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.
June 11, 2021
April 27, 2020
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.
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.
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.
April 25, 2020
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.
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.
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.
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.
April 24, 2020
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.
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.
Switching to Debian isn't easy
After experimenting with the Debian 10 operating system in a qemu enviornment, i have decided to install the software on a physcial machine. Unfurtunately, the installation menu was a bit complicated. First thing to mentioned was, that the touchpad wasn't recognized, so all the settings has to be made with the keyboard only.
Second problem was that after the first boot up the display resolution was wrong. Only a vesa mode was shown which was below the normal resolution. After experimenting with different grub settings (none of them are working) the answer was hidden in the debian wiki https://wiki.debian.org/AtiHowTo What the user has to do is to install a non-free AMD graphics driver. After the next bootup the normal display resolution is shown.
It's unclear how other Linux distribution are handling the situation. Perhaps they are installing in the background the non-free package and doesn't ask back. So nice, the resolution is now improved.
One thing which isn't working yet in debian is the edge scroll of the touchpad. It seems that with the new wayland display manager the settings aren't recognized. Perhaps it's possible to find a workaround or in the worst case the touchpad is working below their optimal quality.
Let us describe a unique feature of debian which has to do with installing outdated software. The standard webbrowser in Debian 10 is Firefox 68.7 ESR. In contrast to the normal Firefox software, this version was released in 2019 and then it was improved slightly. So what is the difference? The interesting situation is, that for most users the ESR version makes more sense. The story told in the version history looks predicatable. That means, a year ago the software was programmed, and then it was improved by security updates.
Now it is possible to compare this story with the trunk branch of Firefox and Chrome. In the trunk branch the story is, that the user has to check twice a week for an update, and if an improvement is available he has to install the latest version of Chrome within 24 hours, otherwise the system becomes vulnarable to attacks. Or let me tell the story a bit different. Suppose a user has installed the latest Chrome browser and hasn't updated the software since a week. From the perspective of the Chrome development team, the user has made something wrong. He was adviced to check for updates twice a week, he wasn't doing so, and as a result the user has made mistake.
Rolling release webbrowser are blaming the user if the system becomes vulnarable. In contrast, Longterm versions like Firefox ESR are blaming the upstream. That means, if something with the Firefox 68 ESR is wrong it's up to mozilla to fix the issue. And if Mozilla isn't able to fix the problem, the next question is why does a certain compoenent was introduced in the ESR version which needs so frequenetly an update?
Touchpad in XFCE4
After playing around with a different display manager the problem with the edge scrolling has been solved. In XFCE4 the touchpad can be configured differently than in gnome. Which allows to even scroll the content on the screen with the touchpad itself.
Second problem was that after the first boot up the display resolution was wrong. Only a vesa mode was shown which was below the normal resolution. After experimenting with different grub settings (none of them are working) the answer was hidden in the debian wiki https://wiki.debian.org/AtiHowTo What the user has to do is to install a non-free AMD graphics driver. After the next bootup the normal display resolution is shown.
It's unclear how other Linux distribution are handling the situation. Perhaps they are installing in the background the non-free package and doesn't ask back. So nice, the resolution is now improved.
One thing which isn't working yet in debian is the edge scroll of the touchpad. It seems that with the new wayland display manager the settings aren't recognized. Perhaps it's possible to find a workaround or in the worst case the touchpad is working below their optimal quality.
Let us describe a unique feature of debian which has to do with installing outdated software. The standard webbrowser in Debian 10 is Firefox 68.7 ESR. In contrast to the normal Firefox software, this version was released in 2019 and then it was improved slightly. So what is the difference? The interesting situation is, that for most users the ESR version makes more sense. The story told in the version history looks predicatable. That means, a year ago the software was programmed, and then it was improved by security updates.
Now it is possible to compare this story with the trunk branch of Firefox and Chrome. In the trunk branch the story is, that the user has to check twice a week for an update, and if an improvement is available he has to install the latest version of Chrome within 24 hours, otherwise the system becomes vulnarable to attacks. Or let me tell the story a bit different. Suppose a user has installed the latest Chrome browser and hasn't updated the software since a week. From the perspective of the Chrome development team, the user has made something wrong. He was adviced to check for updates twice a week, he wasn't doing so, and as a result the user has made mistake.
Rolling release webbrowser are blaming the user if the system becomes vulnarable. In contrast, Longterm versions like Firefox ESR are blaming the upstream. That means, if something with the Firefox 68 ESR is wrong it's up to mozilla to fix the issue. And if Mozilla isn't able to fix the problem, the next question is why does a certain compoenent was introduced in the ESR version which needs so frequenetly an update?
Touchpad in XFCE4
After playing around with a different display manager the problem with the edge scrolling has been solved. In XFCE4 the touchpad can be configured differently than in gnome. Which allows to even scroll the content on the screen with the touchpad itself.
Subscribe to:
Posts (Atom)