> Yeah, but its worth checking from time to time.  They have been making
> good progress lately, except that right now their main web site is down
> for a major overhaul or something....

Yeah, they certainly have made some progress and they certainly are having
constant web problems.

> To be very frank about it I'm looking forward to giving it a try.
> Mainly because they are "attempting" to do it all, by not relying
> on the Mac's ROMs at all.  From my perspective (I'd love to here 
> comment from those of you that are more expert in this) that would
> also make their chances of success very, very difficult, what with
> the dirth of info on the internals of the various models.

Yep. And unfortunately they are going to have to reproduce a great deal
of our work from scratch. Though that's not too bad since a fresh
perspective may be a good thing. Our code is quite old.

To give them a hand I'm going to try and document what I'm doing separately
so that people with licensing problems can use my info. That should be
quite a boost as they seem to have early alpha versions of SCSI, serial,
and ADB for the II's.

> The reason its interesting to me is this: shouldn't their port be
> able to provide better performance from a given machine, since they
> won't be utilizing any ROM'd code, or is that wrong?  If its wrong,
> why is that the case?

To some degree but not because of the ROM code. We only use ROM code in a
very few places: optionally on ADB and in Paul's SLOTMAN code. The rest is
all ROM-free code. However, you'll probably find that Linux code is a bit
faster in some areas because the Linux folks' primary concern is speed
over portability. So you'll see lots of C speed stuff like heavy use of
macros and speed hacks all over the place.