Groxx

Reading this while working for a division that pivoted to provide interfaces for agentic workflows, only to discover that only ten users had ever touched the products we made for agents, only to pivot again to support for agentic workflows, which has a lot of competition because every company has to do something agentic now and there's only like four things you can do in that space, is bracing.

– An editor of this essay

The most popular form of AI psychosis in a nutshell, yea. "AI will understand this for us, so we can be groundbreaking and get rich if we just try" is only possible to believe when you have no idea what you or the rest of your field is doing, and have only attempted to learn about it from "AI", which has spent a lot of your money convincing you that you're brilliant and revolutionary.

It's exactly like surrounding yourself with relentless ego-boosting yes-men. You lose touch with reality. Just take a brief look at any super-wealthy person, they're obviously insane but everyone around them thrives on convincing them that they're not.

---

For the latter customer-facing applications, I have rarely had a pleasant experience as a consumer, with perhaps the exception of live transcription during medical appointments...

These have been abject failures, personally. They've made major mistakes in summaries, and added non-existent symptoms multiple times. Medical transcription seems an especially dangerous place to put them.

"most" is a hell of a claim, yea. "they're going to be useful sometimes and will stick around in some form" has been rather clear from early on (they're Transformer++, of course they'd be useful sometimes), but every session I spend with one still turns into lengthy deeply-misleading wild goose chases until I learn enough to force them down the right path[1]. quality/size of the model hasn't mattered for that, it always happens at some points (and it's just luck whether or not it's a critical point), and I see no reason to expect that it will change.

From memory, the last time I was given a presentation on it, by actual Snowflake staff, they reported that ideal configuration results in something like ~92% accuracy due to the complexity of data at a large business ...

it's exactly this problem. nobody has solved it. lots of companies are trying to sell that they have solved it.

when I don't care about the end result that might be fine (I have used wordpress too), but frequently it ends up that they helped find relevant docs (they're quite good at finding that from vague descriptions, and it's very easy to verify) and I would have been quicker if I had simply read those docs in full. and then I'd have a more complete understanding of the space too. my biggest worry for personal use is that LLMs will write those docs in the future, and be riddled with mistakes :\

1: ...and then they're quite good code dictation tools. people who think "writing code isn't the bottleneck" just haven't spent enough time in well-understood spaces or rebuilt enough wheels. it absolutely can be a several-multiples bottleneck in day-to-day work, or when re-doing something you've done before and fully understand.

I've built custom batch-processors because percona-toolkit's automatic stuff was far too aggressive :|

Every DB needs it, eventually. Even NoSQL darlings like Cassandra - I've seen it go into a resource-constrained death-spiral on stuff that should be async / non-blocking and safe. If you need to stay up, it's always worth planning on, and making sure your logic works during long-running gradual migrations.

Might be because it's water tolerant, i.e. it doesn't break down with exposure to water? Roman über-concrete stories are always full of "check out the concrete that's sitting in sea-water, it's still going strong! maybe it even helps!" cases too.

They've already got anomaly detection: their users.

Also less grease dripping down on them, less water pooling on the flat surface...

* The length() SQL function only counts characters up to and excluding the first NUL.*

The quote() SQL function only shows characters up to and excluding the first NUL.

The .dump command in the CLI omits the first NUL character and all subsequent text in the SQL output that it generates. In fact, the CLI omits everything past the first NUL character in all contexts.

That's just all kinds of "oh no", wow.

I mean, I can't come up with a better strategy, but... oof. C-style strings being a thing at all really hurts.

You seem to be drastically overcomplicating this. They are asking people who are uncomfortable with it to not use it. The people who are uncomfortable with it are the ones deciding, nothing at all in there implies that they are deciding who is uncomfortable.

Why use a license that is designed to be politically neutral and then ask some people not to use it?

Because you can have preferences while not restricting legal rights.

You can have preferences while not restricting legal rights.

You can apply tags to blocks, which make them a kind of thing (a project, an author, a quote, a thought).

Possibly worth pointing out that this is a Logseq thing in general, and not specific to the DB version. And I agree it's pretty great - I don't use it often, but it is very handy when I do. Much more usable than YAML frontmatter, which requires dedicated pages for everything.

Well. Time to look for a new editor again. Ain't no way I'm giving up my dumb file syncing that works for decades.

Maybe this time I'll find one with a sane extension system, so it isn't open-season for malware.

Preloading certainly does seem to be a lost art at times, yeah. It's just so complicated, we might never climb back to such heights.

Yes, I mean it in the sense that the spanner itself and who the spanner funnels money to is so bad that anyone using it has automatically accepted themselves being that bad. Unlike most tools (which the tool analogy leans on heavily), it's very much not an impartial tool, there is no such thing as "using it responsibly" when you're paying Musk.

It's a spanner where every quarter turn costs noticeable money. Which directly funds behavior like this.

The tool analogy is intentionally minimizing, and doesn't capture just how different rented tools with constant surveillance are.

Yup. Anything layout-related could be costly to read, and could force a layout to occur if modified since the last read (even within the same synchronous javascript code). Most things are not deferred until the next layout pass, which is one of the reasons virtual DOM got popular: it batches changes for you.

Personally: make a reading app the only app icon on your home screen on your phone. When reading is the easiest action, you choose it fairly often.

Anubis is by far the least annoying throttler I encounter. Entirely agreed, just crank it up when you get a flood, I much prefer waiting a couple seconds to interacting with custom UI for tens of seconds.

