This is a Python article! Of course somebody has to complain about whitespace! When did you ever know a Python article to not start an argument about whitespace?

Nuclear still looks good compared to water: http://en.wikipedia.org/wiki/Energy_accidents#Fatalities

I believe a properly administered git mirror will do everything the GP wanted, except for testing the backups (which isn't git's problem) and the "2-sided crypto-hash compare" because, in my amateurishness, I don't know what that is. I do know that git does cryptographic hash checks on pull and push. I don't know exactly what checks are done when. I didn't know that "git clone" didn't do those checks until today and it seems that the KDE folks didn't either â" but, hey, we all do now. (From the update, "git clone --mirror" is what failed, but I believe the "--mirror" part is incidental. Should have been "git pull --all --force" as far as I know in my amateurishness.)

I see other folks are less keen on discussing these issues than making condescending remarks about how to do backups. The update to the article goes in to a fair amount of detail about what they didn't do and why. It's almost as if they did think about these things.

What is this "git --mirror"? It's in the summary but not the original article. There are different git commands that have the --mirror option and they work differently.

My simple experiment, with an old version of git, shows that "git clone" succeeds whether or not you specify --mirror, that "git pull" doesn't have a --mirror option (maybe because I'm out of date but http://linux.die.net/man/1/git-pull doesn't show it either) and "git push" fails (hangs, in fact) if it tries to push a corrupt blob.

A discussion about whether you should use the safe method for backups wouldn't be very interesting because of course you should. The issue here is that they didn't know they weren't doing integrity checks and they may not be the only ones.

Cloning new repositories rather than pulling to existing ones sounds risky to me. If that's what they were doing I don't know why. A forced pull ("git pull --force") will keep old branches and a reflog and so on. It will also, as it happens, abort if an integrity check fails. So this seems like good practice. But I haven't seen any discussions of good practice in backing up git repositories and I'll excuse anybody not knowing the clone operations didn't do the integrity checks. (Especially if they also saved tarballs, whatever the problems with those may have been.)

I vouch for the parent. I checked the man pages and I don't see this behaviour documented. Those who think reading the documentation would have made the lack of integrity checks clear can easily point to the place it's documented. Then we can discuss whether a competent admin should have found it.

(Note: I read the latest article, and they did have backups. So any posts about them trusting one tool and not having backups are irrelevant.)

Yes, you can override the no-cache headers in Squid. Use a refresh pattern and ignore or override the headers the server sends to defeat the cache:

http://www.squid-cache.org/Doc/config/refresh_pattern/

MAC address

Wegener knew the continents were moving, and collected a huge amount of evidence. Wegener didn't know why they were moving, but neither did anybody else. Wegener also failed to produce a cure for cancer and was hopeless at averting the Second World War. He did make the mistake of producing half-baked arguments for why the continents were moving, and getting his figures wrong on the rate of drift.

Geologists rejected his model because they decided to argue with Wegener, instead of continental drift. They proved Wegener was wrong and somehow thought that the whole problem of continental drift had gone away. They also applied special pleading, because they didn't know why the continents were rising (or they would have eroded away by now) or where the land bridges came from. According to the scientific method, they should have considered continental drift based on the evidence and the evidence should have been overwhelming. This is a classic example of human weakness in the face of a disruptive new idea.

I think it's very rare in Silicon Valley that an otherwise deserving businessman loses out because they're black. Rather, the deficiency is in the lack of deserving minority businessman in the first place. That's a social and cultural issue, and may not even be a problem. Not every culture needs to have equal representation in all fields; that's one of the ways in which cultures are different.

From over here, it certainly looks like a problem if Americans whose families have been in America for generations are still pushed into different societies and cultures according to skin color. Who says "African American" has to be the culture with quaint differences from Americans with the opportunity to succeed?

"Harmony with international trends" is a particularly insidious phrase, isn't it? Not harmony with international reality. Most countries don't have laws like this. But they're thinking about it, or will be when we send the boys round, so you'd better do what we say if you know what's good for you.

Thing is, if I were running a clandestine organization, I'd want my recruits to stay off social networking sites. I don't want the authorities to find our network mirrored on Facebook. So my ideal recruit would have the social networking trail of . . . an undercover policeman.

Libraries may close or may go fully digital. They'll be allowed to do this because nobody will care about paper books. The books might go into storage somewhere (even in the basement) or they might be trashed. The Library of Congress will still be there, and so will the city zoo, with lions.

I don't even see a cable saying the contact didn't see bloodshed. What two of them (with slightly different wording) say is "THERE WAS NO MASS FIRING INTO THE CROWD OF STUDENTS AT THE MONUMENT". These are edited by the Telegraph, but if they edited out a clearer refutation of bloodshed . . . why? "No mass firing" in the square is consistent with what I thought we thought we knew. Nothing about people not being run over by tanks or other vehicles in a part of the square this diplomat may or may not have been watching.

That's the other thing about the CLI vs GUI debate. It doesn't only ignore the fact that you can use both together, but that some applications are neither CLI nor GUI. Yes, they have GUI versions, but emacs and vim are fundamentally not GUI applications. They are, let's speak it, full screen text mode.

Full screen text mode is not a CLI. There are editors that run in a pure command line. The most famous is ed. When vi was invented, it was a big step up from ed, but it wasn't a full replacement because it required full screen text mode.

Full screen text mode is certainly not a class of GUI. It doesn't require graphics. It may borrow concepts from a GUI, like pointers, menus, even windows, but it isn't graphical because it doesn't require the operating system to have graphics capabilities.

Full screen text mode is what we were using before GUIs took off. For certain tasks, it can be as usable as a GUI. It does, however become redundant when you have a GUI, hence vim and emacs get upgraded to GUI applications. The CLI, then, is the survivor, and full screen text mode gets written out of history.

America's bloodiest war was with itself.