Linux-kernel 6.2 met Apple M1-soc- en Intel Arc-ondersteuning is uit

Versie 6.2 van de Linux-kernel is uit. De eerste kernelrelease van dit jaar heeft directe ondersteuning voor Intel Arc-graphics en voor Intels On-Demand-driver. Ook is ondersteuning voor Apples M1-processors nu in mainline en daarmee stabieler dan eerst.

Linux-hoofdontwikkelaar Linus Torvalds schrijft in een mailinglijst naar ontwikkelaars dat Linux kernelversie 6.2 definitief uit is. "Misschien is dit niet zo'n sexy LTS-release zoals 6.1 dat was, maar ook deze normale kernels hebben wat testliefde nodig", schrijft hij. Kernelversie 6.1 kwam eind vorig jaar uit en was een long term support-release. Versie 6.2 is een normale release.

Nieuw in versie 6.2 is onder andere dat er standaard ondersteuning in de kernel zit voor Intels Arc-kaarten. Ook is er voor het eerst ondersteuning voor de betaalde On-Demand-driver die op vierde generatie Xeon-cpu's kan worden bijgekocht voor extra rekenkracht. Ook is er bètaondersteuning voor accelerated graphics op GeForce RTX30-kaarten met de Ampere-architectuur op Nouveau.

In de nieuwe kernel zit ook voor het eerst mainline-ondersteuning voor Apples M1-chips. Dat zat eerder al als testfunctionaliteit in de kernel, maar nu is de ondersteuning definitief goed genoeg. Er zijn verschillende distro's die Linux werkend proberen te krijgen op Mac-systemen met de M1-soc. Asahi Linux is daar de bekendste van; de ontwikkelaars brachten in 2021 al een werkende versie uit.

Andere opvallende nieuwe features zijn een update voor de NTFS3-kerneldriver waarmee bestanden verborgen kunnen worden op Windows-systemen en er is RISC-V-ondersteuning voor persistent externe schijven. Ook willen de makers de basis leggen voor toekomstige hard- en software. Zo is er wake-on-connect/disconnect voor USB 4-apparaten en is de basis gelegd voor Wi-Fi 7 en 800Gbit/s-verbindingen.

Reacties (76)

[henk717]

Erg jammer dat dit net niet de LTS is geworden. Veel nieuwe hardware ondersteuning die men graag zou hebben. Niet enkel arc kaarten, de wifi in mijn nieuwe laptop wordt als het goed is nu ook direct ondersteund. En ik kan mij voorstellen dat het voor M1's al helemaal prettig was geweest.

[beerse]

Dat zaken niet direct in de long-term-support distributies komen is juist onderdeel van de naam en reden voor het bestaan. Wat er bij lts wordt meegeleverd is al een tijdje in gebruik bij andere versies, er is dus al wat langer ervaring mee. En daarmee kan wat er wel geleverd worden ook wat langer worden ondersteund.

Als je zaken direct en zo snel mogelijk wilt gebruiken, dan ben je geen klant voor lts, esr en andere versies/varianten die juist langer stabiel geleverd worden.

[Katsunami]

Erg jammer dat dit net niet de LTS is geworden. Veel nieuwe hardware ondersteuning...

Ik heb altijd al gevonden dat hardwareondersteuning los getrokken zou moeten worden van de eigenlijke kernel. "Pak maar een andere distributie met een nieuwere kernel, zoals Arch" is geen oplossing omdat die distributie voor dagelijks gebruik niet betrouwbaar is. Niet omdat hij onstabiel zou zijn, maar omdat hij constant verandert. Dat is voor een productiecomputer niet wenselijk.

Als je nu bijvoorbeeld Debian wilt installeren, dan moet je dat doen alsof je een jaren-90 Unix workstation bouwt: je moet de computer aanpassen op wat het besturingssysteem ondersteunt. Dat is de reden waarom ik na mijn overstap op Linux heb besloten om enkel nieuwe computers te bouwen c.q. hardware te kopen kort na de release van een nieuwe Debian Stable en dan hardware te kiezen waarvan ik zeker weet dat die gaat werken.

[Reactie gewijzigd door Katsunami op 24 juli 2024 07:25]

[GertMenkel]

Ik heb gekozen geen hardware te kopen die net uit is omdat of je nu Linux of Windows gebruikt, de drivers echt ruk zijn bij release. Op Linux duurt het een eeuw voordat Intel hun drivers af heeft, dat heeft niet zo'n prioriteit voor ze.

Supernieuwe hardware en LTS gaan in de praktijk niet samen. Je wilt iets dat lang ondersteund wordt, of je wilt het nieuwste van het nieuwste, je kunt niet allebei doen. Pak Arch als je bleeding edge wilt gaan of Gentoo als je Arch met meer wachttijd wilt, want Debian is net als de rest afhankelijk van partijen als Intel om op tijd hun drivers aan te leveren in een versie die ze kunnen ondersteunen op termijn. Sommige drivers kunnen worden gebackport naar oudere versies, maar net als je een Windows 11 driver niet zomaar op 10 kan zetten, kun je een GPU-driver niet zomaar even op een oude versie inladen.

Of de driver nu ingebouwd zit in de kernel of niet, Debian zal de driver in hun repo's moeten bijhouden, hun versie moeten testen, en hun versie klaarmaken. Intel kan niet zomaar een driver over de heg slingeren en roepen "zie maar of 'ie werkt", dan krijg je exact de bende aan driverdownloads die je op Windows ook door mag elke keer als je je OS installeert (neem niet aan dat de versie van Windows Update de nieuwste of beste is, want dat zijn de geverifieerde drivers waar veel fabrikanten snellere drivers op hun eigen site hebben staan die nooit de verificatie door zullen komen vanwege hacks).

Het alternatief is dat je een miljoen repositories in /etc/apt/sources.list gooit en hopen dat ze allemaal lief met elkaar samenwerken. Als Intel ARC wil aanbieden aan Linuxgebruikers, hebben ze de keuze om dat te doen. In de praktijk doen bedrijven daar niet zoveel moeite voor.

[Immutable]

