When GNU finally releases a semi-stable Hurd, a major exodus will occur.
I think it's not just due to people wanting a pure GNU system (although I actually wouldn't mind just for the aesthetic value:) ) -- but the HURD has some cool architectural features that would be difficult to get into Linux without basically rewriting everything. In fact, while it's API (and maybe even binary -- same executable format (?) and same libc) compatible with UNIX it really isn't even a UNIX at all. Maybe a superset of UNIX. I've been hanging out on the debian-hurd mailing list for about six months now; the system is far from being releasable but looks like it'll be incredible when it is.
I'm actually the sort who diversifies. I eschew commercial releases of Open Source OS's, though I do poke around with them. I use Debian, FreeBSD, and NetBSD, and I'll be checking out OpenBSD pretty soon. When HURD is done, I'll definitely be using the Debian GNU/HURD release for a while, just to play with it.
One of the things that's most interesting to me about Debian GNU/HURD is that..well..it's Debian. Having the same userspace running on the Hurd as as on Linux will be..well..neater than I can express:)
Hopefully this will also result in more flexibility in the Debian arch specification and ftp hierarchy, so we can add Debian GNU/BSD and GNU/Win32:)
I see this happening, but I don't think (except for a small disgruntled minority) that it will be because the people in question hate Linux. I suspect that rather than being pushed out by newbies, they'll be pulled out by The Next Great Thing, *probably* not to a *BSD kernel (which is, AFAIK, extremely similar in architecture to GNU/Linux) but to a Free Unix-compatible operating system that extends the Unix philosophy in significant ways. Currently the best candidate here seems to be the Hurd (once it stops falling over every 3 minutes) -- it manages to out-Unix Unix as it were:) I'm sure there are other similar projects out there. I think it'll be a while after that that that the 'I'M mORe 31137 thAn YoU' types show up for the party, and a little while more before the mainstream notices it.
It wastes some. It goes as much as 5 to 10% slower because of it. That is about it.
Ha! Try ``an order of magnitude.'' Where did you get this idea?
For that matter, where did *you* get *this* idea? Have you benchmarked?
Further, exactly what do you mean? I agree that communication speed may decrease by quite a bit, but that's not directly correlated to *display* speed. Individual pixel operations are slow, Quake shouldn't use the X pipe. That's obvious. It's slightly less obvious that this is a significant problem for other programs. Sockets are slightly slower than direct memory copy, but unless the video card is *really* fast I suspect the time spent servicing a request far exceeds the time spent in the request. (I haven't benchmarked this either) Finally, it is my observation after using it that X is not an 'order of magnitude' slower than other display systems -- at worst, 5-10% is a reasonable estimate.
Do you have a constructive suggestion for improvement or are you just getting a kick out of making snide remarks? Having a well-known email address doesn't mean you can simply make insinuating remarks with no explanation to back them up.
Daniel
Re:Criticisms I have read elsewhere...
on
Is X The Future?
·
· Score: 1
I haven't had a chance to see the shared memory or OpenGL extensions; I heard that extensions have to be compiled in and I postponed it indefinitely.
Which distribution are you using? I think Debian ships them either as modules or compiled in (I think XFree doesn't support modules yet so they're probably compiled in)
Hardware acceleration/locality: Playing Quake2 over 10baseT is awkward; that's an area where client/server could definitely use an intelligent terminal, and avoiding streaming over a socket if possible (yes, bypass client/server entirely). It's a bit of an extreme, I know, but video and games should be no challenge whatsoever for Linux and X. Video and games can use OpenGL, SHM, DGA, etc to bypass the usual mechanisms. SHM and DGA speed up blitting on the local machine; OpenGL (as you know) provides a graphics-drawing interface with much support for hardware accel. The really nice thing about OpenGL is that (er, I think) it can actually (!) be run network-transparently; I don't know exactly what sort of performance you get with (eg) Quake but some modeling programs at Brown run quite nicely over the LAN.
I have been wondering how multimedia (specifically, video) can be added to Linux and X. Streamlining seems necessary to me; a video extension, perhaps? Or a window manager (see NeWS) that handles different protocols? Or would you guess that shared memory can handle these efficiently? I just want to see the multimedia capabilities of Amiga added to Linux, and I'm curious about what is preventing that.
I think that things like DGA/SHM and DRI can help a lot. Since with DGA you're basically writing to video memory directly, you can't speed up much more than that:) (although this doesn't work in a window) I don't know how DRI works; SHM needs at least two copys (app to SHM segment, SHM segment to display). I'm not sure you can really do much more (someone could correct me of course:) ) without jeopardizing the stability/security of the system. (non-exclusive direct writes to video memory are really dangerous)
X is, currently, pretty much as you say, "a network [video] display system". But it's also the core piece of software for user interfaces. Audio I/O is an important component of the computeruser I/O interface. And it's only natural that X should be extended to be a truly multimedia display system.
No. That's Windows thinking:) The only benefit of putting audio into X is that you could easily coordinate audio and video. This is something that should be addressed, but putting audio in X is a nasty kludge; some sort of general way to synchronize X with other systems is a better way to do things IMO. Small discrete systems are more correct, and a more correct system is more user-friendly *in the long term* because of flexibility and stability even if a hack will be better in the short-term.
And I still want to be able to play audio from another machine without running X.:)
Daniel
Re:X doesn't save state. VNC does.
on
Is X The Future?
·
· Score: 1
This has nothing to do with X. X just displays stuff on the screen. Saving state is the job of the client libraries/session manager. (none of which work right but that's a separate argument)
Daniel
Re:Everything we'd need in a potential replacement
on
Is X The Future?
·
· Score: 1
(I'm using traditional, rather than X notions of client and server)
Um. A server is something which accepts connections, takes requests, and Does Stuff (possibly returning information to the client). This is exactly how X works: a client conencts to the server, requests that the server do things for it (in this case, draw on the screen), and the server does it. There's nothing backwards about this at all.
[compression snipped..it would be a good thing although it's not critical]
And from what I hear other people saying about the protocol, there is some room for simplification.
I'm generally careful about what I hear people saying..there are always people who dislike a system and then come up with explanations. (not that that's necessarily the case here, but in general:) )
Efficiency. The protocol needs to make better use of information already sent. Invalidate-areas would be great. Additional primitives to do basic stuff like BitBlt could help things along. Maybe I'm confused, but Expose events already give the exposed area and there is a pixmap-copy operation unless I miss my mark..
Common controls aka widgets. You shouldn't need a toolkit to draw the standard user interface. There is a lot to be said for a few simple controls built into the standard. (This might be a "layer" issue--do they go in the window manager, the toolkit, or the GUI?) I think widgets belong in the GUI so every programmer can depend on them being there. I've seen 10 different shapes of buttons, 3 major types of scroll bars, etc. etc. Make it standard, so the programmer doesn't have to worry about it, and the user understands what they see!
Repeat after me:
X IS NOT A GUI! X IS NOT A GUI! X IS NOT A GUI!
X just draws stuff on the display. Agnosticism about GUI style is one of the things that makes it so flexible.
No sound support in X stream. I can export my display to a remote machine and work great from there -- until I want to do audio/input or output. Then my sounds comes out halfway across the universe. Great. X is a display server. It shouldn't be in the job of playing sounds. You need a sound server (NAS, rplay, ESD,...)
No 3D support. You can graft OpenGL on top of X, but then you've got this kludge with two APIs. The OpenGL API has nothing in common in the Xlib API. Weird. This should be unified. No! OpenGL's strength is that it code for it can run on many systems. For example, it can be integrated into X..or Win32..or BeOS..or Hurd (well, not yet)..or..or..
Gross design. Does the protocol *really* need that many things in it? Can't we abstract some of that into a higher layer? Ugh.
My impression is that it is intentionally general-purpose and low-level; it's a protocol for drawing on the screen. Widget sets are for higher-level operations. (there are some interesting ideas of 'widget servers'..berlin being the most obvious one..but I don't think you can cut out the low-level stuff without hampering the client's ability to decide what to do)
) X doesn't let you store "methods" on the server side. This means, for example, to draw a rounded box you have to draw 4 arcs and 4 lines. Need to draw another rounded box? That's another 8 drawing operations.
I like this idea. Let's do it in Guile:) *ducks*
No, we'd need a simple language (like the pseudo-assembly used for Mac SCSI) that can go into the X protocol..sounds like a great idea for X12..
2) X uses a client/server model. All instructions pass over a single pipe. This is often (correctly) accused of being X's most significant bottleneck for performance. But most people incorrectly think the solution is to throw the pipe away.
However the pipe is only truly a hinderance when doing large bitblits, such as for games or doing an animation. The X pipe isn't a problem for any normal windowing operations (drawline, drawtext, createwindow) which constitute 99% of normal work.
Thank you!! I've been yelling myself blue trying to explain this to idiots who think network-transparency explains the 'slowness' of X..
MITSHM tried to solve the problem by letting you draw directly to pixmaps on the server's side of the pipe, but you still needed to copy that pixmap into the framebuffer. No good.
DGA solves the problem by giving you full access to the framebuffer. You write directly to vidcard memory. There are no wasted copies. No problems with the pipe getting in the way. DGA wins.
I disagree. Both are good in different circumstances. MITSHM, while actually adequate for games, is best for window-managers, graphics programs, and other systems that just want to display pixmaps. These programs don't need to be suid root or writing directly to display memory -- in fact, doing so would be a security and stability risk. SHM is a good comprimise for these. Games, on the other hand, would do well to use DGA.
Also, you forgot a third option: server-side pixmaps (in fact I think many window-managers and so on may use this..but I know Imlib at least uses shm) These work well, even over a network, for many programs -- especially games whose graphics are built using tiles (Freeciv for example:) )
3) Font handling in X is ancient. There isn't any way of arguing against this. X fonts were designed before scalable fonts gained popularity. Scaled fonts in X are a nasty hack onto a system which doesn't understand them.
Absolutely.
New extensions to X are fixing problems that have been caused by advancing hardware. DRI, XKB and Xv are all perfect examples of new advances in X that have loads of functionality and in some ways have been implemented better than commercial windowing system alternatives.
I still haven't worked out how to use XKB/Xinput yet..:-/
Most of the problems in X are honestly a problem with users and developers, or people's failure to understand that the X way of solving a problem is no worse than competing windowing systems. A good example of people not understanding the problem and the solution is evidenced by the neverending complaints against the X client/server pipe.
<AOL>I agree</AOL>
Daniel
Re:X Copy and Paste Model is Dated
on
Is X The Future?
·
· Score: 1
I actually like this..it drives me crazy to have to go and select paste. On the other hand, it is sometimes a nuisance the way X does it too. I wouldn't say 'dated' as much as 'different'.
I think it would be nice if support for both mechanisms could be added, but that's nontrivial..
Daniel
Re:X _needs_ a good window manager
on
Is X The Future?
·
· Score: 1
WindowMaker- Quick, feels light and stable. Just not that flexable. For instance, you can't maximize a window to full screen and then back to a small window. It just doesn't have the features of GNOME or KDE.
Actually, you can do that. You can also hide all windows associated with a program, something incredibly useful that I haven't seen anywhere else. The dock is also pretty cool -- it's similar to the panels. WindowMaker also has Gnome-compliance; in fact I have Gnome panels hanging around on my screen right now:) I switched to Enlightenment for a while, but it didn't seem as solid, either in terms of widget layout/animation, design, or features. WindowMaker's themability is enough for me.
It's worth noticing that the network model IS being worked on in X4, with the Direct Rendering Infrastructure (Interface? I've forgotten already.)
Wow, I must be really advanced..I seem to be running X11 here..:)
We have QT and the GTK, and Motif, and some other toolkits, but there's no unifying conceptual interface.
Whether this is good or not, this soapbox is (or should be) totally irrelevant to X itself. X's strength is its simplicity: it draws stuff. This is a fundamental concept in UNIX: make small, specific but general within a specific area, and powerful tools. If X is to be replaced it should be with another general-purpose display server, not something which thinks that the only thing you want to draw is a button.
2. Device transparency which has true WYSIWYG support for all devices. The code which talks with the screen should also be able to talk with my printer, plotter, network, etc. What I display on one device must look the same on another device within the bounds of that device's capabilities.
I think this should be the job of some document-rendering engine (like GnomeCanvas) rather than the windowing system. X is just a server to draw on the screen. Trying to make it replace lpd is a Bad Idea..
by starting over again with hardware acceleration on every drawing function and modern programming techniques like multithreading and message queues, The only thing I can see helping them is multithreading..message queues, AFAIK, aren't much different performance-wise than pipes/sockets like X uses and probably are worse than SHM (although I'm sure Berlin supports SHM) -- and I believe X can already hardware-accelerate everything if it chooses, no? (yes, I don't fit your criterion for replying, but the thing about message queues was too much:) )
BTW, how is Berlin coming? Last I heard there was celebration because they'd gotten it to draw two overlapping triangles on the screen or something..:-/
HOWEVER X really doesn't "feel" as fast as my win95A partition (needed for school) on my computer. The mouse seems sluggish and jerky (very much like when playing 8 player starcraft on it (p120)). Anyone know WHY X feels slower? Probably because X is just a normal process, while the Win95 GUI is partially integrated into the kernel. This means, in particular, that the mouse doesn't move until X is allowed to read from/dev/mouse. I think reaction time to mouse clicks is no more in X than in Windows, but the mouse seems like it's moving more slowly.
In my case i have not much use for network transparency, and pcanywhere appears to do this much better anyway without the transparancy.
As I keep pointing out -- given a client-server architecture, no-one has suggested out a realistic alternative to some sort of stream protocol to communicate between them. UNIX sockets are extremely efficient for most cases, and SHM is available for things (ie, big pixmaps) which need more bandwidth. Once you have one stream protocol, though, you can generally support TCP with a trivial code change (most operations have the same semantics on any socket-based connection). The small bit of extra code won't be loaded into memory if you don't use TCP so it's not a loss that way. In other words, network transparency really doesn't hurt a local-machine situation much. Now, you can argue about what is transmitted over the network (some people think the display should be abstracted at the widget level..I don't, but..) but network transparency itself is a Very Good Thing. [tm]
Also, i think it would be a good idea to wait for V4 to come out before we switch to a faster windowing system.
AFAIK, X is currently at Version 11, Revision 6. (hence X11R6) So you're a little late:)
Daniel
Re:I want my GUI to get more info from the app
on
Is X The Future?
·
· Score: 1
Um, this has absolutely nothing to do with X itself. X just draws what programs tell it to, if they don't tell it to draw menus when the user clicks that's their problem. You want more integration between the WM and the programs.
No! No, no, no, no, no! This is the job of a printserver and a printing library (maybe the widget set) -- not, I repeat NOT the display server! The display server displays. The print server prints. The mail server mails. The foo server 'foo's. This is a Good Way to do things.
Gnome's solution here is (IIRC) to make the drawing canvas support multiple targets, one of which is Postscript to be sent to the printer.
That said, print support in Linux sucks.:) But it's not X's fault.
Dnaiel
Re:Criticisms I have read elsewhere...
on
Is X The Future?
·
· Score: 1
Confusing user interface
X doesn't have anything to do with a user interface, it's a display server. I fail to see the point. Separating the mechanism of display from the things displayed is a *good thing*.
Too much versatility, leading to overly complex or impossible interprogram communication: "cut-and-paste never works properly with X (unless you are cutting and pasting straight ASCII text)
I agree, cut-and-paste with X is problematic. On the other hand, middle-button paste is way cool.:) I want to see that extended to more data types in the next X iteration..
X is a non-extensible window server - in contrast to NeWS. X was based around the concept of a dumb graphical terminal, and it uses a lot of data to achieve that.
I don't know much about NeWS, but: -> I like the iea of a fairly dumb display server. A display server just display:) Putting widget sets and stuff server-side, if that's what you're talking about, is kind of interesting. I'm not sure how I feel about it:) -> I'm not sure what you mean about non-extensible. That sounds like a problem with particular implementations -- there are various X extensions floating around (such as OpenGL, shared memory, and other things)
X programs have lots of nasty user interface problems, including X configuration.
That's an application problem, not X's fault.
X has bad hardware support - This is out of place, isn't it?
Sounds like a problem with particular implementations to me.
X isn't device independent, or maybe has a limited graphical toolkit? "Drawing arcs is probably impossible in a portable fashion."
They may be referring to colordepth handling, which is a definite problem.
Other criticism I've heard that the X protocol should take advantage of the locality if the client and server are operating on the same machine. This only makes much sense to me if the cpu overhead in dealing with the network protocol is noticeable; being able to transparently work from another machine is too nifty to throw away.
I really think this is a baseless comment -- I haven't heard any solid explanation of *how* X would 'take advantage of the locality'. Given that we have a client-server model, there must be a mechanism of communication; this is almost certain to be a stream protocol, and indeed X uses UNIX-domain sockets. These tend to be extremely efficient for almost everything; those programs that really need more bandwidth can use DGA or SHM. (even on a totally non-accelerated server -- fbdev -- SHM gave me a good framerate in the Myth2 demo)
In general, I feel that the UNIX-hater-handbook folks are a lot of people who were frightened by sh as a child or something and now feel that their purpose in life is to make snide remarks about UNIXy systems without offering any real suggestions for improvements. Which I guess is why it's called 'the UNIX Hater's handbook'
Daniel
Re:audio and other "local" resources
on
Is X The Future?
·
· Score: 1
Excuse me, but this is completely irrelevant. X is a network display system and has nothing to do with your sound card. NOTHING! If you want a network sound server that's great and I think it's a worthy goal, but it is not a deficiency in the X server that it doesn't have a sound server welded to it. If nothing else, people using text-mode or other windowing environments might want sound as well!
Daniel
Re:I'm looking forward to the day they ditch X
on
Some KDE news
·
· Score: 1
But let me refrase my point: if you had one server, you could hard code a good portion of your communication protocol to speed things up. I still don't get it (although you'll probably never read this since it's such an old article:) ) How can it be more hardcoded than..well..hardcoded? That is--we code into the code what bytes to send when (xlib) and what to do when we get them. And what does 'one server' mean?
I hope you do not claim that X protocol is as efficient as a pipe. Well, on a local computer the X protocol uses filesystem sockets, which I believe are essentially fancy pipes. So there's no IP overhead, just the protocol itself. I freely admit that I don't know much about the low-level structure of the X protocol, but I believe that it's rarely used to draw single dots on the screen -- in those cases you use SHM. Higher-level structures -- like boxes, lines, text, and server-side pixmaps -- are much more common and bandwidth-efficient (you have to send relatively little information to specify a box compared to what the server does with the information. Pixmaps cached on the server are even better)
When I said there'd be no reason for client server architecture, I meant precisely that the user would not have a choice of servers but one server only.
I still don't get this. You mean we'd throw out all XFree drivers except one, or that there would be a single canonical implementation of the protocol? Neither one sounds like an especially good idea to me -- the second is more reasonable but not so good as a way to get a new standard (pretty much every common protocol I can think of has multiple implementations)
I still think that a web page stating flaws in X is necessary.
The main things that spring to mind are an ugly font-handling system, a need for better authentication systems, and inflexibility in color-handling. XFree could use a good, intelligent tool for picking the Right Video Timings, but that's their problem, not a problem with X in general.
I still feel like you're confused about something. Basically -- you have to have a client-server architecture anyway, pretty much any protocol can work over multiple transport mechanisms (TCP/pipe/local socket), and all the different protocols are already in libc and don't get paged in unless you use them so it doesn't make X any larger. And UNIX sockets are efficient enough for anything but extremely high-bandwidth stuff (think pixmaps and Quake), which is what SHM is for. Not supporting network is just unnecessarily crippling your server.
Daniel
Re:I'm looking forward to the day they ditch X
on
Some KDE news
·
· Score: 2
First, I personally do not need networking and I suspect that a lot of home users (i.e. desktop users) will not need it either. Yet I cannot turn the networked architecture off and switch to something more direct and efficient and with fewer components communicating between themselves.
I think that this statement is based on a fundamental misunderstanding of how UNIX works. It is clear (I hope) that any effective display server has to be a separate process from the programs which display on it. Given this, there obviously must be some means of communication between the server and the clients. On a UNIX system this generally means opening a socket of some form, be it TCP, Unix domain, or just a pipe. This is not only the standard way of doing things, it is quite efficient most of the time; the only place where it really fails is *extremely* high-bandwidth transfers (think big pixmaps being written all over the screen), which is why shared-memory was invented. Any halfway modern app will probably detect that it's running on a local X server and use shared memory where appropriate -- ie, for bandwidth-intensive things like moving images around. (eg: *any* Imlib-based program will use SHM) The Myth2 demo is a good example of this -- on a *framebuffer X server* -- a server entirely lacking in acceleration -- I acheived a high framerate with the game running *in a window*. (I couldn't find how to clock it but it seemed like it had maxed out -- I noticed little improvement on a PII/400 with an accelerated server)
Without networking, there's no reason to have a client-server architecture
This is completely false. Even the kernel itself is in many ways a client-server architecture: programs connect with system calls and request stuff from it. (the Hurd just makes this explicit) How would you allow multiple programs to access a single display at once without some sort of server?
I suspect all of stand-alone X desktop functionality can be written as one file for maximum speed and efficiency. Which functionality are you referring to?
A networked version is only good as an option.
But given that programs are *already*, for reasons mentioned above, connecting in a client-server fashion using localhost UNIX sockets why not make the simple jump to supporting TCP and get five times the flexibility?
Second, I hope someone starts a page dedicated to pointing out what's wrong with X. Most criticism I've seen of X is a slightly more literate version of "X sux, it's too big!" or "X sux, it scares me!" There are some real warts but the "X must die!!!!" camp generally doesn't even mention them (probably because most of them just mean that specific issues need to be fixed rather than throwing out the entire system they've got so much vitriol for)
If nothing else, it'd help X evolve in the right direction. Read: the one I want.
Daniel
Re:That's a pretty sad list of GUI's there...
on
Some KDE news
·
· Score: 1
First point: Every one of the GUI's you mention is crap. (Particularly Motif, but I digress.) Saying something does not make it true (although Motif is pretty awful..)
Second point: Openlook was first implemented on NeWS, not X. Unfortunately, Openlook was so butt-ugly and clumsy that it killed off NeWS, which was a brilliant piece of work.
I dunno..I actually kind of like the OpenLook look, in fact I keep meaning to make a GTK+ theme engine based on it. But it was a bit of a pain to use.
As for what I want X to do, I want it to follow the OS/2 Presentation Manager and Vision into a well-earned oblivion. Not much room for compromise there, is there?
Why can't we just get OpenGL talking directly to the display hardware, and take it from there? OpenGL does 2d just as well as it does 3d...
Yes, that would be the problem. I have no desire for my widget sets to be running at the speed of molasses. Please understand, I think that OpenGL is an excellent interface, if you happen to have a good graphics accelerator. Not all of us can afford to spend as much on the video system as on the rest of the computer (heck, I can't even afford the rest of the computer right now..:-/ )
Slashdot Mirror
When GNU finally releases a semi-stable Hurd, a major exodus will occur.
:) ) -- but the HURD has some cool architectural features that would be difficult to get into Linux without basically rewriting everything. In fact, while it's API (and maybe even binary -- same executable format (?) and same libc) compatible with UNIX it really isn't even a UNIX at all. Maybe a superset of UNIX. I've been hanging out on the debian-hurd mailing list for about six months now; the system is far from being releasable but looks like it'll be incredible when it is.
I think it's not just due to people wanting a pure GNU system (although I actually wouldn't mind just for the aesthetic value
Daniel
I'm actually the sort who diversifies. I eschew commercial releases of Open Source OS's, though I do poke around with them. I use Debian, FreeBSD, and NetBSD, and I'll be checking out OpenBSD pretty soon. When HURD is done, I'll definitely be using the Debian GNU/HURD release for a while, just to play with it.
One of the things that's most interesting to me about Debian GNU/HURD is that..well..it's Debian. Having the same userspace running on the Hurd as as on Linux will be..well..neater than I can express
Hopefully this will also result in more flexibility in the Debian arch specification and ftp hierarchy, so we can add Debian GNU/BSD and GNU/Win32
Daniel
I see this happening, but I don't think (except for a small disgruntled minority) that it will be because the people in question hate Linux. I suspect that rather than being pushed out by newbies, they'll be pulled out by The Next Great Thing, *probably* not to a *BSD kernel (which is, AFAIK, extremely similar in architecture to GNU/Linux) but to a Free Unix-compatible operating system that extends the Unix philosophy in significant ways. Currently the best candidate here seems to be the Hurd (once it stops falling over every 3 minutes) -- it manages to out-Unix Unix as it were :) I'm sure there are other similar projects out there. I think it'll be a while after that that that the 'I'M mORe 31137 thAn YoU' types show up for the party, and a little while more before the mainstream notices it.
Daniel
It wastes some. It goes as much as 5 to 10% slower because of it.
That is about it.
Ha! Try ``an order of magnitude.'' Where did you get this idea?
For that matter, where did *you* get *this* idea? Have you benchmarked?
Further, exactly what do you mean? I agree that communication speed may decrease by quite a bit, but that's not directly correlated to *display* speed. Individual pixel operations are slow, Quake shouldn't use the X pipe. That's obvious. It's slightly less obvious that this is a significant problem for other programs. Sockets are slightly slower than direct memory copy, but unless the video card is *really* fast I suspect the time spent servicing a request far exceeds the time spent in the request. (I haven't benchmarked this either)
Finally, it is my observation after using it that X is not an 'order of magnitude' slower than other display systems -- at worst, 5-10% is a reasonable estimate.
Do you have a constructive suggestion for improvement or are you just getting a kick out of making snide remarks? Having a well-known email address doesn't mean you can simply make insinuating remarks with no explanation to back them up.
Daniel
I haven't had a chance to see the shared memory or OpenGL extensions; I heard that extensions have to be compiled in and I postponed it indefinitely.
:) (although this doesn't work in a window) I don't know how DRI works; SHM needs at least two copys (app to SHM segment, SHM segment to display). I'm not sure you can really do much more (someone could correct me of course :) ) without jeopardizing the stability/security of the system. (non-exclusive direct writes to video memory are really dangerous)
Which distribution are you using? I think Debian ships them either as modules or compiled in (I think XFree doesn't support modules yet so they're probably compiled in)
Hardware acceleration/locality: Playing Quake2 over 10baseT is awkward; that's an area where client/server could definitely use an intelligent terminal, and avoiding streaming over a socket if possible (yes, bypass client/server entirely). It's a bit of an extreme, I know, but video and games should be no challenge whatsoever for Linux and X.
Video and games can use OpenGL, SHM, DGA, etc to bypass the usual mechanisms. SHM and DGA speed up blitting on the local machine; OpenGL (as you know) provides a graphics-drawing interface with much support for hardware accel. The really nice thing about OpenGL is that (er, I think) it can actually (!) be run network-transparently; I don't know exactly what sort of performance you get with (eg) Quake but some modeling programs at Brown run quite nicely over the LAN.
I have been wondering how multimedia (specifically, video) can be added to Linux and X. Streamlining seems necessary to me; a video extension, perhaps? Or a window manager (see NeWS) that handles different protocols? Or would you guess that shared memory can handle these efficiently? I just want to see the multimedia capabilities of Amiga added to Linux, and I'm curious about what is preventing that.
I think that things like DGA/SHM and DRI can help a lot. Since with DGA you're basically writing to video memory directly, you can't speed up much more than that
Daniel
X is, currently, pretty much as you say, "a network [video] display system". But it's also the core piece of software for user interfaces. Audio I/O is an important component of the computeruser I/O interface. And it's only natural that X should be extended to be a truly multimedia display system.
:) The only benefit of putting audio into X is that you could easily coordinate audio and video. This is something that should be addressed, but putting audio in X is a nasty kludge; some sort of general way to synchronize X with other systems is a better way to do things IMO. Small discrete systems are more correct, and a more correct system is more user-friendly *in the long term* because of flexibility and stability even if a hack will be better in the short-term.
:)
No. That's Windows thinking
And I still want to be able to play audio from another machine without running X.
Daniel
This has nothing to do with X. X just displays stuff on the screen. Saving state is the job of the client libraries/session manager. (none of which work right but that's a separate argument)
Daniel
(I'm using traditional, rather than X notions of client and server)
Um. A server is something which accepts connections, takes requests, and Does Stuff (possibly returning information to the client). This is exactly how X works: a client conencts to the server, requests that the server do things for it (in this case, draw on the screen), and the server does it. There's nothing backwards about this at all.
Daniel
[compression snipped..it would be a good thing although it's not critical]
:) )
And from what I hear other people saying about the protocol, there is some room for simplification.
I'm generally careful about what I hear people saying..there are always people who dislike a system and then come up with explanations. (not that that's necessarily the case here, but in general
Efficiency. The protocol needs to make better use of information already sent. Invalidate-areas would be great. Additional primitives to do basic stuff like BitBlt could help things along.
Maybe I'm confused, but Expose events already give the exposed area and there is a pixmap-copy operation unless I miss my mark..
Common controls aka widgets. You shouldn't need a toolkit to draw the standard user interface. There is a lot to be said for a few simple controls built into the standard. (This might be a "layer" issue--do they go in the window manager, the toolkit, or the GUI?) I think widgets belong in the GUI so every programmer can depend on them being there. I've seen 10 different shapes of buttons, 3 major types of scroll bars, etc. etc. Make it standard, so the programmer doesn't have to worry about it, and the user understands what they see!
Repeat after me:
X IS NOT A GUI!
X IS NOT A GUI!
X IS NOT A GUI!
X just draws stuff on the display. Agnosticism about GUI style is one of the things that makes it so flexible.
Daniel
No sound support in X stream. I can export my display to a remote machine and work great from there -- until I want to do audio/input or output. Then my sounds comes out halfway across the universe. Great. ...)
X is a display server. It shouldn't be in the job of playing sounds. You need a sound server (NAS, rplay, ESD,
No 3D support. You can graft OpenGL on top of X, but then you've got this kludge with two APIs. The OpenGL API has nothing in common in the Xlib API. Weird. This should be unified.
No! OpenGL's strength is that it code for it can run on many systems. For example, it can be integrated into X..or Win32..or BeOS..or Hurd (well, not yet)..or..or..
Gross design. Does the protocol *really* need that many things in it? Can't we abstract some of that into a higher layer? Ugh.
My impression is that it is intentionally general-purpose and low-level; it's a protocol for drawing on the screen. Widget sets are for higher-level operations. (there are some interesting ideas of 'widget servers'..berlin being the most obvious one..but I don't think you can cut out the low-level stuff without hampering the client's ability to decide what to do)
Daniel
) X doesn't let you store "methods" on the server side. This means, for example, to draw a rounded box you have to draw 4 arcs and 4 lines. Need to draw another rounded box? That's another 8 drawing operations.
:) *ducks*
:) )
:-/
I like this idea. Let's do it in Guile
No, we'd need a simple language (like the pseudo-assembly used for Mac SCSI) that can go into the X protocol..sounds like a great idea for X12..
2) X uses a client/server model. All instructions pass over a single pipe. This is often (correctly) accused of being X's most significant bottleneck for performance. But most people incorrectly think the solution is to throw the pipe away.
However the pipe is only truly a hinderance when doing large bitblits, such as for games or doing an animation. The X pipe isn't a problem for any normal windowing operations (drawline, drawtext, createwindow) which constitute 99% of normal work.
Thank you!! I've been yelling myself blue trying to explain this to idiots who think network-transparency explains the 'slowness' of X..
MITSHM tried to solve the problem by letting you draw directly to pixmaps on the server's side of the pipe, but you still needed to copy that pixmap into the framebuffer.
No good.
DGA solves the problem by giving you full access to the framebuffer. You write directly to vidcard memory. There are no wasted copies. No problems with the pipe getting in the way. DGA wins.
I disagree. Both are good in different circumstances. MITSHM, while actually adequate for games, is best for window-managers, graphics programs, and other systems that just want to display pixmaps. These programs don't need to be suid root or writing directly to display memory -- in fact, doing so would be a security and stability risk. SHM is a good comprimise for these. Games, on the other hand, would do well to use DGA.
Also, you forgot a third option: server-side pixmaps (in fact I think many window-managers and so on may use this..but I know Imlib at least uses shm) These work well, even over a network, for many programs -- especially games whose graphics are built using tiles (Freeciv for example
3) Font handling in X is ancient. There isn't any way of arguing against this. X fonts were designed before scalable fonts gained popularity. Scaled fonts in X are a nasty hack onto a system which doesn't understand them.
Absolutely.
New extensions to X are fixing problems that have been caused by advancing hardware. DRI, XKB and Xv are all perfect examples of new advances in X that have loads of functionality and in some ways have been implemented better than commercial windowing system alternatives.
I still haven't worked out how to use XKB/Xinput yet..
Most of the problems in X are honestly a problem with users and developers, or people's failure to understand that the X way of solving a problem is no worse than competing windowing systems. A good example of people not understanding the problem and the solution is evidenced by the neverending complaints against the X client/server pipe.
<AOL>I agree</AOL>
Daniel
I actually like this..it drives me crazy to have to go and select paste. On the other hand, it is sometimes a nuisance the way X does it too. I wouldn't say 'dated' as much as 'different'.
I think it would be nice if support for both mechanisms could be added, but that's nontrivial..
Daniel
WindowMaker- Quick, feels light and stable. Just not that flexable. For instance, you can't maximize a window to full screen and then back to a small window. It just doesn't have the features of GNOME or KDE.
:) I switched to Enlightenment for a while, but it didn't seem as solid, either in terms of widget layout/animation, design, or features. WindowMaker's themability is enough for me.
Actually, you can do that. You can also hide all windows associated with a program, something incredibly useful that I haven't seen anywhere else. The dock is also pretty cool -- it's similar to the panels. WindowMaker also has Gnome-compliance; in fact I have Gnome panels hanging around on my screen right now
Daniel
It's worth noticing that the network model IS being worked on in X4, with the Direct Rendering Infrastructure (Interface? I've forgotten already.)
:)
Wow, I must be really advanced..I seem to be running X11 here..
We have QT and the GTK, and Motif, and some other toolkits, but there's no unifying conceptual interface.
Whether this is good or not, this soapbox is (or should be) totally irrelevant to X itself. X's strength is its simplicity: it draws stuff. This is a fundamental concept in UNIX: make small, specific but general within a specific area, and powerful tools. If X is to be replaced it should be with another general-purpose display server, not something which thinks that the only thing you want to draw is a button.
Daniel
2. Device transparency which has true WYSIWYG support for all devices. The code which talks with the screen should also be able to talk with my printer, plotter, network, etc. What I display on one device must look the same on another device within the bounds of that device's capabilities.
I think this should be the job of some document-rendering engine (like GnomeCanvas) rather than the windowing system. X is just a server to draw on the screen. Trying to make it replace lpd is a Bad Idea..
Daniel
by starting over again with hardware acceleration on every drawing function and modern programming techniques like multithreading and message queues, :) )
:-/
The only thing I can see helping them is multithreading..message queues, AFAIK, aren't much different performance-wise than pipes/sockets like X uses and probably are worse than SHM (although I'm sure Berlin supports SHM) -- and I believe X can already hardware-accelerate everything if it chooses, no? (yes, I don't fit your criterion for replying, but the thing about message queues was too much
BTW, how is Berlin coming? Last I heard there was celebration because they'd gotten it to draw two overlapping triangles on the screen or something..
Daniel
HOWEVER X really doesn't "feel" as fast as my win95A partition (needed for school) on my computer. The mouse seems sluggish and jerky (very much like when playing 8 player starcraft on it (p120)). /dev/mouse. I think reaction time to mouse clicks is no more in X than in Windows, but the mouse seems like it's moving more slowly.
:)
Anyone know WHY X feels slower?
Probably because X is just a normal process, while the Win95 GUI is partially integrated into the kernel. This means, in particular, that the mouse doesn't move until X is allowed to read from
In my case i have not much use for network transparency, and pcanywhere appears to do this much better anyway without the transparancy.
As I keep pointing out -- given a client-server architecture, no-one has suggested out a realistic alternative to some sort of stream protocol to communicate between them. UNIX sockets are extremely efficient for most cases, and SHM is available for things (ie, big pixmaps) which need more bandwidth. Once you have one stream protocol, though, you can generally support TCP with a trivial code change (most operations have the same semantics on any socket-based connection). The small bit of extra code won't be loaded into memory if you don't use TCP so it's not a loss that way. In other words, network transparency really doesn't hurt a local-machine situation much. Now, you can argue about what is transmitted over the network (some people think the display should be abstracted at the widget level..I don't, but..) but network transparency itself is a Very Good Thing. [tm]
Also, i think it would be a good idea to wait for V4 to come out before we switch to a faster windowing system.
AFAIK, X is currently at Version 11, Revision 6. (hence X11R6) So you're a little late
Daniel
Um, this has absolutely nothing to do with X itself. X just draws what programs tell it to, if they don't tell it to draw menus when the user clicks that's their problem. You want more integration between the WM and the programs.
Daniel
No! No, no, no, no, no! This is the job of a printserver and a printing library (maybe the widget set) -- not, I repeat NOT the display server! The display server displays. The print server prints. The mail server mails. The foo server 'foo's. This is a Good Way to do things.
:) But it's not X's fault.
Gnome's solution here is (IIRC) to make the drawing canvas support multiple targets, one of which is Postscript to be sent to the printer.
That said, print support in Linux sucks.
Dnaiel
Confusing user interface
:) I want to see that extended to more data types in the next X iteration..
:) Putting widget sets and stuff server-side, if that's what you're talking about, is kind of interesting. I'm not sure how I feel about it :)
X doesn't have anything to do with a user interface, it's a display server. I fail to see the point. Separating the mechanism of display from the things displayed is a *good thing*.
Too much versatility, leading to overly complex or impossible interprogram communication: "cut-and-paste never works properly with X (unless you are cutting and pasting straight ASCII text)
I agree, cut-and-paste with X is problematic. On the other hand, middle-button paste is way cool.
X is a non-extensible window server - in contrast to NeWS. X was based around the concept of a dumb graphical terminal, and it uses a lot of data to achieve that.
I don't know much about NeWS, but:
-> I like the iea of a fairly dumb display server. A display server just display
-> I'm not sure what you mean about non-extensible. That sounds like a problem with particular implementations -- there are various X extensions floating around (such as OpenGL, shared memory, and other things)
X programs have lots of nasty user interface problems, including X configuration.
That's an application problem, not X's fault.
X has bad hardware support - This is out of place, isn't it?
Sounds like a problem with particular implementations to me.
X isn't device independent, or maybe has a limited graphical toolkit? "Drawing arcs is probably impossible in a portable fashion."
They may be referring to colordepth handling, which is a definite problem.
Other criticism I've heard that the X protocol should take advantage of the locality if the client and server are operating on the same machine. This only makes much sense to me if the cpu overhead in dealing with the network protocol is noticeable; being able to transparently work from another machine is too nifty to throw away.
I really think this is a baseless comment -- I haven't heard any solid explanation of *how* X would 'take advantage of the locality'. Given that we have a client-server model, there must be a mechanism of communication; this is almost certain to be a stream protocol, and indeed X uses UNIX-domain sockets. These tend to be extremely efficient for almost everything; those programs that really need more bandwidth can use DGA or SHM. (even on a totally non-accelerated server -- fbdev -- SHM gave me a good framerate in the Myth2 demo)
In general, I feel that the UNIX-hater-handbook folks are a lot of people who were frightened by sh as a child or something and now feel that their purpose in life is to make snide remarks about UNIXy systems without offering any real suggestions for improvements. Which I guess is why it's called 'the UNIX Hater's handbook'
Daniel
Excuse me, but this is completely irrelevant. X is a network display system and has nothing to do with your sound card. NOTHING! If you want a network sound server that's great and I think it's a worthy goal, but it is not a deficiency in the X server that it doesn't have a sound server welded to it. If nothing else, people using text-mode or other windowing environments might want sound as well!
Daniel
But let me refrase my point: if you had one server, you could hard code a good portion of your communication protocol to speed things up. :) ) How can it be more hardcoded than..well..hardcoded? That is--we code into the code what bytes to send when (xlib) and what to do when we get them. And what does 'one server' mean?
I still don't get it (although you'll probably never read this since it's such an old article
I hope you do not claim that X protocol is as efficient as a pipe.
Well, on a local computer the X protocol uses filesystem sockets, which I believe are essentially fancy pipes. So there's no IP overhead, just the protocol itself. I freely admit that I don't know much about the low-level structure of the X protocol, but I believe that it's rarely used to draw single dots on the screen -- in those cases you use SHM. Higher-level structures -- like boxes, lines, text, and server-side pixmaps -- are much more common and bandwidth-efficient (you have to send relatively little information to specify a box compared to what the server does with the information. Pixmaps cached on the server are even better)
When I said there'd be no reason for client server architecture, I meant precisely that the user would not have a choice of servers but one server only.
I still don't get this. You mean we'd throw out all XFree drivers except one, or that there would be a single canonical implementation of the protocol? Neither one sounds like an especially good idea to me -- the second is more reasonable but not so good as a way to get a new standard (pretty much every common protocol I can think of has multiple implementations)
I still think that a web page stating flaws in X is necessary.
The main things that spring to mind are an ugly font-handling system, a need for better authentication systems, and inflexibility in color-handling. XFree could use a good, intelligent tool for picking the Right Video Timings, but that's their problem, not a problem with X in general.
I still feel like you're confused about something. Basically -- you have to have a client-server architecture anyway, pretty much any protocol can work over multiple transport mechanisms (TCP/pipe/local socket), and all the different protocols are already in libc and don't get paged in unless you use them so it doesn't make X any larger. And UNIX sockets are efficient enough for anything but extremely high-bandwidth stuff (think pixmaps and Quake), which is what SHM is for. Not supporting network is just unnecessarily crippling your server.
Daniel
First, I personally do not need networking and I suspect that a lot of home users (i.e. desktop users) will not need it either. Yet I cannot turn the networked architecture off and switch to something more direct and efficient and with fewer components communicating between themselves.
I think that this statement is based on a fundamental misunderstanding of how UNIX works. It is clear (I hope) that any effective display server has to be a separate process from the programs which display on it. Given this, there obviously must be some means of communication between the server and the clients. On a UNIX system this generally means opening a socket of some form, be it TCP, Unix domain, or just a pipe. This is not only the standard way of doing things, it is quite efficient most of the time; the only place where it really fails is *extremely* high-bandwidth transfers (think big pixmaps being written all over the screen), which is why shared-memory was invented. Any halfway modern app will probably detect that it's running on a local X server and use shared memory where appropriate -- ie, for bandwidth-intensive things like moving images around. (eg: *any* Imlib-based program will use SHM) The Myth2 demo is a good example of this -- on a *framebuffer X server* -- a server entirely lacking in acceleration -- I acheived a high framerate with the game running *in a window*. (I couldn't find how to clock it but it seemed like it had maxed out -- I noticed little improvement on a PII/400 with an accelerated server)
Without networking, there's no reason to have a client-server architecture
This is completely false. Even the kernel itself is in many ways a client-server architecture: programs connect with system calls and request stuff from it. (the Hurd just makes this explicit)
How would you allow multiple programs to access a single display at once without some sort of server?
I suspect all of stand-alone X desktop functionality can be written as one file for maximum speed and efficiency.
Which functionality are you referring to?
A networked version is only good as an option.
But given that programs are *already*, for reasons mentioned above, connecting in a client-server fashion using localhost UNIX sockets why not make the simple jump to supporting TCP and get five times the flexibility?
Second, I hope someone starts a page dedicated to pointing out what's wrong with X.
Most criticism I've seen of X is a slightly more literate version of "X sux, it's too big!" or "X sux, it scares me!" There are some real warts but the "X must die!!!!" camp generally doesn't even mention them (probably because most of them just mean that specific issues need to be fixed rather than throwing out the entire system they've got so much vitriol for)
If nothing else, it'd help X evolve in the right direction.
Read: the one I want.
Daniel
First point: Every one of the GUI's you mention is crap. (Particularly Motif, but I digress.)
:-/ )
Saying something does not make it true (although Motif is pretty awful..)
Second point: Openlook was first implemented on NeWS, not X. Unfortunately, Openlook was so butt-ugly and clumsy that it killed off NeWS, which was a brilliant piece of work.
I dunno..I actually kind of like the OpenLook look, in fact I keep meaning to make a GTK+ theme engine based on it. But it was a bit of a pain to use.
As for what I want X to do, I want it to follow the OS/2 Presentation Manager and Vision into a well-earned oblivion.
Not much room for compromise there, is there?
Why can't we just get OpenGL talking directly to the display hardware, and take it from there? OpenGL does 2d just as well as it does 3d...
Yes, that would be the problem. I have no desire for my widget sets to be running at the speed of molasses. Please understand, I think that OpenGL is an excellent interface, if you happen to have a good graphics accelerator. Not all of us can afford to spend as much on the video system as on the rest of the computer (heck, I can't even afford the rest of the computer right now..
Daniel
It presents both sides (mostly through links) but is otherwise a good article.
Heaven forbid that someone should write a balanced journalistic piece!
Daniel