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
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
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
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.
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
been using bluefin while it was in beta for almost a year and for me it was very easy to move to it as my development workflow is nothing like most and i heavily utilize podman containers on the outset and not system packager or flatpak. this is what i have been recommending to most at this time as it lowers friction whether you use silverblue or not, and enchances tability of your system as if you switch versions doesnt leave lots of gooblygook of orphaned files and such brokedness
Totally agreed one man distros might not get maintained after release or two but:
Behind Bluefin is a project called Universal blue which is a whole bunch of people with many interests, but biggest one being DevOps, devOps combined with its "immutable", image-based nature which should make maintenance of distro lot easier then normal
in some cases i essentialy ensure my whole app remains using --include-path flags so that i get a removal of you know things that i absolutly dont need.
one question is is possible in any kind of way that that passwd or any other binary that stays that you dont need has a security vulnarability that could if someone got into the container in one way or another(most likely your app) cause trouble on the host.
hint yes it is and that could be a problem a giuant one
i would disagree i use em in production apps, i configured it and it works if you do it blindly it happens that sometimes things break but if you configure it, it will work
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