John Plocher wrote: > Simon Phipps wrote: > > On Nov 13, 2007, at 12:28, James Carlson wrote: [snip] > Joerg and Roland will team up to beat us all to the punch, coming out > with a Schillix distro that has an awesome POSIX compliant personality > and ksh93 for the default shell - for root and for users :-) [snip]
Umpf... this isn't a special Jörg&&Roland thing... ;-/ ... IMO the problem looks like this: If we don't stick to the standards such as POSIX/SUS/etc. then we're sooner or later in trouble. And the term "trouble" is a _huge_ understatement... For example: Just take a look how it current looks in GNU land: GNU[1] (coreutils) has more or less the following ordering of their priorities: 1. Features 2. UTF-8 encoding 3. Conform to standards IMO this is both _wrong_ and _dangerous_ (at least for the long-term goals of binary compatibiliy and stability) - the correct ordering for Solaris should be... 1. Conform to standards 2. Multibyte encodings (e.g. *.UTF-8, zh_CN.GB183030, ja_JP.PCK etc.) 3. Features ... which is more or less the reverse order of how the GNU people work. However with out conforming to standarts we're sooner or later in serious trouble - not now and not in a year - but in 10 or 15 years the GNU stuff has likely evolved (remeber the comment which came up earlier in the GNU discussion: The Linux shell scripts from ten years ago do not run anymore with today's GNU coreutils) and I don't see how it's possible to maintain binary compatibilty if we don't make "standard conformance" our highest priority (we already have that problem with some tools in /usr/bin/ because the standards were ignored (which how causes _serious_ pain for customers)). The second item is related to "multibyte encodings" vs. "UTF-8" - I agree that Unicode is a good idea... but looking at the history I would be _very_ carefull about the usual "The ultimate character encoding"-talk. Remeber when ISO-2022 was "cool" and called "... the ultimate solution for character encoding problems..." ? IMO it is a better idea to stay completely neutral and continue the path of "CSI" (="Code Set Independence"), e.g. support any codeset and not only UTF-8 (erm... many GNU utilities&&tools still support multibyte encodings but the support for them is more and more going down and often hand-crafted optimisations for UTF-8 appear in the code (for testers this means you have to test three codepaths: single-byte locales, UTF-8 and "normal" multibyte locales)). The multibyte API (which allows an application to be code set independet) surived ISO-2022, supports more or less all national character encoding systems and was able to handle even new stuff like UTF-8... and IMO it is important to continue this path. Otherwise we _may_ be in trouble when (maybe in 20 years) the next "utilmate encoding" comes out (see "TRON vs. UTF-8"-wars). Another issue are "national requirements", e.g. zh_CN.GB183030 support is AFAIK mandatory for getting contracts in China and the more convernative japanese folks prefer ja_JP.PCK over ja_JP.UTF-8 (and I doubt it will change in the next ten years) wich already causes problems for Indina _now_. Third items is "features" - which is IMO OK as long as they do not violate [1] or [2]. [1]=Disclaimer: This is not an attempt to join the "/usr/gnn/bin in PATH"-wailing - I am just using this as an example to explain how IMO our priorities should be done... ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) [EMAIL PROTECTED] \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) _______________________________________________ indiana-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
