Linux-onderhouder weert AMD-drivercode uit kernel

De onderhouder van de Direct Rendering Manager van de Linux-kernel heeft geweigerd om 100.000 regels aan AMD-code in de kernel op te nemen. Volgens hem bevat de code te veel hardware abstraction layers, wat het onderhouden ervan bemoeilijkt.

De AMD-code moet voor een driver met aanvullende functies ten opzichte van de amdgpu-driver zorgen, waardoor bijvoorbeeld ondersteuning voor hdmi 2.0 en FreeSync mogelijk is. Deze stond eerst bekend als DAL, maar heet nu DC. Volgens de onderhouder Dave Airlie bevat de code van AMD te veel hardware abstraction layers, zo schrijft hij in een mailinglijst. "Dit maakt het de inzet voor AMD misschien waard, maar voor de Linux-kernel biedt dit geen voordeel en zorgt ervoor dat de code een stuk lastiger te onderhouden is", aldus Airlie.

Hij voegt daaraan toe dat hij de code niet om politieke redenen aan de kernel wil toevoegen en dat hij niet het vertrouwen van Linus Torvalds op het spel wil zetten. Hij voegt daaraan toe dat de Linux-kernel ook zonder de toevoeging wel zal overleven, ook al 'zal dit een aantal mensen boos maken'. Phoronix schrijft dat AMD de abstractions in de code heeft opgenomen zodat deze bijvoorbeeld ook op Windows-systemen te gebruiken is.

De site meldt verder dat AMD zich nu in een lastige positie bevindt, omdat de code nodig is voor de ondersteuning van toekomstige gpu's. Het bedrijf staat daarom voor de keuze om alle abstractions te verwijderen, waarvoor het naar eigen zeggen echter geen mankracht heeft. Het is vooralsnog nog niet duidelijk op welke manier AMD dit probleem wil oplossen.

Reacties (214)

"Here's the thing, we want AMD to join the graphics community not hang out inside the company in silos. We need to enable FreeSync on Linux, go ask the community how would be best to do it, don't shove it inside the driver hidden in a special ioctl."

AMD is niet blij:
https://lists.freedesktop...2016-December/126684.html

"Here's the thing, we want AMD to join the graphics community not hang out inside the company in silos. We need to enable FreeSync on Linux, go ask the community how would be best to do it, don't shove it inside the driver hidden in a special ioctl."

AMD is niet blij:
https://lists.freedesktop...2016-December/126684.html

Dat is het voordeel en nadeel van open source.
Bij closed source worden dit soort zaken binnendeurs onderhandeld bij open source kun je alles mee volgen.

Daarom moet je dit bericht met een pak zout nemen.

Daafrom zou een titel
"Linux-onderhouder weert huidige AMD-drivercode uit kernel"

Bij ee presentatie van Greg Kroah-Hartman geweest daar vertelde hij ook dat Microsofts Hyper-V kernel code meermaals afgekeurd was voordat het aan de Linux kernel eisen voldeed.

Daarom denk ik dat het alleen heel erg mee gaat vallen. De code zal uiteindelijk in aangepaste vorm in de kernel komen.

Leuk artikel voor de sensatiepers die weinig binding met open source heeft.

Stukje copy&paste uit de mail vanuit de AMD kamp:

..and we get shit on for trying to do the right thing. It doesn't exactly make us want to continue contributing

Oei, hopelijk blijft het maar bij 'idle threats' en trekken ze zich niet compleet terug.

Dat "contributing" is natuurlijk een holle frase. Het is geen liefdadigheid daar bij AMD. Een goede werking van hun producten op de Linux kernel is inmiddels een strategische noodzaak.

"If Linux will carry on without AMD contributing maybe Linux will carry on ok without bending over backwards for android."

Damn.

Ik vind het juist geniaal

Maybe we could try and support some features right now. Maybe we'll finally see Linux on the desktop.

Would you like some ointment?
- what for?
That sick burn.

Maak die drivers gewoon open source dan heb je er genoeg die er aan sleutelen tot de laatste frame.

Ik denk dat het open source is.
Het gaat meer om gemierenneuk.

Nou ja, gemierenneuk, ik kan zelf als softwareontwikkelaar dat als er code van derden aan je project toegevoegd moeten worden, deze wel moeten passen in de structuur.
Anders wordt het in de toekomst bij bepaalde refactors totaal onhoudbaar.

Het is leuk dat AMD een hoop zooi geabstraheerd heeft om zo gemakkelijker hun code voor meerdere platforms te schrijven, maar dat moet niet ten koste van de code kwaliteit van de linux kernel gaan.

Dus ik snap het standpunt wel. De functionaliteit is secundair aan de algehele kwaliteit van de code. Dat bijt je anders enorm in de toekomst, en dat raakt meer vlakken dan enkel het AMD stukje.

Het probleem is dat ontzettend veel derde partijen code voor linux schrijven, en er hierover vaker wordt geklaagd. Linux' obsessie voor perfecte code zorgt er regelmatif voor dat prima functionele code geschrapt wordt. Het houdt de voortgang van de OS tegen.

AMD heeft een reactie geschreven in een mail terug naar Linux die je kan vinden in een reactie van xDiglett hier. Ik kan het zeker niet oneens zijn met hun klachten. Er is een balans tussen "perfecte" code en functionele code. Misschien zit AMD net iets te ver aan de (voor hun) functionele kant, maar Linux blijft koppig veel te ver aan de andere kant plakken. Nogmaals - er is een balans. Linux weet die niet te vinden. Wil Linux ooit concurrentie vormen, dan moet daar iets veranderen.

Wil Linux ooit concurrentie vormen? Statististisch gezien loop je flink wat jaren achter. Ze hebben een goed werkend systeem dat door dusdanig veel machines word gebruikt dat het het meest gebruikte besturingssysteem op dit moment is (als ik het mij goed herinner, meer dan Windows en OSX bij elkaar). Ze kunnen dit omdat ze perfecte code eisen. Er is geen balans nodig. De code moet goed zijn, zo niet, veranderen tot het wel goed is. Een stuk brakke software in de kernel inbouwen is iets dat gewoon niet kan. Dat gaat later weer mis en dat wil je voorkomen.

Een voordeel is ook wel dat Linux eenvoudig geforkt kan worden. Hoe lang heeft Android wel niet met allerlei aanpassingen de kernel gedraaid? En een Google zou waarschijnlijk Microsoft wel kunnen overtuigen om aanpassingen aan WinRT's kernel te gaan beheren. Maar kleine spelers meestal niet. Dat kan bij Linux eenvoudiger. Ik denk dat ook daar een grote reden van succes in schuilt. En niet enkel in 'perfectie'. Het mag trouwens misschien vloeken in de kerk zijn, maar zeker niet alle Linux kernel kode is perfect hoor. En zéker niet code die extern beheerd wordt.

Je moet voor te lachen maar eens de mottige rotzooi die de gobi driver van Qualcomm (van vroeger, maar veel in gebruik bij Android op dit moment) is eens bekijken. Die qcusbnet.c en qmidevice.c en zo jongens jongens toch. Ma goed, die geraakt dan ook niet in upstream.

Zeker mee eens voor waar het nu voor wordt gebruikt. Maar ze willen ook terrein winnen in Desktop gebruik en in gaming, en dat gaat op deze manier niet lukken. Dus ja, ze willen concurreren, maar ze willen overal concurreren.

Een stuk brakke software in de kernel inbouwen is iets dat gewoon niet kan. Dat gaat later weer mis en dat wil je voorkomen.

Het gaat hier niet om 'brakke code'. Niemand beweert dat er fouten inzitten.

[Reactie gewijzigd door Kalief op 10 december 2016 02:19]

dat door dusdanig veel machines word gebruikt dat het het meest gebruikte besturingssysteem op dit moment is

Helaas is de inzet van die vele linux toepassingen bijzonder onveilig omdat er nooit of vrijwel nooit iets gepatched wordt op de iot devices of consumenten elctronica die de bulk van deze getallen vormen..
Daar doet zuivere code weinig aan af en voegt er al helemaal niets aan toe.

Alleen de closed-source forks van je telefoon enzo hebben daar last van. Daar heeft de fabrikant ook nog eens een hoop meuk aan toegevoegd wat nooit in mainline gaat komen, met daarin god weet wat voor kwetsbaarheden.

Gewone open systemen kun je prima bijwerken.

Helaas, er zijn ongelooflijk veel apparaten die volledig open source zijn met Linux kernels die volsterkt onveilig zijn en nooit meer een patch ontvangen. (closed source maken op basis van open source is ook onmogelijk trouwens, de licentie laat dat niet toe)
Het feit dat ze open source zijn helpt niet echt als er niemand een oplossing voor maakt en los daarvan zijn de betreffende gebruikers niet eens in staat een optionele patch toe te passen.

Gebruikers hoeven dat ook helemaal niet te doen, dat hoef je op je PC ook niet.

Als je een open platform hebt, kun je upgrades gewoon online regelen, en een paar guru's zorgen dan wel voor het patchen van de kernel enzo. Dat werkt zo in bijvoorbeeld Ubuntu, maar ook voor open-source settopbox PVR apparaten, en dat zou ook prima kunnen voor tablets en telefoons.

De meeste telefoons en tablets bevatten weliswaar open source code, maar zijn helemaal niet open. Je kunt er geen andere software op draaien dan wat de fabrikant erop gekwakt heeft, en als je de sources vraagt wordt je opgescheept met meer dan 12000 patches op de kernel alleen al, en wat je zelf bouwt krijg je doorgaans niet werkend omdat de proprietary bootloader ook nog dwars gaat liggen.

En aansluitend op je laatste alinea: er wordt dus nooit meer gepatched!
Er zijn ook heel veel apparaten waar geen enkele guru zich nog aan zal wagen en dus tot het einde der dagen onveilig blijven.

Die zouden toch ook geen update ontvangen als er closed sourced firmware op draaide?

Ze hebben een goed werkend systeem dat door dusdanig veel machines word gebruikt dat het het meest gebruikte besturingssysteem op dit moment is (als ik het mij goed herinner, meer dan Windows en OSX bij elkaar). Ze kunnen dit omdat ze perfecte code eisen.

Ze kunnen dit omdat het licentietechisch mag, en ook nog eens goedkoop is. Zeker niet omdat de code van de kernel beter is.

https://en.wikipedia.org/...hare_of_operating_systems
meest gebruikt? miss ik iets?

De wereld is groter dan alleen desktop pc's

