
Technological Literacy #
In the age of technology, knowing how to set up and configure your computer’s operating system (OS) is a bit like having super powers. Sounds cool — until you realize that those powers cannot be bought. Instead, they have to be earned. Ideally, we’d get some help along the way. However, formal education appears to be stuck in the past, leading those of us with a basic understanding of tech to believe that computers are some voodoo-like magic requiring you to be an expert spell-caster also known as a programmer. Or a math wizard ruling the domain of logic. So a desire to steer clear of these intimidating mystery boxes seems quite understandable.
Before throwing in the towel, however, I want to invite you to take a look at the following definition:
Technological literacy is the ability to use, manage, understand, and assess technology. Technological literacy is related to digital literacy in that when an individual is proficient in using computers and other digital devices to access the Internet, digital literacy gives them the ability to use the Internet to discover, review, evaluate, create, and use information via various digital platforms, such as web browsers, databases, online journals, magazines, newspapers, blogs, and social media sites.
I love spending time in nature. As a matter of fact, I go for a walk almost every day. To me, technology and nature are not mutually exclusive as it often seems to be portrayed in human thinking. The same way you probably wouldn’t spend your time in a library looking at all those books, thinking about how sad it is that so many trees were cut down to create these containers filled with knowledge and creativity. Excessively exploiting nature is what’s at odds with it. Producing more for the sake of profit with a complete disregard for what’s already been achieved.
So when I think about technology and its evolution, I don’t think about the things that are at odds with what we often romanticize as nature. Rather, I think about infrastructure, hubs, and opportunities to nurture the mind — leading to ideas that will help bring about that romanticized view of nature. This is where I see technological literacy as incredibly valuable. It can be advantageous not only in competitive economic landscapes, but also on a personal level where it can facilitate our learning, leading to a more nuanced understanding of the realities we live in. And the latter is what matters to me.
Of course, in these times it doesn’t seem uncommon to be introduced to computers within the context of unpleasant or boring work. The good news: it doesn’t have to be like that. Boredom and unpleasantness don’t have to go hand in hand with everything we can accomplish with technology. In fact, developing your own understanding for how to interact with a computer (or with any future technology for that matter) has the potential to make your life extremely convenient and relaxing. The bad news: convenience is only worth something if we work to obtain it ourselves.
So to start, I want to frame the interaction with the computer in a different light than the old-fashioned approaches learn how to code and get good at mathematics. In a nutshell: if you got introduced to a computer at school or at work, we’ll have to recalibrate your understanding towards a different purpose: a playground for fun and creativity with access to a well of infinite knowledge and some wisdom to be savored. Because, in my view, the computer is a vessel for all the building blocks necessary to imbue us with the power of autonomy. “But what kind?”, you might want to ask. After all, wouldn’t a reliance on technology simply make us dependent in some other form? This is where a bit of nuance is required.
Essentially, when I think about autonomy, I mean a kind of freedom from other people while having everything at our disposal to reach our objectives without any compromise. Here, technology allows me to navigate what I perceive as my reality with greater precision and accuracy. On top of that, it helps me to uncover things that were previously imperceptible. In a way, this isn’t unlike using a microscope to gain access to an otherwise hidden world.
Something’s Brewing #
Consider the following illustration:
Bridging the Gap

