jakewins

To me this seems easier than the alternative model (logs, metrics, traces), in that you only have one abstraction to contemplate handling PII in?

In what way is this worse than the alternative?

I tried this a while back and found it ended up being easier to just give the firmware agent a dedicated machine, there’s so much low-level stuff you want access to for iterating on firmware, and the docker layers kept confusing the agents when they were debugging faults, crashes, brownouts etc.

Combining a dedicated small machine with a USB hub that supports per-port power cycling lets the agent iterate and un-wedge stuff with no human intervention for very long (days) periods. Obviously any software produced that way is unusable, but it’s incredible for debugging. Agent gets a programmable oscilloscope, power-cycling, and peripherals (also power-cycleable) emulating the various things our product talks to in the wild.

TL;DR I found the docker layers just caused confusion for the agent and giving her an old laptop was way simpler and much more powerful

Related: I just discovered this weekend that you can trivially flash Lego power hubs and then program them from a browser via pybricks.

I don’t want my 7yo to have a phone or iPad, so he’s not been able to use the PoweredUp hubs unless I’m there and can lend him my phone :(

But he has a nixos laptop, and after flashing the hubs he can now program Lego technic with Scratch, no iPad or phone needed :)

What you're touching on is an ancient debate :) Should this part of society be top-down planned or should it be market organized?

I know how I feel about this - I much prefer price signals here; it allows any developer that can meet the spec to build energy production - distributed decision making over centralized decree - and it allows the other side of the equation, consumers, to decide they'd rather not pay for this generation: Curtail demand rather than increase supply.

Like - maybe I don't want to pay energy prices this high, I can choose to insulate my house better or get a heat pump and thus reduce my electrical bill. The price signal lets everyone in the market choose how to act, rather than a central authority declaring we must build, say, more gas turbines and share the cost of that across rate payers.

But, there are people much, much smarter than I that completely disagree with this position. In the end I think the answer is how you feel about human nature, the capability and shortfalls of markets and the complexity of deciding how societies' resources should be allocated.

I can assure you the spreadsheets at firms building plants factor in forecasts of revenue for the life of the plant into investment decisions. If they don’t pay past the first few years, that directly translates to lower forecast lifetime plant value for new plants.

I’m not a quant, and I’ve worked energy trading desks long enough to know there is a lot I don’t understand.. but I don’t see how separating auctions by plant age does anything other than move numbers around while keeping the total bill the same. Plants still need the same lifetime revenue to make investment decisions pencil out; whether you front-load payments or spread them evenly, the total in current value needs to be the same.

The money has gone to pay power plants that can supply winter capacity, exactly as the market is designed to do.

The intention of the payments is to increase revenue for that kind of power generation capability to encourage more such plants be constructed.

The argument in the article is dubious to me. Of course the higher price isn’t leading to more generation today, that’s not the point, the point is to reward developers that build and built capacity CA needs in winter. The disagreement then becomes which model is correct about how much capacity is actually needed.. but the fact that a tiny move in demand moves the price so substantially seems to me to undermine the entire premise of the blog post, clearly supply is severely constrained?

Can you explain how that works? With the row-per-item I can see how you’d use locking primitives etc easily to deal with multiple concurrent shopping carts claiming available inventory.. but how does your solution solve contention? There’d need to be some “number of items in inventory” row, wouldn’t there be contention on that?

The point of one row per item is that thousands of concurrent shoppers don’t need to block each other as they can each claim as many free rows as they need for themselves?

Right, except the researchers are the ones that added the button, pressed it and now are upset at Ford, in your example.

GitHub agents don’t have access to unrelated private repos by default, nor respond to public issue comments by default. The researchers manually configured the agent to have access to unrelated private repos and also process untrusted public comments.

How is this a Github vulnerability? The researchers are the ones that grant the agent access to private repos and then ask it to answer questions in public repos.. of course this allows extracting private information?

This is like setting up a normal CI job with access to secrets and running it on public PRs. If you configure GitHub to allow public code or LLM instructions to run in contexts that have access to sensitive things, they will leak; that’s not GitHub’s fault, it’s yours.

There are attacks that allow dumping RAM if the device is powered on though and you have physical access. Depending on config it may be very easy (just plug in a dumper over Thunderbolt on USB C and do direct memory access) or hard (freeze and swap physical RAM to an unlocked machine).. but the idea was defense-in-depth here; a well configured device should both be hard to dump RAM on and it should not give encryption keys if an attacker succeeds.

I’ve had very good success in similar setups where you have some sort of “oracle” and can generate enormous corpuses of test data, such that you really, really trust the LLM code must work for the inputs you expect it’ll ever need to handle.

Makes me think of all the algorithms we specify in proof languages and then hand-implement in production languages - this setup could maybe let you just specify the proof of an algorithm and then let LLMs derive efficient implementations with the (slow) proof as an oracle

The point of “durable” implying stored to durable media is precisely that it allows the operator of the system to make that kind of calculation. They know the disks they picked and the replication chosen, and as long as the database calls fsync, their calculations will work.

My beef is with database systems that use the argument you made further up thread to skip fsync to juice their performance numbers. Data is not “durable” if turning off the machines storing it means it’s lost, that’s a category difference, not a pure probability difference as you are claiming.

It is of course totally fine to not store data to durable media and say the risk of devops doing a coordinated reboot is as low as the risk of raid disk data loss, but then don’t use the word “durable”.

