Bug: Lyx makes trouble again

http://www.lyx.org/trac/wiki/BugTrackerHome

After the last month, the Lyx software for authoring ebooks had shown serious problems. After editing a bit in a text, the screen freezes. This problem occurred only sometime, but the View mechanism for preview a pdf-paper is completely broken. Round about every 20th execution the screen freezes after pressing the button. And it depends not only on the pdflatex engine, but also the xelatex engine makes trouble. So my conclusion is, that inside the Lyx program at all is something really wrong.

In most cases the freeze is recognized after 2 minutes from the operating system and the system is killed hard via the dialog-box of Fedora. If the document was saved correctly depends on random. In 90% of the cases it was saved before, but i had also some cases in which after open the paper again, my text was lost. So if somebody has a time-critical workflow with important documents like a phd-thesis i can no longer recommend the software. Instead the better option would be MS-Word which is very stable and runs under all operating systems.

Advertisements

Bug: zuwenig Paranoia in OpenSource Filmen

Wikipedia hält eine Liste mit OpenSource Movies bereit https://en.wikipedia.org/wiki/List_of_open-source_films Darunter werden Filme subsummiert welche sich ähnlich wie Linux unter einer GPL artigen Lizenz verbreitet werden. Die Liste ist sehr kurz und wenn man einige der Filme die ab 2002 erschienen sind anschaut so macht bereits der Trailer wenig Lust sich den ganzen Film reinzuziehen. Anders formuliert, die Filme sind grottenschlecht. Das einzig positive ist noch die freie Lizenz, aber die bräuchte es eigentlich weil diese Filme garantiert kein Publikum finden werden.

Aber wieso gelang mit dem großen Vorbild Linux es eine OpenSource Software zu entwickeln die nützlich ist, das selbe Konzept jedoch bei der Filmproduktion scheitert? Kann man generell mit wenig Budget keine guten Filme machen? Meiner Analyse nach fehlt den Filmen vor allem eines: Paranoia. Damit ist gemeint, dass vor dem eigentlichen Dreh ein gutes Drehbuch nötig ist und um das spannend zu schreiben müssen die Protoganisten etwas zu verlieren haben und dann hilflos mitansehen wie sie nichts dagegen tun können. Das ist das wichtigste Rezept was in traditionellen Kinofilmen eingesetzt wird. Leider nicht so bei OpenSource Produktionen.

Warum Paranoiade Filme beim Zuschauer besser ankommen als belanglose Filme hat damit zu tun wie Menschen funktionieren, es hat also etwas mit den Rezipienten zu tun und wann sie einen Film als sehenswert einschätzen. Üblicherweise werden Themen als wichtig / wertvoll bezeichnet die etwas mit Gefahr, Schrecken und Bedrohung zu tun haben. Sowas zieht den Kinozuschauer in seinen Bann, er glaubt etwas zu verpassen wenn er den Film nicht zuende anschaut. Genauer gesagt möchte der Zuschauer vom Drehbuchschreiber also manipuliert werden. Er will eine Geschichte erzählt bekommen die ihn persönlich betrifft. Und genau daran mangelt es den Filmen auf der OpenSource Liste von Wikipedia. In keinem einzigen Film ist die Rede davon, dass gleich die Welt untergeht.

Aber technisch wäre es durchauus möglich solche Filme zu produzieren, wohlgemerkt das Geheimnis liegt weniger im Budget, in den Schauspielern oder in der FullHD Kamera, sondern man muss das richtige Drehbuch haben.

Testbericht Torcs

