JPEG-XL ist ein Bildformat, welches anderen Bildformaten in vielen Aspekten – zumindest auf dem Papier – überlegen ist. Andere Browserhersteller als Apple waren bisher allerdings nicht von einer Unterstützung zu überzeugen. Dies könnte sich für Firefox und Chrome ändern.

Nightly-Versionen von Firefox bieten bereits seit Mai 2021 eine experimentelle Unterstützung für das Bildformat JPEG-XL, kurz: JXL, welche über about:config aktiviert werden kann, indem der Schalter image.jxl.enabled per Doppelklick auf true gesetzt wird. Auch wenn der Schalter in Beta- sowie finalen Firefox-Versionen ebenfalls zur Verfügung steht, ist eine Aktivierung auf diesen Kanälen nicht möglich. Google hat seine experimentelle Unterstützung für JPEG-XL im Februar 2023 wieder aus Chrome entfernt. Im Gegensatz dazu unterstützt Apple für macOS und iOS das Bildformat JPEG-XL seit Safari 17 im September 2023.

Große Unternehmen wie Meta, Adobe, Shopify und weitere sind große Unterstützer von JPEG-XL, da hiermit gegenüber aktuell unterstützten Bildformaten, einschließlich WebP und AVIF, weitere Reduzierungen der Dateigrößen bei gleichbleibender Qualität oder höhere Qualität ohne Erhöhung der Dateigrößen von Bildern möglich sind.

Anfang September 2024 hat Mozilla eine Aktualisierung seiner Position bezüglich JPEG-XL vorgenommen, welche Hoffnung auf eine Unterstützung auch in anderen Browsern als Safari machen darf.

Demnach liegt Mozillas größtes Bedenken im erhöhten Angriffsvektor, den der über 100.000 Zeilen schwere Multithreaded C++-Code des Referenz-Decoders mit sich bringt. Man habe in den letzten Monaten allerdings produktive Unterhaltungen mit dem JPEG-XL-Team von Google Research gehabt, welches sich bereit erklärt habe, sein Fachwissen einzusetzen, um einen sicheren, leistungsfähigen, kompakten und kompatiblen JXL-Decoder in Rust zu entwickeln und diesen Decoder in Firefox zu integrieren. Ein in Rust geschriebener Decoder würde das Risiko und damit auch Mozillas Bedenken erheblich reduzieren. Gelingt dies und erfüllt Mozillas Anforderungen, würde Mozilla diesen in Firefox ausliefern.

Hierin stecken nicht nur gute Nachrichten für Firefox-Nutzer, sondern auch für Nutzer von Google Chrome sowie sämtlichen anderen auf Chromium basierenden Browsern. Denn Google würde keinen JXL-Decoder entwickeln und zu Firefox beitragen, würden sie nicht selbst auch JPEG-XL unterstützen wollen.

Der Beitrag Neue Hoffnung für Unterstützung von Bildformat JPEG-XL (JXL) in Firefox und Chrome erschien zuerst auf soeren-hentzschel.at.

Mit Common Voice stellt Mozilla den weltweit größten öffentlichen Datensatz menschlicher Stimmen bereit – kostenlos und für jeden nutzbar. Mozilla hat Version 19.0 seines Datensatzes veröffentlicht.

Der Markt für Spracherkennung wird von den ganz großen Namen kommerzieller Anbieter dominiert: Amazon, Apple, Google, Microsoft. Darum hat Mozilla im Jahr 2017 das Projekt Common Voice gestartet. Mit Common Voice bietet Mozilla eine kostenlose Alternative an, zu der jeder beitragen kann und die jedem zur Verfügung steht. Damit möchte Mozilla Innovation und Wettbewerb in der Sprachtechnologie auf Basis von Maschinenlernen fördern.

Mit dem nun veröffentlichten Common Voice Corpus 19.0 wächst der deutschsprachige Datensatz von 1.431 auf 1.436 Stunden an. Wer bereits den Common Voice Corpus 18.0 besitzt, kann wie immer auch nur ein sogenanntes Delta Segment mit den Unterschieden zur Vorversion herunterladen. Für Deutsch würde das den Download von 33,6 GB auf 108 MB reduzieren.

Insgesamt deckt Mozilla Common Voice mit der neuen Version jetzt 131 Sprachen mit insgesamt 32.584 aufgenommenen Stunden ab, was Mozilla Common Voice zum vielfältigsten mehrsprachigen Sprachkorpus der Welt macht.

Zum Download der Mozilla Common Voice Datensätze

Der Beitrag Mozilla veröffentlicht Common Voice Corpus 19.0 erschien zuerst auf soeren-hentzschel.at.

