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] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
