Why the microkernel part? Although I don't have much experience in this, I'd say it should be quite simple, relatively speaking. Look at Linux, most of the kernel tree is drivers. The kernel itself is pretty small.
From reading stuff and watching discussions what I got is that the problem with microkernels is that they're hard to properly implement and still have fairly bad performance. In fact, I hit those same problems when trying to code an extremely modular application, that I tried to write as an exper
From reading stuff and watching discussions what I got is that the problem with microkernels is that they're hard to properly implement and still have fairly bad performance. In fact, I hit those same problems when trying to code an extremely modular application, that I tried to write as an experiment.
BeOS is a microkernel. OSX is a microkernel... er ok it's performance isn't fabulous. NT is sorta a microkernel (with a lot of rules broken), and its I/O still spanks everyone else (owing to its VMS-inspi
BeOS is dead, and last time I heard about it, OS X runs all of Darwin as one big process. Now, this area of my knowledge is very fuzzy, but if true then it's not much of a microkernel, when if I understand correctly, the original idea was to have lots of little components.
NT might have been somewhat of a microkernel in NT 3.51, but it's not anymore. Win2K is a NT system, and I haven't seen it resist driver failures. In fact, any serious kernel failure results in a BSOD, followed by a reboot. Heck, even Lin
BeOS is *not* dead! I'm so sick and tired of telling that:-( http://haiku-os.org -- http://yellowtab.com We just got Java with Swing running : http://www.haikunews.com as well as a.NET port...
Actually there are so many things from BeOS that Unix would benefit... - queriable indexed *typed* attributes in the filesystem (I've yet to see reiser4 on work, BFS has that for ages) I even recently did a queryable live bookmark using google : http://clapcrest.free.fr/revol/beos/shot_googlefs_ 006.png - a standardized (no 3 different API to choose from) node monitor that doesn't require you to recompile the kernel (and that was way before linux even tried to do that), which doesn't send you a signal to let you pool everything to know what changed (why node monitor then ?). - uncluttered easy to use and standardized threading. - a logical driver framework (modules are loaded on demand from drivers by their logical hierarchical name, no need for insmod foo.o which you don't know its use). Haiku will even push that further. And the hierarchical/dev/ tree thatcomes with it that took years to Linux to get. - mime-driven APIs, with a sniffer, mimetype attribute that doesn't require you to fix broken file extentions, assigns apps to files automatically... - a file-based mail system (using indexed fs attributes, so you just run a query to find new mail, no bloody mbox or app-specific stuff) - consistent GUI - easy to use IPC (sems, ports, and BMessage on top of ports)...
Oh, another important one: UTF-8 everywhere by default. So much easier (except when porting apps when the author thinks supporting Unicode requires that stupid wchar_t and insists on using that crap)
Several frustrating points (Score:5, Insightful)
In my opinion, here are some headaches that have plagued a wary UNIX engineer or two:
IEEE and Posix, X/Open, etc. provide a basis for standardizing UNIX interfaces, but adherence tends to be spotty
Difficult to implement a microkernel architecture
XPG3 aside, a de facto "common API" has never really been acheived
In many cases, code scrutiny is difficult or impossible
Progress and innovation tends to occur within the context of aquisitions
Re:Several frustrating points (Score:3, Interesting)
From reading stuff and watching discussions what I got is that the problem with microkernels is that they're hard to properly implement and still have fairly bad performance. In fact, I hit those same problems when trying to code an extremely modular application, that I tried to write as an exper
Re:Several frustrating points (Score:2, Interesting)
BeOS is a microkernel. OSX is a microkernel
Re:Several frustrating points (Score:3, Interesting)
NT might have been somewhat of a microkernel in NT 3.51, but it's not anymore. Win2K is a NT system, and I haven't seen it resist driver failures. In fact, any serious kernel failure results in a BSOD, followed by a reboot. Heck, even Lin
Re:Several frustrating points (Score:1)
I'm so sick and tired of telling that
http://haiku-os.org -- http://yellowtab.com
We just got Java with Swing running : http://www.haikunews.com
as well as a
Actually there are so many things from BeOS that Unix would benefit...
- queriable indexed *typed* attributes in the filesystem (I've yet to see reiser4 on work, BFS has that for ages) I even recently did a queryable live bookmark using google : http://clapcrest.free.fr/revol/beos/shot_googlefs
- a standardized (no 3 different API to choose from) node monitor that doesn't require you to recompile the kernel (and that was way before linux even tried to do that), which doesn't send you a signal to let you pool everything to know what changed (why node monitor then ?).
- uncluttered easy to use and standardized threading.
- a logical driver framework (modules are loaded on demand from drivers by their logical hierarchical name, no need for insmod foo.o which you don't know its use). Haiku will even push that further. And the hierarchical
- mime-driven APIs, with a sniffer, mimetype attribute that doesn't require you to fix broken file extentions, assigns apps to files automatically...
- a file-based mail system (using indexed fs attributes, so you just run a query to find new mail, no bloody mbox or app-specific stuff)
- consistent GUI
- easy to use IPC (sems, ports, and BMessage on top of ports)...
and I'm already tired of listing them.
Re:Several frustrating points (Score:1)
Re:Several frustrating points (Score:1)
googlefs shot [clapcrest.free.fr].