Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 96 reacties

In de nacht van donderdag op vrijdag is versie 3.0 van de Linux-kernel vrijgegeven. De wijzigingen in de nieuwe kernel zijn minder groot dan het versienummer doet vermoeden: de belangrijkste wijziging is deze keer het versienummer zelf.

He crazy!Eind mei verscheen al een release candidate van versie 3.0 van de Linux-kernel en nu is de final versie uitgegeven, zo heeft Linus Torvalds op Google+ bekendgemaakt. Hoewel het gaat om een flinke verhoging in het versienummer - de vorige versie kreeg nummer 2.6.39 - bevat de nieuwe kernelversie weinig grote veranderingen.

Aanvankelijk stond Linux 3.0 zelfs als 2.6.40 op de planning, maar Torvalds vond dat het versienummer daarmee te hoog zou oplopen. De eerste Linux 2.6-versie kwam ruim zeven jaar geleden uit en sindsdien werd het volgnummer telkens opgehoogd. Overigens verschijnen er ook nog steeds updates in de 2.4-branch.

Kernelversie 3.0 bevat onder andere ondersteuning voor nieuwe Intel-hardware, zoals Sandy Bridge- en Ivy Bridge-cpu's. Ook is er flink gesleuteld aan het nog steeds experimentele btrfs-bestandssysteem en er zijn nieuwe drivers aan de kernel toegevoegd. Onder andere Ubuntu 11.10, dat in oktober verschijnt, zal de nieuwe Linux-kernel aan boord hebben.

Moderatie-faq Wijzig weergave

Reacties (96)

Dit versienummer is dan ook voornamelijk gekozen omdat we het 3e decennium van Linux intreden, en omdat Torvalds de versienummers te hoog vond oplopen. Het versienummer is voornamelijk cosmetisch, en tijd-gebaseerd, niet feature-gebaseerd.
offtopic:
Wanneer komt Linux Kernel 3.0 bij de Tweakers C.V. te staan? :)

[Reactie gewijzigd door Dystized op 22 juli 2011 12:28]

offtopic:
Wanneer komt Linux Kernel 3.0 bij de Tweakers C.V. te staan
?
offtopic:
Ik denk op dezelfde dag dat je ook kunt aangeven dat je ervaring hebt met de ZX80, ZX81 en de ZX Spectrum
:+
Zeer relevant als je bij een techniekmuseum solliciteert. :)
Al dat gezever over versienummers. Als het beestje maar een naampje heeft, toch?

2.6 ging natuurlijk niet 'zomaar' naar 3.0. We praten over 7 jaar ontwikkeling en 7 LTS releases, of waren het er 8? Ik kan er best eentje naast zitten.
Punt is, dat er nu gekozen is voor een nieuw 'begin' met versie 2.6.39.3 als uitgangspunt en we noemen 'm: versie 3.0, op de 20ste verjaardag van Linux.

Linux: I applaud you!
Deze 3.0 versie komt ongeveer overeen met de 20ste verjaardag van Linux. Linus heeft al eens gezegd dat hij het ziet als "we beginnen aan het derde linux decennium" en dat hij over 10 jaar 4.0 wil uitbrengen*.


* Ga er maar van uit dat hij de komende 10 jaar nog wel een paar keer van idee zal veranderen.

[Reactie gewijzigd door CAPSLOCK2000 op 22 juli 2011 13:01]

Lijkt me moeilijk, omdat er soms heel weinig tijd tussen versie releases zit.
Ze kunnen nu toch llnux geen jaartallen gaan geven? Dat deed Microsoft 15 jaar geleden.
Heeft MS daar dan patent op aangevraagd? (Je weet maar nooit in de USA).
Das idd een goed idd en is wat de catalyst drivers al een heletijd doen en het is daarom ook erg duidelijk of je een oude driver draait of niet.
Voor diegene die het hebben gemist, hier onderbouwt Linus Torvalds zijn motivatie voor de nieuwe versienummering: https://lkml.org/lkml/2011/5/29/204
I decided to just bite the bullet, and call the next version 3.0. It
will get released close enough to the 20-year mark, which is excuse
enough for me, although honestly, the real reason is just that I can
no longe rcomfortably count as high as 40.
Verder ben ik benieuwd hoe lang het duurt voordat de verschillende distro's deze versie oppakken. Ik bevind mij momenteel zelf in de Fedora hoek en verwacht hem dan ook op z'n minst in Fedora 16 en nieuwer. Ben tevens wel benieuwd hoe ze het model verder binnen Fedora op zullen pakken. Meestal pakken ze 1 major versie per release maar ik weet niet of dat nog steeds het geval zal zijn.

