CleanPress

Schlagwort: Fedora

  • Ausblick auf Fedora 31

    Fedora 31
    Logo: Public Domain

    Fedora Workstation 31 wird zwar erst im Oktober erwartet, trotzdem hat Red Hat-Entwickler Christian Schaller kürzlich bereits einen ausführlichen Bericht über die bei Fedora immer üppig zu erwartenden Neuerungen erstellt.

    Christian Schaller ist der Leiter der Desktop-Entwicklung bei Red Hat und hat somit immer ein waches Auge auf die Entwicklungen bei Fedora, die dann zu einem späteren Zeitpunkt in Red Hat Enterprise Linux (RHEL) einfließen.

    Fedora 31 wird spannend

    Ganz oben auf dem Zettel der Entwickler bei Fedora steht immer noch der Abschluss des Übergangs von X zu Wayland. Das Projekt liefert bereits seit Fedora 25 Wayland mit GNOME als Standard aus. Derzeit geht es unter anderem darum, die Abhängigkeit zum herkömmlichen X-Server in GNOME zu beseitigen. Die GNOME-Shell soll ohne XWayland laufen, GNOME 3.34 oder 3.36 sind das Ziel dieser Bestrebungen.

    Nvidia besser mit Wayland?

    Darüber hinaus bietet Nvidias proprietärer Treiber noch keinen hardwareunterstützten 3D-Support für unter XWayland laufende X-Anwendungen. Hier warten die Entwickler darauf, dass man bei Nvidia die letzten Entwicklungen von Fedora begutachtet und hoffentlich in den Nvidia-Treiber einbindet. Insgesamt geht man bei Red Hat davon aus, dass X.org in Kürze in den Erhaltungsmodus wechselt und keine Weiterentwicklung mehr stattfindet.

    PipeWire bereits im Einsatz

    Ein weiteres großes Projekt, an dem Wim Taymans federführend seit einigen Jahren arbeitet ist PipeWire. Dieses Framework soll einmal die Wiedergabe von Audio und Video vereinen und im Bereich Audio Jack und PulseAudio ablösen. Es kommt bereits beim Desktop-Sharing mit Wayland im Hintergrund zum Einsatz. Ein neuer Nutzer des Desktop-Sharing-Portal ist Miracast , dessen Einbindung in GNOME im Fedora COPR Repository vorab gestestet werden kann.

    Flatpak soll in Zukunft RPM ablösen

    Flatpak darf natürlich auch nicht fehlen, denn das alternative Paketsystem ist ein Kind der Fedora-Entwickler. Derzeit wird an der Verbesserung der Infrastruktur gearbeitet, um die Schritte zum Bau von Flatpaks aus RPMs möglichst weit zu automatisieren. Das sind die Vorarbeiten, um Flatpaks in Fedora Workstation auszuliefern so wie das bereits bei Fedora Silverblue geschieht.

    Fedora Toolbox für Entwickler

    In diesem Zusammenhang wird auch das Projekt Fedora Toolbox weiter vorangetrieben. Es soll Entwickler befähigen, auch auf schreibgeschützten Systemen wie Fedora Siverblue die nötigen Tools, Treiber und Anwendungen installieren zu können. Hier steht eine Überarbeitung an um aus dem derzeitigen Shell-Script eine in Go geschriebene Anwendung zu machen, die besser mit Container-Bibliotheken und -Werkzeugen harmoniert.

    GNOME Classic aufgewertet

    Die Anhänger von GNOME 2 wird es freuen zu hören, dass der GNOME Classic genannte Modus der GNOME Shell überarbeitet wird, um noch mehr GNOME-2-Feeling zu vermitteln. Fortschritte gibt es auch in Sachen Fingerabdruck zu vermelden. Bald gibt es neue Treiber für Synaptics Fingerprint-Reader, weitere Hersteller sollen animiert werden, ihre Treiber für Linux zu verbessern.

    OpenH264 Codecs 2.0

    Die Unterstützung für Media Codecs verbessert sich, da Cisco die zweite Version seines OpenH264 Codecs freigegeben hat. An dieser freien Implementation von H264 hängt beispielsweise die Unterstützung von Firefox für H264 für WebRTC. Mit OpenH264 Codecs 2.0 kann nun nicht nur das Basisprofil für Videoanrufe decodiert werden, sondern auch die Profile Main und High, die für den Großteil von Video-Inhalten im Netz unabdingbar sind.

    Weitere Änderungen

    Des weiteren wird Fedora das Root-Passwort für SSH-Zugänge deaktivieren. Die Entfernung von Paketen, die von Python 2 abhängen, die mit Fedora 30 begonnen wurde, wird fortgesetzt. RPMs wechseln zur Kompressionsmethode zstd. Firefox für Wayland soll zudem Standard-Browser werden. Wie üblich scheint auch Fedora 31 ein spannendes Release zu werden.

  • Fedora 30 wird wieder ein spannendes Release

    Fedora 30 Beta
    Bild: Fedora Magazine

    Vor wenigen Tagen ist die Beta-Version zu Fedora 30 erschienen. Sie ist voll mit Verbesserungen und Neuentwicklungen und macht Lust auf die stabile Veröffentlichung, die für den 30. April vorgesehen ist.

    Vielversprechende Fedora 30 Beta

    Red Hats Christian Schaller hat zum Erscheinen der Beta einen langen Blogeintrag veröffentlicht, den ich hier verkürzt zusammenfassen möchte. Das Herzstück von Fedora 30 ist das neue GNOME 3.32. Nicht nur fühlt sich die GNOME-Shell flotter an als zuvor, auch die Apps wurden an vielen Stellen aufgewertet. Zudem kommen Besitzer von HiDPI-Displays in den Genuss von Fractional Scaling, einer Methode für eine feinere Abstufung bei der Skalierung des Displays.

    Screen-Sharing unter Wayland

    Fedora liefert bereits seit Version 25 Wayland als Standard-Display-Protokoll aus, was wegen des Sicherheitsmodells von Wayland zu einigen Einschränkungen führte. So war Screen-Sharing zunächst nicht möglich, da Wayland anders als X es nicht erlaubt, Bilder oder Streams des Desktops zu direkt zu grabben.

    Mit Fedora 30 ist es nun soweit, dass Screen-Sharing sowohl im Chrome 73 als auch in Firefox unter Wayland funktioniert. Dazu wird das Multimedia-Framework PipeWire verwendet. Firefox als native Wayland-Anwendung sollte ebenfalls mit Fedora 30 erscheinen, wurde aber auf Version 31 verschoben.

    Fortschritte bei Nvidia unter Wayland

    Aufseiten grafischer Anwendungen konnte das Gaming unter Wayland verbessert werden. Der proprietäre Nvidia-Treiber sollte nun laut Schaller mit nativen Wayland-Apps zufriedenstellend laufen, nur die Unterstützung von XWayland-Anwendungen mache noch Probleme. Diese werden vermutlich erst mit einem neuen Nvidia-Treiber im Herbst beseitigt, sodass betroffene Anwender bis dahin mit X vorlieb nehmen müssen.

    Fedora wird zudem einen verbesserten OpenH264-Treiber erhalten. Der soll nicht nur Firefox in die Lage versetzen, OpenH264 auch für Dinge wie Youtube-Wiedergabe zu verwenden, sondern auch über den von Cisco kostenlos bereitgestellten offenen Treiber H264-Material mit GStreamer-Anwendungen wie Totem wiederzugeben.

    Flatpak ist Fedoras Zukunft

    Vorbereitungen für die alternative Bereitstellung von Flatpaks von Fedora-Paketen in der normalen Workstation-Ausgabe sind in vollem Gange, ein Repository dafür ist in Fedora 30 Beta verfügbar und kann über die Paketverwaltung GNOME Software über das Aufklappmenü rechts oben erreicht werden. Fedora bereitet sich so immer mehr darauf vor, Flatpak als Standard-Paketformat mit RPM als Alternative anzubieten.

    Fedora Silverblue, das seit Fedora 29 offiziell ausgeliefert wird, geht noch einen Schritt weiter und basiert das Paketsystem gänzlich auf OSTree. Das finde ich sehr interessant und schreibe dazu noch eine eigene News.

    Die Links zu den Beta-Versionen für Workstation, Server und Silverblue 30 sowie zu den Fedora Spins, Labs und ARM-Versionen enthält die Ankündigung des Fedora Magazine.

  • Fedora räumt weiter auf

    Fedora 31
    Logo: Public Domain

    Die im Mai erwartete Veröffentlichung von Fedora 30 wird unter Umständen das einzige Fedora-Release im Jahr 2019 bleiben. Das ist zumindest der Plan einiger Entwickler, die Fedora 31 verschieben wollen, um die Distribution besser auf die Zukunft vorzubereiten.

    Der Umbau geht weiter

    Nachdem die Struktur von Fedora in den letzten Jahren bereits stark umgebaut wurde, sollen nun die Werkzeuge, die zur Entwicklung und zur Erstellung von Veröffentlichungen benutzt werden, vereinheitlicht und modernisiert werden.

    Den Weg frei machen

    Die Werkzeuge und der Ablauf, wie Fedora gebaut wird sind seit fast 15 Jahren etabliert und bedürfen nach Meinung von Projektleiter Matthew Miller und einiger Entwickler dringend der Überarbeitung, damit sich Fedora an dieser Stelle nicht selbst im Weg steht.

    Community stärken

    Vor allem soll die Community damit weiter befähigt werden, an diesem Prozess teilzuhaben, was mit der momentanen, nicht weiter ausbaubaren Arbeitsweise nicht funktioniert. Derzeit können nur wenige Leute Veröffentlichungen bauen und ausliefern. 

    Umbau im Maschinenraum

    Nach den Erkenntnissen, die in einer Zielvorgabe definiert wurden, ist dazu ein hohes Maß an Neukonzeption und Überarbeitung von Werkzeugen und Prozessen notwendig. Dazu wird ein schnellerer und besser skalierender Compose-Prozess benötigt, um Continuous Integration und Continuous Delivery (CI/CD) zu verbessern. Dazu gehört auch mehr Automatisierung von Vorgängen bei Qualitätstests, die derzeit teils manuell durchgeführt werden.

    Dabei müssen diese Änderungen über verschiedene Teams hinweg koordiniert werden, hier arbeiten einzelne Teams seit langem nicht sehr effektiv mit unterschiedlichen Werkzeugen. Insgesamt bezeichnet ein Entwickler die gewachsene Situation als »komplex und oft unorganisiert«.

    Nicht das erste Mal

    Wenn die Pläne so umgesetzt werden wie geplant, wäre dies nicht das erste Mal, dass ein Fedora-Release ausfällt. Auch zwischen  Fedora 20 und 21 lagen 12 Monate, während die Entwickler im Rahmen der Initiative »Fedora Next« die Distribution in die heute bekannten drei Teile Workstation, Server und Cloud aufteilten. Bisher sind die Beiträge zu dem Vorhaben auf der Mailingliste überwiegend positiv.

  • Red Hat Enterprise Linux 8 Beta zum Test bereit

    Red Hat Enterprise Linux 8 Beta
    Bild: Red Hat Linux | Quelle: Leonid Mamchenkov | Lizenz: CC BY 2.0

     

    Rund zwei Wochen nach dem Erscheinen des sechsten Updates für das aktuelle Red Hat Enterprise Linux 7 und dem Übernahmeangebot von IBM veröffentlicht das Unternehmen aus Raleigh in North Carolina die erste Beta-Version zu seiner Unternehmens-Distribution Red Hat Enterprise Linux 8 (RHEL 8). Die im nächsten Jahr in stabiler Version zu erwartende neue Version von RHEL modernisiert die Distribution an vielen Stellen und greift dabei unter anderem auf Techniken aus dem aktuellen Fedora 29 zurück.

    Modularisiert

    So führt RHEL 8 Beta die Modularisierung durch Application-Streams ein. Das ermöglicht dem Anwender, Entwicklungswerkzeuge und andere für Unternehmen relevante Software in verschiedenen Versionen zu installieren, ohne dabei das Basissystem zu aktualisieren. So können neben der aktuellen, mit der Distribution ausgelieferten Version auch ältere oder aktuellere Versionen genutzt werden.

    Storage-Pools vereinfacht

    Ebenfalls erstmals mit Fedora 29 veröffentlicht wurde die neue Storage-Lösung Stratis, die sich bereits in der Beta zu RHEL 8 wiederfindet. Damit will Red Hat die Komplexität aus der Verwaltung von Storage-Volumes nehmen, indem der Anwender die daruter liegenden Techniken nicht zwingend verstehen muss, um seinen Storage-Pool zu konfigurieren. Stratis setzt dabei auf XFS auf und soll diesem Dateisystem die Tricks von Btrfs und ZFS beibringen.

    Verschlüsselung

    In diesem Bereich bietet RHEL 8 zudem Unterstützung für LUKSv2 zur Verschlüsselung von lokalen Daten in Kombination mit Network-Bound Disk Encryption (NBDE) für mehr Datensicherheit und vereinfachten Zugriff auf verschlüsselte Daten. Snapshots des Dateisystems ermöglichen zudem eine schnellere Durchführung von Aufgaben auf Dateiebene, wie das Klonen virtueller Maschinen, während sie gleichzeitig Platz sparen, indem sie neuen Speicher nur dann verbrauchen, wenn sich Daten ändern.

    Container-Tools

    Im Bereich Cloud und Container erhielt RHEL 8 ein Werkzeugset bestehend aus Buildah zum Erstellen von Container-Images, Podman zur Verwaltung sowie Skopeo zur Handhabung dieser Images in Repositories. Wird statt Containern eine Virtuelle Mschine benötigt, ermöglicht RHEL mit Composer die Erstellung und das Ausrollen benutzerdefinierter Images in der Hybrid-Cloud mit einer einfachen grafischen Benutzeroberfläche.

    Gnome, kein Plasma

    Die RHEL 8 Beta basiert auf Kernel 4.18 und bietet Gnome 3.28, falls eine grafische Oberfläche gebraucht wird. KDEs Plasma-Desktop wird ab dieser Beta nicht mehr unterstützt. Ebenso entfällt die Unterstützung für Btrfs. Als weitere  Software sind unter anderem Apache 2.4, Nginx 1.14, MariaDB 10.3, MySQL 8.0, PostgreSQL 9.6 und 10, PHP 7.1 sowie Node.js 8 und 10 mit im Paket.

    Weitere Einzelheiten vermittelt die Ankündigung des Herstellers. Die Betaversion steht in 64-Bit für die Architekturen x86, ARM, Power und System Z den Red-Hat-Kunden sowie registrierten Entwicklern zum Test zur Verfügung.

  • Red Hat unterstützt KDE nicht mehr

    Red Hat unterstützt KDE nicht mehr
    Bild: Red Hat Linux | Quelle: Leonid Mamchenkov | Lizenz: CC BY 2.0

     

    Ein wenig untergegangen in der Berichterstattung bezüglich der geplanten Übernahme von Red Hat durch IBM ist die Nachricht, dass Red Hat KDE als Desktop in seiner Distribution Red Hat Enterprise Linux (RHEL) künftig nicht mehr unterstützt. Die Plattformen, die die Nachricht brachten, haben sie aus meiner Sicht etwas zu hoch aufgehängt.

    Veralteter KDE-Desktop

    Und das aus mehreren Gründen: RHEL wird zum größten Teil als Server eingesetzt, der Anteil, den dabei Red Hat Desktop (RHD) einnimmt, ist überschaubar. Davon nutzen die allermeisten Anwender den von Red Hat bevorzugten GNOME-Desktop. Das ist verständlich, da das aktuelle RHEL 7.x größtenteils noch auf Fedora 19 und 20 von 2013 basiert und RHEL dementsprechend noch auf KDE 4 setzt.

    Historisch bedingt

    Der geringe Stellenwert von KDE bei Red Hat ist auch historisch bedingt, da Red Hat in seinen Anfangstagen KDE nicht unterstützt hat, weil Qt damals einer unfreien Lizenzen unterstand und somit KDE nicht als freie Software galt. Auch Debian weigerte sich damals, KDE auszuliefern. Das führte auch zum Beginn der GNOME-Entwicklung. Erst 2002 wurde die Linux-Version von Qt dual-lizensiert und unterlag fortan auch der GPL.

    Ferner liefen…

    Die Nachricht ging auch unter, da Red Hat sie in der Release-Ankündigung von RHEL 7.6 versteckt hat. Dort steht, in Kapitel 51, dass die eingestellten Funktionen enthält: [su_quote style=“modern-light“]KDE Plasma Workspaces (KDE), die als Alternative zur standardmäßigen GNOME-Desktopumgebung bereitgestellt werden, sind veraltet. Eine zukünftige Hauptversion von Red Hat Enterprise Linux wird die Verwendung von KDE anstelle der standardmäßigen GNOME-Desktopumgebung nicht mehr unterstützen. [/su_quote]

    Bis 2024 unterstützt

    KDE sowie alles, was in Kapitel 51 der »Red Hat Enterprise Linux 7.6 Versionshinweise« aufgeführt ist, wird während der gesamten Lebensdauer von Red Hat Enterprise Linux 7, die derzeit bis 2024 geplant ist, weiterhin unterstützt. Es besteht somit kein Grund zur Sorge für Anwender dieses KDE-4-Desktops, der, wenn das Support-Ende 2024 naht, immerhin bereits 11 Jahre auf dem Buckel hat. Ich finde es sehr verwunderlich, das Red Hat das ungeliebte KDE so lange mitgeschleppt hat.

    Kein Einfluss auf Fedora

    Für die KDE-Gemeinde sowie dessen Entwickler ist der Wegfall der Unterstützung kein Beinbruch, die dort verwendete Version wird bereits sehr lange nicht mehr vonseiten KDEs unterstützt. Auch bei Fedora spielt KDE nicht die erste Geige, zumindest gibt es aber einen Spin mit aktuellem Plasma-Desktop, der von Red Hats Entscheidung auch in keinster Weise betroffen ist.

  • Fedora 29 mit GNOME 3.30 freigegeben

    Fedora 29
    Screenshot:ft

     

    Es ist fast genau 15 Jahre her, dass mit Fedora Core 1 die erste Ausgabe von Fedora erschien. Pünktlich im Rahmen der Vorgaben veröffentlichten die Fedora-Entwickler heute Version 29 der von Red Hat unterstützten Distribution. Dabei bringt die alle sechs Monate neu herausgegebene Distribution diesmal neben GNOME 3.30 und einem aktualisierten Paketbestand wie immer einige neue Entwicklungen mit. Hervorzuheben sind hier unter anderem Version 1.0 des neuen Storage-System Stratis sowie mit Silverblue ein Blick in eine mögliche Zukunft von Fedora Workstation.

    Die Zutaten

    Doch zunächst zu Brot und Butter. Kernel 4.18.5, Systemd 239-3, Wayland und X.Org-Server 1.20.1 sowie GCC 8.2.1 bilden die Grundlage, auf der mit GNOME 3.30.1 die Bedienoberfläche läuft. Als Browser dient Firefox 63.0, Büroaufträge nimmt LibreOffice 6.1.2.1 entgegen. Als Dateimanager ist Nautilus 3.20.2 mit von der Partie, der dank GNOMEs Umbenennungswahn nun Dateien heißt. Auch alle anderen GNOME-Apps sind auf neuestem Stand.

    Fedora Modularity

    Eine Entwicklung, die auf den ersten Blick vielleicht gar nicht auffällt, die aber von vielen Anwendern wegen der erweiterten Flexibilität begrüßt werden dürfte ist die Einführung der Fedora-Modularität für alle Fedora-Varianten. Mit Fedora 28 wurde dieses neue Feature nur für die Server-Variante freigegeben.

    Um die Änderung wahrzunehmen, muss man sich die Repositories ansehen. Dabei fällt auf, dass neben den drei traditionellen Repos Fedora, Updates und Update-Tests nun drei weitere Repos eingeführt wurden. Die neuen Repos heißen fedora-modular.repo, fedora-updates-modular.repo und fedora-updates-testing-modular.repo. Somit hat jedes der bisherigen Repos ein modulares Gegenstück erhalten.

    Damit werden die Anwender in die Lage versetzt, Pakete einer früheren noch unterstützten oder einer künftigen Version aus Git zu nutzen ohne gleich die gesamte Basis ändern zu müssen. Nicht alle Pakete werden diesen Service erhalten, die Verfügbarkeit hängt vom jeweiligen Paketbetreuer ab. Anwender, die von den Modulen keinen Gebrauch machen wollen, können die neuen Repositories deaktivieren und Fedora wie bisher weiterverwenden.

    Remote-Desktop mit Wayland

    Ein weiteres Ziel für Fedora 29  im Zusammenhang mit Wayland war die Fertigstellung der Remote-Desktop-Unterstützung für die GNOME-Shell mithilfe von PipeWire, dem neuen Multimedia-Framwork auf Basis von GStreamer. Auf Systemen, auf denen nur ein einziges Betriebssystem installiert ist, bietet das Grub-Menü keine nützliche Funktionalität und wird daher künftig standardmäßig ausgeblendet. In diesem Zusammenhang soll auch ein flickerfreier Bootvorgang zu einem besseren Starterlebnis führen.

    Spins und Labs

    Neben den Hauptausgaben Workstation, Server und Atomic für die Cloud bietet Fedora Spins und Labs an. Spins bieten Fedora mit anderen Desktopumgebungen wie Plasma, Xfce, LXQt, Mate, Cinnamon und LXDE an. Fedora Labs sind dagegen zusätzliche spezialisierte Images unter anderem für Astronomie, Design, Games, Robotics oder Sicherheit.

    Der Spin für Xfce weist dabei bereits Entwicklerversionen von Paketen des kommenden, auf GTK+ 3 portierten Xfce 4.14 auf, die Fedora für ausgereift genug empfand, um sie zu veröffentlichen. Allerdings werden sich die Spins von Xfce und LXQt ein wenig verspäten, sodass hier noch etwas Geduld gefragt ist.

    Die Zukunft der Fedora Workstation

    Atomic Workstation heißt jetzt Silverblue und wird im neuen Format mit Fedora 29 erstmals veröffentlicht. Mit Silverblue arbeiten die Entwickler an einer möglichen zukünftigen Version von Fedora Workstation, die auf Flatpak und OSTree basiert und atomar aktualisiert werden soll.

    Downloads

    Alle Versionen von Fedora 29 stehen auf der Downloadseite des Projekts bereit. Wer einen Blick in die Zukunft wagen will, der findet Silverblue auf deren Projektseite zum Download. Apropos Zukunft: Gerade erst machte die Nachricht die Runde, dass IBM Red Hat übernehmen will. Das beunruhigt viele Entwickler, die sich sorgen um die Zukunft machen. IBM hat versichert, Red Hat werde weitermachen wie bisher. Es bleibt zu hoffen, dass etwaige Änderungen an Fedora vorbeigehen werden.

  • Aktuelle Entwicklungen bei Fedora Workstation

    Screenshot: FThommes

     

    In der Fedora-Experimentierküche brodeln zu jeder Zeit interessante Entwicklungen. Red-Hat-Mitarbeiter Christian Schaller berichtet in unregelmäßigen Abständen über solche Entwicklungen, die dann in absehbarer Zeit in Fedora Workstation verfügbar sein werden. Jetzt bietet die kürzlich zu Ende gegangene GNOME-Entwicklerkonferenz GUADEC den Anlass für Schaller, einen neuen Bericht zu veröffentlichen.

    Wayland im Hintergrund

    Bei den meisten derzeitigen Projekten steht Wayland im Hintergrund. So etwa auch bei Remote Desktop und Desktop-Sharing. Hier stellen Unterschiede von X11 zum von Fedora Workstation seit einigen Veröffentlichungen als Standard eingesetzten Wayland-Protokoll die Entwickler vor neue Herausforderungen.

    Entfernte Desktops laden

    Jonas Ådahl arbeitet derzeit an Remote-Desktop für die GNOME-Shell. Die für Ende Oktober erwartete Veröffentlichung von Fedora 29 Workstation soll eine VNC-basierte Implementierung des Remote-Desktop bieten, weitere Protokolle wie etwa Spice sollen folgen. VNC ist zwar ziemlich veraltet, ist trotzdem noch recht weit verbreitet und anspruchslos im Einsatz. Um die Wayland-Sitzung über VNC zu teilen kommt das Multimedia-Framework PipeWire zum Einsatz, das vom GStreamer-Pionier Wim Taymans entwickelt wird.

    Desktop-Sharing per WebRTC

    Jan Grulich, Tomas Popela und Eike Rathke arbeiten seit geraumer Zeit am Desktop-Sharing unter Wayland mit Firefox und Chromium unter Zuhilfenahme von WebRTC. Auch hier spielt PipeWire das Bindeglied, indem die Browser jeweils ein PipeWire-Backend erhalten. Eine gepatchte Firefox-Version steht bereits seit einiger Zeit zum Testen für Fedora 28 und Fedora Rawhide bereit.

    PipeWire

    Auf der GUADEC 2017 hielt Entwickler Wim Taymans einen Vortrag über die Ideen hinter und den Entwicklungsstand von PipeWire. Hier wird unter anderem beständig an der Nachbildung der Funktionalität des professionellen Audio-Servers Jack gearbeitet. Die Player Totem und Rhythmbox können zum Abspielen von Audio über PipeWire mit dem PulseAudio-GStreamer-Plugin genutzt werden, nachdem ein Ersatz für die libpulse.so implementiert wurde.

    Im Herbst wird ein PipeWire und Linux Audio Hackfest stattfinden, bei dem die Teams von  PipeWire, GStreamer, Totem, GNOME Control Center, PulseAudio und Jack über die weitere Entwicklung von PipeWire diskutieren.

    GNOME Builder im Container

    GNOME Builder, die integrierte Entwicklungsumgebung, die seit einiger Zeit in den GNOME-Desktop integriert ist, wird maßgeblich von Christian Hergert entwickelt. Die derzeitige Entwicklung geht in Richtung Unterstützung für die Entwicklung hin zu Embedded-Geräten wie dem kommenden Linux-Smartphone Purism 5. Christian erwähnte zudem in seinem GUADEC-Vortrag, dass Builder wahrscheinlich die erste »Container Native IDE«  der Welt ist, indem es einerseits mit dem Ziel entwickelt wird, als Flatpak verteilt zu werden, als auch, Flatpaks als primäres Ausgabeformat zu erstellen.

  • Stratis – Red Hats neues Storage-System

    Stratis – Red Hats neues Storage-System

    Im August 2017 erklärte Red Hat seine vermutlich endgültige Abkehr vom Btrfs-Dateisystem. Bald darauf wurde klar, dass ein neu gestartetes Projekt zu Red Hats künftiger Speichertechnologie werden soll. Die Rede ist von Stratis, dass vor wenigen Tagen mit Fedora 28 erstmals vorgestellt wurde und für Fedora 29 eine erste stabile Version 1.0 anstrebt.  Stratis soll eine ähnliche Funktionalität wie ZFS und Btrfs bieten, allerdings basierend auf einem hybriden Modell. Da ZFS aus lizenzrechtlicher Sicht für Red Hat nicht infrage kommt und Btrfs eigene Probleme im Zusammenspiel mit Docker zeigt, entschied sich Red Hat zu dieser partiellen Neuentwicklung, die vor rund einem Jahr in einem White-Paper (PDF) vom Hauptentwickler Andy Grover erstmals beschrieben wurde.

    Nicht neu erfunden

    Dabei will Red Hat aber kein neues Dateisystem schreiben, sondern aus bestehenden Komponenten eine Lösung bauen, die dem Anwender eine gut integrierte Lösung mit konsistenter Konfiguration bietet. Hauptentwickler Andy Grover beschreibt es in dem Papier als eine Kommandozeilenlösung mit einer umfassenden API, die auf bestehenden Techniken aufbaut und in Rust und Python umgesetzt wird. Stratis soll dabei nicht nur den Geschäftskunden von Red Hat die Konfiguration und Pflege riesiger Disk-Arrays erleichtern, sondern auch dem Desktop-Anwender mit nur einer SSD.

    Vereinfachend

    Stratis zielt darauf ab, drei Dinge einfacher zu machen: die anfängliche Konfiguration des Speichers, spätere Änderungen und die Verwendung erweiterter Speicherfunktionen wie Snapshots, Thin Provisioning und sogar Tiering. Es bedient sich dabei des Konzepts des Storage-Pools, bei dem eine oder mehrere Disks zunächst unspezifiziert zusammengefasst werden, um später mehr Flexibilität zu bieten als dies feste Partitionen tun. Im Gegensatz zu LVM wird, ähnlich wie bei einem Virtual-Machine-File-System (VMF) das Dateisystem mit dem Pool verschmolzen, was bei Btrfs als Subvolume bekannt ist. Bei Stratis heißt es einfach Filesystem, dessen einzige Größenbeschränkung die Größe des Pools darstellt.

    Was unterscheidet Stratis von ZFS, Btrfs und LVM?

    Anstatt ganz von vorne zu beginnen versuchen die Entwickler bei Stratis von den Fehlern der Vorgänger zu lernen und bestehende Komponenten zu nutzen. Das Device-Mapper-Framework (DM), dessen sich auch LVM bedient um blockorientierten Geräten Funktionen wie RAID und Thin Provisioning  zur Verfügung zu stellen arbeitet hierfür zusammen mit dem XFS-Dateisystem. Von ZFS wurde der kommandozeilenbasierte Ansatz übernommen sowie die Art und Weise, wie Festplatten zu einem Pool hinzugefügt oder ersetzt werden.

    Bei Btrfs wurden Anleihen beim Konzept der Dateisystem-Snapshots und der Redundanz gemacht. Am weitesten reicht die Verwandtschaft jedoch bei LVM, da beide auf DM als grundlegende Komponente setzen. Stratis soll aber einfacher zu handhaben sein, ohne allzu viel von der breiten Funktionalität von LVM vermissen zu lassen. Somit wird Stratis eine weitere Möglichkeit bieten, einen Storage-Pool zu konfigurieren und zu verwalten.

    Zeitplan offen

    Mit Version 1.0 soll Stratis Snapshots beherrschen, für Stratis 2.0 ist die Integration von RAID und Write-Through-Caching geplant. Mit Version 3.0 soll die Funktionsparität mit ZFS erreicht sein. Abgesehen von Stratis 1.0, das mit Fedora 29 im Oktober erwartet wird, ist noch kein weiterer Zeitplan bekannt.

  • Neue Fedora-Initiative »Team Silverblue«

    Screenshot: ft

     

    Fedora ist zweifelsohne die innovativste unter den bekannteren Linux-Distributionen. Das ist nicht zuletzt Red Hat geschuldet, das einerseits genügend Entwickler zur Verfügung stellt und andererseits auf viele der bei Fedora getätigten Innovationen später für ihre Enterprise-Edition RHEL zurückgreift. Jetzt wurde das Fedora Council als oberstes Leitungsgremium über eine neue Initiative informiert, die auf den Namen »Team Silverblue« hört. In einem PDF werden Hintergrund und Zielsetzung näher erläutert. Das Projekt lief seit Fedora 25 bisher eher im Hintergrund unter der Bezeichnung »Fedora Atomic Workstation« und hatte zum Ziel, das Beste aus Fedora Workstation und der Fedora-Cloud- und Container-Ausgabe »Project Atomic« zu vereinen. Für Fedora 27 wurde ein Image zum Testen bereitgestellt. Seit Februar 2018, nach den DevConf- und FOSDEM-Konferenzen nahm das Projekt Fahrt auf. Matthias Clasen hat seitdem in seinem Blog mehr als ein Dutzend Artikel zum Thema veröffentlicht.

    Atomic Workstation

    Genau wie Atomic Host verwendet Atomic Workstation RPM-OSTree anstelle des in der Workstation-Ausgabe verwendeten DNF als Update-Manager. Dabei werden Updates in der Form eines Image ausgerollt. Wenn dabei etwas schief geht, kann das System auf den vorherigen Stand zurückgerollt werden. Atomic Workstation ist jedoch ansonsten auf die gleichen Anwendungsfälle ausgerichtet wie die reguläre Workstation Edition. Allerdings gibt es einige Unterschiede zwischen den beiden über das Update-Modell hinaus. So werden die Desktop-Applikationen bei  Atomic Workstation im Flatpak-Format ausgeliefert und die Entwicklung findet in Containern statt.

    Team Silverblue

    Jetzt soll das Projekt von Fedora Atomic Workstation zu Team Silverblue umbenannt werden und einer breiteren Öffentlichkeit zugänglich gemacht werden. Langfristiges Ziel dieser Bemühungen ist es, Fedora Workstation in eine Image-basiertes System zu transformieren, bei dem Anwendungen vom Betriebssystem getrennt sind und Updates mit RPM-OSTree atomar sind. Fedora-Entwickler haben in den letzten Jahren die meisten Teile für diesen neuen Desktop bereits gebaut: OSTree, Flatpak, Flathub sowie die Paketverwaltung GNOME-Software.

    Künftige Planung

    Die Linux-Distribution Endless OS hat das Modell auf Basis dieser Komponenten bereits in weiten Teilen umgesetzt. Die Planung von Team Silverblue sieht vor, mit Fedora 29 den Bekanntheitsgrad über die Fedora-Webseite zu erhöhen und mit Fedora 30, vielleicht als »Fedora Silverblue«, voll integriert zu sein. Das Image soll künftig gleichberechtigt neben der normalen Ausgabe von Fedora Workstation stehen und wendet sich bei gleichen Anwendungsfällen  an enthusiastische Anwender und Entwickler, die einen Desktop suchen, der den Ansprüchen dieser Klientel standhält und ein Container-orientiertes Arbeiten unterstützt.

  • Fedora 27 Workstation und Server erneut verschoben

    Fedora 27 Workstation
    Screenshot: FThommes

    Das Fedora-Team hat kein Glück mit der Herausgabe von Fedora 27. Bereits vor der Beta-Version drei mal verschoben, musste jetzt auch die stabile Veröffentlichung von Fedora 27 Workstation um eine Woche nach hinten verlegt werden. Das beschloss am gestrigen Donnerstag das Fedora-Steuerungskomitee FESCo auf seiner wöchentlichen GO/NO-GO-Sitzung. Obwohl, mit fehlendem Glück hat es diesmal wohl eher weniger zu tun. Schaut man sich die blockierenden Fehler an, so sind das keine Fehler in Paketen mit Anwender-Software. Sie wirken eher wie unnötige Versäumnisse bei der Vorbereitung der Veröffentlichung.

    Keine wirklichen Bugs

    Als Grund für die Verschiebung dient die Tatsache, dass es noch keinen Release-Candidate gibt. Zudem wurden von 11 in der Sitzung diskutierten Bugs drei zu Release-Blockern erklärt. Diese drehen sich allesamt um Fehler in der Release-Vorbereitung. Bei zwei der Release-Blocker geht es um fehlende Pakete, die nach den Statuten für eine Veröffentlichung unabdingbar sind. Dabei geht es einmal um ein Paket mit den finalen Release-Notes in der richtigen Version. Zum anderen fehlt das Paket spin-kickstarts, das bei der Erstellung von Fedora-Release-Images vorhanden sein muss. Für den dritten Release-Blocker ist ein zusätzlich noch eingebundenes Repository verantwortlich.

    Auch Fedora Server verschoben

    Von der Verschiebung ebenfalls betroffen ist Fedora Server 27. Hier war bereits länger klar, dass das Release dieses Mal vom Veröffentlichungszeitplan abgekoppelt werden musste. Der Grund für die Abkoppelung sind die aufwendigen Arbeiten an der Modularisierung der Server-Variante im Projekt Boltron. Auch hier ist der Grund für die Verschiebung ein noch nicht vorhandener Release-Candidate.

    Laut dem angepassten  Release-Plan erscheint Fedora 27 Workstation nun am 7. November. Am selben Tag soll die Beta-Version des Fedora Modular Server 27 erscheinen. Hier ist das Datum für die stabile Veröffentlichung auf den 19. Dezember festgelegt worden.