I think it's worth remembering that this was a storage procedure that was also already abnormal/odd because of the specifics of the existing shielding. I think it's somewhat understandable for a technician to trust that the chemists know what they're doing in that kind of circumstance. If they had concerns, they may have even voiced them, but as is often the case, if the authority confirms that even though it's strange it's correct, it's not surprising that a technician would follow the directive. Even the authority figure may have verbally confirmed, "you said an organic absorbent??" "Yes, that's right, inorganic absorbent." Maybe even in a meeting that was meant to clarify written procedures.
Compiled Lua vs LuaJIT is a major example imho, but maybe it's not especially pertinent given the looseness of the Lua language. I do think it demonstrates that the concept that it is possible to have a tighter type-system at runtime than at compile time (that can in turn result in real performant benefits) is a sound concept, however.
The major Javascript engines already have the concept of a type system that applies at runtime. Their JITs will learn the 'shapes' of objects that commonly go through hot-path functions and will JIT against those with appropriate bailout paths to slower dynamic implementations in case a value with an unexpected 'shape' ends up being used instead.
There's a lot of lore you pick up with Javascript when you start getting into serious optimization with it; and one of the first things you learn in that area is to avoid changing the shapes of your objects because it invalidates JIT assumptions and results in your code running slower -- even though it's 100% valid Javascript.
Totally agree on js, but it doesn't have the same easy same-language comparison that you get from compiled Lua vs LuaJIT. Although I suppose you could pre-compile JavaScript to a binary with eg QuickJS but I don't think this is as apples-to-apples comparison as compiled Lua to LuaJIT.
I simply choose to believe that people do this out of a place of genuine curiosity / excitement to share knowledge. I believe this approach of assuming the best of intentions is even in the HN guidelines! Or maybe it was just the old Reddit ones from long long ago when Reddit was more like what HN is now. Either way, maintaining the background assumption, even when it is challenging to do so, makes HN a far more pleasant place to inhabit.
Just because someone has different taste doesn't make it bad taste. Books have lower resolution still, and they evoke far greater imaginative leaps. For me, the magic lies in what is not shown; it helps aid the suspension of disbelief by requiring you imagination to do more work filling in the gaps.
I'm an avid video game player, and while FPS and sports-adjacent games demand high framerates, I'm perfectly happy turning my render rates down to 40Hz or 30Hz on many games simply to conserve power. I generally prefer my own brain's antialiasing, I guess.
In the broadest sense of the word, aliasing refers to a problem where an insufficient number of samples create a misrepresentation of an intended signal source. I was being a bit poetic, because in graphics programming, where the term "antialiasing" is most often encountered by lay audiences, antialiasing generally refers to X/Y sampling coordinate correction rather than representations across time. It's not usually considered a major issue in vision, because our brains naturally fill in the gaps pretty easily across time for motion (they already naturally do this for eg blinking, you don't see your eyelids when you blink). So usually antialiasing across time is only an issue in audio domains for the layperson, where a misrepresentation of a sample might be perceived as an entirely different pitch, since our ears need >40k samples per second (for accurate high pitches) vs the 24 samples per second that we are accustomed to getting in old fashioned film. When our eyes "miss" a frame or two, our brain is happy to fill in the gaps, ie "antialiasing."
Edit: to clarify, I'm suggesting that some people might prefer to let their brains "fill in the missing frames" rather than see the extra frames shown explicitly. For example, you might be more likely to notice visual tearing at 60Hz than you are to take note of visual tearing at 24Hz when you're already accustomed to filling in the missing pieces, or to a greater extreme, across two panels of a comic strip portraying motion.
That's good, because the "O" should never be dotted. You use slash OR dot for zero, unless you vaguely remember them both as useful for disambiguating but forgot that both marks are for zero and vary by typeface. Mostly dotted zero was just during the dot matrix era. I wouldn't mind being shown counter examples.
The Luddites weren't against automation, they were retaliating against the capital class. Their demands were to have dignified work, not for automation to go away. They attacked the machines because it was the tool the capital class used to deny them their livelihood.
This is why I've been all in on Steam for so long! The catalog is so huge, there's a massive number of fantastic couch multiplayer games. It is indeed a bit more fiddly... I've found that it's generally easier to connect my Steam Deck to the TV and play lower fidelity games than it is to fiddle with a Windows machine that needs to be prepped for friends popping in every other month.
Although, Nintendo is still doing a good job at keeping the couch-social experience alive, and building 1st party games that can be good solo experiences but really shine when played next to a friend sitting on the same couch.
I used to rally friends over for couch gaming years ago. Think I'll try to put something together for Thanksgiving. Been a bit out of the loop - any recent PC couch games you recommend for normies? I think for my group, it'll lean casual / co-operative. Nintendo's always felt too kid-like for us.
"It takes two", "Split Fiction" and "Lego Voyage" are the same style of casual two-player coop. Downside is it's only two players but otherwise may he exactly what you're looking for and very well made.
If you want something a bit different, check out "keep talking or everbody explodes".
Rivals of Aesther - like Super Smash Bros but with Steam Workshop support for player-made characters... TARS (interstellar) vs Ronald McDonald vs Obama anyone??
nidhogg - deserves to be in an arcade cabinet but honestly this one is ALWAYS a hit...just 2player though
Broforce - 80s action stars in 80s action movie multiplayer platformer
Ultimate Chicken Horse - competitively build a platformer level and then race to complete the level first, best with 4 players
TowerFall Ascension - 2-4 players, also deserves to be in an arcade cabinet
Screen Cheat - FPS made for the couch; think N64 Goldeneye or Quake, but all the players are invisible, so the only way to figure out where your opponents are is to look at their quadrants (screencheat)
Overcooked 2 - it's pretty kid-oriented on the surface, but it's a game where you must out-communicate the absolute chaos unfolding around you in order to succeed...such a good couch-multiplayer experience, but best for experienced gamers imho
Rocket League
Magicka
Regular Human Basketball - control giant basketball automatons by jumping inside them and operating the manual controls in a team v team. Minimum 4 players to really work well, supports up to 10 players shared screen
That should get you started! But oops that wasn't my casual coop list, more my "makes for memorable group experiences" list.
It Takes Two, Portal 2, Untitled Goose Game, Halo Master Chief Collection was like $10 recently, all come to mind as positive local coop experiences I've had.
That's been me before. If you're wondering why people ghost at the technical when they seemed like great candidates: sometimes, at least, they like engineering because it's a discipline where they can get things "right" within some defined band / acceptable tolerance. In interview context, where there's somebody watching and judging, the degree of tolerance is unknown, and you know you won't be given time to choose the most correct approach regardless, and that solving the technical problem is just an indirect proxy for solving the "is this person a good social fit" problem (because you know you have the technical ability), all acts as anti-motivator for practicing for leetcode style interviews.
Its easier to say "I just didn't study and that's why I didn't get the job" than it is to say "even though I spent a bunch of time optimizing for this interview scenario and know I absolutely aced the technical interview, they still didn't like me."
Heck, I've been in interviews where I found the technical aspect a relatively easy bar to pass, and I blurted out something strange just to sabotage myself. If they can look past that and still see that I know what I'm doing and bring a lot to the table, I know they are people that I can do my best work with without needing to be constantly second guessing myself in conversation.
Some companies seem to forget that interviews go both ways, and that job candidates are screening for something different than what companies are screening for.
It does if you do DNS over TLS or HTTPS, although I guess that information would still be knowable to your DNS provider if they terminate your TLS behind the scenes
Not quite. In order to make TLS certs work on a per-site basis, requests sent over HTTPS also include a virtual host indicator in cleartext that shows the hostname of the site you’re trying to connect to, so if the IP on the other end is hosting multiple domains it can find the right cert. For this reason some people feel that DNS over TLS is pretty pointless as a privacy measure.
It's still not perfect since you're still leaking information about the privacy set implied by the outer ClientHello, but this possibly isn't much worse than the destination IP address you're leaking anyway.
SNI relies on the client specifying the host name in the unencrypted ClientHello message that initiates a TLS handshake. Encrypted Client Hello involves extra configuration that most websites don't implement.
reply