Re: Foolproof version checking
Bill Campbell
>Hi all,
>
>What is the best way, on an unknown Open Server box, to determine the
>version (such as 5.0.6), including on very old boxes?
I have always used ``uname -X''
>And has there ever been a version 4.2?
As in 3.2v4.2, which I think was the last OpenDesktop 2.0 system.
I have one in my rack, but it has not been booted for years.
Bill
--
INTERNET: bi...@celestial.com Bill Campbell; Celestial Software LLC
URL: http://www.celestial.com/ PO Box 820; 6641 E. Mercer Way
Voice: (206) 236-1676 Mercer Island, WA 98040-0820
Fax: (206) 232-9186
There's no trick to being a humorist when you have the whole government
working for you. -- Will Rogers
Bob Rasmussen
What is the best way, on an unknown Open Server box, to determine the
version (such as 5.0.6), including on very old boxes?
And has there ever been a version 4.2?
Regards,
....Bob Rasmussen, President, Rasmussen Software, Inc.
personal e-mail: r...@anzio.com
company e-mail: r...@anzio.com
voice: (US) 503-624-0360 (9:00-6:00 Pacific Time)
fax: (US) 503-624-0760
web: http://www.anzio.com
street address: Rasmussen Software, Inc.
10240 SW Nimbus, Suite L9
Portland, OR 97223 USA
ThreeStar
> On Mon, Jul 21, 2008, Bob Rasmussen wrote:
> >Hi all,
>
> >What is the best way, on an unknown Open Server box, to determine the
> >version (such as 5.0.6), including on very old boxes?
>
> I have always used ``uname -X''
>
> >And has there ever been a version 4.2?
>
> As in 3.2v4.2, which I think was the last OpenDesktop 2.0 system.
> I have one in my rack, but it has not been booted for years.
>
> Bill
> --
> URL:http://www.celestial.com/ PO Box 820; 6641 E. Mercer Way
> Voice: (206) 236-1676 Mercer Island, WA 98040-0820
> Fax: (206) 232-9186
>
> There's no trick to being a humorist when you have the whole government
> working for you. -- Will Rogers
I believe Open Desktop was a bundle. Version 2.0 did include 3.2v4.2
but I don't believe they're synonymous.
I'm still maintaining a number of 3.2v4.2 production systems.
RLR
*** Software
Jeff Liebermann
<r...@anzio.com> wrote:
>What is the best way, on an unknown Open Server box, to determine the
>version (such as 5.0.6), including on very old boxes?
See:
<http://members.cruzio.com/~jeffl/sco/versions.txt>
Kinda overkill, but uname -X should do the trick unless you want
versions of all the various modules and installed software.
>And has there ever been a version 4.2?
Sorta. Open Desktop 3.2v4.2
-> uname -r
3.2
-> uname -a
comix comix 3.2 2 i386
[ksh] [ttyp0] [root] [/]
-> uname -X
System = comix
Node = comix
Release = 3.2v4.2
KernelID = 93/04/28
Machine = i80486
BusType = ISA
Serial = sco006640
Users = unlim
OEM# = 0
Origin# = 1
NumCPU = 1
Incidentally, this ODT box has been in service continuously since
about 1989. It's currently a 486DX2/66 with 8MBytes ram and a Conner
1080s 1GB drive. Fast, efficient, reliable, cheap, etc... I keep
waiting for it to die so I can replace it with something better.
--
# Jeff Liebermann 150 Felker St #D Santa Cruz CA 95060
# 831-336-2558 je...@comix.santa-cruz.ca.us
# http://802.11junk.com je...@cruzio.com
# http://www.LearnByDestroying.com AE6KS
Bela Lubkin
I believe they're anti-synonymous.
Lists of SCO Unix, Open Desktop, Open Server, and OpenServer version
number history have been posted before. Google thyself.
Ummm. Actually, I'm not finding my own posting on the subject, and the
best web pages I can find about it are moderately wrong(*). So here's a
modified quote from an old private email of mine:
Here is a correct mapping of standalone SCO Unix version numbers to
bundled Open Desktop version numbers:
Bundled "SCO Open Desktop", "SCO Open
Standalone "SCO UNIX" Desktop Server System", and/or "SCO Open
version Server" version
3.2.0 (ODT 1.0 hadn't yet shipped)
(3.2.1) ODT 1.0 (underlying OS labeled 3.2.1; 3.2.1
was never available as a separate standalone)
3.2v2.0 ODT 1.1
3.2v2.1 (was a version number which `uname -X` would return on
both 3.2v2.0 and ODT 1.1 systems after being upgraded by
a supplement whose name I no longer remember)
3.2v4.0 (no corresponding ODT release)
3.2v4.1 ODT 2.0 (**)
3.2v4.2 ODT 3.0
Starting with SCO Unix 3.2v5.0.0 / OpenServer 5.0.0, there was no
"standalone Unix" product, so the version numbers are in perfect sync.
The "standalone" column shows what `uname -X` would have displayed, at
least in those versions which supported that flag. I believe it was
added in 3.2v2.0. Before that you would have had to look in places like
/etc/perms/rtsmd and the kernel startup messages in /usr/adm/messages;
`uname -a` always showed "3.2 2" meaning "3.2[AT&T SysV release number]"
"2[AT&T tape update number]" -- it took until 3.2v2.0 before the
pressure from Support to get identifiable version numbers out there
overcame Engineering's fear of AT&T reprisal for touching what was seen
as a sacrosanct AT&T version number.
(**) Due to internal politics and development schedules, the base OS
identified as "3.2v4.1" in the Unix 3.2v4.1 standalone was moderately
different from that in ODT 2.0. Each had some components which were
newer than the other. These didn't properly synch back up until
3.2v4.2 / ODT 3.0 shipped.
(*) Two of the best, or at least most interesting, that I found are:
http://williambader.com/museum/dell/xenixhistory.html
(moderately good coverage of Xenix history, though I doubt the
congruence between AT&T SysV release subversions & Xenix versions;
plus Unix / OpenServer, gets some of the version mapping wrong and
the one date that I'm pretty sure about -- OSR5.0.0 in 1995 -- is
wrong here)
http://www.tkrh.demon.co.uk/scod.html
(sparse on UW7 releases; stops before OSR507; mapping between Unix &
ODT versions is wrong in many cases)
>Bela<
Pepe
> [ksh] [ttyp0] [root] [/]
> -> uname -X
Hello.
Very niche prompt that you have there. Would you share the Korn Shell
recipe for it?
> System = comix
> Node = comix
> Release = 3.2v4.2
> KernelID = 93/04/28
> Machine = i80486
> BusType = ISA
> Serial = sco006640
> Users = unlim
> OEM# = 0
> Origin# = 1
> NumCPU = 1
>
> Incidentally, this ODT box has been in service continuously since
> about 1989. It's currently a 486DX2/66 with 8MBytes ram and a Conner
> 1080s 1GB drive. Fast, efficient, reliable, cheap, etc... I keep
> waiting for it to die so I can replace it with something better.
Amazing. Is it an stand-alone machine, or is it networked to ethernet?
Even more amazing is that you can run all that time with such an small
HDD, and not filling it up!
Pepe
> `uname -a` always showed "3.2 2" meaning "3.2[AT&T SysV release number]"
> "2[AT&T tape update number]" -- it took until 3.2v2.0 before the
> pressure from Support to get identifiable version numbers out there
> overcame Engineering's fear of AT&T reprisal for touching what was seen
> as a sacrosanct AT&T version number.
Bela, I have always wondered why did SCO kept their Unix at SystemVR3.2
and then spent a lot of engineering effort to replicate in-house the
features from SystemVR4 (except on-demand loadable drivers and never
getting an advanced filesystem, among others), while all the competitors
happily licensed SystemVR4 and devoted their engineering efforts not to
catch-up but to add differentiation and unique features to their UNIXes...
I mean, while SunOS grew from a little BSD-derived UNIX to be a fully
SystemVR4.2 UNIX and was ported to the SPARC and was made to support
hot-swappable hardware, SCO Unix stayed frozen in SystemVR3.2 and went
slowly adding features to almost get up-to-par with vanilla SystemVR4.
SUN Microsystems surpassed SCO by far, but it could have been a totally
different story.
Could you share some light on those issues?
Thank you.
Jeff Liebermann
>Jeff Liebermann wrote:
>> [ksh] [ttyp0] [root] [/]
>> -> uname -X
>
>Hello.
>
>Very niche prompt that you have there. Would you share the Korn Shell
>recipe for it?
Sure. Methinks (not sure) that KSH ish required.
This is from my $HOME/.profile file.
# setup prompt
PS1="\!> [$(logname)\@$(hostname)] [$(basename $(tty))] \$PWD
=> " # set the main prompt on 2 lines
I dumped the whole mess on my web pile. See:
http://www.LearnByDestroying.com/sco/profile
http://www.LearnByDestroying.com/sco/kshrc
Feel free to borrow, etc.
--
Jeff Liebermann je...@cruzio.com
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558
Pepe
> Sure. Methinks (not sure) that KSH ish required.
> This is from my $HOME/.profile file.
>
> # setup prompt
> PS1="\!> [$(logname)\@$(hostname)] [$(basename $(tty))] \$PWD
> => " # set the main prompt on 2 lines
Thank you very much.
Bela Lubkin
Most of the decisions had been made before I started at SCO in 1989, I
was only aware of them as historical fact + how they were reiterated at
later points.
SCO's relationship with the then-current owners of the System V source
code (AT&T, USL, or whoever they were at that point -- definitely not
yet Univel or Novell -- I'll call them AT&T as shorthand for "whoever")
-- was always uneasy. AT&T insisted that if SCO shipped a development
system, AT&T had to be paid for it -- that's why the dev sys was
unbundled. They also insisted on separate payment for the text
processing tools (troff and related materials) -- that's why the text
processing system was unbundled.
When AT&T offered SVR4 to SCO, the terms were unacceptable. They wanted
too much money per shipped copy. Probably so much that SCO would have
had to charge $5000 or more per copy to make a profit. I think -- but
this was only my inferred understanding from oblique comments -- that
part of the reason for the high price was that AT&T was going to insist
that SCO re-bundle the development and text processing tools, but still
pay for them on each shipped unit.
Meanwhile, other SVR4 vendors had better deals; certainly AT&T
themselves, and Sun. SCO didn't feel that they could compete pricewise
against the other SVR4 vendors if they agreed to AT&T's terms. So they
instead set out to replicate enough of the features to allow SCO Unix
System V Release 3.2 to stay a viable alternative. Remember that SCO
Unix 3.2.0, the first release fully based on SVR3.2, shipped in 1989.
SVR4 was [according to wikipedia, which I believe is right] announced in
1988 and shipped in 1990.
If you follow the history from that point, SCO's decision wasn't
necessarily a bad one. Their SVR3.2 based system dominated the Unix
market on Intel for many years. Today, Solaris x86 is probably much
bigger, but that's a recent development. And of course Linux is much
much bigger, but that's also a relatively recent development; and also,
technically, at some level, not part of the "Unix market". SCO's span
of dominating the commercial-closed-source-Unix-on-Intel market was
long.
Closed source is significant there because, as you can tell from later
behavior, SCO was never going to strongly buy into the open source
concept. They were never going to ship a Linux-based system. I
intentionally ignore both the Caldera Linux products that came in when
Caldera bought (and then was swallowed by) the SCO Unix groups; and the
UnitedLinux effort that came thereafter. Caldera Linux was quickly
deprecated and ignored by SCO; UnitedLinux was mostly stillborn. They
serve merely as examples of what I mean.
SCO Unix System V Release 3.2, which eventually became OpenServer, never
did reach technical parity with SVR4. It was far less elegant in many
areas. But it managed to hit enough of the checkmark items and
highlights -- like support for 4GiB RAM, SMP, TCP, NFS, X11, C++, WWW
browser, Perl, Unix brand certification, C2 security certification, etc.
-- to compete well against the SVR4s. It also helped that hardly anyone
put a serious marketing effort behind SVR4. There was a whole list of
also-rans like Dell, ISC, ESIX, UHC, Consensys, Microport, that never
took significant market from SCO. The only moderately successful Intel
SVR4 was USL -> Univel -> Novell's UnixWare. And that was only
moderately successful, not significant enough for Novell to hold onto in
the end, so as everyone knows, they sold that business off to SCO.
Sun was definitely successful with SVR4, but remember that this success
was purely on SPARC until much later in the game. Competition between
x86 Unix and other-CPU Unix was much less direct, being aimed at rather
different markets. Also remember that Sun was one of the codevelopers
of SVR4, with AT&T / USL. I don't know what their licensing terms were,
but I imagine that as codevelopers they were very favorable. Between
being able to charge far more for their boutique hardware and presumably
having much lower software license costs, they could go far.
386 was one of the early ports of SVR4. I've heard rumors that
throughout the history of Solaris 2.x (Sun SVR4) on SPARC, they also
maintained a working 386 port; much later, after a lot of polishing,
they were able to release this as Solaris x86. [I've also heard rumors,
even stronger, about Apple having maintained a full MacOS 386 port
through the PowerPC days; and of course we see where that went.]
Solaris x86 got an early enthusiastic reception, but still took years to
become a serious force in the x86-Unix market. It didn't help that Sun
at one point announced end of life (quickly retracted after it caused an
uproar).
One thing that did probably help a whole bunch was when Sun, with (paid)
permission from SCO, was able to open source Solaris. I imagine that
the open sourcing of Solaris helped contribute to declining SCO sales
(eventually); but of course the immediate benefit of Sun's payment might
have kept SCO afloat. (I should be very clear here that I had little
or no SCO financial information beyond what was publically disclosed in
quarterly reports, press releases etc. Nor was I involved in decision
making; I only inferred or heard internally some details about why
decisions were made.)
Meanwhile, just why was SCO Unix successful over all those SVR4s? I
think a large part of it was SCO Unix's backwards compatibility with SCO
Xenix. A lot of work went into making sure user-level commands, file
locations, system calls, and installation methods were compatible with
Xenix. This allowed the large installed base of Xenix systems, and the
large ecosystem of 3rd party products and ISVs to migrate easily. There
was also a compelling reason to abandon Xenix (16MiB maximum RAM).
Essentially the same reason kept SCO in the lead for a long time. They
were very careful to preserve backwards compatibility. Every change was
considered in the light of what effect it would have on older
applications. For years I thought of backwards compatibility as SCO's
core competency. Other OSes may speak the same language, may claim to
have similar intentions, but they were not as steeped in the desire and
intent to retain backwards compatibility. Of course there were some
errors over the years, so compatibility breaks. When discovered, those
were treated as emergencies, repaired as quickly as possible.
A second important reason was a focus on replicated site businesses.
There must have been some amazing sales people to make it all happen.
There was a time when a SCO box ran every store of at least 8 of the top
10 fast food franchises, most of the big drug store and grocery chains,
several top tier car manufacturers' dealships, and all sorts of other
huge chains. I imagine a fair number of those chains are still running
the same replicated installs even today.
These two reasons were not unrelated. The large chains appreciated that
SCO's product line was committed to being old and backwards compatible.
Upgrading 5000 stores is a Big Deal, taking careful planning,
significant manpower and cost. These sites look at Linux and see a
system that casually breaks compatibility at every level, repeatedly.
Linux seeks internal and external elegance, and does so over
compatibility. There's nothing wrong with that, it certainly produces a
more refined system at any point in time, but it makes it difficult for
replicated sites to deal with. Even Windows server releases change
significantly over the years. SCO moved slowly and carefully.
It even took them 10 years to fulfill the original promise of the
SVR4 purchase by releasing OpenServer 6, which is basically a port of
the OSR5 user space to the much more modern UW7 / SVR4+ kernel. That
couldn't really happen until many compatibility issues had already been
fixed in successive UW7 releases. There's no way the installed base of
OSR5 customers would have accepted it. It's still debatable whether
OSR6 is compatible enough to be accepted. There was too much other
stuff going on at the same time for the "experiment" to be considered
clean -- we can't go back and run a control batch where SCO doesn't
buy SVR4, doesn't fix UW compatibility issues over the years, doesn't
eventually release an SVR4-based OpenServer...
> spent a lot of engineering effort to replicate in-house the features
> from SystemVR4
That effort probably amounted to about 500 engineer-years (estimated
by integrating SCO engineering size over time, accounting for other
projects that would have cost engineers anyway). If we assume
an engineer-year cost about $100K during those years, that's $50
million, which sounds like a lot. I don't know how many total SCO
Unix...OpenServer licenses SCO shipped, but I know it was over a million
and I think close to 2 million. The feeling I got was that SCO was
going to end up paying AT&T something like $400/license for SVR4, so
that would have been perhaps $600 million. So again, as a pragmatic
business decision, it probably made a lot of sense.
You might ask, couldn't SCO have gotten a better deal with that sort of
sales volume? I got the impression that there was a certain amount of
personal bad blood between top SCO officers and the people they needed
to negotiate with at AT&T. There was a feeling that yes they _might_
be able to get a better deal, if they could _promise_ a certain rate
of licensing up front, but that it wasn't worth betting the company
on. The deal they were going to get without promising specific license
counts was much worse. Due to the personal animosity, there was a
strong feeling that it wouldn't be possible to negotiate a better deal,
that if SCO committed to SVR4 then AT&T would have them over a barrel;
able to force any sort of bad deal they wanted. (Again, I should note
that I didn't factually know about any such personal animosity, it's
just a feeling I picked up over the years from conversations in the
hallway.)
> except on-demand loadable drivers
Like many other SVR4 major features, this was sort of half-heartedly
covered by SCO OpenServer, addressing enough of the customer pain points
without delivering the full elegant solution. For loadable drivers, SCO
developed the Boot Time Loadable Driver spec for loading new drivers at
boot time, allowing installation onto novel hardware without getting a
new boot disk from SCO; and dynamically loadable X11 display drivers
(possible because those were really just user-level libraries). BTLDs
really addressed the main pain point. Since there was no hotplug
hardware support, it didn't matter if you had to reboot to add a NIC
driver. You also had to power down -- and then necessarily reboot -- in
order to take the cover off the server and plug in the new NIC.
> and never getting an advanced filesystem
OpenServer 5.0.0 added two new filesystems which were supposed to be
"advanced". They were HTFS (High Throughput Filesystem) and DTFS
(Desktop Filesystem) from Programmed Logic Corp. SCO had looked at VxFS
and probably one or two other choices, eventually choosing the contender
that offered the best tech for the least cost. HTFS was intended to be
a high performance high reliability filesystem. Compared to the
previous SysV filesystem, it delivered those features. It had a
metadata journal, eliminating most costly fsck runs. DTFS had support
for compressing files on the fly, conserving space on desktop systems
that typically had barely adequate hard drives. It was promised to have
a lot of other features later on, things like encryption and
snapshotting. I believe that PLC did go on to develop those features on
DTFS, but only on their SVR4 port, so SCO never picked any of them up.
OSR5 also had a software RAID solution (from NCR), intended to fill the
role of a volume manager like Veritas VxVM.
> hot-swappable hardware
Hot-plug PCI support was added, in concept. It required a
vendor-specific hotplug bus driver, which I believe only Compaq and IBM
ever delivered. Then I think those vendors didn't pay much further
attention to OSR5 hotplug support, so if there was any end-to-end driver
support (allowing admins to actually take advantage of hotplug with
specific hardware), it was for early boards that soon fell off the
market.
One other topic that I should probably insert somewhere above, but I
couldn't figure out exactly where. Remember that when Solaris came out,
Sun's customers were somewhere between wary and contemptuous. It took
several 2.x releases before existing customers got any comfort with it.
This despite the fact that Sun was on of the two core designers of SVR4.
The SunOS -> Solaris transition was in some ways similar to the OSR5 ->
OSR6 transition, except Sun was prosperous enough during the necessary
period to pull it off. Once the transition was reasonably solid, Sun
was able to focus their considerable engineering talent on Solaris,
bringing it to where it is today. It could not be anywhere near as
advanced as it is now if Sun hadn't been prosperous for a long time.
SCO wasn't, and its engineering efforts suffered as a result. Who knows
what OpenServer would be today if its engineering team hadn't been
continually shrinking for 12+ years.
Well, I've been rambling on this in fits and starts for two days, this
probably isn't very coherent, but I hope it helps you understand how
things got the way they are.
>Bela<