Mit der meisten Texterkennungssoftware wandel man beispielsweise eine Bilddatei mit Text in bearbeitbaren Text um. NormCap hingegen könnte man hingegen mit einem Screenshot-Tool vergleichen, dass Text erstellt.

Nehmen wir an, man lässt sich folgendes Bild mit Okular auf dem Bildschirm anzeigen.

Nun will man beispielsweise das, was auf dem Schild steht, in Textform haben. Mit Normcap markiert man einfach wie bei einem Screenshot-Tool den gewünschten Bereich und der erkannte Text wird in die Zwischenablage eingetragen.

Was aber, wenn man auch den Dateinamen in Textform haben will, den Okular oben anzeigt? Man markiert einfach mit NormCamp den betreffenden Bereich des laufenden Programms und auch in diesem Fall wird der erkannte Inhalt in Textform in der Zwischenablage gespeichert. Als Quelle dient also nicht eine bestimmte Datei, sondern das was der Bildschirm anzeigt.

Für die Texterkennung setzt NormCap auf Tesseract, was als ziemlich zuverlässig gilt. Bei meinen bisherigen Tests musste ich daher den erkannten Text auch wenig bis gar nicht verbessern. Vermutlich dürfte aber auch Tesseract in bestimmten Fällen an seine Grenzen stoßen.

Mit Mozilla Social betreibt Mozilla seine eigene Instanz des dezentralen sozialen Netzwerks Mastodon. Über die geschlossene Betaphase wird es allerdings nicht mehr hinausgehen. Mozilla hat die Einstellung von Mozilla Social bekanntgegeben.

Was ist Mastodon?

Mastodon ist eine Microblogging-Plattform oder auch soziales Netzwerk, welches vor allem mit X, ehemals Twitter, verglichen werden kann, oder auch dem neuen Threads von Meta. Der große Vorteil von Mastodon ist seine dezentrale Natur: Das Netzwerk gehört keinem einzelnen Unternehmen. Stattdessen kann jeder seine eigene Instanz mit eigenen Moderationsregeln und eigener Oberfläche betreiben. Die dafür verwendete Software ist Open Source und frei verfügbar.

Was ist Mozilla Social?

Mit mozilla.social betreibt auch Mozilla eine Mastodon-Instanz. Diese war im März 2023 für Mozilla-Mitarbeiter online gegangen, seit Mai 2023 konnte man sich auf die Warteliste für einen geschlossenen Betatest setzen lassen. Ursprünglich hatte Mozilla große Pläne für Mastodon. So wurde zunächst nicht nur eine modifizierte Version von Mastodon mit ebenfalls angepasster Elk-Oberfläche eingesetzt, welche ein paar Dinge anders als andere Instanzen machte, auch investierte Mozilla in die Mastodon-App Mammoth für iOS und für Android sowie iOS waren sogar eigene Apps in Entwicklung.

Das langsame Ende von Mozilla Social – mit zwischenzeitlicher Hoffnung

Die Dinge änderten sich schlagartig im Februar 2024, als Laura Chambers neue CEO von Mozilla wurde. Das Zurückfahren der Investitionen in Mozilla Social zählte praktisch zu ihren ersten Amtshandlungen. Die Entwicklung der eigenen Apps wurden eingestellt und der Betrieb der Mastodon-Instanz auf den minimalen Wartungsaufwand zurückgefahren. Eigene Anpassungen wurden rückgängig gemacht und Elk zugunsten der Standard-Oberfläche wieder gestrichen. Für die Mastodon-Instanz gab es seit dem lediglich die regulären Updates der Mastodon-Software.

Im April 2024 kam noch einmal kurz Hoffnung auf. Denn die zunächst eingestellte und unter anderem Namen privat weiterentwickelte Android-App wurde doch wieder als Mozilla-Produkt weiterentwickelt. Außerdem startete die Entwicklung einer Mastodon-Erweiterung für Firefox und Chrome. Ende Mai 2024 wurden hier aber schon wieder alle Aktivitäten eingestellt, einen Monat später war auch für Android-App endgültig Schluss.

Offizielle Einstellung von Mozilla Social

Nachdem es dann in den letzten Monaten auffällig still um Mozilla Social wurde und auch nichts in Richtung überfällige Öffnung der Mastodon-Instanz für alle Nutzer zu hören war, folgte vor wenigen Tagen die offizielle Ankündigung dessen, was man bereits ahnen konnte: Mozilla Social wird eingestellt. Am 17. Dezember 2024 ist Schluss. Nutzer der Mastodon-Instanz mozilla.social müssen bis dahin ihre Daten gesichert haben, ansonsten verlieren sie den Zugriff.

Der Beitrag Mastodon-Instanz Mozilla Social wird eingestellt erschien zuerst auf soeren-hentzschel.at.

