Linux kernel versie 3

[DeNachtwacht]

Ik vroeg mij na het lezen van wat online blogjes ineens af; zit er binnen niet al te lange tijd een geheel nieuwe versie van de linux kernel in de pijplijn? Versie 2.6 is al zo oud als de weg naar Rome lijkt het wel en de kernel zou toch op sommige punten flink aangepakt kunnen worden. Toch kan ik op internet letterlijk niets vinden omtrent een versie 3 van de linux kernel (of voor mijn part 2.7).

Weet er hier iemand toevallig hoe het met dat soort ontwikkelingen staat?

[Kees]

Ik geloof niet dat ze binnenkort een 2.7/3.0 willen hebben. Een major nieuwe versie impliceert namelijk nogal wat volgens de kernel developers, met name veranderingen in de API e.d. En dat wordt nu niet nodig gevonden.

Verder zul je waarschijnlijk eerder een 2.7 -> 2.8 zien dan iets anders, ze zijn er niet zo happig op om nummers over te slaan en laten dat wel aan microsoft over

zie: http://lwn.net/Articles/298510/

[zordaz]

De aparte "ontwikkelbranche" voor de Linux kernel is na uitkomen van 2.6 bewust losgelaten omdat Linus Torvalds er inmiddels veel nadelen aan vond zitten.

Hij heeft onlangs nog aangegeven dat hij ook niet terug wil naar deze aanpak, er komt geen 2.7 branch. Ik zie het er daarom niet meer niet van komen in de toekomst, alle nieuwe ontwikkelingen worden dus binnen de 2.6.x branch doorgevoerd en op vaste momenten gereleased.

Misschien dat men uiteindelijk zelfs de hele prefix "2.6" weg kan laten?!

[DeNachtwacht]

Het lijkt me toch dat de software op een gegeven moment gewoon te veel achter loopt op de techniek en dat ze een nieuwe kernel in elkaar moeten zetten.. of ligt dat nou aan mij?

[!null]

HetWonder schreef op maandag 19 oktober 2009 @ 16:49:
Het lijkt me toch dat de software op een gegeven moment gewoon te veel achter loopt op de techniek en dat ze een nieuwe kernel in elkaar moeten zetten.. of ligt dat nou aan mij?

Nee ze knutselen de hele tijd door, ze bouwen de kernel verder uit met allerlei kernel modules. Usb 3.0 zat er ook al vrij snel in als module, gewoon in de 2.6 branch.
Maar als men (Linus) geen andere branches wil gaan aanmaken, dan is het wel raar om de hele tijd op 2.6 door te blijven gaan (als in de naam), maar het geeft wel een goeie scheiding weer met 2.4

Maarja de kernel is zoals ie is, en heeft geen veranderingen nodig. Wel updates, en dat gebeurt aan de lopende band.

[Verwijderd]

HetWonder schreef op maandag 19 oktober 2009 @ 16:49:
Het lijkt me toch dat de software op een gegeven moment gewoon te veel achter loopt op de techniek en dat ze een nieuwe kernel in elkaar moeten zetten.. of ligt dat nou aan mij?

Een kernel bestaat uit allemaal losse onderdelen met elk een specifieke functie. Er kunnen nieuwe kernel releases zijn waar een deel veranderd is en een deel niet. Compile maar eens een kernel voor linux vanaf de sources van kerneltrap.org, dan wordt het een stuk duidelijker hoe dit in elkaar zit.

[Arnout]

HetWonder schreef op maandag 19 oktober 2009 @ 16:49:
Het lijkt me toch dat de software op een gegeven moment gewoon te veel achter loopt op de techniek en dat ze een nieuwe kernel in elkaar moeten zetten.. of ligt dat nou aan mij?

Gebruik je zelf Linux?

[Miki]

HetWonder schreef op maandag 19 oktober 2009 @ 16:49:
Het lijkt me toch dat de software op een gegeven moment gewoon te veel achter loopt op de techniek en dat ze een nieuwe kernel in elkaar moeten zetten.. of ligt dat nou aan mij?

Op welke software doel je? Drivers zijn modulair dus behoeven naast een stack(als dat nodig is) geen bijzondere/ noemenswaardige wijzigingen.
Het enige wat ik me afvraag is hoe lang gaan we allerei legacy meuk ondersteunen, het komt de slankheid van de kernel niet ten goede.

[Verwijderd]

Miki schreef op maandag 19 oktober 2009 @ 16:56:
[...]

Op welke software doel je? Drivers zijn modulair dus behoeven naast een stack(als dat nodig is) geen bijzondere/ noemenswaardige wijzigingen.
Het enige wat ik me afvraag is hoe lang gaan we allerei legacy meuk ondersteunen, het komt de slankheid van de kernel niet ten goede.

Je hoeft niet perse alles mee te bakken in de kernel, je kunt gerust modules niet compileren / integreren in de kernel naar eigen inzicht.

[Miki]

Verwijderd schreef op maandag 19 oktober 2009 @ 16:59:
[...]


Je hoeft niet perse alles mee te bakken in de kernel, je kunt gerust modules niet compileren / integreren in de kernel naar eigen inzicht.

Mee eens, ik bak zelf graag kernels, geheel op maat. Monolitisch is het toverwoord, ik heb daarom geen upstart nodig

Maar hoe gaat dit "probleem" getackeld worden door een mainstream distro als, Ubuntu, OpenSuse, Fedora. enz.

[ Voor 3% gewijzigd door Miki op 19-10-2009 17:04 ]

[laurencevde]

De huidige kernel lijkt niet echt meer op 2.6.0. Een hoop dingen zijn intussen vervangen of behoorlijk aangepast:
devfs >udev
sata-stack is nu ook voor ide
framebuffer wordt nu vervangen door KMS
wifi-stack is vervangen
bluetooth-stack is/wordt vervangen?
inotify is toegevoegd en wordt nu weer vervangen
disk-scheduler is vervangen, en nu live kiesbaar
fuse en cuse zijn toegevoegd
er zijn nogal wat bestandssystemen toegevoegd

En een heeele hoop andere random meuk overal en nergens

Er is ook een unstable-branch, MM, een patchset op de stable-branch. Als onderdelen daarin eenmaal stabiel genoeg zijn, verhuizen ze naar linus's branch. Linux's modulariteit en Git zorgen er voor dat dit betrekkelijk eenvoudig is.

