Storage Culture


In a recent interview with Forbes, Seagate CEO Steve Luczo offers a rather startling observation regarding the current production of digital storage capacity:

Our industry shipped 100 exabytes of data five years ago, 400 exabytes in 2011, and we’ll probably ship a zettabyte sometime between 2015 and 2016. A zettabyte is equal to all the data that’s been digitized from 1957 through 2010. Everything, however you want to think of it, cards, tapes, PCs, mainframes, client/server, minicomputers – one zettabyte. And we’re going to ship that in one year. So whatever the architecture is, pads, phones, notebooks, ultrabooks, real notebooks, PCs, servers, clouds, one year, a zettabyte – that’s all going to be on rotating mass storage.

The language of digital storage (gigabytes, terabytes, zettabytes) often abstracts the very real constraints of space, so Luczo’s analogy is stunning: “A zettabyte is equal to all the data that’s been digitized from 1957 through 2010.” Wow.

As Kirschenbaum notes in Mechanisms, we were once firmly aware of the physical constraints of storage. A disk once held only 1.44MB, and software installation spanned many of those plastic squares–the user inserting a disk and removing it, inserting a disk and removing it. I can clearly recall my undergraduate job as a computer tech–how we would groan every time we had to install Windows 95 via floppy disk. Storage constraints were very real for us.

As I consider the launch of Google’s Drive service, however, I can see the slow shift–not just how the physical constraints of storage are abstracted away, but also how the digital metaphors are fleeing with them.

Double Dragon PC Box Those metaphors were once not just real, but also a necessary part of working with software. I remember, at some point in the early 90s, how I saved my allowance to purchase a copy of Double Dragon for the PC. My father had a computer in his office, and I didn’t have a Nintendo, so the PC was the only way I could get my arcade fix at home. I sat at the computer, pulled the shrink wrap from the game, and carefully removed the 3.5” disk from the box. I then put the disk into the computer’s drive and waited. Nothing happened. I tried to type a few things. Run. Go. Launch. (At this point, I knew nothing of MS-DOS or the filesystem.) Nothing happened. Later, my mother and I would send every conceivable command to the machine (Game, Play Game, Double Dragon, DoubleDragon), trying to launch the game. We failed to move past the blinking cursor. In fact, in order to launch the game, I ultimately had to go to the library, get a book on DOS, learn about accessing drives – who knew I had to type A: to access the correct drive?! – and then launch the game. There was a great deal of space between my knowledge and the Double Dragon executable file.

This distance is precisely what cloud storage and systems like iOS are trying to bridge. There aren’t drives to access or disks to defrag; instead, you power on the device and touch an icon. And with a service like iCloud you simply upload documents to Apple’s (abstracted) server somewhere, a user-friendly step toward totally eliminating the file system. You open an app, and the relevant documents are there. Easy, accessible. A perfect setup for those new to computing or those looking for a simplified experience.

And yet I can’t help but connect this shift to the lack of filesystem familiarity I often see in my web design courses. Early in the semester, I spend some time on the file tree, on FTP, on getting a piece of data from here to there. My students struggle with this, and I understand why: For them, files consist of the contents of their Documents folder and/or iTunes. The rest of the system is beyond the demands of their day-to-day work.

To be clear: I don’t think that most of the general computing population needs to work with the command line or file tree on a regular basis. Part of the beauty of Apple’s OS X comes from the elegant layer on top of the Unix core beneath it. While there’s a complex system working beneath the GUI, it’s not of necessary importance to the end user. But it’s there: For access, for experimentation, for the work that needs it. iCloud, however, removes much of the user’s access to the file system. Other cloud storage systems are similar: I’m often frustrated with the lack of hierarchy or organization structures in Google Documents–the service is just a list of files. And implicit within that list is an argument that benefits the cloud provider: You don’t need a folder structure, it seems to say, or any of those old metaphors. You just need the files, and here they are.

Within the promise of simplicity, however, there is also a shift: Of incredible amounts of storage, of physical constraints abstracted, and of our files moving into centralized (and commercial) storage spaces. The question I’m working through, and which I think we need to carefully consider at this moment, regards the balance between simplicity and access–between innovation and constraints. If the development of contemporary computing and digital networks came from a tradition of openness (If you learn the structures and languages, you too can build something), what happens when we sacrifice that tradition for a seeming promise of simplicity?

« Streaming Music and Metadata: Missed Opportunities Amateurs and Professionals »

Comments