Feature:Remembering the Star

Joshy has written an excellent piece after going to visit the Xerox PARC. Joshy also talks about what we could learn from the Star, and gives some ideas on how Linux could benefit as well.

The following is a feature by Slashdot Reader Joshy

A few weeks ago I went with a friend to the last presentation of the Xerox Star computer. It was quite a fun (and full) presentation and highlighted some of the things that are wrong with today's desktop software industry, and allows me bring up some suggestions on how we can fix it (somewhat).

We left Stanford campus to attend The Final Presentation of the Xerox Star at the Xerox Palo Alto Research Center. PARC is the research center where much of the desktop software industry was pioneered in the mid 70's. We got there a few minutes late because of traffic and had to park at FX PAL, another division of Xerox just down the hill from PARC. It still amazes me how much traffic exists on a few miles of back roads in Palo Alto. Presentations at the Pake Auditorium are not usually full, but this one had even filled up the overflow room. We ended up standing outside a second overflow room and watched the proceedings on a closed circuit TV through an open door. What we saw amazed us.

The Star computer was very much ahead of it's time for 1981. It was the successor to the Alto, which was the in house computer designed as a research project at PARC in the late 70's. The hardware consisted of several custom boards, each about 18 inches long and 12 inches wide. The Star had a heavy 8 megabyte (if I remember correctly) hard-drive that was extremely heavy (the guy just about got a hernia picking it up), and 1 megabyte of RAM (an astronomical amount of memory that was still doubled by my first 286). It had on board ethernet that ran at 10 MHz. Originally the Star was to have 20 MHz ethernet but a 10MHz clock chip was small enough to let the ethernet controller fit onto a single board, something which all other commercial ethernet vendors had failed to achieve. (so that's why ethernet runs at 10 MHz!) The keyboard looked like a standard 88 key keyboard with two additional sets of function keys, one on the left side of the main keys, and one above. The left set had names like copy, paste, and properties, while the top set was application specific (more on those later). The mouse had two buttons because research had shown that one was too few and three was too many. One of the presenters joked that the Macintosh also has two buttons on it's mouse, it's just that one of them is on the keyboard.

While the hardware was pretty advanced (it ran as fast as a recent PDP but fit under your desk instead of replacing your fridge) the truly amazing things were in the software. The Star was completely designed to be easy to use by a business professional and ready to run in a networked environment. It had printing, email, RPC (remote procedure calls), a networked file-system, and a complete yet simple desktop environment.

First of all, there was no menu bar. Actually, there was a small pop-up menu with a few oft-used commands that they weren't able to get rid of, but the presenter said that most users never knew they were there. All interactions were done either with direct manipulation, possibly in conjunction with function keys, or with a pop-up window. A user could create a multimedia document (images, text, colors, fonts) using less than 12 different commands. To copy text the user would simply select the text using the mouse and then hit the copy function key. To make some text bold the user would select text and then hit the properties key. A window with a list of properties would pop up, from which the user could change any attribute of the currently selected text. (This is like the context sensitive right menu button in Word, only you don't have to hold the button down.) To move files around or print the user would drag a document from the desktop into a file cabinet or onto a printer icon. If any extra information was needed, a dialog box would pop up asking for it.

To do more complicated things, things that couldn't be done using direct manipulation or with menus, the Star used keyboard mapping. To see what the keys were, the user could hit the 'keyboard' button and see a mini-version of keyboard on-screen, showing what each key did. This mini-keyboard could be used to type in symbols, foreign character sets (like Greek or Spanish), or math equations. It could even be used for Japanese. The user could use the mouse to press a mapped button in the window or just press the key directly. This let the user learn which keys he or she used a lot.

The Star wasn't perfect though. It had a few flaws that kept it back and let it be killed by the IBM PC a year later. With networking, email, windows, and wysiwyg wordprocessing; the Star was truly ahead of it's time. (Despite all of that, the men behind it still felt that it was under powered. It was usable but not zippy. Perhaps with a year or two of advances it would have been really fast.) The system was completely proprietary and not open at all. There was no third party hardware or software. And finally it was too expensive. It may have been many times better than the IBM PC, but for many managers looking to keep down the bottom line, that wasn't the issue.

