OSkit ausprobiert

Das OSkit ist laut Selbstdefinition ein Betriebssystembaukasten. Die Dateien liegen auf https://github.com/dzavalishin/oskit zum Download bereit. Es handelt sich um eine 17 MB große Zip-Datei. Die beiden größten Ordner darin sind linux/ und freebsd/ in denen sich „.c“ Dateien befinden. Vermutlich dieselben die auch in den orginalen Projekten verwendet wurden. Insgesamt besteht oskit aus sehr vielen „.c“ Dateien. Es bleibt die Frage zu klären was sich damit anfangen lässt. Leider gar nichts. oskit ist ähnlich wie MACH Kernel ein Beispiel für ein abgebrochenes verwaistes Softwareprojekt. Die Idee war es, ein Betriebssystem zu entwickeln. Es wurde aber nicht weitergeführt. Das Problem bei oskit ist, dass es als Betriebssystembaukasten konzipiert ist. Zugrunde liegt eine Vorstellung dass man Software möglichst als Library schreiben solle um so die Wiederverwendbarkeit zu ermöglichen. Nur, in der Praxis gibt es zwischen einer Library und einem normalen Programm keinen Unterschied. Eine Library ist einfach C-Code den man woanders included. Es ist der selbe C Code den man auch standalone ausführen kann. Wenn man ein Betriebssystem schreiben will, dann sollte man auf den Meta-Gedanken verzichten und einfach nur das Programm schreiben. Wenn es einen bestimmten Codeumfang übersteigt wird es automatisch zu einer Library, indem Sinne dass es dann nützlich wird und der Code auch woanders genutzt werden kann.

Das Problem mit oskit ist nicht so sehr das Konzept dahinter, oder die Programmiersprache C sondern das Problem ist die fehlende Community. Das also keine Firma dahintersteht welche den Code weiterentwickelt so wie das bei Linux passiert. Wieder einmal mehr wird deutlich dass es eben nicht um systemnahe Programmierung oder um die Programmiersprache C geht sondern um Entwicklerteams. Also dass man Software wie Microsoft gegen Geld verkauft und in dem Unternehmen dann Human-Kapital bündelt was die Software schreibt.

Advertisements

Magische Grenze von 10 Lines of Code im Linux Kernel

https://www.heise.de/ct/artikel/Die-Neuerungen-von-Linux-4-14-3831941.html
Das Buch „The Mythical Man-Month“ genießt unter Programmierern Kultstatus. Es enthält viel wares und zum ersten Mal wurde dort die Größe „Lines of Code“ diskutiert. Das Fazit lautete damals, dass ein durchschnittlicher Programmierer rund 10 Lines of Code am Tag schreibt. Bis heute wird diese Zahl von vielen als zu niedrig angesehen und behauptet, man könnte gut 500 Codezeilen am Tag schreiben, insbesondere wenn automatische Codegeneratoren verwendet werden. In einem früheren Blogpost habe ich schon die realen Werte von Microsoft Windows untersucht wo im Schnitt die Programmierer rund 6 Zeilen Code am Tag erstellt haben. Aber auch das als effizient geltende Linux Projekt schafft es nicht oberhalb von 10 Lines of Code pro Tag zu kommen. Die aktuellen Zahlen gibt es auf https://www.developer-tech.com/news/2017/jul/05/linux-kernel-412-developers-added-795-lines-code-hour/ Danach kommen pro Tag 19093 Codezeilen hinzu, die von 1821 Developern erstellt wurden. Macht nach Adam Riese einen erstaunlich niedrigen Wert von 10,48 Lines of Code pro Kopf und Tag. Ungeachtet dessen erklimmt der Linux Kernel in jeder Version neue Hürden und kaum jemand wird behaupten, dass dort nicht effizient gearbeitet wird, oder Greg Kroah-Hartman ein Anfänger wäre, der noch nicht richtig in C programmieren kann.

