Linux 5.0 met FreeSync-ondersteuning is verschenen

Zondag is de Linux 5.0-kernel vrijgegeven. Ondanks het versienummer gaat het niet om een release met significant meer nieuwe functionaliteit dan andere releases, maar wel is bijvoorbeeld ondersteuning voor FreeSync en Nvidia Turing-gpu's toegevoegd.

Linus Torvalds heeft de distributie van Linux 5.0 zondag op de Linux Kernel Mailing List bekendgemaakt. Daarbij benadrukt hij dat Linux geen featurereleases kent. "5.0 betekent niet veel meer dan dat de 4.x-nummers zo groot werden dat ik vingers en tenen tekort kwam." Aanvankelijk zou de kernelversie met codenaam Shy Crocodile ook als 4.21 verschijnen.

Een van de prominente toevoegingen is de komst van ondersteuning voor AMD FreeSync. Als Linux-gebruikers stotteren en tearing van hun beeld willen voorkomen, moeten ze wel een monitor met ondersteuning hebben en over Mesa 19 en een bijgewerkte xf86-video-amdgpu-package beschikken.

Ook is er ondersteuning voor Nvidia's laatste gpu-generatie Turing door middel van de opensource-Nouveau-driver. Het gaat om basale ondersteuning die niet te vergelijken is met die van de reguliere driver van Nvidia zelf, maar Linux 5.0 is te combineren met GeForce RTX 2000-kaarten.

Daarnaast bevat de nieuwe kernelversie een touchscreendriver voor de RaspBerry Pi en is ondersteuning voor Googles Adiantum toegevoegd in Fscrypt. Adiantum is technologie voor schijfencryptie die werkt op systemen met lage hardwarespecificaties, zoals budgetsmartphones. Verder heeft het btrfs-bestandssysteem weer ondersteuning voor swapbestanden en is er ondersteuning voor scrollen op hoge resolutie via de scrollwieltjes van Logitech- en Microsoft-muizen.

Ondertussen is het werk aan Linux 5.1 in volle gang en die gaat onder andere ondersteuning voor Intels 'Cyclone Peak' 22260-netwerkkaart voor wifi-ax brengen.

Reacties (80)

[Gerco]

Bij Linux zitten heel veel drivers in de kernel source tree, dat betekent niet dat ze ook allemaal geïnstalleerd worden wanneer je een Linux kernel installeert. De drivers worden als modules gebouwd en alleen geladen wanneer nodig.

Dit is een ander model dan bij Windows en Mac OS X, die beide een stabiele kernel-ABI hebben. Linux heeft dat niet en “moet” daarom de driver source code in de kernel hebben zitten.

[Verwijderd]

Er is geen belofte vanuit de kernel-community voor een stabiele kernel ABI. Maar heel vaak wijzigt deze niet en nog vaker is een recompile van de module voldoende.

Kernel modules 'moeten' echter niet open source zijn. Noch om ze te laden noch om legaal te bestaan. Er is namelijk een expliciete uitzondering opgenomen in de GPL licentie van specifiek de Linux kernel opdat dit kan en mag.

De kernel community trekt zich, terecht, echter wel nul komma nul van uw problemen aan van zodra je een tainted kernel hebt (een kernel met binary modules ingeladen waar geen source voor is). Vooral als je een bedrijf bent zoals Nvidia die een voorgeschiedenis hebben van open source tegen te werken. Vooral dan niet.

Maar als je bv. Microsoft bent die actief meewerkt om Azure ondersteuning open source in de kernel te onderhouden en voorzien, dan is de Linux kernel community uwe beste vriend.

[84hannes]

Kernel modules 'moeten' echter niet open source zijn. Noch om ze te laden noch om legaal te bestaan. Er is namelijk een expliciete uitzondering opgenomen in de GPL licentie van specifiek de Linux kernel opdat dit kan en mag.

Het moet inderdaad niet. Maar als je een binaire driver levert, en de kernel ABI veranderd een klein beetje, dan moet jij als fabrikant dat probleem oplossen. Als je een open source driver levert die (bijvoorbeeld vanwege licentierestricties) niet in de kernel is opgenomen, ook dan moet jij als fabrikant werk ondernemen om een nieuwe versie te compileren, al dan niet met enige wijzigingen als ook de kernel API gewijzigd is. Maar als je de driver in de source code van de kernel laat opnemen dan ben je als fabrikant van het probeel af: bij een ABI wijziging zal de distributeur van een linux-versie het hercompileren op zich nemen (of de eindgebruiker zelf, bij bijvoorbeeld Gentoo). Als er een API-wijziging is, dan zal de persoon die de comptabiliteit met jouw driver breekt dit ook zelf moeten oplossen.

Dus als je als fabrikant niet op extra werk zit te wachten dan zorg je dat je drivers opgenomen wordt in de kernel. Helaas heeft, door patenten en licentieovereenkomsten, niet iedere fabrikant deze mogelijkheid of wens.

[Verwijderd]

Precies. Zo zit het. Men vindt in de kernel community niet dat bedrijven die deze wens niet hebben moeten geholpen worden met een stabiele kernel ABI.

Die moeten het dan ook zelf maar uitzoeken.

[erikdenv]

Precies, je kunt je kernel zo groot of klein maken als je wilt. Je kunt de drivers meecompilen met de kernel waardoor ze direct bij het opstarten beschikbaar zijn of als module waardoor ze pas ingeladen worden als ze nodig zijn.
Ondersteuning voor PCI en SATA wil je meecompilen in de kernel maar een driver voor je videokaart of je scanner kan prima als module.
Veel distributies leveren praktisch alle drivers al mee als modules omdat je niet wat wat een gebruiker voor hardware heeft. Ik gebruik Gentoo en compileer mijn kernel zelf, de kernel bevat alleen de drivers voor mijn hardware. De rest heb ik niet nodig.

[lukjah]

Gewoon een vraagje. Waarom zou je niet alles meecompilen? Is toch lekker simpel en voor het ssd gebruik hoef je het volgens mij niet te doen.

[ux15]

Dan duurt het compilen veel langer, en het levert een grotere kernel op.

Een grotere kernel is heeft meer attack surface dan een kleinere, en is daarom ook minder secure.

Overigens zal je als je een "normale" linux distributie gebruikt, eigenlijk nooit zelf je kernel hoeven compileren.