Mozilla hatte Anfang September offizell angekündigt, die Unterstützung von Firefox für die veralteten Betriebssysteme Windows 7, Windows 8, macOS 10.12, macOS 10.13 sowie macOS 10.14 bis März 2025 zu verlängern. Nun ist klar: Für den Mail-Client Thunderbird gilt dies nicht.

Worüber ich bereits im Juli berichtete, hat Mozilla Anfang September offiziell gemacht: Die veralteten Betriebssysteme Windows 7, Windows 8, macOS 10.12, macOS 10.13 sowie macOS 10.14 werden bis März 2025 weiter unterstützt. Dies geschieht durch eine Verlängerung der Lebenszeit von Firefox ESR 115.

Wie seitens der MZLA Technologies Corporation nun angekündigt wurde, gilt dies nicht für Thunderbird. Zwar behält man sich noch die theoretische Möglichkeit vor, ein weiteres Thunderbird 115.15.x-Update zu veröffentlichen, aber über Thunderbird 115.15 wird es nicht hinaus gehen. Das bedeutet: Die Unterstützung für die oben genannten Betriebssysteme gilt für Thunderbird damit offiziell und ab sofort als eingestellt.

Begründet wird dies einerseits mit den geringeren personellen Ressourcen, die das Thunderbird-Team im Vergleich zu Firefox hat. Zum anderen liegt der Anteil der Thunderbird-Nutzer mit Windows 7 oder Windows 8 nicht wie bei Firefox bei immer noch 10,5 Prozent, sondern „nur“ noch bei ca. 6 Prozent. Und das bei einer ohnehin sehr viel kleineren Nutzerbasis als Firefox sie hat.

Die Downloadseite wird vorerst weiterhin den Download von Thunderbird 115 für Nutzer von Windows 7 oder Windows 8 anbieten. Dies wird sich aber ändern, sobald zukünftige Sicherheits-Updates, die für Thunderbird relevant sind, nur noch für Thunderbird 128 und höher bereitgestellt werden.

Die alten macOS-Betriebssysteme werden in der Ankündigung weder explizit erwähnt noch gibt es für diese eine separate Download-Option auf der Thunderbird-Website. Deren Nutzeranteil dürfte daher als verschwindend gering anzusehen sein.

Der Beitrag Thunderbird: Unterstützung für veraltete Betriebssysteme wird nicht verlängert erschien zuerst auf soeren-hentzschel.at.

Die MZLA Technologies Corporation hat mit Thunderbird 128.2.1 ein Update für seinen Open Source E-Mail-Client veröffentlicht. Kurz darauf erschien Thunderbird 128.2.2.

Neuerungen von Thunderbird 128.2.1 und Thunderbird 128.2.2

Mit dem Update auf Thunderbird 128.2.1 hat die MZLA Technologies Corporation ein Update für seinen Open Source E-Mail-Client veröffentlicht. Das Update bringt mehrere Korrekturen für die Versionsreihe 128, welche sich in den Release Notes (engl.) nachlesen lassen. Das Update auf Thunderbird 128.2.2 bringt weitere Verbesserungen, welche die Release Notes (engl.) auflisten.

Update: Mittlerweile ist auch Thunderbird 128.2.3 erschienen und macht eine Änderung des Updates auf Thunderbird 128.2.2 rückgängig.

Der Beitrag Thunderbird 128.2.1 und 128.2.2 veröffentlicht erschien zuerst auf soeren-hentzschel.at.

Mozilla hat Firefox 130.0.1 veröffentlicht und behebt damit mehrere Probleme der Vorgängerversion.

Download Mozilla Firefox 130.0.1

Ein Fehler wurde behoben, der verursachte, dass AVIF-Bilder nur schwarz dargestellt worden sind, wenn Firefox mit GCC kompiliert worden ist. Dies betrifft Firefox unter Linux aus Paketverwaltungen, die nicht von Mozilla verwaltet werden. Der von Mozilla kompilierte Firefox war von diesem Fehler nicht betroffen.

Ein sogenannter Deadlock wurde behoben, der bei Ausführung des Firefox-Profilers aufgetreten ist, wenn eine aktuelle Windows 11 Insider Preview genutzt worden ist. Stabile Windows-Versionen waren von diesem Problem nicht betroffen, hätten es aber potenziell in der Zukunft sein können.

Firefox in der Saraiki-Sprache hat Texte mancher Oberflächen-Elemente fälschlicherweise von links nach rechts statt von rechts nach links geschrieben.

Die UserMessaging-Unternehmensrichtlinie kann jetzt auch zur Deaktivierung von „Firefox Labs“ genutzt werden, einem neuen Abschnitt in den Firefox-Einstellungen seit Firefox 130, um zukünftige Features vorab aktivieren zu können.