Ja, maar de pagina geeft ook geen duidelijk beeld over embedded. Heel vaak draaien daar custom Linux dingen op. OpenEmbedded, Yocto, Baserock: dat zie ik allemaal niet. De hele Duitse autoindustrie is echter wel Yocto en Baserock aan het gebruiken.

Waar zitten al die autodashboards op die wikipagina? Allemaal Android? Nee. Niet.

Die statistieken bestaan niet. Omdat dat heel moeilijk te meten is.

je vergeet je magnetron, koelkast, auto, navigatiesysteem, telefoon, etc etc etc

Yes. Ik ben het met je eens. Overigens is het heel vervelend als je geschreven code min of meer de prullenbak in kan. Zonde van de capaciteit.

Overigens, iemand heeft het al gezegd, maar ik denk dat dit probleem voorkomen had kunnen worden als de submitter (AMD) in een vroeger stadium wat code had gedeeld.

Maar goed, erg zonde dit.

Nee, ze hebben een platform onafhankelijke driver die ze voornamelijk op windows ontwikkelen.
(Dus niet een Windows driver die ze op linux laten werken)

Maar dat is dus wel de terechte opmerking van de linux mensen, in een linux kernel hoort geen code/structuren die voor andere platformen bedoeld zijn. (Mits de code hierdoor anders is dan waneer alleen Linux ondersteund zou worden)

Aan de andere kant zorg soon platform onafhankelijke driver er wel voor dat de driver volledig gelijkwaardig is aan windows en tegelijk gepatched en of getweaked word.

Tja, aan de andere kant is dat het goedrecht dat de linux ontwikkelaars hebben.

Het houdt inderdaad de voortgang van het OS tegen, maar dat is zowel een nadeel als een voordeel. Windows houdt er problemen op na die in dit soort zaken zijn genest. Linux heeft dit effectief nooit - juist omdat ze nooit genoegen nemen met minder dan perfect.

Het gaat niet eens over de code kwaliteit. Het gaat puur over het feit dat er een HAL gebruikt wordt. Ik zie code kwaliteit en het ontwerp van de code als 2 aparte, doch met elkaar verbonden, zaken.

Het hoofd argument wat gemaakt wordt is dat een HAL het zeer lastig maakt voor 'buitenstaanders' om zich goed te verdiepen in de code en deze te kunnen doorzien.
Ze zijn bang voor een vendor die een berg code als deze dumpt, en dat dan andere mensen het mogen gaan onderhouden.
If anything heeft AMD al redelijk bewezen dat het niet zo'n partij is. Dus wat dat betreft mogen ze AMD best wel wat meer credits geven op dit gebied.

Zoals ik het begrepen heb gaat het hier niet over een HAL (Hardware abstraction Layer) maar over een, ik zal het maar een, KAL, noemen (een Kernel abstraction Layer). Een HAL is logisch, maar dan wel vooral in userland. udev en zo dus. De kernel werkt met de hardware. Abstractielagen tussen de kernel en de hardware zitten snel in de weg.

De kernel *is* in feite onderdeel van een abstractielaag. Abstractie hoort geen turtles all the way down te zijn.

Lees ook zeker dit eens:
(6) It is easier to move a problem around (for example, by moving the problem to a different part of the overall network architecture) than it is to solve it.

(6a) (corollary). It is always possible to add another level of indirection.

Je mag gerust van me "the overall network architecture" vervangen door "the overall kernel architecture". Dan klopt de "truth" uit de 1-April RFC uit '96 nog steeds.

Elke partij die code maakt voor linux is zo'n partij, omdat Unix/Linux ouder is dan bijna elk bedrijf in de business, en ze waarschijnlijk allemaal gaat overleven.

Resultaten behaalt in het verleden....

Waar je vooral rekening mee moet houden, tot op zekere hoogte, is wat als.
AMD zit gewoon in zwaar weer dus het is zeer goed denkbaar dat er in de toekomst andere keuzes gemaakt gaan worden.

Zeker in dit soort princiepiele keuzes, kan je nu keuzes maken om problemen te voorkomen. Door het goed onderhoudbaar te houden is het op de lange termijn ook voor iedereen makkelijker om er aan te werken.

Snel en dirty bijt je later vrijwel altijd in de staart.

Ik snap het standpunt ook wel, van beide kanten.

In een wereld waarin veranderingen steeds sneller gaat moeten developers manieren verzinnen om sneller veel functionaliteit toe te voegen en te wijzigen. Alles supermooi in C proppen is dan een uitdaging en het is de vraag of dat nog wel van deze tijd is.

Aan de andere kant is het inderdaad een gevaar om zoveel aparte code in een bestaand project te proppen met een hele andere stijl.

Het lijkt me dat hier een beperking van de monolithische kernel zichtbaar wordt waarbij een grote diversiteit (door snelle vernieuwing van hardware, en veel verschillende merken) aan complexe hardware (GPU's bevatten inmiddels meer transistors dan CPU's) beperkingen oplevert. Een hybride kernel zou hier een oplossing aan kunnen bieden lijkt me.

In elk geval hoop ik dat ze nader tot elkaar kunnen komen en er een goede middenweg kan ontstaan want niemand is gebaat bij beperkte AMD drivers voor Linux. Nvidia heeft wellicht meer resources geinvesteerd in Linux drivers maar ook daar liggen de Linux drivers flink achter op die van Windows dus misschien kunnen ze samen met de Linux maintainers een goede oplossing vinden.

Heeft Linux dan niet een optie om dit soort drivers als kernel modules te laden? Zoals Windows tegenwoordig ook user mode drivers heeft? Waarom moet deze driver met alle geweld -in- de kernel, kan die niet gewoon daarbuiten blijven met in de kernel een "oh, het is een AMD vidkaart, hardware herkend, driver laden wordt uitgesteld" actie bij de bootup.

Is daar geen mechanisme voor?
* Aetje is een Linux noob

Nou ja, gemierenneuk, ik kan zelf als softwareontwikkelaar dat als er code van derden aan je project toegevoegd moeten worden, deze wel moeten passen in de structuur.
Anders wordt het in de toekomst bij bepaalde refactors totaal onhoudbaar.

Het is leuk dat AMD een hoop zooi geabstraheerd heeft om zo gemakkelijker hun code voor meerdere platforms te schrijven, maar dat moet niet ten koste van de code kwaliteit van de linux kernel gaan.

Dus ik snap het standpunt wel. De functionaliteit is secundair aan de algehele kwaliteit van de code. Dat bijt je anders enorm in de toekomst, en dat raakt meer vlakken dan enkel het AMD stukje.

Ik ben het helemaal met je eens. Uiteindelijk is het een openbare onderhandeling op de Linux Kernel mailinglist .Zoals die altijd/heel vaak plaatsvind.

Het kont vreemd over bij mensen die closed source software gebruiken, omdat dit soort onderhandelingen daar achter gesloten deuren plaatsvinden.

Eerlijk gezegd vind ik dit artikel niet echt nieuwswaardig.

Precies. De juiste abstractielaag is, vind ik, dat de code die je kan delen met andere besturingssystemen (of dus kernels) dan maar naar userland en in POSIX moet. Anders vraag ik me af of het wel geabstraheerd (met als doel kernelonafhankelijkheid) moet worden. En als POSIX ook te specifiek is, dan ontwikkel je het met glib of Qt.

Maar abstracties binnen één kernel vind ik wel prima. Bv. Liever één usbnet dan dat iedere router bouwer en concurrent twintig dingen op totaal verschillende manier maakt dat allemaal identiek hetzelfde doet.

Ik denk dat het open source is.
Het gaat meer om gemierenneuk.

Het gaat IMO over openbaar onderhandelen (open source) versus achter gesloten deuren onderhandelen (closed source).

Het is IMO zeker geen mieren geneuk.

Dat is dus eigenlijk juist het probleem, de driver is open-source, maar als hij opgenomen word dan is hij onderdeel van de kernel, die kan er dan niet zo maar weer even uit, en moet dus aan gesleuteld worden.

Ik denk dat Dave Airlie zich nu juist zorgen maakt dat die mensen die er aan gaan sleutelen, straks al de tijd die ze daarvoor hebben moeten gaan gebruiken om de AMD driver te onderhouden.

Als AMD hem zelf ging onderhouden zou dit niet zo uitmaken, omdat zij sowieso ook de Windows driver al moeten onderhouden is het voor hun juist handig als de drivers code delen, maar voor die mensen die echt enkel aan Linux werken is al die Windows-gerichte code juist meer werk.

Niet extact. Het drm-systeem is een snel evoluerend stuk code. Het moet namelijk voortdurend aangepast worden aan de noden van nieuwe hardware. Als het drm-systeem aangepast moet worden, moeten alle drivers aangepast worden. En dat is lastiger als die drivers abstractielagen gebruiken, want dan moet je om de abstractie in stand te houden, ook de abstractielaag aanpassen. Dat is de principiële discussie.

Het is puur principieel, maar zeker begrijpelijk, maar ook zorgelijk, omdat men bezig is AMD te ontmoedigen open source te blijven. Als die programmeurs continu afgebrand worden, en dat duurt nu al maanden, is op een bepaald moment de goede wil weg om met de kernelmensen samen te werken. Als men ze weg jaagt, zal AMD niet Linux de rug toe keren, maar zijn driverontwikkeling uit de kernel halen en teruggaan naar een propriëtaire driver.

In dat geval verliest iedereen en ik denk dat de spelers in de Linuxkernel zich goed moeten realiseren dat de Linuxgemeenschap in het verleden bijzonder veel energie in open drivers heeft gestoken, evenals het gebruiksvriendelijk installeren van propriëtaire drivers, zonder dat de eindgebruikerservaring perfect was. AMD levert nu de perfecte situatie, maar stank voor dank, belanden ze in principiële discussies.

Als het resultaat gaat zijn dat de code zo wordt als men wel, dan is het prima. Is het resultaat dat AMD het voor gezien houdt, dan verliest de hele Linuxgemeenschap.

Kan iemand mij vertellen waarom hardware fabrikanten er niet gewoon OpenGL en OpenCL drivers maken voor Linux?

Waarom zijn er kernel wijzigingen nodig? Voor Windows drivers zijn er toch ook geen kernel wijzigingen nodig?

Dat komt omdat de Linuxkernel ook alle drivers bevat en dus een nieuwe driver per definitie een kernelwijziging is. Je kunt drivers los van de kernel verspreiden (zoals Nvidia en voorheen AMD deed), alleen heb je dan te maken met dat de kernel een bewegend doelwit is: Stel dat er een nieuwe videokaart uitkomt waarvan de ondersteuning van een bepaalde functie niet reeds door de Direct Rendering Manager van de Linuxkernel mogelijk is. De DRM wordt dan aangepast, waarna alle drivers die in de kernel zitten ook een (vaak triviale) aanpassing krijgen. Drivers buiten de kernel compileren dan niet meer totdat ze door de leverancier geactualiseerd worden.

