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 , , 138 reacties

Linus Torvalds heeft de eerste release candidate van Linux-kernel 3.0 vrijgegeven. De Linux-goeroe sprak al eerder zijn twijfel uit over de vraag of de ontwikkel-kernel 2.6.39 uiteindelijk versienummer 2.8 of 3.0 moest krijgen.

TuxDe allereerste Linux-kernel in de 2.6-serie kwam zeven jaar geleden uit. Sindsdien werd het laatste versienummer steeds opgehoogd, maar Torvalds liet vorige week weten dat hij overwoog om de volgende release versie 2.8 of 3.0 mee te geven. Inmiddels is de kogel door de kerk en zal het versienummer worden opgehoogd naar de 3.0-serie. Volgens de Linux-goeroe gaven 'stemmen in zijn hoofd' aan dat de versienummers in de 2.6.x-serie te hoog waren opgelopen. Inmiddels is op Kernel.org een 3.0-rc1-directory aangemaakt.

De sprong naar de 3.0-serie heeft ook een symbolische betekenis: de Linux-kernel zal later dit jaar twintig jaar oud zijn en gaat daarmee zijn derde decennium in. Toekomstige kernelversies zullen versienummers 3.1 en 3.2 meekrijgen. Torvalds geeft echter aan dat de kernel ondanks de sprong naar versienummer 3.0 geen grote wijzigingen bevat.

De vernieuwde 3.0-kernel bevat wel ondersteuning voor nieuwe hardware van Intel, zoals het Sandy Bridge-platform en Ivy Bridge-hardware. Ook is er flink gesleuteld aan het nog steeds experimentele btrfs-bestandssysteem en er zijn nieuwe drivers aan de kernel toegevoegd. Vermoedelijk zal de release candidate over zeven tot negen weken afgelost worden door de final 3.0-kernel.

Moderatie-faq Wijzig weergave

Reacties (138)

Ik heb hem nog niet voorbij zien komen, maar Linus is héél duidelijk in zijn motivatie voor dit nummer:

https://lkml.org/lkml/2011/5/29/204
Yay! Let the bikeshed painting discussions about version numbering
begin (or at least re-start).

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.

The whole renumbering was discussed at last years Kernel Summit, and
there was a plan to take it up this year too. But let's face it -
what's the point of being in charge if you can't pick the bike shed
color without holding a referendum on it? So I'm just going all
alpha-male, and just renumbering it. You'll like it.

Now, my alpha-maleness sadly does not actually extend to all the
scripts and Makefile rules, so the kernel is fighting back, and is
calling itself 3.0.0-rc1. We'll have the usual 6-7 weeks to wrestle it
into submission, and get scripts etc cleaned up, and the final release
should be just "3.0". The -stable team can use the third number for
their versioning.

So what are the big changes?

NOTHING. Absolutely nothing. Sure, we have the usual two thirds driver
changes, and a lot of random fixes, but the point is that 3.0 is
*just* about renumbering, we are very much *not* doing a KDE-4 or a
Gnome-3 here. No breakage, no special scary new features, nothing at
all like that. We've been doing time-based releases for many years
now, this is in no way about features. If you want an excuse for the
renumbering, you really should look at the time-based one ("20 years")
instead.

So no ABI changes, no API changes, no magical new features - just
steady plodding progress. In addition to the driver changes (and the
bulk really is driver updates), we've had some nice VFS cleanups,
various VM fixes, some nice initial ARM consolidation (yay!) and in
general this is supposed to be a fairly normal release cycle. The
merge window was a few days shorter than usual, but if that ends up
meaning a smaller release and a nice stable 3.0 release, that is all
good. There's absolutely no reason to aim for the traditional ".0"
problems that so many projects have.

In fact, I think that in addition to the shorter merge window, I'm
also considering make this one of my "Linus is being a difficult
^&^hole" releases, where I really want to be pretty strict about what
I pull during the stabilization window. Part of that is that I'm going
to be traveling next week with a slow atom laptop, so you had better
convince me I *really* want to pull from you, because that thing
really is not the most impressive piece of hardware ever built. It
does the "git" workflow quite well, but let's just say that compiling
the kernel is not quite the user experience I've gotten used to.

So be nice to me, and send me only really important fixes. And let's
make sure we really make the next release not just an all new shiny
number, but a good kernel too.

Ok?

Go forth and test,

Linus
Wat is er mis met 2.7 dat alleen 2.8 of 3.0 werd overwogen?

[Reactie gewijzigd door tes_shavon op 30 mei 2011 16:42]

