E-mail, designed in the mid-80's by and for computer geeks, in a tiny, trusting little pre-web internet, is a seriously crappy fit for the modern world.
But good luck replacing it.
Random idea: Add a few commands to ESMTP, which allow the mail server to tentatively accept an e-mail for delivery, then examine the message, then either handle it normally...or, optionally, do some basic back-and-forth with the sender. "Do you really want to sent this to 17,000 recipients?" "Your 50MB attachment is too large for reliable delivery." "Your system has the Zandu-j84 virus; an alert was sent to the IT Dept." Etc.
There's a whole lot of current computing that is just hacked together on top of unscalable bad-in-retrospect ideas from the 70s and 80s. If I had a couple billion dollars I'd be interested in hiring a small group of very bright people to see what building a computing platform and infrastructure from scratch with no concern for compatibility with the current paradigm would look like.
If you only had mid-5-digit dollars to spend, I'm thinking that a well-thought-out ESMTP protocol enhancement, submitted RFC, and implementation in a few open-source email client and server software packages would be well within reach. Basic server-side implementation could mostly be done with existing-language scripts - "IF( Total_Message_Size > 50M ); THEN..."
These days we accept that a reduced instruction set is a better idea, but those bloated instruction sets barely take up any any space on the chip anymore compared to all the caching we do.
A couple examples of the kind of thing I'm talking about:
Why is vsync still a thing? Originally it came from how broadcast TV worked with CRTs, but the fundamental technologies are different today. Yet, we still update the entire screen, all at once, on a fixed rate timer with blanking intervals[0]. I'm certainly not an expert in how LCDs work, but my understanding is that there is no fundamental reason we cannot update different parts of the screen at completely different rates or on-demand. We just don't do that, because the convention is a stream of pixel data from top left to bottom right.
Or take process memory isolation and remapping. There's a lot of overhead there, and the whole thing looks like a solution to make a program think it has all the memory to itself and no other processes exist, and then we have to work around that specially to let them share it, and still have to add extra complication to deal with malicious jumps, and now timing attacks. What if there were a better way, so long as your programs didn't essentially act like they were running on a Commodore 64?
What could something like Unicode look like if it had never had to deal with any kind of legacy nonsense, han unification, or the UCS2/UTF-16 debacle? Oh and if it didn't have such an obsession with emoji.
Those are just off the top of my head. Undoubtedly my lack of expertise in these domains means I'm probably missing or misunderstanding some things, but I think there is practical value in occasionally re-examining all of our assumptions and starting from scratch.
[0] Free/Gsync exists now, but we still update the entire screen.
RICS vs CISC was never about the size of the instruction set. It's about human usability vs. bare expressivity.
The unusable, highly orthogonal, composable sets are more efficient than the usable, interdependent, all in one piece instructions. At least with our current compiler tech.
My personal favorite are the emails with a image at the bottom reminding me not to print to save the trees/environment with out realizing that in most cases the image has at least doubled the size of the mail and everything that goes with it from a a transfer storage and display perspective even if miniscule.
Not exactly what you are asking for but many MTA's do have options to limit recipients and ways to make exceptions so there are ways to protect against this and limit who can send to many people. Many enterprise mail servers have something similar to this as well.
I have no idea what the military are using these days. They mention Outlook in the article so I assume they are using O365 or whatever it was renamed to. O365 has the ability to write rules based on AD group membership to limit who can mass email. Perhaps the military can temporarily take away those permissions until people have had training.
Hey man, just a heads up: You're currently shadow-banned on HN so your comments are automatically hidden. I don't think there's anything you can do about it but I'd want to know.
I feel comfortable telling you because most of your content isn't inflammatory, so I fear you might have been wrongly filtered out.
careful, dang will threaten you for doing this. I used to do this, and he eventually showed up and said to stop.
i encourage others to question this behavior and vouch gratuitously, otherwise we'll hivemind ourselves. when vc stops being en vogue, hn loses about 50% of its luster, and whats left will rely on the quality and diversity of discussion here. the day will come where yc shits the bed and there is someone new, don't leave yourself without a nerd community if/when that happens by encouraging samethink.
edit: now the user's <5 minute old grey posts are un-vouchable. this is fucking pathetic
Computer literacy is at no time covered while in the Army from my recent experience. It was required how ever to do a lot of those online Army classes each quarter. It would turn into entire days of people trying to figure out how to just login. Almost all admin duties from soldiers at any level has moved to a digital format and yet still often using Windows XP or the site requires running IE in a weird compatibility mode. All of this means we can quickly lose an entire day of work trying to get people to reset their passwords to do a 15min safety quiz or check if they have a dental appointment.
> What were they going to do, send paratroopers at it?
I think the balloon was flying at 60,000 feet. I'm not qualified to know if paratroopers can operate at that altitude, but it sounds tough. They'd need oxygen at the very least.
It would certainly make for a cool scene in a movie, although it seems pointless?
In military operations, HALO is also used for delivering equipment, supplies, or personnel, while HAHO is generally used exclusively for personnel. In typical HALO/HAHO insertions the troops jump from altitudes between 15,000 and 35,000 feet (4,600 and 10,700 m). Military parachutists will often reach a terminal velocity of 126 mph (203 km/h), allowing for a jump time under two minutes.
...
All types of parachuting techniques are dangerous, but HALO/HAHO carry special risks. At high altitudes (greater than 22,000 feet or 6,700 metres), the partial pressure of oxygen in the Earth's atmosphere is low. Oxygen is required for human respiration and lack of pressure can lead to hypoxia. Also, rapid ascent in the jump aircraft without all nitrogen flushed from the bloodstream can lead to decompression sickness, also known as caisson disease or "the bends".
---
You'll note that the numbers there are much less than 60,000 feet.
The altitude here is closer to the ceiling for the U2 spy plane (famously known for being high altitude) at 70,000 or so feet.
Do Apaches fly high enough for an intercept of something flying at 60k feet? I woupd have rather called in the Space Force with an invisible F-45 or something.
Airbus Helicopters holds the record for the highest take from Mount Everest's summit, they didn't play around with anything less the highest point of earth.
But ok, a sidewinder shot from a Apache flying at the top of his ceiling should do the job as well. My personal pet theory so is, that some USAF pilot wants to become a fighter ace of aces for balloons and is using his political connections within the USAF and the Pentagon to lobby for enough balloon shoot downs to get there. Come thinking of it, maybe it is the USAF fighter pilot community launching those balloons themselves???
How many folks, or at what age cut-off, know what the "CC" stands for? And how many know where the 'carbon copy' term comes from?
For those that don't know:
> A sheet of carbon paper is placed between two or more sheets of paper. The pressure applied by the writing implement (pen, pencil, typewriter or impact printer) to the top sheet causes pigment from the carbon paper to reproduce the similar mark on the copy sheet(s). More than one copy can be made by stacking several sheets with carbon paper between each pair. Four or five copies is a practical limit. The top sheet is the original and each of the additional sheets is called a carbon copy.
Given the existence of bcc, this is as much a sysadmin failure as it is a tech illiteracy failure. This mail should have been bounced by the outgoing SMTP server.
The client is almost always unaware of the true size represented by an alias for a group it does not manage. These are the source of the big storms in my org.
My father-in-law works for a defense contractor around DC and works with and travels to allied countries on classified + items. He has several stories of him and his colleagues at his office being on the receiving end of un-intended reply-alls with the end result in most cases of a military team coming to the office and physically taking away all the computers that had been on the receiving end of the reply-alls.
But good luck replacing it.
Random idea: Add a few commands to ESMTP, which allow the mail server to tentatively accept an e-mail for delivery, then examine the message, then either handle it normally...or, optionally, do some basic back-and-forth with the sender. "Do you really want to sent this to 17,000 recipients?" "Your 50MB attachment is too large for reliable delivery." "Your system has the Zandu-j84 virus; an alert was sent to the IT Dept." Etc.