Slashdot Mirror

The Network extensible Window System. Boy, do I miss NeWS. Not the cruddy widgets and look and feel of OpenLook, but rather the beautiful architecture and capabilities I got to use for a fleeting moment before Sun dropped it. This is a ripe candidate to be open sourced. James Gosling, if you're out there, could you please convince Sun to release the NeWS source tree?

For those who've never heard of it, it was a network window system (duh) that was based around a multithreaded PostScript interpreter with extensions to draw on the screen, handle input events, and with an object oriented programming facility. Unlike DPS it was designed as client server (like X) from the ground up with a much more efficient and customizeable wire protocol. In the version shipped with OpenWindows 3.0 it was integrated with an X server.

The beauty of it was because you communicated with it in PostScript you could offload processing on either the client or the server side depending on where it was most appropriate and by creative use of definitions on the server significantly cut the amount of data that would have to go across the wire. This can include implementing the window manager entirely inside the display server.

If you want to see some of what it could do, Don Hopkins has a page on NeWS at:
http://catalog.com/hopkins/lang/NeWS.html

Also for a good look (now a bit dated) on why X sucks see:
http://catalog.com/h opkins/unix-haters/x-windows/disaster.html
A sample from this page:

"Myth: X Is "Customizable" ...And so is a molten blob of pig iron. But it's getting better; at least now you don't hasve to use your bare hands. Hewlett-Packard's Visual User Environment is so cutting-edge that it even has an icon you can click on to bring up the resource manager: it pops up a vi on your .Xdefaults file! Quite a labor-saving contraption, as long as you're omniscient enough to understand X defaults and archaic enough to use vi. The following message describes the awesome flexibility and unbounded freedom of expression that X defaults fail to provide."

--john dougan

The Network extensible Window System. Boy, do I miss NeWS. Not the cruddy widgets and look and feel of OpenLook, but rather the beautiful architecture and capabilities I got to use for a fleeting moment before Sun dropped it. This is a ripe candidate to be open sourced. James Gosling, if you're out there, could you please convince Sun to release the NeWS source tree?

For those who've never heard of it, it was a network window system (duh) that was based around a multithreaded PostScript interpreter with extensions to draw on the screen, handle input events, and with an object oriented programming facility. Unlike DPS it was designed as client server (like X) from the ground up with a much more efficient and customizeable wire protocol. In the version shipped with OpenWindows 3.0 it was integrated with an X server.

The beauty of it was because you communicated with it in PostScript you could offload processing on either the client or the server side depending on where it was most appropriate and by creative use of definitions on the server significantly cut the amount of data that would have to go across the wire. This can include implementing the window manager entirely inside the display server.

If you want to see some of what it could do, Don Hopkins has a page on NeWS at:
http://catalog.com/hopkins/lang/NeWS.html

Also for a good look (now a bit dated) on why X sucks see:
http://catalog.com/h opkins/unix-haters/x-windows/disaster.html
A sample from this page:

"Myth: X Is "Customizable" ...And so is a molten blob of pig iron. But it's getting better; at least now you don't hasve to use your bare hands. Hewlett-Packard's Visual User Environment is so cutting-edge that it even has an icon you can click on to bring up the resource manager: it pops up a vi on your .Xdefaults file! Quite a labor-saving contraption, as long as you're omniscient enough to understand X defaults and archaic enough to use vi. The following message describes the awesome flexibility and unbounded freedom of expression that X defaults fail to provide."

--john dougan

UNIXUX: click on the cursor

The X-Windows Disaster

UNIXUX: click on the cursor

The X-Windows Disaster

• X is horribly, horrible ram hog
• Many x applications have truly awful interfaces
• The X windows API is almost impossible to program for
• Higher level APIs make it easier to program for, but invariably add layers on top of an already slow system, making it even slower.

