On Fri, Apr 14, 2006 at 09:46:36AM -0400, Dennis Clarke wrote: > >> 1) large scale participation of OpenSolaris developers/users. > > That is a "want" or a "need" ?
I'd suggest it's desirable from a technical perspective, but essential for overall success. > >> 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. While I respect your dogged determination to continue supporting obsolete platforms (I loved 4m as much as anyone), the reality is that the number of people who actually still use this platform is vanishingly small. Smaller still is the number who use this platform for any reason other than support for some obsolete but still useful and tremendously expensive hardware (manufacturing or scientific equipment). Unless the ability to support such obsolete platforms is essentially free - and clearly it isn't, if the hardware is not supported by the current OpenSolaris codebase - the cost would seem to outweigh the rather miniscule benefits. It would seem far more valuable to target current or recently shipped hardware and the OpenSolaris release under current development. The ability to support obsolete hardware and software platforms is a "want"; the ability to take advantage of modern features is, for a large subset of the target user base at least, a "need." All that said, I'm interested in learning whether anyone thinks support for older hardware and software platforms could be accomplished for, say, the cost of typing make on an old build machine. > >> 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. Even given the assumption that support for older Solaris releases (I find it ironic that an OpenSolaris project would desire to explicitly target operating systems which are not OpenSolaris-derived) is required, suggestions regarding virtual dependencies may be a better option. While these approaches are not without flaws, they do address at least some subset of the problem. Without yet having a full understanding of how such a system would work in the domain of OpenSolaris-based distributions, my initial impression is that, despite the known flaws, some type of virtual dependency structure would be preferable to forcing early adopters to pay a tax in the form of forced installation of duplicated (and often confusingly different) software components. Perhaps we acknowledge that there is no way to completely eliminate (or avoid) the challenges associated with support for older releases. In that case, we must decide who must pay the associated tax. Users who stubbornly stick to outdated operating system releases? Those who are using the most current releases? The component owners? Upstream developers? Users of a particular distribution or distributions? Where the tax must be assessed depends to a large extent on the project's overarching goals: whom do we wish to serve? > 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. What requirements, if any, does this impose on component owners? > 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. Yes, exactly. > 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. There's much more to this problem than saying "use Solaris 8" or "use SchilliX 0.5." Because most of the software under discussion is designed under the assumption that the ultimate execution environment will be that of the build host, a much more complete specification is required. For example, what must or must not be present in /usr/local? /opt/sfw (or /opt/csw or /opt/nonamesoftware)? Is it necessary to install any or all of the most recent binary distribution of third-party software before building? Will the build system utilise a proto area, and if so, how can autotools be taught to use it and ignore installed bits? > 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 Nothing is being reproduced; existing work done in the past is being opened, and the discussion is focused on improvements that can be made in the future. As I've pointed out already, those improvements may be adopted from and shared with those made by existing efforts rather than being reproduced if that is the technically correct approach. > 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. Here's some: the number of Sun-employed engineers assigned to work on the Companion Software project is zero. Sun is not a single individual with 60,000 hands typing away to further its unified master goal of ruining your life. Jonathan didn't come to us and hand us $20 million to put Blastwave out of business. The questions here are being asked by a handful of interested engineers working mostly in our free (or stolen) time. Sun management's actual interest in and commitment to the effort, including the assignment of this phantom resource pool, is almost nonexistent. -- Keith M Wesolowski "Sir, we're surrounded!" Solaris Kernel Team "Excellent; we can attack in any direction!"
