Torvalds wil volgende Linux-kernel versienummer 2.8 of 3 geven

Linus Torvalds speelt met de gedachte om de eerstvolgende Linux-kernel niet versienummer 2.6.40 te geven, maar het nummer te verhogen naar 2.8 of zelfs 3.0. Volgens de Linux-goeroe krijgen de 2.6.x-kernelseries een te hoog getal achteraan.

Kort na de release van kernel 2.6.39 is het werk aan 2.6.40 begonnen. Op de Linux Kernel Mailing List heeft Torvalds aangegeven dat het merge window voor deze nieuwe kernelversie wordt verkort, omdat hij eind deze maand naar de LinuxCon Japan-conferentie gaat. Opvallender is dat Torvalds aangeeft te overwegen om op versie '2.6.40' een ander versienummer te plakken en de sprong te maken naar 2.8 of zelfs 3.0.

De Linux-goeroe speelt ook met de gedachte om de manier van versienummering te herzien. Volgende kernelreleases zouden bijvoorbeeld 3.1 en 3.2 als versienummer moeten krijgen, terwijl het derde getal een stabiele release moet aangeven, zoals 3.1.1. Torvalds is niet de enige die de versienummering van de Linux-kernel wil aanpassen. Een aantal kernelontwikkelaars is voorstander van een versienummering op basis van de releasedatum, terwijl een kleine groep de 2.6.x-nummering trouw wil blijven.

Of en wanneer Torvalds de vernieuwde versienummering invoert, is nog niet duidelijk. Vermoedelijk houdt de discussie nog wel enige tijd aan, terwijl kernel 2.6.40 wordt klaargestoomd. Deze krijgt onder andere verbeterde ondersteuning voor Intels Sandy Bridge-platform en moet een eerste aanzet bevatten voor Ivy Bridge-hardware, eveneens van Intel. Ook het stroombesparende Nvidia Optimus-systeem zou in de eerstvolgende Linux-kernel kunnen worden aangesproken.

Reacties (57)

[manuarmata]

het is wel zo dat versie 2.6 al behoorlijk lang standhoud en dat er sinds 2.6.1 welliswaar inder de vorm van kleine tussenstapjes al erg veel veranderd is. mocht men maar eenmaal per jaar een nieuwe release doen zat men met de huidige logica waarschijnlijk al aan kernel 4.x omdat de veranderingen tussen de 2 versies spectaculairder zou zijn. men zou naar een systeem moeten gaan waarbij men van pakweg 2.6.x naar 2.8 gaat als versie 2.6.1 en 2.6.x een vooraf bepaald aantal verschillen overschrijd. nu zou je als leek het vals gevoel kunnen krijgen dat kernel 2.6.1 nog steeds up to date is of dat men al acht jaar de kernel bijna niet meer verder heeft ontwikkeld .

Dat met al acht jaar bij kernel 2.6 zit heeft waarschijnlijk ook te maken met het feit dat men de versienummering heeft bepaald toen de kernel jong en incompleet was en er heel veel ruimte was voor vernieuwing en verbetering. nu volgt men voornaamlijk gewoon de evolutie mee.

Ik volg linus zijn standpunt volledig maar zou anderzijds wel opletten met toestanden zoals bij google chrome.
Ter verduidelijking een summier overzicht van enkele belangerijke versies.

1.0 13 maart 1994
1.0.9 16 april 1994

1.2 7 maart 1995
1.2.13 2 augustus 1995

2.0 9 juni 1996
2.0.40 8 februari 2004

2.2 26 januari 1999
2.2.26 25 februari 2004

2.4 4 januari 2001
2.4.37 2 december 2008

2.6 18 december 2003
2.6.39 19 mei 2011

[Reactie gewijzigd door manuarmata op 22 juli 2024 22:26]

[mvdejong]

Marketing-driven, veranderingen achter het eerste cijfer suggereren dat er geen al te spectaculaire wijzigingen zijn. Een veranderingen in het eerste cijfer wekt de indruk dat het echt fundamenteel anders is.

