5 ms·

THIS. Also what problem does it solve that RC scripts can't accomplish? They are much more readable and less complex. What is the benefit of all that added comp

THIS. Also what problem does it solve that RC scripts can't accomplish? They are much more readable and less complex. What is the benefit of all that added complexity? Even more to the point the business case for it in a professional setting? I've been wondering that for a long time.

rootnod3 10mo ago
It autodiscovers the dependency chain or shit like that? If you got 500+ services that need to be orchestrated you honestly have a very different problem. I love the simplicity of RC scripts. Easy to understand, easy to debug, it just fucking works. Simplicity is king, because it's understandable. A behemoth like systemd feels like it requires a PhD. Systemd also runs 100% against the Unix/Linux philosophy of composability and single purpose.
- arthurfirst 10mo ago
  THIS ---- Systemd also runs 100% against the Unix/Linux philosophy of composability and single purpose.
- tombert 10mo ago
  If you need to make sure that the network stack starts after the usb stack and that starts after the pcie stack and that starts after the … then systemd is considerably easier than SysV init. You’re handwaving away something that is pretty important. You can say that having 500 services is its own problem but it’s also a reality, even on desktop operating systems.
  - rootnod3 10mo ago
    Count how many services you have that are not already defined by the system itself in its order? So, remove core system services. System itself should already make sure that USB starts after PCIE and all that. So go and count all the services that are not base install and tell me how many you have.
- pezezin 10mo ago
  In which bizarre world is an RC script easier to understand than a systemd service file? There is nothing simple about RC scripts.
rootnod3 10mo ago
Addendum to my other reply: it comes down to the "not invented here" problem which always invites weirdly complex solutions to problems that don't exist. Linux is "just" the kernel and every distro invites new solutions to perceived core problems whereas the BSDs have a whole base system that comes from one source, reducing the chance of a systemd popping up there. Both approaches have their ups and downs.
shakow 10mo ago
Barging in as a Linux guy interested to learn more about the BSDs, so please bear with me. Something I love with systemd is how I can get very useful stats about a running process, e.g. uptime, cumulated disk & network IOs, current & peak mem usage, etc. Also the process management (e.g. restart rules & dependency chain) is pretty nice as well. Is that doable with RC (or other BSD-specific tooling) as well?
- rootnod3 10mo ago
  It's up to you to say check in your init script if you need to start another service before you. In terms of uptime or IO and stuff, those metrics are already available. Be that via SNMP or other means. Say you start an nginx in systems, which network and disk usage does it report? Just the main process or all its forks? Same problem in RC. But that is part of the point. Why in the ever-loving existence should an INIT system provide stats like disk usage? That is NOT what an init system is for. If you need memory usage or IO usage or uptime, there are so many other tools already integrated into the system that the init system doesn't need to bother. Init systems should only care about starting, stopping and restarting services. Period. The moment they do more than that, they failed at their core job. This might came across stronger than meant to, but still holds true. BSDs are about "keep it simple, keep it single purpose" to a "I can live with that degree". What you get though is outstanding documentation and every component is easily understandable. Prime examples are OpenBSD/FreeBSD PF. That firewall config is just easy to grok, easy to read up on and does 99.999% of what you ever need out of a firewall.
  - shakow 10mo ago
    > which network and disk usage does it report? Just the main process or all its forks? Same problem in RC. Well, the main process and its whole hierarchy, that's what you would expect of an init system monitoring its services, right? And what's nice with systemd is that I can get that from a simple `systemctl status my-service` – of course I could deploy a whole observability stack, but better if I can avoid it. But there is no need to be defensive, it RC can that's nice, if it can't, then well, too bad. > there are so many other tools already integrated into the system that the init system doesn't need to bother. That's what I'd love to hear about, what are the equivalent in the BSDs world.

rootnod3 10mo ago

It autodiscovers the dependency chain or shit like that? If you got 500+ services that need to be orchestrated you honestly have a very different problem. I love the simplicity of RC scripts. Easy to understand, easy to debug, it just fucking works. Simplicity is king, because it's understandable. A behemoth like systemd feels like it requires a PhD. Systemd also runs 100% against the Unix/Linux philosophy of composability and single purpose.

arthurfirst 10mo ago
THIS ---- Systemd also runs 100% against the Unix/Linux philosophy of composability and single purpose.
tombert 10mo ago
If you need to make sure that the network stack starts after the usb stack and that starts after the pcie stack and that starts after the … then systemd is considerably easier than SysV init. You’re handwaving away something that is pretty important. You can say that having 500 services is its own problem but it’s also a reality, even on desktop operating systems.
- rootnod3 10mo ago
  Count how many services you have that are not already defined by the system itself in its order? So, remove core system services. System itself should already make sure that USB starts after PCIE and all that. So go and count all the services that are not base install and tell me how many you have.
pezezin 10mo ago
In which bizarre world is an RC script easier to understand than a systemd service file? There is nothing simple about RC scripts.

rootnod3 10mo ago

Addendum to my other reply: it comes down to the "not invented here" problem which always invites weirdly complex solutions to problems that don't exist. Linux is "just" the kernel and every distro invites new solutions to perceived core problems whereas the BSDs have a whole base system that comes from one source, reducing the chance of a systemd popping up there. Both approaches have their ups and downs.

shakow 10mo ago

Barging in as a Linux guy interested to learn more about the BSDs, so please bear with me. Something I love with systemd is how I can get very useful stats about a running process, e.g. uptime, cumulated disk & network IOs, current & peak mem usage, etc. Also the process management (e.g. restart rules & dependency chain) is pretty nice as well. Is that doable with RC (or other BSD-specific tooling) as well?

rootnod3 10mo ago
It's up to you to say check in your init script if you need to start another service before you. In terms of uptime or IO and stuff, those metrics are already available. Be that via SNMP or other means. Say you start an nginx in systems, which network and disk usage does it report? Just the main process or all its forks? Same problem in RC. But that is part of the point. Why in the ever-loving existence should an INIT system provide stats like disk usage? That is NOT what an init system is for. If you need memory usage or IO usage or uptime, there are so many other tools already integrated into the system that the init system doesn't need to bother. Init systems should only care about starting, stopping and restarting services. Period. The moment they do more than that, they failed at their core job. This might came across stronger than meant to, but still holds true. BSDs are about "keep it simple, keep it single purpose" to a "I can live with that degree". What you get though is outstanding documentation and every component is easily understandable. Prime examples are OpenBSD/FreeBSD PF. That firewall config is just easy to grok, easy to read up on and does 99.999% of what you ever need out of a firewall.
- shakow 10mo ago
  > which network and disk usage does it report? Just the main process or all its forks? Same problem in RC. Well, the main process and its whole hierarchy, that's what you would expect of an init system monitoring its services, right? And what's nice with systemd is that I can get that from a simple `systemctl status my-service` – of course I could deploy a whole observability stack, but better if I can avoid it. But there is no need to be defensive, it RC can that's nice, if it can't, then well, too bad. > there are so many other tools already integrated into the system that the init system doesn't need to bother. That's what I'd love to hear about, what are the equivalent in the BSDs world.