The reason why systemd has become so prevalent is not that it has been accepted by the community. It's that it has manpower. It is backed up by open source software companies that can provide much more manpower than developers like myself working on free software on their own time.
TLDR
But also it has been accepted by the "community", by and large.
I mean, what is his point? We should have worse software because then the devs are volunteers?
Is Linux now supposed to work like early Olympics?
Explain how other init systems are necessarily worse than systemd
SystemD is not an init system. It provides that functionality, but processes have more life cycle steps than just initialize.
When you accept that, you realise that you cannot compare them.
SystemD provides functionality that they don't. Of course those that refuse to consider this will just claim it's bloat. To some DE's are bloat.
Systemd is no longer just an init system, but the project began with Poettering's dislike of other init systems. I use systemd and I do not like its performance (too slow in some cases).
The tragedy is that being an end-user, it is ridiculously hard to replace systemd on "regular" distros. Admittedly, Debian can be moved back to sysVinit without backbreaking work, but the fact is that distros don't seem to have any intention of providing choice, making applications assume that systemd exists wherever they will be installed. That is the complaint I have against the Linux community
Most distros independently decided that SystemD was superior. They had a choice and they chose. Distros are often maintained by volunteers in their free time. Same with software that depends on it. Expecting them to provide poor irrelevant choices is not how open source works. You're passing on your backbreaking work onto other people. If you want another option, you give your time to make it happen.
Two questions:
do you admit that, comparing only its functionalities as an init system, systemd provides no benefits over alternatives?
what non-init functionalities does systemd provide, which are necessary and beats competition from other software that provides those features?
Sure, the alternative init systems don't provide non init functionalities, but other software probably does.
no. Processes have a life cycle other than init. Fire and forget with bash scripts is backwards.
I am no expert on this and could not do this answer justice. A quick search will provide a better and more detailed answer. That is if you are willing to consider that SystemD provides benefits. The way you wrote your question gives me vibes that you do not want to, so this debate would be fruitless.
Not how I understood it. Rather, there are alternatives that have potential to be better than systemd, but systemd has the unfair advantage of receiving the funding and manpower.
If alternatives had equal manpower, they may have had better success than systemd.
Yeah. I like systemd. This guy is just bitter and adverse to change.
That's the real reason honestly.
I would go as far to say that it has been embraced
Sure but that is most open source programs. It is not the hacker doing it in their spare time. The majority of open source devs are working for a company getting paid to program it.
People have to eat.
Uh, no. Not the majority. Not by a long shot.
And that it is better on many levels
It's 2024, I think we can move on from cringe systemd hating.
This is like being still angry that Windows 7 is heavier than windows XP.
I didn't understand why people were averse to systemd so after reading at least it was informative for me
From my own experience it was more about being a solution in search of a problem. I see some comments about how the old init system was so horribly broken, and yet the reality was it worked perfectly fine for all but some very niche situations. The only advantage I have ever seen with systemd is that it's very good at multitasking the startup/shutdown processes, but that certainly wasn't the case when it first arrived. For example I had a raspberry pi that booted in 15 seconds, and when I loaded a new image with systemd it took close to two minutes to boot. And there were quite a lot of problems like that, which is why people were so aggravated when distro admins asked the community for their thoughts on switching to systemd and then changed the distros anyway. This also touches on the perception that the "community" accepted it and moved on -- no, systemd was pushed on the community despite numerous problems and critical feedback.
But we're here now, systemd has improved, and we can only hope that some day all the broken bits get fixed. Personally I'm still annoyed that it took me almost a week to get static IPs set up on all the NICs for a new firewall because despite the whole "predictable names" thing they still kept moving around depending on if I did a soft or hard reset. Configuring the cards under udev took less than a minute and worked consistently but someone decided it was time to break that I guess.
It also offers a lot of modern features like sandboxing and close tracking of processes. It is also nice to have dynamic resource allocation
There's nothing 'informative' on that article. It's just an opinion piece.
Then maybe you can tell me what "attempting to do more" means, because the author of the article certainly didn't. Or why that's bad. My only take away is that the author thinks the system should facilitate the running of applications and just get out of their way already. But that sounds a lot like building a road network and then failing to install traffic controls because the DOT should just stay out of the way of traffic.
SystemD also contains things like a network manager, dns resolving, ntp time sync and more, which I agree should not be so tightly coupled to the core init system.
Why?
at least this guy recognizes systemd isn't (just) an init system
"it attempts to do more"
yeah. that's the point. that's a good thing. a single source of truth for system background services. background systems used to be a fucking mess and then systemd fixed it. this is why it is the de facto pid 1
i wish people just quit whining
I think if systemd were documented in a more consumable format (the man pages need better organization IMO) more people would see how powerful it is. Mounting directories with BindPath, and BindPathRO, Limiting systemcalls, socket activation and cgroup integration, and nspawn containers are features I can't live without.
I feel like a lot of people that get attached to the "It tries to do everything and it's against the unix philosophy" argument might change their minds when they see the tradeoffs. It has its problems for sure, but you get a lot out of it.
These days I don't even use docker containers for running services. I just put it in a systemd service and lock it down as tightly as I can.
I'm pretty sure the Arch Wiki has a substantial documentation regarding systemd
It's powerfulness IS the problem. Some parts of systemd are great. Some are meh! Some really suck. But because it's monolithic, you can't take the good bits and replace the bad. You have to take it all or nothing.
That's the problem. Its architecture is offensively bad.
That's just completely wrong. Just try e.g. replacing the journald backend with the old text based syslog, and not only will you discover that is possible (which directly contradicts what you just said), it's also easy!
It is pretty well documented. Just look it up online and you will find plenty of articles
You'll find blog spam and ai slop if you look it up online.
Systemd's website/man pages should be the resource that brings me up to speed.
I had to read about run0 and other upcoming systemd features from Lennart's Mastodon which I'm not a fan of either. These kinds of things should be on the systemd website itself.
that's a great example of bad docs.
How so? What are you trying to do?
read up to date current docs and know they are for the current working state of the system, potentially when i don't have a net connection because i'm troubleshooting PID 0/1
What can systemd do that cannot be done with OpenRC?
i don't know much about openrc, but doesn't it use sysvinit? one of the major advantages of systemd is ditching sysvinit
The biggest threat to the Linux Community is the Linux Community itself.
Yeah, but we are the real™ Linux community, not like those splitters from the community of Linux!
But this statement is splitting the Linux community. xD
Quick, someone post the meme from the Simpsons with a penguin on his face
Praise be the Unix Philosophy. May all your projects do precisely one thing, and let they not be tempted by forbidden fruit and do two things.
You do know that systemd is modular and every part of it does only one thing?
Don't see a real conflict with the Unix Philosphy
Systemd: the Biggest Fallacies - point 1 addresses what you're talking about, but remember that this blog is almost a decade old, so by this time, it is not reflective of the current condition.
I fear that the situation will not be better after nearly a decade.
In fact, the situation has gotten much worse. The coupling of SystemD's components to each other has gotten tighter. The coupling of things that aren't SystemD to SystemD has gotten tighter. SystemD itself has gotten less stable. The overall result? Our operating systems require more, not less, troubleshooting, and they're less, not more, enjoyable to use and develop on
I've never ever had an issue with systemd and I've been running Linux for years.
However, systemd makes the system much more secure and reliable as it is vastly superior to just a couple of shell scripts from 1999
However, systemd makes the system much more secure and reliable as it is
less secure and less reliable day-by-day you meant?
systemd introduces needless dependencies ever since as if that was it sole intention ever from its very beginning, which already were used for wide attacks, and exactly those attacks that the people working hard to remove unneeded dependencies for security reasons meant to prevent by things like "do one thing only" (but security was not the number 1 reason for this one i think), systemd instead: 'lets add another level of that exponential dependency tree from the insecurity hell' felt like they did this stupid thing intentionally every month for a decade or more.
and stability... if you don't monitor what systemd does, you'll never know how bad it actually is. i've made custom scripts to monitor systemd's failures (failing in doing a very primitive of its job) and there are hundreds (actually varying around 200 to 300 sometimes more) of such per day on all our systems for one particular(!) measurement only that was breaking service stability and i wrote a measure-and-fix+monitor workaround. other fixes were not monitored however, only silently fixed by workarounds, thus just unnumbered systemd bugs/instabilities in the dark that stole a lot of work capacity...
if you run distros with systemd, unreliability is your daily experience unless you don't really care or have never experienced stability before - like running a service (a single process) for 8 years without any interruption then it suddenly stops and you go like "was it maybe an attack? the process died, how could that be? were there any connects from outside at that moment?" not talking about not updating something that long, but "stability" itself CAN be like if you dont stop it, it'll still run in 10000+ years maybe millions, more likely that humans extincted themselves way earlier than of a process "just dying" by a bug.. while systemd even randomly stops things that were running well for no reason (varying) once a month more or less (also varying in what it actually randomly stops, sometimes (2 times) it even stopped ssh on my servers, me asking myself if i should create yet another workaround for systemds buggyness to not locking me out again from network or ratjer go for the real solution for most* of all systemd problems - *see below) on the few standard installs i personally have as i didn't have the way to automatically replace provider installed distro on VMs in the DC. i want this replacing automatically for the same reason why i don't like systemd, it causes manual work for a thing that should go automated. however due to systemd's perpetuated instability i now managed to have this way, and every second working on getting rid of systemd is worth it 100k times.
this however does not solve all systemd-introduced problems as the xz attack showed (a systemd-dependency on xz made the infected xz library beeing useful-for-the-atracker during compiletime of sshd binary with which then the attacker could infect the newly built sshd binary),one could still be attacked through systemd's dependency hell even if one does not use systemd by oneself, but the build machines used for your distro could be affected/infected by systemd's needless dependencies when "also" compiling for systemd-affected distributions thus there is the risk of becoming a victim of needless-systemd-dependencies while not using systemd at all.
however the attack through systemd dependency (and that the public solution was not the removal of needless dependencies only included as source for superflous third party "needs") made clear that systemd is an overall problem for security that will not be solved quickly but stay just like all windows insecurities will stay as long as they whish to push them to their "users".
systemd reducing overall security and its unreliability combined with some builtin impediments (i.e. when debugging its defects) is what drove me away from systemd. there are solutions way more stable and way more secure (and way better documented btw) that do not call in for needless dependencies, reducing risks, attack vectors and increases overall debuggability i.e. by deterministic behaviour as an easy example.
and none of its important (to me) promises have been fulfilled yet by systemd, drop-in-replacement? have heared that lie thousands of times, but in the last decade i have not experienced it a single time in a distro and it does not seem to be included/finished any more.
for windows users or windows admins a linux with systemd on it IS an improvement in stability, security and of course for updating, yes. but all of that does not come from systemd, rather the opposite is the case, systemd reduces it month by month, thats my experience and thats the most important experience for me, idc what lies whitdepapers tell or what broken promises are believed by anyone or the masses, i want secure and stable servers and services and systemd does not fit in for any of these goals and the time it was still "young" and early problems could be accepted in the hope they get fixed soon are gone, but without those fixes having ever appeared.
this is everything i see monitoring Linux boxes everyday. we've shifted mostly to OpenRC about it. i can't imagine defending SystemD if you have experienced anything other than it and SysInitV. yeah compared to SysInitV, it's really nice, but to say it's good and stable? that's like praising your landlord for all the work they do and the reason they haven't fixed your broken dishwasher is because they're so busy from what a good landlord they are
more likely that humans extincted themselves way earlier than of a process "just dying" by a bug..
Lol what???
Lol what???
wouldn't that be the definition of stable?
the computer on voyager 2 is running for 47 years now, they might have rebooted some parts meanwhile but overall its a long time now, and if the program is free of bugs the time that program can run only depends on the durability of the hardware, protection from cosmic rays (which were afaik the problems the voyager probes faced mostly, not bugs) which could be quite long if protected from hazardous environments and maybe using optoelectronics but the point is that a bug free software can run forever only depending on hardware durability and energy supply, in any other way no humans are needed for a veery long time ;-)
Yeah, was more poking fun of people who cling to the while Unix Philosophy stuff like it's some unwritten rule that must be followed.
I honestly think there's tons of Linux software that could be broadly defined as "multiple things".
Even looking at the links other responders have posted, I even think a lot of linux software is made up of components which are tightly coupled together.
one example of a program that did multiple things is sfdisk, it used to make the kernel reload the new partition table but that was not its main job, only changing them.
the extra functionality moved to blockdev which is nearer to doing such as it also triggers flushing buffers and i think setting read/write status.
i am fully ok with that change as it removes code from a program that doesn't need it to another that already does similar things so that other partitioning programs like gdisk fdisk or parted could go the same way so that maintainers of the reread-partition-table things can concentrate on one solution at one place (in userspace) instead of opening issues at an unknown number of projects that also alter partitioning. the "do one thing" paradigma is good for developers who maintain the code and i pretty much appreciate their work. if you are up to only want one-day-flies that either die or take huge amounts of resources only for keeping them alive (image of a mayfly in an emergency room and a heart-lung machine attached while chirurgs rushing around trying to enlenghten its life a few seconds more) then you are good with monolithic tools that could hardly be maintained and suck allday as no one wants to fix any bugs or cannot without creating new ones due to the tightened dependency hell it has internally.
the point is not a lack of examples doing wrong but where one wants to be heading towards.
Stop it Patrick, you're scaring him
Honestly, it's 2024, and as a result, this post gives me a bit of a chuckle. For most purposes, systemd has won, and honestly, I hardly even notice. (Granted, I have only used Linux during the systemd era.) If systemd actually interferes with one's needs on a technological (not just a vague philosophical) level, little stops them from seeking out a way to use another init system.
Has it gotten more difficult to use other init systems these days? Yes. However, by the time a person has a problem where systemd can't do the job and have to use a different init system, they're probably more than competent enough to create custom services. I also feel like in terms of software support, only the most idiotic, worthless projects have no possible way to port hem to another init system.
I used Linux during the init.d days. What a nightmare that was.
The only thing I liked was arch's pretty boot sequence … which I stared at for a while because SysV init was so slow.
Busybox init and openRC seem to be the alternatives. They are both useful in embedded contexts where you don't need much just a program to start a service
I may have misconveyed my meaning. I wasn't necessarily arguing that systemd has no viable alternatives. I meant to say that where systemd doesn't work (embedded systems being a good example), chances are the lack of support won't be a burden for a reasonably skilled user.
I've heard of s6 and runit alongside OpenRC as alternatives. I believe distros should make the init system agnostic of the rest of the software and not force users to stick with what they force them to do. Systemd is really slow.
What infuriates me more than distros playing the heavy hand in adopting it, are applications depending on it (I'M LOOKING AT YOU GNOME). This is completely unacceptable. If I find an application that doesn't work without systemd, I either compile it to see if it will work otherwise or give up on it.
Maybe my view of systemd will change if I delete all of the other binaries and just use the init module. Who the fuck decided to put a fucking log in manager with the init system???? This is the feature bloat that I'm talking about and I hate it
systemd is a system daemon, not an init system
also, why should applications avoid depending on useful features?
SystemD has been such a frustration the last couple years with the wonderful simplicity and stability it used to provide managing a system completely out the door as its main development company (RedHat) has stopped giving any kind of a shit about being a positive force in the world. We all shoulda listened 10 years ago when the greybeards were telling us not to fall for an init system trying to do too much.
If we listened to the grey beards there’d be no gui. Just a. Cli interface.
I'm not seeing a problem here.
Emacs, sed and logining in as root
Emacs? When there's ed? Talk about bloat…
Why would you need a GUI for the init?
Idk, I kinda like systemd.
Me too. I enjoy the @myservername thing as it lets me have one file to maintain lots of servers (Minecraft in my case). I'm sure someone will say other init systems can do the same, but I learnt this one and I like it.
I just insert the Tragedy of systemd video as my usual response to these threads.
We're doing this again?
Did we ever stop doing this?
If there's two things Linux users will argue about it's how your system inits itself, and text editors.
And Wayland
Wonder if we'll have another good ol' browser war when/if Ladybird releases.
Probably**
Weirdly enough that is somehow less controversial
Maybe some day after we're done replacing X11 people will collectively find the will to do something about systemd before it gets too much worse. I wonder which will be easier: Throw it all out and start again, or split it up into parts of more manageable size with well-defined interfaces between them.
There's shepherd for Guix, which I like, to be frank. elogind is seperated, as opposed to logind being a part of the "init" system. There's also alternatives like s6 and runit.
I'm honestly surprised by how nice Shepherd is now that I'm trying out Guix. It just seems very minimal and stays out of the way. But I havent poked around with it much
I'm pretty sure most people aren't even aware of systemd let along its alternatives. Linux and systemd go together like cake and ice cream. It is the standard.
I'm pretty sure everyone has settled by now, Personally I hate systemd. It's slow, relatively resource intensive, poorly designed in many aspects.
but as an init and service manager it's the best. Though I do have to say dinit does get pretty close for me now.
I personally use Arch on my desktop and artix on my laptop. I want Systemd to die just as much as the next Systemd hater, but unfortunately I don't believe we have anything better yet.
It is faster on modern hardware due to heavy optimization
can't say I have experienced that. I use a myriad of modern but lower end systems and stuff like dinit still uses less resources and is in turn better for the speed and responsiveness of my systems
I've run systemd on a system with 32mb of memory and a Pentium II. It was not the bottle neck and it booted right up.
This article sounds a decade old.
systemd attempts to cover more ground instead of less
Have I got news for the author about the kernel he seems to have no issue with. (Note: I love the Linux kernel, but being a monolith, it certainly covers more ground instead of less, so the author's point is already flawed unless he wants to go all Tanenbaum on the kernel, too)
TLDR
But also it has been accepted by the "community", by and large.
I mean, what is his point? We should have worse software because then the devs are volunteers?
Is Linux now supposed to work like early Olympics?
Explain how other init systems are necessarily worse than systemd
SystemD is not an init system. It provides that functionality, but processes have more life cycle steps than just initialize.
When you accept that, you realise that you cannot compare them.
SystemD provides functionality that they don't. Of course those that refuse to consider this will just claim it's bloat. To some DE's are bloat.
Systemd is no longer just an init system, but the project began with Poettering's dislike of other init systems. I use systemd and I do not like its performance (too slow in some cases).
The tragedy is that being an end-user, it is ridiculously hard to replace systemd on "regular" distros. Admittedly, Debian can be moved back to sysVinit without backbreaking work, but the fact is that distros don't seem to have any intention of providing choice, making applications assume that systemd exists wherever they will be installed. That is the complaint I have against the Linux community
There is Alpine and Void Linux which are commonly known of and used. Plus more: https://en.m.wikipedia.org/wiki/Category:Linux_distributions_without_systemd
Most distros independently decided that SystemD was superior. They had a choice and they chose. Distros are often maintained by volunteers in their free time. Same with software that depends on it. Expecting them to provide poor irrelevant choices is not how open source works. You're passing on your backbreaking work onto other people. If you want another option, you give your time to make it happen.
Two questions:
Sure, the alternative init systems don't provide non init functionalities, but other software probably does.
no. Processes have a life cycle other than init. Fire and forget with bash scripts is backwards.
I am no expert on this and could not do this answer justice. A quick search will provide a better and more detailed answer. That is if you are willing to consider that SystemD provides benefits. The way you wrote your question gives me vibes that you do not want to, so this debate would be fruitless.
If you're genuinely curious Benno Rice has a great talk on SystemD: https://m.youtube.com/watch?v=o_AIw9bGogo&pp=2AHFBpACAQ%3D%3D
Not how I understood it. Rather, there are alternatives that have potential to be better than systemd, but systemd has the unfair advantage of receiving the funding and manpower.
If alternatives had equal manpower, they may have had better success than systemd.
Yeah. I like systemd. This guy is just bitter and adverse to change.
That's the real reason honestly.
I would go as far to say that it has been embraced
Sure but that is most open source programs. It is not the hacker doing it in their spare time. The majority of open source devs are working for a company getting paid to program it. People have to eat.
Uh, no. Not the majority. Not by a long shot.
And that it is better on many levels
It's 2024, I think we can move on from cringe systemd hating.
This is like being still angry that Windows 7 is heavier than windows XP.
I didn't understand why people were averse to systemd so after reading at least it was informative for me
From my own experience it was more about being a solution in search of a problem. I see some comments about how the old init system was so horribly broken, and yet the reality was it worked perfectly fine for all but some very niche situations. The only advantage I have ever seen with systemd is that it's very good at multitasking the startup/shutdown processes, but that certainly wasn't the case when it first arrived. For example I had a raspberry pi that booted in 15 seconds, and when I loaded a new image with systemd it took close to two minutes to boot. And there were quite a lot of problems like that, which is why people were so aggravated when distro admins asked the community for their thoughts on switching to systemd and then changed the distros anyway. This also touches on the perception that the "community" accepted it and moved on -- no, systemd was pushed on the community despite numerous problems and critical feedback.
But we're here now, systemd has improved, and we can only hope that some day all the broken bits get fixed. Personally I'm still annoyed that it took me almost a week to get static IPs set up on all the NICs for a new firewall because despite the whole "predictable names" thing they still kept moving around depending on if I did a soft or hard reset. Configuring the cards under udev took less than a minute and worked consistently but someone decided it was time to break that I guess.
It also offers a lot of modern features like sandboxing and close tracking of processes. It is also nice to have dynamic resource allocation
There's nothing 'informative' on that article. It's just an opinion piece.
Then maybe you can tell me what "attempting to do more" means, because the author of the article certainly didn't. Or why that's bad. My only take away is that the author thinks the system should facilitate the running of applications and just get out of their way already. But that sounds a lot like building a road network and then failing to install traffic controls because the DOT should just stay out of the way of traffic.
SystemD also contains things like a network manager, dns resolving, ntp time sync and more, which I agree should not be so tightly coupled to the core init system.
Why?
at least this guy recognizes systemd isn't (just) an init system
"it attempts to do more" yeah. that's the point. that's a good thing. a single source of truth for system background services. background systems used to be a fucking mess and then systemd fixed it. this is why it is the de facto pid 1
i wish people just quit whining
I think if systemd were documented in a more consumable format (the man pages need better organization IMO) more people would see how powerful it is. Mounting directories with BindPath, and BindPathRO, Limiting systemcalls, socket activation and cgroup integration, and nspawn containers are features I can't live without.
I feel like a lot of people that get attached to the "It tries to do everything and it's against the unix philosophy" argument might change their minds when they see the tradeoffs. It has its problems for sure, but you get a lot out of it.
These days I don't even use docker containers for running services. I just put it in a systemd service and lock it down as tightly as I can.
I'm pretty sure the Arch Wiki has a substantial documentation regarding systemd
It's powerfulness IS the problem. Some parts of systemd are great. Some are meh! Some really suck. But because it's monolithic, you can't take the good bits and replace the bad. You have to take it all or nothing.
That's the problem. Its architecture is offensively bad.
That's just completely wrong. Just try e.g. replacing the journald backend with the old text based syslog, and not only will you discover that is possible (which directly contradicts what you just said), it's also easy!
It is pretty well documented. Just look it up online and you will find plenty of articles
You'll find blog spam and ai slop if you look it up online. Systemd's website/man pages should be the resource that brings me up to speed.
I had to read about run0 and other upcoming systemd features from Lennart's Mastodon which I'm not a fan of either. These kinds of things should be on the systemd website itself.
that's a great example of bad docs.
How so? What are you trying to do?
read up to date current docs and know they are for the current working state of the system, potentially when i don't have a net connection because i'm troubleshooting PID 0/1
What can systemd do that cannot be done with OpenRC?
i don't know much about openrc, but doesn't it use sysvinit? one of the major advantages of systemd is ditching sysvinit
The biggest threat to the Linux Community is the Linux Community itself.
Yeah, but we are the real™ Linux community, not like those splitters from the community of Linux!
But this statement is splitting the Linux community. xD
Quick, someone post the meme from the Simpsons with a penguin on his face
Praise be the Unix Philosophy. May all your projects do precisely one thing, and let they not be tempted by forbidden fruit and do two things.
You do know that systemd is modular and every part of it does only one thing? Don't see a real conflict with the Unix Philosphy
Systemd: the Biggest Fallacies - point 1 addresses what you're talking about, but remember that this blog is almost a decade old, so by this time, it is not reflective of the current condition.
I fear that the situation will not be better after nearly a decade.
In fact, the situation has gotten much worse. The coupling of SystemD's components to each other has gotten tighter. The coupling of things that aren't SystemD to SystemD has gotten tighter. SystemD itself has gotten less stable. The overall result? Our operating systems require more, not less, troubleshooting, and they're less, not more, enjoyable to use and develop on
I've never ever had an issue with systemd and I've been running Linux for years.
However, systemd makes the system much more secure and reliable as it is vastly superior to just a couple of shell scripts from 1999
less secure and less reliable day-by-day you meant? systemd introduces needless dependencies ever since as if that was it sole intention ever from its very beginning, which already were used for wide attacks, and exactly those attacks that the people working hard to remove unneeded dependencies for security reasons meant to prevent by things like "do one thing only" (but security was not the number 1 reason for this one i think), systemd instead: 'lets add another level of that exponential dependency tree from the insecurity hell' felt like they did this stupid thing intentionally every month for a decade or more.
and stability... if you don't monitor what systemd does, you'll never know how bad it actually is. i've made custom scripts to monitor systemd's failures (failing in doing a very primitive of its job) and there are hundreds (actually varying around 200 to 300 sometimes more) of such per day on all our systems for one particular(!) measurement only that was breaking service stability and i wrote a measure-and-fix+monitor workaround. other fixes were not monitored however, only silently fixed by workarounds, thus just unnumbered systemd bugs/instabilities in the dark that stole a lot of work capacity...
if you run distros with systemd, unreliability is your daily experience unless you don't really care or have never experienced stability before - like running a service (a single process) for 8 years without any interruption then it suddenly stops and you go like "was it maybe an attack? the process died, how could that be? were there any connects from outside at that moment?" not talking about not updating something that long, but "stability" itself CAN be like if you dont stop it, it'll still run in 10000+ years maybe millions, more likely that humans extincted themselves way earlier than of a process "just dying" by a bug.. while systemd even randomly stops things that were running well for no reason (varying) once a month more or less (also varying in what it actually randomly stops, sometimes (2 times) it even stopped ssh on my servers, me asking myself if i should create yet another workaround for systemds buggyness to not locking me out again from network or ratjer go for the real solution for most* of all systemd problems - *see below) on the few standard installs i personally have as i didn't have the way to automatically replace provider installed distro on VMs in the DC. i want this replacing automatically for the same reason why i don't like systemd, it causes manual work for a thing that should go automated. however due to systemd's perpetuated instability i now managed to have this way, and every second working on getting rid of systemd is worth it 100k times. this however does not solve all systemd-introduced problems as the xz attack showed (a systemd-dependency on xz made the infected xz library beeing useful-for-the-atracker during compiletime of sshd binary with which then the attacker could infect the newly built sshd binary),one could still be attacked through systemd's dependency hell even if one does not use systemd by oneself, but the build machines used for your distro could be affected/infected by systemd's needless dependencies when "also" compiling for systemd-affected distributions thus there is the risk of becoming a victim of needless-systemd-dependencies while not using systemd at all. however the attack through systemd dependency (and that the public solution was not the removal of needless dependencies only included as source for superflous third party "needs") made clear that systemd is an overall problem for security that will not be solved quickly but stay just like all windows insecurities will stay as long as they whish to push them to their "users".
systemd reducing overall security and its unreliability combined with some builtin impediments (i.e. when debugging its defects) is what drove me away from systemd. there are solutions way more stable and way more secure (and way better documented btw) that do not call in for needless dependencies, reducing risks, attack vectors and increases overall debuggability i.e. by deterministic behaviour as an easy example. and none of its important (to me) promises have been fulfilled yet by systemd, drop-in-replacement? have heared that lie thousands of times, but in the last decade i have not experienced it a single time in a distro and it does not seem to be included/finished any more.
for windows users or windows admins a linux with systemd on it IS an improvement in stability, security and of course for updating, yes. but all of that does not come from systemd, rather the opposite is the case, systemd reduces it month by month, thats my experience and thats the most important experience for me, idc what lies whitdepapers tell or what broken promises are believed by anyone or the masses, i want secure and stable servers and services and systemd does not fit in for any of these goals and the time it was still "young" and early problems could be accepted in the hope they get fixed soon are gone, but without those fixes having ever appeared.
this is everything i see monitoring Linux boxes everyday. we've shifted mostly to OpenRC about it. i can't imagine defending SystemD if you have experienced anything other than it and SysInitV. yeah compared to SysInitV, it's really nice, but to say it's good and stable? that's like praising your landlord for all the work they do and the reason they haven't fixed your broken dishwasher is because they're so busy from what a good landlord they are
Lol what???
wouldn't that be the definition of stable?
the computer on voyager 2 is running for 47 years now, they might have rebooted some parts meanwhile but overall its a long time now, and if the program is free of bugs the time that program can run only depends on the durability of the hardware, protection from cosmic rays (which were afaik the problems the voyager probes faced mostly, not bugs) which could be quite long if protected from hazardous environments and maybe using optoelectronics but the point is that a bug free software can run forever only depending on hardware durability and energy supply, in any other way no humans are needed for a veery long time ;-)
Too long didn't read.
"Situation"
I'm pretty sure everyone moved on
Just read http://judecnelson.blogspot.fr/2014/09/systemd-biggest-fallacies.html and I see now that I was in error with my claim. So yes, I accept all the down votes in shame.
he's joking
Yeah, was more poking fun of people who cling to the while Unix Philosophy stuff like it's some unwritten rule that must be followed.
I honestly think there's tons of Linux software that could be broadly defined as "multiple things".
Even looking at the links other responders have posted, I even think a lot of linux software is made up of components which are tightly coupled together.
one example of a program that did multiple things is sfdisk, it used to make the kernel reload the new partition table but that was not its main job, only changing them. the extra functionality moved to blockdev which is nearer to doing such as it also triggers flushing buffers and i think setting read/write status. i am fully ok with that change as it removes code from a program that doesn't need it to another that already does similar things so that other partitioning programs like gdisk fdisk or parted could go the same way so that maintainers of the reread-partition-table things can concentrate on one solution at one place (in userspace) instead of opening issues at an unknown number of projects that also alter partitioning. the "do one thing" paradigma is good for developers who maintain the code and i pretty much appreciate their work. if you are up to only want one-day-flies that either die or take huge amounts of resources only for keeping them alive (image of a mayfly in an emergency room and a heart-lung machine attached while chirurgs rushing around trying to enlenghten its life a few seconds more) then you are good with monolithic tools that could hardly be maintained and suck allday as no one wants to fix any bugs or cannot without creating new ones due to the tightened dependency hell it has internally.
the point is not a lack of examples doing wrong but where one wants to be heading towards.
Stop it Patrick, you're scaring him
Honestly, it's 2024, and as a result, this post gives me a bit of a chuckle. For most purposes, systemd has won, and honestly, I hardly even notice. (Granted, I have only used Linux during the systemd era.) If systemd actually interferes with one's needs on a technological (not just a vague philosophical) level, little stops them from seeking out a way to use another init system.
Has it gotten more difficult to use other init systems these days? Yes. However, by the time a person has a problem where systemd can't do the job and have to use a different init system, they're probably more than competent enough to create custom services. I also feel like in terms of software support, only the most idiotic, worthless projects have no possible way to port hem to another init system.
I used Linux during the init.d days. What a nightmare that was.
The only thing I liked was arch's pretty boot sequence … which I stared at for a while because SysV init was so slow.
Busybox init and openRC seem to be the alternatives. They are both useful in embedded contexts where you don't need much just a program to start a service
I may have misconveyed my meaning. I wasn't necessarily arguing that systemd has no viable alternatives. I meant to say that where systemd doesn't work (embedded systems being a good example), chances are the lack of support won't be a burden for a reasonably skilled user.
I've heard of s6 and runit alongside OpenRC as alternatives. I believe distros should make the init system agnostic of the rest of the software and not force users to stick with what they force them to do. Systemd is really slow.
What infuriates me more than distros playing the heavy hand in adopting it, are applications depending on it (I'M LOOKING AT YOU GNOME). This is completely unacceptable. If I find an application that doesn't work without systemd, I either compile it to see if it will work otherwise or give up on it.
Maybe my view of systemd will change if I delete all of the other binaries and just use the init module. Who the fuck decided to put a fucking log in manager with the init system???? This is the feature bloat that I'm talking about and I hate it
systemd is a system daemon, not an init system
also, why should applications avoid depending on useful features?
SystemD has been such a frustration the last couple years with the wonderful simplicity and stability it used to provide managing a system completely out the door as its main development company (RedHat) has stopped giving any kind of a shit about being a positive force in the world. We all shoulda listened 10 years ago when the greybeards were telling us not to fall for an init system trying to do too much.
If we listened to the grey beards there’d be no gui. Just a. Cli interface.
I'm not seeing a problem here.
Emacs, sed and logining in as root
Emacs? When there's
ed? Talk about bloat…Why would you need a GUI for the init?
Idk, I kinda like systemd.
Me too. I enjoy the @myservername thing as it lets me have one file to maintain lots of servers (Minecraft in my case). I'm sure someone will say other init systems can do the same, but I learnt this one and I like it.
I just insert the Tragedy of systemd video as my usual response to these threads.
We're doing this again?
Did we ever stop doing this?
If there's two things Linux users will argue about it's how your system inits itself, and text editors.
And Wayland
Wonder if we'll have another good ol' browser war when/if Ladybird releases.
Probably**
Weirdly enough that is somehow less controversial
Maybe some day after we're done replacing X11 people will collectively find the will to do something about systemd before it gets too much worse. I wonder which will be easier: Throw it all out and start again, or split it up into parts of more manageable size with well-defined interfaces between them.
There's shepherd for Guix, which I like, to be frank. elogind is seperated, as opposed to logind being a part of the "init" system. There's also alternatives like s6 and runit.
I'm honestly surprised by how nice Shepherd is now that I'm trying out Guix. It just seems very minimal and stays out of the way. But I havent poked around with it much
I'm pretty sure most people aren't even aware of systemd let along its alternatives. Linux and systemd go together like cake and ice cream. It is the standard.
I'm pretty sure everyone has settled by now, Personally I hate systemd. It's slow, relatively resource intensive, poorly designed in many aspects.
but as an init and service manager it's the best. Though I do have to say dinit does get pretty close for me now.
I personally use Arch on my desktop and artix on my laptop. I want Systemd to die just as much as the next Systemd hater, but unfortunately I don't believe we have anything better yet.
It is faster on modern hardware due to heavy optimization
can't say I have experienced that. I use a myriad of modern but lower end systems and stuff like dinit still uses less resources and is in turn better for the speed and responsiveness of my systems
I've run systemd on a system with 32mb of memory and a Pentium II. It was not the bottle neck and it booted right up.
This article sounds a decade old.
Have I got news for the author about the kernel he seems to have no issue with. (Note: I love the Linux kernel, but being a monolith, it certainly covers more ground instead of less, so the author's point is already flawed unless he wants to go all Tanenbaum on the kernel, too)
Great talk on SystemD for those that are interested: https://m.youtube.com/watch?v=o_AIw9bGogo&pp=2AHFBpACAQ%3D%3D
systemd, not SystemD, or system d.
But yeah, wonderful talk!
Point taken. Saves me some clicking!
I wonder when the year of people shut up about systemd will be
When they die
Uh oh here we go again... spaces are better than tabs! Fight me! The shirt is coming off! Granular white space beats fewer character per file!
Spoiler, the word is: it’s bad!