<?xml version="1.0" encoding="utf-8" ?>
<rss version="2.0" xmlns:osnews="http://www.osnews.com/rss2#">
	<channel>
		<title>OSNews: </title>
		<link>http://www.osnews.com/story/15814/Introduction_to_TUD_OS</link>
		<description>Exploring the Future of Computing</description>
		<language>en-us</language>
		<copyright>Copyright 2001-2013, David Adams</copyright>
		<webMaster>adam+nospam@osnews.com</webMaster>
		<lastBuildDate>Sat, 25 May 2013 09:56:24 GMT</lastBuildDate>
		<image>
			<url>http://www.osnews.com/images/osnews.gif</url>
			<title>OSNews.com</title>
			<link>http://www.osnews.com</link>
		</image>
		<item>
			<title>Two things...</title>
			<link>http://www.osnews.com/thread?161819</link>
			<guid isPermaLink="true">http://www.osnews.com/thread?161819</guid>
			<description>which are often forgotten about microkernels...<br />
<br />
The first one is that in reality, you have to trust more than only the kernel. A bug in the disk driver can very well crash the whole system. Sure, it cannot overwrite data in other processes directly. But it doesn't have to - in fact, other processes *ask* the disk driver to transfer *their* data. Do these OSes check all data from the disk driver for integrity? And how do they make sure that data is written when the driver says so? I can continue the list of possible problems endlessly here.<br />
<br />
Lesson #1: Safety, security, stability and similar features are more than isolating processes against each other.<br />
<br />
The second issue is that all processes run in parallel. This mixes up the order of events during processing, very much like IP packets get reordered on their way to a remote computer. The results are nondeterministic, and thus unpredictable. The once-so-simple code has to be modified to make it possible to enforce a certain order in actions. This is in sharp contrast to the goals a microkernel tried to achieve: Lots of simple and maintainable modules, glued together to create a working whole.<br />
<br />
Lesson #2: If you couple modularity with concurrency, you are begging for problems.</description>
			<pubDate>Tue, 12 Sep 2006 23:10:00 GMT</pubDate>
			<author>donotreply@osnews.com (Morin)</author>
			<category>Comments</category>
		</item>

		<item>
			<title>TUD OS...oops</title>
			<link>http://www.osnews.com/thread?161822</link>
			<guid isPermaLink="true">http://www.osnews.com/thread?161822</guid>
			<description>I thought this article was about Windows.  Then I realized it wasn't about TURD but TUD.<br />
<br />
Silly Me.</description>
			<pubDate>Tue, 12 Sep 2006 23:13:00 GMT</pubDate>
			<author>donotreply@osnews.com (Gadget)</author>
			<category>Comments</category>
		</item>

		<item>
			<title>RE: Two things...</title>
			<link>http://www.osnews.com/thread?161848</link>
			<guid isPermaLink="true">http://www.osnews.com/thread?161848</guid>
			<description>I'm not rooting for or against microkernels, but here are my thoughts on your points:<br />
<br />
The first one is that in reality, you have to trust more than only the kernel. A bug in the disk driver can very well crash the whole system. Sure, it cannot overwrite data in other processes directly. But it doesn't have to - in fact, other processes *ask* the disk driver to transfer *their* data.<br />
<br />
Everyone should know that a microkernel does not itself ensure that code is trusted, or that code does not need to be trusted, or that flaws in code will have no serious impact. All that is ensured, is that memory and resources will be compartmentalized between drivers. However, some people do seem to (erroneously) imply that microkernels make the kinds of guarantees you described! But of course this aspect of microkernels, while having many benefits, is still a far cry from being a silver bullet.<br />
<br />
The second issue is that all processes run in parallel. This mixes up the order of events during processing . . .  The once-so-simple code has to be modified to make it possible to enforce a certain order in actions. This is in sharp contrast to the goals a microkernel tried to achieve: Lots of simple and maintainable modules, glued together to create a working whole.<br />
<br />
Once again, some people can be seen as implying that microkernel systems are dramatically simpler than monolithic systems, which is a misconception. What is mentioned above is indeed one of the major caveats in implementing a microkernel. However, there are solutions to this problem, that keep things relatively simple once implemented. The real problem is that its hard to avoid taking very significant performance penalties when solutions to synchronization issues are implemented. IIRC, the Hurd had this problem, and is trying to curtail such performance penalties by tailoring their system specifically for Intel x86 architectures.</description>
			<pubDate>Wed, 13 Sep 2006 01:02:00 GMT</pubDate>
			<author>donotreply@osnews.com (Frenetic)</author>
			<category>Comments</category>
		</item>

		<item>
			<title>RE[2]: Two things...</title>
			<link>http://www.osnews.com/thread?161931</link>
			<guid isPermaLink="true">http://www.osnews.com/thread?161931</guid>
			<description>Thanks for your reply. I should have said that these problems are not fatal, and they do not make use of a microkernel impossible or even impractical. One just has to be aware of them.</description>
			<pubDate>Wed, 13 Sep 2006 10:50:00 GMT</pubDate>
			<author>donotreply@osnews.com (Morin)</author>
			<category>Comments</category>
		</item>
	</channel>
</rss>
