What?
You try? Were gonna end up in the same boat as all the dead commercial Unices if people don't feed back
their changes. I mean damn, they have to under the GPL, right?:(
Nope - they don't have to. Not unless they redistribute their new, improved kernels. "Redistribution" has been interpreted in the past (even by RMS, if I remember correctly) not to refer to in-house "distribution". Meaning: so as long as those kernels never leave DreamWorks, they don't have to give us back crap.
more users who won't contribute a single thing to the open source movement yay!
Point well taken. The users won't do a darned thing for us except provide just that much more momentum for other end-users. The admins, on the other hand... well, reread the article - one of the last few paragraphs:
Chapin relayed a cheerful account of the cooperative nature of the Open Source
community, pointing out the work of HP, Red Hat, and many other hackers who provided,
improved, and maintained the tools that ultimately enabled PDI/DreamWorks to transition
to an almost 100% Linux shop. "And when we can," he says, "we try to feed our kernel
and video changes back into the community."
If the guy is serious about this, it is good news.
Perhaps I should switch all the proprietary BSD boxes I have sitting around to a more open OS like
Linux...
If I were you I'd look at migrating to FreeBSD or NetBSD - still free / open, and an easier migration path since they're still based on BSD. In the case of FreeBSD, doesn't Walnut Creek operate both FreeBSD and BSDi? (Come to think of it, which proprietary BSDs do you use? BSDi? NeXTStep? SunOS 4? Ultrix?)
Apps won't happen until the Open Source community gives up in X as a desktop GUI. Open source coders
need to realize what Apple did; that X is great for running GUI apps across a network, but as far as the
desktop goes, X still pretty much sucks, even with high-res anti-aliased fonts and the nice 3D support
we have been getting from Nvidia.
Name one feature X doesn't have that it would be easier to provide via a brand new graphics system than it would be to extend X to do. Or a whole set of features, if you prefer. I'll rebut what I can.
Keep in mind that X is very low-level, and that a lot of things can be layered on top of it, and a lot of things are intentionally outside its control. For example - you want application consistency? Make all the apps consistent - nothing to do with X per se. (Just like the Winamp look 'n' feel is not at all consistent with the CDPLAYER.EXE look 'n' feel - does anyone see this as a problem?)
This is great news and shows the curtain is really starting to close on Redmond.
This is much worse news for SGI than it is for Microsoft.
SGI used to own the Hollywood effects houses - anything not Mac was IRIX. Over the past few years everyone has started realising that while SGI sells the biggest and baddest NUMA, some things like 3D rendering are naturally parallelisable to such an extent that clusters make a lot more sense than NUMA. Clusters often mean Linux, for reasons I don't need to get into here. Which is, I'm convinced, the main reason SGI got into Linux in a big way a few years ago - they figured that was the way to keep their current big-spending customers. Remember that SGI "got religion" long before IBM or HP made serious noises about Linux. HP is a comparative johnny-come-lately both to Linux and to serious 3D graphics.
So losing this contract to HP and Red Hat had to hurt SGI. Bad. This was their turf, and we just saw a major failure for SGI's Linux play. Nail in the SGI coffin?
(PS: I just thought of this: it's not a total loss for SGI - they still own Alias|Wavefront, whose Maya software was used.)
Scratch that...it's P4 Xeon powered...I was thinking of the wrong model!
Yes indeed. We have an x4000 here. Very very nice. HP's case design is a work of art in terms of usability (much better than the Dell 530). The BIOS is too cool to boot Linux 2.2 (MP table parsing bugs, I think it was) and the then-current 2.4 kernel had a bug launching an initrd, which made for a fun initial bootstrap....
And according to the article, they used "proprietary HP graphics hardware", which sounds to me like the Visualize FX/10 card. I wish, I wish HP would get their Linux act together and release a free XFree86 driver for the FX/10 already. Not that it's just HP - this binary-only crap for all the high-end graphics boards (Fire GLn, FX/10, Wildcat series, and on down to the latest NVidia offerings) is getting old fast. I don't care if you provide only binaries for Windows; that's not acceptible in Linux space.
I tough that patents
were preventing you from doing patented things and to re-sell them. And that I was free to implement any
of those patent for myself. If it is not the case, it's a serious treat to any hobbyist!
I think you are more or less correct. You can write an application that violates patents, you just can't try to sell it.
Unfortunately, having patent infringement problems really affects widespread adoption of your software. Nobody wants to risk distributing it, for fear of the patent holder. The Debian Project, for example, won't go near patent-infringing works, unless it's something stupid like the XOR or the File/Save-As patent. Why? Partly for their own liability, but mostly because of the Debian Social Contract. Quoting from point #4 in the Social Contract:
We won't object to commercial software that is intended to run on Debian systems,
and we'll allow others to create value-added distributions containing both Debian and commercial software,
without any fee from us. To support these goals, we will provide an integrated system of high-quality,
100% free software, with no legal restrictions that would prevent these kinds of use.
In other words, Debian avoids patent-restricted software so that people who want to use Debian for commercial purposes - reselling official CDs, selling unofficial CDs, or making / selling derivative works - can do so without having to pore through the license texts of thousands of packages. They want you to just assume that when you download an official Debian package, you are free to use it however you wish, and free to redistribute it with or without modifications, possibly subject to some restrictions as noted in the DFSG.
Remember, even free software is bought and sold - just ask SuSE or Red Hat. And it's not likely that Red Hat can just negotiate a patent license for their customers when needed - their CD sets have too little profit margin as it is.
Who cares about speed? I'm going to launch these suckers on everyone with an open display:-)
Not nearly as easy as it used to be. Sure, there are plenty of stupid 'xhost +' users still in the wild, but thanks to the rise of single-user Linux boxes, many distros actually default to the X server not listening on TCP/IP at all! Good for security, bad for people with xroach.
Instead, good ol' X11 once again accomplished it's primary mission -- keep the protocol open while still
finding a way to encourage propreitary lock-in for the applciations. Maybe KDE/Gnome ain't as
"proprietary" as their commercial forefathers, but your post illustrates that the situation hasn't
improved much since the last widget war.
I'm not sure quite what you mean to imply by the term "widget war", but really - it's not so much a war as, perhaps, an archery competition. Nobody is being hurt by the proliferation of applications under both the GNOME and KDE frameworks. It appears to me that both projects have a rich, mature library environment and rapidly maturing development tools - fragmentation doesn't seem to have hurt there. Lots of KDE users use Gnumeric and Mozilla, and lots of GNOME users use KDevelop. Developers don't even have to worry about picking the "right pony" - the two widget sets are easily compatible enough to coexist on one's desktop. (They look a lot more harmonious together than Motif versus OpenLook!)
The "KDE/GNOME war" was pretty much invented for TV, as it were. The mass media love to find a rivalry to report on. Ask any of the actual hackers involved about "beating" the "other team" and they'll probably laugh at you. The war is waged more on public fora like Slashdot among mere end-users than anywhere else - just like any other modern holy war.
And yes, it must be possible to produce an equivalent feature set simply because Win32 & Mac both manage
to have fast desktops despite not using X at all.
You may or may not be fingering the right culprit. I know, when software seems slow or unreponsive, it is very tempting to look at it, find one thing you think is inefficient, and say "that's why this is slow".
Linux is a complex system. XFree86 is a complex system. GNOME is a complex system. The basic user experience will see factors from all three affecting perceived "speed". And often this "speed" is not actually raw speed per se, but latency - which means the amount of time needed to react to an event. Linux is known to have lousy worst-case scheduler latencies - which often don't matter, but occasionally do. Latency is a trade-off against raw efficiency and against system complexity - simpler designs are more efficient (as a rule) but have higher latencies.
There is also complexity in your UI that is not X-related. The huge number of shared libraries used in GNOME, for instance, may affect startup times for your applications, making it seem as though something takes "forever" to pop up its first window. (More later.) Responsiveness while running an app can be due to system paging, or due to the speed of the IPC mechanisms - GNOME uses its own Bonobo component architecture, running over the ORBit implementation of CORBA. CORBA is widely recognised as being potentially quite inefficient, though handy to program for and possible to optimise in some cases.
Solutions: if your Linux box is too heavily loaded down, well, get a bigger machine. (Not likely your problem.) If it has unacceptibly high scheduling latencies, try either Robert Love's preemptible kernel patch or Ingo Molnar's low-latency patch (or both), both of which are designed to help with specifically this. If you think ELF shared libraries are seriously bogging down application startup times, consider Jakub Jelinek's new "prelink" program, which optimises ELF binaries and libraries to do most of the run-time linking ahead of time, a technique used successfully by IRIX for years (for the same reason - IRIX, too, uses the flexible-but-slow ELF binary format). If you are swapping too much, your applications are memory hogs and you really need more memory to support them properly. If it is the GNOME ORBit-based IPC, well, not much you can do except whinge at GNOME, or help them optimise their CORBA implementation.
Overall point being: don't be so sure it's really the X client/server network-transparent protocol that's making your mouse pointer jumpy. (Indeed, if your problem is a laggy or jumpy mouse pointer, it can't be the client/server thing, since the mouse pointer is implemented entirely by the server.)
Does such a thing exist ? It would be great if there was a logo that manufacturers could put on their
packaging that indicated that they had provided ALL information required freely to the community to
develop open source drivers for its product.
Red Hat had a hardware cert of some sort (don't remember the name), but I wouldn't trust it. The very first (or maybe second) piece of hardware Red Hat managed to certify was an IBM laptop whose modem/sound card (the infamous mwave) didn't have any Linux support at all. And I think there were serious issues with at least one other built-in component, but it's been awhile. It really stank of Red Hat just selling the cert stamp without actually having any criteria.
(Yes, the mwave is now supported by Linux. But this was years ago - it sure wasn't supported back then.)
I'm surprised no one has mentioned it but Adaptec has done a very fine job supporting linux. I am not
sure how many if any of the drivers they actually wrote
That's a classic story of a hardware vendor being really unsupportive but finally seeing the light. Back in '98 or so, the Adaptec aic7xxx SCSI cards were horrible in Linux - they worked, sort of, but were really buggy. Why? The driver was completely reverse-engineered. So the word on the streets was, you want SCSI, you want Linux, get Buslogic or NCR.
Apparently Adaptec noticed the lack of ringing endorsements they were getting by the Linux crowd, so they put a guy on going through the Linux / FreeBSD drivers with specs in hand. Magically, the drivers improved and suddenly people started saying, you want SCSI, you want Linux, Adaptec works great. A year or two ago, Justin rewrote the aic7xxx driver again, and now it's even more solid. Way to go.
Actually, you can get the sourc for the nVidia drivers for the purpose of compiling it for your own
machine. You're just not supposed to read it.
Have you looked closely? Last I remember, you got the source for a small part of the drivers for the purpose of compiling on your own machine. The deep magic still happened in the *.o file(s) you got no source for. The driver source you got was just a shim layer to make sure the Real Driver could work correctly with your current Linux kernel.
Can I, with X, set my keyboard to be one networked device, my mouse to be another networked device and
the screen be another?
No - not yet anyway. It is interesting to look at how the X display model has held up over the years. As most of you know, the DISPLAY=myhost:m.n specification allows for multiple hosts (addressed by TCP/IP), multiple display servers per host (doing business on separate TCP ports, 6000+m), and multiple screens per display. Each display has a single set of input devices, which is shared across however many screens it has.
The X protocol designers clearly saw the need for multiple display servers per machine, and this is used for many things - most often, perhaps, running multiple X sessions on a single head, which you can switch between, but also running "fake" X servers which are actually tunnel endpoints with ssh or lbxproxy. However, the multiple-screens capability has mostly gone unused - since it would force an application to specify a particular screen number when drawing a new window. Applications shouldn't have to care about confining windows to particular monitors, so the usual solution is for the X server to present a single logical screen (SLS) larger than any one physical screen. This is one of the few instances I know of where the X protocol turned out to be too general.
OK, back off the tangent. What you propose is sort of the opposite to the screen model, and it won't work, at least not the way X is designed currently. Basically, all applications on a desktop have to use the same core pointer (mouse) and core keyboard. Why? Because the X server is only geared to showing one mouse pointer on the screen, and the window manager must know unambiguously where it is at all times so it can raise windows to the foreground, switch input focus, etc. And speaking of input focus, there is no provision within the ICCCM [the standards and guidelines for X window management) for keeping track of application keyboard focus with multiple keyboards possibly targeted to multiple applications.
In short, the keyboard and mouse must be common to all clients of a specific X server. That in turn implies that you couldn't set a client variable to use such-and-such a mouse or keyboard, since there's no way to guarantee that all clients have the same variable set. You'd have to configure it at the server end.
Which isn't to say you couldn't write an X input driver that internally gets its data from TCP/IP or bluetooth or something....
Re:X kicks ass, XFree86 doubly so.
on
XFree86 10 Years Old
·
· Score: 5, Insightful
Linux needs to consider running X on top of the desktop rather than underneath it. Implement versions of
GTK/QT that talk to the framebuffer directly and run KDE/GNOME on top of that. I bet the performance
increase would be astounding.
So, you run Gtk+ right on the bare metal. Well, that's fine as long as you don't mind running full-screen. If you want to have more than one application running at once, someone has to arbitrate. That means you need a window manager. Then someone has to keep track of the mouse pointer - individual applications would otherwise fight over it. That includes drawing it, moving it around, changing it to the right sizes, shapes and colors on demand. I guess that would go into the window manager as well. Same goes for keyboard focus - applications can't all think they have the keyboard at the same time, now, can they? What the hey, throw that into the window manager too.
Cut 'n' paste between applications? Need some sort of message passing server. Throw that into the window manager as well, why don't we. Drag 'n' drop? More messages - have to support that in the new window manager. Session management (i.e. login, logout, and which applications to start up when you re-log-in)? Need something for that too. 3D calls to the graphics card? Someone had better arbitrate - you only want one application doing that sort of thing at a time. I guess the kernel could probably handle that, since it is already arbitrating the frame buffer.
By now you have a new "window manager" which has subsumed a lot of the complexity of the X server. Sure, you are no longer passing messages between two processes just to display 2D graphics, but I'm not really sure how much of a speedup you get just from that. As Jim Gettys (you're posting technical comments about X11, so I hope you know that name!) is fond of pointing out, lots of people think X is old, clunky and bloated, but nobody seems to be able to produce an alternative windowing system with equivalent (or even adequate) feature set but without comparable complexity.
WHY is it this way? From a bandwidth point-of-view, this is a horrible solution for a network
independent protocol. Instead of saying "draw a button at this position, caption 'OK'" you send several
kilobytes of pixel information.
What you describe is DPS, Display PostScript. The display server can run and even store code snippets sent by the client. Thus you get a completely generic environment that can still draw you exact style of buttons on demand. Think of PostScript as the pre-web-browser equivalent of Java. (:
DPS never did have a free implementation (though Display Ghostscript is around nowadays - but I have no idea how complete / usable it is) but it or similar technology appears/appeared in NeWS, NeXTStep and now MacOS X.
There are some still (rare) cases that you need to modify XF86Config by hand. I had such a case few
months ago when a friend of mine wanted to make Linux work on his P133 Toshiba Libretto.
I recently hand-tweaked mine to adjust video timings for a DLP projector. The projector doesn't need nearly as much horizontal blanking as the average CRT, but it has a fairly limited bandwidth, so I was trying to drive the v-refresh as high as possible by squeezing the blanking parameters. This is for active stereo (left and right eyes each see only half the frames) so every Hz counts. Got it from 85 Hz up to around 93 Hz that way - I know the projector can handle 96 Hz or more (I've seen it under HP-UX), but the X server and/or the graphics card seemed to think some of those numbers were just too small.
Thank goodness for ESR's video timings HOWTO. I don't know of any way in Windows to do the equivalent (OT: anyone?), so our Windows box is stuck at 85 Hz. XFree86 rules!
not trying to troll, but they could make a not network transparent version that's faster couldn't they?
Check out the MIT Shared Memory Extension, standard with XFree86 for about as long as I can remember. Actually it's still network-transparent, but if the client and server both use the SHM extension and are on the same machine, they don't go through network sockets. There are similar extensions available for local access to 3D acceleration and whole-window 2D (like for movie playback).
If you want to completely avoid having separate client/server processes, then no, to my knowledge that hasn't been done. There would be a theoretical advantage in not having to construct / parse the packets, or switch contexts between client and server, but I'm not sure if the speedup would be noticeable on modern hardware.
Ah, but in another sense they bloated their version numbers by starting with 11. What was the original XFree86 (née X386)? X11R3? X11R4? I'm pretty sure X386 came well after the X protocol reached major version 11....
A lot of great software doesn't feel the need for version number bloat. Linux (also 10 years old) hasn't yet reached version 3... Apache (about 8 years old) only recently hit version 2... NetBSD (around 10 years old, I think) hasn't hit version 2 yet... gcc (what, 15 years old or so?) is getting ready for 3.1... Mozilla (3 or 4 years old) hasn't even hit version 1 yet... oh wait, that's not generally considered a Good Thing.... (:
However, they should both use tha same low-level routines for drawing buttons,
menubars and other items. No adaptation should be neccessary for the programmers, the code hiding behind
the Qt and GTK+ API:s should be modified to handle this.
In fact, it
would be possible to get Qt to use Gdk as well, which could make shared themes possible there too.
I hadn't thought of this, but it's a good point. You (or someone you know) could port Qt to use the Gdk graphics widget set, which is what Gtk+ uses. Since both Gtk+ and Qt support multiple display systems (both run natively on Windows, for example) the apps themselves shouldn't be much the wiser.
Re:Still binary compatible.... and....
on
XFree86 10 Years Old
·
· Score: 3, Informative
still a monolith!
By what definition of "monolith"? The five or six client libraries you may or may not need to link to? The separation between client and server for display? The (optional) separation between graphics server and font server? The separation between graphics server and window manager? The separate client libraries for low-level network protocol and widget set? The loadable modules which implement everything from hardware backends to input device drivers to font rasterizers? The separation between user-space and kernel-space components (particularly for 3D graphics rendering)?
Which of the components I have mentioned so far is the "monolith" of which you speak?
I really hope you are joking and pretending to be misunderstanding things. I can't for the life of me
understand how you can achieve this catastrophical level of confusion
He or she probably conflated "twm" and "Xaw" aka the Athena widget set. Not that there are all that many "modern" programs still using Xaw, outside the X distribution itself, but that's my theory.
and still think you can
understand it enough to comment on it on slashdot.
X is the best thing around that meets the exact specifications that X does.
Yes it is.
For most of us the killer feature is network transparency. There are many windowing systems out there which do a great job of running applications on a local CPU, rendering them to a local graphics card, and taking input from local keyboards and mice. This is, however, very limiting to those of us who have been accessing our machines over networks for the past 10 years. Only recently has the Windows world achieved remote access with decent usability / performance (and I'm still not sure if there's a Windows-based remote access solution that supports input devices other than keyboard + mouse), and most other non-X graphics platforms never even made the attempt.
It's not like we are asking for a bunch of esoteric features that only found in X11. We're asking for one basic feature, network transparency. Those who marginalise this feature probably don't understand what all it can be useful for.
Slashdot Mirror
Yeah, but what about the 50% chance that your money instead helped bring him back from the moon?
So, what, a prison term == $rtbl?
Nope - they don't have to. Not unless they redistribute their new, improved kernels. "Redistribution" has been interpreted in the past (even by RMS, if I remember correctly) not to refer to in-house "distribution". Meaning: so as long as those kernels never leave DreamWorks, they don't have to give us back crap.
Here's hoping they do, though. (:
Point well taken. The users won't do a darned thing for us except provide just that much more momentum for other end-users. The admins, on the other hand ... well, reread the article - one of the last few paragraphs:
If the guy is serious about this, it is good news.
If I were you I'd look at migrating to FreeBSD or NetBSD - still free / open, and an easier migration path since they're still based on BSD. In the case of FreeBSD, doesn't Walnut Creek operate both FreeBSD and BSDi? (Come to think of it, which proprietary BSDs do you use? BSDi? NeXTStep? SunOS 4? Ultrix?)
Benefit of the doubt w/r/t trolling... (:
Name one feature X doesn't have that it would be easier to provide via a brand new graphics system than it would be to extend X to do. Or a whole set of features, if you prefer. I'll rebut what I can.
Keep in mind that X is very low-level, and that a lot of things can be layered on top of it, and a lot of things are intentionally outside its control. For example - you want application consistency? Make all the apps consistent - nothing to do with X per se. (Just like the Winamp look 'n' feel is not at all consistent with the CDPLAYER.EXE look 'n' feel - does anyone see this as a problem?)
This is much worse news for SGI than it is for Microsoft.
SGI used to own the Hollywood effects houses - anything not Mac was IRIX. Over the past few years everyone has started realising that while SGI sells the biggest and baddest NUMA, some things like 3D rendering are naturally parallelisable to such an extent that clusters make a lot more sense than NUMA. Clusters often mean Linux, for reasons I don't need to get into here. Which is, I'm convinced, the main reason SGI got into Linux in a big way a few years ago - they figured that was the way to keep their current big-spending customers. Remember that SGI "got religion" long before IBM or HP made serious noises about Linux. HP is a comparative johnny-come-lately both to Linux and to serious 3D graphics.
So losing this contract to HP and Red Hat had to hurt SGI. Bad. This was their turf, and we just saw a major failure for SGI's Linux play. Nail in the SGI coffin?
(PS: I just thought of this: it's not a total loss for SGI - they still own Alias|Wavefront, whose Maya software was used.)
Yes indeed. We have an x4000 here. Very very nice. HP's case design is a work of art in terms of usability (much better than the Dell 530). The BIOS is too cool to boot Linux 2.2 (MP table parsing bugs, I think it was) and the then-current 2.4 kernel had a bug launching an initrd, which made for a fun initial bootstrap....
And according to the article, they used "proprietary HP graphics hardware", which sounds to me like the Visualize FX/10 card. I wish, I wish HP would get their Linux act together and release a free XFree86 driver for the FX/10 already. Not that it's just HP - this binary-only crap for all the high-end graphics boards (Fire GLn, FX/10, Wildcat series, and on down to the latest NVidia offerings) is getting old fast. I don't care if you provide only binaries for Windows; that's not acceptible in Linux space.
I think you are more or less correct. You can write an application that violates patents, you just can't try to sell it.
Unfortunately, having patent infringement problems really affects widespread adoption of your software. Nobody wants to risk distributing it, for fear of the patent holder. The Debian Project, for example, won't go near patent-infringing works, unless it's something stupid like the XOR or the File/Save-As patent. Why? Partly for their own liability, but mostly because of the Debian Social Contract. Quoting from point #4 in the Social Contract:
In other words, Debian avoids patent-restricted software so that people who want to use Debian for commercial purposes - reselling official CDs, selling unofficial CDs, or making / selling derivative works - can do so without having to pore through the license texts of thousands of packages. They want you to just assume that when you download an official Debian package, you are free to use it however you wish, and free to redistribute it with or without modifications, possibly subject to some restrictions as noted in the DFSG.
Remember, even free software is bought and sold - just ask SuSE or Red Hat. And it's not likely that Red Hat can just negotiate a patent license for their customers when needed - their CD sets have too little profit margin as it is.
Not nearly as easy as it used to be. Sure, there are plenty of stupid 'xhost +' users still in the wild, but thanks to the rise of single-user Linux boxes, many distros actually default to the X server not listening on TCP/IP at all! Good for security, bad for people with xroach.
(Ahhh, fond memories of xflip, xterm -e 'echo foo; sleep 5' (aka poor man's instant messenger), NAS, ...)
I'm not sure quite what you mean to imply by the term "widget war", but really - it's not so much a war as, perhaps, an archery competition. Nobody is being hurt by the proliferation of applications under both the GNOME and KDE frameworks. It appears to me that both projects have a rich, mature library environment and rapidly maturing development tools - fragmentation doesn't seem to have hurt there. Lots of KDE users use Gnumeric and Mozilla, and lots of GNOME users use KDevelop. Developers don't even have to worry about picking the "right pony" - the two widget sets are easily compatible enough to coexist on one's desktop. (They look a lot more harmonious together than Motif versus OpenLook!)
The "KDE/GNOME war" was pretty much invented for TV, as it were. The mass media love to find a rivalry to report on. Ask any of the actual hackers involved about "beating" the "other team" and they'll probably laugh at you. The war is waged more on public fora like Slashdot among mere end-users than anywhere else - just like any other modern holy war.
You may or may not be fingering the right culprit. I know, when software seems slow or unreponsive, it is very tempting to look at it, find one thing you think is inefficient, and say "that's why this is slow".
Linux is a complex system. XFree86 is a complex system. GNOME is a complex system. The basic user experience will see factors from all three affecting perceived "speed". And often this "speed" is not actually raw speed per se, but latency - which means the amount of time needed to react to an event. Linux is known to have lousy worst-case scheduler latencies - which often don't matter, but occasionally do. Latency is a trade-off against raw efficiency and against system complexity - simpler designs are more efficient (as a rule) but have higher latencies.
There is also complexity in your UI that is not X-related. The huge number of shared libraries used in GNOME, for instance, may affect startup times for your applications, making it seem as though something takes "forever" to pop up its first window. (More later.) Responsiveness while running an app can be due to system paging, or due to the speed of the IPC mechanisms - GNOME uses its own Bonobo component architecture, running over the ORBit implementation of CORBA. CORBA is widely recognised as being potentially quite inefficient, though handy to program for and possible to optimise in some cases.
Solutions: if your Linux box is too heavily loaded down, well, get a bigger machine. (Not likely your problem.) If it has unacceptibly high scheduling latencies, try either Robert Love's preemptible kernel patch or Ingo Molnar's low-latency patch (or both), both of which are designed to help with specifically this. If you think ELF shared libraries are seriously bogging down application startup times, consider Jakub Jelinek's new "prelink" program, which optimises ELF binaries and libraries to do most of the run-time linking ahead of time, a technique used successfully by IRIX for years (for the same reason - IRIX, too, uses the flexible-but-slow ELF binary format). If you are swapping too much, your applications are memory hogs and you really need more memory to support them properly. If it is the GNOME ORBit-based IPC, well, not much you can do except whinge at GNOME, or help them optimise their CORBA implementation.
Overall point being: don't be so sure it's really the X client/server network-transparent protocol that's making your mouse pointer jumpy. (Indeed, if your problem is a laggy or jumpy mouse pointer, it can't be the client/server thing, since the mouse pointer is implemented entirely by the server.)
Red Hat had a hardware cert of some sort (don't remember the name), but I wouldn't trust it. The very first (or maybe second) piece of hardware Red Hat managed to certify was an IBM laptop whose modem/sound card (the infamous mwave) didn't have any Linux support at all. And I think there were serious issues with at least one other built-in component, but it's been awhile. It really stank of Red Hat just selling the cert stamp without actually having any criteria.
(Yes, the mwave is now supported by Linux. But this was years ago - it sure wasn't supported back then.)
That's a classic story of a hardware vendor being really unsupportive but finally seeing the light. Back in '98 or so, the Adaptec aic7xxx SCSI cards were horrible in Linux - they worked, sort of, but were really buggy. Why? The driver was completely reverse-engineered. So the word on the streets was, you want SCSI, you want Linux, get Buslogic or NCR.
Apparently Adaptec noticed the lack of ringing endorsements they were getting by the Linux crowd, so they put a guy on going through the Linux / FreeBSD drivers with specs in hand. Magically, the drivers improved and suddenly people started saying, you want SCSI, you want Linux, Adaptec works great. A year or two ago, Justin rewrote the aic7xxx driver again, and now it's even more solid. Way to go.
Have you looked closely? Last I remember, you got the source for a small part of the drivers for the purpose of compiling on your own machine. The deep magic still happened in the *.o file(s) you got no source for. The driver source you got was just a shim layer to make sure the Real Driver could work correctly with your current Linux kernel.
Has this changed?
No - not yet anyway. It is interesting to look at how the X display model has held up over the years. As most of you know, the DISPLAY=myhost:m.n specification allows for multiple hosts (addressed by TCP/IP), multiple display servers per host (doing business on separate TCP ports, 6000+m), and multiple screens per display. Each display has a single set of input devices, which is shared across however many screens it has.
The X protocol designers clearly saw the need for multiple display servers per machine, and this is used for many things - most often, perhaps, running multiple X sessions on a single head, which you can switch between, but also running "fake" X servers which are actually tunnel endpoints with ssh or lbxproxy. However, the multiple-screens capability has mostly gone unused - since it would force an application to specify a particular screen number when drawing a new window. Applications shouldn't have to care about confining windows to particular monitors, so the usual solution is for the X server to present a single logical screen (SLS) larger than any one physical screen. This is one of the few instances I know of where the X protocol turned out to be too general.
OK, back off the tangent. What you propose is sort of the opposite to the screen model, and it won't work, at least not the way X is designed currently. Basically, all applications on a desktop have to use the same core pointer (mouse) and core keyboard. Why? Because the X server is only geared to showing one mouse pointer on the screen, and the window manager must know unambiguously where it is at all times so it can raise windows to the foreground, switch input focus, etc. And speaking of input focus, there is no provision within the ICCCM [the standards and guidelines for X window management) for keeping track of application keyboard focus with multiple keyboards possibly targeted to multiple applications.
In short, the keyboard and mouse must be common to all clients of a specific X server. That in turn implies that you couldn't set a client variable to use such-and-such a mouse or keyboard, since there's no way to guarantee that all clients have the same variable set. You'd have to configure it at the server end.
Which isn't to say you couldn't write an X input driver that internally gets its data from TCP/IP or bluetooth or something....
So, you run Gtk+ right on the bare metal. Well, that's fine as long as you don't mind running full-screen. If you want to have more than one application running at once, someone has to arbitrate. That means you need a window manager. Then someone has to keep track of the mouse pointer - individual applications would otherwise fight over it. That includes drawing it, moving it around, changing it to the right sizes, shapes and colors on demand. I guess that would go into the window manager as well. Same goes for keyboard focus - applications can't all think they have the keyboard at the same time, now, can they? What the hey, throw that into the window manager too.
Cut 'n' paste between applications? Need some sort of message passing server. Throw that into the window manager as well, why don't we. Drag 'n' drop? More messages - have to support that in the new window manager. Session management (i.e. login, logout, and which applications to start up when you re-log-in)? Need something for that too. 3D calls to the graphics card? Someone had better arbitrate - you only want one application doing that sort of thing at a time. I guess the kernel could probably handle that, since it is already arbitrating the frame buffer.
By now you have a new "window manager" which has subsumed a lot of the complexity of the X server. Sure, you are no longer passing messages between two processes just to display 2D graphics, but I'm not really sure how much of a speedup you get just from that. As Jim Gettys (you're posting technical comments about X11, so I hope you know that name!) is fond of pointing out, lots of people think X is old, clunky and bloated, but nobody seems to be able to produce an alternative windowing system with equivalent (or even adequate) feature set but without comparable complexity.
What you describe is DPS, Display PostScript. The display server can run and even store code snippets sent by the client. Thus you get a completely generic environment that can still draw you exact style of buttons on demand. Think of PostScript as the pre-web-browser equivalent of Java. (:
DPS never did have a free implementation (though Display Ghostscript is around nowadays - but I have no idea how complete / usable it is) but it or similar technology appears/appeared in NeWS, NeXTStep and now MacOS X.
I recently hand-tweaked mine to adjust video timings for a DLP projector. The projector doesn't need nearly as much horizontal blanking as the average CRT, but it has a fairly limited bandwidth, so I was trying to drive the v-refresh as high as possible by squeezing the blanking parameters. This is for active stereo (left and right eyes each see only half the frames) so every Hz counts. Got it from 85 Hz up to around 93 Hz that way - I know the projector can handle 96 Hz or more (I've seen it under HP-UX), but the X server and/or the graphics card seemed to think some of those numbers were just too small.
Thank goodness for ESR's video timings HOWTO. I don't know of any way in Windows to do the equivalent (OT: anyone?), so our Windows box is stuck at 85 Hz. XFree86 rules!
Check out the MIT Shared Memory Extension, standard with XFree86 for about as long as I can remember. Actually it's still network-transparent, but if the client and server both use the SHM extension and are on the same machine, they don't go through network sockets. There are similar extensions available for local access to 3D acceleration and whole-window 2D (like for movie playback).
If you want to completely avoid having separate client/server processes, then no, to my knowledge that hasn't been done. There would be a theoretical advantage in not having to construct / parse the packets, or switch contexts between client and server, but I'm not sure if the speedup would be noticeable on modern hardware.
Ah, but in another sense they bloated their version numbers by starting with 11. What was the original XFree86 (née X386)? X11R3? X11R4? I'm pretty sure X386 came well after the X protocol reached major version 11....
A lot of great software doesn't feel the need for version number bloat. Linux (also 10 years old) hasn't yet reached version 3 ... Apache (about 8 years old) only recently hit version 2 ... NetBSD (around 10 years old, I think) hasn't hit version 2 yet ... gcc (what, 15 years old or so?) is getting ready for 3.1 ... Mozilla (3 or 4 years old) hasn't even hit version 1 yet ... oh wait, that's not generally considered a Good Thing.... (:
<whew> - you just saved someone a lot of work. (:
Did you read the interview with Nat Friedman yesterday? Last question, third paragraph of his answer:
I hadn't thought of this, but it's a good point. You (or someone you know) could port Qt to use the Gdk graphics widget set, which is what Gtk+ uses. Since both Gtk+ and Qt support multiple display systems (both run natively on Windows, for example) the apps themselves shouldn't be much the wiser.
By what definition of "monolith"? The five or six client libraries you may or may not need to link to? The separation between client and server for display? The (optional) separation between graphics server and font server? The separation between graphics server and window manager? The separate client libraries for low-level network protocol and widget set? The loadable modules which implement everything from hardware backends to input device drivers to font rasterizers? The separation between user-space and kernel-space components (particularly for 3D graphics rendering)?
Which of the components I have mentioned so far is the "monolith" of which you speak?
He or she probably conflated "twm" and "Xaw" aka the Athena widget set. Not that there are all that many "modern" programs still using Xaw, outside the X distribution itself, but that's my theory.
Heh. As you say, this is slashdot.
Yes it is.
For most of us the killer feature is network transparency. There are many windowing systems out there which do a great job of running applications on a local CPU, rendering them to a local graphics card, and taking input from local keyboards and mice. This is, however, very limiting to those of us who have been accessing our machines over networks for the past 10 years. Only recently has the Windows world achieved remote access with decent usability / performance (and I'm still not sure if there's a Windows-based remote access solution that supports input devices other than keyboard + mouse), and most other non-X graphics platforms never even made the attempt.
It's not like we are asking for a bunch of esoteric features that only found in X11. We're asking for one basic feature, network transparency. Those who marginalise this feature probably don't understand what all it can be useful for.