Um den Programmieraufwand zu minimieren soll man ja auf bestehende Software zurückgreifen. Nun gut habe ihc mir gesagt, lasse ich meine eigene Trafficsimulation einfach unberücksichtigt und installiere ich mir lieber die Standard-Software TORCS. Wikipedia ist voll des Lobes und es gibt unendlich viele Paper dazu. Und oh Wunder, seit 2008 finden sogar jährliche Meisterschaften statt, wo Teams mit selbstprogrammierten AI Bots gegeneinander antreten. Genau mein Fall. Nur was ist das? Nachdem der Fedora Paketmanager die stolze 400 MB auf meine Festplatte beförderte und ich in den Settings erstmal die richtige Auflösung eingestellt hat, fängt nach ca. 30 Sekunden mein Lüfter in den Dauerbetrieb zu schalten. Das geht auch nicht weg, wenn man die Texturenanzahl reduziert und ein wenig mit den Options herumspielt. Woran das liegt ist unklar, offenbar bin ich der einzige mit derlei Problemen. Wenn aber noch nichtmal das manuelle Fahren im Simulator funktioniert wie soll es erst werden, wenn ich versuche einen Bot zu schreiben der 24/7 die Runden abfährt? Nein, Torcs war keine gute Idee und auf die zahlreichen Ableger wie Speed-Dreams, vdrift habe ich auch keine Lust mehr. Letzteres würde lauf der Prognose des Paketmanagers bereits 1,3 GB auf der Festplatte beanspruchen, und weil dort die Grafik noch weiter verbessert wurde, ist anzunehmen dass meine CPU vollends kapituliert.

Grundsätzlich stehe ich dem Ansatz von Torcs positiv gegenüber, auch die verwendete Programmiersprache C++ erhält meinen Beifall. Aber ich glaube ich werde vorerst doch bei meiner selbstprogrammierten Trafficsimulation verbleiben. Die war schön als 2D Topdown realisiert und hat die CPU exakt mit 0% belastet. Das Problem ist folgendes: wenn nochnichtmal die Spiele-Umgebung Torcs Sinn macht, dann gibt es im Grunde keine C++ Bibliothek die man installieren kann. Weil irgendwelche Standard-Software zu Botprogrammierung gibt es unter C++ nicht. Im Grunde ist das einzige worauf man aufbauen kann noch SFML in Verbindung mit Box2D. Damit ein Spiel hinzubekommen ist noch der leichte Part. Schwerer wird es, wenn es an die Botprogrammierung geht. Gerne würde ich an dieser Stelle ein Loblied singen auf Bibliotheken die schon existieren und die man nur bei sich installieren muss, doch wie gesagt scheint es sowas nicht zu geben. Und auch die vorhandenen Bots die für Torcs geschrieben wurden und die bei github gehostet sind, machen vorsichtig ausgedrückt einen unfertigen Eindruck. Mehr als 500 Lines of Code hat keiner der Teams in Stellung gebracht.

Anders ausgedrückt, die Thematik ist noch komplett unerschlossenes Gelände, da funktioniert noch überhaupt gar nichts. Mit nur wenig Programmier-Aufwand kann man richtig viel erreichen.

Flaschenhals Softwareerstellung

Robotik Projekte scheitern selten an theoretischen oder mathematischen Schwierigkeiten. Man muss also keine Theorie von Künstlicher Intelligenz besitzen um mit dem Programmieren zu beginnen. Ganz im Gegenteil, das Adhoc Vorgehensmodell bei dem man einfach mal einige Behavior Trees implementiert ist ausgezeichnet geeignet um Bottom-up Prototypen zu entwickeln. Nein der Flaschenhals liegt woanders. Und zwar ist es nicht möglich Autoprogrammierung anzuwenden. Damit ist gemeint, dass ein Codegenerator der anschließend weiteren Code erzeugt technisch nicht machbar ist. Die Alternative dazu lautet, dass die Programimerung eines Roboters vollständig von menschlichen Programmierern abhängig ist. Mag ein autonomes Robotersystem was eigenständige Entscheidungen trifft das Ziel sein (technisch ist es sogar möglich), aber der Weg hin zur Realisierung geht nur über händisches Programmieren.