Als ik het goed begreep zijn de oneven versienummers bedoeld voor developers en de even nummers dus releases naar de distributies toe. Maar dan blijft de vraag dus wel waarom 3.0 en niet 2.8.... denk dat het derde decennium er alleen mee te maken heeft.
Odd-numbered versions for development releases
Between the 1.0 and the 2.6.x series, the Linux kernel used odd minor version numbers to denote development releases and even minor version numbers to denote stable releases; see Linux kernel: Version numbering. For example, Linux 2.3 was a development family of the second major design of the Linux kernel, and Linux 2.4 was the stable release family that Linux 2.3 matured into. After the minor version number in the Linux kernel is the release number, in ascending order; for example, Linux 2.4.0 → Linux 2.4.22. Since the 2004 release of the 2.6 kernel, Linux no longer uses this system, and has a much shorter release cycle, instead now simply incrementing the third number, using a fourth number as necessary.
meer info http://en.wikipedia.org/wiki/Linux_kernel#Version_numbering

[Reactie gewijzigd door ultimasnake op 30 mei 2011 16:46]

Ik kan iedereen alleen maar aanbevelen om de linux kernel mailing list thread te lezen die in het artikel gelinkt staat. Het bevat alle rationale achter de verschillende opties (zowel 2.8 als 3.0). Je bent er in een 10minuutjes wel door.
Hier de discussie opnieuw houden (onder non-linux kenners) doet de originele thread enkel oneer aan.

Enkele punten waren:
- breken met de oneven/even redenering (daarom dus ook 3.0 en geen 2.8)
Nummering is dan ook 3.0, 3.1, 3.2, ... en de stable releases worden dan 3.0.1, 3.0.2, ...
- de 2.6 in 2.6.X betekent niets meer
- in datum-based versies zag men ook niets
- enkele mensen wilden een belangrijke changeset (bvb de ARM-tree cleanup of enkele maanden terug zelfs de big-kernel lock removal) als versie-bump zien, anderen wilden net door dit niet te doen aangeven dat er eigenlijk weinig verandert, behalve het nummertje.
enz...
Je spreekt over oneer terwijl het over versioning gaat, vind je dat zelf niet een beetje vergaand? ;-)

Anderzijds een mooie samenvatting van wat er beschreven is.
En dan was er nog eentje die wou wachten op 2.6.42. Da's net zoiets als Apache 1.3.37
Maar zo werkt het dus al 6-7 jaar niet meer.(wat ook wel in de link staat) Releases worden ook door de tijd bepaald, niet door features.
Maar veel mensen hebben dat idee nog wel, en om de verwarring te voorkomen hebben ze besloten om die nummers over te slaan.
van oudsher zijn oneven minor nummers altijd gebruikt voor development branches. Voordat de 2.6 kernel uit gebracht werd had je de stable (2.4) branch en de experimental/development branch (2.5). Toen 2.5 volwassen genoeg was, werd het opgehoogd naar 2.6. Daarna is er nooit meer een development brach gemaakt
Het tweede getal moet even zijn voor alle release versies, de oneven getallen zijn gereserveerd voor ontwikkelingsversies.
Zoals hierboven al meedere malen genoemd dat was zo. En de sprong naar 3.0 is dus om die verwarring eindelijk te stoppen.
0 is een even getal ;)


In de lijn van: 0, 2,4,6 en 8
Het viel me al op, ik wou vanmorgen 2.6.39 downloaden en toen zag ik ineens een 3.0 mapje staan, maar ik had nog niks in het nieuws gelezen erover. Ik was wel verbaasd kan ik je zeggen :)
Mooi rond getal voor 20jarig bestaan Linux ;)

[Reactie gewijzigd door Relief2009 op 30 mei 2011 16:55]

Ja, dat is die 3.0.... maar waarom naar 2.8 als je vanaf 2.6.39 komt...
Omdat vroeger de oneven reeks unstable was...
Dit is toch nog steeds het geval?
Nee, ze willen geen unstable releases meer uitbrengen, en dat wordt ook al niet meer gedaan sinds 2.5

Dus gewoon 3.0 - 3.1 - 3.2 .. 3.11 etc
Lol, 3.11 for workgroups :)
Oei dat gaat dan lang duren : linux millenium edition
Microsoft Windows "Tux". :')
Ontopic: Waarom is het zo lastig om te kiezen of het 2.xxx of 3.xxx word?
Als de Linux kernel dan toch later dit jaar 20 jaar bestaat, dan zou ik de keuze 3.xxx snel gemaakt hebben, maarja.
Maar jij hoort (hopelijk) niet de hele tijd stemmen in je hoof ;)
Eindelijk eens een comment waar ik om moet lachen wordt die weggemod.. Is humor verboden op tweakers? Of moet alles puur informatief zijn?

[Reactie gewijzigd door Rollo op 31 mei 2011 07:52]

grote versienummer veranderingen gaan traditioneel samen met inhoudelijk stevige veranderingen. Bugfixes en kleine aanpassingen zijn de kleinere nummers voor.

Dus aan de lijst van veranderingen zoals beschreven, is het niet nodig een versienummer verandering aan te brengen.
Ja, dat is die 3.0.... maar waarom naar 2.8 als je vanaf 2.6.39 komt...
Omdat volgens mij de oneven versienummers test of experimentele releases zijn. Daar was iets aparts mee dacht ik mij te herinneren.
Klopt dat was voor 2.6.0 (ergens 2003) 2.5 waren de voor lopers van 2.6 maar zijn nooit stabiel verklaart. Heel veel grote release nummers hebben dat gehad Maar dat is dus ook alweer bijna een decennia uit gedenderd. En nooit een behoefde geweest aan een 2.7 experiment. Blijkbaar voldoet Linux.

[Reactie gewijzigd door daft_dutch op 30 mei 2011 22:58]

20 jaar? Volgens mij en wikipedia klopt dat niet:
http://nl.wikipedia.org/wiki/Linux#Geschiedenis
Ik lees daar toch echt dat Torvalds in 1991 is begonnen met het bouwen van z'n eigen kernel. Wat klopt er volgens jou niet aan die 20 jaar dan?
Ben zelf geboren in 1991, weet toch wel 100% zeker dat ik 20 ben :+
hier van 1990 en ook nog voor een hele maand 20 :Y)
Omdat de eerste Linux kernel pas in 1994 werd uitgebracht.
1994 zou goed kunnen heb hier een slackware 3.0.0 versie liggen uit 1995, in de readme staat o.a deze tekst:

"This is Slackware Linux 3.0.0 (ELF).

This version contains libc 5.0.9, Linux kernels 1.2.13 and 1.3.18"

Dus 1.0 in 1994 lijkt me aardig juist

[Reactie gewijzigd door Ghoztmaster op 31 mei 2011 18:26]

hij heeft 10 jaar in coma gelegen.
hij heeft 2001 tot 2011 gemist dus hij denkt dat het nog 2001 is.
Volgens mij was GNU geen Linux distributie maar een voorloper van en toevoeging tot kernel ;)

[Reactie gewijzigd door kniftagstuh op 31 mei 2011 08:21]

Oooei!
GNU is de userland, dwz zo'n beetje alle belangrijke utilities die linux onder de motorkap gebruikt, aangevuld met nog wat andere zaken. Gnu wil al tientallen jaren een eigen kernel, maar bij gebrek daaraan is er destijds gekozen voor de linux kernel.
Gnu/Linux is dan ook een naam waar in het begin het gnu deel eigenlijk meer naam mocht hebben dan het linux deel, maar ondertussen is dat veranderd (hoewel gnu zonder linux (andere kernel) wel gaat lukken, gaat linux zonder gnu toch echt een probleem worden)
Wel waar, lezen is een kunst:
In 1992 en 1993 groeide Linux uit tot een volledig functionele kernel en kreeg het ook steeds meer aandacht. Verschillende bedrijven begonnen eigen distributies te ontwikkelen.
Moeilijk hè? ;)
Nou, ik ben de tel wel eens kwijt dus ik ben er wel blij mee.
Ik vind het nog steeds een vreemde motivatie om ineens een compleet versienummer te verhogen. Normaalgesproken wil de verhoging van een compleet versienummer zeggen dat er significante veranderingen aangebracht zijn.

Hiermee gooi je eigenlijk het hele concept van versienummers overboord.. Je kunt dan net zo goed buildnummers gebruiken (hoewel je dan wel nog onderscheid moet kunnen maken tussen finals en betas, maar dat terzijde).
Normaalgesproken wil de verhoging van een compleet versienummer zeggen dat er significante veranderingen aangebracht zijn.
Ik ben bang dat deze nummering alleen voor Commerciele software echt op gaat. Bij Microsoft bijvoorbeeld is het zaak dat ze eens in de pakweg, 3 jaar een nieuw besturingssysteem verkopen. Dit nieuwe OS heeft een heleboel veranderingen, mensen vinden het hip om te switchen of zien er juist tegen op, maar waarom ze honderden euro's moeten neerleggen is duidelijk: het is een nieuwe versie en uiteindelijk zal de oude niet meer ondersteund worden.

