What's new in Solaris 2.5?
Mark Thomas
What are the new features of Solaris 2.5? It doesn't
seem that long ago that 2.4 was released; are there
any major changes?
.------------------------------------------------.
| Mark Thomas <ma...@ipctech.com> |
| Systems Analyst / Network Integration Specialist |
| IPC Technologies Inc. http://www.ipctech.com/ |
`------------------------------------------------'
Ryan Zotovich
Rob Kroeger
: This is a curiosity question more than anything.
: What are the new features of Solaris 2.5? It doesn't
: seem that long ago that 2.4 was released; are there
: any major changes?
I seem to recall that Solaris 2.4 was announced around last November
so it's been a while. I think we'll see 2.5 in conjunction with new
hardware (UltraSparc machines) around September (so roughly a year.)
I think that major changes in Solaris 2.5 include COSE, some 64-bit
support (UltraSparc), support for new graphics hardware, X11R6 derived
server, MT thread-safe Xlib, full Asynch I/O support, more complete
POSIX and POSIX realtime support, and perhaps hints of DOE stuff.
But, hey, since I'm allowed to say all this stuff, you know I don't
actually know anything about it. These are just guesses. :-)
Rob Kroeger
Computer Graphics Lab
University of Waterloo
http://www.cgl.uwaterloo.ca/~rjkroege
Jeff Bonwick
New Features:
Hardware support:
UltraSPARC platform support
PCI support
Networking:
NFS Version 3
NFS over TCP
Dynamic IP addressing for PPP
Multithreaded automounter
4.4BSD-compatible telnet
Version 8 sendmail
Faster, cleaner, *much* more robust network file locking (lockd/statd)
Security:
ACLs (Access Control Lists)
NIS+ Password Aging
Standards:
POSIX threads (P1003.1c)
Commands and utilities for SPEC-1170 (XCU4.2)
CDE (Common Desktop Environment)
Kodak Color Management System
X/Open Federated Naming
Performance analysis and debugging tools:
Integrated kernel/user-level tracing tools (see prex(1))
Process analysis tools (see proc(1))
Thread library debugging (libthread_db)
Scoping/versioning linker
Administration:
All-new admintool
Cache-only Clients
cachefs statistics (see cachefsstat(1M))
Features that were formerly unbundled or patched that are now standard:
PCMCIA support
SPARCstorage Array support
Kernel Asynchronous I/O
In-kernel telnetd/rlogind to support hundreds of users
(smaller, faster, and better in 2.5)
Performance Improvements:
Pipes: new pipe implementation 5 times faster than 2.4.
Standard I/O: fread(3S) and fwrite(3S) 4 times faster than 2.4.
Timesharing: dramatically improved due to low-level VM rewrite,
in-kernel telnet/rlogin support, per-processor kernel memory
allocation, and breakup of global locks in ufs, tmpfs and VM.
Name service cache: speeds up name service lookups -- whether from
NIS, NIS+, DNS, or just local files like /etc/passwd -- by two
orders of magnitude (even more for large files or slow networks).
Kernel memory comsumption: reduced by roughly a megabyte on
most platforms (sun4m, sun4d, and i86pc).
SPARC hardware multiply and divide support: most recent SPARC CPUs
provide this, but existing code doesn't take advantage of it.
In 2.5 calls to .mul and .div (etc) are transparently turned
into multiply and divide instructions if the CPU supports it.
NFS: roughly 10% faster.
Window system: 10-20% faster due to fast pipes and reduced
kernel memory consumption.
Compatibility: (bcopy is back!)
Source code:
Popular library routines from SunOS 4.x are now first-class
interfaces in libc:
memory:
bcmp, bcopy, bzero, index, rindex
random numbers:
random, srandom, initstate, setstate
process control:
killpg, getpriority, setpriority, ualarm, usleep,
wait3, wait4, getrusage, getwd, setregid, setreuid
regular expresssions:
re_comp, re_exec
standard i/o:
setbuffer, setlinebuf
miscellaneous:
ftime, getdtablesize, gethostod, gethostname,
sethostname, getpagesize, reboot
Shell scripts:
Popular commands from SunOS 4.x are now in /usr/bin:
arch, hostid, hostname, mach, pagesize
Makefiles:
/usr/ccs/bin/ranlib provided as a simple "exit 0" command.
SunOS 4.x applications:
Dynamically linked apps have been supported since 2.0;
support for statically linked apps was added in 2.3;
support for mixed dynamic/static apps is new in 2.5.
Ship dates:
Preliminary Solaris 2.5 Beta CDs were distributed at the
developer's conference in May 1995. Official Beta CDs
(the same thing plus a few last-minute bug fixes) are
in the works now.
The exact date for Solaris 2.5 FCS (the final product)
has not been set. It should be sometime this Fall.
Disclaimer:
This is not an official Sun document. This is my current
best estimate of the feature content and performance of
Solaris 2.5 based on the features we have integrated
thus far and the benchmarks we have run most recently.
Any or all of this is subject to change without notice.
Jeff Bonwick
Solaris Performance
Pete Hartman
> Version 8 sendmail
I am *excited*!
This is really really good news. And about time, too.
> Security:
> ACLs (Access Control Lists)
Which are?
> Performance analysis and debugging tools:
> Integrated kernel/user-level tracing tools (see prex(1))
> Process analysis tools (see proc(1))
If even half of all these new features actually make it to release,
I think I'm going to be VERY happy with Solaris 2.5. Thanks for the
info!
--
Pete Hartman Bradley University p...@bradley.bradley.edu
"Never mind the roses, just read the card!"
Casper H.S. Dik
>> Security:
>> ACLs (Access Control Lists)
>Which are?
Access control lists are an extension to the standard file modes.
They allow you to give multiple groups and users extra access
permissions to files and make it possible for files to inhereit
them from the directory they're in. (Must more flexible than
multiple groups). They've been in many OSes for years.
Casper
--
Casper Dik - Network Security Engineer - Sun Microsystems
This article is posted from my guest account at the University
of Amsterdam. My real-life e-mail address is: Caspe...@Holland.Sun.COM
Opinions expressed here are mine (but you're welcome to share them with me)
Minh Tran-Le
a) It seems that program bss (non initialized data) are not initalized
any more to 0. I know that you are not supposed to rely on it, but
it still broke some of our code that was running correctly under
solaris 2.4
b) The unix kernel is not any more /kernel/unix. I don't know where
it has been moved. We were using it to figure out KERNELBASE_DEBUG.
Minh Tran-Le.
Paul Eggert
>a) It seems that program bss (non initialized data) are not initalized
> any more to 0. I know that you are not supposed to rely on it....
Why can't you rely on it? The C Standard requires that uninitialized
static variables be set to 0 at program startup, and both SunPro cc and
gcc implement this by putting them in bss. Surely, if bss isn't zero
in Solaris 2.5 beta, it is a bug not a feature.
Roland Schemers
> it has been moved. We were using it to figure out KERNELBASE_DEBUG.
>
It should be under:
/platform/`uname -i`/kernel/unix
roland
--
Roland J. Schemers III | 2550 Garcia Avenue, MS MTV14-210
Member of Technical Staff, SunSoft | Mountain View, CA 94043-1100
Roland....@Eng.Sun.COM | (415) 336-1035 (phone)
sche...@Leland.Stanford.EDU | (415) 336-3156 (fax)
Casper H.S. Dik
>Other changes that I found with solaris 2.5:
>a) It seems that program bss (non initialized data) are not initalized
> any more to 0. I know that you are not supposed to rely on it, but
> it still broke some of our code that was running correctly under
> solaris 2.4
You should be able to realy on the fact that the BSS is zero.
If it isn't , lots of programs will break.
The stack is a different matter, though.
>b) The unix kernel is not any more /kernel/unix. I don't know where
> it has been moved. We were using it to figure out KERNELBASE_DEBUG.
You shouldn't need to access /kernel/unix or wherever it is now.
The kernel namelist is in /dev/ksyms, but many kernel statistics can
be access through /dev/kstat. (e.g., loadaverage)
Bryan Althaus
: Here's a brief summary of the high points:
: New Features:
: Networking:
: NFS Version 3
: NFS over TCP
: Dynamic IP addressing for PPP
: Multithreaded automounter
: 4.4BSD-compatible telnet
: Version 8 sendmail
: Faster, cleaner, *much* more robust network file locking (lockd/statd)
I was lead to believe that Solaris 2.5 would support a IPX/SPX stack?
WABI 2.0 would then be able to use this to access Netware servers as would
the underlying OS.
I really hope this is in there. Solaris x86 being a PC OS needs to live
in a Netware world not to mention the Sparc version. If NT which competes
with Novell has it I can't see why Solaris by now doesn't.
2.5 will not support PowerPC or is that port up to IBM?
P.S. Thanks for the summary Jeff. Sounds like Solaris 2.5 should be even
more solid than 2.4 and CDE was an unexpected surprise!
My $.02 :)
[...]
: Disclaimer:
Jeff Bonwick
> I was lead to believe that Solaris 2.5 would support a IPX/SPX stack?
I think that's already available as an unbundled product.
> 2.5 will not support PowerPC or is that port up to IBM?
Sun is doing the port, but I don't know what the ship date or release
vehicle will be.
Jeff Bonwick
Solaris Performance
Ronald van der Pol
>> 2.5 will not support PowerPC or is that port up to IBM?
>Sun is doing the port, but I don't know what the ship date or release
>vehicle will be.
Will it be merged with the SPARC/x86 source code such that the SPARC, x86
and PowerPC versions of Solaris are identical?
--
Ronald van der Pol Vrije Universiteit
rv...@cs.vu.nl de Boelelaan 1081a
FAX: +31 20 444 7653 1081 HV AMSTERDAM
http://www.cs.vu.nl/~rvdp The Netherlands
a90...@pluto.tiuk.ti.com
:
:You shouldn't need to access /kernel/unix or wherever it is now.
:The kernel namelist is in /dev/ksyms, but many kernel statistics can
:be access through /dev/kstat. (e.g., loadaverage)
Interesting .
Is there an easy way to find total swap available/allocoated this way?
Dr Ivan S. Bishop
poor offering that AIX and HPUX give. ALthough they have some
functionality, they do not (runs for cover) offer anything like the
flexibilty of ACLs under VMS!
Just a passing thought.
--
Ivan S. Bishop
These views reflect those of Ivan Bishop alone (!)
David Robinson
Dr Ivan S. Bishop <I...@legend.demon.co.uk> wrote:
>ACL's in solaris 2.5 GREAT. But, I hope the implementation is not the
>poor offering that AIX and HPUX give. ALthough they have some
>functionality, they do not (runs for cover) offer anything like the
>flexibilty of ACLs under VMS!
What are the lack of capability that makes AIX and HPUX poor
in comparison to VMS? I am interested in what you want from an
ACL.
-David
Doug Gwyn
>> Security:
>> ACLs (Access Control Lists)
>Which are?
If you were into computer security you'd recognize the term.
An ACL specifies the users who are allowed each type of access to a file.
There are various ways of implementing ACLs, some of which make it less
burdensome than others. (For example, the default security policy might
be to resort to the traditional UNIX access mode scheme unless an ACL is
defined for the object, in which the ACL would override the traditional
scheme. Also, contents of an ACL might have to be an enumeration of each
access mode and each user, or it might support groups, wildcards, default
security policy, or various other conveniences.) I don't yet know the
details of Sun's implementation.
>I think I'm going to be VERY happy with Solaris 2.5.
I appreciated the info, too. My question about Solaris 2.5 is:
Since I have not been able to get Solaris 2.4 x86 to work on
my (NCR SDMS) PCI Pentium system, due to some problem with its
access to the PCI subsystem, will I be able to obtain Sol2.5x86
as a free upgrade or will I be ripped off for even more $$ ?
James_Mathiesen
anyone know if that include support for the /bin/login -f ? The
Kerberos version of telnet would work a lot better with it. james
Roland Schemers
It doesn't appear in the man page or usage output but its in the source
and the change was approved. It was added for the reason you mentioned...
Mike Coleman
|If even half of all these new features actually make it to release,
I'd be happy if it'd just show up not so double-dog slow. We're serving up an
OODB via CERN httpd on a Sparcstation 2 w/48MB running Solaris 2.3 and a $1k
486/SX25j laptop w/12MB running Linux. Both versions were compiled with their
"native" (Sparcworks, GNU) compilers using optimization, and both machines
were otherwise unloaded.
Guess which one loses?
Or how about starting up Netscape? Again, the Sun loses against every other
piece of hardware around here, possibly excepting an old Mac IIci. The
problem seems to be that Sun's X drops dead whenever it has to deal with new
fonts.
Rather than seeing bales of new features, I'd rather the core functionality
present in other OSes like SunOS 4.1.3 or Linux was functioning, reliable, and
reasonably efficient in Solaris.
--Mike
--
Mike Coleman * col...@cstp.umkc.edu * http://ctr.cstp.umkc.edu/~coleman (PGP)
**** Center for TeleComputing Research, CSTP, U. of Missouri--Kansas City ****
When you say 'I wrote a program that crashed Windows', people just stare at
you blankly and say 'Hey, I got those with the system, *for free*'.--L.Torvalds
Doug Gwyn
>Since 2.5 is introducing a few "BSD-isms" for compatibility... does
>anyone know if that include support for the /bin/login -f ? The
>Kerberos version of telnet would work a lot better with it. james
Speaking of Kerberos, it would be *wonderful* if Solaris 2.5 were to
bundle in (probably as an optionally installable package) Kerberos-5
support. We are moving to a Kerberized environment here and without
source code it is impossible to do the job right for Solaris.
Jeff Bonwick
If you just want a command to do this, try swap -l.
If you want C code, the program below illustrates the technique.
Compile with: cc -O -o swapstat swapstat.c -lkstat
Jeff Bonwick
Solaris Performance
#include <stdio.h>
#include <string.h>
#include <kstat.h>
#include <sys/sysinfo.h>
/*
* Print out average swap statistics every 5 seconds.
*/
#define DELTA(x) ((double)(new.x - old.x) * pagesize / 1048576 / interval)
main()
{
vminfo_t old, new;
kstat_ctl_t *kc;
kstat_t *ksp;
int interval = 5;
int pagesize = sysconf(_SC_PAGESIZE);
kc = kstat_open();
ksp = kstat_lookup(kc, "unix", 0, "vminfo");
kstat_read(kc, ksp, &new);
printf("%8s %8s %8s %8s\n", "resv", "alloc", "avail", "free");
printf("%8s %8s %8s %8s\n", "----", "-----", "-----", "----");
for (;;) {
old = new;
sleep(interval);
kstat_read(kc, ksp, &new);
printf("%6.0fMB %6.0fMB %6.0fMB %6.0fMB\n",
DELTA(swap_resv),
DELTA(swap_alloc),
DELTA(swap_avail),
DELTA(swap_free));
}
}
Bob Palowoda
: p...@bradley.bradley.edu (Pete Hartman) writes:
: |If even half of all these new features actually make it to release,
: |I think I'm going to be VERY happy with Solaris 2.5.
: I'd be happy if it'd just show up not so double-dog slow. We're serving up an
: OODB via CERN httpd on a Sparcstation 2 w/48MB running Solaris 2.3 and a $1k
: 486/SX25j laptop w/12MB running Linux. Both versions were compiled with their
: "native" (Sparcworks, GNU) compilers using optimization, and both machines
: were otherwise unloaded.
: Guess which one loses?
You because the title of the subject was Solaris 2.5.
I'm sure you have fun with Linux but I though this thread
was discussing new features in Solaris 2.5.
One of the attributes of Solaris 2.5 was that was not mentioned
was some performance improvements in the kernel. I have measured
the performance changes with lmbenchmark and compared them to
the Solaris 2.4 on the same hardware and I am seeing about 18 to
20 percent increase with in kernel memory copies, redecued
context switch times reduced tcp and udp latencies and higher
tcp bandwidth. Compare the results yourself the lmbenchmarks
are available at verious ftp sites. It originated out of
sgi.
Actually 2.4 had a significant increase in performance over
2.3.
---Bob
--
+--------------------------------------------------------+
| palo...@fiver.sns.com http://fiver.sns.com/~palowoda/ |
| Solaris x86 Corner http://fiver.sns.com/ |
+--------------------------------------------------------+
Kevin Clarke
>p...@bradley.bradley.edu (Pete Hartman) writes:
>I'd be happy if it'd just show up not so double-dog slow. We're serving up an
>OODB via CERN httpd on a Sparcstation 2 w/48MB running Solaris 2.3 and a $1k
>486/SX25j laptop w/12MB running Linux. Both versions were compiled with their
>"native" (Sparcworks, GNU) compilers using optimization, and both machines
>were otherwise unloaded.
>
>present in other OSes like SunOS 4.1.3 or Linux was functioning, reliable, and
>reasonably efficient in Solaris.
>
You're running Solaris 2.3. Upgrade and reevaluate the delivered performance
of the product. We have a difficult job making your environment perform
better if you don't track our progress. :^)
---
===============================================================
| Kevin Clarke - Solaris Perf | "To err is human, |
| k...@Eng.Sun.COM | to moo bovine." |
===============================================================
Mike Coleman
|You're running Solaris 2.3. Upgrade and reevaluate the delivered performance
|of the product. We have a difficult job making your environment perform
|better if you don't track our progress. :^)
Yours is a valid point and I realize that the comparison isn't quite fair (or
at least not very scientific).
We'll probably be getting a new Sparcserver (running 2.4, I presume) soon, so
we'll get a chance to see. Unfortunately, we're also getting a 100MHz 586
Linux box. :-)
The Sparcserver *should* win...
Peter C. Tribble
|> In article 802474750@mmsun5, col...@cstp.umkc.edu (Mike Coleman) writes:
|> >p...@bradley.bradley.edu (Pete Hartman) writes:
|> >I'd be happy if it'd just show up not so double-dog slow. We're serving up an
|> >OODB via CERN httpd on a Sparcstation 2 w/48MB running Solaris 2.3 and a $1k
|> >486/SX25j laptop w/12MB running Linux. Both versions were compiled with their
|> >"native" (Sparcworks, GNU) compilers using optimization, and both machines
|> >were otherwise unloaded.
|> >
|> >Rather than seeing bales of new features, I'd rather the core functionality
|> >present in other OSes like SunOS 4.1.3 or Linux was functioning, reliable, and
|> >reasonably efficient in Solaris.
|> >
|>
|> of the product. We have a difficult job making your environment perform
|> better if you don't track our progress. :^)
|>
|> ===============================================================
|> | Kevin Clarke - Solaris Perf | "To err is human, |
|> | k...@Eng.Sun.COM | to moo bovine." |
|> ===============================================================
The Solaris Performance team are out defending their turf, I see. It's
good to know they're out there.
The reality is that for a lot of things (not all, by any means, but if
the part of the OS you use most is one that gets hurt then you notice),
Solaris 2 is significantly slower than SunOS 4. While 2.4 is better
than 2.3, particularly on sun4d where 2.3 was abysmal, it's still not
up to scratch. The things that are slow are very simple things - it's
very obvious that commands like ls, rup are very much slower. I mean, I
type these simple unix commands a lot and it's very annoying to
'upgrade' a system and make it so sluggish.
Now I like a lot of Solaris 2. It makes administration, configuration
and the like much easier. (I even like nisplus!) But we're definitely
paying a price in terms of interactive performance to do this. (As far
as reliability goes, we're reasonably happy with 2.4, as long as we
don't run a recent kernel jumbo patch - rev 27 was unuseable,
apparently rev 31 fixes it but having had to back out we aren't in a
hurry to try again.)
-Peter Tribble
HGMP Computing Services
Jon Tara
>p...@bradley.bradley.edu (Pete Hartman) writes:
>|If even half of all these new features actually make it to release,
>|I think I'm going to be VERY happy with Solaris 2.5.
>I'd be happy if it'd just show up not so double-dog slow. We're serving up an
>OODB via CERN httpd on a Sparcstation 2 w/48MB running Solaris 2.3 and a $1k
>486/SX25j laptop w/12MB running Linux. Both versions were compiled with their
>"native" (Sparcworks, GNU) compilers using optimization, and both machines
>were otherwise unloaded.
>Guess which one loses?
>Or how about starting up Netscape? Again, the Sun loses against every other
>piece of hardware around here, possibly excepting an old Mac IIci. The
>problem seems to be that Sun's X drops dead whenever it has to deal with new
>fonts.
Don't be so sure the problem is the software.
We have a Sun SparcStation IPX and a generic clone 486/66, both
running Solaris 2.4 (the latter running the X86 version of course.)
The 486 beats the pants off of the IPX, and did so even before I
replaced the 33 chip with a 66. The hard drive on the 486 is an
unspectacular old clunker 1GB SCSI drive with an Adaptec 1542B
controller (so it's buffering to get at memory above 16MB). The 486
does have 32MB while the IPX has only 16MB.
I dunno how the IPX compares to your Sparc 2.
The performance of the 486 is *quite* acceptable, and X compares
favorablely to MS-Windows run on the same hardware. AnswerDog doesn't
quite compare to Windows Help, but it loads in maybe 5-10 seconds, vs.
30 or more on the IPX.
Ade Rixon
Pete Hartman (p...@bradley.bradley.edu) wrote:
> bon...@cathy.Eng.Sun.COM (Jeff Bonwick) writes:
> > Version 8 sendmail
> I am *excited*!
> This is really really good news. And about time, too.
Sendmail V8 appears to be available for 2.4 as a point patch (102319). I
only saw it on the updated patch report today; it seems to have slipped out
fairly quietly. Any more details?
Ade_
/
--
| Ade Rixon, Elsevier Science Ltd | http://www.dcs.aber.ac.uk/~ajr/ |
"Yeah when you call my name, I salivate like a Pavlov dog
Yeah when you lay me out, my heart beating louder than a big bass drum"
- "Bitch", Stones
Stephen Meatheringham
|> |If even half of all these new features actually make it to release,
|> |I think I'm going to be VERY happy with Solaris 2.5.
|>
I've seen lots of followup posts like the above to a list of 2.5 features
but have never seen the original post with them listed. Would it be possible
for someone to mail me a copy of the original? Many thanks.
--
Stephen Meatheringham
Mt. Stromlo Observatory
Private Bag, Weston Creek P.O.
ACT 2611, AUSTRALIA
phone : +61 6 2490293
email : s...@mso.anu.edu.au
John DiMarco
>The reality is that for a lot of things (not all, by any means, but if
>the part of the OS you use most is one that gets hurt then you notice),
>Solaris 2 is significantly slower than SunOS 4. While 2.4 is better
>than 2.3, particularly on sun4d where 2.3 was abysmal, it's still not
>up to scratch. The things that are slow are very simple things - it's
>very obvious that commands like ls, rup are very much slower. I mean, I
>type these simple unix commands a lot and it's very annoying to
>'upgrade' a system and make it so sluggish.
I keep seeing things like this on this newsgroup, but it doesn't correspond
with our experience. We found that Solaris 2.3 felt as quick (or perhaps
even a bit quicker) than 4.x on our lab of IPCs, given sufficient memory. We
did discover, however, that it had a significantly bigger memory footprint,
which, if it pushes a machine over the "frequent paging" threshold, can make
it feel a fair bit slower. Putting more memory in our machines fixed that.
Regards,
John
--
John DiMarco <j...@cdf.toronto.edu> Office: EA201B
Computing Disciplines Facility Systems Manager Phone: 416-978-1928
University of Toronto Fax: 416-978-1931
http://www.cdf.toronto.edu/personal/jdd/jdd.html
Jeff Bonwick
>
>I've seen lots of followup posts like the above to a list of 2.5 features
>but have never seen the original post with them listed. Would it be possible
>for someone to mail me a copy of the original? Many thanks.
You're probably not alone, so here's the original post once again:
New Features:
Hardware support:
UltraSPARC platform support
PCI support
Networking:
NFS Version 3
NFS over TCP
Dynamic IP addressing for PPP
Multithreaded automounter
4.4BSD-compatible telnet
Version 8 sendmail
Faster, cleaner, *much* more robust network file locking (lockd/statd)
Security:
ACLs (Access Control Lists)
NIS+ Password Aging
Standards:
POSIX threads (P1003.1c)
Commands and utilities for SPEC-1170 (XCU4.2)
CDE (Common Desktop Environment)
Kodak Color Management System
X/Open Federated Naming
Performance analysis and debugging tools:
Integrated kernel/user-level tracing tools (see prex(1))
Process analysis tools (see proc(1))
Thread library debugging (libthread_db)
Scoping/versioning linker
Administration:
All-new admintool
Cache-only Clients
cachefs statistics (see cachefsstat(1M))
Features that were formerly unbundled or patched that are now standard:
PCMCIA support
SPARCstorage Array support
Kernel Asynchronous I/O
In-kernel telnetd/rlogind to support hundreds of users
(smaller, faster, and better in 2.5)
Performance Improvements:
Pipes: new pipe implementation 5 times faster than 2.4.
Standard I/O: fread(3S) and fwrite(3S) 4 times faster than 2.4.
Timesharing: dramatically improved due to low-level VM rewrite,
in-kernel telnet/rlogin support, per-processor kernel memory
allocation, and breakup of global locks in ufs, tmpfs and VM.
Name service cache: speeds up name service lookups -- whether from
NIS, NIS+, DNS, or just local files like /etc/passwd -- by two
orders of magnitude (even more for large files or slow networks).
Kernel memory comsumption: reduced by roughly a megabyte on
most platforms (sun4m, sun4d, and i86pc).
SPARC hardware multiply and divide support: most recent SPARC CPUs
provide this, but existing code doesn't take advantage of it.
In 2.5 calls to .mul and .div (etc) are transparently turned
into multiply and divide instructions if the CPU supports it.
NFS: roughly 10% faster.
Window system: 10-20% faster due to fast pipes and reduced
kernel memory consumption.
Compatibility: (bcopy is back!)
Source code:
Popular library routines from SunOS 4.x are now first-class
interfaces in libc:
memory:
bcmp, bcopy, bzero, index, rindex
random numbers:
random, srandom, initstate, setstate
process control:
killpg, getpriority, setpriority, ualarm, usleep,
wait3, wait4, getrusage, getwd, setregid, setreuid
regular expresssions:
re_comp, re_exec
standard i/o:
setbuffer, setlinebuf
miscellaneous:
ftime, getdtablesize, gethostid, gethostname,
sethostname, getpagesize, reboot
Shell scripts:
Popular commands from SunOS 4.x are now in /usr/bin:
arch, hostid, hostname, mach, pagesize
Makefiles:
/usr/ccs/bin/ranlib provided as a simple "exit 0" command.
SunOS 4.x applications:
Dynamically linked apps have been supported since 2.0;
support for statically linked apps was added in 2.3;
support for mixed dynamic/static apps is new in 2.5.
Ship dates:
Preliminary Solaris 2.5 Beta CDs were distributed at the
developer's conference in May 1995. Official Beta CDs
(the same thing plus a few last-minute bug fixes) are
in the works now.
The exact date for Solaris 2.5 FCS (the final product)
has not been set. It should be sometime this Fall.
Jeff Bacon
: I keep seeing things like this on this newsgroup, but it doesn't correspond
: with our experience. We found that Solaris 2.3 felt as quick (or perhaps
: even a bit quicker) than 4.x on our lab of IPCs, given sufficient memory. We
: did discover, however, that it had a significantly bigger memory footprint,
: which, if it pushes a machine over the "frequent paging" threshold, can make
: it feel a fair bit slower. Putting more memory in our machines fixed that.
actually, in some senses, I'm willing to agree. many things seem
to work fine. the SMP support is fantastic in comparison, of course.
and solaris has a whole bunch of neat new features I just love.
openwindows is of course light-years faster, and indeed it's finally
worth running OW over MIT X11.
however, logging in ALWAYS takes me longer than before. using the same
setup files across on both platforms. using tcsh, which is compiled
better-optimised on my solaris boxes (historical reasons why the
sunos version isn't compiled as well).
why is this? I don't know. I've been meaning to do a trace of the
whole procedure and see what the deal is.
it's not surprising of course that someone observed that printing
takes longer - the lp stuff in solaris has so many more layers
and lots more overhead. some of it of course implements added
features, which may be useful to some. but IMHO, printing subsystem
still sucks. I'm sure many will disagree with me on this, but (using
current patch revs under 2.4) I've had the darndest time with lp.
crashes, leaving extra crud laying around, weird behavior...
plus of course having to figure out how to configure and
drive a printer to begin with without using admintool
(which I did finally do; kudos to the answerbook writers for
a manual that was actually useful). I've given up on it
and moved to PLP.
-bacon
--
= Jeff Bacon General Systems Hack, Michigan Technological Univ. =
= ba...@mtu.edu ph-(906)487-2197 fax-(906)487-2782 DoD#2110 I'm the NRA =
= Any war is a major war when you're the one being shot at. =
Mario Klebsch DG1AM
>We have a Sun SparcStation IPX and a generic clone 486/66, both
>running Solaris 2.4 (the latter running the X86 version of course.)
>The 486 beats the pants off of the IPX, and did so even before I
>replaced the 33 chip with a 66. The hard drive on the 486 is an
>unspectacular old clunker 1GB SCSI drive with an Adaptec 1542B
>controller (so it's buffering to get at memory above 16MB). The 486
>does have 32MB while the IPX has only 16MB.
32 MByte on a CISC machine vs. 16 MByte on a RISC machine? What do you
expect? The poor IPX is permanently swapping, letting the processor
only walk.
The 486 has smaller code and twice as much memory, so the processor
really can run.
Please don't be unfair!
73, Mario
--
Mario Klebsch, DG1AM, M.Kl...@tu-bs.de +49 531 / 391 - 7457
Institut fuer Robotik und Prozessinformatik der TU Braunschweig
Hamburger Strasse 267, 38114 Braunschweig, Germany
Ajay Lunawat
|> Here's a brief summary of the high points:
|>
|> sethostname, getpagesize, reboot
I think Sun claims Solaris to be 100% confirming to SVR4 ABI standards,
would not providing these routines in default libc affect that.
One thing our company liked about Solaris(and HP-UX/AIX) is that
if we develope the code intially it is very portable to other SVR4 based OS.
In my opinion Putting these routines back in libc will that away that feature
and Solaris will become Hp-UX linient/friendly but non portable.
I would be more happy to see these routines /usr/ucblib (As in Solaris 2.3/2.4
and other SVR4 based OS).
Ajay
John DiMarco
>however, logging in ALWAYS takes me longer than before. using the same
>setup files across on both platforms. using tcsh, which is compiled
>better-optimised on my solaris boxes (historical reasons why the
>sunos version isn't compiled as well).
Odd. I don't have identically configured 4.x and 5.x machines to do a
comparison, but logging in doesn't seem to be outrageously slow on our 5.x
boxes.
>it's not surprising of course that someone observed that printing
>takes longer - the lp stuff in solaris has so many more layers
>and lots more overhead. some of it of course implements added
>features, which may be useful to some. but IMHO, printing subsystem
>still sucks. I'm sure many will disagree with me on this, but (using
>current patch revs under 2.4) I've had the darndest time with lp.
>crashes, leaving extra crud laying around, weird behavior...
>plus of course having to figure out how to configure and
>drive a printer to begin with without using admintool
>(which I did finally do; kudos to the answerbook writers for
>a manual that was actually useful). I've given up on it
>and moved to PLP.
Good idea. One of the most important bits of knowledge when moving to Solaris
is knowing what pieces to throw away. These include:
NIS+ - Baroque, resource-intensive, buggy and complicated. NIS+
is a Sun invention. It's a half-decent idea that caught a
bad case of second-system disease. I recommend that Sun put
it out of its misery and start from scratch.
Replace with:
NISkit (not recommended for passwd) or files + DNS. Note
these replacements are not always adequate. More work
needed here.
LP - Buggy and complex. Sun inherited this from SVR4; it's
essentially the traditional System V printing subsystem with
some BSD compatibility stuff added. Sun apparently plans to
throw it away and replace it with POSIX-blessed printing
(which will probably look more like BSD-style lpd than
SYSV-style lp), as soon as POSIX finishes the blessing
process and a suitable implementation is ready.
Replace with:
PLP (ftp.iona.ie:/pub/plp/*) or some other BSD-style lpd.
ttymon/sac/saf - Buggy, very complex. This is an SVR4 invention that seems
to have gotten away from its inventors. Sun adopted it
wholesale from SVR4, probably through inertia. Robust direct
serial line support appears to have never been high on Sun's
priority list. If you have significant serial port needs,
Sun will probably try to sell you a rebadged Annex terminal
server (which avoids all this stuff).
Replace with:
agetty (ftp.cdf.toronto.edu:/pub/agetty/*) or another
BSD-style getty.
sendmail - Insecure. It's fairly hard to write a mailer and make it
secure. Sun's sendmail is based on an older version of
BSD sendmail, which grew from a small program to an
enormous one over time. A relatively large number of
security bugs have been reported in BSD sendmail over the
years, and new ones are periodically being discovered.
Replace with:
sendmail-v8, zmailer, or some other mailer.
rdist - Insecure. It's a setuid root program that doesn't need to
be setuid root. Holes in rdist in the past have been widely
used to obtain unauthorized root privileges.
Replace with:
rdist v6 (usc.edu:/pub/rdist/*)
rpcbind - Insecure. Sun's rpcbind supports proxy rpc, which clever
programs can use to fool your NFS server into thinking that
remote NFS mount requests are really coming from the local
machine. It's best to use an rpcbind that is wary about
proxy RPC, and can be configured to talk only to trusted
machines.
Replace with:
Weitse Venema's rpcbind (ftp.win.tue.nl:/pub/security/rpcbind*)
In addition, one might consider replacing finger[d] and talk[d].
David Robinson
Ajay Lunawat <aj...@unison.com> wrote:
>In article <3qp5iq$m...@engnews2.Eng.Sun.COM>, bon...@cathy.Eng.Sun.COM (Jeff Bonwick) writes:
>|> Compatibility: (bcopy is back!)
>|>
>|> Source code:
>|> Popular library routines from SunOS 4.x are now first-class
>|> interfaces in libc:
> I think Sun claims Solaris to be 100% confirming to SVR4 ABI standards,
>would not providing these routines in default libc affect that.
This has no effect on SVR4 ABI compliance. When it comes to an
ABI you are said to be compliant if any *application* that is
ABI compilant will run on your OS. If the application uses
interfaces that are not part of the ABI then it may or may not
work on a compliant OS.
> One thing our company liked about Solaris(and HP-UX/AIX) is that
>if we develope the code intially it is very portable to other SVR4 based OS.
>In my opinion Putting these routines back in libc will that away that feature
>and Solaris will become Hp-UX linient/friendly but non portable.
>I would be more happy to see these routines /usr/ucblib (As in Solaris 2.3/2.4
>and other SVR4 based OS).
I agree that a company that wishes to develop portable SVR4 code
should only use SVID interfaces. Counting on libc only containing symbols
that are part of the SVID is a bad idea, there already are interfaces
in libc that are unportable in 2.4.
A new feature in 2.5 is the concept of "scoping" a library. It allows
you to have a single library with symbols scoped at different levels.
This has the potential to allow you to ask for just the ANSI C, or
POSIX, or SPEC 1170, etc when you link. Unfortunately no bundled
libraries are scoped in 2.5.
-David
Guy Harris
>ttymon/sac/saf - Buggy, very complex. This is an SVR4 invention that seems
> to have gotten away from its inventors. Sun adopted it
> wholesale from SVR4, probably through inertia.
We tried to kill it, really we did....
>sendmail - Insecure.
...
> Replace with:
> sendmail-v8,
I think another message in this thread indicates that Sun is doing
exactly that in Solaris 2.5.
Guy Harris
> I think Sun claims Solaris to be 100% confirming to SVR4 ABI standards,
>would not providing these routines in default libc affect that.
Only if it caused ABI-compliant applications to fail.
I don't expect it to do so; if your application defines the symbol
"index", for example, internally, and uses it for its own purposes,
those references should all resolve to *your* "index", not to the one in
the C library.
> One thing our company liked about Solaris(and HP-UX/AIX) is that
>if we develope the code intially it is very portable to other SVR4 based OS.
*If* you avoid using any Solaris 2.x-specific interfaces, of course -
many of which are currently in "libc", such as the threads stuff.
>In my opinion Putting these routines back in libc will that away that feature
>and Solaris will become Hp-UX linient/friendly but non portable.
Yes, putting them in "libc" will require developers to be more
disciplined about writing apps on a Solaris 2.x machine if they want
them to be portable, but it also makes life more pleasant for people
trying to move applications written to a more V7ish/old-BSDish API to
Solaris 2.x. I guess Sun got enough complaints about the latter that
they're changing "libc"; if they don't get many new complaints as a
result of that change, that may mean that, over all, they did the right
thing.
It might also be useful if they provided tools to check whether an
application is using API's outside of some specified set; for all I
know, they may already do so.
Casper H.S. Dik
>The reality is that for a lot of things (not all, by any means, but if
>the part of the OS you use most is one that gets hurt then you notice),
>Solaris 2 is significantly slower than SunOS 4. While 2.4 is better
>than 2.3, particularly on sun4d where 2.3 was abysmal, it's still not
>up to scratch. The things that are slow are very simple things - it's
>very obvious that commands like ls, rup are very much slower. I mean, I
>type these simple unix commands a lot and it's very annoying to
>'upgrade' a system and make it so sluggish.
You must have done something treuly awful with your configuration.
I never noticed "rup" or "ls" being slow in 2.3/2.4 In 2.4 ls should
be substantially faster (at least on second runs) than in 2.3 and
SunOS 4: the OS caches the readdir blocks.
It looks like you're using a slow nameserver machine with a slow
nameserver protocol.
>Now I like a lot of Solaris 2. It makes administration, configuration
>and the like much easier. (I even like nisplus!) But we're definitely
>paying a price in terms of interactive performance to do this. (As far
>as reliability goes, we're reasonably happy with 2.4, as long as we
>don't run a recent kernel jumbo patch - rev 27 was unuseable,
>apparently rev 31 fixes it but having had to back out we aren't in a
>hurry to try again.)
You may be running NIS+ on an underconfigured machine, but it is also the
case that the NIS+ secure RPC authentication is much more expensive to
setup (done once for each program) than non-authenticated NIS.
The Name Server Cache Daemon (in 2.5) should alleviate this problem.
Casper
--
Casper Dik - Network Security Engineer - Sun Microsystems
This article is posted from my guest account at the University
of Amsterdam. My real-life e-mail address is: Caspe...@Holland.Sun.COM
Opinions expressed here are mine (but you're welcome to share them with me)
Charles
:
: NFS: roughly 10% faster.
Is this a NFS 2.4 vs NFS 2.5 speed quote, or a NFS 2.4 vs NFSv3 2.5 quote?
Our Sun people told us NFS v3 was going to be 80% faster than current NFS.
--
Harnad describes the status of Usenet aptly:
a communication medium with revolutionary intellectual
potential being used mostly as a global graffiti board.
[Harnad 1991]
Charles Hedrick
>Compatibility: (bcopy is back!)
> Source code:
> Popular library routines from SunOS 4.x are now first-class
> interfaces in libc:
> Shell scripts:
> Popular commands from SunOS 4.x are now in /usr/bin:
> arch, hostid, hostname, mach, pagesize
> Makefiles:
> /usr/ccs/bin/ranlib provided as a simple "exit 0" command.
This is great news. If I had wanted System V I would have bought a
(hmmm... prudence suggests that I not name the vendor). As I'm sure
you know, other workstation vendors have also used a mixed libc in
their new-generation OS's. Have you made some attempt to see what
other vendors are putting in their libc? It would be nice to have a
list of stuff that all the major vendors support. Also, did you put
the networking stuff in libc? The other big portability problem is
that we have to add a zillion libraries to all our makefiles (libnsl,
libsocket, etc.) The SGI version of SVr4 seems to have avoided this.
They still have libnsl and all that, but typically you don't seem to
need it.
Charles Hedrick
> Shell scripts:
> Popular commands from SunOS 4.x are now in /usr/bin:
> arch, hostid, hostname, mach, pagesize
The two most serious incompatibilities I found were in utilities that
suddenly started returning sizes in units of 512 bytes, and the new
ps. 512 bytes is clearly brain damage: it's a unit that has no
meaning these days with varying block sizes. Have you ever tried
explaining to users why some commands give disk use in half-K? Aren't
you tried of remembering which numbers you have to mentally divide by
two? (or is it multiply by two?) The POSIX spec wasn't handed down by
God. We should admit where it's broken. You should follow the Gnu
lead and display in K unless the user sets an environment variable
POSIX_ME_HARDER. For ps, I like the Digital Unix kludge of have ps
behave like Berkeley if the argument doesn't begin with -, and System
V if it does.
Larry McVoy
: One of the attributes of Solaris 2.5 was that was not mentioned
: the performance changes with lmbenchmark and compared them to
: the Solaris 2.4 on the same hardware and I am seeing about 18 to
: 20 percent increase with in kernel memory copies, redecued
: context switch times reduced tcp and udp latencies and higher
: tcp bandwidth. Compare the results yourself the lmbenchmarks
: are available at verious ftp sites. It originated out of
: sgi.
Actually, Sun paid me to write that benchmark while I was suffering
from severe burnout after having produced Sun's first cluster product
(which flopped big time, boo, hiss).
You can get the benchmark by sending mail to arch...@slovax.engr.sgi.com,
with a Subject line of "lmbench1.0*".
There will be a web page appearing soon with pretty graphs, I'm almost done
with it.
--
---
Larry McVoy (415) 390-1804 l...@sgi.com
Davin Milun
According to the July _Unix Review_ article abotu the new XOpen Unix
standards, many of these are back in the standard.
Davin.
-------------------------------------------------------------------------------
Davin Milun Internet: mi...@cs.Buffalo.EDU
BITNET: milun%cs.buffalo.edu@ubvm
Fax: (716) 645-3464
WWW: http://www.cs.buffalo.edu/~milun/
Casper H.S. Dik
[[ Please don't quote all of an article just two add two or three lines ]]
}|> Compatibility: (bcopy is back!)
}|>
}|> Source code:
}|> Popular library routines from SunOS 4.x are now first-class
}|> interfaces in libc:
}|> memory:
}|> bcmp, bcopy, bzero, index, rindex
}|> [[ ... ]]
} I think Sun claims Solaris to be 100% confirming to SVR4 ABI standards,
}would not providing these routines in default libc affect that.
} One thing our company liked about Solaris(and HP-UX/AIX) is that
}if we develope the code intially it is very portable to other SVR4 based OS.
}In my opinion Putting these routines back in libc will that away that feature
}and Solaris will become Hp-UX linient/friendly but non portable.
}I would be more happy to see these routines /usr/ucblib (As in Solaris 2.3/2.4
}and other SVR4 based OS).
Personally, I agree with your sentiments. However, one of the gripes many
people had with Solaris 2.x is that a lot of programs didn't port easily
w/o using the ucblibs. (I would say that the rusage stuff and wait3 are the
only ones not easy to port). A lot of people are lazier and don't care about
a clean, pure SVR4 environment. It seems to be what the customer
wants (at least those customers that haven't bothered switching to Solaris 2.x
yet)
Another problem suddenly adding these functions to libc is that you'll
need to keep old Solaris 2.x around to do development work.
(Though it was always the case that if you developed on system a.x you could
only expect your code to run on a.y, y>= x and not y<x because new
features are added all the time)
But all is not lost: scoping will be added to the Solaris 2.x linker
which will eventually enable you to specify that you want to link
with libc but only use the X/Open, POSIX, SVR4 or whatever ABI.
Casper H.S. Dik
}The two most serious incompatibilities I found were in utilities that
}suddenly started returning sizes in units of 512 bytes, and the new
}ps. 512 bytes is clearly brain damage: it's a unit that has no
}meaning these days with varying block sizes. Have you ever tried
}explaining to users why some commands give disk use in half-K? Aren't
}you tried of remembering which numbers you have to mentally divide by
}two? (or is it multiply by two?) The POSIX spec wasn't handed down by
}God. We should admit where it's broken. You should follow the Gnu
}lead and display in K unless the user sets an environment variable
}POSIX_ME_HARDER. For ps, I like the Digital Unix kludge of have ps
}behave like Berkeley if the argument doesn't begin with -, and System
}V if it does.
If you want BSD ps, you know where to find it.
You can use the -k option with df and du, and I suppose Sun has no]
choice in the matter: requireing POSIX_ME_HARDER or anything else
would break SVR4 and POSIX compliance.
Chuck Lever
Neil Hoggarth
Charles Hedrick <hed...@farside.rutgers.edu> wrote:
> The SGI version of SVr4 seems to have avoided this.
Oh great! A chance to be pedantic!
SGI's OS isn't SVR4 - it's SVR2 based, with lots of functionality from
later releases (and other sources, such as BSD) rolled in. They keep
adding new stuff to their original source base, rather than starting
with a clean sheet.
Charles' basic point is valid however - IRIX has always been System V
based but it's not such a shock for someone brought up on SunOS 4.X as
Solaris 2 is. Solaris has lots of nice features and lots of shiny new
technology in it, but on an IRIX machine I don't need to link against a
thousand and one libraries, I can set it up to send stuff to a print
server by editing "/etc/printcap", I've got and "/etc/fstab" file and
and "/etc/exports" file to manage my file systems and NFS with, etc.
From what we've been reading in this thread it sounds as though 2.5 is
going to do some things to soften the dislocation that you get in moving
from 4.1.X. I think that this has to be a good thing, and it's a shame
that Sun didn't do things like native NIS support, bcopy() in libc, an
ranlib stub to keep the Makefiles happy, a nice print spooler system,
etc, in the first place. They would have saved themselves a lot of flak
from the users and got a much better take up if they had. They should
also have just called it SunOS 5. I know that the operating system
component of the "Solaris" package is called that anyway, but the
repackaging of the distribution as "Solaris" has built a wall in many
people's minds. They see it as something totally different, rather than
an upgrade. "We run SunOS, they run Solaris".
Regards,
--
+-------------------------------------------------------------------------+
Neil Hoggarth Departmental Computer Officer
<neil.h...@physiol.ox.ac.uk> Laboratory of Physiology
http://www.physiol.ox.ac.uk/~njh/ Oxford University, UK
+-------------------------------------------------------------------------+