On Thu, 25 Jul 2002, at 5:54pm, Derek D. Martin wrote:
> When you say this, it makes me think that you don't get GNU.  GNU's *not*
> Unix.  But it was always intended to work like Unix, by and large.

  I have written and rewritten a response to this several times now.  In all
cases, the inevitable conclusion is an argument over semantics, and/or the
fact that USAH is a holy cow for you.  I don't want to go there.  :-)

> That doesn't mean that [Linux distributors] haven't introduced their own
> brain damage ...

  Oh, gawd, have they ever.  I was never trying to say they were perfect.  
Indeed, in many cases, they have taken one or two steps back for every step
they have taken forward.  :-(

>> A good example is the whole /var/spool/mail thing.  Historical Unix made
>> that directory world writable with the sticky bit set.  The major reason for
>> that was locking -- programs created lock files in that directory to reserve
>> write access to a mailbox.  Of course, it is also a rather big security
>> exposure, especially on a large, multi-user system.
> It doesn't have to be, and it shouldn't be.

  I am sorry, but I am confused on your context here.  In that sentence,
does "it" evaluate to "the mail directory" or "a world-writable directory"?

> This is a case where the Linux developers did NOT erase a brain damage, in
> the name of making it work like traditional Unixen.

  Alas, the "let's fix it now while we have the chance" mentality does not
always win.  Sometimes for good reason, sometimes for not-so-good reasons.  
Your example, I think, is one of the not-so-good instances.

  I have noticed that Alan Cox and some of the other kernel hackers
occasionally retreat into the "Unix has always done things this way" defense
when a more objective approach might be called for.  The whole devfs debate
comes to mind....

> Proper implementation and enforcement of policy, and attention to
> permissions on created files will mitigate or eliminate most of them.

  Did you get that from Microsoft's playbook?  :-)  "Yah, we know this is a
really bad idea, but if you do this, this, and this, you can smooth most of
the wrinkles out..."  No, thank you.  :)

>> Red Hat went to the trouble of making sure all the mail programs on
>> their system use kernel-level locking (flock/fcntl), eliminating the
>> need for that long-standing braindamage.  And I say: Good!
> Sort of...  Traditionally ...

  There's that word again.  "Traditionally."

  Here is a story I like to tell:

  A daughter is watching her mother make dinner -- a roast.  She notices
that her mother cuts the end off the roast and throws it away before putting
the roast in the oven.  She asks her mother why.  Her mother says, "Well...  
um... I think it makes the juices come out and adds flavor.. but I'm not
really sure.  My friend Mary taught me to cook, and that's the way she
always did it."

  So the daughter calls her mom's friend, and asks her why she cuts the end
of the roast off.  Mary says, "You know, I never really thought about it.  
That's just the way my mom taught me to do it."  So, now being really
curious, the daughter asks for Mary's mother's phone number, and calls her.  
She asks, "Mrs. Smith, why do you cut the end of the roast off before
putting it in the oven?"  And Mrs. Smith says, "So it will fit in the pan."

  That fact that Unix has traditionally had poor file locking support is a
reason to fix things -- not to continue using poor locking!

> So if you need to interoperate via NFS with multiple platforms ... you're
> pretty much guaranteed that your locking mechanism will break somewhere,
> no matter what you pick...

  Right.  What I don't understand is why that is used as an argument in
favor of using files as lock semaphores for mail.  As you've already said,
NFS locking is notoriously wonky in a heterogeneous environment, so what Red
Hat does doesn't really make things any worse than they already were.  And
it does improve things markedly within Red Hat's domain.  I think they did
the Right Thing.

  But again, this is turning into an argument over design decisions.  
Sometimes there is more than one way to do things, and the "right" one is
more a matter of taste than anything else.

| The opinions expressed in this message are those of the author and do not |
| necessarily represent the views or policy of any other person, entity or  |
| organization.  All information is provided without warranty of any kind.  |

To unsubscribe from this list, send mail to [EMAIL PROTECTED]
with the text 'unsubscribe gnhlug' in the message body.

Reply via email to