Ich glaube die Verwunderung über 10 LoC/Day kommt daher, dass über Softwareentwicklung meist Leute diskutieren die an den Universitäten arbeiten und selber noch nie Software entwickelt haben. Das eingangs zitierte Buch wurde nicht von einem Akademiker geschrieben sondern von einem IBM Angestellten. Die Vorstellung man könnte am Tag 500 Lines of Code erzeugen und womöglich noch Metaprogramming mit Haskel einsetzen ist wohl eine Vorstellung die so nur an den Universitäten gelehrt wird. Man teilt sie, wenn man sich einer Gruppe zugehörig fühlt welche für sich die Deutungshoheit reklamiert und eine sehr verzerrte Sicht auf die Wirklichkeit besitzt.

Meine Prognose lautet, dass man die 10 Lines of Code natürlich wird steigern können. Aber nur sehr mäßig. Vielleicht wird sie in 5 Jahren auf 11 Lines of Code pro Tag angestiegen sein, weil besser klar ist, was ein Kernel eigentlich ist und wie man richtigen C-Code schreibt. Der eigentliche Anstieg der Produktivität basiert jedoch auf einer anderen Größe: Zahl der Entwickler. Je mehr Coder man für den Linux Kernel abstellt und die in das Projekt integriert, desto schneller steigt die absolute Zahl an Codezeilen an. Noch vor ein paar Jahren waren es nur 1000 Developer die regelmäßig commits beigesteuert haben, heute weißt die Statistik einen Wert von 1800 aus.

Der Name Greg Kroah-Hartman wurde schon erwähnt. In einem Vortrag hat er einmal gezeigt wie genau sein täglicher Arbeitsablauf aussieht. Er hat damals auf der Commandline mal auf die Schnelle neue Commits in den Master-Tree übertragen und nebenbei noch am Sourcecode herumeditiert. Die Zuschauer waren beindruckt, weil das extrem Profi-mäßig daherkam. Was in dem Vortrag leider nicht erwähnt wurde ist, dass auch die Produktität von Kroah-Hartman nicht oberhalb von 10 Lines of Code am Tag liegt. Es macht eben einen Unterschied ob man Patches die jemand anderes geschrieben hat und die bereits jemand als korrekt bezeichnet hat, in das git repository einpflegt oder ob man richtige Software from scratch schreibt. Hätte Hartman damals in seinem Vortrag Kernel Programmierung unter Live-Bedingungen gezeigt, dann wäre über die Zeitdauer des gesammten Vortrags genau eine neue Zeile hinzugekommen. 10 Stunden Arbeit täglich geteilt durch 10 Codezeilen macht 1 Zeile pro Stunde. Rein statistisch gesehen bedeutet es, dass man pro Minute ein Byte anfügt. Also sehr gemächlich die Tastatur bedient. Was Hartman wohl eher demonstriert hat war, was passiert wenn man die Produktivität von 1800 Developern zu einem ganzen kombiniert. Es also mittels git schafft, dass man am Tag nicht 10 Zeilen Code neu dazufügt sondern 10×1800=18000 Zeilen. Dort kann man tatsächlich live Zuschauen wir das Projekt immer größer wird. Die Kernel Developer bilden einen virtuellen Superprogrammierer, der ziemlich schnell auf der Tastatur ist und perfekten C-Code schreibt. Jeden Tag erweitert er den Kernel massiv.

Produktivitätstool Lyx

Der wissenschaftliche Publikationsprozess ist nicht allein deshalb so schwerfällig weil sich dort Publisher wie Elsevier zwischen Konsumenten und Produzenten befinden, sondern das Haupthinderniss beim Erzeugen und Weiterverbreiten von wissenschaftlichen Dokumenten ist ein Problem, was eigentlich als gelöst gilt: die Textverarbeitung. Also eine Software, um an einem Computer ein Dokument zu erstellen. Schaut man sich jedoch einmal die Praxis an, so ist das bis heute überhaupt nicht gelöst worden. Ja ich würde vermuten, dass hier der Hauptgrund verborgen liegt, warum die meisten Forscher keine oder wenige Dokumente veröffentlichen. Weil sie gar nicht die technischen Grundlagen geschaffen haben, um in kurzer Zeit viel Seiten Papier als PDF auszugeben.

