The low bandwidth / high latency lossy link problem is still a major issue. Cell phone service is sufficiently shitty in the area I live in that I have to use mosh to get a usable remote connection many times a year. Mosh is also quite useful while travelling! Got a crappy connection on a train or airplane? No problem. I have so much muscle memory with the mutt email client that nothing else has ever come close. Where's the equivalent of mutt's limit command in Thunderbird?

Try getting a usable VNC session when your cell phone hot spot is hitting 2-30 second ping times (yes -- thirty seconds) with only a handful of packets getting through.

Version 2 of the Amiga's operating system did a great thing in version 2 of AmigaOS which explicitly spelled out what conventions to apply (see Amiga User Interface Style Guide at https://archive.org/details/amiga-user-interface-style-guide). Modern GUIs that have weird meaningless buttons are infuriating. Even moreso when they lack obvious keyboard shortcuts.

The real issue at hand is that humans need to decide to start resource constraining AI before it consumes the entire world.

If it were possible to charge $0.25/email for delivery, I'd be more than happy . However, I'm sure large tech firms will need to say that is "too hard to implement at scale".

My scale is that I ran an ISP for ~500 users before the network was disassembled last month. At that scale, you will encounter people that make mistakes with their email setups. When the people who make mistakes are customers which DMARC prevents delivery of emails, it is an issue as those are exactly the people for which I want to see the emails from.

I get more spam with valid SPF and DKIM via Google's own mail servers than DMARC blocks.

It says something when even gmail doesn't use DMARC as a signal that an email is valid, as gmail regularly blocks legitimate mailing list emails with completely valid signatures and non-spam content from a reputationaly sound IP.

The problem DMARC was supposed to solve (impersonation to reduce spam) isn't solved by DMARC.

DMARC does absolutely nothing to prevent the kind of impersonation that occurs in the real world. It doesn't block homoglyphs or or typo-squatting or all the other forms impersonation that matter. It has failed at preventing impersonation.

Just a few days ago I had a phishing email from an elderly woman I had previously done some work for. The message passed DMARC and everything else, and the domain it was sent from was valid. But it was not legitimate; it was an impersonation of her which became obvious once the content was read.

DMARC is noise, not signal. It has to be ignored in the real world as it provides virtually no value beyond blocking emails pretty randomly because someone made a mistake when rotating their DKIM keys or one of a million other mistakes that do happen.

The core problem is that the real need of email end users need is a way of determining whether or not to trust a given sender. Signatures are purely a technical measure which provides no information on the trustworthiness of the sender. The end result is that email scoring still has to be content based, and the signature check technologies are pure noise with no useful signal for the purpose of determining if an email should actually show up in my inbox.

The tech industry has a bad habit of providing solutions to problems adjacent to problems the user actually needs solved while leaving the user's actual problem unresolved.

That said, there are lazy hardware designers that just slap on a block to recompute the CRC and replace the old one with the new. An experience I had years ago at Red Hat taught me that the hard way as a shiny new Cisco ethernet switch IT deployed ended up costing us weeks of frustration and delayed a release when it caused bit flips in NFS packets during stress testing. The switch was so awesomely advanced that it recomputed the CRC on the bit flipped packets causing kernel builds to fail.

Personally, I find it better to have multiple low end access points (like the TP-Link Archer C80 which has 3x3 MIMO on 5 GHz) deployed to achieve excellent coverage in a house. Sadly, the U7 line is a bit too expensive for that. Plus, I'm loathe to deal with UniFi deployments now that I am well versed in the glass jaws in the platform.

There really is space in the market for a product line that is basically what UniFi is, but done "right". Ie: can be debugged or you can fix it without an internet connection or recover the system when the owner forgets the password and lost access to the email account used for 2FA. UniFi is an absolute nightmare the moment anything goes even slightly wrong.

This is really starting to feel like the pets.com era again.

The sad thing is that the relationship probably cannot be rebuilt anytime soon. It will take decades to restore trust that was damaged in a few short years. Canada is forced to diversify and build closer relationships with less volatile nations across the world. This is probably good for Canada in the long term.

Persistent ethX names were far better to me, and we had those before enpXXX via udev. At least then when I logged into a random system with a single NIC it was called eth0. With 2 NICs they were eth0 and eth1. Simple to predict, no thinking required (unless the system already had bound those names to other MAC addresses).

Usability dies by a thousand cuts. Forcing needlessly complex behaviour onto people with simple use-cases is not an improvement.

Now if only every other website on the internet would learn that latency matters...

"Those who cannot remember the past are condemned to repeat it".

Yes, I wish software developers were more like actual engineers in this regard.

Back in the MS-DOS days, the amount of data needed to be read off a disk while the OS booted was negligible, so a second or two on a fast 486 felt amazing compared to the incredibly slow grind of watching code execute on an 8086 or slow 80286. Software was still in the space of having to run tolerably on an 8086, so the added resources of a newer faster machine actually did improve the feel of the system.