DEV Community: Frank Kmiec

Bluefin (Atomic) Linux is for Tinkerers

Frank Kmiec — Mon, 12 Jan 2026 19:45:52 +0000

During downtime over the holidays, I like to tinker with computers. Given this habit and knowing how often I break my Linux system in the process, I was pretty excited when I came across Distrobox, which lets you run other Linux distros in a container, protecting your host system from whatever shenanigans you want to try. It recommended the Podman container engine over Docker and that was another exciting tool to learn about. This was going to be fun.

Then, ironically, while struggling to install a recent version of Podman on Ubuntu 24.04 (not available in ubuntu repos), I borked my system!

Well, shoot. Now what?

I had learned that Distrobox and Podman come from the Redhat / Fedora Linux community and are heavily used in so-called immutable / atomic distros. I had seen some articles and videos by Jorge Castro about Fedora Silverblue, an atomic Fedora distro, and his Ubuntu-flavored customizations. I'm a longtime Ubuntu user, too, so that made Fedora more possible in my mind. I had also learned about bootc, a tool promising to underpin future immutable distros by using container technology to build, distribute, install and upgrade OS images on bare metal hardware. As it turns out, Jorge is one of the developers of a new bootc distribution based on Fedora Silverblue called Bluefin.

At this point, I had to reinstall the OS, but I would run the same risk of borking the system trying to install Podman if I reinstalled Ubuntu. I decided to give Bluefin a shot.

Installation

Simply put, it was the easiest installation I've ever experienced. Up and running in about 10 minutes. No hardware issues. Everything just worked. As an aside, I decided to change up my dual-boot and move Windows to a separate drive. It took more than 3 hours from the start of the install process to having a working system (no bells and whistles ... just a functional display, a user folder matching my username, and Chrome installed).

It took about 5 more minutes to apply Secure Boot and whole-disk encryption with TPM unlock using user-friendly ujust commands included with Bluefin (after 20 minutes of googling and nervous flip flopping). Google TPM setup on Linux if you want a sense of the complexity that drives most of us to run less securely. This is the security I want if my travel laptop is stolen.

Of course, as a developer, I wanted to apply Bluefin's devmode that brings in a suite of modern development tools including Podman and Distrobox, the very tools that sent me down this path in the first place. One ujust devmode command and a reboot later and I had a powerful developer workstation.

Rules of the Road

Bluefin is opinionated and aims to keep system and user separate in order to ensure a stable system. This is where the immutability comes in. Only the /etc and /var directories are writeable. Before you write this off as a non-starter, know that most other system directories you might need to interact with to configure and run the system are linked to sub-directories in /etc and /var.

/home -> /var/home
/usr/local -> /var/usrlocal
/opt -> /var/opt
/mnt -> /var/mnt
/media -> /run/media

This enables you to add systemd unit files and rules, install software in /usr/local, update /etc/fstab and /etc/hosts, for example.

Coming from Ubuntu and using the apt package manager, I expected to have to learn the Fedora dnf package manager, but as it turns out, Bluefin recommends the following alternatives, depending on what you want to install:

Flatpak: For GUI applications
Homebrew: For CLI and TUI apps
Distrobox / Toolbox: For apps or binaries not available via Flatpak and Homebrew
rpm-ostree: For low-level packages needed on the host system

This might seem like a lot of complexity compared with apt install this and apt install that, but the result is clean separation and ease of maintenance.

Flatpaks are isolated and can be easily removed without impacting the system.

Everything installed by Homebrew is under /home/linuxbrew/.linuxbrew, clearly separate from the system packages and easily removed without incident.

Containers exist to isolate filesystems and processes, so Distrobox is your ultimate tinkering playground. Install anything from any distribution and export it to make it run as if installed on the host system. If you break your container, or just don't like what you installed, you can delete it easy peasy and your system will still be working like new.

Finally, rpm-ostree gives you the means to install whatever packages you need as a layer on top of the host filesystem image managed by Bluefin. As an example, I installed the envycontrol package to be able to turn off the nvidia gpu in my laptop to save battery.

Now, rpm-ostree, in particular, gives you the ability to bork your system. And this is where the image-based nature of Bluefin is the ultimate backstop.

Updates and Restoring When Things Go Wrong

Bluefin uses OCI images and bootc to enable image-based updates that are staged and applied automatically after a reboot. That means packages aren't updated piecemeal with fingers crossed. Instead, a tested stable image replaces the prior tested stable image and you are, in most cases, blissfully unaware. Even more magical, it does this without interfering with your apps, configurations and customizations thanks to rpm-ostree and the clean separation described earlier.

Now, every user's combination of hardware, packages, apps and configuration is unique, so it's still possible that an update could break your system, or more likely that you add some ill-advised package or config via rpm-ostree and break it yourself. However, in that unlikely event, rolling back to a working system is as easy as selecting it from a menu at boot time. Amazing!

Now, restoring the immutable system doesn't restore your personal data if lost due to, for example, a drive failure. So, having a backup strategy is still important, but the built-in rollback for the host system makes having a workable backup strategy a lot easier.

Implementing a backup strategy short of block device replication is an exercise in hard choices. What do I backup? Where is all the important stuff located? How do I reapply what I backed up when I'm ready to restore the system? Is it a different process depending on how it got broke?

With Bluefin, getting back to a current working system is a reboot. After that, I keep a list of my flatpaks, homebrew installs, rpm-ostree layered packages, the few specific system customizations I've made to /etc/fstab and /etc/hosts, for example, and backup /home. (NOTE: This will get easier still with new tools and options that I'm still learning from Bluefin)

Tinkering

With so much thought having gone into the stability and recoverability of the system, Bluefin (and ublue, in general) gives me a lot more confidence about tinkering with new software.

Ideally, I'll find what I'm looking for available as a flatpak or via Homebrew, which are nearly certain to be problem-free. If not, I can launch a Distrobox container and install just about anything from any Linux distro. I might break the container, but I won't break my system.

If developing software, I'll use a devcontainer launched in VS Code and any system dependencies will be installed in the container, leaving my host system conflict-free.

Finally, infrequently, like when I'm experimenting with a whole new paradigm in operating systems, some things will need to be installed on the host system. As noted above, rpm-ostree gives me that option and the confidence of knowing that undoing any damage is a reboot away.

This is going to be fun!

Goscript: Go For (go-pher?) Scripting

Frank Kmiec — Tue, 15 Apr 2025 16:29:44 +0000

Scripts are short bits of code typically written to automate a series of otherwise manual steps or accomplish a small task. With that focus on quickly getting some task done, a compiled, strongly-typed, multi-threaded language might not be your first thought, but Go has a lot going for it when it comes to scripting. With a bit of support, it can be a compelling choice.

Using Go for scripting isn't a new idea. It's attractive because Go has a fantastic standard library and a large ecosystem of third-party packages, the compiler is very fast and a tool like go run almost makes it feel like an interpreted scripting language. And, as a natively compiled language, Go is fast. Some say Go is too verbose for scripting, but I'll take "easy to read and understand" over "cryptic but powerful" every time.

Goscript is an opinionated tool aimed at making scripting in Go more convenient. It was inspired by bitfield/script, which brings functionality similar to Unix pipes to Go. By opinionated, I mean that Goscript embraces Go modules (rather than GOPATH with modules turned off) and uses a dedicated module project for your "scripts". It asks you to update your PATH as part of the setup so that your scripts can be immediately available as system-wide commands. It enables treating Go code like a local script with --exec and shebang options, but encourages reuse by letting you name your commands and then saving them, together with source, in your dedicated Goscript project. Finally, its many options are designed to make the project fade into the background and make writing scripts in Go convenient and easy like your favorite scripting language.

Goscript Features:

Execute simple go code directly on the command line with automatic imports for stdlib and your most-used third-party packages
Execute Go source files directly with the --exec option or by including the Unix shebang
Compile Go code into named binaries for repeated use, enabling you to build up a library of custom commands
Automatically "go get" missing modules required by imports (and remove them when the code importing them is deleted)
Organize all of your Go "scripts" in one project, accessible system-wide
Generate a template source file for your next Go script
List, edit and export sources and binaries for existing commands
...

Of course, implied in the term "script" is the idea that the code is relatively small and uncomplicated. If you need multiple source files or a complex build process, you will want to create a dedicated Go project.

Installation

Do go install github.com/fkmiec/goscript@latest followed by goscript --setup help and follow the instructions.

How It Works

The goscript executable will wrap any code specified on the command line with a main function and apply any specified imports before compiling and optionally executing the code. If no name is given, temporary files will be created and cleaned up. If a name is provided, then the binary file will be [project folder]/bin/[name] and the source file will be [project folder]/src/[name].go.By adding the [project] and [project]/bin folders to your PATH environment variable, the goscript command can be used anywhere on your system and the resulting binaries you build with it will also be immediately available to execute like other system commands (such as ls, cat, echo, grep, etc.).

If the --file option is used, then Goscript will assume the file is a complete Go source file and build it as is, automatically downloading missing modules required by imports. The --exec option can be included to run it immediately. On Linux and Mac, a shebang at the top of a Go source file works similarly. The --template option can print out a skeleton source file as a starting point, including a shebang line at the top in case your aim is to produce a locally executable script. While the shebang is incompatible with Go, Goscript automatically strips it out before compiling.

