Location: GUIs >
Apple >
Apple A/UX
<< Previous Page | 1 | 2 | 3 | 4 | 5 | Next Page >>
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
<< Previous Page | 1 | 2 | 3 | 4 | 5 | Next Page >>
|