EDIT: typefout

[Reactie gewijzigd door ux15 op 22 juli 2024 16:45]

[MrMonkE]

-ot-
Werkt dat -geen module maar compiled into kernel- in theorie sneller dan in onder windows met drivers?

[Verwijderd]

Neen. Niet echt. Of niet merkbaar echt. Een kernel module wordt ook in het geheugen van de kernel geladen. Een verschil is dat je met ingecompileerde kernel modules het laden van modules volledig kan uitschakelen.

Dit maakt uw kernel robuster tegen kernel rootkits. M.a.w. een trojan kan dan geen kernel module inserten om op die manier zichzelf onzichtbaar te maken voor softwares die onder de kernel lopen en die uitzoeken of die trojan aanwezig is.

Langs de andere kant kan zo'n virus ook gewoon de kernel image overschrijven (ook daar kan je tegen beschermen) eens root geworden (wat ook nodig is om kernel modules te laden). Dan ben je sjaak na de boot. Maar. Daar hebben we dan weer UEFI boot enzo voor. Bij dat soort boots moet je kernel's image signed zijn en zal de boot enkel de kernel inladen wanneer de image overeen komt met wat verwacht wordt.

[batjes]

Ergens vind ik het wel komisch hoe Linus in het verleden Microsoft tig keer afgevallen heeft vanwege de enorme bloated kernel van NT, en dat Microsoft allerlei problemen liep op te lossen in de kernel dat Linux op OS/distro niveau liet gebeuren.

Sindsdien is het speelveld best veranderd in dat opzicht. MS heeft die kernel verkleint en opgeschoond en Linus propt meuk die kernel in wat daar niet zou moeten horen. Linux is zich op een bepaald niveau veel meer als OS gaan gedragen

[elteck]

In diezelfde tijd, is Linux wel een dominante speler geworden (Android, ChromeOs, vele cloud servers, etc.), dus ze doen wel iets goed.

Dat bloated valt wel mee. In Linux kun je gewoon jouw hardware selecteren, en de rest weglaten, en deels kun je die zelfs (on demand) dynamisch laden. Effectief nauwelijks anders dan de micro kernel van NT (windows). Waar Linus in het verleden over klaagde was dat de monolitische kernel makkelijker te beveiligen was, dan de micro kernel die "kernel privileges" aan iedere module moest geven. Inmiddels is er heel veel veranderd, en heeft MS zelfs Linux omarmt.

[Croga]

Ik dacht dat het de bedoeling van Linux was om een zo kaal mogelijke kernel te draaien waarbij alle specifieke device-functionaliteit via drivers toegevoegd werd. Alles wat ik hier lees is dat er drivers toegevoegd zijn;
- Grafische functionaliteit zit toch in X? En aansturing van specifieke videokaarten in de videokaart driver? Wat heeft het ondersteunen van nVidia's 2000 series met de kernel te maken?
- Scrollwiel ondersteuning kan ik me voorstellen als kernel functie maar waarom dan specifiek de scrollwielen van Microsoft en Logitech in de kernel bouwen? Dat is toch driver functionaliteit?
- Same voor de Intel Cyclone Peak; draadloze netwerken worden al jaren ondersteund, deze implementatie hoort dan toch gewoon in een driver thuis?

We praten altijd over de vage update dingen van Microsoft. Maar als je in Linux de nieuwste drivers nodig hebt moet je nu je kernel updaten? Ofwel: LTS versie gebruiken ben je gesjochten wanneer je een andere videokaart installeert? En ervaringen uit het verleden vertellen mij dat een kernel update funest is voor je packages....

Is mijn beeld van de basale architectuur van Linux nou verkeerd of gebeuren er gewoon hele rare dingen?

[RangedNeedles]

Ik vroeg het me ook wel af. Touchscreendriver voor RPi, bijvoorbeeld. Leuk, maar als je daar niets mee doet, is dat een beetje nutteloos en verspilling van disk space. Of komt dit alles via inlaadbare modules? Of vinden we dit terug in de repo’s?

[sniek]

Je moet een driver binnen de kernel zien als een module. Aan of uit en dus wel of niet geladen. En als jij de linux kernel overdreven veel diskspace op vindt eten dan ... ja dan kan dat. Je kunt je eigen kernel compileren helemaal specifiek voor jouw systeem. Zo zitten kernels voor embedded systemen vaak ook in elkaar.

Ik denk dat de hoeveelheid overhead aan resources minimaal is en de benadering van Linux tov drivers vind ik persoonlijk erg fijn. Nooit meer een machine installeren om vervolgens op een USB drive ethernet drivers over te moeten zetten zodat je iig met internet verbonden kunt zijn.

[bjp]

het is idd zo dat een kernel + modules nogal klein is, toch voor wat je een typische computer noemt (< 100MB).
Voor beperkte systemen kan je idd vanalles laten weghalen wat je al weet dat je niet nodig hebt (<1MB).

Dat is net een kracht van Linux, het past of zowat vanalles

Ter antwoord op de vraag hieronder, een voorbeeldtje:750kB.
http://www.picotux.com/

Ander typisch voorbeeld, een WRT54G Linksys router: 2 of 4MB flash (ik heb er hier een paar nog liggen).
https://en.wikipedia.org/wiki/Linksys_WRT54G_series

[Reactie gewijzigd door bjp op 22 juli 2024 16:45]

[DrPoncho]

Een kernel met wat drivers op minder dan een MB?

[snoopdoge90]

Jazeker, vooral als we spreken over embedded systemen met specifieke configuraties. Niet te vergelijken met standaard server / desktop image.

Neem nou bijv. een simpele routertje welke ook vrijwel allemaal Linux zijn. Met iets minder dan twee MB heb je al alles wat je nodig hebt: een kernel met drivers (USB, netwerk, wifi, chipset, enz) + wat packages zoals dnsmasq (DHCP / DNS server), Dropbear (SSH), VIM (text editor) , Lighttpd (webserver) en zelfs Strongswan (IPSec VPN).

[Thymo]

Ik heb mijn eigen kernel gecompiled en zit (met een aantal drivers die ik zelden gebruik) rond de 4MB.

[Stiggy]

Een posix real time kernel met GUI, wat demo's, een game en een web browser op een floppy. Dat was de QNX 1.44 MB challenge!

