Professional workflows on Margine

Why Distrobox for proprietary tools (and not rpm-ostree layering)

DaVinci Resolve, BricsCAD, Maya, AutoCAD, MATLAB: vendors ship their own .deb / .rpm / .run installers with assumptions about /usr layout, kernel modules, library versions. Layering them with rpm-ostree install would slow every future upgrade and break when the vendor expects to write to paths the immutable system protects.

Distrobox sidesteps that completely. You get a real distro inside a container, with sudo, package manager, and full access to your home, GPU, audio, X11/Wayland, USB devices. The vendor sees a normal Ubuntu 22.04 (or whatever). Your host OS doesn't budge an inch. Removing a tool is distrobox rm <name>.

DistroShelf (preinstalled in Margine DX, find it in Activities) is the GUI for managing containers: create, enter, install, remove. All without typing.

DaVinci Resolve (video editing + colour grading)

Free tier (1080p) and Studio tier (4K, NR, hardware decoders). Both ship as a single .run installer for Ubuntu / Rocky Linux. Setup:

1. Download Resolve from Blackmagic Design's site (free registration). You get a .zip with a .run inside.
2. Open DistroShelf → Create new container → pick Ubuntu 22.04 (Resolve's officially-supported base) → name it resolve.
3. From DistroShelf, Enter the container. You're in a normal Ubuntu shell. Run the installer:

# Inside the resolve container
sudo apt update
sudo apt install -y libfuse2 ocl-icd-libopencl1 fakeroot xz-utils
# Extract Blackmagic's installer (path matches the file you downloaded)
unzip ~/Downloads/DaVinci_Resolve_*_Linux.zip -d /tmp/resolve
sudo /tmp/resolve/DaVinci_Resolve_*_Linux.run --install
# Optional: expose the launcher to the host
distrobox-export --app /opt/resolve/bin/resolve

That last line makes a desktop entry appear in your Margine Activities so you can launch Resolve like any other app. GPU access works out of the box (Margine's Mesa freeworld + Vulkan/OpenCL stack is exposed to the container).

For Studio (paid) you'll also want the BMD hardware key drivers. Same Distrobox, same installer flow, the BMD docs cover it.

BricsCAD (CAD)

Vendor ships a .deb only. Bricsys provides Ubuntu 22.04 / 24.04 as supported targets. Same pattern:

1. Download the BricsCAD .deb from bricsys.com.
2. DistroShelf → Create container → Ubuntu 24.04 → name bricscad.
3. Enter the container and install:

sudo dpkg -i ~/Downloads/bricscad_*.deb
sudo apt-get install -f         # pull missing deps
distrobox-export --app bricscad

BricsCAD relies on the network license server for paid tiers; configure it on first launch as you would on stock Ubuntu, nothing Margine-specific.

Pro audio (Reaper + low-latency kernel + JACK / PipeWire)

Reaper is one click away in Bazaar (or flatpak install flathub fm.reaper.Reaper). It used to be preinstalled; we removed it from the default set because its Flatpak downloads the actual REAPER binary from the vendor at every update (an "extra-data" app), and a hiccup in that download can stall unattended updates. Installing it yourself is fine: if that download ever wedges your nightly updates, Margine detects it, excludes the app automatically and tells you; ujust margine-update-unblock updates it in the foreground whenever you want. For pro-audio work, three knobs matter beyond Reaper itself:

1. The kernel

Margine ships CachyOS with the BORE scheduler (Burst-Oriented Response Enhancer). BORE prioritises short bursts of activity (which is what audio buffer cycles look like) and delivers measurably more stable frame times under load. No setup, it's there.

For sessions where you want to compare sched_ext behaviour, open Margine CPU Scheduler from Activities and try a shipped scheduler such as scx_lavd or scx_flash (predictable low-jitter latency, the audio pick). Use Off to return to the kernel default BORE scheduler.

ujust margine-scheduler lavd
ujust margine-scheduler off

The scheduler picker is opt-in. Margine leaves scx_loader disabled until you choose a scheduler, so the default desktop stays on BORE unless you explicitly switch. Full guide (what each scheduler is for and how to benchmark honestly): CPU schedulers.

2. The sound server

Bluefin DX ships PipeWire with the pipewire-jack shim. That means apps that expect a JACK server (Ardour, Carla, ZynAddSubFX, most VST hosts) just work as if they were talking to JACK. No need to install or run jackd separately.

Tune the latency from EasyEffects (preinstalled) → top-right menu → Preferences → "PipeWire quantum / sample rate". Lower quantum = lower latency, higher CPU cost. Typical: quantum 64 at 48 kHz for live monitoring; 1024 at 48 kHz for mixing. EasyEffects itself (presets, per-device autoload, when to bypass) has its own page.

3. The user limits

For consistent sub-10 ms latency, your user should be in the realtime group. Margine ships the realtime-audio limits ready to go, you just need to add your user to the group:

sudo usermod -aG realtime $USER # Log out + back in to pick up the new group.

Machine learning / GPU compute (PyTorch, Stable Diffusion, ROCm / CUDA)

ML workloads want huge dependency trees pinned to specific CUDA / Python / driver versions. Forcing those onto an immutable host is wrong; Distrobox is right.

For NVIDIA: DistroShelf → Ubuntu 22.04 (the version PyTorch's prebuilt wheels are tested against) → enter → install the CUDA toolkit per NVIDIA's apt instructions. The host's NVIDIA driver is exposed to the container automatically through nvidia-container-toolkit (which ships in Bluefin DX).

For AMD: ROCm via Ubuntu 24.04 container. Margine's host Mesa stack already includes mesa-libOpenCL + ROCm-compatible drivers for runtime, the container only needs the toolkit:

distrobox create --name ml-amd --image ubuntu:24.04
distrobox enter ml-amd
sudo apt install -y rocm-hip-sdk
# install pytorch with the right ROCm wheel index, etc.

darktable (RAW photography, GPU-accelerated)

darktable is preinstalled (Flatpak). Its darkroom is compute-heavy: denoise, local contrast, lens corrections and every pipeline redraw run much faster on the GPU through OpenCL. The catch is that the Flatpak ships without knowing which OpenCL driver to load, and darktable keeps the Mesa driver blocklisted until two preferences are flipped, so out of the box it quietly falls back to the CPU. One command sorts it:

ujust margine-darktable-opencl

It detects your GPU (AMD or Intel), points darktable's Flatpak at the matching Mesa rusticl driver, and turns OpenCL on in darktable's config. No sudo, no ROCm or CUDA, no package layering: it only writes a Flatpak --user override plus darktable's own darktablerc, and it's safe to re-run. rusticl is part of the host Mesa stack and covers AMD (down to older cards like Polaris / RX 500) and Intel, so there's nothing else to install.

Quit darktable and reopen it, then check it took under Preferences → processing → OpenCL GPU acceleration: activate OpenCL support should be ticked.

The first time you enter the darkroom afterwards, darktable may show a one-off "OpenCL 'per device' settings have changed" notice. That's expected: it's just darktable writing its new per-device profile. Dismiss it and carry on.

To confirm from a terminal, run flatpak run org.darktable.Darktable -d opencl; the log prints the device it picked, or the reason it declined (usually an unsupported or busy GPU).

Blender (GPU rendering on AMD)

Blender is preinstalled. Cycles, its path-tracing renderer, is dramatically faster on the GPU than on the CPU. On AMD that path is HIP, and there is a catch worth knowing: the Blender Flatpak does not ship the ROCm/HIP runtime, so out of the box Cycles finds no GPU and quietly renders on the CPU instead. Margine's host does ship ROCm, so one command bridges the two:

ujust margine-blender-gpu enable

It exposes just the host's ROCm libraries to Blender (only those, so nothing the interface itself depends on gets shadowed and the app still launches normally) and selects HIP in Blender's preferences. No HSA_OVERRIDE, no ROCm install, no sudo: a Flatpak --user override plus a small symlink shim. AMD only; NVIDIA uses CUDA/OptiX and Intel uses oneAPI, which are separate paths. ujust margine-blender-gpu disable reverts it, and status shows what it found.

Then, in each project, set Render Properties → Device to GPU Compute (the device itself is already ticked for you under Edit → Preferences → System → Cycles Render Devices). Render with F12; Blender's status line names the device it is using. To make GPU the default for new files, set it once and then File → Defaults → Save Startup File.

Verified on a Radeon 760M (an integrated RDNA3 chip): recent ROCm supports it natively, so Cycles renders on the GPU with no override tricks. One honest note for integrated GPUs: the video memory is shared with the system, so a very heavy scene can hit out of memory; drop the resolution or the sample count if it does. A discrete AMD card has its own VRAM and does not have that ceiling.

OBS Studio (hardware video encoding)

OBS Studio is preinstalled. Recording or streaming with the CPU (the x264 encoder) burns cores you would rather give to the game or the app you are capturing. Your GPU can do the video encoding in dedicated silicon instead, at close to zero CPU cost, through VAAPI.

On an AMD Radeon (and on Intel GPUs) that hardware path covers H.264, H.265/HEVC and AV1; NVIDIA uses its own NVENC path. OBS picks the VAAPI encoders up on its own: it ships its own FFmpeg built with them, Margine exposes the GPU render node to the Flatpak, and the Mesa driver provides the encode entrypoints. To switch to it:

1. OBS → Settings → Output, and set Output Mode to Advanced.
2. Under Streaming or Recording, set Video Encoder to a VAAPI entry, for example FFMPEG VAAPI (H.264), HEVC (VAAPI), or AV1 (VAAPI).
3. Pick a bitrate and record. Your CPU usage stays low even at high resolutions.

AV1 (VAAPI) is the one to reach for on modern platforms (YouTube, recent Discord) and for local recording: clearly better quality per bitrate, and the GPU does it for free. H.264 (VAAPI) is the safe default when whatever you are sending to needs the widest compatibility. If OBS shows no VAAPI entry, the encoder your machine exposes may differ; the list in Output only ever shows what the GPU actually supports.

Netflix at 1080p (Zen Browser)

Netflix caps Linux browsers at 720p unless the browser identifies as one it has blessed for Full HD. The DRM side already works on Margine: Zen downloads Widevine on first protected playback, so the block is only the user-agent string. One command sets it up:

ujust margine-netflix-1080p install

It installs the AMO-signed Netflix 1080p UA extension into your Zen profile. The extension rewrites the user agent to Opera-on-Linux on netflix.com only (it does not touch any other site, and it does not provide or bypass Widevine). It is opt-in and per-user, and ujust margine-netflix-1080p remove takes it back out.

After installing, fully quit Zen and start it again: a freshly sideloaded extension only activates its background on a clean restart, so the first Netflix page can otherwise still show the native user agent at 720p. Then play a compatible title, wait for the stream to settle, and press Ctrl+Shift+Alt+D to open Netflix's diagnostic overlay. The Playing line should read 1920x1080.

Two honest caveats: Full HD needs a Netflix plan that includes it (the Premium tier), and the title itself has to be available in 1080p. If the overlay's UserAgent line shows Opera but the resolution stays at 720p, it is the plan or the title, not the browser.

The Margine creative chain (already preinstalled)

Margine ships these on first boot, no setup, no installs needed:

• GIMP: raster image editing
• Inkscape: vector graphics
• Pinta: Paint.NET-style lightweight editor
• darktable: RAW developing + photo management
• OBS Studio: recording + streaming
• Audacity: multitrack audio editing
• EasyEffects: system-wide audio equaliser / processing
• Apostrophe: distraction-free Markdown writing
• Gapless (g4music): local-library music player
• LibreOffice: office suite

All Flatpaks, all sandbox-isolated, all updated daily by uupd.timer. None of them required a single click on your part to be there.