jcastro (u/jcastro) - Readit News

jcastro commented on Bootc and OSTree: Modernizing Linux System Deployment a-cup-of.coffee/blog/ostr... · Posted by u/mrtedbear

pojntfx · 15 days ago

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 bit easier to extend with things like an immutable version of the Nvidia drivers or codecs thanks to system extensions handled by `systemd-sysext` (which in turn are just simple squashfs files overlayed over `/usr`) and configuration via `systemd-confext`. `mkosi`, also by systemd, is quickly becoming _the_ way to build custom images too, and is somewhat tied to these new standards.

jcastro · 15 days ago

> 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

jcastro commented on Bootc and OSTree: Modernizing Linux System Deployment a-cup-of.coffee/blog/ostr... · Posted by u/mrtedbear

iamcalledrob · 15 days ago

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.

jcastro · 15 days ago

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

jcastro commented on Why didn't AI “join the workforce” in 2025? calnewport.com/why-didnt-... · Posted by u/zdw

jcastro · 2 months ago

> In one example I cite in my article, ChatGPT Agent spends fourteen minutes futilely trying to select a value from a drop-down menu on a real estate website

Man dude, don't automate toil add an API to the website.It's supposed to have one!

jcastro commented on Ask HN: Abandoned/dead projects you think died before their time and why? · Posted by u/ofalkaed

jcastro · 5 months ago

OS/2 my beloved.

jcastro commented on Bluefin LTS Is Released docs.projectbluefin.io/bl... · Posted by u/nikodunk

moltopoco · 6 months ago

I think I agree with what the grandparent poster wrote, and I'll try to expand on my reasoning. As a mildly paranoid user, I cannot possibly keep track all of all the individuals who maintain parts of Bluefin, no matter how much I like following all of you on Discord etc. I still don't even know what a DistGit or COPR is.

When I install a more corporate product such as Ubuntu or macOS, sure, it's also mostly middlemen repackaging other people's code. But it is clear what and who belongs to the company or team, and the team has a shared interest in protecting its reputation, and hopefully pwning or buying a single individual's accounts cannot infect everything else.

To that end, I agree that "consolidation" would help - sometimes that might mean controlled mirroring of things into the Bluefin org or so - but that is exactly what distros do, and I understand that Bluefin does not want to be a distro.

jcastro · 6 months ago

> I still don't even know what a DistGit or COPR is.

I agree, I hate all of this too. The wolfi version will be much better.

jcastro commented on Bluefin LTS Is Released docs.projectbluefin.io/bl... · Posted by u/nikodunk

baobun · 6 months ago

Really? Do you control the negativo17.org repo (just one example from akmods)?

https://github.com/ublue-os/akmods/blob/9946c17373b1a49e60a0...

https://github.com/ublue-os/bluefin-lts/blob/84cac6e9a063ec5...

How about jreilly1821? Looks like nothing's really preventing them from sneaking in a malicious version of glib2..

https://github.com/ublue-os/bluefin-lts/blob/84cac6e9a063ec5...

jcastro · 6 months ago

I would be in trouble if I didn't trust jreilly1821 since he's one of the Bluefin maintainers. And the nvidia binaries come from an nvidia employee.

jcastro commented on Bluefin LTS Is Released docs.projectbluefin.io/bl... · Posted by u/nikodunk

NewJazz · 6 months ago

Hmm so you don't use rpm-ostree? Or ostree at all? Sorry I'm just having trouble finding some of the technical implementation details, seeing a lot of details on the UX though.

jcastro · 6 months ago

ostree is the library that rpm-ostree and bootc share. However bootc is moving over to composefs as a backend. This effectively makes it distro agnostic and there are communities forming: https://github.com/bootcrew

Fedora still uses rpm-ostree, when you do an update it's pulling from an ostree remote served from a server. bootc replaces that with just an OCI registry. We ship the `rpm-ostree` binary on the systems still. It's still used for things like adding kernel boot arguments.

Here's their diagram: https://bootc-dev.github.io/bootc/filesystem-storage.html

Generally speaking new users can skip the rpm-ostree parts and just start with bootc. I am not an expert in this, there's a rust library in there somewhere. Hopefully someone can help fill in the blanks.

jcastro commented on Bluefin LTS Is Released docs.projectbluefin.io/bl... · Posted by u/nikodunk

baobun · 6 months ago

Mostly agree.

I think they have some improvement to do on supply-chain though. A lot of random COPRs and kernel patches pulled in from various random third- and first party repos that I think should get consolidated before I can consider it mature and really ready for prime time.

Similarly it would also be nice to see end-to-end builds being reproducible locally. (Things are currently hardcoded to github.com or tied to GitHub Actions in a few places. The patching required for that is nothing crazy - Good First Issue material :))

jcastro · 6 months ago

For Bluefin LTS we're in control of all the 3rd party repositories we use. We depend on EPEL but so does everybody else. I am unaware of any kernel patches that we are shipping since we ship the default CentOS Stream kernel and the optional hwe kernel ships CentOSs' kmod kernel.

jcastro commented on Bluefin LTS Is Released docs.projectbluefin.io/bl... · Posted by u/nikodunk

rvrb · 6 months ago

As someone quite happy with a vanilla Fedora Silverblue install on both my desktop and laptop, can anyone explain why I would rebase to Bluefin instead? It seems like there must be technical merit to the Universal Blue spins beyond adding preinstalled software/configs, but I can't find it, despite looking.

jcastro · 6 months ago

Co-maintainer here. I dogfooded Silverblue for about 2 years before deciding to do this. Initially Bluefin was just a "fix me script" that did the usual bits. When bootc came around this let me put that script in GitHub CI and then just consume the fixes I want. A few of us started to do this and then since a bunch of us were kubernetes nerds we defaulted into "let's make this together."

Here are some of the changes:

- We add all the codecs, and drivers in the build step so the user never has to care.

- We turn on automatic updates by default, these are silent

- We remove Fedora's broken flatpak remote and go full Flathub out of the box

- We handle major version updates for you in CI, there's no "distro release day" update that's just a normal update that day

- Since we use bootc it's easy for people to FROM any of our images and make a custom build, and we ship a template for anyone to do so: https://github.com/ublue-os/image-template

- You can turn on "developer mode" which gives you vscode with devcontainers, docker, incus, etc in addition to podman.

- We integrate homebrew out of the box for package management for the CLI, flathub handles the GUI packages - we don't want to be a distro, in this world the base image is a base image and my relationship is with brew and flathub. I don't need or want to have a relationship with my OS.

- We gate kernel versions to avoid regressions, so we can avoid certain releases or "ride it out" until fixes are published.

- We ship [Bazaar](https://github.com/kolunmi/bazaar) - which is a flatpak only store designed for performance. Since the OS is a different layer we can throw away all those packagekit jankfests and start from scratch.

As for the desktop, I worked on Ubuntu for about a decade and wasn't happy with the direction Ubuntu was going at the time. Fedora had rpm-ostree/bootc but didn't know what to do with it so they were just sitting on the tech. So I just combined them, the desktop has an Ubuntu-like layout and vibe.

The clear benefit is that you have one image for everything, whereas local layering in Silverblue doesn't really make sense to me anymore, if you want to handle a bunch of local packages just use a traditional distro. Because doing that in Silverblue breaks just as often as it does in package distros. Pure image mode is the strongest benefit. It's 2025 I refuse to do "post installation crap" that should be automated, bootc lets me do that!

More info here since I'm leaving out a bunch of stuff: https://docs.projectbluefin.io/introduction