Thuis gebruik ik tevens Chakra, ik verwacht hem daar eerlijk gezegd best snel in.

[edit] quote tags gefixed

[Reactie gewijzigd door E-B op 22 juli 2011 12:54]

Hum... Arch zit nu nog op 2.6.39.3-1, ik verwacht 3.0 toch zeker wel op maandag.
Maandag zou ik wel erg snel vinden. Laat ze eerst maar 3.0 in de testing repo droppen. Ik ben ook benieuwd of alle scripts zonder problemen de transitie kunnen maken. Zou wel zo moeten zijn.
En dan ga ik hier at the office waarschijnlijk de eerste zijn met de nieuwe kernel. Eens een leuke wallpaper zoeken...
Ik heb het gevoel dat dit geen major release is, waarom geen 2.8?
En het lijkt nu wel of linux nu ineens meegaat met het versienummergeweld van firefox en chrome!
Ze hadden beter nog een paar maandjes door kunnen sleutelen zodat ze dan een release major kunnen noemen!
Edit:fixed major

[Reactie gewijzigd door Lemming op 22 juli 2011 12:28]

Grote releases geven het probleem dat het ontwikkel-proces dan maandenlang wordt afgeremd. Dat heeft weer als gevolg dat een hoop programmeurs op eigen houtje verder werken en er steeds minder mensen overblijven om te testen. Hierdoor zal de release van de major versie steeds verder vertraagd worden. Uiteindelijk wordt er dan iets gereleased waar een groot deel van de programmeurs al maanden niet meer naar om heeft gekeken.

Als iedereen die zelfstandig verder heeft zitten werken dan z'n code gaat insturen krijg je het volgende probleem. Omdat het zo lang heeft geduurd is de code van verschillende mensen uit elkaar gegroeid en moet je veel werk doen om alles weer aan elkaar te plakken.

