Live data from Hacker News

Bootc and OSTree: Modernizing Linux System Deployment

a-cup-of.coffee

41–50 of 69 posts

Re: Bootc and OSTree: Modernizing Linux System Deployment

#41
I like the idea behind ostree and bootc, but I feel that OCI (with tarlayers) is not a good fit. `repack` makes an absolute hash of things, and since the layers are logically packaged, they will have to be composed somehow, and then ostree becomes only slightly more useful than coreos's A/B usr.

OCI roughly assumes that layers will be laid out in some logical way, and that a given host will see opportunities to reuse across different instances, but with bootc, there will only ever be one instance.

OCI also assumes that individual layers are small enough that it is always worth pulling and unpacking a layer instead of some kind of authentication delta, which is great for a k8s cluster in a center, but not great for devices out on the edge, where you might want this kind of pseudo-immutable system even more.

I really want some standardized way for a manifest in OCI to say that "this content is also available in other format X here".

Re: Bootc and OSTree: Modernizing Linux System Deployment

#42

developers will do anything but to use a cow fs

You cannot replicate the full filesystem among multiple hosts with their own drives though, can you?

With OSTree my team can deploy a commit over an existing ones to a field of 60k embedded Linux devices. Similarly bootc is a great alternative for deploying images for dedicated or virtualized servers.

Re: Bootc and OSTree: Modernizing Linux System Deployment

#43

I'd love to have my system be declared in code, so I can replicate the same environment across a laptop and a desktop with minimal drift. So same OS, users, packages, flatpaks etc. And a mostly synced home dir too. Is NixOS the only viable way to do this? I don't like the path mangling that Nix introduces. It seems like an immutable distro customized via a Containerfile could work too? Except rebooting/reimagine for…

Apart from NixOS and GuixSD there's also Arkane Linux (https://www.arkanelinux.org/>), which seems kind of interesting, but I don't like various decisions it makes.

Re: Bootc and OSTree: Modernizing Linux System Deployment

#44
post #20

Earlier quoted context omitted.

> A filesystem with snapshots makes software installation transactional. You take a snapshot, install some software, and if it doesn't work right, you can revert to the snapshot. (With very slightly more flexible snapshots, you can limit the snapshot to just some part of the directory tree, but this is not essential; it merely permits more flexibility.) Eh, you don't typically have a lock mechanism for the filesystem…

A snapshot is taken before installing updates, so you'd get two snapshots from your example. Rolling back would leave you right after adjusting firewall rules.

Not if someone else modified firewall rules while you were installing updates? (Eg: someone else being a Cron job).

Re: Bootc and OSTree: Modernizing Linux System Deployment

#45
post #5

bootc and OSTree are both very neat, but the leading edge of immutable Linux distros (GNOME OS, KDE Linux) is currently converging on a different proposal by systemd developers that's standardized by the UAPI Group ( https://uapi-group.org/specifications/ ). It fixes quite a few of the complexities with OSTree (updates are handled by `systemd-sysupdate`/`updatectl` and are just files served via HTTP) and is quite a b…

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

Re: Bootc and OSTree: Modernizing Linux System Deployment

#46
post #5

bootc and OSTree are both very neat, but the leading edge of immutable Linux distros (GNOME OS, KDE Linux) is currently converging on a different proposal by systemd developers that's standardized by the UAPI Group ( https://uapi-group.org/specifications/ ). It fixes quite a few of the complexities with OSTree (updates are handled by `systemd-sysupdate`/`updatectl` and are just files served via HTTP) and is quite a b…

Ironically the first implementation of ostree required an HTTPS server to serve the ostree commits, allowing a much smaller subset of what's needed to be transferred. However that became an adoption hurdle since it required unique infrastructure. Ostree switched to using containers because zstd allows compressed chunks now rather than the old all-or-nothing image layers, and the existing widespread container image re…

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)

Re: Bootc and OSTree: Modernizing Linux System Deployment

#47
post #5

bootc and OSTree are both very neat, but the leading edge of immutable Linux distros (GNOME OS, KDE Linux) is currently converging on a different proposal by systemd developers that's standardized by the UAPI Group ( https://uapi-group.org/specifications/ ). It fixes quite a few of the complexities with OSTree (updates are handled by `systemd-sysupdate`/`updatectl` and are just files served via HTTP) and is quite a b…

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. i…

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

Re: Bootc and OSTree: Modernizing Linux System Deployment

#48
post #44

Earlier quoted context omitted.

A snapshot is taken before installing updates, so you'd get two snapshots from your example. Rolling back would leave you right after adjusting firewall rules.

Not if someone else modified firewall rules while you were installing updates? (Eg: someone else being a Cron job).

[deleted]

Re: Bootc and OSTree: Modernizing Linux System Deployment

#49
post #44

Earlier quoted context omitted.

A snapshot is taken before installing updates, so you'd get two snapshots from your example. Rolling back would leave you right after adjusting firewall rules.

Not if someone else modified firewall rules while you were installing updates? (Eg: someone else being a Cron job).

That's an easy thing to account for.

Re: Bootc and OSTree: Modernizing Linux System Deployment

#50
post #47

Earlier quoted context omitted.

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. i…

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…

> nix and nixos has a lot to learn from bootc

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.

> BootC uses primarily conventions already existing previously

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.

Post reply on HN