[springtouwtje]

ik vermoed dat hij bedoelt: 100 MB - 1 MB = 99 MB

[gjmi]

Een kernel is echt niet groot. Alle bijgeleverde tools en windowsmanager spullen, dat kost ruimte.

[Alfa1970]

Een kernel kan nog véél kleiner. De meeste kernels van vandaag de dag zijn grotendeels bloatware.
Er wordt een heleboel rommel in kernels mee-gecompileerd die uit meerlaags libraries.

Sommige daarvan zijn 3 of 4 lagen diep waarbij functie x net weer een klein beetje andere parameters meekrijgt omdat de programmeur van library 2 vond dat de parameterisering of naamgeving van library 1 niet handig of duidelijk genoeg was. Helaas zijn de optimizers nog niet zo goed dat ze die meuk herkennen en uitfilteren.

Low level bekeken heb je voor een kernel maar een kilobyte of 30 a 40 nodig zelfs voor een moderne desktop PC, de rest is allemaal syntaktische suiker, libraries en drivers.

[dataindataout]

Nee hoor, paar MB in totaal is geen uitzondering.

[Tjahneee]

kijk is op https://distro.ibiblio.org/tinycorelinux/downloads.html

Je hebt daar al een linux distro van 11MB
En met totaal16MB heb je een WM (GUI) erbij.

[Reactie gewijzigd door Tjahneee op 22 juli 2024 16:45]

[Verwijderd]

Mijn router draait op een linux distro van 4 MB

[kidde]

Je kan de kernel standaard zichzelf (na het compileren) laten comprimeren met algoritmes naar keuze; zo kan je een zeer kleine kernel bouwen.

Overigens is vooral glibc erg groot (vooral met veel locales); die vervangen door ulibc levert misschien meer ruimte winst op.

[Blokker_1999]

De distributies die een kernel compileren voor een gewone PC gaan die specifieke driver simpelweg afvinken en je ziet daar niets van terug in je uiteindelijke build. Enkel distributies die zich op de RPi richten gaan die driver of aanvinken of als module voorzien waarbij een module hier nog de voorkeur gaat hebben omdat je deze tijdens het opstarten niet nodig hebt en achteraf kunt inladen als je die specifieke driver expliciet nodig hebt.

[.oisyn]

Ik heb geen verstand van Linux kernels specifiek, maar zou het niet gewoon kunnen gaan over standaard generic drivers zodat het out of the box gewoon werkt?

[Reactie gewijzigd door .oisyn op 22 juli 2024 16:45]

[beerse]

In de kernel zit voor veel zaken wel een standaard generic driver. Denk bijvoorbeeld aan de disk interface: Als je een module wilt laden voor een disk-interface, dan zou je een kip-en-ei uitdaging hebben. Dus zit er wel een standaard in die zo ongeveer overal wel werkt. MAAR die heeft alleen de basis functies. Wil je meer dan zou je daar drivers voor meten laden die het meer ontsluiten.

En daar zit hem de kneep: die extra functionaliteit heeft extra parameters en instellingen en zo nodig. De drivers en modules die geladen worden hebben dus een uitgebreidere interface. Binnen de software zou je "een grotere/andere stekker" kunnen zeggen. En de kernel moet daar op aansluiten. Dat is nu juist de reden voor tegelijk compileren: Dat de juiste aansluiting gemaakt kan worden.

[.oisyn]

Thanks . Ik drukte me wellicht wat verkeerd uit met "ik heb er geen verstand van", daar ik wel mijn eigen OS heb geschreven dus ik heb weldegelijk een beetje verstand van hoe kernels in elkaar zitten , maar specifiek van Linux heb ik weinig kaas gegeten. Ik vermoedde idd dat het dus zoiets was, bedankt voor de bevestiging.

[CAPSLOCK2000]

In de kernel zit voor veel zaken wel een standaard generic driver. Denk bijvoorbeeld aan de disk interface: Als je een module wilt laden voor een disk-interface, dan zou je een kip-en-ei uitdaging hebben. Dus zit er wel een standaard in die zo ongeveer overal wel werkt. MAAR die heeft alleen de basis functies. Wil je meer dan zou je daar drivers voor meten laden die het meer ontsluiten.

Volgens mij niet hoor.
Er is geen kip-ei probleem omdat je een bootloader hebt. Het is de taak van de bootloader om dingen van disk te laden en in RAM te zetten voordat de kernel start (typisch door de 'initramfs' image te laden). Als de kernel eenmaal start zouden alle benodigde drivers aanwezig moeten zijn.
Dan is wel weer de vraag hoe de bootloader aan een driver komt om de data van disk te lezen, maar dat is niet het probleem van de kernel.

[beerse]

Voor de eerste boot-stappen heb je gelijk: De boot-loader leest het boot-image en zet dat in geheugen.

Dan is wel weer de vraag hoe de bootloader aan een driver komt om de data van disk te lezen, maar dat is niet het probleem van de kernel.

En daar is nu het kip-ei probleem: Hoe leest de net op gestarte kernel de disk-drivers van disk. Hiervoor heeft ze basic/basale drivers nodig om in ieder geval te kunnen lezen. Voor zover ik het weet is dat op wintel-pc-s ongeveer zo:
- bij bios boot biedt de bios disk-lees routines. Die zijn niet te snel maar werken wel.
- bij uefi boot biedt de uefi interface de drivers aan, die heeft ze immers ergens staan. Omdat dit niet de beste/laatste/perfecte hoeven te zijn kunnen de nieuwere alsnog van disk gelezen worden.
Good-old pa-risc en sun-sparc systemen hebben (hadden) een boot-loader die daar voor gebruikt worden.
Overigens, het is goed mogelijk om de drivers in de kernel in te bakken. Met den gentoo-installatie kan je dat betrekkelijk makkelijk zelf doen. Dan zitten de goede drivers al in de kernel.

[CAPSLOCK2000]

Voor de eerste boot-stappen heb je gelijk: De boot-loader leest het boot-image en zet dat in geheugen.

En daar is nu het kip-ei probleem: Hoe leest de net op gestarte kernel de disk-drivers van disk. Hiervoor heeft ze basic/basale drivers nodig om in ieder geval te kunnen lezen.

