I’m planning to move over to Guix over NixOS, as soon as my current situation improves and possibly import a new libre respecting laptop (Star Labs is thankfully available in India). I do have a very old laptop with a Celeron processor and 4GB of RAM with Guix installed already, and what has come to my attention is that it uses shepherd.
I’m not actually against or for systemd, in fact, I am not really sure why I should even care - maybe it is because I’m still not on to the level of a power user. Since I’m starting to learn kernel basics to prepare for GNU/Hurd contributions in the nearest possible future and shepherd seems to be what the GNU folks will be using, is there any reason why I should even care about the freedom of init system?
Edit: I’m asking this because I came across this blog - What is systemd and Why Should I Care? and also because Guix uses shepherd, and I’m not sure how I’ll be affected.
To imply that systemd is merely an init system is ingenuous at best and dishonest at worst - systemd is so much more than an init system, as that article mentioned. Since the article was written in 2014 systemd has grown massively in scope, even more than the author feared.
It manages DNS, home directories, system services, seat managment, cron, system logging, booting… the list is ever growing. As such many people fear it is becoming too dominant through making more and more software dependent on it. It is not atomic - it is very difficult to have just one piece of systemd as its parts are tightly integrated and inter-dependent.
One could even claim that systemd failed in it’s original remit - to make startup as fast as macOS by running tasks in parallel and by deferring service startup until they are actually needed. The result has been a not very performant init system - many init systems are faster eg runit, dinit. The systemd people now claim that speed is not a design goal.
It is, however, open source and very widely adopted. Most people don’t care - they just want to run their browser and word processor.
I never understood why people care about 1-2s of boot time (unless maybe they are working on testing things after boot while developing a kernel or similar tasks that require boots every other minute).
The main problem with systemd has never been the time it takes to boot, it’s more on the lines of what @z3rOR0ne@lemmy.ml and @StrangeAstronomer@lemmy.ml mentioned.
The main problem with systemd opponents has always been that they have not offered any compelling alternatives because as a sysadmin I know very well that I do not miss the days of debugging which of my environment variables from my interactive session slipped into and changed the behaviour of my init script call or indeed writing init scripts in general that re-implement the same 5 things badly for every daemon.
That has never been true, not at the point of the discussions on Debian (on Arch there was never a public discussion that I remember), and of of course not true now.
s6, dinit, runit, openrc and shephered are good options, currently in use by different distros. At the time of the public debian descussions, at least runit and openrc were available, but they were dismissed, and I don’t remember the arguments, but not so convincing at the time, thus the whole discussion about the topic.
I’m not a systemd opponent, but claims of not having compelling alternatives doesn’t feel right. I used Arch with systemd for a while, and I moved later to Artix with s6, and I’m thinking on testing dinit, and I have no issue. I guess if some major distros had made the move to runit or openrc, they would be more used as of now. BTW, at work, for containers and VMs I actually need to use systemd, and I see no problem with that.
It’s totally true sysVinit was way hard to keep maintaining on distros, and something else was required. Probably given the influence from major distros changed the game over systemd, and now that’s considered standardization now a days, but something else could also have become the standard. What’s for sure is that there are success stories of using something else, Guix with shepherd, Artix with several inits (dinit, s6, runit, openrc), Gentoo with openrc (one can choose others, like systemd), void with runit, chimera with dinit, and the list goes on. Variety is not necessarily a luxury, in this case it means one can choose whatever aligns better to one’s needs, believes (perhaps simplicity, perhaps minimalism, perhaps free/libre considerations, etc), and so on.
What’s also true is that for work purposes, one can’t be negligent learning about systemd, most probably one will need to deal with it sooner or later, because major distros, and in particular commercial ones, already embraced systemd, and that’s not changing any time soon.
The sad effect of wide adoption of systemd, whether one opposes it or not, is that now services/daemons developers focus on providing systemd ready daemons, and for anything else the distro developers need to port to non systemd alternatives, and even build applications without systemd if that’s possible at all. And if one is looking for a daemon not packaged by the non systemd distro of choice, ones is on our own creating the proper service/daemon, but not something impossible.
I used openrc for years before switching to systemd on my Gentoo systems and indeed it was the default there at the time (might still be a default, defaults on Gentoo tend to be very soft suggestions unlike some other distros). It had nothing particularly compelling compared to any of the other init script based systems as far as I remember. Certainly had all the same major downsides.
The very reason it is so hard to provide init scripts for alternative systems should be a hint that systemd actually does quite a lot of useful things because I certainly don’t consider it nearly as hard writing a systemd unit for a daemon that lacks on these days as it was to write an init script back in the bad old days. Especially if you give a shit about not just copy&pasting and then tweaking a random other init script for a total maintenance nightmare or care about it being usable on both Debian- and RedHat distros.
I guess for init system development making speed one of the goals makes sense
I came across this blog - What is systemd and Why Should I Care?
A 2014 blog post by someone with the bio “Software Engineer at Microsoft, currently working on Outlook for iOS” should not be a significant influence on the choices you are making about your usage of GNU/Linux in 2023 :)
I use Artix Linux with runit and am happy. Artix offers multiple init systems other than systemd. If you’re familiar with using Arch Linux, basically Artix is the same without systemd.
You can install the various ISOs and see the differences for yourself, but the complaints launched against systemd that have any validity are either technical and/or philosophical in nature.
In a lot of ways, systemd has become like the JavaScript of init systems in that it handles a lot more than what it originally was needed for (init starts other processes after boot, JavaScript adds small amounts of interactivity to web pages).
As opposed to what each became (systemd now handles DNS, cron, bootloader, and is a suite of tools tightly coupled with the init system) (JavaScript has now become a scripting language with access to the C level exec library to the point where an OS can and has been written in it).
In the early days of systemd adoption, there was much controversy over its seemingly sudden mass adoption. SysV init needed a modern replacement, and indeed, alternatives like Upstart, openrc, and others were in production to eventually replace it. Lennart Poettering and Kay Sievers over at Red Hat created and heavily promoted systemd.
Lennart was already somewhat beloved/hated in the community as he had developed PulseAudio, which was a boon over the previous Alsa implementation, but was considered bloated and unnecessary by the less audio oriented Linux users of the time. He was inspired to create systemd after researching Apple’s new init implementation, launchd.
Controversy spread as Lennart would dismiss adoption of systemd into the BSD family of UNIX like OSes. He also dismissed competitors like Upstart, as their implementation of certain modern features like CGroups was not as developed as systemd at the time. Additionally, Linux users at the time were heavily concerned that Red Hat was trying to take over the entirety of the Linux space, enforcing a more corporate and commercial influence on what had previously been a community more in line with the aims of the FSF.
Much of this culminated in a months long email exchange on the Debian email list, where many of these grievances, pros and cons of systemd adoption, and overall discourse around this topic took place in 2013-2014. Eventually the result was that Debian adopted systemd as the default init system, which along with Fedora, Arch, and other distros, sealed the fate of other alternative init systems as being fringe, out of date, and irrelevant.
More and more system admins would learn the ins and outs of systemd as it would become required for their jobs, and the criticism of systemd became more and more quiet as it just became part of the every day Linux experience.
Truth be told, the birth of systemd really heralded in the death of the UNIX philosophy as an old way of thinking about software development and program scope. Doing one thing only, and doing it well, while looking good on paper, and oftentimes is a good general rule of thumb, doesn’t apply to modern application development, for better and worse.
I personally like runit not for its speed, but for its simplicity. I can peruse the C code in an afternoon and appreciate it for what it is, an init system. I can’t say the same when I look at systemd’s code.
But most could care less. As long as it works. And all the power to them…
It does surprise me somewhat, however, that Linux users will condemn bloated browsers, electron apps, and text editors, but will give a pass to systemd, which holds so much more importance over whether pid 1 even launches and starts user space.
Let the downvoting commence.
Gentoo took the (imo) correct approach by providing users choice as well.
systemd has become like the JavaScript of init systems
Likening systemd to JavaScript is incredibly inappropriate.
systemd now handles DNS, cron, bootloader, and is a suite of tools tightly coupled with the init system)
No. Except for the cron replacement, all of those are stand-alone tools that can be run with systemd, without systemd or replaced with any alternative.
They just happen to be developed under the systemd project umbrella and are obviously tested to work well with another.
This argument is especially weird for systemd-boot; it’s not even a Linux program ffs.
There are some components that are harder to replace with alternatives but mostly because no good alternatives exist. Systemd might be partially to blame here in how easy it is those parts can be ran independently and replaced with equals and you could certainly criticize it for that but you didn’t even mention one of them.
Truth be told, the birth of systemd really heralded in the death of the UNIX philosophy
There is no truth in this sentence.
Doing one thing only, and doing it well, while looking good on paper, and oftentimes is a good general rule of thumb, doesn’t apply to modern application development, for better and worse.
What? Please google “Microservices”.
Your whole wall of text hinges on the assumption that systemd is a simple “init system”; a root process spawning a set of other processes. This is false.
systemd (as in: PID1) does service management, not init. It happens to also fit into the “job description” of init because starting and cleaning up dead services also fall under the responsibility of a service manager but reducing it to just an init system is just plain wrong. All the other things are handled by separate components/processes.
Thus, it still follows the “unix philosophy”. The “one thing” it does simply isn’t what you think it does.
It’s like saying
cpdoesn’t follow the UNIX philosophy because you could copy files withcat.catis soo much simpler to understand, why would anyone ever use the bloatedcp? Must be the pesky commercial influence of Bell labs!Truth be told, the birth of
cpreally heralded in the death of the UNIX philosophy.deleted by creator
Dont worry about the hyperbola developers. They have, after a careful consideration of what word to use, completly lost their minds when it comes to free software. They have such rigid standards about software that they have become much more restrictive than even the FSF. Just ignore them, its what I do to protect my sanity.
Hyperbola has the best vision for a clean and libre general-OS.
Yes, they very strict about the interpretation of “libre”, but that makes the vision pure and crytal clear.
Systemd is what most programs and systems have come to expect, and you shouldn’t bother changing your init system unless you have a VERY GOOD REASON.
Some people hate it for not following the unix philosophy of doing one thing and doing it well, but at this point nothing does except stuff like
cat.Some people hate it for not following the unix philosophy of doing one thing and doing it well, but at this point nothing does except stuff like
cat.you can actually write iso images to thumb drives with cat
cat linux.iso > /dev/disk/by-id/usb-My_flash_drivecat isn’t the one writing to the drive there.
It actually is. The file gets opened by bash and bash passes the file descriptor to
catbutcatis the program which instructs the kernel to write to the device.Modern
cateven does reflink copies on supported filesystems.cat is writing to a file descriptor. Which is pretty much transparent to it. it’s just sometimes redirected. What happens when cat writes to it is not up to cat. In fact, I looked at the source of coreutils. there are two sub implementations of cat. copy_cat, which uses copy_file_range when the input and output are a regular file, and simple_cat which does a simple read/write loop. In both cases the target file descriptor is STDOUT_FILENO. So the target file descriptor is hardcoded to 1. Cat is not aware of where the data is coming from, or where it’s going. It is hardcoded to only ever write to stdout.
edit: re the reflink thing, you were probably thinking of cp, not cat.
Wow that’s cool
You can even use
echo, which is way fasterecho linux.iso > /dev/disk/by-id/usb-My_flash_drive/s
or: cp my.iso /dev/sdaX
(much faster than dd)
actually many “Unix people” got mad at cat becoming “bloated”, because of options like -v (which escapes nonprinting characters)
This is why I focus on pragmatism above all else.
Getting bogged down in theory is a good way to waste your life.
You generally shouldn’t care about systemd, nor choose a distro or an OS just based on it’s init system, as they all ultimately achieve the same thing… Start and stop services. And while I don’t personally use it on my main desktop, it’s just because I don’t need any of it’s functionality and OpenRC IS a bit faster in my experience, though I can see why systemd the default on most distros, it’s extremely versatilea, powerful and handles a lot of things that you’d need separate programs for…
not on the level of a power user
Learns kernel basics
Bro i think you may be underestimating yourself
deleted by creator
is there any reason why I should even care about the freedom of init system?
Freedom of choice! It’s troublesome if distros and/or DEs rely so heavily on systemd to do their bidding. So much so, that some combinations of distro + DE don’t allow any differentiation in init or make it very cumbersome and unwieldy at best. I’m not interested in making systemd a necessary part of Linux. Therefore other inits not only have to exist, but should be ‘competitive’ as well. Which, to be frank, is currently not the case.
Another concern is that systemd is by no means a minimalist approach. Which beyond bloat, also has security implications. More information can be found in this (infamous) guide by Madaidan; security researcher on multiple distros known for taking security and privacy very seriously like e.g. Kicksecure and Whonix. Interestingly, while Madaidan discourages the use of systemd in that guide, it’s still heavily relied on in Kicksecure; one of the distros he works on. I think this is a perfect illustration of how systemd has become so good that even opponents can’t deny its merits and continue to make use of it for the time being out of necessity.
So much so, that some combinations of distro + DE don’t allow any differentiation in init or make it very cumbersome and unwieldy at best.
it’s still heavily relied on in Kicksecure; one of the distros he works on. […] this is a perfect illustration of how systemd has become so good
Considering Kicksecure is based on Debian, aren’t you contradicting yourself?
How so? I literally don’t see it. My apologies if I come across as obnoxious, but I simply don’t understand how I might have contradicted myself. I never explicitly mentioned Debian anyways, so why did you feel the need to mention that as somehow being related to a supposed contradiction.
Fine, i’ll bite, i’m bored.
Interestingly, while Madaidan discourages the use of systemd in that guide, it’s still heavily relied on in Kicksecure; one of the distros he works on.
While you didn’t explicitly state it, it’s a distro that’s based on Debian, so, has to be based on systemd.
I think this is a perfect illustration of how systemd has become so good that even opponents can’t deny its merits and continue to make use of it for the time being out of necessity.
No, not at all. You said it yourself:
It’s troublesome if distros and/or DEs rely so heavily on systemd to do their bidding. So much so, that some combinations of distro + DE don’t allow any differentiation in init or make it very cumbersome and unwieldy at best.
So trying to use Kicksecure without systemd would be very cumbersome and unwieldy at best. Perhaps Madaidan should’ve used Devuan as a starting point instead.
In case you’re bored enough to read my ramblings and/or interested in what I understood and how, then consider reading the spoiler below.
spoiler
Fam, you’re all over the place.
Because you did an awful job at pointing at the supposed contradiction, I’ll have to analyze your excuse of an elaboration so that it somehow starts to make sense if at all:
A contradiction consists of N statements that logically contradict with each other; for the sake of making it more precise we’ll refer to these statements as P, Q, R, S etc. After we’ve established this, we can move on to find what these alleged statements are from your comments. My best take would be:
(Supposed) Contradicting Statements:
- P: systemd is the only init that’s beyond a particular level of excellence and/or feature set.[1]
- Q: Some combinations of distro + DE are cumbersome and unwieldy at best if systemd is not used.[2]
Perhaps some other related statements that are either implied or a given/fact:
- R: Kicksecure uses systemd as its init.
- S: Modern distros use an init.
- T: Default init is chosen based on preference[3].
- U: Kicksecure has to use systemd because P despite not being in favor of some aspects of its design.
Please feel free to notify me if I missed the mark!
Don’t you think that P and Q are actually complementary to one other?
No, not at all.
The crux might be here. But I’m not sure where exactly you might have tripped over. Was it because I said “opponents” instead of “(some) opponents”? Was it because I said “out of necessity”, while elsewhere I said “don’t allow any differentiation in init or make it very cumbersome and unwieldy at best”, but in this case they aren’t contradictory statements. Was it the fact that Devuan exists? But, this assumes that any of the inits found on Devuan are somehow as mature and feature-rich as systemd. Which, unfortunately, is simply not the case. (I’m hopeful that dinit and s6 might reach maturity soon, though.)
So trying to use Kicksecure without systemd would be very cumbersome and unwieldy at best.
Exactly, that was my point.
Perhaps Madaidan should’ve used Devuan as a starting point instead.
It’s a team effort, I don’t even know if he started working on Kicksecure from its inception[4]. They might also simply be victims of the sunk-cost fallacy. Furthermore, I wouldn’t be surprised if -to them- systemd’s pros simply outweigh its cons. Which, curiously, gets us back to the entire point of my original comment; viable alternatives to systemd don’t exist. This painful truth is not only sad and unfortunate, but perhaps even worrisome for the future of Linux.
- From: “systemd has become so good that even opponents can’t deny its merits and continue to make use of it for the time being out of necessity”
- From: “some combinations of distro + DE don’t allow any differentiation in init or make it very cumbersome and unwieldy at best.”
- Preference is arguably too broad of a term, but I wanted to make clear that distro maintainers have different priorities.
- This page suggest otherwise, simply because someone else is referred to as founder. Though, ultimately, I don’t know.
If not 😜; did I understand you correctly in that the mere existence of Devuan is the supposed contradiction?
Big spoiler there.
I don’t think systemd is the epitome of technological evolution, but that’s another rant. The fact that it’s not just another init system is at the center of it, though.
Because it’s not, any distro that chooses to use it is, in fact, adopting a whole ecosystem. Some apps that predate systemd are even hard-depending on it for… reasons. Can you use GNOME without it? Why most distros adopted it as default instead of an alternative i can only speculate. At least Slackware hasn’t adopted it so far and Gentoo took, to me, the sanest approach: you can choose your init system, including systemd if you so prefer.
Devuan is the response to Debian choosing systemd. It’s its raison d’être, to be Debian without systemd.
I was unaware of Kicksecure, who their founder is and when they decided to adopt systemd, so i may be at fault here.
With this i agree:
It’s troublesome if distros and/or DEs rely so heavily on systemd to do their bidding. So much so, that some combinations of distro + DE don’t allow any differentiation in init or make it very cumbersome and unwieldy at best.
With this, i don’t:
systemd has become so good that even opponents can’t deny its merits and continue to make use of it
And this is where i think you’ve contradicted yourself. IMO, the only reason opponents use it is not because it’s so great but because it’s so entrenched in whichever distro they’re using.
Thanks a lot for this excellent write-up! I believe it has successfully fulfilled its purpose.
To make myself absolutely clear: I believe that we agree on our general sentiment towards systemd; I don’t like how it has almost ostracized other inits, nor do I like how ever-impactful it has become across the board so much so that even the most established DE (read: GNOME) has had hard dependencies to systemd in the past[1].
And this is where i think you’ve contradicted yourself. IMO, the only reason opponents use it is not because it’s so great but because it’s so entrenched in whichever distro they’re using.
Got it! I see now why you might have perceived that as a contradiction. And honestly, you might be correct! I assumed that systemd is used for how it might enable the full system AppArmor policy[2] and other features that Kicksecure has become known for. Honestly, I’m not an expert on Kicksecure myself. I just like the project and even try to import some of their systemd-related features and/or configs on my daily driver.
Based on past readings, the idea that systemd was (ironically) still preferred on Kicksecure for security-related features stuck with me. But, honestly, it could have been my misunderstanding and instead they might have chosen to make the best out of it as not using systemd would have increased the maintenance burden tremendously.
This conversation has opened the possibility to me that Kicksecure’s maintainers might have stuck to systemd for non-security reasons. Ultimately, your contribution by addressing that point has been immense. Thank you so much for the insight and for being patient with me 😊!
- I believe this has since been resolved.
- Based on the following statement: “AppArmor can do this by loading a profile for systemd in the initramfs.” found here
most people use whatever init system gets installed by their distro and, for the average user, interaction with the init system is pretty much non-existent (what interaction does exist is usually automated through the package manager)
if you’re planning to go into devops, sysadmin, or backend, then learning the ins-and-outs of the init system for whatever is populating your containers is worthwhile (ex. OpenRC for Alpine Linux) but beyond that, it’s up to you where you want to spend your time
deleted by creator
- again, most of that is handled by the package maintainers for any particular distro (ex. for Guix, gnome-shell and plasma have already been taken care of)
- a lot of packages don’t touch or even know about the init system
- so the worries will only come into play for packages not in the chosen repository AND require systemd – and for distros not using systemd, they’ve probably already got a process in play for translating between systemd and whatever they’re using
If you’re gonna use gnome you’re bound to systemd. Yes, gnome predates systemd. Strange…
Don’t know about KDE.
Systemd is free software. It’s perfectly good. No one should care about init systems
Typical desktop users don’t need to care about init systems. Some people really, really do though.
Also, it’s perfectly fine to care about some things you don’t need to. We all do for some things, and the inner workings of an operating system is not a bad thing to be fascinated by.
deleted by creator
a new libre respecting laptop (Star Labs is thankfully available in India)
FYI, Star Labs’ laptops require proprietary blobs.
Apart from boot time. I don’t have any complaint against systemd.
If you have issues it’s usually a configuration issue or a misbehaving daemon, try investigating with “systemd-analyze blame”, “systemd-analyze critical-chain” and “systemd-analyze plot > boot_anal.svg”.
Tried everything in systemd-analyze and systemd-analyze blame. Still slow compared to dinit.
deleted by creator
I’m pretty sure dinit, s6 and runit are faster than systemd (in that order), but it probably depends a bit on your setup. It has better boottime than some others, tho
Systemd is the slowest init system that I have used
How many did you use though? Is it also the fastest (n=1) ? 😃
I used dinit, runit, openrc, systemd and s6 Dinit was the fastest.
Ow wow, that’s a lot! Unsure to what degree you’ve used them; but if you feel confident talking about (at least some of) them, would you be so kind to offer us a rundown of what you liked and didn’t like? Thanks in advance!
I just have a super crappy laptop with a hdd. So speed difference is quite noticeable. On systemd, boot times were greater than 2 min (done everything I could in systemd-analyze). So, I switched to Dinit which is new and quite barebones also a tad bit unstable (sometimes crashed for me). It allowed under 30 sec boot times. Then, I tested all init managers. Currently, on runit which is about 2-3sec slower than dinit but otherwise quite stable. I just choosed based on speed nothing else. I didn’t notice much difference in functionality. All allowed me to do all the things I wanted just in a different way. Artix linux allows easy switching of init managers
Thank you!
Sysvinit might be slower, I’m not sure, but runit is definitely faster.
deleted by creator
deleted by creator
deleted by creator
Correct me if I am wrong, but a ton of modern Linux stuff relies on systemd afaik. I dont see why standadisation has to be fought always, even thought their 1k+ Github issues make me uncomfortable
Personally I’m not opposed to standardization, but having alternatives would be nice in case something ever happened to the standard
It’s bad design and therfore a wrong standard. Also, it’s a security desaster.
Do you mind sharing some examples, I personally have only used systemd based systems, works as a RHEL admin, started learning with RHEL7. I’ve only ever known systemd and it seems to work really well!
Sure, systemd does what it is supposed to do. It is NOT bad design from the admins perspective, but from a os-architecture perspective. It is a huge single binary with a huge number of 0-day exploits (you can check those). The scale of the projects causes many possible exploits. A set of small programs, which do only one thing, is easier to maintain (^= decentralization of os-design)
I feel that. Its nice for funding, support, guidelines and standards, but having the software itself being a single binary is bad
I don’t believe that starlabs is completely freedom respecting. However, its close enough.
One note about guix though, I’ve found the mirrors to be very slow. I haven’t played with it a long time but it is something to keep in mind.
deleted by creator
They definitely don’t have freedom respecting parts. They use modern Intel which requires proprietary binaries to even boot and there wifi, graphics and thunderbolt connections all need there own proprietary firmware.
The only options these days are a old machine from 2008 or before or an ARM based system from a company like Pine64
deleted by creator
Good luck, the odds are stacked against you. I do think pine64 us the future of free hardware. They even have Risc-V boards for those who are feeling adventurous
freedom of init system
What do you mean by this?
deleted by creator
Then probably the people to ask would be the Devuan people.
