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

Linus Torvalds, de Fin die aan de wieg stond van de Linux-kernel, heeft op de LinuxCon in Portland zijn opensource-OS getypeerd als 'bloated', 'eng' en 'uit zijn voegen gegroeid'. Toch zou de ontwikkeling van de kernel goed verlopen.

TuxDe Linux-kernel, waar Torvalds in 1991 aan begon te werken, is in de loop der jaren door de bijdragen van talloze bedrijven en ontwikkelaars uitgegroeid tot een omvangrijk geheel. Zo kende versie 2.6.30 meer dan 11,5 miljoen regels code. Volgens Torvalds, die nog steeds toeziet op de doorontwikkeling van de Linux-kernel, voldoet het huidige ontwikkelmodel prima. Dit beeld werd onlangs nog onderschreven in het rapport 'Linux Kernel Development' van de Linux Foundation.

Ondanks dat de ontwikkeling van de kernel soepel verloopt, ziet Torvalds problemen, zo schrijft InternetNews.com. Volgens de Linux-goeroe is de omvang van de kernelcode te groot geworden: "We hebben zeker niet de gestroomlijnde en efficiënte kernel die ik 15 jaar geleden voor ogen had. De kernel is gigantisch en bloated", zo hield Torvalds het luisterend publiek voor.

Torvalds stelde dat elke nieuwe feature die aan de bestaande kernelcode wordt toegevoegd het probleem groter maakt. Toch was Torvalds niet van mening dat er in het huidige ontwikkeltraject te snel features worden toegevoegd. Bovendien zouden ontwikkelaars steeds sneller bugs in de code ontdekken en deze ongedaan maken. De opmerkingen van Torvalds zijn desondanks opvallend, omdat vanuit de Linux-ontwikkelgemeenschap dikwijls het Windows-besturingssysteem wordt aangewezen als bloatware.

Torvalds liet ondanks zijn kritische kanttekeningen over de ontwikkeling van de Linux-kernel weten dat hij door de huidige opzet weer tijd heeft gevonden om zelf code te schrijven. Momenteel zou hij gemiddeld twee commits per week aandragen voor het opensource-OS. Verder liet Torvalds weten dat in de loop der jaren zijn motivatie voor het doorontwikkelen van Linux niet langer technisch van aard is, maar tegenwoordig vooral voortkomt uit zijn contacten met de ontwikkelgemeenschap. Ook liet de Fin zich ontvallen dat hij dol is op ruzie maken en kan genieten van het deelnemen aan of het starten van een flame thread.

Gerelateerde content

Alle gerelateerde content (30)
Moderatie-faq Wijzig weergave

Reacties (132)

Haha, geeft hij eindelijk toe dat prof. Tanenbaum gelijk had:

http://en.wikipedia.org/w...m%E2%80%93Torvalds_debate

Die zei in 1991 dat Linux bij distributie eigenlijk technologisch achterhaald is om twee redenen:
  • Het was niet portable, omdat het puur en alleen voor de 386 geschreven was. Dat hebben ze goed gefixt, als er nu iets portable is is het wel Linux.
  • Het heeft een monolitische kernel, in plaats van een microkernel. Dat is imho wat Linux uiteindelijk nog eens gaat opbreken, want dit is niet zo makkelijk meer te fixen. Die kernel barst ondertussen zwaar uit zijn voegen.
Die discussie speelt zich inmiddels op het gebied van de paleontologie af.

Als je het artikel zou lezen, zie je dat de kernel sneller dan ooit wordt gefixed. "Makkelijker fixen" is nooit een overweging geweest. Stabiliteit en performance wel.

Theoretisch zou een microkernel ontwerp aan stabiliteit kunnen winnen, terwijl dit performance kost. Voor uitgebreide toepassingen is een puur microkernel ontwerp geeneens haalbaar.

De geschiedenis heeft trouwens uitgewezen dat stabiliteit geen issue is voor Linux. Toegeven dat Tanenbaum gelijk had zou zo ongeveer gelijk staan aan een leugen verkondigen.
Microkernels zijn theoretisch beter, maar practisch blijkbaar niet haalbaar. Of ken jij een besturingssysteem met een microkernel?

Waarom zou een microkernel trouwens niet 'uit zijn voegen barsten'? Als je bepaalde dingen niet in de kernel steekt zullen ze ergens anders moeten zitten en verplaats je IMO gewoon het probleem...
Ik geloof niet dat Linus bedoelt dat er te veel drivers zijn. Of je nu drivers hebt voor 3 chipsets of voor 50, aan de structuur van de kernel verandert er niks.

Laat ik als voorbeeldje geluid nemen.
Je hebt een algemeen stuk, Alsa, en drivers voor de individuele chipsets. Met Alsa en die drivers is niks mis. Helaas zijn er een hoop goedkope geluidskaarten die maar 1 geluidje tegelijk kunnen spelen. Wil je toch meerdere geluidjes door elkaar horen dan moet je die in software door elkaar mixen. Je kan je afvragen waar dat moet gebeuren. Je zou het in de driver kunnen doen, je kan het in Alsa doen, je kan de applicaties zelf laten doen, of je kan er een aparte applicatie voor schrijven.

Als je het in de driver doet, dan moet je het voor iedere kaart die het nodig heeft opnieuw doen.
Het voordeel van het door Alsa laten doen is dat het in een keer werkt voor alle geluidskaarten, en de gebruiker er niks voor hoeft te doen. Het nadeel is dat je weer een extra stukje software in de kernel duwt, en dat de daar voor benodigde infrastructuur ook aanwezig is als je er geen gebruik van maakt.

Een alternatief is zo veel mogelijk door aparte programma's te laten doen, die in userspace draaien. Helaas zal dat nooit zo snel zijn als het binnen de kernel houden. Het andere nadeel is dat zo'n applicatie wel geinstalleerd en beheerd moet worden, en iedere keer dat de kernel verandert bijgewerkt moet worden.

Het heeft ook grote voordelen. Het is makkelijker om een apart programma te maken dan om een driver te schrijven; als programmeur veel meer gereedschap tot je beschikking.
Nog een voordeel is dat je programma's "gewoon" kan herstarten. Als het programma crasht dan hoef je nog niet direct je hele systeem te gaan rebooten. Je zou zelfs een ander programma kunnen gebruiken. Misschien wil jij graag wat echo toevoegen, dat zou je dan prima op dezelfde manier kunnen doen.