Nee, er zijn geen basic/basale drivers. Het is de hele volwaardige driver of niks. De Linux-kernel en eventuele drivers worden door de bootloader in RAM gezet. Daarom is er geen kip-ei probleem.
Je bootloader/bios/eufi/whatever zal wel een driver nodig hebben om dit te doen, maar dat staat helemaal los van Linux. Als Linux een disk-driver laadt dan is het direct de complete, volwaardige, driver.

[killercow]

Dat is nu net de oplossing.
Ip plaats van dat elke dozenschuiver z'n eigen installer, crapware en logo's je desktop op duwt omdat zij echt de allertofste gui hebben gedacht om iets te regelen voor hun stakje hardware zie je dat er in linux-land juist knappe drivers worden geschreven voor de daadwerkelijke chip, of chip-familie. Hiermee worden alle andere tools overbodig, want de kernel weet hoe hij met de hardware moet praten, en de desktop omgevingen kunnen weer een genormaliseerde api aanspreken om tegen die drivers aan te praten.

Wifi was op windows eerst een wirwar van specifieke vendor drivers en tools, op linux werd dat al vrij snel een handje vol chip-specifieke drivers en een klein aantal desktop-smaak afhankelijke tools om je connectie te beheren. Goed, dat duurt even, en er zijn uiteraard drivers die nog een stukje functionaliteit missen omdat de hardware niet goed gedocumenteerd is, maar op deze manier scheelt het wel enorm veel onderhoudswerk en crapware.

[.oisyn]

Je reactie slaat echt kant noch wal. Zoals je in het artikel al kunt lezen zijn drivers dus helemaal niet "knap", het zijn standaard drivers met de bare minimum aan ondersteuning. En de rest van je relaas heeft helemaal niets (maar dan ook echt *niets*) te maken met hoe de kernel werkt en hoe die met drivers omgaat. Zo levert Microsoft ook tal van standaard drivers voor hardware. En net als bij Linux duurt het even voor hardware (en API's) gestandaardiseerd zijn.

Het is duidelijk dat je kritiek hebt op de praktijk in Windows, en dat bij drivers idd vaak allerlei crap meegeleverd wordt. Maar dat komt niet door het ontwerp van de Windows NT kernel, genoeg hardware vendors die gewoon keurige drivers leveren zonder allerlei nonsens toe te voegen.

Maar leuk dat je een discussie over de Linux kernel probeert te kapen om Windows af te branden

[Reactie gewijzigd door .oisyn op 22 juli 2024 16:45]

[killercow]

Je hoeft je niet zo aangevallen te voelen.
Ik had je post verkeerd gelezen zie ik.

Je gaf aan er niet veel van te weten mbt linux. Ik leg uit hoe het in de linux wereld gaat, het generieke driver model (ook helemaal niet vreemd aan windows inderdaad) is waar men naar streeft. Dat betekend dat het soms wat langer (en soms te lang) duurt voordat hardware en nieuwe features ondersteund worden, maar het scheelt doorgaans de brij aan tijdelijke oplossingen die vendors voor windows wel in elkaar draaien.

Ik probeer windows overigens niet af te branden, alleen de praktijk dat de nieuwste feature direct tot een non-generieke oplossing in de vorm van tijdelijke crapware leidt. Iets dat nu eenmaal meer gebeurt op windows omdat de vendors daar de grootste markt kunnen verwachten.

De drivers die nu toegevoegd zijn aan de kernel zijn inderdaad zoals jij aangaf generieke drivers voor deze nieuwe chipset. Iedereen met deze kernel kan dus out-of-the-box die hardware gebruiken, en doorgaans krijgen ook oudere kernels wel iets van een backport om dit mogelijk te maken als het echt nuttige hardware betreft.

[Marctraider]

Bijna alle drivers kan je in W10 gewoon bare minimum installeren. Gewoon geen setups gebruiken ;-)

[kidde]

Jawel, als je je er meer in verdiept zijn die drivers wel knap. En knapper dan bij Windows, als u dan toch per se zo graag wil vergelijken.

Eerst had iedere ARM chip zijn eigen driver. Dat werd een rotzooi waarbij 10 bedrijven hetzelfde net wat anders maakten. Zoals voor Windows altijd het geval is.

Dat werd op een gegeven moment niet meer geaccepteerd: De gemeenschappelijke stukken werden uitgefactoriseerd, dus ook openbaar gemaakt en beter beheerd. Daarom werd het heel makkelijk een driver pakket voor een ARM SoC te maken.

En daarom heeft Linux ondersteuning voor de honderden ARM SoC's die er zijn, en Windows momenteel maar voor hooguit 4 van slechts 2 fabrikanten: Op Windows moet iedere ARM SoC maker nog steeds zelf het wiel uitvinden; ze hebben immers geen inzage in drivers van concurrenten want die zijn closed Source.

Het binnen Linux uitfactoriseren van die gemeenschappelijke functionaliteit (bijv ook voor netwerkkaarten), leveranciers daarin meekrijgen, dat is het knappe, ook op politiek gebied. Dat is Microsoft vziw nooit gelukt.

Dus ja, de veel betere hardware support bijv voor ARM heeft wel met de Windows kernel te maken, maar niet met de technologie maar met de licentie; waardoor binnen Windows drivers onderling (dus tussen drivers) weinig code gedeeld wordt. Het stuk dat in Linux nu door verschillende bedrijven samen wordt gemaakt, moet in Windows ieder bedrijf alleen maken. Hierdoor is het voor Windows moeilijker en duurder een fatsoenlijke driver voor een complete SoC te maken, en daarom kunnen de armere ARM SoC makers alleen maar dusdanige bagger drivers leveren, dat ze gewoon in het geheel afzien van Windows.

Zo ook Broadcom: Vziw heeft MSFT zelf de drivers voor de Raspberry Pi moeten maken, waar voor Linux BCOM dat zelf doet.

Ook voor HPC geld trouwens hetzelfde: Windows voor niet-x86 supercomputers is dood. Want niemand wil drivers schrijven voor dat gesloten systeem.

Ook Google, Amazon en Alibaba, die nu hun eigen SoCs maken, bieden natuurlijk alleen ondersteuning voor Linux.

[batjes]

