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
Put yourself in the skin of Joe Sixpack and reread your submission. You'll see that your mistake doesn't matter, Joe Sixpack will simply go get another beer.
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
I don't particularly like butter cookies. Any interesting pancake recipes?
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
Why not support the XFree developer team instead of creating another GUI? The chances are higher that it will be integrated into a bigger user base. It is very unlikely that it will happen in the Cosmoe case.
Anyone remember Berlin?
http://www.berlin-consortium.org
A case mod made of a Beowolf Cluster of these babys!
I'm on fire right now! Aaarrrggghhh!
felt alittle bit of shaking way down in morgan hill, ca 10 minutes ago. I guess its my first quake, boy what fun, dog hated it though.
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?
Still no report at quake.usgs.gav
--- Who put this sig here? ---
but look at his web site! May I humbly suggest that you name your new os HideOuS? Also, are we talking about a fork from Athena or Atheos here? Maybe they are the same, who knows, who cares.
Here's a cool map of California earthquakes, updated every few minutes.
cpeterso
My San Jose home rolled slightly, and BART has stopped for a bit, but life goes on.
oops, here's the map link: Recent Earthquakes in California and Nevada
cpeterso
I wouldn't say massive.
5.2 sw of gilroy...
USGS site
http://pasadena.wr.usgs.gov/shake/ca/ magnitude 5.2 - not catastrophic, but not insignificant either. It is the largest magnitude quake this year in CA.
I was wondering...
If this one guy can somehow bridge Beos's API to cocoa, couldn't someone (easily?) wrap cocoa around GTK?
What would be the issues involved? I mean, isn't GNUstep an entire open source implementation of much of cocoa?
It sure would be neat to have cocoa versions of GNUCash, Abiword, GNUmeric, etc...
feasible? or a pipe dream?
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.
and it will be: a) pointless b) vaporware
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.
I want a standard look&feel across all my apps
My response seems so obvious, but no one ever seems to suggest it. If you want all your apps to look and feel the same, then I suggest you run KDE or GNOME (or any other toolkit/appkit). Just pick one. There are enough apps for each that you never should have to leave your chosen "standard" look and feel. And for the rest of us who don't care, let us run what we want.
Doesn't this sound a bit like Windows 3.1 being called an 'Operating System'?
This is a GUI that supposedly will support the API's of multiple platforms. Methinks it won't be all that easy in the end. (think ardi with their executor trying to copy *just* the Mac API...yes, I *did* buy a copy).
I don't see how this could be even remotely possible, unless linux-like numbers of developers jumped in.
Go, Springboard, Go!
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?
Thanks.
Never had ANY trouble setting up quake3 in linux. Not a GeForce either, a G400 Max. Couple of kernel options and a few tweaks to XF86Config and it was the first "application" I had working on my new Gentoo Linux install besides X
And since I'm already WAY offtopic, I'll mention that the Gentoo Linux install is long but worth it and not difficult at all. The instructions on the website are FANTASTIC. I have never seen better installation instructions in my entire life. I was a hardcore slack user for a while, and this came to be as a bit of a shock. System is nice too :P
Anyway, play q3! and to a lesser extent rtcw! Support your local Cache! Cause computer games are damn fun
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.
Any ideas of making this financial viable in some way so that it actually can be a finished product in the end instead of just another un-usable Linux?
If you choose to compile and install things by hand, of course, you have to edit XF86Config files. But even there things have gotten much easier (e.g., in XF86v4, you don't need to worry about modelines anymore).
Ah.. That explains why my mouse stopped working in XFree 4.2 - both the mouse (a logitech trackman marble+), and XFree must be trying to autodetect which protocol to use, and deadlocking..
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?
well, according to the rest of the world you're fairly wrong about Linux being a toy OS, hasn't been that for many years now...
eah, know this is a bad troll, but what was the development of linux to do about some geezer using said kernel for his own project??
if (!signature) { throw std::runtime_error("No sig!"); }
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?
Why do they require you to know your monitors sync frequencies and how does windows get away with not requiring people to know them?
Maybe he's using difficult hardware, my friend.
I said no... but I missed and it came out yes.
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.
Use vlc. Much easier to use than xine, and it's packaged with debian.
Higher Logics: where programming meets science.
GNUstep does not wrap around anything. It is a reimplementation, done from the ground up. It implements Foundation, AppKit, and Display PostScript.
Problem is, I type 'Linux DVD' into google, I get to the livid web site (which is down right now). From there, I understand that 'oms' is the player to use, but apparently, that's not actively developed anymore.
When you search google for 'Linux DVD,' you don't get any web pages that point to xine or mplayer, at least at first. The only way I heard about these projects was through slashdot. Now, someone just mentioned vlc, so there's another choice.
So, it seems I have four options: oms, xine, mplayer and vlc. I could go and install all of them to make a comparison, but finding the right css plugin for each takes time. OTOH, I could go through mailing list archives to see which one is actively developed. If you go by the Linux DVD howto, it recommends oms and doesn't mention the other options, so it actually leads you in the wrong direction. That document must be rewritten or trashed.
I actually tried both oms and xine, and xine didn't do sound sync - it wasn't just slightly annoying on my slower system, but it meant all I heard was a bunch of pops and silences, perhaps punctuated with seconds of the film's sound.
DVDs aren't that important to me. I have a lot of machines available to me, and the only one that has a DVD instead of a regular CD-ROM or a CDR drive is my laptop - it came with DVD, no choice. I don't want to put together a machine with an Athlon XP 2000+, a gig of DDR, an expensive 32 meg video card, etc. just to play a DVD, since playing DVDs is entertainment I can do without. The laptop never had windows on it, but I'm assuming that I would be able to watch DVDs with it if I installed Windows (otherwise, it wouldn't have come packaged with a DVD drive). Actually, the only reason I put Linux on it instead of FreeBSD was because I was hoping at some point to use it for DVD playback.
Anyway, I can empathize - with the possibility of the MPAA hunting down Linux DVD developers, I wouldn't write DVD software, especially since I live in the US.
Thanks - this looks pretty cool. When I do Linux (rarely, I usually use FreeBSD instead), I always go with slackware. This looks really nice - they have an answer to ports and the install program looks right up my alley :)
In case you're wondering why Bill doesn't like X11, he explains this on the Cosmoe mailing list. Basically Bill encountered the bug in Qt 2.x that means that you can't cut and paste between most KDE applications and most other apps.
So what did he do? Did he report the bug to the Trolls, or at least to KDE's devel team? No. He decided to create a new OS based on AtheOS, BeOS, Linux and anything else that creates hype. The only thing missing so far is a promise to build a next generation Amiga
Oh yeah, and Bill thinks X is ugly. But, he also thinks AtheOS and Cosmoe are ugly. He proposes to fix this by making Cosmoe look different, which will be very hard, rather than making X look different which is easy but doesn't get you on Slashdot.
Meanwhile every distro worth talking about either includes KDE 3.x or plans to do so very soon. So the bug that annoyed Bill is gone.
X11 is the equivalent of GDI or Quartz; it doesn't have to enforce GUI semantics. If you want to enforce a "coherent" desktop on top of it, you can impose whatever draconian measures you like. KDE looks quite coherent and standardized to me, for example.
It's a myth, in any case, that Windows or MacOS are any more coherent than, say, KDE. Take a look here for an extensive critique. And you think that the appearance or window management behavior can't be changed on Windows? Think again: Stardock, Litestep, Microsoft PowerToys.
but isn't the fact that video drivers are implemented in userland an architectural problem to begin with?
The video drivers are in the kernel. The drawing and acceleration is in the display server. The toolkit is in the application. It's fast and it's robust. It's what NeXTStep and MacOSX do as well. Where is the "architectural" problem?
Plus, the resources mechanism is absolutely byzantine and needs to be be razed,
Neither Gnome nor KDE use the X11 resource mechanism. They use something much more like Windows. That's actually a shame because the X11 resource mechanism is better.
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?).
Windows, MacOS, and NeXTStep make the same distinction as X11: they have a low-level graphics and windowing component that runs in a display server, and they have a high level toolkit part that runs in a display client.
Altogether, it looks to me like you have a rather outdated notion of what Windows, MacOS, and X11 are. Windows and MacOS have pretty much become like X11 architecturally; they simply lack the well-defined and efficient X11 protocol to support that architecture. On the other hand, X11 toolkits (for better or worse) have become much more like Windows and MacOS toolkits. All three of them have gotten direct rendering and 3D acceleration.
Eugenia Loli is more of a wannabe than anything else. She touts her experience "working" for a defunct British assembly language software house (Intelligent Firmware, only accessable by archive.org. You will see how laughable it was and why it's defunct), but knows no assembly, takes credit for "porting" mostly ANSI code applications and cross-platform SDL games.
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) is in the kernel. The drawing and acceleration is in the display server, and for certain special applications, the application itself gets memory mapped into its address space.
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).
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.
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.
In fact, with the right toolkit, X11 is often faster than GDI. The reason is that X11 was designed to go through a bottleneck. GDI was designed assuming direct library calls and had to get retrofitted to work in a protected mode environment. Furthermore, X11 naturally takes advantage of multiple processors and graphics processors.
Before, when basically everything was simple blits or pixel plotting, the latency of individual operations was critical.
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.
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.
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.
well... (at the risk of being modded down even more) what is the point of this remark? the original post was critical about setting up x and dvd playing under linux. considering the possibility that he does have "difficult" hardware (support for my hardware is not complete in x either: voodoo5 5500) only weakens his argumentation. just because it doesn't work in a *very* specific situation, doesn't mean that the configuration is difficult perse.
;-)
it seems i need to rephrase my criticism overhere, since my original post was modded flamebait twice. i was just trying to point out that the original poster was saying that configuration was difficult, while he is an expert on the subject (i suppose so at least since he calls himself an unix systems programmer), after which he questions the use for multi-head configuration.
failing to see the use of a feature just because you have no use for it is not a good argument IMHO. if that's flamebait, someone please explain me why.
or maybe it's just my sig that makes people assume i'm flaming
> Problem is, I type 'Linux DVD' into google,
try rephrasing your query: i typed 'dvd player linux' (quite obvious i think), and i get ogle, xine, and mplayer within the first 7 hits.
> Anyway, I can empathize - with the possibility of
> the MPAA hunting down Linux DVD developers, I
> wouldn't write DVD software, especially since I
> live in the US.
i know that writing linux dvd players can cause legal problems, which is why i didn't suggest that to the original poster. i suggested working on the x-configurator, which was one of the original posters' criticisms towards xfree.
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...