Nieuwe Linux-kernel wordt begin maart verwacht

Vermoedelijk begin maart zal de nieuwe Linux-kernel 2.6.33 worden uitgebracht. In de nog in aanbouw zijnde kernel zal Nouveau worden opgenomen, een reverse-engineered driver voor videokaarten met een Nvidia-gpu.

De opensource Nouveau-kernelmodules moeten een alternatief gaan vormen voor de propriëtaire code in de Linux-drivers van Nvidia. Kernel-ontwikkelaar Jonathan Corbet stelt in een toelichting op de voortgang van de nieuwe kernel dat het Nouveau-project, waar jarenlang aan gewerkt is, een 'meesterlijk staaltje reverse-engineering' is, mede omdat Nvidia vrijwel geen informatie over de precieze werking van zijn gpu's vrijgeeft. In december werd bekend dat de code van Nouveau werd geaccepteerd als module voor Linux-kernel 2.6.33.

Een andere vernieuwing die in de kernelcode zal zijn te vinden, is het ftrace-mechanisme. Met ftrace kunnen programmeurs gedetailleerd inzage in kernelprocessen krijgen, al is de tool nog niet geheel klaar. Volgens Corbet is ftrace vergelijkbaar met dtrace in Solaris en zijn dergelijke tools onmisbaar in kritische bedrijfstoepassingen, zoals de betaalsystemen van banken of het serverpark van grote internetfirma's.

Inmiddels is kernel 2.6.33, bestaande uit bijdragen van meer dan tweeduizend vrijwilligers, aangekomen in de testfase; op 12 januari werd door Linus Torvalds nog RC4 aangekondigd. Naar verwachting zal kernel 2.6.33 begin maart de definitieve goedkeuring krijgen, waarna de ontwikkelgemeenschap zijn tanden kan gaan zetten in de bouw van kernelversie 2.6.34.

Reacties (96)

[Left]

Wat is nou het grote voordeel van zo'n reverse engineered NVidia driver? Je mag toch aannemen dat Nvidia's eigen drivers het beste werken om zij het beste op de hoogte zijn van alle ins en outs van hun videokaarten?

[jiriw]

Je bent voor proprietary/gesloten drivers natuurlijk wel afhankelijk van de fabrikant ... NVidia. Als ze besluiten een kerneltje over te slaan of helemaal met support te stoppen dan heb je een probleem. En zoals hier boven wordt aangegeven, zij bepalen welke features ze in Linux willen ondersteunen. Als zij geen goed gevoel hebben over, zeg, de veiligheid van DRM media in Linux, dan komt er geen HDMI support zodat je 'legaal' afspelen van je BLU-raytjes in HD formaat wel kan vergeten. (Ik weet even niet of dat sowieso ooit mogelijk gaat worden maar het is maar een voorbeeldje)
Dit is overigens niet puur een Linux probleem... gebeurde ook met, zeg een Windows Vista. Hoe lang het daar geduurd heeft voordat sommige (grote) fabrikanten goede drivers beschikbaar hadden... Denk aan een Creative...
En dan is er natuurlijk nog het GPL 'probleem' met gesloten kernelmodules. Als je gesloten kernelmodules aan je kernel hangt dan wordt een kernel 'tainted'. De module wordt onderdeel van de kernel, kan alle kernel datastructuren veranderen, en omdat er geen debugsymbolen van de module beschikbaar zijn (omdat, als die uitgegeven zouden worden deze onder GPL MOETEN vallen, iets waar een gesloten driverfabrikant niet op zit te wachten) kan je in de gehele kernel geen fouten meer opsporen tenzij je zin hebt om op assembly niveau te gaan zitten debuggen.
Ook ben je met een gesloten module afhankelijk van een precieze definitie van de kernelstructuren die je gebruikt en de kernelmoduleinterface, Als daar iets in verandert (er komt een veldje bij in een van de kernel structs voor, weet ik veel wat voor een functionaliteit die misschien niet eens van toepassing is op het aansturen van grafische kaarten) kan je je module niet meer in de volgende kernel laden. Terwijl je vaak met een recompile van de code zo weer een goed werkende module zou hebben gehad. Maar ja, jij kan dat niet, alleen de fabrikant.

[YaPP]

Wat is nou het grote voordeel van zo'n reverse engineered NVidia driver? Je mag toch aannemen dat Nvidia's eigen drivers het beste werken om zij het beste op de hoogte zijn van alle ins en outs van hun videokaarten?

Denk maar aan Windows Vista, waar we lang hebben gewacht op goede drivers. Microsoft kan die problemen niet oplossen.

De kracht van Linux is vrijheid en onafhankelijkheid.

Een Open Source driver biedt de volgende mogenlijkheden:
- bugs kunnen direct door de kernel ontwikkelaars aangepast worden.
(de Linux kernel is het grootste Open Source product op deze planeet!)
- dubbele code tussen video drivers kan op een centrale plek gezet worden.
- nieuwe kernel functies (suspend, mode switching, aanpassingen voor X.org) kunnen direct in de drivers verwerkt worden)
- bij aanpassingen aan de API van de kernel kunnen drivers direct geport worden,

Ofwel, bij het uitkomen van een nieuwe Linux versie, of kernel versie, werkt je apparatuur direct al!


Met de huidige closed source driver:
- moeten distributeurs wachten met nieuwe X-server versies totdat NVidia de driver heeft aangepast.
- kan Linux alleen worden uitgebracht met hardware / software die NVidia support.
- kan niemand Q&A uitvoeren, behalve het team binnen NVidia zelf
- kan bij crashes ("blue screen") niemand dit oplossen, behalve dit melden en hopen dat het team binnen NVidia er tijd voor heeft.
- heeft hibernate lang niet goed gewerkt, omdat NVidia het niet ondersteunde.
- heeft compositing + ARGB visuals (aka Windows Vista effecten) lang niet goed gewerkt.
(wat KDE 4 zo ontzettend traag maakte)
- gebruikt ieder OpenGL proces 11MB extra geheugen omdat de binary niet gecompileerd wordt als position-independant-code (PIC). (wat KDE 4 meer geheugen liet gebruiken bron)
- kan niemand oude hardware ondersteunen als NVidia daar geen waarde in ziet.

Zelf vind ik de NVidia drivers van een goede kwaliteit, en heb ik er veel plezier van gehad. Met het bovenstaande lijstje kun je je misschien voorstellen dat dit niet voor iedereen zo is, en dat ontwikkelaars graag verbeteringen zien in het proces, zodat ze de kwaliteit nog verder en sneller omhoog kunnen krijgen.