Ich habe mir mal einige Softwaregroßprojekte sowohl aus dem Bereich Robotik als auch in der klassischen Betriebssystementwicklung näher angeschaut und bin zu der Erkenntnis gelangt, dass die Produktivität niemals höher liegt als 10 Zeilen Code pro Tag und Mann. Will man also die Software für ein Selbstfahrendes Auto, einen Pick&Place Roboter, für eine Drone oder für einen Küchenroboter programmieren muss man im Schritt 1 grob schätzen wieviel Codezeilen erforderlich sind. Minimum für ein selbstfahrendes Auto sind 1 Mio Lines of Code, in der Praxis haben die meisten Systeme sehr viel mehr Codezeilen. Umgerechnet sind das nicht mehr als 40 MB Sourcecode, das ist weniger als der Linux Kernel benötigt. Im Schritt 2 berechnet man jetzt die benötigten Mannjahre, wenn alles glatt läuft. Obiges Beispielprojekt würde 274 Mannjahre benötigen, bis die Software fertig programmiert ist. Wenn man als Einzelperson sich daran macht wird das Projekt scheitern und wenn man es im Team macht besteht die Gefahr dass sich das Team streitet oder die Finanzierung nicht sichergestellt ist. Und genau liegt die eigentliche Schwierigkeit bei der Realisierung von Robotik, und zwar geht es um die Frage ob man Softwaregroßprojekte mit mehr als 1 Mio Codezeilen durchführen kann. Also ob man prinzipiell das nötige Fachwissen hat und eine geeignete Projektstruktur.

Die spannende Frage lautet jetzt wie man verhindern kann solche Großprojekte anstoßen zu müssen. Deutlich einfacher zu realisieren sind kleine Softwareprojekte, wo also in wenigen Codezeilen eine sehr überschaubare Funktion realisiert wird die von einem sehr kleinen Team umgesetzt wird. Ein erster Ansatz in diese Richtung ist die Verwendung von Simulationen. Anstatt einen echten Roboter zu programmieren wie das bei Robocup Wettbewerben gemacht wird, sollte man sich auf ein Teilgebiet fokussieren, also das Programmieren eines Controllers in einer 3D Welt. Dafür ist der Programmieraufwand deutlich reduziert. Man kann sich die meisten Vision-Komponenten sparen und legt den Fokus stattdessen auf kognitive Agenten. Solche Systeme sind praktisch gesehen zwar nutzlos, weil man damit nicht wirklich Fußball spielen kann, dafür jedoch ist der Erstellungsaufwand niedriger und die Möglichkeit des Erfolgs ist vorhanden.

Einerseits steigt die Anzahl von benötigten Codezeilen in realen Projekten an, gleichzeitig passiert in der öffentlichen Wahrnehmung eine Verschiebung hin zu nicht-programmier-Ansätzen wie DeepLearning. Deeplearning ist eine Technologie die vorwiegend auf leistungsfähige Grafikkarten setzt um mittels Numbercrunching automatisch Software zu erzeugen. Man braucht nur ein sehr kompaktes Framework wie Caffee und kann damit Robotersoftware synthetesieren — so zumindest das Versprechen. Natürlich funktioniert DeepLearning in der Praxis nicht und das wissen die Beteiligten nur zu genau. Echte Software besteht zwingend aus vielen Codezeilen. Aber genau deshalb ist DeepLearning ja so attraktiv: man schreibt einfach ein 10 Zeilen Script in Python worin man Beispieldaten auswertet und nur Sekunden später ist dann der Roboter-Controller von dem neuronalen Netz erzeugt worden.

Eine interessante Mischung aus klassischer objektorientierter Softwareentwicklung und neuartigen DeepLearning Verfahren stellt „ontology based deeplearning“ da. Es ist der Versuch, einerseits Ontologien und Objektmodelle zu verwenden, gleichzeitig aber ohne selbstgeschriebenen Code auszukommen.

