FungalRaincloud

I understand having a locked-down version of mass-produced tech that is for the general consumer. However, I also firmly believe that anyone who wants to should be able to bypass that. Make it void the warranty, don't allow customer support, whatever you want. But make it a free option to have complete control. If I buy a piece of hardware, I should own it.

(I say this as I am currently charging a cheap doorbell camera I bought, so that I can start dumping data from it and reverse engineer its protocol, solely so that I can lock it down to my local network...We needed something at the time, or I would have bought something more expensive that had an open protocol...)

A lovely thing in math is that a counterexample, especially if it leads to infinitely more counterexamples in a particular class, can teach you more about the problem. I find this article hopeful. It made me excited about knot theory for the first time in a while.

I'm a bit surprised that you put PHP in that list. My current workload is in it, and a relatively modern version of it, so maybe that surprise will turn around soon, but I've always felt that PHP was more obnoxious than even C to read and write.

Granted, I started out on LISP. My version of "easy to read and write" might be slightly masochistic. But I love Perl and Python and Javascript are definitely "you can jump in and get shit done if you have worked in most languages. It might not be idiomatic, but it'll work"...

Two _is_ more than the average, but not by that much...

He's 77 years old. Let the man retire, damn.

The Hedgehog Review? Yes, they've been around since 1999, and publish a few times a year. But I'm not sure where you're leaping to a strong political leaning. They're an academic journal published by the University of Virginia. I don't religiously follow them, but I've been cursorily aware of them for a while. I don't think I've ever considered them to lean one way or another when reading their publications.

I had something similar set up on my second to last work laptop. I had done some heavy customization that was mostly focused on common workflows for that job, but I have learned that I should still keep a backup even if most of it won't work elsewhere. I should have learned this lesson almost a couple decades ago when I lost all my emacs customizations on a personal computer. But instead, I decided to learn vim.

I think it's important to consider audience. If I'm working with the intent that what I write is legible to folks who only have a basic understanding of math, I'll usually use the multiplication symbol (NOT the letter x, but ×, intentionally in the middle). Someone with more advanced knowledge of math, who may be more inclined to think it's an x, because my handwriting is shit, I will typically use the dot operator. But then there's the whole other audience where I need to define what the dot operator does. At that point, I'm probably pulling up something like LaTeX, because, again, my handwriting sucks.

Funnily enough, when I write for the purpose of math, my numbers are more legible than when I just write down a number. For some reason, I code switch in my handwriting. Kinda obnoxious when I'm filling out forms.

I was advised by a few recruiters to remove all PII from my resume but my email, both for privacy reasons and because it's better to funnel all offers to the same location. I still keep my phone number on there, but if someone really wants my data, it's remarkably easy to find, so I am not really doing much by just removing it from my resume. Oddly, I've had a few people actually try to find more PII on me and fail miserably. They claimed to be good at it, and should have known enough to find at least my legal name with ease. Used to be able to find old AIM conversations of mine if you knew what to search for (or got lucky).

I understand how this works, but for some reason, when I read your comment, I thought of Flappy Bird.

Trust, to me, is not the problem. You can build trust. Known-good certificates can be distributed physically, and require signed messages for replacement. Or, we can develop schemes for distribution digitally via validated channels. For example, each worker at a company has a particular known-good digital presence, verified by their own public key, and distribution happens with them as the source, essentially creating an expanding ring of trust to the key being distributed. Violating such a ring of trust is not going to be easy, if it is well enough built.

There are two issues I do see, though, and they're kind of the same issue. Right now, we have this concept of a central store of public certificates. It makes it easy for you to get a certificate for a particular entity, but it also makes the central store a target. If you can compromise a central store (or a machine that is attempting to access said central store), you probably have the resources to at least redirect the user to your own site and leave them none-the-wiser, and you probably have the resources to man-in-the-middle their connection entirely and just snoop your heart out. So central stores of trust are a bit of an issue, and the ways around that are non-trivial to set up. A good example is probably KeyBase, who allow you to certify your various online presences with your private key. So if someone wants to replace your information on KeyBase with their own one, and they have the resources to do so, now they also have to compromise all the places you've distributed that key to. Or, they have to compromise one of those centralized stores of trust....

The big issue with centralized stores of trust is that they build blind trust. That's the big issue with humans in general, though. We don't want to question what we're watching. And we probably don't want to be bothered with validating that the "trusted source" of the certificate used to sign this content is actually _trusted_. It's just too much mental overhead. We want it to be automatic. We want central stores of trust, because it's just _easier_. The work is going to be convincing people that _easier_ is dangerous, in this case. Or, it's going to be to convince software companies to build in inconvenient technology and not make it trivial to turn off.

I think he is implying that he would personally never use FB messenger, so he would not be able to maintain contact with those friends.

I can't think of a case where that's not just a quick find/replace to fix. Or, if you're using a more modern IDE, a refactoring rule.

Do you have something in mind that might be more complicated?

It's memorable.

Something that does concern me about WhatsApp is that backups of messages (by default, it seems, put on Google Drive on Android) are not encrypted. I'm not really sure why. There's not a compelling reason that I can think of.