Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

[P]
Why the X server should be an "ex-" server!

By MoxFulder in Technology
Thu Nov 02, 2000 at 06:23:25 AM EST
Tags: Software (all tags)
Software

First off, I'd like to applaud the developers of both KDE and Gnome. They've done an admirable job of increasing the usefulness of Linux as a desktop OS, with standard and user-friendly interface design, suites of useful and standardized applications, graphical configuration, and more.

But nagging details still hold both desktop environments back. Who hasn't tried to get a wheely-mouse to work by clicking on Gnome Control Center, only to find that Gnome has its hands tied by the underlying X server? And who has ever copied an image from Gimp to the clipboard and back, without a complimentary mangling courtesy of the X server?


The X Window System is the silent partner in all Linux desktop environments to date. By itself, X is rather harmless, mostly because it doesn't do all that much. An X server isn't much more than a glorified raster graphics library like SVGALib, providing routines to plot pixels and requisition rectangular windows of the screen. Oh, and let's not forget that it allows mouse and keyboard input :-)

As is pointed out in The X-Windows Disaster, X provides a graphics mechanism but hardly any user-interface policy. That's why there are so many "standard" interface toolkits, "standard" keybindings, "standard" drag and drop and clipboard protocols, etc. Have you ever used "xedit"? Try running it and then you'll see the beautiful X user-interface in all its glory! No wonder the Motif, Tk, Gnome, and KDE toolkits were invented!

KDE and Gnome are the latest and greatest user-interface policy layers superimposed on the X Window System. Both do a good job of providing a standardized interface, and they are fast improving. But they are still at the mercy of the underlying X server! Too often, Gnome or KDE are rendered helpless by the surly X server, which must be tamed through the XF86Config file, whose friendly looking file format has lured in many a newbie.

Additionally, X is a memory hog ... I'm not sure why it is using 47 megs of memory on my system at the moment, considering that Gnome is doing most of the hard work, but I don't really care either. X is inefficient and wasteful, needlessly bogging down the elegant desktop environment running on top of it.

Since I don't want this to be a rant, I'd like to point out my favorite feature of X: its network transparency! With just three commands, "xhost", "telnet", and "DISPLAY=", I can display a program running on the computer at work on my screen at home! Handy, that! Unfortunately, in network transparency as in all things, the X server implements the lowest common denominator in terms of policy: it transmits all graphics commands and input events directly across the network, making the protocol ridiculously slow for any truly graphical application.

To make a long story short, X has one good feature and a laundry list of annoyances, inefficiencies, and inconsistencies. To deal with these, the designers of Gnome (as an example) had to write several layers of glue libraries to keep the X server at a safe distance from user applications. Compare the Gnome program-to-hardware interface with the MS Windows application-to-hardware interface:

Gnome:

  1. Kernel Device Drivers -- Handle keyboard and mouse input.
  2. X server -- Handles graphical screen output and obfuscates keyboard and mouse,
  3. Xlib -- A horrendously complex library for basic windowed graphics,
  4. Gimp Drawing Kit -- Quarantines the atrocious Xlib within a wrapper library.
  5. Gimp ToolKit -- Provides a set of widgets, or user interface elements, like text boxes, buttons, scrollbars, etc.
  6. Gnome -- Provides internationalization, audio support, the Gnome panel, standard keybindings, standard icons, etc. MS Windows (last time I checked):
    1. Device Drivers -- Handle keyboard and mouse input and graphical screen output.
    2. Graphical Device Inteface -- Provides basic windowed graphics and drawing routines.
    3. USER.EXE -- Provides windowing, widgets, audio, etc.
    The Windows paradigm is considerably more streamlined. Now, I'm not saying that we should all be using Windows (anything but that!) In fact, the USER.EXE library is quite bloated under current versions of Windows. What I'd like to see is Linux desktop environments freed once and for all from the constraining X Window System. Here are my proposals for streamlining graphical user environments under Linux:

    • Graphical console drivers should be handled in the kernel! The Linux kernel is compiled with support for the standard text console, why should it not include support for a standard raster graphics console as well? Of course, there are many different types of graphics cards with different command sets, so each system would only use the ones it needed, as loadable kernel modules. Each could export a set of standard entry points that would make it device independent, just as the text console is (mostly) independent of the underlying graphics hardware.
    • Create standard (really!) libraries for clipboards, drag-and-drop, internationalization, audio, etc. These could be used by text applications as well as graphical ones, of course!
    • Create a better mechanism for network transparency in which the user interface (written in Java perhaps?), can be run on one computer, while the code that does the work executes on another.
    • Build graphical desktop environments on top of these!
    If we do all these things, Gnome and KDE, as well as Linux itself, should improve immensely, to the point where they are far, far better than any other desktop OS!

    Finally, let me provide some compelling evidence that graphical user interface shortcomings are to blame for Linux's lukewarm reception as a desktop OS thus far: Recently, a friend of mine got Mac OS X Beta. It's undoubtedly the best Mac OS ever, and it's based on a Unix BSD core, with a graphical desktop environment on top. The catch? The graphical environment, Aqua, is not based on X Windows, unlike nearly every other Unix graphical environment. No, it is a proprietary environment developed by Apple. Undoubtedly, Mac OS X will be a great user OS because of its intuitive and seamless graphical environment. But it won't be as dumbed down as Windows or old Mac OS's because, under the pretty pictures, there's a shell, a unix filesystem hierarchy, and text-based configuration files.

    Apple was able to break free of the inertia that bound its elegant graphical environment to weak memory management, networking, and filesystem code. Can Linux developers similarly separate our elegant OS from our obsolete and inefficient graphics model? If so, it will be a great day for Linux and for the graphical desktop!

