It's not irrelevant, because if SPEC 0 says that a particular Python version is no longer supported, then libraries that follow it won't avoid language or standard library features that that version doesn't have. And then those libraries won't work in the corresponding PyPy version. If there isn't a newer PyPy version to upgrade to, then they won't work in PyPy at all.

You might make a different decision if you were targeting PyPy.

Can you explain how this works? Is it different from what's described in the "Language vs. system package managers" section of the post?

Yeah, definitely. Think of it as what the post calls a "system" package manager. The difference between nix and the SPMs mentioned by the post is that in the former case, control over dependencies lies with you, not with the package manager.

In other words, with nix you decide the spec of the software you want installed on your machine, not the maintainer of your chosen package manager. Depending on your use case and knowledge/experience level, either choice may be preferable.

Also, nixpkgs is definitively the widest-spanning "package manager" on the "market"; see link.

https://en.wikipedia.org/wiki/Nix_(package_manager)#Nixpkgs

Yes! Nixpkgs straddles both worlds, like a system package manager it provides a way to install packages and their dependencies. However, like most language package managers it also imposes a locking mechanism so that every input into the nix expression* is locked to a hash, the mechanism is recursive and handles multiple versions of the same package in parallel.

The recent(ish) concept of "nix flakes" means there are 2 related but different mechanisms for achieving this but the end result is the same.

* In the land of NixOS everything is a nix expression including the system packages, configuration files, install image. It's all locked to hashes of upstream sources and is in theory, fully byte-identical reproducible.

IIUC the recent high-profile npm backdoors were mostly detected by supply-chain-security firms that ingest all package updates from the registry and look for suspicious code using automated or semi-automated analysis. Dependency cooldowns work great with this kind of thing. I agree that, if malicious packages were mostly detected via user reports, dependency cooldowns would create a prisoners' dilemma.

I don't understand what you're saying about reporting mechanisms; is there something wrong with how this is currently done?

Maybe a better way would be to allow third-parties to certify releases, and you can specify only to pull the package once they've given it the green light.

Cathedral or Bazaar on and on. We vary in opinion.

IMO we should be using the best easiest information syndication we have for all, that's as decentralized as we can be. That's why I suggested atproto. I believe the Bazaar approach here would be more interesting, and would avoid pressure points of only specific people having the relationships to pull the oh shit alarm.

We have this thing called a "survey"

Less accurate in a lot of situations and costs money to run. It's not a massive loss to use surveys but I see the appeal of prediction markets.

Also surveys don't tell you anything about politics questions other than election outcomes, such as what existing elected officials will do.

The question of what does and doesn't constitute illegal insider trading turns out to be surprisingly subtle, and can vary depending on the type of market. Prediction markets in the U.S. are legally treated as commodities, not as securities like stocks, and insider trading rules for commodities are in some ways less strict. (There are good policy reasons for this; you want to let, e.g., farmers hedge their exposure to the market prices of the stuff they grow, this being the principal reason why we have futures markets, and presumably they have inside information about how their crops are doing.)

Specifically, the CFTC's rules say that it's illegal to "misappropriate confidential information in breach of a pre-existing duty of trust and confidence to the source of the information" by using that information to inform your commodity trades. The MrBeast editor likely did that, but the gubernatorial candidate didn't (he didn't promise anyone that he'd keep his candidacy secret), so if it were just up to government regulators and not platform rules, he'd be in the clear.

Matt Levine writes about this a lot (and is both funny and astonishingly good at explaining the workings of financial capitalism to laypeople); most recently he did so about this particular case: https://www.bloomberg.com/opinion/newsletters/2026-02-25/kal...

Do you think prediction markets need regulation to reclassify them away from commodities likeness?

I don't have any better ideas for what they should be classified as. They certainly aren't securities.

Perhaps new category is needed, unlikely for the next 3 years

Auto-hyphenation is part of what text-wrap: pretty does.

No, it’s not. You can turn it on or off independently.

I consider this a bigger deal than the Pentagon thing.

It’s the same deal

While not surprising at the least, it still kind of crazy that literal pdf files in charge is not concerning, but this is.

I just hope something happens to USA before it can do damage to the world.

What PDFs are you referring to? Do Anthropic or other LLMs using PDFs as some kind of 'SOUL.md' file or for training?

It's a joke way of saying pedophiles -> pdf files.

he means pedophiles

can't say paedophile on YouTube so people say PDF file

But we're not on YouTube.

Op sec is a thing. Gotta avoid the internet crawlers that look for key words.

Tell him that, not me.

They wrote a post (https://oxc.rs/docs/learn/performance) but it doesn't include direct comparisons to SWC.

Their main page says 3x fast than SWC

Yeah, but not how their implementation techniques differ from SWC's to produce those results.

Deno uses V8, which is from Chrome. Bun uses JavaScriptCore.

Ah, yeah. Easy mistake

Oxc is not a JavaScript runtime environment; it's a collection of build tools for JavaScript. The tools output JavaScript code, not native binaries. You separately need a runtime environment like Deno (or a browser, depending on what kind of code it is) to actually run that code.