Cosmoe 0.7rc20 is now available. During all the furious patching, “Pulse” started working and now has apparently broken again. Most other patches submitted via the mailing list have now been applied.
Cosmoe 0.7rc20 is now available. During all the furious patching, “Pulse” started working and now has apparently broken again. Most other patches submitted via the mailing list have now been applied.
While I admire and respect their work, it makes me wonder what the main “selling features” so to speek are. Does it run under the Kernel FrameBuffer? If so, I imagine that not many apps would exist.
Wouldn’t GTK+’s FB port be an easier place to start rather than porting a GUI from another OS (AtheOS)?
But the whole point of Cosmoe was to use the AtheOS C++ infrastructure (which is similar to BeOS’) and port the BeOS toolkit/API on top of it.
Cosmoe is not something that was created in random, therefore the C-based GTK+ is not what he needed in order to do what he wanted. Cosmoe is not just a new environment that happens to run on FB, therefore it would have been a good idea to use GTK+. Cosmoe has different goals and Bill just used whatever would help him better to get these goals done.
These guys really have a nice chunk of work ahead of them. I wish them luck. I love the comment he makes in his faq:
Another reason for this project is my loathing of X11. I tried to like it — I really did. However, after trying to make sense of this decades-old monstrosity, I came to the conclusion that it should taken out behind the barn and shot. Cosmoe is my gun.
AMEN. Perhaps not so much X11 itself, as it is a very valuable and usefull system. But definately the way they’re going at it now. I wont pretend to have a clue as to why but even XDirectFB when it’s friendly enough to work for me (which is to say, not recently) is better than straight XFree86. Resizing a window wont make xmms skip or mplayer freeze. If XDFB is still just an X server, and I am using the same window manager, shouldnt X(lib?) locking cause the same problems in both implementations?
I love X11, it just doesnt seem to love me back sometimes. :/
Also, the idea of being able to simply compile BeOS apps (that are open source of course) is an interesting one. I’m not a BeOS fan myself (or even a C++ fan.. ick), but I continually hear nothing but good things about it’s programming API. It definately cant hurt to have something like that available under linux. As much as I like to play with other systems, I just cant give up my GNU/Linux.
To ask a question of those of you who know better than myself, if the API were all there and available what difficulties would there be in implementing binary compatibility with BeOS? I know there must be issues abound other than simply having an API to translate calls to, and I seem to recall BeOS had a unique threading implementation that might get in the way of providing binary compatibility. Other than that, BeOS used standard ELF binaries and the like I think so threading issues would probably be the biggest thing… With the new 2.6.0-test1 kernel out Linux just might be ready for multimedia apps galore soon enough. It would be nice to be able to run BeOS apps.
Actually, beyond any threading or other low-level API issues, you’d have to deal with a more fundamental problem to get binary compatibility with BeOS apps: the ABI changes in gcc/g++ between the 2.9X (which BeOS uses) and 3.X versions (which most recent Linux distros use, and the Cosmoe build instructions recommend).
Since you can’t even use shared libraries compiled with one version in apps compiled with the other, the only real way to get full binary compatibility would be to only use the old 2.9X GCC toolchain — and this is, in fact, exactly the solution the OpenBeOS folks decided on.
However, the 3.X series of compilers introduced a number of performance and stability-related enhancements, especially for C++ code. Any significant C++ applications not utilizing those improvements will be at a significant disadvantage, and runs the risk of no longer being supported in newer distros unless an entirely different compiler toolchain is kept around for the Cosmoe/BeOS/whatever runtime to use.