Re: [SLUG] Re: Aptitude command to TOTALLY remove KDE
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, Sep 03, 2005 at 08:28:55PM +1000, Sam Couter wrote: telford [EMAIL PROTECTED] wrote: If you do not want to go the whole hog and run a fully isolated virtual machine then you MIGHT be able to recover SOME of the time but think about a situation where you have swap-to-disk implemented as a user space task and it crashes. Can you recover the situation? All memory on the entire system is now in an untrustworthy state so you must find a way of cleanly restarting every task -- most people call this a reboot. The point of a microkernel is that for the swap to become corrupted, the swap service must be buggy. It doesn't matter to the swap system how buggy the graphics or network drivers are, for example. So if your graphics drivers crash out with a bad pointer was the error in the graphics driver or was the memory corrupted by a bug in the swap service? Different tasks can even be using different virtual memory systems, so if one crashes then processes using the others are completely unaffected. Except when those tasks interface with hardware and the hardware can do DMA which includes storage devices, network cards, sound and graphics drivers. Then there's anything that can access the i2c bus (and thus do things like reprogram your CPU clock frequency), anything that can reprogram interrupt delivery... Then there's all the various bridge machinations such as opening an AGPGART window. Yes, you do get memory protection and yes memory protection is a good start but it certainly is no guarantee of safety. What I'm saying here is that while a microkernel is a bit safer than a monolithic kernel... the microkernel promises a lot more than it can deliver. And because microkernel designs have been tried (e.g. MS-Windows NT) and so far they have proven both slower and less stable. NT was never released as a microkernel, although that was the original plan. It has only ever pretended. NT's instability is mostly due to shoddy graphics and other drivers being loaded in kernel memory for performance reasons. In other words, the instability is due to *failing* to really be a microkernel. QNX was the first microkernel to demonstrate decent performance, and that came at the cost of flexibility and performance. More recent research has lead to more portable and flexible microkernels with high performace such as L4. I think that's a bit of an unfair comparison because QNX never had the same scope of applications that MS-Windows attempted to handle. QNX was written by a very small team without even attempting to cope with things like vendor-supplied Direct X drivers and the like. When Linux first came into existence, microkernels were still just a neat idea with a few big problems and were a long way from being proven. And now microkernels are a little bit closer to being proven with a long way to go... and still only a small hint that they might be a little bit better than what we already have. The high cost of context switches and switching supervisor mode (ring zero) on and off on x86 makes things difficult for any microkernel. Most of those problems are solved with SPARC machines which are easy enough to get hold of. I notice that Sun never tried leaving their basic BSD kernel design even though they designed the SPARC chips with fast context switch in mind. Besides all this, the real problem with current Linux kernels is not that developers have problems tracking down bugs, or that they find the bugs are difficult to fix. The real problem is that cutting-edge kernels don't get tested enough to even detect the bugs that do exist. So many people are perfectly happy with older kernels that even though the number of Linux users is growing, the number of people testing new kernels is getting smaller. Changing to a microkernel isn't going to fix this either. - Tel -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) iQIVAwUBQxzDfcfOVl0KFTApAQJlkw//Vv70gdv7lD17cxQ88tEKftktxSyd/59o 6EAqs4FNytZH/NSGB+UkcRQT8n8A/G1FV2bWbC+hHsk5QAYWQoAgrLdWMgNVfMkd 6zI0kAjd0l/85V0YyoNg5fZ+2nYjba9dEoXHtAtFWxNuA9jBt9SqCzc1L2146z1t asiu5ZtsHsll4Bq5i9JCpcOpCxJ4yIMf1EsITlF0MBjeZCjsLu06Oql1FU31rRed NzXnLvTHf2ozBY2AI23QfzVKrDxx4CJiFBXXedJUv0DzAEH/B6/DZ/ZOQB70ba+w P6G2SSKDyIM+5esyZaXyPZrAv15OCitCkYFyKXxi8YUEgGvPuenDeI2e/6TJSbk8 RuUs2hXPTkcKaHbtNa4+jyrb0nrsMxS10hBgOXHHg/a08l9PEV359ZWuHELhOfIz 9dJutXryKS7etncBlRwKyRaBLq9e9t7rMd202G3fSRUJPYqs3pPqsRM/fttk1+5+ 6CHMGJkthgTT5Le2TLTGynSyqSHGz0PnRPeNG4mBphHEd0kd2reIPpxulsDLOBjE 87qpn7I9//PCkKPM25j70pa6qGEwtOXh0UyvQsCNvgCuVlPaV0PWBSBF6M069n4u HZDdNMaei2pyf9GN1MZaEFZ8SNaSfN60xJe+L8uO9AjKg0G4Em8vTLhmhVzowk0S jHtGkPmpIhw= =IISq -END PGP SIGNATURE- -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Re: Aptitude command to TOTALLY remove KDE
telford [EMAIL PROTECTED] wrote: If you do not want to go the whole hog and run a fully isolated virtual machine then you MIGHT be able to recover SOME of the time but think about a situation where you have swap-to-disk implemented as a user space task and it crashes. Can you recover the situation? All memory on the entire system is now in an untrustworthy state so you must find a way of cleanly restarting every task -- most people call this a reboot. The point of a microkernel is that for the swap to become corrupted, the swap service must be buggy. It doesn't matter to the swap system how buggy the graphics or network drivers are, for example. Different tasks can even be using different virtual memory systems, so if one crashes then processes using the others are completely unaffected. And because microkernel designs have been tried (e.g. MS-Windows NT) and so far they have proven both slower and less stable. NT was never released as a microkernel, although that was the original plan. It has only ever pretended. NT's instability is mostly due to shoddy graphics and other drivers being loaded in kernel memory for performance reasons. In other words, the instability is due to *failing* to really be a microkernel. QNX was the first microkernel to demonstrate decent performance, and that came at the cost of flexibility and performance. More recent research has lead to more portable and flexible microkernels with high performace such as L4. When Linux first came into existence, microkernels were still just a neat idea with a few big problems and were a long way from being proven. The high cost of context switches and switching supervisor mode (ring zero) on and off on x86 makes things difficult for any microkernel. -- Sam Eddie Couter | mailto:[EMAIL PROTECTED] Debian Developer| mailto:[EMAIL PROTECTED] | jabber:[EMAIL PROTECTED] OpenPGP fingerprint: A46B 9BB5 3148 7BEA 1F05 5BD5 8530 03AE DE89 C75C signature.asc Description: Digital signature -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Re: Aptitude command to TOTALLY remove KDE
On Thu, Sep 01, 2005 at 10:05:40PM +1000, QuantumG wrote: [EMAIL PROTECTED] wrote: Don't forget that a microkernel introduces communication overhead and usually some extra scheduling overhead which in turn eats into performance. I seem to remember there was a big squabble over who had the fastest webserver until Linux introduced a kernel level http accelerator which blew everyone else out of the water so badly that they first tried accusing the kernel developers of cheating and when that didn't work they just stopped playing that game, took the ball and went home. That's because it's a stupid idea. Really, it is. Really, Linux kicked everyone's backside. Really it did. Runs on the board. You may argue that the test was unrealistic in the first place, and many people would agree with you, but FOR BEATING THAT TEST it was a good strategy. We can put all the code of the entire system into one process and run it in ring-0 and we'll have the fastest system in the world! Setting every priority to mostest is a common strategy in Australian management circles but it doesn't actually make things get done faster. Again, going back to the webserver test, I'm sure all the other participants were also trying their hardest to get impressive results and they failed. Getting high performance out of a system is a bit more complex than you suggest. Until it crashes. Which is what the argument really boils down to. When something which is part of the kernel crashes, do you want it to take down the whole machine or do you want it to be contained and replacable? A web server should run in user space. End of story. Debatably a file system and a network stack should run in user space.. if you can get sufficient performance. If you want to trade off performance for the ability to recover from bugs then you can run user mode linux and you have got the whole kernel running in user space. Mind you, if your UML kernel is crashing regularly then you are going to have to fix the bug sooner or later, just restarting the job whenever it crashes is a bit crappy. If you do not want to go the whole hog and run a fully isolated virtual machine then you MIGHT be able to recover SOME of the time but think about a situation where you have swap-to-disk implemented as a user space task and it crashes. Can you recover the situation? All memory on the entire system is now in an untrustworthy state so you must find a way of cleanly restarting every task -- most people call this a reboot. Same problem if you have a filesystem task in user space and it crashes -- what state did it leave the drive in? Restarting the task might quite likely create further corruption. Again, if you have bugs at the filesystem level then there really is no other answer than finding the bugs and fixing them. Restarting the task won't actually solve anything. Being able to make an attempt at recovery is a bogus sense of security. I might also point out that some hardware devices can have nasty effects on the system when used wrongly (e.g. graphics cards with DMA) so restarting the task isn't going to help you if your PCI bus is locked solid by a bad graphics operation. A microkernel, by its very nature, can't be smart enough to protect you from these things and as far as I know there is no architecture where hardware devices can be guaranteed free of side effects. For a desktop operating system (which, remember, is what we were talking about) today's hardware is so much overkill that you could run different parts of the kernel on different parts of a local network and still get adequate performance. In which case, why the earlier comment about the importance of real time scheduling? I completely agree that a typical 2GHz Celeron can execute any desktop task (except starting Open Office) in shorter time than I can react to the results. I don't understand why scheduling is such an important issue when the system is almost completely unloaded almost all the time. The only things that I have noticed killing destop performance are: * Swapping. If you are running big-memory jobs and you don't have enough memory then linux will swap out anything it likes including chunks of your desktop code. This is not a scheduling issue. * Choking the disk bandwidth with a large backup operation or file transfer and trying to open desktop tasks at the same time. Linux has no priority system for jobs waiting on I/O bandwidth (and such a system is hard to implement because of the many layers of abstraction) * Intensive graphics that are beyond what your system can actually handle (in which case you can't win, get a better system) I would be curious to know exactly what real time requirements there are on desktop systems in terms of something that the user can detect. For most operations, 1/4 of a second would be the smallest time interval that a human can recognise so frankly I have trouble believing
[SLUG] Re: Aptitude command to TOTALLY remove KDE
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, Sep 01, 2005 at 08:48:41AM +1000, QuantumG wrote: I didn't say it was impossible. I said it was insane. Yes, you can hack real time scheduling into Linux. Yes, we do have a kernel threads and kernel re-entry in Linux. Does Linux have the best architecture for such features? Hell no. The result is a massive blob of complexity running at the highest privilege level on the system. As for whether or not a microkernel really made a lot of difference to BeOS.. it contributed a lot to the overall system architecture. It let the developers compartmentalize concerns into communicating servers more readily than a monolithic kernel does. Don't forget that a microkernel introduces communication overhead and usually some extra scheduling overhead which in turn eats into performance. I seem to remember there was a big squabble over who had the fastest webserver until Linux introduced a kernel level http accelerator which blew everyone else out of the water so badly that they first tried accusing the kernel developers of cheating and when that didn't work they just stopped playing that game, took the ball and went home. That just happens to be one example of a real time task that Linux turns out to be rather good at. However, other real time tasks (such as queuing live music streams) have proven a bit more of a challenge and to some extent the idea that real time means anything specific is in itself quite wrong because there are a great many different tasks that have special sorts of time constraints (e.g. low average latency, bounded worst case latency, consistent latency (low jitter), fast resume from a power-save state (power efficient), accurate and reliable internal timing sources, etc) and depending on the situation, different constraints will become critical. - Tel -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) iQIVAwUBQxbtMcfOVl0KFTApAQKoZhAAjecVbjt1TkSmg2caEmMCQNuShJxY8uPd /wC/ut9FYp3HqdZPJEFC15z27OkedkHV7zKorrCQs5vXzSgqckkXPkUeqK1yjUPd IROh7xtxkVr4TobCBR/sXI7ZinbcU66jPxvPAAibKAhYsbTk2/0AgptGNZK+Xylj G8o26E9228nTdnseUd8wqGWJxtCT1/1vcjHy9vdZuDexI/zQYC8HKiuShsf/92GX RvB+2pJnfgMK5VzmzKYuw77hxA62LHJamr5pt/9UwjsHeUZQ6Jklmw32RHxiCNDo +PC+7sqpSRiS1erSjsg32soS+NWVrpeHq3E0sLANDGzTPM+YRLGLep/XC30ay37H Fx/Q6SIKtJlxVguqA69BGWZSd7Oo5oitX5+P0EEBvAY+Thhr7Oxufmd1wvsVQrel 0lOXLus3zr1lkhZ5kUhuQBLNvvNCwuEVdn/kJ5D3V8fm90Ma2Yq76nxs/1Z5qee5 NiyLgHut8ODlpBa9mQJ/t1EnPhApTrX6jtbK6Bs4EbdZNdp0B2z+tJYrdO+qgpgH zeIvSL1sP7P4APhMUdzblzBeVzomJ2ughFoFjtEzXflkLrOsNm6k1zQtTX6TkQbc syKJySo9IrHmvUAqWsd+cmyy8OvTeTquNBR2xbHIqMrvR7Dbxz+Bmtoe3uQz3rcj wd3YlBB2hNw= =bZn5 -END PGP SIGNATURE- -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Re: Aptitude command to TOTALLY remove KDE
[EMAIL PROTECTED] wrote: Don't forget that a microkernel introduces communication overhead and usually some extra scheduling overhead which in turn eats into performance. I seem to remember there was a big squabble over who had the fastest webserver until Linux introduced a kernel level http accelerator which blew everyone else out of the water so badly that they first tried accusing the kernel developers of cheating and when that didn't work they just stopped playing that game, took the ball and went home. That's because it's a stupid idea. Really, it is. We can put all the code of the entire system into one process and run it in ring-0 and we'll have the fastest system in the world! Until it crashes. Which is what the argument really boils down to. When something which is part of the kernel crashes, do you want it to take down the whole machine or do you want it to be contained and replacable? A web server should run in user space. End of story. Debatably a file system and a network stack should run in user space.. if you can get sufficient performance. For a desktop operating system (which, remember, is what we were talking about) today's hardware is so much overkill that you could run different parts of the kernel on different parts of a local network and still get adequate performance. So why are we still running it in ring-0? Because that's the system we have today and it doesn't make sense to reinvent the wheel if it is working. But it does make sense to keep working on it and slowly migrate things out of ring-0 and into their own process space so we can get rock solid stability and the flexibility needed to implement and debug new things more safely. Trent -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
