News Release Candidate: Linus Torvalds hat den neuen Linux-Kernel 6.0 freigegeben

[Tanzmusikus]

Zeitlich kamen die sogenannten V5-Patches aber etwas zu spät und haben das Zeitfenster für Linux 6.0 und den aktuellen Release Candidate verpast. Die gepatchten P-State-Treiber werden damit voraussichtlich in Linux 6.1 mit einfließen.

Knapp daneben ist auch vorbei, sagt man im Fussball.
Hier ist es ja nur eine Timeline. 😉

Grüße

 

[0x8100]

Also ich hab gerade mal den Kernel gezogen und das war ein über 200 MB großer tarball. Wenn ihr micht fragt ist der Linux-Kernel inzwischen viel zu fett geworden.

solange der kernel kleiner ist als bei einem gewissen anderen system die gpu treiber alleine habe ich damit kein problem. zumal der kernel selbst wesentlich kleiner ist, der grossteil kommt von den treibern. aber du wolltest ja sicherlich nur stänkern.

 

[andy_m4]

Welche denn z.B.?

Zum Beispiel das Linux immer noch ein sehr monolithisches System ist. Was die Implikation hat, das ein Problem an einer Stelle den ganzen Kernel mit in den Abgrund reißen kann.

Auch hat Linux Probleme eingeführt die es im traditionellen UNIX nicht gab. Nämlich das es für ein Problem unterschiedliche konkurrierende Lösungen gibt. Guck Dir nur allein die Anzahl an unterschiedlichen Sicherheitsframeworks an (AppArmor, SELinux, Secomp und wie sie alle heißen). Klar. Man kann sagen, das führt dann auch dazu das man für seinen konkreten Fall sich das Passenste aussuchen kann. Aber es bringt auch viel Komplexität in den Kernel und damit natürlich auch potentiell viele Bugs.

Man braucht auch nur mal gucken was für andere Systeme es noch gibt. Ich denke da z.B. an Plan-9 welches die Unix-Philosophie konsequenter umgesetzt hat, was dazu führt das es für bestimmte Probleme einfachere Lösung gibt und überhaupt das System weniger komplex gehalten werden kann.

Klar kann man trotzdem sagen: Na gut. Wir haben mit Linux ein System was seine Probleme hat. Aber im Großen und Ganzen funktioniert es in der Praxis gut und warum sollte man das alles wegwerfen? Vor allem da auch ein neues Projekt erst mal Kinderkrankheiten mitsich bringt und eh man einen Reifegrad hat, wo es auch praktisch einsetzbar ist wird ne ganze Weile vergehen und mit viel Aufwand verbunden sein.

Die Frage ist aber, ob das so bleibt. Ob das ganze auch künftig beherrschbar ist oder uns die Komplexität irgendwann das Genick bricht. Es könnte nämlich sein, das gar nicht die Frage ist ob wir das tun müssen, sondern wann. Und umso später man startet, umso schwieriger und aufwändiger wird es.

Ich finde schon das das Fragen sind, die man zumindest mal diskutieren sollte.

Ähhh, dann kompiliere dir deinen eigenen und wähle alle Optionen ab, die du nicht brauchst?!

Ja. Kann man. Aber wie oft geschieht das in der Praxis schon? In der Regel wird der Kernel benutzt, der der Distribution bei liegt. Und der wird eher fett sein. Und muss er auch sein weil unterschiedliche Programme benutzen unterschiedliche Features.

Tarball fallen 84% allein auf drivers, arch, fs und Documentation.

Ja. Alles weg. Gleich die Gelegenheit nutzen mehr auf Open-Source-Hardware zu setzen. Denn auch die Hardware ist viel zu komplex. Sieht man ja allein an den ganzen Sicherheitsproblemen auch aktuell wieder in den CPUs. Und glaubt mal gar nicht das es bei GPUs und Co so viel besser aussieht.
Gut. Der Vorschlag wäre vielleicht etwas radikal. :-) Aber wäre ja schon einiges gewonnen, wenn mehr Sachen out-of-tree sein könnten. Wenn es stabile Kernel-Schnittstellen gäbe, dann ginge das ja. Das würde dann auch einen Schritt mehr hin zu echter Modularität bedeuten.

 

[foofoobar]

Es ist nicht der Kernel, sondern die Kernelmodule für Hardware und Architekturen der letzten 30 Jahre(? ) , die das aufblähen. Von dem entpackten Tarball fallen 84% allein auf drivers, arch, fs und Documentation. Der eigentliche "kernel" Ordner hat nur 11 MB und keine halbe Million Zeilen. Das sollte eigentlich überschaubar sein.

