linux-kernel - Re: UNIX Compatibility

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4DDD67B4.5080803@schaufler-ca.com>
Date:	Wed, 25 May 2011 13:33:56 -0700
From:	Casey Schaufler <casey@...aufler-ca.com>
To:	Michael Witten <mfwitten@...il.com>
CC:	Ted Ts'o <tytso@....edu>, Mike Galbraith <efault@....de>,
	Richard Yao <ryao@...sunysb.edu>, linux-kernel@...r.kernel.org
Subject: Re: UNIX Compatibility

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 majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>
>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/