Agreed. I can't say for certain if someone isn't running SunOS 4.x
anymore (just as I couldn't say for certain that no one is running
DOS 4.x anymore).
From a corporate standpoint, Sun's recommendation is that people should
use/develop on/migrate to Solaris 10 or OpenSolaris [aka Indiana/Nevada etc..]
I, and most Sun Solaris engineers, run on either the most recent build
or nightly build (as of today thats snv_95/snv_96). Many update every
morning before they start serious work using bfu. I generally consider a build
that is older than 5 builds (10 weeks) to be pretty ancient. Many shared
engineering machines, build machines etc. are also updated every other
week or nightly to the latest build. On the corporate IT side the rule is
systems should be running Solaris 10 or later, and/or should be on a schedule
to updated if they aren't. The majority of IT is on Solaris 10 at this point,
but some Solaris 8 and Solaris 9 boxes still exist internally.
Externally, we know that people who are using Solaris and that are still using
a release prior to Solaris 10, do so using Solaris 8 or Solaris 9, hence the reason
why Sun is also doing a lot of work to support those OS releases in xVM or
containers [zones] aka Etude, on newer hardware platforms.
For OS releases usage prior to Solaris 8, our support interest and the known
external usage of those OS releases falls sharply.
There are known to be a small number of Solaris 2.6 and 2.7 systems still
running, but Solaris 2.5.1 or earlier are statistically very rare. Side note,
Sun stops providing any support for Solaris 2.7 on August 15, 2008.
From what I can tell, the last patch made to the SunOS 4.1.4 patch gate
was in 1999, SunOS 4.1.3U was last touched in 1993, 4.1.1 in 1990,
and SunOS 3.5 in 1988.
I hope that helps people make a decision as whether to continue support
SunOS 4.x or not, and to know what we focus our energies on. Hopefully this
info will help others to also be less distracted by really old Solaris builds.
Howard Chu wrote:
Doug Leavitt wrote:
> To the best of my knowledge, within Sun we use almost exclusively
> threads APIs and not LWP APIs. I scanned the current Nevada
> code base and the only references that remain to LWP calls are
> internally in the threads APIs themselves, the kernel& syscall
> and one spot in dtrace.
In fact, you're looking at a completely different API. The code in
question is for SunOS4 LWP, not SunOS5/Solaris. I'd be shocked if anyone
was still running a Sparc1/SunOS4 out there today...
> My recommendation is to remove the non-functional LWP code.
> If someone at Sun used LWP calls instead of normal thread calls in
> code, during the code review people here would certainly question it.
> Also FYI, during Solaris 10, the threading model was updated to 1-1
> LWPs to
> threads vs. MxN LWP pools [prior to Solaris 10], and the thread APIs were
> all moved to libc [libthread is now a stub library so Makefiles don't
> This happened as part of the "Solaris Process Model Unification" project.
> Google can provide some further details if desired.
> Hallvard B Furuseth wrote:
>> libraries/libldap_r/thr_lwp.c (SunOS LWP) has since 1999 (rev 1.5) said:
>> /* This implementation NEEDS WORK. It currently does not compile */
>> I suggest we kill LWP support. Has anyone tried to use it since 1999?
>> Note, configure --with-threads=lwp turns into either Solaris
>> threads (#define HAVE_THR) or SunOS LWP (#define HAVE_LWP).