Date: Fri, 8 Mar 2002 23:43:53 -0500 From: Bob Drzyzgula <bob@drzyzgula.org> Message-ID: <20020308234353.B29678@www2> Subject: Re: [suse-sparc] Will there be a SuSE 8.0 for Sparc?
Well, I just wanted to add my voice as one who greatly
appreciates whatever work SuSE has put into the SPARC
port. When the post went out earlier saying "where are
the SuSE employees on this list?", my first reaction was
that the poster must not have subscribed to the list for
very long, because I thought that SuSE employees were
frequent contributers to this list. We of course see dry
spells from that direction -- all of us get overwhelmed
on occasion. But I think that there's a remarkable amount
of support here for a product that is being developed and
distributed for free.
I do wonder a bit about SuSE's motivations for maintaining
the SPARC port. I think if people understood the motivation
a bit more, they might not be so prone to complain. SuSE's
SPARC port clearly does virtually nothing for them in terms
of unit sales. I suppose that there may be some big support
deals where the availability of the SPARC port gives
SuSE an advantage over the competition. Having it ready
to go if Sun were to more clearly endorse Linux on SPARC
(as opposed to x86, where Sun still seems to want to keep
Linux contained) might also be useful from a competitive
standpoint. Perhaps it's just something Thorsten likes
to do as a hobby :-) But it seems unlikely that the ISOs
for download make them any money in any direct sense.
Although all my SPARC machines at home are all 32-bit,
(mostly some SS5s, along with a couple of SS10s and an SS20
that I don't run because they are electricity hogs) I really
don't expect that SuSE will be able to do much to help with
the problems with 32-bit SPARC unless the SPARC port starts
making some real money, and even then it's likely to be the
64-bit SPARC that will get the bulk of the attention.
Let's be real for a minute: the 32-bit SPARC systems
haven't been made for years. The fastest of these use the
HyperSPARCs, which only got up to around 200MHz and at that
were slower than a 200MHz non-MMX Pentium. At least in the
US, $100 will buy you a used or surplus x86 system that
will run circles around a quad-processor SPARC 20. A 500MHz
Athlon is six times as fast as a single 150MHz HyperSPARC
for integer work (SPECint95). You can even purchase a
300MHz Ultra 10 -- with 128MB, 4.2GB Disk, CDROM, Keyboard
and Mouse -- for about $350, see http://www.solarsys.com
(#include <std_disclaimer.h>).
So I don't think that many of us are running 32-bit
SPARC Linux machines because it's a cost-effective thing
to do. If we were businesses, continuing to use these
things instead of replacing them with something faster,
cheaper, newer, and more well-supported would most likely
be regarded as irresponsible except in highly unusual
circumstances.
No, more likely, we just have some of these things kicking
around because we rescued them from the surplus bin,
and we're trying to make them seem useful even though it
doesn't make any damned economic sense at all. Heck, at my
electricity rates, it was costing me around $40 per month
to run a SPARCstation 20 24x7 with four 90MHz HyperSPARCs,
three S-bus cards and two internal SCSI disks. Replacing it
with an old Pentium 166 system would have paid for itself
within a few months.
IMHO, it really doesn't make much sense to keep supporting
these old machines in the newest kernels. The new
Linux kernels are huge by comparison to what preceded
them. One probably should think of these systems as
museum pieces which are capable of running only older
software, or software which is designed specifically
with the requirements of older hardware in mind, such
as NetBSD -- which still runs on MC68010-based Sun 2 and
MC68020-based Sun 3 systems. Linux 2.4 is optimized for
larger, faster, modern systems, and no 32-bit SPARC meets
this criteria today. Linux 2.4 is all about 8-way systems
with 2GHz processors in each slot. It's about System 390
mainframes. It's about handheld units, yes -- but handhelds
with CPUs running at hundreds of megahertz.
If someone has so much time on their hands that they can
afford to clean up the 32-bit SPARC port of Linux 2.4,
well so be it. But I really don't think that any kernel
developers *owe* that to *anybody* (well, unless they
are being paid to do it, but I suspect that none of them
are...) I will go so far as to say that if there is a
community of 32-bit SPARC users who want to continue
using them as Linux machines ad infinitum, then I think
that they should pick some historical, working Linux
port, say something in the 2.2.x series, and start
adding functionality from there through a series of
patches, possibly including stuff backported from later
kernels. This of course amounts to a fork of the kernel,
but it is the very best kind of fork -- one that allows
the developers of the leading-edge kernels to not have to
constantly worry about antique hardware. Again, the NetBSD
project is an excellent example of how this might look
down the road. And again, I don't think this is SuSE's
responsibility in the least.
--Bob
-- To unsubscribe, e-mail: suse-sparc-unsubscribe@suse.com For additional commands, e-mail: suse-sparc-help@suse.com
This archive was generated by hypermail 2.1.0 : Fri Mar 08 2002 - 20:42:46 PST