The Arch wiki may have some ideas for you - tl;dr is that GDM uses a global dconf db over in /etc/ and this might be the root of your problem (these configs might not get cleaned up with a --purge?) I’m a LightDM user so best I can do to help: https://wiki.archlinux.org/title/GDM#dconf_configuration

Quick update for anyone still reading this thread:

@fdroidorg@floss.social As with any other app, we flagged Fennec and Mull with KnownVuln until the app is updated. Contributors fixed the issues that delayed versions 130 and later. Stand by for the build.

https://floss.social/@fdroidorg/113384089915217604

A bit of backstory on how we got here - in June 2024 Mozilla chose to (a) integrate the source tree of Firefox Mobile into their huge monorepo (“gecko-dev”), and (b) move the source off of Github onto their own git servers (“Mozilla Central”). You can read about it in the now-archived old repo:

• https://github.com/mozilla-mobile/firefox-android
• https://github.com/mozilla-mobile/firefox-android/wiki#upcoming-migration-to-mozilla-central

This was then compounded by a core Android build kit (“NDK”) choosing to remove parts of the toolchain which is/was used to build Firefox releases (ergo, forcing another change to build process):

• https://github.com/android/ndk/issues/2010

Together these have caused a bit of a kerfuffle in getting new releases compiled and released via the official F-Droid methodology. See the other comment about the Mull version in their private repo, they’re having to use a Mozilla pre-built clang (a compiler toolchain) now to make it work for the time being.

The link(s) to add their F-Droid repo if not running DivestOS: https://divestos.org/pages/our_apps.html#repos

I have been using Linux on laptops as main/only compute since around 1997 (started with an Inspiron 4000, PII-400 IIRC), Dell is generally extremely boring and very Linux/BSD compatible. I have been buying gently used Precision models (typically using local marketplace, Craigslist in USA) as they tend to have better build quality and non-janky custom parts (think “winmodem”). They last forever, pretty much every Linux/BSD distro works. The most important thing is to stay away from Broadcom chips and look for Intel eth/wifi. Stay away from Inspiron to avoid hardware problems, in modern times those are the bottom of the barrel janky hardware.

The Dell Latitude line used by businesses are even more boring than Precisions and really always have been - their BIOS has a somewhat unique charging profile “always plugged in” to extend battery life - I use two ancient E6330 models tuned to super low power modes as mini-servers (think anything you’d use a raspberry Pi for) that have been chugging away for probably 5+ years just running cron jobs, backups, Syncthing services and whatever I toss on them. Throw an SSD in anything and it just works - power goes out, batteries act as UPS. $100 USD each, “just work”.

Thinkpads have always been a Linux favorite, at least the old models when IBM owned the brand but not too sure about the Lenovo modern ones. Last Thinkpad I owned was a 32bit one back in like maybe 2010 and it worked just fine. They tend to be more expensive used than Dells (retain their purchase price better, like a nice used auto).

This is unfortunately a choice the Nautilus (GNOME) folks have taken; in other file managers (Thunar for XFCE, Caja for MATE, etc.) the ability to use custom actions are a first class citizen. Within Nautilus, the nautilus-actions project was superseded by the filemanager-actions project which was then archived: https://gitlab.gnome.org/Archive/filemanager-actions - a custom GNOME action might be something like gio open /path/to/terminal.desktop %d (where %d is the directory from Nautilus)

There are 3rd party attempts to recreate what was stripped out of/abandoned in Nautilus such as this one: https://github.com/bassmanitram/actions-for-nautilus

Went down the rabbit hole for you while drinking some tea listening to the rain - it looks like in the future there is a new app/proposal for FreeDesktop to use xdg-terminal-exec as the new/default way and it’s hard coded into the GNOME “gio” code over here (ctrl+f search xdg-terminal-exec): https://gitlab.gnome.org/GNOME/glib/-/blob/main/gio/gdesktopappinfo.c

That said, it looks like the nautilus-open-terminal Nautilus extension is shipped as part of gnome-terminal so it’s hard coded to run that terminal not using the above code. Instead, you’d need to leverage a different extension called nautilus-open-any-terminal for now until the landscape changes: https://github.com/Stunkymonkey/nautilus-open-any-terminal

(disclaimer: not using GNOME/Nautilus or Fedora, theorycraft from me)

I would agree, and would bring awareness of ionice into the conversation for the readers - it can help control I/O priority to your block devices in the case of write-heavy workloads, possibly compiler artifacts etc.

The Linux kernel uses the CPU default scheduler, CFS, a mode that tries to be fair to all processes at the same time - both foreground and background - for high throughput. Abstractly think “they never know what you intend to do” so it’s sort of middle of the road as a default - every CPU cycle of every process gets a fair tick of work unless they’ve been intentionally nice’d or whatnot. People who need realtime work (classic use is for audio engineers who need near-zero latency in their hardware inputs like a MIDI sequencer, but also embedded hardware uses realtime a lot) reconfigure their system(s) to that to that need; for desktop-priority users there are ways to alter the CFS scheduler to help maintain desktop responsiveness.

Have a look to Github projects such as this one to learn how and what to tweak - not that you need to necessarily use this but it’s a good point to start understanding how the mojo works and what you can do even on your own with a few sysctl tweaks to get a better desktop experience while your rust code is compiling in the background. https://github.com/igo95862/cfs-zen-tweaks (in this project you’re looking at the set-cfs-zen-tweaks.sh file and what it’s tweaking in /proc so you can get hints on where you research goals should lead - most of these can be set with a sysctl)

There’s a lot to learn about this so I hope this gets you started down the right path on searches for more information to get the exact solution/recipe which works for you.