Dazu ein kleiner Exkurs: normalerweise werden Softwareprojekte mittels objektorientierter Programmierung ausgeführt. Die Entwickler programmieren Klassen, legen Vererbungen fest und implementieren Methoden. Die objektorientierte Programmierung ist ein Hilfsmittel zur Domainmodellierung: die Umwelt wird in Software nachgebaut. Wie eingangs schon erwähnt ist die Durchführung solcher Projekte zeitaufwendig. Bei DeepLearning hingegen wird überhaupt kein Sourcecode erstellt, es werden auch keine Klassen definiert, sondern DeepLearning bedeutet, dass man sich ein Optimierungsproblem überlegt und dieses als Reward Funktion in 2 Zeilen Python Code niederlegt. Jetzt startet man das DeepLearning Framework auf einem GPU Cluster und die Software optimiert sich dann von allein. DeepLearning kann man als Quatsch bezeichnen, es ist komplett unwissenschaftlich und gleicht mehr Hokuspokus als seriöser Softwareerstellung. Es besitzt aber einen großen Vorteil: DeepLearning Softwareprojekte sind extrem billig. Eigentlich reicht es die Hardware anzuschaffen, weil groß programmiert werden braucht da nichts. Da ist der Grund warum es aktuell bei Google Scholar geschätzt mehrere Tausend Paper gibt, in denen DeepLearning in allen möglichen Facetten dargestellt wird. Solche Projekte durchzuführen ist unglaublich billig. Irgendwelche konkrete ausführbare Software gibt es zwar keine, aber dafür ist es interessant sich damit zu beschäftigen.

Warum eigentlich nicht Python?

Python steht nach wie vor ein wenig im Abseits. So richtig konkurrenzfähig mit Java und C# ist es nicht. Aber warum eigentlich? Vermutlich deshalb weil Python als Scriptsprache entworfen wurde, und die dazugehörige Runtime Umgebung erst später erfunden wurde. Anders als bei Java und C# gab es zum Start von Python also noch keine einheitliche Plattform wo man Python Scripte ausführen konnte und wo auch Zusatzbibliotheken vorhanden waren. Aber inzwischen gibt es Bestrebungen hier aufzuholen. Das pypy Projekt ist zu nennen aber auch die Google App Runtime Umgebung für Python ist zu nennen. Auch pyrun geht in diese Richtung, es handelt sich um eine 12 MB Große Datei die Python Scripte ausführen kann und wo wichtige Bibliotheken schon enthalten sind. Generell dürfte an dieser Stelle über die Zukunft von Python entschieden werden. Ob es gelingt neben der Sprache als solche noch eine leistungsfähige Runtime Umgebung zu entwickeln.

Aktuell sieht es hier leider nicht so gut aus. Anders als Java gilt Python als sehr langsam. Und anders als bei C# gibt es auch keine guten Standard-Bibliotheken um Spiele zu entwickeln. Man kann Unity3d zwar in Python programieren aber nur als Zusatz, nicht so wie in C#. Zwischen Python und C# gibt es aber auch gemeinsamkeiten. Beides sind objektorientierte interpretierte Sprachen. Das heißt, der Code wird nicht zu Assembler Opcodes kompiliert, sondern er wird von einem Zusatzlayer ausgeführt, der voriinstalliert ist. Die Mächtigkeit dieses Konzepts kann man gar nicht hoch genug einschätzen, im Grunde ist das nichts geringeres als die Weiterentwicklung von objektorientierter Programmierung. Zur Erinnerung: eine Sprache wie C++ ist bereits mächtig, aber wenn man sie zusätzlich noch Sandboxed und daraus C# macht wird es interessant. Der Vorteil ist, dass dadurch die Entwicklungkosten sinken. Einmal für die Programmierer des C# Codes, weil sie relativ unkompliziert ein Minispiel entwickeln können, aber auch für die Entwickler der Compiler weil sie leichter die Sprache auf andere Betriebssyteme und andere Prozessoren übertragen können.