Standardisatie van ARM kwam vanuit ARM zelf met ARMv5. Waardoor je met 1 enkele driver in feite elke ARM chip van die generatie in 1 keer kon aanspreken. Wat in het verleden anders was. Nu kwam dat wel o.a. vanuit druk uit het Linux kamp, maar MS deed hierin net zo hard mee (WinCE is/was geen kleine speler).

Voor Windows is dit niet anders als bij Linux. Die ondersteund in theorie elke ARM chip die minstens het standaard API riedeltje kan praten (en dat kunnen ze vrijwel allemaal wel). Het ding is alleen dat een SOC heel wat anders is dan een CPU. En vooral op de smartphone, MS geen brakke ervaring wilt geven aan gebruikers. Niet werkende WiFi modules, gebrek aan encryptie, niet werkende codecs of amper/geen GPU ondersteuning. Er komt bij een SoC heel wat meer bij kijken, ondanks dat al die socs wel praktisch dezelfde ARM architectuur zijn, zullen die addons op de SoC vaak niet eens van dezelfde fabrikanten komen. Dus MS is -begrijpelijk- wat dat betreft vrij streng met de ondersteuning van ARM.

Met een beetje hacken krijg je Windows op de meeste ARM systemen SoCs prima draaiend, de stabiliteit en ondersteuning van andere hardware onderdelen is vaak een issue.

Dat netwerkkaarten (en veel andere hardware) in de jaren 90/begin 2000 standaard API's begon te verstaan is dankzij Microsoft. Die begon dat namelijk te eisen voor hun Windows stickertjes waar de fabrikanten zo tof mee konden doen. Hoezo is Microsoft dat nooit gelukt?

De hardware support, of naja, support van architecturen heeft inderdaad met de NT kernel te maken. Die is wat dat betreft hardware agnostisch. NT heeft op meer architecturen gedraaid dan alleen x86 en ARM. Wat dat betreft zijn Linux en NT hierin elkaars gelijke. Het verschil is alleen dat Linux de gebruikers vrij laat en Microsoft vrij streng is met hun support. Want ja, de gemiddelde Linux gebruiker is de gemiddelde Windows gebruiker niet en dan krijg je snel het verschil tussen "X crashed omdat applicatie/driver/hardware ruk is" of de "X crashed omdat Windows". Er is in NT maar een klein binary blobje wat direct met de CPU praat, de rest van de kernel maakt het geen bal uit welke CPU dit is, zolang er maar module voor is. Wat dat betreft geen bal anders dan Linux.

Het is helemaal niet duurder om voor Windows drivers te ontwikkelen, of naja, MS stelt eisen. Op Linux kan men maar wat doen en is men vaak zat al blij als men ergens een keer wel drivers voor krijgt. Ik weet niet hoe Linux het nu in een keer wel wint met driver support, maar zal aan mij liggen.

En voor HPC, Azure is 1 systeem, 1 platform.. Een super computer. Alhoewel Duitsland tot vorig jaar los draaide. Heeft ooit zelfs een linpackje gedraaid en er best een respectable score mee weten te halen. Was wel lange tijd eenzaam als enige NT systeem in de top 500

Google en Amazon zijn ook geen concurrenten van Microsoft oid.

[Reactie gewijzigd door batjes op 22 juli 2024 16:45]

[kidde]

Zoals ik al zei, 'als je je meer in de drivers verdiept'. Aangezien u daar kennelijk nog geen tijd voor heeft gehad, doe ik een poging te helpen.

Ten eerste: U verwart de ARM instructieset (bijv ARMv5) / ARM CPU (bijv. Cortex) met een 'complete ARM SoC'. Gaan we terug naar de rotzooi uit ca. 2011, welke ca. 20 aanbieders hadden we:

TI, Qualcomm, Broadcom, Marvell, Samsung, Cavium, NXP, Freescale, Renesas, ST-Ericsson, Allwinner, Rockchip, Mediatek, vapourware als NuChip, LG en AMD en nog een paar die ik vast vergeet.

Stel, die 20 maken allemaal minstens 5 modellen, dan waren er dus 100 'code-opberkbakken'; iedere SoC had compleet zijn eigen software.

Hoeveel GPU leveranciers waren er (behalve Qualcomm): ca 3, namelijk Imagination Technologies, Vivante en ARM. Is het dan handig, om 100 verschillende GPU-drivers in te leveren?

Hetzelfde geldt voor de DPS / HSP, daar waren ook maar een paar aanbieders voor (o.a. standaard van-de-plank ontwerpen zoals CEVA); of voor video accelerators (o.a. Ittiam). Al die dubbelingen wil je graag slechts 1x beheerd hebben.

Dan komt het hele randgebeuren er nog bij: GPIO, UART, I2C, MIPI, SATA, USB en al die meuk: Die hoef je echt niet 100x overnieuw te schrijven; juist veel van die zaken kan je delen.

Daarbij komt nog weer het aller, allermoeilijkste (waar Windows volgens mij nog steeds moeite mee heeft), en dat is het schedulen met big.Little. Linux heeft altijd een grote verscheidenheid aan schedulers gehad - inclusief de religieuze zaken eromheen (o.a. Con Kolivas brainfuck scheduler); en big.Little maakte dat nog moeilijker. Vroeger konden alleen alle keine kernen samen draaien, of alle grote; maar niet samen of bijv. 2 grote en 3 kleine samen (Heterogeneous MultiProcessing kwam pas later). Dat hele stuk, big.Little, delen bijna al die ARM kernen. Zoals vermeld het gestuntel bij MSFT hieromtrent; zij kwamen pas 4 jaar nadat Linux al HMP had met hun allereerste babystapjes op big.Little gebied. Intel gaat nu ook dat concept kopieren, dus kans is groot dat Linux weer als eerste fatsoenlijke support daarvoor gaat hebben.

Het werken met de ARM-instructieset zelf, is dus misschien < 2% van de hele SoC software.

Wat voor een rotzooi was het in 2011? Staat hier schitterend uitgelegd, en hier mede ondertekend door de Linux Foundation.

Wat was het samenwerkingsverband dat dit ging oplossen, en waarin "concullega's" samen de rotzooi gingen opruimen? Dat is (nog steeds) Linaro. Vziw is er geen 'winaro'; ARM-SoC fabrikanten werken niet samen met het delen code voor Windows-drivers.

Wat was het resultaat in 2012? Zie o.a. hier.