Wat de kernel ontwikkelaars aangeven, is dat ze liever documentatie ontvangen over de hardware. Daarmee kunnen ze kosteloos de driver blijven onderhouden en supporten. Voor een fabrikant is dat uiteindelijk een goedkopere oplossing (ze verdienen geld met hardware, niet met drivers supporten). Alleen in het uiterste geval dat een fabrikant geen documentatie of open driver levert, is reverse-engineering de oplossing om toch een Open Source driver te maken.

Zie ook:
http://www.linuxfoundatio...ions/linux-graphics-essay

[Reactie gewijzigd door YaPP op 23 juli 2024 05:17]

[page404]

volgens mij draaien de eigen drivers niet 'native' of gewoon helemaal niet, simpelweg omdat er geen specifieke linux-drivers uitgebracht worden door nVidia.

[The Flying Dutchman]

Onder welke steen kom jij vandaan?

nVidia brengt al jaaaaaaaaaaaaaarenlang drivers uit voor Linux, net zoals AMD dat doet. De drivers die nVidia uitbrengt zijn daarnaast overigens ook van hele behoorlijke kwaliteit, daar waar AMD (eigenlijk vooral toen het nog Ati was) nogal wat te wensen overliet aan de driver kwaliteit. Momenteel is AMD bezig met een flinke inhaalslag op driver gebied. Persoonlijk ben ik erg tevreden over de AMD drivers.

Wist je dat nVidia zelfs drivers uitbrengt voor BSD?

Het voordeel van de nouveau drivers is dat ze opensource zijn. Dat is heel belangrijk voor sommige mensen. Daarnaast heb je met een opensource driver volledige controle over de ondersteuning. Stel dat nVidia plotseling besluit om een oude serie videokaarten niet meer te ondersteunen in de nieuwe Linux versies. Dan heb je een probleem als je zo'n oude videokaart hebt. Met de opensource drivers bestaat dit probleem niet. Desnoods schrijf je namelijk zelf de patch! (maar over het algemeen wordt oudere video hardware heel behoorlijk ondersteunt door de community)

[Anoniem: 28958]

Stel dat nVidia plotseling besluit om een oude serie videokaarten niet meer te ondersteunen in de nieuwe Linux versies.

Dit is al gebeurd met diverse kaarten. Daarop is hun hele business model gebaseerd (en dat van de hardware industrie in het algemeen). Als hardware eeuwig meegaat, hoeft het niet zo vaak vervangen te worden en is er dus minder omzet. Dit is vooral het geval voor hardware waarin geen enkele innovatie is gedaan de laatste 10 jaar, zoals bijv. geluidskaarten.

[Anoniem: 95522]

geen enkele innovatie in geluidskaarten? misschien in ONBOARD geluidschipcodecgevalletjes... Maar ik noem, Dolby Digital Live, DTS interactive, de overstap van DxSound naar OpenAL (ok die was wat gedwongen maar toch), betere Opamps, Realtime oppoetsmogelijkheid voor MP3's etc etc etc etc etc...

[Anoniem: 196662]

Allemaal zeer belangrijk voor gemiddelde luidsprekerset van max €50. Heel ander verhaal bij cpu, hdd, gpu, ... waar simpelste ziel tot raketwetenschapper grote en impactrijke stappen heeft gezien en kunnen gebruiken.

[BeosBeing]

Kijk, zijn we het voor de verandering wer een keertje eens met elkaar.
Sinds de onboard geluidchip standaard werd, is de consumenten-geluidskaartenbranche die op dat moment 24 bits op samplingfrequenties van 96kHz bij opname en 192kHz bij weergave was beland, geheel stil gevallen.

Voor de discrete geluidskaarten die rond die tijd uitkwamen werden toen ook al enkel nog drivers gemaakt voor de meest recente Os-sen. WinXP was amper een jaar op de markt, en Creative bracht voor haar nieuwe geluidskaarten geen drivers meer uit voor WinME. Ik heb toen mijn OEM-geluidskaart maar verkocht aan iemand die wel WinXP had.

[Anoniem: 28958]

Ik geloof niet zo in dit soort reacties. Vertel eens in detail wat er nu zo nieuw is aan een willekeurig onderdeel van je reactie.

De kaarten van Creative waren al programmeerbaar in die tijd en dus was een firmware upgrade ook genoeg geweest en volgens mij is het tegenwoordig zo dat al het geluid ook al in software uitgevoerd kan worden.

[Anoniem: 282252]

De driver van nVidia worken niet goed samen met een RTOS (RTAI) bijvoorbeeld, dan zou het wel eens handig kunnen zijn dat er een vollsige accelerated open source vesie komt.

Ries

[page404]

steen? steen? het is meer dat ik dingen door elkaar aan het halen ben spuit elf he...

[Vorlon]

Er worden wel linux-drivers uitgebracht alleen dat zijn binaries. Dus alleen voor de platformen die ze zelf ondersteunen.

En aangezien er geen source van is kan je ze ook niet porten naar een ander systeem.

[MBV]

NVidea's driver gaat stuk bij elke kernel-update, en bij elke verandering van interfaces wacht NVidea erg lang met de driver updaten. Als hij opensource is, wordt hij door degenen die de interfaces veranderen direct meegenomen en zal dus meestal blijven werken.
Daarnaast hebben Linux-ontwikkelaars een pesthekel aan closed-source drivers, terwijl dat voor videokaarten niet eens zo'n gek idee is. Geen support op kernels waar een closed-source driver geladen is enzovoort.

[humbug]

Dat is natuurlijk het gevolg van keuzes die de kernel ontwikkelaars zelf maken. Vrijwel elk OS hecht aan stabiele interfaces. De linux kernel ontwikkelaars kiezen voor de vrijheid om het te kunnen wijzigen wanneer ze willen wetende dat de drivers elke keer moeten worden aangepast. In mijn ogen betekent dat ofwel onkunde (Kan men niet een interface bedenken die wat langer mee gaat? Kijk bv eens bij Open Solaris hoe het wel kan) ofwel pure onwil. Beide situaties zijn nogal ongewenst en je zou verwachten dat men een oplossing zou vinden.

[35MHz OC]

Of optie drie. Binaire drivers zijn een schending van de kernel licentie. Door geen stabiele interfaces te scheppen, wordt o.a. de mogelijkheid van het schenden van de licentie tot een minimum beperkt.

NVidia en consorten hebben gewoon mazzel dat Linus Torvalds het schemergebied waarin de huidige drivers zich bevinden oogluikend tollereert.

[ppl]

Als Linus het ooglijkend toestaat heeft dat helaas wel juridische gevolgen waarbij het zeer waarschijnlijk niet meer mogelijk is om te beroepen op schending van de kernel licentie. In dit geval is er echter geen sprake van een GPL schending omdat de GPL wel het gebruik van closed source software toestaat (hoewel hier nog wat controverse over bestaat en niet iedereen het als iets legaals ziet). Nvidia maakt van die clausule handig gebruik door een open source deel voor de kernel te schrijven die daarna een closed source deel gebruikt. Overigens is "binaire drivers" ook een volledig onjuiste woordkeuze omdat je hier closed source bedoeld. Binaire zaken zijn nogal cruciaal voor een computer en vindt je ook terug in open source. Kijk maar eens naar de diverse packagesystemen die Linux rijk is

Optie 3 is nogal gebaseerd op onwaarheden en mag dus helemaal opnieuw. Dit hele verhaal doet overigens niets af aan het verhaal van humbug: gewoon een algemene interface die eens niet bij iedere versie wijzigt waardoor zowat alles op de schop moet zou zeer wenselijk zijn.

@ Rizon: ja dat is in heel vaak wel legaal maar dan moet je je wel aan alle mitsen en maren houden. Vaak is het iets in de zin van: de ene puzzelt en documenteert, de ander pakt de documentatie en maakt op basis daarvan een implementatie. Direct mag vaak niet. En dan is er nog reverse engineering voor educatieve doeleinden wat ook weer zoiets is.

[Reactie gewijzigd door ppl op 23 juli 2024 05:17]

[Katsunami]

Linus Torvalds en consorten hebben gewoon mazzel dat bedrijven als nVidia drivers schrijven voor een OS waarvan de kernel continu verandert en dat slechts 1% van de desktopmarkt bedient.

[Anoniem: 196662]

En reverse engineeren is wel legaal in de westerse wetboeken...

[_Pussycat_]

@ Rizon:

Ja, want het Nouveau-team maakt gebruik van 'clean-room reverse engineering'. Dit houdt in dat één team de driver van nVidia analyseert en daaruit een spec van de nVidia-hardware maakt. Een tweede team schrijft dan de driver voor de hardware. Daardoor wordt er gegarandeerd geen code van nVidia gejat.

[Anoniem: 196662]

Reverse engineeren gaat niet enkel om code stelen. Het ontwerp zelf is ook beschermd en ontleden is zelfs vaak al strafbaar.

[BeosBeing]

Als nVidia graka's wilt verkopen moet ze drivers aanbieden, dat geld zowel voor Windows als voor Linux. Doen ze dat niet, dan is de hardware onbruikbaar.

Ondanks eventueel auteursrecht op de code van de driver is het slechts een hulpmiddel om de hardware aan de gang te krijgen.

Dat geldt ook voor eventuele specificaties van de interfaces van gpu en graka. Het enige doel is om de hardware bruikbaar te maken. Het alternatief is dat gebruikers geen nVidia meer kopen, en daar is nVidia zeker niet bij gebaat.

Nou is de Linux-gebruikersgroep (en xBSD, Haiku, enz) mischien niet zo groot, maar blijkbaar groot genoeg voor nVidia om er rekening mee te houden.

[Goderic]

Nee optie drie is: De Linux kernel ontwikkelaars vinden dat een interface die veranderd beter dan eentje die niet verandert. En aangezien de drivers toch in de kernel zitten is dat helemaal geen probleem.
Als er dan mensen zijn die een driver (om welke reden dan ook) niet in de kernel steken moeten ze hun problemen zelf maar oplossen.

En als je wilt weten waarom ze dat beter vinden: http://www.mjmwired.net/k...n/stable_api_nonsense.txt

edit:
spellingcorrectie

[Reactie gewijzigd door Goderic op 23 juli 2024 05:17]

[ATS]

Aan de andere kant: het is natuurlijk bizar dat er voor elke kernel update of X update weer een nieuwe driver nodig is. Ik weet het, daar wordt aan gewerkt om wat aan te doen, maar in feite is dat natuurlijk too little, too late.

[blouweKip]

Dan kun je ook beter de driver van nvidia gebruiken, die heeft de problemen die jij schetst niet

[Goderic]

Juist wél, de kernelinterface veranderd maar de Nvidia driver niet dus er is een probleem.

@ mstreurman
Kan best zijn, maar dan heeft hij het nog steeds fout. De drivers van Nvidia hebben dat probleem net.

[Reactie gewijzigd door Goderic op 23 juli 2024 05:17]

[Anoniem: 95522]

hij wees op een veelgemaakte spellingsvaud

[Anoniem: 325409]

nVidia's drivers zijn ver van optimaal. Waarschijnlijk zal dit een stuk sneller draaien. Jammer, want ik ga zodadelijk een ATI kaart kopen.

[johnbetonschaar]

Dat is echt onzin, de Linux nvidia drivers zijn exact hetzelfde als die op Windows met uitzondering van de koppeling met de kernel. Uit benchmarks blijkt zelfs vaak dat de Linux drivers nog beter presteren dan onder Windows (door OS verschillen).

Dat de nouveau drivers sneller zouden zijn is ook klets, ze zijn al lang blij dat het uberhaupt werkt, maar dezelfde feature set en performance die Nvidia in zijn binary drivers haalt gaan ze nooit en te nimmer bij in de buurt komen.

Zoals gezegd zijn de grootste (enige?) voordelen van een open-source driver dat je geen 'onbekende' binary's op je systeem hoeft te installeren (vooral een ideologisch voordeel dus), dat je drivers blijven werken bij kernel of X upgrades (en dus niet op Nvidia hoeft te wachten), en dat de ontwikkelaars flexibeler kunnen zijn in de interactie met andere systeem onderdelen.

Edit:
Nog 1 tip: als je linux gebruikt zou ik maar gewoon voor een Nvidia kaart met de Nvidia drivers gaan, want daar haal je de meeste performance en features uit met het minste gezeik. ATI op linux is redelijk ruk als je aan GPU performance en features hecht. De ATI binary drivers staan niet echt goed bekend als snel, stabiel of compleet, en de open source drivers ondersteunen alleen oudere kaarten en kunnen lang niet alle features van de hardware gebruiken.

[Reactie gewijzigd door johnbetonschaar op 23 juli 2024 05:17]

[Ventieldopje]

