Comparisons with dedicated distributions

RF Swift and the dedicated distributions

This page is not a contest. Dedicated distributions and RF Swift solve different problems, and they combine well. There are two ways to get an RF and hardware lab with RF Swift: complete the distribution you already run (Kali, Parrot, Pentoo, BlackArch, DragonOS), or start from a plain, lighter system (a minimal Arch, Debian, Fedora or Ubuntu, a Mac, a Windows laptop, a small board) and let RF Swift supply the tools. The table below shows where each approach stands on its own; the sections after it show how to use them together.

The model behind the dedicated distributions comes from the late 1990s live CDs: one machine, one system, every tool preinstalled. It carried this field for twenty-five years and it still does a lot of things right. What changed is what a lab is expected to be. RF Swift is what that same idea looks like in 2026, and it is built to run on those distributions as happily as next to them.

With RF Swift’s container and Nix engines, each engagement runs in its own isolated environment. You can experiment freely, knowing that a broken dependency or conflicting library won’t cascade across your entire system.

Pentest Distributions includes Kali Linux, Pentoo, Parrot OS, and similar security-focused operating systems.

What a dedicated distribution gives you, and where RF Swift completes it

Distributions like Kali, Parrot, Pentoo, BlackArch or DragonOS are good at what they were made for, and there are cases where they stay the better base. RF Swift is built to sit on top of them, not to argue with them.

Where they win

• Everything is there after one install. Boot, plug the radio, type the command. No engine, no image, no device mapping to learn.
• The kernel is part of the package. Drivers, realtime patches, kernel modules and firmware are integrated and tested together. A container still runs on your host’s kernel.
• Full hardware access is the default. USB, PCIe cards, Wi-Fi monitor mode and GPUs need no passthrough, which matters most on a Windows or macOS host where a VM sits between the tools and the hardware.
• Made for a machine you dedicate. A lab PC or a burner laptop with nothing else on it is exactly their use case.

Where they run short

• You take everything to use one thing. Trying SDR++ or one new GNU Radio module means installing a distribution of tens of GB, or a VM of that size, and keeping it updated.
• One system, one state. Tools share libraries and Python versions. An upgrade for one can break another, and the fix is a snapshot or a reinstall; there is no per-tool rollback.
• Your own OS goes. A partition, a dual boot or a VM, and a context switch every time you go back to email, notes and the report.
• Hard to reproduce. “Works on my install” is not a build recipe. Colleagues, CI and next year’s you get a different system after the first upgrade.
• Few architectures. Most are x86_64 first; ARM64 boards and RISC-V are partial or absent.
• The attack surface is the whole image. A monolithic tool set ships every vulnerable library it contains, and nothing tells you which.

What RF Swift adds

• Containers, per task. rfswift container create -i rfid -n badge gives a tested toolbox for that job, from a digest that is identical on every machine, on Linux, macOS and Windows, on x86_64, ARM64 and RISC-V64. Delete it when the engagement ends.
• Nix, per tool. rfswift env run sdr_light sdrpp fetches that tool’s closure (prebuilt for standard packages, built once for RF Swift’s patched ones) and runs it natively with USB, audio and OpenGL, on a laptop that has no container engine. rfswift env install <package> adds one package, pinned, with rollback. A tool costs its closure, not a distribution.
• Native, and isolated when you want it. On Linux and macOS the same native environment runs inside a jail with --isolate (bubblewrap, or Seatbelt on macOS): your home and the host filesystem disappear, the radios, the display and the network stay. A distribution cannot give you that without a VM.
• Your OS stays. Both run next to your desktop, and the Workbench keeps the engagement’s notes, findings, captures and reports with the target.
• You know what you run. rfswift audit tells you the CVEs and the attack surface of what you are about to use, so a large tool set is a conscious choice, not a silent default.
• The gaps are stated. What a container cannot bring from the host kernel, and the few tools that do not build on an architecture, are written down as known limits rather than hidden.

How to install one tool, one image or one environment: Installing software. How the caches make the second machine fast: Caches and fast delivery.

Two ways to get the lab

Complete the distribution you already run

None of this asks you to leave Kali, Parrot, Pentoo, BlackArch or DragonOS. The strongest setup is not one or the other: it is the distribution you already know with RF Swift on top, and the Nix engine is what makes that combination work without a container engine, a VM or a single change to the distribution’s packages. Your distribution is the operating system. RF Swift is the lab you carry from one engagement to the next.

Why the pair beats either alone

