Kritische Schwachstellen in OpenWrt
OpenWrt ist eine freie Linux-basierte Firmware für Router und andere Netzwerkgeräte.
OpenWrt ist eine freie Linux-basierte Firmware für Router und andere Netzwerkgeräte.
Das CalyxOS-Projekt hat die Version 7.2.2.0 seines Google-freien Android-basierten Betriebssystems veröffentlicht.
Beim Open Document Format handelt es sich um einen Standard für Office-Dokumente. Dem gegenüber steht das Microsoft-Format OOXML. Dieser Artikel klärt über die Hintergründe auf.


Mecklenburg‑Vorpommern stärkt seine digitale Unabhängigkeit und führt eine landesweite Kollaborationsplattform auf Basis von Nextcloud ein. Das Projekt soll langfristig zehntausende Beschäftigte erreichen und die Kontrolle über zentrale IT‑Strukturen sichern. Die neue Lösung wird vollständig durch die DVZ M‑V GmbH betrieben. Das Land nutzt eigene Server und behält damit die Hoheit über Daten und Abläufe. Die […]
Der Beitrag Digitale Souveränität: Mecklenburg‑Vorpommern setzt auf eigene Nextcloud‑Plattform erschien zuerst auf fosstopia.
Die neue Claude‑Desktop‑App erreicht jetzt auch Linux. Anthropic öffnet damit erstmals den Weg des beliebten Entwickler-KI-Assistenten für Ubuntu und Debian. Entwickler erhalten eine native Lösung ohne Bastelei, die in der Beta jedoch noch nicht alle Funktionen besitzt. Die Anwendung jedoch schon viele Bereiche ab. Chat, Cowork und Code stehen bereit. Dazu kommen parallele Sitzungen und […]
Der Beitrag Claude kommt auf Linux: Neue Desktop‑App startet durch erschien zuerst auf fosstopia.
Das Fedora Projekt zieht die Notbremse. Die Diskussion um einen speziellen KI‑Entwickler‑Desktop wird vorerst beendet und der Community‑Initiativen‑Prozess pausiert vollständig. Auslöser war ein Vorschlag für eine vorkonfigurierte Umgebung für lokale KI‑Workloads. Die Idee sollte Hardware‑Beschleunigung vereinfachen und Entwicklern einen schnellen Einstieg bieten. Doch die Reaktionen fielen sehr unterschiedlich aus. Streitpunkte reichten von der Rolle proprietärer […]
Der Beitrag Fedora stoppt KI‑Desktop und überdenkt Community‑Prozesse erschien zuerst auf fosstopia.
In diesem Artikel thematisiere ich, wie sich die Anzahl der entdeckten Schwachstellen in den letzten Jahren entwickelt hat und ob wir noch von Zero-Day sprechen, oder eher von Zero-Hour oder Zero-Minute.
Ich werde darstellen, warum es in meinen Augen bis auf wenige Ausnahmen nicht mehr angemessen ist, nur noch einmal im Jahr oder quartalsweise zu patchen und unter Schmerzen eingeübte Prozesse heute nicht mehr zeitgemäß erscheinen.
Anschließend werde ich euch bitten, eure Erfahrungen anonym mit mir zu teilen. Ich erhoffe mir, so einen besseren Überblick über die Situation da draußen in den Rechenzentren, Serverräumen und IT-Betriebseinheiten zu gewinnen. Mehr dazu unten im Text.
Die Anzahl der pro Jahr gemeldeten Schwachstellen (CVE) steigt rasant, wie folgendes Diagramm in Abbildung 1 verdeutlicht.

