j0rge

She only suggested a small “news channel” built into the OS.

Yeah we're working on that here: https://github.com/ublue-os/bluefin/issues/1485

The failure with secure boot afterwards is news to me, we'll investigate, thanks!

Did you experience the Silverblue issue on a ublue image? We mitigated that last month so you should only have one problem or the other, not both.

there are a lot of tools included that are new to me, despite being a cloud-oriented developer.

Interesting! What tools do you commonly use?

We probably won't (we're not looking to grow that much anymore), but I think someone should definitely take either portainer or the proxmox stack and just slap it on top a CoreOS image with a user friendly installer and make a killer SMB server.

Here's the repo: https://github.com/ublue-os/bluefin and the intro doc outlines some of the features. We include all the codecs from rpmfusion and use negativo17 for the nvidia drivers.

Yeah checkout ucore, which is derived from CoreOS instead of Silverblue: https://github.com/ublue-os/ucore

What kind of printer? What's the name of the package that got it working? We can add printer drivers pretty easily.

Hi! Universal Blue co-maintainer here, here's the TLDR. You've got the basic descriptions right, "Universal Blue" is mostly the parent organization that holds everything in github.

We take Fedora's Atomic OCI images and customize them for different use cases (Aurora, Bazzite, and Bluefin) and then publish base images so people can make their own versions of whatever they want. So if you wanted to take Silverblue, Kinoite, and make your own custom image you can mostly just grab whatever you want and shove it into an OS image. Bluefin started off as a "fix me" script for Silverblue that added all the stuff I wanted and then once I was shown what Fedora wanted to do with it the natural progression was to just make it a custom image. We just released 3.0 a few minutes ago actually!

Basically in Fedora 41 the tech will become more widely available with official OCI base images and better tooling. We just decided to start way earlier in the process so we could get all the automation out of the way, build a community, get familiar with it, etc. Happy to answer any other questions you may have!

Flameshot is 3.6MB on disk according to flatpak info org.flameshot.Flameshot

ublue co-maintainer here. I go over a bunch of the reasons here: https://www.ypsidanger.com/homebrew-is-great-on-linux/

Namely we needed a way to complement Flatpak and brew was a natural fit. It's an ecosystem reason not a technical one. It has everything we need and a good deal of Bluefin's target audience are already using it on mac. So for us it's an easier lift to just add homebrew and move on to larger problems.

Plus it's nice that they're working with the openssf to secure the supply chain pipeline, and it's nice that everything is in github where we can inspect it, use the same tooling we use for the OS, etc.

Use the distrobox assemble command, that'll let you have an ini file with all the stuff you want and then when the assemble command runs it'll remake the entire thing. Then just toss the assemble in cron and you'll always have a fresh container with your exact setup.

Immutable is new to me,

It's best to ignore the whole "immutable" thing as most of the discussion around that is conflating a bunch of other concepts and it just leads to confusion. When it comes to things like host daemons, these systems are designed to deploy daemons the same way as cloud servers, so for mpd it'd be running the service as a container. A quick search of /r/selfhosted shows some options, but I'm on the road so don't have time to recommend a specific image, but generally speaking anything server related is done via containers.

I use the 1password firefox plugin for my password management. There still isn't a flatpak portal that allows flatpaked password managers to talk to flatpaked browsers, that can be a pain point to some people depending on your use case.

As far as how you manage your distroboxes, that's up to you. We differ from fedora here where they default to "just use toolbox" for everything, whereas we default to "just use brew" for everything. I keep an ubuntu and fedora distrobox in case I need to check something from those distros, and arch is a popular choice. If you're happy with your existing distro but want the reliability of atomic updates then this is a good option. For most new users I recommend not caring about distrobox, most of that stuff is for developers or people that know how to linux already and know exactly what they want.

Also, are there any issues with upgrading a distrobox to a new major release over time?

Containers are designed to be ephemeral, so that you can recreate them on the spot when something goes bad. So I never upgrade boxes, I recreate on the spot using my custom configs. That way I have the same experience on all my machines and when something breaks I don't lose any time setting things up again. Distrobox assemble is awesome for this: https://github.com/89luca89/distrobox/blob/main/docs/usage/distrobox-assemble.md

So far my mindset has been make sure I don’t layer anything, but maybe some things like mpd do make sense to layer?

I don't really layer anything, I use everything via containers or brew. Generally speaking some people might have a few things they have no choice to layer - a good example is a VPN provider that doesn't provide a wireguard config for network manager and instead you have to layer some 3rd party app. But it's also not the end of the world, updates will take longer but 99% of the time I'm asleep when that happens or it happens in the background and is transparent to me. The more you layer the more maintenance you'll have to do when you do upgrades, so if you end up adding a bunch of 3rd party repos it'll behave the same way as a traditional distro and likely need to be babysat.

The system will update all your boxes and your brew packages as well, so whichever one you use you'll never be out of date. Hope this helps!