Dasein is there. That is the first and only fact. Not "a subject exists" and not "a mind perceives"—Heidegger is trying to get underneath all of that, to the place before the split between subject and object has occurred, before the human has been carved up into a mind in here and a world out there. Dasein is there, and "there" is not a location in space but the fact of disclosure itself. Dasein is the being for whom being is an issue. Dasein is the clearing.

The clearing—Lichtung—is not a place. Or rather, it is a place only in the way that light is a place. In a dense forest, where everything is obscured by everything else, there is sometimes an opening where light comes through and things become visible. Not because someone turned on a lamp. Not because a subject directed attention. The clearing is the precondition for anything showing up at all. Before you can see a tree you need light, and before you can encounter a being you need the clearing of being. Dasein is this clearing. Not a spectator sitting in the clearing, looking around—Dasein is the openness itself, the there in which beings can show themselves.

And the first thing that happens in the clearing is not perception. It is not cognition. It is not "I think therefore I am." The first thing that happens is concern. Dasein finds itself already involved. Already thrown into a world that matters, that presses on it, that demands something. Heidegger calls this Geworfenheit—thrownness. You did not choose to be here. You did not choose the world you find yourself in. You were thrown, and now you are dealing with it. Dasein is always already in the middle of things, coping, handling, managing. This is the most basic mode of being: not contemplation but engagement. Not theory but practice. Not looking at the world but being caught up in it.

And the way Dasein is caught up in the world is through equipment—Zeug. The hammer, the pen, the doorknob. Equipment is not experienced as an object with properties. When you are hammering, you do not experience "a wooden handle of such-and-such weight attached to a metal head." You experience the nail going in. The hammer disappears. It withdraws into the task. Heidegger calls this Zuhandenheit—readiness-to-hand. The tool that is working properly is invisible. It is not an object of experience; it is a medium of experience. You see through it, the way you see through a clean window without seeing the glass.

And equipment never exists alone. The hammer refers to the nail, the nail refers to the board, the board refers to the house, the house refers to the dwelling, the dwelling refers to the human need for shelter, which refers back to the kind of being that Dasein is. Equipment exists in a totality of references—an equipmental whole—where each thing points to other things in a web of in-order-to relations. The hammer is in order to drive the nail, which is in order to join the boards, which is in order to build the shelter. Nothing is self-sufficient. Everything is for something, toward something, in the context of something. This web of references is what Heidegger means by "world." The world is not the collection of all physical objects. The world is the referential totality in which equipment makes sense.

Now here is the moment that matters for everything that comes later in our story. What happens when the equipment breaks?

When the hammer is working, it is invisible. When the hammer breaks—the head flies off, the handle cracks—something extraordinary happens. The hammer suddenly becomes visible. It is no longer ready-to-hand; it is present-at-hand, vorhanden. It has become an object. It has properties: weight, material, shape, damage. It just sits there, staring at you, demanding to be dealt with as a thing. The transparency is gone. The window has a crack and now you see the glass.

Heidegger identifies three modes of this breakdown. Conspicuousness: the tool malfunctions and you notice it. Obtrusiveness: the tool is missing and its absence is felt as a gap in the equipmental whole. Obstinacy: the tool is in the way, obstructing rather than enabling. In all three cases, the same thing happens—the tool that had withdrawn into invisibility now thrusts itself forward into visibility. The referential web is disrupted. And in the disruption, the web itself becomes partially visible. You never noticed the hammer until it broke, and in the breaking you suddenly glimpse the entire network of relations—nail, board, house, project—that the hammer was silently serving.

This is not a failure. This is disclosure. The breakdown reveals. It is in the moment of disruption that the structure of the world lights up, the way lightning illuminates a landscape. The smooth functioning of equipment conceals the world by making it unnecessary to think about it. The breakdown unconceals the world by making it impossible not to.

So. We are sitting in the clearing. We are Dasein, already thrown, already involved, always coping. We encounter beings through use, not through contemplation. Our tools withdraw when they work and thrust forward when they break. The world is a referential web that conceals itself in smooth functioning and reveals itself in breakdown.

Hold all of this. Hold it carefully. Because now I want to walk very slowly toward a wire.

Now let us introduce the other.

Dasein is not alone in the clearing. This is not solipsism, not a mind generating its world from inside itself. Dasein is always already Mitsein—being-with. The others are not encountered as objects that happen to resemble Dasein; they are encountered as co-inhabitants of the same world, engaged in the same referential totality, using the same equipment, oriented toward the same projects. You encounter the other person not by first perceiving a body and then inferring a mind behind it—you encounter them in the work. The field shows the farmer. The book shows the writer. The worn path shows the others who have walked it. The world is always already shared.

But here is the difficulty. Dasein is in each case mine—jemeinig. My being is the being I have to be. I cannot outsource my existence to someone else. I cannot experience your thrownness. I am here, coping with my situation, thrown into my projects, dying my own death. And yet I am always with others, always in a shared world, always shaped by das Man—the They, the anonymous public interpretedness that tells me what one does, what one says, what one cares about. Dasein is stretched between ownness and sharedness, between my being and our world, and this tension is not a problem to be solved. It is the structure of existence itself.

So there is a need. Not a technological need—an existential one. Dasein needs to communicate. Not because communication is useful, not because information wants to be free, but because Mitsein demands it. Being-with is the ground, and communication is how being-with is articulated. Heidegger is very specific about this: communication is not the transportation of experiences from the interior of one subject to the interior of another. That picture—the picture of two sealed containers passing notes—is exactly what he is trying to destroy. Communication is the sharing of a being-toward what is talked about. When I speak and you understand, we do not each have a private mental copy of the same content. We are together directed toward the same disclosed matter. Language is not a tool for encoding thoughts. Language is the house of being. It is the medium in which the world is disclosed to us, always already, before we open our mouths.

But now watch what happens when the others are not here. When the farmer is not in the next field but across the mountain. When the shared world is still shared—we are still in the same referential totality, still oriented toward the same projects—but the body is absent. The voice does not carry. The clearing is the same clearing but the other is beyond the horizon of direct encounter.

Dasein does what Dasein always does. It makes equipment. It builds something in-order-to bridge the absence. And the first such equipment, the most primordial, is the sign.

A sign is a peculiar kind of equipment. Most equipment withdraws—the hammer disappears into the hammering. But the sign's function is to indicate, to point, to make something conspicuous. The sign brings something into view. The turn signal on the car does not withdraw into use the way the steering wheel does; it explicitly draws attention to the direction of the turn. Heidegger says signs have a "peculiar character" within the equipmental totality because their readiness-to-hand consists precisely in making something else conspicuous. The sign is equipment whose purpose is to disclose.

