mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@aerifal.cx>
To: musl@lists.openwall.com
Subject: Re: make -i with linux-pam
Date: Tue, 22 May 2012 16:00:02 -0400	[thread overview]
Message-ID: <20120522200002.GV163@brightrain.aerifal.cx> (raw)
In-Reply-To: <ec7187ecbdf1f2e6b961f3f7aff490df@exys.org>

On Tue, May 22, 2012 at 08:45:24PM +0200, aep wrote:
> >They might be _used to_ it working, but that doesn't
> >necessarily mean they "want" it.
> 
> Heh, this is where the difference in mindset shows. I tend to think
> people using things, actually want them.

That would make sense if there were any evidence they chose to use
them, but if they just ended up with these things by default, it's not
so clear...

> >With that said, one acceptable approach might be to have utmp/wtmp
> >support exist, but silently bail out (reporting success) if the file
> >does not exist.
> 
> having utmp in libc is just so utterly wrong in the first place.
> This really belongs in the higher stack, where decisions like that
> can be made based on config files.

It really belongs in PAM. And not by PAM just making calls to libc,
but by PAM doing its own utmp-like thing if the admin wants to.

> Sounds like an interesting problem for your platform vision :)

No, sounds like a problem for somebody else's. My view is that layer
upon layer of unnecessary crap like this that's leaked into all sorts
of progams is what's led us to a bad platform. Part of why I'm such a
supporter of the POSIX standard in particular is because, despite the
flaws of some of its interfaces designed by committee, they did a
great job of looking at the historical corpus of crap and making
decisions about which interfaces are actually necessary and useful to
write user-facing applications, and which ones were purely part of the
ugly inner workings of historical systems. utmp is clearly among the
latter.

My platform goals are (in the abstract):

(1) To be able to run user-facing applications.

(2) To Get Stuff Done™ at the system level, without a lot of regard
for how it was traditionally done.

I suppose some people who are attached to tradition won't like the
last part of #2, but they don't like it in the FDO regime either, and
yet they go along with it, even though the FDO stuff generally doesn't
Get Stuff Done™ and suffers from massive bloat and unpredictable or
unstable behavior..


Rich


      reply	other threads:[~2012-05-22 20:00 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-14  3:58 Isaac Dunham
2012-05-14  4:11 ` Rich Felker
2012-05-14 18:01   ` Isaac Dunham
2012-05-14 18:17     ` Rich Felker
2012-05-15  0:09   ` Isaac Dunham
2012-05-16  3:24     ` Rich Felker
2012-05-16 14:23       ` Isaac Dunham
2012-05-21 19:12       ` aep
2012-05-21 19:28         ` Rich Felker
2012-05-21 20:24           ` aep
2012-05-21 20:55             ` Rich Felker
2012-05-21 21:08               ` aep
2012-05-21 21:20                 ` Rich Felker
2012-05-22 16:51             ` Christian Neukirchen
2012-05-22 17:50               ` Rich Felker
2012-05-22 18:22               ` aep
2012-05-22 18:28                 ` Rich Felker
2012-05-22 18:45                   ` aep
2012-05-22 20:00                     ` Rich Felker [this message]

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=20120522200002.GV163@brightrain.aerifal.cx \
    --to=dalias@aerifal.cx \
    --cc=musl@lists.openwall.com \
    /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.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

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).