Subject: Re: Solaris 2.4 -- feature list

From: [email-masked] (Rick Leir)
Date: 05 May 1994 13:22:02 GMT

In article <[email-masked]> [email-masked] (Graham Crawford) writes:

	   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:   [email-masked] 

Status: RO

Status: RO

Status: RO

---

From: [email-masked] (Steve McKinty - SunConnect ICNC)
Date: 5 May 1994 09:03:15 GMT

In article <[email-masked]>, [email-masked] (Pete Hartman) writes:
> [email-masked] (Casper H.S. Dik) writes:
> >A journalled file system,
> 
> What is a journalled file system?

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: [email-masked]

---

From: [email-masked] (Bil Lewis)
Date: 6 May 1994 23:40:52 GMT

Yes, I can tell you!  The answer is: N/A.

  "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 ([email-masked]) wrote:
: Rick Leir ([email-masked]) wrote:

: : 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 ?

--
  Three days late!  I told you butter wouldn't suit the works.

---

From: [email-masked] (Bil Lewis)
Date: 9 May 1994 23:11:33 GMT

Philip Brown ([email-masked]) wrote:
: Frank Peters ([email-masked]) wrote:
: : Philip Brown <[email-masked]> 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.

  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!!!

---

From: [email-masked] (Bil Lewis)
Date: 10 May 1994 23:38:41 GMT

Damn it!  I'm trying to be helpful by taking time out to share what I
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 ([email-masked]) wrote:
: : Bil Lewis ([email-masked]) 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

---

From: [email-masked] (Bob Palowoda)
Date: Wed, 11 May 1994 07:05:11 GMT

: 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.

  Actually I got my life at Kmarts for only $9.95.

---Bob

-- 
+----------------------------+-----------------------------+
| [email-masked]     | Fiver Enterpises Inc        |
| [email-masked]   | x86 Solairs 2.4             | 
| [email-masked]        | Development and Integration |
+----------------------------+-----------------------------+

---

From: [email-masked] (Frank Peters)
Date: 11 May 1994 08:38:50 -0500

>yet, and we still manage to bundle the libraries earlier than expected.

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.

>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.

-- 
Frank Peters  -  UNIX Systems Programmer  -  Mississippi State University
Internet: [email-masked]  -  Phone: (601)325-7030  -  FAX: (601)325-8921