4 ms·

That's true but what we're hoping for is that Debian doesn't change things so much that sysvinit is unusable. Systemd does have its advantages but some people _

by castis 7y ago

That's true but what we're hoping for is that Debian doesn't change things so much that sysvinit is unusable. Systemd does have its advantages but some people _like_ sysvinit.

shawnz 7y ago
> but some people _like_ sysvinit Is that really true, or is it just that some people have a grudge against systemd and sysvinit is the only other practical option?
- johnr2 7y ago
  >> but some people _like_ sysvinit > Is that really true Yes
  - IntelMiner 7y ago
    Forgive me if it sounds like I'm trying to bait into an argument, but Why? What is the appeal of writing immensely long, fragile shell scripts? Having to wrap them in various monitoring and logging daemons Having to have different ones for every distro you want to support with your software Is this something that is truly a productive use of your time? Putting aside the question of if systemd is "good" or not. Is the current sysvinit system truly "good enough" and not in need of change?
    - yjftsjthsd-h 7y ago
      > Is the current sysvinit system truly "good enough" and not in need of change? Something having been used for decades certainly doesn't mean that it's optimal and shouldn't be changed, but it does strongly suggest that it's good enough.
    - johnr2 7y ago
      > Is the current sysvinit system truly "good enough" and not in need of change? For me it's relative and a case of "the devil I know". I actually prefer BSD-style init to sysvinit, but I've used the latter for ~20 years. I'm aware that traditional init systems may not meet the requirements of certain users (eg. those who run very large server installations), but for my simple use case (small servers and workstations) they do the job. I'm not against change per se; I'm running Void (with runit) on one of my systems, and the desktop I'm using to post this runs OpenBSD.
- madhadron 7y ago
  Stockholm syndrome is a thing.
- krzyk 7y ago
  sysvinit is simple, and I didn't have any major issues with it. On the other hand, systemd is too big, takes on too much responsibility (really I need a system to retrieve logs in it? or a way to run local dns?). Since last update on my ubuntu desktop I can't get dns to work from DHCP, I need to overwrite /etc/resolv.conf with correct nameservers after each restart (BTW. Why would anyone think that running local DNS is a good default option - I see `nameserver 127.0.0.1` in the overwritten file). And the second one on Debian on my laptop, when I run VPN (openconnect) name resolution fails, and I need again - ovewrite resolv.conf. I didn't have such problems with sysvinit. systemd is so controversial that I'm astonished why it is used in any distro.
  - ernst_klim 7y ago
    > sysvinit is simple, and I didn't have any major issues with it. How do you encode service dependencies? If a service dies, what happens to services relying on it on your system?
    - csande17 7y ago
      At least on my desktop machine, there aren't a whole lot of services that directly depend on other services. Usually, a service will provide some functionality (e.g. sound) used by applications I launch. As far as I know, systemd doesn't help with that, and I don't really want it to--imagine if systemd suddenly killed and restarted your browser! Also, maybe I'm just lucky (or using popular hardware, or something), but services on my machine don't just randomly die for no reason. NetworkManager, sshd, etc all seem pretty well-written and stable.
      - ernst_klim 7y ago
        >As far as I know, systemd doesn't help with that It depends on the service in use and how is it defined. I have an embedded system in production, which have quite a complex graph of dependencies, some of which should be restarted on sudden death of others, some of which should persist anyways. Needless to say that systemd provides an incredible, robust and easy way of solving that, I had to write just a few 10-line long unit files for in-house software and use standard units provided by standard daemons. >imagine if systemd suddenly killed and restarted your browser Because your browsed doesn't rely on them. But my web interface definitely depends on NetworkManager, because it speaks to it via d-bus.
- cthalupa 7y ago
  >Is that really true, or is it just that some people have a grudge against systemd and sysvinit is the only other practical option? Well, considering quite a few distros had already replaced sysvinit with upstart prior to systemd, obviously we have multiple options besides sysvinit. There's also options such as openrc, which will let you make use of whatever you want for pid 1, and manage services elsewhere. In general, whether or not replacing systemd with something besides sysvinit/upstart is a practical option depends on how reliant you are on packages provided by an upstream distro or 3rd party. It isn't particularly hard to just swap init systems on several distros - debian included - but there are varying levels of tie-in with provided packages. If you're building all of your required packages with a CI/CD pipeline and deploying with containers based on a minimal linux distro, you could relatively easily use a myriad of systemd and sysvinit alternatives. If you're just deploying on RHEL or Ubuntu VMs and doing yum/apt install to get your software, it's relatively more difficult. Personally, I think sysvinit needs to be relegated to the annals of history. But I also have been bitten in production many times by systemd bugs, which due to the more... integrated... nature of systemd and it's components have been more trying to troubleshoot and have resulted in longer periods of problematic behavior, increased system level outages, and other headaches. Back when I worked with Solaris, I loved SMF - not so much the XML portion of it, but it worked well, was leaps and bounds ahead of sysvinit in usability in features, and didn't manage to induce nearly as many problems in my production environments as systemd has. And this isn't the first project I've wasted hundreds of hours of my life troubleshooting from the key systemd maintainers. My general experience with their projects has left the impression that they are not nearly as concerned at making their software bug-free as they are chasing features and use cases that interest them. Which is fine - they're welcome to write whatever software they want and prioritize things however they want. My hope is that some other init system which recognizes the fact that it's no longer the 80s receives traction. Init scripts are awful, and no one should be writing them in this day and age, but I would prefer a system that only has a subset of systemd features but is instead focused on maintaining airtight code quality for those features. I don't need the vast majority of the features and services offered in today's systemd suite, and I don't want to suffer from the cost that all of those diversions extract on the core functionality. Crib the good parts, keep a high quality bar, and make sure a feature is likely to produce high positive impact before investigating resources in delivering it. Which is, I know, quite a lot to ask.