Deze aanpak van Linux heeft voor- en nadelen. Een belangrijk is dat de ondersteuning van hardware niet afhankelijk is van of de fabrikant zijn hardware nog ondersteunt. De drivers zitten immers in de kernel en worden onderhouden. De situatie die bij Windows bestaat dat als er een nieuwe Windows-versie uitkomt een hele hoop hardware niet meer met die nieuwe versie werkt is bij Linux vrijwel afwezig.

Een ander belangrijk voordeel is de installatieervaring: Voor computers waar voor alle hardware in de Linuxkernel drivers aanwezig zijn, is de gebruikerservaring buitengewoon goed. Linux op het apparaat installeren en gaan met de banaan, de fase drivers installeren is geheel afwezig en daarmee ook allerlei voor de eindgebruiker lastige situaties met betrekking tot dingen die daarbij mis kunnen gaan.

Het belangrijkste nadeel is, is dat fabrikanten die buiten de Linuxkernel om drivers leveren een driver hebben die rap veroudert en veel sneller onbruikbaar is, dan bij Windows het geval is.

AMD wil af van die situatie en wil naar een model toe waar zijn driver in de kernel zit, vanwege de goede gebruikservaring van drivers in de kernel. En, code in de kernel krijgen, drivers of iets anders, gaat vaak met felle discussies gepaard, juist omdat het niet alleen om het aanleveren van een lap code gaat, maar ook om het scheppen van een situatie dat de Linuxgemeenschap onderhoud aan de code kan doen, om de goede gebruikservaring voor onbepaalde tijd te kunnen verzekeren. Niemand heeft onbeperkte middelen, fabrikanten niet, de Linux-kernelprogrammeurs niet. Dus het gaat om het scheppen van een situatie waarbij alle betrokkenen op economische wijze kunnen werken.

Het lijkt mij dat een tussenoplossing in dit geval logischer is, waarbij er een aparte GPU kernel driver of API is (voor alle GPUs), die apart ge-update kan worden zodat de Linux kernel verder onafhankelijk blijft.

Het is niet verstandig dat hardware fabrikanten individueel de toekomst van Linux kunnen delegeren.

Mijn persoonlijke ervaring met Linux is dat de meeste GPUs niet volledig ondersteunt worden, vooral de high-end end maar ook minder standaard chipsets met onboard video. En voornamelijk high end AMD GPUs werden wel ietwat redelijk ondersteunt.

Het weren van AMD drivers kan dramatische gevolgen voor de toekomst van Linux met zich mee brengen.

Dat is ook mijn vrees: De betreffende kernelprogrammeurs doen alsof het ze niets kan schelen, regels zijn heilig, en stellen dat Linux ook wel zonder AMD overleeft. Hoewel dat op zich waar is, verliest als AMD ontmoedigd raakt code bij te dragen aan de kernel, de hele Linuxgemeenschap hierbij, die dan niet alleen AMD's driver kwijt is, maar ook zelf weer energie moet gaan steken in alternatieve drivers. En omdat de discussie meer om principes dan daadwerkelijke technische problemen gaat... is de vraag of men de eigen glazen niet ingooit.

Het resultaat kan ook nog zijn dat AMD de drivers als open source kernelmodule aan gaat bieden. In dat geval kan de community vrij plukken uit die code om de bestaande open source drivers te verbeteren. Iedereen blij.

Ik denk eerder dat AMD zal gaan zeggen: Dan niet...
Markt voor Linux op de desktop is ongeveer verwaarloosbaar, het statement dat ze geen mankracht hebben om de abstractions layer te verwijderen wijst erop dat er geen budget is, waarschijnlijk omdat ze er niets mee denken te gaan verdienen...

Markt voor Linux op de desktop is ongeveer verwaarloosbaar

Maar wel in een dikke stijgende lijn sinds SteamOS, ChromeOS, Android (op je telefoon, tablet, en straks ook PC), en al die Raspberry-achtige ARM mini-pc's.

Linux is nu al het meestgebruikte OS, en Linux op de desktop is volgens mij alleen maar een kwestie van tijd; over niet al te lange tijd heb je aan een ChromOS genoeg en gaat je OS alleen nog maar dienen om online te gaan.

Eerst en vooral Linux is geen OS, het is een kernel. Zeggen dat Linux een OS is is hetzelfde als zeggen dat OneCore een OS is: dat is het niet.

Ten tweede: "dikke stijgende lijn"? Van Steam OS en Chrome OS? Ik weet niet, maar ik heb nog geen enkele bedrijf zoals NetApplications en StatCounter 1 van die 2 als een apart OS buiten de "Other" categorie zijn voorstellen, Chrome OS komt er bij StatCounter op land-niveau hier en daar uit (niet meer dan 13 landen, laatst dat ik het checkte) en dan was de 2% al een kanjer van een uitsteker, Steam OS heb ik nog nooit ergens individueel genoemd zien worden en is dus absoluut niet noemenswaardig.

"Linux op de desktop is volgens mij alleen maar een kwestie van tijd", een argument dat we al sinds de jaren 90 horen en waar nog steeds niks van gekomen is. Over "niet al te lange tijd" alleen nog maar Chrome OS nodig hebben? Nee, niet eens een beetje. Natuurlijk zijn er nu al mensen die perfect met Chrome OS onder de voeten uit kunnen, maar het feit dat Google Android apps al naar Chrome OS heeft moeten brengen spreekt al boekdelen dat "alleen nog maar [...] online gaan" nog lang niet aan de orde is. Een ander goed voorbeeld dat dit tegenspreekt is Microsofts aankondiging om Win32 te ondersteunen op ARM: mensen hebben hun oude vertrouwde desktop apps nodig.

En dan, zelfs als we volledig alles online kunnen doen, dan nog is Chrome OS belangen na niet de enige die in deze markt kan strijden. Microsoft heeft bijvoorbeeld al enige tijd nu ook een simpel desktop OS in de vorm van Windows 10 Mobile's Continuum wat in tegenstelling tot Chrome OS een omgeving is waar nu al miljoenen mee vertrouwd zijn: het is tenslotte Windows (maar dan zonder legacy). En dan hebben we het nog niet over Apple die zo'n markt ook heus niet aan zijn neus voorbij zou laten gaan en alle andere bedrijven die geïnteresseerd zijn hierin.

Ik heb het gevoel dat je Chrome OS om de een of andere reden nogal heftig overschat.

Ja, da's een success gebleken? We horen nu al een kleine 20 jaar dat het volgend jaar toch echt gaat gebeuren.

We moeten maar eerst zien of desktop nog lang zal blijven bestaan... Als Linux niet doorbreekt dan zou het mij niets verbazen dat de huidige desktop wereld binnen 10 jaar instort ten gunste van andere computer platformen.

Als je de post van de AMD kerel leest denk je haast dat ze aan liefdadigheidswerk doen inderdaad. En als het dan geweigerd wordt is dat inderdaad zuur, daar mag je IMO ook wel even over klagen.

Ongewoon is dit niet in de Linux wereld. Er worden volgens mij haast wel dagelijks patches geweigerd en devs compleet de grond in gebrand als ze "vage code" schrijven of dingen refactoren op de verkeerde wijze. Natuurlijk allemaal aan de definities van de Linux wereld. Immers C is all you need, toch?

Aan de andere kant kan ik dat weigeren ook wel begrijpen. Als je alles merged dat 'seems to work', dan zijn de regression bugs waarschijnlijk al helemaal niet meer te overzienn op zo'n complex project

[Reactie gewijzigd door Hans1990 op 9 december 2016 20:21]

Linux moet eens beslissen wat ze willen. Deze obsessie voor het behouden de perfecte codebase is prima voor wat linux altijd is geweest: voor Developers en Servers, niet voor de mainstream en consumenten. Maar Linux wil beide zijn. Dat gaat niet met deze insteek.

Dat zou ik niet te hard roepen. Microsoft heeft periodes van 'problemen door niet perfecte code' alleen maar overleefd omdat het doorlopende inkomstenbronnen, veel vlees op de botten en veel personeel over had en zich dus rewrites kon veroorloven. Linux kan zich niet veroorloven om 6 jaar te doen over de stap naar een volgende major version en dan nog eens 2 jaar over de stap naar een werkbare minor version van die mislukte major version.

[Reactie gewijzigd door mae-t.net op 10 december 2016 03:06]

Hier haak ik even op in. De code hoeft niet perfect te zijn (dat gaat immers niet), maar moet wel makkelijk leesbaar en goed te onderhouden zijn. Dat is de code nu niet, dus dan is het erg jammer maar wel begrijpelijk.

Als AMD nu zelf mensen dit zou laten doen was het nog tot daar aan toe, maar dit is gewoon een code dump over de schutting zo van "veel plezier ermee he". Geen enkele maintainer word daar blij van, zeker niet als het om 100K regels code gaat.

Probeer het zelf maar eens. Schrijf maar eens een stuk code van 10.000 regels en doe er dan 2 jaar niks mee, en pak het dan maar weer eens op. Grote kans dat je dan toch even zit te zoeken van "hoe was het ook alweer??" en "waarom heb ik dit zo gedaan?" en meer van dat soort kreten. Probleem is dat er dan code geschreven is die interfaced met jouw geschreven code waardoor je niet even wat kan aanpassen zonder dat er ergens anders wat omvalt.

Maar goed, Linus Torvalds is niet de enige. Denk je dat ze alle code bij Microsoft na de 1e keer accepteren en integeren?

Precies, en als intel goede code kan leveren dan moet amd dat ook kunnen.

Nee, dus. Intels R&D afdeling is enkele magnituden groter dan AMD's. Maar AMD moet wel een vergelijkbare feature set leveren, anders is iedere vorm van bedrijfsvoering voor hen zinloos. Dus ze moeten hun R&D capaciteit 'slimmer' inzetten.
Op softwaregebied betekent dat dus dat je gaat abstraheren om grote brokken code gelijk te trekken tussen verschillende platformen, zodat je alleen die kleine stukjes die echt platform specifiek zijn opnieuw hoeft te schrijven.