Vergelijk dat met Open Source software. Iedere toeovoeging wordt direct aan de community gereleased, zodra deze stabiel is. Linus (Linux Kernel), evenals bijvoorbeeld Mozilla (Firefox) of The Document Foundation (LibreOffice) heeft er geen enkel belang bij nieuwe features drie jaar op te sparen en ze in een keer uit te brengen. Dat zou een major versieophoging verantwoorden, maar de ontwikkeling van Linux alleen maar tegenwerken. In plaats daarvan kunnen ze meerdere strategieen toepassen:
  • Builds nummeren. Helaas is build 58648 niet zo intuitief
  • Kleine versienummeringen, maar zoals vermeld, 2.6.39 is dus ook niet zo intuitief
  • De versies noemen naar de datum, zoals Ubuntu dat doet, of in elk geval releasen op bepaalde tijdstippen
Let er op dat distributies als Ubuntu en OpenSuSE op tijd releasen, en hierdoor een taak van de softwaremakers hebben overgenomen. Waar je als Windows gebruiker pas een nieuwe Office versie koopt als je er aan toe bent, waardeer je bij Linux je hele systeem in een keer op. Voordeel hieraan is dat je niet "opeens" een nieuwe versie van Firefox krijgt voorgeschoteld(van 3.x naar 4.x bedoel ik, van 3.6 naar 3.7 gaat wel "vanzelf"). Nadeel is dat alvast een nieuwe Firefox nemen, maar nog even wachten met de nieuwe LibreOffice, lastig is.
Jij claimt dat
Iedere toeovoeging wordt direct aan de community gereleased, zodra deze stabiel is.
Dat is leuk maar zo werkt het niet. Wat er gebeurd is dat je ontwikkeld, test en uitbrengt. Oftewel elke toevoeging gaat door een testtraject. Maar aangezien veel toevoegingen impact op elkaar kunnen hebben kun je beter een set toevoegingen bundelen en gezamenlijk door het testtraject halen. Ook voor Open Source geldt dus dat je de ontwikkeling op een datum af moet hebben, gaat testen en daarna op een datum gaat releasen. Ubuntu (bijvoorbeeld) released twee keer per jaar en kiest weken voor die release datum welke versies meegenomen worden in de release. Dit kan dus prima met traditionele versie nummers.

Ook de kernel wordt niet continue gecompileerd en er worden keuzes gemaakt welke componenten worden meegenomen. Ook daar zijn traditionele versie nummers prima geschikt.

Eigenlijk heeft dus elke software belang bij een proces waarbij features worden opgespaard en gezamenlijk uitgebracht. Doe je het niet is je testtraject een ramp.

Tot slot een opmerking. Je aanname dat je bij Linux het systeem in 1 keer opwaardeert is alleen correct als je de software gebruikt die in de standaard distributie zit. In de meeste gevallen gebruiken mensen echter alsnog software die niet in de standaard distributie zit. (MySQL, Sun Java, Eclipse met plugins enz enz) De werkelijkheid is dus niet veel anders tussen Windows en Linux (en zelfs niet te scheiden volgens lijnen van Open en Closed Source)

Oftewel. Open Source vs Closed Source is een licentie verschil, maar heeft geen impact op de gebruikte methodiek
En dan spring Microsoft nog niet eens met majors. Vista, 7 en in de toekomst 8 hebben allemaal als versie nummer 6.x.
Dat had Microsoft gedaan voor compatibillity apparently.

Elke nieuwe Windows major had ook echt major changes (in veel gevallen)
Van 3 naar 4 (NT4, Win9x + Me). Van 4 naar 5 (NT4 > 2000, 98/Me > XP, wel afhankelijk van productlijn)

Vista was gewoon een enorme major change (niet geweldig overigens) en 7 was een update en weliswaar de 7e release die oorspronkelijk 7.x moest krijgen (Vista was eigenlijk gewoon Me 2.0)..

blijft als je erover nadenkt een hele vreemde versienummering.
Ik vind het nog steeds een vreemde motivatie om ineens een compleet versienummer te verhogen. Normaalgesproken wil de verhoging van een compleet versienummer zeggen dat er significante veranderingen aangebracht zijn.

Hiermee gooi je eigenlijk het hele concept van versienummers overboord.. Je kunt dan net zo goed buildnummers gebruiken (hoewel je dan wel nog onderscheid moet kunnen maken tussen finals en betas, maar dat terzijde).
Ja en nee :+

Je moet er bij bedenken dat versienummers in software voor verschillende doeleinden gebruikt worden. Voor developers simpelweg om tussen versies te kunnen onderscheiden, daarvoor voldoen build nummers in principe prima, en om tussen features of release cycles te onderscheiden, wat dan weer vaak met major versie nummers gedaan wordt. Versienummers zijn echter ook een geliefd speeltje van marketing & sales, in veel commerciele software wordt dan ook met een dubbele versienummering gewerkt: 1 versienummer dat vooral voor communicatie naar buiten gebruikt wordt, en 1 versienummer dat intern voor ontwikkeling gebruikt wordt. Geloof het of niet, maar in veel bedrijven wordt met regelmaat een versienummer in 1 keer met een grote sprong verhoogd, met geen enkele andere reden dan dat het daardoor lijkt dat de software veel beter of nieuwer is dan de vorige versie. Om vergelijkbare reden slaan sommige bedrijven ook versie 1.0 over omdat dat psychologisch gevoelig kan liggen, sommige mensen hebben de associatie dat je 'versie 1.0' van een produkt maar beter links kan laten liggen.

