GUIs
Site News

Xerox
Visi On
GEM
Deskmate
GEOS
Desqview/X
AmigaOS
RISC OS
BeOS
QNX
OS/2
Apple
Linux/Unix
Windows
Win Shells
Misc GUIs

GUI Timeline
GUI Sites
Location: GUIs > Apple > Apple A/UX


Talking to the world, and wrap-up:

Well, I needed a good way of getting all those screenshots off the system, so I gave Appletalk a spin. The control panel setting to choose between Localtalk and Ethertalk works just like a normal Mac, and the chooser looks pretty familiar as well:
Now, A/UX 's UNIX side is a little schizoid about Appletalk. An advanced server implementation was available to run under A/UX, which if Apple's documentation is to believed, scaled much better under load then the standard Mac OS based implementation. Here's a note lifted from the Server Tuning Guide docbook:
 
Increased performance you can expect from AppleShare Pro

The following table shows the results of tests with AppleShare running on a Macintosh Quadra 950, and with AppleShare Pro running on the Apple Workgroup Server 95. As an example of the tests, the read operation involved opening a set of large files and sequentially reading from each one. The numbers in the table reflect the aggregate throughput of the server, which is the sum of all the server's processing for all of its clients.
Table 1-1
Comparison of performance of AppleShare 3.0 and AppleShare Pro (with 10 active clients)
AppleShare 3.0.1
on Macintosh Quadra 950
AppleShare Pro 1.0
on AWS 95
AppleShare Pro 1.1
on AWS 95
Sequential read operations 193 Kbits/sec. 851 Kbits/sec. 951 Kbits/sec.
Sequential write operations 160 Kbits/sec. 348 Kbits/sec. 594 Kbits/sec.
Enumeration (file listing) operations 90 items/sec. 132 items/sec. 295 items/sec.

The aggregate throughput of read and write operations performed by AppleShare Pro is four times faster than that of corresponding operations performed by AppleShare on a Macintosh Quadra 950. The improvement in aggregate throughput in AppleShare Pro as compared to AppleShare is largely due to the multitasking of the server; while the server is waiting for a request from one client, it processes a request from another client. (Tests of directory enumeration operations are discussed later in this chapter.)

