Not just the costs, but also whether the energy is dispatchable.

Power sources which can be turned on and off at short notice - such as gas and hydro - are economically more valuable than ones which can't - such as coal and nuclear. (Some nuclear plants can be ramped up and down, but the capital costs are so high and the fuel costs so low that it doesn't win you much.)

Any of the above are considerably more valuable than sources which are both non-dispatchable and intermittent, such as wind and solar. (How much more valuable depends on factors such as the shape of the demand curve, and how much of the rest of your capacity is gas and/or hydro. Intermittent sources can work quite well in some locations, others not so much.)

It would be a fallacy if background levels were fixed and unavoidable. They're not. So long as people are allowed to and choose to travel by air, and live in areas with above-average background radiation, it is reasonable to argue that nuclear power should be held to a similar standard.

(Granted that medical imaging is different because you would normally be doing it for a good medical reason.)

0.25 mSv is a measure of the dose received, not the radioactivity emitted. A given amount of radioactivity inside your body will result in a larger dose than the same amount outside, so the effects you describe should already have been allowed for.

Besides, if you believe in the LNT model (which current standards are based on) then it makes little difference whether you give 0.25 mSv/yr to ten people or 2.5 mSv/yr to one person (both being well below the level at which acute effects become significant). Bioaccumulation is an issue, but merely having an uneven distribution should not be.

Bear in mind that the safety precautions needed to prevent very low level emissions are different to those needed to prevent catastrophic meltdowns. Focussing attention and resources on the former rather than the latter isn't necessarily in the best interests of safety.

I'm told that they contributed a few libraries too, but with cryptic names like glibc they surely can't be that important.

The main reason is that burial is fairly safe whereas rockets are not.

Let's put my comment back into context. I was talking about forgetting to bind a private network service to the loopback interface. That would normally be done by an administrator. If an administrator is acting maliciously then you have fairly serious problems with or without a local firewall. In fact, this is a pretty good demonstration of my point that if you are going to use a firewall to protect against that kind of threat then the firewall wants to be on a different box (eg. a router or dedicated firewall), not the one that you are expecting to be compromised.

To be clear: I'm not saying that firewalls should never be used on Linux-based hosts (that would be ridiculous), only that they are not a necessary part of running Linux securely in the way that they are for Windows.

If you need a service to be publicly accessible then you will need to configure the firewall accordingly, in which case it typically provides no protection if the service is exploitable.

If the service doesn't need to be publicly accessible then either turn it off or bind it to the loopback interface. Why add extra software to protect against a vulnerability that you could have avoided creating in the first place? Note that operating systems that take security seriously do not install public-facing network services unless you ask them to.

Firewalls certainly have their uses, but they aren't a necessity on non-Windows machines in the way that they are for Windows.

Yes, but I presume you are talking about Windows machines which run an SMB/CIFS server out of the box. Most GNU/Linux distributions rightly don't do that. Typically if you want to run Samba, or an FTP server, or an HTTP server on the default port then you need to be root to do that. Once you are root then you can also poke a hole in the firewall.

Granted you can run servers on high-numbered ports, but within a LAN all that does is allow two machines that had already been compromised to communicate with each other. For communication with the outside world I prefer to detect and/or block that at the boundary router (otherwise all it takes is a local root exploit to disable the firewall).

The same applies to outbound connections, although in a world where so many programs need network access that is arguably a lost cause for general-purpose workstations. In any event, a firewall isn't the right tool for controlling the capabilities of individual programs: you really need something like SELinux or AppArmor to do that effectively.

For machines which are not routers the comment is just as valid now as it was then. If you use a GNU/Linux distribution that takes security seriously then it will not install any externally-visible network services by default. The attack surface in that condition is small enough that installing a firewall won't help much, and might even make matters worse. If you deliberately install any public-facing network services then you need to add matching firewall rules, so again no benefit.

A firewall does help if you install a private network service and forget to bind it to the loopback interface (unless you have one of those systems which automatically install a firewall rule alongside the network service, which totally defeats the purpose of having a firewall). In any event, this only protects against internal incompetence rather than external malice, so is not a necessary part of running a secure system.

Firewalls are useful on routers, and on servers where you want very specific control of what can be accessed from where (such as a DBMS that is only accessible from a single client machine), but for typical Linux-based hosts they add little.

Already been done as it happens: Family Guy had a clip from an 'edited' version of Cosmos in which the Earth was explained to be 'hundreds and hundreds of years old'.

When they become adults, regular people often move on to zealous advocacy of their preferred political system, nationality, or religious denomination. This often descends into violence, sometimes over seemingly trivial differences between the two parties. Personally I find that very off-putting: give me Debian vs. Ubuntu any day.

This isn't a zero sum exercise: by flattening the peak you are lowering the underlying cost of generating the electricity -- because you can use more efficient methods -- which in a competetive market should reduce the average price.

(Obviously in an uncompetetive market all bets are off.)

That's a matter of perspective: followers of the Roman Imperial cult would have considered them to be gods, followers of most other religions obviously wouldn't. Since their elevation to godhood would have been formalised by the senate, and since we have firm evidence that both individuals existed, you could argue that as deities go their claims are stronger than most.

(Granted I'm not sure which came first, month naming or apotheosis - quite possibly the former.)

My problem is that once you cross the line from a policy of keeping religion out of the calendar system to one of keeping Christianity out, you are entering questionable territory that I for one would be reluctant to endorse in any way. Even if you frame it as polytheism in, monotheism out, I think that destroys any case that CE/BCE should be adopted on the grounds of avoiding religious bias.

Besides, if it is acceptable to retcon the epoch to avoid disruption, surely it would be logical to retcon AD to mean something else so that you don't need to change anything?