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.
yea it switched to a in general much better distribution method then custom https server, for one thing authentication is built in something many of these https solutions forget(look at every linux package manager)
system extensions are just as usable on bootc based systems but bootc based systems allow for much simpler composition, you dont have to know about all the intricacies of linux filesystem tree to install a set of packges for your own image as you can base uppon what someone else did easily using industry standard semantics and use actual package managers. And on top of all that it uses a far better distribution system, the oci's distribution spec
your normal distro does updates by pulling every package on your system and swapping files mid running this can cause miriad of issues just by doing it and another miriad if update is stopped mid updating(not always but sometimes). So this means your system is being recomposed at runtime
while on other hand on bluefin and simialr image based OS-s composition of your OS is done somewhere else not directly on your running file system(could be your computer just not your rootFS) then it takes that image and pulls old image(normally on startup) and places new one in its place all in one go, so any composition errors dont get triggered during update and such. (composition before deployment is a principle cloud-native pushes) This makes updates far more stable and less error prone and automatic updates are a thing you dont even notice day to day. and what happens if image cant boot it just boots the old one or you can select the old one from grub(2 old versions are stored per default if i remember correctly) This idea has been successfully used by likes of android chromeOS and such to create seamless and risk free updates.
> This idea has been successfully used by likes of android chromeOS and such to create seamless and risk free updates.
Those are not updates, they are just containers deployments at the end of the day (Flatpak and all related technologies).
> your normal distro does updates by pulling every package on your system and swapping files mid running this can cause miriad of issues just by doing it and another miriad if update is stopped mid updating(not always but sometimes). So this means your system is being recomposed at runtime
In practice rolling distros so that every day, with very little issues. (Arch is a good example of that).
yes it is un update its not a container deployment and this is in no way connected to flatpak outside of ostree
well my experiance and experiance of many other people say otherwise and most wide reaching example look at how a single miss configured package(dependancy misconfiguration) deleted Linus Sebastians pop desktop.(and no the fact that he didnt read doesnt excuse poor package dependancies that even got to that point) that could have easily been caught if composition didnt happen at runtime
On non 0 number of occasions i lost or recoverably broke arch installs while it was updating using pacman just because X or DE's WM got crashed during update because of update. just 2 examples out of many for why composition at runtime is a bad idea for linux to be a more mainstream OS
Cloud native is a set of principles with which you develop and build software to make it less likely to break and be more conducive to rapid iteration(In theory you dont even need to deploy your app to cloud to be cloud native) ublue and project bluefin just cherry picked those principles that make sense for a desktop OS to try and bring what cloud native did for server world into desktop linux and hopefully make it not suck.
one of those sucky things about linux desktop is package management which is just sad at best problematic at worst which is why image-based and flatpak first
no project bluefin doesnt sell a piece of hardware but chromebook is far more known as a technology then the operating system it runs ChromeOS(based on gentoo)
so its wording targeted at layman
its more applying cloud native principles (principles that work very well in server side even if you don't use cloud) to create stable and well made "next-gen" distros
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