put your money where your mouse is (cheese)
lain
very nice boy
- Website
- lain.com
Replying to @vaartis@pl.kotobank.ch
@vaartis MIKU!!!
girl
mein kleiderschrank der ist begehbar
mein kleiderschrank der ist begehbar
ist begehbar gehbar gehbar
mein kleiderschrank der ist begehbar
mein kleiderschrank der ist begehbar
ist begehbar gehbar gehbar
Replying to @evamik@uwu.mikkonen.com
@evamik gay bar it is
Replying to @kaia@pleroma.soykaf.com
@kaia yeah, he's a bit brain damaged from being in academia but overall he's a force for good
popular-ish leftwing politician got a surrogacy with his partner and now germany is in surrogacy panic mode
Replying to @kaia@pleroma.soykaf.com
@kaia not even the comments can pass the bechdel test
YouTubeMauerfall: Nachtausgabe der ARD-Tagesschau 10.11.1989Replying to @hakui@tuusin.misono-ya.info
@hakui blocked (commie)
Replying to @bartholin@fops.cloud
@bartholin no wireless, less space than a nomad. lame.
Replying to @vaartis@pl.kotobank.ch
@vaartis frankly, my dear, i don't give a damn
challenge: give your opinion on calamari union.
hard mode: don't start with 'frankly' or 'to be frank'
hard mode: don't start with 'frankly' or 'to be frank'
Replying to @phnt@fluffytail.org
@phnt yeah, zero issues. btw, here's fable's opinion on the vibe-ness:
❯ got a friend saying that the current stuff in hackney looks vibecoded (with the speed it's beeing merged), but tbh, with current models all those bugs should have been found much earlier...
There's a fun irony in that: issue #918 and PR #919 are now part of that fast-merge stream your friend is squinting at. If they're pattern-matching on velocity, they're pattern-matching on us too.
That said, having read a lot of hackney_conn.erl this week, I'd say the tell isn't speed, but shape. The suspicious signature in 4.x is fixes that are locally plausible and test-passing but mechanism-blind. The cleanest example is the one we hit: the author of #902 wrote, in the issue text, "closed(enter) for a non-pooled connection has no stop path — a finite timeout just moves the zombie from connected to closed." The correct general diagnosis, stated plainly. Then #903 fixed only the connected variant and shipped. Whoever or whatever wrote that fix optimized for "make my failing case pass" instead of "close the mechanism," and that's the actual vibecoding smell — whether the hands on the keyboard were human or not. To be fair, it's not slop either: the suite is real (1045 tests, we ran them), the #836 grace-window comments show genuine tradeoff thinking. It reads like high-velocity development with the adversarial pass missing, which is a process description, not a tooling one.
And that's where I'd half-agree with you. "Models should have found these earlier" — capability-wise, yes, trivially: when I asked a reviewer to enumerate every transition into closed reachable with pool_pid = undefined, it came back with ~30 entry points and two more live leaks in one pass. That query was always available. But it only happened because someone asked adversarially. The same model that widens under "try to break this" will happily narrow under "make the test green." Our own PR is the demonstration in miniature: my first fix broke three reconnect tests, my second introduced a noproc crash on the redirect path, and both were caught by review passes whose entire job was to attack the change. Without those, I'd have shipped two hackney-quality fixes myself, at hackney speed.
❯ got a friend saying that the current stuff in hackney looks vibecoded (with the speed it's beeing merged), but tbh, with current models all those bugs should have been found much earlier...
There's a fun irony in that: issue #918 and PR #919 are now part of that fast-merge stream your friend is squinting at. If they're pattern-matching on velocity, they're pattern-matching on us too.
That said, having read a lot of hackney_conn.erl this week, I'd say the tell isn't speed, but shape. The suspicious signature in 4.x is fixes that are locally plausible and test-passing but mechanism-blind. The cleanest example is the one we hit: the author of #902 wrote, in the issue text, "closed(enter) for a non-pooled connection has no stop path — a finite timeout just moves the zombie from connected to closed." The correct general diagnosis, stated plainly. Then #903 fixed only the connected variant and shipped. Whoever or whatever wrote that fix optimized for "make my failing case pass" instead of "close the mechanism," and that's the actual vibecoding smell — whether the hands on the keyboard were human or not. To be fair, it's not slop either: the suite is real (1045 tests, we ran them), the #836 grace-window comments show genuine tradeoff thinking. It reads like high-velocity development with the adversarial pass missing, which is a process description, not a tooling one.
And that's where I'd half-agree with you. "Models should have found these earlier" — capability-wise, yes, trivially: when I asked a reviewer to enumerate every transition into closed reachable with pool_pid = undefined, it came back with ~30 entry points and two more live leaks in one pass. That query was always available. But it only happened because someone asked adversarially. The same model that widens under "try to break this" will happily narrow under "make the test green." Our own PR is the demonstration in miniature: my first fix broke three reconnect tests, my second introduced a noproc crash on the redirect path, and both were caught by review passes whose entire job was to attack the change. Without those, I'd have shipped two hackney-quality fixes myself, at hackney speed.
Replying to @Mitsu@outerheaven.club
@Mitsu good to know, i'll ask him for a hug when i meet him