Is de opzet van de Linux kernel niet enorm ouderwets? Ik ben geen kernel expert, maar ik heb wel eens opinie stukken gelezen waarin wordt gewezen dat de Linux kernel qua opzet helemaal niet zo geweldig is. Helemaal omdat het een monolit kernel is, en dat hedendaags gewoon zeer ouderwets en niet meer bij de tijd past. Maar goed, het is wel opensource, en wordt zeer veel gebruikt.

[Katsunami]

Geen idee; maar een microservice-kernel werkt gewoon niet omdat het veel te traag is. Windows heeft een hybride kernel, die deels monolitisch is en deels services bevat.

Of de Linux-kernel wel of niet ouderwets is qua opzet heb ik geen idee van. Ik vind het echter al 20 jaar lang een absurde situatie dat nieuwe hardware een nieuwe kernel betekent (behalve als de hardware door de fabrikant is voorzien van drivers voor de huidige en oudere kernels) en dat het vervangen van de kernel betekent dat drivers opnieuw gecompileerd moeten worden of soms zelfs niet eens meer werken.

"Nou, dan maak je de drivers maar open source zodat het kernel-team ze kan onderhouden."

Lekker dan, als het kernel-team drivers voor weet ik wat, 25 miljard-miljoen apparaten moet ondersteunen...

Het verweven van de hardware en de kernel, en het verweven van het OS en de applicaties zorgt ervoor dat Linux helemaal niet zo modulair is als het lijkt. Het is bijvoorbeeld erg lastig om GIMP van 2 jaar terug te draaien op een hedendaagse Linux (of omgekeerd), terwijl het zonder problemen mogelijk is om GIMP van 10 jaar terug te draaien op een hedendaagse Windows (of omgekeerd). Windows 10 uit 2015 kan zonder problemen op een hedendaagse computer worden geïnstalleerd, Windows Update erover heen (met wat pech moet je enkel de driver van de netwerkkaart via USB installeren) en zo ongeveer alles wordt bijgewerkt met de laatste drivers.

En ja, ik gebruik tegenwoordig full-time Linux, ik ga nooit meer vrijwillig terug naar Windows vanwege verschillende redenen, en ja, ik vind de compatibility van Windows met hardware en software, zowel voorwaarts als achterwaarts, nog steeds veel beter dan die van Linux. Bij Windows kun je van alles door elkaar heen gebruiken, onder Linux moet je hardware ouder zijn dan je distributie, en is de software altijd uit dezelfde tijd als de distributie. (Behalve als je Flatpaks op oude distributies installeert; indien dat mogelijk is heet dat, want er zit ook een limiet aan hoe oud de distro kan zijn en je Flatpak nog erop kan zetten.)

Vanwege deze reden bouw ik nu altijd computers kort nadat een nieuwe Debian-release uitkomt, met hardware van het jaar ervoor, en installeer enkel het OS, services, Firefox en Thunderbird en kleine applicaties (KWrite, KCalc, Okular, etc) vanuit de repository. De grote applicaties waarvan ik altijd de laatste versie wil (GIMP, DarkTable, LibreOffice, VSCode, Calibre, Lutris, etc) zet ik erop via een officiële Debian-repository (als een app die heeft, zoals VSCode of Lutris), of Flatpak.

Voor mij is dit de beste manier van doen, maar het voelt een beetje irritant dat ik niet zomaar kan besluiten om, bijvoorbeeld, over een jaar een nieuwe GPU te kopen (zonder gezeik) omdat ik heb besloten om eens flink hard te gaan gamen.

[Reactie gewijzigd door Katsunami op 24 juli 2024 07:25]

[Goderic]

Het verweven van de hardware en de kernel, en het verweven van het OS en de applicaties zorgt ervoor dat Linux helemaal niet zo modulair is als het lijkt. Het is bijvoorbeeld erg lastig om GIMP van 2 jaar terug te draaien op een hedendaagse Linux (of omgekeerd), terwijl het zonder problemen mogelijk is om GIMP van 10 jaar terug te draaien op een hedendaagse Windows (of omgekeerd).

Dat ligt helemaal niet aan de kernel maar aan userland. De Linux kernel neemt backwards compatibiliteit zeer serieus, "we do not break userspace". Programma's van 20 jaar geleden die enkel kernel inferfaces gebruiken kun je gewoon nog draaien.

Het probleem zit 'm in libraries, glibc, ed. Dat heeft echter niets te maken met het verweven van de hardware en de kernel.

[Katsunami]

Dat snap ik ook wel. De kernel zelf is goed compatible; zoals je zegt, "we do not break user space". Echter, de kernel zelf en de drivers zijn met elkaar verweven, waardoor het niet mogelijk is om nieuwere hardware te draaien op een oudere kernel zoals dat wel kan onder Windows.

Dat de hele user space gebruik maakt van dezelfde libraries (one library, one version) zorgt er dus voor dat die user space met de applicaties verweven raakt. Soms kun je niet één applicatie updaten, omdat die een nieuwe library vereist waardoor je 5 andere applicaties ook moet updaten. Als je glibc zou moeten updaten dan ben je SOL; dan moet je waarschijnlijk je halve distro updaten. (Dat is dan ook een van de redenen waarom ik geen Arch draai. "Oh, een update"; en voor je het weet heb je niet alleen bugfixes, maar ook een nieuwe kernel en een nieuwe versie van GIMP en KDE op een moment dat dat niet uitkomt.)

[Reactie gewijzigd door Katsunami op 24 juli 2024 07:25]

[Plofkotje]

Distros doen niks anders dan modules die ontwikkeld zijn voor nieuwere kernels backporten naar oudere versies van de kernel. Linux is een monolithische kernel, maar je kan gewoon losse modules laden. Zo dramatisch dat je een compleet nieuwe kernel nodig hebt voor nieuwe hardware is het niet.

Aangezien de meeste modules los ontwikkeld worden voordat ze gemainlined worden is bepaalde hardware support allang geregeld in de grote distros, lang voordat een module gemainlined wordt in de kernel.

[Gimmeabrake]

