This is not a case of misspelling (think Notingham) or variant spelling (think Britney vs. Brittany). There's simply no standard way of transliterating Russian names. Cyrillic "e" may be pronounced "eh", "yeh", "yo", "o" or "ih" and some people will use some kind of phonetic approximation so they don't have their names too badly garbled.

I would have expected them to include the original cyrillic name and all the /obvious/ transliterations in their database, but that's apparently way beyond their capabilities.

I can see those letters fine.

No, you don't.

Just because you don't know Polish, don't assume that "Pchn" and "jea" are actual words.

Explaining quicksort to the layman.

[...]

Sort the names into three piles

That is dumb.

The big advantage of quicksort is that is able to quickly sort in place.

Now try to convey that with your piss-poor piles and cards examples.

Anything but mergesort (including bubbesort) looks contrived with physical objects.

A "central tenant of morality" is just as needed as hair in the soup.

I find the idea that a "Central Lie" is necessary for people to act morally highly offensive, and impossible to prove in practice; but if that is really the case, then better let the whole world go to hell than having to play with and smugly pretend to believe some random bullshit.

And if we're into real Scotsmans, for a "real" Christian, the thing is about sin and salvation, not pretending to be an idiot in the hope that the others will do the same, and so be able to go along nicely instead of killing and maiming each other.

So the solution is either to turn off that specific warning (usually means it's off in all files)

why?

It's very easy to tailor compiler options for each source file in the Makefile.

There's also 'pragma GCC diagnostic push/pop', even if it doesn't work for some cases (like -Wunused-function).

For unused functions/variables/parameters it's best to conditionally define 'UNUSED__' to '__attribute__((unused))' for gcc and use that; creating dummy use cases is stupid.

Yes, there will still be problems, yes, there will ALWAYS be people who are willing to cause physical violence to get their way, but building interpersonal relationships is always the best way to work towards reducing problems.

No. Many people are just rabidly, abjectly bigoted, reactionary fucks. And access to information tools only tends to exacerbate it.

If you ever lived in one of those third-world countries, you would know that the middle-class, relatively affluent (ie exactly the people a westerner can relate to) are the ones that are falling for all that conservative or revolutionary trash. In Afghanistan, that's probably the 1.5 million with access to the internet.

You need solid bourgeois values (foremost hypocrisy and intelectual dishonesty) and LOTS of free time to ingurgitate the amount of bullshit needed to be able to embrace any ideology.

They won't -- because you are obscure -- get it?

no.

15mm about half an inch

You're way off, sooner or later you'll get into trouble with that.

Better try something like: 25mm ~ 1'', 10cm ~~ 4'', 1.5m ~~ 5'.

Come on.

Poking the wrong bits into hardware (as in your experimental driver) will lock hard your entire system -- you won't even have the chance of a kernel panic, micro-kernel or not.

Then, how about those video cards that have hard access to the whole memory, bypassing whatever restrictions the kernel may put in place?

If a driver wants to 'drive' anything, he needs access to the system's interrupts, busses, locks, whatever. At that point, all bets are off.

Most of this is from "Genghis Khan and the Making of the Modern World" (a great read): http://www.amazon.com/Genghis-Khan-Making-Modern-World/dp /0609809644 Other pieces

Attila and Genghis Khan were completely different historical figures -- there was like a MILLENIUM or such between them.

And anyway, trying to interpret old history through modern prejudices and stereotypes is, to put it mildly, cringeworthy.

Many crash-causing bugs are readily exploitable for code execution.

Come on, it would be much easier on Linux to exploit bugs in the filesystem code - I now from experience that the code is not that hardened on that side: even accidental corruption of the fs may easily crash the system.

Why bother with executable files and such?

I don't know of any Unix that regards file system metadata as an attack vector -- it's assumed that the hardware (including the physical support of any non-network fs) is under the complete control of the user ;-)

What system do you use which trashes all its buffer cache from time to time, just for fun?

Usually, a filesystem is fully synced only when it is unmounted, and that cannot happen while a process still holds a reference to a file on it.

Instead of "sync" or "echo 3 > /proc/sys/vm/drop_caches" you can start some memory-hungry program, which will quickly eat up all your memory and force all buffers to disk (either in swap or in the filesystem). Problem solved ;-)

Sure, you're calling "sync" in order to force write all dirty buffers to disk immediately.

Try it without the "sync".

And any user who has read access to /dev/mem can read everything from there, /tmp files or not.

What's your point? Are you assuming that putting random users in the "disk" group is safe?