Opensource is niet de toekomst

[anoniem]

Nog een voorbeeldje inzake de snelhied van OSS-ontwikkeling: Ons team heeft over de vertaling van KDE2 ongeveer 5 maanden gedaan. Best snel vond ik Een ZA-team heeft over de vertaling van KDE 2.2 (die overigens 50% groter is dan kde2 qua strings) 1 maand gedaan. Verschil? het ZA-team is een bedrijf die full time aan de kdelocalisatie werken, wij zijn vrijwilligers die in de avonduurtjes beetje bij beetje vertalen. Overeenkomst? Beide valt onder OSS-ontwikkeling. max

[anoniem]

Het is ook maar net wat je de toekomst vindt: * zeg je OpenSource is een professioneel uitgangspunt voor software dan zeg ik ook nee. Wat Max zei klopt wel, een team vrijwilligers of een professioneel team werken allebei aan een open-source project, maar tijd is in dit geval misschien wel het enige verschil, maar over kwaliteit is nog nix gesproken. Dat elke hobbyist zomaar mee kan werken aan elk stukje open-source code draagt niet altijd bij tot kwaliteit. Vaak slordig versiebeheer, instabiele code blablabla.... * Dat wil niet zeggen dat het niet leuk is om er wat aan te doen. Ik ben ook zeer geinteresseerd i de open source development en ik wil er met mijn stage iets mee doen, want het is gewoon heel leuk om ermee te werken en je steentje bij te dragen. en zijn ook hele goede voorbeelden, zoals Apache die wel een succes geworden zijn, maar opensource is niet de garantie voor Succes en professionele software GreetzZzz

[anoniem]

Commerciele software is trouwens ook geen garantie, ik ken genoeg commerciele software/shareware die totaal nutteloos zijn. Eigenlijk is niks in de wereld een garantie. 100% garantie bestaat niet.

[anoniem]

[quote:ec0539cd4c]Commerciele software is trouwens ook geen garantie, ik ken genoeg commerciele software/shareware die totaal nutteloos zijn. [/quote:ec0539cd4c] Dat zei ik ook niet, maar dat klopt wel, oerigens is de kans daarop bij opensource wel groter denk ik. [quote:ec0539cd4c]Eigenlijk is niks in de wereld een garantie. 100% garantie bestaat niet. [/quote:ec0539cd4c] Klopt!!! GreetzZzz

[anoniem]

Waar baseer je de stelling dat OpenSource vaker nutteloos is op?? Waar ik het wel met je eens ben is dat OpenSource-bomen niet naar de hemel groeien. Toen de Linux-hype begon dacht men al gauw dat, wanneer je iets onder een OSS-licentie uitbracht er een grote groep hoog-gekwalificeerde ontwikkelaars zou opstaan die de software tot ongekende hoge kwaliteit zouden optillen. Das niet waar gebleken, OSS is niet een garantie dat er meer ontwikkelaars worden aangetrokken, en is ook geen garantie dat de kwaliteit uitmuntend is. Maar wat wel een voordeel is, als een applicatie slecht gebouwd is, en je hebt het nodig: je kunt het zelf veranderen!! Weer een praktijkvoorbeeldje: Deze week nog werd ik benaderd door een SuSE-gebruiker die aanmerkingen had op de vertaling van een applicatie. Deze applicatie is niet door ons team vertaald. Maar dat was geen ramp, door even het juiste bestand uit de broncode te lichten, vervolgens via KBabel te verbeteren en met een enkel commando te compileren kon ik een verbeterde versie van het betreffende mo-bestand naar de gebruiker sturen. Deze zet het op de juiste plaats in /opt/kde2, en voila de fout is hersteld, zonder dat de auteur van de applicatie/vertaling uberhaupt in beeld is geweest. In een closed source situatie moet je in zo'n geval de auteur van de applicatie benaderen (als je die kunt vinden, bij deze applicatie viel dat tegen..), en moet je vervolgens op de volgende update wachten voordat je wensen vervuld worden, tenzij de fout ernstig genoeg is om een patch te rechtvaardigen Max

