AMD Ryzen 3000-processors werken door bug niet met recente Linux-distributies

AMD's nieuwe Ryzen 3000-processors werken momenteel niet in combinatie met recente Linux-distributies zoals Ubuntu 19.04. Het gaat mis bij het booten; de systemd services starten niet. De processors werken wel met LTS-versies zoals Ubuntu 18.04.

Linux-website Phoronix concludeert dat in zijn review van de Ryzen 9 3900X en de Ryzen 7 3700X. De auteur probeerde de nieuwe AMD-hardware werkend te krijgen met recente Linux-distributies, maar dat lukte niet. Bij zowel Ubuntu 19.04, Manjaro Linux als Fedora Workstation 31 gaat het bij het booten mis. Bij gebruik van een Linux-versie die langdurige ondersteuning heeft, of oudere versies, zijn er geen problemen.

AMD zegt tegenover Phoronix dat er een probleem is met de Linux-kernel 5.0.9, maar geeft geen verdere details. Het lijkt echter niet om een kernelprobleem te gaan, want volgens Phoronix booten de nieuwe Ryzen-processors wel als Ubuntu 18.04 wordt gebruikt in combinatie met kernels 5.0, 5.1 of 5.2. De processorfabrikant zegt zelf de processors grotendeels getest te hebben met Ubuntu 18.04, de meest recente LTS-versie.

Volgens Phoronix is het niet duidelijk waar de fout precies zit. Het kan gaan om een issue tussen de Linux-kernel en de nieuwe processors, of om een probleem met de X570-chipset. Met oudere Ryzen-processors zijn dergelijke problemen er niet.

Linux-gebruikers die aan de slag willen met een Ryzen 3000-processor zullen, zolang er geen oplossing is, moeten terugvallen op een versie zoals Ubuntu 18.04 LTS of een andere enterprisedistributie die niet op de nieuwste kernel is gebaseerd. Wanneer er een oplossing komt, is nog niet bekend.

Reacties (167)

[CAPSLOCK2000]

Ik kan me niet voorstellen dat niemand bij AMD dit geweten heeft, er zijn daar meer dan genoeg nerds in dienst dat er wel iemand moet zijn die Ubuntu 19.04 draait. De vraag is meer of er nog iets aan gedaan kon worden. Het ontwerp van die processor is waarschijnlijk maanden geleden afgerond, op een moment dat nog niet duidelijk was welke kernel Ubuntu 19.04 precies zou krijgen.

Als het echt een kernelbug is, zoals het lijkt, dan is AMD natuurlijk niks te verwijten. Ik vermoed dat er al een patch is om de bug te verhelpen maar dat die niet tijdig is doorgevoerd omdat niemand buiten AMD van het probleem kon weten.

Als de patch er nog niet is verwacht ik dat die binnen een paar dagen wel beschikbaar is. Aangezien andere kernels geen probleem hebben zal het niet heel moeilijk zijn om het verschil te vinden en het probleem op te lossen. Dan zal het wel nog even duren voor Ubuntu een nieuw installatie image heeft gebakken met de nieuwe kernel. In de tussentijd kunnen gebruikers zich behelpen met de LTS versie van Ubuntu.

[Reactie gewijzigd door CAPSLOCK2000 op 23 juli 2024 09:44]

[Freeaqingme]

maar dat die niet tijdig is doorgevoerd omdat niemand buiten AMD van het probleem kon weten.

Dat denk ik niet. Vaak zie je al maanden voor een release wat een nieuwe CPU zoal gaat kunnen omdat er aan de kernel nieuwe dingen worden toegevoegd die enkel mensen binnen AMD of Intel kunnen testen. Dit juist om er voor te zorgen dat op het moment dat de hardware gereleased wordt er al kernels in omloop zijn die hier mee om kunnen gaan.

Mijn vermoeden is dat ze voor Linux een aantal (LTS) distro's gepakt hebben en zich daarop hebben gefocust en eventueel op basis van die distro ook nog wat nieuwere kernels geprobeerd.

Als er dan al iemand zou zijn geweest die Ubuntu 19.04 had gepakt, dan had 'ie (mogelijk) geconcludeerd dat het aan Systemd lag. De systemd-community is niet altijd de makkelijkste, en als 't probleem dan ook nog eens moeilijk te pinpointen is, kan ik me goed voorstellen dat ze 't gewoon lekker bij de LTS kernels hielden, er van uitgaande dat de systemd community dit op het moment van uitbrengen ook heel goed zelf op kon lossen.

[Umbrah]

Het lijkt er op dat het niet eens een kernel probleem is, maar een systemd probleem, voornamelijk in de samenwerking met de kernel juist... Het probleem is inderdaad hoe gigantisch breed en divers dit landschap is, en ja, er zullen best veel nerds in dienst zijn, maar ik gok dat de focus ook heel erg op virtualisatie/epyc lag (zelfde architectuur... Zen2. Geen woord of dat wel/niet werkt). Je kan bij Microsoft gewoon Epyc-based azure bakkies aanzetten met een linux distro er op, en dat werkt gewoon goed. Erg snel zelfs. Nadeel dat het geen kleine VM's kunnen zijn, maar als je de workload hebt om een vol te zetten, dan zijn ze binnen Azure heel erg bang-for-bucks!

[MainframeX]

Ubuntu biedt anders wel gewoon een fijne, mooi gestyleerde desktop aan met behoorlijk wat gebruiksvriendelijkheid. Ik heb enorm veel distro's door de jaren gebruikt maar Ubuntu blijf ik voor de desktop nog steeds prefereren. Geen gedoe en redelijk stabiel zonder dit met al te oude software te bewerkstelligen. Ik vind het sentiment dat Ubuntu niet voor nerds is dan ook, als nerd zijnde, volkomen onterecht.

[Tout]

Ja, dat is ook wat ik bedoel. Een nerd vind ik iemand die extreem puristisch bezig is. En daar telkens verder in gaat en de grens op zoekt. Dus dan draai je volgens mij niet Ubuntu.
Maar er kunnen natuurlijk verschillende definities zijn van nerd.

[Jerie]

Ach, wat een kak, alsof die allemaal Arch draaien.

Ubuntu LTS werkt prima in productie. Op individuele development laptops kan ik me iets bleeding edge als 19.04 nog wel voorstellen.

Maar er kunnen natuurlijk verschillende definities zijn van nerd.

Nee, er is maar 1 definitie van nerd, en die vind je in het woordenboek of op Wikipedia. Die definities zijn geen van allen hier van toepassing.

Het probleem zit hem hier:

Een nerd vind ik iemand die extreem puristisch bezig is.

