One interesting O2 oddity is that the native pixel format is RGBA rather than ARGB (the alpha channel is at the other end of each 32 bit word).

Fixing that flushed out a whole bunch of assumptions in X driver and application code, which helps keep non SGI specific X and application code portable. Interesting to think that a user who only runs x86_64/Linux may be running an app with slightly cleaner code thanks to Michael's work on an ol' SGI O2...

(He has also fixed up and extended the accelerated driver for SGI Indy machines with newport graphics, and written drivers for a bunch of other graphics hardware on sparc, macppc and arm)

Most of the focus in NetBSD is on x86_64/i386 and embedded arm/mips/ppc boxes nowdays, but if you squint a little a small enough embedded box looks *really* similar to an older desktop/server box :)
so if people want to maintain support, why not?

Anyway, if you want a *really* slow older box you should be looking at an Atari TT or Vax (and lets just say we're not seeing any burst of new graphics drivers for them :)

NetBSD recently cut across to 64-bit time_t and its shaken out quite a few 32 bit assumptions.

http://mail-index.netbsd.org/current-users/2009/01/05/msg007024.html

The interesting part is not converting across to 64-bit time_t, its providing compatibility so all the previously 32-bit time_t compiled binaries and library keep working (at least until 2038 :)

dev_t was converted to 64-bits at the same time (two flag days for the price of one)

It involved versioning every function/system call that uses time_t, struct timeval, struct timespec, struct itimerval, struct itimerspec, struct rusage, struct stat, dev_t, struct ppasswd, struct utmp, struct utmpx, and ensuring the system can read both old and new versions of utmpx etc...

Certain bits of code which were using time_t to hold time offsets rather than absolute values were converted to using a normal 32 bit value (a good example might be anything in space constrained boot blocks)

I expect we'll be seeing a *lot* of patches in pkgsrc as the 64bit time_t application issues are fixed...

It would make a lot of sense to group the priority of support for different architectures. The obvious benefits include:

• Users know what level of support to expect from a given port
  
• It helps developers judge when adding a feature which ports should be updated first, and if some of the ports have not been updated whether it should necessarily hold up committing the feature
  
• It indicates which ports are looking for a new champion to take up the cause