I know that the system call codes used by Linux are not 100% UNIX
compatible. Is there anything else in the kernel that is not UNIX
compatible? Would modifying these things for UNIX compatibility break
anything in userland provided that it is recompiled against the
modified sources?
By the way, I subscribed to the mailing because I heard that Linus
Torvalds is considering changing Linux's version scheme from 2.6.x to
3.x. Is there any possibility of putting better UNIX compatibility on
the list of features planned for 3.x?
Yours truly,
Richard Yao
On May 24, 2011, at 7:49 AM, Richard Yao wrote:
> I know that the system call codes used by Linux are not 100% UNIX
> compatible. Is there anything else in the kernel that is not UNIX
> compatible? Would modifying these things for UNIX compatibility break
> anything in userland provided that it is recompiled against the
> modified sources?
What do you mean by "UNIX compatible?" API compatibility?
ABI compatibility? Which Unix? Solaris and HPUX and AIX
are systems which are allowed to use the Unix(tm) trademark,
but them are not compatible with each other.
So the question you are asking is not well defined.
Also, why are you asking it? What problem are you trying to solve?
At this point, Linux is running on far more servers than any of the
Legacy Unix systems out there, and the ones which are still in
development (i.e., Solaris and AIX) are have recently been worrying
about adding Linux compatibility layers (usually at the API level).
-- Ted
On Tue, May 24, 2011 at 13:06, Theodore Tso <[email protected]> wrote:
>
> On May 24, 2011, at 7:49 AM, Richard Yao wrote:
>
>> I know that the system call codes used by Linux are not 100% UNIX
>> compatible. Is there anything else in the kernel that is not UNIX
>> compatible? Would modifying these things for UNIX compatibility break
>> anything in userland provided that it is recompiled against the
>> modified sources?
>
> What do you mean by "UNIX compatible?" API compatibility?
> ABI compatibility? Which Unix? Solaris and HPUX and AIX
> are systems which are allowed to use the Unix(tm) trademark,
> but them are not compatible with each other.
>
> So the question you are asking is not well defined.
>
> Also, why are you asking it? What problem are you trying to solve?
> At this point, Linux is running on far more servers than any of the
> Legacy Unix systems out there, and the ones which are still in
> development (i.e., Solaris and AIX) are have recently been worrying
> about adding Linux compatibility layers (usually at the API level).
Surely something as precarious as hegemony is nothing to boast about.
Dear Ted,
First off, I was wrong about the system call codes. I just checked my
reference and the difference between Linux and UNIX System V that I
meant to cite involved the system error codes. At the moment, I do not
know anything about the compatibility of the system call codes.
With that out of the way, I am under the impression that the Linux
kernel code is in some way incompatible with the Single Unix
Specification (i.e. the thing required for an OS to be certified as
being UNIX). So far, the only kernel code of which I am aware that
could possibly be incompatible is code involving error codes, but
after reading your email, I realize that I am not sure if having those
match the UNIX System V error is a requirement for the specification.
I have always heard that Linux was almost compatible with UNIX, but
not quite compatible; yet no one ever seems to enumerate the reasons
for that. I know that the GNU userland that typically accompanies the
Linux kernel in Linux distributions is not UNIX compatible (e.g.
blocks are not 512 bytes).
I would like to know if there is anything in the kernel code itself
that would need to change for people to say that Linux is a UNIX
kernel minus the external factors (i.e. a UNIX userland and
certification) needed to be an official UNIX kernel. If there are any
long standing differences, now would be a good time to discuss
resolving them considering the proposed Linux 3.0 change.
By the way, with regard to the error codes, Groklaw has an article
enumerating the differences from UNIX System V:
http://www.groklaw.net/articlebasic.php?story=20040221192536920
It seems Linus Torvalds wanted to use the UNIX System V call codes
when he was working on Linux 0.0.1, but he lacked a reference at the
time, so he only got them partially right. Considering that the error
codes were originally intended to be compatible with UNIX System V, it
might be worth changing them to match. The Linux 3.0 change would
probably be a good time for this.
Yours truly,
Richard Yao
On Tue, May 24, 2011 at 9:06 AM, Theodore Tso <[email protected]> wrote:
>
> On May 24, 2011, at 7:49 AM, Richard Yao wrote:
>
>> I know that the system call codes used by Linux are not 100% UNIX
>> compatible. Is there anything else in the kernel that is not UNIX
>> compatible? Would modifying these things for UNIX compatibility break
>> anything in userland provided that it is recompiled against the
>> modified sources?
>
> What do you mean by "UNIX compatible?" ?API compatibility?
> ABI compatibility? ? Which Unix? ?Solaris and HPUX and AIX
> are systems which are allowed to use the Unix(tm) trademark,
> but them are not compatible with each other.
>
> So the question you are asking is not well defined.
>
> Also, why are you asking it? ? What problem are you trying to solve?
> At this point, Linux is running on far more servers than any of the
> Legacy Unix systems out there, and the ones which are still in
> development (i.e., Solaris and AIX) are have recently been worrying
> about adding Linux compatibility layers (usually at the API level).
>
> -- Ted
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at ?http://www.tux.org/lkml/
>
On Tue, May 24, 2011 at 10:49:26AM -0400, Richard Yao wrote:
>
> With that out of the way, I am under the impression that the Linux
> kernel code is in some way incompatible with the Single Unix
> Specification (i.e. the thing required for an OS to be certified as
> being UNIX). So far, the only kernel code of which I am aware that
> could possibly be incompatible is code involving error codes, but
> after reading your email, I realize that I am not sure if having those
> match the UNIX System V error is a requirement for the specification.
The Single Unix Specification is a API specification, not an ABI
specification. So no, it doesn't specify the precise numeric
assignments of EINVAL, ENOSPC, etc.
> I have always heard that Linux was almost compatible with UNIX, but
> not quite compatible; yet no one ever seems to enumerate the reasons
> for that. I know that the GNU userland that typically accompanies the
> Linux kernel in Linux distributions is not UNIX compatible (e.g.
> blocks are not 512 bytes).
No one ever bothers to deal with issues because they are tiny,
nit-pitcky things that no one other than standards mavens would care
about. You have to be someone who is extremely anal to really care
about this kind of stuff. It's really stupid stuff --- for example,
if you call unlink() on a directory, POSIX and the Single Unix
Specification requires that a conforming operating system return
EPERM. Linux returns the error code EISDIR instead, and Al Viro has
explicitly stated that we're not going to change this just to keep
some paper pushers happy.
If you want to waste time out of your life that you'll never get back,
you can see more details of this kind of stuff here:
http://www.opengroup.org/personal/ajosey/tr11-11-2005.txt
There has been some talk that the standards committee would make
changes to the standard to recognize what the dominant implementation
(i.e,. Linux) actually does (because standards committee, as full of
ivory-tower eggheads as it is, does have some folks who recognize that
there is such a thing as the Real World). However, at this point, it
seems very unlikely this will happen, because (a) one really cares
about POSIX/SUS compatibility since no one, including governments, are
requiring POSIX compatibility in their purchasing decisions these days
--- Linux has had no problems getting acquired and used in governments
all over the world, and (b) the companies who used pay $$$$ to fund
standards folks to fly all over the world to have standards meetings,
aren't funding this sort of thing any more, because of (a).
> I would like to know if there is anything in the kernel code itself
> that would need to change for people to say that Linux is a UNIX
> kernel minus the external factors (i.e. a UNIX userland and
> certification) needed to be an official UNIX kernel. If there are any
> long standing differences, now would be a good time to discuss
> resolving them considering the proposed Linux 3.0 change.
Not going to happen. Some of these changes are things where we
fundamentally believe that the Linux behaviour is more technically
correct.
And there's no point in trying for what you are calling "Unix
compatibility"; the Single Unix Specification leaves a lot of things
undefined, so multiple Legacy Unix systems (i.e, Solaris, AIX, HPUX)
can all be conformant to the POSIX/SUS standards, but applications
will still need to do significant porting between two UNIX systems.
So why do it?
> By the way, with regard to the error codes, Groklaw has an article
> enumerating the differences from UNIX System V:
>
> http://www.groklaw.net/articlebasic.php?story=20040221192536920
>
> It seems Linus Torvalds wanted to use the UNIX System V call codes
> when he was working on Linux 0.0.1, but he lacked a reference at the
> time, so he only got them partially right.
No, Linus originally wanted to be binary compatible with MINIX. What
makes you think there was any intention to be Unix System V
compatible? It's simply not true. Just to give one example, Unix
System V used AT&T Streams for its networking interface, which was a
disaster, and Linux doesn't even bother to try to support Streams; we
use the BSD socket interface instead.
- Ted
On Tue, 24 May 2011, Richard Yao wrote:
> With that out of the way, I am under the impression that the Linux
> kernel code is in some way incompatible with the Single Unix
> Specification (i.e. the thing required for an OS to be certified as
> being UNIX).
I beleive it's less a matter of being incompatible and more a matter of
not having been certified as being compatible.
a historic note: at the time that Linux was getting started, getting
certified as Unix was a very expensive undertaking (and Linux definantly
did not comply in the early days anyway). Even getting the full specs was
an expensive thing (at least for an individual)
as such, there are probably some differences that crept in (like the error
codes you refer to below), but the biggest difference is that there are
additional system calls available on Linux compared to Unix
That being said, the differences are minor enough that many flavors of
Unix have implemented Linxu compatibility layers to support unmodified
linux binarires, and recompiling code written for Unix almost always 'just
works' on Linux (the biggest issue is usually libraries)
> It seems Linus Torvalds wanted to use the UNIX System V call codes
> when he was working on Linux 0.0.1, but he lacked a reference at the
> time, so he only got them partially right. Considering that the error
> codes were originally intended to be compatible with UNIX System V, it
> might be worth changing them to match. The Linux 3.0 change would
> probably be a good time for this.
and what exactly would the advantage be of breaking backwards
compatibility with all existing linux code?
I don't see any real advantage.
David Lang
On Tue, May 24, 2011 at 18:16, Ted Ts'o <[email protected]> wrote:
> No one ever bothers to deal with issues because they are tiny,
> nit-pitcky things that no one other than standards mavens would care
> about. You have to be someone who is extremely anal to really care
> about this kind of stuff. It's really stupid stuff... paper pushers...
>
> If you want to waste time out of your life that you'll never get back...
> ...
> ... standards committee, as full of ivory-tower eggheads as it is,
> does have some folks who recognize that there is such a thing as
> the Real World)...
The world would be a better place if you weren't so needlessly
confrontational when sharing your knoweldge, Ted.
On Tue, 2011-05-24 at 18:31 +0000, Michael Witten wrote:
> On Tue, May 24, 2011 at 18:16, Ted Ts'o <[email protected]> wrote:
>
> > No one ever bothers to deal with issues because they are tiny,
> > nit-pitcky things that no one other than standards mavens would care
> > about. You have to be someone who is extremely anal to really care
> > about this kind of stuff. It's really stupid stuff... paper pushers...
> >
> > If you want to waste time out of your life that you'll never get back...
> > ...
> > ... standards committee, as full of ivory-tower eggheads as it is,
> > does have some folks who recognize that there is such a thing as
> > the Real World)...
>
> The world would be a better place if you weren't so needlessly
> confrontational when sharing your knoweldge, Ted.
Ivory-tower eggheads is common vernacular, a colorful and communicative
description of a mindset. Ted's usage added useful information to the
conversation, unlike the pompous interjection above.
-Mike
On Wed, 25 May 2011 06:18:28 +0200, Michael Galbraith wrote:
> On Tue, 2011-05-24 at 18:31 +0000, Michael Witten wrote:
>> On Tue, May 24, 2011 at 18:16, Ted Ts'o <[email protected]> wrote:
>>
>> > No one ever bothers to deal with issues because they are tiny,
>> > nit-pitcky things that no one other than standards mavens would care
>> > about. You have to be someone who is extremely anal to really care
>> > about this kind of stuff. It's really stupid stuff... paper pushers...
>> >
>> > If you want to waste time out of your life that you'll never get back...
>> > ...
>> > ... standards committee, as full of ivory-tower eggheads as it is,
>> > does have some folks who recognize that there is such a thing as
>> > the Real World)...
>>
>> The world would be a better place if you weren't so needlessly
>> confrontational when sharing your knoweldge, Ted.
>
> Ivory-tower eggheads is common vernacular, a colorful and communicative
> description of a mindset. Ted's usage added useful information to the
> conversation, unlike the pompous interjection above.
At first I thought you were labeling as `pompous' my suggestion that the
world would be improved by the introduction of a little more civility in
our discourse, and so I was confused.
However, it ocurred to me that you were actually admonishing yourself
for your preceding sentence:
> Ivory-tower eggheads is common vernacular, a colorful and communicative
> description of a mindset.
Common vernacular among whom? Among the leathered-handed thick-necked
hacks bumping around mindlessly in the fog at the base of the ivory-tower?
Oh. Perhaps, though, you are unfamiliar with that particular
common vernacular for colorfully describing a mindset...
Everybody brings a different brain to the task at hand, and it is foolish
to dismiss an entire class of brain, especially by indirectly insulting
a particular person.
Ted just got finished telling Richard that Richard thinks about tiny,
nit-picky, really stupid stuff on which only egg-headed paper pushers
waste time that they'll never get back.
We don't need that kind of thing.
Sincerely,
Michael Witten
On Wed, May 25, 2011 at 02:20:09PM +0000, Michael Witten wrote:
>
> Ted just got finished telling Richard that Richard thinks about tiny,
> nit-picky, really stupid stuff on which only egg-headed paper pushers
> waste time that they'll never get back.
There are people who spend hours and hours worrying about the fact
that if you try to unlink a directory, Linux will return EISDIR
instead of EPERM. They will kill forests of trees, and cause tons and
tons of carbon dioxide to be released into the atmosphere travelling
to distant meetings in Singapore, Zurich, Japan, etc., to debate
standards that specify this kind of detail. How much value does this
really add to the Linux ecosystem? What would you call these people?
Now that the people who tried to lobby governments and academic
institutions (mostly in Europe) not to use Linux, all in the name of,
"because it's not Unix" are largely in full retreat, the answer is,
why, pretty much none. This kind of requirement is largely gone in
most procurement contracts.
And of course, the supreme irony is that if your OS is encumbered with
AT&T copyrighted code, you can use the Unix trademark even if you are
not conformant to the Single Unix Specification. (There's an escape
clause for AT&T derived-Unix systems, which are automatically "Unix"
even if they fail the SUS.)
Given all of that, what _use_ is the Single Unix Specification at this
point? What's the _point_?
And what name would you propose to call people who are worried about
whether or not Linux is "Unix compatible" (whatever the hell that
means)? Especially when the rest of the world is worried about being
"Linux compatible", and a huge amount of software is targetted first
for Linux.
This idea that Linux needs to care about being "Unix compatible" keeps
coming back from the grave, like some Buffy-the-vampire-slayer
monster. It's time to slay it.
- Ted
On Wed, May 25, 2011 at 02:20:09PM +0000, Michael Witten wrote:
>
> Ted just got finished telling Richard that Richard thinks about tiny,
> nit-picky, really stupid stuff on which only egg-headed paper pushers
> waste time that they'll never get back.
P.S. I never said that, and it's manifestly not true. Given that
Richard apparently doesn't know the first thing about whether the SUS
is an API or ABI specification (i.e., whether or not errno numeric
values matter), it's clear he's not an egg-headed paper pusher. :-)
I'm just trying to convince him not to get seduced into the dark side
of the standards world. :-)
- Ted
On Wed, 2011-05-25 at 14:20 +0000, Michael Witten wrote:
> On Wed, 25 May 2011 06:18:28 +0200, Michael Galbraith wrote:
> > On Tue, 2011-05-24 at 18:31 +0000, Michael Witten wrote:
> >> On Tue, May 24, 2011 at 18:16, Ted Ts'o <[email protected]> wrote:
> >>
> >> > No one ever bothers to deal with issues because they are tiny,
> >> > nit-pitcky things that no one other than standards mavens would care
> >> > about. You have to be someone who is extremely anal to really care
> >> > about this kind of stuff. It's really stupid stuff... paper pushers...
> >> >
> >> > If you want to waste time out of your life that you'll never get back...
> >> > ...
> >> > ... standards committee, as full of ivory-tower eggheads as it is,
> >> > does have some folks who recognize that there is such a thing as
> >> > the Real World)...
> >>
> >> The world would be a better place if you weren't so needlessly
> >> confrontational when sharing your knoweldge, Ted.
> >
> > Ivory-tower eggheads is common vernacular, a colorful and communicative
> > description of a mindset. Ted's usage added useful information to the
> > conversation, unlike the pompous interjection above.
>
> At first I thought you were labeling as `pompous' my suggestion that the
> world would be improved by the introduction of a little more civility in
> our discourse, and so I was confused.
No you weren't. I found your remark to be pompous sideline sniping.
The End.
-Mike
On Wed, 25 May 2011 10:36:02 -0400, Ted Ts'o wrote:
>On Wed, May 25, 2011 at 02:20:09PM +0000, Michael Witten wrote:
>>
>> Ted just got finished telling Richard that Richard thinks about tiny,
>> nit-picky, really stupid stuff on which only egg-headed paper pushers
>> waste time that they'll never get back.
>
> There are people who spend hours and hours worrying about the fact
> that if you try to unlink a directory, Linux will return EISDIR
> instead of EPERM. They will kill forests of trees, and cause tons and
> tons of carbon dioxide to be released into the atmosphere travelling
> to distant meetings in Singapore, Zurich, Japan, etc., to debate
> standards that specify this kind of detail. How much value does this
> really add to the Linux ecosystem? What would you call these people?
These are largely strawmen arguments.
> Now that the people who tried to lobby governments and academic
> institutions (mostly in Europe) not to use Linux, all in the name of,
> "because it's not Unix" are largely in full retreat, the answer is,
> why, pretty much none. This kind of requirement is largely gone in
> most procurement contracts.
While that's good for the Linux world, it's not necessarily good for the
software world; I guess you have to be in a tower to see further than than
the trees.
> And of course, the supreme irony is that if your OS is encumbered with
> AT&T copyrighted code, you can use the Unix trademark even if you are
> not conformant to the Single Unix Specification. (There's an escape
> clause for AT&T derived-Unix systems, which are automatically "Unix"
> even if they fail the SUS.)
That sounds like the work of the hacker class (or some subclass). After
all, you KNOW the eggheads wouldn't approve.
> Given all of that, what _use_ is the Single Unix Specification at this
> point? What's the _point_?
>
> And what name would you propose to call people who are worried about
> whether or not Linux is "Unix compatible" (whatever the hell that
> means)? Especially when the rest of the world is worried about being
> "Linux compatible", and a huge amount of software is targetted first
> for Linux.
You've got the game of modern society wrong.
The winner is not the one who smashes the competition; the winner is the
one who best eases the lives of as many people as possible.
The point of such a specification is to provide a single, relatively stable
source of documentation for how a complex system works. It sucks to have
to wade through the Linux codebase, out-dated and incomplete `Documentation/',
and haphazard asortments of blogs, webpages, and mailing list archives just
to figure out WTF Linux is doing TODAY (and then having to perform the same
research on other systems, which is even more difficult when they are
proprietary).
> This idea that Linux needs to care about being "Unix compatible" keeps
> coming back from the grave, like some Buffy-the-vampire-slayer
> monster. It's time to slay it.
What needs to die is the tyranny of the hackers.
Humans are capable of organizing themselves better than just acquiscing to
whomever is capable of imposing himself fastest.
Sincerely,
Michael Witten
On Wed, May 25, 2011 at 15:17, Mike Galbraith <[email protected]> wrote:
> On Wed, 2011-05-25 at 14:20 +0000, Michael Witten wrote:
>> On Wed, 25 May 2011 06:18:28 +0200, Michael Galbraith wrote:
>> > On Tue, 2011-05-24 at 18:31 +0000, Michael Witten wrote:
>> >> On Tue, May 24, 2011 at 18:16, Ted Ts'o <[email protected]> wrote:
>> >>
>> >> > No one ever bothers to deal with issues because they are tiny,
>> >> > nit-pitcky things that no one other than standards mavens would care
>> >> > about. You have to be someone who is extremely anal to really care
>> >> > about this kind of stuff. It's really stupid stuff... paper pushers...
>> >> >
>> >> > If you want to waste time out of your life that you'll never get back...
>> >> > ...
>> >> > ... standards committee, as full of ivory-tower eggheads as it is,
>> >> > does have some folks who recognize that there is such a thing as
>> >> > the Real World)...
>> >>
>> >> The world would be a better place if you weren't so needlessly
>> >> confrontational when sharing your knoweldge, Ted.
>> >
>> > Ivory-tower eggheads is common vernacular, a colorful and communicative
>> > description of a mindset. Ted's usage added useful information to the
>> > conversation, unlike the pompous interjection above.
>>
>> At first I thought you were labeling as `pompous' my suggestion that the
>> world would be improved by the introduction of a little more civility in
>> our discourse, and so I was confused.
>
> No you weren't. I found your remark to be pompous sideline sniping.
I like your ironical humor.
On Wed, May 25, 2011 at 03:17:35PM +0000, Michael Witten wrote:
>
> The winner is not the one who smashes the competition; the winner is the
> one who best eases the lives of as many people as possible.
>
> The point of such a specification is to provide a single, relatively stable
> source of documentation for how a complex system works.
I've been to ISO standards meetings, and it is filled with people who
use standards for the purposes of gaining a competitive advantage.
Most of them were paid to do standards work by companies who funded it
precisely because it would net them a competitive advantage.
I've represented the United States at official ISO meetings, and I saw
a lot more personality issues, corporate politics (i.e., a
representative from Sun who trying to torpedo ISO/IEC 23360-1:2006
because it would help Solaris and hurt Linux), than you would expect.
In fact, all of the technical work was done outside of the ISO
standards process; what we did inside ISO was all paper pushing,
because there were still so misguided government types in Europe who
cared about ISO at that time.
(As another example, I point you to the fireworks of OOXML and ISO/IEC
29500, and the blatent influcing of national standards bodies by
Microsoft.)
So if you want a specification of how **Linux** works, I don't think
going through ISO and national standards bodies is the most efficient
way to work.
>
> What needs to die is the tyranny of the hackers.
>
> Humans are capable of organizing themselves better than just acquiscing to
> whomever is capable of imposing himself fastest.
You know, biologists have a term for a static, stable system. It's
called "dead". If you want something that doesn't change, feel free
to use AT&T System V Release 4. It doesn't change. And it's well
documented.
Oh, you wanted the new features that's in Linux? The new hardware
support? That's all brought to you by the hackers that you seem to
hate so much.
- Ted
On 5/25/2011 11:51 AM, Michael Witten wrote:
> On Wed, 25 May 2011 13:38:46 -0400, Ted Ts'o wrote:
>
>> On Wed, May 25, 2011 at 03:17:35PM +0000, Michael Witten wrote:
>>
>>> The winner is not the one who smashes the competition; the winner is the
>>> one who best eases the lives of as many people as possible.
>>>
>>> The point of such a specification is to provide a single, relatively stable
>>> source of documentation for how a complex system works.
>> I've been to ISO standards meetings, and it is filled with people who
>> use standards for the purposes of gaining a competitive advantage.
>> Most of them were paid to do standards work by companies who funded it
>> precisely because it would net them a competitive advantage.
> That's great. Nobody is defending them; they certainly aren't the eggheads,
> and they clearly aren't inhabitants of any ivory tower.
>
> Essentially, your wrath is misdirected.
>
>>>> This idea that Linux needs to care about being "Unix compatible" keeps
>>>> coming back from the grave, like some Buffy-the-vampire-slayer
>>>> monster. It's time to slay it.
>>> What needs to die is the tyranny of the hackers.
>>>
>>> Humans are capable of organizing themselves better than just acquiscing to
>>> whomever is capable of imposing himself fastest.
>> Oh, you wanted the new features that's in Linux? The new hardware
>> support? That's all brought to you by the hackers that you seem to
>> hate so much.
> I don't hate the hack[er]s. I also don't hate the eggheads.
>
> A new feature is outside of the purview of an existing standard (and if it
> existed in the standard first, then it is simply newly implemented).
>
> Standards are only useless because non-eggheads make them so.
Alternatively, standards are only useful if they are useful to non-eggheads.
> A user should be able to request (possibly dynamically) as many
> standards-compliant interfaces as possible from Linux (even if that
> precludes new features or optimizations).
Err, no, and I'll tell you why.
Back in the old days of Unix (circa 1985) there were two "standards",
System V and BSD. Each had a well defined collection of interfaces for
dealing with signals. Both implementation were complete and functional,
but they were different. Unix system vendors, being highly responsive
to customer requirements to run programs written for either variant,
created Unix systems that provided both sets of interfaces at the same
time. Everyone should have been happy, but this was not the case. It
seems that many programmers found the signal processing set-up functions
from BSD preferable to those from System V but the signal handling
interfaces from System V more to their liking than those of BSD, so
they mixed the two and got non-deterministic results. The users got the
interfaces they demanded and a system that did not meet their needs as
a direct result. Eventually a deterministic behavior for mixed metaphor
programs was introduced, effectively creating a third "standard".
Users are a really terrible source of interface specifications. "Hackers"
are often not much better, but at least if the interface is lousy the
developer has the potential to be accountable for it and its improvement.
> Sincerely,
> Michael Witten
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>
On Wed, 25 May 2011 10:36:02 EDT, "Ted Ts'o" said:
> And of course, the supreme irony is that if your OS is encumbered with
> AT&T copyrighted code, you can use the Unix trademark even if you are
> not conformant to the Single Unix Specification. (There's an escape
> clause for AT&T derived-Unix systems, which are automatically "Unix"
> even if they fail the SUS.)
>
> Given all of that, what _use_ is the Single Unix Specification at this
> point? What's the _point_?
We're pretty shameless in mugging other operating systems for good new ideas
(witness the recent patches stealing SEEK_HOLE and SEEK_DATA from Solaris), but
most of the time, the neat stuff like that isn't part of SUS anyhow, because only
one or two Unix-derived systems implemented the function.
Single most useful thing left in SUS? The few places we're *really* divergent from SUS,
we can usually go back and read the SUS spec for the function in question and remind
ourself that yes, we diverged for a reason - the spec was on total crack. :)
On Mit, 2011-05-25 at 18:51 +0000, Michael Witten wrote:
[...]
> A user should be able to request (possibly dynamically) as many
> standards-compliant interfaces as possible from Linux (even if that
> precludes new features or optimizations).
A user can request anything anytime since ages. But if no one implements
and maintains it, s/he can't so anything anyways - except to implement
and maintain it on his/her own.
Bernd
--
Bernd Petrovitsch Email : [email protected]
LUGA : http://www.luga.at
On Mit, 2011-05-25 at 15:17 +0000, Michael Witten wrote:
[...]
> What needs to die is the tyranny of the hackers.
The problem with that is, that it is replaced with a tyranny of some
others like marketing folks, sales droids or paper pushers - which is
even worse, especially if the "decision" is a compromise.
Think about why there are so many "bad" standards. Mainly because most
of them (if not all) are a compromise to fit to already existing
implementations of competing vendors ....
Or take the "unlink a directory gives EPERM" example: why is it
specified with an errno that indicates that the user is not allowed to
remove it (and not that the sys-call is the wrong one).
> Humans are capable of organizing themselves better than just acquiscing to
> whomever is capable of imposing himself fastest.
If it's with (self written) good patches, it's a good thing. Imposing
with a (not necessarily self-written) presentation at a meeting is
something completely different ....
Bernd
--
Bernd Petrovitsch Email : [email protected]
LUGA : http://www.luga.at
On Thu, 26 May 2011 13:30:39 +0200, Bernd Petrovitsch said:
> Or take the "unlink a directory gives EPERM" example: why is it
> specified with an errno that indicates that the user is not allowed to
> remove it (and not that the sys-call is the wrong one).
Because on some old Unix's, it wasn't the wrong syscall...
RATIONALE
Unlinking a directory is restricted to the superuser in many historical
implementations for reasons given in link() (see also rename()).
http://pubs.opengroup.org/onlinepubs/009695399/functions/unlink.html
I've encountered at least one system (admittedly 20+ years ago), where
unlink("./") actually did work. Took me a while to correlate the weird fsck's
at reboots to the program that tried to remove './$A' when $A was unset...
On Don, 2011-05-26 at 08:07 -0400, [email protected] wrote:
> On Thu, 26 May 2011 13:30:39 +0200, Bernd Petrovitsch said:
>
> > Or take the "unlink a directory gives EPERM" example: why is it
> > specified with an errno that indicates that the user is not allowed to
> > remove it (and not that the sys-call is the wrong one).
>
> Because on some old Unix's, it wasn't the wrong syscall...
Oh well, I'm probably too young for that ....
> RATIONALE
>
> Unlinking a directory is restricted to the superuser in many historical
> implementations for reasons given in link() (see also rename()).
>
> http://pubs.opengroup.org/onlinepubs/009695399/functions/unlink.html
So someone changes the semantics of the unlink() sys-call (obviously in
some compatible, standards-compliant way) as it no longer unlinks
directories but it is not possible to define the returned errno for
the new error case to something sane?
What did I miss?
Bernd
--
Bernd Petrovitsch Email : [email protected]
LUGA : http://www.luga.at
On Thu, May 26, 2011 at 02:24:59PM +0200, Bernd Petrovitsch wrote:
> > RATIONALE
> >
> > Unlinking a directory is restricted to the superuser in many historical
> > implementations for reasons given in link() (see also rename()).
> >
> > http://pubs.opengroup.org/onlinepubs/009695399/functions/unlink.html
>
> So someone changes the semantics of the unlink() sys-call (obviously in
> some compatible, standards-compliant way) as it no longer unlinks
> directories but it is not possible to define the returned errno for
> the new error case to something sane?
Yes, it was those horrible hackers at BSD that implemented mkdir() and
rmdir() as atomic operations that could be executed by any process,
instead of only allowing root to create subdirectories.
It was the righteous AT&T marketing managers that created the first
standard, the AT&T SVID, which enshrined the Unix V7 error return, and
forbade it from ever being changed lest you "not be compatible with
Unix". And thus was a design decision made over 40 years became cast
in concrete, never to change, until the Linux hackers said, "to hell
with the standard".
- Ted