Selbst die als fortschrittlich geltenden Informatiker verwenden üblicherweise noch LaTeX als Dokumentensystem, jedenfalls deuten die bei Arxiv hochgeladenen Dateien darauf hin. Und bei den Nicht-Informatikern sieht es noch sehr viel trauriger aus. Da wird ganz überwiegend MS-Word eingesetzt. Aber das ist nur die halbe Wahrheit. In Wirklichkeit passiert folgendes: zuerst schreibt der Professor das Dokument mit seiner 30 Jahren alten Schreibmaschine vor, so hat es zumindest Clifford Stoll mit seinen Manuskripten gemacht. Das es noch einige Kollegen gibt, die mit handschriftlichen Notizen arbeiten, erwähne ich hier lieber nicht, hochnotpeinlich das ganze. Also, gehen wir mal davon aus, dass der Professor das Manuscript mit der Maschine geschrieben hat. Dann gibt er es weiter an seinen wissenschaftlichen Mitarbeiter oder die Sekräterin, die das in ein abgabebereites Word-Dokument verwandelt und die Formatierung der Fußnoten anpasst. Der Professor wird so entlastet (glaubt er zumindest). Das MS-Word Dokument wird dann per E-Mail auf eine lange Reise zu Publisher gesendet, also zu Elsevier. Dort wiederum nutzt man jedoch kein Word, sondern entsprechend des eigenen Anspruchs setzt man auf QuarkXPress. Die Anschaffung dieses Programms ist teuer, aber es ist sein Geld wert. Man kann damit hochqualitativ hochwertiges Layout erzeugen, was so gut ist wie das von LaTeX oder sogar leicht besser. Mit QuarkXPress wiederum wird dann die eigentliche PDF Master Datei erzeugt, die dann online abrufbar ist.

Klingt dieser Workflow umständlich? Mit Sicherheit, es dauert lange, und es sind viele Leute daran beteiligt. Es ist also nicht so, dass Elsevier allein die Schuld trägt wenn es 24 Monate dauert bis ein neues Paper online geht, sondern schon davor wird viel Zeit aufgewendet für Quatsch-Tätigkeiten.

Dabei ginge es deutlich einfacher. Im Grunde muss der Professor bzw. der Autor eines Textes bei sich nur Lyx installieren, es handelt sich dabei um ein Frontend für LaTeX, was speziell auf wissenschaftliche Texte zugeschnitten ist. Mit Lyx kann man in kurzer Zeit viel Text schreiben, und ein Klick auf „export to PDF“ erzeugt die Master-PDF-Datei. Man kann sich dabei die oben beschriebenen Zwischenschritte sparen.

Schaue ich mir meine eigene Publikationsliste auf Academia.edu an, so ist diese was den Umfang betrifft beachtlich. Mit MS-Word oder LaTeX wäre es nicht möglich gewesen in kurzer Zeit soviel Text zu erzeugen. Das war allein der Verdienst von Lyx. Das interessante ist, dass selbst Informatiker dieses nützliche Programm nicht kennen. Es gibt nur wenige Anleitungen dazu. Stattdessen setzt man entweder auf Word oder alternative auf LateX oder Quarkxpress. Das ganze hat häufig historische Gründe, MS-Word setzen die Leute ein, weil sie Windows auf ihren Desktops vorinstalliert haben und glauben, das wäre geeignet um damit wissenschaftliche Texte zu verfassen. LaTeX hingegen setzen die Leute ein, weil sie glauben, dass TeX unübertroffen gute Layout-Qualitäten besitzt, was stimmen mag, aber leider ist TeX sehr umständlich in der Bedienung. Komischerweise gibt es im Internet dutzende Anleitungen wo man mit VIM oder mit Texnic-Center seine Diplom- oder Hausarbeit formatieren soll, was technisch möglich ist, aber komplette Zeitverschwendung darstellt. Lyx hingegen wird fast schon demonstrativ gemieden. Langjährige TeX User haben da ein böses Gefühl, als ob der Code der von Lyx erzeugt wird, nicht sauber wäre. In der Praxis hat Lyx noch nie Probleme gemacht, bis auf die hacklige Einbidung von bibtex-Datei läuft die Software sauber durch und ist insbesondere für Veröffentlichungen mit 400 Seiten und mehr unübertroffen.

