I'm currently reinstalling Linux and I want to discover all pieces of my system because I like understanding how my system works, so I can do choices while being aware of what I do.
However, despite reading for hours about systemd, everything explaining it assumes either a lot of specific knowledge about how Linux initializes – but I don't have this knowledge – or it's rather very global, basically saying “it's a glue between kernel and applications" (I thought that the kernel was already a glue between hardware and applications, why another glue is needed?)
So I would want to know:
1. Why there's a boot process? A PID 1? Why do we need either init or systemd? How it works? Some background that will help me to understand what's broken in sysvinit, and what systemd brings.
2. What was broken with sysvinit?
3. Why D-Bus is important and is an advantage for systemd?
4. What means the "RC" acronym we can see in OpenRC for example?
5. GNOME seems to use both systemd and network manager, but systemd have networkd. Don't they overlap?
6. Some talks about shell being slow? What's slow in shell?
7. One of the systemd developers did a comparison with other init systems. However, a lot of the boxes was talking about features I don't understand, so a better overview of systemd enhancements will be helpful.
8. How can logind make a process logged in as an user? Via setuid? How does it works?
9. Why another glue is needed? Once you can run any complied program, we run an initialization system just to bring up features to other applications, or it's fully needed and we can't get rid of? Like could we run only a simple root shell instead?
You don't need to reply to all questions, you can just reply to some.
Have a nice day!
Do you want your keyboard and mouse to be automatically detected, configured and work across all applications? How about being able to run a program at a certain time? Or to suspend the laptop without typing your root password?
If so, then you need some kind of system glue or "plumbing system". Linux has many such "plumbing pipes" that makes life easier for both programmers and end-users. systemd is trying to improve some important parts of that plumbing system. That way systemd can offer really advanced security and resource control functionality like "kernel capabilities" and "cgroups". You don't have to code or understand difficult kernel concepts to use those features; just add a simple keyword in a text config file, like "ProtectedHome=true", and everything works.
Another problem systemd is solving, is the problem of the fossilized Linux plumbing system.
Take "cron" that allows you to execute programs at certain times; there isn't a "cron" development group any more, just fragmented forks of various old and obsolete "cron" implementations of eg. "Vixie-cron".
That means there are no way to develop "cron" to fix feature problems, because if you change your "cron" variation, it won't be cron-compatible, which leads to problems with coordination with userland programs.
So "cron" 2.0 has become "impossible". Instead distros chose to add more cron-like programs like "at" and "anacron" to solve the most glaring problems.
Same with SysVinit; you may make a slightly enhanced version, but you can't change it fundamentally, because then it wouldn't be SysVinit any more.
So you had this strange problem in Linux, that the Kernel and userland programs are being developed at a rapid pace, but some Linux "plumbing systems" were fossilised and unable to change.
With systemd, we can now have a Linux plumbing layer that develops at the same speed as the Kernel and userland programs. It is a huge advantage that there now is a hub of developers that can actually take user requests and translate them into new features.