Een echte, onafhankelijke, unstable-branch is nergens voor nodig, en heeft als nadeel dat-ie ooit stable gemaakt moet worden, maar in het begin daarvan nooit zo stable zou zijn als de huidige stable, en de ontwikkeling dan over 2 branches verdeeld moet worden...

[BoZ_]

Kees schreef op maandag 19 oktober 2009 @ 14:01:
Ik geloof niet dat ze binnenkort een 2.7/3.0 willen hebben. Een major nieuwe versie impliceert namelijk nogal wat volgens de kernel developers, met name veranderingen in de API e.d. En dat wordt nu niet nodig gevonden.

Verder zul je waarschijnlijk eerder een 2.7 -> 2.8 zien dan iets anders, ze zijn er niet zo happig op om nummers over te slaan en laten dat wel aan microsoft over

zie: http://lwn.net/Articles/298510/

Ik vind 2.7 -> 3.0 niet overslaan hoor, het impliceert alleen dat de developers vinden dat er dusdanig veel is veranderd dat het een nieuwe major-release is. Dat kan in principe op ieder moment, daarvoor hoeft de minor niet eerst tot .9 te lopen ofzo. Slackware die van versie 4.0 naar 7.0 gaat, dat is overslaan

[MBV]

Ik vind het wel jammer dat linux nog steeds 2.6 heet: intern is er aardig wat veranderd. IMHO zouden drivers geschreven voor 2.6.0 nog steeds moeten werken voor 2.6.<huidig>, wat niet niet geval is: allerlei interfaces zijn veranderd (in een poging om binary drivers onmogelijk te maken ), en het lijstje van laurencevde natuurlijk. Het zou een stuk duidelijker zijn als ze dat in 2.7.0 hadden gedaan.

[DeNachtwacht]

Arnout schreef op maandag 19 oktober 2009 @ 16:55:
[...]
Gebruik je zelf Linux?

Ubuntu ja, maar echt op het niveau van een gebruiker. Programmeren kan ik niet, mijn meest custom besturingssysteem ooit was een windows xp lite voor mijn netbook bouwen. Dus ik zal er idd wel technisch te weinig verstand van hebben.

Maar begrijp ik dus dat het met linux 2.6 dus net zo zal gaan als nu met gnome (waarbij 2.32 gnome 3 genoemd gaat worden)?

[DeKaerften]

HetWonder schreef op dinsdag 20 oktober 2009 @ 18:02:
[...]

Maar begrijp ik dus dat het met linux 2.6 dus net zo zal gaan als nu met gnome (waarbij 2.32 gnome 3 genoemd gaat worden)?

offtopic:
AFAIK is het nog niet bekend of 2.30 of 2.32 gnome 3.0 wordt. Daar wordt volgens mij pas volgende maand uitsluitsel over gedaan.

[Arnout]

Zowiezo zou ik niet zo bezig zijn met versienummers. Het zijn maar aanduidingen. Of het nu 2.6, 2.8 of 3.0 heet, het gaat om functionaliteit. 2.6 kernel werkt gewoon zoals het zou moeten, namelijk uber stabiel en betrouwbaar.

Dat er vroeger wel stricte scheiding was (qua versienummering dan) tussen dev en stable, dat is waar, maar dat was ook niet ideaal.

Edit: als je echt zelf wilt ervaren hoe de kernel precies in elkaar zit, zou ik zelf een kernel gaan compileren op je Ubuntu machine. Hartstikke leuk en interessant, en niet moeilijk. Zoek bij google op 'debian kernel compile'.

[ Voor 24% gewijzigd door Arnout op 21-10-2009 13:04 ]

[Verwijderd]

Miki schreef op maandag 19 oktober 2009 @ 16:56:
Het enige wat ik me afvraag is hoe lang gaan we allerei legacy meuk ondersteunen, het komt de slankheid van de kernel niet ten goede.

Klopt, daarom snap ik ook niet waarom in het verleden niet is gekozen om alle legacy spul af te splitsen van het huidige code.

[evaarties]

Verwijderd schreef op woensdag 21 oktober 2009 @ 16:13:
[...]

Klopt, daarom snap ik ook niet waarom in het verleden niet is gekozen om alle legacy spul af te splitsen van het huidige code.

Dat is toch juist een kracht van linux? Installeer het op een oude bak en alles werkt meteen, juist door die legacy-ondersteuning.

[CAPSLOCK2000]

Ik zelf verwacht dat Linus op een dag zegt "en vanaf nu is de vorige kernel versie met terugwerkende kracht 3.0".

Het probleem is dat mensen te veel waarde aan versie-nummers hechten.
Als Linus nu zou zeggen "over 1 jaar komt kernel 3.0" dan zullen een hoop mensen en bedrijven prompt denken: "ok, niks meer investeren in 2.6, over een jaar zullen we eens naar een versie voor 3.0 kijken"

Als 3.0 dan daadwerkelijk uit komt krijg je weer de reacties "X, Y en Z werken nog niet? waarom heb je dit al 3.0 genoemd?" Waarop het antwoord is "niemand wilde het testen zolang het nog beta was".
En in de tussentijd zit je al een jaar zonder ondersteuning.

Dan duurt het nog eens tot versie 3.0.5 voor het stof een beetje neerdaalt, en dan komen de bedrijven pas in actie om hun software bij te werken, en tegen de tijd dat de nieuwe versie er dan eindelijk is heeft alles twee jaar stil gestaan.


Ik overdrijf het een beetje, de wereld is natuurlijk niet afhankelijk van de Linux kernel, maar ik hoop dat je nu beter begrijpt waarom Linus het liefste nooit meer een versienummer zou gebruiken.

[Verwijderd]

evaarties schreef op woensdag 21 oktober 2009 @ 16:24:
[...]


Dat is toch juist een kracht van linux? Installeer het op een oude bak en alles werkt meteen, juist door die legacy-ondersteuning.

Dat noem ik geen kracht, dat is een nadeel. zelfs de maindevelopers hebben niet altijd zicht op of alle legacy spul nog werkt. En dat is veel erger.

Splits je alle legacy spul af dan heb je A: weer een snelle kernel en B: je ondersteunt alles nog maar dan een andere tak. Ontwikkeling van legacyspul gaat ook gewoon door maar veel minder snel dan wat er nu is. En je hebt beter zicht van wat er volledig ondersteunt wordt en wat niet. En of het noodzakelijk is.

