Follow Slashdot blog updates by subscribing to our blog RSS feed


Forgot your password?
Book Reviews Books Media

X Power Tools 219

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
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 Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
This discussion has been archived. No new comments can be posted.

X Power Tools

Comments Filter:
  • by Anpheus ( 908711 ) on Wednesday February 13, 2008 @03:48PM (#22410234)
    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-?
  • by pembo13 ( 770295 ) on Wednesday February 13, 2008 @04:01PM (#22410392) Homepage
    You mean X should be able to auto config itself and not rely on a set resolution in /etc/X1ll/xorg.conf? Kinda like how it does now?
  • by Enleth ( 947766 ) <> on Wednesday February 13, 2008 @04:06PM (#22410438) Homepage
    mv /etc/X11/xorg.conf /etc/X11/xorg.conf.bak

    And restart it. Seriously. Since about a year, the best way of running X on a PC is to let it autoconfigure itself without any configuration file, not even the one generated by some distro-supplied automatic configuration system.
  • by neumayr ( 819083 ) on Wednesday February 13, 2008 @04:20PM (#22410610)
    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.
  • by AKAImBatman ( 238306 ) <akaimbatman&gmail,com> on Wednesday February 13, 2008 @04:22PM (#22410626) Homepage Journal
    Actually, that's how Solaris already works. The graphics drivers are compiled into the kernel for workstation builds. The Xsun server just hooks into those drivers.

    From Alan Coopersmith [] of Sun Microsystems:

    Xsun though is only an Xserver, with no device specific knowledge - the
    drivers for various graphics devices for Xsun come from 3 other groups
    at Sun - SPARC Graphics, x86 Platform Drivers, and Sun Ray.
  • Wrong (Score:1, Informative)

    by Anonymous Coward on Wednesday February 13, 2008 @04:31PM (#22410774)
    > 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?

  • by misleb ( 129952 ) on Wednesday February 13, 2008 @04:35PM (#22410844)
    Really? I don't recall having much problem with XDMCP. Granted, I never had to do it large scale, but it was more or less just a matter of having one machine run XDM/GDM and then on "client" machines start X with an option that points it to the IP of the XDMCP "server." IIRC, there is even an XDMCP browser. The only thing is that some distributions (maybe most these days?) don't enable listening for TCP connections by default for security reasons. So you have to know where to enable that.

  • by ianezz ( 31449 ) on Wednesday February 13, 2008 @04:37PM (#22410862) Homepage

    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.

    Uh? Xorg (and XFree86 before) have been querying monitors characteristics via DDC for years. HorizSync and VertRefresh are just for really ancient monitors/graphic adapters. Look here [] if you don't believe me.

  • Re:Bad review (Score:2, Informative)

    by logru ( 909550 ) on Wednesday February 13, 2008 @04:40PM (#22410918) Homepage
    * What does it cover?
    * What are the chapters?
    * What detail does it go into?
    * Who is it aimed at?
      * Would a newbie find it useful or bewildering?
    * How expensive is it?
    * Is it easy to use as a reference or do you read it cover to cover?
    * What didn't you like about it?
    * Was there any bad information in there?
    * When you say it's more linux aimed, to what degree?

    Those are just some of the questions I can come up with from the top of my head...
  • by Anonymous Coward on Wednesday February 13, 2008 @04:42PM (#22410948)
    Yes, that works great if you plug in one display when you install and never change it.

    Now go to your nearest Mac, plug in a second display (while it's running), and watch what happens. Then go to your nearest Linux box, plug in a second display (also while it's already running), and watch what happens. Note that the Mac was using both displays about 4 seconds after you plugged it in, and the Linux box was not.
  • by msuarezalvarez ( 667058 ) on Wednesday February 13, 2008 @05:26PM (#22411592)

    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?

    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.

  • by ADRA ( 37398 ) on Wednesday February 13, 2008 @05:42PM (#22411796)
    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.
  • by krmt ( 91422 ) <therefrmhere@yahoo . c om> on Wednesday February 13, 2008 @06:10PM (#22412136) Homepage
    Jim is one of the original authors of X. Keith is essentially the de facto overlord of the current, 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
  • by serviscope_minor ( 664417 ) on Wednesday February 13, 2008 @08:38PM (#22413982) Journal
    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: [] [] [] 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.

  • by Enleth ( 947766 ) <> on Thursday February 14, 2008 @08:21AM (#22418564) Homepage
    I'm saying that a binary that is 20 years old and uses the X11 protocol as a client most likely will work with a modern Xorg server. It would probably be a problem to find an OS and libc able to run it while being modern enough to run X, but that wasn't the point. X connection itself should work just fine.

I've noticed several design suggestions in your code.