Sponsors

Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure

Login

Related Links
o Also by MoxFulder


Display: Sort:
Why the X server should be an "ex-" server! | 46 comments (46 topical, editorial, 0 hidden)
FUD (3.15 / 13) (#1)
by evvk on Thu Nov 02, 2000 at 02:58:07 AM EST

Just because XFree86 is bloated and inefficient doesn't mean all X servers are. X is just the protocol, no one says how one has to implement the server. Yes, there's a lot that could be improved - more specifically, unnecessary stuff removed and certain graphical capabilities added (no, that's not antialiased fonts, I don't want them), but I haven't really find X limiting myself. Now, everyone is telling how <insert your favourite bloated desktop environment> should be implemented on the server side. But I don't want that bloat because I don't want that stinking environment and widgets. What could be usefull and portable, is to implement "display lists" in X for storing the information how to draw something common and then send in the command to draw that instead of all the lines.

Here's where we get to the X server sometimes consuming loads of memory - programs store graphics in the server memory as pixmaps, and some programs (read: netscape) leak. Your window manager with pixmapped themes that stretches the pixmaps may be storing a pixmap per window - X needs the ability to stretch pixmaps. Afterall it would be really inefficient to always send the graphic to the server when it is drawn (that's what is done with 'Image's, which are stored in client memory - there's MITSHM for storing in shared memory if both are running on same system).

On linux specifically, X should use GGI, if it ever was finished.

Re: FUD (3.00 / 9) (#6)
by Qtmstr on Thu Nov 02, 2000 at 06:56:01 AM EST

*sigh*. Memory leaks are a client side problem, as long as they're not in X proper, which they arn't. while(1) malloc(1000); *will* exhaust all memory on the system under Linux in a few seconds. Is this a Linux kernel bug? No! It's doing exactly what it was designed to do.


Kuro5hin delenda est!
[ Parent ]
Re: FUD (3.00 / 5) (#10)
by evvk on Thu Nov 02, 2000 at 07:36:13 AM EST

Programs not freeing ("leaking") the pixmaps they have stored in the server memory, after the pixmaps, or any resources, are not used anymore, is a client-side problem. There are many other resources than just memory that programs can "leak", and it is a client-side problem, because the server, kernel or whatever cannot know. Unless we had some fancy kernel-side GC and all.


[ Parent ]
Time to change. (2.80 / 15) (#2)
by gawi on Thu Nov 02, 2000 at 03:25:12 AM EST

Nothing can be cool for 15 years. Especially for desktop computers. The time has come to change all this. But of course, many will be unwilling to change as there are tons of X applications already developped.

Is Berlin the solution? It sure looks great on paper.

What else?

-- Are you in denial?

! (3.91 / 12) (#3)
by vsync on Thu Nov 02, 2000 at 03:31:30 AM EST

An X server isn't much more than a glorified raster graphics library like SVGALib

Except for trivial little features like network transparency. See my recent comment.

Graphical console drivers should be handled in the kernel! The Linux kernel is compiled with support for the standard text console, why should it not include support for a standard raster graphics console as well?

This is called, strangely enough, the "framebuffer" and has been in Linux for some time now. On my iMac, I've got it set up so the console driver does the acceleration and the X server just draws crap to it.

Factual errors aside, I voted it up because there are some good/interesting points, and it's of a useful length.



--
"The problem I had with the story, before I even finished reading, was the copious attribution of thoughts and ideas to vsync. What made it worse was the ones attributed to him were the only ones that made any sense whatsoever."
Drivers in kernel (4.70 / 17) (#4)
by swr on Thu Nov 02, 2000 at 04:42:23 AM EST

Graphical console drivers should be handled in the kernel! The Linux kernel is compiled with support for the standard text console, why should it not include support for a standard raster graphics console as well? Of course, there are many different types of graphics cards with different command sets, so each system would only use the ones it needed, as loadable kernel modules. Each could export a set of standard entry points that would make it device independent, just as the text console is (mostly) independent of the underlying graphics hardware.

As others have pointed out: Framebuffer.

But, there are good reasons for having graphics drivers seperated out from the kernel. For one thing, drivers written for Linux won't work with other OSs like BSD. Also, many companies can not provide kernel-level drivers for Linux because of the GPL issue (I don't know if that applies to loadable modules).

The DRI addresses these problems. As I understand it, there is a single kernel module that provides basic hardware access- DMA, AGP, etc. The DRI kernel module is the only part that needs to be ported between operating systems. Then there are XF86 modules that contain the actual drivers. These drivers are binary-compatible across operating systems (but not CPU architecture) because the ABI is the same. People are using this right now- for example, there are FreeBSD users using Matrox drivers that were compiled for Linux. DRI also bypasses the X protocol, allowing the process to talk directly to the hardware like lesser-evolved ;) systems do.



GPL (3.00 / 4) (#20)
by delmoi on Thu Nov 02, 2000 at 11:45:51 AM EST

Does not apply to loadable modules, not in Linux anyway.
--
"'argumentation' is not a word, idiot." -- thelizman
[ Parent ]
If you disagree... (4.26 / 15) (#5)
by Qtmstr on Thu Nov 02, 2000 at 06:52:38 AM EST

If you disagree so with 'provide mechanism, not policy', why are operating systems not burned into ROM (Don't tell me about Apple --- you could override their ROM). Why can keys be remapped at all? If people are so despirate for a single interface, why are there so many themes at themes.org?
Graphical console drivers should be handled in the kernel! The Linux kernel is compiled with support for the standard text console, why should it not include support for a standard raster graphics console as well? Of course, there are many different types of graphics cards with different command sets, so each system would only use the ones it needed, as loadable kernel modules. Each could export a set of standard entry points that would make it device independent, just as the text console is (mostly) independent of the underlying graphics hardware.
Pfft, and give up all hope of portability with any other platform that might run XFree? Besides, 1) X can use the Linux framebuffer as a driver, and 2) Some drivers already require kernel modules for 3d stuff (Think nVidia).
Create standard (really!) libraries for clipboards, drag-and-drop, internationalization, audio, etc. These could be used by text applications as well as graphical ones, of course!
We have them. Clipboards? The X Clipboard and the X Primary Selection. (Well, and cut buffers, but noone uses them anymore). Just because something works differently under X than it does in Windows doesn't mean it's broken. DnD? XDnd, now used by both Gnome and KDE. You have Motif DnD as well, which seems to be somewhat compatable with XDND (As I can drag from Nutscrape into the Gnome desktop). Internationalization? Already have that. Audio? OSS.
Create a better mechanism for network transparency in which the user interface (written in Java perhaps?), can be run on one computer, while the code that does the work executes on another.
Java is a *really* bad idea for this. All The World Does Not Have A JVM, Dammit, and embedding a JVM in every single piece of software would cause bloat like you've only seen in M$ products (which essentially embed a Vbscript interpreter everywhere).

You discuss OSX. This was *not* developed in-house by Apple, it is merely an extension of Display Postscript (Well, Display PDF now) that was used on the old NeXT. Display postscript does what you want, and, since Postscript is an actual turing-complete programming language, you'd be able to store that button code on a remote X server and execute it there (not that OSX has any network transparency, IIRC).

The FSF people have made some progress on an open implemenaqtion of this --- take a look at Display GhostScript.

If you can pull this off, it would truly be better than the X we have now, but there is no need to discard X completely.

What I love about X is that it's such a configurable beast --- You can make it do *anything* you want it to do, from remapping keys to displays in some odd resolution with the proper modeline. If you don't like the way X does something, fix it.


Kuro5hin delenda est!

Well said! (3.14 / 7) (#11)
by Paul_F on Thu Nov 02, 2000 at 08:04:05 AM EST

You just saved me a lot of time Qtmstr. Thank you.

Just because something works differently under X than it does in Windows doesn't mean it's broken.

You like Windows MoxFulder? Why then feel free to knock yourself out. Some of us out here like the plethora of widget sets offered by X. Personally I find a consistant UI boring looking. To me more will always be more. Mo bigger, mo better!

My guess is that Windows is so streamlined as you put it, to keep their users and developers, on the road ahead. Freedom always comes at a price, one that in X's case I am willing to pay.

[ Parent ]

Actualy (3.00 / 4) (#19)
by delmoi on Thu Nov 02, 2000 at 11:44:55 AM EST

Display PDF is no longer Turning Complete, from what I hear.
--
"'argumentation' is not a word, idiot." -- thelizman
[ Parent ]
PDF vs PS (3.00 / 3) (#21)
by dgwatson on Thu Nov 02, 2000 at 12:33:37 PM EST

PDF never WAS Turing(not turning ;) -complete. PS always has been and always will be. Beats me why Apple made OSX use PDF instead of PS, tho...

[ Parent ]
Licensing (3.66 / 3) (#35)
by Simon Kinahan on Fri Nov 03, 2000 at 11:22:10 AM EST

The main reason is that PDF is free. You have to pay to use postscript.

Also, because it is not turing complete, PDF is easier to implement in a predictable, scalable way. You can usuallt render PDF in a reasonable time period. With postscript, obviously, you can never know how long it will take to render.

Simon

If you disagree, post, don't moderate
[ Parent ]
Free Postscript (3.00 / 2) (#44)
by Qtmstr on Tue Nov 07, 2000 at 11:29:23 AM EST

Uhm... What is this 'dvips' program I have here? What about ghostscript? What are you talking about, Postscript is non-free?


Kuro5hin delenda est!
[ Parent ]
AFAIK, X11's clipboards are text-based (3.00 / 4) (#23)
by pin0cchio on Thu Nov 02, 2000 at 03:38:37 PM EST

We have them. Clipboards? The X Clipboard and the X Primary Selection.

Those clipboards assume a text (or, stretching it, XML) representation of the data. So how do you copy data to the clipboard if it isn't easily representable as text or XML, such as a bitmap or a sound sample?


lj65
[ Parent ]
Re: Text-Based (4.00 / 4) (#30)
by Qtmstr on Thu Nov 02, 2000 at 06:26:19 PM EST

Encoded, of course. Not that text image formats don't exist.


Kuro5hin delenda est!
[ Parent ]
Hmm. (3.33 / 3) (#32)
by pb on Fri Nov 03, 2000 at 05:30:31 AM EST

That would actually be *very* cool. I'd like it if I could select an image in Netscape, and paste it into elm as uuencoded text.

How about making a clipboard that implements some sort of customizable translation filters? Then I could tweak it a bit and paste that same image into elm as alt-text, or ASCII art... :)
---
"See what the drooling, ravening, flesh-eating hordes^W^W^W^WKuro5hin.org readers have to say."
-- pwhysall
[ Parent ]
Very Linux oriented... (3.78 / 14) (#7)
by pak21 on Thu Nov 02, 2000 at 07:01:24 AM EST

The story as posted seems to be assuming that everybody runs Linux, and probably even i386 Linux. There are plenty of places out there which don't (for one reason or another); my department uses a mixed Sparc Solaris/i386 Linux/Alpha Linux setup (along with a few other boxes as well). Without X, there'd be no way I could run a job on one of our powerful boxes, rather than the SparcStation 4 on my desk. I consider that a huge advantage!

[PS: Tell me you're actually using ssh, rather than telnet]



"Please tell me you're using ssh" (4.33 / 9) (#13)
by titivillus on Thu Nov 02, 2000 at 08:20:53 AM EST

The reason for that is this: ssh seamlessly and securely handles X redirection, so you don't have to worry about those three commands. Also, it does it securely, invisibly encrypting the network traffic. Sure, it slows things down, but it is better to be secure.

Not enough geeks are advocating ssh. I hear it on occasion, and most geeks I know use it, but "Don't use telnet (except for testing network protocols), use ssh!" should be shouted from the rooftops.



[ Parent ]
Actually... (3.77 / 9) (#16)
by tzanger on Thu Nov 02, 2000 at 09:34:40 AM EST

Sure, it slows things down, but it is better to be secure.

Actually SSH tends to speed up X because it compresses the datastream before it encrypts it. Strange but true...

As far as SSH/Telnet is concerned here's a datapoint from my systems: in.telnetd is not installed.



[ Parent ]
RE: Actually (3.00 / 1) (#40)
by titivillus on Sat Nov 04, 2000 at 04:02:55 PM EST

Actually SSH tends to speed up X because it compresses the datastream before it encrypts it. Strange but true...

I trust you on that, and it makes sense, but I haven't seen too much speedup and occasionally a slowdown comparing it to X redirection, but this was before I started primarily using SSH for my X-redirection needs. In those cases, I preferred the slowdown because it made the bad guys slower and easier to shoot.

As far as SSH/Telnet is concerned here's a datapoint from my systems: in.telnetd is not installed.

My home firewall blocks telnet, but I have no problem telnetting within the network.



[ Parent ]
SSH vs. Telnet (4.00 / 1) (#43)
by Delphis on Tue Nov 07, 2000 at 09:07:37 AM EST

My home firewall blocks telnet, but I have no problem telnetting within the network.

I don't use telnet ever these days.. I use SSH to log in to machines on the local network as I don't run in.telnetd on them at all, it's a security hole. It might be a local network but I didn't want to leave it open as the less clueful 'admins' (read Windows PC fixers) who also work in my department didn't realize that it was insecure so I'd rather they never type their passwords in in cleartext over any sort of network, local or internet.

I agree wholeheartedly with your earlier point about shouting the use of SSH from the rooftops.. I try to. :)

Using SSH everywhere (even locally) means it's nice and consistent to use too, i.e. you just get used to it and forget about telnet altogether. Plus the compression is nice for text in the shell as well as X. Ban telnet now! :D


--
Delphis : For Pay Distributed Processing
[ Parent ]
ssh compression & speed: YMMV (none / 0) (#46)
by kmself on Wed Nov 08, 2000 at 12:30:48 AM EST

The only definite answer is "maybe".

On local, high-bandwidth, low-latency networks, ssh probably slows the connection (though not noticably for console work) because there is both CPU and latency overhead for the compression and encryption stream. Results are minimized with increased processor speed.

On remote, low-bandwidth, high-latency networks, ssh will appear to increase throughput as bandwidth, not CPU, is your bottleneck. Opting for tools such as lbxproxy, the low-bandwidth X proxy, may further improve X performance.

The real answer is that your performance will vary with tradeoffs in bandwidth and processor speed. In general, I'd trade a bit of performance for a tremendous gain in security.

--
Karsten M. Self
SCO -- backgrounder on Caldera/SCO vs IBM
Support the EFF!!
There is no K5 cabal.
[ Parent ]

Erm... (2.80 / 5) (#17)
by simmons75 on Thu Nov 02, 2000 at 11:26:27 AM EST

except for the mention of Linux once, all that software could be ported to other platforms *cough*BSD*cough*
poot!
So there.

[ Parent ]
BSD Users on Kuro5hin ?!? (1.50 / 2) (#24)
by cypherpunks on Thu Nov 02, 2000 at 05:00:10 PM EST

> except for the mention of Linux once, all that
> software could be ported to other platforms
> *cough*BSD*cough*

<FLAMEBAIT>
Like anyone on this board actually runs BSD. :)

(well, besides yourself and I).

Heck, when I've sat in on #kuro5hin, (under a different login ID of course) somebody makes a comment along the lines of "Stupid, arrogant BSD users. Why can't they see that Linux is the ultimate OS?".
</FLAMEBAIT>

[ Parent ]
Actually *looks guilty* (2.00 / 1) (#38)
by simmons75 on Sat Nov 04, 2000 at 01:12:07 AM EST

I admire BSD and use Linux (sorry.)

I admire what I see as simplicity (for instance, the make process.../usr/shar/mk is a helluva lot easier to deal with) without actually using the darn thing. =) I'll soon rectify the situation. =)
poot!
So there.

[ Parent ]
cypherpunks (none / 0) (#45)
by jovlinger on Tue Nov 07, 2000 at 12:02:19 PM EST

I haven't seen that one in a while. All the newspapers and websites seem to have closed that login down. Can anyone confirm?

[ Parent ]
Different usages (4.20 / 5) (#34)
by chuq_r on Fri Nov 03, 2000 at 11:19:52 AM EST

I think the author (and I could be wrong on this) is speaking from the point of view of a 'home user' or similar -- i.e. someone who probably only has one machine around anyway and network transparency probably isn't as big of a concern to them as having a nice, quick, affordable computer. (Something like VNC could probably fill that gap for them well enough should it prove necessary.) For someone who simply wants the stability that a Unix system tends to provide over the crashyness of, say, Windows or MacOS, but still wants nice fast graphics and things like that, X's network transparency features add a lot of overhead and can really slow things down. In a workplace such as yours, X is a very helpful thing because you really do need to be able to run code on one machine but see the UI for it on another. However, I'd contend that something like 75-85% of total computer users don't actually need network transparency. And in this day and age of personal Unix workstations, heck, that number might well be similar among Unix users as well.

While I can't very well see actually throwing X right out and not letting anyone use it (that would be stupid), I personally would very much like to see a better alternative for situations where things like network transparency just aren't an issue and I simply want the whiz-bang-iest 2d and/or 3d performance out of my applications and not have to suffer with large amounts of RAM being used by the rasterizer like I seem to be doing with XFree86. There are all sorts of niggly issues about X (especially implementations like XFree86) that bug people every day like how colors are handled, 3d accelleration, direct hardware access (which really takes away the whole point of using X in the first place, doesn't it?) many of which are kludges or bloated hacks which are a pain to work around and make it quite difficult to write software like image editing packages where users need certain things to be exact and developers are expecting such.

Heck, if you look around a bit you'll find lots of comments about how certain implementations of X (and other platforms as well -- lets be fair here) can royally screw up colors and gamma values. I don't believe that XFree86 even considers gamma issues (please correct me if I'm wrong here) when it rasterizes images. But the differences from platform to platform sure seem to tick guys like Paul Haeberli at SGI off...

ObUnrelated: is "to tick off" an infinitive? If so, did I just split it in the last sentence of that previous paragraph?

Anyhoo, I believe X can be a great thing in certain situations, but I certainly don't believe it's good for all situations and would very much like to see an alternative for those of us who like high rasterization performance without huge system RAM costs and/or other overhead before I completely succumb to my own destructive tendencies toward hubris and try to do it myself. ;)

Chuq

[ Parent ]

GTK, Qt, and Mozilla can all change (3.53 / 15) (#8)
by Paul Crowley on Thu Nov 02, 2000 at 07:14:14 AM EST

GTK, Qt and Mozilla all have their own abstraction layer which allows them to be re-directed to other graphical environments; all of them can draw for Win32 instead of X. Mozilla's XUL is pretty much a widget toolkit all to itself, which is why it's there. So as Berlin (or Y, or whatever) becomes ready for prime time, all of the toolkits can be ported so we'll get a flood of programs ready to run straight away. I've seen a preliminary demo of some GTK stuff based on direct framebuffer draws, and I suspect the others could do the same.

If I was going to port just one, it would be Mozilla, for embedded/kiosky type environments. The huge win here is antialiased text rendering - it's worth it for that alone.

One thing that might be nice would be a client end you could run code on, so that basic widget functions (buttons lighting up as the mouse passes over, menus drop down etc) can happen fast, without network latency. But that certainly wouldn't combat bloat in the graphics layer! Most X users have the client and server on the same machine, and those who don't mostly find it usable, so increasing complexity and bloat to achieve nicer results in this rare circumstance is probably not worth the trouble. I believe Berlin's architecture is flexible enough that this could be made possible, but I'm not an expert.
--
Paul Crowley aka ciphergoth. Crypto and sex politics. Diary.

Good point (3.00 / 3) (#29)
by MoxFulder on Thu Nov 02, 2000 at 05:58:40 PM EST

You're right to emphasize that GTK, Qt, and Mozilla all complying abstract the gory details of the X server. Their toolkits can be ported to other windowing systems by rewriting the glue code. Since Gnome and KDE programming is (effectively) independent of the X server, I believe that it's time for a complete rewrite of the underlying layers!

"If good things lasted forever, would we realize how special they are?"
--Calvin and Hobbes


[ Parent ]
It is already possible (3.33 / 12) (#9)
by Nickus on Thu Nov 02, 2000 at 07:22:47 AM EST

1. The framebuffer doesn't exist on all architectures. You must remember that Linux/XFree is just a piece of a large pictures.
2. Standards are good but as long as there is now central authority that directs what is good and what is bad we won't have 100% standards. That is both a weakness and a strength of *nix.
3. You can already run a program on one machine and have the userinterface on another. You just have to do it yourself.
X isn't perfect but it is good for its purpose.


Due to budget cuts, light at end of tunnel will be out. --Unknown
True, but there's a larger issue! (2.50 / 4) (#28)
by MoxFulder on Thu Nov 02, 2000 at 05:55:11 PM EST

3. You can already run a program on one machine and have the user-interface on another. You just have to do it yourself.
Precisely! And the whole problem with the minimalist, do-it-yourself attitude of X is that it has led to many mutually incompatible ways of doing the same thing!

X isn't perfect but it is good for its purpose.
However, its original purpose (the way I see it) was merely to standardize graphics programming on Unix workstations in the '80s, so that you wouldn't have to buy two monitors and two graphics cards to run two different programs. It has definitely achieved this goal, but now I think it is time for a higher-level approach, in which many user-level interface elements are standardized as well.

"If good things lasted forever, would we realize how special they are?"
--Calvin and Hobbes


[ Parent ]
UI standardization, but not at the server level (4.00 / 1) (#39)
by evvk on Sat Nov 04, 2000 at 10:50:30 AM EST

But the user interface elements should not be standardized at the server or protocol level (or however the system would be implemented). That way we are stuck with legacy UI bloat, when people finally see the light and realize that modern GUIs are crap. X's strength (in addition to network transparency) is exactly that it provides graphics and input for any kind of graphical 2D UI. What other window systems could be used with a renegade window manager such as Ion and others? The solution is a standard UI library. Such can be built on top of X or anything. Motif used to be one, but unfortunately it was propriatary and therefore, unfortunately, has a bad reputation among the free software folk. No, it is not perfect, but I'd choose it any day over that common LGPL'd widget set, if I wanted one.

[ Parent ]
Layers (3.50 / 12) (#12)
by evvk on Thu Nov 02, 2000 at 08:14:44 AM EST

You discuss gnome having n layers. Well, IMO gnome takes the wrong approach - too much virtual compatibility with "to-be" systems that might afterall be doing everything in a totally different way. Xt/Athena/Motif do it the right way - Xlib is still used for primitives. Too little abstraction is bad, yes. But so is too many layers of abstraction, that just leads to bloat and inefficiency. I think there should always be the lowest abstraction layer (Xlib) and the highest-level layer but nothing between should be used directly. In fact, I don't even think we should have widget sets used directly (I don't like widget GUIs anyway) but should just give a general description what the UI (not specifically GUI) contains. Just as I like low-level languages such as C (and assembly) and very highlevel languages (logic, functional, though not lisp and dialects) and mostly dislike "middle-level" languages like C++, Java and such.


X is good enough (3.64 / 17) (#14)
by molo on Thu Nov 02, 2000 at 08:25:40 AM EST

I'd like to point out my favorite feature of X: its network transparency! With just three commands, "xhost", "telnet", and "DISPLAY=", I can display a program running on the computer at work on my screen at home!

Try just one command next time: "ssh -X" .. Encryption and port forwarding is a beautiful thing.

As for your complaints on speed, X was intended for remote displays on a lan. I don't think anyone was expecting people to try to run it across a modem or anything like people try to do today.

I wouldn't mind a replacement for X, as long as the major benefits (like network transparency) are maintiained.. but I don't think it will happen / catch on. Why? X is so entrenched in the way we use our GUIs that everything will need a rewrite from the ground up. Tons of work, marginal benefit.

So people have to figure out XF86. God forbid anyone should learn anything new when using a computer.

--
Whenever you walk by a computer and see someone using pico, be kind. Pause for a second and remind yourself that: "There, but for the grace of God, go I." -- Harley Hahn

Not intended to run over a modem? (3.00 / 3) (#27)
by MoxFulder on Thu Nov 02, 2000 at 05:48:54 PM EST

While it's true that the X protocol was not intended to be used over a modem connection, many people today would like to do so. So there should be an efficient way to do it ...

Plus, X is pretty darn slow even over a LAN. If I run AbiWord (for example) over the ten foot LAN cable between my computer and my IP-masqing router, it feels like I'm using EMACS over a 2400 baud modem connection ...

(By the way, thanks for pointing out "ssh -X" ... I'll admit that I've only been using ssh for a couple of months :-)

"If good things lasted forever, would we realize how special they are?"
--Calvin and Hobbes


[ Parent ]
AbiWord over LAN slow? (3.25 / 4) (#31)
by ilmari on Fri Nov 03, 2000 at 12:13:06 AM EST

How fast are these machines, and how much RAM have you got?

I often, and quite successfully run Helix GNOME and Mozilla remotely, over 3 routers, the slowest link being a 30 foot 10Mb/s UTP cable. The box running this is a Celeron 700MHz with 128MB RAM, and the display box is a Pentium II 600 or something similar (I have also used a SunRay NC for the display), and it worked quite nice.

The largest slowdown I notice is on large images, which are transfered almost uncompressed (only the compression that SSH gives). Most apps are built of many small pixmaps, cached in the X server, so they run quite well. I also notice some slowness when swithching between virtual desktops in GNOME/Sawfish


--
ilmari
[ Parent ]
at the risk of repeating myself (4.10 / 19) (#15)
by mihalis on Thu Nov 02, 2000 at 08:36:16 AM EST

Here is my comment on the other X Window story X should be fixed not dumped and in particular the following quote shows that X need not be bloated :

Xfbdev from XFree86 4.0 runs on the iPaq 3600. The X server executable is about 600KB and consumes 650KB of memory with several simple clients running. The small footprint of the server is due to the work of Keith Packard - see this

The iPaq is a handeld computer.

Now there are also some factual errors in your post as well. For example if you insist on including GDK/GTK in your list of libs needed with X, then you really should have MFC in the Windows list (I'm assuming you already included Win32 if it's in USER.EXE, I forget). That goes a long way to balancing out the "horrendously complex" xlib (not that I think it is that horrendous).

Another error (in my opinion) is not noting the severe disadvantage that embedding the graphics driver into the kernel layer has given Windows, namely really bad instability if the device driver is bad. We know this because when they did it (in the transition from WindowsNT 3.51 to 4.0, stability decreased significantly).
-- Chris Morgan <see em at mihalis dot net>

Another error (4.33 / 9) (#18)
by simmons75 on Thu Nov 02, 2000 at 11:33:17 AM EST

There's no KDE toolkit. KDE uses the Qt toolkit.

Also, X isn't that much of a memory hog. Maybe it's somehting about the author's setup that causes a reported 47M used by X. That must be, because checking my system monitor right now, I note that my current X server is taking up a little under 14M...and I've been told much of that is due to the fact that this X server erroneously reports video memory as some of the taken memory. I used to run X on a machine that had 8 megs of ram with few problems.

I agree; it's kinda sad that so many people who obviously haven't learned much at all about X11 are all too happy to replace it. Ignorance is bliss, I suppose. =) I'm all for fixing the darn thing; while I haven't upgraded mine yet, I hear that X4.x has modularized video support.

If one wants to be Linux-specific for a moment, GGI tends to be the framebuffer-on-steroids type of software. It attempts to place a layer between hardware and graphics software (including XGGI, its X server.) It's an ambitious project, and it's starting to take on a Rodney Dangerfield aspect (it don't get no respect) but it's an admirable goal.

And to the original author; the wheely-mouse is easy to fix. You have to be willing to use (GASP!) a text editor.
poot!
So there.

[ Parent ]
He he :-) (2.66 / 3) (#26)
by MoxFulder on Thu Nov 02, 2000 at 05:45:08 PM EST

Yes, of course I've gotten my wheely mouse working ... but it took a while when I first tried to do it, a couple months ago :-)

The point is not that the wheely mouse is too hard to configure, but that the whole configuration for Gnome is inconsistent because to configure some things you have to configure the underlying X server. What I'm mainly looking for is better integration of the graphical server and the graphical user environment, and not ubiquitous graphical configure tools (which I don't use all that much myself).

(And by the way, I did subtract my video RAM from the total in order to arrive at a memory usage of 47M for X :-(, unfortunately)

"If good things lasted forever, would we realize how special they are?"
--Calvin and Hobbes


[ Parent ]
RAM problem (3.00 / 2) (#33)
by chuq_r on Fri Nov 03, 2000 at 10:13:17 AM EST

I must admit that I have the exact same RAM problem. I run a dual-head display, one card with 32M of video RAM and the other with 16M, yet >clicky, click< top is showing that X is hogging up 129MB of memory. That seems like a lot to me. I have 256M of system RAM, so I'm not swapping, but still. Even trying to use X on a system with 16 or 32M of RAM is a pain in the butt these days. Ultra slow, and I'd really be hesitant to consider something even as lowly as a P133 slow at tossing basic 2d graphics around when it has a speedy graphic accellerator card in it. ISTR that even Quake wasn't necessarily dreadfully slow (though still unplayable) even at 640x480 on such a system and it is very much more complex than most 2d apps.

But that's just me. I'm one of those weirdos who thinks that throwing more and more cycles and RAM at a problem just to attain the same performance I had last year from apps that don't have all that many new features this year seems like a rather dumb thing. ;) That's probably why I don't upgrade applications very often...

Chuq

[ Parent ]

Well...here's the thing: (2.50 / 2) (#37)
by simmons75 on Sat Nov 04, 2000 at 01:09:49 AM EST

You've come to Linux (and X11) expecting a Mac/Windows experience, and have instead gotten a UN*X/X11 experience.
poot!
So there.

[ Parent ]
Some open projects (2.66 / 6) (#22)
by Misagon on Thu Nov 02, 2000 at 03:27:45 PM EST

Standard inter-client communication protocols: X Desktop Group defines protocols for drag'n drop, clipboards etc. GNOME and KDE follows them. XFree86 is working on a standard audio server. (see the mailing lists)

X is a solid piece of engineering with a large feature set. Projects have been formed to create replacements but stumbled on the mere complexity of coming up to par with just a fraction of X's features.

(I hate it when Netscape Navigator keeps crashing on me. This is the third time I write this)
--
Don't Allow Yourself To Be Programmed!

Problems and solutions with X (4.38 / 13) (#25)
by Simon Kinahan on Thu Nov 02, 2000 at 05:17:45 PM EST

X does indeed have a lot of problems. I'm not actually convinced that not imposing UI policy is one of them. It does also have at least one good thing going for it, that it would be a shame to lose.

The best thing about X is that it is a thin client - that is, one with no application specific code - that works with any application. That is something that is worth keeping. The closest analogy, albeiut much less capable, is a web browser. A web browser is capable of presenting a simple UI for a wide range of applications that can fir within a form-filling, query-response kind of model. Similarly X is capable of presenting a UI for a much wider range of applications, albeit in a way that needs a lot more bandwidth. I do not see many people complaining that web browsers do not impose a UI policy on the sites they display.

What are the problems ? Well, for a start the rendering model is not very good. Although it is based on the postscript one, it has had so many limitations placed on it, it is not really very useful. For example, it has no support for non-axis aligned elipses, no support for transparency, no support for non-bitmap fonts, and only limited support for colour. You *cannot* fix these problems in software running on top of X, you can only work around them. To fix them, you need to change X quite radically. For these reasons, rich UI environments tend to use X only to move bitmaps around, and create windows. It ends up performing less well than ICA (Citrix) or RDP (Microsoft), for very little gain in functionality.

Second, X is only part of the solution to the problem of creating a network transparent user environment. In this respect, the problem is a more general Unix problem, and not a problem specific to X. While Unix still has better network transparency in most fields than any other operating system, it integrates them very poorly. It order to be able to run an application remotely and get the same functionality I can get from ICA, I need to configure and run NFS and an automounter to get at my home directory, NIS to configure the network information needed for the application to find out who I am, esd and the appropriate drivers for the app to allow the it to remote sound, lpr on the app's machine and lpd on my machine for printing ,and finally an X server on my machine and X libraries on the apps machine. Oddly enough not many people bother do to all this. I wonder why ? In spite of all this useful software, the lack of any underlying model for how network transparent computing should work makes the job of setting up a Unix network very difficult.

In this respect, the malaise is deeper than just X. Unix is essentially a random aglomeration of different tools, each with their own policy, their own file formats, and their own highly local relationships with other tools. This makes the job of KDE and Gnome harder than it needs to be. In order to present a single configuration system for an entire unix system, for instance, they need to implement a file format read/write system for every single tool. In order to configure the X server, they need to acheive things that simply have no protocol support: reconfiguring the display on which you yourself are running. I'm not saying any other OS is much better, but you simply cannot impose a sane, component based world on top of a bunch of tools configured with text files. Ultimately some kind of coherent underlying strategy for configuration, network transparency, and so on needs to be imposed on the entire system.

Simon

Disclaimer: In this context I should declare that I work for Citrix. None of the above is sanctioned by my employer, and I am not speaking for them.

Simon

If you disagree, post, don't moderate
Come up with something better, then. (4.16 / 6) (#36)
by tmb on Sat Nov 04, 2000 at 12:24:40 AM EST

Additionally, X is a memory hog ... I'm not sure why it is using 47 megs of memory on my system at the moment, considering that Gnome is doing most of the hard work, but I don't really care either.

You probably have a 32M card, and that memory is counted as part of the server. Maybe you should care to find out a little more about what you are criticizing before you condemn it so strongly.

Compare the Gnome program-to-hardware interface with the MS Windows application-to-hardware interface:

I think you underestimate what is going on in MS Windows. The times where any Windows application just got to hack screen memory through a library are over. MS Windows faced the same tradeoffs as X11, and they came up with roughly the same answers: some stuff lives in the kernel, separated from the application through the system call interface (not much different from X11 on the local machine), and some stuff allows direct access to the frame buffer (like the X11 DRI).

But MS Windows lacks a lot of facilities that let multiple applications live together reasonably nicely, and that let you separate things like window management from the low level drawing stuff. MS Windows is much more of a monolithic block of code.

Graphical console drivers should be handled in the kernel! [...] Create a better mechanism for network transparency [...] Build graphical desktop environments on top of these! [...] If we do all these things, Gnome and KDE, as well as Linux itself, should improve immensely,

Feel free to support the Berlin Project. What you describe is exactly what they are attempting.

Personally, I consider that a waste of time. What X11 desparately needs is antialiased 2D drawing primitives, and it is getting those. Beyond that, I think the world doesn't need another 2D windowing system based on C/C++. X11 is big and messy, but any other system that matures to that point will be equally big and messy, or it will be cutting corners.

Don't expect much sympathy from the folks who wrote The X-Windows Disaster either; they would likely consider any kind of C/C++-based windowing system a poor excuse for a real window system. I think they would also probably argue that a real window system should have decent hardware support to allow separate tasks to write to screen memory safely and they'd argue for implementation in a "real" programming language (read the other chapters of that book to get some idea of what they think about UNIX and C/C++).

I'm curious, though, have you actually ever done any serious graphics hacking (beyond drawing a few lines) on these systems? X11? Win32? Hardware accelerated Amiga? OpenGL?

troll? (5.00 / 1) (#42)
by boxed on Mon Nov 06, 2000 at 07:51:38 AM EST

this is a troll right? Claiming C/C++ is the blame for X-windows suckiness is practically identical to claiming the microprocessor architectures are to blame since C/C++ models the underlying hardware very accurately. (C++ less than C of course.)

[ Parent ]
"dictating policy" (2.80 / 5) (#41)
by kubalaa on Sat Nov 04, 2000 at 09:42:45 PM EST

When one (especially a Linux user) hears the phrase "dictating policy," there's an instant sense of revulsion; isn't this why we deserted (or never joined) the Evil Empire? To escape policy being dictated? Isn't this what freedom of choice is all about? Getting to chose your own desktop, window manager, keymap, filesystem, software, etc. etc.

Freedom, in the form we want it, is all about freedom for the USER.

The designers of X, when they chose not to dictate policy, chose to do so for the wrong reason; freedom for the programmer. They didn't want to constrain programmers to one way of doing things, i.e. a widget toolkit or a set of interface standards. This is all very well, but the problem is that it puts the choice in the programmer's hands, not the user's.

As in, imagine if all the widget toolkits had a properly standardized abstraction layer; then the user could globally choose their toolkit, instead of having it dictated by the programmer.

The reason why we got where we are is because programmers are the main users, and they like their programmer freedom, but Linux will never get ahead -- I don't mean get ahead as in market share, I could care less if Average Joe can use Linux, but I mean get ahead as in become more efficient, more flexible, more technologically advanced -- unless programmers can learn to sacrifice their freedom of choice in favor of standards which return the freedom of choice to the users.

Why the X server should be an "ex-" server! | 46 comments (46 topical, 0 editorial, 0 hidden)
Display: Sort:

kuro5hin.org

[XML]
All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!