[ Voor 7% gewijzigd door Verwijderd op 21-10-2009 16:53 ]

[!null]

CAPSLOCK2000 vat het goed samen.

Verwijderd schreef op woensdag 21 oktober 2009 @ 16:50:
[...]

Dat noem ik geen kracht, dat is een nadeel. zelfs de maindevelopers hebben niet altijd zicht op of alle legacy spul nog werkt. En dat is veel erger.

Splits je alle legacy spul af dan heb je A: weer een snelle kernel en B: je ondersteunt alles nog maar dan een andere tak. Ontwikkeling van legacyspul gaat ook gewoon door maar veel minder snel dan wat er nu is. En je hebt beter zicht van wat er volledig ondersteunt wordt en wat niet. En of het noodzakelijk is.

Ik snap niet helemaal hoe je dat ziet. Men kan nu gewoon een kernel bouwen zonder al die oude meuk, volledig naar keuze. Dus legacy ondersteunen is een keuze van degene die de kernel bouwt. Dat zijn dus de mensen die een distributie ontwikkelen, die kunnen kiezen wat ze in de kernel gooien en wat niet. Verder zijn heel veel dingen, ook legacy meuk, gewoon te installeren als kernel modules, en hoef je dat sowieso niet bij voorbaat in je kernel te stoppen. Het is meer interfacing voor die legacy drivers etc dat denk ik een probleem is. Maar goed, heel veel is al op de schop gegaan zoals in dit topic valt te lezen.

[Verwijderd]

!null schreef op woensdag 21 oktober 2009 @ 16:58:
Ik snap niet helemaal hoe je dat ziet. Men kan nu gewoon een kernel bouwen zonder al die oude meuk, volledig naar keuze. Dus legacy ondersteunen is een keuze van degene die de kernel bouwt. Dat zijn dus de mensen die een distributie ontwikkelen, die kunnen kiezen wat ze in de kernel gooien en wat niet. Verder zijn heel veel dingen, ook legacy meuk, gewoon te installeren als kernel modules, en hoef je dat sowieso niet bij voorbaat in je kernel te stoppen. Het is meer interfacing voor die legacy drivers etc dat denk ik een probleem is. Maar goed, heel veel is al op de schop gegaan zoals in dit topic valt te lezen.

Dat ze een afsplitsing maken van wat actueel is en wat legacy is en deze er naast laat bestaan puur ter ondersteuning van de oudere systemen. En kwa aandacht zal het wel minder zijn maar dat is logisch.

Als je een legacy machine heb zit je ook niet te wachten op nieuw spul maar wil je wel een snelle kernel hebben die werkt.

[ Voor 6% gewijzigd door Verwijderd op 21-10-2009 18:12 ]

[Dr. Horrible]

Ik dacht dat de 2.4 branch er was voor legacy spul en 2.6 voor normale dingen. Of waren ze daar nou mee gestopt?

[Osiris]

Verwijderd schreef op woensdag 21 oktober 2009 @ 18:09:
[...]

Dat ze een afsplitsing maken van wat actueel is en wat legacy is en deze er naast laat bestaan puur ter ondersteuning van de oudere systemen. En kwa aandacht zal het wel minder zijn maar dat is logisch.

En waarom zouden de kernel-developpers dat in vredesnaam voor jou moeten doen? Die bieden gewoon alles aan. Wat jij of een distro-devver vervolgens wel of niet relevant cq. legacy/modern vindt, moet je vervolgens lekker zelf weten.

De distro's zouden vervolgens legacy binaries kunnen ontwikkelen voor hun users.

Ik zie geen enkele reden waarom nou de kernel-devvers het vóór je zouden moeten bepalen. Het heeft totaal geen voordelen.

Dr. Horrible schreef op woensdag 21 oktober 2009 @ 18:13:
Ik dacht dat de 2.4 branch er was voor legacy spul en 2.6 voor normale dingen. Of waren ze daar nou mee gestopt?

Ik ben maar een simpel Gentoo-gebruikertje en geen programmeur ofzo, maar was 't niet zo dat de 2.4-branch een andere API/interface/onderliggende-zooi/whatever had dan de 2.6-branch? En dat het dus niet puur legacy<->modern is?

[ Voor 23% gewijzigd door Osiris op 21-10-2009 18:24 ]

[H!GHGuY]

Verwijderd schreef op woensdag 21 oktober 2009 @ 18:09:
Als je een legacy machine heb zit je ook niet te wachten op nieuw spul maar wil je wel een snelle kernel hebben die werkt.

De kernel wordt helemaal niet trager van legacy spul.
Dezelfde interfaces worden gebruikt voor oude en nieuw meuk. Daarenboven worden legacy dingen in distributies meestal in modules gestopt.

Linus heeft, zoals eerder al gezegd hier, aangegeven op dit moment niet bereid te zijn om van 2.6.xx af te stappen aangezien de huidige ontwikkelmethode naar behoren werkt en er geen changes zijn die een nieuwe major/minor vereisen. Er zijn trouwens aparte ontwikkelbranches voor heel wat spul waar dan telkens de stabiele stukken naar de mainline gemerged worden.

Osiris schreef op woensdag 21 oktober 2009 @ 18:23:
Ik ben maar een simpel Gentoo-gebruikertje en geen programmeur ofzo, maar was 't niet zo dat de 2.4-branch een andere API/interface/onderliggende-zooi/whatever had dan de 2.6-branch? En dat het dus niet puur legacy<->modern is?

Jup

[smesjz]

Wat ten tijden van 2.4 ontwikkeling (en 2.0 en 2.2) ook speelde is dat je op een gegeven moment ook spannende dingen wil gaan om iets totaal herschrijven. Dat wil je het liefst buiten je stabiele versie doen waarvan je bijv. alleen bug fixes blijft doen.
In 2.5 werden veel grote veranderingen doorgevoerd totdat deze uiteindelijk 2.6.0 werd. Nu gebeuren er nog steeds grote wijzigingen maar een significant deel is dus al in 2.5.x gerealiseerd.

Vroeger had je nog de -mm en -ck branches waar ook weer experimentele code werd gebruikt. Ook daar zijn weer andere zaken voor in de plaats gekomen en werkt ook het versie nummers aan om aan te geven wat voor soort versie het betreft.

Dit alles zorgt er volgens mij ook voor dat de 2.7 nog niet nodig is omdat de huidige modellen redelijk vol doen.

Een nieuwe scheduler (CFS) als default zetten is lang niet zo spectaculair als heel je memory management herschrijven, dus wanneer zoiets zich aandient zal 2.7 wel worden aangekondigd denk ik.

[Verwijderd]

H!GHGuY schreef op woensdag 21 oktober 2009 @ 18:34:


De kernel wordt helemaal niet trager van legacy spul.
Dezelfde interfaces worden gebruikt voor oude en nieuw meuk. Daarenboven worden legacy dingen in distributies meestal in modules gestopt.

Linus heeft, zoals eerder al gezegd hier, aangegeven op dit moment niet bereid te zijn om van 2.6.xx af te stappen aangezien de huidige ontwikkelmethode naar behoren werkt en er geen changes zijn die een nieuwe major/minor vereisen. Er zijn trouwens aparte ontwikkelbranches voor heel wat spul waar dan telkens de stabiele stukken naar de mainline gemerged worden.


[...]

Jup

Linus heeft ook gezegt dat de Linux kernel bloated was. Wat o.a de uitwerking heeft dat het wat vertrager werkt. Of zal eerder aan de kwaliteit van de code liggen?

[H!GHGuY]

Verwijderd schreef op woensdag 21 oktober 2009 @ 18:51:
[...]

Linus heeft ook gezegt dat de Linux kernel bloated was.

Dat heeft ie gezegd.

Wat o.a de uitwerking heeft dat het wat vertrager werkt. Of zal eerder aan de kwaliteit van de code liggen?

Dat is jouw interpretatie.

Hoe snel de kernel is op jouw machine hangt enkel af van de gevolgde codepaden. Als die voldoende geoptimaliseerd zijn en geen speciale kronkels moeten maken om oude code te supporteren dan heb jij er geen last van.

Er _zijn_ natuurlijk wel van die rare kronkels die wegens legacy blijven bestaan, maar die zullen samen wel geen mirakels verrichten wat performance betreft.
Daarenboven loopt, volgens mij, de windows kernel op veel vlakken gigantisch achter op de linux kernel.
Sommige dingen hebben ze dan wel weer goed (en vroeg) voor elkaar, maar daar zitten uitgebreide NDA's en hun quasi-monopolie op de desktopmarkt wel voor iets tussen.

[MBV]

Sterker nog: qua architectuur is de hele linux-kernel eigenlijk ruk, zelfs NT had al een micro-kernel wat in theorie beter werkt. Gelukkig hebben ze een werkende workaround in de vorm van modules, maar een schoonheidsprijs verdient het niet.

Verder ben ik wel van mening veranderd: ik denk dat er wel aardig wat wijzigingen t.o.v. 2.6.0 zijn gemaakt die allemaal samen groter zijn dan 2.4.<latest> naar 2.6.0, maar die in zulke kleine stapjes zijn gemaakt dat het moeilijk is om 1 punt aan te wijzen.Een beetje jammer is dat wel: sommige drivers zullen moeten aangeven dat ze alleen werken van 2.6.X tot 2.6.Y, omdat de interfaces zijn veranderd.

[mithras]

Volgens mij is de opzet van de kernel nog helemaal niet zo slecht, met al die modules. Juist de distributeurs zullen hierin een actievere rol moeten spelen (imho) in de keuze bij de packaging van de modules.

Ik snap best dat je al de legecy meuk niet eruit wilt halen vanwege bepaalde redenen. Ik kan alleen niet geloven dat het supporten van hardware uit 1991 totaal geen impact heeft op de performance (m.n. bij booten). Je moet dat toch allemaal nalopen? GNU/Linux kan in 2 seconden opstarten, door ver te optimaliseren voor specifiek de geïnstalleerde hardware. Dat lijkt me toch genoeg bewijs?

Je ziet bijvoorbeeld bij binary grafische drivers dat er verschillende versies zijn voor verschillende type kaarten. Dat kunnen ze ook doen met de kernel. Een kernel-latest, een kernel-legacy en een kernel-support-all. Dan kan je gewoon een lichte kernel gebruiken die niet veel nodig heeft. Een legacy wanneer je toch oude hardware gebruikt en mocht je tegen het probleem aanlopen dat je hardware hebt uit 1991 én 2009, kan je nog het totale pakket gebruiken.
De kernel ontwikkelaars kunnen dan lekker hun ding doen, de distributeurs kijken wat de benodigdheden zijn van de gebruikers (en dus specifieker afgestemd op de doelgroep).

[CAPSLOCK2000]

Verwijderd schreef op woensdag 21 oktober 2009 @ 16:50:
[...]

Dat noem ik geen kracht, dat is een nadeel. zelfs de maindevelopers hebben niet altijd zicht op of alle legacy spul nog werkt. En dat is veel erger.

Splits je alle legacy spul af dan heb je A: weer een snelle kernel en B: je ondersteunt alles nog maar dan een andere tak. Ontwikkeling van legacyspul gaat ook gewoon door maar veel minder snel dan wat er nu is. En je hebt beter zicht van wat er volledig ondersteunt wordt en wat niet. En of het noodzakelijk is.

Zo'n beetje alle oude rotzooi zit in drivers. Als jij geen ISA-bus in je computer hebt dan hoef je die ISA driver ook niet te laden. Er zijn natuurlijk wel wat beperkingen, maar die code vervangen maakt het nog niet direct sneller. Om dergelijke ingewikkelde code snel en betrouwbaar te maken moet je er jaren lang aan doorwerken. Je kan wel helemaal opnieuw beginnen, maar het kan jaren duren voor je dezelfde kwaliteit weer gehaald hebt. Tegen de tijd dat het af is zal een deel al weer verouderd zijn. De Linux manier is om het stukje bij beetje te doen, en verouderde subsystemen er langzaam uit te werken.

Voor een deel is het ook noodzaak. Kijk bijvoorbeeld naar het WIFI. Ik geloof dat er nu wel drie WIFI subsystemen in de Linux kernel zitten, allemaal naast elkaar. Ieder keer komt er weer een nieuw systeem dat nog beter is dan wat er al was, maar er zijn nog maar voor een paar chipsets drivers. Je kan dan wel zeggen "pech voor de rest", maar dan ontneem je de halve wereld z'n WIFI, en dat is ook niet realistisch. Het duurt een tijd voor alle drivers zijn overgezet, en pas dan wordt het oude systeem helemaal afgeschaft. Als de hardwarefabrikanten niet meewerken kan het best lang duren voor het allemaal geregeld is.

[H!GHGuY]

MBV schreef op woensdag 21 oktober 2009 @ 23:18:
Sterker nog: qua architectuur is de hele linux-kernel eigenlijk ruk, zelfs NT had al een micro-kernel wat in theorie beter werkt. Gelukkig hebben ze een werkende workaround in de vorm van modules, maar een schoonheidsprijs verdient het niet.

Ik denk dat linux net bewijst dat een monolithische kernel helemaal zo slecht niet is als men denkt. Daarenboven is de kernel misschien wel monolithisch, ze is wel helemaal modulair opgebouwd en volgens OO concepten geïmplementeerd. NT's kernel is geen pure micro-kernel. Het is een hybride tussenvorm. De belangrijkste reden waarom een micro-kernel zogezegd beter is, is omdat ze klein is en niets anders doet dan message-passing. Als je subsystemen die erop geënt zijn ruk/lek zijn dan sta je even ver.

Verder ben ik wel van mening veranderd: ik denk dat er wel aardig wat wijzigingen t.o.v. 2.6.0 zijn gemaakt die allemaal samen groter zijn dan 2.4.<latest> naar 2.6.0, maar die in zulke kleine stapjes zijn gemaakt dat het moeilijk is om 1 punt aan te wijzen.Een beetje jammer is dat wel: sommige drivers zullen moeten aangeven dat ze alleen werken van 2.6.X tot 2.6.Y, omdat de interfaces zijn veranderd.

Ook hier zijn workarounds voor die veel gebruikt worden.
Onze linux drivers hebben hier en daar een linux version check om bepaalde features wel of niet te gebruiken
of om met API changes om te gaan.

mithras schreef op woensdag 21 oktober 2009 @ 23:51:
Ik snap best dat je al de legecy meuk niet eruit wilt halen vanwege bepaalde redenen. Ik kan alleen niet geloven dat het supporten van hardware uit 1991 totaal geen impact heeft op de performance (m.n. bij booten). Je moet dat toch allemaal nalopen? GNU/Linux kan in 2 seconden opstarten, door ver te optimaliseren voor specifiek de geïnstalleerde hardware. Dat lijkt me toch genoeg bewijs?

De boottijden zijn in Linux enorm aan het inkorten doordat ze het booten aan het parallelliseren zijn.
Ik compileer mijn kernel ook zelf (met enkel de drivers die ik nodig heb) en die kernel geeft ook de controle aan init binnen enkele seconden (en dan zit ik nog met extended tracing op het USB niveau)

Je ziet bijvoorbeeld bij binary grafische drivers dat er verschillende versies zijn voor verschillende type kaarten. Dat kunnen ze ook doen met de kernel. Een kernel-latest, een kernel-legacy en een kernel-support-all. Dan kan je gewoon een lichte kernel gebruiken die niet veel nodig heeft. Een legacy wanneer je toch oude hardware gebruikt en mocht je tegen het probleem aanlopen dat je hardware hebt uit 1991 én 2009, kan je nog het totale pakket gebruiken.
De kernel ontwikkelaars kunnen dan lekker hun ding doen, de distributeurs kijken wat de benodigdheden zijn van de gebruikers (en dus specifieker afgestemd op de doelgroep).

Eerst doen nVidia en AMD/ATI zoveel moeite om unified drivers te maken, dan gaan ze weer alles opsplitsen. Nee hoor.

[DeNachtwacht]

H!GHGuY schreef op donderdag 22 oktober 2009 @ 09:31:
Ik compileer mijn kernel ook zelf (met enkel de drivers die ik nodig heb) en die kernel geeft ook de controle aan init binnen enkele seconden (en dan zit ik nog met extended tracing op het USB niveau)

Is dit nu ook een beetje simpel te doen voor een niet gevorderde gebruiker? Ik zit me er nu een beetje in te verdiepen, het lijkt me namelijk wel wat om voor Ubuntu 9.10 een speciaal op netbooks gerichte kernel in elkaar te sleutelen. Maar: moet ik dan bij elke officiële kernel update weer zelf een nieuwe geupdate kernel in elkaar draaien? En zoja; is dat dan met een paar klikjes nieuwe features toevoegen en compilen maar, of is dat weer from sketch alles overnieuw doen?

Ik speel namelijk al een tijdje met het idee om zowel op gebied van de kernel als de (keuze voor) meegeleverde software een sterk afgeslankte versie van ubuntu in elkaar te draaien speciaal voor netbooks. Er zit namelijk nu megaveel overbodige rommel in de standaard UNR terwijl de enorme overeenkomsten in hardware in netbooks (Atom N270, Intel GMA450) het nu juist makkelijk maken veel overbodige zaken eruit te slopen.

[ Voor 5% gewijzigd door DeNachtwacht op 22-10-2009 15:01 ]

[Verwijderd]

Ben je dan niet beter af met een andere distro? Kijk een naar Gentoo of Arch Linux bijvoorbeeld, daarbij begin je from-scratch maar heb je uiteindelijk precies de installatie die je wilt. Een uitgebreide Ubuntu installatie afbrokkelen tot je alleen het bare-minimum over houdt lijkt mij de omgekeerde wereld.

Verder is een eigen kernel bouwen niet zo moeilijk. Er zijn legio handleidingen hiervoor te vinden. Je zult wel telkens je kernel opnieuw moeten compilen na een update, behalve voor minor updates waarvoor patches bestaan, dan hoef je alleen die te compilen.

[ Voor 71% gewijzigd door Verwijderd op 22-10-2009 15:06 ]

[CAPSLOCK2000]

HetWonder schreef op donderdag 22 oktober 2009 @ 14:59:
Is dit nu ook een beetje simpel te doen voor een niet gevorderde gebruiker? Ik zit me er nu een beetje in te verdiepen, het lijkt me namelijk wel wat om voor Ubuntu 9.10 een speciaal op netbooks gerichte kernel in elkaar

Je weet dat er al verschillende Ubuntu versies zijn voor netbooks, zoals Eeedubuntu en Ubuntu Netboot Remix.

te sleutelen. Maar: moet ik dan bij elke officiële kernel update weer zelf een nieuwe geupdate kernel in elkaar draaien? En zoja; is dat dan met een paar klikjes nieuwe features toevoegen en compilen maar, of is dat weer from sketch alles overnieuw doen?

De moeilijkheid van het configureren van een kernel zit niet in de interface. Een lange lijst met vinkjes die je aan of uit kan zetten snapt iedereen tegenwoordig wel. De moeilijkheid is dat je genoeg van computerhardware moet weten om te begrijpen wat je wel en niet nodig hebt. Een typische beginnersfout is bijvoorbeeld het vergeten van een driver voor je harde schijf. Je moet enerzijds beseffen dat je zo'n driver nodig hebt, en van de andere kant weten of jij IDE, SATA, SCSI of nog iets anders gebruikt.
Als beginner kun je het beste van je huidige configuratie uitgaan (staat in /boot/config-2.6.xxx) en dan beginnen met stukken uit te schakelen die je toch niet gebruikt.

Een kernel compilen is enorm leerzaam, maar eerlijk gezegd ook wat overgewaardeerd. De meeste mensen zullen geen merkbaar snelheidsverschil behalen. Als je geluk hebt kun je nog een paar seconden van je boot-tijd afhalen, maar hoe belangrijk is dat nu echt?

Als je meer wil leren over Linux en je computer, ga er voor, ik heb het altijd zeer bevredigend gevonden. Als je een snellere computer wil, ga dan een middag bij werken bij de supermarkt en koop wat extra RAM.

[Arnout]

Helemaal mee eens. Overigens kun je vrij risicoloos essentiele zaken vergeten, je kunt altijd booten met je oude (werkende) kernel.

[H!GHGuY]

HetWonder schreef op donderdag 22 oktober 2009 @ 14:59:
Is dit nu ook een beetje simpel te doen voor een niet gevorderde gebruiker? Ik zit me er nu een beetje in te verdiepen, het lijkt me namelijk wel wat om voor Ubuntu 9.10 een speciaal op netbooks gerichte kernel in elkaar te sleutelen. Maar: moet ik dan bij elke officiële kernel update weer zelf een nieuwe geupdate kernel in elkaar draaien? En zoja; is dat dan met een paar klikjes nieuwe features toevoegen en compilen maar, of is dat weer from sketch alles overnieuw doen?

Je kan over het algemeen wel weg met

code:

cp /usr/src/linux-previous/.config .config
make oldconfig

Dan krijg je enkel vragen over de nieuwe stukken. Ik zou hierna dan toch wel nog even door de menuconfig lopen.

De snelheidswinst zit hem vooral in het afwezig zijn van probing naar devices die niet in je PC zitten. Maar of dat op hedendaagse computers en met de recente boot-parallellisatie nog veel verschil maakt moet je voor jezelf uitmaken. Een all-yes config (met alles erop en eraan) is natuurlijk een stuk veiliger.

[DeNachtwacht]

CAPSLOCK2000 schreef op donderdag 22 oktober 2009 @ 16:40:
Je weet dat er al verschillende Ubuntu versies zijn voor netbooks, zoals Eeedubuntu en Ubuntu Netboot Remix.

...

Als je meer wil leren over Linux en je computer, ga er voor, ik heb het altijd zeer bevredigend gevonden. Als je een snellere computer wil, ga dan een middag bij werken bij de supermarkt en koop wat extra RAM.

Ubuntu Netbook Remix is alleen maar een grafisch schilletje voor verder exact dezelfde distributie. Het netbook menu staat me zeer aan, maar er kan volgens mij zeer veel meuk uit. Juist voor netbooks zal dat volgens mij veel snelheid kunnen opleveren. Heel veel overbodige configbestanden, drivers, modules etc zal toch zeker wel snelheidswinst opleveren voor een minimale machine als een netbook? Het lijkt me dat het allemaal een stuk lichter moet kunnen op zo'n ding.

[Tha_Butcha]

mmm, voor zover ik weet is ie echt custom hoor.

quote wikipedia

Ubuntu Netbook Remix (UNR) is a version of Ubuntu that has been optimized to enable it to work better on netbooks or devices with small screens with the Intel Atom processor

Ben nu te lui om mijn netbook te pakken, maar ik weet zeker dat mijn server over zijn nek zou gaan met die kernel en vice versa, al was het maar vanwege de processor.

Daarnaast zitten er o.a. een SSD in, een webcam, touchpad (multitouch capable) en een veel kleiner scherm. En dat werkt allemaal out of the box.Daarbij is netbook al redelijk snel voor mijn gevoel. Heb geen benchmarks hier liggen, maar een logge XP install die niet is getweaked gaat het echt niet redden op een netbook hoor.

En verder ontopic: zoals eerder gezegd, versie nummers zullen me eerlijk gezegd aan mijn reet roesten, Het enige wat ik wil is een stable kernel, die ik zelf kan compilen en al mijn hardware ondersteunt, wat ie ook precies doet.

[CAPSLOCK2000]

HetWonder schreef op vrijdag 23 oktober 2009 @ 01:29:
[...]


Ubuntu Netbook Remix is alleen maar een grafisch schilletje voor verder exact dezelfde distributie. Het netbook menu staat me zeer aan, maar er kan volgens mij zeer veel meuk uit. Juist voor netbooks zal dat volgens mij veel snelheid kunnen opleveren. Heel veel overbodige configbestanden, drivers, modules etc zal toch zeker wel snelheidswinst opleveren voor een minimale machine als een netbook? Het lijkt me dat het allemaal een stuk lichter moet kunnen op zo'n ding.

Ik denk dat het tegen zal vallen. Je zal een hoop megabytes hardeschijf vrij kunnen maken, maar echt veel geheugen en snelheid winnen gaat je niet lukken door alleen maar te deleten. Je kan veel meer winst behalen door andere componenten te selecteren. Bijvoorbeeld LXDE in plaats van Gnome of Abiword in plaats van OpenOffice. Kijk eens naar de distributies die zich richten op oudere computers, zoals Damn Small Linux, die hebben het grootste deel van het werk al gedaan.

[DeNachtwacht]

Tha_Butcha schreef op vrijdag 23 oktober 2009 @ 02:06:
mmm, voor zover ik weet is ie echt custom hoor.

quote wikipedia


[...]


Ben nu te lui om mijn netbook te pakken, maar ik weet zeker dat mijn server over zijn nek zou gaan met die kernel en vice versa, al was het maar vanwege de processor.

