Slashdot Mirror
Bringing xMach To Life
jmallett writes: "xMach, the microkernel BSD Operating System, first made an announcement on Daily DaemonNews stating that there were some new source and binary snapshots available. Also, OsOpinion has an article I wrote about my experiences so far, entitled 'Giving Birth to xMach'. Development of xMach currently is limited to the microkernel and its servers, but a userland (based on that from the good people at OpenBSD) will be worked on shortly. Some of the primary focuses on xMach are data storage, security, and non-bloat."
You know that commercial software vendors have got to be feeling like they are in a precarious position when 16 year-old highschool dropouts can successfully write their own Unix microkernel based operating system.
Seriously, the programming team for this xMach thing consists of some punk kid and 5 or 6 other people (none of which stuck the project out to the end). That is insane (in a good way). Honestly, if uneducated volunteers can accomplish a feat like that and give the results away then you almost have to feel sorry for those people in the business of creating proprietary operating systems. Basically they are screwed.
Congratulations to the hackers working on xMach.
The WHOLE POINT of a microkernel based architechure is to have this layer. It's another thing that can break, yes, BUT unlike the rest of the 'kernel' it is small, and it has very very limited goals in life. (things like schedule tasks, map memory, provide some ipc primitives, etc....) Small means debugable. Small means TESTABLE. Like formal qualification tests. Regression test suites. You can beat the hell out of a microkernel. Then you have known stable base to build your OS services from.
Look at QNX as a real example. (not to say it's perfect, however, it works quite well. You can pull hardware drivers in and out on the fly.)
Enough of this. I need to do some work here
"There's no secret. You just press the accelerator to the floor and keep turning left." -- Bill Vukovich
I'm interested in hearing more about the issued you had porting Streamripper to BeOS. The link to the BeOS binary from BeBits seems to be broken. I'll cvs it and take a look at it tonight. Any major brokes, besides the panics while debugging?
, but the GUI was beyond me. all of the same code i could find wouldn't even compile. Also i got constant kernel panics when debugging threads. real shame...
Well, Be's native gui is unique. In other words: BeAPI != win32API != gtk/qt/motif/whatever. The BeBook is available online, if anyone's interested in the API. Programming for BeOS is a great way to learn C++, IMHO.
It does not mean that BeOS is broken. Sheesh. Software evolves, paper decomposes. Fortunately, there *is* current documentation available.
Try the current version of the BeBook (available online), or join #bedev on irc.elric.net :-)
Uhmm.. it sort-of is. Check out darwinos.org, or read Apple's FAQ.
"Darwin is processor-independent and is built for PowerPC and Intel platforms, enabling Open Source developers to work on Darwin projects on the widest choice of computer systems."
BeOS has an IP stack in-kernel.
>>>>>
Not yet.
That ain't no micokernel.
>>>>>>>>>
That might sully its definition as a "true" microkernel, but I'd argue that BeOS is more of a microkernel OS where it counts than any other Mach-based OS, except maybe HURD. First, many microkernel OSs have networking integrated, I believe QNX4 had it in the kernel. Second, Most Mach based OSs use a monolithic system server, which throws many of the benifets of a microkernel OS out the window. In BeOS, for example, if the net_server crashes, it can be restarted without too much trouble. If networking in the BSD system server crashes, then the OS is down the tube anyway.
A deep unwavering belief is a sure sign you're missing something...
A) BeOS doesn't yet have networking in the kernel. Even with BONE, its microkernel-nature isn't effected too much since microkernels that do networking in userspace (such us QNX4 which, contrary to my previous post, does indeed do networking in userspace) use highly-optimized shared-memory paths to communicate with the kernel. These paths are much easier to corrupt and thus cause crashes than normal messaging interfaces. Besides, BeOS (and arguably NT) is more of a microkernel than NeXT, OSX, or whatever. Mach or not, they use a single system server, which gets rid of a lot of the benifets of the microkernel design. As for USB devices, how does that make it not a microkernel? Its a bus just like the ATA or PCI busses, and I have yet to see anybody propose to do PCI outside the kernel.
A deep unwavering belief is a sure sign you're missing something...
I don't know about you, but (aside from when I was writing a kernel driver) Linux (X actually, but since I use the GUI, its all the same) has crashed on me more often than BeOS. Not to mention that it hosed ext2 twice... BeOS is probably a little less stable than Linux, but I only reboot my machine once every few weeks and neither OS crashes on me. As I said, net_server is pretty unstable, but that's why its being replaced.
A deep unwavering belief is a sure sign you're missing something...
certainly not! the best hoovers by far are those on the Roland Alpha Juno 2.
- j
Am I missing something here, or is Darwin already what xMach is trying to be? Darwin may not be ported to x86 yet, but it is the foundation for a comercial product and as such has seen a great deal of development. And if the goal was to create a free implementation of OPENSTEP why not work on porting GNUStep to Darwin?
W2k is not based on mach, and the rumours that its stability lessened significantly when win32 and others were allowed to run in kernel mode are unfounded when considered more carefully.
Give the book "Inside Windows 2000" a read sometime.. but basically, i'll paraphrase
"Is Windows 2000 Less Stable with Win32 USER and GDI in Kernel Mode ?
...the reason the impact on system stability has been minimal is that prior to windows NT 4 (and this si still true today), a bug (such as an access violation) in the usermode Win32 subsystem process (csrss.exe) resulted in a system crash. This crash occures because the parent process of Csrss (the session manager, smss) does a wait operation on the process handle to csrss, and if the wait ever returns, smss crashes the system, because the win32 subsystem process was (and still is) a vital process to the running of the system....
there is one additional danger that did not exist prior to moving the windowing and graphics system into kernel mode.. because this body of code is now running in kernel mode, a bug (such as the use of a bad pointer) could result in corrupting kernel mode protected data structures..prior to nt4 such references would ahve caused an access violation because kernel mode pages aren't writable from user mode, but a system crash would ahve then resulted, as described earlier.. with the code now in kernel mode, a bad pointer ref that caused a write op to some kernel mode page might not immediately cause a crash, but if it corrupted some data, a crash would likely result soon after..
.. another area of impact can come from moving the graphics drivers into kernel mode.. previously some portions ran in csrss, and others in kernel mode.. now the entire driver runs in kernel mode..
... finally, running the windowing system and graphics drivers in kernel mode is not _fundamentally_ risky... many other device drivers (network cards, hard disk drives) have always run in kernel mode on every version of NT, with a high degree of reliability.."
his little analysis goes on an on.. talking about the scheduling impact on smp and non-SMP boxes about these moves, and many other cool issues..incase you cant tell i think anyone that uses w2k at all should have this book.. its pretty sweet (and comes with a cd full of neat make-NT-stink-less tools like a self-hosted kernel debugger, etc..)
its "Inside Microsoft Windows 2000", by Davide Solomon and Mark Russinovich...
My opinions are my own, and do not necessarily represent those of my employer.
But i'm also a critic, mainly of people who blather on about how people should stop compaining and write code for X etc.. it JUST DOESN'T HAPPEN! Very few open source project are more then a single person hobby. it's hard to make a world class large project out of this. There are exceptions, Linux or instance, but not many.
-Jon
Streamripper
this is my sig.
Assuming you meant microkernel and not Mach, you missed one commercial (though admitedly not widely used) Unix OS that uses a microkernel: Unicos/mk, which runs on Cray T3E systems. Of all the OS's you list, I think Unicos/mk wins hands down - it scales to almost 2000 processors and you can reboot individual processors without taking down the entire system.
Go Badgers! -- #include "std/disclaimer.h"
set yourself up as a tin-pot dictator of your own website -- then you can decide what stories get posted.
Or just go to Kuro5hin, where the community chooses the stories.
Will I retire or break 10K?
I seriously think some people here think that Linux would make a better vacuum cleaner than a Hoover branded one!
I'm not so sure -- it seems like a legit question. It wouldn't be modded down if it asked "Should I use Linux instead of Windows for a NAT server"
I don't think it's the FreeBSD community, per se, but rather the newsgroup community in general. Just think about all of the BW that is wasted when NG-lurkers with big heads critique every word in your post before telling you to Read the FAQ/Manual/Earlier posts. Just spend a day reading comp.lang.perl.misc and you'll get my point.
--
Wooden armaments to battle your imaginary foes!
There are basically two reasons I can see for xMach to even exist:
-Lites is Not Ready for Prime Time (which I have no knowledge of), or
-someone wants to see a GPL'ed BSD.
I don't know if either situation applies; xMach as it stands is BSD licensed, so the second possibility is currently out. Apart from that, why do we need a fifth BSD to begin with except to satisfy someone's hacker itch?
The thing is, Yet Another Microkernel BSD is not what we need. We already have Lites. We already have Darwin. If you're going to create a Mach-based OS, why not do something non-Unixy? Why not do a freeware clone of Solaris or some other Unix with a lot of specialized features?
That said, I may offer to help out anyway, I don't know...
/Brian
Wow. Can you moderate someone down -3/4 for being 3/4 of a troll?
Last time I checked, the OS of choice for Mach is pretty much any Unix you care to port to it; the most important of these would be OSF/1 (aka Compaq Tru64) and MacOS X/NextStep (there may be others). The Hurd fits loosely into that category as it's meant to be more or less a Unix act-alike, though its architecture is drastically different from any Unix or Linux system available.
(IMHO the Hurd is obsolete except as a teaching tool anyway -- the world marched on without it while it was still vapor. But that's my personal bit of flamebait and I invite others to disagree.)
/Brian
I've seen this before... does someone have an autopost script that pops this up on every BSD article or something? (And a Linux version now...)
/Brian
(ps To those not really in the know, it's a crock anyway -- I'm not going to get into it, but someone is clearly missing the point...)
Hurd is overkill for most projects, and its long delay in seeing the light of day stands as a monument to cathedral hubris. And it's not developed from scratch anyway -- it shares the Mach kernel with a number of other OSes. The only thing really innovative about it is the multiserver design and the architectural intricacies that follow from it. The Hurd is basically a huge toy for the OS geek, and will not gain the kind of momentum that Linux and BSD have.
And yes, you BSD-is-dead, people, BSD has massive momentum. Just ask Apple, and Compaq, and Yahoo, and...
/Brian
Failure schmailure. BSD has been going for over twenty years now -- that's got to be some kind of Open Source record.
/Brian
WinNT/2K is a joke as far as microkernel design is concerned -- you're right about Microsoft blowing massive holes in the design to do things. They've fixed a lot of that in W2K, but it's still Windows.
BeOS was a great idea that got bogged down by Jean-Louis Gassee's ego. The fact is that BeOS was "forced" onto Intel hardware because they weren't willing to suck it in and use the information that was already out there in the form of MkLinux (granted that would require some creative interpretations of the GPL, but I'm sure Apple could get away with GPLing Darwin without doing the same to X).
OS X is very much like what xMach is doing, though it's already been there for maybe ten or twelve years now (or is it longer?). It doesn't have the holes NT has, and it has one of the best object frameworks in the business (even if you do need to know ObjC or Java to use it).
The Hurd, finally, is not actually vaporware. What it is is a monument to Stallman's hubris in thinking that he could create a cutting-edge OS (and it's bleeding-edge, at the very least, if you know anything about its internals). The problem with the Hurd is that it's an extraordinarily complex piece of software with a limited appeal; where Linux pays little attention to the state of the art and follows the classic Unix philosophy of "just make it work right, dammit", the Hurd from what I've read tries to be the most advanced system out there; almost everything is customizable, and the kernel architecture itself is a Mach-based multiserver. (Read up on it -- you'll grok instantly why it took ten years to get it to daylight in any form at all...)
There are a few others, I believe. Minix is said to be a microkernel architecture, though I don't know much about it. PalmOS is microkernel-based, but the Palm userland doesn't really pay much attention to it. MacOS uses something called a nanokernel, which I think is nothing more than a very low-level HAL (exactly what use it is I don't know).
/Brian
The HURD is developed from scratch, a pure design, a working microkernel with an up-and-coming Debian distribution, and officially supported by the GNU project.
xMach appears to fall short of the HURD in each of these areas, if I'm not mistaken: it's not developed from scratch, has a more mingled design with existing BSDs, in partially-working state and is not part of a funded project.
Not to disparage the xMach team, but as an honest question, how is this use of resources better than simply contributing to the HURD? Is it simply ego?
That brings up another point. How often do free software projects suffer from ego? Not the make-things-better-because I'm good ego, but rather splitting projects, wasting time on personal conflicts, etc. NetBSD vs. OpenBSD, GNU Emacs vs. XEmacs, KDE vs. GNOME, and now xMach vs. HURD; do these competing forks serve a productive purpose in the free software community, or are they simply reminders of the inherit inefficiency prevalent in any organized human endeavour?
Just some thoughts... thanks.
What do you feel comfortable with? FreeBSD is my personal preference, but you have to be very aware of the huge cultural difference between Linux and FreeBSD communities. Within the FreeBSD community, it is extermely necessary to RTFM completely before you step forward and ask a presumably stupid (all newbies are presumed stupid until proven smart) question on the mailing list. Clueless lusers are not very welcome. (I'm just stating what I see as the attitude on the various FreeBSD mailing lists.)
That said, the technical qualities of FreeBSD make it outperform Linux in all cases. Linux suffers from the disease of the least common denominator--i.e., they let anyone hack away and contribute poor quality software to the effort. With FreeBSD, there is a lot of attention to doing things the right way, where the right way is defined by the people on the committers list.
So, if you think that you can install and start up the system on your own, go for FreeBSD. If you need help from the get-go, better stick with Linux. After you get the system up and running, and you have thoroughly R'd TFM, and you have spent at least 2 weeks reading freebsd-stable mailing list, then ask for help.
I'm curious how xMach compares to Mach 3.0 from CMU. Is there any relation at all besides sharing a microkernel architecture and the word "Mach?" Does anyone have a summary of the interesting features of xMach? Is this doomed to be yet another operating system?
--Sam
It was marked "troll" because the FreeBSD philosophy is to make a high-performance x86 server, and it probably is the highest performance server you can set up on an x86 box.
Whether the poster knew this or not is another question altogeather.
Trolls throughout history:
Trolls throughout history:
Jonathan Swift
Ceci n'est pas un sig
...FOX Broadcasting has just filed in court an injunction again xMach for infringing on their trademark "X-Files" TV show. When asked to comment, the lawyers for FOX said, "we think that popcorn manufacturers need to learn that they can't name their kernels after TV shows and not expect legal action."
Come on.. It could happen.