Schaut man sich hingegen einmal das LLVM Projekt an, so ist das nicht besonders offen. Dort wird die Programmiersprache eng mit dem Compilerprojekt verknüpft.

Commandline issue tracker

Ein git commit ist eine Veränderung am Sourcecode, aber dazu passend benötigt man noch einen Issuetracker. Die vorhandenen Systeme sind zu kompliziert, erinnert sei an Trac und ähnliche Programme. Bei github gibt es ein integriertes Issue-Tracking System wo man in ein Issue sogar einen Link zum git sha commit anfügen kann. Aber, github ist eine Webplattform.

Jetzt wurde ein Projekt vorgestellt, was sich lokal installieren lässt, es heißt https://github.com/dspinellis/gi und stellt einen neuen Befehl namens „gi“ zur Verfügung. Im Grunde wird die Funktionalität von git kopiert nur nicht zur Sourcecodeverwaltung sondern um Issues anzulegen. Diese bestehen aus Text-Snippets welche einen Status haben (open,close,usw). Das Konzept macht Sinn und überschneidet sich teilweise wie git funktioniert. Zur Erläuterung: wer die Atlassian Hilfeseite studiert hat wird auf eine Bestpractice Methode gestoßen sein. Danach soll man für jeden neuen Issue einen neuen Branch anlegen. Das heißt, man zweckentfremded git als Issue Tracker. Aber, das bildet nicht die echten Abläufe ab. Üblicherweise sind Sourcecode-Control und Issuetracker zwei unterschiedliche Dinge, und sollen es auch bleiben. Weil, mal angenommen man erstellt 3 neue Issues (Task1, Task2, Task3). Und stellt die alle auf open. Will man jetzt dafür drei komplett neue Branches erzeugen, selbst wenn sich herausstellt, dass Task2, und Task3 sich ohnehin erledigt haben? Nein, natürlich nicht. .Sondern in der Praxis wird man im Issue Tracker lediglich auf die git SHA Checksumme verlinken, aber beide Systeme schön getrennt halten. Und genau dafür eignet sich gi sehr gut.

Nach einer kurzen Analyse handelt es sich um 600 Lines of Code welche als Shellscript geschrieben wurde. Nicht die beste Programmiersprache aber als Proof of concept akzeptabel. Ich werde das tool mal einer näheren Betrachtung unterziehen. Vielleicht ist es ja nützlich.

UPDATE
Inzwischen habe ich das Tool einem näheren Test unterzogen. Rein technisch gesehen funktioniert es. Die versprochene Funktionalität besteht. Man kann schön über die Commandline Tickets erstellen. Es gibt jedoch ein Problem, es macht keinen Sinn. Herkömmliche überdimensionerte Issue-Tracker wie Trac sind deshalb so mächtig, weil sie im Intranet als Diskussionsforum genutzt werden, wo also mehrere Leute Kommentare abgeben. Sie erfüllen demnach eine soziale Funktion. Das ist bei gi nicht gegeben, weil man es lokal auf der Festplatte installiert. Bleibt noch die Frage ob man es nicht auch im Single-User Betrieb effektiv nutzen kann. Seine Funktionsweise ist vergleichbar mit git. Es gibt zu jedem Issue einen SHA256 Hash und man kann sich ein Logfile anzeigen lassen. Das Problem ist, dass es keine eigentliche Commits gibt. Das heißt, anders als bei git passiert nach dem Anlegen eines Issues gar nichts, weil im Hintergrund ja nicht eine Kopie des Sourcecode erzeugt wird sondern der Issue-Tracker läuft für sich. Diese Funktionalität kann man mit einer simplen Textdatei „issues.txt“ leichter erreichen. Wenn man diese unter Versionsverwaltung stellt kann man auch dessen wachsen mitverfolgen. Ja ich würde sogar sagen, dass diese Textdatei gar nicht mal unter Versionsverwaltung gestellt werden muss sondern in einem lokalen Direktory gepflegt werden kann.