(Editorial: This is vivid illustration as to why real multitasking matters. It's a shame Apple never figured that out for its consumer versions of Mac OS.)

Back to Appletalk and A/UX. Even though it can serve Appletalk resources, the UNIX side of A/UX has no idea how to mount a remote Appletalk share in the classic sense. Similarly, A/UX can't directly mount HFS partitions in the UNIX way. Instead, it depends on the Finder to handle moving things back and forth. A little odd, but ahwell.

Incidentally, the server I'm picking from the chooser is the same x86 Linux box I was FTPing and X-clienting from earlier, not another Mac. It's amazing what you can do these days.

Also, just to show off my incurable nerdiness, this is what I did with the screenshots after transferring them off the A/UX box:

Here I'm using the freeware image processing program 'BME' running inside of Basilisk II on my little notebook computer to turn the screenshots into GIFs, which I can then edit with the Gimp. I've mounted the same Linux box again, this time using Linux Netatalk's AppleShare IP emulation instead of plain Ethertalk.

It's Magic.

Anything else? Well, wait, before I forget. Here's what it looks like if you log in to A/UX's native X server:

To use A/UX in this mode, you select 'X11' as your desired session type from the option menu at login. (See the screenshot on page one) When A/UX is running in this mode, it becomes a pure UNIX workstation, similar to an old Sun 3/60 or SparcStation. You cannot run any pure Macintosh software, nor any hybrid programs which require the A/UX Toolbox.

There's not much to say about this mode, really. It defaults to the good old-fashioned twm window manager, like you'd find on just about any X capable *NIX box. Every program running in this shot, except for the Gimp (which I used to take this screenshot) is running locally on the Quadra. Yes, it even comes with xeyes. How old is that program, anyway?

In case you're wondering, it emulates a three button mouse using Option-Arrow combinations, same as MacX. Here it's a little less charming then it is on the Mac desktop, and you start getting fidgety about wanting the real thing.

If you're running a lot of X programs, this is the mode to run them in. The full-screen X server is quite a lot faster then MacX. MacX also suffers the limitation of essentially being a Mac OS program, which makes it fundamentally unable to multi-task as smoothly as you might like. That said, on a Q650 MacX is quite usable, and the OS overall is really quite responsive. If you set the machine next to an iMac or Beige G3 running OS X, you'd quickly rack up usability points during the comparison. A/UX boots faster, it takes much less time for the desktop to come up after logins, applications launch faster...

Yes, I'm speaking from experience. Having run OS X on a Rev. A iMac, I can say with a straight face that if I were forced to choose between that and A/UX on a fast 68K machine, I'd pick A/UX, with the proviso that I could use remote X sessions on a Linux box or something to run software that won't go on it directly.

Of course, don't get me wrong here. If UNIX performance is what you want, A/UX isn't where to look for it. Having run Linux on a 486 of similar Mhz rating to my Quadra, I'd have to say the PC would probably outperform it on most tasks. The Q650's video hardware is superior to the horrid ISA video cards you'll find in some ancient PCs, so X might actually be faster on A/UX. A machine with VESA or PCI local bus and/or accellerated video would easily shift the balance the other way, however.


So, that's your five-minute tour of A/UX. What do I personally think of it? (Warning: Some editorial content. The maintainers of this site might not necessarily endorse nor remotely agree with anything I say.)

The weird-looking critter above is a Gorgonopsid. It's one of the advanced "mammal-like reptiles" that ruled the earth near the end of the Permian Period, millions of years before the dinosaurs. They were well on their way to world domination, and had tragedy in the form of the Permian Extinction not set them back, strange big-toothed marsupialoids might of landed on the moon sometime in the late Jurassic. I'm sure they would of kept pterosaurs in little cages and taught them to talk as well. But things just didn't go their way.

For some reason A/UX reminds me of them. It was clearly contains some fairly advanced thinking, and in a number of ways was ahead of its time. It really made a good attempt to make (what many consider) a fundamentally difficult, but powerful operating system accessible enough that anyone could sit in front of it and use it successfully. I don't think any other UNIX of its vintage challenges it seriously in that regard. Another advanced concept it pulls off quite well is the ability to seamlessly mix old programs running in a virtual machine with the OSes native software. Some other UNIXes of the period could run DOS programs, and IBM's OS/2 made a valiant attempt to make Windows 3.0 look like a modular part of the OS, but A/UX clearly outclassed them. If the OS had continued to evolve, primarily towards making the Finder shell a true multitasking environment to match the solid UNIX underpinnings, Apple really would of had something nearly unbeatable.

But sadly, A/UX clearly was doomed to extinction. It wasn't climactic change or an asteroid that took it down, but something that for it was just as devastating. By the time A/UX got as good as what you've seen here, Apple was preparing to jump ship on the Motorola 68k platform. Porting A/UX to the PPC platform on top of all the trouble they were having with the bread-and-butter Mac OS would undoubtedly have been too large a drain of resources. Further, the "we'll run the parts we haven't done yet under emulation" strategy they used with Mac OS just wouldn't of flown under A/UX; a complete rewrite would of been called for.

(Do note how classic Mac OS didn't even get close being all-native code until OS 8.6/9, years after the switch to PPC. Even such vital parts of the OS as the SCSI drivers were emulated 68K code until quite recently. Whether Apple was suffering a lack of resources to do it right or misplaced priorities in dragging their feet that long I can't say. I do wonder if the change in architecture mortally wounded any chance of real structural improvements taking place in the OS. Instead of having the time to make it multi-task well and reliably, they ended up putting out fires in platform support and adding dubious bells and whistles to the GUI.)

Of course, A/UX had other problems even before then. It was ridiculously, frighteningly expensive. (although not any worse then most UNIXes of the time) Further, the system requirements to run well: 16MB of RAM and 200MB or so of hard disk, while almost comically small today, were quite significant back when people were still buying Color Classics. It never had a prayer of being a home operating system, and I don't think Apple ever made the attempt to market it seriously to businesses either, other then as the core of their most expensive file servers. Outside of the AWS 95, it was almost entirely something for academic use, so far as I've been able to deduce. Maybe they sold an occasional copy to a rich eccentric. (You had to be pretty well-heeled to drop $800 on an OS, plus the Mac able to run it.) But it never had much of a user base, certainly.

Finally, of course, there's the simple fact that Apple wasn't in the business of being a UNIX vendor, and AU/X couldn't be considered a core product. Mac OS was "good enough" for Apple's chosen high end stomping ground, desktop publishing and graphics manipulation. Its user base wasn't technical, and thus wasn't going to demand features such as robust memory management and multitasking kernels. While the OS would of benifitted immensely from such features, in a marketing sense they were an unnecessary expense. You can actually see some analog in the somewhat tepid response OS X has recieved by many Macintosh users. They don't understand the technical advantages of the core OS, and only see how the user interface is alien and kludgy compared to what they've grown accustomed to. Ironically, A/UX might not of had nearly the acceptance problem, because its UI is essentially indistinguishable from plain vanilla Mac OS if one ignores the UNIX underneith it. It doesn't have any equivilent of 'Aqua' to further confuse things.

So without a user base to sustain it and with the very environment it needed to survive eroding out from under it, A/UX sadly went the way of the Gorgonops. In some respects Apple is still struggling to regain the technical perfection they'd achieved back then in the Permian age of desktop computers. Meanwhile, the dinosaurs crawled out of the swamps and conquered the world.

Ahwell. The dinosaurs are ugly and frightening, and possibly even inefficient, but they are fast, powerful, and plentiful. They even run UNIX pretty well. But one still has to wonder how Gorgonops would of done in their place, if given the chance.
 
Apple Computer A/UX (eryops)
 
login: peppy
Password:
 
*******************************************************************************
*                                                                             *
*                       W E L C O M E   T O   A / U X                         *
*                                                                             *
*******************************************************************************
 
TERM = (vt100)
Mon Sep  3 20:53:51 PDT 2001
/users/peppy
./              .bashrc         .mac/           README          x11debug.log
../             .cshrc          .mailrc         System Folder/
.X11*           .kshrc          .profile        docs/
.aux_prefs      .login          .twmrc          download/
.bash_history   .logout         .x11start*      src/
eryops.peppy 1 % uname -a
A/UX eryops 3.1 SVR2 mc68040
eryops.peppy 2 % bash
peppy@eryops:~$ exit
eryops.peppy 3 % exit

 Thought for the day:
Alimony and bribes will engage a large share of your wealth.
 
Goodbye - come back soon
Connection closed by foreign host. 

A telnet session to an A/UX machine

If you want to run UNIX on your old Macintosh, I honestly can't recommend A/UX. The primary reason is licensing. A/UX was commercial software, quite pricey commercial software, and is still under copyright. While I doubt anyone would bother prosecuting you for running it on your old hardware, it is technically a problem. Further, with it being discontinued and unsupported software, I'm not even quite sure how you'd get a legal license for it. (Because of some vagueries of server software licenses, I'm not entirely sure that even were you to find a mint condition AWS 95 still in its original box with all the disks you'd necessarily have the clear right to use A/UX on it.)

These are of course all good reasons to support the concept of 'Abandonware' licensing for software once the manufacturer chooses to discontinue a product. Write your local congressman about it sometime. While you're at it, give him some heat about having voted for the DMCA.

There are other reasons that A/UX isn't really practical for production use. It is old code, and sources for bug fixes and updates for it dried up years ago. Out of the box is contains a multitude of security holes. Although obscurity might save you for a while, I personally wouldn't run A/UX without a good firewall in front of it. It's a very interesting museum piece, but for real work there are plenty of good modern UNIXes out there. For 68k Macs, look into NetBSD. For Powermacs, which won't run A/UX anyway, try Linux in one of its various forms.

Neither will have quite the charm of A/UX, but they're entirely free.

--Peace