On Wed, Apr 11, 2007 at 07:37:11PM +0200, Bart Blanquart wrote: > Claiming that incompatibly changing /usr/bin is customer-friendly seems a bit > odd, considering that > it'd break things for a fair number of Solaris users: it'd be > customer-hostile to them... >
This needs to be quantified at some point. In over a decade of working with Solaris, I can't poinpoint anything that anyone I know has written to rely on the limitations of, eg. /usr/bin/id. What breaks, for who, and what would it take to help them fix it? Why not shove the cruft into /usr/depricated and let it slowly rot there, as it's doing now in /usr/bin? I'm sure this conversation's been had within sun but now that this is the *open*solaris community, one which I understand is trying to *expand* the userbase for solaris, why not entertain that this is an extremely frustrating and seemingly arbitrary position to most users (users - not religious zealots and systems programmers, though they are often the same things) and quantify how many people and processes would be impacted. Or, why not offer a package with an alternative userland with things like an un-f*cked awk, a good sed, multi-byte support, an id that can tell you numeric ids, etc. by default, instead of subjecting new users to ridicule for not understanding via some un-specified mechanism why there's /bin/sh, /sbin/sh and /usr/xpg4/bin/sh and why you get the least compatible (or useful) ones by default, offering the impression that the platform is broken? Mind you, that impression is gotten because that's what the platform is telling you to use! Sure, solaris folks earn the big $$$ by editing such arcane things as /.profile to make a system useful, but this kind of chicanery is no way for a decent man to earn a living, now is it? -Peter -- The 5 year plan: In five years we'll make up another plan. Or just re-use this one. _______________________________________________ opensolaris-discuss mailing list [email protected]