(Illustration: gibru / Licensed under: CC-BY-SA 4.0)
That, dear reader, is what I’d describe as a visual metaphor. There’s a lot going on, starting with the person underneath the brain tree. Or as I like to call her: our inventor. She has just created something new. Her current knowledge regarding that something is thus extremely high. It started its life as a fragment of inspiration, slowly matured into an idea and, finally, blossomed into a conceptual blueprint leading to something. In other words, her current ability to express what it is can be summarized as low. That’s why she’s all isolated, by the way.
You see, exploring new paths and discovering previously unseen, unheard, or not experienced stuff can lead down a very lonely path. At first, at least. Slowly, our inventor must build the rudimentary language to make her something new a little more tangible. Of course, the more complex the something, the more demanding the expressive work. As a result, very few people will have conceptual access to her creation.
Our inventor is not as alone as it seems, though. Someone has been following her adventure from afar and is very curious about that something new: the bridge builder. His current knowledge, however, is extremely low. Obviously! He’s presented with something new after all. So he starts playing with the invention, trying to figure out how it works, what he could use it for, and if it might be useful for anyone else. Step by step he tries to make sense of the inventor’s rudimentary language, trying to use it as the foundation for his conceptual bridge to build on top of. And once he’s convinced of the potential, he can get to work. Because his ability to express himself is extremely high. He will thus create a metaphorical framework connecting something to an expressive system such as natural language and visual creations. Perhaps even sounds. Who knows? I guess whatever works, as they say.
Finally, we have the people on the mainland. There’s even you, dear reader! How you doin’? On our side, something’s brewing. As you might imagine. And we are working on bringing it over. You could even benefit from it. We just have to figure out a way to show you that it actually exists, what it’s for, and how to use it. Or to inspire you to come up with your own ideas. Of course, you’d have to do your part by being receptive and willing to learn something new. If you’re not, please move along. There isn’t much to see. Just a little something…
Building Blocks #
In order to make something new a little more tangible, we need some building blocks. After all, right now it’s just words with nothing more to offer than to serve as a placeholder. Or can you explain to me what I mean by something? My guess is that you still have no idea what this is about, right? “Get to the point!”, you shout. “My time is extremely valuable and I have so little of it.”, you remind me. I’m aware. Don’t worry. I’m here. Making an extra effort to ensure that you take at least something from these words — starting with the building blocks that can be found in three conceptual realms:
- technology: our inventor’s workspace
- language: our (linguistic) bridge builder’s workspace
- illustrations: our (artistic) bridge builder’s workspace
Extracting and connecting the building blocks obtained in these three conceptual realms should be enough to work towards something a little more tangible. You have to know, however, that the building process is more important to me than the end result.
This is where we often differ as thinkers, writers, and readers. But, if you’re still reading, I presume you’ve already figured that out for yourself: my writing’s purpose isn’t to entertain or to provide an escape. It’s to challenge both you and me and to make us work. I want to explore. And that won’t be possible without an effort inside the mind — as the mind space I want to live in is the one I’m going to build myself. Can be collaborative if you feel adventurous, but I’m definitely willing to take care of the heavy lifting alone — starting with an overview of the first realm.
Technology #
Technically speaking, we’ll be working with the following main concepts as well as highlighting the reasons for doing so:
- a computer operating system
- the snapshot feature of a copy-on-write (CoW) file system
- snapshot integration into a bootloader
Linguistically speaking, this means that we will have to develop a common ground for how to think about the technical terms. In other words: I don’t assume any prior technical knowledge at this point. Instead, I suggest that we discover a possible meaning for these terms together. To that effect, I want to develop this subsection a little further.
Obsolescence #
Technology keeps evolving way faster than our language. That makes it extremely hard to keep those two in sync. So by the time we adopt a new technology into our lives and are finally ready to use it, it’s already been made obsolete by newer technology. And that leads me to an important aspect concerning this piece of writing:
How to deal with obsolescence?
Let’s start with a bit of context: the seed that would eventually lead to Change and Stability was planted years ago. It all started with a simple technical command:
btrfs subvolume snapshot / /[snapshot-location]
The meaning of this command doesn’t really matter right now. So no worries if you’re unfamiliar with it. Metaphorically, we’ll express it as follows for the time being:
Capturing Stability in a Dynamic Environment
Just think of the command as some sort of magic spell. And, as we’ll see, there are different ways to capture stability. The example above is just one approach — which leads me back to obsolescence: will this command still be useful in the future from now? Are we still going to cast magic spells in such a crude fashion? Personally, I’d argue probably not. At least not in our daily lives.
However, depending on the context we are operating in, obsolescence can be irrelevant. We could, for instance, set up a laboratory environment to study the above command under conditions isolating it from the progress brought about by time. The reason I find this to be something compelling is because practical value can be found in more than just the use of technology.
Specifically, a conceptual understanding can preserve value long after we stopped using the command to actually capture stability — especially for those who like to explore different disciplines. After all, learning how to conceptually approach a solution in one domain might be carried over to another one. Something that could be incredibly rewarding depending on whether we successfully manage to transfer our knowledge across disciplines.
Ultimately, that is why developing a conceptual understanding is essentially what Change and Stability is all about. In short: this is about converting something abstract into a perceivable solution — not about giving you (technical) instructions to be blindly followed.
In a way, we can break down the idea as follows: without being curious and knowing how to formulate the question(s), it will be tough to find appropriate answers. After all, without making ourselves properly understood, it might be rather difficult to work with someone else. Something that is bound to remain a collaborative effort. And equally importantly, iterative i.e. starting with an imperfect question and getting an imperfect answer. Refining the question to be able to refine the answer. And so on. Of course, sometimes we’re lucky and we only need one attempt. However, that shouldn’t be the expectation. It’s simply the exception to the rule. Besides, makes it easier to remain patient. Especially when you’re working alone — as our present self will always have to collaborate with our past and future selves.
Language #
Even though it might not keep up with technology, language continues to evolve as well. There are different reasons for that. For instance, it helps us to keep track of the changes that occur in the physical reality. Say, by updating existing words or creating new ones (e.g. neologisms). Once these adaptations and creations occur, we have to become aware of them. As alluded to in the intro for this section, this is unfortunately not as easy as registering the new words and we’re good to go. Otherwise, we could’ve slapped the label something on top of our inventor’s creation and be done with it already:
Here’s something! You can do anything with it. Enjoy!
Think of it this way: coining a new word (or repurposing an existing one) is akin to engineering a new conceptual device or tool for compressing mental models. The whole process could start with inspiration — maybe even with an epiphany of some sorts. The thoughts are plentiful and all scattered around. So the engineers begin to collect, arrange and, perhaps, even rearrange them. Over time, it turns into some sort of mental model with the engineers completing that process by giving it a name so that they can easily express the complexity in conversation as they all understand how that device was built.
But you and I? We have no clue what these people are talking about when they use the new word. Kind of like you currently probably don’t see where I’m going with all of this as, within this piece of writing, I’m an engineer myself — building a device of my own. That said, our mission is to reverse engineer the finished conceptual device to be able to imagine the word’s whole referent.
Compared to the engineers who were moving from a perceived problem or challenge to its imagined solution, reverse engineering their solution or conceptual device could be a tedious process. This can be explained by taking a look at the gains for each approach, starting with the engineers who are rewarded by being able to express complexity in a single word (or compound) — which, in turn, allows them to communicate more efficiently in order to further flesh out their mental model.
By contrast, for us it’s like moving from solution to problem to derive an understanding of the matter. And unless we want to contribute to the mental model in some way or another, the required effort to understand the newly coined term or conceptual device might seem a bit disproportional just to use in conversation.
That being said, asking the engineers themselves to help us understand the conceptual device i.e. the new term they’ve created (or repurposed) can often result in a frustrating experience. They simply use more words that we don’t understand to explain the one term we would like to understand. That’s because they just retrace their steps to derive the concept. But for you and me that ain’t a walk in the park. And really, how could it be? We never even had access to those engineers’ thought process! Now, we’re overwhelmed with even more stuff.
So how can we approach this communicative conundrum? With two new terms, of course! “Oh the irony!”, I know…but bear with me because this time we are building them from existing and, thus, already familiar ones: conceptual translation and conceptual engineering. The objective: conceptually engineering the term conceptual engineering. The reason: to build an interpreter or translator between us and those engineers whose jargon we don’t understand.
Let’s start by defining conceptual translation:
The practice of using an expressive system (natural language, visualizations, sounds, etc.) to solve problems related to conveying ideas, emotions, or information.
In other words, we first have to define the variables before we start to play with them. On the other hand, conceptual engineering is something that will become more apparent in the following parts of Change and Stability as it demands a more practical approach than a simple linguistic definition. Basically, we have to apply it to something tangible (e.g. technology) to get a feel for it. In the meantime and within the confines of the first part, we stay with conceptual translation, oscillating somewhere between information and knowledge.
Knowledge Flow #
The relationship between information and knowledge could be defined in terms of ingredients (e.g. for a cake) and instructions for how to combine and process those ingredients to get to the final result. As such, it is important to understand that being only in possession of the ingredients isn’t going to lead to the cake because information alone doesn’t lead to an understanding stored as knowledge and expressed as know-how.
That being said, even if we manage to develop an understanding, from an expressive point of view it might still be trapped inside of our mind. Some people call this tacit knowledge.
On top of that, this type of knowledge comes with its own nuances. Take, for example, the perspective of bilingualism i.e. speaking multiple languages. Here, we have something called a passive understanding:
A passive speaker (also referred to as a receptive bilingual or passive bilingual) is a category of speaker who has had enough exposure to a language in childhood to have a native-like comprehension of it, but has little or no active command of it.
Looking at a language as stored knowledge, it is quite fascinating that some people can store an entire language, yet they are unable to retrieve it in order to express themselves. And the same goes for knowledge in general: being (very) knowledgeable in a specific field or domain doesn’t automatically lead to an ability to express ourselves in order to communicate or transfer that knowledge onto others.
Now, in order to refine the relationship between conceptual translation, information, instructions and knowledge, let’s imagine the concept of knowledge flow in the following two ways:
Information vs. Knowledge Flow

