In some ways I think the filesystem is philosophically the exact opposite of systemd — I can boot my system with an ext4 root, with a btrfs /home…or vice versa. Or add some ZFS, or whatever. The filesystem is (with the exception of some special backup schemes) largely independent of the rest of the system, despite being of core importance.
On the other hand, I can’t change my init system (i.e., systemd) without serious, serious work.
It’s also “infectious” software. The way systemd positions itself on the system, it can make it more difficult for software to be written in an agnostic way. This isn’t all software, and is often more of a complaint by lower level software, like desktop environments. https://catfox.life/2024/01/05/systemd-through-the-eyes-of-a-musl-distribution-maintainer/
This isn’t a terrible summary of some of the aspects of it.
Another aspect is that when it was first developed, the lead on the project was exceptionally hostile to anyone who didn’t immediately agree that systemd definitely should take over most of the system, often criticizing people who pointed out bugs or questionable design decisions as being afraid of change or relics of the past.
It’s more of a social reason, but if people feel like the developer of a tool they’re forced to use doesn’t even respect their concerns, they’re going to start rejecting the tool.
It’s that it also decided to take over log management, event management, networking, DNS resolution, etc, etc.
If it were just an init system that would be perfectly portable. People were able to write software that way with sysv for years.
It’s that in order to do certain low level tasks on a systemd system, you need to integrate with systemd, not just “be started by it”. Now if a distro wants that piece of software, it needs to use systemd, and other pieces of software that want to be on that distro need to implement integration with systemd.
A dependency isn’t infectious, but a dependency you can’t easily swap out is, particularly if it’s positioned near the base of a dependency tree.
Almost all of my software can run on x86 or arm without any issues beyond changing compiler targets.
It’s closer to how it’s tricky to port software between Mac and Linux, or Linux and BSD. Targeting one platform entails significant, potentially prohibitive, effort to support another, despite them all being ostensibly compatible unix like systems.
log management, event management, networking, DNS resolution
and this is a bad thing? the distro can choose to not use it, but because every systemd distro uses it, it’s a 1000x easier to implement it without needing to put a fuck tons of if-else’s for every distro
No, not everyone thinks it’s a bad thing. It is, however, infectious, which is a reason some people don’t like it.
Knowing why people dislike something isn’t the same as thinking it’s the worst thing ever, and liking something doesn’t mean you can’t acknowledge it’s defects.
I think it’s a net benefit, but that it would be better if they had limited the scope of the project a bit, rather than trying to put everything in the unit system.
and what’s the problem?, it’s not like everything is in the same binary or it’s a monstrosity that can’t be used without using every single feature, it’s a project that just has different programs under the same project name, because no one wanted todo theoe programs
I think the init system is the best part of systemd. It is sooo easy to use. You don’t have to write the same complicated shell script for your software like everyone else. You just give systemd the path to your executable and that’s basically it. It does the rest and you don’t have to worry about PID files or forking the actual software. Systemd basically runs it like you did while developing it.
I think what people don’t like are all the other parts of systemd that seem to be tightly coupled. I don’t know if it is even possible to run just the systemd init without any other systemd package.
The last time I got angry at systemd was when resolvd did some DNS shit I did not approve of.
Indeed, the Unix philosophy was do one thing and do it well. ls just list directory’s and files it’s not a network manager too. Systemd crams a lot of extra shit into an init.d/rc.
I still prefer the old system-v/openRC setup or BSD’s setup. It’s simple does 1 job and does it well. But I can work with systemd just fine in creating scripts these days and it does have some nice features like user startup scripts baked into it and podman integrates very nicely with it.
The idea as far as I can tell is that it’s responsible for too many things and gives a massive point of failure.
Man, wait until these people hear about the filesystem and kernel.
In some ways I think the filesystem is philosophically the exact opposite of systemd — I can boot my system with an ext4 root, with a btrfs /home…or vice versa. Or add some ZFS, or whatever. The filesystem is (with the exception of some special backup schemes) largely independent of the rest of the system, despite being of core importance.
On the other hand, I can’t change my init system (i.e., systemd) without serious, serious work.
hurd “exists”
That’s GNU/Hurd thank you
yes mr stallman
Does it ? I thought it was never completed !
On the other hand, if you want a microkernel that does exist, there’s Mach. But I don’t think you can replace Linux with it 😆
It’s been two years away for the last 30 years.
Yeah, there’s a Debian implementation of GNU/hurd. Debian recommend you run it in a VM
I won’t bother. Sounds like hurd work.
The very existence of a defined kernel is an insult to the Linux philosophy
The Linux kernel (the part that gives Linux the name) is antithetical to Linux philosophy? I could understand it being contrary to GNU philosophy
It’s also “infectious” software. The way systemd positions itself on the system, it can make it more difficult for software to be written in an agnostic way. This isn’t all software, and is often more of a complaint by lower level software, like desktop environments.
https://catfox.life/2024/01/05/systemd-through-the-eyes-of-a-musl-distribution-maintainer/ This isn’t a terrible summary of some of the aspects of it.
Another aspect is that when it was first developed, the lead on the project was exceptionally hostile to anyone who didn’t immediately agree that systemd definitely should take over most of the system, often criticizing people who pointed out bugs or questionable design decisions as being afraid of change or relics of the past.
It’s more of a social reason, but if people feel like the developer of a tool they’re forced to use doesn’t even respect their concerns, they’re going to start rejecting the tool.
the develope receive a fuck ton of hate too, and he keep the project going, against every one unix-way haters
Well, I don’t give him too much credit for that given that it was his day job, not some passion project.
Most of the hate towards him was because he took an abrasive stance against anyone who disagreed with him, or pointed out bugs.
What do you expect from an init system? It’s like saying my cpu is infectious because my computer depends on it
It’s that it also decided to take over log management, event management, networking, DNS resolution, etc, etc.
If it were just an init system that would be perfectly portable. People were able to write software that way with sysv for years.
It’s that in order to do certain low level tasks on a systemd system, you need to integrate with systemd, not just “be started by it”. Now if a distro wants that piece of software, it needs to use systemd, and other pieces of software that want to be on that distro need to implement integration with systemd.
A dependency isn’t infectious, but a dependency you can’t easily swap out is, particularly if it’s positioned near the base of a dependency tree.
Almost all of my software can run on x86 or arm without any issues beyond changing compiler targets. It’s closer to how it’s tricky to port software between Mac and Linux, or Linux and BSD. Targeting one platform entails significant, potentially prohibitive, effort to support another, despite them all being ostensibly compatible unix like systems.
Bro I’m with you on this but the systemd bots will just keep arguing with and downvoting you. Don’t bother.
and this is a bad thing? the distro can choose to not use it, but because every systemd distro uses it, it’s a 1000x easier to implement it without needing to put a fuck tons of if-else’s for every distro
No, not everyone thinks it’s a bad thing. It is, however, infectious, which is a reason some people don’t like it.
Knowing why people dislike something isn’t the same as thinking it’s the worst thing ever, and liking something doesn’t mean you can’t acknowledge it’s defects.
I think it’s a net benefit, but that it would be better if they had limited the scope of the project a bit, rather than trying to put everything in the unit system.
and what’s the problem?, it’s not like everything is in the same binary or it’s a monstrosity that can’t be used without using every single feature, it’s a project that just has different programs under the same project name, because no one wanted todo theoe programs
I think the init system is the best part of systemd. It is sooo easy to use. You don’t have to write the same complicated shell script for your software like everyone else. You just give systemd the path to your executable and that’s basically it. It does the rest and you don’t have to worry about PID files or forking the actual software. Systemd basically runs it like you did while developing it.
I think what people don’t like are all the other parts of systemd that seem to be tightly coupled. I don’t know if it is even possible to run just the systemd init without any other systemd package.
The last time I got angry at systemd was when resolvd did some DNS shit I did not approve of.
Indeed, the Unix philosophy was do one thing and do it well. ls just list directory’s and files it’s not a network manager too. Systemd crams a lot of extra shit into an init.d/rc.
I still prefer the old system-v/openRC setup or BSD’s setup. It’s simple does 1 job and does it well. But I can work with systemd just fine in creating scripts these days and it does have some nice features like user startup scripts baked into it and podman integrates very nicely with it.