Ik weet hoe debiel het klinkt, maar ik heb het zelf meegemaakt, bij verschillende bedrijven. Nu is linux natuurlijk geen bedrijf, maar ook bij de Linux kernel spreken 'marketing' overwegingen mee. Linux kernel 3.0 klinkt gewoon een stuk hipper dan Linux kernel 2.8.

Dat ze inmiddels een keer van de 2.6 serie afwillen snap ik wel, daarmee maak je weer een periode vrij waarin er wat meer risicovolle ontwikkeling en ingrijpendere wijzigingen plaats kunnen vinden in de 3.0 tree, terwijl de 2.6 tree netjes uit stabiliseert en uiteindelijk alleen nog maar bugfixes en security patches krijgt.

[Reactie gewijzigd door johnbetonschaar op 30 mei 2011 17:22]

Er zijn al hele boeken volgeschreven over versienummering. Ik heb in ons devteam ook jarenlange debatten meegemaakt over hoe we het gaan doen. Maar er is uiteindelijk geen juiste of foute manier van nummeren. Zo moet je bijv. niet wachten op 1.0 om iets stabiel te hebben of kan 1.0 net ook nog altijd een onstabiele build zijn. Heb ooit zelfs van een project gelezen dat de versies daar aftellen.
TeX is na versie 3 decimalen gaan toevoegen: "Stable release 3.141592653"
Het versienummer van TeX convergeert inderdaad naar π. Het versienummer van METAFONT (de programmeertaal waarin TeX-fonts gezet worden) convergeert dan weer naar e. Donald Knuth (de ontwerper van TeX) heeft testamentair vastegelegd dat na zijn dood respectivelijk exact π en e zullen worden, en dus per definitie bug-vrij, voor het eerst in de computergeschiedenis. Zie ook http://www-cs-faculty.stanford.edu/~uno/abcde.html

[Reactie gewijzigd door Typhoner op 30 mei 2011 22:57]

haha briljant. je kunt dan ook stellen dat de beste man nooit dood zal gaan.
Of dat na zijn dood de ontwikkeling stopt aangezien π en e niet exact in decimalen zijn uit te drukken. Maar het blijft een originele manier van nummeren. Commercieel niet echt handig maar vooruit. Dat is TeX ook niet.
TeX is na versie 3 decimalen gaan toevoegen: "Stable release 3.141592653"
3.141592654 ...

(3.14159265358979323846264338327950288419716939937510)

....35 rond af naar ....4

8-B

[Nerd patrol]

[Reactie gewijzigd door mystic101 op 31 mei 2011 10:20]

Out of the box denken. The world is changing. Niks mis met Kernel versie 3.0. Klinkt lekker, bekt lekker, zelfs linux 3.0 ziet er goed uit. En wat kan Linux nu beter gebruiken dan dat? :) Wachten op dié significante verandering kun je jaren.

[Reactie gewijzigd door RielN op 30 mei 2011 16:57]

aan de andere kant, - oh ik heb nu 2.6 - en dit zus zo dat en ginds werkt nog niet lekker, de drivers (FOSS voor nvidia of ati) werken nog niet lekker en btrfs wil nog nie. en ga ga zo maar door...

nu komt het, 3.0 - en geen van al die show stoppers zijn opgelost. het 'linux stroomvreet -> issue is er nog, kortom er is geen regel code meer bij gekomen in een giga lange release... lekker bagger dat linux... lekker onbetrouwbaar ook... |

natuurlijk zijn er genoeg mensen die WEL weten waar het over gaat.. maar wees nu eerlijk, het hele idee van een versie nummmer bij software is een stuk marketing. anders had je genoeg aan een build-nr. (die er ook gewoon is... ook voor de linux kernel).
btrfs, is "experimenteel" omdat btrfs in combinatie met oude disk hardware en een stekker uit de muur trekken het filesysteem in een onbekende staat laat. dus moet fsck draaien en dat is er nog niet, Omdat fsck eigenlijk helemaal niet meer nodig is voor de huidige hardware en daarom staat dat niet boven aan het ontwikkel lijstje.
En dat probleem is nooit op te lossen. ZFS is bijvoorbeeld productiewaardig op alles wat eerlijk is over de staat van de write back cache, dat hebben ze gewoon als eis gesteld.
Als je geen write barriers kan forceren, zal geen enkel filesystem betrouwbaar zijn.