by castis 7y ago

That's true but what we're hoping for is that Debian doesn't change things so much that sysvinit is unusable. Systemd does have its advantages but some people _like_ sysvinit.

shawnz 7y ago

> but some people _like_ sysvinit Is that really true, or is it just that some people have a grudge against systemd and sysvinit is the only other practical option?

johnr2 7y ago
>> but some people _like_ sysvinit > Is that really true Yes
- IntelMiner 7y ago
  Forgive me if it sounds like I'm trying to bait into an argument, but Why? What is the appeal of writing immensely long, fragile shell scripts? Having to wrap them in various monitoring and logging daemons Having to have different ones for every distro you want to support with your software Is this something that is truly a productive use of your time? Putting aside the question of if systemd is "good" or not. Is the current sysvinit system truly "good enough" and not in need of change?
  - yjftsjthsd-h 7y ago
    > Is the current sysvinit system truly "good enough" and not in need of change? Something having been used for decades certainly doesn't mean that it's optimal and shouldn't be changed, but it does strongly suggest that it's good enough.
  - johnr2 7y ago
    > Is the current sysvinit system truly "good enough" and not in need of change? For me it's relative and a case of "the devil I know". I actually prefer BSD-style init to sysvinit, but I've used the latter for ~20 years. I'm aware that traditional init systems may not meet the requirements of certain users (eg. those who run very large server installations), but for my simple use case (small servers and workstations) they do the job. I'm not against change per se; I'm running Void (with runit) on one of my systems, and the desktop I'm using to post this runs OpenBSD.
madhadron 7y ago
Stockholm syndrome is a thing.
krzyk 7y ago
sysvinit is simple, and I didn't have any major issues with it. On the other hand, systemd is too big, takes on too much responsibility (really I need a system to retrieve logs in it? or a way to run local dns?). Since last update on my ubuntu desktop I can't get dns to work from DHCP, I need to overwrite /etc/resolv.conf with correct nameservers after each restart (BTW. Why would anyone think that running local DNS is a good default option - I see `nameserver 127.0.0.1` in the overwritten file). And the second one on Debian on my laptop, when I run VPN (openconnect) name resolution fails, and I need again - ovewrite resolv.conf. I didn't have such problems with sysvinit. systemd is so controversial that I'm astonished why it is used in any distro.
- ernst_klim 7y ago
  > sysvinit is simple, and I didn't have any major issues with it. How do you encode service dependencies? If a service dies, what happens to services relying on it on your system?
  - csande17 7y ago
    At least on my desktop machine, there aren't a whole lot of services that directly depend on other services. Usually, a service will provide some functionality (e.g. sound) used by applications I launch. As far as I know, systemd doesn't help with that, and I don't really want it to--imagine if systemd suddenly killed and restarted your browser! Also, maybe I'm just lucky (or using popular hardware, or something), but services on my machine don't just randomly die for no reason. NetworkManager, sshd, etc all seem pretty well-written and stable.
    - ernst_klim 7y ago
      >As far as I know, systemd doesn't help with that It depends on the service in use and how is it defined. I have an embedded system in production, which have quite a complex graph of dependencies, some of which should be restarted on sudden death of others, some of which should persist anyways. Needless to say that systemd provides an incredible, robust and easy way of solving that, I had to write just a few 10-line long unit files for in-house software and use standard units provided by standard daemons. >imagine if systemd suddenly killed and restarted your browser Because your browsed doesn't rely on them. But my web interface definitely depends on NetworkManager, because it speaks to it via d-bus.
cthalupa 7y ago
>Is that really true, or is it just that some people have a grudge against systemd and sysvinit is the only other practical option? Well, considering quite a few distros had already replaced sysvinit with upstart prior to systemd, obviously we have multiple options besides sysvinit. There's also options such as openrc, which will let you make use of whatever you want for pid 1, and manage services elsewhere. In general, whether or not replacing systemd with something besides sysvinit/upstart is a practical option depends on how reliant you are on packages provided by an upstream distro or 3rd party. It isn't particularly hard to just swap init systems on several distros - debian included - but there are varying levels of tie-in with provided packages. If you're building all of your required packages with a CI/CD pipeline and deploying with containers based on a minimal linux distro, you could relatively easily use a myriad of systemd and sysvinit alternatives. If you're just deploying on RHEL or Ubuntu VMs and doing yum/apt install to get your software, it's relatively more difficult. Personally, I think sysvinit needs to be relegated to the annals of history. But I also have been bitten in production many times by systemd bugs, which due to the more... integrated... nature of systemd and it's components have been more trying to troubleshoot and have resulted in longer periods of problematic behavior, increased system level outages, and other headaches. Back when I worked with Solaris, I loved SMF - not so much the XML portion of it, but it worked well, was leaps and bounds ahead of sysvinit in usability in features, and didn't manage to induce nearly as many problems in my production environments as systemd has. And this isn't the first project I've wasted hundreds of hours of my life troubleshooting from the key systemd maintainers. My general experience with their projects has left the impression that they are not nearly as concerned at making their software bug-free as they are chasing features and use cases that interest them. Which is fine - they're welcome to write whatever software they want and prioritize things however they want. My hope is that some other init system which recognizes the fact that it's no longer the 80s receives traction. Init scripts are awful, and no one should be writing them in this day and age, but I would prefer a system that only has a subset of systemd features but is instead focused on maintaining airtight code quality for those features. I don't need the vast majority of the features and services offered in today's systemd suite, and I don't want to suffer from the cost that all of those diversions extract on the core functionality. Crib the good parts, keep a high quality bar, and make sure a feature is likely to produce high positive impact before investigating resources in delivering it. Which is, I know, quite a lot to ask.