De grote voorwaarde is wel dat je een goede manier hebt om met de kernel te communiceren. Als je niet in de kernel zit ben je toch een beetje tweederangs burger, en mag je niet zomaar overal bij. Ook is de communicatie tussen kernel en programma relatief langzaam.

Er bestaat al een tijdje zo'n interface voor "block devices" (harde schijven en CD's) genaamd FUSE. Hiermee kun je als gebruiker zelf drivers toevoegen en laden. Bijvoorbeeld een driver die een FTP server er uit laat zien als een lokale hardeschijf.

Sinds kort is er ook zo'n interface voor "character devices" (zoals geluidskaarten). Ik denk dat je Linus' opmerkingen in dat licht moet zijn. Hij zegt eigenlijk "Jongens, we hebben een nieuw speeltje; gebruik het aub, want dat ruimt lekker op." Maar als je het zo zegt doet niemand het, dus draait hij er een lekker punt aan.
(bijna) alle software dat door ontwikkeld wordt, wordt bloated. Software is nooit af omdat klanten dan geen nieuwe versie kopen, er moet dus door ontwikkeld er moeten features bijkomen en dan krijg je vanzelf het bloated probleem. Nero is daar een heel goed voorbeeld van, evenals Paitn Shop pro.

Eigenlijk doet MS het met windows en office helemaal niet zo slecht.. KDE heb ik altijd al bloated gevonden maar Linux met gnome komt totaal niet bloated op me over.
Het is zeldzaam dat zoveel misverstanden in een paar zinnetjes passen

De linux-kernel wordt niet verkocht, dat is dus geen reden om deze bloated te maken en je kan het niet vergelijken met applicatie-software, wat jij een paar keer in een adem noemt.
Je kan de Linux-kernel ook niet vergelijken met WIndows. Windows is een compleet OS, terwijl de kernel maar een klein deel van een OS is. KDE staat er helemaal buiten,Gnome ook. Beiden hebben niets met de Linux-kernel te maken, maar draaien er onafhankelijk van. Beiden zijn bijvoorbeeld ook verkrijgbaar voor BSD, en er is zelfs sprake van KDE voor Windows

De kernel in Linux breidt vooral uit vanwege de toenemende hardware-ondersteuning, en die is vooral modulair. Het is dus ook niet zo dat de in productie zijn kernel bloated hoeft te zijn (ongebruikte driver-modules niet laden), maar de code-base wordt erg groot.
Die misverstanden valt wel mee.
Ik weet het verschil tussen een kernel en een applicatie, daarom heb ik het over software in het algemeen, dat ik twee applicaties als voorbeeld noem doet daar niks aan af.

Alle software wat uitgebreid wordt, bijna altijd om nieuwe functionaliteit te ondersteunen wordt op den duur bloated. Of dat nu om een kernel gaat of om een applicatie of het hele windows OS maakt geen verschil.

Het enige wat helpt is alles weg gooien en over nieuw beginnen.

Blijkbaar is het modulair zijn van linux ook geen "oplossing", anders bestond dit "probleem" niet.
Blijkbaar is het modulair zijn van linux ook geen "oplossing", anders bestond dit "probleem" niet.
Het is wel een oplossing, het zorgt ervoor dat code die niet benodigd is niet wordt geladen.
Het probleem is niet dat de kernel in runtime bloated is, daar is veel aan te doen, en dat is configureerbaar. Veelal gaat het automatisch.
Ondanks dat de ontwikkeling van de kernel soepel verloopt, ziet Torvalds problemen, zo schrijft InternetNews.com. Volgens de Linux-goeroe is de omvang van de kernelcode te groot geworden
Het probleem van Torvalds betreft het aantal code-regels, dat is een heel ander probleem dan hier door de meesten wordt besproken. Toch staat dat letterlijk in het artikel, en het is ook logisch dat hij het alleen daarover kan hebben.

Nu zie ik een groot aantal code-regels niet als een probleem. Aantallen code-regels zeggen niets over de kwaliteit van de code.
Torvalds zal dat ook wel inzien, hij heeft gewoon een terloopse opmerking gemaakt. Hoge bomen etc.... Overigens wordt voortdurend aan de kernel gewerkt door een kleine 300 programmeurs. Code wordt vaak opnieuw gestructureerd. Dus het is een ongoing onderhoudsproces, het heet refactoring, zoals dat gebruikelijk is in alle complexe software-ontwikkeling.

Een van de gouden stelregels van refactoring: question: when should I refactor? answer: always.

[Reactie gewijzigd door SimonKroller op 22 september 2009 16:07]

Correctie: het is wel degelijk de runtime die bloated is. Uit de source:
Citing an internal Intel study that tracked kernel releases, Bottomley said Linux performance had dropped about two per centage points at every release, for a cumulative drop of about 12 per cent over the last ten releases. "Is this a problem?" he asked.
en:
The kernel is huge and bloated, and our icache footprint is scary. I mean, there is no question about that. And whenever we add a new feature, it only gets worse.
Het gaat dus om het trager worden. De code-regels is juist geen probleem meer volgens hem:
the development model actually seems to be working. And it’s working better than it did even just 6 months ago, and certainly a year ago
I stand corrected

Het is natuurlijk zo dat de kernel groeit vanwege de meer soorten hardware die standaard in een PC zitten. Dit is echter een probleem voor alle operating systems.
Maar dat de kernel daardoor langzamer zou worden vind ik raar. Want de code wordt alleen doorlopen wanneer het stukje betreffende hardware in gebruik is.

Hoe meet je objectief de snelheid van een kernel. Dan moet je een oude kernel en een nieuwe kernel op dezelfde machine laten draaien, en dan een aantal taken laten uitvoeren die tot een veelzeggend gemiddelde komen.

Maar dan zit je gelijk met het probleem dat de oude kernel de hardware op de nieuwe machine maar deels ondersteunt, en zal daardoor sneller worden omdat hij dan minder doet.

Met andere woorden, waar gaat dit dan over, appels en peren?

Ik heb ooit voor test doeleinden Windows 3.11 gedraaid op een machine uit het jaar 2000. Ik kon alleen maar 16 kleuren VGA draaien omdat de videokaart niet werd ondersteund.
Maar verder, razendsnel. In minder dan 1 seconde MS Word op het scherm.
Maar is dat zinvol, is dat interessant? Voor mij vanwege een test, maar verder, om daar de wereld over in te lichten?

[Reactie gewijzigd door SimonKroller op 22 september 2009 16:49]

Ik heb ooit voor test doeleinden Windows 3.11 gedraaid op een machine uit het jaar 2000. Ik kon alleen maar 16 kleuren VGA draaien omdat de videokaart niet werd ondersteund.
Maar verder, razendsnel. In minder dan 1 seconde MS Word op het scherm.
Maar is dat zinvol, is dat interessant? Voor mij vanwege een test, maar verder, om daar de wereld over in te lichten?
Ja, dat is het hele punt. Zestien kleuren is erg beperkt, maar het is goed om de vraag te stellen van: willen we niet teveel.

Vor fotobewerking zijn meer fleuren zinvol, maar voor een briefje (Word-documentje) feitenlijk niet. Je draagt dus continu 80% belasting mee voor die ene keer (20%) dat je wel een foto gaat bewerken/filmpje gaat kijken op dat systeem.

In den beginne verafschuwde de gemiddelde linux-gebruiker de GUI van Windows (3.11, 95) juist omdat ze alles wat ze wilden konden zonder GUI op de commandline, en het was juist die GUI die Windows relatief traag maakte. Nu kan, op de desktop, vrijwel niemand meer zonder GUI, en is dit verschil grotendeels verdwenen. De grotere code-base heeft ook het aanvankelijke voordeel van nauwelijks bugs/security-issues in Linux doen verkleinen. Het verschil tussen de Linux wereld en de Windows wereld zit hem nu meer in filisofie gratis/open source versus betaald/closed source.

Tegenwoordig wilt iedereen graag ook dat filmpje kunnen bekijken, maar mischien moet je, zolang je dat soort dingen niet doet de kleurdiepte en schermresolutie wel beperken. De meeste GUI/DE's zijn dan echter niet meer flexibel genoeg.
nog meer vorm foutjes??

overnieuw beginnen is GEEN optie, het wiel opnieuw starten, zal ongetwijfeld veel tijd kosten, en betekend net als bij de huidige kernel, weer dat er veel ontwikkelaars aan zullen werken - met verschillende code-stylen... en dus wordt de code WEER bloated.

de oplossing moet je dan dus structureler zoeken dan opnieuw starten...

dat kan door grote delen te herdefineren.

de nieuwe wifi stack is daar een goed voorbeeld van... - wanneer je dat op de hele code toepast, - ga je code vaker herbruiken en wordt je kernel een stuk lichter, - maar pottentieel ook gevoeliger ...
Volgens mij zijn er distro's waar je voor betaald?
dat staat los van de kernel, die kun je downloaden
Het is Apple anders wel gelukt om een nieuwe versie van het OS te maken dat minder bloated is maar wel minstens evenveel functionaliteit bevat. Dit moet ik tenminste geloven uit de voordelen van Snow Leopard t.o.v. Leopard. Als ik de geluiden uit de pers mag geloven is dit ook het geval voor Windows 7 t.o.v. Vista.
in het geval van snow leopard vs leopard, kwam dat voornamelijk doordat ze de ondersteuning voor de powerpc architectuur hebben laten vallen in snow. Dat maakt de universal binaries een stuk kleiner. (in weze is zo'n binary een dubbele, vroeger zelfs 4-dubbele binary, met seperate binaries voor iedere ondersteunde architectuur in 1 groot bestand gerold). Een Universal Binary op Snow Leopard heeft nu nog maar 2 architecturen: i386 en x86_64.

In Windows 7 hebben ze vooral de boel geoptimaliseerd, maar of windows 7 echt kleiner is? De kernel wel dacht ik, maar de rest van het OS is nog steeds behoorlijk groot.

In Linux gaat 't er Linus vooral om dat er teveel regels code, die te weinig geoptimaliseerd is in terecht is gekomen. Dat zou in de toekomst de snelheid van het ontwikkelen en de performance kunnen benadelen.

[Reactie gewijzigd door arjankoole op 23 september 2009 07:46]

Apple heeft zeker wat code geoptimaliseerd, maar de grote voordelen qua footprint zitten hem in het enerzijds droppen van PPC ondersteuning, en anderzijds het comprimeren van localization data, en zelfs de binaries zelf.
In de commercile wereld moet er steeds weer een nieuwe versie komen met meer features, mooiere looks zodat klanten een nieuwe versie kopen. Programmeurs worden daarvan betaald. Bugs verwijderen is bijzaak, dient alleen om klanten tevreden te houden.

In de Free Software wereld ontstaan nieuwe versies omdat men fouten verwijderd en men bepaalde functionaliteit (features?) mist en die toevoegd en verbeterd. Of het pakket daarmee beter verkoopt of een grotere gebruikersgroep vindt is minder belangerijk. Staat een project stil omdat het is uitontwikkeld (zoals veel Gnu tools), dan zoeken de programmeurs andere projecten om aan te werken. Nadeel is dat hierdoor een pakket uitstekend kan voldoen voor de makers en eventuele huidige gebruikers maar dat dit, en hetgeen de makers zinvol vinden om toe te voegen geen grote doelgroep aanspreekt.

De kunst is dan om daarin een balans te vinden, tussen wat de makers zinvol vinden om toe te voegen en wat de gebruikers willen. Dat is wat Ubuntu en diens afgeleiden anders maakt als andere distributies. Uiteraard zijn er voor de producten van Red Hat, Suse doelgroepen die aansluiten en zijn er mensen die de filisofie van Debian of Fedora zeer aanspreekt, maar geen van hen spreekt de gebruiker aan in de mate waarin Ubuntu dit doet.

Ook Haiku probeert die balans te vinden, waarbij zij uitgaan van wat hen zo aansprak in BeOS maar Minix3 en vele andere zijn nog niet zover.

Uiteraard is, zolang er steeds nieuwe hardware uitkomt waarmee het moet gaan werken, een OS nooit af en hoe meer hardware het ondersteund hoe meer bloated het wordt. Tussen een zinvolle toevoeging van hardwareondersteuning, bij voorkeur gecombineerd met het gefaseerd verwijderen van ondersteuning voor zeer oude, en een weinig zinvolle toevoeging van steeds meer features en flauwekul is echter een groot verschil.

Nero was uitstekende brandsoftware, en omdat het drivers en codecs toevoegde die in het OS ontbraken is men gaan verbreden naar mediaspeler en mediabewerker.
Dat had men nooit moeten doen. Al deze functionaliteit zou ook modulair moeten zijn. Wie zijn homevideo's wilt bewerken en branden kan twee pakketten nemen die op elkaar aansluiten. Dat is ook een onderdeel van de filosofie die men terugziet bij de free software, Gnu en linux communities. Commercie verkoopt liever een all-in-one oplossing.
Hij kan zich vast redden met een kleine kernel en een zo kaal mogelijk OS.
Maar Linux noobs als mijzelf willen graag dat alles zo simpel mogelijk werkt en dat ik niet eerst drivers moet compileren en toevoegen voordat ik het OS kan installeren.

Ik ben benieuwd hoe groot de Linux kernel is vergeleken met die van OS X, die moet natuurlijk een stuk minder hardware ondersteunen.
OSX heeft dan ook de XNU kernel (met als onderdeel de Mach kernel in zich), Dit is een hybride kernel waar veel dingen in userspace worden gedaan, dus niet in de kernel zelf. De kernel biedt alleen via een gecontroleerde, minimalistisch interface toegang tot hardware. Dit voorkomt dat drivers bv verkeerde geheugen blokken knnen aanspreken wat onvoorspelbare implicaties heeft, zoals kernel panics.
De XNU kernel zal dan ook over het algemeen iets meer lichtgewicht zijn, daarentegen wordt er dan wel weer meer afgehandeld in userspace, wat meer context changes teweegbrengt (wisselen van real mode naar protected mode op een x86 processor), wat dus voor meer overhead zorgt.

in een notendop is dit dus ook de afweging die je moet maken tussen monolitsch en een hybride/microkernel.
Of een elegant ontwerp: microkernel f voor zoveel mogelijk snelheid gaan en overhead verminderen: monolitisch.

Het feit dat de linux-kernel modules heeft zegt niet dat het een microkernel is, de linux-kernel-modules draaien nog steeds in real-mode, en kunnen dus ieder de kernel laten crashen. In linux is het dus nog belangrijker om code doorgrondig te testen.

/sidenote
In XNU en de NT-kernel wordt voor een groot deel ook nog steeds gewoon drivers* gemaakt die in real mode draaien.
Terwijl het FUSE project voor linux weer een groot gedeelte van de filesystem-drivers uit de kernel wil halen. Kortom, het is een beetje een grijs gebied

*= met windows vista is microsoft een nieuwe weg ingeslagen met betrekking tot graphics drivers om zoveel mogelijk functionaliteit uit de kernel te halen:
http://msdn.microsoft.com/en-us/library/aa480220.aspx

[Reactie gewijzigd door DLGandalf op 22 september 2009 14:46]

*= met windows vista is microsoft een nieuwe weg ingeslagen met betrekking tot graphics drivers om zoveel mogelijk functionaliteit uit de kernel te halen:
http://msdn.microsoft.com/en-us/library/aa480220.aspx
Eigenlijk is dat wel grappig, want NT3.1 had ook al userspace graphics. De prestaties waren op grafisch gebied zo traag, dat het zelfs 2D-programma's vaak met moeite vloeiend kon weergeven, laat staan 3D-software. Daarom heeft men in NT4, Win2k en XP de grafische drivers in de kernel gehangen.
Goh, komt me dat even bekend voor.
Dat is toevallig :P
Ik kan Windows XP niet installeren zonder eerst drivers toe te voegen :P

(nou moet ik daaraan toevoegen dat het in Windows voor de gemiddelde consument/leek iets makkelijker geregeld is)
Nou: drivers opzoeken, slipstreamen in een cd image, dat nieuwe image branden en dan installeren. En dat alleen als ik XP wil installeren op een laptop met een sata harddisk. :(
Maar je kan toch alles wat je niet nodig hebt nog steeds uit de kernel slopen? Dat distro's zoals Ubuntu een grotere kernel hebben is omdat ze willen dat het out-of-the-box op bijna alle configuraties draait. Maar dat betekent niet dat de kernel bloated moet zijn om te kunnen draaien. En mijns inziens is het toch juist goed dat er zoveel code wordt geschreven voor de kernel, want dan is er meer hardware ondersteuning en dat is prima. Of hij bedoelt het op een andere manier of ik vat het niet helemaal :P
Of hij bedoelt het op een andere manier of ik vat het niet helemaal
Linux is een monolithische kernel, en dus groot. Andere kerneltypen zijn de microkernel, en de hybride kernel zoals die van Windows.
Klopt, vandaar dat ik deze opmerking uit het artikel dan ook een beetje loos vond:
De opmerkingen van Torvalds zijn desondanks opvallend, omdat vanuit de Linux-ontwikkelgemeenschap dikwijls het Windows-besturingssysteem wordt aangewezen als bloatware.
De linux kernel is misschien monolithisch, en de code-base bevat gigantisch veel regels driver code (die je dus niet in je kernel hoeft te laden als je de hardware niet hebt), maar dat wil niet zeggen dat de kernel dan ook 'bloated' is in de zin van: bevat te veel features waardoor het geheel minder efficient of flexibel wordt.

Dit in tegenstelling tot wat er vaak over Windows gezegd wordt, dat draait op een heel erg kleine, gestroomlijnde kernel (sinds NT tenminste), maar los daarvan krijg je er wel hele bergen aan userland code bij die samen het Windows platform vormen. Dat zou je bloated kunnen noemen, omdat het merendeel onmisbaar is om Windows te draaien. Dit in tegenstelling tot Linux, wat je vrij eenvoudig kunt compileren voor 1001 verschillende targets, waaronder zover uitgekleed dat je alleen nog een kernel, een shell en een minimale set van systeembinaries hebt.
Sorry. Windows draait ook op verschillende targets en het is lastig aan te geven hoe moeilijk het is om die andere versies te maken. Zoals je bij windows server en de microsoft hypervisor kan zien is er echt niet veel nodig om windows te kunnen draaien. Je tegenstelling bestaat dus enkel in je eigen hoofd en niet in werkelijkheid.
De windows die ik kan krijgen draait bij mijn weten alleen op x86 en x86-64, het is niet mogelijk voor third parties om het te recompilen naar andere targets, en een windows installatie is volkomen zinloos zonder de hele set API's waarop het platform is gebaseerd er bij te leveren. Dat zit niet in mijn hoofd dat is een feit.

Zoals ferdinand hieronder al aangeeft is CE en WM niet gemaakt omdat Windows zo makkelijk is te porten voor andere toepassingen dan desktop-PC's. Volhouden dat het windows platform zo flexibel en modulair is als de linux kernel + GNU userland, dat zit in jouw hoofd.

[Reactie gewijzigd door johnbetonschaar op 22 september 2009 15:47]

Windows draait ook op verschillende targets en het is lastig aan te geven hoe moeilijk het is om die andere versies te maken.
Er is een reden waarom Windows Mobile en Windows CE bestaan. Windows gaat niet op je mobiel draaien en zeker niet op je koelkast of tv.
De ontwikkeling van Windows NT heeft de ontwikkeling van de hybride kernel richting een monolithische kernel doen gaan, en Linux is allang niet monolithisch meer, maar er kunnen dynamisch features in de kernel worden geladen - een feature van hybride en microkernels.
Ja en nee. Windows NT was bedoeld als microkernel. Wegens performanceredenen zijn er steeds meer functies in gekomen. Nu lijkt Microsoft echter weer de andere kant op te gaan en functies uit de kernel naar userspace te verhuizen zoals dwm. Linux probeert ook om veel functies uit de kernel te houden, maar zoals Torvalds aangeeft niet al te succesvol.
Zou hij dan toch naar een microkernel willen gaan ? ;)

<edit> voor mensen die die opmerking niet kunnen plaatsen: The Tanenbaum-Torvalds Debate http://oreilly.com/catalog/opensources/book/appa.html </edit>

[Reactie gewijzigd door Sentry23 op 22 september 2009 13:58]

Dat lijkt me zeker niet (ben goed bekend met die discussie). Daarvoor is de keuze voor een monilitisch ontwerp te fundamenteel. Maar Torvalds houd er zoals hij ook zegt van om zaken scherp te stellen omdat je dan een bepaald effect krijgt. Zeker als je zoals hij in een unieke positie zit als initiatiefnemer van de kernel.

Hij ziet gewoon een groeiend probleem en heeft gezorgd dat dat nu op de kaart staat.
Tanenbaum had toe gelijk en heeft nog steeds gelijk.
Een monilitische kernel is kleinder dus ALTIJD minder bug en beter te onderhouden.
Helaas heeft Tanenbaum zijn besturings systemen (ja niet aleen Minix) altijd ontwikkeld voor het onderwijs.
Torvald heeft altijd gewerkt aan praktische oplossingen.

Ik hoop (of dromen) dat er ooit iets komt dat tussen Torval en Tanenbaum in zit. Zo praktisch als Linux, en zo netjes als Minix3. :)
Hybride kernel van Darwin/Mac OS-X ?
Helaas doordat de aandacht vrijwel geheel naar Linux gaat is, wordt Darwin nauwelijks verder ontwikkeld, en MacOS is niet geheel Open-Source/Vrij/Gratis.
Ook Minix3 krijgt nauwelijks aandacht en of die aandacht er voldoende is voor Haiku is de vraag.

