One and a half months ago, we were among the first to report about an operating system which would combine the strengths of Linux & AtheOS and that would breath a new kind of life back to BeOS. Today, we are happy to host an exclusive interview with the architect of the combined OS, Bill Hayden. Dubbed “Cosmoe“, the OS not only will feature support for the AtheOS, Linux and BeOS APIs, but also for… Macintosh’s Carbon! Read on for more surprises!1. What is the current status of Cosmoe?
Bill Hayden: Cosmoe is nearing the stage where I would feel comfortable doing a preliminary release aimed at developers. The entire BeOS and MacOS API has not been completed, naturally, but the low fruit (and some of the harder ones) have been picked.
2. What kind of BeOS applications can be easily recompiled for Cosmoe?
Bill Hayden: Really small ones! 🙂
Gobe won’t be compiling their office suite on Cosmoe this month. My tests have involved taking existing BeOS source code from BeBits and seeing if it will compile. Very few will compile with absolutely no changes, but with only minor changes I compiled Pulse, BeCalc, and a few others small utilities. Obviously the big victory would be success with Deskbar and Tracker. Trying to compile those two apps are what is currently molding and improving Cosmoe into a better OS.
Currently, differences remain in certain areas of the native API versus the BeOS API which make some things, even common things, not port correctly. The goal, of course, is to isolate and fix these differences.
3. Did you write the Carbon API wrapper from scratch? What is its status?
Bill Hayden: Yes, I wrote it from scratch starting well before Cosmoe was even a dream. I had wanted to port some existing MacOS programs of mine to BeOS several years ago. Carbon was just coming out, and it looked like the future of MacOS programming, so I used it as the basis of the port.
Its status is much like the BeOS API status: the easy stuff is done, but there is much hard stuff left to do.
4. Did you find Carbon or the BeOS API more difficult to wrap around Linux/AtheOS? Please tell us about the porting difficulties you encountered so far.
Bill Hayden: Carbon is probably a bit harder to wrap since it’s procedural. The Atheos and BeOS APIs were sufficiently similar that it made the port rather straightforward. That doesn’t mean it was easy, just that you knew exactly what you had to do next.
5. How are you going to solve the problem of the not-too-many graphics drivers for the Linux framebuffer? Are you going to create another gfx driver API or use the Linux framefuffer one?
Bill Hayden: This is probably best answered by my response to question 4.
6. The AtheOS graphics engine does not support many modern goodies, like doublebuffering, MTRR support for faster 2D and VESA drivers, non-rectangle windows, and its GUI layout and widgets are rather aging and not well done (aesthetically-speaking). Has any work been done for this yet?
Bill Hayden: Not much has been done here, since my goal is to get the API done first. That doesn’t mean that I don’t have big plans, though. The GUI does in fact need a major sprucing-up, and the graphics engine will be completely overhauled before it’s done. It’s too slow and too ugly for my taste, and it must change for Cosmoe to be a viable OS. Cosmoe uses the Linux framebuffer at the moment, but the short term plan is to pick up acceleration by going with DirectFB, and the long term plan is to wrap the XFree86 driver plug-in architecture. Please understand that the previous sentence does NOT mean that I will be using XFree86 as the engine (shudder), just that Cosmoe will leverage XFree86’s existing drivers to drive Cosmoe’s graphics engine.
7. Are you going to use stock kernels, or are you going the Gentoo way, where several patches for speed have been incorporated? Which Linux distro do you use for development?
Bill Hayden: Stock kernels will be the norm for some time. Cosmoe is a one-man show until the community gets involved, and there is only so much I can do and still release something this year. 🙂 I’m sure my wife and family would like to see me occasionally too.
8. Gentoo, except the fact that it uses custom kernel, it also compiles the software against a particular architecture (especially fast if compiled with GCC 3.x). Is Cosmoe going to offer such targetted binaries, optimized for speed?
Bill Hayden: Not in this release. See #7.
9. In addition to BeOS and Carbon APIs, does Cosmoe have its own native API? Is this an API derived from AtheOS, Linux or was it developed from scratch? Is it C or C++?
Bill Hayden: Good question. Yes, Cosmoe has it’s own native API. The BeOS API is implemented as a compatibility wrapper around the native Cosmoe API. When you say “wrapper”, people think “slow”, but that is not the case here. The wrapping is done at compile time, so you get the full speed of the native API without thunking overhead or anything else. The Carbon API is implemented using the BeOS API. The native Cosmoe API is a significantly reworked derivative of the Atheos API, which is done in C++. Confused yet?
By the way, Atheos apps can be recompiled for Cosmoe in a matter of minutes.
10. BeOS has a pretty unique filesystem. Which Linux filesystem do you use for Cosmoe? (XFS seems to be the closest relative to BFS) Does BFS wrap around it well? Do the BeOS “live queries” work?
Bill Hayden: This may come as a letdown to the idealists, but Cosmoe does not implement BFS nor use some of its more advanced features. Live queries are not even on the roadmap at this stage of the game. Cosmoe works on any of the standard filesystems available for Linux.
11. You are certainly combining a lot of different technologies and APIs on Cosmoe. Are you also going to include XFree with KDE/Gnome/etc and WINE on a basic stock Cosmoe distribution?
Bill Hayden: No, I do not plan on providing XFree86 with a stock Cosmoe distribution. There would be nothing to prevent someone from adding it though, and having Cosmoe and XFree86 on different virtual terminals. WINE offers interchangeable front-ends, so I’ve considered writing a WINE front-end for Cosmoe. That’s more work than I want to tackle at the moment, and there are more important things to work on first.
…the web page isn’t a reflection on how the GUI will look.
It’s hideous!
I actually find the design for this page interesting. Sure, a bit more work should have been done in the fonts faces and font colors and also I would use tables instead of frames, but I find the page “interesting” in a pretty… weird sense of the word.
sounds great!
“Please understand that the previous sentence does NOT mean that I will be using XFree86 as the engine (shudder)…”
That sounds very wise!
This looks like one of the most promising new os’s to come along in some time, if he can only pull it off. As it sits on top of Linux, which is already popular, perhaps a more incremental approach to innovation will succeed where BEOS didn”t
A new BlueEyedOS under GPL licence?
new duplicated work, more time spent… I love that
Regards,
Guillaume
it would be a boon for many other alternative OSes, at least in the concept if not in the actualy Driver interface.
I mean snaging the XF86 drivers and throwing them into a diffrent Display engine is a realy cool thing to do.
now, if he can just get a translation wraper for the XF86 system calls for his display enguine and he will have so many apps that he willnot know what to do with them all….he might even get all the Linux distros off of X and on to his display system.
With so many GUI APIs it does make sence to use an unified decorator API. This is valid for KDE/Gnome too.
All effort to bring OSS OS’es together is nice. United they will be stronger, and reduce duplications of work. The more experimentations with different APIs and the more merging of OSS code, the easier it will be to combine code, port code and just grow.
I also like the combination of different licenses, it suggests that this Bill probably has chosen the best license for every part. Ie making the native Cosmoe API LGPL makes it possible for properiary OS’es to include it, and might therefore extend the developer base for Cosmoe API in the long run (provided it is/will be a good one).
While at the same time having the app_server GPL’ed prevents others from making use of the code for handling apps, and at the same time makes all code changes available for Bill to include in Cosmoe app_server in case he wants to.
According to FAQ he also seems positive to community co-operation in development. Hopefully this will draw developers, and hopefully projects like Cosmoe, AtheOS, OBOS and BlueEyedOS will discuss directions of their projects, goals, APIs, compatiblity etc
The OSS model has worked well on servers – let’s see what it can do for the desktop now when it’s starting to take form.
> A new BlueEyedOS under GPL licence?
No, Cosmoe is not the same as BlueEyedOS/BlueOS. It does not use XFree, it does not use the backend stuff of BeOS, it does not wrap the Be filesystem or kernel calls etc. etc.
Cosmoe simply ports a large chunk of many different APIs (Be API, Carbon, AtheOS) on top of the Linux kernel.
However, by not wrapping the Be filesystem, Tracker and Deskbar will not work as they work under BeOS. No Live Queries will work (needed by BeMail, NetPositive bookmarks, Tracker Queries, Deskbar add-ons etc etc) which means that the OpenTracker functionality will be troublesome and not complete. If Cosmoe is not going to use ReiserFS, XFS, JFS or ext3, no attributes will be supported either. And at the end of the day, these are the things that made a BeOS, BeOS.
However, by not wrapping the Be filesystem, Tracker and Deskbar will not work as they work under BeOS. No Live Queries will work (needed by BeMail, NetPositive bookmarks, Tracker Queries, Deskbar add-ons etc etc) which means that the OpenTracker functionality will be troublesome and not complete.
But he did say it would support any of the native Linux filesystems. Maybe this is a cue for some enterprising soul to implement the Be filesystem in the standard Linux kernel?
I also like the combination of different licenses, it suggests that this Bill probably has chosen the best license for every part. Ie making the native Cosmoe API LGPL makes it possible for properiary OS’es to include it, and might therefore extend the developer base for Cosmoe API in the long run (provided it is/will be a good one).
While at the same time having the app_server GPL’ed prevents others from making use of the code for handling apps, and at the same time makes all code changes available for Bill to include in Cosmoe app_server in case he wants to.
Bill had no choice in the licencses he has used. Linux & the AtheOS appserver are under the GPL, hence the Cosmoe appserver is under the GPL. libatheos is under the LGPL, hence libcosmoe is under the LGPL. Tracker etc. are under a BSD like licencse, hence…you get the picture.
By the way, Atheos apps can be recompiled for Cosmoe in a matter of minutes.
<href=http://www.shagged.org/~vanders/mercury.shtml>Not all of them can be, unless you’re doing something very clever to emulate file attributes. According to the interview, you’re not supporting anything like that. Besides which, you’d also have to emulate the full AtheOS kernel API as well.
I don’t mind the fact that you have used parts of AtheOS to build Cosmoe, more power to you in fact, but can we get over the fad of trying to paint Cosmoe as some sort of “super-AtheOS” please? I’m sure you wouldn’t like it if Linux users started describing Cosmoe as some sort of “Linux distro”, would you?
I’m going to stop moaning now
Being a atheos junkie, I have to say that at first I didn’t like this fork, but props go out to Bill Hayden. You are doing a great job. That doesn’t mean I am giving up working on AtheOs, but it does look like I am going to make room for another os
. By the way, I have got some major work done on the desktop, and I am going to work on icons very soon 
.
actualy, you can include BSDLed code in a larger project that is under antoher licence if you want, all you have to do is keep the header of the code file intact.
don’t believe me? MS uses the BSD TCP/IP stack.
Cosmoe uses the Linux kernel, so by definition it is a Linux distrobution.
OHHHHHHH
you mean that it is not a GNU/Linux Operating system distrobution.
When will be able to get screenshots?
And when will it be available for download?
Adam
> When will be able to get screenshots?
I asked for screenshots of course, but Bill told me that the GUI looks exactly like the AtheOS one, for the time being. If you have seen the AtheOS one, you have seen Cosmoe, he said. I think it is subject to a change though.
Someone really should make a simple X client that runs (preferably invisible) under the Cosmoe GUI. This way you could have a Xserver running in the background and just fire up X apps directly (kind of like MacOS 9 compatiblity server in MacOSX if I understand the concept right).
With such a feature any Linux user could start using Cosmoe at once, still being able to run all the old apps until new GUI-native ones arrive and are being developed.
Do I understand this right?
a) Application developers can build using AtheOS, Carbon, or BeOS API’s, and with minimal work they will run on Cosmoe?
b) Hardware that runs under linux will run under Cosmoe?
c) One step closer to XR11 RIP?
If I got this right, this is very promising indeed. I like the direction you are taking. Well thought out. Thanks for giving new spark and light to the open source community.
>Do I understand this right?
Yes to all.
However, I would still favour the “invisible rootless X” solution Ealm suggests above. It would add more applications to the lot.
What is ment with Linux API?? POSIX?
Why support Carbon? Since OS 9.x is dead now,
alle future development will bei OS X only.
OS X only means Cocoa. I think Apple will drop
the Carbon “compatiblity layer” sooner or later.
So the only benefit in supporting Carbon is that
you can run outdatet software. And… by the way….
its not that simple (= only a recompile) because
Carbon software is written for PPC.
So – why support for 100% a dead API?
How about using the Berlin windowing system for this
project?? http://www.berlin-consortium.org/
While I’m not a user or even a programmer of the
berlin consortium.. But it could be useful since it
kinda works…
Actually, Carbon isn’t what you’d call a deal API. Granted it’s purpose was to help transition from Mac ToolBox to Cocoa, but many newer programs are written in Carbon, so the developer can gain users on both 9 and X.
OS X doesn’t only mean Cocoa. It’s compatible with Carbon.
> So – why support for 100% a dead API? [Carbon]
Carbon would not be dead, even if Apple has shelved MacOS 9. There always going to be developers that want to program in C and C++. Apple can’t dump C/C++ because of these devs, therefore, Carbon will be around for at least a while.
Carbon will be around until they get C and C++ bindings into Cocoa.
I am almost positive that Apple will eventualy make bindings to support these languages, or perhaps a new API to replace Carbon that will be a clean room none legacy API.
All you need is GNUStep…GNUStep is a nearly complete implementation of COcoa…and that’ll work when you get a rootless X running on top of it out of the box…plus it’s designed to use multiple display frontends…so a port to Cosmoe should be quite doable.
ealm, do we really want a new linux flavour to be compatible with Xserver, that’ll surely mean that cosmoe won’t recieve its own generation of programs, and it’ll be stuck in bloaty ol’ x11.
my 2p..
This will be WONDERFUL if we can get rid of X (I am WELL aware this won’t be able to happen for some time of course
!!
Also, I like the idea of using the Linux kernel for now, which isn’t as bad as so many zealots around here like to say. This means that while newer technology is in the works (such as the atheos kernel itself), we get to use Linux, which has a lot more drivers, a better vm system (for now), and a lot of other stuff atheos (or whatever other new open/free kernel) doesn’t have yet, and once another kernel is (relatively) ready, we can begin migrating to that new kernel.
This GUI system must have some portability if one man has managed to do a port to linux and then some (beos and cocoa api stuff).
I read somewhere that it probably wouldn’t be TOO difficult to get network support working with the atheos UI (run desktop apps remotely like X), is this planned? If not, I’ll still prefer to use something other than X.
DirectFB already allows you run X apps “rootlessly” which means you can run X apps through directFB in addition to any directfb apps. I assume that since you intend to work with directfb, we’ll be able to run X apps this way. This question is more for the directfb people… does dri work when running X apps this way? I ask because Linux games tend to be for X and it’d be nice if I didn’t have to switch to an X based UI every time I wanted to play wolfenstein (or whatever other game I’m into when this is ready).
Anyway, I have confidence in this, this guy has pulled off quite a bit on his own it would seem, I’m sure once the word gets out, other developers will begin to contribute!
Berlin? Don’t you mean http://fresco.org ?
Cosmoe has the Carbon API. Use GNUstep (somewhat Cococa compatible) with it and you have an OS mostly compatible to OSX (on source level).
Nice interview, thanks Eugenia!
I meant carbon, not Cocoa..
ealm, do we really want a new linux flavour to be compatible with Xserver, that’ll surely mean that cosmoe won’t
recieve its own generation of programs, and it’ll be stuck in bloaty ol’ x11
It IS already compatible with X, since it IS in fact Linux we’re talking about at OS level. If running X on this Linux flavour means we’ll not get any alternative apps to the X ones (which I highly doubt), it probably also means that people WANT X apps – and in that case I really can’t understand why they will use Cosmoe and not another, regular, flavour of the Linux OS. My opinion is that people should be able to choose what API to write their apps in. My opinion also is that bringing X apps to Cosmoe will make it far more interesting from a user perspective. “Protecting” Cosmoe from X apps is like MS trying to make MS-competetive apps run badly in Windows – let the best solutions survive, don’t freeze anyone playing with fair cards out!
notice :this whole project seems really cool, more power to the programmer!
“ealm, do we really want a new linux flavour to be compatible with Xserver, that’ll surely mean that cosmoe won’t
recieve its own generation of programs, and it’ll be stuck in bloaty ol’ x11”
This reminds me of the os/2 problem. os/2 was a ‘better windows than windows’ a ‘better dos than dos’, so why would developers want to write programs just for os/2 when they could write them for windows and have them run on both?
Mike,
A big difference between Cosmoe and OS/2 is that the OS is not binary compatible on all counts(linux apps aside because of its inherent nature). By just making the OS source compatible, it could (providing a large enough install base) possibly get developers to simply recompile for Cosmoe.
Regards,
Maverick
Wow what a lot of discussion on a project that, to my reading of the webpage, has nothing of real substance. There is no code, no cvs, no docs, no screenshots, nothing. All there is is a long FAQ telling us, why he is proposing this project, why this isn’t BeOS, nor Carbon, nor AtheOS,and how it extends the UI on Linux by killing the red-headed stepchild of Linux (X11). Oh, and the part on how you could possibly make some money by working on this project for him.
From reading the interview Cosmoe sounds less like an Atheos fork and more like a variant of linux that has the Atheos API added in because it’s similar to BeOS’ I think the hype that went around the Atheos mailing list was a little misplaced.
is not a atheos kernal fork, but he did fork the gui apis and whatnot, so its really just a linux distro with a responsive gui and beos/atheos/carbon api wrappers? (not exactly but as close as im gonna get at 2am)
I think you guys are reading way too much into this. The only reason he answered “Good Question” to question 9 was because he had considered it, it seems. While I believe that something like this has certain merit, he’s going to need lots of help.
Carbon will be around until they get C and C++ bindings into Cocoa.
I am almost positive that Apple will eventualy make bindings to support these languages, or perhaps a new API to replace Carbon that will be a clean room none legacy API.
Cocoa already have, C++ bindings (at least Rhapsody had, haven’t checked MacOSX).
Cocoa is supposed to be a “clean room none legacy API”, there is no way to create something as modern and flexible based on the C++ static object model.
opt-out: There IS code, and it will be publicly available as soon as cvs is put up (soon according to Bill).
Mike: A big difference is that OS/2 was a commercial system and lived on sales. Who would buy OS/2 to run Windows apps?
Another important thing is that Cosmoe is getting backing of the OSS community, which IBM never could have.
If new, neat, API’s are brought to linux I don’t have a single seconds doubt about that the OSS developers will embrace it.
and it’s spelled stupid
“”Please understand that the previous sentence does NOT mean that I will be using XFree86 as the engine (shudder)…”
That sounds very wise!”
While I can agree X hasn’t always been pure happiness, would you mind elaborate what’s so terrible bad with X nowadays?
Seems to me ppl are slagging off X for no other reason that one is *supposed* to slag X off.
well thanks for the brilliant comment on spelling mr.jhkhohohiyuyetrsti-0978q.
Euginia Wrote: “I actually find the design for this page interesting. Sure, a bit more work should have been done in the fonts faces and font colors and also I would use tables instead of frames, but I find the page “interesting” in a pretty… weird sense of the word.
“
I actually liked the design of that page too when I saw it in the prebuilt templates section of http://www.blogger.com. I assume his whole site is a collection of Blogs. Its a nice easy way to keep it up to date without having to build your own database.
From his FAQ: “(no offense to the KDE/Gnome folks, who have obviously puts hundreds of hours of work into their respective products) ”
s/hours/man-years/
There is a general lack of substance and any kind of planning vision to back something of this size up.
One thing a man with a house and 3 kids doesn’t have is time.
I will be suprised if this project ever gets off the ground floor.
X is the most complex and annoying part of linux.
I use slackware because i wanted to learn about the admin side of things (I like the deep end) and I was told that it was a more involved process than other modern Linux distros. < I dont know how automated it is in red-hat/mandrake type things.
If linux is to break into the mainstream end user market it is only as good as its installation procedure. If you dont know the command ‘xf86config’, cant see the desktop to find the helpfiles, let alone get online to ask for help. a first time user is stuck at the command line.
If my parents can install it on my old p200 for free, understand the gui, surf the net, use office apps and send email. its mission accomplished.
If BeOS had JavaVM we would be there. (NOW we ger a browser – the iriny)
It may not be the BeOS, AtheOS or even recognisable as linux to the end user – so what? If It works it works and its what many Linux users want.