Je ziet steeds meer software-projecten die time-based releases doen om te zorgen dat de vaart er in blijft. Heb je de deadline niet gehaald dan is er geen reden tot paniek, over (bv) zes maanden krijg je weer een kans. Dat voorkomt dat deadlines eindeloos worden opgerekt omdat een of andere feature nog niet helemaal af is, met alle voornoemde gevolgen.
Argh :( Ik maar hopen dat er hybride graphics support in zat...
Voor nvidia kan je gebruik maken van bumblebee, tenminste als dat is wat je bedoelt met hybride graphics support. Bumblebee maakt dan een virtuele 2e X scherm aan waarop grafische kaart kan helpen renderen als je niet genoeg hebt aan je onboard GPU.
Ik denk niet dat je dat soot specifieke dingen in de kernel moet gieten. Het is allemaal extra gewicht dat je mee moet sjouwen, voor de >99% van de pc's die het niet nodig heeft. Ik zou zeggen wacht gewoon een degelijke driver af.
De drivers voor dat soort dingen kun je wel of niet in de kernel compileren, en gewoonlijk wordt zoiets als kernel module gereleased. Als je het niet nodig hebt wordt hij niet geladen.
Either way, nVidia moet dit bouwen. Niet de community. En ik denk dat het niet in de standaard kernel thuishoort, want de meeste pc's hebben het niet of gebruiken het niet.

[Reactie gewijzigd door _Thanatos_ op 23 juli 2011 03:59]

Snap het ergens wel maar uiteindelijk is het net zo loos als dat gedoe van Firefox en Google wat betreft versienummering.
Vind het zelf allemaal nog niet zo nodig, maar misschien loop ik wel gewoon achter.
2.6 is in 2003 gereleased. Is 3.0 in 2011 echt zo loos?
De spontane sprong vind ik loos ja.

Vroeger was het zo dat je met grote versienummer wijzigen dat je ook echt te maken had met een radicaal nieuwe release van de betreffende software en waren de kleine aanpassingen meer bugfix related.
Ik begrijp niet zo goed wat er precies mis is met dat systeem en waarom er zo populair gedaan moet worden met die versienummering. Maargoed ik ben dan ook geen coder. (refereer nu niet persé naar linux overigens)

[Reactie gewijzigd door Alpha Bootis op 22 juli 2011 12:28]

De Linux-kernel ontwikkelt zich niet in grote stappen. Radicale stappen worden maar zelden genomen. Men geeft de voorkeur aan kleine en overzichtelijke stappen.

In vrijwel iedere kernel versie zitten dingen die niet meer compatible zijn met de vorige versie. Tot en met linux 2.6.0 ging was het wel zo dat 'grote' versie nummers werden bewaard voor grote stappen. Gedurende de 2.6 serie is dat veranderd. Doorgaan op het oude schema was ook niet helemaal duidelijk meer want dan zouden we altijd bij 2.6 gaan blijven. Dat is ook niet meer redelijk want er is enorm veel veranderd sinds 2.6.0 . Je moet niet verwachten dat je zonder problemen kan wisselen tussen 2.6.0 en 2.6.39.

Het verschil met 2.6.39 is misschien niet groot genoeg om versienummer 3.0 te verantwoorden, maar als je vergelijkt met 2.6.0 dan is het wel terecht.
Eens, maar als je kijkt naar waar de grootste sprong tussen 2.6.0 en 3.0.0 zat, dan was dat niet tussen 2.6.39 en 3.0.0. Ik zou dan eerder denken aan 2.6.17 (system calls&I/O op de schop) of 2.6.28 (ext4, GEM GPU memory manager).

Dit is geen giant leap maar een rustige wandeling waarbij de omslag van 2 naar 3 niet eens bij een van de huppeltjes in die wandeling was.

Natuurlijk hangt het samen met het ontwikkelmodel voor 2.6, maar dit klinkt echt alsof de marketeer in Linus behoefte had om iets te kunnen roepen zonder dat er daadwerkelijk ook maar iets significants in z'n product (de kernel) veranderd was...
Omgekeerd zou je ook kunnen zeggen dat we met 2.6.17 al naar 3.0 hadden moeten springen en met 2.6.28 naar 4.0 - misschien is Linus te weinig marketeer? Laat die versienummering maar zo. Zolang er maar verbetering in zit (en die zit er elke keer weer in), blijf ik bij linux.
Achteraf gezien was het misschien beter geweest om de stap eerder te nemen. Er is ook niemand die ontkent dat dit meer uit marketing-overwegingen is gedaan dan uit technische belangen.
Vroeg of laat moest het een keer gaan gebeuren en nog veel langer wachten zou het niet beter hebben gemaakt.
Eigenlijk had hij destijds, dus ten tijd van 2.6.17 of 2.6.28 het versienummer naar 2.8 moeten ophogen, maar dat is dan dus achteraf gepraat,
De Linux-kernel ontwikkelt zich niet in grote stappen. Radicale stappen worden maar zelden genomen. Men geeft de voorkeur aan kleine en overzichtelijke stappen.
Daar is op zich neits mis mee, maar wat wel vreemd is dat is dat de versienummering nu suggereert dat de stap 2.6.39>2.6.40 vele malen groter is dan de vele stappen van 2.6.0->2.6.39 samen.

Persoonlijk zie ik er niet zo'n probleem in om gewoon door te gaan met de huidige nummering; in het algemeen wordt de kernel toch niet los verspreid, maar als deel van een linux-distributie met een meer overzichtelijke versienummering. Maar als men vanwege de marketing graag een andere nummering hanteert, waarom bedenkt men dan niet iets dat ook echt breekt met de oude manier van nummering? idee: iets met de datum van uitgave in het nummer verwerkt? zo loopt het nummer vanzelf op, en kan je eraan aflezen hoe oud je kernel is?
De linux kernel raakt steeds verder uitgekristaliseerd, er worden minder grote stappen genomen. De stap van 2.4 naar 2.6 werd gekenmerkt door de nieuwe processcheduler en ander geheugen management. Zulke grote stappen gebeuren niet meer, en dus gebeurde die overeenkomstige versiestappen ook niet meer. Maar ja, als je vervolgens al op iteratie 39 zit, dan begint het versienummertje ook een beetje nutteloos te worden. Dus nu wordt gewoon de schaal aangepast.
Dat is onderdeel van de evolutie van de kernel.
Ik herinner me dat ik nog een hele tijd op 2.0.37 gedraaid heb (2.0.38 kwam ook nog uit maar bevatte alleen een bugfix voor een driver die ik niet gebruikte). Dus zo ongewoon is dat versienummer nu ook weer niet hoor.
Het staat ook symbool voor het 20 jarige bestaan van de Linux kernel, daarmee gaat het namelijk haar derde decennium in.

[Reactie gewijzigd door Wolfos op 22 juli 2011 13:11]

De oude nummering liep gewoon te hoog op. Ooit moet je toch die sprong gaan maken?
Ik heb er totaal geen probleem mee, dit maakt alles gewoon véél duidelijker.
Ohja, want 2.7 was geen mogelijkheid dus de sprong MOEST wel gemaakt worden...?
Gezien de historische nummering was 2.7 inderdaad geen optie, nee.
Dat zou enkel verwarring opleveren.
daar wil ik nog wel in mee gaan, maar dan kun je nog steeds prima doorgaan naar 2.6.99

er zijn of waren genoeg mogelijkheden om weer een dev trunk te starten.. om linux 3 ook echt linux 3 te maken.
Blijkbaar heeft i-chat geen kaas gegeten van revision control en je roept maar wat.

trunk wordt bij SVN gebruikte en de Linux kernel gebruikt allang geen trunk meer,
De linux kernel gebruikt nu GIT.
Ten tweede wordt bij trunk bedoeld de plaats waar je nieuwe features toezet, en heeft niets met release te maken, je 'start' geen trunk, want je trunk is gestart tijdens het maken van je repo, je kunt hoogstens een branch 'starten'.
Welke verwarring zou dat opleveren? 2.7 lijkt me een stuk duidelijker dan 3.0...
2.7 zou dan weer de schijn hebben van een unstable. Al is dat stramien ook al lang losgelaten. (Even no's voor stable, oneven no's voor unstable)
Dus: 2.8... dan heb je een stable nummer.... Gezien de wijzigingen zou dit logischer zijn geweest...
Ach, het is toch alleen boeiend voor distro-bouwers. De gebruikers van linux (behalve de ubernerds dan) houden zich helemaal niet bezig met kernelversies. Lekker aan de distro overlaten welke kernel erin zit, en updaten gaat tegenwoordig zo goed al volautomatisch.

[Reactie gewijzigd door _Thanatos_ op 22 juli 2011 14:18]

Ik begrijp niet zo goed wat er precies mis is met dat systeem
Release early, release often: http://en.wikipedia.org/wiki/Release_early,_release_often
Hoe vaker je releast, hoe kleiner de veranderingen tussen versies. Een onderscheid tussen major en minor releases is dan dus lastig te maken.
Alleen is het imho in en grot project nogal meilijk vast te stellen wat de "grote" veranderingen zijn.
Bovendien worden er zoveel aanpassingen gedaan, dat er zelfs bij elke "minor" release heel wat veranderd is.
3de decenium gaan we in :)
Ach bij linux ging het toch meestal gewoon om het os maar ze gaan nu met de marketing tijd mee.

