• 1 Post
  • 9 Comments
Joined 1 year ago
cake
Cake day: September 2nd, 2024

help-circle

  • Non-Fedora-based immutable distros:

    • NixOS → Not based on any distro. Immutable-like because the entire system is declaratively managed through the Nix package manager. Rollbacks are built-in.
    • openSUSE MicroOS / Aeon → Based on openSUSE Tumbleweed (not Fedora). Uses transactional updates and Btrfs snapshots for immutability.
    • Vanilla OS (2.x, Orchid) → Originally Ubuntu-based, but now moving to a Debian Sid base with its own package manager (apx) and immutability features.
    • Endless OS → Independent distro, based on Debian but shipped as a read-only OSTree system with Flatpak apps.
    • Ubuntu Core → Based on Ubuntu, but entirely snap-based and immutable. Mostly aimed at IoT.
    • blendOS → Independent, immutable, designed around atomic updates and containerized package managers (supports apt, dnf, pacman, etc. via containers).

    Installing development libraries, whether bleeding edge nightlies, or just slightly obscure, often requires write access to some of the key folders. Does that get difficult?

    Nope if you do it in containers. In case of Bazzite, you have podman/distrobox/toolbox, and this particular thing you’d usually want to do in distrobox, which is going to be easier/faster than going full general docker/podman container route. It usually goes like this:

    distrobox create -n ubuntubox -i ubuntu:20.04
    distrobox enter ubuntubox
    sudo apt-get install mydevlibraries
    ...
    

  • I’m having difficulty getting docker desktop setup but I’m sure I’ll figure that out, had a lot of shit containerised before. But yeah, whole point of the post - Thanks people, you’re awesome.

    Just in case, podman is basically the same as docker and is preinstalled (cli only). You can use docker images and even run stuff from docker hub. There might be a GUI for it similar to Docker Desktop. Also, distrobox/toolbox are preinstalled - those variants of podman that do a lot of passthrough / bind mounts by default, so that you can build and run graphical, audio, networking apps in those and get them running with native performance and full access to devices/networking/etc.


  • Any rough edges you’ve encountered yet?

    No problems so far, but I didn’t try anything USB-related. Two of the more interesting programs I use it actively for are Ubuntu distrobox for Ultimate Doom Builder (level editor, works with GPU) and toolbox for natpmpc (utility for port-forwarding). I made a systemd service on my host system that calls toolbox run natpmpc -a 1 0 tcp 60 -g "$GATEWAY" 2>/dev/null in a loop to establish port-forwarding for my ProtonVPN connection (running on the host ofc), parses the assigned port and calls qbittorrent’s web api to set forwarded port there.


  • Distrobox uses bind mounts by default to integrate with the host: X11 and Wayland sockets for display, PulseAudio/PipeWire sockets for audio, /dev/dri for GPU acceleration, and /dev/shm for shared memory. On NVIDIA systems it relies on the standard NVIDIA container toolkit, while AMD/Intel GPUs just work with Mesa. Compared to plain Docker, where you usually have to manually mount X11/Wayland sockets, Pulse/PA sockets, /dev/shm, and GPU devices, Distrobox automates all of this so GUI, audio, and hardware-accelerated apps run at near-native efficiency out of the box. Toolbox works the same way but is more tailored for Fedora/rpm-ostree systems, while Distrobox is distro-agnostic and more flexible.


  • hisao@ani.socialtoLinux@programming.devWhy NixOS is the Future - YouTube
    link
    fedilink
    English
    arrow-up
    8
    arrow-down
    2
    ·
    28 days ago

    For me, NixOS feels like something from the 2010s. I used it a bit about a decade ago. It’s great and powerful, but still pretty niche and not for everyone. Right now I’m on Bazzite, which seems to aim for the same goals but in a much easier and more forgiving way.

    If I really need to overlay something onto the system, I can use rpm-ostree, but that’s rare since almost everything I need runs fine in toolbox or distrobox. Using those is super easy and forgiving—it’s basically like having super-efficient containers where you can mess around without worrying about breaking the host OS.

    Personally, I mostly stick to a single Ubuntu distrobox, where I build graphical/audio/gaming apps from source and just launch them directly from the container—they work perfectly. Distrobox feels like having as many Debians, Arch installs, or Fedoras as you want, all running at near-native efficiency. Toolbox is similar, but I use it more for system-level stuff that would otherwise require rpm-ostree —like being able to run dnf in a sandboxed way that can’t mess anything up.



  • FWIW, the thing with killswitch it not due to Bazzite, nor KDE. There’s a f*ck load of user reports all over the internet with different systems that have experienced the same thing; e.g. this one by a GNOME user on Pop!_OS.

    My bad, so it’s probably ProtonVPN client doing tricky hidden things that can break.

    As for your criticism on kdewallet, I was also bothered by it the last few times I engaged with KDE Plasma.

    I also got a kdewallet problem with flatpak VS Code authenticating to github, but that one is so widely known, they even included guidelines in docs on how to solve it.


  • The only real issue I’ve had was that the btrfs partition sometimes shits itself and requires some CLI commands in emergency mode to fix it.

    This sounds scary, not sure I’d be able to fix that. Hopefully, with some search if that happens to me.

    IIRC there was a widget for setting preferred GPU in the taskbar?

    Couldn’t find this one, and in general couldn’t find any UI for configuring GPUs systemwide. It’s possible to set preferred GPU in Lutris settings, but it didn’t work for some reason. I installed most heavy games via Steam, and Lutris doesn’t see my Steam games and setting preferred GPU in its Steam category doesn’t affect games in question.