9 ms·

That's not quite right in this case. Systemd and gnome3 were cases where the new 'version' did not need full feature parity. Both those projects were written on

by gcb0 8y ago

That's not quite right in this case. Systemd and gnome3 were cases where the new 'version' did not need full feature parity. Both those projects were written on leisure time, with no pressure for deadline or feature. and still adopted from top down. i guess some projects forget the benevolent part of benevolent dictator for life. systemd arguments were just "boot faster" and "it's newer". Everyone knew it was going to be broken, buggy, lacking features. As those were never actual goals. In fact, the goals had features never intended for init. So we could say they were rushing for feature anti-parity. https://www.tecmint.com/systemd-replaces-init-in-linux/ https://www.tecmint.com/systemd-replaces-init-in-linux/ see the table at the end. All the features systemd have show "no" for init. And "verbose debug", something you would consider very essential on a piece of software responsible for making your machine something broken and unusable, just show "no" for systemd, and nobody ever cared, because: boot faster (or so they say) systemd is a mistake. But i guess now it is a permanent mistake.

mikekchar 8y ago
You're getting down voted mainly because you are wrong. I'm actually not well versed in this, so hopefully somebody will correct my wrong version -- but at least I think it will steer you in the right direction ;-) Systemd solves real problems that have to do with virtualisation and/or containerisation. Red Hat is the company that wrote Systemd and they did it for commercial reasons (i.e. they needed these facilities in order to fulfil contracts with paying customers). Red Hat contributes greatly to Gnome. I haven't checked, but I believe they are far and away the biggest contributor. They have financial reasons for doing so, but I don't really understand what they are. The connection between Systemd and Gnome is real, but not quite what you think. Systemd does make some stuff in Gnome easier to do, but it isn't really necessary at all. Systemd was not developed for Gnome -- it was adopted by Gnome. It's a bit of a dog food problem. Most Gnome developers (i.e. Red Hat developers) have a vested interest in Systemd being successful. They want to make sure they are using it where they can. They saw no particular reason to make Gnome 3 compatible with any other init system because: 1. It would be more work and why should they pay for work that isn't in their interest 2. They want more people to adopt Systemd because that puts Red Hat in a good position to sell more contracts. It's totally understandable and not really underhanded. I personally hate it with a passion, but things I hate are not always evil :-)
- thwarted 8y ago
  Systemd solves real problems that have to do with virtualisation and/or containerisation. systemd predates the industry love affair with containerization and virtualization for workload management, although work on containerization within systemd may have helped increase awareness of containerization's value. I don't remember early reasons to use systemd mentioning either; the rationales trotted out in favor of systemd in its early days were reducing boot time and replacing shell scripts used during boot, shell scripts labeled things like "old" and "fragile", despite multiple decades of shell scripts being successfully used to reliably manage the boot process on open source and proprietary Unixes, alike.
  - beagle3 8y ago
    systemd does not predate the industry's love affair. According to wikipedia, the initial release was in March 2010. The industry started courting virtualization (as it is practiced today) with the appearance of EC2, in August 2006, and the love affair came shortly afterwards. "Reducing boot time" is of great importance for short-lived containers - if it takes 60 seconds to boot a server, and you only run it for 120 seconds, then you have 50% overhead. If it takes 6 seconds, you're down to 5% overhead; If it takes 150ms (e.g. Intel Clear Container project), it's completely negligible. Those scripts, are, in fact, old and fragile, and while they did manage the boot process, "reliable" is a stretch. I've personally filed 2 bugs against the horrible hodge-podge of isc-dhcp that, in rare occasions, randomly failed (which is a bit of a problem if your DHCPd box is unattended and a few hours drive). Through the years, many systems much better than init scripts have been proposed and implemented - personally I like the daemontools family, which I think is inherently better thought out. although it definitely helped to have red hat backing, systemd won on for technical reasons: it's much better than the init scripts; it's not inferior to any other system; and it comes with simple integration with network/resolvers/etc (by virtue of including those services) -- something that saves distributions a lot of work integrating various parts.
    - amaccuish 8y ago
      > "Reducing boot time" is of great importance for short-lived containers Containers don't tend to run an init.
