4 ms·

> All of the PAM modules are named pam_xxxxx.so so the configuration file only needs to specify the name, ie the xxxxx. I would rather type a few extra charact

> All of the PAM modules are named pam_xxxxx.so so the configuration file only needs to specify the name, ie the xxxxx. I would rather type a few extra characters so that it is blindingly obvious that "pam_foo.so" in the config file will load code from pam_foo.so in the filesystem. Typing only "foo" would remove a little clutter, but it would also increase my cognitive load a little.

tablespoon 5y ago
>> All of the PAM modules are named pam_xxxxx.so so the configuration file only needs to specify the name, ie the xxxxx. > I would rather type a few extra characters so that it is blindingly obvious that "pam_foo.so" in the config file will load code from pam_foo.so in the filesystem. > Typing only "foo" would remove a little clutter, but it would also increase my cognitive load a little. Exactly. Sometimes magic like what the GP wants is evil. It sub-optimally trades a steeper learning curve for some too-small convenience. It's like buying a shiny new penny for a dollar.
- notyourday 5y ago
  > It's like buying a shiny new penny for a dollar. That's bonk. PAM significantly simplified the ecosystem - at the time there were dozens specialized hack upon hack upon hack login suits such as * login-otp * login-shadow * login-skey * des-login * login-rsa-otp that implemented some of the functionality for some of the manipulations, sometimes on the same system. Some of them already used shared libraries and some of those shared libraries already used the names. Specifying loading paths fully was considered a bad idea because of how subsystems were installed on the deployed servers. The decisions about name collisions ( pam_ prefix ), following Sun's original specs ( some of the names of stages ), etc were made from those constraints. It needed to be deployable on the top of the existing login systems where the users would not be locked out because of some sort of a conflict. PAM significantly simplified that messy ecosystem while being extremely system, which is why it won and remains the integral part of the ecosystem for twenty seven years. But hey, this is open source -- don't like it? Rewrite it in Rust! Just remember that first you would need to make sure that Rust exists on all the platforms PAM has been used on.[0] [0] Pam-static was created as during the first few releases Linux/Alpha did not have support for shared libraries. So there it was, Pluggable Authentication Modules which on Alpha did not have dynamic loaders.
  - tablespoon 5y ago
    >>>> All of the PAM modules are named pam_xxxxx.so so the configuration file only needs to specify the name, ie the xxxxx. >> It's like buying a shiny new penny for a dollar. > That's bonk. PAM significantly simplified the ecosystem... That's not what I was talking about at all. I wasn't talking about PAM itself, but the commenter's impulse to use an abbreviated name of the module in the config rather than the module's actual name. PAM did that right by using the full name in my opinion.
    - notyourday 5y ago
      I misunderstood. My apologies.

tablespoon 5y ago

>> All of the PAM modules are named pam_xxxxx.so so the configuration file only needs to specify the name, ie the xxxxx. > I would rather type a few extra characters so that it is blindingly obvious that "pam_foo.so" in the config file will load code from pam_foo.so in the filesystem. > Typing only "foo" would remove a little clutter, but it would also increase my cognitive load a little. Exactly. Sometimes magic like what the GP wants is evil. It sub-optimally trades a steeper learning curve for some too-small convenience. It's like buying a shiny new penny for a dollar.

notyourday 5y ago
> It's like buying a shiny new penny for a dollar. That's bonk. PAM significantly simplified the ecosystem - at the time there were dozens specialized hack upon hack upon hack login suits such as * login-otp * login-shadow * login-skey * des-login * login-rsa-otp that implemented some of the functionality for some of the manipulations, sometimes on the same system. Some of them already used shared libraries and some of those shared libraries already used the names. Specifying loading paths fully was considered a bad idea because of how subsystems were installed on the deployed servers. The decisions about name collisions ( pam_ prefix ), following Sun's original specs ( some of the names of stages ), etc were made from those constraints. It needed to be deployable on the top of the existing login systems where the users would not be locked out because of some sort of a conflict. PAM significantly simplified that messy ecosystem while being extremely system, which is why it won and remains the integral part of the ecosystem for twenty seven years. But hey, this is open source -- don't like it? Rewrite it in Rust! Just remember that first you would need to make sure that Rust exists on all the platforms PAM has been used on.[0] [0] Pam-static was created as during the first few releases Linux/Alpha did not have support for shared libraries. So there it was, Pluggable Authentication Modules which on Alpha did not have dynamic loaders.
- tablespoon 5y ago
  >>>> All of the PAM modules are named pam_xxxxx.so so the configuration file only needs to specify the name, ie the xxxxx. >> It's like buying a shiny new penny for a dollar. > That's bonk. PAM significantly simplified the ecosystem... That's not what I was talking about at all. I wasn't talking about PAM itself, but the commenter's impulse to use an abbreviated name of the module in the config rather than the module's actual name. PAM did that right by using the full name in my opinion.
  - notyourday 5y ago
    I misunderstood. My apologies.