I often see bootc and/or buildstream uncritically presented as the future of the linux desktop, and find it somewhat surprising because, in my experience, they are both more complex _and_ less capable than nixos.
To elaborate, I will separate linux operating systems into three categories:
1. traditional mutable package management (debian, fedora, arch, etc) - Bad model for obvious reasons, I won't get into this.
2. immutable images (embedded deployments, android, chromeos) - A build system (yocto, nix, buildroot, buildstream) procudes a disk image. System boots the disk image and handles updates using A/B root partitions with `systemd-sysupdate` or similar.
3. store-based atomic (nixos, ublue) - The system keeps a mutable store of hashed objects (/nix/store, /var/lib/containers/storage, /ostree/repo) and boots a specific system generation. Updates add new objects to the store, which must be automatically cleaned, and create a new systemd generation to boot into.
In the case of categories 2 and 3, a build system of some kind is used to produce the image or packages that are turned into the new system generation.
The bootc project, which falls into category 3, attempts to use the standardized and highly adopted OCI image format (layered filesystem changes stored in a content addressed store) as a medium for distributing linux systems. The major limitation here is that these systems are very complicated to build and extend. While it may not seem that way compared to nixos if you have prior experience writing dockerfiles, configuring your system with imperative statements that build on previous state is _really_ tedious. For example, you can't just re-use work with multiple `FROM` statements in the same layer, so you instead need to copy files between images. This is incredibly jank, look at [the docs](https://blue-build.org/how-to/minimal-setup/) for bluebuild's module system. Additionally, for a motivated user to change their system internals, they need to make the jump to hosting it with CI and pulling the images.
As jcastro mentioned elsewhere in this thread, there is work in the ublue project, which focuses on bootc images, to instead build their systems from source using buildstream, the same way GNOME OS works. The idea is that this is no longer a "distribution" and doesn't have "packages" anymore, since the entire system is built from source into an image that can be updated to atomically. While this model is simpler and way less jank than assembling your OS in a dockerfile, the model of separating packaging from distribution makes things harder for users for no benefit over the alternative.
To elaborate: Buildstream is a build system created by gnome developers that works as follows:
- Various element are defined in yaml files with their dependency and build steps
- Buildstream forms a tree of build elements to evaluate
- Each element is evaluated in a sandbox with access to only its dependencies and the output is placed in a content-addressed store for caching
If you have experience with nix, you may recognize that this is almost the same way nix works, with the difference that buildstream dependencies are mounted to regular directories (e.g. /usr) in the build sandbox instead of directly dealt with as /nix/store objects, and that buildstream is much harder to extend. A nix build results in artifacts that live in the nix store and are symlinked to other paths in the nix store, while a buildstream build results in artifacts that are compatible with a more traditional directory structure.
The idea of GNOME OS being "distroless" and not having packages is misleading, as it does have packages. Only, the packages exist exclusively during the build process. In order for a user to modify their system, they must add a rule to the buildstream definitions their system is built from and rebuild the entire thing from source to generate a new system image, which is unnecessarily burdensome. This is because the content-addressed artifact store (buildstream's cache) that exists when building has no relationship to the content-addressed artifact store on the deployed system (ostree or oci storage). This is pointless indirection with no clear benefit. By not separating building from distribution, nixos (a project using the nix dsl to build a linux system) achieves the same benefits of this model without any of the drawbacks. Users can modify how their system works, use caches, add their own packages, and share/integrate these modifications freely without building their entire os again from source every time.
To put this power in perspective, adding a nginx server to your system on nixos amounts to adding to your nix configuration:
services.nginx.enable = true;
and then rebuilding, switching to the new system generation.
Imagine how painful it would be to do this via a dockerfile (based off a different image) or buildstream definitions...
Finally, I'd like to clarify that nixos is not perfect. There are many areas of that need improvement (documentation, evaluation speed, evaluation caching, ifd, error messages, etc). However, I believe nixos is a fundamentally better and simpler model than the one being pushed by a lot of the linux desktop ecosystem at the moment. I believe a lot of the work on infrastructure like bootc and buildstream would be better focused on nix/nixos, or at least would benefit from learning from them.
nixos may have a simpler moder on paper the implementation of it is so backwards that it ruins everything, and once you implement the model you see its not simpler
and your conclussion is wrong nix and nixos has a lot to learn from bootc, like usage of standard industry tooling instead of inventing its own things for what to be honest is no benefit mostly drawbacks which are so huge. BootC uses primarily conventions already existing previously its just different way to deliver and define, better in almost every way.
first off i can start nginx locally i dont need to change a fancy config in a bad DSL(and yes its bad actually horrible),but if i want it in an image i add one line in my docker file RUN systemctl enable nginx and rebuild thats it does it take longer to rebuild WHO CARES CI takes care of it
nix is a build system, and has nothing to learn from bootc. However, I agree that nixos could adopt some of the developments around bootc, like composefs for verified boot.
> usage of standard industry tooling instead of inventing its own things for what to be honest is no benefit mostly drawbacks which are so huge
nix was first released in 2003, nixos and docker were first released in 2013, and the OCI was started in 2015. bootc was created ~2023. For the purposes of deploying environments, an input-addressed (hopefully content-addressed in the future) tree of build artifacts is just a conceptually _better_ model than coarse layers of filesystem changes. It's a shame it isn't industry standard, because the industry would be better off if it was.
As previously established, nix and nixos were created before docker, and all of them existed before bootc, even though you might not have personally encountered nixos before then. There's a lot of value in keeping an open mind to technologies you might not be familiar or comfortable with, even though it might be tempting to arbitrarily hate them because they are different from what is commonly used.
> better in almost every way
refer to my previous post
> first off i can start nginx locally
yes, but you have to install and configure it. You cannot add nginx as a system package on a bootc system without building a new layer. Configuring it can be done by manually editing /etc/nginx and /var/www on _both_ nixos and bootc distros, but configuring it in a manner reproducible across machines requires either writing all your config in the dockerfile or something like ansible on a bootc system.
> bad DSL(and yes its bad actually horrible)
the nix language has plenty of areas for improvement, but it really is not that bad. I personally prefer it to a combination of yaml and python glue that alternatives like buildstream tend to use.
> WHO CARES CI takes care of it
good luck asking any user who wants to change something about their system to choose between setting up CI, essentially being responsible for a custom distribution, or waiting for a docker build on every update because their bottom layer's cache gets invalidated.
> I’m increasingly convinced that the mere existence of a package manager (for programs, not source code) is a sign of a failed platform design.
Nix is a build system for source code, similar to make. It is such a robust build system that it also can be used as a package manager with a binary cache
The problem with a federation system like mastodon/activitypub is that relying on propagation hurts usability and discoverability. [tangled.sh](https://tangled.sh/) is to federated forgejo what bluesky is to mastodon, where it relies on atproto to have decentralization without sacrificing ux
There is an ActivityPub protocol extension that is specific to federation of code forges, called ForgeFed. It is an NLnet funded project, that receives funding through EU Next Generation Internet programs. But the project is struggling, because of a lack of community help and implementers giving feedback to help steer and mature the specs.
As someone who actively uses a wayland compositor and has done so since switching to linux ~4 years ago, I often feel like I live in a different world from the authors of articles discussing its usability. Just to discuss a few points made about wayland's supposed inferiority:
> Wayland cannot do (or do well) tons of things:
> VNC server
> remote desktop
I don't regularly use either of these so I cannot attest to whether they work on wayland.
The remote desktop is one of the reasons I haven't switched to wayland on a few machines. I used Anydesk to manage them, and Anydesk says they are unable to support Wayland.
the remote desktop stuff is important for some. Waypipe was very slow last time I tried it.
That all being said, I actually found the remote desktop situation to be /okay/ on wayland. `gnome-remote-desktop` is decent; though it uses quite a lot of bandwidth, it appeared to be smoother than xrdp when that bandwidth is available. And the sunshine/moonlight pair, while intended for game streaming, worked fine as a usual remote desktop server/client under wayland.
The only wayland compositor that I know of that handles XWayland correctly is hyprland.
And when I say correctly, I mean that if I am on a non 96 DPI display, e.g. a 168 DPI display (1.75x) and want things scaling properly, Xwayland gets told to pretend that the display size is some resolution in the vicinity of ~1097 by ~686 (not sure how this part works, and honestly I don't think it's relevant) and a DPI of 96. Then xwayland does the most idiotic thing imaginable, it takes the output of applications running under it and stretches it.
And now I have vaseline on my screen.
No thanks.
I may try hyprland at some point to see if there's actual value to using Wayland over X but so far every time I've tried to switch it has been random obstacle after random obstacle.
One of the most baffling has been arbitrary restrictions on the scaling factor.
KWin/Plasma have a switch in the settings where you can toggle vaseline on or off. If you run modern X11 applications that are HiDPI-aware, or you can crank the size of fonts and controls however you want, you may turn it off. If you have that Athena widget application that is tiny otherwise, you turn it on (alas, there is no possibility to have two sets of X display and putting apps on the one you need).
The only thing that for some stupid reason can't be solved is that I can't turn off blurry interpolation on the low DPI applications. Come on! The low DPI layer is in integer multiples, make it nearest-neighbor pixelated but crisp! How hard is that!?
To elaborate, I will separate linux operating systems into three categories:
1. traditional mutable package management (debian, fedora, arch, etc) - Bad model for obvious reasons, I won't get into this.
2. immutable images (embedded deployments, android, chromeos) - A build system (yocto, nix, buildroot, buildstream) procudes a disk image. System boots the disk image and handles updates using A/B root partitions with `systemd-sysupdate` or similar.
3. store-based atomic (nixos, ublue) - The system keeps a mutable store of hashed objects (/nix/store, /var/lib/containers/storage, /ostree/repo) and boots a specific system generation. Updates add new objects to the store, which must be automatically cleaned, and create a new systemd generation to boot into.
In the case of categories 2 and 3, a build system of some kind is used to produce the image or packages that are turned into the new system generation.
The bootc project, which falls into category 3, attempts to use the standardized and highly adopted OCI image format (layered filesystem changes stored in a content addressed store) as a medium for distributing linux systems. The major limitation here is that these systems are very complicated to build and extend. While it may not seem that way compared to nixos if you have prior experience writing dockerfiles, configuring your system with imperative statements that build on previous state is _really_ tedious. For example, you can't just re-use work with multiple `FROM` statements in the same layer, so you instead need to copy files between images. This is incredibly jank, look at [the docs](https://blue-build.org/how-to/minimal-setup/) for bluebuild's module system. Additionally, for a motivated user to change their system internals, they need to make the jump to hosting it with CI and pulling the images.
As jcastro mentioned elsewhere in this thread, there is work in the ublue project, which focuses on bootc images, to instead build their systems from source using buildstream, the same way GNOME OS works. The idea is that this is no longer a "distribution" and doesn't have "packages" anymore, since the entire system is built from source into an image that can be updated to atomically. While this model is simpler and way less jank than assembling your OS in a dockerfile, the model of separating packaging from distribution makes things harder for users for no benefit over the alternative.
To elaborate: Buildstream is a build system created by gnome developers that works as follows:
- Various element are defined in yaml files with their dependency and build steps
- Buildstream forms a tree of build elements to evaluate
- Each element is evaluated in a sandbox with access to only its dependencies and the output is placed in a content-addressed store for caching
If you have experience with nix, you may recognize that this is almost the same way nix works, with the difference that buildstream dependencies are mounted to regular directories (e.g. /usr) in the build sandbox instead of directly dealt with as /nix/store objects, and that buildstream is much harder to extend. A nix build results in artifacts that live in the nix store and are symlinked to other paths in the nix store, while a buildstream build results in artifacts that are compatible with a more traditional directory structure.
The idea of GNOME OS being "distroless" and not having packages is misleading, as it does have packages. Only, the packages exist exclusively during the build process. In order for a user to modify their system, they must add a rule to the buildstream definitions their system is built from and rebuild the entire thing from source to generate a new system image, which is unnecessarily burdensome. This is because the content-addressed artifact store (buildstream's cache) that exists when building has no relationship to the content-addressed artifact store on the deployed system (ostree or oci storage). This is pointless indirection with no clear benefit. By not separating building from distribution, nixos (a project using the nix dsl to build a linux system) achieves the same benefits of this model without any of the drawbacks. Users can modify how their system works, use caches, add their own packages, and share/integrate these modifications freely without building their entire os again from source every time.
To put this power in perspective, adding a nginx server to your system on nixos amounts to adding to your nix configuration:
services.nginx.enable = true;
and then rebuilding, switching to the new system generation.
Imagine how painful it would be to do this via a dockerfile (based off a different image) or buildstream definitions...
Finally, I'd like to clarify that nixos is not perfect. There are many areas of that need improvement (documentation, evaluation speed, evaluation caching, ifd, error messages, etc). However, I believe nixos is a fundamentally better and simpler model than the one being pushed by a lot of the linux desktop ecosystem at the moment. I believe a lot of the work on infrastructure like bootc and buildstream would be better focused on nix/nixos, or at least would benefit from learning from them.