"Groupthink", as the term is used by epistemologically isolated in-groups, actually means the opposite. The problem with the idea is that it looks symmetric, so if you yourself are stuck in groupthink, you fool yourself into think it's everyone else doing it instead. And, again, the solution for that is reasonable references grounded in informed consensus. (Whether that should be a curated encyclopedia or a LLM is a different argument.)

Definitely not! I absolutely do not want an LLM that gives much or any truth-weight to the vast majority of writing on the vast majority of topics. Maybe, maybe if they’d existed before the Web and been trained only on published writing, but even then you have stuff like tabloids, cranks self-publishing or publishing through crank-friendly niche publishers, advertisements full of lies, very dumb letters to the editor, vanity autobiographies or narrative business books full of made-up stuff presented as true, et c.

No, that’s good for building a model of something like the probability space of human writing, but an LLM that has some kind of truth-grounding wholly based on that would be far from my ideal.

> And, again, the solution for that is reasonable references grounded in informed consensus. (Whether that should be a curated encyclopedia or a LLM is a different argument.)

“Informed” is a load bearing word in this post, and I don’t really see how the rest holds together if we start to pick at that.

I have to be misunderstanding you, though, because any time we want to build knowledge and skills for specialists their training doesn’t look anything like what you seem to be suggesting.

> "Groupthink" informed by extremely broad training sets is more conventionally called "consensus", and that's what we want the LLM to reflect.

It's nothing to do with how LLMs work that I wrote what I did, but with this "ought" suggestion of how we should want them to work.

I would rather have an actual audio engineer's take than than the opinion of an amalgamation of hifi forums' talking pseudoscience and the latter is way more numerous in the training.

Yes you do, often. Understanding ideas and consensus is part of understanding "topics". To choose a Godwinized existence proof: an LLM that didn't understand public opinion in, say, 1920's Germany is one that can't answer the question of how the war started.

You're making two mistakes here: one is that you're assuming that "facts" exist as a separate idea from "discourse". And the second is that you appear to think LLMs merely "average" the stuff they read instead of absorbing controversies and discourse on their own terms. The first I can't really help you with, but the second you can disabuse yourself of on your own just by pulling up a GPT chat and talking to it.

Uh... Xorg is packaged by FreeBSD too...

Really the whole theme that (from the article) "FreeBSD ships as a complete, coherent OS" is belied by this kind of nonsense. No, it's not. Or, sure, it is, but in exactly the same way that Debian or whatever is. It's a big soup of some local software and a huge ton of upstream dependencies curated for shipment together. Just like a Linux distro.

And, obviously, almost all those upstream dependences are exactly the same. Yet somehow the BSD folks think there's some magic to the ports stuff that the Linux folks don't understand. Well, there isn't. And honestly to the extent there's a delta in packaging sophistication, the Linux folks tend to be ahead (c.f. Nix, for example).

Ehhh... not exactly. With nothing but the smallest FreeBSD installer image, you can, if you include just one optional package, have a system that is capable of entirely recompiling itself.

You might say "who cares?" and that's fine. But it is "complete" in a sense that no linux system I know of is. I admit that I don't know what it would take to install from, say, almalinux-10.0-x86_64-minimal.iso, and end up with a system capable of recompiling itself, but I expect it would be a whole lot more work than that. Could be wrong.

This kind of problem happens frequently when users add repositories such as Packman on Linux providing dependencies versions different from the ones used by the base system of the distro.

Experienced people know how to avoid these mistakes, but this whole class of problem does not exist on FreeBSD.

This is no longer the case in "immutable" distros such as Bluefin/Aurora, which uses ostree for the "base" distro, while most other user packages are installed with homebrew. Nix and Guix solve it in a very different way. Then there's flatpak and snap.

A lot of poor *BSD advocacy likes to deride Linux for its diversity one moment, then switch to treating it as a monolith when it's convenient. It's a minority of the users for sure, but they naturally make an outsized share of the noise.

I think you missed the point in my original comment. I explained I moved my platform with all dependencies and had 1 bug which was actually a silent bug in Linux.