Daarnaast zitten er o.a. een SSD in, een webcam, touchpad (multitouch capable) en een veel kleiner scherm. En dat werkt allemaal out of the box.Daarbij is netbook al redelijk snel voor mijn gevoel. Heb geen benchmarks hier liggen, maar een logge XP install die niet is getweaked gaat het echt niet redden op een netbook hoor.

En verder ontopic: zoals eerder gezegd, versie nummers zullen me eerlijk gezegd aan mijn reet roesten, Het enige wat ik wil is een stable kernel, die ik zelf kan compilen en al mijn hardware ondersteunt, wat ie ook precies doet.

Ik begin nu ook te twijfelen. Feit is wel dat de UNR image 680 mb groot is t.o.v. 687 mb voor de normale versie, dus erg veel optimalisatiewerk lijkt er niet gedaan te zijn.

[Borromini]

HetWonder schreef op vrijdag 23 oktober 2009 @ 01:29:
Het netbook menu staat me zeer aan, maar er kan volgens mij zeer veel meuk uit. Juist voor netbooks zal dat volgens mij veel snelheid kunnen opleveren. Heel veel overbodige configbestanden, drivers, modules etc zal toch zeker wel snelheidswinst opleveren voor een minimale machine als een netbook? Het lijkt me dat het allemaal een stuk lichter moet kunnen op zo'n ding.

Drivers maken deel uit van de kernel. Als jij daarin wil gaan hakken: veel plezier . Ubuntu heeft ongetwijfeld wel een paar extra pakketten die je kan verwijderen, maar 95% van de drivers waar jij over spreekt zitten in één pakket - dat van de kernel. Een volledige kernel met alle toeters en bellen zal ettelijke tientallen MB in beslag nemen, maar modules worden alleen maar geladen indien ze nodig zijn en vertragen de kernel dan ook nauwelijks. Configuratiebestanden nemen dan weer nauwelijks plaats in - en ze horen altijd bij een programma. Die paar tekstbestandjes, daar komt het echt niet op aan.

Uiteindelijk is een netbook alleen qua specs 'minimaal'. De hardware die erin zit functioneert net zoals elke andere x86-hardware.

[laurencevde]

Je kunt altijd de boottijd nog wat verkorten door initrd te schrappen, en de benodigde modules direct in de kernel te bakken...

Verder doet udev er ook nog een tijdje over om zijn werk te doen. Dat kan je schrappen, of iig een hoop regels ervan, scheelt ook weer wat boottijd, maar kost wel flexibiliteit.

Als je ergens een linux-server/ permanent bereikbare desktop hebt staan, kan je daar ook nog interessante dingen mee doen, bijv. als bestandsserver gebruiken, liefst nfs+cachefs, of remote applicaties op draaien, liefst via NX.

Je kunt het complete OS in een squashfs stoppen. Is alleen-lezen, maar wel een stukkie sneller.
Als je dan de rest van de bestandsruimte op je netbook puur als cache gebruikt, kun je ook enigszins risico op bestandssysteemcorruptie accepteren, en bijv. wat minder veilige mount-opties gebruiken(bijv. nobarrier, geen journal). Maakt het ook weer wat sneller.

Je kunt behoorlijk gaan snijden in de scripts die bij het opstarten gedraaid worden.

Veel power-management staat, voor de algehele stabiliteit, nogal conservatief ingesteld. Enjoy.

Dit zijn dingen die niet echt te doen zijn voor een OS voor algemeen gebruik, omdat ze nogal afhankelijk zijn van de specifieke situatie. Maar voor eigen gebruik kan het natuurlijk wel...


Maarre, beginnen we niet een klein beetje offtopic te raken?


ONtopic:
Er is GEEN ENKELE echte microkernel voor algemeen gebruik. Er zijn er een paar voor embedded-systemen, en daar houdt het mee op. Mac OS X heeft een hybride kernel, met een dunne bodem, en daar bovenop de feitelijke kernel. Windows heeft een gedrocht gecreëerd. Dat ding stamt af van een microkernel, maar MS, en de hardwarefabrikanten et al, hebben in de tussentijd dusdanig veel in de kernel lopen proppen dat er van micro weinig over is. En de belangrijkste reden voor een microkernel, de stabiliteit, is ook ver te zoeken...

Een microkernel heeft 2 voordelen: stabiliteit en veiligheid. Met een goed ontwerp gebeurt er verder weinig als er een onderdeel crasht. En dat ene onderdeel kan je dan simpelweg herstarten. Bij een macrokernel neem je meestal de complete kernel mee... Ook hebben onderdelen niet volledige toegang, wat de veiligheid aanzienlijk vergroot.
Als nadeel zit je echter wel met het probleem dat je, om die voordelen te kunnen bereiken, elke keer als de ene module de ander aanroept goed moet kijken of-ie dat wel mag. Dat is nogal vertragend. Ook zal je heel voorzichtig moeten zijn met niet-helemaal-veilige functionaliteit, zoals dma. (daarmee kan een apparaat zelf bij het geheugen, en dus de kernel passeren...)
Het heeft niet veel zin om nu nog te gaan proberen de linux-kernel naar een microkernel te verbouwen. Daar is-ie intussen toch net iets te groot voor geworden, tegen de tijd dat je klaar bent is de monilitische kernel alweer een heel stuk verder, en er behoorlijk performance uit krijgen wordt ook nogal lastig.
Wel krijgt de linux-kernel steeds meer mogelijkheden om drivers in userspace te planten. Bijv. USB-drivers, fuse, en nu ook cuse.
Ik kan me weinig andere redenen bedenken om een 3.0 te gaan beginnen...

[DeNachtwacht]

Borromini schreef op vrijdag 23 oktober 2009 @ 19:20:
[...]

Drivers maken deel uit van de kernel. Als jij daarin wil gaan hakken: veel plezier . Ubuntu heeft ongetwijfeld wel een paar extra pakketten die je kan verwijderen, maar 95% van de drivers waar jij over spreekt zitten in één pakket - dat van de kernel. Een volledige kernel met alle toeters en bellen zal ettelijke tientallen MB in beslag nemen, maar modules worden alleen maar geladen indien ze nodig zijn en vertragen de kernel dan ook nauwelijks. Configuratiebestanden nemen dan weer nauwelijks plaats in - en ze horen altijd bij een programma. Die paar tekstbestandjes, daar komt het echt niet op aan.