I'm so glad to see that (essentially) HashCash is coming back. Now we just need it for email, like it was originally designed for...

Manipulating "studies" doesn't help reveal how true this is (or even if it is, do we perhaps have an inherent level of addiction and phones are just an easy target?), nor help find effective ways to reduce it.

Does it just use "here" / viewing box as a bias, not a hard cutoff? Personally I definitely expect "here" to mean "absolutely no results outside my window under any circumstances" (with some room for fuzziness with different screen aspect ratios, though even then I expect fewer results, not more). I'm not familiar with what Photon does tho, and it's not particularly clear from a quick skim of the site/readme.

I do have resist-fingerprinting on, thanks! I'll have to poke at that, I'm curious about the technical reasons. A dialog would help, this is the first I've heard of it and I don't mind exceptions for sites that aren't injecting javascript on billions of unrelated pages.

and they're on the edges of the map

I don't think they were very edge-y from what I remember... but I'll double check. And will get a screenshot if I disagree - maybe it's something about window size or display density.

we don't enable category discovery and search at high zoom.

Yeah, I've seen that in a few apps. It's kinda fine when zoomed far out as it's not like you'd be getting a representative distribution, and it might flood more specific (and intended) results out. It broadly makes sense, though I mostly see people confused and frustrated by it in-person (there's rarely any way to tell it has happened). Some of that is just them being overly familiar with only Google though.

But if that category search is not enabled, why doesn't it find business name matches? And why are the results far outside the viewing window?

Also I think that zoom level is almost certainly worth allowing (not necessarily defaulting to) category search. In a dense city it'll overwhelm things, but in much of the USA that might find 2-3 things, if any at all. Maybe it's worth blending in the number of results you'd get if it was enabled when deciding? Like "<10, use category". Or do you also do that?

Prioritisation on search behaviors is super hard, I definitely understand that... but that's why user-controlled options are useful. OSM apps nigh-universally seem to be removing that as the years go by, and the end result is that it's almost unusable because it doesn't let you find things you know exist. Google mitigates it with enormous amounts of ad money and hundreds/thousands of engineers feeding recommendation systems to show 10 decent results out of 100,000 matches (and a lot of learned helplessness by their users), but I don't think that's worth emulating, and they still have a ton of optional controls for filtering. OSM data is convoluted and messy and hard to make convenient, but not having any control at all seems obviously worse to me. Even a `raw-field-name:"value"` seems better, it's passively learnable and fairly easy when tokenized.

---

Lest this all seem like ranting / an upset user: I just have lots of opinions about mapping! And I'm broadly rather unhappy with existing apps. I'm literally always glad to see new attempts, and I don't expect everything to be built for me, so thank you for trying things :) I'm entirely happy to say a ton more or just not be your target audience and stick to technical stuff.

-Wconversion perhaps: https://clang.llvm.org/docs/DiagnosticsReference.html#wconve... or -Wimplicit-int-conversion for the main check I've built in other languages (afaict, I have not used C(++) professionally)

both seem equally undesirable to me in all cases where I intend neither. though one also risks undefined behavior, so that is strictly worse.

the reason I use a type system is to make error classes unrepresentable (where possible) or a failure. these are both leaky abstractions in the worst possible manifestation: silent misbehavior at runtime.

that argument (and many others) also round to essentially "implicit imprecise integer casting is surprising but we do it anyway" which is... perhaps the actual problem???

I've made lints for Go that simply disallow implicit number casting, and omfg the (real, occurring but unnoticed) bugs it found. those kinds of lints are trivial to build, you can just stop doing it. forcing visible casts made many of these problematic patterns extremely suspicious at a glance, catching issues at review time far more easily.

as much as I'm not really a fan of Go, and I would love to spend some time in a language that defaults to unsigned ints by default to see just how pleasant or painful it really is, I do think Go makes a reasonable tradeoff here.

signed ints are rather obviously the majority decision, so that default is defensible, and their const / compile-time math is arbitrary precision. so as long as you can describe your math as either wholly const or can move all overflow-risky stuff into a const equation, you're good - Go's compiler will fail if it exceeds the bounds of whatever number you try to cast it to (implicitly or explicitly).

ignoring fun with float rounding, of course.

signed overflow (or underflow) is frequently undefined behavior. (often because it's undefined in C)

unsigned is frequently defined. (often because it's defined in C)

tough choice.

(honestly I just lean towards "over/underflow should raise unless explicitly allowed", the ratio of unintended to intended-and-fully-checked overflow behavior is almost certainly FAR beyond 100:1)

Game websites are second only to restaurants in average UI complexity. Lots of them do extremely complicated stuff to provide game-realistic framerates to visitors so they can see if it meets their expectations (10fps or so).

(as I can no longer edit)

concretely, here's an example search session: https://news.ycombinator.com/item?id=48825127

I mean it when I say that's "maybe slightly better than average". When it gets extra weird I generally go check the OSM node data out of curiosity, and fairly often I find searches returning things where literally no field at all matches any word I searched for, across many different apps. I don't really think that's an address parsing issue, though I have definitely noticed many apps being picky (but completely unspecified) about search formatting when looking for addresses.

The only thing I'm seeing there is that line-wrapping might do [something], and a suggested workaround (which, oddly, they don't implement on the page). And the line-wrapping issue doesn't look like that to me, at least when I do it.

Without the polarizer, you wouldn't be able to see anything. Unless wearing polarizing sunglasses.

But yea, you'd need light on the subject you're looking at it through to take pictures too.