karl@??? wrote:

> I guess pam was an attempt to centralize auth things, before pam it was
> ever daemon to its own.

That's what I've always assumed - and IMO it seems like a sensible idea. After all, people don't generally object to the idea of programs calling various libraries instead of "doing their own thing".

> Useing pam doesn't hinder some daemon to ignore
> it, depending how it is written. So you have to check booth pam and
> daemon settings, it seems.

That's perhaps the main issue - with flexibility comes complexity. But in this case, I'd have thought that the flexibility of allowing "any"* program to use "any"* authentication method by supporting just one module should be considered a "good thing".
* For some definition of "any" since I suppose there could be some obscure combinations that might not work - I don't know enough about it myself.


Aldemir Akpinar <aldemir.akpinar@???> wrote:

> And I fail to see what the big deal about PAM is in this case.

+1
Though I think the argument is that if you want to mount your root filesystem via ${random method} and ${random method} uses PAM for auth, then you need PAM support in advance of being able to mount your root. Hence the need for some form of temporary filesystem containing the support tools needed to get root mounted.

Having said that, I don't think I've heard anyone suggesting that ${some form of temporary filesystem} shouldn't be supported - only that the current offering is "a bit complicated" and in many cases not needed.