Hacker Newsnew | past | comments | ask | show | jobs | submit | Jolter's commentslogin

How to make hydrogen production cheaper and easier: include an atomic reactor component.

Huh?

I’d be interested in hearing about some scenario where this actually costs less, given the cost of building anything nuclear in 2026.


I agree, the experience building nuclear reactors is mixed bag. Some builds failed, like Flamanville 3, Hinkley Point C, Vogtle 3. Some builds succeeded: Barakah nuclear power plant, Fuqing 5,6. It really depends on maturity of supply line and political support.

The real question is: how do we produce hydrogen from the coming massive overbuilding of cheap-but-variable solar. Nuclear reactors are a whole different animal: even if we build them "cheaply" they're not going to approach the costs of overbuilt solar, so those nuclear watts will be better used for other purposes.

Coupling PV to electrolyzers and efficient hydrogen production using solar energy is still open research problem. Batteries will be probably needed.

"The low efficiency of PV-electrolyzer systems can be attributed to several factors: intrinsic losses in both the PV and electrolyzer units, energy consumption by balance-of-system components (e.g., inverters, thermal management), and, most critically, ineffective electrical coupling. Although some researchers advocate for direct coupling as a cost-effective solution, variable solar input remains a major challenge. Fluctuations in solar irradiance can cause the power delivered to fall outside the acceptable operating range of electrolyzers, leading to frequent shut-downs and start-ups. These cycling events can accelerate degradation, particularly in PEM electrolyzers, and also affect the purity and yield of hydrogen"

"Recent studies also highlight the integration of battery energy storage systems (BESS) into large-scale PV-CSP hybrid plants as a strategic enhancement. With anticipated declines in battery costs, this integrated approach may become increasingly viable in the near future."

https://link.springer.com/article/10.1007/s44373-025-00080-4


This site seems to auto-translate itself into my browser’s locale. Interesting approach but probably not the right choice if your audience is the tech crowd. I’m perfectly fluent in English, thank you very much.

I suppose it’s a clue that the whole thing was copy-edited or written using LLM. Not reading it.


Well, you’re saying that after you already learned how to do it.

I am very new to the crafts and I can attest trying to solder smd stuff, with correct equipment is way easier than soldering 2 wires correctly together. And I also kinda hate QFN like packages where you can’t see the pads.

I don’t know if we’re reading the same article? The linked one states very plainly:

”Idempotency is about the effect

An operation is idempotent if applying it once or many times has the same intended effect.”


I do not disagree with their definition of idempotency, but they silently assume resending the same result is the default. They discus this later on in the article but they do not seem to question why that might not be a good idea in the first place.

Edit: Perhaps it is my mental model that is different. I think it makes most sense to see the idempotency key as a transaction identifier, and each request as a modification of that transaction. From this perspective it is clearer that the API calls are only implying the expected state that you need to handle conflicts and make PUTs idempotent. Making it explicit clarifies things.

The article actually ends up creating the required table to make this explicit, but the API calls do not clarify their intent. As long as the transaction remains pending you're free to say "just set the details to X" and just let the last call win, but making the state final requires knowing the state and if you are wrong it should return an error.

If you split this in two calls there's no way to avoid an error if you set it from pending to final twice. So a call that does both at once should also crash on conflicts because one of the two calls incorrectly assumed the transaction was still pending.


Right. An operation is idempotent only if doing it twice has the same result as doing it once. If you have to worry about whether an operation has already been done, it's not idempotent. If you have to worry about order of operations, it's not idempotent.

What's being asked for here is eventual consistency. If you make the same request twice, the system must settle into a the same state as if it was done only once. That's the realm of conflict-free replicated data types, which the article is trying to re-invent.

   x = 1
is idempotent.

   x = x + 1
over a link with delay and errors is a problem that requires the heavy machinery of CRDTs.

You’ll notice they raised prices in Japan by A Lot, but the US price is only up $50.

Uuuuuuh, ¥10,000 is currently about $64, so it's not that much different to be calling it "a lot".

The price is increasing by 20% in Japan and 11% in the US, so the price increase in Japan is nearly double the increase in the US.

Classic class warfare. ”Buy on eBay”. Sure worked for the bolsheviks!

Presumably someone claimed it as ”AI” by listing it on the registry.

Not that I’ve seen. Every time I rent a recent model year, they have the lane keeping assist feature but it only works when you enable adaptive cruise control.

But maybe that’s what you meant?


It’s not exactly a back door. It’s a fake radio cell, mimicking your network provider and acting like a man in the middle. In that sense, it’s like a stingray. The differences are

1. The Stingray eavesdrops, but avoids interfering with user traffic

2. The stingray is operated by law enforcement, not by fraudsters looking to steal your money


In mamy parts of the US, the cops are the fraudsters looking to steal your money. So it isn't that much of a difference.


Ban civil asset forfeiture!


Is it possible to prove security properties about a web application?


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: