Re:Yes. Microkernel technology died last millenium
on
Hurd: H2 CD Images
·
· Score: 1
You're just trying to get someone else to do your homework for you.
Feel free to believe so if that makes you happy. (Herregud for noen helvetes idioter der er rundt om her nå om dagen.)
You STILL haven't read any Intel documents, have you?
If you're referring to the Intel documents describing what the pure context switching costs (for some definition of "pure") in various application scenarios, I'm affraid the answer would be no. Give me a URL or an Order Number for these documents and I'll be happy to revoke my claim that these documents do not exist.
If you want to pretend you're at least kernel knowledgeable, you need to start there.
How brilliant. I would never have figured that I needed to actually read the processor specs before going about designing and implementing various kernels from scratch. Thank you very much. I must have been pretty lucky to get things right in the first place.
Re:Yes. Microkernel technology died last millenium
on
Hurd: H2 CD Images
·
· Score: 1
You didn't actually bother to read my previous post, did you?
Re:Yes. Microkernel technology died last millenium
on
Hurd: H2 CD Images
·
· Score: 1
Considering that the overhead in context switching, as well as task-level switching, has been published for every x86 CPU since the 286, would you please explain why all the academics missed this incredible flaw with microkernels? That's quite embarassing, if you ask me. All they had to do was to ask someone with a modicum of kernel experience.
Please show me the location where context switching and task switching overheads are published properly (and officially by Intel). Please also take into account the indirect overhead of cache flushes (TLB and Trace Cache), and the cost of reestablishing the cache working sets. Oh, and don't forget to include measurements for various typical application scenarios. Also make sure to include the costs using different context switching techinques. (Did you know that using the systenter/sysexit instructions saves you a few thousand cycles compared to software interrupts on a Pentium 4?)
Re:Yes. Microkernel technology died last millenium
on
Hurd: H2 CD Images
·
· Score: 1
Microkernels were a neat academic idea - except that the academics forgot (or didn't know about) the overhead in switching between General Protection Levels. Which is something that was obvious to most x86 kernel hackers from the start.
So, you being a representative of these "x86 kernel hackers" (I assume that you believe yourself to be one), would you be so kind as to enlighten us about what the overhead of context switching really is? Believe me, most academics working in the field has a pretty good idea of what's going on. I just find statements like yours completely hillarious, and a testament to the ignorance and stupidity of people who find Linux kernel hacking to be 1337.
I see virtually no point to fancy 3G technology and broadband phones. All I need to see in a mobile phone is the following:
- Good voice clarity - equivalent to wired when in better-than-marginal conditions.
- Good enough battery life to talk for at least 3 or so hours on a charge. LiIon batteries for no memory and good power density.
- Antennas that are either recessed or integrated to the body. Nokias do this well in current models. No protruding breakable dongles like the StarTAC.
- A phone that fits in my pocket.
- The ability to download phone numbers from my PC. But that's all the PIM functionality I want.
These all seems to be issues with the phone itself, and not so much with the technology behind the network. That said, voice quality definitely relies on the technology, but I've never found GSM to be any worse than wired. Battery and phone size also depends somewhat on the network technology as they might need more powerful and bigger transmitters sucking more power, but these issues are also addressed by phone and bettery technology.
And from the phone company, I want the following:
- Coverage almost anywhere. Digital, too. No more AMPS service anywhere.
- No roaming. At all. And no long distance if the carrier has a national footprint.
- Either free incoming or "caller pays" incoming, the way real telcos do it.
Seems like you need to move to somewhee out of the US. In Europe at least this is pretty much standard stuff. Roaming is of course an issue if you travel across borders and your provider has no network there. Coming around this is sort of hard unless you are using some big multinational provider. Then there's also the problem of nations having restrictions on who can build up a network in their country. But again, this is not a problem with the network technology per se. It's more of a political problem.
"Is This It", the real hype
on
This is IT?
·
· Score: 1
People call this hype? No way. The real hype came in the name of The Strokes' "Is This It", hit the European charts a couple of months back and the US ones some weeks later. Bleeding good band for being such a hype, though.
When I did my turn as a sysadm, we used a system called Store to do all the management for us. The system basically contained a directory for each packages/application. Each package had its own directory tree which was symlinked into the respective location of the store tree (usually "/store", but could also be "/usr/local" if you configured your system that way).
The directory tree in each package could also contain a mixture of different architectures so that one could share most of the package's files (e.g., man pages) among platforms and only keep separate files where needed (e.g., executables). The scheme allowed you to categorize the files into any granularity you wanted. You could for instance have one exeuctable for m68k, one optimized for Pentium4, another optimzed for 486, and a generic x86 one (if you had, say, a PentiumIII). The system made sure that the symlink which suited you best was used.
There were also, of course, possibilities to specify files only valid for certain OSes and OS revisions, and one could specify files which should be valid only within one certain domain, or on one certain host.
Another feature was the ability to keep multiple versions of the same application around, and mark the different versions as stable, release, beta, etc. This allowed you to specify hosts or domains which only should run stable software, which should be able to run beta software, and so on.
In addition to keeping multiple versions of the binaries around, the system also could keep multiple build frameworks around. The build framework could contain configurations for various OSes and platforms, and allowed applications to be more easily installed on various architectures.
Of course, there was also a package config file indicationg the name of the package, short info, dependencies, etc.
For distribution one could create a tree-like structure where the whole or a subset of the packages and binaries for the packages were automatically mirrored to hosts in the network. This allowed you to have most of the packages located on the servers while the clients which had only limited diskspace only had a limited set of packages (e.g., shells) installed locally.
There were also add-ons to automatically configure various environment variables on the hosts, configre mailcap/mime-type files, emacs configuration entries, info-file entries, etc.
The whole thing worked wonderfully (once you as a sysadmin learnt how to use it properly). It automatically propagated new applications throughout the system once you installed them and generally made life easier for the sysadmin. Installing software on new machines was also pretty painless. You just configured your new client system, fired up a single command, and all applications suitable for the system were installed and configured for you.
The unix system doesn't really dump all the files in/usr/bin. These are, almost without exception, executable files. For each executable, support files are usually installed into one or more directory trees, such as/usr/share/executable_name/. The main convenience gained by having all the main binaries in one place (or two - I usually try to leave system binaries in/usr/bin and my own installations in/usr/local/bin) is convenience for searching paths when looking for the binaries.
You shouldn't forget that another reason for splitting stuff up in bin/, share/, etc., is to allow certain directories be shared among multiple nodes in a cluster. E.g., "bin/" can be shared among same hardware platforms, "share/" can be shared among different platforms, "etc/" can not (in general) be shared, etc.
I somehow doubt that some of the messages people send to each other is suitable for saying out load on, say, a bus. Texting is a somewhat more "private" way of communicating than speaking out loud to the phone. And then there is the problem of sending messages when you're in a really loud place like a club (of course, you might argue that people should stop texting while being at there).
Basically, if you spend a lot of time copying data between address spaces of different chunks of the kernel, you're going to pay for it.
First, if you've designed your system in a way that you have to copy large amounts of data between time critical components, you've been doing a terrible job at the design board. Why not share/map the data between different components instead? Second, copying data in and out of the kernel is usually completely unnecessary. The kernel can simply copy the data from one address space to another (no extra copy cost and cache polution by having a temporary copy buffer inside the kernel).
If you have to switch address spaces to switch kernel tasks, you're going to pay for it (in cache misses).
Now, why do you assume that you're going to pay for it in cache misses. True, there may be some cache misses incurred by context switches, but a properly designed kernel can get this down to 12 misses or less (i.e., the kernel touches 12 cache lines doing an IPC between two address spaces, cache lines which may flush out some of the working set of the applications).
Strange. Last time we did measurements here (L4Ka), we ended up with 99 cycles on a 450Mhz PIII to send a message from one process to another. If one has communication within a single task the numbers are an order of magnitude lower (i.e., about 15 cycles).
Examine, for a moment, Linus' motives for improving the kernel. Who are the improvements meant to please? You? Me? No. Himself.
So, improvements are only good if the ideas originate from Linus himself, no? Would Linus not be pleased about improvement ideas if they were originally thought of in, say, the BSD camp? Your parent poster was never trying to say that he wants to have this and that feature in the kernel. He was simply pointing out that Linus might (with high predictability) miss out on some brilliant ideas if he sticks his head in the sand.
The terrorists don't have any real hope of getting the U.S. to say "Sorry. We'll stop doing the things that make you angry." They have no defined goal toward which they are working. They have a vague goal of defeating us. Because of this, they know they won't gain anything substantial by performing these acts.
[...]
We need to go to our baseball games. We need to go buy a bunch of things we don't need from Walmart. We need to take our SUV's out to the lake for a picnic, or to go camping. We need to be ourselves. If we become somebody else, anybody else, we surrender.
While I wholeheartedly agree that one shouldn't give in to terrorism, I am pretty stunned by the total lack of concern people have in finding the cause of the attacks. I mean, sure, there were probably no legitimate reasons for the terrorists to take even remotely as drastic steps as they did on Tuesday, but there must have been something in somebody's mind that triggered the whole thing. It's not like some guy suddenly decides that "Hey, let's take out the Pentagon, White House, and WTC, kiling thousands of innocents in the process!", and 30-50 other people goes "Yeah, that sounds like a jolly good idea!"
Even if it turns out to be bin Laden having a sickingly hatred agains the US and Americans, the answer still prompts the question "Why? There surely must be a reason for the hatred?"
I guess what I'm trying to say is that some people's objections to not trying to learn, to being too bullheaded, to not being willing to adapting at any cost, might have played a significant role in the last days event.
Just to fire up under the conspiracy theories, here's some other "related" stuff which occured on September 11.
1609, Henry Hudson discovers Manhattan island.
1922, Britain is granted mandate of Palestine.
1990, In a statement to the Congress, President Bush promises retaliation of Iraq's invation in Kuwait.
Other close matches:
Sep. 9, 1993. Yassir Arafat agrees on the "Declaration of Principle", i.e., the Oslo-agreement. A signing ceremony is hosted by President Bill Clinton on Sep. 13.
Sep. 12, 2001. Two bin Laden supportered terrorists (the Tanzania US embassy bombing) were supposed to be convicted by a judge in a federal court just beside World Trade Center.
Also have a look on thesesites for more September 11 info.
Quite frankly, that sounds like a very poor design. If you are changing your internal APIs so often and don't have a good abstraction layer in place for basic driver work, then you're shooting yourself in the foot. The internal APIs being in a "constant state of flux" shows that you need to get your heads out of the implementation detail, step back, and do some actual design work first.
There do exist instructions on how to construct drivers. One can even run shell scripts located in/usr/share/examples/drivers which creates working skeleton drivers. Then there exist the option of reading manual pages. Driver(9) might be a good place to start.
As for the kernel API being in a constant state of flux, I believe that the poster didn't mean it that litterally. Sure, some things do change over time, but I find most of the stuff to be very clear and well documented (note, I'm not a FreeBSD kernel hacker/developer). I also find the newbus scheme a very compelling infrastructure for driver development.
Eh... I don't know about the SGIs, but the HP Itanium boxes ship with Linux, HP-UX and Windows. Win XP has, as far as I know, been available for the IA-64 for ages. I can't comment on how stable or efficiently it runs, though, but I guess that Linux for the Itanium still has a few quirks in it too.
It's not only a matter of optimizing for using fewer registers. If you're coding loops for instance, you would most likely want to use the register rotation stuff to do software pipelining of your loop: register r32 becomes r33 from one iteration to the next, register r33 becomes r34, and so on (same thing for predicate and floating point registers). Using this technique you can do some really kick ass optimization of your inner loops. Only problem is that coding the thing and debugging it will do your head in. Now, you would want the compiler to do this stuff for you, but gcc does not support it yet (the SGI Pro64 compiler does, though).
This was one example of low level optimizations, another one is giving hints to different branches (both target and outcome of branch conditions). This is also best done by the compiler (at least the branch target hints), and works even better if you can supply the compiler with profiling information. You can also give data prefetch hints and specify which cache level different prefetch data should go into.
Another example of when you might need to do asm is when you do SMP. The reason being that different load and store instructions are given semantics of how the are to behave in a multiprocessor environment: you want acuire semantics on this load, release semantics on this store, fence semantics here, undefined semantics there, etc. I can't see how the compiler would be able to generate correct assembly in this case (unless it is modified so that you can attach some new attributes to your variables and types).
Then there is this whole plethora of floating point stuff that I won't mention because I don't know shit about it.
Hmm, reading your post again I see that I didn't really answer your question, and most of my ranting about doing asm coding ended up with the conclusion that having the compiler do all the nasty stuff is probably better anyway. I guess I'd better shut up now.
First time I heard this mentioned I interpreted the title as ``Attack of The Clowns''. Needless to say, I was pretty much stunned by the choice of title. I figured that the episode would feature loads of evil annoying people with colorful splashes of paint in their faces (we all know clowns are evil, right) and decided to see what the Slashdot crowd would make of it. I must say I was a tad disappointed when I discovered that the whole story merely was about some meek clones.
Agree. This was one of the things that struck me too. The articles might be good, but they won't be great unless you're able to augment them with decent looking figures. Does anyone know of any macro/scripting like language like MetaPost, Fig, or the LaTeX picture environment for creating simple figures? Using something like embedded MetaPost in a HTML document will of course enable you to create arbitrary complex figures (which also will look great on paper). Using it, however, requires the author to get past a not too trivial threshold.
I guess there does exist a simpler ``package'' somewhere that achieves this. In the beginning one could simply embed the script in the HTML document, and as time passes by one could create a Java application (or whatever) to assist non-expert users in creating figures.
Eh... reality check. There's (almost) just as many FreeBSD core members and committers from Europe as from the US (well, at least that's what the FreeBSD xearth markers tell you), and I assume that the other BSDs (save xMach, probably;-) have a somewhat similar distribution. I don't believe that Europeans are generally less interested in BSD than their american brethrens.
I've been looking through the posts here and I must say that I'm pretty scared of the views that most slashdot people seem to share. Basically, what most of the crowd seems to be saying is: a) don't go there since the infrastructure, standard of living, or whatever really sucks, or b) don't go there because there are more dire needs that need to be fixed first (e.g., current health situation).
I just have to say: What the f**k is wrong with the slashdot crowd? I guess most of the crowd is American, but I always sincerely thought that Americans where better than their reputation (I guess I have to reeavaluate these thoughts).
People considering a) probably never spent a single day outside the comfort of their hometown (or neighbouring town). So what if the standard of living is a bit lower where you get to live in Africa? I mean, I haven't been there myself, but common sense makes me see that there's a bit more to Africa than people living in bungalows and eating each other for dinner.
People considering b) must have their head so thight up their arse that they're only able to consider a direct route from A to B as the only true solution. Get a life. This is the real world. It's not some derivate of a Populus like game where evolution happens to take one specific route. Does anyone actually believe that improvement of, e.g., the net infrastructure does have to occur after other improvements are finished? Does anyone believe that improvement of the net infrstructure is completely orthogonal to othe improvements in the societey, that, e.g., the health sector can not benefit from improvements in the IT sector?
Moreover, anyone taking on a job to build a net infrastructure in Africa (even if their salaries might be lower) will at least be able to help 3rd world countries in a concrete and very useful way. It will probably help more than giving a $10 donation to some random help organization every year. Having someone use their acquired skills to do real, much needed work will usually be way more helpful. In addition, living in another country for some time tend to give you a more unbiased view of the world.
Oh, so you're one of these research really sucks, we should all make some big nasty hack instead sort of arse-crack? I mean, I don't exactly know how DARPA grants work, but I know that there are other expenses than pure salaries. Does travel expenses or hardware expenses mean anything to you? Besides, it is pretty common to secure ones back by saying something like: ``Ok, we'll probably manage to pull this off, but will likely discover that there still are some unresolved issues that we might need to work on in the future (of course, if you would like to give us more funding at that time, we would be very thankful).'' Mentioning something like this in an application or press release doesn't really cost very much.
Rumours have it that PentiumIV will have Simultaneous Multithreading(SMT) enabled, which let's the processoor run any
instruction from any thread on any unit at any time.
It is supposedly going to be implemented in the Foster next year (enter ``foster'' and ``smt'' into your favourite search engine). I recently also independently heard this from some Intel source, so I guess there are some thruths to these rumours.
Creating small toy OSes isn't really as difficult as people tend to believe (given that you have some knowledge of low-level programming that is). On the contrary, doing the programming is often easier since you only operate within an environment that you know pretty well (after all, you designed and implemented it). You just have to deal with the hardware details.
As for designing it multithreaded and for multiprocessors, that one requires a bit more of an effort, but is still very doable. Just for the record, I've seen 2nd year students implement--from scratch--a multithreaded, preemptive kernel with demand paging in 4 months, albeit with a bit og holding hands (well, the holding hands bit didn't really apply to the better students).
The classical paper that contains the numbers suggesting that Mach is... er... suboptimal with respect to performance, is this comparison of L4 versus Mach (and a number of other kernels). This paper does suggest that microkernels need not necessarily be slow if designed and implemented correctly.
As to why (so termed) 1st generation microkernels are still used as the base for newer systems, I can only speculate - but I believe that tradition is the main reason here (teaching an old dog new tricks tend to be hard). Just for the record, however, there is actually an effort to port it to L4.
For more info on L4 related issues, you could have a look at L4Ka, a C++ish implementation of the L4 API.
Slashdot Mirror
Feel free to believe so if that makes you happy. (Herregud for noen helvetes idioter der er rundt om her nå om dagen.)
You STILL haven't read any Intel documents, have you?
If you're referring to the Intel documents describing what the pure context switching costs (for some definition of "pure") in various application scenarios, I'm affraid the answer would be no. Give me a URL or an Order Number for these documents and I'll be happy to revoke my claim that these documents do not exist.
If you want to pretend you're at least kernel knowledgeable, you need to start there.
How brilliant. I would never have figured that I needed to actually read the processor specs before going about designing and implementing various kernels from scratch. Thank you very much. I must have been pretty lucky to get things right in the first place.
You didn't actually bother to read my previous post, did you?
Please show me the location where context switching and task switching overheads are published properly (and officially by Intel). Please also take into account the indirect overhead of cache flushes (TLB and Trace Cache), and the cost of reestablishing the cache working sets. Oh, and don't forget to include measurements for various typical application scenarios. Also make sure to include the costs using different context switching techinques. (Did you know that using the systenter/sysexit instructions saves you a few thousand cycles compared to software interrupts on a Pentium 4?)
So, you being a representative of these "x86 kernel hackers" (I assume that you believe yourself to be one), would you be so kind as to enlighten us about what the overhead of context switching really is? Believe me, most academics working in the field has a pretty good idea of what's going on. I just find statements like yours completely hillarious, and a testament to the ignorance and stupidity of people who find Linux kernel hacking to be 1337.
People call this hype? No way. The real hype came in the name of The Strokes' "Is This It", hit the European charts a couple of months back and the US ones some weeks later. Bleeding good band for being such a hype, though.
The directory tree in each package could also contain a mixture of different architectures so that one could share most of the package's files (e.g., man pages) among platforms and only keep separate files where needed (e.g., executables). The scheme allowed you to categorize the files into any granularity you wanted. You could for instance have one exeuctable for m68k, one optimized for Pentium4, another optimzed for 486, and a generic x86 one (if you had, say, a PentiumIII). The system made sure that the symlink which suited you best was used.
There were also, of course, possibilities to specify files only valid for certain OSes and OS revisions, and one could specify files which should be valid only within one certain domain, or on one certain host.
Another feature was the ability to keep multiple versions of the same application around, and mark the different versions as stable, release, beta, etc. This allowed you to specify hosts or domains which only should run stable software, which should be able to run beta software, and so on.
In addition to keeping multiple versions of the binaries around, the system also could keep multiple build frameworks around. The build framework could contain configurations for various OSes and platforms, and allowed applications to be more easily installed on various architectures.
Of course, there was also a package config file indicationg the name of the package, short info, dependencies, etc.
For distribution one could create a tree-like structure where the whole or a subset of the packages and binaries for the packages were automatically mirrored to hosts in the network. This allowed you to have most of the packages located on the servers while the clients which had only limited diskspace only had a limited set of packages (e.g., shells) installed locally.
There were also add-ons to automatically configure various environment variables on the hosts, configre mailcap/mime-type files, emacs configuration entries, info-file entries, etc.
The whole thing worked wonderfully (once you as a sysadmin learnt how to use it properly). It automatically propagated new applications throughout the system once you installed them and generally made life easier for the sysadmin. Installing software on new machines was also pretty painless. You just configured your new client system, fired up a single command, and all applications suitable for the system were installed and configured for you.
You shouldn't forget that another reason for splitting stuff up in bin/, share/, etc., is to allow certain directories be shared among multiple nodes in a cluster. E.g., "bin/" can be shared among same hardware platforms, "share/" can be shared among different platforms, "etc/" can not (in general) be shared, etc.
I somehow doubt that some of the messages people send to each other is suitable for saying out load on, say, a bus. Texting is a somewhat more "private" way of communicating than speaking out loud to the phone. And then there is the problem of sending messages when you're in a really loud place like a club (of course, you might argue that people should stop texting while being at there).
First, if you've designed your system in a way that you have to copy large amounts of data between time critical components, you've been doing a terrible job at the design board. Why not share/map the data between different components instead? Second, copying data in and out of the kernel is usually completely unnecessary. The kernel can simply copy the data from one address space to another (no extra copy cost and cache polution by having a temporary copy buffer inside the kernel).
If you have to switch address spaces to switch kernel tasks, you're going to pay for it (in cache misses).
Now, why do you assume that you're going to pay for it in cache misses. True, there may be some cache misses incurred by context switches, but a properly designed kernel can get this down to 12 misses or less (i.e., the kernel touches 12 cache lines doing an IPC between two address spaces, cache lines which may flush out some of the working set of the applications).
Strange. Last time we did measurements here (L4Ka), we ended up with 99 cycles on a 450Mhz PIII to send a message from one process to another. If one has communication within a single task the numbers are an order of magnitude lower (i.e., about 15 cycles).
Examine, for a moment, Linus' motives for improving the kernel. Who are the improvements meant to please? You? Me? No. Himself.
So, improvements are only good if the ideas originate from Linus himself, no? Would Linus not be pleased about improvement ideas if they were originally thought of in, say, the BSD camp? Your parent poster was never trying to say that he wants to have this and that feature in the kernel. He was simply pointing out that Linus might (with high predictability) miss out on some brilliant ideas if he sticks his head in the sand.
Even if it turns out to be bin Laden having a sickingly hatred agains the US and Americans, the answer still prompts the question "Why? There surely must be a reason for the hatred?"
I guess what I'm trying to say is that some people's objections to not trying to learn, to being too bullheaded, to not being willing to adapting at any cost, might have played a significant role in the last days event.
- 1609, Henry Hudson discovers Manhattan island.
- 1922, Britain is granted mandate of Palestine.
- 1990, In a statement to the Congress, President Bush promises retaliation of Iraq's invation in Kuwait.
Other close matches:- Sep. 9, 1993. Yassir Arafat agrees on the "Declaration of Principle", i.e., the Oslo-agreement. A signing ceremony is hosted by President Bill Clinton on Sep. 13.
- Sep. 12, 2001. Two bin Laden supportered terrorists (the Tanzania US embassy bombing) were supposed to be convicted by a judge in a federal court just beside World Trade Center.
Also have a look on these sites for more September 11 info.As for the kernel API being in a constant state of flux, I believe that the poster didn't mean it that litterally. Sure, some things do change over time, but I find most of the stuff to be very clear and well documented (note, I'm not a FreeBSD kernel hacker/developer). I also find the newbus scheme a very compelling infrastructure for driver development.
Eh... I don't know about the SGIs, but the HP Itanium boxes ship with Linux, HP-UX and Windows. Win XP has, as far as I know, been available for the IA-64 for ages. I can't comment on how stable or efficiently it runs, though, but I guess that Linux for the Itanium still has a few quirks in it too.
This was one example of low level optimizations, another one is giving hints to different branches (both target and outcome of branch conditions). This is also best done by the compiler (at least the branch target hints), and works even better if you can supply the compiler with profiling information. You can also give data prefetch hints and specify which cache level different prefetch data should go into.
Another example of when you might need to do asm is when you do SMP. The reason being that different load and store instructions are given semantics of how the are to behave in a multiprocessor environment: you want acuire semantics on this load, release semantics on this store, fence semantics here, undefined semantics there, etc. I can't see how the compiler would be able to generate correct assembly in this case (unless it is modified so that you can attach some new attributes to your variables and types).
Then there is this whole plethora of floating point stuff that I won't mention because I don't know shit about it.
Hmm, reading your post again I see that I didn't really answer your question, and most of my ranting about doing asm coding ended up with the conclusion that having the compiler do all the nasty stuff is probably better anyway. I guess I'd better shut up now.
First time I heard this mentioned I interpreted the title as ``Attack of The Clowns''. Needless to say, I was pretty much stunned by the choice of title. I figured that the episode would feature loads of evil annoying people with colorful splashes of paint in their faces (we all know clowns are evil, right) and decided to see what the Slashdot crowd would make of it. I must say I was a tad disappointed when I discovered that the whole story merely was about some meek clones.
I guess there does exist a simpler ``package'' somewhere that achieves this. In the beginning one could simply embed the script in the HTML document, and as time passes by one could create a Java application (or whatever) to assist non-expert users in creating figures.
Eh... reality check. There's (almost) just as many FreeBSD core members and committers from Europe as from the US (well, at least that's what the FreeBSD xearth markers tell you), and I assume that the other BSDs (save xMach, probably ;-) have a somewhat similar distribution. I don't believe that Europeans are generally less interested in BSD than their american brethrens.
I just have to say: What the f**k is wrong with the slashdot crowd? I guess most of the crowd is American, but I always sincerely thought that Americans where better than their reputation (I guess I have to reeavaluate these thoughts).
People considering a) probably never spent a single day outside the comfort of their hometown (or neighbouring town). So what if the standard of living is a bit lower where you get to live in Africa? I mean, I haven't been there myself, but common sense makes me see that there's a bit more to Africa than people living in bungalows and eating each other for dinner.
People considering b) must have their head so thight up their arse that they're only able to consider a direct route from A to B as the only true solution. Get a life. This is the real world. It's not some derivate of a Populus like game where evolution happens to take one specific route. Does anyone actually believe that improvement of, e.g., the net infrastructure does have to occur after other improvements are finished? Does anyone believe that improvement of the net infrstructure is completely orthogonal to othe improvements in the societey, that, e.g., the health sector can not benefit from improvements in the IT sector?
Moreover, anyone taking on a job to build a net infrastructure in Africa (even if their salaries might be lower) will at least be able to help 3rd world countries in a concrete and very useful way. It will probably help more than giving a $10 donation to some random help organization every year. Having someone use their acquired skills to do real, much needed work will usually be way more helpful. In addition, living in another country for some time tend to give you a more unbiased view of the world.
Oh, so you're one of these research really sucks, we should all make some big nasty hack instead sort of arse-crack? I mean, I don't exactly know how DARPA grants work, but I know that there are other expenses than pure salaries. Does travel expenses or hardware expenses mean anything to you? Besides, it is pretty common to secure ones back by saying something like: ``Ok, we'll probably manage to pull this off, but will likely discover that there still are some unresolved issues that we might need to work on in the future (of course, if you would like to give us more funding at that time, we would be very thankful).'' Mentioning something like this in an application or press release doesn't really cost very much.
It is supposedly going to be implemented in the Foster next year (enter ``foster'' and ``smt'' into your favourite search engine). I recently also independently heard this from some Intel source, so I guess there are some thruths to these rumours.
As for designing it multithreaded and for multiprocessors, that one requires a bit more of an effort, but is still very doable. Just for the record, I've seen 2nd year students implement--from scratch--a multithreaded, preemptive kernel with demand paging in 4 months, albeit with a bit og holding hands (well, the holding hands bit didn't really apply to the better students).
As to why (so termed) 1st generation microkernels are still used as the base for newer systems, I can only speculate - but I believe that tradition is the main reason here (teaching an old dog new tricks tend to be hard). Just for the record, however, there is actually an effort to port it to L4.
For more info on L4 related issues, you could have a look at L4Ka, a C++ish implementation of the L4 API.