Der alternative App-Store für freie Android-Software F-Droid wird vom Open Technology Fund (OTF) mit 396.000 US-Dollar unterstützt. Die Gelder stammen aus dem FOSS Sustainability Fund des OTF.

Open Source Software ist eine Schlüsseltechnologie, um viele der aktuellen Herausforderungen in Europa zu lösen – das war die zentrale Botschaft des EU Open Source Policy Summit 2025. Auch SUSE nahm vergangene Woche an der Konferenz in Brüssel teil und unterstützt ab sofort die Arbeit des OpenForum Europe als offizieller Supporter. Damit wollen wir dazu beitragen, die Wettbewerbsfähigkeit, Innovationskraft und digitale Souveränität in der EU durch den Einsatz von Open Source zu stärken.

Quelle

Linux-Server und Netzwerkdienste effektiv und umfassend vor Angriffen schützen - von physischer Sicherheit über Verschlüsselung und 2FA bis hin zu SELinux.

Mirantis hat die nach eigenen Angaben erste Distributed-Container-Management-Environment-Lösung (DCME) vorgestellt, die als zentrale Schaltstelle und Single Point of Control für Cloud-native…

Am 23. Februar 2025 wird ein neuer Bundestag gewählt. Aufgrund der vorgezogenen Wahl, des verkürzten Wahlkampfes und der aktuell dominierenden Migrationsdebatte drohen andere wichtige Themen aus dem Fokus zu geraten. Wir haben uns daher die einzelnen Wahlprogramme angeschaut und stellen hier die wichtigsten Vorschläge der demokratischen Parteien rund um die Themen digitale Souveränität und Open Source vor.

Quelle

Wie einfach ist es heute, einen Canon-Drucker unter Linux zum Laufen zu bringen? Es ist sehr einfach, wie ihr in diesem Erfahrungsbericht lesen könnt.

Tails, The Amnesic Incognito Live System, schließt in seiner neuesten Ausgabe 6.12 einige kritische Sicherheitslücken. Tails nutzt für seine Zwecke das das Tor-Netzwerk.

Zum 40. Geburtstag der Free Software Foundation werden zahlreiche Andenken versteigert - unter anderem die originale Gnu-Zeichnung. (FSF, Richard Stallman)

Tails 6.12 schließt weitere Lücken, die bei einem externen Audit durch die Non-Profit-Organisation Radically Open Security aufgedeckt wurden.

Quelle

Bereits Ende Oktober 2024 hatte ich mich bei Loops.video registriert. Loops, von den Machern von Pixelfed (dansup), soll "DIE Alternative zu TikTok werden" – ein großes Ziel, das man sich gesetzt hat. Ich war gespannt.

Docker und Kubernetes bieten für Spring-Boot-Anwendungen eine leistungsstarke Grundlage, um Anwendungen flexibel, skalierbar und effizient in verschiedenen Umgebungen auszuführen. Wie das geht, zeigt dieser Workshop. (Golem Karrierewelt, Server-Applikationen)

Wie der Titel andeutet, geht es in diesem Text um Release-Zyklen von Betriebssystemen und Zeiträume, in denen diese unterstützt werden. Ich möchte meine großartige Idee mit euch teilen und bin daran interessiert, zu erfahren, wie ihr darüber denkt.

Transparenzhinweis 1: Ich arbeite als Technical Account Manager bei Red Hat. Zuvor habe ich mehrere Jahre als Systemadministrator mit Red Hat Enterprise Linux (RHEL) gearbeitet. Dieser Text spiegelt ausschließlich meine persönliche Meinung wieder.

Transparenzhinweis 2: „Großartige Idee“ ist Code für eine Idee, die andere als Spinnerei, Wahnsinn, verrückt oder anderweitig dispektierlich bezeichnen würden. Mein bester Freund und ich hatten in unserem Leben schon viele großartige Ideen. Wir haben sie bisher alle überlebt. ;-) Nehmt das hier Geschriebene daher vielleicht nicht bierernst und mit einer Prise Ironie und Humor.

Wann? Wie oft? Wie lang?

Ca. alle 2-5 Jahre ist bei den bekannten Linux-Distributionen mit einem neuen Major-Release zu rechnen. Für jedes Major-Release bekommt man bis zu 10 Jahre und länger Unterstützung. Der Umfang der Unterstützung schwankt dabei je nach Support-Phase deutlich.

Die folgenden Abbildungen geben einen kleinen Überblick.

Betrachtet man diese Release-Zyklen und Unterstützungszeiträume, ist es problemlos möglich, ein Release zu überspringen, während sich die Unterstützungszeiträume für das alte und neue Release überschneiden.

