Linux-kernel gaat andere versienummering gebruiken

Linus Torvalds heeft een beslissing genomen over de versienummering van de Linux-kernel. In tegenstelling tot het voorstel van een aantal kernelontwikkelaars om onderscheid te maken tussen de even en oneven nummers van de kernel zal de Linux-kernel gebruik gaan maken van een extra nummer. De 2.6-kernelbranch zal dan voorzien worden van een 2.6.x.y-nummering, waar de y-versies van de kernel minder ingrijpende patches zullen bevatten. Torvalds waarschuwt wel voor het feit dat het beheren van deze y-versies van de kernel een ondankbare taak kan worden.

Gebruikers verwachten namelijk dat de kernelversies gewoon werken en dat eventuele patches de functionaliteit verbeteren, terwijl het voor zal komen dat een patch de kernel dusdanig verandert dat deze niet meer naar wens functioneert. Ondanks deze waarschuwing staat Torvalds wel achter het voorstel en geeft aan dat het goed kan werken als er enkele technische eisen gesteld worden aan de patches. Zo stelt Torvalds voor om een patch te beperken tot een maximale lengte van 100 regels en dat alleen patches in de kernel opgenomen worden die kernel-oopses, een hangende kernel of kritieke lekken oplossen. Als beheerder van deze patchversie van de kernel heeft Greg KH zich aangeboden.

Reacties (41)

"Zo stelt Torvalds voor om een patch te beperken tot een maximale lengte van 100 regels en dat alleen patches in de kernel opgenomen worden die kernel-oopses, een hangende kernel of kritieke lekken oplossen."

Zal dat niet min of meer leidden tot het afraffelen van stukken code om het binnen 100 regels te krijgen, omdat het anders niet meer onder de titel "patch" valt? Of is afraffelen op niet mogelijk (ik ben absoluut geen Linux-kenner)

Ik neem aan dat een patch nog steeds goedgekeurd moet worden door de maintainer, dus dat soort dingen zal niet snel gebeuren denk ik.

deze Patches zijn aanpassing van bestaande code die niet goed werkt. deze source wordt door een patch hier en daar veranderd. een patch langer dan 100 regels betekent dat er 100 rgels fout/ontbraken in de voorgaande code.

dan is 100 vrij veel.

Ik denk dat feature patches hier niet tussen vallen. want deze passen de source aan niet om fouten er uit tehalen maar voegen nieuwe mogelijk heden toe.

freeswan
bootsplash
bluez (was eerst ook een patch zit nu in de kernel)
selinux (patch van de nsa zit nu ook standaard in de kernel)

Dat zal wel een 'richtlijn' zijn. Hij verwacht dat je meeste kleine bugs opgelost worden binnen de 100 regels, maar als er een belangrijke bug gefixed kan worden in 105 regels dan zal dat ook geen probleem zijn.

Hint: Gewoon de enters schrappen en doortikken op 1 regel )*

*nee, niet happen.

Die vervolgens niet geaccepteerd wordt omdat er zoiets als codingstyle gehandhaafd wordt. Zie ook Documentation/CodingStyle, alles > 80 kolommen is not done ivm. leesbaarheid.

The limit on the length of lines is 80 columns and this is a hard limit.

Dat is zeker interessant in het licht van de praat van Alan Cox die hij afgelopen weekend op FOSDEM gaf, "Building a stable kernel".

Alan heeft uitgelegd dat er meestal te weinig mensen zijn die -rc (Release Candidates) testen, en dat daarom wel eens fouten erin blijven zitten als "stable" (dwz. 2.6.x) uitgegeven wordt. Dit probleem treedt voornamelijk met het nieuwere development model op, waarin heel veel meer per 2.6.x release gebeurt dan het ooit het geval was. Hij zei ook dat fixes meestal wel duidelijk blijken, maar dat het lang niet altijd makkelijk is:

