Done! Please let me know if any changes need to be made. Maybe a little to long?
@torjunkie Since most if not all of my wiki contribs require edits. Would it make more sense for you to make edits in place i.e just make edits to my post? I don’t mind and this would cut down on (sometimes large) semi-duplicate posts. Plus the edit history is still available.
BTW thanks for helping out with my edit backlog
Libre Software Development VS. Development in a Company
The method used to development of
Libre/freesoftware can vary greatly between projects and factors such as software type and design goals of the project play an important roll when deciding which methodology to use. When developing proprietary software a more tradition method is typically used which used a centralized approach. In this model all aspects of the project are tightly managed and participants are given clearly defined rolls with in the project. Only a select few developers have access to the source code and its not uncommon to have many participants dedicated to core development, project management, implementation and bug tracking.
In stark contrast is the
Libre model which uses a decentralized style encouraging the users themselves to become involved in the development of the project. In this model participants are loosely managed and the source code is publicly available. This model solves many of the issues faced with closed-source development by integrating users into the developmental process. Since
Libreusers have the freedom to use and improve the software any way they like[ref]https://en.wikipedia.org/wiki/Free_software#Definition_and_the_Four_Freedoms[/ref], they make ideal candidates to also assume the role of a “developer” of the project.
[blockquote]The terms user and developer here refer to someone’s relationship to the open source software project in question, not to her identity in the world at large.
The relationship between users and developers can be very porous: every user is a potential developer. This principle is apparent in the Libre developmental model.
Users should be treated as co-developers - Users are treated like co-developers. As such they should have access to the source code of the software. Furthermore, users are encouraged to contribute additional code , bug reports, bug patches etc. By having more co-developers, the rate in which bugs are found and fixed increases substantially. Note that some users have advanced programming skills, and furthermore, each user’s machine provides an additional testing environment. This new testing environment offers that ability to find and fix a new bug. This in turn allows the software to evolve at a quicker rate. This concept is termed as Linus’ Law which states:
[blockquote]“Given enough eyeballs all bugs are shallow.”[/blockquote]
Early releases - Since many volunteers are attracted to help develop the software based on the early release. This first version should be released as early as possible. This increases the chances of finding co-developers.
At least two versions of software should be available
- Stable version - This version has fewer features than the developmental version but has been thoroughly tested and most identified bugs have been fixed.
- Developmental version - For users that desire the use of the latest features not found in the stable version. Since this version has not been thoroughly tested, users must being willing to accept the risk of using a version that does not yet have all bugs patched. users can act as co-developers, providing bug reports and submitting bug patches for the developmental version.
Use a highly modular structure - The structure of the software should be modular allowing for parallel development on independent interchangeable components.
Frequent code integration - Code changes should be merged into a shared code base as often as possible to avoid the overhead of fixing a large number of bugs at the end of the project life cycle. Some open source projects have nightly builds where integration is done automatically on a daily basis.
Dynamic decisions making structure - There is a need for a decision making structure, whether formal or informal, that makes strategic decisions depending on changing user requirements and other factors.
Development in a Company
Libre/freesoftware can not not be accomplished using a more traditional method. With a decentralize approach participants have much more flexibility in the developmental process which allows the software to be developed according to technical guidelines. Although this allows for companies to adapt according to different developmental needs. There are elements that can influence the overall outcome of software.
Third Party Software
For companies that only use software that is developed from within there company, the design goals which users expect can be met with less difficulty. However, this may not be the case for companies that also use software developed by other
Libre/freecompanies. This software is developed according to the design goals of the third party project which may run counter to that of the company that uses the software. This applies not only to packages integrated into the software but also to the standalone software that may be used to support development. Changes to third party software can be time consuming and costly and smaller companies may not not have the necessary resources.
This simple illustration shows third party software used by Whonix. Note that some of the third party software also uses packages from other 3rd party project. Many of these companies do not share the same design goals as Whonix (advanced security and anonymity).
Firefox Web Browser --- Tor Browser --- --- Phabricator (bug/issue tracker) \ / Whonix ---> Infrastructure --- MediaWiki / \ Debian OS --- --- Discource (forum software) / \ Many software packages --- --- Google search engine
The size of the company has a significant impact on development. Although
Librecompanies use the same methodology in development, the developmental practices used to achieve these goals is difference across companies of different sizes.
Many large companies employ many full-time employees and may receive contributions from hundreds[ref]The Linux kernel has about 200-250 companies on average per release contributing patches[/ref] of companies which use and depend upon the software, as well as hobbyist and research developers. Many of these companies also integrate third party packages into their software. If design changes are needed in this software the resources are available to either assign an employee to develop, test and submit a patch, or if necessary sponsor the third party company to make the desired changes.
Since small companies have limited resources they do not have full-time employees akin to larger companies (if they have them at all). Its not uncommon for these companies to have a 1 or possibly 2 core developers along with a small number of community members that make contributions towards development. Quite often, due to limited resources these companies must remain focused on core development which leaves less time to develop new features. This in turn prevents developers from presenting users with a unified experience when using their software.
Making Changes to a Third Party Software
Its common for companies to use third party packages in their infrastructure and also integrated into their software. Although they may provide many benefits to the company, they are not always developed with identical design goals. This can lead to software not functioning as a user expects or may even break other packages. There are several options if changes are wanted in the third party software all of which require time and/or resources
Polity ask the company to make the changes
Submit a Patch that makes sense from their point of view
Fork the software and add your own patches
Use software from an alternate third party project
The methods used to change software is identical whether the request is from a large company or collaborator from a small community. When requesting changes try look at the software from the perspective of the third party project. The developers are more likely to accept the changes if they also benefit the design goals of the project. If significant workload is added with little benefit to the project, the changes would likely be rejected. Many project have instructions specifying how to submit patches on their web site. Whonix Patches Welcome
The last option is to fork the software and add your own patch. Since maintaining an additional software package could increase the workload substantially. Forking software is usually not an option for small companies with little resources. The better option would be to submit a patch so all users of the software would benefit, not just users of software from one company.
My plan is to complete:
curlin Whonix users should use
Then start working on:
Qubes R4 adjustments for DisposableVMs
It looks as though “Libre Software Development VS. Development in a Company” chapter has an identity crisis. The first section is “This is the model, this is what you need to develop Libre” when is should be “LIbre model co-developer concept”.
- “Infrastructure” and “Developmental Version” sections can be removed.
- One of the paragraphs can be removed
- Other edits?
Second section “Development in a Company” needs to be shortened.
- Combing “Company Size” (large and small) makes sense. Remove some content.
- Try to simplify the section
I’ll have the edits completed later on today.
Not sure where we discussed this. Just to make sure: This is not a wiki wide thing. Only when they want curl without stream isolation.
“Libre Software Development VS. Development in a Company” Chapter
Has been updated.
I see where I can condense subheadings
“Third Party Software” and " Making Changes to a Third Party Software"
Not sure centralized vs decentralized is a useful concept here. For example, onionshare is centralized in Micah. And Whonix is centralized in me. Hard to truly decentralize it. I haven’t seen projects where it truely doesn’t matter much if the main developer vanishes.
Libre Software Development VS. Development in a Company
Maybe better compare Windows (same of Mac OS) and Linux distributions?
- chain of command
- authority to issue directives
- possibility to deliver a unified experience (Windows) (CEO can issue directives to the developers of internet explorer to make it fit into the overall vision, guaranteed execution, fire on non-compliance)
- patchwork rug (linux distributions can only pick what’s available, need to ask/contribute nicely while taking the perspective of the third party project)
Maybe a comparison table?
This fits better at the bottom of the text perhaps to justify what’s the point of FLOSS if it’s such as patchwork rug.
The main desire of mine here was to explain to users who come from a nice unified usability experience. Like iPhone - you can complain about many things, but on the points of usability and a unified experience [no patchwork rug], you can’t complain. What I mean, lots of people come from an iPhone experience and then are going to demand the same from FLOSS. They’re entitled to their opinion and demand, but it makes sense to explain why things are as is.
Therefore this also doesn’t fit.
We have that here has
The User Co-developer Concept.
Something like this.
I am sure, prorietary software development isn’t a piece of cake either but we don’t have to explain why that is.
companies: less about company vs non-company. There are also companies working on Open Source. It’s about proprietary (chain of command based development) vs libre distributions (patchwork rug).
Showing some examples is really good.
Companies refers to proprietary software, I guess. In these cases, they often don’t get the source code of third party software. So they can’t submit patches. Neither legal (nor feasible) to fork.
- targeted at users expecting iPhone experience but getting linux distribution patchwork
- rehash the forum posts I wrote before?
- not so much a detail analysis of development inside a company vs open source development style (except: distribution maintainers can only ask nicely, even phrasing a nice request that gets understood is work)
There’s some good stuff there. I’m happy to edit it, but I guess I’ll wait for any reworking first.
It looks like- right idea, wrong interpretation . I assumed “company” meant a large well established project (had grown into a large open-source company) and maybe Whonix was a small open-source company. Oops
This is probably one of the reasons why I was having so much trouble writing this.
I really appreciate you taking the time to get me pointed on the right track. I’ll start working on this right away!
Sound good. As soon as this is complete I’ll start on the “Qubes R4 adjustments for DisposableVMs”
A continually updated chart of mainline hardening defenses:
What would be an appropriate section to add a “kernel hardening status” section to for user reference?
Could this table (DispVM vs inheritance etc.) please be copied to the wiki?
For the changelog. Mostly fixes for Qubes R4 and DispVMs.
I’ll find a home for this table as soon rewrite of Linux Distro vs Windows?? (not sure of title yet) is completed. This is going a little slow as well but I’m starting to make good progress.
Agree with 0brand, that might be a good location for Kernel stuff? Are you going to replicate all that in a mega-table @HulaHoop?
0brand, can you check the onionizing repositories stuff in the security guide? Nothing for Qubes R4, and I’m not sure those old instructions will work.
@Patrick, it’s pretty hard to make head or tails sometimes of those github links re: updates to Release Notes. Much easier from phabricator to see what is actually going on i.e. some basic description.
Also that Authorship page needs further clean up towards the bottom. I may well cut out Sources and 3rd party images to separate pages etc.
Edit: Tor 3.3.6 etc working fine in Qubes-Whonix. 3.3 series will make it to Whonix 14 stable repo I presume
I went through the onionizing repos docs (tested everything) and most of it looks good.
These are my proposed changes
1. Qubes onionizing: Fedora, Debian, Whonix Templates
Use a wildcard ( * ) in command lines so they work for both
Example: (tested, works)
.../etc/apt/sources.list.d/qubes-r3.list && cat /etc/apt/sources.list.d/qubes-r3.list'
.../etc/apt/sources.list.d/qubes-r* && cat /etc/apt/sources.list.d/qubes-r*'
2. Whonix and Debian Packages
Currently makes reference to “jessie” in section which users must copy and paste into their repo file.
- Perhaps make note that users should replace “jessie” with “stretch” when using Debian 9?
- Once Whonix 14 is stable, change instructions to use “stretch”.
3. Onionize Tor Project Updates
Qubes R4: Since the connection fails when adding the Tor Project deb apt signing key in the TemplateVM. Make note for users to follow instruction in a StandaloneVM.
4. Change all instructions to use v3 .onions and make note of Qubes,Whonix v2 .onion addresses??
@torjunkie Thanks! I needed a little change of pace.
In the onioizing Qubes packages command lines these are not considered varliables are they? If so they never worked.
It never made sense to me that instructions would have users onionize
all TemplateVMs sinced your supposed to keep 1 template each for Debian Fedora etc. in unaltered state. For testing etc.I assumed users where required to replace e.g. $FedoraTemplateVM with Fedorea-26.
If I’m wrong that needs to be changed to
Too little thing for the effort of a StandaloneVM. gpg / apt-key can probably use networking when requests are going through Qubes updates proxy. Another option would be fetching the key in a networked VM and then copying it over as text or file.
That would be great if you could fix those instructions 0brand! It all looks very sensible.
You are great with technical steps and breeze through that stuff. I’m actually very jealous
No. too much unnecessary work. All I wanted was to point users to info on bug mitigation advancements in the kernel so they can assess their sec situation.