jakewins

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.

.. you are commenting on an article about how non-carbon-emitting energy options are beating out polluting alternatives, aided by exactly these taxes, so obviously yes, they are working exactly as intended: price signals for the market to get carbon out of the energy system

The purpose of the tax is not to raise money to plant trees, it’s to raise the cost of emissions so that markets move away from them

The most popular UK electricity retailer is Octopus Energy which is specifically focused on variable prices and flexible consumer demand. By what metric do you mean variable rate retailers are not popular?

Intermittency is already handled by the price mechanisms, they are set quarter-hourly; if you’re not available when there is high demand you don’t get paid.

The marginal price windfalls happen specifically when you’re able to deliver at a low cost when demand is high in the same ISP.

This just seems like data-free fear mongering.

I take trains like those for work, not to France but to Amsterdam, and I don’t speak German, French or Dutch.. if we want a train system that allows Europeans to use it there needs to be announcements and signs in the language 50% of EU citizens speak

I’m baffled that any other language would be considered - the only language that comes close to English in number of speakers is Mandarin, and Mandarin has nearly half a billion fewer speakers than English.

We should be happy there is a language that has emerged for people to communicate globally without borders, and support it’s role as the worlds second language rather than work to re-fracture how people communicate

I tried Basel, Buck2 and Pants for a greenfield mono repo recently, Rust and Python heavy.

Of the three, I went with Buck2. Maybe just circumstance with Rust support being good and not built to replace Cargo?

Bazel was a huge pain - broke all standard tooling by taking over Cargos job, then unable to actually build most packages without massive multi-day patching efforts.

Pants seemed premature - front page examples from the docs didn’t work, apparently due to breaking changes in minor versions, and the Rust support is very very early days.

Buck2 worked out of the box exactly as claimed, leaves Cargo intact so all the tooling works.. I’m hopeful.

Previously I’ve used Make for polyglot monorepos.. but it requires an enormous amount of discipline from the team, so I’m very keen for a replacement with less foot guns

You’re converging a lot of ground here! The article is about producing container images for deployment, and have no relation to Bazels building stuff for you - if you’re not deploying as containers, you don’t need this?

On Linux vs Win32 flame warring: can you be more specific? What specifically is very very wrong with Linux packaging and dependency resolution?

These are LCOE numbers we are comparing, so that is factored in.

The fact that pumps, turbines, rotating generators don’t fail linearly doesn’t mean they are not subject to wear and eventual failure.

Energy Dome expects its LDES solution to be 30 percent cheaper than lithium-ion.

Grid scale lithium is dropping in cost about 10-20% per year, so with a construction time of 2 years per the article lithium will be cheaper by the time the next plant is completed