Opensource is niet de toekomst

[anoniem]

[quote:dc915f22ea] Op 10-03-2002 11:28, schreef maximilaan: Hier een stukkie discussie over Darwin en MacOS X: [quote:dc915f22ea] Re: The values of Mach prev next From: John H=?iso-8859-1?q?=F6?=rnkvist <john@toastedmarshmallow.com> Date: 2001-02-17 15:32:43 Subject: Re: The values of Mach > This may be considered off-topic, and if so, please let me know where best > to ask this question. I also don't intend to post flame-bait, but I am > compelled to ask this question. > > When I have mentioned that Darwin/OSX uses the Mach kernel, some of my > colleagues snicker and say "Mach is slow". They insist that Mach is a > "failed" experiment, that its micro-kernel model is inherently slow, and > will never be as fast as a monolithic kernel like Linux. Some of my > colleagues are graduates of CMU (the birthplace of Mach) and claim to have > intimate knowledge of this as an 'undeniable fact'. > > I know Apple chose Mach for a lot of reasons that aren't necessarily driven > by absolute speed. Is there anything I can say in response to the concerns? > I remember reading early on in the threads that the newer versions of Mach > have been improved in this regard compared to previous versions. Is it a > significant issue? What distinguishes a true microkernel from a traditional monolithic kernel is that it has a very narrow interface -- it does nothing that can be done in other parts of the system. On top of the microkernel you can build servers that provide more convenient interfaces. The advantage of this organization is that the microkernel only has to implement the absolute essentials, which allows it to be a small and easily understood piece of code. Further, the servers can run as normal user processes, so when they crash, they do not crash the machine. However, switching between servers running as processes in user mode and the kernel, which runs in supervisor mode, takes time. This makes it difficult to get good performance from a microkernel, and often the servers are therefore run in supervisor mode, or exotic optimization techniques are used. Advocates of monolithic kernels -- Linus Torvalds comes to mind -- often claim that to get decent performance from a microkernel, you end up making it more complex than a monolithic kernel, and that with a microkernel, you have to solve a small number of very difficult problems, rather than a large number of very simple problems. A microkernel that is intertwined with a server layer, such as earlier versions of Mach, is often called a message passing kernel, in order to distinguish it from real microkernels and completely monolithic kernels. The original CMU version of Mach 3 has a very bad reputation for performance. Work done at University of Utah improved the performance substantially --- which wasn't very surprising; the goal of that work was to make Mach 3 a usable kernel. The OSF derived kernel that Apple uses has the performance optimizations from U of U, and more besides. In addition, Apple has opted to move servers into kernel space, which makes communication much cheaper and removes the context switch penalties. The disadvantage that comes with this decision is that the system is somewhat more likely to crash. However, Apple's argument has been that (for a desktop system) there is little point in keeping the system running in a state where it has to restart all user services anyway. (For a server supporting several users with different operating system "personalities", which I believe they envisioned at CMU, crashing one personality and keeping the rest running is a very nice feature however, I doubt a! nyone is interested in using such a system these days.) In essence, Apple has thrown away most of the much touted user benefits of the micro kernel --- the driver model is the main exception, I think --- in exchange for better performance, but are trying to leverage the engineering benefits of a micro kernel design. [/quote:dc915f22ea] Wat ik uit dergelijke discussie concludeer is dat de microkernel op zich beter is dan een monolithische kernel, maar dat het grootste nadeel de slechte performance is. Veel Microkernelsystemen die wel een goede performance hebben, zijn in essentie geen pure microkernels meer. Max [/quote:dc915f22ea] Je kunt met een hoop texten komen, ten eerste kun je Darwin niet als voorbeeld voor microkernels nemen, omdat het a. Mach is en b. een single server microkernel OS is. Op het punt van snelheid wil ik graag een aantal opmerkingen maken; ten eerste is het threading en multiprocessing van user threads veel eenvoudiger en veiliger dan kernel threads. Omdat in een microkernel alle subsystemen in userspace draaien zijn de netwerkstack, filesystem server, etc. veel eenvoudiger/schoner te multithreaden en eenvoudiger parallel te verwerken (denk aan SMP machines), omdat je bij kernel threading rekening moet houden met I/O problemen. Massieve threading van userspace onderdelen resulteert in een snellere reactiesnelheid omdat je eenvoudiger threads preemptive kunt maken. In de praktijk kun je dit zien aan de uitermate goede SMP ondersteuning van bijvoorbeeld BeOS. Het klopt dat in sommige gevallen een contextswitch erg "expensive" is vergeleken met een monolithic kernel. Maar dan komt de vraag of we altijd snelheid moeten verkiezen boven de voordelen van iets minders snelheid. De voordelen zijn duidelijk, de TCB (Trusted Computing Base) van microkernels is veel kleiner (soms slechts enkele kilobytes), dit maakt een microkernel veel toleranter voor fouten. Een probleem in de netwerks stack gooit in het geval van een monolithic kernel vaak de hele kernel plat, bij een microkernel gaat alleen een server plat die binnen een fractie van een seconde weer hersteld opnieuw gestart is. Denk aan de consequenties van kritieke systemen in bijvoorbeeld de ruimtevaart of de industrie. Beide ontwerpen hebben hun voordelen en er zijn zeker ook goede monolithic kernels. Het hangt vooral van de toepassing af. Op een desktop systeem waarop de "penalty" op een context switch niet zo zwaar telt kan een microkernel een veel betere oplossing zijn. Ironisch genoeg zijn de microkernel desktop operating systems (QNX RTOS, BeOS) sneller dan OSes met monolithic kernels, omdat vaak de modulariteit voortgezet wordt in elk facet van het systeem. Het is zeker niet zo dat er 1 grote winnaar is, maar blind achter het geblaat van Linus aanlopen lijkt mij zeker niet gepast.