(Illustration: gibru / Licensed under: CC-BY-SA 4.0)
We can think of the situation on the left as asking the (conceptual) engineers to pour their knowledge straight into our head. Without any instructions from the recipient i.e. the dude chilling on the lounge chair, it will mostly remain a simple transfer of information. After all, the person with the knowledge can only guess how to optimize said knowledge to actually reach the recipients knowledge receptor (a term I simply made up for explanatory purposes). This isn’t an issue per se, though. If the recipient decides to get his ass out of that lounge chair to work on processing the received information into knowledge — for instance through further research and practice fueled by self-discipline — he will still be able to actually learn and understand something.
By contrast, the people on the right side of the illustration are both involved in the learning process. The younger person first acts as a teacher and communicates instructions regarding his optimal learning process. At that stage, the older man acts as a learner by taking note of these instructions so that he can apply them to his own knowledge to figure out how to best initiate a transfer. Such a dynamic approach changes a simple information dump as depicted on the left side of the illustration into an actual knowledge transfer. The reason: the information has been processed thanks to the contribution of both parties involved.
With that in mind, your direct relationship with this piece of writing, Change and Stability, is similar to the situation depicted on the left of the illustration: these words are essentially just an information dump and, if you want to make something useful with them, you’re still expected to make an effort on your own. That said, can you guess your role as the reader in the situation depicted on the right of the illustration? Hint: you’re currently not giving any instructions.
In order to map those two people engaged in a collaborative learning effort, we need to define the perspective between writer and reader: from my point of view, the writer, I am in the process of transferring knowledge — something I’ve practiced and learned over time — into this piece of writing. That collection of words and illustrations, in turn, becomes an information dump for you, the reader. Conversely, from your perspective, the reader, I am giving you my instructions. You gain an insight into my approach to developing some sort of mental framework. If you manage to apply these instructions to your stored knowledge, you’ll be able to further refine your abilities and, if you so desire, to transfer what you’ve learned back to me, someone else, or into your own work.
However, if you fail to apply my instructions, we’re back on the left side of the illustration: by sticking with this text, you’re left to your own devices when it comes to making an effort. And finally, should you decide to get in touch with me, you’d be the one giving me your instructions and we’re back at a collaborative effort. Just something to keep in mind should you be brave enough to keep on reading.
Illustrations #
Finally, visual metaphors will serve as the glue connecting language and technology. There’s a simple reason for this: language alone can quickly get too overwhelming (it probably already is for this piece of writing) and, before we know it, we need a glossary for the dictionary that we are building. On the other hand, technology often requires layered and interconnected thinking which might be easier to express and understand visually.
Approach #
The first step is to appropriately frame the challenge ahead of us. To that end, I suggest the following two ways for how to conceptually prepare for this little project:
Playgrounds