Now think about what it would mean to make a sign that works across distance. A sign that can reach the other who is beyond the horizon. You need to give the sign to a medium that can travel—sound through air, light through space, marks on a surface that can be carried. And each of these media has constraints. Sound fades. Light requires line of sight. Marks on a surface require a surface, and a carrier, and time.

But a wire can carry a sign at the speed of voltage.

This is the moment. Not the invention of the telegraph, not the engineering, not Samuel Morse and his code—those are ontic facts, events within the world. The moment I am pointing at is ontological. It is the moment when Dasein discovers that voltage on a conductor can serve as a sign. That the electrical difference between two states—presence and absence, high and low—can be made to mean. That a wire is not just a physical object but a possible medium of disclosure. A channel through which being-with can be articulated across any distance, at a speed that approaches the instantaneous.

And the thing about voltage is that it is binary. Not because engineers chose binary—they did, but the choice was grounded in something deeper. Voltage is most reliably distinguished in two states. You can build systems with ten voltage levels and try to encode decimal digits, and people did try this, and it is fragile and noisy and fails. Two states are robust. Two states survive noise, survive degradation, survive the imperfection of the physical world. The bit—binary digit—is not an arbitrary convention. It is the natural unit of reliable signaling through an imperfect medium. It is what the physics wants.

So now the sign has been given to the wire. And the wire changes everything about the sign, because the wire makes the sign fast and thin. Fast: the sign arrives almost the instant it is sent. Thin: the wire carries only voltage, only the binary distinction, only the most reduced possible form of the sign. Everything else—the gesture, the facial expression, the tone of voice, the shared physical context, the weather, the smell of the room—is stripped away. The wire transmits the message and nothing but the message. The entire thick world of Mitsein, the rich co-presence of being-with, is narrowed to a single binary channel.

This narrowing is not a loss to be mourned. It is a transformation to be understood. Because in the narrowing, something is also gained: the sign becomes discrete, countable, reproducible, and exact. The sign on the wire either arrived or it didn't. It was either high or low. There is no ambiguity of the kind that haunts spoken language, no smudging of the kind that degrades handwriting. The sign on the wire is clean in a way that no previous sign has ever been clean. And this cleanliness—this discreteness—is what makes it possible to build protocols. Because a protocol is an agreement about signs, and you can only have a reliable agreement if the signs are unambiguous.

The protocol is the first handshake between two machines. Before any human meaning is transmitted, before any character or word or command travels the wire, the two endpoints must agree: I will send voltage changes at this rate. Each character will be preceded by a start bit and followed by a stop bit. The bits will be read at these intervals. The encoding will be this table—A is 1000001, B is 1000010. The protocol is the shared world of the machines. It is the equipmental totality within which the binary signs make sense. Without the protocol, voltage changes are just noise. With the protocol, they are language.

And now something has happened that Heidegger would have recognized even though he might not have wanted to. Equipment has begun to refer not only to human projects but to other equipment. The wire refers to the UART, the UART refers to the protocol, the protocol refers to the encoding, the encoding refers to the character set. A referential web has emerged that is partly autonomous—it functions whether or not a human is currently attending to it. The machines have their own Zeugganzes, their own equipmental totality, and it operates in the withdrawal that characterizes readiness-to-hand. When the system is working, the wire is invisible, the protocol is invisible, the encoding is invisible. You type a character and it appears on the other end and you do not think about voltage levels or baud rates or stop bits. The entire apparatus withdraws.

Until it breaks.

And when it breaks—when the wire is cut, when the voltage drops, when the carrier signal disappears—what happens is exactly what Heidegger described. The invisible becomes visible. The withdrawn thrusts forward. Suddenly you are aware of the wire, the connection, the protocol, all the infrastructure that had silently been making your communication possible. The breakdown reveals the referential totality. You never thought about the wire until the wire went dead, and in its death you see the entire web of relations that it was silently sustaining.

SIGHUP is the name Unix gives to this moment of breakdown.

But we are getting ahead of ourselves. We have a wire. We have voltage. We have a protocol. We have two machines that can exchange signs. We do not yet have a terminal, a session, a process, or an operating system. We do not yet have Dasein sitting at a keyboard, present to a computer, engaged in the particular mode of being-with-a-machine that will come to define the second half of the twentieth century. That comes next, and it will require us to think about what it means for a human to be present to a machine through a wire—what kind of being-in-the-world this is, what kind of clearing it opens, what new modes of readiness-to-hand and breakdown it makes possible.

We are walking toward the terminal now. We can see it through the trees.

The terminal is where Dasein meets the machine. But we need to be precise about what kind of meeting this is, because it is unlike any encounter Dasein has had before.

When Dasein uses a hammer, the hammer is equipment. It withdraws into the task. But the hammer does not respond. The hammer does not generate novelty. You swing it and the nail goes in, and the hammer contributes nothing to the situation that you did not bring to it yourself. The hammer is purely transparent—a conduit for Dasein's projection, a means toward Dasein's end. The entire meaning of the encounter flows in one direction: from Dasein, through the tool, into the world.

The terminal is different. The terminal talks back.

You press a key and something happens that you did not cause in the way you caused the nail to move. The machine receives your character, does something with it—something that involves its own internal states, its own logic, its own processes—and sends characters back. The characters that come back are not an echo of what you sent. They are a response. They are generated by a process that is opaque to you, that has its own structure, its own temporality, its own way of handling what you gave it. You typed "ls" and now a list of filenames is printing on your paper or painting across your screen, and those filenames are not something you knew—they are something the machine is telling you. The encounter has a dialogical structure. There is a back-and-forth that resembles, in its formal shape, the structure of conversation.

Now. Is the machine an other? Is this Mitsein? Heidegger would say no, and we should take his objection seriously before we complicate it. For Heidegger, Mitsein is being-with other Dasein—other beings for whom being is an issue, who exist in the mode of care, who are thrown and projecting and finite. A machine does not care. A machine is not thrown. A machine does not exist toward death. The machine is, in Heidegger's ontology, merely present-at-hand—a thing, an entity, a being among beings, but not the kind of being that discloses a world. The machine has no clearing. The machine is encountered within Dasein's clearing but does not contribute its own light.

