--pgp-sign-Multipart_Mon_Oct_30_15:38:22_2006-1
Content-Type: text/plain; charset=US-ASCII

>>>>> "sc" == Sean Caron <caron.sean@gmail.com> writes:

    sc> there's lots of good old ultra hardware out there available
    sc> for a song [...] take it over an x86 box anyday.

I more or less agree, except that if you are running more than one or
two very old, simple programs (apache, mutt, Postfix, Samba, Perl and
BIND on a good day), these machines simply will not work.  ex.:

 * Java (Azureus)
 * OpenOffice
 * anything using Gnome or KDE because of thread bugs

There is also some incredibly obscure bug in libdvdcss that on x86 it
can crack all DVD's, but on SPARC it can only crack some DVD's.  If I
pull over the title key from an x86 box, the SPARC can rip the disk
fine.  so,...wtf am i supposed to do about that?  I think there is no
realistic hope I can fix it or beg someone else to fix it before DVD's
are replaced with some unplayable FutureDISC with working crypto and
even more draconian laws behind it.

The development toolchain (the speed of gcc.  The quality/workingness
of gdb.  whether or not the kernel can do core dumps and gdb can read
them.) is much of the time worse on non-x86 architectures.

Also, proprietary software is either completely unavailable, or the
student-discount / crippled version for 1/20th the cost is limited to
Linux/Mac/Windows only, so buying a personal copy before you graduate
and holding onto it is impossible.  In addition some (ex. Wolfram)
arbitrarily double the price for non-x86 architectures.

 * LispWorks
 * MatLab
 * Mathematica
 * Maple

Hardware-wise, it is often a major problem to use IDE or SATA disks on
non-x86.  On alpha, IDE controllers basically do not work at all (they
trash network performance, operate at 1/10th speed, or are
unreliable), perhaps because of some simple PCI latency register bug
but the problem has persisted for years.  On macppc I found my card
mostly worked, but it probed the same disk/cable as Ultra33 in the Mac
and Ultra100 in the x86---no clue why, and sadly no patience on my
part.  Even on SPARC where as I understand it the latency register is
properly set by NetBSD no matter what OpenPROM does, for some IDE
chips there are problems because the x86 ROM does some kind of magic
initialization to the chip that we can't replicate.  There is maybe
some long-term solution to this imagineable---maybe some emulated
userland x86 machine with almost all imaginary chips, into which we
map a single real PCI device that appears to be on bus 0 right next to
the emulated CPU no matter where it is in the actual hardware or what
kind of MMIO or sparse memory it needs, and then we run its ROM---I
don't think anyone's interested in working on something big,
difficult, maybe-doomed like that.  I guess some people have good luck
with PATA/SATA on non-x86, but even the post I read in this thread was
about a SCSI array.

Given the politics of the time, and just trying to clean up and
modernize a bit, I would like to start encrypting all disks.  Once you
decide to do this, having a fast CPU isn't just about builds going
snappier or being able to watch DVD's---it's about being able to
saturate 100Mbit/s over Samba so my housemates don't complain and say
``well Vista can encrypt disks too'' or some fucking noise like that.

Power-wise, my wintertime bill is >$500/mo, and I wouldn't be
surprised if it doubled within 5 - 10 years.  Our power bill is
already 0.6x - 1.0x rent in the summer thanks to an old clunker
aircon, pre-NAFTA Bushwick factory windows, and all these old
computers.  At places like CCC Cologne they have this neat and huge
collection of old hardware, many architectures and OS's proprietary
and free, but they are all switched off!  I saw nothing but Debian the
whole time there.  and just trying to colocate a box in their closet,
the club officers will argue with you about power and whether it's
really needed.  It was really depressing for me to see computers being
_switched off_ at all.  basically everyone has moved onto laptops to
escape the German $0.33/kWh power prices, and NYC is already at
$0.20/kWh.  I'm really interested in how to do more with fewer watts,
and while non-x86 is probably a great idea, buying old hardware on
eBay because it's supported by old operating system code probably
isn't the winning strategy here.

Finally, BSD doesn't have any logging filesystem, so every time
capacity increases 10x, fsck time increases 100x.  It doesn't matter
if you can fsck in the background with UFS2 if it takes a year to
check your 10TB array.  As the arrays get larger, span multiple disks,
consolidate NFS-roots of multiple machines homedirs of multiple
people, backups of DVD collections worth thousands of dollars, emails
photos and memories for an increasingly large fraction of the time I
get to spend on this planet, I start to get really paranoid about some
subtle filesystem weirdness occurring in some beta release some time
in the next thirty years backing me into a corner and losing all my
shit.  so I don't want just disk mirroring, or RAID5 with a gaping
write hole.  I want something with snapshots and some fsck fancyness.
And I don't want to pay double or quadruple per spinning GByte because
of some weird ancient bus requirement, when I could spend the same
money on an rsync mirror for some real protection.

so...I still prefer the ``feel'' of BSD and non-x86 to everything
else.  and I still own no non-x86 hardware (I weasel out of it by
saying everything x86 belongs to someone else and I ``maintain'' it,
or it's ``shared ownership by the House'' or something).  but the
range of usefulness keeps getting squeezed and shrunken while what I
want to do is expanding.  so I feel like these are dark times for our
whole industry, and that that BSD on non-x86 is being outnumbered or
outmanouvered by a bunch of second-rate crap that is starting to look
more and more enticing.

--pgp-sign-Multipart_Mon_Oct_30_15:38:22_2006-1
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (NetBSD)

iQCVAwUARUZiyYnCBbTaW/4dAQJiwAP8Cidy7Z/M7TF/LpT4jVqvZ12D5h8Fe0tr
YJ7NZhdNEWfr4PDkjeUrT/l/K9G6glQ9un+cv+Oe0RrJRRVKHEJwT9ezTzjb591m
byw/2FuUahe4hwueMEjefEasX5mGbfT2HSXN4TwI668xjb2G6OJW9o5TE9g5Bc40
+raldyzVq6k=
=V0Q5
-----END PGP SIGNATURE-----

--pgp-sign-Multipart_Mon_Oct_30_15:38:22_2006-1--