2 ms·

> systemd is a large beast -- no need to make it larger with unrelated things I think I sufficiently explained why it is very much related. > the Unix philoso

by deng 2y ago

> systemd is a large beast -- no need to make it larger with unrelated things I think I sufficiently explained why it is very much related. > the Unix philosophy seems to be applicable here Systemd very much follows the unix philosophy. It is not one big binary, but actually consists of dozens and dozens of tools communicating with each other through protocols. > the result should be portable to non-systemd systems Portable on what basis? POSIX?

Spivak 2y ago
People who just have an axe to grind with systemd really don't like when you point out that it's incredibly modular and follows the unix philosophy. I think what people mean to say but don't have the words for is that systemd is an East coast school of thought project and folks prefer "worse is better" style tools.
- cryptonector 2y ago
  I like the idea behind systemd. I don't have an axe to grind. I don't want SysV init or whatever you might think.
cryptonector 2y ago
> I think I sufficiently explained why it is very much related. This: | Systemd already handles logins ? But I don't see why a bring-up/shutdown system should handle logins. > Systemd very much follows the unix philosophy. It is not one big binary, but actually consists of dozens and dozens of tools communicating with each other through protocols. That is fine. As long as this service (sudo replacement) is a standalone, separate daemon started by a systemd unit, I'm happy. If it's a core part of systemd itself then I'm not happy. > Portable on what basis? POSIX? Or Linux / glibc / musl, sure, why not. Some people (no, not me) want to run Linux w/o systemd. The point is that a sudo replacement service should be fairly portable to the universe of UNIX/Unix/BSD/Linux.
- deng 2y ago
  > Or Linux / glibc / musl, sure, why not. Some people (no, not me) want to run Linux w/o systemd. The point is that a sudo replacement service should be fairly portable to the universe of UNIX/Unix/BSD/Linux. This fetish of "everything should just stick with libc and POSIX" needs to go. These standards have not evolved at all, they are decades behind and don't even remotely cover the necessary requirements for implementing a "sudo replacement service". Just stick with sudo then.

by deng 2y ago

Spivak 2y ago

People who just have an axe to grind with systemd really don't like when you point out that it's incredibly modular and follows the unix philosophy. I think what people mean to say but don't have the words for is that systemd is an East coast school of thought project and folks prefer "worse is better" style tools.

cryptonector 2y ago
I like the idea behind systemd. I don't have an axe to grind. I don't want SysV init or whatever you might think.

cryptonector 2y ago

> I think I sufficiently explained why it is very much related. This: | Systemd already handles logins ? But I don't see why a bring-up/shutdown system should handle logins. > Systemd very much follows the unix philosophy. It is not one big binary, but actually consists of dozens and dozens of tools communicating with each other through protocols. That is fine. As long as this service (sudo replacement) is a standalone, separate daemon started by a systemd unit, I'm happy. If it's a core part of systemd itself then I'm not happy. > Portable on what basis? POSIX? Or Linux / glibc / musl, sure, why not. Some people (no, not me) want to run Linux w/o systemd. The point is that a sudo replacement service should be fairly portable to the universe of UNIX/Unix/BSD/Linux.

deng 2y ago
> Or Linux / glibc / musl, sure, why not. Some people (no, not me) want to run Linux w/o systemd. The point is that a sudo replacement service should be fairly portable to the universe of UNIX/Unix/BSD/Linux. This fetish of "everything should just stick with libc and POSIX" needs to go. These standards have not evolved at all, they are decades behind and don't even remotely cover the necessary requirements for implementing a "sudo replacement service". Just stick with sudo then.