[anoniem]

Even reageren over dat Linux' jaren 70 technologie niet opkan tegen BeOS. Men is bezig om een BeOS kloon te maken bovenop Linux (BlueOS): http://www.osnews.com/story.php?news_id=215 En het is gebleken dat Linux (met de preemtive patch) en XFree86 *wel* net zo snel kan zijn als BeOS. Sterker nog, sommige dingen in BlueOS zijn dankzij de Linux kernel zelfs sneller dan BeOS (zie vraag 11).

[anoniem]

Ja NU zijn we opeens stil he. :wink:

[anoniem]

Volens mij is Daniel even weg :wink: max

[anoniem]

[quote:91b602ab46]Eigenlijk is niks in de wereld een garantie. 100% garantie bestaat niet.[/quote:91b602ab46] 100% garantie op het feit dat je ooit dood gaat. :grin:

[anoniem]

[quote:c6bef96f29] Op 01-03-2002 20:48, schreef RobertV: Even reageren over dat Linux' jaren 70 technologie niet opkan tegen BeOS. Men is bezig om een BeOS kloon te maken bovenop Linux (BlueOS): http://www.osnews.com/story.php?news_id=215 En het is gebleken dat Linux (met de preemtive patch) en XFree86 *wel* net zo snel kan zijn als BeOS. Sterker nog, sommige dingen in BlueOS zijn dankzij de Linux kernel zelfs sneller dan BeOS (zie vraag 11). [/quote:c6bef96f29] Ooit BeOS gedraait? Nee. Nou, waar heb je het dan over?

[anoniem]

[quote:5a2f4a67d7] Op 07-03-2002 10:20, schreef maximilaan: Volens mij is Daniel even weg :wink: max [/quote:5a2f4a67d7] danieldk is de laatste tijd 0% idle, dus ik heb niet zoveel tijd meer om hier te komen jammer genoeg...

[anoniem]

[quote:53af117ef6] Op 07-03-2002 12:40, schreef danieldk: Ooit BeOS gedraait? Nee. Nou, waar heb je het dan over? [/quote:53af117ef6] Je bedoelt waar de BlueOS developers het over hebben. [b:53af117ef6]Zij[/b:53af117ef6] hebben [b:53af117ef6]wel[/b:53af117ef6] BeOS gebruikt, die uitspraken zijn dan ook van [b:53af117ef6]hen[/b:53af117ef6], niet van mij.

[anoniem]

[quote:e94d7c0833] Op 07-03-2002 20:18, schreef RobertV: [quote:e94d7c0833] Op 07-03-2002 12:40, schreef danieldk: Ooit BeOS gedraait? Nee. Nou, waar heb je het dan over? [/quote:e94d7c0833] Je bedoelt waar de BlueOS developers het over hebben. [b:e94d7c0833]Zij[/b:e94d7c0833] hebben [b:e94d7c0833]wel[/b:e94d7c0833] BeOS gebruikt, die uitspraken zijn dan ook van [b:e94d7c0833]hen[/b:e94d7c0833], niet van mij. [/quote:e94d7c0833] Serieus, zien die BlueOS mensen eruit alsof ze een microkernel kunnen schrijven? Daarom gebruiken ze Linux. IMHO doet OpenBeOS veel beter werk.

[anoniem]

Hij blijft op die microkernel hameren :smile: Max

[anoniem]

[quote:efffabc632] Op 08-03-2002 22:13, schreef maximilaan: Hij blijft op die microkernel hameren :smile: [/quote:efffabc632] Heb je die website al eens gelezen?

[anoniem]

Ben wat warrig dit weekeinde, maar welke site bedoel je? Ik heb redelijk wat gelezen over microkernels vs monolitische kernels, zoals Linux ze heeft, en in theorie zou je voor micro gaan, maar de mono-fans geven vaak vele praktijkvoorbeelden waarbij micro toch niet het antwoord blijkt te zijn. Max

[anoniem]

