[ Cisheterosexual | He/Him | 24 yo | ES/EN | Venezuelan | ADHD, autism and bipolar disorder | agnostic atheist ]


I’m just a random weeb. I love anime, dubstep, science, philosophy, logic and tech all along.

PS: English isn’t my native language, so sorry if I mispell some things, please kindly point it to me.

  • 0 Posts
  • 17 Comments
Joined 4 months ago
cake
Cake day: April 13th, 2026

help-circle






  • Honestly, I personally feel sorry (with every intention to offend) that you and others like you settle for and defend tooth and nail a half-baked solution, glued together with saliva and that breaks every time a core GNOME developer decides on it like monkey-patching over a shitty API. Not to mention the fact that KDE also allows it, and I say this as a KDE user, for the deepest part of its extensibility and scriptability, but without breaking it just because it looked ugly, and also allows other types of extensions, such as compiled dynamic libraries, or Plasmoids and components.










  • It may be a matter of hardware compatibility, a bug, or an issue during compilation or installation — I am not entirely sure. However, at least in my case, it runs significantly faster than virtually any other Firefox-based browser, including vanilla Firefox. It reduces CPU and GPU load by approximately 5–10%, which is substantial given my setup: an Intel Xeon v4 (Broadwell-EP, v3 SIMD) clocked at just 2.20 GHz (base, up to 2.90 GHz with Turbo Boost), featuring 12 cores and 24 threads, paired with an NVIDIA GTX 1060 (3 GB VRAM).

    ​Regarding memory consumption, RAM usage does not exceed 4–5 GB, even under a heavy extension load of nearly 100 installed add-ons. That said, this performance might be achieved in part by my custom about:config flags, the use of CachyOS repositories (optimized up to v3), and forced optimized compilation utilizing Mold, LLVM/Clang, Ananicy, and full LTO, among other tweaks, inside of my makepkg.conf (I use Arch, btw 🤪).