Whats the problem with self-driving cars?

 

Some attempt were made in the past by Waymo and Tesla to push autonomous driving forward. In an interview a journalist has asked at which moment in the future these cars will become available for the public. The engineers itself doesn't know. There is a general prediction available that after 2025 autonomous cars will be available but it is unlikely that this will become the reality. In theory it is possible that in 2025 the starting point is delayed to 2035 and so on.

This sounds surprising because from a technical perspective all the problems are solved or can be solved with minor improvements. Today's software connects a car with a cloud based infrastructure, a 3d lidar scan creates a precise map of the environment, the SLAM self localization algorithm knows where the car is, and advanced path planning generates the route for the car. So, where is the bottleneck, why are autonomous cars not available?

The problem is, that autonomous cars are without any doubt an AI technology. AI means, that it wasn't available in the past but everything was invented from scratch. The interesting situation is, that Artificial Intelligence has failed to control more simpler domains, which are autonomous trains and autonomous subways. And the engineers want to automate highly complex cars which are driving next to human controlled vehicles.

Instead of asking at which moment autonomous cars will become available we have to ask why it is so complicated to automate cargo trains and the subway. From a technical point of view, a train has no steering wheel but it can only accelerate and brake. The workload for the human operator is much lower and it is easier to create software which can handle the task by it's own. The reason why these software isn't used in reality is because train automation is to complicated for today's AI as well. Or to be more precisely, every task in the world which is important can't be handled by AI algorithms.

Let us analyze some existing press reports about train automation. There are some success stories available about robotics project. The shared similarity is, that all of these attempt are explaining how the future will look like. Not a single example for a working prototype is available. What all the railway companies are doing is that they are figuring out how to realize such future trains. But no one has found a reliable solution which can deployed in the reality.

To understand the situation we have to explain the difference between AI based automation and non AI automation. Non AI automation means to build highly complex machines but let a human operator control the system. AI based automation is the other way around. These systems were designed without a human in mind. Let us give some example. Non AI technology is a minor improvement of existing machines. For example the train gets a better chair for the pilot. Or the monitor gets a higher resolution. Everything else remains the same and no experiments are needed. This sort of technology has a high chance to become reality within the next 10 years.

In contrast, AI based technology is trying to reinvent something from scratch. Instead of improving something by 0.1% the idea is to revolutionize the domain, reduce the costs to a minimum and show what state of the art technology is about.

Autonomous trains

It was claimed that autonomous cars and trains are not possible within the near future. To understand the reason why we have to investigate some press releases about current projects. Autonomous trains are introduced to the audience as a demand. It is explained, that the requirement in the future will become higher and there is need for robotic trains. This statement is correct. Indeed the demand for such technology is there. In another press statement it was written that in the year 2019 an autonomous train was demonstrated on a 48 mile test track. Some detail information about the technology was given too. In another article, autonomous trains are compared with automatic elevators and it was made clear that some challenges need to be addressed before the technology is available.

Does this look like something which is available today? Or which can be realized within the next 10 years? No, it is a vision for future transport systems and nothing else. It is a technology which can improve the life and reduce the costs but nobody knows how to realize such things.

Perhaps another example would help to understand what the situation with robotics is. In the year 2011 the japanese powerplant in Fukushima was hit by a tsunami. At this time, no robots were available to fix the problem. This was a surprise for the public, because in the TV many prototypes were shown in the year before. From the year 2011 until 2020, robotics engineers have taken the issue more seriously and have developed new robots, which can be used for practical applications. Really? No they didn't. The current status is the same like 10 years ago. No robots at all are available. Even remote controlled robots are not reliable.

Why are robots not available?

How can it be, that on the one hand advanced biped robots are developed by engineers and autonomous cars are demonstrated on a real road, but at the same time, the technology is not available for deployment? The paradox can be understood by explaining what is shown exactly in a video or in a paper about a biped robot. Suppose a new robotics video was released in which a robot is able to climb stairs and play football. For the audience, this demonstration looks very impressive and the engineers are proud of the newly written software. The shortfall is, that the demonstrated technology isn't a robot but it is artificial life. Artificial Life looks very impressive to humans but at the same time it is completely useless.

A useful robot is able to replace a human worker. This is the meaning of the word robot. In contrast, Artificial Life doesn't replaces something but it is adding something not available before. Creating artificial life is from a technical perspective an easy to solve problem. The early braitenberg vehicles, a computer game with AI characters and today's biped robots can be understood as artificial life. These machines are doing something, and they need energy for the task. The problem is that humans can't utilized this behavior for their own purpose.

What humans are doing instead is to invent the task which fits to the robot. Let me explain the situation in case of an autonomous car. The starting point is to build the car including the sensor and the software. An engineering team assembles the onboard computer, the lidar and the gps navigation system into a self-driving car. In the next step the car is released to a track on the normal road. The assumption is, if the cars drives on a normal road during a rush hour and no human intervention is needed the engineering team was successful.

