> "Peter Tribble" <[EMAIL PROTECTED]> wrote: > > > I love the experimentation. Heaven only knows we > need it. My > > concern here is that Indiana is trying to be (or is > seen to be, or > > is being marketed as) several different things at > once and, apart > > from the confusion that results, it could end up in > a 'jack of all > > trades, master of none' scenario. > > I also love experimenation but this should only be > done in a platform > clearly marked as experimental playground. > > A plaform that has been announced as "the" > future..... > cannot be used to experiment in areas that endanger > compatibility. > > Jörg
Then maybe we need to see a timeline for when (if) Indiana replaces SXDE or SXCE, with access to a snapshot very close to the one that will _before_ the replacement happens, so that we can apply our compatibility concerns to something that's actually a candidate for replacing anything that presently satisfies those concerns; as contrasted with applying those concerns to something that's still focusing on redistributability, ease of use, ease of installation and updates, etc. If I were to worry about Indiana, it would be that I still don't see SPARC support, and that even if I did, I'd have to revert to my XVR-100 since there looks to be no redistributable driver for the XVR-1000 (thus no Xorg support), which means losing both 3D acceleration (unless there's a new driver that will support that for the XVR-100) _and_ display bandwidth (since my XVR-1000 uses a UPA slot, and the only 66MHz slot in my Ultra 2000 has a SATA controller in it, which also needs to have decent bandwidth). So I for one will stick to SXDE or SXCE (with Studio 11 and 12 added to the latter) until such time as Solaris 11 comes out (assuming it will support my hardware) or Indiana can support my hardware, or I feel like dropping a few thousand on a new box, rather than on any one of a number of other things. Now, I'll grant that some of the concerns are worth some serious thought, that incompatibilities should at the very least be documented (and avoided unless there are compelling benefits, and as much as possible only allowed within the established taxonomy, etc). And some of the things mentioned sounded to me like they offered alternatives worth at least thinking about (like adding decent command line editing to the old Bourne shell, which would keep maximum compatibility while improving basic ease-of-use). OTOH, i don't think that particular solution addresses the complaints by people who (misguidedly, given that POSIX only requires that: >Applications should note that the standard PATH to the shell cannot >be assumed to be either /bin/sh or /usr/bin/sh, and should be determined >by interrogation of the PATH returned by getconf PATH , ensuring that the >returned pathname is an absolute pathname and not a shell built-in. ) expect /bin/sh to be a POSIX shell. Whether those complaints, although not justifiable strictly on the basis of standards, nevertheless make it worthwhile to break compatibility for those scripts that work under the old /usr/bin/sh but not under ksh93, is another issue over and above the lack of ease of interactive use with Bourne shell (which IMO is dubious too, since accounts don't need to be created with /bin/sh as their interpreter). So, there are real issues, and there's value to constructive suggestions. But a lot of the conversation and emotion seems to be short on completeness or substance or both. I hope Indiana turns out to be useful, either for what's learned from it or as part of a future direction. I hope that whatever will eventually become Solaris 11 or 12 or whatever doesn't break the existing compatibility expectations. And I hope my hardware won't become a big bulky doorstop. Beyond that, I'd just as soon see less emotion and conflict, and more cooperative work towards common concerns. This message posted from opensolaris.org _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