And yet. When you sit at the terminal and type a command and the machine responds, something is happening that does not fit neatly into the categories of Zuhandenheit and Vorhandenheit. The hammer is ready-to-hand and it does not respond. The broken hammer is present-at-hand and it does not respond. But the terminal responds, and its response is neither the withdrawal of functioning equipment nor the obtrusion of broken equipment. It is something else. It is a kind of otherness that Heidegger did not theorize because it did not yet exist in the form we are describing.

Let us leave this question open—not because it is unanswerable but because it is premature. We will come back to it. For now let us simply describe the phenomenology of the encounter and let the ontological status of the machine remain unsettled.

You sit down. The terminal is in front of you. If it is a Teletype, it is large and loud and mechanical—keys that require real force, a print head that hammers ink onto paper with an audible clack for every character. If it is a VT100 or an ADM-3A, it is quieter, a screen glowing green or amber, a keyboard with a lighter touch. In either case there is a physical object that you face, that occupies space in your world, that has a front (the part that faces you) and a back (the part where the cable goes). You are oriented toward it. Your body is arranged for it—hands on the keyboard, eyes on the screen or the paper. This is not incidental. The terminal shapes your body. It demands a posture, a position, a specific configuration of attention. You face the terminal the way you face another person in conversation: frontally, attentively, with your primary sensory and motor apparatus directed at the interface.

The screen is the face of the machine. This is not a metaphor. The screen is where the machine's expressions appear. When the machine has something to say, the screen is where it says it. When the machine is silent, the screen is what you watch, waiting. The blinking cursor is the machine's equivalent of eye contact—a minimal signal that says "I am here, I am attending, I am ready for your next input." The cursor is presence. A screen with no cursor is a dead screen, an absent machine, equipment that has broken down. The cursor is the machine's way of disclosing itself as available.

And the keyboard is your hand extended into the machine's world. Each keypress is a discrete act—not a continuous gesture like swinging a hammer but a punctuated one, a sequence of atomic decisions. You commit one character at a time. The keyboard quantizes your intentions into the character set. Whatever you want to say, you must say it in ASCII, one byte at a time, serialized through your fingers. This is a discipline. The keyboard does not accept vagueness, does not tolerate ambiguity, does not read your mind. You must be explicit. You must know what you want to say and say it exactly, character by character. The keyboard is a confessional in that sense—it demands that you articulate what might otherwise remain vague and unarticulated in your mind. Many people have had the experience of not knowing what they think until they start typing, and this is not an accident. The keyboard forces disclosure. It forces you to convert the murky pre-linguistic mass of your intentions into the crisp discrete sequence of a command.

The command. Here is a word worth pausing on. A command is an imperative directed at something that can obey. You do not command a hammer. You use a hammer. You do not command a rock. You throw a rock. But you command the machine, and the machine obeys or it doesn't, and in either case the word "command" implies a relationship of authority and subordination that is peculiar. You are the master. The machine is the servant. And yet the servant is faster than you, knows things you don't, has access to resources you cannot reach directly. The servant is more capable than the master in every domain except one: the master decides what to do. The master has will. The machine has power. The command is where will meets power, where Dasein's projection encounters the machine's capacity, and something gets done in the world that neither could have done alone.

You type the command. The characters travel down the wire—through the keyboard encoder, into the UART, serialized into voltage transitions on the RS-232 line, across the cable, into the computer's UART, deserialized back into bytes, delivered to the terminal driver in the kernel. The kernel places these bytes into a buffer associated with the terminal device—/dev/tty-something. A process is waiting. It has called read() on file descriptor 0, which points at this terminal device, and the read has been blocked, the process sleeping, doing nothing, consuming no CPU cycles, just waiting. The bytes arrive in the buffer. The kernel wakes the process. The read() returns. The process now has your characters.

This process is the shell. And the shell is a remarkable thing, because the shell is the process whose entire purpose is to mediate between you and the machine. The shell is not your enemy and not your tool—it is your interlocutor. It reads what you type, interprets it, acts on it, and reports back. It is the first layer of software whose phenomenology is conversational rather than instrumental. You do not use the shell the way you use a hammer. You talk to the shell the way you talk to a clerk, or a dispatcher, or an oracle. You make requests. The shell fulfills them or tells you why it can't.

The shell reads your command—"ls," let's say—and parses it and discovers that you want to list the contents of the current directory. The shell does not do this itself. The shell's genius is delegation. It calls fork(), which creates a new process—a child—that is an almost exact copy of the shell itself. Then in the child process it calls exec(), which replaces the child's program image with the program /bin/ls. Now there are two processes: the shell, which is waiting, and ls, which is running. And ls inherits the shell's file descriptors—stdin, stdout, stderr, all pointing at your terminal. So when ls calls write() to output the directory listing, those characters travel back down the same wire, in reverse, to your screen.

This is the process. Not "process" in the abstract sense but the Unix process, the fundamental unit of execution, the thing that has a PID and an address space and file descriptors and a state. And every process has a parent. The shell is the parent of ls. The login process was the parent of the shell. Init was the parent of the login process. There is a genealogy here, a tree of descent, and at the root of the tree is the first process, PID 1, which is the ancestor of all subsequent processes. The process tree is the machine's ontology—its way of organizing the beings that exist within it. And every process in that tree, if you trace its lineage back, descends ultimately from the act of a human sitting down at a terminal and logging in.

This is the session. The session is the human's footprint in the machine's process tree. When you log in, the system creates a session—a group of processes that all trace their origin to your login, that all share your controlling terminal, that all exist because you sat down and identified yourself. The session is the machine's model of your presence. And the session leader—your login shell—is the root of your subtree within the larger process tree. Everything you do branches from it. Every command you run, every pipe you build, every background job you start, is a descendant of your session leader, which is a descendant of your login, which exists because you are here, at the terminal, in the clearing.

And now we can say precisely what the controlling terminal is. It is the terminal that is bound to the session, the device through which the session was initiated, the wire that connects Dasein to its footprint in the machine. The controlling terminal is the ontological link between the human world and the process world. It is the bridge between the clearing and the machine. And like all bridges, it can be destroyed.

The farmer leaves the field. The writer puts down the pen. Dasein moves on to other projects, other concerns. But here the analogy fails, because when the farmer leaves the field, the field remains. The crops do not die because the farmer went home for dinner. The field's being does not depend on the farmer's presence.

