jard

Not only are root accounts themselves disabled by default, but it’s also highly recommended that any methods of remote and local login to root are disabled. It’s literally the most basic hardening step you can do for any Linux setup.

My VPS gets hit by tens of thousands of attempts to SSH into root every single day. My fail2ban jail for ssh alone get so absurdly large that it fills my remote terminal, and that’s not even including the fact that I ban by CIDR blocks, not individual IP, so I have hundreds of IPs blocked for a single fail2ban entry.

None of those attempts are actually successful as I’ve completely disabled password authentication and logins to root. The last thing I would want on my phone is full, unadulterated root access for that reason alone.

deleted by creator

I have Librewolf with uBO and CanvasBlocker whitelisted for very specific websites. It required me both disabling uBO and allowing *.google.com in CanvasBlocker’s whitelist for my browser to suddenly be “secure” again.

In other words… “we won’t let you sign in unless you enable your trackers on your browser.”

In my personal experience this is blatantly untrue, because now I can’t even log into my Google/YouTube account on Librewolf anymore. I get a prompt saying “this browser may be insecure” and requesting that I use Chrome instead. This is exactly what the Web Environment Integrity API was intended for — maybe they did decide to shelve it for general use, but Google is still absolutely trying to push this bullshit for their own services.

I never had this issue for the past 2 years I’ve used Librewolf until, coincidentally, Google “decided” to “sunset” its browser DRM.

The primary distinction between them is their fundamental philosophies towards coremodding (modification of the vanilla game’s code itself, rather than just appending mod code).

Forge is sort-of hostile towards coremodding because, by serving a central event-driven API for all Forge mods, Forge in principle claims responsibility of all forms of the coremodding needed to allow that API to be possible. Because of that, Forge is naturally going to become a large, bulky monolith when it comes to performance and complexity, but the benefits you gain is the general ensured compatibility between mods and not needing to learn JVM internals and Java bytecode.

Also, coremodding was historically achieved through raw bytecode manipulation, which was very ugly and unmaintainable, nowadays Forge provides the Mixin library for that purpose. It’s worth noting coremodding isn’t impossible on Forge, you just need to have a very good and necessary reason to do it.

In contrast Fabric elevates coremodding to a first-class citizen of the ecosystem; all mods are encouraged to use Mixin. This means that modders are now responsible for the vanilla modifications that the Forge API was responsible for, and the conflicting that will inevitably ensue. In most cases Mixin can handle these conflicts, but this isn’t guaranteed and you’ll get very weird and usually undebuggable Mixin errors (or even crashes that appear to originate from vanilla Minecraft or the JVM) if they aren’t caught.

As such, one mixin modifying one thing for multiple mods is a far better practice than multiple mixins modifying the same thing for multiple mods, so Fabric modders generally organize mixins into libraries that other mods depend on. The Fabric API itself is a glorified assembly of libraries that all mixin into vanilla code, and provide API functions for other Fabric mods to use, in the same vein as the Forge API.