I've been keeping bees for well over a decade now, and Varroa mite management and prevention of downstream disease vectors like deformed wing virus are consuming ever greater amounts of our time and concern in the community.
Personally, I've tried a number of mitigations with varying levels of success--most all resulting in requeening due to toxicity of treatment. At this point unless a truly successful new therapy is found it seems like a losing battle tbh. I meet monthly with beekeepers and scientists monthly for a few years now, an 99% of the time discussions involve Varroa destructor. It has that name for a reason...
Analog to digital converters (components generally built-in to uCs and SoCs but you can make them using simple resistor ladders) have common resolution ranging usually from 8bit to 24bit in most consumer hardware.
Resolution of +/- 500g just means there's not enough "steps" values in your ADCs provided bit depth: for example the 10bits on an attiny85 gives you 1024 discreet values you can map to weight values etc.
not claiming kotlin invented anything, just that after kotlin adopts something and it turns out to be useful, java will come along in a few years and implement it (or avoid it, depending on how it goes)
I'm honestly happy with java lang's stewardship over the past decade, this particular JEP notwithstanding (it's fine, but the good parts come later.) They're conservative in adopting new features whereas I see every other language bolting on everything under the sun with reckless abandon. I prefer the "let's see what shakes out" and adopt "the good parts" which seems to be Java's approach. Sugar like "var" from kotlin, project loom event loop like nodes, etc.
They just decided to tackle non-nullable value types in a follow-on JEP. I don't think they're saying it's untenable. You don't eat the elephant in one bite and all that.
That said, we've been gnawing on this limb for a while...
Am I understanding this correctly: a value type really only works when it fits on a 64 bit "cache line", and when larger, it falls back to normal heap allocated objects as before? Seems extremely limiting, no? Great for a boxing optimization, but not much else unless you're deal with very small data types regularly...
Reminds me of my teenage years when I'd echo spooky messages to other folks /dev/pttys to freak them out (messages i sent just magically appeared in their open terminals)
Why they didn't lock those down by using different creds per client in the computer lab I still don't know. Maybe it was a VAX limitation (at the time)?
I don't hate it. Covers all the bases: 1.1, 2, 3/quic and solves real problems: get query limitations vs body content & post-without-mutation. Yes there are preexisting workarounds, but they're non-obvious.
Did a bit of digging; the first client gets forked to create the "server". The forked server then detaches and runs in the background. You're right that -x creates an entirely new, separate client process, unrelated to the OG client or the forked server.
Without -x though it works as originally described.
Edit: gnu screen 1.0 was originally released in 1987. The -x flag was released in screen 3.0 in the 90s. TIL
I didn't say you couldn't have multiple clients, I said clients and servers are the same process forked. Or did someone add distinct client/server support to screen finally? I know theres a lot of stuff bolted onto screen over the years but I wasn't aware they dropped forked servers for the tmux model...
I enjoyed snow crash probably up until 2/3rds through, same with cryptonomicon. I truly wish he would stick a god damn landing. I don't know what happens after the halfway marks. It's like a different writer takes over and it jumps the shark. I stopped reading his books after a while when they all seem to go off the rails. Damn shame really.
Any sufficiently large (preexisting) codebase has subtlties and "load bearing" bugs that allow it to function.
In my personal experience, the vibe coded solutions are incapable of delivering "safe" changes outside of anything trivial without breaking something. Folks now just seem to think this is OK? The result is software like my password manager and banking apps no longer reliably work. The trade offs (currently) just aren't worth it imho.
Maybe once we get context windows in the 100M range these systems will handle large scale (and distributed in my case) backend systems just fine. They most certainly are not at the moment, at least not to preexisting backend software systems of modest complexity. Not even close.
I've been pulled into these 90% done vibe-coded projects several times now to "get them over the line" and all I have to say is I wouldn't wish it on my greatest enemy.
PCA (using eigenvectors for dimensionsional reduction) is kinda like moving the axis from an x/y/z grid and onto the shape itself. So it's not 2d in the sense of a simple projection where the loss of information is greater. It has a lot of useful applications, 3d shape recognition is just one.
Using PCA on 3d shapes is a proven method for identification. It's nothing like phrenology aside from both involving morphology. Former actually works, latter does not.