Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bootc and OSTree: Modernizing Linux System Deployment

a-cup-of.coffee

Post reply on HN
Print view View original

21–30 of 69 posts

Re: Bootc and OSTree: Modernizing Linux System Deployment

#21

Post by coderedart »

smashed wrote: post #6
pojntfx wrote: 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…

> the bleeding edge of immutable Linux distros (GNOME OS, KDE Linux) These are words but they don't make sense.

Kdelinux uses pacman for now, but the eventual goal is systemd-sysext based mkosi images.

They are also considering moving to buildstream and join gnome.

Re: Bootc and OSTree: Modernizing Linux System Deployment

#22

Post by 7777777phil »

pojntfx wrote: post #14
smashed wrote: post #6

Earlier quoted context omitted.

> the bleeding edge of immutable Linux distros (GNOME OS, KDE Linux) These are words but they don't make sense.

Corrected - I meant leading edge. Context re:distros mentioned: GNOME OS: https://os.gnome.org/ KDE Linux: https://kde.org/linux/

Doubling progression-free survival (17.6 vs 7.4 months) is a large effect size for recurrent prostate cancer.

Re: Bootc and OSTree: Modernizing Linux System Deployment

#24

Post by Scipio_Afri »

7777777phil wrote: post #22
pojntfx wrote: post #14

Earlier quoted context omitted.

Corrected - I meant leading edge. Context re:distros mentioned: GNOME OS: https://os.gnome.org/ KDE Linux: https://kde.org/linux/

Doubling progression-free survival (17.6 vs 7.4 months) is a large effect size for recurrent prostate cancer.

I’m pretty sure Linux doesn’t have a prostate, even with all the changes in the leading edge distros, and you’re commenting in the wrong post.

Re: Bootc and OSTree: Modernizing Linux System Deployment

#25

Post by debugnik »

rurban wrote: post #8
pojntfx wrote: 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…

Typo: (CoreOS and Fedora Silverblue) are the bleeding edge of immutable distros. Those mentioned are just users.

It's confusing, but there're apparently distros called "GNOME OS" and "KDE Linux" now.

Re: Bootc and OSTree: Modernizing Linux System Deployment

#26

Post by debugnik »

e12e wrote: post #20
lproven wrote: post #16

It is very odd to me to watch OStree-based distros starting to take off and win recruits. The only reason Red Hat needed to invent this very complex mechanism was because RH does not officially have a COW-snapshot capable filesystem in its enterprise distro. 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 t…

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

Re: Bootc and OSTree: Modernizing Linux System Deployment

#27

Post by iamcalledrob »

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 every change sounds tedious as hell.

Re: Bootc and OSTree: Modernizing Linux System Deployment

#29

Post by jcastro »

iamcalledrob wrote: post #27

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…

> customized via a Containerfile could work too? Except rebooting/reimagine for every change sounds tedious as hell.

You can do this today with Aurora, Bazzite, Bluefin, and other bootc systems. The system updates by default are weekly and require a reboot but when you move most of the stuff into the userspace most of that stuff updates independently anyway.

Re: Bootc and OSTree: Modernizing Linux System Deployment

#30

Post by jcastro »

pojntfx wrote: 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…

> is currently converging on a different proposal by systemd developers that's standardized by the UAPI Group

We're working in this space with Project Bluefin: https://github.com/projectbluefin/dakota

Both approaches are indeed competitive, but you can also leverage both to achieve the same thing. We're experimenting with a pure ddi Bluefin, a buildstream/GNOMEOS one that spits out a bootc image, as well as a Bluefin that is just a systemd-sysext on top of GNOME OS. Chef's choice!

There will be many ways to slice this problem -- my opinion is that in the end it will be how you design the infrastructure to make these and not the artifacts themselves.

We already have CentOS/Fedora builds alongside these, long term we'll see which ones end up being the most efficient. Buildstream is a tool which people should look at in this space too: https://buildstream.build/index.html

Post reply on HN