News Linux Kernel 7.2: „Umfangreicher als ich mir gewünscht habe“, sagt Linus Torvalds

sedot schrieb:
Bazzite sollte sich als immutable, atomic Distro doch selbst aktualisieren oder verwechsle ich gerade was?
Ne nicht wirklich... immutible heißt quasi nur das das Basissystem read only ist und nur als ganzes quasi ersetzt werden kann bzw vom User nicht geändert werden kann direkt also direkt dateien Löschen oder verändern, mehr heißt das nicht.

Also alle User Anwendungen laufen dort dann in der Regel als Flatpak zumindest bei Bazzite. man kann das image wohl auch verändern mit der Brechstange aber die gehen dann beim nächsten Update verloren weil alles überschrieben wird. Es gibt natürlich lockdateien oder anderes zeug das auch beschreibbar ist und nicht beim update überschrieben werden aber große teile des systems werden überschrieben. wenn dann willst dateien zusätzlich dazu machen, das geht teilweise also gewisse konfigurationen kann man hinzufügen, also quasi wie ne Patch datei oder so. Systemd Dienste und sowas, hab da einen der irgend nen samba mounted oder sowas.
 
  • Gefällt mir
Reaktionen: sedot und Bigfoot29
h2f schrieb:
kopfkratz: als MintUser lese ich staunend, mit was für Problemen sich die Rolling Release Tester so rumschlagen.
Klar, das HDMI 2.1 Lizenzding habe ich verfolgt, aber ansonsten ist mein System sowas von "abgehangen", da bleibt alles stabil.
Sei doch einfach froh das es Menschen gibt die für dich testen :-)
 
  • Gefällt mir
Reaktionen: Pummeluff, xXDariusXx, Kuristina und eine weitere Person
Zuletzt bearbeitet:
Mordekai2009 schrieb:
In ungefähr eins bis zwei Wochen.
Wäre sehr früh. Soweit ich das immer mitbekommen habe, wird erst zum ersten RC der nächsten Kernelversion ein Testwoche für den aktuellen Mainline-Kernel angekündigt und danach dauert es meist noch eine Woche, bis der auch ausgeliefert wird.

h2f schrieb:
Meine Erfahrung war, dass man da auch in der Regressions-Lotterie mitspielt, sobald man erst mal im HWE-Track ist. 😅
 
  • Gefällt mir
Reaktionen: Bigfoot29
iPat1337 schrieb:
Hab seit einer Woche RC 7.2 am laufen.
Geht bei den Arch-basierten Linux-Distris (wie CachyOS) auch recht gut. Es gibt im AUR ein Paket, dass glaube ich "Linux-Mainstream" heißt und dass den jeweilig aktuellen RC-Kernel aus den GIT-Quellen zieht und dann passgenau baut. Musste ich früher (zu 6.x-Zeiten) selber nutzen, da meine Hardware damals recht schlecht unterstützt war und die nächsten Kernel jedes Mal deutliche Verbesserungen brachten.

Yakomo schrieb:
SCTPhantom Schwachstelle
Dazu sagen sie bei einem Kernel Release GAR nichts. Denn das ist nicht Sache eines neuen Kernels sondern läuft davon weitgehend unabhängig. Ich zitiere hier mal: """fix commit 9b2854f86f0b backported to 6.6.148, 6.12.101, 6.18.42, and 7.1.6."""
Yakomo schrieb:
...nicht geschissen bekommen...
Die Leute können nicht fixen, was sie nicht wissen. Sonst würden manche Leute vielleicht auch an ihrer Art und Weise der Kommunikation arbeiten...

Yakomo schrieb:
Die Leute müssen doch Bescheid wissen.
Die Leute, die es betrifft (Security-Guys), wissen Bescheid. Das lesen die aber nicht auf Spiegel.de oder auf CB, sondern auf speziellen, security-audience-centered Portalen. Und wenn Du nicht nur FUD hättest verbreiten wollen, wäre auch von Dir gekommen, dass Du Dich kundig gemacht hättest. Also bitte, den Ball etwas flacher halten. - Danke. :)

