> > And don't pretend that you know what happened on > day one better than > > anyone else, most of the people involved in this > discussion were also > > there on launch day or /very/ shortly thereafter. > To state otherwise > > is simply revisionist history in the worst sense of > the word. > > > In fact most, if not all, people here are using > Solaris for a *way* longer time, than Shawn does > (2005, if I remember correctly, before 2005 Debian, > before Debian DR-DOS, before DR-DOS MacOS ? ). > > And yes: Before that very day Sun decided to call > Sun-Solaris "OpenSolaris" I hadn't complained a > single time about what Sun feels it should or > shouldn't do with it, not a single time. > > But IF SMI calls something "OpenSolaris", THEN it > must stay (or ever become) OPEN solaris. The name is > what I have the problem with. I mean, okay: Sun > really has opened up very very much of the previously > closed proprietary code and processes. But did they > do so by choice? Did they do so to do their strong > loyal community "a favour" ?? Or were they forced by > circumstances. It doesn't look driven entirely > full-heartedly. > > %martin
(1) there are _no_ altruists (even those who set the needs of others before their own, do so for their own reasons) (2) public for-profit corporations _cannot_ be altruists - they _have_ to show at least intent and plans to achieve return-on-investment for what they do; also see (1) above. (3) there is however such a thing as "enlightened self-interest"; but even where some application of that becomes policy, no policy changes individual behavior all at once (witness that some projects open up a lot later in their life cycle than others). IMO, the name is irrelevant. Much more important is whether there can be a practical mechanism for incorporating alternative implementations (such as the mpt vs itmpt drivers), or other code or programs that Sun wouldn't for whatever reason want to incorporate themselves (like stuff that might have trouble with the DMCA in the US, and so on). Repository-based building, packaging, and installation (which doesn't necessarily mean getting rid of SVR4 pkg compatibility) is IMO an enabling mechanism for some of this, although for some cases, such as overlapping or conflicting drivers (esp. for bootable hardware components), more is probably needed. On the desktop side, it seems to me that sfe and pkgbuild, together with pkg-get, demonstrate how this could be done, as could corresponding evolutions producing some other package format, no doubt.l Oddly enough, a repository-based approach might also be an enabler for package-based compatibility definitions, which might eventually get back to reaching more widely satisfactory solutions to the name issue. (That approach would imply that alternative package schemes might reduce the level of compatibility and associated name usage a distro might be eligible for; but if you want to get down to plain old binary compatibility alone, rather than package-level compatibility, who is going to pay for developing the inverse of appcert, which is to say the test that a distro supports binary compatibility with anything that passes appcert on the same or earlier base, provided all needed libs are present?) So anyway, why not solve technical and administrative problems that encourage alternative distros and components to be explored without actually forking, define measures of compatibility that can be evaluated without undue difficulty, and _then_ waste time complaining about what to allow the result to be called? -- This message was posted from opensolaris.org
