Sporadisch gibt Christian F. Schaller, Direktor für Softwareentwicklung bei Red Hat und Fedora Entwickler, in seinem Blog einen Überblick, was bei Fedora in der Roadmap steht. So geschehen vor einer Woche unter dem Titel Looking ahead at 2025 and Fedora Workstation.
KI bei Fedora
Als erstes Thema wählt er Artificial Intelligence. Fedora hat, wie einige andere Distributionen auch, den Stellenwert einer vom Open-Source-Gedanken geprägten KI erkannt. Es verwundert nicht, dass Fedora dabei auf IBMs Granite 3.0 zurückgreift, gehört doch Fedoras Mutter-Distribution Red Hat mittlerweile zu IBM.
Granite 3.0 als die aktuellste Ausgabe von IBMs LLMs ist Open Source und steht unter einer Apache-Lizenz. Auf dieser Basis soll ein Code-Assistent angeboten werden. Ein weiteres Tool, das Fedora einsetzen möchte, ist RamaLama, das die lokale Verwaltung und Bereitstellung von KI-Modellen durch die Verwendung von OCI-Containern vereinfachen will. Zudem soll garantiert werden, dass die Einrichtung von beschleunigter KI in Toolbx einfach möglich ist.
Wayland
Wie nicht anders zu erwarten, steht auch Wayland weit oben auf der Agenda der Fedora-Entwickler. Das vergangene Jahr wird zwar vielfach und mit Recht als das Jahr bezeichnet, in dem Wayland endgültig Fuß gefasst hat. Allerdings gab es hinter den Kulissen teils heftige Auseinandersetzungen darüber, was Wayland-Protokolle sein sollten und was nicht. Dadurch wurde die Veröffentlichung von Protokollen teils stark ausgebremst, da viele wichtige Protokolle zu lange mit den Flags staging oder unstable verharren.
Doch nicht nur Uneinigkeit darüber, was Wayland leisten soll und was nicht, bremste die Entwicklung aus. Auch der in Open Source allgegenwärtige Mangel an Leuten, die bei der Überprüfung von Protokollen oder der Bereitstellung von Referenzimplementierungen helfen, spielt dabei eine Rolle. Hinzu kommt, dass bei Wayland meist mehrere Leute aus mehreren verschiedenen Projekten benötigt werden, um ein Protokoll der Allgemeinheit zu übergeben. Schaller sieht aber hier Licht am Ende des Tunnels, denn es sollte nicht mehr allzu lange dauern, bis alle wichtigen Protokolle verabschiedet sind. Was dann noch folgt, seien eher Nischen-Protokolle, die kein großes Interesse mehr erwecken.
Flatpak und Portals
Fedora kann Verbesserungen bei Flatpak vermelden, nachdem das USB-Portal, das aus Mitteln des deutschen Sovereign Tech Fund für GNOME finanziert wurde, Upstream integriert wurde. Damit ist ein sicherer Zugriff von Sandbox-Anwendungen auf USB-Geräte gewährleistet. Noch in Arbeit ist die Installierbarkeit von System-Daemons über Flatpak. Lennart Poettering leistet die Vorarbeit für systemd, während Christian Hergert die Integration auf seine To-do-Liste gesetzt hat.
PipeWire
Alle wichtigen Funktionen, die PipeWire aufweist, sind jetzt grundsätzlich in gutem Zustand. Deshalb wird sich die Entwicklungsgeschwindigkeit künftig etwas verlangsamen. Die PulseAudio-Unterstützung funktioniert zuverlässig und es kommen nur noch sehr wenige Fehlerberichte rein. Auch das Feedback aus der Pro-Audio-Community besagt, dass PipeWire für die meisten Leute etwa in Bezug auf die Latenz genauso gut oder besser funktioniert als JACK.
Die Entwickler arbeiten noch an der Weiterentwicklung der Videounterstützung, obwohl diese mittlerweile sehr solide ist. Die Unterstützung für Bildschirmaufnahmen gilt als vollständig ausgereift, aber die Kameraunterstützung ist noch in Arbeit, teilweise weil ein Generationswechsel in der Kameralandschaft ansteht, bei dem UVC-Kameras durch MIPI-Kameras ersetzt werden. Die PipeWire-Kameraunterstützung für Firefox ist jetzt in Fedora standardmäßig aktiviert, Chrome kommt schnell voran und OBS Studio unterstützt PipeWire bereits seit einiger Zeit.
Zugänglichkeit
Bei Fedora steht Zugänglichkeit immer im Fokus. Dabei geht es im Moment um die Arbeit an Portalen und Wayland-Erweiterungen, um die Zugänglichkeit zu erleichtern. Die Arbeit am ORCA-Bildschirmleser und seinen Abhängigkeiten soll sicherstellen, dass er unter Wayland einwandfrei funktioniert. Die nächste Veröffentlichung von Fedora wird Version 42 sein und ist zur Veröffentlichung am 15. April vorgesehen.
Ich bin ja mal gespannt, wie man da KI integriert. Und vor allem: Wird man es nur abschalten können oder richtig deinstallieren können? Das ist ja ein großer Unterschied.
In dem Zusammenhang habe ich in einem Youtube Video vom Channel ”The Linux Experiment” gehört, dass man bei Gnome wohl auch überlegt ob und wie man das einbauen könnte – wobei das wohl vorerst nur Gedankenspiele sind und noch nichts konkretes ist, wenn ich das richtig verstanden habe.
Ich denke Du wirst dann auch Distributionen finden, die auf KI verzichten.
So war es immer bei Linux, das ist ja gerade das Schoene.
Flatpak oder Snap ebenso wie KI, Dinge auf die ich gerne verzichten kann.
Zwingt dir ja niemand auf.
Joar noch nicht. Das kommt aber nach und nach. Für uns Anwender bedeutet das Universalität, Sicherheit, Benutzerfreundlichkeit und Aktualität, für Entwickler ausschlaggebend die plattformübergreifende Kompatibilität, vereinfachte Wartung, konsistente Umgebungen und Flexibilität (stable, beta, testing). Flatpak wird sich durchsetzten.
Wobei das wohl darauf ankommt. Ich meine, Snap und Flatpak kann man – wenn es vorinstalliert ist – ja wieder deinstalleren order eben gar nicht erst installieren.
Wenn aber KI … wie drücke ich mich aus … ”fest eingebaut” ist, wird man das wohl nicht ohne weiteres wegbekommen. Dann wäre das ja zumindest zu einem gewissen Maße aufgezwungen. Man könnte es dann – hoffentlich – abschalten. Aber es wäre ja trotzdem da.
Da sehe ich ähnlich. Snap lehne ich ab, weil Cononical das Monopol dafür hat und man muss es, obwohl es sich aus freien Quellen bedient, letzten Endes als closed souce ansehen, da niemand von außen Einblick hat, was am Ende im Kompilat steckt.
Bei flatpak sieht es anders aus und ich sehe die Entwicklung dort recht positiv. Privat benötige ich es nicht, aber für Firmen-Anwender ist es ein Segen die genutzten Anwendungen unabhängig vom Distributionszyklus upgraden zu können.
Was ich am Konzept kritisiere ist 1. Die naive Auffassung, Softwareentwickler könnten sich selbst kontrollieren und sollten direkt an den Anwender ausliefern und 2. wird dabei weit unterschätzt wie wichtig die Rolling Release Distributionen für den Upstream bei der Softwareentwicklung sind.
Flatpak alleine ohne den bisherigen upstream mit maintainten Distributionen ergibt vielleicht so was wie Android, aber ist kein Entwicklungsmodell für vertrauenswürdige freie Software.
Am Liebsten würde ich es sehen, wenn die Distribution meines Vertrauens auch selbst die Flatpaks packt und das bräuchten dann auch nur bei den Version einer Anwendung geschehen, die besonders stabil laufen. Auf diese Weise hätte man a) flatpaks von den Leuten denen man vertraut und b) bei einen Rolling Release jederzeit die Möglichkeit bei einer Anwendung auf ein flatpak umzusteigen wenn einmal die Weiterentwicklung einer Anwendung für den persönlichen Geschmack zu schnell geht oder noch zu fehlerhaft ist um damit produktiv arbeiten zu können.
KI ist ein gänzlich anderes Thema. Hier nur soviel, dass die Anwendung des Begriffs Intelligenz bei toter Materie keinen Sinn ergibt und es dadurch zu vielen Missverständnissen kommt, aber leider ist das ja auch durchaus beabsichtigt.
Flatpaks gehören nach Flathub. Hier veröffentlichen alle Entwickler ihre jeweiligen Apps. Und gut ist. Schau mal bei Phoronix vorbei und lies den Artikel über Fedora und OBS-Studio was da gerade passiert. Ganz großer Bockmist. Sowas kommt dann dabei herraus. Nein danke. Ich liebe Fedora, aber das erste was ich gemacht habe war: flatpak uninstall –all. Und siehe da, alles richtig gemacht.
“Flatpaks gehören nach Flathub” – Nein! Zumindest nicht zwangsläufig. aber wir reden momentan ohnehin knapp an einander vorbei.
“2. wird dabei weit unterschätzt wie wichtig die Rolling Release Distributionen für den Upstream bei der Softwareentwicklung sind”
Nee also ich als Anwendungs und Schnittstellenentwicker mit 30 Jahren Erfahrung kann Dir versichern: “Das schlimmste was es gibt sind rolling Releases.”
Als Anwender nutze ich seit über 20 Jahren privat wie beruflich nichts anderes als Rolling. In den 2000er Jahren wurden wir mit unserer damaligen Distribution sidux von der Debian-Kabale allerübelst beschimpft und beleidigt, weil wir es wagten, Unstable zu releasen. War nicht schön und änderte sich erst, als ich den damaligen DPL Stefano Zachhiroli nach Berlin zu einer Mini-Debconf einlud und sich Debian dann langsam für seinen Entwicklungszweig als veröffentlichte Distribution erwärmte und Dinge wie #debian-derivatives entstanden.
Sorry, war ich sicher auch dabei bei denen die das nicht gut fanden. 😉 Finds jetzt immer noch nicht gut aber akzeptiere es, ist ja dank Derivat euer Problem und kommt nicht auf Debian zurueck. 🙂
Aendert aber nix dran, das rolling releases ne Katastrophe fuer die Softwareentwicklung sind.
und so richtig rolling releases ist ja der unstable auch nicht. 😉
Wenn ich, wie bei Unstable viermal am Tag upgraden kann, dann ist das für mich Rolling in Reinkultur.
Das Schlimmste überhaupt für die Entwicklung ist stable.
Mag sein, dass du bei (old) stable 30 Jahre und bis in alle Ewigkeit funktionierende Schnittstellen bewundern kannst, aber bei stable findet definitionsgemäß keine Entwicklung mehr statt. Gut, hier und da mal ein patch aber sonst?
Ist dir schon mal in den Sinn gekommen, dass es ohne sid auch gar kein neues Debian stable geben kann?
Du verwechselt Entwicklung mit dem was du gerne für deine Zwecke einsetztest.
Das sind aber ganz unterschiedliche paar Schuhe. Oder gehst du in Pantoffeln Tanzen?
Du kommst scheinbar nicht aus der Softwareentwicklung, wie man an deinem Post liest.
Ich spreche ja nicht ueber die Debian Entwicklung, sondern ueber die Anwendungsentwicklung von Programmen und Schnittstellen fuer Linux OS
.
Dort brauchst Du eine sichere feste Basis um entwickeln zu koennen. Also stable.
unstable oder gar dev waere der Supergau.
Aber ich glaube darueber koennen wir 2 nicht wirklich disskutieren.
So langsam kommst du auf den Trichter!
Du nimmst stable als statische Basis um entwickeln zu können.
Und wenn du dann (halbwegs) fertig mit deiner Entwicklung bist, kommt dein neues Prog. oder die neue Prog. Version wohin? Genau – es kommt nach unstable – und dort wird es usern zugeführt – und wenn sich dann dort herausstellt, dass dein Prog. mit einer bestimmten Hard- oder Softwarekombination die du als Entwickler gar nicht alle testen kannst Zicken macht, dann bekommst du von den usern einer RR-Distribution bug reports. Und falls auf unstable schon neue lib Versionen sind, dann machst du was? Genau! Oder veröffentlichst du etwa nach stable?
Stable ist wie Totholz. Damit kannst du was schönes bauen, was du ja auch tust, aber bei stable selbst wächst nichts mehr nach.
Ich sprach davon, dass flatpaks für die Weiterentwickung von Software nicht das leisten können, was RR-Distributionen tun. Nämlich jedes Stück Software in einer sich ständig veränderden Umgebung zu testen. Diesen dynamischen Prozess bezeichnet man als upstream.
flatpaks tun genau das Gegenteil!
Und deshalb sind flatpaks auch nicht dazu geeignet das bisherige Distributionsmodell abzulösen.
Flatpaks sind wunderbar für ein bestimmtes Zielpublikum und für die Firmen die dort Support leisten. Aber der Upstream würde, wenn es nur noch flatpaks gäbe ziemlich bald zerrupft werden und wahrscheinlich dann auch irgendwann ganz zum Erliegen kommen.
Red Hat ernährt sich vom Support und daher erklärt sich auch das hohe Interesse daran. Aber flatpak ist keine Lösung für alles und schon gar nicht dafür die bisherigen Distributionen abzuschaffen.
“Flatpaks sind wunderbar für ein bestimmtes Zielpublikum und für die Firmen die dort Support leisten.”
Aso ich gebe ja auch debian support, aber mit Sicherheit nicht auf unstable oder Flatpacks.
Wer das nutzt der muss auch selbst damit klar kommen.
Wir raten explizit von so etwas ab und der Support erlischt bei der Verwendung. (Es sei denn bestimmte Progs sind mit uns abgesprochen und von uns geprueft.)
Und was soll ich sagen, es funktioniert super (nat. Supporten wir keine Privatanwender, da waeren die supportpreise auch viel zu hoch.)
Aber wie ich merke reden wir immer noch du von Aepfel und ich von Birnen. Ich spreche von Anwendungsprogrammen, du eher von Tools.
Aber lass es gut sein unsere Sichtweise ist da total unterschiedlich.
Wenn ihr ausschließlich nur Kunden betreut, die Debian stable laufen haben, dann ist euer Konzept ja in Ordnung.
Flatpaks beruhen jedoch auf der Idee auch in einer vielfältigen Linux Distributionslandschaft einen einheitlichen Support von Programmen zu ermöglichen, da ein flatpak seine eigene Umgebung mitbringt und damit unabhängig vom Distributionszyklus wird.
Von daher ist flatpak ideal für Firmen die ihre Produkte quer über die Linuxlandschaft supporten möchten. Wenn ihr Kundschaft habt, denen ihr das Linux OS vorschreiben könnt, dann ist das prima für euch.
Du musst auch gar nicht über flatpak argumentieren wenn du es rundherum ablehnst. Aber dann macht eine Unterhaltung darüber wenig Sinn.
Aber, dass stable im Grunde nichts anderes als ein unstable zum Zeitpunkt des freeze ist, dass solltest du eigentlich schon wissen.
“stable im Grunde nichts anderes als ein unstable zum Zeitpunkt des freeze ist” stable ist durch und durch getestet, was ein unstable auch zum freeze noch nicht ist stable ist das wo man sagt: “freigegeben zum produktiven Einsatz”, bei unstable sagt man: “nicht freigegeben zum produktiven Einsatz” also von Sicht der Distribution aus,
als Produkt gibt man das als garnicht raus (das ist quasi ein RC1 Stand), manche geben den auch raus aber nicht als produktiv nutzbar, eher weil man den Kunden zum testen mit einspannen will.
Dem muss ich heftigst widersprechen. Ich nutze Unstable seit über 20 Jahren produktiv. Früher musste man schon genau aufpassen und wissen, wie man mit APT und DPKG umgeht. Heutzutage ist das sehr handzahm geworden. Man sollte es natürlich nicht auf Servern oder missionskritischen Umgebungen nutzen. Aber produktiv einsetzbar allemal. Das beweisen unter anderem viele Nutzer von siduction.
moin Stephan,
klar aber so ist es eigentlich nicht von debian gedacht und wird auch nicht angeraten. Wie ich sagte, das ist jedem sein Problem. Und die Frage ist ja, was verstehst Du unter produktiv? Das mal der admin eine frickelkiste nutzt? na das gab’s schon immer. 🙂
Nein, nicht frickeln, Produktiv-Output erstellen, der auch Geld verdienen kann.
Ich verstehe schon deinen Standpunkt und der macht für deine Arbeit auch durchaus Sinn, also bleib dabei. Ich will dir ja nicht in deinen Kram herumfummeln. Für dich ist dein Argumentation richtig.
Vielleicht kannst du aber mal abseits deiner festgelegten Denkschemata einem Argument folgen.
Frage: Veröffentlichst du bei Debian und falls das der Fall wäre, wo würdest du (ganz egal wie gut deine Software vorher getestet ist) das tun?
Richtig. In unstable!
Wie viele Pakete hat Debian in unstable?
Wie viele davon erhalten ein Patch bevor sie als stable im neuen Release herausgegeben werden?
Wie viele Fehlerbereinigungen die im Freeze getätigt werden, gelten gar nicht den fremden Software-Paketen, sondern gelten ausschließlich der Konsistenz und der Erneuerung von Debian als Distribution?
Wohin laufen Fehlerbereinigungen wenn Debian mal nicht im Freeze ist, als erstes ein, bevor sie dann eventuell als Patch auch für die laufende stable übernommen werden?
Richtig: In unstable
Wir müssen die Diskussion hier gar nicht beenden, wir können dieses Jahr mal aufmerksam beobachten, was im Freeze von Debian passiert. Wie viele Pakete werden ohne jede Änderung für stable übernommen und bei wie vielen der Fehlerbereinigungen geht es ausschließlich darum, dass Debian als Distribution konsistent bleibt bzw. auch mal von seinen Tools her erneuert wird.
Die hohe Qualität von Debian unstable ist 1. den Maintainern zu verdanken die wissen was sie tun und 2. den Entwicklern die wissen, dass die neue Version ihrer Software sofort beim Anwender landet und deshalb sorgfältig arbeiten 3. den Usern die qualifizierte bug-reports schreiben.
Das ist ein dynamisches Prozedere und gäbe es das nicht, käme entweder der ganze upstream zum erliegen, oder die Debian Devs bräuchten 2 Jahre bis sie selbst alles durch getestet hätten und das Freeze würde sich dann auch mindestens 2. Jahre hinziehen.
Ohne unstable gibt es kein stable!
Die Begriffe unstable und stable sind aber lediglich Arbeitstitel bei Debian. Und sie sind sogar genaugenommen falsch.
Diese Begriffe sind aus der Architektur übernommen und für Software nur bedingt tauglich.
Ich würde stattdessen lieber in usable, static und stable unterscheiden wollen.
Ein Haus kann benutzbar sein, aber das sagt nichts darüber aus ob es von allein stehen bleibt. Das ist die Statik. Und Stabilität gibt Auskunft darüber ob das Haus auch einem Tornado stand hält oder ob 5 Elefanten im 10 Stock tanzen dürfen ohne, dass es umfällt. Stabilität ist eine Aussage gegenüber einer zu bestimmenden Belastung.
Für mich ist Debian unstable vollauf nutzbar als Desktopsystem. Debian stable im Großen und Ganzen erst einmal ein statisches Beibehalten von Paketversionen, dass dann im Laufe der Jahren durch das Patchen von groben Fehlern immer mehr an Stabilität gewinnt.
Jemand der einen Server betreibt, will auch lediglich nur, dass sich an der Softwareumgebung auf die er sein Projekt aufgebaut hat nicht ständig was ändert. (das ist Statik)
Wenn du in einer Nische lebst und deiner Kundschaft ausschließlich komplett ausgereifte Software servieren kannst, dann ist das Bestens. Bei Projekten die sich um die Verzahnung von 10 Tausenden Stück Software kümmern müssen die sich ständig ändert ist das unmöglich.
Unstabe leistet für diese dynamische Verzahnung mächtig viel. Das war schon meine ganze Behauptung. Und flatpaks können das nicht leisten. Mehr hab ich gar nicht sagen wollen.
Ich glaube man muss anfangen Begrifflichkeiten zu trennen, bzw. eben Dinge anders zu benennnen.
Die Bezeichung Opens-source, ist mittlerweile zu einem Schalgwort von Firmensoftware verkommen, die eben die Sourcen bereitstellt. Das stehen mittlerweile riesen Konstrukte dahinter auch mit komischer Finanzierung.
Frueher war dies das Merkmal von Communitysoftware.
So langsam sollten die freien Entwickler von Software sich von dem Ganzen abgrenzen, damit wieder ganz klar ersichtlich wird was freie Comunity ist und was einfach Firmen bzw. gekaufte (siehe eindeutig einige Foundations) Entwicklung ist. Freie Software sollte sich nicht so vereinnahmen lassen, sondern dagegen vor gehen.
Ich hoffe, das die jetztige Generation auch willens dazu ist, aber ich habe leider keine grosse Hoffnung.
Ja, Freie Software sollte als solche bezeichnet werden. Quelloffene Software muss nicht frei sein und Freeware schon gar nicht. Außerhalb der Linux-Leute kann aber kaum unterschieden werden.
Übrigens:
Augustinus von Hippo (* 13. November 354 – † 28. August 430) schrieb in der “De Doctrina Christiana”:
„Wenn eine Sache nicht gemindert wird, da man sie mit anderen teilt, ist ihr Besitz unrecht, solange man sie nur allein besitzt und nicht mit anderen teilt.“
Dieses Prinzip gilt auch für Software.
Da hat Augustinus von Hippo zweifelsohne Recht. Allerdings ist auch bei Sachen die gemindert werden, da man sie mir anderen teilt, das Teilen meist auch nicht verkehrt. Lautet doch die Übersetzung vom lateinischen privare, denn auch korrekter Weise berauben.
Irgentwie scheinst du hinterm Mond zu leben. Freiheit bedeutet eben auch, das Firmen mitmischen dürfen. Wenn eine Software zB. unter der Copyleft-Lizenz GPL veröffentlicht wurde, dann bleibt das auch auf Ewigkeit so. Das ist Unwiderruflich. Also wo ist das Problem, wenn eine Firma Code dazusteuert?
Sorry aber du hast leider garnichts verstanden um was es da geht.
Ist aber nicht schlimm, zeigt nur mal wieder auf, das Welten zwischen Entwicklern und Anwendern liegen.