Was sagen verschiedene Teams zu neuen Releases?

Die folgende Liste gibt eine Auswahl von Aussagen und Kommentaren wieder, die ich während der letzten 15 Jahre immer wieder in ähnlicher Form gehört habe.

• „Schon wieder ein neues Major-Release. Jetzt müssen wir schon wieder testen, ob unsere Prozesse und Automations-/Konfigurations-Skripte noch funktionieren.“
• „Hoffentlich müssen wir das Betriebskonzept nicht anpassen.“
• „Endlich, wir warten schon lange auf neue Versionen wichtiger Bibliotheken, Laufzeitumgebungen und Datenbankmanagementsysteme.“
• „Wir würden ja gern auf Version B deployen, die IT gibt uns aber nur Version A.“
• „Mit jedem Major-Release ändert sich irgendwas und wir müssen uns schon wieder anpassen.“
• „Unsere Anwendung läuft gut auf Version A. Wir möchten skalieren, aber die IT gibt uns jetzt nur noch Version B. Wir wissen nicht, ob und wie unsere Anwendung darauf läuft.“
• „Wir testen gerade noch die letzte Patch-Version unserer Anwendung auf Version A. Der Test der folgenden Patch-Version drängt schon. Wir haben keine Zeit und keine Leute, um die Anwendung auch noch auf Version B zu testen.“
• „Kaum sind wir mit der Migration unserer Anwendung von Version A auf Version B fertig, drängt uns der IT-Betrieb schon wieder, wir müssten auf Version C migrieren.“
• „Vor lauter Betriebssystemwechseln kommen wir kaum dazu, unsere Anwendung weiterzuentwickeln.“
• „Es dauert so lange, bis alle Anwendungen von Version A auf Version B migriert wurden, dass Version B schon fast wieder End-of-Life ist.“
• „Es erzeugt enorme Aufwände mehrere Betriebssystemversionen parallel zu betreiben.“

Ihr habt hoffentlich erkannt, dass Version A und Version B hier stellvertretend für ein Release einer beliebigen Linux-Distribution stehen. Nimmt man die Aussagen zusammen, kann man den Eindruck gewinnen, dass ein neues Major-Release nicht bei allen Menschen in einer IT-Organisation Freude auslöst.

Und wenn wir nun ein Release auslassen?

• Das Betriebskonzept muss seltener überprüft und ggf. angepasst werden
• Die Anwendungsteams müssen ihre Anwendung seltener migrieren
• Automations-/Konfigurations-Skripte müssen seltener angepasst werden
• Die Anzahl von Migrations- und Veränderungs-Projekten kann reduziert werden
• Geringerer Aufwand senkt die Kosten

Lassen wir außer Acht, dass ich einen Punkt bewusst unterschlage, sind die Vorteile offenbar deutlich und überwiegen alle potenziellen Nachteile mit Leichtigkeit. Oder nicht? Also warum wollt ihr unbedingt jedes Major-Release mitnehmen? Bitte schreibt mir eure Gründe dafür gern in die Kommentare.

Aber Jörg, du weißt doch, wie das so ist…

Ja, natürlich ist mir bewusst, dass es sich bei großen Unternehmen um komplexe Systeme handelt, in denen aus verschiedenen Bereichen sehr unterschiedliche Anforderungen an Anwendungen und IT-Dienste gestellt werden.

So reicht das Spannungsfeld regelmäßig von „Never touch a running system (even when it’s 20 years old)“ bis hin zu „We need the latest and greatest to be successful in our business“.

Manche Anwendungen sind nur für den Betrieb auf ausgewählten Betriebssystemversionen zertifiziert, Abhängigkeiten zu Bibliotheken und Laufzeitumgebungen müssen eingehalten werden.

Doch habt ihr wirklich mal zusammen mit allen Beteiligten bewusst überlegt, ob es ohne einschneidende Nachteile möglich ist, ein Major-Release zu überspringen, um die oben skizzierten Vorteile zu nutzen? Oder nehmt ihr jedes Release mit, weil das schon immer so gemacht wurde?

Dies ist wirklich _____ großartige Idee

Also, was haltet ihr von dieser Idee? Machbar? Gut? Oder doch nur eine Schnapsidee? Was spricht dagegen?

Bitte nutzt die Kommentare unter diesem Text, um mich und alle Leserinnen und Leser wissen zu lassen, ob dieser Ansatz Vorteile hat oder welche zwingenden Gründe ihn unrealistisch erscheinen lassen.

Und wenn ihr euch nur mal den Frust von der Seele schreiben wollt, warum es überall klemmt und hakt und wie es besser sein könnte, ist das natürlich auch in Ordnung.