Heb ik met de software die ik schreef ook wel gedaan... File IO (in C++) was zoveel mogelijk weggeabstraheerd zodat het niet uitmaakte of een platform alleen maar 'C-style' file read/write ondersteuning had (met bare-basic c++ runtime die net de woordjes 'class', 'new' en 'delete' kende), kon werken met IO streams, speciale regels had zoals bij Android (assets vs. files) of helemaal op z'n eigen manier met bestanden omging, zoals Palm OS. Ik had een class die met predefines platform afhankelijke code activeerde als het andere platform specifieke predefines tegen kwam (win32, palmos, posix, android) . Zo maakte ik vrijwel platformonafhankelijke code die door verschillende compilers op verschillende platformen gewoon werkt (zestal verschillende besturingssysteemfamilies, drie verschillende compilerfamilies). Valt in het niet bij de Linux kernel, maar het is wel een vergelijkbare situatie. Je hebt dan een '(H)AL' gemaakt, wat extra function calls toevoegt die tijdens executie op de stack komen (dus wat trager) en je hebt een (paar) extra class(es) die je moet onderhouden. En als je code aan je project toevoegt wat z'n eigen manier van werken heeft en je denkt later 'Laat ik eens alle File IO refactoren', dan kan je precies tegen datgene aanlopen waar Dave Airlie in dit verhaal niet aan wil.

Begrijpelijk vanuit de kant van de Linux maintainer(s), maar erg zuur voor AMD. Want dat betekent in feite het einde van up-to-date driver support voor Linux... of meer rode cijfers schrijven. Want dat is de afweging waar ze nu tegenaan kijken.

[Reactie gewijzigd door jiriw op 10 december 2016 01:06]

Die abstraction layers zijn dan ook wel nodig, maar blijkbaar moeten het er niet teveel worden. Immers, enerzijds heb je de gemeenschappelijke code die AMD blijft onderhouden, wat eenvoudiger wordt, anderzijnds zullen de abstraction layers ook onderhouden moeten worden. Blijkbaar is dat iets dat AMD dus wel doet voor Windows en OS-X maar wordt dat bij Linux gedaan door het vrijwilligersteam. Als dat er teveel worden, krijgen zij teveel voor hun kiezen.
Een goede keuze voor wat je wel en niet naar de abstraction layers verplaatst is dus essentieel. Wordt dit goed gedaan, dan is het uiteindelijk voor zowel de Linux maintainers als voor AMD voordeliger, maar het kan best betekenen dat er initieel meer code moet worden aangepast of herschreven

Nee, maar denk je dat AMD dit na de 1ste keer zelf heeft geaccepteerd? Denk je dat een stuk abstracte code als dit zomaar even om te schrijven is? Abstractie uit code werken is één van de meest tijdrovende vormen van refactoring. Bovendien moet alles helemaal opnieuw getest worden en opnieuw door de QA heen komen. Dat gaat veel te veel tijd en geld kosten voor wat AMD zich kan veroorloven. Dit is dus niet een kwestie van "niet de eerste keer accepteren". DIt is gewoon het compleet weigeren van de code op grond van onrealistische idealen.

Bovendien, als ik het goed had gelezen, werd er gesproken over dat AMD deze code zou onderhouden. Dan is dat dus hun probleem.

Er is een balans tussen "perfecte" code en en functionele code. AMD leunt misschien iets te veel naar de (voor hun) functionele kant, maar Linux leunt veel te ver naar de andere kant. Nogmaals: Dat is prima voor wat het nu is. Het is niet prima als ze willen concurreren in de desktop en gaming markt.

[Reactie gewijzigd door unilythe op 9 december 2016 21:19]

In het artikel staat

Het bedrijf staat daarom voor de keuze om alle abstractions te verwijderen, waarvoor het naar eigen zeggen echter geen mankracht heeft.

Als ze daar al geen mankracht voor hebben, hebben ze die dan wel om de code te onderhouden? Dat is een beetje scheef, want als er wel mankracht is om code te maintainen dan kun je die toch ook inzetten om e.e.a. te refactoren?

Nee, maar denk je dat AMD dit na de 1ste keer zelf heeft geaccepteerd? Denk je dat een stuk abstracte code als dit zomaar even om te schrijven is?

Hier zal inderdaad aardig wat tijd inzitten ja. Wat zonde is, want het is bekend hoe Linux modules eruit horen te zien, wat de coding standards zijn en hoe je je code zo makkelijk mogelijk (vanuit een onderhoudstechnisch standpunt) schrijft. Beetje jammer dat AMD daar niet even naar gekeken heeft en zo te zien een bak met tijd en geld heeft weggesmeten, vind je ook niet?

Als ze daar al geen mankracht voor hebben, hebben ze die dan wel om de code te onderhouden?

AMD heeft daar op verschillende plaatsen een antwoord op gegeven. AMD heeft een "validatieteam". Dat team schrijft code om chips, nadat ze uit de fabriek komen, te doen "oplichten", voor het eerst beeld geven, waarna functionaliteit van de chip getest wordt. Het is een stap voor het schrijven van drivers voor verschillende besturingssystemen.

Veel van de code in de huidige driver is geschreven en wordt onderhouden door dat validatieteam. Daardoor onstaat synergie en is het in economische zin mogelijk worden om de volledige functionaliteit van de GPU onder Linux beschikbaar te maken.

Op het moment dat de code niet meer gedeeld kan worden met het validatieteam, zou een veel groter Linuxdriverteam nodig zijn om de Linuxdriver te onderhouden en te testen. Daar zegt AMD de middelen niet voor te hebben.

Daarmee heeft niet alleen het kernelteam regels waarbinnen ze moeten blijven, maar ook AMD heeft binnen regels te blijven en dat is, dat wat er ook gebeurd, de code bruikbaar blijft voor het validatieteam.

Binnen de randvoorwaarden van beide teams zal geprobeerd moeten worden een oplossing te vinden, zo niet zie ik het somber in voor de toekomst van de openbrondrivers, want AMD zal dan waarschijnlijk weer een driver los van de kernel gaan leveren, waarbij het risico bestaat dat ze de broncode daarvan niet beschikbaar maken.

Ik denk dat je mijn punt mist. Jouw focus ligt op AMD, die van mij niet. Nergens heb ik gezegd dat AMD hier slim bezig was. Ik had het over dat Linux' ideologie niet werkt als ze willen concurreren in de desktop en gaming markt. Dat heeft op zich niets met AMD te maken behalve dat dit verhaal dat probleem alleen maar weer even verduidelijkt.

[Reactie gewijzigd door unilythe op 9 december 2016 21:45]

Dat is het punt nu net. Linux developers vinden gamen en desktops niet het belangrijkste, want dat is het voor hun ook niet. Linux word meer desktop-geörienteerd ja, maar het is voornamelijk nog steeds een server OS.

Waarom leunt Linux te ver? Iedereen kan perfect de tree van Linus forken en die AMD code incorporeren in wat ze uitbrengen. Dat wordt ook veelvuldig gedaan. Wat er in de toppers hun tree komt is wat naar boven gebubbeld is. Dus dat is vaak heel goed en heel hoge kwaliteit. Ja.

Houden zo.

Bekijk het als de wet van de sterkste code. Darwinistische evolutie. En als AMD toch gelijk had, dan zal die code waarover ze gelijk hadden uiteindelijk wel naar boven bubbelen.

Ook houden zo.

Maar zie het ook even vanaf de kant van Linux, ze komen als ik het goed heb met de code aanzetten als deze af is, ze hadden ook even een duidelijk plan met Linux kunnen maken.

Ook als iedereen dit zo zou doen, dan zou Linux in mijn ogen onstabiel kunnen worden. Linux is juist zo goed omdat het snel en vooral stabiel werkt.

Maar dat neemt uiteraard niet weg dat het erg zuur voor AMD is.

Stuur vooral even een reactie als iets in mijn reactie niet klopt.

Nee, wat je zegt klopt helemaal. Het is zuur voor AMD, maar Linux' kant is zeker te begrijpen. Mijn punt was dat Linux niet weet wat het wil. Het is onrealistisch om zo te werken en dan ook te hopen dat je kan concurreren in de desktop en gaming markt.

Denk je dat ze alle code bij Microsoft na de 1e keer accepteren en integeren?

Bij Microsoft hoef je alleen maar een binaire driver blob over de muur te gooien, samen met een zak geld en klaar. Als die blob door een paar rudimentaire testen komt - zelfs zonder de betreffende hardware - is 't al goed en kun je er alle PCs mee gaan infecteren.

Je gaat mij niet vertellen dat ze 100k regels hebben geschreven zonder halverwege even contact te zoeken met de maintainer. Dit moeten ze aan hebben zien komen, maar door het er zo op neer te laten komen krijgt linux een bak negatieve publiciteit over zich heen, waarschijnlijk om het publiek druk te laten zetten om het alsnog op deze suboptimale manier te implementeren.

Maak je niet druk, die kritiek deert de kernel devs al lang niet meer. Hun leuze is al jaren heel duidelijk en eenvoudig: code speaks louder than words.

Als AMD hun driver er in wil: aanpassen dan. En anders kunnen ze hun eigen tree maintainen. Het is git he. Dat gaat allemaal prima tegenwoordig.

Maar kan het niet alsnog gewoon via een externe driver aan Linux toegevoegd worden, ookal zit het dan nu niet in der Kernel? Dan zou de (desktop) eindgebruiker er weinig van hoeven merken, en is het alleen de out-of-the-box en voor OEM's wat lastiger

GPUs worden middels OpenCLveel voor parallele rekentaken ingezet en laat daarvan nou een groot deel op Linux servers draaien. Verder zit het er ook aan te komen dan Linux als console OS (Steam) gebruikt gaat worden.

[Reactie gewijzigd door unglaublich op 9 december 2016 19:54]

In de Top 500 lijst met supercomputers staat één computer met AMD GPUs, op de 288e plaats.
Er staan er 65 in met Nvidia GPUs...

En dus is er voor AMD juist wel wat te winnen.

Verwaarloosbaar?
Tv-settop boxen, media spelers, tablets, telefoons en zelfs Android is gebaseerd op Linux.
En dan noem ik nu alleen nog maar de dingen waarin een CPU/GPU in nodig is.

Zoals ik al schreef: Verwaarloosbaar op de desktop...?
Hoeveel van de dingen die jij noemt zijn een PC met een AMD GPU en niet een ARM SoC?

Servers en workstations maken ook gebruik van AMD kaarten;

En zelf met een kleiner marktaandeel moeten ze die ondersteunen, anders hebben ze geen marktaandeel meer en zullen ze er ook niet in slagen dit te vergroten.

Also, wat niet is, kan nog komen. AMD plant (hopelijk) wat verder vooruit dan 'volgende week'

[Reactie gewijzigd door graverobber2 op 9 december 2016 20:47]

