James Carlson wrote: > those who are claiming that all the software world outside > of Sun is Volatile by mere dint of not having an SMI paycheck > are in fact *WRONG*
I absolutely agree. But I think there is another meme flowing thru this conversation: > If it really is the case that the upstream is known to make > unpredictable and even baldly stupid moves, then ... > But when the upstream really is sensible, and doesn't > deliberately break their own software I think you missed my point - and provide an example of what I meant when I said > We used to think that incompatible changes to > interfaces found in/on Solaris were always Bad, > and that evolutionary stability was always a > Good Thing. Yes, stability is important, but it is not the only thing that matters. Under your words, I hear "everything will be OK if we can achieve interface stability; if we can't, all we can do is punt" (and, yes, I am taking your statements to an unwarranted extreme :-) I think we need to admit up front that the traditional Sun Interface Taxonomy simply does not work for most "pass it on" FOSS projects - the only pragmatic answer to "what does this project team promise to commit to" is "nothing", because no matter what the past track record is from the upstream provider, they have no choice but to follow their lead going forward. The traditional Interface Taxonomy assumes that we have the option of not passing on (or re-engineering or deferring or ...) incompatible changes so we can live up to our commitments of stability. In today's environment, we don't have that option, and furthermore, nobody but us expects us to use those options in the first place. If GDB does something we ourselves wouldn't have done, we still have to ship the new version on to our users - or those same users will go elsewhere to get it. They (and we) don't have the option of doing without it, and we don't have the resources to re-engineer it. So let's not go there. Step back and take a big breath. What do *we*, the Operating System / OpenSolaris Distro Developer need from these FOSS projects? IM(ns)HO, we need: 1) If we are building a dependency on it from within our system, we need a way to install and find a version that works with all the other core pieces co-located within the system and that won't be changed if someone installs additional versions. 2) If we want others to be able to use this component, we it need it to be discoverable by them and usable when/where it is found. 3) We must allow for other versions of the thing to be installed, in additional locations if need be, even if those versions are incompatible with our stacks or other components. However it is done, installation of another version of something must not negatively impact existing installed silos. To me, this sounds a lot like the JDK/JRE work that jek3 did - and the work that was going on in WSARC around architecting multiple coherent silos, with symlinks from /usr/bin and application ld.so linkage dependencies into one specific silo along with the ability to create and install alternative (potentially sparse) silos. Rather than having an architecture that only allows for a single global silo of "plays well with others" apps and libs, this moves us towards a world of multiple silos. Each silo would have an assumption of stability within the stack, and no promises outside itself. - sort of like multiple co-instralled WOS's... This isn't easy - but it isn't impossible, either, given some leadership and a desire to make something that works. Rather than dumping a boil-the-ocean requirement on each and every FOSS project to acomplish by themselves, mostly in the dark, and without any role models, maybe we could nail down some architectural principles and offer some best practices... Please? -John