En het is dan ook niet eens zeker of een fsck dataverlies kan voorkomen, dus dat maakt dergelijek hardware hoe dan ook ongeschikt voor elke serieuze server.
En wat ik dus wil zeggen: er is niets mis met een beetje Linux marketing. De ontwikkelaars hebben er geen last van, op den duur wordt het zelfs lekkerder zo. Gewoon doen.
Flesh-Eating Bats with Fangs was toch een marketing slogan
Tuurlijk ik noem mijn fiets voortaan ook auto. Klinkt lekker bekt lekker en ik kan zeggen dat ik een cabrio heb ;)

Probleem is dat men niet out-of-the-box wil denken maar nog steeds bij hetzelfde versienummer systeem blijft. Als je dan bij een standaard versienummer systeem blijft is het "vreemd" om die versienummers zo te verkrachten. Dat is geen out-of-the-box denken dat is gewoon raar.
Ik kan me de wens voor een nieuw major versie nummer wel voorstellen na 7 jaar, alleen had het misschien handiger geweest om dat te doen op het moment dat er ook echt een major change in de architectuur in zat. Nu wordt het wat lastig uitleggen.
Ze willen af van feature-based numbering, ze gaan nu gewoon over op een tijdgebaseerd nummeringsysteem.
Dan is het alsnog niet erg handig om voor een dergelijk systeem te gaan, wanneer ga je dan bijvoorbeeld naar versie 4?

Dan zou ik eerder zoiets als Ubuntu doen, dus de datum er in verwerken, al is dat misschien weer lastig met RC's, als je de release datum nog niet weet.
Volgens de laatste plannen: over 10 jaar, in het jaar dat Linux 30 jaar oud wordt.
Al verwacht ik dat het plan nog wel een keertje wordt aangepast voordat het zo ver is.
Dat is makkelijk over 10 jaar, dan gaat het zijn 4de decennium in,
in de tussentijd kan er dan 3.5 komen ofzow....
Neen, dat doen ze momenteel nog niet. In 3.0 benummering zit niets timebased in tegenstelleting tot bijv. ubuntu met zijn YY.MM .
Sorry, maar ik had dit dus echt niet nodig gevonden.
Met 2.2 > 2.4 braken er allerlei programma's, denk ipchains. Ook met 2.4 > 2.6 waren er grote wijzigingen. Het enige argument wat ik nu lees is "het laatste getalletje werd zo hoog".
Ik vermoed dat als je van 2.6.0 naar 2.6.39 zou gaan er ook vanalles stuk zou gaan. Er is in de tussentijd nogal wat verbouwd (bv een nieuw IO subsysteem waardoor de namen van je HD's kunnen veranderen).
Aan regressies worden altijd aandacht gespendeerd. Zolang de lagen boven linux compatible blijven is er niets aan de hand. Op software na, zou ik niet weten wat er eigenlijk niet meer zou werken (ik had wel ergens gelezen dat ze wel zeer oude drivers van zeer oude hardware hadden uitgehaald, maar waarschijnlijk is dit beperkt tot vervuilde drivers die de kernel lastig onderhoudbaar maakten).
Toch niet geheel onbelangrijk, software... Je kunt nog zo compatible blijven, als de kernel besluit om je HDD ineens sda te noemen ipv hda, dan gaat toch je systeem niet booten omdat /etc/fstab ineens verkeerd is en hij het root filesystem niet kan mounten.

Ik heb toen (2.6.13 ofzo?) iig flink gescholden.
Dat komt deels door het systeem waarin Linus in werkt. Hij onderhoud de kernel door zijn project nauwlettend in het oog te houden. De patches komen vooral van andere ontwikkelaars. Omdat Linus geen invloed heeft op welke patches inkomt (op het accepteren na) en alle patches tijdens de zogenoemde "merge window" geaccepteerd kan worden, kan je moeilijk zeggen dat wanneer de volgende grote release aankomt (behalve na de merge window, maar dan zijn de features al binnen).

Daarnaast heeft linux geen bugfix releases, deze zijn er echter wel gekomen nadat verschillende ontwikkelaars zich bezighielden met het backporten van bugfixes, maar Linus houdt zich daar niet mee bezig. Zijn enige taak is dat nummertje zo snel mogelijk omhoog krijgen tot het nummer te hoog wordt.

[Reactie gewijzigd door avdg-BE op 30 mei 2011 18:22]

Volgens mij is 'stemmen in zijn hoofd' verkeerd vertaald. Ik denk dat Linus met "voices in head" de collega developers bedoelt die op de master branch (aka: "HEAD") zitten.

Verder juich ik dit toe en hoop ik dat ze van de gelegenheid gebruik maken om cruft uit de kernel te laten en die eventueel nog leaner en modulairder maken.

Cheers to Linux 3.0!
Ik denk dat het wel goed is vertaald:
PS. The voices in my head also tell me that the numbers are getting
too big.
bron: http://thread.gmane.org/gmane.linux.kernel.mm/63589
HEAD ken ik bij FreeBSD ook als "release tag". Die kun je blijven updaten. Over een half uur zijn er alweer nieuwe code changes. Zal bij Linux wel helemaal gekkenwerk zijn. Misschien dat dat toch iets met die stemmen te maken heeft?
Die terminologie wordt in de Linux-wereld nauwelijks gebruikt, dus ik denk niet dat het er iets mee te maken heeft.
Is dat een nieuwe hype ofzo, snel veranderen van versienummers ?
Nu firefox ook al sneller gaat opvolgen met versienrs (firefox 4 - 5 - ... ) volgt linux, ...
Bij Linux was het helaas wel het hardste nodig. Versie x.xx.xx was nu niet bepaald intuïtief.
Waarom niet? In het verleden was de sprong gerechtvaardigd omdat 2.0, 2.2, 2.4 en 2.6 allemaal een hoop vernieuwingen met zich meebrachten. Nu gaan we naar 3.0 terwijl het eigenlijk een standaard update betreft.
:) Ik was al bang dat iemand zo ging reageren.

