That reminds me of the Yes, Prime Minister foreign office 4 stage strategy. You've just outlined stages 1 and 2. I guess that once they can no longer deny it's anthropogenic, they'll move to saying that there's nothing we can do (stage 3), again absolving them of the need to do anything. Then they won't need stage 4 until after some coastal cities are already underwater and millions of climate refugees/victims are making their lives a misery.

It'd be funny if it weren't so tragic.

you can't just turn up the thermostat and assume the room will stay the same temperature, nor can people simply burn more energy while living the same life style in the same body.

I don't see why not. You could just convert the energy to heat. The body's homoeostasis system will then expand the surface blood vessels, or start sweating, to dump the heat to the environment, just like it does whenever you get warm. It'd just be like having an artificially increased rest metabolism.

Ha!

IANANP, but I did take some nuclear physics courses as part of my degree.

It's somewhat unlikely that there's an exothermic nuclear reaction in there. Iron/Nickel is the tipping point where you go from fusion being exothermic to fission being exothermic. (This is why elements up to and including Iron and Nickel are much more common than elements from Cobalt onwards; they can be made in a stable way in the core of a star for a while. Once you start to (try to) fuse these elements though, you suck energy out of the star and things go bad.) Copper is the wrong side of that limit.

Even putting that aside, while you're correct that fusion is not "new physics", "cold fusion" is, because of the need to get the nuclei together in spite of the electrostatic repulsion. Yes, catalysts/quantum tunnelling/whatever aren't "brand new physics" in that they are concepts we are aware of, but finding a way in which they can be applied to allow cold fusion would be a new application, and is what I was intending to encompass in my meaning.

However, this is kind of beside the point, as all I was really doing was obligatorily referencing xkcd.

I bet you $200 it's not cold fusion, or any other kind of new physics.

Can't you do both? Make them unsearchable by default, and also untag them as they are added?

You should really read through this thread (especially Linus Torvalds' comments)

I did, when the problem first hit. Linus is right for the code that he writes, in that the public APIs he is in charge of (the Linux kernel<->userspace boundary) does not have a normative public specification, is not designed to be re-implemented by multiple vendors (despite the BSDs impressive efforts), and, while the documentation (at least for syscalls) is generally pretty good, the only real definition in Linux of "what does this part of the API do?" is "whatever that part of the API currently does".

Linus' comments are dead right for the project he works on. However, he does not work on an implementation of The Standard C Library.

It is extremely unlikely that memcpy() outperforms memmove()

But ... that particular change to memcpy() wasn't made on a whim, for no reason. Rather, it was specifically made so that memcpy() could seriously outperform memmove(), because you can do extra optimisations if you know that the source and destination must not overlap!

the sane cleanup is just to add a new guarantee for a previously undefined usage of memcpy.

So convince ISO to change the standard, and the C libraries will follow. Including glibc.

Plus, I'm not convinced that strncpy() is a good example of a function that has "fix[ed] the brain damage". IMHO strncpy() is pretty brain damaged itself, and best avoided. strlcpy() is better, although not standardised, and not in glibc because of perfectly well-reasonsed arguments by Drepper. So I much prefer snprintf(dest, sizeof(dest), "%s", src);

Quite right. The OS is in charge of mechanism, the applications - via the services (mechanisms) the OS provides - is in charge of policy.

Keeping "buildings, traffic and services running smoothly" sounds like policy to me, and hence in the domain of applications running on an OS.

As an ex-smuggler who feels like going straight by, e.g. doing a little gas mining in an out-of-the-way place that won't attract much attention from the emp^H^H^Hauthorities, that sounds like just what I was looking for!

Very few who criticize Flash have ever [...] explored it's benefits for [...] cross-platform usability.

What the...?

Ha ha ha ha hahahahahahahaha!

*wipes tears from eyes* That's probably the funniest thing I've heard all day, thanks!

Flash? Cross-platform? You have got to be kidding! Or on crack. Or maybe you can point me to where I can get Flash 10.3 for *BSD/Solaris/Plan9. Or where I can get Flash for any OS running on IA64/generic ARM (not just Cortex-A8)/MIPS/PowerPC/Sparc/Alpha? Heck, they only started supporting x86-64 properly this year, despite that arch being over 10 years old.

Flash cross-platform. Heh. Good one!

It's not a glibc bug, it's a bug in Flash.

Flash was using memcpy(3) incorrectly. It happened to work on older versions of glibc/x86 by chance. There was never any guarantee that it would work on later version of glibc/x86, or on non-x86 versions of glibc, or non-glibc libcs (e.g. BSD libc), or basically any other Unix/POSIX/C-based system.

The whole bloody reason for API documentation, standards and the like is so that bad or non-optimal implementation details need not be fixed in stone forever! You should be able to re-implement an API any way you like "under the hood", and providing the implementation meets the API spec, you're good to go. Anyone relying on undocumented side effects of a particular implementation is doomed to pain. That's how APIs work. That's how the POSIX and the C standard work, and that's how memcpy(3) works, and that's the reason for memmove(3)'s existence.

Yes, all developers make mistakes. Sometimes we do make the wrong API call, or pass a NULL where we shouldn't, but the code accidentally works on one implementation of the API for a while. When we become aware of it, the correct response is to FIX THE BUG IN OUR USE OF THE API on all current branches and release a "point" update ASAFP. "Months" should not be an acceptable timescale for that sort of thing. Especially for something as simple as replacing calls to memcpy(3) with calls to memmove(3).

That seems to be more along the lines of how quite a few TV shows (although not CSI/NCIS) and movies still think you need to be on a call for a certain amount of time for the cops to be able to trace it, or how on one episode of CSI they went through a long and drawn-out way of tracking down the printer a note came from without even looking for the yellow dots. It seems the writers of these shows tend to purposefully "ignore" real life mass-surveillance law enforcement aids.

Their motivation for this is left as an exercise for the reader...

Surely you mean Good. I need the cash.

(Not much point making the bet if you're broke now, if no-one tries to reproduce the result for years...)