Ik begrijp niet zo goed wat het probleem is. Doordat Linux user space niet breekt, en oude drivers best lang maintaint, hoef je eigenlijk nooit een oude kernel te gebruiken. Je kunt een distro met een linux 6.2-kernel gewoon op een PC uit 2010 zetten, daar kun je dan gewoon veilig mee het internet op. De user experience zal door de snelheid niet denderend zijn, maar dat is een ander verhaal. Dat wordt met Windows toch lastiger.

Omgekeerd heeft Microsoft ook backwards incompatible changes in Windows driver models. Probeer maar eens Windows XP op een recent systeem te installeren. Grote kans dat je geen netwerkdriver, grafische kaart driver, etc. vindt. De laatste generatie Intel CPU/chipset die Windows XP drivers heeft is bijv. Ivy Bridge, dacht ik.

[rob12424]

Juist niet dat is bij hybride zo.

Bij Linux moet je de drivers of aan de kernel haken (erin compileren --> opensource)

of de drivers als module bij de kernel meeleveren. (Closed source in het algemeen)

Dat 2de is juist de ramp met closed source shit van Nvidia en andere videodrivera enz.

Soms heb je ook nog een combi van. Opensource kernel drivers die als module door fabrikant geleverd worden. Of deels erin gecompileerd zijn.

De meeste ellende is dus van de fabrikanten. Die gaan iets closed source maken. Waardoor kernel ontwikkelaars het niet aan kunnen passen. Iedereen is gelukkig nu meer opensource aan het worden omdat ze vanwege valve anders de strijd gaan verliezen op de videokaart markt.

En Linux is veel efficiënter in bijvoorbeeld het afhandelen van Api calls. Daarom werden spelers vroeger vaak ook gekicked met gamen op Wine onder Linux.

[Reactie gewijzigd door rob12424 op 24 juli 2024 07:25]

[_JGC_]

Het probleem bij Archlinux is dat ze heel vaak soname bumps doen met rebuild lijstjes om de oude soname weg te werken. Als je dan een verouderde versie van een stuk software hebt of iets wat je zelf hebt gecompileerd moet je dat opnieuw compileren.

Andere distributies lossen dat veel eleganter op door libraries af te splitsen naar losse pakketjes en per soname een pakket te maken. Zo kan je op Debian of Ubuntu prima libssl1.0.0 naast libssl1.1.0 en libssl3 zetten.

Wat betreft glibc: die is backwards compatible, maar andersom niet forward compatible vanwege symbol versioning. Je hoeft dus niet per se alles te updaten om een nieuwe glibc binnen te kunnen trekken.

[Goderic]

Echter, de kernel zelf en de drivers zijn met elkaar verweven, waardoor het niet mogelijk is om nieuwere hardware te draaien op een oudere kernel zoals dat wel kan onder Windows.

Het voordeel hiervan is dat Linux gemakkelijk de in kernel driver ABI kan veranderen, op Windows is dit zeer moeilijk (veel van de Vista problemen kwamen hierdoor).

[Katsunami]

Het voordeel hiervan is dat Linux gemakkelijk de in kernel driver ABI kan veranderen

Er zijn meer mensen die er zo over denken als ik, maar blijkbaar vindt men de mogelijkheid om snel zoveel mogelijk ABI's te veranderen belangrijker dan de mogelijkheid om fabrikanten van hardware opties te geven het OS daadwerkelijk te ondersteunen.

Er is geen hond die Linux wil ondersteunen omdat er 500 verschillende kernelversies in omloop zijn op elk gegeven moment. Daarom zie je, ALS er al officiële Linux-ondersteuning is, dit enkel wordt gedaan voor Ubuntu LTS, SLED, RHEL, en heel misschien Debian Stable (maar die is met een distro-upgrade elke 2 jaar eigenlijk al wat snel voor veel fabrikanten).

[_JGC_]

Het probleem met kernel ABI is dat het per patchlevel of configuratie optie kan verschillen. Op zowel Debian als Ubuntu heb je daarom al 5.10.0-19-amd64, 5.10.0-20-amd64, etc. Elke security update krijgt zowat een ABI bump.
Als je dacht dat ABI bumps een uitdaging was, je krijgt in de nabije toekomst ook te maken met signed kernels en signed modules. Kloppen die niet met elkaar, kan je de module niet inladen, ook niet geforceerd. Alles vanwege secure boot en dergelijke.

Wij zitten er op dit moment mee dat van hogerhand Crowdstrike is opgelegd als beveiligingspakket. Die werkt met binary kernel modules die structureel een aantal kernel releases achter loopt. Als Crowdstrike een nieuwe versie uitbrengt heeft Debian de week erop alweer een nieuwe security update voor de kernel.

Maargoed, dit alles is een keuze. Je kunt ook gewoon een binary module met een stukje te compileren shim-code uitbrengen. Dit is wat Nvidia al sinds jaar en dag doet met het kernel-deel van hun drivers. Systemen als DKMS zijn niet voor niks uitgevonden.

[Goderic]

Het mes snijdt natuurlijk in twee richtingen Er is ook geen hond in de Linux kernel community geïnteresseerd in het ondersteunen van (closed source) drivers die niet in de kernel zitten. Open source de drivers en steek ze in de kernel en er is helemaal geen ABI probleem.

[freaky]

Start windows 98 eens op een modern UEFI only systeem met enkel NVMe opslag dan.

Succes...

Staat je weinig in de weg om drivers te backporten overigens. Meestal niet eens heel lastig. Alleen voelen velen denk ik minder noodzaak dan jij om perse een oudere kernel te draaien.

[lezzmeister]

Glibc is ook zo'n dingetje. Officieel zijn de C libs inwisselbaar, in de praktijk echt helemaal niet. Is wel vaker het een en ander over gezegd.

[downtime]

Is de opzet van de Linux kernel niet enorm ouderwets?

Je kunt kiezen: Een "ouderwetse" kernel waar al 30 jaar aan gewerkt wordt om 'm steeds stabieler en sneller te maken. Of een "moderne" kernel met allerlei theoretische voordelen maar een achterstand van 30 jaar in ontwikkeling. Die 30 jaar ontwikkeling maakt zo'n enorm verschil dat we misschien nooit meer van die traditionele kernels af komen.

