> We are trying to decide whether we should switch to Solaris 2.X
> this summer or next summer. I'd be interested in hearing what
> other academic sites are doing with respect to this decision.
> Please include your decision and the major reasons why you
> made your choice.
Here's the summary:
Full transition this summer 6
Full transition if they don't switch to SGI 1
Full transition if required 3rd party apps ready 2
Partial transition this summer 1
Solaris 2.x for classics and LX's only 5
Waiting until next summer 6
No answer, advises waiting 1
Almost all of the respondents have tried Solaris 2.1 and many report
significant problems. There seems to be a great deal of hope that
Solaris 2.2 will be much better.
There seems to be a consensus that the transition will be much easier
next summer and that you should wait if you don't need MP or low-end
(Classic and LX) machines until then.
The full responses follow:
From: "Jim Davis" <email@example.com>
I'd wait if you can.
SunOS 4.1.3 is very stable, and there's tons of free stuff (GNUware,
etc) and commerical applications ported to it.
Solaris is relatively new and still a little buggy. Not as many free
programs or commerical apps have been ported yet -- within a year I
suspect that won't be a factor, and the bugginess problem should be
The drawback to waiting is that the LX and other new boxes have to
have Solaris; SunOS won't run on them. So if you're thinking about
buying new Sun hardware in the next year you're going to have to get
into Solaris, at least on the new boxes.
I think Sun's shift to Solaris and away from SunOS was a marketting
decision more than a technical one -- Solaris does have a few
advantages but I don't see it as markedly superior to SunOS. Sooner
or later you will have to switch, but unless you have new hardware
purchases coming up I'd be inclined to wait. Let someone else smooth
out the rough edges -- it's still pretty early in the Solaris life
From: Robert Allan Zeh <firstname.lastname@example.org>
Here at the U of I math department we (well, I) are already running
Solaris 2.1 on our big server, and I am hoping to have switched all 30
or so Sparcs to Solaris 2.x before the start of next semester.
The only thing that's stopped me so far is that some of our important
commerical software won't run under Solaris --- Mathematica and
Maple are the prime offenders --- most of the free stuff will compile
and run under Solaris 2.1.
I'd have already switched over to Solaris 2.1 by now if it wasn't for
Mathematica and Maple. Delaying the changeover is only going to cause
more trouble --- I'll only have more users and machines in the future.
I've clearly got to switch over to Solaris 2.x, and the sooner I do it
the better (not excepting bugs in the OS; I've heard 2.2 is fairly
From: Bob Dowling <email@example.com>
We have three SparcServer 4/690 MP's providing our "Central Unix
Service" with ~1700 registered users and several expensive "glossy"
commercial applications. (We buy them for us rather than have every bit
of the University buy their own and then everyone uses ours.)
We cannot move our three machine to Solaris 2.x this summer as too few
of our glossy applications have been ported. We plan to move to Solaris
2.x next Summer (ie 1994). We have an additional problem which is
colouring our opinions, though. Our 3 current machines are showing
their age and will probably not be able to withstand the additional 1500
users we anticipate over the next 12 months. (We are decommissioning our
3084 in 1995 and encouraging users to start up elsewhere now.) However,
we cannot keep stuffing memory and multi-CPU boards into the current
machines without moving to Solaris 2.x.
So we plan to start up a parallel Unix service under Solaris 2.x. This
will initially only run PD software, but we hope this will divert some
of the load from the other machines by offering a faster platform for
people only running the PD stuff. As the "glossies" become available
for Solaris 2.x we will install them on the new system and hopefully, by
Summer 1994 it will be offering all the facilities currently offered by
the current Solaris 1.1 machines at which point its use gets changed to
being a plain file server and network facility provider rather than
This assumes we get the funding. If we don't then we stick with Solaris
1.1 on the current three machines which progressively run more and more
like a drain as the number of users increases and in the Summer of 1994
we have a ghastly rush to make the transition from Solaris 1.1 to 2.x
and we insert all the extra hardware that then becomes available to us.
From: rusty@zirkel.CFNR.ColoState.EDU (Rusty Scott)
Our lab facility here at CSU focuses heavily on GIS/Remote Sensing applications.
Because of that we are bound (heavily) to 3rd party software such as
ARC/INFO, ERDAS, Genasys, etc. Most vendors are talking about summer
releases of their software, Erdas is talking November. This summer is
pretty unstable in the software scene, so I'm actually thinking about doing
a Christmas break move here, since the studentia will be gone for 5 weeks.
If something gets in my way, it'll be summer '94.
From: misawa@physics.Berkeley.EDU (Shigeki Misawa)
Hi. I'm not an official spokesperson for UCB but I can say a few
things about the subject. One of the major sticking points with going
to Solaris here on campus is the license manager situation.
Apparently, all the new SunPro software (mostly compilers) use
FlexLM. According to the computer support people here, the increased
paperwork needed to deal with licensing makes an upgrade to new
versions of SunPro stuff (and hence Solaris 2.x) unlikely. This
license manager problem is apparently a major sticking point with many
.edu sites. It might be wise to contact some of the other major .edu
sites and talk with them about the license manager issue.
From: James A de Haseth <firstname.lastname@example.org>
We believed Solaris was the most cost-effective solution. I have the
first & only SPARC solaris 2.1 on campus, and I have been on the
bleeding edge. The product is pretty solid, it's just the
documents that are too few and have too many errors.
I suspect we will have others in the not too distant future.
From: email@example.com (Ken Mandelberg)
We switched our main student lab and 690-140 server to Solaris 2.1
in January 93 on our semester break. Our expectation was to switch
our faculty/staff machines a few weeks later, leaving a handful
of Solaris 1.X machines for applications that were hard or impossible
The motivation for the decision was two fold. For the MP server we
were expecting a big performance boost from the SMP support. On the
workstation side we had already acquired a number of classics
and wanted to support only one version of the OS. We believed the
Sun marketing line which at the time characterized Solaris 2.0 as
a developers release, with 2.1 the end user release that solved
the 2.0 bug and performance problems.
What became apparent after the initial switch, was that Solaris 2.1
was itself very buggy and had bad performance problems. The printing
software was basically unuseable. Workstations had to be rebooted
multiple times a day to solve printing hangs. Server panics were
frequent and the patches often made things worse. We have 10 open
calls at the moment. The turnover of hotline people is rapid, we have
had 2 and 3 contacts on some calls as the hotline people change jobs.
Sun has been late in supporting their own hardware. For example,
despite the fact that Prestoserve support was announced as tested
and available in the Solaris 2.1 announcment, it actually was not
available until May.
I attribute some of our problems to our configuration. Because of the
way we have done upgrades we have many diskless workstations, a server
with IPI/VME disks and a Cypress MP. This is apparently not what Sun
concentrates on in its testing. Others with more common configurations
may do better.
We never did the second cut of conversions because of the problems.
Our hope is that Solaris 2.2 will solve many problems. Our plan is
to upgrade to 2.2 at FCS in late May, and covert the rest of our
machines if it seems stable.
From: firstname.lastname@example.org (Scott Budge)
We are switching to Solaris 2.2 this summer. The reasons are as
1. We need to upgrade before the new school year. Upgrading in the
middle of a quarter is a disaster (as you probably know).
2. We have surveyed the vendors who provide software for our College
of Engineering computer lab and found that all are in the process of
porting their software to Solaris 2.x. (Some are not porting until
Nov. timeframe, but it acceptable in our curriculum.) If we wait too
long, we will not have the new features of the software available to
3. We offer graduate classes in multiprocessing and would like to have
the threads library available to us for class assignments.
4. Our research in areas that require intensive computation can
benefit from the multiple CPUs available in our servers.
5. The University as a whole would like to set up the NIS+ to prepare
for University-wide distribution of upgrades.
6. We want to stay on the leading edge of software.
7. We now have an LX and had to go to Solaris 2.x on it.
8. I have upgraded my own machine and found the upgrade to be LESS of
a problem than I thought it would be. There is a performance drop
(with 2.1), but not too bad, and the next release (2.2) is supposed to
be much better. I like OpenWindows better in Solaris 2.1, and find
the differences in the admin commands fairly easy to get used to.
There are the usual glitches, but nothing major.
From: email@example.com (Grant Basham)
I manage a small clutch of suns (~20) for the engineers here (along
with a larger number of dec vax&mips&alpha vms&unix boxes). The
faculty member in charge of the sun boxes has a bug on to do the
transfer. They are fully warned that much won't work and some of the
third party software is not available yet (Matlab). And that
openwindows 3.0 under solaris 2.1 may look the same to them, but
SystemV.4 doesn't look the same to their sysfolks. I don't think my
idle bitching has made much of an impression. They are confident that
Grant and Sun can straighten out any problems that might arise. Ha.
They are not terrified of some down time in midsummer. I will
probably have to take a run at it in July if Solaris2.2 is out and
Matlab has been adapted. Next summer is a MUCH saner time to try it.
From: Richard Elling <Richard.Elling@eng.auburn.edu>
We are already moving to Solaris 2.x. Mostly because edu sites get good
discounts on SPARCclassics. We've already got about a dozen or so installed
and integrated into the network. We've also identified a number of machines,
mostly old 4/280s that we will never upgrade.
What I foresee happening is that there will be a large number of good reasons
to upgrade many machines before the fall. These are:
1. user level support for removable media (floppies)
2. better compilers
3. SMP support
5. support for 7 SCSI disks per SCSI controller on servers
The only real reason not to upgrade will be support of existing applications.
Depending on the app vender, whether or not there is an upgrade path, and
the [non]existance of a maintenance contract will play big here. Some apps
work ok, others are statically linked or otherwise won't work in binary
compatibility mode. We have a *lot* of applications on the net here, some
will probably never be upgraded :-(. So our plans include keeping a few old
machines to run old apps on.
From: Moses <KIRKHAM@kuhub.cc.ukans.edu>
We just received a lab of Sun Classics so we were forced to adopt the
the new operating system (Sol 2.1). Hopefully we will be able to pitch this
one out the window soon. We will be upgrading to 2.2 as soon as I can lobby
for some money.
Before these new machines arrived (late I might add) we had 5 Sun boxes happily
running OS 4.1.1 and are destined to continue unless 2.2 is a major improvement
over 2.1. My advice would be to wait. At the very least don't upgrade to
Solaris 2.1. The OS has too many bugs to be useful. I ha[1~ve heard that 2.2 is
a much better platform, but then again anyone running 2.2 now must be in
pretty good with Sun :-).
From: Dave Curry <firstname.lastname@example.org>
Here at the Purdue University Engineering Computer Network, we are
handling it as follows:
- Anything new which comes in (SPARCstation LXes, etc.) runs Solaris 2.1.
We have ported most of the commonly used stuff in /usr/local/bin, etc.,
and we have configured sendmail and printers and stuff so that they work
in our environment.
The only thing missing is the third-party software.
- Anything old which is currently running SunOS 4.1.1 will not be converted
until Summer 1994, unless the school which owns the systems specifically
requests conversion before then.
We had hoped to migrate this summer, but the lack of third-party packages
has forced us to delay until next year. So, we are trying to make the Solaris
systems interoperate with SunOS 4.x as much as possible. So far, we have
not had too much trouble doing this.
From: Michael Sanderson <email@example.com>
We were going to upgrade one of our undergraduate lab fileservers from a
Sparc 2 running 4.1.2 to a Sparc 10 running Solaris 2.1 this summer. However,
we require that quotas work and Solaris 2.1 and 2.2 do not have working quota
systems. We won't be upgrading that server until the quotas are fixed.
As far as our graduate/faculty systems are concerned, Solaris is being
installed on new desktop machines that don't export file systems. We haven't
purchased any new fileservers recently. Everything else still runs 4.1.x and
it doesn't appear that we will upgrade in the near future.
Basic reasons are:
- we are moving to a new building sometime in the summer and have
enough other things to do.
- Solaris is different and there hasn't been any strong request from
users to get it installed. Too many people that like the Berkeley
feel of 4.1.x.
- The 4.1 compatibility mode seems too slow. We need to get several
more software packages compiled for Solaris. We currently have basic
things recompiled (gemacs, gdb, X11R5), but much of the extra utilities
haven't been done yet.
- Time needs to be spent to configure kernels and disk partitions
nicely to get some extra performance and get rid of things that we
- It seems that there are still too many weird things in 2.1 (bugs and
otherwise) that will be fixed with Solaris 2.2 or 2.3.
It boils down to inertia and the fact that we are facing a move in the near
future, making use face other problems we will have to deal with. Introducing
Solaris at this point doesn't seem like a good idea.
I'm currently running a Sparc LX with Solaris 2.1 and it seems alright. It
takes some time to get accustommed to the SYS V flavour (though if your path
is right, you can avoid alot of it). There are bugs in 2.1 but most of the
ones you can't live with have patches available.
From: firstname.lastname@example.org (Tony Wood)
We (Academic Computing Services) at UCSD won't
likley be switching until Summer '94. There
are simply not enough applications ported, both
commercial and public domain. We doubt that
this will change in the next month or so.
From: John DiMarco <email@example.com>
We're planning to switch at the end of this summer (before the fall term)
because our current compute server (690-140) is inadequate, and we want
to turn it into a 690-54.
From: "Steven Davis" <firstname.lastname@example.org>
The Mathematics and Applied Mathematics computer systems at Cornell
University are waiting until next summer to upgrade. I believe
the reasons are as follows:
(1) Stability: Most of the systems involved are the property of
individual professors or research groups. Our shop
works fine so long as pretty-much everything works,
but our jobs would be at risk if forced people to
switch to Solaris at this point.
(2) Third party software: As long as the big packages aren't available,
(Maple, Cayley, Publisher), the main servers must be
kept with BSD which makes politically impossible to
change anything else.
(3) No point: At the current time, there doesn't seem to be any
reason to want to change.
(4) PC undertoe: Unfortunately people are too quick to believe
advertising claims and first impressions. We fight
against a sentiment that it would be much cheaper,
easier, and more reliable to fire the computer room
staff and replace all the computers with Mac's. My
experiences have always been that this is far from
the true, but if we switched all of the machines to
Solaris, all of our explanations who be paled by
the apparant evidence that workstation station
designers are more interested in esoteric subjects
like OS history than in getting work done.
From: "Adam W. Feigin" <email@example.com>
It really depends on what you mean by "switch". I will assume that you
dont mean over the period of 1 week (or somewhat) that you install
Solaris 2.x on every machine, and you kiss Solaris 1.x goodbye.
We have a large amount of 3rd party software that does not yet run
under Solaris 2.x; we cannot, therefore, make the switch until the
majority of packages do run. In addition, our local software (2 and 3
dimensional semiconductor device simulation software) has yet to be
ported to Solaris 2.x.
What we've done in out institute is to set up a single machine with
Solaris 2.x (2.1 currently) so that people can get used to doing
things in the "politically correct manner" (aka the SVR4 way) before
making the switch. I suspect that we will switch some machines to
Solaris 2.2 towards the end of the summer, and make the big switch
next summer, when new hardware rolls in.
In addition, the question of network licensing of SunSoft compilers and such
has yet to be answered to our satisfaction. Basically, we're not going
to commit to making the switch to Solaris 2.x until Sun can answer
these kinds of questions.
Do you have any 3rd party Sbus boards in your machines ? If so, does
the 3rd party have drivers for them ?
These are all things that must be considered before making the
decision to switch....
Finally, we're rather disappointed with the performance of Solaris
2.1. On similarly configured machines running Solaris 1.1 and Solaris
2.1, the former "feels" faster and has better response times than the
From: firstname.lastname@example.org (Tom Bradshaw)
Our site will not likely be moving until next summer. The main reason
is software. Some of our software we our currently running will not be
available until late this year or sometime in 94. The other reason is,
there is nothing we currently need in Solaris 2.X that 4.1.X does not
provide. We do have about 5 LXs running Solaris 2.1 that will provide
a Solaris environment in case someone wants it.
We currently have about 30 Sun3s and 50 Sparcs in the departement. The
Sun3s will turn into Xterminals and be supported by 3 Sparc10s.
From: email@example.com (Dan Revel)
We already have some machines running 2.1 (Classics->no choice,SS10s->naivete).
I am not satisfied with the product - it is very frustrating to go from a
relatively stable and mature 4.1.3 to a very buggy 2.1.
I talked to one of Sun's support people who implied that the 2.1 release was
intended for developers to give them a platform for product porting, 2.2
should be better.
If it were my decision I don't think I would be going to 2.x this summer
unless there were some pretty good reasons (e.g. 2.2 proves much more
robust and bug free). You'd be better off living with two OS's 4.1.3 on
older suns and 2.x on new SPARCclassics than to switch now.
From: firstname.lastname@example.org (Wolfgang Ratzka)
This Decision is still ahead of us. But maybe I share the discussions
going on here. We have Solaris 2.1 running on a newly installed
Computer pool (11 machines, SPARCclassics --- so no choice) meant for
the use by students, whereas the bulk of our machines (~50 ) run
The Solaris pool (which was meant to be a test case for the coming BIG
CHANGE ;-) has proven rather unstable (quotas won't work, the server
crashes twice a day, user administration is buggy...). Now we are
waiting, how version 2.2 turns out.
Our timing in switching to 2.X is however determined by another coming
event. The physics department is going to buy another ~40 machines. As
the number of machines is fixed and monetary resources are limited,
most of these have to be SPARCclassics --- again no choice. As we
would hate to live with a heterogenous network, the arrival of these
machines would set an upper limit for the time to switch.
If version 2.2 does not turn out much better than 2.1, the question
will be, whether the 40 new machines still will be SUNs. Our
computing center has recently decided on bying a compute server by
SGI, and SGI is going to announce new low-prized products next month.
This just to show how bad the reputation of Solaris has become here...
From: email@example.com (Ronald G Minnich)
well i have 32 classics and more on the way. We have to use solaris on those.
Everywhere else though it looks like we are going to wait a while:
1) our cad software won't run under solaris
2) we don't have Frame for solaris
3) all of our experimental os hacks (e.g. MNFS) won't run under solaris
4) Condor won't run under solaris
And (3) and (4) will not be easy.
what fun this will be. If you possibly can wait, your life will be easier ...
From: "Bob Cunningham" <firstname.lastname@example.org>
We're running a mixed (SunOS4.1.* aka Solaris1.1 v. Solaris2.1/1) setup
at the moment. Frankly, I wish I'd waited until the summer to do this.
By fall, I hope to have most systems running Solaris2, but if and only
if we can get Solaris2 versions of the 3rd-party software we routinely
use here. That includes: Matlab, Mathematica, Splus, Lotus123, etc.
Lots of those vendors aren't shipping Solaris2 versions of their
packages yet. Sigh.
Plus we still need to get/craft Solaris2 versions of a lot of the
"public domain" software we use. Most of the GNU stuff comes
up fine (thanks to the new "configure" setup) under Solaris2.
A lot of other stuff doesn't, yet.
The other reason we may hold some systems at Solaris1 has to do with
various and sundry 3rd-party peripherals. In some cases we may
never be able to get the necessary Solaris2 drivers and so we'll
have a few systems running SunOS4 indefinitely.
Otherwise, well we skipped Solaris2.0 (and I wish we'd skipped 2.1),
but 2.2 is pretty nice.
I'd recommend "getting your feet" wet this summer, and taking it step
by step while discovering where the pitfalls lie for your own environment.
I don't think it's unreasonable to convert almost entirely by the fall.
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:07:50 CDT