Uiteindelijk is een netbook alleen qua specs 'minimaal'. De hardware die erin zit functioneert net zoals elke andere x86-hardware.

Ik schaarde me tot vanmiddag nog aan de kant van de sceptici, maar ik heb inmiddels gevonden wat ik hoopte. Intel is bezig met een linux versie die geoptimaliseerd is voor de Atom processor: Moblin.
Ziehier het verschil in boot time tussen Ubuntu 9.04 en Moblin 2 en sta verbaasd!

De app is nog in ontwikkeling maar t laat wel zien dat ubuntu zeker fiks kan worden uitgedund

[ Voor 3% gewijzigd door DeNachtwacht op 23-10-2009 23:57 ]

[H!GHGuY]

laurencevde schreef op vrijdag 23 oktober 2009 @ 22:03:
ONtopic:
Er is GEEN ENKELE echte microkernel voor algemeen gebruik. Er zijn er een paar voor embedded-systemen, en daar houdt het mee op.

GNU/Mach (GNU/HURD kernel) binnen Debian GNU/HURD ?

[Borromini]

HetWonder schreef op vrijdag 23 oktober 2009 @ 23:56:
[...]


Ik schaarde me tot vanmiddag nog aan de kant van de sceptici, maar ik heb inmiddels gevonden wat ik hoopte. Intel is bezig met een linux versie die geoptimaliseerd is voor de Atom processor: Moblin.
Ziehier het verschil in boot time tussen Ubuntu 9.04 en Moblin 2 en sta verbaasd!

De app is nog in ontwikkeling maar t laat wel zien dat ubuntu zeker fiks kan worden uitgedund

Een vriend van me heeft dat op z'n netbook geïnstalleerd, bleek het ding geen DivX/XviD en MP3 af te spelen. Hij gaat zijn licht opsteken bij de community, en wat blijkt: Intel verwacht dat je een licentie voor beide codecs koopt (MP3 en DivX). Way to go zou ik zeggen...

Needless to say dat hij dat onding er binnen de kortste keren weer afgegooid heeft .

Oh en wat die 'optimalisatie' betreft: maak je niet teveel illusies. Misschien dat Intel inderdaad wat tweaks heeft doorgevoerd maar het is geen compleet nieuwe codebase. Moblin is gebaseerd op Fedora.

Als je echt een geoptimaliseerde omgeving wil dan gooi je er toch gewoon Gentoo op en compileer je naar hartelust?

[DeNachtwacht]

Das waar, maar het gaat me niet zozeer om de lol van het compileren (goh wat een verassing) maar om een gebruiksvriendelijk en supersnel OS, en er is voor op de netbook weinig dat moblin kan verslaan denk ik.

Enige nadeel is idd mp3 en divx support jah, ik was er ook achter gekomen. MP3 is nog gratis te installeren, maar ik erger me dr ook mateloos aan. Heb je een systeem dat 100% perfect is, eigenlijk helemaal mijn wens en dan zit gstreamer-bad en gstreamer-ffmpeg niet in de repo. en je kan ook niks handmatig installeren Onzin.

[mithras]

Een kernel is een kernel. Dus wat als je nu de moblin kernel in je UNR stopt? Gewoon de moblin kernel config kopiëren en met die config in je netbook je eigen kernel neerzetten. Die andere pakketten zijn binnen Ubuntu wel allemaal toegankelijk (en maken voor je kernel niets uit).

[Yucko]

@ HetWonder:

Ook geen VLC ?

[ Voor 36% gewijzigd door Yucko op 24-10-2009 17:09 ]

[CAPSLOCK2000]

Borromini schreef op zaterdag 24 oktober 2009 @ 16:19:
Een vriend van me heeft dat op z'n netbook geïnstalleerd, bleek het ding geen DivX/XviD en MP3 af te spelen. Hij gaat zijn licht opsteken bij de community, en wat blijkt: Intel verwacht dat je een licentie voor beide codecs koopt (MP3 en DivX). Way to go zou ik zeggen...

Intel heeft niks te kiezen, ze mogen het gewoon niet gratis weggeven.

[Borromini]

Maar ze zouden wel, zoals andere 'aanbieders' van distributies doen, op mirrors buiten de VS codecs kunnen aanbieden, of de gebruikers kunnen informeren over hoe ze die dingen wél kunnen afspelen. Suggereren dat ze maar even een licentie kopen is wel iets anders.

[DeNachtwacht]

JaJoah schreef op zaterdag 24 oktober 2009 @ 17:08:
@ HetWonder:

Ook geen VLC ?

Staat helaas ook niet in de repos... de enige mogelijkheid is het handmatig installeren in de console. Niet ideaal dus.

[Keeper of the Keys]

Borromini schreef op zaterdag 24 oktober 2009 @ 17:58:
Maar ze zouden wel, zoals andere 'aanbieders' van distributies doen, op mirrors buiten de VS codecs kunnen aanbieden, of de gebruikers kunnen informeren over hoe ze die dingen wél kunnen afspelen. Suggereren dat ze maar even een licentie kopen is wel iets anders.

Ik denk dat je de macht van de advocaten binnen multinationals zwaar onderschat.
Canonical Ltd. is in Europa gevestigd en hoeft zich dus heel wat minder zorgen te maken dan het Fedora Project dat door het Amerikaanse Red Hat wordt ondersteund/gerund.

Op moblin kun je waarschijnlijk net als voor Fedora (aangezien het Fedora based is) een externe repo toevoegen, maar zij zelf (zeker aangezien ze door intel worden betaald) kunnen jou niet aanraden om dat te doen.

Verder vraag ol me af hoe de moblin boot vergelijkt met de Ubuntu 9.10 boot (upstart) want die is op nieuwe systemen van-je-stoel-af-vallen snel....

[DeNachtwacht]

Keeper of the Keys schreef op maandag 26 oktober 2009 @ 00:06:
Op moblin kun je waarschijnlijk net als voor Fedora (aangezien het Fedora based is) een externe repo toevoegen, maar zij zelf (zeker aangezien ze door intel worden betaald) kunnen jou niet aanraden om dat te doen.

Verder vraag ol me af hoe de moblin boot vergelijkt met de Ubuntu 9.10 boot (upstart) want die is op nieuwe systemen van-je-stoel-af-vallen snel....

1. moblin heeft geen mogelijkheden om de repositories aan te passen
2. het youtube filmpje moblin vs ubuntu 9.04 boot time al gezien?