Während sich die Anzahl der CVE pro Jahr erstmalig im Zeitraum von 2016 bis 2017 von ca. 6.500 auf ca. 14.500 mehr als verdoppelt hat, kam es zuletzt in den Jahren 2021 bis 2024 zu einer Verdopplung. Diesmal hat sich die Anzahl jedoch von ca. 20.000 auf knapp über 40.000 gesteigert. Und diese Zahl steigt weiter. So wurden für das erste Quartal 2026 bereits 15.176 CVE gezählt.
Wenn sich dieser Trend fortsetzt, werden wir das Jahr 2026 mit deutlich mehr als 60.000 registrierten CVE abschließen. Das wären 5.000 CVE/Monat oder 164 CVE/Tag.
Gleichzeitig sinkt die mittlere Zeit von der Veröffentlichung eines CVE bis zu einem Exploit, wie Abbildung 2 zeigt.

Lag die mittlere Zeit zwischen der Veröffentlichung eines CVE und des Exploits 2023 noch bei über 4 Monaten, ist diese auf 21,5 Tage im Jahr 2025 gesunken. Für 2026 wird diese sogar mit nur noch 3 Stunden angegeben.
Noch bedrohlicher wirkt die Lage, wenn man sich ansieht, für wie viele CVE noch am gleichen Tag oder sogar vor deren Veröffentlichung ein Exploit bekannt wird (siehe Abbildung 3). Man spricht hier auch von Zero-Day-Exploits.