(Illustration: gibru / Licensed under: CC-BY-SA 4.0)
This illustration simply blends a bit of tech jargon with two different contexts: scientific and artistic. At this stage, the meaning of these words in their original context — technology — doesn’t really matter. After all, anybody with no more than a very basic understanding of computers probably wouldn’t be able to make sense of terms such as bootloader or file system. Instead, we can map them to more familiar items like test tubes, flasks or a palette. This allows us to view them as components or building blocks of something larger and less intimidating than complicated sounding tech mumbo jumbo. So how about a (magic) blue potion/solution or a painting? And instead of worrying about the technical meaning of another fancy term such as operating system, we can simply approach it from the perspective of curiosity and creativity.
That said, one way to elicit how these two approaches aren’t that different from one another is to point out a common denominator: fun or play. In other words, before we get to the result — the operating system — we want to have some fun. There’s no point other than that. This is not about learning skills to get a job or to impress your peers; it is not a matter of the utmost importance; and it won’t change or save the world. It’s just some form of amusement to pass some time.
At any rate, while both of these approaches shall be grounded in fun and play, the results will have to be appreciated in a different light: on the left, once we’re done playing, the solution has to be effective. Put differently, the choice of our operating system in combination with our file system, bootloader and other components shall form a unified one, translating into a new playground to explore. A simple case of one thing leads to another.
By contrast, there’s a beauty in all of that as shown on the right side of the illustration. Taking time to appreciate that beauty will reward us on the emotional level the same way the properly mixed solution will arouse our intellectual side.
Affordability #
It is of great importance to me that anyone with an interest and the motivation to learn has access to the technology that allows them to grow and make progress. And to (conceptual) resources such as this piece. So I want to briefly single out and look at the following two aspects:
The hardware choice has to be as broad as possible because this is what is going to be the biggest expense next to access to an internet connection. Luckily, the software used for this endeavor does allow for a lot of flexibility when it comes to the hardware. Unfortunately — or perhaps fortunately —, it will be for you to decide how you want to approach that flexibility once we get to the actual software selection.
Speaking of the operating system and the rest of the needed software, things are on the bright side: it won’t cost you a dime. That’s not to say that you shouldn’t support those projects financially if you can (and for as long as such support still makes sense), but it won’t exclude you because of an empty wallet — leading to a myth that needs dispelling.
In this day and age, it isn’t uncommon to think that if something is free of charge it can’t be that good. After all, who in their right mind would put their blood and sweat — their valuable time — into any kind of challenging project without expecting anything in return? I certainly wouldn’t. However, that anything doesn’t have to be money. I know…to some people that seems unthinkable and that’s fine. But to people like me, having to think about money is primarily in the way of progress and fun. Not an enabler for it. So whenever an opportunity presents itself, we work on things because it gives us pleasure or, even better, a sense of purpose. Just like some people want to travel the world, buy tons of stuff or meditate in some temple, others enjoy studying and expressing what they’ve learned. And effort fueled by fun and play can produce incredible results — such as the software that will be at the center of discussion for this piece.
That being said, make no mistake! Some of that software used for this project is backed by a lot of money as not only individuals but also companies can and do tremendously benefit from these technologies. That makes it immediately a very complicated topic to explore and, as a result, I won’t bother. What matters more is this: with all this incredible and freely available technology scattered all over the internet, why aren’t more people benefiting from it? To be clear, I don’t really want to look for an answer here either, but I do think that — as opposed to products for purchase that are backed by armies of marketers to raise awareness and persuade us to buy and consume — the really cool and freely available stuff would need awareness backed by education because it doesn’t have a “selling point”. Remember, it’s free of charge. Yet it still comes at a huge cost: it will require a monumental learning effort. Hence, education as a key word. However, not the traditional prescriptive one used to manufacture workers with diplomas as keys that unlock their grim future in (metaphorical) cubicles. I’m referring to knowledge transmission that makes our lives more enjoyable; that makes it actually worth living. Just something to keep in mind.
Basic Terminology #
When it comes to language, pretty much everything is arbitrary. Probably makes it sound as if it were a miracle that we understand each other at all. Then again, do we really?
Consider, for a moment, people who speak multiple languages. For them, chien, cane, pies, 犬, 狗, or Hund are words to denote what we also call dog. As long as they can imagine the same thing behind different terms (or “symbols”), it just works — even with a word that’s already in use for something else like cat. Of course, it would probably require some mental rewiring to make dogs out of cats, but with enough effort it is certainly not impossible. Come to think of it, I do have a feeling that the less familiar we are with a word or concept behind it, the easier it’ll be for us to replace it with something else (but don’t quote me on that). For the time being, however, the point is this: as long as there is a group of people who agree on a common denominator, natural language within the communicative sphere can be quite moldable.
So as you might start to suspect by now, being able to play with language is actually of crucial importance to this piece: it is supposed to provide us with the necessary freedom to shape the linguistic building blocks to make things a little more accessible. In other words: we are going to form our own little speech community to reach our destination — starting by making sure that we are on the same page when it comes to the basic terminology. And in case you are interested, this is primarily inspired by what is known as grounding. I jest! It’s obviously based on common sense.
Now, here’s what’s about to unfold: we are going to start with the term operating system and look at a few different aspects that come with it. Each one of them can be considered one of several necessary steps to building a tool (or conceptual device) that will contribute to helping us reach the end of this project. And if, occasionally, it feels a bit like I’m winging it, that would be because I am. Besides, I wouldn’t be able to write a piece like this without having some fun in the process.
Lastly, don’t expect to learn another way to explain in dictionary-style what the meaning of operating system actually is — as knowing the words and sentences to describe a word can be quite different from actually discerning a concept behind it. Instead, the aim is to build a mental space with enough room to connect the bits of knowledge we collect in novel (or at least different) ways.
The Operating System (OS) #
As opposed to something completely theoretical, the cool thing with the compound operating system is that its referent actually exists outside of the linguistic or abstract realm. So in an effort to avoid going in endless terminological circles (click here to view our sponsor for this subsection), the most obvious thing to start with is probably a couple of examples of actual operating systems.
Essentially, there are different kinds of operating systems running on different types of devices. Let’s start with an overview of two currently common types:
Digital Environments for Work and Fun

