> Dennis Clarke wrote:
>> [ even poorer form to post to a mail list to which I am not subscribed. ]
>>
>>> Bart Smaalders wrote:
>>>> I'm both a user of blastwave and another Sun engineer
>>>> cycle-stealing on this project. From my point of view,
>>>> what I'd like to see happen with a community software
>>>> distribution for Solaris Nevada is:
>>>>
>>>> 1) large scale participation of OpenSolaris developers/users.
>>
>> That is a "want" or a "need" ?
>
> For me, this is a need. Sun laid off the folks doing the
> Companion early last year; it has had little to no work done
> on it since.
Granted .. its a need.
Done.
>
>>
>>>> 2) automatic installation of required software dependencies
>>
>> That feels like a "need".
>
> Yup; it's too clunky to do this by hand and as I'm fond of saying,
> we have these really cool computer thingies that can automate
> routine tasks like this :-).
Just the other day I was able to add numbers with this one here.
Yes, full automation and Phil has a good grip on that I think
although the SVR4 package spec could use some review.
>>>> 3) compilation on recent enough Solaris version that modern
>>>> features can be enabled. Eg mplayer can use XVideo, SSE,
>>>> SMF, etc; where appropriate, amd64 bit versions, etc.
>>
>> That feels like a want. Tough to implement on sun4m.
>>
>
> But to tell you the truth, that's not a very interesting part of
> the space to me. Sun4m shipped w/ 75 Mhz cpus max (discounting the old
> HyperBrokens). They were obsoleted when UltraSparc shipped in
> 1995, 11 years ago. Constraining all the software to run on that
> hardware would be like only supplying software that ran on 486
> machines; doable but clunky and slow.
Bloody miserable actually.
Last login: Fri Apr 14 13:58:33 2006 from 192.168.35.137
---------------------------------------------------------------------------
Sun Microsystems Inc. SunOS 5.8 Generic Patch February 2004
Solaris 8 2/04 s28s_hw4wos_05a SPARC
Copyright 2004 Sun Microsystems, Inc. All Rights Reserved.
Assembled 08 January 2004
SunOS fossil 5.8 Generic_117350-28 sun4m sparc SUNW,SPARCstation-20
--------------------------------------------------------------------------
$
$ echo $PATH
/usr/xpg4/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/dt/bin:/usr/openwin/bin:/usr/ccs/bin:/opt/csw/bin:/opt/csw/sbin
$ echo $SHELL
/usr/xpg4/bin/sh
$
$ /opt/SUNWspro/bin/cc -V
cc: Sun C 5.5 Patch 112760-18 2005/06/14
usage: cc [ options] files. Use 'cc -flags' for details
$ /opt/SUNWspro/bin/CC -V
CC: Sun C++ 5.5 Patch 113817-14 2005/07/19
$
The hostname there is fossil. As in "please bury this thing."
> For me, having the OpenSource software unable to take advantage
> of the last 10 years of evolution in instruction sets and
> 6 years of evolution in operating system features is a non-starter.
Agreed.
> It makes the OpenSolaris platform appear slow and out of date, and
> places it at a huge competitive disadvantage in terms of performance
> and features with respect to systems offering either more
> closely targeted binaries or compiled in place binaries.
You would be surprised how often an open source application gains little
advantage by being a 64-bit build. The same binary on sun4m and sun4u will
operate within 3% of the clock speed limited rate. I am sure you have seen
this too. The creation of and inclusion of chip specific libraries in
dependencies and in ISAEXEC/ISALIST type of directory strucs (
v8,v8plusa,v9,v9a etc etc ) often duplicates and triplicates the efforts
needed to create a single package. For what gain?
I am not being argumentative here. I am often wont to do I know.
I am simply speaking from measured experience.
The other side of the coin exists also. There are applications in which
the virtual memory space and other goodies ( VIS !!! ) can make all the
difference in the world. I still have a copy of Ultra Computing Volume 2
here that shipped with the UltraSparc units that had Creator 3D
framebuffers. The performance of certain operations in UltraSparc with VIS
is just blistering fast.
I am preaching to the choir. Sorry.
>
>>>> 4) No duplication/replacement of libraries already
>>>> present in the target Solaris release.
>>
>> Also super tough given the multiple versions of Solaris to be
>> supported. It may simply be a case where there will be multiple
>> trees of software. Currently Blastwave has a tree for Solaris 8
>> on Sparc and x86. This is then linked to 5.9, 5.10, 5.10.1 and
>> of course 5.11. We do not yet have a link for SchilliX etc.
>>
>> The ultimate solution is to have a source code repository that
>> allows the code changes to be submitted and then have a package
>> produced that targets a given platform. By a build system and
>> in an automated fashion. This is what we are doing at Blastwave
>> now with the new build system.
>>
>
> Excellent. This could be a nice solution to this problem. It's
> going to be tricky, though. I can imagine doing it using zones,
whoa .. zone there. Whoa.
We really need to go back to the drawing board and look at a number of
things to really allow users to fully gain the advantage of zones. I would
really like users to be able to implement some software in the global zone
that is then available to all zones as well as software that can be
implemented per zone and yet NOT exist in the Global zone.
I thought that I was able to do this in build 54 beta of Solaris 10 but my
memory may be wrong.
What I am saying is that we need to take our time and think.
> but getting a lot of that open source build cruft not to grovel
> through /usr/local looking for tools is awkward.
>
>>> It's poor form, I suppose, to follow up on my own comments,
>>> but during today's discussion it became clear to me that
>>> there's likely another requirement for a successful community
>>> software distribution:
>>>
>>> 5) Builds need to to be reproducible in all dimensions,
>>> including time (two builds of the same software at
>>> different times produces the same results), machines
>>> (there's a defined way of configuring build machines
>>> such that it is possible for two individuals to follow
>>> defined steps to configure two different machines that
>>> produce the same results) and space (it is possible for
>>> people anywhere (eg outside of sun, at blastwave, at
>>> sunfreeware, at my house) to download the software,
>>> build instructions and produce the same bits.
>>
>> Is this a "need" or a "want"? In order to ensure that you can
>> reproduce the exact same bits at "your house" then we need to
>> completely spec out the build platform as well as patches etc.
>>
>
> This is a need. It's work; there isn't a lot of glory in it but if
> you've built OpenSolaris, you know what's involved.
over and over and over .. ad infinitum ....
> The real issue is that unless we can say:
>
> "Here are the instructions. Follow these to configure and build
> the companion/blastwave/sunfreeware/..."
>
> we're one disk crash/earthquake/meteor strike/etc from being unable
> to build at all.
good point. bloody excellent in fact.
Also .. there is the issue of compliance with the FSF various licenses
and the need to provide sources etc etc.
> There's nothing more frustrating than discovering that "well, it works
> for me" is the answer to build problems. If one doesn't have a
> defined series of steps to reproduce a build, one is building
> on sand.
granted .. given and received clearly here.
>> The Blastwave build farm uses Solaris 8 as the base because we
>> can be assured that anything that builds on Solaris 8 is promised
>> to work flawlessly on Solaris 9 and 10 etc. I say promised and
>> not "assured". In the event that something does run on Solaris 8
>> but not on Solaris 9 or 10 or 11 then we need to look at the
>> source and perhaps make conditional compile tweaks.
>>
>
> It's going to be harder than that, I'm afraid; you'll need reference
> machine configs for the different build targets, etc.
Yes .. I agree completely. Please see the email that I posted to Kieth.
>> Those sort of changes then need to be fed to the build system such
>> that a unified base package can be produced or a specific software
>> result be produced. In either case you would then need all of
>> this to be reproducable at "your house". This explains why the
>> Blastwave project implemented Subversion such that a person could
>> easily get the code changes.
>>
>> http://svn.blastwave.org/wiki/GettingStarted
>>
>> However, having said all of this, I am still bothered by what appears
>> to be a desire on the part of Sun to reproduce all of this except
>> inside Sun and for the purposes of being "Sun blessed". The only
>> clear benefit being that Sun has all the money and people to do such
>> a thing that will clearly compete with its own Solaris Community
>> project. Yes, that is a combative stance but I see no evidence to
>> suggest any other posture on my part.
>
> What we're doing right now is talking about what I perceive the
> requirements of the [insert name of open source for Solaris project]
> project to be.
I get that now.
I do.
Its an emotional process for me also. I have a tendency to be passionate
about what I believe in. This may be my undoing in life.
> One of those requirements is that anyone can build the
> software anywhere.
An excellent notion to put forwards.
> I can assure you from what I know of our workload
> and headcount, our management isn't interested in having Sun engineers
> build OpenSource software.
Somehow .. I get that now.
> Let's focus on what those of us on this discussion list think
> the requirements of a open source software system for OpenSolaris
> would be. I'm really completely uninterested in Solaris 8. I want
> something that works really well for OpenSolaris/Solaris Nevada.
Here is where we differ.
I feel that we need to support all shipping editions of Solaris.
--
Dennis Clarke
