Ignoring the ironically missing way to respond to the post beyond the consult page, this is something I used to reliably do, for exactly this reason:
> First, it’s positive and affirming in the aggregate. Despite its scale, the internet can be a lonely place. Most creators create in a vacuum. ... Leaving something adds a little humanity to the internet.
I think I'll try better to re-establish this habit.
While interesting, I get a few questions from this:
- As another commenter said, this is a known disadvantage of averages. I'm curious if it's possible to get a median result from per-individual averages. I'm not familiar enough with how this research is done to get a result.
- Was any effort made to re-test individuals in a second/third/etc session, showing consistent patterns to the brain activity? I know it was consistent within a session, but I'm curious if it might change week over week.
Are you serious? This is the kind of thing you'd ask a clarifying question on and get information back immediately. Further, the huge overreaction from Hegseth shows this is a fundamental disagreement.
This reads as if it isn't trivial to have an HTTP API for your public API in Erlang/Elixir, which is weird. Sure there isn't an included HTTP API for Erlang processes, but why exactly would you want one? They're not for the public internet, as their an implementation detail of your system. The majority of what they're capable of just isn't relevant to the public internet.
It's a normal part of scaling because often bringing in the new technology introduces its own ways of causing the exact same problems. Often they're difficult to integrate into automated tests so folks mock them out, leading to issues. Or a configuration difference between prod/local introduces a problem.
Your DB on the other hand is usually a well-understood part of your system, and while scaling issues like that can cause problems, they're often fairly easy to predict- just unfortunate on timing. This means that while they'll disrupt, they're usually solved quickly, which you can't always say for additional systems.
Genuine question, as I've not invested much into understanding this. What features of the OS would enable these kinds of network restrictions? Basic googling/asking AI points me in the direction of things that seem a lot more difficult in general, unless using something like AppArmor, at which point it seems like you're not quite in OS land anymore.
The main lib everyone uses, :ex_aws, has been actively maintained for literally over a decade[1]. Official or not, it's used by literally the entire community, since even non-AWS services often will support its API.
Config/settings management are often paired with things that require at the very least an app reboot, where Feature Flags are explicitly something that should be capable of changing at will.
Now, could you have real-time config management that doesn't require a re-deploy/reboot of the app? Sure, but the typical 12-factor app can't really avail itself of that without significant rework.
I mean, this mechanism wouldn't make a server operator using entirely non-Google cert authorities more difficult to maintain. I'm pretty cynical on Google these days, but I don't see how this wouldn't be a boon to everybody pretty equally.
- As we've known for years, cryptographically-relevant quantum computers(CRQC) likely could wreck digital security pretty massively
- For HTTPS, 2 out of its 3 uses of cryptography are vulnerable to CRQC
- The currently accepted algorithms that fix these vulnerabilities transmit 30+ times the data of current solutions, which for more unreliable network conditions(like mobile) can introduce latency by as much as 40%
- Because attackers could store data now and decrypt it later with a CRQC, some applications need to deploy a solution now, so Chromium has enabled Kyber(aka ML-KEM) for those willing to accept that cost
- However, other algorithms are being worked on to reduce that data size, but server operators for your applications at the moment can generally only use one certificate, which older clients like smart TVs, kiosks, etc are unlikely to support
- So they're advocating for "trust anchor negotiation" by letting clients and servers negotiate on what certificate to use, allowing for servers to allow multiple at the same time
Honestly really impressively written article. I've understood the risk that a cryptographically-relevant quantum computer would pose for years, but I didn't really know/understand what was being done about it, or the current state of things.
I understand, and what you shared is a perfect example of what I said- but I fundamentally disagree with the notion that it's the same between the two.
I think that in effect, as you associate more behavior with a particular struct(as opposed to what you're attempting to do with said struct), the greater expectation it presents that the struct is what you code around. More and more gets added to state over time, and more expectations about behavior get added that don't need to exist.
Sure, you could say "Well, then just be strict about what behavior is expected in the interface"- but that effort wouldn't be necessary if we didn't make the struct the center of the behavior in the first place.
If people get it wrong so regularly, what value is it providing as a concept? These concepts are supposed to help us reach something better, if you have to add 30 caveats to every part of it, all it did was hide its own complexity from you, instead of managing it for you.
I'd ask what you mean by "fighting the browser"- as generally, the number one way to ruin the performance of your CSS is to introduce depth to it. In general, keeping everything isolated regularly leads to better rendering performance.
> Where I think inheritance works best is when the state in base classes is limited and the interface is quiet clear. Ideally where you are meant to override is also well defined.
What benefit is inheritance providing here? What you described sounds mostly like a struct, at which point the only value the interface provides is possibly some computed fields.
> First, it’s positive and affirming in the aggregate. Despite its scale, the internet can be a lonely place. Most creators create in a vacuum. ... Leaving something adds a little humanity to the internet.
I think I'll try better to re-establish this habit.