- Linus wil dat fixes "mooi" zijn, Alan vindt het belangrijk dat de fixes vooral fixes zijn en niet nieuwe problemen introduceren. Alan accepteert dus ook 'hacky fixes', die Linus nooit zal opnemen.
- Release candidates bevatten teveel nieuwe code om als stable gebruikt te worden, vooral in productieomgevingen.
- Je kunt nooit helemaal alle gevolgen van een fix inschatten, dus wil je in een stabiliserende release zo weinig mogelijk fixes hebben (dit komt overeen met wat Greg en Chris voor de 2.6.x.y versie doen, alleen echt broodnodige fixes die na review door een aantal topdevelopers goedgekeurd zijn). Er zijn verschillende soorten problemen: Domme fouten (typo's bijvoorbeeld), maar ook designproblemen. De laatste zijn erg moeilijk zonder bijwerkingen te verhelpen.
- Tenslotte moet geregeld worden, dat de fixes uit 2.6.x.y ook in 2.6.x+1 opgenomen worden. Dat lijkt logisch, maar heeft ook nog een aantal aandachtspunten: Mogelijk wil je in een 2.6.x release geen hacky fix uit een 2.6.x-1.y overnemen, omdat het probleem al anders (netter) gefixed is, of simpelweg niet van toepassing is. Er moet dus nog extra gekeken worden wat wel en niet over moet.

Ik verwacht dat de 2.6.x.y tree erg conservatief qua fixes is (in 2.6.11.1 zitten zo'n 4 patches) en alleen "my system is screwed" problemen oplossen, die met een 'non-intrusive' patch op te lossen zijn. Greg en Chris (de "$suckers" die 2.6.x.y maintainen) zullen goed kijken wat Alan heeft, wat in -as zit, en uiteraard nog extra dingen die hun nodig en toepasbaar lijken) opnemen.

Deze stap lijkt me trouwens logisch, nadat Linus een tijdje geleden heeft aangekondigt voorlopig nog maar geen 2.7 te beginnen aangezien zijn werk samen met Andrew Morton (-mm) erg efficient is, en het gewoon goed werkt. De ontwikkeling ging nooit eerder zo hard terwijl de stabiliteit naar verhouding weinig te lijden had.

Hoe kan het dat een enkele persoon een beslissing kan/mag nemen over een kernel van een besturingssysteem wat in in de hogere regionen van business omgevingen draait en deze persoon dat ook nog tegen de adviezen van de andere kernel ontwikkelaars in doet.

Ik volg dat echt even niet. En dan vragen mensen zich af waarom er nog niet zo veel vertrouwen is in Linux voor bedrijfsomgevingen.

De macht van Linus is imo te groot, er moet voor dergelijke zaken een board van directors komen die tezamen met de industrie dergelijke beslissingen nemen, in het grotere belang.

Je bent vrij om je eigen fork te starten als je geen vertrouwen hebt in Linus, Andrew en consorten.

Heel makkelijk: Het gebeurt zo simpelweg niet. Linus released een kernelversie en vervolgens gooien er de distro maintainers (Andrew Salomon voor Debian, Alan Cox voor RedHat en ik dacht Stefan Seyfried voor SuSE) nog wat patches overheen om bepaalde features toe te voegen, mogelijke fixes, e.d..

Een vanilla kernel komt niet zomaar in een distro, en al helemaal niet automatisch, dwz. zonder reviewing, testing en feedback.

Jouw opmerking is dus helemaal niet van toepassing, je mening klinkt leuk, maar je snapt blijkbaar te weinig van hoe't in z'n werk gaat om er wat zinnigs over te zeggen,

With that said, no flame intended. :-)

Hoezo macht van Linus te groot? Als er iemand is die weinig te vertellen heeft over wat er met "zijn" product gebeurt dan is hij het wel. Als je het niet met zijn beslissingen eens bent dan kun je zonder expliciet om toestemming te vragen een eigen versie van de kernel maken en daarmee doen wat je zelf het beste acht. Democratie bepaalt vervolgens welke Linux-kernel beter is; de jouwe of die van Linus. Als genoeg anderen het met je eens zijn (en dus overstappen) dan kun je Linus dus praktisch buitenspel zetten (hoewel hij op zijn beurt weer met jouw versie verder kan gaan). Een dergelijk scenario is met de OS'en van bedrijven als Microsoft, Sun, IBM en HP onmogelijk, en in dat opzicht heeft Linus dus juist veel minder macht. Tot nu is iedereen het er schijnbaar over eens dat hij goed werk verricht, anders hadden we inmiddels al een alternatief gezien.

N.B. Het woord "jij" in bovenstaande alinea kan in theorie slaan op "jij persoonlijk", maar eigenlijk moet je het natuurlijk vervangen voor bijv. een groep bedrijven als Red Hat / Suse of een deel van de harde kern van ontwikkelaars.

Betekend dit nu ook het einde van het verschil tussen de oneven en de even subversies? Dus straks een 2.7.0.0 stable?

Voor zover ik het goed begrepen heb zijn de 2.6.x-rc versies eruit geflikkerd en is daar een 2.6.x.y voor in de plaats gekomen. Ik zie in ieder geval niets over verandering in de nummering van major versies (wat een 2.x versie toch wel betekent) in de grote discussies onder de bronpagina

-rc bestaat nog steeds. De 2.6.x.y versies zijn gewoon een overbrugging tussen 2.6.x en 2.6.x+1. Alan cox doet in zn uppie de -ac tree, welke ongeveer op hetzelfde uitkomt. Probleem met Alan Cox is dat ie alleen is, dus al ie ziek is, geen tijd heeft of op een FOSDEM staat te spreken over het een en ander, dat je geen security fix krijgt voor je kernel.

Stel, er wordt een bug gevonden mbt security. Fix heeft geen nadelige gevolgen, dus wordt er een 2.6.x.y release uitgerold. In plaats dat je onveilig blijft draaien met je 2.6.x kernel of jezelf waagt in de -pre en -rc versies, kan je nu een 2.6.x.y kernel nemen om veilig te zitten.

De huidige -pre en -rc release cycle zal nog wel een tijdje aanhouden. De -pre en -rc zijn puur om te testen voor de volgende -final, terwijl de .y versies gewoon onderhoudsreleases zijn.

Ik hoop het niet, dat zou de overzichtelijkheid m.i. niet ten goede komen. Ik vind dit systeem al redelijk ondoorzichtig nl...

Oude systeem werkte prima imo

Toch wel. Maar voorlopig nog niet. Voorlopig blijft de development in mm tree van Andrew Morton. Maar eens er grotere aanpassingen gaan gebeuren die enkele maanden nodig hebben om de stabiliseren dan pas wordt er overgeschakeld naar de 2.7 tree.

Lijkt me niet, wordt toch met geen woord over gerept?

De wereldwijd meest gebruikte versienummersystemen gebruiken het schema
major.minor en bij een patch major.minor.patch,
of
major.minor.build en bij een patch major.minor.patch.build.

Het is dan ook verwarrend dat voor de Linux 2.6-kernel niet een van deze systemen wordt gekozen, omdat dit aansluit bij wat gebruikelijk is. Bij 2.6.x.y zou je immers verwachten dat y het buildnummer is en niet het patchnummer.

major.minor.release.build is de standard vorm.

maar die word vaak creatief gebruikt, sommige resetten release bij elke minor andere weer niet. Sommige resetten de build na elke release. Sommige hanteren eigenlijk geen major (alles opgeschoven). Vaak worden fields met een '0' weggelaten.
Dus eigenlijk is er geen standard versie nummer vorm.

Bij de linux kernel werd de build dus ook gereset na elke release (een build is btw niet super interesant voor een source release).

Gebruikers verwachten namelijk dat de kernel-versies gewoon werken en dat eventuele patches de functionaliteit verbeteren, terwijl het voor zal komen dat een patch de kernel dusdanig veranderd dat deze niet meer naar wens functioneert.

Dus de remedie kan erger zijn dan de kwaal... als dit gebeurt in de stable branch mag er een niet te missen waarschuwing bij zitten, je mag namelijk inderdaad gewoon verwachten dat een kernel uit de stable gewoon naar behoren werkt.

Er is geen echte unstable kernel meer De 2.5 kernel was de dev-branch voor 2.6, en een 2.7 is er niet. Het idee van de introductie van deze nieuwe branch is juist om sneller patches te kunnen toepassen. Als je de zekerheid wil hebben dat alles goed werkt moet je gewoon bij de main-branch blijven, de 2.6.x dus... wil je up-to-date blijven en het risico nemen dat het broken is soms --> dan neem je 2.6.x.y

Dat is niet correct.
De 2.6.x.y branch bevatten enkel veilige bugfixes t.o.v. 2.6.x, en zijn dus per definitie stabieler dan 2.6.x.

De reden van de verandering is juist dat er in 2.6.x nieuwe features worden geïntroduceerd, die soms onstabiliteit veroorzaken voor sommige mensen. Uiteraard worden die dan tegen 2.6.(x+1) opgelost, maar dan zijn er weer andere nieuwe features toegevoegd, die weer andere stabiliteitsproblemen kunnen veroorzaken, enz...

Het doel is dus de bugs die ontdekt worden in 2.6.x, op te lossen in 2.6.x.y, zonder nieuwe features die risico's met zich meebrengen. Eens 2.6.(x+1) echter uit is, zal de 2.6.x.y niet meer verder ontwikkeld worden, en gaat men door met bugfixes in 2.6.(x+1).y. Die bugfixes komen dan samen met nieuwe features weer terecht in 2.6.(x+2), enz...

Het eerste voorbeeld is 2.6.11.1, die een bugfix bevat voor mensen met een Dell toetsenbord, en enkele compilatieproblemen voor PowerPC oplost t.o.v. 2.6.11.

Je hebt helemaal gelijk, alleen kan je er vanuit gaan dat bijv. de 2.6.x.y door de bugfixes af en toe minder stable zou zijn dan de main-branch.

Aangezien er zeer strenge eisen worden gesteld aan de fixes die in 2.6.x.y komen en nieuwe features worden geweerd lijkt mij dat vrij onwaarschijnlijk. Misschien op een dag gebeurt het wel dat er een nieuwe bug wordt geïntroduceerd in 2.6.x.y, maar dat zou dan echt wel een uitzonderlijke situatie zijn...

Als ik dit zo lees

And finally, the 2.6.x.y tree would only be maintained until 2.6.(x+1) was released, at which time 2.6.x.y would be completely frozen. During all this time, any fixes in the 2.6.x.y branch would be regularly merged into Linus' mainline tree. The proposal met favorable responses, and Greg KH volunteered to begin maintainership.

Dan zit er toch echt wel een risico aan. Sterker nog, of ik moet het heel verkeerd lezen, dit wijst erop dat de 2.6.x.y release een developpers release is, waar bij elke bugfix een nieuwe versie van komt, en dat al die bugfixes uiteindelijk in de main-branch komen. Ik kan me niet voorstellen dat er dan in de 2.6.x branch nog veel veranderd. Op die manier houd je namelijk altijd een onstabiele kernel. 2.6.x.y is niet stabiel want die wordt in een hoog tempo geupdate, en 2.6.x bevat nieuwe features. Ik ben dan nu ook wel heel erg benieuwd hoe het eruit gaat zien

Overigens denk ik dat m.n. de hoge snelheid waarin ze de 2.6.x.y variant willen brengen elke keer toch echt gaat zorgen voor bugs

Iedereen die een kernel zelf compiled behoort eerst de instructies te lezen waar dat dan ook in zal staan. En als je zo ver bent dat je een kernel gaat compilen zal je er ook wel wat van af weten.

127.0.0.1

255.255.255.255

Wilt u daar Sambal bij?

Dat was grappig geweest als je had getypt: "Wilt u daar Samba bij?"...nu is het enkel een non-sequitur.

En jij weet niet wat non sequitur betekent.

Dit is dus een mooie combo om de wenst van Linux (mooie patches) in vervulling te laten gaan, maar ook snel kunnen reageren. Lijkt me wel een goede ontwikkeling alleen moeten we er even aan wennen.

En dat het een ondankbare taak is...mja, dat is maar hoe je het ziet. Je maakt geen nieuwe features maar je helpt wel weer mensen die tegen de bug opbotsen.

dat was een foutje. net na de release kwamen ze erachter dat er een flinke domme fout in zat, die ff gefixed is.

dit word anders: er komt een 2.6.x uit, dan gaat "the sucker" (zoals linus em noemt) elke paar dagen een 2.6.x.y uitbrengen, die ABSOLUUT (voor zover dat menselijk te bepalen is) beter is dan de 2.6.x. die zekerheid heb je, omdat er echt alleen hele obvious fixes in komen, dingen die een duidelijk, afgebakend probleem oplossen op een eenvoudige manier. Zodra er een 2.6.x+1 uitkomt, stopt de sucker met 2.6.x.y, en begint aan 2.6.x+1.y.

Inderdaad zat ik ook aan te denken, is wel de eerste keer ook dat ik dat in ieder geval tegen ben gekomen bij de linux kernel. Het ging daar ook om een belangrijke fix...

Ach, voor de buitenstaander klinkt het wel aardig. Als er nu een 2.7 zou bestaan, zou die "hoger en dus beter" zijn terwijl het juist een testversie is. Met dit systeem klopt de aanname "hoger versienummer == betere versie" al beter.