On Sun, 30 Dec 2007, [EMAIL PROTECTED] wrote: >> But do you consider ksh93 to be a "sound architectural decision"? It was >> integrating a piece of open source software from my view, and replacing a >> component that was already in place. > > Did you actually follow the discussion? The ARC discussion of ksh93 > belied the fact that it was a "simple Open Source" integration. > > It was not and many things weren't so obvious as they seemed on the > surface (just install /usr/bin/ksh93 which would have been a fast track). > > No, the fact of the matter was that it was much more complicated, > specifically because of all of ksh93's builtins which don't work > quite the same way as their Solaris counterparts all of the time.
Certainly it was complicated, but it was not any architecture change, and it certainly wasn't re-architecting a component of Solaris, other than integrating. > And your point is? This is a known problem which can not be addressed > quickly; for one we're hampered with a model which assumes a flat, open, > network and secondly in order to get up into the developer hierarchy > you need experience and apart from ex-Sun employees there are few, if any, > outsiders with the needed credentials. > > But that is all to be expected; we can argue that the pace is wrong > but that doesn't fix the problem. I'm not even arguing it, my point was two-fold. 1) Nobody in the community has proposed any type of architectural change, or any type of project that has gone through ARC that would be something substantial to work on. I haven't seen anything, even for something as adding ext2/3 support, and I'm sure a lot of folks would like that. 2) Even if they do, they are still under the same limitations, and nobody outside of SWAN can really do anything. CAB/OGB has expertise, but only by association (i.e., you, Keith, Jim, et al), but under OGB there is little power in the process. > Nothing, I hope. That isn't part of their role. Well, it's the only body that gets voted on for the community, so when Roy speaks of voting rights and getting things approved, there has been nothing that has tied all of this together. It's all smoke and mirrors. > And your point is? Again, this is a known technical shortcoming which > is being fixed. Well, saying the community has an active role and can participate is moot, and I'm not trying to push the process any faster, just being a realist. The fact is that we are where we are today, and we're moving forward. > There clearly needs to be a mechanism for Sun where it can deviate from > OpenSolaris for its products (be it in some Solaris update or what not) > > But that is largely irrelevant for the community apart from the minor > detail that conflicts between the Solaris binary releases will need to > be reflected in some source repository somewhere inside Sun. And possibly > with a makefile setting for a consolidation which says "build bits for > Sun's official release" vs "build all bits". It is very important though, that the system goes through OpenSolaris and Solaris is a user of OpenSolaris just like any other distribution. Until we get to that point, OpenSolaris is caught in the "Darwin Syndrome", where Sun just tosses a tarball over the firewall for the community. If the community does changes they can't do a putback and would need to keep merging their changes with new tarballs. I do know this is being fixed, and has been underway, but we need to be realist about this and not try to kid ourselves into believing the community has a role that someone has tossed a couple buzzwords on. I believe OpenSolaris is making good progress, but let's be honest with each other on the process as it is today. -- Alan DuBoff - Solaris x86 IHV/OEM Group _______________________________________________ driver-discuss mailing list driver-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/driver-discuss
