I exhaled from my nose, but at the end this joke doesn’t seem fair.
I’ve been running Artix for years, because I wanted to try it out for fun and now am too lazy to switch, cause most things just work. I update weekly just fine and sometimes I have to write an init file for openrc.
The biggest pain point was when I was trying to debug an issue which crashed KDE and realised that there is no journalctl ofc.
Like with most technology, init should be based on use-case.
Some setups are not made for quick reboots and that’s ok. When all your container does is run ddclient you might find that even cron can work just as well as systemd.timers
Back in the day, around 2005 or 2006 I did that and I had browse the internet in a text based browser for 2 days because KDE on that old machine took two days to compile.
It depends on the site, back then there were a lot of table-layouts which were quite fucked up in the text-only browser. Nowadays there are non of them which is good, but nowadays there are JavaScript only websites which don’t really work well. You can install a text only browser and try it out yourself.
I was really hoping this would be American Sign Language linux. All you’d need to do is develop a writing system with hand shape, face shape, location, and motion characters then build an entire operating system around it…
I’m sure the Gentoo crowd will refute this in a day or two when they’re finished compiling and can read it.
Edit: bro, a 2001 era Thinkpad is going to take like a month to finish building everything. You can probably cross build that system faster on your phone.
Yes it would be faster but it’s my first go at Gentoo for the base install I want to stick to the handbook. As soon as the base install is done I will see how to make my good Debian machine compile the packages for the IBM. Besides, I have time.
I’m not a linux power user but have some servers running on linux and honestly wouldn’t change it with anything else, as everything runs smooth and maintainance is easy and straight forward. Even if something gets fucked there is a great online community which helped me out everytime.
That said, and sorry for the long introduction:
I read a lot systemd memes in the last weeks: What is the problem with it and why is it trending now?
Sysinit was basically one file where you tell a process what to do, start, reload, stop. Systems is way way more complicated and according to some, prone to breaking.
It’s funny, after your first sentence, I thought “yeah, that’s exactly the problem. Copy&paste fragile shell code for managing processes instead of standardized lifecycle management”. Then your second sentence painted that horrible mess as “less complicated”
Nothing new. Nothing recent. Just people being scared of something because they don’t know how it works or because it’s relatively new.
Major distros have started adopting it in recent years. It’s one of many ways for a distro to manage which services are running. Many of the others are essentially a hodgepodge of shell scripts.
systemd provides a lot of flexibility with service dependencies and logging, amount other things. It has a standard way to have user-scoped services. It’s standardizes filtering logs for specific services.
basicly people complaining about what they don’t understand, that it don’t follow unix philosophy, when that philosophy was created 50 years ago, any way,etc, if systemd wasn’t good anyone could have adopted it, and everyone did, beause it easier, it’s faster and it work
I’m neither a systemd fan nor a hater, but in my experience not even enterprise linux distributors can get it to work correctly all the time. That tells me that maybe it is too complicated.
It’s getting better for sure, but there are still a lot of issues for me (Plasma 5, Nvidia 545). I think I might stick with it for now until I run into some major dealbreaker for me. Right now I can only game without glitches if I limit my monitors refresh rate to 60hz and even then you will run into issues.
Honestly I don't know. I just know that desktop environments and a lot of other packages have hard dependencies on Systemd, at least on Arch and Debian based systems. Those packages include: base, flatpak, polkit, xdg-desktop-portals, and vulkan-intel. So yeah, it's nearly impossible to not break anything.
None of the others are as deeply integrated into everything as systemd, they pretty much just handle starting things up so dropping in a replacement should be fairly straightforward. At least, it was until everything switched to systemd. Which is probably my biggest issue with it: that it integrates to the point you can’t replace it anymore.
Debian lets you switch and AFAIK it mostly works fine. They provide both sysvinit and runit as alternatives. Packages are only required to provide systemd units now, however a lot of core packages still provide sysvinit scripts, and Debian provides a package orphan-sysvinit-scripts that contains all the legacy sysvinit scripts that package maintianers have chosen to remove from their packages.
That’s just in the official repository, of course. Third-party repos can do whatever they want.
I think it would not actually be easy to test this. The massive combinations of hardware and software configurations in use out in the world make it nearly impossible to conclusively say one way or the other.
For instance consider the hypothetical of a service with a bug that increases its startup in certain circumstances. If Systemd triggered this bug and OpenRC didn’t because of some default setting in each, perhaps a timeout setting, would you say OpenRC is conclusively better at start up time? Not really, they just got lucky that their default bypassed someone elses bug. Just off the top of my head other things that would probably cause hell in comparisons are disk access speeds, RAM bottlenecks, network load, CPU and GPU temp and performance etc.
You can perhaps test for specific use cases and sets of services, but I think this is more useful for improving each init system than it is as a comparison between them.
Is boot time that much of an issue besides for arbitrary competitive reasons? I haven’t tried any optimizations and boot time on my headless server is less than two seconds.
It comes in handy for people who wants to run Linux on their notebook without being an engineer and look at Mac users with envy because of their “ready to work” time on their macbooks of 1-2 seconds after they open the lid.
Fun. You can dick around with your init scripts without having to worry about the right triggers or spawn classes or anything. Your system is hackable with bash. Systemd: here are a list of approved keywords, don’t insert that there, why are using cron when you can use me?
oh, you haven’t seen nothing yet. you know the lisp-y, hackable goodness you get in emacs? what if an init system was that hackable, and configured with a lisp? go give GNU shepherd a try.
It’s not systemd doing all the things completely unrelated to system initialization that it does that I have a problem with. It’s systemd doing them worse than the existing tools that do those things that the systemd equivalents replace and Lennart Poettering being completely unable to fathom why anyone would ever want to use any piece of software other than his. systemd talks big game about being modular, but makes breaking changes to how those modules communicate without warning anyone, so if you dare to be a “systemd hater” as he calls them and replace one of those modules with an equivalent he isn’t involved with, Heaven help you when he breaks the API of systemd that they hook into and the developers of your equivalent scramble to implement the binary protocol he thought up yesterday so that their alternative continues to work.
I don’t want software on my system that is managed like that. It’s the same reason I prefer Firefox over anything Chromium based.
Lennart Poettering being completely unable to fathom why anyone would ever want to use any piece of software other than his
What’s behind this? I’m sure it’s definitely not 100 % a single guy working on systemd, and tbh hating software because of the person who wrote it seems rather silly.
And what about those API changes you mentioned? Genuinely curious, I thought it always at least mentions them in release notes during betas.
It appears I was mistaken – systemd does announce changes to internal interfaces on their mailing list although I can’t be bothered to find out how much warning they give – but I believe my point stands. Regardless of whether he gives adequate warning, he’s still very much a dick about it (“gentoo users, this is your wakeup call”) and he still seems to be doing the embrace-extend-extinguish thing. It used to be possible to run systemd-logind without systemd – it no longer is – and that mail I just linked is about making udev hard dependent as well.
Of course Poettering does not do all the development himself, but he does lead the project and it is his hubris and inability to accept that one size does not fit all that is responsible for the project being as hostile to outside implementations as it is.
Again, it’s not the systemd project making alternatives to widely used applications and daemons (or even bringing development of those applications under the systemd umbrella) that I mind. It’s Poettering’s “my way or the highway” attitude and apparent belief that if your system is not either 0% systemd or 100% systemd then you do not deserve to have a system that works.
You can look up Lennart Poettering yourself, but he was also involved in PulseAudio which if you learned Linux in the 00’s might give you pause, and has had some minor beef with Linus Torvalds before. His Wikipedia page has something like 5 paragraphs for controversies and 2 for his actual career.
I think focusing on him is a mistake, but I also understand people who were still mad about PulseAudio latching on to him if they also had issues with Systemd. This article goes into some of it, but I can’t vouch fully for its accuracy. I will say that the dates of 2008 for PulseAudio’s release and 2012ish for when it became actually fairly functional lines up pretty roughly with my own memory, and systemd was released in 2010 and adopted by Arch and Debian in early 2012, so PulseAudio was barely fixed before the same developer started pushing Systemd, and succeeded in getting the normally very conservative Debian developers on board.
Borderline impossible if you aren’t using a distro designed with that in mind. Pretty much everything that isn’t a program you directly start (e.g. sound system, desktop environment, bluetooth daemon etc.) either only provide a systemd unit to start them (which you’ll have to manually translate into e.g. a shell script if you want it to work with your new init system) or is entirely reliant on systemd to function.
Your choices of distro if you don’t want systemd are Debian, Void, Artix, and Gentoo, and afaik that’s about it.
Replacing components of the systemd suite (e.g. using connman or networkmanager instead of systemd-networkd) isn’t actually that bad as long as your DE has support for them, but replacing systemd itself is something you are building your entire system around.
It still leaves sysvinit as an option. Debian doesn’t lock you into systemd. Heck, it doesn’t even lock you into Linux – you can use Debian on top of the FreeBSD kernel if you so desire
Systemd, as a replacement init system, is fine-ish. It’s sometimes slow and when it decides a service is lost there’s not much to do aside from killing the thing and restarting it.
Systemd, the full blown ecosystem that wants to replace literally everything by systemd-thesamethingasbeforebutfromscratch however, invites scepticism, especially when there are no particular flaws in the existing versions of things. DNS resolution, DHCP clients, NTP sync, etc. worked perfectly well.
From reading all of these comments, I think I have to agree. It seems like systemd as “the tool” is ok (I know there’s some argument there too), but systemd as the project and ecosystem seems to go a bit against the soul of GNU and Unix.
Use systemd if you want. It’s not perfect, but nothing is. There are certainly good reasons to use systemd, including, but not limited to, that it’s the default on most distros and you don’t want to mess with init systems. My only complaint is that too much software and documentation is written with the expectation that you have systemd for no good reason, which makes it harder to leave, which makes more people stick with it, which is an excuse to neglect support for other init systems even more.
You get a lot more transparency with the other init systems. Systemd is a big system that does lots of things and it’s not always possible to see everything it’s doing, because it’s doing a lot.
It also likes to hide things behind port redirections and binary storage of things that have always been text before so you pretty much have to use their tools to even read them
I assume there’s an advantage to the binary formats though. More efficient in terms of storage size? Easier to quickly search by a particular field even in huge files? Maybe something like that. (I genuinely don’t know)
I can actually understand what’s going on with other init systems. They’re basically just a list of stuff that gets run before you even log in. I do not understand everything that systemd does. I like understanding what my computer is doing. Most people don’t care about that, and there’s nothing wrong with that, but systemd is not what I want. I feel forced into using it anyway though, because it can be a lot of work to avoid it, and there’s no reason for that beyond the fact that not enough people care.
I get it. I’m in a small niche within a small niche. Nobody owes me an easy alternative to systemd. I’d still like one though.
Yeah. That was my point. It’s a self fulfilling cycle of people using it because it’s all that’s supported, and it being all that’s supported because people use it. I think that is a problem. That’s the same reason most software is for Windows. I don’t think that’s a good reason.
Agreed. Was just looking at Podman’s documentation the other day, and even though it’ll run on distributions without systemd, for a second I thought cgroups might not even work without systemd. Glad that’s not the case though, but I’m predicting a few problems down the road simply because I plan to use Alpine.
Thank you, Callyral. I didn’t know either. But now I’m trying to learn Linux again after 30 years of not touching it, so this is helpful.
If I may ask an additional possibly stupid question (coming from Windows/Mac): as an init system in Linux, after you get past BIOS and POST at power up, is systemd also responsible for the initial OS software boot process (the “bootstrap” or Boot Manager in DOS/Windows) or is that another process altogether?
Or, asked another way, does systemd load the Linux kernel, and if not, what does?
Just so you know, I have no real skin in this game yet; I’m just trying to figure out where systemd starts and stops so that I can follow the [endless] debate, lol.
Or, asked another way, does systemd load the Linux kernel, and if not, what does?
Immediately after the BIOS/POST, the first thing that starts is the boot loader. This is usually a piece of software called GRUB. There’s a part of GRUB in the Master Boot Record on the drive, that the loads the rest of GRUB from /boot. /boot has to be a basic partition so that the MBR code can mount it, so for example if you use something a bit fancier (like LVM) then you’ll usually have a separate small ext2 or FAT partition just for /boot.
GRUB shows a list of available kernels, and other operating systems (if any are installed), based on a config in /boot.
Once you select a kernel to boot (or wait a few seconds for it to automatically choose the default option), it starts loading the kernel. There is a small disk image called the “initial ramdisk” in /boot, usually with a name like initrd or initramfs. This is a small ramdisk that contains all the drivers needed to mount your root partition - for example, drive drivers (NVMe, SATA, etc), file system drivers (ext4, ZFS, XFS, etc), LVM, RAID drivers if needed, and so on. If the root disk is on an NFS network share (not as common any more, but still doable), it also needs to contain network drivers for your network card. It also contains a few basic utilities, usually provided by BusyBox.
Some Linux distros (such as Debian) build a custom initramfs, whereas others (like Fedora) have a generic one containing all possible drivers.
The initial ramdisk then mounts the root partition and hands control over to the Linux kernel, which starts actually booting the OS. The very first process the kernel starts running is the init process, which these days is usually systemd but can be a different one like sysvinit or runit.
Okay, yeah. This makes much more sense now. I really appreciate it. I’ve been seeing the GRUB menu in LiveUSB boots but didn’t understand that it was part of the initial boot process for general Linux systems (for whatever reason I had it stuck in my head that it was just for USB booting). And you’ve placed systemd exactly where it makes sense to me as the init process for that OS.
That is extremely helpful. Thank you so much for taking the time to write the entire boot order, because it just got crystal clear for me. Much appreciated!
Oversimplified: It’s the service that handles starting and stopping of other services, including starting them in the right order after boot. Many people hate it because of astrology and supersticion. Allegedly it’s “bloated”. But still it has become the standard on many (most?) distros, effectively replacing init.
I like init. It’s simple. I like systemd as well. It’s convenient. Beyond that i don’t have very strong feelings on the matter.
I think the arguments against the “bloat” are not towards systemd as an init system, but rather are because systemd does so many things other than being an init system. I also don’t mind systemd, but I absolutely hate systemd-resolved. I do not want my init system to proxy DNS queries by setting my resolv.conf to 127.0.0.53. Just write systemd- and press tab, that’s “the bloat”. I’m not saying that the systemd devs should not develop any new tools, but why put them all inside one software package? systemd-homed is cool, but useless for 99% of users. Same with enrolling FIDO2 tokens in a LUKS2 volume with systemd-cryptenroll. Far from useless or “bad”, but still bloat for an init system.
Now that you mention it, I find systemd messing with my DNS settings incredibly annoying as well, so I can’t help but agree on that point. At this production system at work, when troubleshooting, I often need to alter DNS between local, local (in chroot), some other server in the same cluster, and a public one. This is done across several service restarts and the occasional reboot. Not being able to trust that resolv.conf remains as I left it is frustrating.
On the newest version of our production image, systemd-resolvd is disabled.
Cultural appropriation is a bullshit concept predominantly invoked by people not belonging to a culture who are not able to make valuable contributions to society.
linuxmemes
Oldest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.