Second, that this topic is growing really quickly and in the time it took to compose this, much of this has become redundant - at least I have a link to another copy of the Unix Haters Handbook, because it just seemed appropriate to mention the canonical criticism site about Unix. This is from the X Windows portion, specifically The X-Windows Disaster; here's a brief summary of highlights.

• Confusing user interface/Too much versatility, leading to overly complex or impossible interprogram communication: "cut-and-paste never works properly with X (unless you are cutting and pasting straight ASCII text), drag-and-drop locks up the system, colormaps flash wildly and are never installed at the right time, keyboard focus lags behind the cursor, keys go to the wrong window, and deleting a popup window can quit the whole application".
• X is a non-extensible window server - in contrast to NeWS. X was based around the concept of a dumb graphical terminal, and it uses a lot of data to achieve that. In contrast, NeWS and Java offer a somewhat more intelligent terminal interface to the client, and they make better use of less data.
• X programs have lots of nasty user interface problems, including X configuration.
• (This is about halfway through, then the complaining gets more heated and lengthier, like sitting in a Unix Users Anonymous group and hearing about how someone hit the bottom.)
• X has bad hardware support - This is out of place, isn't it?
• X isn't device independent, or maybe has a limited graphical toolkit? "Drawing arcs is probably impossible in a portable fashion."

Allowing alternate display primitives makes some sense to me; adding, say, an OpenGL extension simply to incorporate double-buffering seems like overkill. But then, how, outside of an extension, can you make use of an accelerated card, without processing the lowest-common-denominator drawing primitives? Using the X protocol, can you exploit accelerated hardware to anti-alias text and graphics, for example?

Other criticism I've heard that the X protocol should take advantage of the locality if the client and server are operating on the same machine. This only makes much sense to me if the cpu overhead in dealing with the network protocol is noticeable; being able to transparently work from another machine is too nifty to throw away.

By a coincidence, I was speaking to a more X-literate friend (hi Eric!) about this last night. My knowledge is badly limited; he had to explain the purpose of the window manager to me. So please, if you want to flame me, be brief.

Second, that this topic is growing really quickly and in the time it took to compose this, much of this has become redundant - at least I have a link to another copy of the Unix Haters Handbook, because it just seemed appropriate to mention the canonical criticism site about Unix. This is from the X Windows portion, specifically The X-Windows Disaster; here's a brief summary of highlights.

• Confusing user interface/Too much versatility, leading to overly complex or impossible interprogram communication: "cut-and-paste never works properly with X (unless you are cutting and pasting straight ASCII text), drag-and-drop locks up the system, colormaps flash wildly and are never installed at the right time, keyboard focus lags behind the cursor, keys go to the wrong window, and deleting a popup window can quit the whole application".
• X is a non-extensible window server - in contrast to NeWS. X was based around the concept of a dumb graphical terminal, and it uses a lot of data to achieve that. In contrast, NeWS and Java offer a somewhat more intelligent terminal interface to the client, and they make better use of less data.
• X programs have lots of nasty user interface problems, including X configuration.
• (This is about halfway through, then the complaining gets more heated and lengthier, like sitting in a Unix Users Anonymous group and hearing about how someone hit the bottom.)
• X has bad hardware support - This is out of place, isn't it?
• X isn't device independent, or maybe has a limited graphical toolkit? "Drawing arcs is probably impossible in a portable fashion."

Allowing alternate display primitives makes some sense to me; adding, say, an OpenGL extension simply to incorporate double-buffering seems like overkill. But then, how, outside of an extension, can you make use of an accelerated card, without processing the lowest-common-denominator drawing primitives? Using the X protocol, can you exploit accelerated hardware to anti-alias text and graphics, for example?

Other criticism I've heard that the X protocol should take advantage of the locality if the client and server are operating on the same machine. This only makes much sense to me if the cpu overhead in dealing with the network protocol is noticeable; being able to transparently work from another machine is too nifty to throw away.

By a coincidence, I was speaking to a more X-literate friend (hi Eric!) about this last night. My knowledge is badly limited; he had to explain the purpose of the window manager to me. So please, if you want to flame me, be brief.

