drzaiusx11

Very hard on queens in particular

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 still recall when java first came out, its all relative--but sure, a decade can seem like eons in software.

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.

I switched to a nxtpaper pro phone which has a hardware switch for bw vs color modes and an e-ink like display (not as good but close enough)

I love it, mostly because it forces me to use phone less..

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...

Tmux is n clients to 1 server.

Screen is 1 server to 1 client.

In screen each client session is a fork of the screen server. In tmux there's one server and many client forks iirc.

Fun fact, Snow Crash was originally written as a video game script (and it shows.)

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.

Maybe I'm just not tapped into the community but I've been a ruby developer going on 6 years now and I find debugging ruby apps no better or worse than any other languages I've worked with over the years. It's fairly easy to instrument ruby much like all the other dynamic languages (python3, js, etc) but with better ergonomics. My main qualm with ruby is their reliance on external type files for type annotations. What a terrible idea. Should have just done inline optional types like python3 or typescript.

How does this microvm/sbx compare to lima (what Colima uses)?

I thought they were already heading in that direction with the single window mode merging. But ok sure I guess they'll never change anything because a sister project existed 2 decades ago or whatever.

How do we get this into mainline GIMP? As a GIMP user since it existed, I can say that the default interface "works" but the ux isn't great. This looks like a marked improvement and would give me something more like Inkscapes UI but for raster images instead of vector...

I'm so fucking tired of jumping ship with these password vault providers. This will be my third jump in so many years.

Exactly what value do they think they have left to extract from me? I'm a paying customer for a product that essentially just stores an indexed list of strings with at-rest encryption.

Their official App's autofill on my phone hasn't worked for several months now., I literally have to login to it once every couple hours just to manually copy and paste my usernames and passwords separately. I guess enshitification knows no bounds?

Requiring a reverse proxy for TLS is pretty standard, but the rest of those findings are egregious (if they haven't been addressed yet.)

Glyphosate use didn't really explode in use until the genetic modification of "round up ready" crops in 1996.

The real danger was the havoc it'd play on my gut biome.

To be frank, we live in sad dark HN loser times.

Depends on the domain really, along with you and your user's aversion to risk. On average I'd agree your take holds true though.

Good.