«Todo es un archivo»: la idea de Unix de hace 50 años que explica por qué Linux es tan distinto

De dónde sale la idea: Unix, 1969

Unix surgió durante 1969 dentro de los Bell Labs de AT&T, en Nueva Jersey. Con tiza sobre una pizarra y apuntes a mano, Rudd Canaday, Dennis Ritchie y Ken Thompson dieron forma al sistema de archivos; Ritchie lo describiría después como «el corazón de Unix». Él mismo se atribuye la ocurrencia de los archivos de dispositivoref.

La descripción pública inicial fue el artículo «The UNIX Time-Sharing System», expuesto por Thompson y Ritchie en un congreso de octubre de 1973 y editado por Communications of the ACM en julio de 1974. Según ese texto, el usuario distinguía tres tipos de archivosref:

• Archivos normales: ficheros del disco.
• Directorios, archivos que guardan una lista con otros archivos.
• Archivos especiales: existe uno por cada dispositivo de entrada y salida, y viven en /dev.

Para los autores, los archivos especiales eran «la característica más inusual» del sistema, y ofrecían tres razonesref:

1. Leer o escribir resulta muy similar en un archivo y en un dispositivo. Un programa capaz de escribir en un archivo también sabrá hacerlo en una cinta o en un terminal.
2. Los nombres funcionan igual. Allí donde un programa aguarda un nombre de archivo, admite el de un dispositivo.
3. Los permisos son los mismos. El mismo mecanismo que decide quién lee un documento controla quién usa la impresora o el disco.

Bytes sin formato

La segunda pieza: para Unix, un archivo no es más que una secuencia de bytes. El sistema no distingue texto, foto o base de datos; cada programa decide eso. Sistemas contemporáneos como VMS usaban archivos estructurados (registros, campos). Linus Torvalds lo resumió en 2001: cuando Unix afirma que «todo es un archivo», lo que en realidad sostiene es que **«todo es un flujo de bytes»**ref.

Las tuberías

El tercer elemento apareció en 1972: las tuberías (pipes), propuestas «o quizá por insistencia» por Doug McIlroy, compañero de Ritchie y Thompsonref. Una tubería enlaza lo que un programa escribe con lo que otro lee. El texto de 1974 describe cómo varios mandatos divididos por barras verticales corren a la vez y llama filtro al programa que toma su entrada, la transforma y la vuelca en la salidaref.

Estas tres piezas explican la filosofía de Unix: herramientas pequeñas, cada una con una única misión, encadenadas porque comparten el mismo idioma: bytes de entrada y bytes de salida.

De Unix a Linux

Linux no constituye un Unix propiamente dicho, pues no comparte su código, aunque adoptó su diseño. Linus Torvalds lo empezó en 1991 tomando el modelo de Unix; de ahí que /dev, los permisos y las tuberías se comporten en Linux casi como en el sistema de los años setenta. macOS, descendiente de Unix por la vía de BSD, también cuenta con /dev y tuberías, pero carece de /proc y /sys.

/dev: el hardware convertido en archivos

Ritchie y Thompson ya hablaban de /dev en 1974, y ahí continúa. Basta con ls -l para verlo:

ls -l /dev/nvme0n1 /dev/null /dev/zero /dev/urandom

brw-rw---- 1 root disk 259, 2 oct 26 07:44 /dev/nvme0n1
crw-rw-rw- 1 root root   1, 3 oct 26 07:44 /dev/null
crw-rw-rw- 1 root root   1, 9 oct 26 07:44 /dev/urandom
crw-rw-rw- 1 root root   1, 5 oct 26 07:44 /dev/zero

La primera letra revela el tipo de archivo especial:

• b, dispositivo de bloques: discos y particiones, accesibles en bloques y en un orden cualquiera. Los SATA o USB suelen recibir nombres como /dev/sda o /dev/sdb…, y los NVMe, /dev/nvme0n1.
• c, dispositivo de caracteres: terminales, ratones, puertos serie y los dispositivos virtuales de más abajo, que se consumen como un flujo de bytes.

Esos dos números que normalmente ocupan el lugar del tamaño, separados por coma, son el número mayor y el menor. El primero señala al núcleo qué controlador sirve al archivo; el segundo, cuál de sus dispositivos toca. Dentro del archivo no hay nada: solo una puerta hacia el controlador.

Los permisos también cuentan, tal como anunciaba el texto de 1974. El disco es del grupo disk, de modo que únicamente root y sus integrantes pueden leerlo. /dev/null, por el contrario, permite lectura y escritura a cualquiera.

Cuatro archivos que no tienen hardware detrás

Hay archivos de /dev sin ningún aparato detrás; los crea el núcleo y figuran entre los más usados:

• /dev/null, el agujero negro. Todo lo que recibe desaparece; al leerlo, entrega «fin de archivo» de inmediatoref. Sirve para acallar a un programa:

find / -name "*.conf" 2>/dev/null

El 2> desvía los avisos de error («permiso denegado») hacia la papelera y deja únicamente los resultados en pantalla.

• /dev/zero no deja de soltar cerosref. Sirve para crear archivos de un tamaño exacto o llenar un disco:

head -c 10M /dev/zero > prueba.bin

• /dev/urandom entrega bytes aleatorios que produce el núcleo; su manual lo considera apto para cualquier propósito, excepto en los primeros momentos del arranqueref. Por ejemplo, para obtener una contraseña de 20 caracteres:

head -c 15 /dev/urandom | base64

• /dev/random era la variante que se quedaba bloqueada si el núcleo creía que andaba escaso de entropía. A partir de Linux 5.6, ese bloqueo desaparece salvo al arrancar; en la práctica, ambas ofrecen lo mismoref.

Ver los discos y montarlos

Para conocer los discos y las particiones disponibles, lsblk despliega el árbol entero. Resulta ilustrativo: no consulta servicio alguno, sino que toma los datos de /sysref.

lsblk -o NAME,SIZE,TYPE,MOUNTPOINTS

NAME          SIZE TYPE MOUNTPOINTS
nvme0n1     953,9G disk
├─nvme0n1p1     4G part /boot
└─nvme0n1p2 949,9G part /

Un disco no se utiliza directamente: se monta, o sea, se engancha su sistema de archivos a una carpeta. Desde ese momento, sus archivos quedan visibles dentro de ella. Linux prescinde de letras de unidad al estilo de C: o D:; todo parte de un único árbol con raíz en /, y cada memoria USB, disco o carpeta de red cuelga de alguna ramaref:

sudo mount /dev/sdb1 /mnt

Copiar un disco como si fuera un archivo

Como el disco funciona como archivo, dd lo copia byte a byte; esta utilidad traslada datos entre archivosref. De este modo se graba una ISO en una memoria USB:

sudo dd if=distro.iso of=/dev/sdX bs=4M status=progress conv=fsync

Así se saca una imagen íntegra del disco y se guarda como copia:

sudo dd if=/dev/sdX of=copia-del-disco.img bs=4M status=progress

Para grabar imágenes con seguridad, Linux también ofrece utilidades gráficas, incluidas en la guía de programas para pasar una ISO a un USB.

/proc y /sys: el núcleo responde en texto

Unix transformó cada dispositivo en un archivo; sus herederos fueron más lejos y volcaron también en archivos lo que ocurre dentro.

/proc: los procesos como archivos

Tom Killian presentó en USENIX, durante 1984, el trabajo «Processes as Files», con un /proc para la octava edición de Unixref. Buscaba reemplazar ptrace —la llamada con la que los depuradores leían palabra a palabra la memoria ajena— por una vía más simple: abrir el proceso como archivo y leerlo con readref.

La versión 0.97.3 de Linux, de septiembre de 1992, trajo su propia implementación de /procref. El manual lo califica de pseudosistema de archivos que permite consultar las estructuras internas del núcleoref. Recibe el prefijo pseudo porque nada de ello habita en el disco.