En hoeveel daarvan is compatibel met elkaar? Ergens in Android zit inderdaad Linux, maar daar stopt het ook wel me.

Uhm. Iets wat is de kernel wordt opgenomen is in ieder geval open source.

Als je wil duiken in de 100k regels, staat dat je compleet vrij.

waarna vervolgens nvidia alles schaamteloos over kan nemen? tenminste mijn gok is dat dat ze ervan weerhoud om het opensource te maken

edit: de kernel is sowieso opensource dus alle toevoegingen ook.

[Reactie gewijzigd door coolkil op 9 december 2016 19:37]

En de AMD Linux drivers zijn ook gewoon open source, net zoals die van Intel. Alleen nVidia blijft met gesloten drivers werken.

Er was ook altijd een closed source driver. Kan alleen zijn dat ze daar van af gestapt zijn.

nVidia heeft niets aan drivers voor AMD, tenminste niet om over te nemen. Hooguit zouden ze er details over het ontwerp van de chips uit kunnen afleiden, maar dan geldt nog steeds het auteursrecht dat ook al beletsel is om ze integraal over te nemen als dat al nut gehad zou hebben.

Zal wel meevallen. Zal wellicht wel wat tussen zitten wat interessant is, maar een hoop zal in de hardware zitten en de rest is vast wel bekend.

Het is ook niet bepaald dat ze de code niet kunnen reverse engineeren als het gesloten is. Ja, dat kost tijd en moeite, maar is voor een club als nvidia vele malen makkelijker kapitaal technisch gezien dan voor een startup oid.

Als Linux zo graag AMD support en drivers wil hebben, zou ik als ik hun was niet zo piepen. Wees blij dat AMD nog trekt aan zo'n dood paard, iig voor de thuisgebruikers.

Precies, AMD kan nu de middelvinger geven en FreeBSD of Windows (of een PS4 / XBox 360) aanraden.

AMD is verre van verplicht om met een Linux driver te komen. Mensen kunnen wel zeiken dat AMD niet de "Linux"-community wil helpen. Maar als de houding van AMD's hulp is. Die Dave Airlie moet maar bewijzen dat hij het beter kan.

Het gaat hier niet om het feit dat AMD code aanlevert, dat waarderen we. Het gaat om de kwaliteit van die code. Als de code die er nu ligt 1:1 opgenomen word in upstream word het over twee of drie jaar extreem lastig te onderhouden, zeker omdat niemand van AMD zelf dit gaat doen. AMD dumpt dit, in dit geval, lekker bij de Linux ontwikkelaars met de boodschap "hier heb je het, zoek het zelf maar uit".

Dan snap ik Dave wel, als je 100K regels code voor je neus krijgt waarvan er een groot aantal alleen is om Windows aan te sturen, zou ik het ook afwijzen.

Wel pluspunten voor AMD. Nvidia levert alleen binary blobs aan, en alleen door reverse egineering hebben we nouveau.

Het gaat ook niet zozeer om de kwaliteit van de driver, maar om de opbouw, en hoe hij in de DRM core gehangen is: met een hardware abstraction layer (HAL).

Code doesn't trump all, I'd have merged DAL if it did. Maintainability trumps all. The kernel will be around for a long time more, I'd like it to still be something we can make changes to as expectations change.

- Dave Airlie ^[source]

Zoals AMD's John Bridgman uitlegt^[source]:

A lot of the confusion here is that DC has two meanings - it's the big chunk of developer effort & code we want to re-use across platforms for all kinds of good reasons, and it is also a very specific abstraction layer inside that code. It's the second meaning that Dave and Daniel have concerns about, because it internalizes things that they feel should be part of the driver rather than part of what is effectively a blob (despite being publicly developed open source) to them. We understand that.
Again, this was primarily a miscommunication, so other than making for some good reading it doesn't mean much.

Hoe ik het begrijp:
Het eerste deel is de low-level code die met de hardware "praat" en daarmee ook functionaliteit als reclocking, Freesync, DisplayPort, HDMI audio etc mogelijk maakt. Dit deel wil AMD delen tussen de verschillende platformen (besturingssystemen) die ze ondersteunen. Het is dus niet zo dat van al die regels code "een groot aantal alleen is om Windows aan te sturen".
Het tweede deel, de HAL, zorgt voor de integratie met het besturingssysteem en is daarmee platform afhankelijk.

Deze aanpak lijkt me vanwege het delen van goed geteste code met andere platformen erg handig voor AMD en daarmee ook voor gebruikers, maar die HAL voldoet niet aan de strenge richtlijnen om DC in de kernel ge-mainlined te krijgen. Zie details over waarom deze aanpak problematisch wordt gevonden hier.

De eerste patch series, die februari dit jaar was vrijgegeven, voegde zo'n 93k lines of code toe aan de Linux kernel^[source]. Echter zijn er sindsdien veel wijzigingen doorgevoerd die de code base kleiner heeft gemaakt, maar hoeveel weet ik niet. Dit komt overigens dus ook de Windows driver ten goede.

Edit: Maar inderdaad, veel kudos voor AMD voor deze open source aanpak. Als alles rond is geeft dat een geweldige out of the box ervaring voor hun hardware.

[Reactie gewijzigd door Just3 op 10 december 2016 11:26]

Ah, nu wordt het verhaal duidelijker.

Van de andere kant, wat let AMD om de code in een aparte kernel module te stoppen in plaats van in de kernel zelf? Met uitzondering van de performance lijkt me dat een voorlopige win-win situatie

Van de andere kant, wat let AMD om de code in een aparte kernel module te stoppen in plaats van in de kernel zelf?

Niks, maar dan zijn de mensen met een AMD GPU en een UEFI de pisang, dan weigert je UEFI namelijk je OS te booten omdat de handtekening niet meer overeen komt. Dat heb je nu ook met Nvidia binary drivers in combinatie met Fedora. Tenminste, dat was voor mij het probleem. Secure boot uit en klaar, maar toch.

Als AMD de juiste licentie kiest voor hun driver dan kan een distributie prima een kernel samenstellen met AMD's code en EUFI juist regelen. Daar moet AMD's code niet voor in de main tree van Linus.

Er is en was genoeg kernel code die een Fedora shipped die niet in de main tree van Linus zit en zat.

Alles kan, maar niet alles is praktisch. Het is niet dat de Linuxgemeenschap oneindige middelen heeft, ook al lijkt dat soms zo. Als Linuxdistributeurs allemaal zelf drivers in kernels moeten gaan stoppen, dan is dat een enorm dubbel werk dat op tal van plaatsen plaatsvindt. Energie die niet aan andere zaken besteed kan worden.

Linuxdistributeurs hebben veel tijd gespendeerd aan drivers en doen dat nog steeds. Maar dat is omdat het moet, niet omdat het ideaal is. Ideaal is een kernel waarmee alle hardware werkt.

Ideaal is een goede kernel die goed geschreven is en zo weinig mogelijk of zelfs geen bugs heeft. Het moet niet zo lang duren als die HURD kernel. Maar als dat wat langer duurt, dan is dat maar zo.

Grotendeels eens dat het goed is dat zo veel mogelijk hardware functioneel is. Maar bepaalde hardware is zo slecht ontworpen dat je soms gewoon geen ondersteuning wil. Moet je bv. Matthew Garrett's blog maar eens over doornemen. Om de zoveel dagen hilarische verhalen over super super slechte hardware.

Vooral omdat je als gebruiker van een kernel verwacht dat die kernel de hardware dan ook maar meteen activeert.

Het gaat niet om de licentie, het gaat om een MD5/crc32 checksum die in je UEFI moet staan, die overeen moet komen met de checksum van je kernel. Zodra je een andere module (nvidia, amd, intel netwerk drivers sommige) toevoegt is je kernel 'tainted' en klopt de checksum niet meer, wat resulteeert in je UEFI die weigert te booten, want andere checksum.

Dat is niet meer zo onder Fedora. Nvidia drivers zijn netjes gesigned.

Oh? Ik heb hier (F25, nvidia drivers 375.xx) toch écht mijn secure boot uit moeten zetten omdat het systeem anders weigerde te booten.

Let wel op dat ik het over de binary driver van de nvidia site zelf heb he, niet over de nouveau driver die onderdeel is van de kernel.

Anyway: heb je ergens een linkje of een howto hiervoor?

Je kunt beter nooit de driver van de nvidia site nemen. Dat geeft niets dan problemen, zeker bij upgrades.

Wat ik zelf gebruik is de akmod nvidia. Vergeet niet het stukje over 32-bit mee te nemen.
https://rpmfusion.org/Howto/nVidia

Voordeel van deze methode is dat je deze ook automatisch meegaat bij een kernel upgrade. En Secure boot hoeft niet uit.

Je kunt beter nooit de driver van de nvidia site nemen. Dat geeft niets dan problemen, zeker bij upgrades.

Dat valt wel mee. Ik heb nu alle upgrades vanaf F25 meegenomen en nog niet één keer een kapotte installatie gehad. Dat de nvidia driver dingen breekt tijdens upgrade was vroeger inderdaad zo, maar nu niet meer, zeker niet met DKMS support (waar door de driver naar gevraagd word).

Ook is de RPMFusion variant niks meer dan een repack van de binary driver van nvidia zelf.

Voordeel van deze methode is dat je deze ook automatisch meegaat bij een kernel upgrade.

Dat doet de nvidia driver dus ook (zie stukje boven, over DKMS).

En Secure boot hoeft niet uit.

Dat is dan het enige voordeel. Echter booten Windows en Fedora ook gewoon zonder secure boot

Ik heb andere ervaringen met kapotte installaties met de binary driver. Helemaal met conflicten met de nouveau driver. Echt kapot is die installatie natuurlijk niet, het is vooral zwaar irritant.

akmod of kmod werkt allemaal wat slimmer. Net zoals het gebruik van Secure boot ook wat slimmer is.

Je moet natuurlijk wel de nouveau driver disablen, maar dat moet je overal, ook als je de akmod/kmod installeert.

En wat werkt er slimmer nu met de akmod/kmod? Beide doen hetzelfde: dkms aanroepen, dat doet de binary driver nu ook.

Secure boot aan of uit zou ik niet onder "slim/niet slim" willen gooien, dat is een keuze. Behalve als je duizenden apparaten support voor netzoveel mensen, dan is het fijn als je het aan kan laten staan.

Nee, dat is juist het fijne. Met akmod hoef je de nouveau driver niet te disablen. Geen secure boot is een no go voor mij. Omdat het te ingewikkeld wordt zet je het maar uit. Dat is geen goede reden.