Met de code die er is voor BSD en Linux moet er zo een leuke distributie te maken zijn als die kernel er eenmaal is, en drivers ook over te zetten zijn.

@Balachmar
Wie zelf zijn kernel compileert kan deze zo slank mogelijk maken. De meerderheid zal echter nooit zijn kernel zelf kunnen compileren. Vroeger had ik bij mijn Ubuntu (4.10 Warty Warthog, 5.04, 5.10) een ready-made AMD-kernel (voor mijn Duron 850, dus niet 64bits) maar in 6.06 en 8.04 heb ik die nog niet gevonden in de repositories.

Op zo'n moment is een micro-kernel juist wel een goede oplossing.
Juist ook door het toenemende verschil in processors/architecturen (Core iX, Core 2, Atom, AMD, ARM) waarvoor de Linux kernel nu gecompileerd wordt, wordt het steeds interessanter om deze op deze manier te stroomlijnen. En mischien ligt de waarheid wel in het midden: een hybride kernel. In principe werkt Linux ook al deels met modules (waaronder usermode modules zoals ntfs-3g)

Kortom: wat echt altijd nodig is gaat in de kernel, de rest, wat niet op alle platformen voorkomt, wordt module. IDE-ondersteuning (p-ata of s-ata) is mischien interessant voor x86 (en x86-64) maar waarschijnlijk weer niet bij ARM-gebaseerde apparaten, dus dat komt dan niet in de kernel, maar wordt dan een module die bij x86-pc's automatisch geladen wordt.

@Antipater
Zijn de drivers voor Linux/BSD niet te compileren voor Minix3, of moet er nog best veel aangepast worden. Zonder drivers wordt het zowiezo moeilijk, dat gold al voor OS/2 en BeOS.

Wat mij trouwens opvalt is dat bij distributies zoals Dragonfly BSD en andere BSD-smaken vaak nog nauwelijks ontwikkeling is gestoken in de GUI/DE.

[Reactie gewijzigd door BeosBeing op 23 september 2009 11:21]

Je haalt wel even de begrippen door elkaar.
De Linux kernel is een monolitische kernel (net als bijna alle grote os-en).
Wat Tanenbaum voorstelde was een micro kernel. En een micro kernel is dus inderdaad kleiner.
Het idee is dat je met een microkernel alleen draait wat je nodig hebt. Maar heeft als nadeel dat er inherent wat meer overhead is. Een monolitische kernel heeft de overhead niet, maar zorgt ervoor dat eigenlijk altijd alles in je kernel hebt zitten.
Hoewel je als je je eigen kernels compiled deze best slank kan maken. (Maar niet te slank, want dat werkt niet goed... :+)
Minix3 wordt niet langer alleen voor onderwijs ontwikkeld maar begint een serieuzere vorm te krijgen.

