Someday science may develop a bootloader more braindead than grub

And it shall be called grub3

Zoom acquired Keybase today.

Keybase helped me to identify a trend in the software industry: using a pretty UI to cover up the disruption of an open ecosystem with a closed, centralized replacement. Keybase seemed cool on the face of it - making encryption easier is a laudible goal, and PGP certainly could use the improvement. But, thanks to Keybase, now I ask different questions upfront.

Beware the Keybase formula:

1. Integrates with an existing, open ecosystem
2. May have open-source clients, but server is closed source and does not federate
3. Pretty UI and good marketing
4. VC funded

HTML email is bad and should be considered harmful.

https://jrswab.com/blog/you-need-to-stop-using-html-email

Shout out to @sir for all the useful information on useplaintext.email

#tech #email

I have two simple mantras which establish my philosophy here:

1. YOU are responsible for your dependencies.

2. Open source participants are volunteers and owe you nothing.

It was never Nikolay's job to vet actix-web for you, nor did it become his job when the library became popular, nor does invoking "security" change anything in the slightest. Your dependencies are your responsibility. Responding with vitrol, anger, or hate when failing to uphold this responsibility bites you in the ass is just being a jerk.

User entitlement is totally unjustified and will burn out maintainers faster than almost anything else. I don't stand for it. If any other maintainers out there are struggling with this, please send me an email: [email protected]. I'm sympathetic to your cause and I can likely lend some pertinent advice.

git-via-email workflow tip:

On GitHub, many users will push several commits to their branch to build up one cohesive change gradually, with bug fixes, style fixes, and so on, along the way. In this workflow, the pull request itself acts as a container for the entire change, rather than each commit.

Technically this isn't a great habit for GitHub either, but with email the drawbacks are particularly stark. Trying to replicate this flow for email will have you sending a bunch of "fix typo" commits to a mailing list, entering them all into the record forever. Instead, so long as your original patches are unmerged, you should go back and rebase them to merge bug fixes into earlier commits. Accordingly, you shouldn't take your changes upstream until they're good and ready and tested, as to minimize this churn. Good commit discipline is especially important for email-driven projects.

If you need a refresher on rebasing: https://git-rebase.io

I wonder how much of the death of the "unix way" of having lots of tiny binaries that each do one thing has to do with the ever-rising relative cost of TLB and cache misses due to the fact that CPU pipelines have become so deep, and the slowness of memory relative to the CPU.

One can imagine CPU makers might have pursued a different path had they not been targeting Windows for so long.