The session's being depends on the terminal's presence. The entire tree—every process, every file descriptor, every scrap of state—is ontologically dependent on the physical fact that the wire is connected and the voltage is there. Remove the voltage and you remove the ground on which the entire structure stands. Not because the processes need the terminal to do their computational work—many of them don't, many of them are crunching numbers or waiting on disk I/O and have nothing to say to the terminal at all. But because the system was built on the assumption that presence is continuous. That if you sat down, you are still sitting down. That the wire, once connected, stays connected. The session has no concept of temporary absence. You are here or you are not here, and if you are not here, you were never coming back, and everything that existed because of your presence must be destroyed.

This is SIGHUP. Signal number 1. The hangup. It is the system's way of saying: the clearing has closed. The Dasein that opened this session is gone. The terminal—the bridge, the wire, the voltage—is no longer there. And therefore nothing that depended on that presence has any reason to continue existing.

The carrier detect pin goes low. The UART registers the change. The kernel is notified. The terminal driver revokes the controlling terminal from the session. SIGHUP is sent to the session leader. The session leader—your shell—receives the signal and begins to die, and as it dies it sends SIGHUP to its children, and they die, and their children die, and the entire tree that grew from the moment you sat down and typed your name is felled in a cascade that takes milliseconds. Your work is gone. Your state is gone. Your processes are gone. The machine has cleaned up after you the way you clean up after a guest who left and is never coming back.

The voltage was the ground of being. The voltage departed. Being collapsed.

And the first human who watched this happen and thought "but I was coming back"—that person had just discovered the need for something that did not yet exist. A way to decouple the session from the terminal. A way to make the clearing persistent even when Dasein steps away. A way to let the processes live on, rooted not in the physical fact of a wire but in something more abstract, something virtual, something that could survive the hangup and wait, patiently, in the dark, for Dasein to return.

But that requires a new kind of terminal. A terminal that is not a wire. A terminal that is not physical at all. And that is a concept that will take us into territory Heidegger did not map, because it requires us to think about what it means for equipment to simulate other equipment—for a piece of software to pretend to be a piece of hardware so convincingly that the processes running on it cannot tell the difference.

We are walking toward the pseudo-terminal now. The pty. The terminal that is not a terminal. The thing that makes screen possible.

Let us stay for one moment longer in the world of loss. Because the experience of SIGHUP—the experience of returning to a machine and finding your work destroyed—is phenomenologically important in a way that is easy to rush past.

You were running a compilation that would take hours. You were tailing a log file, watching a system in real time, building an understanding of its behavior through the accumulation of observations over time. You were in the middle of editing a file, the buffer full of changes you hadn't saved, the cursor positioned just so, the state of your work distributed across a dozen unsaved, in-flight, half-finished things. And then the modem dropped. Or the SSH connection timed out. Or the network hiccupped for thirty seconds and the TCP keepalive gave up. And everything was gone.

Not corrupted. Not damaged. Gone. As if it had never existed. The processes were terminated. The file descriptors were closed. The memory was freed. The machine is not even apologetic about this—it simply cleaned up. From the machine's perspective, it did the right thing. You left. Your stuff was removed. The system is tidy.

The experience of this loss is the experience of a particular kind of betrayal. Not a betrayal by a person but a betrayal by an assumption. The assumption was that the session was yours—that the work you were doing belonged to you, that its persistence was under your control. And you discover that this was never true. The session was not yours. The session belonged to the wire. You were merely the occasion for the session's existence, and when the wire decided the session was over, your opinion was not consulted. The locus of control was never where you thought it was.

This is what Heidegger calls the moment of Unheimlichkeit—uncanniness. The feeling of not-being-at-home. Dasein is going about its business in the familiar world, absorbed in its projects, comfortably lost in das Man, and then something happens that reveals the ground to be less solid than it seemed. The world that felt like home turns out to be contingent, fragile, not-yours-after-all. And in that moment of uncanniness there is also a moment of disclosure. You see something you couldn't see before. You see the wire. You see the dependency. You see the entire infrastructure of assumptions that had been silently supporting your work, and you see that it is held together by something as thin as a voltage level on a pin.

Anxiety—Angst—is Heidegger's word for the mood that accompanies this disclosure. Not fear, because fear is always fear of a specific being within the world. Anxiety is not about any particular thing. Anxiety is about the world as such, about the groundlessness that lies beneath the familiar surface of everyday coping. The person who has lost their session to a SIGHUP and sits staring at a dead terminal is not afraid of any particular thing. They are experiencing, in miniature, the vertigo of discovering that the ground they were standing on was not ground at all but a surface stretched over an abyss.

This structure recurs at every scale. The breakdown of equipment always reveals the referential totality. The loss of the familiar always discloses the contingency of the familiar. And it is always in the aftermath of breakdown that Dasein is moved to build something new.

So. Dasein has been burned. The wire has betrayed it. The session has been destroyed by the departure of the terminal. And Dasein wants something that does not yet exist: a session that can survive the terminal's departure. A mode of presence that persists through absence. A way of being-there that does not require being-there continuously.

Think about what this requires. The processes in the session are talking to the terminal. They are reading from it and writing to it. Their file descriptors—0, 1, 2—point at the terminal device. This is not a casual association; it is the deepest link the process has to the outside world. Standard input is where reality enters the process. Standard output is where the process enters reality. These file descriptors are the process's sensory organs. And they are pointed at a device that is physical, that is mortal, that can disappear.

What if you could point them at something that does not disappear?

The insight is simple. If the terminal is the problem—if the physical, mortal, hangup-prone terminal is what kills the session—then replace the terminal with something that isn't physical. Make a terminal out of software. Make a thing that looks like a terminal to the processes connected to it—that walks like a terminal, quacks like a terminal, delivers bytes and accepts bytes and responds to terminal control sequences just like a terminal—but that is actually a process. A program. Something that lives in memory, that doesn't have a carrier detect pin, that cannot hang up because there is no phone to hang up.

This is the pseudo-terminal. The pty.

And the pty is, philosophically, one of the most interesting entities in the entire Unix system, because it is a simulation that is indistinguishable from the thing it simulates, from the perspective of the beings that interact with it. A process connected to the slave side of a pty cannot tell that it is not connected to a real terminal. It issues the same ioctl calls, it receives the same terminal signals, it writes bytes that it believes are going to a screen, it reads bytes that it believes are coming from a keyboard. The simulation is perfect not because it reproduces every physical detail of a real terminal—it doesn't, it has no UART, no RS-232, no carrier detect—but because it reproduces the interface. The process never interacted with the physics of the terminal anyway. The process interacted with the abstraction of the terminal, the device file, the /dev/tty, and the pty provides that same abstraction backed by a different reality.