Het grootste probleem is echter niet de kernel, Minix3 loopt qua kernel wel op een aantal zaken achter maar mist vooral drivers. Dat is iets waar je de grote OS-en niet zomaar op kan inhalen.
Wel, je poogt zo te zien die discussie nieuw leven in te blazen. Beide kampen hebben argumenten aangedragen maar laten we voor het gemak naar de praktijk kijken. We zijn immers behoorlijk wat jaren verder.

Wijs mij eens een succesvolle implementatie van een micro-kernel OS aan in een multi-tasking en multi-user environment.
En neen, Windows en Mac OS beweren hybride te zijn, een monolitische kernel bovenop een micro-kernel waarbij de micro-kernel eigenschappen vrijwel niet benut worden.

Alleen in typische dedicated omgevingen zoals wapensystemen e.d. worden microkernels succesvol gebruikt. Verder nergens, zeker niet in server en kantooromgevingen.
Dat zal best kunnen maar de vraag is of zo'n kernel zal kunnen wat we eisen van een modern OS.
In de tekst wordt gesproken over de code contributie van bedrijven. Het merendeel van de code wordt tegenwoordig door bedrijven gemaakt die het niet als eerste prioriteit hebben om snelle efficiente code te schrijven. Als je de huidige code optimaliseert is het probleem waarschijnlijk al gedeeltelijk weg
Dat zal schelen maar ik denk dat er verder gekeken kan worden: er zit ontzettend veel overlap in delen van de kernel en het generaliseren van die overlap scheelt pas echt veel code. Neem de Wifi stack die wordt nu pas omgezet naar een generieke Wifi laag en een HW specifieke wifi-chip driver. Zo zijn er wel meer stukken te vinden.
Een andere reden die ik hier nog niet gezien heb is de scalability: het draait op een kleine MCU tot een mainframe of distributed cluster met honderden CPUs. Dat krijg je nooit lean-and-mean door de grote verschillen.
De generieke wext-driver bestaat al heel lang hoor (toch wel zo'n 4 jaar).
Zal best, maar degene die gebruikt wordt is de versie van device-scape maar dan opgepoetst. Die Wavelan generieke laag is het volgens mij nooit helemaal geworden (zie ook: http://tuxology.net/wp-co...wirelessLecHerzelinux.pdf)
Neen, precies omdat er zo weinig firmware is die dit echt ondersteunt. Dankzij de FCC is er nooit een low-level toegang kunnen komen voor wifi-hardware, zoals het origineel echt bedoeld was. In plaats daarvan worden nu soms enkel nog IP-pakketjes richting WiFi-firmware gepusht, zodat de wavelan generieke laag inderdaad overbodig is geworden.

Blame litigation and closed-source firmware blobs.
Er bestaat naar mijn weten ook geen (succesvol) OS met een micokernel. Maakt je systeem traag. Oplossingen zoals een hybride kernel (Windows) zijn wel valide.
LOL Mac OS X? :Y)
Mach kernel version:
Darwin Kernel Version 10.0.0: Fri Jul 31 22:47:34 PDT 2009; root:xnu-1456.1.25~1/RELEASE_I386
(hostinfo)
Darwin is de kern (kernel) van Mac OS X, de nieuwste generatie OS van Apple. Darwin is een microkernel-ontwerp gebaseerd op de Mach 3.0 microkernel en de 4.4BSD system services.
(Wikipedia NL)

Of wil men nog steeds niet geloven dat Mac OS X toch echt wel "een van de groten" is? ;)

[Reactie gewijzigd door BezurK op 22 september 2009 20:58]

Als je wikipedia erbij sleurt, doe het dan ook goed:
Een hybride kernel is een combinatie van bovengenoemde twee kernels die bepaalde eigenschappen van de twee werelden combineert. Hybride kernels zijn doorgaans "gegroeide" microkernels, waarbij er meer functionaliteit in een microkernel is geplaatst. Windows NT, BeOS, Darwin (de kernel van Mac OS X) en DragonFly BSD zijn een paar voorbeelden van hybride kernel besturingsystemen.
wiki

Zelfs Symbian kan geen microkernel handhaven. In theorie mooi, maar te inefficient.
Symbian OS has a lightweight 32-bit pre-emptive kernel that follows a hybrid design combining
characteristics from both micro-kernel and monolithic kernel architectures. Symbian OS design focuses
developer.symbian.com
Start op tijd gaan meten? Wat heb je daar nu aan. Je weet niets van wat er in de achtergrond gebeurt op zowel W7 als Ubuntu?

Welke services worden gestart?
Wordt er meteen prefetch data geladen?
Snelle geheugen check virusscanner, of juist niet?
Firewalls ja/nee?
Zwaardere interface die mogelijk mooier/bruikbaarder is?
Andere handige taken die worden gestart die gebruiksgemak bevorderen maar opstarten vertragen?

(note: deze slaan zowel op windows als linux).

Voor een os keuze (/flamewar) is een startup benchmark echt nutteloos. Als beide systemen een beetje normaal starten (in dat filmpje beiden binnen 60 seconden). Dan draai je toch gewoon het OS wat voor jou daarna het fijnste is. Opstarten en afsluiten doe je n keer per dag. Who cares hoe lang dat duurt? Ik zou graag een 15% sneller systeem hebben als dat betekend dat hij 30% langzamer opstart :P.


