4 ms·

That change log is HUGE and it’s the main reason we don’t use systemd. Creeping featurism isn’t good in your OS when you need things to be consistent and work t

by Klwohu 6y ago

That change log is HUGE and it’s the main reason we don’t use systemd. Creeping featurism isn’t good in your OS when you need things to be consistent and work the same every time. Systemd has a lot of state.

greyw 6y ago
Who is we? I use systemd on the operating systems I use (debian, centos and opensuse)
- Klwohu 6y ago
  Our organization. It doesn’t make sense to rely on software which grows to consume all available niches. Systemd is a perfect example of this kind of software. I don’t wish to have to ascertain what new features it’s reimplemented, sometimes in ways which are not POSIX compliant, every time there’s an update.
  - esarbe 6y ago
    Do I guess correctly that your organization doesn't value clean services initialization, solid services dependencies management and reliable log handling? Well, there must be room for such organizations too. It's a colorful world after all.
    - Klwohu 6y ago
      No, we get all of that with time-worn traditional methods which work well, are documented properly, and conform to standards. I’m not interested in beta testing Red Hat’s replacement for Linux.
dgellow 6y ago
I'm very happily using systemd since a bit less than a decade now. It's fantastic to have a common standardized way to manage your services and jobs that doesn't rely on a fragile set of scripts, and unified logs that can be easily queried and exported to a machine readable format.
- generalizations 6y ago
  I've never had an issue with the shell scripts that run my systems, and I consider it a strength that they can be easily modified. Why do people always seem to make 'no more fragile scripts' their first point in favor of systemd?
  - dgellow 6y ago
    Because sh and bash are horror shows. Maintaining and creating new service init scripts is a real pain and difficult to do with consistency. Bash scripts can do anything, meaning they have to be audited one by one, every single time they are updated. Every single distribution has its own way to run services via scripts. And that can change between upgrades. In the systemd world, I can audit a unit file via a simple `systemctl cat <name>`, and edit it directly via `systemctl edit <name>`. I can easily see services dependencies, I can easily change the user running the service, the workdir, etc. There is a standard interface to start, stop, restart, enable at startup. All of this from one system that is consistent and the same between Linux systems. But really the best features IMHO is journald.
    - Klwohu 6y ago
      sh isn't a horror show, it's a POSIX standard and it's pretty easy to learn. Does systemd conform to any known standard? Of course not, they're making it up as they go. When's it going to be finished? Nobody knows. You simply can't rely on it.
      - zaarn 6y ago
        The core primitives of systemd units haven't changed in a long while. You can always rely on it being able to start your service and stop it. What might not work depending on what version of systemd you ship is additional parameters (such as requiring a path to exist outside mountpoints or setting resource limits).
    - generalizations 6y ago
      Well, thanks for telling me how you see it. I can't say I agree with almost anything you've said, but it's definitely informative. My perspective is that on the one hand, systemd is very 'cerimonial' in how it goes about things, while shell-based systems have the potential to be extremely well done. My go-to example is the OpenBSD init script - I once tried to boot OBSD over the network, and mount it on a RAM filesytem, and was able to simply open that boot script and change the mount commands. Ever since, I've been impressed by the clarity and simplicity of that shell script (in its original form, not after I was done with it (: ). > Because sh and bash are horror shows. I disagree. The syntax is obtuse, but it is at this point very well understood, and the rest of the system runs on it. Better to use fewer languages throughout, than more. Are you referring to something other than the syntax? > Maintaining and creating new service init scripts is a real pain and difficult to do with consistency. I'm not sure, but it sounds like you're talking about systemd services. If you are, I agree; multiple files with layers of cerimony are hard to compare to an extra line of shell core in an rc.local. If you're talking about non-systemd, I've never encountered this, and certainly found the process far less painful than the systemd way. > Bash scripts can do anything, meaning they have to be audited one by one, every single time they are updated. Just diff the scripts...not that hard. Just have to check the changes. That's no harder than any other program you care about. > Every single distribution has its own way to run services via scripts. vive la différence! No point to the stagnation caused by homogeniety; I don't see why I should expect debian services to run the same as FreeBSD. > And that can change between upgrades. Systemd is notorious for changing things. One great example is when they tried to change how processes can persist after the user logs out. I don't think you have a leg to stand on here. In the systemd world, I can audit a unit file via a simple `systemctl cat <name>`, and edit it directly via `systemctl edit <name>`. I can too: `cat /etc/rc.local` and `vim /etc/rc.local`. Added benefit, I'm using the same tools and interfaces that I do for the rest of my system administration. > I can easily see services dependencies, I can easily change the user running the service, the workdir, etc. Service dependencies are the strong point of systemd, I will give you that. However, `su` can change the user running the command, and `cd` is this awesome little tool I found for changing the directory I'm in. No extra benefit there, just new commands for doing the same old things. > There is a standard interface to start, stop, restart, enable at startup. That standard interface is only useful because the underlying complexity has increased so much that `systemctl start` has become a necessary abstraction to cover it up. Your standard interface is medicine for an ailment I do not have. > All of this from one system that is consistent and the same between Linux systems. Why is that beneficial? It just means that you've put all the innovation in the hands of the systemd devs. I'm over on systems like void, where my startup times are faster, my base system load is a third, and I can get my hands dirty in the system internals without googling for strange systemd incantations. > But really the best features IMHO is journald. You're going to have to spell that out, because I really like being able to use a proliferation of text-oriented tools to manage my logs. I'm not a fan of binary, no matter the supposed speed improvements.
Jasper_ 6y ago
Wait until you see the Linux kernel changelogs...

by Klwohu 6y ago

greyw 6y ago

Who is we? I use systemd on the operating systems I use (debian, centos and opensuse)

Klwohu 6y ago
Our organization. It doesn’t make sense to rely on software which grows to consume all available niches. Systemd is a perfect example of this kind of software. I don’t wish to have to ascertain what new features it’s reimplemented, sometimes in ways which are not POSIX compliant, every time there’s an update.
- esarbe 6y ago
  Do I guess correctly that your organization doesn't value clean services initialization, solid services dependencies management and reliable log handling? Well, there must be room for such organizations too. It's a colorful world after all.
  - Klwohu 6y ago
    No, we get all of that with time-worn traditional methods which work well, are documented properly, and conform to standards. I’m not interested in beta testing Red Hat’s replacement for Linux.

dgellow 6y ago

I'm very happily using systemd since a bit less than a decade now. It's fantastic to have a common standardized way to manage your services and jobs that doesn't rely on a fragile set of scripts, and unified logs that can be easily queried and exported to a machine readable format.

generalizations 6y ago
I've never had an issue with the shell scripts that run my systems, and I consider it a strength that they can be easily modified. Why do people always seem to make 'no more fragile scripts' their first point in favor of systemd?
- dgellow 6y ago
  Because sh and bash are horror shows. Maintaining and creating new service init scripts is a real pain and difficult to do with consistency. Bash scripts can do anything, meaning they have to be audited one by one, every single time they are updated. Every single distribution has its own way to run services via scripts. And that can change between upgrades. In the systemd world, I can audit a unit file via a simple `systemctl cat <name>`, and edit it directly via `systemctl edit <name>`. I can easily see services dependencies, I can easily change the user running the service, the workdir, etc. There is a standard interface to start, stop, restart, enable at startup. All of this from one system that is consistent and the same between Linux systems. But really the best features IMHO is journald.
  - Klwohu 6y ago
    sh isn't a horror show, it's a POSIX standard and it's pretty easy to learn. Does systemd conform to any known standard? Of course not, they're making it up as they go. When's it going to be finished? Nobody knows. You simply can't rely on it.
    - zaarn 6y ago
      The core primitives of systemd units haven't changed in a long while. You can always rely on it being able to start your service and stop it. What might not work depending on what version of systemd you ship is additional parameters (such as requiring a path to exist outside mountpoints or setting resource limits).
  - generalizations 6y ago
    Well, thanks for telling me how you see it. I can't say I agree with almost anything you've said, but it's definitely informative. My perspective is that on the one hand, systemd is very 'cerimonial' in how it goes about things, while shell-based systems have the potential to be extremely well done. My go-to example is the OpenBSD init script - I once tried to boot OBSD over the network, and mount it on a RAM filesytem, and was able to simply open that boot script and change the mount commands. Ever since, I've been impressed by the clarity and simplicity of that shell script (in its original form, not after I was done with it (: ). > Because sh and bash are horror shows. I disagree. The syntax is obtuse, but it is at this point very well understood, and the rest of the system runs on it. Better to use fewer languages throughout, than more. Are you referring to something other than the syntax? > Maintaining and creating new service init scripts is a real pain and difficult to do with consistency. I'm not sure, but it sounds like you're talking about systemd services. If you are, I agree; multiple files with layers of cerimony are hard to compare to an extra line of shell core in an rc.local. If you're talking about non-systemd, I've never encountered this, and certainly found the process far less painful than the systemd way. > Bash scripts can do anything, meaning they have to be audited one by one, every single time they are updated. Just diff the scripts...not that hard. Just have to check the changes. That's no harder than any other program you care about. > Every single distribution has its own way to run services via scripts. vive la différence! No point to the stagnation caused by homogeniety; I don't see why I should expect debian services to run the same as FreeBSD. > And that can change between upgrades. Systemd is notorious for changing things. One great example is when they tried to change how processes can persist after the user logs out. I don't think you have a leg to stand on here. In the systemd world, I can audit a unit file via a simple `systemctl cat <name>`, and edit it directly via `systemctl edit <name>`. I can too: `cat /etc/rc.local` and `vim /etc/rc.local`. Added benefit, I'm using the same tools and interfaces that I do for the rest of my system administration. > I can easily see services dependencies, I can easily change the user running the service, the workdir, etc. Service dependencies are the strong point of systemd, I will give you that. However, `su` can change the user running the command, and `cd` is this awesome little tool I found for changing the directory I'm in. No extra benefit there, just new commands for doing the same old things. > There is a standard interface to start, stop, restart, enable at startup. That standard interface is only useful because the underlying complexity has increased so much that `systemctl start` has become a necessary abstraction to cover it up. Your standard interface is medicine for an ailment I do not have. > All of this from one system that is consistent and the same between Linux systems. Why is that beneficial? It just means that you've put all the innovation in the hands of the systemd devs. I'm over on systems like void, where my startup times are faster, my base system load is a third, and I can get my hands dirty in the system internals without googling for strange systemd incantations. > But really the best features IMHO is journald. You're going to have to spell that out, because I really like being able to use a proliferation of text-oriented tools to manage my logs. I'm not a fan of binary, no matter the supposed speed improvements.

Jasper_ 6y ago

Wait until you see the Linux kernel changelogs...