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

  • d3Xt3r@lemmy.nzM
    link
    fedilink
    arrow-up
    8
    arrow-down
    2
    ·
    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
    • wolf@lemmy.zipOP
      link
      fedilink
      English
      arrow-up
      1
      ·
      1 year ago

      Impressive list! What is the benefit of using Opal compared to LUKS?

      • d3Xt3r@lemmy.nzM
        link
        fedilink
        arrow-up
        2
        ·
        edit-2
        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.

        • wolf@lemmy.zipOP
          link
          fedilink
          English
          arrow-up
          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.