Ein dezidierter Issuetracker wie gi macht keinen Sinn weil dessen Benutzung aufwendig ist. Man muss sich mehrere KOmmandos merken. Und der Mehrwert der sich ergibt ist minimal. Im Grunde verwaltet man damit nur eine to do Liste. In der Summe halte ich das Tool für entbehrlich.

OpenSource und das Versprechen auf Herstellerunabhängigkeit

Das schöne an der mißglückten Linux-Umstellung der Stadt München „LiMux“ ist, dass der Ablauf der Geschichte gut dokumentiert ist. Es gibt zahlreiche Pressebereichte, 1 Stündige Vorträge und sehr unterschiedliche Perspektiven auf die Ereignisse die 2003 begonnen und damit endeten, dass München jetzt wieder Microsoft einsetzt. Viele haben darüber gerätselt was die Ursache für das Versagen war. Überwiegend hat man die IT-Abteilung als Schuldigen ausgemacht, also Leute die entweder zuviel oder zuwenig Ahnung von Linux hatten. Doch ganz so einfach ist es nicht. Meiner Meinung nach ist der Umstieg gescheitert, weil man dem Marketing-Versprechen Linux aufgessen war, das nichts mit der Realität zu tun hat.

Das Marketing-Versprechen geht ungefähr so: Der böse Microsoft Konzern zockt seine Kunden ab, weil er pro Jahr 200 EUR für eine Server Lizenz haben will, und selbst wenn man das bezahlt, muss man mit Virenangriffen rechnen und erhält nochnichtmal Einblick in den Sourcecode. Wenn man hingegen ein Linux einsetzt wie z.b. Debian ist dort nicht nur die Technik fortschrittlicher, sondern man spart auch Geld und fördert freie Software.

Das ist jenes Bild das in Linux Zeitschriften, auf den Chemnitzer Linux Tagen und auch in vielen Büchern verbreitet wird. Es ist ein sehr attraktives Bild was jedoch einen Makel hat: es ist komplett erlogen. Was Linux hingegen in Wirklichkeit ist, kann man nirgendwo nachlesen. Um Linux zu verstehen muss man sich auf Fedora fokussieren. Es handelt sich um eine Distribution von Redhat. Der Witz ist, dass Linux und Redhat ein und desselbe ist. Es gibt nicht unterschiedliche Distributionen, die von einer bunten Community mit Software bestückt werden, sondern der gesammte Linux Stack wird von Redhat Angestellten entwickelt und zu einer Distribution geschnürt. Dazu zählt der Linux Kernel selbst, das ext4 Dateisystem, die Freedesktop-Oberfläche bis hin zu LibreOffice. Hier http://community.redhat.com/home/ ist zu lesen, wo Redhat überall als Contributer tätig wird. Die Liste ist nicht vollständig, es gibt fast nichts wo Redhat nicht involviert ist. Aber es geht noch weiter. Auch die zentrale CVE Exploit Datenbank wird von einer Stiftung gepflegt wo Redhat beteiligt ist: der Mitre Corperation.

In der Außendarstellung von Linux wird das Märchen verbreitet, es gäbe von einander unabhängige Communities. Also einmal die Programmierer und dann die Distributionen. Das ist so nicht richtig. Die sogenannten Linux Distributionen wie Debian oder ArchLinux sind nichts anderes als Redhat Clone. Sie nutzen die Pakete der Redhat Entwickler, etikettieren diese um und behaupten das wäre ihr Linux. In Wahrheit ist Ubuntu, Debian und Co jedoch nicht technologiegetrieben, sondern es sind Marketing-Vorgaben von Redhat.