In other words, it works. Your particular stack might have a different snag profile but if I can move my giant complex app there, yours is worth a shot.

FreeBSD is more complete than you make out. They also have hard working ports maintainers.

Well, sure, but that's a ridiculous double standard. You're making the claim (or implying it, at least) that FreeBSD is fundamentally superior because it's a unified piece of software shipped as a holistic piece of artifice or whatever. And that by inferrence it's unlike all that kludgey linux stuff that you can't trust because of politics or whatever.

But your evidence that it's actually superior? "it works". Well, gosh.

You'll tar the competition with all sorts of ambiguous smears, but all you ask from your favorite is... that you got your app to work?

I never said anything about that. Again in my opening comment I listed the reasons I like it. It’s boring and stable which is what I like to center my work on. I even provided a specific technical example of superior memory management.

In any case, what I personally find more problematic than just slowness is electron apps interacting weirdly with my Nvidia linux graphics drivers, in such a way that it causes the app to display nothing or display weird artifacts or crash with hard-to-debug error messages. It's possible that this is actually Nvidia's fault for having shitty drivers, I'm not sure; but in any case I definitely notice it more often with electron apps than native ones.

Anyway one of the things I hope that AI can do is make it easier for people to write apps that use the native graphics stack instead of electron.

Gen X and Boomers strangely enough managed to write portable native code, across multiple hardware architectures, operating systems and language toolchains.

As is an insurmountable challenge apparently, to master Web UI delivery from system services, daemons to the default browser like UNIX administration tooling.

If McDonald’s hamburgers taste like warmed-over shit, why are they the most popular in the world?

From the person you're responding to:

> I would guess a moderate amount of performance engineering effort could solve the problem without switching stacks or a major rewrite.

Pretty clearly they're not saying that this is a necessary property of Electron.

Try enabling 10k lines of scrollback buffer in vscode and print 20k lines.

Setting that aside, I think you learned the wrong lesson here. There's no fight. Performance comes from app architecture engineering more than the underlying tools. Building on the trash fire that is the current JS ecosystem may make it harder, true, but apps like VS Code, Discord, Slack, etc show that with enough effort a team can use those tools to deliver something with relatively much better performance. The underlying browser engines are quite sophisticated and very efficient for what they are asked to do, it's just a question of good engineering on top of that. Based on the observable behavior I'm guessing the Claude app is doing something like triggering reflow for the entire chat thread every time they append a few characters to the chat. Totally avoidable.

The big reason web tech is ubiquitous is it has the best properties for distribution. That may last a little while or a long time, but there is no fundamental reason why it's more durable than say Win32 and MFC.

Thunderbird is a fully-featured mail app and much more performant than Gmail. Neovim has more or less the same feature set as VSCode and its performance is incomparably better.

TB is great and I use it every day. An argument for it from a performance standpoint is ridiculous on its face. Put 10G of mail in the Inbox and come back to me with measurements. GMail laughs at mere gigabytes.

Using market success to excuse poor UX is pointless.

"adread", meaning afraid

Still a recognizable archaic word, constructed from a still-in-use root. Just the spelling is different.

And we know in practice that Trump TACOs out rather than pick real fights with established powers. Markets don't like it when regulatory agencies go rogue vs. the rule of law. They'll just shift gears to something else.

Trump Always Chickens Out (TACO) is a term that gained prominence in May 2025 after many threats and reversals during the trade war U.S. president Donald Trump initiated with his administration's "Liberation Day" tariffs.

The charitable explanation is that he chickens out when confronted with real backlash.The less charitable explanation is that he 'chickens' out after the appropriate bribe has been paid to him.

1. That's transparently NOT what the white house said the tariffs were for.

2. There has been NO significant change (via negotiation or not) in non-tariff trade policy under this administration. Essentially all those "announcements" of "deals" were, were just the acts of rolling back the tariffs themselves. No one caved. We didn't get any advantage.

It's just absolutely amazing to me the degree of epistemological isolation the right has created for it in the modern US.