No they don't. What the engineers have done in reality is to redefine the public road into an experimental track. Not the AI controlled works fine, but the other cars are robust against interruption.

Kitchen robot

Robots are not helping the humans but they force them into a certain social role. In case of a kitchen robot this problem should be explained briefly. Suppose, a kitchen robot was built which can make a sandwhich with two dexterous arms. Building such robot is possible with today's hardware and software and some online videos are showing how such a robot will look like.

Focussing only on the robot itself is only the first step. The more interesting problem is, how to deploy this technology into the reality. There are two cases available. First idea is, that a normal kitchen gets improved by the robotic helper. And the second idea is, that the robot gets deployed into its own kitchen and humans are invited to join the room.

The second case is shown in the reality. The robocup@home challenge has demonstrated these robots. In all the videos, a newly created kitchen was shown and the human participants are acting with a certain rule set. They get a clear instruction how to interact with the sandwich making robot. At first, the human has to smile. Then he has to press the start button, then he waits some minutes until the robot is done, and then the human has to take the sandwich and eat it. He has to stand in a certain angle to the camera so that the robot and the human is shown at the same time.

The interesting situation is, that the robot can't be deplayed into a real kitchen. Because in this case, the human operator has to guideline who to interact with the robot. It doesn't make much sense to press the start button if no camera is filming the scene. Even the engineers who have created the kitchen robot have no working robot in their own kitchen. If they want to eat a sandwich they will order it from a company.

Artificial demonstrations

Perhaps it makes sense to analyze in detail how robots are deployed into artificial use cases. The robocup@home challenge was mentioned already. It is one of the most famous robotics shows in the world. In a larger building many robots are shown at the same time. There is a soccer playground, a kitchen and a maze with obstacles. All these domains are created from scratch. That means, the kitchen isn't used as a real kitchen, but it is a kitchen to deploy robots.

In such a non human kitchen, the robot laws are established. The engineers who have programmed the robots want to show a certain behavior. They are creating around the robot a scenario which contains of different tasks. What will happen, if no audience and no camera are available during a demonstration? The robot kitchen is useless. It works only if somebody will see what is going on.

This is perhaps the most major difference to a real kitchen. In most kitchens, no cameras are deployed which are filming the scene, but a kitchen is the room in which the meal is prepared. The interesting situation is, that the gap between an artificial kitchen and a real one can't be bridged.

All the advanced robots shown in television and described in academic papers are working fine in artificial situations. Around a certain robot, a scenario was created which has to be solved by the robot. A biped robot needs as an environment a staircase. An autonomous car needs a road, and a pick&place robot needs an object. The funny thing is that the robots can handle these domains very well. As the result a human observers things, that the engineers have solved a certain problem with advanced algorithms. The problem is that an artificial playground a real world applications are working with different rules.

Basically spoken, if a sandwich making robot is creating a sandwich in it's own kitchen the task is useless. Except the engineers, nobody cares about the result and nobody would buy such a robot for it's own purpose.

What is a robot kitchen?

A robot kitchen is an artificial playground to demonstrate AI technology. It contains of a refrigerator, a table and some food and helps to evaluate the capabilities of a robot. A certain robot can grasp the apple from the table or he fails with the task. A robot kitchen is some sort of a game. It is not part of normal life but was created from scratch to evaluate the consequences.

Robot kitchens are used frequently by robotics engineers. All the papers in which advanced household robots are mentioned are shown in robot kitchens. The assumption is, that a robot kitchen is a great testbed which helps to bridge the gap between reality and imagined future. If a task was demonstrated in the robot kitchen, the robot is ready for deployment – this is at least the claim.

What exactly is the meaning of deployment? The idea is that a robot is sold to the public, replaces human workers and is doing a task by it's own. The reason why robot kitchens were built is because to support this goal. The paradox situation is, that at the same time an artificial environment prevents that a certain robots gets released to the public. To understand this situation we have to take a look into the history.

In the 1970s the assumption was that industrial robots can be deployed directly to the industry. The engineers have identified a workplace, and created a robot for this job. Then the machine was powered with electricity in the hope to increase the automation level. After some attempts it was recognized fast, that the newly installed robot was doing a poor job. After a while the machine was switched off and it was labeled as a failed automation project.

The idea of the engineers to improve the situation was to invent a playground to extend the testing of a new robot in a realistic scenario. Such a playground can be a virtual simulation on the computer screen, or a robot competition like micromouse. Since the 1990s, such playgrounds are used frequently and they evolved over the years.

Creating new playgrounds and programming robots which are working well under artificial condition is an easy to solve task. What remains an open problem is how to transfer a robot from the playground into the reality.

Automation market worldwide

