3 ms·

> I don't think that's the case. Systemd was introduced with a SysV init backwards compatibility mode, so it was trivial to port services over to using it. Port

by growse 6y ago

> I don't think that's the case. Systemd was introduced with a SysV init backwards compatibility mode, so it was trivial to port services over to using it. Porting a systemd-only service over to SysV init is much harder, though. (I meant before systemd/upstart existed). Is it harder because systemd supports more features than sysv? What's stopping someone writing a new init / service manager that's systemd-compatible? Or improving sysv so that it supports those features? > Software freedom is not a binary matter (excuse the pun)... Of course there's nuance, and you're right to point out that different corners of the open source world have different values and disagree on things (BSD/GNU etc). But the point is that the users are in control and that the power lies with the users. If systemd was bad, or actively useless, people would stop using redhat, Debian, etc. As proof that the overall model works, there are distributions out there that shun or provide non-systemd options. People can use and contribute to those! I also don't agree that anything is a "one way process". Everything is temporary. We'll use systemd until something better comes along, just like we did with perl, apache, Hadoop, or any technology that was the de facto canonical way of doing things right up until the point that there were better options. I remember the history too - systemd would have gotten zero traction anywhere if it wasn't actually solving real problems. Sure, there were some pretty major bugs, and I wish Debian had done it right, but that doesn't take away from the recognition that there was a problem to solve and this was our best stab at solving it. I guess I just don't understand the energy poured into hyperbole like "world domination" and "stranglehold". If you want to convince me that something I find useful every single day is bad, then build something better.

dane-pgp 6y ago
> (I meant before systemd/upstart existed). I still don't think we were "locked into shell scripts" though. Even if shell scripts were the only thing that existed, it was still possible for someone to make a service manager which supported something else, with a backwards compatibility mode for shell scripts. > What's stopping someone writing a new init / service manager that's systemd-compatible? My understanding is that systemd deliberately makes it hard to independently reimplement certain critical components like logind and journald. In practice, no distro is going to go to the trouble of packaging and supporting a mixture of components from the "official" systemd set and other competing implementations, even if those competing implementations were easier to use, or faster, or more secure, or more portable. Compare this to the situation where system services were not so tightly coupled and it was possible for distros to change their default ntpd, for example. Just as monopolies in industries prevent new innovative start-ups from emerging, a monoculture in Linux system services prevents people from even trying new approaches. > As proof that the overall model works, there are distributions out there that shun or provide non-systemd options. I can't help being reminded of the (in)famous scene of a Microsoft lawyer holding up a boxed copy of Red Hat as a defence against the claim that they were abusing their monopoly[0]. Alternatively, it's like an authoritarian dictatorship pointing to the existence of nominal opposition parties to show that its citizens are free. My point is, I think you're missing some of the power dynamics here, in particular the fact that people don't want to completely reinstall their operating system just to avoid the problems of systemd. Indeed, most users wouldn't even know that systemd is the cause of their problems, especially when the problem is something nebulous like a lack of innovation and competition in the system services space. To put it more simply: Just because lots of people don't switch away from Windows (or Facebook for example) doesn't mean that they are happy with it. > systemd would have gotten zero traction anywhere if it wasn't actually solving real problems. It might have solved a few people's real problems, but I think that GNOME suddenly making it a hard requirement probably mattered to more people. > If you want to convince me that something I find useful every single day is bad, then build something better. If you find it useful every day then I'm happy for you. However, I don't think I have to convince you of anything. I'm not trying to make it harder for you to use systemd, whereas systemd is making it harder for people to use other inits, including SysV init which has been working fine for them for decades. The onus should be on the ones doing the coercion, to convince the people whose choices they are reducing, not the other way around. [0] https://archive.is/eMmMB https://archive.is/eMmMB / https://www.washingtonpost.com/wp-srv/business/longterm/microsoft/stories/1999/linux012199.htm https://www.washingtonpost.com/wp-srv/business/longterm/micr...

by growse 6y ago

dane-pgp 6y ago

> (I meant before systemd/upstart existed). I still don't think we were "locked into shell scripts" though. Even if shell scripts were the only thing that existed, it was still possible for someone to make a service manager which supported something else, with a backwards compatibility mode for shell scripts. > What's stopping someone writing a new init / service manager that's systemd-compatible? My understanding is that systemd deliberately makes it hard to independently reimplement certain critical components like logind and journald. In practice, no distro is going to go to the trouble of packaging and supporting a mixture of components from the "official" systemd set and other competing implementations, even if those competing implementations were easier to use, or faster, or more secure, or more portable. Compare this to the situation where system services were not so tightly coupled and it was possible for distros to change their default ntpd, for example. Just as monopolies in industries prevent new innovative start-ups from emerging, a monoculture in Linux system services prevents people from even trying new approaches. > As proof that the overall model works, there are distributions out there that shun or provide non-systemd options. I can't help being reminded of the (in)famous scene of a Microsoft lawyer holding up a boxed copy of Red Hat as a defence against the claim that they were abusing their monopoly[0]. Alternatively, it's like an authoritarian dictatorship pointing to the existence of nominal opposition parties to show that its citizens are free. My point is, I think you're missing some of the power dynamics here, in particular the fact that people don't want to completely reinstall their operating system just to avoid the problems of systemd. Indeed, most users wouldn't even know that systemd is the cause of their problems, especially when the problem is something nebulous like a lack of innovation and competition in the system services space. To put it more simply: Just because lots of people don't switch away from Windows (or Facebook for example) doesn't mean that they are happy with it. > systemd would have gotten zero traction anywhere if it wasn't actually solving real problems. It might have solved a few people's real problems, but I think that GNOME suddenly making it a hard requirement probably mattered to more people. > If you want to convince me that something I find useful every single day is bad, then build something better. If you find it useful every day then I'm happy for you. However, I don't think I have to convince you of anything. I'm not trying to make it harder for you to use systemd, whereas systemd is making it harder for people to use other inits, including SysV init which has been working fine for them for decades. The onus should be on the ones doing the coercion, to convince the people whose choices they are reducing, not the other way around. [0] https://archive.is/eMmMB https://archive.is/eMmMB / https://www.washingtonpost.com/wp-srv/business/longterm/microsoft/stories/1999/linux012199.htm https://www.washingtonpost.com/wp-srv/business/longterm/micr...