So,
I’ve never bothered with this before, since systemD seems to work just fine.
But I did this year stop using Ubuntu for most of my hosting needs and moved to Alpine or Debian, depending on what I’m doing.
So it makes sense to optimize even more. I read up a little about why people dislike systemD. Good reasons if mainly you’re worried that it’s doing too much and is too heavy.
So what are the alternatives that work with both Alpine and Debian? What are people using? Is it relatively easy to move from systemD to whatever is your alternative?
Thanks!
You must log in or register to comment.
Openrc is used by alpine and gentoo. They both work great.
Runit used by void is also fine.
If you can figure out gentoo it’s not a bad OS but compiling can be slow. You’ll learn a lot though. Checkout oddlama/gentoo-installer
So what are the alternatives that work with both Alpine and Debian?
My opinion is that you’d be better off sticking to the OOTB init system that these distros provide, and hop to an entirely different distro that supports the init system you want/need. And for distros that do support multiple, stick to their guides carefully. Would save from a lot of incompat quirks and unsupported bugs, since these things can be as integrated into the main system as the package manager, if not more.
Conceptually though systemd can be a bunch. The s6 dev put out these definitions for the way he conceptually breaks down the entire init/service ecology into small pieces so have a look (ou may be interested in his full post explaining the motivation behind s6/s6-manager too). And since you’re on Alpine, see their plans for a future init system.
With that said you may wanna try out dinit on Chimera Linux. They’re one of the unique distros that offers this and some other cool things
Alpine already uses OpenRC. There’s no option to use systemd with Alpine.
Popular alternatives include runit (which Void uses), OpenRC (Gentoo and Alpine), s6, sysVinit, dinit. The suckless people have also written some suckless inits—I think one of them’s called sinit.
So what are the alternatives that work with both Alpine and Debian?
None. On Alpine you can only use OpenRC and on Debian you can only use systemd. Most distros don’t let you change out the init system. If you want systemdless Debian look into Devuan.
Judging from this post, I would say you should not be looking to change out your init system as, no disrespect intended, but you really don’t seem to know what you’re talking about. You don’t even know what init systems your operating systems (Alpine and Debian) are using, let alone the details of different init systems.
Some people have strong opinions about init systems. They are nerds with reasons behind those opinions. You don’t seem to have many reasons and you don’t seem to be particularly invested in the debate. I would say it’s not worth your time to change operating system (which is what you would need to do to change your init) just because you heard vaguely that systemd is bad. If you reach a point where init system matters to you, then you won’t need to be asking the questions you’re asking in the OP.
None. On Alpine you can only use OpenRC and on Debian you can only use systemd. Most distros don’t let you change out the init system. If you want systemdless Debian look into Devuan.
Fake news. On Debian you can use both sysvinit and openrc (I have six servers on sysvinit, tho I do actually intend to shift them to systemd later mostly because of the container management goodies).
Judging from this post, I would say you should not be looking to change out your init system
Mostly agreeing here. For selfhosting the init system matters barely any, since past the default distro setup one would be doing most of everything with Docker, Podman, etc. At that point, none of the usual Linux religious wars matter much (you can perfectl edit a compose file with nano).
On Debian you can use both sysvinit and openrc
Huh really? Then why does Devuan exist? (I don’t use Debian for context)
I personally would just stick to systemd
It is heavy optimized due to how popular it is. You would save a few megs or ram but not much more.
Why are you searching for a solution to a problem you don’t have?
There’s nothing wrong with systemd.
It’s good to step out of your comfort zone.
Wow.
It’s
- built bad
- … by the uncooperative
- … for the wrong reasons
- incredibly frail
- indivisible
- a logically incomplete and unsound replacement for everything it supplants
- the poster-child for bad ideas pushed into the mainstream with browbeating and gaslighting
I’m no systemd fan, but this is wacky.
Alpine already doesn’t use systemd
I kind of wish it did
I was using it for some VMs but OpenRC is so much worse and slower in many cases.
I use dinit with artix linux(for of arch).
Look out for OpenRC. Using it since forever and never missed systemd.
Plain script files, simple, just works. Unless you need any systemd advanced capabilities, OpenRC just rocks.
System V init scripts
PClinuxOS is a far derivative of redhat via Mandriva, itself Conectiva and Mandrake, both of them RHL (not RHEL) forks.
And it’s free of Systemd. And it’s rolling.
Alpine is an interesting choice for hosting, really curious what situation you’re hosting in that would require that level or lightness for a distro?
I use Alpine for servers because I like its simplicity. Not in terms of computational power requirements, just in terms of user experience.
Alpine is an interesting choice for hosting
I’d say servers are one of the main uses of Alpine, second to containers. It would be a much more unusual choice for a desktop OS.
I kind of very much dislike this line of thinking. Debian and Ubuntu are full of shit and cause an astronomical amount of bloat when containerized or running in production on a server.
I switched to Alpine quite a long time ago and run it on servers, in containers and on my own networking equipment. I don’t miss Debian’s slow as hell updates nor Ubuntu’s Microsoft-style bloat.
I have to deal with all this cruft a lot at work and I always ask myself “why?” It’s super frustrating, it slows everything down and after sprinkling in more “we don’t care about efficiency” attitudes you suddenly find yourself trying to deploy 15GB containers.
We should aim to do better.
that would require that level [of] lightness for a distro
Goal Of Least Fuckery.
I bought a miniPC from AliExpress last year expecting 8GB RAM and Intel N100. The vendor sent an Intel N5095 with 4 GB RAM. I clawed most of my money back, but kept the machine for experimentation. Upped the RAM with the money I got back.
Alpine seems to work best for that machine. Though, I’m tempted to just put Debian on there so I can make docker and portainer agent work on it easily.
Update: Intel 5095, not Intel 50. My bad!
there’s also devuan if you want, debian but with init freedom!
Huh? I don’t think you need anything near as memory efficient as Alpine for something which has 4GB of RAM, unless you’re doing it for the sole purpose of pushing the machine and yourself to the limit.
I only ever consider dropping Debian and/or Systemd when going below 512MB RAM. I’ve run most of my public-facing homelab stuff on a 1GB VPS till recently, including multiple webservers such as FoundryVTT, and Docker containers such as a Wireguard server, Jenkins, Searxng, etc… It rarely used more than ~60% of the RAM, but I obviously couldn’t run Immich or any heavy services on it.
Alpine is a fair amount lighter in memory consumption than Debian.
Is it? I thought the thing that musl optimized for was disk usage, not memory usage or CPU time. It’s been my experience that alpine containers are worse than their glibc counterparts because glibc is damn good. It’s definitely faster in many cases. I think this is fixed now, but I remember when musl made the python interpreter run like 50-100x slower.
EDIT: musl is good at what it tries to be good at. It’s not trying to be the fastest, it’s trying to be small on disk or over the network.
Glibc matters on desktop, but the speed advantage doesn’t really matter to services running in cgroup2 containers borrowing the host’s kernel and namespaces.
For op’s purposes, memory density is important, and alpine base images will need about 10x less memory than their Debian counterparts, mostly due to a very pared-down service layout.
There’s a reason a huge portion of docker images are alpine-based.
Do you have any sources for the 10x memory thing? I’ve seen people who have made memory usage claims, but I haven’t seen benchmarks demonstrating this.
EDIT: glibc-based images wouldn’t be using service managers either. PID 1 is your application.
EDIT: In response to this:
There’s a reason a huge portion of docker images are alpine-based.
After months of research, my company pushed thousands and thousands of containers away from alpine for operational and performance reasons. You can get small images using glibc-based distros. Just look at chainguard if you want an example. We saved money (many many dollars a month) and had fewer tickets once we finished banning alpine containers. I haven’t seen a compelling reason to switch back, and I just don’t see much to recommend Alpine outside of embedded systems where disk space is actually a problem. I’m not going to tell you that you’re wrong for using it, but my experience has basically been a series of events telling me to avoid it. Also, I fucking hate the person that decided it wasn’t going to do search domains properly or DNS over TCP.
That is incus. But similar in other implementations of LXC. Docker has similar ratios, but I suspect you know this already.
Also, I fucking hate the person that decided it wasn’t going to do search domains properly or DNS over TCP.
That has been fixed since 3.18.
Look, I’m not sure why you’re challenging me so hard on this, I’m not a superfan of Alpine or anything. I use it when I can because it’s really, really light on memory and so do others. There are lots of cases that don’t work with Alpine, like mongodb, sql, etc. But there are lots of great uses for alpine as well, like networking or anything that works well with busybox tooling.
Have a better one.
You make it sound like Debian is obviously superior to Alpine. Alpine Linux is just fine for server tasks. It is nice that is it lightweight, but that isn’t the only thing it has going for it.
Debian is superior for server tasks. musl is designed to optimize for smaller binaries on disk. Memory is a secondary goal, and cpu time is a non-goal. musl isn’t meant to be fast, it’s meant to be small and easily embedded. Those are great things if you need to run in a network/disk constrained environment, but for a server? Why waste CPU cycles using a libc that is, by design, less time efficient?
EDIT: I had to fight this fight at my job. We had hundreds of thousands of Alpine containers running, and switching them to glibc-based containers resulted in quantifiable cloud spend savings. I’m not saying musl (or alpine) is bad, just that you have horses for courses.
I’m not entirely sure how “… don’t need anything near as memory efficient as Alpine” became “Debian is obviously superior to Alpine”.
… I was referencing systemd and familiarity of use in regard to OP. Debian just happened to be mentioned, it comes per default with systemd, and it’s my personal first choice for servers. Though, taking context into account, OP did say they originally came from Ubuntu and made it sound like they were trying to optimize their system since it “only” had 4(8)GB memory in total.
I do believe Debian with systemd is more similar to Ubuntu than Alpine is to Ubuntu. My point was not so much about Debian vs Alpine in general as it was specific to efficiency in regard to memory usage, with the sole reason to change to Alpine over Debian (or any OS which uses systemd, really) purely for memory savings being rather weak when systemd only uses some <50MB in memory, the computer has 4GB+ of it, and the user already is familiar with Debian-based flavors which use systemd.
So no, Debian is obviously not “obviously superior to Alpine”, just as systemd isn’t too heavy to run on computers with 4GB of RAM - unless you’re trying to push the computer to its limits.
You can go with Debian (or Devuan), easily. My home server is running Proxmox on metal (Debian-based itself), virtualized OPNSense, and multiple Debian containers on an i3-4150 and previously 4GB RAM (now mis-matched 10GB).
openRC
It is primarily single threaded
🔥
I’ve used Devuan before with decent success, I run it as a server on an ancient netbook with 1Ghz and 2GB RAM. Works pretty well, but bear in mind so much has become entangled with the expectations of systemd that as more packages get installed you may find things that break. As an example,
aptgets an error every time it does anything because Mullvad VPN software has a configuration step that expects systemd functionality, and obviously that won’t work on Devuan. The program itself works fine, just have to start it a little differently, but it means thataptfunctionality always returns an error, which itself breaks any other scripts you may run that have steps that useapt. I had to do a lot of manual patching for PiHole scripting to get that installed because every time it would run anything with apt it thought there was a showstopping error simply because Mullvad complained during apt configurations.deleted by creator
Devuan is Debian with sysv.
They could have called it DeUwUan and it would have been perfect
22MB is too heavy???
Well S6 is lighter but I wouldn’t recommend it.
Gnu Shepherd is about the same but solid.
You can go much lower than that. I ran systemd on a system with 32mb of ram.
I ran sysvinit on a 4mb daily-driver machine forever. That’s not a flex; that’s just a comparison for bloat since sysvinit wasn’t using but a tiny portion of that. What the hell can lennart’s cancer offer at the cost of at least 5x the ram used by an entire OS and apps?
Well futex based high performance mutex support which is 400x faster than what existed back when 4MB systems were sold. A Constraint solver that doesn’t deadlock, support for a boatload of functionality that didn’t even exist back then.
And most of the size comes from -O3 compiler optimizations that didn’t exist back then and if you build with -Os it is about 512KB of a memory footprint which is smaller than SysV out of the box on Debian. So it is snappy on a 386SX with 4MB of RAM if you go the gentoo route.
People use SystemD because it works better than what came before it and it will be replaced when something actually better shows up. No one happens to have found a generally better solution yet.
OpenRC, Gnu Shepherd, runit and S6 are available for people who like them better but don’t assume that they are generally better for someone else’s use cases until you know what they are.
