Slashdot Mirror

X makes you do input-processing application-side, but that doesn't really introduce an inefficiency.

You are quite incorrect, sir.

The data rate of a mouse/keyboard even uncompressed never approaches more than 100 bytes/second. That's really not a bottleneck for the roles X is aimed at.

It's the round trip time, not the data rate, that causes the delay. Sluggish mouse tracking is very noticeable, and makes interactive applications impossible to use. Try running GIMP over a modem -- it's unusable!

The application also has to send graphics commands back down to the server in response to mouse motion, which you have neglected to account for in your bytes/second calculation.

So why not just download a graphics editor into the window server, so any other application can easily reuse it as a plug-in component? Then any trivial application (like the clock) could incorporate a fully functional graphics editor (so you could edit the graphics used for the face and hands). You could use a customizable clock over a slow network connection, because it would not have to send the same complex graphics commands each second to redraw the face and hands -- in fact the entire clock could run in the window system itself without requiring another process like XClock.

Am I crazy for suggesting incorporating a graphics editor into the window server, just for a silly clock? Well why not? It's been done before.

The HyperLook user interface system, which was based on NeWS, had a fully functional PostScript graphics editor component that ran in entirely within the NeWS server.

You could implement distributed objects with PostScript graphics that download data to the NeWS server, where it's locally rendered as scalable PostScript graphics, without generating any unnecessary network activity.

Ordinary users could use the graphics editor to create custom skins with structured PostScript graphics. With the built-in user interface editor, you could totally reconfigure the user interface while it was running.

HyperLook illustrates why I think it's important to be able to download code into the user interface and process input locally.

But nobody is trying to remote X over a cell-phone link. However, X is quite usable over a low-bandwidth link, given an appropriate compression technology.

You illustrate my point for me. You kids take free infinite bandwidth for granted these days, so I bring up cell phones to remind you that bandwidth is neither infinite nor free.

X is simply not useable over a low-bandwidth link such as a cell phone, compression technology or not. The ultimate compression technology is executable code, which is the basis of NeWS architectures.

If you can convince app developers to write their code in Javascript, than more power to you.

What year are you living, in 1994? Zillions of app developers write their code in JavaScript every day. I've written many JavaScript components and applications that incorporate them, and I love it. Fasteroids, Run-On-Sentence and Pie Menu Schema Editor are some simple examples, but it's easy to write much more complex desktop applications, and even entire desktop windowing interfaces, in JavaScript.

But that's where I was getting at with the Lisp comment. To be

X is modular.

George W Bush is a Compassionate Conservative.

Iraq has stockpiled of Weapons of Mass Destruction.

The British government has learned that Saddam Hussein recently sought significant quantities of uranium from Africa.

Nobody ever bothers to check the facts that Bush says in his State of the Union Address, so all emphatic misstatements of fact are purely accidental, and certainly not intended to mislead.

You're Unamerican for suggesting that Bush is a liar.

The Iran/Contra scandal wasn't about trading Arms for Hostages.

OJ Simpson didn't do it.

Got any more good ones for us?

-Don

Someone on slashdot asks, " Why is it still called X-Windows?".

Predictably, the first reply says: "It isn't. It's called 'The X Window System.' Or simply 'X'. 'X Windows' is a misnomer."

He didn't ask why it is "X-Windows". He asked why it's called "X-Windows". You're wrong that it isn't called "X-Windows". It is! It's just that it isn't "X-Windows". Being something is independent of being called something.

The answer to the question 'Why is it still called X-Windows?' is: It's still called X-Windows in order to annoy the X-Windows Fanatics, who take it upon themselves to correct you every time you call it X-Windows. That's why it's called X-Windows.

Things That Happen When You Say 'X Windows'

THE OFFICAL NAMES

The official names of the software described herein are:

X
X Window System
X Version 11
X Window System, Version 11
X11

Note that the phrases X.11, X-11, X Windows or any permutation thereof, are explicitly excluded from this list and should not be used to describe the X Window System (window system should be thought of as one word).

The above should be enough to scare anyone into using the proper terminology, but sadly enough, it's not. Recently, certain people, lacking sufficient motivation to change their speech patterns, have fallen victim to various 'accidents', or 'misfortune'. I've compiled a short list of happenings, some of which I have witnessed, others which remain heresay. I'm not claiming any direct connection between their speech habits and the reported incidents, but you be the judge... And woe betide any who set the cursed phrase into print!

You are forced to explain toolkit programming to X neophytes.

Bob Schiefler says, "You should know better than that!"

The Power Supply (and unknown boards) on your workstation mysteriously give up the ghost.

Ditto for the controller board for the disk on your new Sun.

Your hair falls out.

xmh refuses to come up in a useful size, no matter what you fiddle.

You inexplicitly lose both of your complete Ultrix Doc sets.

R2 won't build.

Bob Schiefler says "Type 'man X'".

Your nifty new X screen saver just won't go away.

The window you're working in loses input focus. Permanently

-Don

http://catalog.com/hopkins/images/pizzatool.gif (screen snapshot)
ftp://ftp.uu.net/graphics/NeWS/tnt/pizzatool (source code)
ftp://ftp.uu.net/graphics/NeWS/tnt/pizzatool.6 (manual)

-Don

You could have a standard format for describing menus (xml is the obvious choice now but wasn't around at the time), that applications could install on the desktop, that would be tracked and managed locally (by a separate menu manager or more likely merged into the window manager, to maintain a consistent look and feel).

It's slow, inefficient and wasteful of system resources for menus to track over the network. It would be much easier and more consistent if all menus were locally rendered and tracked quickly with the same look and feel, and the user could select which way they wanted all menus to be rendered. If you can change the window frames by changing window managers, why should't you be able to do the same thing with menus?

Changing the look an feel of all menus in the system was easy to do with the NeWS window system, because all the menus ran locally in the window server, and shared the same code. So it was simple to change all linear menus to pie menus, put tabs on all window frames, or anything else.

If nobody's fixed this problem with X in 16 years, there must be a reason.

To quote The X-Windows Disaster: Ultimately, NeWS was not economically or politically viable because it solved the very problems that X was designed to create.

-Don

From: Don Hopkins (don@BRILLIG.UMD.EDU)
Subject: Window Managers and Client Menus
Newsgroups: comp.windows.x
Date: 1989-09-19 09:08:21 PST

I think it's a pretty good idea to have the window manager, or some other process running close to the server, handle all the menus. Window managment and menu managment are separate functions, but it would be a real performance win for the window and the menu manager to reside in the same process. There should be options to deactivate either type of managment, so you could run, say, a motif window manager, and an open look menu manager at the same time. But I think that in most cases you'd want the uniform user interface, and the better performance, that you'd get by having both in one process.

I think it would be possible to implement something like this with the NDE window manager in X11/NeWS. It's written in object oriented PostScript, based on the tNt toolkit, and runs as a light weight processes inside the NeWS server. This way, selecting from a menu that invokes a window managment function only involves one process (the xnews server), instead of three (the x server and the two "outboard" managers), with all the associated overhead of paging, ipc, and context switching.

Here's a message on a related subject that I sent to xpert a couple years back (before I'd heard of the ICCCM). I never did get much response, except that one person pointed out that that was precisely the problem that NeWS was designed to solve. ;-)

c(-; Once were done forging the menu manager standard, how about we do text editors, huh?)

-Don

Date: Mon, 23 Feb 87 18:31:00 EST
From: Don Hopkins <brillig.umd.edu!don@harvard>
To: xpert@athena.mit.edu
Subject: Uwm extensions, perhaps?

Date: 23 Feb 87 19:44:43 GMT

From: cartan!weyl.Berkeley.EDUrusty@ucbvax.berkeley.edu (Rusty Wright)

Marvin Solomon) writes: What's the solution? I think it is to get rid of the idea of window manager as a separate process, and build "window-manager" functions into all windows.

That scares me. Wouldn't we then have the problem that suntools has where the suntool binaries are huge? On my sun 3/50 the suntools program itself is 728 blocks and the various other tools that run under suntools are 952 blocks. Yuck.

How about setting up some sort of standard? For example, all window

The only way I could see Y going much of anywhere is if it allowed you to run X apps too.

There is absolutely no need for a new window system to be backwards compatible with X in any way at all. Just run an X server in a window. Seal it off into its own minor sub-process, and don't let it pollute the design of another window system.