Diese Realität wird in den gängigen OpenSource Büchern nicht erzählt, weil sie der gewünschten Außendarstellung von Freier Software zutiefst wiederspricht. Keineswegs ist Linux das Gegenteil von Microsoft, sondern Linux ist ein verbessertes Microsoft. Was den Anwender noch mehr gängelt, wo man noch abhängiger ist von einem Konzern und wo man noch weniger Freiheiten hat. Schauen wir uns mal die Realität an, bei dem Behörden oder Unternehmen den Schritt gegangen sind weg von Microsoft hin zu Linux. Das erstaunliche daran ist, dass alle erfolgreichen Umstellungen bei Redhat endeten. Wie ein simpler Blick in das Preisverzeichnis zeigt, sind Redhat Server um einiges teurer als Microsoft Server. Rabette gibt es keine. Beispiele für andere erfolgreiche Umstellungen hin zu Ubuntu oder zu Gentoo Linux gibt es keine.

Was sagt uns das? Es sagt uns, dass man sich den Wechsel auf Linux gut überlegen sollte. Man kann ihn entweder erfolgreich durchführen, das endet damit dass man bei Redhat landet, sich in die Abhängigkeit eines Großkonzerns begibt und weitaus mehr Geld ausgibt als bei Microsoft, oder es endet wie im Fall LiMux wo man auf das Marketing-Versprechen hereinfällt und dann in der Realität erkennt, dass Linux anders funktionert als erhofft.

Die gute Nachricht im Fall von LiMux lautet, dass weder die Politiker noch die IT-Abteilung der Stadt München Schuld an dem Desaster hatte. Und zwar deswegen nicht, weil es weltweit keine andere Stadt, Unternehmen oder Behörde gibt, die auf Debian erfolgreich gewechselt ist. Das ist technisch auch gar ncht möglich. Debian existiert nur aus einem Grund: um Desinformationen zu verbreiten. Also das Märchen von der freien OpenSource Welt anzustimmen und so zu tun, als gäbe es kein Redhat, sondern als ob Linux von unahbängigen Entwicklern entwickelt wird, die irgendwo in Brasilien oder sonstwo wohnen und aus lauter Spaß an der Sache Sourcecode schreiben und Pakete pflegen.

Und LiMux ist auch nicht das letzte Projekt was scheitern wird. Auch in China fällt man auf die selben Marketing-Versprechen herein. Dort versucht der Staat auf Basis von Ubuntu die Linux Umstellung, das Projekt nennt sich „Ubuntu Kylin“. Ebenfalls mit der gleichen Intention wie in München auch: es geht darum, die Abhängigkeit von Microsoft zu reduzieren, Freie Software einzusetzen und die eigenen Kosten zu senken. Auch „Ubuntu Kylin“ muss scheitern. Wenn China wirklich auf Linux umsteigen wollte, hätten sie Redhat kontaktiert, Ubuntu Kylin hingegen ist keine Distribution, sondern es ist ein Märchen.

Um die Entstehung und die Arbeitsweise von Redhat zu verstehen ist es wichtig ins Jahr 1995 zurückzugehen. Damals gab es lediglich Microsoft welche Serverbetriebssysteme angeboten hat (Windows NT, einige werden sich erinnern). Die Frage damals war, wie Microsoft das Monopol auf Software behalten kann, wenn es irgendwann quelloffene Software gibt. Redhat war darauf die Antwort. Redhat wurde gegründet um OpenSource zu fördern, genauer gesagt um es zu kontrollieren. Die Mechanismen unterscheiden sich leicht von dem wie Microsoft gearbeitet hat. Zu Zeiten von Microsoft war es ausreichend, wenn man einen Kopierschutz in die Software einbaute und mit Anwälten Jagd gegen Raubkopierer machte. Bei Redhat ist die Ausgangslage schwieriger. OpenSource bedeutet, dass kein Kopierschutz da ist. Dennoch hat Redhat einen Weg gefunden wie man geistiges Eigentum schützen kann, und zwar dadurch dass man die Informationen selbst kontrolliert. Redhat macht das so, dass die Handbücher für ihre Software hinter einer Paywall liegen, genannt Redhat Customer Network, Zugriff auf diese Handbücher erhält nur derjenige, der eine Subscription abschließt. Um noch mehr Kontrolle auszuüben, hat Redhat alle Programmierer angeheuert, die Ahnung hatten von Betriebssystemen. Sie programmieren zwar allesamt Freie Software, aber diese Software tut exakt das was Redhat beschließt. Wenn Redhat Standards etablieren möchte so geht das. Der Rest war dann nur noch Fleißarbeit. Man musste einfach dafür sorgen, dass der Linux Kernel so gut ist, dass er jede Anforderung spielend bewältigt und schon hatte man ein Betriebssystem was auf der einen Seite kostenlos kopiert werden konnte, worüber man jedoch gleichzeitig die Kontrolle besaß. Linux war geboren.

