That's a very valid question... Probably the person who wrote the related API spec thought that UTC was a good way to communicate time, since it doesn't have things such as time zones and daylight savings time to deal with... I think the idea behind UTC was for it to be a good time format to use for communication. How it deals with leap seconds makes that only true if all the software involved, or its time library is kept up-to-date for each new leap second that gets inserted.

Drift is not a solution. Drift means accepting you will have a clock that can be one second off. Accurate clocks means that two independent systems are each keeping time accurately enough to allow monitoring of events such that it is known which event occurred first, or how much time difference _exactly_ there was between the events, even if the events occurred on different systems thousands of miles apart.

It's not about education, it's about determinism. Leap seconds are _not_ deterministic like leap years, etc, are.

Leap seconds are not known more than _one_ in advance, at the most... For example, right now, nobody knows exactly when the next leap second will be. When one is inserted depends on where the planet 'hangs out' in space around the sun, and that has some characteristics that are either nondeterministic, or still unknown to us humans.

It is not possible to make a program the will correctly account for all leap seconds it will encounter in its life for the next five or ten years, because those leap seconds have not been determined yet.

For example: How many seconds are there between August 24, 2010, and September 1 2017? You don't know yet, because you don't know how many leap seconds will be inserted in that time period, so no programmer can make a program _right now_ that can give that answer correctly. Yet, there are many applications where such accurate time differences are needed. The solution, is in the clock.

http://www.timeanddate.com/time/leapseconds.html

Otherwise maybe what's going on is that the volume of space around the planet between those roughly 9km and 62km is so large compared to the amount of available helium that even while it's still there, the helium will be dispersed so much that it will be practically impossible to retrieve (I mean, the gas will be at very low pressure).

Can somebody do the math?

It's not easy but also not impossible, and it seems to be improving a bit over the last year or two. Bread from the bakery department doesn't always have hfcs, nor do many 'pepperidge farm' branded prepackaged breads. The latter used to be one of the very few options in my local supermarkets, but now there are some more brands that are also hfcs free. Some even loudly advertise it on their labels. I really prefer to make it at home with the bread machine, but to be honest I'm usually just too lazy or not thinking ahead enough to even pour the ingredients in the machine...

Even though I don't drink much soda anymore: I saw some hfcs free pepsi products in the store recently too, as some kind of special, and there is of course Jones Soda which doesn't have it. Also, the mixes from the sodastream company don't have hfcs, and their diet sodas use sucralose (splenda) instead of aspartame.

Note that in Europe, where obesity is a smaller problem, hfcs usage in food is also much smaller, if not virtually nonexistent, and most (non-diet) products are simply sweetened with sugar. It doesn't prove anything, but I see smoke, so I'm trying to reduce my exposure to it...

The difference is probably that in this case the speaker knows lip-reading is being used, specifically wants to be understood, and probably is getting live audio feedback about how well it's working.

Or Microsoft is behind this and they want full control of Novell...

Eh, the story is about Novell, and nobody has used the word Microsoft and Linux yet, and they usually go together with 'Novell'...

Oh, and the SCO vs Novell trial is still on the 'todo list' for the courts...

Who knows what is really going on here... People tend to think long and hard before offering to spend $2B of their own money...

"Disclaiemr: I have no idea what I'm talking about."

Agreed... Neither do I, but I have a hard time imagining that plastic wrap containing an updraft of air strong enough to drive a turbine that generates.... 100 friggin Megawatts of electricity from it...

Would plastic wrap contain such a tornado? Do you have such winds flowing through your greenhouse (the part of the bottom has all the same air flowing under it as what eventually goes up into the tower...)?

Oh, and would that lowest plastic panel on the bottom of the tower be strong enough to hold the weight of the 2396 foot of plastic panels above it? That antenna mast definitely won't be strong enough to hold that weight, let alone stay upright on a windy day.

"Because that's how it works. You start with some initial reserves. You mine them cheaply. When you start to run out of reserves, prices go up. The high
prices cause exploration. New mines open up, and prices go down. Repeat ad infinitum."

Just like how it has been working so well for oil, copper, gold, pretty much anything else we dig up from the ground or a mountain?

</sarcasm>

"It's not more dangerous than the output of other industrial sites"

Umm, really?

Let's take just one example out of the so many possible. Look at one of the more 'benign' risks of nuclear power: tritium releases into ground water: How many industries other than nuclear plants need federal "Lessons-Learned Task Task Forces" for stuff like that?...

Tritium releases such as this one in august 2006 in California:

http://articles.latimes.com/2006/aug/18/local/me-radioactive18

Groundwater Reveals Radiation Leak at San Onofre

Cancer-causing tritium is found under the nuclear plant. Drinking water supplies are tested.

Radioactive, cancer-causing tritium has leaked into the groundwater beneath the San Onofre nuclear power plant, prompting the closure of one drinking-water well in southern Orange County, authorities said.

"simply because my best guess was that I am the only person who will ever want feature x"

You may have been underestimating 'the others'... "Release early, release often" means release it, even if you think it's (still) useless junk. Just label it as that, and perhaps others will find it better than useless junk, or if needed maybe clean it up and turn it into something you never even thought it could be.

At least send a message 'listen guys, this is what I threw together for myself and here is why', or put up a webpage on a blog or wiki somewhere with your patches and mention the site once on the mailing list.

Do it for the others, whom may surprise you.

A lot of programmers with good intentions end up never releasing what they've made, and what could have turned into something great, just because they want to 'clean it up first', or because they think 'nobody would want it' (they wanted it, so somebody did, making it less than unlikely that somebody else wants it too). Release it, just be honest and say that even you the creator thinks it's dirty and useless. Perhaps others disagree about the 'useless', or are better/faster than you in cleaning it up, or maybe it inspires others to make something similar, or more advanced, in 'the right way'.

"Mike wonders why the kernel tries so hard, rather than just failing allocation requests when memory gets too tight."

I realize this is formulated in a negative way, with no prior reservation of resources, but erm, it was fast and easy right now and gave a sufficient response to the thread with the lowest possible latency, and if and when it ever becomes important I'll reformulate it nicely right before it's needed, and until that time those resources stay available for other uses. So be warned, here it comes: Probably that is because Mike doesn't know what lazy allocation means, why it is used, and that that means that there is not an allocation request to fail when the OOM condition happens?

Hmm, I sound so arrogant in this post that I'm probably wrong... But I can't help but feel that I'm pretty close to being right...

"If it's not superscalar, why does it need a branch predictor?"

Because it has a pipeline and without a predictor a branch means a pipeline stall until the branch comes out the execution stage. With a predictor, even a simple one, it means a pipeline flush only when the predictor is wrong, which means you can gain a lot of cycles with even a very simple predictor.

And slow down interactive response such as seeking?

No, latency is _not_ good.