Mona OS is a Japanese OS in C++ (screenshot). At a present stage, although it still is not at a practical use stage, it is continuing to evolving fast.
Mona OS ver.0.2.0RC1 released
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
(^-^)b good job
Here is the about page after Babelfish:
http://babelfish.altavista.com/babelfish/trurl_pagecontent?url=http…
A new Minix based OS that is a microkernel in C++ . . . .
At least they seem to be making more progress then the HURD, I guess.
Mmm, too bad their site is in Japanese– I certainly hope the attention they will get via OSNews.com enables them to maybe do an English version.
After reading the Babelfish page it became obvious to me it’s a microkernel operating syste– great news, since somehow I tend to prefer microkernel/microkernel-like operating systems (QNX Neutrino RTOS, BeOS, OS X). And of course the fact that they use yellow tabs makes it cool already
.
Bookmarked!
For the record, OS X isn’t anything like a microkernel. It just takes the Mach microkernel code and uses it as a monolithic kernel. All services still run in kernel space, and message passing is replaced with function calls.
I know, that’s why I specifically added the “microkernel-based”.
BeOS doesn’t either use a microkernel in the strict definition from Tannenbaum. It uses a microkernel (nukernel), but runs other things (fsil, drivers) in kernel space either.
Again, I didn’t say microkernel-like for nothing
.
very nice BeOSish GUI
I mean, it was a good thing in theory, but had really poor performance.
very nice. very nice indeed.
i’d stay away from the beos gui, but i’m sure they have plenty of other things to worry about right now.
I mean, it was a good thing in theory, but had really poor performance.
Try the QNX Neutrino RTOS. It’s a true microkernel operating system. And yes, performance is extremely good on Neutrino.
Whats wrong with the beos gui?
not to start a flame. just curious
C++ (cool!), graphically interfaced, MIT licenced, nice English sourcecode…
have a look!
http://sourceforge.jp/projects/mona
I think if the mona can become a viable MyPetDesktopOS next to Syllable/AtheOS.
_cies
anyone know how to start up that gui? as far as I can tell theres only 7 demo apps plus the kernel, 4 servers and a sample.txt on the floppy image.
Where does it say it’s a minix based kernel??
“Where does it say it’s a minix based kernel??”
i havent read the article yet. but im assuming they mean minix like in design “microkernel” opposed to Monolithic kernel design
QNX does.
I can think of two big problems with microkernels:
1 – The message passing means they’re asynchronous by nature, so posix system calls (wich are synchronous by nature) can’t be implemented with decent performance.
2 – Context switching is very expensive with microkernel on some cpu architectures (like x86).
In Venice “mona” is a “hidden” female body part…
Copying the BeOS gui isn’t all bad,as long as one tries to copy the slickness of it as well.I mean there’s been tons of projects that pretty much copy the Win9X look.NewDeal,the early SkyOS, and some various X window managers come to mind.Although myself ,I was never a big fan of the yellow tabs and was extremely happy to get WindowShade up and running on my BeOS box,to me the slickness and responsiveness of the BeOS interface has yet to be surpassed!And on that note I am hoping a project like this one would rememnber that and try to grab the slickness and ease of use of the BeOS UI over and above the look of it after all there are BeOS themes for KDE,but underneath all it’s still slow old Klunkey KDE
And they have an mini animated Kukuri! Haha!
helf: type startgui (it tells you when it boots) There seems to be more than 7 progs, haven’t counted though.
There is another GUI, classic Mac-style. You can execute that with: /servers/baygui.ex5
Easy way to try this little OS is get the download Qemu download on their SF page, and run MonaStart.bat.
Debman wrote:
I mean, it was a good thing in theory, but had really poor performance.
That depends on your definition of “performance”. I have noticed that the GUI in QNX can be quite slow if you don’t have a 100% supported video card. Forgive me if I am wrong, but I can only assume that this is the “performance” issue you are speaking of. With a supported video card, I have acheived GUI responsiveness that far surpasses Linux and Windows, and even approaches the slick feel of BeOS.
Keep in mind also that most commercial uses of QNX are GUI-less; i.e. the OS drives proprietary hardware that is almost always headless (no keyboard or monitor). It is here that the performance, and just as importantly, the reliability, of the microkernel design come into play.
I read in the Linus Torvalds biography that Windows NT runs a micro kernel. That may have changed though.
Linus’ opinion of micro kernels by the way is this:
Micro kernels simplify each process so that it’s easy to understand. But people ignore the fact that the interprocess handling is insane when everything’s broken down that far. So basically the simplicity is false.
One that is available is Tru64 which is based on Mach 2.5 IIRC; regarding Windows NT, *very* early on it was a strict micro kernel, but then Microsoft compromised realising that the performance penalty of running it on a 486 processor wasn’t worth the effort – mind you, however, as Paul (http://www.wininformant.com) pointed out, Windows NT asn’t originally designed for the x86 – so one *could* assume that the whole issue of contexual switching wasn’t an issue as the architecture they were targeting, IIRC a RISC based CPU Intel had in development, wouldn’t have had those problems.
IMO there is no pure microkernel in commercial run nowadays.
Most of them are compromise between pure mkernel and monolithic one, which provides much flexibility of mkernel and yet keep time critical sections efficient.
May be when dual core cpu comes to mainstream and things will change. Time will tell.
I have noticed that the GUI in QNX can be quite slow if you don’t have a 100% supported video card.
Thats because if the vid card is not supported it is running in vesa mode which is inherently slow on *any* OS. Try running windows (xp seems to be the only that supports vesa be default if drivers arent present..), any linux distro, beos etc in VESA mode. they will be slooow moving windows around and such.
aha, i seem to have downloaded an older version by mistake
>Thats because if the vid card is not supported it is running in vesa mode which is inherently slow on *any* OS.
Maybe you should try AROS then… VESA isn’t slow here.
Leo.
helf: i wasn’t trying to start a flame either.
basically, i’m pretty tired of everyone trying to emulate the _look_ of a gui and not necessarily the functionality. like sasquatch666 said, “…I am hoping a project like this one would rememnber that and try to grab the slickness and ease of use of the BeOS UI over and above the look of it after all there are BeOS themes for KDE,but underneath all it’s still slow old Klunkey KDE.”
so if they can keep the graphics layer snappy, slick, and responsive, i’d be a happy camper.
beyond that, i’m just not a fan of the yellow tabs… but that’s a personal preference.
what i’d really love to see is a “new” gui, built from the ground-up as well. i mean, they’re taking the trouble to do so much already… why not why not rethink how the user interacts with their computer. keep in mind, a gui is not just the window decoration and widgets. the user interface, generally speaking, is oddly the most overlooked aspect of most os’s today; it seems like all anyone cares about is eye candy for the sake of eye candy. that’s rather unfortunate.
helf wrote:
Thats because if the vid card is not supported it is running in vesa mode which is inherently slow on *any* OS. Try running windows (xp seems to be the only that supports vesa be default if drivers arent present..), any linux distro, beos etc in VESA mode. they will be slooow moving windows around and such.
That is very true, but not exactly the point of my post. Basically, I was saying that it is the *perception* of slowness that most people thow in the face of QNX, when it was never really designed to be a desktop OS. To realize the advantages of the microkernel architecture, you have to get under the hood, so to speak.
At the opposite end of the spectrum, you have BeOS, which is not really a microkernel, but is designed around a similar principle. BeOS was designed from the ground up to be a desktop OS, and is lightning-fast both visually and behind the scenes. Native file searching is second to none, programs compile quickly, etc. The only problem I’ve ever had with BeOS is the lack of hardware support, but that’s no one’s fault. They went out of business before they could get big enough to make that happen.
In other words GUI speed, VESA or no VESA, is practically irrelevant in QNX, unless for some reason you are using it to run a GUI-driven machine. In that case, you will most likely develop your own optimized video driver anyway. Either way, you reap all of the the benefits of a microkernel with a familiar development environment.
Disclaimer: No, I don’t work for QNX. But I hope to someday use their OS to run the pet project floating around in the back of my mind.
“The message passing means they’re asynchronous by nature, so posix system calls (wich are synchronous by nature) can’t be implemented with decent performance.”
A lot of SASOS, microkernel and microkernel-like systems provide synchronous IPC by allowing threads to migrate from one process/address space into another in a controlled manner. This is a bit like how the “far call” mechanism in segmented systems allows a thread to call into different segments.
Usually there will be a stack already allocate in the destination process for the thread to use for the duration of the transfer. Variations allow the destination stack to allocated on-demand or when the client explicitly opens a connection to the server.
In some paper by B Bershad (IIRC) it was called LRPC for Lightweight RPC. In Mach they’re called Migrating Threads. Sun’s Spring Nucleus (and Solaris) have their Doors mechanism. The Mungi SASOS has PDX Protected Procedure Call. Pebble, Opal and Nemesis also have some form of migrating threads. Windows NT (and maybe WinCE/PocketPC)
has LPC.
The terminology related to the threads used by these OSs is sometimes different. For example, Mach calls the whole Thread that spans multiple processes a Thread and the individual sections in each address space are called Activations. Spring on the other hand calls a section in each address space a Thread and the top part a Shuttle.
These servers that threads can migrate into are sometimes called, “Protected Shared Libraries,” though I’ve read that WinCE has something similar but calls them ”
“Evolving Mach 3.0 to a Migrating Thread Model”, “Microkernels should support Passive Objects” and the various papers on the OSs mentioned above are worth reading.
Most of the papers can be downloaded from CiteSeer.
Oops, missed out a bit…
These servers that threads can migrate into are sometimes called, “Protected Shared Libraries,” though I’ve read that WinCE/PocketPC has something similar but calls them “Protected Server Libraries” or PSLs for short.
That is very true, but not exactly the point of my post. Basically, I was saying that it is the *perception* of slowness that most people thow in the face of QNX, when it was never really designed to be a desktop OS. To realize the advantages of the microkernel architecture, you have to get under the hood, so to speak.
The Neutrino RTOS is one of my favourite operating systems– and a few days ago I (finally) upgraded from 6.2.1 to 6.3.0.
I tend to disagree with what you call “the perception of slowness”. Of course we are talking feelings here and therefore discussing it does not make any sense. But I just wanted to add here that I disagree with the so-called slowness of Neutrino/PhotonUI. And since I’m one of those remaining BeOS fans, I do know what a fast and responsive UI is. For me, it’s like this, from fast to slow (all based on my feelings/perceptions, not on actual benchmarks):
BeOS/Zeta – large gap
– QNX Neutrino RTOS – SkyOS – Mac OS X (my main OS) – Windows 2000/XP/2003 – Linux with X.org – others.
As you can see, it are the microkernel/microkernel-like operating systems in the lead for me (with the exception of SkyOS).
L4´s kernels like Pistacho and Fiasco are synchronous.
Interesting look, while it may never approach the original for speed at least they decided to do something other than yet another Windows 95 clone for their GUI. I’ve always liked the beOS look as it attempts to give only that interface that you need, and no more. Much better than the big eye candy rich modern UI’s, particually the horror that is the current alpha mock-ups of Longhorns UI.
All OS’s should have good software titles, which is why I am really glad to see that the Mona OS already has ObeseCat 1.0 running in a stable fashion.
I was actually referring to others’ perception of slowness in QNX/Photon, not my own. I personally find it very fast and responsive; of course, I run it on fully supported hardware. My beef is that it seems that many people who say QNX is “slow” are describing the GUI alone, and are not realizing the speed of the underlying system.
Oh, and I agree 100% with your fast-to-slow comparison, although I like to put OS/2 as tied for second with QNX Neutrino.