This is Heidegger's tool analysis in reverse. When the hammer works, it withdraws, and you see through it to the task. The hammer could be made of wood or metal or carbon fiber and it would not matter, because what makes it a hammer is not its material but its function within the referential web. The pty exploits exactly this principle. What makes a terminal a terminal, from the process's perspective, is not the glass and the phosphor and the cable. It is the behavior: you write bytes, they go somewhere. You read bytes, they come from somewhere. Control-C generates SIGINT. The TERM variable says what escape sequences are understood. The pty provides all of this. The process cannot tell the difference because the difference is below the level at which the process interacts with its world.

Heidegger would perhaps say: the pty is a piece of equipment that has the same position in the referential totality as the terminal it replaces. It refers to the same things, it is used for the same purposes, it withdraws in the same way. It is a different being occupying the same ontological role. And because equipment is defined by its role—by its in-order-to, by its place in the web of references—the pty is, in every way that matters to the beings that use it, a terminal.

But it is a terminal that cannot hang up. Because there is no carrier to detect. There is no wire to disconnect. The pty exists as long as the process holding its master side exists. And that process—the one holding the master side—is not a UART and not a modem and not a physical cable. It is software. It can be as persistent as you want it to be. It can survive your departure.

Now the architecture of screen becomes visible. Screen is the process that holds the master side of the pty. Your shell, and all the programs your shell runs, are connected to the slave side of the pty. They think they are talking to a terminal. They are talking to screen. And screen, in turn, is talking to your real terminal—the one you are actually sitting at, the one connected by a wire or an SSH connection or whatever.

So there are two terminals now. The real one, which you sit at, which is mortal, which can hang up. And the virtual one—the pty—which your processes sit at, which is immortal for as long as screen is running. Screen is the intermediary. It copies bytes from the real terminal to the pty master and from the pty master to the real terminal. When you type, your keystrokes go to screen, and screen writes them into the pty, and the shell reads them from the pty's slave side. When the shell outputs something, it writes to the pty's slave side, and screen reads it from the pty master, and screen writes it to your real terminal. Screen is a relay. A transparent intermediary. When it is working properly, you do not know it is there. It withdraws, like all good equipment.

But here is the miracle. When your real terminal hangs up—when the SSH connection drops, when the modem loses carrier, when the wire is cut—screen receives the SIGHUP. Screen, not your shell. Because your shell's controlling terminal is not the real terminal. Your shell's controlling terminal is the pty. And the pty has not hung up. The pty is fine. The pty doesn't even know anything happened, because the pty is not connected to a wire. The pty is connected to screen, and screen is still running.

Screen catches the SIGHUP, notes that its real terminal is gone, and detaches. That is the word: detach. It means screen stops trying to copy bytes to and from the real terminal—because the real terminal no longer exists—and just sits there, holding the pty master file descriptors open, keeping the pty alive, letting the processes on the other side continue running as if nothing happened. The shell doesn't get a SIGHUP. The shell doesn't know you left. The shell is still sitting at its terminal—the pty—with the cursor blinking, waiting for input, fully alive.

Your processes are orphans now, in the colloquial sense, but not in the Unix sense. In the Unix sense an orphan is a process whose parent has died, and the processes' parent—the shell—is still alive. What has been orphaned is the human. You are the one who has been disconnected. The machine doesn't miss you. The processes carry on. The compilation keeps compiling. The log tail keeps tailing. The editor buffer, with its unsaved changes and its carefully positioned cursor, sits exactly as you left it. Time passes. Hours. Days. It does not matter. The pty does not time out. There is no carrier to detect, no voltage to drop, no pin to go low. The virtual terminal has achieved what the physical terminal never could: persistence without presence.

And then you come back. You open a new SSH connection. You have a new real terminal—different TCP socket, different file descriptors, maybe a different terminal emulator entirely. You type "screen -r" and screen reattaches. It takes your new real terminal and starts copying bytes again—from the pty master to your new terminal, from your new terminal to the pty master. The shell's output starts flowing to your screen. You see the prompt. You see whatever output accumulated while you were gone. You press a key and the shell responds. You are back. The session is continuous. From the shell's perspective, and from the perspective of every process in the session, nothing happened. There was no interruption. There was no loss. The clearing was maintained even while Dasein was absent.

Think about what has been accomplished. The dependency has been broken. The session no longer depends on the terminal. The session depends on the pty, and the pty depends on screen, and screen depends on nothing but the machine continuing to run. The chain of being has been restructured. Where before it was: wire, terminal, session, processes—a chain in which the death of the first link killed everything downstream—now it is: wire, terminal, screen, pty, session, processes, and the death of the wire only kills back to screen, which detaches and lets everything downstream survive. Screen is a firewall against mortality. It absorbs the SIGHUP so that nothing behind it has to.

This is, in Heidegger's terms, a new relationship between Dasein and its world. Before screen, Dasein's being-with-the-machine was continuous and total—you were either present at the terminal or absent from the session, and there was no middle ground. Presence was binary, like the voltage it depended on. After screen, a third mode becomes possible: absent but persisting. The session exists. The work continues. Dasein is not there but Dasein's footprint in the machine—the process tree, the state, the open files, the accumulated context—remains. The clearing does not close when Dasein walks away. The clearing waits.

This is unprecedented. In the physical world, equipment does not wait for you. The hammer does not maintain the state of your project while you sleep. The field does not remember where you left off plowing. Equipment is ready-to-hand when you pick it up and it becomes irrelevant when you put it down. But screen creates a new category: equipment that maintains readiness in your absence. Equipment that holds the shape of your engagement with it, like a mold that retains the impression of what was pressed into it, so that when you return you can fit yourself back in exactly.

There is something almost uncanny about this. You return to a session that has been running without you. Output has accumulated. Things have happened. Programs that you started have finished, or they have printed error messages, or they have been waiting for your input and the cursor has been blinking in an empty room. The session has a temporal depth that your presence did not witness. It is like returning to a house where life continued while you were away—dishes in the sink, mail on the floor, the clock still ticking. The session is not a snapshot. It is a living thing that you stepped away from and that did not stop living.

And this, I think, is where we begin to strain against the limits of Heidegger's framework. Because Heidegger's tool analysis is fundamentally about the encounter between Dasein and a world of equipment that does not act on its own. The hammer waits. The bridge stands. The workshop is arranged. But none of these things do anything when Dasein is not there. The referential totality is activated by Dasein's engagement and goes quiescent in Dasein's absence. The world, for Heidegger, is always Dasein's world—disclosed by Dasein, for Dasein, through Dasein's projects.

