When cars were first invented, I have to believe that people thought about a car in terms of its parts: the engine; oil and its purpose; the gas tank; the starter; etc. (I don't know much about cars.) But as cars became more commonplace, they started to exist as an atomic "car." You can know you have a car, and how to unlock and start it, but not know any of the components or how the car works.

I came to this conclusion about cars reflecting on my observations about computers. I grew up building computers with friends, and understand how the motherboard, hard drive, disk drives, and peripherals were physically connected. I understand the idea of a BIOS and what a BIOS password is. However, for many people who grew up with, say, pre-built laptops, the computer is an atomic system and they do not understand (or need to understand) the computer's components.

The same is true of computer networking. If you have never needed to wire a 10base2 or an RJ45 network together, I'd imagine it is harder to picture what's going on when your computer connects to "the Internet" or how the particular wireless device you're connecting to is different from the Internet as a whole. The Internet becomes an entity unto itself.

I had thought that people born after me would know even more than me about computers: that their knowledge would build on top of the knowledge my generation had gained. Instead, from my observations people can take the component layer for granted as they engage with technology as an organic system instead of a series of components.

I got into computers pretty early in life and have been able to hang with people from previous generations in talking about computing from the mid-1980s onward. However, I'm starting to notice that the computer knowledge I've taken for granted is starting to become more rare–kind of like people who understand COBOL. As examples, I feel like I'm finding fewer people who have experience with:

  • inetd or the low, odd-numbered ports in /etc/services
  • lpd
  • Apache httpd
  • BASIC, Pascal
  • building applications from source, up to and including Makefiles
  • MacOS 6/7
  • Perl (at least for substantive programs)
  • RCS/CVS/Subversion
  • Solaris 2.5, or for that matter any UNIX system that is not Linux- or Free/Net/OpenBSD-based
  • Zope

I know many people still know these technologies; I just am realizing that people getting into IT now have few reasons to learn the above. And to an extent, these tool examples help highlight the "DIKW" model:

  1. Data, which can be filtered into
  2. Information, which can be filtered into
  3. Knowledge, which can be filtered into
  4. Wisdom

It's easy for people new to these tools to gather data and information through man pages and Google searches, but it will be much harder for people to gain knowledge (e.g. lpd has a code for "printer on fire") or especially wisdom (e.g. lpd on Linux may consult its own magic file and guess wrong for small files, resulting in garbled printing).

In Seattle we're lucky to have the Living Computers: Museum + Labs, which has on its top floor a working server room, Ataris, a SunOS machine, and other historical equipment. You can even log into many of the mainframes.

I'm thinking about knowledge of these tools going away in the context of digital preservation. Tools and formats grow and change. I have been responsible for several tool conversions in my career, to try and keep content accessible despite a tool being deprecated. Org-mode's philosophy is that everything's a text file, so you can still read it even if org-mode goes away.

And I'm also thinking about these tools in a sentimental way, probably very much like how a classic car collector reflects on how engines used to work. Tools like Zope, for example, were built before Apache httpd, and we can learn what assumptions we may hold by seeing what Zope did not take for granted.