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.

Advertisements

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.

Wie hoch sind die TCO Kosten für Windows?

Eine Recherche zu den Kosten für Microsoft Lizenzen hat ergeben, dass keiner genau sagen kann was es kostet Windows auf einem Business PC zu installieren. Selbst die sonst gut informierte Wikipedia hält sich zu dieser Frage bedeckt. Es gibt zwar sehr genaue Tabelle über HyperV, Cloud, Datacenter Eigenschaften von Windows Betriebssystemen, aber keine Informationen die etwas mit US$ pro User zu tun haben.

Fragen wir dochmal naiv Amazon was es kostet einen Windows PC zu betreiben. Noch halbwegs leicht fällt die Antwort bei Privat PC. Dort ist beim Kauf von Hardware eine OEM Windows 10 Lizenz mit dabei und fertig. Schwierig wird es jedoch im Business-Segment. Folgende Zahlen konnte ich ermitteln:

– Windows 2016 Server, 500 EUR
– SQL Server 2016, 1000 EUR
– SQL Server User Cal, 150 EUR
– Visual Studio, 500 EUR
– Windows 10, 200 EUR

Hier mal eine Beispielrechnung für einen Server und eine Workstation:
Server: 500+1000 = 1500 EUR
Workstation: 200+500+150 = 850 EUR

Nur, ob diese Zahlen so stimmen ist unklar. Selbst in dezidierten Microsoft Foren scheint niemand zu wissen was es genau kostet, Windows einzusetzen. Anstatt Preise zu nennen heißt es immer, man sollte irgendwo anrufen und das es Verhandlungssache wäre. Was sich jedoch halbwegs seriös sagen kann ist, dass im Business Umfeld folgende Microsoft Produkte eingesetzt werden: Windows 10, Windows Server 2016, SQL Server, Visual Studio, MS Office (inkl. Access), Exchange E-Mail Server. Offen ist die Frage, was der Spaß pro Nutzer kostet. Also wenn man eine Abteilung mit 10 Angestellten hat, die mit obigen Programmen arbeiten, was das Unternehmen dafür bezahlt. Hier wäre ein TCO Rechner sicherlich hilfreich, sowas gibt es jedoch erstaunlicherweise nicht. Meine eigene Schätzung geht ungefähr dahin, dass es 1000 EUR pro Kopf kostet. Aber diese Zahl ist ungewiss.

Und hier kommt Linux ins Spiel. Das interessante bei Linux ist weniger die Software an sich, als vielmehr die Notwendigkeit Linux mit Microsoft zu vergleichen. Seit ungefähr den 1990’er gibt es die ersten Vergleichsstudien, wo also eine Migration von Windows nach Linux durchgerechnet wird. Fast alle diese Studien arbeiten mit geschönten Zahlen, jenachdem wie das Ergebnis ausfallen soll, dennnoch sind solche Vergleiche nützlich weil es zum ersten Mal überhaupt den Versuch gibt TCO Kosten zu bestimmen. Ich vermute mal, auch das LiMux Projekt in München war weniger die Migration von Windows zu Linux sondern eigentlich war es eine Studie darüber, was genau Linux bzw. Microsoft eigentlich kostet.

