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.
Except we could just treat them the same, and we could have a type system that makes that possible. Multiple languages before Go had a solution to this, that could've been used. Or, it could've written said sufficiently advanced compiler itself.
Crypto right now, while being used by under 1% of population use, uses 40% of the energy of the global banking system[1].
In other words, if it were to increase to even 10% of the population using it, it would use over 4x the energy of the global banking system. If that increased to 50%, it would be 20x.
This would be somewhat mitigated in the case of Proof of Stake, but would simultaneously give major players in the market complete control of said market. Y'know, like a government.
> When we have a society that so willingly accepts and even desires to live in a surveillance state, well, that's a problem. This is a direct path to a totalitarian surveillance state that would be much much more invasive than anything written about in 1984.
The cognitive dissonance in these two sentences is staggering.
> 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.