Wel grappig dat in dit stukje trouwens verwezen wordt naar 'die bloated windows' (staat er niet zo I know). Dat moge misschien waar zijn. Maar qua kernel ontlopen Linux en Windows elkaar niet vreselijk. Er is dan wel geen TinyWindows distro ofzo. Maar dezelfde (ietwat oudere) kernel van windows draait onder WinMob. Net als dat dat ook bij linux kan. Beide kernels zijn in mijn ogen toch vrij clean and mean. Maarja voor een heel os ben je er dan natuurlijk nog niet. (En dan geef ik als MS fanboy wel toe dat Windows soms een wat dik buikje heeft :P ).
Opstarten en afsluiten doe je n keer per dag.
Groot gelijk. Een keer per maand zelfs als je Linux of OSX gebruikt. Op zo een moment is je hibernate al 30 x belangrijker dan je opstarttijd.
En op wie reageer je nou man? Zie je mij ergens de snelheid van Linux in twijfel trekken?
het lijkt me dat als er iets aan gedaan gaat worden, het modularisatie en afsplitsing van onderdelen wordt. ik vind zelf dat het aantal drivers omlaag kan, want veel drivers heb je niet nodig om te booten, en verder zijn er vaak voor n apparaat toch wel meerdere drivers. misschien maar eens beginnen met pluggable scheduling ;-)?
jij houdt ook van het starten van een flame war
Hij houd idd erg van flamen. Tjsa, er zitten tegenwoordig zoveel drivers al in de kernel dat hij idd een beetje bloated is, maar wel handig om meteen werkende hardware te hebben bij een livecd. Al een keer meegemaakt dat een linux livecd een windows server met hp raid array kon redden.
Om meteen een werkende hardware te hebben hoeven de drivers niet in de kernel te zitten. Kijk maar naar Windows PE, waar veel benodigde drivers bijzitten, niet in de kernel, en waar je zelf drivers aan toe kan voegen door ze in een map te plaatsen (en dan een nieuwe DVD branden natuurlijk).
Op de livecd's van linux distributies zitten de drivers doorgaands ook niet in de kernel maar zijn de drivers als modules gecompileerd die door the kernel hardware manager worden geladen wanneer deze hardware gedetecteerd worden.
Alleen zit de code van het merendeel van die drivers wel in de Kernel Source. (Tenminste dat was in 2.4 zo, toen ik uit mobide interesse een tarball heb uitgepakt en door de code ben gaan kijken.)

En de drivers buiten de kernel ontwikkelen schijnt lastig te zijn omdat er nogal vaak wijzigingen zijn in 'echte kernel' waarop drivers aangepast moeten worden.

Ik lees af en toe overigens nog changelogs en het lijkt er erg op dat veel drivers voor nieuwe hardware naar userspace verhuizen. Dat zal het probleem allicht verlichten.
Edit: even geherformuleerd, had je reactie niet goed gelezen:
Ik neem aan dat Torvalds weinig problemen heeft dat er zo veel drivers in de kernel distributie zitten, hoe meer hoe beter zou je denken, daar wordt de kernel zelf niet meer of minder bloated van (slechts de size van de tarball). Als je wilt kun je praktisch elke hardware driver als module compileren (wat de meeste distros dan ook doen).
het probleem is dat de scheiding tussen driver en kernel niet echt geweldig is. Er was nooit een echt stabiel driver model om drivers buiten de kernel te ontwikkelen. Bij een nieuwe kernel moesten de kernels ook weer opnieuw aangepast worden. Dus ja, Torvald wil graag veel drivers in de distributie maar liefst allemaal in userspace en met een gestandaardiseerd drivermodel. Zoals bv in het geval van de Wifi ondersteuning.
Mooie van de linux kernel is dan wel weer dat hij compleet modulair is en dat het zelfs op miniscule embedded systemen kan draaien of zoals ze dat bij de installatie van Arch Linux aanraden: "If you are looking to install Arch on something more exotic, such as your kerosene-powered cheese grater, please consult the wiki" :Y)

Je kunt dan nog zo veel drivers hebben maar als die maar geladen worden als modules is er niks aan de hand, de kernel blijft dan zo klein mogelijk, het kost alleen een klein beetje schijfruimte :)
Op die hele kleine machines wil je juist weer geen modules: de overhead van jumptables om bij de driver te komen zijn significant. Leuk dat het kan op je x86 machine met 4Gb: genoeg cycles om de overhead te verbergen, maar daar heeft het weer geen zin omdat de geheugenbesparing insignificant is.
Kan iemand trouwens recente cijfers vinden van de overhead van een driver via module of in-kernel?
Soms ontkom je niet aan modules. Er zit namelijk nog een groot nadeel aan het drivermodel van Linux: je kunt de volgorde van het initialiseren van de drivers niet aanpassen. Als je een driver hebt die afhankelijk is van een andere driver die later worden geinitialiseerd dan heb je een probleem.
Om dingen weer even in het goede perspectief te zetten:

Linux (Ubuntu): 15 miljoen regels code
Linux live CD: OS met een selectie serieuze open source software.
Minimale systeemeis: Pentium 3, 700 Mhz, 384 MB RAM, 5 GB hdd

Windows (Vista): 50 miljoen regels code.
Windows DVD: Enkel een OS met wat tools.
Minimale systeemeis: 800MHz processor, 512 MB RAM, 20GB hdd

Ik kan het niet laten om nog even iets te quoten:
Windows is bloated vanwege een boel features en de sourcecode van de moderne varianten (xp, vista, 7) zijn echt niet zo bloated meer door rommel, maar puur door ondersteuning. Als linux dat ook wil evenaren dan is het logisch dat ook die code groeit.
Ondersteuning? Hm. Ik heb nog geen hardware gevonden die wl ondersteund wordt door Windows, maar niet door Linux. Sterker nog, legacy producten worden vaak beter ondersteund door Linux. En daarnaast zal bijvoorbeeld USB 3.0 of de nieuwste SATA implementatie als eerste ondersteund worden door Linux. Om maar even wat te noemen.
Ik vind dat niet echt schokkende verschillen in de minimale systeemeisen om eerlijk te zijn.
Helemaal niet als je naar die luchtkastelen kijkt die gemaakt worden over het werken van Linux op een trage bak en hoe geweldig dit gaat.
Ok, ok. 4x HD ruimte is pittig.
Dan heb je een linux met een shell en een windows met een gui, oftwel appels en peren.
Linux met een recente KDE of Gnome draait ook niet meer werkbaar op P3 700mhz.

Windows doe je ook erg te kort door het enkel een OS met wat tools te noemen.
Dan doe je iets niet goed, want bij mij werkt het wel.
Helemaal geen appels en peren. Windows en Linux (in mijn persoonlijke geval Ubuntu) zijn beide OSsen.