Den Buttons im Dialog zur Personalisierung der Pocket-Empfehlungen auf der Firefox-Startseite konnte direkt nach dem Browserstart das Styling fehlen. Hierbei handelt es sich um ein neues Feature von Firefox 130, welches derzeit schrittweise in den USA und Kanada ausgerollt wird.

Dazu kommt noch eine Hand voll Änderungen in Zusammenhang mit der KI-Generierung von Alternativtexten für Bilder in PDF-Dateien, einem weiteren neuen Feature von Firefox 130, welches derzeit schrittweise ausgerollt wird.

Der Beitrag Mozilla veröffentlicht Firefox 130.0.1 erschien zuerst auf soeren-hentzschel.at.

Ananke ist eines der bekannteren Themes (veröffentlicht unter der MIT-Lizenz) für den statischen Website-Generator Hugo. Für dieses Theme wird nun ein neuer Betreuer gesucht.

Wer also Lust hat das Projekt zu übernehmen, kann in dem genannten Repository ein Issue erstellen um sein Interesse bekunden.

Ich habe selbst nichts mit Ananke zu tun, da ich ein eigenes Theme nutze. Es wäre aber schade, wenn dieses Theme verschwinden würde.

In meinem heutigen Beitrag kommentiere ich den 2024 State of Open Source Report und vergleiche die enthaltenen Ergebnisse mit meinen persönlichen Erfahrungen.

Der 2024 State of Open Source Report (im Folgenden auch als Bericht oder Report bezeichnet) wurde von der Firma OpenLogic in Zusammenarbeit mit der Open Source Initiative (OSI) und der Eclipse Foundation erstellt. Der Bericht kann hier als PDF kostenlos heruntergeladen werden (der Haken für den Empfang von Kommunikation muss nicht gesetzt werden). Ich werde in diesem Text häufig auf den Bericht als Quelle verweisen, sodass ich euch empfehle, den Report ebenfalls verfügbar und im besten Fall gelesen zu haben. Seitenangaben beziehen sich auf das PDF mit dem Bericht.

Transparenzhinweis: Ich arbeite als Technical Account Manager für die Firma Red Hat. Meine Arbeit beeinflusst meinen Blick auf den Bericht. Dieser Kommentar stellt ausschließlich meine persönliche Sicht dar.

Informationen zum Bericht

Im Zeitraum vom 10. Oktober bis 8. November 2023 wurde weltweit eine anonyme Umfrage durchgeführt, welche insgesamt 2046 Antworten erhielt (siehe S. 4-6). Es findet sich darin kein Hinweis, ob die Umfrage repräsentativ ist. Es werden jedoch Angaben darüber gemacht, aus welcher Weltregion, Unternehmensgröße und Job-Rolle die Antworten stammen, um diese einordnen zu können.

Nutzung und Verbreitung von Open Source in Unternehmen

Es freut mich zu lesen, dass 95 Prozent der Antworten belegen, dass der Anteil an Open Source in den an der Umfrage teilnehmenden Unternehmen gestiegen (67,57 %) oder gleichgeblieben (27 %) ist (siehe S. 7). Auffällig ist allerdings auch, dass im Mittleren Osten 22,22% angaben, dass der Einsatz von Open Source zurückgegangen ist. Unternehmen, die gar keine Open-Source-Software einsetzen, haben vermutlich nicht an der Umfrage teilgenommen. Der Bericht macht dazu keine Aussage.

Auf Seite 8 findet sich die Aussage, dass 40 % aus der C-Level-Abteilung (z.B. CEO, CTO, CIO, CFO, etc.) angegeben haben, dass der Anteil an Open Source gleichgeblieben ist, während über 60% der Teilnehmer aus technischen Rollen eine Zunahme von Open Source sehen. Laut Bericht deutet dies auf eine mögliche Entfernung bzw. Trennung der Führung von der Basis hin. Dieser Ansicht mag ich mich nicht anschließen, da immerhin 58,46% der Führungskräfte ebenfalls eine Zunahme von Open Source in ihren Unternehmen sehen; das ist von den 60% der technischen Rollen doch nun wirklich nicht weit weg.

Interessant finde ich die genannten Gründe für den Einsatz von Open Source in Unternehmen (siehe S. 9-10). Ein wenig betrübt es mich, dass knapp 37 % „Keine Lizenzkosten“ und „Kostenminimierung“ als wichtigstes Argument für den Einsatz von Open Source nannten; hat Open Source in meinen Augen doch so viel mehr zu bieten, während sich das Ziel der Kostenminimierung nicht in jedem Fall erreichen lässt.