Nu is het wachten op linux 4 die zeker over een half jaar gaat uitkomen.
linux = de kernel, niet het OS.
Kortom, bij linux gaat het wel degelijk om de kernel.

De rest zijn de gnu tools, en die zijn niet beperkt tot enkel de linux kernel.
Een hoop van die tools zul je bijvoorbeeld ook zien op BSD of Solaris-achtigen.
Dat hebben ze ook... Een hybride kernel. (Je hebt micro-kernel of monolitische kernel en hybride is combinatie van de 2) Alleen updaten ze deze maar enkel bij een nieuwe windows-release.

bron: http://en.wikipedia.org/w...ting%29#Microsoft_Windows
Tussentijdse updates kunnen ook ook op Windows kernelpatches bevatten. Maar omdat Windows zo'n kleine kernel heeft, zitten (tov Linux) de meeste patches in de libraries ipv in de kernel.
Dat valt wel mee, als je je kernel met alle modules statisch ingebouwd gaat zitten compileren heb je wel een dikke kernel, maar de meeste kernel modules zijn ook slechts losse onderdelen die afzonderlijk bijgewerkt kunnen worden hoor :)
Ik merk zelf dat ik major updates gewoon mis. Ik weet op een gegeven moment echt niet meer of nu 2.6.28 recent is of niet. Want dat lijkt sprekend op 2.6.38.

