Email List: Xaustin-group-lX
[All Lists]

Re: POSIX vs. LSB

Subject: Re: POSIX vs. LSB
From: Jim Zepeda <yyyyyyyyyy@xxxxxxxxxxxxxxxxx>
Date: Tue, 02 Dec 2003 10:42:15 -0800
Cc: "Austin-Group-L (E-mail)" <yyyyyyyyyyyyyy@xxxxxxxxxxxxx>
References: <FB15E670DA55D51185350008C786514A0F90E0CA@sottexch1.cognos.com> <200312021758.33377.lois@loisgoldthwaite.com>
Good point. Unix and Posix also has similar "gods" of code. I have been fortunate enough to have met many of them. This phenomenon is good as software/operatings systems grow and mature.

The difference right now in this area between Posix and Linux is that the Posix community has learned to disregard arbitrary decisions and try for the "greater good" and to listen to defensible justifications, possibly changing the standard.

In some cases this attitude was actually driven by many of these programming "gods" who wanted to hear ideas from other people and had also come to understand that people stopped using their APIs if they changed them too often in an incompatible way.

Jim

Lois Goldthwaite wrote:

It is one thing to say, "There are good reasons why Linux differs from Posix in such-and-such an area," but it's something else again to say, "Compliance with Posix is irrelevant and undesirable, merely a historical coincidence when it occurs."

The UK position is that compliance between the two standards is highly desirable, where it can be achieved without causing major breakage of programs on either side. Nowhere have we suggested that Linux must always change to accommodate Posix; we expect the harmonisation effort to work both ways. (But nor do we expect that Posix must do all of the changing because of sheer intransigence from the Linux community.)

Hundreds of millions of dollars worth of software have been based on the Posix standard; for Linux to pooh-pooh compatibility, as Glen points out, makes it harder for users to migrate to Linux if they wish to. Or for Linux users to migrate to mature high-end platforms providing capabilities not yet available in the Linux environment.

At the Linux Study Group meeting last May, the comment was repeatedly offered that some inconsistency or another was "because XXX is the designated maintainer of YYY and he thinks it makes more sense to return the ZZZ error code here, even if it's not Posix-compliant." I would hope the Linux world can find mechanisms of reaching consensus other than delegating every tiny decision to a named individual.

There are justified criticisms of the ISO process in general and the recent operations of WG15 in particular, but that does not invalidate the widespread perception that ISO confers the "gold standard" of standardization. We need to find ways to improve ISO's procedures without losing those aspects of its process which are valuable.

Lois
(convenor of UK Posix panel)




On Tuesday 02 December 2003 14:22, Seeds, Glen wrote:

I'm attaching an interesting statement from an LSB adherent, along with my
response. Are we aware of these issues? What are our plans?
/gen
-----Original Message-----
From: yyyyyyyyyyyyyyyyyyy@xxxxxxxxxxxxx
[mailto:yyyyyyyyyyyyyyyyyyy@xxxxxxxxxxxxx]On Behalf Of Seeds, Glen
Sent: December 2, 2003 9:12 AM
To: 'Evan Leibovitch'; ...
I find this point of view hard to understand. The attitude that "we don't
need to worry about any standards but our own, because we're better" is one
of the main things that give Microsoft such a bad name with users. The
Linux folks should know better.
The principal value of POSIX is that it allows applications to be written
in a way that can be assured to work correctly on all compliant
implementations. Where "obsolete" features have been retained in POSIX,
this was done to ensure that old applications (or which there are MANY)
will continue to run. If Linux decides not to support this level of
compliance, that will be a significant factor in any company's decision to
migrate to Linux as its primary platform.
Having said that, it is also true that the LSB is a binary standard. POSIX
is a source standard, and has nothing to say about binary compatibility.
While there are many areas where there is significant functional overlap,
in other areas POSIX compatibility does not constrain the LSB.
Where there is overlap, from the point of view of consumers of these
systems, alignment between POSIX and LSB is HIGHLY desirable, if not
mandatory. If there are areas where the LSB folks believe a difference is
necessary for the good of all, it behooves them to raise this for public
discussion with the folks that depend on POSIX for portability.
I will raise this issue with the Open Group.
/glen
-----Original Message-----
From: yyyyyyyyyyyyyyyyyyy@xxxxxxxxxxxxx
[mailto:yyyyyyyyyyyyyyyyyyy@xxxxxxxxxxxxx]On Behalf Of Evan Leibovitch
...
The Linux community has generally agreed upon a set of standards, which at
a binary and basic interface level have been defined through the LSB.
Significant POSIX compliance is NOT (and I cannot stress this enough) a
mandatory, inevitable or even universally-considered-desirable goal of
Linux standards efforts. In areas where the Linux community (as expressed
through LSB) considers POSIX standards obsolete or irrelevant, it will
happily circumvent or ignore them. It is the POSIX people who are
talking-up Linux being more POSIX compatible; you will not hear that level
of enthusiasm from within the Linux camp.
The LSB has widespread support of the Linux community (developers, vendors
and end-users). Attempts to shoehorn Linux into an undesired level of POSIX
compliance will simply diminish the relevance of and respect for SC22
activity in this field.
So your premise is incorrect. We do not have two POSIX-compliant systems.
We have one POSIX compliant system and one that is, deliberately, never
likely (and uninterested) to become POSIX-compliant unless POSIX changes
radically. There is some significant intersection between the two, but also
significant divergence that is unlikely to be bridged in the foreseeable
future if ever.
IMO SC22 has a role to play in facilitating communications between two
superficially-similar but different standards, in an effort to find common
ground as well as identify and document the differences. Any attempt to
merge the two under one committee will be a disaster and simply erode SC22
authority in the field.
The best that can/should be expected right now is to have two WGs,
encourage joint sessions, and create a NP (which I believe is already done)
to document the differences. If WG15 runs out of steam/interest, that's not
the fault of the Linux folk; using Linux to revive WG15 is a mistake.
- Evan

This message may contain privileged and/or confidential information. If
you have received this e-mail in error or are not the intended recipient,
you may not use, copy, disseminate or distribute it; do not open any
attachments, delete it immediately from your system and notify the sender
promptly by e-mail that you have done so. Thank you.



<Prev in Thread] Current Thread [Next in Thread>