Slashdot Mirror
Domain: vsta.org
Stories and comments across the archive that link to vsta.org.
Comments · 20
-
Re:Back in the day...
Unfortunately, Linux in this respect is not a "Modern OS". The ability to sandbox user applications is extremely poorly developed. I have been looking at portable sandboxing lately, and it is a horrible nightmare. The Chrome developers created some fancy hacks for each OS, and they have pulled it off quite nicely, but they remain hacks, not elegant designs. The platform with the best current sandboxing API is, ironically, Windows Vista/7, with their configurable integrity levels. An API dubbed "Seatbelt" is being developed on MacOSX, but it is still in its barely-can-walk infancy, and the Chrome devs used undocumented parts of the API to make it all work. On LINUX there is a set of competing security modules for the kernel, with SELinux being the most used. Unfortunately, not only do some distros not use it, but a lot of users who have it disable it immediately (or set it to permissive mode, which from a sandboxing point of view is the same thing). And SELinux is a horrible beast to program for. It is insanely complex, and has non-existent documentation on how to use it to confine user programs.
What is needed is some generally agreed upon extension to POSIX on how to easily allow a user process to drop privileges it does not need. One experimental OS I looked at once (VSTa) had the ability for all users to create subgroups to their GID by adding more numbers. If your UID.GID was 500.500, you could create a new directory owned by 500.500.2, and allow the process owned by 500.500.2 only to access to this directory (some documentation on this is still up at http://www.vsta.org:8080/VSTa_2fDocumentation_2fCapabilities). I wish some similar, dead simple scheme could be created for Linux that ordinary users could understand themselves. Only a dedicated security elite could possibly wrap their heads around the SELinux rules -- everyone else just turn it off as soon as it gets in the way.
-
To add to that list...
-
Re:I like the last bit
That's just the HURD people being idiotic.
Folks with better design sense have implemented their own microkernels with vastly better performance and in far, far less time. -
Re:I like the last bit
Microkernels are not necessarily slower than dirt -- just poorly implemented ones (the HURD being a prime example).
See VSTa for a counterexample. -
It's all about the size.
I happen to know some very skilled embedded systems developers, and at least one (also a Linux kernel maintainer) recently lost a possible contract with a very large multinational company because Linux turned out to be too large for the environment they wanted to run it in.
Hopefully VSTa or a like open operating system better suited to very small environments (eCos? dunno) will become practical and popular for such usage. Linux is reasonable in larger embedded systems -- networking hardware and the like -- but its suitability becomes less and less as space constraints constrict (think 100K of RAM or less). Remember, it's not just the cost of the OS that's an issue -- the cost of the extra hardware to run it, and the loss of battery life, is also a dealbreaker.
So no, I'm not convinced by this report; the summary makes it look too much like something concocted by talking to managers with insufficient engineering input. -
Re:Not so surprising
I need to finish my OS for when Linux goes down in flames. Then I can be the author of the most popular free OS instead of the least popular.
Isn't that what open source is all about? Who is most popular?
Try these OSes on for size:
Retro Forth
AtheOS
VSTa
TinyOS
-
Free software inspired by QNX:
VSTa is a free software OS inspired by QNX and Plan 9. Very nice looking, although when you run it very disappointing (it's slow).
Much more interesting to me is the concept of exokernels, a completely different OS organization which allows for
(The most significant person who's pushing for this plan for Linux, by the way, is Larry McVoy, notorious author of BitKeeper.)
-Billy -
A number of choicesProbably you will not expect peak performance from that anyway... So here is what I would go for:
- Linux Kernel 2.2 (with low memory i would recommend 2.2..) or a really stripped-down 2.4 kernel, running a modern distro which is rather slick in itself, like Slackware or Debian. This will help you avoiding numerous security holes in older distros.
- There has been an article which focusses on small yet functional destop programs.
- If you want to go with really stripped-down distros, which are suitable (or optimized) for embedded computers, check this link.
- I have to agree with some of the other posters that one of the *BSD derivates can be and feel a lot smaller than full-featured, KDE3-based Linux distros...
- If security is not much of an issue for you, for whatever reason, you might want to go for an outdated Linux distro. Watch out for a 2.0 or 2.2 kernel, and libc5 instead of glibc2/libc6, or you might not gain much from the old stuff... Or even Minix? VSTa?
-
Re:Also let it be known...try VSTa then.
-
VSTa
An OS that is worth checking out if you like the ideas in Plan 9 is VSTa. It is a GPL'ed OS borrowing a lot of ideas from Plan 9. It's microkernel. But not as mature as Plan 9.
-
Bah -- VSTA is a better microkernel-based OS.
Seriously -- VSTA has a much cleaner design than the HURD and far superior runtime speed. It's based on some rather different design decisions (favoring being Right over being backwards-compatible where the two conflicted strongly), but is just generally Good Stuff.
If the HURD increases interest in microkernel-based OSen, good for it -- I *like* my drivers running in userspace! (heckuvalot easier to write and debug that way, no? heck -- that means one can write a prototype driver in Python before putting together the final version in C; let's see 'yall do that in Linux!)
Admittedly, it's not nearly as close to being end-user-ready as the HURD, but for folks doing embedded systems work (or who want a cool OS to play with), it's seriously worth looking into. -
Consider VSTa...
...or another experimental OS. VSTa in particular needs drivers (and lots of other stuff) so you can easily find something to do, and has many novel design features (being a proper microkernel design -- with almost all work, including traditionally "driver"-style code, done in userspace -- yet faster than Linux) that make it fun to learn about.
If you're decided to go with Linux, though, just pick something and do it. My first kernel driver was a network driver for a NIC (don't remember the model, it was quite a while ago; Don Becker ended up writing a better driver that was accepted into the official kernel, but it was an interesting experience anyhow). If you have access to any interesting hardware that isn't supported (which may be hard to find on x86), writing drivers or porting to new hardware (not whole new architectures, mind you -- that's a bit much) is a good starting place. -
What about VSTa?
VSTa is a very promising upcoming OS, with a microkernel architecture and very modular design. Why wasn't it mentioned in that list? Development seems to be active. I know of someone at MontaVista who spends all his spare time working on VSTa. It's supposed to be similar to Plan9 in a few ways, very advanced, research-based, designed by people experienced with kernel and OS programming... It already supports SMP.
-
VSTaIf you want to check out a GPL'ed, microkernel based os with a lot of ideas from Plan9. Check out VSTa at http://www.vsta.org/
-
Re:"Mach is a bad microkernel implementation".. HOWill someone please attempt to assert or refute, using some kind of solid logic or numbers or something, the statement that microkernels are a good idea but Mach is a bad implementation of that idea? What is done wrong in Mach, and can it be fixed?
I don't know enough of the Mach internals to know exactly why it's such a poor performer, but I have read alot of theories put forth. The most common(and accepted) reason is that Mach's memory management is too abstract and that because Mach is built on a hardware abstraction layer. Those two reasons are directly interrelated.
The Hardware abstraction layer(HAL) restricts the u-kernel to operation on a "generic machine". Everything is abstracted in the sense that the HAL contains the units which are common to all CPU architectures. This was done to improve portability. However, it sacrifices a great deal of performance because alot of issues are platform dependent. Things such as page size must be dictated by the architecture you are running on. But because Mach uses the HAL to abstract this away, Mach performance suffers a great deal in memory operations. Often, the HAL dictates a page size which is too small/large for the architecture. The hardware can't handle address translation anymore, so the kernel has to do this manually. This is very expensive.
In general, Mach's architecture just seems poorly designed from what I've read. Alot of research has been done on this topic, and they're coming to the realization that u-kernels are inherently non-portable. That's a very important point. This shouldn't be surprising either because the u-kernel is so small that mostly only platform dependent code end up in there. L4 is 12k, Eros is 32k(I think), VSTa is around 50k and QNX is less than 10k!
The good thing about this approach is that most(if not all) of the platform-dependent code is wrapped up in the u-kernel. The rest of the system is completely portable. So all you have to do is re-write about half of a 20k kernel for the new architecture, and you're done! Re-compile and off you go. Theoretically at least.
If mach is, indeed, a bad implementation of the microkernel, what would be a *good* implementation of the microkernel? Are any well-designed microkernels out there?
Good u-kernels that have implementations with performance comparable to or exceeding Linux:- QNX: Everyone's heard of this one. They have a very good u-kernel.
- Opearting Systems Group at Dresden: They do alot of great work with u-kernels. They have code for L3 and L4, the first very promising, high-performance u-kernels(though they may not have designed them). They even have Linux running as a service on top of L4, so you may be able to run it right now! Also see This University and the L4KA page for other implementations of L4(ie. other architectures).
- Eros: EROS is a new operating system based on the architectures of earlier high-security capability systems(KeyKOS). Very promising and has performance comparable to L4. The measurements are in the papers section(usually towards the end of the paper). System is GPL'd.
- VSTa: a cool GPL'd hobby u-kernel system(in that it has no university or company backing). This one has a somewhat complete system, ie. self-hosted with gcc, vi, emacs, etc. Runs on a windows partition and uses GRUB to boot(all of which you'll need to run it). No performance metrics that I'm aware of.
- Fluke: No working system as far as I know. The kernel is complete and some performance measurements have been made. Looks promising and source is available(GPL I think).
If there are, then what is it that repeatedly leads projects like xMach/HURD/OS X/mkLinux to embrace Mach as opposed to one of the competing microkernels?
I have no idea. Ignorance of their existence probably.
Unless i am quite confused, supposedly, because the interaction between the microkernel and the OS is somewhat abstract, you ought to be able to replace the microkernel with a better one as long as the interface is the same. Is there any reason a better microkernel with the same software-side interface as Mach could not be written, and used to replace mach?
Yes you could. But then you'd just have Mach.
someone once told me that Mach has the ability to host multiple kernels on the same machine at the same time. Is this true? How does that work in terms of sharing the hardware? How do you go about doing this?
Yes that's true, but not in the way you're thinking. Both kernels don't run as kernels at the same time. A well-engineered u-kernel is so thin and provides such a minimal interface to the hardware, that by just slightly modifying Linux(or other kernel) you can get it to run on top of the u-kernel like any other application, and it could do everything that Linux does running on the bare hardware. See L4Linux, MkLinux, Darwin/MacOS X and even this xMach project as examples. The key to good performance is to provide as small a u-kernel with as minimal an interface as feasible to avoid performance problems. It will never run as fast as on bare hardware, but you can get pretty damn close.
I am just thinking that at this point, it would be an utterly useless but nifty parlor trick to try to get Mac OS X/Darwin, MkLinux, xMach and HURD running off the same mach microkernel on the same machine at the same time.
Not so useless as you might think. The problem with any new operating system or kernel is software. There's nothing written for it yet. But what if you could run the Linux kernel on top of your new OS? You'd have near instant access to whatever drivers and applications are currently available for Linux without any porting effort! (except for the initial Linux port) Then you can have a complete system and start writing native drivers for what you need.
-----
"Goose... Geese... Moose... MOOSE!?!?!" -
Re:Judge language by thickness of its first book.
int* pi = malloc(sizeof(int));
That's an illegal C++ statement!
It's technically not legal in C either, but compilers accept it since they assume they know what the programmer meant.
int* pi = (int*)malloc(sizeof(int));
Now, that C++-version is legal C, but it is *poorly written* C code. Any C programmer worth his salt would frown on a program littered with such statements.
What are you talking about? That's perfect code. You should always cast your return values to the approriate type. It enforces type checking. Doing otherwise can be dangerous. Anyone not doing it should be immediately shot. Perhaps you should check out the Ten Commandments for C Programmers. Specifically, commandment 3 and 4. Malloc is a library function which returns a (void *). That is an illegal pointer to dereference, modify or use in any meaningful way. You have to cast it to use it.
Most modern compilers often just do it for you, but assuming a compiler will do it for you reduces portability. Also, subtle bugs can appear since the compiler has to interpret what you meant. This case is pretty clear what the intention is, but more complicates situations are sure to come up where the compiler will guess wrong and you'll be sitting there scratching your head wondering why your program is segfaulting.
-----
"Goose... Geese... Moose... MOOSE!?!?!" -
Re:But he doesnt follow his own advice
-
Re:But he doesnt follow his own advice
-
There are better projects in the pipeline
Others have mentioned MkLinux, which is a version of Linux which runs on top of the Mach microkernel. By modern standards, Mach isn't so "micro". On my Hurd partition, the gnumach executable weighs in at 726kb compressed, and about 1.6Mb uncompressed. Compare with ntoskrnl.exe, which is 907kb on NT 4.0 enterprise server. Both of these are comparable with the size of an average linux or BSD monolithic kernel, which sit around the megabyte mark uncompressed.
The QNX kernel, on the other hand, is something like 8kb in size, which fits in the cache of a 486. Even the BeOS kernel is only something like 78kb compressed. Not that size is the only concern (so my wife keeps telling me), but in general, the less code that runs in the kernel, the easier it is to say something about how secure it is. Also the easier it is to change things while the system is running.
I hate to sound like Andrew Tanenbaum, but MkLinux and the Hurd are now obsolete too. Mach belongs to the old school of microkernels which were popular 10-15 years ago, but with the benefit of hindsight, we know better. Nowadays, for example, we know that you don't even need to do VM swapping inside the kernel.
There are some projects of note which may result in a product which is cleaner and better designed than Linux. Here are some suggestions:
- chaos, which has a very clean, pragmatic design without sacrificing its microkernel philosophy
- VSTa, which is loosely based on Plan9 and QNX
- There's one out there somewhere which is an Open Source re-implementation of L4. Can anyone provide a link?
- Or you could always roll your own...
-
Re:Plan 9 (Somewhat tangential)VSTa is a plan9ish system that is under development(not much at the moment) and released under GPL. Take a look at the homepage. I think that kind of system is the future in distributed computing.