> "Quick" is relative, of course.  Shouldn't we be able to cross-compile 
> packages for the popular, slow, architectures (such as m68k, arm, and mips)? 
> Actually my biggest problem was disk space.  Laptop drives don't come cheap, 
> and we don't effectively support FireWire HDs.

We should, yes. And someone (I forget off the top of my head) had 
integrated a CPU level emulator with a framework which passed all OS calls 
to the native CPU. Or something like that. It'd be wonderful to extend 
something like that to all CPUs, as there are emulators for just about 
everything now.

Regarding drives, a bulk build can be told where to extract and compile, 
so you can keep the distfiles and binary packages on an NFS volume and 
just have a drive large enough for the compile process. I do this on 
several older machines (50 pin half height SCSI drives are impossible to 
find with more than 9 gigs of space).

>> I should point out that if the system ever gets very busy (lots of network 
>> while compiling, let's say), having awacs will probably lead to a lockup. 
>> But for a local machine, that's not that big of an issue.
>
> Hmm.  Well often I'd run several builds concurrently (e.g. downloading one 
> while compiling another), but my pipe to the outside world maxes out at about 
> 400 KB/s.  I guess that doesn't qualify as "lots of network".

I saw lockups about once or twice a month on a system which was pushing 
around 10 gigs a day. Since I've removed awacs, it has been up 100 days 
and done about 4 terabytes of traffic.

> Whatever happened to Alex Zepeda <zipzippy@sonic.net>?  Sounded like he was 
> doing good stuff with the awacs driver a while ago.

It'd be nice to fix, but unfortunately I was never local to the machine 
when it locked. It's 3000 miles away, which makes it a pain.

I saw the same problem with a G4 running 2.0, but I put in the motherboard 
serial port at the same time I removed awacs from the kernel config.

John