In Foren und Kommentaren in Blogs liest man häufig, KDE Software habe zu viele offene Fehler und die Entwickler sollten sich lieber darauf konzentrieren, alte Fehler zu beheben, anstatt ständig neue Funktionen einzuführen. Und es stimmt, im KDE Bugtracking System finden sich viele Berichte über Fehler, die dort bereits sehr lange unbearbeitet stehen.
Freie Software praktizieren
Anstatt sich darüber zu beschweren, kann eigentlich jeder mit geringen Mitteln und ohne Programmierkenntnisse helfen, diese Zahl zu senken. Dazu gibt es die KDE Bug Squad, die sich das Bug-Triaging zur Aufgabe macht. Unter Bug-Triaging versteht man die anfängliche Analyse von gemeldeten Fehlern nach bestimmten Kriterien wie unter anderem:
Ist der Fehler reproduzierbar?
Hat der meldende User genügend Informationen übermittelt?
Ist die Fehlermeldung ein Duplikat eines bereits gemeldeten Fehlers?
Bug Triage hilft den Entwicklern
Allein die Klärung dieser Fragen hilft, irrelevante Fehlermeldungen zu schließen, weitere nötige Informationen einzuholen oder Dubletten zusammenzuführen. Das hilft den Entwicklern beim der Behebung von Fehlern. Dabei ergibt es anfangs Sinn, sich Fehler in Anwendungen zu suchen, mit denen man selbst arbeitet und die man von daher gut kennt. Manch gemeldeter Fehler stellt sich beispielsweise als falsch verstandene Funktionalität heraus. Die KDE Bug Squad hat eine ausführliche Anleitung verfasst, um den Einstieg in das Thema zu vereinfachen. Neueinsteiger erhalten einen Mentor, der sie in die Materie einführt. Bevor ihr euch also das nächste Mal über die hohe Fehleranzahl beschwert, schaut doch mal rein und versucht zu helfen.
Ein positiver Nebeneffekt dabei ist, dass man dabei einen guten Einblick in die einzelnen Komponenten und deren Zusammenwirken erhält. Auch wer erwägt, in die Entwicklung mit Qt einzusteigen findet hier einen guten Einstiegspunkt.
Es ist das Buzzword unserer Tage: Digitale Souveränität. Schon seit längerer Zeit reden nicht mehr nur Aktivisten darüber, sondern auch Politik und Medien bis zu den Tageszeitungen. Beschleunigt wird der Diskurs durch die aktuelle Corona-Pandemie, die tatsächlich das Digitale auf die Agenda setzt. Im Kern geht es dabei um die Frage, inwieweit die Länder Europas (in Form vom Individuum bis zur Gesellschaft) in der Lage sind, individuelle Kompetenzen zu besitzen und die äußeren Rahmenbedingungen für den souveränen Umgang mit digitalen Medien zu schaffen.
Das klingt akademisch, die Antwort erleben wir aber in der Praxis: Just am heutigen Montag sind viele Unterrichtsveranstaltungen, die »synchron« stattfinden sollten, an diversen deutschen Universitäten ausgefallen: Es liegt eine Störung der Webex Education Cloud vor. Fehlermeldungen höchster Priorität trudeln nun beim zuständigen Dienstleister ein. Die Universitäten können nur abwarten und Veranstaltungen verschieben. Ist das souverän?
Wer ist schuld?
Es wäre wenig fair, den Dozierenden einen Strick daraus zu basteln. Die individuellen Kompetenzen sind nach den zahlreichen Monaten der Online-Lehre sicherlich bei nahezu allen gegeben. Die Rahmenbedingungen passen allerdings nicht.
Cisco Webex stellt den Standard für Videokonferenzen dar. An einzelnen Tagen wurden 4,2 Millionen Meetings mit Webex veranstaltet. Webex ist im Prinzip proprietär, wenngleich eine solche Software natürlich nicht ohne zahlreiche Bestandteile freier Software auskommt. Hier ist Cisco auch durchaus aktiv in der Entwicklung. Trotzdem ist der Einsatz nicht ganz unproblematisch.
Dabei will ich gar nicht lange über Datenschutz schreiben. Dass es nicht unbedingt charmant ist, diesen (amerikanischen) Dienst zu nutzen, dürfte klar sein. Irgendwie arrangieren sich dann aber doch alle Beteiligten, wenngleich das mitunter zu interessanten Auswüchsen führt: Manche Unterrichtsmaterialien dürfen nicht gezeigt werden, Anwesenheit nicht geprüft…
Problem: Die Abhängigkeit bei SaaS
Viel größer wiegt das Problem der Abhängigkeit. Wenn Webex nicht läuft, läuft die Lehre nicht. Es ist der klassische Lock-In-Effekt der Software as a Service (SaaS). Und hier zeigt sich auch, dass Open Source alleine nicht (mehr) die Lösung ist. Natürlich reduziert das Prinzip »Public Money, Public Code« die Abhängigkeit von einzelnen Anbietern und letztlich wahrscheinlich auch die Kosten. Viele Universitäten nutzen beispielsweise Moodle als Lernplattform. Doch auch hier traten im Einzelfall Probleme auf, wenn die Datenbanken überlastet sind. Diese können allerdings im Vergleich zur Software as a Service noch leicht auf einen anderen Server geladen werden, um die Verfügbarkeit wiederherzustellen.
Das geht nicht mit Videokonferenzsoftware, die als Cloudsoftware läuft. Die große Anzahl an benötigten Ressourcen macht das Bestehen von Open Source Software ohne angebundene Cloud in diesem Bereich auch schwierig: Zwar gibt es Jitsi und BigBlueButton, für das Betreiben sind aber gerade in höheren Skalen von einigen Hundert Teilnehmern sehr kluge Köpfe vonnöten. Und auch für andere Software gibt es oft gute Gründe, auf die Cloud zu setzen, wenngleich bei Weitem nicht für jede. Allerdings bedarf es dafür auch eines Angebots an offenen Clouds.
Das läuft allerdings den Interessen von Amazon, Microsoft und Google zuwider. Will man digital souverän sein, so braucht es nicht nur kompetente Köpfe vom Anwender bis zum Politiker, sondern auch offene Software samt »offener Clouds«. Es bleibt zu hoffen, dass das europäische Projekt »Gaia-X« diese Lücke schließt und auch auf den Ebenen davor nicht geschlafen wird.
Die Apache Software Foundation (ASF) verkündet in ihrem Blog, die unter ihrem Schirm agierende Büro-Suite OpenOffice verzeichne von 2011 bis heute über 300 Mio. Downloads. Dabei entfallen mehr als 200 Mio. auf die Veröffentlichungen der Reihe Openoffice 4.1.x. In den vergangenen Tagen lagen die Downloadzahlen jeweils bei über 4.000, wie die Statistik zeigt.
Statistik
Der Großteil der Downloads wurde über SourceForge getätigt, die Zahlen werden über deren Download Stats API bereitgestellt und über ein Python Script ausgelesen. Über weitere Downloads von Servern, die von der ASF zur Verfügung gestellt werden, liegen keine genauen Zahlen vor. Die verteilten CDs und DVDs sind in dieser Zahl ebensowenig enthalten wie Sprachpakete, SDKs oder Quelltexte.
Bei der Aufschlüsselung der Zahlen ergibt sich, dass die meisten Downloads mit 51,5 Mio. in den USA getätigt wurden, gefolgt von Frankreich mit annähernd 40 Mio. und Deutschland mit fast 32 Mio. Aufgegliedert nach Betriebssystemen entfallen 271,3 Mio. auf Windows, 28,7 Mio. auf macOS und 4,3 Mio. auf Linux.
Offener Brief an die Entwickler
Laut dem Blogeintrag arbeiten die Entwickler gerade an der Fertigstellung von Apache OpenOffice 4.1.8. Erst kürzlich feierte OpenOffice den 20. Geburtstag nach der Abspaltung von StarOffice im Jahr 2000. Der Vorstand der Document Foundation (TDF) als Schirmorganisation der aus OpenOffice hervorgegangenen LibreOffice-Entwicklung hatte einen offenen Brief an die Entwickler von Apache OpenOffice gerichtet, in dem sie forderten, aufgrund der zwar großen Bekanntheit, andererseits aber fehlender Entwicklung einen Hinweis auf der Webseite von OpenOffice auf das »viel modernere, aktuellere, professionell unterstützte« LibreOffice zu platzieren und gemeinsam daran weiterzuarbeiten. Bereits mehrfach wurde OpenOffice von verschiedenen Seiten aufgefordert, zumindest die Downloads zu sperren. Im Jahr 2017 äußerten sich die Entwickler unterschiedlich zum damaligen Stand des Projekts.
Schein und Sein
Schaut man sich die Entwicklung von OpenOffice im Git an, so ist man geneigt, dem offenen Brief zuzustimmen. Es finden zwar viele Commits statt, diese beschränken sich aber hauptsächlich auf zwei Personen, die mehrheitlich Bugfixes einbringen. Insgesamt ist nur wenig Weiterentwicklung zu erkennen.
Liest man allerdings die Meldung zum 20. Geburtstag im Blog der ASF, so stellt sich OpenOffice als vitales Projekt dar und verweist auf 12 Veröffentlichungen in den 8 Jahren unter dem Dach der ASF. Nicht erwähnt wird dabei, dass OpenOffice seit 2013 auf Version 4.x verharrt und man seitdem LibreOffice hinterherläuft, was Weiterentwicklung angeht. OpenOffice lebt heute überwiegend von seinem früheren Glanz und die Downloadzahlen erklären sich aus damit verbundenen Bekanntheit in der Öffentlichkeit.
Minix war 1995 mein Einstieg in die Unix-Welt und 1999 bin ich privat vollständig von DOS/Windows auf Linux mit X11 umgestiegen. Seit 2014 benutze ich Linux auch beruflich als Hauptbetriebssystem und Windows nur noch für die proprietäre Software meines Geräteparks.
Im August 2020 habe ich mir zu meinem Microsoft Surface Pro-4 einen 32-Zoll UHD Monitor geleistet und mich auf eine deutliche Verbesserung meines täglichen Arbeitsumfeldes gefreut – die Augen werden auch nicht besser und das Display vom Surface ist super in der Auflösung, aber doch recht klein. Die Erwartungen an das Gesamtsystem mit dem neuen Monitor waren hoch.
Mein bisheriges Arbeitsumfeld mit Manjaro und KDE 5.19.5 lief unter X11. Damit war für alle drei Monitore nur eine einheitliche Skalierung möglich. Im Klartext hieß 100% perfektes Bild auf dem neuen UHD und dem alten FullHD Schirm, dafür unleserlich klein auf dem Surface. Oder lesbar auf dem Surface und dafür verschwendete Auflösung auf den anderen beiden Schirmen – so schlecht sehe ich nun auch wieder nicht.
„Wayland kann das“, sagt das Netz
Die Lösung war schnell gefunden: Wayland, der neue Standard für die grafische Oberfläche – so stand es in zahlreichen Beiträgen im großen weiten Web. Diese sollte neben höherer Sicherheit auch mehr Performance und vor allem freie Skalierbarkeit je Monitor bieten.
Super – schnell die Wayland-Session dazu installiert und – das Chaos begann. Als erstes streikte gleich einmal Libreoffice, welches unter Wayland keine Menüleiste mehr anzeigte. Copy und Paste funktionierte nicht mehr, ebenso wenig Screenshots. Auch andere Programme verhielten sich sehr zweifelhaft und Systemabstürze stellten sich stündlich ein.
Als leidenschaftlicher Experimentierer (schließlich bin ich Chemiker) war das eine Herausforderung, der ich mich gerne stellte. So installierte ich mehrere Distributionen und schließlich auch unterschiedliche Desktop Environments auf einer eigenen Partition (keine VMs). Immer auf der Suche nach einer für den Produktiveinsatz stabilen Variante mit Wayland, die mir auch den gewohnten Komfort bot.
Erkenntnisse harter Arbeit
Nach einem knappen Monat muss ich ernüchternd feststellen, dass es die viel zitierte „eierlegende Wollmilchsau“ noch immer nicht gibt. Ich bin jetzt (wieder) bei KDE neon mit Plasma 5.20.0 gelandet, weil ich mich mit den anderen Desktop Environments nicht anfreunden kann und ich hier noch die „stabilste Kombination“ installieren konnte. Aus mir nicht nachvollziehbaren Gründen stellte sich Manjaro plötzlich als äußerst widerspenstig heraus und auch Fedora, SUSE Tumbleweed und diverse Ubuntu Varianten boten mir nicht das, was ich wollte.
Mit „stabilster Kombination“ möchte ich sagen, dass man zwar damit arbeiten kann, sich allerdings mit einigen Problemen abfinden muss. Gleich nach dem Login (SDDM) zeigen sich auf den Bildschirmen Darstellungsfehler im Aufbau der Desktops – sieht fast so aus, als ob Wayland die Position mit den drei Schirmen so lange über mehrere Versuche festlegt, bis es passt. Bei den Systemeinstellungen fehlt das Sub-Menü für die Verwaltung der Schriftarten. Nicht benötigte deinstallieren oder neue hinzufügen geht unter Wayland auf diesem Weg nicht.
Problembereich Screenshots
Screenshots sind nach wie vor ein Problem. Spectacle bei KDE funktioniert als User sporadisch, zumindest für die Aufnahme aller Bildschirme oder desjenigen, auf dem man sich gerade befindet. Für einen rechteckigen Bereich lässt einen das System einen Rahmen aufziehen, übernimmt dann allerdings einen ganz anderen Bildschirmbereich. Meist startet es allerdings erst gar nicht (Speicherzugriffsfehler). Als Root (mittels sudo auf der Kommandozeile) startet Spectacle problemlos (nachdem man Root den Zugriff mit xhost +si:localuser:root erlaubt hat) und schaltet dann bei der Auswahl auf drei vollkommen schwarze Bildschirme um. Dort darf man auswählen und bekommt als Ergebnis auch ein schwarzes Bild. Auch Flameshot funktioniert unter Wayland nicht – es zeigt das Icon im Systray an und das war’s dann auch schon. Kurz und Gut – noch immer keine Screenshots unter Wayland.
Startet man GwenView und navigiert durch die Unterordner kommt es zu Darstellungsfehlern (die Icon/Ordner-Größe stimmt nicht und sie überlappen sich), welche sich durch manuelle Größenänderung reparieren lassen. Nervig ist auch, dass Wayland die räumliche Anordnung der Bildschirme von Zeit zu Zeit vergisst und ich diese wieder neu einrichten muss (insbesondere, wenn ich mein Surface aus der Docking-Station nehme und später wieder in diese zurückbringe).
Copy & Paste Lotterie
Was mich jedoch am meisten stört, sind noch immer auftretende Abstürze der Plasma-Shell und das nur sporadische Funktionieren der Copy & Paste Funktion. Es ist wirklich lästig, wenn man Textschnipsel von einem Dokument in ein anderes übernehmen will und Wayland offensichtlich im Hintergrund würfelt, ob es die Information übernehmen soll oder nicht. Die Abstürze der Plasma-Shell fallen erst auf, wenn man ein Element aus der Kontrollleiste braucht und dieses nicht reagiert. Die stehen gebliebene Uhr zeigt dann an, wann die Shell abgeschmiert ist. Leider bin ich bis dato trotz Syslog noch nicht auf einen verbindlichen Anhaltspunkt gestoßen, woran es liegen kann. Dieses Problem habe ich auf zwei Varianten umschifft: einmal mit einem forschen killall plasmashell ; plasmashell & als Tastaturkürzel zum Wiederbeleben und zum anderen das Starten einer Debug-Shell mit sudo gdb -pid `pidof plasmashell`. Letzteres vermeidet die Abstürze, liefert dann aber leider keine Hinweise mehr.
Langer Rede kurzer Sinn
Ich habe die (schmerzliche) Erfahrung gemacht, dass sich Wayland und KDE offensichtlich nicht so vertragen, dass man von einem stabilen System für produktives Arbeiten sprechen kann. Ich bin mir bewusst, dass meine Konstellation (MS-Surface & Multi-Monitoring) durchaus herausfordernd ist, allerdings beherrscht X11 alles problemlos, bis auf die individuelle Skalierbarkeit.
In diesem Sinne verstehe ich die Schönrederei rund um Wayland nicht. Was nutzt es mir, wenn ein (inzwischen auch schon in die Jahre gekommenes) neues, moderneres und zukunftssicheres System, das seit 30 Jahren laufende X11 ersetzen soll, wenn es immer noch nicht stabil ist. Mehr Sicherheit, Performance und Skalierbarkeit sind schön, will ich haben – allerdings muss es funktionieren. Wenn so einfache Dinge wie Copy & Paste sowie Screenshots am Sicherheitssystem scheitern, lässt das bei mir die Alarmglocken klingeln – irgendetwas läuft hier nicht rund. Vielleicht ist das auch nur die Spitze vom viel zitierten Eisberg.
Es ist mal wieder soweit: Mozilla hat einen neuen Dienst herausgebracht, der spannend klingt und einen echten Mehrwert bietet: Firefox Relay erstellt zufällige E-Mail-Aliase, die man für Online-Dienste verwenden kann. Trotzdem landen alle E-Mails in dem Postfach des Nutzers, wird allerdings ein Dienst gehackt oder verbreitet Spam kann man die Adresse schnell deaktivieren.
Klingt doch spannend, oder? Trotzdem werde ich den Dienst nicht nur nicht nutzen, sondern es stößt in mir etwas auf, was mich dazu verleitet, einen Kommentar zu verfassen.
Das Unternehmen hinter Firefox
Hinter dem Firefox steht Mozilla. Die Mozilla Foundation ist eine Non-Profit-Organisation mit einer Selbstbeschreibung als „gemeinnützige Organisation, gewidmet der Wahrung der Wahlmöglichkeiten und der Innovation im Internet“. Die Foundation besitzt eine Tochterfirma, die Mozilla Corporation. Diese ist für Projekte wie den Firefox zuständig. Der Umsatz liegt bei 450 Millionen US-Dollar, 700 Mitarbeiter sind angestellt, jüngst wurden recht umfangreich Stellen abgebaut. Viele Kritikpunkte wurden bereits auf diesem Blog vorgestellt.
Wenn ich heute von neuen Diensten lese, werde ich etwas emotional. Der Firefox war damals mein erster Kontakt mit freier Software. Und er war wahrlich ein Segen im Vergleich zum Internet Explorer. Firefox war nicht nur der Inbegriff von technischer Innovation, sondern auch von Datenschutz und setzte sich vollkommen zurecht an die Spitze der Internetbrowser, was sich mit Suchmachschinenvoreinstellungen gut monetarisieren ließ. Und auch immer noch gut lässt. Wenngleich heutzutage Google freiwillig so viel Geld gibt, um einer Zerschlagung oder Monopolverfahren zu entkommen. So landet man in der desaströsen Position, nicht nur abhängig von seinem Konkurrenten zu sein, sondern auch technisch mehr und mehr und im Marketing vollständig ins Hintertreffen zu geraten. So drängt sich immer, wenn man von neuen Mozilla-Projekten liest, die Frage auf, ob Mozilla nicht das Kerngeschäft sträflich vernachlässigt.
Die Marke Firefox nimmt Schaden
Doch damit nicht genug. Die Marke Firefox, eben doch noch positiv besetzt, wird mehr und mehr ausgehöhlt. Auch durch diese Projekte, die primär gar nichts mit Firefox als solches zu tun haben. Der gemeine Nutzer mag Firefox als seriöse Marke kennen (oder gekannt haben?), weiß aber mit Firefox Relay, Firefox Send, Firefox Lockwise und Konsorten nichts anzufangen. Und damit nicht genug: Letztlich schaden solche Dienste der Marke, wenn sie Ressourcen aus dem Kerngeschäft ziehen, anderer Qualität sind oder letztlich schnell wieder eingestampft werden.
Denn das passiert nur allzu schnell und zu oft. Ehemalige Nutzer von Mozilla Prism, Chromeless, Persona, Firefox Note oder Firefox OS kennen es allzu gut. Mitunter groß angekündigt, verschwanden all diese Dienste schnell wieder in der Versenkung. Und jedes Mal ging ein wenig vom Mythos des Firefox verloren. Früher hießen die Dienste noch Mozilla, mittlerweile gleich Firefox, egal wie wenig sie mit dem Browser zu tun haben. Wie sie wohl dann heißen, wenn der Name Firefox nicht mehr wert ist?
Und was folgt als Nächstes? Wird Mozilla VPN eingestampft, bevor oder nachdem der Dienst in Deutschland startet? Was wird aus Pocket? Oder dem eingangs erwähnten Firefox Relay? Wie lange bleibt man auf dem scheinbar aussichtslosen Markt der mobilen Endgeräte? Rust als Programmiersprache mit großer Zukunft hat sich schon ganz freiwillig in eine unabhängige Foundation ausgegliedert.
Muss es mit dem Firefox und Mozilla ein böses Ende nehmen?
Nein, denn eigentlich ist die Struktur gar nicht schlecht. Ein umsatzstarkes Unternehmen, welches Firefox entwickelt und Profite erwirtschaftet, auch wenn die von Google kommen, ist nicht schlecht. Allerdings muss es sich auch wie ein gewinnorientiertes Unternehmen verhalten. Und nicht nur Laien würden zu einer Konzentration auf das Kerngeschäft raten. Und zu einer Verschlankung des administrativen Bereichs. Möglicherweise würde man Firefox auch für die Businesswelt fit machen und könnte dort Geld sammeln.
Gewinne sollten dann an die Foundation abgeführt werden, die auch auf politischer Ebene aktiv werden muss. Die Sicherung eines freien Internets für die Menschen statt der Unternehmen muss Priorität der Stiftung haben, die zu einer starken Stimme werden kann. Neben dem Geld aus der Corporation sollte auch um öffentliche Gelder geworben werden. Sei es vom Nutzer, sei es vom Steuerzahler. Und dann sollten Projekte freier Software wirkungsvoll unterstützt werden. Nicht nur mit Geld, sondern auch Know-how. Die Möglichkeiten des Internets sind riesig. Solange es frei bleibt. Dazu braucht es eine starke Stiftung und einen guten Browser.
Neben aktuellen News und längeren Artikeln gibt es auf diesem Blog gelegentlich auch Meinungsbeiträge. In diesem hier geht es um freie und unfreie Software mitsamt ihren Grenzen und Problemen. Kommentare und Anmerkungen zu eigenen Erfahrungen sind willkommen.
Mit freier Software ist es wie mit dem Vegetarismus. Es spricht vieles dafür, dieser Lebensweise zu folgen. Manchmal ist es aber erstaunlich schwierig, dem Steak zu widerstehen, wenn man sonst nur Beilagen zur Auswahl hat.
Wenn freie Software keine Alternative ist
Es gibt Momente, in denen freie Software keine Alternative ist. Diese sind zwar deutlich seltener als gemeinhin angenommen, zumindest zwei Szenarien fallen mir allerdings ein: Zum einen, wenn ein Gerät ohne freie Software gar nicht läuft. So sehr ich auch auf freie Software setzen möchte: Damit allein läuft mein Drucker nicht.
Zum Zweiten gibt es Situationen, wo man beruflich, schulisch oder universitär Software vorgesetzt bekommt, die unfrei ist. Da hilft kein Jammern: Wenn die Videokonferenz aus dem Hause Cisco stammt, kann man nur darüber teilnehmen. Will man sich dann auch noch selbst beteiligen, so ist man auch angeraten, den (unfreien) Client zu installieren. Gibt es den wenigsten für Linuxdistributionen? Natürlich nicht.
Das sind Momente, wo man sich die Frage, ob die freien Alternativen wie Jitsi oder BigBlueButton nicht auch taugen, gleich sparen kann. Man ist eh nicht in der Entscheidungsposition.
Wenn freie Software die Alternative ist
Allerdings hört hier die Grenze allerdings auch schon auf: Ab jetzt ist man immer in der Entscheidungsposition. Und da macht es dann auch Sinn, sich mit freier Software zu beschäftigen. Diese wird übrigens als solche bezeichnet, wenn sie über folgende vier wesentliche Freiheiten verfügt:
Die Freiheit, das Programm auszuführen wie man möchte, für jeden Zweck (Freiheit 0).
Die Freiheit, die Funktionsweise des Programms zu untersuchen und eigenen Datenverarbeitungbedürfnissen anzupassen (Freiheit 1). Der Zugang zum Quellcode ist dafür Voraussetzung.
Die Freiheit, das Programm zu redistribuieren und damit Mitmenschen zu helfen (Freiheit 2).
Die Freiheit, das Programm zu verbessern und diese Verbesserungen der Öffentlichkeit freizugeben, damit die gesamte Gesellschaft davon profitiert (Freiheit 3). Der Zugang zum Quellcode ist dafür Voraussetzung.
Schon beim Durchlesen dieser Definitionen leuchtet den meisten ein, dass es durchaus Sinn macht, sich an erster Stelle im Entscheidungsprozess auch immer mit freier Software zu beschäftigen. Und diese gibt es eben auch für fast jeden Zweck.
Wenn unfreie Software die Alternative ist
Nur manchmal lachen die unfreien Alternativen den Nutzer an. Besonders gerne, wenn sie vorinstalliert sind. Oder aber als Marktstandard gelten. Da stellt sich dann doch die Fragen, wie man damit umgehen möchte. Mitunter erinnern Diskussionen zwischen Verfechtern freier Software und jenen Nutzern, die proprietäre Programme nutzen, an jene, die Vegetarier und Fleisch-Esser führen: Der Nutzer freier Software sieht alle entscheidenden Argumente (zumindest die ethischen) auf seiner Seite und versucht, den anderen davon zu überzeugen.
Aber wie viele Fleischesser wurden bislang durch eine Diskussion mit Vegetariern zum Vegetarismus bekehrt? Zumal bei einer Diskussion über Freiheit auch hinzukommt, dass der Nutzer Entscheidungsfreiheit besitzt. Er darf sich auch gegen freie Software entscheiden. Auch wenn die Entscheidung nicht unbedingt clever ist. Mitunter bietet sich dann allerdings die Chance, zumindest auf einen freien Standard zu setzen.
Wenn unfreie Software keine Alternative ist
Manchmal zeigt sich allerdings auch im Nachhinein für den Nutzer selbst, dass unfreie Software auch keine Lösung ist. Dazu eine Anekdote: Zu Beginn des Jahres kaufte ich mir (gebraucht) ein älteres iPhone. Und das durchaus als Verfechter freier Software. Trotzdem war die Entscheidung bewusst: Ein vier Jahre altes Smartphone, das noch immer mit aktueller Software versorgt wird, ein gutes Energiemanagement verfügt und durchaus sicher ist. Alles Dinge, die die Konkurrenz auf dem Markt der mobilen Endgeräte nicht erfüllt. Mir war bewusst, dass ich mich dabei auch für ein Ökosystem entscheide. Heutzutage sind die Smartphones ja sehr unabhängig von anderen technischen Geräten, was sollte da schon schief gehen.
Nun, einen ersten Makel erlebte ich früh. Schon beim Versuch, meine Musiksammlung auf das Smartphone zu übertragen, musste ich feststellen: Das geht ohne iTunes schlichtweg nicht. iTunes ist natürlich keine freie Software und läuft unter Linux nicht. Dafür muss man sich eine virtuelle Maschine basteln, die für die Nutzung eines USB-Ports auch wieder ohne freie Software auskommen muss. Da wird dann Windows installiert, danach iTunes und dann darf man sich um seine Musiksammlung kümmern. Das mag heutzutage nur noch wenige Menschen stören, wenn jeder seine Musik streamt. Wer allerdings Musikstreaming ablehnt oder mit der Musik einschlägiger Streamingdienste unzufrieden ist, der muss basteln.
Trubleshooting XXL
Aber einige Monate später kam es noch schlimmer: Eines der hochgelobten Upgrades für iOS lief schief. Nichts ging mehr, das Geräte zeigte mir an, dass ich es an einen Computer anschließen sollte. Das soll auch nicht das Problem sein, allerdings ist mit PC heutzutage wohl ein Mac oder ein Windows-Computer mit iTunes gemeint. Eine virtuelle Maschine hingegen funktioniert nicht. Der Restore-Modus des iPhone lässt sich nicht als USB-Geräte an die virtuelle Maschine weitergeben, zumindest bei den bekanntesten drei Programmen für virtuelle Maschinen.
Hat man kein Mac oder Windows in seinem Haushalt nativ, muss man sich eben eines zulegen. In der Reserve befand sich noch einen bootfähigen Windowsstick. Dieser hat auch mal funktioniert, wollte aber just in diesem Moment nicht: „Medientreiber“ fehlen. Dasselbe gilt dann auch für jeden der weiteren erstellen bootfähigen Sticks und auch kein erdenklicher Treiber des Planeten lässt mich die Installation starten. Nächster Versuch: Es soll eine DVD gebrannt werden, der alte klassische Weg. Allerdings funktioniert natürlich auch dies nicht einfach so.
Obwohl Windows nach einer Installation eh noch massig Updates runterlädt, ist das Installationsimage über 5 Gigabyte groß. Auf eine Standard-DVD passen allerdings nur 4,7 GB. Ich halte wenig davon, Menschen über das Internet die Kompetenz abzusprechen, schließlich könnte man das bei mir auch wunderbar machen. Allerdings bin ich dicht davor, für die Mitarbeiter aus dem Hause Microsoft, die das Installationsimage für Windows erstellen, eine Ausnahme zu machen. Zu groß für eine normale DVD, zu klein für den „Medientreiber“? Immerhin, im vergangenen Jahr konnte man aus einem USB-Stick auch nicht ohne Weiteres einen Windows 10 Stick machen, weil eine Einzeldatei des Images zu groß für das Dateisystem war, welches zur Windowsinstallation benötigt wird.
Also erst einmal eine DVD des Typs „Double-Layer“ besorgt, wenig später dann noch einen passenden Brenner (da sind wir wieder bei der Kompetenz, wer austeilt…). Dann also „schnell“ die DVD gebrannt, Windows installiert, Treiber und Updates heruntergeladen, iTunes installiert und iTunes mein iPhone retten lassen.
Fazit
Eigentlich haben die Nutzer freier Software alle Argumente auf ihrer Seite. Allerdings stoßen sie doch gelegentlich auf Grenzen. Diese sind zwar deutlich geringer als gemeinhin angenommen und spielen sich häufig eher im Kopf ab. Probleme hat man auch mit unfreier Software. Mich hat die Erkenntnis, dass freie Software und freie Standards viel wert sind, fast einen ganzen Tag an Troubleshooting gekostet. Keine freie Software ist halt auch keine Alternative. Vielleicht finde ich ja noch eine für die mobile Welt.
Während der Online-Konferenz DebConf 20 vor rund zwei Wochen hielt der derzeitige Projektleiter Jonathan Carter einen Vortrag zu den Problemen, denen sich das Projekt derzeit gegenüber sieht. Kurz zusammengefasst lautet das Fazit: Wir haben genug Geld, aber zu wenig Entwickler.
Große Außenwirkung
Debian ist ein Projekt mit großer Außenwirkung. Einerseits wird es in vielen Unternehmen und Organisationen bis hinauf zur ISS als Server-Software eingesetzt, andererseits nutzen viele Distributionen Debian als Basis. Ubuntu ist die größte dieser Distributionen, die wiederum selbst Hunderte von Ablegern hat, die indirekt ebenfalls auf Debian basieren.
Diese große Außenwirkung erzeugt Debian erstaunlicherweise als freies Projekt ohne ein Unternehmen im Hintergrund und nach dem Prinzip der Do-ocracy arbeitend.
Genügend Geld …
Im Vergleich mit der Bedeutung von Debian ist die Entwicklerschar relativ übersichtlich und schwankt seit Jahren um die Tausend. Derzeit sind es 975 Entwickler und 223 Maintainer. Das ist laut Carter zu wenig und behindert das Wachstum des Projekts. Derzeit finden sich in Debian 11 »Bullseye«, der kommenden stabilen Version des Projekts über 61.000 Binärpakete der amd64-Architektur und fast 32.000 Quellpakete.
… zu wenig Entwickler
Die finanzielle Basis des Projekts erscheint sehr solide, denn derzeit verwalten die drei Organisationen debian.ch, debian.france und Software in the Public Interest (SPI) rund 930.000 US-Dollar für Debian. Angesichts dieser Summe erscheint es mir unverständlich, warum Teams von Debian-Entwicklern komplexe Software-Sammlungen wie KDE Plasma auf unzureichender Hardware bauen müssen und dabei sowieso schon rar gesäte Entwicklerzeit verschwenden.
Debian ist ein bodenloser Abgrund an Problemen und ich meine das auf die freundlichste Art und Weise, die möglich ist.
Jonathan Carter, DebConf 2020
Carter versucht im Vortrag zu erklären, woran es liegt, dass Hardwarebeschaffung in einem solchen Projekt aufgrund der dezentralen Verteilung der Entwickler ein Vorhaben ist, dass oft länger dauert als erwartet. Allein der Austausch einer Festplatte kann so zu einem größeren Unterfangen werden, wenn jemand zum entsprechenden Rechenzentrum reisen muss, um den Austausch vorzunehmen.
Hardware-Bereitstellung
Bei der Inbetriebnahme neuer Server gestaltet sich das noch wesentlich komplexer. Carter weist zudem darauf hin, dass Covid 19 natürlich in diesem Jahr noch zusätzlich bremst. Ein weiterer Punkt sei, dass viele Entwickler sich schämen, ihren Bedarf öffentlich zu machen. Das will mir nun gar nicht einleuchten. Wenn ich schon meine Zeit einbringe für ein Projekt, erwarte ich sogar, bestmöglich unterstützt zu werden.
Viele Entwickler sind permanent überlastet, ihr Leben ist zeitweise von Debian bestimmt und sie arbeiten am Rande ihrer Leistungsfähigkeit. Carter schätzt, dass Debian mit der dreifachen Zahl an Entwicklern alle seine Ziele erreichen könnte und gleichzeitig das Stresslevel auf ein erträgliches Maß gesenkt werden könnte.
Neue Entwickler akquirieren
Das führt zu der Frage, warum Debian bei der großen Außenwirkung nicht mehr Entwickler anzieht und wie mehr Anreize im Onboarding geschaffen werden können. VieleProbleme des Projekts sind bereits öffentlich diskutiert worden, Abhilfe ist aber nur sehr begrenzt in Sicht. Es wird ständig darüber diskutiert, wie man mehr Frauen und Minoritäten für Debian akquirieren kann. Ich denke dagegen, viel entscheidender ist, dass der Entwicklernachwuchs immer weniger bereit ist, sich mit verkrusteten Strukturen und nicht adäquaten Tools und Kommunikationsformen abzufinden.
Veraltete Strukturen
Auch die internen Strukturen halten Debian auf. Neue aufzunehmende Pakete oder bestehende, deren Änderung eine Sichtung im Hinblick auf Copyright und Lizenzen benötigen, landen in NEW-Warteschlange, in der eine Wartezeit von einem Monat keine Seltenheit ist und derzeit zwei Pakete seit fast einem Jahr festhängen.
Teils feindliche Arbeitsumgebung
Zwei weitere Punkte, die Carter anspricht sind einerseits zu wenig Marketing, was sich in zu wenig Präsenz in den Medien ausdrückt, andererseits müsse Debian auch optisch attraktiver werden. Was Carter nicht anspricht ist, dass Debian oft eine feindliche Arbeitsumgebung sein kann, in der es Machtspiele gibt und es immer öfter eher um Political Correctness und den Code of Conduct geht als um den eigentlichen Code. Angesichts der ganzen Probleme ist es erstaunlich, dass das Projekt so gut funktioniert, wie es das tut, jedoch wäre mehr möglich, wenn die Last auf mehr Schultern verteilt wäre und der Code im Vordergrund steht.
In den letzten Tagen geisterte eine Sicherheitslücke durch die Medien, die auf den Namen BootHole getauft wurde und die Katalognummer CVE-2020-10713 erhielt. Dort hieß es beispielsweise, es seien Millionen (potenziell sogar Milliarden) Geräte betroffen und das unter Linux wie unter Windows und auch dann, wenn Secure Boot eingeschaltet sei.
Wenn das Kind erstmal im Brunnen ist…
Das ist so weit alles richtig. Was dann aber im Text nur beiläufig erwähnt wird, ist, dass zur Ausnutzung der Lücke Root-Rechte benötigt werden. Hat ein Angreifer aber bereits Root-Rechte, kann er machen, was er möchte.
GRUB2-Konfiguration manipuliert
Was war passiert? Die Sicherheitsfirma Eclypsium hatte im April 2020 eine Lücke entdeckt, die über die Manipulation der Konfigurationsdatei grub.cfg des Bootloaders GRUB2 oder generell bei Maschinen mit aktiviertem Secure Boot das Einschleusen von Schadcode ermöglicht. Die technischen Hintergründe vermittelt der Artikel There’S A Hole In The Boot.
Zwei Hacks notwendig
Schadcode im Bootprozess ist sehr gefährlich, da sind wir uns einig. Dort installierte Malware wie etwa ein Bootkit kann unter Umständen lange unentdeckt bleiben und ermöglicht uneingeschränkte Kontrolle der befallenen Geräte. Aber wie bereits erwähnt, muss man zur Manipulation der Datei grub.cfg Root-Rechte besitzen, die normalerweise nur durch einen vorausgehenden Hack zu erhalten sind.
GRUB2 ist meist signiert
Der Zusammenhang mit Secure Boot entsteht dadurch, dass GRUB2 bei allen großen Distributionen mit Secure Boot signiert ist. Dazu verwenden Distributionen eine kleine Datei, die als Shim bezeichnet wird. Dieser enthält den Code, um den Bootloader zu verifizieren. Dieser Shim wird beim Start gegen die UEFI-CA von Microsoft verifiziert, bevor der Shim den GRUB2-Bootloader lädt und verifiziert.
Heap-Overflow
Ist die grub.cfg entsprechend manipuliert, kann per BootHole Code eingeschleust werden, da der Parser in GRUB2 nicht ordnungsgemäß beendet wird, wenn ein Fehler entdeckt wird, was zum erzeugen von Pufferüberläufen im Heap-Datenbereich genutzt werden kann. Ein Angreifer kann dadurch bereits vor dem eigentlichen Start des Systems Code ausführen. auf diesem Weg kann beispielsweise Ransomware untergeschoben werden.
8,2 von 10
Das ist zweifelsohne eine gefährliche Lücke, die deshalb auch mit 8.2 von 10 möglichen Punkten beim CVSS-Index bewertet wurde. Die Angaben zur tatsächlichen Gefährdung sind aber nach meinem Dafürhalten mal wieder weit übertrieben und kommen mit markigen Überschriften dem Marketing von Eclypsium zugute.
Weitere Lücken entdeckt
Aber die Beschäftigung von allen großen Distributoren mit dem Problem förderte weitere sieben Sicherheitsprobleme bei GRUB2 ans Licht, die gleich mit beseitigt werden konnten. Angepasste Versionen von GRUB2 sind teilweise bereits erstellt und in Kürze einspielbar.
Lücke gefährlich – Gefährdung gering
Wir müssen uns wegen BootHole um unsere privaten Rechner wohl kaum Sorgen machen, denn zwei notwendige Attacken erscheinen hier nicht lohnenswert. Cyber-Gangster kennen weniger aufwendige Wege, unsere Rechner in ihre Botnetze zu integrieren. Rechner mit sensiblen Informationen im Enterprise-Umfeld sollten über geeignete Maßnahmen wie TPM oder PureBoot den Bootprozess absichern. Oder seht ihr das anders?
Seit dem unsäglichen gewaltsamen Tod von George Floyd und dem damit einhergehenden Erstarken der »Black Lives Matter«-Bewegung schwappt eine Welle von Meldungen durchs Netz, die von Dutzenden Projekten besonders aus dem Bereich Open Source berichtet, die ihre Webseiten und ihren Code nach politisch unkorrekten Bezeichnungen durchforsten und diese medienwirksam umformulieren.
Schwarz und Weiß
Allen voran GitHub, dass seinen Master-Zweig in Main umbenennen will, da der Begriff Master Assoziationen an die koloniale Zeit der Sklavenhaltung wecke. Dabei ist die Diskussion nicht neu, bereits 2018 gab es ein Plädoyer gegen Master und Slave als Bezeichnung für ein Abhängigkeitsverhältnis bei Datenbanken und anderswo.
Andere Beispiele sind Whitelist und Blacklist oder White Hats und Black Hats. Dabei kommen jeweils die Guten ins Töpfchen und die Schlechten ins Kröpfchen. Auch bei Festplatten sind Master und Slave für primäre und sekundäre Platten gängige Begriffe. Wenn das so weitergeht, müssen bald auch der »Master Bedroom« und der universitäre Master-Abschluss umbenannt werden.
Latenter Rassismus
Warum diese Bezeichnungen ursprünglich so gewählt wurden und ob sie einem allgegenwärtigen latenten Rassismus entspringen, muss jeder für sich selbst entscheiden. Ich würde das nicht mal in Abrede stellen wollen. Klar ist auch, dass es vermutlich in vielen Fällen gleichwertige oder gar bessere Bezeichnungen gibt. So vermittelt die Bezeichnung Main für den Hauptzweig eines GitHub-Repositories die gleiche Bedeutung wie Master.
Politisch korrekt bei Open Source
Politische Korrektheit ist ja nicht neu im Open-Source-Bereich. Social Justice Warriors sorgten im letzten Jahr dafür, dass Linus Torvalds seine nicht immer feine und manchmal auch verletzende Wortwahl ändern musste, obwohl die Mehrzahl der Entwickler mit dem rauhen Ton des Chefs umzugehen wussten. Auch der Name GIMP für GNU Image Manipulation Program wurde als anstößig empfunden, was den Fork Glimpse ins Leben rief.
Der Mohr als Symbol
Auch in deutschen Landen gab und gibt es Bestrebungen gegen Alltagsrassismus. Namen wie »Mohren Apotheke« oder der »Sartotti Mohr« als überkommenes rassistisches Symbol sind nicht mehr opportun und gelten als diskriminierend. Der Mohrenkopf gehört schon länger der Vergangenheit an und heißt nun brav Schokokuss.
Ob die Agenda der Streiter für politische Korrektheit gutzuheißen ist oder nicht, sei dahingestellt, das muss jeder für sich selbst entscheiden. Ich frage mich eher, wem soll das alles helfen? Beim Mohren wie beim Master geht es darum, dass dunkelhäutige Menschen Anstoß an den Begriffen nehmen könnten.
Ich glaube nicht, dass ein dunkelhäutiger Mitbürger beim Betreten einer Apotheke, die den Mohren im Namen führt, an Rassismus denkt. Genauso wenig werden sich vermutlich People of Color durch die Verwendung von Begriffen wie Master oder Blacklist davon abhalten lassen, zu einem Open-Source-Projekt beizutragen.
Gutes Marketing
Die Umbenennungen, die gerade zeitlich opportun vorgeschlagen und vorgenommen werden, helfen keinem einzigen Menschen aus der »Black Lives Matter«-Bewegung. Sie helfen lediglich, Unternehmen und Projekten, sich in einem guten Licht darzustellen. Die Diskussion im Netz darüber verläuft kontrovers. neben Befürwortern gibt es auch starke Kritik, die sogar in einer Petition Ausdruck findet.
Ob mit den Umbenennungen der bestimmt vorhandene latente Rassismus abgebaut werden kann, wage ich ebenfalls zu bezweifeln. Wie denkt ihr darüber?
Gerade erst hat Microsoft auf seiner Entwicklerkonferenz Build Erweiterungen für das Windows Subsystem for Linux in zweiter Version bekannt gegeben und setzt dabei einen Linux-Kernel ein. Wenige Tage vorher hatte Microsoft-Präsident Brad Smith offiziell eingestanden, sein Unternehmen habe Open Source Anfang des Jahrhunderts falsch eingeschätzt.
Paulus oder doch Saulus?
Irgendwann könnte man geneigt sein, Microsoft ihre Wandlung vom Saulus zum Paulus abzukaufen, doch dann rupft man dieses zarte Pflänzchen mit Stiel und Stumpf wieder aus. So geschehen in den letzten Tagen. Der Konzern aus Redmond änderte den Namen des Frameworks Xamarin.Forms im Rahmen der Integration in die .Net-Umgebung zu MAUI. Dabei hat man – wissentlich oder nicht – übersehen, dass es bei Linux bereits zwei durch KDE verbundene Projekte gleichen Namens gibt. Da ist einerseits die Distribution Maui, andererseits MauiKit, das, wie der neue Namensvetter, ebenfalls ein Framework zur Erstellung von Nutzerschnittstellen darstellt.
Microsoft was on the wrong side of history when open source exploded at the beginning of the century, and I can say that about me personally
Brad Smith, President, Microsoft
Ich will Microsoft nicht unterstellen, hier absichtlich und provokativ gehandelt zu haben. Allerdings, wenn es ein Versehen war, dann sollte man in Redmond mal ordentlich mit dem eisernen Besen durch die Rechtsabteilung fegen. Die ist vermutlich größer als die Entwicklerteams der meisten Linux-Projekte und hat offensichtlich übersehen, dass MAUI als KDE-Projekt bereits seit 2014 als Wortmarke geschützt ist.
Der Affront machte natürlich schnell die Runde und löste besonders auf GitHub rege Diskussionen aus. Das kann Microsoft natürlich nicht gefallen, da GitHub im Sommer 2018 von Microsoft übernommen wurde.
Diskussion unterdrückt
Die vielen Kommentare wurde in der Folge fast alle als Off-Topic versteckt und Microsoft-Mitarbeiter David Ortineau hinterließ seine Microsoft-E-Mail-Adresse, um die Diskussion von der Plattform zu verlagern. Als das nichts nutze, wurde der Thread als »too heated« geschlossen.
Die Entwickler von MAUI (MauiKit, Maui Apps) äußerten sich auf ihrer Webseite und eröffneten ebenfalls eine Diskussion auf GitHub, die zwar zwischenzeitlich für Nichtbeteiligte wurde, aber offiziell als Thread zur Klärung der Angelegenheit benannt wurde.
Wir dürfen gespannt sein, wie die Angelegenheit beigelegt wird. Wird Microsoft seine Marktmacht versuchen durchzusetzen oder Kleinbeigeben? Was glaubt ihr?