(Illustration: gibru / Licensed under: CC-BY-SA 4.0)
The systems illustrated above are different examples for the same thing on two different form factors: desktop and mobile. In other words, think of the OS as an environment for digital tools that can help us accomplish a task — be it for work, fun, or whatever else we can imagine.
On mobile, we have examples such as Android, iOS and the discontinued Windows Phone. By contrast, desktop operating systems include Microsoft Windows and macOS. Of course, there is a lot more to unpack with these operating systems, but for a small overview this should do.
Linguistically speaking, there’s also room for nuance depending on the form factor. For instance, on a desktop OS we typically run software or programs, whereas on a mobile OS we use terms such as applications or apps for short. Then again, there are no fixed rules as people probably call software “apps”, apps “software”, apps “applications”, programs “applications” — or my personal favorite: stuff that runs on the thing. Not to mention that, considering the current technological progress, we’ll likely end up with more anthropomorphic metaphors. In short: as long as we have established a common denominator for our terminology, that’s fine. What matters here is that it’s enough to think of these words as different terms for similar things. After all, at this stage it’s all about awareness. Nothing more.
Speaking of awareness, there’s a third desktop operating system family that requires its own illustration, namely Linux:
A Selection of Linux Desktop Environments

(Illustration: gibru / Licensed under: CC-BY-SA 4.0)
Technically, Linux runs on a lot of form factors. In fact, way more than the desktop one shown in the illustration above.
For starters, the Linux kernel is also part of the Android mobile operating system shown earlier on. And by the way, people in my circles sometimes tend to call Android a “Samsung”:
Me:
Does your phone run Android or iOS?
Other person:
What do you mean? I have a Samsung.
Of course, I don’t mention that to make fun of them. It’s just in case you were wondering why I wanted to write a piece on technological literacy.
Next, let’s zoom in on the illustration with the penguin and take a closer look at the second example that says KDE Plasma. In combination with a distribution called Arch Linux, we have my main operating system. The one I use as my desktop OS. Incidentally, at the time of writing that is a combination also powering a handheld gaming device known as Steam Deck. The Deck’s form factor is very different, but to me it doesn’t really matter whether I use Linux on my desktop PC, a laptop, a Steam Deck, a server, a router and so on.
Linguistically, the situation is quite intriguing as well! So I guess it’s time to inject some more nuance into the discussion. Specifically, let’s consider the desktop metaphor. With desktop operating systems such as Windows or macOS, there’s one desktop environment that we’ll (hopefully) find ourselves in after successfully booting the OS. The place where we find start menus, task bars, docks and so on. Except for adventurous tinkerers, it is common to be aware of one such environment. In other words, it is enough to linguistically codify that graphical user interface (GUI) as the desktop. With Linux, however, there’s a choice of different desktops i.e. it helps to be aware of environments.
This leads us back to our Playgrounds situation. People who don’t appreciate technology from either of those two perspectives don’t like choice. We know that because they are very vocal about it. That’s fine. For the rest of us, this is where the fun already begins: with a ritual also known as distro hopping — referring to constantly switching Linux distributions in an effort to try, learn and, ultimately, find the one system with an optimal combination of components such as the aforementioned desktop environment. And perfectly tailored to our personal preferences.
Finally, another example in the illustration above is the first one without a desktop. As opposed to a graphical user interface (GUI) such as the desktop, it simply features a command-line interface (CLI) — considerably changing our ways to interact with a computer.
Interacting with an OS #
The distinction between the GUI and the CLI can be summarized as follows:
While it isn’t uncommon for some of us to be intimidated by the CLI, at its core we simply have a different approach to interacting with a computer than the point & click approach we’re all familiar with. Of course, as screens have become tactile, gestures as a way of interacting with an OS are more ubiquitous as well. And this will keep evolving into a plethora of different ways to engage with our technology, such as voice and probably more sci-fi resembling approaches that we won’t be exploring here.
Within the context of Change and Stability, GUI and CLI is where we stay — keeping in mind that these different types of interaction are not meant to replace but to complement one another. To give you a better idea for what I mean by that, consider the following illustration:
Different Interaction Layers

(Illustration: gibru / Licensed under: CC-BY-SA 4.0)
Starting on the left, imagine the CLI being a layer below the GUI layer. On Linux, we can choose to install a desktop environment or not. So the first layer without a desktop environment simply presents us with a prompt: a username and a hostname followed by a symbol indicating the type of user: $
for regular users or #
for root or admin users with elevated privileges.
That being said, just because there’s nowhere to click doesn’t mean there’s nowhere to navigate. In fact, using the CLI, we can interact with an operating system just like we would when using a desktop environment. In the example from the illustration, we open the Downloads folder with the cd
(short for change directory) command. By contrast, the GUI element hovering in front of the monitor is a standard file manager of a desktop environment presenting us with the possibility to click on the Downloads folder to open it.
Both ways of interacting with an OS are absolutely fine, but the CLI approach is arguably the more flexible one. There are a few reasons for that, but I’ll give you a simple example. Imagine you want to create a folder called Photos and inside that folder you create twelve folders (January, February, March, etc.). Assuming you’re not familiar with keyboard shortcuts, on a desktop environment you would have to right-click and choose Create new folder from the context menu. Then, you give it a name (e.g. Photos) and navigate to the newly created folder. Next, you’d repeat that process twelve times to create the remaining folders. By contrast, using the CLI you can simply execute the following command (starting with mkdir
which is short for make directory):
[username@hostname ~]$ mkdir -p Photos/{January,February,March...}
Of course, the point isn’t to try and convince you to learn the command-line interface, but to give you a bit of an idea behind this kind of digital spellcasting. Besides, both CLI and GUI will be complemented (and eventually superseded) by other forms of interaction.
So, at the end of the day, the CLI is just another method for interacting with a computer, but instead of tickling the OS with a mouse cursor we communicate in text. These text commands are often times a combination of a natural language i.e. English with a particular syntax (or word order) and logical operators. That latter aspect can make it somewhat daunting for most of us, but you’d be surprised by the amount of creativity that goes into technology as well as into interacting with it. In other words, there are plenty of cool things to do even for those of us who aren’t considered to be the nerd in the family.
Finally, let’s move on to the ones and zeros connecting the GUI element in the illustration to the central processing unit (CPU). That would be the computer’s native language a.k.a. binary code. More specifically, stringing these two digits together in a particular order is to a computer what English (or whatever other languages you’re familiar with) is to a human. As such, the GUI and CLI are simply layers of abstraction that allow us to communicate or give instructions to a computer without having to encode everything into two measly symbols: zero and one. I mean, imagine having only two letters of the entire alphabet available to express yourself. Personally, I truly appreciate a wide range of symbols, gestures, and sounds at our disposal to express ourselves. YMMV.
Housing an OS #
Many years ago, I had a conversation at work with a person who wasn’t particularly familiar with technology. It was one of those Mondays and so the coffee break had to be extended. At the center of our verbal exchange was my weekend project: assembling my own computer. As it turned out, my discussion partner seemed to have followed along rather well. Basically, her level of awareness was sufficient to point out that I had forgotten the OS in my explanation — or in her words:
But without Windows, what happens when you power on the computer?
Of particular interest here is the use of the word Windows instead of operating system as the person in question didn’t have any notion of the concept itself. Instead, the idea was expressed with a particular product: MS Windows. And this, dear reader, is why you want to get your product into people’s hands before they can make sense of their reality. In other words, you’ll find your ideal clients in Kindergarten — or, at the very latest, in elementary school.
Joking aside, considering the illustrations in the OS section, we now know that I could’ve used at least two other desktop operating systems if not more. And this is where being aware of the concept itself is essential as it allowed me to make sense of the person’s question even though she guessed the wrong OS. As a matter of fact, I did answer using the term Windows despite not actually using that system. After all, this was our coffee break and not a class requiring linguistic and technical accuracy. Otherwise, I would have gladly given her a glimpse into the wonderful world of Linux and other such technologies.
With that in mind, I do think her question was very pertinent because it isn’t uncommon to get our computers, tablets, or phones preloaded with an OS — including a lot of additional stuff that we don’t necessarily want (let alone need). So the basic assumption is that the OS is just magically “there”.
Sometimes, however, we might want a computer that doesn’t come with an OS preinstalled. Or we intend to reinstall or replace the existing one. For such cases, it makes sense to have a bit of an idea about its physical location:
Housing the OS

