Adventures in Creating a Minimal Alpine Linux Installer | Hacker News Reader

Adventures in Creating a Minimal Alpine Linux Installer

bt.ht

73 pointsbradley_taunt41 comments

I would like to see a glibc version of Alpine.

My favorite feature (the killer feature) of Alpine is that rootfs is not persistent. Persistent storage actually only contains the base system itself and each package you install. On startup, the system is loaded into a tmpfs and all your packages are loaded on top of it. I've successfully created a desktop install using this method, it boots off a USB stick and the only persistent partition is /home. I find the cleanliness of this extremely impressive.

IIRC, it only works this way if you don't use the official installer, which wants to make a persistent rootfs. I feel like Alpine has shown me "true level" [0] and I feel dirty using any distro with a persistent rootfs... in fact it's the single largest reason why I haven't felt motivated to try Linux in a while (aside from KISS since it was interesting enough).

There are no other distros like this, so the fact that it uses musl is a little disappointing if I want to use it as a desktop (which I know it's not designed for).

NixOS comes close, but is fully declarative and I don't really want to learn a new DSL today. I should probably just settle and go with Arch or something.

[0]: https://www.youtube.com/watch?v=Q1zBtJhgwBI

Regarding the persistent storage, is that anything like PuppyLinux [0] ?

Boot off of something (eg, usb drive), it loads the first layer (ro) into tmpfs, then the 2nd-X layers (also ro) over that, and finally a read/write layer of your saves (/home, config changes under /etc, ...), remove boot medium, eventually do a save to some medium.

[0] https://puppylinux.com

which redirects to

https://puppylinux-woof-ce.github.io/

Have you considered something like Fedora Silverblue?

I have, but never got around to trying it. I plan to try Kinoite too, since it's just Silverblue but with KDE Plasma. Maybe I'll actually get around to it.

Have a look at Fedora Silverblue? It boots off an immutable image and mounts user env over it. Applications and CLI customization use podman user containers (with "toolbox") and flatpaks. And it's still "just Fedora" so you get all packages and updates you need.

Silverblue is great, my only regret in my own install was not adding more storage. I could just be making this up, but it seemed like flatpaks were taking more storage than an install of the same apps from repositories.

That being said, flatseal is amazing, and I wish I could use it for everything. If this is the first time you're hearing about flatseal, check it out! It's a dashboard or control-center for each app you've installed via flatpak, and it features granular control as far as what facilities and resources that specific program can access on your machine.

> I could just be making this up, but it seemed like flatpaks were taking more storage than an install of the same apps from repositories.

Flatpaks don't use any shared libraries, that's why. Every app has its own copy of everything, including glibc. That's why flatpak can be used to run glibc apps on MUSL distributions like Alpine.

Since last commenting here, I've tried both Silverblue and Kinoite. Partitioning for Silverblue is undocumented (I had to do it all custom because I installed to the same USB stick that contained the installer itself), but I was able to figure it out after 4 or 5 tries.

OSTree is absolutely awesome, and for me it definitely seems to fill a niche between total anarchy and total NixOS. I could just rebase into Kinoite from my existing Silverblue installation, and then boot right back into Silverblue once I was done trying it.

I gotta say, GNOME (Silverblue) was a much better experience for me than KDE Plasma (Kinoite), even though it's Wayland. I'm not sure why I remembered Plasma so fondly, but it looks terrible on my 4K display and has all sorts of issues. The last I had used it was in 2017 on a 1080p screen, so maybe my standards were just low back then, but GNOME has definitely spoiled me, especially with how great its trackpad support is.

Additionally, getting Nvidia acceleration on my cheap laptop was darn simple, just install a single package and add a few kargs and boom.

Silverblue feels like it has a lot of the same benefits as Alpine without any of the downsides, although the layered packages have to be compiled into an image before they can be used, instead of being applied at boot time. It's only one command, but it takes quite some time on my hexa-core i7-10750H - maybe it'd be faster if I were running it off my internal NVMe SSD.

I feel like if I were to switch to Linux desktop it would probably be Silverblue. It's just really good and I'm glad I finally got around to trying it.

As someone that uses Alpine on literally everything except for a desktop I think this is great and would love to see it contributed upstream and integrated by the Alpine developers to be a fully supported installer option.

If you're willing to set things up yourself, Alpine is already a pretty good desktop OS. Not that I'd object to also getting preconfigured desktop flavors, granted.

I completely agree. The reason I would like to see such creations contributed upstream is that it could potentially make adoption greater.

I really like Alpine, even as a desktop OS. musl is a downside but I guess flatpaks and whatnot help that

What problems did you encounter? I installed Alpine on some laptops for desktop use and never had a problem except with one HP small netbook where the energy management seems broken as the kernel rewrites somewhere the screen backlight value with a value of 4 (= almost invisible) as soon as I pull the DC plug but doesn't update it when I plug it back. This also happens with ACPI and all power management uninstalled, so I sorta solved this by installing ACPI and making scripts to echo the right value back. This problem aside, I could install a lot of non trivial things, including for example WINE and Yabridge to use music plugins. Unless the system pulled them unbeknownst to me, I made no use of flatpaks and the like. The more I use Alpine, the more I like it.

> What problems did you encounter?

I personally found it difficult to get Nvidia drivers & Steam working. The latter worked with flatpaks, but Nvidia is always annoying.

Yes. You may laugh at me for trying to use Linux on a computer that was not built for it.

One of my favorite quotes, no idea about the author or the date, is "discoveries are made by not following instructions". Laughing because you're trying to get more from a machine that is built to give less would be really stupid; that is actually clever and admirable, and when one succeeds it gives extreme satisfaction. As for Nvidia drivers I can't help because my last experience with their cards is quite old, possibly older than the Nouveau drivers, but keep trying; it couldn't be a Alpine Linux failure as Nvidia, according to a famous Linus Torvalds quote, has already been less than friendly to Linux developers in the past.

And yet NVidia have the only graphics cards with working 3D acceleration and GPU compute capabilities.

Not true. It's just that AMD reserves those capabilities for the expensive server cards whereas Nvidia allows regular desktop gaming cards to do everything.

I bought a barebones PC specifically for my linux work station. One criteria from the outset was no NVIDIA.

Can't have CUDA without nvidia, and can't have nvidia without glibc

It's funny what different people find interesting in Alpine. I started using it expressly because it uses musl. Void is a distro with similar principles that offers a glibc version, so I use that when I need GNU.

What's the benefit of musl that you don't get with glibc?

musl is statically linked, so each binary can update at their own leisure. There are no system-wide libc updates to break anything.

How much space is added to each app to include the needed parts of app-level libc?

I don't know, but for statically linked glibc, it adds a couple megabytes to each binary that uses it. That may or may not be great if you're concerned about cache optimization, which is one big reason why dynamic linking is still so popular.

glibc doesn't actually support statically linking. (You can force it, but it breaks things.)

Yep. There's a reason why macOS and iOS have a giant (easily 1GB) "shared cache" that is most of the libraries that make up the OS in a giant file, mapped into every process's address space.

Without shared linking, in your example you end up with a copy of glibc and whatever else in every process. Without some fancy page deduplication scheme (that would come with its own set of problems), the kernel cannot know that all these pages in all these processes are the same. And they might not even be, because different versions and just the process of static linking itself might make an arbitrary number of them look slightly different.

Not every program needs all of glibc, so not all of it will be paged in, but still, it looks like you will pollute your CPU caches with many copies of essentially the same thing.

I'd love to see some instrumentation demonstrating this. I've never been able to find any evidence whatsoever that it's the case. It makes sense intuitively but I yearn for proof.

Yeah, totally fair. I mean it's relatively hard for me to conclude otherwise, but stuff is super complex, you never know. If not anything else, after all you can do link time optimization on the actual whole program, including its libraries. But whether that offsets it...

I thought about whether there was some quick evidence already, but nothing comes to mind (maybe someone's less blind to it than me now).

Maybe you could take some self-building Linux distribution like Gentoo, and hack it such that it links everything statically? Compare that against an equivalent unhacked Gentoo-installation by doing a few tasks, measuring wall clock for a good first estimate?

No idea how hard that would be in practice, especially with people mentioning that glibc does not really support that. So maybe it's actually easier with one of the BSDs, e.g. OpenBSD, which is also feasible to build completely from source because it is very self-contained, depending on how that stomachs static linking for everything.

I'd also not do it in a VM. While that's not necessarily completely invalid, it does seem to skew things pretty significantly, what with at least one whole other OS running as the hypervisor and all that.

I'ts trivial. Only the functions needed are built into the binary.

I'm given to understand that musl tends to use less memory and disk, at the expense of being slower to execute. (YMMV on all counts)

Don't get me wrong - musl is amazing, but I need CUDA on desktop and I can't get that with musl.

Great article!

You know, I would love to see an "Alpnix" in the future -- all of Alpine's speed and lightness, all of NixOS's hermetic and reproducible build capabilities...

> NixOS is a Linux distribution built on top of the Nix package manager

Can the Nix package manager not be added to Alpine?

I guess you'd have to replace apk?

I think they're actually asking for the other way around; they want nixpkgs packages that are as light on disk space as alpine, which probably needs some config tweaks (which nix lends itself to) and possibly using musl (which I think you just do with an overlay? I know it's doable, but I'm not familiar)

apko is close to that, it's a tool to build fully reproducible Alpine Linux containers from a declarative YAML description: https://github.com/chainguard-dev/apko

Wow, magical linux distro that cut Firefox memory usage in half.

Yeah I was similarly unimpressed with their methodology. Like...a single pie chart listing the results of top sorted by physical memory would have provided meaningful insight both as to why Alpine supposedly uses less memory as well as how valid the results are.

Next they should do a pie chart of devops time wasted with busybox and libc triggered issues.

Alpine is cancer.

Has anyone tried running Linux without xorg/xwayland, only pure Wayland?

Is there a distribution of Alpine Linux under 50MB (terminal only), iso or raw image, with APK intalled? Every minimal Linux installer brings Busybox without a proper package manager.

I don't understand what you're asking for. Alpine is a Linux distro, and any version of Alpine will have apk, which is a proper package manager. If you just want Alpine with a smaller disk footprint, the big problem is actually drivers, but you can work around that by removing what you don't need. In fact, it appears that the "virt" image - https://dl-cdn.alpinelinux.org/alpine/v3.17/releases/x86_64/... is 49MB, so unless I missed something, what you're asking for exists?

Reply on news.ycombinator.com