[anoniem]

Beide systemen hebben hun voors ten tegens. Maar de stelling dat Linux verouderde architectuur is, en daarom automatisch slechter dan op microkernel gebaseerde systemen als BeOS, is imho wat kort door de bocht. De microkernel heeft zeker voordelen tov een monolitische kernel, maar is niet zaligmaken in elke situatie. Dat een systeem als BeOS snel is staat los van het feit of ze een microkernel gebruiken of niet. Veel vertraging in Linux heeft meer te maken met de portability, flessehalzen in gcc, en het feit dat de code niet van alle optimalisaties van bijv. de processor gebruik maakt. Allemaal issue's die opgelost dienen te worden, maar die los staan van 'verouderde architectuur' Max Max

[anoniem]

[quote:c77418cfd3] Op 11-03-2002 1:12, schreef maximilaan: Dat een systeem als BeOS snel is staat los van het feit of ze een microkernel gebruiken of niet. [/quote:c77418cfd3] Een "threaded to the bone" microkernel set wel de toon voor de rest van het systeem. [quote:c77418cfd3] Veel vertraging in Linux heeft meer te maken met de portability, flessehalzen in gcc, en het feit dat de code niet van alle optimalisaties van bijv. de processor gebruik maakt. [/quote:c77418cfd3] Leuk dat je dit soort dingen noemt, want BeOS gebruikt GCC en is portable (AT&T Hobbit->BeBox->PowerPC->i386), dus de punten die je noemt vind ik niet echt sterk. Bovendien is het vaak zo dat modulariteit aan de basis doorgezet wordt tot elk facet van het systeem.

[anoniem]

Is BeOS echt zo snel? En dan bedoel ik niet hoe de GUI altijd reageert (volgens mij komt het omdat de GUI toolkit in BeOS automatisch zwaar gebruik maakt van multithreading), maar andere dingen zoals de snelheid van malloc(), fork() of hoe snel ie geheugen swapt enzo. Zijn er tests waarin je BeOS met cijfers vergelijkt met andere besturingssystemen?

[anoniem]

