Month: December 2014

Here’s another example of why science is awesome.

We now have a crazy cool camera that can take photographs at the rate of 100 billion frames per second. That’s down in the realm of picoseconds. Here’s one of the photos from a series– it shows a pulse of laser light bouncing off a mirror.

That blobby thing at the top right is a bundle of photons. That’s right: we can actually see the photons in motion because even light moves slowly when your clock is ticking in picoseconds. That’s absolutely freaking amazing.

Here’s a little artistic shot of one of our Christmas decorations. These little guys are about an inch tall.

Okay, that thing I said the other day about not posting goofy internet memes… well, I can’t help it. This one struck my fancy today.

I have a client who’s been hosting a lot of sensitive files on a dedicated server that’s co-located at a major provider. We did some juggling and were able to move the files to a different server, and as a result it was time to decommission the old one. Because of the nature of the files, as well as recent high-profile news about security breaches at big companies, he wanted to be sure the files were truly gone. I have no idea how most co-location providers decommission servers and what happens to the old hard drives, but I figured it would be safer to assume the drives could be reused for another client at some point. Someone malicious or just curious would have a treasure trove of information, so I thought about how to completely destroy the data and in fact the server itself.

This isn’t something I do very often (obviously) but after a little thought I came up with a few things that would take care of what was needed. In escalating severity:

Delete all of the files.  This is simple, but on a modern filesystem a delete command really just removes an entry in the folder that “points” to the file data.  The data itself remains on the disk and can be recovered with advanced filesystem tools.  Mac, Windows, and Linux all work this way, so deleting a file is really just superficial.  This can be good if you do it on accident and want to spend the time to recover the file, but bad if someone is malicious and wants to find data.

Delete the disk partition table.  This ensures that the system won’t reboot because it won’t know how the disk itself is structured.  The system can still run without a partition table, but once it’s rebooted it’s toast.

Delete user accounts and access keys.  This prevents anyone from being able to login to the server.  I could continue working on it in this state, but as soon as I logout I wouldn’t be able to get back in.

Nuke the operating system.  I removed all of the boot programs and the operating system “kernel”, so nothing that’s not already running will be able to start.

Zero the disk.  There’s about 900GB of space on the disk, and the files are somewhere in there.  As mentioned above, a determined person could scan the disk looking for data and reconstruct the files.  I created a single massive 900GB file that contains nothing but binary zeros.  This will take a while and eventually fill up the disk, but it’s basically erasing all of that hidden file data because the operating system needs to use that space for all of its exciting new zeros. It took about four hours to consume the disk:

Nice! That’s a big file. Now for the final step:

Nuke the disk.  Once the disk filled up with zeros, I simply removed every file on the server.  I’d already wiped out the file data with the zero-file; this step will make sure no one can do anything at all on the server. Here goes…

I don’t know how far the delete got– since it’s typically alphabetic, it probably wiped out all of the programs in /bin, then the hardware devices in /dev, configuration in /etc, shared libraries in /lib, and at some point couldn’t continue supporting my remote shell connection. It kicked me out, and that was that.

Fun stuff. I don’t often get the opportunity to think about destroying stuff.

Tonight’s lesson: solid state disks don’t like to be crushed.

I was installing some SSD’s in servers at my datacenter tonight, and one of the metal cabinet doors (about the size of a regular door) fell out of the cabinet and landed squarely on my backpack. Amazingly, my ultrabook wasn’t damaged, but one of the SSD’s was destroyed. Ugh.

I find that as I write posts on this blog, there’s definitely a pattern where I write several posts in quick succession– sometimes a handful in a day– followed by long periods where I don’t write much of anything at all. I suppose that some of those doldrums are because nothing noteworthy has happened to me, but more likely it’s that I just didn’t find the time to sit down and write about them.

In any case, I find that it’s always fun and interesting to jump back in time a few months, or even a few years, and read posts that I wrote a while ago. Thus, it seems that the more I write now, the more I’ll have to reminisce about someday. I’ve been toying with the idea of taking the time to write more musings and memories here, rather than posting silly internet memes. This evening I was reading an article written by a guy who worked for the Tandy computer company back in the day. And by “back in the day” I mean the early 1980’s, when computers were a new thing, very expensive, and not useful for too much quite yet. It was fun to read the article because the stuff he talked about brought back memories of those same days.

I once read the entire archive over at folklore.org, which is a huge set of articles written by various members of the original Apple development team. They’re great stories because they dive into some of the technical detail about the first Apple, the follow-on Lisa, and eventually the legendary Macintosh. I was an Apple boy myself, having been raised on an Apple IIe because it was pretty much the only “real” computer out there.

So.

Combining all of the above, I think I’m going to write a series of posts about my journey along the path of software development. Heck, I’ve essentially been a programmer since age eight. Things are a little different today than they were in 1980, but that’s part of what makes the nostalgia fun. Maybe no one will care to read all of this, but perhaps someone in my worldwide audience of three people will find a bit of enjoyment in it.

I can remember some formative moments in my journey as a programmer– they’re very clear and in one way or another they put me on this path I find myself following even today. I’ll do my best to point them out and connect the dots in what will probably be a pretty long and rambling tale. There will undoubtably also be some tangential stories of my childhood thrown in for good measure and a bit of entertainment value.

