Slashdot Mirror
X Power Tools
stoolpigeon writes "The X Window System has been around for over twenty years and is the display system for an incredibly wide range of operating systems. With the number of Linux users growing, there are more people working with X than ever before. Most modern desktop environments provide user friendly interfaces that make modifying X rather simple. There is not a need to dig into config files and settings as in the past. For those environments without such tools or for the user who loves to dig deep into their environment, this book can be a simple way to understand how X works and how to tweak it in any number of ways. If you want things that 'just work' and have no interest in digging around below the surface this book is not for you. On the other hand, if you think the best thing to do with a shiny new tool is to take it apart, well "X Power Tools" by Chris Tyler may be just for you." Read on for the rest of JR's thoughts on this book.
X Power Tools
author
Chris Tyler
pages
254
publisher
O'Reilly Media, Inc.
rating
9/10
reviewer
JR Peck
ISBN
0-596-10195-3
summary
The author, Chris Tyler, is a professor at Seneca College in Toronto as well as a programmer and Linux user. His first book published by O'Reilly was "Fedora Linux: A Complete Guide to Red Hat's Community Distribution", published in 2006. He cites the growth in X users, combined with active development and the lack of existing books that address X as the motivation for writing "X Power Tools."
X is the windowing system on a wide range of Unix and Unix like systems. Chris is obviously most familiar with Linux and so the material is heavily Linux oriented. This is most apparent when the book deals with Session Managers, Desktop Environments and Window Managers. The material focuses on Gnome, KDE and Xfce and their associated components in regards to X. For the Linux user this could be a valuable resource.
When I've had issues in working with X locally and over the network, I've found that while what I need is available on the web, getting just what I need can be very labor intensive at times. Usually just what I want is spread across tutorials, on-line man pages and forum posts. Sorting out what applies to my situation can be especially difficult when I'm not even sure just how things work for my setup. Chris makes this kind of guessing unnecessary and provides the locations and function of key files. He also spells out how the most important files and tools can be best used.
For the sysadmin on another platform, these Linux specific sections are not going to be much help. Most of the book though, deals with X itself. I've already loaned my copy to one of our AIX admins more than once and I think he plans on picking up a copy of his own.
When Gnome and KDE provide an interface for modifying or customizing X functionality, the book gives at least the name of the program and sometimes screen shots and explanations of how the tool works. This is always after an illustration of how to get the job done with the tools that are a part of X itself. From fonts to keyboard layouts, multi-display to kiosks, everything required is laid out in straight forward terms.
For me, as a Fedora user, this means that having read this book I approach my work environment with a new level of confidence. Behaviors that used to puzzle me, now make complete sense. Quirks that bothered me, no longer need to be tolerated as I know have the tools to get things working just the way I want, rather than using defaults.
The book has just come out, so it was being written before the release of KDE 4. I've looked through the documentation and I don't think any of the changes to programs like KDM or KWin make the information in the book out of date. In fact, according to the KWin release notes, when discussing KWins new compositing support, "...manual configuration of X may be required for proper results..." So if you are a KDE user that likes to live on the edge, this book may come in handy.
O'Reilly says that their "Power Tool" books are comprised of a series of stand-alone articles that are cross-referenced to one another. To be honest, it didn't feel much different from reading any other tech book. Topics flowed naturally and the articles are analogous to sections that divide up chapters in other books. One nice navigation feature is that page numbers are on the bottom of the pages while chapter and article numbers are at the top corner in a decimal notations. For example at the top of page 58 there is a grey square containing the number 3.13 which means that it is the 13th article in chapter 3.
The book has a thorough index. It also comes with 45 days free access to an electronic version through O'Reilly Safari.
For me the only real weakness of the book is that I would like to have seen more information on working with X on Unix. When reference is made to specific implementation of X it is almost always in regards to Linux. I wouldn't want to lose that, but I think a mixed environment of Unix, Linux and Windows is more the rule than the exception today. It would be more work to include other operating systems, but it would have also made the book much more valuable.
All tech books face the danger of becoming quickly useless as progress marches forward. X is actively being developed, but at the same time, looking back on its history I think this book will be useful for sysadmin and user for some time to come.
You can purchase X Power Tools from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
X is the windowing system on a wide range of Unix and Unix like systems. Chris is obviously most familiar with Linux and so the material is heavily Linux oriented. This is most apparent when the book deals with Session Managers, Desktop Environments and Window Managers. The material focuses on Gnome, KDE and Xfce and their associated components in regards to X. For the Linux user this could be a valuable resource.
When I've had issues in working with X locally and over the network, I've found that while what I need is available on the web, getting just what I need can be very labor intensive at times. Usually just what I want is spread across tutorials, on-line man pages and forum posts. Sorting out what applies to my situation can be especially difficult when I'm not even sure just how things work for my setup. Chris makes this kind of guessing unnecessary and provides the locations and function of key files. He also spells out how the most important files and tools can be best used.
For the sysadmin on another platform, these Linux specific sections are not going to be much help. Most of the book though, deals with X itself. I've already loaned my copy to one of our AIX admins more than once and I think he plans on picking up a copy of his own.
When Gnome and KDE provide an interface for modifying or customizing X functionality, the book gives at least the name of the program and sometimes screen shots and explanations of how the tool works. This is always after an illustration of how to get the job done with the tools that are a part of X itself. From fonts to keyboard layouts, multi-display to kiosks, everything required is laid out in straight forward terms.
For me, as a Fedora user, this means that having read this book I approach my work environment with a new level of confidence. Behaviors that used to puzzle me, now make complete sense. Quirks that bothered me, no longer need to be tolerated as I know have the tools to get things working just the way I want, rather than using defaults.
The book has just come out, so it was being written before the release of KDE 4. I've looked through the documentation and I don't think any of the changes to programs like KDM or KWin make the information in the book out of date. In fact, according to the KWin release notes, when discussing KWins new compositing support, "...manual configuration of X may be required for proper results..." So if you are a KDE user that likes to live on the edge, this book may come in handy.
O'Reilly says that their "Power Tool" books are comprised of a series of stand-alone articles that are cross-referenced to one another. To be honest, it didn't feel much different from reading any other tech book. Topics flowed naturally and the articles are analogous to sections that divide up chapters in other books. One nice navigation feature is that page numbers are on the bottom of the pages while chapter and article numbers are at the top corner in a decimal notations. For example at the top of page 58 there is a grey square containing the number 3.13 which means that it is the 13th article in chapter 3.
The book has a thorough index. It also comes with 45 days free access to an electronic version through O'Reilly Safari.
For me the only real weakness of the book is that I would like to have seen more information on working with X on Unix. When reference is made to specific implementation of X it is almost always in regards to Linux. I wouldn't want to lose that, but I think a mixed environment of Unix, Linux and Windows is more the rule than the exception today. It would be more work to include other operating systems, but it would have also made the book much more valuable.
All tech books face the danger of becoming quickly useless as progress marches forward. X is actively being developed, but at the same time, looking back on its history I think this book will be useful for sysadmin and user for some time to come.
You can purchase X Power Tools from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
As long as the program lives on (even as abandonware), so does the technology and the potential for manuals and other HOWTO material. People still buy QBasic By Example (and blogs still rave about it) even though it was unbundled from Windows in Vista (maybe even XP, I'm not sure) and most people (myself included) haven't written a proper program in it for coming up on a decade.
Those using pirated Tinysoft signatures(TM) are a real threat to society and should all be thrown in jail.
How bad can a review be? This provides no useful information, except that the reviewer seems to have liked it a lot.
Then make one ;)
Lack of planning on your part does not constitute an emergency on mine.
I entirely agree. It's obvious that it most be fairly hard to code for or else getting it to work wouldn't be so difficult.
Even on Ubuntu 7.10, it's still a beast to deal with. I don't have hardware ordered specifically with Linux in mind, I need Linux to work without that.
But X is speedy and X works. And there'd need to be an awful lot of programs ported to get X's successor to catch on.
Those using pirated Tinysoft signatures(TM) are a real threat to society and should all be thrown in jail.
Can you provide some code? You are free to make a new graphics interface. X has been around for a long time and it will stay for a long time yet. It has proven itself despite of its shortcomings. I don't think that a complete replacement is a good idea. The best thing for X that yet has to happen is it running as an unpriveledged user, but that is hard with the hardware so close to the software.
I wasn't aware a lot of programs interfaced directly with X. I'm sure there are some that for whatever reason feel like they must interact with X directly, but wouldn't say, X2 or X+ or whatever with GTK/QT4 be sufficient to run -almost everything-?
is that it know the hardware it's running on better. You shouldn't need a file to say what resolution your monitor can do for instance; it should just know and keep track of preferences of what resolution you'd prefer maybe.
This isn't a troll; monitors and graphics cards have been able for donkeys years to tell the OS what resolutions and refresh-rates they are capable of for years now and X hasn't caught on.
And that's pretty much my only complaint.
throw new NoSignatureException();
What are you smoking?
You don't install ANY OS on hardware without considering driver support.
MacOS is no different. Various forms of Windows are no different.
Linux and X are not alone in this.
That said, I've never gotten all the whining. I've put no more
effort into buying machines and vidcards that I would have done
to avoid a lemon under Windows. Yet I've managed to avoid problems.
Slackware 96 was not pretty but it wasn't painful in this regard at all.
A Pirate and a Puritan look the same on a balance sheet.
#DeleteChrome
http://www.mhall119.com
Why? What's wrong? We have hw acceleration, we can use it over the network, we have nice toolkits that work on top of it, it has good documentation and nvidia, ati and intel write drivers for it. Why change it?
I just don't trust anything that bleeds for five days and doesn't die.
Because then it wouldn't work on BSD or Solaris, which is also why X has it's own Keyboard and Mouse drivers, because not all kernels that X was designed for provided APIs for them.
http://www.mhall119.com
From man xorg.conf, verbatim:
...
VIDEOADAPTOR SECTION
Nobody wants to say how this works. Maybe nobody knows
On the more serious note, Xorg might have some misfeatures and shortcomings - that don't really justify everyone whining there, but, well, it's kind of typical - but the sheer fact that something designed over 20 years ago to operate with hardware and software long forgotten still does its job well and manages to keep up with other windowing systems even when it comes to bells and whistles (Composite, etc.), while being ABI (ABI, mind you, not API) compatible with software that actually is 20 years old, means something. That's one solid piece of engineering, the kind one doesn't see often.
This is Slashdot. Common sense is futile. You will be modded down.
Isn't that one of those oxymoron things like "Military Intelligence".
Engineering is the art of compromise.
In 1997 I'd have agreed with you, but today X is working better than ever. Only problems I run into are: configuring it still sucks; and, exporting to a remote machine is still slow as crap compared to Windows Remote Desktop*. There are other things that could make it even better like detaching and reattaching windows to different screens, but personally I'd just be happy if it was as snappy over the network as Windows.
*My experience with NX has not been that great, both from a use and configuration standpoint. And it's not standard with X.
> Look, I know this is the standard FOSS fanboy answer to any criticisms about anything and everything,
> but it's gotten tiresome - it doesn't actually address the criticism at all.
Actually it is more response than the original poster deserved. Go reread it, he complaimed that it is old. No specific complaint, no suggested solution.
And you fail to understand the FOSS idea. The line between users and developers doesn't exist. If you don't like it you are free to fix it. Iven if you aren't a uber coder who can write GL drivers in their sleep you can at least learn enough to make good guggestions, bug reports or hell, contribute some better documentation. If you can't code or at least understand the system enough to make constructive criticisms and suggestions for improvements then you really should just shut up and accept what you get because talking from ignorance just reduces the signal to noise and makes it harder for those who do have a clue to get on with improving the stuff you use.
10 to one both you and the original poster don't even realize GNOME and KDE aren't even part of X. That sort of ignorance is what makes every thread about X devolve into silly rants about GUI usability and brings out the Mac fanbois. X itself is just fine now and with some of the current improvements working their way towards mainstream it will only get better.
Democrat delenda est
X is not a window system, it's a display system.
KDE is a windowing system, as is GNOME.
That's an invalid argument. I may know enough to say my car isn't working (e.g., it won't start), but I certainly don't know enough to fix it.
You're pretty new to this, eh?
It's not so obvious anymore on todays multicore, multi-GHz numbercrunchers with gigs of RAM, but X11 is a lot of things, but _not_ speedy. They didn't even try to make it speedy - the network transparency layer (among other things) creates so much overhead it was a pain to use X11 until relatively recently.
When XP was first released its windowing system actually felt more responsive than X11 did on the hardware from that time.
Truth arises more readily from error than from confusion. -Francis Bacon
I agree with that, but you haven't even told us what's wrong with X, or how another system could be better.
factor 966971: 966971
From Alan Coopersmith of Sun Microsystems:
Javascript + Nintendo DSi = DSiCade
That's an invalid argument. X works. In this case, you might know your car isn't getting forty miles per gallon like a hybrid, and don't know enough to convert it into one. Neither do most people. So just shut the fuck up unless you've got something to offer. It'd be awesome if someone would convert my car into a hybrid for me. It isn't likely to fucking happen--it might if enough FOSS people got together and came up with something though.
XDMCP is one of my favorite features of X. But, getting it set up is such a royal pain in the butt, especially on networks with mixed distros and OSs. It's been a few years since I've had to administer it much, but my only real gripe with X was the time it took getting a good XDMCP environment up and running. Hope there's some help with it included.
I swear to God...I swear to God! That is NOT how you treat your human!
Why don't you double how much you're paying for the X Window System ($0) and see if anybody is interested in writing a replacement for that kind of money?
If you didn't pay for it and you don't like it you have two options:
1) Write something better. Surely you can because you know what you don't like about the old one, right?
2) Shut the fuck up, grow a set, and realize that the open source community is not your personal bitch.
You are exactly the reason why I gave up writing open source software. You had criticisms about my software, software that I designed and wrote for what I needed it for. I told you that I wasn't going to change it and you went on a total tirade about how I was supposed to fix this for you and how this software was yours. Bullshit. If you don't like it, fix it. If you can't fix it, there are programmers that specialize in open source software that would be more than happy to make a little scratch on the side to code something up for you. If you're too cheap to do that, then SHUT THE FUCK UP.
Bad analogy. What the original poster said would be more like "I know the internal combustion engine is entrenched and all, aren't we fed up with this dinosaur? ..."
False analogy.
When X doesn't start you simply tweak the configuration.
We're talking about possible serious flaws in the design of the protocol, APIs, etc.
Didn't Windows at some point suffer from having all the graphics stuff running in kernel mode? I'm pretty sure you wouldn't like loading a multi-megabyte module into your kernel. The size of the NVIDIA closed source kernel module alone is scary enough. Now, take a lot of functionality out of X and put it in there and you have a real monstrosity.
-matthew
"THERE IS NO JUSTICE, THERE IS ONLY ME." -Death
What you are describing is already been worked on. Soon, at least on Linux, Xorg will no longer need to run as root.
> X is not a window system, it's a display system.
X is the windowing system, metacity/kwin are window managers and Gnome/KDE are desktops. Why do you presume everyone would call it "X Windows" if it wasn't a windowing system?
I think this is a great post, in spite of the backlash against it. I support your cause, and fully agree. If I had mod points, I'd give them to you rather than posting here.
The general defense I keep seeing for X seems to be that people "aren't criticizing it properly". As if to say that just having problems with X isnt sufficient if you don't fully understand and can vocalize on those problems in a tech-savvy manner. In the past year, I don't know how many X problems I've run into, *most* of them being related to the fact that X itself is single-threaded, and there's a whole can of worms related to that when something minor in X happens to go wrong. There are certain issues that can be triggered in either KDE or Gnome (since X is beneath both of them), and some of them are fairly crippling. Maybe most users don't have the issues with X that I do. I find that very easy to believe, since I tend to be one of those users who manages to scrape even the most insignificant bugs out of any software.
I would think open-source users would be more akin to a certain way of thinking. For example, a piece of software isnt good "just because" it's entrenched. If that's the case, then that just creates a whole boatload of defenses for the proprietary softwares like Microsoft. X has issues, it's fairly limited as far as a display protocol goes, unless I'm misremembering it is the *only* display manager between Linux, Apple, and Microsoft systems that is single-threaded... and the main reason it's not replaced is that it's such a very daunting task. Now I'm not saying that's not a good reason (I certainly don't have the gall to try to replace X), but it's a very poor defense of it.
Then hire (and more importantly pay) a mechanic to fix it. A mechanic doesn't do what he does out of the goodness of his heart and because he likes other people. He wouldn't be able to pay his bills if he did that. You are not entitled to free car service just because you are you, just like you are not entitled to free and open source software changes on your whim.
If you know him personally or if it's a side project or it interests him enough, he may do it for free. That's his choice as to how to spend his time. However, the vast majority of programmers in the open source community think that X works. They aren't interested in pursuing an alternative, at least not for free. I'll bet if you offer to pay their salary, their interest would be piqued. I'll bet if you had the skills to write one on your own, you could do it and attract some mindshare. Now, and this is key, sitting around on Slashdot and bitching about it won't solve the problem.
Do it yourself because you are interested, hire someone else to do it, or accept that the vast majority of open source development is done because it's in the best interests of the person working on a particular project, and right now, the consensus amongst open source developers is that the X Window System works.
You mean loosing 5 years (and a manpower needed elsewhere) on a rewrite, while in the meantime Xorg will be improved to the point that a rewrite is pointless? (we can't just drop X protocol compatibility or all existing applications will stop working).
Even porting only Qt4 (so your new operating environment could run KDE4.0 apps but not Gnome apps) would take a whole team of programmers some years.
That said, Y and Berlin _do_ exist, and are very pretty... why don't take a shot at it?
It's better to be the foot on the boot than the face on the pavement. ~~ tkx Kadin2048
I know X is entrenched and all, but really, aren't we all fed up with this dinosaur? A new window system might be a good thing for Linux as a whole.
Why does every new kid on the block insist you have to replace it to be any good without knowing how much effort it takes to get a GUI working right?
X-Windows is also 1984 from MIT as Wiki on X-Windows, which makes it almost 24 years old. And components of it likely existed before it's 1984 debut. It has had a lot of years to become polished. For without it Linux would likely still have some proprietary GUI that can't be used with other hosts. That is, I enjoy login into Linux, login to a different vendor of Linux or perhaps a BSD, AIX or Solaris....and it works!
I will admit, having used and programmed X-Windows from almost year one, it was initially heavy, had alignment bugs and was no where near like today's X. It was in fact ahead of it's time but now that the graphics hardware has enough juice it is in it's prime. A portable inter-operable network/GUI.
And just so you don't think this fossil is stodgy, GTK is a fantastic Motif replacement. You should try it, real nice.
Don't try to make Linux look like Vista, Vista will not last. And X-Windows will outlast Bill Gates himself. Bills empire still can't do portable Windows without outside help. Perhaps spend your time with that new X-Windows desktop for Linux, the one with the cube.
This is what you get when most of your windowing system is run in the kernel: the low-level drawing and management routines are just a syscall away. Plus I believe the Windows window system is multithreaded (or, at least, much of the stuff runs in the applications' threads when they make windowing calls). X.org, on the other hand, is single-threaded and runs as a user-space process, so there's also context switching overhead. [All that "Ha-ha, NT runs its video drivers in the kernel" stuff is misleading; the criticism wasn't that the hardware support was in the kernel, which is where it should be, it was that a load of management stuff was there too.]
Personally I'd like to see a lot change in the structure of X11. I'm not fond of the way the 2D stuff appears to work by acquiring privileged maps to areas of physical memory, effectively subverting the kernel. I'd much rather it were all built using DRI. In-kernel modules would be responsible for mediating access to hardware registers. The heavy lifting and config part of the drivers should be done in user-space (much like MesaGL) with a minimal multi-threaded graphics server. X11 would be run as an application on top of this to provide network/legacy support, etc. But then again I'm not an X.org developer and they probably know better.
Nice troll, first post too. 9/10.
Give me Classic Slashdot or give me death!
Let me put it this way. If we were to come up with say, a new open standard for a window system API, and all the associated drivers necessary for it, etc., and we were to submit that to ISO, we would call it something like the Open Window Standard or somesuch. X.Org would rename themselves to "Open X.Org." X is as much a defacto standard as .doc, but that doesn't make it good. And anyone whose ever had X break on them can testify to the fact that it's just not an elegant solution for how to do things. It's inefficient, it's monolithic, it doesn't play well with multiple processors, it has all these flaws. I didn't think I had to bring those things up: this is Slashdot, we know the flaws are there. Dammit, we should be complaining about them shouldn't we?
Since when does Open Source mean we have to be content with what we have and bitch at people who say what we have isn't better than the competition? I love Open Source, I'd eat, drink and sleep with Open Source. My toaster should be Open Source. And in some ways it's really, spectacularly advanced. Server applications for example, top-notch. But for desktop users we have a monolithic window system that breaks, all the damn time, and has fallen so far behind the competition that it's only recently become usable and with an enormous investment of effort into hacking 3d rendering into it.
I shouldn't need to say those things though, as I said, this is Slashdot. People here know what the problems with X are, dammit, I'm announcing my dissatisfaction. People reply with "You don't like it, code your own," ok. Let's start. Let's make a development program for a replacement for X that will correctly process the hooks for a few popular toolkits (QT,GTK+) and work from there. If we can get QT4 and GTK+2 working on something -other- than X, that will be major progress.
Look, I know this is the standard FOSS fanboy answer to any criticisms about anything and everything, but it's gotten tiresome - it doesn't actually address the criticism at all. It's on the same level of relevance as if you'd responded "Oh, yeah? Well your momma's fat!"
But the original post didn't have any criticisms to answer! All he said was X was a dinosaur. No specific complaints of any kind. So what better response to a content-free question than a content-free answer?
Give me Classic Slashdot or give me death!
Windows XP has the GDI and Window Manager in the Executive. A lot would probably argue that this, and the most computationally intensive parts of the drivers should be in user-space, leaving the kernel to handle the protection of the low-level hardware interfaces.
"Look, I know this is the standard FOSS fanboy answer to any criticisms about anything and everything, but it's gotten tiresome - it doesn't actually address the criticism at all."
And you think complaining about it is somehow going to magically solve the problem? Problems are solved because *someone* creates a solution, not because people whine about it. If everybody complains and nobody actually does anything about it, then the problem will continue to exist forever.
"It's on the same level of relevance as if you'd responded "Oh, yeah? Well your momma's fat!"
No it isn't. Such a comparison is utterly ridiculous.
Have you measured the cost of network transparency, and would you be willing to debate Jim Gettys and Keith Packard about that being one of the bottlenecks? (This is one of the persistent myths of X11.)
how to invest, a novice's guide
KDE is not a windowing system, neither is GNOME.
For KDE kwin and plasma are the windowing systems, for GNOME it's metacity and compiz.
<\nitpick>
Truth arises more readily from error than from confusion. -Francis Bacon
If you don't like the software you can try to get the developer to fix it, by sending detailed bug reports or requests for adding some functionality. The developer may, or may not, work on your requests.
But you are NOT entitled to bitch about any of the work done. You are free to not use it, to fix it yourself, to have someone fix it for you however.
If you don't contribute yourself then you may take what is offered or you can leave it alone. But, as parent put so eloquently, SHUT THE FUCK UP if you're only going to whine.
Let me put it this way. If we were to come up with say, a new open standard for a window system API, and all the associated drivers necessary for it, etc., and we were to submit that to ISO, we would call it something like the Open Window Standard or somesuch. X.Org would rename themselves to "Open X.Org." X is as much a defacto standard as .doc, but that doesn't make it good.
Was there a point to all that?
And anyone whose ever had X break on them can testify to the fact that it's just not an elegant solution for how to do things.
If X is breaking on you all the time, you're doing something wrong. X is very stable.
What specific problems have you had?
It's inefficient
It's at least as fast as the competition.
it's monolithic,
So? How does that affect the user?
it doesn't play well with multiple processors,
It works just fine on my dual core system.
I didn't think I had to bring those things up: this is Slashdot, we know the flaws are there.
No we don't, we use X every day, and we quite like it thank you very much. These days saying that X is a dinosaur sounds a lot like saying that BSD is dying.
Give me Classic Slashdot or give me death!
It's good to look at why one wants to replace something, and not replace it if it's not broken.
But really, X *is* a dinosaur. The drawing operations it has to support were neat when we had 1-bit displays, but aren't that useful (or accelerated) on modern hardware. Its imaging model is completely different from modern printers and page definition languages. Antialiasing and transparency (at the window level) is obviously an afterthought, and resolution-independence was an early goal that nobody really got working. Font support is only so-so. Color calibration is basically nonexistant. It has a bunch of individual features which run great, but not with each other, like OpenGL and video and Xinerama. Compositing support is still kind of flakey. Network support can be useful but X11 screwed up the design. The Unix Haters' Handbook has a whole chapter of other issues.
And sure, we could (and probably will, eventually) fix each of these things. But X11 seems to never drop its old baggage, even when nobody's using it. So when somebody wants to fix fonts or colors, they'll do that by adding new extensions (which have to be installed in the server, yay), and now we'll have N+1 ways to do these things, and still most people won't use the good new way. Anybody who's done software testing can tell you about the reliability of N orthogonal features; it's no wonder compositing + video + OpenGL + Xinerama doesn't work.
There's something to be said for wiping the slate clean and saying "OK, it's 2008 and we now know how to do compositing and acceleration and video and fonts and colors, so we're going to throw out all the dead ends we've created in the past 25 years, and start fresh". (You can even run X11 inside whatever graphics system we create, like X11.app on the Mac.)
Writing a network protocol for a graphics system isn't fundamentally that hard to do. There's no black magic here. Linux users claim to know better than anybody the problems with a monoculture. And yet, X11 is so monstrous that there's really only room for one implementation; there simply aren't enough graphics geeks who are willing to put up with the pain of maintenance to support several. So when Xorg forked, it was a Really Big Deal. It shouldn't be! Note that the programs that open-source does best are those that we have a million of (like text editors, or chat clients, or MP3 players), and those that we always complain about are the big monsters that nobody is crazy enough to write a new implementation of (X11, OOo, Moz). I do not believe this is a coincidence.
I would really like to have a graphics system that is simple enough that I (with only a 4-year degree in computer science) can understand, and which we're using because it's the best design we can come up with, not because it's the only free windowing system we could find in 1984.
That's less and less the case. The whole of my xorg.conf was written automatically without my participation. The only thing I was asked was the layout of my keyboard.
Sucking was when you had to invoke the help of the mightier gods in order to protect you from having your monitor burst in flames and/or emit very acute noises when you were trying modelines and sync rates...
What criticism? The complaint didn't describe anything actually wrong with X. I see no problem with the "put up or shut up" response when the other person hasn't even bothered to describe what problems they think need to be fixed.
Bogtha Bogtha Bogtha
What `issues' would you describe as crippling?
In what way being multithreaded would help? Do you know or are you simply repeating something you heard?
So there are multi-billion-dollar corporations working to keep X11 so entrenched as to ensure profits for said corporations?
All comments are properties and trademarks of the voices in my head. Not like I'm gonna claim them.
No idea who they are.
It's kind of a moot point anyways, like I said, today's computers are so fast the overhead of X probably doesn't matter. It's just that I spent some time in 2000 looking at what X events come up during a normal session - there were a lot. A lot more than there were on Windows IIRC.
Though the tone of your post suggests there's some other major bottleneck, besides the network layer - care to share?
Truth arises more readily from error than from confusion. -Francis Bacon
Good suggestions. Fortunately that's exactly what Xorg/DRI/DRM people are working on. Future graphic system on linux will have full drivers in kernel, rootless X, and all that with unified 2D+3D acceleration. They also want to get rid of a VT switch in the future and allow for multiple accelerated instances of X, but also non-X acelerated apps.
With Gallium a userspace acceleration will get a performance boost and cleaner architecture.
lol man that brings back memories... remember the sizzling noise it used to make if you screwed up your vsync?
good times, good times.
Actually, here in slashdot what we get is lots of people, much as yourself, mentioning flaws. But very few people have any real idea of what they are talking and about one third (being generous!) of the posters are probably among those that think that KDE is a window manager, that QT and GTK are part of X, and that have some very mystical and completely misguided understanding of how the SELECTION protocol works.
There are flaws. This is obvious from reading the mailing lists of the X developers. But your blowing hot air about `flaws' in no way is comparable to any positive action with regards to their solution---let alone their identification.
But for desktop users we have a monolithic window system that breaks, all the damn time, and has fallen so far behind the competition that it's only recently become usable and with an enormous investment of effort into hacking 3d rendering into it.When does it break, exactly, and all that frequently, for desktop users? In what way does its being monolithic affect anyone apart from its own developers? Are you really not aware of the reasons why accelerated 3d rendering goes at somewhat glacial speed?
I shouldn't need to say those things though, as I said, this is Slashdot. People here know what the problems with X are, dammit, I'm announcing my dissatisfaction. People reply with "You don't like it, code your own," ok. Let's start. Let's make a development program for a replacement for X that will correctly process the hooks for a few popular toolkits (QT,GTK+) and work from there.Ah. I see. You are going to be in charge of the management of such a project... And I imagine you'll want to participate in the critique part, too! We will contact you.
If we can get QT4 and GTK+2 working on something -other- than X, that will be major progress.Both work on top of things other than X, on top of several different things in fact.
Not being psychic, if the best vocalization of your problem is "I have a problem", but refuse to say any more detail at all than that, then yes, you can't be helped, sorry. You appear to be inserting words into the OP's mouth beyond that -- the OP didn't even say they had a problem! They merely said X is old, and had no actual criticism to offer at all. Being old isn't in and of itself a problem, but it's the only issue that poster appeared to have. You don't have to be tech-savvy to say you have a problem, and to try to explain as best you can what the problem is, but OP didn't even get as far as saying they had a problem, much less even offer a clue as to what the problem might be.
If the problem is bugs, then the bugs need to be fixed. If the problem is inherent in the design, then the design needs to be redone. But if the problem is "it's over X years old and running software over X years old is uncool" then the software doesn't need fixing, the user's attiude needs fixing. Since OP appears to have no problems other than age (no complaint was made other than the age of the software), then frankly his comment should have been modded as the obvious troll that it is. Even if it's true that X actually needs fixing or replacing, that doesn't justify pointless trolling.
It's a sad commentary on the rampant abuse of the mod system that you admit you'd give him mod points merely because you agree with him, rather than objectively mod him down, not because you agree or disagree, but because it was a bad, content-less post. Your own post was actually interesting and informative of what the actual issues are that people have with X (unlike the post you're replying to, which was in fact nothing but a troll). Mod points shouldn't be handed out because you support a cause, they should be handed out because the post is a good one, whether you agree with it not. (Or negative points given if it's a bad post, whether you agree with it or not.)
"Convictions are more dangerous enemies of truth than lies."
What you mean is that the Xfree86 and xorg implementations of the X server for the PC are single-threaded. I don't think there is anything in the standard that prevents X servers in general from being written differently. X clients, like browsers or window managers, are not single threaded.
The problems of being single-threaded are simple and easy to find: something hanging causes all updates to stop. The bugs that you get in multi-threaded code are generally much worse: locking problems and concurrency issues can be very hard to track down.
Access to the hardware has to be serialized anyway, so its not clear that multi-threading the server is going to result in any major improvement. It would speed up any rendering that is done in software and could be parallelized, but would not help X operations that are a single call to the graphics card.
Intron: the portion of DNA which expresses nothing useful.
wait wait wait
your computer is in a house
the house's windows are made of glass
therefor only things made of glass are window managers, such as glassfish
I wouldn't want a window made of plasma!
Why?
On my version of Ubuntu that I just installed it is working just fine and is pretty fast.
Most of the problems with X have to do with the current implementation and not with X.
Improving X is what needs to be done.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
Quite a bit of XP's 2d drawing functions are accelerated using video card driver supports. All the blitting, etc.. which may be supported in Linux drivers was pretty much stock in every well used Windows graphics driver since 2k.
You ever run into the issue that Firefox scrolling is sooo slow? Its probably because the scrolling routines aren't being 2d accelerated like they should be.
Putting too much in user space might seem like a good compromise, but depending on how often you context switch to achieve this separation, the trade offs could be quite inhibitive. I'm not much of a driver programmer and I've never even looked at a graphics driver implementation, but given the cursory glance at the ATI released register mappings, I imagine that the setup and maintenance of said buffers requires quite a bit of hand-holding.
Bye!
that just because the software is old doesn't mean that it is bad. In fact the case is often that old software which has withstood the test of time is often *better* than newer programs.
.... ...
Having said this, X has had a bit of a controversial reputation for a *long* time. One day a number of years ago, I ran fortune and got the ABC's of UNIX:
A is for awk which runs like a snail
B is for biff which reads all your mail
C is for cc as hackers recall
D is for dd, the command that does all
W is for whoami which tells you your name
X is, well, X, of dubious fame
The basic issue is that X has traditionally been riddled with difficult (often nearly useless) error reporting, complex setups, low-level configuration issues which could cause hardware damage with older monitors, and the like. In some cases, documentation can also be a problem.
However, over the last decade or so that I have worked with X (and especially the move from XF86 to X.org), these issues have been greatly reduced. Even when I hack configuration files, I find that things are a lot more pleasant than they used to be and that error messages are almost always more meaningful. Yes, it is still a beast, but it is far better than it used to be. I expect it will continue to get better.
The large question as to a successor is a big one. I am not sure that it is possible to displace X at the moment. However, even if it happens, it will be extremely difficult to fill the entire market that X fills.
LedgerSMB: Open source Accounting/ERP
I have been using X since 1990 and it has *always* been fast enough for my purposes, except when used over a slow network link. I wish that they had improved the network performance of X long ago, but I have read recently about improvements that supposedly make X over slow links useable, which is great.
Aside from that, X has *always* been fast enough for me, to the extent that I have never considered it to be significantly different from, say, Windows on the same platform.
I'm talking about computers all the way from Digital DECStation 4100s (which had the processing equivalent of maybe a 486 sx 33), to Pentium 100s, AMD 233s, Athlons, Pentium Ms, desktop, notebooks, Sun SparcStations, you name it.
I don't know what it is you are doing, but your assertion that X has been perceptibly slow until modern hardware of the last couple of years made it fast enough flies in the face of over *two decades* of my own experience.
X may not be fast enough for high performance games or 3d stuff, that may very well be true, but considering the number of games available on X platforms, that is hardly important, and only affects a small number of applications and a small number of people who use them. And it's my understanding that lots of improvements have been made recently with respect to gaming in X, which is not surprising since nobody really wanted to play games in X until recently - we always used to just Do Real Work. Not that I have anything against games, I'm just saying that this aspect of the windowing system didn't get much focus until recently because the typical user of X didn't need it until recently. I do remember playing XEvil about 10 years ago, that was fun, but hardly a game that would stress any windowing system.
Ok, I don't think that the line between users and developers is entirely non-existant in most FOSS. In general you have:
1) Core maintainers (aka project leaders, steering committee members, etc)
2) Committers
3) Users/implementors/developers. They may all contribute in their own ways (bug reports, documentation, patches)
One of the key issues in FOSS community management is helping people contribute optimally. Even discussion about missing features should be encouraged because even if the original poster can't code, someone else who can may read the discussion thread.
Users, developers, etc. are not entirely separate in FOSS communities but they are not entirely the same either.
LedgerSMB: Open source Accounting/ERP
Jim is one of the original authors of X. Keith is essentially the de facto overlord of the current X.org, although he doesn't play dictator except in rare cases.
As for rendering bottlenecks, they are many and varied and none of them have to do with the network transparency issue. When local clients talk to a local server they do so via local sockets or shared memory, both of which are very fast and impose minimal or no penalties.
What accounts for bottlenecks are things like the inability to do compositing, leading to tearing of windows when they're being dragged. This is fixed by the composite extension and a fast compositing manager, like the one found in compiz.
Another issue is that the old driver architecture (XAA) was geared towards old-style drawings. These days we don't really look at stipple patterns much, so the new driver architecture (EXA) is geared towards solid fills and fast blits for bitmaps instead, which is what you end up doing on a modern desktop anyway. It turns out though that this is very hard to get right and the bugs are still being worked out. I don't think that this is really an issue with X being old so much as that this is just a damned hard problem to get right. It is being worked on (check out Carl Worth's blog for some examples on this particular front) so hopefully things will improve.
Finally, there's the constant bottleneck due to incomplete or inadequate drivers. The new radeonhd, for example, only recently gained 2d acceleration support, and still lacks any sort of 3d accel. This sort of problem prevents X from adequately taking advantage of all the hardware has to offer, so performance can suffer. As a result, you lose the ability to run things like compiz, which address these issues.
Finally, I haven't watched it yet, but I recommend you take a look at Keith Packard's google talk on remaking X. X has been largely rebuilt from the inside over the past several years, and things like Render, RandR, Composite, Damage, Fixes, Input Hotplug, and EXA have really sprung from that initiative. It's wort
"I may not have morals, but I have standards."
They didn't even try to make it speedy - the network transparency layer (among other things) creates so much overhead it was a pain to use X11 until relatively recently.
That's not true. Locally, X communicates through unix domain sockets which aren't any slower than any other form of interprocess communication.
When XP was first released its windowing system actually felt more responsive than X11 did on the hardware from that time.
Also not true. A light weight window manager (I used icewm at the time) has always out performed XP on any hardware I've tried. You're probably conflating GUI toolkit bloat (which is a real problem) with the performance of the X server.
Give me Classic Slashdot or give me death!
I've not had X successfully autoconfigure on any Macintosh I've ever owned, save for an LC-III running NetBSD. On "normal" PCs, I've had much better success lately, but specifically I was referring to the mystery that is configuring the xorg.conf by hand.
Have you tried getting out of the car and getting back in?
Your courageous and selfless spelling corrections have made me a better person.
I used to be involved with Berlin. Berlin was re-renamed back to Fresco and has been dead since 2003/2004.
DNA just wants to be free...
X11 tunneling over SSH would be sorely missed.
X is as much a defacto standard as .doc,...
.doc, the X11 is fully documented, and there exist multiple implementations, both free and commercial, both open and closed source. If you want to write another implementation, you don't have to reverse engineer anything, you just read the documentation. It does not have an official stamp of approval of some international standard body, but it is open and documented. ...this is Slashdot, we know the flaws are there...
Er, no. Unlike
That may be true, except that we don't seem to agree exactly on what the flaws are. If you read the posts here, the few posts that actually list specific flaws seem to each come up with a different list.
Let's start. Let's make a development program for a replacement for X that will correctly process the hooks for a few popular toolkits (QT,GTK+) and work from there...
Anybody knows what happened to the Berlin project? Their web page seems to be gone.
AccountKiller
Does it talk about how to get the bloat out of X, and perhaps low bandwidth?
Not bashing X as its got its place and is universal, but no one can honestly say its resource friendly.
---- Booth was a patriot ----
DirectFB?
The general defense I keep seeing for X seems to be that people "aren't criticizing it properly". As if to say that just having problems with X isnt sufficient if you don't fully understand and can vocalize on those problems in a tech-savvy manner.
I think you'll find this is true in general. If you can't explain your problems to the people who you want to fix them, they won't be fixed.
In the past year, I don't know how many X problems I've run into
Well could you describe just one of them? It should be easy if you've had so many.
*most* of them being related to the fact that X itself is single-threaded
How do you know?
There are certain issues that can be triggered in either KDE or Gnome (since X is beneath both of them), and some of them are fairly crippling.
Again, such as?
Maybe most users don't have the issues with X that I do. I find that very easy to believe, since I tend to be one of those users who manages to scrape even the most insignificant bugs out of any software.
Sounds like you like to fuck around with things you don't understand. Don't do that.
I would think open-source users would be more akin to a certain way of thinking. For example, a piece of software isnt good "just because" it's entrenched.
I don't think anyone here is saying that. In fact, I think you, and the OP are saying the opposite: X is bad "just because" it's entrenched.
Give me Classic Slashdot or give me death!
I wasn't talking about the network performance - that of course is negligible when there's no real network, when all communication is local.
What I meant was the whole layer of code that provide this network transparency, which every X event must pass through no matter what.
Also not true. A light weight window manager (I used icewm at the time) has always out performed XP on any hardware I've tried. You're probably conflating GUI toolkit bloat (which is a real problem) with the performance of the X server.
It's kind of hard to compare windowing systems when you use something as lightweight as IceWM on one and the windows shell on the other. Assuming things like IceWM generate a fewer events, I tried to push both equally by using GNOME.
Truth arises more readily from error than from confusion. -Francis Bacon
Sorry, but that totally reads like 'get of my lawn'. My old man thought GEM was plenty responsive too...
I assume you actually used DECWindows on that DECStation, and doesn't SUN have it's own implementation of X too? I think it's safe to assume both Digital and SUN made some effort to make their windowing systems responsive - maybe with a lightweight window manager, maybe by cutting back on features, I don't know.
After using computers for such a long time as it seems you have, I think it's pretty natural to become more tolerant concerning responsiveness. I experienced that when I was still using my 233 MHz AMD in 2003 - which still seemed to be an okay computer even though everyone else was using >1GHz CPUs. Since then my upgrade cycles got shorter though..
Truth arises more readily from error than from confusion. -Francis Bacon
It might be, it might not. Now if we could just pin down whether we have a problem or a whinge... we might just get somewhere, or we might not. The change X.org needs is a name change. I mean, Apple has Carbon or something, Windows has Aero... OSS has... Unknown Designation? I propose we drop the period for the next major release thus we have Xorg (pronunciation: \zORg\) ; which EVERYONE would agree that it sounds better than X.org (pronunciation: \'ecKss\ \dot\ \org\) or (pronunciation: \'ecKss\)
Semi-automatic amateur armchair Australian philosopher; conjecture ready at any moment...
"You're pretty new to this eh?"
"Sorry but that totally reads like 'get of [sic] my lawn'. My old man thought GEM was plenty responsive too..."
Why do you feel a need to trivialize the comments of the people that you respond to in this way? Do you have some kind of deep-seated insecurity about your viewpoint that requires that you disregard others' points by dismissing them using phrases like the above? Do you think there is any good reason to dismiss the personal opinions of others in this way when your posts are nothing but opinions themselves?
aren't we all fed up with this dinosaur?
Not really, no. As a user and application developer, X works great for me. It provides the functionality the user needs, and application developers is largely isolated from low-level X APIs by their GUI toolkit (GTK+, QT, etc).
A new window system might be a good thing for Linux as a whole.
I'm not sure about that. Inventing something new without first establishing what is really wrong with the existing product (and for whatever reason, can't be fixed) would be a waste of time. This is why all the attempts at creating a better window system than X on Linux/Unix have failed; they don't have a driving reason for their existence, or a killer app that would ensure adoption.
Funny fact: my NX remote is noticeably faster than RDP, at least twice as fast despite the fact that my Linux box is halfway around the world.
Despite that, I strongly dislike X. I feel it takes the Unix philosophy too far outside its comfort zone. What is X anyway ? What does X do by itself that's not delegated to the window manager, the decorator, the QT libs etc... How is X any different from that generic GUI framework I built in a thousand lines of Pascal and assembler back in the 90's before Windows tried to be its own operating system ?
I find X very painful to program, thanks to a zillion libs that all love to fight over the same castrated resources. It's just not pleasant at all, and doesn't lend itself to elegant GUI design.
I think what gets me the most is how poorly various programs interoperate, there's no consistency at all. Pretty much all I can bring myself to do with X is launch a bunch of terminals and a web browser - it's all easier to do on a command line than through the various half-broken GUIs everyone loves to abandon on SourceForge.
-Billco, Fnarg.com
Semi-automatic amateur armchair Australian philosopher; conjecture ready at any moment...
I don't pretend to possess much in the way of social skills. You're critisism is noted, and for the first one totally valid. So, if you're still reading this jrothwell97, sorry.
That other comment, emphasizing two decades of experience, does remind me a little of an old man ranting. It wasn't meant as an insult though, I was.. well, joking I guess. Seems it didn't work, probably was a lousy way to start a reply with, so sorry to you too.
About my posts being opinions, well, yeah, of course they are. But I did try to be constructive in this discussion, even though the things you quoted say otherwise.
Well, guess I broke it. Was fun while it lasted though.
Truth arises more readily from error than from confusion. -Francis Bacon
Berlin apparently became Fresco http://www.fresco.org/ and haven't had any visible development since 2004. Last release was 2003.
Semi-automatic amateur armchair Australian philosopher; conjecture ready at any moment...
But the code is out there
It's better to be the foot on the boot than the face on the pavement. ~~ tkx Kadin2048
I've been using X since 1998 and it has *never* been fast enough for my purposes, even when used entirely on the local host.
Even on my recently installed Ubuntu 7.10. You can move windows around and watch them wobble, which is nice. But if you minimise and then restore something like firefox and thunderbird, it takes a second or so to completely redraw itself.
In fact, if you open this discussion say, in fifteen tabs on firefox in an X environment, the whole system will grind to a halt. Do the same on any Windows or Mac OS from 2000 onwards and it'll be fine. When moving from my puny Mac mini onto my relatively powerful ubuntu machine, I suddenly have to be really careful not to do anything that might slow the system down.
X may not be fast enough for high performance games or 3d stuff, that may very well be true, but considering the number of games available on X platforms, that is hardly important.
Err... cause and effect?
Did you know a Miles O'Neal from the early days of X? If so, feel free to drop me a line at MEO at RRU dot COM. Or even if you didn't, what the heck!
Absolutely. That's why I find the standard response of "well fix it yourself" to be so boorish and irritating. Criticisms should not be dismissed simply because they come from someone who's not a programmer. I think you put it very eloquently when you talk about helping people to contribute.
... and then they built the supercollider.
And what evidence do you have that any of the problems that you are seeing are related to X?
I open discussions in many tabs all the time and my system doesn't grind to a halt.
I suspect the problem is more likely the tremendous amount of bells, whistles, and cruft that go into a "modern" Linux desktop implementation. I still run twm and no Enlightenment, K Desktop, Gnome Desktop, or any of the countless 'servers', 'D-Bus clients', or any of the reams and reams of associated stuff.
I think that the bloated nature of Linux desktop implementations is more likely the cause of your problems than your X server. I can say with fair certainty that if you keep your desktop trim and light, as I do, that performance is very good. X doesn't enter into it; any system that was running as much crap as modern desktop systems do will have poor performance.
An example is my father-in-law's computers. Any of them. He always installs the latest version of Windows, and every single little task bar applet, browser plug-in, desktop quick-launch software, etc, etc, that he can get his hands on. I can't quite understand his thinking, except to assume that he really likes the idea of having as much software as he can, just in case someday he needs something. His computers are always much more powerful than mine and yet take 3 - 5 minutes to boot Windows, and when they are up and running, suffer from all of the problems you have ascribed to X; clicking on windows will show noticeable redraw latency, trying to open a pull down menu will cause a noticeable pause, etc.
It's not the underlying window system that's the problem, it's how much 'junk' (for lack of a better term, although certainly one man's junk is another man's treasure) you have gumming up the works. X and Windows are the same in this respect.
It's not that it's difficult, they do a pretty good job now, it's that noone has come up with anything better. A decade ago, some guys got together with something called GGI which was intended to be a non-networking X11 replacement. Its main distinguishing feature was that it would be closely tied to the kernel, much like the graphics in Microsoft Windows is tied. Nothing much came of it.
The biggest problem with X11 has always been looks. Always. The core stuff is ugly, difficult to code with, ugly, not integrated into a single desktop environment and did I mention that it's ugly? The KDE guys fixed all of that, though X11 has been pretty decent though not always integrated since X11R4.
My biggest like about X11 is how easy it is to network with. Your server runs locally, your windows can run natively on any machine in the world. Outstanding!
It's not broken, so it really doesn't need any fixing or rewriting for the sake of rewriting and I like my KDE/X11/RedHat workstation at work more than I like my MacBook Pro.
I'm not offended, although I purposely tried to make myself sound that way in my post to incite your response. So I guess two can play at that game huh ... :)
... I think that a large part of the perceived inadequacy of X is due to the nature of modern desktop implementations. I'm really going to show what an old man I am here, but I *still* run twm, one of the original X window managers, and I have it 'tuned' using a configuration file that does things like remove window title bars (they waste space don't you know), and binding most windowing operations to keypresses (or key/mouse combinations). I don't run any kind of 'start' menu bar, I just type the command name of any program I want to run into an xterm. While my desktop is in no way representative of the reality of modern desktops, it does demonstrate, I think, that performance is to a large degree dependent upon the complexity of the desktop, much more so than the underlying graphics subsystem. All X programs have always run speedily for me, because there is so little running on my system and contending for CPU and video card cycles. I have no fancy effects going on. No D-Bus servers, or clients, no big and complex window managers like the K window manager or whatever one Gnome uses. It's all streamlined and simple. And as a result, I get to see the performance of X when it's not bogged down with 'crap', and honestly, it's pretty good.
As a final point, something I mentioned in another post I made just a minute ago to another poster in this thread
I mentioned in my other post about how my father-in-law's approach to computers is to buy (or build, actually he likes to build his own systems, to his credit) the fastest stuff available, and the absolutely *load* it down with the newest version of Windows and every task bar application, quick-launcher, drag-and-drop utility, browser toolbar, etc, that he possibly can. It is absolutely no joke when I say that he, for example, will have two or three browser toolbars installed at once (who needs BOTH Yahoo and Google toolbar at the same time? You end up with the top 1/3 of every browser window being covered in little buttons and doodads that are totally redundant and useless). And he'll have 2 or 3 drag-and-drop CD-burning applications running from the taskbar at the same time. On top of that, every little task bar icon known to mankind; there'll be literally 15 - 20 of them in there. His computer, despite being way faster than anything I ever owned, boots in like 5 minutes, and once booted, every windowing operation is sluggish; redraws can be watched as they occur. Opening windows or pulling up the Start menu or clicking on a drop-down menu literally takes several seconds. It is insane.
This is an example of how the exact same poor performance that you are ascribing to X, can be achieved on the supposedly superior (from a performance perspective) Windows "directly in the kernel" graphical system.
I installed Linux on a USB drive and booted his same computer up with it, and it was so fast and snappy in comparison to his Windows XP installation, it was amazing.
So my point is, that really the slowness is almost certainly caused by the amount of work being loaded onto the graphical system, not by the underlying performance of the system itself. And Windows and X are no different in this respect.
There are lots of programs that use Xlib and no bloatware libraries at all.
but have you considered the following argument: shut up.
Not bashing X as its got its place and is universal, but no one can honestly say its resource friendly.
Are you sure? I've personally used X on these machines:
http://en.wikipedia.org/wiki/SPARCstation
http://en.wikipedia.org/wiki/Intel_80486
http://en.wikipedia.org/wiki/SGI_Indy With accelerated 3D in 1993.
Not to mention a bunch of other machines I can't find convinient references for. Bear in mind that a well written X11 program will still display on those machines (albeit probably missing some modern features).
Perhaps you're including the mapped graphics card memory as part of its memory usage (as top does). It will also happily cache as many pixmaps as it's allowed to. Perhaps you're including that as well.
20 years ago, X was a monster. These days you emulate the machines it ran on then faster in emulation than the old machines ran in hardware.
But if you still really care about the so-called `bloat', then try installing KDrive (part of the recent X11 distributions) and use that instead of the main X server. It's used find for embedded systems, so it will be OK for your PC. If your PC is still suffering under the load, then you machine is probablu so old that you could drag a faster one out of these for free.
SJW n. One who posts facts.
So you're saying it is only fair to compare X to a bloated pig by making it a bloated pig??
It worked really well the last time I installed X on a Macintosh. Of course, it was an SE/30 running NetBSD on the built in display. It worked quite well with minimal configuration.
Unfortunately in this thread though the OP (possibly a troll) simply said that we need something else because X is old.
I am quite happy to disregard that criticism as invalid, not because it came from someone who can't code but because it isn't useful in building better systems. So you are left with one troll being countered by a problematic but all-to-common response.
A better response would have been:
"Then get involved. Help make X better, build an alternative, or something else. These things require participation (including but not limited to coding) so...."
LedgerSMB: Open source Accounting/ERP
And here I thought the Window Manager was the guy who yells at the fry cooks and consoles the waitresses when they're sent out with buttered toast on the plate of a customer who explicitly specified dry toast.
Then again, I was once the 'toast cook' at a place where I 'managed the window' and it was the opposite of that. You scampered to keep the toast coming in the right format for each order from the middle, with waitresses screaming at you for buttered toast, etc. and fry cooks shoving plates full of food at you.
(we can't just drop X protocol compatibility or all existing applications will stop working).
Microsoft wishes we would. In fact, if we started shitcanning everything with each major release number, Microsoft would like it very much. They wouldn't mind an even playing field for once.
Sure. While we're at it, I know "Hello World!" is entrenched and all, but really, aren't we all fed up with this dinosaur? A new introductory programming example might be a good thing for Linux as a whole.
It's not at all clear that we could gain anything by starting over, and in fact we'd probably lose quite a bit. Yes, there are old methods to do things, but they are being deprecated or replaced outright. XCB replacing Xlib is a particularly good example, as is the replacement of server-side fonts with client-side. Essentially these things aren't real issues any more, so they don't take up any real mental bandwidth when you need to work on X. The drawing model and things that the UNIX Hater's Handbook talks about have been pretty well addressed over the last half decade. Cairo is the official replacement for the old drawing model that X provided, and Cairo works really well and is getting better all the time. The problems you're talking about, like compositing well and having video work well with OpenGL, are not trivial problems, and they are often unsolved. We don't really know how to accelerate all sorts of rendering operations (glyph rendering is proving to be particularly difficult at the moment, for example) and for things like video in a composited opengl context it's highly unlikely that the code would get written any faster or cleaner if you were starting from scratch rather than reworking the existing codebase to make this necessarily complicated thing happen. You're also ignoring many of the problems that X solves remarkably well. It's an incredibly modular design that allows for extensibility with simultaneous backwards compatibility. It actually does a very good job of managing windows. Finally, it does a ton of the dirty work like knowing how to read EDID blocks, parse a configuration file, or allow drivers to execute x86-mode BIOS calls on non-x86 hardware. All of this can be unpleasant code to write where you'd gain little or nothing by rewriting it. So yeah, a cleaner design would be nice, but a vast amount of code has been fixed by deletion from the X server, to the point where the size of the server actually has gone down between some releases. So things are improving, and while it's slow, at least it's moving at a visible pace these days. Because of this, I'm really not convinced that starting over would get you more than the joy of reimplementing solutions to hard problems.
"I may not have morals, but I have standards."
(Argh, why did I not use preview? Sorry, posted again with formatting!)
It's not at all clear that we could gain anything by starting over, and in fact we'd probably lose quite a bit. Yes, there are old methods to do things, but they are being deprecated or replaced outright. XCB replacing Xlib is a particularly good example, as is the replacement of server-side fonts with client-side. Essentially these things aren't real issues any more, so they don't take up any real mental bandwidth when you need to work on X.
The drawing model and things that the UNIX Hater's Handbook talks about have been pretty well addressed over the last half decade. Cairo is the official replacement for the old drawing model that X provided, and Cairo works really well and is getting better all the time.
The problems you're talking about, like compositing well and having video work well with OpenGL, are not trivial problems, and they are often unsolved. We don't really know how to accelerate all sorts of rendering operations (glyph rendering is proving to be particularly difficult at the moment, for example) and for things like video in a composited opengl context it's highly unlikely that the code would get written any faster or cleaner if you were starting from scratch rather than reworking the existing codebase to make this necessarily complicated thing happen.
You're also ignoring many of the problems that X solves remarkably well. It's an incredibly modular design that allows for extensibility with simultaneous backwards compatibility. It actually does a very good job of managing windows. Finally, it does a ton of the dirty work like knowing how to read EDID blocks, parse a configuration file, or allow drivers to execute x86-mode BIOS calls on non-x86 hardware. All of this can be unpleasant code to write where you'd gain little or nothing by rewriting it.
So yeah, a cleaner design would be nice, but a vast amount of code has been fixed by deletion from the X server, to the point where the size of the server actually has gone down between some releases. So things are improving, and while it's slow, at least it's moving at a visible pace these days. Because of this, I'm really not convinced that starting over would get you more than the joy of reimplementing solutions to hard problems.
"I may not have morals, but I have standards."
You should be able to do this with xrandr. Don't blame X, blame Ubuntu for not making this obvious.
If you don't know enough to know who JG and KP are then you don't know enough to debate X's strengths and weaknesses.
Well, I don't see what was trollish about the OP. I just thought that a smart crowd like slashdot would have known the problems with X, and not needed specific elaboration - I saw it simply as a general comment. I also doubt that the complaint was simply because it is old - the term "dinosaur" has several levels of meaning. If it were old but problem-free, then I don't think it would have been called that, it would have been called "mature" or "tried and true".
Again, as someone else has observed, it seems the true meaning of "troll" has been lost and now simply means somebody who goes against popular opinion.
... and then they built the supercollider.
I ran a X11 CAD program over the network (10M/s) back in about 1991 and it was completely usable. What do you mean by "relatively recently"?
XML causes global warming.
Hmm, actually it was about 1992-93. Memory goes with age.
XML causes global warming.
No idea whether things have improved since then or not, but it suggests that the kernel-level 3D rendering was working OK
Has there been any recent efforts to add at least a sound extension to X Windows. It seems a logical next step.
Keyboard
Video
Mouse
Sound
Think about it. If a Window manager can control mouse clicks/selections on a window, wouldn't it be cool to control the sound coming from that window/app like Vista can.
I know they have things like ESD and nasd and the like, which are network transparent like X, but they don't have nearly the user base X does.
You don't install ANY OS on hardware without considering driver support.
True, but I just install Ubuntu and it recognizes all my hardware, so far, anyway, automatically.
Think so? So because I don't know who made a piece of software, I can't possibly know what's wrong with it?
Truth arises more readily from error than from confusion. -Francis Bacon
I don't see a need for sound in a GUI environment, unless you perhaps need to control window position with spoken commands, but if it's application-specific volume you're after you should check out PulseAudio - it's due to be included in the next Ubuntu release. http://en.wikipedia.org/wiki/PulseAudio
Seems interesting. Maybe im just two lazy to tunnel sound and XWindows though ssh. But I think an integrated system would have its advantages. Can you honestly tell me that you would be fully OK with now sound at all in a GUI enviroment
Don't know, don't care. It worked, and that's all that matters.
Have you ever actually read the "criticisms"? If you did, then you'd notice that almost each and every time, people only say "fix it yourself" if the criticism isn't constructive.
99.9% of the X "criticisms" are some form of "X is old and sucks and must die". They add no value whatsoever other than potentially making people angry. What part of their "criticisms" is constructive? I'm a programmer, I have the ability to improve X, and I might even do it for free. But every time I read "criticisms" like this I fail to understand what exactly it is that they're criticizing. As a programmer, not only do I have no idea what I can do after reading their comments, their comments generate some kind of anger and frustration because of the way they're written.
So what can I do? I suppose I can spend 3000 hours into studying X, only to find out that the "criticizers" are wrong. I would have wasted 3000 hours of my life for the sake of some anonymous Slashdotter that I don't even know!
You say the "fix it yourself" responses are boorish and irritating. That is a very selfish thing to say. Do you think the "X sucks and must die" comments, which contain absolutely no constructive information, aren't equally, if not more, boorish and irritating? So for some reason you are allowed to bore and irritate the programmers - who give you their work for free -, but not vice versa?
Sure. When comparing the performance of two windowing systems, both should be equally stressed. Otherwise a comparison would be kind of meaningless.
Truth arises more readily from error than from confusion. -Francis Bacon
That seems to explain why you're X environment is more responsive than Windows is.
It makes sense that a barebones environment like the one you described will generate a lot less load on the windowing system than the Windows shell would.
Truth arises more readily from error than from confusion. -Francis Bacon
That is pretty impressive. Do you remember the name of that CAD program? They must have had really clever ways to cope with that lack of bandwidth.
With relatively recently I meant up to a few years ago, when GHz CPUs became common. I compared it to Window XP's windowing system - others already gave a good explanation of why it was faster.
Truth arises more readily from error than from confusion. -Francis Bacon
ACAD - (not autocad) - a program commissioned and used by the US DoD.
XML causes global warming.
This is nonsense and follows "if its old its bad" fallacy. Actually X performs quite well, is mature and stable. Quite frankly, trying to switch to something else would lead to a code base that is far more immature and buggy and which has not been as well refined as X has. Sometimes. something is well designed enough that it does not make sense to replace it, this is the case with X. Its clean network client design makes it highly flexible, and it has an extension mechanism that has allowed it to keep up with changing technology requirements. Your views on X are based on nothing more than this idea that if its old its bad, but often it is the case that older software is often better, less buggy and more mature, which is the case with X. I see no reason why X cannot continue to fulfill all of the desktop needs for the forseeable future in a completely backwards and forwards compatable manner.
I disagree with this. Totally. X is not really all that bad or difficult to manage, and it is not a dinosaur. It is the case sometiems that trying to replace something as mature and refined as X with something that is bound to be flaky, buggy and immature would likely create more problems than it claims to solve. When something just works well it does not make sense to replace it. X has been improved with extensions and that is how it can continue to be improved, in a backwards compatable manner. And do we really want 100 different window systems? X being the main standard is actually a good thing. This allows me to know that I can always run an application on an X server, no matter how old the app is, it is supported. X provides a standard interface for the window system. Can you imagine what things would be like if there were 10 different window systems or if some smartass came along and decided to make an incompatable system to fix problems that dont exist with X, or which can be fixed without breaking backward compatability? You would have a dozen different systems, with applications that would run on one and not the other, it would be a nightmare of incompatability. X is actually one of the things that works best on Linux and as far as X itself, i have never had a problem with it. Most problems exist at the driver level, which is not at all actually a part of the X core at all. Work has been done to as well improve X and build new extensions that improve its performance. Anyone who says X is a dinosaur has absolutely no clue what they are talking about and i am GLAD they are not the ones making design and archicture decisions.
I agree that X is not at all a fossil and in fact is at the cutting edge of design improvements and technology such as with compiz. Anyone who says X is a fossil does not have the slightest clue what they are talking about and they apparently have been living under a rock for they have not seen compiz and the amazing things it does. X is polished and a mature code base, it has the benefit of backwards compatability as well. ALl of the downsides of trying to replace something so mature and well developed, with something which is likely going to be, with todays coding standards (sloppy, bloated), to consume far more ram, would probabaly end up being slower, which would be immature and filled with bugs, and which would not be backwards compatable, would create far more problems than it can solve. This is the way most new software is today and X by todays standards is pretty darn efficient and uses less resources than most modern programs I have seen. It makes far more sense as well to develop extensions to X to improve it and in this manner we can make it do whatever we need to do and keep it up to date with the times while backwards compatable. This has what has worked now since 1987 when X11 was released. I am glad people who say that X needs to be replaced are not making design decisions because they do not know what they are talking about and their ideas would give us huge problems for something that carries no benefit to what we have now. X can continue to improve and keep up with whatever new demands may arise while keeping the benefits of backwards compatability. As far as X being slow this is an old myth that refuses to die. It is far faster and uses less memory than vista. I have used X successfully on a 486 with 8 mb of ram! Just try that with vista, you wont get far! ANd yet X with compiz is at the cuting edge support more high end graphics features than Vista does. You have everything you want with X, so I dont see why people are trying to bash it!
I get so sick and tired of these old myths about X being bloated, etc. X by modern standards uses very little resources compared with say Vista, and yet it has kept up with latest improvements in graphics technology. Most of these myths were invented at a time 1980s when computer hardware was very slow 4 mhz for instance, ram was small, and where the true performance problems were with the hardware of the time which was not advanced enough to run much of any GUI. They have nothing to do with X itself but were complaints that were caused by the hardware of the day. By todays standards X is fast, efficient and small on modern hardware, and you will find that vista consumes far more resources than X does.
X is not at all a fossil and in fact is at the cutting edge of design improvements and technology such as with compiz. Anyone who says X is a fossil does not have the slightest clue what they are talking about and they apparently have been living under a rock for they have not seen compiz and the amazing things it does. X is polished and a mature code base, it has the benefit of backwards compatability as well. ALl of the downsides of trying to replace something so mature and well developed, with something which is likely going to be, with todays coding standards (sloppy, bloated), to consume far more ram, would probabaly end up being slower, which would be immature and filled with bugs, and which would not be backwards compatable, would create far more problems than it can solve. This is the way most new software is today and X by todays standards is pretty darn efficient and uses less resources than most modern programs I have seen. It makes far more sense as well to develop extensions to X to improve it and in this manner we can make it do whatever we need to do and keep it up to date with the times while backwards compatable. This has what has worked now since 1987 when X11 was released. I am glad people who say that X needs to be replaced are not making design decisions because they do not know what they are talking about and their ideas would give us huge problems for something that carries no benefit to what we have now. X can continue to improve and keep up with whatever new demands may arise while keeping the benefits of backwards compatability. As far as X being slow this is an old myth that refuses to die. It is far faster and uses less memory than vista. I have used X successfully on a 486 with 8 mb of ram! Just try that with vista, you wont get far! ANd yet X with compiz is at the cuting edge support more high end graphics features than Vista does. You have everything you want with X, so I dont see why people are trying to bash it!
Well, a *lot* of software I end up using gets called by that label by people who don't take the time to even try to learn it (LaTeX comes to mind). With X, I generally find that this is done by people who don't understand the capabilities of the software itself (particularly the network-transparent elements).
My own experience is that X was pretty painful to troubleshoot 10 years ago but is far easier to deal with today. If X is a dinosaur then it is rapidly evolving into a modern bird. I suspect that this is why every (generally well-published) attempt to make a new GUI layer for Linux has not come even close to getting widespread support (and really, it isn't *that* much software to support-- a number of toolkits like GTK, QT, Tk and then leave the other software for the maintainers to port since that gives you enough to be useful).
This suggests to me that no successor is here because none of the successor attempts offered any compelling advantage over the older software.
LedgerSMB: Open source Accounting/ERP
like xosview and xkbevd?
Rudd-O - http://rudd-o.com/
This is BULLSHIT. X locally uses shared memory, not "network transparency". And even through network displays, it's pretty speedy. The main issue has always been a single-thread architecture for event processing, and poorly-accelerated display drivers.
Rudd-O - http://rudd-o.com/
This is inaccurate. If you see windows wobble, then when you minimize those windows, compiz or kwin will maintain the rendered image in RAM, so when you unminimize it, it will first blit to the screen the saved rendered image while re-requesting a redraw from the app in parallel. Now, if you are using a noncompositing window manager, I agree with you -- the app needs to rerender its contents and that is what causes the problem.
Rudd-O - http://rudd-o.com/
The LAYER of code that you are talking about is one function call per operation. INCREDIBLY negligible. With MIT-SHM (shared memory IPC) windowing operations are almost like directly talking to the hardware. It's the HARDWARE DRIVERS that are the bottleneck.
Rudd-O - http://rudd-o.com/
1. multicore
2. smoother input processing
3. smoother screen redraws
Rudd-O - http://rudd-o.com/
And you know this how, exactly? Have you made experiments which show that multithreading would actually improve this, or have some other real information? In that case, I am absolutely sure the Xorg developers would love to heard from you and our data (and your code, of course!). If, on the other hand, you are saying this because you somehow believe that adding multithreading automagically makes things better, then you are not answering my question.
Take for example your third point... In what way, exactly, does multithreading help with that, in a context when you have a compositing manager, mediumly sane toolkits, and apps mediumly sanely written so as not to block the gui?
Contrary to the popular belief, there indeed is no God.
"Start your own rewrite" is excellent response to a criticism like "X is old and boring, we need something sexy and new".
Because there isn't a viable rewrite yet (if it was needed, I'm sure that X developers would already be working on it).
No, "deprecated" means that API has to stay there because of compatibility with old programs, but new programms should use new API's (like Cairo or Qt's Arthur, XRender etc.) which solve problems you outlined (antialiasing, printer-compatible rendering model, possibly even color calibration).
Simply, there is nothing we can do about old programs that use flawed API's except to wait until they are forgotten or ported to new API (or do that job ourselves).
Xcb - it was meant to fix various Xlib problems (e.g. some latency issues), not to change/replace X protocol. Both are actually helper libs intended to stuff in code commonly used for handling the protocol (so that it's reused instead of being rewritten in each client app).
Compositing *still* clashes with Xv and everything else. In fact devs have been working to fix that for a year or two. Video memory manager in kernel and new DRI drivers ported to it, new direct rendering interface etc. So you will finally have direct rendering working nice with compositing. Since overlays aren't possible to integrate with 3D engines, Xv will be emulated using texturing (currently this approach suffers from same problem as direct GL rendering).
Xinerama stuff with all above - I think it also needs new memory manager stuff to be solvable, plus it could benefit from multi-GPU support which is on the TODO list of xorg people (this basically needs VGA arbiter code, but some guys started working on it), then the randr 1.3 should integrate all of Xinerama's features. But even now, the existing randr 1.2 is good if you are satisfied with only one framebuffer.
The point here is that protocol isn't the problem. Extensions can solve problems with it and apps will start using them if old approach is deprecated. The implementation of X server is. Yes, it's still a huge mess. But that is actually possible to solve withouth abandoning and starting from scratch (and in the new project you still have to provide same compatibility layer, anyway).
In Ubuntu, all you have to do is go into the monitor configuration tool and tell it you plugged in a second monitor. It makes you log out and back in, but it does not make you reboot, power off, or any of that stuff. If you want mirroring, the button on your laptop's keyboard should do the trick. It's easier than Windows, but still a bit more work than OSX.
That said, some funky stuff can happen if you have a less popular laptop. Laptop graphics are still fairly poorly supported. This is true in windows too though, where you're dependent on the manufacturer's display driver which never gets updated unless you're using a major brand (more major than Acer, or Sony).
In this case, yes. If you'd done *any* research on the issues you proclaim to have great knowledge about rather than just spouting out your ass, you'd know who they are.
Wow. When did I claim to have great knowledge?
All I did was share my (subjective of course) experiences.
Truth arises more readily from error than from confusion. -Francis Bacon
http://slashdot.org/comments.pl?sid=452556&threshold=1&commentsort=0&mode=thread&cid=22410610
That says that X is not speedy, compares it to Windows XP and speculates on why that is the case. That speculation may have been written as if it's a proven fact, but that's /. standard.
What part says "behold my great knowledge I have chosen to share, feel honored"?
Besides the point, but why couldn't I have detailled knowledge about some software and its shortcomings without knowing about the people involved?
Truth arises more readily from error than from confusion. -Francis Bacon
Would you trust a analysis of Hamlet or King Lear if the author had no idea who Will Shakespeare was?
Will who?
But seriously, I wouldn't dismiss this kind of analysis based on that fact alone.
Truth arises more readily from error than from confusion. -Francis Bacon
You don't install ANY OS on hardware without considering driver support.
MacOS is no different. Various forms of Windows are no different.
Linux and X are not alone in this.
That said, I've never gotten all the whining. I've put no more
effort into buying machines and vidcards that I would have done
to avoid a lemon under Windows. Yet I've managed to avoid problems.
Slackware 96 was not pretty but it wasn't painful in this regard at all. hmm that`s interesting