On 11/9/06, Don Cragun <don.cragun at sun.com> wrote: > >Date: Thu, 09 Nov 2006 12:38:52 -0700 > >From: Joel Buckley <Joel.Buckley at sun.com> > > > ... ... ... > > > >I believe precedent is already set by "/usr/xpg6/bin/stty". > > > >My suggestion is to obsolete & EOF the xpg6 directory entirely: > > > >1. merge the remaining "/usr/xpg6/bin/*" utilities into "/usr/bin/*" > equivalents > >and replace "/usr/xpg6/bin/*" with softlink, consistent with "stty" below. > > > > /usr/xpg6/bin/stty=../../../usr/bin/stty l none SUNWxcu6 > > > >2. After remaining "/usr/xpg6/..." entries are all softlinks to "/usr/..." > equivalents, > >the SUNWxcu6 packages could be simplified to the following and marked for > >End Of Feature (EOF) in the next appropriate Solaris release: > > > > /usr d none 0755 root sys SUNWxcu6 > > /usr/xpg6=../usr l none SUNWxcu6 > > Hi Joel, > To do what you suggest, we must first agree that Sun will stop > supporting multiple, conflicting revisions of various standards > (especially the System V ABIs, the POSIX standards, and the Single UNIX > Specifications). That clearly IS NOT this case. Until we agree that > Sun should stop supporting multiple standards (and I don't see me ever > agreeing to that), I don't believe we will ever be able to have only > /usr/bin as the only directory needed to contain conforming > utilities). Even if everything else could magically be aligned, we > will need more than one version of the getconf utility. (Try the > commands: > /usr/bin/getconf _XOPEN_VERSION > /usr/xpg4/bin/getconf _XOPEN_VERSION > /usr/xpg6/bin/getconf _XOPEN_VERSION > to see one trivial difference.)
Don, which standard defines the behaviour of the utilities in /bin? The sorry state of these tools, including ksh, is the reason why we're close to drop Solaris support from our products. Whatever standard forces Sun to ship a disaster like /usr/bin/tr which is not even capable of handling Asian characters or the EURO currency symbol should be dropped from the distribution. This is just one of the smaller examples which drives the porting, development and maintenance costs beyond an acceptable point. Maintaining a Solaris port is more resource intensive than ANY other operating system, even in comparison to MacOS 10. Sun now has to decide whether they are willing to support the development of new software on their operating system or maintain backwards compatibility to their obsolete tools at all costs, even at the expense of the software companies who want to port, develop or maintain their software products on Solaris. I think that Solaris needs a modernisation project to rework the base tooling and applications. Irek