Dat komt omdat de akmod zelf /etc/modprobe.d/blacklist.conf toevoegt met als content "blacklist nouveau" ;-) Met andere woorden, dat doet de driver/package dus voor je.

Geen secure boot is een no go voor mij. Omdat het te ingewikkeld wordt zet je het maar uit.

Ik disable het niet omdat het te ingewikkeld word, ik disable het omdat ik geen zin heb om mijn eigen kernel te signen, de PEM files (e.a) op een FAT32 partitie of stickje te zetten, mijn UEFI te starten en de PEM files bij te voegen aan degene die de OEM meegeleverd heeft. Eén keer, ok. Met elke kernel update? Hell no.

Waarom moet secure boot perse aanstaan? Bij mij is de situatie gok ik anders, ik ben de enige hier die achter/aan deze machine komt.

(En ook dat de rpmfusion driver nog niet mijn GPU corrrect ondersteund helpt ook niet mee... )

Secure boot, SELinux, etc is tegenwoordig dik aan te raden met alle risico's die je nu eenmaal hebt met internet.

En je beschrijft precies goed waarom je Secure boot nu uitzet: die hele riedel steeds opnieuw moeten doen is gewoon te ingewikkeld om iedere keer uit te moeten voeren. Daar heb je met akmod geen last van. Waarom moeilijk doen als het niet hoeft? Maar je geeft aan dat jou GPU niet werkt, dan is het natuurlijk een ander verhaal.

Secure boot, SELinux, etc is tegenwoordig dik aan te raden met alle risico's die je nu eenmaal hebt met internet.

Voordeel is dat SELinux gewoon werkt of je nu wel of niet de nvidia driver of de (a)kmod hebt draaien.

Daar heb je met akmod geen last van. Waarom moeilijk doen als het niet hoeft? Maar je geeft aan dat jou GPU niet werkt, dan is het natuurlijk een ander verhaal.

Inmiddels werkt de akmod ook met mijn GPU, alleen moet je wel de eerste keer bij het inloggen je keuze op GNOME on X.org zetten inplaats van laten staan waar hij op staat (GNOME, met Wayland). Dat is denk ik nog een bug, want Wayland werkt helemaal niet samen met nvidia drivers (nog). Dat was dus ook te merken toen ik geen effecten en geen venster UI's had....

Dat is flauw, ze dumpen het niet. Ook de maintainer verwacht niet dat AMD zich hierna terugtrekt.

Trekt aan een dood paard? Linux is verre van dood, op het gaming aspect na dan. Linux is volgens mij dé standaard oplossing voor in ieder geval NAS systemen, webservers, Raspberry Pi achtige computers etc.

Misschien is het voor de thuisgebruikers niet het meest gekozen systeem, maar 2,5% markt aandeel is wereld wereldwijd gezien nog steeds het ondersteunen waard, vooral omdat tussen dat aandeel veel power users zitten die je te vriend wilt houden

[Reactie gewijzigd door maartenvdezz op 9 december 2016 20:42]

De Steam Machine draait op SteamOS welke Linux based is. Dus zelfs qua gaming gebeurt er heel veel.

Dat is kip en ei. Wanneer er genoeg van verkocht worden gaan er steeds meer game developers over naar Linux.

En dat worden er steeds meer. Het is niet voor niets dat Windows 10 nu ook een Linux bash heeft gekregen: voor al die Linux developers.

Dat is kip en ei. Wanneer er genoeg van verkocht worden gaan er steeds meer game developers over naar Linux. En dat worden er steeds meer.

Iedere 3rd party die een Steam Machine heeft zegt dat ze niet verkopen. Nagenoeg allemaal zeggen ze dat ze er al mee gestopt zijn of binnenkort gaan stoppen.

Het is niet voor niets dat Windows 10 nu ook een Linux bash heeft gekregen: voor al die Linux developers.

Dat staat er volledig los van. Bash heeft überhaupt niets met gaming te maken en games hebben niets te maken met het besluit om Bash toe te voegen. Ik zeg ook nergens dat Linux geen goed idee is (ik heb privé 2 Linux servers en 4 desktops draaien). Ik zeg wel dat Steam Machine een doodgeboren kind is en het er niet naar uit ziet dat dat op korte, of zelfs lange, termijn gaat veranderen.

Je overdrijft. Steam Machines met Linux verkopen nog steeds prima.
Het is wel zo dat de komst van Windows 10 ze het niet gemakkelijker heeft gemaakt.

Wees blij dat ze er zijn: meer concurrentie = lagere prijs.

http://www.pcgamer.com/al...ws-10-changed-everything/

En Linux bash is gemaakt voor developers, niet voor consumenten.

[Reactie gewijzigd door CR2032 op 10 december 2016 13:13]

25% van alle games die Steam aanbiedt draait (ook) op hun SteamOS (en andere Linux varianten). Dat percentage zal nog wel flink omhoog moeten, wil gaming op Linux echt een succes gaan worden. Mac zit overigens op 36%.

Pro: Steeds meer game-engines hebben prima support. Porten gaat steeds professioneler, sneller en makkelijker. Vulkan gaat flink wat kunnen opschudden. Andere aanbieders zoals GOG zijn ook in Linux gaming gestapt.

Con: het gaat nog steeds erg langzaam. Steam machines zijn inderdaad geen succes geworden (matige specs, weinig keuze en veel te duur).

Leuk, maar die steam machine is wel afhankelijk van drivers.
En HDMI 2.0 support lijkt me daarbij wel essentieel.

Ik denk inderdaad dat @Visgek82 niet goed doorheeft hoeveel meer miljard computers er Linux draaien dan MacOS X and Windows samen. Namelijk om te beginnen al alle Android toestellen. Boem. Dat alleen al is meteen meer dan alle Windows en MacOS X installaties samen.

Reken daarbij wat er nu in ontwikkeling is. Als zelf embedded ontwikkelaar word ik de laatste tijd overstelpt met de vraag naar Linux ontwikkelaars. Het is eigenlijk niet meer normaal.

Ik denk dat jij dan niet goed door hebt dat die miljard computers allemaal eigenlijk servers zijn zonder GUI en waar er dus minimaal of geen GPU nodig is. Dus vanuit dat aspect heeft de AMD code nul komma nul toegevoegde waarde.

Fout. Android is ook Linux. Android laptops zijn er al en op alle moderne Chromebooks gaat Android ook op werken.

Als je er op let kom je overal Linux tegen, het heet alleen vaak anders. Bijvoorbeeld Chrome OS, Steam OS, Android TV, Tizen (Samsung), openELEC, OSMC.

Naast de echte Linux desktops, zoals Ubuntu, Fedora waar je ook op kunt gamen met Steam. AMD ondersteuning is relevant.

Je vergeet dat er ook servers zijn die GPUs voor simulaties en deep learning gebruiken. Nu heeft NVidia daar de monopolie op, omdat programma's betere CUDA ondersteuning hebben dan OpenCL. Dat komt weer omdat AMD drivers zo bagger zijn en daardoor NVidia OpenCL links kan laten liggen.

Wij draaien bij Heidenhain zo een embedded omgeving op CNC machines waar een GPU voor nodig is. Dat is voor CNC machines en het OS wordt in de industrietak Heros5 genoemd. Dat is een RT Linux. Vanzelfsprekend ben ik gebonden aan enige geheimhouding, maar ik denk wel dat ik kan vertellen en a.d.h.v. de publieke website van Heidenhain kan tonen dat een GPU nodig is (dat fotootje is uiteraard de huidige UI, dus het was de laatste 10 jaar al nodig).

Als je nog voorbeelden nodig hebt kan ik er nog wel wat geven. Na zo'n 15 jaar ervaring als Linux ontwikkelaar heb ik wel een lijstje klaar voor je. Het zal je meer dan verbazen moest je echt denken dat Linux enkel maar op servers draait. Dat is zelfs een mini marktje in vergelijking van embedded. De meeste dingen die jij niet erkent als een computer, maar die het eigenlijk wel zijn, draaien Linux.

En die embedded devices draaien het liefst een zeer oude zeer lekke linux. De 2.2 branch bijvoorbeeld, het feit dat ik dat soms nog tegen kom op devices die NU nog in gebruik zijn en aan een actieve internet verbinding hangen.... Spijtig.

Nou geldt wel dat de meeste embedded devices toch echt geen baat hadden gehad bij deze code, of dat ooit zouden hebben.

Ik ben het volledig eens met je, en ik ben één van die opensource maintainers die zich naar de bedrijven begeeft om hen te helpen naar modern-Linux over te gaan.

Dat wil zeggen KIO, udev, moderne kernels, packages gebruiken, semver toepassen, systemd (jawel, ja, haat me maar), nieuwere versies van Qt, en van GLib, en zo verder. M.a.w. gebruik upstream en probeer het wiel niet zelf uit te vinden. Maar werk samen met hen.

Precies voor jouw opmerking dat ze geen baat hebben gehad aan nieuwere versies, adviseer ik bedrijven met regelmaat om géén eigen package formaat te bedenken maar gewoon met DEB of RPM te werken. Wanneer ze dat doen, voor hun hele platform, dan genieten ze automatisch van allerlei updates.

Dat is moeilijk. Bedrijven en vooral mensen, vooral die rare dieren die mensen noemen, vooral die, denken het altijd beter te weten. Dat is niet zo. Die beesten weten het vrijwel nooit beter. Vooral niet diegene die alles zelf opnieuw willen uitvinden. Vooral die beesten niet.

Maar we doen ons best.

Over gaming op linux: Als je bedenkt dat Android op Linux gebaseerd is, wordt er best wel vet veel gegamed op linux (mobiele telefoons).

Sowieso sinds steam OS is valve er mee aan de gang gegaan en draaien er best een degelijk aantal Games native op. Ik verkies nog steeds Windows vanwege het relatief lage compatibiliteitsproblemen maar het is niet vreselijk gesteld of zo.

Unix =/= linux

Niet zo'n interessant statement, gezien Android op Linux is gebaseerd.

En linux weer op minix en minix weer op unix.

The *nix family !

(mijn favorite family)