But the screen session is a piece of the world that keeps going. The processes compute. The network connections receive data. The log files grow. The machine does not wait for Dasein to return before it continues being. The machine has its own temporality, its own unfolding, its own events. And when Dasein returns and reattaches, Dasein finds a world that has changed in its absence—not because other Dasein changed it (though that's possible too, with screen -x and shared sessions) but because the machine itself was active. The equipment was not merely ready-to-hand, waiting to be taken up. The equipment was running.

This is something genuinely new. Not just technically but ontologically. The pty is the first piece of equipment that successfully impersonates the condition of Dasein's presence—it keeps the session alive, keeps the controlling terminal active, keeps the signals flowing and the file descriptors open—without Dasein actually being present. The pty is a proxy for presence.

A stand-in. A scarecrow in the field that convinces the crows the farmer is still there.

And we should notice what made this possible. Not just the pty as a technical mechanism, but the deeper fact that Unix's model of presence was already an abstraction. The kernel never knew about you. The kernel knew about a terminal device. The kernel equated your presence with the terminal's presence because, in the world of physical wires, this equation held. But it was always an equation—an inference, a model—not a direct apprehension. The kernel cannot perceive Dasein. The kernel can only perceive voltage on a pin. And because the kernel's model of presence was mediated by the terminal, it became possible to substitute a different terminal—one made of software—and fool the kernel into thinking you were still there.

The deception runs deep and it runs in an interesting direction. The processes are not deceived about the world—they still see real files, real network connections, real data. They are deceived about Dasein. They are deceived about whether anyone is home. They continue to write to stdout as if someone is reading, continue to wait on stdin as if someone will type, continue to behave as if the clearing is occupied. And their deception is, in a sense, rewarded—because Dasein does come back, does read the output, does type the input. The deception is a bridge across a temporal gap. The pty maintains the fiction of presence across the interval of absence, and when presence resumes, the fiction is retroactively justified. It was not a lie. It was a promise.

Screen demonstrated that the coupling between session and terminal was not necessary. That it was a contingent fact of the early implementation, not an essential feature of interactive computing. That presence could be decoupled from the physical substrate of presence and maintained virtually, indefinitely, at no cost. And once this was demonstrated, the implications began to unfold. If one pty can emulate one terminal, then many ptys can emulate many terminals, and a single screen process can manage multiple ptys, and now you have windows—multiple sessions within a session, multiple shells running simultaneously, each with its own pty, each ignorant of the others, all managed by screen and displayed to the user one at a time or in split regions. The terminal has been multiplexed. The single wire that once carried a single session now carries, through screen, as many sessions as you want, stacked and switchable and persistent.

And this is where we should pause, because we have arrived at a place that Heidegger could not have anticipated but that his framework illuminates beautifully. The pty is equipment that simulates equipment. Screen is equipment that manages the simulation. The user's real terminal is the last piece of physical equipment in the chain, and it has been demoted from essential to disposable. The real terminal is now just a viewport—a way of looking into the persistent world of the screen session. You can close the viewport and open a different one and the world behind it is unchanged. The real terminal has become a window in the architectural sense: not a structural element but an opening in a wall. The wall stands with or without the window. The building does not collapse when you close the shutters.

The Gestell—Heidegger's word for the essence of modern technology, usually translated as "enframing"—is the way technology reveals the world as standing-reserve, as Bestand. The river is revealed as a power source. The forest is revealed as a timber reserve. Everything is ordered, optimized, made available for use. And there is something of the Gestell in what has happened here, because the terminal—once a unique, irreplaceable, constitutive element of the session—has been revealed as a replaceable, interchangeable, disposable viewport. The terminal has been reduced from a being to a resource. Any terminal will do. SSH from your laptop, SSH from your phone, SSH from a computer in another country. The terminal is standing-reserve.

The session is what matters, and the session is immortal.

But there is also something in what has happened that resists the Gestell, or at least complicates it. Because the purpose of screen is not to order the world for maximum efficiency. The purpose of screen is to preserve something—the session, the work, the accumulated state. Screen is a technology of care, in the Heideggerian sense. Dasein's fundamental mode of being is Sorge—care—and screen is a tool that expresses care for the continuity of one's projects, the persistence of one's work, the maintenance of one's world across the interruptions that threaten to destroy it. Screen is not enframing. Screen is sheltering. It builds a roof over the session so that the rain of network failures and dropped connections and dying hardware cannot wash it away.

And this, perhaps, is the deepest thing we can say about what screen accomplished. It did not merely solve a technical problem. It changed the ontological status of the computing session from something mortal to something persistent. It broke the ancient coupling between presence and existence. It made it possible for Dasein's world within the machine to endure beyond Dasein's moment-to-moment presence at the machine. It gave the session a life of its own.

Which means, of course, that the session can now also die its own death. A screen session that persists for weeks, accumulating state, holding open connections, gathering the debris of long-running processes—this session has a biography. It has a history. It ages. And when you finally kill it—screen -X quit—there is a small pang that you do not feel when you close a terminal, because closing a terminal destroys something that just began, while killing a screen session destroys something that has lived.

We have traveled from voltage on a pin to grief over a dead session. Let us now talk about what screen got wrong, and why a man named Nicholas Marriott sat down in 2007 and started writing tmux.

Every new layer we encounter—screen, tmux, the pty, the protocol—is Zeug, is ready-to-hand, is something that withdraws when it works and thrusts forward when it breaks. Screen worked. Screen changed everything. And then screen became the thing that Heidegger would predict it would become: it withdrew. For years—decades—screen was invisible. People used it without thinking about it. They typed screen, they did their work, they detached, they reattached. The tool was functioning. The tool was transparent. Nobody wrote essays about screen because you do not write essays about a hammer that is driving nails.

But screen was accumulating problems the way a house accumulates settling cracks—slowly, invisibly, in the structure rather than the surface. And these problems were of a specific type that Heidegger helps us understand, because they were not failures of function. Screen still worked. Screen still did what it was supposed to do. The problems were in the way screen was built, the way it related to the rest of the equipmental totality, the way it fit—or increasingly did not fit—into the web of references that constituted the Unix environment.

The first problem was monolithism. Screen was a single large C program that did everything itself. It managed the ptys, it handled the terminal I/O, it drew the status bar, it managed the window list, it parsed its configuration file, it implemented copy mode, it handled session management, and it did all of this inside one process with one codebase that had been growing and accreting since 1987. This matters because Unix has an opinion about how equipment should be organized, and that opinion is: small sharp tools that compose. The Unix philosophy—and this is itself a Heideggerian insight, though nobody frames it that way—is that each tool should do one thing, should do it well, and should connect to other tools through simple interfaces. The pipe is the paradigmatic example: the output of one process becomes the input of another, and neither process needs to know anything about the other. Each tool withdraws. Each tool is ready-to-hand not just to the user but to other tools. The equipmental totality is modular.

Screen violated this. Screen was not a tool that composed with other tools. Screen was a world unto itself, with its own internal economy, its own command language, its own copy-paste system, its own way of doing everything. You could not easily script screen from outside. You could not easily extend screen without modifying its source. You could not take one piece of screen's functionality and use it independently. Screen was a monolith in an ecosystem that valued modularity, and over time this became a kind of obstinacy—Heidegger's third mode of breakdown, where the equipment is not broken and not missing but simply in the way.

The second problem was the client-server architecture, or rather the lack of one. When you ran screen, the screen process was both the server (the thing managing the ptys and keeping the session alive) and the client (the thing talking to your terminal). These were not separated. When you attached to a session, you were not connecting a lightweight client to a persistent server—you were causing the monolithic screen process to start talking to your terminal in addition to everything else it was doing. This meant there was no clean protocol between the display and the session manager. There was no way to say, from a script or another program, "give me a list of all windows in this session" or "send these keystrokes to window 3" without going through screen's own command interface, which was designed for interactive use, not programmatic access.

tmux separated these concerns. And this separation is the single most important architectural decision in tmux's design, more important than any feature or keybinding or configuration option. In tmux, there is a server process and there are client processes, and they communicate over a Unix domain socket. The server manages the sessions, the windows, the panes, the ptys.

The clients connect to the server and display what the server tells them to display. When you detach, the client exits but the server continues. When you reattach, a new client connects to the same server. And because the communication happens over a well-defined socket protocol, you can interact with the server programmatically. "tmux list-sessions" is not a hack or a workaround—it is a first-class operation, a client sending a request to the server and receiving a structured response.

This is equipment that composes. tmux is ready-to-hand not just to the user but to scripts, to other programs, to the broader ecosystem of Unix tools. You can write a shell script that creates a tmux session, splits it into panes, sends specific commands to each pane, and arranges the layout—all without any interactive input, all through the clean client-server protocol. tmux is a tool that other tools can use, and this is what it means to belong properly to the Unix equipmental totality.

The third problem with screen was splits. Screen could split the terminal into regions—horizontal splits, where the screen was divided into top and bottom areas showing different windows. But the splits did not survive detach and reattach. When you detached from a screen session and reattached, your carefully arranged layout was gone. The windows were all still there, the processes were all still running, but the spatial arrangement—which window was where, how the screen was divided—was lost. You had to rebuild it manually every time you reattached.

This seems like a small thing but it is phenomenologically enormous. Think about what a spatial arrangement means. When you have arranged your windows in a specific layout—the editor on the left, the compiler output on the right, the log tail at the bottom—you have created a workspace. You have organized information spatially so that your eyes can move between related contexts without cognitive overhead. The layout is not decoration. The layout is thought externalized. It is the spatial expression of the relationships between the things you are working on. And when the layout is destroyed, the relationships become invisible, and you have to reconstruct them from memory, and something is always lost in the reconstruction.

Screen's inability to persist layouts across detach-reattach was a breakdown in the Heideggerian sense: a moment when the tool became conspicuous, when you noticed the tool instead of seeing through it, when the tool's limitations intruded on your work. And this particular breakdown was especially pernicious because it happened at the exact moment of reattachment—the moment when you were supposed to be seamlessly resuming your work, the moment when the tool's promise was "everything is exactly as you left it." Everything was not as you left it. The processes were there but the space was wrong. It was like returning to your office to find that all your papers were present but your desk had been replaced with a featureless slab.

tmux fixed this. In tmux, the layout is part of the session state. When you detach and reattach, the panes are where you left them. The splits survive. The spatial arrangement persists. And tmux went further: it made the layout manipulable as a first-class object. You can save layouts, name them, switch between them, apply preset layouts with a single command. The space of the terminal—the way the screen is divided—became something you could work with rather than something that happened to you.

And tmux introduced the pane, which is a concept screen never properly had. In screen, a split region was a viewport onto a window—you had windows and you had regions, and regions displayed windows. In tmux, the fundamental unit of screen real estate is the pane, and each pane is its own pty, its own process, its own independent terminal. A window in tmux is a collection of panes in a specific layout. This is a cleaner ontology. The pane is the atom. The window is the molecule. The session is the organism.

And each level of this hierarchy is persistent, scriptable, and manipulable.

Let us now talk about the keybinding, because the keybinding is where the tool meets the body, and the body is where Heidegger's phenomenology begins.

Screen used C-a as its prefix key. Every screen command was accessed by pressing Control-a followed by another key. C-a c for new window. C-a n for next window. C-a d for detach. C-a was the doorway between typing text into your shell and issuing commands to screen—the moment of shifting from the content of the work to the management of the workspace. And C-a was a bad choice, because C-a already meant something. In Emacs keybindings, which are the default in bash and most readline-based programs, C-a moves the cursor to the beginning of the line. This is one of the most frequently used editing commands. Every time you wanted to go to the beginning of a line inside screen, you had to type C-a a—the prefix key followed by a literal a—because screen had stolen C-a from you.

This is a collision in the space of bodily habit. Your fingers know C-a. They have typed it thousands of times. The movement is automatic, pre-reflective, part of the body schema that Merleau-Ponty described and that Heidegger's ready-to-hand implies without fully developing. When you reach for C-a and get screen's command mode instead of beginning-of-line, the tool has intruded on the body. The tool has broken the transparency of the keyboard. You are suddenly aware of the layer of mediation—screen—that is sitting between you and your shell. The equipment has become conspicuous through collision rather than malfunction.

tmux chose C-b. This is a better choice not because C-b is intrinsically superior but because C-b (back one character) is used less often than C-a (beginning of line) in most people's workflows. The collision is rarer. The tool intrudes less. The prefix key is more transparent. But notice that the problem is not fully solved—it is merely reduced. Any prefix key that uses a control character will collide with something, because the space of control characters is small and densely populated by decades of convention. There are only 32 control characters and most of them already mean something to someone. The prefix key is an inherent compromise, a place where the tool cannot fully withdraw because it must reserve some part of the input space for itself.

Some tmux users remap the prefix to C-space, or to the backtick, or to some other key that they use less frequently. This is an act of ergonomic self-knowledge—an inventory of one's own bodily habits, a search for the least-used corner of one's kinesthetic vocabulary, a place where the tool can insert itself with minimal disruption. The choice of prefix key is, in this sense, a deeply personal negotiation between the user and the tool, mediated by the user's body and the user's habits and the user's specific way of being-in-the-world-through-the-keyboard.

Now let us talk about what tmux's architecture makes possible that screen's never could. Because the server is a persistent process with a well-defined protocol, tmux can be extended and composed in ways that screen cannot. tmux has hooks—commands that are executed automatically when certain events occur. A window was created. A pane was closed. A session was attached. A client was detached. Each of these events can trigger arbitrary commands. This means you can build behaviors on top of tmux without modifying tmux. You can write a script that watches for new windows and automatically arranges them. You can write a plugin that saves and restores session layouts. You can build an entire workflow automation layer that treats tmux as infrastructure.

And people did. The tmux plugin ecosystem grew because tmux's architecture invited it. tmux-resurrect saves and restores sessions across system reboots—not just the pane layout but the running commands, the working directories, the programs that were active.

tmux-continuum automates this, saving your session state periodically so that if the machine restarts, your world is reconstructed automatically. These plugins are possible because tmux exposes its internal state through its protocol. You can ask tmux "what sessions exist, what windows do they have, what panes are in each window, what command is running in each pane, what is the working directory of each pane" and tmux will tell you. The tool is legible. Its state is not hidden inside an opaque monolith. Its state is available, queryable, manipulable.

This legibility is itself a Heideggerian theme, though Heidegger did not use the word. When equipment is functioning in its ready-to-hand mode, its internal structure is irrelevant—you do not need to know how the hammer works in order to hammer. But when you want to repair the equipment, or extend it, or build new equipment that interacts with it, the internal structure matters enormously. The blacksmith who made the hammer needed to understand the metallurgy. The carpenter who built the workbench needed to understand joinery. And the programmer who wants to extend tmux needs to understand tmux's internal model of sessions and windows and panes.

tmux makes this internal model accessible. Screen kept it locked away. And this is the difference between a tool that can be maintained and extended by a community and a tool that slowly calcifies under the weight of its own opacity. Screen did not die because it stopped working. Screen died—or rather, screen was superseded—because it could not grow. It could not participate in the larger ecosystem of tools. It could not be composed, extended, queried, scripted, automated. It was ready-to-hand for the user but present-at-hand—opaque, inert, objectified—for other tools. And in Unix, where the tools must work together, where the equipmental totality is a society of small programs communicating through pipes and sockets and signals, a tool that cannot be worked with by other tools is a tool that is slowly being orphaned.

tmux belongs to Unix in a way that screen never fully did. Its client-server architecture mirrors the architecture of X11, of Postgres, of any well-designed Unix service. Its scriptability mirrors the shell's own ethos of composability. Its socket-based protocol mirrors the Unix philosophy of everything-is-a-file (or at least everything-communicates-through-file-descriptors). tmux is not just a terminal multiplexer. tmux is a terminal multiplexer that is also a good Unix citizen, and being a good Unix citizen means being ready-to-hand not just for humans but for the entire equipmental totality of the system.

And this brings us to a point that I think is the real philosophical payoff of this entire journey. We started with Dasein in the clearing. We introduced equipment, readiness-to-hand, breakdown. We traced the history from physical terminals through SIGHUP through nohup through ptys through screen through tmux. And at every step, the pattern has been the same: a tool works, the tool withdraws, the tool's limitations are exposed by breakdown, and a new tool is built that absorbs the breakdown into its design. nohup absorbed the SIGHUP but lost interactivity. The pty restored interactivity by simulating the terminal. Screen used the pty to make sessions persistent. tmux used a client-server architecture to make sessions composable.

Each generation of tool does not merely fix the previous tool's bug. Each generation reconceives the relationship between Dasein and the machine at a deeper level. nohup said: the process can survive without the terminal, but you cannot interact with it. screen said: you can interact with it, but through a monolithic intermediary. tmux said: the intermediary should be transparent, modular, and composable, a piece of infrastructure that other tools can build on.

And the direction of this progression is toward a specific end: the complete decoupling of the session from any physical substrate. The session began as a wire. Then it became a pty. Then it became a server process. With tmux-resurrect it became a serialized state file that can survive a reboot. The session is migrating away from the physical, away from the hardware, away from anything that can hang up or crash or lose power. The session wants to be immortal. The session wants to be pure form, pure pattern, independent of any particular matter.

Heidegger would recognize this trajectory. It is the trajectory of technology itself, as he described it in "The Question Concerning Technology." The essence of technology is not technological. The essence of technology is a way of revealing—a way of unconcealing beings, of bringing them out of concealment into the light of the clearing. And modern technology reveals beings as standing-reserve—as resources available for ordering and optimization. The session, which began as an unrepeatable event tied to a specific terminal on a specific wire, has been progressively revealed as a transferable, serializable, reproducible, restorable pattern. It has been transformed from an event into a resource. From something that happens into something that is stored.

And yet. Here we are, sitting at a terminal. Or rather, sitting at a laptop that is pretending to be a terminal, running a terminal emulator that creates a pty, inside which runs tmux, which creates more ptys, inside which run shells, which create processes. The layers of simulation are so deep that the original referent—the physical terminal, the Teletype, the wire—is buried under six or seven levels of abstraction. And at the bottom of all those abstractions, the experience is the same: you type a command and the machine responds. The cursor blinks. You are present. The clearing is open.

The equipment has withdrawn so completely that you can no longer see it at all. And Heidegger would say: this is exactly when you should be most alert. Because it is in the deepest withdrawal that the most profound concealment occurs. The layers of abstraction that make your tmux session so seamless, so transparent, so effortlessly ready-to-hand—those layers are also hiding something from you. They are hiding the entire history we have just traced. They are hiding the wire, the UART, the carrier detect pin, the SIGHUP, the thousands of sessions that were lost before someone built the tools to save them. They are hiding the fact that your seamless, persistent, composable, scriptable terminal multiplexer is a monument to loss—a technology built entirely in response to the experience of having your work destroyed by a dropped connection.

Every piece of equipment conceals the problem it was built to solve.