According to the latest stats, around 2.7 million robots are available in the world and each year 350000 new robots are shipped to the companies. On the first look, these numbers are looking very positive. It is a sign, that the robot revolution has started and it is growing.

A closer look into the details will show, that automation is never realized with robots but with automation technology. Automation technology means to install electrical servo motors, assembly lines and even an electric driven truck. There are many obvious problems with the mentioned 2.7 million robots worldwide.

First issue is, that a large amount of robots are nothing else but classical automation technology. For example, a CNC machine is not a robot. Second problem is, that lots of real robots for example robot arms are not used in production environment but they are sold as teaching robots. They are used outside the factory in a university lab.

A positive future

There is a reason available why robotics projects are not analyzed with objective measurements. Because the engineers are believing in a vision. They want to change something in the world, and see a robotics project as one way in doing so. The first place in which robots were mentioned was the science fiction literature. They were developed as tool to tell a new sort of stories. Then the same idea was established in the reality. A robot project gives an idea about a possible future world.

If robotics engineers would be honest to themself, they know in advance that their robots are useless. But if they are not creating such projects, who else is in charge? Somebody has to stand up and claim that robots are useful in the world of tomorrow.

Suppose it is possible to convince today's robotics engineers that their work is useless. All the autonomous cars, robo trains and kitchen robot projects would be stopped because of missing values. From a rational perspective this would be the optimal decision but is such a future a nice place to life?

Warum größere Projekte in Python keinen Sinn machen

2017-10-04 C++, import from other blog

Von den Sprachstandards her ist Python ausgezeichnet um größere Projekte darin zu realisieren. Die Python Virtual Machine ist hinreichend robust, die Python-internen Möglichkeiten zur objektorientierten Programmierung sind vorbildlich und das Modulkonzept erlaubt es Klassen zu Packages zu aggregieren. Technisch gesehen kann man mit Python durchaus Projekte mit 100k LoC oder sogar noch mehr realisieren. Es gibt nur ein Problem: wer möchte diese Programme verwenden? Endanwender machen üblicherweise einen großen Bogen um GUI Applikationen die in Python erstellt wurden, und Systemprogrammierer werden garantiert keine Libraries einbinden, die in Python geschrieben wurden. Dagegen spricht schon die geringe Performance. Python erinnert an das Schicksal was Turbo Pascal ereilt hat: es ist eine Lehrsprache in der Programmierausbildung, kann aber nicht für reale Projekte eingesetzt werden.

Die Sprache als solche ist vorbildlich: Python ist sehr elegant designt. Und es lässt sich darin auch produktiver Sourcecode schreiben, in dem Sinne dass man für einfache Aufgaben wie das Sortieren eines Arrays eben nicht erst tagelang in Foren um Rat fragen muss, sondern einfach den pythonic way of life verwendet. Nur, stellen wir uns mal vor wie das in der Realität konkret aussieht. Man schreibt sein elegantes Python Programm runter, es besteht aus 12000 Lines of Code, nutzt dafür selbstverständlich mehrere Klassen und dann? Rein theoretisch ist das Script jetzt überall ausführbar, aber wer will das auf seiner Maschine tatsächlich verwenden? Das Problem mit Python ist, dass es nur eine weitere Programmiersprache ist in einer ganz speziellen Nische (anfängerfreundlich und interpretiert) und das der damit erstellte Code garantiert nicht in größere Projekte wird einfließen. Genau genommen kann man Python Programmierer nur bemitleiden, weil ihre schönen Programme sonst keiner haben will. Java Programmierer werden ganz sicher keine Python Bibliothek in ihr Projekt einbinden, C Programmierer auch nicht. Mit etwas Glück kann man die Library im Pypi Repository unterbringen, aber das wars dann auch schon. Es ist keineswegs Zufall dass es keine großen namenhafte Python Projekte gibt, mit mehr als 10k LoC. Wie gesagt, rein technisch geht das ausgezeichnet, nur leider ist die Welt außerhalb von Python sehr viel kritischer in solchen Dingen.

Ich bin mir nicht sicher, ob Guido van Rossum der Welt einen Gefallen getan hat, als er die Sprache erfunden hat. Auf den ersten Blick hat Python viele Vorteile. So richtet es sich nicht explizit an Informatiker sondern an Wissenschaftler aus den Bereichen Physik, Linguistik und Geschichtswissenschaften. Ferner ist als interpretierte Sprache mit kurzen Edit-Compile-Run Zyklen konzipiert wodurch man in kurzer Zeit viel Code schreiben kann. Genau genommen ist Python also in eine Lücke vorgestoßen wofür es davor noch keine Sprache gab. Aber kann es wirklich das Ziel sein, zu den gefühlten 500 Programmiersprachen immer weitere hinzuzufügen um darüber die Spaltung der Entwickler voranzutreiben? Reicht es noch nicht, wenn Java und C# Programmierer gegeneinander arbeiten? Braucht man neben PHP, go und Perl noch weitere Sprachen? Python hat sogar das seltene Kunststück fertiggebracht zu sich selber inkompitbel zu sein. Bekanntlich laufen Python3 Programme nicht mehr auf einem Python2 Interpreter. Und das Pypy Projekt ist zwar ein JIT Compiler kann aber nicht alle Bibliotheken aus cpython verarbeiten. Irgendwie ist Python eine ganz eigene Welt die im universitären Umfeld prächtig gedeiht und die dazu führt, dass Leute ihre Zeit verschwenden. Anders kann man es nicht ausdrücken, wenn man Ressourcen in den Aufbau von Python Sourcecode investiert.

