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.
Doug.
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 (OpenSolaris) code base and the only references that remain to LWP calls are internally in the threads APIs themselves, the kernel& syscall interfaces 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 OpenSolaris 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 break]. This happened as part of the "Solaris Process Model Unification" project. Google can provide some further details if desired.
Doug.
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).