Algunos archivos que se pueden leer ahora mismo:

grep "model name" /proc/cpuinfo | head -1   # el modelo de procesador
head -3 /proc/meminfo                       # memoria total, libre y disponible
cat /proc/uptime                            # segundos encendido
cat /proc/loadavg                           # carga media del sistema

Utilidades como free, ps o top no disponen de un canal secreto hacia el núcleo: pertenecen al paquete procps, que toma sus datos de /procref y los muestra ordenados.

Cada programa activo tiene una carpeta que lleva su número de proceso (PID); /proc/1234 sería un ejemploref. Existe un atajo, /proc/self, que siempre señala al proceso lector. Gracias a él se observa una curiosidad:

ls -l /proc/self/fd

lr-x------ 1 ruben ruben 64 oct 26 09:51 0 -> /dev/null
l-wx------ 1 ruben ruben 64 oct 26 09:51 1 -> pipe:[307103]
l-wx------ 1 ruben ruben 64 oct 26 09:51 2 -> pipe:[307103]

Son los archivos abiertos por el propio ls. El descriptor 0 es su entrada, el 1 su salida y el 2 los errores. Según el lugar desde el que se ejecute, señalarán un terminal (/dev/pts/0), /dev/null o una tubería (pipe:[…]), que igualmente carece de presencia en disco.

Un archivo de 0 bytes con 46.000 bytes dentro

Estos archivos no se comportan del todo como los normales:

ls -l /proc/cpuinfo
wc -c /proc/cpuinfo

-r--r--r-- 1 root root 0 oct 26 07:43 /proc/cpuinfo
46122 /proc/cpuinfo

ls declara un tamaño de 0 bytes, mientras que wc cuenta más de 46.000 al leerlo. El contenido nace en el instante de la lectura, de modo que el núcleo ignora de antemano cuánto medirá. A cat le da igual, pues consume hasta el final; en cambio, un programa que se fíe del tamaño antes de leer fallará.

/sys: un valor por archivo

/proc terminó como un cajón de sastre donde la información de los procesos se mezclaba con los ajustes de los dispositivos y del núcleo. Para ordenar ese desorden, mientras se desarrollaba Linux 2.5 surgió un modelo de dispositivos nuevo y, junto a él, sysfs, montado en /sys y presente en las versiones estables desde Linux 2.6ref.

Según la documentación del núcleo, sysfs es un sistema de archivos en memoria que hace visibles los atributos del núcleo, sus estructuras internas y las relaciones entre ellas. Añade una norma: cada atributo debe vivir en un archivo de texto y, a ser posible, guardar un solo valorref. Leerlos desde un script resulta muy sencillo.

cat /sys/class/power_supply/BAT0/capacity    # batería, de 0 a 100
cat /sys/class/power_supply/BAT0/status      # Charging, Discharging, Full…
cat /sys/class/thermal/thermal_zone0/temp    # temperatura

El archivo capacity entrega el porcentaje de batería, de 0 a 100, y es únicamente de lecturaref. La temperatura se expresa en milésimas de grado: 41000 equivale a 41 °Cref.

Los nombres varían según el equipo. La batería podrá llamarse CMB0, BAT1 o BAT0, y un ordenador de sobremesa quizá no tenga ninguna. Para descubrir qué existe en el tuyo:

ls /sys/class/power_supply/
ls /sys/class/thermal/

Cambiar el brillo escribiendo un número

/sys no se limita a la lectura. Hay archivos que aceptan escritura y cambian cómo actúa el hardware. Destaca el brillo de la pantalla en un portátil:

ls /sys/class/backlight/
cat /sys/class/backlight/*/max_brightness
cat /sys/class/backlight/*/brightness

El archivo brightness acepta valores entre 0 y el contenido de max_brightnessref. Con un máximo de 65535, la orden siguiente lo sitúa aproximadamente en la mitad (sustituye amdgpu_bl1 por el nombre que aparezca en tu equipo):

echo 32000 | sudo tee /sys/class/backlight/amdgpu_bl1/brightness

Buena parte de los ajustes del escritorio funciona así por dentro: en un portátil, el deslizador de brillo suele acabar escribiendo una cifra en un archivo así.

Tuberías, sockets y descriptores: la versión más exacta de la idea

Al abrir un archivo, un programa recibe del núcleo un número pequeño: el descriptor de archivo. Desde ese instante prescinde del nombre y opera con él para leer y escribir. Cualquier proceso nace con tres abiertos:

• 0, entrada estándar (stdin): normalmente, lo que recibe del teclado.
• 1, salida estándar (stdout): normalmente, lo que escribe en pantalla.
• 2, salida de errores (stderr): avisos y errores, también por pantalla.

Lo fundamental es que el programa desconoce la naturaleza de cada número. Según Torvalds en 2001, un proceso simplemente lee y escribe, sin necesidad de saber si el descriptor corresponde a un socket de red, una tubería, un dispositivo o la apertura de un archivoref.

Las tuberías en la práctica

Las tuberías resultan el ejemplo más nítido. En 1974 ya se explicaba que el programa que lee de una tubería queda a la espera de que el otro extremo escribaref. De este modo se encadenan herramientas que se desconocen entre sí:

# Los cinco procesos que más memoria usan
ps aux --sort=-%mem | head -6

# Cuántas veces aparece cada error en un registro, de más a menos
grep -i error /var/log/app.log | sort | uniq -c | sort -rn | head

# Las 10 palabras más repetidas de un texto
tr -cs '[:alpha:]' '\n' < libro.txt | tr '[:upper:]' '[:lower:]' | sort | uniq -c | sort -rn | head

Ninguna de estas herramientas fue pensada para colaborar con las demás. sort ignora que aquello que ordena proviene de grep; se limita a leer bytes a través del descriptor 0. La guía de contar palabras y caracteres en Linux reúne muchas más recetas parecidas.

El núcleo genera un par de descriptores vinculados, así que una tubería convencional carece de nombre y no se guarda en el disco. De ahí que en /proc/self/fd aparezca como pipe:[307103]. Si hace falta una tubería con nombre, para enlazar dos aplicaciones que no lanzó la misma terminal, existe mkfifo, que sí crea una entrada en el árbol de directoriosref.

Sockets: la red con read y write

Las conexiones de red obedecen al mismo esquema. Un programa abre un socket, contacta con un servidor y obtiene un descriptor para leer y escribir como si fuera un archivo. El socket carece de nombre en /dev, aunque una vez establecido se maneja igual.

Bash va un paso más lejos con un recurso propio: escribir /dev/tcp/servidor/puerto dentro de una redirección establece una conexión TCPref. Esa ruta no existe en el disco, la entiende Bash y falla en otros intérpretes como zsh o fish:

exec 3<>/dev/tcp/example.com/80
printf 'HEAD / HTTP/1.0\r\nHost: example.com\r\n\r\n' >&3
cat <&3

Esas tres líneas establecen una conexión web mediante el descriptor 3, mandan una petición y recogen la respuesta, sin curl ni navegador.

«Todo puede tener un descriptor»

Por eso, la expresión «todo es un archivo» resulta a la vez insuficiente y exagerada. Neil Brown, desarrollador del núcleo, publicó en LWN durante 2010 que esa frase «exagera la realidad»: las tuberías y los dispositivos imitan parte del comportamiento de un archivo, pero no lo son. Su alternativa, menos pegadiza y más precisa: **«todo puede tener un descriptor de archivo»**ref.

Linux tomó ese rumbo. Hoy existen descriptores para señales (signalfd), eventos (eventfd), temporizadores (timerfd) y hasta procesos (pidfd), además de los de sockets, tuberías y archivos. La ventaja es práctica: una única llamada que vigila una lista de descriptores permite a un programa esperar a la vez a que llegue un dato de la red, salte un temporizador o termine un proceso hijoref.

