gus@Shasta.ARPA (12/10/85)
It has come to my attention that there are or may soon be one or more
versions of UNIX proted to the Mac, especially with the roumored hardware
upgrades.
I would like to point out that there have been other attempts at porting
other operating systems to the Mac, most notably, UCSD Pascal. By their
very nature, these ports cannot take full advantage of a machine which sets
itself apart almost entirely with its software. There is really very little
in the Mac hardware architecture other than a 68K, a standard frame buffer,
a mediocre sound generator, and a few off the shelf I/O chips. This, in
todays market, makes for very little. Any hobbyist can put together such
a machine, and many small companies are making a good living by making such
machines and having someone port their operating system to it.
What really sets the Mac apart from the rest of the croud is its ROM, system,
and application software. This is where the Mac makes its main impact on
the marketplace. Without this, the machine is no better than an IBM PC
(an otherwise dull machine which was lifted to prominence by marketing muscle
of its parent company).
One might argue that porting software like UNIX to the Mac can only help
the marketplace by increasing the amount of software available on the
machine. There are many other machines that run UNIX, however, and thoes
people most tempted to run UNIX on the Mac probably have access to another
UNIX machine somewhere else. There is now a prolifferation of readily
available compute power, especially for those in the know, who can most take
advantage of the full power of UNIX, that being computer science
professionals, and other technically minded individuals. There is still a
stunning lack of full-blown commercial UNIX applications software for end-
users, as opposed to that available for, lets say, MS DOS, VAX VMS, various
IBM OS's or even Macintosh.
My main argument here is: if you really want UNIX on the Mac, you probably
have access to it somewhere else. You can probably make best use of ALL the
resources available to you if you use each machine for what it does best.
One of the main reasons that one would want to use a Mac to run UNIX (perhaps
the ONLY reason) is the prolifferation of excelent software development
tools running on UNIX. One may be tempted to see if you could apply these
tools to Mac native development, instead of cross development, as is
available now.
Although I have no idea of the exact nature of these UNIX ports, I can give
a pretty good educated guess as to what one might expect when trying to do
native Mac development in a UNIX environment.
1) File system incompatibility: Even though the new HFS supports a UNIX
style tree structure, there are many incompatibilities, most notably links,
that would make it cumbersome to substitute the Mac file system for the one
in System V or Berkeley 4.2. At best, you may be able to partition a Hard
Disk 20 for use partly with UNIX and partly with HFS, with a file system
transfer program to bring files across. At worst, you will not be able to do
any partitioning, and the entire hard disk will be devoted to Unix. This is
the sort of situation currently available on a Lisa running both Workshop
and MacWorks. One often finds that the partitioning originally set up gives
too much room on one side, and that you have to re-format the disk (thus
erasing all files on both sides) in order to change the partition.
2) ROM incompatibility: Moswt of the Mac ROM assumes that memory is layed
out in a certain way. In particular, most of low core is pre-defined, and
memory manager data structures are assumed to be intact. UNIX would have
thing completely differently. It is thus unlikely that even the simplest ROM
calls could be supported. This also means the you cannot run, or even debug
mac-specific software under a UNIX environment. This is not to say that UNIX
will not allow access to the Mac framebuffer, and that some of the simpler
QuickDraw calls might not be able to be implemented (or at least emulated)
but this is a far cry from having the entire set of calls available to you.
3) Tool unavailability: Most of the unix utilities work at the source
code level. Make, lex, yacc, diff, grep, awk, csh, tar, etc. are act on, and
produce text files as output. These can obviously come in handy for any sort
of development work. Unfortunately, the sorts of tools which are useful for
Mac related work, i.e. resource compilers/editors, would have to be written
from scratch. Much of this work has been done in the SUMACC system developed
by Bill Croft. This, however, is public domain work which would probably not
appear in a commercial product. As mentioned above, some of the excelent
runtime tools under UNIX, such as the dbx debugger, and the prof profiler,
would not be available because you would not be able to run any software that
is the least bit Mac OS dependent.
4) User interface incompatibility: This probably goes without saying. The
UNIX shell is a far cry from the Mac finder. Although a "Mac-style" finder
might be made available, this would take a lot of work and would probably
not be expected in a simple port. More importantly, perhaps, is the style of
editing available under UNIX vs that available with the Mac. Although there
are EMACS packages which allow minimal mouse support, they are a far cry from
a Mac style editor where all commands are supported from the mouse, and the
keyboard is simply used for typing and shortcuts. If you are used to EMACS or
VI, then you will like UNIX on the Mac. If you like Mac style editors, you
may have to change your habbits.
Perhaps most importantly when considering user interface design, is
the "I don't mant to learn a new way of doing things" syndrome. If you are
planning on developing FOR the Mac, you should be exposed as much as
possible to its unique user interface. Otherwise, you might find yourself
slipping into old progreamming habbits which are undesireable in a Mac
program, such as modal interfaces. As use the Mac AS a Mac, you begin to
detect many of the subtle nicities which are available in some of the more
polished programs. I give the MacWrite header/footer icons as a perfect
example. To put automatic page number, time, or dates in your document, just
drag one of three icons into the header or footer windows. This is a feature
which would probably NOT be thought of by someone coming from a heavy UNIX
background.
5) Frequent 'world' swapping: Lets say that you have all of the tools to
create Mac compatible resource files under Mac UNIX. You now transfer the
file to a Mac diskette (or the Mac side of the hard disk), bring down UNIX,
and bring up Macintosh. You now bring up your debugger, run your program,
and find a trivial error which requires you to recompile. You bring down
Macintosh and bruing up UNIX (A rather long process...) and make your edit
change, recompile, ... This is a rather long edit-compile-debug cycle. I
would put it at minimum of ten minutes for a trivial program. To say that
this is not ideal is an understatement. Now I am not saying that this cycle
is not long in native Mac environments (especially when using a minimal
configuration) but having to switch operating systems can only agravate the
problem.
The solution to this problem is to use TWO machines: a source machine,
and an object machine. Even when both machines are using the same OS, this
is a desireable method of development on small machines without true
protected multitasking, because you want to debug your code and make changes
to it in the editor at the same time. Unless you have a true multitasking
window system with hardware memory protection, it would not be wise to debug
your program on the same machine that you are running it. You thus want two
seperate machines with two seperate monitors: one running your program with
the debugger, and the other running your editor.
If one of these machines is running UNIX and the other is running Mac
OS, then why does the former even have to be a Macintosh? Most lisa based
development setups work this way. Even if the Lisa can run MacWorks, it is
much nicer to have both a Lisa and a Mac on your desk and use both for what
they do best.
Macintosh developemnt unde UNIX is thus done best in a cross
development environment. UNIX is not actually RUN on the macintosh; it is
simply used as a tool to write programs FOR the Macintosh.
Let us assume, then that you are not using Mac UNIX to create Macintosh
specific software. Perhaps, then, you are writing a port of an existing UNIX
application so that it runs under Mac UNIX. You are thus using the Mac as
"just another computer" and you plan to use few, if any, of its unique
features. Let us also assume that you are trying to sell this softwasre
commercially. This means that your customers must also buy a UNIX license
for their machines just to run your program. This license will cost a least
$500-$1000. Unless you have a very specialized vertical market application,
few customers could justify this sort of expense. Furthemore, you would
probably be bundling the hardware with the software to make a full turnkey
system. In this case, your choise of a Macintosh with its limited memory and
slow processor was a poor choice of a target machine to start with,
especially when there are many other inexpensive UNIX boxes in the
marketplace.
Even if you are not planning todevelop software, but simply USE
existing UNIX software on a Mac, you must find a very good reason to lay out
the overhead costs of buying a UNIX license. (and the hard disk deditcated to
supporting it) You will probably find that, with the increasing availability
of Mac software, that your application is covered by an existing Mac product.
Certainly, there may be legitemate reasons for wanting a Mac running
UNIX. The worst reason is because you originally made a bad hardware
descision, and that you find the Mac OS distasteful, and you see no reason
why you should have to change your style of computing from a standard
command line interface. In this case, you have payed about $2,000 for a
machine that you really didn't want, or which was given to you. In this
case, another $1000 might be justifyable instead of buying a new machine.
Another reason has to do with machine portability and form factor.
The Mac's unique shape and 'style' of portability might make it ideal for
certain 'nitch' markets where other UNIX machines would prove combersome.
Perhaps the best reason for having a Mac UNIX port available is peceived
(but not actual) market demand. Many MIS directors, when looking at what
machines to buy for their company, check to see if a machine can run UNIX or
not. If so, then the machine could run some as yet un thought of software,
and it does not become obsolete if and when the software base dies down.
This is really a fallacious argument since it is very unlikely that the
'perfect' application will come your way that will tempt all of your users
which have been using MacWrite for months to have to switch to a new
operating system. Once a hardware base is installed and users are trained on
it, no matter how bad it is, inertia will set in and it is hard to change
that system with another which is incompatible.
Seeing as UNIX has been ported to a host of different hardware
architectures, there are certain software engineers who have made it their
business to port UNIX, and it then becomes easy to treat the Mac as 'Just
another machine.' For this reason, you will probably see UNIX running on
the Mac, and any and all machines designed in the near forseable future, as
lon as they have a reasonable amount of power and there is even the
slightest market demand. The mere fact that this issue was brought up in a
previous discussion indicates that there at least might be. The fact that
UNIX has been ported time and time again means that the cost of doing a Mac
port is low enough to satisfy this demand, even if it only a peceived
demand, amnd not an acual one.