From: jj@franjam.org.uk
On 2025-10-12, Ben Collver wrote:
> Half an year on Alpine: just musl aside
>=======================================
And there I was expecting a review of my favorite mail software :-)
>
> 2025-08-31 20:05:26
>
> Warning: Contains tongue-in-cheek language that might feel
> provocative if you have invested part of your identity into your
> software choices. [1]
>
> For roughly six months now, I've been running Alpine on my laptop as
> a daily driver.
>
> Before that, I was running Void. I like how blazing fast Void is to
> start up and shut down, has an excellent package management system
> and its init system, runit, is beautifully integrated. Alpine also
> fits this description.
>
> When I first learned about Void, I read it described itself as
> "rolling but stable", meaning you get new package versions often, but
> not to the point of breakage. While I never had an upgrade break a
> system, it still bothered me to upgrade and suddenly have sound or
> Bluetooth not work anymore, or have the system Python version change
> frequently, leading to all sorts of complaints from this or that
> application I didn't even know was a Python program.
>
> I wanted to go back to a more stable distribution, but I also wanted
> a simpler, faster init system than systemd. Alpine, which has fixed
> releases every six months, eventually rose as an alternative.
>
> Choosing a path forward
>=======================
>
> So, prompted by a charger dying in the beginning of this year, which
> put a machine out of work, I decided to take the opportunity to try
> another system with a slower release cycle and started weighing my
> options.
>
> What remained in the end were Devuan, antiX and Alpine. And I briefly
> tried all three during this experiment before settling on Alpine.
>
> Devuan and antiX do offer options besides SysV-style init, but they
> don't really integrate them very well in their systems. While with
> Void you will really use runit to manage any services installed
> through the distribution's package manager, because when a package
> has a relevant service to ship it will ship a runit service, Devuan
> and antiX have other init systems as options rather than the
> distribution's init system.
>
> What you really get then is a mixture of runit/OpenRC and SysV-style
> init, leaning a lot more towards SysV-style and leveraging the
> runit/OpenRC ability to also run SysV-style init scripts. [2] If you
> like managing SysV-style init, that should not be a problem, although
> in that case you might as well get the SysV-style version then!
> Alpine, on the other hand, just like Void, has OpenRC as the way to
> run services.
>
> Alpine it is
>============
>
> For starters, I wanted to learn a little bit more about this
> unknown-to-me init system, OpenRC, since I'd be spending some time
> setting up services with it.
>
> OpenRC can be used alongside or in place of SysV-style init. I will
> not get into the different roles played by so-called init systems and
> process supervisors, but OpenRC provides openrc-init, which can
> replace /sbin/init for a fully OpenRC-powered system.
>
> I could not find explicit information on whether this is the case
> with Alpine, but an actual inspection of the running system shows it
> is not. Mind you, even Alpine's /sbin/init is actually BusyBox:
>
> % file $(which init)
> /sbin/init: symbolic link to /bin/busybox
>
> I then checked out BusyBox's manual page to try and understand more:
>
>> Init is the first process started during boot. It never exits. It
>> (re)spawns children according to /etc/inittab.
>>
>> Signals:
>>
>> * HUP: reload /etc/inittab
>> * TSTP: stop respawning until CONT
>> * QUIT: re-exec another init
>> * USR1/TER, /USR2/INT:
>> run halt/reboot/poweroff/Ctrl-Alt-Del script
>
> I knew Alpine heavily leaned on BusyBox, but didn't realize it was to
> this extent. So, following this trail, there was Alpine's
> /etc/inittab, where I found this:
>
> ::sysinit:/sbin/openrc sysinit
> ::sysinit:/sbin/openrc boot
> ::wait:/sbin/openrc default
>
> Meaning, Alpine's init is BusyBox's init, which in turn calls on
> OpenRC to bring services up.
>
> Working around musl...
>======================
>
> Willing to give OpenRC a try, I had to clear up my only concern with
> Alpine: lack of compatibility with glibc software.
>
> This took a long time to evaluate, because you need to actually try
> to do what you usually do in real situations to see if things will
> work out or not.
>
> If you are questioning whether Alpine can reliably run a full desktop
> environment or window manager, play and record audio, share your
> screen, run GUI applications including the latest browsers, act as
> the host of virtualization and development environments, the answer
> is an unwavering yes.
>
> If you are questioning whether on top of that Alpine can play DRM
> video and games (e.g., Netflix and Steam), the answer is also yes,
> but you'll need a glibc layer around it. If you like Flatpak, that
> might actually be trivial.
>
> But for more involved usage of software that requires glibc, in
> particular novel and experimental stuff you are compiling yourself or
> exploring and prototyping with, your mileage may vary. It is more
> likely that a vendor will not provide a musl build of their
> software.
>
> Some stuff works just by installing `gcompat`, a compatibility layer
> that will make glibc software run as-is. Some however won't work with
> it.
>
> Sometimes I'd just compile something myself, meaning I made my own
> musl-linked executable of something that was available only for
> glibc. That works, but compilation for musl is often less documented
> and may not be possible at all depending on whether or not musl
> provides all the needed features. The latter case was however quite
> rare in my experience.
>
> Some other options are running things through Flatpak, or Nix, or
> Distrobox. But sometimes, if all failed, I just had to accept it
> wasn't possible. Or it would work and then crash when using a
> specific feature at runtime.
>
> And that's great, having ways to circumvent musl. But you could also
> just... run stuff directly? It's nice to have options, but it's also
> a lot of friction. And sadly that is what ended up exhausting me from
> using Alpine as a daily driver.
>
> I think that, if you have a very consistent usage of Alpine, where
> you are mostly doing the same thing and using the same tools, you
> could find a comfy workflow there. But I am extremely moved by
> experimentation and curiosity. And something tells me that I could
> devise a more fluid workflow to run my experiments and try different
> tools inside isolated glibc-friendly environments, but in the end
[continued in next message]
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
