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
+-------------------------------------------------------------------------+
Alan Coopersmith
|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.
Don't the POSIX, X/Open, etc. standards say you should be able to do
this by just adding "#define _POSIX_SOURCE", "#define _XOPEN_SOURCE",
etc. ?
--
________________________________________________________________________
Alan Coopersmith Internet: al...@OCF.Berkeley.EDU
Open Computing Facility or: al...@CSUA.Berkeley.EDU
University of California, Berkeley Bitnet: alanc@ucbocf
Casper H.S. Dik
}cas...@fwi.uva.nl (Casper H.S. Dik) writes in comp.unix.solaris:
}|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.
}Don't the POSIX, X/Open, etc. standards say you should be able to do
}this by just adding "#define _POSIX_SOURCE", "#define _XOPEN_SOURCE",
}etc. ?
That will give you the defines and function definitions. But most
C compilers don't complain if you use unprototyped functions, except
in fascist mode, which is hardly ever the default.
Bryan Althaus
: I was lead to believe that Solaris 2.5 would support a IPX/SPX stack?
Jeff Bonwick (bon...@cathy.Eng.Sun.COM) wrote:
: I think that's already available as an unbundled product.
Doesn't anyone but me think Solaris 2.5 should come bundled with
IPX/SPX?
Does everyone who uses Solaris, Sparc and x86 not have Netware
somewhere in their building? I find it hard to believe that
Solaris customers are just UNIX houses.
If the unbundled product was a few dollars I wouldn't care, but
I know the IPX/SPX stack for Solaris is going to be >$300 per seat!!!
All I want to do is use WABI and be able to run programs off
the Netware server as well as be able to share Word and Excel
stuff with the Windows crowd. I currently use an NT box for that
but not everyone who runs Solaris x86 around here uses NT as well.
For the Sparc version of Solaris ok, but Solaris x86 needs to
work in a PC world. Every article I read about Solaris x86
keeps saying that Sun is clueless when it comes to the PC
market, and I'm starting to think their correct.
I was told if enough interest was show the IPX/SPX stack might
make it as an update to 2.4 but that it would definately be
in 2.5.
NT, UnixWare, SCO, Linux/Caldera all x86 based support IPX/SPX.
Is there anyone at SunSoft who is up on this? I plan on writing
this in as a missing feature when my beta of 2.5 shows up.
Other than that, 2.5 looks very interesting....
Derick J.R. Qua-Gonzalez
>Doesn't anyone but me think Solaris 2.5 should come bundled with
>IPX/SPX?
Gee, I dunno. I personally don't know anyone who would need to
talk IPX/SPX, nor would I recommend it to any client. Why should
the cost of that software (IPX/SPX bridge) be included, when it's
more than likely gonna be zapped or never installed? When I install
systems for clients, I often use refurbished Sun SPARCstation 2s
and IPXs, coupled with a brand-spankin'-new SPARC20 server or so;
works much better and is cheaper (really) than PC's off a SPARC20.
Not a sign of IPX/SPX anywhere.
>If the unbundled product was a few dollars I wouldn't care, but
>I know the IPX/SPX stack for Solaris is going to be >$300 per seat!!!
For that cost, you might as well buy a hardware bridge!
>For the Sparc version of Solaris ok, but Solaris x86 needs to
>work in a PC world. Every article I read about Solaris x86
>keeps saying that Sun is clueless when it comes to the PC
>market, and I'm starting to think their correct.
Or maybe the PC world, in general, is under the mystic spell of
the Grand Wizard Gates? BTW, have you tried Linux?
>NT, UnixWare, SCO, Linux/Caldera all x86 based support IPX/SPX.
Guess you have.... :-) I suppose you could somehow justify
spending $750 for Solaris x86, $1000+ for Development Tools, etc.,
as opposed to $30--$100 for Linux/Caldera. ``But it's got the
pretty box, George, just look at how impressive these packages
will look on our credenzas!'' I confess I'm a very satisfied Sun/
Sun-clone person, but Solaris x86 is overpriced considering the
market they are trying to break into (PC==inexpensive).
Best regards,
--
+----------------------------------------------------------------------------+
| Derick R. Qua-Gonzalez | ________ |
| Department of High Engery Physics | \ / |
| California State University | \ / |
| dq...@Prometheus.EarthLink.Net | \ / |
| | G \/ |
+----------------------------------------------------------------------------+
| It is better to be hated for what one is, than loved for what one is not. |
| (A. Gide) |
+----------------------------------------------------------------------------+
Torbj|rn Lindgren
Casper H.S. Dik <cas...@fwi.uva.nl> wrote:
>ptri...@hgmp.mrc.ac.uk (Peter C. Tribble) writes:
>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.
He might have memory problems. Solaris 2.4 seems to leak memory on
some machines, and it ain't fun to run Solaris 2.4 when you hear the
disk crack every time you press enter... (Someone timed the openwin
startup, it took ~1 hour on a otherwise unused 32 MB SS20/50!).
I'll have to get patch 101907-05 and see if that helps, setting
nrnodes in /etc/system didn't help. I still wonder why Sun hasn't
released that patch on their ftp-sites, it's so much faster to get it
that way (I can get the patches other ways, but it isn't as fast).
R. Stewart Ellis
>>bon...@cathy.Eng.Sun.COM (Jeff Bonwick) writes:
>> 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.
You have discovered the -k and -t switches for /usr/bin/ps?
--
R.Stewart(Stew) Ellis, Assoc.Prof., (Off)810-762-9765 ___________________
Humanities & Social Science, GMI Eng.& Mgmt. Inst. / _____ ______
Flint, MI 48504 el...@nova.gmi.edu / / / / / /
Web admin: chimera,nn,tin,jove,kermit - free's best!/________/ / / / /
Mario Klebsch DG1AM
>Ajay Lunawat <aj...@unison.com> wrote:
>> 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.
I also would like, these routines to appear in a distinct
library. What about -lsos4?
I think, it is no problem to add a library, when porting, since you
already have to add -lnsl and -lsocket to losts of them.
I really like the win of portability, when using the new mem*()
functions. I knew them for years, since I learned UNIX on a SYSV box;
I even used them. But after using SunOS for about 4 years, I got used
to use b*(). I did this, when switching to Sun with SunOS 3.5.
P.S. I never understood, why there were two different sets of library
routines.
Jeff Bacon
: : 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.
: IPX/SPX?
*shrug* it might be nice, just so long as it comes as a separate
package that I don't have to load.
: Does everyone who uses Solaris, Sparc and x86 not have Netware
: somewhere in their building? I find it hard to believe that
: Solaris customers are just UNIX houses.
yes, I don't have netware anywhere. no, we're not a complete
unix house; there's more PCs than suns around here. we just
don't happen to run netware. :)
(our fascist telcom types deemed long ago that any packet on the
backbone better be an IP packet, which is fine by me. 'course,
I also worked there then and helped wih the decision. :) )
: If the unbundled product was a few dollars I wouldn't care, but
: I know the IPX/SPX stack for Solaris is going to be >$300 per seat!!!
that's a little ridiculous.
it definitely should be cheaply available if sun wants to play.
moi
> can anyone guess whether Solaris 2.5 will support 32-bit UIDs ?
I've heard 2.6 from a "reliable" source.
Cheers,
Aldo
Torbj|rn Lindgren
Sinan Karasu <si...@u.washington.edu> wrote:
>In article <3ri5ag$2...@nyheter.chalmers.se>,
>Torbj|rn Lindgren <t...@ae.chalmers.se> wrote:
>>startup, it took ~1 hour on a otherwise unused 32 MB SS20/50!).
>
Yes, that's about normal. After I had rebooted the SS20/50 it took
less than 10 seconds to enter openwin. It takes about 6-10 days to get
it to the 1 hour point :) It's not just that it leaks memory, it leaks
fast too.
Sinan Karasu
>Casper H.S. Dik <cas...@fwi.uva.nl> wrote:
>>ptri...@hgmp.mrc.ac.uk (Peter C. Tribble) writes:
>>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.
>
>He might have memory problems. Solaris 2.4 seems to leak memory on
>some machines, and it ain't fun to run Solaris 2.4 when you hear the
>disk crack every time you press enter... (Someone timed the openwin
Interesting. It takes my SparcStation 1 (28 Megs) about 24 seconds....
Sinan
Henry Leparskas
Just to point out the Solaris X86 sells for $187 Canadian on our
campus. You can get Sparcworks C++ for $187 as well.
Cheers,
Henry
Henry Leparskas
UWO Astronomy
hle...@uwo.ca
Casper H.S. Dik - Network Security Engineer
>I also would like, these routines to appear in a distinct
>library. What about -lsos4?
A mechanism by which to specify which set of functions to use from a
certain library would seem sufficient to me.
>I really like the win of portability, when using the new mem*()
>functions. I knew them for years, since I learned UNIX on a SYSV box;
>I even used them. But after using SunOS for about 4 years, I got used
>to use b*(). I did this, when switching to Sun with SunOS 3.5.
>P.S. I never understood, why there were two different sets of library
>routines.
Historical: some people invented the mem* functions by copying the
str* functionality with a similar interface. The BSD folks created
a different interface from scratch. ("designing" APIs is one of the
weakest points of the BSD folks)
There is a lot of that around: most functionality invented after the
"Great Divide" exists in one or more flavours.
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Paul Eggert
>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.
I think the proper spelling of that environment variable these days is
`POSIXLY_CORRECT'.
Why does requiring POSIXLY_CORRECT break POSIX compliance? It's just
selecting the proper implementation -- just as gcc's `-ansi' option
selects ANSI compatibility.
SVR4 I don't know about -- I don't have a copy of that spec. But I am
also skeptical that requiring something like SVR4LY_CORRECT would break
the letter of SVR4 compliance.
By the way, if you want to see a case where mindless Posix compliance
is lunacy, check out the Posix spec for `patch' -- it requires that
`patch' not generate backup files by default! I don't know of any
`patch' implementation that follows *that* spec.
Thomas W. Lucey
In a previous article, bon...@cathy.Eng.Sun.COM (Jeff Bonwick) says:
>In article <bryD9o...@netcom.com> b...@netcom.com (Bryan Althaus) writes:
>
>> 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.
>
>
>Jeff Bonwick
>Solaris Performance
>
If support for IPX/SPX is available now, I am interested in any experiences,
good or bad, with accessing from Wabi 2.0 a Netware server running Windows 3.1
Any comments on upcoming developments on IPX/SPX support would be appreciated.
-------
Tom Lucey preferred email address: tlu...@fcc.gov
Doug Gwyn
>The POSIX spec wasn't handed down by God. We should admit where it's broken.
1024-byte units are as broken as 512-byte units.
In fact "byte" is somewhat broken as it seems to be taken as meaning
octet (8 bits) but there is no fundamental reason why files should be
organized into octets.
POSIX.2 conformance may well be a requirement in many contracts, for
example in large government or industry procurements. There is a lot
about POSIX.2 that one can legitimately gripe about, but conformance
is largely a market issue.
>You should follow the Gnu lead and display in K unless the user sets
>an environment variable POSIX_ME_HARDER.
If that's the only thing it affects, it ought to be along the lines
FILE_SIZE_DISPLAY_UNIT=1024
Actually, I don't think this kind of thing is an efficient use of the
"environment" facility. Why not have a per-user "dot file" similar to
ones in use for X-Windows etc.? It could even be organized like the
Windows .INI file format and have a well-known name so that lots of
applications could query it for user preferences.
Doug Gwyn
>P.S. I never understood, why there were two different sets of library
>routines.
That's relatively easy to answer. When UNIX first started to become
popular (over a dozen installations!), a group inside Bell Labs wanted
to use it as the basis for "production" systems as well as the "research"
system it started out as. They developed, originally from 6th Edition
UNIX, the Programmer's WorkBench version of UNIX. That became the
basis for an in-house "supported" version of UNIX, with different staff
supporting and evolving it than the people still working on the research
version of UNIX. Early versions of the *research* version made their
way out to universities and other places outside the Bell System, where
numerous people including Berkeleyites hacked on it and adding many
things. Simultaneously, inside the Bell System the "supported" version
(Unix Support Group or USG version) underwent a similar evolution, but
with very little coordination with the outside world branch of the
evolutionary tree. So, for example, "bcopy" was devised for the
Berkeley Software Distribution (originally user-mode add-ons for PDP-11)
while "memcpy" was devised for USG UNIX.
Later on, each system tended to pick up features from the other, so
that one might find both versions of the block-copy function on the
same system. C and UNIX standardization was largely a matter of
resolving such conflicting interfaces. As it happens, memcpy must
be provided by any C implementation that conforms to the C Standard.
Roland Kaltefleiter
>hed...@farside.rutgers.edu (Charles Hedrick) writes:
>}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.
I rellay like Solaris 2.x, but I really need SOME aliases and ist fine:
alias ps /usr/ucb/ps
alias du /usr/ucb/du
alias df /usr/ucb/df
and maybe:
ls /usr/ucb/ls -F
AND:
alias passwd nispasswd
passwd does not follow the way in /etc/nsswitch.conf for passwd.
Like we, running NIS+, a user MUST type nispasswd or you get:
orff[kaltef] > id
uid=306(kaltef) gid=30(schattke)
orff[kaltef] > /bin/passwd
/bin/passwd: Changing password for kaltef
/bin/passwd: kaltef does not exist.
Roland
--
Roland Kaltefleiter | OFFICE: n/a please use Papermail
| PRIVAT: rol...@toppoint.de
In another world in another time to come, there won't be MS-DOS.
Mario Klebsch
>: somewhere in their building? I find it hard to believe that
>: Solaris customers are just UNIX houses.
We have about 3 times as much Sun computers as PC's. We don't run
anything like netware, our PC's run PC/NFS from Sun. It works great in
integrating the PC's into our UNIX environment.
Bryan Althaus
: >: Does everyone who uses Solaris, Sparc and x86 not have Netware
: >: Solaris customers are just UNIX houses.
: We have about 3 times as much Sun computers as PC's. We don't run
: anything like netware, our PC's run PC/NFS from Sun. It works great in
: integrating the PC's into our UNIX environment.
So you are more of a UNIX shop. PC/NFS per seat is expensive as is any
TCP/IP stack for Windows, anywhere from $100 up to $300 with the
higher range being more common, especially if your not buying 100's of seats.
And so your really making you Windows boxes work in a UNIX world. Thats
fine for you situation. I am no fan of NetWare or IPX/SPX just I realise
the huge market thats out there.
But for a lot of company's, definitely most in NYC where I work and live,
Windows is "the" platform (reason why the Windows app market is so huge)
and the most popular way to have Windows boxes talk is Novell's Netware,
IPX/SPX, with some 80% of the market. Which is nothing new to anyone.
So at that point adding TCP/IP stacks to Windows is not going to happen
not only for the amount of $$$ it would take but they are happy with
the NetWare servers. So that means the UNIX side has to learn to
talk to the Netware servers.
If it wasn't for WABI I would care less, but Word, Excel, Access, Emailetc.
all are on the NetWare servers. Why do I want to wast space on my
machine not to mention I still need to share files with these people.
If they send me email, I need to be able to get the attachments.
In this case I need to talk IPX/SPX, its as simple as that. So I can
pay >$300 seat for this only to be laughted at by the pro NT people who
have it out of the box ( I run both Solaris and NT so this is not a war,
just a matter of survival for Solaris or any UNIX ).
I know I could get a seat approved for me, but alot of people are running
WABI as they switch from SunOS to Solaris. And everyone's going to
want an IPX/SPX stack until it gets to the point where someone in
management (some of our management are x-techies) says
"hey just run NT for $100 and forget about this Solaris,WABI,IPX/SPX stuff."
I could use NT to do all the above, but Solaris is my main platform so it
has the bigger monitor, faster CPU, etc. etc.
I just think its 1995 and once when Solaris 2.5 is reviewed by the critics,
they will once again point out as they always do that Solaris unlike
most modern OS's, can talk to a Netware server. And Solaris 2.5 x86
will really get the brunt of this since its a PC OS. Just read the
Solaris 2.4 x86 reviews from this year. Find one that doesn't mention this.
Anyway just my $0.02.
Oh, as for SunSoft and PC's. A friend works for SunSoft doing Windows stuff
so I know a little about the mind set of SunSoft when it comes to the PC.
Scott Seligman
>
> alias passwd nispasswd
>
> passwd does not follow the way in /etc/nsswitch.conf for passwd.
The passwd(1) command in Solaris 2.5 does know about NIS and NIS+,
so there are no longer separate yppasswd and nispasswd commands.
(They still exist, but are just links to passwd.)
Scott Seligman
seli...@Eng.Sun.COM
The opinions expressed are my own. Facts, though, are just facts.
Andy McCammont
In article <3rdjs3$j...@farside.rutgers.edu>, hed...@farside.rutgers.edu.. stuff deleted
|>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.
--
Andy McCammont
mcca...@expt05.stp.xfi.bp.com
<A HREF="http://www.stp.xfi.bp.com/~mccammaa/">Internal Home Page</A>
pgp key on request, key id 1024/A24B6995
Andre Beck
WILL 2.5 have a SNMP Agent built in ? Every relevant UNIX has, NT has,
and Solaris _must_ have one, too. And buying Suns Netmanager is _no_
option, as I decide what management station to use, not Sun (and there
is absolutely nothing what an SNMP agent would have to do with a particular
management station implementation).
--
+-o-+--------------------------------------------------------+-o-+
| o | \\\- Brain Inside -/// | o |
| o | ^^^^^^^^^^^^^^ | o |
| o | Andre' Beck (ABPSoft) be...@ibh-dd.de XLink PoP Dresden | o |
+-o-+--------------------------------------------------------+-o-+
Martin Spott
: good or bad, with accessing from Wabi 2.0 a Netware server running Windows 3.1
Maybe you can help me: Do you have any experiences in running apps under
WABI using TCP/IP via winsockets ? I tried, but I got 'network error'.
Somewhere in the doc's Sun writes about winsocket support in WABI.
Martin Spott.
----------------------------------------------------------------------------
EMail: I prefer correspondence to: Mar...@smigel.mitropa.com
If necessary, business mail can be sent to: Martin...@uni-duisburg.de
Snail Mail: Martin Spott, Karlstrasse 61, D-47119 Duisburg, Germany
Maus: Martin Spott @ DU3
----------------------------------------------------------------------------
Microsoft isn't the answer. Microsoft is the question, and the answer is NO.
----------------------------------------------------------------------------
Juergen Keil
> 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.
This is probably because you're using different fonts with Xsun
(i.e. F3 scalable fonts, that do not have precomputed bitmap versions
installed in $OPENWINHOME/lib/X11/fonts/F3bitmaps) than you've used on
the other systems.
Producing a bitmap version from an F3 scalable font takes ~3-4 seconds
per font on a SS2; during this time the Xsun server seems frozen
(mouse pointer doesn't move, no keyboard input accepted, ...).
You can:
- install bitmap versions for often used F3 fonts using the supplied
'makebdf' program. See makebdf(1) and mkfontdir(1).
$OPENWINHOME/lib/X11/fonts/F3bitmaps already contains 6, 8, 10, 12 and
14pt versions of the F3 fonts for a screen resolution of 72dpi x 72dpi.
- or reorder the fontpath (or even remove the F3 directory from the
fontpath).
Using one of these methods reduces startup time (into the 'blank'
initial page) for netscape on a SS2 from 12 seconds down to 5 seconds.
--
Juergen Keil j...@tools.de ...!{uunet,mcsun}!unido!tools!jk
Brian Horn
Ronald van der Pol <rv...@cs.vu.nl> wrote:
>bon...@cathy.Eng.Sun.COM (Jeff Bonwick) writes:
>
>>> 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?
There is no "merge" to be accomplished. From day one the PowerPC has been
from the same code base as both the SPARC and the x86.
David Robinson
Well yes and no. Yes the PowerPC was developed from the same code
base as SPARC and x86 but no, there is a minor merge. All the
platform specific code needs to be "merged" back into the source
base. The hardest part will be merging the Makefile (eg. not hard :-)
-David