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.