Jammer dat je een ATI kaart gaat halen, die drivers zijn pas verre van optimaal! Nvidia heeft het goed voor elkaar onder linux en games via Wine werken vaak even goed zo niet nog beter dan onder windows

[KillerSponge]

Qua prestaties waarschijnlijk wel ja. Qua integratie met de rest van het systeem, not so much.

[HerrPino]

Het geeft mij persoonlijk niet echt veel vertrouwen in de stabiliteit van het geheel. Bij het reverseengineren hoef je maar 1 cruciaal dingetje over het hoofd gezien te hebben. Ik neem aan dat ze hebben geprobeerd om de videokaart oververhit te krijgen mbv hun drivertje maar geef mij toch maar de driver van NVidia zelf.

[cumulus007]

Daarom is men dus vele jaren bezig met het ontwikkelen van de driver. O.a. om te testen.

[ari3]

Soms blijken drivers opeens minder features te hebben dat hun Windows equivalent. Zo hebben ATI en Intel wel HD video decoding op de IGP in Windows, maar niet onder Linux en *BSD. Daarom is het belangrijk dat men de specs en/of broncode vrijgeeft om implementaties te maken die alles uit de hardware halen wat er in zit.

Ook zijn open source drivers handig om Macrovision en DRM-meuk uit de drivers te halen.

[_JGC_]

Niet alleen dat, maar ook het feit dat binary drivers moeilijk te debuggen zijn. Elke keer als er een nieuwe versie van X uitkomt is het weer wachten op nieuwe binary drivers die ermee compatible zijn.
Als die drivers er vervolgens zijn werken ze niet of niet goed, en staan alle partijen naarelkaar te wijzen, omdat niemand goed kan zien wat er gebeurt in een binary driver.

[rulus]

Klopt. Maar de mensen achter Nouveau zijn dan weer beter op de hoogte van de ins en outs van de kernel. Ook niet onbelangrijk

[Anoniem: 95522]

dat de reversed engineered driver Open Source is en dat men bepaalde dingen die niet in de "standaard" driver zitten zelf kunnen gaan toevoegen of zelfs "niet-bestaande" functionaliteit toe kunnen voegen. Daarnaast kan men de code gaan optimaliseren zodat hij misschien wel beter/stabieler/sneller is dan de officiële driver

[Rob Coops]

Het aller grootste verschil is dat de extremisten onder ons eindelijk ook Nvidia kaarten kunnen kopen. Met extremisten bedoel ik de mensen die onder geen beding ook maar iets op hun systeem willen hebben dat niet open source is en juist voor hun is het erg fijn dat er een driver voor Nvidia is die wel gewoon open source is zo dat ze er zeker van kunnen zijn dat er geen kwaad willende code in zit en geen bugs etc. (ook al zullen de meeste toch geen wijs woorden uit 99% van de code, maar goed dat zijn details het gaat om het princiepe)

Het andere grote voordeel is dat de driver nu veel beeter geintegreerd kan worden omdat men nu ook de binnen kant kan zien en waarschijnlijk dus ook wel hier en daar een kleine verbeterign kan door voeren.
Of de prestaties er ook op voor uit gaan, geen idee die kans is er natuurlijk altijd maar eerlijk gezed denk ik dat Nvidia inderdaad beter weet hoe hun product werkt dan dat de open source community dat zal doen. Ook denk ik dat de open source community altijd achter Nvidia aan zal moeten rennen wat betreft ondersteuning van nieuwe chips en zo.

Maar goed de puristen zijn blij en de wereld is weer een stukje veiliger nu we zeker weten dat er geen kwade code in de Nvidia drivers zit. Maar uit eindelijk lijkt het me toch aan te raden om zeker als je van de nieuwste kaarten gebruik wilt maken gewoon de echte Nvidia driver te gebruiken omdat je anders best wel eens teleurgesteld zou kunnen worden wat betreft ondersteuning etc.

[SirBlade]

[aluhoedjesmode]
Die kwade code zit vast in de firmware....
[/aluhoedjesmode]

[MaestroMaus]

[Disclaimer: ik ben geen expert, dus ik kan me vergissen]
NVIDIA's (en anderen) gesloten drivers zijn expres grotendeels multi-platform gemaakt om zo efficiënt te kunnen werken. (bron: http://www.phoronix.com/s...tem=nvidia_qa_linux&num=1)

Dit levert echter bepaalde beperkingen op onder Linux. We kunnen bijvoorbeeld met deze drivers er niet voor zorgen dat normale zaken als bijvoorbeeld de desktop-compositie mooi vloeiend verlopen.

Verder hebben we speciale zaken zoals KMS (kernel mode setting) die Windows en Mac niet hebben en dus niet ondersteund worden.

