supervision - discussion about system services, daemon supervision, init, runlevel management, and tools such as s6 and runit
 help / color / mirror / Atom feed
From: Vincent Danen <vdanen@linsec.ca>
Subject: Re: svlogd and umask settings
Date: Sat, 16 Sep 2006 11:20:54 -0600	[thread overview]
Message-ID: <20060916172054.GA806@annvix.org> (raw)
In-Reply-To: <20060916095109.GA24837@skarnet.org>

[-- Attachment #1: Type: text/plain, Size: 2331 bytes --]

* Laurent Bercot <ska-supervision@skarnet.org> [2006-09-16 11:51:09 +0200]:

> > and I'm aiming to protect dumb admins from themselves.
> 
>  I don't want to start a discussion here, or sound patronizing, but
> might I suggest you're on a wild goose chase ? ;)

No, I don't think I am.  I might be, but where's the harm, really?
Other than tending to sound, as you say, patronizing, or perhaps
elitist, I don't see the point in telling a user or customer what you're
telling me.  =)

>  Unix wasn't made to protect dumb admins from themselves. It was made
> to be used by people who know what they're doing. (And that's the
> reason why there are so many Unix problems and misconfigurations.)

Absolutely.  But that doesn't mean it can't be done differently, or more
correctly.  It certainly doesn't mean that I shouldn't bother or try and
assume a holier-than-thou "if you can't figure it out you don't deserve
to use it" attitude.  Of course, if they bugger things up even with the
little bits of properness that are implemented, it's still *their*
problem (not mine), but as a Linux distributor I'm doing my part to ease
things.

>  I have found so far that the most efficient way to write software that
> aims to ensure proper working and security of a Unix system is to set
> clear boundaries and document them: point A is the software's
> responsibility, point B is *your* responsibility as the admin and you
> should make sure it works before running the software.

Sure, but I'm not coding anything.  I'm packaging a Linux distribution.
So setting sane defaults and whatnot is part of the "job".

>  Anyway. Enough ranting.

Yeah, that's fine.  You can rant all you like, but it doesn't much
matter to me.  Others might take your elitist attitude to heart, and
that's fine (for some stuff I also share similar elitist attitudes), but
to sit back and tell people they're not smart enough to use it so I
won't bother making it any easier on them seems, well, really arrogant.

But that's ok too... it is unix after all and we are, more often than
not, elitist, arrogant, and better than the mindless sheep that use
other operating systems.  =)

-- 
{FEE30AD4 : 7F6C A60C 06C2 4811 FA1C  A2BC 2EBC 5E32 FEE3 0AD4}
mysql> SELECT * FROM users WHERE clue > 0;
Empty set (0.00sec)

[-- Attachment #2: Type: application/pgp-signature, Size: 186 bytes --]

  reply	other threads:[~2006-09-16 17:20 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-08-30 22:03 Vincent Danen
2006-09-01 17:49 ` Vincent Danen
2006-09-15 14:47   ` Gerrit Pape
2006-09-15 15:22     ` Vincent Danen
2006-09-16  9:51       ` Laurent Bercot
2006-09-16 17:20         ` Vincent Danen [this message]
2006-09-18 15:18       ` Christian Holtje
2006-09-18 16:06         ` Vincent Danen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20060916172054.GA806@annvix.org \
    --to=vdanen@linsec.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).