Hoe ziet dat er in de praktijk uit? Kennelijk zo.

Daarom kan een 'opkomend' bedrijfje zoals een paar jaar terug HiSense (Huawei), Phytium of Dreamchip binnen beperkte tijd een werkende SoC met Linux ondersteuning uit de grond stampen. En zoals hierboven beschreven, is dat dus ook de reden dat dit voor Windows niet lukt: Die gezamenlijke Linux drivers zijn gewoon echt knap geschreven (en gezamenlijk verbeterd!); en het is omdat Linux open source is, gewoon heel makkelijk om hier met software mee te experimenteren; al tijdens de ontwerpfase van je fysieke product.

[Reactie gewijzigd door kidde op 22 juli 2024 16:45]

[phaas]

Ik vind het toch raar dat ze over zijn gegaan op de 5.x versienummers. Is het echt zoveel meer werk om 4.21 te typen, lijkt me nou ook weer niet. Vroeger was de nummering sowieso veel helderder: even minor voor stabiel en oneven voor beta versies.

[Reactie gewijzigd door phaas op 22 juli 2024 16:45]

[Belgar]

Het is voornamelijk psychologisch belangrijk. De kernel is nu eenmaal een product. Er worden nog zelden echt grote stappen gemaakt, dus vanuit die gedachte kun je nog door tot 4.xxxxxx . Om de zoveel te tijd de versie verhogen geeft duidelijk aan dat er nog vernieuwing is en dat er "oudere" en "nieuwere" kernels zijn.

Aan de andere kant, als je het te vaak doet loop je het gevaar dat vooral grote bedrijven belangrijke features gaan opsparen om alleen te releasen in versieverhogingen vanwege de extra aandacht. Daarom wordt ook pas na de finale RC besloten of het versienummer veranderd wordt.

Er is nu weer aandacht voor de kernel. Bedrijven kunnen binnenkort weer pochen dat zij de "nieuwste" linux al hebben. Builders kunnen een nieuwe schone "tree" beginnen. Dezelfde discussie was er rond 2.48 (?). Veel bijdragen zijn tegenwoordig nu eenmaal van megabedrijven en die willen hun management af en toe ook vertellen dat ze "v5 mogelijk hebben gemaakt".

[strompf]

Interessant. Zoiets als Apache, die ooit een 2.x-release had, en nu vermoedelijk tot in lengte van dagen met dat versie-nummer opgescheept zit.

[The Third Man]

Zo helder was het niet dat er 8 jaar zat tussen 2.6.1 en 2.6.39 om maar een voorbeeld te geven. Juist een major release elke 4 of 5 jaar is een betere afbakening, zo was het trouwens ook voordat 2.4 en 2.6 kwamen.

[Reactie gewijzigd door The Third Man op 22 juli 2024 16:45]

[Rukapul]

Het grootste onderdeel van Linux zijn juist de drivers. De kernel en drivers worden ontkoppeld via APIs.

En inderdaad een moderne videokaart op een oude LTS versie kan lastig zijn als e.e.a. niet is gebackport. Soms kan het in geheel niet.

[henk717]

Lastig kan het zijn maar met llvmpipe is het geen ramp meer. Deze driver is voor software rendering en ondersteund OpenGL 3.1 (3.0 in oudere versies). Traag maar wel snel genoeg voor de desktop interface. Vanaf daar kun je een nieuwere kernel of driver installeren.

[Blokker_1999]

Drivers horen bij de kernel. Ofwel in de kernel gecomponeerd ofwel ingeladen als modules. Software als X11 is geen driver maar een renderer. Die bepaald wat er op het beeld staat en stuurt dat door naar de driver om op het scherm te tonen.

[phaas]

X11 is in een user proces, dus een gedeelte van de hardware ondersteuning zou altijd ergens op kernel niveau plaats moeten vinden. Er is altijd de keuze om de drivers als losse modules te compileren of in de kernel mee te bakken. Ik weet niet precies welke keuzes distributies daarin maken, maar als je wel eens zelf de kernel hebt gecompileerd, dan ben je dat waarschijnlijk wel tegengekomen. Verder is inderdaad een groot deel van de taak van een kernel om het eerste stukje communicatie met de hardware te regelen, vandaar de enorme stapel drivers die er in de Linux kernel zit. En ja, in sommige gevallen moet je je kernel updaten voor een nieuwe driver. Vroeger was dat wel eens een probleem, maar met moderne distro's heb ik dat eigenlijk nooit meer gezien. LTS versies krijgen volgens mij sowieso nog lang kernel-updates.

[psychicist]

Linux is een monolithische kernel met drivers die in de kernel gecompileerd of als modulaire drivers geladen kunnen worden. Sinds een aantal jaar zit de basisfunctionaliteit voor grafische ondersteuning in de kernel via KMS (kernel mode setting). Tegenwoordig kun je dus ook een grafische schil draaien zonder gebruik te maken van X, bijvoorbeeld via Wayland.

De open source nouveau driver heeft eveneens een kernelcomponent en een Xorg module. Wat betreft scrollwielen denk ik dat het eerder het geval is dat de driver voor USB hid apparaten aangepast is om deze muizen met hoge resolutie scrollwielen goed te laten werken.

Linux heeft heel veel drivers in de kernel sources, maar ondersteuning voor nieuwere protocollen moet ook in de gemeenschappelijke code voor een subsysteem opgenomen worden. Eigenlijk snap ik het probleem niet echt. Als je niet de kernel van je distributie wilt draaien, kun je je eigen kernel compileren en installeren. Maar met de hardware van tegenwoordig is dat niet echt meer nodig.

Als je een nieuwe videokaart installeert, kun je bijvoorbeeld in het geval van Nvidia gewoon eerst de nieuwste proprietaire driver installeren, voordat je de nieuwe videokaart in het systeem zet. En als je een van de grotere distributies draait die backports van kernels en drivers ondersteunt, hoef je eigenlijk nooit zelf met kernels en X/Mesa drivers aan de slag. Ubuntu upgrade gewoon die componenten iedere 6 maanden in LTS versies naar die van de reguliere versies met een beperkte ondersteuningstermijn.

[D0phoofd]

