Looks like the BeBox motherboard didn't have the external L2 in the first place.
Besides web sources, logic dictates this as well: Since dual-cpu was its selling point, it wouldn't make sense to ship a disabled L2 implementaton on the mobo at extra cost. There was no single-cpu model.
Electricity is fungible, so when big operators buy wind-only power from the market, the rest of the demand uses the non-green power left in the pool.
(It still potentially increases wind buildout so it can have indirect positive impact especially if wind is not competitive at the same prices with fossils)
Also the accounting is "we bought as many MWh of wind power as we used" over some time window, so in reality they are using fossil power in peaks, competing with everyone else and placing pressure to expand fossil based capacity.
These are also the reasons it's probably better to talk about the electricity used instead of trying to translate it to emissions by proxy, which is prone to being gamed due to abovementioned reasons.
(Also the number is high rather than low if you consider that all the individual slices of the emisison pie at this subdivision granularity are pretty small)
There are some YAML based schemas there too. How does this work, is there a canonical YAML->JSON transformation, or does JSON schema spec have explicit YAML support?
Buildings lose value over time in most places. And in many places where they don't, including renovation investments in the picture results shows declining value.
Doesn't the shielding help prevent heat output only with short duration power use peaks? If we imagine the conductor is heating at the same rate 24/7, all of the heat must flow out of the cable at the same rate it's getting generated unless the conductor's temperature can increase indefinitely.
The x86 monoculture has shaken around a bit. But surprisingly it seems there has been friction even on the JVM side, partly because of Docker style nonportable containers had time to cement in the x86 monoculture period.
We're so far behind in replacing fossils and fighting off global warming disaster, that we should do both. Nuclear has worse bang for the buck though and decades long lead times. But as long as it can be financed without displacing more capital efficient renewables we should still build nuclear as well.
Network segregation is your last line of defense. Having anything rely on it is a recipe for a bad security that's always just one step away from someone getting around it due to misconfiguration, request forgery, networks configuration changes over time, malware transiting over via VPNs etc. And of course from the SW vendor POV they don't know if the customer env employs this defense in depth layer, so it's really irresponsible to rely on it. Like is amply demonstrated here...
If a product upon unboxing promptly flops on its back with "come here internet" access controls, even if by good fortune it's saved by your network ACLs, it's time to put it back in the box and return it.
Interesting that ES is still such a widely used component, this is a huge red flag about a software product. And of course there are lots of other regular complaints about it (eg uses a lot of memory and wants a 3-node cluster so costs 4 figures/mo to run on AWS).
Your impressions are cordect: DynamoDB is quite low-level and more like a DB kit than ready to use DB, for most applications it's better to use something else.
There are benchmarks for different purpouses, but for users if you're going to run just one benchmark, the best one is the workload you have, or anticipate.
Besides web sources, logic dictates this as well: Since dual-cpu was its selling point, it wouldn't make sense to ship a disabled L2 implementaton on the mobo at extra cost. There was no single-cpu model.