GUIdebook: Graphical User Interface galleryHome > Articles > “The X Attitude”
GUIsTimelinesScreenshotsIconsSoundsSplashesApplicationsAdsVideosArticlesBooksTutorialsExtras
Go backArticlesThe X attitude

Reprinted from Byte, issue 7/91, pp. 352.

I have a Unix workstation in my office, and I love it. It has a CPU that runs at 12 million instructions per second, 12 megabytes of RAM, a big swap disk, and 8 gigabytes of server space on the network. Of course, it runs the X Window System. But even with all this hardware, X Window is just “acceptable.”

I have a Mac SE next to my workstation. Even though the workstation trounces the Mac at number crunching (it’s 40 or 50 times faster), the two are neck and neck when it comes to windows and graphics. Ask both machines to draw 10,000 random line segments, and they finish about the same time.

What is going on here? Why would anyone design a system like X Window, such a pig when it comes to hardware resources? How did the designers get away with this? Why have people embraced the X Window environment?

X Window is successful for many reasons: It’s free, it’s portable, and it works. But more important, X Window is designed to offer some very nice capabilities, despite the fact that these capabilities require lots of hardware. I call this design philosophy “the X attitude,” and its central tenet is, “The hardware will catch up shortly.” This attitude has broad implications for software designers everywhere.

Everything about X Window is a pig. Its disk and RAM requirements are unbelievable. For example, if I want to build a little “hello world” program, I use the Motif widget set and write 10 lines of code. The executable file for this one little program consumes over a megabyte of disk space!

The network traffic generated by an X workstation is unbounded. X Window is network transparent, which means that I can run a simulation program on a supercomputer and get its graphical results displayed on my workstation. But X terminals can run a drawing program the same way. Every time I move the mouse 1 pixel while drawing a line, the terminal dumps a button motion event packet onto the network, and the computer at the other end has to send back commands to redraw the line – in real time.

You can see that X Window has tremendous hardware demands. What’s interesting is that in 1984, when X Window was conceived, no normal person had hardware that could handle these loads. The 128-KB Mac came out in early 1984, and the IBM AT later in the year. But the designers of X Window were in a completely different world. It’s as though they said to themselves, “Let’s not clutter our minds with the constraints of today’s hardware. The hardware will catch up with us in a few years.” With the X attitude, you simply ignore hardware limitations and let the design proceed uninhibited. In a world where hardware is advancing by leaps and bounds every year, this is the smart thing to do.

The primary advantage of the X attitude is this: It is incredibly freeing from a creativity standpoint. No longer are designs constrained by today’s realities.

It is educational to look for the X attitude (or its absence) in other products, like PostScript. It epitomizes the X attitude: It works, it is portable, and it is powerful. It is also a pig. It wants lots of MIPS and RAM, even though it was designed when these were expensive. It has been successful despite its prodigious appetite because of its amazing capabilities.

Then there’s OS/2. Its designers ignored the X attitude. They initially stuck with the old 16-bit 286 architecture instead of looking ahead to the future. The design was constrained and limited by this decision, and OS/2 has paid dearly for it. There is a lesson here.

What do you do if you are a software designer and you want to make use of the X attitude? Buy the biggest, fastest machine you can find. Load it to the gills with memory, give it a few gigabytes of highly cached disk space, and connect the fastest graphics coprocessor you can find. Sure it costs $50,000 now, but in three years it will be a small-footprint entry-level machine.

Now use this monster for a month. Write some good code, and watch it scream. Let your mind wander. What kind of software would you design for a machine like this? What are the possibilities that open up? Which nagging limitations fall by the wayside? Now you have the right attitude! Program toward the future, not for the past. The hardware vendors will love you.

Marshall Brain

Marshall Brain is a faculty member at North Carolina State University and is the author of An Introduction to Motif Programming (due from Digital Press in 1992). You can reach him on BIX c/o “editors.”

Stop Bit is a forum for informed opinion on personal computing topics. The opinions expressed are those of the author and not necessarily those of BYTE. Your contributions and comments are welcome. Write to: Editor, BYTE, One Phoenix Mill Lane, Peterborough, NH 03458.

Page added on 25th June 2005.

Copyright © 2002-2006 Marcin Wichary, unless stated otherwise.