[Katsunami]

Het is natuurlijk wel mogelijk om een kernel, beetje bij beetje, om te schrijven naar een andere architectuur en zelfs een andere programmeertaal. Dat zal wel 10 jaar kunnen kosten natuurlijk. Maar je hebt gelijk: even opnieuw beginnen zit er niet in.

[lezzmeister]

Even opnieuw beginnen zit er zeker wel in. Maar dan is de vraag wat je met zo'n kernel wil doen.

Redox bijvoorbeeld heeft de basis al klaar. Rust is zo oud nog niet. Is het mogelijk om een RTX aan te sturen en even wat van Steam te spelen? Zeker niet. Kun je een iso maken die start? Jazeker.

Kernels worden continu gemaakt, Singularity was een onderzoeksproject, L4 wordt nog aan gesleuteld en ze zijn recent weer begonnen aan een nieuwe variant. Hurd is al een tijdje bezig en nog steeds in de beginfase (al is dat meer een kwestie van gebrek aan interesse vermoed ik), er zijn er vast nog veel meer.

[Gimmeabrake]

Ouderwets vind ik een ongelukkig woord, het concept van de microkernel is ook tientallen jaren oud.

Een monolithisch ontwerp heeft nadelen, maar is juist ook zeer geschikt voor een open source kernel. Kernels zijn constant in ontwikkeling omdat hard- en software dat ook is. Microsoft introduceerde met Windows Vista bijv. WDDM, een nieuwe driverarchitectuur voor grafische kaarten. Omdat NVidia hun driver bij de release van Vista niet op orde had, heeft Vista onder andere een reputatie voor veel bluescreens. Doordat in linux de drivers in de broncode zitten*, kunnen de kernel developers veel makkelijker aanpassing maken aan het driver model, ze kunnen de drivers namelijk gewoon mee aanpassen en testen.

*) Er zijn helaas soms vanuit de kernel driver verwijzingen naar blobs, closed source firmware waar alleen de binary van beschikbaar wordt gesteld.

[downtime]

Je noemt nu juist een probleem wat je in een echte microkernel architectuur niet hebt. Omdat alles in essentie een applicatie is (als apart proces in eigen geheugen en een aparte security context draait) is het crashen van een videodriver ook geen groot probleem. De kernel en alle andere applicaties zijn immers geisoleerd van de videodrivers. Zodra de videodriver niet meer reageert kan de kernel de driver herstarten en gaat het leven weer verder.

[FateTrap]

AmigaOS was in het begin technologisch veel geavanceerder dan windows en macOS toen waren. Maar omdat het een microkernel gebruikte kon het op een gegeven moment niet meer concurreren met windows en macOS. Darwin komt voort uit de Mach microkernel maar het is geen pure microkernel, omdat dit te grote prestatieverliezen oplevert. Het is een hybride kernel. Windows gebruikt ook een hybride kernel.

Hybryde kernels zijn sneller dan microkernels, mar uiteraard ook trager dan de meeste monolithische kernel s. Dus als je Linux en FreeBSD volledig optimaliseert gaan beide hogere prestaties leveren dan wat macOS en windows kunnen bereieken. FreeBSD en Clear Linux zijn ook in de praktijk sneller dan macOS en windows. FreeBSD heeft dan ook het voordeel dat het om één of andere reden meer IOPS kan halen in ZFS dan Linux. Apps starten op Linux zo goed als nooit significant sneller op dan in FreeBSD.

Maar al deze drie verschillende kernel types zijn echt al oud. De reden dat windows en macOS een hybride kernel gebruiken is omdat ze geen servers zijn en prestaties niet kritiek. En een tweede reden is dat Microsoft en Apple een hybride kernel gebruiken is omdat dit minder moeite vraagt van hun werknemers om te ondersteunen, dus ze hebben dit type kernel vooral gekozen uit gemakzucht.

[Pjotr]

Een al lang lopende discussie. :-)

Mocht je hem niet kennen, dan kan ik je de discussie (uit 1992) tussen Linus Torvalds en Andy Tanenbaum aanraden:

https://en.wikipedia.org/wiki/Tanenbaum–Torvalds_debate

[Reactie gewijzigd door Pjotr op 24 juli 2024 07:25]

[latka]

Het is inmiddels een bewuste keuze geworden. Het grootste voordeel van deze opzet is dat oude drivers ook ge-update worden. Als je dat bij fabrikanten neerlegd gebeurt het niet of slecht (zie HP printers en de overgang naar Windows 10: geen support vanuit HP dus de printer kan bij het oud-vuil). Voor kernel-mode drivers (dat zijn printerdrivers on Linux gelukkig niet) geld dat het direkt zichtbaar wordt tijdens het ontwikkelen welke drivers aangepast moeten worden als de kernel veranderd. Die wijziging voert men dan ook door. Als er geen gebruikers/maintainers van een driver meer zijn is er waarschijnlijk ook geen of minimaal gebruik en wordt de driver uit de kernel gegooid om te voorkomen dat oude kak drivers de boel instabiel maken.
Vergelijk dit met het windows model: daar is MS inmiddels ook wel een beetje om en staan alle drivers gewoon bij MS op de download server ipv. de ouderwetse driver-hunt en patchen van van .inf files om het werkend te krijgen.

De opinie stukken lijken me meer FUD dan goed onderbouwd.

[joost00719]

Misschien heb ik gewoon geluk gehad, maar ik heb juist het idee dat Debian overal wel op draait (amd/intel).
Het enige waar ik rekening mee hou, is dat ik netwerkkaarten neem waar Intel nics op zitten.
Maar goed, misschien verandert mijn ervaring zodra ik ga spelen met een SAS kaart/schijven.

Daarnaast heb ik inderdaad ook alle computers thuis die als server fungeren Debian geïnstalleerd omdat het stabiel is, en niet alle bleeding-edge meuk erin probeert te stoppen.

[Jazco2nd]