BEISPIEL
An einem kleinen Beispiel möchte ich das Thema vertiefen. Früher habe ich schön mit pygame Spiele programmiert. Das geht wunderbar einfach, und mit erstaunlich wenig Sourcecode. Man fängt einfach oben an mit “import pygame”, aktiviert das Fenster, und schon kann man seine erste Box auf den Bildschirm zaubern. Jetzt wo ich nicht pygame nutze, sondern in C++ mit SFML das Spiel realisiere ist es deutlich aufwendiger. Man muss sich durch Manuals auf English wühlen, es gibt für alles mindestens 4 Möglichkeiten und mehr Sourcecode benötigt man auch. Für den Computer macht es keinen Unterschied. In beiden Fällen sieht man eine GUI in der etwas angezeigt wird, und beidesmal mit ruckelfreien 60fps. Der Unterschied liegt in der Community die hinter der Sprache steht. Projekt-1 wendet sich an die Python Community, also an Nicht-Informatiker, während Projekt-2 sich an C++ Programmierer richtet. Die Community unterscheiden sich im Anspruch an sich selbst. C++ Programmieren tönen lautstark dass sie die besten Programmierer der Welt seien und demzufolge haben sie auch den Ehrgeiz die besten Programme des Universums zu schreiben, während es in der Python Community sehr viel entspannter zugeht, in dem Sinne dass man sich gegenseitig versichert Anfänger zu sein und überhaupt sich eher mit mit inhaltlichen Dingen und weniger mit Programmieren beschäftigt. Damals in Python war meine Produktivität immerhin bei stolzen 10 Zeilen Code am Tag, jetzt mit C++ in SFML ist sie abgesunken auf 5 Zeilen täglich. Dadurch verdoppelt sich natürlich die Zeitdauer bis das Projekt fertig ist.

How to reduce the traffic in a blog to zero

The first thing to do is to avoid larger blogging websites like wordpress and medium and select Google Blogspot as the blogging website. Google Blogspot doesn't has commercial advertaisment which makes the space not attractive for a larger audience. Additionally, Google websearch doesn't indexes the blogspot subdomain so the newly created blog is nearly invisible in the internet. After creating some blog posts the user has to rename the blog. This can be realized with the settings menu. The result is, that even the blog was discovered by external search engines like bing, the URL becomes obsolete and the newly created URL has to discovered again. This will drop the daily pageview counter down to zero for sure.

The open question is, what to do with a blog which has no audience? This is outside the scope of this tutorial. Here, it was only explained how to create such a C- weblog. The only thing what is for sure is, that the no comments were written by external internet users, and that no search engine will find the blog.

First look into Debian 10

Debian 10 was released in mid 2019. Installing it on a virtual machine make sense, but the more interesting idea is to install it on a phyical notebook. I have done so and it works reasonable well. The most obstacle was the installation proecudure itself. After booting the USB stick, the user has the choice between a Gnome based installer, a graphical installer and a text install. I have choosen the graphical installer but it was a bit complicated to browse through the options. After a bit reading the manual an installation was possible, but especially newbies will find the installer difficult to use.

The more elaborated way is the modern gnome based installer. Which works better but needs more system ressources. In the next installation it is the better choice. After the system was installed on the PC the first bootup was using the wrong graphics settings. The user has to manual install the non-free driver which fits to the graphics card. Selecting the correct package has to be done manual. That means, the user has to know that the resolution problem can be solved with a non -free driver and then he has to read the wiki section to identify which driver needs to be installed. Similar to the installation software this step is a bit hard for newbies.

After mastering the step the system runs great. All the programs are available which means that firefox, Spreadhseet programs, python 3 and all the other open source software runs out of the box. The system requirements are on the same level like in Fedora and Arch LInux, which means that an idle PC will need around 2 GB of RAM and the Debian OS occupies around 15 GB on the harddrive. Compared to early Linux systems for example slackware the hardware requirements are high, but in comparison with Windows 10 it's a midsize system with moderate requirements.

