On Fri, Apr 14, 2006 at 10:04:10AM -0700, Bart Smaalders wrote: > .... > But to tell you the truth, that's not a very interesting part of > the space to me. Sun4m shipped w/ 75 Mhz cpus max (discounting the old > HyperBrokens). They were obsoleted when UltraSparc shipped in > 1995, 11 years ago. Constraining all the software to run on that > hardware would be like only supplying software that ran on 486 > machines; doable but clunky and slow. > > For me, having the OpenSource software unable to take advantage > of the last 10 years of evolution in instruction sets and > 6 years of evolution in operating system features is a non-starter.
FYI: blastwave packages are constrained to support solaris 8 and sparcv8, as a *minimum*. Some packages can and do support more advanced architectures, *if* there is a noticable benefit. We take advantage of isaexec to do this, and -R$ISALIST. http://www.blastwave.org/standards/build.html mentions specific examples of when a maintainer should consider providing 64bit binaries. but the same logic applies for whether or not to supply an sparcv8plus+vis executable: "If an executable is noticably(10%+) faster " Currently, the following CSW packages already provide a sparcv8plus+vis optimized binary, in addition to the standard sparcv8 ones,according to http://www.blastwave.org/filesearch mpg123 lame radiance mplayer fox This does not include libraries that may be cpu-optimized. We have many more packages that offer sparcv8plus+vis optimized libraries, alongside the plain sparcv8 ones. Usually, there is more benefit in compiling the libraries that way, than the top-level executables :-) Similarly.. there are certain features that only exist in solaris 10. We *are* supporting those through various mechanisms, usually involving a run-time postinstall adjustment to the package. (ie: SMF support)