Zum Beispiel besteht wohl ein großer Teil des AMD GPU-Treibers aus automatisch generierten Registerbeschreibungen welche aus den VHDL-Sourcen generiert werden.

 

[madmax2010]

Besten noch mit Blockchains und "AI" verzahnt ist,

AI? Ham wa da

because more than half of it is yet another AMD GPU register dump. And the Habanalabs Gaudi2 people want to play in that space too

letzteres sind halt dedizierte AI ASICs und da kommen gerade einige Unternehmen in de Bereich nach

Ja. Alles weg. Gleich die Gelegenheit nutzen mehr auf Open-Source-Hardware zu setzen. Denn auch die Hardware ist viel zu komplex. Sieht man ja allein an den ganzen Sicherheitsproblemen auch aktuell wieder in den CPUs. Und glaubt mal gar nicht das es bei GPUs und Co so viel besser aussieht.
Gut. Der Vorschlag wäre vielleicht etwas radikal. :-)

Ding Dong!
Guten Tag, ich bin von Vorwerk und moechte Ihnen dieses schicke Laptop mit offener Hardware vorstellen.
https://mntre.com/media/reform_md/2020-05-08-the-much-more-personal-computer.html
Im prinzip der Novena von damals in weniger Hacky und modern

 

[0x8100]

Ja. Kann man. Aber wie oft geschieht das in der Praxis schon? In der Regel wird der Kernel benutzt, der der Distribution bei liegt. Und der wird eher fett sein. Und muss er auch sein weil unterschiedliche Programme benutzen unterschiedliche Features.

ach komm... der kernel hier ist z.b. 11 ganze MB gross. der rest sind optionale treiber, die nur für vorhandene hardware oder features genutzt werden.

$ ll -h /boot/vmlinuz-5.15.0-46-generic
-rw------- 1 root root 11M Aug  4 19:34 /boot/vmlinuz-5.15.0-46-generic
$ du -h --max-depth=0 /lib/modules/5.15.0-46-generic/
459M    /lib/modules/5.15.0-46-generic/

 

[foofoobar]

Zum Beispiel das Linux immer noch ein sehr monolithisches System ist. Was die Implikation hat, das ein Problem an einer Stelle den ganzen Kernel mit in den Abgrund reißen kann.

In Zeiten von Spectre &Co steht ein µ-Kernel noch mehr auf der Verliererseite. Und was Apple und MS mal als µ-Kernel verkauft war alles Mögliche aber kein µ-Kernel.

Auch hat Linux Probleme eingeführt die es im traditionellen UNIX nicht gab. Nämlich das es für ein Problem unterschiedliche konkurrierende Lösungen gibt. Guck Dir nur allein die Anzahl an unterschiedlichen Sicherheitsframeworks an (AppArmor, SELinux, Secomp und wie sie alle heißen). Klar. Man kann sagen, das führt dann auch dazu das man für seinen konkreten Fall sich das Passenste aussuchen kann. Aber es bringt auch viel Komplexität in den Kernel und damit natürlich auch potentiell viele Bugs.

BSD-Sockets vs. SYSV-Streams gab es auch schon früher. Oder diese ganzen Kompatibilitätslayer von Solaris.

 

[pseudopseudonym]

Ja. Kann man. Aber wie oft geschieht das in der Praxis schon? In der Regel wird der Kernel benutzt, der der Distribution bei liegt. Und der wird eher fett sein. Und muss er auch sein weil unterschiedliche Programme benutzen unterschiedliche Features.

Und wo ist das Problem? Die meisten sind wie ich faule Säcke und wissen nicht einmal, wie groß der Kernel ist.

 

[andy_m4]

Bei dem was heutzutage als modern gilt, hätte ich eher Angst davor. Am Ende kriegen wir ein JS-Kernel, der über 10 verschachtelte Frameworks läuft, unzählige externe Ressourcen ungeprüft nachlädt und am Besten noch mit Blockchains und "AI" verzahnt ist, mit kostenpflichtigen DLCs

Da bin ich ganz bei Dir. Das ist auch nicht das, was ich meinte.

Wobei, um mal jetzt Javascript aufzugreifen, man kann durchaus auch mal über die Programmiersprache nachdenken. C ist jetzt nicht unbedingt ne Programmiersprache die über jeden Zweifel erhaben ist. Nicht falsch verstehen. Ich mag C. Aber es bietet halt auch ne Menge an potentiellen Stolperfallen und das Abstraktionsniveau ist nach heutigen Maßstäben auch her gering. Sowas wie Rust könnte da ein potentiell interessanter Kandidat sein. Da gibts auch schon experimentelle Systeme die das nehmen (Redox) und es ist auf den Weg dahin auch als Programmiersprache für Module des Linux-Kernels akzeptiert zu werden.