Zo had Sun Microsystems aanvankelijk een nummering voor het Solaris operating-system van 2.5, 2.6 maar daardoor leek er t.o.v. de concurrentie te weinig echt te veranderen, dus lieten ze het eerste cijfer vallen en leek het veel spectaculairder, met Solaris 7, 8, enz.

Om het echt onoverzichtelijk te maken, historisch heb je Solaris 1.x, gebaseerd op SunOS 4.x, een BSD-kernel, en Solaris 2.x, gebaseerd op SunOS 5.x, een SVR4 (System V Release 4) kernel.

[supersnathan94]

waarom zouden ze van 2.6.40 naar 2.8 gaan? waarom niet gewoon 2.7? lijkt mij veel logischer of hebben ze het altijd in stappen van 2 gedaan?

[RubenBentein]

Oneven is ontwikkelingskernel

Edit:

Het eerste getal wordt gebruikt om zeer radicale veranderingen aan te geven. Als het tweede getal even is, betekent dat dat het gaat om een productiekernel; een oneven getal betekent dat het een ontwikkelingskernel is. Elke versie van de kernel wordt bovendien gevolgd door kleinere bijwerkingen die fouten oplossen. Dit patchlevel is herkenbaar aan het derde getal.

[Reactie gewijzigd door RubenBentein op 22 juli 2024 22:26]

[bzerk]

oneven WAS de ontwikkelkernel.
Hiervan is afgestapt bij 2.6

[postbus51]

In principe zijn alle RC nu een Ontwikkelkernel met eventuele instabiliteit (hoewel dit altijd kan , regressie door middel van patches welke later in beeld komen)

[jj71]

Daar zit een hele geschiedenis achter... vroeger waren de kernels waarbij het tweede versie-getal oneven was de onstabiele ontwikkelversies, terwijl de kernels waarbij het tweede getal even was de stabiele productieversies. Ik denk niet dat ze dat nog steeds zo doen, maar dat zal wel de reden zijn waarom er nu 2.4, 2.6, 2.8 enz. wordt gebruikt.

Overigens vind ik "het getalletje is te hoog" niet echt een goede reden om naar een volgend nieuw major versienummer te gaan... je zou verwachten dat dat betekent dat er een grote rewrite is geweest van het systeem met wellicht incompatible wijzigingen.

[Anoniem: 296748]

Wat ik vreemd vind is dat er serieus gedicusseerd wordt over het versienummertje. De gemiddelde consument heeft geen idee wat het betekent (en gebruikt wss geen Linux ), en de meer ervaren computergebruiker weet hoe het systeem werkt.

Waarom zou je dan veranderen? Iedereen is nu toch gewoon blij. Proberen ze nou een illusie van extra vooruitgang creeren door de versienummers sneller toe te laten nemen?

Straks krijgen we nog onzin namen als Linux Kernel 12.9 Hyper XFX... Puur omdat het snel en krachtig klinkt. Doe mij maar gewoon de oude vertrouwde nummering.

[supersnathan94]

