Markaos

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

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.

Does UEFI initialize all the cores? I know the OS always starts with only one core available, but I'm not sure if UEFI just disables the cores after it's done its thing, or if it doesn't touch them. Because if it stays on core 0 and never even brings the other ones up, then this issue with core 2 could let it boot this far just fine.

Only if you consider ROMs like LineageOS to be stock Android and ignore the many things they do to make the user's life easier.

AOSP never had internet access as a toggleable permission, and it never will as long as Google is calling the shots and wants ads to work the way they currently do.

Maybe. To be clear the delay isn't that large (my very rough guesstimate is somewhere between 100 and 300 ms, probably more towards the lower end), and if I just click somewhere on the slider, it feels fine.

It only feels janky when I drag the slider and the screen brightness updates in very noticeable steps. But that is how I naturally interact with sliders, so it's hard not to notice it for me.

It's a very common feature for monitors, at least in my experience - both of my cheap AOC monitors support it, as well as all the other monitors I've ever connected my laptop to (a few HP and Samsung monitors iirc).

But it also feels kinda janky due to how long the display takes to change the brightness, so maybe that's why Microsoft decided not to support it?

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.

Not really - report your issue on their issue tracker if you can and feel like spending your time on it, then move on (and maybe check back in some time). Flatpak are meant to fix dependency issues, there's not much you can do if they got it wrong for whatever reason.

If it's a Flatpak, then installing anything with APT shouldn't help you at all - it is possible to build a Flatpak that accesses host libraries, but it would defeat the point of using Flatpak in the first place. So your xapp issues are moot anyway.

As to the meaning of the output of apt policy: it says that the most up to date libxapp1 is from Linux Mint repos, and that there's also an older version in Ubuntu repos. That means that Linux Mint doesn't provide a xapp package at all, and the only one you could install is the old one from Ubuntu (which conflicts with the newer libxapp1 from LM)

The APT error is most likely a result of using PPAs - some PPA you use (probably the one with simple64) provides libxapp1 2.8, but doesn't provide happy at all, so you end up falling back to the much older version from your distro's repositories. But xapp needs an exact version of libxapp1, so you get this error.

That said, if the simple64 PPA doesn't provide the xapp package, then it perhaps isn't required and the module should be provided by libxapp1 (and the problem is something different). Or maybe it comes from a completely different PPA - I believe apt policy libxapp1 should tell you where it's coming from.

Yes, but they are asking how to set up FDE in the same way it works on Windows, where automatic unlocking works using TPM. They just don't know the technical details.

Yeah, but a lot of those things will trip the TPM module, so you will get a different decryption key if you for example try to use the single kernel parameter to boot into a root shell. And different decryption key means no access to the data.