When the article mentioned email matching, I was concerned that it would break down when a contributor's email address changes. (I have contributed to more than a few projects over the years, using email addresses that no longer exist.)

However, it looks like they're not using the email address recorded in the author's original git commit, but instead a GitHub-generated address whose unique parts are the GitHub user ID and username. That should survive authors changing their email addresses. It would still break down if a contributor loses access to their account and has to create a new one, but that's probably less common.

At the same time, it's often technically true, but for a good reason that you neglected to mention:

Those old tools tend to be very capable email clients, not web apps with their awkward attempts to simplify complex conversation structure. A good email client can handle large, high-traffic, frequently branching, long-lived threads with ease. All the web forums I've ever used fail miserably here.

The people who are tasked with participating in large scale discussion groups (like the LKML) know this through experience. They prefer email because it works better. It makes their lives easier. It helps them to be more efficient, which is absolutely necessary given the sheer volume of messaging that they handle.

Yes, a specialized tool is required to get these benefits, just as a specialized tool is required to make web server output easily readable. Thankfully, these tools have existed for decades.

https://www.displayspecifications.com/en/model/f86e3770

https://www.displayspecifications.com/en/model/49bc3e67

20 years ago, Mercurial was not the wrong choice.

- Its internal design was very similar to Git's.

- Its cross-platform support was superior to Git's. (Git didn't get good Windows support until some years later.)

- Its ergonomics were superior to Git's, which was an important factor on its own, and especially important when trying to get a whole organization to retrain and retool around a distributed model.

- (It had a third major advantage over Git that I unfortunately cannot recall at the moment.)

So you weren't wrong back then...

...but Git improved over time, tipping the scale closer to a balanced state. It also had unbeatable author recognition, making it the obvious choice for anyone unaware of Mercurial's advantages, and eventually leading it to benefit from the network effect. And GitHub appeared, greatly improving Git's ecosystem with no support for Mercurial.

So while I believe you about all those difficulties existing today, it's plausible that they would mostly fade away over time. I think temporary growing pains would be an acceptable price for the significant long-term public benefit.

Then let us hire different leaders into government. Public servants, not overlords.

Many of us find it unethical to give money to scalpers.

> a handful of .net domains that are under $100

And this is why.

I suppose it might be true for .city.state.us subdomains, but those fail my first criterion (they're not short), and are themselves a privacy hazard since they substantially narrow the search space for personal info about the domain owner. So it doesn't refute my criticism.

Unfortunately, it forbids WHOIS privacy services, which makes it a privacy and security hazard for personal domains. Pity, that.

https://en.wikipedia.org/wiki/DEX_(protocol)

https://www.cable-tester.com/dex-connector-pin-out/

https://www.storedex.com/abcs-of-dex

I assume the possibility of spurious Rx state is why FTDI chose to wire Rx to the tip pin of the female TRS connector: It's the last pin to make contact with anything when plugging in, and therefore least likely to be bridged to ground. I suppose the mechanical design of any particular jack would determine whether it's possible at all.

The same issue applies to PCB header pins.

And the same goes for 25-pin D-sub connectors, which have been widely used as RS-232, parallel printer, and SCSI ports.

Voltages vary, too.

This is why we check before wiring them to other things.

But yes, if someone happens to be using their serial line for some kind of sensitive signaling, then I would agree that choosing a more isolated connector (or just avoiding hotplug) would make sense.

I added one to my single-board computer enclosure, following FTDI's wiring. Now I can easily connect whenever I need to use the serial console, and a standard 3.5mm audio extension cable will let me reach across the room without moving my main computer. Replacement parts, if I ever need them, are cheap and easy to find.

Here's the pinout:

https://www.ftdichip.com/Support/Documents/DataSheets/Cables...

Languages with rich standard libraries provide enough common components that it's feasible to build things using only a small handful of external dependencies. Each of those can be carefully chosen, monitored, and potentially even audited, by an individual or small team.

That doesn't make the resulting software exploit-proof, of course, but it seems to me much less risky than an ecosystem where most programs pull in hundreds of dependencies, all of which receive far less scrutiny than a language's standard library.

It is a special when the usual price is $2 each.

> Why not?

Because I'm not interested.