De gemiddelde consument heeft geen idee wat het betekent (en gebruikt wss geen Linux

dat eerste klopt, maar dat tweede niet. de linux kernel is namelijk de basis voor heel veel elektronica zoals telefoons, netwerkapparatuur en dvdspelers. linux is heel krachtig en is in het dagelijks leven eigenlijk onmisbaar. veel mensen hebben dat helaas alleen niet door.

overigens ben ik het ook niet echt eens met de reden om naar een nieuw nummer over te stappen. het is te hoog. ja lekker belangrijk van mij part ga je door tot 2.6.356153425635224. voor de die-hard linux fans is dat natuurlijk veel makkelijker te onthouden. net als bij iOS 4.3.3. het eerste getal staat voor de major release, het tweede voor wat wijzigingen in een minor release en het derde getal zijn bugfixes. eventueel nog met aanduiding erachter als het jailbroken firmware is. zo heel moeilijk is het toch niet? het systeem van linux klinkt mij ook heel logisch in de oren alleen snap ik nog niet waar die twee dan voor staat, als 6 al een major update betekent.

[RubenBentein]

De discussie gaat hem erover dat de nummering te hoog oploopt (het laatste cijfer). Ik vraag me wel af wie juist bepaalt of een nieuwe ontwikkeling aan de kernel een ophoging waard is van het eerste, tweede, of derde cijfer.

Langs de andere kant vind ik een nummering gebaseerd op de datum ook heel handig. Dan weet je direct hoe 'oud' je kernel is, en dat het eens tijd wordt om up te daten

Voor versies zoals 12 Hyper xfx of Linux Vista Ultimate zit ik wel niet te wachten

[RielN]

Een kernel moet zo oud zijn als je hardware vind ik. Als het functioneert is een update niet nodig.

[Anoniem: 196662]

Het werkt tot het kapot gaKERNEL PANIC

[Anoniem: 35352]

Ik vraag me wel af wie juist bepaalt of een nieuwe ontwikkeling aan de kernel een ophoging waard is van het eerste, tweede, of derde cijfer.

Het antwoord daarop is simpel: Linus bepaalt dat.

[Anoniem: 295700]

Incompatibele wijzigingen en grote rewrites kun je nu al tussen de minor versienummers vinden. Ze zouden beter een enkelvoudig releasenummer kunnen hanteren.

[wildhagen]

De oneven nummers zijn toch gereserveerd voor development-branches, en niet voor stable branches bedoeld? Of is dat systeem losgelaten tegenwoordig? Vroeger was dit in ieder geval wel de filosofie erachter.

[arjankoole]

Dat was inderdaad vroeger het geval, maar die filosofie is al een tijdje geleden geschrapt. Desalnietemin denk ik dat ze er wel rekening mee houden, om verwarring te voorkomen.

[Jesse]

Eigenlijk zijn ze daar sinds 2.6 uit is van afgestapt.
Een belangrijke reden is volgens mij dat het te lang duurde totdat verbeteringen bij de eindgebruiker terecht kwamen, terwijl daarnaast de grondigheid van het testen in de oneven-branch tegenviel.
Ook toen 2.6 uitkwam heeft het een paar releases geduurd voordat de grote distro's die standaard gingen gebruiken. In de tussentijd zaten die grote distro's weer features (uit 2.5) in 2.4 te bouwen, waardoor de geloofwaardigheid als 'stabiele' branch weer minder werd, terwijl het onderhoud van 2.4 een ondergeschoven kindje werd, omdat men liever aan de nieuwe dingen werkte.

[Blokker_1999]

Een oneven getal in het midden duid op een onstabiele versie. Zo was 2.5 de ontwikkelversie van 2.6 . Alleen was er toen wel degelijk een verschil tussen 2.4 en de toekomstige 2.6 . Zulke grote veranderingen staan blijkbaar niet meer op til waardoor men de versienummering op de schop wenst te nemen

[arjankoole]

waarom zouden ze van 2.6.40 naar 2.8 gaan? waarom niet gewoon 2.7? lijkt mij veel logischer of hebben ze het altijd in stappen van 2 gedaan?

van oudser duide het 2e cijfer, indien een oneven getal, een development release aan. Alhoewel dat al lang niet meer het geval is, denk ik dat ze verwarring willen voorkomen op dat vlak.

[gday]

Omdat de oneven minor versienummers bedoeld zijn voor development releases. De even nummers zijn voor stabiele releases.

[MindStorm]

Op dit moment geven even getallen stable releases aan, oneven zijn alleen voor tests. Vroegere linux kernel releases hadden 2.0, 2.2 of 2.4.

[Eagle Creek]

Wat zijn ze toch moeilijk aan het doen met versienummers de laatste tijd. Chrome lijkt begonnen met zijn enorme jumps, en Firefox gaat hen nu achterna.

Nu wil Linux ook al gaan jumpen. Ik heb altijd geleerd dat hoe groter je wijziging, hoe groter de versie'hop'. Kleine wijzigingen komen achter de punt, nog kleiner nog verder achter de punt.

Ik vraag me echt af of we straks "Firefox 24.4", Chrome 58" of Linux "17.2" draaien of zo.

[ILUsion]

Volgens mij zal Linus wel niet meegaan in die versie-oorlog zoals bij de browsers tegenwoordig en dat is ook een compleet andere wereld.

In de browserwereld moet je de computerleken weten te binden; als je een nieuwe versie hebt, slijt je die liefst zo snel mogelijk aan je eigen gebruikers en aan mogelijke nieuwe gebruikers. Als je daar met versie 3.6.1 aankomt en die opwaardeert naar 3.6.2 en vervolgens naar 3.6.3 etc., dan ben je dat veel sneller vergeten ("wat was de laatste versie ook alweer?") en ga je dus ook minder snel updates doen (voor zover die niet automatisch gebeuren) en dat is voor de meeste partijen een slechte zaak (voor jezelf vooral qua veiligheid en nieuwe features; voor de maker omdat ze veel tijd moeten steken in ondersteuning van oude producten en omdat de sociale features hen meer data verschaft in wat de mensen eigenlijk doen). Maar als je dan afkomt met "de nieuwe Chrome 11" of "Internet Explorer 9", "Firefox 5", dat kunnen de mensen wel onthouden en vergelijken. Ook voor onderlinge concurrentie moeten al die makers elkaar wel volgen, veel mensen denken immers in termen van "meer is beter", dus versie 5 moet toch wel beter zijn dan versie 3.6, het maakt dan niet uit dat we IE 5 vergelijken met Firefox 3.6: "meer is beter"; maar zo gaat het nu eenmaal en zo ging het met IE versus Netscape ook al. Dus de inflatie van de versienummers bij Firefox zijn op die manier zeker en vast te verklaren; de komende maanden zullen ze snel stijgen maar nadien zal dat wel afvlakken.

Wat de Linux-kernel betreft, kan ik me wel vinden in het ophogen van de minor-versie; een major-versie is misschien wat overdreven, omdat de stap niet zo groot is als tussen 2.2, 2.4 en 2.6; maar ondertussen weet ik eignelijk niet meer welke kernel ik hier draai; het is ergens in de 2.6.3x. Door naar 2.8 te gaan, wordt dat toch enige tijd weer wat eenvoudiger (hoewel het natuurlijk helemaal makkelijk zou worden met datums al versienummer).

[bbob]

Versienummer moeten eigenlijk niets uitmaken maar ja het is gewoon marketing.

Het klinkt natuurlijk leuker als je linux versie 3 hebt i.p.v 2.6.5.0.

Denk dat marketing dan ook een beetje de reden is om de versienummers te wijzigen. Voor een techneut maakt het uiteindelijk niets uit welk nummer je erop plakt, maar voor een doorsnee gebruiker is een versienummer hoe hoger een indicatie dat ze denken iets nieuws en nog beters te krijgen.

[Tsurany]

Je creëert er echter ook weer bepaalde verwachtingen mee. Als je van 2.6.38 direct naar 3.0 gaat verwachten mensen vaak drastische verbeteringen die zo'n grote sprong in versienummers verdiend. Zeker als je een sprong van versie 2 naar versie 3 maakt, dan verwacht je wel iets drastisch.

[zenlord]

Daarmee dat bepaalde devs hadden gesuggereerd om de sprong naar v3 te doen op het ogenblik dat de 'big block'-bug oid werd verwijderd, maar dat punt zijn we met 2.6.37 voorbij.

Nu zou men kunnen stellen dat vanaf v3 de ARM-code is opgeruimd.

[metaal]

Volgens mij heb je het over de BKL, ofwel de "Big Kernel Lock" (klok, klepel, etc). Is niet bepaald een bug, maar een mechanisme wat sinds de eerste versie van Linux die op SMP systemen kon draaien aanwezig was. Dit was nogal een lomp systeem om te voorkomen dat threads die op verschillende CPU's draaien elkaar in de weg zitten. Uiteindelijk beperkte de BKL de schaalbaarheid (in het aantal CPU cores) van Linux. De laatste releases van Linux is er hard aan gewerkt om deze lock eruit te halen. In 2.6.37 kan je de BKL nu helemaal uitschakelen, in 2.6.38 of 39 (weet ik niet meer) is deze nu helemaal verwijderd.

Omdat de BKL zo enorm verwoven zat met zo'n beetje elke module in de kernel vonden sommige mensen het een mooie mijlpaal om naar 2.8 of 3.0 te gaan. Dat is dus niet gebeurd.

Nu zou men kunnen stellen dat vanaf v3 de ARM-code is opgeruimd.

Volgens mij bedoel je dat er wordt geoppert de ARM architectuur code op te ruimen voordat de boel met versie 3.0 wordt gelabelled. Gaat waarschijnlijk niet gebeuren.

[bartje]

uhm niet om het een of ander,
maar je hebt geen linux versie, hoorguit een linux-kernel versie
en deze kernel kan dan geimplementeerd worden in een linux-distributie.
als het om marketing gaat zouden ze iets moeten doen aan de nummerting van de distributies zoals bij bijvoorbeeld ubuntu al gebeurd.

het gaat niet over marketing maar over overzicht denk ik.
als 2.6.20 heel veel scheelt van 2.6.40 ofzo is dat voor niemand echt duidelijk. ik zou dan denken hooguit een paar bugfixes ofzo.
Ik weet dat het verschil tussen 2.4 en 2.6 heel groot was, met name de firewall. maar verder weet ik niet wat er in kernel 2.6 allemaal verder is ontwikkeld.

De versienummering zou natuurlijk ook met implementatie te maken kunnen hebben omdat het implementeren van een kernel met een gelijksoortig serienummer geen actie vereist van overstap naar versie 3 wel.

[MtC]

klok, klepel?

linux IS een kernel. En een distributie is eigenlijk geen linux-distributie maar een GNU/Linux-distributie. Wel even je feiten checken he.

[IStealYourGun]

Versienummers zijn eigenlijk wel belangrijk bij de Linux kernel i.v.m de hard- en software ondersteuning. Je moet niet vreemd staan kijken als een distributie met een kernel versie lager dan 2.6.37 niet draait op een PC met Sandy Bridge.

Bij veel software is het eerder een manier om het aantal features aan te duiden en is het inderdaad een stuk marketing, maar bij Linux is het eerder een kwestie van ondersteuning.

[foobar79]

Dit is alleen voor vanilla kernels.
Hardware ondersteuning en soms ook features worden door de distributies ge-backport naar oudere kernel versies.

[Anoniem: 91169]

Het klinkt natuurlijk leuker als je linux versie 3 hebt i.p.v 2.6.5.0.

Het klinkt nog leuker als je de versienummers van de diverse distributies gebruikt. Die zitten in de dubbele cijfers.

[trab_78]

Al dat ingewikkelde gedoe met nummeringsschema's... Vroeg of laat wordt er toch weer van afgeweken. Waarom niet gewoon een oplopend nummer per release? Geen punten of andere scheidingstekens, gewoon een nummer. Misschien wel handig om het met voorloopnullen te schrijven, zodat ook bij alfabetische ordening de volgorde klopt.

[ZpAz]

Dus dan krijg je binnen 3 week versie 2384 omdat elke patch meegenomen wordt? Lijkt me niet dat dat wenselijk is.

[springtouwtje]

dat heet een "build", wordt al toegepast. Het nadeel is dat je aan sec een hoger build nummer niet kunt zien of er alleen bugs zijn opgelost of dat er ook functionaliteit is gewijzigd.

[Anoniem: 112442]

Ik hoop dat er weer een development kernel terug komt.

Doordat de huidige kernel een stabiele kernel is komen er geen experimentele/revolutionaire zaken meer in.

Tav de nummering.
Als het normale stramien volgt kun je de kernel zeker niet 3.0 noemen omdat de stap tussen 2.6 en 3.0 vele malen kleiner is dan tussen 2.0-2.2, 2.2.-2.4 of 2.4-2.6.

Waarschijnlijk inderdaad een commerciële beslissing, op zich wel jammer. Aangezien Linux primair niet een commercieel OS is.

[RielN]

Linux 3.0 zou het echter in de volksmond goed doen. het is nu ook weer niet zo dat een beetje commercie linux slecht af gaat. Ze mogen best even meedoen in de roerende OS markt momenteel.

Billboards met TUX? Laat maar komen.

[Raventhorn]

Dan kan je beter promoten met distro's en niet met de kernel zelf...
Op die manier ziet men ook wat de Linux kernel in combinatie met pakketten kan doen voor ze en evt. mensen overhalen om het te proberen. Komen we nog eens van de dictatuur van M$ af en word het voor ontwikkelaars ook interessanter.

Offtopic:

Billboards met TUX? Laat maar komen.

Die wil ik in m'n kamer!

[Rmg]

Kernel versie is helemaal niet interessant voor marketing. NIEMAND praat over linux kernel versie 2.6.40 maar over distributie en dan de versie (ubuntu 10.10 / 11.01 etc etc.)

Ik denk dat een groot deel van de linux gebruikers op de vraag van "Welke kernel draai je?" iets zal antwoorden als Ubuntu x.x of redhat 6 of iets in die trend

Het versie nummer systeem voor de kernel is geboren om snel te kunnen zien of je een stable versie gebruikt of niet en welke patch versie (iets wat voor techneuten juist interessant is. nu stable/unstable niet echt meer gebruikt wordt wordt het gewoon tijd om de nummering aan te passen, zit weinig marketing achter

[Reactie gewijzigd door Rmg op 22 juli 2024 22:26]

[Anoniem: 96523]

Tegenwoordig, met name in de Android custom rom wereld, is de kernel versie zeker wel belangrijk. En ook op server niveau is het erg belangrijk om te weten welke kernel je draait, ipv van "uhhh... Redhat?"

Voor de consumenten markt is het inderdaad nutteloos om te weten welke versie je hebt, zoals het geval bij browsers. Voor de ontwikkelaars is het zeker wel belangrijk, maar voor hen maakt het niet veel uit hoe de nummering werkt, als het maar consequent is.

[LessRam]

Alle software gewoon naar datum nummeren en evt. een letter er achter wanneer je op één dag meerdere releases hebt. Makkelijk en overzichtelijk. 2011.05.24c

[psyBSD]

En hoe leg ik het verschil uit tussen een nieuwe release 2011.05.24 - dat een nieuwe feature toevoegd en 2011.05.24a dat een bugfix bevat op 2011.05.23?

[Edek]

Even gekeken op Wikipedia, daaruit blijkt dat de Linux versie nummering als volgt gaat:
A.B.C
A staat voor een enorme wijziging in de kernel
B staat voor grote veranderingen
C staat voor kleine aanpassingen (nieuwe drivers, bugfixes enz.)

[Goderic]

quote: wikipedia

After the 1.0 release and prior to version 2.6, the version was composed as "A.B.C"

Dat is al lang niet meer zo.

Momenteel gaat de versienummering zo: 2.6.x.y Elke 2 à drie maand komt er een nieuwe 2.6.x versie uit, met verschillende verbeteringen en bug fixes (hangt af van wat de devs gedaan hebben, dit kunnen grote en/of kleine wijzigingen zijn). De y versie bevat enkel bugfixes en security patches.

[Skinkie]

Zou mij het logisch zijn als voor v3 echt nieuwe technologie aanwezig zijn. Denk aan het schrappen van Ext2/3 technologie en alleen het meeleveren van Ext4 (die overigens de eerste twee ook kan mounten). Belangerijke zaken als Brtrfs eerst stabiel krijgen, alvorens naar een versie 3 te gaan. Zoals al eerder genoemd behalve marketing is er ook een verwachtings patroon. Je wilt er eigenlijk 100% vanuit kunnen gaan dat 3 stabiel is op het moment van release.