solange der kernel kleiner ist als bei einem gewissen anderen system die gpu treiber alleine habe ich damit kein problem.

Na ich weiß nicht ob es immer so zielführend ist auf Systeme zu gucken, wo es schlechter ist. Selbstkritik zu vermeiden unter den Vorwand, das es woanders schlimmer ist .... würde ich auch als Anspruch ein bisschen dünn finden.

Guten Tag, ich bin von Vorwerk und moechte Ihnen dieses schicke Laptop mit offener Hardware vorstellen.
https://mntre.com/media/reform_md/2020-05-08-the-much-more-personal-computer.html

Das sieht wirklich interessant aus. Danke für den Link.

Ergänzung (15. August 2022)

Die meisten sind wie ich faule Säcke und wissen nicht einmal, wie groß der Kernel ist.

Du Banause!
Du bist halt auch kein echter Linuxer. Der durch die Config kämpft. Den Compiler mit netten Flags füttert und bei Laune hält. Den noch warmen Kernel dann liebevoll beim Bootloader bekannt macht. :-)

 

[foofoobar]

Die Frage ist aber, ob das so bleibt. Ob das ganze auch künftig beherrschbar ist oder uns die Komplexität irgendwann das Genick bricht. Es könnte nämlich sein, das gar nicht die Frage ist ob wir das tun müssen, sondern wann. Und umso später man startet, umso schwieriger und aufwändiger wird es.

Jedenfalls war Linux nicht so gefickt wie MS als Spectre kam, man konnte das System durchsuchen und alles gegen einen neuen Compiler und Macros bauen. MS konnte das nicht. Die Butze mit dem Hyper-Wifi-Stick von Schlong-Dong Limited kriegt man nicht so schnell ran.

 

[darthbermel]

Wobei, um mal jetzt Javascript aufzugreifen, man kann durchaus auch mal über die Programmiersprache nachdenken. C ist jetzt nicht unbedingt ne Programmiersprache die über jeden Zweifel erhaben ist. Nicht falsch verstehen. Ich mag C. Aber es bietet halt auch ne Menge an potentiellen Stolperfallen und das Abstraktionsniveau ist nach heutigen Maßstäben auch her gering. Sowas wie Rust könnte da ein potentiell interessanter Kandidat sein.

Rust soll ja bald schon losgehen:
https://thenewstack.io/rust-in-the-linux-kernel-by-2023-linus-torvalds-predicts/

 

[foofoobar]

Ich mag C. Aber es bietet halt auch ne Menge an potentiellen Stolperfallen und das Abstraktionsniveau ist nach heutigen Maßstäben auch her gering. Sowas wie Rust könnte da ein potentiell interessanter Kandidat sein.

Zu Rust im Kernel hat Linus T. was sehr wichtiges gesagt, Rust hat in seiner Runtime Situationen wo die Runtime einfach per exit() aussteigt. Für einen OS-Kernel ist sowas total ungeeignet. EBPF könnte da interessant werden.

 

[andy_m4]

In Zeiten von Spectre &Co steht ein µ-Kernel noch mehr auf der Verliererseite.

Ein Komplexitätsproblem haben wir halt nicht nur bei der Software, sondern auch bei der Hardware. Mit ähnlichen Auswirkungen. Wir sollten auf beiden Seiten die Komplexität reduzieren. Man kann ja das eine tun ohne das andere zu lassen.

Und was Apple und MS mal als µ-Kernel verkauft war alles Mögliche aber kein µ-Kernel.

Von Apple und Microsoft hab ich gar nicht gesprochen daher bin ich etwas verwundert über den Einwand. Das einzige was hier im Thread zur Sprache kam war HURD. und dem kann man viel vorwerfen. Aber sicher nicht nicht genug Microkernel zu sein. :-)

Jedenfalls war Linux nicht so gefickt wie MS

Ich weiß nicht, was diese ständigen Microsoft-Vergleiche sollen.
Wie bereits gesagt: Schlechtere Systeme als Maßstab zu nehmen ist jetzt nicht gerade die beste Variante, um mal über mögliche Probleme und deren Lösung zu sprechen.
Offenbar ist es mit manchen schwierig sich kritisch mit Linux auseinander zu setzen ohne das es zu dem Millionsten sinnlosen Windows-vs-Linux-Flamewar kommt.

 

[darthbermel]

OT: beim Thema Microkernel habe gleich mal wieder die alte Diskussion Torvalds/Tanenbaum zu dem Thema rausgekramt. Herrlich :-)

 

[andy_m4]

Zu Rust im Kernel hat Linus T. was sehr wichtiges gesagt, Rust hat in seiner Runtime Situationen wo die Runtime einfach per exit() aussteigt. Für einen OS-Kernel ist sowas total ungeeignet.

Unabhängig davon ob Rust jetzt im Speziellen geeignet ist oder nicht kann man ja einfach mal ergebnisoffen darüber diskutieren ob es Sinn macht an C festzuhalten oder obs bessere Möglichkeiten gibt.
Abgesehen davon das das ein Detail der Implementierung ist und nicht der Sprache.

 

[pseudopseudonym]

Du Banause!
Du bist halt auch kein echter Linuxer. Der durch die Config kämpft. Den Compiler mit netten Flags füttert und bei Laune hält. Den noch warmen Kernel dann liebevoll beim Bootloader bekannt macht. :-)

Würde ich basteln und verzweifeln wollen, würde ich mir Windows installieren. Ich klopp mir lieber so ne pöse DAU-Distro wie Linux Mint drauf und lehn mich zurück.
Wenn ich mich an anderen Stellen mit Compilern, Configs und Code beschäftige, bekomme ich sogar Geld dafür. Das reicht dann auch.

 

[andy_m4]

OT: beim Thema Microkernel habe gleich mal wieder die alte Diskussion Torvalds/Tanenbaum zu dem Thema rausgekramt. Herrlich :-)

Ja. Legendär. :-)
Die Diskussion wird ja häufig als durch Torvalds gewonnen gewertet (vermutlich auch deshalb weil Linux erfolgreich wurde). Ich seh' das nicht so. Ich sehe auf beiden Seiten valide Punkte. Und einiges hat sich ja auch mit der Zeit überholt.

 

[madmax2010]

OT: beim Thema Microkernel habe gleich mal wieder die alte Diskussion Torvalds/Tanenbaum zu dem Thema rausgekramt. Herrlich :-)

Ich war nur mal mit Stallman und tanenbaum in einem Raum als sie ihre Ansätze diskutierten. Sie sind aber schon an der Lizenz hängen geblieben. Amüsant war es trotzdem

 

[foofoobar]

Ich weiß nicht, was diese ständigen Microsoft-Vergleiche sollen.
Wie bereits gesagt: Schlechtere Systeme als Maßstab zu nehmen ist jetzt nicht gerade die beste Variante, um mal über mögliche Probleme und deren Lösung zu sprechen.

Die kompletten Treiber-Sourcen zu haben und den Kernel als ganzes bauen zu können ist einfach ein Vorteil.
Und schicke Abstraktionen sind nicht immer schnell, und Zeit ist Geld.
Und mir ist ein freies konkurrenzfähiges System wesentlich lieber als wenn es nur rein kommerzielle Systeme geben würde weil Systeme die nach dem Prinzip der reinen Lehre gebaut sind nicht konkurrenzfähig wären.

Richtig schaue Ideen fallen halt recht selten vom Himmel.

Offenbar ist es mit manchen schwierig sich kritisch mit Linux auseinander zu setzen ohne das es zu dem Millionsten sinnlosen Windows-vs-Linux-Flamewar kommt.

Ich bekenne mich dazu ein GPL-Nazi zu sein, und Spectre hat die Vorteile aufgezeigt.

Ergänzung (15. August 2022)

Ich war nur mal mit Stallman und tanenbaum in einem Raum als sie ihre Ansätze diskutierten. Sie sind aber schon an der Lizenz hängen geblieben. Amüsant war es trotzdem

In der SGX-Enklave und den Mgmt-Funktionen von Intel-CPUs hat Minix jedenfalls ziemlich versagt.
Und die Lizenzen der BSDs haben dafür gesorgt das jeder seinen eigenen Kram gemacht hat und sich das komplett zerfasert hat und es keine zusammenhängende Weiterentwicklung gab.

 

[madmax2010]

In der SGX-Enklave und den Mgmt-Funktionen von Intel-CPUs hat Minix jedenfalls ziemlich versagt.

wie meinst? ich habe nur mitbekommen, dass minix da in teilen eingesetzt wurde.
Ich habe den teil, wenn ich hardware damit hatte, seit jeher so feste deaktiviert wie es ging.