Uh... yeah? That's true of basically all platforms, and anyone who says otherwise is selling something.

> it gets painful once you leave that path

Still less painful than being zero-day'd by a supply chain attack.

> Uh... yeah? That's true of basically all platforms, and anyone who says otherwise is selling something.

What code can you not write in C?

Might be painful for some(many) cases, but there is nothing you can't write in C.

And if you are going to point out compiler extensions, they are extensions exactly because ISO C cannot do it.

This falls under the "selling somthing" angle I mentioned. Yes yes yes, generality and abstraction are tradeoffs and higher level platforms lack primitives for things the lower levels can do.

That is, at best, a ridiculous and specious way to interpret the upthread argument (again c.f. "selling something").

The actual point is that all real systems involve tradeoffs, and one of the core ones for a programming language is "what problems are best solved in this language?". That's not the same question as "what problems CAN be solved in this language", and trying to conflate the two tells me (again) that you're selling something. The applicability of C to problem areas it "can" solve has its own tradeoffs, obviously.

The point is someone needs to curate those "deps". It's not about rolling your own, it's about pulling standard stuff from standard places where you have some hope that smart people have given thought to how to audit, test, package, integrate and maintain the "deps".

NPM and Cargo and PyPI all have this disease (to be fair NPM has it much worse) where it's expected that this is all just the job of some magical Original Author and it's not anyone's business to try to decide for middleware what they want to rely on. And that way lies surprising bugs, version hell, and eventually supply chain attacks.