(Illustration: gibru / Licensed under: CC-BY-SA 4.0)
This illustration serves an important purpose: I wanted to have a basic visual representation to expand upon for upcoming illustrations. The Linux mascot is supposed to be a stand-in for the actual OS. Correct! At this stage, I want you to think of an incredibly complex system as a penguin. Basically, it’s my take on Where’s Wally/Waldo, but this time we’re looking for Tux.
Placing Tux on different types of storage devices is meant to give you a sense of the operating system’s physical location. Depending on the device (PC, phone, router, SBC, and so on), the storage device can take different forms. Here are just a few examples:
- a hard disk drive (HDD) (e.g PC/laptop)
- a solid-state drive (SDD) (e.g. PC/laptop)
- an SD Card (e.g. SBC)
- a USB flash drive (e.g. live media)
As for how to get Tux (or the OS) on these storage devices, we need a copy of the operating system itself. These OS installers can be downloaded from the official OS websites. They are typically written to a USB flash drive, connected to our computer (as pictured above on the right with more context) and, finally, installed on our computers internal storage. There are exceptions to this process such as with SBCs like the Raspberry Pi where the OS can be written to a MicroSD card instead and used directly as the Pi’s storage device.
So going back to my former co-worker’s question, when building the PC ourselves, we have to start by installing the OS on our computer’s (internal) storage device. One specific way for going about that little endeavor will be discussed further down the road. For now, I thought it could be useful to have a bit of an idea regarding what to put in front of our mind’s eye during an encounter with the term storage device in relation to operating system.
Puzzling Metaphor #
With our Linux mascot Tux now being a stand-in for the operating system, we have entered the realm of the metaphor. This opens up new (or at least different) ways to think about tech jargon. However, there’s no reason to restrict ourselves to one single metaphor. Besides, that penguin alone won’t be enough to develop a more nuanced approach. In other words, time to take a closer look under the figurative hood of the OS itself:
Putting an OS under the Microscope

