Capítulo 1: Introducción, Filosofía y Preparación del Medio↑ Inicio

Bienvenido a "El Gran Libro de Arch Linux". Este manual no es simplemente un tutorial para que logres instalar un sistema operativo y te olvides de él; es un viaje arquitectónico. Arch Linux no es un producto terminado, es un conjunto de herramientas (un toolkit) diseñado para construir tu propio sistema operativo a medida. Si estás aquí, probablemente estés cansado de distribuciones que toman decisiones por ti, que instalan docenas de servicios en segundo plano que no utilizas y que ocultan los engranajes internos bajo pesadas interfaces gráficas.

En este capítulo fundacional, exploraremos la historia de Arch, los pilares filosóficos inquebrantables que dictan su desarrollo, las implicaciones reales del modelo Rolling Release en entornos de producción, y cómo preparar tu medio de instalación utilizando las mejores prácticas de la industria.

1.1 Historia y Nacimiento de una Idea↑ Inicio

Arch Linux fue concebido en marzo de 2002 por Judd Vinet, un programador y músico canadiense. Vinet se inspiró profundamente en una distribución minimalista llamada CRUX. Aunque apreciaba la elegancia y la construcción desde el código fuente de CRUX (y de Gentoo), Vinet quería algo más pragmático: un sistema que mantuviera esa pureza estructural pero que utilizara paquetes binarios precompilados para ahorrarle al usuario las horas masivas de compilación que requería Gentoo.

Así nació pacman (Package Manager), escrito originalmente en C por el propio Vinet. El objetivo era simple: rastrear las dependencias con precisión quirúrgica e instalar archivos binarios preempaquetados de forma increíblemente rápida. Desde 2007, Aaron Griffin tomó el relevo como líder del proyecto, seguido por Levente Polyak. Hoy en día, Arch Linux es un proyecto masivo apoyado por la comunidad, pero sigue manteniendo la visión original intacta.

1.2 La Filosofía: The Arch Way↑ Inicio

En el ecosistema de Arch Linux, la documentación no es una sugerencia, es la ley. Todo el proyecto se rige por una serie de principios conocidos informalmente como The Arch Way. Comprenderlos te evitará muchas frustraciones.

1.2.1 Simplicidad (KISS - Keep It Simple, Stupid)

En el contexto de Arch, la "simplicidad" no significa "fácil de usar para tu abuela". No significa que haya botones grandes y asistentes (wizards) que hagan el trabajo por ti. De hecho, para Arch, esos asistentes añaden complejidad. La simplicidad se define desde un punto de vista técnico e interno. Un sistema simple es aquel que tiene la menor cantidad posible de modificaciones respecto al código original (vanilla). Arch Linux entrega el software tal como sus desarrolladores originales (upstream) lo diseñaron. No hay parches masivos de Arch, no hay configuraciones ocultas, y los scripts de inicio no hacen "magia". Si quieres que un demonio se ejecute, debes escribir el comando para habilitarlo. La simplicidad de Arch reside en que sabes exactamente qué está haciendo tu sistema, porque tú lo construiste.

1.2.2 Modernidad (Bleeding Edge)

Arch Linux se esfuerza por mantener las últimas versiones estables del software. Tan pronto como los desarrolladores del Kernel de Linux o del escritorio KDE Plasma liberan una nueva versión y es compilada, aterriza en tus repositorios en cuestión de días u horas. Esto te proporciona soporte inmediato para el hardware más nuevo del mercado y las últimas tecnologías (como PipeWire o Wayland). La desventaja inherente es que estás en la "vanguardia sangrienta" (Bleeding Edge); si hay un bug en el código original recién liberado, serás de los primeros en el mundo en experimentarlo.

1.2.3 Pragmatismo

Mientras que el proyecto GNU y distribuciones como Trisquel tienen una estricta postura moral que prohíbe cualquier software que no sea de código abierto, Arch es profundamente pragmático. Si bien prefiere el software libre por razones técnicas y éticas, no dudará en proporcionar drivers privativos (como los de las tarjetas gráficas NVIDIA) o firmware binario cerrado si eso es lo que el hardware del usuario necesita para funcionar correctamente. Las decisiones se toman basándose en el consenso técnico y la usabilidad práctica, no en el dogma político.

1.2.4 Centrado en el Usuario (User-Centric vs User-Friendly)

Las distribuciones como Ubuntu o Linux Mint son User-Friendly (Amigables con el usuario): intentan anticiparse a las necesidades del usuario, autoconfiguran impresoras, montan discos USB automáticamente e instalan suites ofimáticas por defecto. Arch Linux es User-Centric (Centrado en el usuario): confía plenamente en la inteligencia y capacidad técnica de su usuario. Asume que estás dispuesto a leer el manual, investigar los problemas y tomar el control total. Arch no te dice qué escritorio usar, simplemente te proporciona las piezas de Lego para que tú lo construyas. Eres el arquitecto.

1.3 El Modelo Rolling Release vs. Fixed Release↑ Inicio

Entender el ciclo de vida de tu sistema operativo es crucial para su mantenimiento. La industria del software utiliza principalmente dos modelos de distribución de actualizaciones.

1.3.1 El Modelo Fixed Release (Lanzamiento Fijo)

Utilizado por Debian, Ubuntu, Fedora y Windows.

• Funcionamiento: Cada X meses o años, se lanza una versión (Ej. Ubuntu 22.04). Durante el ciclo de vida de esa versión, el software principal (Kernel, Entorno de Escritorio, bibliotecas base) se congela. Si Firefox lanza una nueva característica, Ubuntu no te la da inmediatamente; solo recibirás parches de seguridad para la versión antigua que venía con el sistema.
• Ventajas: Estabilidad extrema. Como nada cambia, las cosas no se rompen de forma inesperada. Ideal para servidores críticos de grado bancario o aeroespacial.
• Desventajas: El software se vuelve obsoleto rápidamente. Para obtener nuevas funciones, debes realizar una "Actualización de Versión" masiva (Ej. pasar a Ubuntu 24.04), lo cual a menudo implica que gigabytes de dependencias cambien de golpe, corriendo un alto riesgo de romper el sistema.

1.3.2 El Modelo Rolling Release (Lanzamiento Continuo)

Utilizado por Arch Linux, Gentoo y openSUSE Tumbleweed.

• Funcionamiento: No existen versiones como "Arch Linux 2024". Arch Linux es un flujo constante de actualizaciones fluidas. Instalas el sistema una sola vez. A partir de ese momento, ejecutas tu gestor de paquetes periódicamente, y cada paquete individual se actualiza a su última versión.
• Ventajas: Tienes un sistema moderno para siempre ("Install once, update forever"). El rendimiento mejora con las nuevas versiones del kernel. Solucionas vulnerabilidades de seguridad (Zero-Days) instantáneamente.
• Desventajas: Requiere mantenimiento activo. No puedes dejar un equipo con Arch apagado durante 8 meses, encenderlo, y lanzar una actualización; los cambios acumulados en las bibliotecas de C o Python chocarán entre sí y el sistema requerirá intervención manual. Además, la responsabilidad de probar que una actualización no rompa un flujo de trabajo muy específico recae en el usuario.

1.4 Comparativa: ¿Dónde encaja Arch en el Ecosistema?↑ Inicio

• Frente a Ubuntu / Pop!_OS: Estas distros son excelentes para recién llegados o desarrolladores que quieren un entorno listo en 10 minutos. Sin embargo, su uso intensivo de paquetes Snap y PPAs (Personal Package Archives) a menudo crea sistemas fracturados (Franken-Debians). Arch elimina los PPAs y unifica todo bajo el AUR.
• Frente a Debian: Debian es la roca inamovible de la estabilidad. Es insuperable para servidores donde el tiempo de actividad (uptime) se mide en años. Arch es todo lo contrario: está vivo, se mueve rápido y es ideal para estaciones de trabajo de desarrolladores, gaming y servidores web ágiles.
• Frente a Fedora: Fedora es el término medio. Tiene software muy nuevo, pero sigue un modelo Fixed Release de 6 meses respaldado por Red Hat. Arch le gana a Fedora en la inmensidad de su repositorio comunitario (el AUR) y en la ligereza de su instalación base (Fedora tiende a preinstalar muchos servicios corporativos como SELinux o firewalld por defecto).
• Frente a Gentoo: En Gentoo compilas absolutamente todo desde el código fuente para tu procesador específico. Toma días instalarlo. Arch te da paquetes binarios precompilados, ofreciendo un 99% de la personalización de Gentoo en una fracción del tiempo de instalación.

1.5 La Arch Wiki: El Oráculo del Pingüino↑ Inicio

No se puede enfatizar lo suficiente la importancia de la Arch Wiki (wiki.archlinux.org). Es, por consenso unánime en la comunidad informática, la documentación de sistemas GNU/Linux más exhaustiva, mejor mantenida y técnicamente precisa de internet. Los usuarios de casi todas las demás distribuciones terminan en la Arch Wiki cuando buscan en Google cómo solucionar un problema de red, compilar un kernel o configurar el Bluetooth.

Reglas de Oro del Usuario de Arch:

1. Si tienes un problema o quieres instalar algo nuevo, busca primero en la Wiki.
2. Si la Wiki te remite a una página de manual (man page), léela (man nombredelcomando).
3. Solo si la Wiki y el manual no resuelven tu duda, acude a los foros o a Reddit. La comunidad espera que hayas hecho tu tarea antes de preguntar; la frase "Read The F*cking Manual (RTFM)" no es un insulto en Arch, es un recordatorio de la filosofía.

1.6 Preparación del Medio de Instalación (Live USB)↑ Inicio

Para comenzar nuestra travesía, necesitamos descargar y preparar el medio de instalación. La ISO de Arch Linux es un sistema Linux completamente funcional y comprimido que arranca desde la memoria RAM.

1.6.1 Descarga y Verificación Criptográfica

Dirígete a la página oficial de descargas: https://archlinux.org/download/. Se recomienda encarecidamente utilizar el protocolo BitTorrent o Magnet link. Esto no solo alivia la carga de los servidores de la organización, sino que el protocolo Torrent verifica automáticamente la integridad de los fragmentos descargados mediante hashes SHA-1.

Si descargas mediante descarga directa (HTTP), debes verificar la integridad y autenticidad del archivo ISO. Un archivo corrupto causará fallos inexplicables durante la instalación. Peor aún, un atacante podría haber inyectado malware en la ISO (ataque a la cadena de suministro).

Para verificar, descarga la ISO y el archivo de firma PGP (terminado en .sig) en la misma carpeta. En una máquina Linux o macOS existente, ejecuta:

# Importar la llave pública del desarrollador de Arch (Pierre Schmitz)
gpg --keyserver-options auto-key-retrieve --verify archlinux-version-x86_64.iso.sig

La salida debe decir "Good signature from...". Si dice "BAD signature", el archivo está corrupto o comprometido. Bórralo inmediatamente.

1.6.2 Creación del USB Booteable (Flasheo a bajo nivel)

Las herramientas que simplemente extraen el contenido de la ISO a un USB formateado en FAT32 no funcionarán con Arch, ya que la ISO de Arch es un híbrido (contiene sectores de arranque para UEFI y para BIOS simultáneamente). Debemos hacer una copia bit a bit (block-level copy).

Método 1: Desde sistemas Linux (La herramienta dd) El comando dd (Data Duplicator, o jocosamente conocido como Disk Destroyer) es la forma más potente y peligrosa de grabar imágenes. Un error en la letra del disco borrará irreversiblemente tu sistema actual.

1. Averigua la ruta de tu USB conectado usando lsblk. Supongamos que es /dev/sdb o /dev/sdc (NUNCA uses un número de partición como sdb1, usa la unidad raíz sdb).
2. Asegúrate de que no esté montado: sudo umount /dev/sdb*
3. Graba la imagen:

    sudo dd if=archlinux-2024.xx.xx-x86_64.iso of=/dev/sdb bs=4M status=progress oflag=sync

• if: Input File (tu ISO).
• of: Output File (tu USB crudo).
• bs=4M: Escribe en bloques de 4 megabytes para mayor velocidad.
• status=progress: Muestra una barra de progreso.
• oflag=sync: Garantiza que todos los datos en la memoria caché se escriban físicamente en el USB antes de que el comando termine.

Método 2: Desde sistemas Windows Para usuarios que vienen desde Windows, se recomienda Rufus o BalenaEtcher.

1. En Rufus, selecciona tu memoria USB.
2. Selecciona el archivo ISO de Arch Linux.
3. Al darle a "Empezar", Rufus te lanzará una advertencia sobre el formato "ISOHybrid". Es obligatorio que selecciones la opción "Escribir en modo Imagen DD (DD Image mode)". Si seleccionas el modo ISO, el USB no arrancará.

Método 3: Ventoy (El estándar para profesionales) Si trabajas frecuentemente con múltiples sistemas operativos, Ventoy es una revelación. Instalas Ventoy en tu USB una sola vez, y te creará una partición de datos. A partir de ese momento, simplemente copias y pegas (arrastras) todos los archivos .iso (Arch, Windows, Ubuntu, herramientas de rescate) a esa partición. Al arrancar el USB, Ventoy te mostrará un menú permitiéndote elegir qué ISO quieres bootear. Arch Linux soporta el arranque mediante Ventoy de forma nativa.

1.6.3 Configuración de la Placa Base (UEFI)

Antes de insertar tu USB, debes preparar la máquina objetivo:

1. Enciende el equipo y presiona repetidamente la tecla del firmware (suele ser F2, F12, Supr/Del, o Esc).
2. Desactiva Secure Boot (Arranque Seguro). Arch Linux, a diferencia de Fedora o Ubuntu, no compra claves criptográficas a Microsoft para firmar su gestor de arranque por defecto. Si el Secure Boot está activo, la placa base se negará a cargar el USB de Arch. (En capítulos avanzados, aprenderás a firmar tu propio kernel y reactivarlo).
3. Desactiva el Fast Boot de Windows si haces dual-boot. Fast Boot realmente no apaga Windows, lo hiberna, dejando los discos duros bloqueados e inaccesibles (Read-Only) para Linux.
4. Asegúrate de que el modo de control de almacenamiento SATA esté en AHCI y no en RAID/RST (Intel Rapid Storage Technology). El kernel de Linux necesita ver los discos en crudo a través de AHCI.
5. Coloca el USB en el primer lugar de la prioridad de arranque (Boot Order).

Guarda los cambios, reinicia y estarás listo para adentrarte en el prompt de la terminal negra. Si has llegado hasta aquí, posees el conocimiento teórico necesario; el Capítulo 2 (que ya hemos generado) te espera para ensuciarte las manos con el particionado físico.

Capítulo 2: Instalación Base - Fundamentos y Arquitectura de Sistemas↑ Inicio

La instalación de Arch Linux es a menudo vista por los recién llegados como un obstáculo insuperable, un rito de paso arcaico. Sin embargo, para el profesional de sistemas o el desarrollador, es una clase magistral sobre cómo se construye un sistema operativo GNU/Linux desde sus cimientos. A diferencia de los instaladores automatizados como Calamares o Anaconda, que abstraen la complejidad y toman decisiones arquitectónicas por ti, el proceso "The Arch Way" requiere que comprendas cada componente de la pila tecnológica: desde el firmware de la placa base hasta el gestor de paquetes.

En este extenso capítulo, no solo aprenderás los comandos necesarios para instalar el sistema, sino la teoría y el porqué detrás de cada uno de ellos. Al finalizar, estarás capacitado no solo para instalar Arch, sino para rescatar servidores Linux caídos, diseñar arquitecturas de almacenamiento seguras y comprender el proceso de arranque (boot process) a nivel empresarial.

2.1 El Entorno Live y el Proceso de Arranque Inicial↑ Inicio

Cuando insertas tu medio de instalación USB y enciendes el equipo, entras en una fase crítica controlada por el firmware de tu placa base. Existen dos paradigmas principales de firmware en la computación moderna, y comprender la diferencia es vital, ya que dictará cómo particionaremos nuestros discos más adelante.

2.1.1 BIOS Legacy vs. UEFI

BIOS (Basic Input/Output System) y MBR

El BIOS es el estándar de firmware introducido en la década de 1980. Cuando un sistema BIOS arranca, ejecuta un chequeo de hardware (POST) y luego busca el MBR (Master Boot Record), que es un espacio minúsculo de 512 bytes al principio de tu disco duro. En este pequeñísimo espacio, el gestor de arranque (como GRUB) debe alojar su código principal. Las limitaciones del BIOS y el MBR son severas para los estándares modernos:

• Solo soporta discos de hasta 2 Terabytes.
• Solo permite 4 particiones primarias (requiriendo particiones "extendidas" y "lógicas" para superarlo).
• El arranque es secuencial y, a menudo, lento.

UEFI (Unified Extensible Firmware Interface) y GPT

Introducido masivamente a partir de 2012, UEFI es un mini-sistema operativo por derecho propio. En lugar de buscar código en un pequeño sector de 512 bytes, UEFI busca una partición específica en el disco formateada en FAT32, conocida como EFI System Partition (ESP). Dentro de esta partición, UEFI lee archivos ejecutables (con extensión .efi). El esquema de particionado que acompaña a UEFI es GPT (GUID Partition Table), el cual:

• Soporta discos de hasta 9.4 Zettabytes.
• Permite hasta 128 particiones por defecto en Windows/Linux.
• Almacena copias de seguridad de la tabla de particiones al final del disco para redundancia en caso de corrupción.

Identificación del entorno en Arch Linux: Al iniciar el USB de Arch, llegarás a una terminal (tty1) logueado como root con un prompt Zsh. El primer paso como administrador es confirmar en qué modo ha arrancado el firmware. Arch Linux monta las variables EFI virtuales en /sys/firmware/efi/efivars. Ejecuta:

ls /sys/firmware/efi/efivars

• Si el directorio existe y muestra cientos de archivos, tu sistema ha arrancado en modo UEFI. Deberás utilizar particionado GPT. Esta guía se centrará en UEFI por ser el estándar absoluto.
• Si arroja un error (No such file or directory), estás en modo BIOS/Legacy. (Si tu equipo es moderno pero arrancó en BIOS, es recomendable reiniciar, entrar a la configuración de la placa base y forzar el modo UEFI "Solo UEFI" o deshabilitar "CSM / Compatibility Support Module").

2.1.2 El Entorno Zsh de Archiso

El sistema en el que te encuentras es efímero. Corre íntegramente en la memoria RAM (tmpfs) de tu computadora. Cualquier cambio que hagas aquí (excepto escribir en los discos físicos) desaparecerá al reiniciar. La ISO oficial de Arch Linux (archiso) proporciona un entorno rico en herramientas de diagnóstico: iproute2, vim, nano, parted, cryptsetup y utilidades de recuperación de datos.

El teclado, por defecto, se configura en la distribución estadounidense (US). Trabajar con símbolos como /, - o : en una distribución incorrecta es frustrante. Para cargarlo en español:

# Para teclado de España (incluye la Ñ y símbolos correctos)
loadkeys es

# Para teclado latinoamericano
loadkeys la-latin1

Dato técnico: loadkeys interactúa con el subsistema kbd del kernel de Linux, cargando un mapa de teclas .map.gz almacenado en /usr/share/kbd/keymaps/.

2.2 Subsistema de Red: Conectividad y Sincronización↑ Inicio

Arch Linux no incluye los paquetes del sistema operativo en el archivo ISO de instalación (a diferencia de Ubuntu o Debian). La ISO solo contiene el entorno base en vivo. Por lo tanto, una conexión a internet estable es el requisito no negociable más importante. Todos los binarios y dependencias serán descargados directamente desde los repositorios globales durante la fase pacstrap.

2.2.1 Interfaces de Red (Ethernet)

El kernel de Linux, a través de udev, asigna nombres predecibles a las interfaces de red (Predictable Network Interface Names). En lugar de los antiguos eth0 o wlan0, verás nombres como enp3s0 (Ethernet, bus PCI 3, slot 0) o wlp2s0 (Wireless).

Para listar tus interfaces de red y verificar su estado:

ip link

Si conectas un cable Ethernet, el demonio systemd-networkd que corre en el Live USB detectará el enlace y solicitará automáticamente una dirección IP a tu router mediante DHCP. Puedes verificar que tienes IP con:

ip -brief address show

Y probar la resolución de DNS y conectividad:

ping -c 4 archlinux.org

2.2.2 Redes Inalámbricas (Wi-Fi) con iwd

Si dependes de Wi-Fi, la ISO de Arch incluye iNet Wireless Daemon (iwd), escrito por Intel. Es un demonio moderno y extremadamente rápido que reemplaza al antiguo wpa_supplicant.

Para configurar la conexión de forma interactiva, invoca el cliente:

iwctl

El prompt cambiará a [iwd]#. La secuencia lógica de comandos es:

1. Identificar el adaptador de radio:

[iwd]# device list Supongamos que el nombre del dispositivo (Name) es wlan0.

1. Activar el escáner de redes:

[iwd]# station wlan0 scan

1. Listar las redes disponibles:

[iwd]# station wlan0 get-networks

1. Conectarse a la red (SSID):

[iwd]# station wlan0 connect "Nombre De Tu Red WiFi" Si la red tiene espacios en el nombre, usa comillas. Te pedirá el "Passphrase" (contraseña). Tras introducirla y presionar enter, sal del prompt de iwd usando exit o Ctrl+D.

Troubleshooting Wi-Fi: Si tu adaptador no aparece en device list, es altamente probable que requiera firmware propietario que no está incluido en la ISO por defecto (común en ciertos chips Broadcom o adaptadores USB Realtek muy específicos). En ese caso, la única solución es usar un cable Ethernet o anclar (tethering) el internet de tu teléfono móvil mediante un cable USB (Linux detectará el teléfono como una interfaz de red cableada automáticamente).

2.2.3 Criptografía y Sincronización Temporal (NTP)

Antes de descargar paquetes de internet, el reloj de tu sistema debe ser preciso. ¿Por qué? El gestor de paquetes de Arch (pacman) verifica las firmas criptográficas GPG de cada paquete descargado para prevenir ataques Man-in-the-Middle y garantizar que el paquete proviene legítimamente de un desarrollador de Arch. Si el reloj de tu placa base tiene meses o años de retraso, los certificados digitales serán evaluados como "no válidos" o "caducados", y pacman se negará rotundamente a instalar nada, devolviendo errores de "corrupted package" o "invalid PGP signature".

Para sincronizar la hora usando el Network Time Protocol (NTP):

timedatectl set-ntp true

Para verificar que el sistema se ha sincronizado correctamente:

timedatectl status

Busca la línea que dice NTP service: active y System clock synchronized: yes. Además, asegúrate de que el "Universal time (UTC)" sea correcto. Linux prefiere que el reloj por hardware (RTC) de la placa base esté en UTC y calcula tu hora local sumando o restando según tu zona horaria.

2.3 Arquitectura de Almacenamiento y Particionado Avanzado↑ Inicio

El particionado es el diseño de los cimientos de nuestra casa. Un mal diseño aquí limitará la flexibilidad futura de tu servidor o estación de trabajo. Linux trata todo en el sistema operativo como un archivo, y los discos duros no son la excepción. Residen en el directorio /dev/ (devices).

2.3.1 Nomenclatura de Bloques (Block Devices)

Antes de modificar los discos, debemos identificarlos con absoluta certeza. Equivocarte de dispositivo significa la pérdida irrecuperable de datos. Ejecuta el comando para listar dispositivos de bloques:

lsblk -f

(El flag -f muestra los sistemas de archivos existentes y sus UUIDs).

• SATA (Discos duros mecánicos y SSDs tradicionales): Se denominan sd (SCSI disk). El primer disco es /dev/sda, el segundo /dev/sdb. Las particiones se numeran: /dev/sda1, /dev/sda2.
• NVMe (SSDs modernos PCIe): Tienen su propia nomenclatura para reducir la latencia de la capa SCSI. Se denominan nvmeXnY (donde X es el controlador e Y el namespace). Ejemplo: /dev/nvme0n1. Las particiones añaden una 'p': /dev/nvme0n1p1.
• eMMC (Común en portátiles baratos o Raspberry Pi): Se denominan /dev/mmcblk0.
• Bucle (Loop devices): Verás muchos /dev/loopX. Estos son archivos de la propia ISO cargados en la RAM y puedes ignorarlos por completo.

A partir de este punto, asumiremos que estamos instalando Arch Linux en el disco SSD principal NVMe: /dev/nvme0n1. Si tienes un disco SATA, simplemente sustituye la ruta por /dev/sda en los comandos pertinentes.

2.3.2 LVM, LUKS y Esquemas de Particionamiento

Existen múltiples formas de dividir tu disco, que van desde lo simple hasta la arquitectura empresarial:

1. Esquema Básico (Recomendado para principiantes):

• Partición EFI (Boot) - FAT32.
• Partición Swap - Linux Swap.
• Partición Root (/) - Ext4 o Btrfs.

1. LVM (Logical Volume Manager):

LVM introduce una capa de abstracción sobre los discos físicos. En lugar de tener particiones estáticas, agrupas varios discos físicos (Physical Volumes) en un "pool" gigante (Volume Group), y de ahí extraes "Volúmenes Lógicos" elásticos. Si en el futuro te quedas sin espacio en /home, puedes comprar otro disco duro, añadirlo al Volume Group y expandir la partición /home en caliente, sin reiniciar.

1. LUKS (Linux Unified Key Setup) - Cifrado de disco completo (FDE):

Si se trata de un ordenador portátil, el cifrado es mandatorio en entornos profesionales. LUKS crea un contenedor cifrado a nivel de bloque (block-level encryption). Sin la contraseña de descifrado introducida en el gestor de arranque, los datos en el SSD son ruido aleatorio indescifrable, protegiendo tus claves SSH, código fuente y datos de clientes en caso de robo del hardware.

En este manual, abordaremos el Esquema Básico con particiones estáticas, pero adaptado a las mejores prácticas actuales.

2.3.3 Destrucción de la tabla anterior y creación de GPT

Utilizaremos cgdisk (interfaz visual basada en ncurses para discos GPT) o fdisk. El estándar clásico y más universal es fdisk.

Inicia fdisk apuntando a tu disco objetivo:

fdisk /dev/nvme0n1

En el prompt interactivo de fdisk:

1. Crear una nueva tabla de particiones vacía (Borrado total): Pulsa g (crea una nueva tabla GPT). ¡Atención! A partir de este momento, has marcado el disco para borrar todas las particiones anteriores.

1. Crear la partición EFI (Boot):

• Pulsa n (nueva partición).
• Número de partición: 1 (presiona enter).
• Primer sector: Presiona enter (usa el inicio por defecto).
• Último sector: Escribe +1G y presiona enter. (Aunque el mínimo absoluto son 260MB para Windows y 512MB para Linux, 1GB se recomienda hoy en día si planeas instalar múltiples kernels de Linux simultáneamente, ya que los archivos initramfs modernos son pesados).
• Cambiar el tipo: Pulsa t, luego 1 para seleccionar tipo "EFI System".

1. Crear la partición Swap (Intercambio):

La memoria Swap actúa como un desbordamiento cuando tu RAM física se llena, previniendo que el kernel aplique OOM Killer (cierre forzoso de aplicaciones). También es indispensable si quieres utilizar la función de Hibernación (Suspender a disco).

• Pulsa n.
• Número de partición: 2 (enter).
• Primer sector: enter.
• Último sector: Escribe +8G (O el equivalente a tu memoria RAM si planeas hibernar. Por ejemplo, si tienes 16GB de RAM, puedes poner +16G).
• Cambiar el tipo: Pulsa t, selecciona la partición 2, y escribe 19 (Linux Swap).

1. Crear la partición Root (Raíz - /):

Aquí residirá todo el sistema operativo, binarios, configuraciones y tus archivos personales (si no haces una partición separada para /home, lo cual es más sencillo para instalaciones modernas de escritorio).

• Pulsa n.
• Número de partición: 3 (enter).
• Primer sector: enter.
• Último sector: enter (al no poner un límite, usará todo el espacio libre restante en el disco, lo cual es ideal).
• El tipo por defecto será "Linux filesystem" (tipo 20), así que no es necesario cambiarlo.

1. Verificación y Escritura:

Pulsa p para imprimir (print) la tabla que acabas de diseñar. Deberías ver:

• /dev/nvme0n1p1 - 1G - EFI System
• /dev/nvme0n1p2 - 8G - Linux swap
• /dev/nvme0n1p3 - (Resto del tamaño) - Linux filesystem

Si estás seguro y todo está correcto, pulsa w (write) para escribir los cambios al disco y salir. Si te equivocaste, pulsa q para salir sin guardar y volver a empezar.

2.4 Sistemas de Archivos (Filesystems) y Formateo↑ Inicio

Las particiones crudas no sirven para nada hasta que se les imprime un sistema de archivos, que dicta la lógica algorítmica de cómo se guardan, indexan y leen los datos. Linux brilla en la variedad y especialización de sus filesystems.

2.4.1 Teoría de Sistemas de Archivos: Ext4 vs Btrfs vs XFS

• Ext4 (Fourth Extended Filesystem): Es el abuelo confiable. Presente desde 2008, es robusto, estable como una roca y casi inmune a la corrupción por cortes de energía gracias a su diseño de "journaling". Si quieres un sistema de instalar y olvidar, Ext4 es la elección por defecto.
• Btrfs (B-Tree Filesystem): Desarrollado por Oracle y SUSE, es un sistema de archivos de "próxima generación" (Copy-on-Write). Soporta snapshots (instantáneas del sistema en milisegundos), compresión en vuelo (zstd transparente) y subvolúmenes. Es el filesystem por defecto en Fedora y Garuda Linux. Permite un nivel de recuperación ante desastres increíble (puedes restaurar el sistema operativo a cómo estaba hace 5 minutos), pero requiere un aprendizaje más profundo para gestionar su espacio, ya que las snapshots consumen disco silenciosamente.
• XFS: Creado por Silicon Graphics. Es el rey indiscutible para el manejo de archivos masivamente grandes (como bases de datos empresariales o edición de vídeo 8K) debido a su asignación de ancho de banda y capacidad paralela de I/O. Es el estándar en Red Hat Enterprise Linux.

Para este manual profesional de despliegue, usaremos Ext4 por su resiliencia y universalidad, que reduce la complejidad en entornos de producción y escritorio estándar.

2.4.2 Formateo de las Particiones

La utilidad para dar formato es mkfs (Make File System).

1. La partición EFI (Boot): La especificación UEFI dictamina de forma estricta que la partición EFI debe estar formateada en FAT32, un sistema de archivos muy antiguo de Microsoft, porque es el único que los firmwares de placa base saben leer nativamente.

mkfs.fat -F 32 /dev/nvme0n1p1

(Nota: -F 32 especifica que se use FAT32, no FAT16. Es un error común olvidarlo).

2. La partición Swap: Swap tiene su propia estructura especializada. Se inicializa y luego se activa inmediatamente para que el entorno Live USB pueda usarla si fuese necesario.

mkswap /dev/nvme0n1p2
swapon /dev/nvme0n1p2

3. La partición Root (Ext4): Formatearemos el grueso del disco con Ext4. Este proceso construirá la tabla de inodos y el journal.

mkfs.ext4 /dev/nvme0n1p3

Si has elegido Btrfs (para usuarios avanzados), el comando sería mkfs.btrfs /dev/nvme0n1p3.

2.4.3 Montaje del Árbol de Directorios

Para instalar el sistema, debemos montar nuestras nuevas particiones dentro del árbol de archivos virtual de nuestro Live USB. Por convención, usaremos el directorio /mnt.

El orden es crítico. Siempre monta la partición raíz (/) primero, y luego crea carpetas dentro de ella para montar particiones subordinadas (como boot o home).

Montar Root:

mount /dev/nvme0n1p3 /mnt

Preparar y montar Boot/EFI: En Arch Linux, existen varios debates sobre dónde montar la partición EFI: /mnt/efi, /mnt/boot/efi, o /mnt/boot. Montarlo en /boot directamente es el método más simple y recomendado si usas systemd-boot, y funciona perfectamente con GRUB, ya que permite que los kernels (vmlinuz) se almacenen directamente en la partición FAT32 donde el firmware UEFI tiene acceso directo e irrestricto.

Creamos el directorio en nuestra nueva raíz y montamos la partición:

mkdir /mnt/boot
mount /dev/nvme0n1p1 /mnt/boot

