Bart Smaalders wrote:
> Garrett D'Amore wrote:
> > Hang on a sec. I think what I'm hearing is that it is now OK to accept
> > architecturally inferior software into Solaris if it already exists on
> > Linux.
> > ...
> > Are we just abdicating all engineering responsibility here, so that
> > Solaris will ultimately become a mishmash of various bits of FOSS of
> > differing quality? I really hope not!
>
> You mean like an editor that won't work on terminals wider than
> 160 characters? (that was Sun's vi until S10)... you mean like a version
> of awk that breaks if the lines are longer than (gasp) 255 characters?
Or many system utilities which do not support multibyte characters,
which codebase (mainly OS/Net) is not 64bit-clean (which means: Cannot
be compiled as 64bit code - which makes it currently impossible to port
OpenSolaris to platforms which are 64bit-only) and so on...
... maybe it would be usefull to have some kind of "standard form" for
ARC cases which asks the following things (examples... AFAIK there are
more things which should be asked):
---- cut ---- cut ---- cut ---- cut ---- cut ----
1. Does the code have any input/output/processing limits of any kind
(e.g. "awk" not being able to work beyond 255 characters or
/usr/xpg4/bin/sed unable to handle more than 100 commands (this kind of
problem makes it impossible to compile OS/Net using the XPG4/XPG6
tools)) ? If there are such limits please write a justification (min.
200 words) why this limit is needed.
2. Is the application a) CSI-enabled, supports b) only UTF-8 locales
(many GNU tools fall into this category) or c) is it completely unable
to handle multibyte characters ?
If there the application is not fully CSI-enabled please write a
justification (min. 200 words) why this limitation is needed.
3. Is the codebase 64bit clean [yes]/[no] (not technically an ARC
question but it is imortant since the non-64bit cleanness of the OS/Net
codebase _killed_ one OpenSolaris port and other port had to add
artificial 32bit support just to get the gate tools running) ?
If the codebase is not 64bit clean write a justification (min. 600
words) why the code cannot be made 64bit clean.
4. Do the utilities described in the ARC case intersect with any
POSIX/SUS standards (e.g. GNU grep vs. POSIX "grep" spec etc.) ? If
"yes" do they conform to the standard ? If they do not conform to the
standard please file a justification why this is neccesary (min. 200
words).
5. Is the proposed (library) API completely threadsafe, without using
(hidden) global or thread-local variables (for example the FUSE API
relies on thread-local variables which makes it nearly impossible to
implement FUSE bindings for languages which do not support the concept
of thread-local storage) ?
6. Is the proposed (library) API async-signal safe ?
7. Is the application largefile aware ?
---- cut ---- cut ---- cut ---- cut ---- cut ----
(the idea to write "justifications" with <n> words is more or less
thought as way to nudge the engineers to check whether it's easy/easier
to fix the code and than do it if possible - noone likes to write
pointless "justifications" with a few hundred words... =:-) )
----
Bye,
Roland
P.S.: Setting Reply-To: to { opensolaris-arc at opensolaris.org,
arc-discuss at opensolaris.org } to get the followup discussion off the
Unison ARC case...
--
__ . . __
(o.\ \/ /.o) roland.mainz at nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
