Slashdot Mirror
Interview With Cosmoe's Bill Hayden
Eugenia writes: "Over a month ago it was reported that a developer had forked the Athe(na) operating system and ported its GUI on top of Linux, without the use of XFree86. This combined OS, called Cosmoe, would support Linux, AtheOS, BeOS and even Macintosh's Carbon APIs (without the use of GNUStep - his port of Carbon is wrapped around the Be API). OSNews today features an interview with the architect of the combined OS, Bill Hayden, where a lot of things are explained about his plans for Cosmoe."
Duh! I made a mistake when I submitted the story. GNUSTEP wraps around the Cocoa API, not the Carbon one. Sorry for the confusion.
:P
I was deep into porting a game to MacOSX at the time of the submission and everything was like a big knot in my head...
.cx is perhaps the most unfortunate 3 characters to have at the end of a URL.
I have been pwned because my
Words/phrases in story -
operating system - 1 point
Linux - 10 points
Linux (again) - extra 5 points
AtheOS - 5 points
BeOS - 15 points
APIs - 2 points
Be - 5 points
Total : 43 points!
40-45 points: This story is so geeky it's bound to be accepted on slashdot!
Video Game cheats, hints a
When AtheOS was "outed," it was really far along. Especially when you consider it was all written by one person.
... what? Run BeOS apps on Linux? Run AtheOS apps on Linux? Run BeOS apps on AtheOS? Run MacOS X apps on Linux?
Similarly, OpenBeOS was impressive because it garnered a big crowd working on it rather quickly, and working code soon followed, to the chagrin of many. (There's already much work done on the kernel, via NewOS, BFS, the network stack, the GUI implementation, various preference and utility apps, and much more.)
AtheOS was a new OS built for fun (seemingly) by a guy that was impressed (but maybe not directly influenced) by BeOS. More power to him.
OpenBeOS is being built by fans of BeOS who want to see an open source version that can live on in binary compatability (for the first releases), and eventually progress beyond what Be, Inc. did (RIP).
Where does Cosmoes fit in to things? This guy forked AtheOS against the original author's wishes (welcome to the world of Open Source, Kurt), in order to
Honestly I'm trying to figure out what the goals are; I don't mean to be negative. If the guy is just doing this like Kurt, to have fun, then great... Otherwise, why promote this thing so much when virtually nothing is done? He admits the most of the hard stuff is waiting to be done. Instead of doing an interview, announcing the code fork, etc, why not start coding and announce it when you've got something to show for it?
"And like that
What is supposed to be wrong with the X11 graphics engine? Why do people keep complaining about it?
X11 does hardware-accelerated 2D and 3D graphics with transparency, anti-aliased fonts and graphics, ClearType-like rendering, and server-side geometric transforms.
You can get a good X11 server into less than 1Mbyte with almost no off-screen memory, or you can give it hundreds of megabytes for caching, buffering, fonts, and textures.
X11 provides a uniform and powerful API for all sorts of input devices.
It can't be the client/server architecture that people complain about because neither Windows nor OSX do direct graphics I/O for their UI either. Neither can it be the footprint, because if you look at Windows or OSX GUI apps and system resources, they are as big as X11 on similar hardware, or bigger.
Graphic design can't be the problem either: X11 imposes no constraints on the toolkits, GUIs, or desktops you build on top of it, and X11 toolkits have emulated Windows, OS/2, and MacOS/OSX so closely that it is really hard to tell the difference.
So, what concretely is supposed to be wrong with X11? Why this visceral dislike? Why do people keep starting projects to replace X11 with unaccelerated display servers?
My San Jose home rolled slightly, and BART has stopped for a bit, but life goes on.
Yes, thanks. This is the web site my husband loaded after I woke him up, when I felt the strong earthquake... :o :)
This is where we got the preliminary report for the 5.2 magnitude as well.
www.sfgate.com has gathered more info about the earthquake.
Is anybody thinking that this might be on the "Top Ten Vapourware of the year"?
In other news, did I mention that I'm building a program for Linux that can eliminate ALL of those nasty unresolved dependancies!! It works for DEB, Slackware TAR, and RPM's. It automagically scans and can determine what the developer really means when he puts the program names and versions in the RPM's. REALLY! IM SERIOUS!(cough)
we'll have BeOS and Carbon API support under normal real world linux use [with X11]. After all, if he's using the linux kernel, he's just writing another user mode GUI layer, like X. It should be relatively trivial to modify the code so that instead of directly talking to the framebuffer, it opens up in a managed window under X, [like with wine].
Why do I care? Because I like X, and I'm certainly not about to want to give that up that to run other neat apps that have been targeted to BeOS and carbon API. But if it's already on linux, well, nifty! [Once it's out of pre-alpha, of course]...
---
the pen is mightier than the sword, the sword is mightier than the court, the court is mightier than the pen.
As many of the responses to your post illustrate, folks just don't get the idea that XFree86 is a highly modular system. They don't get the idea that the fastest path to a high-quality GUI desktop for their favorite OS is to start with the existing XFree86 server, extend it as necessary, and layer atop it with a decent client side. Yes, Xlib's time has come and gone, and Xt has always been pretty hopeless. So use something like XCB as a base, and design the GUI API of your dreams atop it.
Also note that many of the XFree86 features you mention are either brand-new or not-quite-there-yet. For example, decent font support has only been solid for about a year now, and is still evolving a bit. Server-side affine transformations have been specified but not yet implemented. The spec for proper anti-aliasing of polygons was just finalized last week: it was implemented this week. (That's how fast XFree86 is moving these days with Keith Packard working on it full time. Keith has repeatedly demonstrated that it's pretty easy to add the "missing" functionality you want as an X extension.) As folks get used to the Render and FontConfig APIs, I expect to see correspondingly less interest in building window systems from scratch.
IMHO, the "visceral dislike" comes from several factors, including outdated ideas about what X is and how well it works (the performance claims I see around here sometimes crack me up), insufficient appreciation of the difficulty of what X does, and NIH syndrome.
The good news is that all the carping isn't slowing down the clueful folks any. KDE 3 is nice enough that for the first time since the mid-80s I'm not running twm as my window manager any more. I expect things to only get better from here.
Disclaimer: I'm an X11 programmer. I love X. Allows me to install matlab on only one machine but use it from anywhere (instead of buying 30 licenses for the 30 people that would occasionally use it), wrote my own window manager since everyone else's window manager got at least something wrong, and the X11 APIs are extremely clean and elegant - especially if you compare it to say, win32 SDK.
Here's why I think the kids don't like X nowadays:
I don't know how to solve this problem: XFree86 programs like xfontsel, bitmap or xvidtune shouldn't depend on GTK or QT, but at the same time, we should limit exposure to Athena. At least use Xaw3d instead.
This problem can probably be solved by the Linux distributers - include decent truetype fonts, set up QT correctly, etc. I imagine they're probably doing this at this point, but I don't keep up with them.
Solution to this problem? The config generators must be fixed. This is really a very, very big problem. I shoudn't ever have to choose my graphics card from a drop-down list - the config generator program should figure out what graphics card I have by snarfing its PCI id. "X -configure" does this, but it's none too friendly and still doesn't make for a usable XF86Config - it should be integrated with something like XF86Setup from the 3.x days, which allowed you to also set the various other options. No keyword should be added to XF86Config until the config generators are updated to set up the new option.
I've never managed to watch a DVD using Linux/XFree86. I'm a unix systems programmer, so I'm not some noob who's afraid to read docs - however, the last time I checked, oms still doesn't do sound sync, so it's completely useless. In XFree86 4.1, the ATI drivers were completely broken and wouldn't correctly do DGA, etc on every ATI card I've seen. It's much better now with XFree86 4.2, but it's extremely dangerous to say that watching DVDs in Linux is feasible at this point. This will only encourage the neophyte to actually try it - they'll have to upgrade and recompile their kernel, upgrade their XFree86, mess with some crap in /proc to enable DMA on their DVD drive, get a CVS checkout of oms as the published tarballs are outdated, search for the correct css plugin, as there are at least three different ones, and then, maybe, perhaps, they can try to see if it will even work. I didn't write down the crap I went through while trying this, so I'm missing a whole bunch of steps here - suffice it to say, this will take a few days. If you try to run quake3 or any other 3D game under Linux, you'll run into the same things.
Solution to this problem? Cut back on the advocacy. Let's be honest and admit that very few people will be able to watch DVDs or play newer games in Linux at this point.
At least now all of those people that bitch about X have something better to play with now than SVGAlib. Personally I like X, but I'm probably biased since I like to run stuff across networks. something like this may actually work on a large scale if qt and gtk support is added. How many apps actually talk to X directly?
Woh woh woh woh!
I think it must have been a while since you tried dvd playing on linux. AFAIK oms isn't even developed anymore. I use xine with the dvdnav plugin. It installed easily on debian, and the only sound sync problems I had were when I tried it using esd.
I also run 3d games under linux. Both the Wolfenstein and Quake III work, as does max payne running under WineX. All with no trouble after I installed the NVidia drivers.
I do agree with you about the X configuration issues, this seems to be something that each commercial distro is trying to solve in their installers (somewhat unsuccessfully in my experience).
Your points are mostly well-taken.
The default XF86Config file format may be moving to XML. This would help a lot with newbies being able to use sensible tools to edit their configuration. In particular, XML editors are pretty good at not messing with parts of the file they don't understand...
The DVD player thing is a special case, since there are folks in the world actively trying to make it hard :-). But if you run
Debian, you can very easily install
usable XFree86
bits, a usable kernel, and the current
Xine bits. It's then just a question of
finding a .deb for the Xine CSS plugin, and
you should be able to watch movies---I can.
The DRM/DRI support for 3D has stabilized to the point that it mostly just works. As you suggest, if it doesn't, you are probably out of luck unless you have direct access to a guru. This is true in Windows-land as well. The traditional solution there is to buy new hardware to make your software work. Buying a modern Nvidia card means you automatically get usable Linux drivers and some tech support, so this is always an option.
I agree that there are some things that still require some expert help, and that this is too bad. But all of this has gotten pretty off topic. If you check out the 3D and video HW support of the competition to XFree86 (e.g. Cosmoe [which is apparently going to call its initial distribution potatoe :-)]) you'll find it
to be far inferior, to say the least. X may
not be perfect, but it's tremendously good.
Help out or just be patient, and it will get even
better.
First of all Carbon is the C++ based MacOSX API
based on the old toolbox functions from MacOS 9 backwards. It has nothing to do with Cocoa which
is a Objective C API based on OpenStep.
GNUStep is the free (as in GPL) Implementation of
the OpenStep specification.
Ok, here is my ungrateful whiney rant. Feel free to skip it and move along.
We have tons of half-baked, alpha, spin-off, desktop operating system/UI projects that never get anywhere, and which invoke laughter when anybody claims Linux/<some free unix> is ready for the desktop. I don't mean to sound ungrateful, I realize that these guys are doing this "for themselves" as a hobby, but unless desktop developers get together, think over the hard questions, and come to solutions which all can agree on ("standards"? Gasp!), all we will have is a sea of hobby projects. Work that has already been done needs to be leveraged.
It seems to me that AtheOS, OpenBeOS, BlueOS, and NewOS (which I just discovered today), all have the same goal in common - to create a new, all-encompassing, semantics-enforcing, object oriented UI (basing it of the BeOS APIs simply because this is one of the areas BeOS did really well) fundamentally integrated with the rest of the OS. Surely these projects can work together? What about Berlin - is *none* of the work they've done relevant?
In the end, it may simply be that more work will get done *without* cooperating because each hobby developer is incentivized to work on his own thang (working in parallel, through the magic of open source), but it just really screams of inefficiency to me - the work that is done on any of these projects is probably reusable in the others (and I think bootstrapping by using the X drivers is a great idea). Is there really any fundamental philosophical difference between any of these projects? We'll never get anywhere if everybody is reinventing their own unicycle - let's combine them into a useful vehicle. I'm also more than partly motivated because I, myself, as a user, am pretty sick of X (no matter what is thrown on it) and am ready for a free desktop OS designed from the ground up *as* a desktop OS.
It's 10 PM. Do you know if you're un-American?
The biggest problem with X, no matter how wonderful it is, technically speaking, is that it does not enforce GUI semantics. This can be considered either a good or bad thing. From the perspective of a desktop OS, I think this is a bad thing. I don't know the guts of X well, but isn't the fact that video drivers are implemented in userland an architectural problem to begin with? Plus, the resources mechanism is absolutely byzantine and needs to be be razed, and salted, as well the complex distinctions between server and client (wait, who's the server, who's the client, who has the toolkit?, who's running the window manager? what the fsck is going on?). X simple suffers from being everything to everyone. I mean, it does an OK job being everything to everyone, but sometimes, as in when designing a *cohesive* desktop operating system, you *purposefully* don't want to have every option, and you *purposefully* want to force/standardize some things. Currently to get a GUI you have to choose a permutation of Toolkit/Window Manager/Desktop each of which might have its own subtle semantic differences, and due to the "flexibility" of X, may or may not work with each other with varying degrees of success. Just because a toothpick is "modular" doesn't mean you should build a house out of them.
Now maybe X is as modular as you say, and can be used as the building blocks for a more narrowly-defined GUI. But I think X has engendered as much bile against it as there is inertia behind it. (and a lot of the problems of X are the same old unsolved problems of Unix in general - no standardized method of configuration or collation of preferences for one)
It's 10 PM. Do you know if you're un-American?
Maybe he's using difficult hardware, my friend.
I said no... but I missed and it came out yes.
The port/implementation that is proposed is not of Cocoa, but of Carbon. Cocoa is the API that is inherited from Next, Carbon is the API inherited from the Macintosh Toolbox.
This implementation would not permit such things as Cocoa (or Carbon) versions of GNUCash. Instead this would mean that current carbon applications (Microsoft Office, Photoshop) could be compiled to run on a Linux like system.
Doing this would mainly require a lot of work., Carbon is quite a large API. Among the issues I see:
"Husband"? Geeks are taking it too far.
--
HideOuS
ha ha ha ha ha.
The video drivers are in the kernel. The drawing and acceleration is in the display server.
>>>>>
Except its not. For almost all cards (NVIDIA and its kernel driver nonwithstanding) the whole driver is in userspace, acessing the hardware via user-mapped I/O ports. This isn't the ideal situation, because for the absolute best performance, you need some stuff in the kernel (which DRI does, but DRI support is rather limited and only for 3D).
The toolkit is in the application.
>>>
That's a crappy design. Its more flexible, but its faster to have the toolkit server-side. That's why Qt (and GTK+) on X is slower than Qt on Windows. It basically uses X as a way to move bitmaps around the screen, which isn't the best (or fastest) way to use X. If the toolkit was in the sever, communication between the client and server would be limited to a much higher level (and thus low bandwidth) protocol.
As for windows and MacOS becoming more like X, that's only half true. Windows has the GDI in the kernel, unlike X, which is in userspace (personally, I think that's okay, I mean networking is pretty big too, and that's in the kernel). Quartz is slow as hell, so that's a bad example. Either way, client/server archs are becoming more practical. Before, when basically everything was simple blits or pixel plotting, the latency of individual operations was critical. These days, with OpenGL serving as the support for the GUI (see Longhorn and Jaguar) clients have to package up command anyway (vertex buffers, display lists, etc) and each operation takes comparitvely longer than a single PutPixel(). Thus, the latency of the communication isn't as much of a factor anymore.
A deep unwavering belief is a sure sign you're missing something...
That's what I said: the video driver (i.e., on Linux, the thing that does the mapping and switching)
>>>>>>>
Except its not! The only part of whole display system that's in the kernel is the part that alters the X server's TSS so it can use the I/O ports of the graphics hardware. This is unlike other OSs (even other ones with client/server archs) where an actual graphics driver, that does stuff like initialization, handling interrupts, etc, runs in the kernel. The main weakness with X's approach is that because *no* part of the graphics driver is in the kernel, certain facillities of the card cannot be taken advantage of. DRI (and NVIDIA's kernel driver) fix this by putting a little bit of the graphics driver in the kernel, but both are rather limited in the range of hardware they support, and only really affect 3D operation.
Qt is slower on X11 than on Windows because Qt ignores most of the server-side facilities that X offers. The "crappy design" there is Qt, not X11, and it mostly means that the authors of Qt just didn't want to bother doing a high-quality X11 implementation: Windows apparently matters more to them. Furthermore, on Windows, the "toolkit" isn't server side either: the display server runs in the kernel, and Qt runs in user space.
>>>>>>>
Hmm. If that's the case, then X's design is so borked that implementing toolkit functionality server-side is too difficult to get working. There is no major toolkit that puts an appreciable amount of code server-side. This is one of the big things Berlin is trying to solve. As for the Windows case, it's hard to tell. The GDI spec is just the call interface to gdi32.dll. How much of the GDI is implemented in userspace, is uncertain. It is entirely possible that gdi32.dll maps the graphics driver into the application and implements accelerated drawing in userspace. BeOS had an API that worked this way, btw.
I'm not sure what you mean by "before". Windows was written that way. X11 had a client/server architecture from the start and has always worked well with it. Windows is the latecomer, and it still isn't very good at it.
>>>>>>>
No, I should have said "in the past." I'm talking about the standard WIMP's that have been around for years, basically moving bitmaps around the screen and drawing lines and pixels. Now, the communication latency isn't as important anymore because a lot of overhead goes into packaging objects for the API to begin with.
As I was saying, X11 got it right from the start because X11 didn't assume that any program can just bash pixels in the frame buffer. Windows is playing catch-up
>>>>>>>
Oh please. The people who designed X never had any clue that 3D hardware would eventually come to their rescue and render the terrible latency in the interface a moot issue. Otherwise, they would have provisioned the system with something like DRI to begin with. Windows is not playing catch up at all in this case. Windows did it right the first time. It specified the drawing API as a set of procedures supported by gdi.dll, nothing more. They've got the freedom to implement their graphics engine however they bloody want to, without being restricted to a 20-year old protocol like X. And no, extensions don't help, because app must be specifically compiled to use them. Extensions violate every principle of OS transparency out there. Take a look at DirectX for an interface that got backwards compatibility correct. Just code your apps for the interface, and generations of hardware can go by and you're app will automatically support new advances.
A deep unwavering belief is a sure sign you're missing something...