Nearly every other Goscript option is intended to let you work with Go code where you are and put the project and modules back of mind.

Let's See Some Examples

We'll use toy examples to keep things simple and demonstrate some features of Goscript. An inaugural "Hello World!" can be executed directly on the command line like this:

> $ goscript --exec --code 'fmt.Println("Hello Goscript!")'    
Hello Goscript!

Similar to go run, Goscript produced a binary and immediately executed it. Unlike go run, however, Goscript automatically supplied the package declaration, imports and main function.

Adding the --name option will save the binary and source files to the project, which you can see with the --list option.

> $ goscript --exec --name hello --code 'fmt.Println("Hello Goscript!")'    
Hello Goscript!

> $ goscript --list                                                       
hello

Using --cat, we can see that the code was wrapped in a main function and the fmt package was imported for us. Using the --code option, Goscript will automatically add imports for packages in the standard library and any packages listed in the project's imports.json file. The imports.json file also enables specifying a different package alias (e.g. "re" rather than "regexp").

> $ goscript --cat hello                                                 
#!/usr/bin/env -S goscript
package main

import (
    "fmt"
)

func main() {
    fmt.Println("Hello Goscript!")
}

Note also that --cat added a shebang (#!/usr/bin/env -S goscript) to the top of the file in the event your intent was to execute locally as a script. More on that later.

Since the [project]/bin folder is on the PATH, you can execute the compiled command directly.

> $ hello                                                              
Hello Goscript!

The --cat option can also be used together with the --name option to copy an existing command to a new name.

> $ goscript --cat hello --name greet                                         
A copy of hello was saved as greet

If you use an IDE, such as VSCode, you are probably used to a high level of support when writing Go code. If you try to edit locally (ie. outside of your project), your IDE may not have the proper context to provide you that support. The --edit option enables you to easily open the command source within the project directory in your favorite editor.

> $ goscript --edit greet

We can then edit the file to take a command-line argument and recompile. You can recompile a specific command simply by passing the --name option, or all commands using --recompile.

> $ goscript --recompile                                                     

> $ greet World                                                               
Hello World!

If you prefer, you can --export the greet command as a script, complete with a working shebang line (similar to the --cat example shown above). This will also do a "soft delete" in the project, removing the binary but saving a copy of the source without the .go extension, making it effectively invisible to the Go compiler. That renamed source file will be shown if you --list commands, pointing out the option to --restore the command.

> $ goscript --export greet > greet.gs                                                                                                                     
> $ goscript --list                                                         
hello
greet (requires --restore)

We can modify the permissions on the "greet.gs" file we just created and execute it as a script.

> $ chmod 744 greet.gs                                                                                                                                  
> $ ./greet.gs Shebang                                                         
Hello Shebang!

If you need to use a package outside Go's standard library, there is a --goget option to pull it into the project. However, since Go's package convention is geared toward online repos (e.g. github), Goscript will often be able to automatically go get external packages that are imported, adding them to both the go.mod file and the imports.json file. Goscript will also run go mod tidy to clean up go.mod when using the --export or --delete options.

As an example, let's write a simple uppercase utility that imports the github.com/bitfield/script package. We can write this outside the project in a file called "tmp.go" (Note, the .go extension isn't required).

package main

import (
    "github.com/bitfield/script"
    "strings"
)

func main() {
    script.Stdin().FilterLine(strings.ToUpper).Stdout()
}

We can use --file and --name to import the code to the project with the name "upper".


> $ goscript --file tmp.go --name upper

> $ echo uppercase | upper                                                    
UPPERCASE

Executing the code demonstrates that the external package was added, but we can also view the updated go.mod file using the --dir option to reference the project location.

> $ cat `goscript --dir`/go.mod                                               
module goscripts

go 1.22.1

require (
    github.com/bitfield/script v0.24.1 // indirect
    github.com/itchyny/gojq v0.12.13 // indirect
    github.com/itchyny/timefmt-go v0.1.5 // indirect
    mvdan.cc/sh/v3 v3.7.0 // indirect
)

Likewise, the imports.json file now includes a mapping for "github.com/bitfield/script" to support automatic import with the --code option when using the alias "script".

> $ cat `goscript --dir`/imports.json                                        
{
    "script": "github.com/bitfield/script"
}

And, as you can see from that last example, bitfield/script makes it easy to write commands that can be combined in a pipeline just like built-in Unix utilities.

> $ ./greet.gs Pipes | upper                                                  
HELLO PIPES!

Conclusion

Scripting in Go is fun and powerful. Goscript can make it more convenient to use Go for scripts. To get started, visit the repo at https://github.com/fkmiec/goscript.