>When an attacker gains a foothold in a corporate environment, they will immediately try to find any accessible credentials to assist in lateral movement.
So you think this isn't the case with home users? Maybe I still misunderstand the point that is being made here, but from my perspective it's only a matter of time until my encrypted password store gets exposed to the local attacker (as soon as I unlock it).
Have you tried a different USB-A charger? Some smaller devices have problems with USB-C to USB-C. I don't know why this is the case, though. It's just something I have observed with different devices.
What are "absurd" amounts of CPU and memory? Calculating and pinning dependencies is just a very difficult problem which happens to be reducible to SAT. If you think a SAT solver takes a lot of time and memory, then all alternatives would probably be even slower.
I use pip-tools with venvs for that and can‘t complain. It pins dependencies and you can create different requirements.txts for local dev and production (production for me is usually dev minus some debugging tools). It‘s not particularly fancy, but it gets the job done.
Threema's protocol doesn't even implement forward secrecy. From a security standpoint Threema is closer to iMessage than to Signal or other Signal-protocol-based messengers.
Are you implying that getting init script customisations overwritten by package managers isn't a problem with non-systemd init managers?
I have lost track how often that happened with sysvinit, because the "logic" how to treat customisations was usually handled by the package manager and they messed it up regularly.
systemd has a standard way to handle customisations. As long as you put everything you do in /etc/systemd/system, everything is fine. It's simple and works across distributions.
802.11n with 5 GHz is okayish, but using 2.4 GHz can be brutal. It's not just the bandwidth, the whole frequency band is just bad. My latency regularly goes through the roof and voice calls are noticeably worse than with 5 GHz wifi.
802.11ac mandates 5 GHz, so it's a reasonable baseline. I don't even care if it's SISO, MIMO or whatever as long as I don't have to fall back to 2.4 GHz.
I think the appeal of the 13 mini is that it actually has all the interesting features of the bigger phones (minus 120 hz and ProRes), just in a smaller phone. I would agree that this is true for the SE, though, but it's also significantly cheaper.
They could easily do it if they wanted to, now that they have more control over the SoC. With Chrome OS they already do it. Most devices that are released now will get 8 years of security updates, which are supplied by Google.
I guess the installation via pip is only best effort in the sense that they can't support every platform that pip is able to run on. For example their dependency on the "cryptography" library might cause problems on platforms which can't get a pre-compiled version from PyPi and have to built it from source.
If you are on x86 and use a distribution with glibc I wouldn't expect any problems.
It's tricky, because most phones can't be flashed with an alternative aftermarket OS. I know that LineageOS etc. exist, but most phones don't have a stable build and a lot of SoCs will never work reliably with an aftermarket OS.
In that case whoever will exploit your phone first is the one who owns it, not you.
This has been a problem for a long time. I'm not sure why other distributions are better at this than Debian, but I think it has something to do with how Debian splits up software in much more packages than other distributions. Maybe it's more difficult to keep track of the state?
So you think this isn't the case with home users? Maybe I still misunderstand the point that is being made here, but from my perspective it's only a matter of time until my encrypted password store gets exposed to the local attacker (as soon as I unlock it).