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!

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.

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

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.

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.

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?

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 .

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.

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.

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.

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.

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!

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?

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.

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.

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.

""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.

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 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.

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.