I fail to see how any of this is relevant to this case.
The stability level of nproc is "unstable" and interfaces work on
Solaris, which is the only platform we're concerned with.
If an end user is comfortable using an interface which is disclosed as
unstable, and does the due diligence to see that the interface is
available on the platforms he or she wishes to use, then that is their
prerogative. Failing to deliver an interface because nobody else (or
nobody else but Linux) has would be deadlock.
Now, can we please take the GNU internal politics to GNU lists or some
other medium as they have absolutely no architectural relevance?
-JohnS
On 05/13/10 10:04 AM, Chris Pickett wrote:
2010/5/13 Darren J Moffat<[email protected]>:
On 13/05/2010 17:47, ольга крыжановская wrote:
No, it shouldn't impact the outcome of this case.
I explained where nproc came from. It also has an impact on script
portability because nproc is completely non standard (the lack of
getconf on old platforms and the buggies of getconf implementations
like Solaris getconf is the reason why ksh93 has a built in getconf).
A nit: Maybe the nproc(1) man page should contain the warning:
===== cut =====
nproc is not portable across platforms. Portable scripts shall use the
output of NPROCESSORS_ONLN to determinate the number of active
processing elements in a system.
===== cut =====
Please submit that upstream, this project team and case should not be adding
that to the upstream projects documentation in my opinion.
HA HA. Nice joke.
The last person who tried to suggest that parts of coreutils promote
unportable scripting was kicked off the coreutils list and got a few
interesting other lists subscriptions, such as the famous nazi.org
SIEG HEIL list. The coreutils team and McGrath/Drepper are mortal
enemies; neither team will add a comment in their own documentation
that the other team is right. Forget that quickly.
Chris
_______________________________________________
opensolaris-arc mailing list
[email protected]