What is important to know that before the user will accept the Debian philosophy he has to understand the advantages of a stable system over a rolling release distribution. If the user isn't familiar about the details of git branches and how a stable branch is monitored for security issues, he won't like the Debian philosophy very much. The reason is, that a short look into the version history of all the software will show, that Debian is outdated. Firefox is obsolete since 6 months, the Linux kernel is an older one and Python is not the current version.

The main advantage of Debian over other Linux distributions is, that all the Debian users have installed the same software. On 2020-04-27 it Debian 10.3 which means, that the user will need for exactly this version a handbook, security patches and updates. This makes it more likely that after installing an update the system will run without interruption. In contrast, the situation at Gentoo Linux and Fedora is, that every user has installed a slightly different Linux system which makes it hard to trace errors back. Therefor, Debian has much in common with Windows 10 in which all the users have installed the same version. This is important to blame the right opponent. That means, if the user has installed Debian 10.3 already, and something isn'T working it the fault of the Debian project but not of the single user.

Debian Release management

A short look into the Debian release schedule https://wiki.debian.org/DebianReleases provides helpful information for the endusers. In general, each version is maintained for 2 and a half year which means, the user has to install the Operating system once and can use it very long. If the 2.5 years are over the user can update to the next release with a simple command line. This brings the user in a very comfortable situation.

What is not answered in the release chart is how to program all the software. The Linux operating system contains of hundreds of programs and it's unclear how these programs are working together. From the users perspective this is a mnor problem, but it's up to the developer to program and test the code.

Perhaps this is the most obvious difference between Debian and other operating systems like Arch Linux. In Debian there are two conflicting social roles: normal users vs. developers. The social role of the user is installing the software and then it is using all the code without doing anything in return. While the social role of a programmer has to do with fixing issues, compiling sourcecode and monitor security issues.

The simple explanation is, that two conflicting roles are equal to a professional Linux distribution. If a linux distribution has only one role which is the developer, it can't be called a serious distribution. A wrong assumption is, that the conflicting roles are only available in closed source ecosystem in which the user has to pay 100 US$ for the operating system while the other side takes the money and programs the code. The surprising situation is, that the same social roles can be imited in the Open Source world as well. The idfference is, that Debian users aren't paying money. The result ist, that the quality of the software is lower. The latest Debian 10 software has a weaker quality than the latest Windows 10 version. In Windows 10 the graphics card is working better, the PC needs less energy and the installation works more smooth. These disadvantages have to be accepted by the Debian users because they get the .iso file for free.

The advantage of Debian over other LInux distributions like Gentoo, OpenSuse and Fedora is, that in Debian it's possible to become a normal end user. An end user is somebody who doesn't write sourcecode nor he fills out bug reports, but he is using the software. Very simlialr what most users are doing with Wikipedia. They type in the adress into the URL bar and read the content which was written by other.

Most Debian experts are arguing that their operating system has a greater stability than other linux distributions. What are they talking about? A naive assumption is, that stable means, that the software is secure or has no bugs. This is only partly true. The current Debian 10 stable has a lot of security issues, and some minor bugs too. What stable means more concrete is, that the development is done in a stable branch. That means, Debian contains of a unstable branch and a stable branch. The existence of a stable branch allows to publish longterm versions which are running 2.5 years on the computer. In contrast, Linux distribution which are not stable like Arch Linux or Fedora need to be updated once a week and in case of doubt, the system won't boot after the update.

The term stable is referencing to a publishing schedule in which every 2.5 years a new release is available and during this period the user is running the same version on the computer. The stable branch is a technique to provide this release schedule.

Some arguments for Arch Linux

Arch Linux plays a unique role under all Linux distribution. Because the Linux distribution can be explained very easily. The latest version of each software is compiled and installed on the PC of the user. The Arch Linux wiki and the pacman package manager are supporting this workflow very well. Most users understanding the idea behind Arch LInux so they using it at least for playing around.

From a more abstract perspective, Arch Linux is a developer friendly distribution. It supports the idea of agile software development. If a certain subsystem has a problem, a bug is created, the sourcecode is improved and with a delay of less than 24 hours the updated binary version can be downloaded from the server. No matter if the sourcecode of Firefox, Linux kernel, a texteditor or from a game was improved, the sourcecode gets compiled into binary versions and the user can download it from the server.

Unfurtunately, the Arch Linux project has some limits. It is used not very often in productive envirionments. In theory it's possible for doing so. That means, on a vserver an Arch Linux system can be installed and on the Laptop as well, but only few people are doing so. The exact reason is not defined clearly. Sometimes the explanation which is provided is, that sometimes the Arch Linux system won't boot after an update. But with the recent improvements of pacman this is seldom the case. In most cases, the boot process is working fine, and if not the manual intervention is minimal. Another explanation why Arch Linux isn't used in reality is because the concept is too new. That means, the concept of agile development and a rolling release doesn't fit to the well known waterfall software cycle so its hard to convince a larger audience in using the software in reality.

