4 ms·

The main complain of the author seems to be that linux use systemd. In my experience, systemd is far better and more reliable than anything else, especially if

by csdvrx 2y ago

The main complain of the author seems to be that linux use systemd. In my experience, systemd is far better and more reliable than anything else, especially if you need complex logic (ex: when this and that happen, start doing this, except when such and such are present) Most of the problems I've seen come from trying to duplicate systemd functions: in the author example, why bother with rsyslog or network-manager? I have also seen many people refusing to learn modern tools, instead trying to make it work with the tools they know, by disabling what works better, often with poor results. It's like trying to keep using ifconfig and route instead of ip: you can make it work, but for say managing multiple ip on the same interface forces you to go with eth0:0 eth0:1 etc (and let's not even talk about network namespaces). I like the various BSD and distributions like postmarket OS, but I wish they had access to modern tools instead of having to "roll my own" with scripts or make do with what they depend on

toast0 2y ago
> It's like trying to keep using ifconfig and route instead of ip: you can make it work, but for say managing multiple ip on the same interface forces you to go with eth0:0 eth0:1 etc (and let's not even talk about network namespaces). On FreeBSD, ifconfig works fine for having multiple addresses on the same interface (and has since like forever?? I had multiple addresses on the same interface in 2004, and it's documented in the FreeBSD 1.0 man page) and it also manages configuration for wireless interfaces too. There's no need for new tools when there is already an appropriate tool that can be updated to do the job. Keeping the existing tools working means you don't need to retrain users and you don't need to update documentation that doesn't touch the new use cases.
braincat31415 2y ago
I went back to Devuan and sysvinit for a peace of mind. Systemd works until it does not. The final straw for me were randomly missing NFS mounts after booting to multiuser. I was not able to find the fix, and the good folks on debian forums, while acknowledging the problem, could not help either.
Gud 2y ago
What tools are missing from FreeBSD? Regarding your example with "eth0:0" Is not how you do things in FreeBSD. There is no "eth0" at all. You use ifconfig xy0 alias. https://man.freebsd.org/cgi/man.cgi?query=ifconfig&apropos=0&sektion=8&manpath=FreeBSD+14.2-RELEASE&arch=default&format=html https://man.freebsd.org/cgi/man.cgi?query=ifconfig&apropos=0...
graemep 2y ago
> In my experience, systemd is far better and more reliable than anything else, especially if you need complex logic The author is talking about home servers that do not need the complex logic.
- Klonoar 2y ago
  Basic systemd is really not that complex.
  - watermelon0 2y ago
    I think the author's point is that systemd by itself is complex, and it doesn't matter if you use it in a simple configuration, or in a more complex one.
    - Klonoar 2y ago
      And I'm saying that's a somewhat ridiculous premise, because a simple systemd configuration will "just work" 99% of the time. That complexity is not something the generic case needs to care about.
  - graemep 2y ago
    My point is that the need for complex logic (see the parent comment I quoted) is not a reason to use Systemd for a home server.
yjftsjthsd-h 2y ago
> I like the various BSD and distributions like postmarket OS, but I wish they had access to modern tools instead of having to "roll my own" with scripts or make do with what they depend on It sounds like you wish they used systemd. "Modern" is rarely a good description, and at 15 years old I don't think systemd qualifies as such anyways.
- csdvrx 2y ago
  > It sounds like you wish they used systemd I do. > "Modern" is rarely a good description Then call it reliable and dependable. Modern doesn't always win for me: I prefer vim to neovim, or bash to zsh. Having a solid set of features and a good integration does. If you are curious, see https://marcelofern.com/posts/linux/goodbye_zsh/index.html https://marcelofern.com/posts/linux/goodbye_zsh/index.html which mirrors my reasons to prefer bash
  - technothrasher 2y ago
    > Modern doesn't always win for me: I prefer [...] bash to zsh Bash and zsh are approximately to same age. I think bash is older by only a few months.
    - wyclif 2y ago
      Yes, I think this confuses modern Linux users because bash is the default on most Linux server and desktop installs. So they end up thinking zsh is "new" because it's an additional package.
  - Klonoar 2y ago
    Postmarket actually wound up porting systemd somewhat recently. https://postmarketos.org/blog/2024/03/05/adding-systemd/ https://postmarketos.org/blog/2024/03/05/adding-systemd/
    - MisterTea 2y ago
      Not by choice. > This is of course not an easy task, one of the main blockers we found as we collaborate more closely with KDE and GNOME developers is that they have a hard time with our OpenRC-based stack. In order to get KDE Plasma and GNOME working at all, we use a lot of systemd polyfills on top of OpenRC.
hylaride 2y ago
99% of my issues with systemd are that it is a kitchen sink mentality. If it just dealt with process and service management, it'd mostly be minor quibbles - it was time to replace init with something. But instead it also does NTP, DHCP/networking, logging, etc. There were some very annoying teething issues with a lot of these components. It became more difficult to isolate problems buried within the systemd stack. It also became a pain to do some common, basic tasks. When the first distros starting supporting it, getting the systemd/journald logs for all the services into a central logging service was extremely painful. With (r)syslog it is just one line in a config. Heck, even the config files for systemd are littered all over the place. It didn't help that the systemd head (Lennart Poettering) was extremely intransigent with any complaints, often outright refusing to deal with various historical edge cases for long-established norms. And yes, by doing all this it the broke the long-held UNIX philosophy of "do one thing really well" and that continues to ruffle a lot of feathers. I've mainly accepted the fact that it won out, but it's helped by the fact that I'm now mostly using it to start a docker orchestrator and that all the networking is now handled by cloud-computing resources.
- csdvrx 2y ago
  > There were some very annoying teething issues with a lot of these components Currently, I don't have any issue at all, and I'm not aware of any either. I like how it's very reliable and integrated: the "kitchen sink mentality" can have positive effects > It didn't help that the systemd head (Lennart Poettering) was extremely intransigent with any complaints, often outright refusing to deal with various historical edge cases for long-established norms. In retrospect, given how well it all works, maybe he was right to refuse to compromise.
  - hylaride 2y ago
    > I like how it's very reliable and integrated: the "kitchen sink mentality" can have positive effects. Many people don't. When something more complex and integrated works it can seem perfectly fine. When something more complex and integrated fails, it often has more cascading effects that would otherwise be desired. > In retrospect, given how well it all works, maybe he was right to refuse to compromise. systemd's timesyncd is less accurate than ntpd and is terrible at dealing with drift; it is mostly only suitable for desktop timesyncing. As soon as you need to deal with synchronous timing with multiple machines, it's usually the number one problem. Even worse is that it doesn't tend to use less memory or cpu than alternatives. systemd's DHCP client continues to be a nightmare for people using it with many ISPs or corporate networks due to the creators deciding to only handle one format of optional headers (in particular option 43, but also many others) resulting in networking issues in many situations. These issues are long-historical and can even be due to ancient endian issues. Every other DHCP client implementation deals with this - except systemd's. I have to cleanup my ec2 instances because systemd's dhcp client adds 032 instead of a space to resolv.conf's search field because we have more than one domain there. In some cases these problems are because of long-established practices that technically violate an RFC. In others it's because they refuse to deal with more than one legit way of doing things. Either way, what is a service/process manager doing in this fight? When you replace something that's been around for decades (init), you're going to ruffle feathers for good and bad reasons. It's had decades of maturity. But now one is going to do it for dozens of services and not appreciate or handle the nuances that come with such a responsibility? It's literally pure arrogance - hence the hate.
johnklos 2y ago
> I have also seen many people refusing to learn modern tools One of the reasons I prefer NetBSD (and the BSDs in general) is that they don't change gratuitously. The ifconfig / ip example you use is good: Why? If we look at the reasoning given, it was that they didn't want to make big changes to ifconfig, so they made a whole new set of commands, even though the BSDs have extended ifconfig many times. So that ends up meaning that how-tos just don't work any more. Imagine if you want to write a how-to these days where you're telling people how to do something using standard ifconfig and now also need to add ip. This is how you do DNS on standard Unix(like) systems, and now you have to explain multiple iterations of systemd. This is how you add software, but now you need to have separate instructions for apt, yum, dpkg. Having administered Ubuntu for others, even going from version 18 to 20 or 22 means that how-tos no longer work, scripts need to be modified, systemd handling has to be updated, et cetera. This is why I will always choose a BSD if given a chance. Pointing to a less messy Linux (like Void because it doesn't use systemd) isn't good enough when clean, well thought out systems already exist.
- LargoLasskhyfv 2y ago
  Regarding ifconfig, one could use Jonathan de Boyne Pollard's http://jdebp.info/Softwares/nosh/guide/ifconfig.html http://jdebp.info/Softwares/nosh/guide/ifconfig.html which comes with his http://jdebp.info/Softwares/nosh/ http://jdebp.info/Softwares/nosh/
- csdvrx 2y ago
  > One of the reasons I prefer NetBSD (and the BSDs in general) is that they don't change gratuitously. I like BSDs for the integration and the performance. > So that ends up meaning that how-tos just don't work any more Complexity (or change) doesn't come out of nowhere: sometimes, new tools must be learned. > isn't good enough when clean, well thought out systems already exist. I also love well thought out systems, but I think systemd is one of these "well thought out" systems.

by csdvrx 2y ago

toast0 2y ago

> It's like trying to keep using ifconfig and route instead of ip: you can make it work, but for say managing multiple ip on the same interface forces you to go with eth0:0 eth0:1 etc (and let's not even talk about network namespaces). On FreeBSD, ifconfig works fine for having multiple addresses on the same interface (and has since like forever?? I had multiple addresses on the same interface in 2004, and it's documented in the FreeBSD 1.0 man page) and it also manages configuration for wireless interfaces too. There's no need for new tools when there is already an appropriate tool that can be updated to do the job. Keeping the existing tools working means you don't need to retrain users and you don't need to update documentation that doesn't touch the new use cases.

braincat31415 2y ago

I went back to Devuan and sysvinit for a peace of mind. Systemd works until it does not. The final straw for me were randomly missing NFS mounts after booting to multiuser. I was not able to find the fix, and the good folks on debian forums, while acknowledging the problem, could not help either.

Gud 2y ago

What tools are missing from FreeBSD? Regarding your example with "eth0:0" Is not how you do things in FreeBSD. There is no "eth0" at all. You use ifconfig xy0 alias. https://man.freebsd.org/cgi/man.cgi?query=ifconfig&apropos=0&sektion=8&manpath=FreeBSD+14.2-RELEASE&arch=default&format=html https://man.freebsd.org/cgi/man.cgi?query=ifconfig&apropos=0...

graemep 2y ago

> In my experience, systemd is far better and more reliable than anything else, especially if you need complex logic The author is talking about home servers that do not need the complex logic.

Klonoar 2y ago
Basic systemd is really not that complex.
- watermelon0 2y ago
  I think the author's point is that systemd by itself is complex, and it doesn't matter if you use it in a simple configuration, or in a more complex one.
  - Klonoar 2y ago
    And I'm saying that's a somewhat ridiculous premise, because a simple systemd configuration will "just work" 99% of the time. That complexity is not something the generic case needs to care about.
- graemep 2y ago
  My point is that the need for complex logic (see the parent comment I quoted) is not a reason to use Systemd for a home server.

yjftsjthsd-h 2y ago

> I like the various BSD and distributions like postmarket OS, but I wish they had access to modern tools instead of having to "roll my own" with scripts or make do with what they depend on It sounds like you wish they used systemd. "Modern" is rarely a good description, and at 15 years old I don't think systemd qualifies as such anyways.

csdvrx 2y ago
> It sounds like you wish they used systemd I do. > "Modern" is rarely a good description Then call it reliable and dependable. Modern doesn't always win for me: I prefer vim to neovim, or bash to zsh. Having a solid set of features and a good integration does. If you are curious, see https://marcelofern.com/posts/linux/goodbye_zsh/index.html https://marcelofern.com/posts/linux/goodbye_zsh/index.html which mirrors my reasons to prefer bash
- technothrasher 2y ago
  > Modern doesn't always win for me: I prefer [...] bash to zsh Bash and zsh are approximately to same age. I think bash is older by only a few months.
  - wyclif 2y ago
    Yes, I think this confuses modern Linux users because bash is the default on most Linux server and desktop installs. So they end up thinking zsh is "new" because it's an additional package.
- Klonoar 2y ago
  Postmarket actually wound up porting systemd somewhat recently. https://postmarketos.org/blog/2024/03/05/adding-systemd/ https://postmarketos.org/blog/2024/03/05/adding-systemd/
  - MisterTea 2y ago
    Not by choice. > This is of course not an easy task, one of the main blockers we found as we collaborate more closely with KDE and GNOME developers is that they have a hard time with our OpenRC-based stack. In order to get KDE Plasma and GNOME working at all, we use a lot of systemd polyfills on top of OpenRC.

hylaride 2y ago

99% of my issues with systemd are that it is a kitchen sink mentality. If it just dealt with process and service management, it'd mostly be minor quibbles - it was time to replace init with something. But instead it also does NTP, DHCP/networking, logging, etc. There were some very annoying teething issues with a lot of these components. It became more difficult to isolate problems buried within the systemd stack. It also became a pain to do some common, basic tasks. When the first distros starting supporting it, getting the systemd/journald logs for all the services into a central logging service was extremely painful. With (r)syslog it is just one line in a config. Heck, even the config files for systemd are littered all over the place. It didn't help that the systemd head (Lennart Poettering) was extremely intransigent with any complaints, often outright refusing to deal with various historical edge cases for long-established norms. And yes, by doing all this it the broke the long-held UNIX philosophy of "do one thing really well" and that continues to ruffle a lot of feathers. I've mainly accepted the fact that it won out, but it's helped by the fact that I'm now mostly using it to start a docker orchestrator and that all the networking is now handled by cloud-computing resources.

csdvrx 2y ago
> There were some very annoying teething issues with a lot of these components Currently, I don't have any issue at all, and I'm not aware of any either. I like how it's very reliable and integrated: the "kitchen sink mentality" can have positive effects > It didn't help that the systemd head (Lennart Poettering) was extremely intransigent with any complaints, often outright refusing to deal with various historical edge cases for long-established norms. In retrospect, given how well it all works, maybe he was right to refuse to compromise.
- hylaride 2y ago
  > I like how it's very reliable and integrated: the "kitchen sink mentality" can have positive effects. Many people don't. When something more complex and integrated works it can seem perfectly fine. When something more complex and integrated fails, it often has more cascading effects that would otherwise be desired. > In retrospect, given how well it all works, maybe he was right to refuse to compromise. systemd's timesyncd is less accurate than ntpd and is terrible at dealing with drift; it is mostly only suitable for desktop timesyncing. As soon as you need to deal with synchronous timing with multiple machines, it's usually the number one problem. Even worse is that it doesn't tend to use less memory or cpu than alternatives. systemd's DHCP client continues to be a nightmare for people using it with many ISPs or corporate networks due to the creators deciding to only handle one format of optional headers (in particular option 43, but also many others) resulting in networking issues in many situations. These issues are long-historical and can even be due to ancient endian issues. Every other DHCP client implementation deals with this - except systemd's. I have to cleanup my ec2 instances because systemd's dhcp client adds 032 instead of a space to resolv.conf's search field because we have more than one domain there. In some cases these problems are because of long-established practices that technically violate an RFC. In others it's because they refuse to deal with more than one legit way of doing things. Either way, what is a service/process manager doing in this fight? When you replace something that's been around for decades (init), you're going to ruffle feathers for good and bad reasons. It's had decades of maturity. But now one is going to do it for dozens of services and not appreciate or handle the nuances that come with such a responsibility? It's literally pure arrogance - hence the hate.

johnklos 2y ago

> I have also seen many people refusing to learn modern tools One of the reasons I prefer NetBSD (and the BSDs in general) is that they don't change gratuitously. The ifconfig / ip example you use is good: Why? If we look at the reasoning given, it was that they didn't want to make big changes to ifconfig, so they made a whole new set of commands, even though the BSDs have extended ifconfig many times. So that ends up meaning that how-tos just don't work any more. Imagine if you want to write a how-to these days where you're telling people how to do something using standard ifconfig and now also need to add ip. This is how you do DNS on standard Unix(like) systems, and now you have to explain multiple iterations of systemd. This is how you add software, but now you need to have separate instructions for apt, yum, dpkg. Having administered Ubuntu for others, even going from version 18 to 20 or 22 means that how-tos no longer work, scripts need to be modified, systemd handling has to be updated, et cetera. This is why I will always choose a BSD if given a chance. Pointing to a less messy Linux (like Void because it doesn't use systemd) isn't good enough when clean, well thought out systems already exist.

LargoLasskhyfv 2y ago
Regarding ifconfig, one could use Jonathan de Boyne Pollard's http://jdebp.info/Softwares/nosh/guide/ifconfig.html http://jdebp.info/Softwares/nosh/guide/ifconfig.html which comes with his http://jdebp.info/Softwares/nosh/ http://jdebp.info/Softwares/nosh/
csdvrx 2y ago
> One of the reasons I prefer NetBSD (and the BSDs in general) is that they don't change gratuitously. I like BSDs for the integration and the performance. > So that ends up meaning that how-tos just don't work any more Complexity (or change) doesn't come out of nowhere: sometimes, new tools must be learned. > isn't good enough when clean, well thought out systems already exist. I also love well thought out systems, but I think systemd is one of these "well thought out" systems.