LukeShu 8y ago
I want to expand on mikekchar's "You're getting down voted mainly because you are wrong." systemd has been adopted by many different distros, however this is not because of "top down" pressure (From who, Red Hat? Most distros don't answer to Red Hat), and most of them don't have a (B)DFL who could have imposed that decision on them. There are many arguments for systemd other than "boot faster" and "it's newer". In fact, the author of the article this is a thread for has written a pretty good list of them: https://utcc.utoronto.ca/~cks/space/blog/linux/SystemdRight https://utcc.utoronto.ca/~cks/space/blog/linux/SystemdRight The article you linked... is bad for very many reasons. In particular, it makes no acknowledgement that what it refers to as "init" (http://www.nongnu.org/sysvinit/ http://www.nongnu.org/sysvinit/) is only really half of an "init system" as the term is commonly used today, and all distros would be pairing it with something else on top of it. The table at the bottom is particularly ridiculous, and I take issue with almost every row; a lot of that comes down to the silliness of comparing systemd to sysvinit-by-itself, rather than sysvinit+initscripts or sysvinit+OpenRC or sysvinit+LSB-init-scripts.
- onli 8y ago
  > systemd has been adopted by many different distros, however this is not because of "top down" pressure (From who, Red Hat? Most distros don't answer to Red Hat), and most of them don't have a (B)DFL who could have imposed that decision on them. Often it was a "matter of fact" thing. If the ecosystem under the distro changes to use systemd distros will follow. There might be more advantages to it, but it being required to run Gnome 3 without additional effort, and in general other servies starting to rely on it, make the decision pro systemd the easy one for distro maintainers. You can see that point being made in the debian discussion on the issue. Till they hit the showstopper bugs and can't solve them.
  - LukeShu 8y ago
    sysvinit is short enough to be trivially maintainable. If you're just using it as a shim to load a framework on top of it, you can ditch even more of it cutting it down to around 500LOC (see openrc-init). So that's not a large enough part of "the ecosystem under the distro". Debian maintained their own init-scripts framework (and still does, for kFreeBSD and other kernels), so that certainly didn't move out from under them. Arch Linux maintained their own initscripts framework, so that wasn't moving out from under them. I suppose there is a case to be made that distros were pushed to systemd by Gnome 3's reliance on systemd-logind's D-Bus API.

by gcb0 8y ago

mikekchar 8y ago

You're getting down voted mainly because you are wrong. I'm actually not well versed in this, so hopefully somebody will correct my wrong version -- but at least I think it will steer you in the right direction ;-) Systemd solves real problems that have to do with virtualisation and/or containerisation. Red Hat is the company that wrote Systemd and they did it for commercial reasons (i.e. they needed these facilities in order to fulfil contracts with paying customers). Red Hat contributes greatly to Gnome. I haven't checked, but I believe they are far and away the biggest contributor. They have financial reasons for doing so, but I don't really understand what they are. The connection between Systemd and Gnome is real, but not quite what you think. Systemd does make some stuff in Gnome easier to do, but it isn't really necessary at all. Systemd was not developed for Gnome -- it was adopted by Gnome. It's a bit of a dog food problem. Most Gnome developers (i.e. Red Hat developers) have a vested interest in Systemd being successful. They want to make sure they are using it where they can. They saw no particular reason to make Gnome 3 compatible with any other init system because: 1. It would be more work and why should they pay for work that isn't in their interest 2. They want more people to adopt Systemd because that puts Red Hat in a good position to sell more contracts. It's totally understandable and not really underhanded. I personally hate it with a passion, but things I hate are not always evil :-)

