Describing the Linux failure landscape

 

The Linux online forums have to handle a lot of request from disappointed users. The typical situation is that a certain Linux distribution isn't working with a concrete piece of hardware. And nobody in the forum knows the exact reason or can fix the problem upstream. Instead of explaining what each single case was let us give a birds eye perspective about linux compatibility in general.

The overall situation has nothing to do with init scripts or kernel modules but the problem is located on a time line. A hardware vendor releases a product to the market and is selling the product for 2-3 years. During that time, the product won't work with Linux for sure. That means, the touchpad of the notebook isn't recognized and the graphics card can't display even standard VGA signals. The only way to run the hardware is the Windows operating system.

If the product delivery was stopped after a while and was replaced by a new product it is possible to write open source hardware driver for the product. This results into kernel patches. Without these hardware driver, the linux kernel can't recognize the device. Until the newly written hardware drivers are put into the kernel and shipped to normal Linux users it will take another 2 years. So we can say, that after a certain period Linux works great with the hardware.

The critical time span are the first three years. If a product is sold, no Linux support is available. And if the product is outdated, it will run fine in Linux. Which customer likes to run Linux on brandnew devices? Right nobody because the customers are aware of the problem.

Let us summarize the situation a bit: most (90%) of all the Linux bug reports in online forums are about recent hardware. It is very unlikely that somebody finds a problem with outdated hardware because if the product is 5 years and older the chance is very high that it will run out of the box with Linux. So basically Linux provides something nobody was asking for.

Technical experiments wiki-pov fork

The precondition for a successful fork project is, that the fork gets all the patches from the upstream projects. Otherwise the branches are of sync. At the same time, the goal is to not sync the branches so that it make sense to create a fork which looks different. This sounds a bit complicated so let us go into the details of using the git tool for merging different branches.

The first attempt in using only 2 branches was not succesful. The idea was, that the upstream is copied in to the master branch, while the fork is edited in the issue1 branch. The first merge was working fine, but after the second merge some conflicts are the result.

The next next was to use three branches: upstream, master and issue1. This is working much better and it like to explain the idea. The first thing to do is to initialize in a working directory the git repository:

git init

git branch issue1

git branch upstream

git branch

On the screen there are three branches available in which the user can edit. In the upstream branch the snapshot from the wikipedia website are stored. The file article.txt hold the current version which is updated once a month. The upstream is merged into the master branch, and then it's merged into the issue branch. In the issue branch the fork can be edited. Now, the next version of the upstream version is stored in the upstream branch.

And now the magic happens, the user switches to the master branch and executed the following statement:

git merge upstream

git merge issue1

What the git software is doing is to combine the latest upstream version with the fork into a new file. The resulting article.txt contains all the improvements from Wikipedia but it contains also the updates from the fork.

I know, the overall procedure is very complicated because the user has to type in many commands into the terminal. So the prediction is, that some errors will upraise. But in general the idea is to use three branches and merge them into the master branch. In contrast, the upstream branch holds only the upstream version history, which is equal to the timeline of WIkipedia provided in the website.

The chart from the beginning will increase the confusion. What the user needs to know is that he has to copy the latest version of the Wikipedia article into the upstream branch, and commit the changes with “git commit”. It's also important to not delete the branches after merging, because the issue1 branch is the forked version which looks different from the upstream. If the user want's to edit the encyclopedia he is doing so only in the issue1 branch. The master branch is some kind of clearning branch in which the two other branches are combined.

POV forking of Wikiipedia

On the first look the git tool and the Wikipedia project are working the same, because they are supporting a version history. The difference is, that the Wikipedia project never was forked in his history, only local copies are created. A fork is technique used heavily at github to bypass the original community and start developing a new branch. The main feature of a fork is it's ability to integrate the updates of the upstream. That means, the fork contains the latest information plus extra content.

The subject overall is very complicated. So i have decided to make a simple experiment to test what will happen in the reality. For the first step, the fork is created only on the local harddrive but not in the Internet, and it's not the entire Wikipedia but only a few files. But it is well documented so that other users can reproduce the steps. It starts by creating a new git project in a working directory:

mkdir wiki-fork

git init

touch readme.txt

git add --all && git commit -m "initial commit"

Then the folder is populated with three files from the original wikipedia, With a copy&paste the latest markup-file is created in the directory. What we need also is a branch:

git add --all && git commit -m "create three files"

git branch issue1

The idea is, that the fork is maintained in the issue1 branch while the original project (upstream) stays in the master branch. The merge is done with the following command:

git checkout master

git merge issue1

git branch -d issue1 // delete branch

The idea is, that in the issue1 branch my own individualized Wikipedia version is available in which only i can edit, similar to a sandbox. The created edits are never send back into the Wikipedia but they are merged on the local harddrive into the master branch. The best visual understanding is a github project in which a fork is created. In theory, this allows to the developer to become independent from the original project.

The open question is, how does it work in reality. I have searched at Google for some information but didn't found something. So i have to test it out. The critical point is, that sometimes the upstream will update their content. That means, if the wikipedia community change one of the three files online, i have to update the content in the master too. The problem is, that the information in the issue1 branch are different from that so there is need to merge. It's unclear how often this is necessary. The hope is that a merge is needed only once a week, and that it can be done automatically. But in case of doubt it will result into a merge conflict and it's unclear how to solve it.

What we can say is, that the git tool is a here to stay. It's the most advanced forking / version control system available and was designed with the desired purpose in mind.