Even over dat Linux geen microkernel en dus slecht is: GNU Hurd is bijna klaar. Hurd is, net als Darwin, een microkernel gebasseerd op Mach, maar is open source.

[anoniem]

[quote:062826cc24] Op 12-03-2002 16:49, schreef RobertV: Even over dat Linux geen microkernel en dus slecht is: GNU Hurd is bijna klaar. Hurd is, net als Darwin, een microkernel gebasseerd op Mach, maar is open source. [/quote:062826cc24] Maar er is een groot verschil dat imho erg positief is; Darwin is Mach met een single-server 4.4BSD. Hurd is GNU Mach met Hurd servers, dus elk component, networking, filesystem ondersteuning zijn in andere servers geplaatst. Bedenk hoe cool dat is als je een server draait en je wilt, laten we zeggen, een nieuwere network stack installeren, dan gooi je alleen die plat en start de nieuwe versie en je server is met slechts een fractie van een seconde downtime geupgraded. In principe hoef je volgens mij alleen te rebooten als je de microkernel wilt upgraden voor nieuwe hardwareondersteuning en voor nieuwe hardware moet je een server zowiezo uitzetten. GNU Hurd lijkt me dus erg interessant (heb het al eens gedraait), vooral om een server erop over te switchen...

[anoniem]

[quote:9d9e43cee0] Op 11-03-2002 13:35, schreef danieldk: [quote:9d9e43cee0] Op 11-03-2002 1:12, schreef maximilaan: Dat een systeem als BeOS snel is staat los van het feit of ze een microkernel gebruiken of niet. [/quote:9d9e43cee0] Een "threaded to the bone" microkernel set wel de toon voor de rest van het systeem. [/quote:9d9e43cee0] Niet mee eens, als de onderliggende structuur threaded to the bone is, maar de bovenliggende applicaties niet, dan is het systeem traag.. [quote:9d9e43cee0] [quote:9d9e43cee0] Veel vertraging in Linux heeft meer te maken met de portability, flessehalzen in gcc, en het feit dat de code niet van alle optimalisaties van bijv. de processor gebruik maakt. [/quote:9d9e43cee0] Leuk dat je dit soort dingen noemt, want BeOS gebruikt GCC en is portable (AT&T Hobbit->BeBox->PowerPC->i386), dus de punten die je noemt vind ik niet echt sterk. Bovendien is het vaak zo dat modulariteit aan de basis doorgezet wordt tot elk facet van het systeem. [/quote:9d9e43cee0] Maw als Intel haar compiler voor BeOS beschikbaar maakt, dan is dat nog sneller. Bij Linux werden versnellingen tot 300% gemeld. Wat Gcc betreft: developer-versies in combinatie met kde3 leverden ook een 500% versnelling op. Dat is helaas nog steeds niet stabiel, dus laat die versnelling nog op zich wachten.. Wat portabiliteit betreft: het feit dat een systeem op verschillende platformen draait wil niet zeggen dat het portable is. Kijk naar Linux: de eerste port was naar de alpha-processor, terwijl jaren daarvoor ook al linux-versies voor oa Atari en Commodore-pc's beschikbaar waren. Alleen waren dat geen ports in de essentie van de naam, het systeem is simpelweg herschreven voor de architectuur. Ader voorbeeld: MS Office draait op Windows en MacOS. Maar er is geen sprake van een port naar de Mac, MS Office voor de mac is een aparte ontwikkeling.. Verder staat buiten kijf dat BeOS een machtsysteem is. Het is erg jammer dat het niet aangslagen is, maar dat zie je vaker bij technologie, men gaat vaak (altijd?) niet voor de beste innovaties. Maar of dat dankzij de microkernel is? Neen, wat mij betreft niet. De bovenliggende architectuur is heel goed doordacht opgezet en superieur wat betreft het aanspreken van de processor en de schijven, en de verdeling ervan. Bij Linux of windows staat het systeem bijna stil als een applicatie flink op de schijf aan het lezen/schrijven is. Dat heb je in BeOS niet. Ook de processortijd wordt veel eerlijker verdeeld om dat de aangeboden code in kleinere stukjes is opgedeeld. Dat laatste staat of valt natuurlijk bij goedgeschreven software om op de BeOs te draaien. Ik vraag me af of bloatware op BeOS sneller draait als op Linux. Max ----------------------------------------- AFJ // /n./ Written-only abbreviation for "April Fool's Joke". Elaborate April Fool's hoaxes are a long-established tradition on Usenet and Internet; see kremvax for an example. In fact, April Fool's Day is the only seasonal holiday consistently marked by customary observances on Internet and other hacker networks.

