Vor einigen Tagen wurde durch Linus Torvald, nach längerem hin und her, die Freigabe zum nagelneuen Hauptentwicklungsstrang für Linux erteilt. Somit können sich alle auf eine gerneralüberholte neue Version Linux / Kernel 5.5 freuen ab Anfang Februar '20!
Wie bei eigentlich bei jeder neuen Hauptversion, sind diesmal auch über 10000 Änderungen, Neuerungen sowie Ergänzungen mit an Bord, die teilweise komplett neue Features beinhalten, aber auch viele bestehende ergänzen und verbessern!
Einige Neuerungen überraschen eventuell, andere sind schon eine gefühlte Ewigkeit von der Community erwartet worden und werden nun endlich bedient.
Die wichtigsten dieser Verbesserungen hier einmal im Überblick (eine kleine Auswahl):
Der neue Kernel bringt endlich Krypto-Funktionen für Wireguard, gegen die sich die Entwickler lange gesperrt haben. Support für die Furore machende VPN-Technik folgt mit an Sicherheit grenzender Wahrscheinlichkeit dann Ende März oder Anfang April erwarteten Kernel
Linux 5.5 bringt einige Umbauten am Btrfs-Dateisystem mit, die dessen Performance verbessern und Unterstützung für neue RAID-1-Verfahren nachrüsten.
Linux 5.5 läuft endlich auch auf dem neuesten Raspberry-Pi-Modell – zwar noch unrund, aber das soll sich bald bessern.
Durch Verbesserungen beim Live Patching wird es leichter, Sicherheitslücken in Kernel-Code zu beheben, der bereits zuvor im Betrieb erheblich modifiziert wurde.
Ein neuer Load-Balancing-Algorithmus verteilt die Arbeit anders auf die Prozessorkerne und versucht so, mehr Geschwindigkeit herauszuholen.
Die Virtualisierung mit KVM soll dank Optimierungen an Geschwindigkeit zulegen.
Der neue Kernel kann weitere Firewall- und Routing-Arbeiten an Netzwerkchips delegieren und hebelt nebenbei auch eine kneifende Namensbeschränkung bei Netzwerkgeräten aus.
Umbauten bei der BPF Virtual Machine steigern dessen Geschwindigkeit und öffnen weitere Anwendungsgebiete.
Ein riesiger Haufen neuer und überarbeiteter Treiber verbessert den Hardware-Support signifikant. Durch die Umbauten wird jetzt etwa die neue Radeon RX 5600 unterstützt. Bei den Sunxi-SoCs einiger bekannter Einplatinencomputern lässt sich nun der H.265-Decoder verwenden. Ein Realtek-WLAN-Treiber liefert bessere Performance. Außerdem gab es gleich bei mehreren Treibern kleinere Änderungen, die bei Notebooks auf etwas längere Akkulaufzeiten hoffen lassen. All das ist aber nur die sprichwörtliche Spitze des Eisbergs von Treiberneuerungen.
Einige Optimierungen am Netzwerkcode versprechen, die Performance in WLANs und bei der Kommunikation mit Virtual Machines (VMs) zu verbessern. Auch Multichannel-Support bei CIFS, das Samba- und Windows-Freigaben ins Dateisystem einhängt, soll die Geschwindigkeit steigern.
Die Kernel-Entwickler haben einen weiteren Mechanismus integriert, um persistente Speichermodule wie Intels Optane DC Persistent Memory einzubinden.
Einen Sicherheitsgewinn verspricht eine Infrastruktur, die eine alte x86-Technik zur Hardware-Ansteuerung emuliert.
Wie man an der Aufstellung unschwer erkennen kann, sind das alles handfeste Features, die sich vor allem beim Server-Betrieb und in der Netzwerktechnik sowie der Sicherheit auswirken. Aber auch für den Standard-Konsumenten sind massig Vorteile vorhanden. Alleine die riesige Erweiterung im Treiberbereich, bezüglich Audio, Video und Wlan etc. werden zukünftig viele merkbare Vorteile in den vielen Linux-Consumerversionen, wie Ubuntu, Mint usw. hinzukommen!
Für März / April ist sogar schon eine weitere Aktualisierung des Hauptentwicklerstrangs auf Version 5.6 angesagt, um die Bereiche zu ergänzen, die in dieser Version wohl nicht mehr gepasst haben…
(Quellen: u.a. Heise & Community)
Richtig innovativ wäre es gewesen, wenn der neue Kernel systemd nicht mehr unterstützt hätte. Gerade Torvald, als einer der schärfsten systemd Kritiker, hätte hier ein Zeichen setzen können.
Viele Linux-Enthusiasten und -Entwickler sind ja der Meinung, dass systemd die Linux-Community nachhaltig gespalten und deswegen mehr Schaden als Nutzen verursacht hat.
Stimmt schon, vor allem weil Torvald diesen Daemon schon seit 3-4 Jahren als bösen Dämon sieht! Da es aber im Vorfeld zu 5.5 schon wieder Palaver um kleinste Kleinigkeiten gab. denke ich das er den „Weg des geringsten Widerstands“ dabei gegangen ist, um überhaupt nun ein „stable Rel.“ präsentieren zu können…?
Ich kanns ja sogar nachvollziehen, denn anfänglich war „systemd“ ja mal eine klasse Idee, mitlerweile ist der Dienst einfach zu einem voluminösen Sicherheitsleck verkommen bzw. wurden die letzten Jahre eigentlich nur noch dubiose Dinge darüber umgesetzt…wenn man nur mal so an die Google-DNS Geschichte denkt! Hinzu kommt ja auch noch die teilweise grottige Programmierung, die ja auch schon DoS usw. Tür und Tor aufgemacht hatte…etc. pp.
Ich glaube auch nicht, dass es bei dem heutigen Stand so einfach wäre systemd einfach so abzuschaffen! Denn ohne dabei wieder in die Steinzeit zurückzufallen in Punkto Performance usw. geht das ja kaum (IMO). Das alte SysVinit müsste als kompatibelste Alternative quasi auch wieder neu entwickelt werden, um jetzige Standards zu halten.
Andere Distris haben ihre alternativen Daemons schon wieder vor langem beerdigt. Und bei der momentanen Spaltung der wirklich fähigen Community, wo mitlerweile persönliche Befindlichkeiten in den Fokus gerückt werden, anstatt sich um das Produkt an sich zu kümmern, lässt für die nahe Zukunft eigentlich nichts gutes mehr erwarten - eigentlich darf so etwas nicht passieren!!!
Das Problem bei systemd ist, dass dieser Daemon von zwei Leuten hauptsächlich entwickelt wurde. Und dahingehend die komplette Community bis zur Veröffentlichung ausgeschlossen war.
Beim veralteten SysVinit wurde Linux quasi drum herum entwickelt, weil ja SysV von Anfang an da war. Somit hat das dann auch immer funktioniert. Und deswegen wurde das warscheinlich auch nicht auf die heutigen Bedürfnisse weiterentwickelt, weil es ja trotzdem immer lief.
Bei systemd ist es halt genau andersrum. Da sind die Linux Distros und der Kernel schon vorhanden, aber müssen auf einmal einen komplett neuen System-/Init-Dienst vertrauen und zusammenarbeiten. Ohne das überhaupt auf die Bedürfnisse der einzelnen Distros geachtet wurde.
Da aber systemd der einzige, zeitgerechte Systemstart-Daemon ist mussten zwangsläufig die vielen Distros diesen nutzen. Egal wie fehlerhaft und ominös das Ding ist.
OpenRC scheint für die großen Distros ja irgendwie keine Alternative zu sein, wenn se das noch nichtmal optional in ihr OS integrieren. Obwohl Gentoo-Linux und BSD z.B. das wiederum nutzen, weil es so gut und sicher ist. Warscheinlich wollen die Linux-Entwickler bei so wichtigen Prozessen nicht mehr auf Damonen vertrauen, wo man mit Skripten alles anpassen kann.
systemd geht ja eher den Weg der Restriktion. Es macht das was es macht und keiner kann es verhindern oder ändern.
Stimmt schon…wenigstens optional wäre das zumindest eine Alternative gewesen! Alleine schon, um die Gemüter etwas abzukühlen…
Es wird ja garantiert vor dem Release jetzt, mit darüber diskutiert worden sein um ein für und wieder! Vor allem hätten durch die Integration doch beide Seiten, mehr oder weniger, ihren Willen bekommen! Die systemd - Gegner hätten einen echten Ersatz bekommen. Die Verfechter einen Dienst, der fast identische Funktionen liefert.
Zumal openRC keine Nebelkerze ist und 13 Jahre erfolgreiche Entwicklung hinter sich hat! OpenRC mit openrc-init, kann das /sbin/init ersetzen, und der standardmäßige Anbieter für das init-Programm wäre SysVinit für OpenRC…als Option doch wohl mehr, als nur eine Überlegung wert.
