It took my friends months to find working 8" floppy drives they could take to Guatemala to decode the files the police and army had created during the dirty wars there. I don't want to have to buy a 9-track tape drive to read the one 9-track tape I have (if I find it again, and if it's still even readable.) (I gave away the Sun cartridge drive along with the Sun-2.)

Much more reliable to copy the data every couple of years to some current medium, knowing that Moore's Law means that it's not going to cost much and the only problems will be data formats, not media formats.

Just curious but why do you say that? We have no clue how likely intelligent life is to evolve. All we know is that it has happened once, and it took 3.5 billion years from the formation of the first like on Earth. Suppose that this was very much faster than average and the the mean time for intelligent life to evolve (once life itself has started) is 30 billion years? Such a long time would hugely reduce the number of intelligent species since you need a very stable environment for a long period of time and even then you have to get lucky.

Trying to quantify what you don't know is a mug's game...in order to be able to do it you really need to know what you don't know. If anything I would argue that there is, perhaps, some weak evidence for intelligent life being rare: travel might be hard but radio is easy. We have not heard ET's broadcasts which would suggest perhaps that there is no intelligent life nearby (or they use some technology beyond EM waves).

void *strcpy() { printf("Don't use strcpy, idiot! We told you that years ago!\n"}; exit(-37); }

void *strcmp() { printf("Don't use strcmp either, idiot! We told you that years ago too!\n"}; exit(-37); }

Also, according to the articles I've read about this, the somewhat more official patch came out in 2013, but wasn't marked as a "security" patch so it only made it into the newer OS versions, but wasn't retrofitted into the older ones. So it'd be fixed in Ubuntu 14.04, but not in the 12.04 LTS version.

Oh? You check for errors in code that gets #ifdef-ed out in a production build? What could possibly go wrong with that plan? (Or do you mean first the check, then the assert, following every function call, further hiding the few lines of business logic in a huge function).

It's quite easy to write "all exception safe all the time" code in C++, in ways that even the junior guys can't screw up. It's not obvious what that coding standard looks like. That's the big problem with C++. Many have never even seen it done right - it's very understandable why business largely moved to managed code.

People see RAII and think "oh, instead of allocate at the top and free at the bottom, I'll allocate in the constructor and free in the destructor". No, you're still doing it wrong if you have any non-trivial destructors outside of a bit of well-reviewed library code.

If you're doing it right, the only avenues for screwing up resource management are adding stuff to a global object and forgetting it there, as with every language.

Moore's Law is only partly your friend here - storage keeps getting cheaper rapidly, but that also means that not only do devices become obsolete, but the interface specs and data formats also become obsolete. You probably don't have an 8" floppy drive anywhere, or a working 5.25", or the right kind of cable to plug the 5.25" drive into, or a Bernoulli drive, or a 9-track tape drive (800, 1600, or 6250dpi), or the Sun cartridge drive, or anything to plug those MFM drives into, or SCSI-1, or probably SCSI-2. You might have something that can handle IDE / PATA, or an old laptop with PCMCIA, but even those are getting scarcer. If you can connect to that old disk disk drive, you can probably load a virtual machine running NetBSD that'll have drivers for the file system format, but maybe not; you certainly don't want to risk having Windows "update" the format. You might think that FAT 8.3 format will stick around for a long time (and maybe it will for reading, but it's rapidly getting replaced with FAT16, FAT32, ExFAT, NTFS, etc.

Leave aside the question of whether you can read a 20-year-old version of WordStar or WordPerfect format file (unlike my late-70s nroff files, which would be readable if they weren't on a 9-track tape I've probably lost.) You can probably read that 4-year-old TurboTax file, but if you need to get tax data back from when you bought your house, you'd better have everything on paper.

Just for physical format alone, you need to copy stuff every couple of years.

Acid-free paper, otherwise you and your friends will just keep eating bits of your archives.

More seriously, paper's only good for some things, and only if you protect it well enough. Some years ago, my work hard drive crashed, and when I was driving to work a day or two later, my coffee cup bounced off the holder into my briefcase, taking out both the Palm Pilot and the dead-tree copies of my data. There were backups of some of my PC data, but my current calendar was gone.

The cloud makes a great backup. If what you're archiving is small, encrypt it and upload it to a variety of cloud file companies with free offerings - Cloud Drive, OneDrive, DropBox, etc.

For a moderate amount of data, use (encryption and) Amazon Glacier. If you don't know the trick: Amazon offers mail us a hard drive as an upload format for S3 and Glacier, and it's as good as way to do offsite backups as any.

I wouldn't use the cloud as my only archive, but as the offsite copy it's probably more disaster-survivable than most other choices most of us have available. (And affordable if we're talking a few hundred GB of personal stuff, not the entire multi-TB geek archive of "binaries").

:-)

If you don't check for an error due to sloppy coding, you get a failure sometime later which can be quite hard to debug. If you don't handle an exception, your program exits, and if you can repro the problem under a debugger, any good debugger will break where the exception is thrown - immediately debuggable. Which approach better protects customer data from bugs?

If you check for errors after every call, your program become 80% error checking, 20% business logic. Needless cluster that obfuscates code.

For a large enough C program you re-invent exceptions anyway. The return code from every function becomes the error code. The first thing you do after every function call is check for errors, and either handle the error locally if you can, or return it up the stack if you can't. If you make some handy macros for doing that, you might as well call them "try" and "catch" and "throw", since you're just doing what the compiler does with exceptions, except in a manual, tedious, and eror-prone way.

Really, this was an intelligent argument 20 years ago. The experiment was tried, the data is in, almost everyone moved to languages with exceptions because they make it easier to get it right, not out of some group masochism.

Even in Finance, they've done that. Look at PayPal. The only reason that it exists is that the banks and credit card companies dragged their feet with online payments. They're now doing free electronic person-to-person transfers, but it's still expensive to take credit card payments online.

Exactly. Go back a couple of hundred years and you even have well-off people saying 'I don't need to learn to write, I can afford to hire a scribe'. You had people saying 'not everyone needs to learn to read and write, there aren't enough jobs for that many scribes anyway'.

Before he retired, my stepfather was the head groundskeeper on a golf course. Not exactly the kind of job you think of as requiring coding skills. Except that they had a computerised irrigation system that could trigger sprinklers in response to various events (humidity sensors, motion sensors, time, and so on). It came with a partly-graphical domain-specific programming language for controlling it. It's going to be very hard in the next 50 years to find a job that doesn't require some programming to do it competently - even this kind of stereotypically low-tech job requires it now.

I used to pirate games and I used to buy games. I eventually couldn't be bothered with pirating and worrying about malware or with trying to jump through the hoops that the publishers wanted, so I stopped playing games altogether. Then gog.com launched and sold me games that I was nostalgic about, cheaply. Then they started selling newer games. I spent more with them last six months than I did on total on games in the five years since Steam was launched and the industry wend DRM-happy. I can download DRM-free installers for all of the games, often in OS X, Windows, and Linux versions.

It turns out that there's another answer to piracy that works: sell your product in a way that's easy to use at a reasonable price. Stop worrying about pirates and start worrying about customers. Someone who wouldn't buy your game anyway who pirates it is not a lost sale, but someone who can't be bothered to put up with your treating them like a criminal and so doesn't buy from you is. Buying a game from gog.com is easier than pirating and, if you factor in the cost of your time, probably cheaper as well.

Give me a product I want for a reasonable price and I will happily hand over my money, because I feel that I'm getting something valuable in return. Don't, and... well, computer games are not the only form of entertainment available.