Een kernel update staat los van of je een LTS versie hebt of niet. LTS is gewoon een term dat "Distro" versie 18 voor X jaar ondersteund is. Dat gaat eerder over packages. Dat betekent niet dat je vast zit op kernel versie 4.15. (Zie Arch / Manjaro)

Los daar van, kun je altijd je kernel updaten. Sterker nog, sinds een recente versie kun je kernel live-patchen zonder reboot. Maar een reboot kan nooit kwaad natuurlijk.

[ard1998]

We praten altijd over de vage update dingen van Microsoft. Maar als je in Linux de nieuwste drivers nodig hebt moet je nu je kernel updaten? Ofwel: LTS versie gebruiken ben je gesjochten wanneer je een andere videokaart installeert? En ervaringen uit het verleden vertellen mij dat een kernel update funest is voor je packages...

het is aan de distro om te bepalen hoe met updates om te gaan. In ubuntu gebaseerde LTS distros kan je van gebruik maken de hardware establishment stackom een nieuwe kernel en nieuwe X server te verkrijgen. voor meer info, zie https://wiki.ubuntu.com/Kernel/LTSEnablementStack

[Reactie gewijzigd door ard1998 op 22 juli 2024 16:45]

[beerse]

De grafische functionaliteit voor de gebruiker zit in X11.
Maar vanuit de kernel gezien wordt de console en dus de aangesloten monitor op meerdere manieren aangestuurd:
- als tekst terminal, zoals ook bij booten zichtbaar is: Daar waar je de bios/uefi instellingen doet. De kernel begint in deze stand.
- als frame-buffer: De door de kernel aangeboden, 'minimale' grafische omgeving, overigens ook met een tekst interface. Als je bij het booten de tekst-interface ziet schakelen, bijvoorbeeld naar een ander lettertype (meestal kleinere letters en dus meer tekst op het scherm).
- als interface tussen de grafische gebruikers interface en de hardware drivers. Zoals dat bijvoorbeeld bij X11 en wayland gebeurt.

[i-chat]

je hebt het deels goed, want drivercode die niet opensource is maar wel kernel specifiek is een behoorlijk probleem in linux, dit is zo'n beetje DE reden voor MS om een ander model te hanteren. wanneer code echter wel open is kunnen heel wat patches en zeker ook drivers worden gebackport naar kernels voor LTS releases, dit is dan echter wel de taak van de software-leverancier (Cononical, Redhad, Oracle etc).

vaak is het dan inderdaad makkelijker om toch voor een kernel upgrade te gaan wanneer je nieuwe hardware wilt implementeren.

[CAPSLOCK2000]

Ik dacht dat het de bedoeling van Linux was om een zo kaal mogelijke kernel te draaien waarbij alle specifieke device-functionaliteit via drivers toegevoegd werd.
<knip>
Is mijn beeld van de basale architectuur van Linux nou verkeerd of gebeuren er gewoon hele rare dingen?

Je beeld is verkeerd. Kernel en drivers worden onder Linux samen ontwikkeld en gedistribueerd. Het klopt wel dat er een vrij kale kern is, maar die is zo kaal dat je er niks aan hebt. De meeste functionaliteit van de kernel zit in drivers en zonder die drivers heb je geen werkend systeem. Het is mogelijk om extra drivers toe te voegen aan de kernel uit een andere bron, maar zonder drivers heb je ook geen kernel. In het taalgebruik wordt daarom meestal geen onderscheid gemaakt tussen de kernel en de drivers.

[burne]

Is mijn beeld van de basale architectuur van Linux nou verkeerd

Ja. En flink ook. En alle vragen die je stelt worden al twintig jaar lang gesteld en beantwoord. Dus ook dat is onnodig.

Dit is leuk als je kernel-developer bent. De rest van de wereld heeft hier nog niets aan. Als je het oneens bent met muiswiel-kernelsupport: Stuur Linus een mailtje waarin je je klachten uiteen zet. Hij zal er vast vriendelijk op reageren.

[pennywiser]

Inderdaad reageert Linus tegenwoordig vriendelijk, maar jij loopt nog wat achter denk ik?

[Reactie gewijzigd door pennywiser op 22 juli 2024 16:45]

[SuperDre]

Dat was precies mijn gedachte ook, bij elk punt dat hier genoemd wordt dacht ik, "maar dat hoort toch niet in een kernel thuis, dat hoort in een driver thuis".

[Jazco2nd]

Maar waarom zoveel tijd aan FreeSync ondersteuning besteden ipv die tijd direct in FreeSync 2 te stoppen?

[ard1998]

omdat freesync 2 een doorontwikkeling is op vsync 1 en daardoor vsync 1 ondersteuning een belangrijke tussenstap is om tot freesync 2 te komen.

[Rob Coops]

Dat en omdat het simpel weg tijd kost om zo iets te bouwen, het is niet even een paar minuten typen en door naar de volgende taak. Om die reden is het hele goed mogelijk dat freesync 2 simpel weg nog niet klaar was maar freesync al wel in een staat is waar men het aandurft deze mee te leveren voor de gewone gebruiker.
Vergeet niet dat veel van het werk aan de linux nog altijd buiten werktijd om door vrijwilligers gedaan wordt en niet door betaalde teams van enkele tientallen of zelfs honderden mensen zo als bij Windows bijvoorbeeld wel het geval is. Om die reden duurt het vaak even voor Linux dit soort nieuwe standaarden kan ondersteunen. De andere kant van het verhaal is wel dat omdat het veel al hobby matig gedaan wordt mensen vaak meer aandacht besteden aan het zo goed mogelijk laten werken van de functionaliteit waar bij commerciele pakketten het niet zelden goed genoeg is omdat er simpel weg geld verdiend moet worden en men dus naar het volgende project verschoven wordt.
Dit zorgt er voor dat mensen binnen de Linux community soms zeer idealistische beslissingen nemen om bepaalde dingen anders te implementeren omdat het netter is etc, waar het lang niet altijd een betere of snellere manier van werken is maar architectonisch wel mooier bijvoorbeeld.

[MrMonkE]

Ik neem aan dat AMD er ook wat boys op gezet heeft.
Of negeren die dat soort iniatieven?

[N8w8]

Zo te zien is er ook Freesync 2 support.
@Rob Coops/@MrMonkE: AMD betaalt al jaren werknemers om aan open source Linux drivers te werken, net als Intel, en in tegenstelling tot nVidia. Deze commit is ook van een AMD werknemer, die dat ws niet vrijwillig heeft gedaan maar ervoor betaald wordt.