[anoniem]

[i:20861d5840]"Ik vraag me af of bloatware op BeOS sneller draait als op Linux."[/i:20861d5840] Vast wel. De meeste bloatware gebruiken vooral veel geheugen. Daardoor gaat je OS steeds swappen. Als BeOS sneller is in swappen dan draait bloatware ook sneller. Maar hoe komt het dat BeOS sneller is in swappen of grote bestanden kopieren? Linux staat bekend als een goede server OS, dus je zou verwachten dat vooral swappen erg goed moet zijn...

[anoniem]

Wat ik van het lezen/schrijven van beOS heb begrepen, is dat er meerdere taken tegelijk kunnen worden uitgevoerd (vandaar dat je meerdere video streams kunt draaien zonder hapering) terwijl NT en Linux 1 lees/schrijfactie per keer toe staan. Wat ik me afvraag is dat wanneer een bloatware-applicatie de code niet in kleine stukjes aanbiedt, of BeOS dan nog steeds snel is, of begint te vertragen... Max

[anoniem]

[quote:280558ef8e] Op 17-03-2002 10:07, schreef maximilaan: Wat ik van het lezen/schrijven van beOS heb begrepen, is dat er meerdere taken tegelijk kunnen worden uitgevoerd (vandaar dat je meerdere video streams kunt draaien zonder hapering) terwijl NT en Linux 1 lees/schrijfactie per keer toe staan. [/quote:280558ef8e] Meer door goede preempting waardoor de decoder threads bijna realtime draaien. Op het punt van "threaded to the bone" geef ik je geen gelijk; als de kernel en daarop de API volledig multithreaded zijn gebeurt dit ook min of meer automatisch in programma's omdat de API het forceert.

[anoniem]

[quote:3d1868313e] Op 17-03-2002 10:07, schreef maximilaan: Wat ik van het lezen/schrijven van beOS heb begrepen, is dat er meerdere taken tegelijk kunnen worden uitgevoerd (vandaar dat je meerdere video streams kunt draaien zonder hapering) terwijl NT en Linux 1 lees/schrijfactie per keer toe staan.[/quote:3d1868313e] Ik kan ook 5 video streams tegelijk in Linux kijken zonder hapering... Maar ik dacht dat de Linux kernel preemptive wordt gemultitaskt door die preemptive patch. Maar tot nu toe merk ik er niet veel van (zeker tijdens het verplaatsen van grote bestanden). Hoe zit dat eigenlijk?

[anoniem]

[quote:3ca3d66d7b] Meer door goede preempting waardoor de decoder threads bijna realtime draaien.[/quote:3ca3d66d7b] Ik heb me dit altijd afgevraagd: hoe kun je nou in hemelsnaam een 1200 kbit/sec MPEG 4 stream in realtime bekijken zonder framedrops op een Pentium 166?

[anoniem]

[quote:09a44751b2] Op 17-03-2002 22:12, schreef RobertV: Maar ik dacht dat de Linux kernel preemptive wordt gemultitaskt door die preemptive patch. Maar tot nu toe merk ik er niet veel van (zeker tijdens het verplaatsen van grote bestanden). Hoe zit dat eigenlijk? [/quote:09a44751b2] Hmmm, vaag, ik wel. Heb je'm wel aangezet in de kernelconfig?

[anoniem]

Jawel. Ook de harde schijf met hdparm getuned.