Ik denk dat open bron het op gegeven moment wel gaat winnen omdat je werkelijk 'doodziek' wordt van de veranderingen (om het veranderen) of vendor lock-ins, je kan er niets anders mee - dan aangewezen ( is geïnstalleerd ). Als bedrijf wil je continuïteit, als bedrijf wil je functionaliteit en de noodzaak om te veranderen begint erg vervelende vormen aan te nemen, het gaat in de weg staan mede omdat er nu wel zo'n beetje alles al is (uitontwikkeld). Om dan alleen te moeten veranderen vanwege commerciële behoeften/continuïteit van de fabrikant, om de trein maar op de rit te houden, is voor de continuïteit van een bedrijf, wat gebruikt van maakt van producten van desbetreffende fabrikant, niet echt handig. Het geeft duidelijk aan dat het verdienmodel op zijn einde is, we hebben te maken met verzadiging en daardoor zie je de meest vreemde bokkensprongen om de markt gaande te houden. Basisinkomen invoeren en alles in dienst van de mens ipv het geld, dat is de onvermijdelijke volgende stap die genomen moet worden om technologie in alle facetten zinvol te kunnen blijven inzetten en beheersbaar/betaalbaar te houden. Geen commerciële meuk waar niemand op zit te wachten.

Ah, een -1. Proost Tweakerspeople. Begin steeds meer hekel te krijgen aan het publiek hier. Laterz! Weet je wat, ik kijk zo af en toe en zeg niets meer, deal?

[Reactie gewijzigd door codebeat op 10 december 2016 11:04]

Je noemt een heleboel toepassingen voor linux waar AMD helemaal niks te maken mee heeft.

Het gaat hier over desktop support. Punt is dat hardware acceleratie het onder windows bijna altijd heel makkelijk doet. Linux? Als je gelukt hebt ja.

En dus hebben linux desktop gebruikers veel meer problemen met het zien van HD video in de browser dan windows gasten. En dat moet nu maar eens een keer verleden tijd zijn!

Momenteel bied AMD veel betere support voor Linux dan Intel en Nvidia. En nu krijgen ze daar crap voor van een linux ontwikkelaar?

Het is algemeen bekend dat Nvidia veel betere support heeft voor Linux dan AMD.
Zoek maar eens op hardware aanbevelingen voor een Linux systeem.

Momenteel bied AMD veel betere support voor Linux dan Intel en Nvidia. En nu krijgen ze daar crap voor van een linux ontwikkelaar?

Waar haal je dat vandaan?

De AMD drivers zijn opnieuw enorm brak. De ondersteuning voor moderne kaarten (zeg maar vanaf de HD200 series) is überhaupt niet aanwezig, wat enorm raar is aangezien dat gewoon rebrands zijn van oudere kaarten.

En waarom krijgen ze crap? Omdat ze crap leveren. Als code niet aan de kwaliteits standaarden voldoet dan moet je het niet integreren. Doe je dat wel dan krijg je X. Een systeem wat niet meer aan te passen is omdat de codebase te brak is. En brakke code is niet te onderhouden. Simpel as that.

Punt is dat hardware acceleratie het onder windows bijna altijd heel makkelijk doet. Linux? Als je gelukt hebt ja.

10 jaar geleden misschien.. Ik heb recent een gloedjenieuwe bak gekocht, met daarin een i7 6800K, 1 SSD en 4 x 1TB HDD (voor mijn documenten e.g. /home) en een gtx 1060 6GB. Hiervan werd álles, let wel, alles direct ondersteund door Fedora. De videokaart niet optimaal, maar genoeg om de nvidia driver te installeren (wat ook logisch is, super nieuwe GPU).

Afijn, ook Windows 10 geïnstalleerd. Die had drivers nodig voor:
- De CPU (Ja, echt )
- De GPU
- De netwerkkaarten
- De audiokaart
- Bluetooth adapter

Met Fedora was ik, al met al, 20 minuten bezig. Windows? Een uurtje of 3..

"Op het gaming aspect na", ja. En dat blijft ook dood als de maintainers op deze wijze menen te moeten handelen... Ik vond het al uitermate indrukwekkend dat AMD zoveel werk wil doen voor een groep die een marktaandeel (op Steam) heeft van 0.88% of zoiets (en waarvan minstens de helft NVidia kaarten heeft). Je kunt je afvragen of ze die moeite uberhaupt nog wel willen blijven doen als er zo op gereageerd wordt.

Valve zal ook niet blij zijn: na alle investeringen die ze in Linux gedaan hebben vertellen de maintainers ze hier dat 'gaming' gewoon geen prioriteit is en dat een van hun belangrijkste partners lekker in hun drivers kan stikken.

Dom - dat is het enige wat ik ervan kan zeggen. Linux op de desktop is zojuist weer tien jaar achteruit gezet.

Dude... really.....

De maintainers zeggen helemaal niet dat gaming geen prioriteit is. De maintainers zeggen dat maintainability (je weet wel, hun hoogste prioriteit, de reden van hun bestaan) belangrijker is dan gaming.
Net zo goed als dat ze zeggen dat maintainability belangrijker is dan storage, networking, webservers, fileservers, en alles.

Wanneer je brakke code toe laat zeg je in feite dat de toekomst van je systeem je niet interesseert. Dat is leuk voor een iPod maar niet voor het OS waar zo'n beetje alle servers die het internet in de lucht houden op draaien.

Brakke code opnemen in de Linux kernel kan problemen opleveren in veel meer gebieden dan enkel in het onderdeel wat het toevoegt.

Een software project van die omvang is enkel houdbaar door het handhaven van strikte kwaliteitseisen.

Als deze code toegevoegd wordt met al die abstractielagen, dan kan het zo zijn dat als er bijvoorbeeld over een half jaar een refactor plaatsvind in de algehele GPU ondersteuning, dat dit maar mondjesmaat gedaan kan worden omdat de structuur van de AMD code het herschrijven hindert.
Dat kan er dus weer voor zorgen dat door de structuur van de AMD code, de gedeeltes van bijv. Nvidia en Intel niet optimaal kunnen draaien omdat de refactor niet volgens wens doorgevoerd kan worden.

Ach als men zo tegen hardware abstractie layers is laten dan gelijk maar alle hal's die voor de cpu ondersteuning zorgen eruit halen en voor elke gen/serie cpu's software gaan compilen.

Daarnaast zal deze code als het goed is enkel worden aangesproken als er een amd gpu aanwezig is. Als er dus een refactor plaats vind dan kan men gewoon die code eruit halen en tegen amd zeggen doe je werk maar opnieuw mocht het niet meer werken. Maar voor het moment zou het een hele grote stap vooruit zijn.

Als men op de desktop een groter marktaandel wilt met linux dan moet men gebruik maken can dit soort code en later maar bedenken hoe het te onderhouden of weer te verwijderen.

Als ze het later toch weer moeten veranderen kunnen ze het net zo goed in één keer goed doen. Het is jammer dat nu al deze code in de prullenbak kan en opnieuw mag gebeuren, en dat daarom ondersteuning voor dingen als FreeSync nog even moeten wachten. Daar staat tegenover dat AMD er later minder werk aan zal hebben en dat komt dus de kernel en AMD als bedrijf ten goede.

Dat de code 'toch niet gebruikt wordt als er geen AMD GPU aanwezig is' is waar, maar dan zou je net zo goed gewoon onzin kunnen coden in de kernel die 'misschien ooit eens nuttig zou kunnen zijn'.

Het marktaandeel van Linux hangt ook niet af van dit soort features; je kunt prima gamen zonder FreeSync. Dat soort dingen zijn extra's.
(terzijde, IMO ligt het grootste probleem in het marktaandeel in de keuze die gebruikers moeten maken, bijvoorbeeld welke distro ga ik gebruiken? welke DE? oh maar ik kan dan niet meer mijn favoriete game spelen die alleen voor Windows is uitgebracht...)

Drivers waren en zijn één van de belangrijkste redenen waarom gebruikers afhaken van Linux: Het is te lastig alles perfect te laten werken. Om het bruggetje naar het onderwerp te maken: "Leuk dat Linux, maar ik wil wel audio over mijn HDMI-kabel hebben om op mijn UHDTV te kunnen spelen".

Dus ja, het marktaandeel van Linux hangt wel degelijk van dit soort, veelal lullige, zaken af.

Eigenlijk is AMD de eerste die met deze code, onder Linux een volwaardige desktopervaring kan bieden, out-of-the-box, zonder dat de gebruiker over drivers hoeft na te denken.

Behalve dat de drivers die in Linux zitten, alle basistaken makkelijk aan kunnen. Het is zeker niet perfect maar het werkt.

De manier waarop AMD het hier brengt is zodat het goed uit komt voor *hen*, niet voor Linux. AMD wil een codebase die makkelijk is voor hen en het boeit ze verder niet hoe de Linux maintainers er verder mee omgaan, lijkt het. Ik vind dat ze groot gelijk hebben om die code af te wijzen. Dan duurt het maar wat langer voordat ze een groter marktaandeel krijgen.

Dat lijkt me een wat ongenuanceerde weergave. Als je de discussies leest dan is men bij AMD tot nog toe zeer welwillend geweest in het aanpassen van de code aan de wensen van de kernel, en de betrokkenen beamen dat. Waar het pijnpunt zit is dat het delen van de code met hun interne validatieteam nu in gevaar komt.

Dat de drivers nu alle basistaken aankomt, is enkel en alleen het gevolg is dat AMD's Linuxteam extra werk heeft gedaan, om die basistaken mogelijk te maken. Je kunt in de discussie lezen dat men van dat "dubbel werk" af wil en toekomstige GPU's dus alleen door DAL ondersteund worden.

Het validatieteam is zowel de bron van de problemen, als de bron dat het mogelijk is een volledig functionele open driver te hebben. Het is niet een kwestie van "goed uitkomen", maar dat het Linuxteam van AMD niet groot genoeg is om alle code zelf te schrijven vanaf nul. Als je kijkt naar de hoeveelheid code waar het om gaat, 93000 regels aanvankelijk waar nu nog 66000 regels van over zijn, dan snap je dat dat niet op een middagje geschreven wordt en het delen van code dus belangrijk is. Er is dus een economische noodzaak code met dat validatieteam te delen om alle functionaliteit mogelijk te maken.

Als je de laatste ontwikkelingen in die discussie leest, dan zie je dat de betrokkenen aan Linuxzijde begrip tonen hebben dat die code gedeeld moet worden. Dat lijkt me de eerste stap naar een oplossing, maar die oplossing is er nog niet. De omvang van de code is zoals gezegd groot, de boel herschrijven kost veel mankracht, en het is nog niet geheel duidelijk hoe herschreven moet worden om aan de randvoorwaarden waarin beide partijen kunnen werken te voldoen.

De desktop: dat is toch een steeds minder boeiende markt naar mijn idee.
Plus, Linux hoeft niets te winnen, het is geen for-profit organisatie.

Dank je, als programmeur kan ik die reacties als 'stop het er gewoon in, niet zeuren' niet zo goed hebben.

