

Firefox isn’t much better in that regard. Bootstrapping alone takes many minutes, which is no surprise since their build system is not only huge but also written in Python of all things. Even if you use gcc instead of clang to compile the corporate spaghetti, the tons of rust in the codebase will make up for all that time gained lol. On my 2014 Xeon workstation where a generic Linux Kernel takes less than an hour, FF takes 6+ hours to build.
This reads like it was written by some LLM.
Don’t ever disable journaling if you value your data.
Neither of these schedulers exist anymore unless you’re running a really ancient Kernel. The “modern” equivalents are
none
andbfq
. Also this doesn’t even touch on the many tunables thatbfq
brings.Also changing them like they suggest isn’t permanent. You’re supposed to set them via udev rules or some init script.
None of this changes any settings like they imply.
No shit. Who would’ve thought that throwing more/better hardware at stuff will make things faster.
EDIT: More bullshit that I noticed:
Again this doesn’t permanently change the maximum number of open files. This only raises the limit for the user who runs that command. What you’re actually supposed to do is edit
/etc/security/limits.conf
and then relog the affected user(s) (or reboot) to apply the new limits.This doesn’t even make any sense.