The more realistic description why Arch Linux isn't used for productive environment has to do with conflicting needs of developers and normal users. Arch Linux was developed from coders for coders. The project is located in the upstream and explains that the upstream is equal to the downstream. Everybody is a programmer and in exchange he gets the most secure software ever programmed. This story doesn't fit to the reality. First thing is, that most users are not interested in creating software, but they want to use it as a normal user. Arch Linux ignores the idea of software quality checks.

Let us describe the preconditions behind the Arch Linux workflow. The idea is, that the upstream never makes a mistake. If the Linux kernel was improved from version 1.0 to 1.1 this improvement make sense and there is no time to argue for the reason why. The problem is, that most software was written by amateurs and they are not programming the software for the normal users, but they are programming the code for other reasons. Especially in the Open Source ecosystem most software projects are started because the developer team likes to try out something. For example, somebody likes to learn how the C language is working and therefore he starts a gaming project in which the C language was used.

The average user assumes that the upstream has programmed malware, which is spying the data from the user. In contrast, the upstream assumes, that the normal user has no experience with computers at all and therefore he needs pre-defined settings. The consequence is, that no trust at all is available between upstream and downstream. This problem is ignored by Arch Linux. Arch Linux assumes, that no conflict between upstream and downstream is there.

Update over the Internet

Rolling release distributions like Arch Linux have become successful since the advent of fast internet connection. If the users are euipped with a stable internet connection, its possible to update the osftware every week. This narrative reduces the comparison between rolling release and stable release to a file transfer problem. The more elaborate comparison is focused on the development process. The bottleneck is located on the upstream level. Before a software can be installed somebody has to write the code. Software development is done with the git version control system in which a team of programmers are writing lines of code. The software development process has to be organized in a certain way. The management of writing code can be realized with rolling release and stable release.

Rollling release is equal to a single branch model which is trunk. It is the same principle used in a wikipedia article. There is only one current version of the wikipedia article and everybody is allowed to modify it. It is surprising to know, that in reality most software project doesn't work with a single branch model. Because software development is more complicated than creating a wikipedia article.

The first reason is, that the amount of commits is higher. The average wikipedia article contains of only 20 commits over a timespan of 1 year. While the average software project contains of thousands of commits. The second problem in software development that different tasks has to be solved in parallel. It's is possible to create new features, improve the security, update the documentation, and fix existing bugs. The best practice method in doing so is to use two branches or more.

The problem with two and more brnach models is, that no longer a current version is available. A current version means, that all the branches are merged into a single one, which is not the case. Instead, the average software project has many current versions at the same time:

• a current testing version

• a currrent security version

• a current stable version

• a current bugfix version

• and so on

The additional problem is, that these versions are improved independent from each other. This is the major advantage but also the major disadvantage of the git version control system. A rolling release software makes only sense if the development model is based on a single trunk branch.

Let us describe a common three branch software development model. If a one man project or a small team is starting a new project at github they will create three branches: stable-branch, issue-branch, testing-branch. If the developer likes to fix an issue from the bugtracker he will submit into the issue-branch, if the maintainer of the project likes to aggregate different bugfixes into the testing version he will merge the issue-branch into the testing branch and if a new stable version should be created, the testing branch is copied into the stable branch.

This three branch model is some sort of best practice method in software development. The surprising information is, that it's not a rolling release version. Instead the new versions in the stable branch are produced with a time lag. That means in january 2019 the bugfix was created, in March 2019 the testing branch was updated, and in June 2019 the new stable branch version was created. In this example, it took 6 months until the bugfix was available in the stable version. This timelag can't be reduced. The reason is, that the amount of ressources in a project are limited. For example, if the github project was created by 2 programmers, the maximum amount of written codelines per day is only 10x2=20 lines per code.

Let us make a small example. Suppose, the team likes to improve the software with 3000 additional lines of code. According to the math, they will need 3000/20=150 days for the task. If they are starting today, they are finished in 6 months. This delay produces the time lag in the release workflow. The only way to reduce the time between the occurence of a bug and until it was fixed in the stable version is to increase the amount of programmers. If the team has access to 200 programmers, they can reduce the timelag drastically.

Freezing the upstream

In the first example, a rolling release software project is described. It contains of a trunk branch which is updated once a day. The normal user is asked to install always the latest version, because it contains all the improvements and security fixes.

In the second example, a stable release is described. It is created by freezing the trunk branch. That means, on a certain time in the past, a copy of the sourcecode is created in a different folder. And then the copy gets improved to fulfill the needs of the normal user. Freezing the upstream is done as an addition to a normal upstream development. At the same time, the upstream trunk branch gets improved without interruption. That means, the stable team is able to create the freeze independent from the upstream developers.

