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.