Second, that this topic is growing really quickly and in the time it took to compose this, much of this has become redundant - at least I have a link to another copy of the Unix Haters Handbook, because it just seemed appropriate to mention the canonical criticism site about Unix. This is from the X Windows portion, specifically The X-Windows Disaster; here's a brief summary of highlights.

• Confusing user interface/Too much versatility, leading to overly complex or impossible interprogram communication: "cut-and-paste never works properly with X (unless you are cutting and pasting straight ASCII text), drag-and-drop locks up the system, colormaps flash wildly and are never installed at the right time, keyboard focus lags behind the cursor, keys go to the wrong window, and deleting a popup window can quit the whole application".
• X is a non-extensible window server - in contrast to NeWS. X was based around the concept of a dumb graphical terminal, and it uses a lot of data to achieve that. In contrast, NeWS and Java offer a somewhat more intelligent terminal interface to the client, and they make better use of less data.
• X programs have lots of nasty user interface problems, including X configuration.
• (This is about halfway through, then the complaining gets more heated and lengthier, like sitting in a Unix Users Anonymous group and hearing about how someone hit the bottom.)
• X has bad hardware support - This is out of place, isn't it?
• X isn't device independent, or maybe has a limited graphical toolkit? "Drawing arcs is probably impossible in a portable fashion."

Allowing alternate display primitives makes some sense to me; adding, say, an OpenGL extension simply to incorporate double-buffering seems like overkill. But then, how, outside of an extension, can you make use of an accelerated card, without processing the lowest-common-denominator drawing primitives? Using the X protocol, can you exploit accelerated hardware to anti-alias text and graphics, for example?

Other criticism I've heard that the X protocol should take advantage of the locality if the client and server are operating on the same machine. This only makes much sense to me if the cpu overhead in dealing with the network protocol is noticeable; being able to transparently work from another machine is too nifty to throw away.

By a coincidence, I was speaking to a more X-literate friend (hi Eric!) about this last night. My knowledge is badly limited; he had to explain the purpose of the window manager to me. So please, if you want to flame me, be brief.

Hi, Jamie.

This is also in the Unix Hater's Handbook, referenced from your site, of course.

One of the quips on X sheds some light though "How to make a 50 Mips workstation run like a 4.77 MHz IBM PC". Courtesy of Mr. Moore, consumer desktop PCs are shipping with 10 times the CPU speed and memory of a what was once a top-of-the-line workstation. When you add network bandwidth to the equation -- X was (and is) used to run many apps remotely on a server or other workstation to the local display -- X was a pig.

The world's changed a lot. Most of the complaints against X have been repaired either by fixing the original problem, or more often, by upgrading the environment.

SGI takes it to ridiculous extremes, however. What does Jot do, for example, that requires GLX?

I'm guessing you know the answer to this already, but the reason Jot requires GLX is that it was written using a GUI toolkit that happens to be built on OpenGL instead of on Xlib. I haven't used that toolkit, so I don't know what its merits are, but it's sure not hard to imagine a GUI toolkit whose API recommends it over Xt or Motif.

Jot is also a very old program; most of SGI's tools use Motif these days.

But, you know, there are technical reasons why one might want to use GL in something like a text editor, too: because when you only use raw X, performance sucks . For example, you're not going to be able to do things like, say, scroll text smoothly without using an API that gives you more direct access to the frame buffer than the baseline X protocol gives you.

Even for non-3d applications, the performance improvements you can get by using GL instead of X are amazing. I mean, my god, raw X can't even do double buffering properly. (And before you mention the ``double-buffering extension,'' try it with XFree86: the performance is identical to copying pixmaps yourself by hand, meaning that's doubtless how it's implemented in the server.)

As Don Hopkins so eloquently put it, `` The X approach to device independence is to treat everything like a MicroVAX framebuffer on acid.'' All the associated layers of pseudo-generalism make it impossible to actually take any real advantage of the underlying hardware.

