Ive been runing Debian 12 (kde) since bookworm was released and am loving it.
I have recently discovered Devuan which seems to be Debian without systemd - what is the benefit of removing this init system?
It’s mostly opinionated. systemd is written in C, uses a consistent config, is documented well, has a lot of good developers behind it, is very fast and light, and does what it’s doing very well. Since systemd also is split up into multiple parts, it still follows the “do one thing, do it right” philosophy.
There are some people that believe that systemd “took over” the init systems and configuration demons of their distro, and does “too much.” It really does quite a lot: it can replace GRUB (by choice), handle networking config, all the init stuff of course, and much more.
However, I have lived through the fragmented and one-off scripts that glued distros together. Some distros used completely custom scripts for init and networking, so you had to learn “the distro” instead of “learn Linux.” They were often slower, had worse error handling, had their own bugs, were written in various scripting languages like tcl, Perl, Bash, POSIX shell, etc. It was a mess.
The somewhat common agreed-upon init system was System V, which is ancient. It used runlevels, nested configuration (remember /etc/rc.d?), and generally, it was mostly used because it was battle tested and did the job. However, it is arguably esoteric by modern standards, and the init philosophy was revised to more modern needs with systemd.
You can probably tell my bias, here. If you have to ask, then you probably don’t have a “stance” on systemd, and in my opinion, I would stick with systemd. There were dozens of custom scripts running everywhere and constantly changing, and systemd is such an excellent purpose-built replacement. There’s a reason why a lot of distros switched to it!
If you want to experience what other init systems were like, I encourage you to experiment with distros like the one you mentioned. You might even play with virtual machines of old Linux versions to see how we did things a while back. Of course, you probably wouldn’t want to run an old version of Linux for daily use.
It should also be mentioned that init systems are fairly integral to distros. For example, if you install Apache httpd, you might get a few systemd .service files. Most distros won’t include init files for various init systems. You can write them yourself, but that’s quite a lot of work, and lots of packages need specific options when starting them as a service. For this reason, if you decide you want to use a different init system, a distro like the one you mentioned would be the best route.
Great question, and good luck! 👍
I liked runlevels. 🤷
Targets are just a more flexible, granular run level. Plus it can actually handle dependencies.
Some distros used completely custom scripts for init and networking, so you had to learn “the distro” instead of “learn Linux.”
I never really noticed init scripts differing much between distros, but I also didn’t play around with many. If the systemD scripts are the same across every system, then this is the first positive thing that I’ve heard about systemD, so thanks for that.
Init scripts were different, I can confirm. And it was pretty bad if you were doing your job and had to change something on a Debian
massivemachine, then moved to a red hat one.Ah ok, most of my experience has been on debian or derivations in the past decade. It seems weird that the init scripts would need to be different on various systems, I thought they had been pretty well standardized, with variables in the /etc/default/ entries pointing to specific folders or startup options. Ah well.
I was reading about Slackware today and it seems their init system still uses system V and lots of scripts.
So I’d definitely recommend that OS to anyone curious about the old style of init system.
Slackware uses the sysvinit program, but doesn’t have System V-style scripts. Which is somewhat confusing, but sysvinit is a basic init program that will just do whatever
/etc/inittabtells it, so you can write your startup scripts to work however you want.Slackware uses what people tend to call a BSD-style init, but it’s nothing like the modern BSDs, nor the older BSDs, not really. If you use Slackware, you’ll learn how Slackware’s init system works, but that’s about it.
Ah my mistake. I’m just generally curious about what distros use an alternative to systemd (not that I have any issues with systemd myself but I like variety).
So I googled what init system Slackware uses and read this page.
http://slackware.com/config/init.php (no https)
They mention several scripts on that page and that’s why I thought they use scripts.
But I haven’t actually used the Slackware yet. Suppose I should though since I’m interested.
No, you’re right that it has scripts, they’re just not the scripts used by SysV-style init systems. They have different names, are in different locations, and are executed differently.
I used Slackware for several years back in the 90s, and from that experience I’d recommend against learning it. I mean, with VMs today it’s simple to try new distributions, so go for it, but I’d put it waaaaay down the list of distributions/operating systems to try. If you have anything else you’re interested, put it first. Slackware is standard Linux so there’s nothing really special you’d find when using it, and it’s just a painful experience in general. I think some people will argue that it helps you “really learn Linux”, but I don’t think so. It just helps you learn Slackware’s idiosyncrasies, and learning pretty much any other distribution would be more beneficial than that.
Slackware has advanced from when I used it in the 90s, but only barely (they have a network-based package manager now, I guess, although it proudly avoids dependency resolution!)
Oof that stance on dependency resolution is a big no for me. As much as I hated building gnome from source it was amazing that Gentoo can do that in a single command.
Great answer. I do use systemd boot on one of my systems as well. It isn’t exactly systemd itself is it? Simply a boot loader packaged as part of the general systemd boot suite, right?
Systemd-the-init does depend on some core services and thise need to be used together: Init, logging and IPC. Anything running systemd-init will have journald for logging and IIRC DBus for communication. That’s because you need to control a system managing services, so you need to communicate with it and you need to document whatbthe managed services do, so you need logging. And you do want tested and stable code here (reusing something that was widely used in Linux before systemd started) and you do not want that code in the init process either. So systemd-the-init has very simple code tomlog and journald then has thencode needed to stream logs out to disk or to interact with other logging systems.
Everything else is optional and in separate binaries written in a layered architecuture: Each layer uses services provided by the lower layer and offers services to layers higher up in the stack. So lots of services depend on systemd-the-init to start other processes instead of reimplementing that over and over again (thus gaining unified config files for everything that gets started and all the bells and whistles systemd-the-init has already or will pick up later).
Or if you prefer a more negative spin: “Systemd is on huge entangled mess of interdependent binaries” :-)
Yeah exactly. It does have some features that require integration with the init system, which systemd obviously supports, but it could be used independently of systemd quite happily, and other init systems could easily support those integrations.
I am fan of principles like KISS and “Do one thing and do it right”. From this point of view is systemd disaster because it is almost everywhere in the system - boot, network, logs, dns, user/home management… It’s always surprise for me if nothing breaks when I do upgrades.
I understand why systemd is here but I’m not at all happy to use it.From this point of view is systemd disaster because it is almost everywhere in the system - boot, network, logs, dns, user/home management…
That’s almost like complaining that GNU coreutils is a disaster from KISS point of view because it includes too many things in a single project - cat, grep, dd, chown, touch, sync, base64, date, env… Not quite, because coreutils is actually a single package unlike systemd.
The core systemd is big (IMHO it needs to be in order to provide good service management, and service management is a reasonable thing to include in systemd), but everything you listed are optional components. If your distro bundles them into one package, that’s on them.
Systemd includes many complex things, coreutils includes many simple things. And coreutils are ported to many different OS’es, systemd is linux only. Ask why?
Lets imagine, my linux distro runs with openrc/upstart and I like systemd-journal features. Am I able to run system-journal without any other systemd components running?
(…) systemd is linux only. Ask why?
It is well known that systemd’s service management is built around cgroups, which is a Linux-only concept for now. Other OSs have their own ways to accomplish similar things, but adapting to that would require huge changes in systemd.
Am I able to run system-journal without any other systemd components running?
No, the only part of systemd project that doesn’t depend on systemd core is systemd-boot. And there’s also elogind, which is an independent project to lift systemd-logind out of systemd.
But honestly, I don’t see the issue here. You can’t use systemd’s components elsewhere, but your previous complaint was the opposite - that systemd is everywhere, as if you were forced to use networkd, resolved (which pretty much no distro uses AFAIK because it’s way worse than other DNS resolvers), homed, timedated etc. when you use systemd as init.
Also, I have a correction for my previous comment: systemd-journald is not an optional dependency, as it’s used as a fallback if the configured log daemon fails. I’ve only learned after writing that comment.
I can see you are much more familiar with systemd and thank you for details.
But still I think systemd hardly follow KISS principle.
Back when systemd was a hot topic I jumped on the bandwagon of using systemd-less distros just because people were telling me how bad it was. To this day I still use openrc but the reality is that systemd works very well and is easy to understand and use. The average user gains no benefit to using another init besides having a better understanding of how the system works.
Well and a faster boot time but it’s definitely a learning curve and not really worth it unless you want to try a Distro that ships something else by default (E.g. Alpine).
Faster by how much. My PC boots almost instantly now.
I never had a fast NVME SSD so my devices boot significantly slower than yours but unless you are actually at the point of instant booting it’s about half the boot time for me. I only use OpenRC on my Pinephone because it’s the default for PostmarketOS (a Alpine based OS for mobile phones) and never found a good enough reason to use it on my actual computer but it’s quite a bit faster and also quite a bit less convinient so all in all probably not worth it but still impressive to watch!
I am on an NVMe drive, however most of my boot time actually comes from the POST process so even if I were to switch to an OpenRC (or runit / another init system), it wouldn’t really have any meaningful impact on my system’s boot time unfortunately.
❯ systemd-analyze time Startup finished in 17.412s (firmware) + 2.684s (loader) + 3.587s (kernel) + 2.134s (initrd) + 9.244s (userspace) = 35.063s graphical.target reached after 9.208s in userspace.
This is such a “consumer-grade” take imo. No offense intended, but in enterprise Linux development systemd is considered horrible trash.
I can see why a more casual / desktop user would love it, though.
Hi. Long time enterprise Linux admin here. Systemd is great and way, way better than sysvinit. I’ve also used openrc and i can say it is okay.
Yeah I’m not sure where the idea that systemd is “trash” in the enterprise world is coming from. Of all the contacts that I know who work in an enterprise environment say this, nor have I even seen anyone on the internet mention this.
I mean if there’s an actual reason for it other than just the usual bandwagon of “systemd bad” I’m all ears.
Wait, people really believe writing boilerplate filled bash scripts to implement just the idea of dependencies does scale into enterprise environments? Which don’t come even close to emulate most of the very useful and important features systemd provides?
Seriously that’s a take I have never heard one say while keeping a serious face. There is a reason systemd is as popular as it is for every desktop and server distro out there.
It is far from perfect, but who in their right mind would want sys-v init or similar systems back? I can’t even imagine what a mess it would be managing all the contexts and implementing it securely and portable with an init script.
“consumer-grade”
Yeah, that’s the point. Again, the average user (as in desktop user) gains nothing from using a different init. There may have been some crazy server-side scenario where the type of init you used actually mattered but we’re talking about desktop Linux, which the answer is a clear-cut no. I’m not stopping the people that are interested in trying a different init out, I’m just telling them that there’s little to no benefit in the end if they’re expecting an improvement in performance or whatever else.
As someone who wants to learn enterprise linux rather than desktop linux, I would like more detail, but I’m willing to just take your word for it.
Short version: some people (I’m one of them) object to systemd on grounds that are 75% philosophical and 25% the kind of tech detail that’s more of a matter of taste than anything else. The older sysV init is a smaller program, which means that it has a smaller absolute number of bugs than systemd but also does less on its own. Some of us regard “does less” as a feature rather than a bug.
If systemd works for you and you don’t know or care about the philosophical side of the argument, there is probably no benefit for you in switching.
If systemd works for you and you don’t know or care about the philosophical side of the argument, there is probably no benefit for you in switching.
Exactly this. There are few techincal problems with systemd, but those are so miniscule. I say this as an OpenRC+openrc-init user.
And the init system systemd replaced was also serial.
Which means that you trade some speed for making it easier to understand what’s going on at any point during init. (Also, OpenRC does have a parallel mode, although it isn’t commonly used.) “Serial” isn’t inherantly evil, it’s just another tradeoff.
I’m more bothered by the very concept of an integrated supervision suite (running as PID 1 and managing services in runtime). And with the feature creep (not-invented-here syndrome despite being mostly worse on all metrics), the following heavy binding of applications to it’s services and that it can’t coexist, because of that, with any other init/service manager in a repo without an uncount number of wrapper scripts (some distros tried).
taking a breath Which is why we must have specialized not-systemd distros instead of Choose-your-iso-with-bootloader-X-and-Desktop-Y distros, like Artix does (a not-systemd distro).
The attitude of the devs to technical issues and even security holes is another issue. Systemd is really bad software in that regard.
I basically lump everything you’ve listed under “philosophy”—poorly chosen design goals and no one at the project doing anything about dev behaviour are not technical flaws per se, as the software is functioning as intended and expected.
systemd and init+OpenRC can exist together in the same repository, though—it just means that the repository also needs to contain both init scripts and service files, both of which are trivially small.
As a Gentoo user since 2005, I’ve been able to watch the entire debacle as it’s progressed, and the various efforts required to keep udev and friends working separately from systemd. (Currently, there are 7 Gentoo packages on the “absolutely requires systemd” list—6 optional daemons that I don’t perceive as being very useful, although maybe it’s just me, and one library that I’ve never heard of in any other context. So what’s being done to keep it from taking over is working.)
Ok, except OpenRC.
Systemd is huge. It’s a complex project that covers not just the init system, but also process management, networking, mounts, sessions, many other things. Many people think its monolithic design run counter with the Unix philosophy and wish to use distros without systemd.
Just to avoid misunderstandings: it’s not a monotolithic blob, it is thought so because its first project was a system daemon that manages system services. It is described as “a software suite that provides an array of system components for Linux operating systems.”, it is highly modular and offer many optional components that each have their own purpose.
You’re conflating a monorepo and with software monolith.
The development style of systemd is the same as most BSDs, and nobody in their right mind would argue those are counter to the Unix philosophy.
If a collection of programs that each do a specific thing runs counter to the Unix philosophy, then Unix runs counter to the Unix philosophy.
Devuan is the outlet of a bunch of people that don’t want Linux to evolve, become better and have more flexibility because it violates the UNIX philosophy and/or it is backed by big corp. Systemd was made to tackle a bunch of issues with poorly integrated tools and old architectures that aren’t as good as they used to be. If you look at other operating systems, even Apple has a better service manager (launchd).
Systemd is incredibly versatile and most people are unaware of its full potential. Apart from the obvious - start services - it can also run most of a base system with features such as networking (IPv4+IPV6, PBR), NTP, Timers (cron replacement), secure DNS resolutions, isolate processes, setup basic firewalls, port forwarding, centralize logging (in an easy way to query and read), monitor and restart services, detect hardware changes and react to them, mount filesystems, listen for connections in sockets and launch programs to handle incoming data, become your bootloader and… even run full fledged containers both privileged and non-privileged containers. Read this for more details: https://tadeubento.com/2023/systemd-hidden-gems-for-a-better-linux/
The question isn’t “what is the benefit of removing this init system”, it is “what I’ll be missing if I remove it”. Although it is possible to do all the above without Systemd, you’ll end up with a lot of small integration pains and dozens of processes and different tools all wasting resources.
What worries me about the “systemd does everything as a tightly integrated package” is the too-big-to-fail aspect. I’d be worried that we’re seeing a lot of configurations that can’t be pulled apart piecemeal-- for example, if you need a feature not available in systemd, or you need to deactivate a systemd component due to an unfixed vulnerability. It feels like there’s value in supporting a non-systemd init in the same way there’s value for individual packages to support an architecture beyond x86-64-- you get some extra checks that you aren’t making assumptions that only work for a specific happy path.
The problem of not having systemd is the mess what’ve seen before. It doesn’t make sense to have 200 different services to be able to have usable dual-stack networking. Furthermore Init and Cron are aging, having everything based on bash scripts doesn’t cut it anymore - they don’t scale, you can’t monitor and audit things properly and worse it creates a dependency on some very specific shell.
What worries me about the “systemd does everything as a tightly integrated package” is the too-big-to-fail aspect.
It’s been the default for ~10 years and it hasn’t been an issue yet… Even if it did “fail” the solution would never be to roll an entirely different init system. That would be absurd. If there is a bug, it gets patched.
I’d be worried that we’re seeing a lot of configurations that can’t be pulled apart piecemeal-- for example, if you need a feature not available in systemd
You can run services independently of systemd. There is no reason you couldn’t have whatever feature you want and systemd at the same time.
you need to deactivate a systemd component due to an unfixed vulnerability.
When vulnerabilities are discovered there is disclosure to maintainers, a patch is released, and then an announcement is made publicly with the instructions on how to fix the problem. I’ve never seen an instance where the industry collectively says “There’s a vulnerability here but we aren’t going to fix it. Good luck!” Especially for such an important layer of the stack… There’s no way that is going to happen.
Devuan community is a cesspool indeed. However, I cannot deny the validity on some of their argument, namely about having alternatives.
Yeah, I just have a question about that community. Debian maintainers told them they were open to a multi init architecture (as in have Debian support both systemd and init) as long as they maintained it, they just rumbled around and decided to fork Debian instead. This is the kind of people we’re dealing with.
Indeed wasted potential. Debian could’ve welcomed them with open arms had they participated in the Init divesity discussion.
That’s the problem, Debian did welcome them with open arms… they decided to left and fork.
people that don’t want Linux to evolve
Exactly this.
The philosophical arguments are pretty garbage. I generally want to know if the “it violates the UNIX philosophy” people use browser extensions… That violates the UNIX philosophy too. Systemd “is backed by big corp” but who do you think is actually contributing time/effort/code to the Linux kernel? It’s the device manufacturers who are trying to get you to buy their products… So that fails too.
No offense to anyone reading this but if you’re really passionately anti-systemd, I would not hire you. This is a dumb hill to die on and a red flag.
Exactly bigncorp is doing the majority of the Linux kernel development. Wonder why nobody complains about that.
Maybe you should hire me then?
5 minutes of fame when Debian said “if you want other init systems, maintain them”, soon-to-be-Devan folks slammed the door and effectively ruined the chance of multi-init debian by fracturing efforts into their fork instead. But hey, all the news were abuzz about them.
If you’re a new user you’d be better off moving on from here and not paying much attention. It’s a hot topic full of opinions that everyone will want to force on you.
If you really want to swap out the init system there are some things you need to know.
First, do you need a desktop environment(DE)/window manager(WM)? If so you’ll need to find a DE/WM that is not going to demand you use the mainstream init choice which currently is SystemD. If you want to use Gnome from your chosen distro repo’s then chances are it will pull SystemD with it.
If you want Gnome but not SystemD you’re gonna be building that beast from source every update and for the most part you’ll need to go direct to Gnome for any issue/bug you fall over and this too will be painful.
Simpler WMs will be more forgiving and will only rely on either xorg or wayland and will happily run on any init.
There will be other packages out there that also demand you use SystemD, so you’ll have to find them and decide if you need them or if there are alternatives that don’t have a hard dependency on SystemD.
All the current usable inits are written in C or C+ (except for GNU Shepherd, this is written in guile).
The benefit of swapping out the init system is mainly down to choice, necessity but again this all boils down to what the installation is for and what will it be doing.
For a good run down of the features of the init systems refer to these 2 urls: https://wiki.gentoo.org/wiki/Comparison_of_init_systems https://wiki.archlinux.org/title/Init
All of the init’s (except for epoch) provide parallel service startup so if boot time is a focus test each to find the fastest for your platform, Not all of them provide per-service config.
For example one can cobble together: minirc, busybox, syslogng, crond, iptables, lighttpd.
And the end result would be a relatively secure webserver with a small footprint, you could further extend this with nginx to sit in front of lighttpd to provide waf and cache features.
The biggest bug bear with SystemD is that it writes to binary log files and even though it can be configured to generate plain text, if it falls over in a bad way you will still only get a binary log file and if you’re in a situation where your only access is say busybox for emergencies. In this instance your only option is to boot from another systemd distro and mount the broken install and run:
$ journalctl --file /var/log/journal/system.journal
Other than that many take issue with SystemD trying replace parts of the system that many say don’t really need replacing like sudo, fstab, resolv.conf, etc but again these statements get full of opinion and don’t help us truly way up the differences and some of the SystemD alternatives misbehave or become hard dependencies other projects which makes it harder to disable parts and swap out to your chosen package.
I’ve tried to be more objective with this response and keep as much of my personal opinion out of this, But here is mine:
I don’t really like it but to make it easier to get support for my OS I put up with it, I daily drive arch and so must accept it. I could rip it out or run artix, I’ve gone down this path and got fed up with jumping hurdles to get what I wanted so went back to Arch and now I disable parts of it I don’t need/want, have it generate text log files, use openresolv and other choices.
None. The opposition to systemd is highly irrational.
That statement is factually false.
Now we have both said almost nothing.
The only valid argument I see is monoculture. If systemd every does fall out of favour, become broken or compromised in some disastrous way it will be a lot of work getting going again.
The same is true of Linux itself.
Anyway, I’m not sure I see how a non-gigantic, slow-moving, pretty-much-finished open-source project like systemd can become broken or compromised in a way that forking it cannot solve. This isn’t Chromium we’re talking about, where it takes an army of world-class developers just to keep it from falling so far behind as to be basically unusable. If systemd were to stop being developed in any way other than security and critical bug fixes, it would still remain useful for many years.
It may speed up your boot time, at least it happened to me on Void (maybe the reason is how minimal this distro is though). I personally prefer runit over systemd in how it handles services, but honestly you most probably won’t notice a much difference - definetely not worth reinstalling whole system.
Not to mention runit is a few thousand lines of code, systemd is 1.5 million plus. From a theoretical standpoint it’s an extra massive attack surface.
That comparison is bad on several levels:
First off, systemd-the-repo does contain way more than an init system. But yes, I am pretty sure systemd-the-init is slightly bigger than runit.
Secondly: Systemd-init does set up some useful linux kernel features for the processes it manages in an easy and consistent way. That’s why other services started to depend on systemd-the-init by the way: Systemd does linux-specific things developers find so useful that they prefer adding a dependency on systemd over not having the functionality.
Runit does not support any linux kernel specific features at all to stay portable to other unixes. Other alternative inits made the same design choice.
Thirdly: The overall attack surface of the system without systemd is bigger than a typical systemd system. That’s because so much code run by the init system is way more locked down as systemd provides easy ways to lock down services in a cross-distribution way. Note that the lockdown functionality is 100% linux kernel features, so it involves little code in the init itself. Users of other inits can of course add the same lockdown features as service-specific startup code into the init scripts. We saw how well that works across distributions with sysv-init…
Finally lots of security features implemented outside systemd-the-init require a systemd system as they need the lockdown features offered by the systemd-init. One example is systemd-logind: That depends on systemd-init to be secure where the pre-systemd attempts all failed to archive that goal. Logind makes sure only the user sitting at a screen/keyboard can actually interact with the device interfaces of the kernel device files managing that hardware, so no other user but you can see ehat you type and take screenshots of your screen. Contrast that to devuans approach: Add all users allowed to start the UI to a group and make the devices controllable by that group. Much simpler, KISS and the Unix way… but it also allowes all users on the system that ssh into the machine somebody sits on can log what other users can type. Apparently that is not a problem, since no system ever will have more than one user in the age of personal laptops and desktops. That seriously isvtheir answer… and they even rejected to maintain the ubuntu-before-systemd logind replacement when canonical asked them, because such functionality is not needed im Devuan.
Runit is brilliantly simple, and as the old granite maul examine text says, “simplicity is the best weapon”.
I’m sorry, you won’t be able to convince me to use it, it doesn’t feel KISS (I left Arch when they swapped). Fuck binary logs too. The only place I use it is on my phone which is SailfishOS.
Void to me is what Arch used to be – I tend to use minimal replacements where I can, e.g. Openntpd as ntp, socklog as logger, seatd as logind, zfsbootmenu instead of systemd-boot, no polkit et cetera.
it’s the closest usable distro for me to cut most of the poetteringware out apart from messing around with Gentoo (which I can’t be arsed with any more). I am not a fan.
Like or dislike systemd, be it convenient or not, you can’t deny it’s a behemoth.
Fuck binary logs too.
Text logs are binary, too… they just uses a pretty common binary encoding.
Where do you actually use text logs? I did not use text logs outside of hobby machines ever during my career. Logs were either aggregated in databases or at least stored in temper-resistant formats (usually due to legal requirements).
Do you actually use text logs in a professional setting? Just curious.
If binary logs get corrupted they’re kaput; text logs are not (as far as I know?). Also you cannot grep binary logs? I wouldn’t know.
No, I just have used Linux/BSDs for ~15 years in a non-professional setting.
With textlogs you have a hard time noticing a couple of added/removed/changed characters or even entire log entries. Thats exactly why some industries may not use text logs in the first place as permanent records that are at least temper-evident are mandated.
If binary logs go kaputt they tell you exactly which entries were effected and still display every bit of data they contain. Typically you do not grep in binary logs: Grep can not make sense of all the extra data in the logs (way more than in a typical syslog), so grep is just a poor tool for the job. You typically can use grep as binary logs so contain lots of text. This is ignoring compression, encryption and other extras of course.
I am not trying to convince you: Use whatever you want.I am trying to explain it, so that people can have a more informed discussion. The web is full of either systemd is the best since sliced bread and systems is horrible. It is neither: It is just a technical system that made technical choices that make certain things easier or even possible and others harder or even impossible.
The sytemd time thingy is actually more minimal than openntpd: It only supports sNTP and not the full NTP protocol and is a client only… Openntpd is a full NTP implementation with both client and server. It also is a great technical choice, so keep using it, especially when you need an NTP daemon.
You behemoth is my plumbing layer:-)
I like the ton of small and simple tools that systems brings along: systemd-nspawn is a really lightweight way to run containers that works basically everywhere, no need to install docker or podman. Disk resizing, sysusers, tmpfiles, boot, Key Management, homed, etc. enables me to build reliable, immutable images for my systems. There is no tooling whatsoever for this outside the systems umbrella.
If you do not try to build a 1980-style UNIX system, then you basically are stuck with systemd. Nobody else is even thinking about how to move forward. If you try to raise the challenges you see outside systemd, you get laughed at and are told that your usecase is obviously stupid. The limitations admins ran into 1980 are gospel now and you may not question any of that.
Fair play, as you say it is a “love it or hate it” affair. I personally really like the simplicity and stability of old school UNIX.
OpenBSD comes to mind as the closest thing in contemporary times and I would use it as a daily driver but I need Linux for a few bits.
Void to me seems like the Linux equivalent. Minimal, stable, no bullshit. Alpine also fits this criteria but is a bit more sparse in some packages that I use. Both great distros.
Systemd is 1.5+ million lines of code! However convenient, it felt forced by Redhat into the Linux world and many of us who do not like it feel bent over backwards to be fucked in the arse by Poettering et al.
As solely an init system, may I suggest a superior alternative, s6?
(I am in hospital on morphine so I may not be making sense).
You should embrace systemd. It’s actually good. Replaces all startup scripts, logs to a common log, even has scheduled systemd jobs just like cron but better, since they can have proper dependencies. Want to run something right after network stack is up and working? Easy with systemd, more difficult with cron and more hacky.
what is the benefit of removing this init system?
I don’t know anything about Devuan, but the init system is replaced, not removed. You need an init system. Devuan probably has something more barebone than systemd.
There are some security, privacy and stability advantages of other init systems over systemd. But for most people systemd should be fine.
See here for further info:
https://madaidans-insecurities.github.io/guides/linux-hardening.html#choosing-the-right-distro
https://forums.whonix.org/t/fixing-the-desktop-linux-security-model/9172/2
https://www.unixsheikh.com/articles/systemd-isnt-safe-to-run-anywhere.html
https://unixsheikh.com/articles/the-real-motivation-behind-systemd.html
https://suckless.org/sucks/systemd/
https://without-systemd.org/wiki/index_php/Arguments_against_systemd/
https://nosystemd.org/Also getting encrypted dns to work with systemd is pretty tough and unreliable in my experience (with debian and opensuse). See here https://github.com/DNSCrypt/dnscrypt-proxy/wiki/Installation-linux
Removed by mod
His stance on desktop security may be very hard. But his views are not far off from that of other known security researchers like Micay (Copperhead/GrapheneOS), Rutkowska (QubesOS), Matthew Garrett (Red Hat, Canonical), Solar Designer (Openwall) and others. They heavily criticize Linux and *BSDs to make us aware of all its shortcomings.
Systemd is hated by hobbyists mainly because it invalidates a lot of their hacked together wisdom …
Maybe these people dont hate systemd but want choices for a more minimal/barebones OS. Not to gatekeep Linux but to install a more energy-efficient, lightweight Linux OS for themselves like many Alpine, Debian and Arch users do. They believe in the KISS principle. The concept that less complexity equals better security (“less is more”).
Removed by mod
I don’t personally like SystemD, but Devuan sucks. They advertise “init freedom”, but in reality all of the scripts by default are just sysV init scripts that runit and openrc can’t control.
For a desktop user I don’t see any significant benefits to replace systemd. But also no-systemd distros works fine. I was impressed during my try on Alpine Linux, that uses openrc instead. The text printing during OS startup is so short that the terminal didn’t scroll. The bluetooth worked flawlessly. But it is a small community distro, and Alpine is limited by other things than the init system. The init system is a problem for people that have to deal with services.
On political aspects, IMO FOSS works easier with small and focused components that can survive with spare time developers. I can’t make critisicms on technical aspect, I’m not a good programmer, I just notice systemd seems to works fine. Red hat has man-power and capable of large contributions to Linux distros so they leads the innovations. All big distros switched to systemd, now its hard to avoid.
I would like to support smaller FOSS-friendly systems but I use Arch because I need recent versions and the anti-systemd arch-forks are harder to use. I’m a weak guy.
In short, as an user you should be fine by keeping normal Debian. If for political reasons you want a no systemd distro, the easiest is to use MX Linux with the default init.
SystemD replaced a variety of Linux init systems across different distros almost 10 years ago now but it is still resented by a significant and vocal section of the Linux community.
Realistically, at this point, non-SystemD distros are of niche interest. Devuan is one of the distros available in that niche
SystemD replaced a variety of Linux init systems across different distros almost 10 years ago now but it is still resented by a significant and vocal section of the Linux community.
No, it is not. It is always the same few people that repeat the same slogans that failed to convince anyone ten years ago. But that does not really matter: In open source the system that can captures developer mind share wins. Systemd did, nothing else came even close.
what you just wrote doesn’t seem to contradict what you quoted in any way. even if there haven’t been any people in the past decade who decided they prefer avoiding systemd (unlikely), there’s still that vocal minority of linux users that you yourself acknowledge, so idk why you’re posturing like you’re in a disagreement?
edit: a typo
The contradiction is in the claim that the vocal minority is significant. One could argue that the lack of mainstream distros not using systemd is an indicator of the lack of a significant population against it.
There is no significant section. It is just a few people telling each other the same old conspiracy stories over and over again.
ooh, conspiracy stories? do tell, if you’d like. i’ve never seen conspiracy stuff in this debate, but conspiracy theories are a cognitive failure mode that fascinate me.
Check out the devuan mailing lists then:-)
