Around 10 years ago, at age 17. i started using linux right before systemd became the default on debian.
I didn't really know what i was doing.
I just followed a guide on forums and stuff.
Installing the nvidia drivers required me to disable the display manager, enter tty console, and blacklist nouveau drivers.
Since then, linux has evolved allot.
I'm a solo developer, working on my own projects. Never worked for a big company.
Why does systemd exist and why should i care about it?
What exactly does systemd bring to the table that alternative "modular standalone software" does not?
And why not just create an alternative to elogind? How hard could it be?
How many systemd shims does artix use? elogind, etmpfiles, etc...
Systemd seems to keep growing forever, adding its own way of doing things on top of the existing linux userspace that's already installed on the system.
Basically duplicated software.
After trying many times to learn it, i found it too difficult finding the relevant documentation for it.
The systemd website does not explain how to use systemd indepth.
The manpages are all over the place in an unorganized way.
No good books are written about it either. Imaging paying $$$ for documentation.
Systemd currently has 465 open bug issues.
https://github.com/systemd/systemd/labels/bug%20%F0%9F%90%9B
This makes my eyes hurt.
I plan on migrating to artix, currently on arch linux.
Hello and welcome,
A little reading to complete:
https://unixdigest.com/articles/the-real-motivation-behind-systemd.html
I think the question should be "Why systemd was adopted at such an astonishing rate"... And the answer is - control and money.
always good to read, which shows the real motivations of redhat/ibm..
exactly :(
I'm saying since years: When Ballmer said "Linux is cancer", he was right. - But he meant systemd.
Speaking of (in this case a bit less) money I want to reference the Pmos thread
https://forum.artixlinux.org/index.php/topic,6579.msg40103.html#msg40103
this came recently
https://postmarketos.org/blog/2024/08/16/paying-for-development/
Keep comments about this more silent if you can, you know.
Also, I would say don't hate on them, the fight for independence can be vicious sometimes.
all this good,
but can you explain why ALL mainstream distros switched and still using systemd if it so evil thing?
how systemd can control and how it make money at all about that?
answer here?
https://unixdigest.com/articles/the-real-motivation-behind-systemd.html
systemd, 10 years later: a historical and technical retrospective (https://blog.darknedgy.net/technology/2020/05/02/0/index.html)
SSL cert expired but worth a read, or at least a scan, if you want to know some of the history of how we got to where we are (or at least to 2020) with distro's and systemd.
But the short answer is Redhat, money, power and the growth of cloud computing imho.
What does it do for cloud computing?
It simplified part of the provision of instances by the cloud providers without the need to each write their own entire solutions from scratch.
With regard to the above the existent init solutions in use by the big distro's were complex, varied a lot in their implementation and fell short of some desired functionality. At least that was what they were saying at the time.
Systemd was created and heavily pushed by Redhat as a solution.
Once it achieved dominance the huge mission creep began and it started to subsume more and more linux userspace functionality.
It provided features, sd-bus for example, which once used by an application would necessitate the presence of systemd unless the applications developer specifically coded an alternative.
"Embrace, extend, and extinguish" is a famous Microsoft phrase.
Lennart Poettering now works for MS. Maybe they were paying him all along ?
The only thing that bothers me is that s6 and dinit aren't as complete and as well documented enough for someone to use easily as a drop in replacement for sysd. At least not for a normal user's userspace with services other than his, which includes the dbus/socket activation thing.
Why M$ workers are developing sysd?
If I understood correctly https://github.com/bluca and https://github.com/poettering works for M$.
I don't want to stir up controversy, but I think the main reason systemd was adopted by most distributions is that it offered fairly good parallelization capabilities when it was introduced. My favorite init, which is OpenRC, still doesn't provide a parallelization capability as good as that of systemd. I guess reading the following pages can answer your questions:
Systemd (https://wiki.archlinux.org/title/Systemd)
Debate initsystem systemd (https://wiki.debian.org/Debate/initsystem/systemd)
Systemd (https://en.wikipedia.org/wiki/Systemd)
Because R*d H*t is a company motivated by profit and simplicity and stability does not sell, so they kept bloating up Linux to create bugs and security vulnerabilities so they could sell their services.
Being that not enough, they decided to create soystemd, and they had to, because at this point they have bloated Linux enough with so many services at boot that the argument of parallel service start became logically sound. With soystemd they got plenty of bugs and security issues to keep selling support for years, again.
Now the commercialization of Linux is complete, with p*ettering working at micr*s*ft. I'm surprised that R*d H*t is not a subsidiary of Microshit yet.
Embrace, extend and extinguish.
I think this adds to the discussion, in that it addresses what made Systemd attractive.
Specifically I would like to know what one can do with Systemd NOW, that another init(s) cannot do, or do not do well.
And in specific response to Sulfide9842, of course other inits do, right?
Sysd has those dynamic services used by socket activation (start when neeeded), or as other non service types of what it calls "units" and parts of it is useful (getting actual status more than just stderr/fishing a metalog), i know it clashes with unix where a process does it's own thing but a sort of a standardized api won't hurt, sysd doesn't standardize much anyway (apart from like auditing?).
User services are also prettier, although dinit-turnstile-dinit works mostly (basic functions+controlling of the "slave" by the root instance), it's still not as good.
Also the measurement of service startup is sometimes useful.
"Masking" services is something that dinit lacks and kind of needs now with the new codependency scheme.
There's an S6 page on this https://skarnet.org/software/s6/socket-activation.html (https://skarnet.org/software/s6/socket-activation.html). Knowing the origin I would imagine it's fairly easy to generalise to be useful with other inits.