"This Pournelle guy" also can't write decent SF yet gets his name on a lot of Larry Niven books.

Apparently, he also was kicked off ARPANET, back in the day:


MIT Maximum Confusion PDP-10

MC ITS.1488. PWORD.2632.
TTY 57
16. Lusers, Fair Share = 86%

*:login pourne
That account has been temporarily turned off.
Reason:
Think of it as evolution in action.
Any questions may be directed to USER-ACCOUNTS
*

A good place to start here is to refer you to The Unix Haters Handbook which was compilled by Simson Garfinkel, Daniel Weise and Steven Strassman. Published by Programmer's Press/IDG Books in 1994. ISBN 1-56884-203-1. While some of it's complaints are about old version of unix and some are just nitpicking, there are a lot of valid points in there. Every serious unix user should read it. Here is a web page with some little excepts. It also has a link to some stuff with the blinking cursor thing.

I did have some good bookmarks here that would been good to include here, however I can't seem to find them. If you look arround the net you might find some of them. The sites are still probably out there. One site that occassionly has interesting unix problems is the Risks Digest. Occasionally security sites have stuff like this too.

Some quick points. There a lot more than I've got here and some things may be open to taste and religion. Other people have done a much better job than I'm doing here. Much of unix was written as series of quick and dirty hacks that worked for the simple case but does does not scale to the general case. Any way - some points

• A lot of the programs that come with it are inconsistent, they take different flags, take their input and output through different means, etc. This can be a real killer on occasion when you accidentally use the wrong flag and trash something. It also make using them more work, since you have to learn all the different flags and behaviours. Some programs even interperet them differently ie "foo -bar" may be the same as "foo -b -a -r" or it may be different. The pieces just don't always fit together.
• The unix shells intercept and expand all sorts of things like "*" and "~" rather than just passing them through to programs and letting them deal with it. (Really simple example: "rm * .o" -- "do you really want to remove all files?". You can't do this. This may seem like it's not all that important but there can be times when you really want to do it. Also if you want pass stuff like this down to say a lower shell script using say $1, then it's too late. Unless you make the user put quotes arround it. But then quotes get removed and it gets expanded at the next step if you not careful. and so on. All this is assuming that there are not so many files in a directory that your shell can't cope with the size of the strings produced when * is evaluated)
• Shells are a bastard crossbreed of command interperter and scripting language. And don't do a great job of either. Fortunately Larry Wall and Guido van Rossum wrote Perl and Python ;-)
• Relics like man (1) persist even though they suck for what they are supposed to do.
• BSD v System V incompatabilities.
• Really, really, inflexible file access control system. (ie rwxr-x--- type stuff). Sure it's easy to implement but there is just so much stuff you can't do. For example: people in group "coders" and group "testers" have access to this directory without having to make a new group "codersandtesters". Even windows NT has ACL's.
• Core files. Yeah, I really wanted a 20MB core file from an application that I an not devolping and don't even have the source code for. Unix treats everyone as if they are a developer.
• X windows, where widget chaos reigns. Different programs behave differently and "mode confusion" is a matter of course. And soooo much of it is ugly and tricky to use. GNOME and KDE may help, but there will always be apps that are exceptions.
• It's mostly built on C which is another area of serious brain damage (and is also talked about in the haters book). A lot of the standard libraries have serious safety problems.
• Curses and termcap/terminfo. Basically this involves moving the terminal driver into the application rather than having the operating system do it for you. Ditto for graphics. There should not be a program that is directly accessing the hardware (and thus can screw your whole machine if is crashes). GGI/KGI are fixing that.
• Unix style file systems including ext2 can be incredibly fragile. I had a flaky hard disk controller. Under windows individual files got corrupted. Under linux huge chunks of the file system failed. Sometimes fsck was like pouring petrol on a fire. (It did teach me to back up regularly ;-)