Volgens mij zijn ze in de fout gegaan door geen 3.0 te lanceren toen ze het memorymanagement en wat andere zaken op de schop hebben genomen. Dat was het ideale moment geweest (en toen zijn er ook nogal wat stabiliteitsissues geweest)
Memorymanagement is toch een implementatiedetail?
Memory management is een van de kerntaken (zoniet de spiltaak) van een OS.
Een os moet programma's beheren. Programma's vragen 4 dingen van een OS: Memory space, CPU tijd, I/O access en device access. Als je de laatste 2 dingen handig programmeert kan je die samenvoegen tot één categorie. De eerste 2 vormen het hart van het vermogen om custom code te draaien op elke computer.
Niet echt een detail dus.
Dan had 2.6.13 ook al 3.0 of 2.8.0 kunnen heten in verband met de udev implementatie.
Wat ook weer jou device acces raakt. Maarja dan was 2.6 een soort vista release omdat dat ook in 2.5 in development was.
Maar de interne 2.6 verschillen zijn niet te vergelijken met de 2.4 VS 2.6 veranderingen waar de veel delen van de interne structuur over de kop gingen
2.5 was ook de dev versie van 2.6... (zoals hierboven in een post al staat aangegeven kwam er altijd eerst een oneven development nummer (2.5) voordat de stabiele versie (2.6) werd vrijgegeven.) Dat is net als dat 2.3 werd ontwikkeld voordat de veranderingen daarvan in 2.4 werden vrijgegeven.

Dus het is logisch dat de veranderingen in 2.6 in 2.5 in development waren, dat heeft echter verder niks te maken met de (hard) gefaalde release van Vista van M$.
Dat had gekund ja. lijkt me een minor relase number upgrade wel waard. (2.8.0 dus)
Major zou zijn als je een hele nieuwe rewrite an meerdere onderdelen zou doen met een andere interface o.i.d.

Maar de praktijk laat wel zien dat release number management iets volledig willekeurigs is. It's whatever you like it to be. Een andere versie is een andere versie, en zolang je de PR goed doet weet iedereen wat ie er aan heeft.

Google en Mozilla zijn wat dat betreft wat doorgeschoten. Door het uppen van de major bij zowat elke release is het voor wat mij betreft eindgebruikers nu wel erg vervelend geworden om alles bij te houden. Tegelijkertijd is met de ontwikkeling van HTML5 wel zo dat er in de weergavecapaciteiten en methoden van de pagina, toch wel de core feature van een browser, nu vaak grote veranderingen aangebracht worden, dus ergens is het wel gerechtvaardigd.
Welke versie was dat?

