It was initially sold as a modern replacement for SysVinit, taking advantage of Linux specific features and not caring about portability. It was based on Apple's launchd, providing demand driven daemon startup for faster boot and lower memory consumption.
systemd-init is the init system part. Do you mean by that that you find it too big ? Or systemd in general. Also well I think it was easier to unify certain parts and one of the reason it grows is because of some service dependencies notable: - devices (some services might need a specific device to be there to work, like drives for partitions) - mounting points as some service might use a path not mounted yet if started to early, in the other case you need to wait the mounting service to mount ALL services (telling the init system for each mounted device would be doing the same as systemD) - networking (especially if you need some NFS mountpoints as it requires you to have your network set up) For journalctl well this one is an kind of an odd one but basically having the same project managing the logging system and the init system allows you to get log from before the logging service as been started However effectively some project benefit less from being in the same unique project in my eyes - The login system as it can be a regular service from systemd with other services like agetty requiring it - The boot system as most distro use grub anyway So yeah the main part of systemd is still it's init system a lot of parts are just integrated directly with it at it make things easier/allow to boot faster, however some are a bit odd to be in the same project for me
@@HinaraT you're totally ignoring the personal factors that caused anxiety, see the developer issues supporting real users, lacked tact, to understand the scepticism search "Pulse Audio has broken my sound". The controversy was never purely technical, but the result of past history, so an embrace & extend with massive mission creep by a developer not known for sympathy for real user issues and requirements was not unsurprising.
@@imwacc0834 To be fair systemd is large and modular. Essentially what people call "systemd" isn't one piece of software - its like a dozen. It's also a fantastic piece of software from a user perspective and a sysadmin perspective. It really empowers the user and simplifies system management. Shell script hell is a real place, and I don't want to go back
I'm perfectly happy with SystemD and also truly hope that alternatives continue to be developed and actually maintained because having _no alternatives_ on the backburner is what's scary.
I am happy with it too. It's a really great open source project. However, just to inform you, it's called systemd, not "SystemD" or "system D". Those are completely different things. It's the same d as the one at the end of any standard Linux or Unix deamon name. I think to problem is the lack of choice indeed. Gentoo does this right by letting the user choose what they want. A lot of Linux and Unix hobbyist want simple to use init systems and that should not be such an issue. However people blame systemd for a thousand things which are just objectively wrong. The whole bloat argument is part of that in my opinion. Systemd is a large project, but so is the Linux kernel. And both are modular in structure. I don't see the point of those haters. And my personal experience is that the system boots faster with systemd than with other init systems, because systemd does everything in parallel a lot. People don't seem to get that point.
I feel the same way. I've learned a bit of how to use systemd but I still have a long way to go. Then maybe I would like to test out runit and OpenRC as those seem like the most popular and developed. I'll probably not use them in the long run but it's nice to know they are there for systems and projects that want or might even need them.
launchd is what sparced systemd. because it's not a bootscript replacement , it's a system layer like MacOS, BSD and even windows have . They all use a system service/demon. The haters of systemd just don't get how modern os are built.
@@TremereTT some of the worst problems of modern OS's are a result of everything being a daemon though. It's an inherently wasteful solution that is also very convenient, and that is an unavoidable tradeoff. Some things you basically have to run as a daemon or you will be forced to restart the OS more often than people are used to now. But systemd is imo not configurable enough to manage that tradeoff well. For two examples, CUPS and Tumblerd are both aggressive because people expect their printers to respond quickly and reliably, and their thumbnails to show up. But for me they are both incredibly annoying. Tumblerd crashes all the time because it's bad. CUPS is just a security nightmare and way too aggressive, making a mess of network logs. But your only solutions are to uninstall them and lose those functionalities or deal with it. They don't have configurability to balance out their problems, which is not "the linux way". So I think criticisms are perfectly fair. But as always you can't really complain about FOSS.
At launch, systemd was in some ways so far behind the competition that it never should have got off the ground. At the time, I knew a supercomputer sysadmin who, of course, had to work with huge log files, often 2GB or more. It took off because enough people blindly swallowed the lie that binary logging means faster log searching. The truth is that fast search comes from good search algorithms which grep has and which systemd absolutely didn't. My supercomputer sysadmin acquaintance had a hard time until he found systemd can be configured to log to sysklogd. For starting and managing services, experienced sysadmins found Debian's little program, run-parts, to be all they need. For managing udev nodes, systemd might actually be the best thing, but the problem here is udev. Every other operating system, including the BSDs, have better solutions than udev. The problem here is Linus Torvalds insistence on "no policy in the kernel," so device management has to be pushed to userspace where it's hard to make it work well. However, I've heard mdev is easier to work with than udev, so even here, systemd isn't the only choice. Systemd exists because the vast majority of open-source fans do not test and verify information.
@@n.m4497 I have 2 issues with Lennart Poettering: He's employed by Red Hat and his work seems to bring unnecessary complexity. Amongst fans of clean code, Lennart Poettering is known as someone who can't express himself succinctly in code or words. Complexity is sometimes necessary but not as often as you might think, and I think Red Hat have introduced a lot of unnecessary complexity into Linux via Lennart Poettering and others. Besides this, I don't like Poettering because he's employed by Red Hat. Back in '98 when I was just getting started with Linux, Red Hat were a huge impediment to me as they tried to make Linux very hard to administer without a Red Hat support contract. Between the influence of Poettering and other people who don't have the intelligence to simplify things, Linux has become the hardest OS to administer by quite a margin, worse than the BSDs, worse than Windows, absolutely worse than old VMS, and sysadmins get paid the least.
I think you missed the main underlying problem of systemd. A lot of other programs interface with systemd components and are thus dependent on it. But since the systemd interfaces are not based on a standard, but instead just made up as they go, it's impossible to create a program to replace a part of systemd. It's similar to the rust situation where there is one official compiler implementation. And that compiler implementation basically decided what the rust standard is. But they are working on a standard definition to make it possible to create other compilers. If systemd would make standards for how interfaces with an init system should work, all concerns with systemd could be resolved by replacing parts of it with alternative programs. But systemd is not incentivised to create such standard, since it would mostly benefit systemd alternatives.
systemd is under no obligation to standardize anything either, it costs massively and carries no benefit, that's something others have to push for and actually make reasonable standards that then can be adopted into systemd and at least some of the other init systems. If one is not pragmatic and methodical with it, its a waste of time, and there's not much point if the software users don't push for it.
@@Spartan322 Yes, it takes a lot to standardize things, see for example wayland. And it has to be evaluated if it's worth it for our init systems. But I believe that at this point it's the only reasonable way that there could be systemd alternatives, without burdening all applications that rely on it to change
I doubt having a standard or not matters. systemd is pervasive -- that's the main complaint. Even if the interface was a "standard", it would still be an opinionated and systemd interface. You could replace the code behind the interface, but you would still end up with "systemd", just an alternative implementation.
the same can be said about linux, It's just been made up as they go, it just kinda respects POSIX. At the other side of these stories we have C++ which the standard moves faster then the compilers. or ECMA which is years behind Typescript. Until people just realize and implement a better way to do the same things as it does, there is no point of having a fight over it's ways. And complete interoperability it's hard to achieve
My biggest frustration with SystemD is the fact that so much software has gotten coupled to it. It's frustrating how much extra effort it takes (with my level of skill) to set up another init system and be able to trust that I'm not breaking my system or my applications in some obscure way. I like working with SystemD most of the time, but I don't want to be stuck with it!
Because the vast majority of people knows absolutely nothing about tecnology they dont take it serious, so we'll end up stuck, and it will be used against users/consumers, like always happens...
@@RobBCactive I don't want to be rude, but if I were you, I wouldn't pretend I know what means to fork a project like this. Specially to minimize wrong behaviours.
@@jfolzI would not dare to call systemd a "really good piece of software", and while it did solve issues that sysvinit had, so did openrc and runit (and nowadays s6). it was an alternative for which some low level packages (and high level oned now) started to have hard dependency on (hi gnome and udev).
One of the most compelling arguments against systemd is the topic of debugging errors that prevent systems from booting. With init daemons you could add a few echo lines or comment out lines you suspect being problematic. that and the fact, that logs are stored in a binary format - who wants to open dedicated "apps" when you have the shell available?
Systemd was sold on the myth that searching binary logs would be faster. I used to chat with a supercomputer sysadmin at the time, and he found systemd's binary logs impossible to search because its search tool had a poor search algorithm. Grep was far faster. Fortunately for him, systemd's logging facility can be configured to output plain text to good old sysklogd. Personally, I have mixed feelings. Initially, using the shell was a huge relief after dedicated apps, but in the end, there are so many tasks where you need a program to do something from the shell, and that program is just as likely to have poor documentation and a poor interface as any app. I could rant about it, but I'm done ranting for the day.
@@lucass8119 That is a DEFINITE non-argument. Syslog has always been full text, even in the days that the space requirements for a MB of storage was measured in cubic feet. In fact, it is my greatest gripe with systemd, that I have to use special tools and search for the logs that I want, instead of a simple `grep`.
@@TheEvertw Well its not a non-argument because its not an argument, its a fact. Binary logs are smaller than text-logs. That doesn't mean they're better, as I've already stated. Take a seat.
@@lucass8119 You should study the UNIX philosophy a bit. Storing data in human-readable form is a basic tenet of UNIX. There are many reasons for it, have a read in e.g. "The Art Of Unix Programming" to learn more. "take a seat" -- pip squeak thinks he is being clever. You only display your ignorance.
I think the only concern is that so many apps now require systemd to function, making more work for distros using other init systems. If Devs would leave the choice of init system open when making apps it would be less of an issue
It's becoming a problem on BSDs and other Unix-like operating systems too. Much like cgroups, PipeWire, and Wayland. But this is just Linux and, by extend, some distributions of Linux being too influential. It's not going to change anytime soon.
Centralization is probably the main concern, especially with how much Linux has appeared to favor decentralization. It's kind of what makes Linux different from the big boxes. S6 is pretty cool and a great alternative used by Artix, which is basically Arch without SystemD. It's a fast distro, gaining popularity, and, though you have to be careful what you load, you can use the Arch repositories for to add programs and do updates. Devian/Devuan has a few non-SystemD distros worth trying out. I'm still not sure about installing into RAM, but for some of my old laptops with dead hard drives, it does propose a unique possibility for giving them new life. Just trying out all the options out there is part of the fun of distro hopping.
This is kind impossible without standardization, which people who are actually bugged by this issue need to actually push for, a solution doesn't just come by saying "it should be this way", someone has to actually make it, else you just get de facto standards that everyone has to emulate because its completely infeasible to support every system, any developer should already know the hell that is trying to support everything the user does, (also you shouldn't expect the systems themselves to do it because its more work then building the system itself and unless you need it, nobody actually benefits) much like how pipewire emulates pulseaudio and jack, and kinda like how Wayland compositors are trying to emulate X11 specifically. (you see, without standards, you have to emulate the de facto standards, this is extremely common in Linux)
@@Spartan322 I can't help but wonder what might have happened if the Community came together back then, to improve one of the existing inits in a way that would be similar to systemd, but perhaps not so monolithic and community developed rather than red Hat developed?
@@MrOrtmeier Eh the result would've been mostly similar, systemd came up out of need, if something was being made at the time that was FOSS, Red Hat very likely would've considered backing it instead at the time and it would've still become monolithic because it would be the most common and easiest to use init system, what happened with systemd is just an organic result of building for general user cases, you can see it with every major user focused platform, the only way it wouldn't is if you sabotaged Linux adoption to the common man.
There are a few things which I would consider bad about systemd: - the way they handle certain security vulnerabilities (to a point where their "solution" is sometimes "we don't care what POSIX says about it") - some projects even when they are older, suddenly start to hard depend on it (like udev which quite a lot of projects depend on is these days part of it) - some implementation details (I straight up dislike the design of journald, but considering how hard-depend the rest of systemd is on it, I can't just jank that out and replace it with something else (as literally the only component of this project)) - hard dependency on glibc (this is actually one of the reasons why some distros don't use systemd); they depend on a specific libc implementation so you can't use better engineered ones like musl (don't get me wrong, a lot of the reasons for why glibc is in its state is age, but there are also other reasons like their own extensions to a point where Microsoft would blush at that); and since you can't statically link glibc (no seriously, if this works properly for your project, you got lucky), it quite complicates things for some embedded projects (ever heard of few application Linuxes?) But I also like quite a lot about systemd: - unit files - it often uses symlinks where other projects would have config files - custom targets (which let's you do quite interesting state management stuff in a pretty easy and reliable way)
systemd targets is a very neat and good idea. I would love projects like openRC to have that instead of runlevels. Though systemd's init system is really terrible for anything else. On most inits you can just go to the script, append && and do things like preloading files for faster init
Anyone who touched a minimalistic embedded Linux system knows the third biggest init system out there: busybox/toybox. If you really wanna keep your system "bloat-free" for an embedded device, where your available internal memory might be measured in megabytes, a custom minimal kernel with barely enough drivers to boot a terminal and a busybox/toybox init is the way to go. This is an advanced configuration where you sacrifice any semblance of general compatibility and standards though, so most people are better off trusting systemd and their big distro kernels. Even servers don't use this kind of config because the management options systemd provides are too good to pass up, and well worth the (fairly low) security risks.
@@kelownatechkid If you know what your doing you don't need docket to run cloud apps. Docker isn't better than traditional hosting, it's just different. You're replacing old problems with newer. But I hate designs where apps ship their own dependencies. You don't just ship all your dependencies, because if you do, your responsible for the security of every component you're shipping. So have fun managing all these dependencies daily. I feel like many forget the responsibilities that come with shipping software, because a dependency doesn't just offload problems, it also offloads responsibility.
I'm don't really care that much about init systems, but after switching to MX Linux, I have started to see SystemD from an outside perspective. There are two main problems I see with it: 1. Every tutorial and guide assumes you use SystemD 2. This next point is kinda hard to put into words, but SystemD has became a sort of "default Linux OS." I feel like it contributes it the idea of having a default Linux experience. I just don't want to see a future where we unironically use the term GNU/SystemD/Linux. The software is perfectly fine though, I just don't like how it changes the way people think of the Linux software ecosystem. *DISCLAIMER FOR KEYBOARD WARRIORS:* I'm not here to start arguments, debates, or discussions. I'm just thinking out loud and sharing my perspective for anyone who might not have thought of things from this angle before.
Is point 2 a bad thing? I can understand there are benefits from keeping few alternatives alive, but for overwhelming majority of users, it's probably way better to have a solid "default linux" as foundations to build on.
@@ahettinger525 This approach (if true) is kind of moot if the end product is foss, isn't it? As I've stated previously, there are benefits from parallel development of alternatives, but where is this huge problem with having one "standard" version? It could be argued, that having Linux as "standard" for servers, has very similiar issues. Where is the difference?
When a scalpel is needed, Lennart Poettering has a tendency to use a wrecking ball instead... and then expect everyone else to rebuild in his wake. Systemd was his biggest wrecking ball.
Hi Nick, first, THANK YOU for such a detailed explanation of arguments against systemd , I always understood the mood towards it but never understood why Second, PLEASE do pulseaudio next! It was also made by Pöttering and I personally believe it sucks even in 2023 😢
I look for distros using Pipewire because low latency matters with my workflow in music. Gaming also can get a boost from it as well. However, AV Linux boasts of being able to have low latency, claiming to have the 'correct' setup of Pulse Audio, and I can't help but be curious what they are doing that countless other musicians and sound folks have split hairs on when it comes to getting Alsa, Jack and Pulse to 'play nice'. 😏👍
I wish there was something like freeinit just like Freedesktop so that we could have interoperable init systems and it wouldn't be a concern to replace anything. I think people are more afraid of systemd becoming irreplaceable than other non-fundamental excuses.
Systemd isn't irreplaceable at all. How do you explain existence of Devuan, debian based distro that uses sysvinit? Devuan even supports upstart and other init solutions.
@@Beryesa. in linux world nothing is certain due to its open source nature. Sysvinit may be older init system but there is nothing wrong with it and can surely be used in latest distros without any problem at all. If Devuan is using sysvinit it means somebody is still maintaining it, same thing may be with upstart and other solutions offered by Devuan and other distros that follow same path. If i want to i can tear debian's current iso and just replace systemd with sysvinit, upstart or any other init solution listed on devuan's page, i am not obligated to use systemd if i don't want to.
I love systemd in such a way... It unifies all kinds of system services. Timers, mountpoints, swap... It makes it easy to manage the system. Program logs are written in the journal, so no need to look for specific log files to find a problem. Also, programs can trigger a service as needed, which means no backgroud services running indefinitely even if it is not being used.
Totally agree! I also love that you can totally isolate your systemd services, limit RAM, cpu, drop capabilities and change mountpoints. It's very versatile. I also systemd-networkd to be the only good enough solution to configure my complex networking setup on my router.
Creating a service is so easy with systemd, yet you can have very fine-grained control over how it behaves, what it can and -- more importantly -- cannot do. But what I like most is the journaling system. People like to hate on the binary file format, but at the end of the day you can't read the bits on disk either without some tool to turn them into legible characters. journalctl is that tool for systemd logs. The advantages of journald are too numerous to ignore. Services don't have to manage log files. Just print and it gets logged, including an accurate timestamp. If you need logs for a specific service/unit and time range, you can get just those lines very easily -- no need to search through multiple rotated file, some of which are maybe gzipped. There's no need for any of that nonsense, since journald can compress logs, and clean them up while keeping a specified amount of time or data.
@@jfolzThe problem is not that it needs a tool, but a specialist tool, I could read old syslog files on windows even without specialist tools. But also look at what the initial implementation did to kernel logging, a problem the kernel developers had to go fix for them. That said, it is much better now than it was, a lot of the hare is actually quite old or out of date.
I run Void Linux with runit. In my opinion, systemd isn't too bad (I run Arch on one of my other systems), but I prefer the simplicity of runit. There's barely anything to lose when switching from systemd, and lots to gain. My PC only takes about five or six seconds to boot to desktop, and it's certainly worthwhile. I encourage anyone to at least try an alternative to systemd, and see if it's for you. But again, it really doesn't matter at the end of the day. If it works for you, then it's fine. Void and runit works better than systemd for me, but it may not be necessarily for you.
4:05 I always see this argument in places like reddit and it's always by sysadmins and powerusers, but I can assure you you won't see a developer say this. If most components of systemd have hard dependencies on each other then it is not modular, even if they are different binaries. Thats why we have entire desktop environments having systemd as a hard dependency. And let me tell you there is no reason why a DE needs to have an init system as a hard dependency.
Honestly I didn't really know about the hate of systemd. I've been learning and using Linux for 3 years now, and pretty much most of the distros I used use systemd. And I haven't had a problem with it.
@@Stevexupen There's definitely some technical details that turned people off initially. One thing that isn't mentioned is that systemd is aggressively Linux specific, meaning that the portability principle of Unix projects isn't being honored in this project. There's a ton of advantages to this approach (use of C groups is the biggest Linux-specific item that I'm aware of), but it still isn't a true Unix project. I think the main reason people don't like this project is that the conversation around it became wildly toxic. From what I understand, Poettering was a little glib in addressing criticism, and in return he started receiving death threats. The whole thing turned quite ugly after that, with people drawing battle lines based on ideology rather than usability and technical viability. To be clear, I wasn't around for the holy wars, so someone else here might have a better insight into what was going on at the time.
@@Stevexupen one main issue is the blatant scope creep (modern init system -> service manager -> system layer -> ... ), for example it now has a bootloader.
Great video Nick. Your high level approach to explaining why I should not care that my distro uses systemD is comforting after reading all the hate systemD gets online. Now I can continue my use of linux distros with one less thing to worry about. Thanks!
I don't have a problem with systemd per se. Its core functionality as a system service manager has always worked well for me. Yes the configuration is more extensive but it does a lot and has a lot if flexibility. My biggest issues are with some of its support functionality. The whole journald subsystem uses tonnes of memory and is redundant with *syslogd. Resolved is 100% broken on 100% of my systems 100% of the time and gets removed immediately on every install. My biggest concern is that it seems to be subsuming subsystem after subsystem that has perfectly viable alternatives. While resolved can be removed easily, I havent found a way to remove journald.
Yup. resolved is borked by design. However, it gets _reinstalled_ every major OS upgrade (now with cloud-init integration which performs magical at-boot updates to files in /etc, so that stinks even more), so I recently gave up and just did a search on how to correctly configure upstream DNS servers in it and let resolved do its thing so I never have to deal with it ever again. Do I want resolved and syslogd and a good chunk of cloud-init to vanish? Yes. Am I going to waste hours of my time every two years to figure out how to do that? No.
Correction: why has systemd _ALWAYS GOTTEN_ so much hate. It was imposed in a top-down fashion on the entire Linux community by one entity (Red Hat), and the developers who did it treated everyone else like garbage and had piss poor attitudes. Now the main author works for Microsoft. It's the Microsoftification of Linux. And you basically swept the serious security concerns under the rug like they almost don't even matter.
It didn't get pushed "top down". Red Hat adopted it, because of course they did. For an enterprise environment it makes perfect sense. It is simply the best and most productive experience for a sysadmin - and it's not even close. Regardless, other distros did use alternatives and had the opportunity to use anything else. They CHOSE systemd, all of them, independently of each other. They literally all chose to abandon other solutions in favor of systemd. As for the security concerns, I do think there is some truth. But I also think its a bit overblown. People act like systemd is this huge monolith piece of software, and thus is a huge security concern. That's not the case. "systemd" is actually, like, a dozen pieces of software. And, even without systemd, other init systems need to have privileges and power. They can ALSO be attack vectors, to the same scale as systemd. Simply switching systemd-init for upstart doesn't change anything. And, the large adoption of systemd helps its security. It's being contributed to from a lot of places... which is good.
@@liquidmobius Are you gonna elaborate further? I mean, its not like red hat held debian distributions at gun point. They chose systemd, willingly. Fedora, maybe not.
I give you one example: There was a time when systemd made deliberate choices to exhaust the Linux kernels random pool for totally arbitrary tasks like creating device uuids at boot. This basically meant that when the system was booted, not enough rng pool was left for critical tasks, e.g. in networking. There was a big clash between the kernel (Ted) and systemd (Lennart), because the practice was actually doing widespread harm. systemd insisted it's not their problem the kernel can't provide a faster high quality rng stream. It was utterly ruthless behaviour. The distro I run (systemd early adopter) reverted to use haveged, a daemon _seperate to the kernel and systemd_ to gather more rng for the kernel, for years. And it's just one example. It's very easy to pinpoint other issues. I can pinpoint critical issues that get finally fixed in v255, but have been denied for 5+ years. There are a lot of great people contributing to systemd and it's super innovative and brings Linux forward. Frankly, I also can't understand how much work Lennart himself shoulders. Yet, the forcing upon the community was an issue, and you won't convince me that attitude problem is totally gone.
This was hugely helpful, thanks. I came to Linux in 2009 and was oblivious to all the drama over SystemD until just a few years ago, but couldn’t find any good explanations of the problem. This is the best concise explanation I’ve seen yet. Gracias!
I use two different systems with OpenRC (Gentoo) and systemd (Arch). It's a bit of a pain to keep the commands straight between the two systems. I'm quite used to OpenRC. The only gripe I have is that many things are spidered into systemd.
@@1DwtEaUnI seriously hope that doesn't happen. I don't use emacs. I prefer vi and a kernel being merged in would be no different than Windows. It seems we're headed in that direction considering Lannert works for Microsoft.
The systemd project is actually one of the main reasons why I moved to FreeBSD. Also, because many Linux distros change for the sake of change…like ip, instead of just keeping with ifconf.
The issue with Systemd was always that you could n't simply use only one of its components without also using systemd-init. We still need (kinda) forks of logind and udev because neither works without systemd-init. (Debian used to use Systemd-shim to be able to run alternative init Systems). And their Attitude towards fixing certain (minor) security issues because 'If you use a sensible configuration, you wouldn' t be able to Do that' (which were the reasons I was using artix for a few years) But I Do admit that it doesn't matter for most users.
Biggest criticism of systemd is it's linux only nature. Before init systems were also supported on other platforms like BSDs, Solaris, etc. This meant many applications that would interact with the init system (e.g. desktop environments, login managers) could support more platforms with less effort.
10:31 if people think it's an attractive target for attackers, they shouldn't use Linux. The Linux Kernel is the most used OS Kernel in the world and probably the most valuable target that exists.
Good explanation. I'm an old-school (early '80s) *nix user/admin, and I my main objection to systemd was "why are you making such a fundamental change to a system that works and is well-understood?" "It's old." is not a good reason. In the end, I end up using systemd because the distros that have the capabilities I need are using it. Otherwise, I'd use BSD.
The main thing that draws me to alternative init systems (runit specifically) is their speed. I used to have relatively low-spec hardware. Because of that the speedup in boot time runit gave me was significant. It went from 2 minutes to just under 30 seconds on a cold boot. Right now it is less relevant, as I actually own modern hardware now, but still, a pretty big difference for me.
Back in 2001, I got a huge improvement in boot speed by writing my own init scripts. :) There weren't many options for init in those days. What I didn't have was proper service control, particularly restarting crashed services but not if they keep crashing. I think Debian's little program, run-parts would have given me that, but I wasn't online and I didn't have any Debian CD-ROMs, so I didn't have it.
@@EvoraGT430 Me who hasn't booted anything but Knoppix for years: ... ;) Even running from a memory stick, 2 minutes would be remarkable for Knoppix. It's got such a gnarly boot process!
I've been using Linux since last century. Before SystemD there was all kinds of "sub init processes". Things like serviced and others that could monitor services and restart if needed. I remember, "oh, that uses xyz to manage the services" so try and remember their tool. SystemD came along to unify things. Where the hatred came was all of a sudden there were tons of systemd services. This was happening anyway as the desktop side was pushing all kinds of stuff into init services. Systemd was there to accept these services across distros. Without systemd, the other init services would have also had these apps anyway. When systemd first came out, it was a mess of half systemd and half init.d services. Management was a mess. Now systemd can automatically manage init.d services with no manual config. Now, I have had no issues in years across several distros. BTW, MX Linux can boot in either init.d or systemd mode. Tried both ways and boot times were about the same. In init.d mode, it starts all the same services. Like you, I don't care as long as it works.
I agree with your take / clarification of his take - but implied in here (that I think you'll acknowledge) is that while systemd is better than the previous initd, etc situation, it is still a mashed ball of previous solutions and some other stuff with some really good lipstick, and maybe some spanx, on it. It could be a lot better, which is why there are complaints. The complaints are justified because while it works, it is still a mess on the backend. I'll walk back "mess" even, I think it has been reworked a lot, but it started from such a mishmash that it's still messy. If you were buillding a services framework from the ground up you would not choose to structure it the way systemd is organized. I think that is a fair criticism. And I also think that relying on an private company to maintain this amalgamated mess is inherently dangerous, even open sourced, because if they ever choose to stop maintaining it, the backend complexity will make it a nightmare of little boobytraps for others to take up. I'm not calling on anyone for a solution right now, but a lot of other posts are being extremely aggressive about 'defending' systemd and sounding a lot like "it still snows in Montana so global warming isn't a problem" logic. Aggressively denying things are heading in a bad direction is such a bizarre human behavior.
@@craigslist6988 Yes, if started from scratch now, it would probably be simpler. I do see more things becoming consistent (mostly gone are started by systemd but managed elsewhere.) Not too concerned about RH heading up the project. Having a core group from one source would focus things in one direction. As Nick said, if they close it, a fork will immediately start and continue. But it may end up going is several directions. I don't defend it other than it solved some problems with management. Due to all that was pushed into it, it has become the 600lb gorilla we have to appease. This "everything is a service" idea has bloated all init implementations.
@@craigslist6988 If everything is now unified under the systemd umbrella at least there is hope for improvement. Initd with its mess of distro/installation/login specific hacked up scripts probably stood no chance of further improvement.
There are two major problems with systemd. The first is technical: systemd starts multiple processes at the same time. While this can significantly reduce boot times from cold boot to a running system, it also means that repeatable boots are nearly impossible to achieve. This has consequences. Particularly for servers. Servers need to have consistent bootup sequences because they need to be reliable. This can lead to very difficult technical problems that cannot be easily solved. For example, systemd does not cleanly reboot a system on certain motherboards. This behavior requires going into a remote control panel connected to the system to hard reset the system remotely about 20% of the time that the system reboots. The second problem is Lennart Poettering. A man who wrote and maintained the PulseAudio drivers for Linux. Audio support on Linux is notoriously bad and Lennart didn't finish what he started. If you started building a house and then the contractor you found decided to stop building your house halfway through the project and instead goes over and starts building an office building across the street, would you trust them to complete either project? I wouldn't.
Lennart is a huge part of the problem. I cannot dismiss how prolific he is as a programmer, but he has repeatedly shown that he does not care about any practical concerns and systematically rebukes any and all criticism, constructive or otherwise. Lennart does his own thing and seems to believe everyone else is too stupid to appreciate his mess.
This example makes no sense. The office building across the street (systemd) would is usable, and occupied by all the largest corps, using it to make billions. lol
I had issues with systemd, it was preventing me from shutting down my system. When I'll install Linux again, it will probably be a distro without systemd. I am thinking Alpine Linux.
I get a little weird when I don't have config files I can look at, even if I only ever adjust those settings through GUI. It just makes me uncomfortable that wherever those configurations are being stored, they're kinda hidden. It just gives me WIndows Registry flashbacks. I know my brain is wrong for that association, but I can't help it.
I don't have the energy to go fight system-d, but I heard criticism if you have a problem and need to troubleshoot it, everything is now binary instead of plaintext, I understood sysv init systems, how to edit, and manage it. Faster boot times are not an issue with SSDs really. The CLI for systemd is ass-backwards if you learned service control cli before systemd. I should be able to say systmctl myservice status/start/stop/restart etc. I tweak my linux less now and haven't had to debug startup issues in forever so I guess it is what it is. I don't particularly like systemd but it also has mostly just worked. I just feel like i don't know what I am doing any more in linux. It's some voodoo thing and I'm paranoid about IBM exerting too much influence and breaking linux.
It's systemctl [, ...] it allows you to simultaneously interact with many services. And if that's so high on your list of criticisms, then I worry how you cope with changes in life in general.
I've compared the startup times and systemd is not the slowest, but it isn't the fastest, either. MX Linux boots faster than Debian, Ubuntu, Linux Mint, and LMDE, but I don't know how much of that is from the absence of snapd for some of those (Mint boots faster than Ubuntu, and so does LMDE).As Nick said, a lot of it is down to package and distro maintainers and their implementation choices. A lot of SysV, OpenRC, S6, and other old school style init systems can for sure be configured in a bloated, slow booting manner, same as systemd. I don't have a preference either way, I just happen to like the rest of the system in a lot of distros that don't come with systemd (MX Linux, AntiX, PCLinuxOS) but I like plenty that do come with it, too (Debian, Q4OS, Mint, etc)
For security implications, it's important to consider not only attack surface but also attack leverage. Say you have a process which is an everything-server, and it runs as root. You split it up, and you place the different servers into their own users which can only access a limited amount of files, then although the system presents all the same ports and services to the outside attacker, its subsystems will provide much less attack leverage. Then also imagine you have a sharp admin and it notices unusual activity in a process and chooses to investigate; but if you have a single process which does everything and routinely accesses basically all files and has substantial blips of activity at all random times, then it creates a shadow in which illicit activity is easier to hide. I don't think security implications of systemd are relevant on a desktop and can be mitigated on a server, but one has to wonder whether it had to be that way whether that's actually good design. Cobbled together combination of scripts also has an advantage of not being written in C, a language with an abhorrent memory safety track record in spite of so much piled on tooling and sharpest attention of expertly developers.
In principle I have nothing against systemd, and I have used distros such as Debian that have it, and distros like Slackware that uses SysV. I am still on the fence on systemd and its improvements over a traditional init, but on the other hand I can understand why systemd exists, and to be honest the fact that someone just decided to write their own init system is rather incredible -- I would direct anyone to see Benno Rice's talk on systemd "The tragedy of systemd" , it is a rather interesting perspective. -- However I do not agree that other projects not related to systemd such as GNOME and others bending to the will of systemd.
Bingo. I think systemd in and of itself isn't bad. The problems start when projects like snap (which I don't really care about anyway) and GNOME essentially depend on it. This opinion is coming from somebody who uses Arch (btw) on a daily basis, which was one of the first distros outside of Fedora to adopt it. And no, I don't use GNOME, but not for that reason alone. (I use KDE Plasma because I prefer the vast options of customization and traditional desktop experience of Plasma. I don't use GNOME because I don't really like its workflow.)
I came to the comments to recommend Benno Rice's talk as well! It's a great discussion of both the technical and interpersonal challenges of open source projects. Oftentimes people, not technology, can create the most challenging issues to resolve.
@@cameronbosch1213 that's the choice of the other project, though. It's not like the systemd attack squad rocks up at people's houses and forces them to depend on it. It's just a really solid system layer that solves many very common issues.
Essentially everyone who ever wrote or modified init scripts was enthusiastic to adopt systemd, and almost all the people who complain about it have never written an init script.
imho one of the worst things about systemd is binary log files, it just requires you to use THEIR tools, you can't simply grep the log (or better yet, grep several logs at the same time), or setup a file watcher and e.g. send an alert to yourself whenever a critical error is sent to log (and you don't want to go about modifying all the code yourself, which could change how the program works) and I'm also not a fan of the unit file syntax, like the thing that finally pissed me off enough to switch init, was trying to setup 2 services, which would always be BOTH brought up AND brought down together, irrespective of one of them crashing or not, and such....can bring both up via a target file, but never figured out how the hell do you force one service to go down whenever another goes down...it's just so complicated system to deal with... but from a normal user perspective, it really doesn't matter at all, whether you do "systemctl restart nginx" or "sv restart nginx" or "service nginx restart", etc, it's all pretty much the same, the only difference is how it works on the backend, and how hard it is to write stuff using it I do love how minimal runit is, it's small and simple enough it's even included in busybox, and for vast majority of stuff, it is enough, and best of all, it doesn't care what your init scripts are written in, you can use shell scripts (what most people use), python, lua, java (lol who'd use java for startup scripts), some compiled code, whatever, it's up to you, no syntax to bog you down, yet there's a few utility programs to help you do fancier stuff
Funny, because IMO overhauling the log system (if you can call an unorganized collection of logfiles, some rotated and gzipped, a system) into journald is one of my most favorite things about systemd. My services can just print messages without worrying about anything, not even timestamps. I can get logs for many units from journalctl at once and they're nicely interleaved by timestamp. Beyond that I don't see any meaningful difference between grep /var/log/whatever and journalctl -u whatever | grep. It produces the same result with a similar number of keystrokes. I'd love it if everyone started using the journal. On our cluster at work, the promtail config is 6 lines for the journal (i.e., barely more than "please read from the journal"), and over 100 lines for the few logs that aren't in the journal -- mostly because everyone has a different opinion on what a timestamp should look like...
The security issue with systemd being used for a number of different functions that means that if systemd is exploited then all it's related functions are vulnerable. It would be more secure if a separate non connected process was used for each function. However this would likely impact function to some degree between interoperability and support.
Just leaving a comment to say thank you for this explanation. I use Linux but must confess that I dont know too much about it and I have wondered for quite some time about exactly the kinds of things you are explaining here :)
At 8:45 about the restriction in interest for other project, it's under systemd of course. If systemd does a bunch of things, that's a bunch of things that other projects aren't needed for. It's not about having competitors in the init-system department. (That whole section is completely missing the point and comparing apples with oranges.)
The biggest problem with the Linux community is there's a bunch of old guys who hate any change at all, and are so ideological about how things have been done in the past that they are unwilling to ever consider anything new might be better. We saw it with systemd, we see it now with Wayland. We're going to see it with every new technology that comes along and gets widespread adoption by the major distros. I think these sorts of people simply miss the days when Linux was very new, very difficult to get running, and they had to learn and know every bit of their system inside and out. They're very proud of the knowledge they gained, and anything that renders their existing knowledge obsolete threatens their ego in a very big way. They want the same old paradigms to remain in place forever, otherwise it feels like they've wasted their time and energy. It's basically the sunk cost fallacy. They'd rather spend oodles of time maintaining an old abandoned project trying to make it work when everyone else has moved on, than to drop the old thing and gain immediate benefits from something better. And frankly whining over kilobytes in an era of terabytes is a form of mental illness.
I don't have a problem with systemd, but I do have a problem with Linux-only elitism attitudes behind systemd. Lennart calling BSD a toy-OS... Kay and Greg trying to sneak kdbus into the kernel to deprecate netlink. Calling sysvinit deprecated when the project was never out of date and only in extended maintenance because little was needed. The fact systemd duplicates perp, s6, runit, and daemontools but shoves everything onto PID1 without a job fork to sustain PID1. The countless undocumented APIs. Trying to lock udev into systemd to prevent modularity of design by Gentoo and other distributions. There's a lot really that systemd developers have done VERY wrong. Their attitudes have literally caused a lot of hatred and distrust towards them and the project. The software isn't wrong and in fact is very good at what it aims to accomplish. It's gotten a lot better. The current maintainers have done a great job. It does make Linux easier to use and daemonize properly, but the fact orher distributions do the same with other tools is kind of saying, it's just another init system that does no more or less than the next. However, getting Kay Sievers, Greg Kroah-Hartman, and Lennart Poeterring to admit they were being pompous assholes towards the entirety of the UNIX userland space of applications all to favor only their distribution, Red Hat, is never going to happen because they're too prideful.
@@botnet3201I use Arch, and honestly, the way Arch implemented it is minimalistic. It works well for Arch. However, programs like runit, s6, and OpenRC get ignored far too easily. Skarnet who did s6 is pompous and arrogant as well, but one thing he says is right... and adheres to core UNIX-isms PID1 shouldn't be the end-all of the system, it should be forked.
systemd about the init system alone... why not... But systemd tend to grow and touch everything... Now in Debian12 we have journalctl, and we have to do a lot of thing to just go back to the old way to logs things... With just simple txt log files... Damn KISS is important... Why using binary files for logging ?!? Soon there will be no more distro, just systemd with specific package manager... And even that, with flatpak it will be systemd on immutable distro with flatpak on top... on my opinion it's a very bad thing that a single project take so much space in the linux world. We need choice, we need competition... Not another windows or mac system...
Hi, I felt that RUclipsrs are having a fake idea that viewers are only viewing it on desktop/Laptop and cases are actually most of the views come from developing nations were the learning or addiction is on phone. Plz make the font readable is you show it on screen. Just feel how i, paid audience view when the size of Video is no more than 25% of the app screen. and 75% of screen space is filled with other recommendations. Your videos are always commendable and love to watch them as always.
Personally im fine with systemD I have used it for a WHILE now and since the distro’s I use with a virtual machine come with systemD as default and the fact that I’m too lazy to look at any other options I’m fine with it
nice comentry on some of the differences. I think if you are using linux like windows, as a basic user, you probably don't care, as long as it works, If you want more control over what happens, then there is something to be said for simple text file configs and easy to understand scripts, where things aren't hidden away. I use slackware which is not systemd, and as a result has to use things like eudev and elogind to work around the increasing dependency of applications on systemd. It is good to be able to have these alternatives, just like it is good having alternative web browsers. No-one likes to be forced to change everything just because someone else thinks their way is the best. As Nick has well stated, there are reasonable arguments both for and against the different init systems. I hope there is not so much attrition of the sysv init supporters that it becomes impossible to run alternatives to systemd, and that application developers consider that not "everyone" is using systemd. linux is a clone of unix which is around 50yrs old. not everything old is bad.
"systemd is a security risk because it's a single thing across multiple projects" - this is as true as "open source is more secure because there are many eyes on it", with these many projects using systemd, there sure would be someone looking for security breaches
All I know is for shell automation things changed drastically, my dynamic SSID network renaming scripts for a honeypot project are not worth the time to transfer over due to all the changes. Maybe in the future but I just feel GNU/Linux is starting to cater more and more to window users rather that keeping true.
Hey Nick, I wanted to thank you and your channel for rekindling my curiosity and interest with Linux. I used Linux for some time years ago when I was stuck in the Windows ecosystem, but then dropped it when I got a Mac computer, which was the perfect middle term solution for my personal use. I rebuilt a Windows machine for gaming a couple of years ago and have gotten so disappointed with the direction that Microsoft is going with the OS, and your channel appeared on my feed out of nowhere and made me feel very curious about giving it another try. I’ve been using Nobara for a few months and it plays everything I want super well, and made me enjoy my computer again. Thanks Nick!
Life is too short to be worrying about things like this. If it works it works. Year of Linux desktop is never going to come if people can't even agree on an init system.
systemd's main advantages: a) thoroughly designed b) can do some stuff which no other system can do well. systemd's main problems: a) not just complex, but unnecessarily complex b) solves too many problems I didn't even know I had c) gets in the way of existing systems - second system effect.
The hate for SystemD just seems so irrational. You need a good strong service model, and that starts at init and is continued from there. Benno Rice’s “The tragedy of SystemD,” and “what Unix costs us” really addresses these points pretty well
If it's under IBM control we need to start a new project immediately.. it's a snake wrapping around linux.. before you know it it's going to be subscription based or under whatever greedy practice.
I hate systemd because it doesn't run in Linux containers without elevated permissions, and even then it doesn't really work right. With Upstart, you could start and stop services in a container without any extra effort. Now I have to write supervisord or bash scripts and it's a pain
I actually complain about CUPS a lot. The past three printers I've had required special PPD's to work with it. For some reason, not a single all-in-one I've had works out of the box.
Everyone can choose whether to use related programs, software, etc. This is Linux, not quarrels. If everyone really likes Linux, they should treat every contribution with an appreciative attitude. Communicate and cooperate with each other in harmony for the sake of the Linux family. This way we will not be criticized by windows Users look down upon.
11:42 we had back then alike "simpler and comfortable" system opening socket for us - (x)inetd. Wondering why it was long gone before wide adoption of systemd 🤔
I love Linux. I don't really like the drama that gets generated over how people exercise their choices. My take: "If it works for you, then it is good for you". I'm happy for you.
I can understand why some people made drama because of it. It's similar to the Windows/Mac vs. Linux Desktop debate. Most companies and schools use Windows/Mac, and most applications and games are developed to support only Windows. Consequently, many people have to choose Windows/Mac as their operating system. However, almost all Linux users know how bad those operating systems is. With all major corporations in Linux choosing to use SystemD, it has led most Distros, DE's, WM's, and applications to only develop support for SystemD. This compels most people to choose SystemD. Me myself still using SystemD, i tried RUnit and OpenRC but some important Applications can't run on them, and i don't feel any improvement from SystemD. And I agree with your take: "If it works for you, then it is good for you".
It's a problem when fundamental system building blocks like udev are hard-dependent on systemd. Now it's not "you use what works for you" because what works at all MUST use systemd.
Incroyable cette video, depuis le temps que je me posait la question sans vraiment chercher, j'esperait un jour en avoir la motivation, tu l'a fait et c'est fantastique !
Like every project, though. Linux kernel and drivers also have CVEs regularly. OpenSSH as well, everything does, doesn’t make them insecure or unsuitable
@@TheLinuxEXP you just stated platitudes. Just because other code has vulns doesn't make all code equivalently insecure. Obviously the judgement of whether something is more or less insecure than is "suitable" is nuanced, no one would use a blatantly insecure software (actually idk, maybe they would.. tiktok?) but people often find it "suitable" do use objectively insecure software (windows being the most obvious). So I think criticising software as having security vulnerabilities implies they think it's less secure than is acceptable. Anyway, nice video to rile comments 😉
The attack surface wouldn't be the same. systemd does many things because it does many things, it has a higher attack surface. A init system that does only initialization has a smaller attack vector than systemd.
systemd-init is just that - only an init system. systemd isn't a piece of software, its an entire suite. So... its the same principle as using different components. Its all different pieces of software. A vulnerability in systemd-networkd doesn't mean system-init is broken, for example.
systemd is not a giant monolith. If you remove components from it, you have to replace them with something else. So on the contrary, splitting the functionality into many projects leads to code repetition and you end up with more code that poses a risk.
I think the reason systemd gets a bad rep is because for most people, the first time they got in touch with it was after swapping/upgrading operating systems, they were suddenly told "the way you have been doing things no longer works. It's systemd time now!". And the most natural reaction by most people was "I don't want that! I want to go back to what I know". Systemd might have been the best thing since sliced bread, but it didn't advertise to users why it was better than what it was replacing. All users saw was "new", "unfamiliar", "incompatible".
This is one of the hottest topics I used to read on Reddit before starting to use Linux and thought it was a big deal, but as soon as I started using Fedora, I realized that I absolutely don't care about all that. My system boots fast and safely, that's all I care about.
I think systemd is an example of "software written in one mindspcae" instead of "software written for one purpose" people that write systemd are the same people that would know not only how to implement service management, but other things like logging, user sessions, network managment, etc.
They could have limited the scope, had smaller other projects rather than everything under one umbrella. The key idea for the revamp of init came from Apple's approach and thinking someone who was infamous for Pulse Audio breaking sound knew anything about that list of management features is funny. Lennart had his ideas, would relentlessly pursue them ignoring experienced admins, tradition and reasonably expressed requirements. So he upset a lot of people. RHEL engineers would have had a lot of input, those suspecting an embrace & extend would occur were correct.
Monolithic kernel model shouldn't necessarily mean everything ought to be monolithic as well... Imagine all desktop environments embedded in one single systemd blob? Don't think that would make sense either. :)
@@Ebalosus well.. have you ever tried to type "sys" and hit the TAB during an SSH session in the terminal? When you do that, there happens to be way too many command options popping all over the screen and you get lost all of a sudden... And then you go... "Heck! What was i looking for in the first place?" It's more like "a command line options hell" right there in front of your eyes.. :) You can't say the same happens with Xserver tools under any circumstances. What i'm trying to tell is that, it was always the sysadmins who were hurt by "systemd verbosity" in the first place. Not the regular desktop users. Then again, Systemd turns out to provide a very smooth experience for regular desktop users indeed. Not something the sysadmins have been yearning for at all.
@@Ebalosus except anyone complaining about systemd probably hates the X11 situation even more, or doesn't ever leave the console.. so idk what your point is
Systemd is not an 'init' system. It's an event-driven system management suite. In other words, it's Apple Launchd's concepts adapted to Linux. There are 2 very good reasons why Systemd developpers have rewritten lots of classical Unix daemns: 1. Those daemons depend on the old scripted 'init' system. 2. Their maintainers have not provided an event-driven system management paradigm version of them, because the guys haven't embraced this paradigm (some even don't understand it). Besides, the first good old daemons had been adapted by the same team of guys who had invented the 'init' system too, since in 1971, the Unix system developpers amounted to a very small team.
Once again your thoughts and mine coincide. I started back in 1970 on IBM big iron, mid 1990s tried Mark Williams Coherent, thence to Red Hat (pre commercialization). Yes, I do remember LILO. That first install took me a week to gather all the graphics card info and the relevant monitor specs. Finally it was working! Since then I use Debian-based distros since I am into using the tool, not spending all my life "tweaking" it. Linux Mint Cinnamon or LMDE Cinnamon for the win IMHO. I basically want FOSS with no fuss. Keep up the good work.
It's not that I hate it, its the fact that its hard to remember all the specific commands, so yes a GUI with concise documentation and of course concise menu selections would be very very helpful. With the Command line on many tools, i do always have to look up more info either through docs and man, but sometime yes they confuse me, so I do look online to get more clarification. Just being honest, is it getting easier, yes in many areas.
Lennart Poettering (creator of systemd) has "protective dad" characteristic. Which means, he would rule everything because he thinks he knows everything for his kid's best (which in this context, the kid is his systemd). Most of Linux users (including me) are prefer freedom. Thus, it would hurts if somebody rules too much and that's why so many systemd haters here. On the otherhand, big distro like Ubuntu and Arch are chilling because its compact and tightly designed.
I'm just a casual guy who happens to use Linux on my desktop computers. I noticed a speed bump when the distro I used back then switched to systemd (not sure whether it was Kubuntu, Mint KDE or still something else) and was excited. When I need to tinker with that stuff, I will end up relying some sort of help anyway so it is nothing I personally care about.
In view of the way the project (especially Mr. Lennart Pöttering) deals with security gaps and bugs, however, it must be noted that Systemd unnecessarily increases the attack surface of Linux. btw: Lennart Poettering has joined Microsoft. - You can't make this shit up!
I recently used a systemd timer to schedule an Rclone script to back up files. I used to use cron but systemd timers are so much easier. You can actually state the time you wish something to run in English and not use that stupid secret code cron uses. And there was no problem with permissions like I always have with cron.
You do realize that you not understanding how crontab works and is properly set up is an issue on your part? Just for subject's sake: The Secret code is simply: min - hour - day of month month - day of week There are 60 minutes in an hour, there are 24 hours in a day, there are between 28 und 31 days in a month and there are 7 days in a week. The secret code consists of exactly that. The permission part is another thing. Depending on where the file is located you can't execute it as any arbitrary user. That's more or less it. Crontab is fairly simple and the man to it is plenty to get it to work. Apart from that, systemd is is definitely more user friendly.
@@romancvijanovic7130 If something comes a longer that makes it tiny bit easier in some way, people are going to use that. (insert quote about path of least resistance) It's just how things tend to play out.
@@romancvijanovic7130 I know how the secret code works and there are online calculators to work it out. But it is an unnecessary complication that only serves to make elitist nerds feel elite. Edit: I've been using Linux exclusively for 20 years , but I never brought into the cryptic bullshit a small group of adherents insist must be used - such as VIM etc. I actually use micro text edit because it has *normal* shortcuts
@@VektrumSimulacrum I call bullshit on that! There is no way in hell that writing a bespoke systemd timer unit is easier OR faster than adding a cron job.
When Ubuntu moved to systemd, initially I was a bit reluctant to keep that distro as my main system because of the changes it implied, mainly rewrite convert init configs, and changing a few habits. Now I'm used to it and find that it makes usually things simpler.
Head to squarespace.com/thelinuxexperiment to save 10% off your first purchase of a website or domain using code thelinuxexperiment
oh wow, first reply
Ah you corrected the video title from SystemD to systemd. Thank you. It's systemd indeed and not SystemD.
You explained it better than the official Linux Foundation course on basics of linux did.
Can't agree more sir.
@@idontknow390 I mean thier website course.
@@mglsj theioüĞr*
really? i don’t agree with that ..
@@mintoo2cool you can compare it to LFS101x chap 3.3.4
The only problem is that, although they call it a "init system", it's actually a system manager which includes a init system.
It was initially sold as a modern replacement for SysVinit, taking advantage of Linux specific features and not caring about portability.
It was based on Apple's launchd, providing demand driven daemon startup for faster boot and lower memory consumption.
systemd-init is the init system part. Do you mean by that that you find it too big ? Or systemd in general.
Also well I think it was easier to unify certain parts and one of the reason it grows is because of some service dependencies notable:
- devices (some services might need a specific device to be there to work, like drives for partitions)
- mounting points as some service might use a path not mounted yet if started to early, in the other case you need to wait the mounting service to mount ALL services (telling the init system for each mounted device would be doing the same as systemD)
- networking (especially if you need some NFS mountpoints as it requires you to have your network set up)
For journalctl well this one is an kind of an odd one but basically having the same project managing the logging system and the init system allows you to get log from before the logging service as been started
However effectively some project benefit less from being in the same unique project in my eyes
- The login system as it can be a regular service from systemd with other services like agetty requiring it
- The boot system as most distro use grub anyway
So yeah the main part of systemd is still it's init system a lot of parts are just integrated directly with it at it make things easier/allow to boot faster, however some are a bit odd to be in the same project for me
@@HinaraT you're totally ignoring the personal factors that caused anxiety, see the developer issues supporting real users, lacked tact, to understand the scepticism search "Pulse Audio has broken my sound".
The controversy was never purely technical, but the result of past history, so an embrace & extend with massive mission creep by a developer not known for sympathy for real user issues and requirements was not unsurprising.
...and that's the big problem
@@imwacc0834 To be fair systemd is large and modular. Essentially what people call "systemd" isn't one piece of software - its like a dozen. It's also a fantastic piece of software from a user perspective and a sysadmin perspective. It really empowers the user and simplifies system management. Shell script hell is a real place, and I don't want to go back
I'm perfectly happy with SystemD and also truly hope that alternatives continue to be developed and actually maintained because having _no alternatives_ on the backburner is what's scary.
I am happy with it too. It's a really great open source project. However, just to inform you, it's called systemd, not "SystemD" or "system D". Those are completely different things. It's the same d as the one at the end of any standard Linux or Unix deamon name.
I think to problem is the lack of choice indeed. Gentoo does this right by letting the user choose what they want. A lot of Linux and Unix hobbyist want simple to use init systems and that should not be such an issue.
However people blame systemd for a thousand things which are just objectively wrong. The whole bloat argument is part of that in my opinion.
Systemd is a large project, but so is the Linux kernel. And both are modular in structure. I don't see the point of those haters.
And my personal experience is that the system boots faster with systemd than with other init systems, because systemd does everything in parallel a lot. People don't seem to get that point.
I feel the same way. I've learned a bit of how to use systemd but I still have a long way to go. Then maybe I would like to test out runit and OpenRC as those seem like the most popular and developed. I'll probably not use them in the long run but it's nice to know they are there for systems and projects that want or might even need them.
launchd is what sparced systemd. because it's not a bootscript replacement , it's a system layer like MacOS, BSD and even windows have . They all use a system service/demon. The haters of systemd just don't get how modern os are built.
@@TremereTT some of the worst problems of modern OS's are a result of everything being a daemon though. It's an inherently wasteful solution that is also very convenient, and that is an unavoidable tradeoff. Some things you basically have to run as a daemon or you will be forced to restart the OS more often than people are used to now.
But systemd is imo not configurable enough to manage that tradeoff well. For two examples, CUPS and Tumblerd are both aggressive because people expect their printers to respond quickly and reliably, and their thumbnails to show up. But for me they are both incredibly annoying. Tumblerd crashes all the time because it's bad. CUPS is just a security nightmare and way too aggressive, making a mess of network logs. But your only solutions are to uninstall them and lose those functionalities or deal with it. They don't have configurability to balance out their problems, which is not "the linux way". So I think criticisms are perfectly fair. But as always you can't really complain about FOSS.
Exactly. I like having a variety of options. The more competition the better.
I think the best argument I've heard against systemd is that it could benefit from some healthy competition
Pottering is a German genius. Hard to challenge systemD.
I don't know, it's Open Source so their is no real monetary competetion. I don't know if competition would change anything.
@@anonymunsichtbar3715 it might even harm it due to less people working on a single project
At launch, systemd was in some ways so far behind the competition that it never should have got off the ground. At the time, I knew a supercomputer sysadmin who, of course, had to work with huge log files, often 2GB or more. It took off because enough people blindly swallowed the lie that binary logging means faster log searching. The truth is that fast search comes from good search algorithms which grep has and which systemd absolutely didn't. My supercomputer sysadmin acquaintance had a hard time until he found systemd can be configured to log to sysklogd.
For starting and managing services, experienced sysadmins found Debian's little program, run-parts, to be all they need.
For managing udev nodes, systemd might actually be the best thing, but the problem here is udev. Every other operating system, including the BSDs, have better solutions than udev. The problem here is Linus Torvalds insistence on "no policy in the kernel," so device management has to be pushed to userspace where it's hard to make it work well. However, I've heard mdev is easier to work with than udev, so even here, systemd isn't the only choice.
Systemd exists because the vast majority of open-source fans do not test and verify information.
@@n.m4497 I have 2 issues with Lennart Poettering: He's employed by Red Hat and his work seems to bring unnecessary complexity. Amongst fans of clean code, Lennart Poettering is known as someone who can't express himself succinctly in code or words. Complexity is sometimes necessary but not as often as you might think, and I think Red Hat have introduced a lot of unnecessary complexity into Linux via Lennart Poettering and others.
Besides this, I don't like Poettering because he's employed by Red Hat. Back in '98 when I was just getting started with Linux, Red Hat were a huge impediment to me as they tried to make Linux very hard to administer without a Red Hat support contract.
Between the influence of Poettering and other people who don't have the intelligence to simplify things, Linux has become the hardest OS to administer by quite a margin, worse than the BSDs, worse than Windows, absolutely worse than old VMS, and sysadmins get paid the least.
I think you missed the main underlying problem of systemd. A lot of other programs interface with systemd components and are thus dependent on it. But since the systemd interfaces are not based on a standard, but instead just made up as they go, it's impossible to create a program to replace a part of systemd.
It's similar to the rust situation where there is one official compiler implementation. And that compiler implementation basically decided what the rust standard is. But they are working on a standard definition to make it possible to create other compilers.
If systemd would make standards for how interfaces with an init system should work, all concerns with systemd could be resolved by replacing parts of it with alternative programs. But systemd is not incentivised to create such standard, since it would mostly benefit systemd alternatives.
systemd is under no obligation to standardize anything either, it costs massively and carries no benefit, that's something others have to push for and actually make reasonable standards that then can be adopted into systemd and at least some of the other init systems. If one is not pragmatic and methodical with it, its a waste of time, and there's not much point if the software users don't push for it.
@@Spartan322 Yes, it takes a lot to standardize things, see for example wayland. And it has to be evaluated if it's worth it for our init systems. But I believe that at this point it's the only reasonable way that there could be systemd alternatives, without burdening all applications that rely on it to change
ty for the explanation @@frisosmit8920
I doubt having a standard or not matters. systemd is pervasive -- that's the main complaint. Even if the interface was a "standard", it would still be an opinionated and systemd interface. You could replace the code behind the interface, but you would still end up with "systemd", just an alternative implementation.
the same can be said about linux, It's just been made up as they go, it just kinda respects POSIX.
At the other side of these stories we have C++ which the standard moves faster then the compilers.
or ECMA which is years behind Typescript.
Until people just realize and implement a better way to do the same things as it does, there is no point of having a fight over it's ways. And complete interoperability it's hard to achieve
My biggest frustration with SystemD is the fact that so much software has gotten coupled to it. It's frustrating how much extra effort it takes (with my level of skill) to set up another init system and be able to trust that I'm not breaking my system or my applications in some obscure way. I like working with SystemD most of the time, but I don't want to be stuck with it!
I wish it wasn’t so entangled with other projects, yeah
Because the vast majority of people knows absolutely nothing about tecnology they dont take it serious, so we'll end up stuck, and it will be used against users/consumers, like always happens...
@@TheLinuxEXPSame, I don't mind extra options but this has essentially got a chokehold by being required more by important stuff.
@@Thurgenevso fork the code when they turn evil.
Distros have replaced other key components in the past.
@@RobBCactive I don't want to be rude, but if I were you, I wouldn't pretend I know what means to fork a project like this. Specially to minimize wrong behaviours.
i didnt expect systemd to be that recent, as 2010, thats crazy!
And Arch actually adopted it rather quickly. Only a year after Fedora afaik.
It's almost like it actually is a really good piece of software that solves many problems distro maintainers frequently encounter. Huh.
@@jfolzI would not dare to call systemd a "really good piece of software", and while it did solve issues that sysvinit had, so did openrc and runit (and nowadays s6). it was an alternative for which some low level packages (and high level oned now) started to have hard dependency on (hi gnome and udev).
One of the most compelling arguments against systemd is the topic of debugging errors that prevent systems from booting. With init daemons you could add a few echo lines or comment out lines you suspect being problematic. that and the fact, that logs are stored in a binary format - who wants to open dedicated "apps" when you have the shell available?
Systemd was sold on the myth that searching binary logs would be faster. I used to chat with a supercomputer sysadmin at the time, and he found systemd's binary logs impossible to search because its search tool had a poor search algorithm. Grep was far faster. Fortunately for him, systemd's logging facility can be configured to output plain text to good old sysklogd.
Personally, I have mixed feelings. Initially, using the shell was a huge relief after dedicated apps, but in the end, there are so many tasks where you need a program to do something from the shell, and that program is just as likely to have poor documentation and a poor interface as any app. I could rant about it, but I'm done ranting for the day.
@@eekee6034 The only real upside to binary logs is maybe disk space. But even that is questionable when text compression exists.
@@lucass8119 That is a DEFINITE non-argument. Syslog has always been full text, even in the days that the space requirements for a MB of storage was measured in cubic feet. In fact, it is my greatest gripe with systemd, that I have to use special tools and search for the logs that I want, instead of a simple `grep`.
@@TheEvertw Well its not a non-argument because its not an argument, its a fact. Binary logs are smaller than text-logs.
That doesn't mean they're better, as I've already stated. Take a seat.
@@lucass8119 You should study the UNIX philosophy a bit. Storing data in human-readable form is a basic tenet of UNIX. There are many reasons for it, have a read in e.g. "The Art Of Unix Programming" to learn more.
"take a seat" -- pip squeak thinks he is being clever. You only display your ignorance.
support init freedom
I think the only concern is that so many apps now require systemd to function, making more work for distros using other init systems.
If Devs would leave the choice of init system open when making apps it would be less of an issue
It's becoming a problem on BSDs and other Unix-like operating systems too. Much like cgroups, PipeWire, and Wayland. But this is just Linux and, by extend, some distributions of Linux being too influential. It's not going to change anytime soon.
Centralization is probably the main concern, especially with how much Linux has appeared to favor decentralization. It's kind of what makes Linux different from the big boxes. S6 is pretty cool and a great alternative used by Artix, which is basically Arch without SystemD. It's a fast distro, gaining popularity, and, though you have to be careful what you load, you can use the Arch repositories for to add programs and do updates. Devian/Devuan has a few non-SystemD distros worth trying out. I'm still not sure about installing into RAM, but for some of my old laptops with dead hard drives, it does propose a unique possibility for giving them new life. Just trying out all the options out there is part of the fun of distro hopping.
This is kind impossible without standardization, which people who are actually bugged by this issue need to actually push for, a solution doesn't just come by saying "it should be this way", someone has to actually make it, else you just get de facto standards that everyone has to emulate because its completely infeasible to support every system, any developer should already know the hell that is trying to support everything the user does, (also you shouldn't expect the systems themselves to do it because its more work then building the system itself and unless you need it, nobody actually benefits) much like how pipewire emulates pulseaudio and jack, and kinda like how Wayland compositors are trying to emulate X11 specifically. (you see, without standards, you have to emulate the de facto standards, this is extremely common in Linux)
@@Spartan322 I can't help but wonder what might have happened if the Community came together back then, to improve one of the existing inits in a way that would be similar to systemd, but perhaps not so monolithic and community developed rather than red Hat developed?
@@MrOrtmeier Eh the result would've been mostly similar, systemd came up out of need, if something was being made at the time that was FOSS, Red Hat very likely would've considered backing it instead at the time and it would've still become monolithic because it would be the most common and easiest to use init system, what happened with systemd is just an organic result of building for general user cases, you can see it with every major user focused platform, the only way it wouldn't is if you sabotaged Linux adoption to the common man.
There are a few things which I would consider bad about systemd:
- the way they handle certain security vulnerabilities (to a point where their "solution" is sometimes "we don't care what POSIX says about it")
- some projects even when they are older, suddenly start to hard depend on it (like udev which quite a lot of projects depend on is these days part of it)
- some implementation details (I straight up dislike the design of journald, but considering how hard-depend the rest of systemd is on it, I can't just jank that out and replace it with something else (as literally the only component of this project))
- hard dependency on glibc (this is actually one of the reasons why some distros don't use systemd); they depend on a specific libc implementation so you can't use better engineered ones like musl (don't get me wrong, a lot of the reasons for why glibc is in its state is age, but there are also other reasons like their own extensions to a point where Microsoft would blush at that); and since you can't statically link glibc (no seriously, if this works properly for your project, you got lucky), it quite complicates things for some embedded projects (ever heard of few application Linuxes?)
But I also like quite a lot about systemd:
- unit files
- it often uses symlinks where other projects would have config files
- custom targets (which let's you do quite interesting state management stuff in a pretty easy and reliable way)
Best comment
systemd targets is a very neat and good idea. I would love projects like openRC to have that instead of runlevels. Though systemd's init system is really terrible for anything else.
On most inits you can just go to the script, append && and do things like preloading files for faster init
systemd is a monolithic monstrosity that creates a huge security concern.
Anyone who touched a minimalistic embedded Linux system knows the third biggest init system out there: busybox/toybox. If you really wanna keep your system "bloat-free" for an embedded device, where your available internal memory might be measured in megabytes, a custom minimal kernel with barely enough drivers to boot a terminal and a busybox/toybox init is the way to go. This is an advanced configuration where you sacrifice any semblance of general compatibility and standards though, so most people are better off trusting systemd and their big distro kernels. Even servers don't use this kind of config because the management options systemd provides are too good to pass up, and well worth the (fairly low) security risks.
Yep or containers... something like that or supervisord is used by pretty much any complex app stack/monolithic image
@@kelownatechkid If you know what your doing you don't need docket to run cloud apps. Docker isn't better than traditional hosting, it's just different. You're replacing old problems with newer. But I hate designs where apps ship their own dependencies.
You don't just ship all your dependencies, because if you do, your responsible for the security of every component you're shipping. So have fun managing all these dependencies daily.
I feel like many forget the responsibilities that come with shipping software, because a dependency doesn't just offload problems, it also offloads responsibility.
I'm don't really care that much about init systems, but after switching to MX Linux, I have started to see SystemD from an outside perspective. There are two main problems I see with it:
1. Every tutorial and guide assumes you use SystemD
2. This next point is kinda hard to put into words, but SystemD has became a sort of "default Linux OS." I feel like it contributes it the idea of having a default Linux experience. I just don't want to see a future where we unironically use the term GNU/SystemD/Linux.
The software is perfectly fine though, I just don't like how it changes the way people think of the Linux software ecosystem.
*DISCLAIMER FOR KEYBOARD WARRIORS:* I'm not here to start arguments, debates, or discussions. I'm just thinking out loud and sharing my perspective for anyone who might not have thought of things from this angle before.
Is point 2 a bad thing? I can understand there are benefits from keeping few alternatives alive, but for overwhelming majority of users, it's probably way better to have a solid "default linux" as foundations to build on.
geez I got my mountain dew and pitchfork all ready, put the disclaimer at the BEGINNING next time
@@craigslist6988 It was a genuine question.
@@jirivegner3711 Yes, because systemd is taking an "embrace, extend, extinguish" approach.
@@ahettinger525 This approach (if true) is kind of moot if the end product is foss, isn't it? As I've stated previously, there are benefits from parallel development of alternatives, but where is this huge problem with having one "standard" version? It could be argued, that having Linux as "standard" for servers, has very similiar issues. Where is the difference?
When a scalpel is needed, Lennart Poettering has a tendency to use a wrecking ball instead... and then expect everyone else to rebuild in his wake. Systemd was his biggest wrecking ball.
Hi Nick, first, THANK YOU for such a detailed explanation of arguments against systemd , I always understood the mood towards it but never understood why
Second, PLEASE do pulseaudio next!
It was also made by Pöttering and I personally believe it sucks even in 2023 😢
I look for distros using Pipewire because low latency matters with my workflow in music. Gaming also can get a boost from it as well. However, AV Linux boasts of being able to have low latency, claiming to have the 'correct' setup of Pulse Audio, and I can't help but be curious what they are doing that countless other musicians and sound folks have split hairs on when it comes to getting Alsa, Jack and Pulse to 'play nice'. 😏👍
Pöttering 🤮
I wish there was something like freeinit just like Freedesktop so that we could have interoperable init systems and it wouldn't be a concern to replace anything.
I think people are more afraid of systemd becoming irreplaceable than other non-fundamental excuses.
This is exactly the problem
Systemd isn't irreplaceable at all. How do you explain existence of Devuan, debian based distro that uses sysvinit? Devuan even supports upstart and other init solutions.
@@raughboy188 that's somewhat true today, I'm just imagining a way to maintain certainty for the future
@@Beryesa. in linux world nothing is certain due to its open source nature. Sysvinit may be older init system but there is nothing wrong with it and can surely be used in latest distros without any problem at all. If Devuan is using sysvinit it means somebody is still maintaining it, same thing may be with upstart and other solutions offered by Devuan and other distros that follow same path. If i want to i can tear debian's current iso and just replace systemd with sysvinit, upstart or any other init solution listed on devuan's page, i am not obligated to use systemd if i don't want to.
I love systemd in such a way... It unifies all kinds of system services. Timers, mountpoints, swap... It makes it easy to manage the system. Program logs are written in the journal, so no need to look for specific log files to find a problem.
Also, programs can trigger a service as needed, which means no backgroud services running indefinitely even if it is not being used.
Totally agree! I also love that you can totally isolate your systemd services, limit RAM, cpu, drop capabilities and change mountpoints. It's very versatile. I also systemd-networkd to be the only good enough solution to configure my complex networking setup on my router.
This is part of the reason why I love systemd as a system administrator.
Creating a service is so easy with systemd, yet you can have very fine-grained control over how it behaves, what it can and -- more importantly -- cannot do.
But what I like most is the journaling system. People like to hate on the binary file format, but at the end of the day you can't read the bits on disk either without some tool to turn them into legible characters. journalctl is that tool for systemd logs. The advantages of journald are too numerous to ignore. Services don't have to manage log files. Just print and it gets logged, including an accurate timestamp. If you need logs for a specific service/unit and time range, you can get just those lines very easily -- no need to search through multiple rotated file, some of which are maybe gzipped. There's no need for any of that nonsense, since journald can compress logs, and clean them up while keeping a specified amount of time or data.
@@jfolzThe problem is not that it needs a tool, but a specialist tool, I could read old syslog files on windows even without specialist tools. But also look at what the initial implementation did to kernel logging, a problem the kernel developers had to go fix for them.
That said, it is much better now than it was, a lot of the hare is actually quite old or out of date.
I run Void Linux with runit. In my opinion, systemd isn't too bad (I run Arch on one of my other systems), but I prefer the simplicity of runit. There's barely anything to lose when switching from systemd, and lots to gain. My PC only takes about five or six seconds to boot to desktop, and it's certainly worthwhile. I encourage anyone to at least try an alternative to systemd, and see if it's for you. But again, it really doesn't matter at the end of the day. If it works for you, then it's fine. Void and runit works better than systemd for me, but it may not be necessarily for you.
4:05 I always see this argument in places like reddit and it's always by sysadmins and powerusers, but I can assure you you won't see a developer say this. If most components of systemd have hard dependencies on each other then it is not modular, even if they are different binaries. Thats why we have entire desktop environments having systemd as a hard dependency. And let me tell you there is no reason why a DE needs to have an init system as a hard dependency.
MacOS has lots of binaries, so, it must be very modular, right?
Honestly I didn't really know about the hate of systemd. I've been learning and using Linux for 3 years now, and pretty much most of the distros I used use systemd. And I haven't had a problem with it.
The scandal happened way earlier :-)
@@new-lviv which is?
@@Stevexupen There's definitely some technical details that turned people off initially. One thing that isn't mentioned is that systemd is aggressively Linux specific, meaning that the portability principle of Unix projects isn't being honored in this project. There's a ton of advantages to this approach (use of C groups is the biggest Linux-specific item that I'm aware of), but it still isn't a true Unix project.
I think the main reason people don't like this project is that the conversation around it became wildly toxic. From what I understand, Poettering was a little glib in addressing criticism, and in return he started receiving death threats. The whole thing turned quite ugly after that, with people drawing battle lines based on ideology rather than usability and technical viability.
To be clear, I wasn't around for the holy wars, so someone else here might have a better insight into what was going on at the time.
@@Stevexupen one main issue is the blatant scope creep (modern init system -> service manager -> system layer -> ... ), for example it now has a bootloader.
@@1DwtEaUn is this a problem though? if it works and has power and allows you to get things done then I don't care, really.
Great video Nick. Your high level approach to explaining why I should not care that my distro uses systemD is comforting after reading all the hate systemD gets online. Now I can continue my use of linux distros with one less thing to worry about. Thanks!
I don't have a problem with systemd per se. Its core functionality as a system service manager has always worked well for me. Yes the configuration is more extensive but it does a lot and has a lot if flexibility.
My biggest issues are with some of its support functionality. The whole journald subsystem uses tonnes of memory and is redundant with *syslogd.
Resolved is 100% broken on 100% of my systems 100% of the time and gets removed immediately on every install.
My biggest concern is that it seems to be subsuming subsystem after subsystem that has perfectly viable alternatives. While resolved can be removed easily, I havent found a way to remove journald.
Yup. resolved is borked by design. However, it gets _reinstalled_ every major OS upgrade (now with cloud-init integration which performs magical at-boot updates to files in /etc, so that stinks even more), so I recently gave up and just did a search on how to correctly configure upstream DNS servers in it and let resolved do its thing so I never have to deal with it ever again. Do I want resolved and syslogd and a good chunk of cloud-init to vanish? Yes. Am I going to waste hours of my time every two years to figure out how to do that? No.
I don't mind systemd existing, i like an extra option ...but I don't like that its mandatory for Gnome's stuff :/
Correction: why has systemd _ALWAYS GOTTEN_ so much hate. It was imposed in a top-down fashion on the entire Linux community by one entity (Red Hat), and the developers who did it treated everyone else like garbage and had piss poor attitudes. Now the main author works for Microsoft. It's the Microsoftification of Linux. And you basically swept the serious security concerns under the rug like they almost don't even matter.
✊
It didn't get pushed "top down". Red Hat adopted it, because of course they did. For an enterprise environment it makes perfect sense. It is simply the best and most productive experience for a sysadmin - and it's not even close. Regardless, other distros did use alternatives and had the opportunity to use anything else. They CHOSE systemd, all of them, independently of each other. They literally all chose to abandon other solutions in favor of systemd.
As for the security concerns, I do think there is some truth. But I also think its a bit overblown. People act like systemd is this huge monolith piece of software, and thus is a huge security concern. That's not the case. "systemd" is actually, like, a dozen pieces of software. And, even without systemd, other init systems need to have privileges and power. They can ALSO be attack vectors, to the same scale as systemd. Simply switching systemd-init for upstart doesn't change anything. And, the large adoption of systemd helps its security. It's being contributed to from a lot of places... which is good.
@@lucass8119 Okay, Pinocchio 🤥
@@liquidmobius Are you gonna elaborate further? I mean, its not like red hat held debian distributions at gun point. They chose systemd, willingly. Fedora, maybe not.
I give you one example: There was a time when systemd made deliberate choices to exhaust the Linux kernels random pool for totally arbitrary tasks like creating device uuids at boot.
This basically meant that when the system was booted, not enough rng pool was left for critical tasks, e.g. in networking. There was a big clash between the kernel (Ted) and systemd (Lennart), because the practice was actually doing widespread harm. systemd insisted it's not their problem the kernel can't provide a faster high quality rng stream.
It was utterly ruthless behaviour.
The distro I run (systemd early adopter) reverted to use haveged, a daemon _seperate to the kernel and systemd_ to gather more rng for the kernel, for years.
And it's just one example. It's very easy to pinpoint other issues. I can pinpoint critical issues that get finally fixed in v255, but have been denied for 5+ years. There are a lot of great people contributing to systemd and it's super innovative and brings Linux forward. Frankly, I also can't understand how much work Lennart himself shoulders. Yet, the forcing upon the community was an issue, and you won't convince me that attitude problem is totally gone.
People often forget that the Linux kernel doesn’t follow the UNIX philosophy
This was hugely helpful, thanks. I came to Linux in 2009 and was oblivious to all the drama over SystemD until just a few years ago, but couldn’t find any good explanations of the problem. This is the best concise explanation I’ve seen yet. Gracias!
I use two different systems with OpenRC (Gentoo) and systemd (Arch). It's a bit of a pain to keep the commands straight between the two systems. I'm quite used to OpenRC. The only gripe I have is that many things are spidered into systemd.
given it has a boot loader now, how long until emacs and a kernel are merged in
@@1DwtEaUnI seriously hope that doesn't happen. I don't use emacs. I prefer vi and a kernel being merged in would be no different than Windows. It seems we're headed in that direction considering Lannert works for Microsoft.
The systemd project is actually one of the main reasons why I moved to FreeBSD. Also, because many Linux distros change for the sake of change…like ip, instead of just keeping with ifconf.
The issue with Systemd was always that you could n't simply use only one of its components without also using systemd-init. We still need (kinda) forks of logind and udev because neither works without systemd-init. (Debian used to use Systemd-shim to be able to run alternative init Systems). And their Attitude towards fixing certain (minor) security issues because 'If you use a sensible configuration, you wouldn' t be able to Do that'
(which were the reasons I was using artix for a few years)
But I Do admit that it doesn't matter for most users.
3:20 Devuan is the Debian fork without systemd.
I like systemD reliability but openrc was so much faster to boot the system. Good thing nowadays I barely ever reboot, because suspend works flawless.
Biggest criticism of systemd is it's linux only nature. Before init systems were also supported on other platforms like BSDs, Solaris, etc. This meant many applications that would interact with the init system (e.g. desktop environments, login managers) could support more platforms with less effort.
10:31 if people think it's an attractive target for attackers, they shouldn't use Linux.
The Linux Kernel is the most used OS Kernel in the world and probably the most valuable target that exists.
oh so they should use windows then?
What a garbage take, why did you post this.
Happy with runit for years.
Good explanation. I'm an old-school (early '80s) *nix user/admin, and I my main objection to systemd was "why are you making such a fundamental change to a system that works and is well-understood?" "It's old." is not a good reason. In the end, I end up using systemd because the distros that have the capabilities I need are using it. Otherwise, I'd use BSD.
The main thing that draws me to alternative init systems (runit specifically) is their speed. I used to have relatively low-spec hardware. Because of that the speedup in boot time runit gave me was significant. It went from 2 minutes to just under 30 seconds on a cold boot.
Right now it is less relevant, as I actually own modern hardware now, but still, a pretty big difference for me.
I have been waiting for runit comment. Idk much about init systems, but runit feels fast and I like void linux so I use it :)
i prefer dinit which is faster and has that command. but void linux is my favorite and it's essentially the same sooooo
Back in 2001, I got a huge improvement in boot speed by writing my own init scripts. :) There weren't many options for init in those days. What I didn't have was proper service control, particularly restarting crashed services but not if they keep crashing. I think Debian's little program, run-parts would have given me that, but I wasn't online and I didn't have any Debian CD-ROMs, so I didn't have it.
2 minute boot on Linux? Wow that must have been really low-spec!
@@EvoraGT430 Me who hasn't booted anything but Knoppix for years: ...
;) Even running from a memory stick, 2 minutes would be remarkable for Knoppix. It's got such a gnarly boot process!
I've been using Linux since last century. Before SystemD there was all kinds of "sub init processes". Things like serviced and others that could monitor services and restart if needed. I remember, "oh, that uses xyz to manage the services" so try and remember their tool. SystemD came along to unify things.
Where the hatred came was all of a sudden there were tons of systemd services. This was happening anyway as the desktop side was pushing all kinds of stuff into init services. Systemd was there to accept these services across distros. Without systemd, the other init services would have also had these apps anyway.
When systemd first came out, it was a mess of half systemd and half init.d services. Management was a mess. Now systemd can automatically manage init.d services with no manual config. Now, I have had no issues in years across several distros.
BTW, MX Linux can boot in either init.d or systemd mode. Tried both ways and boot times were about the same. In init.d mode, it starts all the same services. Like you, I don't care as long as it works.
I agree with your take / clarification of his take - but implied in here (that I think you'll acknowledge) is that while systemd is better than the previous initd, etc situation, it is still a mashed ball of previous solutions and some other stuff with some really good lipstick, and maybe some spanx, on it.
It could be a lot better, which is why there are complaints. The complaints are justified because while it works, it is still a mess on the backend.
I'll walk back "mess" even, I think it has been reworked a lot, but it started from such a mishmash that it's still messy. If you were buillding a services framework from the ground up you would not choose to structure it the way systemd is organized. I think that is a fair criticism. And I also think that relying on an private company to maintain this amalgamated mess is inherently dangerous, even open sourced, because if they ever choose to stop maintaining it, the backend complexity will make it a nightmare of little boobytraps for others to take up.
I'm not calling on anyone for a solution right now, but a lot of other posts are being extremely aggressive about 'defending' systemd and sounding a lot like "it still snows in Montana so global warming isn't a problem" logic. Aggressively denying things are heading in a bad direction is such a bizarre human behavior.
@@craigslist6988 Yes, if started from scratch now, it would probably be simpler. I do see more things becoming consistent (mostly gone are started by systemd but managed elsewhere.)
Not too concerned about RH heading up the project. Having a core group from one source would focus things in one direction. As Nick said, if they close it, a fork will immediately start and continue. But it may end up going is several directions.
I don't defend it other than it solved some problems with management. Due to all that was pushed into it, it has become the 600lb gorilla we have to appease. This "everything is a service" idea has bloated all init implementations.
@@craigslist6988
If everything is now unified under the systemd umbrella at least there is hope for improvement.
Initd with its mess of distro/installation/login specific hacked up scripts probably stood no chance of further improvement.
There are two major problems with systemd. The first is technical: systemd starts multiple processes at the same time. While this can significantly reduce boot times from cold boot to a running system, it also means that repeatable boots are nearly impossible to achieve. This has consequences. Particularly for servers. Servers need to have consistent bootup sequences because they need to be reliable. This can lead to very difficult technical problems that cannot be easily solved. For example, systemd does not cleanly reboot a system on certain motherboards. This behavior requires going into a remote control panel connected to the system to hard reset the system remotely about 20% of the time that the system reboots. The second problem is Lennart Poettering. A man who wrote and maintained the PulseAudio drivers for Linux. Audio support on Linux is notoriously bad and Lennart didn't finish what he started. If you started building a house and then the contractor you found decided to stop building your house halfway through the project and instead goes over and starts building an office building across the street, would you trust them to complete either project? I wouldn't.
Lennart is a huge part of the problem. I cannot dismiss how prolific he is as a programmer, but he has repeatedly shown that he does not care about any practical concerns and systematically rebukes any and all criticism, constructive or otherwise. Lennart does his own thing and seems to believe everyone else is too stupid to appreciate his mess.
This example makes no sense. The office building across the street (systemd) would is usable, and occupied by all the largest corps, using it to make billions. lol
I had issues with systemd, it was preventing me from shutting down my system. When I'll install Linux again, it will probably be a distro without systemd. I am thinking Alpine Linux.
For systemD and linux kernel, they wanted to patch kernel to ~lock it to systemD, but at least linux kernel maintainers shoot it down, fortunately.
I get a little weird when I don't have config files I can look at, even if I only ever adjust those settings through GUI. It just makes me uncomfortable that wherever those configurations are being stored, they're kinda hidden. It just gives me WIndows Registry flashbacks.
I know my brain is wrong for that association, but I can't help it.
I don't have the energy to go fight system-d, but I heard criticism if you have a problem and need to troubleshoot it, everything is now binary instead of plaintext, I understood sysv init systems, how to edit, and manage it. Faster boot times are not an issue with SSDs really. The CLI for systemd is ass-backwards if you learned service control cli before systemd. I should be able to say systmctl myservice status/start/stop/restart etc. I tweak my linux less now and haven't had to debug startup issues in forever so I guess it is what it is. I don't particularly like systemd but it also has mostly just worked. I just feel like i don't know what I am doing any more in linux. It's some voodoo thing and I'm paranoid about IBM exerting too much influence and breaking linux.
It's systemctl [, ...] it allows you to simultaneously interact with many services.
And if that's so high on your list of criticisms, then I worry how you cope with changes in life in general.
I've compared the startup times and systemd is not the slowest, but it isn't the fastest, either. MX Linux boots faster than Debian, Ubuntu, Linux Mint, and LMDE, but I don't know how much of that is from the absence of snapd for some of those (Mint boots faster than Ubuntu, and so does LMDE).As Nick said, a lot of it is down to package and distro maintainers and their implementation choices. A lot of SysV, OpenRC, S6, and other old school style init systems can for sure be configured in a bloated, slow booting manner, same as systemd. I don't have a preference either way, I just happen to like the rest of the system in a lot of distros that don't come with systemd (MX Linux, AntiX, PCLinuxOS) but I like plenty that do come with it, too (Debian, Q4OS, Mint, etc)
For security implications, it's important to consider not only attack surface but also attack leverage.
Say you have a process which is an everything-server, and it runs as root. You split it up, and you place the different servers into their own users which can only access a limited amount of files, then although the system presents all the same ports and services to the outside attacker, its subsystems will provide much less attack leverage.
Then also imagine you have a sharp admin and it notices unusual activity in a process and chooses to investigate; but if you have a single process which does everything and routinely accesses basically all files and has substantial blips of activity at all random times, then it creates a shadow in which illicit activity is easier to hide.
I don't think security implications of systemd are relevant on a desktop and can be mitigated on a server, but one has to wonder whether it had to be that way whether that's actually good design.
Cobbled together combination of scripts also has an advantage of not being written in C, a language with an abhorrent memory safety track record in spite of so much piled on tooling and sharpest attention of expertly developers.
In principle I have nothing against systemd, and I have used distros such as Debian that have it, and distros like Slackware that uses SysV. I am still on the fence on systemd and its improvements over a traditional init, but on the other hand I can understand why systemd exists, and to be honest the fact that someone just decided to write their own init system is rather incredible -- I would direct anyone to see Benno Rice's talk on systemd "The tragedy of systemd" , it is a rather interesting perspective. -- However I do not agree that other projects not related to systemd such as GNOME and others bending to the will of systemd.
I just watched that video last week! Indeed it is fascinating
Bingo. I think systemd in and of itself isn't bad. The problems start when projects like snap (which I don't really care about anyway) and GNOME essentially depend on it.
This opinion is coming from somebody who uses Arch (btw) on a daily basis, which was one of the first distros outside of Fedora to adopt it. And no, I don't use GNOME, but not for that reason alone. (I use KDE Plasma because I prefer the vast options of customization and traditional desktop experience of Plasma. I don't use GNOME because I don't really like its workflow.)
I came to the comments to recommend Benno Rice's talk as well! It's a great discussion of both the technical and interpersonal challenges of open source projects. Oftentimes people, not technology, can create the most challenging issues to resolve.
this and another presentation on systemd I can't recall the name of were good for getting a better idea of the thinking behind it
@@cameronbosch1213 that's the choice of the other project, though. It's not like the systemd attack squad rocks up at people's houses and forces them to depend on it. It's just a really solid system layer that solves many very common issues.
Essentially everyone who ever wrote or modified init scripts was enthusiastic to adopt systemd, and almost all the people who complain about it have never written an init script.
imho one of the worst things about systemd is binary log files, it just requires you to use THEIR tools, you can't simply grep the log (or better yet, grep several logs at the same time), or setup a file watcher and e.g. send an alert to yourself whenever a critical error is sent to log (and you don't want to go about modifying all the code yourself, which could change how the program works)
and I'm also not a fan of the unit file syntax, like the thing that finally pissed me off enough to switch init, was trying to setup 2 services, which would always be BOTH brought up AND brought down together, irrespective of one of them crashing or not, and such....can bring both up via a target file, but never figured out how the hell do you force one service to go down whenever another goes down...it's just so complicated system to deal with...
but from a normal user perspective, it really doesn't matter at all, whether you do "systemctl restart nginx" or "sv restart nginx" or "service nginx restart", etc, it's all pretty much the same, the only difference is how it works on the backend, and how hard it is to write stuff using it
I do love how minimal runit is, it's small and simple enough it's even included in busybox, and for vast majority of stuff, it is enough, and best of all, it doesn't care what your init scripts are written in, you can use shell scripts (what most people use), python, lua, java (lol who'd use java for startup scripts), some compiled code, whatever, it's up to you, no syntax to bog you down, yet there's a few utility programs to help you do fancier stuff
I lol'd at Java startup script
Funny, because IMO overhauling the log system (if you can call an unorganized collection of logfiles, some rotated and gzipped, a system) into journald is one of my most favorite things about systemd. My services can just print messages without worrying about anything, not even timestamps. I can get logs for many units from journalctl at once and they're nicely interleaved by timestamp. Beyond that I don't see any meaningful difference between grep /var/log/whatever and journalctl -u whatever | grep. It produces the same result with a similar number of keystrokes.
I'd love it if everyone started using the journal. On our cluster at work, the promtail config is 6 lines for the journal (i.e., barely more than "please read from the journal"), and over 100 lines for the few logs that aren't in the journal -- mostly because everyone has a different opinion on what a timestamp should look like...
The security issue with systemd being used for a number of different functions that means that if systemd is exploited then all it's related functions are vulnerable. It would be more secure if a separate non connected process was used for each function. However this would likely impact function to some degree between interoperability and support.
The first segway was the smoothest one ever! Never saw it coming😂
Just leaving a comment to say thank you for this explanation. I use Linux but must confess that I dont know too much about it and I have wondered for quite some time about exactly the kinds of things you are explaining here :)
At 8:45 about the restriction in interest for other project, it's under systemd of course. If systemd does a bunch of things, that's a bunch of things that other projects aren't needed for. It's not about having competitors in the init-system department. (That whole section is completely missing the point and comparing apples with oranges.)
That’s a funny coincidence. I just uploaded a video about MX Linux, and specifically mentioned it’s not using Systemd, at least as the init system.
The biggest problem with the Linux community is there's a bunch of old guys who hate any change at all, and are so ideological about how things have been done in the past that they are unwilling to ever consider anything new might be better. We saw it with systemd, we see it now with Wayland. We're going to see it with every new technology that comes along and gets widespread adoption by the major distros. I think these sorts of people simply miss the days when Linux was very new, very difficult to get running, and they had to learn and know every bit of their system inside and out. They're very proud of the knowledge they gained, and anything that renders their existing knowledge obsolete threatens their ego in a very big way. They want the same old paradigms to remain in place forever, otherwise it feels like they've wasted their time and energy. It's basically the sunk cost fallacy. They'd rather spend oodles of time maintaining an old abandoned project trying to make it work when everyone else has moved on, than to drop the old thing and gain immediate benefits from something better. And frankly whining over kilobytes in an era of terabytes is a form of mental illness.
I don't have a problem with systemd, but I do have a problem with Linux-only elitism attitudes behind systemd.
Lennart calling BSD a toy-OS...
Kay and Greg trying to sneak kdbus into the kernel to deprecate netlink.
Calling sysvinit deprecated when the project was never out of date and only in extended maintenance because little was needed.
The fact systemd duplicates perp, s6, runit, and daemontools but shoves everything onto PID1 without a job fork to sustain PID1.
The countless undocumented APIs.
Trying to lock udev into systemd to prevent modularity of design by Gentoo and other distributions.
There's a lot really that systemd developers have done VERY wrong. Their attitudes have literally caused a lot of hatred and distrust towards them and the project.
The software isn't wrong and in fact is very good at what it aims to accomplish. It's gotten a lot better. The current maintainers have done a great job. It does make Linux easier to use and daemonize properly, but the fact orher distributions do the same with other tools is kind of saying, it's just another init system that does no more or less than the next.
However, getting Kay Sievers, Greg Kroah-Hartman, and Lennart Poeterring to admit they were being pompous assholes towards the entirety of the UNIX userland space of applications all to favor only their distribution, Red Hat, is never going to happen because they're too prideful.
these guys' elitism is the reason I avoid everything systemd related tbh.
@@botnet3201I use Arch, and honestly, the way Arch implemented it is minimalistic. It works well for Arch. However, programs like runit, s6, and OpenRC get ignored far too easily.
Skarnet who did s6 is pompous and arrogant as well, but one thing he says is right... and adheres to core UNIX-isms PID1 shouldn't be the end-all of the system, it should be forked.
systemd about the init system alone... why not...
But systemd tend to grow and touch everything...
Now in Debian12 we have journalctl, and we have to do a lot of thing to just go back to the old way to logs things... With just simple txt log files...
Damn KISS is important... Why using binary files for logging ?!?
Soon there will be no more distro, just systemd with specific package manager...
And even that, with flatpak it will be systemd on immutable distro with flatpak on top...
on my opinion it's a very bad thing that a single project take so much space in the linux world. We need choice, we need competition... Not another windows or mac system...
journald is genuinely better than log files.
Thank you, as usual a very informative and insightful video for someone who is a linux user but not THAT knowledgeable with all the system components
Hi, I felt that RUclipsrs are having a fake idea that viewers are only viewing it on desktop/Laptop and cases are actually most of the views come from developing nations were the learning or addiction is on phone. Plz make the font readable is you show it on screen. Just feel how i, paid audience view when the size of Video is no more than 25% of the app screen. and 75% of screen space is filled with other recommendations. Your videos are always commendable and love to watch them as always.
Personally im fine with systemD I have used it for a WHILE now and since the distro’s I use with a virtual machine come with systemD as default and the fact that I’m too lazy to look at any other options I’m fine with it
nice comentry on some of the differences. I think if you are using linux like windows, as a basic user, you probably don't care, as long as it works, If you want more control over what happens, then there is something to be said for simple text file configs and easy to understand scripts, where things aren't hidden away. I use slackware which is not systemd, and as a result has to use things like eudev and elogind to work around the increasing dependency of applications on systemd. It is good to be able to have these alternatives, just like it is good having alternative web browsers. No-one likes to be forced to change everything just because someone else thinks their way is the best. As Nick has well stated, there are reasonable arguments both for and against the different init systems. I hope there is not so much attrition of the sysv init supporters that it becomes impossible to run alternatives to systemd, and that application developers consider that not "everyone" is using systemd. linux is a clone of unix which is around 50yrs old. not everything old is bad.
"Everything depends on systemd because everyone has systemd"
then later "Systemd does not restrict linux, there are alternate init systems"
lol
"systemd is a security risk because it's a single thing across multiple projects" - this is as true as "open source is more secure because there are many eyes on it", with these many projects using systemd, there sure would be someone looking for security breaches
All I know is for shell automation things changed drastically, my dynamic SSID network renaming scripts for a honeypot project are not worth the time to transfer over due to all the changes. Maybe in the future but I just feel GNU/Linux is starting to cater more and more to window users rather that keeping true.
10:30 - " One Ring ... To Rule Them ALL.!! "
Hey Nick, I wanted to thank you and your channel for rekindling my curiosity and interest with Linux. I used Linux for some time years ago when I was stuck in the Windows ecosystem, but then dropped it when I got a Mac computer, which was the perfect middle term solution for my personal use. I rebuilt a Windows machine for gaming a couple of years ago and have gotten so disappointed with the direction that Microsoft is going with the OS, and your channel appeared on my feed out of nowhere and made me feel very curious about giving it another try. I’ve been using Nobara for a few months and it plays everything I want super well, and made me enjoy my computer again.
Thanks Nick!
Life is too short to be worrying about things like this. If it works it works. Year of Linux desktop is never going to come if people can't even agree on an init system.
Your words inspired me to make another 10 linux distros, each a clone of each other but with different color schemes and preloaded packages
@@arkvsi8142 I like you
systemd's main advantages: a) thoroughly designed b) can do some stuff which no other system can do well.
systemd's main problems: a) not just complex, but unnecessarily complex b) solves too many problems I didn't even know I had c) gets in the way of existing systems - second system effect.
Another X11 in making
The hate for SystemD just seems so irrational.
You need a good strong service model, and that starts at init and is continued from there.
Benno Rice’s “The tragedy of SystemD,” and “what Unix costs us” really addresses these points pretty well
If it's under IBM control we need to start a new project immediately.. it's a snake wrapping around linux.. before you know it it's going to be subscription based or under whatever greedy practice.
the arguments over whether systemd is bloat inside the linux community are the equivalnt of slicing thru a handful of sand while standing in a desert.
I hate systemd because it doesn't run in Linux containers without elevated permissions, and even then it doesn't really work right. With Upstart, you could start and stop services in a container without any extra effort. Now I have to write supervisord or bash scripts and it's a pain
I actually complain about CUPS a lot. The past three printers I've had required special PPD's to work with it. For some reason, not a single all-in-one I've had works out of the box.
When I first got into Linux, it took me too long to get that "init" is not short for "isn't it?" in forums. Too long.
Everyone can choose whether to use related programs, software, etc. This is Linux, not quarrels. If everyone really likes Linux, they should treat every contribution with an appreciative attitude. Communicate and cooperate with each other in harmony for the sake of the Linux family. This way we will not be criticized by windows Users look down upon.
11:42 we had back then alike "simpler and comfortable" system opening socket for us - (x)inetd. Wondering why it was long gone before wide adoption of systemd 🤔
I love Linux. I don't really like the drama that gets generated over how people exercise their choices. My take: "If it works for you, then it is good for you". I'm happy for you.
Don't you know you need to have favorites and demand others use them? I mean come on man it's evil if you use thing I don't use, literal evil lol
I can understand why some people made drama because of it. It's similar to the Windows/Mac vs. Linux Desktop debate. Most companies and schools use Windows/Mac, and most applications and games are developed to support only Windows. Consequently, many people have to choose Windows/Mac as their operating system. However, almost all Linux users know how bad those operating systems is. With all major corporations in Linux choosing to use SystemD, it has led most Distros, DE's, WM's, and applications to only develop support for SystemD. This compels most people to choose SystemD. Me myself still using SystemD, i tried RUnit and OpenRC but some important Applications can't run on them, and i don't feel any improvement from SystemD. And I agree with your take: "If it works for you, then it is good for you".
It's a problem when fundamental system building blocks like udev are hard-dependent on systemd. Now it's not "you use what works for you" because what works at all MUST use systemd.
on my gentoo laptop i still use openrc, its much more logical and simple but not for everyone, i get that
Incroyable cette video, depuis le temps que je me posait la question sans vraiment chercher, j'esperait un jour en avoir la motivation, tu l'a fait et c'est fantastique !
Tldr: it tries to do everything at once, and has security vulnerabilities regularly
Like every project, though. Linux kernel and drivers also have CVEs regularly. OpenSSH as well, everything does, doesn’t make them insecure or unsuitable
@@TheLinuxEXP you just stated platitudes. Just because other code has vulns doesn't make all code equivalently insecure. Obviously the judgement of whether something is more or less insecure than is "suitable" is nuanced, no one would use a blatantly insecure software (actually idk, maybe they would.. tiktok?) but people often find it "suitable" do use objectively insecure software (windows being the most obvious). So I think criticising software as having security vulnerabilities implies they think it's less secure than is acceptable.
Anyway, nice video to rile comments 😉
Funny you argue like someone defending Windows at some points. :-D
"Why do I care? My device was shipped with it. As long as it works."
The attack surface wouldn't be the same.
systemd does many things because it does many things, it has a higher attack surface. A init system that does only initialization has a smaller attack vector than systemd.
A total one should be, theoretically, same. It would be just distributed among multiple projects.
systemd-init is just that - only an init system. systemd isn't a piece of software, its an entire suite. So... its the same principle as using different components. Its all different pieces of software. A vulnerability in systemd-networkd doesn't mean system-init is broken, for example.
systemd is not a giant monolith. If you remove components from it, you have to replace them with something else. So on the contrary, splitting the functionality into many projects leads to code repetition and you end up with more code that poses a risk.
I think the reason systemd gets a bad rep is because for most people, the first time they got in touch with it was after swapping/upgrading operating systems, they were suddenly told "the way you have been doing things no longer works. It's systemd time now!". And the most natural reaction by most people was "I don't want that! I want to go back to what I know".
Systemd might have been the best thing since sliced bread, but it didn't advertise to users why it was better than what it was replacing. All users saw was "new", "unfamiliar", "incompatible".
This is one of the hottest topics I used to read on Reddit before starting to use Linux and thought it was a big deal, but as soon as I started using Fedora, I realized that I absolutely don't care about all that. My system boots fast and safely, that's all I care about.
I think systemd is an example of "software written in one mindspcae" instead of "software written for one purpose"
people that write systemd are the same people that would know not only how to implement service management, but other things like logging, user sessions, network managment, etc.
They could have limited the scope, had smaller other projects rather than everything under one umbrella.
The key idea for the revamp of init came from Apple's approach and thinking someone who was infamous for Pulse Audio breaking sound knew anything about that list of management features is funny.
Lennart had his ideas, would relentlessly pursue them ignoring experienced admins, tradition and reasonably expressed requirements.
So he upset a lot of people.
RHEL engineers would have had a lot of input, those suspecting an embrace & extend would occur were correct.
> Imagine someone using the Linux kernel criticizing SystemD for being a huge monolith and violating the Unix philosophy
Monolithic kernel model shouldn't necessarily mean everything ought to be monolithic as well...
Imagine all desktop environments embedded in one single systemd blob? Don't think that would make sense either. :)
Funny, the kernel has dynamic load modules and DOESN'T force you to use a particular C library or compiler ..
Or complaining about the bloat in systemd (or it violating the UNIX principle) while using X11 as their display manager.
@@Ebalosus well.. have you ever tried to type "sys" and hit the TAB during an SSH session in the terminal?
When you do that, there happens to be way too many command options popping all over the screen and you get lost all of a sudden...
And then you go...
"Heck! What was i looking for in the first place?"
It's more like "a command line options hell" right there in front of your eyes.. :)
You can't say the same happens with Xserver tools under any circumstances.
What i'm trying to tell is that, it was always the sysadmins who were hurt by "systemd verbosity" in the first place. Not the regular desktop users.
Then again, Systemd turns out to provide a very smooth experience for regular desktop users indeed.
Not something the sysadmins have been yearning for at all.
@@Ebalosus except anyone complaining about systemd probably hates the X11 situation even more, or doesn't ever leave the console.. so idk what your point is
Looks to me as if systemd is your OS's OS
Systemd is not an 'init' system. It's an event-driven system management suite.
In other words, it's Apple Launchd's concepts adapted to Linux.
There are 2 very good reasons why Systemd developpers have rewritten lots of classical Unix daemns:
1. Those daemons depend on the old scripted 'init' system.
2. Their maintainers have not provided an event-driven system management paradigm version of them, because the guys haven't embraced this paradigm (some even don't understand it).
Besides, the first good old daemons had been adapted by the same team of guys who had invented the 'init' system too, since in 1971, the Unix system developpers amounted to a very small team.
Once again your thoughts and mine coincide. I started back in 1970 on IBM big iron, mid 1990s tried Mark Williams Coherent, thence to Red Hat (pre commercialization). Yes, I do remember LILO. That first install took me a week to gather all the graphics card info and the relevant monitor specs. Finally it was working! Since then I use Debian-based distros since I am into using the tool, not spending all my life "tweaking" it. Linux Mint Cinnamon or LMDE Cinnamon for the win IMHO. I basically want FOSS with no fuss. Keep up the good work.
Essentially, the Linux community will always be the Linux community, no matter how mainstream it becomes.
It's not that I hate it, its the fact that its hard to remember all the specific commands, so yes a GUI with concise documentation and of course concise menu selections would be very very helpful. With the Command line on many tools, i do always have to look up more info either through docs and man, but sometime yes they confuse me, so I do look online to get more clarification. Just being honest, is it getting easier, yes in many areas.
Lennart Poettering (creator of systemd) has "protective dad" characteristic. Which means, he would rule everything because he thinks he knows everything for his kid's best (which in this context, the kid is his systemd). Most of Linux users (including me) are prefer freedom. Thus, it would hurts if somebody rules too much and that's why so many systemd haters here. On the otherhand, big distro like Ubuntu and Arch are chilling because its compact and tightly designed.
I like systemd, the hard dependencies does matter though, as for bloatware what i try to do is use those various components extensivelly.
I don't hate systemd, I dislike it
I'm just a casual guy who happens to use Linux on my desktop computers.
I noticed a speed bump when the distro I used back then switched to systemd (not sure whether it was Kubuntu, Mint KDE or still something else) and was excited.
When I need to tinker with that stuff, I will end up relying some sort of help anyway so it is nothing I personally care about.
In view of the way the project (especially Mr. Lennart Pöttering) deals with security gaps and bugs, however, it must be noted that Systemd unnecessarily increases the attack surface of Linux.
btw: Lennart Poettering has joined Microsoft. - You can't make this shit up!
I recently used a systemd timer to schedule an Rclone script to back up files.
I used to use cron but systemd timers are so much easier. You can actually state the time you wish something to run in English and not use that stupid secret code cron uses. And there was no problem with permissions like I always have with cron.
You do realize that you not understanding how crontab works and is properly set up is an issue on your part? Just for subject's sake:
The Secret code is simply: min - hour - day of month month - day of week
There are 60 minutes in an hour, there are 24 hours in a day, there are between 28 und 31 days in a month and there are 7 days in a week. The secret code consists of exactly that.
The permission part is another thing. Depending on where the file is located you can't execute it as any arbitrary user. That's more or less it. Crontab is fairly simple and the man to it is plenty to get it to work.
Apart from that, systemd is is definitely more user friendly.
@@romancvijanovic7130 If something comes a longer that makes it tiny bit easier in some way, people are going to use that. (insert quote about path of least resistance) It's just how things tend to play out.
@@romancvijanovic7130 I know how the secret code works and there are online calculators to work it out.
But it is an unnecessary complication that only serves to make elitist nerds feel elite.
Edit: I've been using Linux exclusively for 20 years , but I never brought into the cryptic bullshit a small group of adherents insist must be used - such as VIM etc.
I actually use micro text edit because it has *normal* shortcuts
@@VektrumSimulacrum I call bullshit on that! There is no way in hell that writing a bespoke systemd timer unit is easier OR faster than adding a cron job.
@@romancvijanovic7130you are what is wrong with the Linux community. Well done.
When Ubuntu moved to systemd, initially I was a bit reluctant to keep that distro as my main system because of the changes it implied, mainly rewrite convert init configs, and changing a few habits.
Now I'm used to it and find that it makes usually things simpler.
The Linux kernel itself doesn't follow the Unix philosophy by being monolithic