Meiner persönlichen Erfahrung nach verschieben sich die Aufwände in vielen Fällen lediglich. So stellten einige Organisationen fest, dass der Einsatz kostenlos verfügbarer Open-Source-Software mit einem höheren Personalbedarf bzw. einem erhöhten Aufwand für Wissensaufbau und Fehleranalysekompetenz einhergeht. Hier finden sich zum Teil die Kosten wieder, die man zuvor für Lizenzen und externen Support aufgewendet hat. Es gibt hier keine pauschal gültige Empfehlung. Jedes Unternehmen muss für sich selbst bewerten, ob es das erforderliche Personal selbst aufbauen bzw. einstellen kann oder ob der Einkauf externer Unterstützung in Zeiten von Fachkräftemangel nicht doch günstiger ist.

Macht man sich von externem Wissen abhängig, läuft dies dem Ziel entgegen, sich mit Open Source unabhängiger von einzelnen Herstellern machen zu wollen. Hier ist darauf zu achten, wie viel Auswahl an Anbietern am Markt besteht.

Ich nehme allerdings ebenfalls wahr, dass die wirtschaftliche Situation in vielen Unternehmen angespannt ist und kann das Ziel, Kosten zu reduzieren, nachvollziehen. Ich hoffe darauf, dass Unternehmen, die Open Source zur Kostensenkung einführen, auch die weiteren Vorteile, wie z.B. die Vermeidung von Vendor Lock-ins sowie offene Standards und Interoperabilität erkennen und zu schätzen lernen. Die zuletzt genannten Punkte sind immerhin 21 % der Befragten heute schon wichtig.

Herausforderungen beim Einsatz von Open Source

Wie bereits im vorangegangenen Abschnitt erwähnt, ist für den Einsatz von Open Source die Verfügbarkeit des notwendigen Wissens und entsprechende Fertigkeiten notwendig. Immerhin 38 % der befragten Unternehmen sehen es als eine Herausforderung an, das notwendige Wissen und die Fähigkeiten zum effizienten Einsatz von Open Source im Unternehmen verfügbar zu machen (S. 13). Dabei versuchen sie, dies auf unterschiedlichen Wegen verfügbar zu machen. Das Diagramm auf Seite 14 zeigt, dass die Mehrheit mit 45% auf Training des eigenen Personals setzt. Weitere 38% versuchen, Personal mit dem benötigten Wissen einzustellen.

Ich arbeite aktuell selbst in einem Unternehmen, in dem die Fort- und Weiterbildung der eigenen Mitarbeiter einen hohen Stellenwert besitzt. Ich freue mich sehr, dass mein Unternehmen mich aktiv dabei unterstützt, mein Wissen aktuell zu halten und in verschiedenen Bereichen auszubauen.

Ohne einen Beleg zur Hand zu haben, meine ich mich zu erinnern, dass die Qualifizierung bestehenden Personals für ein Unternehmen häufig günstiger ist, als neues Personal einstellen und einarbeiten zu müssen. Falls ihr dazu eine gute Quelle habt, teilt sie mir doch bitte in den Kommentaren mit.

Updates und Patches

Auf Seite 13 des Berichts findet sich die Aussage, dass es für 40 % aller Umfrageteilnehmer eine große bis sehr große Herausforderung darstellt, die Systeme und Anwendungen auf einem aktuellen Stand (Patchlevel) zu halten.

Nach meiner Erfahrung zählen ein geringer Automatisierungsgrad, unzureichende Testprozeduren und eine zu starre Aufbauorganisation mit komplizierten und langwierigen Abstimmungsprozessen zu den größten Problemen in diesem Bereich. Wenn Wartungsfenster zur Installation von (Sicherheits-)Updates mit 3-6 Monaten Vorlauf angekündigt und geplant werden müssen und es keinen Prozess für schnelle Notfallupdates gibt, kann man halt nicht innerhalb von 72 Stunden reagieren und Schwachstellen schließen. Wenn die Kommunikation zwischen Betriebs- und Anwendungs-Team rein über Ticketsystem läuft, hat man zwar einen sauberen Prozessablauf mit Genehmigungs- und Prüfschritten; werden die Schritte jedoch alle manuell ausgeführt, darf man sich nicht wundern, wenn Updates vier Tage statt vier Stunden brauchen.

Noch immer begegnen mir im Gespräch Szenarien, wo Anwendungsteams nicht über Testsysteme und Testpläne verfügen. Die Folgen eines Updates/Patches lassen sich nur direkt in Produktionsumgebung prüfen. Bei Fehlern kommt es dann sofort zu einer Beeinträchtigung des Dienstes und der Stresslevel steigt. Wo es bereits an der Fähigkeit mangelt, Änderungen zeitnah zu verifizieren, fehlt oft auch die Möglichkeit, auf einen zuletzt als funktionierend bekannten Stand zurückzurollen. Hier bleibt nur der Weg voran unter Einsatz aller verfügbaren Ressourcen, bis das Problem behoben oder das Unternehmen insolvent ist.