Astorek86 schrieb:
AMD ist diesbezüglich sehr komisch: Die bieten nämlich Modifikationen der APU an, ohne zwangsläufig Treiber bereitzustellen, damit sich dann der Hersteller des Notebooks drum kümmern kann. ASUS-Notebooks etwa sind berüchtigt dafür, weil ASUS kein Geld für Treiberentwicklung ausgeben möchte - die veröffentlichen meist ein einziges Mal einen Grafiktreiber für ihr Notebook, und das wars.
Ich hab keine Ahnung, was Du sagen möchtest... Bereits seit JAHREN werden bei allen drei großen GPU-Herstellern (und den aktuell noch ZWEI großen x86-CPU-Bauern) nur noch standardisierte Produkte herausgegeben, die die Hersteller so übernehmen, damit die Gerätehersteller exakt eben keine lokalen Entwicklungskosten mehr zu haben. Schon seit 10 Jahren kann man bei so ziemlich jedem Laptop (unter Windows) zu AMD/Intel/NV gehen, dort sagen, welche HW man hat und das jeweilige Gesamtpaket installieren. Die unrühmlichsten Ausnahmen sind dabei noch Apple, die ihre AMD-GPUs mit angepasster Firmware (und beim Mac-Mülleimer auch mit speziell nötiger Software) angeboten haben und einige NVidia-SLI-Konfigurationen bei Notebooks, die fernab der normalen Configs waren, so dass DORT tatsächlich nur die Treiber des Geräteherstellers gingen.

Brrr schrieb:
Vielleicht sind aber auch einfach bei Rolling Release Distributionen implizit alle User Tester.
:D In gewisser Weise ja. Wobei es auch bei den Rolling-Distris wie Arch Linux immer noch einen "Testing" branch gibt, den man explizit aktivieren muss. Pakete laufen also i.d.R. nicht direkt vom Upstream-Git zu den "normalen" Nutzern. Aber stimmt schon... die Leute, die stabile Distris nutzen, haben selten die allerneuesten Features. Dafür aber halt dann Software, die mit hoher Wahrscheinlichkeit genau so funktioniert, wie sie soll. (Keine Sorge, für diese Distris werden die Sicherheitspatches dann zurückportiert.)

Brrr schrieb:
Ich habe das früher auch mal gemacht, aber um ganz ehrlich zu sein, habe ich da viele Optionen angepasst von denen ich keine Ahnung hatte. Ich nehme da mittlerweile gerne einfach das was mir serviert wird. make menuconfig gibt es aber immernoch und sieht auch noch gleich aus.
Es gibt eine Funktion, die sich - glaube ich - "make oldconfig" heißt. Damit wird die aktuelle Konfiguration des aktuellen Kernels übernommen. Dann braucht man nur noch das ändern, was man ändern möchte. Nach dem Abschluss der Kommandozeilen-Funktion dann noch ein "make menuconfig" oder "make xconfig"(?), und man kann nach Belieben rumklickern... - Ich bin da aber auch lange raus. :D

Garmor schrieb:
Meine Erfahrung war, dass man da auch in der Regressions-Lotterie mitspielt, sobald man erst mal im HWE-Track ist. 😅
Deswegen ist der HWE ja auch... - Trommelwirbel... optional. :D

Regards, Bigfoot29
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Brrr
Astorek86 schrieb:
Immerhin läuft der Laptop einwandfrei unter Linux bei mir und hat dort nicht solche komischen Sperenzchen. Kann mir aber schon vorstellen, dass das nicht bei allen AMD-APUs der Fall ist...
Solchen Kokolores gibt es doch ewig unter Windows das die generischen Treiber unter Linux funzen aber unter Windows nur die Spezialtreiber vom Hersteller.

Wofür das gut sein soll hat sich mir nie erschlossen.
 
@foofoobar : Ich weiß, dass ich mich zu gerade wiederhole, aber: Ich habe seit gut 10-15 Jahren schon kein Standard-Notebook mehr gesehen, welches nicht mit den Default-Treibern von AMD/nVidia/Intel läuft. Notfalls in Kombination. Wobei ich zugeben muss, dass ich das ganze nVidia-Gedöns vollständig umgangen habe. Entweder ich nutz(t)e die Intel-IGP oder eine AMD-APU. Ich hatte also nie mit dem ganzen GPU-Passthrough-Gedöns zu tun. Vermutlich weht der Wind da her.

Regards, Bigfoot29
 
  • Gefällt mir
Reaktionen: areiland
Bigfoot29 schrieb:
@foofoobar : Ich weiß, dass ich mich zu gerade wiederhole, aber: Ich habe seit gut 10-15 Jahren schon kein Standard-Notebook mehr gesehen, welches nicht mit den Default-Treibern von AMD/nVidia/Intel läuft. Notfalls in Kombination. Wobei ich zugeben muss, dass ich das ganze nVidia-Gedöns vollständig umgangen habe. Entweder ich nutz(t)e die Intel-IGP oder eine AMD-APU. Ich hatte also nie mit dem ganzen GPU-Passthrough-Gedöns zu tun. Vermutlich weht der Wind da her.
Bei mir war es ein Ethernet-Treiber für einen Intel Chip.

Und neulich hatte hier doch jemand ein Soundchip der sich trotz unterschiedlichen Funktionsumfang mit der gleichen ID meldet.
 
  • Gefällt mir