Solche Studien kann man als sehr wertvoll bezeichnen, weil bis heute eben nicht klar ist, was die Lizenzkosten pro Kopf sind. Das Wort Linux wurde bereits erwähnt. Das schöne an Linux ist nicht unbedingt dass es besser ist, sondern dass dort halbwegs bekannt ist welche Kosten auflaufen. Ein Redhat Server kostet 799 US$ im Jahr (standard-support Vertrag), während eine Redhat Workstation 299 US$ im Jahr kostet (ebenfalls Standard-support). Wenn die Abteilung aus 10 Leuten besteht die 8 Workstations und 2 Server verwenden entstehen Kosten von 399 US$ je Kopf und Jahr. Diese Leute können dann unbegrenzt mit der kompletten Software herumspielen: also C++ Programme schreiben, SQL Datenbanken fahren, Videos schauen und was auch immer. Aber was noch wichtiger ist: wenn irgendwann die Kosten für Redhat aus dem Ruder laufen oder das Unternehmen sparen muss, lässt sich Redhat sehr einfach auf Fedora migrieren. Und das heißt, dass sich die Kosten weiter reduzieren lassen und zwar auf 0 US$. Also das was Linux eigentlich sein sollte: komplett kostenlos. In der Praxis lassen sich die 0 US$ pro Kopf nicht realisieren. Fedora im Unternehmen einzusetzen ist utopisch, weil es dafür keinen Support gibt, das System Bugs enthält und alle 12 Monate aktualisiert werden muss. Aber, wer es draufanlegt kann es versuchen.

Das heißt, im Fall von Redhat hat man Kosten die im Normalfall 399 US$ pro Kopf betragen, und sich theoretisch auf 0 US$ je Kopf senken lassen, bei Microsoft hat man ungefähre Kosten von 1000 EUR über die gesammte Zeit. Wobei man noch im Detail nachrechnen müsste, wie hoch die Kosten für Microsoft tatsächlich sind. Warum das so schwer ist, zeigt ein Beispiel:

Angenoommen die Frage lautet: „Was kostet eine Microsoft SQL Server Lizenz?“ Google wird als Antwort darauf eine Preisspanne von 500 EUR für eine ebay Lizenz bis hin zu 2000 EUR zurückgeben. Unklar ist, was davon benötigt wird und was nicht. Wenn man die Frage beantworten soll, was der SQL Server kostet, der von 100 Leuten benutzt werden darf, wird es noch schwieriger. Hier ist scheinbar alles Verhandlungssache.

Einem Unternehmen den Umstieg auf Linux zu empfehlen ist gewagt, üblicherweise zeichnen sich Linux Projekte dadurch aus, dass sie scheitern (siehe das Beispiel LiMux), was man einem Unternehmen jedoch empfehlen kann ist es, eine TCO Studio Linux vs. Microsoft zu erstellen. Also einfach mal aufzulisten, was die Kosten pro Jahr und Kopf sind. Wenn man dann zum Schluss kommt dass Microsoft preiswert ist und man damit zufrieden ist: ausgezeichnet. Am besten die Studie als wissenschaftliches Paper im Internet veröffentlichen, weil es aktuell zuwenig von derartigen Analysen gibt. Fleißige Wikipedianer könnten solche Paper dann auswerten und so einen Einblick erhalten, was genau eine Microsoft Lizenz kostet. Das würde für Markttransparenz sorgen.

Ich würde sogar noch einen Schritt weiter gehen und explizit empfehlen, solche TCO Studio mit einem Pro Microsoft Bias zu versehen, also in der Einleitung festlegen, dass Microsoft preiswerter ist und dann im Detail auflisten, was das SQL Server kosten sind. Gerade solche Pro Microsoft Studien geben einen besseren Einblick. Eine der wenigen TCO Studien ist https://core.ac.uk/download/pdf/33973715.pdf (Total Cost of Ownership von Linux und Windows:
Ein systematischer Vergleich, Diplomarbeit 2006). Dort wird sehr allgemein an die Sache herangegangen und es wird versucht auch die Qualität der Software, Stromkosten usw. mit in die Rechnung aufzunehmen. Die 112 Seiten sind jedoch mit dieser Aufgabe überfordert, das Thema ist sehr komplex. Besser wäre es, wenn man sich nur auf Lizenzkosten selber beschränkt und unterstellt, dass die Stromkosten, Anwenderzufriedenheit und Hardwarekosten identisch sind. Also lediglich die reinen Software-Lizenzkosten von Linux mit Windows vergleicht.

