Fedora Strategy 2028: February/March Planning Work and Roadmap 'til Flock

I’ve been on Silverblue for 2 years now. Calling 38 a Beta is off putting IMO. The accessible info from places like Fedora Magazine that pop up in searches for silverblue is old. SB feels kinda stale from my raw perspective.

I’ve been playing with offline AI stuff for the last few weeks. The documentation path to get nvidia drivers running is all over the place IMO. Leading would be a seamless path to secure boot regardless of GPU with no hassle integration. The integration of secure boot was one of the main reasons I chose to try Fedora a couple of years ago.

Adding native support for offline AI tools like Oobabooga, Automatic1111/Stable Diffusion, and KoboldCpp, or making an alternative would be leading right now. The first two are just gradio. Most of the models people are using from Hugging Face need a llama.cpp file that requires compiling from source to use the latest and larger models. The easiest checkpoint models in practice use a llama.cpp file packaged with pip and it doesn’t appear to be well maintained. The last update was 2 months ago. Arch just added direct support for the proper llama.cpp file in the AUR a week ago. There are also Nix flakes around for some of the more feature rich GUI’s. This space has research papers dropping weekly. It is ripe for someone in the linux space to lead IMO. The biggest potential here is for basic assistance at the moment, but mixing current capabilities, with langchain to add large blocks of text to a model’s context will make individualized education possible and accessible on enthusiast level hardware soon. This is what I am trying to get working right now on a year old laptop with a 3080Ti. Individualized education should be possible already, but no one has really streamlined the FOSS toolchain.

Within a week I have made a mess of Workstation despite trying to use distrobox and conda trying to get various AI tools working from source.

Silverblue and nvidia didn’t feel like a good move for me. I’ve come across issue 272 since then, and probably would have been fine.

Distrobox is way better than toolbx, but it still makes a mess of the filesystem and configs everywhere. IMO there is no comparison between these two. If I ran Silverblue again, I would just use distrobox without a doubt.

I don’t think SB completely solves the issue I’ve had with containers for AI tools. I really want a way to be able to delete the container and have the option to remove everything it ever created. This has me strongly considering trying out Nix.

AI is a sketchy space for what open source really means. As a user, the freedom to ask an offline AI what some command is doing without man pages or how to do some task based on plain English is awesome. So long as expectations from outputs are kept in check with skepticism, this is a massive game changer. It makes an operating system an order of magnitude easier to navigate and learn.

If you haven’t seen the interview of Yann LeCun (former Bell Labs guy) where he makes the case for open source AI from a couple of months ago (YT), its a good watch. Someone needs to lead this space within FOSS.

Check out the -h flag for distrobox if you want the container data to remain explicitly seperate from your default ~ directory. Toolboxes are great as interactive CLI for systems, but for deploying stacks of stuff you’re probably better off using podman with deployment yaml files directly! It’d be cool if we could find a way to share these amongst the community.