pull down to refresh

bluefin - Next gen Linux workstation, reliability, performance, & sustainabilitygithub.com/ublue-os/bluefin
529 sats \ 3 comments \ @kepford 23 Jul devs
For end users it provides a system as reliable as a Chromebook with near-zero maintainance. For developers, a powerful cloud native developer workflow.
I have too many balls in the air right now to try this out but I am tempted...
Anyone tried it?
write
preview
related posts
270 sats \ 2 replies \ @freetx 23 Jul
I've used it for awhile. Things have really gotten more interesting that they are now switched to bootc over rpm-ostree (long story but bootc sorta kinda uses rpm-ostree anyway but its more hidden).
Anyway, I was an early Silverblue user, then when back to vanilla Fedora. When I saw the Bluefin project in late 2023 I jumped onboard since they really fixed / sorted out many of the pain points I had with Silverblue. Plus their graphics are awesome.
However with the rise of bootc, I now just build my own OS using Containerfiles (Dockerfile) + podman (docker). (although I do miss their slick graphics / icons).
Once the resulting image is built, I push it to a container registry (I'm using gitea for that), then my laptop and desktop can "podman pull" the image to install it.
Makes upgrades really smooth. I basically have a bash script that does a weekly rebuild / push of the Containerfile so I still get timely updates but not constantly spammed with updates constantly. If an update goes bad, you can just boot into the previous image and you are back to where you started from.
reply
101 sats \ 1 reply \ @kepford OP 23 Jul
If an update goes bad, you can just boot into the previous image and you are back to where you started from
This to me is the biggest selling point for me and the workstation usecase. I'll have to take a look at bootc.
reply
265 sats \ 0 replies \ @freetx 23 Jul
Yes, there are two main benefits: (a) atomic updates that can be rolled back, and (b) Both your OS and the apps / containers that run on the OS uses the same tooling (ie. podman).
Most of the servers I roll-out now are bootc versions and all applications I container-ize. That means that composing both the OS and the apps on the servers all uses same workflow.
Example (toy example) of a simple server:
FROM quay.io/fedora/fedora-bootc:latest

# Install basic server packages
RUN dnf install -y \
    cockpit \
    firewalld \
    openssh-server \
    bash-completion \
    git \
    sysstat \
    wget \
    && dnf clean all

RUN useradd -m -G wheel core && \
    echo 'core:password123' | chpasswd

RUN systemctl enable sshd firewalld cockpit.socket

CMD ["/sbin/init"]

LABEL containers.bootc=1 
LABEL ostree.bootable=1 
LABEL bootc.build.iso=1
Then you can build it with something like:
sudo podman build -t "myserver" .
Then you can create your qcow2 image for use in qemu-kvm or even build an installable iso with bootc-image-builder, like:
sudo podman run --rm -it --privileged -v $(pwd)/output:/output \
  quay.io/centos-bootc/bootc-image-builder:latest \
  --type qcow2 \
  myserver

sudo podman run --rm -it --privileged -v $(pwd)/output:/output \
  quay.io/centos-bootc/bootc-image-builder:latest \
  --type iso \
  myserver
reply