Show HN: An immutable ostree-based Arch Linux image(github.com)
github.com
Show HN: An immutable ostree-based Arch Linux image
https://github.com/myyc/vyy
7 comments
As a previous Arch user I don't understand what you mean by "best of both worlds"? The point of Arch is to be mutable to a great extent and shipping vanilla packages.
For example, it is quite annoying to have a sane font setup due to Arch shipping vanilla. Fontconfig sucks, it has bad documentation and Arch Wiki examples go only so far. Among the entire distro universe only Fedora has sane configs. So an immutable Arch goes against immutability.
Moreover OSTree requires a server to receive updates regularly, are you going to put the effort to building the OSTree multiple times a day? Why should we trust a single person?
For example, it is quite annoying to have a sane font setup due to Arch shipping vanilla. Fontconfig sucks, it has bad documentation and Arch Wiki examples go only so far. Among the entire distro universe only Fedora has sane configs. So an immutable Arch goes against immutability.
Moreover OSTree requires a server to receive updates regularly, are you going to put the effort to building the OSTree multiple times a day? Why should we trust a single person?
Ostree and immutable distros in general are seeing a renewed interest lately for mostly security reasons but they have been and are still widely used for appliance-type devices.
I could see someone wanting to build an arch based firmware with OTA updates use this as a proof of concept. Yes, they would have to customize it and operate some infra but that does not make it useless.
I could see someone wanting to build an arch based firmware with OTA updates use this as a proof of concept. Yes, they would have to customize it and operate some infra but that does not make it useless.
exactly. plus i mean, this particular build is quite boring because it's, like i said, silverblue. vanilla gnome and all that. but one can go quite wild and make vastly different builds. building locally takes very little since it's basically decompressing a bunch of packages, moving some files around and building an initramfs, so the infrastructure one actually needs is minimal (especially if said upgrades happen silently).
i must say that even though this tech has been around for a while it's still very much WIP. much of the ostree command line is undocumented, some commands are hidden and even though there is significant overlap between rpm-ostree, ostree and bootc, they do quite different things and some things are easy with one tool and outright impossible with the other. but personally i think this is the future of "mainstream" linux, and even though "immutable linux" has been often associated to locked platforms (e.g. android), it's been fun to showcase how you can do it yourself too, with whichever distro you like.
i must say that even though this tech has been around for a while it's still very much WIP. much of the ostree command line is undocumented, some commands are hidden and even though there is significant overlap between rpm-ostree, ostree and bootc, they do quite different things and some things are easy with one tool and outright impossible with the other. but personally i think this is the future of "mainstream" linux, and even though "immutable linux" has been often associated to locked platforms (e.g. android), it's been fun to showcase how you can do it yourself too, with whichever distro you like.
Of course, SteamOS is an immutable Arch spin, so it's not as if this isn't an idea that's been had before, but Arch is indeed on the surface sort of a weird distro to implement as immutable.
this one technically doesn't have an ostree server because it would require dedicated infrastructure, but if you decide to either try out images (they're in ghcr) or fork the project and build your own, you can schedule nightly builds (as it's being done now) and use bootc rather than ostree. the problem is that you'd always have to pull a 2GB image rather than incremental updates.
Look at this project for reference too, feels pretty similar as well
https://github.com/Zerixal/Zena
https://github.com/Zerixal/Zena
it's the same idea, done slightly differently because with fedora you can start from their own atomic images and change them a bit. the setup is much easier and probably more robust because it feels less like a hack. ironically, my intermediate step between silverblue with layered packages and vyy was similar: https://github.com/myyc/silverpurple/ – using bluebuild instead of containerfiles.
worth noting that because of the constraints of the setup you can develop something similar on your main machine without any realistic possibility of data loss since you never really touch the bootloader or the filesystem (partitioning and so on).