Nicht immer ist es ganz so dramatisch. Häufig löst mangelnde Automation einen langwierigen Abstimmungsprozess aus. Viele Personen müssen Zeit einplanen, um diverse Schritte im Prozessablauf manuell auszuführen, zu testen und zu dokumentieren. Schnell sind 3,6 kg Excel-Dateien erstellt, das Update aber immer noch nicht abgeschlossen.

Ich erinnere mich an die schöne Zeit zwischen 2011 und 2014. Unser damaliger stellvertretender Abteilungsleiter hatte die Idee, DevOps auszuprobieren. Dazu wurden Teams aus Entwicklern und Systemadministratoren gebildet, die nun gemeinsam für den Betrieb und die Verfügbarkeit bestimmter Anwendungen verantwortlich waren. Statt den auf Papier dokumentierten Verantwortungsübergängen und dem daraus häufig folgenden Hin- und Herschiebens des schwarzen Peters saßen wir jetzt gemeinsam in einem Boot und hatten gemeinsame Ziele. Wir lernten dabei die Sicht- und Arbeitsweise der jeweils anderen Job-Rolle kennen und zu verstehen. Und im gemeinsamen Dialog, gelang es uns Automationsprozesse zu entwickeln, um Updates schneller und erfolgreicher durchführen zu können. Leider überlebte dieses Modell die Zeit nicht. Heute ist mir bekannt, dass mit dem Wechsel dieses Modells auch die alten Probleme zurückkehrten und deutlich weniger Updates durchgeführt werden.

Oft liegt die Verantwortung für die Installation von Updates/Patches beim Betrieb. Jedoch ist nur das Anwendungsteam in der Lage, die korrekte Funktionsfähigkeit der Anwendung/des Dienstes zu beurteilen. Auch wenn manche Abteilungsleiter es nicht gerne hören, es geht am besten gemeinsam, mit kurzen Abstimmungswegen über Team- und Abteilungsgrenzen hinweg.

Der zweite Schlüssel zum Erfolg ist Automation. Lasst den Automaten die einzelnen Prozessschritte ausführen, welche in der Regel wie folgt aussehen:

1. Anwendung bzw. Dienste stoppen
2. Updates/Patches installieren
3. System neu starten
4. Anwendung bzw. Dienste starten
5. Anwendung/Dienst auf korrekte Ausführung testen
6. Bei Fehlschlag –> Rollback bzw. bei Erfolg –> Update erfolgreich

Zeit und Energie, die hier investiert werden, zahlen sich in aktuellen Systemen mit weniger Sicherheitslücken aus. Schafft einen Raum, in dem sich eure Experten aus Systemadministration und Anwendungsentwicklung austauschen und abstimmen können.

Selbstverständlich haben die Qualität der vom Hersteller bereitgestellten Updates ebenfalls einen großen Einfluss auf den Erfolg von Patchinstallationen. Sollte es hier wiederholt Probleme geben und keine Besserung in Sicht sein, ist ggf. ein Wechsel des Anbieters in Erwägung zu ziehen. Doch bevor ihr euch Hals über Kopf in die Migration stürzt, denkt daran, dass das Gras auf der anderen Wiese stets grüner wirkt, als es ist. Es geht nicht ohne ausführliche Tests.

Ich wünsche allen, die sich für Updates und Patches Nächte und Wochenenden um die Ohren schlagen müssen, dass sich die Situation für euch bessert und sich dies im nächsten Open Source Statusbericht ablesen lässt.

Wartung von End-of-Life Versionen

Manche nennen es den Giftschrank, andere die Schmuddelecke. Gemeint sind damit Betriebssystem-Releases und Anwendungen, die das Ende ihres Lebenszyklus erreicht oder schon überschritten haben. Laut Seite 13 des Berichts ist dies für 42 % der Umfrageteilnehmer ein Thema.

Die Gründe warum diese Systeme noch existieren, lauten häufig sehr ähnlich. Fast immer läuft eine geschäftskritische Anwendung darauf,

• Von der im Unternehmen niemand mehr weiß, wie sie funktioniert, um sie auf ein neues Betriebssystem zu migrieren
• Für deren Migration keine Ressourcen verfügbar sind
• Mit der komplizierte und langwierige Abstimmungsprozesse zur Migration verbunden sind; niemand will das Ding anfassen
• Die für keine aktuellere Betriebssystem-Version zertifiziert ist

Im hier kommentierten Bericht wird auf Seite 15 ausgewiesen, dass 22 % der Befragten noch CentOS einsetzten, dessen Release 7 seit dem 30. Juni 2024 End-of-Life (EoL) ist. In der Umfrage kommt es sogar auf Platz 3 der am häufigsten eingesetzten Distributionen.

