Thread by @arter97

I won't call anyone out specific because that's "offensive", but I literally have never seen anything good from add-ons / Magisk modules that claims to improve your device by tweaking system internals automatically.

Especially the ones that include questionable words like "best", "significant", "insane", "perfect" and claims to be compatible with all devices.

Also especially the ones that do not even have a technical explanation on what it's actually changing.

And some of those were even highlighted on XDA's front page.

Unlike a manufacturer where one would actually have to pass Google's tests to ship a device, there's no limit on how bad such modules can do.

Some even straight up have the potential to brick devices, and I've been told that already happened.

A little lesson to everyone: stay away from anything that says "best", "significant", "insane", "perfect" or anything like that.

Once a person gets scientific, researches and studies data, you really don't say those words anymore even if that's true.

I get why some kernel developers are starting to block those modules. I probably would have done the same if it didn't involve me going through exhausting and meaningless political discussions.

PSA to the users: stay away from those.

Apparently I'm "rassist".

Also apparently, @franciscof_1990 needs to get his shit together 😂

@franciscof_1990 Also also apparently, "x64" (which is a term only Microsoft uses) is not "x86".

@franciscof_1990 Anyone pls explain me the logic here.

Some asked for the full thread.

arter97.com/wtf1.jpg
arter97.com/wtf2.jpg

Ok, I'm done being nice. I'm mad.

The FDE.AI developer kindly allowed the world to peek at his stupidity.
github.com/feravolt/FDE-s…
archive.is/rFunp

Coding style and dangerous C practices aside, there are so much wrong in that bullshit that I genuinely feel sorry for users applying this cancer.

As far as I'm concerned, this should be outright banned from XDA and Magisk module repository, and I'm personally ashamed that I'm on the same community with that person.

One should always keep in mind of this principle:
Defaults are set for a fucking reason.

If you’re going to set a value that differs from the default, you’d better have a good scientific reason for doing so. That fde.c contains 152 writes to sysfs nodes.

If you are smart enough to understand the ramification of changing 152 kernel tunables, you wouldn’t be writing this bullshit to begin with and just create a much better version of Android or the Linux kernel all by yourself.

But just so that I can shut up the baseless people arguing “but you haven’t tried this out yourself”, let me list a few things that are so stupid that you couldn’t have possibly have gone through the details of what it actually does.

1. FDE.AI overrides Linux’s defaults and manufacturer’s values.
I’ve mentioned overriding the defaults above. But FDE.AI also overrides the manufacturer’s values.

If a manufacturer has a testing and an R&D facility, it goes through rigorous data-based benchmarking to ensure it enhances user experience. Every major OEMs goes through this.

This is often done per-chip and per-device, not by “a magic app that can tune all the values by artificial intelligence”.

Also here: github.com/feravolt/FDE-s…

If an OEM went through the efforts of adding a kernel tunable that says “power_reduce” and left it disabled, why do you think they would have done that?

Sure, let’s just turn it on and “Reduce LCD power consumption”.

2. FDE.AI disables some wakelocks.
github.com/feravolt/FDE-s…
This is fine *as long as you’ve fully understood what the wakelock does*.

I’ve too disabled Qualcomm’s Wi-Fi driver’s rx wakelock from the conclusion that the potential of dropping ARP packets won’t affect the general user experience.

FDE.AI disables a wakelock from smb135x, which is Qualcomm’s battery charger and fuelguage IC.

Sure, let’s disable a random wakelock from the most crucial component of your smartphone that’s responsible for preventing explosion of your battery.

3. FDE.AI disables vsync.
github.com/feravolt/FDE-s…
Disabling vsync is the last thing you want to do on a mobile device.

People disable vsync on games as you can live with tearings with games. That’s not the case on pretty much everything else.

4. FDE.AI enables BBR congestion control without testing its validity.
github.com/feravolt/FDE-s…
BBR under Linux 4.13 is unusable. Detail by kdrag0n here: forum.xda-developers.com/showpost.php?p…

5. FDE.AI makes the dumbest choices for tuning your I/O device.
github.com/feravolt/FDE-s…

5.1. FDE.AI disables write and read caches on UFS devices.
This both slows down(disabling read cache) and increases the risk of losing your data(disabling write cache). I have no fucking idea why one would do that.

5.2. FDE.AI disables I/O merges.
While SSD and UFS storages are fast, it’s not as fast to disable I/O merging outright. It’s extremely easy to find data on the Internet proving disabling I/O merging is meaningless except for some very specific db programs.

This effectively disables timer coalescing on UFS without any tangible benefits and just increases power consumption.

5.3. FDE.AI disables low latency mode.
Android is not your average Jenkins build server. You always want lower latency than higher throughput. This change removes some of the SSD optimizations under the Linux kernel. Why???

5.4. FDE.AI enables synchronous trimming on ext4.
github.com/feravolt/FDE-s…
Android always has used fstrim since 4.3 Jellybean to workaround slowdowns from using synchronous trimming. Using the “discard” option slows down your device.

6. FDE.AI also makes dangerous choices as well.

6.1. FDE.AI changes f2fs checkpoint intervals from 60 seconds to 900 seconds.
github.com/feravolt/FDE-s…
By default, f2fs creates a new checkpoint every 60 seconds. With this changed to 15 minutes, you can lose up-to 15 minutes worth of data.

6.2. FDE.AI enables nobarrier.
github.com/feravolt/FDE-s…
(Not to be confused with f2fs’ fsync_mode=nobarrier)
Using nobarrier disables write cache flushing on the storage device.

One should only use this if: a. the storage device is always battery-powered between power cycles(e.g. Motorola devices) or b. the file-system is capable of recovering to the last-known-good checkpoint from out-of-order writes like f2fs.

FDE.AI enables nobarrier regardless and it’s been proved to brick several devices because of it. The author simply decided to exclude the known ones(K20 Pro or Mi 9T) from nobarrier instead of understanding what it does.

If you happen to own a device not on the blacklist and if its UFS firmware happens to do out-of-order writes, you can enjoy using your new brick for your next construction plans.

All in all, FDE.AI just looks like from someone who went through the kernel tunable’s names and enables stuff that looks good, and disables stuff that looks bad with 0 efforts into understanding what those actually do.

And as proven before, it actually bricked devices and the solution was to simply blacklist some devices.

And if you were to believe the person behind this is rightfully using the term “Machine Learning”, you’re dumb too.

An actual image from github.com/feravolt/FeraD…

God, I hope other tweaks like Lspeed are much better than this monstrosity.

He replied

forum.xda-developers.com/showpost.php?p…

so I replied
forum.xda-developers.com/showpost.php?p…

Saved it just in case.

archive.is/Bcpwf
archive.is/WE5SP