Generell sollte beim TCO Vergleichen für Linux immer Redhat ansetzen und dort das Standard-Subscription Modell. Es gibt zwar theoretische Alternativen wie das oben erwähnte Fedora oder gar Debian im Unternehmensumfeld einzusetzen. Aber, die einzig erfolgreichen Beispiele wo Linux tatsächlich in Behörden und Unternehmen eingesetzt wurden basieren allesamt auf Redhat.

WAS KOSTET WINDOWS?
Versuchen wir den Lizenzkosten von Windows noch etwas auf die Spur zu kommen. Sucht man bei ebay nach einem SQL Server so gibt es dort Angebote für 120 EUR je Stück. Allerdings ist unklar, ob das gebrauchte Ausgaben sind oder ob sie überhaupt funktionieren. Wenn man hingegen den Dienst Google Shopping bemüht erhält man folgenden Shop https://www.softwareonlinekaufen.eu/Windows-Server/SQL-Server/Microsoft-SQL-Server-2016-Standard–337.html?refID=gs-de der halbwegs seriös aussieht. Wollte man tatsächlich Software kaufen und im Unternehmen einsetzen wäre das wohl die richtige Anlaufstelle. Dort ist zu lesen, dass der Microsoft SQL Server 2016, 879 EUR kostet und eine Lizenz für einen PC beinhaltet. Das ist dochschonmal eine klare Aussage. Das heißt, man kauft sich einen Server bei HP oder sonstwo und kann darauf dann das Programm installieren.

Blättert man noch etwas im Shop herum so findet sich auch der „Microsoft Windows Server 2016“ für 489 EUR. Aber, dort wird es in der Beschreibung schon schwieriger:

„2-Core Paket. Sie benötigen Lizenzen für 8 Cores pro Prozessor, und mindestens 16 Cores für einen Server.“

Ein fairer Vergleich zwischen Microsoft und Redhat kann nur so aussehen, dass am Ende Microsoft gewinnt. Alles andere wäre unseriös. Weil, wer Redhat einsetzt will im Regelfall seine alten Windows Programme insbesondere die Antivirensoftware von Norton weiterbenutzen und zwar in einer virtuellen Umgebung. Damit das rechtlich erlaubt ist, muss man jedoch weiterhin die Windows Lizenzen bezahlen. Ontop kommen dann noch die Kosten für Redhat, also 299 US$ pro Jahr für die Workstation.

Warum sich bisher Linux nicht durchsetzen konnte

Viele Anhänger von OpenSource und Linux müssen kleinlaut mit Blick auf den Marktanteil zugeben, gegenüber Microsoft im Nachteil zu sein. Auf Webservern hat Linux zwar einen nennenswerten Anteil, aber bereits im Business-Bereich dominiert unangefochten Microsoft und auf dem Desktop liegt der Marktanteil von Linux bei kleiner als 1%. Wie kann es sein, dass ein Projekt wie Linux einerseits technisch so hochentwickelt ist, aber auf der anderen Seite sowenig Anerkennung erfährt?

Wenn ein mittelständisches Unternehmen seine Computer von Windows auf Linux migriert ist der erste Schritt eine Kostenkalkulation. Geld ist das, was für Unternehmen an oberster Stelle steht. Hinzu kommt dann noch eine Bewertung der möglichen Vorteile. Das Hauptproblem ist aktuell, dass niemand so genau sagen kann, was eine Linux Migration kosten wird. Wenn man sich die folgenden Details anschaut wird man sehen, dass Linux sehr viel teurer ist als man vermutet.

