Solaris 2.4
Graham Crawford
Hi,
Does anyone know when Solaris 2.4 is
going to be released?
Does anyone know what enhancements and
new features it will have over 2.3?
--
Graham Crawford
CelsiusTech Australia Pty Ltd
AUSTACCS User Facility, Gallipoli Barracks
MILPO Enoggera QLD 4052 Australia
Ragnvald T. Blindheim
: It has a lot of bug fixes, a lot of performance improvements,
: A journalled file system, a Motif based administrative frontend, Motif
This filesystem, is it the Veritas filesystem?
: Casper
--
Ragnvald T. Blindheim ragn...@edb.tih.no
Utleirveien 6
7033 Trondheim
Norway
Casper H.S. Dik
> Does anyone know when Solaris 2.4 is
>going to be released?
>Does anyone know what enhancements and
>new features it will have over 2.3?
It is generally expected to be released in the August/September timeframe.
The release has just been frozen, or so I'm told.
It has a lot of bug fixes, a lot of performance improvements,
A journalled file system, a Motif based administrative frontend, Motif
are some of the new features. The announcement of 2.4 als maentions
all kinds of stuiff new in 2.2 and 2.3 but that's because it's also
the jump from 2.1 x86 to 2.4 x86.
Casper
Pete Hartman
>A journalled file system,
What is a journalled file system?
Casper H.S. Dik
>cas...@fwi.uva.nl (Casper H.S. Dik) writes:
>>A journalled file system,
In the words of Kirk McKusick, explaining the BSD 4.4 Journalled
file systems:
something you dont' want, needs 50% free space and all
that only for quick recovery on crashes and w/o the
proper Unix semantics found in crash recovery.
It's supposed to be more reliable and have faster/better crash recovery
than the BSD FFS.
Casper
Marc Fraioli
>It has a lot of bug fixes, a lot of performance improvements,
>A journalled file system, a Motif based administrative frontend, Motif
>are some of the new features. The announcement of 2.4 als maentions
>all kinds of stuiff new in 2.2 and 2.3 but that's because it's also
>the jump from 2.1 x86 to 2.4 x86.
>
taking a little longer than they said it would...
---
Marc Fraioli | "They couldn't hit an elephant at this dist- "
m...@clark.net | - Last words of Union General John Sedgwick,
| Battle of Spotsylvania Court House, U.S. Civil War
Ken Bibb
>In article c...@mail.fwi.uva.nl, cas...@fwi.uva.nl (Casper H.S. Dik) writes:
>>It has a lot of bug fixes, a lot of performance improvements,
>>A journalled file system, a Motif based administrative frontend, Motif
> ^^^^^ ^^^^^
>>are some of the new features. The announcement of 2.4 als maentions
>>all kinds of stuiff new in 2.2 and 2.3 but that's because it's also
>>the jump from 2.1 x86 to 2.4 x86.
>But when do we get mwm, the COSE CDE, and so on? They promised, but it's
>taking a little longer than they said it would...
With 2.4--that's why "Motif" is up there :)
My understanding is that it will be CDE "compliant"--they were talking
heavily about CDE at the Solaris Developer's Conference.
--
Ken Bibb "Imagine what it would be like if TV actually were
kb...@qualcomm.com good. It would be the end of everything we know."
jes...@crash.cts.com --Marvin Minsky
Bob Palowoda
Well, I'll make a few comments here. First I never had the luxury of
working with 2.1 x86 :-), I work with x86 2.4.
I have worked with other versions of SVR4, the last was Unixware and
I would definitly say the file system is faster for the same hardware
and the network is also definitly faster.
I believe the Motif based frontend your talking about up there is
a CDE based install GUI. Much more streamlined than Unixware.
The telephoney (Xtel) I beleive is new. Real ddx layer, dga.
I also beleive their was alot of improvements to XIL.
After the Developers Conference it took me about three hours to
convert my Unixware development machine to x86 2.4. There is about
2G of utility/pd source which I'd say about 70 percent of it is
converted. I can't make too many opinions right now because I'll end
up sounding like a salesperson here, as I work with x86 2.4 at work
and my other work. This I can say, I'm not going back to Unixware,
not after seeing this performance and development tools.
---Bob
palo...@netcom.com
--
+------------------------+-----------------------------+
| palo...@fiver.sns.com | Fiver Enterpises Inc |
| palo...@eng.sun.com | x86 Solairs 2.4 |
| palo...@netcom.com | Development and Integration |
+------------------------+-----------------------------+
Kari Sutela
>But when do we get mwm, the COSE CDE, and so on?
I think that we get mwm and other Motif stuff, but from what I heard,
this is not the COSE/CDE release, yet.
--
Kari Sutela sut...@utu.fi
Jussi Eloranta
>m...@clark.net (Marc Fraioli) writes:
>
>>But when do we get mwm, the COSE CDE, and so on?
>
>I think that we get mwm and other Motif stuff, but from what I heard,
>this is not the COSE/CDE release, yet.
>
package which you would have to buy separately?!? Hopefully this is
wrong information!?!?
Jussi
Kari Sutela
>There was a rumor (heard at cebit) that cose/cde would be a separate
>package which you would have to buy separately?!? Hopefully this is
>wrong information!?!?
I received the impression that initial developer releases of cose/cde
are indeed a separate package. However, when it's ready, it'll be
bundled with the normal OS.
--
Kari Sutela sut...@utu.fi
Andrew Harrison SUNUK Consultancy
>
>: It has a lot of bug fixes, a lot of performance improvements,
>: A journalled file system, a Motif based administrative frontend, Motif
>This filesystem, is it the Veritas filesystem?
>
>: Casper
No it is not.
Andrew Harrison SUNUK Consulting
Ruth Milner
>It has a lot of bug fixes, a lot of performance improvements,
>A journalled file system,
Will this filesystem be either an optional alternative to the current one or
a compatible extension which doesn't require re-newfs-ing all our disks? The
mere thought of having to back up, newfs, and restore more than 100GB of disk
(or, worse, tell the users they have to do it :-) ) makes my head hurt ...
--
Ruth Milner NRAO/VLA Socorro NM
Manager of Computing Systems rmi...@aoc.nrao.edu
Colin Campbell
: What is a journalled file system?
The filesystem is set up with a circular log of changes made to be made to
the filesystem. As each change is made that log entry is deleted. At this
stage the filesystem is guaranteed(?) to be correct. If the system crashes
all that need be done to bring the filesystem up to scratch is complete
the transactions in the log. No need to fsck. Filesystem recovers in seconds
regardless of the size.
Most implemetations of SVR4 use Veritas' JFS. Sun are doing their own. Who
says you can't make wheels rounder :-).
Colin
Steve McKinty - SunConnect ICNC
I don't know the specifics of the Sun one, but my previous experience
(with other hardware) is that it is a file system which records all
changes made, to a separate medium. Say you have a critical file system,
you make a backup every night then during the day you 'journal' (i.e.
record) all changes to a second disk. If you have a failure of the
main system, head crash or similar, you can restore the backup and
process the journal entries to recreate all changes up to the point
of failure.
Its essential for banks & such like which require integrity. Imagine
a transfer of money from one account to another. After debiting
account A, and just before you credit account B, the disk fails.
You've just 'lost' the money! With a journal you can either restart
the operation, or backout the initial debit.
Steve
--
Steve McKinty
Sun Microsystems ICNC
38240 Meylan, France
email: smck...@france.sun.com
Simon Leinen
>> MCMLXXXXIV, Ricus Leirus <le...@midas.prior.com> ecribat:
> The Main features of Solaris 2.4 are :
> [...]
> Localizations: (same as Solaris 2.3)
> European : french german italian swedish latin [... :-)]
^^^^^ wow!
Ceterum censeo "Fenestras" delendas esse! :-)
--
Simonus.
Casper H.S. Dik
>In article c...@mail.fwi.uva.nl, cas...@fwi.uva.nl (Casper H.S. Dik) writes:
>>It has a lot of bug fixes, a lot of performance improvements,
>>A journalled file system,
>Will this filesystem be either an optional alternative to the current one or
>a compatible extension which doesn't require re-newfs-ing all our disks? The
>mere thought of having to back up, newfs, and restore more than 100GB of disk
>(or, worse, tell the users they have to do it :-) ) makes my head hurt ...
>--
They won't remove the BSD fs, that's for sure.
And, although the Solaris 2.4 release announcements mentions the
new fs as part of the base OS, someone later told me that 2.4
only includes *hooks* for a journalled filesystem and not the thing
itself.
If this JFS is part of Solaris 2.4, it will be just another FS, not
a replacement of one of teh already existing fses.
Casper
Rick Leir
Does anyone know when Solaris 2.4 is
going to be released?
Does anyone know what enhancements and
new features it will have over 2.3?
Sun tells me (snip -- snip):
The Main features of Solaris 2.4 are :
x86 and SPARC Source code Merge
Administration enhancements :
Install GUI uses Motif
Install GUI enhancements
AutoInstall (repackaged Jumpstart
x86 installation improved (better kdmconfig and sysidtool)
Size estimates more accurate
Improved upgrade capablity(add/remove pkgs during upgrade)
DiskSuite 2.0 is now bundled in Workgroup and Enterprise editions
Graphics/Imaging/Multimedia:
Alot of bugfixing and Performance ehnhancements
XGL 3.1 has Transparent overlay support
Pex 2.2
XIL 1.2
XTL 1.0 (for telephony support)
Openwindows 3.4:
Imagetool adds Kodak PhotoCD support
AccessX keyboard support for handicapped
support to Map Ctrl-Alt combo to Meta-key on x86
OW repackaging ( prepares for CDE)
Performance
MT-safe Xlib
MBX support ( multibuffering extenstion to X)
DDK has info to support Trasparent Overlays
DPS lib reordered to give smaller working set
SunOS 5.4, networking and utilities
journalled filesystem include on servers with DiskSuite 2.0
vold :semi-smart on x86 because no autoeject on PC's
MT: MT-HOT server interface for TI-RPC
NIS+ : Bug fixes
Performance :
Database- 10 % improvement over Solaris 2.3
networking- 20 % improvement over Solaris 2.3
Localizations: (same as Solaris 2.3)
European : french german italian swedish latin american spanish
Asian : japanses korean chinese/PRC chinese/taiwan
(snip -- snip)
It looks as if CDE might be on a separate cd. cheers -- Rick
--
Rick Leir Voice: 613-721-0902
Gallium Software Net: rl...@gallium.com
Anatoly M. Lisovsky
>In <2q6r2k$m...@clarknet.clark.net> m...@clark.net (Marc Fraioli) writes:
>
>>In article c...@mail.fwi.uva.nl, cas...@fwi.uva.nl (Casper H.S. Dik) writes:
>>>It has a lot of bug fixes, a lot of performance improvements,
>>>A journalled file system, a Motif based administrative frontend, Motif
>> ^^^^^ ^^^^^
>>>are some of the new features. The announcement of 2.4 als maentions
>>>all kinds of stuiff new in 2.2 and 2.3 but that's because it's also
>>>the jump from 2.1 x86 to 2.4 x86.
>
>>But when do we get mwm, the COSE CDE, and so on? They promised, but it's
>>taking a little longer than they said it would...
>
>With 2.4--that's why "Motif" is up there :)
>
>My understanding is that it will be CDE "compliant"--they were talking
>heavily about CDE at the Solaris Developer's Conference.
>
BTW, somebody told me, that Solaris 2.4 was donated to Solaris
Development Conference members.
Is it true, or not?
--
Anatoly M. Lisovsky, KAMAZ Inc., General Economics Department, STAR division
------------ The Network is The Computer. Per Aspera ad Sun! ---------------
Philip Brown
: Sun tells me (snip -- snip):
: The Main features of Solaris 2.4 are :
: x86 and SPARC Source code Merge
: Administration enhancements :
: Install GUI uses Motif
: Install GUI enhancements
[etc]
Note that nowhere does it say we get Motif programming libraries.. just
that the TOOLs have switched to run-time Motif stuff.
Can anyone definately confirm or deny that Motif will be bundled as the
default GUI programming library, instead of OpenLook ?
Andre April
: If this JFS is part of Solaris 2.4, it will be just another FS, not
: a replacement of one of teh already existing fses.
: Casper
I hope that Sun will provide some interactive backup/restore utilities like
ufsdump / ufsrestore for their JFS !
Andre
-----
Andre April
Unite d'Informatique
Universite Catholique de Louvain
Belgium
E-Mail: a...@info.ucl.ac.be
Tel: +32.10.47.31.13
Pete Clinch
: What's going to happen with the print system, smae old sys V lp
: or is something new in store for us?
The 2.3 release notes said that the current print system was to be
trashed and replaced from 2.4.
Check out p2 of Solaris 2.3 Open Issues and Late Breaking News for System
Administrators for full details.
Pete.
--
Peter Clinch University of Dundee
voice 44 382 60111 x 2050 Department of Medical Physics
fax 44 382 640177 Ninewells Hospital
email pjcl...@dux.dundee.ac.uk Dundee, DD1 9SY, Scotland, UK
Anatoly M. Lisovsky
Leinen writes:
A vot s russkim vsegda hrenovato-s... :(
Ili im ne interesna 1/6 chast mira?
Hey, SunSoft!!!
May i help you?
I suggested you my help about 2 years ago.
Casper H.S. Dik
>Jim Craven (cra...@cg.emr.ca) wrote:
>: What's going to happen with the print system, smae old sys V lp
>: or is something new in store for us?
>The 2.3 release notes said that the current print system was to be
>trashed and replaced from 2.4.
The release notes said ``to be replaced in future''.
It didn't say from 2.4 onwards.
Casper
Wiley Sanders
>BTW, somebody told me, that Solaris 2.4 was donated to Solaris
>Development Conference members.
>Is it true, or not?
2.4 was not part of the kit but there was a coupon to return and
get on the list to receive Early Access (Beta) 2.4 when it is
eventually released.
-w
--
"There is absolutely no truth to the rumor that all employees are
going to be required to have lobotomies . . . at least at the
prices we were quoted." -Dilbert
Bil Lewis
There are many details which we just don't know about yet (like EXACTLY
when the code will be finished -- tho we do have a date, or on which release
of Solaris it will become the default desktop), but one thing we can say for
certain: It will not be a separate item which we charge for.
It may come first on a separate CD, it may not. But it will be part of
Solaris.
-Bil
(Antieksi, mutta Suomi Kiele on very difficult for us poor Americans.)
Kari Sutela (sut...@utu.fi) wrote:
: elor...@kala.cc.jyu.fi (Jussi Eloranta) writes:
: --
: Kari Sutela sut...@utu.fi
--
Three days late! I told you butter wouldn't suit the works.
Bil Lewis
"Default programming library"?? That doesn't mean much. :-)
But more serious... What I *think* you were asking: OL will continue to
be the default desktop & OL libs will continue to ship for years & years to
come. We will bundle Motif 1.2.3 in 2.4 (so you don't have to statically
link), and we will bundle all of CDE when it's ready ('95 some time).
-Bil
Philip Brown (ph...@cats.ucsc.edu) wrote:
: Rick Leir (le...@midas.prior.com) wrote:
: [etc]
Philip Brown
: 2.4 was not part of the kit but there was a coupon to return and
: get on the list to receive Early Access (Beta) 2.4 when it is
: eventually released.
ha.. another "coupon" :-)
Philip Brown
: But more serious... What I *think* you were asking: OL will continue to
: be the default desktop & OL libs will continue to ship for years & years to
: come. We will bundle Motif 1.2.3 in 2.4 (so you don't have to statically
: link), and we will bundle all of CDE when it's ready ('95 some time).
Yeah, but when you say "bundle Motif 1.2.3", I'm presuming you just mean
"will include a shared version of the Motif library, and license thereof".
What about Motif programming libraries?
Frank Peters
>Bil Lewis (ble...@Sun.COM) wrote:
>
>: But more serious... What I *think* you were asking: OL will continue to
>: be the default desktop & OL libs will continue to ship for years & years to
>: come. We will bundle Motif 1.2.3 in 2.4 (so you don't have to statically
>: link), and we will bundle all of CDE when it's ready ('95 some time).
>
>"will include a shared version of the Motif library, and license thereof".
>
>What about Motif programming libraries?
How do "programming libraries" differ from "a shared version of the
Motif library" exactly? Are you asking about libraries for static
linking? Or header files? Or something else?
2.4 will include everything you need (except a C compiler, but then gcc
is free) to compile dynamically linked Motif based executables. It
will probably include everything you need for statically linked
executables (I'm almost certain of this though I did not explicitly
ask) though Sun appears to be trying to discourage the use of static
linking.
I understand that it will also include mwm (the standard motif window
manager...with no CDE modifications) and some "demo" programs using
motif.
--
Frank Peters - UNIX Systems Programmer - Mississippi State University
Internet: f...@CC.MsState.Edu - Phone: (601)325-7030 - FAX: (601)325-8921
Philip Brown
: Philip Brown <ph...@cats.ucsc.edu> says:
: >
: >What about Motif programming libraries?
: How do "programming libraries" differ from "a shared version of the
: Motif library" exactly? Are you asking about libraries for static
: linking? Or header files? Or something else?
Opps. My mistake. I was indeed asking if the "programming package"
(ie header files + library + man pages) would be included.
Ken Bibb
>BTW, somebody told me, that Solaris 2.4 was donated to Solaris
>Development Conference members.
>Is it true, or not?
No, 2.3 was given out, although the documents said that we would be
getting 2.4.
Early access 2.4 will be available, though, sometime in June if I
remember right, for those attendees who signed up for it. A COSE/CDE
"snapshot" cd will also be made available...
--
Ken Bibb "Imagine what it would be like if TV actually were
kb...@qualcomm.com good. It would be the end of everything we know."
jes...@crash.cts.com --Marvin Minsky
Marc Fraioli
>In <2q6r2k$m...@clarknet.clark.net> m...@clark.net (Marc Fraioli) writes:
>
>>In article c...@mail.fwi.uva.nl, cas...@fwi.uva.nl (Casper H.S. Dik) writes:
>>>It has a lot of bug fixes, a lot of performance improvements,
>>>A journalled file system, a Motif based administrative frontend, Motif
>> ^^^^^ ^^^^^
>>>are some of the new features. The announcement of 2.4 als maentions
>>>all kinds of stuiff new in 2.2 and 2.3 but that's because it's also
>>>the jump from 2.1 x86 to 2.4 x86.
>
>>But when do we get mwm, the COSE CDE, and so on? They promised, but it's
>>taking a little longer than they said it would...
>
>With 2.4--that's why "Motif" is up there :)
>
some of the deskset tools and such would be written with the Motif toolkit
in 2.4, the basic system would still be Open Look. I will be happy to be
proven wrong.
---
Marc Fraioli | "They couldn't hit an elephant at this dist- "
m...@clark.net | - Last words of Union General John Sedgwick,
| Battle of Spotsylvania Court House, U.S. Civil War
Jim Craven
or is something new in store for us?
Jim
--
Love is like the ozone layer, |Jim Craven (cra...@cg.emr.ca)|
You don't miss it until it's gone. |Geological Survey of Canada |
---Frank Drebbin, Police Squad |1 Observatory Cres., Ottawa |
-----------------------------------------|K1A 0Y3 (613) 996-9935-------|
Bil Lewis
: (ie header files + library + man pages) would be included.
Nope. For programming you'll need some kind of SDK (ours for example!).
But you will not need to bundle any Motif libraries with your product.
We are also NOT including MWM.
We're making it possible for all apps to run, but we're looking to CDE for
the full desktop/manager/etc.
Yes. Dynamic linking we push. Big time. This is a *GOOD THING*. It is
part of the definition of the ABI. Lemme find an old mail message...
I wrote this Q&A for the CATALYST FLASH. (If you're an ISV, you want
this. You probably have it.)
________________________________________________________________
Q: What happened to the static libraries in Solaris 2??
A1: They're gone.
A2: This is a GOOD thing. For your business, for your programming, and for
your immortal soul. Really.
#1: Statically linking libraries into your program takes up more disk space
(bad for you, good for Seagate). How much? Here's the size of hello.c:
dynamic: 5132
static: 147708
#2: Statically linking libraries into your program takes up more physical
memory (bad for you, good for Fujitsu). How much? Harder to say, but...
My workstation has 85 processes running on it now, 64 of them are unique
binaries. If they pulled in say 25% of libc (~1MB) that would add 250K to
each of the 64 at a minimum... 16 MB. 13 of the binaries are using X11...
another 4 MB. And 8 of the binaries use libxview... 6 MB. So from just
taking the most obvious libraries, I'd say we're saving about 25-30 MB of
virtual space by sharing the libraries.
#3: Statically linking libraries into your program breaks the ABI (bad for
your immortal soul). The program you statically linked on 2.0 may not run
on 2.3! The actual numbers assigned to various system calls, register
contents, etc. are not part of the ABI, and are subject to change; whereas
the library calls are part of the ABI and can't be changed.
#4: If there were a bug in a library under 2.2 (this is hypothetical of
course) and that was fixed under 2.3, then a statically linked program
wouldn't get the fix when run under 2.3, but a dynamically linked program
would. Ditto performance improvements.
-Bil
--
Sharks eat Maple Leafs alive!!!
Philip Brown
: Philip Brown (ph...@cats.ucsc.edu) wrote:
: : Frank Peters (f...@CC.MsState.Edu) wrote:
: : : Philip Brown <ph...@cats.ucsc.edu> says:
: : Opps. My mistake. I was indeed asking if the "programming package"
: : (ie header files + library + man pages) would be included.
: Nope. For programming you'll need some kind of SDK (ours for example!).
: But you will not need to bundle any Motif libraries with your product.
Ah. didn't occur to the marketing droids that this is only a half-solution?
This is doing nasty things to Sun's long-standing position as the best
platform for net software. First there was the move to SysV.
A good thing, but straining public relations.
Next, there was the unbundling of a compiler.
Sort of fair enough, as gcc was available.
But now, no more bundled GUI programming possibilities?
It seems like Sun is forcing its customers to choose between a completely
"free software" setup, or putting out the $$$ for their (or third-party)
stuff. This is a dumb move.
For a long, long time, sun has been a good company for systems, because,
if you didn't like how one or more of the supplied programs worked, you
could download something free from the net.
I was actually very impressed when sun finally bundled Xaw with OW3.3
It was a _good_ move.
However, this is another leap backwards.
Presuming sun is ultimately looking towards ditching openlook and moving
everything to motif, this is like saying:
"Use all free stuff, or all commercial stuff".
A giant leap backwards for Sun's future.
I hope the appropriate people get to hear what I'm saying here.
On the other hand, I completely support distributed shared libraries for
Motif. I think this is a Good Thing.
But it sucks to presume Motif is going to be a future standard, and not
help people take full advantage of it.
I'd really like motif on my system. But I'm certainly not going to buy
2.4 if all it gets me is a few extra patches and an extra shared library.
Thomas Wolf
: Bil Lewis (ble...@Sun.COM) wrote:
: : Nope. For programming you'll need some kind of SDK (ours for example!).
: : But you will not need to bundle any Motif libraries with your product.
: Ah. didn't occur to the marketing droids that this is only a half-solution?
: This is doing nasty things to Sun's long-standing position as the best
: platform for net software. First there was the move to SysV.
: A good thing, but straining public relations.
: Next, there was the unbundling of a compiler.
: Sort of fair enough, as gcc was available.
: But now, no more bundled GUI programming possibilities?
: It seems like Sun is forcing its customers to choose between a completely
: "free software" setup, or putting out the $$$ for their (or third-party)
: stuff. This is a dumb move.
: For a long, long time, sun has been a good company for systems, because,
: if you didn't like how one or more of the supplied programs worked, you
: could download something free from the net.
I holeheartedly agree with this: Sun seems to justify these things with
statements like "only developers need these development tools - the
majority of users don't" (at least that seemed to be the theme when
the compiler was unbundled.) This argument, IMHO, was a crock for the
compiler and, presuming Sun really doesn't bundle the base tools (headers and
libraries) necessary to build applications, also is so for the UI.
Sun is making it tougher and tougher to justify buying Sun equipment! As
the previous poster pointed out, I used to recommend Sun because for our
environment (vertical applications) Sun had the most complete set of
development tools available: one could either go with the basic tools
provided by Sun or go to numerous 3rd-party vendors for more sophisticated
needs. If either of those didn't provide what was needed, one could always
find stuff on the net. Now, little by little, the "platform" of basic
components seems to be pulled out from under us. If all that remains are
3rd-party tools and net stuff, what is the motivation (other than support for
the established base of SPARC software/hardware) for sticking with Sun
hardware? Performance certainly isn't top notch anymore (at least in the
single-processor world most of us still live in.)
: A giant leap backwards for Sun's future.
: I hope the appropriate people get to hear what I'm saying here.
I do too. But I'm doubtful that it will have any effect. I think
Sun is no longer exclusively building their hardware/software for the
development community - scientists, engineers writing applications for
vertical markets. They're now also trying to satisfy the gods of
mass-market (without, IMHO, having a mass-market :-( by cutting prices/costs
and making "non-essentials" optional.
Oh well...life goes on, I suppose.
Tom
--
+------------------------------------------+
| Thomas Wolf | (908) 957-3955 |...Still can't think of anything
| Bell Labs, NJ | wo...@merlin.mt.att.com | original to put in my sig...
| MT 4D-213 | wo...@jolt.mt.att.com |...So this valuable real-estate
+------------------------------------------+ is for sale...
Disclaimer: These are my opinions and not necessarily those of my employer.
Bil Lewis
know, and I feel like I'm getting banged around for it! They don't pay us
to do this you know. grumble grumble grumble
Thomas Wolf (wolf@merlin) wrote:
: Philip Brown (ph...@cats.ucsc.edu) wrote:
: : Bil Lewis (ble...@Sun.COM) wrote:
: : : Nope. For programming you'll need some kind of SDK (ours for example!).
: : : But you will not need to bundle any Motif libraries with your product.
: : Ah. didn't occur to the marketing droids that this is only a half-solution?
: : This is doing nasty things to Sun's long-standing position as the best
: : platform for net software. First there was the move to SysV.
Hey! We eliminated the tariff on Motif, we're not ready to release CDE
yet, and we still manage to bundle the libraries earlier than expected.
This is bad??
: I holeheartedly agree with this: Sun seems to justify these things with
: statements like "only developers need these development tools - the
: majority of users don't" (at least that seemed to be the theme when
: the compiler was unbundled.) This argument, IMHO, was a crock for the
It is a business decision, plain & simple. It is true that the majority
of our users don't do compiles & they don't want to pay for the compiler,
why should they? Compilers cost money to build. The only question is how
they get paid for: by higher OS/machine costs or directly?
Anyway, it shouldn't be an emotional issue. You look at what you get for
what price & decide if it's the right thing.
: : I hope the appropriate people get to hear what I'm saying here.
Yes, we do. But we don't always agree. (In this case I personally agree,
however...)
: Oh well...life goes on, I suppose.
: Tom
Yup. We do our best (like to think it's pretty good), then continue with
life. I've got a hang-glider that's felt pretty lonely over the winter &
needs some exercise.
-Bil
Bob Palowoda
: I holeheartedly agree with this: Sun seems to justify these things with
: statements like "only developers need these development tools - the
: majority of users don't" (at least that seemed to be the theme when
: the compiler was unbundled.) This argument, IMHO, was a crock for the
: compiler and, presuming Sun really doesn't bundle the base tools (headers and
: libraries) necessary to build applications, also is so for the UI.
: Sun is making it tougher and tougher to justify buying Sun equipment!
You used the words "presume" and "justify" in the same sentence. I have
found this approach has not worked in consensus teams. I presuming
that if you work for Bell Labs that there is some sort of purchasing
process.
: As
: the previous poster pointed out, I used to recommend Sun because for our
: environment (vertical applications) Sun had the most complete set of
: development tools available: one could either go with the basic tools
: provided by Sun or go to numerous 3rd-party vendors for more sophisticated
: needs. If either of those didn't provide what was needed, one could always
: find stuff on the net. Now, little by little, the "platform" of basic
: components seems to be pulled out from under us. If all that remains are
: 3rd-party tools and net stuff, what is the motivation (other than support for
: the established base of SPARC software/hardware) for sticking with Sun
: hardware? Performance certainly isn't top notch anymore (at least in the
: single-processor world most of us still live in.)
Actually I think Sun has made some well thought out appropreiate decisions.
For both the customer and internal. Let me ask you this, how much do
you think the compiler costs when it's bundled in? You don't know, you
look at the total cost. Thats ok, but lets look the real world for a
moment. Let's say Sun wishes to stay competitive and notices that other
OS's are spawning third party compilers that have a better price/performance
ratio. At some point customers begin to realize that they can get a
better deal on the hardware compiler combination else where. Some have
given a name to this theroy, "shopping". Some people actually go out
and write down all the little hardware features performance measurements
software features compiler costs features make bar charts graphs and
plots and they run around and show these figures to everyone in the
company. These people can be stopped, you whack em over the head with
a big bat and fire them. Sometimes these little twerps get to the
upper management and this also can be stop. You just need a bigger
bat for the management.
You know the bottom line is Sunpro gets to develop what they think
is the best price/perf/feature compiler that they can with no
finacial ties to the hardware group (not directly).
And they branch out creating compilers for other OS such as unixware.
In the end it is one of those win - win situations for both the customer
and manufacture. Does the model work, I think so and this is only my opinion.
: : A giant leap backwards for Sun's future.
: : I hope the appropriate people get to hear what I'm saying here.
: I do too. But I'm doubtful that it will have any effect. I think
: Sun is no longer exclusively building their hardware/software for the
: development community - scientists, engineers writing applications for
: vertical markets. They're now also trying to satisfy the gods of
: mass-market (without, IMHO, having a mass-market :-( by cutting prices/costs
: and making "non-essentials" optional.
Gods! I'm not a marketing guru here but do you think Sun or any
other large corparation could grow selling to just exclusively to
what you have mentioned. Really SMCC what's to sell hardware
Sunpro wants to sell compilers.
: Oh well...life goes on, I suppose.
Actually I got my life at Kmarts for only $9.95.
---Bob
--
+----------------------------+-----------------------------+
| palo...@fiver.sns.com | Fiver Enterpises Inc |
| bob.pa...@eng.sun.com | x86 Solairs 2.4 |
| palo...@netcom.com | Development and Integration |
+----------------------------+-----------------------------+
Frank Peters
> Hey! We eliminated the tariff on Motif, we're not ready to release CDE
>yet, and we still manage to bundle the libraries earlier than expected.
>This is bad??
Not bad particularly. But...
The Motif header files are less than 1MB of data. Comparing mine to
header files on other platforms suggests that there is very little Sun
value added (most of the differences, in fact, seem likely to be slight
differences in the version of Motif included). I can't see anything in
the Motif licensing terms which suggests that it would be particularly
expensive to include header files once the libraries are included (if
Sun has licensed Motif under some strange terms please feel free to
correct me).
Leaving out very low cost (to Sun) header files when you are including
libraries seems odd. Making customers buy a developers toolkit with a
bunch of other stuff they probably don't need in order to get those low
cost header files looks bad...it seems to suggest a disturbing motive
on the part of the person/people who made this decision.
>Thomas Wolf (wolf@merlin) wrote:
>: I holeheartedly agree with this: Sun seems to justify these things with
>: statements like "only developers need these development tools - the
>: majority of users don't" (at least that seemed to be the theme when
>: the compiler was unbundled.) This argument, IMHO, was a crock for the
>
> It is a business decision, plain & simple. It is true that the majority
>of our users don't do compiles & they don't want to pay for the compiler,
>why should they? Compilers cost money to build.
We aren't talking about compilers here. We aren't talking about
development tools like devguide. We're talking about a bunch of *.h
files and manual pages (and I could even live without the manual
pages).
If Sun is serious about remaining popular with the educational and
networked communities then I would suggest the following policy:
Always include the header files and manual pages necessary to link against
any included libraries unless
1) The libraries are intended for Sun internal use only (hopefully not
the case with Motif :) or
2) There is some significant additional cost to including the header
files when the libraries are included.
Adopting this policy would make it possible for your customers to just
ask "do you include Motif?" instead of having to play silly "Well, do
you include the header files? How about manual pages?" games.
None of these comments, of course, are directed at you personally.
Antonio Vasconcelos
: I'd really like motif on my system. But I'm certainly not going to buy
: 2.4 if all it gets me is a few extra patches and an extra shared library.
You are forgeting all the brand new BUGs that will be introduced...
There will be a Motiff-based 'installpatch' real soon now. 8-)))))
--
regards,
Antonio Vasconcelos
@ The Lisbon $tock Exchange (BVL) require 'std/disclaimer.ph'
<<< Money is the root of all bills. >>>
Pete Hartman
> It is a business decision, plain & simple. It is true that the majority
>of our users don't do compiles & they don't want to pay for the compiler,
>why should they? Compilers cost money to build. The only question is how
>they get paid for: by higher OS/machine costs or directly?
>
> Anyway, it shouldn't be an emotional issue. You look at what you get for
>what price & decide if it's the right thing.
It's an emotional issue because people have invested significantly in
Sun equipment, only to find that Sun is removing a lot of what attracted
us to them in the first place, in the name of "business decisions".
You have to ask yourself: "Well, they STILL have things that I need,
but are they going to pull ANOTHER carpet on me with the next release
of the OS?"
Anatoly M. Lisovsky
Rudolf Schreiner writes:
>In article <DAVGZojKOD@fkamaz> you write:
>
>>>> European : french german italian swedish latin [... :-)]
>>> ^^^^^ wow!
>>>Ceterum censeo "Fenestras" delendas esse! :-)
>>A vot s russkim vsegda hrenovato-s... :(
>>Ili im ne interesna 1/6 chast mira?
>
>No Rossia ne 1/6 chast rynka...
Esli smotret ne dalshe sobstvennogo nosa. :)
A kak naschet "Russkoyazychnyh stran"?
I ya ponimayu, that Sun have a lot from NASA, etc...
>In the west many people think, Russia is a part of the 3rd world.
But what does think Sun's office in Moscow?
>They know absolutly NOTHING about your country. You can't imagine
>what terrible nonsense we see in german TV-news about Russia.
>They simply don't understand, that they could earn a lot of money in
>Russia.
BTW, DEC, HP, and IBM have already localized workstations.
>>Hey, SunSoft!!!
>>May i help you?
>>I suggested you my help about 2 years ago.
>
>Did you even get an answer?
Yes.
David Lehmann
> The Main features of Solaris 2.4 are :
> Graphics/Imaging/Multimedia:
> Alot of bugfixing and Performance ehnhancements
> XGL 3.1 has Transparent overlay support
Can you give more details?
> Openwindows 3.4:
> DDK has info to support Trasparent Overlays
More details?
-David
------------------------------------------------------------------------------
David Lehmann Toshiba America Consumer Products, Inc.
Email: da...@toshiba.com Advanced Television Technology Center
Voice: (609)951-8500 ext. 21 202 Carnegie Center, Suite 102
Fax: (609)951-9172 Princeton, NJ 08540
------------------------------------------------------------------------------
Thomas Wolf
: Thomas Wolf (wolf@merlin) wrote:
: You used the words "presume" and "justify" in the same sentence. I have
: found this approach has not worked in consensus teams. I presuming
: that if you work for Bell Labs that there is some sort of purchasing
: process.
Yes there is - and it has always been easier to write a single PO than
two. When the compiler came bundled, I wrote one PO. Now I write two - or
more, since everyone now wants to use a different compiler.
: Actually I think Sun has made some well thought out appropreiate decisions.
: For both the customer and internal. Let me ask you this, how much do
: you think the compiler costs when it's bundled in? You don't know, you
: look at the total cost. Thats ok, but lets look the real world for a
: moment. Let's say Sun wishes to stay competitive and notices that other
: OS's are spawning third party compilers that have a better price/performance
: ratio. At some point customers begin to realize that they can get a
: better deal on the hardware compiler combination else where. Some have
: given a name to this theroy, "shopping". Some people actually go out
The "other OS's" you're referring to are presumably (there goes that word
again :-) DOS/Window/NT, since I know of no other OS's that are spawning
compilers at better price/performance ratios? I don't think Sun should
base their compiler (or tool bundling) decisions on what they see
happening in that world. The two markets are different by an order
of magnitude. Since the Solaris/SunOS market hasn't grown much relative
to the other markets, the price/performance improvement you speak of
haven't happened - and I don't see competition to be fierce enough to
drive down prices as they have in the DOS world.
: You know the bottom line is Sunpro gets to develop what they think
: is the best price/perf/feature compiler that they can with no
: finacial ties to the hardware group (not directly).
: And they branch out creating compilers for other OS such as unixware.
: In the end it is one of those win - win situations for both the customer
: and manufacture. Does the model work, I think so and this is only my opinion.
I don't think it's a win-win situation, since I certainly didn't win in
Sun's scenario. I used to be able to assume a lowest-common-denominator
in tool availability. Now I have to think about the subject - and I'd
rather use my limited abilities for other things :-) That is not to say
that I didn't use better technology (I frequently use tools like
ObjectCenter, SunPro CC, etc. to make my life easier) - but I had a choice;
If I wanted to, I could log into a user's machine and write a small C
program to, say, do some quick debugging/test/tool (this sorta thing happens
when your application user base consists of only a couple users :-) That
option has been taken away (unless I purchased/setup licenses on that user's
machine.)
: Gods! I'm not a marketing guru here but do you think Sun or any
: other large corparation could grow selling to just exclusively to
: what you have mentioned. Really SMCC what's to sell hardware
: Sunpro wants to sell compilers.
I don't think any company can grow appreciably by serving an unchanging user
community (i.e. engineers/scientists in my remarks.) But I do think that
Sun made a mistake in believing that their current user base would stick
with them when an important tool was taken away. I don't know how many new
users Sun attracted with its new policies but, I would venture to guess that
it hasn't increased dramatically. Market-share wise (workstation market),
Sun has actually dropped over the past few years. The latter statistic
implies that (a) more new users are flocking to the other workstation
vendors, (b) that more Sun users moved to other vendors than other
vendors' users went to Sun, or (c) both (a) and (b) - none of which
confirm that Sun's strategy was successful.
: : Oh well...life goes on, I suppose.
: Actually I got my life at Kmarts for only $9.95.
I got my Life on a Blue-Light-Special - I paid $7.95 for the same thing!
Paul Eggert
> You know the bottom line is Sunpro gets to develop what they think
Yes, Sunpro is free to invest their development effort wherever they please.
Nobody is forcing Sunpro at gunpoint to listen to its current customers,
and if Sunpro abandons them they'll just have to take their business elsewhere.
Ruth Milner
>Q: What happened to the static libraries in Solaris 2??
>
>(bad for you, good for Seagate).
>
>memory (bad for you, good for Fujitsu). How much? Harder to say, but...
Has Sun done any benchmarks on the performance of statically- vs dynamically-
linked executables? We have some numbers which suggest that, at least when
the executables are accessed over NFS, dynamically-linked programs run as
much as 20% slower than statically-linked ones. This is fairly significant.
Any idea why this might happen (network congestion can't be the sole cause)?
BTW, this application package uses around 800MB for three versions of source
and executables. So trying to replicate it locally to get the best perfor-
mance out of dynamic linking would make Seagate a lot happier than linking
one remotely-accessed statically-linked copy!
--
Ruth Milner NRAO/VLA Socorro NM
Manager of Computing Systems rmi...@aoc.nrao.edu
John DiMarco
>Q: What happened to the static libraries in Solaris 2??
>A1: They're gone.
Not quite. On my 2.3 system, ls /usr/lib/lib*.a returns:
/usr/lib/lib300.a /usr/lib/libcmd.a /usr/lib/libnisdb.a
/usr/lib/lib300s.a /usr/lib/libcrypt.a@ /usr/lib/libnls.a
/usr/lib/lib4014.a /usr/lib/libcrypt_i.a /usr/lib/libnsl.a
/usr/lib/lib450.a /usr/lib/libelf.a /usr/lib/libpkg.a
/usr/lib/libTL.a /usr/lib/libgenIO.a /usr/lib/libplot.a
/usr/lib/libadm.a /usr/lib/libintl.a /usr/lib/librac.a
/usr/lib/libauth.a /usr/lib/libkrb.a /usr/lib/librpcsvc.a
/usr/lib/libbsdmalloc.a /usr/lib/libkvm.a@ /usr/lib/libsocket.a
/usr/lib/libbsm.a /usr/lib/libm.a /usr/lib/libthread_db.a
/usr/lib/libc.a /usr/lib/libmail.a /usr/lib/libvolmgt.a
/usr/lib/libc2.a@ /usr/lib/libmapmalloc.a /usr/lib/libvt0.a
/usr/lib/libc2stubs.a /usr/lib/libmp.a /usr/lib/libw.a
It doesn't look like they're "gone" to me.
>A2: This is a GOOD thing. For your business, for your programming, and for
>your immortal soul. Really.
There are occasional good reasons to statically link things. These include:
- a need to run very early in the boot process, when the dynamic
libraries are not available.
- avoiding OSF's Motif licence fees for distributing Motif-based s/w.
- security (eg. tripwire should not be dynamically linked, and
dynamically linked apps can't find libraries when chroot'ed)
I'd moderate Bil's recommendation somewhat: only link statically if you have
a good reason.
> Sharks eat Maple Leafs alive!!!
Grr, uppity californian newbies!!!
Regards,
John
--
John DiMarco j...@cdf.toronto.edu
Computing Disciplines Facility Systems Manager j...@cdf.utoronto.ca
University of Toronto EA201B,(416)978-1928
Bob Palowoda
: palo...@netcom.com (Bob Palowoda) writes:
If your going to quote me please include the whole sentence as to keep
the context. I did not give any indication that Sunpro is ignoring
customer compiler issues.
Casper H.S. Dik
>Has Sun done any benchmarks on the performance of statically- vs dynamically-
>linked executables? We have some numbers which suggest that, at least when
>the executables are accessed over NFS, dynamically-linked programs run as
>much as 20% slower than statically-linked ones. This is fairly significant.
>Any idea why this might happen (network congestion can't be the sole cause)?
I guess this depends on many factors. First of all, shared libraries
do have a price: you need some extra (unshared) data space for the
indirect jump tables and the dynamic linker needs some memory too.
The second costs is some extra function call overhead for shared libraries
and a large startup cost. The last bit is especially noticable in shell
script. Because expr and such are dynamically linked with four different
shared libraries, shell scripts using lots of expr/seds/other small,
short-lived programs, run dramatically slower under Solaris 2.3.
(they would crawl on 2.2 and earlier, 2.3 is better)
The gains are mainly in working set size. For libc the savings are big:
you run many different apps, all with the same lib. Smaller workingset
size, especially as soon as programs use stdio.
However, if you have a set of big libraries and you run only one
different app against that library at the same time, you'll pay both in
workingset size and in unshared memory use.
E.g., if the only X program running on a machine is xterm, but many
of them, linking xterm statically with the X libs is better. The
textsegment will be shared anyway, and you won't have the datasegment
dynamic linking overhead.
In SunOS 4.1.x, tehre is another important effect that may muddy the
figures you see: the .so and .sa split. If your program references
data from the sharedlib that's not in libfoo.sa, or the major.minor
number of libfoo.sa doesn't exactly match the highest number of libfoo.so,
the text segment of the executable linked against that library will not
longer be shared because it needs fixing up at runtime.
This is often seen on sites that installed a libc.so.x.y (w/
resolver or otherwise) w/o updating libc.sa. to the same revsion
number. Since most programs will reference stderr or errno, all
applications linked after teh installation of this library will
have a disastrous effect on memory use.
Casper
Frederick Herrmann
>: Frank Peters (f...@CC.MsState.Edu) wrote:
>: : Philip Brown <ph...@cats.ucsc.edu> says:
>: Opps. My mistake. I was indeed asking if the "programming package"
>: (ie header files + library + man pages) would be included.
> Nope. For programming you'll need some kind of SDK (ours for example!).
> But you will not need to bundle any Motif libraries with your product.
This statement betrays the assumption that anyone doing programming
must be developing a product. Sun's unbundling policies seem based on
the idea that there are only two types of customers: users and
developers.
The majority of sun customers might now fit into one of the two
groups. I don't know, I'm just an out-of-touch graduate student. But
I think it's understandable that user-programmers in the scientific
and engineering communities are feeling abandoned.
Damnit Jim, I'm a circuit designer, not a software developer... but I
spend a lot of time writing code for my own and my colleague's use.
- Fritz
fr...@mtl.mit.edu
Frederick P. Herrmann, speaking only for himself
Richard M. Mathews
>In article c...@mail.fwi.uva.nl, cas...@fwi.uva.nl (Casper H.S. Dik) writes:
>>It has a lot of bug fixes, a lot of performance improvements,
>>A journalled file system,
>Will this filesystem be either an optional alternative to the current one or
>a compatible extension which doesn't require re-newfs-ing all our disks? The
>mere thought of having to back up, newfs, and restore more than 100GB of disk
>(or, worse, tell the users they have to do it :-) ) makes my head hurt ...
My understanding of the journalled file system is that it is just UFS plus
a log. The log is stored in a separate device. There is no change at
all to the UFS format or to backup, newfs, etc. If you remove the log,
you revert to old-style UFS operation. Adding journalling to existing
file systems is certainly optional.
Richard M. Mathews Freedom for Lithuania
ric...@West.Sun.COM Laisve!
Steve Lindsey
> In article <palowodaC...@netcom.com> you wrote:
> : You know the bottom line is Sunpro gets to develop what they think
> : is the best price/perf/feature compiler that they can with no
> : finacial ties to the hardware group (not directly).
> : And they branch out creating compilers for other OS such as unixware.
> : In the end it is one of those win - win situations for both the customer
> : and manufacture. Does the model work, I think so and this is only my opinion.
>
> I don't think it's a win-win situation, since I certainly didn't win in
> Sun's scenario. I used to be able to assume a lowest-common-denominator
> in tool availability.
it's shipped with EVERY Sun computer; and the support (I you choose to buy it) from
Cygnus is good. IMHO the GNU/Cygnus C compiler is much better than the old cc. In
addition it is ANSI compliant.
If you need a more powerful development environment, then you have at least three
good options:
1. SunPro
2. Apogee
3. Centerline
Please remember that these are my opinions.
#include <standard_disclaimer_so_the_laywers_won't_sue_me.h>
---
/\
\\ \
\ \\ / Steve Lindsey
/ \/ / / Sun Microsystems Computer Corporation
/ / \//\ 1501 Robert J. Conlan Boulevard, Suite 160
\//\ / / Palm Bay, Florida 32905
/ / /\ / steve....@east.sun.com
/ \\ \ (407) 725-7115 voice
\ \\ (407) 725-6805 FAX
\/
Pete Hartman
>The one thing I haven't heard mentioned is the Cygnus/Gnu C compiler. It's FREE;
>it's shipped with EVERY Sun computer; and the support (I you choose to buy it) from
>Cygnus is good. IMHO the GNU/Cygnus C compiler is much better than the old cc. In
>addition it is ANSI compliant.
It would be really nice if people posted less than 80-character lines
for those of us in the normal world.
>If you need a more powerful development environment, then you have at least three
>good options:
>
> 1. SunPro
> 2. Apogee
> 3. Centerline
Those are all wonderful, but that wasn't what was being discussed.
Yes, GNU C is excellent.
No, GNU C does NOT include all possible header files that would
ever be wanted. If SUN is going to ship particular libraries
with their systems, then SUN should also ship the header files
necessary to USE those libraries with whatever compiler the system
owner thinks is appropriate.
This is not to say that Sun IS NOT doing so, but there is obviously
some question, given their attitude about breaking up their OS
features so far. And that is the source of the discussion; not
any thought that at this late date there was a way that Sun would
provide a free development environment.
So: IS Sun going to ship Motif headers and reference material with
the Motif libraries so that the masses can actually USE the libraries?
Bil Lewis
: Has Sun done any benchmarks on the performance of statically- vs dynamically-
: linked executables? We have some numbers which suggest that, at least when
: the executables are accessed over NFS, dynamically-linked programs run as
: much as 20% slower than statically-linked ones. This is fairly significant.
: Any idea why this might happen (network congestion can't be the sole cause)?
Not benchmarks, but order-of-magnitude tests. OOM is zero. STARTUP times
are significently higher, but once the application is linked & running (and
fits in core) there is no noticable degradation.
(Except for the exceptions.)
-Bil
--
Three days late! I told you butter wouldn't suit the works.
Benson I. Margulies
HP unbundles the real C compiler.
AIX dosen't quite do so yet, but is on the verge.
Ultrix unbundles the ANSI C compiler.
and EVERYONE unbundles C++, and, like it or not,
that is the way the language winds are blowing.
How do you want Sun to be competitive in the face of
this?
--
Benson I. Margulies
Kenji Okamoto
| : majority of users don't" (at least that seemed to be the theme when
| : the compiler was unbundled.) This argument, IMHO, was a crock for the
|
| It is a business decision, plain & simple. It is true that the majority
| of our users don't do compiles & they don't want to pay for the compiler,
| why should they? Compilers cost money to build. The only question is how
| they get paid for: by higher OS/machine costs or directly?
I agree with his opinion, if I look around me. ^_^
Futhermore, I think Sun is going rather well on this subject, because
they dropped just only C compiler itself. We have all the header files,
linker, assembler etc. So, we just need gcc.
However, please get rid of stupid bugs as soon as possible without any
additional payment. I don't like to pay any money to fix the bugs.
Kenji
------------------------------------------------------------------------------
Kenji Okamoto | e-mail oka...@earth.cias.osakafu-u.ac.jp
______ __ |__ | Universiy of Osaka Prefecture, Dept. of Earth Science,
|__\/__| /|\ | Gakuen-cho 1 - 1, Sakai, Osaka 593, Japan
||_|_| | /-|-\ | old e-mail: oka...@asuws3.la.asu.edu
------------------------------------------------------------------------------
Bob Palowoda
: The "other OS's" you're referring to are presumably (there goes that word
: again :-) DOS/Window/NT, since I know of no other OS's that are spawning
: compilers at better price/performance ratios?
I think we should backup and list the UNIX OS the deliver free
compilers with them. I agree that DOS/Windows are not a fair
comparison so who delivers a free compiler with their workstation.
DEC?
: I don't think Sun should
: base their compiler (or tool bundling) decisions on what they see
: happening in that world.
Yea but Sun blew it, they hired someone from New York and all
hell broke lose.
: The two markets are different by an order
: of magnitude. Since the Solaris/SunOS market hasn't grown much relative
: to the other markets, the price/performance improvement you speak of
: haven't happened - and I don't see competition to be fierce enough to
: drive down prices as they have in the DOS world.
So do you ever think it will change? If so when? How?
How will you know when it changes?
: I don't think it's a win-win situation, since I certainly didn't win in
: Sun's scenario. I used to be able to assume a lowest-common-denominator
: in tool availability. Now I have to think about the subject - and I'd
: rather use my limited abilities for other things :-)
I'm suprised you don't have someone within Bell Labs that gives you
more input on purchase.
: program to, say, do some quick debugging/test/tool (this sorta thing happens
: when your application user base consists of only a couple users :-) That
: option has been taken away (unless I purchased/setup licenses on that user's
: machine.)
What about GCC?
: I don't think any company can grow appreciably by serving an unchanging user
: community (i.e. engineers/scientists in my remarks.)
So what is a company going to do when they reach that point?
What are the stockholders going to say?
: Sun has actually dropped over the past few years. The latter statistic
: implies that (a) more new users are flocking to the other workstation
: vendors, (b) that more Sun users moved to other vendors than other
: vendors' users went to Sun, or (c) both (a) and (b) - none of which
: confirm that Sun's strategy was successful.
Boy I wish marketing was that simpile, at least it used to be at
one point in time. Basiclly I agree with some of your basic assumptions
Sun has lost some of the workstation market. I don't feel it has
alot to do with the compiler issue. Still you can't always under
estimate a moving target.
---Bob
Disclaimer: These are not the expressed opinions of any past or present
working relations.
Antonio Vasconcelos
:
: You know the bottom line is Sunpro gets to develop what they think
: is the best price/perf/feature compiler that they can with no
: finacial ties to the hardware group (not directly).
: And they branch out creating compilers for other OS such as unixware.
: In the end it is one of those win - win situations for both the customer
: and manufacture. Does the model work, I think so and this is only my opinion.
The funny part is that now, Software houses like Borland and
(God forbide it) Microsoft have a virgin market for their
C/C++, GUI compilers. What do you think ? "Borland C++ 2.1 for
Motiff..." ?! Sounds great.
--
regards,
Antonio Vasconcelos
@ The Lisbon $tock Exchange (BVL) require 'std/disclaimer.ph'
<<< A hammer sometimes misses its mark - a bouquet never >>>
Casper H.S. Dik
>Let's see:
>HP unbundles the real C compiler.
>AIX dosen't quite do so yet, but is on the verge.
>Ultrix unbundles the ANSI C compiler.
SGI unbundles the compilers, the headers and other stuff you need
for development and NFS.
Casper
Jeff Vosburg
week and guess what, it still had a bundled C compiler! Now
if I want to run Solaris2 (which I actually do) then I must
either get gcc or buy a compiler. BIG DEAL! Every SysV Unix
I've ever run required me to purchase a compiler. So now
we are to the fourth release of Solaris 2 and you're still
complaining. GET OVER IT!!
As for Sun losing workstation market share - where? Sun's
sales have increased quarter after quarter and they are still
the volume Unix leader. HP is larger in Unix dollars, but
the average HP costs more than the average Sun and HP sells
a whole lot more big servers, which of course cost more. I
haven't seen a break down of workstations versus servers, but
I would bet Sun still ships more "workstations" than anyone
else.
I started following this thread to find out what feature
would be in 2.4. Instead, I get the same old, tired
religious wars. STICK TO THE SUBJECT!
------------------------------------------------------------------
Jeff Vosburg
Internet: vos...@mli.mot.com
X.400: Jeff_Vosb...@email.mot.com
Motorola Lighting and Energy Products Division
DISCLAIMER: All views are entirely my own opinions and probably wrong!
-------------------------------------------------------------------
Casper H.S. Dik
>Sun will *not* be including all of the header files with Motif. You'll
>need to buy a separate package (with stuff you probably don't need or
>want) in order to get those header files. This, if it becomes a trend,
>represents a much more substantial change than the unbundling of the
>compiler.
This would indeed be a bad move. However, you should keep in mind
that there still is a number of possible future actions possible.
The two differen ways to extrapolate from ``no Motif headers''
in 2.4 is this:
method 1: all headers will be dropped in future.
method 2: Sun adds the Motif lib and will add the rest
of Motif in future (CDE release?)
Personally, I would find the unbundling of headers from the OS
hard to swallow. It would mean that you can no longer support
third party compilers onless you buy Sun's SDK. No other
vendor can possibly produce a set of headers to match Solaris 2.x
libraries in all details.
SGI has set a bad example here that shouldn't be followed.
It is also very common in the x86 Unix market, which is
a market Solaris 2.x is targetted for as well. So
the big question is: will Sun try to compete by offering
a similarly stripped down ``Unix'' in the x86 (and consequently
probaby the SPARC and PPC market as well) or will
they try to compete with value add in the form of a
basic OS set of headers, *including all headers needed for
libraries shipped with Solaris*.
I believe it is early enough to voice concern, but too early to
complain. As things stand now the Motif runtime was moved from the SDK
to the base release, which is some form of improvement. However, we
should not forget that all the developer's answerbooks where moved to
the SDK in 2.3, away from the base answerbook release. That was a move
that makes you fear the worst for future Solaris releases.
Casper
Marc Fraioli
horsepower than SPARC, an ANSI-C compiler is bundled, Motif headers and libs
(both shared and static) are included, and they even give you a CD full of
freeware (including gcc with g++), much of it pre-compiled for your convenience
(all of it including source too, of course). Heck, DEC OSF/1 even includes
emacs (with source) in the OS distribution.
---
Marc Fraioli | "They couldn't hit an elephant at this dist- "
m...@clark.net | - Last words of Union General John Sedgwick,
| Battle of Spotsylvania Court House, U.S. Civil War
Frank Peters
>ble...@Sun.COM wrote in the article of <2qp5u1$q...@engnews2.Eng.Sun.COM> .
> |
> | of our users don't do compiles & they don't want to pay for the compiler,
> | why should they? Compilers cost money to build. The only question is how
> | they get paid for: by higher OS/machine costs or directly?
>
>I agree with his opinion, if I look around me. ^_^
>Futhermore, I think Sun is going rather well on this subject, because
>they dropped just only C compiler itself. We have all the header files,
>linker, assembler etc. So, we just need gcc.
I think that you missed the start of this thread.
Sun will *not* be including all of the header files with Motif. You'll
need to buy a separate package (with stuff you probably don't need or
want) in order to get those header files. This, if it becomes a trend,
represents a much more substantial change than the unbundling of the
compiler.
Casper H.S. Dik
>God what a bunch of whinners! I loaded the latest 4.1.3 last
>week and guess what, it still had a bundled C compiler! Now
>if I want to run Solaris2 (which I actually do) then I must
>either get gcc or buy a compiler. BIG DEAL! Every SysV Unix
>I've ever run required me to purchase a compiler. So now
>we are to the fourth release of Solaris 2 and you're still
>complaining. GET OVER IT!!
Right. Though I wouldn't mind having a penny for each time someone
complaints over in comp.lang.c that their Sun compiler doesn't
understand their ANSI-C programs.
>As for Sun losing workstation market share - where? Sun's
>sales have increased quarter after quarter and they are still
>the volume Unix leader. HP is larger in Unix dollars, but
>the average HP costs more than the average Sun and HP sells
>a whole lot more big servers, which of course cost more. I
>haven't seen a break down of workstations versus servers, but
>I would bet Sun still ships more "workstations" than anyone
>else.
Yes. By a margin. I believe that HP and Sun are very close
in $$ market share but Sun ships twice the number of systems.
This makes Sun's installed base grow really fast. And Sun's
current offerings give the best price/performance by a wide
margin. Only people needing really hot boxes need to look
elsewhere.
Casper
Vic Abell
> .UCSC.EDU> <CpL6s...@nntpa.cb.att.com> <palowodaC...@netcom.com> <Cpnny...@nntpa.cb.att.com> <1994May12.1...@schbbs.mot.com>
> NNTP-Posting-Host: adam.fwi.uva.nl
>
> vos...@mli.mot.com (Jeff Vosburg) writes:
>
> >As for Sun losing workstation market share - where? Sun's
> >sales have increased quarter after quarter and they are still
> >the volume Unix leader. HP is larger in Unix dollars, but
> >the average HP costs more than the average Sun and HP sells
> >a whole lot more big servers, which of course cost more. I
> >haven't seen a break down of workstations versus servers, but
> >I would bet Sun still ships more "workstations" than anyone
> >else.
>
> Yes. By a margin. I believe that HP and Sun are very close
> in $$ market share but Sun ships twice the number of systems.
> This makes Sun's installed base grow really fast. And Sun's
> current offerings give the best price/performance by a wide
> margin. Only people needing really hot boxes need to look
> elsewhere.
Dataquest reports (and RS/Magazine repeats in Volume 3, Number
5, May 1994) that HP's UNIX market share, based on the strength
of its sales of servers and midrange computers, was 19.5% in
1993 (revenue $3,834.5 in millions); Sun's, 18.2% ($3,588.9);
IBM's, 11.8% ($2,307.1); DEC, 5.6% ($1,098.4); and SGI, 5.5%
($1,087.7). I don't have details that would show what share of
each vendor's sales were work stations, servers, etc.
Ruth Milner
>Ruth Milner (rmi...@Mr-Hyde.aoc.nrao.edu) wrote:
>: Has Sun done any benchmarks on the performance of statically- vs dynamically-
>: linked executables? We have some numbers which suggest that, at least when
>: the executables are accessed over NFS, dynamically-linked programs run as
>: much as 20% slower than statically-linked ones.
>
>are significently higher, but once the application is linked & running (and
>fits in core) there is no noticable degradation.
>
> (Except for the exceptions.)
Any details available on the tests done (i.e. what programs were used)?
Especially the exceptions ... :-)
Ours are large applications that can run for hours, so the startup overhead
*should* be very small as a percentage of total running time.
Why do you specify "fits in core"? Does a large dynamically-linked executable
page more while running than a large statically-linked one? I'd have thought
it would page less since there should be a greater chance of having what it
needed in memory (less stuff loaded that it doesn't need).
Matt Kennel
: God what a bunch of whinners! I loaded the latest 4.1.3 last
: week and guess what, it still had a bundled C compiler! Now
: if I want to run Solaris2 (which I actually do) then I must
: either get gcc or buy a compiler. BIG DEAL! Every SysV Unix
: I've ever run required me to purchase a compiler. So now
: we are to the fourth release of Solaris 2 and you're still
: complaining. GET OVER IT!!
WHY?
You know, *some* people don't exactly see SysV as a shining paladin of
virtue and good to be worshipped.
: Jeff Vosburg
--
-Matt Kennel m...@inls1.ucsd.edu
-Institute for Nonlinear Science, University of California, San Diego
-*** AD: Archive for nonlinear dynamics papers & programs: FTP to
-*** lyapunov.ucsd.edu, username "anonymous".
Matt Kennel
: Let's see:
Sort of like the upper-class twit of the year competition, I guess.
: --
: Benson I. Margulies
James Litchfield
> was made as to the amount of disk space consumed by this program and
> it was large.
Keep in mind that this may well be an NFS problem rather than shared
libs since all paging that is done for the executable code pages will
be done over the net. Local swap is used for anonymous memory (stack
and malloced memory, etc) but the place where code pages are read from
as needed is the executable - across the net. They are not copied into
local swap so you're trading 3MB/sec of disk bandwidth for 1MB/sec of
network access.
Jim
Antonio Vasconcelos
: My understanding of the journalled file system is that it is just UFS plus
: a log. The log is stored in a separate device. There is no change at
: all to the UFS format or to backup, newfs, etc. If you remove the log,
: you revert to old-style UFS operation. Adding journalling to existing
: file systems is certainly optional.
That's not my understanding of journalled file system. As I understand
it, it's saffer than an usual fs, ok, but that's not the major
improvment, the fact is that it should be possible to increase the
size of a file system if you have unallocated space on disk, and with
the filesystem on-line.
Some of the more advanced implementations will let you REDUCE the size
of the filesystem, but you'll have to unmount it for that opperation,
but I'm not expecting Sun to include such a clever thing in Solaris.
I'll be happy if you could just increase the size.
On the other hand, I don't even belive that you could do that, as Sun
is not jumping up and down announcing something that other unix'es had
for years. Let's wait and see...
--
regards,
Antonio Vasconcelos
@ The Lisbon $tock Exchange (BVL) require 'std/disclaimer.ph'
<<< Too much glory can be half disgrace. >>>
Alain Fauconnet
>DEC is looking better and better for technical markets. Alpha has more CPU
>horsepower than SPARC, an ANSI-C compiler is bundled, Motif headers and libs
>(both shared and static) are included, and they even give you a CD full of
>freeware (including gcc with g++), much of it pre-compiled for your convenience
>(all of it including source too, of course). Heck, DEC OSF/1 even includes
>emacs (with source) in the OS distribution.
Hey! We are a technical shop, we've been nearly 100% DEC for years
and we recently have moved to Sun systems. This was a carefully
studied choice, taking into account the culture shock and all the
pain to migrate sofware (ours and 3rd party's).
Here's why:
DEC has been playing unfair games for too long with us, phasing
out tools we had under contract and call the next version a
"different product", discontinuing support for existing
controllers (DEQNA Ethernet etc.), and so on. They don't seem to
be very positive with software vendors either. An unnamed company
which sells a Common Lisp environment recently told us that they
gave up the idea of porting their software to Alpha platforms
because of DEC's refusal to lend a porting machine. That's
probably why many of our key development tools still don't work on
DEC/OSF-1.
The Alpha systems might be hot boxes, but they still don't seem
to gain a significant part of the Unix market, definitely less
that the "critical mass" that gives easy availability of PD
software ports, enough mutual technical support on the net and
all the things buying Sun gives you.
During the past few years, DEC has been trying too hard to steal
market shares to IBM in the business/bank domains. They have lost
the contact with their technical (mainly academic/research)
installed base. They have reached a level of formalism and
bureaucracy (at least here in France) that equals or exceeds
IBM's. Being a "techie" seems to be a real shame now among most of
DEC employees.
So... they might have the hottest boxes now, but everything else
is a nightmare.
_Alain_ (a previous DEC addict who used to think that there was no
salute out of Maynard)
--
Alain FAUCONNET Ingenieur systeme - System Manager AP-HP/SIM
Public Health Research Labs 91 bld de l'Hopital 75013 PARIS FRANCE
Mail: a...@biomath.jussieu.fr (*no* NeXTmail !)
Tel: (+33) 1-40-77-96-19 Fax: (+33) 1-45-86-80-68
Ruth Milner
>> Comments about slow execution with shared libs via NFS. Mention
>> was made as to the amount of disk space consumed by this program and
>> it was large.
The main query was not simply that dynamically-linked executables run slowly
over NFS, but that dynamically-linked programs run more slowly than
statically-linked ones - *both* over NFS.
>Keep in mind that this may well be an NFS problem rather than shared
>libs since all paging that is done for the executable code pages will
>be done over the net.
But this is true of statically-linked executables, too (isn't it?). This
is why I don't believe that network traffic is the only, or even primary,
source of the difference; they both have that in common - unless one does
much more paging than the other, of course.
The magnitude of the difference is quite significant - as much as 20%.
Startup overhead is greater for the dynamic executables, but startup time
is nothing like 20% of the total running time. Similarly, both types of
executable use NFS for paging. Are there situations where a dynamically-
linked executable does significantly more paging than a statically-linked
version of the same code running on the same system? Are there other areas
where the behavior of the two differs, which might account for this?
Essentially all data (and there's a lot of it) is local in both cases, BTW.
Ian Donaldson
>ric...@astro.West.Sun.COM (Richard M. Mathews) writes:
>: My understanding of the journalled file system is that it is just UFS plus
>: a log. The log is stored in a separate device. There is no change at
>: all to the UFS format or to backup, newfs, etc. If you remove the log,
>: you revert to old-style UFS operation. Adding journalling to existing
>: file systems is certainly optional.
>That's not my understanding of journalled file system. As I understand
>it, it's saffer than an usual fs, ok, but that's not the major
>improvment, the fact is that it should be possible to increase the
>size of a file system if you have unallocated space on disk, and with
>the filesystem on-line.
What has dynamically increassing the size of a filesystem got to do
with journalling? It should be possible with UFS to dyamically
increase its size, by simply writing more cylinder groups at the end
and updating all the super blocks to say there are more inodes...
(presumably there is a virtual to physical mapping available to virtually
extend a partition onto another physical device or somesuch; trivial
things to do in software). Reducing the size is more compilicated and
time consuming, as data beyond the new size would need to be moved to
other inodes.
The things important with journalling include:
- fast crash recovery. Very little time spent in "fsck" type programs.
- better crash recovery. Very little or no chance that a file will be lost,
and a selection of previous versions to choose from. Recovery
can invole replay of recent activity from separate log(s).
- better write performance. If designed right, delays due to synchronous
write's should not be required. (of course there are other ways
to achieve this, such as things like PrestoServ NVRAM but that's extra
hardware)
Other improvements could also be done to enhance security also...
for example by having each block have a back pointer to the inode that
owns it, so that one person's data can't easily appear in another's inode
due to a crash where data gets written to the wrong sectors (a common
thing with flakey hardware or kernel bugs). There is of course a slight space
cost with this. But this is not anything to do with journalling either;
just something one hopes would go into any new filesystem design.
Ian D
John Martinez
for my personal use!
As far as non-x86 goes, though, I think Solaris is still one of the better
OS's (even if it doesn't have a compiler bundled with it).
My $0.02...
-john
--
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
% John Martinez (mart...@bats.com) UNIX System Administration Services %
% BreakAway Technology Services, San Jose, CA %
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
Obi Thomas
> As far as non-x86 goes, though, I think Solaris is still one of the better
> OS's (even if it doesn't have a compiler bundled with it).
I agree. I recently upgraded this SPARCstation 10 from 4.1.3 to 5.3 and
find that the OS is just as stable and reliable as 4.1.3. However,
debugging is much superior on 5.3 (SunPro debugger offers many more
features in 5.3 --- probably because of /proc?).
To get good performance, I had to increase maxusers in /etc/system. This
made a *huge* difference in performance speed. There may be other things
that can also yield performance boosts; as a developer who must administer
my own workstation I haven't had the time to carefully read the AnswerBook
for Administrators yet.
It may be my imagination but output to xterms seems slightly slower than
on 4.1.3. I'm running X11R5 patch level 26 with Casper Dik's mods and the
IBM Type1 rasterizer. This too may yield to kernel tuning.
Jack Morrison
>Sun will *not* be including all of the header files with Motif. You'll
>need to buy a separate package (with stuff you probably don't need or
>want) in order to get those header files. This, if it becomes a trend,
>represents a much more substantial change than the unbundling of the
>compiler.
Excuse me, but there is *no* Motif in any SunOS up through 5.3. And they never
promised a COSE/Motif environment in 5.4. So if they *add* some Motif apps,
and the dynamic libraries (so you don't need gimungous static executables),
why are you griping about "stuff being taken away"?
Surely all the XView and Olit headers and libraries will still be there.
OK, there's no K&R compiler, but that's old news...
---
"How am I typing? Call 1-818-354-7782" ja...@robotics.jpl.nasa.gov
Jack Morrison/Jet Propulsion Lab/MS107-102 4800 Oak Grove Dr, Pasadena CA 91109
Casper H.S. Dik
>That's not my understanding of journalled file system. As I understand
>it, it's saffer than an usual fs, ok, but that's not the major
>improvment, the fact is that it should be possible to increase the
>size of a file system if you have unallocated space on disk, and with
>the filesystem on-line.
You're misinformed. The primary objective of a journalled filesystem
is much improved (faster, more reliable) crash recovery.
There are other, non-journalled, fs-es that do allow space allocation
to grow. I believe that Online Diskuite does just that,
>Some of the more advanced implementations will let you REDUCE the size
>of the filesystem, but you'll have to unmount it for that opperation,
>but I'm not expecting Sun to include such a clever thing in Solaris.
>I'll be happy if you could just increase the size.
As part of Online-Disksuite, which apparently is going to be included
with enterprise server versions of Solaris 2.4 and later.
Casper
Heiko Blume
>Surely all the XView and Olit headers and libraries will still be there.
>OK, there's no K&R compiler, but that's old news...
what makes you think so? sun might argue that you do not need these headers
as well if you are not a developer, saving their customers precious disk
space...what use are header files if you don't have a compiler anyway?
--
s...@contrib.de, Contributed Software, Graefestr 76, D-10967 Berlin, Germany
Voice: (+49 30) 694 69 07, Data: (+49 30) 6934051 [8 lines] 6946055 [5 lines]
<a HREF="http://www.contrib.de/">www.contrib.de</a>
Casper H.S. Dik
>ja...@robotics.jpl.nasa.gov (Jack Morrison) writes:
>>Surely all the XView and Olit headers and libraries will still be there.
>>OK, there's no K&R compiler, but that's old news...
>what makes you think so? sun might argue that you do not need these headers
>as well if you are not a developer, saving their customers precious disk
>space...what use are header files if you don't have a compiler anyway?
What makes you think they are removed? Sun argued that they wated making
3rd party compiler building competitive. To this end they still included:
- libraries (shared & unshared)
- headers (can't be provided by third party)
- assembler
- linker
If Sun stops shipping headers, and there are no indications they will,
they've been lying to us all along. On the otehr hand, if otehr
vendors get away with shipping insufficient stuff to support gcc,
perhaps Sun might follow suit.
Casper
Frank Peters
>In article 8...@Jester.CC.MsState.Edu, f...@CC.MsState.Edu (Frank Peters) writes:
>
>>Sun will *not* be including all of the header files with Motif. You'll
>>need to buy a separate package (with stuff you probably don't need or
>>want) in order to get those header files. This, if it becomes a trend,
>>represents a much more substantial change than the unbundling of the
>>compiler.
>
>Excuse me, but there is *no* Motif in any SunOS up through 5.3. And they never
>promised a COSE/Motif environment in 5.4. So if they *add* some Motif apps,
>and the dynamic libraries (so you don't need gimungous static executables),
>why are you griping about "stuff being taken away"?
I'm not. The words "taken away" appear nowhere in my post.
Until now, Sun has included relevant header files for all of the
libraries they've shipped (with the exception of some functions
intended for internal use only). This has made free and low cost
development tools (like gcc) more practical. Now Sun will begin
shipping a library without its include files.
If this is a one time temporary thing it isn't that big a deal.
If its a trend for packages in the future it is disturbing for those of
us who compile network software or do low end student development and
are looking for low cost development platforms.
Bart Smaalders
working on the 2.4 product and examining the current internal
distribution), 2.4 _will_ include the Motif header files
with the run-time Motif package. We expect product developers
to get the SDK, but you can compile w/o it.
Any statements to the contrary are and were inoperative :=).
- Bart Smaalders CDE Performance SunSoft
Speaking _only_ for myself....
John Martinez
Frank Peters
According to information posted here by a Sun employee, no.
That isn't too unreasonable. CDE (the COSE environment) is not yet
available and will be a good deal different from mwm. So they may
want users to continue using olwm until they can migrate to CDE
rather than having users migrate from olwm to mwm (under the
mistaken impression that they are gaining something) and then
have to migrate to CDE in the future.
Terence Cross
>In article <2r11mv$h...@engnews2.Eng.Sun.COM> ji...@bardolph.Eng.Sun.COM writes:
>>> Comments about slow execution with shared libs via NFS. Mention
>>> was made as to the amount of disk space consumed by this program and
>>> it was large.
>
>The main query was not simply that dynamically-linked executables run slowly
>over NFS, but that dynamically-linked programs run more slowly than
>statically-linked ones - *both* over NFS.
>
>>Keep in mind that this may well be an NFS problem rather than shared
>>libs since all paging that is done for the executable code pages will
>>be done over the net.
Well, only if your processor has no local disk. In which case the file will
be loaded to the local swap disk & paged from there.
>
>But this is true of statically-linked executables, too (isn't it?). This
>is why I don't believe that network traffic is the only, or even primary,
>source of the difference; they both have that in common - unless one does
>much more paging than the other, of course.
>
>The magnitude of the difference is quite significant - as much as 20%.
Have you tested it with many people sharing at the same time? I can't understand 20%,
There is only 1 layer of indirection to provide the dynamic mapping.
If the shared object is reasonable autonomous & does not share many glob vars
& is not called on every second line from the executable then the
indirection should not be used needed too often. You could try setting
the shell variable LD_BIND_NOW to 1, otherwise the first time
a function is called the name must be searched for in all objects.
I suppose you follow the guidlines to reduce paging, grouping
much-used & related function together. Have you checked
the figures for paging activity & compared the stats?
Ruth Milner
>In article 7...@Mr-Hyde.aoc.nrao.edu, rmi...@Mr-Hyde.aoc.nrao.edu (Ruth Milner) writes:
>>why dynamically-linked programs run more slowly than
>if your processor has a local disk ... the file will
>be loaded to the local swap disk & paged from there.
I don't think it works this way after SunOS 4.0 . So far as I know it pages
code segments from the original on-disk image. Hence the "bus error" when
you overwrite the original with something still running.
>>The magnitude of the difference is quite significant - as much as 20%.
>Have you tested it with many people sharing at the same time?
No, unfortunately, just benchmarked it both ways on one system. We don't
have the disk space at the moment to build the copy everyone uses statically
without doing considerable disruptive rearrangement. We may in a few weeks,
though. For the test we used a private partition on the server.
>If the shared object is reasonable autonomous & does not share many glob vars
>& is not called on every second line from the executable then the
>indirection should not be used needed too often.
Hmmm ... well, it does use a fair number of global variables. There is a very
large number of COMMON blocks, for example. And most of the low-level opera-
tions, which are used by many of the tasks, are separated into subroutines
which are then built into the libraries. Could this be largely the source of
the problem, then?
>You could try setting
>the shell variable LD_BIND_NOW to 1, otherwise the first time
>a function is called the name must be searched for in all objects.
Would this actually save time overall, or just move the binding overhead
to the startup period?
>I suppose you follow the guidlines to reduce paging, grouping
>much-used & related function together.
Yes, this application has been around for many years and used to have to
worry about systems with very small amounts of memory. So it has been very
thoroughly tuned for locality of reference.
>Have you checked
>the figures for paging activity & compared the stats?
I don't think that was done during the test. I'll look into arranging for it
to be done again to see if we can glean some more information.
Many thanks for the suggestions!
Jeff Vosburg
Excellent point.
------------------------------------------------------------------
Jeff Vosburg
Internet: vos...@mli.mot.com
X.400: Jeff_Vosb...@email.mot.com
Motorola Lighting and Energy Products Division
DISCLAIMER: All views are entirely my own opinions and probably wrong!
-------------------------------------------------------------------
Charles Hedrick
If you're interested in a motif-like look, but don't want to buy
Motif, consider fvwm. It's not exactly an mwm clone, because the
exact features aren't the same and the configuration files aren't
compatible. But the look of the decorations is pretty much the same,
and unless you're using some really abstruse features, you should be
able to configure fvwm to give you very close to the same behavior,
menu structure, function key bindings, etc, as mwm. It's distributed
with configuration files to more or less emulate mwm and 4Dwm. I have
mwm available on my Suns at Rutgers, but I'm using fvwm because I want
to use the same window manager on Linux at home. (We've generally
stayed away from proprietary software as part of our default setup for
exactly this reason. We've got lots of students who want to be able
to use free software at home.)
Terence Cross
>In article <2rdkve$e...@euas20.eua.ericsson.se> eei...@eua.ericsson.se writes:
>>if your processor has a local disk ... the file will
>>be loaded to the local swap disk & paged from there.
>
>I don't think it works this way after SunOS 4.0 . So far as I know it pages
>code segments from the original on-disk image. Hence the "bus error" when
>you overwrite the original with something still running.
>
My system is configured so that all shared libs are distributed to
local disk & not using NFS. This is alot more efficient. It is also
possible to lock the pages in memory. But I see what you mean about the
way the swapping works for > SunOS 4.
...
>>If the shared object is reasonable autonomous & does not share many glob vars
>>& is not called on every second line from the executable then the
>>indirection should not be used needed too often.
>
>Hmmm ... well, it does use a fair number of global variables. There is a very
>large number of COMMON blocks, for example. And most of the low-level opera-
>tions, which are used by many of the tasks, are separated into subroutines
>which are then built into the libraries. Could this be largely the source of
>the problem, then?
>
I suppose that if it isn't because of excessive paging (which you can discover
with vmstat(1)) then this could be the problem. Solving it is another matter
though.
Maybe it will not be so bad in the live-environment; if a large number of processes
are going to be using the shared object then maybe it will be relatively
more efficient that the static one.
>>You could try setting
>>the shell variable LD_BIND_NOW to 1, otherwise the first time
>>a function is called the name must be searched for in all objects.
>
>Would this actually save time overall, or just move the binding overhead
>to the startup period?
Yes. It just moves the time. Improves running speed after start-up. It Saves
the first-time funtion call search for function addresses.
>
>>I suppose you follow the guidlines to reduce paging, grouping
>>much-used & related function together.
>
>Yes, this application has been around for many years and used to have to
>worry about systems with very small amounts of memory. So it has been very
>thoroughly tuned for locality of reference.
>
>>Have you checked
>>the figures for paging activity & compared the stats?
>
>I don't think that was done during the test. I'll look into arranging for it
>to be done again to see if we can glean some more information.
If you do eventually find out why it is 20% worse I'd be quite interested.
>
>Many thanks for the suggestions!
>--
>Ruth Milner NRAO/VLA Socorro NM
>Manager of Computing Systems rmi...@aoc.nrao.edu
Terence Cross Stockholm, Sweden + 46 8 727 3224 (fax ...4360)
Computer Engineer Terenc...@eua.ericsson.se
Jeff Vosburg
Update - Arrived today:
According to Dataquest (SunExpert, Vol 5, May 84) Sun continued
to lead in workstation sales. Also, Sun's 1993 market share was
17.5, so they actually INCREASED their market share and their
revenue!
Andreas Kromke
>In comp.unix.solaris article <m0q0rTB...@bustan.greenie.muc.de>
> Rudolf Schreiner writes:
>
>>In article <DAVGZojKOD@fkamaz> you write:
>>
>>>>> European : french german italian swedish latin [... :-)]
>>>> ^^^^^ wow!
>>>>Ceterum censeo "Fenestras" delendas esse! :-)
fenestrae delendae ?
Frank Greco
But I think Ruth was comparing apples and apples. She had a
dynamically linked vs statically linked app where the app was
NFS-mounted in *both* cases. Text pages are coming across the
wire for both.
Maybe using the cache fs would help? Just a thought.
Frank G.
--
+-On Assignment at: Lehman Brothers-+-Office: Mercury Technologies, Inc.-+
| World Financial Center, 11th Floor| 53 Wall Street - Fifth Floor |
| New York City, NY 10285 Desk: 1515| New York City, NY 10005 |
| email: fgr...@lehman.com | email: fgr...@mercury.com |
Colin Campbell
While we are on the subject of configurable wm's there is one (xwm?) that
is the `emacs' of window managers. It has/is a LISP interpreter so you
can define your look and feel to whatever you want. It comes with some
setups already amongst which is one that is mwm l+f.
Colin
Charles Hedrick (hed...@geneva.rutgers.edu) wrote:
Joerg Czeranski
> [someone wrote:]
> >>>>> European : french german italian swedish latin [... :-)]
> >>>> ^^^^^ wow!
> >>>>Ceterum censeo "Fenestras" delendas esse! :-)
> fenestrae delendae ?
No, fenestras is right; "fenestras delendas esse" is an ACI.
BTW the quoting is rather confusing. :-)
joerg
--
Joerg Czeranski EMail czer...@rz.tu-clausthal.de
Osteroeder Strasse 55 SMTP injc@[139.174.2.10]
D38678 Clausthal-Zellerfeld Voice (at work) +49-5323-72-3896
Germany Voice (at home) +49-5323-78858
Anatoly M. Lisovsky
<1994May26.1...@newsserver.rrzn.uni-hannover.de> Andreas
Kromke writes:
Sorry, it's mistake. I wrote Russian.
--
Anatoly M. Lisovsky, S/H Company KAMAZ Inc., General Financing Department
------------ The Network is The Computer. Per Aspera ad Sun! ---------------