It depends on the concrete software project how complicate it is to freeze the trunk branch. In most cases, the point release is created together with a handbook, security updates and bug reports against the stable version. The only thing what is sure is, that an additional stable branch needs more effort than only improve the trunk branch. A trunk branch has to do with the software project itself. Which is focused on the sourcecode and the improvements. While a stable branch has to do with the needs of the normal users.

Wikipedia edits made easy

Creating Wikipedia edits is a very complex task. Lots of papers were written about the topic in the past. The good news is, that Wikipedia edits can be formalized and repeated over and over again. The common Wikipedia edit contains of two steps: creating keypoints and writing prose text.

Unfortunately, most long term Wikipedia authors are combining these steps into a single edit. They submitting the changes to an article without further comments. This behavior makes it harder for the newbies to create edits by their own. The better idea is to assume, that the newbie has no experience with WIkipedia at all and likes to contribute to the project in a predictable way. That means, without producing conflicts and without getting banned because of false edits.

An easy to follow edit strategy contains of the described two step pipeline. In step 1 the newbie is posting keypoints for an article to the discussion page and in step 2 he converts these keypoints into full sentences. The good news is, that this strategy is described under the term “creating powerpoint presentation” Since decades. A powerpoint presentation contains of the same steps. In step 1 the author prepares the presentation at home and writes down the keypoints to the slides. In step 2 he helds the presentation which is equal to convert the self created keypoints into natural speech which contains of full sentences. The second step is done in front of the audience. That means, the lecturer not only reads the keypoints loud, but he is using the keypoints to talk about the subject.

Its interesting to know that the two step pipeline for creating powerpoint presentation is the international defacto standard. All the presentations in the world contains of written keypoints stored in the slides plus the oral presentation in which the speaker formulates full sentences. Its not possible to make a presentation in a different way.

Its a bit surprising that in the Wikipedia ecosystem this two step workflow is not known. In the official help section the steps are not mentioned. Instead the official tutorials are assuming that an edit is the smallest item which can't be divided into sub tasks. This assumption is wrong. A wikipedia edit is equal to submit prose text to Wikipedia which is annotated with bibliographic references. Before this prose text can be added to an article, the author needs a preparation step. He has to read through the existing information and he has to make some keypoints what he has read in the papers.

Most authors are storing this prestep either on their local harddrive or they are trained well enough to not need such a step. For newbies the recommendation is, to submit the created keypoints to the talk page, because this helps to get a better overview. Newbies are allowed to make mistakes, which can be located in two steps. Either the newbie struggles in making notes by reading existing information. Or the newbie isn't able to formulate the self-created keypoints into prose text. Getting feedback at which step exactly the error was introduced will help a lot.

That means, it is not enough to judge that a certain edit is wrong. But the more elaborated question is, if the creation of keypoints was a problem or the transfer of keypoints into prose text.

Well written articles

Let us analyze the existing articles in Wikipedia. What they have in common is, that they are written for the enduser. They are formulated in prose text and they are equipped with bibliographic references. A wikipedia article and a recorded powerpoint presentation have much in common. They can be read/listen from start to end and in most cases the text makes sense.

What is not given by the average Wikipedia article are the presteps until the article was created. A naive assumption is, that an article is created by smaller edits. But this definition hides the fact, that the individual authors are using their local harddrive to prepare the edits. The prepation steps on the local harddrive is never uploaded to Wikipedia, therefor its much harder for the newbies to reproduce the steps for creating articles by their own.

The interesting point is, that in the normal tutorials about creating academic text the prestep of notetaking is described in detail. Nearly 100% of the manuals in which the process of creating academic presentations and academic papers is described, the user is asked to create first the keypoints and then formulate the prose text. It's not very difficult to transfer this tutorial for creating Wikipedia articles. The reason why this is not made in existing Wikipedia tutorials is, because the average long term Wikipedia author is already familiar with academic note taking. For the Wikipedia expert there is no need to talk about creating notes, because this step is assumed. This untold assumption makes it harder for newbies to do the same what Wikipedia experts are doing. What the newbies are doing is not making notes, but they think its possible to create on the fly edits.

Let us describe the imaginary on-the-fly edit in detail. On the fly means, that an edit can't be divided into substeps. Somebody reads a fact in a book, and adds this fact to Wikipedia by submitting an edit. This workflow is described in existing Wikipedia edits. The problem is, that in the reality it won't work. Especially not for newbies. The reason is, that the subjects are too complicated, the quality standards in Wikipedia are too high and the newbie isn't familiar with academic writing. The result is that an on-the-fly edit will become a reason why the newbie get banned.

Two step edit pipeline

The recommended edit workflow is much easier to master. Creating keypoints from existing academic papers is not very complicated. The user has to write down important facts and he makes a note from which paper the information comes from. Training this behavior is not very advanced. The second step in the overall pipeline is also easy to master. Taking existing keypoints and convert them into prose text is something which has to do with academic writing. The facts and the literature are given in advance and what the user has to do is formulate the facts in an easy to read paragraph.