Ook verandert de software waarmee de gesloten drivers moeten praten erg snel en de driver-programmeurs hebben veel moeite om alles bug-vrij te houden (dat zijn ze nooit) (bron: eigen ervaring en http://www.nvnews.net/vbu...mdisplay.php?s&forumid=14).

Last but not least, streef je er als opencource project natuurlijk ook gewoon voor dat je zoveel mogelijk opensource software in je eindproduct hebt.

[Reactie gewijzigd door MaestroMaus op 23 juli 2024 05:17]

[gertvdijk]

Wat is nou het grote voordeel van zo'n reverse engineered NVidia driver? Je mag toch aannemen dat Nvidia's eigen drivers het beste werken om zij het beste op de hoogte zijn van alle ins en outs van hun videokaarten?

Dan heb je als kernelontwikkelaar het allemaal zelf in de hand qua integratie. Neem bijvoorbeeld kms (kernel mode setting). Dat is een feature die Nvidia (nog) niet wil implementeren, maar wel veel voordelen biedt voor een gemiddelde consument. Misschien doet die driver 3D versnelling niet zo goed, maar dat kan misschien opwegen tegen de voordelen.
Daarnaast zijn met open source drivers (met open development) aanmerkelijk minder problemen in het algemeen. Gewoon minder bugs (vaak ook minder feautures ja), betere suspend/hibernate ondersteuning en dergelijke.

[Anoniem: 185441]

komt er niet bijna iedere maand mel een nieuwe linux kernel uit...?

[Jeanpaul145]

Er komen grofweg 4 production-quality kernel releases per jaar uit: Een kernel heeft eerst een zogenaamd mergewindow, waarin de grootste veranderingen in een bepaalde release gemerged moeten worden. Nadat de mergewindow gesloten is krijg je de stabilitatiefase; Hier komen er bijna alleen bugfixes uit, en deze versies worden gekenmerkt door een "rcX" suffix aan het versienummer, bijvoorbeeld "2.6.33-rc3". Een grote uitzondering hierop zijn staging drivers; dit zijn drivers die officieel nog niet als production quality worden gezien; dit kan om een aantal redenen zijn (lelijke code, te weinig documentatie, ontbrekende features, niet stabiel genoeg etc). Nouveau's code bijvoorbeeld zit in de staging area. Zoals de naam al aangeeft is het wel de bedoeling dat code dat daar geplaatst wordt altijd uiteindelijk een mainline deel van de kernel wordt.

Wat ik niet snap is het doel van dit artikel: wat is er zo speciaal aan de 2.6.33 kernel (tov andere releases)? Nouveau is een hele fijne toevoeging voor nvidia gebruikers, maar waarom vindt t.net het speciaal genoeg om er een artikel aan te weiden?

[Reactie gewijzigd door Jeanpaul145 op 23 juli 2024 05:17]

[Pixeltje]

Waarschijnlijk inderdaad Nouveau, omdat het hiermee in principe makkelijker wordt om je Nvidia kaart fatsoenlijk te laten werken in Linux. Het is in ieder geval een toevoeging die ervoor moet zorgen dat de kans groter is dat je Nvidia kaart werkt.

[teek2]

Eerlijk gezegd had ik vroeger met mijn Nvidia kaart en closed source driver minder gezeur dan nu met mijn intel gma die open source drivers heeft... ik weet het nog zo niet niet hoe nuttig dit is. Sure, je hebt nu out of de Box waarschijnlijk 3D maar daarna zal je vast willen upgraden en features als vdpau gaan gebruiken.

[BeosBeing]

Goede drivers en een duidelijke configuratie zijn bepalend voor de werking, ongeacht of dat die dan closed of open source zijn. Veel puristen zweren bij een van beide, maar dat maakt voor de werking in principe niet uit.

Wel is het zo dat bij open source er veel meer kans is dat bugs gevonden worden, en dat de ontwikkeling doorgaat als de hardware al uit productie is, bij closed source moet je maar afwachten of de fabrikant het voor een ouder product nog zinvol vind voor een nieuwe kernel/os* versie/... nog nieuwe drivers te maken, en ook bij nieuwe producten of ze nog de moeite willen doen drivers voor oudere versies van kernel/os.
* voor os kun je dan lezen een bepaalde distributie of bv windows versie

Vaak is het ook zo dat hardware fabrikanten niet meer de moeite nemen een eigen driver te ontwikkelen, als er al een open source driver beschikbaar is, of er aan gewerkt wordt, en daaraan ook geen bijdrage levert, ongeacht of die laatste dan al stabiel is, alle functies ondersteund enzovoorts, wat meestal niet het geval is aangezien een driver maken niet zo gemakkelijk is, en zeker niet als je niet alle ins en outs van de hardware kent.

[kozue]

Nouveau heeft er voor mij in Fedora 12 voor gezorgd dat ik moeite moest doen om m'n nvidia kaart behoorlijk aan de gang te krijgen. Omdat dat nouveau standaard aan staat claimde die driver alvast maar even de videokaart, waardoor de echte driver (de binary van nvidia zelf) niet meer werkte. Heb de initrd moeten rebuilden om het zaakje op een normale manier te laten werken.
Die nouveau driver zelf is nog nauwelijks een alternatief te noemen. Om te beginnen laadde m'n desktop niet eens normaal met die driver (wat het precies was ben ik vergeten, maar het was een nouveau issue en ging weg met de binary driver) en zelfs als het voor de desktop zou werken koop ik een nvidia kaart voor de 3D performance. Als ik alleen een desktop wil neem ik wel een goedkoop intel dingetje, dat scheelt geld. Zolang ik niet behoorlijk WoW kan spelen op nouveau valt het bij mij onder het kopje "rommel" en vind ik het jammer dat ze het in de kernel opnemen.

[ACM]

't Is nu januari en de volgende wordt aangekondigd voor begin maart, de 2.6.32-kernel is overigens van 3 december. Is dat antwoord op je vraag?

[Kopje_Koffie]

Wat bedoel je met nieuwe kernel? Als je 2.6.x bedoeld, dan zijn t er toch wel wat minder. In 2009 zijn de kernels 2.6.29 tot 2.6.32 uitgebracht: zie ook http://git.kernel.org/?p=...linux-2.6.32.y.git;a=tags. Alle, 2.6.x.x releases heb ik geen zin om te tellen

[MaestroMaus]

En dat is maar goed ook. Iedere nieuwe kernel bevat namelijk ook ge-update drivers. (zie: http://linux.oneandoneis2.org/LNW.htm)

[Reactie gewijzigd door MaestroMaus op 23 juli 2024 05:17]

[ari3]

Goede zaak die Nvidia drivers! Gaat men dit ook doen voor de ATI/AMD chips? Ik zit al een jaar te wachten op VAAPI of XVideo support voor de 780G (HD3200). AMD geeft zelfs geen closed-source HD video acceleratie driver. Ook mis ik 64-bit ondersteuning voor de HD3200 in FreeBSD.

[TUX2K]

ATI/AMD had zijn driver toch grotendeels vrij gegeven.
Op wat propriëtaire code na.
Oke zie reacties hieronder

Dus geen reverse-engineered driver maar gewoon een implementatie van de specs.

[Reactie gewijzigd door TUX2K op 23 juli 2024 05:17]

[gertvdijk]

ATI/AMD had zijn driver toch grotendeels vrij gegeven.

Nee, AMD heeft veel informatie/documentatie omtrent hun chips beschikbaar gesteld. Voor een deel zijn dit gegevens die de meeste bedrijven beschouwen als bedrijfsgeheim, omdat het inzicht geeft in de werking ervan. Daarom is dat heel dapper van AMD en waarderen veel open source aanhangers dat ook.

Maar zelfs met alle informatie over de hardware is het nog een teringklus om er een werkende driver mee te maken. En dat is precies wat gaande is. Novell is 'ingehuurd' om een driver te ontwikkelen en ook vrijwilligers kunnen bijdragen leveren, maar dat neemt niet weg dat het wel meer dan een jaar duurt voordat ook maar één specifieke grafische kaart volledig ondersteund wordt...

Beter is het natuurlijk als AMD zelf open source drivers ontwikkelt samen met de community, maar ik vrees dat dat teveel tegen de commerciële drijfveren indruist en ze daarom (nog) niet overgaan daartoe.

[stijn1989]

Als je een videokaart koopt, zouden ze voor alle platformen een driver mogen meeleveren buiten Windows. Het is niet omdat je een ATI kaart koopt, dat je Windows installeert.

[robvanwijk]

zouden ze voor alle platformen een driver mogen meeleveren

Da's niet helemaal realistisch he? Er zijn gewoon veel te veel platformen, dus zul je een keuze moeten maken. Of wou je ook nog graag DOS 6 en Win 3.1 drivers meegeleverd hebben? Haiku-drivers misschien? Of kunnen draaien onder NeXT?
Juist de aanpak die AMD/ATI heeft gekozen is het beste om zoveel mogelijk platformen te kunnen ondersteunen: specs vrijgeven. Als er voldoende vraag is naar ondersteuning voor platform X, dan kunnen geburikers van X zelf aan de slag.

[BeosBeing]

Maar meehelpen is oook zinvol, is alleen niet voor alle platformen haalbaar.
Wel is het zo dat er een aantal platformen is waartussen je gemakkelijk kunt porten, waaronder volgens mij Linux, xBSD, OS-X, of waarvoor je makkelijker een driver kunt maken als je de zo'n andere al hebt, hiertoe behoren volgens mij Haiku en ReactOS.

[The Flying Dutchman]

AMD heeft een aantal mensen in dienst die ook werken aan de opensource drivers. Zie ook mijn bericht hierboven.

[The Flying Dutchman]

Nee.

AMD heeft alle specificaties van zijn gpu's vrijgegeven (kan zijn dat er nog wat documentatie ontbreekt op gebied van video decoding, dat weet ik niet helemaal zeker). Daarnaast steunt AMD het opensource project door enkele medewerkers mee te laten programmeren aan de open source driver. AMD heeft volgens mij ook zo nu en dan wat basis code vrijgegeven om voor bepaalde functionaliteit een kleine basis te hebben in de opensource driver.

Daarnaast heeft AMD ook nog steeds een proprietaire driver die volledig closed source is.

De open source driver van AMD is volgens mij al langer in de kernel opgenomen... niet geheel zeker hiervan overigens.

[johnbetonschaar]

De open source driver van AMD is volgens mij al langer in de kernel opgenomen...

Video drivers zitten bij Linux niet in de kernel, slechts een minimaal gedeelte voor mode-setting en resource management/initialisatie.

Gek genoeg doet het artikel vermoeden dat de hele Nouveau driver in de kernel zit, maar dat is dus zeker niet het geval, praktisch alles zit in de Xorg driver.

[revertive]

De video drivers zitten wel in de kernel-tree, dat ze gecompileerd worden als modules ipv rechtstreeks in de kernel tsja lekker spannend.

[drahca]

Nee dus. Alleen het mode setting gedeelte zit in de kernel, de rest van de driver loopt in user space onder X.org.

Vroeger zat alles in user space en dat was een onwenselijke situatie omdat het initialiseren van de hardware, wat toch echt een taak is van de kernel, nu door X moest gebeuren. Ook modesetting werd door X gedaan, maar in de kernel draaide wel de terminal driver. De twee konden niet met elkaar communiceren wat tot de rare situatie leidde dat er twee drivers waren voor een stuk hardware waarvan de kernel driver niet op de hoogte was van de user space driver.

Gelukkig wordt dit nu dus opgelost door een mode setting driver in de kernel op te nemen. Het deel dat zorgt voor 2D en 3D acceleratie en OpenGL etc draait in user space en communiceert met de kernel via de Kernel Mode Setting driver.

[MisterE]

video acceleratie schiet niet op. Heeft schijnbaar ook geen prio bij AMD.
Er stond op phoronix (goede site hierover) toen wel een closed omweggetje om acceleratie aan de gang te krijgen.

[Jeanpaul145]

Video acceleratie is een puntje waarvan ik verwacht dat het pas echt opgelost wordt als Gallium3D eenmaal mainstream gebruikt wordt voor nouveau en de radeonHD kaarten.

Gezien dat moment steeds dichter bij komt denk ik dat het gewoon niet rendabel is om nu in fglrx die support te gaan inbouwen; Thuisgebruikers ziet AMD graag de FOSS drivers gebruiken - fglrx is atm vooral bedoeld voor enterprise klanten.
Dat ze support leveren voor hun radeonkaarten komt vooral voort uit het feit dat m.n. 3D support nog niet helemaal af is voor de R600/R700 en R800 generaties gfx kaarten. Ik verwacht dan ook dat ze op een gegeven moment (wanneer AMD same-day FOSS support kan leveren voor linux als voor windows met Catalyst) dat ze radeonkaarten niet langer zullen supporten in fglrx.

[Anoniem: 112442]

De R600 en R700 is nog experimenteel. Zie de link.

De R500 werkt al perfect.

[Anoniem: 190996]

Ik heb een heel dubbel gevoel bij reverse engineering. Het is een knap staaltje werk, en er zijn meerdere voorbeelden waar het goede resultaten heeft opgeleverd.

Maar... wat is het voor flauwekul dat een fabrikant niet mee wil werken. Alle reden om dan ook de producten niet af te willen nemen. Gewoon boycotten! Dat doen we met software die onder een niet compatibele licentie is uitgebracht toch ook? Met reverse engineering loop je altijd achter de feiten aan, wordt onnodig veel van ontwikkelaars gevergd en zijn de resultaten kwalitatief minder. Alleen al omdat onaangekondigde wijzigingen in de hardware voor onverwachte ellende kunnen zorgen.

Het zou goed zijn als de linux gemeenschap ook eisen aan hardware aanbieders gaat stellen.

[Anoshky]

Ik denk dat de fabrikanten dan gewoon eens goed zullen lachen.
Zij liggen toch totaal niet wakker van het feit dat ze geen klanten meer zouden hebben die op Linux werken?

Alhoewel een slimme fabrikant eens de overstap zou moeten maken.
Stel dat NVidia nu morgen zegt: vanaf vandaag ondersteunen wij alle linuxdistri's met volledig compatibileit.
Dan zou hun klantenbestand toch een héél stuk stijgen en zouden ze hun concurrenten toch even een 'ferme hak' kunnen zetten?

[jiriw]

Hmm, volgens mij spreek je jezelf een beetje tegen in die twee alinea's. Maar zelf denk ik dat het heel erg afhankelijk is van wat voor een hardware je maakt als fabrikant. Voor fabrikanten van voornamelijk consumenten pc-onderdelen heb je misschien gelijk omdat de meeste 'gezinnen' toch windows draaien. Maar voor de zakelijke- en vooral internetservermarkt zou het niet willen ondersteunen van Linux wel eens de slechtste strategie kunnen zijn die je als hardwarefabrikant zou kunnen nemen. In de praktijk zie je dat ook wel een beetje terug. Voor zaken als netwerkkaarten en RAID en andere storage controllers zijn vrijwel altijd drivers beschiknaar, vaak met steun van de fabrikant. Als je kijkt naar moderne geluidskaarten (Creative) of USB gadgets dan zie je vrijwel nooit goede drivers met ondersteuning van de fabrikant. Als ze er al zijn dan is het reverse-engeneerd door OSS driverontwikkelaars die daar graag hun tijd in steken (omdat ze bijvoorbeeld zelf het desbetreffende apparaat hebben en er niet meer tegen kunnen dat het niet in Linux werkt )

[DJFreestyler]

Dat is in principe een beetje wat AMD/ATI heeft gedaan. ATI was altijd berucht om zijn belabberde Linux drivers, toen AMD ze kocht hebben ze flink wat moeite in de Linux driver gestoken en daarbij ook nog eens nagenoeg alle specificaties vrij gegeven en veel support aan de Open Source ontwikkelaars die een driver willen ontwikkelen.

Vooral het laatste heeft ze erg veel goodwill opgeleverd en het begint zo langzamerhand ook zijn vruchten af te werpen. Ikzelf draai in ieder geval al tijden de open-source ATI driver en heb er absoluut geen klachten over, zeker aangezien de binary driver van ATI zelf bij mij amper werkt. Zolang je geen 3D nodig hebt doet de open-source driver het eigenlijk even goed of zelfs beter dan de binary.

Bij de hardware survey van Phoronix afgelopen jaar werd verder duidelijk dat er tegenwoordig meer mensen open-source ATI draaien dan binary en het aandeel van open + binary ATI was bijna gelijk aan dat van NVidia (scheelde een paar procenten). Toegegeven, ATI heeft vorig jaar support voor r500 en lager uit de binary driver gehaald, dus dit heeft waarschijnlijk invloed gehad op het aantal open-source ATI bij die survey. Toch zal dat niet de enige reden zijn waarom de open-source driver zoveel meer aandeel heeft.

[MisterE]

a: nvidia geeft WEL closed source drivers uit
b: die paar linux gebruikers zal nvidia weinig boeien als die hun producten niet koopt.

[ATS]

Tot het om een commerciële embedded oplossing voor bijvoorbeeld een media set-top box gaat die als warme broodjes over de toonbank gaan. Dan baalt nVidia ineens wel dat er gekozen wordt voor een grafische chip van de concurrent, omdat de driverondersteuning beter geregeld is.

[YaPP]

Het zou goed zijn als de linux gemeenschap ook eisen aan hardware aanbieders gaat stellen.

Bij grote deployments doet de LinuxFoundation dit ook.

Als een fabrikant niet meewerkt aan open drivers, moet je op een bepaald moment je eigen boontjes doppen.

[Anoniem: 28958]

Ik wil wel eisen, maar dan moet er wel een alternatief zijn. Als ik bijv. een laptop kan kopen waarin alle componenten volledig met documentatie komen, dan wil ik dat een stuk liever hebben dan iets wat zo gesloten is als de pest (wat we nu hebben). Probleem is alleen dat niemand zoiets aanbiedt.

Ik denk dat we wel binnen 5-10 jaar zo'n open systeem kunnen kopen overigens, omdat er allerlei Chinese bedrijven zijn die wel open componenten al bouwen.

[Anoniem: 325409]

Open source drivers is zowiezo een goed iets, moet de industriestandaard worden.

[Anoniem: 95522]

't probleem met open source is dat er 1001 forks/branches kunnen komen daarnaast wil je ook de interne werking van je hardware niet blootgeven op je IP te beschermen.

[Anoniem: 28958]

Volgens mij heb je geen idee waar je over spreekt. Waarom de interface naar je hardware zou vrijgeven hoe je hardware werkt is mij overigens ook een raadsel.


Dan is het altijd mogelijk om het hele apparaat te reverse-engineeren (inclusief hardware), alleen kost het tijd en heb je er specialistische apparatuur voor nodig.

En "IP", is ook maar een relatieve term, aangezien het al lang bedacht is hoe je theoretisch optimaal een willekeurig berekenbaar probleem op kunt lossen. Het concept van creativiteit is iets van voor die tijd en misschien alleen nog toepasbaar op niet-technologische dingen zoals een "mooi" schilderij.

[Skinkie]

Bijvoorbeeld omdat Nvidia iets heel cools doet met tabellen als lookup functie, en die nogal goed zijn gekozen. Daar zit ontwikkeltijd in misschien zelfs van een externe partner. En dat kun je niet zomaar op tafel gooien.

[Anoniem: 28958]

Al dit soort trucjes zijn allemaal te berekenen door computers zonder enige menselijke interactie. Het kan misschien wel 30 jaar CPU tijd kosten (en dat kost wel wat), maar op een computer cluster van 50000 computers is dat al snel gedaan.

Het punt is dat hoewel er inderdaad ooit menselijke tijd is ingestopt, heeft die methode van problemen oplossen zijn langste tijd gehad.

[Skinkie]

En als we een paar miljoen apen een schrijfmachine geven komt er ook vast ooit wat zinnigs uit. Ik wil Genetische algoritmes zeker niet te kort doen, maar een persoon die echt een schakeling heeft bedacht of in dit geval een lookup functie voor kleuren en primitieven ook niet.

Maar goed, AMD en Via hebben de drivers volledig open gegooid, nouja volledig; alle troep als macrovision is 'undocumented'. Persoonlijk zit ik nog bij nVidia omdat ik er op kan vertrouwen, als ik dat op een AMD kaart ook kan, dan zal ik dat ook zeker doen. Dat neemt niet weg dat nVidia goed bezig is voor Linux met VDPAU, Cg en gewoon robuste drivers.

(Ohja, ik heb zelf bijgedragen aan de Nouveau ontwikkeling dus zo 'sociaal' ben ik dan ook weer)

[Anoniem: 28958]

Het punt is dat er sinds genetische algoritmen _nieuwe_ ontwikkelingen zijn (ook al weer meer dan 5 jaar oud). Deze algoritmen werken op een probleem genaamd universal search en tenzij mensen meer zijn dan een finite state machine (wat nog nooit is aangetoond), dan zullen een netwerk van computers altijd mensen verslaan op willekeurig welke taak, omdat ze bewijsbaar optimaal werken en ook daadwerkelijk een oplossing vinden als deze er is. De gemiddelde mens kan dat niet.

Niemand heeft voor zover ik weet deze dingen al geimplementeerd, maar ze impliceren wel hoe ouderwets het patentsysteem is.

Overigens kudos voor jou dat je aan Nouveau ontwikkeling helpt.

[Skinkie]

Niemand heeft voor zover ik weet deze dingen al geimplementeerd, maar ze impliceren wel hoe ouderwets het patentsysteem is.

Je weet dat juist met genetische algoritmen om patenten worden heen gewerkt (en nieuwe patenten worden aangevraagd)? En ja, ik zou ook meer voor een historisch correct systeem zijn op basis van 'eerste publicatie', dat nooit een recht op exclusiviteit impliceert.

[Jeroen]

Volgens mij heb je geen idee waar je over spreekt.

Waarom de interface naar je hardware zou vrijgeven hoe je hardware werkt lijkt mij best logisch.

[Anoniem: 28958]

Als ik een stuk hardware bouw dat op miraculeuze wijze een groot getal kan ontbinden in factoren en jou de interface geef dan helpt dat je helemaal niets om zelf grote getallen te ontbinden. Je zult dan zelf de hardware moeten gaan analyseren.

Dus jij bent de persoon die, zoals ze dat zo mooi zeggen, poep praat.

[Anoniem: 28557]

't probleem met open source is dat er 1001 forks/branches kunnen komen

Ten eerste, waarom zou dat een probleem zijn?
Ten tweede, hoeveel forks/branches zijn er van de Linux kernel, van Apache, van PHP, van het overgrote deel van alle opensource projecten?

daarnaast wil je ook de interne werking van je hardware niet blootgeven op je IP te beschermen.

Waarom zou niemand het accepteren als je een auto met dichtgelaste motorkap zou kopen, terwijl met hardware ineens het een groot probleem is als iemand de inner workings van je hardware kan zien... geloof mij, ook met closed source drivers kan AMD prima zien hoe de kaarten van nVidia aangestuurd worden...

[Anoniem: 28958]

Zonder electronica kom je nergens meer met het repareren van een auto voor zover ik weet en volgens mij is die software/hardware om de service computers uit te lezen ook niet beschikbaar. Auto's zijn de laatste jaren net zo veel een blackbox geworden als andere technologie.

[Anoniem: 28557]

Zeker wel, autofabrikanten zijn tegenwoordig verplicht om die informatie tegen een redelijk tarief vrij te geven en er zijn ook diverse merkonafhankelijke software voor auto diagnostics te koop.

[multipasser]

Reverse engineered driver voor nvidia gpu's?
Waaronder GPU acceleratie voor h264?

Kunnen we dat ook niet voor osx doen?
Daar wachten we ook vergeefs op gpu acceleratie van video (buiten QT).

[MaestroMaus]

Ghehe, die reverse-engineered GPU acceleratie is goed genoeg voor Quake Live, flash en 2d maar denk maar niet dat je er bijv. de games van de afgelopen vier jaar op kan draaien (unlike your mac).

[Sfynx]

Iedere zoveel tijd komt er een nieuwe kernel uit, maar er is geen parallelle ontwikkeling meer van "development" versies als ik het zo bekijk. Iedereen is met de volgende 2.6 bezig, en zodra die uit is, is iedereen met de volgende 2.6 bezig, en zodra die uit is, etc... Is dat niet vragen om problemen?

Meestal verwacht je toch een parallel model als bij FreeBSD:
9-CURRENT = zandbak, alles kan en alles mag. Wordt ooit versie 9.0-RELEASE en de 9-STABLE. Dingen worden geport naar *-STABLE waar nodig/handig.
8-STABLE = zandbak, maar niet voor zeer revolutionaire ontwikkelingen. Nieuw moduletje hier, optimalisaties en wat drivers daar, contributed software naar nieuwe versies, etc... Wordt ooit de volgende 8.*-RELEASE. Dingen worden geport naar 9-CURRENT waar nodig/handig.
8.0-RELEASE = productieversie, krijgt alleen fixes voor security en voor show-stopper bugs.

Want hoeveel tijd is er bij Linux nu om een nieuwe feature in de huidige kernel te testen voordat het in productie gaat?

(of is er toch ergens een 2.7 dev kernel die intern gebruikt wordt o.i.d.?)

Nadeel bij FreeBSD is dat ontwikkeling trager gaat, maar wel erg gecontroleerd.

Driver interfaces e.d. zie ik nauwelijks veranderen, zeker niet in een major serie (Draai je bv. 7.2-RELEASE en werkt een driver gecompileerd op 7.0-RELEASE nog steeds zonder problemen)

[Reactie gewijzigd door Sfynx op 23 juli 2024 05:17]

[MaestroMaus]

Als je prestatiegericht kijkt naar de afgeleverde linux-kernels zie je dat het geen problemen oplevert (zie continue regressietests op Phoronix).

[Darude1234]

Die nvidia drivers zou goed zijn. Sinds de laatste paar linux kernels krijg ik mijn nvidia drivers met geen mogelijkheid meer aan de praat dus werk nog steeds met een vrij oude kernel 2.6.14 die wel werkt.

[Darude1234]

Hmm.. vandaag nog eens verder zitten zoeken ik bleek nog wat verouderde nvidia drivers te hebben. Achteraf een beetje dom. Heb de nieuwste nvidia drivers geinstalleerd en nu werkt ook de nieuwste linux kernel 2.6.31-17

[Binscow]

Hier gaat Ubuntu 10.04 Lucid Lynx op draaien. Ben benieuwd! Ubuntu is een erg fijne distro.

[Peetke]

Ubuntu 10.04 LTS blijft op 2.6.32 draaien. Ze hebben voor optimale stabiliteit gekozen (tegenover Bleading Edge software)

[MaestroMaus]

Wat niet wil zeggen dat het niet gebackport wordt. Dat gaat namelijk gewoon wel gebeuren (is al aangekondigd).

[DCK]

Overigens sluit Canonical niet uit dat in updates van 10.04 LTS ook kernel-updates mee gaan komen. De server versie moet het dan ook uitzingen tot 2016, tegen die tijd zitten we wel blij Linux-kernel 2.6.50+.

[Ghostface9000]

@Left
Dat vraag ik mij ook af