Um Linux einzusetzen benötigt man zwingend eine Linux-Distribution. Damit ist nicht etwa das lesenswerte Handbuch „Linuxfromscratch“ gemeint sondern damit ist eine Business-taugliche Distribution gemeint, die sich über Auto-Updates von alleine die neuesten Sicherheitsupdates herunterlädt und die 24/7 läuft. Die einzige Distribution ist derzeit Redhat, alles andere ist Spielkram und ungeeignet für den Business-Betrieb. Bei Redhat gibt es zwei Preismodelle: self-support und Standard. Self-support ist ebenfalls ungeeignet für Business-Kunden, weil der Normalfall darin besteht, dass man die Software auf seinem Rechner-Park installiert, damit nicht klarkommt und dann jemanden benötigt der das Problem lösen kann. Desweiteren hat Redhat geschickterweise dafür gesorgt, dass die Handbücher für ihre Produkte sich innerhalb des „Redhat Customer Networks“ befinden in das man sich nur einloggen kann, wenn man den Standard-Support bestellt hat.

Machen wir es etwas konkreter. Laut https://www.redhat.com/en/store/all-products kostet ein Redhat Server 799 US$ pro Jahr an Lizenzkosten und ein Workstation PC 299 US$ im Jahr. Auch hier gäbe es vielleicht die Option nicht das Workstation Lizenzmodell zu bestellen sondern nur die Desktop-PC Variante, aber die ist nicht leistungsfähig genug. Der Clou ist, dass bei einer Migration von Windows zu Linux man die alten Windows Programme noch eine Weile weiternutzen möchte, so dass ontop noch die Ausgaben für Microsoft Lizenzen anfallen.

Nochmal konkret: wer Linux im Unternehmen einsetzt bezahlt pro PC 299 US$ jährlich und pro Server 799 US$, und die Ausgaben für Microsoft Lizenzen laufen weiter. Das heißt, Redhat ist um einiges teurer als wenn das Unternehmen bei Microsoft only verbleibt, und hier haben wir den Grund warum Linux sich bisher nicht durchgesetzt hat. Die Business-Kunden haben einfach keine Lust ihre Ausgaben für IT zu erhöhen. Und die neuen Freiheiten wie Zugriff auf den Sourcecode, leistungsfähige Kommandozeilenwerkzeuge sowie Absicherung gegen Trojaner benötigen die meisten nicht.

Keineswegs ist die obige Rechnung übertrieben oder basiert auf falscher Interpretation der Redhat Preisliste. Soetwas wie einen preiswerteren Zugang zu Linux gibt es nicht. Weder der self-support innerhalb der Redhat Produktfamilie ist eine Option und schon gar nicht die Verwendung von Non-Redhat Distributionen wie Debian und Co. Keine einzige dieser Distributionen wurde bisher von Firmen erfolgreich ins Tagesgeschäft integriert, obwohl es viele probiert haben. Das heißt, wenn man die obige Methode mit dem Redhat Standard-Vertrag wählt gelingt die Umstellung auf Linux und sonst wird sie scheitern.

Die Frage ist weniger, wie man von Windows auf Linux wechselt, die Frage ist vielmehr welche Alternativen es dazu gibt. Der beste Tipp den man einem Unternehmen geben kann, was seine Kosten reduzieren möchte ist ironischerweise nicht der Umstieg auf Linux, sondern wenn der Ratschlag halbwegs seriös ausfallen soll, lautet er bei Microsoft zu bleiben. So bleiben die Kosten überschaubar und man kann sich die 799 US$ jährlich für den Redhat Server sparen.

Ich will nicht behaupten, dass Linux ein schlechtes Betriebssystem ist. Ganz im Gegenteil, ich selber nutze es seit einer halben Ewigkeit und konnte dadurch sehr viel lernen. Es hat jedoch gute Gründe, warum die Popularität von Linux gering ist. Linux ist vergleichbar mit einem Luxus-Accessoire, wenn Geld keine Rolle spielt nur her damit, wer jedoch als Business Kunde seine Kosten senken will, der wird damit keine Freude haben.