Ik denk dat ze toen geen 2.7 hebben gereleased omdat er al een tijd geen unstable-kernel tak meer was en het ook de gewoonte was om een boel te veranderen in de unstable tak en ze die changes gewoon snel erdoor wilden hebben.
Hoe zit het eigenlijk tegenwoordig met het hele Android verhaal, zitten die nog steeds op een kernel fork?
Was er dan misschien iets mis met de aanduiding 2.7 ?
Oneven versies (2.1, 2.3, 2.7) etc zijn toch gereserveerd voor de development-branches van de kernel, niet voor produktieversies?

Lijkt me dat mensen dan niet willen overstappen omdat men denkt dat het een test-versie is, het zal op zijn minst iig voor verwarring zorgen lijkt me?
Lijkt me dat mensen dan niet willen overstappen omdat men denkt dat het een test-versie is

Denk dat de meeste mensen die lnux gebruiken daar egt niet wakker over liggen
En degene die het als probeersel inzetten zullen al helemaal enige jota hebben van de kernel laat staan de versie nummering hoe dit in elkaar stak vroeger
Tja, zo wordt het nooit wat bij de gewone gebruiker.
Dat was zo tot 2003, toen 2.6 uitkwam.
Nu laten ze de oneven nummers hoogstens nog weg vanwege het gevoel.

edit@hieronder: dat even/oneven sloeg alleen op het tweede getal.

[Reactie gewijzigd door Jesse op 22 juli 2011 13:12]

En hoe zit het met 2.6.35?
Oneven nummers werden in het verleden gebruikt voor onstabiele (ontwikkelings) kernels. Dan zou het eerder 2.8 geweest zijn.
Ik ben het met de mensen eens die het een "zinloze sprong" vinden. Op de site http://semver.org/ staat heel aardig beschreven hoe je versienummers in een technische context zou moeten gebruiken.
Dat hele stuk gaat er van uit dat je een stabiele API hebt, of daar op z'n minst naar streeft. Linus heeft de (zeer omstreden) beslissing genomen dat er geen stabiele API is. Iedere versie kan alles veranderen*.


* in praktijk gebeurt dat niet, maar er is altijd wel een onderdeel waar iets verandert.
Niks zo stabiel als de kernel ABI.

Ik begrijp zelfs niet waar die mythe vandaan blijft komen. De kernel ABI is heilig in linux-kernel land.
De ABI is misschien heilig, maar de interne API is dat des te minder. Wellicht dat het daardoor komt?
En juist dat is heel zonde.

Een stabiele api, al is het alleen maar voor de grafische drivers(of beter: juist voor grafische drivers), zou een hele hoop schelen qua acceptatie op de desktop. Eerst een stabiele api, dan komen de drivers, dan een aantal spellen en dan komt de meute.
Als je de uitleg van Linus goed leest, dan zie je dat ook hij het een 'zinloze' sprong vind. De versienummering die op semver beschreven wordt is heel nuttig als het ook daadwerkelijk de 'beloftes' van stabiliteit aangeeft, maar het ontwikkelproces van de linux kernel verloopt anders en is niet in dat schema te vatten (CAPSLOCK2000 legt het in een eerdere post goed uit).

De versienummering van Ubuntu en Catalyst zijn eigenlijk meer van toepassing (jaar-maand), die geven net als het semver.org schema nog iets van informatie naast het kunnen praten over een versie en de chronologie van verschillende versies.
Tja, noem native xen support maar niet major. Ik ben er erg blij mee :P.
XEN is al sinds 2.6.39 native (maar het blijft tof).

[Reactie gewijzigd door CAPSLOCK2000 op 22 juli 2011 14:18]

Het is stukje voor stukje toegevoegd. Vanaf 2.6.39 heb je genoeg stukjes om er iets mee te kunnen. In 3.0 zijn nog wat extra stukjes togevoegd.
Het versienummer heeft vooral een psychologisch effect denk ik
Omwille van het psychologisch effect is het misschien wel handig dat de verschillen met 2.6.39 niet zo heel groot zijn. In de software-wereld hoor je wel eens dat mensen de .0 versie overslaan omdat daar vaak nog grote bugs in zitten. Deze Linux 3.0 kernel durf ik wel te vertrouwen omdat ik weet dat verschillen niet zo enorm groot zijn.

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True