(Illustration: gibru / Licensed under: CC-BY-SA 4.0)
Let’s focus on the system part of operating system for a moment. Here’s a possible definition to work with:
A group or set of related things that operate together as a complex whole.
Essentially, the puzzle pieces represent a few example components that are part of the operating system i.e. “a complex whole”. Of course, in actuality there are many more pieces, but quantity isn’t what we are aiming for here. It just has to be enough to make some sense. And once it does, you’ll decide for yourself how far you want to go down that rabbit (w)hole.
Now, while understanding the labels on the puzzle pieces isn’t really that crucial for our purposes (feel free to look them up, though), something is still worth pointing out.
Conceptually, it makes sense to separate two different types of components:
- important pieces, providing essential functionality for the OS to boot up and operate at a basic level (e.g. Linux kernel, file system, etc.)
- optional pieces, adding features on top of the basic level and enhancing the overall user experience, but not required for the OS to function at all (e.g. desktop environment, music player, etc.)
In short, if you uninstall a piece providing essential functionality such as the Linux kernel, your computer won’t boot anymore. By contrast, uninstalling an optional piece such as the music player won’t stop your OS from booting up.
The next thing on the agenda is to take an even closer look at one of those puzzle pieces to further develop the visual metaphor:
A Closer Look at an OS Component

(Illustration: gibru / Licensed under: CC-BY-SA 4.0)
Here, the idea is to imagine a program or an individual software piece as a written document — not unlike your standard tax declaration or your essay for school (my apologies for such a lame example, but I am sure you can relate to either one of them or both if you’re old enough).
On top of that, we have to point out the importance of perspective: the written document contains the variables and instructions for a Calculator program (or app). These variables and instructions are written in human-readable language (the example in the illustration is the Python programming language). By contrast, the computer understands machine-readable language such as the already mentioned binary code, represented as strings of ones and zeros1.
That said, while the machine-readable example is simply there for contrastive purposes, thinking about a piece of software as a recipe with variables (i.e. ingredients) and instructions that we humans can (learn to) understand, allows us to express changes made to a single puzzle piece the same way those pieces allow us to express changes to the operating system. For example, just as we can think of OS software installation and removal as adding or removing another puzzle piece, we can now look at changes to the software itself (i.e. updates and downgrades) as editing text: sometimes we want to correct a spelling mistake, sometimes we want to get rid of syntactic ambiguity, make the text more concise, or simply improve the style.
Finally, this leads us to the following question: what are we supposed to do with these metaphors?
-
Bear in mind that the actual situation is way more nuanced (e.g., high-level vs. low-level languages like Python vs. C++, or compiled vs. interpreted languages like Java vs. Python), but within the context of Change and Stability, these nuances are not relevant. ↩︎