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. > >>> 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 :-). > >>> 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. 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. 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. >>> 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, 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. 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. 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. > 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. > 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. One of those requirements is that anyone can build the software anywhere. 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. 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. - Bart -- Bart Smaalders Solaris Kernel Performance barts at cyber.eng.sun.com http://blogs.sun.com/barts
