bigpod

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

not realy look for a more detailed anwser on one of your other comments under the parent of this one

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.

kinda the point

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

thanks to distrobox

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

at the end of the day its just set of principles

same principles, Buzzword, Excitement

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

your tests and your application knowledge should

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

essentialy yes

with good pipeline and knowledge about your app you should be able to ensure it works without much of a problem

use --include-path to ensure its in

its more about being more like people say as smaller by 200% isnt as understandable as 30 times smaller

this is not valid but its what people say 30 times smaller.

i have docker-slim in CICD completly automated seems to not have a problem as i ahve configure it per pipeline, maybe check out examples for docker-slim

docker-slim started at docker hackathon in 2015 and company behind Slim.AI has an extension for docker desktop in its marketplace.

this removes far more then multistage docker build ever would, do you need bash dash or passwd or many other binaries and files in image that are in by default no you dont only way to do anything simular to what docker-slim does is with scratch image which doesnt work if you dont copy everything you need in

it sometimes doesnt work sure but thats why we have tests and test i minify all my containers nowdays and in most cases it works in those that it doesnt i figured out the pattern when and why for my apps and use include flags to ensure things remain inside

yes that tends to be the problem with docker-slim as well that is why it includes flags like --include-path with which you can easily achive such fixes

personaly i highly recommend as it works in most cases and gets rid of those vulnerablities that come with things like bash or passwd that you dont need in prod apps

it is error prone somewhat but it has flags to allow you to fine tune what gets added back in. great thing is you can work with any base image and language including those that wont work with scratch

thats why you should test and if there are stuff htat needs to be included but arent and you know wont work fail the test and add --include-path to your docker-slim command to ensure something is added