PREISE
Schauen wir uns die unverschämt hohen Redhat Preise etwas genauer an: 799 US$ für den Server jährlich. Die Frage lautet warum man soviel Geld ausgeben soll, wenn es den Sourcecode für den Linux-Kernel, Apache und PHP kostenlos im Internet gibt. Kann man den Code nicht einfach nehmen, damit eine eigene Linux-Distribution basteln um darüber Redhat Konkurrenz machen? So nach dem Motto: Redhat will 799 US$, unsere Distribution kostet nur die Hälfte. Viele haben sich daran bereits versucht, ergebnislos übrigens. Das beste Beispiel in Sachen Redhat Clone dürfte ArchLinux sein. Ein Projekt was eine minimalistische Linux Distribution zum Ziel hat. Das Problem ist folgendes: kein Unternehmen verwendet ArchLinux um seine Server zu betreiben, und es würde auch nicht funktionieren. ArchLinux ist für Hobbyanwender interessant die lernen wollen zu programmieren, aber man kann darüber nicht Redhat Konkurrenz machen. Die Schwierigkeiten im Detail:

Sich aus dem kostenlosen Linux-Sourcecode ein eigenes Betriebssystem zu kompilieren ist möglich. Man braucht dafür mehrere Scripte und das wars dann. Das Problem sind die Updates. Damit das System 24/7 laufen kann und immun ist gegen Virenattacken muss man die Pakete laufend aktualisieren. Genau daran scheitern die Non-Redhat Distributionen. Egal ob man sich ArchLinux, Ubuntu, Gentoo oder wen auch immer anschaut, keiner davon hat eine funktionsfähige Aktualisierung die es mit Redhat aufnehmen kann. Insofern ist es logisch, dass Redhat jährlich 2 Mrd US$ an Umsatz generiert, während alle andere Distributionen Null Euro Umsatz machen.

Es gibt aber noch ein weiteres Problem. Selbst wenn ArchLinux stabil laufen würde, wäre es keine echte Linux Distribution, weil man darauf angewiesen ist das jemand anderes im Upstream den Sourcecode schreibt. Dieser Upstream heißt Redhat. Genauer sind es die dort angestellten Programmierer wie Linus Torvalds und noch einige mehr, welche den Code bearbeiten. Deren Gehaltswünsche sind hoch und sie würden niemals zu ArchLinux wechseln um dort umsonst den Sourcecode verbessern.

Das sind soweit erstmal die Rahmenbedingungen des Linux-Biotops. Ich hoffe, ich habe halbwegs verständlich erläutert was die Ursachen für den geringen Marktanteil von Linux sind und wiso es nicht gelingt, Redhat Konkurrenz zu machen. Das Business Kunden dem Microsoft Konzern treu bleiben liegt nicht etwa am fehlenden Wissen bezüglich Linux, sondern es ist die richtige Entscheidung wenn man die IT-Kosten niedrig halten will.

Es gibt von Linus Torvals ein berühmtes Foto wo er vor einem Windows 7 Stand posiert https://bjdouma.home.xs4all.nl/Linus-Windows-7-rocks-NOT.jpg Das ist keineswegs ironisch gemeint, sondern die Migration von Redhat Linux zu Windows ist ein sinnvoller Weg für Businesskunden die keine Lust mehr auf horrende IT Kosten haben und die einen Weg suchen, Geld zu sparen. Für die ist Microsoft konkurrenzlos preiswert. Man kann Windows Server als einziges Betriebssystem einsetzen ohne parallel noch Linux zu betreiben, und da Windows ein Massenmarkt ist, sind die Lizenzkosten überschaubar. Hier mal der Vergleich:

Redhat:
– Server jährlich 799 US$
– Windows Server in virtueller Umgebung für Altanwendungen, 233 US$ jährlich
Summe 1032 US$ jährlich

Microsoft Windows:
– Windows Server 2016, Preis 700 US$
– 3 Jahre Nutzungsdauer, jährlich 233 US$
Summe 233 US$ jährlich

Das heißt, ein Windows only System kostet nur 1/4 eines Redhat Servers in Vollausstattung.