10 ms·

Replacing Systemd with OpenRC in Debian

63 points by nogajun 3mo ago

atmanactive 3mo ago
I'm confused... isn't Devuan exactly this?
- _flux 3mo ago
  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 3mo ago
    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 3mo ago
      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 3mo ago
        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 3mo ago
        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 3mo ago
        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 3mo ago
        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 3mo ago
        > 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. [0] <https://news.ycombinator.com/item?id=48717056 https://news.ycombinator.com/item?id=48717056>
        JdeBP 3mo ago
        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. * https://jdebp.uk/Softwares/nosh/guide/commands/convert-systemd-units.xml https://jdebp.uk/Softwares/nosh/guide/commands/convert-syste... * https://jdebp.uk/Softwares/nosh/guide/converting-systemd-units.html https://jdebp.uk/Softwares/nosh/guide/converting-systemd-uni... * https://jdebp.uk/Softwares/nosh/debian-binary-packages.html https://jdebp.uk/Softwares/nosh/debian-binary-packages.html
- shevy-java 3mo ago
  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_gentoo_go_this_way_too_soon_linux_from/ https://old.reddit.com/r/Gentoo/comments/1qy4xsc/might_gento... and https://www.phoronix.com/news/LFS-Dropping-SysVinit https://www.phoronix.com/news/LFS-Dropping-SysVinit)
  - muvlon 3mo ago
    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 3mo ago
    Debian is an OS, not a kit to build an OS using lots of different components.
pydry 3mo ago
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 3mo ago
  where is it janky?
  - youre-wrong3 3mo ago
    His imagination.
  - shakna 3mo ago
    The output devices (/dev/stdXXX) being sockets-only constantly trip people up.
- egorfine 3mo ago
  > systemd desperately needs competition Maybe it's too late. LP is cooking a way to deny system modifications [1] [1] https://news.ycombinator.com/item?id=46784572 https://news.ycombinator.com/item?id=46784572
- matheusmoreira 3mo ago
  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 3mo ago
  GNU Shepherd maybe?
- nubinetwork 3mo ago
  Try porting svcs from Solaris to Linux...
- 3mo ago
globular-toast 3mo ago
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 3mo ago
  Because if you dare criticise or say "I encountered a bug" the mob will get you.
  - simoncion 3mo ago
    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] [2] <https://news.ycombinator.com/item?id=48716382 https://news.ycombinator.com/item?id=48716382>
- simoncion 3mo ago
  > 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...
mid-kid 3mo ago
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 3mo ago
  Can't these features be toggled?
  - mort96 3mo ago
    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 3mo ago
      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? See: https://www.amutable.com https://www.amutable.com
      - gatlin 3mo ago
        Lennart Poettering will not rest until all software is completely unusable.
lousken 3mo ago
Just install devuan?
- pwdisswordfishq 3mo ago
  This devuan? https://lwn.net/Articles/786593/ https://lwn.net/Articles/786593/
  - LetMeLogin 3mo ago
    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 3mo ago
  That was my initial thought.
mkesper 3mo ago
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 3mo ago
  I've never *ever* broken a production system by reconfiguring a sysvinit service, at all, no no no, not me...
  - LetMeLogin 3mo ago
    Absolutely not!
  - adrian_b 3mo ago
    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 3mo ago
  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.
ErroneousBosh 3mo ago
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.
- shevy-java 3mo ago
  How about age sniffing though? :) https://github.com/systemd/systemd/pull/40954 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.
  - gf000 3mo ago
    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 3mo ago
      You can just ignore them. What are they going to do about it?
  - ErroneousBosh 3mo ago
    You can just compile it without that.
ChocolateGod 3mo ago
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 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?
- wink 3mo ago
  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 3mo ago
    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.
    - LtWorf 3mo ago
      The commercial products can patch it then if they so wish.
      - ChocolateGod 3mo ago
        The field does nothing when left untouched, which it is by default. If having the ability to set a piece of metadata worries you, don't set it.
