3 ms·

A lot of init problems you describe are very real, but it felt like by the late 00s they had mostly been solved with efforts like linting and standards, as well

A lot of init problems you describe are very real, but it felt like by the late 00s they had mostly been solved with efforts like linting and standards, as well as LSB init shell functions making init a much more standardized process. PAM was and still is quite hard to understand but, again, it had enough power and flexibility with @ based includes to allow individual distributions to lay things out sensibly and allow new packages to follow a coherent standard that emerged rather than being forced. Concurrent init systems helped drive a lot of this, back when there was a sweet spot of Linux complexity increasing faster than processing power could handle. (Nowadays I feel like boot speed is less important, given how many more resources a modern machine has, though it’s still a concern for low resource platforms.) I guess I’ve just never seen revolution as a solution to hacks and untidiness. Linting, guidelines and policy, with technically compelling reasons to encourage people to follow them have seen much more success, where I’ve seen them deployed, than centralized authority.

Conan_Kudo 7y ago
> A lot of init problems you describe are very real, but it felt like by the late 00s they had mostly been solved with efforts like linting and standards, as well as LSB init shell functions making init a much more standardized process. These improvements weren't real. There was a long tail of scripts that didn't follow the standard and never would. Every distribution still had their own customizations on how sysvinit scripts worked (e.g. debian with start-stop-daemon, suse with insserv, etc.) And rc was different on almost every major distro family, which made life even more difficult for no particularly good reason. And there's a certain point where all these things you are doing are ultimately to paper over the "hacks and untidiness" of everything. The introduction of systemd had two major effects: 1. It broke all non-LSB init scripts (because LSB is all it supported) 2. It introduced a straightforward declarative syntax for system resources (units for services, timers, mounts, etc.) I would argue that the above two things have done more to standardize the Linux plumbing layer and help people take fuller advantage of it than literally all the linting, guidelines, and policywork we did for the decade prior.
- dTal 7y ago
  And if that's all it did, we wouldn't be having this discussion. Instead it is becoming some sort of self-appointed "userland middleware", which nobody asked for. People resent "better init" turning into "henceforth home directories will behave differently".
  - lorenzhs 7y ago
    That's a dishonest argument and you know it. The entire home directories thing is aimed at enterprises, and nobody wants to enable it for individuals' machines. Poettering said as much in the talk where he presented it. It would be much more reasonable to respond to people who dislike systemd if they wouldn't constantly make bad-faith dishonest claims about it.
    - dTal 7y ago
      The question remains, what do home directories have to do with init, at all? Okay so Poettering wants to "fix" home directories - is there any reason to couple that with systemd, beyond the fact that systemd is his baby (and point of leverage over the rest of the system)? There are dozens of other examples - network configuration? syslog? cron? This is what I mean by 'OS middleware' - systemd is basically a distro, and a radical one at that. It is aiming to replace huge swathes of stuff that no one except seemingly Poettering believes is broken in the first place. I think distros would have been more hesitant to adopt systemd as an "init system" if this roadmap had been clear upfront. <conspiracy> I have heard the opinion ventured that systemd is actually a power play by Red Hat to introduce an API layer between userland and the kernel - one controlled by Red Hat. It's not implausible - as Red Hat is funded by selling consultancy services, they have a financial incentive to convert as much of Linux as possible into Red Hat Linux. </conspiracy>
      - majewsky 7y ago
        That's one shitty conspiracy. If this were Red Hat's play, why would they do it with a project that other distros can adopt and have adopted? If anything, providing APIs in systemd makes it easier to migrate to other distros as long as they use systemd. (All relevant enterprise distributions use systemd, i.e. RHEL and SLES and Ubuntu Server.)

Conan_Kudo 7y ago

> A lot of init problems you describe are very real, but it felt like by the late 00s they had mostly been solved with efforts like linting and standards, as well as LSB init shell functions making init a much more standardized process. These improvements weren't real. There was a long tail of scripts that didn't follow the standard and never would. Every distribution still had their own customizations on how sysvinit scripts worked (e.g. debian with start-stop-daemon, suse with insserv, etc.) And rc was different on almost every major distro family, which made life even more difficult for no particularly good reason. And there's a certain point where all these things you are doing are ultimately to paper over the "hacks and untidiness" of everything. The introduction of systemd had two major effects: 1. It broke all non-LSB init scripts (because LSB is all it supported) 2. It introduced a straightforward declarative syntax for system resources (units for services, timers, mounts, etc.) I would argue that the above two things have done more to standardize the Linux plumbing layer and help people take fuller advantage of it than literally all the linting, guidelines, and policywork we did for the decade prior.

dTal 7y ago
And if that's all it did, we wouldn't be having this discussion. Instead it is becoming some sort of self-appointed "userland middleware", which nobody asked for. People resent "better init" turning into "henceforth home directories will behave differently".
- lorenzhs 7y ago
  That's a dishonest argument and you know it. The entire home directories thing is aimed at enterprises, and nobody wants to enable it for individuals' machines. Poettering said as much in the talk where he presented it. It would be much more reasonable to respond to people who dislike systemd if they wouldn't constantly make bad-faith dishonest claims about it.
  - dTal 7y ago
    The question remains, what do home directories have to do with init, at all? Okay so Poettering wants to "fix" home directories - is there any reason to couple that with systemd, beyond the fact that systemd is his baby (and point of leverage over the rest of the system)? There are dozens of other examples - network configuration? syslog? cron? This is what I mean by 'OS middleware' - systemd is basically a distro, and a radical one at that. It is aiming to replace huge swathes of stuff that no one except seemingly Poettering believes is broken in the first place. I think distros would have been more hesitant to adopt systemd as an "init system" if this roadmap had been clear upfront. <conspiracy> I have heard the opinion ventured that systemd is actually a power play by Red Hat to introduce an API layer between userland and the kernel - one controlled by Red Hat. It's not implausible - as Red Hat is funded by selling consultancy services, they have a financial incentive to convert as much of Linux as possible into Red Hat Linux. </conspiracy>
    - majewsky 7y ago
      That's one shitty conspiracy. If this were Red Hat's play, why would they do it with a project that other distros can adopt and have adopted? If anything, providing APIs in systemd makes it easier to migrate to other distros as long as they use systemd. (All relevant enterprise distributions use systemd, i.e. RHEL and SLES and Ubuntu Server.)