thwarted 8y ago
Systemd solves real problems that have to do with virtualisation and/or containerisation. systemd predates the industry love affair with containerization and virtualization for workload management, although work on containerization within systemd may have helped increase awareness of containerization's value. I don't remember early reasons to use systemd mentioning either; the rationales trotted out in favor of systemd in its early days were reducing boot time and replacing shell scripts used during boot, shell scripts labeled things like "old" and "fragile", despite multiple decades of shell scripts being successfully used to reliably manage the boot process on open source and proprietary Unixes, alike.
- beagle3 8y ago
  systemd does not predate the industry's love affair. According to wikipedia, the initial release was in March 2010. The industry started courting virtualization (as it is practiced today) with the appearance of EC2, in August 2006, and the love affair came shortly afterwards. "Reducing boot time" is of great importance for short-lived containers - if it takes 60 seconds to boot a server, and you only run it for 120 seconds, then you have 50% overhead. If it takes 6 seconds, you're down to 5% overhead; If it takes 150ms (e.g. Intel Clear Container project), it's completely negligible. Those scripts, are, in fact, old and fragile, and while they did manage the boot process, "reliable" is a stretch. I've personally filed 2 bugs against the horrible hodge-podge of isc-dhcp that, in rare occasions, randomly failed (which is a bit of a problem if your DHCPd box is unattended and a few hours drive). Through the years, many systems much better than init scripts have been proposed and implemented - personally I like the daemontools family, which I think is inherently better thought out. although it definitely helped to have red hat backing, systemd won on for technical reasons: it's much better than the init scripts; it's not inferior to any other system; and it comes with simple integration with network/resolvers/etc (by virtue of including those services) -- something that saves distributions a lot of work integrating various parts.
  - amaccuish 8y ago
    > "Reducing boot time" is of great importance for short-lived containers Containers don't tend to run an init.

LukeShu 8y ago

I want to expand on mikekchar's "You're getting down voted mainly because you are wrong." systemd has been adopted by many different distros, however this is not because of "top down" pressure (From who, Red Hat? Most distros don't answer to Red Hat), and most of them don't have a (B)DFL who could have imposed that decision on them. There are many arguments for systemd other than "boot faster" and "it's newer". In fact, the author of the article this is a thread for has written a pretty good list of them: https://utcc.utoronto.ca/~cks/space/blog/linux/SystemdRight https://utcc.utoronto.ca/~cks/space/blog/linux/SystemdRight The article you linked... is bad for very many reasons. In particular, it makes no acknowledgement that what it refers to as "init" (http://www.nongnu.org/sysvinit/ http://www.nongnu.org/sysvinit/) is only really half of an "init system" as the term is commonly used today, and all distros would be pairing it with something else on top of it. The table at the bottom is particularly ridiculous, and I take issue with almost every row; a lot of that comes down to the silliness of comparing systemd to sysvinit-by-itself, rather than sysvinit+initscripts or sysvinit+OpenRC or sysvinit+LSB-init-scripts.

onli 8y ago
> systemd has been adopted by many different distros, however this is not because of "top down" pressure (From who, Red Hat? Most distros don't answer to Red Hat), and most of them don't have a (B)DFL who could have imposed that decision on them. Often it was a "matter of fact" thing. If the ecosystem under the distro changes to use systemd distros will follow. There might be more advantages to it, but it being required to run Gnome 3 without additional effort, and in general other servies starting to rely on it, make the decision pro systemd the easy one for distro maintainers. You can see that point being made in the debian discussion on the issue. Till they hit the showstopper bugs and can't solve them.
- LukeShu 8y ago
  sysvinit is short enough to be trivially maintainable. If you're just using it as a shim to load a framework on top of it, you can ditch even more of it cutting it down to around 500LOC (see openrc-init). So that's not a large enough part of "the ecosystem under the distro". Debian maintained their own init-scripts framework (and still does, for kFreeBSD and other kernels), so that certainly didn't move out from under them. Arch Linux maintained their own initscripts framework, so that wasn't moving out from under them. I suppose there is a case to be made that distros were pushed to systemd by Gnome 3's reliance on systemd-logind's D-Bus API.