systemd desperately needs competition. it isnt just that it became a dependency for every low level service and a potential vector for privacy invasion, it's also janky to use.
fragmede · 2026-06-29 08:05:50 UTC
where is it janky?
youre-wrong3 · 2026-06-29 08:11:45 UTC
His imagination.
shakna · 2026-06-29 08:29:06 UTC
The output devices (/dev/stdXXX) being sockets-only constantly trip people up.
egorfine · 2026-06-29 08:22:44 UTC
> systemd desperately needs competition
Maybe it's too late.
LP is cooking a way to deny system modifications [1]
I do agree it needs competition. The more the better. The dependency thing is bad but it's free software. It will always be possible to route around that if it ever turns into a problem. Especially now that we have LLMs.
I don't think it's janky though. It's pretty great. It has an answer to everything I've ever needed from it.
tmtvl · 2026-06-29 09:28:39 UTC
GNU Shepherd maybe?
nubinetwork · 2026-06-29 09:54:56 UTC
Try porting svcs from Solaris to Linux...
jeroenhd · 2026-06-29 14:24:27 UTC
I do agree that systemd could use some competition, but until someone builds one, we're going to be dealing with some systemd defaults. Canonical's attempts seem to have been most complete, but outrage at change and different ideas have shut down most of Canonical's attempts to improve the situation.
It's far from janky, at least compared to what else is out there for Linux. If you're not writing systemd service files, you're almost surely back to writing unpredictable 80s style scripting jank.
globular-toast · 2026-06-29 07:56:06 UTC
I find it fascinating how different people are with respect to being able to see the future, or at least caring about it. I find many people are like lumbering beasts in a forest complaining when a twig pokes them in the eye. While other saw the forest from miles away and just went around it.
Gentoo is still home to a sizeable number of users who noped out of systemd more than 10 years ago. This is exactly the kind of thing they saw on the horizon. Why does it take others so long to see the same thing?
LtWorf · 2026-06-29 08:04:14 UTC
Because if you dare criticise or say "I encountered a bug" the mob will get you.
simoncion · 2026-06-29 08:25:58 UTC
Your comment is very poorly phrased, but, yeah, I've found both the SystemD [0] maintainers and boosters to be very, very unwelcoming to claims that the way something SystemD does is incompatible with a totally reasonable and long-standing way to use a computer.
As I've mentioned elsewhere, SystemD is great... until you hit a bug born of its accidental complexity, or you find can't do something because the SystemD maintainers -sometimes suddenly- decided that they didn't want to let people do it anymore.
[0] This is shorthand for "The Systemd Project", not a slur against it. It sucks shit that systemd(1) and the project it's part of share the same name... it's very confusing. [1]
[1] For a real-world example of the sort of conversation this confusion causes, check out [2]
> Gentoo is still home to a sizeable number of users who noped out of systemd more than 10 years ago.
As a Gentoo user for the past ~quarter-century, I'd say that it's more that -unlike Debian- Gentoo has been using a system service manager that's way better than the classic SysV init for approximately forever.
The early discussion of systemd-as-init [0] was pretty much 100% focused on how much better systemd-as-init was than classic SysV init. When restricted like this, systemd-as-init is an obvious winner. But, when you consider other init systems -such as OpenRC- that provide a bunch of useful scaffolding and support tools (rather than demanding you reimplement all that yourself) the benefits of using systemd-as-init are far less clear.
I've mentioned this before in an HN comment or two from way back when, but I'm really mad at myself for not recognizing how extremely important the "What should Debian adopt to replace the incredibly ancient SysV init?" discussion was and failing to take part in it. OpenRC was knocked out of contention for reasons that were never really clear to me, and I'd have loved to put a bunch of time and effort into fixing whatever deficiencies the Debian folks believed made it unworthy of consideration.
Oh well.
[0] ...as well as some-to-much contemporary discussion...
dijit · 2026-06-29 08:17:21 UTC
Yes, exactly.
"Systemd-vs-SysV" was never the concern for me personally, it was always "Systemd as the last init we ever create" based on how it's being built, and I always tried to argue that it was a hard pill to swallow because there were already better foundations in the world (SMF, for my favourite example), people didn't want to have that discussion, they just wanted to talk about how bad SysV was and that systemd was progress... I was impeding progress...
But, we're here now, and replacing systemd at this point will require being API and bug compatible or else major software (like GNOME) won't run at all.
So, systemd is the last init we'll ever have, just like I feared.
simoncion · 2026-06-29 08:37:19 UTC
> "Systemd as the last init we ever create" ... they just wanted to talk about how bad SysV was and that systemd was progress... I was impeding progress...
Yeah, that rhetoric was maddening. Poettering and crew were -and continue to be- absolutely incapable of maintaining a project of such scope and importance.
Do you remember the fucking kdbus saga? I really wish the folks on the kernel side of that who were responsible for asking careful, technical questions, thinking deeply about the answers that they got, and cutting through the bluster and misdirection they received had been the ones in charge of deciding the new Debian init system for... Jessie, was it?
> But, we're here now, and replacing systemd at this point will require being API and bug compatible or else major software (like GNOME) won't run at all.
I've heard from many folks who have tried to reimplement substantial parts of the SystemD. [0] They report that the documentation is woefully inadequate, the interactions between components get incredibly complex, and the project maintainers have a habit of breaking things whenever they feel like it. This breakage doesn't matter to things they maintain, because they can make changes to account for it... but for "out of tree" reimplementations, well, they are -perhaps correctly- entirely disinterested in worrying about those.
> So, systemd is the last init we'll ever have, just like I feared.
Eh. I still hold hope that Debian or some other major distro will notice how unsuited the SystemD maintainers are to long-term stewardship of something so wide-reaching and critically important and cast about for alternatives. We'll see.
[0] This is a shorthand for "Systemd Project", not a slur against it. It sucks that systemd(1) and the project that contain it share the same name. [1]
[1] For a real-world example of the sort of conversation this confusion causes, check out [2]
The OpenRC people in Debian only really noticed the discussion when it reached the technical committee. There was an effort to put OpenRC into contention, and all of the technical committee people who did evaluations included it in their evaluations. The problem was that OpenRC as it existed on Debian at the time was lacking. People argued that it could with a little work do the things that the technical committee people pointed out, but the counterargument was that the decision really had to be made at that point, given the argument that had built up. I do recommend reading the discussions by Russ Alberry and others about OpenRC on the technical committee mailing list back then.
Yes, everyone who has, in the succeeding 12 years, framed this as a choice between van Smoorenburg init+rc and systemd either didn't pay attention or is being woefully slapdash. Debian's choice was between Upstart, as established on Ubuntu at the time, and systemd, with OpenRC as a late entry.
People also made the argument that van Smoorenburg init+rc could be fixed. And in fact they did address some of it, The same year (2014), the sprawling shell scripts so characteristic of van Smoorenburg init+rc were being replaced by a new system, modelled somewhat after Mewburn rc on NetBSD and FreeBSD, where the scripts were much shorter, largely declarative, and reliant upon a new init-d-script interpreter that did all of the repetitive common stuff.
>Why does it take others so long to see the same thing?
What thing, exactly? To me systemd has done what it has set out to do and I quite like it for it (not that it's perfect in every respect, but it's in general a welcome improvement on what came before it, especially in terms of consistency between distros instead of a million arbitrary differences). It's also important to note what systemd was offering to distro maintainers, as well. It substantially reduced the work involved in creating and packaging for a distro (though probably only Arch, which is explicitly a distro by and for the maintainers, really said that part loudly).
matheusmoreira · 2026-06-29 08:27:05 UTC
I enjoy using systemd but I'm glad Gentoo exists and I'm thankful that people are using and maintaining alternatives. Diverse ecosystems are not just good, they are necessary.
shevy-java · 2026-06-29 08:35:53 UTC
Gentoo is great from a philosophy point of view.
From a practical point of view, though, Gentoo kind of struggled a lot. Archlinux kind of took away a lot of the user base here and I don't think Arch is necessarily worse than Gentoo, even if Gentoo may still be better due to offering more choice, which is also true. I myself fell victim to the GoboLinux philosophy, so versioned AppDirs are the only logical way to install something (I don't use the GoboLinux naming scheme though, my naming scheme is simpler, but also flexible, e. g. I could use /pkg/htop/3.2.1/ as example, even though I opted for e. g. /home/Programs/Htop/3.2.1/ instead, just feeling nicer to read).
> Why does it take others so long to see the same thing?
People will have different opinions. Many bought into the pro-systemd advertisement without challenging it ever. Over the years this has also changed, what with the more recent "we love age sniffing" code change to systemd, but even still people don't want to think on their own. They like to adopt what is given to them as an opinion. If you look back in history, many articles about systemd were clearly written by a systemd developer. Naturally these are very biased articles.
adrian_b · 2026-06-29 08:38:16 UTC
I am one of the happy Gentoo users, who have escaped from systemd until now.
Some years ago I have experimented with systemd for a month, by using Arch Linux. However I have encountered an ugly bug and eventually I wiped it out.
The problem was not that there was a bug, I assume that the bug must have been solved years ago. The problem was that the bug was not something that could be attributed to a random error, like a cut-and-paste error when editing. It was a bug that in my opinion demonstrated extremely poor judgment in the overall software system design. Thus I considered that the bug was too outrageous and I blacklisted systemd.
(The bug consisted in that the computer, could fail to shutdown, randomly, due to a race condition regarding messages sent on D-Bus, messages that were generated for some reason by systemd while shutting down, when the recipient of a certain message could have been killed before receiving the last message intended for it, or the D-Bus daemon could have been killed before the last attempt of a message transmission, which resulted in a stall. The fact that sending and receiving messages on D-Bus was necessary for being able to complete a shutdown, was in itself a proof of stupidity. In decades of using computers, from IBM mainframes and DEC minicomputers, until the latest computers of today, only with systemd I have seen a case when shutting down a computer could fail. Moreover, even when successful, shutdown was very slow, unlike the instant shutdown with which I am accustomed. For decades my computers have been optimized to boot in a few seconds, by using custom kernels, so the supposed fast boot of systemd had not brought any improvement in my case, while the shutdown was degraded.)
nubinetwork · 2026-06-29 09:50:56 UTC
That's funny, because I've been converting all of my Gentoo systems to systemd... from my point of view, the writing is on the wall, most distros use systemd already, so there's no sense in not learning it.
mid-kid · 2026-06-29 07:57:57 UTC
Tbh, the installer was inevitable after systemd integrated a bootloader, crafted a paritioning scheme for autodiscovery, took over user and home directory management, and topped it off with an updater and "system extensions" layering system that some immutable distros are using.
I'm not saying any of this is particularly bad but it's been very clear fot a while that systemd just wants to be an OS. With immutable systems the "distribution" part of it is reduced to a build system, and everything else can be provided by systemd and flatpak.
d_tr · 2026-06-29 08:21:39 UTC
Can't these features be toggled?
mort96 · 2026-06-29 08:27:13 UTC
They're separate programs and system services which all more or less just do their own thing, just developed under the systemd umbrella. So it can't be "toggled", you can just not use the parts of systemd you don't want.
But it's meant to work as a cohesive system when everything in systemd is used together.
FWIW, I think it's great that someone is trying to make a coherent set of system services for Linux. Things tend to interoperate better when they're explicitly written to work together than when every component is meant to be hacked to work with arbitrary other services through shell script soup.
bayindirh · 2026-06-29 08:35:51 UTC
It's great that the same someone has formed a company called Amutable which has the sole purpose of converting Linux to a locked-down immutable OS where the users doesn't have the key.
Also it's interesting that a set of simple interfaces have worked for so long. Maybe they did something wrong that it didn't break?
That approach is part of why Valve has been able to ship Linux to general consumers.
I don't know exactly why you'd go for amutable specifically, but not handing users the key is a huge benefit to any company-owned hardware out there.
bayindirh · 2026-06-29 15:14:48 UTC
Having an immutable OS for some scenarios makes sense. However, I find waving the whole layer into systemd and kernel permanently, instead of having it as a layer which you can install and enable if you need so is a bit sinister.
This enables the danger of locking out every Linux distribution out there, esp. with new IPC protocols, new image based installation methods, encryption and whatnot systemd brings in with all these modules.
One day, Microsoft can disallow disabling of secure-boot for PC certification and stop signing 3rd party bootloaders. The rest will be fun.
jeroenhd · 2026-06-29 15:58:07 UTC
> instead of having it as a layer which you can install and enable if you need so is a bit sinister
I don't really get it. If you don't want systemd, you can install your own OpenRC-based immutable OS. I don't know if that currently exists (Android does, I suppose? maybe ChromeOS?) but it's not like systemd is forbidding everyone from doing anything.
The biggest difference between systemd and alternatives is that systemd builds out the architecture that makes things like building immutable distros easy. If you have a thousand different components, all with slightly different roles, the amount of coordination necessary to get everything to play nice together makes it near impossible to achieve the same things a coordinated system can achieve.
I'm sure that if someone would build an alternative to systemd-sysext and prepare a prebuilt set of tooling and configuration that does what systemd does, there will be distros that will use them.
Secure boot can be overridden by just adding your own keys. At worst, Microsoft will refuse to boot Windows because you added a key yourself. The exception is extra expensive, specially labeled Enterprime (TM) hardware built for Windows sysadmins and Microsoft tablets built for consumers, but I don't know why you'd buy either if you don't want to give MS that much control.
gatlin · 2026-06-29 14:44:21 UTC
Lennart Poettering will not rest until all software is completely unusable.
tym0 · 2026-06-29 09:02:17 UTC
Right, are any of the things mentioned in the GP really required if you only want this init?
I know they've attached all these projects to the systemd brand because they thought it would beneficial but it's hard not to wonder if we could avoid all those discussions if the umbrella project was called something different...
mort96 · 2026-06-29 09:24:53 UTC
No, you can just run the systemd init system and not use any other systemd programs.
I would probably run systemd-journald just because it's really nice to have a logging system which knows about the system services, but it's not required.
bonzini · 2026-06-29 11:24:48 UTC
You probably also want to run udev, and logind comes close. Everything other than these four is absolutely optional.
mort96 · 2026-06-29 08:25:12 UTC
The various Red Hat affiliated projects have so much more reason to call themselves the "OS" than GNU at this point. A Linux system with systemd for the init, systemd-networkd and NetworkManager for networking, GNOME for the desktop, systemd-boot for the bootloader, RPM/DNF as the package manager, etc. probably contains orders of magnitude more Red Hat code than GNU code even if the system uses glibc and GNU coreutils.
benterix · 2026-06-29 10:50:28 UTC
Suppose someone wants to play this game, what's the point? Not to mention the fact that Gnome, even though is not a GNU project, literally means GNU Network Object Model Environment.
s_ting765 · 2026-06-29 08:52:30 UTC
Partition autodiscovery is pretty neat. I did my archlinux install with it using this guide[0]. I have never touched /etc/fstab and I have had zero to worry about corrupting a boot with wrong fstab entries.
Btrfs and zfs don't need an fstab at all, they manage their mountable filesystems internally.
s_ting765 · 2026-06-29 10:46:21 UTC
Sure. After you have located root and the boot partition which is what this addresses.
simoncion · 2026-06-29 10:56:48 UTC
My searches for "systemd partition autodiscovery" lead me to [0]. In the table labeled "Table 1. Partition Type GUIDs", we find this in the Explanation section for 'SD_GPT_HOME'
The first partition with this type UUID on the same disk as the root partition is mounted to /home/.
...you can't spread your /home and / partitions on separate disks and use this? In fact, it looks like you can't use this autodetection unless all of the partitions of interest (including your /boot/) are on the same disk? Seriously? There's also no indication that this works with LVM... which is -if true- is extremely inconvenient. The document at [1] only mentions LVM in passing, and [2] is Poettering saying "Fuck off, I don't want to support doing this with LVM".
Did I misread a document or fail to find a relevant one? If not, is this really limited to single-disk, "legacy" [3] configurations?
[3] Yes, I'm considering any fixed-partition mechanism, whether MBR or GPT to be "legacy". The flexibility you get from LVM is sooooo nice.
jeroenhd · 2026-06-29 14:33:04 UTC
> you can't spread your /home and / partitions on separate disks and use this
No, you'll need to add a line to your fstab manually if you want something autodiscovery cannot do, like multi-disk setups, LVM, and FDE with unsupported configurations. It's great if it works for you and a very minor change if it doesn't.
I don't recall ever installing a system with / and /home on separate partitions, though.
simoncion · 2026-06-30 02:21:09 UTC
> No, you'll need to add a line to your fstab manually if you want something autodiscovery cannot do...
It's just shocking that autodiscovery is so extremely limited. I'm aware that if you want to do something that autodiscovery can't do, then you cant use autodiscovery for that thing... I'm pretty sure that was covered in a recent Tautology Club meeting.
> I don't recall ever installing a system with / and /home on separate partitions, though.
I'd wager that that's the configuration of vast majority of the consumer systems out there... which makes it even more confusing how anemic partition autodetection is.
Its target user is one who bothers to partition out space for subdirectories, but doesn't use either multiple disks or LVM? That's a very particular sort of user.
jeroenhd · 2026-06-30 08:11:48 UTC
> I'd wager that that's the configuration of vast majority of the consumer systems out there...
I'm not so sure. Most people I know, including developers, only have one SSD, maybe a hard drive for photos or whatever that's not mounted inside /home.
The most popular mainstream Linux distributions (Android, ChromeOS, SteamOS) all default to a single disk setup, as do most virtual machines (which must exceed the number of home installs by at least a thousandfold).
For a particular brand of enthusiasts, running multi-disk is definitely more popular (I have 4 in my desktop), but I don't think those are the majority, and even among those splitting partitions across disks rather than just using a /media (or equivalent) to access the larger disk like you would an external drive is quite popular.
Multi-disk detection would be nice, but I can already imagine the absolute mess that would happen if you were to try to boot on a multi-distro PC, or even just a recovery flash drive on an existing Linux image. My recovery boot drive only has a root partition so auto-detecting the drive will work fine, but auto-mounting my home directory to /home would mess up the entire system.
The code would be so full of edge cases and weird guards that it'll inevitably just break without configuration, making the entire thing pretty damn useless.
pseudalopex · 2026-06-29 18:31:57 UTC
> ...you can't spread your /home and / partitions on separate disks and use this? In fact, it looks like you can't use this autodetection unless all of the partitions of interest (including your /boot/) are on the same disk? Seriously?
How would it choose from 2 home partitions on other disks?
simoncion · 2026-06-30 02:13:47 UTC
A little better than how you'd handle having multiple '/home' lines in fstab? Either pick one to mount, or have the bootloader give a hint as to which one to mount (as there's apparently a whole protocol the bootloader must use for this to work). [0]
But. Having said that, why would you have two home partitions on other disks? Having a bigass disk for your home partition [2] is way more common than having multiple entirely-independent Linux installs that you all want to use this automagic mount point detection on. Do you disagree?
[0] > Note that automatic discovery of the root only works if the boot loader communicates this information to the OS, by implementing the (Boot Loader Interface)[1].
That was pre-covid, and the guy stepped down. But I can see your point. My point is that they had time to re-think what happened.
LetMeLogin · 2026-06-29 09:24:21 UTC
That was my initial thought.
atmanactive · 2026-06-29 08:00:29 UTC
I'm confused... isn't Devuan exactly this?
_flux · 2026-06-29 08:05:07 UTC
Devuan us a separate Debian with its own repositories (and presumably many packages patched to improve systemd-less life), while this is just replacing Systemd with OpenRC on a Debian system, while keeping Debian repos etc.
nubinetwork · 2026-06-29 09:44:27 UTC
You're going to have to make a separate repo for everything anyways, because you'll have to change all the init scripts and whatnot that get supplied with programs... well, unless you install both and just leave the useless systemd files laying around forever.
_flux · 2026-06-29 10:08:22 UTC
My /usr/lib/systemd takes 6.4 megabytes, so I think I could live with that overhead. Or I suppose just delete them manually.
What would actually be useful would be a generic OpenRC wrapper that would ingest those service files and provide traditional start/stop interface for them.
nubinetwork · 2026-06-29 10:22:03 UTC
You mean the inverse of systemd.generator? Probably wouldn't be hard to make, but you'd have to be pretty committed to your init system to not just write the script by hand...
_flux · 2026-06-29 10:28:07 UTC
Hmm, I perhaps didn't quite catch this. I thought having a generator would let you be less committed to it, as you wouldn't need to manually write all the init scripts you need.. ?
nubinetwork · 2026-06-29 10:32:36 UTC
Writing a basic init script is less intensive than having to learn the entire "schema" for both script formats, which you'd probably want to know if you were writing the generator.
_flux · 2026-06-29 10:47:52 UTC
Yes, but one only needs to write it once, and then everyone could use it. It could probably even be packaged as an official Debian package.
simoncion · 2026-06-29 11:35:17 UTC
> Yes, but one only needs to write it once...
...and then keep up with behavioral changes that the Systemd Project people introduce and load-bearing bugs that services end up relying on for lifecycle management.
OpenRC service files are easy to write, and their schema is far far simpler than that of Unit files. [0] It's really not worth the effort to write and maintain an converter, if for no other reason than you need to understand the semantics of both systems' service files to double-check the results of the converter.
It's wild to see people having this argument in the subjunctive in 2026. I've had a convert-systemd-units tool since 2014, and provided Debian packages for the toolset that it is part of for around that long.
Writing a script is easy. But converting a whole system of .service files seems like a great time to automate.
shevy-java · 2026-06-29 08:30:04 UTC
Well - it is an alternative to debian and in many ways is debian. But the counter-question is: why should debian users HAVE to use systemd? This is a much more fundamental question. Devuan solved it via forking. I think the proper way to handle this is to be able to offer both. I think gentoo went that approach. Debian went the "my-way-or-the-highway" route, which objectively is worse, even if understandable (less to maintain; see LFS/BLFS submitting to systemd finally in 2026: https://old.reddit.com/r/Gentoo/comments/1qy4xsc/might_gento... and https://www.phoronix.com/news/LFS-Dropping-SysVinit)
muvlon · 2026-06-29 09:00:26 UTC
FWIW, debian did the gentoo approach for years. I used to run debian with OpenRC during a time when systemd was already the default. It and other init systems remained fully supported by the distro for quite a while.
Eventually, the pain of supporting everything became too much and debian did go with "my way or the highway", which I supported at the time and still do. I have no idea how that could be "objectively worse", it's very obviously a tradeoff to me. If your packages have to work on any init system, they can not benefit from any particular init system's features and have to work with the lowest common denominator. Every service has to hack around the lack of working state management with pidfile hacks and such.
In my opinion, it's better for a distro to pick any single init system than to try to support them all by limiting all packages to SysV style init scripts. Yes, user choice is important, but that can and does happen via distro choice. Alpine or Devuan are right there if you need them. Linux is fragmented enough, we don't need every distro to be a microcosm of the fractured overall Linux landscape.
tuna74 · 2026-06-29 16:08:25 UTC
Debian is an OS, not a kit to build an OS using lots of different components.
mkesper · 2026-06-29 08:12:12 UTC
You do not have to use all resources that are under the systemd umbrella. That's just BS, sorry. And prod deployments breaking... Well I guess that never happened with those best-managed sysv init scripts?
Guys, pick your fights reasonably.
ErroneousBosh · 2026-06-29 08:13:50 UTC
I've never *ever* broken a production system by reconfiguring a sysvinit service, at all, no no no, not me...
LetMeLogin · 2026-06-29 08:16:33 UTC
Absolutely not!
adrian_b · 2026-06-29 09:12:32 UTC
For production systems, I started more than a quarter of century ago with FreeBSD, which at that time was still much more stable and more performant than any Linux variant.
Even then, the init scripts system of FreeBSD was much better than the traditional sysvinit. I have never ever had the slightest problem with it, since then until today, when I still run a mixture of Linux and FreeBSD servers.
In the following years, many features of the FreeBSD software package system and of its init scripts system have become available in some Linux distributions, especially in Gentoo.
I have never used in production any variant of the traditional sysvinit, while with the improved versions from FreeBSD, Gentoo and a few others I have never seen any difficulty and no feature that could have been improved by the use of systemd.
In my opinion, the way to an optimal init scripts system has been shown by Daniel J. Bernstein with his "daemontools", which I have also been using continuously 24/7 for more than a quarter of a century, for some essential services, on many servers.
Today, there are a few new init scripts systems that have been inspired by the DJB daemontools, and I think that one of them could become the best choice in the future.
shevy-java · 2026-06-29 08:32:00 UTC
Agreed. But you still need to know what to enable/disable, so more complexity is the outcome.
> And prod deployments breaking... Well I guess that never happened with those best-managed sysv init scripts?
Which of these two has the larger surface area? I would assume there are more problems in systemd simply because it has a lot more code.
> Guys, pick your fights reasonably.
I don't see what is not reasonable here at all. Can you explain this? In particular I would like to see your explanation how more code means less issues, all other things considered being equal. And that's just the code - there are many additional issues, documentation, maintenance and so forth.
gf000 · 2026-06-29 09:21:46 UTC
Not all code are equal.
There is an essential complexity you need, period. This is a fundamental truth that that can never decrease.
And init and service management is a generally hard problem - like a static approach wouldn't bring you too far, you have services activated at runtime, modules appearing, disappearing etc.
So it's a hard problem, yet many parts are repeating. A network service and a file system mount both require some kind of dependency management, parallelism with locks, logging etc. On top, a declarative approach is far better for such a dynamic system and that's exactly what systemd is.
OpenRC gives some of this, but bash is an abomination and anything larger than 2-3 lines will have bugs. I don't really see what it's giving you over an open-source binary that parses trivial .ini-like files that have pretty good portability across systems.
adrian_b · 2026-06-29 09:40:46 UTC
Init scripts should not need significantly more than a few lines.
I do not think that I have ever used an init script longer than 1 page of text.
If bugs are feared, it is always possible to invoke a script written in another scripting language.
While some people like Python for this purpose, in the past I had good results by using scsh for complex scripts where one wants to avoid bugs.
"scsh" is a Scheme dialect specially designed for replacing shell scripts, i.e. where you have a convenient syntax to express the features of a shell scripting language, like writing command pipelines, file redirections, etc.
Even a zsh script can avoid the most frequent errors from bash scripts, which are caused by the incorrect use of quotation.
With any scripting language, it is possible and recommendable to use strictly declarative init scripts, which only contain definitions of variables and parameters for invocations, separating the procedure definitions in distinct files, which are common to any installation and which are not modified for a custom configuration.
Even when it may be desirable to implement some functions of the init system in binary executables, those must be extremely simple, as demonstrated by the small executables included in the daemontools of Daniel J. Bernstein, and not like the big monstrosities of Systemd.
simoncion · 2026-06-29 09:50:01 UTC
> OpenRC gives some of this, but bash is an abomination and anything larger than 2-3 lines will have bugs. I don't really see what it's giving you over an open-source binary that parses trivial .ini-like files that have pretty good portability across systems.
Hey, hun. Here's an OpenRC service file that's nearly as small as it can get. [0] I don't know about you, but that OpenRC service file looks a whole hell of a lot like a Unit file to me. Do you disagree?
If you replace line 14 with
supervisor=supervise-daemon
and remove the "-D" from 'command_args' to make avahi-daemon run in the foreground, then you don't have to deal with "icky" pidfiles, and you get daemon supervision and automatic restart on failure.
OpenRC also does parallel service start and stop. I've been using it for... ten years now with no problem.
There's only the optionality because of the pushback though.
One element of the free software culture is pushback against monolithic software. It allows you to swap out components in this way. Without that culture there wouldn't be the choice. You could disagree with a particular manifestation of that culture, but at least understand and accept that culture and accept that the reason why you perceive this to be a non issue is precisely because of that culture.
ErroneousBosh · 2026-06-29 08:12:56 UTC
Interesting that it's kind of that simple. It looks almost like you could make a fairly straightforward fork that works with that, as long as they sysvinit packages are kept up-to-date.
I have to say while I dislike systemd it hasn't annoyed me enough to send me down that route yet.
Granted, this is not quite a thorough age sniffing requirement yet,
but with the legislation in the USA and other countries currently
changed, the operating system is de-jure forced to sniff off data
from people and send it over to others, be it state agencies or
companies. It's like the novel 1984 adapted to the modern days, but
crap. With tons of AI slop.
gf000 · 2026-06-29 09:24:11 UTC
Like they added a field to be possibly law-complient?
What's the alternative, Linux should just not run in places where this will be the legal framework? How is that field limits your freedom?
ErroneousBosh · 2026-06-30 11:22:16 UTC
You can just ignore them. What are they going to do about it?
ErroneousBosh · 2026-06-29 19:27:38 UTC
You can just compile it without that.
ChocolateGod · 2026-06-29 08:26:58 UTC
This makes the mistake of confusing systemd the service manager and systemd the project. This is an easy mistake to make given they have the same name.
The systemd service manager does not have an installer, systemd-sysinstall is a separate tool that's part of the systemd project.
systemd has not integrated age verification. All that's been discussed is a simple field to allow a user to register a DoB and an way for services to validate the user is over a certain age.
You could arguably already do this by having a DoB field for the user, but that'd involve giving applications your full DoB which I'm sure is distasteful for many.
> usual "fight" against non-sense laws
Because developers have to follow laws like everyone else?
mort96 · 2026-06-29 11:50:33 UTC
The expressed intention behind adding the DoB field is to comply with age verification laws. Intent matters a whole lot here.
ChocolateGod · 2026-06-29 13:02:29 UTC
> comply with age verification laws
Do you want the developers to ignore the law and in the case of companies like Red Hat etc be vulnerable to law suits?
LtWorf · 2026-06-29 13:45:42 UTC
There's multiple laws, and they all conflict with each other.
They are obeying some by violating some others. In this case I'd personally do nothing.
iamnothere · 2026-06-29 14:10:12 UTC
Yes. Stand up and be a test case like Bernstein. Show some guts.
In the case of a company there’s even less at risk, and a lot of good will to be farmed.
ChocolateGod · 2026-06-29 14:22:51 UTC
Are you offering to pay for their lawyers?
iamnothere · 2026-06-29 15:09:56 UTC
If it’s a good test case, EFF would surely represent an individual pro bono. Depending on the importance of a corporate case, they would contribute heavily. But you can think of the expense as marketing, especially for a company like Red Hat who gets a lot of unnecessary grief from the community.
7e · 2026-06-29 17:01:40 UTC
These are laws passed by democratically elected legislatures. It’s not a legal issue, it’s a political one. Ostensibly, the will of the people. But these wimpy geeks passively-aggressively protest by arguing about code online, instead of engaging in real political activism.
iamnothere · 2026-06-29 17:16:31 UTC
When lobbyists push legislators to enact laws that violate the Constitution, and voting differently does not resolve the problem, the next recourse is the jury box. Courts are a check on the other two branches.
halJordan · 2026-06-29 19:21:04 UTC
You can't foist this on an ethereal other that we can just blame for all our ills. Pretending American democracy is somehow broken to the point voting doesn't work is an insane take. Especially because you literally watched republican grassroots vote in their man and he's giving them what he campaigned on to give them.
Pretending there's nothing to done is just an excuse to do nothing
iamnothere · 2026-06-29 19:28:05 UTC
I was just as unhappy with Biden, with Obama (by the end of his term), and with Bush. So no, voting doesn’t work.
Regardless of the face you put on the presidency, we are always going to have to fight for privacy and freedom at the grassroots level.
Fortunately, economic decline has brought with it a decline in state capacity, which does bring new problems, but enforcement is becoming an issue across the board. That’s a form of freedom, even if it sucks to deal with stuff like petty crime on a daily basis.
mort96 · 2026-06-29 20:02:25 UTC
I don't think there's anything SystemD has to do in order to comply with age verification laws. They could just ignore it. They're not an operating system.
ChocolateGod · 2026-06-30 19:02:49 UTC
If any distro made their own way to store a DoB field, it'd be a nightmare of interoperability.
wink · 2026-06-29 12:16:51 UTC
Which law though?
Which country/state/region? Does it even apply? We're talking about an open source project that is not being sold, with contributors from all over the world.
ChocolateGod · 2026-06-29 13:01:35 UTC
IIRC laws in some US states will require OS's to collect the age of the user so services can age restrict, it does not mandate any kind of ID verification.
It doesn't matter it's an open source project, ultimately it ends up in commercial products which do require following the rules.
Comments
Maybe it's too late.
LP is cooking a way to deny system modifications [1]
[1] https://news.ycombinator.com/item?id=46784572
I don't think it's janky though. It's pretty great. It has an answer to everything I've ever needed from it.
It's far from janky, at least compared to what else is out there for Linux. If you're not writing systemd service files, you're almost surely back to writing unpredictable 80s style scripting jank.
Gentoo is still home to a sizeable number of users who noped out of systemd more than 10 years ago. This is exactly the kind of thing they saw on the horizon. Why does it take others so long to see the same thing?
As I've mentioned elsewhere, SystemD is great... until you hit a bug born of its accidental complexity, or you find can't do something because the SystemD maintainers -sometimes suddenly- decided that they didn't want to let people do it anymore.
[0] This is shorthand for "The Systemd Project", not a slur against it. It sucks shit that systemd(1) and the project it's part of share the same name... it's very confusing. [1]
[1] For a real-world example of the sort of conversation this confusion causes, check out [2]
[2] <https://news.ycombinator.com/item?id=48716382>
As a Gentoo user for the past ~quarter-century, I'd say that it's more that -unlike Debian- Gentoo has been using a system service manager that's way better than the classic SysV init for approximately forever.
The early discussion of systemd-as-init [0] was pretty much 100% focused on how much better systemd-as-init was than classic SysV init. When restricted like this, systemd-as-init is an obvious winner. But, when you consider other init systems -such as OpenRC- that provide a bunch of useful scaffolding and support tools (rather than demanding you reimplement all that yourself) the benefits of using systemd-as-init are far less clear.
I've mentioned this before in an HN comment or two from way back when, but I'm really mad at myself for not recognizing how extremely important the "What should Debian adopt to replace the incredibly ancient SysV init?" discussion was and failing to take part in it. OpenRC was knocked out of contention for reasons that were never really clear to me, and I'd have loved to put a bunch of time and effort into fixing whatever deficiencies the Debian folks believed made it unworthy of consideration.
Oh well.
[0] ...as well as some-to-much contemporary discussion...
"Systemd-vs-SysV" was never the concern for me personally, it was always "Systemd as the last init we ever create" based on how it's being built, and I always tried to argue that it was a hard pill to swallow because there were already better foundations in the world (SMF, for my favourite example), people didn't want to have that discussion, they just wanted to talk about how bad SysV was and that systemd was progress... I was impeding progress...
But, we're here now, and replacing systemd at this point will require being API and bug compatible or else major software (like GNOME) won't run at all.
So, systemd is the last init we'll ever have, just like I feared.
Yeah, that rhetoric was maddening. Poettering and crew were -and continue to be- absolutely incapable of maintaining a project of such scope and importance.
Do you remember the fucking kdbus saga? I really wish the folks on the kernel side of that who were responsible for asking careful, technical questions, thinking deeply about the answers that they got, and cutting through the bluster and misdirection they received had been the ones in charge of deciding the new Debian init system for... Jessie, was it?
> But, we're here now, and replacing systemd at this point will require being API and bug compatible or else major software (like GNOME) won't run at all.
I've heard from many folks who have tried to reimplement substantial parts of the SystemD. [0] They report that the documentation is woefully inadequate, the interactions between components get incredibly complex, and the project maintainers have a habit of breaking things whenever they feel like it. This breakage doesn't matter to things they maintain, because they can make changes to account for it... but for "out of tree" reimplementations, well, they are -perhaps correctly- entirely disinterested in worrying about those.
> So, systemd is the last init we'll ever have, just like I feared.
Eh. I still hold hope that Debian or some other major distro will notice how unsuited the SystemD maintainers are to long-term stewardship of something so wide-reaching and critically important and cast about for alternatives. We'll see.
[0] This is a shorthand for "Systemd Project", not a slur against it. It sucks that systemd(1) and the project that contain it share the same name. [1]
[1] For a real-world example of the sort of conversation this confusion causes, check out [2]
[2] <https://news.ycombinator.com/item?id=48716382>
Yes, everyone who has, in the succeeding 12 years, framed this as a choice between van Smoorenburg init+rc and systemd either didn't pay attention or is being woefully slapdash. Debian's choice was between Upstart, as established on Ubuntu at the time, and systemd, with OpenRC as a late entry.
* https://jdebp.uk/FGA/debian-systemd-packaging-hoo-hah.html
Interesting tidbit:
People also made the argument that van Smoorenburg init+rc could be fixed. And in fact they did address some of it, The same year (2014), the sprawling shell scripts so characteristic of van Smoorenburg init+rc were being replaced by a new system, modelled somewhat after Mewburn rc on NetBSD and FreeBSD, where the scripts were much shorter, largely declarative, and reliant upon a new init-d-script interpreter that did all of the repetitive common stuff.
* https://unix.stackexchange.com/a/480897/5132
* https://manpages.debian.org/trixie/sysvinit-utils/init-d-scr...
What thing, exactly? To me systemd has done what it has set out to do and I quite like it for it (not that it's perfect in every respect, but it's in general a welcome improvement on what came before it, especially in terms of consistency between distros instead of a million arbitrary differences). It's also important to note what systemd was offering to distro maintainers, as well. It substantially reduced the work involved in creating and packaging for a distro (though probably only Arch, which is explicitly a distro by and for the maintainers, really said that part loudly).
From a practical point of view, though, Gentoo kind of struggled a lot. Archlinux kind of took away a lot of the user base here and I don't think Arch is necessarily worse than Gentoo, even if Gentoo may still be better due to offering more choice, which is also true. I myself fell victim to the GoboLinux philosophy, so versioned AppDirs are the only logical way to install something (I don't use the GoboLinux naming scheme though, my naming scheme is simpler, but also flexible, e. g. I could use /pkg/htop/3.2.1/ as example, even though I opted for e. g. /home/Programs/Htop/3.2.1/ instead, just feeling nicer to read).
> Why does it take others so long to see the same thing?
People will have different opinions. Many bought into the pro-systemd advertisement without challenging it ever. Over the years this has also changed, what with the more recent "we love age sniffing" code change to systemd, but even still people don't want to think on their own. They like to adopt what is given to them as an opinion. If you look back in history, many articles about systemd were clearly written by a systemd developer. Naturally these are very biased articles.
Some years ago I have experimented with systemd for a month, by using Arch Linux. However I have encountered an ugly bug and eventually I wiped it out.
The problem was not that there was a bug, I assume that the bug must have been solved years ago. The problem was that the bug was not something that could be attributed to a random error, like a cut-and-paste error when editing. It was a bug that in my opinion demonstrated extremely poor judgment in the overall software system design. Thus I considered that the bug was too outrageous and I blacklisted systemd.
(The bug consisted in that the computer, could fail to shutdown, randomly, due to a race condition regarding messages sent on D-Bus, messages that were generated for some reason by systemd while shutting down, when the recipient of a certain message could have been killed before receiving the last message intended for it, or the D-Bus daemon could have been killed before the last attempt of a message transmission, which resulted in a stall. The fact that sending and receiving messages on D-Bus was necessary for being able to complete a shutdown, was in itself a proof of stupidity. In decades of using computers, from IBM mainframes and DEC minicomputers, until the latest computers of today, only with systemd I have seen a case when shutting down a computer could fail. Moreover, even when successful, shutdown was very slow, unlike the instant shutdown with which I am accustomed. For decades my computers have been optimized to boot in a few seconds, by using custom kernels, so the supposed fast boot of systemd had not brought any improvement in my case, while the shutdown was degraded.)
I'm not saying any of this is particularly bad but it's been very clear fot a while that systemd just wants to be an OS. With immutable systems the "distribution" part of it is reduced to a build system, and everything else can be provided by systemd and flatpak.
But it's meant to work as a cohesive system when everything in systemd is used together.
FWIW, I think it's great that someone is trying to make a coherent set of system services for Linux. Things tend to interoperate better when they're explicitly written to work together than when every component is meant to be hacked to work with arbitrary other services through shell script soup.
Also it's interesting that a set of simple interfaces have worked for so long. Maybe they did something wrong that it didn't break?
See: https://www.amutable.com
That approach is part of why Valve has been able to ship Linux to general consumers.
I don't know exactly why you'd go for amutable specifically, but not handing users the key is a huge benefit to any company-owned hardware out there.
This enables the danger of locking out every Linux distribution out there, esp. with new IPC protocols, new image based installation methods, encryption and whatnot systemd brings in with all these modules.
One day, Microsoft can disallow disabling of secure-boot for PC certification and stop signing 3rd party bootloaders. The rest will be fun.
I don't really get it. If you don't want systemd, you can install your own OpenRC-based immutable OS. I don't know if that currently exists (Android does, I suppose? maybe ChromeOS?) but it's not like systemd is forbidding everyone from doing anything.
The biggest difference between systemd and alternatives is that systemd builds out the architecture that makes things like building immutable distros easy. If you have a thousand different components, all with slightly different roles, the amount of coordination necessary to get everything to play nice together makes it near impossible to achieve the same things a coordinated system can achieve.
I'm sure that if someone would build an alternative to systemd-sysext and prepare a prebuilt set of tooling and configuration that does what systemd does, there will be distros that will use them.
Secure boot can be overridden by just adding your own keys. At worst, Microsoft will refuse to boot Windows because you added a key yourself. The exception is extra expensive, specially labeled Enterprime (TM) hardware built for Windows sysadmins and Microsoft tablets built for consumers, but I don't know why you'd buy either if you don't want to give MS that much control.
I know they've attached all these projects to the systemd brand because they thought it would beneficial but it's hard not to wonder if we could avoid all those discussions if the umbrella project was called something different...
I would probably run systemd-journald just because it's really nice to have a logging system which knows about the system services, but it's not required.
[0] https://walian.co.uk/arch-install-with-secure-boot-btrfs-tpm...
Did I misread a document or fail to find a relevant one? If not, is this really limited to single-disk, "legacy" [3] configurations?
[0] <https://www.freedesktop.org/software/systemd/man/latest/syst...>
[1] <https://uapi-group.org/specifications/specs/discoverable_par...>
[2] <https://github.com/systemd/systemd/issues/1727>
[3] Yes, I'm considering any fixed-partition mechanism, whether MBR or GPT to be "legacy". The flexibility you get from LVM is sooooo nice.
No, you'll need to add a line to your fstab manually if you want something autodiscovery cannot do, like multi-disk setups, LVM, and FDE with unsupported configurations. It's great if it works for you and a very minor change if it doesn't.
I don't recall ever installing a system with / and /home on separate partitions, though.
It's just shocking that autodiscovery is so extremely limited. I'm aware that if you want to do something that autodiscovery can't do, then you cant use autodiscovery for that thing... I'm pretty sure that was covered in a recent Tautology Club meeting.
> I don't recall ever installing a system with / and /home on separate partitions, though.
I'd wager that that's the configuration of vast majority of the consumer systems out there... which makes it even more confusing how anemic partition autodetection is.
Its target user is one who bothers to partition out space for subdirectories, but doesn't use either multiple disks or LVM? That's a very particular sort of user.
I'm not so sure. Most people I know, including developers, only have one SSD, maybe a hard drive for photos or whatever that's not mounted inside /home.
The most popular mainstream Linux distributions (Android, ChromeOS, SteamOS) all default to a single disk setup, as do most virtual machines (which must exceed the number of home installs by at least a thousandfold).
For a particular brand of enthusiasts, running multi-disk is definitely more popular (I have 4 in my desktop), but I don't think those are the majority, and even among those splitting partitions across disks rather than just using a /media (or equivalent) to access the larger disk like you would an external drive is quite popular.
Multi-disk detection would be nice, but I can already imagine the absolute mess that would happen if you were to try to boot on a multi-distro PC, or even just a recovery flash drive on an existing Linux image. My recovery boot drive only has a root partition so auto-detecting the drive will work fine, but auto-mounting my home directory to /home would mess up the entire system.
The code would be so full of edge cases and weird guards that it'll inevitably just break without configuration, making the entire thing pretty damn useless.
How would it choose from 2 home partitions on other disks?
But. Having said that, why would you have two home partitions on other disks? Having a bigass disk for your home partition [2] is way more common than having multiple entirely-independent Linux installs that you all want to use this automagic mount point detection on. Do you disagree?
[0] > Note that automatic discovery of the root only works if the boot loader communicates this information to the OS, by implementing the (Boot Loader Interface)[1].
[1] <https://systemd.io/BOOT_LOADER_INTERFACE/>
[2] ...because where else would you store all your porn?
What would actually be useful would be a generic OpenRC wrapper that would ingest those service files and provide traditional start/stop interface for them.
...and then keep up with behavioral changes that the Systemd Project people introduce and load-bearing bugs that services end up relying on for lifecycle management.
OpenRC service files are easy to write, and their schema is far far simpler than that of Unit files. [0] It's really not worth the effort to write and maintain an converter, if for no other reason than you need to understand the semantics of both systems' service files to double-check the results of the converter.
[0] <https://news.ycombinator.com/item?id=48717056>
* https://jdebp.uk/Softwares/nosh/guide/commands/convert-syste...
* https://jdebp.uk/Softwares/nosh/guide/converting-systemd-uni...
* https://jdebp.uk/Softwares/nosh/debian-binary-packages.html
Eventually, the pain of supporting everything became too much and debian did go with "my way or the highway", which I supported at the time and still do. I have no idea how that could be "objectively worse", it's very obviously a tradeoff to me. If your packages have to work on any init system, they can not benefit from any particular init system's features and have to work with the lowest common denominator. Every service has to hack around the lack of working state management with pidfile hacks and such.
In my opinion, it's better for a distro to pick any single init system than to try to support them all by limiting all packages to SysV style init scripts. Yes, user choice is important, but that can and does happen via distro choice. Alpine or Devuan are right there if you need them. Linux is fragmented enough, we don't need every distro to be a microcosm of the fractured overall Linux landscape.
Even then, the init scripts system of FreeBSD was much better than the traditional sysvinit. I have never ever had the slightest problem with it, since then until today, when I still run a mixture of Linux and FreeBSD servers.
In the following years, many features of the FreeBSD software package system and of its init scripts system have become available in some Linux distributions, especially in Gentoo.
I have never used in production any variant of the traditional sysvinit, while with the improved versions from FreeBSD, Gentoo and a few others I have never seen any difficulty and no feature that could have been improved by the use of systemd.
In my opinion, the way to an optimal init scripts system has been shown by Daniel J. Bernstein with his "daemontools", which I have also been using continuously 24/7 for more than a quarter of a century, for some essential services, on many servers.
Today, there are a few new init scripts systems that have been inspired by the DJB daemontools, and I think that one of them could become the best choice in the future.
> And prod deployments breaking... Well I guess that never happened with those best-managed sysv init scripts?
Which of these two has the larger surface area? I would assume there are more problems in systemd simply because it has a lot more code.
> Guys, pick your fights reasonably.
I don't see what is not reasonable here at all. Can you explain this? In particular I would like to see your explanation how more code means less issues, all other things considered being equal. And that's just the code - there are many additional issues, documentation, maintenance and so forth.
There is an essential complexity you need, period. This is a fundamental truth that that can never decrease.
And init and service management is a generally hard problem - like a static approach wouldn't bring you too far, you have services activated at runtime, modules appearing, disappearing etc.
So it's a hard problem, yet many parts are repeating. A network service and a file system mount both require some kind of dependency management, parallelism with locks, logging etc. On top, a declarative approach is far better for such a dynamic system and that's exactly what systemd is.
OpenRC gives some of this, but bash is an abomination and anything larger than 2-3 lines will have bugs. I don't really see what it's giving you over an open-source binary that parses trivial .ini-like files that have pretty good portability across systems.
I do not think that I have ever used an init script longer than 1 page of text.
If bugs are feared, it is always possible to invoke a script written in another scripting language.
While some people like Python for this purpose, in the past I had good results by using scsh for complex scripts where one wants to avoid bugs.
"scsh" is a Scheme dialect specially designed for replacing shell scripts, i.e. where you have a convenient syntax to express the features of a shell scripting language, like writing command pipelines, file redirections, etc.
Even a zsh script can avoid the most frequent errors from bash scripts, which are caused by the incorrect use of quotation.
With any scripting language, it is possible and recommendable to use strictly declarative init scripts, which only contain definitions of variables and parameters for invocations, separating the procedure definitions in distinct files, which are common to any installation and which are not modified for a custom configuration.
Even when it may be desirable to implement some functions of the init system in binary executables, those must be extremely simple, as demonstrated by the small executables included in the daemontools of Daniel J. Bernstein, and not like the big monstrosities of Systemd.
Hey, hun. Here's an OpenRC service file that's nearly as small as it can get. [0] I don't know about you, but that OpenRC service file looks a whole hell of a lot like a Unit file to me. Do you disagree?
If you replace line 14 with
and remove the "-D" from 'command_args' to make avahi-daemon run in the foreground, then you don't have to deal with "icky" pidfiles, and you get daemon supervision and automatic restart on failure.OpenRC also does parallel service start and stop. I've been using it for... ten years now with no problem.
[0] <https://github.com/OpenRC/openrc/blob/29f620c16036586c39ec17...>
One element of the free software culture is pushback against monolithic software. It allows you to swap out components in this way. Without that culture there wouldn't be the choice. You could disagree with a particular manifestation of that culture, but at least understand and accept that culture and accept that the reason why you perceive this to be a non issue is precisely because of that culture.
I have to say while I dislike systemd it hasn't annoyed me enough to send me down that route yet.
https://github.com/systemd/systemd/pull/40954
Granted, this is not quite a thorough age sniffing requirement yet, but with the legislation in the USA and other countries currently changed, the operating system is de-jure forced to sniff off data from people and send it over to others, be it state agencies or companies. It's like the novel 1984 adapted to the modern days, but crap. With tons of AI slop.
What's the alternative, Linux should just not run in places where this will be the legal framework? How is that field limits your freedom?
The systemd service manager does not have an installer, systemd-sysinstall is a separate tool that's part of the systemd project.
> systemd already integrated it, why (age verification)
systemd has not integrated age verification. All that's been discussed is a simple field to allow a user to register a DoB and an way for services to validate the user is over a certain age.
You could arguably already do this by having a DoB field for the user, but that'd involve giving applications your full DoB which I'm sure is distasteful for many.
> usual "fight" against non-sense laws
Because developers have to follow laws like everyone else?
Do you want the developers to ignore the law and in the case of companies like Red Hat etc be vulnerable to law suits?
They are obeying some by violating some others. In this case I'd personally do nothing.
In the case of a company there’s even less at risk, and a lot of good will to be farmed.
Pretending there's nothing to done is just an excuse to do nothing
Regardless of the face you put on the presidency, we are always going to have to fight for privacy and freedom at the grassroots level.
Fortunately, economic decline has brought with it a decline in state capacity, which does bring new problems, but enforcement is becoming an issue across the board. That’s a form of freedom, even if it sucks to deal with stuff like petty crime on a daily basis.
Which country/state/region? Does it even apply? We're talking about an open source project that is not being sold, with contributors from all over the world.
It doesn't matter it's an open source project, ultimately it ends up in commercial products which do require following the rules.