The curation step is a critical piece of infrastructure: thing things like the Linux maintainer hierarchy, C++ Boost, Linux distro package systems, or in its original conception the Apache Foundation (though they've sort of lost the plot in recent years). You can pull from those sources, get lots of great software with attested (!) authorship, and be really quite certain (not 100%, but close) that something in the middle hasn't been sold to Chinese Intelligence.

But the Darwinian soup of Dueling Language Platforms all think they can short circuit that process (because they're in a mad evangelical rush to get more users) and still ship good stuff. They can't.

But what's the threat model here. Does it matter that the Rust STD library doesn't expose say "Regex" functionality forcing you to depend on Regex [1] which is also written by the same people who write the STD library [2]? Like if they wanted to add a back-door in to Regex they could add a backdoor into Vec. Personally I like the idea of having a very small STD library so that it's focused (as well as if they need to do something then it has to be allowed by the language unlike say Go Generics or ELM).

Personally I think there's just some willful blindness going on here. You should never have been blindly trusting a giant binary blob from the std library. Instead you should have been vendoring your dependencies and at that point it doesn't matter if its 100 crates totaling 100k LOC or a singular STD library totaling 100k LOC; its the same amount to review (if not less because the crates can only interact along `pub` boundaries). [1]: https://docs.rs/regex/latest/regex/

[2]: https://github.com/rust-lang/regex

That's not the requirement though! Curation isn't about packaging, it's about independent (!) audit/test/integration/validation paths that provide a backstop to the upstream maintainers going bonkers.

> But what's the threat model here.

A repeat of the xz-utils fiasco, more or less precisely. This was a successful supply chain attack that was stopped because the downstream Debian folks noticed some odd performance numbers and started digging.

There's no Debian equivalent in the soup of Cargo dependencies. That mistake has bitten NPM repeatedly already, and the reckoning is coming for Rust too.

Wasn't that a suspected state actor? Against that threat model your best course of action is a prayer and some incense.

Notably, xz utils didn't use any package manager ala NPM and it relied on package management by hand.

> because the downstream Debian folks

Not sure what you mean by this, but this was discovered by a Postgres dev running bleeding edge Debian. No Debian package maintainer noticed this.

> There's no Debian equivalent

How would Debian approach help? Not even their maintainers could sniff this one.

There exists a sort of extended std library of Rust dep. But no one is using it.

No? They caught it! But they did so because the software had extensive downstream (!) integration and validation sitting between the users and authors. xz-utils pushed backdoored software, but Fedora and Debian picked it up only in rawhide/testing and found the issue.

> Notably, xz utils didn't use any package manager ala NPM and it relied on package management by hand.

With all respect, this is an awfully obtuse take. The problem isn't the "package manager", it's (and I was explicit about this) it's the lack of curation.

It's true that xz-utils didn't use NPM. The point is that NPM's lack of curation is, from a security standpoint, isomorphic to not having any packaging regime at all, and equally dangerous.

> a Postgres dev running bleeding edge Debian

Exactly. Not sure how you think this makes the point different. Everything in Debian is volunteer, the fact that people do other stuff is a bonus. Point is the debian community is immunized against malicious software because everyone is working on validation downstream of the authors.

No one does that for NPM. There is no Cargo Rawhide or NPM Testing operated by attested organizations where new software gets quarantined and validated. If the malicious authors of your upstream dependencies want you to run backdoored software, then that's what you're going to run.

No? Who else has 2-3 years worth of time to become a contributior and maintainer for obscure OSS utils?

Plus made sockpuppets to put pressure on OG maintainer to give Jia Tan maintainer privilege.

> Exactly. Not sure how you think this makes the point different. Everything in Debian is volunteer, the fact that people do other stuff is a bonus.

What you mean exactly? This isn't curation working as intended. This is some random dev discovering it by chance. While it snuck past maintainers and curator of both Debian and Red Hat.

> Everything in Debian is volunteer, the fact that people do other stuff is a bonus. Point is the debian community is immunized against malicious software because everyone is working on validation downstream of the authors.

You can do same in NPM and Cargo. Release a v1.x.y-rc0, give everyone a trial run, see if anyone complains. If they do, it's downstream validation working as intended.

Then yank RC version and publish a non-RC version. No one is preventing anyone from making their release candidate version.

> No one does that for NPM. There is no Cargo Rawhide or NPM Testing

Because, it makes no more sense to have Cargo Rawhide than to have XZ utils SID.

Cargo isn't an integration point, it's infra.

Bevy, which integrates many different libs, has a Release Candidate. But a TOML/XYZ library it uses doesn't.

If say Serde gets compromised then only the projects depending on that version of Serde are as opposed to if Serde was part of the std library then every rust program is compromised.

> That mistake has bitten NPM repeatedly already, and the reckoning is coming for Rust too.

Eh, the only things that coming is using software expressly without a warranty (expectantly) will mean that software will cause you problems at an unknown time.

Not on the menu. The question is do you want them controlled by the US or by China?

Besides security guarantees/defense aegis, the heaviest lifters in U.S. soft power projection are structural and cultural forces that operate largely independent of government:

- Dollar hegemony & financial infra

- Cultural exports

- Universities & research

- Private sector (including tech)

but in this instance I can't help but wonder from a game theory standpoint, is there anything GAINED by affecting USAID in a way in which we clearly lose some (relatively small per your comment) amount of soft power?

That is to say, a perfectly played game would involve not making any sacrifices unless it was to gain some value or reduce some loss. What is gained (or not lost) here?

Domestic 'gain' is fiscal + political + transparency. USAID was pass-through where taxpayer dollars flowed to NGOs and contractors whose missions aligned with whatever administration or congressional bloc was in power – but with enough layers of separation to obscure the nature of the spending.

Foreign 'gain' is a move away from liberal internationalism to transactional bilateralism/resetting expectations wrt American largesse. We were being outbid everywhere anyway, and the org was ineffectively doing something DoS should be doing.

In a thread about USAID it makes sense to talk about the damage to USAID. If these other pillars of soft power matter more to you, then try writing productive comments lamenting their destruction rather than downplaying in this discussion.

> USAID is nowhere near the most effective nor the most important source of soft power for the U.S.

And the goalposts move again. Your original point was that soft power was bad. After pushback, now it's "soft power is good but USAID was inefficient".

I submit that neither of these arguments was presented in good faith and that your real goal is just defense of DOGE.

If you believe this, why did you just go "well, what about China?"

Basically: analysis of international relations and influence techniques can only be correct when it treats with the influence of all parties, and not just the US. You agree with that framing, right?