I used to say this as well but like.. industry has, for a long time now equated “durable” with “stored on disk”. Any DBA will assume that’s what it means, and use that fact when they work out the replication they need either in clustering or in raid.

If you’re building a data storage system and are using the term “durable” to mean “it’s in RAM on three virtual machines”, for example, I don’t think it’s unfair to say that you are lying to your customers, because you are intentionally misusing a well-established term.

If a company says “encrypted at rest” that is generally compliance-speak for “not encrypted, but the hard drive partition is encrypted”.

Various certifications require this, I guess because they were written before hyper scalers and the assumed attack vector was that someone would literally steal a hard drive.

A running machine is not “at rest”, just like you can read files on your encrypted Mac HDD, the running program has decrypted access to the hard drive.

The complexity for that is almost always for redundancy and for ease of deploys.

I feel like I’ve seen elsewhere that the argument there is that you often must have this optimisation working in algos that rely on it or you will get stack overflows. Having a keyword to force it then becomes a very useful thing, vs relying on hopes that future compiler versions and different arch targets will all discover the optimisation opportunity.

Utility solar is cheaper in studies that do not factor in the cost of distribution, but the picture is much less clear when total system cost is considered - not having to pay for expanded distribution grids or new interconnects is a major benefit of residential production.

As for the last part not being true, can you clarify? The majority of the earths population lives between the 20th and 40th latitude, the band around the earth approximately between Madrid and the Sahara desert. Sure you can’t run a poorly insulated home in northern Michigan on solar year around without considerable expense, but that’s nowhere near where the majority of humanity lives.

No reason to be rude or hyperbolic - I agree with you that cars destroy communities and we should strive to reduce the need for cars and parking.

For solar powered homes specifically though, multi-story buildings are much harder to run solar powered from the simple ratios - even if you reduce energy use 75%, at 4 stories you are break-even in roof-ratio-to-energy-need. I’ve worked in this space a while, and it’s now pretty straight forward to run single-family homes 24/7/367 on solar in most of the world, but multi story buildings are much harder.

Nothing is ever simple or one-dimensional :)

Respectfully, 30kWh is not much in this context. In 10 years every modern 2-car home will have 200kWh on the driveway just from the EVs; add a 100kWh whole home battery at a price point close to a 10kWh battery today and the calculus changes in most of the world.

The cost of materials going into modern batteries easily leaves room for another 10x reduction in price, IMO where this all is heading is obvious. Zero marginal cost will win every day of the week.

FWIW we run our cabin on 15kWh battery today year around, though we do run a small wood stove to supplant the heat pump on cold winter days.

Fooled by Randomness talks a good bit about this, and argues it’s true - except you don’t know what to bet on. Hence the outlier successes will be from extreme risk takers, and for each such person there will be 1,000s of other gamblers that bet on the wrong thing.

Taleb does the math as well IIRC, assuming there are x hundred thousand extreme risk takers, and outlier “correct bets” are y% chance, then you will have a surprisingly high number of people with a long series of “correct” bets behind them looking like business geniuses, from pure chance & basic statistics.

This was really good, and second leaning on property testing. I’ve had really good outcomes from setting up Schemathesis and getting blanket coverage for stuff like “there should be no request you can generate as logged in user A that let’s you do things as or see things that belong to user B”, as well as “there should be no request you can find to any API endpoint that can trigger a 5xx response”

They are clearly suggesting that the story recurring every two months is Astro-turfed, not that the story itself is false?

I mean, no, it's more than that.

You also need to choose optimal instruction encoding, and you need to understand how relocs work - which things can you resolve now vs which require you to encode info for the linker to fill in once the program is launched, etc etc.

Not sure why I'm on this little micro-rant about this; I'm sure Claude could write a workable assembler. I'm more like.. I've written one assembler and many, many parsers, and the parsers where way simpler, yet this thread is littered with people that seem to think assemblers are just lookup tables from ascii to machine code with a loop slapped on top of them.

I am surprised by the number of comments that say the assembler is trivial - it is admittedly perhaps simpler than some other parts of the compiler chain, but it’s not trivial.

What you are doing is kinda serialising a self-referential graph structure of machine code entries that reference each others addresses, but you don’t know the addresses because the (x86) instructions are variable-length, so you can’t know them until you generate the machine code, chicken-and-egg problem.

Personally I find writing parsers much much simpler than writing assemblers.

I don’t understand this summary - isn’t this a summary of the authors recitation of Masleys position? It’s missing the part that actually matters, the authors position and how it differs from Masley?

lol no, but if you are in a regular vehicle, you can see under the front of the bus as you pass it, it’s a standard safety practice? The first picture of the bus in this random article shows what I mean, you should be checking under the bus ahead of the front wheel as you pass: https://www.nvp.se/2026-01-08/bil-i-sparviddshinder-stoppade...

Googling this turned up a presentation from Waymo saying they do exactly this: https://www.reddit.com/r/waymo/comments/1kyapix/waymo_detect...

Aye, and to always look for feet under and by the front wheel of vehicles like that.

Stopped buses similarly, people get off the bus, whip around the front of them and straight into the streets, so many times I’ve spotted someone’s feet under the front before they come around and into the street.

Not to take away from Waymo here, agree with thread sentiment that they seem to have acted exemplary

Sorry I don’t follow. Why would the taxes need to be spent offsetting anything? The carbon reduction already happened, because the taxes made this auction choose lower emission alternatives.

If you then also spend the taxes on some form of offsets (if we pretend for the sake of argument that those work) you would have reduced emissions twice. One time seems plenty to say they are doing their job.