shevy-java 3mo ago
The article makes one key mistake, in that it compares systemd to openrc. Aka some monster-system with billion features, to a fairly small system that juts relates to initializing a few things. The whole debate about systemd has always been very dishonest from the systemd devs. If you have 3 million lines of code, for instance, and offer 5000 features, just to give out semi-random numbers, then every alternative with, say, 100.000 lines of code and only 50 features, will lose out by definition. Systemd has NEVER been solely or primarily been an "init" system. People need to stop buying the propaganda 1:1. That includes self-promo. It is the same with age sniffing; some still believe it is about protecting kids. Then they were flabbergasted when governments - who suspiciously smell like corporate-controlled governments by the way, in particular in the UK - declare total war against VPNs. The excuse they use is not convincing at all, IF you buy into the assumption that this is about kids (which it is not). On the other hand, when systemd decided to support age sniffing (https://github.com/systemd/systemd/pull/40954 https://github.com/systemd/systemd/pull/40954), I guess they went a step too far. People who weren't against systemd, look at it differently now. After all why is Poettering so defensive about systemd supporting age sniffing? All that tasty data that is to be amassed. Some private entities love that data. You have become the product. As for "alternatives" to systemd, which is a misnomer IMO: I found that all the alternatives are pretty bad too. The best option is to try to stay as lean as possible without losing things that are objectively useful. Any init system that depends on shell scripts, already is a failure by design. (Systemd's unit files are also a failure; and the lack of transparency too. It is like the ultimate trojan horse.)
- master-lincoln 3mo ago
  > The whole debate about systemd has always been very dishonest from the systemd devs. What did they debate? What about it was dishonest? > If you have 3 million lines of code, for instance, and offer 5000 features, just to give out semi-random numbers, then every alternative with, say, 100.000 lines of code and only 50 features, will lose out by definition. Why? Just because average lines of code per feature are by a factor of 5 or so lower for systemd in your example? What is the definition they will lose out on? Also unclear to me what you are referring to with 5000 feature to generate random numbers... > It is the same with age sniffing; some still believe it is about protecting kids. Then they were flabbergasted when governments - who suspiciously smell like corporate-controlled governments by the way, in particular in the UK - declare total war against VPNs. The excuse they use is not convincing at all, IF you buy into the assumption that this is about kids (which it is not). What about it is sniffing if a person voluntarily enters that data to be shared with a service so they can use it? What is it about then if not kids? It sounds like you think all governments who think about enforcing age restrictions online have some shared hidden agenda. > On the other hand, when systemd decided to support age sniffing (https://github.com/systemd/systemd/pull/40954 https://github.com/systemd/systemd/pull/40954), I guess they went a step too far. People who weren't against systemd, look at it differently now. After all why is Poettering so defensive about systemd supporting age sniffing? All that tasty data that is to be amassed. Some private entities love that data. You have become the product. It's linux, you can disable it or not enter your date. Alternative would have been that you are not able to use certain online services in those strict jurisdictions or that any tool that wants to support these services comes with their own implementation. > As for "alternatives" to systemd, which is a misnomer IMO Why? It's a daemon (and more) managing your system. > Systemd's unit files are also a failure; and the lack of transparency too. Why are they a failure? Which lack of transparency?
INTPenis 3mo ago
Systemd resistance is silly to me. Systemd is what is turning Linux into a viable modern OS. You need something to tie all the parts of the OS together with a unified API, otherwise you'll be fighting fragmentation constantly. I don't like the age verification thing either, but all systemd did was add a field for it, it's still up to your distro to use it.
- wolvoleo 3mo ago
  Fragmentation is what makes Linux great imo. I'm not against systemd per se but I am against monoculture.
  - lukan 3mo ago
    And what are your thoughts on deploying software to a fragmented system?
    - wolvoleo 3mo ago
      Just like it's done now, every distro having their own system. It containerization for people who like that. What I have an issue with is apps making themselves dependent on systemd like KDE is doing. https://www.reddit.com/r/kde/comments/1qi9vo5/comment/o0pzvqc/ https://www.reddit.com/r/kde/comments/1qi9vo5/comment/o0pzvq...
      - tuna74 3mo ago
        KDE is not an app, it is a fully blown DE.
    - prmoustache 3mo ago
      You define the supported target and that's it. RHEL and Ubuntu LTS, kubernetes, docker/podman or flatpak are popular ones.
    - graemep 3mo ago
      Systemd does not solve the deployment problem, and will not unless it adds something like a systemd package manager. It is interesting that Linux is far more widely used than alternatives that are not fragmented (e.g. FreeBSD) and has not standardised on one distro. Different people have different needs and preferences. People using Debian, Alpine, and NixOS are unlikely to agree on what they want.
HackerThemAll 3mo ago
Not long in the future we'll have "Systemd Linux".
- gf000 3mo ago
  We basically have it already. And we are all better off for it with software actually working as intended, without maintainers having to make heroic efforts of porting programs.
- wewewedxfgdf 3mo ago
  It can reasonably be argued that Systemd is a very substantial chunk of what the operating system actually is. The kernel has a very focused job to do. The hard work of running the show on top of the kernel - and it's a big job - is done by Systemd. And it's awesome I love Systemd. If you dislike Systemde I can only imagine you haven't really taken the time to learn it and use it properly.
  - adrian_b 3mo ago
    I have seen a lot of Systemd presentations, for much more than a decade. None of them has included even the slightest reason why I would want to use it, and on my computers, desktops, laptops, mini-PCs and servers, I have run only Linux or FreeBSD since about 23 years ago, when I have reformatted my last HDD containing a Windows installation, so I have a lot of experience with Linux. One time, already a few years after Systemd had become mainstream and it was supposed that its early bugs had been fixed, I have tried to use Systemd for a month, thinking that the criticisms that I had heard about Systemd might have been exaggerated. However, I encountered then a bug myself, which was severe enough to convince me that I cannot trust the Systemd developers, so I never used it again.
jdw64 3mo ago
I mainly use Ubuntu, so I know about systemd, but what is OpenRC? Why is there such a split, and why are people arguing about it in the comments? Could someone kindly explain it to me? I only know how to control Linux through systemctl, and I don't know much beyond that. It seems like the components are different, but I'd appreciate it if someone could explain it to me.
- deleted 3mo ago
  [deleted]
- opem 3mo ago
  why don't you try searching on the internet?
  - jdw64 3mo ago
    I gooogled it, but I still don't really understand why there's a debate. Because OpenRC and systemd don't even seem like comparable things—OpenRC is much smaller. And from what Google shows me, one is written in C and the other is script-based. So one is a lightweight service manager, and the other is a framework that manages the entire OS. I'm a Windows enviroment developer, so I don't really know, but they seem to have different roles. Yet there's still a debate, and I don't get it. Is this really just an argument about PID 1?
    - graemep 3mo ago
      Its an argument about whether you want an init that is just an init, or an init that is designed as an extra layer of the OS. If they were comparable (i.e. if systemd was just an init system) there would be no debate. it does not help that the systemd devs are obnoxious and dismissive of concerns about compatibility. Lots of "its your problem" in their bug tracker on github.
      - jdw64 3mo ago
        Thanks to your summary, I finally understand. So it's about whether it's a small tool that only handles init, or whether it handles multiple layers. That's the issue. Thank you. I didn't know why there was a debate since the size difference between them is quite significant. so I don't know much about the Linux side. Have a good day.
hks0 3mo ago
I have a curious question. My local setup has worked for me for ages ever since arch decided to switch to systemd. Same on the servers I deal with, after Debian's switch. At the same time, I can say I'm not involved with inner workings of a Linux system enough, to be affected by init system change and the pain it might bring. In other means consider me an average Joe of the Linux world. Hence this question: If it sucks so much, why did it become so widespread?
- gf000 3mo ago
  It doesn't suck, people are just emotional beings and have some "football team" level takes on technical stuff as well. The very same people that hate systemd for "being a monolith" and limiting choice are usually also love X and hate Wayland where they can manage to explain how being a monolith is suddenly good. Especially that systemd is pretty modular - at least the actual systemd program running as PID 1. It also refers to a project with many optional modules running under the same name, but that's like KDE having a file manager and complaining that plasma DE is a monolith.
  - graemep 3mo ago
    That is a straw man. Plenty of people have different opinions on different issues. > but that's like KDE having a file manager and complaining that plasma DE is a monolith On the other hand it would be very rare to use Plasma without the KDE file manger. You lose all sorts of integration. Similarly, once you use systemd init its going to be a lot easier to replace everything else with the systemd equivalent.
  - nubinetwork 3mo ago
    Both systemd and wayland were quite broken when they were first being pushed onto everyone... they're mostly fine now.
    - gf000 3mo ago
      It's the bazaar. No one is pushing anything on you, you have a wrong mental model if you think anything can be pushed.
0dayz 3mo ago
To this day I have not found a single modern argument against systemd that is a technical one (I tried systemd but it does not support x which openrc does), instead it's these vague bike shed arguments (Unix philosophy, anti-centralization and "bloat" ). I can't wrap my head around it, since those 3 are a "you" problem, systemd is just a service manager it's you who decide to use other systemd parts.
- LtWorf 3mo ago
  I found a few bugs where journald was losing data for example. I reported them and they got fixed in later releases. Of course I still got called a neckbeard and got told that I didn't like systemd because I'm a dinosaur and so on. So I have a really hard time to take positions such as your seriously to be honest.
  - 0dayz 3mo ago
    If you mean that there are times systemd has a critical bug; sure the same way x11, kernel modules or drivers have critical bugs are annoying. You can always point to where I said you are a neckbeard, so I do not get the "hard time" angle. You can not like systemd, but the arguments for it is silly, and that is fine it's your machine and I don't care as long as people stop spreading FUD on such awful grounds. Say in contrast with BTRFS or BcacheFS there are genuine issues with those and there are technical philosophical arguments (I want journaling, I do not want or need CoW features, snapshot? never heard of her).
    - LtWorf 3mo ago
      You are precisely part of the mob I was describing. Perhaps you did not say exactly word by word "neckbeard" but you are dismissing all the arguments as FUD. As I said, when distributions were already using systemd by default I installed it and tried it for one hour and found 3 different ways it was losing data sent to journald. According to you when a logging daemon loses log entries, stating that it's not ready for real use is FUD. Funny how you think of yourself as being the reasonable one here :)
unsungNovelty 3mo ago
Alpine Linux and Void are the only mainstream enough distro I can think of as an interest for my planB. But I wonder how good Alpine is for desktop computing and development stuff. I know they have recently started shipping full DEs for desktop IIRC. Anyone with any experiences?
- yjftsjthsd-h 3mo ago
  > Alpine Linux and Void are the only mainstream enough distro I can think of as an interest for my planB. Consider Gentoo as well? They have decent binary package availability now which reduces the compilation needed. > But I wonder how good Alpine is for desktop computing and development stuff. I know they have recently started shipping full DEs for desktop IIRC. How do you mean? You can install whatever graphical system you want on Alpine. I've got Alpine boxes running i3 and KDE, which seems like the full spectrum. > Anyone with any experiences? Alpine is great. I've run it on desktops, laptops, headless, and a Steam Deck and it's been mostly a good time. As you kinda allude to, it really shines on underpowered machines by being so light.
  - unsungNovelty 3mo ago
    >How do you mean? Alpine was more for container environment right? So I was wondering how it has been for normal usage and apps. Especially with MUSL etc
    - yjftsjthsd-h 3mo ago
      IIRC Alpine was originally built largely for embedded networking gear, then because of its small size came to be favored in container images (where smaller images are a selling point), but it's a general purpose distro and I've had a good time daily-driving it on laptops. If apps/musl are a problem you can just install flatpak, but off the top of my head I've only needed that for Steam and non-firefox browsers (but `apk add firefox` works fine). Actually, a funny thing is that I used to daily-drive Void, and I do remember having more problems there because of musl. But I think that may have been mostly a chromium or webkit problem with... something about how Void+musl did memory allocations? I forget. Anyways, I'm pretty sure even that would be fixed with firefox or flatpak so w/e.
eqvinox 3mo ago
For people interested in "less systemd" there's also the gardenhouse bits at https://git.pinkro.se/ https://git.pinkro.se/
Someone 3mo ago
FTA: “Before deleting systemd, need to be sure that OpenRC will be installed, to so the command will be sudo apt purge --allow-remove-essential systemd && sudo apt install openrc sysvinit-core ” I don’t see that installing openrc before deleting systemd. It tries to delete systemd and, if that fully succeeds, to install openrc. > Issue itself was that while uninstalling systemd somehow OpenRC was removed too or not installed at all. I don’t see how “somehow OpenRC was removed” could be true if it wasn’t installed before. My hunch would be that uninstalling systemd failed halfway through.
valentynkit 3mo ago
Curious how you're handling supervision after the switch. The remoteproc unit you converted by hand is the part that gets interesting: when it crashes, what restarts it, and what guarantees it came up only after its dependencies were actually ready rather than just launched? That dependency ordering and the cgroup resource accounting are the real work, and OpenRC hands both back to you.
- simoncion 3mo ago
  > Curious how you're handling supervision after the switch. In the service file, you put this supervisor=supervise-daemon and either ensure the program you're running as a service doesn't daemonize, or make use of 'command_args_background=' and 'command_args_foreground=' if you want to be able to swap between supervised and unsupervised use. > That dependency ordering [is on you to manually manage]... Nope. OpenRC has had dependency ordering for the quarter-century I've been using it. [0] It's a core feature, so it's probably had it for forever. > ...and the cgroup resource accounting are the real work, and OpenRC hands both back to you. Nope. [1][2] [0] <https://github.com/OpenRC/openrc/blob/29f620c16036586c39ec17af5d0838a2b1296771/service-script-guide.md?plain=1#L65 https://github.com/OpenRC/openrc/blob/29f620c16036586c39ec17...> [1] <https://github.com/OpenRC/openrc/blob/29f620c16036586c39ec17af5d0838a2b1296771/user-guide.md?plain=1#L133 https://github.com/OpenRC/openrc/blob/29f620c16036586c39ec17...> [2] <https://github.com/OpenRC/openrc/blob/29f620c16036586c39ec17af5d0838a2b1296771/etc/rc.conf#L200 https://github.com/OpenRC/openrc/blob/29f620c16036586c39ec17...>
taris2 3mo ago
[flagged]
jmclnx 3mo ago
> Currently OpenRC does the work. That is a shame, but I wonder if you tried this with devuan you may have better luck ? https://www.devuan.org/ https://www.devuan.org/

63 points by nogajun 3mo ago

atmanactive 3mo ago

I'm confused... isn't Devuan exactly this?

_flux 3mo ago
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 3mo ago
  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 3mo ago
    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 3mo ago
      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 3mo ago
        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 3mo ago
        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 3mo ago
        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 3mo ago
        > 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. [0] <https://news.ycombinator.com/item?id=48717056 https://news.ycombinator.com/item?id=48717056>
        JdeBP 3mo ago
        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. * https://jdebp.uk/Softwares/nosh/guide/commands/convert-systemd-units.xml https://jdebp.uk/Softwares/nosh/guide/commands/convert-syste... * https://jdebp.uk/Softwares/nosh/guide/converting-systemd-units.html https://jdebp.uk/Softwares/nosh/guide/converting-systemd-uni... * https://jdebp.uk/Softwares/nosh/debian-binary-packages.html https://jdebp.uk/Softwares/nosh/debian-binary-packages.html
shevy-java 3mo ago
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_gentoo_go_this_way_too_soon_linux_from/ https://old.reddit.com/r/Gentoo/comments/1qy4xsc/might_gento... and https://www.phoronix.com/news/LFS-Dropping-SysVinit https://www.phoronix.com/news/LFS-Dropping-SysVinit)
- muvlon 3mo ago
  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 3mo ago
  Debian is an OS, not a kit to build an OS using lots of different components.

pydry 3mo ago

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 3mo ago
where is it janky?
- youre-wrong3 3mo ago
  His imagination.
- shakna 3mo ago
  The output devices (/dev/stdXXX) being sockets-only constantly trip people up.
egorfine 3mo ago
> systemd desperately needs competition Maybe it's too late. LP is cooking a way to deny system modifications [1] [1] https://news.ycombinator.com/item?id=46784572 https://news.ycombinator.com/item?id=46784572
matheusmoreira 3mo ago
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 3mo ago
GNU Shepherd maybe?
nubinetwork 3mo ago
Try porting svcs from Solaris to Linux...
3mo ago

globular-toast 3mo ago

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 3mo ago
Because if you dare criticise or say "I encountered a bug" the mob will get you.
- simoncion 3mo ago
  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] [2] <https://news.ycombinator.com/item?id=48716382 https://news.ycombinator.com/item?id=48716382>
simoncion 3mo ago
> 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...

mid-kid 3mo ago

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 3mo ago
Can't these features be toggled?
- mort96 3mo ago
  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 3mo ago
    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? See: https://www.amutable.com https://www.amutable.com
    - gatlin 3mo ago
      Lennart Poettering will not rest until all software is completely unusable.

lousken 3mo ago

Just install devuan?

pwdisswordfishq 3mo ago
This devuan? https://lwn.net/Articles/786593/ https://lwn.net/Articles/786593/
- LetMeLogin 3mo ago
  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 3mo ago
That was my initial thought.

mkesper 3mo ago

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 3mo ago
I've never *ever* broken a production system by reconfiguring a sysvinit service, at all, no no no, not me...
- LetMeLogin 3mo ago
  Absolutely not!
- adrian_b 3mo ago
  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 3mo ago
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.

ErroneousBosh 3mo ago

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.

shevy-java 3mo ago
How about age sniffing though? :) https://github.com/systemd/systemd/pull/40954 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.
- gf000 3mo ago
  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 3mo ago
    You can just ignore them. What are they going to do about it?
- ErroneousBosh 3mo ago
  You can just compile it without that.

ChocolateGod 3mo ago

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 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?

wink 3mo ago
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 3mo ago
  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.
  - LtWorf 3mo ago
    The commercial products can patch it then if they so wish.
    - ChocolateGod 3mo ago
      The field does nothing when left untouched, which it is by default. If having the ability to set a piece of metadata worries you, don't set it.

shevy-java 3mo ago

The article makes one key mistake, in that it compares systemd to openrc. Aka some monster-system with billion features, to a fairly small system that juts relates to initializing a few things. The whole debate about systemd has always been very dishonest from the systemd devs. If you have 3 million lines of code, for instance, and offer 5000 features, just to give out semi-random numbers, then every alternative with, say, 100.000 lines of code and only 50 features, will lose out by definition. Systemd has NEVER been solely or primarily been an "init" system. People need to stop buying the propaganda 1:1. That includes self-promo. It is the same with age sniffing; some still believe it is about protecting kids. Then they were flabbergasted when governments - who suspiciously smell like corporate-controlled governments by the way, in particular in the UK - declare total war against VPNs. The excuse they use is not convincing at all, IF you buy into the assumption that this is about kids (which it is not). On the other hand, when systemd decided to support age sniffing (https://github.com/systemd/systemd/pull/40954 https://github.com/systemd/systemd/pull/40954), I guess they went a step too far. People who weren't against systemd, look at it differently now. After all why is Poettering so defensive about systemd supporting age sniffing? All that tasty data that is to be amassed. Some private entities love that data. You have become the product. As for "alternatives" to systemd, which is a misnomer IMO: I found that all the alternatives are pretty bad too. The best option is to try to stay as lean as possible without losing things that are objectively useful. Any init system that depends on shell scripts, already is a failure by design. (Systemd's unit files are also a failure; and the lack of transparency too. It is like the ultimate trojan horse.)

master-lincoln 3mo ago
> The whole debate about systemd has always been very dishonest from the systemd devs. What did they debate? What about it was dishonest? > If you have 3 million lines of code, for instance, and offer 5000 features, just to give out semi-random numbers, then every alternative with, say, 100.000 lines of code and only 50 features, will lose out by definition. Why? Just because average lines of code per feature are by a factor of 5 or so lower for systemd in your example? What is the definition they will lose out on? Also unclear to me what you are referring to with 5000 feature to generate random numbers... > It is the same with age sniffing; some still believe it is about protecting kids. Then they were flabbergasted when governments - who suspiciously smell like corporate-controlled governments by the way, in particular in the UK - declare total war against VPNs. The excuse they use is not convincing at all, IF you buy into the assumption that this is about kids (which it is not). What about it is sniffing if a person voluntarily enters that data to be shared with a service so they can use it? What is it about then if not kids? It sounds like you think all governments who think about enforcing age restrictions online have some shared hidden agenda. > On the other hand, when systemd decided to support age sniffing (https://github.com/systemd/systemd/pull/40954 https://github.com/systemd/systemd/pull/40954), I guess they went a step too far. People who weren't against systemd, look at it differently now. After all why is Poettering so defensive about systemd supporting age sniffing? All that tasty data that is to be amassed. Some private entities love that data. You have become the product. It's linux, you can disable it or not enter your date. Alternative would have been that you are not able to use certain online services in those strict jurisdictions or that any tool that wants to support these services comes with their own implementation. > As for "alternatives" to systemd, which is a misnomer IMO Why? It's a daemon (and more) managing your system. > Systemd's unit files are also a failure; and the lack of transparency too. Why are they a failure? Which lack of transparency?

INTPenis 3mo ago

Systemd resistance is silly to me. Systemd is what is turning Linux into a viable modern OS. You need something to tie all the parts of the OS together with a unified API, otherwise you'll be fighting fragmentation constantly. I don't like the age verification thing either, but all systemd did was add a field for it, it's still up to your distro to use it.

wolvoleo 3mo ago
Fragmentation is what makes Linux great imo. I'm not against systemd per se but I am against monoculture.
- lukan 3mo ago
  And what are your thoughts on deploying software to a fragmented system?
  - wolvoleo 3mo ago
    Just like it's done now, every distro having their own system. It containerization for people who like that. What I have an issue with is apps making themselves dependent on systemd like KDE is doing. https://www.reddit.com/r/kde/comments/1qi9vo5/comment/o0pzvqc/ https://www.reddit.com/r/kde/comments/1qi9vo5/comment/o0pzvq...
    - tuna74 3mo ago
      KDE is not an app, it is a fully blown DE.
  - prmoustache 3mo ago
    You define the supported target and that's it. RHEL and Ubuntu LTS, kubernetes, docker/podman or flatpak are popular ones.
  - graemep 3mo ago
    Systemd does not solve the deployment problem, and will not unless it adds something like a systemd package manager. It is interesting that Linux is far more widely used than alternatives that are not fragmented (e.g. FreeBSD) and has not standardised on one distro. Different people have different needs and preferences. People using Debian, Alpine, and NixOS are unlikely to agree on what they want.

HackerThemAll 3mo ago

Not long in the future we'll have "Systemd Linux".

gf000 3mo ago
We basically have it already. And we are all better off for it with software actually working as intended, without maintainers having to make heroic efforts of porting programs.
wewewedxfgdf 3mo ago
It can reasonably be argued that Systemd is a very substantial chunk of what the operating system actually is. The kernel has a very focused job to do. The hard work of running the show on top of the kernel - and it's a big job - is done by Systemd. And it's awesome I love Systemd. If you dislike Systemde I can only imagine you haven't really taken the time to learn it and use it properly.
- adrian_b 3mo ago
  I have seen a lot of Systemd presentations, for much more than a decade. None of them has included even the slightest reason why I would want to use it, and on my computers, desktops, laptops, mini-PCs and servers, I have run only Linux or FreeBSD since about 23 years ago, when I have reformatted my last HDD containing a Windows installation, so I have a lot of experience with Linux. One time, already a few years after Systemd had become mainstream and it was supposed that its early bugs had been fixed, I have tried to use Systemd for a month, thinking that the criticisms that I had heard about Systemd might have been exaggerated. However, I encountered then a bug myself, which was severe enough to convince me that I cannot trust the Systemd developers, so I never used it again.

jdw64 3mo ago

I mainly use Ubuntu, so I know about systemd, but what is OpenRC? Why is there such a split, and why are people arguing about it in the comments? Could someone kindly explain it to me? I only know how to control Linux through systemctl, and I don't know much beyond that. It seems like the components are different, but I'd appreciate it if someone could explain it to me.

deleted 3mo ago
[deleted]
opem 3mo ago
why don't you try searching on the internet?
- jdw64 3mo ago
  I gooogled it, but I still don't really understand why there's a debate. Because OpenRC and systemd don't even seem like comparable things—OpenRC is much smaller. And from what Google shows me, one is written in C and the other is script-based. So one is a lightweight service manager, and the other is a framework that manages the entire OS. I'm a Windows enviroment developer, so I don't really know, but they seem to have different roles. Yet there's still a debate, and I don't get it. Is this really just an argument about PID 1?
  - graemep 3mo ago
    Its an argument about whether you want an init that is just an init, or an init that is designed as an extra layer of the OS. If they were comparable (i.e. if systemd was just an init system) there would be no debate. it does not help that the systemd devs are obnoxious and dismissive of concerns about compatibility. Lots of "its your problem" in their bug tracker on github.
    - jdw64 3mo ago
      Thanks to your summary, I finally understand. So it's about whether it's a small tool that only handles init, or whether it handles multiple layers. That's the issue. Thank you. I didn't know why there was a debate since the size difference between them is quite significant. so I don't know much about the Linux side. Have a good day.

hks0 3mo ago

I have a curious question. My local setup has worked for me for ages ever since arch decided to switch to systemd. Same on the servers I deal with, after Debian's switch. At the same time, I can say I'm not involved with inner workings of a Linux system enough, to be affected by init system change and the pain it might bring. In other means consider me an average Joe of the Linux world. Hence this question: If it sucks so much, why did it become so widespread?

gf000 3mo ago
It doesn't suck, people are just emotional beings and have some "football team" level takes on technical stuff as well. The very same people that hate systemd for "being a monolith" and limiting choice are usually also love X and hate Wayland where they can manage to explain how being a monolith is suddenly good. Especially that systemd is pretty modular - at least the actual systemd program running as PID 1. It also refers to a project with many optional modules running under the same name, but that's like KDE having a file manager and complaining that plasma DE is a monolith.
- graemep 3mo ago
  That is a straw man. Plenty of people have different opinions on different issues. > but that's like KDE having a file manager and complaining that plasma DE is a monolith On the other hand it would be very rare to use Plasma without the KDE file manger. You lose all sorts of integration. Similarly, once you use systemd init its going to be a lot easier to replace everything else with the systemd equivalent.
- nubinetwork 3mo ago
  Both systemd and wayland were quite broken when they were first being pushed onto everyone... they're mostly fine now.
  - gf000 3mo ago
    It's the bazaar. No one is pushing anything on you, you have a wrong mental model if you think anything can be pushed.

0dayz 3mo ago

To this day I have not found a single modern argument against systemd that is a technical one (I tried systemd but it does not support x which openrc does), instead it's these vague bike shed arguments (Unix philosophy, anti-centralization and "bloat" ). I can't wrap my head around it, since those 3 are a "you" problem, systemd is just a service manager it's you who decide to use other systemd parts.

LtWorf 3mo ago
I found a few bugs where journald was losing data for example. I reported them and they got fixed in later releases. Of course I still got called a neckbeard and got told that I didn't like systemd because I'm a dinosaur and so on. So I have a really hard time to take positions such as your seriously to be honest.
- 0dayz 3mo ago
  If you mean that there are times systemd has a critical bug; sure the same way x11, kernel modules or drivers have critical bugs are annoying. You can always point to where I said you are a neckbeard, so I do not get the "hard time" angle. You can not like systemd, but the arguments for it is silly, and that is fine it's your machine and I don't care as long as people stop spreading FUD on such awful grounds. Say in contrast with BTRFS or BcacheFS there are genuine issues with those and there are technical philosophical arguments (I want journaling, I do not want or need CoW features, snapshot? never heard of her).
  - LtWorf 3mo ago
    You are precisely part of the mob I was describing. Perhaps you did not say exactly word by word "neckbeard" but you are dismissing all the arguments as FUD. As I said, when distributions were already using systemd by default I installed it and tried it for one hour and found 3 different ways it was losing data sent to journald. According to you when a logging daemon loses log entries, stating that it's not ready for real use is FUD. Funny how you think of yourself as being the reasonable one here :)

unsungNovelty 3mo ago

Alpine Linux and Void are the only mainstream enough distro I can think of as an interest for my planB. But I wonder how good Alpine is for desktop computing and development stuff. I know they have recently started shipping full DEs for desktop IIRC. Anyone with any experiences?

yjftsjthsd-h 3mo ago
> Alpine Linux and Void are the only mainstream enough distro I can think of as an interest for my planB. Consider Gentoo as well? They have decent binary package availability now which reduces the compilation needed. > But I wonder how good Alpine is for desktop computing and development stuff. I know they have recently started shipping full DEs for desktop IIRC. How do you mean? You can install whatever graphical system you want on Alpine. I've got Alpine boxes running i3 and KDE, which seems like the full spectrum. > Anyone with any experiences? Alpine is great. I've run it on desktops, laptops, headless, and a Steam Deck and it's been mostly a good time. As you kinda allude to, it really shines on underpowered machines by being so light.
- unsungNovelty 3mo ago
  >How do you mean? Alpine was more for container environment right? So I was wondering how it has been for normal usage and apps. Especially with MUSL etc
  - yjftsjthsd-h 3mo ago
    IIRC Alpine was originally built largely for embedded networking gear, then because of its small size came to be favored in container images (where smaller images are a selling point), but it's a general purpose distro and I've had a good time daily-driving it on laptops. If apps/musl are a problem you can just install flatpak, but off the top of my head I've only needed that for Steam and non-firefox browsers (but `apk add firefox` works fine). Actually, a funny thing is that I used to daily-drive Void, and I do remember having more problems there because of musl. But I think that may have been mostly a chromium or webkit problem with... something about how Void+musl did memory allocations? I forget. Anyways, I'm pretty sure even that would be fixed with firefox or flatpak so w/e.

eqvinox 3mo ago

For people interested in "less systemd" there's also the gardenhouse bits at https://git.pinkro.se/ https://git.pinkro.se/

Someone 3mo ago

FTA: “Before deleting systemd, need to be sure that OpenRC will be installed, to so the command will be sudo apt purge --allow-remove-essential systemd && sudo apt install openrc sysvinit-core ” I don’t see that installing openrc before deleting systemd. It tries to delete systemd and, if that fully succeeds, to install openrc. > Issue itself was that while uninstalling systemd somehow OpenRC was removed too or not installed at all. I don’t see how “somehow OpenRC was removed” could be true if it wasn’t installed before. My hunch would be that uninstalling systemd failed halfway through.

valentynkit 3mo ago

Curious how you're handling supervision after the switch. The remoteproc unit you converted by hand is the part that gets interesting: when it crashes, what restarts it, and what guarantees it came up only after its dependencies were actually ready rather than just launched? That dependency ordering and the cgroup resource accounting are the real work, and OpenRC hands both back to you.

simoncion 3mo ago
> Curious how you're handling supervision after the switch. In the service file, you put this supervisor=supervise-daemon and either ensure the program you're running as a service doesn't daemonize, or make use of 'command_args_background=' and 'command_args_foreground=' if you want to be able to swap between supervised and unsupervised use. > That dependency ordering [is on you to manually manage]... Nope. OpenRC has had dependency ordering for the quarter-century I've been using it. [0] It's a core feature, so it's probably had it for forever. > ...and the cgroup resource accounting are the real work, and OpenRC hands both back to you. Nope. [1][2] [0] <https://github.com/OpenRC/openrc/blob/29f620c16036586c39ec17af5d0838a2b1296771/service-script-guide.md?plain=1#L65 https://github.com/OpenRC/openrc/blob/29f620c16036586c39ec17...> [1] <https://github.com/OpenRC/openrc/blob/29f620c16036586c39ec17af5d0838a2b1296771/user-guide.md?plain=1#L133 https://github.com/OpenRC/openrc/blob/29f620c16036586c39ec17...> [2] <https://github.com/OpenRC/openrc/blob/29f620c16036586c39ec17af5d0838a2b1296771/etc/rc.conf#L200 https://github.com/OpenRC/openrc/blob/29f620c16036586c39ec17...>

taris2 3mo ago

[flagged]

jmclnx 3mo ago

> Currently OpenRC does the work. That is a shame, but I wonder if you tried this with devuan you may have better luck ? https://www.devuan.org/ https://www.devuan.org/