LN-Waschpress

Schlagwort: Fedora

  • Fedora 31 glänzt mit Kernel 5.3 und GNOME 3.34

    Fedora ist die Hexenküche von Red Hat, in der viele neue Entwicklungen angestoßen werden. Damit ist das zweimal jährlich veröffentlichte Fedora die vermutlich innovativste Linux-Distribution auf dem Markt. Jetzt war es wieder so weit, Fedora 31 hat das Licht der Welt erblickt. Diese Veröffentlichung erfolgt nur wenige Tage vor dem fünfzehnten Jahrestag der Veröffentlichung von Fedora Core 1, der ersten Veröffentlichung von Fedora.

    Bereits im Juli hatte der bei Red Hat angestellte Fedora-Entwickler Christian Schaller einen ausführlichen Ausblick auf die zu erwartenden Neuerungen von Fedora 31 gegeben. Was davon die nötige Reife zur Veröffentlichung erreicht hat, verrät das Changeset. Zwei grundlegende Änderungen betreffen Anwender von 32-Bit-Maschinen und Python-Anwender.

    Gnome 3.34

    GNOME 3.34 stellt den Desktop von Fedora 31, der durch Sammelordner mehr Übersicht in der Shell erlaubt. Auch optisch wurde die GNOME-Shell an einigen Stellen aufgewertet und reagiert schneller auf Eingaben und bei Animationen. Der Standard-GNOME-Browser Web, früher als Epiphany bekannt, lässt Webseiten nun in getrennten Sandbox-Prozessen laufen, was Sicherheit und Leistung zugutekommt.

    Wayland

    Wayland ist und bleibt Thema und darf natürlich in der Liste der Verbesserungen nicht fehlen, ist doch der Gleichstand mit X11 bei der Funktionalität noch nicht ganz erreicht. Eine der Neuerungen bei GNOME 3.34 ist, dass die Position des Mauszeigers nun auch unter Wayland durch Drücken von STRG hervorgehoben wird, sofern die Funktion vorher aktiviert wurde.

    Firefox als Wayland-App

    Eine weitere wichtige Verbesserung im Hintergrund betrifft den GNOME-Fenstermanager und Wayland-Compositor Mutter. Dieser erlaubt es fortan, X-Wayland nur noch bei Bedarf zu starten, um eine X11-Applikation zu unterstützen. Zudem ist Firefox als GNOME-Wayland-Version verfügbar. In allen anderen Sitzungen wird Firefox-X11 verwendet. QT-Apps laufen mithilfe des Qt Wayland-Platform-Plugins und Qt 5.12 jetzt nativ in GNOME-Sitzungen mit Wayland.

    32-Bit auf dem Rückzug

    Fedora 31 stellt mit Linux 5.13 keine i686-Kernel mehr bereit und liefert keine 32-Bit Installationsmedien mehr aus. Zudem fallen Teile der 32-Bit Repositorien weg. Lediglich die Kernel-Header sollen weiterhin bereitgestellt werden, um die notwendigen Abhängigkeiten für 32-Bit-Programme zu bedienen, die diese Header benötigen.

    Das bedeutet nicht nur, dass Fedora 31 keine Installationen auf 32-Bit mehr unterstützt, sondern der Wegfall der Repositorien »Everything« und »Modular« trifft auch Bestandsanwender, denen lediglich die Multilib-x86_64 Repositorien bleiben.

    Python 2 bald ohne Unterstützung

    Python 2 und seine Pakete sollen mit Fedora 32 komplett aus der Distribution entfernt werden, denn am 1. Januar 2020 wird die Unterstützung für Python 2 offiziell endgültig eingestellt. Derzeit verbleiben noch 828 dieser Pakete in der Distribution. Bereits mit Fedora 31 bedeutet die Schreibweise Python ohne Zusatz jedoch, dass es sich um ein Python 3 Paket oder einen entsprechenden Befehl handelt.

    Kein SSH per Root mehr

    Fedora 31 schaltet die Kernelfunktion CgroupsV2 frei. Die standardmäßige Aktivierung der CgroupsV2 ermöglicht es Anwendungen wie Systemd, Container-Tools und Libvirt, die Vorteile der neuen Features und vieler Korrekturen seit CgroupsV1 zu nutzen. Die Nutzung des Root-Passworts zum Erstellen von SSH-Verbindungen wurde aus Sicherheitsgründen standardmäßig deaktiviert, wie das bei OpenSSH bereits seit Jahren der Fall ist.

    Das Paketformat RPM wechselt bei der Kompression von Xz zu Zstandard (Zstd), womit Pakete wesentlich schneller ausgepackt werden können. Das Paket RPM selbst wird auf Version 4.15 aktualisiert. Standard bei Node.js ist jetzt Version 12 mit 30 Monaten Langzeitunterstützung, Version 10.x verbleibt als Modul im Repository. PipeWire erhielt einige Verbesserungen und ist als technische Vorschau integriert.

    Verschiedene Varianten

    Fedora 31 steht in verschiedenen Varianten zum Download bereit. Neben Fedora Workstation und der Server-Edition stehen Fedora Silverblue, Fedora CoreOS und Fedora IoT bereit. Als alternative Architekturen werden ARM AArch64, Power und S390x bedient. Darüber hinaus bietet Fedora Spins mit verschiedenen Desktops sowie Labs mit Themenschwerpunkten wie Astronomie, Games oder Sicherheit.

  • Warum sind Paketmanager so langsam?

    Warum sind Paketmanager so langsam?

    Dieser Frage geht der bei Google tätige Entwickler Michael Stapelberg derzeit in seinem Blog und in einem Vortrag nach. Im März hatte Stapelberg seinen Rückzug aus Debian bekannt gegeben, wo er über zehn Jahre tätig war. Grund für seine Kritik an Debian waren dessen Strukturen, die ihm ein effizientes Arbeiten unmöglich machten.

    Testobjekt Paketmanager

    In der Zwischenzeit hat sich Stapelberg der Paketmanager angenommen und die bekanntesten Exemplare unter Linux systematisch untersucht. Im Grunde gibt es nur zwei Formate, von denen fast alle anderen mehr oder weniger abgeleitet sind. Dabei handelt es sich um das Debian-Paket deb und den Red Hat Package Manager rpm, die beide im Grunde Archivformate sind.

    Sie machen zu viel

    Was passiert nun, wenn wir eine Paketinstallation anstoßen? Traditionell werden zunächst die Paketlisten gelesen und die Abhängigkeiten überprüft. Darauf folgt der Download, das Entpacken der Archive und das Konfigurieren auf der Basis der im Paket hinterlegten Anweisungen. Schließlich wird das Paket in /usr/bin installiert.

    Hoffen und Bangen

    Der Moment der eigentlichen Installation nach dem Download der Pakete ist bei den hier betrachteten Paketmanagern heikel. Wenn währenddessen der Akku leer ist oder der Kernel aussteigt oder die Software fehlerhaft, haben wir meist ein Problem. Um das möglichst abzufedern, bedienen sich die Paketmanager des Linux-System-Calls fsync, um den gepufferten Dateiinhalt nicht nur im RAM zu haben, sondern auch auf den Datenträger zu schreiben. Das ist aber nur ein Grund warum eine Paketinstallation teilweise so lange dauert.

    Stapelberg hat getestet, wie lange eine Auswahl von Paketmanagern braucht, um ein kleines und ein größeres Paket zu installieren:

    Quelle: Michael Stapelberg

    Dabei hat das Paket ack eine Größe von 70 Kb, während qemu im Download 70 MB in die Waagschale wirft. Fedora macht bei beiden Paketen die schlechteste Figur. Die herunterzuladenden Metadaten stehen in keinem Verhältnis zur Größe des Pakets und das umso mehr, je kleiner das Paket ist.

    Maintainer-Scripte

    Ein weiterer Grund, warum Paketmanager lange für eine Paketinstallation brauchen sind die Maintainer-Scripte, die während der Installation über Hooks und Trigger abgearbeitet werden. Dabei werden Anweisungen aus den mit im Paket befindlichen Dateien preinst und postinst ausgeführt, die nach Stapelbergs Ansicht meist auch beim ersten Programmstart aufgerufen werden könnten. Zudem verhindert dieses Abarbeiten der Scripte, dass Pakete parallel installiert werden können.

    Aus diesen Beobachtungen zog er den Schluss, dass entweder das Potenzial besteht, den Paketmanager selbst zu optimieren oder was das System macht, ist einfach zu komplex. Das veranlasste ihn dazu, eine experimentelle Distribution namens distri zu erstellen, die einige Dinge anders angeht und über einen wieselflinken Paketmanager verfügt.

    Nicht ganz neu

    Dabei hat Stapelberg das Rad nicht völlig neu erfunden, sondern verwendet Ideen aus der Distribution NixOS und deren Paketmanager Nix. Betrachtet man obige Grafik, so schafft es Nix einerseits, die benötigten Daten klein zu halten, erreicht aber andererseits nur lausige Übertragungsraten, sodass von der möglichen Geschwindigkeit nichts übrig bleibt. Stapelberg vermutet hier Implementationsfehler. Alpine und Arch Linux sind deutlich schneller als der Rest. Sie machen weniger als der Rest und das effizienter.

    Images anstatt Archive

    Stapelberg verwendet anstelle von Archiven, die entpackt werden müssen, Images, die schnell gemounted werden können, ähnlich wie bei AppImage oder Snap. Als Format kommen nur lesbare Squash-Images zum Zug, gemounted wird per FUSE. Ein weiterer Vorteil dieser Herangehensweise ist, dass die Pakete nicht verändert werden können. Ähnlich wie bei NixOS werden alle Bestandteile eines Pakets in ein einziges Verzeichnis installiert.

    Wer näheres dazu lesen möchte, findet Details im Blog. Die Distribution soll ihren experimentellen Charakter behalten, kann aber von GitHub in verschiedenen Formaten heruntergeladen und getestet werden.

  • 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.

    https://www.youtube.com/watch?v=Z9hPtg-caJ0
  • 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.