The best thing about using watercourses as your heat source for heat-pumps - the water flow naturally takes away your "colder" output and brings you more "warmer".

Ground source heat pumps are limited because the ground they have chilled stays stubbornly in the same place, so the only way you can extract more heat from it is to make it even colder, which gets less efficient. Watercourses don;t have that problem.

The opposite effect is also why thermal stations (including but not only nuclear) are usually on the coast or near large rivers: you can dump a lot of water heat into water and have it carried away.

Not always good for the local ecosystem without mitigation, but at least one Japanese reactor allowed local colonisation by tropical fish and local legend said the same about Sizewell.

Sizewell C claims to plan recover waste heat and use it for carbon capture somehow, about which all I can say is a big old hmmmmm.

> always good for the local ecosystem without mitigation, but at least one Japanese reactor allowed local colonisation by tropical fish and local legend said the same about Sizewell.

Not quite the same thing, but there is a tropical greenhouse in the south of France that used to be heated by cooling water from a nearby uranium enrichment facility: https://fr.wikipedia.org/wiki/La_ferme_aux_crocodiles (unfortunately not available in English).

The air temperature isn't relevant.

It is, since the obvious alternative to taking the heat from water would be taking the heat from the air or from the ground.

The air is colder in winter than the water, and the ground only provides a limited amount of heat before you can't extract any more. So water beats both.

It is a bit relevant because if the air was warm enough you would be better building huge air source heat pumps.

And if it was really warm enough you wouldn't need heating in the first place.

No, it's all about corporate greed.

Don't be ridiculous.

Not ridiculous at all.

Rust coreutils are MIT licensed.

Canonical sells extended support and security packages.

It’s completely reasonable to think they will want to monetize additional patches on coreutils as part of their commercial offerings.

That is a valid and interesting discussion point. I do concede that OpenAI will probably not survive in the long term. Google and Microsoft on the other hand have dozens of independent verticals and revenue sources. Google can afford to be a loss leader with Gemini AI, and when every competitor goes out of business, they will jack up prices and enshittify a tool everyone depends on. Like what happened with YouTube once Google Video, DailyMotion, Vimeo, and the other sites essentially stopped being relevant.

But, and this is key, AI is not going away for as long as the potential to replace human labour remains there.

Separating interface from implementation of one of the core practices for making large code bases tractable.

Of course, but that's doable without making programmers maintain headers, and some modern languages do that.

I've found usually to poor effect. Both Rust and Haskell did away with .mli files and ended up worse for it. Haskell simplified the boundary between modules and offloaded the abstractions it was used for into its more robust type system, but it ended up lobotomizing the modularity paradigm that ML did so well.

Rust did the exact opposite and spread the interface language across keywords in source files, making it simultaneously more complicated and ultimately less powerful since it ends up lacking a cognate to higher order modules. Now the interfaces are machine generated, but the modularity paradigm ends up lobotomized all the same, and my code is littered with pub impls (pimples, as I like to call it) as though it's Java or C# or some other ugly mudball.

For Haskell, the type system at least copes for the bad module system outside of compile times. For Rust, it's hard for me to say anything positive about its approach to interfaces and modules. I'd rather just have .mlis instead of either.

I don't understand that hate against header files. It is just a separate file with the interface. Of course you also need to change it, when you change the API, which you might find annoying, but maybe you should use that to consider that you are just changing an API?

Flat, monochrome icons might look nice, but they are only useful if used sparingly.

If you're going to use many icons, then they need to be visually distinctive. That means ditching the flat designs, and embracing colour again.

Color icons needs to done twice - once for light mode and again for dark mode.

It is the reason for removing colors and shadings from all icons.

Think about what was lost in the quest for dark mode versus the benefits.

I would argue that menu icons are more useful than dark mode in several situations.

We don't need light mode and dark mode if we just set our monitor brightness correctly.

It seems some monitors now assume dark mode - only the very lowest brightness setting isn't blinding.

So in your opinion, monochrome icons are a sign of laziness, rather than an aesthetic choice. Got it.

I never said that. However, I think the entire industry ended up using monochrome icons due to aesthetic, and many practical reasons.

Agree. Surely the ISP can assign customers a real IPv6 range, and also a NAT'd IPv4 address for legacy stuff?

I hardly notice if IPv4 stops working, these days.

It's possible to get malware onto even air-gapped machines. This is a way to then communicate across the air-gap.

"Content not available in your region."

Please avoid Imgur.

Use a vpn or avoid the UK