I can still clearly remember my very first foray into programming. I was in third grade (age eight, sometime in 1980) and I was in the gifted program at school. I loved it because it meant I could get out of my boring old reading class or whatever, and join about half a dozen other gifted kids; we were given quite a bit of freedom in deciding what we could do with our time there. At some point we were told that we had to choose and pursue a pretty major project: it had to be something we’d never done before, and we were supposed to learn it from scratch and have a completed presentation of some kind at the end of the semester. I chose programming. At the time, our school had maybe two or three Apple II computers. They were quite expensive at the time, although I suspect Apple gave substantial educational discounts back then just as they do today.

I wanted to learn BASIC and write a program that I’d show to the class at the end of the project. My great love at the time (and to this day) was astronomy, so I decided to write a program called Mimas. It took me a lot of trial and error, but eventually I had a program that presented a ten-question multiple-choice test to the user. The questions went something like this:

(Everyone knows the answer is “C” here.) After completing the ten questions, the user would be presented with their score and a message tailored to how well they did. I wasn’t as cheeky back then as I am now, so I suspect the message for someone who did poorly was along the lines of “Aww, shucks, you didn’t do so well… would you like to try again?” instead of “Sheesh, loser, don’t you know anything about Mimas?”

I showed the class my finished program, probably beaming with pride. Although I remember the program very well, I can’t recall anything at all about how it was received. I doubt my classmates were awed, but they probably gave me polite encouragement while they prepared to talk about how they learned to play chess or whatever.

What’s funny about that little BASIC program was that it opened my eyes to the world of programming. For the first time I understood that you could tell a computer what to do, and it would do exactly what you asked of it, unfailingly, over and over again. What else could I ask a computer to do? Hmm.

I don’t know how much later my parents bought an Apple IIe, but I’m guessing it was within a year or two. I can vividly recall the excitement of opening the boxes containing the main computer terminal, the beautiful green-screen monitor, and the pair of 5 1/4″ floppy drives. Mom and Dad went the extra mile with this (maybe there was a bundle deal?) because we had two disk drives and a coveted 80-column card, which not only boosted the resolution of the monitor to allow 80 columns of text, but doubled the onboard memory from 64kB to 128kB. Yep, 128kB. That’s about the size of a single decent email message these days, and back in 1982 it was all you had to run the operating system, software, and all of the data you were working with.

I remember that my friends had VCR’s and we didn’t. One time I lamented that fact; movie rentals were just starting to gain traction, and it was a huge deal to be able to watch movies outside the theater or the ABC Sunday Night Movie (which was always edited and peppered with commercials). I thought we should definitely have a VCR, but Mom pointed out that we were the only ones on the block with a computer. I had to admit it was true. These things were expensive, so we couldn’t have it all, but in the end I suspect our Apple IIe was far more influential in my life than a VCR would ever have been. (We did eventually get a VCR so we weren’t complete pariahs.)

I dove right in and started monkeying with the computer. I wasn’t ever the guy who was satisfied with the software that came with it– I needed to know what made it tick. I began by writing little BASIC programs to do random, mostly useless things, but it gave me a rudimentary understanding of how programs worked. Things were actually pretty simple. Each 5 1/4″ floppy disk could hold a handful of programs; 720kB wasn’t all that much space. Of course all of the cool kids had a little device that would punch a notch out of one side of the disk, making it double-sided. I never really understood why the disks could store data on both sides, but the manufacturers only allowed one side to be used. I imagine it had something to do with the manufacturing process– perhaps it was easier to coat both sides of the disk with the magnetic material. In any case, the first thing you’d do after buying a box of floppies was punch them and double your storage capacity. Yeah, you still had to remove the disk and flip it over to use the other side, but two for one is a good deal no matter how you look at it.

I had two friends, Steve and David, who were my “source” for software. To this day I don’t know where they found the programs they had, but I’m pretty sure they didn’t pay for them. We’d get together and they’d let me borrow some of their floppies. That’s where two disk drives were invaluable: they made it possible to do a disk-to-disk copy. Otherwise you had to use a single drive and swap the original and copy about a dozen times, since the computer couldn’t hold all of the disk’s data in memory at once. Two drives made the process a breeze, and often it was a matter of just copying the files. After all, there was no directory structure; all of the programs were in the main top-level directory and could be copied by name.

The software vendors wised up to that, and started implementing copy-protection strategies. They’d hide files or data on the disk using raw sectors, so copying the files in the traditional way would appear to give you a perfect copy, but the programs wouldn’t run. Over time the copy protection became more clever, using extra non-standard tracks on the disks, or unusual sector counts, and so forth. I learned all of this stuff mainly because I would be frustrated by my attempts to copy software, so I’d learn more about how these schemes worked so I could circumvent them. I suppose you could say that a lot of my technical knowledge was really for illicit purposes. I found and used specialized disk-copy programs that could detect these clever mechanisms. Over time I had boxes upon boxes of floppies with all sorts of software. I suppose Mom knew that it was all technically illegal, but since she used some of the programs she never really said anything about it.

In order to understand and work around copy protection, one had to know the technical details of the floppy disk and the operating system that accessed it. I bought a book called the Apple IIe Technical Reference Manual and it was probably one of the most influential books I’ve ever owned. I read it cover-to-cover, which is sort of laughable because it’s exactly what the title implies: it’s a technical manual that goes into gory detail about the operating system, memory usage, jumper pins, and so forth. The funny thing is, it’s still on the bookshelf in my basement office. Anyway, with this book I was able to understand how to control the stepping motor in the disk drive, how the tracks were arranged, how to access “unreachable” sectors, and that sort of thing.

Now I was the master of the floppy disk, ready to move on to something different. That’s a story for another day…

Wow, gas is so cheap these days it makes me want to buy an SUV or something. Forget this 30+ MPG Honda…