Puedes verificar que tu jerarquía está perfectamente ensamblada con el comando:

lsblk

Deberías ver una estructura jerárquica con /mnt en tu partición 3 y /mnt/boot en la partición 1.

2.5 Instalación del Ecosistema Base (Pacstrap)↑ Inicio

Llegados a este punto, hemos preparado el terreno físico y lógico. Es hora de inyectar el código del sistema operativo. En otras distros, el instalador simplemente copia los archivos de la ISO al disco duro. En Arch, usamos un script llamado pacstrap, que es esencialmente un envoltorio (wrapper) del gestor de paquetes pacman. pacstrap descarga los paquetes más recientes directamente desde los servidores de Arch Linux y los instala (descomprime e inicializa) dentro de la carpeta /mnt. Esto garantiza que, al terminar la instalación, el sistema esté 100% al día con la última versión de todo el software (zero-day update).

2.5.1 Los Mirrors (Espejos) de Descarga

pacstrap usará la lista de servidores (mirrors) definida en /etc/pacman.d/mirrorlist. En el pasado, los usuarios tenían que buscar manualmente los servidores más rápidos de su país para evitar descargas a velocidades de módem de los años 90. Hoy en día, la ISO de Arch incluye un servicio en segundo plano llamado reflector que automáticamente evalúa los espejos mundiales, ordena los 20 más rápidos, y actualiza el archivo mirrorlist por ti. Si tu conexión está activa, este paso ya está optimizado automáticamente.

2.5.2 Selección de Paquetes Nucleares

El comando pacstrap requiere que le pases explícitamente qué grupos de paquetes o paquetes individuales formarán tu sistema operativo. El minimalismo de Arch exige que pienses bien qué necesitas.

Los elementos fundamentales de un sistema GNU/Linux moderno son:

1. base: Es un metapaquete vacío que indica las dependencias mínimas requeridas. Instalará el sistema de inicialización systemd, pacman, bibliotecas de C (glibc), y utilidades GNU de núcleo duro (coreutils) como cp, ls, cat. Nota importante: Desde 2019, el metapaquete base ya no incluye un Kernel ni un editor de texto ni soporte de red. Debes instalarlos explícitamente.
2. El Kernel (linux): Descargará la imagen del núcleo y sus módulos. Si eres un administrador de servidores, puedes optar aquí mismo por linux-lts. Nosotros usaremos el estable linux.
3. Firmware (linux-firmware): Código binario propietario que los fabricantes de hardware requieren para que las tarjetas gráficas, adaptadores Wi-Fi y chips de Bluetooth funcionen. Sin esto, podrías tener un kernel funcionando, pero sin capacidad de hablar con tu hardware.
4. Editores (vim o nano): Indispensables para modificar archivos de configuración en el siguiente paso. Instala el que domines. (Nano es intuitivo, Vim es poderoso).
5. Herramientas de red (networkmanager e iwd): Si no las instalas en este momento, al reiniciar tu nueva máquina te encontrarás sin internet y completamente incapaz de instalar el entorno gráfico.
6. Microcódigo de la CPU (intel-ucode o amd-ucode): Las CPUs modernas son tan complejas que tienen su propio software interno con bugs (recordemos Spectre o Meltdown). El sistema operativo puede inyectar parches a la CPU durante el arranque. Dependiendo del procesador de tu máquina física, debes instalar el paquete correspondiente. Si tu procesador es Intel, usa intel-ucode. Si es AMD, usa amd-ucode.

Ejecuta el despliegue con el comando de orquestación final (asumamos una CPU Intel y Nano como editor):

pacstrap -K /mnt base linux linux-firmware nano networkmanager iwd intel-ucode

(El flag -K inicializa un anillo de claves PGP vacío y nuevo en el sistema destino, asegurando un entorno criptográfico limpio para pacman en la nueva instalación).

El proceso descargará entre 400MB y 800MB dependiendo de los paquetes, los verificará, y los instalará en /mnt. Observa la salida en la terminal; es una radiografía de los bloques de construcción de Linux pasando ante tus ojos.

2.6 Persistencia del Montaje (fstab)↑ Inicio

Si reinicias ahora, tu nuevo sistema operativo no tendrá idea de qué disco representa la Raíz y dónde está el Boot. Necesitamos generar el archivo de configuración fstab (File System Table). El kernel lee /etc/fstab durante el arranque para saber qué particiones montar y con qué parámetros (solo lectura, habilitar cuotas, deshabilitar caché de tiempos de acceso, etc.).

Históricamente, fstab se escribía usando las rutas estáticas de los dispositivos (ej. /dev/sda1). Esto era catastrófico si conectabas un disco USB y el kernel decidía que el USB ahora era sda y tu disco duro pasaba a ser sdb. Para solucionar este desastre arquitectónico, se utilizan los UUID (Universally Unique Identifier), unas cadenas de 128 bits garantizadas para ser únicas en el universo, escritas físicamente en los metadatos del sistema de archivos cuando lo formateas.

Arch proporciona la herramienta genfstab para automatizar esto detectando qué está montado actualmente en /mnt y traduciéndolo a formato UUID.

Ejecutamos:

genfstab -U /mnt >> /mnt/etc/fstab

(Explicación de sintaxis: -U fuerza el uso de UUIDs. >> es un operador de redirección del shell (bash/zsh) que toma la salida del comando genfstab (el texto generado) y lo agrega al final del archivo /mnt/etc/fstab, creándolo si no existiera).

Auditoría y Verificación del Fstab: En Linux, la confianza es buena, pero el control es mejor. Nunca continúes sin auditar archivos de configuración generados automáticamente.

cat /mnt/etc/fstab

Deberías ver una estructura similar a esta:

# /dev/nvme0n1p3
UUID=3a4b5c6d-7e8f-9a0b-1c2d-3e4f5a6b7c8d	/         	ext4      	rw,relatime	0 1

# /dev/nvme0n1p1
UUID=1234-ABCD      	/boot     	vfat      	rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro	0 2

# /dev/nvme0n1p2
UUID=9f8e7d6c-5b4a-3f2e-1d0c-b9a8f7e6d5c4	none      	swap      	defaults  	0 0

Analicemos rápidamente los campos:

• Device: El UUID de la partición.
• Mountpoint: Dónde se montará en el árbol (/, /boot, none para swap).
• FSType: El tipo de sistema de archivos (ext4, vfat, swap).
• Options: Opciones especiales del kernel. rw (lectura/escritura), relatime (una optimización crucial que evita que el disco escriba metadatos cada vez que se lee un archivo, salvando incontables ciclos de vida en los SSD).
• Dump & Pass: El último número indica el orden en que la utilidad fsck (File System Check) comprobará los discos en busca de errores al arrancar. La partición Raíz siempre debe ser 1, y las demás particiones 2 (o 0 para desactivar el chequeo).

Si el archivo fstab se ve correcto y no está vacío, puedes dar un gran suspiro de alivio. La base física, lógica y binaria del sistema operativo está asentada y consolidada en tu hardware.

En el próximo y crucial capítulo (Capítulo 3), utilizaremos el poderoso concepto de "Chroot" para teleportarnos mentalmente dentro de este nuevo sistema y realizar la configuración final (idioma, zona horaria, usuarios) y, sobre todo, instalar el cerebro que orquestará el encendido: el gestor de arranque GRUB.

Capítulo 3: El Chroot y la Configuración Interna↑ Inicio

Tras ejecutar pacstrap en el capítulo anterior, hemos descargado cientos de megabytes de software binario, depositándolo ordenadamente en el disco duro (montado en /mnt). Sin embargo, en este momento, todavía estamos utilizando la memoria RAM y el Kernel del Live USB temporal.

Para configurar tu nuevo sistema, tienes que entrar en él. Tienes que engañar a los comandos que ejecutes para que crean que el disco duro es el universo entero, ocultando por completo la existencia del USB. Este truco de magia informática se llama Chroot (Change Root).

3.1 La Teoría y Práctica del Chroot↑ Inicio

chroot es una operación de los sistemas operativos tipo Unix que cambia el directorio raíz aparente (/) para el proceso actual y todos sus subprocesos (hijos). Cualquier programa que se ejecute dentro del entorno chroot no puede ver, acceder ni modificar archivos fuera del nuevo directorio raíz. Es una de las primeras formas de "aislamiento" (sandboxing) que existieron, precursora de los contenedores Docker modernos.

En Arch Linux, utilizamos una versión vitaminada llamada arch-chroot, proporcionada por el paquete de scripts de instalación.

¿Por qué arch-chroot y no el chroot normal de bash?

El comando chroot crudo requiere que, antes de entrar al entorno, montes manualmente sistemas de archivos virtuales vitales del Kernel (API file systems) como /dev (dispositivos), /proc (información de procesos y kernel), /sys (dispositivos hardware sysfs) y /run (archivos temporales de demonios). Si entraras con un chroot normal sin estos montajes, utilidades como grub-install fallarían estrepitosamente al no poder encontrar discos duros. arch-chroot automatiza el montaje de estos sistemas virtuales (bind mounts) y configura automáticamente resolv.conf para que mantengas la conexión a internet dentro del nuevo entorno.

3.1.1 Ejecución

Simplemente ejecuta:

arch-chroot /mnt

Notarás que el prompt de tu terminal cambia ligeramente (generalmente pasando de un prompt colorido de zsh a uno básico de bash con [root@archiso /]#). ¡Felicidades! Técnicamente acabas de iniciar sesión en tu propio sistema operativo instalado en tu disco NVMe/SATA, utilizando sus propios binarios recién descargados (su propia versión de bash, nano, pacman, etc.). Todos los comandos a partir de este punto se escribirán permanentemente en tu disco.

3.2 Huso Horario y Reloj de Hardware↑ Inicio

Una computadora maneja el tiempo usando dos relojes distintos:

1. System Time (Reloj del Kernel/Sistema): Un reloj virtual en memoria que se reinicia cuando apagas la computadora. Lo mantiene el kernel mientras el sistema está encendido, generalmente sincronizándolo por internet con NTP.
2. Hardware Clock (RTC - Real Time Clock): Un reloj físico alimentado por la pila de botón CR2032 de la placa base. Mantiene la hora cuando el equipo está desenchufado.

3.2.1 Configuración de la Zona Horaria (Timezone)

El sistema necesita saber dónde estás físicamente para sumar o restar horas al reloj universal UTC. Las definiciones de zonas horarias se alojan en el directorio /usr/share/zoneinfo/.

Para listar los continentes y regiones (usa las flechas para navegar, presiona 'q' para salir de la paginación):

ls /usr/share/zoneinfo

Para ver las ciudades de una región (por ejemplo, Europa):

ls /usr/share/zoneinfo/Europe

Creamos un enlace simbólico (un acceso directo que apunta a la definición correcta) en /etc/localtime. Por ejemplo, para Madrid, España:

ln -sf /usr/share/zoneinfo/Europe/Madrid /etc/localtime

(Para América Latina podrías usar America/MexicoCity, America/BuenosAires, America/Bogota, etc.)

3.2.2 Sincronización del Reloj de Hardware (hwclock)

Ahora que el sistema conoce su zona horaria, debemos decirle que escriba esta información y la hora actual en el reloj físico de la placa base, generando automáticamente el archivo /etc/adjtime.

hwclock --systohc

Por defecto, Linux asume que el Hardware Clock está en UTC (Tiempo Universal Coordinado). Esta es la práctica correcta y estándar en servidores. Linux leerá UTC de la placa base y calculará la hora local basándose en el timezone que configuraste.

El Problema del Dual-Boot con Windows: Windows, por razones históricas de compatibilidad con MS-DOS, asume de forma absurda que el reloj de la placa base está en Hora Local (Localtime). Si tienes Windows y Linux instalados, entrarán en una guerra civil: Linux pondrá la placa base en UTC y mostrará tu hora local correcta. Al reiniciar en Windows, este leerá UTC pensando que es tu hora local y mostrará la hora retrasada. Windows la "corregirá" reescribiendo la placa base, y al volver a Linux, Linux se desconfigurará. La solución profesional: No fuerces a Linux a usar Localtime. Abre el editor de registro en Windows (regedit), navega a HKEYLOCALMACHINE\System\CurrentControlSet\Control\TimeZoneInformation y crea un DWORD de 32-bits llamado RealTimeIsUniversal con valor 1. Así fuerzas a Windows a comportarse como un sistema moderno (usando UTC en la placa base).

3.3 Localización del Sistema (Locale) e Idioma↑ Inicio

El "Locale" es una piedra angular en sistemas operativos POSIX. No solo dicta el idioma (español, inglés), sino cómo los programas deben interpretar y clasificar caracteres, cómo formatear los números (coma decimal o punto), la representación de fechas y la codificación de símbolos complejos (UTF-8). Un locale mal configurado resultará en letras con tilde apareciendo como signos de interrogación o cajas extrañas, o scripts de Python rompiéndose al leer archivos de texto.

3.3.1 Generación de Locales (locale.gen)

En Arch Linux, compilas tus propios locales. Primero, le dices al sistema cuáles deseas generar activándolos en el archivo maestro.

Abre el archivo con tu editor (asumimos nano):

nano /etc/locale.gen

Este archivo contiene cientos de opciones comentadas (precedidas por el símbolo #). Busca y descomenta (elimina el #) las opciones que necesites. Se recomienda tener siempre el inglés americano como reserva por temas de compatibilidad de ciertos compiladores. Para un usuario en España:

• en_US.UTF-8 UTF-8
• es_ES.UTF-8 UTF-8

(Si eres de otro país hispanohablante, descomenta tu versión correspondiente, ej. esMX.UTF-8, esAR.UTF-8). (Asegúrate de NO descomentar las versiones ISO-8859, esas son antiguas. Usa siempre las que terminan en UTF-8).

Guarda el archivo (Ctrl+O, Enter, Ctrl+X en nano). Ahora, compila los binarios de localización:

locale-gen

3.3.2 Archivos de Configuración de Entorno

Una vez generados, debes decirle al sistema cuál debe usar por defecto para todo el sistema (las variables de entorno LANG).

Crea el archivo locale.conf:

echo "LANG=es_ES.UTF-8" > /etc/locale.conf

Opcionalmente, para usuarios que exigen precisión, puedes tener un sistema mixto. Por ejemplo, tener el idioma en inglés (para que los mensajes de error en terminal sean buscables en Google), pero usar el formato de fecha, papel (A4) y moneda (€) españoles:

# En /etc/locale.conf
LANG=en_US.UTF-8
LC_TIME=es_ES.UTF-8
LC_MONETARY=es_ES.UTF-8
LC_PAPER=es_ES.UTF-8

3.3.3 Distribución del Teclado en la Consola (vconsole.conf)

El comando loadkeys es que usamos en el Capítulo 2 solo es temporal en memoria RAM. Para que tu teclado siga estando en español la próxima vez que inicies el PC y veas la consola TTY (la pantalla negra antes del entorno gráfico), crea el archivo vconsole.conf:

echo "KEYMAP=es" > /etc/vconsole.conf

(Usa la-latin1 en lugar de es si es un teclado latinoamericano).

3.4 Configuración de Red: Hostname y Hosts↑ Inicio

La identidad de tu máquina en las redes locales se define mediante su hostname (nombre de host). Esto es lo que verás en tu router, o en terminales SSH de otras computadoras.

Crea el archivo /etc/hostname y escribe el nombre que desees para tu PC. Debe ser una sola palabra, sin espacios ni símbolos raros. Por ejemplo arch-workstation, srv-produccion o simplemente arch:

echo "arch-workstation" > /etc/hostname

3.4.1 Resolución DNS Local (/etc/hosts)

El archivo /etc/hosts es un directorio telefónico primitivo que consulta el sistema antes de preguntar a los servidores DNS de internet. Es crucial para que tu máquina se reconozca a sí misma en su propia red de loopback (127.0.0.0/8). Muchas aplicaciones en red locales (como bases de datos PostgreSQL o servidores web locales) fallarán con timeouts severos si este archivo no está correctamente emparejado con tu hostname.

Abre el archivo:

nano /etc/hosts

Añade la siguiente estructura, sustituyendo arch-workstation por el nombre que elegiste en el paso anterior:

127.0.0.1        localhost
::1              localhost
127.0.1.1        arch-workstation.localdomain    arch-workstation

(Nota: 127.0.0.1 es la dirección IPv4 local y ::1 es la dirección IPv6 local).

3.5 Gestión de Identidades: Contraseñas, Usuarios y Privilegios (Sudo)↑ Inicio

En la jerarquía de un sistema UNIX, root es Dios. Tiene permisos irrestrictos para sobrescribir la RAM, formatear discos en caliente o borrar el sistema operativo entero sin advertencia. Operar bajo el usuario root para tareas diarias es un riesgo de seguridad masivo, no solo frente a virus (que no tendrían barreras), sino frente a errores humanos.

3.5.1 Contraseña de Superusuario (Root)

Debemos asegurar la cuenta principal.

passwd

Te pedirá la nueva contraseña y que la repitas. Por razones de seguridad del sistema echoing, la terminal no mostrará asteriscos ni puntos mientras escribes; teclea con confianza.

3.5.2 Creación de tu Usuario Estándar

Crearemos el usuario que usarás el 99% del tiempo.

useradd -m -G wheel -s /bin/bash francesc

Desglosemos este comando crucial:

• useradd: El binario del sistema para crear identidades.
• -m: (Make home). Crea automáticamente el directorio de inicio personal en /home/francesc copiando la plantilla desde /etc/skel.
• -G wheel: (Group). Añade al usuario al grupo suplementario wheel. En distribuciones basadas en RedHat y Arch, wheel es el grupo administrativo con derecho a escalar privilegios. (En Debian/Ubuntu se usa el grupo sudo).
• -s /bin/bash: (Shell). Define a bash como la consola por defecto para el usuario.
• francesc: Tu nombre de usuario (siempre en minúsculas).

Por supuesto, establece una contraseña para tu nuevo usuario:

passwd francesc

3.5.3 Escalada de Privilegios: Configuración de Sudo

El usuario está en el grupo de administradores, pero la herramienta que permite "tomar prestados" los poderes de root temporalmente (sudo) no viene instalada en Arch. Es una decisión de diseño, ya que algunos sysadmins prefieren doas (de OpenBSD) o simplemente usar su.

Nosotros instalaremos sudo:

pacman -S sudo

La configuración de qué usuarios pueden usar sudo reside en el archivo /etc/sudoers. Jamás edites este archivo directamente con nano o vim. Si cometes un error de sintaxis en sudoers, bloquearás permanentemente tu propio acceso de administrador al sistema en el futuro. Para editarlo, se utiliza el binario seguro visudo, que verifica la sintaxis al guardar e impide escribir si detecta un error.

Por defecto, visudo usa vi. Si prefieres nano, sobreescribe la variable ambiental:

EDITOR=nano visudo

Baja hasta encontrar la sección que menciona al grupo wheel. Verás una línea como esta:

# %wheel ALL=(ALL:ALL) ALL

Borra el símbolo de almohadilla (#) para descomentarla. Guarda y sal. A partir de este momento, cualquier usuario del grupo wheel (como el que acabamos de crear) podrá ejecutar comandos administrativos anteponiendo la palabra sudo y digitando su propia contraseña de usuario (no la de root).

3.6 El Gestor de Arranque (Bootloader): GRUB y systemd-boot↑ Inicio

El paso final y más delicado dentro del Chroot es instalar el Bootloader. Sin él, la placa base no sabrá cómo inyectar el Kernel de Linux en la RAM al encender el ordenador, dejándote con una pantalla negra o un error de "No Bootable Device Found".

Existen múltiples gestores para sistemas UEFI:

1. GRUB (GRand Unified Bootloader): El peso pesado. Extremadamente configurable, soporta arrancar imágenes ISO directamente, temas gráficos, desencriptación de discos LUKS en su fase temprana y sistemas de archivos complejos como ZFS o Btrfs. Es la opción más segura por su universalidad.
2. systemd-boot: Un gestor minimalista incluido directamente en el sistema base de systemd. Es ridículamente rápido, se configura con archivos de texto plano de 3 líneas y es hermoso en su simplicidad. Sin embargo, requiere que los kernels residan físicamente en la partición FAT32 del EFI y es menos flexible en configuraciones dual-boot complejas.

Dado que estamos construyendo un manual exhaustivo y a prueba de balas, utilizaremos GRUB, ya que su madurez garantiza el éxito en el 99% de los escenarios de hardware.

3.6.1 Instalación de Paquetes de GRUB

Primero, instalamos el software de GRUB y las herramientas para manipular variables UEFI (efibootmgr):

pacman -S grub efibootmgr

(Nota para Dual-Boot: Si tienes Windows instalado en otro disco y quieres que GRUB te muestre un menú para elegir entre Arch y Windows, debes instalar también el paquete os-prober y montar la partición EFI de Windows, aunque esto se detalla en configuraciones avanzadas. Por seguridad reciente, os-prober viene desactivado por defecto en GRUB).

3.6.2 Despliegue del Binario UEFI (grub-install)

El siguiente comando compila un pequeño archivo .efi y lo implanta en tu partición /boot (que es la partición FAT32 que creamos en el Capítulo 2). Además, utiliza efibootmgr para hablar directamente con el chip NVRAM de tu placa base e insertar una entrada de arranque en el menú de la BIOS.

Ejecuta con cuidado:

grub-install --target=x86_64-efi --efi-directory=/boot --bootloader-id=GRUB

• --target=x86_64-efi: Fuerza la compilación para arquitecturas de 64 bits modernas.
• --efi-directory=/boot: La ruta donde montamos nuestra partición FAT32.
• --bootloader-id=GRUB: Este es el nombre que verás listado en el menú de F12 de tu placa base. Puedes poner "ArchLinux" o lo que quieras.

Si el comando se ejecuta exitosamente, debería devolver un mensaje confirmando que "No error was reported" (No se reportaron errores).

3.6.3 Generación del Archivo de Configuración (grub.cfg)

grub-install solo instala el motor. Ahora debemos generar el mapa (el menú) que le dice al motor dónde encontrar el Kernel (vmlinuz-linux) y el sistema de archivos inicial en RAM (initramfs-linux.img). GRUB tiene una utilidad autogeneradora que rastrea tus discos y crea este menú:

grub-mkconfig -o /boot/grub/grub.cfg

En la salida de la terminal, verás cómo el script detecta las imágenes de Linux, el microcódigo de Intel/AMD que instalaste en pacstrap, y crea las entradas de menú apropiadas.

3.6.4 (Opcional) Micro-optimización del Microcódigo en GRUB

Si instalaste intel-ucode o amd-ucode, el script grub-mkconfig automáticamente debería inyectarlos como un initrd primario. Esto significa que antes de cargar tu sistema operativo, el gestor de arranque inyectará parches de seguridad microscópicos en tu procesador para protegerte de vulnerabilidades de hardware. Esto subraya el poder y la importancia de un Bootloader bien configurado.

3.7 Habilitando el Gestor de Red y Cierre↑ Inicio

Si reiniciamos el PC ahora mismo, tendríamos un sistema Arch Linux 100% funcional. GRUB arrancaría, el Kernel se cargaría y veríamos un inicio de sesión pidiendo usuario y contraseña. Sin embargo, no tendríamos internet. El demonio systemd-networkd de la ISO Live no existe mágicamente en nuestra instalación permanente a menos que lo configuremos. En el Capítulo 2 instalamos networkmanager. Es hora de ordenarle al sistema de inicialización que lo arranque en cada encendido.

systemctl enable NetworkManager

(Nota importante: Ojo con las mayúsculas en NetworkManager. Es uno de los pocos servicios en Linux que las utiliza).

Con esto garantizamos que, al reiniciar, tendremos un servicio de red robusto, capaz de conectarse por cable o gestionar redes WiFi complejas en el futuro (lo cual se cubrirá en el Capítulo 4).

3.7.1 La Salida Elegante

Tu trabajo como cirujano de sistemas en el entorno chroot ha terminado. Es hora de cerrar al paciente, limpiar los instrumentos y despertar la máquina.

1. Sal del chroot:

    exit

(Alternativamente, Ctrl+D. Notarás que el prompt vuelve al de la ISO roja/zsh).

1. Desmonta las particiones (Práctica de oro):

Aunque el reinicio lo forzaría, desmontar manualmente garantiza que todos los buffers de la memoria RAM se escriban físicamente en el SSD antes de cortar la energía.

    umount -R /mnt

(-R significa recursivo, desmontando primero /mnt/boot y luego /mnt en el orden correcto).

1. Reinicia la máquina:

    reboot

¡Desconecta tu USB de instalación de inmediato! Si has seguido las instrucciones al pie de la letra, tu placa base procesará el firmware, llamará al archivo UEFI de GRUB que acabas de implantar, y la gloriosa pantalla de selección de GRUB aparecerá por primera vez, abriéndote las puertas a tu nuevo, prístino y ultra-optimizado sistema Arch Linux. En los próximos capítulos dejaremos atrás la tiranía de la instalación para dominar la administración del sistema y el entorno gráfico.

Capítulo 4: Redes Avanzadas y Arquitectura de Audio↑ Inicio

Bienvenido a tu nueva instalación de Arch Linux. Tienes un kernel operativo y un usuario con privilegios, pero tu sistema está aislado del mundo. En los sistemas operativos amigables, la red y el sonido "simplemente funcionan". En Arch, debes construir y comprender estos puentes de comunicación. Este capítulo desmitifica el enrutamiento de red y la compleja evolución del audio en Linux.

4.1 Arquitectura de Red en Linux y NetworkManager↑ Inicio

Históricamente, la red en Linux se configuraba manualmente editando /etc/network/interfaces y usando comandos monolíticos como ifconfig. Hoy en día, la conectividad en entornos de escritorio y portátiles requiere un dinamismo que el método clásico no puede ofrecer (cambiar de una red Wi-Fi de cafetería a una VPN corporativa, y luego a un cable Ethernet en cuestión de segundos). Aquí es donde entra NetworkManager, un demonio apoyado por RedHat que se ha convertido en el estándar de la industria.

4.1.1 La Herramienta de Línea de Comandos: nmcli

Aunque NetworkManager posee interfaces gráficas, un administrador de sistemas domina nmcli. Este comando te permite hacer cualquier cosa que harías en una interfaz visual, de forma programática.

Para ver el estado general de todas tus interfaces:

nmcli device status

Gestión de Redes Wi-Fi desde la terminal: NetworkManager abstrae el uso de wpa_supplicant o iwd bajo el capó. Para buscar redes y conectarse:

1. Activar el escáner y mostrar redes:

   nmcli device wifi list

1. Conectarse a una red nueva (NetworkManager guardará el perfil y la contraseña en texto plano cifrado bajo /etc/NetworkManager/system-connections/):

   nmcli device wifi connect "SSID_DE_LA_RED" password "Tu_Contraseña"

Gestión de Perfiles (Conexiones): En NetworkManager, no interactúas con la "tarjeta de red" directamente para configurarla, interactúas con "Conexiones" (Perfiles) que se aplican a los dispositivos. Para ver tus perfiles guardados:

nmcli connection show

Para forzar una IP estática (útil en servidores) en lugar de DHCP:

nmcli connection modify "Nombre_Perfil" ipv4.addresses "192.168.1.50/24"
nmcli connection modify "Nombre_Perfil" ipv4.gateway "192.168.1.1"
nmcli connection modify "Nombre_Perfil" ipv4.method manual
nmcli connection up "Nombre_Perfil"

4.1.2 Resolución de DNS y systemd-resolved

Cuando escribes google.com, tu sistema debe traducir ese nombre a una dirección IP. Por defecto, NetworkManager utiliza los DNS que le proporciona el router. Sin embargo, en entornos avanzados, querrás usar systemd-resolved para implementar DNS sobre TLS (DoT) o caché de DNS local, evitando que tu proveedor de internet (ISP) rastree tus consultas.

Para activar el resolvedor local de systemd:

sudo systemctl enable --now systemd-resolved.service

Luego, debemos vincular el archivo clásico de Unix /etc/resolv.conf para que apunte al demonio de systemd:

sudo ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf

A partir de este momento, puedes auditar tus peticiones DNS usando:

resolvectl status

Para forzar el uso de DNS de Cloudflare (1.1.1.1) con cifrado, puedes editar /etc/systemd/resolved.conf y añadir:

[Resolve]
DNS=1.1.1.1 1.0.0.1
DNSOverTLS=yes

Reinicia el servicio (systemctl restart systemd-resolved) y tu navegación estará protegida de escuchas (sniffing) a nivel de DNS.

4.2 El Stack de Bluetooth (BlueZ)↑ Inicio

El ecosistema Bluetooth en Linux se basa en un proyecto colosal llamado BlueZ, patrocinado por empresas como Intel. BlueZ proporciona la pila de protocolos a nivel del kernel y las herramientas de usuario para comunicarse con dispositivos inalámbricos (Low Energy, audio A2DP, periféricos HID).

4.2.1 Instalación y Demonios

sudo pacman -S bluez bluez-utils

El paquete principal contiene el demonio bluetoothd. Debes habilitarlo en el sistema de inicio:

sudo systemctl enable --now bluetooth.service

4.2.2 Interacción con bluetoothctl

Al igual que nmcli, BlueZ proporciona un cliente interactivo para emparejar dispositivos desde la consola, imprescindible antes de instalar un entorno gráfico (o para servidores "headless").

Ejecuta el cliente:

bluetoothctl

Entrarás en el prompt interactivo. El flujo de trabajo profesional para conectar unos auriculares o un teclado es:

1. Encender el adaptador local: [bluetooth]# power on
2. Activar el escaneo temporal: [bluetooth]# scan on

(Verás una lluvia de direcciones MAC y nombres. Cuando veas tu dispositivo, copia su dirección MAC, ej. 00:1D:43:XX:YY:ZZ).

1. Emparejar (Pairing): [bluetooth]# pair 00:1D:43:XX:YY:ZZ

(Esto intercambia las llaves criptográficas de emparejamiento).

1. Confiar (Trusting): [bluetooth]# trust 00:1D:43:XX:YY:ZZ

(Crucial: Esto permite que el dispositivo se reconecte automáticamente en el futuro sin pedir permiso).

1. Conectar (Connecting): [bluetooth]# connect 00:1D:43:XX:YY:ZZ

Si en algún momento el audio Bluetooth falla misteriosamente o se entrecorta, los administradores utilizan el monitor de Bluetooth integrado para inspeccionar los paquetes HCI (Host Controller Interface) en crudo:

sudo btmon

4.3 Arquitectura de Audio: La Revolución de PipeWire↑ Inicio

Durante la última década, el audio en Linux fue fuente de memes y frustraciones. Existían tres subsistemas paralelos que a menudo chocaban entre sí:

1. ALSA (Advanced Linux Sound Architecture): El nivel más bajo, integrado en el kernel. Se encarga de hablar eléctricamente con tu tarjeta de sonido. (Problema: Solo una aplicación podía usar ALSA a la vez).
2. PulseAudio: Un servidor de sonido por encima de ALSA. Mezclaba flujos de audio para que pudieras escuchar YouTube y Spotify simultáneamente. (Problema: Añadía latencia inaceptable para producción musical profesional).
3. JACK: Creado para baja latencia estricta en producción musical y ruteo avanzado. (Problema: Imposible de usar para el usuario de escritorio normal; bloqueaba los navegadores web).

La Solución: PipeWire Desarrollado inicialmente por Wim Taymans en Red Hat, PipeWire es un servidor multimedia de próxima generación. No solo reemplaza a PulseAudio y a JACK, combinando la facilidad de uso del primero con la baja latencia del segundo, sino que también enruta flujos de video (esencial para capturar la pantalla en entornos modernos basados en Wayland).

4.3.1 Instalación de PipeWire y sus Wrappers

En Arch Linux, queremos instalar el servidor principal y las capas de compatibilidad (wrappers) que engañan a los programas antiguos para que crean que están hablando con PulseAudio o JACK.

sudo pacman -S pipewire pipewire-alsa pipewire-pulse pipewire-jack

(Si el sistema te pregunta si deseas eliminar pulseaudio debido a conflictos, debes responder que sí. Esto es intencional).

4.3.2 WirePlumber: El Cerebro del Audio

PipeWire es solo las "tuberías" por donde viaja la información multimedia. Para que las tuberías sepan a dónde ir (Ej. "Si conecto unos auriculares Bluetooth, rutea el audio automáticamente hacia ellos"), necesitamos un Session Manager (Gestor de Sesiones). El estándar de facto, respaldado por Collabora, es wireplumber.

sudo pacman -S wireplumber

4.3.3 Activación y el User Space (systemd --user)

A diferencia de la red o el bluetooth, que son demonios del sistema ejecutados por el todopoderoso root, el audio y el video en Linux moderno se ejecutan por usuario (User space). Esto es una medida de seguridad vital: no quieres que un demonio global del sistema tenga acceso al micrófono y envíe audio sin que el usuario activo lo sepa.

Por tanto, los servicios de PipeWire se activan utilizando el flag --user de systemd. ATENCIÓN: No uses sudo para ejecutar los siguientes comandos, debes ejecutarlos como tu usuario estándar:

systemctl --user enable --now pipewire.service
systemctl --user enable --now pipewire-pulse.service
systemctl --user enable --now wireplumber.service

Para verificar que la arquitectura está en pie y que los wrappers funcionan correctamente, ejecuta un comando de información del servidor PulseAudio antiguo. Si PipeWire intercepta la llamada, verás su nombre:

pactl info

Busca la línea "Server Name". Debería decir PulseAudio (on PipeWire). ¡Magia!

4.3.4 Control y Diagnóstico con wpctl

wireplumber incluye una poderosa herramienta de línea de comandos para manipular nodos de audio, volumen y dispositivos predeterminados: wpctl (WirePlumber Control).

Para listar todos los "sinks" (altavoces/salidas) y "sources" (micrófonos/entradas) detectados por el sistema:

wpctl status

La salida mostrará identificadores numéricos. El dispositivo con un asterisco * a su lado es el dispositivo predeterminado actual (Default Node).

Para modificar el volumen desde un script de bash o un atajo de teclado en un gestor de ventanas (Window Manager), puedes usar sintaxis relativa. Subir el volumen al dispositivo por defecto un 5%:

wpctl set-volume @DEFAULT_AUDIO_SINK@ 5%+

Bajar el volumen un 5%:

wpctl set-volume @DEFAULT_AUDIO_SINK@ 5%-

Silenciar (Mute) el micrófono por defecto (útil para una tecla dedicada de mute en tu teclado):

wpctl set-mute @DEFAULT_AUDIO_SOURCE@ toggle

Con una base de red sólida, perfiles DNS cifrados, conectividad Bluetooth para periféricos y el stack multimedia más avanzado del mercado, tu núcleo base está operativamente terminado. Has transformado una consola inerte en una estación de trabajo subyacente. El siguiente gran paso en nuestro viaje arquitectónico (Capítulo 5) es dominar el flujo de vida del software: la sagrada gestión de paquetes.

4.4 Redes Avanzadas: VLANs, Bonding y QoS↑ Inicio

Una vez dominas la conectividad básica con NetworkManager, el siguiente nivel arquitectónico, especialmente crítico en servidores o estaciones de trabajo en entornos corporativos, es la manipulación de las capas lógicas de red.

4.4.1 VLANs (802.1Q)

Las Redes de Área Local Virtuales (VLAN) permiten dividir un switch físico (o tu tarjeta de red) en múltiples subredes lógicas que no se pueden ver entre sí (ej. una red para cámaras de seguridad, otra para invitados y otra de administración). En Arch Linux, NetworkManager maneja esto impecablemente.

Si la red de tu oficina manda tráfico etiquetado con la VLAN 10 a tu puerto Ethernet (ej. enp3s0), puedes capturar y virtualizar esa interfaz en tu PC:

# Crear la interfaz virtual etiquetada como VLAN 10
nmcli connection add type vlan con-name VLAN10 dev enp3s0 id 10
# Asignarle una IP estática en el segmento correcto
nmcli connection modify VLAN10 ipv4.addresses 10.0.10.5/24 ipv4.method manual
nmcli connection up VLAN10

Tendrás ahora una interfaz virtual enp3s0.10 en ip link que funciona como si fuera un cable físico distinto.

4.4.2 Agregación de Enlaces (Bonding)

¿Qué haces si tienes dos tarjetas de red Gigabit Ethernet en tu placa base y tu servidor de archivos se ahoga transfiriendo a 1 Gbps? Los unes. El Network Bonding (o Teaming) permite sumar el ancho de banda o proporcionar tolerancia a fallos (si desconectas un cable, el otro sigue vivo sin que se corte el streaming).

Modo 4 (LACP - Link Aggregation Control Protocol) es el más profesional, asumiendo que tu Switch de red lo soporta:

# Crear la interfaz maestra de tipo bond
nmcli connection add type bond con-name MiBond ifname bond0 bond.options "mode=802.3ad,miimon=100"
# Añadir los dos cables físicos como esclavos del bond
nmcli connection add type ethernet slave-type bond con-name MiBond-Esclavo1 ifname enp3s0 master bond0
nmcli connection add type ethernet slave-type bond con-name MiBond-Esclavo2 ifname enp4s0 master bond0

4.4.3 Mitigación de Bufferbloat (QoS con fq_codel)

El "Bufferbloat" ocurre cuando descargas un archivo masivo (poniendo tu ancho de banda al 100%) y el ping de tu videojuego se dispara de 20ms a 300ms porque los paquetes pequeños del juego se quedan atrapados detrás de la descarga en el búfer del módem. El Kernel de Linux introdujo un milagro matemático llamado fq_codel (Fair Queueing Controlled Delay) que reordena los paquetes en tiempo real, priorizando los flujos pequeños y ágiles sobre las descargas pesadas.

Para activarlo, instruimos al kernel para que sea el algoritmo predeterminado (sysctl):

sudo nano /etc/sysctl.d/99-network.conf

Añadimos:

net.core.default_qdisc=fq_codel

Tras reiniciar (o aplicar con sudo sysctl --system), podrás saturar tu conexión de red con torrents y tu ping en League of Legends o llamadas de Zoom se mantendrá idéntico a como si no estuvieras descargando nada.

4.5 Audio Profesional: Masterizando PipeWire↑ Inicio

PipeWire no se limita a reproducir audio de YouTube; es una navaja suiza que desdibuja la línea entre el audio de un usuario final y el enrutamiento de un estudio de grabación profesional.

4.5.1 Latencia, RTirq y Mitigación de Crackling

Si utilizas sintetizadores MIDI o software de DJ (como Mixxx) y notas crujidos (Crackling / Xruns) al tocar el piano, se debe a que el tamaño del búfer (Buffer Size) de PipeWire es demasiado pequeño y tu CPU no tiene tiempo de procesar el sonido.

Ajuste del Quantum (Buffer): Podemos forzar la latencia en tiempo de ejecución. El "Quantum" es el número de muestras (samples) por bloque. 1024 es seguro pero tiene lag; 128 tiene bajísima latencia pero exige CPU. Para forzar un búfer ultra-rápido en una tarjeta de sonido que corre a 48000 Hz:

PIPEWIRE_LATENCY="128/48000" mixxx

Para evitar los crujidos a latencias tan bajas, el demonio de PipeWire necesita permiso del sistema para interrumpir a todos los demás programas (Prioridad RealTime). Instala rtirq:

sudo pacman -S rtirq
sudo systemctl enable --now rtirq.service

Esto reorganiza las interrupciones IRQ de la placa base, dándole máxima prioridad de hardware a tu tarjeta de sonido USB/PCIe por encima de tu tarjeta gráfica o discos duros.

4.5.2 Ecualización Paramétrica Sistémica (EasyEffects)

En lugar de depender de los ecualizadores individuales de cada programa (Spotify, Firefox), en Arch puedes instalar una capa interceptora que procesa matemáticamente todo el sonido del sistema operativo mediante convolución.

sudo pacman -S easyeffects lsp-plugins

EasyEffects utiliza la naturaleza de grafos de PipeWire para ponerse en medio (Proxy) de todas las salidas de audio. Puedes aplicar:

• Auto-Gain: Normaliza el volumen de videos de YouTube, de manera que jamás te asustes con un anuncio 3 veces más alto que el video.
• Convolver: Puedes descargar archivos de respuesta a impulsos (IR) de estudios acústicos de 10.000 dólares, cargarlos aquí, y hacer que tus auriculares de 30 dólares suenen acústicamente como un estudio profesional corregido por sonar (tecnología AutoEQ).
• Noise Reduction (RNNoise): Un filtro de IA para tu micrófono. Intercepta el ruido de las teclas mecánicas o de los ventiladores de tu PC, enviando a Discord/Teams una voz de locutor limpia.

4.5.3 Audio Distribuido por Red (Network Audio)

¿Tienes unos altavoces increíbles conectados a tu PC de escritorio, pero estás cocinando en la otra punta de la casa con tu portátil y quieres que Spotify suene en el escritorio? PipeWire incluye módulos de protocolo TCP para ruteo de red. No necesitas cables.

En el PC Servidor (Escritorio), activas el módulo nativo:

pactl load-module module-native-protocol-tcp listen=0.0.0.0 auth-anonymous=1

En tu Portátil (Cliente), le ordenas que no reproduzca localmente, sino que envíe la señal cruda IP al servidor:

PULSE_SERVER=tcp:192.168.1.50 spotify

El audio será transportado bit-perfect sin compresión por tu Wi-Fi doméstica. Con este nivel de modularidad, Arch Linux te da el control propio de una cadena de radiodifusión comercial en la palma de la terminal.

Capítulo 5: Gestión de Paquetes, Pacman y la Revolución del AUR↑ Inicio

Si el Kernel es el corazón de Arch Linux, el gestor de paquetes es su sistema circulatorio. A diferencia de Windows, donde navegas por la web para descargar instaladores .exe de orígenes dudosos, en Linux confías en repositorios centralizados y firmados criptográficamente. Arch Linux brilla de manera excepcional en este aspecto gracias a dos componentes legendarios: Pacman (el gestor oficial) y el AUR (Arch User Repository, la biblioteca de software impulsada por la comunidad más grande del mundo).

En este capítulo, aprenderemos a dominar estas herramientas no como simples usuarios que copian y pegan comandos, sino como administradores de sistemas que entienden cómo se empaqueta, compila y despliega el software.

5.1 Anatomía y Arquitectura de Pacman↑ Inicio

pacman es un gestor escrito en C. A diferencia del viejo apt (Ubuntu/Debian) que abstrae a dpkg, pacman maneja tanto la resolución de dependencias desde servidores remotos como la instalación de archivos locales.

5.1.1 El Formato de Paquete (.pkg.tar.zst)

En Arch Linux, un paquete de software compilado (binario) no es magia negra. Es simplemente un archivo comprimido utilizando el avanzadísimo algoritmo zstd (Zstandard, creado por Facebook para máxima velocidad de descompresión). Si descargas un paquete como firefox-125.0-1-x86_64.pkg.tar.zst y lo descomprimes (usando tar -I zstd -xf), verás que dentro solo contiene dos cosas:

1. La estructura de directorios real: (ej. una carpeta usr/bin/firefox).
2. Archivos de metadatos (MTREE): Archivos de texto ocultos (.PKGINFO, .INSTALL) que pacman lee para saber qué versión es, quién lo construyó y qué scripts ejecutar al instalarlo o desinstalarlo.

Cuando pacman "instala" un paquete, literalmente extrae esta estructura de carpetas sobre la raíz de tu disco duro y anota en su base de datos (/var/lib/pacman/local/) qué archivos pertenecen a qué programa.

5.1.2 Optimizando pacman.conf

El comportamiento de pacman se dicta estrictamente mediante el archivo /etc/pacman.conf. Vamos a configurarlo como un profesional. Abre el archivo:

sudo nano /etc/pacman.conf

Busca y modifica las siguientes opciones en la sección [options]:

• Descargas Paralelas: Descomenta la línea ParallelDownloads = 5. Por defecto, pacman descarga los paquetes de uno en uno. Al activar esto, descargará 5 archivos a la vez, lo que multiplicará por 5 la velocidad de actualización en conexiones de fibra óptica.
• Color visual: Descomenta Color. La salida de la terminal será infinitamente más legible.
• Easter Egg (Comecocos): Justo debajo de Color, escribe una nueva línea con la palabra ILoveCandy. Esto transformará la barra de progreso de pacman (que normalmente son guiones #) en un Pac-Man que come píldoras (c-o-o-o).

5.1.3 El Repositorio Multilib

Arch Linux hoy en día es una distribución estrictamente de 64 bits (x86_64). Ya no existen repositorios base para procesadores antiguos de 32 bits. Sin embargo, mucho software propietario, como Steam, Wine y juegos de Windows emulados, siguen estando programados en 32 bits. Para ejecutar este software, debes habilitar el repositorio [multilib], que contiene bibliotecas (como lib32-glibc) que permiten a un sistema de 64 bits ejecutar binarios de 32 bits de forma nativa. En el mismo pacman.conf, baja hasta el final y descomenta estas dos líneas:

[multilib]
Include = /etc/pacman.d/mirrorlist

Guarda el archivo y actualiza la base de datos de los repositorios para que los cambios surtan efecto:

sudo pacman -Sy

(Nota: Solo -Sy actualiza la base de datos de qué paquetes existen en los servidores, no actualiza tu software local).

5.2 Dominando los Comandos de Pacman (S, Q, R)↑ Inicio

Pacman utiliza flags principales en mayúscula para definir la operación, y subflags en minúscula para refinarla.

1. Operaciones de Sincronización (-S):

• sudo pacman -Syu: El santo grial de Arch. S (Sync), y (Refresh repositories), u (sysUpgrade). Este comando sincroniza las bases de datos locales con los servidores e inmediatamente actualiza todos los paquetes instalados a su última versión. Ejecuta esto al menos semanalmente. Jamás uses -Sy seguido de una instalación suelta sin hacer -Syu, podrías causar un estado de actualización parcial que romperá tu sistema.
• sudo pacman -S paquete: Instala un programa nuevo desde los repos oficiales.
• pacman -Ss palabra: Busca paquetes en los repositorios remotos que coincidan con la palabra clave.

2. Operaciones de Consulta Local (-Q):

• pacman -Q: Lista todos los paquetes instalados en tu sistema y su versión.
• pacman -Qe: Lista solo los paquetes instalados "Explícitamente" por ti (ignorando las dependencias que se instalaron automáticamente). Útil para hacer un backup de lo que has instalado.
• pacman -Qo /ruta/al/archivo: ¿Ves un archivo raro en tu sistema y no sabes de qué programa proviene? Este comando interroga a la base de datos de pacman para decirte a quién pertenece el archivo.

3. Operaciones de Eliminación (-R):

• sudo pacman -R paquete: (¡Peligro!) Elimina el paquete, pero deja instaladas todas las dependencias que trajo consigo, acumulando basura en tu disco duro (huérfanos).
• sudo pacman -Rs paquete: (La forma correcta). Elimina el paquete y, recursivamente, elimina cualquier dependencia suya que no esté siendo utilizada por ningún otro programa en tu sistema.
• sudo pacman -Rns paquete: Hace lo mismo que -Rs, pero además (n de No-save) borra los archivos de configuración globales (.pacsave) que el programa pudiera dejar en /etc/.

5.3 El AUR (Arch User Repository) y el Proceso de Compilación (Makepkg)↑ Inicio

Si un software es legalmente propietario (ej. Google Chrome), de nicho (ej. un tema oscuro oscuro para un gestor de ventanas) o muy nuevo, no estará en los repositorios oficiales de Arch. Sin embargo, está garantizado al 99.9% que estará en el AUR.

El AUR no contiene software. No hay binarios precompilados. El AUR es una colección gigante de recetas, llamadas PKGBUILD, escritas por usuarios como tú. Un PKGBUILD es un script de Bash que contiene las instrucciones exactas: de dónde descargar el código fuente, cómo parchearlo, cómo compilarlo y cómo empaquetarlo en un .pkg.tar.zst para que pacman pueda instalarlo.

5.3.1 Compilación Manual: The Arch Way

Todo usuario de Arch debe instalar un paquete de AUR manualmente al menos una vez en su vida para entender la mecánica y los riesgos de seguridad (si alguien pone un comando malicioso en el PKGBUILD, se ejecutará en tu máquina).

Para compilar, necesitas el grupo de herramientas de desarrollo (compiladores C/C++, Make, automake, patch) y Git:

sudo pacman -S base-devel git

Ejemplo manual: Instalar el navegador google-chrome (que es cerrado y no oficial).

1. Clonación del repositorio AUR:

Debes hacerlo como tu usuario normal, NUNCA como root.

    git clone https://aur.archlinux.org/google-chrome.git
    cd google-chrome

1. Inspección (Mandatoria en seguridad):

Abre el archivo PKGBUILD con nano o cat. Lee las URLs que descarga (source=()). Asegúrate de que apuntan a dl.google.com y no a un servidor ruso extraño.

1. Construcción e Instalación (makepkg):

Ejecutamos la herramienta constructora de Arch.

    makepkg -si

• -s (Sync dependencies): Si el PKGBUILD requiere otras cosas para compilar, llamará a pacman para instalarlas primero.
• -i (Install): Tras pasar minutos o horas compilando y generar el .pkg.tar.zst, ejecutará pacman automáticamente para instalar el resultado final.

5.4 Automatización del AUR: Los "AUR Helpers" (Yay / Paru)↑ Inicio

Hacer el proceso manual anterior de clonar, leer el PKGBUILD y ejecutar makepkg cada vez que quieres actualizar un paquete de AUR o buscar uno nuevo es una tortura. Para solucionar esto, la comunidad creó los AUR Helpers. Estos programas envuelven a pacman, agregándole la capacidad de buscar, clonar y actualizar de forma automatizada desde el AUR.

Los dos dominantes en el mercado son Yay (Yet Another Yogurt, escrito en Go) y Paru (escrito en Rust, desarrollado por el creador original de Yay). Instala el que prefieras; sus comandos son idénticos. Instalaremos yay.

Dado que yay es una herramienta del AUR, paradójicamente, la única forma de instalarlo por primera vez es utilizando el método manual.

cd ~
git clone https://aur.archlinux.org/yay.git
cd yay
makepkg -si

5.4.1 Dominando Yay

A partir de ahora, yay es tu mejor amigo. De hecho, puedes dejar de usar pacman casi por completo, ya que yay pasa todos los comandos de los repositorios oficiales directamente a pacman, y maneja el AUR en segundo plano. No uses sudo con yay, él mismo te pedirá la contraseña para instalar el paquete cuando termine de compilarlo.

• Buscar e instalar de ambos mundos (Oficial + AUR):

    yay -S spotify

(Yay descargará el PKGBUILD, lo leerá, resolverá las dependencias y lo instalará por ti).

• Actualizar el sistema completo:

El comando maestro de mantenimiento de Arch ahora es:

    yay -Syu

O de forma aún más minimalista, simplemente escribir yay y pulsar Enter ejecuta la actualización total. Yay primero actualizará los paquetes de Arch oficiales, y luego comprobará si hay actualizaciones para los programas compilados en el AUR.

5.4.2 Limpieza y Mantenimiento de la Caché (Paccache)

Arch Linux nunca borra un paquete descargado de la caché. Cada vez que actualizas el kernel, el viejo archivo .pkg.tar.zst se queda en /var/cache/pacman/pkg/. A lo largo de los años, esto puede ocupar decenas de gigabytes en tu SSD, robándote espacio precioso. Esta caché es útil para hacer "downgrades" (bajar de versión) si una actualización falla, pero no necesitas conservar las 40 versiones anteriores de Firefox.

Instala el paquete de utilidades contribuidas:

sudo pacman -S pacman-contrib

La herramienta paccache limpiará todos los paquetes antiguos, conservando por defecto solo las 3 versiones más recientes de cada programa instalado, dándote una red de seguridad sin gastar espacio inútil:

sudo paccache -r

Para automatizarlo y olvidarte de ello, habilita el timer de systemd (el cron moderno, que veremos en detalle en el Capítulo 10) que viene incluido:

sudo systemctl enable --now paccache.timer

Has conquistado el sistema de paquetes. Comprendes cómo pacman gestiona el binario, y cómo el AUR expande el software hasta el infinito mediante compilación. Con estas herramientas, tu TTY está lista para evolucionar; en el próximo capítulo daremos el salto a la capa visual: los Entornos de Escritorio y el Servidor Gráfico.

5.5 Repositorios Locales: Hospeda tu Propio AUR↑ Inicio

La inmensa mayoría de usuarios consume el AUR, pero pocos entienden que pacman está diseñado para ser completamente descentralizado. No tienes que depender de los repositorios de terceros para instalar paquetes; si en tu empresa o en tu clúster de servidores (Home Lab) necesitas distribuir un programa interno, debes forjar tu propio repositorio.

5.5.1 Forjando la Base de Datos con repo-add

Imagina que has compilado el núcleo personalizado linux-tkg o un software de gestión propio, generando el archivo mi-software-1.0-1-x86_64.pkg.tar.zst. Para que pacman lo acepte a través de la red, debe indexarlo.

1. Crea un directorio que actuará como tu servidor:

    mkdir -p /var/www/html/mi_repo
    # Copia el paquete binario a la carpeta
    cp mi-software-1.0-1-x86_64.pkg.tar.zst /var/www/html/mi_repo/

1. Genera la base de datos de Pacman. El comando repo-add crea un archivo .db.tar.gz que pacman lee para entender las dependencias:

    cd /var/www/html/mi_repo
    repo-add mi_repo.db.tar.gz mi-software-1.0-1-x86_64.pkg.tar.zst

1. Despliega tu repositorio. Puedes usar Nginx (Capítulo 14) o para una LAN rápida, el módulo HTTP interno de Python:

    python -m http.server 8080

5.5.2 Modificando a los Clientes

Ahora, en tu portátil (o en cualquier máquina que deba instalar el software corporativo), editas /etc/pacman.conf y añades al final del archivo:

[mi_repo]
SigLevel = Optional TrustAll
Server = http://192.168.1.150:8080

Ejecutas sudo pacman -Sy y verás que descarga tu base de datos y ahora puedes instalar mi-software con un simple pacman -S mi-software. Este es el secreto de Manjaro, EndeavourOS y BlackArch: simplemente son Arch Linux con repositorios extras añadidos al pacman.conf.

5.6 Empaquetado Quirúrgico (Chroot con devtools)↑ Inicio

Cuando escribes un PKGBUILD y ejecutas makepkg en tu máquina de desarrollo, existe un riesgo catastrófico, coloquialmente llamado "It works on my machine" (En mi PC funciona). Si tu PKGBUILD compila correctamente, puede ser porque hace tres meses instalaste una librería C++ llamada boost para otro proyecto. Como está instalada en tu sistema, la compilación de hoy la encuentra y triunfa. Pero olvidaste anotar boost en las dependencias (depends=) del PKGBUILD. Cuando subas tu paquete al AUR, miles de usuarios intentarán compilarlo y fallarán con un error de "librería no encontrada" porque ellos no tienen boost instalado.

El equipo oficial de Arch utiliza devtools para solucionar esto garantizando la pureza del entorno.

5.6.1 Construcción en Aislamiento (extra-x86_64-build)

En lugar de compilar en tu entorno contaminado, devtools crea automáticamente una "cápsula" (chroot) limpia con el Arch Linux base más primitivo (sin librerías, sin tus configuraciones, sin tus temas), mete el PKGBUILD dentro y lo compila. Si falta una dependencia en tu script, fallará espectacularmente, permitiéndote cazar el error.

1. Instala el kit para mantenedores de paquetes:

    sudo pacman -S devtools

1. Ve a la carpeta de tu PKGBUILD, pero NO ejecutes makepkg. En su lugar, lanza el constructor de contenedores:

    extra-x86_64-build

Esta herramienta levantará un entorno de chroot inmaculado en /var/lib/archbuild/, sincronizará pacman, resolverá las dependencias declaradas e intentará construir. El paquete resultante es matemáticamente predecible y puro, garantizado para funcionar en la máquina de cualquier otro usuario.

5.6.2 Firmas Criptográficas (GPG) en Pacman

Para evitar ataques Man-In-The-Middle (MITM), donde un ISP malicioso inyecta malware en los paquetes que descargas de un espejo HTTP, pacman verifica que cada paquete esté firmado criptográficamente por un "Master Keyholder" de Arch Linux.

El "Keyring" (Llavero) se actualiza de forma autónoma, pero si un desarrollador renueva su llave, tu pacman fallará al actualizar con un error de firmas (PGP Signature Error). Esto es aterradoramente común. El protocolo de emergencia para restablecer el anillo de confianza y purgar claves caducadas (resucitando a un pacman roto) es:

sudo rm -rf /etc/pacman.d/gnupg/
sudo pacman-key --init
sudo pacman-key --populate archlinux
sudo pacman -Sy archlinux-keyring

Con este nivel de profundidad, tu relación con el software en Arch Linux ha evolucionado: ya no eres un simple consumidor de binarios, te has convertido en un orquestador capaz de construir, verificar, firmar y distribuir software a escala de red.

Capítulo 6: Entornos de Escritorio y el Servidor Gráfico↑ Inicio

En los sistemas operativos comerciales como Windows o macOS, la interfaz gráfica está soldada al núcleo del sistema operativo. Si el explorador de ventanas falla, todo el sistema operativo a menudo colapsa (la famosa Pantalla Azul de la Muerte). En Linux, la filosofía de diseño es radicalmente modular. La interfaz gráfica de usuario (GUI) es simplemente otra aplicación (o conjunto de aplicaciones) que se ejecuta en el espacio de usuario (User Space). Puedes detenerla, cambiarla por otra completamente distinta, o no usarla en absoluto y tu servidor seguirá funcionando imperturbable.

En este capítulo, construiremos la pila gráfica (Graphics Stack) desde los cimientos (los drivers) hasta el tejado (el entorno de escritorio interactivo).

6.1 La Capa Base: Drivers Gráficos y Mesa↑ Inicio

Antes de que podamos dibujar píxeles en la pantalla, el sistema operativo necesita saber cómo hablar con el procesador gráfico (GPU). Las tarjetas gráficas son calculadoras matemáticas complejas que no entienden los comandos estándar del sistema.

El Kernel de Linux incluye los módulos (drivers de bajo nivel) para la gran mayoría del hardware. Sin embargo, para traducir las instrucciones 3D (como OpenGL o Vulkan) de los programas a la tarjeta de red, utilizamos Mesa. Mesa es un proyecto de software libre colosal que proporciona implementaciones Open Source de las APIs gráficas. Si tienes una tarjeta AMD (Radeon) o Intel integrada, Mesa es el estándar de oro absoluto; ofrece un rendimiento extraordinario y estabilidad nativa.

Instala la pila de Mesa:

sudo pacman -S mesa

(Nota sobre NVIDIA: Si tienes una tarjeta gráfica NVIDIA discreta, su driver oficial es propietario y cerrado. No usa Mesa para OpenGL. La instalación detallada de los drivers NVIDIA y su configuración se abarca exhaustivamente en el Capítulo 8: Gaming. Por ahora, Mesa te dará gráficos básicos si usas Nouveau, el driver libre de NVIDIA).

6.2 El Servidor de Pantalla: Xorg vs Wayland↑ Inicio

Una vez que podemos comunicarnos con la GPU, necesitamos un programa maestro que gestione la pantalla física, los teclados, los ratones y ofrezca un lienzo en blanco para que las aplicaciones dibujen sus ventanas.

6.2.1 El Viejo Rey: X Window System (X11 / Xorg)

Desarrollado en 1984 en el MIT, X11 ha sido el estándar durante casi 40 años. Es un sistema de red (arquitectura cliente-servidor) en el que los programas (clientes) envían instrucciones al servidor X para dibujar.

• Pros: Funciona en todas partes. Miles de programas antiguos asumen su existencia. Es altamente estable.
• Contras: Su código base es gigantesco, arcaico y está inflado. Carece de aislamiento de seguridad básico (cualquier programa X11 puede espiar las teclas que presionas (keylogger) en otro programa X11). El "Screen Tearing" (desgarro de imagen) es un problema intrínseco debido a su diseño, a menos que uses un compositor externo potente.

6.2.2 El Nuevo Paradigma: Wayland

Wayland no es un servidor, es un "protocolo" moderno que define cómo debe dibujarse la pantalla. En el paradigma de Wayland, el Entorno de Escritorio (ej. GNOME o KDE) actúa como el Compositor y Servidor al mismo tiempo.

• Pros: Es ridículamente rápido y suave. Elimina por completo el "Screen Tearing" al forzar que cada frame sea perfecto antes de enviarlo a la pantalla. Es seguro por diseño (un programa de Wayland no puede ver la ventana de otro programa sin pedirle permiso al usuario mediante portales de seguridad). Maneja diferentes monitores con diferentes tasas de refresco (ej. uno a 144Hz y otro a 60Hz) y diferentes escalados (DPI) sin despeinarse, algo que rompe a X11 por completo.
• Contras: Algunas aplicaciones muy específicas o antiguas (como software de captura de pantalla diseñado solo para X11) aún requieren compatibilidad a través de un puente llamado Xwayland.

El Veredicto en Arch Linux: Wayland es el presente y el futuro. Todos los entornos de escritorio modernos que vamos a explorar soportan Wayland de forma predeterminada.

6.3 El Gestor de Pantalla (Display Manager)↑ Inicio

Un Display Manager (DM), también conocido como gestor de inicio de sesión, es la primera interfaz gráfica que ves al arrancar tu máquina. Su trabajo es mostrarte una pantalla bonita, pedir tu contraseña, autenticarte a través de los módulos PAM (Pluggable Authentication Modules) y, si el login es exitoso, iniciar el Entorno de Escritorio con tus permisos de usuario.

Aunque técnicamente podrías iniciar sesión desde la consola negra y escribir startx o iniciar Wayland a mano, un DM es indispensable para una experiencia de escritorio moderna. Los DM más profesionales son:

1. SDDM (Simple Desktop Display Manager): El recomendado para KDE Plasma. Moderno, basado en Qt y con soporte experimental completo para correr de forma nativa bajo Wayland.
2. GDM (GNOME Display Manager): El estándar de GNOME. Extremadamente pulido, integrado en la suite de GNOME, pero pesado.
3. LightDM: El estándar histórico para escritorios ligeros (como XFCE). Usa X11 bajo el capó y es increíblemente rápido.

La instalación del Display Manager se realiza simultáneamente con el entorno de escritorio, ya que cada entorno suele requerir el suyo para una integración de bloqueo de pantalla óptima.

6.4 Desktop Environments: Instalación y Arquitectura↑ Inicio

Un Entorno de Escritorio (DE) es un conjunto masivo de software (el gestor de ventanas, panel de control, explorador de archivos, calculadoras, visores de imágenes) diseñado para funcionar en armonía. En Arch, instalamos metapaquetes (paquetes que no contienen software en sí, sino que contienen listas de dependencias para descargar todo el ecosistema de golpe). Elige solo uno para tu instalación inicial.

6.4.1 KDE Plasma (El Coloso Personalizable)

Desarrollado en C++ usando el framework Qt, KDE Plasma es famoso por ser el escritorio más personalizable del mundo Linux. Irónicamente, a pesar de ser visualmente deslumbrante, las versiones recientes han optimizado el uso de memoria (RAM) a niveles que rivalizan con los escritorios ligeros tradicionales. Plasma lidera la adopción de Wayland.

Instalación:

# Instalamos Plasma, el gestor SDDM y las aplicaciones base de KDE (Dolphin, Konsole)
sudo pacman -S plasma-meta kde-applications-meta sddm

Habilitación: Debemos decirle a systemd que inicie la pantalla de login (SDDM) en el próximo arranque:

sudo systemctl enable sddm.service

6.4.2 GNOME (El Paradigma Moderno)

GNOME (desarrollado en C utilizando GTK) toma una ruta diferente. Inspirado fuertemente por macOS, elimina la barra de tareas tradicional, el concepto de minimizar ventanas y el escritorio de iconos en favor de un flujo de trabajo basado en espacios de trabajo dinámicos (Workspaces) y un tablero central de Actividades. Es el escritorio por defecto en Fedora y Ubuntu Enterprise. GNOME es intencionadamente rígido: sus desarrolladores creen que un diseño cuidadosamente curado no debe ser alterado indiscriminadamente.

Instalación:

sudo pacman -S gnome gnome-extra gdm

Habilitación:

sudo systemctl enable gdm.service

6.4.3 XFCE (El Clásico Inmortal)

XFCE es el rey de la estabilidad y el bajo consumo. Si estás reviviendo un portátil de 2012 o simplemente quieres que tu entorno no cambie nunca, XFCE (basado en GTK) es tu elección. Sigue utilizando X11 y no soporta Wayland.

Instalación:

sudo pacman -S xfce4 xfce4-goodies lightdm lightdm-gtk-greeter

Habilitación:

sudo systemctl enable lightdm.service

6.5 Tipografías y Renderizado de Fuentes (Fontconfig)↑ Inicio

Un error extremadamente común en los novatos de Arch Linux es instalar un escritorio y notar que las páginas web se ven "cuadradas", rotas, o que las aplicaciones parecen de los años 90. ¿Por qué ocurre esto? Ubuntu o Manjaro instalan cientos de fuentes por defecto. Arch Linux no instala ninguna fuente por defecto (KISS). Si un navegador web intenta renderizar la letra Arial y tu sistema no tiene Arial (ni un equivalente de sustitución configurado), la pantalla mostrará cajas ilegibles o la fuente más básica que encuentre el kernel.

6.5.1 Instalación de Fuentes Base

El motor de renderizado de fuentes en Linux se compone de Freetype2 y Fontconfig. Para alimentar este motor, debemos instalar una biblioteca tipográfica robusta:

# Fuentes libres, soporte emoji, y fuentes coreanas/japonesas/chinas (cjk) para evitar caracteres rotos en la web
sudo pacman -S ttf-dejavu ttf-liberation noto-fonts noto-fonts-emoji noto-fonts-cjk

6.5.2 Las Fuentes de Microsoft (Core Fonts)

Independientemente de tu postura ideológica sobre el software libre, la web moderna se construyó asumiendo que los usuarios tienen las fuentes de Windows (Arial, Times New Roman, Comic Sans, Trebuchet). Muchos documentos PDF de empresas o universidades se deforman en Linux si abres el archivo en LibreOffice y el sistema no encuentra "Times New Roman". Como estas fuentes tienen licencia propietaria de Microsoft, no pueden estar en los repositorios oficiales de Arch, pero puedes (y debes) instalarlas a través del AUR:

yay -S ttf-ms-fonts

Una vez instaladas, puedes refrescar la caché de fuentes manualmente (aunque el gestor de paquetes suele hacerlo) con el comando:

fc-cache -fv

6.5.3 Tema de Cursores e Iconos

Finalmente, para darle cohesión al escritorio (especialmente fuera de GNOME, que trae los suyos fuertemente integrados), se recomienda instalar paquetes de iconos completos. El estándar dorado moderno es papirus-icon-theme.

sudo pacman -S papirus-icon-theme

Tu máquina está lista. Una simple orden, reboot, te llevará por primera vez fuera del abismo de la terminal pura. Serás recibido por la pantalla de inicio de sesión de tu DM. Al introducir tu contraseña, la magia ocurrirá, y tu estación de trabajo gráfica Arch Linux cobrará vida con un rendimiento que los usuarios de sistemas operativos genéricos rara vez experimentan.

6.6 Infraestructura Subyacente: DBus y XDG Desktop Portals↑ Inicio

Cuando pasamos del arcaico X11 (donde cualquier programa tenía permiso de administrador implícito sobre la pantalla) a Wayland (donde todo está aislado o sandboxed), surgió un problema de ingeniería masivo: ¿Cómo hace un programa como OBS Studio para grabar tu pantalla si el compositor de Wayland (el jefe de seguridad) se lo prohíbe explícitamente?

La respuesta son los XDG Desktop Portals. Estos portales son interfaces API estandarizadas (independientes de si usas GNOME, KDE o Hyprland) que las aplicaciones utilizan para "pedir permiso" al usuario a través del bus del sistema (DBus).

6.6.1 Arquitectura de Compartición de Pantalla (Screen Sharing)

Para que puedas compartir pantalla en Google Meet o Discord usando Wayland, la aplicación web utiliza el estándar WebRTC. WebRTC envía una señal DBus pidiendo acceso a la pantalla. El "Portal" lo intercepta y dibuja una ventana nativa de tu escritorio preguntando: "Firefox está pidiendo grabar el Monitor 1. ¿Aceptas?"

Si tienes un escritorio pre-construido como GNOME, esto viene instalado. Pero si construiste tu sistema manual, debes instalar el backend del portal de tu entorno:

# Para KDE Plasma:
sudo pacman -S xdg-desktop-portal-kde
# Para Hyprland:
sudo pacman -S xdg-desktop-portal-hyprland

Además, necesitas el portal "base" que sirve como enrutador y la capa de compatibilidad para aplicaciones GTK (como Firefox):

sudo pacman -S xdg-desktop-portal xdg-desktop-portal-gtk

Una vez instalados, si ejecutas OBS Studio y añades una fuente de captura, no elegirás "Captura XSHM", sino Captura de Pantalla (PipeWire). PipeWire, como vimos en el Capítulo 4, no solo enruta audio, sino que en ruta el flujo de video en bruto directamente desde el Compositor hacia OBS a 60 FPS sin pérdida de calidad ni latencia.

6.6.2 DBus: El Sistema Nervioso del Escritorio

DBus es el bus de mensajes del sistema. Si tu portátil se queda sin batería (10%), el kernel envía una señal. DBus la recoge, busca qué programa está escuchando eventos de energía (tu entorno de escritorio) y le entrega el mensaje para que pinte un aviso rojo en tu pantalla. Puedes inspeccionar este tráfico alienígena en tiempo real usando herramientas de auditoría:

# Instalar herramienta visual de DBus
sudo pacman -S d-spy

Verás que cada programa (Spotify, Firefox, el gestor de red) publica objetos en la red DBus. Un hacker o sysadmin avanzado puede enviar mensajes falsos por DBus usando el comando dbus-send para pausar la música, bloquear la pantalla o forzar al sistema a dormir sin usar la interfaz gráfica.

6.7 Aceleración de Video por Hardware (VA-API)↑ Inicio

Uno de los fallos más silenciosos y destructivos de una mala instalación de Arch Linux es el renderizado por software en los navegadores. Si reproduces un video 4K en YouTube y notas que tu portátil se calienta como un horno y los ventiladores giran al máximo, tu navegador no está usando el decodificador de video dedicado de tu GPU. Está usando la CPU bruta (Renderizado por Software) para calcular cada pixel del video.

La API estándar en Linux para decodificar videos H.264, VP9 o AV1 utilizando la tarjeta gráfica se llama VA-API (Video Acceleration API).

6.7.1 Habilitación en GPUs Intel y AMD

# Para procesadores Intel modernos (Broadwell o superior)
sudo pacman -S intel-media-driver
# Para AMD Radeon
sudo pacman -S libva-mesa-driver

Para comprobar si tu hardware puede decodificar, instala las utilidades de libva:

sudo pacman -S libva-utils
vainfo

La salida escupirá decenas de perfiles (ej. VAProfileVP9Profile0). Si dice VAEntrypointVLD, significa que el hardware soporta decodificación perfecta.

6.7.2 Forzando la Aceleración en Firefox y Chromium

A pesar de tener los drivers, los navegadores en Linux los desactivan por defecto por miedo a causar cuelgues (crashes) en hardware defectuoso.

• En Firefox: Escribe about:config en la barra de direcciones. Busca media.ffmpeg.vaapi.enabled y cámbialo a true. Busca también gfx.webrender.all y ponlo en true.
• En Chromium/Chrome: Abre chrome://flags. Busca Hardware-accelerated video decode y fuérzalo a Enabled.

Reproduce un video 4K. La carga de tu CPU pasará del 80% al 3%, y tu batería durará 4 horas más.

6.8 Gestión de Color y Perfiles ICC (Colord)↑ Inicio

Si eres fotógrafo, diseñador gráfico (usando Darktable o GIMP) o editor de video en DaVinci Resolve, sabes que el monitor miente. Un rojo en tu pantalla no es el rojo estándar de impresión. Para corregir esto, se utilizan colorímetros por hardware (como el X-Rite i1Display) que generan archivos de calibración de perfil de color .icc.

Linux posee un demonio central para la gestión del color llamado colord.

sudo pacman -S colord

En entornos como GNOME, la gestión del color está integrada nativamente en el panel de control. Seleccionas tu monitor, cargas tu archivo .icc y GNOME ajusta las curvas gamma de la GPU (LUT) automáticamente.

En Wayland, la implementación de gestión de color es un protocolo en desarrollo extremadamente agresivo. Compositores profesionales (como los diseñados para Wayland Color Management Protocol) aseguran que el color HDR (Alto Rango Dinámico) de 10-bits no sea modificado por XWayland ni alterado en el camino hacia el monitor, permitiendo edición de grado cinematográfico en Arch Linux con una precisión superior a la de macOS.

Capítulo 7: Window Managers Avanzados y el Arte del Ricing↑ Inicio

Mientras que KDE y GNOME (Capítulo 6) proporcionan la comodidad de un hotel todo incluido, muchos usuarios avanzados, programadores y entusiastas de UNIX encuentran los Entornos de Escritorio tradicionales lentos y limitantes. La alternativa radical es utilizar un Window Manager (Gestor de Ventanas) independiente.

En los escritorios tradicionales las ventanas son "flotantes" (Stacking); puedes arrastrarlas, cambiarles el tamaño con el ratón y ocultarlas una detrás de otra. Los Gestores de Ventanas avanzados utilizan la filosofía Tiling (Mosaico). En el tiling, el gestor de ventanas calcula matemáticamente el espacio de tu monitor y divide las ventanas en un mosaico perfecto que ocupa el 100% del espacio útil sin superposiciones. Navegas, cierras y mueves las ventanas exclusivamente con atajos de teclado. El ratón se vuelve opcional. Al principio la curva de aprendizaje es severa, pero una vez tu memoria muscular asimila los atajos, la productividad se dispara (y el consumo de RAM baja de gigabytes a unos escasos 200MB).

7.1 Gestores Tiling en X11 (La Vieja Escuela)↑ Inicio

Si deseas mantener la máxima compatibilidad con software antiguo o si tu hardware sufre bajo el nuevo protocolo Wayland, los Tiling WMs en X11 son tu campo de juegos.

7.1.1 i3wm: El Árbol Binario

i3 (y su sucesor i3-gaps) es el Tiling WM más famoso de la historia de Linux. Su estructura mental se basa en un árbol. Cuando abres una terminal, ocupa toda la pantalla. Si abres un navegador, la pantalla se divide en dos (50% y 50%). La genialidad de i3 es que su archivo de configuración es texto plano increíblemente legible, sin requerir conocimientos de programación.

Instalación:

sudo pacman -S xorg-server xorg-xinit i3-wm i3status dmenu alacritty

• xinit permite iniciar el entorno gráfico sin usar un Display Manager pesado (SDDM).
• dmenu es un buscador minimalista para lanzar programas escribiendo su nombre.
• alacritty es un emulador de terminal moderno y ultrarrápido (escrito en Rust y acelerado por GPU).

Configuración Inicial de i3: Para iniciarlo, creas un archivo oculto en el directorio de tu usuario llamado .xinitrc.

echo "exec i3" > ~/.xinitrc

Desde la TTY, escribes startx. En el primer arranque, i3 generará su archivo de configuración maestro en ~/.config/i3/config. Te pedirá elegir la tecla modificadora (ModKey), que suele ser la tecla "Windows/Super" o "Alt". A partir de ahí, Mod+Enter abre terminales; Mod+d abre el menú; Mod+Shift+q cierra ventanas.

7.1.2 bspwm: El Paradigma de los Contenedores Vacíos

Mientras que i3 maneja las divisiones por ti basándose en el enfoque activo, bspwm (Binary Space Partitioning Window Manager) separa el gestor de ventanas de los atajos de teclado. bspwm solo gestiona las ventanas; utilizas un demonio separado llamado sxhkd para capturar tus teclas y enviarle comandos. Es la opción preferida por los "Ricers" extremos en X11 por su maleabilidad programática mediante scripts bash.

7.2 Compositores Wayland: Hyprland (El Futuro Inmersivo)↑ Inicio

En X11 usabas picom (un demonio separado) para añadir sombras, transparencias y bordes redondos a i3wm. A menudo esto generaba lag y desgarro de pantalla. En Wayland, el gestor de ventanas es el compositor gráfico (todo en uno), lo que permite animaciones tan fluidas como las de un smartphone de alta gama (120Hz reales).

Hyprland es el Compositor Wayland dinámico que ha revolucionado la comunidad. Está basado en wlroots (el backend creado por los autores del compositor Sway) pero modificado pesadamente en C++ para priorizar la estética visual (Efecto Glassmorphism, animaciones personalizables con curvas de Bézier, sombras ricas y desenfoque gausiano de la terminal en tiempo real).

7.2.1 Instalación de la Pila Hyprland

A diferencia de i3, instalar Hyprland requiere componentes específicos diseñados para Wayland (ya que dmenu o los gestores de fondos de pantalla de X11 no funcionarán).

sudo pacman -S hyprland kitty waybar wofi hyprpaper dunst

• kitty: Emulador de terminal acelerado por GPU y con excelente soporte para Wayland (Alacritty también funciona).
• waybar: La barra de estado superior altamente personalizable.
• wofi: El lanzador de aplicaciones nativo de Wayland.
• hyprpaper: Utilidad para renderizar fondos de pantalla hiper-rápidos.
• dunst: El demonio de notificaciones que dibuja los pop-ups en la pantalla.

El Arranque de Hyprland: Al igual que en i3, no necesitas un gestor de sesión (SDDM). Desde la terminal (TTY), simplemente digitas:

Hyprland

Y serás recibido por un entorno de cristal, animaciones elásticas e integración instantánea con Wayland.

7.3 El Arte del "Ricing" y la Configuración de Dotfiles↑ Inicio

El acto de tomar un sistema operativo minimalista (i3wm o Hyprland) y configurar meticulosamente cada archivo de texto, fuente, barra espaciadora y color hexadecimal para crear un escritorio temático unificado y espectacular se denomina "Ricing" (una jerga derivada de la modificación visual extrema de coches). Un sistema "riceado" es un reflejo del alma técnica de su usuario.

Los archivos que manipulas para este arte se conocen como Dotfiles (Archivos punto), ya que en Linux cualquier carpeta o archivo que comience con un punto (.) está oculto (por ejemplo, .config/).

7.3.1 Anatomía de Hyprland.conf

En Hyprland, tu vida gira en torno a ~/.config/hypr/hyprland.conf. A diferencia del XML o JSON, es un archivo de texto secuencial que lee el compositor sobre la marcha (puedes editar el archivo y ver los cambios reflejados instantáneamente sin recargar).

Ejemplo de cómo un "Ricer" ajustaría la estética general:

general {
    gaps_in = 5               # Espacio interior entre ventanas
    gaps_out = 20             # Espacio exterior a los bordes del monitor
    border_size = 2
    col.active_border = rgba(33ccffee) rgba(00ff99ee) 45deg # Borde gradiente arcoíris
    col.inactive_border = rgba(595959aa)
}

decoration {
    rounding = 10             # Bordes redondeados de Apple/Windows 11
    blur {
        enabled = true        # Efecto cristal translúcido detrás de las ventanas
        size = 8
        passes = 3            # Desenfoque gausiano profundo y pesado
    }
    drop_shadow = yes
    shadow_range = 4
}

7.3.2 Tipografías Nerd Fonts (Iconos en Texto)

Si abres waybar o miras la configuración de terminales de usuarios avanzados, verás que usan iconos del clima, discos duros y logos de Wi-Fi incrustados directamente en el texto del código de programación. ¿Cómo lo hacen sin usar imágenes? La respuesta son las Nerd Fonts. Son fuentes tipográficas populares (como JetBrains Mono, Fira Code o Hack) que han sido parcheadas inyectándoles miles de iconos vectoriales de FontAwesome, Material Design y DevIcons.

Para tener una terminal espectacular y barras de estado, debes instalar paquetes de Nerd Fonts (muchos se movieron a los repositorios oficiales recientemente):

sudo pacman -S ttf-nerd-fonts-symbols ttf-jetbrains-mono-nerd ttf-fira-code-nerd

Luego, le dices a tu terminal (~/.config/kitty/kitty.conf) que use esa fuente:

font_family      JetBrainsMono Nerd Font
bold_font        auto
italic_font      auto
font_size        12.0

7.3.3 Waybar: La Barra de Herramientas Programable

Waybar es el estándar en Wayland. Se configura usando sintaxis JSON (~/.config/waybar/config) para la disposición de los módulos (reloj, uso de RAM, batería, espacios de trabajo de Hyprland) y se diseña (stylized) utilizando CSS (~/.config/waybar/style.css). Esto permite a los desarrolladores web crear barras idénticas a las de macOS o interfaces futuristas sin aprender nuevos lenguajes.

Puedes crear "Custom Modules" que ejecutan un script de bash cada 10 segundos para buscar información en internet (ej. precio del Bitcoin o temperatura de tu ciudad) y la imprimen en la barra, dotando al sistema de una versatilidad ilimitada.

7.4 Control de Versiones para Dotfiles (GNU Stow)↑ Inicio

Una vez que has invertido tres semanas diseñando el escritorio perfecto y tu hyprland.conf, tus scripts de waybar y los atajos de teclado de kitty son una obra de arte unificada, te enfrentas a un problema: Si tu disco duro muere, perderás meses de microajustes. Los profesionales usan GitHub para hacer copias de seguridad públicas de sus Dotfiles (basta buscar "Hyprland dotfiles" en GitHub para encontrar miles).

Pero, ¿cómo sincronizas una carpeta aislada como ~/.config/hypr/ y otra como ~/.config/waybar/ a un repositorio Git único sin arrastrar configuraciones secretas (como contraseñas del navegador que también viven en .config)?

La solución hacker por excelencia es GNU Stow (un gestor de symlinks).

1. Instalas Stow: sudo pacman -S stow
2. Creas una carpeta de repositorio central, ej. ~/MisDotfiles.
3. Dentro, replicas la estructura: ~/MisDotfiles/hyprland/.config/hypr/hyprland.conf
4. Desde tu directorio Home, ejecutas stow hyprland -t ~ -d ~/MisDotfiles.

Stow creará un enlace simbólico (un túnel) desde tu directorio real hacia el repositorio git. Ahora puedes inicializar git init en ~/MisDotfiles, subir tus archivos a la nube, y cuando instales Arch Linux en un portátil nuevo, solo tendrás que clonar el repo y ejecutar stow * para que todo tu entorno visual hiper-configurado se ensamble solo en 3 segundos.

Este es el verdadero poder de Arch Linux: el sistema operativo no es una caja negra; es texto plano a tu servicio.

7.5 Comunicación Inter-Procesos (IPC) y Control Absoluto↑ Inicio

La característica definitiva que separa a un Window Manager tiling (como Hyprland o bspwm) de un entorno monolítico (como Windows) es el IPC (Inter-Process Communication). El gestor de ventanas abre un socket (un túnel de red interno) a través del cual cualquier script de tu PC puede enviarle órdenes instantáneas.

7.5.1 Dominando hyprctl

En Hyprland, la herramienta de comando es hyprctl. Desde una terminal cualquiera, puedes ordenar al compositor gráfico que realice acciones físicas.

• Moverte al espacio de trabajo 5: hyprctl dispatch workspace 5
• Hacer flotante la ventana actual: hyprctl dispatch togglefloating
• Lanzar una aplicación específica ignorando reglas: hyprctl dispatch exec firefox

La magia real ocurre cuando solicitas información (telemetría). Si ejecutas:

hyprctl clients -j

Hyprland escupirá un bloque JSON inmenso y estructurado con las coordenadas X/Y exactas, el PID, el tamaño y el estado de cada ventana en tu pantalla. Un desarrollador de bash o python puede parsear este JSON (usando jq) y escribir un script que, por ejemplo, detecte si Spotify está abierto y lo mueva automáticamente al Monitor 2, redimensionándolo al 30% de ancho.

7.5.2 Event Hooks (Escuchando al Compositor)

En lugar de preguntar "qué está pasando", puedes conectar un cable directamente al cerebro del compositor para que él te informe en tiempo real (Event-Driven). Hyprland transmite todos sus eventos al socket de UNIX ubicado en /tmp/hypr/$HYPRLANDINSTANCESIGNATURE/.socket2.sock.

Podemos usar socat para escuchar este flujo constante de datos:

sudo pacman -S socat
socat -U - UNIX-CONNECT:/tmp/hypr/$HYPRLAND_INSTANCE_SIGNATURE/.socket2.sock

Al dejar esto corriendo, si cambias de ventana o cierras un programa, verás texto aparecer en vivo (ej. activewindow>>Firefox). Los "Ricers" utilizan esto para que su barra superior (waybar) reaccione al milisegundo, cambiando los colores de los iconos cuando el usuario se mueve entre pantallas.

7.5.3 Demonización (Systemd User Services en WMs)

En un DE tradicional, el sistema auto-inicia tu demonio de notificaciones y tu fondo de pantalla. En un WM tiling puro, tú debes iniciarlos. El error de novato es escribir líneas exec-once = dunst & en el archivo de configuración. Si el programa se cuelga, no volverá a iniciar.

La forma experta es delegar el inicio de las herramientas del escritorio a tu usuario de systemd (Capítulo 10). Creas unidades ~/.config/systemd/user/waybar.service y ~/.config/systemd/user/hyprpaper.service. El Window Manager solo carga la pantalla; systemd se encarga de vigilar, reiniciar y loguear cada pieza de tu Rice, asegurando una estabilidad industrial.

7.6 La Pesadilla HiDPI y Soluciones Multi-Monitor↑ Inicio

Si tienes un monitor 1080p y un monitor 4K juntos, has entrado en el territorio donde Windows y macOS tradicionalmente sufren, y donde X11 falla catastróficamente. En X11, toda la pantalla unida (las dos pantallas físicas) se considera una única "X Screen". No puedes decirle a X11 que el monitor 4K se escale al 200% y el 1080p se quede al 100%. Las ventanas del 4K se verán diminutas, o las del 1080p se verán gigantes.

Wayland, gracias a su arquitectura moderna (drm/KMS), trata cada pantalla como un lienzo absolutamente independiente con un búfer de memoria aislado.

7.6.1 Escalado Fraccional en Wayland

Si tienes un monitor 1440p (2K), un escalado del 100% hace que el texto sea pequeño, y el 200% lo hace estúpidamente grande. Necesitas un 150% (Fractional Scaling). En la configuración de tu compositor (Ej. Hyprland en hyprland.conf):

# Monitor 1 (4K) a 144Hz escalado al 200%
monitor=DP-1,3840x2160@144,0x0,2

# Monitor 2 (1440p) a 60Hz a la derecha, escalado al 150%
monitor=HDMI-A-1,2560x1440@60,1920x0,1.5

La advertencia del XWayland: Las aplicaciones antiguas que no entienden Wayland (como algunos juegos o Electron viejo) corren sobre XWayland. Cuando Wayland escala de forma fraccional (1.5), lo que hace con XWayland es decirle al programa "dibuja a resolución normal", y luego Wayland estira la imagen un 150% como si fuera una foto borrosa (Blurriness). Para evitar esto, debes forzar a todas tus aplicaciones (Firefox, VSCode, Discord) a usar los backends nativos de Wayland.

Para aplicaciones Electron (VSCode, Discord), ejecútalas añadiendo las flags mágicas:

code --enable-features=UseOzonePlatform --ozone-platform=wayland

Automáticamente el texto dejará de estar borroso y será renderizado nítidamente por los vectores de tu GPU.

7.6.2 Monitores Virtuales Headless (KVMs por Software)

Un truco de administrador avanzado: si tienes un portátil potente con la pantalla rota o un servidor Arch en un armario, puedes usar Wayland para crear un monitor que no existe físicamente. Usando comandos IPC (ej. hyprctl output create headless), el compositor genera un búfer de video 4K en la RAM.

Luego, puedes usar un protocolo de escritorio remoto avanzado (como Sunshine/Moonlight o WayVNC) para capturar ese búfer invisible y enviarlo por la red local a tu iPad, Smart TV o portátil ligero. Estarás utilizando el 100% de la potencia de la tarjeta gráfica del ordenador servidor (jugando a juegos Triple A en calidad ultra) mientras recibes el video comprimido en tiempo real en un dispositivo de baja potencia en el salón.

Esta arquitectura convierte cualquier máquina Arch Linux en un servidor en la nube de computación visual privada.

Capítulo 8: Gaming y Rendimiento Gráfico Extremo↑ Inicio

En la última década, Linux ha pasado de ser un páramo desolado para el gaming a convertirse en la plataforma base de la consola portátil más exitosa (Steam Deck). Arch Linux, gracias a su modelo Rolling Release, es indiscutiblemente la mejor distribución para juegos: tienes acceso al último kernel y a los últimos drivers gráficos en el mismo momento en que los fabricantes de hardware los liberan, proporcionando mejoras de FPS (Frames Per Second) masivas para títulos de lanzamiento reciente (Day-1).

En este capítulo analizaremos las entrañas de los drivers gráficos, la capa de traducción Proton y las utilidades de rendimiento que pueden hacer que un juego funcione mejor en Arch que en Windows.

8.1 Drivers Gráficos a Nivel de Kernel (KMS/DRM)↑ Inicio

Para jugar en serio, los drivers de código abierto mesa básicos no siempre son suficientes o requieren ajustes para aprovechar la aceleración de hardware total.

8.1.1 Arquitectura AMD (Radeon)

Si tienes una tarjeta AMD, estás en el paraíso de Linux. AMD mantiene el código abierto de sus drivers e invierte fuertemente en el Kernel. Existen dos módulos de kernel para AMD: el obsoleto radeon y el moderno amdgpu. Asegúrate de que el repositorio [multilib] está activado (como vimos en el Capítulo 5) e instala la implementación de Vulkan específica de AMD (RADV) proporcionada por Mesa:

sudo pacman -S mesa lib32-mesa vulkan-radeon lib32-vulkan-radeon

Dato técnico: RADV (Radeon Vulkan) es la implementación de código abierto que Valve patrocina. Existe otra oficial de AMD llamada amdvlk, pero RADV ofrece consistentemente un mejor rendimiento y menor latencia en juegos.

8.1.2 Arquitectura NVIDIA (Drivers Propietarios y DKMS)

NVIDIA históricamente ha proporcionado soporte deficiente de código abierto (el driver libre nouveau es inútil para gaming moderno porque NVIDIA bloqueaba las frecuencias del reloj). En Arch, estás forzado a instalar el driver privativo y cerrado de NVIDIA.

El problema de las actualizaciones de Kernel: Cuando instalas el paquete estándar nvidia, este está precompilado única y exclusivamente para la última versión del kernel oficial (linux). Si utilizas un kernel personalizado como linux-zen o el kernel LTS, y pacman actualiza dicho kernel, tu driver NVIDIA se romperá, dejándote en una pantalla negra al reiniciar. La solución profesional: DKMS (Dynamic Kernel Module Support) DKMS recompilará automáticamente el módulo de la tarjeta gráfica NVIDIA cada vez que pacman detecte una actualización del kernel, sin importar qué kernel uses.

Instala la pila propietaria con DKMS:

sudo pacman -S nvidia-dkms nvidia-utils lib32-nvidia-utils

Habilitar DRM Modesetting (Crítico para Wayland y Anti-Tearing): Para que NVIDIA funcione correctamente bajo compositores modernos como Hyprland o GNOME Wayland, y para evitar desgarros de pantalla en X11, debes habilitar el parámetro KMS en el Kernel. Abre /etc/default/grub y busca la línea GRUBCMDLINELINUX_DEFAULT. Añade nvidia-drm.modeset=1:

GRUB_CMDLINE_LINUX_DEFAULT="loglevel=3 quiet nvidia-drm.modeset=1"

Reconstruye GRUB: sudo grub-mkconfig -o /boot/grub/grub.cfg y reinicia.

8.2 La Revolución Proton y las APIs de Traducción (DXVK / VKD3D)↑ Inicio

La gran mayoría de los juegos comerciales de alto presupuesto están programados para DirectX, una API gráfica exclusiva y cerrada de Microsoft Windows. Un juego de DirectX no sabe cómo hablar con Linux ni con su API nativa, Vulkan.

Aquí entra Proton, un fork masivamente modificado de Wine financiado por Valve. Proton intercepta las llamadas de DirectX del juego en tiempo real y las traduce a instrucciones Vulkan mediante traductores:

• DXVK: Traduce DirectX 9, 10 y 11 a Vulkan.
• VKD3D-Proton: Traduce el complejísimo DirectX 12 a Vulkan.

Gracias a la eficiencia extrema de Vulkan y a que Linux tiene menos procesos en segundo plano que Windows (menor "overhead"), la traducción a menudo ocurre con una penalización de rendimiento del 0%, y en muchos casos, el juego traducido rinde mejor que el original en Windows.

8.2.1 Instalación de Steam y Configuración de Proton

Steam en Linux es una aplicación nativa, pero la mayoría de los juegos no lo son.

sudo pacman -S steam ttf-liberation

Inicia Steam, loguéate y ve a Parámetros > Compatibilidad. Marca las casillas:

1. Enable Steam Play for supported titles.
2. Enable Steam Play for all other titles. (Permite ejecutar CUALQUIER juego de Windows).
3. Selecciona "Proton Experimental" o la última versión numérica estable como tu herramienta global por defecto.

Steam te pedirá reiniciar. Ahora el botón "Instalar" aparecerá habilitado para cada juego de tu biblioteca, sin importar el sistema operativo original.

8.2.2 Juegos fuera de Steam: Lutris y Heroic

Para juegos de Epic Games, GOG, Amazon Games o instaladores .exe sueltos, Steam no te sirve.

• Lutris: Es el administrador definitivo de videojuegos en Linux. Gestiona scripts creados por la comunidad que autodescargan dependencias oscuras de Windows (como viejas librerías C++ o fuentes) para que un juego funcione perfectamente con un clic.

    sudo pacman -S lutris

• Heroic Games Launcher: El cliente Open Source no oficial (y muy superior) para Epic Games y GOG. Descarga e instala los juegos y te permite inyectar versiones personalizadas de Proton (como Proton-GE, mantenido por GloriousEggroll, que incluye codecs de video de Windows media que Valve no puede incluir por temas legales).

    yay -S heroic-games-launcher-bin

8.3 Maximizando el Rendimiento (FPS) e Inyección de Herramientas↑ Inicio

En Linux tienes el control absoluto de los recursos de tu hardware. La comunidad ha desarrollado herramientas (usadas intensivamente en la Steam Deck) para encapsular juegos, engañarlos y exprimir hasta el último hercio de la CPU.

8.3.1 Feral GameMode (Overclock Automático del Sistema)

GameMode es un demonio del sistema que, cuando arranca un juego, solicita permiso a systemd para elevar la prioridad del proceso del juego, cambia el gobernador de la CPU (CPU Governor) al estado "Performance" (para que los núcleos no bajen su frecuencia para ahorrar batería), desactiva los protectores de pantalla e incluso puede ejecutar scripts personalizados (como apagar el compositor gráfico de X11). Al cerrar el juego, devuelve el sistema a su estado normal.

Instalación:

sudo pacman -S gamemode lib32-gamemode

Para usarlo en un juego de Steam, haces clic derecho sobre el juego > Propiedades > Opciones de Lanzamiento, y añades:

gamemoderun %command%

8.3.2 Gamescope (El Micro-Compositor)

Un problema común al jugar en Linux es que el juego intente cambiar la resolución de todo el monitor (estropeando el escritorio) o que el ratón se escape a un segundo monitor en pleno combate. Gamescope crea una ventana aislada (un servidor Wayland anidado) que le hace creer al juego que él es el único que existe. Gamescope es brillante porque incluye FSR (FidelityFX Super Resolution) a nivel de sistema. Puedes decirle a Gamescope que renderice un juego pesadísimo a 720p interno, y que lo escale mediante IA a 1440p (o 4K) en tu monitor. El juego creerá que está corriendo a 720p y te dará el triple de FPS, mientras tú lo ves a resolución casi nativa.

Instalación:

sudo pacman -S gamescope

Uso en Opciones de Lanzamiento de Steam (Renderizado interno 1080p, escalado de salida 1440p usando FSR):

gamescope -h 1080 -H 1440 -U -f -- %command%

(-U activa FSR, -f fuerza pantalla completa).

8.3.3 Telemetría en Tiempo Real (MangoHud)

¿Ves esos vídeos de YouTube comparando tarjetas gráficas donde aparece un gráfico detallado en la esquina superior izquierda con la temperatura, uso de VRAM y un gráfico de los FPS? Ese es MSI Afterburner en Windows. En Linux, usamos el infinitamente superior MangoHud, que se inyecta directamente en la llamada de Vulkan/OpenGL.

Instalación:

sudo pacman -S mangohud lib32-mangohud

Para activarlo en un juego de Steam, pones en opciones de lanzamiento:

mangohud %command%

(Y sí, puedes encadenar los comandos: mangohud gamemoderun %command%).

8.4 El Último Bastión: Anti-Cheats (Anti-Trampas)↑ Inicio

Todo lo anterior suena a magia tecnológica, y lo es. Hoy en día, Cyberpunk 2077, Elden Ring, Red Dead Redemption 2 o Baldur's Gate 3 funcionarán en Arch Linux en Ultra a 60+ FPS sin que tengas que abrir una sola terminal. El único problema real para el gaming en Linux son los juegos Multijugador Competitivos.

Para evitar que los jugadores hagan trampas, empresas como Riot Games (Valorant, League of Legends) o Activision (Call of Duty) utilizan programas Anti-Cheats (como Vanguard o Ricochet) que se instalan a nivel del Kernel de Windows (Ring 0). Funcionan como Rootkits legales. Al intentar ejecutarlos a través de Proton en Linux, el Anti-Cheat entra en pánico porque no puede encontrar los archivos del núcleo de Windows y banea o bloquea al usuario inmediatamente. Estos juegos son injugables en Linux.

Sin embargo, los Anti-Cheats más populares de la industria, EasyAntiCheat (EAC) y BattlEye, anunciaron soporte oficial y nativo para Linux y Proton. Juegos competitivos como Apex Legends, The Finals o Counter-Strike 2 (nativo) funcionan de forma impecable en Arch Linux.

El sitio web de referencia obligatoria para cualquier gamer de Arch es ProtonDB (protondb.com). Antes de comprar o descargar un juego, búscalo allí; la comunidad te dirá si funciona de caja (Nivel Platino/Oro) o si el desarrollador tiene bloqueado el Anti-Cheat a propósito (Nivel "Borked").

8.5 Control Térmico y Energético: Overclocking y Undervolting↑ Inicio

Un administrador de sistemas o gamer entusiasta no acepta las frecuencias de reloj y voltajes predeterminados de la fábrica. Reducir el voltaje (Undervolting) de una tarjeta gráfica puede bajar las temperaturas en 10 grados Celsius y reducir el ruido de los ventiladores a cero, mientras se mantiene exactamente el mismo rendimiento.

8.5.1 Entorno AMD (AMDGPU Sysfs y CoreCtrl)

El driver de código abierto amdgpu expone casi toda su telemetría y palancas de control a través del sistema de archivos virtual (/sys/class/drm/card0/device/). Puedes hacer overclocking simplemente escribiendo números en archivos de texto, pero es peligroso y tedioso. Para hacerlo de forma segura e intuitiva, instalamos CoreCtrl, el equivalente de Linux a MSI Afterburner.

sudo pacman -S corectrl

Para que CoreCtrl pueda tocar los voltajes, debemos arrancar el kernel pasándole un parámetro explícito que relaje las restricciones de seguridad del driver AMD. Abre /etc/default/grub y añade a GRUBCMDLINELINUX_DEFAULT:

amdgpu.ppfeaturemask=0xffffffff

Regenera GRUB y reinicia. Al abrir CoreCtrl, verás curvas de ventilador ajustables mediante nodos gráficos, perfiles 3D y la capacidad de fijar el límite máximo de vatios (Power Limit) de tu tarjeta de 200W a 150W, logrando una eficiencia energética drástica sin perder FPS.

8.5.2 Entorno NVIDIA (Coolbits y GreenWithEnvy)

NVIDIA bloquea el overclocking en Linux a menos que habilites una bandera oculta secreta en el archivo de configuración del servidor gráfico X11 (o su equivalente Wayland). Este modo "Dios" se llama Coolbits.

Para activarlo en X11, se genera el archivo de configuración de NVIDIA y se inyecta el valor 31 (que suma permisos de overclocking, ventiladores y voltajes):

sudo nvidia-xconfig --cool-bits=31

Luego, se instala una aplicación del AUR llamada GreenWithEnvy (GWE):

yay -S gwe

Con GWE, podrás alterar los relojes del núcleo (Core Clock Offset) y de la memoria VRAM (Memory Offset). Un aumento de +500MHz en la VRAM de las gráficas de la serie 3000 o 4000 suele otorgar entre un 5% y un 10% de FPS extra sin esfuerzo térmico adicional.

8.6 Entendiendo la Sub-Arquitectura de Wine↑ Inicio

No todo en la vida es jugar a través de Steam (Proton). Muchos usuarios de Arch Linux dependen de software hiper-especializado de Windows (DAWs de producción musical como FL Studio/Ableton, herramientas de modelado CAD, o suites de Adobe). Para correr estos monstruos, no usamos Wine genérico. Manipulamos los Prefixes (Prefijos).

8.6.1 El Concepto del WINEPREFIX Aislado

Un prefijo de Wine es una carpeta de tu disco duro que simula ser el disco C:\ de una máquina con Windows. Por defecto, si ejecutas wine programa.exe, se instalará todo en ~/.wine/. Esto es un error garrafal. Si instalas 10 programas en el mismo prefijo, las DLLs empezarán a sobreescribirse y a crear conflictos insalvables.

La ley de hierro: Cada aplicación pesada debe tener su propio prefijo aislado.

# Crear un prefijo "C:\ limpio" específicamente para FL Studio
WINEPREFIX=~/.wine-flstudio winecfg

Este comando abrirá una ventana de configuración de Windows 10, y generará un disco C:\ virgen en esa carpeta oculta.

8.6.2 Winetricks y Manipulación de DLLs

Cuando instalas FL Studio, al intentar arrancar, es probable que crashee en silencio. ¿Por qué? Porque FL Studio espera que tu "Windows" tenga las librerías C++ Redistributables de Microsoft y ciertas tipografías nativas que el instalador asume que vienen de fábrica. Como Wine es ingeniería inversa legal, no incluye código patentado de Microsoft. Para inyectarlo, usamos Winetricks, un script mágico.

sudo pacman -S winetricks

Para descargar e inyectar silenciosamente el Framework .NET 4.8, DirectX 9 y las tipografías de Microsoft (Arial, etc.) en nuestro contenedor de FL Studio:

WINEPREFIX=~/.wine-flstudio winetricks dotnet48 d3dcompiler_47 corefonts vcrun2015

El script descargará los instaladores oficiales .exe desde los servidores de Microsoft, extraerá los archivos .dll reales, y los sobreescribirá dentro del prefijo, indicándole al registro (user.reg) que debe usarlos (Override) en lugar de usar las implementaciones libres de Wine.

8.6.3 Edición del Registro de Windows

Al igual que en un sistema real, puedes inyectar llaves en el registro de la máquina simulada para solventar bugs (por ejemplo, escalar la interfaz si se ve demasiado pequeña en monitores 4K).

WINEPREFIX=~/.wine-flstudio wine regedit

Esta arquitectura aislada, reproducible y controlada por variables de entorno, permite a los SysAdmins empaquetar aplicaciones de Windows cerradas en scripts bash ejecutables con doble clic, logrando que el software propietario hostil corra domesticado en tu entorno libre.

Capítulo 9: Mantenimiento, Monitoreo y Rescate del Sistema↑ Inicio

Uno de los mitos más persistentes (e injustos) sobre Arch Linux es que "se rompe solo" con cada actualización. Esto es demostrablemente falso. Arch Linux no se rompe solo; los usuarios lo rompen al no leer, al hacer actualizaciones parciales, o al ignorar las alertas de los mantenimientos de configuración. En un modelo Rolling Release, tú eres el SysAdmin. Tienes el control total, y con ello, la responsabilidad. Este capítulo te enseñará las herramientas y hábitos para mantener una máquina Arch funcionando sin reinstalar durante una década entera.

9.1 Gestión de Cambios (Los archivos .pacnew)↑ Inicio

Cuando el equipo de desarrolladores de Arch (o de upstream) decide cambiar el comportamiento por defecto de un programa, modifican su archivo de configuración. Pero imagina el desastre si tú pasaste 3 horas modificando el archivo de configuración de tu servidor SSH (/etc/ssh/sshd_config) y de repente, una actualización rutinaria sobrescribe tu archivo con el nuevo archivo por defecto.

Para proteger tu trabajo, Pacman hace lo siguiente: Si detecta que has modificado un archivo de configuración, no lo sobrescribe. En su lugar, instala la nueva versión de configuración a un lado y la nombra con la extensión .pacnew (por ejemplo, /etc/ssh/sshd_config.pacnew). El programa seguirá usando tu archivo original.

El peligro: Si ignoras los archivos .pacnew durante meses o años, llegará un punto en que el código binario nuevo del programa exigirá una variable en el archivo de configuración que solo existe en el .pacnew, y como tú sigues usando el antiguo, el programa (o incluso tu sistema de arranque) fallará silenciosamente.

9.1.1 Resolución Profesional con pacdiff

Nunca busques los pacnew a mano. Instala la herramienta de utilidades del sistema pacutils (que contiene pacdiff) y un programa de combinación visual de archivos (Diffing) como meld (útil si estás en un entorno gráfico) o simplemente usa vimdiff (incluido en Vim).

sudo pacman -S pacutils meld

Para buscar, comparar y fusionar tus archivos de configuración periódicamente (recomendado una vez al mes):

sudo DIFFPROG=meld pacdiff

El script escaneará todo el sistema en un segundo y, si encuentra un .pacnew, te ofrecerá:

• Ver (View) las diferencias.
• Sobrescribir (Overwrite) tu archivo antiguo (si te das cuenta de que no habías modificado nada importante).
• Borrar (Remove) el archivo nuevo (si prefieres mantener el tuyo para siempre, bajo tu propio riesgo).
• Fusionar (Merge) las líneas usando meld, abriendo una ventana con dos columnas resaltando los cambios para que puedas arrastrar el nuevo código necesario sin borrar tus personalizaciones.

9.2 El Centro de Inteligencia: Lectura de Logs y dmesg↑ Inicio

Cuando algo falla en Windows, a menudo obtienes un código hexadecimal incomprensible (Ej. 0x80004005). En Linux, el sistema registra cada evento en formato de texto. Comprender dónde leer es el 90% del trabajo de diagnóstico.

9.2.1 El Búfer del Kernel (dmesg)

Durante el arranque, y mientras el sistema funciona, el Kernel habla consigo mismo y con los drivers antes incluso de que los demonios de registro puedan arrancar. Este es el registro de nivel de hardware (Ring 0). Si tienes un disco duro a punto de morir por fallos mecánicos de I/O, o si conectas un USB corrupto, aquí es donde saltan las alarmas en rojo.

Para ver los mensajes del kernel, usa el anillo de diagnóstico:

sudo dmesg -H

(El flag -H lo hace humanamente legible, paginando la salida y añadiendo fechas. Presiona espacio para bajar, q para salir). Para ver los mensajes en vivo mientras conectas dispositivos físicos: sudo dmesg -w.

9.2.2 Systemd Journal (journalctl)

Para todo el software a nivel de usuario (el servidor web, la interfaz gráfica, fallos de red), systemd recolecta los logs en un archivo binario centralizado ultra-rápido. Se consulta mediante la navaja suiza journalctl.

• Ver el registro de tu inicio de máquina actual (Boot):

    journalctl -b

• Ver los errores del Boot ANTERIOR (-1) al actual: (Crítico cuando tu PC se congeló completamente y tuviste que reiniciarlo por la fuerza; esto te dirá qué fue lo último que ocurrió antes del pantallazo).

    journalctl -b -1

• Filtrar solo errores de alta prioridad y catastróficos (prio 3 = err):

Este es el comando mágico si tu PC va mal y no sabes por qué. Limpia la basura (mensajes de información) y te da los fallos crudos:

    journalctl -p 3 -xb

• Seguimiento en tiempo real de un servicio problemático: (Ej. intentas conectar el bluetooth y falla en el panel superior; abres una terminal y observas el log en vivo).

    journalctl -u bluetooth.service -f

9.3 Control de Versiones: El Arte del Downgrade↑ Inicio

En un modelo Bleeding Edge como el de Arch, ocasionalmente los desarrolladores externos liberarán código con regresiones (bugs que rompen funcionalidades previamente estables). Si tras hacer un pacman -Syu descubres que tu navegador (ej. Firefox) lanza un "Segmentation Fault" y no abre, no entres en pánico ni intentes reinstalar Arch. Solucionarlo requiere literalmente un comando de 5 segundos.

9.3.1 Regresar a una versión local de la Caché

Como vimos en el Capítulo 5, pacman guarda todos los paquetes .pkg.tar.zst en /var/cache/pacman/pkg/ a menos que los borres explícitamente. Si tu Firefox se rompió al instalar la versión 126.0, simplemente instala forzosamente la versión antigua (ej. 125.0) que todavía tienes almacenada localmente:

# Usa la tecla Tab para autocompletar el nombre largo del archivo
sudo pacman -U /var/cache/pacman/pkg/firefox-125.0-1-x86_64.pkg.tar.zst

Esto desinstalará la nueva versión y pondrá la antigua. Pero hay un problema: mañana, al hacer pacman -Syu, pacman verá que tienes una versión vieja e intentará actualizarlo de nuevo. Para evitarlo temporalmente, edita /etc/pacman.conf y añade firefox a la línea IgnorePkg = firefox. (Recuerda quitarlo semanas después cuando el bug oficial se haya resuelto).

9.3.2 La Herramienta AUR 'downgrade'

Si limpiaste tu caché ayer, o el paquete se corrompió, pacman no te ayudará. Para este escenario existe la maravilla llamada downgrade (disponible en el AUR). Esta herramienta interroga a los servidores A.L.A. (Arch Linux Archive) donde la organización guarda copias masivas de cada paquete de Arch de los últimos años.

yay -S downgrade
sudo downgrade firefox

Aparecerá un menú listando las últimas 20 versiones de Firefox junto con las fechas. Escribes el número de la versión que funcionaba, el script la descarga del Archivo Histórico, la instala, y lo más importante, te pregunta si quieres añadir automáticamente el programa al IgnorePkg.

9.4 El Chroot de Rescate (Resurrección de un Sistema Caído)↑ Inicio

Incluso con las mejores prácticas, puedes cometer un error humano (por ejemplo, apagar el PC tirando del cable en mitad de la actualización del Kernel Linux o durante una regeneración de GRUB). Al encender el ordenador, verás el espantoso menú negro de GRUB Rescue, o un "Kernel Panic", y ninguna tecla responderá. El sistema operativo está "roto" y no puede arrancar.

Regla de Oro: Un sistema Linux con los datos intactos en el disco duro jamás está irreparablemente roto. Si puedes acceder a los archivos, puedes curarlo.

El protocolo de rescate quirúrgico utiliza tu USB de instalación de Arch Linux:

1. Fase 1: El Bypass. Inserta tu USB de Arch (el que usaste en el Capítulo 1) y enciende el PC arrancando desde él. Estás utilizando el Kernel del USB, esquivando el kernel roto de tu disco.
2. Fase 2: Conexión. Conéctate a internet (iwctl o cable), es indispensable.
3. Fase 3: El Montaje Forense. Monta tus discos estropeados exactamente como lo hiciste en la primera instalación:

    mount /dev/nvme0n1p3 /mnt
    mount /dev/nvme0n1p1 /mnt/boot

1. Fase 4: La Inyección (Chroot). Entra como un parásito en tu sistema roto.

    arch-chroot /mnt

1. Fase 5: La Operación. Ahora estás como usuario Root dentro de tu sistema estropeado, y tienes internet, pero la máquina respira gracias al USB. Aquí reparas el desastre:

• ¿El Kernel se corrompió a medias por un apagón? Reinstálalo: pacman -S linux
• ¿Actualizaste paquetes pero el sistema se congeló al medio? Fuerzas una resincronización total con la reparación de dependencias cruzadas: pacman -Syu
• ¿Dañaste el cargador de arranque GRUB? Vuelve a instalar el binario UEFI (como vimos en el Cap. 3): grub-install --target=x86_64-efi --efi-directory=/boot --bootloader-id=GRUB y luego grub-mkconfig -o /boot/grub/grub.cfg.
• ¿Olvidaste tu contraseña de Root o de Usuario? Ejecutas passwd tu_usuario, pones una nueva y listo (por eso el cifrado de disco LUKS es tan importante; cualquiera con un USB puede hacer este proceso chroot y cambiar tu contraseña si te roban el PC).

1. Fase 6: La Salida. Cierra el chroot (exit), desmonta (umount -R /mnt) y reinicia.

Tu sistema se levantará de sus cenizas, perfectamente funcional, sin perder un solo byte de datos. Este es el verdadero poder del control del sistema en The Arch Way.

9.5 La Red de Seguridad Definitiva: Btrfs y Snapshots (Snapper)↑ Inicio

Todo lo que has leído en este manual sobre cómo arreglar el sistema con un USB de rescate (Capítulo 9.4) asume que tienes tiempo y ganas. Pero, ¿y si estás a punto de dar una presentación a inversores, haces un pacman -Syu, se rompe el servidor gráfico, y la reunión empieza en 2 minutos? No tienes tiempo para hacer Chroot forense.

Si, durante el Capítulo 2, formateaste tu partición raíz / utilizando el moderno sistema de archivos Btrfs, posees el superpoder de los Snapshots Atómicos.

Btrfs no sobreescribe archivos cuando los cambias (Copy-on-Write). Si instalas un paquete, Btrfs guarda los bloques de datos nuevos en otro lugar. Un "Snapshot" en Btrfs es una simple fotografía instantánea (tarda milisegundos y ocupa 0 kilobytes adicionales) del estado exacto de tu sistema.

9.5.1 Instalación y Configuración de Snapper

La herramienta creada por SUSE para gestionar esta magia es snapper.

sudo pacman -S snapper

Creamos el archivo de configuración para la raíz (/):

sudo snapper -c root create-config /

A partir de este instante, puedes decirle al sistema operativo: "Fotografía toda la partición C: ahora mismo":

sudo snapper -c root create --description "Antes de la locura"

9.5.2 Automatización con Pacman Hooks

Nadie se acuerda de tomar fotografías antes de actualizar. Lo configuraremos para que pacman lo haga por sí solo. Instalamos el gancho:

yay -S snap-pac

La próxima vez que escribas sudo pacman -Syu, antes de descargar un solo paquete, el sistema congelará un snapshot "Pre". Al finalizar la instalación, congelará un snapshot "Post". Podrás usar snapper diff para ver exactamente qué bloques de disco cambió la actualización.

9.5.3 Viaje en el Tiempo (Rollback en el Arranque)

Si tu actualización rompe el PC, reinicias. Gracias a integraciones avanzadas (como grub-btrfs), el propio menú negro de tu GRUB tendrá un nuevo apartado llamado "Arch Linux Snapshots". Seleccionas el snapshot de ayer por la tarde, y el sistema arranca exactamente como estaba ayer. Para hacer que ese viaje temporal sea permanente, usas un script restaurador (o comandos manuales en subvolúmenes Btrfs) para promocionar la foto antigua a disco principal.

Tu Arch Linux acaba de volverse literalmente inmortal a los errores de software.

9.6 Monitorización Fina de Hardware y Prevención de Desastres↑ Inicio

Para mantener un servidor o un equipo de alto rendimiento vivo, no puedes esperar a que el Kernel arroje alertas en rojo en dmesg. Debes inspeccionar el estrés físico preventivamente.

9.6.1 Perfilado de Carga (htop / btop)

Los administradores UNIX desprecian los "Administradores de Tareas" gráficos de los entornos de escritorio por su ineficiencia e inexactitud matemática con los hilos de CPU.

• htop: El clásico intemporal. Muestra con precisión los estados de los procesos (R running, S sleeping, Z zombie), las fallas de páginas de memoria, y te permite disparar señales de la muerte (SIGKILL -9) instantáneamente a procesos traviesos.
• btop: El sucesor en C++. Tiene una interfaz C-UI (Character-UI) espectacular en la terminal, dibujando gráficos continuos de ancho de banda de red, operaciones del disco (I/O) y temperaturas por núcleo, con una latencia de actualización inferior a 100 milisegundos.

sudo pacman -S btop

9.6.2 Termodinámica (lm_sensors)

Las placas base contienen docenas de sensores de temperatura (chipsets, puentes norte/sur, vrm, núcleos de CPU). Linux debe mapearlos.

sudo pacman -S lm_sensors

Ejecuta el asistente de detección (responde YES a todo, analizará los buses i2c de tu hardware buscando chips):

sudo sensors-detect

A partir de entonces, escribir sensors en la terminal te arrojará el estado térmico exacto de tu máquina.

9.6.3 Salud del Disco Duro y Sectores Dañados (SMART)

Los SSDs y NVMe no fallan "poco a poco" con chasquidos mecánicos. Cuando mueren, lo hacen en una fracción de segundo, bloqueando permanentemente su controladora en modo solo lectura o borrando todo. La tecnología S.M.A.R.T (Self-Monitoring, Analysis and Reporting Technology) está dentro de cada disco para alertarte meses antes del fallo catastrófico.

sudo pacman -S smartmontools

Comprueba el estado de tu disco NVMe (ej. /dev/nvme0n1):

sudo smartctl -a /dev/nvme0n1

Presta atención colosal a la línea "Percentage Used" y "Critical Warning". Si el sistema detecta sectores reasignados (Spare blocks cayendo), es señal inminente para comprar un disco nuevo y clonar el sistema.

9.6.4 Purgando el Diario de Registro (Journald Limits)

Paradójicamente, la herramienta que vigila el PC (systemd journalctl) puede terminar asfixiándolo. Si tu tarjeta Wi-Fi está lanzando un error irrelevante 1000 veces por segundo porque su driver es verboso, el archivo binario del diario crecerá gigabytes de tamaño en un mes, devorando espacio en SSD de portátiles pequeños. Limita el tamaño histórico máximo en /etc/systemd/journald.conf:

[Journal]
SystemMaxUse=500M

Reinicia el demonio sudo systemctl restart systemd-journald. Así, Arch siempre mantendrá solo el medio gigabyte más reciente de historia clínica, destruyendo automáticamente los logs de hace meses.

Capítulo 10: Systemd - Orquestación, Timers y Automatización Avanzada↑ Inicio

En el corazón de casi todas las distribuciones modernas de Linux existe una suite de software que despierta amores pasionales y odios profundos en la comunidad UNIX: systemd. Desarrollado originalmente por Lennart Poettering, systemd reemplazó al antiguo y secuencial sistema SysVinit. Systemd no es un simple programa de arranque; es una plataforma colosal que gestiona desde la creación de redes y montaje de discos, hasta los registros de logs, la gestión de energía (suspensión/hibernación) y la resolución DNS. Es el Process ID 1 (PID 1), el padre supremo de todos los programas que se ejecutan en tu máquina.

Dominar systemd es separar al usuario casual del ingeniero de sistemas.

10.1 Arquitectura y Comandos Base (Systemctl)↑ Inicio

El comando maestro para interactuar con el sistema de inicio es systemctl. Todo en systemd se organiza en "Unidades" (Units). Una unidad puede ser un servicio (un programa en segundo plano, .service), un zócalo (un puerto de escucha, .socket), o un temporizador (como un reloj despertador, .timer).

10.1.1 Gestión de Servicios (Services)

Los demonios (daemons) tradicionales como SSHD, Nginx, o NetworkManager son archivos de unidades terminados en .service.

Comandos esenciales (asumiendo que operamos sobre bluetooth.service):

• Iniciar (Start): Lo enciende ahora mismo. No persistirá si reinicias el PC. sudo systemctl start bluetooth.service
• Detener (Stop): Lo apaga (envía una señal SIGTERM o SIGKILL). sudo systemctl stop bluetooth.service
• Habilitar (Enable): Modifica el sistema creando un enlace simbólico para que el servicio arranque automáticamente en el próximo reinicio. No lo enciende ahora. sudo systemctl enable bluetooth.service
• Deshabilitar (Disable): Rompe el enlace. Ya no arrancará con el sistema. sudo systemctl disable bluetooth.service
• El Atajo Maestro (Enable --now): Combina "enable" y "start". Lo enciende ahora y lo marca para el arranque futuro. sudo systemctl enable --now bluetooth.service
• Reiniciar (Restart): Apaga y enciende. Obligatorio tras cambiar un archivo de configuración del servicio (ej. en Nginx o SSH). sudo systemctl restart bluetooth.service

10.1.2 Targets (Los antiguos Runlevels)

En sistemas antiguos, usabas "runlevels" (niveles de ejecución, 1 a 6) para decirle al PC si debía arrancar en modo rescate (sin gráficos) o en modo completo. Systemd usa el concepto mucho más flexible de "Targets" (Agrupadores de servicios).

• multi-user.target: Equivalente al nivel de consola TTY (servidor sin interfaz gráfica). Agrupa todos los servicios de red y de consola.
• graphical.target: Equivalente a tu entorno de escritorio. Depende del multi-user pero añade los gestores de pantalla (GDM/SDDM).
• rescue.target: Inicia una consola root sin red ni discos montados extra (para reparar desastres).

Si por alguna razón quieres que tu PC arranque por defecto en consola pura sin iniciar tu entorno gráfico pesado (para convertir un portátil en un servidor o ahorrar batería), le ordenas a systemd que el target por defecto sea el texto:

sudo systemctl set-default multi-user.target

(Para revertir al modo gráfico: sudo systemctl set-default graphical.target).

10.2 Creación de tus Propias Unidades de Servicio (Unit Files)↑ Inicio

La verdadera potencia llega cuando aprendes que un archivo .service no es un programa complejo en C; es simplemente un archivo de texto de 10 líneas de fácil lectura. Como desarrollador o sysadmin, querrás que tu script de Python (un bot de Discord, una copia de seguridad o una app web en Node.js) corra permanentemente de fondo, se reinicie si el bot falla por un error de código y arranque solo.

Crea un archivo llamado mibot.service en el directorio sagrado de los administradores:

sudo nano /etc/systemd/system/mibot.service

Estructura profesional de un servicio en Node.js, por ejemplo:

[Unit]
Description=Mi Bot de Discord en Node.js
Documentation=https://mi-wiki-interna.com
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=francesc
Group=francesc
WorkingDirectory=/home/francesc/proyectos/mi_bot/
ExecStart=/usr/bin/node index.js
Restart=on-failure
RestartSec=5s
Environment="NODE_ENV=production"
Environment="PORT=8080"

[Install]
WantedBy=multi-user.target

Análisis profundo:

• After=network-online.target: (Orden de arranque). Esto es vital. Le dice a systemd que si intenta arrancar el bot en el segundo 2 del arranque, pero la red (Wi-Fi/Ethernet) no está disponible hasta el segundo 5, ponga en espera el arranque del bot. Si no lo pones, el bot fallará inmediatamente por falta de internet y no volverá a arrancar.
• User=francesc: Privilegios minimizados (Drop privileges). Un servidor web NUNCA debe correr como Root. Si alguien hackea el bot en Node.js, solo tendrá acceso a los archivos de mi usuario, no a todo el PC.
• Restart=on-failure: Resiliencia pura. Si el código Node.js sufre un fallo o el PC se queda sin RAM (OOM Killer), systemd esperará 5 segundos y lanzará un nuevo proceso limpio, manteniendo un tiempo de actividad (uptime) infinito sin tu intervención.

Después de crear o editar cualquier archivo en /etc/systemd/, el demonio principal debe releer los directorios para integrar los cambios antes de que puedas usar systemctl start:

sudo systemctl daemon-reload

10.3 Systemd Timers: El Fin de la Era Cron↑ Inicio

Durante décadas, los administradores UNIX usaron el demonio cron para programar tareas periódicas. Editabas un archivo crontab y añadías líneas criptográficas de asteriscos ( *). Cron tenía limitaciones horribles: no generaba buenos logs si fallaba el script, y si programabas un backup los sábados a las 4 AM y tu PC portátil estaba apagado, la tarea simplemente se perdía (a menos que añadieras anacron).

Systemd resolvió esto con los Timers. Un Timer es un reloj que, al sonar la alarma, dispara automáticamente un archivo .service con el mismo nombre. Requiere escribir más líneas, pero el control, la visibilidad de los logs (van a journalctl) y la confiabilidad son infinitamente superiores.

El Caso Práctico: Respaldo Diario Creamos el servicio que ejecuta el respaldo (/etc/systemd/system/respaldo.service):

[Unit]
Description=Ejecuta script Rsync de respaldo de documentos

[Service]
Type=oneshot
ExecStart=/usr/bin/bash /home/francesc/scripts/hacer_backup.sh
User=francesc

(Nota: Tipo oneshot indica que el servicio arranca, ejecuta la orden, y se detiene y marca como exitoso. No se queda corriendo permanentemente).

Creamos el Timer (reloj despertador) con el mismo nombre exacto (/etc/systemd/system/respaldo.timer):

[Unit]
Description=Timer para respaldo diario

[Timer]
# Se ejecuta todos los días a las 3:00 de la madrugada
OnCalendar=*-*-* 03:00:00
# Si el PC estaba apagado a las 3AM, hazlo inmediatamente al encenderlo
Persistent=true
# Espera de forma aleatoria hasta 15 minutos (para evitar picos de I/O en servidores)
RandomizedDelaySec=15m

[Install]
WantedBy=timers.target

Recargas el demonio, e inicias y habilitas EL TIMER (nunca el servicio, el timer se encargará de lanzar el servicio):

sudo systemctl daemon-reload
sudo systemctl enable --now respaldo.timer

Para ver el calendario estelar de tu sistema y comprobar la cuenta regresiva milimétrica de todas las tareas automatizadas:

systemctl list-timers --all

10.4 Auditoría de Rendimiento: systemd-analyze↑ Inicio

Systemd sabe exactamente en qué milisegundo arrancó el kernel y en qué milisegundo terminó de cargar el entorno gráfico. Ofrece utilidades de perfilado de rendimiento asombrosas para administradores obsesionados con la optimización.

Para ver cuánto tiempo tardó tu PC desde que presionaste el botón de encendido hasta que el sistema estuvo operativo:

systemd-analyze

Salida de ejemplo: Startup finished in 3.123s (kernel) + 2.456s (userspace) = 5.579s.

Si tu sistema tarda 30 segundos (en un SSD) y sientes que algo va mal, systemd te permite generar una lista culpabilizadora de cada servicio ordenado por tiempo de impacto en el arranque:

systemd-analyze blame

Al leer la lista, a menudo encontrarás servicios inútiles, como un comprobador de discos antiguos o el infame NetworkManager-wait-online.service (que bloquea el arranque hasta que detecta una IP real válida y suele tardar de 5 a 10 segundos). Si no tienes servicios web que requieran arrancar sabiendo que la red está lista estáticamente, puedes deshabilitarlo de forma segura:

sudo systemctl disable NetworkManager-wait-online.service

Para el ingeniero visual, systemd puede generar un gráfico vectorial (SVG) que dibuja un diagrama de Gantt exquisitamente detallado mostrando paralelismo, hilos y bloqueos en el arranque:

systemd-analyze plot > arranque_pc.svg

Ábrelo con tu navegador Firefox o Chrome y maravíllate de la ingeniería orquestada que ocurre en los primeros tres segundos de vida de tu Arch Linux.

10.5 Control de Recursos de CPU y Memoria (cgroups en Systemd)↑ Inicio

Systemd no es solo un inicializador de arranque; es una poderosa interfaz gráfica (en texto) para los Control Groups (cgroups) del Kernel de Linux. Los cgroups son la tecnología que hace posibles a los contenedores Docker, y systemd te permite utilizarlos directamente para domesticar cualquier programa problemático.

Imagina este escenario: Tienes un servidor en Arch Linux con 16 GB de RAM. Está ejecutando una base de datos vital y, simultáneamente, le dices que procese la codificación de un vídeo en 4K. El programa de vídeo utilizará instintivamente el 100% de tus núcleos de CPU y devorará los 16 GB de RAM. El servidor se congelará (OOM - Out of Memory) y las páginas web de tu base de datos dejarán de cargar para tus clientes.

Puedes usar systemd para "atar con cadenas" ese servicio. Abre tu archivo unitario (ej. video-encoder.service):

[Unit]
Description=Proceso pesado de video

[Service]
ExecStart=/usr/bin/ffmpeg -i video.mkv salida.mp4
# Limita brutalmente la RAM máxima. Si el proceso pide 2.1G, el kernel lo asesina instantáneamente.
MemoryMax=2G
# Le otorga el derecho a usar un núcleo y medio de CPU, y ni un 1% más, sin importar cuán libre esté el PC.
CPUQuota=150%
# Baja la prioridad del disco duro; si la base de datos quiere leer, el video se pone en pausa.
IOWeight=10

Al recargar (systemctl daemon-reload), este simple script en bash estará sujeto a las leyes físicas restrictivas del kernel de Linux. El programa creerá que está corriendo en un ordenador del año 2005. Esta es la arquitectura base de los servidores Cloud que te venden máquinas virtuales minúsculas.

10.5.1 Modificación Inyección Rápida (Drop-in files)

¿Y si el programa que devora la RAM es Firefox, que no instalaste tú a mano, sino pacman? Si editas el /usr/lib/systemd/system/firefox.service oficial, pacman lo sobrescribirá en la siguiente actualización y borrará tus MemoryMax. La solución son los Drop-in files (archivos de sobreescritura). Ejecutas:

sudo systemctl edit firefox.service

Se abrirá un editor en blanco. Escribes exclusivamente tus variables inyectoras:

[Service]
MemoryMax=8G

Systemd creará automáticamente una sub-carpeta /etc/systemd/system/firefox.service.d/override.conf. Al arrancar, leerá el archivo oficial y fusionará tus reglas sin destruirlo, manteniéndose a salvo de las actualizaciones.

10.6 Systemd-Nspawn: Contenedores Integrados (El Chroot con Esteroides)↑ Inicio

Si leíste el Capítulo 15 (Docker) y el Capítulo 9.4 (Arch-chroot), te habrás dado cuenta de que a veces necesitas un sistema operativo paralelo, pero Docker es demasiado complejo y añadir el demonio de Docker gasta memoria RAM extra.

El secreto mejor guardado de las distribuciones Linux es que ya vienen con un sistema de contenedores ultra-ligero de fábrica incrustado en systemd: systemd-nspawn. Se describe como un "Chroot con namespaces y aislamiento de red". Se usa masivamente por los ingenieros de Arch para compilar paquetes en arquitecturas diferentes o para probar virus/malware en un entorno cerrado sin la pesadez de una Máquina Virtual.

10.6.1 Levantando un Contenedor de Debian puro dentro de Arch

Imagina que un cliente te obliga a compilar un programa viejo, pero las librerías necesarias solo existen en los repositorios antiguos de Debian o Ubuntu. Instalaremos la herramienta de arranque Debian (debootstrap) en Arch:

sudo pacman -S debootstrap

1. Instalación del SO alienígena:

Creamos un directorio que actuará como el "disco duro C:" de nuestro contenedor, e instalamos el sistema operativo Debian 12 (bookworm) en él.

    mkdir ~/mi_debian
    sudo debootstrap bookworm ~/mi_debian http://deb.debian.org/debian

En 30 segundos, debootstrap habrá descargado un núcleo base de Debian completo (~300MB).

1. Arranque del Contenedor Nspawn:

Para "encender" la máquina, no usamos chroot (porque compartiría tus procesos de host, algo inseguro). Usamos nspawn pasándole el directorio raíz (D=Directory).

    sudo systemd-nspawn -D ~/mi_debian

En medio segundo, el prompt cambiará de [francesc@archlinux] a root@archlinux:~#. Pero no es Arch. Si ejecutas apt update, verás el gestor de paquetes de Debian trabajando. Si ejecutas htop, verás que el contenedor está aislado: no puede ver los procesos de tu Arch Linux. Estás en una cápsula sellada. Sales tecleando exit.

10.6.2 Machinectl: Orquestando Contenedores

Para gestionar docenas de estos nspawns como un profesional (igual que gestionarías Dockers), usamos el comando administrativo machinectl.

Si mueves tu contenedor Debian a la carpeta oficial de contenedores (/var/lib/machines/mi_debian), podrás ordenarle al núcleo systemd de Arch que lo trate como un sistema operativo dependiente:

• Arrancar en segundo plano: sudo machinectl start mi_debian
• Listar contenedores encendidos: sudo machinectl list
• Inyectarte (abrir terminal) en un contenedor encendido: sudo machinectl shell mi_debian
• Autostart (para que Debian arranque como servicio junto con tu Arch Linux al encender tu PC): sudo machinectl enable mi_debian

Dominar cgroups y nspawn es poseer el poder divino sobre los átomos y procesos de la computación distribuida, todo usando herramientas que siempre han estado ocultas, por defecto, en tu instalación base de Arch Linux.

Capítulo 11: Optimización Extrema y Rendimiento del Hardware↑ Inicio

El objetivo de instalar Arch Linux a menudo no es solo el minimalismo, sino la extracción sin piedad de cada gota de rendimiento de tu procesador (CPU), memoria (RAM) y almacenamiento (SSD/NVMe). Al evitar la hinchazón (bloat) de otras distribuciones, Arch te da una base limpia, pero existen palancas a nivel de kernel y de compilador que permanecen en posiciones conservadoras por defecto para garantizar compatibilidad con hardware de hace 15 años.

En este capítulo, vamos a romper esa compatibilidad retroactiva a favor de la velocidad pura, optimizando el sistema operativo genérico en un traje a medida para tu silicio actual.

11.1 Gestión de Memoria y Compresión al Vuelo (Zram y Zswap)↑ Inicio

Históricamente, cuando la memoria RAM se llenaba, el kernel "paginaba" (movía) bloques de memoria estáticos hacia el disco duro (partición Swap). En la era de los discos mecánicos, esto ralentizaba la máquina a niveles inoperables. En la era de los SSD, es más rápido, pero escribir gigabytes de memoria en el SSD constantemente destruye sus celdas de memoria (ciclos de escritura limitados / Terabytes Written).

La solución moderna, nacida en los sistemas de Android y ChromeOS, es usar compresión en RAM.

11.1.1 Zswap (Para sistemas con partición Swap física)

Zswap es un módulo del kernel que actúa como caché de compresión. Cuando el sistema decide expulsar una página de memoria al disco SSD, Zswap la intercepta, la comprime (a un 30% de su tamaño original mediante algoritmos rápidos como zstd o lz4) y la guarda en la propia RAM en un espacio reservado. Si Zswap se llena, entonces desborda y envía las cosas al disco. Zswap es ideal porque aprovecha tu partición Swap existente reduciendo drásticamente el desgaste del SSD.

Para activarlo en el arranque, editamos los parámetros del kernel en GRUB:

sudo nano /etc/default/grub

En la línea GRUBCMDLINELINUX_DEFAULT, añade:

zswap.enabled=1 zswap.compressor=zstd zswap.zpool=z3fold zswap.max_pool_percent=20

• compressor=zstd: Algoritmo de altísima eficiencia y velocidad decente.
• zpool=z3fold: Permite empaquetar hasta 3 páginas comprimidas en una sola página física.
• maxpoolpercent=20: Le dice a Zswap que puede usar hasta el 20% de tu RAM total para esta compresión de emergencia.

Actualiza GRUB: sudo grub-mkconfig -o /boot/grub/grub.cfg y reinicia.

11.1.2 Zram (Para sistemas SIN partición Swap en disco)

Si decidiste ser audaz y no hacer partición Swap en tu SSD, Zram es obligatorio. Zram engaña al sistema creando un disco duro irreal (Block device) que reside enteramente en la RAM, y le aplica compresión continua. Es la forma más rápida y moderna, recomendada fuertemente por Fedora.

Instalación usando el generador de systemd:

sudo pacman -S zram-generator

Crea el archivo de configuración:

sudo nano /etc/systemd/zram-generator.conf

Añade lo siguiente:

[zram0]
# Crea un bloque de Zram equivalente al 50% de la RAM total disponible
zram-size = ram / 2
compression-algorithm = zstd
# Úsalo como el Swap de mayor prioridad en el sistema
swap-priority = 100
fs-type = swap

Recarga systemd y actívalo en caliente:

sudo systemctl daemon-reload
sudo systemctl start systemd-zram-setup@zram0.service

Usa el comando zramctl para monitorizar en tiempo real cuántos megabytes estás ahorrando por compresión.

11.2 I/O Schedulers y Gobernadores de CPU↑ Inicio

El kernel de Linux actúa como un director de orquesta. Decide qué programa tiene derecho a hablar con el disco y por cuánto tiempo, y a qué velocidad debe vibrar el procesador.

11.2.1 El Programador de Entrada/Salida (I/O Scheduler)

No todos los discos son iguales. Un disco mecánico (HDD) necesita un planificador que lea los datos físicamente cercanos en el disco para no gastar tiempo moviendo la aguja magnética (bfq - Budget Fair Queueing). Los discos NVMe SSD no tienen partes móviles, por lo que el cuello de botella es simplemente cuántos comandos concurrentes puede procesar el chip de memoria. Para SSDs y NVMe modernos, se recomienda encarecidamente el scheduler mq-deadline o el kyber.

Comprueba qué scheduler estás usando en tu disco (ej. nvme0n1):

cat /sys/block/nvme0n1/queue/scheduler

La opción seleccionada estará entre corchetes, ej. [none] mq-deadline kyber bfq (En discos NVMe muy rápidos, none delega todo el trabajo al controlador físico del disco, siendo la opción óptima).

Para forzar el uso de bfq (si tienes un disco HDD lento y notas que el PC se traba cuando descargas un archivo grande), crea una regla udev:

sudo nano /etc/udev/rules.d/60-ioschedulers.rules

Añade:

ACTION=="add|change", KERNEL=="sd[a-z]|mmcblk[0-9]*", ATTR{queue/rotational}=="1", ATTR{queue/scheduler}="bfq"

11.2.2 Gobernadores de CPU (cpupower)

La tecnología de escalado de CPU moderna (P-State en Intel, CPPC en AMD) permite a tu placa base controlar el voltaje. Por defecto, Arch usa el gobernador powersave o schedutil para ahorrar energía bajando el reloj de la CPU a 800 MHz cuando no haces nada, y disparándolo a 4.5 GHz al abrir un programa.

En ordenadores de escritorio (sin batería que cuidar), esto causa milisegundos de latencia que los gamers puristas desprecian. Puedes forzar el modo de rendimiento perpetuo usando cpupower.

sudo pacman -S cpupower

Edita la configuración base (/etc/default/cpupower) y busca la variable del gobernador:

governor='performance'

Habilita el demonio:

sudo systemctl enable --now cpupower.service

(Nota: Tu PC estará consumiendo unos 15W o 20W más de energía inactivo y generará más calor, pero la reactividad del sistema al hacer clics o abrir ventanas será absoluta).

11.3 La Forja de Binarios (Optimizando makepkg.conf)↑ Inicio

Como usuario de Arch Linux, instalarás docenas de programas desde el AUR a lo largo de tu vida. Al hacer esto, descargas código fuente plano (lenguaje C, C++, Rust) y usas makepkg (el compilador envuelto) para traducirlo a código binario en tu propia computadora.

Por defecto, los desarrolladores de Arch configuran las banderas (flags) del compilador GCC (GNU Compiler Collection) de manera muy genérica: asumen que quieres construir un binario compatible con cualquier CPU (desde un Intel Pentium 4 de 2004 hasta un Ryzen 9 de 2024). Para lograr esa retrocompatibilidad, GCC desactiva el uso de instrucciones de vectorización matemáticas avanzadas (como AVX2, AVX-512) que están físicamente en tu CPU moderna y podrían calcular físicas, compresión o criptografía 10 veces más rápido.

Vamos a decirle a GCC: "Conoce el hardware sobre el que estás corriendo y compila código que solo funcione aquí, pero que corra más rápido que la luz".

Abre el archivo maestro del compilador:

sudo nano /etc/makepkg.conf

11.3.1 Arquitectura Nativa (CFLAGS y CXXFLAGS)

Busca la línea que comienza con CFLAGS=. Estará preconfigurada con -march=x86-64 -mtune=generic. Cámbialo por -march=native. Esta única palabra activa todos los silicios específicos de tu chip. Añadiremos también una bandera adicional -O3 (Nivel de optimización 3) que le pide a GCC que desenrolle bucles matemáticos en el código fuente, consumiendo más tiempo y RAM durante la compilación, pero generando un programa final que se ejecuta increíblemente rápido.

CFLAGS="-march=native -O3 -pipe -fno-plt -fexceptions ..."
CXXFLAGS="$CFLAGS" # C++ copia las mismas banderas que C

11.3.2 LTO (Link Time Optimization)

En un programa en C, el código está dividido en cientos de pequeños archivos. Tradicionalmente, el compilador los traduce por separado y al final los "pega" (Linker). Si activas el LTO, el compilador lee absolutamente todos los archivos de golpe, y es capaz de ver que una función en el archivo A llama a una función en el archivo B que realmente no hace nada, y las elimina o reestructura en conjunto. El LTO reduce el tamaño del programa (RAM) y aumenta enormemente la velocidad.

Busca la línea OPTIONS=() al final del archivo. Contiene opciones como (strip docs !libtool !staticlibs...). Añade lto sin el signo de exclamación para activarlo:

OPTIONS=(strip docs !libtool !staticlibs emptydirs zipman purge !debug lto)

11.3.3 Paralelismo en la Compilación (MAKEFLAGS)

Si tu CPU tiene 16 hilos (threads) y compilas un navegador como Chromium (que tarda 4 horas), por defecto makepkg usará un solo núcleo, y tardará... 3 días. Debemos decirle al programa make que lance tantos "trabajadores" como núcleos lógicos tenga tu CPU. Puedes averiguar cuántos núcleos lógicos tienes usando el comando nproc (pongamos que tienes un procesador de 8 núcleos lógicos).

Busca la variable MAKEFLAGS y desactiva el comentario:

MAKEFLAGS="-j8"

(Tip profesional: Pon -j9 o el número de tus núcleos + 1. De este modo, si un núcleo se queda atascado esperando lectura del disco, el otro hilo toma el trabajo).

11.3.4 Adiós a la Compresión Final

Cuando la compilación de un software enorme termina exitosamente, el paso final de makepkg es tomar todos los archivos generados y comprimirlos en un archivo .pkg.tar.zst para que pacman lo instale o tú puedas dárselo a un amigo. Esta compresión masiva (en algo como Firefox o Chrome) exige que tu procesador funcione al 100% durante largos minutos.

Si nunca vas a compartir tus paquetes compilados con otras computadoras por red y solo vas a instalarlos en tu PC, comprimirlos es un desperdicio de tiempo y energía estúpido. Busca las variables PKGEXT hacia el final del archivo y dile a makepkg que use el humilde formato tar sin compresión:

PKGEXT='.pkg.tar'

Al aplicar todos estos cambios, habrás forjado un sistema de construcción de software inigualable. Tus paquetes del AUR se compilarán en minutos utilizando el 100% del procesador, generarán código ensamblador perfectamente adaptado a las singularidades matemáticas de tu chip (AVX-512, SSE4), y prescindirán de compresión inútil al final del proceso.

Has afinado tu Arch Linux como un monoplaza de Fórmula 1.

11.4 Aceleración de Memoria Subyacente (HugePages y PGO)↑ Inicio

El sistema operativo estándar de Linux maneja la memoria RAM dividiéndola en "Páginas" de 4 Kilobytes. Si un programa como una máquina virtual, una base de datos de 20GB o un juego moderno de mundo abierto necesita 8 Gigabytes de RAM, el procesador tiene que buscar, rastrear y mapear 2 millones de páginas separadas. Esto provoca un fenómeno llamado "TLB Miss" (Fallo en el Translation Lookaside Buffer) dentro de tu CPU, generando micro-tirones y cuellos de botella masivos de latencia.

11.4.1 Transparent HugePages (THP)

La solución arquitectónica es usar HugePages (Páginas Gigantes). El kernel permite agrupar la memoria en bloques de 2 Megabytes, e incluso de 1 Gigabyte.

Por defecto, Arch Linux tiene THP en estado madvise (solo se activan si un programa explícitamente se lo suplica al kernel). Para cargas pesadas, podemos forzar al kernel a que siempre intente agrupar la memoria en bloques grandes de forma transparente.

Crearemos una regla para inyectar este comportamiento al encender la máquina. Usa systemd-tmpfiles:

sudo nano /etc/tmpfiles.d/thp.conf

Añade la siguiente orden del sistema:

w /sys/kernel/mm/transparent_hugepage/enabled - - - - always
w /sys/kernel/mm/transparent_hugepage/defrag - - - - defer+madvise

Al reiniciar, el kernel mapeará bloques gigantes. En emuladores de consola (RPCS3, Yuzu/Ryujinx) o en bases de datos Redis, la mejora de rendimiento puede superar el 15% inmediato.

11.4.2 Profile-Guided Optimization (PGO)

Mencionamos -O3 en el capítulo anterior para el compilador. Pero GCC no es adivino. No sabe cómo tú usas un programa. El PGO (Optimización Guiada por Perfiles) es la brujería definitiva de los compiladores. El proceso funciona así:

1. Compilas tu código de C/C++ añadiendo una bandera instrumentada (-fprofile-generate).
2. El compilador genera un programa "espía" (muy lento).
3. Usas ese programa durante unos minutos, haciéndolo hacer las cosas más exigentes (abriendo ventanas, calculando rutas). El programa guarda archivos estadísticos (perfiles).
4. Vuelves a recompilar el código fuente original, pero esta vez con la bandera -fprofile-use, alimentándole los archivos del paso 3.

El compilador ahora SABE estadísticamente que la función matemática A se llama 1 millón de veces por segundo, y la función B nunca se llama. GCC reordenará el código binario, colocando la función A justo en la primera línea de la memoria caché L1 de tu CPU. Navegadores como Firefox y el propio Kernel Linux pueden ser compilados con PGO y LTO simultáneamente (a través del AUR usando paquetes como firefox-pgo), logrando una agilidad que roza lo absurdo.

11.5 Optimizando la Pila de Red TCP/IP (Anillo 0)↑ Inicio

Aunque tu proveedor de Internet (ISP) te prometa "1 Gigabit", es muy probable que tus descargas y tiempos de respuesta estén siendo estrangulados en la propia placa base de tu máquina. El Kernel de Linux utiliza por defecto algoritmos de control de congestión de red diseñados en los años 80 para redes analógicas poco fiables (como TCP CUBIC).

Si usamos Arch Linux, podemos activar los algoritmos diseñados por Google para sus propios servidores de YouTube (TCP BBR), creados explícitamente para maximizar el ancho de banda y hundir la latencia.

11.5.1 TCP BBR (Bottleneck Bandwidth and RTT)

BBR no intenta adivinar si la red está congestionada contando los paquetes que se pierden (como hace el algoritmo viejo). BBR mide continuamente a qué velocidad la tubería puede enviar datos y los bombea a un ritmo matemático exacto para nunca llenar el búfer (evitando el bufferbloat interno).

Para habilitar BBR de forma persistente, inyectaremos parámetros del kernel modificando sysctl:

sudo nano /etc/sysctl.d/99-bbr.conf

Añade las siguientes líneas de ingeniería de red:

net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr

(Es obligatorio usar el planificador fq estricto en lugar de fq_codel para que BBR funcione a su máximo potencial).

11.5.2 TCP Fast Open (Acortando el Handshake)

Cuando visitas una web segura (HTTPS), tu PC y el servidor hacen una "danza" de tres pasos (SYN, SYN-ACK, ACK) antes de enviarte una sola imagen. TCP Fast Open (TFO) permite a tu PC guardar una cookie criptográfica tras la primera visita, de modo que en visitas posteriores envías la petición web "pegada" al mismísimo saludo (SYN), saltándote la danza. Añade al mismo archivo sysctl:

net.ipv4.tcp_fastopen = 3

(El valor 3 activa TFO tanto para conexiones salientes como entrantes, vital si usas Nginx local).

11.5.3 Explicit Congestion Notification (ECN)

Finalmente, habilitaremos ECN. Esto permite que los routers intermedios (de tu compañía telefónica) marquen los paquetes con un bit de "Cuidado, voy colapsado", en lugar de simplemente tirarlos a la basura, lo cual obligaría a tu Arch Linux a reenviarlos desde cero causando lag en juegos.

net.ipv4.tcp_ecn = 1

Tras escribir todo, ordena al kernel que asimile los cambios en caliente sin reiniciar:

sudo sysctl --system

Tu pila de red ha evolucionado tres décadas en cinco líneas de texto. Tu rendimiento de subida a servidores lejanos (ej. subir archivos desde España a Japón) verá un incremento exponencial en estabilidad y MB/s sostenidos.

Capítulo 12: Kernels Personalizados y Arquitectura Modular↑ Inicio

En su definición más estricta, "Linux" no es el sistema operativo que estás usando (tu sistema operativo completo es Arch, o más técnicamente, una variante de GNU/Linux). Linux es exclusivamente el Kernel: un megabyte de código compilado que ostenta privilegios (Ring 0) absolutos sobre la CPU y la memoria. Administra los procesos y traduce los comandos del ratón o el disco duro a impulsos eléctricos comprensibles por el hardware.

Arch Linux utiliza un Kernel de Linux de tipo Monolítico Modular. Esto significa que es un solo bloque de código enorme que se carga al inicio, pero tiene la capacidad mágica de insertar o extraer "módulos" (drivers de red, Bluetooth) en caliente mientras el PC funciona (modprobe), sin requerir reinicios.

Entender, gestionar e incluso compilar tus propios Kernels en lugar de aceptar el predeterminado marca la transición definitiva hacia la maestría en sistemas UNIX.

12.1 Los Cuatro Jinetes: Kernels Oficiales de Arch↑ Inicio

La organización de Arch Linux pre-compila y distribuye oficialmente cuatro sabores (sabores) del kernel Linux. Convivir con varios de ellos a la vez en tu disco duro no solo es posible, es la recomendación oficial. Si una actualización de software crítico introduce un bug de kernel panic, en el siguiente arranque (desde GRUB) seleccionas tu Kernel de reserva y vuelves al trabajo instantáneamente.

12.1.1 linux (El Vainilla Rolling Release)

sudo pacman -S linux linux-headers

Es el paquete instalado por defecto. Sigue directamente la rama estable (stable tree) de Linus Torvalds. Contiene un equilibrio conservador en sus parches. Es tu caballo de batalla diario. (Nota técnica: El paquete -headers es obligatorio. Contiene los archivos en código C y las interfaces que programas como VirtualBox o DKMS de NVIDIA requieren para compilar sus propios módulos contra tu versión del kernel).

12.1.2 linux-lts (Long Term Support - El Salvavidas)

sudo pacman -S linux-lts linux-lts-headers

El desarrollo de Linux avanza vertiginosamente. Cada ~10 semanas se libera una versión mayor (ej. de 6.8 a 6.9). Si usas el kernel linux, estarás sujeto a esos saltos masivos. Si una actualización del código de red de Intel en 6.9 rompe tu tarjeta Wi-Fi, tu vida será miserable. Una vez al año, Torvalds y Greg Kroah-Hartman nombran una versión como LTS. Esta versión (ej. 6.6) se congela y recibe únicamente parches de seguridad durante 2 a 6 años. Instalar el kernel LTS es mandatorio como respaldo. Si usas Arch como servidor (VPS), este es el único kernel que deberías arrancar.

12.1.3 linux-zen (Respuesta en Tiempo Real y Latencia)

sudo pacman -S linux-zen linux-zen-headers

Desarrollado de forma comunitaria (basado en el histórico proyecto Liquorix), zen está fuertemente parcheado con un objetivo claro en mente: interactividad extrema en el escritorio y gaming. Mientras que un kernel estándar de servidor (LTS) está diseñado para procesar bloques masivos de datos (ej. un servidor de base de datos) dándole a un solo proceso cientos de milisegundos ininterrumpidos en el procesador (High Throughput / Batching), el kernel Zen es hiperactivo y ansioso. Utiliza planificadores (schedulers) de baja latencia que cortan los tiempos de CPU en rodajas pequeñísimas (Time Slices). ¿El resultado? Si pones tu CPU al 100% renderizando un video en 4K, y mueves el ratón, el kernel Zen interrumpirá el renderizado durante medio microsegundo para procesar tu ratón y dibujar la interfaz gráfica. Tu PC se siente liso como la seda, incluso bajo un estrés aplastante.

12.1.4 linux-hardened (Para Paranoicos de Seguridad)

sudo pacman -S linux-hardened linux-hardened-headers

Este kernel incluye un masivo parche de seguridad externo (procedente de proyectos de alta seguridad de Android como GrapheneOS). Cierra un centenar de puertas traseras teóricas, prohíbe a la memoria RAM de nivel usuario acceder accidentalmente a espacios kernel (reforzando KASLR), y restringe las funciones BPF a usuarios sin privilegios. La desventaja: El rendimiento del equipo se reducirá entre un 3% y un 10%, y programas como VirtualBox a menudo no funcionarán correctamente. Ideal si vas a dar charlas en convenciones de hackers como la DEFCON o usas redes WiFi públicas no confiables.

12.2 Gestión Interna: Initramfs y Pacman Hooks↑ Inicio

Cuando compraste el paquete linux-zen e instalaste 200 megas de datos, ocurrió una magia silenciosa bajo el capó de la que eres totalmente responsable. Un Kernel no puede arrancar solo desde un disco duro complejo (como un disco NVMe formateado en Btrfs o cifrado con LUKS) porque el Kernel necesita el driver "Btrfs" para leer el disco... pero el driver está dentro del disco. Un círculo vicioso.

La solución es el Initramfs (Initial RAM File System). Es un mini-sistema operativo comprimido (del tamaño de 15MB) que el gestor de arranque (GRUB) carga en la memoria RAM junto con el Kernel. Contiene las herramientas de desencriptación de discos, soporte LVM y comandos bash básicos. Desde ahí, el Kernel se levanta a sí mismo y transfiere el control a tu disco duro principal.

12.2.1 El Generador: mkinitcpio

Arch usa por defecto el programa mkinitcpio (un script de bash puro) para generar estos archivos initramfs. (Fedora usa dracut, que también está soportado en Arch).

Cuando pacman instala un nuevo Kernel (ej. una actualización del linux-lts), notarás que lanza un "Hook" (un gancho automático). Este hook llama a mkinitcpio, el cual analiza tu hardware actual (detecta si usas Ext4, teclados USB, tarjetas gráficas) e inmediatamente construye y comprime un archivo initramfs-linux-lts.img perfecto para tu máquina, soltándolo en /boot.

12.2.2 Añadiendo Módulos Tempranos (Early KMS)

Una de las optimizaciones obligatorias para el usuario moderno es lograr una transición visual limpia (sin destellos negros de pantalla) desde el menú GRUB hasta tu escritorio, habilitando gráficos de alta resolución desde el segundo cero. Esto se logra incrustando el enorme driver de tu tarjeta gráfica (que normalmente reside en /lib/modules/ en tu disco) directamente en el initramfs en RAM.

Abre el archivo de configuración del constructor:

sudo nano /etc/mkinitcpio.conf

Busca la matriz MODULES=(). Si tienes gráficos integrados Intel, añade i915. Si usas AMD, añade amdgpu. Si usas NVIDIA, añade nvidia nvidiamodeset nvidiauvm nvidia_drm.

MODULES=(amdgpu)

Como hemos alterado la receta de cómo se construye el initramfs, debemos regenerar manualmente todas las imágenes pre-compiladas de todos nuestros kernels. Ejecuta la orden masiva:

sudo mkinitcpio -P

12.3 El Grado Maestro: Compilando un Kernel Personalizado (linux-tkg)↑ Inicio

Si eres un purista, puedes descargar el código fuente C de Linus Torvalds de kernel.org y usar los temibles comandos make menuconfig (un menú de texto azul al estilo MS-DOS de los años 90 con más de 10,000 parámetros crípticos del kernel) seguido de un brutal make -j16.

Sin embargo, compilar un kernel a mano y empaquetarlo para pacman de forma limpia y desinstalable requiere escribir PKGBUILDs de cientos de líneas. La forma "Arch" contemporánea de compilar kernels artesanales ultra-optimizados (especialmente para Gaming y baja latencia) es utilizar herramientas orquestadoras de la comunidad, siendo Frogging-Family / linux-tkg la más reverenciada.

12.3.1 Despliegue de TKG

El proyecto linux-tkg te ofrece un script envoltorio que descarga el código del Kernel, aplica docenas de parches exclusivos que no están en el kernel oficial de Torvalds (optimizaciones extremas y experimentales que el equipo oficial considera demasiado agresivas o inestables) y automatiza la compilación con makepkg.

1. Clona el repositorio desde GitHub (nunca como root):

    git clone https://github.com/Frogging-Family/linux-tkg.git
    cd linux-tkg

1. Abre el archivo customization.cfg y lee las opciones con asombro. Aquí puedes elegir el algoritmo planificador del procesador (BORE, PDS, BMQ, CacULE). BORE, por ejemplo, es un scheduler que prioriza masivamente los videojuegos sobre los procesos del sistema en segundo plano. También puedes habilitar la compilación cruzada LTO y desactivar todo el hardware de depuración del kernel (debug symbols) para acelerar el arranque.
2. Ejecuta el constructor de Arch (que llamará al script de tkg):

    makepkg -si

El Asombroso Poder de localmodconfig: Durante el instalador interactivo de tkg, el script te preguntará si quieres usar localmodconfig. Si dices que sí (YES), el compilador mirará el estado de tu hardware EN ESTE EXACTO MOMENTO. Verá que tienes un ratón Logitech, un teclado Ducky y Wi-Fi Intel. Ignorará el código para ratones Razer, controladores de Xbox, cámaras web chinas de 1999 y antenas satélite de servidores IBM. El Kernel gigante (Vainilla) de 150 MB se compilará en un núcleo concentrado, minúsculo y puro de apenas 20 MB que entiende solo el universo de hardware de tu propia habitación, y nada más. Arrancará en fracciones de segundo y consumirá una miseria de RAM.

(Advertencia final: Si compilas tu kernel con localmodconfig y mañana te compras una tarjeta Wi-Fi de otra marca o un mando de PS5 y lo enchufas por USB, tu núcleo microscópico no sabrá qué son, no tendrá los módulos, y los dispositivos no funcionarán. Tendrás que recompilar el kernel conectándolos antes de iniciar).

Al finalizar la compilación y actualizar tu GRUB (grub-mkconfig -o /boot/grub/grub.cfg), reiniciarás la máquina y estarás corriendo un sistema donde hasta las fibras más bajas del metal y la silicona se curvan exactamente hacia tus necesidades.

12.4 Traspasando la Frontera: eBPF (Extended Berkeley Packet Filter)↑ Inicio

Imagina que tu Kernel de Arch Linux está fallando. Un proceso misterioso está escribiendo en el disco duro a 100 MB/s, y las herramientas de usuario como htop no te pueden decir quién es ni qué archivo exacto está escribiendo porque el proceso nace y muere en un milisegundo (ej. un cronjob corrupto). Tocar o depurar el Ring 0 es terrorífico: si el Kernel se detiene, el PC entra en pánico (Kernel Panic).

La tecnología moderna que ha revolucionado el análisis de Kernels se llama eBPF. Es una Máquina Virtual ultrasegura (y sandboxed) incrustada en el mismísimo corazón del Kernel Linux. Permite a los sysadmins inyectar microprogramas escritos en C que se "enganchan" (Hook) a funciones internas del Kernel en caliente. Si el programa que inyectas tiene un bug (un bucle infinito o intenta robar memoria ajena), la máquina virtual eBPF lo detiene antes de que se ejecute, asegurando que el servidor jamás colapse.

12.4.1 Instalación de Herramientas de Auditoría eBPF

No necesitas ser programador del núcleo para usar eBPF. Puedes instalar la colección de herramientas BCC y bpftrace, que traen decenas de scripts precompilados.

sudo pacman -S bcc-tools bpftrace

12.4.2 Diagnóstico Práctico de Syscalls

Por ejemplo, si sospechas de ese proceso misterioso devorando el disco, usaremos el script biosnoop basado en eBPF. Se engancha directamente a las instrucciones I/O de la controladora del disco:

sudo /usr/share/bcc/tools/biosnoop

Al presionar enter, la terminal quedará a la espera, ignorando los programas de usuario, imprimiendo cada milisegundo el PID, el nombre de la aplicación, el sector físico del disco y la cantidad de bytes exactos que se están escribiendo.

¿Quieres ver si alguien en el servidor está ejecutando el comando rm -rf (borrar todo) en secreto?

sudo /usr/share/bcc/tools/execsnoop

Te listará en tiempo real CADA comando (incluso los ocultos de medio segundo de vida) ejecutado por cualquier usuario. eBPF otorga un poder omnipresente sobre la máquina, un control divino sobre la estructura del código en el núcleo.

12.5 Compilación Industrial: ccache y distcc (Grado Servidor)↑ Inicio

Como vimos al generar kernels hiper-optimizados (Capítulo 12.3) con la flag -march=native, la compilación de millones de líneas de C/C++ (ya sea un Custom Kernel, el navegador Chromium, o un sistema operativo base entero) exige el 100% del procesador durante horas. Si posees un portátil ligero y le haces compilar el Kernel, es probable que se apague por sobrecalentamiento.

Para sortear las limitaciones físicas del silicio, usamos dos herramientas fundamentales del desarrollo empresarial.

12.5.1 La Caché de Compilación (ccache)

Si compilas el kernel hoy (versión 6.10.1), y mañana sale la actualización de seguridad 6.10.2, el 99.9% de los archivos C no han cambiado. Sería un estupidez que makepkg volviera a traducir esos archivos otra vez. Ccache es un programa que envuelve (wraps) a GCC. Cuando compilas un archivo, ccache guarda el resultado en una base de datos secreta oculta (~/.ccache/). Si mañana compilas un archivo con el mismo contenido exacto, ccache tira la orden a la basura, va a su base de datos, extrae el archivo pre-calculado y lo inyecta en milisegundos.

sudo pacman -S ccache

Para forzar a makepkg a usarlo, edita /etc/makepkg.conf: Busca la variable BUILDENV=() y quita el signo de exclamación de ccache para habilitarlo:

BUILDENV=(!distcc color ccache check !sign)

La primera compilación de un kernel TKG tardará 30 minutos. La segunda vez (la actualización de mañana), tardará 45 segundos.

12.5.2 Compilación Distribuida por Red (distcc)

Imagina el escenario: Estás en una oficina (o en tu casa) con tu portátil de 4 núcleos (débil). Pero en la misma red local tienes un ordenador de escritorio Gamer masivo de 16 núcleos (potente) que está inactivo, y tal vez un servidor de archivos antiguo de 8 núcleos. Distcc te permite hacer clustering de compilación.

Cuando escribas makepkg en tu portátil, tu portátil delegará los archivos por red TCP a las otras computadoras. El ordenador de escritorio gigante compilará 16 archivos a la vez, el servidor viejo otros 8, y te los devolverán ensamblados. Tu portátil apenas sudará, terminando compilaciones colosales en tiempos récord.

1. En las máquinas esclavas (Los PC potentes):

    sudo pacman -S distcc
    # Les decimos qué IPs de tu portátil tienen permiso para mandarles trabajo
    sudo nano /etc/conf.d/distccd
    # Añade: DISTCC_ARGS="--allow 192.168.1.0/24"
    sudo systemctl enable --now distccd.service

1. En la máquina maestra (Tu portátil):

    sudo pacman -S distcc

Dile a tu máquina dónde están sus sirvientes editando ~/.distcc/hosts:

    # IP del PC de escritorio (16 hilos) y el servidor viejo (8 hilos)
    192.168.1.50/16 192.168.1.60/8

1. Integración final en makepkg:

Edita de nuevo /etc/makepkg.conf. Habilita distcc en el BUILDENV y altera las MAKEFLAGS para desatar la furia de los 24 núcleos combinados de toda tu casa:

    BUILDENV=(distcc color ccache check !sign)
    MAKEFLAGS="-j25"

Has convertido la red de tu hogar en un clúster de supercomputación unificado de Arch Linux.

Capítulo 13: Criptografía y Seguridad Avanzada de Sistemas↑ Inicio

Linux es intrínsecamente seguro desde su concepción debido a su diseño de archivos multicliente UNIX (todo requiere el bendito sudo), pero Arch Linux sigue su doctrina de no hacer nada por defecto. Tu sistema recién instalado es un lienzo abierto de puertos. Si conectas el portátil a la red Wi-Fi de un aeropuerto, otras máquinas infectadas pueden llamar a tus puertos (escaneos Nmap). Si dejas tu PC físico en una cafetería, cualquiera con un USB puede arrancar en un entorno chroot y extraer tus contraseñas del navegador.

Este capítulo eleva la seguridad técnica y criptográfica del sistema de "consumidor descuidado" a "arquitectura inexpugnable".

13.1 El Cortafuegos del Kernel (Netfilter y UFW)↑ Inicio

La magia que bloquea peticiones de red maliciosas vive muy profundo en el Kernel, en un subsistema históricamente llamado netfilter (y en sus evoluciones iptables y el moderno nftables). Escribir las reglas criptográficas matemáticas para nftables a mano es un suicidio de cordura y productividad. Usamos programas front-end. Los dos grandes de la industria son firewalld (complejo, el estándar en Red Hat) y UFW (Uncomplicated Firewall, un diseño limpio creado por Canonical para Ubuntu, perfecto para equipos personales).

Instalación del Gestor de Firewall:

sudo pacman -S ufw

13.1.1 Configurando las Políticas de Defensa (Drop and Deny)

La política paranoica estándar (Default Policy) de un ordenador es simple: "Yo puedo llamar al exterior y nadie puede llamarme desde el exterior".

# Rechazar silenciosamente todas las conexiones que intentan entrar a mi PC
sudo ufw default deny incoming

# Permitir que los navegadores y juegos en mi PC llamen al exterior (Internet)
sudo ufw default allow outgoing

Abriendo Puertos por Necesidad (Whitelisting): Si eres desarrollador de páginas web (Node.js/React/Apache), puede que quieras ver en el móvil cómo queda la página web alojada temporalmente en tu PC local (puerto 80 para HTTP o 3000 para Node).

sudo ufw allow 80/tcp
sudo ufw allow 3000/tcp

Para ver un desglose visual y detallado de cómo están configuradas las reglas en este momento:

sudo ufw status verbose

Y por último, ordenarle al sistema que ponga un escudo permanente (persistente entre reinicios):

sudo ufw enable
sudo systemctl enable --now ufw.service

13.2 Blindando el Demonio SSH (Secure Shell)↑ Inicio

Si alquilas un VPS (Servidor Privado Virtual) con Arch Linux en la nube (ej. DigitalOcean, AWS), dependes enteramente de sshd para controlarlo remotamente desde tu PC. La configuración de fábrica del demonio OpenSSH es criminalmente ingenua y débil para el internet moderno, porque acepta "Autenticación por Contraseña".

Cualquier PC abierto a internet con el puerto 22 recibe aproximadamente entre 5.000 y 10.000 ataques diarios de Fuerza Bruta desde granjas de bots mundiales que prueban diccionarios infinitos (root, admin123, password) de forma automatizada hasta dar con el tuyo.

13.2.1 El Ecosistema de Claves Criptográficas Asimétricas

La única forma 100% invulnerable a la fuerza bruta es desactivar las contraseñas clásicas y usar criptografía de curva elíptica. Creas un par de llaves matemáticas generadas al azar, te quedas la llave Privada en el USB de tu casa (jamás abandona tu PC físico), y copias la llave Pública en el servidor. El servidor SSH enviará un rompecabezas matemático monstruoso y solo tu PC (usando la llave privada) puede resolverlo. No hay texto, no hay "adivinanza".

1. Generación de la Llave en tu PC Cliente: Usa el formato Ed25519 (algoritmo ultra-seguro y rápido moderno, nunca uses el anticuado RSA):

ssh-keygen -t ed25519 -C "llave_servidor_arch"

(Guarda en ~/.ssh/id_ed25519. Ponle una frase de paso para encriptar el propio archivo de la llave por si te hackean tu ordenador cliente).

2. Copia a la Máquina Remota:

ssh-copy-id -i ~/.ssh/id_ed25519.pub tu_usuario@192.168.1.100

(Deberás insertar la contraseña por texto la última vez, esto instala la llave en el servidor remoto ~/.ssh/authorized_keys).

13.2.2 Hardening de la Configuración del Servidor

En tu servidor remoto o máquina Arch, accede y modifica drásticamente las reglas maestras de SSH:

sudo nano /etc/ssh/sshd_config

Busca y modifica (descomentando) obligatoriamente:

• PasswordAuthentication no: El ataque de bots acaba de morir al 100%. Nadie puede digitar claves de texto.
• PermitRootLogin no: Si un atacante entra usando la clave que te robó, entrará a una cuenta de usuario normal. Prohíbes el inicio de sesión remoto directo de la cuenta de Dios (Root).
• Port 2244 (Opcional): Si cambias el puerto clásico 22 a uno oscuro, el 90% de los escáneres de bots masivos (nmap-zmap bots) de Rusia/China ni siquiera encontrarán tu puerta de entrada. (No olvides que tu Firewall UFW debe ser modificado para admitir el nuevo puerto).

Reinicia el candado del sistema: sudo systemctl restart sshd.service.

13.3 Aislamiento Funcional del Kernel con AppArmor↑ Inicio

Supongamos que tienes el mejor firewall del mundo (UFW), pero un día entras a una web y tu navegador Firefox descarga silenciosamente un script malicioso (Zero-Day Exploit). El script es ejecutado localmente, con tus permisos, y como Firefox tiene derecho a leer las fotos de tu carpeta Mis Imágenes o las llaves SSH (~/.ssh), el virus lo empaquetará y te robará todo. UFW de red no puede protegerte de ti mismo; necesitas una prisión de software local (Sandboxing).

En el ecosistema Linux existe SELinux (Complejidad absoluta, usado en Red Hat) y AppArmor (usado por Ubuntu y SuSE, muy intuitivo).

AppArmor añade Control de Acceso Obligatorio (MAC) en Anillo Cero (Ring 0 del Kernel). Asigna "Perfiles" estrictos a las aplicaciones de software, forzándolas al principio del "Principio de Mínimo Privilegio". Un perfil de Firefox dirá: "Firefox SÓLO tiene permiso, por orden del Kernel militar de la máquina, para tocar la carpeta ~/Descargas. Tiene denegado por hardware el acceso de lectura a ~/.ssh o ~/.gnupg". El ataque ha sido neutralizado de forma subyacente.

13.3.1 Activación en el Arranque (Parámetros Grub)

Instala AppArmor y el gigantesco set de perfiles creados por la comunidad de la Fundación Ubuntu y Debian:

sudo pacman -S apparmor

AppArmor no es un programa que se inicie solo. Es un LSM (Linux Security Module) que debe ser inyectado en el Kernel en el milisegundo número 1. Abre el gestor de arranque GRUB:

sudo nano /etc/default/grub

En la línea GRUBCMDLINELINUX_DEFAULT, añade al final de la línea estos parámetros masivos:

lsm=landlock,lockdown,yama,integrity,apparmor,bpf

(Estamos activando una batería completa de módulos de seguridad del Kernel: yama, integrity... AppArmor es uno de ellos).

Actualiza la tabla UEFI de la placa base: sudo grub-mkconfig -o /boot/grub/grub.cfg.

13.3.2 Activación de Demonios y Auditoría

Cuando reinicies el PC, el Kernel estará escuchando la aplicación de perfiles. Inicia el demonio de carga del espacio de usuario que inyectará los archivos en el Kernel en cada arranque:

sudo systemctl enable --now apparmor.service

Puedes monitorizar la magia subyacente usando una utilidad de diagnóstico como aa-status. Verás que cientos de perfiles (ej. libreoffice, evince, tcpdump) se encuentran marcados como [enforce] mode. Estás protegido. Cualquier violación del sistema generará una advertencia roja severa en tu log maestro dmesg.

13.4 Criptografía en Reposo: El Mandato de LUKS↑ Inicio

El firewall repele intrusiones cibernéticas; AppArmor neutraliza exploits internos. Pero si cierras tu portátil en una cafetería, te levantas a por servilletas y alguien se lo lleva corriendo, has perdido la guerra. Las contraseñas de Linux (y de Windows Local) viven lógicamente en un archivo (/etc/shadow). Un atacante sacará el SSD de tu portátil con un destornillador, lo conectará a su computadora, montará el archivo ignorando tu sistema operativo y leerá cada foto, documento y sesión de correo como un simple archivo de texto (Cleartext).

La defensa absoluta de la computación es la Criptografía de Disco Completo (FDE). En Linux, el subsistema se llama dm-crypt y el formato del envase se denomina LUKS (Linux Unified Key Setup).

La encriptación toma los millones de bits (ceros y unos) estructurados de tu partición Ext4, Btrfs o /home y, pasando por un bloque matemático brutal del núcleo de tu procesador (AES-XTS de 256 o 512 bits impulsado por hardware), convierte tus fotos y el sistema operativo entero en ruido blanco aleatorio radiactivo (Entropía alta). Si extraen tu disco duro, la policía científica, un ladrón o una agencia de inteligencia encontrarán miles de gigabytes de estática inútil. La única forma de revertir el ruido a datos puros es mediante la Contraseña Maestra de Desbloqueo (Passphrase) escrita en el gestor de arranque GRUB antes de arrancar.

13.4.1 La Realidad Pragmática de Implementar LUKS

A diferencia del Firewall o de AppArmor que puedes instalar un martes cualquiera, LUKS actúa directamente como un nivel destructor por debajo del formato del disco.

Instalar LUKS sobre un disco Ext4 que lleva funcionando un año no es realista. Requeriría comprimir todos tus datos, desencriptar in-place con herramientas extremadamente lentas, y si la luz se corta 1 milisegundo durante el proceso de 8 horas, perderás todo el disco para siempre. La implementación técnica profunda de LUKS exige planificación arquitectónica durante la Instalación (Capítulo 2 de este manual). Tras usar cfdisk, se invoca cryptsetup luksFormat /dev/nvme0n1p3, se desbloquea temporalmente el envase matemático (cryptsetup open), y dentro del contenedor desbloqueado recién se aplica el formato Ext4 con mkfs.ext4 /dev/mapper/root_encriptado.

Si lees esto con un portátil lleno de secretos corporativos y no tienes LUKS, la recomendación oficial de alta seguridad es: salva tu carpeta ~/.config y documentos críticos en un USB, realiza una instalación limpia desde cero (The Arch Way con Criptografía), y vive en un ecosistema donde una unidad robada es solo un trozo de plástico y aluminio inofensivo.

13.4.2 Auditoría Final (Lynis)

El sistema ahora es impenetrable a nivel de red, a nivel de procesos y a nivel de disco físico. Para confirmar este esfuerzo sobrehumano de SysAdmin, descarga la suite de hacking moral Lynis.

sudo pacman -S lynis
sudo lynis audit system

El script escaneará todos tus demonios y archivos, e imprimirá un reporte (Hardening Index) con recomendaciones (Ej. Deshabilita compiladores para usuarios sin privilegios). Tu Arch Linux ahora opera bajo estándares de certificación tipo militar (DoD).

13.5 Hardware de Seguridad: Autenticación FIDO2 (YubiKey)↑ Inicio

Incluso con contraseñas LUKS, llaves SSH Ed25519 o cifrado en el Kernel, el eslabón débil siempre será el teclado. Si tu ordenador está encendido, tu disco duro desencriptado y alguien planta un software espía (keylogger), capturará la contraseña de root cada vez que ejecutes sudo pacman -Syu.

En un ecosistema "Zero Trust" (Confianza Cero, el estándar en corporaciones como Google), ninguna clave escrita por teclado se considera segura. La máxima seguridad exige el protocolo U2F / FIDO2 (Universal 2nd Factor). Se implementa comprando un hardware criptográfico USB (como una YubiKey).

Este chip USB almacena una llave privada imposible de extraer físicamente (su circuito se autodestruye si intentan abrirlo).

13.5.1 Integrando YubiKey con Sudo (PAM)

En Arch Linux, podemos reescribir los módulos de autenticación de todo el sistema operativo (PAM - Pluggable Authentication Modules). Le diremos al sistema: "Cuando intente hacer un sudo, pídeme mi contraseña, pero SI NO TOCO FÍSICAMENTE el sensor dorado del USB insertado en la máquina, recházame el acceso". Un hacker de Rusia que controle tu PC a distancia no podrá tocar el USB físico de tu salón; sus comandos de destrucción fracasarán.

1. Instala las dependencias y el módulo PAM oficial de Yubico:

    sudo pacman -S yubico-pam libfido2

1. Mapea tu llave al usuario actual:

Inserta tu YubiKey. Genera un archivo de asociación en tu directorio home:

    mkdir -p ~/.yubico
    # Este comando genera un desafío FIDO que la llave resolverá (tócala cuando parpadee)
    pamu2fcfg > ~/.yubico/u2f_keys

1. Forzando el Comportamiento de Sudo:

Este es un paso crítico. Si lo haces mal, puedes bloquear tu propio acceso a root. Abre (con extrema precaución) el archivo de control PAM de sudo:

    sudo nano /etc/pam.d/sudo

Justo debajo de la línea que dice #%PAM-1.0, añade la siguiente instrucción:

    auth required pam_u2f.so

Abre una nueva terminal sin cerrar la actual. Escribe sudo ls. No te pedirá contraseña; la consola se quedará congelada. Tu YubiKey estará parpadeando furiosamente en verde. En el instante en que tu dedo haga contacto humano con el metal capacitivo de la llave, el comando ls se ejecutará. Si el USB no está insertado, el acceso es matemáticamente denegado.

13.6 Defensas Activas: Auditoría de Intrusiones (IDS) y Fail2Ban Expandido↑ Inicio

Un sistema expuesto a internet es como un castillo asediado de forma crónica. Las murallas pasivas (UFW Firewall, Capítulo 13.1) bloquean puertos cerrados. Pero, ¿qué ocurre con los puertos legítimos? Si alojas un servidor Nextcloud, Jellyfin, o una simple aplicación web en un puerto abierto, el atacante intentará reventar la pantalla de inicio de sesión (Login) de esa aplicación.

13.6.1 Expansión Brutal de Fail2Ban

Fail2Ban es un demonio escrito en Python que monitorea los archivos de Log (journald). Cuando observa demasiados errores seguidos desde la misma IP, inyecta una regla dinámicamente en el Firewall (UFW) para "banear" a ese atacante durante X horas.

sudo pacman -S fail2ban
sudo systemctl enable --now fail2ban.service

Por defecto, Fail2Ban solo se preocupa del puerto SSH. Pero podemos enseñarle a defender cualquier servicio, utilizando Regresiones Regulares (Regex) en archivos .local.

Protección Personalizada (El caso Nextcloud): Imagina un servidor en la nube (/var/log/nextcloud/nextcloud.log). Creas el filtro lógico (la máscara de la cerradura):

sudo nano /etc/fail2ban/filter.d/nextcloud.conf

Añades:

[Definition]
failregex = ^.*Login failed: .* \(Remote IP: '<HOST>'\).*$
ignoreregex =

Luego, activas "la cárcel" (Jail) añadiéndola al archivo local de jaulas:

sudo nano /etc/fail2ban/jail.local

[nextcloud]
enabled = true
port = http,https
filter = nextcloud
logpath = /var/log/nextcloud/nextcloud.log
maxretry = 3
bantime = 86400 # Si te equivocas 3 veces, bloqueado 24 horas (86400 segundos).

Reinicia el demonio (sudo systemctl restart fail2ban). Ahora posees un guardián de seguridad que patrulla continuamente los registros, estrangulando botnets enteras desde la capa de red del Kernel.

13.6.2 Auditoría Post-Brecha: Búsqueda de Rootkits

A pesar de AppArmor y LUKS, debemos ser humildes frente a actores patrocinados por Estados o vulnerabilidades Zero-Day de CPU (como Spectre o Meltdown). Si la brecha ha ocurrido, el atacante instalará un "Rootkit": un conjunto de código que modifica las herramientas estándar (ls, ps) de tu propio sistema operativo para hacerse invisible. Si un Rootkit está instalado, cuando haces htop para ver los procesos, el propio htop ha sido reprogramado maliciosamente para no mostrar el virus.

La cura son auditores externos e independientes: rkhunter (Rootkit Hunter) y chkrootkit.

sudo pacman -S rkhunter chkrootkit

Como precaución de salud mental para un servidor Arch Linux, puedes programar un systemd timer (Cap. 10) que ejecute estas herramientas durante la madrugada. sudo rkhunter --check

La herramienta descargará una base de datos de firmas criptográficas. Analizará si los binarios en tu /usr/bin/ coinciden con los que pacman instaló originalmente, o si han sido sobrescritos por un atacante.

Con este arsenal de llaves físicas U2F, jaulas de red reactivas y auditores binarios inmutables, has convertido tu servidor Arch Linux en una fortaleza paranoica de alta disponibilidad, capaz de sostener su soberanía en el núcleo hostil de Internet.

Capítulo 14: Arquitectura de Servidores Web (Pila LEMP Completa)↑ Inicio

Dado que Arch Linux siempre posee los paquetes binarios en su última versión (ej. las últimas compilaciones de PHP 8.x o Nginx 1.25+), montar un entorno de servidor web aquí resulta en una de las plataformas más rápidas del mercado. Muchos administradores evitan Arch en producción por miedo al modelo Rolling Release, pero si te saltas los paquetes del entorno gráfico y gestionas tu servidor "headless" (solo consola), su estabilidad y agilidad son formidables para un SysAdmin que sabe lo que hace.

Vamos a desplegar una arquitectura LEMP (Linux, Nginx, MariaDB, PHP), el estándar que desplaza a la antigua LAMP (que usaba Apache).

14.1 Nginx: El Proxy Inverso y Servidor Web Asíncrono↑ Inicio

Mientras que Apache (el estándar durante la década de los 2000) creaba un proceso/hilo nuevo de consumo de RAM por cada usuario que visitaba tu web (limitando la cantidad de visitas que tu PC podía aguantar), Nginx (pronunciado Engine-X) fue diseñado por el ruso Igor Sysoev con una arquitectura asíncrona (Event-driven). Un solo proceso de Nginx puede manejar más de 10,000 conexiones simultáneas utilizando casi cero RAM extra, y funciona de manera insuperable como proxy inverso (poniéndolo delante de un servidor Node.js o Python).

14.1.1 Instalación y Optimización Inicial

sudo pacman -S nginx

Antes de siquiera arrancar el servicio, ajustaremos el motor principal. Abre la configuración de Nginx:

sudo nano /etc/nginx/nginx.conf

En las primeras líneas, el comportamiento de los "Trabajadores" (Workers). Cambia worker_processes 1; por:

worker_processes  auto;
worker_rlimit_nofile 100000;

(Esto le dice a Nginx que despliegue tantos workers como núcleos de CPU tengas disponibles, y eleva el límite de archivos que el núcleo de Linux le permite mantener abiertos en simultáneo).

En la sección events:

events {
    worker_connections  4096;
    multi_accept on;
}

(Multi-accept permite al trabajador aceptar todas las conexiones nuevas a la vez, reduciendo la latencia masivamente cuando tu servidor sufre un pico de visitas - "Slashdot effect").

Habilita y arranca la bestia:

sudo systemctl enable --now nginx.service

(Nota de Firewall: Si seguiste el Cap. 13 de UFW, debes ejecutar sudo ufw allow 80/tcp y sudo ufw allow 443/tcp).

14.2 Motores Relacionales (MariaDB) y Almacenamiento↑ Inicio

El motor de base de datos relacional es el corazón del estado de tus aplicaciones (donde se guardan los usuarios, contraseñas, y artículos). Oracle compró MySQL y lo cerró parcialmente; el creador original hizo un fork (bifurcación) de su propio código y lo llamó MariaDB, garantizando que siempre sería Open Source. En Arch, son 100% intercambiables comando por comando.

14.2.1 Inicialización de Clúster en Arch

Un detalle técnico crítico: instalar el paquete MariaDB en Arch Linux NO crea el andamiaje del sistema de archivos donde viven las tablas InnoDB o los árboles B-Tree del sistema. Esto es intencional por seguridad (en Ubuntu se hace de forma oculta en un script deb-post-install).

1. Instala el motor:

   sudo pacman -S mariadb

1. Inicializa el clúster de datos obligatoriamente con el usuario mysql:

   sudo mariadb-install-db --user=mysql --basedir=/usr --datadir=/var/lib/mysql

1. Arranca el demonio:

   sudo systemctl enable --now mariadb.service

14.2.2 Hardening (Endurecimiento) de la Base de Datos

Un servidor de base de datos recién instalado es una bomba de relojería (cualquier usuario anónimo puede loguearse). MariaDB incluye un script para parchear estos agujeros. Ejecuta:

sudo mariadb-secure-installation

• Contraseña de Root (MariaDB): Te pedirá si deseas configurar autenticación con unix_socket. En Arch es altamente recomendado, ya que impide que alguien intente loguearse como root a la base de datos a menos que sea el usuario root físico de tu computadora en Linux.
• Dile "Y" (Yes) a borrar usuarios anónimos.
• Dile "Y" a deshabilitar el acceso remoto al usuario Root.
• Dile "Y" a borrar la base de datos de testeo.
• Dile "Y" a recargar los privilegios de tablas.

14.3 El Gestor de Procesos de Servidor: PHP-FPM↑ Inicio

Nginx, por su diseño hiper-eficiente, no incluye un procesador de código (no entiende PHP, Python o Ruby). Es puramente un sirviente de HTTP y despachador de archivos estáticos (imágenes, CSS). Para correr un sitio web dinámico (como WordPress), necesitamos instalar un procesador que corra paralelamente. Para PHP, el estándar es FastCGI Process Manager (PHP-FPM).

14.3.1 Instalación y Sockets UNIX

sudo pacman -S php php-fpm

PHP-FPM y Nginx necesitan comunicarse entre sí de forma furiosamente rápida (miles de veces por segundo). Podrían hablar enviando paquetes de red internos (TCP al puerto 127.0.0.1:9000), pero en la misma máquina física, esto gasta recursos de la pila TCP/IP del kernel. La solución profesional es usar un Socket UNIX, un archivo físico (generalmente /run/php-fpm/php-fpm.sock) que actúa como un túnel directo de memoria.

Habilitamos el servicio de PHP-FPM:

sudo systemctl enable --now php-fpm.service

14.3.2 Enrutando Nginx hacia PHP

Abre la configuración del "Server Block" (Virtual Host) de Nginx en /etc/nginx/nginx.conf. Busca el bloque que empieza con server { listen 80; ... }.

Modifícalo para que atrape todas las peticiones terminadas en .php y se las pase al Socket UNIX de php-fpm:

server {
    listen       80;
    server_name  mi-sitio-web.com www.mi-sitio-web.com;
    root   /usr/share/nginx/html;
    index  index.php index.html;

    location / {
        # Si el archivo no existe físicamente, mándaselo al enrutador (index.php)
        try_files $uri $uri/ /index.php?$args;
    }

    # Bloque FastCGI
    location ~ \.php$ {
        # Intercepta archivos php
        fastcgi_pass   unix:/run/php-fpm/php-fpm.sock;
        fastcgi_index  index.php;
        include        fastcgi.conf;
    }

    # Bloque de seguridad extra
    location ~ /\.ht {
        deny  all;
    }
}

Crea un archivo de prueba en /usr/share/nginx/html/info.php que contenga <?php phpinfo(); ?>, recarga nginx (sudo systemctl restart nginx.service) y visita tu IP en el navegador.

14.4 Criptografía SSL / TLS: Certbot de la EFF↑ Inicio

Alojar una web en HTTP (puerto 80) en el siglo XXI es inaceptable; todos los datos (incluidas las contraseñas de tus usuarios de WordPress) viajan en texto plano a lo largo de la red de cables submarinos, y los navegadores web modernos (Chrome/Firefox) penalizarán tu SEO o directamente bloquearán el acceso a tu sitio mostrando una pantalla roja de alerta de seguridad ("La conexión no es privada"). Antiguamente los certificados SSL/TLS (para que la barra de direcciones saliera verde con el "Candado") costaban cientos de dólares al año. Hoy, la Electronic Frontier Foundation (EFF) gestiona Let's Encrypt, que ofrece certificados gratuitos, cifrados, potentes y automatizados.

14.4.1 La Automatización Total de Certbot

Para que esto funcione, tu servidor Arch debe tener un dominio real (Ej. www.tu-web.com) apuntando a su IP pública desde tu registrador de dominios (Cloudflare, Namecheap), y los puertos 80 y 443 abiertos en el router de tu casa/VPS.

Instalamos la herramienta de línea de comandos de la EFF (Certbot) y su módulo especial para que hable con Nginx:

sudo pacman -S certbot certbot-nginx

El despliegue es brutalmente sencillo:

sudo certbot --nginx

El script de Certbot hará lo siguiente:

1. Leerá tu archivo /etc/nginx/nginx.conf buscando los bloques server_name.
2. Levantará un mini-servidor web para resolver un desafío criptográfico HTTP-01 con los servidores de Let's Encrypt para demostrar que posees la máquina física.
3. Descargará tu certificado .pem y la clave privada .key.
4. Magia: Certbot automáticamente modificará (escribirá código) en tu archivo nginx.conf, cerrando el bloque del puerto 80, forzando una redirección 301 al puerto 443 (HTTPS), e inyectando las rutas de tus certificados SSL.
5. Recargará Nginx de forma elegante sin interrumpir visitas.

14.4.2 Renovación Automatizada (Systemd Timer)

Los certificados de Let's Encrypt caducan en 90 días exactos para mitigar el daño en caso de robo criptográfico. Para evitar entrar por SSH cada tres meses, el paquete de Arch ya incluye un temporizador (certbot.timer) que comprueba los certificados dos veces al día y los renueva si quedan menos de 30 días para su expiración.

sudo systemctl enable --now certbot.timer

Has construido una pila completa de grado empresarial, segura, hiperrápida, asíncrona, y totalmente auto-renovable. Tu infraestructura está lista para alojar lo que se te ocurra.

14.5 Almacenamiento en Caché de RAM (Redis)↑ Inicio

Si tienes un blog de WordPress recibiendo 1,000 visitas por hora, tu base de datos MariaDB tendrá que leer los artículos del disco duro (SSD) y recalcular las consultas SQL 1,000 veces. Esto derretirá tu CPU. La solución de la industria para sitios web de alto tráfico no es mejorar MariaDB, sino colocar una base de datos en RAM hiper-rápida (Key-Value Store) justo delante de ella. El rey indiscutible de esto es Redis.

Redis almacena los datos más solicitados en la memoria RAM. La RAM es 100 veces más rápida que un SSD NVMe. Si la página existe en Redis, se le sirve al usuario en microsegundos, saltándose a MariaDB por completo.

14.5.1 Instalación y Optimización del Kernel para Redis

sudo pacman -S redis

Redis es extremadamente exigente con la forma en que el Kernel de Linux gestiona la memoria. Si arrancas Redis sin modificar tu kernel, arrojará alertas (Warnings) en sus logs de que su rendimiento está paralizado.

Debemos solucionar dos problemas en sysctl (/etc/sysctl.d/99-redis.conf):

# Redis necesita permiso para sobredemandar memoria (Overcommit)
vm.overcommit_memory = 1
# Redis necesita que desactivemos THP (Transparent HugePages) dinámico para evitar latencias de purga

Para desactivar THP (Si activaste THP en el Capítulo 11, debes crear una excepción para el servicio Redis en systemd ExecStartPre=/usr/bin/echo never > /sys/kernel/mm/transparent_hugepage/enabled).

Habilita y arranca Redis:

sudo systemctl enable --now redis.service

14.5.2 Integración (Object Cache)

Si usas PHP, debes instalar el módulo de comunicación:

sudo pacman -S php-redis

En tu aplicación web (ej. WordPress), instalas un plugin de Object Cache y le dices que apunte a 127.0.0.1:6379 (el puerto por defecto de Redis). A partir de ese momento, los tiempos de carga de tu página web caerán de 800ms a 40ms.

Redis también requiere una política de desalojo (Eviction Policy). Si tienes 2GB de RAM para Redis y se llena, ¿qué hace? Edita /etc/redis/redis.conf y configura:

maxmemory 2gb
maxmemory-policy allkeys-lru

(LRU = Least Recently Used. Borrará los datos que hace más tiempo que nadie visita, manteniendo el caché siempre fresco y sin colgar el servidor).

14.6 Proxy Inverso Avanzado y Balanceo de Carga↑ Inicio

Como exploramos en el Capítulo 14.1, Nginx es capaz de enrutar peticiones a PHP-FPM, pero su verdadero poder corporativo es actuar como un Proxy Inverso. Imagina que tienes una aplicación en Node.js corriendo en el puerto 3000, una API en Python (FastAPI) corriendo en el 8000, y tres contenedores Docker corriendo servidores de bases de datos. No quieres abrir todos esos puertos al mundo. Quieres que Nginx intercepte todo en el puerto 443 (HTTPS seguro) y distribuya el tráfico lógicamente.

14.6.1 Configuración de Proxy Pass

Abre la configuración de bloque de servidor (/etc/nginx/nginx.conf):

server {
    listen 443 ssl http2;
    server_name api.mi-sitio-web.com;

    # Certificados gestionados por Certbot (Capítulo 14.4)
    ssl_certificate /etc/letsencrypt/live/api.mi-sitio-web.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/api.mi-sitio-web.com/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:3000;
        
        # Estas cabeceras son CRÍTICAS. Sin ellas, la app Node.js pensará que la visita viene
        # del propio servidor (127.0.0.1) en lugar de la IP real del usuario de internet.
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

14.6.2 Balanceo de Carga (Load Balancing)

Si tu aplicación Node.js en el puerto 3000 se satura, puedes levantar tres copias de la misma aplicación en los puertos 3001, 3002 y 3003. Nginx puede repartir matemáticamente el tráfico entre las tres (Algoritmo Round-Robin) para que tu servidor maneje el triple de carga.

Añade el bloque upstream FUERA del bloque server:

upstream mi_app_node {
    server 127.0.0.1:3001;
    server 127.0.0.1:3002;
    server 127.0.0.1:3003;
}

Y luego, en lugar de enrutar a una IP fija, enrutas al grupo:

proxy_pass http://mi_app_node;

14.6.3 Cabeceras de Seguridad Militar (Security Headers)

Un servidor web mal configurado permite ataques de inyección (XSS) e Iframe-Hijacking. En Nginx, siempre inyecta estas cabeceras (Headers) en tu bloque principal:

# HSTS: Fuerza a los navegadores a recordar que tu sitio SÓLO funciona con HTTPS.
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
# Impide que otras webs incrusten tu página dentro de las suyas (Anti-Clickjacking).
add_header X-Frame-Options "SAMEORIGIN";
# Bloquea que los navegadores adivinen el tipo de archivo, mitigando ataques de scripts ocultos.
add_header X-Content-Type-Options "nosniff";

Con estas adiciones, tu infraestructura LEMP (Linux, Nginx, MariaDB, PHP/Node/Redis) pasará cualquier auditoría de seguridad bancaria o pruebas de estrés de Pentesting modernas, convirtiendo tu máquina Arch en un búnker de producción web inquebrantable.

Capítulo 15: Virtualización, Passthrough y Contenedores↑ Inicio

La computación moderna es la ciencia de mentirle al hardware. Le mentimos a un sistema operativo haciéndole creer que posee una máquina física (Virtualización) o le mentimos a una aplicación haciéndole creer que ella es la única habitante de la memoria (Contenedores). Como usuario avanzado de Arch, rara vez compilarás código en tu sistema anfitrión (host) por miedo a ensuciar tu preciada instalación con miles de dependencias huérfanas. Para las pruebas peligrosas, despliegues web o compilaciones locas, se utilizan entornos aislados.

15.1 La Era del Hypervisor Tipo 1: KVM y libvirt↑ Inicio

Existen Hypervisors de Tipo 2, como VirtualBox o VMware Player. Estos se ejecutan como un programa normal (igual que el navegador web) en el espacio de usuario, lo que añade una capa masiva de retardo en la interpretación de los comandos del disco y de la CPU.

En Linux, utilizamos un Hypervisor Tipo 1 llamado KVM (Kernel-based Virtual Machine). Al estar incrustado físicamente en el núcleo del sistema, KVM convierte al propio Arch Linux en un Hipervisor (Bare-Metal) con apenas un 2% de degradación de rendimiento. Usamos QEMU para emular las placas base, redes y periféricos, y la API libvirt para orquestar este caos.

15.1.1 Instalación del Ecosistema de Virtualización

sudo pacman -S qemu-desktop libvirt edk2-ovmf virt-manager dnsmasq

• edk2-ovmf: Es el firmware Open Source UEFI. Sin esto, tus máquinas virtuales no podrían usar discos GPT y estarían atrapadas simulando ser máquinas del año 2005.
• virt-manager: Una herramienta de interfaz gráfica GTK que abstrae todos los comandos dolorosos XML de libvirt, ofreciéndote una experiencia "a lo VirtualBox" pero con esteroides.

Añade tu usuario al grupo libvirt para no teclear contraseñas cada 2 minutos y arranca el demonio central:

sudo usermod -aG libvirt francesc
sudo systemctl enable --now libvirtd.service

15.1.2 VFIO PCI Passthrough (El Santo Grial del Gaming en VM)

(Teórico Avanzado) Uno de los logros técnicos más impresionantes de KVM es el PCI Passthrough. Si tienes dos tarjetas gráficas en tu PC de escritorio (por ejemplo, una Intel integrada y una NVIDIA RTX discreta), puedes aislar (bind) la tarjeta NVIDIA a través del grupo IOMMU de tu placa base e inyectarla físicamente dentro de tu máquina virtual de Windows 11. El resultado es un sistema operativo Arch Linux ejecutándose en la integrada en el monitor 1, y una máquina virtual de Windows ejecutándose en el monitor 2, usando los drivers oficiales NVIDIA de Windows, logrando un rendimiento de videojuegos nativo del 99%. Windows 11 no tiene forma de saber que está virtualizado y cree que es el propietario legal del silicio RTX. (Este proceso requiere la modificación del kernel IOMMU boot parameters y aislamientos complejos de VFIO).

15.2 La Arquitectura de los Contenedores: Docker↑ Inicio

Las Máquinas Virtuales (VM) simulan la placa base, instalan su propio Kernel (ej. 2GB de Windows), inician su propio disco duro, etc. Consumen muchísima RAM y tardan 30 segundos en arrancar. Los Contenedores son una tecnología exclusiva del Kernel de Linux. Utilizan cgroups (control de grupos de CPU/RAM) y namespaces (aislamiento de red, usuarios) para engañar al proceso. Un contenedor que corre un servidor web (Nginx) y la base de datos (PostgreSQL) comparte EXACTAMENTE EL MISMO KERNEL de tu Arch Linux. El contenedor pesa solo 30 megabytes (porque no contiene un sistema operativo, solo binarios y librerías del sistema), arranca en 0.2 segundos (porque el kernel ya está encendido), y consume la misma RAM que consumiría un proceso normal. Es ingeniería eficiente alienígena.

15.2.1 El Ecosistema Docker y el Demonio

sudo pacman -S docker docker-compose

Docker usa una arquitectura Cliente-Servidor. El cliente es el comando de la terminal, pero el Servidor es un proceso gigantesco (dockerd) que corre como root en segundo plano para orquestar la magia de red y almacenamiento.

sudo systemctl enable --now docker.service
sudo usermod -aG docker francesc

(Cierra sesión y vuelve a entrar. IMPORTANTE: En Linux, estar en el grupo docker es equivalente técnico a tener permisos irrestrictos de Root. Un usuario malicioso podría crear un contenedor y montar el disco /dev/nvme completo dentro de él).

15.2.2 Imágenes, Contenedores y Composiciones

En Docker, la plantilla de Solo Lectura se llama Imagen (Image), que tú descargas de un repositorio global (Docker Hub). Cuando le dices a Docker que "ejecute" esa imagen, Docker clona la plantilla y crea una capa escribible volátil encima, llamándolo Contenedor (Container).

Un comando rápido para ejecutar Ubuntu limpio dentro de tu Arch Linux sin instalar Ubuntu:

docker run -it ubuntu /bin/bash

La verdadera infraestructura (Docker Compose): En un entorno de desarrollo real, no usamos comandos sueltos larguísimos. Describimos la infraestructura en un archivo YAML declarativo y el ordenador lo levanta. Por ejemplo, si necesitas testear la nueva versión de Ghost CMS (un competidor de WordPress) y no quieres ensuciar tu sistema con paquetes de Node.js extraños o de MariaDB, creas un archivo docker-compose.yml en una carpeta vacía:

version: '3.1'
services:
  ghost:
    image: ghost:latest
    ports:
      - "8080:2368" # Mapea tu puerto 8080 local al puerto 2368 del contenedor
    environment:
      database__client: mysql
      database__connection__host: db
      database__connection__user: root
      database__connection__password: contraseña_secreta
      database__connection__database: ghost
  db:
    image: mysql:8.0
    environment:
      MYSQL_ROOT_PASSWORD: contraseña_secreta

Ejecutas desde la carpeta:

docker-compose up -d

En cuestión de 5 segundos, Docker descarga ambas imágenes, crea una red virtual aislada, levanta el MySQL, espera a que responda, levanta el gestor CMS y mapea tu puerto. Vas a localhost:8080 en tu navegador, y tu servidor web complejo está vivo. Cuando termines, ejecutas docker-compose down y el sistema, bases de datos y configuraciones se evaporan en el vacío, dejando tu Arch Linux completamente prístino.

15.3 La Evolución Segura: Podman (Daemonless y Rootless)↑ Inicio

Red Hat identificó tres vulnerabilidades severas en la arquitectura de Docker (y los reemplazó en OpenShift, su orquestador Kubernetes empresarial):

1. Dependencia del Demonio (SPOF - Single Point of Failure): Si el proceso dockerd (el servidor central) se traba y crashea, TODOS tus miles de contenedores se apagan simultáneamente, destruyendo el servidor.
2. Seguridad Root: El demonio siempre debe correr como superusuario, abriendo un abanico gigantesco de exploits (escapes del contenedor hacia la máquina anfitriona).
3. No amigable con Systemd: Al no poder interactuar bien con el sistema de inicio, manejar contenedores para que arranquen cuando el PC encienda es complicado de forma nativa.

La respuesta es Podman. Podman no tiene servidor central (Daemonless). Y lo más importante, Podman permite que tu usuario estándar (francesc) ejecute, descargue y construya contenedores complejos dentro del espacio de usuario normal sin usar NINGÚN permiso de superusuario (Rootless Containers). Si un malware rompe el contenedor de Podman, solo se encontrará con permisos del usuario estándar.

15.3.1 Instalación y Migración

sudo pacman -S podman podman-compose

La transición de Docker a Podman está diseñada para ser imperceptible. Los ingenieros clonaron exactamente los mismos comandos. De hecho, el manual oficial sugiere un truco en tu shell (~/.bashrc):

alias docker=podman
alias docker-compose=podman-compose

Al escribir esto, tus viejos scripts automatizados del trabajo para docker run ... invocarán subrepticiamente a Podman.

Podman también tiene el superpoder de exportar el estado de un contenedor al lenguaje nativo de systemd (.service), permitiéndote inyectar tu infraestructura directamente en los runlevels del sistema operativo sin demonios terceros molestando en medio, logrando la estabilidad absoluta del sistema Arch Linux que construiste.

15.4 Virtualización Ligera (LXC / LXD)↑ Inicio

Mientras que Docker y Podman (Capítulo 15.2) están diseñados bajo la filosofía "Un Proceso Por Contenedor" (es decir, levantas un Docker solo para correr Nginx, y otro Docker solo para correr la base de datos), existe otro paradigma: los Contenedores de Sistema.

Linux Containers (LXC) y su gestor hiper-avanzado LXD/Incus te permiten crear contenedores que se comportan exactamente como Máquinas Virtuales (tienen su propio systemd, su propio proceso de inicio, instalan cronjobs y múltiples aplicaciones dentro), pero usando el núcleo de tu Arch Linux subyacente. No hay emulación de CPU (KVM) ni hipervisor.

15.4.1 Inicializando el Ecosistema Incus

LXD era mantenido por Canonical (Ubuntu), pero tras un cambio de licencias cerrado, la comunidad Linux hizo un fork (Incus) que es el estándar actual adoptado por Arch Linux.

sudo pacman -S incus
sudo systemctl enable --now incus.service

Debes agregar tu usuario al grupo incus-admin y configurar el demonio respondiendo a las preguntas interactivas (asignar un bloque de disco ZFS o Btrfs, y crear un puente de red virtual):

sudo usermod -aG incus-admin francesc
sudo incus admin init

15.4.2 Lanzamiento de Sistemas Completos

Para lanzar un contenedor con Alpine Linux, Debian o incluso otra copia de Arch Linux dentro de tu host en menos de 1 segundo:

incus launch images:archlinux/current maquina-arch-2

Para entrar como root a esa máquina (que tendrá su propia IP interna, su propio firewall y sus propios demonios):

incus exec maquina-arch-2 -- bash

Esta arquitectura es utilizada por empresas de hosting (VPS) para alquilarte "Servidores Dedicados" baratos. Te están alquilando un contenedor LXC que, para ti, es indistinguible de una máquina física.

15.5 Orquestación a Gran Escala: Kubernetes (K3s)↑ Inicio

Cuando tienes 100 contenedores Docker repartidos entre 5 servidores físicos distintos, Docker Compose se queda corto. Si el Servidor 1 se quema físicamente, Docker no sabe cómo encender los contenedores perdidos en el Servidor 2 automáticamente.

Kubernetes (K8s) es el estándar absoluto de orquestación en la nube (inventado por Google). Es un sistema de Inteligencia Operativa que asegura que el estado deseado de tus aplicaciones se mantenga vivo sin importar el caos físico del hardware. Instalar Kubernetes puro "K8s The Hard Way" requiere un libro entero, pero Rancher Labs creó K3s, una distribución certificada hiper-ligera que elimina código viejo, perfecta para instalarse en un único nodo de Arch Linux o en un cluster de Raspberry Pis.

15.5.1 Instalación de K3s (Nodo Maestro)

K3s utiliza containerd (el sub-motor de Docker) y viene en un solo binario. En Arch, lo podemos instalar desde el AUR:

yay -S k3s-bin

Habilitamos el servicio como Nodo Servidor (Master/Control Plane):

sudo systemctl enable --now k3s.service

Para poder usar la herramienta cliente (kubectl) sin ser root, copiamos el archivo de configuración criptográfica del cluster:

mkdir ~/.kube
sudo cp /etc/rancher/k3s/k3s.yaml ~/.kube/config
sudo chown francesc:francesc ~/.kube/config

15.5.2 Conceptos de K8s: Pods e Ingress

Con K3s funcionando, ya no hablas con contenedores sueltos. Hablas en "Declaraciones". Le envías un archivo YAML al servidor maestro.

Un archivo despliegue.yaml clásico en K8s:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: mi-web-escalable
spec:
  replicas: 3 # ¡Magia! K8s levantará 3 copias y las mantendrá vivas
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - name: nginx-contenedor
        image: nginx:latest
        ports:
        - containerPort: 80

Aplicas la infraestructura:

kubectl apply -f despliegue.yaml

Verás nacer 3 "Pods" (cápsulas que contienen tus Dockers). Si usas el comando kubectl delete pod [nombre], emulando un fallo catastrófico, verás que el orquestador K3s, en menos de un segundo, se da cuenta de que faltan réplicas, y arranca un contenedor nuevo para compensarlo automáticamente.

K3s también incluye Traefik, un controlador Ingress (un Router inteligente que hace la misma labor de Proxy Inverso que Nginx, Capítulo 14, pero de forma dinámica y automática a medida que los contenedores nacen y mueren).

Con K3s corriendo en tu máquina local, tu ordenador Arch Linux se convierte en una plataforma de desarrollo Cloud-Native. Escribes código, lo empaquetas en un contenedor, y lo despliegas en tu Kubernetes local, asegurando que cuando lo subas a los clústeres masivos de Amazon AWS o Google Cloud, funcionará matemáticamente igual.

Capítulo 16: El Arte del Desarrollo de Software (The Developer's Arch)↑ Inicio

Has escalado una montaña técnica inmensa. Instalar y endurecer Arch Linux es un proceso formativo único que no muchos profesionales asumen, y si lo has completado, tienes un sistema hiper-ágil bajo tu mando. Arch Linux es, sin temor a equivocarnos, la máquina perfecta para el ingeniero de software, el programador y el Data Scientist.

En una distribución amigable como Ubuntu, si necesitas la versión v20.x de NodeJS, o el compilador de C++20, dependes de repositorios PPA de terceros mantenidos por dudosas cuentas de Launchpad. En Arch, todo está en tus repositorios en el mismo momento en que el código de esas empresas madura. En este capítulo blindaremos nuestros entornos para programar de forma sana y sin corromper el sistema subyacente.

16.1 La Filosofía de los Entornos Aislados (Sandboxing Lógico)↑ Inicio

La primera regla del desarrollo en sistemas Rolling Release: Jamás instales bibliotecas o dependencias globales de lenguajes usando gestores externos como pip (Python), npm (Node), o cargo (Rust) mediante la orden sudo. Si lo haces, el gestor de paquetes genérico (pip) sobrescribirá archivos en /usr/lib/ sin que pacman lo sepa. Meses después, pacman intentará instalar algo ahí y colapsará el sistema con un error de conflicto irreconciliable. Siempre se usan gestores de entorno (Environment Managers).

16.1.1 Ecosistema Python (Venv y PEP-668)

Python viene atado muy íntimamente al propio Arch Linux (muchas herramientas nativas del AUR lo usan). Si intentas hacer sudo pip install requests, Arch te expulsará con una alerta roja del protocolo PEP-668 informándote de que el entorno es "Exterally Managed" (gestionado por pacman).

Para programar en Python de forma segura:

1. Instala VirtualEnv:

    sudo pacman -S python-pip python-virtualenv

1. Crea el microclima de tu proyecto:

Al iniciar un proyecto, créale su propio entorno contenido localmente en la carpeta del proyecto.

    mkdir mi_proyecto_backend && cd mi_proyecto_backend
    python -m venv .venv

1. Activa el Entorno (The Source):

    source .venv/bin/activate

Tu prompt cambiará. A partir de ahora, todo lo que instales (ej. pip install Django) quedará atrapado en la carpeta oculta .venv y será ignorado por el sistema general.

16.1.2 Ecosistema JavaScript/TypeScript (NVM y Node)

El desarrollo Frontend cambia brutalmente rápido. Múltiples proyectos antiguos en los que colabores requerirán obligatoriamente versiones históricas (ej. NodeJS v14 para un proyecto legado, NodeJS v22 para tu app moderna). Instalar el paquete estático nodejs con pacman te arruinará la vida al limitarte a una sola versión.

El estándar empresarial es utilizar el Node Version Manager (NVM). Al ser un script externo, vive en el AUR:

yay -S nvm

Debes inyectar (sourcing) el entorno NVM en el arranque de tu consola interactiva (por ejemplo ~/.bashrc o ~/.zshrc).

echo 'source /usr/share/nvm/init-nvm.sh' >> ~/.bashrc
source ~/.bashrc

Controla el tiempo:

• Para descargar la última versión LTS recomendada para producción: nvm install --lts
• Para descargar la vieja versión 16: nvm install 16
• Para cambiar al instante de versión: nvm use 16
• Todas las instalaciones globales de NPM (ej. npm install -g yarn) se aislarán sanamente dentro de una carpeta oculta local (~/.nvm/).

16.1.3 Ecosistema C/C++ y Rust (El Lenguaje de Moda)

Rust es fundamental porque un número inmenso de herramientas nativas de Arch están reescribiéndose en Rust (incluso partes del kernel de Linux moderno). Al igual que NVM con Node, Rust tiene Rustup.

sudo pacman -S rustup
rustup default stable

(Esto descarga e inicializa los binarios del compilador rustc y el increíble gestor de dependencias cargo en la carpeta ~/.cargo/).

Para programar en C/C++, ya deberías tener el paquete instalador esencial para compilar cosas del AUR, que te provee del glorioso compilador GCC y Make:

# Ya los tienes si seguiste la guía, añadimos las herramientas de debug.
sudo pacman -S base-devel gdb clang cmake

Clang y CMake son la pareja ganadora para compilar C++ en IDEs modernos de forma instantánea.

16.2 Control de Versiones: Git a Nivel SysAdmin↑ Inicio

Eres programador. Necesitas a Git tanto como necesitas oxígeno.

sudo pacman -S git

Autenticación Asimétrica (Adiós Tokens Web): Clonar repositorios privados desde GitHub/GitLab mediante HTTPS requiere teclear engorrosos Tokens de acceso personales que caducan. El enfoque hacker es usar la llave SSH que generaste en el Capítulo 13. Ve a GitHub en la web -> Settings -> SSH and GPG keys -> New SSH Key. Pega allí el contenido público de tu llave generada por terminal:

cat ~/.ssh/id_ed25519.pub

Ahora puedes clonar código mágicamente sin contraseñas usando la URL de protocolo SSH de los repositorios: git clone git@github.com:torvalds/linux.git

Mejoras (Aliases del Dotfile .gitconfig): La configuración de git se guarda en tu home. Usa estos comandos para pintar la interfaz de colores y obligar al comando log a dibujar un gráfico ascii del árbol de versiones:

git config --global user.name "Tu Apellido"
git config --global user.email "developer@empresa.com"
git config --global color.ui auto
git config --global init.defaultBranch main
git config --global core.editor "nano"

# El super-alias de visualización de ramas:
git config --global alias.tree "log --graph --decorate --pretty=oneline --abbrev-commit"

Ahora al escribir git tree, verás todo el historial ramificado del repositorio en gloriosos colores.

16.3 Los Ambientes Integrados de Edición (IDE y Editores)↑ Inicio

Un maestro carpintero respeta sus herramientas. Elegir un editor en Linux (y en Arch) es casi una religión. Tienes dos filosofías predominantes: La usabilidad extensiva basada en interfaz gráfica (VSCode) y el minimalismo implacable de la terminal dominada por el teclado (Neovim).

16.3.1 Visual Studio Code: Cuidado con la Telemetría

Es innegable que VS Code es el campeón actual. Sin embargo, el archivo binario distribuido por Microsoft contiene Telemetría silenciosa (recolecta métricas de uso tuyas) y licencias propietarias cerradas.

Como usuario de Arch Linux, tienes acceso a Code OSS (Open Source Software), que es exactamente el mismo programa, construido directamente desde el código fuente por la comunidad de Arch, sin las inserciones de privacidad invasivas de Microsoft (Telemetría eliminada).

# La versión pura y libre en los repos oficiales
sudo pacman -S code

• Problema Práctico: Como esta versión libre no paga licencias a Microsoft, por políticas legales, Microsoft le prohíbe conectarse a su "Marketplace" oficial de extensiones, obligándote a usar el marketplace libre (OpenVSX).
• Solución (Si necesitas las extensiones privadas de Microsoft, ej. Remote-SSH o Pylance): Tienes que instalar la compilación propietaria oficial disponible en el AUR:

    yay -S visual-studio-code-bin

16.3.2 Neovim: El Editor del Desarrollador UNIX (Terminal)

Neovim no es solo una actualización de vim. Es una reescritura masiva de su núcleo que le permite funcionar asincrónicamente y, sobre todo, usar el lenguaje LUA para escribir configuraciones ultrarrápidas, logrando tener analizadores estáticos de código (LSP - Language Server Protocols, el motor detrás de VSCode) directamente integrados en tu consola.

sudo pacman -S neovim

Si ejecutas nvim, la curva de aprendizaje es monumental (no puedes ni siquiera moverte por el texto sin saber que la 'j' baja, la 'k' sube, y salir requiere el comando :wq). Para disfrutar del poder de un IDE sin configurarlo durante un mes seguido, instala una distribución de neovim mantenida por la comunidad, que convierte la consola estéril en un editor visual espectacular en 30 segundos, inyectando cientos de scripts lua (Ricing extremo).

Ejemplo de Distribución Neovim: NvChad Asegúrate de que tus tipografías Nerd Fonts están correctamente instaladas (Capítulo 7) y ejecuta:

# Haz una copia de seguridad por si tenías config previa
mv ~/.config/nvim ~/.config/nvim.bak
# Descarga el framework ultra rápido NvChad
git clone https://github.com/NvChad/starter ~/.config/nvim
# Ábrelo por primera vez para que él mismo compile sus plugins:
nvim

Te asombrará ver que dentro de tu vieja terminal negra vive un IDE fluido con autocompletado en milisegundos, análisis sintáctico de C++ y explorador de archivos estilo árbol, usando un 2% de la RAM que exigiría VS Code.

16.4 Fin de Trayecto (Conclusión del Sistema)↑ Inicio

Ha sido un largo viaje a través de los rincones del hardware y el software. Empezamos en una terminal negra con un error de arranque UEFI parpadeante. Formatemos bloques, montamos particiones ciegas, chrooteamos nuestra consciencia en el cerebro del sistema y construimos el universo base con pacstrap.

Luego, elevamos el esqueleto dotándolo de músculos (Kernel custom TKG, Optimización Flags C++ -march=native), sistema nervioso (NetworkManager y PipeWire) y un armazón irrompible de titanio (AppArmor, LUKS y UFW). Finalmente, le otorgamos visión y vida con Wayland, componiendo arte cristalino y fluido gracias a Hyprland y a nuestro obsesivo trabajo de Ricing, culminando en la forja de entornos aislados Docker y Python para transformar la máquina en la estación de producción soñada por cualquier ingeniero.

Has dominado la arquitectura fundamental del Sistema Operativo más maleable del mundo, has aprendido comandos que los manuales técnicos dan por sabidos y has entendido la teoría de por qué las cosas, a veces, se rompen. La distribución no fallará sola. Tienes el poder total sobre cada paquete. Arch Linux no asume que eres un idiota; asume que eres, o te convertirás, en un profesional de élite del software.

Bienvenido. El manual nunca termina. El manual, de hecho, se encuentra siempre actualizado en la Arch Wiki. Mucha suerte.

16.4 Lenguajes Compilados Modernos y Depuración (Go y Rust)↑ Inicio

Más allá de C/C++ y los lenguajes interpretados como Python, Arch Linux es el paraíso para los desarrolladores de sistemas modernos (Backend y CLI), donde lenguajes como Go (Golang) y Rust dominan el mercado del Cloud Computing.

16.4.1 El Ecosistema Golang

A diferencia de NodeJS o Python, el compilador de Go es increíblemente estático y genera binarios monolíticos autónomos. Puedes instalar la última versión directamente con pacman, sin miedo a romper el sistema (Go no usa dependencias compartidas C).

sudo pacman -S go

Históricamente, Go requería una estricta jerarquía de carpetas llamada GOPATH (típicamente ~/go). Hoy en día, gracias a los "Go Modules", puedes iniciar un proyecto en cualquier rincón de tu disco duro:

mkdir mi_api_go && cd mi_api_go
# Inicializa el rastreador de módulos apuntando a tu futuro repositorio
go mod init github.com/francesc/mi_api_go

Para compilar un programa de Go en Arch Linux y ordenarle al compilador que lo cruce (Cross-Compile) para que funcione en un servidor Windows antiguo de 32 bits, el comando es absurdamente simple gracias al toolchain nativo:

GOOS=windows GOARCH=386 go build -o mi_programa.exe

16.4.2 Depuración en Profundidad (GDB y Delve)

Escribir código con print() para encontrar errores es de aficionados. Los ingenieros de software usan Depuradores (Debuggers). Un depurador congela el programa en la memoria RAM en el momento exacto en que ocurre un fallo (o en un "Breakpoint" fijado por ti), permitiéndote inspeccionar las variables por dentro.

• Para C/C++ y Rust, se utiliza GDB (GNU Debugger) o LLDB (del proyecto LLVM).

    sudo pacman -S gdb lldb

• Para Go, el compilador aplica tantas optimizaciones que GDB se marea. El estándar de la industria financiado por Google es Delve:

    sudo pacman -S delve

Para cazar un bug en tu programa de Go, en lugar de ejecutar go run, inicias el depurador:

dlv debug main.go

En la consola de Delve, puedes teclear break main.go:25 (detente en la línea 25), luego continue. El código avanzará a la velocidad de la luz y se pausará mágicamente en la línea 25. Podrás escribir print miVariable para ver su contenido en vivo, descubriendo por qué tu software fallaba.

16.4.3 Perfilado de Rendimiento Extremo (Perf)

Si tu programa no tiene bugs, pero funciona lento, y no sabes qué función de tu código está ralentizando la ejecución, usas el perfilador del Kernel: Perf. Perf lee los contadores de hardware (Hardware Performance Counters) dentro del silicio de tu procesador (Intel/AMD).

sudo pacman -S perf
# Perfila el programa durante 10 segundos
sudo perf record -g ./mi_programa_lento
# Lee el reporte
sudo perf report

La terminal mostrará un árbol jerárquico revelando que, por ejemplo, el 45% del tiempo de CPU de tu programa se pierde en un ciclo for específico de la línea 104, debido a fallos de caché L1 (L1 Cache Misses). Es una radiografía a nivel atómico de tu software.

16.5 Integración Continua Local (CI/CD) y Git Hooks↑ Inicio

El desarrollo profesional dicta que ningún código debe ser enviado al servidor de producción (GitLab / GitHub) si antes no ha pasado por una batería de pruebas automatizadas (Testing) y análisis estático (Linting). En una empresa, estos procesos (CI/CD) corren en la nube y gastan costosos minutos de servidor.

En tu Arch Linux, puedes emular toda la infraestructura de la nube localmente, evitando subir código roto.

16.5.1 Git Hooks (La barrera de seguridad de los commits)

Los Git Hooks son scripts de bash ocultos dentro de tu repositorio (.git/hooks/) que Git ejecuta automáticamente al intentar realizar acciones. El más importante es el pre-commit. Si el script devuelve un error (Exit Code 1), Git abortará tu comando git commit y te prohibirá guardar el código, forzándote a arreglarlo.

En proyectos modernos (ej. Python o JavaScript), en lugar de escribir los scripts en bash a mano, se usa el gestor pre-commit (escrito en Python):

sudo pacman -S pre-commit

En la raíz de tu proyecto, creas un archivo .pre-commit-config.yaml:

repos:
-   repo: https://github.com/pre-commit/pre-commit-hooks
    rev: v4.4.0
    hooks:
    -   id: trailing-whitespace # Elimina espacios vacíos al final
    -   id: end-of-file-fixer   # Asegura un salto de línea al final
    -   id: check-yaml          # Asegura que tus archivos YAML no estén rotos

Instalas las barreras con el comando: pre-commit install. La próxima vez que escribas git commit -m "Mi cambio", el sistema parará el reloj, ejecutará las pruebas locales, arreglará el código si está sucio, y solo si todo aprueba, creará la versión.

16.5.2 GitHub Actions en Local (Act)

Si configuras GitHub Actions (.github/workflows/main.yml) para que lance contenedores Docker y pruebe tu base de datos cada vez que haces "push", normalmente tienes que subir el código, esperar 5 minutos en la web de GitHub, y ver si falla. Si falla, corriges una coma, vuelves a subir, y esperas otros 5 minutos.

La herramienta Act lee tu archivo YAML de GitHub, y usando tu demonio local de Docker (Capítulo 15), levanta las imágenes de Ubuntu virtuales de GitHub dentro de tu propio ordenador Arch Linux, ejecutando todas las pruebas en segundos.

Se instala a través del AUR (ya que está programado en Go):

yay -S act

Si estás en la carpeta de tu proyecto y escribes simplemente act, el programa descargará un contenedor Ubuntu de 3GB de tamaño que simula ser el servidor de Microsoft/GitHub, inyectará tu código, y ejecutará los tests (ej. npm run test o pytest). Si el test falla en act localmente, fallará en la nube. Al usar act, aceleras el bucle de retroalimentación de horas a minutos, desarrollando a una velocidad feroz.

16.6 Reflexión Final↑ Inicio

Has concluido la maestría. Tu Arch Linux no es solo un sistema operativo donde consumes contenido; es un laboratorio de ciberseguridad, un clúster de servidores, una estación de ensamblaje criptográfico, y una plataforma orquestadora en la nube. Eres el arquitecto indiscutible de tus propios dominios computacionales. Que el código siempre compile en la primera pasada, y que tu sistema nunca sufra un "Kernel Panic".