From: Thomas Koenig (ig25@fg30.rz.uni-karlsruhe.de)
Date: 04/22/93


From: ig25@fg30.rz.uni-karlsruhe.de (Thomas Koenig)
Subject: Re: Linux on Macintrashes? (Was: Re: Linux on
Date: 22 Apr 1993 12:36:54 GMT

strat@enterprise.ksu.ksu.edu (Steve Davis) writes:

>I stand corrected on this issue, of *course* Macintrashes are real
>computers, there are working UNIX ports to them! (:P) The question is:
>Is it really worth anyone's time to port Linux over to them knowing
>that
> 1. The Linux kernel depends on a 386 protected mode architecture.
> Meaning, of course, that binary compatibility is out of the
> question, and that "porting software to Linux" would mean
> having to work on two completely different architectures.

I'd still say Linux is a better starting point for writing something
to run on a 68k than an empty editor ;-)

The things which would need rewriting are the device drivers and some of
the context switching and interrupt stuff, because of the different I/O
systems, endianness, etc.

Porting application programs should be easy, with the same set of
function calls working in the same way; or does your application
depend on the Intel's little - endianness? ;-)

> (Part of the reason for Linux's success to date is that
> all 386 and 486 systems at least share the same architecture.)
> To put it in simpler terms, a Linux port to the Macintrash
> *wouldn't be Linux*.

It would have different bugs on the driver level, probably, but that's
about it.

> 2. FSF wants nothing to do with the project. This means that there
> won't be any support for the compilers, and none for the
> tools compiled with them. Macintrash Linux users might
> have to *ghasp* write their own patches to software or deal
> solely in precompiled packages (something else FSF isn't
> very fond of).

So what? If it's application compatible with 386 - Linux, there's no
problem at all.

There already are gcc ports to the Atari ST and the Amiga under their
respective "native" operating systems, so it can't be ALL that hard...
Also, there is no reason (other than religion, of course :-) why Atari,
Amiga and Mac ports should not be binary comptatible on the application
level, and source code compatible to the Intel version. (Hey, anybody
working on a Linux port to HP-PA, RS-6000, Sparc or Alpha? ;-)

>Having said this, we get to the issue of what Macintrash users want or
>need. Far be it from me to criticize someone for buying a tool that
>works perfectly for their particular use, but I fail to see reason in
>trying to make a Macintrash something that it's not. Macintrashes
>*have* a stable, multitasking operating system and a reasonable
>selection of software and tools.

Mac System 7 does not preempt. We have a case here at our Institute
where somebody keeps blocking a Mac for hours on end because he's doing
some very extensive calculations in Mathematica. Yuck.

>The few people I know that bought Macintrashes for personal use (most
>have used Macintrashes at work, and consequently go to the computer
>store looking for an alternative), the machines were purchaced for
>homework (word processing) or business (spreadsheets, et al.) and
>wouldn't know the difference between UNIX and VM/CMS if their lives
>depended on it.

We seem to know different people; the only person I know who's bought
a Mac for home is hacking a massive parallel computer (a 2^14 processor
one) right now for his degree, and he knows a thing or 15 about
operating systems :-)

>Finally, I see no particular advantages in running Linux on your home
>Macintrash rather than purchasing a power PC with the expandibility,
>compatibility, and portability issues already dealt with.

What about getting the most out of available hardware?

Frankly, I don't see what the excitement is.

If somebody wants to port Linux to the Mac (or adapt the Amiga version,
or whatever), let them! The worst thing they can do with it is waste
their own time, and I think it's theirs to waste any way they choose.

-- 
Thomas Koenig, ig25@rz.uni-karlsruhe.de, ig25@dkauni2.bitnet
The joy of engineering is to find a straight line on a double
logarithmic diagram.