That's comedy gold bro. :) SystemD is so complex, and I barely understand how it works. No wonder why everyone makes Linux web browser installation memes. :)
@@nima2047 funny. I refer to it as that because it's evil (not open) made by the devil (red hat). not to mention it's slow as hell, cumbersome, and takes up way too much disk space compared to what an init system needs.
*Old system:* kernel space --> user space *New system:* kernel space --> system space --> user space The whole idea behind things like a system layer (systemd) or universal package management (flatpak, snap) is to reduce the fragmentation of GNU/Linux. We've desperately needed standardization for years now and hopefully these will help boost development and adoption. The issue comes from the fact that these projects are spearheaded by profit-driven corporations such as Red Hat/IBM, Microsoft, Google, Facebook, etc who have way too much power and control over the direction of open-source and Linux. The main reasons we love Linux is because it's free, open, secure, and protects our privacy. But with these corporations having so much power and control over the direction of the industry, it makes it difficult to trust these things that they push on everyone, such as systemd.
kernel space-->user space = faster than kernel space-->system space-->user space. Less room for bugs in kernel space-->user space compared to kernel space-->system space-->user space. Also, I do believe all these red hat apologists are eating crow here in the year 2023, yes?
@@RillianGrant I agree. I think it's an excellent improvement and the right direction. But, again, my only concern is that we're moving from the community to the corporations.
I think the best solution would be for Systemd to restructure itself to the core service (init and essential files) and optional plugin services (everything else) not installed by default. This way a person could pick and choose how much of Systemd to use, without creating unnecessary bloat.
"eff-stab" sounded strange to me too because its name is pretty much self-explanatory, where it seems to derive from, since it lists all file systems (well, and pseudo ones like swap) to be mounted at boot (unless noauto appears in the opts field). So I wonder how Chris would pronounce its counterpart vfstab on a Solaris box? But as a non-native English speaker I wasn't too bemused because I thought my way of pronouncing it might be wrong. While at it, "et-si" sounded equally strange to me. We are used to pronounce it like the abbreviation for the Latin et cetera (and so forth) - ee-te-ce. Never heard etsi before. But I have to admit that we fall short of pronouncing /usr correctly as it should be (like the former Soviet Union missing the Socialist s) u-s-r, because as few know, it originally stood for "Unix System Resources". I virtually don't know anyone who wouldn't pronounce this directory "user" although it has nothing to do with user accounts. I think in the old days, when it was common to mount /usr as a separate file system some even advised to mount it read-only (by putting an ro in the opts field of fstab) to make life a little bit harder for an intruder, as a kind of hardening measure.
@@othernicksweretaken Apart from file systems, one that I find myself doing all the time, even though I know better is "sudoh" rather than the proper "sudoo". I think the original expression is from " super user do"... i.e., "do whatever as super user".
Hi Chris, really appreciated your video. I'm not an expert, but I switched about a month ago from Linux mint, which is 'systemd' based, to void Linux, who runs 'runit', and i can do everything i used before, but faster... but I agree that the standardization point is one of the main problem and, at the same time, most beautiful feature of Linux because it respect the highly configuration possibilities of GNU/Linux systems, everything is modular and you can pick whatever you prefer. Anyway use what fits better and works for you. Peace ;)
@@saltrocklamp199 THANK YOU! i see so many systemd haters talking about speed, but I feel like it's very negligible. There are so many things that would affect system speed/boot speed orders-of-magnitude more than what your init system is
7:19 udev actually predates systemd. It was an architecture created by the Linux kernel developers to replace the older “devfs”, if anybody remembers that, as a way of managing the ever-increasing variety of hardware that could be connected to a Linux machine, including hotplugging. And I thought it was still maintained by the Linux developers, not as part of the systemd project or anybody else.
Actually systemd boot is previously gummiboot, aka the fast and simple bootloader. The disadvantage of systemd boot is it only supports UEFI, and many package managers are not cooperating with systemd-boot yet. In Manjaro, we have a package that can manage systemd boot on kernel update, It's just like Grub, I don't need to change anything after setting it up and it's 2 times faster than grub
@@budimanjojo4456, systemd-boot is renamed gummiboot. Only thing it can do is launching other efi programs (like linux kernel with efistub), so when you need have kernel on luks on lvm, you have to use grub. That is why general purpose distros don't default to it.
@@vladisimusI You've got thing wrong man, gummiboot was merged into systemd and become systemd-boot. Gummiboot is a very old project, long before systemd was the default init on every linux distributions (I used it before and failed so I know). Here's the news from 2015 where gummiboot got merged into systemd: www.phoronix.com/scan.php?page=news_item&px=Gummiboot-Is-Dead
Systemd timers are really great. I think is a modern approach to chron jobs. You should really look into it if you haven't yet. It's great to have the possibility to interact with them throw systemctl for status, etc..
I really wish distrubutions had a way to split up systemd, so instead of just download `systemd` you could download only the things you need like `systemd-init`, `systemd-boot` and `systemd-timesyncd`
Problem with that is systemd is not really modular. The systemd proponents will claim "it's modular, it's distributed in multiple files", but check the output of ldd on any of those files and you'll see that they hard-depend on each other. For the parts of systemd where it offers functionality not provided by other packages, there are community projects which extract and stub-out the parts, you can use them in Arch, Gentoo, and other advanced distros. They are eudev, and elogind (and possibly others). There are also projects like sdnotify, written in python, to reimplement some functionality of systemd.
No idea what you're talking about. systemd-init would have to be the service that starts daemons, you need that or nothing is going to start. I don't seem to have a systemd-boot or systemd-timesyncd anywhere on my system. systemd is well designed and modular. The services only depend on each other when they need to, the next post about ldd is way off base too.
@@danespen5772 You can check if you have systemd-boot if you have the command bootctl. If you have systemd-timesyncd you should have the command timedatectl. I am not aware of any distubutions that disables these by default so unless you have compiled systemd yourself you should have them
I personally prefer systemd timers instead of cron. Because it has journald integrated, so you can see the log when things fail. It also gives you when the next trigger will happen and stuffs like that. Also, if your system is not on 24 hours, cron will not trigger it on next boot. For example, you have a daily job that happens on 9 a.m, but your computer is not on that time, cron will not trigger that day job at all, but systemd will know that that job has to be done, so if you turn on your system on 10a.m, systemd will still do it for you so your daily job is done. Also, people hate systemd because it tries to do everything, but that's also the benefit of systemd for me. I don't even have grub and cronie package installed anymore on my system, and that's a good thing for me. And it's not breaking on my end for the last 3 years, so those haters saying systemd broke their systems are not relevant anymore.
🤷🏻♀️I like to start with a very minimal system, basically a shell and a package manager, and install only those features I need. Anacron does what you are looking for on systems that aren't on 24/7, so if that was something I required, I would install that package.
Agreed, I *hate* Windows. I literally needed tons of registry tweaks and GUI modifications that took 2 weeks to finish. Meanwhile with Linux it only took 3-7 days and I'm up and running. As soon as WINE can run LSPDFR and respect anticheat, I'm deleting my Windows partition, or just isolating it in a VM.
I don't really mind systemd but I would actually like if it were to be a bit more broken up into seperate packages so you can only grab the init system and udev if that's what you want but can leave out all the other stuff. You should probably install something like void on another machine of yours just to play around with it. Just to widen your horizon. It's honestly kind of insane how fast it boots etc
It introduces some other neat features. Like the randomized delay option in timers, so you can define a bunch of cleanup tasks to all run nominally at midnight, and it can automatically spread them out a bit so they don’t all kick off at once. Also the fact that system log timestamps are now recorded in UTC, not some arbitrary “local” timezone. The more you look, the more nice things you find.
12:15 As I recall, one of the design goals for systemd-mountd was the ability to impose a hard limit on how long dirty filesystem data would remain in the cache. For example Lennart wanted to be able to guarantee a maximum of 1 second before the cache was flushed on USB sticks, to cater for the all-too-common case where users pull the stick out without remembering to unmount it. This way, they would be more likely to keep their data, rather than end up with a corrupted stick.
Proud user of OpenRC. Udev is great, it was actually there before SystemD, until systemD did absorb it :) Fortunately, udev got forked into eudev after being absorbed by systemd as not everyone want to run systemd and udev is/was kind if a essential part of Linux. Same for gummiboot (the bootloader that got absorbed into systemd and renamed into systemd-boot)
I moved all my cron Jobs to systemd timers and really enjoy the configurability of systemd. It takes a bit to get used to it, but its also really well integrated into the systemd services side of things.
I actually use the systemd boot loader in many production machines. Is soooo easy to configure and change parameters to the kernel. GRUB is a titanic mess with way too many features for a simple boot manager.
Runit from a technical aspect is better than systemd. It is faster than systemd and of course lighter and simpler than systemd. So with the existance of Runit there is no reason to have systemd. There are also articles about systemd and nsa bachdoors. We have 2 b carefull!
I really like how systemd can manage my socket servers and dbus interfaces and start my services on demand. It is nice to have one process using a single select/poll/epoll system call than a bunch of individual processes running and using their own blocking system calls as they wait for IPC.
systemd does some things right. Personally, I love the systemctl feature, it makes many things easier. I also use systemd-boot. Nice thing for a single-boot system. However, I am strictly against systemd slowly taking over the entire OS. In all, systemd-linuxd isn't at all far-fetched, given the fact that Poettering has announced systemd as the »core OS« as early as 7 years ago. And this is where things are going to be very dangerous. On the long run, systemd aims to make Linux obsolete. We might end up with a hard-wired core OS similar to Raspberry Pi you can never get rid of, despite whatever distro you choose to install. People should carefully reflect on whether or not they will want that. I don't. I'm thinking of ways to get around systemd, probably going to switch from Arch to Artix. The ubiquity of systemd might also narrow down the choices of alternatives on the long run. I would also rather not promote something as questionable as Clear Linux, really. People praise the freedom of choice in Linux. I feel we will have lost most of that not too long from now.
Agreed, systemctl is the best and systemd is the most supported init system. I don't get the hate behind systemd, it's just an init system. It's not like Windows where it's an entire OS.
@@justsomerandompersononthei2595 Well, it's written in my comment. systemd is in fact much more than a simple init system. It is in fact an entire system of low-level demons, which in itself isn't a problem either. The problem I see with systemd is that it aims to take control over areas it simply shouldn't touch to begin with. Like why does it need a daemon to mount the home partition? Also, Lennart Poettering's notion of systemd as the »core OS« feels quite spooky to me. On the other hand, I'm getting tired of people who deliberately mistake and discredit opposite opinions as »hate«. Just because I don't want something, it doesn't mean I hate it. Frankly, even if I say I hate something, it almost never means that I literally hate it. To me, it's synonymous with »I don't want it«. People these days need to relearn that not every word is to be taken literally, and that their opinion is not a law all the world needs to follow.
At first, I was agnostic to systemd, I didn't know if it was good or bad because I had tried nothing else. One day, I decided that I really wanted to try a distro without system. I installed artix linux instead of arch and chose runit as the init system. I know understand the pros and cons of systemd very clearly. My overall opinion is that systemd is a more powerful, complex, and bloated init system that is more suited for servers. It offers more options for process management and serveillance. However, for a home user lighter systems like runit are much better. I can boot much quicker than with systemd, and having less options makes it much easier for me to manage my processes. Also, since the servicesare simply bash scripts stored in a directory, they are easier to modify and identify if you are used to shell scripting. You don't need to know all the systemd options in order to use its full power.
wait! what?!? systemd as a bootloader?!? that, sir, is totally mind blowing to me! i paused the vid and searched the web about it. I have something interesting to learn tonight, thank you for that Chris.
systemd is a tool in search of a problem to solve. Many of it's parts are under documented and worse versions of other tools, so it's just extra crap. As for the rest... complication is the real enemy. If you can have a 20-30 min video that explains the basics of systemd, then that's the real problem. Here's my video on init.d: Put scripts in /etc/init.d, symlink them into a runlevel, done, you understand everything, simplicity is power.
I literally spent a hour trying to figure out why name resolution was broken through systemd's caching daemon on a ubuntu 20 server after making some network changes. It was listening where it needed to, but would send a fail for any queries. Decided I had had enough of peeling back onion layers and moved all my servers to alpine. Which btw, is vastly better than ubuntu on servers anyway, the install is far smaller, easier to understand and work with, boots in a second, it's great. It's funny to me how you mentioned that people don't like the boot performance cost of systemd..... Boot performance was litterally one of the main things it was trying to improve! XD Better dependency trees for parallel launching, etc, but it fails at even that apparently.
Udev was a separate daemon before it was integrated into systemd. Now we can't use it without systemd. Dns in systemd introduced decade old security BUGS. Systemd logger is loosing log lines. That is a problem, and systemd developers will not fix it. Which is a bad way handling their users Their implementation of ntp are not good enough to run on server. Systemd initial ideas was good, bloating it and its strong NIH are bad. It is not making clean interfaces between core systemd initial system and externa services. That is bad. And it is in any practice a monolith, which is bad for a system program. Because it doesn't have clean interfaces so we can't exchange with different, better implementation.
Interesting. Debian Developer here, Ubuntu and Debian distros I professioinally use. I am using systemd-networkd/resolved/timedatectl for interfaces, DNS, and system NTP client/system clock BECAUSE it is consistent and handles IPV6 addressing really well. Debian/Ubuntu ifupdown has a real issue properly disabling IPv6 RA address assignment when you want static IPv6 addressing for a server (networkd disables RA completely, clears IPv6 RA dynamic addresses, and all this seems to pop out of the box again with ifupdown), resolved when you look at it is better than dnsmasq for handling DNS over a VPN, chrony/ntpd is not needed when all you need is a simple NTP client. I use Network manager when I have a desktop or laptop though.
@@ChrisTitusTech Hi, good video but you have several deep mistakes in this video that would make a nice second part revision: 1.) systemd-boot does have a menu wiki.archlinux.org/index.php/systemd-boot check the loader configuration. 2.) systemd-boot is vastly superior to grub in case you have UEFI because is basically hack free, doesn't load a pseudo kernel to boot a kernel like grub does, does not require driver support and is basically the best way to boot complex systems like ZFS root over ISCSI(or local) whereas GRUB support is been completely broken for a while. basically if the kernel supports it, systemd-boot can boot it no matter how crazy it the combination is. 3.) systemd-boot misses some cool GUI which grub kinda have in some distros. 4.) systemd-network is not redundant and is not meant to replace network-manager, its main usage is for REALTIME ON DEMAND containers spawning and in my experience nothing beat it speed wise, like order of magnitudes faster than networkmanager, netctl, etc. 5.) systemd-resolved/timesync/etc. can be used for both Desktop and Server but their main function again is for containers which again is insanely fast and have the added perk of TRUSTWORTHY synchronization, no more random times on your containers because ntp or hwclock went full retard for unknown reasons. 6.) Cronie and company is fine for most desktops but if you read the documentation of what timers are actually capable of, you will realize cron is not even on the same league, sure it has a learning curve but for server/container/embedded handling timers are just insanely better with several game changing features in security, resource usage, feedback, etc. 7.) systemd-x or y: is not bloat because they are not active by default(unless your distro went full retard and enabled every systemd service against systemd's recommendations), is just a bunch of several few Kb sitting in /usr/bin doing nothing at all in the same way coreutils put a bunch on binaries on /usr/bin that do nothing unless you execute them. Also remember systemd is not a DESKTOP init system but an init system hence is also meant for virtualization, servers and embedded and several tools are meant for those which is why systemd does not enable all the services by default(again otherwise is the distros fault) and in this other scenarios many of this tool are way superior and widely used and are not meant to compete with bigger desktop variants but can be used in parallel tho.
Systemd SUCKS! The reason you don't hate as much as the rest of us is because you're a windows admin who uses Linux, but still relatively new to it, compared to those of us who have been using Linux for 15 or 20 years.
Note that even with /etc/fstab, it's most likely that the actual fsck/mount actions are performed by systemd, when you're on a systemd-based system. /etc/fstab is just another way to write mount units..
PopOS uses Systemd, they also have KernelStub installed to help edit kernel parameters. I used KernelStub for the VFIO passthrough to give a GPU to a windows guest KVM. It's pretty nice to use with Systemd
I love systemd. Two of the fastest distros are ClearLinux and Solus, both use systemd and even systemd-boot. The performance is just unmatch by any other distro, especially boot time. I get like 4s boot time on Solus even in Legacy BIOS
You need to know that Solus also doesn't have tons of useless services enabled by default like most distros does, like Ubuntu and Mint. It just enables the essential.
@@natri23 I hope that systemd-boot will have a beautiful interface and compatible with LVM in the future, that's the only reasons why people are still using grub.
Coming in as a relative linux/computer-science noob (on a 4yr old video): is the lag in booting still an issue on distros that use systemd’s boot loader? You mentioned it it’s not as slow on systems that use it, but it wasn’t clear if the difference completely refutes the criticism of lag (relative to other innit systems) or if it’s just better than typical systemd implementations (that don’t make use of systemd’s boot loader/other features). I also understand that there’s some philosophical criticisms of systemd-a single system doing a lot of things (and thus have a lot of things depend on it) rather than “the Unix way” of many small programs working together. From your appreciation of the standardization that systemd brought, it seems like it was a good thing that systemd went against the grain in this specific instance. Finally, I heard elsewhere that systemd becoming somewhat more modular in response to the xz vulnerability (was that the name of it?). Do you think that might help systemd’s reception and use? Do you think it might hurt the standardization it brought?
Things I’ve learned is you have to configure things the systemd way AND the traditional way a lot of the time. File descriptors? Gotta change it in like 3 different places. resolved is improved but a mess. I’ve had it mess with my network DNS settings. The timer stuff is bloat, the whole thing is bloat. The old stuff does its stuff right and well. Systemd takes over too much. It also makes for lazy development. Can’t remember the package where I saw this, but Lennart basically told the devs “do it my way or F U”. Boot times faster? TBH, I’ve found Devuan boot up much faster and even FEEL faster than Debian. I don’t mind systemd as an init system. It’s pretty easy to make a simple service file. I just did the other day. Great. Having a hivemind init system is bad though. Like anything, having a monopoly on tech is bad. I can’t call Linux, Linux anymore with systemd. Void, Devuan. That’s Linux. And they are much more true to what Linux IS and the UNIX philosophy. Sadly, mainstream Linux is just trying to emulate Windows
Server management have been much better since systemd. This is why actual production distros (RHEL, Ubuntu, AlmaLinux, Fedora, etc) uses systemd. The standardisation is really important when you start working in non personal consumption environment.
at 5:02 you are talking about systemd having services that are like duplicate by other packages that come pre installed with the OS. So in that case which of the services (OS - or systemd) takes lead in initialization first?
Damn Chris, your a beast! I cannot find the vids any more I need to refresh my memory. AWESOME work, keep going Chris 👍🏻 👍🏻 👍🏻 Greetings from Netherland
It feels very strange when people says systemd is slower than old systems. One of the reason of it's creation was to parallelize tasks, by making listening sockets for services, so that you can start services in any order and in parrallel, sockets will accept requests (still don't response) before the service is started. In part, there is this 1 min 30 default value for when it wait for something that don't seems to happen... and more than not, I guess this is because of services not configured the right way yet.
It's quite funny how some view those who oppose systemd as "haters". I find that starting services with OpenRC is much simpler and the learning curve for systemd very steep. I could understand some of these people if systemd were a true init system, but it tries to do way too much. Much more than any other init system. Then you have the other problem - other OS components and programs that have hard dependencies on systemd. We have truly strayed from our Unix roots. I started out on Gentoo back in 2007, returned to it in 2013, and have been on Artix since 2016 because I didn't have time to deal with system updates in Gentoo. Because Artix is also on OpenRC, it will be easy to chroot into my Gentoo system and do a massive update soon.
I love systemd. I love how fast and responsive networkd is at reacquiring after a drop. Lots of other great functionality in timers. I don't use 'cron' anymore and systemd mount with NFS is miles ahead of FSTAB. The system won't hang if a remote system is not yet UP, it will come back around periodically instead. Far superior IMO.
Using Linux since 25 years I refrained from updating and maintenance whenever possible. Instead I installed a new version of the operating system. With the arrival of systemd I completely changed my procedures. systemd has become a standard and works the same way in all distributions using it. If you turn one of its components off its turned off; no annoyances encountered. On openSUSE Tumbleweed I disabled both wicked and NetworkManager. I enabled systemd-networkd.service and configured a static interface: [Match] Name=enp0s31f6 [Network] Address=192.168.178.2/24 Gateway=192.168.178.1 That's all I need. No bloat whatsoever, fast as hell and extremely reliable.
I use systemd-boot on Arch and I like it, prefer it over grub actually. The main reason is that it is just a text file to edit on your /boot vfat partition to add an entry in the boot menu or add kernel parameters. There is no command to execute to update the boot menu. All in all, I like systemd: the main benefit as you pointed out being the standardization, no chkconfig or update-rc depending on your system. I also use it to start user services, not relying on XDG autostart, it is more portable depending on your desktop environment. You can also start services on different events: device attached, port opened, mounted directory, etc.
Finally, I know what is this systemd hate about. Thank you! As an average user, this systemd hate thing is just a curiosity and nothing that I was concerned with. A lot of smarter people decide to use if for the most systems so it has to have some good points and I suspect, the list if pros (and probably cons) is much bigger than you just pointed out, but we don't need all the details. Thanks!
the average users are the ones who broke linux philosopy. its why systemd got through, ubuntu with intrusive snapd etc. might as well just let microsoft handle linux, or maybe apple. its not just about "it works so its ok. its about keeping the users "freedom" regardless if you wants to or not
@@UnworthyUnbeliever Nope, Snapp and other containerized solutions were created to make developing software for linux easier. I don't like it, but I don't have any better ideas so I'll leave it at that.
@@UnworthyUnbeliever snap has nothing to do with the app stores, you can install the other packaging types through the app store too, in fact, they've been around in some form even before the mobile ones came out. Also, package developers as you put it are a varied group of people, working on different things and with different interests. Canonical came up with snaps, and gnu came with flatpak, both are based on something similar to docker, if I'm not mistaken, which has been around for some time for web development environments. It makes it easier for developers which in turn gives linux better support as whole. There's a lot to be said about it, but your elitist conspiracy has nothing to do with it.
@@redtide9055 actually systemd and containerisation comes from server use case. Large providers need a standardised way to deploy and maintain servers and services.
Thank you, Chris. A good and helpful summary. I too have never found any real reason to object to systemd. Bloat does no really matter for my main beastly box (System 76 Leopard) and other boxen.
4 роки тому+4
Yeah, I have mixed feelings about systemd, too. It's a love/hate relationship. On one hand, it's a total bloated mess, but on the other, it makes system maintenance simpler and easier... I don't hate it nearly as much as I hate snapd :D
The boot speed of my PC is near instant with systemd. How much faster does Lunduke need it to be? Could you a tutorial video on booting with systemd and automounting like Clear Linux? Maybe include some of the other great features no one else is using.
One of the biggest *problems* with systemd is the existence of /etc/init.d. You say you can use stuff in /etc/init.d still, for legacy support, but it doesn't *work*. This is actually where lots of the hate comes from. When Debian switched to systemd such that you'd get it on a fresh install or an upgrade, there was fairly little fanfare. So us poor system admins figured it'd be like any other init system, toss your scripts in /etc/init.d and away you go. If init.d were removed, we'd have figured out something was up and checked the manual (which wouldn't have helped, as systemd's documentation is terrible, out of date, and *wrong*), and known something was up. As it was, the directory still exists, but changes there are generally ignored. I spent about 6 hours kicking the darn thing back in about 2012, before switching away from Debian over the matter.
Hey Chris! Your assumption of systemd-boot not having a menu to edit or choose entries, is wrong. By default, the menu timeout is 0 seconds, tho. You can edit the loader.conf file to change this. Or you can press and hold a key during boot and it is supposed to show up (I cannot test it because my EFI doesn't enable the EFI keyboard driver in non-CSM mode). While in the menu, you can choose an entry and press "e" to edit it just like in grub.
There are some problems with systemd. It's monolithic a.k.a. a "single point of failure" and it's becoming defacto making it hard to replace for folks who don't like it, you can't simply remove it and install something else because there are apps that depend on systemd functions, you have to switch to another distribution. Same goes for Linux kernel. That being said I don't even use systemd, I just do my usual computing and it does it's stuff on the background and in case of Linux kernel, it works and that's all that matters. So I don't think I'll ever replace them unless they pose a threat to my digital security or privacy since they don't have an impact on my user experience, but they still have their problems.
I've been in the process of transitioning from Manjaro to Arch, and during my research I came across Artix Linux as a systemd free alternative, currently testing out Artix OpenRC on my server so see how well it runs in comparison. It's an interesting process. I personally don't hate systemd, but I like the idea of being able to choose which init system we want to use, there is also runit and s6 options. It would be refreshing if more distros would have the alternatives available as well, or even the option to remove unused systemd orphans.
The reason I don't like systemd (or its 'bloat' part) is that controlling the enabled/disabled/running services is tough now. I used to be able to finely control exactly what services are running, disable useless ones, but now there is such a large number of them even in a mini-install. I have no idea what many of them are doing or why they are enabled. As a result one has to just ignore all those starting with 'system' or timers etc. Thankfully I don't need to deal with
I used to to hate on systemd. I never knew myself why, but after a while, the hate just doesn't justify. If many distros are using it, then they must have a very good reason for it. In the end, as long as my system works; an ecosystem is important. I entirely agree the fact that there's standardization for systemd, which is what the linux community should be getting. No standards === mess
So basically he's saying: " I don't mind systemd, because I know how to circumvent it and manipulate it. But I'm not sharing with you how to do that. I wouldn't have power over doing that. "
Linux/Unix/GNU philosophy is to do one thing and do it well. Systemd violates that. It's not really a problem for me unless things get overly complicated. This thing about replacing the home dir with homed or whatever sounds like a horrible idea.
I use the systemd-bootloader on Arch and I didn't have any problems with it since... and always when I see people complaining they shot GRUB in the foot, I question why they all have to use it. I've never seen a reddit post of someone having problems with systemd-boot... ^^' Btw I also have a dualboot setup (so it's wrong that it can not dualboot)... it's actually pretty easy to use for a dualboot setup since it locates a Windows partition automatically and adds an entry for it without configuring. Adding entries for specific kernels or parameters is also pretty easy and clean. The downside is maybe customization of your bootmenu... (I haven't checked yet if it is possible to change background etc.) but it's not necessary in my opinion.
4:30 *No,* dnsmasq is not an alternative to systemd-resolved. dnsmasq is an alternative to BIND. dnsmasq is a lightweight DNS server; BIND is a heavyweight DNS server (used across much of the Internet); systemd-resolved is a DNS *client,* not a server.
journalctl -x and -e for error??? no -e is for going to the end... -x augment log lines with explanation texts from the message catalog -p[level] determine the priority level. "emerg" (0), "alert" (1), "crit" (2), "err" (3), "warning" (4), "notice" (5), "info" (6), "debug" (7). So if you want errors or higher priority (lower-level ... which is strange)... then use journalctl -p3 ... -p4 for warning or higher priority... -p5 for notice or higher. The most important option is probably -b ... because if you don't use it, you have the full log and it can be from months back to now, so -b 0 is the current boot session (since you booted to now), -1 is the previous boot session, -2 the session before -1, etc.
I am learning how to manage services in my recently installed Arch Linux system, I have heard the systemd is reviled but I didn't know why. I know people like apps that focus on doing one thing and doing it well. but honestly, since systemd is already on my system and I don't know how to replace it I am tempted to look up the full breadth of what it can do and for instance uninstall grub if it can be a bootloader in its place. as always, thanks for the info 👍🏽
What I love about systemd is that it gives me easy access to kernel functions like namespaces, CGroups and capabilities without having to modify the init script. This way I can better protect services without using frameworks like SELinux or AppArmor.
1) Anyone should be wary of any init system that has 1.3 million lines of code 2) The "developer" of it spends a whole lot of time replying to Github's posts, shouldn't he be "developing"?? 3) Anyone should be wary of a software that is never finished, that is never properly delivered in a final state. SPECIALLY something with such a limited scope as an Init system... systemd is good for the person, to keep the guy's job, not for the software or the system itself...
Um, Gentoo doesn't use a legacy init system. That's FUD. Gentoo's init system started around the same time as systemd, taking the neat ideas (parallel init (which debian already had, but was unreliable), dependency based startup order, non-duplicating init scripts), but not integrating them with everything else, not being buggy and unstable (boot races were common in systemd at the time), and actually supporting legacy init scripts (anything in /etc/init.d with #!/bin/bash at the top generates a warning, but still works as intended). It's called OpenRC, and it's far nicer, and far easier to use than systemd init (and *also* faster).
is that really all you gathered from this? chris has voiced his opinions to why he prefers linux over windows on several occasions before, the part that it is faster than windows is a minor point on that list. Dont like something in linux? change it or get some elbow grease and make something superior.
@@HikariKnight First, I do love linux. I have been using it on and off since the late nineties. I have not used windows in months. I am currently using my linux mint laptop. Second, I get that it is only a minor point and no, it is not the only thing I got from this. Surely, it is still ok for me to respond to it? Third, linux (including systemd) should be about making the best technology we can without bloat. Our benchmark should not be "Is it better than Windows?" Windows is getting worse and worse. If linux merely stays better, than it will get worse and worse too.
2:50 The traditional way of doing system logging was with syslog, where a bunch of text files get appended to in /var/log/. systemd replaces these with binary “journal” logfiles. Some Unix traditionalists hate this, but it has some nice benefits. One I like is that timestamps are in UTC, rather than some “system default” timezone, and journal entries can be formatted with timestamps in any timezone you choose. Another is the ease of selecting entries based on various criteria, rather than trying to invent elaborate grep match patterns.
I think the reason behind system.d being the way it is is that it hopes in the future, every Linux distro wouldn't need additional packages to do scheduled tasks, bootloading, mounting drives and so on on top of initializing the OS, and would instead use the pre-included speedy and tiny integrated systemd features which is what Clear Linux is doing. And considering the speed of Clear Linux, maybe system.d was wise for being "bloat".
I have a Dual Boot Windows / Pop_OS / Majaro laptop (Installed in that order) Pop_OS does use systemd boot and Majaro replaced it with Grub boot. One one hand, the boot loader in Grub is something I can get to grips with and looks very easy to customise. Getting Grub and Pop_OS to boot reliably was a bit of a journey though. I had to customise Grub using Grub Customizer to boot Pop_OS on the partition UUID rather than the device name. The biggest issue was updating Pop_OS, which updated Systemd and the bootloader. I had to use a USB stick to get a boot menu, to find the Majaro bootable partition and then used Grub Customizer to re-write the MBR and update the Grub Boot loader.
You've forgot to call out Devuan. It's a fork of Debian without Systemd, and having installed it, it offers a very Debian-like experience. And yes, it does boot faster :)
I believe the 'beards don't like SystemD because of a few things: 1) Do one thing and do it well. (the *nix golden rule) 2) Always prefer human readable txt for everything and avoid binary data. On 1), SystemD does booting and logging plus a whole bunch of other things instead of just booting, or alternatively just logging or etc etc. On 2) SystemD has the logging aspect which is all binary data - you need to use the control program to view the log output yourself. SystemD does boot much faster than what was there before - I believe the main reason is that all of the interdependencies of services are specced up by the authors? - which means SystemD can put everything into a graph of dependencies and perform steps massively in parallel, reducing wait times.
Thanks for the Info. Is my impression right, that a good part of the redundancy aspect of systemd is a thing that's done for compatibility, I. E. The systemd-boot that requires UEFI? I mean look at the outcry when Ubuntu removed 32 Bit support, and AFAIK UEFI was broadly in use quite a time after 64 Bit systems were basically the norm. Also about that systemd timer system, what's making that so uncomfortable, is it just that it offers features noone uses, which makes config more difficult, or something else?
I love how people take guesses at why systemd got so much hate, without actually finding someone who heaped tonnes of hate on it to ask. The issues you list are valid, and if you ask some old timer what the underlying problems with systemd are, they are likely to feature prominently. But if you ask the people with the real vitriol for systemd, you'll get some variant of "it just doesn't work". That's because about 8 years ago, it just would fail, spectacularly. You mention using a dependency graph for parallel startup. Sounds neat. SystemD put that dependency graph into an unordered key-value map. Which meant that the order of startup was non-deterministic. Which meant, in conjunction with service files which were still new and didn't have fully complete dependency information, random hangs at boot due to race conditions and missed dependencies. That's something debian's Makefile-Style-concurrent boot had struggled with for years (and if you wanted support for something, you had to turn that off). The difference is that, once you found the problem in debian's MSCB, your system would thenafter boot properly, because Make uses predictable ordering of orthogonal components (ones listed higher in the file, or files sorted alphanumerically sooner boot first). SystemD, meanwhile, gave sysadmins *no* ability to specify boot order except for editing service files, which would have to be re-edited on every system upgrade. That was the number 1 tech support issue I had with systemd for about the first 5 years of the project. I honestly don't know if the underlying problem is resolved, or if unit files just actually have complete dependencies so it no longer matters.
While I am not a Linux neck-beard, I have heard of the hatred to this and the best understanding I have managed to gleen from what is on UA-cam up to now was that it was not designed 'in the Linux style', whatever that means. While I understand that there are several parts that many Linux users don't use or are not as good as many other packages, if people don't like it being there and taking up resources why not fork the systemd project and simply delete that part of the code? It seems like the hate far outstrips what is otherwise a very useful package that I can't really see taking up that much in the way of system resources.
Instead of start services one by one and checking if it is start, it start all services then restart services which didn't start properly first time. Which is stupid way to start a system.
Sen ne düşünüyorsun hocam ya timer falan diyor timerı başka şeyle de yapabilirsin çok kolayca. Ve de systemd dışındaki sistemlerde zaten scriptlerle çalışıyorsun kod kısa uzun fark etmiyor ki.
I utilize systemd-boot with a dual-boot + boot menu perfectly fine. I'm running an arch linux sharing windows with an nvme drive and have never had an issue. The boot menu can be easily enabled, and indeed as the ability to edit options inside of it! I've not found any of the limitations you've mentioned.
I don't use the systemd bootloader, per se, but I do use the efi stub to build a unified kernel image that is signed for secure boot right into a prompt to unlock FDE. I'm waiting for my next weekend to implement TPM2 key storage and make the whole process faster and easier. I'm not worried about the Feds seizing my hardware and delaminating ICs to break in, so I would like to have the key storage implemented.
One thing i dislike about systemd is that it's service management can not be used on other init systems which severely harms interoperability with other init systems. In comparison if i wanted to i could run the runit service manager under systemd without issues.
Where to begin...Systemd is an attempt to standardize a world in which there pretty much are no standards. There are spec out there that say what normally goes in /etc or /var, or how apps can add themselves to the menus in Gnome, XFCE, or KDE, etc., but in reality everyone is free to do what ever they want in Linux. The 'specs' out there that define the common settings for a system really just amounts to 'friendly suggestions' if you want a system that's easier to migrate to from another system and it's easier for software to be written against a common set of standards. Systemd's biggest issue for a lot of vets is the migration away from the 'friendly suggestions' to if you use this, it will be done only this one way. This is pretty problematic when wanting to design and run a more efficient system for accomplishing the same thing, while still liking some of the things systemd can do for you. That and, one of the biggest allures of Linux is still "you can now do things your way" so since systemd flies in the face of that were you must now 'accept the bloat', I take issue with it. I personally don't think systemd and other standardization will break the Linux world and there really are a lot of good things it does (and I do use it), BUT, there's a price to pay for it and that is in software bloat and lack of freedom. The old init system wasn't perfect, but every distribution had their own 'personality' with it as they strove to make the best system they could with their own way of doing things. On one hand you'd have to figure out the quirks in the init system in different distros every time you distro hopped and not every distro would be as easy to manage depending on what you came from vs what you were moving to. On other hand, it still wasn't terrible to move from one to the other, and you'd constantly see new ideas being done in each distro that others would pick up and use or maybe they'd take them and "fix it" and improve upon them. This is still being done to this day, but when everyone uses the same system for everything, what do they have to look forward to and improve upon? You loose some of the creativity if everyone just agrees to follow the same standard while gaining familiarity and easier adoption. It's a give and take really and everyone's on a different part of the spectrum. In the end, we'll survive, and I'm sure someone will fork systemd and make a newer, better, and more efficient version in time, or just come up with something completely different and we'll be here again having the same debate...again. :)
Maybe someday somebody will follow up on systemd and make it worthwhile. For the creator it was so difficult to get praise, for a system that reminded most people of Windows start up with their lack of security. As the creator said "never finished and never complete, but tracking progress of technology ." The white elephant is too big to repair, the old system was individual pieces easy to fix.The big fear! One major hack and we're all screwed!
Missed opportunity for a pun, Why Systemd is the daemon
That's comedy gold bro. :) SystemD is so complex, and I barely understand how it works. No wonder why everyone makes Linux web browser installation memes. :)
They refer to it as a daemon because it is handling service processes silently and almost invisible. Just like daemons do :)
@@nima2047 funny. I refer to it as that because it's evil (not open) made by the devil (red hat). not to mention it's slow as hell, cumbersome, and takes up way too much disk space compared to what an init system needs.
@@darkcggaming well akshually
It rules over daemons - therefore it's Devil
*Old system:* kernel space --> user space
*New system:* kernel space --> system space --> user space
The whole idea behind things like a system layer (systemd) or universal package management (flatpak, snap) is to reduce the fragmentation of GNU/Linux. We've desperately needed standardization for years now and hopefully these will help boost development and adoption. The issue comes from the fact that these projects are spearheaded by profit-driven corporations such as Red Hat/IBM, Microsoft, Google, Facebook, etc who have way too much power and control over the direction of open-source and Linux. The main reasons we love Linux is because it's free, open, secure, and protects our privacy. But with these corporations having so much power and control over the direction of the industry, it makes it difficult to trust these things that they push on everyone, such as systemd.
kernel space-->user space = faster than kernel space-->system space-->user space. Less room for bugs in kernel space-->user space compared to kernel space-->system space-->user space. Also, I do believe all these red hat apologists are eating crow here in the year 2023, yes?
@@joshuacrumley2031idk systemd looks like it does a lot of very cool stuff that'd otherwise be a massive pain to manage.
incorrect.
@@RillianGrant I agree. I think it's an excellent improvement and the right direction. But, again, my only concern is that we're moving from the community to the corporations.
I think the best solution would be for Systemd to restructure itself to the core service (init and essential files) and optional plugin services (everything else) not installed by default. This way a person could pick and choose how much of Systemd to use, without creating unnecessary bloat.
f-stab ... Now that's a neat way to pronounce it. Personally I say "f s tab" (eff ess tab) as in "file system table". =)
Yup that is the proper way, I just like shortening it to two syllables and because it just sounds cooler lol.
@Donald Mickunas same here, it is just so much faster to say too
"eeeeeeeffffff eeeeeeesssssss tab", but "ef stab"? Lol
"eff-stab" sounded strange to me too because its name is pretty much self-explanatory, where it seems to derive from, since it lists all file systems (well, and pseudo ones like swap) to be mounted at boot (unless noauto appears in the opts field).
So I wonder how Chris would pronounce its counterpart vfstab on a Solaris box?
But as a non-native English speaker I wasn't too bemused because I thought my way of pronouncing it might be wrong.
While at it, "et-si" sounded equally strange to me.
We are used to pronounce it like the abbreviation for the Latin et cetera (and so forth) - ee-te-ce. Never heard etsi before.
But I have to admit that we fall short of pronouncing /usr correctly as it should be (like the former Soviet Union missing the Socialist s) u-s-r, because as few know, it originally stood for "Unix System Resources".
I virtually don't know anyone who wouldn't pronounce this directory "user" although it has nothing to do with user accounts.
I think in the old days, when it was common to mount /usr as a separate file system some even advised to mount it read-only (by putting an ro in the opts field of fstab) to make life a little bit harder for an intruder, as a kind of hardening measure.
@@othernicksweretaken Apart from file systems, one that I find myself doing all the time, even though I know better is "sudoh" rather than the proper "sudoo". I think the original expression is from " super user do"... i.e., "do whatever as super user".
Hi Chris, really appreciated your video.
I'm not an expert, but I switched about a month ago from Linux mint, which is 'systemd' based, to void Linux, who runs 'runit', and i can do everything i used before, but faster... but I agree that the standardization point is one of the main problem and, at the same time, most beautiful feature of Linux because it respect the highly configuration possibilities of GNU/Linux systems, everything is modular and you can pick whatever you prefer.
Anyway use what fits better and works for you. Peace ;)
Void is defintly my favorite linux distribution, runit boots lightning fast and service management is very KISS-esque
I doubt that the init / service supervisor is changing the performance of the system after booting.
@@saltrocklamp199 THANK YOU! i see so many systemd haters talking about speed, but I feel like it's very negligible. There are so many things that would affect system speed/boot speed orders-of-magnitude more than what your init system is
I'm just wating for a version of SystemD as it's own actual OS...
You could call it "SystemDOS" :D
It's systemd and not SystemD but nevermind
SystemD OS
or SystemDOS
or just DOS but better
systemd-kerneld
@@uumas8427 System-boot/Pulseaudio/Systemd/Wayland/X11/Gnome3/GNU/Linux*
Used Fedora lately?
7:19 udev actually predates systemd. It was an architecture created by the Linux kernel developers to replace the older “devfs”, if anybody remembers that, as a way of managing the ever-increasing variety of hardware that could be connected to a Linux machine, including hotplugging. And I thought it was still maintained by the Linux developers, not as part of the systemd project or anybody else.
You are right but at one point they decided to unite the projects
Didn't know systemd had all of this functionality, I'm actually interested in trying the systemd bootloader and seeing how that works.
I use systemd as a bootloader on manjaro why download grub if systemd can already do it and do it good
PopOS uses systemD boot by default. It’s crazy fast; love it.
Actually systemd boot is previously gummiboot, aka the fast and simple bootloader. The disadvantage of systemd boot is it only supports UEFI, and many package managers are not cooperating with systemd-boot yet. In Manjaro, we have a package that can manage systemd boot on kernel update, It's just like Grub, I don't need to change anything after setting it up and it's 2 times faster than grub
@@budimanjojo4456, systemd-boot is renamed gummiboot. Only thing it can do is launching other efi programs (like linux kernel with efistub), so when you need have kernel on luks on lvm, you have to use grub. That is why general purpose distros don't default to it.
@@vladisimusI You've got thing wrong man, gummiboot was merged into systemd and become systemd-boot. Gummiboot is a very old project, long before systemd was the default init on every linux distributions (I used it before and failed so I know). Here's the news from 2015 where gummiboot got merged into systemd: www.phoronix.com/scan.php?page=news_item&px=Gummiboot-Is-Dead
You should make a video to where you make a computer use as much SystemD as possible
^This.
Brilliant idea
@@ChrisTitusTech does this mean a new gentoo stream? 😂
Agree. The more you use it, the less bloat it will be :)
HikariKnight No, it should be based on LFS
Systemd timers are really great. I think is a modern approach to chron jobs. You should really look into it if you haven't yet.
It's great to have the possibility to interact with them throw systemctl for status, etc..
I really wish distrubutions had a way to split up systemd, so instead of just download `systemd` you could download only the things you need like `systemd-init`, `systemd-boot` and `systemd-timesyncd`
Problem with that is systemd is not really modular. The systemd proponents will claim "it's modular, it's distributed in multiple files", but check the output of ldd on any of those files and you'll see that they hard-depend on each other. For the parts of systemd where it offers functionality not provided by other packages, there are community projects which extract and stub-out the parts, you can use them in Arch, Gentoo, and other advanced distros. They are eudev, and elogind (and possibly others). There are also projects like sdnotify, written in python, to reimplement some functionality of systemd.
👍🏻 In other words, the Unix way of doing things.
No idea what you're talking about. systemd-init would have to be the service that starts daemons, you need that or nothing is going to start. I don't seem to have a systemd-boot or systemd-timesyncd anywhere on my system. systemd is well designed and modular. The services only depend on each other when they need to, the next post about ldd is way off base too.
"I don't even understand what you are saying. i disagreet with you"
@@danespen5772 You can check if you have systemd-boot if you have the command bootctl. If you have systemd-timesyncd you should have the command timedatectl. I am not aware of any distubutions that disables these by default so unless you have compiled systemd yourself you should have them
I personally prefer systemd timers instead of cron. Because it has journald integrated, so you can see the log when things fail. It also gives you when the next trigger will happen and stuffs like that. Also, if your system is not on 24 hours, cron will not trigger it on next boot. For example, you have a daily job that happens on 9 a.m, but your computer is not on that time, cron will not trigger that day job at all, but systemd will know that that job has to be done, so if you turn on your system on 10a.m, systemd will still do it for you so your daily job is done. Also, people hate systemd because it tries to do everything, but that's also the benefit of systemd for me. I don't even have grub and cronie package installed anymore on my system, and that's a good thing for me. And it's not breaking on my end for the last 3 years, so those haters saying systemd broke their systems are not relevant anymore.
What happens if you want to run that job at that time but only if computer in powered on?
@@Joe3D You would use cronie. If you want to stay with systemd timers, you would create a timer unit with "Persistent" set to false.
@@Joe3D That is the default behavior actually. You use option Persistent=true to run the job if the last job failed. The default is false.
@@VJtheDJ1000 Right, Persistent is false by default. So that is the default behavior of systemd timer anyway. You have the options.
🤷🏻♀️I like to start with a very minimal system, basically a shell and a package manager, and install only those features I need. Anacron does what you are looking for on systems that aren't on 24/7, so if that was something I required, I would install that package.
I only have so much hate to give
I cant waste hate on SystemD, I wont have enough hate left for Windows
Windows requires all my Hate, and then some
Agreed, I *hate* Windows. I literally needed tons of registry tweaks and GUI modifications that took 2 weeks to finish. Meanwhile with Linux it only took 3-7 days and I'm up and running.
As soon as WINE can run LSPDFR and respect anticheat, I'm deleting my Windows partition, or just isolating it in a VM.
I don't really mind systemd but I would actually like if it were to be a bit more broken up into seperate packages so you can only grab the init system and udev if that's what you want but can leave out all the other stuff.
You should probably install something like void on another machine of yours just to play around with it. Just to widen your horizon. It's honestly kind of insane how fast it boots etc
I’ve even found Devuan to be much faster than Ubuntu and Debian these days. They aren’t laden with bloatware
@@lawrencedoliveiro9104 As I understand that is problem. Systmd is good at being a init system and not good at other stuff. Then why have the bloat
It introduces some other neat features. Like the randomized delay option in timers, so you can define a bunch of cleanup tasks to all run nominally at midnight, and it can automatically spread them out a bit so they don’t all kick off at once. Also the fact that system log timestamps are now recorded in UTC, not some arbitrary “local” timezone.
The more you look, the more nice things you find.
12:15 As I recall, one of the design goals for systemd-mountd was the ability to impose a hard limit on how long dirty filesystem data would remain in the cache. For example Lennart wanted to be able to guarantee a maximum of 1 second before the cache was flushed on USB sticks, to cater for the all-too-common case where users pull the stick out without remembering to unmount it. This way, they would be more likely to keep their data, rather than end up with a corrupted stick.
Proud user of OpenRC.
Udev is great, it was actually there before SystemD, until systemD did absorb it :)
Fortunately, udev got forked into eudev after being absorbed by systemd as not everyone want to run systemd and udev is/was kind if a essential part of Linux.
Same for gummiboot (the bootloader that got absorbed into systemd and renamed into systemd-boot)
I moved all my cron Jobs to systemd timers and really enjoy the configurability of systemd. It takes a bit to get used to it, but its also really well integrated into the systemd services side of things.
While I dislike the the binary logging and inter-dependencies of systemd, I really love their concept of configuration (unit files).
I actually use the systemd boot loader in many production machines. Is soooo easy to configure and change parameters to the kernel. GRUB is a titanic mess with way too many features for a simple boot manager.
Runit from a technical aspect is better than systemd. It is faster than systemd and of course lighter and simpler than systemd. So with the existance of Runit there is no reason to have systemd. There are also articles about systemd and nsa bachdoors. We have 2 b carefull!
Give 1 single source of a NSA backdoor in SystemD
@@SgtPiper audit it or search there are articles here and there... i am sure you will use it wether it has backdoors or not...
@@RHTORAS You do realize only a small % of People who use SystemD can actually read the source code right?
@@SgtPiper xzlib.
@@RHTORAS to be fair, it's hard to take your advice when you don't seem to even try to spell properly.
I really like how systemd can manage my socket servers and dbus interfaces and start my services on demand. It is nice to have one process using a single select/poll/epoll system call than a bunch of individual processes running and using their own blocking system calls as they wait for IPC.
I used a lot of the task scheduling with systemd, timers. Loved it.
systemd does some things right. Personally, I love the systemctl feature, it makes many things easier. I also use systemd-boot. Nice thing for a single-boot system.
However, I am strictly against systemd slowly taking over the entire OS. In all, systemd-linuxd isn't at all far-fetched, given the fact that Poettering has announced systemd as the »core OS« as early as 7 years ago.
And this is where things are going to be very dangerous. On the long run, systemd aims to make Linux obsolete. We might end up with a hard-wired core OS similar to Raspberry Pi you can never get rid of, despite whatever distro you choose to install. People should carefully reflect on whether or not they will want that.
I don't. I'm thinking of ways to get around systemd, probably going to switch from Arch to Artix.
The ubiquity of systemd might also narrow down the choices of alternatives on the long run. I would also rather not promote something as questionable as Clear Linux, really.
People praise the freedom of choice in Linux. I feel we will have lost most of that not too long from now.
Agreed, systemctl is the best and systemd is the most supported init system. I don't get the hate behind systemd, it's just an init system. It's not like Windows where it's an entire OS.
@@justsomerandompersononthei2595 Well, it's written in my comment. systemd is in fact much more than a simple init system. It is in fact an entire system of low-level demons, which in itself isn't a problem either.
The problem I see with systemd is that it aims to take control over areas it simply shouldn't touch to begin with. Like why does it need a daemon to mount the home partition? Also, Lennart Poettering's notion of systemd as the »core OS« feels quite spooky to me.
On the other hand, I'm getting tired of people who deliberately mistake and discredit opposite opinions as »hate«. Just because I don't want something, it doesn't mean I hate it.
Frankly, even if I say I hate something, it almost never means that I literally hate it. To me, it's synonymous with »I don't want it«. People these days need to relearn that not every word is to be taken literally, and that their opinion is not a law all the world needs to follow.
At first, I was agnostic to systemd, I didn't know if it was good or bad because I had tried nothing else. One day, I decided that I really wanted to try a distro without system. I installed artix linux instead of arch and chose runit as the init system. I know understand the pros and cons of systemd very clearly. My overall opinion is that systemd is a more powerful, complex, and bloated init system that is more suited for servers. It offers more options for process management and serveillance. However, for a home user lighter systems like runit are much better. I can boot much quicker than with systemd, and having less options makes it much easier for me to manage my processes. Also, since the servicesare simply bash scripts stored in a directory, they are easier to modify and identify if you are used to shell scripting. You don't need to know all the systemd options in order to use its full power.
wait! what?!? systemd as a bootloader?!? that, sir, is totally mind blowing to me! i paused the vid and searched the web about it. I have something interesting to learn tonight, thank you for that Chris.
Next thing you know, Systemd as a separate OS will be born.
Ya know that even Linux (kernel) has ability to be bootloader by itself?
@nawo266 wait what?, isnt the bootloader responsible for loading the kernel?
@@meztliraihaanalimano3174 Linux can be load via UEFI. AFAIK systemd-boot isn't even bootloader, just manager for Linux built-in bootloader
@nawo266 umm very interesting, thanks for the info!
Artix Linux is the best systemd-free Arch distro.
the best? why?
I seem to like void linux, but I seriously don’t know.
*void
I tried unsuccessfully to use Artix, and came back to Manjaro. So, even if I don't like it, I still use systemd. 😢😢😢
I run Arch, as an experiment forced myself to use all of systemd's components. I was surprised to not hate any of it.
Sizce nasıldır gerçekten bu systemd?
@@EmreYavuzalp Bence systemd kötü değil
Ben openrc kullaniyorum gentoo icin
Epey de hizli kernelide manuel configure edince boot max 5 saniye
systemd is a tool in search of a problem to solve. Many of it's parts are under documented and worse versions of other tools, so it's just extra crap. As for the rest... complication is the real enemy. If you can have a 20-30 min video that explains the basics of systemd, then that's the real problem. Here's my video on init.d: Put scripts in /etc/init.d, symlink them into a runlevel, done, you understand everything, simplicity is power.
I literally spent a hour trying to figure out why name resolution was broken through systemd's caching daemon on a ubuntu 20 server after making some network changes. It was listening where it needed to, but would send a fail for any queries. Decided I had had enough of peeling back onion layers and moved all my servers to alpine. Which btw, is vastly better than ubuntu on servers anyway, the install is far smaller, easier to understand and work with, boots in a second, it's great. It's funny to me how you mentioned that people don't like the boot performance cost of systemd..... Boot performance was litterally one of the main things it was trying to improve! XD Better dependency trees for parallel launching, etc, but it fails at even that apparently.
Maybe you need to do a video on how to debloat systemd.
S6 is a really awesome init system which I'd love to see used more! Obarun uses it for example.
Udev was a separate daemon before it was integrated into systemd. Now we can't use it without systemd.
Dns in systemd introduced decade old security BUGS.
Systemd logger is loosing log lines. That is a problem, and systemd developers will not fix it. Which is a bad way handling their users
Their implementation of ntp are not good enough to run on server.
Systemd initial ideas was good, bloating it and its strong NIH are bad. It is not making clean interfaces between core systemd initial system and externa services. That is bad.
And it is in any practice a monolith, which is bad for a system program. Because it doesn't have clean interfaces so we can't exchange with different, better implementation.
Interesting. Debian Developer here, Ubuntu and Debian distros I professioinally use. I am using systemd-networkd/resolved/timedatectl for interfaces, DNS, and system NTP client/system clock BECAUSE it is consistent and handles IPV6 addressing really well. Debian/Ubuntu ifupdown has a real issue properly disabling IPv6 RA address assignment when you want static IPv6 addressing for a server (networkd disables RA completely, clears IPv6 RA dynamic addresses, and all this seems to pop out of the box again with ifupdown), resolved when you look at it is better than dnsmasq for handling DNS over a VPN, chrony/ntpd is not needed when all you need is a simple NTP client. I use Network manager when I have a desktop or laptop though.
Is that Linux mint logo in the background?
yup
Yup, I have a dedicated mint system in the rack for videos.
Arch go brrrrr
@@ChrisTitusTech Hi, good video but you have several deep mistakes in this video that would make a nice second part revision:
1.) systemd-boot does have a menu wiki.archlinux.org/index.php/systemd-boot check the loader configuration.
2.) systemd-boot is vastly superior to grub in case you have UEFI because is basically hack free, doesn't load a pseudo kernel to boot a kernel like grub does, does not require driver support and is basically the best way to boot complex systems like ZFS root over ISCSI(or local) whereas GRUB support is been completely broken for a while. basically if the kernel supports it, systemd-boot can boot it no matter how crazy it the combination is.
3.) systemd-boot misses some cool GUI which grub kinda have in some distros.
4.) systemd-network is not redundant and is not meant to replace network-manager, its main usage is for REALTIME ON DEMAND containers spawning and in my experience nothing beat it speed wise, like order of magnitudes faster than networkmanager, netctl, etc.
5.) systemd-resolved/timesync/etc. can be used for both Desktop and Server but their main function again is for containers which again is insanely fast and have the added perk of TRUSTWORTHY synchronization, no more random times on your containers because ntp or hwclock went full retard for unknown reasons.
6.) Cronie and company is fine for most desktops but if you read the documentation of what timers are actually capable of, you will realize cron is not even on the same league, sure it has a learning curve but for server/container/embedded handling timers are just insanely better with several game changing features in security, resource usage, feedback, etc.
7.) systemd-x or y: is not bloat because they are not active by default(unless your distro went full retard and enabled every systemd service against systemd's recommendations), is just a bunch of several few Kb sitting in /usr/bin doing nothing at all in the same way coreutils put a bunch on binaries on /usr/bin that do nothing unless you execute them.
Also remember systemd is not a DESKTOP init system but an init system hence is also meant for virtualization, servers and embedded and several tools are meant for those which is why systemd does not enable all the services by default(again otherwise is the distros fault) and in this other scenarios many of this tool are way superior and widely used and are not meant to compete with bigger desktop variants but can be used in parallel tho.
henry stevens but I have i7 :3
Keep up your vids, they are always spot on and so important in these spaced out days
Systemd SUCKS! The reason you don't hate as much as the rest of us is because you're a windows admin who uses Linux, but still relatively new to it, compared to those of us who have been using Linux for 15 or 20 years.
I agree, he s not that good as it seems. I am a newbie aswell but facts he gives... So newbie.
I don't remember where, but I saw this guy who tongue in cheeck said:
"yeah, linux is just a wrapper around systemd-OS these days"
Note that even with /etc/fstab, it's most likely that the actual fsck/mount actions are performed by systemd, when you're on a systemd-based system. /etc/fstab is just another way to write mount units..
PopOS uses Systemd, they also have KernelStub installed to help edit kernel parameters. I used KernelStub for the VFIO passthrough to give a GPU to a windows guest KVM. It's pretty nice to use with Systemd
Is there a way to Uninstall some of the Bloat stuff that comes with Systemd
I love systemd. Two of the fastest distros are ClearLinux and Solus, both use systemd and even systemd-boot. The performance is just unmatch by any other distro, especially boot time. I get like 4s boot time on Solus even in Legacy BIOS
Can systemd-boot choose kernel like grub does? Or edit the kernel options in the beginning.
@@s9209122222 Yes, it's actually cleaner than grub. You can even press D to set a kernel as default or increase, decrease time delay
You need to know that Solus also doesn't have tons of useless services enabled by default like most distros does, like Ubuntu and Mint. It just enables the essential.
@@natri23 I hope that systemd-boot will have a beautiful interface and compatible with LVM in the future, that's the only reasons why people are still using grub.
Coming in as a relative linux/computer-science noob (on a 4yr old video): is the lag in booting still an issue on distros that use systemd’s boot loader?
You mentioned it it’s not as slow on systems that use it, but it wasn’t clear if the difference completely refutes the criticism of lag (relative to other innit systems) or if it’s just better than typical systemd implementations (that don’t make use of systemd’s boot loader/other features).
I also understand that there’s some philosophical criticisms of systemd-a single system doing a lot of things (and thus have a lot of things depend on it) rather than “the Unix way” of many small programs working together. From your appreciation of the standardization that systemd brought, it seems like it was a good thing that systemd went against the grain in this specific instance.
Finally, I heard elsewhere that systemd becoming somewhat more modular in response to the xz vulnerability (was that the name of it?). Do you think that might help systemd’s reception and use? Do you think it might hurt the standardization it brought?
Hey chris. Maybe make a video on how to set it up and use systemD
Well it's setup already in most distributions, but I will show how to utilize it more.
I dualboot with systemd-boot and I am very happy with it, fairly light weight and easy to configure.
Ah yes, my favourite bootloader, *s y s m t e d - b o o t .*
It's spelled systemd-boot btw
@@justsomerandompersononthei2595 That was my dyslexia kicking in, fixed.
Please make a video about the distro that uses all the parts of systemD and the benefits of it.
Great topic as always.
Things I’ve learned is you have to configure things the systemd way AND the traditional way a lot of the time. File descriptors? Gotta change it in like 3 different places. resolved is improved but a mess. I’ve had it mess with my network DNS settings. The timer stuff is bloat, the whole thing is bloat. The old stuff does its stuff right and well. Systemd takes over too much. It also makes for lazy development. Can’t remember the package where I saw this, but Lennart basically told the devs “do it my way or F U”. Boot times faster? TBH, I’ve found Devuan boot up much faster and even FEEL faster than Debian. I don’t mind systemd as an init system. It’s pretty easy to make a simple service file. I just did the other day. Great. Having a hivemind init system is bad though. Like anything, having a monopoly on tech is bad. I can’t call Linux, Linux anymore with systemd. Void, Devuan. That’s Linux. And they are much more true to what Linux IS and the UNIX philosophy. Sadly, mainstream Linux is just trying to emulate Windows
Server management have been much better since systemd. This is why actual production distros (RHEL, Ubuntu, AlmaLinux, Fedora, etc) uses systemd. The standardisation is really important when you start working in non personal consumption environment.
at 5:02 you are talking about systemd having services that are like duplicate by other packages that come pre installed with the OS. So in that case which of the services (OS - or systemd) takes lead in initialization first?
Oh my, God, I'm interested in a video discussing alternative linux bootloaders ! I didn't see that coming !
Damn Chris, your a beast! I cannot find the vids any more I need to refresh my memory.
AWESOME work, keep going Chris 👍🏻 👍🏻 👍🏻
Greetings from Netherland
It feels very strange when people says systemd is slower than old systems. One of the reason of it's creation was to parallelize tasks, by making listening sockets for services, so that you can start services in any order and in parrallel, sockets will accept requests (still don't response) before the service is started. In part, there is this 1 min 30 default value for when it wait for something that don't seems to happen... and more than not, I guess this is because of services not configured the right way yet.
It's quite funny how some view those who oppose systemd as "haters". I find that starting services with OpenRC is much simpler and the learning curve for systemd very steep. I could understand some of these people if systemd were a true init system, but it tries to do way too much. Much more than any other init system. Then you have the other problem - other OS components and programs that have hard dependencies on systemd. We have truly strayed from our Unix roots.
I started out on Gentoo back in 2007, returned to it in 2013, and have been on Artix since 2016 because I didn't have time to deal with system updates in Gentoo. Because Artix is also on OpenRC, it will be easy to chroot into my Gentoo system and do a massive update soon.
Right now I'm learning for LPIC 1 certification. Thanks for information. Is useful
When there is a bug in systemd:
Systemd: you are using it wrong
I love systemd. I love how fast and responsive networkd is at reacquiring after a drop. Lots of other great functionality in timers. I don't use 'cron' anymore and systemd mount with NFS is miles ahead of FSTAB. The system won't hang if a remote system is not yet UP, it will come back around periodically instead. Far superior IMO.
Using Linux since 25 years I refrained from updating and maintenance whenever possible. Instead I installed a new version of the operating system. With the arrival of systemd I completely changed my procedures. systemd has become a standard and works the same way in all distributions using it. If you turn one of its components off its turned off; no annoyances encountered.
On openSUSE Tumbleweed I disabled both wicked and NetworkManager. I enabled systemd-networkd.service and configured a static interface:
[Match]
Name=enp0s31f6
[Network]
Address=192.168.178.2/24
Gateway=192.168.178.1
That's all I need. No bloat whatsoever, fast as hell and extremely reliable.
I use systemd-boot on Arch and I like it, prefer it over grub actually.
The main reason is that it is just a text file to edit on your /boot vfat partition to add an entry in the boot menu or add kernel parameters.
There is no command to execute to update the boot menu.
All in all, I like systemd: the main benefit as you pointed out being the standardization, no chkconfig or update-rc depending on your system.
I also use it to start user services, not relying on XDG autostart, it is more portable depending on your desktop environment. You can also start services on different events: device attached, port opened, mounted directory, etc.
Finally, I know what is this systemd hate about. Thank you! As an average user, this systemd hate thing is just a curiosity and nothing that I was concerned with. A lot of smarter people decide to use if for the most systems so it has to have some good points and I suspect, the list if pros (and probably cons) is much bigger than you just pointed out, but we don't need all the details. Thanks!
the average users are the ones who broke linux philosopy. its why systemd got through, ubuntu with intrusive snapd etc. might as well just let microsoft handle linux, or maybe apple. its not just about "it works so its ok. its about keeping the users "freedom" regardless if you wants to or not
@@UnworthyUnbeliever Nope, Snapp and other containerized solutions were created to make developing software for linux easier. I don't like it, but I don't have any better ideas so I'll leave it at that.
@@UnworthyUnbeliever snap has nothing to do with the app stores, you can install the other packaging types through the app store too, in fact, they've been around in some form even before the mobile ones came out.
Also, package developers as you put it are a varied group of people, working on different things and with different interests. Canonical came up with snaps, and gnu came with flatpak, both are based on something similar to docker, if I'm not mistaken, which has been around for some time for web development environments.
It makes it easier for developers which in turn gives linux better support as whole. There's a lot to be said about it, but your elitist conspiracy has nothing to do with it.
@@redtide9055 actually systemd and containerisation comes from server use case. Large providers need a standardised way to deploy and maintain servers and services.
Thank you, Chris. A good and helpful summary. I too have never found any real reason to object to systemd. Bloat does no really matter for my main beastly box (System 76 Leopard) and other boxen.
Yeah, I have mixed feelings about systemd, too. It's a love/hate relationship. On one hand, it's a total bloated mess, but on the other, it makes system maintenance simpler and easier...
I don't hate it nearly as much as I hate snapd :D
If it works reliably and has an intuitive interface, then I am all in favor of it.
The boot speed of my PC is near instant with systemd. How much faster does Lunduke need it to be? Could you a tutorial video on booting with systemd and automounting like Clear Linux? Maybe include some of the other great features no one else is using.
One of the biggest *problems* with systemd is the existence of /etc/init.d. You say you can use stuff in /etc/init.d still, for legacy support, but it doesn't *work*. This is actually where lots of the hate comes from. When Debian switched to systemd such that you'd get it on a fresh install or an upgrade, there was fairly little fanfare. So us poor system admins figured it'd be like any other init system, toss your scripts in /etc/init.d and away you go. If init.d were removed, we'd have figured out something was up and checked the manual (which wouldn't have helped, as systemd's documentation is terrible, out of date, and *wrong*), and known something was up. As it was, the directory still exists, but changes there are generally ignored. I spent about 6 hours kicking the darn thing back in about 2012, before switching away from Debian over the matter.
Hey Chris! Your assumption of systemd-boot not having a menu to edit or choose entries, is wrong. By default, the menu timeout is 0 seconds, tho. You can edit the loader.conf file to change this. Or you can press and hold a key during boot and it is supposed to show up (I cannot test it because my EFI doesn't enable the EFI keyboard driver in non-CSM mode). While in the menu, you can choose an entry and press "e" to edit it just like in grub.
There are some problems with systemd. It's monolithic a.k.a. a "single point of failure" and it's becoming defacto making it hard to replace for folks who don't like it, you can't simply remove it and install something else because there are apps that depend on systemd functions, you have to switch to another distribution. Same goes for Linux kernel. That being said I don't even use systemd, I just do my usual computing and it does it's stuff on the background and in case of Linux kernel, it works and that's all that matters. So I don't think I'll ever replace them unless they pose a threat to my digital security or privacy since they don't have an impact on my user experience, but they still have their problems.
I've been in the process of transitioning from Manjaro to Arch, and during my research I came across Artix Linux as a systemd free alternative, currently testing out Artix OpenRC on my server so see how well it runs in comparison. It's an interesting process. I personally don't hate systemd, but I like the idea of being able to choose which init system we want to use, there is also runit and s6 options. It would be refreshing if more distros would have the alternatives available as well, or even the option to remove unused systemd orphans.
The reason I don't like systemd (or its 'bloat' part) is that controlling the enabled/disabled/running services is tough now. I used to be able to finely control exactly what services are running, disable useless ones, but now there is such a large number of them even in a mini-install. I have no idea what many of them are doing or why they are enabled. As a result one has to just ignore all those starting with 'system' or timers etc. Thankfully I don't need to deal with
I used to to hate on systemd. I never knew myself why, but after a while, the hate just doesn't justify. If many distros are using it, then they must have a very good reason for it. In the end, as long as my system works; an ecosystem is important.
I entirely agree the fact that there's standardization for systemd, which is what the linux community should be getting. No standards === mess
So basically he's saying:
" I don't mind systemd, because I know how to circumvent it and manipulate it. But I'm not sharing with you how to do that. I wouldn't have power over doing that. "
Isn't MX Linux the most obvious and high profile example of a distro that defaults to not using systemd?
Void Linux has a version without systemd.
Mark void switched from systemd to runit in 2014
Devuan is Debian minus systemd.
@@alurma but you are able to install systemd on glibc vr
Artix Linux
Linux/Unix/GNU philosophy is to do one thing and do it well. Systemd violates that. It's not really a problem for me unless things get overly complicated. This thing about replacing the home dir with homed or whatever sounds like a horrible idea.
I use the systemd-bootloader on Arch and I didn't have any problems with it since... and always when I see people complaining they shot GRUB in the foot, I question why they all have to use it. I've never seen a reddit post of someone having problems with systemd-boot... ^^' Btw I also have a dualboot setup (so it's wrong that it can not dualboot)... it's actually pretty easy to use for a dualboot setup since it locates a Windows partition automatically and adds an entry for it without configuring. Adding entries for specific kernels or parameters is also pretty easy and clean.
The downside is maybe customization of your bootmenu... (I haven't checked yet if it is possible to change background etc.) but it's not necessary in my opinion.
4:30 *No,* dnsmasq is not an alternative to systemd-resolved. dnsmasq is an alternative to BIND. dnsmasq is a lightweight DNS server; BIND is a heavyweight DNS server (used across much of the Internet); systemd-resolved is a DNS *client,* not a server.
About systemd, I really don’t care. I’m not that advanced of a user.
journalctl -x and -e for error??? no -e is for going to the end... -x augment log lines with explanation texts from the message catalog -p[level] determine the priority level. "emerg" (0), "alert" (1), "crit" (2), "err" (3), "warning" (4), "notice" (5), "info" (6), "debug" (7). So if you want errors or higher priority (lower-level ... which is strange)... then use journalctl -p3 ... -p4 for warning or higher priority... -p5 for notice or higher. The most important option is probably -b ... because if you don't use it, you have the full log and it can be from months back to now, so -b 0 is the current boot session (since you booted to now), -1 is the previous boot session, -2 the session before -1, etc.
Runit is evil, but I LOVE IT!
I am learning how to manage services in my recently installed Arch Linux system, I have heard the systemd is reviled but I didn't know why. I know people like apps that focus on doing one thing and doing it well. but honestly, since systemd is already on my system and I don't know how to replace it I am tempted to look up the full breadth of what it can do and for instance uninstall grub if it can be a bootloader in its place. as always, thanks for the info 👍🏽
What I love about systemd is that it gives me easy access to kernel functions like namespaces, CGroups and capabilities without having to modify the init script. This way I can better protect services without using frameworks like SELinux or AppArmor.
1) Anyone should be wary of any init system that has 1.3 million lines of code
2) The "developer" of it spends a whole lot of time replying to Github's posts, shouldn't he be "developing"??
3) Anyone should be wary of a software that is never finished, that is never properly delivered in a final state. SPECIALLY something with such a limited scope as an Init system...
systemd is good for the person, to keep the guy's job, not for the software or the system itself...
have u tried runit? on arch or manjaro?
Um, Gentoo doesn't use a legacy init system. That's FUD. Gentoo's init system started around the same time as systemd, taking the neat ideas (parallel init (which debian already had, but was unreliable), dependency based startup order, non-duplicating init scripts), but not integrating them with everything else, not being buggy and unstable (boot races were common in systemd at the time), and actually supporting legacy init scripts (anything in /etc/init.d with #!/bin/bash at the top generates a warning, but still works as intended). It's called OpenRC, and it's far nicer, and far easier to use than systemd init (and *also* faster).
If we are now going to be satisfied in linux on the basis that it is still faster than windows, then it is all downhill from here.
is that really all you gathered from this? chris has voiced his opinions to why he prefers linux over windows on several occasions before, the part that it is faster than windows is a minor point on that list.
Dont like something in linux? change it or get some elbow grease and make something superior.
@@HikariKnight First, I do love linux. I have been using it on and off since the late nineties. I have not used windows in months. I am currently using my linux mint laptop.
Second, I get that it is only a minor point and no, it is not the only thing I got from this. Surely, it is still ok for me to respond to it?
Third, linux (including systemd) should be about making the best technology we can without bloat. Our benchmark should not be "Is it better than Windows?" Windows is getting worse and worse. If linux merely stays better, than it will get worse and worse too.
@@gregg4 it was how the reply was laid out that made it sound extremely negative just because he said that. Hows mint treating you?
@@HikariKnight It wasn't meant as extremely negative. I love my mint system. I love the cinnamon desktop. Still going strong.
2:50 The traditional way of doing system logging was with syslog, where a bunch of text files get appended to in /var/log/. systemd replaces these with binary “journal” logfiles. Some Unix traditionalists hate this, but it has some nice benefits. One I like is that timestamps are in UTC, rather than some “system default” timezone, and journal entries can be formatted with timestamps in any timezone you choose. Another is the ease of selecting entries based on various criteria, rather than trying to invent elaborate grep match patterns.
I think the reason behind system.d being the way it is is that it hopes in the future, every Linux distro wouldn't need additional packages to do scheduled tasks, bootloading, mounting drives and so on on top of initializing the OS, and would instead use the pre-included speedy and tiny integrated systemd features which is what Clear Linux is doing.
And considering the speed of Clear Linux, maybe system.d was wise for being "bloat".
I have a Dual Boot Windows / Pop_OS / Majaro laptop (Installed in that order) Pop_OS does use systemd boot and Majaro replaced it with Grub boot. One one hand, the boot loader in Grub is something I can get to grips with and looks very easy to customise. Getting Grub and Pop_OS to boot reliably was a bit of a journey though. I had to customise Grub using Grub Customizer to boot Pop_OS on the partition UUID rather than the device name. The biggest issue was updating Pop_OS, which updated Systemd and the bootloader. I had to use a USB stick to get a boot menu, to find the Majaro bootable partition and then used Grub Customizer to re-write the MBR and update the Grub Boot loader.
You've forgot to call out Devuan. It's a fork of Debian without Systemd, and having installed it, it offers a very Debian-like experience. And yes, it does boot faster :)
I believe the 'beards don't like SystemD because of a few things: 1) Do one thing and do it well. (the *nix golden rule) 2) Always prefer human readable txt for everything and avoid binary data. On 1), SystemD does booting and logging plus a whole bunch of other things instead of just booting, or alternatively just logging or etc etc. On 2) SystemD has the logging aspect which is all binary data - you need to use the control program to view the log output yourself. SystemD does boot much faster than what was there before - I believe the main reason is that all of the interdependencies of services are specced up by the authors? - which means SystemD can put everything into a graph of dependencies and perform steps massively in parallel, reducing wait times.
Thanks for the Info.
Is my impression right, that a good part of the redundancy aspect of systemd is a thing that's done for compatibility, I. E. The systemd-boot that requires UEFI? I mean look at the outcry when Ubuntu removed 32 Bit support, and AFAIK UEFI was broadly in use quite a time after 64 Bit systems were basically the norm.
Also about that systemd timer system, what's making that so uncomfortable, is it just that it offers features noone uses, which makes config more difficult, or something else?
Systemd does more than it should do.
I love how people take guesses at why systemd got so much hate, without actually finding someone who heaped tonnes of hate on it to ask. The issues you list are valid, and if you ask some old timer what the underlying problems with systemd are, they are likely to feature prominently. But if you ask the people with the real vitriol for systemd, you'll get some variant of "it just doesn't work". That's because about 8 years ago, it just would fail, spectacularly.
You mention using a dependency graph for parallel startup. Sounds neat. SystemD put that dependency graph into an unordered key-value map. Which meant that the order of startup was non-deterministic. Which meant, in conjunction with service files which were still new and didn't have fully complete dependency information, random hangs at boot due to race conditions and missed dependencies. That's something debian's Makefile-Style-concurrent boot had struggled with for years (and if you wanted support for something, you had to turn that off). The difference is that, once you found the problem in debian's MSCB, your system would thenafter boot properly, because Make uses predictable ordering of orthogonal components (ones listed higher in the file, or files sorted alphanumerically sooner boot first). SystemD, meanwhile, gave sysadmins *no* ability to specify boot order except for editing service files, which would have to be re-edited on every system upgrade. That was the number 1 tech support issue I had with systemd for about the first 5 years of the project. I honestly don't know if the underlying problem is resolved, or if unit files just actually have complete dependencies so it no longer matters.
the distro that is number 1 on distro watch, actually does not use SystemD by default.!
Thanks helpful video while I was researching installing Arch vs AntiX distros
Why spend time working with initd when it's going away? Systemd is where we are now.
While I am not a Linux neck-beard, I have heard of the hatred to this and the best understanding I have managed to gleen from what is on UA-cam up to now was that it was not designed 'in the Linux style', whatever that means.
While I understand that there are several parts that many Linux users don't use or are not as good as many other packages, if people don't like it being there and taking up resources why not fork the systemd project and simply delete that part of the code? It seems like the hate far outstrips what is otherwise a very useful package that I can't really see taking up that much in the way of system resources.
Instead of start services one by one and checking if it is start, it start all services then restart services which didn't start properly first time. Which is stupid way to start a system.
Sen ne düşünüyorsun hocam ya timer falan diyor timerı başka şeyle de yapabilirsin çok kolayca. Ve de systemd dışındaki sistemlerde zaten scriptlerle çalışıyorsun kod kısa uzun fark etmiyor ki.
I utilize systemd-boot with a dual-boot + boot menu perfectly fine. I'm running an arch linux sharing windows with an nvme drive and have never had an issue. The boot menu can be easily enabled, and indeed as the ability to edit options inside of it! I've not found any of the limitations you've mentioned.
I don't use the systemd bootloader, per se, but I do use the efi stub to build a unified kernel image that is signed for secure boot right into a prompt to unlock FDE. I'm waiting for my next weekend to implement TPM2 key storage and make the whole process faster and easier. I'm not worried about the Feds seizing my hardware and delaminating ICs to break in, so I would like to have the key storage implemented.
One thing i dislike about systemd is that it's service management can not be used on other init systems which severely harms interoperability with other init systems. In comparison if i wanted to i could run the runit service manager under systemd without issues.
I thought one of the problems was that lot's of sysadmins liked to put /usr on a separate partition, which I believe systemd has problems with.
I am using Artix with OpenRC and the system feels a bit "lighter". OpenRC is as easy to use as systemd. But you can READ your logs with cat.
Where to begin...Systemd is an attempt to standardize a world in which there pretty much are no standards. There are spec out there that say what normally goes in /etc or /var, or how apps can add themselves to the menus in Gnome, XFCE, or KDE, etc., but in reality everyone is free to do what ever they want in Linux. The 'specs' out there that define the common settings for a system really just amounts to 'friendly suggestions' if you want a system that's easier to migrate to from another system and it's easier for software to be written against a common set of standards. Systemd's biggest issue for a lot of vets is the migration away from the 'friendly suggestions' to if you use this, it will be done only this one way. This is pretty problematic when wanting to design and run a more efficient system for accomplishing the same thing, while still liking some of the things systemd can do for you. That and, one of the biggest allures of Linux is still "you can now do things your way" so since systemd flies in the face of that were you must now 'accept the bloat', I take issue with it.
I personally don't think systemd and other standardization will break the Linux world and there really are a lot of good things it does (and I do use it), BUT, there's a price to pay for it and that is in software bloat and lack of freedom. The old init system wasn't perfect, but every distribution had their own 'personality' with it as they strove to make the best system they could with their own way of doing things. On one hand you'd have to figure out the quirks in the init system in different distros every time you distro hopped and not every distro would be as easy to manage depending on what you came from vs what you were moving to. On other hand, it still wasn't terrible to move from one to the other, and you'd constantly see new ideas being done in each distro that others would pick up and use or maybe they'd take them and "fix it" and improve upon them. This is still being done to this day, but when everyone uses the same system for everything, what do they have to look forward to and improve upon? You loose some of the creativity if everyone just agrees to follow the same standard while gaining familiarity and easier adoption. It's a give and take really and everyone's on a different part of the spectrum.
In the end, we'll survive, and I'm sure someone will fork systemd and make a newer, better, and more efficient version in time, or just come up with something completely different and we'll be here again having the same debate...again. :)
If services are called daemons, does that mean systemd is the daevil?
Could you add the auto-generated subtitle? That would be awesome for some of non-native English speakers like me.
This was an interesting video. I've been running Artix with runit.
Maybe someday somebody will follow up on systemd and make it worthwhile. For the creator it was so difficult to get praise, for a system that reminded most people of Windows start up with their lack of security. As the creator said "never finished and never complete, but tracking progress of technology ." The white elephant is too big to repair, the old system was individual pieces easy to fix.The big fear! One major hack and we're all screwed!