I'm pretty sure all of those entries are in the same /12 network - 172.16.0.0/12. Apparently there's nothing wrong with it, but I think you can significantly simplify that config by just removing all the extra ones
Markaos
That just uses normal fast charging to get to 80%, then stops the charge and finally resumes charging about an hour or two before the planned "charged by" time. No slowing down.
Oh, and it also has (or had on Android 13) a cool bug where it just stops charging if it fails to reach 80% by the time it wants to resume charging (for example if you put the phone on a slow charger late at night - that's how I woke up with 60% battery after 4 hour sleep).
So I just gave up on the idea of using a slow charger to better preserve the battery because the phone clearly wasn't expected to be used that way.
Because of the built-in SSD, I could also sell the external SSD and buy an 8-12tb HDD instead.
If you're going for a 3.5" HDD, then you'll most likely have to look for a bit bigger form factor than TinyMiniMicro (Lenovo Tiny / HP Mini / Dell Micro series) - these computers can't fit a 3.5" HDD.
If size isn't a major concern, I'd go for the SFF variants of these computers - they are often cheaper than minis for same specs, but probably have a bit larger idle power draw and take up more space. As a bonus upside, you get some small PCIe slots in these computers, so yay for expansions.
On the other hand, it's also worth noting that newer RAM generations are less and less susceptible to this kind of attack. Not because of any countermeasures, they just lose the data without constant refreshing much quicker even when chilled / frozen, so the attack becomes impractical.
So from DDR4 up, you're probably safe.
~~I think the idea at the time was that if /usr is unavailable, you won't be doing much with the system anyway (other than fixing the configuration).~~
Nevermind, apparently the original meaning had nothing to do with a network (TIL for me), so our discussion is kinda moot. See section 0.24 in this 2.9BSD (1983) installation guide
Locally written commands that aren't distributed are kept in /usr/src/local and their binaries are kept in /usr/local. This allows /usr/bin, /usr/ucb, and /bin to correspond to the distribution tape (and to the manuals that people can buy). People wishing to use /usr/local commands are made aware that they aren't in the base manual.
No comment on sensibility, but technically both are equally difficult - mount the parent filesystem, then mount the child filesystem into an empty directory in the parent. Doesn't matter which one is where, it's all abstracted away at this level anyway.
That requires just unlocked bootloader, not root. In the distant past before full disk encryption you could often use root to replace the bootloader with a new one that doesn't verify what OS it's booting (so you could say that rooting was part of the process of changing ROM), but nowadays it's very rare to be able to do that.
Now you either get a tool from your OEM to unlock your bootloader (and then you can flash ROMs to your heart's desire), or you're screwed.
I mean, there is the whole 128/8 for localhost, kinda hard to beat that with crazy allocations. And OP still has another /12 and /16 networks available even if they refuse to further divide them.
No, face unlock on Pixels doesn't do anything to illuminate your face, it simply refuses to work if the lighting's too dim. It's actually worse than the face unlock in Google Smart Lock in dealing with low light environments.
Minor nitpick: I'm pretty sure USB Video Class is not an alt mode, just a standardized interface for sending video over USB (like HID for keyboards and mice or mass storage for flash drives). Alt modes completely dump USB (except the USB 2 link which is always available) and repurpose most of USB-C's pins for a different protocol.
JavaScript. Your browser downloads and runs it automatically and the vast majority of people either don't consider it a problem at all or just accept that they can't choose what software they run on their computer. This person apparently wants to avoid websites with proprietary JavaScript if possible.
~~Honestly, I'm kinda surprised that the live translation in Google Camera wasn't dependent on other Google apps before - I thought all Google apps were developed with the assumption that the apps mandated for Android certification would be available, and that losing functionality if the user starts disabling stuff is fine.~~
As to why it isn't very common: Android conditions users to think of the apps as fully self-contained units. There's no way to have Google Play suggest installing app B as an optional dependency when you install app A, and asking the user to install it during the first launch would go against common user experience wisdoms. The current best practice is to get the user up to speed as fast as possible, with every extra tap they have to make increasing the possibility of them leaving for another app.
But there are definitely apps that do use this. For example OpenTracks, a GPS tracking application, has no integrated map to show captured routes and instead expects the user to find another app that supports its API. Or GadgetBridge, an alternative companion app for many smart watches / fitness bands - it is common for these devices to have some weather forecast widget, but one of GadgetBridge's design goals is to not to have internet access (to help with trust). So it has an API for weather provider apps to make this work.
Edit: First paragraph is toast, I misread the OP