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.