That's the same thing they include with the driver, it's just the source release for the part that's required to be open. It uses (as it says on the page) the firmware and user space components from the binary driver. The majority of the driver is still closed.

Is it hard to install CUDA on RH? On Debian it's a simple matter of using the runfile installer. This works flawlessly and also doesn't interfere with multiarch like the driver packages do.

While all of that is true, how was that ever going to overcome the fact that the amount of work which must be done was multiplied by using it? If you go from building cars one-off in a shed to building the "same" cars (essentially) through mass production in a factory, you're not creating additional work for yourself as you're building the same number of cars.

I addressed the question at hand. That question has already been amply answered by reality. THIS question was whether SMRs were going to be what made nuclear power make sense, and the answer was obviously always no as it was never going to address the root problems em was always going to make some of them worse.

If you want to have the usual arguments about nuclear power, I'm sure that would make the site owners very happy, but frankly that stuff has long since gotten quite boring. The pros have no new arguments and the antis need none since nothing has changed for the better.

Nuclear power might make sense in a world where profit wasn't the primary consideration, but we don't live there and most of the same people who want nuclear are against us getting there.

If you want to be lied to, go somewhere else.

Only facts are of value when you're determining culpability.

Why would increasing the number of units ever help with any of these things? No one has ever explained why that even might be true. They simply claim that mass production will improve the situation because it did for other things which are very different from nuclear reactors.

What I have been saying since we started seeing the "SMRs will solve everything wrong with nuclear" argument is that per-unit costs will make them more expensive, not cheaper. More reactors for the same output means for example more welds to make, which means more X-ray inspections of welds which can wind up costing more than the welds themselves (which is why the automated welding they're doing on prototypes isn't going to solve the problem.) The small reactors still need all the same stuff as the big ones. If you're trying to get the same output on a site then not only are you magnifying your costs by building many reactors instead of one, but you're also multiplying the costs of making connections to those reactors from the water source and so on.

Everything tends to get cheaper per unit of output as it gets larger until it reaches the point where it's so large that its very size causes new engineering problems. Why would SMRs ever have been different? It just never made any sense that doing more work to arrive at the same level of output would be cheaper.

In short, yes.

Though that's not what they're talking about, I still feel like answering this.

If you try to run a program which was designed for an earlier version of Linux on a modern system it will probably fail for lack of shared libraries.

When you try building those libraries you may well find that the build fails for the same reason. So now you have to build libraries before you can build the libraries. And this will often go several layers deep, and sometimes you get into a situation where some library simply will not build without some manipulation because of changes to libc...

One famous concrete example is Loki games for Linux for which there is the Loki_Compat set of support libraries. As the years have gone on this approach has become less and less viable, to the point that you're actually more likely to get good results by running the Windows version of the game in Wine.

This used to be a massive selling point of Windows; they went through all the effort to make sure that there were DLLs and other tools to provide backwards compatibility. However, they have slacked off on that in more recent years, notably since Windows Vista. At this same time we also moved to 64 bit and their VM process doesn't support 16 bit even though it could be done. We can run programs in a 32 bit Wine process now that can't be run in windows without replacing the vm used to run old programs with something custom.

Today, if you want to run old Linux software, your best bet is old Linux in a VM...

CO2 levels where emissions are high are only very slightly higher than CO2 levels where they aren't. If this weren't so then the negative health effects would be obvious because high CO2 levels cause cognitive impairment and panic.

*looks at cities*

Er, wait...

Not emitting CO2 in the first place is a better strategy, so the money spent on projects like this should be spent on renewables instead and the places where there's an excess of it already should be using the power to make something that would otherwise be made with CO2-emitting energy sources elsewhere.

When we're talking about crash test standards, the USA has typically been out in front. For a recent example, we were the first to implement a partial offset frontal crash test requirement.

Emissions are mixed; California has often been out in front, most of the country has usually been behind.

It changes.

Allegedly it is named that because of the color being related to the sky where the clouds are.

I think it's half that, and half that we're short on available short names for things that aren't already strongly associated with an idea in people's minds, and/or already a registered trademark.

Cheap shit screens, yes, burn-in, short lives, etc. Or, poor contrast and daylight viewability.

Oh, my sweet summer child, they all do that or they don't get to be companies any more.