Ten eerste vind ik

Ten tweede extreem puristisch op welk vlak precies?

[Tout]

Definition of nerd

... one slavishly devoted to intellectual or academic pursuits

https://www.merriam-webster.com/dictionary/nerd

-----

A nerd is a person seen as overly intellectual, obsessive, introverted or lacking social skills. Such a person may spend inordinate amounts of time on unpopular, little known, or non-mainstream activities, which are generally either highly technical, abstract, or relating to topics of science fiction or fantasy, to the exclusion of more mainstream activities.

https://en.wikipedia.org/wiki/Nerd

[Jerie]

Archetype autist. Nerd is een achterhaald woord.

[bvdli]

In tegenstelling tot het artikel en weel reacties geeft Michael van Phoronix aan dat het niet om de kernel gaat:

"when trying Linux 5.0/5.1/5.2 kernels on Ubuntu 18.04 LTS, they all booted up fine!"


"some kernel+systemd interaction issue happening just on AMD Ryzen 3000 series processors or some awkward thing happening with the X570 chipset"

bron: https://www.phoronix.com/...n-3700x-3900x-linux&num=2

[Reactie gewijzigd door bvdli op 23 juli 2024 09:44]

[Xtuv]

Goed punt, dat nog even verduidelijkt

[TeraMod]

Nu is de laatste alinea niet meer geheel juist, aangezien daar nog gesproken wordt over de kernel versie.

[Reactie gewijzigd door TeraMod op 23 juli 2024 09:44]

[uiltje]

Het lijkt een probleem te zijn met RDRAND en het genereren van random UID's voor file handles ofzo. Zie mijn bericht helemaal onderin.

[3dmaster]

Het is trouwens een combinatie van linuxkernel + ryzen 3xxx en systemd. Systemen zonder systemd maar met (oudere/andere) initsystemen werken namelijk wel.

[himlims_]

beetje-offtopic;

er zijn verschillende Ryzen boardjes, -zonder- vga /hdmi on board.... (in 2019 let ik daar niet op; vanuit gegaan dat standaard onboard vga/hdmi heeft) is dus niet altijd bij die ryzen boardjes, en vereisen soms externe gpu!

Helemaal niets spannends! Dit gebeurd vaker bij nieuwe hardware... kwestie van paar weken wachten.

Ubuntu 18.04.2 gebruikt HWE kernel (4.18), die is gewoon geschikt. Draai de laatste non LTS build of draai een rolling release distro zoals Manjaro/Arch

wat een sensatie artikel

zo heeft hadden we ook probleem met Intel omtrent powermanagement cpu feature; werkte ook niet out of the box, paar weken later fix in kernel gebouwd. Daarom is het -altijd- te adviseren vooraf te controlleren of de gewenste hardwrare reeds ondersteund is. Zo niet, wacht even of kijk op roadmap

//edit;
werkt gewoon met LTS, als je bleeding edge draait heb je redelijk kans op issues

[Reactie gewijzigd door himlims_ op 23 juli 2024 09:44]

[uiltje]

Sensatie artikel? Ik ben zelf in de markt voor een nieuw AMD systeem, expliciet om Linux als dev. environment te gebruiken. Daarbij wil ik wel een relatief nieuwe variant van de stabiele OpenSSL installeren, om maar wat te noemen. Ik zou serieus in de problemen komen als ik 'm nu zou aanschaffen, dus nou stel ik hem met zekerheid uit.

Sorry hoor, maar als de meest up-to-date CPU niet werkt met de meest up-to-date Linux kernel dan is dat toch wel een artikeltje waard?

[Cergorach]

Sorry hoor, maar als de meest up-to-date CPU niet werkt met de meest up-to-date Linux kernel dan is dat toch wel een artikeltje waard?

Das niet helemaal accuraat:

Complicating this issue further is that when trying Linux 5.0/5.1/5.2 kernels on Ubuntu 18.04 LTS, they all booted up fine!

Dus het werkt wel met recentere kernels onder 18.04, het issue lijkt mogelijk in Kernel 5.0.9 te zitten, welke standaard bij Ubuntu 19.04 zit (en kennelijk een aantal anderen). En vergeet ook niet dat 5.0.9 niet de meest recente kernel versie is van de 5.0 serie...

Waarom zou je op een devbak de meest recente versie van Ubuntu willen installeren ipv. de LTS versie?

[uiltje]

Waarom zou je op een devbak de meest recente versie van Ubuntu willen installeren ipv. de LTS versie?

Omdat ik er altijd achter kom dat mijn libraries niet up to date zijn, en ik werk op meerdere omgevingen (Perl, Bash, JavaScript / NodeJS, Python, PHP, GoLang, Ruby, Kotlin en natuurlijk Java). Dit omdat ik meer gespecialiseerd ben in security / cryptografie dan een specifieke taal.

En ja, je kan ze dan allemaal separaat nog een keer gaan installeren, maar da's een pokke-werk en voordat je het weet zit je in een .dll (nou ja, .so) hell.

[thomas_n]

De CPU's zijn nét uit, het is vrij gebruikelijk dat het een paar weken duurt voor alle kinderziektes er dan uit zijn. Dit is er natuurlijk wel één die ze hadden moeten vinden tijdens het testen, maar ik zou sowieso altijd een paar weken wachten met kopen als er nieuwe CPU's of GPU's uit zijn, zodat je zeker weet dat er geen grote problemen optreden.

[Bjorn89]

Nee hoor, dat was vroeger bijna nooit zo. Dat het nu nog amper gebeurd betekend niet dat het niet kan gebeuren. Dit is geen blunder, zoals vaker al aangegeven is hun focus v.n.l servermarkt, waarbij LTS en stabiele versies prioriteit hebben omdat daar hun marktaandeel het grootste is.

Remember, je moet ook afentoe zakelijk denken, AMD heeft minder omzet dan nvidia en intel(iirc), dus moeten ze vaker nadenken waar hun geld naartoe gaat (sowieso met elk bedrag).

Die CPU update zal wel snel komen, dus hold your horses

[SauSkopje]

beetje-offtopic;

er zijn verschillende Ryzen boardjes, -zonder- vga /hdmi on board.... (in 2019 let ik daar niet op; vanuit gegaan dat standaard onboard vga/hdmi heeft) is dus niet altijd bij die ryzen boardjes, en vereisen soms externe gpu!

Dit is al sinds Zen gen 1. Waar bij Intel het een uitzondering is dat er geen iGPU zit, is bij AMD de uitzondering dat er wel een in zit.
Dus de meeste highend bordjes, komen zonder beeldaansluitingen. Aangezien de highend line-up van AMD toch geen iGPU heeft, voor nu 3 generaties al.

