On Thu, Mar 13, 2008 at 7:06 AM, Joerg Schilling <Joerg.Schilling at fokus.fraunhofer.de> wrote: > "Garrett D'Amore" <Garrett.Damore at Sun.COM> wrote: > > If we're stuck with model one, then you should probably consider > > abandoning the notion that star will replace /bin/tar (at least for Sun > > Solaris -- the ability to make Solaris specific features is too > > important, and OpenSolaris can't block bug fixes or progress on Joerg > > Schilling -- any more than they could block on Garrett D'Amore.) > > If you believe you need this model for OpenSolaris, then you do not like an > open developement for OpenSolaris where people who have project specific > skills > decide about the future of a project.
Open Development and requiring a specific architecture for projects that wish to integrate are two different things. Requiring a specific architecture, methods, or other criteria for projects that wish to integrate does not mean that development is not open. Many "open source" projects have very stringent requirements for integration of utilities or code. I don't see these as being any different. There is a difference between star being *part* of the OS, or just an add-on piece. If you want star to be a well-integrated, polished, bit of software that looks and acts like part of the OpenSolaris operating system, then you have to follow certain rules. > write code that depends on non-portable libraries. I would not call such > software "true OpenSource" as the ethics for OSS as defined around 1980 > require > portability. Your definition of "open source" is, however, not the generally accepted one. Open source in today's software culture does not imply anything about portability; it only implies a certain distribution and/or licensing model. > > That's an awful lot of tests. > > > > I suspect many of those tests have "pat" answers on Solaris though. I'm > > still not convinced that autoconfiguration is a worthwhile direction for > > ON -- in fact I think it may prove to be more harmful. > > Thinking "portable" typically increases code quality. This would help to > increase the code quality of many sources included in ON. It would also greatly increase engineering costs. A platform should be focused on its own needs; not that of others unless demanded. It isn't practical from a business perspective to expect Sun to ensure portability of code to platforms that they have no viable interest in. -- Shawn Walker, Software and Systems Analyst http://binarycrusader.blogspot.com/ "To err is human -- and to blame it on a computer is even more so." - Robert Orben