Im Jahr 2024 gab es für 47,9% der CVE einen Zero-Day-Exploit. Im Jahr 2025 war das bereits für mehr als die Hälfte der Fall, nämlich 53,6 %. Das Jahr 2026 ist noch in vollem Gange. Die Rate der Zero-Day-Exploits liegt mit bisher 76,9% nochmals deutlich höher.
Es wird für die Paketbetreuenden, Upstream-Entwickelnden und Software-Herstellenden Menschen immer herausfordernder, einen Patch bereitzustellen, bevor ein Exploit existiert und aktiv gegen verwundbare Systeme eingesetzt wird.
Aus meiner beruflichen Tätigkeit als Red Hat TAM und als Sysadministator bei verschiedenen Unternehmen ist mir bekannt, dass unterschiedliche Unternehmen und Organisationen sehr verschieden mit Schwachstellen und deren Behandlung umgehen.
Allen ist gemein, dass sie für ihre Anwendungen Wartungsfenster vereinbaren, in denen z.B. Sicherheitsaktualisierungen installiert werden, um vorhandene Schwachstellen zu schließen. Einige haben einen Patchday pro Jahr, manche patchen einmal im Quartal und wieder andere monatlich. Einzelne Unternehmen können dies sogar noch schneller.
Die einen haben regelmäßig wiederkehrende Wartungsfenster, die anderen müssen diese bei Bedarf anmelden. Einige haben schlanke Prozesse, einige nutzen Change-Management nach ITIL.
Um die Integrität, Verfügbarkeit und Vertraulichkeit der eigenen Informationssysteme und deren umgebener Infrastruktur zu schützen, sind zwei Grundsätze seit vielen Jahren allgemein bekannt:
Die beiden Grundsätze stehen nicht in einer Entweder-Oder-Beziehung. Sie sollten beide berücksichtigt werden.
In meinen Augen ist es längst nicht mehr zeitgemäß, Sicherheitsaktualisierungen jährlich oder quartalsweise zu installieren. Eine kleine Ausnahme mögen hier Systeme bilden, deren Nutzerkreis stark eingeschränkt ist und auf die ausschließlich über wenige sehr gut gesicherte Kanäle zugegriffen werden kann.
Um es deutlich zu sagen: „Für wochen- oder tagelange Change-Management-Prozesse bleibt keine Zeit. Wer weiterhin so arbeitet, riskiert die Informationssicherheit seiner Umgebung.“
Wer alle seine Systeme einmal im Monat wartet und neustartet, bewegt sich in meiner Wahrnehmung aktuell im Mittelfeld dessen, was man im Feld findet. Doch auch hierauf darf sich niemand ausruhen. Existiert zu einem CVE ein Exploit und ein Patch, erscheint es fahrlässig, bis zu einem Monat mit dessen Installation zu warten.
Leider fehlt etlichen Unternehmen bzw. Organisationen noch immer die Fähigkeit schnell festzustellen, ob ihre IT-Dienste korrekt ausgeführt werden. Patch-Management-Zyklen sehen hier meist vor, dass zuerst einige Systeme aktualisiert werden, dann wartet man 1-2 Wochen, ob jemand meckert und dann aktualisiert man die restlichen Systeme. Das ist nicht mehr zeitgemäß.
Aus der eingangs beschriebenen Bedrohungslage folgend muss das neue Ziel lauten, jedes individuelle System an jedem Tag aktualisieren und neustarten zu können. Die Funktion von IT-Diensten ist durch automatisierte Mechanismen wie z.B. Monitoring oder automatisierte Tests zu verifizieren, um schnell mit der nächsten Stage fortfahren zu können. Wer dieses Ziel noch nicht erreicht hat, sollte sich schnellstens auf den Weg machen. Selbst wenn die 100% unerreichbar scheinen, ist jedes System, das man schnell absichern kann, ein deutlich geringeres Risiko für die eigene Informationssicherheit.
Wo Sicherheitsaktualisierungen nicht zeitnah eingespielt werden können, lässt sich das Risiko durch Verteidigung in der Tiefe minimieren. Kommunikationsverbindungen von und zu betrachteten Systemen sind zu überwachen und ggf. zu limitieren. Doch auch diese Maßnahmen müssen schnell verfügbar und umsetzbar sein. Wer erst zwei Wochen diskutieren muss, ob man den Zugriff auf einen Dienst einschränken könne, müsse, sollte, handelt nicht angemessen.
Zusammenfassend sehe ich unklare Verantwortlichkeiten, langwierige Abstimmungsprozesse und manuelle Tätigkeiten als Gift und Risiko für die Informationssicherheit. Klare Strukturen, geklärte Verantwortlichkeiten und Automation sind kein nice-to-have, sondern ein MUSS.
Nun möchte ich von euch wissen: „Patcht ihr schon oder prozessiert ihr noch?“
Ich bin sehr daran interessiert zu erfahren, wie es in den Umgebungen meiner Lesenden und derer Bekannten zugeht. Daher freue ich mich sehr, wenn ihr (gern anonym) euer Patch-Management-Konzept, die Branche eures Unternehmens und die ungefähre Größe eurer Umgebung mit der Gemeinschaft bzw. mir teilt.
Evtl. werde ich eure Beispiele anonymisiert unter ausschließlicher Nennung der Branche (falls bekannt) in Vorträgen, Diskussion und weiteren Arbeiten zu diesem Thema verwenden. Bitte schreibt ausdrücklich dazu, wenn ihr dies nicht wünscht.
Ich freue mich auf eure Beiträge, Zusendungen und wenn ihr diesen Artikel in euren Netzwerken teilt.
Die Art, wie Menschen Software entdecken, hat sich grundlegend verändert. Wer ein Open-Source-Projekt veröffentlicht, rechnet oft damit, dass Entwicklerinnen und Entwickler es über klassische Suchmaschinen oder GitHub-Suchen finden. Doch in der KI-Suche nach Open-Source-Projekten gelten andere Regeln. KI-gestützte Systeme wie Perplexity, ChatGPT Search oder der KI-Modus von Google lesen, interpretieren und bewerten Inhalte auf eine andere Weise als herkömmliche Crawler. Projekte, die für Menschen gut dokumentiert sind, werden von diesen Systemen längst nicht immer gefunden oder empfohlen. Das betrifft besonders Linux-Projekte und Open-Source-Software, deren Dokumentation oft technisch präzise, aber für KI-Modelle schwer interpretierbar ist. Dieser Artikel zeigt, welche Faktoren darüber entscheiden, ob ein Open-Source-Projekt in der KI-Suche auftaucht, und welche konkreten Schritte die Sichtbarkeit nachhaltig verbessern.
Traditionelle Suchmaschinen folgen einem klaren Prinzip: Sie crawlen Seiten, analysieren Links und vergeben Rankings nach algorithmischen Kriterien. KI-basierte Suchsysteme funktionieren anders. Sie lesen Texte wie ein Mensch, ziehen Schlussfolgerungen und synthetisieren Antworten aus mehreren Quellen gleichzeitig.
Für Open-Source-Projekte bedeutet das einen strukturellen Nachteil. Eine README-Datei auf GitHub ist für Entwickler lesbar, für ein KI-Modell jedoch oft ein Rätsel aus Abkürzungen, Kommandozeilenbefehlen und implizitem Fachwissen. Das Modell kann den Kontext nicht vollständig herstellen und lässt das Projekt in einer Antwort schlicht weg.
Hinzu kommt ein weiterer Faktor: KI-Systeme bevorzugen Quellen, die mehrfach zitiert werden, in strukturierten Formaten vorliegen und auf bekannten Plattformen gehostet werden. Ein gut gepflegtes Projekt auf einer unbekannten Domain hat es deutlich schwerer als ein weniger aktives Projekt mit starker Community-Präsenz auf Reddit, Hacker News oder einschlägigen Technik-Blogs.
Die meisten Open-Source-Projekte dokumentieren, was ihre Software tut und wie sie installiert wird. Was fehlt, ist der Kontext: Warum existiert dieses Projekt? Welches Problem löst es besser als Alternativen? Für welche Zielgruppe ist es gedacht?
KI-Modelle beantworten Suchanfragen kontextuell. Wer fragt „Welches Tool eignet sich zum Monitoring unter Linux für kleine Teams?“, bekommt eine Antwort, die auf Projekten basiert, die genau diese Frage irgendwo in ihrer Dokumentation beantworten. Projekte, die nur Funktionen auflisten, tauchen in solchen Antworten nicht auf.
KI-Suchsysteme bevorzugen Inhalte, die auf Plattformen mit hoher Autorität gehostet werden oder von solchen Plattformen verlinkt sind. Ein Open-Source-Projekt, das ausschließlich auf GitHub lebt, fehlt in Diskussionen, Tutorials und Fachartikeln, die als Quellen dienen könnten.
Für die KI-Suche nach Open-Source-Software zählt nicht allein die Qualität des Codes. Entscheidend ist, ob glaubwürdige Drittquellen über das Projekt sprechen. Ein einzelner Artikel auf einem bekannten Linux-Blog, der das Projekt erwähnt und erklärt, kann mehr bewirken als hundert GitHub-Sterne.
Viele Projektwebseiten werden statisch generiert oder bestehen aus einfachen HTML-Seiten ohne strukturierte Daten. KI-Crawler haben Schwierigkeiten, solche Seiten in einen semantischen Zusammenhang zu setzen. Fehlende Schema-Markups, unklare Seitenhierarchien und das Fehlen von FAQ-Sektionen oder strukturierten Erklärungstexten verschlechtern die Chance, in einer KI-gestützten Antwort zu erscheinen.
Der erste Schritt ist eine Überarbeitung der bestehenden Dokumentation mit Blick auf semantische Klarheit. Statt einer reinen Funktionsliste sollte die Startseite oder README folgende Fragen beantworten: Was ist das Projekt in einem Satz? Welches spezifische Problem löst es? Für wen ist es geeignet? Was unterscheidet es von ähnlichen Projekten?
Diese Informationen müssen in fließendem, verständlichem Prosatext vorliegen, nicht nur als Stichpunkte. KI-Modelle extrahieren Bedeutung aus Sätzen, nicht aus Tabellen oder Befehlszeilen. Ein klar formulierter Einleitungsabsatz, der das Projekt in seinem Verwendungskontext beschreibt, ist wertvoller als eine vollständige Featureliste.
Wer möchte, dass ein Projekt in der KI-Suche nach Open-Source-Software empfohlen wird, muss dafür sorgen, dass vertrauenswürdige Quellen darüber berichten. Das bedeutet konkret: Gastbeiträge auf Technik-Blogs, Diskussionen auf Plattformen wie Hacker News, Beiträge in Foren der Linux-Community sowie Erwähnungen in Podcasts oder Newslettern.
Hier kommt auch die Frage der KI-Sichtbarkeit in der Suche ins Spiel, denn KI-Systeme werten nicht nur die eigene Projektseite aus, sondern aggregieren Informationen aus einem breiten Netz externer Quellen. Je mehr unabhängige Stimmen ein Projekt erwähnen und positiv beschreiben, desto wahrscheinlicher landet es in einer KI-generierten Empfehlung.
Für Projekte mit eigener Webpräsenz lohnt sich die Implementierung von strukturierten Daten nach Schema.org. Besonders relevant sind Typen wie SoftwareApplication, FAQPage und HowTo. Diese Markups helfen KI-Crawlern, den Inhalt korrekt zu kategorisieren.
Zusätzlich verbessern eine klare URL-Struktur, kurze Ladezeiten und eine gut lesbare Sitemap die Indexierungsqualität. FAQ-Sektionen auf der Projektwebseite sind besonders wirkungsvoll, da KI-Suchsysteme häufig gestellte Fragen direkt als Antwortquellen verwenden.
Open-Source-Projekten, die in der KI-Suche gefunden werden möchten, empfiehlt sich eine Kombination aus inhaltlichen und technischen Maßnahmen:
Inhaltlich sollte die Dokumentation regelmäßig aktualisiert und um Anwendungsbeispiele, Vergleiche mit Alternativen sowie Use-Case-Beschreibungen erweitert werden. Echte Nutzungsszenarien, etwa Wie setze ich dieses Tool in einer CI/CD-Pipeline unter Ubuntu ein?, beantworten genau die Fragen, die Nutzerinnen und Nutzer an KI-Systeme stellen.
Technisch gilt: Die Projektwebseite sollte eigenständig sein und nicht ausschließlich auf GitHub-gerenderte Markdown-Dateien setzen. Eine dedizierte Seite mit klarer Struktur, Metadaten und strukturierten Inhalten wird von KI-Systemen konsistenter indexiert als eine reine Repository-Seite.
Aus Sicht der Community-Strategie zahlt es sich aus, aktiv in Diskussionen präsent zu sein, auf Fragen in Foren zu antworten und das Projekt in relevanten Kontexten zu erwähnen. Jede glaubwürdige Erwähnung auf einer externen Plattform erhöht die Wahrscheinlichkeit, dass ein KI-Modell das Projekt als relevante Quelle einstuft.
Popularität gemessen in GitHub-Sternen oder Downloads korreliert nicht direkt mit der Sichtbarkeit in KI-Suchsystemen. Diese Systeme bevorzugen Projekte, über die in verständlicher Sprache auf zitierfähigen Plattformen berichtet wird. Ein Projekt mit 500 Sternen, über das ein bekannter Linux-Blog geschrieben hat, wird oft häufiger empfohlen als ein Projekt mit 5.000 Sternen ohne externe Berichterstattung.
Besonders wirkungsvoll sind Plattformen mit hoher inhaltlicher Autorität: technische Blogs, Fachmagazine für Entwickler, Diskussionsplattformen wie Hacker News sowie spezialisierte Foren der Linux- und Open-Source-Community. Darüber hinaus werden Inhalte aus StackOverflow, Reddit (in relevanten Subreddits) und Dokumentationsseiten mit klarer Struktur von KI-Systemen häufig als Quellen genutzt.
Eine Faustregel ist, die Hauptdokumentation bei jedem größeren Release zu überarbeiten und dabei sicherzustellen, dass Anwendungsbeispiele und Problemlösungsszenarien aktuell bleiben. KI-Systeme gewichten frische Inhalte positiv, besonders wenn sich die Funktionen des Projekts weiterentwickelt haben. Mindestens einmal im Quartal sollte geprüft werden, ob die zentralen Seiten noch den aktuellen Stand des Projekts widerspiegeln.
Der Beitrag KI-Suche und Linux: Open-Source-Projekte sichtbar machen erschien zuerst auf intux.de.
Mozilla hat eine offizielle Roadmap-Seite für Firefox veröffentlicht. Auf dieser können Nutzer schauen, an welchen Schwerpunkt-Themen Mozilla als Nächtes für seinen Browser sowohl am Desktop als auch auf Android und iOS arbeitet. Dieser Artikel fasst die aktuellen Pläne zusammen.
Mozilla hat eie neue Roadmap-Seite veröffentlicht, auf der man die wichtigsten Funktionen sieht, an denen Mozilla aktuell arbeitet. Dieses ist in verschiedene Kategorien aufgeteilt und nennt für jedes Feature separat, ob es sich um eine Verbesserung für den Desktop, Android oder iOS handelt.
Es folgt eine Zusammenfassung der Dinge, die kürzlich abgeschlossen worden sind oder an denen Mozilla Stand heute arbeitet.
Unter dem internen Projektnamen „Nova” arbeitet Mozilla an einem neuen Design für den Desktop, Android und iOS. Darüber, wie das neue Design am Desktop aussehen wird, hatte ich weltweit als erstes berichtet.
Ebenfalls exklusiv berichtet hatte ich von einer Teilen-Funktion für Sammlungen von Tabs, Tab-Gruppen und Lesezeichen im Desktop-Firefox.
Das Ändern von Tastaturbefehlen ist bereits möglich, wenn man die entsprechende Firefox-Seite kennt, soll nach weiteren Verbesserungen aber ein offiziell unterstütztes Feature am Desktop und dann auch leichter zugänglich werden.
Tab-Gruppen werden am Desktop bereits seit dem letzten Jahr unterstützt, seit Firefox 152 auch auf Android und auch eine Unterstützung auf iOS ist geplant.
Ähnlich zum bereits existierenden Bild-im-Bild-Modus für Videos soll es einen solchen Modus am Desktop auch für Dokumente geben.
Für den Desktop, Android und iOS nennt Mozilla Verbesserungen bei der Autovervollständigung sowie für den Desktop eine vielseitigere Such- und Adressleiste.
Das Aufteilen, Zusammenfügen und neu Anordnen von PDF-Dateien am Desktop wird bereits unterstützt, ebenso wie weitere Sprachen für die Übersetzungsfunktion auf iOS.
Die vom Desktop bereits bekannte Integration eines kostenlosen VPNs wird es in Zukunft auch auf Android und iOS geben.
Tab-Umgebungen sind ein einzigartiges Feature, welches kein anderer Browser besitzt und in Firefox für den Desktop seit vielen Jahren existiert, dort aber erst über eine versteckte Option oder eine Erweiterung aktiviert werden müssen. Mozilla plant Verbesserungen dieser Funktion, um diese dann standardmäßig für alle Nutzer bereitzustellen. Die Mozilla-Erweiterung Firefox Multi-Account Containers wird dadurch abgelöst werden.
Da es für Mozilla nicht möglich ist, Erweiterungen in Firefox für iOS anzubieten, arbeitet Mozilla an einem nativen Werbeblocker für seinen iOS-Browser.
Weiter nennt Mozilla ein neues Design für private Fenster sowie einen Zugangsschlüssel-Support für Firefox Sync am Desktop. Ein neues Design der Einstellungen wurde bereits ausgeliefert.
Mit dem sogenannten Intelligenten Fenster am Desktop gibt es einen neuen KI-Modus für Firefox. Dieses wird nach Setzen auf eine Warteliste bereits schrittweise ausgerollt.
Auf iOS soll es die Möglichkeit geben, der KI eine Frage via Sprachaufnahme zu stellen und darauf dann eine schriftliche Antwort zu erhalten.
Für den Desktop nennt Mozilla Verbesserungen der Engine, welche das Laden von Websites schneller machen soll. Dies umfasse die Priorisierung von QUIC und IPv6, wo möglich.
Außerdem plant Mozilla für Android sowohl einen Stromsparmodus als auch einen Ressourcen-Monitor, der anzeigt, welche Tabs die meisten Systemressourcen belegen.
Firefox für den Desktop soll beim Besuch von Websites darauf hinweisen, wenn diese bei einem bekannten Online-Datenleck auftaucht.
Der Fingerprinting-Schutz soll am Desktop und auf Android verbessert werden. Außerdem soll es sowohl am Desktop als auch auf Android ein Widget für den Startbildschirm geben, welches anzeigt, wie viele Tracker blockiert worden sind.
Hier nennt Mozilla neue Web-APIs wie Wasm-JS-Promise, verzögerte Modulauswertung und WebTransport, neue Medienfunktionen wie HDR auf Windows und Linux und die Unterstützung des Bildformats JPEG XL sowie erweiterte CSS-Funktionen wie attr(), corner-shape, shape() und scrollgesteuerte Animationen. All diese Dinge sind für den Desktop und Android geplant. Auf iOS setzt Firefox, wie alle anderen Browser, auf die Webkit-Engine von Safari und hat damit keinen Einfluss auf unterstützte Web-Features.
Der Beitrag Mozilla veröffentlicht umfangreiche Firefox-Roadmap für alle Plattformen erschien zuerst auf soeren-hentzschel.at.
Apple Container ermöglicht den Betrieb von Linux-Containern auf Macs und ist speziell für die M-Chips optimiert. Jetzt ist die Version 1.0 erschienen, die erstmals persistente Linux-Umgebungen mit tiefgreifender Host-Integration bietet.
Der Linux Coffee Talk, das lockere Format rund um Linux, Open Source und Technik im Alltag. Ohne Hype, ohne Clickbait, dafür mit echten Einordnungen der Meldungen, Meinungen und einem Überblick über die wichtigsten FOSS-/Linux-News aus Juni 2026. Wir sprechen über Linux Distros, Tools, Datenschutz, Nerd-Themen und alles, was uns Linux-User bewegt. Perfekt für alle, die […]
Der Beitrag Linux Coffee Talk 6/2026 erschien zuerst auf fosstopia.
Der Linux Coffee Talk ist das entspannte Monatsformat bei fosstopia. Hier fassen wir die spannendsten Ereignisse und Entwicklungen der letzten Wochen für Euch zusammen und ordnen sie bestmöglich ein. Also schnappt euch einen Kaffee, Tee oder Euer Lieblingsgetränk, macht es euch gemütlich und lasst uns den Juni 2026 Revue passieren.
Der Beitrag Podcast: Linux Coffee Talk 6/2026 erschien zuerst auf fosstopia.
Ultramarine Linux 44 steht zum Download bereit, die standardmäßig KDE Plasma in der aktuellen Version 6.7 verwendet. Zudem gibt es Editionen mit den Desktop-Umgebungen GNOME 50, Budgie 10.10 und Xfce 4.20. Dabei setzt die Linux-Distribution auf den Kernel 7.0.
Der neue CEO-Bench, entwickelt von Forschern der Princeton University, testet erstmals, wie sich KI-Agenten als CEO eines fiktiven Unternehmens bewähren.
Vom 19. bis 23. Mai 2026 ist eine OSBA-Delegation nach Kenia gereist und hatte vor Ort zahlreiche Austauschtermine zum Thema Open Source und digitale Souveränität. Mit dabei waren Vertreter aus dem europäischen Open-Source-Ökosystem aus den Bereichen Cloud, Identity Management, Office, Hosting, Groupware, Betrieb und Transformation.
Aktuell schreibt die Dokumentation vor, dass KI-Coding-Agenten, die zum Linux Kernel beitragen, eine Attribution benötigen. Nun diskutieren Kernel-Entwickler den Sinn solcher Attribution.