There are just too many damn X apps out there.

-Don

Well, searching for "windows sucks" on MSN there were some proper anti-ms sites, but one I found funny was...

this

An interesting article about how x-windows sucks. I'd love to see that article up here as a slashdot article just to see the bizarre comments it'd garner.

From: francis@ircam.fr (Joseph Francis)

I would like to propose that all GUI designers eschew anything actually resembling visible display of an interface, and simply ship a library, and a loose 'conceptual' discussion of what effects the display should provoke, according to a psychological or astrological model of the user's personality (Jungian, Freudian, or Dosteyevskian), their latitutude and longitude, and blood sugar levels. It should be completely up to the user to specify a display (I believe POSEUR is addressing the shipment of design-free GUI design for user-transparent configuration: open, scalable, and extensible, the problem is almost PN complete). Sample KIT (using a paradigm of an application which extracts semantic nets from French Literature in Translation):

1. Parameters: none
2. Two thick libraries, with enforced single-entry SlowRead(). and a single NoExit() for enforced modularity.
3. Copy of More's /Utopia/, and a well-fingered /Neuromancer/
4. One copy of Italian Vogue Summer collection '82
5. Default Interface Processor (DIP) to generate a user-configurable default interface upon which one can generate proposed target 'research' examples.
6. One copy of USA Today and Time (tm) magazine to be used for sample non-default graphical layout guidelines.
+ XYmorph (tm): a new easy-to-use open extensible and scalable system for randomly per/mutating user interfaces. A manifestation of the concept of both stimulated healling and scatter-brain i/o in order to most quickly reach suboptimal interface design with the least amount of effort on the part of the designer or the user.
+ Quagmire: a CD-rom collection of over 4 quadrillion possible interfaces generated for a Unix(tm) open, extensible, and scalable graphical C-shell-feel-good-alike system. Meets ANSI, K&R, A&P, S&H
+ and other stamped standards in continental US.
+ boraX: a user-configurable interface cleanser. Open, extensible, and scalable, it removes all traces of design constraint from simple structured systems and creates flat-design mazelike idio(syncratic/pathic/syncretic) systems of fresh and clean code.

Sample concept discussion:

