Your API is constrained by the actual TCP protocol. Even if the sender uses this message-oriented TCP API, the receiver can't make any guarantees that a packet they receive lines up with a message boundary, contains N messages, etc etc, due to how TCP actually works in the event of dropped packets and retransmissions. The receiver literally doesn't have the information needed to do that, and it's impossible for the receiver to reconstruct the original message sequence from the sender. You could probably re-implement TCP with retransmission behaviour that gives you what you're looking for, but that's not really TCP anymore.
This is part of the motivation for protocols like QUIC. Most people agree that some hybrid of TCP and UDP with stateful connections, guaranteed delivery and discrete messages is very useful. But no matter how much you fiddle with your code, neither TCP or UDP are going to give you this, which is why we end up with new protocols that add TCP-ish behaviour on top of UDP.
> but with the expectation that only openai has access to it
You can argue about "the expectation" of privacy all you want, but this is completely detached from reality. My assumption is that almost no third parties I share information with have magic immunity that prevents the information from being used in a legal action involving them.
Maybe my doctor? Maybe my lawyer? IANAL but I'm not even confident in those. If I text my friend saying their party last night was great and they're in court later and need to prove their whereabouts that night, I understand that my text is going to be used as evidence. That might be a private conversation, but it's not my data when I send it to someone else and give them permission to store it forever.
I haven't used it in a few years, but I always found it to be very flexible and useful for non-Qt projects.
I last used it for an embedded project, which are sometimes a pain to set up in an IDE (cross-compiler, sysroot, debug server, etc.), and I was shocked by how easy it was to get going and how smooth it felt compared to most IDEs.
This also stuck out to me, but in defense of Amazon (yuck), I don't see that language directly from anyone at Amazon. They use the regular "reduction in corporate workforce" BS that every big company on earth uses. It just seems like an editorial choice unless I'm missing something.
I work in software now, but I have an electrical engineering degree and started my career on a project developing a radio. Our project probably had ten or more electrical engineers on it, and only one or two of them really understood the RF side of it. It's a very specialized skill -- even EEs with >20 years of experience would describe things as black magic.
So I don't think you're alone feeling this way. Even with a good foundation in the theory and math, I think most people hit a wall with radios at some point. All the people I worked with who intuitively "got" RF stuff had been doing nothing else professionally for over a decade.
A long time ago, worked on a comm satellite program. It used a whack of tuned cans to combine high powered transmit signals with harmonics in each others' frequency bands to feed into the antenna. I once asked how they worked. The answer was 'magic'. I mean, they were physical RF filters, but no one could explain or reproduce how they worked. There was this one guy who could tighten the screws that adjusted the inside baffles so they 'worked'. No one else could.
This is veering into pedantry, but from what I can understand of that setting (I'm not a sysadmin guy but have used MACsec on embedded stuff), that's just as much of an 802.1X feature as a MACsec feature.
Sure the switch will only accept encrypted L2 traffic...but that encrypted link is set up via MKA, which is a part of the 802.1X standard. If you don't have 802.1X authenticating the endpoint, you don't have MKA setting up the encrypted link between that endpoint and the switch and you don't have MACsec.
So if you're trying to prevent a bad guy from getting on your LAN, you need 802.1X, whereas MACsec is an optional extra (a very useful extra if you're worried about MITM attacks). But 802.1X is still doing the heavy lifting w.r.t access control.
You run MACsec either with 802.1X, or with your switch vendor's favorite color of proprietary switch-to-switch 802.1X replacement. MACsec without 802.1X [or equivalent] is a bit like TLS without certificates. It exists in a few places because some people have really weird custom requirements (TLS with pre-shared keys… TLS with NULL encryption…) but those things shouldn't drive a discussion outside their special usage areas.
In that sense: MACsec implies and requires 802.1X. Exceptions confirm the rule.
Even if it's not some staggering triumph of human achievement, I'd argue that Ozempic (etc.) is similar. A magic weight loss drug has always captured the public's imagination, and it feels like I've been hearing about new weight loss drug studies in the news for my entire life that never went anywhere.
I think this is more relevant. Like everything, most games today are optimized to maximize engagement and keep people with low attention spans hooked. There are plenty of intelligent people who could invest a bunch of time into solving a puzzle but just don't care to.
I remember playing Myst as a not-particularly-bright grade schooler and banging my head against puzzles for weeks without making any progress. It wasn't some great intellectual challenge -- I was just bored and didn't have any other games to play. I can't imagine I would have stuck with it if I could have watched YouTube or played Fortnite instead.
I never looked into the guts of how this was implemented, but I worked on a product which had an SNMPv3 agent that was only restricted by a username and password. I could flash a PC with a fresh Ubuntu image, apt install Net-SNMP and start sending SNMPv3 requests without every futzing with any keys.
If I remember right, handling SNMPv3 traps required some messy key stuff so the agent still sent SNMPv2 traps, but there was no requirement for keys for GET/SET.
I'm 6'6" and I basically treat an exit row upgrade as non-negotiable. It's just a fundamental cost of long haul travel for me if I can't swing premium economy or business class.
To get some extra legroom, I paid (round trip, in CAD) $250 for a trip to Dublin this year and $320 for a trip to Hong Kong in 2023. That's a lot of money, but it was <50% of the cost to upgrade to premium economy and <20% of the cost to upgrade to business class.
This used to be much cheaper. I remember paying ~$100 for similar upgrades a decade ago, but airlines got wise to this at some point and jacked the prices way up.
This isn't totally dead. I missed a flight last year and got bumped to a flight the next morning on some weird ticket class where I didn't get a seat assignment until the gate. The gate agent was able to give me a bulkhead seat with extra legroom at no cost. And this was with United, not some airline with a shining reputation for customer service.
So you can roll the dice and try to get a premium seat at the gate, but that's not a risk I'm usually willing to take.
Your API is constrained by the actual TCP protocol. Even if the sender uses this message-oriented TCP API, the receiver can't make any guarantees that a packet they receive lines up with a message boundary, contains N messages, etc etc, due to how TCP actually works in the event of dropped packets and retransmissions. The receiver literally doesn't have the information needed to do that, and it's impossible for the receiver to reconstruct the original message sequence from the sender. You could probably re-implement TCP with retransmission behaviour that gives you what you're looking for, but that's not really TCP anymore.
This is part of the motivation for protocols like QUIC. Most people agree that some hybrid of TCP and UDP with stateful connections, guaranteed delivery and discrete messages is very useful. But no matter how much you fiddle with your code, neither TCP or UDP are going to give you this, which is why we end up with new protocols that add TCP-ish behaviour on top of UDP.