That's the neat part: You do not have too package for all the distro.

Just make your components easy to decouple with provided pkg-config (ideally) and a proper configuration mechanism.

No bundle, no hidden download or tangled vendored messy script.

Then it is easy to do: you can just provide the packages for your main targets (e.g Ubuntu, Redhat typically) and the community of other distros will take care of the rest.

(1) - Supporting only Server grade hardware and ignoring laptop/consumer grade GPU/APU for ROCm was a terrible strategical mistake.

A lot of developers experiments first and foremost on their personal laptop first and scale on expensive, professional grade hardware later. In addition: some developers simply do not have the money to buy server grade hardware.

By locking ROCm only to server grade GPUs, you restrict the potential list of contributors to your OSS ROCm ecosystem to few large AI users and few HPC centers... Meaning virtually nobody.

A much more sensible strategy would be to provide degraded performance for ROCm on top of consummer GPUs, and this is exactly what Nvidia with CUDA is doing.

This is changing but you need to send a clear message there. EVERY new released device should be properly supported by ROCm.

- (2) Supporting only the two last generations of architecture is not what customers want to see.

https://rocm.docs.amd.com/projects/install-on-linux/en/docs-...

People with existing GPU codebase invests significant amount of effort to support ROCm.

Saying them two years later: "Sorry you are out of update now!" when the ecosystem is still unstable is unacceptable.

CUDA excels to backward compatibility. The fact you ignore it entirely plays against you.

(3) - Focusing exclusively on Triton and making HIP a second class citizen is non-sensical.

AI might get all the buzz and the money right now, we go it.

It might look sensible on the surface to focus on Python-base, AI focused, tools like Triton and supporting them is definitively necessary.

But there is a tremendous amount of code that is relying on C++ and C to run over GPU (HPC, simulation, scientific, imaging, ....) and that will remain there for the multiple decades to come.

Ignoring that is loosing, again, custumers to CUDA.

It is currently pretty ironic to see such a move like that considering that AMD GPUs currently tend to be highly competitive over FP64, meaning good for these kind of applications. You are throwing away one of your own competitive advantage...

(4) - Last but not least: Please focus a bit on the packaging of your software solution.

There has been complained on this for the last 5 years and not much changed.

Working with distributions packagers and integrating with them does not cost much... This would currently give you a competitive advantage over Nvidia..

This is due to the physics reality of the ground itself: Power of a Geothermal well will decay over time to a point where the well become unusable and need to be closed.

It is due to the fact underground water is rich in minerals and raw elements. This soup will slowly but surely cement the well itself and its associated underground.

There are techniques (similar to 'fraking') to extend the lifetime of a well but only to some extent.

If the topic interests you (and you can bear artificially translated English), a French content creator did a pretty good video on the topic:

https://m.youtube.com/watch?v=q4xZArgOIWc

Additionally, Geothermal plants can emit CO2 (even a lot of CO2) in some geological configuration.

All of that makes Geothermal (for electricity) a bit controversial as "Renewable".

I precise that there is absolutely nothing wrong about low temperature Geothermal energy for residential heating and we should do more.

Feasible but difficult. CMake has a tremendous user mass, so you do want to be able to use a CMake-based project as a dependency. The CMake Target/Config export system expose CMake internals and make that difficult to consume a CMake built project without CMake.

The cleanest way to do that is probably what xmake is doing: Calling cmake and extract targets information from CMake to your own build system with some scripting. It is flaky but xmake has proven it is doable.

That's said: CPS should make that easier on the longer term.

Please also consider that CMake is doing a lot of work under the hood to contains compiler quirks that you will have to do manually.

> integration of other languages in the project?

Trying to integrate higher level languages (Python, JS) in package managers of lower level languages (C, C++) is generally a bad idea.

The dependency relation is inverted and interoperability betweens package managers is always poor. Diamond dependency and conflicting versions will become quickly a problem.

I would advise to just expose properly your build system with the properties I described and use a multi-language package manager (e.g Nix) or, at default, the higher level language package manager (e.g uv with a scikit-build-core equivalent) on top of that.

This will be one order of magnitude easier to do.

> how to handle qt?

Qt is nothing special to handle.

Qt is a multi language framework (C++, MOC, QML, JS and even python for PySide) and need to be handle as such.

It is completely fine to use -march=native, just do not make it the default for someone building your project.