Reaktionen: Bigfoot29
Bigfoot29 schrieb:
Ich hab keine Ahnung, was Du sagen möchtest... Bereits seit JAHREN werden bei allen drei großen GPU-Herstellern (und den aktuell noch ZWEI großen x86-CPU-Bauern) nur noch standardisierte Produkte herausgegeben, die die Hersteller so übernehmen, damit die Gerätehersteller exakt eben keine lokalen Entwicklungskosten mehr zu haben.

https://www.reddit.com/r/ZephyrusG14/comments/177w0gj/

und https://www.amd.com/en/resources/su...notes/RN-RAD-WIN-ASUS-ROG-G14-2022-GA402.html

Die haben aus irgendwelchen Gründen eine spezielle Treiberseite nur für den Laptop (früher sogar mit dem expliziten Hinweis dass Besitzer des Laptops diesen Treiber benutzen sollten), und sogar einen eigenen (veralteten) Treiber für den Laptop in der Übersicht, der auch heute noch dort auftaucht. Warum ist das so? Und ich bin auch nicht der einzige der erlebt, dass die Stock-AMD-Treiber unter Windows für Probleme gesorgt haben, die von ASUS nicht... Gut, kann auch schlechtes Timing gewesen sein, keine Ahnung...

Ich weiß es nicht, und soweit ich weiß haben weder AMD noch ASUS sich da in der Richtung mal geäußert...

Vielleicht irre ich mich. Wenn du mehr weißt, gerne her mit dem Wissen^^.
 
  • Gefällt mir
Reaktionen: Bigfoot29
h2f schrieb:
kopfkratz: als MintUser lese ich staunend, mit was für Problemen sich die Rolling Release Tester so rumschlagen.
Ja, naja. Verallgemeinerungen sind immer schwierig, da die einzelnen Installationen von Usern sicher stark variieren. Ist auch schwer zu quantifizieren, weil es nur wenig Daten gibt.
Für mich war es eine sehr bewusste Entscheidung mit der ich zufrieden bin, ohne unlösbare Probleme bisher - openSUSE hat eine eigene testing Infrastruktur (openQA), zumindest kaputte Pakete oder Abhängigkeiten sind bisher nicht bei mir gelandet. Abgesehen von eigenen Fehlern, die ich der Distribution nicht anlaste.
Bugs und Unzulänglichkeiten kann es immer und überall geben, ist meine Erfahrung.
 
  • Gefällt mir
Reaktionen: Tanzmusikus und Bigfoot29
@Astorek86 : Danke für den Link. :) Ja, das erklärt manches. :D - Das ist AMDs Implementierung von nVidias Optimus. Offensichtlich waren sie damit derart überfordert, dass Asus ihr eigenes Brot backen musste. (Würde auch erklären, warum es keine aktuelleren AMD Mobile GPUs mehr gibt.)
Danke dafür. Hab ich nicht mitbekommen. :)

@foofoobar : Ja gut, Intel-Treiber werden mit AMD Plattform-Paketen natürlich nicht mitgeliefert. Allerdings sollte dort Intel eigene Treiber anbieten? Da gibts ja auch schon eigentlich ewig eine Plattform-Strategie. Und eigentlich sollten dort auch Treiber über Windows Update kommen, sofern man die nicht blockiert hat(?). Was den Funktionsblock mit unterschiedlichen Attributen aber gleicher ID angeht... möglich, dass das der Treiber auseinander frickelt. Ausgeschlossen ist das ja nicht. (Auch hier wieder die Frage: Hat der Plattform-Betreiber das verbockt oder der Geräte-Hersteller?)

Regards, Bigfoot29
 
Bigfoot29 schrieb:
Deswegen ist der HWE ja auch... - Trommelwirbel... optional. :D
Jein. Wenn du Mint 22.3 installierst, bist du von vornherein im HWE-Track. Ebenso bei allen Ubuntu-Point-Releases.
 
  • Gefällt mir
Reaktionen: Bigfoot29
Bigfoot29 schrieb:
@foofoobar : Ja gut, Intel-Treiber werden mit AMD Plattform-Paketen natürlich nicht mitgeliefert. Allerdings sollte dort Intel eigene Treiber anbieten? Da gibts ja auch schon eigentlich ewig eine Plattform-Strategie. Und eigentlich sollten dort auch Treiber über Windows Update kommen, sofern man die nicht blockiert hat(?). Was den Funktionsblock mit unterschiedlichen Attributen aber gleicher ID angeht... möglich, dass das der Treiber auseinander frickelt. Ausgeschlossen ist das ja nicht. (Auch hier wieder die Frage: Hat der Plattform-Betreiber das verbockt oder der Geräte-Hersteller?)
Keine Ahnung, ich wundere mich nur immer wieder über dieses wirre Windows-Zeug.