Egal ob man nun EoL-Betriebssysteme oder EoL-Laufzeitumgebungen betrachtet, die Lösung ist stets dieselbe. Die dazugehörige Anwendung muss zuerst auf einer neueren und unterstützten Version laufen, bevor die alte abgeschaltet werden kann. Dazu müssen Teams in der Lage sein, Anwendungen neu deployen und das Deployment testen zu können. Auch hier helfen Testsysteme, -prozeduren und Automation. Auch hierbei ist es unerlässlich, dass Betrieb und Anwendungsteams zusammenarbeiten, um den Erfolg der Migration sicherzustellen. Je schneller Feedback-Loops und Abstimmungsprozesse sind, desto schneller sind notwendige Prozeduren etabliert. Die Zeit für Releasewechsel lässt sich so signifikant verkürzen. Ressourcen sind damit schneller frei und können für innovative Entwicklungsprojekte genutzt werden.

Leider erlebe ich häufig, dass Abteilungen nur in ihrem eigenen Bereich nach Lösungen suchen und den Kontakt zu anderen Abteilungen meiden, ja beinahe scheuen. Doch ist dies kein technisches Problem. Es ist eine organisatorische Herausforderung, die angegangen werden muss. Es liegt doch im Interesse aller Beteiligten, regelmäßig wiederkehrende Releasewechsel schnell und störungsarm abwickeln zu können.

In meinem beruflichen Alltag erlebe ich häufig, dass In-Place-Upgrades als Allheilmittel angesehen werden. Ich hingegen bin kein großer Freund davon. Sie sind der vermeintlich einfache Weg, doch führen sie zur dunklen Seite der Macht. Ein In-Place-Upgrade aktualisiert das Betriebssystem inkl. der installierten Bibliotheken und Laufzeitumgebungen. Es befreit nicht von der obligatorischen Aufgabe, die darauf laufenden Anwendungen im Anschluss zu testen. Stellt man dabei Fehler fest, gibt es häufig kein Zurück mehr. Eine Ausnahme bilden hier virtuelle Umgebungen, bei denen man zuvor einen Snapshot der virtuellen Maschine erstellen kann.

Wer eine Anwendung immer nur mit In-Place-Upgrades von einem Release auf das nächste rettet, verliert mit einer größeren Wahrscheinlichkeit die Fähigkeit, die Anwendung sauber neu zu deployen. Man tut sich hiermit keinen Gefallen.

Ich bin der Überzeugung, dass Organisationen in der Lage sein müssen, ihre geschäftskritischen Anwendungen mit einem definierten Zustand automatisiert ausrollen zu können. Dies unterstützt Releasewechsel, erleichtert den Auf- und Abbau von Testumgebungen sowie die Verifizierung von Fehlern und das Nachstellen von Bugs. Anwendungen können so auch deutlich leichter und schneller gegen neuen Bibliotheken und Laufzeitumgebungen getestet werden. Es lohnt sich, Zeit zum Schärfen der Axt zu investieren, bevor man mit dem Fällen der Bäume beginnt. Oder anders ausgedrückt, wer keine Zeit hat, den Zaun zu reparieren, weil er mit Kühe einfangen beschäftigt ist, wird nie zum Melken kommen.

Open Source Distributionen

In dieser Kategorie auf Seite 15 listet der Bericht die Linux-Distributionen auf, die von den Umfrageteilnehmern verwendet werden. Ubuntu führt diese Liste an und liegt mit 46 % vor Debian mit 23%. Platz 3 geht an CentOS mit 22%. Den undankbaren vierten Platz belegt Amazon Linux mit knapp 20%. Die noch recht neue Distribution CentOS Stream findet sich auf Platz 13 mit 9,5%.

Ich habe diese Werte mit denen aus dem State of Open Source Report von 2023 verglichen. Ubuntu hat im Vergleich um 27 % zugelegt (Platz 1 mit 29% in 2023). Debian kam 2023 mit 16,63% auf Platz 6 hinter CentOS Stream mit 16,74%. Die Plätze 2 und 3 wurden 2023 von Alpine Linux (21,1%) und Oracle Linux (19,72%) belegt. CentOS kam damals mit 15% auf Platz 8.

Der Bericht von 2024 spekuliert, dass Red Hat’s Änderung beim Zugriff auf den RHEL Quelltext und das EoL von CentOS mitverantwortlich für diese Veränderungen sind, kann jedoch keine klaren Belege dafür liefern. Laut Bericht sind die Linux Wars noch nicht entschieden und wir können auf den kommenden Bericht gespannt sein.

