Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
X Software GUI Linux

Significant Interactivity Boost in Linux Kernel 673

Posted by CowboyNeal
from the speed-bump-removal dept.
An anonymous reader writes "The Linux kernel team is at it again. Linux creator Linus Torvalds recently proposed a patch to offer interactive processes a boost, greatly benefiting the X desktop, as well as music and movie players. O(1) scheduler author Ingo Molnar merged Linus' patch into his own interactivity efforts, the end result nothing short of amazing... The upcoming 2.6 kernel is looking to be a desktop user's dream come true."
This discussion has been archived. No new comments can be posted.

Significant Interactivity Boost in Linux Kernel

Comments Filter:
  • by Omikr0n (656115) on Saturday March 08, 2003 @12:08PM (#5467387)
    Finally!

    I cannot tell you how long I've been waiting for something like this. As an avid Microsoft fan, one of my biggest beefs was the inferior performance of the Linux GUI and its components. Although I will learn the console eventually, I will still probably use the GUI as my cheif method of computing since I find it very fast and efficient. Maybee this will finally blur the line between OS's enough to get more people to switch over.

  • Re:left, no right! (Score:5, Insightful)

    by Ed Avis (5917) <ed@membled.com> on Saturday March 08, 2003 @12:17PM (#5467436) Homepage
    There's no reason not to implement both high-throughput scheduling for big servers and low-latency scheduling for desktops in the same kernel... just mark each process table entry with a bit saying whether this process is 'interactive' (favour fairness and low response times) or 'batch' (favour total throughput and bigger timeslices at the expense of fairness).
  • Re:left, no right! (Score:3, Insightful)

    by binkley (25431) <binkley@alumni.rice.edu> on Saturday March 08, 2003 @12:22PM (#5467465) Homepage
    For that matter, why are you trying to do two completely different work loads and environments with the same kernel? You compile the kernel tuned to batch workloads for the server, and recompile the kernel tuned to interactive workloads for the desktop. You have the source.
  • Re:left, no right! (Score:1, Insightful)

    by Anonymous Coward on Saturday March 08, 2003 @12:24PM (#5467471)
    Many people are not gonna compile their own kernel, especially those running something like Redhat in a corporate environment. It makes more sense to code it to work either way.
  • by Khomar (529552) on Saturday March 08, 2003 @12:26PM (#5467475) Journal

    "As an avid Microsoft fan..."


    And you admit this on Slashdot?! You are brave.

  • by arvindn (542080) on Saturday March 08, 2003 @12:31PM (#5467512) Homepage Journal
    If the scheduler could "see" what the user is doing, then it could make the desktop appear fabulously responsive, by detecting which program the user is currently looking at. But it can't. So it has to use heuristics based on the behavior of programs wrt. how often they compute/get events etc. Windows tries to blindly give priority to the application that's in the "foreground", and ends up screwing everything else. However, it is really possible to achieve close very good interactivity through clever kernel architecture: Beos did it years ago. Lets see if Linux will do better.

    Note that responsiveness is not something that will scale with increasing processor speed. So these patches could really have an effect in setting the Linux desktop experience apart. Will this help to capture desktop market share? Whoda thunk it :)

  • Re:left, no right! (Score:5, Insightful)

    by einhverfr (238914) <chris@travers.gmail@com> on Saturday March 08, 2003 @12:41PM (#5467561) Homepage Journal
    Many people are not gonna compile their own kernel, especially those running something like Redhat in a corporate environment. It makes more sense to code it to work either way.

    How about this radical idea--

    Let Red Hat, SuSE, etc. compile different kernels with different options and install them as needed ;-) That means a desktop edition could install a low-latency version and a server edition could install a high-throughput version.
  • Err (Score:5, Insightful)

    by bogie (31020) on Saturday March 08, 2003 @12:47PM (#5467592) Journal
    " As an avid Microsoft fan, one of my biggest beefs was the inferior performance of the Linux GUI and its components."

    That would depend on exactly what you talking about. Those linux users running something like Blackbox would laugh at you for saying so. I'd also suggest as a user of both, KDE and XP have about the same interactive performance as well.

    There's no doubt Windows still has more polish than Linux as a whole when it comes to the desktop. And while anything that improves any of LInux's many "gui's" is a welcome event, Linux's gui's are hardly inferior performance-wise across the board like your implying.

    "Maybee this will finally blur the line between OS's enough to get more people to switch over."

    Performance doesn't rate very high on why windows users aren't switching over. Lack of familiar apps and games, lack of widespread OEM bundling, and lack of millions in marketing are what's keeping people from switching over.
  • Re:left, no right! (Score:4, Insightful)

    by shokk (187512) <<moc.oohay> <ta> <otropoeinre>> on Saturday March 08, 2003 @12:48PM (#5467598) Homepage Journal
    Or using that snazzy bootloader technology, both kernels can be compiled and the kernel that gets loaded is determined by a variable in lilo.conf, making it easier to set desktop or server room performance in a corporate environment.
  • Re:X11 Beh. (Score:1, Insightful)

    by Anonymous Coward on Saturday March 08, 2003 @12:51PM (#5467616)
    Bad attempt at a troll. Very high end graphics card and very very high end cpu? Perhaps very high end from 4 years ago. My 4 year old box with a PII 450, 128M RAM and a GeForce 1 seem to run Windows 2000 in a much more than moderately usable state.
  • Re:left, no right! (Score:3, Insightful)

    by mcspock (252093) on Saturday March 08, 2003 @12:54PM (#5467627)
    Err, these are competing philosophies. You can't have both types of scheduling going on. Think about it: you have an interactive process which wants to use all the CPU all day long, and you have 6 server processes that want to have balanced scheduling for the clients they are handling. No matter what the scheduler chooses, it is being unfaithful to your bit for each process.

    The better answer is to either a) make this option compile time, as someone mentioned, or b) make this option configurable (a la sysctl) at runtime. This would allow distribution maintainers to adjust the setting to match the type of installation they are doing, and users on stock installations to quickly adjust the kind of scheduling they have, just like the little check boxes in windows NT/XP.
  • by iamacat (583406) on Saturday March 08, 2003 @01:01PM (#5467656)
    Which always gave boost to interactive processes by raising internal priority of the ones that didn't take up the whole CPU slice. Remember how jerky Solaris 2.x felt right after Sun killed SunOS 4.x? My BSD-based aqua desktop on the other hand is very responsive, even when playing mp3s AND doing real time video compression in the background.

    Anyway, I hope Linus and Ingo now have some spare time for real dreams of power users with Linux desktops - drivers! I used to run Linux at work and at home (used to, because I got rid of the Intel box at home). Between these two machines, I had an NVIDIA card, lucent WinModem, CLIE, Zaurus and an NTFS partition that wasn't recognized by default Redhat kernel.

    After every kernel upgrade, I had to recompile 5 drivers. CLIE and Zaurus drivers came in the form of patches that usually refused to apply, or caused a hang when the device was attached! Once I tried a 2.5 kernel because it had some features, like suspend and resume that I could really use. While the default configuration built Ok, once I enabled the drivers I wanted, I couldn't get the thing compiled even before applying my patches.

    Yes, you could just run "Redhat operating system", never upgrade the kernel and wait a few months to install a new release. Then you might find binary drivers to download for the kernel for your particular kind and number of CPUs. But the whole point of Linux (on a personal desktop) is to have some fun and try new stuff out easily.

    Linux developers really need to stabalize driver interfaces. I should be able to go to kernel.org and download the latest kernel *binary*, then install a binary driver from the CD-ROM that came from my NVIDIA card.

    USB and Firewire buses should be exposed by kernel as network interfaces, accessible to user programs through socket API. In this way, USB drivers will be both easier to write/debug AND will not contribute to Oops. For the ultimate of cool, Wine should support Windows USB drivers (my Virtual PC does!) and I should be able to just install Palm and Zaurus desktops and use them rather trying to feed ttyUSBNN to kpilot.

    Having a stable system that doesn't have to be rebooted to Windows to use some unsupported USB device is far more important than raw performance. I wish any system's developers - Linux, *BSD, Darwin, BeOS, etc - would concentrate on this goal before going back to play with cool toys.

  • by error0x100 (516413) on Saturday March 08, 2003 @01:09PM (#5467689)

    Its not just a UI issues; it does relate to the kernel in that the kernels job is to manipulate process priorities and give CPU cycles where they "should best be given". This is actually best done at the kernel level, and NOT the GUI level, because the GUI does not know about the other non-GUI processes is "competing with". I've felt for a long time that something like this should be done in both Windows AND Linux.

    Windows is TERRIBLE at this. Consider the following scenario, which most here who here run Windows XP will be able to identify with. You boot up, you've just logged in. The task bar is there on the screen, the start button there, you click on it. And nothing happens. You wait. Still nothing happens. You wait some more. You start to get annoyed and click the start button a few more times. The hard disk is grinding away while Windows XP does all sorts of "invisible stuff" in the background. The computer is about as responsive as a brick. Then after anything from 20 seconds to a minute, the start menu suddenly opens and closes rapidly in quick succession a half dozen times.

    THIS IS NOT HOW COMPUTERS SHOULD BEHAVE. Its pathetic. This is a perfect example of the necessity of this. The task bar process doesn't know about all those other background processes hogging CPU after you log in; there is no elegant way for it to magically know when to set its priority temporarily high, and for how long. But the kernel can say, OK, the user is trying to press a button, we must respond, and temporarily boost the start bar (explorer.exe) process and block the others.

    On desktop machines (i.e. not servers), user input is the most important thing. If the user presses a button, something must happen. The kernel should be continually shifting priorities around to where the user is focusing his/her input.

  • by error0x100 (516413) on Saturday March 08, 2003 @01:14PM (#5467710)

    But the kernel can say, OK, the user is trying to press a button

    Just to preempt those people who are about to jump down my throat because "the kernel is not supposed to know about things like buttons", I know that, but thats not what I meant. I was speaking on a more abstract / higher level, but obviously this can still be implemented in terms of lower down OS things, e.g. the Win32 message queue and HWND system: the "OS" *does* know when, for example, when mouse click messages are posted to the DefWndProc of an HWND, and it does know which process is associated with that HWND, etc. In the Linux OS design view, this isn't part of the kernel, no. But in Windows, this is just one layer above what Linux people would classify as being "the kernel"; in Windows there is a lower degree of separation between the two.

  • Re:X11 Beh. (Score:5, Insightful)

    by Bert64 (520050) <bert@slasTIGERhd ... ee.com minus cat> on Saturday March 08, 2003 @01:17PM (#5467725) Homepage
    Dropping X11 would be a HUGE mistake. X11 as a system is far more flexible than the gui system of windows, ofcourse this flexibility can introduce a performance hit, but theres many other things in modern os`s which sacrifice performance for features, ease of use, maintainability etc..
    But even considering the larger and more featured system, X11 is as fast, or faster, than windows on all but one of my machines, the one where its slower is because the graphics card is very poorly supported by X.
    What causes slowness more than X11 itself, is the programs running on top of it... KDE for instance, its hardly a speed demon compared to say, windowmaker.
    You dont need a high end videocard to make X smoothe, you just need one that`s well supported... my PCI ATI Rage Pro works perfectly, as does my Elsa GLoria Synergy, both are oldish 8mb pci cards.
    Any system will completely suck with poor drivers, try configuring windows to use generic vga or vesa drivers if you want a laugh.
    X11 is FAR superior to any local-display-only gui system, i have several machines here, and 1 monitor for X, apps running from each machine and displayed here and interacting smoothly with each other and with locally running apps.
  • by mrjohnson (538567) on Saturday March 08, 2003 @01:18PM (#5467731) Homepage
    "What's your point? If I give the code away, it's instantly a better program or system?"

    Why, yes.

    If I have the code, it's more valuable to me.
  • Re:NT (Score:3, Insightful)

    by mce (509) on Saturday March 08, 2003 @01:25PM (#5467768) Homepage Journal
    Noone claimed that Linus invented the technique (besides, Linux too has been using it for some time already). The only claim made about him is that he proposed that the way in which Linux uses it be changed. (It would help to actually read the article.)
  • by Bert64 (520050) <bert@slasTIGERhd ... ee.com minus cat> on Saturday March 08, 2003 @01:28PM (#5467780) Homepage
    I dont know about the OSX Xserver, but displaying a copy of xchat from a solaris box to my linux or irix box works perfectly.
    Personally i very much like the way X11 and the linux console handles cut+paste, its perfect for me, fast and doesnt require me to keep jumping between the mouse and keyboard. Ofcourse it would be better if it was configureable to satisfy people such as yourself, and also for machines with 1 button mouse.. i have to use an old mac sometimes.
  • by Kjella (173770) on Saturday March 08, 2003 @01:31PM (#5467792) Homepage
    Actually, if you need *guranteed* maximum time, like in a real-time OS, _average_ performance will be much *worse*.

    A lot more important work is to ensure "fairness", so that no processes is very slow, and in particular that near-real time processes (like playing a movie, 1/30th of a second is not real-time, it could render it _way_ faster) get "enough" time to make it play smoothly.

    From what I've been able to gather, both have been greatly improved in 2.6...

    Kjella
  • Yes, thank you (Score:3, Insightful)

    by mikers (137971) on Saturday March 08, 2003 @01:34PM (#5467806)
    Nothing like letting a linux box with say Redhat 7.3 (KDE), Evolution, 4 xterms, Mozilla, Galeon, XMMS get jittery.

    Go to xterm, try to unzip a 1 gig zip file (on a HD on that box) and the open mozilla and drag the window around...

    Wait wait wait, mouse quits moving... Then it starts jumping all over the screen. Time for a coffee.

    This is part pager and part interactive task/busy background task thing that these patches try to fix.

    That was a big turn off of the 2.4 kernel for me.

    m
  • by TheLink (130905) on Saturday March 08, 2003 @01:43PM (#5467853) Journal
    No it's the O/S fault it can't manage the start up. If it's not ready for input it shouldn't show the start button as clickable. This happens on Windows NT too.

    Another thing: try this on Windows 98. While Windows 98 is booting up, just as the desktop gets drawn, press the windows key (or wait till the task bar is just shown).

    Windows 98 crashes - you have to ctrl-alt-del and select shutdown.
  • by vidarh (309115) <vidar@hokstad.com> on Saturday March 08, 2003 @02:09PM (#5467973) Homepage Journal
    There's a patch for making the Linux scheduler preemptive within kernel space as well, however that wouldn't solve the problem that has now apparently been solved, which is that many tasks that are themselves considered non-interactive by the scheduler still dramatically affect interactive behaviour because a lot of interactive tasks depend on them.

    X is the most important example, since it doesn't help how much CPU your xterms or other X clients you run get if X doesn't get enough CPU time to service them, as if X doesn't get enough time the only thing extra CPU time will give your x clients is the ability to go back to sleep faster and more often.

    Realtime scheduling is something else alltogether. Realtime scheduling is about predictability, not about CPU time allocated. With a realtime scheduler you can guarantee that task A get some time at least every 10ms, for instance, but if you're maxing out the CPU you still need a way of deciding which tasks have priority, or reduce their overall time slices.

    The kernel patches in question attempts to decide which tasks to give priority automatically, instead of resorting to hacks like using nice on specific processes. It achieves that by making the assumption that if task A is interactive, and it frequently waits on B, then task B needs to get more CPU too.

    Since a high load desktop scenario will likely have lots of clients waiting on X the result is that X will get more CPU even if X itself isn't an interactive task, and hence the machine will hopefully feel more responsive.

    The way this is being accomplished is good because it doesn't special case - any non-interactive task that provides vital services to interactive tasks will get more CPU (though in this particular implementation, I believe only if they communicate using Unix domain sockets), without the user or developers having to guess which processes should get it.

  • Re:left, no right! (Score:3, Insightful)

    by stienman (51024) <adavis@@@ubasics...com> on Saturday March 08, 2003 @02:14PM (#5467999) Homepage Journal
    The first rule of kernel development is

    Users are dumb.

    Not necessarily the users using the system, but the users developing software for it. If you give them the option of choosing whether their program is scheduled as an interactive process or a batch they will always choose the wrong one.

    "Why yes, that is my elitist attitude you are observing. Please be careful with... Doh!"

    -Adam
  • by Anonymous Coward on Saturday March 08, 2003 @02:28PM (#5468054)
    I think Windows' problem is that on startup it is trying to start all services at the same time, which leads to a lot of unneccessary disk trashing (clearly the HD is the limiting part during Windows startup). A more reasonable procedure would be to start things in sequence. Unfortuantely, in Windows it's practically impossible to influence the timing of startup.
  • Re:Err (Score:2, Insightful)

    by Fembot (442827) on Saturday March 08, 2003 @02:43PM (#5468137)
    On my machine with black box or afterstep as soon as I hit login on xdm/kdm etc its loaded and ready to go. It literaly is that fast.
  • Re:left, no right! (Score:2, Insightful)

    by Nix0n (649693) on Saturday March 08, 2003 @02:47PM (#5468155)
    For that matter, why are you trying to do two completely different work loads and environments with the same kernel? You compile the kernel tuned to batch workloads for the server, and recompile the kernel tuned to interactive workloads for the desktop. You have the source.

    Plenty of people, particularly java developers, like to run local instances of various servers on the same box they use as a workstation. This can often increase a developer's productivity in certain development environments for small-to-medium sized projects.

    Don't think every user is exactly like you and has no need for the proposed change. Proposals such as this, and their subsequent implementation, are the primary strength of open source.
  • by jbolden (176878) on Saturday March 08, 2003 @02:55PM (#5468195) Homepage
    If you think about moving a window in terms of drawing dots on the screen you quickly realize it is rather complicated. Lines need to get shifted over, other windows need to know they can no longer certain areas of the screen. Background stuff needs to get redrawn which often means that windows need to be called to redraw.

    Old fashioned managers handled this by simply giving you an outline of the window you were moving and then doing a full screen redraw. The newer system (say the last 10 years) has been to actually do this real time with dozens of small redraws. This is very CPU intesnive. Further there is an accurate measuring device (the human eye) which notices lacks of performance very quickly.

    On a single tasking machine where the computer could dedicate itself to doing this task this still wouldn't present a problem. On a modern OS with dozens of processes running doing things like the above is a scheduling nightmare. A very complicated scheduling system is out because the scheduling system needs to run so many times a second. The result is you need to think of cool tricks to make this work.

    The cool trick that windows thought of was using the notion of "forground" and "background" to and thus giving certain apps a massive CPU advantage while others got little if any attention except when the CPU wasn't busy. The problem with that is that it forces the user to either:

    a) Have extremely unreliable background processes (default for windows NT/2000/XP desktop)

    b) Have an unresponsibe desktop (default for the NT/2000.. server)

    More importanly this forground/background solution doesn't solve the problem of competing demons which are having other types of CPU problems.

    So Linux long ago rejected this cool trick and there is no notion of "forground" and "background". They were going to handle the problem right or not at all. Now with tuning you can make this particular X related problem go away but only at the cost of introducing other problems, and more importanly all you are really doing is covering the symptom of the disease not curing the diesase. The kernel group has figured out a general solution which improves scheduling for all applications without substantially increasing the complexity of the scheduler.

    Unlike many kernel improvements this one will have substantial impact on desktop performance right out of the box when distributions start shipping with the 2.6 series which is why people are excited.
  • Re:left, no right! (Score:2, Insightful)

    by azzy (86427) on Saturday March 08, 2003 @03:14PM (#5468292) Journal
    To paraphase Linus, his patch is not doing anything especially for X or the desktop. But for processes that have a particular behaviour, and this behaviour is easily seen in X. This patch combo tries to aid any interactive process. Whether an X server, or an IM server, etc etc. So this makes interactivity better all around. Bonus for desktop, bonus all round. Of course.. i could have totally misunderstood :)
  • by Anonymous Coward on Saturday March 08, 2003 @04:09PM (#5468554)
    Solaris has had a choice of schedulers for some time. I think this is more a demonstration that UNIX system programmers "get it" than that Open Source programming leads to superior results.

    Please direct any assertions that Solaris is "Open" to /dev/null -- I am referring to the development methodology/philosophy, not whether I can see the source w/out signing an NDA in blood.

  • by dusanv (256645) on Saturday March 08, 2003 @04:24PM (#5468607)
    Sure. Now use any method at all to copy between OpenOffice and Mozilla. Let me know when you figure that one out without using a third app. No, X11 cut and paste *is* broken (or rather, there is no standard) and it really ought to get fixed.
  • by b0r1s (170449) on Saturday March 08, 2003 @04:24PM (#5468609) Homepage
    What they haven't (yet) realized is that most people don't want to have to turn off their computers ever. They are just forced to reboot all the time by crappy "features" such as these.

    Completely wrong. Most people only care that their computers work reliably for up to 8 hours at a time, and shut them off when they're not in use.

    Most people don't 24x7 uptime, and wouldn't want it anyway: computers use quite a bit of power, and power costs money.

    Indeed, most people I know turn their computers off when not in use.
  • by catenos (36989) on Saturday March 08, 2003 @04:49PM (#5468687)
    What's being described here is called a priority inversion, where a high-priority task makes a request of some service running at a lower priority and gets hung up behind it.

    Which is wrong. Did you read the article?

    Priority inversion is, as you explained yourself, about a high priority task effectively getting a low priority by being dependend and therefore waiting on a low priority task.

    The article is about tasks at the same priority[1]. The task scheduler distinguishes between interactive and non-interactive tasks in order to improve latency where the user cares.

    Beforehand, the behaviour failed on a slow, loaded system to recognize the X server as interactive, because then X looks like a CPU-hog[2]. That resulted in freezes of several seconds[3]. Simply speaking, the patch solves this by passing some interactivity points between processes.

    You could have easily seen that this is not about priority inversion as one of the suggested work-arounds was to simply increase the niceness of the X process (which wouldn't help, if priority inversion had been the problem).

    Regarding QNX: As good as it is as a RTOS, as bad it fails to do something sensible when you have too much processes at the same priority. Having a reasonably working system presumes that each task is assigned an appropriate priority. Of course, the people at QNX did a decent job on the default priorities.

    [1] It may have an impact on tasks of different priority. I did not care to investigate that aspect, because that is of minor importance to what the patch is about.

    [2] And for the scheduler, interactivity is determined by a process going to sleep often (by waiting for interaction).

    [3] For non-interactive processes it is beneficial to do them in larger hunks, i.e. let 5 seconds other processes do their work, then work 5 seconds, instead of having 0.01 second slices and do the switching all the time.
  • by Animats (122034) on Saturday March 08, 2003 @05:32PM (#5468872) Homepage
    The article is about tasks at the same priority[1]. The task scheduler distinguishes between interactive and non-interactive tasks in order to improve latency where the user cares.

    When you treat tasks differently, you're prioritizing them. All the priority information isn't necessarily encoded into the UNIX-type priority number. This is a nomenclature distinction between "priority" in the formal sense of "who gets the (a) CPU", vs. the classical UNIX representation of priority numbers.

  • by Featureless (599963) on Saturday March 08, 2003 @06:37PM (#5469153) Journal
    Someone comes along and points out X's shortcommings and calls for its replacement. Someone else (who fancies themselves older and/or wiser) comes along and disagrees strenuously, and tries to make X11 out to be the greatest UI ever created. Look... it's "network transparent," it's "flexible," it's "fast," we can just extend it to give it whatever features it lacks, etc. etc.

    Ugh. I don't buy it.

    To put it in perspective, lots of Unix has a big organization problem. X is just emblematic. It's "lower-level" APIs are a big stinking mess. Ever tried to program against it without a super-high-level bit of middleware? Then let's talk about how nice it is. If you're not up on this, try reading JWZ's rants on it (many written as he was porting Netscape)? X is a 4 foot high sandwich of crap, layer after layer between you and the display, full of massive, sucking complexity, the bugs, inefficiency... even during this supposedly wonderful "network transparent" windowing this foul stew shows its colors, as no combination of two applications or X servers quite looks the same. It's a verifiability nightmare, too, of course (and for instance, disabling X's many attempts to listen and talk on the network are one of the first things you do to secure a machine properly - and for real security, you avoid installing X altogether).

    The API design itself is atrocious. The much-touted "flexibility" is really code for laziness - it was a lot of work to do a proper GUI, so no one did it. The mishmash of X server extensions, window managers, font handling systems, etc. that's been cobbled together has led to a nightmare for both programers and users, as any given application doesn't just require "X", but a complex recipe of libraries and versions, and an end-user experience where no two applications look or act the same... or even remotely similar... Where cutting and pasting between windows is a pipe dream, and young geniuses still struggle to configure fonts properly for linux distributors.

    Or to just put it plainly, as my friend (who from time to time would write X windows gadgets) would say, it's only about twice as hard as managing the video memory yourself.

    "And thank god it's not all standardized, or we'd never have had all those wonderful experiments with different ways to do a GUI that never actually happened." In practice, no system is immune from its initial design choices, and it's been an endless series of awful MacOS knockoffs, multi-button madness, color-pallete spinning goofiness. Is X11 a "GUI experimenters toolbench?" Then I think it's time for something a little more grounded in everyday realities of computer use.

    I'm not even warmed up yet. I mean, X is still peppering the filesystem with a hedge-maze of exotically formatted text files describing the hex colors of every pixel of the trim of every window for a variety of appliations and classes in a complex inheritance and assignment scheme that few X developers even understand. Check it out, your XDefaults are "human readable."

    Shall we even discuss its security model?

    Modern Linux has tried to make its peace with X through wrappers, and we write against Tcl/Tk, Qt, inside the Gnome or KDE framework, and yet still the focus groups come back crying... we try to blame overfamiliarity with windows, but the problems are bigger... all of Unix (and of course Linux) suffers from the same class of problems that X does; as, for instance, an application needs to prompt you to insert a series of CD's, but there is no "single, authoritiative, standard" place to go find out what CD drives are installed on the computer, and what their device names are (yes, we know what they _usually_ are), and finding out if any of the CDs are already inserted involves parsing the text output of a proc file or a mount command, and so on and so forth... And all of this is being done by a messy bash script... so it's no surprise this functionatlity is broken even in, for instance, RedHat's own v8 package manager... I hope you can grasp the metaphor.

    It's a mess. Patches won't clean it up. Frankly, it's time we took the whole GUI back to the drawing board. But even if MacOS is the end-all/be-all, we can do it a hell of a lot better than we do in X.

    Following are some choice quotes from Don Hopkins' [art.net] essay:

    X-Windows is the Iran-Contra of graphical user interfaces: a tragedy of political compromises, entangled alliances, marketing hype, and just plain greed. X-Windows is to memory as Ronald Reagan was to money. Years of "Voodoo Ergonomics" have resulted in an unprecedented memory deficit of gargantuan proportions. Divisive dependencies, distributed deadlocks, and partisan protocols have tightened gridlocks, aggravated race conditions, and promulgated double standards.

    X has had its share of $5,000 toilet seats -- like Sun's Open Look clock tool, which gobbles up 1.4 megabytes of real memory! If you sacrificed all the RAM from 22 Commodore 64s to clock tool, it still wouldn't have enough to tell you the time. Even the vanilla X11R4 "xclock" utility consumed 656K to run. And X's memory usage is increasing.

    ...

    X was designed to run three programs: xterm, xload, and xclock. (The idea of a window manager was added as an afterthought, and it shows.) For the first few years of its development at MIT, these were, in fact, the only programs that ran under the window system. Notice that none of these program have any semblance of a graphical user interface (except xclock), only one of these programs implements anything in the way of cut-and-paste (and then, only a single data type is supported), and none of them requires a particularly sophisticated approach to color management. Is it any wonder, then, that these are all areas in which modern X falls down?

    ...

    As a result, one of the most amazing pieces of literature to come out of the X Consortium is the "Inter Client Communication Conventions Manual," more fondly known as the "ICCCM", "Ice Cubed," or "I39L" (short for "I, 39 letters, L"). It describes protocols that X clients ust use to communicate with each other via the X server, including diverse topics like window management, selections, keyboard and colormap focus, and session management. In short, it tries to cover everything the X designers forgot and tries to fix everything they got wrong. But it was too late -- by the time ICCCM was published, people were already writing window managers and toolkits, so each new version of the ICCCM was forced to bend over backwards to be backward compatible with the mistakes of the past.

    The ICCCM is unbelievably dense, it must be followed to the last letter, and it still doesn't work. ICCCM compliance is one of the most complex ordeals of implementing X toolkits, window managers, and even simple applications. It's so difficult, that many of the benefits just aren't worth the hassle of compliance. And when one program doesn't comply, it screws up other programs. This is the reason cut-and-paste never works properly with X (unless you are cutting and pasting straight ASCII text), drag-and-drop locks up the system, colormaps flash wildly and are never installed at the right time, keyboard focus lags behind the cursor, keys go to the wrong window, and deleting a popup window can quit the whole application. If you want to write an interoperable ICCCM compliant application, you have to crossbar test it with every other application, and with all possible window managers, and then plead with the vendors to fix their problems in the next release.

    In summary, ICCCM is a technological disaster: a toxic waste dump of broken protocols, backward compatibility nightmares, complex nonsolutions to obsolete nonproblems, a twisted mass of scabs and scar tissue intended to cover up the moral and intellectual depravity of the industry's standard naked emperor.

    Using these toolkits is like trying to make a bookshelf out of mashed potatoes.
    - Jamie Zawinski

    ...

    The fundamental problem with X's notion of client/server is that the proper division of labor between the client and the server can only be decided on an application-by-application basis. Some applications (like a flight simulator) require that all mouse movement be sent to the application. Others need only mouse clicks. Still others need a sophisticated combination of the two, depending on the program's state or the region of the screen where the mouse happens to be. Some programs need to update meters or widgets on the screen every second. Other programs just want to display clocks; the server could just as well do the updating, provided that there was some way to tell it to do so.

    ...

    What this means is that the smarter-than-the-average-bear user who actually managed to figure out that

    snot.fucked.stupid.widget.fontList: micro

    is the resource to change the font in his snot application, could be unable to figure out where to put it. Suzie sitting in the next cubicle will tell him, "just put it in your .Xdefaults", but if he happens to have copied Fred's .xsession, he does an xrdb .xresources, so .Xdefaults never gets read. Susie either doesn't xrdb, or was told by someone once to xrdb .Xdefaults. She wonders why when she edits .Xdefaults, the changes don't happen until she 'logs out', since she never reran xrdb to reload the resources. Oh, and when she uses the NCD from home, things act `different', and she doesn't know why. "It's just different sometimes."

    Joe Smartass has figured out that XAPPLRESDIR is the way to go, as it allows him to have separate files for each application. But he doesn't know what the class name for this thing is. He knows his copy of the executable is called snot, but when he adds a file Snot or XSnot or Xsnot, nothing happens. He has a man page which forgot to mention the application class name, and always describes resources starting with '*', which is no help. He asks Gardner, who fires up emacs on the executable, and searches for (case insensitve) snot, and finds a few SNot strings, and suggests that. It works, hooray. He figures he can even use SNot*fontList: micro to change all the fonts in the application, but finds that a few widgets don't get that font for some reason. Someone points out that he has a line in his .xresources (or was it a file that was #included in .xresources) of the form *fucked*fontList: 10x22, which he copied from Steve who quit last year, and that of course that resources is 'more specific' than his, whatever the fuck that means, so it takes precedence. Sorry, guy. He can't even remember what application that resource was supposed to change anymore. Too bad.

    ...

    On the whole, X extensions are a failure. The notable exception that proves the rule is the Shaped Window extension, which was specifically designed to implement round clocks and eyeballs. But most application writers just don't bother using proprietarty extensions like Display PostScript, because X terminals and MIT servers don't support them. Many find it too much of a hassle to use more ubiquitous extensions like shared memory, double buffering, or splines: they still don't work in many cases, so you have to be prepared to do without them. If you really don't need the extension, then why complicate your code with the special cases? And most applications that do use extensions just assume they're supported and bomb if they're not.

  • by KJKHyperion (593204) on Saturday March 08, 2003 @09:59PM (#5469800)

    Heh, nice to see them giving up and implementing the priority boost. I wish them the best luck implementing the detection of "foreground" tasks, with an user interface with so little contact with the processes it serves

    Don't you know what this patch is about? Well, ever noticed how on Windows the three/four most used programs among the currently open tend to display their windows instantly when switching between them, not cause the disk to swap at all, be generally more responsive? It's because the Win32 subsystem gives foreground tasks a slight sheduling priority boost, and frees up background tasks' unused resources (the on-screen buffers of windows, I guess) as required by the foreground tasks' needs

    You (and I mean you, random Slashdotter talking out of your ass) can easily see how X11 can't possibly compete on equivalent hardware, no matter how hard they try:

    • kernel-mode means one thing: everything happens in-process. You don't need to switch to another process's context to safely access shared resources. This means that the "system" (whatever that means) doesn't need to be notified when a task goes background - the task knows it, and it calls into the kernel, becoming the server process for the small amount of time it takes to access global resources
    • even shared memory and message passing instead of sockets won't speed up X11 much. Windows kicked X11's ass even when it had an user-mode GUI subsystem: the Windows NT team realized the importance of a responsive GUI, and invented a special synchronization object, the low-high pair, with the sole, specific purpose of synchronizing together a client and a server thread with the minimum overhead possible (in fact, extending the scheduler with a new waiting reason for threads)

I have never seen anything fill up a vacuum so fast and still suck. -- Rob Pike, on X.

Working...