5 ms·
I agree although I still run systemd. I run both Debian (with systemd) and Devuan (a Debian fork with anything systemd removed). The reason I still run a syst
by TacticalCoder 3y ago
I agree although I still run systemd. I run both Debian (with systemd) and Devuan (a Debian fork with anything systemd removed). The reason I still run a systemd-less fork is to not forget that Linux still works fine without systemd.
Linux is not systemd.
I did actually write systemd services and I'm not sure the "convenience" warrants what Microsoft (and Poettering) are doing to Linux.
The only one true savior we still have is Linus and, so far, Poettering still hasn't found a way to control the kernel's development.
But Microsoft/Poettering already won PID 1 on most distros/installs and, although I run systemd on several machines (including servers), it is not good that PID 1 is lost. It simply isn't.
Even if there were no technical objections (but there are: gigantic attack surface, lame binary logs, bugs regularly tagged as "not bugs" because Poettering feels like they're not bugs, etc.), it's still a huge problem how this gigantic squid spreads its tentacle everywhere.
Anyone finding it totally normal that the person in charge of PID 1 works for Microsoft is totally delusional.
People should at least acknowledge there are reasons to be concerned about that.
And whether sysvinit scripts do actually suck or not has nothing to do with PID 1 being controlled by someone working for Microsoft.
- stryan 3y agoPoettering didn't join Microsoft until 2022, systemd has been around since 2010.
- jmclnx 3y agoTrue, but soon he will be dropping script integration, not that I care, but the coincidence is a interesting. Join M/S, drop shell scripts :)
- op00to 3y agoScript integration is not dropped. You can easily run a script from a unit file.
- bravetraveler 3y agoYea, they're dropping the native generator for /etc/init.d, I believe. Scripts placed here implicitly became systemd services. Nothing of huge value is lost. Distributions play an important part, we shouldn't forget. They can maintain something like this for users, if so inclined. This mostly hurts third party/ancient/naive packages that you probably, eventually, won't want to install on your distribution for other reasons. This won't affect any packages natively provided by your distribution of choice. Think those random RPMs/DEBs you get from an external vendor -- UPS, keyboard, whatever. They've had over a decade to see the writing on the wall, adding ~12 lines to their entire codebase/packaging spec. Probably a net-reduction given the NIH-syndrome of these scripts. Instead, I've seen them make this directory, put their scripts inside, and just expect things to work out. It did, arguably by chance. The compatibility was deliberate, but support isn't forever.
- op00to 3y agoThat’s wild! I too have seen horror I wish I could forget. For those still worried, the pain is limited to about 15 minutes of writing a unit file, testing it, and waiting for ci or builds to finish! I expect to have to do this for older or more esoteric stuff, but I also enjoy writing unit files.
- kaba0 3y agoWhat a shit take.. system boot is a complex problem requiring a monolith solution, otherwise you just building some Rube Goldberg machine. The same way the kernel is a fucking huge monolith. Also, what would be the point with Poettering? What does he gain from being constantly criticized by lunatics? Like honestly, these takes are some jewish space laser level ones.