Es hat mich überrascht, dass RHEL und SLES es gar nicht in das Ranking geschafft haben. Unter Berücksichtigung, dass die Kostenreduktion in diesem Bericht die Hauptmotivation für den Einsatz von Open Source darstellt, lässt sich ggf. erklären, warum Distributionen gerade nicht hoch im Kurs stehen, die kostenpflichtige Support-Subskriptionen für den produktiven Einsatz voraussetzen.

Ich freue mich schon darauf, herauszufinden, wie dieses Ranking im nächsten Bericht aussieht.

Cloud-Native Open Source Technologies

Das Diagramm auf Seite 17 zeigt das Ranking der wichtigsten Cloud-Native Open Source Technologies für die Umfrageteilnehmer. Platz 1 wird von Docker mit 44,6 % eingenommen, gefolgt von Kubernetes mit 33,61 %.

Der große Vorsprung von Docker vor Podman mit 16,6 % hat mich ein wenig überrascht. Ich hätte den Abstand nicht als so groß eingeschätzt. Hier interessiert mich, welche Vorteile die Nutzer in Docker gegenüber Podman sehen. Leider macht der Bericht hierzu keine Aussage. Ich selbst nutze Podman unter Debian, Fedora und RHEL. In Debian stehen ungünstigerweise nur ältere Podman Releases zur Verfügung, denen wichtige Funktionen fehlen. Dies ist in meinen Augen eine Erklärung, warum Podman gerade in diesen Distributionen wenig genutzt wird. Dies ist allerdings nur wilde Spekulation meinerseits. Ich kann dies nicht belegen.

Für mich ebenfalls unerwartet ist OpenStack mit knapp 18 % sowie OKD und Rancher mit jeweils unter 10%. In diesem Bereich leide ich vermutlich an Betriebsblindheit. Wenn man bei Red Hat arbeitet, kann man leicht den Eindruck gewinnen, dass die ganze Welt nur noch OpenShift macht.

Ich freue mich darauf, diese Kategorie über die nächsten Jahre zu beobachten und zu sehen, wie sich Podman entwickelt, wofür ich eine gewisse Vorliebe habe.

Automations- und Konfigurations-Management

Wer die Kategorie Ansible in diesem Blog kennt, weiß bereits, dass ich mich gerne mit Ansible beschäftige. So freut es mich zu sehen, dass Ansible im betrachteten Bericht auf Seite 25 Platz 1 mit 30% belegt. Überraschend finde ich hingegen, dass 27% angaben, keinerlei Open Source Automations- bzw. Konfigurationsmanagement zu verwenden. Der Bericht führt dies auf Antworten aus jungen Unternehmen zurück, die (noch) keine Notwendigkeit für Automation sehen. Ich möchte diesen Unternehmen empfehlen, frühzeitig eine Automation First Philosophie zu entwickeln, da ich überzeugt bin, dass sich ein konsequenter Einsatz von Automations- und Konfigurationsmanagementwerkzeugen schnell auszahlt.

Unter den Systemadministratoren liegen Ansible (40 %) und Puppet (36%) als beliebteste Werkzeuge nah beieinander. Es ist immer gut, Auswahl und Wettbewerb zu haben. Ich freue mich über den Anteil von Puppet, gerade weil ich in den Nachrichten nur noch wenig Notiz davon nehme.

Salt liegt bei unter 10 % und ich habe auch schon längere Zeit nichts mehr von diesem Projekt gehört. Schade, die Architektur von Salt finde ich ganz interessant.

Im aktuellen Bericht nutzen knapp 23 % Terraform und der Lizenzwechsel zeigt noch keine große Abwanderung zu dessen Fork OpenTofu. Da die Datenerhebung jedoch Ende 2023 durchgeführt wurde, kann der Bericht eine etwaige Nutzerabwanderung noch nicht darstellen. In 2024 hat IBM die Übernahme von Hashi Corp bekannt gegeben. Ich bin gespannt, wie es mit den Produkten und deren Nutzung weitergeht. Hoffentlich gibt der nächste Bericht erste Einblicke.

Fazit

Durch die Arbeit in einem großen IT-Unternehmen mit einem starken eigenen Portfolio fällt es leicht, eine Betriebsblindheit für die Entwicklungen außerhalb des eigenen Kosmos zu entwickeln. Berichte wie der 2024 State of the Open Source Report helfen, der Betriebsblindheit entgegenzuwirken.

Ich habe nicht alle Kategorien des aktuellen Berichts im Detail betrachtet, sondern mir diejenigen herausgepickt, die mein persönliches Interesse ansprechen. Darüber in diesem Blog zu schreiben, hilft mir, über den Bericht und meine Erfahrungen zu reflektieren. Und wenn euch dieser Kommentar ebenfalls gefällt, freue ich mich umso mehr.