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

  • @[email protected]M
    9•1 year ago

    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
      • @[email protected]M
        4•1 year ago

        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.

        • @[email protected]OPEnglish
          1•1 year ago

          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.

          • @[email protected]M
            2•1 year ago

            Yes, I do provide a password on boot, as you said, keys can be extracted from the hardware so that’s not secure, which is why I don’t use the TPM to store the keys.

            There are no hooks necessary in the bootloader, as it’s the BIOS which prompts you for the password and unlocks the drive.

            And yes, there have been implementation problems in the past, but that’s why the Opal 2.0 standard exists - don’t just buy any random self-encrypting drive, do your research on past vulnerabilities for that manufacturer, and check if there are any firmware updates for the drive (don’t just rely on LVFS).

            Also, the common hardware attacks rely on either a SATA interface (to unplug the drive while it still has power) or older external ports vulnerable to DMA attacks such as PCMCIA or Thunderbolt 3.x or below; so those attacks only affects older laptops. Of course, someone could theoretically install a hardware keylogger or something, but this is also why you have chassis intrusion detection, and why you should secure and check any external ports and peripherals connected to your machine. Overall physical security is just as important these days.

            But ultimately, as always, it comes down to your personal threat model and inconvenience tolerance levels. In my case, I think the measures I’ve taken are reasonably secure, but mostly, I’ve chosen Opal for performance and convenience reasons.