Ik heb het niet over de historische rechtvaardiging (en zoek die ook niet) waarom het in de versie nummering zo tot stand gekomen is. Ik weet de historie drommels goed. Ik zeg alleen dat kernel x.xx.xx niet handig is om over te praten of schrijven.

In de praktijk merkte ik vaak dat mensen gewoonweg hun kernel-nummer niet wilden onthouden (te moeilijk) of alleen de laatste twee cijfers onthielden. Vooral bij ontwikkelaars zag ik vaak dat ze het alleen nog over de laatste twee cijfers hadden.

Daaruit blijkt voor mij dat deze versie notatie nodig anders moet. Als u vindt dat men op een ingeslagen weg moet blijven wandelen omwille van consistentie of historie dan snap ik dat. Ik vind gewoon dat men ook moet kijken wat makkelijk is en of iets in het heden nog zin heeft. En daarom vind ik dat de versie notiatie moet veranderen.

[Reactie gewijzigd door MaestroMaus op 30 mei 2011 18:33]

Men kan kiezen wat men wilt en ja, in feite is de linux kernel te lang op 2.6.x blijven steken. Maar om nu de ene "fout" te corrigeren door een andere "fout" te maken.

Het is zeer ongebruikelijk om bij een release die weinig tot niets toevoegt een het eerste cijfer van een versie nummer te verhogen. Dat is normaal gesproken bedoeld voor grote veranderingen of rewrites. Dit maakt de 3.0 versie de verwachtingen bij de buitenwereld nooit zal kunnen waarmaken en in feite is de 3.0 dus net zo onzinnig als 2.6.934. Deze switch had dus beter getimed kunnen worden en had samen kunnen vallen met enkele grotere updates. Dus ja, ik vind het een redelijk vreemde actie.

Tegelijkertijd is het niet iets om je druk over te maken. Als men graag wil dat men na 20 jaar op versie 3 zit. Prima toch? Het is echter wel zo dat dit versie nummer de zaken niet verduidelijkt en de positieve gevolgen pas zichtbaar worden bij versie 3.1.x aangezien de hele 3.0.x serie nu al net zo onlogisch is als de 2.6.x serie.

Verandering dus voor de verandering maar zonder echt goede redenering. Dit zou niet mijn keuze zijn maar ach, als men graag wil zeggen dat men bij versie 3 is aangekomen.... Ik kan me er niet druk over maken. Al is het bijna komisch hoe mensen deze verandering proberen te verdedigen.
Er is een hele goede reden om voor 2.6.42 te switchen naar 2.8 of 3.0, dat wordt door Igno Molnar mooi verwoord:
http://thread.gmane.org/gmane.linux.kernel.mm/63589
* Linus Torvalds <torvalds <at> linux-foundation.org> wrote:
> On Mon, May 23, 2011 at 12:20 PM, Ingo Molnar <mingo <at> elte.hu> wrote:
> >
> > I really hope there's also a voice that tells you to wait until .42 before
> > cutting 3.0.0! :-)
>
> So I'm toying with 3.0 (and in that case, it really would be "3.0",
> not "3.0.0" - the stable team would get the third digit rather than
> the fourth one.
>
> But no, it wouldn't be for 42. Despite THHGTTG, I think "40" is a
> fairly nice round number.

Also, in all fairness, we should probably display a certain amount of humility:
while Linux has certainly reached milestones such as world domination (as far
as large and small computers are concerned), so calling it 3.0 is a fair deal,
we probably have to wait for version 42.0 before we can consider the Linux
kernel to be the ultimate answer to life, universe and everything.


Thanks,

Ingo

[Reactie gewijzigd door psyBSD op 31 mei 2011 10:07]

Maar als men het heeft over linkernel 32 of 39 is net zo duidelijk daar er toch maar weinig nog een 2.4.39 maintainen
Maar meeste weten wel de Nvidia 270.14.06 als driver notatie
Tis denkelijk idd wat er tussen de oortjes afspeeld , ik hoor stemmen dus op naar de 3.x en wie weet na wat camperen in een witte jas met de mouwen op de rug
een totaal nieuwe computer visie

[Reactie gewijzigd door postbus51 op 30 mei 2011 23:19]

Maar meeste weten wel de Nvidia 270.14.06 als driver notatie
Daar zul je dan wel een postbus 51 reklame voor moeten maken, want de kans dat ik weet welke kernel versie ik draai acht ik voor mij persoonlijk toch groter als de kans dat ik weet welke versie ik van de ATI GFX driver draai.
Wanneer is een sprong gerechtvaardigd, hoe groot moeten de veranderingen zijn om een sprong te rechtvaardigen? Als ik kijk naar de diverse 2.6 kernels die we de afgelopen jaren hebben gezien hadden we wat dat betreft al aan 2.20 of 8.0 moeten zitten. Als je een diff trekt tussen 2.6.0 en de huidige stable 2.6.39 kernel krijg je waarschijnlijk een diff file die groter is dan een hele kernel tree op zichzelf.
Maar al ga je kijken van hoe ver de 2.6 kernel gegroeid is, dan is het een nieuw versie nummer niet verkeerd. 2.6.1 was al een wereld van verschil in vergelijking met 2.6.15 en zeker 2.6.39
Na 20 jaar? Niet echt een vergelijking....

Ik ben benieuwd of dit het aantal gebruikers gaat verhogen. "He? een volledig nieuwe versie? Dat moet wat zijn! Proberen!"
Nieuwe gebruikers kijken niet naar het versienummer van de kernel maar naar die van de distributie. En die is vele malen hoger en zit in de dubbele cijfers.
Ik gebruik Linux niet, maar als na al die tijd eindelijk Linux 3 uit is... ga ik eens kijken.
Een uitgave van 2.6.39 boeit niet, want daar zijn er al genoeg van (2.6.38 of zo?).
Ik ben niet zo bekend met de distrubities, dus 3.0 doet het goed.
De 3.x versie is niet zo vervreemd van de 2.6.37 ,38 ,39
Denk het niet, de meeste linux-gebruikers installeren zelf geen kernel maar gebruiken gewoon degene die standaard bij hun distro zit, of bij android of wat dan ook voor OS / device.

En de mensen die dat wel doen hebben er ook wel genoeg verstand van dat ze wel eerst checken wat er dan daadwerkelijk veranderd is (en draaien waarschijnlijk al jaren linux).
Heb je het stuk ook gelezen?

"De allereerste Linux-kernel in de 2.6-serie kwam zeven jaar geleden uit."
edit: reactie onder verkeerde bericht

[Reactie gewijzigd door Hiub op 30 mei 2011 16:58]

3.0 ipv 2.8 is iets HEEL anders dan 4.0 ipv 3.1
Het marketing team van Mozilla overweegt om Firefox 5 e.v. de wereld in te sturen onder een andere naam.
Het gaat om optimalisaties voor Sandy- en Ivy Bridge.
There are several new feature sin Linux 3.0, including a Microsoft Kinect Linux driver, support for cleancache, updated graphics drivers, optimizations for Intel platforms (Sandy Bridge, Ivy Bridge) as well AMD’s Fusion APUs
Bron: http://www.conceivablytec...ds-approves-linux-3-0-rc1

[Reactie gewijzigd door omnislash op 30 mei 2011 17:27]

Tof dat ze het versienummer van de release afstemmen op het 30 jarig bestaan, maar jammer dat er weinig verbetering mee gemoeid gaat. Een dergelijke versieshift zou eigenlijk met een grote update gepaard moeten gaan. Alle reden om dus stoom bij te zetten, maar dat is jammer genoeg niet gebeurd.
hm ik denk dat er hard genoeg wordt gewerkt hoor, en dan ook nog eens door vrijwilligers :) maarja, een grote update: dat zou betekenen dat ze nu patches zouden moeten 'opsparen' tot 3.0, dat zou ook niet echt nuttig 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