The interesting point is, that after combining both steps the result is a high quality Wikipedia edit, which is accepted by the admins. A win win situation means, that such an edit make sense for the newbie and the admins at the same time. The newbie is proud because he has edited in the Wikipedia, while the admin is happy, because existing articles were updated.

A good starting exercise for Wikipedia newbies is to focus only on making notes. The task is, to take 10 existing articles and post keypoints to the talk page. That means, the newbie isn't creating real edits, but he is posting only keypoints to the talk page. The most interesting effect is, that none of these keypoints gets deleted from the talk page. Because the talk page is the perfect place for storing the preparation notes.

Understanding the concept of Longterm releases

In the Open source software development model there are long term stable versions available. For example Firefox ESR, Debian stable, Ubuntu LTS and Linux kernel LTS. What most users doesn't know is what the difference is to the normal version. In most cases, the long term version is older which means, it is not the latest update but its outdated. If the aim is to update the system to the latest sourcecode, LTS versions doesn't make much sense. On the other hand, Firefox ESR and Linux LTS are available as an option so why are LTS versions are available if they are a poor choice?

To understand the situation we have to take a look into closed source software development. All the commercial software is published in long term version. The Windows XP Operating system is available only in the LTS version, the same is true for Windows 10, Mac OS X and so on. The most obvious difference between a rolling release and a long term release version is, that in the LTS version some components are missing. That means, the Firefox ESR browser is a feature reduced version of the latest Firefox browser. If the normal Firefox software has a menu with 10 menupoints, the ESR version is equipped only with 8.

The decision pro or against a LTS version has to do with the missing features. Its the difference between 8 menupoints and 10 menupoints. From the development perspective the interesting question is, why are the missing 2 menupoints not available in the LTS version? It has to do with stability. Improving a software with additional features needs a lot of work. If the manpower in terms of programmers is small, it will take some time until the missing 2 menupoints are added.

All long term versions have in common that with a time delay all the missing features are added. If the endusers waits a bit, the imaginary Firefox ESR version will have 10 menupoints too. The only question is how long does it take. In most projects, the time gap is 1-2 years. That means, the developers have programmed all the 10 menupoints already, but they are only available in the trunk branch but not in the production version. If a software contains of a long term version plus a trunk version at the same time it's a positive situation. It means, that the development team is improving the software and another team is testing the changes for stability and security. On the other hand, if a software project contains only of a trunk branch and doesn't offer a LTS version it's a toy project. That means, the software is programmed just for fun but isn't used in reality.

Let us analyze this hypothesis in detail. Suppose a development team is trying to improve the security, the stability and the amount of features in a software. The only way in doing so is by creating additional branches. One feature branch, one security branch, one stable branch and so on. After these branches are created a time lag is the result. That means, the security team will analyze version 1 of the software, but the feature team is implementing version 2 of the software. The security team is testing something different from the development team.

Let us imagine, the software project contains of a single branch which is called trunk. It is not possible to establiish a quality control on a single branch development model. The reason is, that all the latest updates are commited into the trunk branch and it makes no sense to ask if a certain version is secure. Because the version is changing twice a day. The result is, that a trunk-only repository isn't tested for stability nor security. Instead it's the development version which isn't recommneded for productive usage.

Let us investigate why some software projects have no long term version. The reason is, that the software developers want to minimize their effort. Its a one man team or a two man team which is programming the sourcecode. No quality control is available. Such a software development cycle isn't used for commercial software. Because most customer are paying money for the software and in return they are expecting a high quality. Only open source developers are bold enough to publish the trunk version of the software.

Point releases
Software development consists of two conflicting roles. The end user of a software likes to install the program on the PC, needs a documentation, and is interested in a bug free system. The needs of the software developers are the opposite. A software developer likes to modify the code twice a day, he is testing out new modules and he doesn't like to waste his time in writing a documentation.

Two conflicting roles means, that if the end user is happy, the developer isn't and vice versa. It's only possible that one social role in the game wins. The reason why long term versions were invented is to fulfill both needs at the same time. Let us first describe the end users perspective. The end users is downloading the LTS version of the software. This version is bug free, is well documented and runs out of the box.

From the developer perspective the LTS version is useless. The developer has no need for a documenttation because he has written the sourcecode himself, and he has no need that the software can be installed easily, because he compiles the sourcecode from scratch. What the developer is prefering is a trunk branch in which new commits can be applied. Because of the different needs, there are two versions of the same software available. The LTS version which is adressed to the enduser, and the trunk version which is the playground for the developers. Between both versions, there is a time lag. That means, they are out of sync. This allows that both social roles are happy at the same time.