There’s plenty of designs out there that you can load onto an FPGA or, funds permitting, send off to a fab to burn into silicon.

There’s one two guarantees in life: Death and taxes. Real currencies are the ones you can use to pay the latter.

Noone here is planning to inject hydrogen into existing pipelines. If anything, synthesising methane during the transition so that consumers only have to switch their burners once, from nat gas to hydrogen, and not first to nat gas + more hydrogen and then to pure hydrogen. Gotta switch whole municipalities at once doesn’t make sense to duplicate the last-mile gas pipes. If, and that’s not even clear yet, hydrogen pipes will even be a thing for private consumers.

We shouldn’t be having methane in the atmosphere in the first place. Sure, if you produce the hydrogen from natural gas then you have a problem because that stuff comes with plenty of methane which won’t suddenly stop leaking.

From all that I’ve seen electricity lines (also HVDC) have higher transmission losses by a magnitude. With hydrogen and modern material science you’ll probably have the choice between higher losses and embrittlement, but that’s just another economical equation: Do you want to eat the higher losses, or replace the pipeline in a couple of decades or a century.

At least environment-wise hydrogen leaks aren’t an issue: Some atoms diffusing through the wall don’t constitute a fire hazard and the end result is water. Methane, OTOH, is a nasty greenhouse gas.

Speaking of nature: Ammonia is nasty, but nature produces it itself (just not at those concentrations) and can deal with it. The site directly surrounding a leak would be dead, a bit further downstream (literally) there’s going to be over-fertilisation. Not nice but definitely better than an oil leak and fixing it quite literally involves waiting until grass has grown over it as rain dilutes it and microorganisms migrate back in to eat it. Similar things apply to ethanol which I’d say would be a better choice for general use such as hybrid cars, camping stoves and whatnot because it’s not going to burn your lungs away. Can’t rely on people being conscious enough to get up and flee the ammonia stench when they’re in a car accident.

Back in the early days of gas infrastructure, before wide-spread electrification, you know gas street lights and everything, the gas was produced by gasifying coal, resulting in gas that was often over 50% hydrogen, with only ~20% methane. Rest nitrogen and CO.

Natural gas has a methane content upwards of 75%, which meant that everyone had to switch out their burner nozzles but the rest of the infrastructure stayed intact.

All this is to say: Nothing about is really new or rocket science. Europe is certainly creating a backbone pipeline network for hydrogen, parts of it new pipes, other parts re-purposed natural gas pipes, many were built to a standard that allows them to carry hydrogen though some valves etc. might need upgrading. Some of those were originally built for hydrogen in the first place, and checking Wikipedia there’s actually a 240km segment in the Ruhr area, built in 1938, still in operation, which always carried hydrogen. Plain steel but comparatively low-pressure so it works.

Oh and have another number: According to Fraunhofer, Germany’s pipeline network can store three months of total energy usage (electricity, transportation, everything). Not in storage tanks, but just by operating the pipelines themselves at higher or lower pressure.

And we need that stuff one way or the other: Even if tomorrow ten thousand fusion plants go online that doesn’t mean that the chemical industry doesn’t need feedstock, or that reducing steel with electricity would make sense. Both of those things need hydrogen.

Fusion is still in the future so the plan is to import most of that hydrogen, mostly from Canada and Namibia, in tankers carrying ammonia which is way more efficient that trying to compress hydrogen also ammonia is needed for some processes anyway.

Should all be in place. Even nvidia driver support. It’s one of the rare cases where I actually support nvidia on a technical level, that is, having explicit sync is good. I can also understand that they didn’t feel like implementing proper implicit sync (hence all the tearing etc) when it’s a technically inferior solution.

OTOH, they shouldn’t have bloody waited until now to get this through. Had they not ignored wayland for a literal decade this all could’ve been resolved before it became an issue for end-users.

Programs can’t set position or size of windows, period, at most they can ask and then hope they don’t get ignored and it’s good that way. Window management is responsibility of the compositor, not of applications.

At least KDE has support for it that’s about on X11 level, a proper-proper solution is still in the pipeline. And yes you’re seeing right it’s been there for four years.

And nobody wants to rewrite Xorg or understand the code (other than very basic security maintenance).

That’s precisely the point: All the devs got tired of it and started wayland instead.

X12 might happen at some point when wayland is mature, as in a “let’s create and bless a network-transparent protocol so we might have a chance of getting rid of XWayland in 50 years” kind of move.

Yep that’d be Wayland devs maintaining XWayland, which is part of the x.org codebase. There are no “X11 devs”, they’re the ones who started Wayland to get rid of that bowl of spaghetti!

I argue that X11 would have hyperactive development, if we did not have Wayland

Wayland was started by the X developers because they were sick and tired of hysterical raisins. Noone else volunteered to take over X, either, wayland devs are thus still stuck with maintaining XWayland themselves. I’m sure that at least a portion of the people shouting “but X just needs some work” at least had a look at the codebase, but then noped out of it – and subsequently stopped whining about the switch to Wayland.

What’s been a bit disappointing is DEs getting on the wayland train so late. A lot of the kinks could have been worked out way earlier if they had given their 2ct of feedback right from the start, instead of waiting 10 years to even start thinking about migrating.

Making screenshots does, too, which is why that functionality gets implemented at the compositor level. And so will screenreaders. In fact looking at my settings panel KDE does have support for Orca. Dunno how well it’s working but it’s not like the issue is being ignored.

That does not seem to be a stray and yes there’s definitely reasons to take potshots at Gnome. They still don’t support server-side decorations. Everyone is absolutely fine with them not wanting to use them in their own apps, have them draw window decorations themselves, and every other DE lets gnome apps do exactly that, but Gnome is steadfastly and pointlessly refusing to draw decorations for apps which don’t want to draw their own decorations. It’d be like a hundred straight-forward lines of code for them.

And that’s just the tip of the iceberg when it comes to breakage you have to expect when running Gnome.

Wayland kinda is an x.org project in the first place. AFAIK it’s officially organised under freedesktop but the core devs are x.org people.

x.org as in the organisation and/or domain might not be needed any more, but the codebase is still maintained by exactly those Wayland devs for the sake of XWayland. Support for X11 clients isn’t going to go away any time soon. XWayland is also capable of running in rootfull mode and use X window managers, if there’s enough interest to continue the X.org distribution I would expect them to completely rip out the driver stack at some point and switch it over to an off the shelf minimum wayland compositor + XWayland. There’s people who are willing to maintain XWayland for compatibility’s sake, but all that old driver cruft, no way.