Zodra ik stop met gaming of Linux beter ondersteund wordt zal ik maar al te graag switchen, en weet vrij zeker dat ik bij lange na niet de enige ben.

Op het moment zit de Steam catalogus op bijna 3000 games en dat groeit nog erg hard elke maand. Dus zelfs voor gaming hoef je niet per se meer op Windows te zitten.

Bioshock Infinite op Linux.. die had ik even gemist haha.. thanks

Pardon? AMD drivers heb je dus niet nodig, de open source drivers werken zover ik kan zien prima (ik heb zelf een nvidia kaart, dus geen directe vergelijking).

En kun je even uitleggen waarom Linux volgens jouw een dood paard is?

Die opensource drivers worden vooral door mensen van AMD geschreven. Die Alex die nu aan het mailen is doet dat al een tijdje.

Linux is een dood paard voor thuisgebruik omdat 0.01% (weet het exacte getal niet , maar zal er niet ver vanaf zitten) het gebruikt.

Je zit er ongeveer met een factor 200 naast.
Ter vergelijking: macOS zit momenteel rond de 6,5%.

[Reactie gewijzigd door Q-collective op 9 december 2016 21:15]

Thuiscomputergebruik is steeds vaker kleine geïntegreerde toestellen. Bv. hier in Vlaanderen is bijna iedereen een Linux gebruiker dankzij de Telenet digibox en/of die van Proximus.

Als jij een moderne wagen uit Duitsland hebt, dan draait er op je dashboard ook Linux en Wayland en Qt en al die dingen. Heb je een Amerikaanser type, is de kans groot dat er Android op staat. Dat is ook Linux.

En ja, dus die smartphone in je broekzak is heel vaak een Android he? Linux.

Dat routertje in de gang of garage? Meestal Linux. Die stofzuigerrobot? Je TV toestel? Meestal Linux.

En overmorgen die lampjes in je kerstboom waarschijnlijk ook.

Vrijwel iedereen heeft thuis (veel) meer apparaten die gebruik maken van een linux kernel, dan apparaten die op windows draaien.

Dat is niet eens waar op de PC markt. Op Steam is het 1 of 2 procent doe het gebruikt. Weinig, maar wel beduidend meer dan wat jij claimt. En dat is juist de enige markt waar Windows domineert.

Als je dan kijkt naar andere markten, dan is Windows al gauw een lachertje, of mogelijk zelfs volledig onbekend of onmogelijk. Er zijn een significant aantal servers met Windows, maar vrijwel elke zelfrespecterende server gebruikt toch een vorm van Linux. Waarschijnlijk zijn daarbij CentOS, Red Hat, en Debian, op die volgorde, de populairste distro's, al lijkt er niet echt data te zijn van welke specifieke distro's nu echt populair zijn. Maar als je een enigszins fatsoenlijke webserver pakt als voorbeeld, dan is het toch elke keer weer Linux.

En als je kijkt naar routers en ereaders, daar draait eigenlijk nagenoeg altijd wel Linux op. Misschien een enkele keer een eigen systeem. Windows zou je daar niet eens op kunnen draaien, zelfs als je het zou willen. En supercomputers worden al helemaal gedomineerd door Linux, met hier en daar een andere Unix variant. En ook op mainframes is Linux, vooral Red Hat, niet impopulair. Al wordt meestal IBM z/OS gebruikt, waarbij Linux vaak gevirtualiseerd wordt.

Kortom, eigenlijk wordt Windows juist nagenoeg niet gebruikt, buiten PC's en zo. Er is één bepaalde markt die door Windows gedomineerd wordt, en daarbuiten is het ook gewoon niet veel soeps.

[Reactie gewijzigd door Amanoo op 9 december 2016 22:50]

Nee hoor, die klopt niet.

Nee hoor. De Steam HW survey is niet hetzelfde als de markt voor video drivers.

En de HW survey is optioneel, lang niet iedereen doet mee. Steam OS en gebruikers in Big picture mode worden al helemaal niet meegeteld.

http://www.pcworld.com/ar...dware-survey-implies.html

Het is een kerngezond en huppelend paard.

Als je het hebt over desktop Linux, dat marktaandeel verandert bijna niet, en zit rond 1.5% wereldwijd, als je de browserstats bekijkt (download .csv). Overigens zit ChromeOS daar nog ver onder al is dat afgelopen jaar gestegen van 0.47% naar 0.75%

[Reactie gewijzigd door Dreamvoid op 10 december 2016 09:37]

Moeten mensen met een AMD-GPU nu zelf hun kernel compilen?

Nee, de driver zit nog niet in de kernel. Gewoon de closed source AMD driver pakken gok ik.

Dit zou mogelijk problemen kunnen gaan geven voor een nieuwe GPU architectuur. De huidige modellen werken prima met de amdgpu driver alleen ontbreken er nog een aantal features.
Eigenlijk denk ik dat Linux hier iets te idealistisch is aangezien de klanten gewoon willen dat de hardware werkt zodra die uitkomt. Aan de andere kant is AMD te pragmatisch want even 100K LOC's dumpen op een maintainer is natuurlijk niet hoe het werkt.

Dat is afhankelijk van of je DAL-functionaliteit nodig hebt. De DAL-code maakt meer dan 2 monitoren mogelijk, Freesync, geluid over HDMI, Displayport-hubs, en nog veel meer zaken die met beeldschermen te maken hebben.

Ik ben onlangs overgestapt van een HD6670 naar een RX460 en omdat ik 3 monitoren heb, heb ik mijn eigen kernel moeten compileren.

AMD is niet van plan non-DAL-code te schrijven voor toekomstige GPU's, dus in de toekomst zal, als er geen oplossing wordt gevonden, zelfs voor basisfunctionaliteit het nodig zijn je eigen kernel te compileren.

İk lees vaak op Tweakers.net dat veel tweakers AMD links laten liggen vanwege driver support binnen Linux. Dan dit bericht.. ligt het dan, afgaande van dit nieuwsbericht, aan AMD of aan Linux?

Het is al sinds jaar en dag dat ATI/AMD driver support op linux niet echt best was, in tegenstelling tot NVIDIA. Eeuwig zonde om goeie hardware te leveren maar dan geen aandacht aan de drivers te geven.

Mja het punt is dat ze dit dus proberen te verbeteren maar er nu roet in het eten wordt gegooid. Interessante discussie.

We are finally at a point where our AMD Linux drivers are almost feature complete compared to windows and we have support upstream well before hw launch and we get shit on for trying to do the right thing. It doesn't exactly make us want to continue contributing.

Uit het artikel lees ik dat de code slecht bij te houden zou zijn. Maar inderdaad, als AMD er zo veel energie in stopt lijkt mij dat geen probleem. Ik bedoel, hun kunnen het toch bijhouden?

Of de grote hoeveelheid HAL's moet een andere impact hebben dan alleen maintainability.

AMD/ATI geeft mijn inziens nu aandacht aan Linux. Echter keert Linux de rug naar AMD/ATI. Waarom? 100000 regels code is toch niets vergeleken met de codebase van Linux/Unix. Waar is de community nu?

Dat doet de maintainer niet makkelijk. De code van AMD voldoet nu niet aan de belangrijkste eis van de maintainers: goed onderhoudbare code. Het werkt misschien nu, maar wie zegt er dat het dat ook nog doet over X of Y generaties AMD kaart? Daar word zeer scherp op gelet, en betekent dat de maintainers hart hebben voor hun kernel en er niet alles word geaccepteerd. Als Linux zou vallen hebben we met z'n alllen een gigantisch probleem, net als bijvoorbeeld het uitsterven van bijen (teveel National Geographic gekeken vandaag, my bad)

Het moment om te branchen en amdux in de steigers zetten ?

Het is al een tijdje geleden dat ik een kernel gecompileerd heb, maar ik begrijp niet helemaal waarom een kernel module expliciet onderdeel moet worden van de kernel source? Wat heeft de direct rendering manager manager te maken met de code van een GPU driver? Als de code van AMD werkt en niet interfereert met de code van de kernel of display rendering manager zelf, dan is er toch geen probleem?

Nogmaals: ik heb werkelijk geen idee wat de interdependencies zijn tussen beide modules, dus als iemand daar wat licht op zou willen schijnen...

[Reactie gewijzigd door DwarV op 9 december 2016 20:38]

Had Dave ook het ontzettende gekunstel met de Intel I915 maar geweigerd om die skylake meuk aan de praat te krijgen. Vervolgens werkt je sandy bridge I915 niet meer en krijg je bugzilla entry's met bug meldingen waar alles op een grote hoop wordt geveegd en niks aan gedaan wordt (intel support zo ongeveer niets meer uit het sandy bridge tijdperk als ze het slopen).
Snap dat het maar een beperkte rol kan en mag spelen, maar AMD heeft wat mij betreft toch wel een beetje een gun factor.

Aan de andere kant levert een extra abstractie laag wel een hoop meer kernel code op die alleen maar voor AMD drivers gebruikt wordt. Op zich dus wel begrijpelijk dat men het om die reden liever niet ziet. Maar goed nu harde woorden, maar er zal uiteindelijk waarschijnlijk toch wel een acceptabele weg gevonden worden. Alleen wel meer vertraging en dat is jammer.

[Reactie gewijzigd door gekkie op 9 december 2016 22:26]

100.000 regels code die geweigerd wordt vanwege teveel abstractie?

Hoezo kwam dit niet eerder aan het licht? Zo'n grote bijdrage aan een kernel dump je toch niet even zomaar na honderden zoniet duizenden manuren werk? Zonder demo's of overleg?

Als er een probleem was met de opzet vanwege het onderhoud... Lijkt me dat het een gevalletje is van 'over de schutting gooien'. Ik dacht eigenlijk dat dit tegenwoordig nauwelijks meer voorkwam...

als je onleesbare code levert is het een bedreiging voor de veiligheid.
Ze willen gewoon weten wat er word toegevoegd en wat het doet lijkt me erg redelijk.
Door de onthullingen van snowden begint het bewustzijn door te dringen dat closed source een potentieel beveiligins probleem is.
Dat is jammer want ik denk dat closed source bedrijven dit zelf ook niet willen , maar hun model van werken maakt ze gevoeliger voor afpersing van een staat of dienst.
Bij opensource heeft deze manier van afpersen geen zin , want omdat je er niet naar mag handelen , kun je ook de patch die het veiligheids lek oplost wat jij moest in bouwen niet weigeren.
Bij closed source heeft deze vorm van dwang een veel hogere kans van slagen.

[Reactie gewijzigd door bluegoaindian op 10 december 2016 04:14]