Still, with all of these problems and it's ancient hardware, it is still better designed than much of what we have today. Apple caught up to PARC's research only 10 years late. Microsoft took 15 years. And they still got things wrong. No word processor should require a Pentium processor and 100 megs of disk space. Today computers are 1000 times faster, have 1000 times more storage (though only 10 times faster I/O), but does it have 1000 times better software? (the audience burst out laughing when one of the presenters facetiously suggested this).

Software has improved tremendously and allowed large productivity increases within specialized areas (like photo editing and page layout) but hasn't really helped out the general office user. We are still using arcane and bloated wordprocessors, slow spreadsheets, and having great trouble getting the printer to use that bottom paper tray. Why are things so bad?

We can try to blame greedy software manufacturers by saying that they promote buggy software which requires tech support and constant upgrades, but this is only part of the problem. The real problem is the lack of good User Centric design (I am using the term User Centric design instead of User Interface design because the issue isn't always about what the user sees on the screen). Too many pieces of our computers were designed to quickly or for alternative purposes and then redirected. It's often because the programmers were forced ship something before it's ready. Just look at any version of Netscape since 1.1. Sometimes I do wonder if the companies actually intend to make buggy software though. (no need to mention any names. :) No matter. We are stuck in our rut now and have to find a way out of it.

So this brings me to the second part of my essay. What do we do about it?

What I am about to propose is not a general solution. It is not meant for servers or workstations or pre-press operators. It is for the general office worker who needs to type reports, calculate spreadsheets, answer email, and print things. (This would probably also be true of most college students.) What I am proposing is a simple prefab version of everyone's favorite alternative operating system. A consolidation of protocols and applications to create something that my mom could use and not worry about it breaking. The office appliance.

Larry Ellison was on the right track when he proposed the Network Computer. He had two problems though. First, he didn't foresee the sub-1000$ computer. No one is going to buy a 700$ NC when they can get a fully loaded Pentium for the same price. Second, he and Scott McNealy assumed that they could make loads of money off of writing new software in Java for these NCs. As simple as these things are supposed to be to use, they are still computers. Computers are complicated things that need to be designed well. And that takes time. Creating machines with a new operating system, new applications, and server backends -- and doing it all in a two year time frame -- is simply a bad idea. I want a simple word processor, not a buggy one. As simple as the Star was to use, it was based on many years of research and design. You can't reinvent everything in two years and expect it to fly without crashing a lot. Larry discovered this at his lackluster NC demo last year. I love Java as a language and a platform. I do all of my new projects in Java. But there is no reason to suddenly *rewrite* everything in Java.

So how does Linux fit in?

First of all, Linux is not new. It has been around for almost eight years now, and is based on principles designed and tested over the last quarter of a century. It is very stable, very extensible, and very lightweight (at least compared to other desktop operating systems). Xwindows is less so, but still pretty good.

Second, Linux has lots of support. It may be lacking the latest hardware drivers, but we don't need this to run on the latest hardware. Linux also has lots of people who know how to maintain it. Armed with the newsgroups, LDP, and maybe a few O'Reilly books, there are tens of thousands of qualified sysadmins.

Third, Linux is already qualified to be a backend server. (multiuser, multiprocessor, security, networking ... yadda yadda yadda ... world domination)

Fourth, Linux is the only non-Microsoft desktop operating system that is growing in marketshare.

So how does this work?

We need Slinux (Simple Linux) to run reliably, quickly, and easily; all without having to call the sysadmin. The sysadmin is busy keeping the servers running or installing new Slinux boxes. She or he doesn't need to be bothered with questions about printer dialog boxes. So we need to address the issues of

• System installation
• System failure due to preferences
• System failure due to bugs or hardware
• Application preference failures
• Simple applications

System installation:

The sysadmin creates a custom distribution for each Slinux machine using a special tool that takes a default distribution and modifies it to fit the target hardware and target network environment. This custom distribution is then burned onto a CD, accompanied by a boot floppy, and installed on the Slinux machine. CD burners are really cheap and *should* be really easy to use.

System failure due to software preferences:

Each client machine has a harddrive with two partitions. One is for the OS and the other is for user data and backup of system files. In the event that the users manage to really screw up their system by changing software configurations (unlikely as it is, it can still happen. Murphy is not on our side.) they can reinstall by popping one floppy and one CD into the machine and rebooting. This is the CD with the custom distribution of Slinux. The floppy will erase the system partition on the harddrive and then reload the preconfigured OS from the CD. The floppy is only a boot image and a driver for the CD. I realize that reinstalling the OS seems more like a Windows 95 solution, but sometimes it really is the easiest solution, especially if there is no configuration required afterwards. Any changes made by the sysadmin since the CD was made would be loaded from the network.

System failure due to bugs or hardware:

Any buggy software can be upgraded remotely with tools designed for such a task. If users reinstall their OS, then the new software will be automatically reloaded at install time. If hardware fails then it will of course have to be replaced and a new CD burned. This new CD would take into account any configuration changes made for that target machine, both changes from the sysadmin and changes made by the user. This is possible because any changes made to the system files by the user (assuming they are allowed to) are backed up in a special place on the user's data partition. And of course the data partitions should all be backed up remotely by the sysadmin onto tapes.

If the target hardware or environment ever changes, then a new CD is burned using the burning tool that keeps track of system wide distribution and all of the variations for each target. Burning a new CD is a lot of work if you just want to change some rc files, so many changes would be done using remote administration tools. Scripts would be run on each target machine to download any changes made by the sysadmin (the scripts could be started explicitly or periodically using a cronjob).

A nice feature would be programs that monitors system performance and email the sysadmin if it looks like anything is getting flaky.

Application preference failures:

If the user changes a preference in an application that breaks the functionality of the app, then there should be a simple program to save the changes and then revert back to the default settings (either from the network or the local disk).

Most users won't change their settings so this shouldn't be a problem, but many people like to futz with their fonts or window manager backgrounds, and this should be a recourse just in case anything breaks.

The default distribution:

This should be set up with the latest stable version of all software. The sysadmin can then pare it down and tweak it to fit the target environment (using tools designed for this job of course). There would be no extra users, no extra daemons running, and bug fixes to all major packages. This ensures that the distribution is a secure as possible.

Simple applications:

What end-user applications should be on this system? In addition to any custom or site specific apps, there should be a word processor, a spreadsheet, an email application, a *graphical* file manager, and a webbrowser. And there shouldn't be much else! This isn't for the poweruser or even the average Linux user. It's for someone like my mom. She doesn't want lots of apps. She just wants to get her work done and not have the computer break. She can install other apps if she really wants to, but most of the time the computer should just sit there and work.

Word Processor: There are word processors out there for Linux but they are way too complex. We need something simple, or at least something that can be configured to look simple with the extra stuff hidden unless the user really wants it. I'm talking paragraphs, font size and italics. HTML will serve what most people want out of a wordprocessor.

Spreadsheet: I'm not sure what's out there right now, but I know that I've been very happy using Excel 4.0 for Mac 68k (using the Executor emulator. See http://www.ardi.com/). In fact, I think it *still* has too many features, and it still made graphing too hard. Making charts should be very easy, especially for college students doing their chemlabs. Again the important thing is that the sysadmin can configure the default installation.

Email application: As Mozilla progresses I'm hoping that the email app will get better and eventually be as good as Eudora (stable, fast, easy to do filtering).

Web Browser: Mozilla. (Duh!)

File Manager: I think that KDE is coming along pretty well, though it needs to be more configurable (from the sysadmin side). I'd say that several windowmanager/filemanager combinations should be installed and the user can pick which one they want. These all should be preconfigured by the sysadmin using a preconfiguration tool (dotconfig?)

System Services:

We need to decide on protocols for user to user and user to service interaction.

For email we should have both shared spools and IMAP (people should be able to access their mail from home, firewalls be damned!). All mail readers should be mime-capable.

For networking and filesystems we have TCP/IP, NFS, SMTP. I would say we should ignore directory and database services that aren't web based, but that's up to each sysadmin.

Is there a standard for printing? We have postscript for the files, but what about selecting destination printers and trays. These shouldn't require arcane options for lpr. It would be nice if any application could call a small printer program that pops up a dialog box customized for the target computer/environment. Then a user can directly select which printer and what kind of paper they want.

Miscellaneous:

Instructions on how to reset apps or the system should be in a two page manual that is printed out, *laminated*, and sits on the user's desk.

Small shared apps (like games) or large data collections (like desktop backgrounds) could be on an shared NFS drive.

So what do people think? Is this do able? Are there others working on similar projects? I'd like to start a discussion group to put together such a Linux distribution. Also I'd like some name suggestions. 'NC Linux' might give the impression that it is completely dependent on the network or destined for set top boxes. 'iLinux' might get us sued. :) Slinux? Slynux? eLinux? EZLinux?