5 ms·

I seriously doubt there will be the manpower to keep pushing those projects once the money dries up. They are not intrinsically interesting and their implementa

I seriously doubt there will be the manpower to keep pushing those projects once the money dries up. They are not intrinsically interesting and their implementation leaves a lot to be desired of. There will be yet another huge mess left for the distros to deal with then things will be back to normal in two or three years with everyone remembering why the Unix philosophy is important and that 'this time it isn't different'.

mixmastamyk 7y ago
Am open to improvements but not going back to a shell-script-based boot, thanks.
- JdeBP 7y ago
  The predecessor for systemd on Fedora was upstart, not van Smoorenburg init.
  - mixmastamyk 7y ago
    I liked upstart, but it could stand a few improvements too.
  - loeg 7y ago
    Somewhat briefly, sure. Upstart was used in Fedora, in SysV compatibility mode, from 9 (2008-04)[0] up until 15 (2010-10)[1], or about 2.5 years. Fedora prior to 2008 used classic Redhat runlevel init (what you're calling Smoorenburg). From the first release in 2003, through Fedora 9. So we have 4.5 years of "SysV init" followed by 2.5 years of Upstart in "SysV init" compatibility mode. That said, your comment isn't especially responsive to GP; both Upstart and Systemd in Fedora continued to use a bunch of shell scripts to define startup actions. It wasn't until the systemd unit file conversion efforts[2] around 2012 that Fedora largely moved to services defined as data in "INI"-style configuration files. GP's "shell-script-based boot" is not an unfair way to characterize Fedora's boot process prior to (and including the early history of) systemd in Fedora. [0]: https://fedoraproject.org/wiki/Features/Upstart https://fedoraproject.org/wiki/Features/Upstart [1]: https://fedoraproject.org/wiki/Features/systemd https://fedoraproject.org/wiki/Features/systemd [2]: https://fedoraproject.org/wiki/Features/Systemd-unit-cleanup https://fedoraproject.org/wiki/Features/Systemd-unit-cleanup
    - JdeBP 7y ago
      Miquel van Smoorenburg never worked for Redhat that I know of. It was not a "Redhat init" as you call it. Indeed, it wasn't even init. The things that we are talking about are rc, not init, in the van Smoorenburg system. Nor was there the sort of exclusive "compatibility mode" that you are envisaging in order to make your argument that mixmastamyk was referring to Upstart. Upstart could employ van Smoorenburg rc scripts, but that was not a mode. Upstart was still event-driven with job files. The van Smoorenburg rc scripts were run via what was just another job file. Were your argument valid for Upstart, it would equally be valid for systemd's mechanism for invoking van Smoorenburg rc scripts, and you would have to say that systemd is shell-script-based boot, which really makes a nonsense of mixmastamyk talking about "going back" to it from systemd. Quite clearly, going back to Upstart is not what mixmastamyk was talking about, which not least can be seen from xyr comment written, next to yours, 4 days beforehand.
a1369209993 7y ago
I'd like to believe that, but things like https://www.debian.org/vote/2019/vote_002 https://www.debian.org/vote/2019/vote_002 really aren't encouraging (note the absence of any proposal for actually removing the toxic Big Ball of Mud, and that the top voted proposal is to drop support for any software that works correctly).

mixmastamyk 7y ago

Am open to improvements but not going back to a shell-script-based boot, thanks.

JdeBP 7y ago
The predecessor for systemd on Fedora was upstart, not van Smoorenburg init.
- mixmastamyk 7y ago
  I liked upstart, but it could stand a few improvements too.
- loeg 7y ago
  Somewhat briefly, sure. Upstart was used in Fedora, in SysV compatibility mode, from 9 (2008-04)[0] up until 15 (2010-10)[1], or about 2.5 years. Fedora prior to 2008 used classic Redhat runlevel init (what you're calling Smoorenburg). From the first release in 2003, through Fedora 9. So we have 4.5 years of "SysV init" followed by 2.5 years of Upstart in "SysV init" compatibility mode. That said, your comment isn't especially responsive to GP; both Upstart and Systemd in Fedora continued to use a bunch of shell scripts to define startup actions. It wasn't until the systemd unit file conversion efforts[2] around 2012 that Fedora largely moved to services defined as data in "INI"-style configuration files. GP's "shell-script-based boot" is not an unfair way to characterize Fedora's boot process prior to (and including the early history of) systemd in Fedora. [0]: https://fedoraproject.org/wiki/Features/Upstart https://fedoraproject.org/wiki/Features/Upstart [1]: https://fedoraproject.org/wiki/Features/systemd https://fedoraproject.org/wiki/Features/systemd [2]: https://fedoraproject.org/wiki/Features/Systemd-unit-cleanup https://fedoraproject.org/wiki/Features/Systemd-unit-cleanup
  - JdeBP 7y ago
    Miquel van Smoorenburg never worked for Redhat that I know of. It was not a "Redhat init" as you call it. Indeed, it wasn't even init. The things that we are talking about are rc, not init, in the van Smoorenburg system. Nor was there the sort of exclusive "compatibility mode" that you are envisaging in order to make your argument that mixmastamyk was referring to Upstart. Upstart could employ van Smoorenburg rc scripts, but that was not a mode. Upstart was still event-driven with job files. The van Smoorenburg rc scripts were run via what was just another job file. Were your argument valid for Upstart, it would equally be valid for systemd's mechanism for invoking van Smoorenburg rc scripts, and you would have to say that systemd is shell-script-based boot, which really makes a nonsense of mixmastamyk talking about "going back" to it from systemd. Quite clearly, going back to Upstart is not what mixmastamyk was talking about, which not least can be seen from xyr comment written, next to yours, 4 days beforehand.

a1369209993 7y ago

I'd like to believe that, but things like https://www.debian.org/vote/2019/vote_002 https://www.debian.org/vote/2019/vote_002 really aren't encouraging (note the absence of any proposal for actually removing the toxic Big Ball of Mud, and that the top voted proposal is to drop support for any software that works correctly).