Ik draai mijn homeserver en alle laptops/PCs van mezelf en ouders op Manjaro Gnome, dat is dus Arch based. Retestabiel, energiezuinig en supersnel. Ik zou nooit meer een OS willen dat nog aan "upgrades" doet. Geef mij maar incrementele updates.
Mijn server voert elke laatste zondagochtend van de maand deze updates uit. Al jaren inmiddels.

Veeeeeel minder gedoe dan toen ik Ubuntu draaide op mijn server. Sterker nog, ik denk vrijwel niet meer aan server onderhoud. Hoef niks te fixen. Het draait gewoon. Heerlijk.

En voor laptops erg fijn dat je op een recente kernel zit. Batterijduur wordt er alleen maar beter van.

[Reactie gewijzigd door Jazco2nd op 24 juli 2024 07:25]

[Katsunami]

Ik zou nooit meer een OS willen dat nog aan "upgrades" doet.

Daarom draai ik ook Debian; omdat je dan van versie naar versie kunt upgraden. Bij Ubuntu en Mint kan dat vaak maar beperkt, of helemaal niet. Mint heeft een upgrade-tool, maar op de pagina daarvan staat letterlijk: "Als de upgrade mislukt, installeer dan maar opnieuw."

Op Debian is nog nooit een upgrade mislukt.

[Jazco2nd]

Mijn hele punt is dat ik wel wat beters te doen heb dan mij met upgrades bezig te houden
Scheelt gewoon tijd. Geen ingrijpende jaarlijkse of halfjaarlijkse upgrades. Niet dat dat hoeft te mislukken, maar er is altijd weer wat configuratie of aanpassing daarna nodig.

[xirixiz]

Er is een verschil. Debian Testing kent een rolling release mechanisme, maar Debian en/of Ubuntu niet. Meestal gaan de upgrades goed op Debian, maar ik ben het met @Jazco2nd eens dat rolling releases zeer aangenaam zijn.

Zelf ben ik na jaren Arch en OSX naar Windows 11 gegaan. De integratie met WSL en vscode werkt goed en ik kan ook weer eens gamen. Ik moet zeggen dat ik aangenaam verrast was door Windows 11. Ja, dat zeg ik inderdaad .

[devilkin]

Er zijn voldoende drivers beschikbaar als out-of-tree modules. Deze kan je, mits de fabrikant of ontwikkelaar het nodige werk doet, perfect compileren tegen een oudere kernel.

Daar wringt het schoentje: veel fabrikanten doen geen moeite om linux te ondersteunen. Het is door het vele werk van vrijwilligers dat alles werkt... mensen die alles uitzoeken om te kijken hoe ze hardware xyz aan de praat krijgen.

[henk717]

Met laptops kom je daar niet zomaar mee weg, ik heb mijn laptop volledig op Linux gekocht. Maar het duurde wel tot Linux 6.2 tot alle drivers upstream waren en ik niet langer met DKMS modules hoeft te prutsen. Dus momenteel wacht ik even tot de nieuwe linux-oem kernel uit is met 6.2 en dan verwacht ik dat mijn laptop prima zal werken.

[GekkePrutser]

Ik heb altijd al gevonden dat hardwareondersteuning los getrokken zou moeten worden van de eigenlijke kernel.

Dat kan, maar dan heb je een microkernel nodig.

Linux heeft vanaf het verre begin voor een monolitische kernel gekozen (tegenwoordig iets minder monolitisch omdat er dynamisch laadbare modules zijn, niettemin nog steeds onderdeel van de kernel). Bij een microkernel zoals bijv. die van macOS zitten de drivers voornamelijk in userspace.

Dus dit is iets dat heel diep verweven zit in de architectuur. Linus heeft daar op Usenet destijds uitgebreide flamewars over gehouden met Andrew Tanenbaum van de VU Amsterdam, die destijds Minix bouwde. De redenen die Tanenbaum destijds aandroeg zijn diezelfde waar Linux zich tegenwoordig mee in de voet schiet.

Er is wel omheen te werken met backports en stabiele kernel ABI's (wat Linux momenteel niet doet) enzo maar ik moet zeggen dat ik Tanenbaum wel gelijk vond hebben.

[Reactie gewijzigd door GekkePrutser op 24 juli 2024 07:25]

[Superstoned]

Tja, zo gaat het altijd - 6.3 gaat ook weer veel nieuwe hardware ondersteunen. Maar de enterprise distributies zoals SUSE backporten vaak veel drivers dus dat zit wel goed en als privé gebruiker heb je toch vaak een snellere upgrade cycle - halfjaarlijkse releases of een rilling release zoals tumbleweed of arch?

[CAPSLOCK2000]

Erg jammer dat dit net niet de LTS is geworden. Veel nieuwe hardware ondersteuning die men graag zou hebben.

Die nieuwe hardware is voor een LTS juist minder aantrekkelijke. Nieuwe hardware heeft vaak nog buggy drivers en die wil je dan niet direct in een LTS stoppen die lang mee gaat. Liever wacht je even tot de boel een beetje gestabiliseerd is voor je er lange-termijn-support op geeft.

[tweakkjoost]

Ik heb sinds kort Ubuntu 22.04.2 LTS draaien op een laptop van 1 jaar oud. Als Linux newbie vraag ik me af of het nou goed is om deze kernel 6.2 te installeren? Of zijn er bijvoorbeeld nadelen in de beveiliging of iets dergelijks?

[GertMenkel]

Als je Ubuntu gebruikt, gebruik je de kernels die Canonical voor je klaarzet. Over het algemeen hoef je je niet druk te maken over kernelversies, tenzij je zelf drivers maakt of hele specifieke hardware gebruikt (zoals nu met Intel ARC) waarvan de drivers pas heel laat zijn aangekomen. Qua beveiliging zit je goed zolang je de automatische updates maar installeert.

