What are your ‘defaults’ for your desktop Linux installations, especially when they deviate from your distros defaults? What are your reasons for this deviations?
To give you an example what I am asking for, here is my list with reasons (funnily enough, using these settings on Debian, which are AFAIK the defaults for Fedora):
-
Btrfs: I use Btrfs for transparent compression which is a game changer for my use cases and using it w/o Raid I had never trouble with corrupt data on power failures, compared to ext4.
-
ZRAM: I wrote about it somewhere else, but ZRAM transformed even my totally under-powered HP Stream 11" with 4GB Ram into a usable machine. Nowadays I don’t have swap partitions anymore and use ZRAM everywhere and it just works ™.
-
ufw: I cannot fathom why firewalls with all ports but ssh closed by default are not the default. Especially on Debian, where unconfigured services are started by default after installation, it does not make sense to me.
My next project is to slim down my Gnome desktop installation, but I guess this is quite common in the Debian community.
Before you ask: Why not Fedora? - I love Fedora, but I need something stable for work, and Fedoras recent kernels brake virtual machines for me.
Edit: Forgot to mention ufw
KDE, just because it’s a good balance of usability and customisability.
I don’t think I will ever go back to a filesystem without snapshot support. BTRFS with Snapper is just so damn cool. It’s an absolute lifesaver when working with Nvidia drivers because if you breathe on your system wrong it will fail to boot. Kernel updates and driver updates are a harrowing experience with Nvidia, but snapper is like an IRL cheat code.
OpenSuse has this by default, but I’m back to good ol’ Debian now. This and PipeWire are the main reasons I installed Debian via Spiral Linux instead of the stock Debian installer. Every time I install a new package with apt, it automatically created pre and post snapshots. Absolutely thrilled with the results so far. Saved me a few hours already, after yet another failed Nvidia installation attempt.
Please tell me more about Spiral Linux. I’m not a huge Debian fan personally(at least for desktop), but I often install Linux on other people’s machines. And Mint/ Debian is great for them.
How does it differ from stock?
Details on the Spiral Linux web site: https://spirallinux.github.io/
Key points are BTRFS with Snapper, PipeWire, newer kernels and some other niceties from backports, proprietary drivers/codecs by default, VirtualBox support (which I’ve personally had huge problems with in the past on multiple distros). They also mention font tweaks, but I haven’t done side-by-side comparisons, so I’m not sure exactly what that means.
Edit: shoutout to Spiral Linux creator @sb56637@lemmy.ca , who posted a few illuminating comments on this older thread: https://lemmy.ca/post/6855079 (if there’s a way to link to posts in an instance-agnostic way on Lemmy, please let me know!)
How does it differ from stock?
Well for one thing their driver support is apparently “harrowing”. 😊
I will never understand why people choose distributions that will brick themselves when the wind blows, so they add snapshot support as a band-aid, and then they celebrate “woo hoo, it takes pre and post snapshots after every package install!”
How about using a distro where you never have to restore a snapshot…
To clarify, this is my first time using Spiral Linux. My experience regarding Nvidia drivers is across several different distros (most recently Ubuntu LTS and OpenSuse Tumbleweed). I have never had a seamless experience. Often the initial driver installation works, but CUDA and related tools are finicky. Sometimes a kernel update breaks everything. Sometimes it doesn’t play nice with other kernel extensions.
The Debian version of the drivers didn’t set up Secure Boot properly. Instead, I rolled back and used the generic Nvidia .run installer, which worked fine. Not seamless, obviously, but not really worse than my experience on other distros. In the future I will always just use the generic installers from Nvidia.
Point is, with BTRFS you can just try anything without fear. I’m not going to worry about installing kernel updates from now on, or driver updates, or anything, because if anything goes wrong, it’s no big deal.
- NixOS
- disko + nixos-anywhere (automatic partitioning & remote installation of new systems)
- stylix (system-wide theming)
- agenix (secret management)
- impermanence (managing persistent data)
- nixos containers for sandboxing applications & services (using systemd-nspawn)
- TMPFS as /
- LUKS
- BTRFS as /nix (might try bcachefs)
- SWAP partition (= RAM size, to susbend to disk)
- Greetd with TUIgreet (DM)
- SwayFX (WM)
- Kitty & foot (term)
- Nushell (shell)
- Helix (editor)
- Firefox (browser)
- slackhq/nebula (c.f. self-hosted tailscale, connecting my systems beyond double NATs)
EDIT1: fix “DE” -> “DM”
This is a very interesting setup would you mind providing more explanation / documentation? Also would you mind sharing your nixOS config? I would love to try it.
My system configuration can be found on git.sr.ht/~sntx/flake. I’ve linked the file tree pinned to the version 0.1.1 of my config, since I’m currrently restructuring the entire config[1] as the current tree is non-optimal[2].
The documentation in the README in combination with the files should cover most of what I’ve described, with the following exception: disko is not present to the repo yet, since I’ve set it up with a forked version of my config and the merge depends on finishing the restructuring of my system configuration.
- You can take a look at these (non-declarative) installation steps to get an idea on how TMPFS as root can be setup
- If you’re interested, I can also DM you the disko expression for it
The goal is to provide definitions for desktops, user-packages, system-packages, themes and users. Each system can then enable a set of users, which in turn have their own desktop, user-packages and theme. A system can also enable system-packages for itself, independent of users. If a user is enabled that has a desktop set, the system will need to have display-manager set as well, which should launch the users configured desktop. ↩︎
The current config assumes a primary user, and can only configure a single DE and apply the application/service configs only to that user. ↩︎
This looks like a whole project. What is the overall goal of this build?
I am very new to nixOS and am interested in it. Specifically for ansible scripts to build out easily replicateable docker hosts for lab. I have also considered it for switching my primary desktop and laptops as being able to have the same OS with everything the way I like it is also intriguing.
Sorry for theate response. P.S. I love your wallpaper.
Now that’s quite an interesting NixOS setup, I’m especially intrigued by the tmpfs root portion. The link you provided was a great read, and I’ll keep this and honestly most of what you’ve described in mind for when I mess with NixOS again.
There are also these two blog posts by elis on setting up tmpfs specifically. Though these posts rather are setup guides, than “talking about the philosophy” of systems design.
- LUKS
- Btrfs
- sway
Nobara KDE user here. One of the reasons why I chose it is because it comes with many of the customisations that I’d normally do (such as using an optimized kernel). But in addition, I use:
- Opal instead of LUKS
- KDE configured with a more GNOME/macOS like layout (top panel+side dock)
- GDM instead of SDDM, for fingerprint login
- Fingerprint authentication for sudo
- TLP instead of power-profiles-daemon for better power saving (AMD P-State EPP control, charging thresholds etc)
- Yakuake terminal (and Kitty for ad-hoc stuff)
- fish shell instead of bash
- mosh instead of ssh
- btop instead of top/htop
- gdu instead of du/ncdu
- bat instead of cat
- eza instead of ls
- fd instead of find
- ripgrep instead of grep
- broot instead of tree
- skim instead of fzf
Opal drives are self-encrypting, so they’re done by the disk’s own controller transparently. The main advantage is that there’s almost no performance overhead because the encryption is fully hardware backed. The second advantage is that the encryption is transparent to the OS - so you could have a multi-boot OS setup (Windows and FreeBSD etc) all on the same encrypted drive, so there’s no need to bother with Bitlocker, Veracrypt etc to secure your other OSes. This also means you no longer have a the bootloader limitation of not being able to boot from an encrypted boot partition, like in the case of certain filesystems. And because your entire disk is encrypted (including the ESP), it’s more secure.
Thank you very much for your explanation.
I still feel skeptical about using a chips controller for encryption. AFAIK there have been multiple problems in the past:
- Errors in the implementation which weaken the encryption considerably
- I think I even read about ways to extract the key from the hardware (TPM based encryption)
Do you provide a password and there are ‘hooks’ which the boot process uses for you to enter the password on boot?
I think it is nice to have full disk encryption, but usually we are speaking about evil-maid attacks (?), and IMHO it is mostly game over when an attacker has physical access to your device.