FUSE: cualquier cosa puede ser una carpeta

El último salto consiste en convertir en archivos aquello que no lo es. FUSE deja programar un sistema de archivos dentro de un programa corriente, sin modificar el núcleoref. Gracias a él hay, por ejemplo:

• sshfs, que monta por SSH una carpeta remota y la presenta como local.
• rclone mount, que consigue lo mismo con Dropbox, Google Drive o un almacenamiento S3.
• Los montajes de imágenes ISO, archivos ZIP o teléfonos Android (MTP) de los gestores de archivos.

Tras el montaje, todo programa del sistema, de grep a un editor de fotografías, trabaja con esos archivos sin advertir que en realidad viven en la nube.

Lo que no es un archivo: límites, ioctl y la versión radical de Plan 9

Las tarjetas de red no están en /dev

Un terminal vive en /dev/tty y un disco en /dev/nvme0n1, pero no hay nada parecido a /dev/eth0 o /dev/wlan0. La división clásica entre bloques y caracteres no daba cabida a las interfaces de red, que recibieron un espacio de nombres propio, con funciones específicas para abrirlas, renombrarlas y listarlasref. Para ajustarlas se emplean llamadas concretas sobre un socketref o, en sistemas actuales, el protocolo netlink que maneja el comando ip.

La información disponible sí aparece en /sys, repartida en carpetas:

ls /sys/class/net/
cat /sys/class/net/wlan0/statistics/rx_bytes   # bytes recibidos por el wifi

Los contadores y estados se consultan, pero no existe forma de «abrir la tarjeta de red» y escribir paquetes como se haría en un disco.

ioctl, el cajón de sastre

El flujo de bytes no resuelve todas las tareas. ¿Cómo se indica a un puerto serie la velocidad a la que debe trabajar, o se ordena a un disco expulsar la bandeja? Para eso está ioctl, una llamada que, según el manual, «manipula los parámetros de los archivos especiales». Ese mismo manual admite que sirve de cajón de sastre para lo que no encaja en el flujo de bytes, que sus argumentos y su significado dependen de cada controlador y que no pertenece a ningún estándarref.

Dicho de otro modo: el archivo de dispositivo ofrece la puerta común, pero cada aparato habla detrás su propio idioma. La promesa de «todo se maneja igual» se queda ahí a medias.

Los archivos que mienten sobre sí mismos

/proc/cpuinfo declara 0 bytes. En /sys ocurre al revés: casi todos sus archivos dicen ocupar 4096 bytes aunque solo guarden una cifra de dos dígitos. En estos sistemas virtuales, ni el tamaño ni la fecha de modificación se leen siempre igual que en un discoref. Si una herramienta de respaldo recorre todo el árbol a partir de / sin excluir /proc, /sys y /dev, topará con la memoria del sistema, con miles de entradas que cambian mientras las lee y con archivos infinitos (/dev/zero). Por tal motivo, todo software de copia los excluye.

Otras críticas

• Texto sin formato fijo. Cada archivo de /proc posee un formato propio. Un script que extrae de /proc/meminfo un dato confía en que ese formato no varíe, y el núcleo debe conservarlo para no romper programas.
• No todo cabe. Hoy, audio, gráfica y gestión de energía cuentan con interfaces propias (ALSA, DRM, D-Bus) con descriptores, aunque no se manejan mediante cat y echo.
• Permisos. Exponer tanto como archivos exige mucho cuidado con los permisos. La especificación de contenedores OCI, seguida por Docker y Podman, incluye listas de rutas ocultas o en solo lectura dentro del contenedor, precisamente para tapar partes de /proc y /sysref.

Plan 9: la idea llevada hasta el final