[Cergorach]

Als de maker zegt het niet met Ubuntu 19.04 te hebben getest dan is toch al vlot duidelijk dat Linux geen hoge prio heeft en ik vermoed dat dit niet alleen een AMD issue is. Ubuntu 19.04 is nog geen 3 maanden uit, wat best lang is in software land, maar ik vermoed minder spannend in hardware land.

Fedora Workstation 31 is nog niet eens officieel uit.

Daarnaast mag Ubuntu dan een van de populairdere Linux distributies zijn, het is echter slechts een van honderden distro's. Verwachten dat een fabrikant dat allemaal test is gekke werk. Ik kan me goed voorstellen dat AMD ergens een lijn trekt.

@kozue Sure, maar dan pak je ook niet de meest recente versies van Linux, dan pak je de LTS versies om mee te testen, want dat zal een (web)server draaien. En dat is specifiek servers.

[Reactie gewijzigd door Cergorach op 23 juli 2024 09:44]

[kozue]

Volgens mij heeft Linux een heel hoge prio bij CPU fabrikanten. Wellicht niet voor desktop gebruikers, maar in serverland zijn Linux systemen toch wel in de meerderheid. En juist op servers worden meestal de populaire distro's gebruikt, geen flavor-of-the-month zoals een zoveelste Ubuntu of Fedora spinoff, maar distro's met langere ondersteuning (zoals Ubuntu 18.04 of de laatste Red Hat/CentOS). Ik zou zelf in ieder geval nooit 19.04 op een server zetten, dan blijf je bezig met upgraden als je een veilig systeem wilt houden. Wel of niet testen met een release met zeer korte ondersteuning zegt dus helemaal niets over de prioriteiten van de fabrikant.

[SuperDre]

Linux heeft wel een redelijke prioriteit, alleen niet de allerlaatste versie, maar vooral de LTS versie die WEL in zakelijke omgevingen gebruikt worden.
En precies zoals je het zelf ook al zegt, er zijn zoveel verschillende linux distro's dat het gewoonweg niet te testen valt. En het lijkt dus ook nog eens een combinatie te zijn van verschillende factoren.
Eerst dus maar eens afwachten waar het probleem nu werkelijk in zat, en dat zal ook best redelijk snel wel opgelost zijn.

[sapphire]

Hier ga ik denk heel veel mensen mee op de tenen trappen maaaar.....

Is dit niet een klein beetje Linux eigen? Vroegâh toen al mijn vrienden zo'n beetje sys-admin/hacker/coders waren en ik vrijwel de enige was in de groep die Windows draaide hebben ze me vaak genoeg geprobeerd over te halen. Alleen omdat ik relatief vaak van HW wisselde en nieuw-op-de-markt-spul had was het altijd geklooi omdat er altijd wel 1 onderdeel of combinatie van onderdelen niet goed werkte of ondersteund werd.
Afgelopen jaren vaker dit soort dingen gehad dat het out of the box even pielen was om dingen goed werkend te krijgen. Als Tweaker nog te doen maar makkelijk is het niet voor de gemiddelde consument.

Begrijp me niet verkeerd ik heb niets tegen Linux en gebruik het op mijn Pi's nog dagelijks maar qua gebruiksvriendelijkheid voor de gemiddelde consument schieten dit soort dingen echt niet op
Bij wie de 'schuld' ligt laat ik even in het midden maar vaak is Windows wel een stuk sneller/makkelijker in gebruik met nieuwe HW (en ja Windows heeft ook zo zijn nadelen).

Voor ik van alles naar mijn hoofd krijg, ik heb de afgelopen jaren regelmatig Ubuntu, Linux Mint, Puppy Linux en Rasbian gebruikt
En ja dit is alleen mijn persoonlijke mening, ik presenteer dit dus niet als feiten ofzo

[batjes]

Het ondersteunen van X86 is niet zo makkelijk als het lijkt voor een OS. Het grote probleem is dat iedereen, inclusief Linux en Microsoft, de ontwikkeling voornamelijk op Intel deden. En dat AMD toch echt heel andere koek is.

Windows 7 had bv ook enorme problemen met de Bulldozer lijn (Hè 8 cores, hier 8 threads, oh sorry, zijn 8 floating threads, kut maar 1 float unit per 2 cores.... jammer). Maar heeft ook voor Ryzen weer optimalisaties mogen uitbrengen om de bende zo goed mogelijk te ondersteunen. Windows heeft het voorbereid dit keer en de Mei update al voorzien van Ryzen 3000 optimalisaties en verbeteringen.

[MSalters]

Sorry, maar dat laatste is vaag. Er is niet zoiets als een "floating (point) thread". Of je het nu over Windows 7, Windows 95 of Windows 10 hebt, en zelfs onder Linux, elke thread mag op elk moment floating point instructies gebruiken.

Sowieso is "de floating unit" een achterhaald idee op x86. Je hebt de antieke x87 unit, SSE en AVX.En daarvoor maakt de OS versie wel uit. Voor AVX heb je Windows 7 SP1 nodig, maar dan werkt AVX dus meteen op alle threads. Het OS moet namelijk bij een thread switch alle registers bewaren, dus ook alle SSE en AVX registers, en dan moet het OS dus ook weten welke registers dat zijn.

In een theoretisch OS zou je dus wel een "floating point thread" kunnen hebben, waar het OS weet dat de SSE en AVX registers in gebruik zijn, terwijl "integer threads" kleiner zijn. Dat is theoretisch, Windows en Linux werken dus niet zo.

[batjes]

Berekeningen worden doorgaans gedaan met INT of floats. Bulldozer/Piledriver is ongewoon in deze, omdat het aantal float en int units niet gelijk is. 2 int units per float. Terwijl dat voor Athlon en Intel wel het geval is/was.

Software moet hier rekening mee houden, anders stort de performance in elkaar. Ongepatchde Unreal Engine 3.0(3.5), Unity <6 en ARMA hebben hier bv enorm veel last van.

Stuur 6 threads met float berekeningen naar een 8 core FX, en de performance zakt gewoon enorm in elkaar, want het kan er maar 4 tegelijkertijd verwerken. Als software 8 cores ziet, verwacht het er normaal ook echt 8 volledig functionele cores en wordt er geen rekening gehouden met de opzet van Bulldozer.

Met Ryzen is het aantal float en int units weer gelijk aan het aantal cores. Zoals voor Bulldozer en wat bij Intel het geval is.

[MSalters]

Daar is de Bulldozer helemaal niet zo ongebruikelijk in. Zelfs de originele Pentium (P5 architectuur) had al integer U- en V-pipelines, terwijl die maar een enkele FP unit had. En ook de modernste Coffee Lake heeft 4 integer ALU's (port 0-3) tegen 2 FP units (port 0-1) Bron: https://en.wikichip.org/w...ffee_lake#Individual_Core

Waar Bulldozer ongebruikelijk in is, is dat de FP units oook nog eens gedeeld zijn tussen cores.

[Itrme]

Die mei update is anders ook niet zaligmakend. Zo te zien hebben Ryzen processors nog steeds last van Core/thread shuffling. In plaats van de meest efficiënte core te pakken blijft het verspringen. Niet echt handig

Maar goed, Zen2 is nu een dag uit en er werkt iets niet naar behoren. Hier kan ik me niet echt druk om maken. Het is niet alsof iedereen in het bedrijfsleven gelijk de meeste recente software gaat draaien. Dat verschillende distro's niet werken is vervelend maar dat wordt t.z.t. vast wel gefixed.

[N8w8]

Het wordt doorgaans belangrijk gevonden dat nieuwe hardware goed werkt onder Windows/Apple.
Dan is de kans ook groot dat de fabrikant er voor de verkoop alvast voor zorgt dat dat snor zit.
Wil je Linux gebruiken, dan moet je van tevoren uitzoeken welke hardware daar goed mee werkt, of bidden dat je hetgeen je koopt op eoa manier werkend zal gaan krijgen.
Maar nieuwe CPUs werken doorgaans wel prima omdat Intel/AMD daar (net als bij Windows) van tevoren zelf voor zorgen. In dit geval dus niet (dat je je computer niet eens kan booten is wel een dingetje!), dus is mss wel een nieuwsberichtje waard

[thomas_n]

Ja, dit is Linux-eigen, maar het is ook niet echt een groot probleem. Als je altijd een maandje wacht voor je de nieuwste spullen koopt heb je hier nooit echt last van.

Waarom zou je als Tweaker trouwens graag iets willen dat gericht is op "de gemiddelde consument"?

[ignitem]

Het is verstandig om voordat je nieuwe hardware koopt na te gaan of Linux deze hardware ondersteunt. Liever nog of de fabrikant populaire linuxdistributies ondersteunt. Zo heb je nooit hardwareproblemen.
Anders loop je inderdaad het risico dat je een half jaar moet wachten totdat het een en ander werkt.

[uiltje]

Lijkt me dat het technische probleem zich niet per se bij AMD moet liggen. Het is best wel denkbaar dat Linux iets foutief gebruikt en dat het bij de vorige platvormen geen probleem vormde.

Maar dat een kernel dat gebruikt wordt in de grootste Linux distro van April niet werkt, tja, da's wel een blunder. Tijd genoeg om te testen, lijkt me zo. Als AMD engineer die verantwoordelijk is voor Linux zou ik tenminste 1 keer geprobeerd hebben om te booten, zelfs als ik daar geen opdracht toe gekregen had.

Dat kan je doen tijdens de lunch tussen de opdrachten door.

[RavonsDaro]

Is een beetje kortzichtig, niet? "Dat kan je doen tijdens de lunch tussen de opdrachten door" is alleen niet zwaar kort door de bocht maar voor die engineers niet altijd een haalbaar feit.

Je lunch is om te lunchen, niet om iets wat gewoon een standaard opdracht op de roadmap had moeten zijn te testen. Dit is gewoon een blunder van het team van AMD als wie ook verantwoordelijk is voor de Linux distributies.

[Reactie gewijzigd door RavonsDaro op 23 juli 2024 09:44]

[yvez]

Waarschijnlijk was de lunch comment een figure of speech, denk je niet?

Het punt is dat dit waarschijnlijk heel simpel op te lossen is, maar iemand moet het wel even doen.

[MrMonkE]

En weten wat de oorzaak is.
Soms ben je weken aan het zoeken, soms vind je het binnen een dag.

[yvez]

Daar heb je helemaal gelijk in. Zoals eerder aan gegeven door anderen; ik ben echt benieuwd hoe dit heeft kunnen gebeuren. Hebben ze niet gevalideerd of hebben ze van AMD niet de resources gekregen om te valideren.

Enfin, uiteindelijk is dat voor de toekomst om dit te voorkomen, nu moet het gewoon opgelost worden natuurlijk.

[Dennism]

Ik zou dit geen lichte blunder willen noemen, dit is gewoon echt een flinke blunder.
Hier had AMD echt strakker op moeten zitten.

[Reactie gewijzigd door Dennism op 23 juli 2024 09:44]

[OMX2000]

Hoezo? De LTS versie wordt ondersteund, dus als je afhankelijk bent van je machine is het sowieso handig om met een LTS versie te werken.

En misschien wist je het nog niet maar een CPU is al een bijzonder complex beestje, doe er een chipset bij en operating systems die je niet zelf in de hand hebt en het is wachten op een fout.

[Dennism]

Waarom dit een flinke blunder is? Ten eerste omdat bedrijven als AMD (Maar ook bijv Intel, Nvidia en IBM) linux programmeurs in dienst hebben juist om dit soort zaken af te vangen en op te lossen voor een release. Als bijvoorbeeld een Ubunto 19.04 gister uitgebracht was dan was het nog enigszins logisch geweest. Echter Ubuntu 1904 is van half April, dat had echt op moeten vallen dat deze distributie niet werkt, een bugje hier of daar is prima en ook te verwachten. Maar dat recente distri's niet eens booten is gewoon simpelweg niet in orde.

Ten tweede, omdat dit nu in het nieuws komt. Dit is voor AMD een enorme release waarbij het zeer belangrijk is dat dit je niet van dit soort nieuws berichten krijgt. Je wil geen negatief nieuws tijdens een grote release als dit. Dit is een zeer mooie release van AMD, echter zie je nu alweer negativiteit naar boven komen, o.a. dit nieuws, maar ook nieuws bugged Agesa code waardoor cpu's niet kunnen boosten naar de waardes waarmee AMD adverteert, te hoge voltages (wederom) op de Navi 5700XT kaarten. Al met al legt het een klein smetje op de release wat gewoon zeer jammer is en daar hadden ze voor moeten waken.

[Reactie gewijzigd door Dennism op 23 juli 2024 09:44]

[cavey]

En dan nog zie ik het niet als blunder van AMD. Ze geven zelf aan dat hun processors prima werken op Linux kernels 5.0, 5.1, 5.2. Nu is er een specifiek geval van 5.0.9 die op Ubuntu 19.04 wordt geleverd, waar een issue optreedt. En dan zit het issue ook nog eens in SystemD, wat iedereen toch al een gedrocht van een services manager vindt/vond.