Je kunt via omwegen een eigen kernel kiezen die niet van Canonical komt, maar dan moet je goed opletten dat die ook alle optionele drivers die je nodig hebt bevat, en dat de software die je gebruikt ook met de nieuwe kernel overweg kan. De software die Ubuntu aanbiedt is getest en gemaakt voor de kernelversies die zij bijhouden, en met sommige drivers (DisplayLink, nvidia) komt het voor dat je een upstreamversie nodig hebt om de allernieuwste kernel te kunnen gebruiken. Ubuntu voegt ook een aantal patches aan hun kernel toe en doet nog wat configuratie om de kernel naar hun wensen aan te passen. Ik heb zelf meegemaakt dat de Ubuntu-kernels bepaalde systemen beter ondersteunden dan de nieuwste mainlineversies zonder ellenlang gedoe.

In de praktijk maakt Ubuntu gebruik van LTS-kernels die een wat oudere versie zijn maar wel worden bijgehouden met patches. Zo heb je geen risico dat de nieuwe kernel dingen stuk maakt. Andere distros (Gentoo, Arch, daarvan afgeleiden) hebben een andere insteek, daar is iedere update je eigen risico en meestal gaat dat helemaal prima (en soms moet je handmatig je OS weer werkend maken).

Als je het nieuwste van het nieuwste wilt draaien, moet je over het algemeen niet bij Ubuntu zijn. Ubuntu is er voor stabiliteit en spul een tijd lang gewoon laten werken. Aangezien deze kernelversie niet als LTS is aangekondigd (6.1 is dat nu geloof ik wel) gok ik dat Ubuntu 23.04 ook deze kernel niet zal krijgen, bijvoorbeeld. 23.04 komt al over anderhalve maand uit en ik denk niet dat ze nu nog een nieuwe kernel gaan testen.

Wil je toch Linux 6.2 toch op Ubuntu uitproberen, dan kun je deze stappen volgen zodra 6.2 door het mainlineproject beschikbaar is gemaakt (meestal binnen een dag of twee na release). Laat wel de oude kernel geïnstalleerd staan, dan kun je in je opstartscherm nog de oude kernel laden mocht je problemen krijgen met de allernieuwste.

[tvtech]

Ik heb dat een jaar of wat geleden ook eens gedaan op mijn dual boot laptop maar toen was gelijk mijn secure boot stuk. Is dat nog steeds zo met een andere kernel dan degene die er standaard bij zit? Denk het wel want dat is dacht ik het hele idee achter secure boot.

[GertMenkel]

Ja, de mainline-kernels zijn niet ondertekend. Als het apparaat van jou is, kun je je eigen sleutels inladen en dat gebruiken om arbitraire kernels te ondertekenen (en zo secure boot werkend te houden). Gebruik daarvoor tools als deze of deze handleiding of deze handleiding afhankelijk van hoe modern je systeem is.

Let op als je dit doet: hiermee wordt vaak de secure boot state gereset, wat er bij een dual boot systeem voor kan zorgen dat Bitlocker om je recovery key vraagt. Ook zul je mogelijk de Microsoft-key nog een keer moeten inladen nadat je je eigen key hebt geladen, of de Microsoft-bootloader met je eigen key ondertekenen(edit: dat werkt niet met Windows, helaas). Ook andere TPM-gebaseerde applicaties zullen mogelijk hun sleutels kwijtraken (afhankelijk van hoe je apparaat is geïmplementeerd) dus zorg dat je daarvoor backups hebt.

Standaard gebruikt Ubuntu een shim die door Microsoft ondertekend is en de officiële kernels van diverse distros vertrouwt. Wil je daarvan gebruik blijven maken, dan zul je moeten wachten tot Ubuntu met een 6.2-kernel uitkomt.

[Reactie gewijzigd door GertMenkel op 24 juli 2024 07:25]

[tvtech]

Dank voor je uitgebreide uitleg! Ik laat het maar even zoals het nu is, standaard Ubuntu dual boot want het is mijn dagelijkse werklaptop dus net even te hard nodig om dit soort experimenten zomaar uit te voeren.

[psychicist]

Met het installeren van een nieuwe kernel zou ik me helemaal niet bezighouden, als alles nu goed werkt voor jou. Het is niet meer de tijd van 20-30 jaar geleden dat je nog zelf een kernel moet compileren om de nieuwste hardware te kunnen gebruiken. Updates bevatten ook updates voor de kernel, dus je hoeft in feite verder helemaal niets te doen.

Over 2 jaar upgrade je naar Ubuntu 24.04.1 LTS en heb je weer toegang tot de nieuwste features en hardware. Mocht het echt zo zijn dat een driver voor een nieuw apparaat niet in jouw kernel zit, dan zijn er wel mogelijkheden om een nieuwe kernel te installeren. Maar dat hoeft in jouw geval waarschijnlijk helemaal niet.

[NielsFL]

Lekker laten zitten zo. Als er iets heel belangrijks verandert, dan regelt Ubuntu dat door de "oude" kernel te updaten. Het zal je misschien opgevallen zijn dat Ubuntu een extra nummertje achter de kernel versie plakt, bijvoorbeeld: 5.4.0-125-generic ipv 5.4.0-generic. Dat extra nummertje verandert af en toe, mits je je updates bijhoudt.

[PrimusIP]