Der Clou von Lyx besteht darin, dass es eine Reihe von möglichen Stolpersteinen schon im Ansatz entfernt. So ist es standardmäßig möglich, Bilder wie SVG, PNG und JPEG einzubinden, es gibt einen eingebauten Tabelleneditor und sogar Sourcecode lässt sich mit wenigen Mausklicks platzieren. Über den Daumen gepeilt würde ich mal schätzen, dass man mit Lyx die Produktivität von Autoren mindestens verdoppelt kann oder sogar mehr. Wenn der nächste Nobelpreis tatsächlich an den Gründer von ResearchGate gehen sollte, weil er die Wissenschaft nach vorne gebracht hat, sollte er geteilt werden mit dem Programmierer von Lyx. ResearchGate alleine ist nutzlos, weil man das PDF Paper ja irgendwomit schreiben muss.

Heise Online sieht Debian im Enterprise Bereich positioniert

Wie Heise Online herausgefunden hat wird Debian Linux im Business Bereich eingesetzt:

„In vielen Unternehmen kommt Debian sowohl auf dem Server als auch dem Desktop zum Einsatz.“ https://www.heise.de/ix/meldung/Linux-Distributionen-im-Vergleich-Debian-9-oder-Devuan-3788018.html

Quellen für diese kühne Behauptung werden keine geliefert. Der tatsächliche Marketshare von Debian Linux im Enterprise Segment dürfte bei 0% liegen. Hier https://www.quora.com/What-is-the-market-share-in-percentage-for-enterprise-linux-distributions-Mainly-Redhat-Suse-and-Ubuntu mal eine halbwegs seriöse Auflistung. Danach hat RHEL einen Marktanteil von 60%, Suse 20%, Oracle Linux 12% und der Rest liegt bei 8%.

Heldenverehrung bei Pro-Linux

https://www.pro-linux.de/news/1/24986/ubuntu-1710-artful-aardvark-alpha-2-erschienen.html berichtet geradezu euphorisch von den Entwicklungen in der Ubuntu Community. Die Sprache bezeugt die uneingeschränkte Huldigung dem Projekt gegenüber. Vokabeln werden verwendet wie:

– stabile Ausgabe
– Standard-Browser
– Image ist verfügbar
– Mate-TEAM
– voll funktionsfähiges Global-Menü
– wurde überarbeitet
– Abbildung steht zum Download bereit
– stabile Veröffentlichung aller Varianten

Der Bericht von Pro-Linux erinnert an den Kommentar zu einem Fußballspiel wo die Mannschaft hervorragende und übermenschliche Arbeit geleistet hat und man wahrhaft stolz ist, darüber berichten zu dürfen. Die Realität ist leider eine andere. Nicht nur, dass die Ubuntu Distribution ungepatchte Sicherheitslücken enthält https://people.canonical.com/~ubuntu-security/cve/ sondern darüber hinaus befindet man sich auch auf Konfrontationskurs zum Upstream, hat selbst kein einziges OpenSource Projekt am Start und die oben erwähnte Programme wie Linux-Kernel, Libreoffice und Gnome sind keineswegs von Canonical entwickelt worden, sondern wurden von festangestellten Red Hat Mitarbeitern programmiert. Kurz gesagt, die Pro Linux Redaktion jubelt dem falschen Team zu. Genauer gesagt spielt Ubuntu gar nicht mit sondern die sitzen komplett im Abseits.

Aber vielleicht was das ja nur ein Versehen, und es wurde einfach nur etwas mißverständlich formuliert? Wohl kaum, ein weiterer Artikel der sich mit Linux Mint beschäftigt ist in einem ähnlich euphorischen Duktus gehalten. Man sollte dazu wissen, dass Ubuntu Mint noch unseriöser daherkommt als das ohnehin schon fragwürde Ubuntu Projekt. Aber http://www.pro-linux.de/news/1/24896/linux-mint-182-erschienen.html lobt es dennoch in den allerhöchsten Nuancen:

– sicherer zu machen
– eine höhere Qualität zu erreichen
– stark verbessert
– laufen jetzt als separate Prozesse
– signifikante Software-Aktualisierungen

