Bill Hayden released version 0.7rc3 of the AtheOS fork, Cosmoe, today. The changes from 0.6 are almost too extensive, since libcosmoe was almost rewritten from scratch based on code from OBOS.
Cosmoe 0.7rc3 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
Looking at the changelog, I was disappointed to see the DirectFB support fall by the wayside, especially given the fact that the FAQ lists the standard framebuffer interface under Linux as one of the primary motivating factors in choosing that kernel.
Really, with DirectFB (hopefully with a higher-level GUI library than Gtk layered on top), XFS (and its support for arbitrary-length user and system-provided rich metadata on files), and the new scheduler tweaks designed to improve SMP and interactive (read: media) system performance, Linux has almost caught back up with BeOS at the infrastructure level.
In the meantime, of course, I’ll keep bouncing back and forth between Linux, NetBSD, and BeOS, until one jumps forward again and convinces me to stick around for a while.
Without DirectFB, does that mean it will be portable to other Unix-like OSes? Isn’t that the main reason it had to be used with Linux.
Bill Hayden released version 0.7rc3 of the AtheOS fork, Cosmoe, today.
AtheOS fork? Isn’t that Syllable???
No. It is AtheOS.
Cosmoe was a fork before Syllable. If I remember it was actually a fork when Atheos itself was still being developed.
Syllable is a complete OS. Cosmoe is built on top of the Linux Kernel.
“AtheOS fork? Isn’t that Syllable???”
Well, as far as I understand the word “fork”, it means *multiple* path going in different directions, all coming from one single origin. In this case, AtheOS.
“Without DirectFB, does that mean it will be portable to other Unix-like OSes?”
Along those lines – and slightly off topic – what makes one OS portable (ex. NETBSD), while another is not? (ex. Windows(?)) In other words, what are the requirements for portability?
Without DirectFB, it’s not going to be very responsive. Too bad. Cosmoe really has some potential. I still think everyone should have jumped on the cosmoe bandwagon as the new opensource beos replacement.
AFAIK Cosmoe is a one man project so far…
If I new anything about coding, I would be right there helping out. But I’m just a manager in the technology industry, so I don’t have a lot to contribute.
Portability used to be an enormous stumbling block for application programs, let alone operating systems. Everything was in assembly or machine language. These are of neccessity dependent on the processor architecture. After the shift to higher level languages, much of the application program portability problems went away. But an operating system by its very nature has to speak pretty directly to the hardware. You can’t not have SOME problem.
Unix was the first highly portable operating system. When it came out there were very few OS written in HL – GE’s Multics (PL/I) and Burroughs’ MCP (Algol).
It’s worth noting that until somewhere in MacOS System 8.x (I think) there were critical sections of code deep in the operating system written in 68k assembly for which your PowerPC-based Mac had to run emulation.
Even if you’ve written your OS almost completely in a higher level language, here are a few potential stumbling blocks:
1) Endianness: In what order are your bytes stored?
2) Bitness: What happens when your pointers are suddenly 64bit instead of 32bit? Or even a non-power of two — there are still lots of 36bit systems in production use. How about native integer or word sizes? The more things your OS assumes, the worse off you’ll be.
3) Dependencies on “special features” implemented in the hardware of your source system. For example, a reason Multics was never ported anywhere was its native hardware’s support of eight privilege levels.
4) Does your OS depend on an MMU? Many embedded systems are without one.
5) Do your stacks grow up? Or down?
6) What’s the native character set — EBCIDIC? ASCII? Baudot?
You are referring to a different kind of portability. There are two: Hardware portability and OS portability. Assembly/machine language is highly OS-portable, but not HW-portable. High-level code is significantly more HW-portable than it is OS-portable.
what makes one OS portable (ex. NETBSD), while another is not? (ex. Windows(?))
ah, but the winNT(and CE/PocketPC) line is portable. there just wasn’t a large enough demand for it on the other platforms, so MS kind of let the ports go. NT ran on MIPS, Alpha and PowerPC(not Mac) back in the day. when w2k came around it was only x86, Alpha and IA64. Haven’t seen an alpha port since XP/w2k3 came around, so maybe it’s dead. I guess the same thing happened with the Solaris PowerPC port way back when, lack of interest.
win9x probably wasn’t worth the effort, too much x86 assembly and lack of interest to make it worthwhile.
Are they not duplicated efforts? Where do they differ since Cosmoe now using OBOS components?
Ooops, sorry, what i was trying to say was that i didn’t know cosmoe was an atheos fork like syllable. (I still don’t get it, doesn’t it use a linux kernel?), anyway sorry for my bad engrish
As for direcfb portability, i think directfb can also use sdl instead of the framebuffer device, so it’s (i guess) possible to port it to anything with sdl (freebsd, windows etc.)
There was a thread on the directfb mailing list about that:
http://www.directfb.org/mailinglists/directfb-dev/2002/09-2002/msg0…
It’s confusing…. Should it be a penguin because of the linux kernel? Should it get an atheos icon for the appserver code? Should it get a beos icon because for the comitment to beunited, source-compatibility, and changes to a beos style api? What about the fact that it’s supposed to be source-compatibil with Carbon apps?
I think it should have it’s own icon. Like a Franken-icon that has pieces of all the other logos stitched together.
Someone should do that…
So are these two projects trying to achieve similar goals? Yes or No.
Does anyone know?
Get a copy of the FreeDOS Kernel book – it should be available at one of the internet’s book retailers – and check out what the author, Pat Villani, has to say about where FreeDOS was before it became FreeDOS.
If FreeDOS, while it was NSS-DOS and DOS/NT, could provide a DOS-compatible API on MC68K, then Microsoft was slacking off with their decision not to try. After all, you have a 32-bit API that’s portable – or at least the WinNT 3.1 I’ve saved from the tip/rubbish dump exists in all the appropriate variants.
Laziness is its own reward/punishment.
>>It’s worth noting that until somewhere in MacOS System 8.x (I think) there were critical sections of code deep in the operating system written in 68k assembly for which your PowerPC-based Mac had to run emulation. <<
Um, no, I think you’ll find that was 7.X. The 8.X series was the first native PPC MacOS.