[FireInsight]

The 'bootable container' / 'native container' space is getting really exiting, even (and especially) for desktop usecases. Atomic Fedora has had support for so called Ostree Native Containers for a while now, and that will eventually adapt `bootc` as the base layer for building and booting containers (but as of now it's not totally ready yet). VanillaOS is also working on similar things but I don't think it'll use `bootc`.

Some awesome community projects have also been born out of this space:

- https://universal-blue.org/ provides some neat Fedora images, which have one of the best Nvidia driver experiences on Linux IME, and are over all solid and dependable

- https://blue-build.org/ makes it pretty easy to build images like Universal Blue's for personal use

The best part here is really the composability; you can take a solid atomic Linux base, add whatever you like, and ship it over the air to client computers with container registries. All clients see is a diff every day, which they pull and 'apply' to be used after the next boot.

[themgt]

There's also Elemental which is SUSE-oriented but distro agnostic https://github.com/rancher/elemental-toolkit

I've been hoping NixOS moves in this direction over time, the distribution/rollout aspect seems under-baked currently.

[hhh]

What's the best way to start with Elemental today? I haven't been able to grasp a start point, unlike RKE/Rancher which is pretty easy to onboard.

[themgt]

It depends what you're trying to do, but I was essentially following this guide: https://rancher.github.io/elemental-toolkit/docs/examples/em... updated to ghcr.io/rancher/elemental-toolkit/elemental-cli:v1.3.0 / registry.suse.com/suse/sle-micro-rancher/5.4

The whole project is in major flux now though, with v1.3 -> v2.1 being pre-release and docs haven't been updated, so I'm waiting for dust to settle before picking it back up. But basically `docker build` -> `elemental build-disk` -> qcow2/iso -> deploy / `elemental upgrade` update via OCI registry, or deploy vanilla image and then just update that via registry.

[tkz1312]

What do you think nixos is missing in this area?

[ranger_danger]

One of my biggest complaints with distros has been the lack of documentation on how to actually build the distro itself, not just an ISO but like build all the packages from source as well. Like as if you were following an LFS book. I have seen VERY few distros that provide this.

Do you think this helps that at all?

[Zambyte]

GNU Guix does an awesome job with this. The documentation is one of the main reasons I left NixOS, and then some time later I landed on Guix. I have stuck on the latter for a few years now.

[fransje26]

Out of personal interest, do you also make use of the non-free parts of Guix? And if so, how well do they work, and how well are they documented compared to the "core" part? The orthodoxy of free software purity is nice, but I unfortunately also need to get CUDA working.

I tried Nix a few times, but the documentation was so lacking and/or outdated that I couldn't figure out how to get the setup I needed working, and I had to drop the idea as I couldn't justify the time investment that would be needed to prod around in the dark until everything worked.

[Zambyte]

Can't speak to CUDA as all of my systems run AMD or Intel at this point, but I use the nonguix channel for the mainline Linux kernel. I even built a custom iso using the mainline kernel, since my servers NIC requires non-free blobs. The process for doing that was surprisingly easy to me.

Between the nonguix README and other resources like systemcrafters, you're in pretty good company as far as the documentation for non-free things to.

Edit: less related but I still wanted to mention:

Guix makes extensive use of the info[0][1] system for documentation also. There is essentially a textbook worth of information locally on the machine, which is generally what I use instead of turning to the web.

[0] https://www.gnu.org/software/texinfo/manual/info-stnd/info-s...

[1] https://www.gnu.org/software/emacs/manual/html_mono/info.htm...

[fransje26]

Thank you for your feedback and the information!

[rekado]

CUDA is available in the guix-science-nonfree channel. https://hpc.guix.info/channels/non-free/

[brirec]

Universal Blue’s build system (not Blue-Build) is pretty clear, and self documenting. I maintained a personal fork of Bluefin for a while, and it was easy to understand!

[aliasxneo]

What made you stop?

[brirec]

Honestly? Immersing myself headfirst into Nix/NixOS, which has been fun and worthwhile.. but I’m not convinced it’s really “better,” at least for my needs.

And the fact that it’s ever so slightly easier to build and deploy a NixOS VM from scratch on a Proxmox VE server than to build and deploy a CoreOS VM using Ignition (also on Proxmox).

But it’s probably worth it for me to switch back, at least for now. It takes maybe 10-15 minutes to build a bootable Bluefin fork native container image with GitHub Actions, but a relatively basic NixOS+ Plasma 6 image took closer to 60 minutes and came out to over 8 GB compressed…

[aliasxneo]

Interesting, I _just_ went from NixOS to Bluefin. I took home-manager with me, though, which gives me just enough Nix without the NixOS headaches (mainly around processes daring to bring "foreign" binaries into the system). My honeymoon period with Nix lasted about six months and was pretty quickly over. I stuck with NixOS for about 18 months only out of laziness of not wanting to set something else up. I really like this new stack, though. Time will tell if it's actually better.

[Gormo]

Where I'm from, we refer to a "bootable / native container" as an "OS image".