The pointer (I hesitate to use such a loaded word: for users who object to object orientation and simplistic Western-philosophy views of dichotomatic (not diatomaceous or deciduous, though wooden feelings might be appropriate for Environmentally friendly X displays) subject/object distinctions might prefer to discuss 'object compliment', or even 'compliment' (as in Complimentary beverage or Complimentary sugar-coated dry-roasted 100% genuine Virgina grown goober peas just the way they grew them in olden times) in order to provoke an awareness and create a more extensible scalable and transparent user environment for those who aren't really worried about domain/range distinctions in disjunctive noun mappings) should respond to a click (which is to say a simple tap, of varying duration depending upon the physical capabilities and inclinations of those who might be inclined to acutally depress the open, extensible, and scalable button on a mouse (though those of us who object to laboratory research mechanomorphization of living entities prefer to call 'mice' 'clickers', thus preserving the dignity of what we all must recognize is part of a larger Gaiaen web of life (which is, I must remark, open, scalable, and extensible, life that is, not the mouse) and metonymically convolving form and function into the open, scalable and extensible nomenclature of X).

XBorges.

One longs for the day when the responsibility of programming computers falls squarely on the shoulders of the users, where it belongs; they are provided with a set of infinitely configurable instruction codes, on an open, extensible, and scalable n-bit bus, and their task before setting upo

Myth: X Demonstrates the Power of Client/Server Computing

At the mere mention of network window systems, certain propeller heads who confuse technology with economics will start foaming at the mouth about their client/server models and how in the future palmtops will just run the X server and let the other half of the program run on some Cray down the street. They've become unwitting pawns in the hardware manufacturers' conspiracy to sell newer systems each year. After all, what better way is there to force users to upgrade their hardware than to give them X, where a single application can bog down the client, the server, and the network between them, simultaneously!

The database client/server model (the server machine stores all the data, and the clients beseech it for data) makes sense. The computation client/server model (where the server is a very expensive or experimental supercomputer, and the client is a desktop workstation or portable computer) makes sense. But a graphical client/server model that slies the interface down some arbitrary middle is like Solomon following through with his child-sharing strategy. The legs, heart, and left eye end up on the server, the arms and lungs go to the client, the head is left rolling around on the floor, and blood spurts everywhere.

The fundamental problem with X's notion of client/server is that the proper division of labor between the client and the server can only be decided on an application-by-application basis. Some applications (like a flight simulator) require that all mouse movement be sent to the application. Others need only mouse clicks. Still others need a sophisticated combination of the two, depending on the program's state or the region of the screen where the mouse happens to be. Some programs need to update meters or widgets on the screen every second. Other programs just want to display clocks; the server could just as well do the updating, provided that there was some way to tell it to do so.

The right graphical client/server model is to have an extensible server. Application programs on remote machines can download their own special extension on demand and share libraries in the server. Downloaded code can draw windows, track input events, provide fast interactive feedback, and minimize network traffic by communicating with the application using a dynamic, high-level protocol.

As an example, imagine a CAD application built on top of such an extensible server. The application could download a program to draw an IC and associate it with a name. From then on, the client could draw the IC anywhere on the screen simply by sending the name and a pair of coordinates. Better yet, the client an download programs and data structures to draw the whole schematic, which are called automatically to refresh and scroll the window, without bothering the client. The user can drag an IC around smoothly, without any network traffic or context switching, and the server sends a single message to the client when the interaction is complete. This makes it possible to run interactive clients over low-speed (that is, slow-bandwidth) communication lines.

Sounds like science fiction? An extensible window server was precisely the strategy taken by the NeWS (Network extensible Window System) window system written by James Gosling at Sun. With such an extensible system, the user interface toolkit becomes an extensible server library of classes that clients download directly into the server (the approach taken by Sun's TNT Toolkit and Arthur van Hoff's HyperLook gui environment). Toolkit objects in different applications share common objects in the server, saving both time and memory, and creating a look-and-feel that

Myth: X Demonstrates the Power of Client/Server Computing

At the mere mention of network window systems, certain propeller heads who confuse technology with economics will start foaming at the mouth about their client/server models and how in the future palmtops will just run the X server and let the other half of the program run on some Cray down the street. They've become unwitting pawns in the hardware manufacturers' conspiracy to sell newer systems each year. After all, what better way is there to force users to upgrade their hardware than to give them X, where a single application can bog down the client, the server, and the network between them, simultaneously!

The database client/server model (the server machine stores all the data, and the clients beseech it for data) makes sense. The computation client/server model (where the server is a very expensive or experimental supercomputer, and the client is a desktop workstation or portable computer) makes sense. But a graphical client/server model that slies the interface down some arbitrary middle is like Solomon following through with his child-sharing strategy. The legs, heart, and left eye end up on the server, the arms and lungs go to the client, the head is left rolling around on the floor, and blood spurts everywhere.

The fundamental problem with X's notion of client/server is that the proper division of labor between the client and the server can only be decided on an application-by-application basis. Some applications (like a flight simulator) require that all mouse movement be sent to the application. Others need only mouse clicks. Still others need a sophisticated combination of the two, depending on the program's state or the region of the screen where the mouse happens to be. Some programs need to update meters or widgets on the screen every second. Other programs just want to display clocks; the server could just as well do the updating, provided that there was some way to tell it to do so.

The right graphical client/server model is to have an extensible server. Application programs on remote machines can download their own special extension on demand and share libraries in the server. Downloaded code can draw windows, track input events, provide fast interactive feedback, and minimize network traffic by communicating with the application using a dynamic, high-level protocol.

As an example, imagine a CAD application built on top of such an extensible server. The application could download a program to draw an IC and associate it with a name. From then on, the client could draw the IC anywhere on the screen simply by sending the name and a pair of coordinates. Better yet, the client an download programs and data structures to draw the whole schematic, which are called automatically to refresh and scroll the window, without bothering the client. The user can drag an IC around smoothly, without any network traffic or context switching, and the server sends a single message to the client when the interaction is complete. This makes it possible to run interactive clients over low-speed (that is, slow-bandwidth) communication lines.

Sounds like science fiction? An extensible window server was precisely the strategy taken by the NeWS (Network extensible Window System) window system written by James Gosling at Sun. With such an extensible system, the user interface toolkit becomes an extensible server library of classes that clients download directly into the server (the approach taken by Sun's TNT Toolkit and Arthur van Hoff's HyperLook gui environment). Toolkit objects in different applications share common objects in the server, saving both time and memory, and creating a look-and-feel that

Myth: X Demonstrates the Power of Client/Server Computing

At the mere mention of network window systems, certain propeller heads who confuse technology with economics will start foaming at the mouth about their client/server models and how in the future palmtops will just run the X server and let the other half of the program run on some Cray down the street. They've become unwitting pawns in the hardware manufacturers' conspiracy to sell newer systems each year. After all, what better way is there to force users to upgrade their hardware than to give them X, where a single application can bog down the client, the server, and the network between them, simultaneously!

The database client/server model (the server machine stores all the data, and the clients beseech it for data) makes sense. The computation client/server model (where the server is a very expensive or experimental supercomputer, and the client is a desktop workstation or portable computer) makes sense. But a graphical client/server model that slies the interface down some arbitrary middle is like Solomon following through with his child-sharing strategy. The legs, heart, and left eye end up on the server, the arms and lungs go to the client, the head is left rolling around on the floor, and blood spurts everywhere.

The fundamental problem with X's notion of client/server is that the proper division of labor between the client and the server can only be decided on an application-by-application basis. Some applications (like a flight simulator) require that all mouse movement be sent to the application. Others need only mouse clicks. Still others need a sophisticated combination of the two, depending on the program's state or the region of the screen where the mouse happens to be. Some programs need to update meters or widgets on the screen every second. Other programs just want to display clocks; the server could just as well do the updating, provided that there was some way to tell it to do so.

The right graphical client/server model is to have an extensible server. Application programs on remote machines can download their own special extension on demand and share libraries in the server. Downloaded code can draw windows, track input events, provide fast interactive feedback, and minimize network traffic by communicating with the application using a dynamic, high-level protocol.

As an example, imagine a CAD application built on top of such an extensible server. The application could download a program to draw an IC and associate it with a name. From then on, the client could draw the IC anywhere on the screen simply by sending the name and a pair of coordinates. Better yet, the client an download programs and data structures to draw the whole schematic, which are called automatically to refresh and scroll the window, without bothering the client. The user can drag an IC around smoothly, without any network traffic or context switching, and the server sends a single message to the client when the interaction is complete. This makes it possible to run interactive clients over low-speed (that is, slow-bandwidth) communication lines.

Sounds like science fiction? An extensible window server was precisely the strategy taken by the NeWS (Network extensible Window System) window system written by James Gosling at Sun. With such an extensible system, the user interface toolkit becomes an extensible server library of classes that clients download directly into the server (the approach taken by Sun's TNT Toolkit and Arthur van Hoff's HyperLook gui environment). Toolkit objects in different applications share common objects in the server, saving both time and memory, and creating a look-and-feel that

Myth: X Demonstrates the Power of Client/Server Computing

At the mere mention of network window systems, certain propeller heads who confuse technology with economics will start foaming at the mouth about their client/server models and how in the future palmtops will just run the X server and let the other half of the program run on some Cray down the street. They've become unwitting pawns in the hardware manufacturers' conspiracy to sell newer systems each year. After all, what better way is there to force users to upgrade their hardware than to give them X, where a single application can bog down the client, the server, and the network between them, simultaneously!

The database client/server model (the server machine stores all the data, and the clients beseech it for data) makes sense. The computation client/server model (where the server is a very expensive or experimental supercomputer, and the client is a desktop workstation or portable computer) makes sense. But a graphical client/server model that slies the interface down some arbitrary middle is like Solomon following through with his child-sharing strategy. The legs, heart, and left eye end up on the server, the arms and lungs go to the client, the head is left rolling around on the floor, and blood spurts everywhere.

The fundamental problem with X's notion of client/server is that the proper division of labor between the client and the server can only be decided on an application-by-application basis. Some applications (like a flight simulator) require that all mouse movement be sent to the application. Others need only mouse clicks. Still others need a sophisticated combination of the two, depending on the program's state or the region of the screen where the mouse happens to be. Some programs need to update meters or widgets on the screen every second. Other programs just want to display clocks; the server could just as well do the updating, provided that there was some way to tell it to do so.

The right graphical client/server model is to have an extensible server. Application programs on remote machines can download their own special extension on demand and share libraries in the server. Downloaded code can draw windows, track input events, provide fast interactive feedback, and minimize network traffic by communicating with the application using a dynamic, high-level protocol.

As an example, imagine a CAD application built on top of such an extensible server. The application could download a program to draw an IC and associate it with a name. From then on, the client could draw the IC anywhere on the screen simply by sending the name and a pair of coordinates. Better yet, the client an download programs and data structures to draw the whole schematic, which are called automatically to refresh and scroll the window, without bothering the client. The user can drag an IC around smoothly, without any network traffic or context switching, and the server sends a single message to the client when the interaction is complete. This makes it possible to run interactive clients over low-speed (that is, slow-bandwidth) communication lines.

Sounds like science fiction? An extensible window server was precisely the strategy taken by the NeWS (Network extensible Window System) window system written by James Gosling at Sun. With such an extensible system, the user interface toolkit becomes an extensible server library of classes that clients download directly into the server (the approach taken by Sun's TNT Toolkit and Arthur van Hoff's HyperLook gui environment). Toolkit objects in different applications share common objects in the server, saving both time and memory, and creating a look-and-feel that

Myth: X is Device Independent

X is extremely device dependent because all X graphics are specified in piel coordinates. graphics drawn on different resulution screens come out at different sizes, so you have to scale all the coordinates yourself if you want to draw at a certain size. Not all screens have square pixels: unless you don't mind rectangular squares and oval circles, you also have to adjust all coordinates according to the pixel aspect ratio.

A task as simple as filing and stroking shapes is quite complicated because of X's bizarre pixel-oriented imaging rules. When you fill a 10x10 square with XFillRectangle, it fills the 100 pixels you expect. But you get extra bonus pixels when you pass the same arguments to XDrawRectangle, because it actually draws an 11x11 square, hanging out one pixel below and to the right!!! If you find this hard to believe, look it up in the X manual yourself: Volume 1, Section 6.1.4. The manual patronizingly explains how easy it is to add 1 to the x and y position of the filled rectangle, while subtracting 1 from the width and height to compensate, so it fits neatly inside the outline. Then it points out that in the case of arcs, however, this is a much more difficult proposition (probably impossible in a portable fashion). This means that portably filling and stroking an arbitrarily scaled arc without overlapping or leaving gaps is an intractable problem when using the X Window System. Think about that. You can't even draw a proper rectangle with a thick outline, since the line width is specified in unscaled pixel units, so if your display has rectangular pixels, the vertical and horizontal lines will have different thicknesses enen though you scaled the rectangle corner coordinates to compensate for the aspect ratio.

The color situation is a total flying circus. The X approach to device independence is to treat everything like a MicroVAX framebuffer on acid. A truly portable X application is required to act like the persistent customer in Monty Python's Cheese Shop sketch, or a grail seeker in Monty Python and the Holy Grail. Even the simplest applications must answer many difficult questions:

WHAT IS YOUR DISPLAY?
display = XOpenDisplay(unix:0);
WHAT IS YOUR ROOT?
root = RootWindow(display, DefaultScreen(display));
AND WHAT IS YOUR WINDOW?
win = XCreateSimpleWindow(display, root, 0, 0, 256, 256, 1, BlackPixel(display, DefaultScreen(display)), WhitePixel(display, DefaultScreen(display)));
OH ALL RIGHT, YOU CAN GO ON.

WHAT IS YOUR DISPLAY?
display = XOpenDisplay(unix:0);
WHAT IS YOUR COLORMAP?
cmap = DefaultColormap(display, DefaultScreen(display));
AND WHAT IS YOUR FAVORITE COLOR?
favorite_color = 0; /* Black. */
/* Whoops! No, I mean: */
favorite_color = BlackPixel(display, DefaultScreen(display));
/* AAAYYYYEEEEE!! */
(client dumps core & falls into the chasm)

WHAT IS YOUR DISPLAY?
display = XOpenDisplay(unix:0);
WHAT IS YOUR VISUAL?
struct XVisualInfo vinfo;
if (XMatchVisualInfo(display, DefaultScreen(display), 8, PseudoColor, &vinfo) != 0) visual = vinfo.visual;
AND WHAT IS THE NET SPEED VELOCITY OF AN XConfigureWindow REQUEST?
/* Is that a SubStructureRedirectMask or a ResizeRedirectMask? */
WHAT??! HOW AM I SUPPOSED TO KNOW THAT?
AAAAUUUGGGHHH!!!!
(server dumps core & falls into the chasm)

-Don Hopkins

On the whole, X extensions are a failure. The notable exception that proves the rule is the Shaped Window extension, which was specifically designed to implement round clocks and eyeballs. But most application writers just don't bother using proprietarty extensions like Display PostScript, because X terminals and MIT servers don't support them. Many find it too much of a hassle to use more ubiquitous extensions like shared memory, double buffering, or splines: they still don't work in many cases, so you have to be prepared to do without them. If you really don't need the extension, then why complicate your code with the special cases? And most applications that do use extensions just assume they're supported and bomb if they're not.

The most that can be said about the lowest-common-denominator approach that X takes to graphics is that it levels the playing field, allowing incredibly stupid companies to jump on the bandwagon and sell obsolete junk that's just as unusable as high-end brand-name workstations.

-Don

-Don

From the X-Windows Disaster:

How to make a 50-MIPS Workstation Run Like a 4.77MHz IBM PC

If the designers of X-Windows built cars, there would be no fewer than five steering wheels hidden about the cockpit, none of which followed the same principles -- but you'd be able to shift gears with your car stereo. Useful feature, that.
- Marus J. Ranum, Digital Equipment Corporation

X has had its share of $5,000 toilet seats -- like Sun's Open Look clock tool, which gobbles up 1.4 megabytes of real memory! If you sacrificed all the RAM from 22 Commodore 64s to clock tool, it still wouldn't have enough to tell you the time. Even the vanilla X11R4 "xclock" utility consumed 656K to run. And X's memory usage is increasing.

-Don Hopkins

I see that you are a fan of Bastiat.
-russ

INSTRUCTIONS FOR THE USE OF THE "&ArtistFormerlyKnownAsPrince;" SYMBOL

-Don

-Don

-Don

PS: To annoy X fanatics, Don specifically asked that we include the hyphen after the letter "X,", as well as the plural of the word "Windows," in his chapter title.

Here's a picture of MIT-MC, including the Decwriter console and a VT52. I think the box to the right of the VT52 is the 10/11 interface.

http://catalog.com/hopkins/images/mc-console.jpg

The only pictures I have of rms's house (which burnt down), are of Devon climbing up a tree to the roof:

http://catalog.com/hopkins/images/devon-climbing.j pg
http://catalog.com/hopkins/images/devon-landing.jp g

And of course, here's a picture of RMS asking, "I don't know, why do you wrap a gerbil in duct tape?":

http://catalog.com/hopkins/images/jsol-rms-gerbil- liz-mg.jpg

On the left is JSOL, and the two people on the right are Liz and MG (who RMS branded an "Evil Software Hoarder" for developing Gosling's Emacs at UniPress.)

RMS is quick on his feet, and can be hillariously funny, unless you make the mistake of being offended. MG ran into RMS at a science fiction convention, and asked him "I heard there was a rumor about you house burning down." RMS snapped back "That's true, but where you work, I think you would have heard about it in advance."

-Don

Here's a picture of MIT-MC, including the Decwriter console and a VT52. I think the box to the right of the VT52 is the 10/11 interface.

http://catalog.com/hopkins/images/mc-console.jpg

The only pictures I have of rms's house (which burnt down), are of Devon climbing up a tree to the roof:

http://catalog.com/hopkins/images/devon-climbing.j pg
http://catalog.com/hopkins/images/devon-landing.jp g

And of course, here's a picture of RMS asking, "I don't know, why do you wrap a gerbil in duct tape?":

http://catalog.com/hopkins/images/jsol-rms-gerbil- liz-mg.jpg

On the left is JSOL, and the two people on the right are Liz and MG (who RMS branded an "Evil Software Hoarder" for developing Gosling's Emacs at UniPress.)

RMS is quick on his feet, and can be hillariously funny, unless you make the mistake of being offended. MG ran into RMS at a science fiction convention, and asked him "I heard there was a rumor about you house burning down." RMS snapped back "That's true, but where you work, I think you would have heard about it in advance."

-Don

Here's a picture of MIT-MC, including the Decwriter console and a VT52. I think the box to the right of the VT52 is the 10/11 interface.

http://catalog.com/hopkins/images/mc-console.jpg

The only pictures I have of rms's house (which burnt down), are of Devon climbing up a tree to the roof:

http://catalog.com/hopkins/images/devon-climbing.j pg
http://catalog.com/hopkins/images/devon-landing.jp g

And of course, here's a picture of RMS asking, "I don't know, why do you wrap a gerbil in duct tape?":

http://catalog.com/hopkins/images/jsol-rms-gerbil- liz-mg.jpg

On the left is JSOL, and the two people on the right are Liz and MG (who RMS branded an "Evil Software Hoarder" for developing Gosling's Emacs at UniPress.)

RMS is quick on his feet, and can be hillariously funny, unless you make the mistake of being offended. MG ran into RMS at a science fiction convention, and asked him "I heard there was a rumor about you house burning down." RMS snapped back "That's true, but where you work, I think you would have heard about it in advance."

-Don

Here's a picture of MIT-MC, including the Decwriter console and a VT52. I think the box to the right of the VT52 is the 10/11 interface.

http://catalog.com/hopkins/images/mc-console.jpg

The only pictures I have of rms's house (which burnt down), are of Devon climbing up a tree to the roof:

http://catalog.com/hopkins/images/devon-climbing.j pg
http://catalog.com/hopkins/images/devon-landing.jp g

And of course, here's a picture of RMS asking, "I don't know, why do you wrap a gerbil in duct tape?":

http://catalog.com/hopkins/images/jsol-rms-gerbil- liz-mg.jpg

On the left is JSOL, and the two people on the right are Liz and MG (who RMS branded an "Evil Software Hoarder" for developing Gosling's Emacs at UniPress.)

RMS is quick on his feet, and can be hillariously funny, unless you make the mistake of being offended. MG ran into RMS at a science fiction convention, and asked him "I heard there was a rumor about you house burning down." RMS snapped back "That's true, but where you work, I think you would have heard about it in advance."

-Don

There's a partial web copy at:

Unix Haters (hint: click on the login cursor)

It's quite dated (Unix 10 years ago, did suck fairly badly in some ways, although not as badly as Windows 95!), and getting exponentially more so. The book was actually fairly humorous, it loses a lot in its translation to the web. The book is well out of print in both senses of the word 'well'.

The argument of "what's out there isn't good enough" doesn't fly either. You have the source to fix it and make it better!

Quick show of hands please: How many people have tried to "fix" the X Window System?

Many people feel that X11 is a bloated, unmaintainable hack. It is absolutely full of cruft.

My hope is that this effort gains enough of a foothold that it attracts developers that can put a WINE-like layer on it to translate KDE or QT calls. Then, as people migrate from lower-level toolkit libraries (Athena Widgets, TCL/TK, etc.) to higher-level libraries, it becomes simple to port their apps to an O/S like Syllable that doesn't have all the cruft that comes with an underlying X11 layer. Now, I realize that's a bit far fetched, but it is a step in what I feel is the right direction.

Yes, it is extra work to develop a new O/S, but the GNU/Linux crowd is inextricably tied to X11. If it takes a new O/S to see the benefits of a simpler graphical subsystem, then I say its worth it. DirectFB could be the answer for Linux, but doesn't get the attention or support I feel it should. (Hey, Trolltech, how about a QT port?) For those of you with your favorite X11 apps that don't have a port yet, DirectFB even has a rootless X-server.

FWIW, I use X11, but I don't program with it. Everyone I know of that does program with it complains about it. They say its bloated, difficult to program at the lower levels, and generally complain about its cruftiness. Use of higher level libraries are making these types more and more scarce, which I think is a good thing.

http://catalog.com/hopkins/text/head.html

Mars exploration is a thought, at least it's dramatic enough that it might grab people's attention. I submit that we would be better off pursuing a goal in space with some obvious practical benefit, e.g. this scheme of Robert Kennedy of the Ultimax Group:

Mirrors & Smoke: Ameliorating Climate Change with Giant Solar Sails;

Topic: Mirrors & Smoke, and Other Shady Schemes

390,000 sq.km of solar sails, placed in non-Keplerian orbits around the Sun-Earth L1 Lagrange point, can intercept enough (~0.25%) sunlight to offset global warming and concomitant rapid climate change due to anthropogenic CO2, or if you will, a mirrored Maunder Minimum. Such mirrors can also provide total planetary electricity demand, estimated at 300 quads (quadrillion BTUs) by 2050, displacing all terrestrial carbon-burners.

Bright Future for Solar Power Satellites

"Consider whether chewing on glass might have more of a payoff than what you're about to go through."

- Jamie Zawinski, quoted in The X-Windows Disaster

One of the most widespread contemporary uses of Forth is the Open Firmware boot ROMs used in Suns, Macs and even Linux. It's even defined by IEEE standard 1275-1994.

It was based on Langston and Perry's Forth83, and developed by Mitch Bradley at Sun, who is a major Forth guru and hardware guy. When you hit L1-A on a Sun, it dumps you into the Forth boot monitor, which let you do all kinds of things to the hardware and nvram configuration.

The point to having a cross platform bytecode dialect of Forth in firmware, is so hardware devices can have drivers, diagnostics and configuration interfaces in ROM that will execute on any system, no matter what the processor. That was implemented long before Java was ever invented.

-Don

"I'd like you to point out a large retailer that uses php for its online store, or an online banking site."

I am not sure where you are getting at with this. If you mean it's not possible to build a large, complex and busy site using php you need to look no further then sourceforge. Now sourceforge is not a commercial site but I bet it gets more use then 99% of the commercial sites on the net.

I don't know why it's so special to have a commercial site in php but I know of several. Here are just a few companies that I have dealt with which use php on their web sites.

Nonetheless if you insist on an example of a large online store using php look at
Insight.com or catalog.com

Have you read this? Your satire seems inspired by postmodern literary critique. It also has the elements of a good BS "paper," and I'm guessing you picked this up at Columbia. This style is a large part of what got me through the common core courses.

The essential paradigm of cyberspace is creating partially situated identities out of actual or potential social reality in terms of canonical forms of human contact, thus renormalizing the phenomenology of narrative space and requiring the naturalization of the intersubjective cognitive strategy, and thereby resolving the dialectics of metaphorical thoughts, each problematic to the other, collectively redefining and reifying the paradigm of the parable of the model of the metaphor.

The source of the above paragraph should serve as an adequate introduction to postmodernism.

The challenge then is designing a pie menu component that doesn't suck, when you throw any old menu at it, without somebody redesigning each menu to work well as a pie.

One possible solution is user-editable menus, like Alias Maya supports. As far as I know, the NeXT and OS/X systems don't support allowing users to edit the user interface and menus at run-time, like HyperCard does for example.

For NeWS, I implemented a "SoftMenu" editable subclass of pie menus (that also could mix into linear menus), that enabled the user to edit, cut and paste menu items. But it was quite dangerous because you could really confuse things by pasting emacs commands into the terminal emulator, etc.

The HyperLook gui environment for NeWS supported fully editable user interfaces with pie menus at run-time, like HyperCard but with PostScript graphics and scripting, and a client/server architecture.

I used HyperLook to port SimCity to Unix, which used pie menus of course. Here's a deconstructionist screen snapshot of the SimCity user interface vandalized in edit mode.

Another possible solution is "smart" pie menu layout algorithms, user interface editors and wizards that automatically encourage or assist good user interface design (to whatever extent that is possible without annoying the user).

For example, the ActiveX pie menus can automatically raise the number of items to be even, limit the number of active items to 8, support scrolling, and reading order layout as well as circular layout. And you can optionally enable or disable any of those features through the property sheet. But the downside is that the property sheet looks like a 747 control panel.

-Don

The challenge then is designing a pie menu component that doesn't suck, when you throw any old menu at it, without somebody redesigning each menu to work well as a pie.

One possible solution is user-editable menus, like Alias Maya supports. As far as I know, the NeXT and OS/X systems don't support allowing users to edit the user interface and menus at run-time, like HyperCard does for example.

For NeWS, I implemented a "SoftMenu" editable subclass of pie menus (that also could mix into linear menus), that enabled the user to edit, cut and paste menu items. But it was quite dangerous because you could really confuse things by pasting emacs commands into the terminal emulator, etc.

The HyperLook gui environment for NeWS supported fully editable user interfaces with pie menus at run-time, like HyperCard but with PostScript graphics and scripting, and a client/server architecture.

I used HyperLook to port SimCity to Unix, which used pie menus of course. Here's a deconstructionist screen snapshot of the SimCity user interface vandalized in edit mode.

Another possible solution is "smart" pie menu layout algorithms, user interface editors and wizards that automatically encourage or assist good user interface design (to whatever extent that is possible without annoying the user).

For example, the ActiveX pie menus can automatically raise the number of items to be even, limit the number of active items to 8, support scrolling, and reading order layout as well as circular layout. And you can optionally enable or disable any of those features through the property sheet. But the downside is that the property sheet looks like a 747 control panel.

-Don

The challenge then is designing a pie menu component that doesn't suck, when you throw any old menu at it, without somebody redesigning each menu to work well as a pie.

One possible solution is user-editable menus, like Alias Maya supports. As far as I know, the NeXT and OS/X systems don't support allowing users to edit the user interface and menus at run-time, like HyperCard does for example.

For NeWS, I implemented a "SoftMenu" editable subclass of pie menus (that also could mix into linear menus), that enabled the user to edit, cut and paste menu items. But it was quite dangerous because you could really confuse things by pasting emacs commands into the terminal emulator, etc.

The HyperLook gui environment for NeWS supported fully editable user interfaces with pie menus at run-time, like HyperCard but with PostScript graphics and scripting, and a client/server architecture.

I used HyperLook to port SimCity to Unix, which used pie menus of course. Here's a deconstructionist screen snapshot of the SimCity user interface vandalized in edit mode.

Another possible solution is "smart" pie menu layout algorithms, user interface editors and wizards that automatically encourage or assist good user interface design (to whatever extent that is possible without annoying the user).

For example, the ActiveX pie menus can automatically raise the number of items to be even, limit the number of active items to 8, support scrolling, and reading order layout as well as circular layout. And you can optionally enable or disable any of those features through the property sheet. But the downside is that the property sheet looks like a 747 control panel.

-Don

http://catalog.com/hopkins/images/pizzatool.gif

It was written entirely in NeWS PostScript, and shipped with OpenWindows 2.0 (but with the faxing option disabled).

Ironically enough pizzatool didn't use pie menus. (There were too darn many toppings to choose from, which wouldn't have worked well on a pie menu.)

-Don

As I understand it, the primary advantage of pie menus over standard linear/cascading menus is that they leverage muscle memory for enhanced speed and accuracy in menu selections. In essence, pie menus are not unlike a gestural control scheme with training wheels -- a series of selections from a cascading pie menu effectively forms a complete mouse-gesture, which can later be replicated without conscious reference to menu labels. This allows novice users to make selections cognitively by following menu selections, while more advanced users can simply remember the series of mouse movements required to reach a given selection.

More info here.

is here. It's a bit out of date though, perhaps some one could update it?

First, a little history. The X window system escaped from Project Athena at MIT where it was being held in isolation. When notified, MIT stated piblicly that "MIT assumes no resonsibility...". This is a very disturbing statement. It then infiltrated Digital Equipment Corporation, where it has since corrupted the technical judgement of this organization.

After sabotaging Digital Equipment Corporation, a sinister X consortium was created to find a way to use X as part of a plan to dominate and control interactive window systems. X windows is sometimes distributed by this secret consortium free of charge to unsuspecting victims. The destructive cost of X cannot even be guessed.

X is truly obese - whether it's mutilating your hard disk or actively infesting your system, you can be sure it's up to no good. Innocent users need to be protected from this dangerous virus. Even as you read this, the X source distribution and the executable environment is being maintained on hundreds of computers, maybe even your own.

Digital Equipment Corporation is already shipping machines that carry this dreaded infestation. It must be destroyed.

This is what happens when software with good intentions goes bad. It victimizes innocent users by distorting their perception of what is and what is not good software. This malignant window system must be destroyed.

Ultimately DEC and MIT must be held accountable for this heinous software crime, brought to justice, and made to pay for a software cleanup. Until DEC and MIT answer to these charges, they both should be assumed to be protecting dangerous software criminals.

Don't be fooled! Just say no to X.

I'm working on a robot project with the Stupid Fun Club, and we're going to build the Evolution laptop into a much bigger heavier duty robot body, to control it. [These people started the Robot Wars competition, but this particular robot is designed to be peaceful, even friendly and social.] The big friendly robot is still under construction, so I decided to assemble Evolution's cute smaller modular robot to see how it works.

It took an afternoon to put together the lego-like parts to build the Evolution robot kit. It included a bunch of aluminum beams, lots of ingenious modular plastic connectors, nuts and bolts, wheels and motors, bump and IR distance sensors, and some awesome ultra-heavy-duty velcro.

The IR distance sensors were somewhat tricky to attach, had flakey connectors, and don't all work; but everything else was quite straightforward and easy. I haven't had so much fun with legos in years!

We're using a laptop recommended and preconfigured by Evolution: an IBM Thinkpad type 2612-1bu. Most interesting is the software, which runs on Linux. Evolution has developed a "robotic operating system", which is written in C++ and configured with XML.

It has a visual behavior programming language for connecting together boxes (representing software behavior modules) with wires (representing data types of input and output parameters).

It's kind of like the "SimAntics" language used to program The Sims, but much simpler, more general purpose, and extensible.

The behavior modules are implemented in C++ and compiled into dynamically linked libraries or built into the application. There's a C++ SDK for programming your own behavior modules, with which I've just started experimenting.

XML schema files describe the module interfaces (name, description, library, symbol, parameters, input and output ports with data types, etc). They're not standard XML-Schema, just Evolution's own special purpose behavior schema format, which is appropriate for the task.

XML behavior files assemble a bunch of modules and connect them together into high level behavior networks, which you can use to build even higher level behavior networks in a modular fashion.

There's a visual programming tool implemented in Java that lets you graphically construct networks of behavior modules, or you can simply type them in as XML in a text editor.

Unfortunately the behavior construction tool isn't integrated with the behavior execution engine, so you have to run them separately, so you can't actually edit the behaviors in place while they're running.

Other visual programming languages like SimAntics and Bounce let you edit live programs while they are running, which is extremely useful.

The software side of the Evolution robotics kit includes modules for voice synthesis and voice recognition (IBM's ViaVoice libraries), as well as video capture, some simple image processing, sensor reading, motor control, network communication, teleoperation, a simple emotion engine and animated human face, and a bunch of other stuff.

But unfortunately the source code for many of the interesting modules is not included, so if they don't do exactly what you want you have to replace them from scratch.

For example, the human face emotion animation module doesn't support texture mapped faces. That's fine if your robot's face is Kermit the Frog, but I want to use face skins from The Sims. If Evolution decided to include more module source code with the SDK, programmers would be able to customize it more easily, instead of reinventing the wheel.

In summary, I like Evolution's modern and open architecture, and the code that I've seen so far is quite well designed and nicely written. But I'd like to see more code, please! One of the big problems in robotics is smoothly integrating many different pieces of software and hardware, and I think they've taken a good approach to that problem. Now they have to enable developers to easily integrate many different software and hardware modules, and let them all fight it out.

-Don

• http://www.ecn.org/radikal/
• http://www.connix.com/~harry/radikal/
• http://www.df.lth.se/~micke/not_my_political_views / adikal/
• http://catalog.com/jamesd/radikal/
• http://rigel.cyberpass.net/radikal/
• http://radikal.autono.net/

The /etc/hosts file is a different matter, but I've never seemed to have had too much of a problem with that one regarding nidump and niload. The only issue comes about when I have to delete entries. In that case I do need to use niutil.

I wholeheartedly agree that MacOS X will probably not replace most other Unixes in a server capacity or any of a dozen others I haven't thought of. That said, I think it's the best Unix workstation OS going right now, which probably isn't saying very much, but it beats many of the alternatives. At least Objective-C is mildly pleasant.

Actually, the X has a fairly sophisticated clipboard model, maybe a little bit too sophisticated. [...] Also read this for a backgrounder about clipboard and X: http://www.jwz.org/doc/x-cut-and-paste.html

Gee, that's nice. Care to explain how to make that "sophisticated" clipboard model work with something other than plain text?

lameness filt i,-""-,-" i i i "-,-""-, er lameness f
ilter lamene /,-' , .-'-.7.-'-. , '-,\ ss filter lam
eness filter \( i i/ i_ i i _ i\ i i)/ lameness filt
er lameness f '-, i{ (0) i (0) } i,-' ilter lameness
filter lamenes / i i> i.---. i< i i\ s filter lamene
ss filter lam |/ .-' i \___/ i '-. \| eness filter l
ameness filte {, / i,_ i i i _, i\ ,} r lameness fil
ter lameness i\ {, i i\ i i / i i,} / filter lamenes
s filter lamen ',\. i i'---' i i./,' ess filter lame
ness filte _.-""""""-._ i i _.-""""""-._ r lameness
filter l .' i i ___ i i`._.` i _ i i i i'. ameness f
ilter i_/_ i i | i_| _ _ i __ | |__ i i i \ lameness
fil .'` i `\ i | |_ | | | / _|| | / i i i i\ ter lam
en / i i i i| i| i_|| | || |_ | i \ i i i i ; ess fi
lt | i i i i/ i|_| i \_/ i\__||_|\_\ i i i i| er lam
en \ i;'---' i i__ i__ i_ i _ _ i _ i i i i ; ess fi
lte '. ; i i i i\ \/ / / \ | | | | | i i _ ; r lamen
ess f `-\ i i i i\ i/ | O || | | iV i i/' `, ilter l
ameness i`\ i i i/ / i \_/ i\_/ i o i | i i \ filter
lameness f \ i i/_/ i i i i i i i i i \ i i | ilter
lameness fi `\ i i i i i i i i i i i /` i _/ lter la
m ,-""-. en .'`\ i i i i i i i i i /`-,-'` .-""-, es
/ i i i`\.' i i`\ i i i i i i i /` i i'./` i i i\ s
; i.--. i \ i i i '\ i i i i i /' i i i / i .--. i;
| ( i i\ i |, i i i '\ i i i /' i i i i| i / i i) |
\ ; i i} i i i i i i ;\ i /; i i i i ` i { i i; / f
i `;\ i \ i i i i _.-' i\ / i`-._ i i i i / i /;` lt
er i\ \__.' i _.-' lamen Y ess f `-._ i i'.__// lame
ness '.___,.-' filter lameness filter`-.,___.' lamen

I think Linux is a great thing, because Linux is an alternative to Windows, and because, of all the operating systems that are at all relevant today, Unix is the best of a bad lot.

(Yes, that's right, though I've been living in Unix for more than a decade, I think Unix sucks. Read the "Unix Hater's Handbook" if you want to know why. But I'd rather run Unix than Windows or MacOS any day, because Unix sucks less. That doesn't mean it doesn't suck.)

I used Linux exclusively for most of 1995 and 1996, or thereabouts; back then, I found it to be a total nightmare. It took me three weeks to get X to drive my monitor at better than 640x400, even though Windows did 1280x1024x16 without flinching. I spent weeks fighting IRQ conflicts, trying to get PPP working, trying to find a three-button mouse that worked, and all manner of gross indecencies which do not bear mentioning in polite company.

I understand that here in this modern world, things are much better; but at the time, it was the most pathetic computing environment I had ever had the misfortune of being shanghaied into trying to sysadmin.

(And the fact that some of the problems I had were hardware problems did little to make me feel better; regardless, they were problems that were easier to solve under Windows, and problems that I would not have had at all had I been using a hardware/software combo from a ``real'' Unix vendor. I've heard all the apologies and excuses, I know the litany well.)

See, unlike most hackers, I get little joy out of figuring out how to install the latest toy. I don't get much sense of reward from having discovered how to get the Foo card to coexist with the Bar card. As far as I'm concerned, that crap is a solved problem, and not worth revisiting. That's like banging rocks together and being proud that you've re-derived fire from first principles. It's boring.

So finally I talked my boss into getting me an SGI Indy (which I've since replaced with an SGI O2) and life became joyous again. Because SGI actually knows something about building user interfaces, and about making it possible to administer a machine without being a member of the technological priesthood. For but one example, I was able to install and format a new disk on this machine through GUIs, without once having to run ``man'' and try to remember some random arcane command that I last used in 1986.

This is the part where I start getting hate mail from people, and cheerleading messages telling me to take a look at it again, because it's so much better now. I understand. I'll take your word for it. And when the time comes to replace the O2 I have today, maybe my next machine will run Linux. But as we all know, Linux is only free if your time has no value, and I find that my time is better spent doing things other than the endless moving-target-upgrade dance.

Of course, all of the software I write runs on Linux; that's the beauty of standards, and of cross-platform code. I don't have to run your OS, and you don't have to run mine, and we can use the same applications anyway!

I think Linux is a great thing, in the big picture. It's a great hacker's tool, and it has a lot of potential to become something more. I hope that some day it will have evolved to the point where my mom can take home a Linux box, turn it on, and get on with her life without having to become a Unix sysadmin first, and without having to give up on all the ease of use she's come to expect from allegedly less powerful operating systems.

Because, you see, what I want to do is to commoditize the OS. I want to have access to all the applications that I need to do the things that I need to do, regardless. Why should someone have to retrain themselves to use a new application that does the same basic thing as the old application, just because something as trivial as the operating system changed out from under them?

Operating systems matter deeply to programmers, but in the big picture, they're old news. It's all about the network, and the applications that let you get benefit from the network. Using a computer isn't an end in itself, it's merely a means to an end. The focus must always be on the task that the person wants to accomplish, to communicate, to learn, to create, to be entertained. Insofar as the computer itself makes itself known in this process, the computer is an impediment. Do What I Mean! Be humanistic, don't get bogged down in the details.

lameness filt x,-""-,-" x x x "-,-""-, er lameness f
ilter lamene /,-' , .-'-.7.-'-. , '-,\ ss filter lam
eness filter \( x x/ x_ x x _ x\ x x)/ lameness filt
er lameness f '-, x{ (0) x (0) } x,-' ilter lameness
filter lamenes / x x> x.---. x< x x\ s filter lamene
ss filter lam |/ .-' x \___/ x '-. \| eness filter l
ameness filte {, / x,_ x x x _, x\ ,} r lameness fil
ter lameness x\ {, x x\ x x / x x,} / filter lamenes
s filter lamen ',\. x x'---' x x./,' ess filter lame
ness filte _.-""""""-._ x x _.-""""""-._ r lameness
filter l .' x x ___ x x`._.` x _ x x x x'. ameness f
ilter x_/_ x x | x_| _ _ x __ | |__ x x x \ lameness
fil .'` x `\ x | |_ | | | / _|| | / x x x x\ ter lam
en / x x x x| x| x_|| | || |_ | x \ x x x x ; ess fi
lt | x x x x/ x|_| x \_/ x\__||_|\_\ x x x x| er lam
en \ x;'---' x x__ x__ x_ x _ _ x _ x x x x ; ess fi
lte '. ; x x x x\ \/ / / \ | | | | | x x _ ; r lamen
ess f `-\ x x x x\ x/ | O || | | xV x x/' `, ilter l
ameness x`\ x x x/ / x \_/ x\_/ x o x | x x \ filter
lameness f \ x x/_/ x x x x x x x x x \ x x | ilter
lameness fi `\ x x x x x x x x x x x /` x _/ lter la
m ,-""-. en .'`\ x x x x x x x x x /`-,-'` .-""-, es
/ x x x`\.' x x`\ x x x x x x x /` x x'./` x x x\ s
; x.--. x \ x x x '\ x x x x x /' x x x / x .--. x;
| ( x x\ x |, x x x '\ x x x /' x x x x| x / x x) |
\ ; x x} x x x x x x ;\ x /; x x x x ` x { x x; / f
i `;\ x \ x x x x _.-' x\ / x`-._ x x x x / x /;` lt
er x\ \__.' x _.-' lamen Y ess f `-._ x x'.__// lame
ness '.___,.-' filter lameness filter`-.,___.' lamen

I think Linux is a great thing, because Linux is an alternative to Windows, and because, of all the operating systems that are at all relevant today, Unix is the best of a bad lot.

(Yes, that's right, though I've been living in Unix for more than a decade, I think Unix sucks. Read the "Unix Hater's Handbook" if you want to know why. But I'd rather run Unix than Windows or MacOS any day, because Unix sucks less. That doesn't mean it doesn't suck.)

I used Linux exclusively for most of 1995 and 1996, or thereabouts; back then, I found it to be a total nightmare. It took me three weeks to get X to drive my monitor at better than 640x400, even though Windows did 1280x1024x16 without flinching. I spent weeks fighting IRQ conflicts, trying to get PPP working, trying to find a three-button mouse that worked, and all manner of gross indecencies which do not bear mentioning in polite company.

I understand that here in this modern world, things are much better; but at the time, it was the most pathetic computing environment I had ever had the misfortune of being shanghaied into trying to sysadmin.

(And the fact that some of the problems I had were hardware problems did little to make me feel better; regardless, they were problems that were easier to solve under Windows, and problems that I would not have had at all had I been using a hardware/software combo from a ``real'' Unix vendor. I've heard all the apologies and excuses, I know the litany well.)

See, unlike most hackers, I get little joy out of figuring out how to install the latest toy. I don't get much sense of reward from having discovered how to get the Foo card to coexist with the Bar card. As far as I'm concerned, that crap is a solved problem, and not worth revisiting. That's like banging rocks together and being proud that you've re-derived fire from first principles. It's boring.

So finally I talked my boss into getting me an SGI Indy (which I've since replaced with an SGI O2) and life became joyous again. Because SGI actually knows something about building user interfaces, and about making it possible to administer a machine without being a member of the technological priesthood. For but one example, I was able to install and format a new disk on this machine through GUIs, without once having to run ``man'' and try to remember some random arcane command that I last used in 1986.

This is the part where I start getting hate mail from people, and cheerleading messages telling me to take a look at it again, because it's so much better now. I understand. I'll take your word for it. And when the time comes to replace the O2 I have today, maybe my next machine will run Linux. But as we all know, Linux is only free if your time has no value, and I find that my time is better spent doing things other than the endless moving-target-upgrade dance.

Of course, all of the software I write runs on Linux; that's the beauty of standards, and of cross-platform code. I don't have to run your OS, and you don't have to run mine, and we can use the same applications anyway!

I think Linux is a great thing, in the big picture. It's a great hacker's tool, and it has a lot of potential to become something more. I hope that some day it will have evolved to the point where my mom can take home a Linux box, turn it on, and get on with her life without having to become a Unix sysadmin first, and without having to give up on all the ease of use she's come to expect from allegedly less powerful operating systems.

Because, you see, what I want to do is to commoditize the OS. I want to have access to all the applications that I need to do the things that I need to do, regardless. Why should someone have to retrain themselves to use a new application that does the same basic thing as the old application, just because something as trivial as the operating system changed out from under them?

Operating systems matter deeply to programmers, but in the big picture, they're old news. It's all about the network, and the applications that let you get benefit from the network. Using a computer isn't an end in itself, it's merely a means to an end. The focus must always be on the task that the person wants to accomplish, to communicate, to learn, to create, to be entertained. Insofar as the computer itself makes itself known in this process, the computer is an impediment. Do What I Mean! Be humanistic, don't get bogged down in the details.

That reminds me...
Golden-rod.

C-X C-S

NeWS was an advanced, Postscript-based network windowing system develped at Sun that was later dropped as a product in the late 1980s. NeWS contained advanced technologies that many people still praise today. Is there any possibility that Sun will release source code of NeWS under a free software/open source license? That should be a great contribution to the community.

That would be Quorum's Mac compatibility library. I evaluated the Quorum library in 1991, for use in porting the Mac version of SimCity to Unix. But I decided it would be much better to do a completely native port of SimCity to Unix instead of using a Mac emulation library.

The application and Quorum library are compiled on Unix, and provided API level compatibility (not binary), layered on top of a lame-assed X11 toolkit (Motif). So the application would have to be ported the the native C compiler and recompiled on Unix, unlike the much more successful approach that Transgaming has taken with Wine and The Sims on DirectX.

The main appeal of using a Mac emulation library like Quorum was that it would not require changing (much of) the original SimCity source code (modulo compiler incompatibilities, which are numerous).

But there was really no point to that, because the code was already forked, and being able to compile the same code on multiple platforms was not an issue. The whole point of porting SimCity to Unix was to take advantage of Unix features that Quorum's emulation library could not support, like pie menus and the multi player ability.

Doing a native port required much work rewriting the user interface from scratch, but that was what I wanted to do. So I used HyperLook on NeWS (which is similar to NeXTStep and Cocoa in that it uses the PostScript imaging model), and then implemented Multi Player SimCity using TCL/Tk on X11.

Adobe used Quorum to port Photoshop 2.5 to the Sun Solaris and SGI Irix platforms. I still have my original CD and manual for Sun Photoshop 2.5, which was only ever useful as a coaster. It was totally unusable, because it was so slow, with many glitches in the user interface, and it would crash at the slightest misplaced mouse click.

Because of the way that the single tasking Mac-centric interruptable screen redisplay algorithm clashed with the asynchronous X-Windows protocol and bloated Motif toolkit, you had to take your hands off the keyboard and mouse and sit on them while you waited for Photoshop to finish drawing everything, before it was safe to use.

Of course there weren't any commercial plug-ins available on the Sun or SGI platforms, because porting Photoshop plug-ins to Suns or SGIs was extremely tricky, thanks to the Mac compatibility layer. (Plug-ins didn't have a dynamic linking mechanism to call back into X11 and Motif, to implement their control panel guis).

The Quorum library's approach is quite different from the more successful binary level compatibility approach that Transgaming is taking to run The Sims on Linux.

I've been harshly criticized by fanatic Loki supporters for justifying Transgaming's emulation approach, instead of native ports. But Loki had their chance to perform a native port of The Sims, and blew it. Don't blame Transgaming for figuring out a way to do it successfully after Loki failed to.

I'm not religiously beholden to one technique or another. I'm interested in getting the best results, so I've used many different approaches myself. An emulated port is far better than no port at all. And there are many different approaches to porting and emulation, some better than others.

The particular application as well as the particular platforms involved play extremely important roles in deciding how to best perform a port. There are also many economic issues. There is no one best approach that's right all the time. And porting software is always going to be a lot of work. If you're not willing to put enough effort into it, the results will always be horrible no matter which approach you take.

-Don

That would be Quorum's Mac compatibility library. I evaluated the Quorum library in 1991, for use in porting the Mac version of SimCity to Unix. But I decided it would be much better to do a completely native port of SimCity to Unix instead of using a Mac emulation library.

The application and Quorum library are compiled on Unix, and provided API level compatibility (not binary), layered on top of a lame-assed X11 toolkit (Motif). So the application would have to be ported the the native C compiler and recompiled on Unix, unlike the much more successful approach that Transgaming has taken with Wine and The Sims on DirectX.

The main appeal of using a Mac emulation library like Quorum was that it would not require changing (much of) the original SimCity source code (modulo compiler incompatibilities, which are numerous).

But there was really no point to that, because the code was already forked, and being able to compile the same code on multiple platforms was not an issue. The whole point of porting SimCity to Unix was to take advantage of Unix features that Quorum's emulation library could not support, like pie menus and the multi player ability.

Doing a native port required much work rewriting the user interface from scratch, but that was what I wanted to do. So I used HyperLook on NeWS (which is similar to NeXTStep and Cocoa in that it uses the PostScript imaging model), and then implemented Multi Player SimCity using TCL/Tk on X11.

Adobe used Quorum to port Photoshop 2.5 to the Sun Solaris and SGI Irix platforms. I still have my original CD and manual for Sun Photoshop 2.5, which was only ever useful as a coaster. It was totally unusable, because it was so slow, with many glitches in the user interface, and it would crash at the slightest misplaced mouse click.

Because of the way that the single tasking Mac-centric interruptable screen redisplay algorithm clashed with the asynchronous X-Windows protocol and bloated Motif toolkit, you had to take your hands off the keyboard and mouse and sit on them while you waited for Photoshop to finish drawing everything, before it was safe to use.

Of course there weren't any commercial plug-ins available on the Sun or SGI platforms, because porting Photoshop plug-ins to Suns or SGIs was extremely tricky, thanks to the Mac compatibility layer. (Plug-ins didn't have a dynamic linking mechanism to call back into X11 and Motif, to implement their control panel guis).

The Quorum library's approach is quite different from the more successful binary level compatibility approach that Transgaming is taking to run The Sims on Linux.

I've been harshly criticized by fanatic Loki supporters for justifying Transgaming's emulation approach, instead of native ports. But Loki had their chance to perform a native port of The Sims, and blew it. Don't blame Transgaming for figuring out a way to do it successfully after Loki failed to.

I'm not religiously beholden to one technique or another. I'm interested in getting the best results, so I've used many different approaches myself. An emulated port is far better than no port at all. And there are many different approaches to porting and emulation, some better than others.

The particular application as well as the particular platforms involved play extremely important roles in deciding how to best perform a port. There are also many economic issues. There is no one best approach that's right all the time. And porting software is always going to be a lot of work. If you're not willing to put enough effort into it, the results will always be horrible no matter which approach you take.

-Don

That would be Quorum's Mac compatibility library. I evaluated the Quorum library in 1991, for use in porting the Mac version of SimCity to Unix. But I decided it would be much better to do a completely native port of SimCity to Unix instead of using a Mac emulation library.

The application and Quorum library are compiled on Unix, and provided API level compatibility (not binary), layered on top of a lame-assed X11 toolkit (Motif). So the application would have to be ported the the native C compiler and recompiled on Unix, unlike the much more successful approach that Transgaming has taken with Wine and The Sims on DirectX.

The main appeal of using a Mac emulation library like Quorum was that it would not require changing (much of) the original SimCity source code (modulo compiler incompatibilities, which are numerous).

But there was really no point to that, because the code was already forked, and being able to compile the same code on multiple platforms was not an issue. The whole point of porting SimCity to Unix was to take advantage of Unix features that Quorum's emulation library could not support, like pie menus and the multi player ability.

Doing a native port required much work rewriting the user interface from scratch, but that was what I wanted to do. So I used HyperLook on NeWS (which is similar to NeXTStep and Cocoa in that it uses the PostScript imaging model), and then implemented Multi Player SimCity using TCL/Tk on X11.

Adobe used Quorum to port Photoshop 2.5 to the Sun Solaris and SGI Irix platforms. I still have my original CD and manual for Sun Photoshop 2.5, which was only ever useful as a coaster. It was totally unusable, because it was so slow, with many glitches in the user interface, and it would crash at the slightest misplaced mouse click.

Because of the way that the single tasking Mac-centric interruptable screen redisplay algorithm clashed with the asynchronous X-Windows protocol and bloated Motif toolkit, you had to take your hands off the keyboard and mouse and sit on them while you waited for Photoshop to finish drawing everything, before it was safe to use.

Of course there weren't any commercial plug-ins available on the Sun or SGI platforms, because porting Photoshop plug-ins to Suns or SGIs was extremely tricky, thanks to the Mac compatibility layer. (Plug-ins didn't have a dynamic linking mechanism to call back into X11 and Motif, to implement their control panel guis).

The Quorum library's approach is quite different from the more successful binary level compatibility approach that Transgaming is taking to run The Sims on Linux.

I've been harshly criticized by fanatic Loki supporters for justifying Transgaming's emulation approach, instead of native ports. But Loki had their chance to perform a native port of The Sims, and blew it. Don't blame Transgaming for figuring out a way to do it successfully after Loki failed to.

I'm not religiously beholden to one technique or another. I'm interested in getting the best results, so I've used many different approaches myself. An emulated port is far better than no port at all. And there are many different approaches to porting and emulation, some better than others.

The particular application as well as the particular platforms involved play extremely important roles in deciding how to best perform a port. There are also many economic issues. There is no one best approach that's right all the time. And porting software is always going to be a lot of work. If you're not willing to put enough effort into it, the results will always be horrible no matter which approach you take.

-Don