Los propios Bell Labs que habían creado Unix intentaron resolver sus carencias a lo largo de los años ochenta y noventa con Plan 9, un sistema operativo de investigación por el que pasaron, entre otros, Ken Thompson y Rob Pike. Tres principios sostienen su diseño: todos los recursos se nombran y manejan como archivos de una jerarquía; se accede a ellos mediante un protocolo común, 9P; y cada proceso disfruta de su propia vista privada de ese árbolref.

La red, en Plan 9, sí funciona como archivo. Al abrir /net/tcp/clone se asigna una conexión cuyo archivo de control permite gobernarla mediante órdenes de textoref. Las ventanas siguen la misma lógica: cada una ve sus propios /dev/cons y /dev/mouseref. Y en lugar de ioctl, los dispositivos obedecen a mensajes de texto, por ejemplo al anotar en un archivo la velocidad de un puerto serieref.

Plan 9 no llegó a imponerse, aunque varias de sus ideas llegaron a Linux. Los namespaces (espacios de nombres), incorporados en 2002 inspirados por Plan 9, sostienen hoy Docker, Podman y los demás contenedoresref. Además, WSL usa el protocolo 9P para que Windows vea los archivos de las distribuciones Linux en la ruta \\wsl$ref.

Cómo lo hace Windows: handles, objetos y el registro

Windows no es tan distinto por dentro como parece. Su particularidad reside en dónde coloca cada cosa y en las herramientas que ofrece para alcanzarla.

Handles en vez de descriptores

El handle ocupa en Windows el lugar del descriptor de archivo. Para trabajar con un recurso, la aplicación lo identifica por su nombre, obtiene un handle y ejecuta luego todas las operaciones a través de élref. CreateFile, a pesar del nombre, abre tanto archivos como dispositivosref.

Hasta aquí, la cosa se parece bastante a Unix. Además, los handles no se limitan a archivos: también existen para procesos, hilos, eventos o claves del registro.

Los dispositivos, fuera del árbol de carpetas

El contraste aparece en los nombres. Los dispositivos de Windows no residen en ninguna carpeta del disco, sino en un espacio de nombres separado que administra el Object Manager del núcleo. Allí un volumen se llama algo como \Device\HarddiskVolume1, y la letra C: no es más que un enlace simbólico hacia élref. El Explorador oculta ese árbol: se necesita una herramienta como WinObj, de Sysinternals.

Desde un programa, el prefijo \\.\ da acceso a los dispositivos. \\.\PhysicalDrive0, por ejemplo, abre entero el primer disco físico y se salta el sistema de archivos, algo que aprovechan las herramientas de clonadoref. Viene a ser el /dev/sda de Windows, escondido tras una sintaxis que casi nadie llega a ver.

NUL, el /dev/null de Windows

Windows conserva nombres reservados de MS-DOS para dispositivos: CON (la consola), PRN (la impresora), COM1…COM9 (puertos serie) y NUL, que hace las veces de /dev/null. Son tan especiales que no se puede crear un archivo con esos nombres en ninguna carpeta, ni siquiera añadiendo extensión: NUL.txt equivale a NULref. En la consola de Windows, eso acalla un programa igual que en Linux:

programa.exe > NUL 2>&1

El registro en vez de archivos de texto

La configuración aporta otra diferencia de fondo. En Linux, casi toda vive en archivos de texto repartidos entre /etc y la carpeta personal, mientras los valores del núcleo viven en /proc/sys y /sys. Windows, en cambio, guarda la mayor parte en el registro, descrito por Microsoft como una base de datos jerárquica de claves y valoresref.

El registro ofrece ventajas como permisos por clave, tipos de datos y acceso rápido. Ahora bien, tocarlo exige herramientas propias (regedit, reg, PowerShell). En Linux, un ajuste se copia, se compara con diff, se guarda en Git o se edita con cualquier editor, pues es un archivo.

PowerShell: tuberías de objetos

Windows también dispone de tuberías, y PowerShell las orientó de otro modo. En vez de trasladar texto entre programas, traslada objetos .NET, con sus propiedades y sus métodosref:

Get-Process | Sort-Object -Property WorkingSet -Descending | Select-Object -First 5

De este modo, la ordenación usa la propiedad WorkingSet (la memoria) y evita recortar columnas textuales, una flaqueza de las tuberías de Unix. Como contrapartida, solo funciona bien entre órdenes que entienden esos objetos. Las de Linux son más toscas, pero conectan todo programa, escrito en el lenguaje que sea, de los últimos cincuenta años, porque todos leen y escriben bytes. XDA señala que tal diferencia crea hábitos muy distintos según el sistemaref.

Para qué sirve en el día a día

La idea produce efectos prácticos siempre que se emplea Linux, incluso en servidores o contenedores sin pantalla.

Scripts que leen el sistema sin instalar nada

Los archivos de texto guardan el estado del sistema, así que un script breve puede vigilarlo. El siguiente avisa al bajar la batería del 20 % y no estar cargando:

#!/bin/bash
bat=/sys/class/power_supply/BAT0
if [ "$(cat $bat/capacity)" -lt 20 ] && [ "$(cat $bat/status)" = "Discharging" ]; then
  notify-send "Batería baja" "Queda un $(cat $bat/capacity) %"
fi

No se necesita biblioteca alguna ni permiso especial: basta con cat y una comparación. Sirve igual para el tráfico de red, la temperatura o la memoria libre. Muchas utilidades de vigilancia, entre ellas las barras de estado de los escritorios ligeros, funcionan exactamente así.

Depurar un programa que se ha colgado

/proc funciona como navaja suiza para descubrir qué hace un proceso, incluso sin utilidades de depuración. Sabiendo su número (con pgrep nombre):

cat /proc/1234/cmdline | tr '\0' ' '   # con qué opciones se lanzó
ls -l /proc/1234/fd                    # qué archivos y conexiones tiene abiertos
ls -l /proc/1234/cwd                   # en qué carpeta está trabajando
grep VmRSS /proc/1234/status           # cuánta memoria usa

Eso es lo que herramientas como lsof consultan internamente. Truco provechoso: si se borra por accidente un archivo que un programa aún mantiene abierto, su contenido permanece accesible en /proc/PID/fd/ mientras no lo cierre, y puede recuperarse copiándolo de allí.

Contenedores

Un contenedor de Podman o Docker manipula, en gran medida, el árbol de archivos. Su /proc es propio y solo enseña los procesos de dentro: al montarlo en un espacio de nombres de procesos, queda limitado a ese ámbitoref. Para habilitar un dispositivo se entrega su archivo de /dev (--device /dev/ttyUSB0). Y si un contenedor debe controlar Docker, se le monta /var/run/docker.sock, un socket con nombre que abre la puerta del servicio. Montar ese archivo le concede, en la práctica, permisos de administrador sin restricciones sobre el equiporef.

Copias de seguridad y discos

dd clona un disco completo porque el disco funciona como archivo. Mediante una tubería, la copia viaja a otro equipo sin necesidad de un archivo intermedio:

sudo dd if=/dev/sdX bs=4M status=progress | gzip | ssh usuario@servidor 'cat > disco.img.gz'

dd vuelca el disco, gzip comprime esa salida, ssh la cifra y la manda, y cat la guarda al final. Cuatro aplicaciones ajenas entre sí, unidas por tuberías. Si hay particiones en uso y montadas, la copia puede quedar incoherente: conviene desmontar el disco o arrancar desde un USB.

Todo se aprende una vez

Alguien que domine |, >, grep y cat para tratar archivos de texto puede luego clonar un disco, vigilar la batería, consultar la CPU o depurar un proceso. No cambian las herramientas; solo varía la ruta. La lista de los comandos de GNU/Linux que más se usan los reúne.

Por eso Linux «se siente» diferente: no gracias a una aplicación concreta, sino a que casi todo puede inspeccionarse con los mismos cuatro o cinco comandos.