Möge uns der Mittelfinger von Linux Torvalds lange erhalten bleiben!
 
  • Gefällt mir
Reaktionen: Bigfoot29
h2f schrieb:
kopfkratz: als MintUser lese ich staunend, mit was für Problemen sich die Rolling Release Tester so rumschlagen.
Keine Ahnung was du damit meinst - ich habe jedenfalls seit vielen Jahren keinerlei Probleme mit rollingrelease.
Mich wundert aber immer wieder, mit was für Problemen sich LTS-User herumplagen und auch, was da für eine Angst vor Kernel-Updates besteht.

Ausser Virtualbox: da musste ich eingreifen weil das alte ausgelieferte VB mit neueren Kerneln nicht wollte ;)
solche Probleme hat man halt, wenn man alte Software benutzt - sowohl unter Fedora als auch mit Suse Tumbleweed sind mir diese Art von Problemen unbekannt, da funktionieren solche Dinge mit aktueller VB und neuen Kerneln einfach und muss sich nicht mit alter, nicht mehr unterstützter Software rumärgern. ;)
 
SavageSkull schrieb:
Welche Desktop Umgebung hast du denn probiert.
Mein Standard war immer Manjaro KDE, Mint Cinnamon und manchmal auch Pop!_OS (ich glaube Mate).
Ganz früher auch Ubuntu und Kubuntu, was aber keine Option mehr ist.

KDE gefällt mir am meisten.
 
Habicht schrieb:
Keine Ahnung was du damit meinst - ich habe jedenfalls seit vielen Jahren keinerlei Probleme mit rollingrelease.
...
Probleme liegen nicht an Rolling vs. Point Release, sondern an seltenen Vernachlässigungen, die selbst den größten Distributoren gelegentlich passieren. Vor ca. 5 Jahren oä. führte Firefox für das Webrendering von Websites und (so ist das bei XUL) seiner eigenen Programmoberfläche ein, dass auf allen GPUs mit dem DX11-Feature-Set Features, die mit diesem Feature-Set kamen, für die Beschleunigung der Berechnungen genutzt werden - auf Linux natürlich über OpenGL, aber das DX11-FeatureSet. Der Rechner meiner Mutter hatte eine Radeon HD4350 GPU, weil das günstig war. Das DX11-Feature-Set wurde bei AMD erst mit der HD5000 Serie umgesetzt, HD4000 war DX10.1. Aus irgendwelchen Gründen waren aber die von Fedora offiziell gebauten Firefox-Pakete mindestens ein dreiviertel Jahr lang der Meinung, diese Funktion auf Radeon HD4000er GPUs eingeschaltet haben zu müssen, wodurch dann eben alles von Firefox ein einziger Grafikfehler war, weil ja Befehle von der GPU abgerufen wurden, die diese nicht kannte. Und weil Firefox Firefox ist, umfasste das auch die komplette Firefox-Preogrammoberfläche - nix mit: "Schalt das einfach im Menü aus oder geh mal in about:config" - auch das war ja alles ein einziger Grafikfehler. Wann und ob das jemals behoben wurde, weiß ich nicht, ich habe nach einem dreiviertel jahr dann den Rechner meiner Mutter auf OpenSuse Leap migriert. Solche Probleme kommen mit Hardweare-Nieschen (absichtliche Rechtschreibabweichung) vor. Die HD4000er Serie war zu dem Zeitpunkt schon relativ alt. Gamer haben davon nichts mitbekommen, hat aber existiert und wenn der Standardbrowser der Distro nach einer Standard-Installation nur aus Grafikfehlern besteht, ist das schon ein heftiges Problem.

Insofern wäre ich immer vorsichtig, zu sagen, es gäbe keine Probleme, nur weil man auf seinen eigenen Rechnern keine Probleme erfahren hat.

Es kommt aber, wie in meinem Beispiel, auch vor, dass nicht die Treiber im Kernel das Problem sind, sondern irgendwelche Konfigurationsfehler bei den Paketbauern der jeweiligen Distro.
 
  • Gefällt mir
Reaktionen: CasualP
Mal gucken was CachyOS noch dazu packt, im Kernel manger ist es aktuell noch ein RC release. aber 7.1.8 läuft bei mir absolut Stabil.
 
Ich wäre mal froh, wenn Unraid endlich auf einen aktuellen Kernel wechselt und besser mit Intels Big-Little CPUs klar kommt um etwas Energie zu sparen. Die krebsen immer noch mit einem sehr alten Kernel umher.

Unter CachyOS habe ich bisher keine Probleme festgestellt.
 
Der 7.2er läuft hier genau so geschmeidig wie seine Vorgänger. ;)
Code:
~$ uname -r
7.2.0-61.fc46.x86_64
 
Zurück
Oben