Dus ik zou het eerder daar in systemd gaan zoeken, wat helemaal niet kernel of AMD gerelateerd is. Dat het dan niet opstart is wel zuur, maar omdat op het conto van AMD af te gaan schuiven.

Uit het artikel:
[quote phoronix]
On newer Linux distributions, there's a hard regression either within the kernel but more likely some cross-kernel/user-space interaction issue leaving newer Linux distributions unbootable.|
[/quote phoronix]

Dat is een complexe keten waar AMD niet zo gek veel aan kan doen. Ze hadden het misschien kunnen vinden/concluderen, maar als je voornaamste taak is om je CPU support in de kernel te bakken volgens het raamwerk binnen de kernel, en de boel compileert en boot, dan is op zich jouw kant van het verhaal klaar. Dus er zit een nieuwigheid in systemd (versie verschil tussen 18.04 LTS, en 19.04), wat voor de nodige issues zorgt.

En dat wordt netjes door Phoronix verteld. Dus ik zie niet in hoe AMD hier aan het blunderen is. Misschien is hun security model iets te strak voor systemd, of doet systemd oneigenlijke dingen (undocumented features die met Ryzen3 niet meer kunnen). De toekomst zal het leren.

[Dennism]

De blunder is naar mijn mening dat je dit niet afvangt vooraf, dit is gewoon simpel weg nieuws dat je niet wil zien verschijnen de dag na je grote release.
Ik zeg totaal niet dat AMD hiervoor direct verantwoordelijk is, echter had dit naar mijn mening wel gewoon getest moeten worden. En of AMD dat testen zelf had moeten doen of dat AMD samples had moeten verstrekken aan bijv. Canonical zodat zij dit vooraf konden testen is me dan om het even.
Marketing technisch is dit gewoonweg niet heel handig terwijl je dit volgens mij gemakkelijk voor de deur had kunnen afvangen en of oplossen met de dev's in dienst van AMD in samenwerking met de dev's van bijv. Canonical en eventueel de Systemd dev's of zorg dat er vooraf een advisory gepubliceerd is met "Dit en dit zijn openstaande issues, we werken eraan met onze partners en oplossing gaat het helaas nog niet zijn op release day".

Dat komt veel beter over dan dat je dit soort nieuws moet lezen in de media. En dat vind ik toch echt gewoon een blunder, het was namelijk echt niet nodig geweest.

[cavey]

Ah, een PR blunder, ja, dat kan ik beamen.

[uiltje]

