It doesn't matter much how you view this. Nation-wide State enforced censorship (being it what is made in China, in India or even in the US) is something that does not look like very democratic.
So where do you draw the line? When can we stop calling India the biggest democracy in the world? Should we really do that or this is nothing compared to anywhere else in the world?
Hmmmm, no, you don't. It does not really matter in what language it has been written as long as the calling conventions and the interfaces are the same and, of course, the driver manages to resolves all the symbols it depends on. In the end, it is all x86 ASM anyway. All you really need is a wrapper that loads the drivers, exports all the stuff the driver itself need and provides the interface the OS need.
Being RT means it has predictable response times. If some specific operation is said to take 10 ms to complete you can count that as being always true and this is what makes RT systems special. That's why it would be *VERY* difficult to have a "partial" RT system like what you decribe. Either it is RT or it is not.
That said, recently we had some flexibility on the Rt definition and we ended up with definitions for systems that are "hard RT" and "soft RT". The first case is what I described (QNX is hard RT, for instance). The second one is a system that provides extremelly low latency times but they are not really predictable, although the average time is (BeOS - now Zeta - is said to be soft RT).
Really, you should not be trying this on a production environment. Anyway, there are some issues that we discovered that will be worked on and as soon as I can reliably boot using it on my computer I will make a compiled package and put it up somewhere with instructions on how to install/uninstall it.
Let me clarify that (and I really have to change that text on the page). Once upon a time there was the start of an OpenBFS team. They *WOULD* be using the Linux BFS code as a reference (with the author permission, AFAIK) but they actually never wrote one single line of code. Eventually me and Axel ttook over the OpenBFS team and ended up basing the code on Axel's previous work on the BFS Recovery Tools package.
In other words, no code has been used from that Linux driver.
Believe-me, it is not just Linus. C++ in the kernel is really a sensitive matter but it *CAN* be used if you know what you're doing. Basically, no exceptions and no pure-virtual methods.
Binary compatibility is not really set in stone yet. Doing that would imply, for instance, that we would be locked out from using GCC 3.0 (at least without huge hacks). If I was the one making the call, I would say forget about binary compatibility. But I am not.
I happen to partially agree with that. It is pretty obvious BeOS won't get developed further (although my BeOS is still working... Not only here at home but at work too).
Although OpenBeOS is based in the BeOS spirit (and APIs), it *IS NOT* BeOS. It is a new OS and is being developed as such, including with a completelly new modern kernel (NewOS), thanks to Travis.
Just a small correction. Right now we have write support working and files and directories can be created. Growing a file only works for the direct range (that means we didn't even touch the indirect and double indirect range yet). Also, we don't have any journaling in place yet, but we do have a transaction class that *IS* being used (only that it just writes the blocks directly to disk right now without any journaling).
Slashdot Mirror
The fact that at only few years ago you could not include Linux (and even MacOS) in this list actually serves as an answer to your question.
It doesn't matter much how you view this. Nation-wide State enforced censorship (being it what is made in China, in India or even in the US) is something that does not look like very democratic.
So where do you draw the line? When can we stop calling India the biggest democracy in the world? Should we really do that or this is nothing compared to anywhere else in the world?
Hmmmm, no, you don't. It does not really matter in what language it has been written as long as the calling conventions and the interfaces are the same and, of course, the driver manages to resolves all the symbols it depends on. In the end, it is all x86 ASM anyway. All you really need is a wrapper that loads the drivers, exports all the stuff the driver itself need and provides the interface the OS need.
Being RT means it has predictable response times. If some specific operation is said to take 10 ms to complete you can count that as being always true and this is what makes RT systems special. That's why it would be *VERY* difficult to have a "partial" RT system like what you decribe. Either it is RT or it is not.
That said, recently we had some flexibility on the Rt definition and we ended up with definitions for systems that are "hard RT" and "soft RT". The first case is what I described (QNX is hard RT, for instance). The second one is a system that provides extremelly low latency times but they are not really predictable, although the average time is (BeOS - now Zeta - is said to be soft RT).
How about Galactic Civilizations?
http://www.galciv.com/
There is even a sequel being produced:
http://www.galciv2.com/
Really, you should not be trying this on a production environment. Anyway, there are some issues that we discovered that will be worked on and as soon as I can reliably boot using it on my computer I will make a compiled package and put it up somewhere with instructions on how to install/uninstall it.
Let me clarify that (and I really have to change that text on the page). Once upon a time there was the start of an OpenBFS team. They *WOULD* be using the Linux BFS code as a reference (with the author permission, AFAIK) but they actually never wrote one single line of code. Eventually me and Axel ttook over the OpenBFS team and ended up basing the code on Axel's previous work on the BFS Recovery Tools package.
In other words, no code has been used from that Linux driver.
-Bruno
Believe-me, it is not just Linus. C++ in the kernel is really a sensitive matter but it *CAN* be used if you know what you're doing. Basically, no exceptions and no pure-virtual methods.
-Bruno
Binary compatibility is not really set in stone yet. Doing that would imply, for instance, that we would be locked out from using GCC 3.0 (at least without huge hacks). If I was the one making the call, I would say forget about binary compatibility. But I am not.
I happen to partially agree with that. It is pretty obvious BeOS won't get developed further (although my BeOS is still working... Not only here at home but at work too).
Although OpenBeOS is based in the BeOS spirit (and APIs), it *IS NOT* BeOS. It is a new OS and is being developed as such, including with a completelly new modern kernel (NewOS), thanks to Travis.
Just a small correction. Right now we have write support working and files and directories can be created. Growing a file only works for the direct range (that means we didn't even touch the indirect and double indirect range yet). Also, we don't have any journaling in place yet, but we do have a transaction class that *IS* being used (only that it just writes the blocks directly to disk right now without any journaling).