[Reactie gewijzigd door N8w8 op 22 juli 2024 16:45]

[ro8in]

Kan je eigenlijk gewoon Linux draaien als in Linux? Dus niet van een distro zoals Ubuntu of Redhat, maar gewoon de originele vanilla Linux. Of is Linux enkel de kernel en komt er een distro bij kijken om het daadwerkelijk installeerbaar te maken etc?

[Reactie gewijzigd door ro8in op 22 juli 2024 16:45]

[Drakin-Korin]

Ja,
De Raspberry Pi doet dat.

Je hebt dan onderstening voor basis toetsenbord, scherm, hd, netwerk, usb. Iets als MSDOS maar dommer.
Met wat basis commandos(assembler ....) kan je dan een C compiler inladen en zo stapje voor stapje verder gaan.

Oorspronkelijk was Linux Unix compatibel en dus konden ze direct unix programma's laten draaien.

[ro8in]

Heb je toevallig meer info, waar kan je dit downloaden etc?

[batjes]

www.kernel.org
Als je echt alleen de kernel wilt hebben, zul je deze zelf mogen gaan compileren. Als je meer een soort bare bones Linux ervaring wilt, zijn er misschien andere opties.

Een netinstall van Debian is echt bare bones 0 applicaties met alleen een command line interface.
Arch Linux is ook een mooie, waarbij je ook met net iets meer dan 0 begint en alles zelf mag opzetten. Wel hardcore difficulty in vergelijking met Debian.

[CAPSLOCK2000]

Kan je eigenlijk gewoon Linux draaien als in Linux? Dus niet van een distro zoals Ubuntu of Redhat, maar gewoon de originele vanilla Linux. Of is Linux enkel de kernel en komt er een distro bij kijken om het daadwerkelijk installeerbaar te maken etc?

Dat laatste, Linux is strict genomen alleen de kernel den de drivers. Je hebt een distro nodig om een bruikbaar systeem te maken. Op zich kun je een losse kernel op een USB-stick zetten en die booten, maar dat is alsof je een los motorblok in de garage hebt liggen zonder chasis, wielen of stuur. Het ding zal wel draaien, maar je hebt er pas iets aan als je zo'n motor in een auto inbouwt.

[Natsu]

Je hebt Linux From Scratch http://www.linuxfromscratch.org/ een handleiding om zelf je eigen Linux systeem te bouwen.

[ro8in]

Thank you! Dat is een beetje wat ik bedoelde. Lijkt me leuk om eens te gaan proberen als ik wat tijd heb.

[Kalief]

"5.0 betekent niet veel meer dan dat de 4.x-nummers zo groot werden dat ik vingers en tenen tekort kwam."

Als ik zo naar die pinguïn kijk zal dat al snel het geval zijn.

[HollowGamer]

Jammer dat het enkel werkt over DP, mijn LG monitor (net als vele andere) ondersteund via CRU Freesync over HDMI. Hopelijk kan dit nog worden toegevoegd of via een omweg.

De Linux kernel is echt flinke stappen aan het maken o.a. op gebieden als I/O en energiebeheer. Met wat tweaks haal je een flinke snelheid boost, maar ook je notebook kun je het langer laten volhouden (mijn uren komen boven die van Windows 10 uit).
Het is jammer dat veel van die dingen niet standaard aanstaan, maar dat komt vooral doordat fabrikanten deze niet goed implementeren (kijkt boos naar externe USB RAID controller).

Nouveau heeft een mooi streven, maar ik zie liever NVIDIA zijn drivers opengooien zoals bij AMD. Zelf ben ik naar AMD overgestapt omdat NV simpelweg andere standaarden heeft dan de min-of-meer afsproken protocollen en had ik ontzettend veel lag op KDE. Overigens zijn nog niet alle onderdelen opensource, al is AMD flink aan het porten.

Het enige jammer vind ik de beschikbare Linux desktop-omgevingen. In mijn ogen zijn die niet zo gebruiksvriendelijk als op macOS en Windows 10. GNOME gooit steeds meer dingen in een Tweak-tool, KDE heeft nog altijd zijn nukken (geen CSD bv.), 'casual' gebruikers moeten toch vaak teruggrijpen naar terminal.. nee, voorlopig zie ik nog geen verplaatsing naar Linux-desktop, al gaat het met gaming op Linux wel de goede kant op.

[Reactie gewijzigd door HollowGamer op 22 juli 2024 16:45]

[i-chat]

gnome is inderdaad ook mijn vriend niet, en kde heb ik eigenlijk nooit echt overwogen, ik draai daarom cinamon op mint, het heeft hier en daar wel wat puntjes, maar over het algemeen vind ik het nog steeds een van de pretigste Desktop omgevingen die er zijn.

[JustWesol]

Ik zou liever willen zien dat de driver's voor wifi usb sticks in de kernel komen. Momenteel moet je usb tethering gebruiken met je telefoon om die drivers te clonen en compile....... (rtl8812au driver)

[Reactie gewijzigd door JustWesol op 22 juli 2024 16:45]

[jimshatt]

xf86-video-amdgpu?? XFree86 bestaat toch allang niet meer? Bij mij heet hij 'xserver-xorg-video-amdgpu'.

Zal wel afhankelijk zijn van je distro natuurlijk (ik gebruik debian).

[PureTryOut]

Zal wel afhankelijk zijn van je distro natuurlijk (ik gebruik debian).

Ja, natuurlijk. In bijvoorbeeld Arch Linux of Alpine Linux heet het wel gewoon xf86-video-amdgpu.

[TaboZ]

Linux is alleen de kernel. Daarnaast worden veelal de GNU-tools geinstalleerd. Je draait ook geen linux, maar linux/GNU.

edit: was een reactie op bovenstaande.

[Reactie gewijzigd door TaboZ op 22 juli 2024 16:45]

[PureTryOut]

Ik kan ook Alpine Linux draaien, dan is het echt geen GNU/Linux hoor.

[TaboZ]

"veelal"

[Kafka]

Freesync, is dat gratis ofzo? Nog nooit van gehoord.

[ro8in]

Jij komt net onder een steen vandaan?

http://bfy.tw/MbDQ