[quote:e5f5624e84] Op 10-03-2002 0:07, schreef maximilaan: Ben wat warrig dit weekeinde, maar welke site bedoel je? Ik heb redelijk wat gelezen over microkernels vs monolitische kernels, zoals Linux ze heeft, en in theorie zou je voor micro gaan, maar de mono-fans geven vaak vele praktijkvoorbeelden waarbij micro toch niet het antwoord blijkt te zijn. [/quote:e5f5624e84] Ja, in 1991. Men wijst vrijwel altijd terug op de Torvalds vs. Tanenbaum discussie of op Mach of Chorus. Maar kijken we naar moderne microkernels, zoals die van BeOS of QNX dan zijn de voordelen duidelijk.

[anoniem]

Hmm, in 1991 had ik nog geen pc :smile: Ik doel op documentatie van afgelopen jaar.. Max

[anoniem]

Hier een stukkie discussie over Darwin en MacOS X:  [quote:22dc0f0794] 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:22dc0f0794] 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

[anoniem]

Andere statement: [quote:4f5fbd1055] microkernel (also abbreviated µK or uK) is an approach to operating systems design by which the functionality of the system is moved out of the traditional "kernel", into a set of "servers" that communicate through a "minimal" kernel, leaving as little as possible in "system space" and as much as possible in "user space". <LI> microkernels were invented as a reaction to traditional "monolithic" kernel design, whereby all system functionality was put in a one static program running in a special "system" mode of the processor. The rationale was that it would bring modularity in the system architecture, which would entail a cleaner system, easier to debug or dynamically modify, customizable to users' needs, and more performant. <LI> The prototypical Microkernels is Mach, originally developed at CMU, and used in some free and some proprietary BSD Unix derivatives, as well as in the heart of GNU HURD. MICROS~1 Windows NT is said to originally have been a microkernel design, although one that with time and for performance reasons was overinflated into a big piece of bloatware that leaves monolithic kernels far behind in terms of size. Latest evolutions in microkernel design led to things like "nano-kernel" L4, or "exokernel" Xok. <LI> At one time in the late 1980's and early 1990's, microkernels were the craze in official academic and industrial OS design, and anyone not submitting to the dogma was regarded as ridiculous. But microkernels failed to deliver their too many promises in terms of either modularity (see Mach servers vs Linux modules) cleanliness (see Mach horror), ease of debugging (see HURD problems), ease of dynamic modification (also see HURD vs Linux), customizability (see Linux vs Mach-based projects), or performance (Linux vs MkLinux, NetBSD vs Lites). This led some microkernel people to compromise by having "single-servers" that have all the functionality, and pushing them inside "micro"kernel-space (WindowsNT, hacked MkLinux), yielding a usual monolithic kernel under another name and with a contorted design. Other microkernel people instead took an even more radical view of stripping the kernel from everything but the most basic system-dependent interrupt handling and messaging capabilities, and having the rest of system functionality in libraries of system or user code, which again is not very different from monolithic systems like Linux that have well-delimited architecture-specific parts separated from the main body of portable code. With the rise of Linux, and the possibility to benchmark monolithic versus microkernel variants thereof, as well as the possibility to compare kernel development in various open monolithic and microkernel systems. people were forced to acknowledge the practical superiority of "monolithic" design according to all testable criteria. Nowadays, microkernel is still the "official" way to design an OS, although you wont be laughed at when you show your monolithic kernel anymore. But as far as we know, no one in the academic world dared raise any theoretical criticism of the very concept of microkernel. Here is our take at it.[/quote:4f5fbd1055] Ook uit deze tekst blijkt dat micro-os in theorie sneller en flexibeler zijn, maar in werkelijkheid veel groter en trager dan een monolithische kernel. Veel snelle microkernels zijn dusdanig gewijzigd dat ze eigenlijk geen microkernels genoemd kunnen worden. Daarnaast ken ik enkele documentatie die de protabiliteit van microkernels bediscusseren. Zij stellen dat een microkernel die protable is, flink aan performance moet inboeten.. Max