Ahh, GTE is so reliable. I wish they would get in gear and
install this dry pair for my DSL.
I've gotten 2.2.12 boot-floppies ready for Debian SPARC
potato, should prove to be very reliable. I'm looking
forward to this SPARC release, it is a huge improvement over
the slink release.
On the job front, I'm merging some data sets for our
internal directory server. 4300+ user entries with names,
addresses, phone numbers, and email. All three data sets
need to be compared and merged and checked for
discrepancies, what fun :)
On the lighter side of the Debian front, I've volunteered to
represent Debian/SPARC for testing gcc3 (am I an idiot? :).
64bit support will be very exciting, Dave and Jakub have
done an excellent job with SPARC build tools. I'm still
contemplating whether Debian will have a native sparc64
port, or will I simply overlay 64bit userspace on the
sparc32 port. I may end up doing both. I don't know of any
OS for UltraSPARC that is native 64bit from kernel to
userspace (even Solaris 7 is 64bit overlay, not sure about
Solaris 8), so having it will be a big plus :)
I still need to talk to Jakub about the 64bit library
layout. /lib64:/usr/lib64 seems simply wrong, IMHO. Solaris
does it with /lib/sparcv9. I'm just wondering if /lib/64
would fit better into the FHS, especially since i386 does
things like /lib/686. Also, it would be nice if SPARC's
ld.so could pull optimized libraires like
/lib/{v7,v8,v8plus} based on the current running system.
Only problem with that is uname() only returns "sparc"
instead of "sparcv7", "sparcv8", "sparcv8plus", etc.. I
should probably code up a patch for that, shouldn't be too
hard.
I think I finally have the Debian lists.debian.org mailing
lists under control. VERP is a wonderful thing, and it has
reduced my maintainence effort considerably. Now all I do is
sit and watch the bounce logs while the automated system
slices and dices those evil errors.