Ja, als die kernels wel onder LTS goed draaien dan kan ik me voorstellen dat ze er vanuit gaan dat ze het in een andere distro ook wel doen. Dat is wel een gekke omstandigheid. Dat het technisch niet AMD's fout hoeft te zijn had ik zelf ook al bedacht en opgeschreven. Toch wel vreemd dat zo'n belangrijke release niet kort getest is; het niet testen is de blunder. Een probleem met booten zal ik niet snel een blunder noemen - dat kan gebeuren. Linux blijft een monokernel, dus sw crashes kunnen voorkomen (hw crashes kunnen natuurlijk altijd voorkomen, nothin' is perfect).

[psychicist]

Het is aan te raden het originele artikel op Phoronix te lezen, want daaruit wordt het duidelijk dat het niet enkel om Ubuntu gaat, maar dat het probleem zich ook voordoet op Manjaro en een vroege versie van Fedora 31. Het probleem lijkt zich dus specifiek voor te doen in systemd en de ontwikkeling daarvan wordt voornamelijk gedaan door Red Hat.

In deze is het dus zaak voor AMD om met de ontwikkelaars gezamenlijk tot een oplossing te komen voor het probleem, omdat het wel degelijk ernstig is en voorkomt dat mensen de nieuwste distributies in combinatie met de nieuwe Ryzen 3000 processoren kunnen gebruiken

[OMX2000]

Wacht ff. De belangrijkste markt is Windows en daarna Linux. En dan met name zakelijk Linux. Dus als je prioriteiten moet stellen begrijp ik wel dat je de 19.04 release niet bovenaan je lijstje hebt staan.

Dus een fout, ja. Blunder vind ik overdreven.

[ejabberd]

AMD zit ook in de ontwikkeling van supercomputers, zeg maar de Formule 1 van computers. Die dingen draaien allemaal Linux. Als je meedoet met zulke prestigeprojecten (die waarschijnlijk ook veel opbrengen), dan zorg je ervoor dat uw processors goed draaien onder Linux.

Wat nu gebeurt is een even grote blunder als zou Ferrari een jeep op de markt brengen waarvan de motor stilvalt op hobbelig terrein.

[Jasper Janssen]

Beta versies van Ubuntu zijn nu eenmaal geen prioriteit. De boel moet werken op LTS, en verder moet Ubuntu zorgen dat er geen regressies zijn.

[sfranken]

*Beta* versies niet nee, maar 19.04 is gewoon uitgekomen en gereleased, dus geen beta versie (allang niet) meer...

[ejabberd]

19.04 is géén betaversie. Die versie krijgt evenveel ondersteuning als 18.04 LTS. De periode van die ondersteuning is enkel korter.

[Jasper Janssen]

Dat zeg ik, de bleeding edge die alleen gebruikt wordt door hobbyisten.

[Dennism]

Dan verschillende we daar deels over van mening, ben het met je eens dat andere disti's ook belangrijk zijn en dat 19.04 niet bovenaan de prio lijst staat.

Maar dat deze (en andere distro's) niet eens willen booten vind ik toch echt een blunder en geen klein foutje. Dat had gewoon ofwel gefixed moeten worden, of je brengt een advisory uit dat je de bug kent. er hard mee bezig bent het op te lossen samen met de partners bij de betreffende distri's, maar dat op release date er nog geen oplossing is. Dat staat veel netter dan berichtgeving als deze.

[zenlord]

Misschien is het probleem niet door AMD veroorzaakt of op te lossen, maar niemand anders kon het probleem opmerken tot voor gisteren omdat er een moratorium gesteld was op nieuws over de nieuwe processors en chipsets.
AMD heeft een specifiek team om hun hardware te doen werken met linux, en begin dit jaar hebben ze nog aangegeven dat ze dit team met 20 personen zouden uitbreiden, dus minstens claimen ze enige welwillendheid naar de linux-gemeenschap...
Als je aan de vooravond staat van een lancering van een nieuw product, zou ik van dat team toch verwachten dat ze inderdaad meer dan 1 distributie (minstens meer dan 1 versie van die ene distributie) hebben geboot.
Grote fout, blunder, catastrophe of gewoon een gemiste kans om punten te pakken bij powerusers en influencers (iedere tweaker beinvloedt *tig mensen rondom zich)? Op een ogenblik dat menig enthousiast het AMD zou gunnen om Intel van de troon te stoten, laten ze hier wat mij betreft de bal vallen.

[jbhc]

Valt toch wel mee? Ik, als linux gebruiker, zou er geen Intel van gaan kopen. Hardwareondersteuning duurt wel vaker wat langer bij Linux.

[Reactie gewijzigd door jbhc op 23 juli 2024 09:44]

[zenlord]

Het is net het omgekerde in deze situatie: vaak moet je bij nieuwe hardware net kiezen voor een zeer recente kernel, video drivers en mesa. Begin dit jaar bvb heb ik mijn standaard installatie script voor nieuwe hardware zodanige ingesteld dat bovenop Debian Stretch de backports repo's werden gebruikt voor deze packages. Zoniet, wou menig recente laptop X niet laden...
In dit geval moet je dus tegen-intuitief een oudere linux distributie kiezen om de bleeding edge hardware te kunnen opstarten...

[Jasper Janssen]

19.04 is wel degelijk ongeveer gisteren uitgekomen. Wat denk je dat een engineer drie maanden voor de publieke release nog kan veranderen aan een chip?

[Dennism]

Aan de chip niet, maar dat wordt ook nergens aangegeven. En dat is ook niet nodig voor dit issue. Dit is gewoon iets dat in software opgelost gaat worden en juist daar heeft AMD een sloot aan ontwikkelaars voor in dienst.

Verder is 19.04 uitgekomen op 18 april en dus zeker niet "ongeveer gisteren".

[Reactie gewijzigd door Dennism op 23 juli 2024 09:44]

[locke960]

Wat denk je dat een engineer drie maanden voor de publieke release nog kan veranderen aan een chip?

Niets, maar elk nadeel heb zijn voordeel, om met Johan Cruyff te spreken. Een lange hardware freeze geeft veel tijd om nog voor de publieke release de nieuwste software te testen. Dat kun je zelf doen, of je kunt engineering samples naar bedrijven sturen. Is heel gebruikelijk.

Ubuntu 19.04 is op 18 April uitgekomen. Dat betekent dat zowel AMD als Ubuntu in de afgelopen (bijna) 3 maanden de combinatie niet heeft getest. Zonder verwijten rond te strooien kun je toch wel stellen dat dit opmerkelijk is.

[Brousant]

Waarom dit een flinke blunder is? (...) Al met al legt het een klein smetje op de release (...)

Een klein smetje op de release vind ik geen flinke blunder.

Grote kans dat er al binnen een paar dagen een bug fix of workaround beschikbaar is om het op te lossen.

[Dark_man]

Maar wacht even, zijn we dan zo snel vergeten dat een paar weken terug nog de CPU's van Intel die jarenlang verkocht zijn enorm veel veiligheidsissues bevatten?

Dat gaat dan om CPU's die al jaren te koop zijn en dus juist voor bedrijven enorme risico's meebrengen om ze te hebben draaien op je servers.

En dan maak jij je druk om een weinig gebruikt OS onder consumenten waarvan een specifieke versie ook nog niet zou booten.

Verhoudingen lopen dan wel erg scheef kwa ophef als je de ernst van beide zaken vergelijkt.

[Dennism]

In hoeverre is dat relevant dit te benoemen onder een nieuws artikel over AMD. Kritiek op Intel m.b.t. security plaats je bij een nieuws artikel over Intel, bijvoorbeeld wanneer er nieuwe lekken ontdekt worden.
Niet compleet willekeurig onder een nieuws artikel over Linux in combinatie met AMD cpu's. Intel veiligheidslekken zijn in deze context totaal niet relevant, het is dus ook vrij logisch dat die hier niet benoemd of vergeleken worden.

Verhoudingen lopen dan wel erg scheef kwa ophef als je de ernst van beide zaken vergelijkt.

En daarom vergelijk je deze zaken dus ook niet, daar valt geen enkele zinnige vergelijking over te maken. Het zijn 2 compleet verschillende zaken, die naar mijn mening beide kritiek verdienen, echter Intels veiligheidslekken zijn hier compleet offtopic en behoren hier dus ook niet besproken te worden.

[Reactie gewijzigd door Dennism op 22 juli 2024 13:48]

[uiltje]

Zo groot is dat team volgens mij niet. We hebben het hier over een boot die niet werkt. Je hebt een nieuw bord met nieuwe CPU liggen, je bent verantwoordelijk voor het testen van Linux, en je boot de laatste versie van het meest populaire Linux platvorm niet eens op? Serieus?

Of ze hebben het wel gedaan, geconstateerd dat er een probleem is en het daarna onder de pet gehouden natuurlijk. Die launch hadden ze er niet voor vertraagd of aangepast.

[SuperDre]

Kan natuurlijk goed zijn dat het met een eerdere testversie wel werkte, maar juist met de allerlaatste niet. Zolang niet bekend is wat er aan de hand is, valt er niet zoveel over te zeggen.

[svenk91]

Of de test procedure was al afgerond voor de laatste releases waar dit probleem zich voor doet. Als de linux engineers redelijk onder druk staan (geen idee of dat zo is, een veronderstelling) dan kan ik mij goed inbeelden dat ze niet nog steekproefsgewijs hele recente distributies extra kunnen testen als dit niet in de planning was opgenomen.

[Jasper Janssen]

19.04 is pas net uit. Laaaang nadat die CPU getest was en vastgezet.

Toen deze CPU voor het laatst taped out is was 18.04 wsch de nieuwste versie.

[tweaknico]

laatste versie is niet belangrijk, LTS support wel.

[bartje]

Ik weet het niet zeker maar volgens mij zijn de hardware fabrikanten zelf verantwoordelijk voor de ondersteuning in de kernel.
Wat inhoudt dat het isseu door het Linux team van AMD gefixed dient te worden niet door het Linux kernel team.

[Cergorach]

Als ik het bron artikel lees, dan lijkt het niet aan de kernel te liggen, maar aan wat anders...

[kozue]

Het zou inderdaad ook in systemd kunnen zitten (dat was iig mijn indruk na het lezen van de tweakers.net versie), maar in 1 van hun screenshots staat er ook een page fault en dat lijkt wel degelijk op een probleem met geheugenmanagement in de kernel. Ik vind het nog te vroeg om conclusies te trekken, maar ben wel benieuwd naar de uitkomst van het onderzoek naar het onderliggende probleem...

[Jasper Janssen]

Hardware fabrikanten zijn helemaal nergens “verantwoordelijk voor”. Ze hebben engineers in dienst die bijdragen aan het ontwikkelen van diverse FOSS projecten met als doel om hun eigen spul beter te laten draaien, maar daar zijn ze niet toe verplicht.

[himlims_]

"AMD has said their testing has been mostly focused on Ubuntu 18.04 given its LTS status."
^-- dat dus

en daar werkt ie dus ook op.

[Reactie gewijzigd door himlims_ op 23 juli 2024 09:44]

[RJG-223]

Dat kan je doen tijdens de lunch tussen de opdrachten door.

Ja. En de volgende keer besteden ze een uurtje met het booten van alle belangrijke linux distributies en kernels, en dan gaat dat goed. Hoera! En dan blijkt dat zo'n machine na tien minuten crasht. En dan zeg jij weer: had zo'n machine dan ook gewoon tien minuten laten draaien. En dan crasht ie de volgende keer na een uur. Of na het opstarten van een webserver. Of een database server. Of na het opstarten van libreoffice. Of ... etc. etc. etc. En voor je het weet ben je toch een volledige batterij testen aan het uitvoeren, omdat elke van die afzonderlijke tests 'er toch wel even bij' kon.

Moraal van het verhaal: Als er geen reden is om iets specifiek te testen, dan heeft het ook geen zin om heel specifiek één testje te doen. De kans dat die een bug aantoont is dan minimaal, terwijl de echte bug zit in iets wat je ook makkelijk had kunnen testen, maar wat je dus niet 'eventjes' getest had.

In het geval van AMD: ze hebben een testbudget, en als ze dat gebruiken om één populaire distributie (of twee) uitgebreid te testen, dan is de kans dat een andere distributie problemen geeft minimaal. Maar niet nul. Zo is het leven nu eenmaal. Binnen een of twee weken is dit opgelost, en binnen evenzoveel maanden zal het al bijna vergeten zijn, en is iedereen over tot de orde van de dag.

[JohanNL]

Dit is gewoon het risico met nieuwe hardware, maar ook software.
Even een half jaartje wachten en de meeste kinderziektes zijn er wel uit, en bij AMD weten we dat ze ook best snel wel aan prijsverlagingen doen

[HollowGamer]

Waarom werkt die nieuwe hardware dan wel op Windows inclusief performance upgrade in laatste versie? En dat zonder eerst een half jaar te moeten wachten.

Het geeft een beetje aan waar de prio's liggen. Opzicht wel vreemd omdat AMD voor de recent uitgekomen GPU's wel ondersteuning al in de (open) amdgpu module heeft zitten, dacht al twee weken of meer van te voren zelfs. Dat dit dus voor de CPU's niet geld is een beetje vaag. Moet toegeven dat ik het niet zelf heb getest, maar op nieuws dat ik heb gelezen op Phoronix.

Je hebt zeker gelijk hoor, verwacht ook dat het goed komt. Zo heeft Intel ook veel opstart problemen gehad met hun Skylake CPU op Linux (kan daar over meepraten.. booten zonder C-states o.a. ) en ook met latere families was dat (altijd) zo (Bay Trail - al blijft die hele chipset slecht op Linux), echter vraag je af waarom ze dit niet even testen of het werkt en mogelijk aanpassingen in de Linux-kernel nodig zijn. We moeten niet meer doen als Linux een ondergeschoven kindje is, sterker nog in de developer wereld zijn ze wat ik lees flink aan het groeien.

[Reactie gewijzigd door HollowGamer op 23 juli 2024 09:44]

[SuperDre]

Ja, logisch toch dat de prio's liggen bij eerst de grootste groep (Windows), dan de groep die daarna komt (Linux LTS versies) en dan pas de allerlaatste versies. En CPU's en GPU's zijn natuurlijk wel compleet verschillende dingen/afdelingen.
Het probleem is er bij de allerlaatste versies van Linux, en dat zal ook wel weer snel opgelost worden waarna we weten waar het probleem nu werkelijk lag.
De prioriteit ligt bij OSsen die werkelijk voor (zakelijke) productie gebruikt worden, en bij Linux betekent dat dus LTS versies.

[RJG-223]

Waarom werkt die nieuwe hardware dan wel op Windows inclusief performance upgrade in laatste versie? En dat zonder eerst een half jaar te moeten wachten.

Zou het kunnen zijn omdat we dat half jaar wachten op die performance upgrade al achter de rug hebben...

[Wingman555]

Fedora Workstation 31...?!? die is nog niet eens in Alpha fase.
dus ik snap best goed dat die mogelijk issues heeft. komt vast goed.

Maar ben wel benieuwd of het dan ook zo is met de huidige Fedora Workstation 30. Want daar draai ik momenteel mee, op mijn oude FX8350je, en ben best geinterreseerd in een upgrade naar een R7-3700x systeem.

daar kan ik niks over vinden in het artikel (alleen dat oudere versies geen problemen vertonen) maar Fedora WS 30 is net als Ubuntu 19.04 al uit, en recent maar zeker niet 'oud'...

Zal nog even op meer testen en reviews wachten (of een fix die het fixed) voor ik een 3700X systeempje ga bestellen.

[sfranken]

En ander straks de mainline kernel installeren op je Fedora machine.

Let wel: there be dragons, maar dat spreekt voor zich

[Vuurvoske]

Ik vind het persoonlijk wel een gemiste kans van AMD. Maargoed het probleem zit hem waarschijnlijk in de vernieuwde architectuur van de processor waar de kernel (nog) niets mee kan. De linux community kennende is het een kwestie van tijd voordat dit euvel is verholpen.

[Reactie gewijzigd door Vuurvoske op 23 juli 2024 09:44]

[Cybermage]

Oeps kan je wel zeggen ja. Ander kant wie ubuntu 19.x en fedora 31 al gebruiken voor hun dagelijks werk is zeker niet verstandig want dat zijn imho testlabs.

[RobinJ1995]

19.04 is gewoon gereleased hoor.

[Cybermage]

Klopt mee eens maar die versie zitten nog zodanige kinderziekte in dat je het gewoon moet beschouwen als testlab. bij canonical weten ze gewoon niet wat ze doen en doen ze naar mijn beleving het image van linux meer kwaad dan goed.

[psychicist]

Ik zie weinig kinderziektes in Ubuntu 19.04 AMD64, ARM64 en PPC64LE, dus je kunt niet zomaar stellen dat Canonical niet weet waar het mee bezig is. Het is gewoon een bug die getriggerd wordt in combinatie met bepaalde hardware die nog niet uit was, toen de distributie uitkwam.

Er zal vast een oplossing voor komen in een toekomstige versie van Ubuntu, maar op dit moment is het aan te raden in ieder geval op deze hardware Ubuntu 18.04 LTS of een andere distributie te gebruiken.

[Cybermage]

Zoals ergens in een post al weer aangehaald gebruiken maar weinig een non LTS versie. Dat heeft een dikke reden dat je maar korte tijd support krijg. Je verplicht na een jaar of 2 moet upgraden naar nieuwe versie die weer alles overhoop gooit. Kortom een non LTS versie is zowiezo kruis bij ubuntu. Dan heb ik een andere grote tekort koming die je kan tegenkomen die je bij fedora niet hebt. Probeer maar eens nvidia videokaart drivers te installeren en dan regelmatig kernel updates. Daar ben je bij ubuntu gauw van genezen.

[Reactie gewijzigd door Cybermage op 23 juli 2024 09:44]

[psychicist]

Ik gebruik non-LTS versies op secundaire hardware en in virtuele/geëmuleerde QEMU machines, wanneer het belangrijker is om de nieuwste software te hebben draaien dan om absolute stabiliteit te garanderen. Daarnaast heb ik ook LTS versies geïnstalleerd op mijn primaire hardware als in virtuele/geëmuleerde QEMU machines.

Voor anderen installeer ik inderdaad altijd LTS versies, als ik er zeker van ben dat alles goed werkt. Zij hoeven niet echt de nieuwste software te draaien en zo kunnen ze er 2 jaar mee vooruit. Onder Kubuntu 18.04 LTS heb ik nu de CUDA software geïnstalleerd, waar ook de nvidia closed driver bij zit. Ik heb het afgelopen jaar al meerdere kernelupdates voorbij zien komen zonder problemen.

Fedora heb ik sinds de Fedora Core 1 niet meer op mijn hardware geïnstalleerd, dus daar kan ik niet veel over zeggen. Wat ik wel weet is dat er een probleem was met de Radeon driver, waardoor het beeld veel te helder was en dat de proprietaire AMD fglrx driver de machine constant liet crashen. Toen heb ik Slackware maar geïnstalleerd en dat tot 2010 gebruikt naast Solaris/Opensolaris en OpenBSD.

[Cybermage]

Fedora core 1 was toe net afgesplitst van redhat Denk als je het nu installeerd dat je het niet meer herkend zoals het toen was. Op word dit moment herkend het AMD out of the box van de week een oude kaart erin gepropt en gaan. Met rpmfusion werken ook nvidia kaarten gewoon mee heb een 1080ti werkend ondanks dat er wekelijks kernels updates langsvliegen. En dan bedoel ik dus niet patchen maar complete nieuwe kernels. MIjn ervaring is dat fedora erg dichtbij de laatste stabiele kernels ziet. Dit in tegenstelling tot ubuntu die gewoon blijft zitten waar het zit en af en toe een patch overheen gooit.
Verder draai ik dus wel ook veel ubuntu 18.x LTS in KVM want het blijft ondanks ik vind dat het tekort komingen heeft tbv upgraden een referentie os.

[RobinJ1995]

En Microsoft weet wel waar het mee bezig is? Elke 2 maanden tegenwoordig wel een nieuwsbericht over updates die gebruikersdata verwijderen of systemen unbootable achterlaten.

Het is gewoon de natuur van software. Er zijn zoveel verschillende hardwareconfiguraties (hier hoeft Apple zich bijvoorbeeld geen zorgen om te maken) die zich allemaal net wat anders gedragen, en verschillende combinaties van software die mensen gebruiken die niet allemaal even goed geschreven is, dat het gewoon onmogelijk is een waterdicht systeem te maken. En waar Microsoft dan een groot bedrijf is met vrijwel onbeperkt budget tot zijn beschikking, moet Ubuntu het hebben van vrijwilligers. Ik heb niet het idee dat Ubuntu echt meer bugs heeft dan Windows (tegenwoordig), wat best indrukwekkend is, maar je ervaring hangt gewoon heel erg van je hardware af. Mijn moeder met haar Thinkpad heeft praktisch geen enkel probleem met Ubuntu, waar ik met mijn MSI soms de vreemdste bugs tegenkom (maar goed, de Windows 10 installer crasht ook gewoon compleet op dat ding tot ik die tweede SSD die ik er zelf bij in heb gestopt er uit haal 😂). Hardware en drivers zijn over het algemeen het de grootste veroorzakers van problemen.

[Cybermage]

Micorosoft weten en bezig ahum daar heb ik al eens wat postings over geschreven en er is een reden dat ik klaar me ze ben. Krijg om de 2 weken de insiders previews te zien en tot nu toe word ik ondanks dat ze wsl2 aangezet hebben nog echt niet wild van. Ook windows 10 blijft voor mij een refentie os om te blijven experimenteren maar dan virtueel in KVM.
Ubuntu en vrijwilligers laat me niet lachen. Canonical is gewoon een commericeel bedrijf en je kan ze met microsoft rustig kwa houding vergelijken. Commercieel belang boven wat technisch nodig is en niet of te laat luisteren naar de klanten is het resultaat. Iemand kan zich recent nog herinderen wat ze wouden doen met 32bits liberaries zodat die niet mer zouden draaien met proton / steam? Dat hebben ze na veel gezeik pas gedeeltelijk teruggedraaid.
Bij fedora is het toch echt wel een verschil. Heb diverse bugs aangemeld en daar word geluisterd naar je.
Temminste dat gevoel geven me wel. Heel simpel ondanks dat nu ondeel van ibm zijn doen vind ik erg goed. Ondanks dat ik geen betaald support account heb bij redhat of zo. Dus bedrijven kunnen het wel! Heb fedora nu op 3 soorten hardware gedraaid. Een Threadripper / Een thinkpad laptop /
en een atom minipctje. Allemaal draaid het fedora uit de kunst. Wel updaten is het devies.

[Reactie gewijzigd door Cybermage op 23 juli 2024 09:44]

[sfranken]

Technisch gezien is Fedora los van Red Hat en dus *geen* onderdeel van IBM. Mocht de Council het willen zijn ze volgende week los van hun 'grote neef' en is het een eigen distro weer. Tuurlijk, zullen ze niet doen, maar de mogelijkheid is er.

We weten allemaal dat Fedora (gebruikers) gewoon de nieuwste RHEL testen, of features uit RHEL (welke in RHEL gaan komen). Is niks mis mee.

Ik draai Fedora op alles van oude Macbooks tot mijn game PC tot mijn werklaptop(s). Draait prima :-)