5 ms·

I don't think anyone has ever dropped a distro because it wasn't using systemd, just like I don't think anyone ever moved to Ubuntu from a sysvinit system just

I don't think anyone has ever dropped a distro because it wasn't using systemd, just like I don't think anyone ever moved to Ubuntu from a sysvinit system just because Ubuntu had upstart. I don't think there was ever a "fight" - they simply wanted to use systemd, and so they did. If Slackware ever moves to systemd, it will be a sad day, but i'll keep using Slack because it's the whole distro that I want, not just how the system initializes services. If I could deal with Windows's bullshit, I can deal with systemd. Just like ConsoleKit, and PolicyKit, and NetworkManager, and UPower, and PulseAudio, and HAL, and UDev, and DBus, and all the other annoying crap that's been shoved down our throats over the years. Now I know how old people feel when they talk about modern cars...

mgbmtl 10y ago
> "I don't think anyone has ever dropped a distro because it wasn't using systemd" That's an odd assumption. I have. I'm a big fan of standardisation. I understand some people not liking systemd, but there are a lot of folks out there who really prefer it. Once I started adopting it, I no longer needed/wanted to support cross-distro start scripts, since systemd does that. So non-systemd distros were dropped.
- milesrout 10y ago
  systemd isn't a standard, it's a monoculture. There's a difference.
  - afarrell 10y ago
    Id be interested to hear what the difference is. By moniculture, are you saying that adopting systemd leaves you vulnerable to cross-distro vulnerabilities hitting a bunch of systems all at once? (Most of my knowledge on the downsides of monoculture come from Irish history) Or are you pointing to something else?
    - peterwwillis 10y ago
      It's a standard in the sense that Service Control Manager is a standard. But it's a monoculture in the sense that writing your application for Service Control Manager means it will only ever work on Windows NT-derived operating systems. That's not a good standard for an operating system supposedly about flexibility, compatibility, and choice. And it's even more annoying for software which isn't intended to be run in a monoculture, like most of the open source/free software world.
      - roblabla 10y ago
        To be fair, how hard can it be to port your app from one init system to the other ? And for that matter, did anyone make a systemd-to-sysv converter ? Because that should surely be possible, systemd service files being declarative. If such a converter did exist, then suddenly, the systemd "service files" could become an actual standard, since they'd be (somewhat) compatible accross sysv and systemd. And maybe we could work from there and support other init systems...
        peterwwillis 10y ago
        Making a service file is only a small part of the systemd monoculture. People don't care about the init system as much as how it hijacks the entire OS and shuts out alternative Linux systems. Your suggestion of turning systemd's APIs and formats into a standard is not out of the question, but it would never happen. Poettering and his team showed they have zero interest in making a compatible system, or in making any concessions at all. Standards have to do both. And other platforms have to buy into the standard, otherwise it just sits there like a third leg. The way it would probably end up is a project like Alien would adopt some of systemd's quirks. But so much of systemd is tied directly into the application via APIs that it would be a huge PITA to support both systemd and anything else - hence why some devs simply drop support for anything that isn't systemd. It's the same sort of thing that causes devs to only develop for Windows, or iOS/OSX, because it's more popular and porting to Linux is too expensive.
        10y ago
  - deleted 10y ago
    [deleted]
- peterwwillis 10y ago
  Most distros have different package managers, different flavors of compiled and packaged software, different libraries, different system management tools, and different kernel versions. Yet you switched distributions because of the two whole different methods of start-up scripts. The one thing that only has to be written once, and then forgotten about forever.
  - mintplant 10y ago
    Messing with sysvinit scripts is just that painful.
    - tomc1985 10y ago
      I still don't understand how sysv scripts can be so long and hard-to-read for such a simple task.
  - rtpg 10y ago
    Isn't this the point though? We're moving more and more to having unified low-level services across Unices, so it stops being about stupid things like "Oh sorry, Arch can't run this because it uses its own audio stack even if we're just using audio to make a notification sound", and starts being about the things that are fundamentally different about the systems. Think about how nice it is that we don't have to recompile most things for most kernel versions. Why do we have to set up multiple startup script mechanisms?
    - peterwwillis 10y ago
      > Think about how nice it is that we don't have to recompile most things for most kernel versions. Yes, nobody has ever had to recompile their application to work on a new kernel. If you mean that's nice that there's binary backwards compatibility, I agree. I don't see what this has to do with supporting multiple systems. > Why do we have to set up multiple startup script mechanisms? Why do we have to support multiple <insert any kind of software> ? > We're moving more and more to having unified low-level services across Unices AFAIK, the only thing I know of moving toward middleware unification specifically is Linux desktop software. Choosing to use systemd in exclusion of everything else is "unification" in the same way that nationalism/xenophobia/homophobia are. (i'm aware of how mean that sounds, but it's the closest comparison I can think of) It is certainly nice that there is now middleware that abstracts the underlying software that controls the hardware, for example, or that authentication and authorization are more uncoupled. But this is really almost the opposite of what systemd does.
vacri 10y ago
Systemd does more than init - it keeps popping up its head all over the place, such as for login or timekeeping. After all, it's 'systemd', not 'initd'...
- qznc 10y ago
  Instead of "Linux", you say "GNU/systemd/Linux" from now on.
