... i.e. /home/karellen, but the whole /home partition.

Well, to be more precise, I encrypt the /var partition, and /home is a bind mount to /var/local/home

Yup, I guess that's why many European societies which have much tighter gun controls and lower levels of firearm ownership than the US are so much less polite.

Oh, wait...

Yes, my ATI drivers had a hand in this, but that's part of the problem itself: why do all new GUIs demand glossy, sugar-coated rendering at the cost of my processing power? [...] For the record, even KDE4's non-accelerated mode rendered incorrectly.

I used to be the biggest proponent of Linux around, but it is really difficult to advocate something when its quality is dropping so quickly, and you yourself are barely able to operate it.

If KDE4's non-accelerated mode is rendering incorrectly, then I suspect that that is a serious problem with your graphics card drivers, or maybe even your graphics card. Really. And if you're using an out-of-tree driver with serious problems, I don't see how you can claim that it's the quality of Linux that's the problem. The Linux devs have no influencing there at all.

Lots of people (e.g. all the KDE developers) have been using KDE4 all day, every day, for 4 years or so now. Don't you think they'd have the means, motive and opportunity to clean up such problems if they were experiencing them? The fact that they're not experiencing them (and, as an almost-worthless anecdote which I'll throw in anyway, neither am I) is a pretty good indication that the problems you're experiencing aren't in the KDE part of the stack which you share with them. Or in Qt. Rather, they're much more likely to be in the part of the stack which is unique to you - your drivers and graphics card.

While I agree with you that GNU touch with its extended date parsing is fantastic and worth the space it requires, that link does not make your point that

"touch" supports the --date=STRING feature, which contains a very elaborate parser for all kinds of weird ways to write the date, including locale support for different languages.

Rather, it specifically says that

The option-argument shall be a string of the form: YYYY-MM-DDThh:mm:SS[.frac][tz] or: YYYY-MM-DDThh:mm:SS[,frac][tz]

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).