4 ms·

We were all "locked into" shell scripts for service management not so long ago. Either open source and software freedom affords us endless amounts of choice an

• dane-pgp 6y ago
  > We were all "locked into" shell scripts for service management not so long 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'll be charitable and say that this one-way "interoperability" wasn't deliberate, but it does seem reminiscent of the way some proprietary software supports open standards for importing files but not exporting them. > Either open source and software freedom affords us endless amounts of choice and capability Software freedom is not a binary matter (excuse the pun), and different licences have given people different amounts of freedom in the past. For example, the FSF considered the pre-1999 BSD licence to be non-free simply because it required a sentence to be included in any advertisement of the product[0]. Another example would be "the Dissident test"[1] that Debian applies to licenses, considering them non-free if they require that modifications to the source code be reported back to the original author. I think that when trying to determine the freeness of a piece of software, we have to consider the second-order effects it has on the free software ecosystem generally. If the adoption of a (hypothetical) piece of nominally free software caused other unrelated pieces of software to run artificially slower, or become insecure, or to no longer be developed, then that could be a net loss to the free software community, even if the new software has some shiny new features. > It's got large adoption, because it's actually useful. That's a rather self-serving interpretation of events. As another comment in this thread[2] explains, systemd at every stage of its adoption was made hard to avoid, and adopting it was made a one-way process. I also gave a more thorough analysis in a comment on another thread a couple of years ago[3], but it seems that the myths about systemd's path to world domination are becoming more and more accepted as people forget the actual history. [0] https://www.gnu.org/licenses/bsd.html https://www.gnu.org/licenses/bsd.html [1] https://en.wikipedia.org/wiki/Debian_Free_Software_Guidelines#debian-legal_tests_for_DFSG_compliance https://en.wikipedia.org/wiki/Debian_Free_Software_Guideline... [2] https://news.ycombinator.com/item?id=26647130 https://news.ycombinator.com/item?id=26647130 [3] https://news.ycombinator.com/item?id=18879657 https://news.ycombinator.com/item?id=18879657
  • 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...