tie_ 10y ago
I don't believe people would have dropped Ubuntu (in general) for not using systemd (but I'd not bet on the word anyone). My point was that Ubuntu went with the fold even if people would not have dropped them for sticking to their own system. The benefits of that unification are very, very tangible for package authors/maintainers - they now have to write just one flavor of a service file. And that is a great thing(tm) for the Linux community as a whole - well worth my own gripes with systemd itself.

mgbmtl 10y ago

> "I don't think anyone has ever dropped a distro because it wasn't using systemd" That's an odd assumption. I have. I'm a big fan of standardisation. I understand some people not liking systemd, but there are a lot of folks out there who really prefer it. Once I started adopting it, I no longer needed/wanted to support cross-distro start scripts, since systemd does that. So non-systemd distros were dropped.

milesrout 10y ago
systemd isn't a standard, it's a monoculture. There's a difference.
- afarrell 10y ago
  Id be interested to hear what the difference is. By moniculture, are you saying that adopting systemd leaves you vulnerable to cross-distro vulnerabilities hitting a bunch of systems all at once? (Most of my knowledge on the downsides of monoculture come from Irish history) Or are you pointing to something else?
  - peterwwillis 10y ago
    It's a standard in the sense that Service Control Manager is a standard. But it's a monoculture in the sense that writing your application for Service Control Manager means it will only ever work on Windows NT-derived operating systems. That's not a good standard for an operating system supposedly about flexibility, compatibility, and choice. And it's even more annoying for software which isn't intended to be run in a monoculture, like most of the open source/free software world.
    - roblabla 10y ago
      To be fair, how hard can it be to port your app from one init system to the other ? And for that matter, did anyone make a systemd-to-sysv converter ? Because that should surely be possible, systemd service files being declarative. If such a converter did exist, then suddenly, the systemd "service files" could become an actual standard, since they'd be (somewhat) compatible accross sysv and systemd. And maybe we could work from there and support other init systems...
      - peterwwillis 10y ago
        Making a service file is only a small part of the systemd monoculture. People don't care about the init system as much as how it hijacks the entire OS and shuts out alternative Linux systems. Your suggestion of turning systemd's APIs and formats into a standard is not out of the question, but it would never happen. Poettering and his team showed they have zero interest in making a compatible system, or in making any concessions at all. Standards have to do both. And other platforms have to buy into the standard, otherwise it just sits there like a third leg. The way it would probably end up is a project like Alien would adopt some of systemd's quirks. But so much of systemd is tied directly into the application via APIs that it would be a huge PITA to support both systemd and anything else - hence why some devs simply drop support for anything that isn't systemd. It's the same sort of thing that causes devs to only develop for Windows, or iOS/OSX, because it's more popular and porting to Linux is too expensive.
        10y ago
- deleted 10y ago
  [deleted]
peterwwillis 10y ago
Most distros have different package managers, different flavors of compiled and packaged software, different libraries, different system management tools, and different kernel versions. Yet you switched distributions because of the two whole different methods of start-up scripts. The one thing that only has to be written once, and then forgotten about forever.
- mintplant 10y ago
  Messing with sysvinit scripts is just that painful.
  - tomc1985 10y ago
    I still don't understand how sysv scripts can be so long and hard-to-read for such a simple task.
- rtpg 10y ago
  Isn't this the point though? We're moving more and more to having unified low-level services across Unices, so it stops being about stupid things like "Oh sorry, Arch can't run this because it uses its own audio stack even if we're just using audio to make a notification sound", and starts being about the things that are fundamentally different about the systems. Think about how nice it is that we don't have to recompile most things for most kernel versions. Why do we have to set up multiple startup script mechanisms?
  - peterwwillis 10y ago
    > Think about how nice it is that we don't have to recompile most things for most kernel versions. Yes, nobody has ever had to recompile their application to work on a new kernel. If you mean that's nice that there's binary backwards compatibility, I agree. I don't see what this has to do with supporting multiple systems. > Why do we have to set up multiple startup script mechanisms? Why do we have to support multiple <insert any kind of software> ? > We're moving more and more to having unified low-level services across Unices AFAIK, the only thing I know of moving toward middleware unification specifically is Linux desktop software. Choosing to use systemd in exclusion of everything else is "unification" in the same way that nationalism/xenophobia/homophobia are. (i'm aware of how mean that sounds, but it's the closest comparison I can think of) It is certainly nice that there is now middleware that abstracts the underlying software that controls the hardware, for example, or that authentication and authorization are more uncoupled. But this is really almost the opposite of what systemd does.

vacri 10y ago

Systemd does more than init - it keeps popping up its head all over the place, such as for login or timekeeping. After all, it's 'systemd', not 'initd'...

qznc 10y ago
Instead of "Linux", you say "GNU/systemd/Linux" from now on.

tie_ 10y ago

I don't believe people would have dropped Ubuntu (in general) for not using systemd (but I'd not bet on the word anyone). My point was that Ubuntu went with the fold even if people would not have dropped them for sticking to their own system. The benefits of that unification are very, very tangible for package authors/maintainers - they now have to write just one flavor of a service file. And that is a great thing(tm) for the Linux community as a whole - well worth my own gripes with systemd itself.