I'm booting and running Haiku on my Thinkpad. It's a from-scratch workalike of BeOS, and able to run Be software. Though, frankly, Be software is totally 1990s, so a lot of Linux software written for Qt has been ported to Haiku.
In the end I wound up with basically the same application software as on my Debian desktop, except running on Haiku instead of Linux. Haiku is noticeably snappier and more responsive than Linux+X+Qt+KDE, though.
In late September or early October 1996, Fry's Electronics places a full page promo ad on the back of the business section of the San Jose Mercury News for OS/2 4.0 "WRAP [sic]" in 256 pt font in multiple places. Oops!
Runs on modern Intel/AMD CPUs, but limited to 32-bit and low RAM limits. The OS/2 source is owned by IBM and IBM won't talk to you unless a number with 8 zeroes is involved.
Nah, that time has passed and there's not much to miss from the base OS. What would be interesting is for IBM to publish the source to the Workplace Shell and the underlying SOM code so it might get a new life running on one of the free *nixes.
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.
Hi I'm jreilly1821, I made those COPRs for Bluefin LTS. I guess I could put something malicious but you can see that they are all just packages from Fedora DistGit. I'm not sure what your preference would be? I think distros have mystique given to them that is misappropriated. At the end of the day they are mostly middlemen packaging someone else's code.
Bootc is and will change things, images will be tested as an integrated experience and we'll continue to strive to pull from as far upstream as we can.
Negativo17 is Simone, an NVIDIA employee who has been instrumental in packaging nvidia drivers for linux for years. I don't know for certain, but I wouldn't be suprised if they are also doing the official packaging for nvidia drivers as well. Needless to say they are very trusted and a known entity in the Linux community
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.
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!
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.
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.
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.
Boots currently relies on OSTree, you use OSTree enable base images. But the work is well on its way to transition to composefs which uses kernel native tech to replicate the features need from OSTree, so any systemd enabled distro can become bootc-able, for a bunch of example see: https://github.com/bootcrew
Co-maintainer here. When I saw one of these I immediately want to run Bluefin on it.
In spirit I would love to support this, someone with one of these would need to PR in support, but it's usually taking the enablement instructions from NVidia and putting it in a dockerfile. Bluefin is already working well on on the Ampere ARM workstations that System76 sells. Getting it on one of these would be awesome.
You can "just use" KDE too. The default are actually less insane than gnome, it's easier to use.
The idea that more functionality makes software less usable makes no sense to me. No, it's more usable.
Its like when people argue that iOS not allowing anything other than safari is a good thing.
Okay... how? Because if you like safari, nothing changes for you. You just keep using it. You wouldn't even be able to tell.
Similarly, if you like KDE you can just... use it. You don't actually have to change anything. There's no gun to your head. If you're the type of person who just takes software and uses it, then great - you don't need Gnome for that. KDE is actually better at that, IMO.
Hi Jeff, I'm a linux ambassador for Framework and I have one of these units. It'd be interesting if you would install ramalama in fedora and test that. I've been using that out of the box as a drop in replacement for ollama and everything was GPU accelerated out of the box. It pulls rocm from a container and just figures it out, etc. Would love to see actual numbers though.
This is my impression - if you explicitly don't want to use toolbox or devcontainers I don't think you're on Bluefin's happy path at all, and the maintainers don't seem concerned enough by that to improve other experiences.
No but Bazzite DX is almost done so we can start working on Bazzite GDX soon, which is going to be our game dev image. Though hopefully as more things become flatpak native ideally someday the idea of specialized images won't be so necessary.
There's also https://github.com/gomuks/gomuks/tree/master for golang folks (although it's currently doing a transition to being a web client... and then back to being a TUI apparently)
> An OSTree based atomic system is pretty close, although there is some added complexity.
The author mentions this as well but there's no details there. We've been shipping chromeos-style images with universal blue for over 4 years and the ostree parts are invisible to end users. What do you feel takes away from the user experience?
Thanks for your work by the way, I'm a happy uBlue (Bazzite) user.
I think my main concern is something like a known OSTree design issue around UID/GID drift, there was a bug that was partly fixed in 2023 but the issue comes from OSTree assigning known UIDs from the deployment once created, but this may not map to the proper UID on the system the deployment is being blasted to. You can get improper ownership out of this.
Not something I've ever encountered myself, but if I were developing an embedded device it seems like one less thing to worry about.
