I had one of those old phones and it was preferable to have slower performance overall as opposed to seemingly random shutdowns. In reality the shutdowns were directly related to when the cpu was drawing more current than the battery could provide often on websites that had tons of client side scripting.

So before the update I’d be browsing the web and my shit would just shut off and after it would run little slower but stay on.

Iirc they ended up improving the battery management software so it would maximize battery life and suggest when it was time to have it replaced.

If you can figure out how to make a Debian usb installer without help then you’ll be fine.

I don’t think that rust in the kernel is for naught or impeding progress. I think the patterns of expanding the scope of conversation to the absolutely philosophical level that some rust mailing list exchanges have done and kicking decisions up the chain or requesting a set of accommodations be made to the existing processes and methods fall broadly into the tactics outlined in the simple field sabotage manual.

I think it’s that behavior that isn’t going to get anywhere or solve problems.

I don’t think that the kernel codebase has been infected with rust. I think that especially after Linus said “sure, see what happens” to the suggestion of taking in rust work rust devs have been making tons of commits and sometimes it’s accepted, sometimes it’s rejected and often a border is created and there’s friction along it like this example.

It’s surprising to see that statement get brought up in the news considering it’s immediately followed by a parenthetical specifically enumerating a multi language code base as the subject not rust specifically.

Iirc it’s even preceded by something to the effect of “I like rust, it’s good and there’s nothing wrong with projects that use it”.

The news coverage of kernel mailing list stuff is always so needlessly breathless.

Mullvad us Denver 205.

I’m also using their encrypted dns though that shouldn’t matter. Recording an email might be a regulatory requirement of the intelligence sharing treaties of the eu and broader eurozone.

Try an endpoint outside of the western world and see what happens!

I think I got in before they started doing that.

Actually I don’t think they require that. I just set up a new proton account on a device with a fresh wipe from a vpn endpoint I never used before and they offered to record a phone number or recovery email but didn’t require it.

Of course, I only meant that unlike Gmail and such services like proton don’t actively impede your anonymity and build a profile on you as far as we know.

Here’s hoping Apple sticks to their guns and pulls adp instead of caving.

In case you didn’t see it a few weeks ago, 3.3 million servers are doing unencrypted transport.

The way email delivery is handled also means you’re not safe just because you aren’t talking to those servers.

What do you want to know how to do?

The barrier to entry was intended to refer to others since it’s already installed on over half their phones to start with and most people are gonna be using a messaging program on their phone.

When there’s above a 50% chance the person you’re talking to is already using a particular encrypted messaging program that’s the lowest barrier to entry.

The barrier to entry always refers to other people because the hardest part of establishing private communications has always been convincing other people to actually do it.

If you really wanted to get on imessage for the least amount of cash out of pocket possible, the bluebubble bridge application random letters person mentioned is ~$100 for an old mac, and tbh that’s a high estimate in my experience. People are just giving those things away nowadays.

Some food for thought:

Absence of information is its own sort of information. You may find it worthwhile in your search for an acceptable compromise to place some kind of value on “looking normal”.

So go ahead and take a look at your journalctl output. The left hand side should be timestamps, so you can immediately figure out if it’s starting a million years in the past or sometime you know you had the problem.

If it is a million years in the past, use the —since flag and specify the time you want to start at as enumerated in the manual file (man journalctl).

Once you’re looking at the logs in journalctl from a day you know the problem happened, go ahead and use arrow keys and pgup/pgdn to find a reboot. You’ll know when you find a reboot because it’ll look different. The messages will be about figuring out what hardware is attached and changing runlevels and whatnot.

Once you found where the reboot is, go backwards to find something weird happening in the logs.

E: By default the parser (program used to handle text) of journalctls output is “less”. If you want to get out of it, press “q”, and if you want to know more “man less”.