Roland Mainz wrote:
> Garrett D'Amore wrote:
> > Alan Coopersmith wrote:
[snip]
> Yes, at least we cover the following goals:
> - Familarity: GNU+BSD command line options (which increases
> interoperabilty, not only across GNU but BSD and MacOSX, too)
> - Performance:
> 1. The AST implementions are usually a lot faster than the current
> commands (we seen with the replacements for /usr/bin/cut, /usr/bin/paste
> etc. which are sometimes eight, ten or twelve times faster (partially
> because the |libc::stdio| implementation is _extremely_ slow))
> 2. Performance boost for OpenSolaris/Indiana since the tool is a
> builtin shell command for /usr/bin/sh, /sbin/sh, /usr/bin/ksh and
> /usr/bin/ksh93
> - 64bit clean codebase: Right now OS/Net is _not_ being 64bit clean (the
> tools we are touching in ksh93-integration update2 and this case are in
> particular the worst offenders, followed by the CTF tools and some minor
> other areas). This situation causes serious problems (e.g. accounting
> for 1/5 of the engineering time required to port Solaris) for ports to
> other hardware - for example the Solaris/SyetemZ port was forced to
> implement a 32bit emulation layer (!!) on pure 64bit hardware because
> there was no other easy way to get Solaris ported (and IMO this
> situation _sucks_ (<-- sorry... but I really don't like it that the code
> was never cleaned-up)).
[snip]
I forgot two items:
- Make all tools 100% largefile-aware. Right now some tools are still
not largefile-aware, related bugs include:
1. CR #4808051 ("pathchk of file larger than 2GB will fail") [1]
2. CR #5082249 ('*fold* is not large file aware "value too large for
defined data type"')
- Implement IEEE Std 1003.1-2008 features (e.g. pathchk's "-P" option)
[1]=<comment mode="sarcastic">I'm wondering how Solaris 10 passed the
Unix&co. certifications with this bug... grrr...</comment>
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.mainz at nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 3992797
(;O/ \/ \O;)
