Why Systemd is the Devil but I Love It - Chris Titus Tech
video description
Date: 2022-03-21
Related videos
Comments and reviews: 10
henningsplace
As an average linux user I understand systemd as a kind of resource and service manager.
Call it systemd or anything else, I don't see how any modern system would not be based on any kind of management (be it centralized or distributed) - except for completely human-managed -steam engines- running endlessly or absolutely minimal tinker and education things.
There are applications for -steam engines-, they are societal backup solutions, off-the-grid support systems, and important educational examples.
However, I was waiting for decades to have a scripted system foundation (what reminded me of punch cards) replaced by a system that deserves the name -system-.
It is increasingly complex what end user laptops must be capable of doing - a plethora of plug-in peripheries, user interfaces, cloud connections, streams, backups and synchronizations, data safety and security layers, repeated sudden sleep and hibernation triggers, multimedia connections, and many more. Anyone tell me s/he wanted scripted service startups / shutdowns that might be interrupted repeatedly by closing the lid - I wouldn't believe her/him. The requirements for modern systems are not anywhere near the ones for steam engines anymore.
The duplication of things is not optimal. My answer to that to the community would be: Audit and evaluate the architecture and standards of systemd, then fix it or fork it, then contribute to it - e.g. take the puzzle pieces (like grub, and other stuff) and either replicate them for systemd (when they are too old to re-use) or let them connect to systemd.
Binary logging - well - is a cosmetic flaw, not a real counter-argument.
Text configuration is probably important, though.
As an engineer I see scripting as crucial for prototyping. And many prototypes will be sold as products. But they are still prototypes for showing the core functionality of a potential, finished product. In many cases, prototyping never ends. That's totally okay, as it shows the development potential in a certain direction. But it's also okay to try to create intelligent, resource-managing, self-monitoring products for end users. And I'd absolutely love to see Linux gaining more momentum on end user machines while keeping them safe and serving them the purposes of their everyday tasks.
reply
As an average linux user I understand systemd as a kind of resource and service manager.
Call it systemd or anything else, I don't see how any modern system would not be based on any kind of management (be it centralized or distributed) - except for completely human-managed -steam engines- running endlessly or absolutely minimal tinker and education things.
There are applications for -steam engines-, they are societal backup solutions, off-the-grid support systems, and important educational examples.
However, I was waiting for decades to have a scripted system foundation (what reminded me of punch cards) replaced by a system that deserves the name -system-.
It is increasingly complex what end user laptops must be capable of doing - a plethora of plug-in peripheries, user interfaces, cloud connections, streams, backups and synchronizations, data safety and security layers, repeated sudden sleep and hibernation triggers, multimedia connections, and many more. Anyone tell me s/he wanted scripted service startups / shutdowns that might be interrupted repeatedly by closing the lid - I wouldn't believe her/him. The requirements for modern systems are not anywhere near the ones for steam engines anymore.
The duplication of things is not optimal. My answer to that to the community would be: Audit and evaluate the architecture and standards of systemd, then fix it or fork it, then contribute to it - e.g. take the puzzle pieces (like grub, and other stuff) and either replicate them for systemd (when they are too old to re-use) or let them connect to systemd.
Binary logging - well - is a cosmetic flaw, not a real counter-argument.
Text configuration is probably important, though.
As an engineer I see scripting as crucial for prototyping. And many prototypes will be sold as products. But they are still prototypes for showing the core functionality of a potential, finished product. In many cases, prototyping never ends. That's totally okay, as it shows the development potential in a certain direction. But it's also okay to try to create intelligent, resource-managing, self-monitoring products for end users. And I'd absolutely love to see Linux gaining more momentum on end user machines while keeping them safe and serving them the purposes of their everyday tasks.
reply
Oded
A lot of the things you say systemd has that are redundant aren't redundant - they are improvements and are better than the older packages that might be installed:
- resolved is better than dnsmasq because it understand more dynamic networking conditions such as wifi switching networks and having multiple interfaces were reach you have different upstream resolvers and different local domains - all this dnsmasq can't handle at all. It's great for other things, but not for very mobile devices that users carry with them.
- timers - this is one of the greatest achievements of systemd: ye-old crons can basically do per minute scheduling and if you want to do anything that is more accurate than that you are usually screwed. If you want multiple schedules - write everything twice. If you want to schedule for some time after boot - no can do. User schedules that only run when you are logged in - cron doesn't know about that. Schedules that are triggered by other services starting or stopping - you'd need to program then yourself. But best of all: systemd timers bunch up - if you trade off accuracy, you get less CPU wake-ups and save energy.
- systemd-boot is not yet mature, but it'll get there - it has better story for UEFI and secureboot and to support multiple Linux OSs in the save system and it will be used in the future. Grub has a lot of pain points and will die shortly.
You forgot to mention other great things systemd does:
- user services
- user mounts
- automatic remote file system mounts
- system slices and per service resource limits (not per process)
- nspawn
- machined
- socket activation
- bus service activation (great for user services, but also some system wide stuff)
Regarding performance - the -legacy- init systems are faster only when doing much much less than systemd. When you start a graphical desktop, dbus and all the other services, or you are running a server with multiple dependant services - in these use cases systemd is orders of magnitude faster - especially if you take advantage of socket activation (that most services do these days).
reply
A lot of the things you say systemd has that are redundant aren't redundant - they are improvements and are better than the older packages that might be installed:
- resolved is better than dnsmasq because it understand more dynamic networking conditions such as wifi switching networks and having multiple interfaces were reach you have different upstream resolvers and different local domains - all this dnsmasq can't handle at all. It's great for other things, but not for very mobile devices that users carry with them.
- timers - this is one of the greatest achievements of systemd: ye-old crons can basically do per minute scheduling and if you want to do anything that is more accurate than that you are usually screwed. If you want multiple schedules - write everything twice. If you want to schedule for some time after boot - no can do. User schedules that only run when you are logged in - cron doesn't know about that. Schedules that are triggered by other services starting or stopping - you'd need to program then yourself. But best of all: systemd timers bunch up - if you trade off accuracy, you get less CPU wake-ups and save energy.
- systemd-boot is not yet mature, but it'll get there - it has better story for UEFI and secureboot and to support multiple Linux OSs in the save system and it will be used in the future. Grub has a lot of pain points and will die shortly.
You forgot to mention other great things systemd does:
- user services
- user mounts
- automatic remote file system mounts
- system slices and per service resource limits (not per process)
- nspawn
- machined
- socket activation
- bus service activation (great for user services, but also some system wide stuff)
Regarding performance - the -legacy- init systems are faster only when doing much much less than systemd. When you start a graphical desktop, dbus and all the other services, or you are running a server with multiple dependant services - in these use cases systemd is orders of magnitude faster - especially if you take advantage of socket activation (that most services do these days).
reply
Kamil
It's an interesting topic, but really for people who just want to use a computer, it doesn't matter. If it works, it works.
As for the future of systemd, there is a chance that it may be what will make Linux a commercial competitor to Windows and MacOS. Systemd may be something that will unify the structure of Linux based systems and push it into the so-called mainstream. The way I see it is that systemd might become the top layer of Linux. As if systemd itself becomes the base upon which the operating system is built. Sorry for the analogy I'm about to use, but systemd in the Linux world may become similar to what DOS has become for Windows. Whether it's good or bad is a different story and everyone has their own opinion.
And if you care about my opinion, my opinion is that I don't care what happens. I just want to use my computer. After all, these are just tools, and the tools can always be replaced.
But I guess I understand that Linux today is an idea of --independence. And ideas are immortal. Almost.
reply
It's an interesting topic, but really for people who just want to use a computer, it doesn't matter. If it works, it works.
As for the future of systemd, there is a chance that it may be what will make Linux a commercial competitor to Windows and MacOS. Systemd may be something that will unify the structure of Linux based systems and push it into the so-called mainstream. The way I see it is that systemd might become the top layer of Linux. As if systemd itself becomes the base upon which the operating system is built. Sorry for the analogy I'm about to use, but systemd in the Linux world may become similar to what DOS has become for Windows. Whether it's good or bad is a different story and everyone has their own opinion.
And if you care about my opinion, my opinion is that I don't care what happens. I just want to use my computer. After all, these are just tools, and the tools can always be replaced.
But I guess I understand that Linux today is an idea of --independence. And ideas are immortal. Almost.
reply
GOD
-Old system:- kernel space --> user space
-New system:- kernel space --> system space --> user space
The whole idea behind things like a system layer (systemd) or universal package management (flatpak, snap) is to reduce the fragmentation of GNU/Linux. We've desperately needed standardization for years now and hopefully these will help boost development and adoption. The issue comes from the fact that these projects are spearheaded by profit-driven corporations such as Red Hat/IBM, Microsoft, Google, Facebook, etc who have way too much power and control over the direction of open-source and Linux. The main reasons we love Linux is because it's free, open, secure, and protects our privacy. But with these corporations having so much power and control over the direction of the industry, it makes it difficult to trust these things that they push on everyone, such as systemd.
reply
-Old system:- kernel space --> user space
-New system:- kernel space --> system space --> user space
The whole idea behind things like a system layer (systemd) or universal package management (flatpak, snap) is to reduce the fragmentation of GNU/Linux. We've desperately needed standardization for years now and hopefully these will help boost development and adoption. The issue comes from the fact that these projects are spearheaded by profit-driven corporations such as Red Hat/IBM, Microsoft, Google, Facebook, etc who have way too much power and control over the direction of open-source and Linux. The main reasons we love Linux is because it's free, open, secure, and protects our privacy. But with these corporations having so much power and control over the direction of the industry, it makes it difficult to trust these things that they push on everyone, such as systemd.
reply
Hudson
It's quite funny how some view those who oppose systemd as -haters-. I find that starting services with OpenRC is much simpler and the learning curve for systemd very steep. I could understand some of these people if systemd were a true init system, but it tries to do way too much. Much more than any other init system. Then you have the other problem - other OS components and programs that have hard dependencies on systemd. We have truly strayed from our Unix roots.
I started out on Gentoo back in 2007, returned to it in 2013, and have been on Artix since 2016 because I didn't have time to deal with system updates in Gentoo. Because Artix is also on OpenRC, it will be easy to chroot into my Gentoo system and do a massive update soon.
reply
It's quite funny how some view those who oppose systemd as -haters-. I find that starting services with OpenRC is much simpler and the learning curve for systemd very steep. I could understand some of these people if systemd were a true init system, but it tries to do way too much. Much more than any other init system. Then you have the other problem - other OS components and programs that have hard dependencies on systemd. We have truly strayed from our Unix roots.
I started out on Gentoo back in 2007, returned to it in 2013, and have been on Artix since 2016 because I didn't have time to deal with system updates in Gentoo. Because Artix is also on OpenRC, it will be easy to chroot into my Gentoo system and do a massive update soon.
reply
Stephen
The bloat is NetworkManager. The bloat is GRUB. The list goes on. In both those cases systemd offers a cleaner simpler interface to these fundamental functions. The fact that some people want to use their same old same old and install them automatically does not mean the systemd implementation of those services is bloat or redundant.
Some things are ridiculous, sure. Systemd-resolve? Whatever. What is wrong with a hardcoded resolv.conf?
reply
The bloat is NetworkManager. The bloat is GRUB. The list goes on. In both those cases systemd offers a cleaner simpler interface to these fundamental functions. The fact that some people want to use their same old same old and install them automatically does not mean the systemd implementation of those services is bloat or redundant.
Some things are ridiculous, sure. Systemd-resolve? Whatever. What is wrong with a hardcoded resolv.conf?
reply
Entelin
systemd is a tool in search of a problem to solve. Many of it's parts are under documented and worse versions of other tools, so it's just extra crap. As for the rest... complication is the real enemy. If you can have a 20-30 min video that explains the basics of systemd, then that's the real problem. Here's my video on init.d: Put scripts in /etc/init.d, symlink them into a runlevel, done, you understand everything, simplicity is power.
reply
systemd is a tool in search of a problem to solve. Many of it's parts are under documented and worse versions of other tools, so it's just extra crap. As for the rest... complication is the real enemy. If you can have a 20-30 min video that explains the basics of systemd, then that's the real problem. Here's my video on init.d: Put scripts in /etc/init.d, symlink them into a runlevel, done, you understand everything, simplicity is power.
reply
Jordan
I don't use the systemd bootloader, per se, but I do use the efi stub to build a unified kernel image that is signed for secure boot right into a prompt to unlock FDE. I'm waiting for my next weekend to implement TPM2 key storage and make the whole process faster and easier. I'm not worried about the Feds seizing my hardware and delaminating ICs to break in, so I would like to have the key storage implemented.
reply
I don't use the systemd bootloader, per se, but I do use the efi stub to build a unified kernel image that is signed for secure boot right into a prompt to unlock FDE. I'm waiting for my next weekend to implement TPM2 key storage and make the whole process faster and easier. I'm not worried about the Feds seizing my hardware and delaminating ICs to break in, so I would like to have the key storage implemented.
reply
Robbie
From an interview with brian kirningham, unix used lots of small programs instead of monolithic ones due to the hardware restrictions they had with the pdp7 and later the pdp11. But we dont have the same limitations now so im thinking -why would monolithic be bad?- Am I missing something? Not trying to be a jerk im honestly asking cause im new. I dont even have stubble on my neck yet lol
reply
From an interview with brian kirningham, unix used lots of small programs instead of monolithic ones due to the hardware restrictions they had with the pdp7 and later the pdp11. But we dont have the same limitations now so im thinking -why would monolithic be bad?- Am I missing something? Not trying to be a jerk im honestly asking cause im new. I dont even have stubble on my neck yet lol
reply
ulfen69
Systemd boot helped me when I just could not get my laptop working with grub. There was several solutions for grub. The next one more complicated than the latter.
For systemd there were three steps. Not complicated. Then I had my laptop running.
So next time if grub doesnt work. No more: - I just say welcome to Systemd boot. -
reply
Systemd boot helped me when I just could not get my laptop working with grub. There was several solutions for grub. The next one more complicated than the latter.
For systemd there were three steps. Not complicated. Then I had my laptop running.
So next time if grub doesnt work. No more: - I just say welcome to Systemd boot. -
reply
Add a review, comment
Other channel videos