Heel goed dat ze moeite steken om het beter op Apples ARM spul te laten draaien. Ik hoop dat op een gegeven moment het ook eenvoudiger wordt om via bijvoorbeeld een USB stick of een bootloader Linux te starten. Momenteel is dat niet gebruikersvriendelijk en helemaal een slecht idee als je van plan bent ook veel met macOS te blijven werken (tenzij het je hobby is om elke keer weer van alles in de CLI aan te moeten passen zodra je weer van OS wilt wisselen).
Maar dat obstakel ligt bij Apple. Ik ben er pessimistisch over of ze dat gaan veranderen. Heel misschien ooit een keer voor duoboot als ze met Microsoft praten, wie weet. Maar ben bang dat Linux ze niet over de streep gaat trekken.
(Moet trouwens zeggen, bepaalde Linux distro's werken best oké als VM op een ARM Mac. Dat is iig al fijn.)

[Keipi]

Waar baseer je dit op? Zelf heb ik Asahi Linux op m’n M1 draaiende. Dat kan je, incl. bootloader, van een enkel command line script installeren. Daarna rebooten en klaar.

Het is letterlijk `curl https://alx.sh | sh` en dan de installer volgen.

Als enige verbeterpunt zou ik noemen dat ik grasg elke keer in het “Kies je OS” scherm wil komen ipv. dat het automatisch je ingestelde keuze laad en je 5 seconden de aanknop in moet drukken om bij een selectieschermte komen.

[killercow]

`curl https://alx.sh | sh`

Data direct in Curl gieten vanaf het web is echt een security anti-pattern, maargoed, hopelijk was de machine toch al leeg

[MrMonkE]

[...]

Data direct in Curl gieten vanaf het web is echt een security anti-pattern, maargoed, hopelijk was de machine toch al leeg

Het ergste wat je kan doen is toch een nieuwe machine installeren uit een onzuivere bron?

[Gamebuster]

We weten het, en toch doen we het massaal.

NodeJS met name kan gewoon code uitvoeren tijdens installeren NPM packages, en een gemiddeld NodeJS zal gauw 100en of 1000en NPM packages hebben.

[GekkePrutser]

Klopt maar het is wel iets dat niet veel langer zo door kan gaan. Het is al enkele keren misbruikt door malwaremakers. Niet alleen bij NodeJS maar ook andere 'moderne' talen die alles wat los en vast zit van internet binnenslurpen zonder enige check op de auteurs daarvan. Zoals Python, ruby, go enz.

Het is natuurlijk wachten op iemand die dit echt goed weet uit te buiten en een nieuwe "wannacry" situatie creeert waar de hele wereld op zijn gat ligt. Als het kalf verdronken is, gaan we de put pas dempen want het is zo handig allemaal.

En dit geldt niet alleen voor account takeovers van de ontwikkelaars en het inbrengen van echte malware. Ook fouten in de code natuurlijk, als die niet snel opgelost worden. Het Log4J verhaal komt hierbij goed naar voren en dat viel nog mee omdat het zo snel opgelost werd.

Verplichte XKCD: https://xkcd.com/2347/

[Reactie gewijzigd door GekkePrutser op 24 juli 2024 07:25]

[PrimusIP]

Dan is het verbeterd sinds de laatste keer dat ik er naar keek. Mooi dat het nu kan. Hoe verhoudt de bootloader zich tot MacOS updates? Blijft het buiten schot?

[Keipi]

Ja, zeker! Bootloader en OS staan bij de nieuwe Mac’s helemaal los van elkaar (weet niet hoe het met de oude Mac’s zit).

Asahi Linux heeft er zelf een goed document over: https://github.com/AsahiL...oduction-to-Apple-Silicon

Je kan iig zonder zorgen je MacOS updaten.

[duderuud]

Er zijn wel meer verbeterpunten. Audio werkt ook nog steeds niet, toch wel een showstopper...

[Keipi]

Oh, aan het OS zelf is nog een heel hoop te doen! Externe display, betere sleep, etc.

Ging me voornamelijk even over het gemak van installeren en het “it just works”

[duderuud]

Ja dat is zeker waar. Een beetje Tweaker heeft het zo geïnstalleerd.

[johnbetonschaar]

Kleine nuancering: audio werkt gewoon, echter alleen via de headphone port en niet via de ingebouwde speakers.

De reden dat de interne speakers nog niet gesupport worden is omdat het mogelijk is ze op te blazen als de driver niet binnen bepaalde limieten blijft. Hector Martin die hier aan werkt heeft op die manier al van 1 MBP de speakers vernacheld, vandaar dat de interne speakers nu nog gedisabled zijn om te voorkomen dat mensen per ongeluk hun laptop beschadigen.

[Jan Onderwater]

En waarom draai je het niet in een VM? Dan kan je tegelijkertijd in MacOS en Linux, ja zelf Windows 11 werken.

[PrimusIP]

Je verliest een stuk performance. Dat ga je wel merken bij met name zware processen die bijvoorbeeld veel ramgeheugen vragen.

[Jan Onderwater]

Ben ik niet met je eens, je kan hooguit niet alle cores en al het geheugen gebruiken. Het is een misverstand dat virtualisatie in principe langzamer is.

[PrimusIP]

Je OS heeft ook resources nodig. En het verschilt natuurlijk wat je draait met wat. Maar je blijft ram en processorkracht verliezen, want je OS en je VM applicatie heeft ook wat nodig.
Parallels bijvoorbeeld raadt me met klem aan om iig twee CPU cores en 4GB ram vrij te houden. Dat kun je overrulen, maar neemt niet weg dat het geen succes gaat worden als ik de volle 100% voor de VM wil gaan inzetten.

[Jan Onderwater]

Dat zeg ik, je kan niet alle cores en geheugen gebruiken, maar MacOS en applicatie die je onder virtualisatie draait op 10 cores en 16GB geheugen is niet daadwerkelijk langzamer dan MacOS die je direct op 10 Cores en 16GB geheugen draait.

[Frame164]

Dat valt echt heel erg mee tegenwoordig. Je praat echt maar over procenten bij zware processen. Het hoogste wat ik ooit heb gemeten was 9%. En als je proces zo zwaar is dat die paar procent relevant worden moet je sowieso krachtigere hardware hebben.

[RoestVrijStaal]

Ik beschouw het hetzelfde als Android o.i.d. porten naar een Nintendo Switch of Playstation 4/5; puur "omdat het kan" en omdat het interessant is om het werkend te krijgen op propritaire hardware waar geen drivers voor uitkomen, dan een daadwerkelijke use case.

Bij Apple systemen in het bijzonder eigenlijk. Je wisselt de ene UNIX-gebaseerde besturingssysteem in voor een op-UNIX-geïnspireerde besturingssysteem. De winst is marginaal.

[Sando]

Hoe werkt dat, een begrensde On-Demand-driver die je tegen betaling kunt unlocken via een open source kernel?

[StefanTs]

https://www.intel.com/con...cs/ondemand/overview.html

[rubenbe]

De open source driver zal enkel de licentie keys doorgeven aan de CPU. Die zijn cryptografisch getekend. De CPU kan dan verifiëren of de licentie echt is. De driver is dus enkel een doorgeefluik.

[Meiklokje]

Laat de linux distros nu maar komen, alles op ARM.

Zorin os
Elementry os
Mint
Ubuntu maar dan de desktop versie niet de server iso
Open Suse Leap en tumbleweed
Fedora
Arch
Manjaro

En nog meer distro s wat linux rijk is en ook open BSD. Dat gaat nog leuk worden dan.

Als men zo door doet wil ik wel eens op die apple silicon trein springen. Maar dan moet rosetta 2 support ook helemaal weg zijn en alles op ARM te gebruiken zijn. Kom op jongens, meer apps, meer software meer ossen via een vm. Als men zo graag op ARM wil toeren haal er dan ook echt alles uit. Ook geen crossover meer of wine. Zorin os on ARM zou voor mij gewoon de killer app zijn.

[psychicist]

Linux op ARM is al zo volwassen dat alles erop draait. Nu is het een kwestie van de kers op de taart met zaken zoals Wine en Box64. Maar het beste is natuurlijk om gewoon native te compileren voor Linux op ARM (en x86 en binnenkort ook RISC-V).

Ik wacht wel op Qualcomm 8cx gen 4 en chips van Mediatek en Rockchip. Apple Silicon is leuk voor als je weinig eisen hebt, maar het ontbreken van modulaire opslag en geheugen is gewoon niet zo handig.

[Roel1966]

Ik zit mij eigenlijk af te vragen of er nog doorontwikkelingen zijn op mobiel gebied qua Linux distro's, want meestal lees ik alleen vernieuwingen van desktopversies. Lijkt mij nu ook die M1 chip van Apple ondersteund word dat b.v. een distro voor een iPad wel apart zou zijn. Nu zal dit technisch gezien wel een hele uitdaging zijn omdat die iPad's best wel dichtgetimmerd zitten. Dus geen idee of dit wel mogelijk zou zijn en ik daar wel eens nieuwsgierig naar ben in hoeverre daar al iemand mee bezig is geweest.

[Umbrah]

Linux Kernel 6.2... Dan moeten we nog een 6.22 hebben, en daarna is het op. Ik hoop dat Mr. Torvalds puur als grap de volgende kernel versie 95 noemt. Hoewel dat uiteindelijk gewoon een zekere 7.0 onder zich had.

Ik doel op Dos natuurlijk. Dos 6.2 was voor mij een van de laatste 'volwassen' DOS-en!

[DexterDee]

MS-DOS 6.22 was absoluut een van de meer populaire DOS versies, maar zeker niet de laatste volwassen DOS versie. Onder Windows 95/98 draaide MS-DOS 7.x en MS-DOS 8.0 is uitgekomen onder Windows ME. Pas toen Windows XP uitkwam is MS-DOS ingeruild voor de NT kernel, wat MS-DOS 8.0 de meest recente MS-DOS versie maakt.

[Umbrah]

Mwoah, niet helemaal waar. Win-DOS was niet écht DOS meer, hoe compatible het ook was. Veel van de kernel draaide niet meer in msdos.sys. Sterker nog: dos 8.0 kon niet eens meer 'gewoon' DOS-mode booten, en autoexec.bat was meer een soort van environmental variables bestand. DOS7 draaide ook al vanuit io.sys en was meer een soort bootloader-met-shell, sterker nog, als ik het me goed herinner, moest zeker onder 7.1 nogal eens een CAB-file in een ramdrive gezet worden om het ding uberhaupt op een floppy te krijgen, en genoeg échte DOS meuk die niet helemaal lekker meer werkte er op.

Dat maakt voor mij Linux 6.2 speciaal, want 6.22 is er bijna, en daarmee hoop ik dat Torvalds net zo'n soort truc toepast als hier:

nieuws: Linus Torvalds brengt Linux 3.11-kernel uit

[Katsunami]

MS-DOS 8.0 de meest recente MS-DOS versie maakt.

Klopt, maar die kon je niet officieel gebruiken. Je kon Windows 95 en 98 starten in DOS-mode, en dan Windows opstarten met "win". Als ik het me goed herinner, was dit officieel niet mogelijk met ME, al kon je het wel met wat onofficieel gevrot voor elkaar krijgen. Hoe? Weet ik niet; ik heb ME nooit in de praktijk gebruikt. (En 95 en 98 enkel geïnstalleerd voor andere mensen, maar ik heb het nooit zelf op een computer gehad. Ik ben van OS/2 (met daarin Win3.1, "Win-OS/2" geheten) direct naar NT4 gegaan.)

[Reactie gewijzigd door Katsunami op 24 juli 2024 07:25]

[beerse]

Niet helemaal... Het inruilen van ms-dos naar wnt begon al in de tijd van windows 3.11 (msdos 5). De eerste breed bruikbare versie van wnt was immers 3.5 (of 3.51). Vanaf dat moment hebben ze elkaar aardig afgewisseld, al is de nummering redelijk heen en weer gegaan, geheel los van de marketing-nummers zoals 95 en 98. https://nl.wikipedia.org/wiki/Microsoft_Windows

Over msdos versie 6.2, 6.21 en 6.22: https://nl.wikipedia.org/wiki/MS-DOS. Daar was iets met rechten en zo de achtergrond. Iets met compressie op filesysteem/disk niveau. Hopelijk geen rechten/licentie issues met de linux versies 6.2 en volgend...

[Meiklokje]

FreeDOS heb je ook, kan je aanmaken bij de Rufus usb flash tool. Of even hirens boot cd downloaden. Ook genoeg om je hart op te halen. Oh weer nostalgie en een mooi Druaga1 moment.

Nu nog een ssd in je IBM compatible dos pc proppen. Het is zo jammer dat mijn IBM AT op zolder ligt, zou een ssd zon dino computer aan nemen ? Of toch maar een compact flash kaartje met een adapter op de hard disk controller aansluiten om de snelheid van de schijf in de dos benchmark software te testen. Zalig.

[OxWax]

Nu graag ook X86 op de Mx Macs, hoef ik geen 2 laptops meer te kopen

[Meiklokje]

Rosetta 2 vertaal laag.