Cool story bro. Assuming that's common, I have trouble understanding why Arch (non-AUR) is any more at risk than Debian--besides the latter being more popular and having more users/incidental testers, which is a real benefit if that's your goal, but has its own drawbacks (like older and known-vulnerable packages lingering for longer before updated releases are made available).

> it's not reasonable to ask package maintainers to spend all their time on those stuff, especially in this "Age of AI"

Aren't Debian and friends similarly at risk of this as well, then?

> security practices (such as TOTP, sandboxing browsers and video players, etc.)

I'm not sure if those are more or less prevalent on Arch; I know that many IDEs and GUI programs I've installed on Arch ran by default in Flatpaks or similar, and Debian/Ubuntu like Snaps, but I'm honestly not familiar with whether those ecosystems have significant and/or equivalent penetration in different distros.

The AUR is, as many others have pointed out, a deliberately un-vetted pile of random Git repos. Arch deliberately doesn't even ship with a default one-click installer for AUR packages; their published guidance is "git clone this stuff from wherever it's hosted and build it at your own risk". Plenty of third-party, non-Arch-blessed tools turn that into a one-click process, but it's not "part" of Arch itself--at least not any more than, like, curl | bash or directions on how to add rando websites to /etc/apt/sources.list.d is part of Debian and friends.

I've used Arch as a daily driver for years. At peak, I've had five (5) total packages, with no transitives, installed from the AUR. Today I have one: sublime-text-4. It's perfectly possible--and extremely reasonable for many users, even power users--to live in an AUR-less world, or to use so few AUR packages that the guidance of "read what you're installing, doofus" is manageable and not onerous.

It’s likely a better use of anthropic’s resources to try to get the export controls lifted by appeasing the government. I’m not saying that’s a good thing; it’s a stupid situation to be in in the first place for reasons many others in this thread have pointed out.

All of the government’s options to retire/ban Fable entirely would have required expensive protracted (potentially years long) legal battles. The government wanted to make Anthropic feel pain in the short term, so they looked around for pre existing laws that could be exploited to do that.

Enter export control—a law that doesn’t require banning a product outright to effectively ban it for everyone. Because Anthropic has no way of telling whether a given user is a foreign national, and because even a few false negatives in any check they did for that would expose them to serious criminal charges, they had to disable the model for everyone. The government knew very well that they would have to.

It’s similar to GDPR in a way. For GDPR, tons of websites started complying for all their users worldwide, simply because IP location detection is too fallible, and the legal costs of even a small number of detection failures for EU citizens were potentially steep.

> do stuff in parallel either by hand or by terraform

…specifically by terraform. Making k8s own the provisioning and management of external infrastructure on principle (as opposed to when that makes sense, e.g. load balancers/gateway/CSI providers) is not a good approach. Sure, it feels unified, but the cost of unification is incredibly not worth it.

That, and even those clone-without-pagetable-copy improvements leave a lot of slowness on the table. Being able to skip even disable-able functionality intended for fork would simplify code. Also, for programs that launch the same subprocess many times, a better API might allow caching away some of the pre-entrypoint initialization of exec.

Not what I said at all. Note the “even if I grant … (which I don’t…)”.

And reduced illness, increased education, increased access to better nutrition, increased lifespan, increased able lifespan (knees/back/teeth don’t give out as early), and lots more.

Like, even if I grant that this replaced human connection (and I’m not sure that’s true, nor am I sure if it is meaningfully true—access to water replaces thirst, too), some very substantial benefits were acquired in return.

I don’t think that’s because of birth rate decline. While authoritarians give lip service to that occasionally, it’s never their primary cited reason (which is usually some combo of religion, purported return to “traditional” prosperity via reduced promiscuity, aggression against feminist political opponents, etc). Also, most authoritarians aren’t that long-term in their goals.

People buying more chocolate ice cream than vanilla? Could be changing preferences or Hersheys marketing, or it could be undetected brain worms. People voting for one political party over others? Could be that party is campaigning/governing in a more popular way, could be brain worms.

If there’s evidence of contaminants or whatever influencing behavior strongly enough to change large scale demographic trends, then present it. Otherwise, your best chance at good data is to take people at their word when they say why they do things.

Embedding would make local dev/CI integration testing convenient.

Embedding replicated Redis with each application instance would give you HA benefits while infra-management complexity.

Embedded redis (even via local RPC) is still going to be faster than a lot of languages or frameworks’ built-in data structures. Large array operations in, say, Python are gonna slower than RPCing to Redis (assuming that the data structures are built gradually and not built all at once); to beat Redis you’d have to use numpy or something—-which is definitely preferable, but is extra work if your app already uses Redis for other things.

Just like choosing SQLite over e.g. LMDB or RocksDB, embedded Redis would be a nice future proofing option for small apps during the prototype phase; less would have to be changed to move Redis out of the app than if a different cache or persistence service were chosen.

All good advice, but the choice of runtime can affect the point at which autoscaling and load balancing even need to enter the conversation at all. Optimizing, say, a mostly in-memory cache service and writing it in Golang may yield results like "we can run a single instance of this and serve three orders of magnitude of business growth; slap it behind a DNSRR or a k8s NodePort for update/replacement/fast failover if it crashes, no complex load balancer needed", where writing the same thing in, say, PHP might require discussing orchestration/load balancing/memory/worker process recycling/autoscaling early on in the service's lifetime. Being able to skip those conversations (entirely or for a long time) is a very significant business benefit.

Haha yep. In my experience, everyone running CGI/process-per-request application servers is bullish on switching to a concurrent or cooperative runtime...until they realize they just removed the primary ratelimiter on downstream DB/service accesses.

The converse war stories are also amusing: people rewrite their whole app in a concurrent/asynchronous framework and nothing changes, because the DB driver is still farming out all queries to a tiny fixed-size threadpool of connections that was the bottleneck all along.

Take the example of some simple HTTP<->blob store service gets slammed with millions of requests when someone using the API does a backfill via some framework on their end that aggressively scales request volume up and out.

Something like, say, async Python/starlette with a coroutine per request is gonna perform slightly worse than Erlang, which in turn is gonna perform much worse than Go.

You're right that those differences are sometimes marginal when the latency of whatever IO the backend's doing dominates the equation. However, in my experience huge volume surges show issues with the runtime (the thing managing/launching multiplexed request handler routines) or the ecosystem (the backend IO libraries' ability to work with the runtime's IO multiplexing and make things like request coalescing easy or automatic) more often than you'd think.

It really takes surprisingly little volume to cripple a return-hello-world Phoenix app that indirects the "hello world" behind way too much middleware and message passing; it takes even less to kick over, say, a Gunicorn instance returning "hello world" at the bottom of the Django middleware stack. Golang with Gin, on the other hand, is surprisingly hard to cripple in the same way. And I say that as someone who likes Elixir and Python a lot more than I like Go!

I like immutability too; I wish Java and Golang did more of it. It costs a lot in terms of unexpected copies in the BEAM though, there's less copy-elision optimization than you'd think. That especially bites if you're doing a ton of message passing, because of how process heaps are implemented and how garbage collection (traditional or ETS/ThreadProgress-based) works.

I think what I want is something like Golang but with goroutine-based ownership semantics (or Rust with the Go runtime and goroutines): en excellent scheduler for extremely light-weight green threads, no refcounting or reduction counting, and all the clever optimizations around channel sending and copy elision--but no ability to use a value after it's sent to a channel, and only channel-based access to shared global state. That'd get most of the benefits of process-local heaps but without the (copying, cache/memory fragmentation) drawbacks.