Hoofdcategorieën
Device Settings

Linux-kernel gaat andere versienummering gebruiken

Door Ronald van den Blink, zondag 6 maart 2005 20:06
Bron: Kerneltrap, views: 18.205

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.

Linux pinguinGebruikers 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.

Volgende 20:35 Intel schuldig bevonden aan overtreden antitrustwetgeving
Vorige 15:34 Beslissing softwarepatenten mogelijk uitgesteld
Advertentie

Reacties

«  1  2  »

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

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 :)

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

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.

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.

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).

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.

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.

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.

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.

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

"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.

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 :Y)*

*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.

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)


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...

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.


Als je onder de titel kijkt, daar waar de auteur ('vertaler') van het verhaaltje kijkt zie je daar ook - een gerelateerde link - naar één van de Kerneltrap artikelen hierover.

De /. link was er niet te vinden inderdaad.

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.
«  1  2  »

Op dit item kan niet meer gereageerd worden.

Volgende 20:35 Intel schuldig bevonden aan overtreden antitrustwetgeving
Vorige 15:34 Beslissing softwarepatenten mogelijk uitgesteld
VNU Media logo Hosted by True

© 1998 - 2012 Tweakers.net B.V. - Alle rechten voorbehouden - Contact - Jouw privacy - Algemene Voorwaarden

Uitgever van:

Website van het jaar 2011