Diese Methoden von Redhat sind nicht neu und auch nicht ungewöhnlich. Wer sich die Geschichte der Computerindustrie in den 1980’er anschaut wird bei Firmen wie Borland, Microsoft und Adobe exakt das selbe bemerken. Die Methoden damals waren jedoch plump und als solche zu erkennen. Der Anwender wurde beispielsweise mittels Dongel an den Hersteller gebunden und das Monopol war an closedSource gebunden. Redhat hingegen funktioniert raffinierter. Einerseits gibt es eine Marketing-Abteilung (Ubuntu und Co) welche der Welt erzählt dass Linux kostenlos sei, und das es von Freiwilligen gepflegt werde. Und auf der anderen Seite gibt es den Redhat Konzern selber wo strikte Guidelines befolgt werden und man sich gegen die Welt in einem Krieg befindet der Microsoft alt aussehen lässt.

Wenn Microsoft erzählt, dass sie preiswerter sind und gegen einen Großkonzern rebellieren, dann halten das viele für Marketing-PR. Aber Microsoft sagt die Wahrheit. Es ist ein Underdog, der letzte verbleibende freie Softwarekonzern der sich Redhat erfolgreich wiedersetzt hat. Es ist ein Unternehmen, dass für seine Kunden da ist und sie mit preiswerter Software versorgt. Also mit unabhänger / freier Software. Nicht Microsoft ist der Feind, sondern Linux ist es.

OPEN SOURCE
Das Versprechen von OpenSource lautet, dass man darüber Monopole verhindert, die Kosten für die Anwender reduziert sowie mehr Freiheit erhält. Keines dieser Versprechen hat sich in der Realität eingelöst. Das genaue Gegenteil ist passiert. Dadurch, dass der Sourcecode einsehbar ist, wurde der Aufwand um dort Hintertüren einzubauen erhöht. Das heißt, man hat jetzt 1 Mio Lines of Code von dem man zwar alles im Editor anzeigen kann, aber was der Code in Wirklichkeit macht ist ein Geheimnis. Ferner wurde versprochen, dass sich die Kosten reduzieren. Die Realität ist, dass ein Unternehmen heute 1500 EUR jährlich bezahlt nur für einen simplen EAL4+ zertifizierten Redhat Server. Microsoft hat selbst zu Hochzeiten nicht einen derartigen Geld-Hunger entwickelt. Gleichzeitig ist es heute ausgeschlossen, dass ein anderes Unternehmen zu Redhat in Konkurrenz gehen könnte. Zu Zeiten von Microsoft gab es zumindest noch Hersteller wie Novell die alternative Betriebssysteme angeboten haben. Zu Redhat hingegen gibt es keine Alternative. Aber das schlimmste ist wohl, dass man bei Microsoft wenigstens weiß, dass sie böse Dinge im Sinn haben und im Zweifel die Kunden einfach ausplündern. Redhat hingegen hat es geschafft, seine Kunden selbst darüber zu täuschen.