Wiederum ist das kein objektiver Bericht der dem Leser die Fakten nennt, sondern es handelt sich um „Embedded Journalism“. Es wird aus Sicht der vorgestellten Distribution berichtet, der Leser wird gefangengenommen und instrumentalisiert. Vordergründig besteht die Mission darin, Linux auf den Desktop zu bringen. Das es mit Linux Mint gerantiert nicht funktioniert ist allgemein bekannt.

Neuigkeiten aus der sogenannten Linux-Community

Wie http://www.pro-linux.de/news/1/24968/statusreport-des-debian-reproducible-builds-projekts.html berichtet gibt es Neuigkeiten aus dem Debian Projekt. Man sollte vielleicht erstmal erläutern, was Pro-linux.de überhaupt ist. Laut Selbstbeschreibung möchte man Linux fördern und berichtet regelmäßig zu Themen OpenSource und Linux. Tatsächlich gibt es jedoch nervige Pop-up Werbung zur „Microsoft Cloud“ und die Berichterstattung ist einseitig pro Debian und Anti Red Hat ausgelegt. Wer hinter dem Portal steckt ist nicht ganz offensichtlich, aber wenn Microsoft dort Werbung schaltet liegt der Verdacht nahe, dass Microsoft das Portal auch finanziert. Insofern sollte man skeptisch sein, ob die Informationen wirklich „pro linux“ sind.

Aber gehen wir mal auf den oben verlinkten Debian Status-Bericht etwas näher ein. Demzufolge geht es um reproduzierbare Debian Pakete. Genauer gesagt um die Buildinfo-Datei, welche sich in einem .deb Archiv befindet. Soweit ist das erstmal korrekt. Debian arbeitet tatsächlich an soetwas. Nur, was der Bericht auf Pro-Linux leider nicht erläutert ist, dass Debian mit seinem .deb Format ziemlich alleine dasteht, und es von keiner anderen Distribution genutzt wird. Und ganz besonders nicht von RHEL oder Fedora. Das heißt, auch das aktuelle Projekt zu verifizierbaren Builds wird Linux schwächen, die Gemeinschaft fragmentieren und ist ein aktiver Beitrag dafür, dass sich Linux niemals wird auf dem Desktop wird durchsetzen können. Mit dem Redhat Upstream sind die Arbeiten jedenfalls nicht abgestimmt. Und aller Voraussicht nach, wird auch nichts davon zu Redhat zurückfließen. Das heißt, außer den Debian Usern wird keiner davon profitieren.

Heise hat keine Ahnung von Linux

Obwohl sich das Trollheaven Blog vornehmlich als Robotik-Blog versteht lohnt es einen kleinen Blick auf themenverwandte Blogs zu wagen, allen voran Heise.de die sich auf https://www.heise.de/newsticker/meldung/Debian-9-erscheint-Stretch-saugt-sich-fest-3745108.html mit dem neuen Debian 9 beschäftigen. Dort heißt es als Fazit:

„Im c’t-Test der Entwicklungsversionen überzeugte Debian Stretch. Server- und Desktop-Upgrades von Debian Jessie oder sogar von Squeeze und Wheezy funktionierten ohne größere Probleme.“

Die Frage ist hier was die Zielstellung ist. Wenn man ein Betriebssystem benötigt um 30 Jahre alte Computer zu betreiben und extrem unsichere Server benötigt die nochnichtmal EAL4+ zertifziert sind, dann ist Debian in der Tat eine gute Wahl. Es hat bis heute nicht Systemd integriert, besitzt keinerlei Security-Policy und ist eine Art von Schonraum um zu lernen wie man Linux macht. Für die Praxis auf echten Desktops oder auf echten Servern dürfte Debian so ungefähr der schlimmste Albtraum sein. Es ist eine Zombie Distribution die schon längst tod ist.

Was hat die Heise Redaktion geritten so einen Pro Debian Artikel zu schreiben? Wäre es nicht an der Zeit seinen Lesern einfühlsam beizubringen, dass sie umsteigen sollten auf „Rell 7“? http://www.pediaphon.org/~bischoff/radiopedia/mp3/9476839279095.mp3