Als ik kijk naar de Ubuntu CD, met een heel pakket aan drivers, Gnome 2.x (dat is een GUI, toch?), Open Office, een media player, browser, en nog een hele hoop nuttige software.

Analoog heeft de Windows DVD ook een GUI, maar bijvoorbeeld geen Office pakket aan boord.

Linux met een recente Gnome, werkt gewoon probleemloos op een P3. :)
Het licht eraan wat je 'met wat tools' noemt: Open Office.org zit er bijvoorbeeld standaard al in en zo zijn er nog wel wat zaken die in Windows ontbreken.

En Ubuntu draait prima op mijn Duron 850, enkel bij zware flash (www.funnygames.nl) en sommige games (superTuxKart, Cars*, Need4Speed*) trekt hij het niet meer. (* windows games)
Je vergelijkt het linux kernel met 15M regels code met het complete Windows systeem van 50M regels code. Je hebt zelf niet eens een idee hoeveel code er in de Windows kernel zit.

En ik heb hier nog wel ergens een TV-kaartje liggen waar geen Linux drivers voor zijn, en voor Windows wel. En nog wat draadloze netwerk pruttel.
Het is inderdaad wat lastig te vergelijken.

Ik heb geen cijfers die de omvang van de Windows "kernel" omschrijven.
Het MS Windows XP OS omvat ca. 50 miljoen regels code. Grappig is dat je dan alleen het OS krijgt en weinig extra applicaties. De applicaties die er dan bijzitten worden niet meegerekend met die 50 SLOC. De hele handel moet op een DVD, omdat een CD te klein is.

Het Ubuntu pakket (ik zeg dus niet OS) omvat 121 miljoen regels code, maar de driver libraries zijn veel groter en dit is inclusief repository/functionele software; o.a. een compleet office pakket. Grappig detail is dat dit wl op een CD past.

Met dit als gegeven concludeer ik dat de kernel (OS, zonder GUi en andere toestanden) van Linux hedentendage nog steeds een stuk kleiner is dan die van MS Windows. Als ik er rigoreus naast zit, dan hoor ik dat graag.

Persoonlijk heb ik nooit problemen om hardware aan de praat te krijgen op een machine met Ubuntu. Maar daarbij moet ik de kanttekening maken dat ik meestal geen exotische hardware aanschaf.
Inderdaad, mijn oude scanner dat niet werkte onder Vista x64 draait perfect onder de laatste Ubuntu, plug-and-play dan nog. :-D
bloated, misschien.
Maar er valt nog best wel wat aan te doen hoor.
zoals Chilly_Willy al zegt, het is zeker een pluspunt dat Hardware gewoon werkt, (zelfs vanaf life-cd).

Er valt nog best wel een hoop te verbeteren aan de kernel structuur hoor. zo is er nog zat ruimte om dingen te algemeniseren, te diffrentieren, te refactoren en te optimaliseren.

het grootste commentaar op die stelling is dat dat nu al word gedaan. (ergo de situatie is zelf-verbeterend,mits er niet te veel nieuwe features worden aangedragen die dat proces vertragen)

ik wacht wel af hoe het er bij ligt volgend jaar.
Er valt nog best wel een hoop te verbeteren aan de kernel structuur hoor. zo is er nog zat ruimte om dingen te algemeniseren, te diffrentieren, te refactoren en te optimaliseren.
Dat denken wij soms op het werk ook tot we er aan willen beginnen er de baas met nieuwe ideen afkomt waardoor het telkens wordt uitgesteld en uitgesteld. Het is niet altijd haalbaar om zomaar even te gaan opsplitsen als er andere onderdelen worden door ontwikkeld.
Laat dat nu exact het verschil zijn tussen commerciele software en OSS, overal waar ik gewerkt heb kom je de situatie tegen die jij beschrijft, terwijl OSS projecten om de haverklap op de schop gaan en worden herschreven of gerefactored tot iets beters. Er staan immers geen klanten in de nek te hijgen van de vrijwilliger die vindt dat hij of zij het beter kan dan wat er al was.

Mijn ervaring is dan ook echt dat de commerciele code die ik onder ogen heb gehad kwalitatief bagger is (natuurlijk vooral die van anderen :+) vergeleken met de OSS waar ik ook genoeg van gezien heb.
Is toch de normaalste zaak. Als je een persoonlijk product ooit bent beginnen maken en daarna moet het voor de hele wereld werken, dan gaat het zijn doel voorbij en krijg je een groter pakket. Je hebt nog altijd de optie om het klein te houden, dus het moet geen probleem zijn.
Daarom is de trend nu juist naar modules (en user-space) waarvan het meest extreme voorbeeld de micro-kernel is. Linux heeft echter veel aanhangers gekregen terwijl dat oorspronkelijk niet de bedoeling was. Die optie om het klein te houden is er daarom niet meer.

Uitgaande van een beperkte usergroep en hardware ondersteuning had in de hele flamewar/discussie destijds tussen Torvalds en Tanenbaum, de eerste wel gelijk, echter met een steeds breder waaiend hardware-spectrum glijd de waarheid steeds verder naar Tanenbaums standpunt. Althans dat is mijn mening.

Strict genomen is Linux meer geschikt voor routers, mid's, telefoons, smartbooks en dergelijke als voor een desktop systeem. Voor de laatste zijn Haiku, Darwin en Minix, DragonflyBSD (om even in de FOSS wereld te blijven) en BeOS geschikter.

Uitgaande van "de markt heeft gelijk" of "het volk (de massa) heeft gelijk", die heeft Linux gekozen* (naast Windows en OS-X) en ongeacht of Linux technisch het meest geschikt is voor deze grote groep gebruikers en (vooral) hardware, zal men deze op de gebruikers en de gebruikte hardware moeten aanpassen.

In ieder geval is er een (langzaam) groeiende groep gebruikers die de voorkeur geeft aan een gratis en vrij besturingssysteem boven een closed-source betaalde zoals Windows of Mac OS-X. Op dit moment ligt in die wereld de focus op Linux in diverse smaken (distributies) maar dat kan veranderen. Haiku, Minix, DragonflyBSD en Darwin verdienen ook meer aandacht maar de meeste mensen zijn eerder trendvolgers of volgen die weer.

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