That should always be something to opt-in.

The main reason is that software are a composite of (many) components. It becomes quickly a pain in the ass of maintainability if any tiny library somewhere try to sneak in '-march=native' that will make the final binary randomly crash with an illegal instruction error if executed on any CPU that is not exactly the same than the host.

When you design a build system configuration, think for the others first (the users of your software), and yourself after.

The 15000 was a typo on my side. Fixed.

- (1) Provide a way to compile without internet access and specify the associated dependencies path manually. This is absolutely critical.

Most 'serious' multi-language package managers and integration systems are building in a sandbox without internet access for security reasons and reproducibility reasons.

If your build system does not allow to build offline and with manually specified dependencies, you will make life of integrators and package managers miserable and they will avoid your project.

(2) Never ever build in '-03 -march=native' by default. This is always a red flag and a sign of immaturity. People expect code to be portable and shippable.

Good default options should be CMake equivalent of "RelWithDebInfo" (meaning: -O2 -g -DNDEBUG ).

-O3 can be argued. -march=native is always always a mistake.

- (3) Allow your build tool to be built by an other build tool (e.g CMake).

Anybody caring about reproducibility will want to start from sources, not from a pre-compiled binary. This also matter for cross compilation.

- (4) Please offer a compatibility with pkg-config (https://en.wikipedia.org/wiki/Pkg-config) and if possible CPS (https://cps-org.github.io/cps/overview.html) for both consumption and generation.

They are what will allow interoperability between your system and other build systems.

- (5) last but not least: Consider seriously the cross-compilation use case.

It is common in the world of embedded systems to cross compile. Any build system that does not support cross-compilation will be de facto banned from the embedded domain.

That's not what he said. He said this is the scenario in case of full cycle up and down every day. Which is obviously not how a central is operated.

Consensus today is that nuclear powerplant can live for around 60-80y without issues if the maintenance is done properly. The US park is getting there.

> This simply wouldn't have happened if it hadn't been necessary, the government wouldn't have allowed it at the time.

The government has no word to say over an ASN decision, specially when Nuclear safety is at stake.

It is France we are talking about, not the USSR.

Again, it is commonly admitted today, after the facts, that it was over-reacting. Thats said: It is bad economically as it cost EDF few billions. But it is exactly what you want to see for safety: Better overreacting than having an incident.

> A few years pass again and some people are talking themselves again into this technology being anything except useless.

So. You are taking one single year failure as a representative example of a technology that has given cheap, abundant and low carbon electricity for the entire Europeean continent for 3 decades ?

Do you have not the impression of being of slightly bad faith here ?

Because reality is very different of propagandists and lobby reports.

Currently, not a single major country right now can afford to have energy storage capacity large enough to pass, even a single day, without sun if running exclusively on solar power.

Not even China, the biggest battery provider world wide.

Considering that to get a stable and reliable grid, the needed capacity would need to supply for weeks during Dunkelflautes, this is realisitically not going to happen before multiple decades.

China has an energy problem it need to solve now: The country is developing so its electricity consumption is growing, rapidly.

Their solution is the most pragmatic on short term: Building coal plants.

Their long term solution is also the most pragmatic on long term: Using Nuclear energy to support the baseload and a mix of hydro, solar, wind for the peaks.

You apparently did not. because you are the revisionnist here.

CSC (corrosion sous contrainte) is a well documented topic with accessible reports from the ASN (the french nuclear agency) [1], the court des comptes (French accounting court) and EDF itself.

The source of the problem is a phenomena that affect mainly the N4 (1400MW) series of the French reactor. It has been detected in 2021, so before the 2022.

Some pipe in some specific part of the circuit (secondary circuit) presented some unexpected cracks under inspection in one specific reactor.

And EDF chose the stop all the potentially affected reactor and disassembly all the potentially affected pipe to scan them with X ray and triple check that the corrosion phenomena is not widespread.

Where they over-reacted, is that they also disassembled the different serie 900Mw reactor 'just in case', at the worst time.... meaning right before Vladmir Putin attacked Ukrain.

> If it was just "an overreaction" there would've been tremendous political pressure to just put the plants back online

Sure. They should have just emergency duck tape the pipe without following any safety protocol, in a nuclear installation, just to please some politicians and because Putin dreamed of cold war again #sarcasm.

You seem to have very little clue of about the nuclear industry internals and its associated safety processes.... It of course took time.

The only thing you are correct on is that, indeed, it took longer than expected and caused delays.

[1]: https://recherche-expertise.asnr.fr/avis-rapports-corrosion-... [2]: https://www.ccomptes.fr/fr/documents/68958 [3]: https://www.ladrome.fr/wp-content/uploads/2022/10/cli-csc.pd...

I start seriously question your intellectual honesty here.

- For the last 2 decades, EDF was privatised and give back to the state an average of 2bn€ per year in dividende [1]. That is currently EDF giving to the state, not the opposite.

- The monopoly situation in France was ended in 2007. The loi NOME in 2010 even offred to the competitor of EDF an access to nuclear energy at fixed low price [2].

Worth to note that when the Energy crisis spiked in 2022, the same 'competitors' sent back their customers to EDF because they massively increased their price and did not want to follow the TRV.

> hydrogen to kick in.

Nobody sane of mind and reasonable take hydrogen and Power2Gas seriously in the energy sector: The law of physics simply play against it.

The general efficient is low (practically around 50%), the electrolizers strongly hate the spike style usage pattern necessary for a coupling with intermittent energy, and no installations of the required scale has even been tried.

The only reason this is still on the table is because it gives the gaz industry a reason to drain public subsidies and some hope to stay relevant.

> France's transition to nuclear power began in 1963 and is now complete.

Thats also wrong.

The Messner plan started in 1974 and France was other 55% of electricity production provided by Nuclear in 1985. It finishes with over 50 reactors in 15 years to cover up more than 70% of the electricity generated [3]

The cost of the plan Messmer was estimated at 100bn€ in 2012 money.

Germany started their energiewende in 2005 and 20 years later and 400Bn€ burned, they still do have a CO2/kwh intensity 4x higher than France in the 80s.

The results are so bad that Germany started to subsidies its own industry to protect them against electricity price increase [4]

Again, the results speak for themselves.

[1]: https://www.senat.fr/rap/r16-335/r16-3354.html

[2]: https://www.cre.fr/electricite/marche-de-gros-de-lelectricit...

[3]: https://www.sirenergies.com/en/article/history-of-nuclear-po...

[4]: https://perspectives.se.com/blog-stream/germany-industrial-e...

Bailout of 2022 alone was around 22bn€, which was added on top of it the historical debt.

Revenue of EDF in 2025 is over 100bn€ to put things into perspective.

> Furthermore it was discovered that the plants had neglected maintenance that had to be undertaken rightaway, that had nothing to do with the TRV.

That is also wrong. The immediate maintenance in 2022 was related to "corrosion sous contrainte" which has nothing to do with carelessness. It was mainly the French nuclear regulator (ASN) over-reacting to some non-critical cracks find in some pipes. They have themselves said afterward that the immediate actions were not necessary. The actions were overreactive (from EDF side) and the calendar was very unfortunate.

> So even if the mentioned 5 bn export now was pure profit - which is isn't -

Indeed. Profits in 2025 were currently over 8bn€, so well over 5bn€.

5bn€ just concern the profit made by the exports.

This is not hard to understand: Making a profit by selling valuable nuclear energy during evening peak consumption while buying cheap intermittent solar during low consumption time is an easy game.

People generally do not understand that Nuclear is a CAPEX game, not an OPEX one.

> And they will have to sell their power on markets that will increasingly often have free electricity from solar and wind. How do you pay 1000 educated plant operators when electricity prices are negative?

By selling nuclear electricity at 180€/MWh every night when the sun do not shine.

(This is the average price, every evening peak this month)

Meaning-while, the profitability of solar operators will sink to the ground due to the overcapacity causing negative price during the day as soon as the sun shine. Many of them will die if not state subsidized with public money.

> nuclear power isn't the kind of thing you can try and then walk away from when it turns out to be a bad idea

It is currently the best low-carbon energy around. And will continue to be for the next 2 decades.

The current Co2/kwh emission of France is 27g/kwh.

The comparison with country like Germany (397g/kwh) or state like California (190g/kwh) that spend >100Bn$ on renewable speak for itself.

I can safely bet that in 15y from now, the French grid will still be greener than the German one.

That's just wrong.

EDF nuclear fleet is highly profitable with around 92TWh exported in 2025 and more than 5 Billions of benefits for the country and the company.

https://www.sfen.org/rgn/le-nucleaire-en-chiffres-923-twh-de...

The reason EDF had to be nationalized is because the government used the company as a "price shield" to protect consumer against energy price rise on the European market in 2022 with a mechanism named TRV (Tarif Régulé vente). That digged up EDF dept tremendously.

> Spain plans to deprecate their remaining nuclear for renewables for similar reasons

Span deprecated their nuclear government because their current Socialist government is aligned with Ecologists that are, like everywhere in Europe, antinuclear.

Additionally, the lack of spinning generator in Spain is currently partially what caused the Blackout in Spain in 2025 due to a lack of inertia in the system.

> EDF fleet upkeep will cost over 100 billion euros by 2035, court of auditors says

This is over 25 years and will prolong-ate the lifetime of the 56 reactors by 20 more years. These produce 70% of the country need in electricity.

In comparison, the German energiewende cost 400 billions for 37% of electricity of 2025 produced by solar and wind. With production medium that will need to be entirely renewed in 20 years.

> California will achieve a low carbon generation profile for far cheaper than it cost France (refer to the Lazard LCOE

That is also wrong.

Because LCOE calculation does not take into consideration the price of the grid consolidating necessary for renewable nor the necessity of backup generation in case of dunkleflaute.

Yeah but that's theory and theory only.

I would say that 99.9% of anything that look like a roundabout is a "normal roundabout" where the priority is for people in the center, not for the ones entering. This is currently the same than the rest of Europe.

Place de l'étoile is an exception, not a rule and the total number of roundabout like that in the country can probably be counted on one hand.

There is very good reasons why De Gaulle was always a bit doubtful about American military protection and why post-war France put a strong emphasis on military sovereignty.

That has nothing to do with any French stubbornness or a so called French anti-American feeling.

The main reason is that De Gaulle experienced the fact American leadership can be untrustworthy first hand.

When he was the leader of the exiled French force during the 40s, Churchill supported him.

Meaningwhile Roosevelt refused to give him any support and actively acted to make him replaced by a puppet, General Giraud. Mainly because it was better aligned with American interests to setup a puppet state in France on the longer term.

The situation changed only later when it became pretty obvious that Giraud was antisemite, an openly nazi collaborationist and a pretty poor politician.

Only then, America started to support De Gaulle officially. Initially only indirectly through the relation between De Gaulle and Eisenhower.

Thank you for your work on ALGOL, you were multiple decade ahead of your time.

Rest in peace.

> (and btw it's not just time that matters here)

My remark is still valid. Even considering memory space and cognitive complexity.

> even function calls are not always zero-cost. For multiple reasons, some of which differ across compilers more than others

Divergence about the support of inlining in compiler implementation have nothing to do with the debate here. Some idiosyncrasy about C++ argument passing and lifetime might causes a cost in some specific scenario, still that is specific to C++.

It still does invalid the concept of zero runtime cost for abstraction.

As much as people like to dismiss it, Stepanov was right all along.

> Nobody is concluding you shouldn't write functions either.

Then, you will be surprised to learn that some 'devs' actually recommend exactly this and write guideline that minimize the number of function written. They tend to be from the same crowd that the one was describing before.

There is always a cost to abstraction, and that can take different form. In C++, it is often build time (and/or complexity). And Chandler, in his talk, is perfectly right about that.

But that does not change the validity of the C++ concept 'zero cost abstraction at *runtime*'. It is possible to get proper language abstractions while not sacrificing runtime performances.

I did get sharp on his comment because this talk is constantly posted by a specific C crowd that profoundly hate any form of abstraction and use it as a totem to justify terrible development practices.

If your language support zero cost abstraction and genericity, by the sake of god, use it... most of the time the impact in term compilation time is worth the benefits.

unique_ptr is a beautiful example of that btw.

This talk just point that unique_ptr is not one of them due to the side effect of C++ move semantics being non destructive.

People that do not understand that should honestly stop to use it as an argument in favor of "there is no zero cost abstractions".

Directional laser beams are orders of magnitude to jam compared to radio wave. That alone makes it of big interest for military applications, even with 500 ms latency.

There is several known cases where jamming caused the loss of costly military drones.

https://en.wikipedia.org/wiki/Iran%E2%80%93U.S._RQ-170_incid...

Laser comms could prevent that entirely.