Opt Green: KDE Eco's New Sustainable Software Project

The context of Ignite is marketing. They are hyping/cheerleading the most current (not potential future versions! - that doesn't make any money) of Windows and their currently public SDKs is what Ignite is for. Jerry Nixon's purpose was to encourage corporations to move off Windows 7 after the utter failure of Windows 8 as a product. Traditionally, MS's largest customers skip one or more versions of Windows before planning fleet migrations. Microsoft wanted people moving to 10 ASAP. The way you do that is to insinuate (without lying) the most currently released product is the last version for an unspecified amount of time. The media and the computing public fell for the idea Windows 10 is the *final* version (which Nixon didn't say!) hook, line, and sinker to the point where it's now an annoying meme that says more about the public's gullibility than anything else.

Software versioning is very arbitrary, and the product names in commercial software are for pushing products and revenue. They don't reflect what's under the hood. That quote from Tron is very apt: "This year we put a 12 on the box." We all fell for a marketing campaign.

(a) those vans will still be there in rush hour, and

(b) BECAUSE those vans are there, rush hour will start earlier and last longer.

One of the best ways to reduce pollution, is to keep traffic moving. By keeping the 4am traffic moving, you can get rid of it quicker and the later traffic will keep moving longer. Unfortunately, so much logic is along the lines of "the obvious way to improve matters is to reduce the speed limit from 30 to 20, so traffic stuck doing 0 won't be able pollute as much". Seriously, I've seen that argument in a newspaper. Doesn't say much for either the writer, or the editor who thought it was worth publishing!

Much as people hate it, strict enforcement of box junctions would also help matters. Traffic flow (or lack of it) is one of the biggest problems.

Cheers,
Wol

It was probably just a prototype at the moment, but it came over as real and soon to be ready for prime time ...

Cheers,
Wol

> Interestingly, because electric motors are so superior, the largest mining trucks have used them since long before global warming became a concern, they typically have one or more diesel engines running generators that then power the electric motors. This is much less hassle than trying to design a combustion engine plus gearbox large enough to turn the wheels.

I'm afraid that's not because "electric models are so superior". That's simply because electric _braking_ is superior (it is much easier to cool a bunch of resistors than it is to cool the disc brakes, and a mining truck operating in a quarry uses brakes extensively).

And this technology is pre-war. I used to read a lot of autobiographies, and it was clear that (war)ships with this technology - be it diesel or fuel-oil-powered gas turbine, were just so much more responsive, and if required could get under way in minutes rather than hours.

I've thought right from the early days of electric cars that they should replace piston engines with small gas turbines, that would burn almost anything, and use that to drive electric motors in the wheels. Households could use waste cooking oil almost straight into the car engine :-)

Cheers,
Wol

This is not true, but also it is not the right metric.

The metric you want is cost per kWh. By that metric solar is the clear winner.

> The fact some environmentalists don't like [nuclear]

You know who *really* don't like nuclear? Try asking an insurance-company how much it would cost to insure your nice new nuclear power plant.

Not a single plant would be built, ever, if the owners had to buy insurance.

Fortunately for them, many governments, including the US, are actually willing to waive the insurance-requirements and assume the risk themselves.

Unfortunately, even with that massive subsidy the nuclear plants are still way more expensive than solar.

Just wanted to follow up on this -- If you have to disable SMT to mitigate against a vulnerability, that's going to result in about a 33% performance impact, meaning you'll need roughly 50% more resources [1] to achieve the same overall performance. 50% more servers, 50% more datacenter space, 50% more power (and cooling), etc.

Or you can use a combination of microcode patches (possibly in combination with OS awareness) to bring the net performance hit to ~5%. It's a win-win for everyone. [2]

[1] Assuming SMT gives you a 50% performance boost on average, losing it means your net performance will be approximately 2/3rds of what it was with SMT. (SMT gains are highly workload dependent)
[2] If you run truly private/trusted workloads, you're going to disable all of these mitigations as part of your performance tuning anyway.

The browser is not alone, it works in concert with the kernel, and there are lots of tricks the kernel can use to mitigate these vulnerabilities (both between userspace and the kernel, and between the sandboxed JS process and the other browser processes) even without firmware help.

> Even at the OS level, these "mitigations" generally consist of completely disabling hardware features, usually with _severe_ performance impacts. If said features can even be disabled at all.

The main "completely disabling hardware features" mitigation is disabling SMT. Other than that, most non-microcode mitigations are AFAIK code to block speculation (or make it harmless) at key points, which does have some performance impact, but not severe enough to make the hardware unusable. If you can accept some performance degradation, you can have good enough security even after the hardware maker stopped support for that hardware.