Cosmoe is back. “Well, I couldn’t stay away. My lengthy hiatus away from working on Cosmoe is now over, and I am back in full force! For those of you not familiar with Cosmoe, it is a BeOS API (or Haiku API, if you will) environment running on Linux.” There’s even a screenshot.
While I’m not on the “BeOS on Linux” bandwagon yet myself, I still think this project is important for a couple reasons.
First, it provides more incoming code for Haiku. One could say it even provides an alternative development platform for Haiku/BeOS (source-compatible) apps.
Secondly, it should expose any assumptions made by the various modules of Haiku about the underlying kernel/driver architecture. It would be nice to see clear abstraction wherever possible.
Thirdly, Cosmoe may assist as a good stepping stone to porting more applications from Linux to BeOS/Haiku. It may even serve as an reverse example for building a Linux->Haiku compatibility layer someday in the future?
I think Bill Hayden and Cosmoe is a very good resource for the Haiku community in the future.
I agree. And Cosmoe will make easier to have a Haiku/BeOS-like OS ported to PowerPC and other platforms, once linux already has been ported.
I wasn’t a fan of “BeOS on Linux” either, but over time I’ve changed my mind.
One of the big advantages of riding on top of Linux and X11 is drivers. The lack of drivers was a problem for Be and yellowTab, are one for Magnussoft and will be one for Haiku. When you hijack Linux+X11 on the other hand, you start not only with a fully working kernel and display server but also with a wide variety of drivers, some of which you couldn’t write yourself even if you wanted to. It takes a huge burden off the already overworked OSBOS developers (not having to write a networking stack, SATA support, debugging SMP problems) and leaves them more time to work on the things that make BeOS BeOS.
I totally agree with you. Though a port of Cosmoe on some BSD, like OpenBSD or DragonflyBSD could offer more advantages because they need the BeOS layer to complement their efforts. Anyway even on Linux (I have no reservations), it provides a good alternative to Gnome/KDE and could bring more people back to BeOS/Haiku/Yellowtab.
I don’t agree with your points. BeOS was cool because it was NOT Linux or another Unix. A Linux with BeOS’ APIs will be just that, not what we (the Haiku people) want.
BeOS was cool because it removed compatibility layers and its pieces were very well integrated with the system as a whole. If we start to make Haiku pieces “compatible with other systems”, then what remains of Haiku?
If we start to make Haiku pieces “compatible with other systems”, then what remains of Haiku?
Haiku can stay Haiku. No need to Linux-ify it, just don’t whine about the other BeOS-ified platform being able to use the GPL-ed Linux-drivers and Haiku cannot (without adopting the GPL).
It will only mean broader adoption of the BeOS way of doing things in other platforms. On the other hand, it will kill all the pleasure BeOS purists have now in knowing to be a member of a small, exclusive BeOS niche.
BeOS was pretty POSIX, so not being another *Nix is a bit of a shortcut.
I agree wholeheartedly with you that Haiku can _stay_ Haiku. I believe R1 will be, as it set out to be an improved R5 clone.
With a Linux kernel beneath the hood, Haiku has the _opportunity_ to become something else. I for one, would much rather see a broader adoption of the BeOS/Haiku ‘modus operandi’ which to a great extent (from a users perspective) is derived from the intuitive UI. Linux, as a kernel only, shouldn’t detract from that though (Kudos to Bill), I wouldn’t like to be the one wiring it all together :o)
As you rightly say, Haiku could garner extra momentum from this development which can only be a good thing. As for the drawback for BeOS purists, being a member of a small, exclusive niche should be a fair trade-off for greater visibility and interest in the various projects. Come the day Haiku R2 arrives, Haiku may well be a good distance _removed_ from what R5 is today. The purist drawback will be null and void.
“With a Linux kernel beneath the hood, Haiku has the _opportunity_ to become something else. I for one, would much rather see a broader adoption of the BeOS/Haiku ‘modus operandi’ which to a great extent (from a users perspective) is derived from the intuitive UI. Linux, as a kernel only, shouldn’t detract from that though”
But I don’t want Haiku to become something else. The BeOS modus operandi was most due to system kernel and architechture, which cannot be replied on a Linux kernel without a lot of work (say, monolithic kernel versus modular kernel).
Giving Linux the BeOS look and feel will not make it a new BeOS, it will just be another Linux. We have too many of them (I always wonder why Linux devs don’t understand the problem in that).
There are a lot of things that Haiku can borrow from Linux or other open OSs, but not the kernel or, even worse, X.
“But I don’t want Haiku to become something else. The BeOS modus operandi was most due to system kernel and architechture, which cannot be replied on a Linux kernel without a lot of work (say, monolithic kernel versus modular kernel).
Giving Linux the BeOS look and feel will not make it a new BeOS, it will just be another Linux. We have too many of them (I always wonder why Linux devs don’t understand the problem in that). ”
Haiku _as is_ with the NewOS kernel will be as close to BeOS (R5) as it is possible to get. It will most probably be that way for a long time to come.
My post didn’t imply in any way that the Haiku team was about to swap-out the current kernel for a Linux one….or that it should even consider doing so.
However, as the Cosmoe effort (clearly a separate development) is, at least, part compatible with the Haiku development effort, there seems little or no reason for denying the potential to explore the possibilities that now exist. Who knows what will emerge??
One thing is for sure, that as long as the Cosmoe project remained static, no opportunities, either good or bad, would emerge.
IMHO, as long as it is built on top of NewOS, Haiku will remain very close to the BeOS way and hopefully become the excellent desktop OS is was designed to be. Cosmoe on the other hand, may develop in an entirely different direction which may or may not generate external developer interest. Again, who knows, we’ll have to wait and see.
For the currently _minute_ userbase that makes up the community, this is no bad thing.
Just my 0.02 euro
Edited 2007-02-09 16:09
Edit: Hmmmm….posted same twice! Must get memory checked out!
Edited 2007-02-08 18:13
just don’t whine about the other BeOS-ified platform being able to use the GPL-ed Linux-drivers and Haiku cannot (without adopting the GPL).
Please explain what requires an entire OS to be GPL’d in order to compile a driver for it? I can write a GPL driver for Windows and compile it and distribute it in binary form without requiring windows to be GPL’d. All I have to do is make my driver source available on demand.
Because a driver links to the kernel (and vice versa). The way module loading is implemented on most OSs, loading a kernel module is almost exactly equivalent to:
gcc -c -o gpl_code.o gpl_code.c
gcc -c -o non_gpl_code.o non_gpl_code.c
gcc -o my_program non_gpl_code.o gpl_code.o
(except the last bit is done at runtime by the kernel dynamic module loader)
By the definition of the GPL (and copyright law in general, actually), my_program must be covered by the GPL, because since it includes GPL’ed code it is a derivative work. It’d be like including a few pages from a book in your own. The fact that the copied portion is much smaller than the whole work doesn’t change things.
Of course, there is a point to be made about Haiku. Since Haiku is MIT licensed, and the MIT license is GPL-compatible, there is no conflict. Since the MIT license is strictly less restrictive than the GPL, it’s consistent for them to ship a GPL’ed driver while keeping the rest of the code MIT. The work as a whole will be GPL’ed (when its linked at runtime), but that’s not particularly meaningful.
Edited 2007-02-09 06:46
I disagree that it’s derivative…
Those modules can be removed without affecting the “larger work”.
It seems like you are saying that nobody can create GPL’d code for ANY non-GPL’d OS/Software. We know that’s not true, either that or thousands and thousands of GPL’d products running on Windows, OSX, etc. are in violation of the GPL by your definition.
Heck, the devs can turn off and on the compilation of these GPL add-ons anyway without affecting the final result (other than some hardware simply won’t be recognized by the OS at startup by default). In the end, if someone wishes to distribute them with the MIT-licensed code, they’ve met the requirements.
In any case, I’m sure this has happened in the past… what was the result then? I would even say that nVidia and ATI’s method of releasing DRI drivers is even MORE questionable – and yet they get away with it.
>I don’t agree with your points. BeOS was cool because it was NOT Linux or another Unix.
Sigh, different from Linux *the OS*, but you can reuse the Linux kernel and make an OS which doesn’t feel like Unix..
MacOS X has shown quite clearly that you can reuse a kernel and make a different OS: Mach+FreeBSD personality, does Mac OS X feels like FreeBSD?
macos x is based on an older kernel than freebsd. Many people have complained that it’s not exactly the most responsive thing in the world.
On the other hand since it’s not based on a gpl kernel you don’t have the problem linux faces with closed source drivers in the kernel. Let’s say someone wants to embed Haiku in some multimedia hardware solution. why should they even have to worry about lawyers before thinking about Haiku? Just say no to lawyers!
>Many people have complained that [macos x] it’s not exactly the most responsive thing in the world.
And? Linux kernel is considered to be a high performance kernel, the responsiveness issue of Linux OS are more related to the lack of integration / optimisations of the higher layers and applications (no enough usage of multi-threading), so a BeOS clone made on top of Linux kernel could be responsive.
>why should they even have to worry about lawyers before thinking about Haiku?
Because usually people want something for something, the success of Linux and of the GPL has shown that the ‘I’ll show mine if you show yours’ GPL license is appreciated by the developers, whereas *BSD OS see less contributions.
So it’s possible that a clone of BeOS using GPL would have more developers than one using BSD.
“MacOS X has shown quite clearly that you can reuse a kernel and make a different OS: Mach+FreeBSD personality, does Mac OS X feels like FreeBSD?”
No, until you exit the Aqua and venture into the terminal. This is when you see that Aqua is not “integrated” with the system below, but it is “over” it. Finder don’t let you go below /Volumes, what if I have to edit files under /private, /usr, /etc… you have to learn Unix.
And? The vast majority of MacOS X users never use the terminal, so they *don’t* have to learn Unix!
So I’m not sure what’s your point here: if a BeOS clone on top of Linux kernel was done in a similar fashion, the vast majority of the users would never know what the kernel is and that’s fine.
Sure if they want to go and see under the hood, they would find the Linux kernel, but so what? As long as the BeOS clone works well enough that you don’t *have to* learn Linux unless you want, I fail to see how that is the problem.
Yes, but OS X has some hundreds programmers. With this, you can put any kernel behind any face. That’s something we’ve seen in past for Apple, you can put a kernel worse than Win95 and people would still say that it rocks as long as it has Aqua.
But we want to keep the OS simple, and we have to because we don’t have hundreds of programmers.
Somehow the logic of manpower to support restarting nearly from scratch to create a new clone of BeOS using a kernel with few drivers instead of a Linux kernel with many drivers seems a bit dubious..
“That’s something we’ve seen in past for Apple, you can put a kernel worse than Win95 and people would still say that it rocks as long as it has Aqua.”
Before someone comments this: I am not saying that OS X is worse than Win95. It was just an example, ok?
What is the deal with all the overlapping text? Notice how the letter “e” in File overlaps the “E” in edit. And how the word Controls goes beyond its tab into the next tab. And how the words GUI Elements go way beyond their tab border.
The words Check Boxes and Radio Buttons are sitting in the middle of the box outline. What is up with that?
The words “Show Alert” are truncated because the word “Alert” goes beyond the button border. Same with the word “Button” in the bottom box.
Looks like the API is a total mess at the moment.
Edit: Fixed a typo.
Edit II: OK – I should have finished reading the article first because it mentions the GUI problems. So nothing to see here. Mod down my comment, I deserve it.
Edited 2007-02-07 22:55
what happened with blueeyeos? i think that there is no need for 1 more BeOS look a like, we already have haiku.
Browser: ELinks/0.11.1 (textmode; Linux 2.4.30 mips; 125×44-2)
i think that there is no need for 1 more BeOS look a like, we already have haiku.
I really like the idea of using a reasonably stable and mature kernel (yes I’m talking about Linux
and putting the BeOS API on top.
I think it is also a good choice in that Linux is highly scalable for process & thread scheduling, in the spirit of the original BeOS multi-processor systems, and the multi-threaded design of it’s applications.
At the end of the day, if it gets more people writing BeOS/Haiku compatible applications it’s all good!
BlueEyedOS is different. As far as I am aware B.E.OS is/was using XFree86. Cosmoe is a new/different windowing environment altogether…To answer your question, I have no idea what happened to B.E.OS.
Edited 2007-02-08 00:28
BlueEyedOS used X, but the way that it was intended, it didn’t have to. As far as what happened, the developers ran into problems finding time to work on it, IIRC.
“BlueEyedOS used X, but the way that it was intended, it didn’t have to. As far as what happened, the developers ran into problems finding time to work on it, IIRC.”
Beyond that, Guillaume have said: Zeta is more important now…
Michael Vinícius de Oliveira
Cosmoe currently runs on X as well (well, SDL technically, so it’s not highly dependent on X).
FTA:
Cosmoe currently runs in an SDL window under X until full graphics driver support can be achieved.
As the main developper of BlueEyedOS (B.E.OS), I have to say that the current status of B.E.OS is “sleeping”.
The main reason is that we (the B.E.OS team) delivered some times ago, a demo CD (a 200MB bootable iso file) of something that I could name a ‘preview’. The font rendering was great and controls had a correct rendering.
It was far ahead the current Cosmoe, and OpenBeOS (the old name of Haiku, last time I had time to look at it).
By “sleeping”, I mean that such project needs a lot of work and faith, and that as soon as I have enough time to make B.E.OS as good as BeOS was, curious people who will try it, will say “wow”.
I still believe that systems with gnome and kde are not an alternative to Windows; and that Haiku will go nowhere due to:
– a lack of drivers (even linux [with a lot of developpers, money, big companies support] is far from a good system for common usage)
– a lack of real applications.
Exciting technologies are today, for me : the power of the Core2Duo, Java6 with the damned great Eclipse IDE, iLife on MacOSX and Maya on WindowsXP, web related servers with Linux, dtrace on Solaris and JNode.
In today’s world, no one cares about creating/selling/using/buying a ‘state of the art’ operating system.
If not, could someone explain us why big companies could spent hundreds millions dollars to buy a website like youtube, when only few millions could be used to create a technicaly Vista killer?
Managing my own software company, I can confirm that the only financial contacts I had with Google, were to pay adwords bills
Regards,
Guillaume
Cosmoe runs on variant of Linux – so I take it it won’t be binary compatible with BeOS apps?
It will be interesting to see which of Haiku or Cosmoe does better once Haiku 2 breaks binary compatibility with Haiku 1/BeOS.
I think it maybe better on FreeBSD than on a Linux variant since OSS licencing of Haiku/OpenTracker is BSD compatible.
Isn’t the network stack on Haiku going to based on FreeBSD stack?
Isn’t the network stack on Haiku going to based on FreeBSD stack?
That was the plan at one point, but was scrapped.
The stack is now home-grown and built mostly from scratch. I’m sure it takes some cues from FreeBSD and/or other stacks – but it is not ported from there at this point.
Edit: forgot to answer you licensing point:
This licensing thing always comes up, and I think people just don’t get it. You can put MIT-licensed code on top of Linux (GPL’d) code without a problem. As long as any code he writes/modifies and commits to the Haiku repo doesn’t derive from any GPL’d libraries/code, it can also be MIT licensed. He owns the copyright on any code he writes – he decides the license for it – it’s that simple guys. If he makes use of other code in order to distribute his own code, then he must follow the licensing obligations of that other code as well (GPL) – which MIT licensed code already does.
Edited 2007-02-08 03:55
As far as I understand it, BlueEyedOS came about mostly because the folks in charge didn’t like the technical and licensing decisions that Haiku made.
Cosmoe is a different story. Bill is using the Linux kernel but Haiku’s app server and other pieces. He contributed a good amount of fixes back to Haiku. I suspect that he will have to report his changes to both the Haiku (if he wants) and Linux kernels, making it a bigger and bigger job as time goes on.
That’s the way it was told to me by Big Red himself.
I suspect that he will have to report his changes to both the Haiku (if he wants) and Linux kernels, making it a bigger and bigger job as time goes on.
All he has to do is make any Linux-based code available if anyone wants it. Why is that so hard?
It’s not. What the parent was talking about was working with the kernel team and the haiku team and sending his fixes and editing them if need be, etc. Being a _good_ developer is a lot of work. and completely worth it
“As far as I understand it, BlueEyedOS came about mostly because the folks in charge didn’t like the technical and licensing decisions that Haiku made.”
Actually BlueEyedOS started before Haiku, so…
Not to argue without reason, but started has many different meanings.
07/01/2001: The BlueOS project is born.
08/05/2001: FAQ has been updated
08/22/2001: mailing list opened and member section updated
You opened your mailing list on August 22, 2001
Okay, but now look at this.
[openbeos] Ok, let’s start
* From: “Marcus Overhagen” <dos4gw@xxxxxx>
* To: openbeos@xxxxxxxxxxxxx
* Date: Sat, 18 Aug 2001 15:47:33 -0700
OpenBeOS opened their mailing list on the exact same day !
It seems to me you started at the same time.
Edited 2007-02-08 10:24
08/18/2001 is 4 days earlier than 08/22/2001. How does Augst 18th. equal August 22nd.?
With a project start at July 1st. and a FAQ update approx. 2 weeks before opening the mailing lists for Haiku it seems that BlueEyedOS was the older project.
But of course – you’re free to live in your own dimension
BTW: Noticed how responsive Haiku is? Even in VMWare
Its fine in VMware…networking support would be nice.
Network support is there, just use “bridged” mode and not “nat” in vmware.
Wow, I was really tired last night.
Still, they went public, with mailing lists, at the virtually same time.
/// Oppps
Edited 2007-02-08 07:09
One of the big advantages of riding on top of Linux and X11 is drivers.
Syllable manages to use quite a few Linux drivers. Of course, like Linux, Syllable is GPL licensed whereas Haiku is not.
Using GPL’d drivers is perfectly feasible for a non-GPL’d OS. There is nothing linking to the drivers, and as long as the driver source is made available, there’s no violation of the license.
Again, it seems like there’s some serious FUD regarding the mixing of GPL code with MIT code. What the heck?
Edit: There are even GPL drivers in the Haiku repo already.
Edited 2007-02-08 20:55
Using GPL’d drivers is perfectly feasible for a non-GPL’d OS. There is nothing linking to the drivers, and as long as the driver source is made available, there’s no violation of the license.
The main text of the GPL actually makes no mention of linking, but of the idea of distributing two separate pieces of software as a whole. Now the question becomes what constitutes a “whole” in terms of the GPL. The license makes it clear that just sticking two pieces of software on the same media doesn’t make them a “whole” as far as the GPL is concerned.
That said, the relationship between a kernel and a kernel module isn’t all that different than that of an application and a shared library and that is generally accepted to be a condition that invokes the viral portion of the GPL.
That said, if the drivers aren’t distributed with the OS there’s obviously no way that the viral portion of the GPL would come into effect. If you were simply arguing that someone could port a GPL driver to Haiku and it could be used without any problems so long as it wasn’t distributed with the OS then I don’t disagree with you.
If you are instead suggesting that the two can be legally distributed together without offering the kernel under a GPL license than I’ll have to disagree, but I am admittedly not a GPL expert. If you’d like to point me in the direction of some info that would invalidate my interpretation of the GPL it would be welcome.
That said, the relationship between a kernel and a kernel module isn’t all that different than that of an application and a shared library and that is generally accepted to be a condition that invokes the viral portion of the GPL.
Now come on – that’s like saying bash and gcc are part of the “whole” also. They obviously can be distributed with an OS without “virally” making the entire OS GPL.
Kernel modules in Haiku are loadable standalone binaries. They are not compiled into the kernel. The driver doesn’t link to GPL’d code – the driver IS the GPL’d code. It links to MIT code in fact. So you’re thinking of this backwards.
Besides all that, MIT license already satisfies the requirements of GPL and is thus “compatible”.
edit: typos.
Edited 2007-02-09 02:17
Now come on – that’s like saying bash and gcc are part of the “whole” also. They obviously can be distributed with an OS without “virally” making the entire OS GPL.
bash and gcc are completely independent programs that do not get loaded into kernel space.
Kernel modules in Haiku are loadable standalone binaries. They are not compiled into the kernel.
A shared object isn’t compiled into the program that links to it either.
The driver doesn’t link to GPL’d code – the driver IS the GPL’d code. It links to MIT code in fact. So you’re thinking of this backwards.
It’s no different than an application that has a plug-in interface in which a plug-in is a shared object that exports a pre-defined set of symbols and the application loads the shared object at runtime. I could be wrong, but I doubt if I made a closed source application that uses such a plug-in mechanism that I could legally distribute it along with a GPLed plug-in (unless of course I own the copyright to the GPLed plug-in).
Here’s a statement from the FSF’s GPL FAQ regarding GPL plug-ins for non-GPL programs:
It depends on how the program invokes its plug-ins. If the program uses fork and exec to invoke plug-ins, then the plug-ins are separate programs, so the license of the plug-in makes no requirements about the main program.
If the program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single program, which must be treated as an extension of both the main program and the plug-ins. This means that combination of the GPL-covered plug-in with the non-free main program would violate the GPL. However, you can resolve that legal problem by adding an exception to your plug-in’s license, giving permission to link it with the non-free main program
Besides all that, MIT license already satisfies the requirements of GPL and is thus “compatible”.
Yes, but the end result of mixing MID and GPL software is essentially GPL licensed software.
I’m not convinced of those hybrid projects/ideas…
Haiku is the easiest concept: rewrite the OS from scratch.
If Haiku was FAR from complete.. I would consider more the Whole Thing (Cosmoe). But now.. With Haiku R1 nearly alpha status (or beta I would like to say), who would care about BeOS API on top of Linux? O__o Mmmh.