• The RF stack is where a distribution is weakest, and where RF Swift is strongest. A distribution’s GNU Radio is whatever its release froze, and out-of-tree modules are the first casualties of every version bump; srsRAN, OCUDU, the patched SDR forks and the telecom stacks are simply not in the repositories. RF Swift brings 50+ GNU Radio modules that build and are tested, the 2G-to-5G stacks, RFID, automotive and hardware sets, pinned to a revision. Kali keeps the general pentest tooling; RF Swift brings the radio side to the same laptop, both current.
• One environment per engagement, instead of one shared state. On a distribution, two clients’ captures, wordlists, credentials and half-installed tools live in the same home. With RF Swift each engagement is its own environment or container, with its own workspace, deletable when the report is delivered and exportable as one archive when a colleague takes over. The Workbench keeps notes, findings and evidence with it.
• Try anything without breaking what you rely on. Installing a bleeding-edge tool on the distribution can take down the ones you depend on tomorrow morning. In a Nix environment it is pinned, updates are transactional and env rollback undoes them; rfswift env run tries a tool with no footprint at all. Nix never fights the distribution’s package manager: a tool that needs Python 3.14 or Boost 1.90 carries its own closure while the distribution keeps its versions.
• Untrusted tools stop being a risk to the whole laptop. A pentest laptop carries client data and SSH keys next to tools downloaded from anywhere. --isolate runs an environment in a jail that hides your home and the system while the USB radio, the display and the network keep working; rfswift audit tells you the CVEs and attack surface of a tool set before you use it. A distribution has no equivalent short of a VM.
• The same lab on every machine, and on the one in the rack. An environment is a flake revision, an image is a digest: the DragonOS box in the lab, the Kali laptop and a colleague’s Mac run the same tools, and the remote agent lets the laptop drive the lab box from the Workbench. “Works on my install” stops being an argument.
• It costs what you use, and it leaves no trace. One tool costs its closure, not a second VM or a dual boot. Everything RF Swift installs lives in /nix/store and ~/.rfswift/nix/, so rfswift env remove and rfswift env gc take it away without a line changed in the distribution’s package database.

# On the distribution, as your user
curl -fsSL "https://raw.githubusercontent.com/PentHertz/RF-Swift/refs/heads/main/get_rfswift.sh" | sh   # pick Nix, Podman, Docker or several
rfswift host setup --engine none --nix yes                          # or later: Nix only, nothing else changes

rfswift env run sdr_light sdrpp                                     # one tool, natively, with the distribution's display and audio
rfswift container create --engine nix -i sdr_full -n survey         # the whole SDR stack next to the distribution's tools
rfswift container create --engine nix -i rfid -n badge --isolate    # jailed: the tool cannot read your home or the system
rfswift container create -i telecom_5G -n gnb                       # a container, when Docker or Podman is there

A container engine is optional; rootless Podman is the least intrusive one on a shared box. Whichever you pick, the distribution stays exactly as it was: RF Swift only fills in what it did not ship.

Or start from a plain, lighter system

The other route is a system that ships nothing security-specific at all: a minimal Arch, Debian, Fedora or Ubuntu, a Mac, a Windows laptop, a Raspberry Pi 5 or a RISC-V board. RF Swift turns it into the same lab, and the result is lighter than any dedicated image, because you install the base system once and then only the tool sets you use.

# Arch (pacman package), Debian and Ubuntu (deb), Fedora (rpm): one installer, or the package by hand
curl -fsSL "https://raw.githubusercontent.com/PentHertz/RF-Swift/refs/heads/main/get_rfswift.sh" | sh
rfswift host setup                                        # udev rules, Podman or Docker, Nix, the jail: each step asked
rfswift container create -i sdr_light -n radio            # a container...
rfswift container create --engine nix -i rfid -n badge    # ...or a native environment, same command

• A base you chose. Your window manager, your dotfiles, your update cadence. RF Swift does not care which Linux it is, and the same commands work on macOS and Windows.
• Only what you use on disk. The base system plus the images or closures you asked for. A laptop set up for SDR and RFID work carries those two sets, not thirty tool categories.
• The same tools as the Kali user next to you. Environments are pinned to a flake revision and images to a digest, so a team can mix Arch, Kali, macOS and a Pi in the lab and still run identical tools.
• Quick to rebuild. A reinstalled laptop is back in minutes: install RF Swift, then pull again or restore the .rfenv and image archives you exported.
• Small boards included. arm64 and riscv64 images cover the Raspberry Pi 5 and RISC-V boards, where dedicated images are rare or absent, and the Nix engine runs on arm64 too.

Both routes end in the same place: the same pinned environments, the same Workbench, the same audits and the same remote agent, on whatever base you prefer.

Use Case Scenarios

Questions or Feedback?

Next Steps

Dive right into the following section to get started: