Prev: sending/handling INT signal in child processes in bash
Next: Convert UTC seconds to actual time.
From: Geoff Clare on 7 Jul 2010 08:49
Nicolas George wrote:

> "Ersek, Laszlo" wrote in message
> <Pine.LNX.4.64.1007062249410.13491(a)login03.caesar.elte.hu>:
>> Why the hostility towards The Open Group?
>
> It was not hostility towards The Open Group, nor towards you. If it was
> hostility, it was towards setting importance to the "certification" in a
> technical discussion.
>
> I do not begrudge The Open Group for offering that certification, they have
> to earn a living after all, and if they do that by taking money to apple and
> oracle and turning it into open standards, that is in fact quite good.
>
> But contributors of a technical programming newsgroup should know better
> than to trust that certification: it has no more than a minimal technical
> meaning.

The UNIX certification has much more than a "minimal" technical meaning.
In order to achieve certification, systems have to pass many thousands
of tests.

If you search the Solaris bug database you will see many changes that
have been made over the years as a result of Solaris failing Open
Group tests in "VSX", "VSU, "VSTH", "VSC", etc.

Also, regarding your "big bucks" comment earlier, it is true that
the UNIX certification has a significant cost associated with it.
However, a POSIX certification is also available which has a much
lower price tag.

There is no commercial/legal reason why someone like Red Hat or Novell
couldn't get a POSIX certification for their Linux system. However,
there is a technical reason why they couldn't: there are some Linux
behaviours that are intentionally different from POSIX (as documented
in the LSB).

--
Geoff Clare <netnews(a)gclare.org.uk>


From: Ersek, Laszlo on 7 Jul 2010 10:23
On Wed, 7 Jul 2010, Geoff Clare wrote:

> [...] it is true that the UNIX certification has a significant cost
> associated with it. However, a POSIX certification is also available
> which has a much lower price tag.

But then the implementation is not required to support the XSI option,
right?

http://www.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap02.html#tag_02_01_04


> There is no commercial/legal reason why someone like Red Hat or Novell
> couldn't get a POSIX certification for their Linux system. However,
> there is a technical reason why they couldn't: there are some Linux
> behaviours that are intentionally different from POSIX (as documented in
> the LSB).

Are you thinking of these?

http://refspecs.linux-foundation.org/LSB_4.0.0/LSB-Core-generic/LSB-Core-generic/posixconflicts.html
http://www.opengroup.org/personal/ajosey/tr11-11-2005.txt
http://refspecs.linux-foundation.org/LSB_4.0.0/LSB-Core-generic/LSB-Core-generic/app-a.html

I picked strerror_r() as an example (it defaults to LSB, not SUSv3).
However its manual page documents the SUSv3 declaration and behavior as
well, and alos how one can select one over the other (eg. with
_XOPEN_SOURCE, which conforms to the SUS).

I probably chose a wrong example, but it seems to me that Red Hat or
Novell or whoever else could both support the LSB and obtain UNIX
certification, by introducing a "big switch". Solaris' standards(5) lists
a bunch of environment variables.

Would you care to name an example where the SUS behavior is not available
at all, and deliberately so?

Thank you very much,
lacos
From: Nicolas George on 7 Jul 2010 10:32
Geoff Clare wrote in message
<ln9eg7-lo7.ln1(a)leafnode-msgid.gclare.org.uk>:
> there is a technical reason why they couldn't: there are some Linux
> behaviours that are intentionally different from POSIX (as documented
> in the LSB).

I sometimes came across similar discrepancies between (documented) behaviour
and standard for certified systems. I do not remember the details though.
From: Geoff Clare on 8 Jul 2010 08:35
Ersek, Laszlo wrote:

> On Wed, 7 Jul 2010, Geoff Clare wrote:
>
>> [...] it is true that the UNIX certification has a significant cost
>> associated with it. However, a POSIX certification is also available
>> which has a much lower price tag.
>
> But then the implementation is not required to support the XSI option,
> right?

Correct. And some other options that are mandated for UNIX conformance.

>> There is no commercial/legal reason why someone like Red Hat or Novell
>> couldn't get a POSIX certification for their Linux system. However,
>> there is a technical reason why they couldn't: there are some Linux
>> behaviours that are intentionally different from POSIX (as documented in
>> the LSB).
>
> Are you thinking of these?
>
> http://refspecs.linux-foundation.org/LSB_4.0.0/LSB-Core-generic/LSB-Core-generic/posixconflicts.html
> http://www.opengroup.org/personal/ajosey/tr11-11-2005.txt
> http://refspecs.linux-foundation.org/LSB_4.0.0/LSB-Core-generic/LSB-Core-generic/app-a.html
>
> I picked strerror_r() as an example (it defaults to LSB, not SUSv3).
> However its manual page documents the SUSv3 declaration and behavior as
> well, and alos how one can select one over the other (eg. with
> _XOPEN_SOURCE, which conforms to the SUS).

It was the second of those links that I had in mind. Some of those
differences between SUSv3 and LSB have gone away due to relaxations
made in SUSv4, but some remain.

> I probably chose a wrong example, but it seems to me that Red Hat or
> Novell or whoever else could both support the LSB and obtain UNIX
> certification, by introducing a "big switch". Solaris' standards(5) lists
> a bunch of environment variables.

Yes, they could make changes to get certified. I meant that they
couldn't certify their current systems.

> Would you care to name an example where the SUS behavior is not available
> at all, and deliberately so?

http://refspecs.linux-foundation.org/LSB_4.0.0/LSB-Core-generic/LSB-Core-generic/baselib-kill-3.html

which says:

If pid is specified as -1, sig shall not be sent to the calling
process. Other than this, the rules in the ISO POSIX (2003) apply.

Rationale: This was a deliberate Linus decision after an unpopular
experiment in including the calling process in the 2.5.1 kernel.
See "What does it mean to signal everybody?", Linux Weekly News,
20 December 2001, http://lwn.net/2001/1220/kernel.php3

--
Geoff Clare <netnews(a)gclare.org.uk>



From: Ersek, Laszlo on 8 Jul 2010 12:01
On Thu, 8 Jul 2010, Geoff Clare wrote:

> Ersek, Laszlo wrote:
>
>> Would you care to name an example where the SUS behavior is not
>> available at all, and deliberately so?
>
> http://refspecs.linux-foundation.org/LSB_4.0.0/LSB-Core-generic/LSB-Core-generic/baselib-kill-3.html
>
> which says:
>
> If pid is specified as -1, sig shall not be sent to the calling
> process. Other than this, the rules in the ISO POSIX (2003) apply.
>
> Rationale: This was a deliberate Linus decision after an unpopular
> experiment in including the calling process in the 2.5.1 kernel.
> See "What does it mean to signal everybody?", Linux Weekly News,
> 20 December 2001, http://lwn.net/2001/1220/kernel.php3

Very interesting.

Except for SIGSTOP & SIGKILL, the sending process could ignore or block
the signal. OTOH, stopping or killing all (non-system) processes at one
fell swoop while staying up and running is probably a useful operation.

Thank you very much.
lacos
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: sending/handling INT signal in child processes in bash
Next: Convert UTC seconds to actual time.