Re: sparc32 and sparc64-only packages
Reinhard Tartler wrote:
> >> I agree. SPARC-32 might still have its place as an introduction for people
> >> with no experience of Sun machines if that's all they can get hold of, but
> >> I can't see anybody in their right mind expecting to run fancy animated
> >> graphics on it.
> >
> > It all depends what you use the box for. I run IceWM on my 170MHz
> > SPARCstation 5. I agree that it's not suited for watching movies, etc,
> > but it's still a useful box.
I agree that something like a WM, particularly one that prides itself as being
light and tight, would be expected to run on as many systems as possible,
irrespective of performance. Hell, I run KDE on an 8-way SPARCserver on
occasion, but in my case I'm concerned with being able to demonstrate that we
can /potentially/ reduce our reliance on the PC architecture rather than having
something that can do real work without major air conditioning.
> As xine comaintainer I'm interested if I should disable special vis
> optimisations in the xine-lib source package sacrificing performance on
> ultrasparc machines for the sake of older SPARCstations. This was not
> meant as offence for SPARCstation users (and I don't have much clue
> about sparc anyway), I rather want to find a good solutions for our
> users.
I'm a very junior member of this community, and I'm not a practicing C/C++ or
kernel hacker, so I'm not really sure I'm entitled to an opinion. However the
bottom line is that something like xine would be unlikely to perform adequately
on /any/ SPARC-32 system, either because of insufficient processor speed or
peripheral issues (limited colour depth on most screens, availability of audio
and suitable CD/DVD drives etc.).
The fastest 32-bit SPARC is going to be what- 200MHz? Let's say that in a
workstation that does the same amount of work as a 400MHz PC- marginal for
multimedia, even allowing that SPARC CPUs frequently come in pairs. In practice
most people who've acquired 32-bit machines will have something slower than
this: I might be wrong, but I think that xine would have problems even with the
most ingenious optimisations.
In other words, where there's a clear physical requirement which a particular
variant of an architecture can't meet then I see no reason to bend over
backwards to accomodate it.
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
Reply to: