diff --git a/notas-jaime/guion-arch.html b/notas-jaime/guion-arch.html index e4603e6..c6d4a74 100644 --- a/notas-jaime/guion-arch.html +++ b/notas-jaime/guion-arch.html @@ -21,26 +21,20 @@ SO de Linux.
Daemonsde red (NetworkManager, iwd)
Note
kernel -> coreutils -> init -> network
Hacerlo como una progresión.
-boot loaderque se encarga de arrancar un -SO al encender el ordenador. También pueden ser
boot managers, -que además ofrecen menús y opciones para configurar que SO arrancar si -hay varios o incluso con que opciones.
mkdiral arrancar. A esto se le llama el
init, que es el -programa que se ejecuta al arrancar y se encarga de arrancar los -
serviciosen su orden correcto, como configurar el teclado, -arrancar el
daemonde red, etc, y mostrarnos nuestra interfaz de -usuario cuando todo esté listo.
Dejar daemon
un poco en el aire y desarrollarlo en
-NetworkManager como ejemplo.
Note
-En Network Manager
Hay muchas alternativas, NetworkManger es el todo en uno
, pero
hay paquetes para cosas mas pequeñas, iwd
con
@@ -234,12 +198,19 @@ kernel y ejecutarlo adecuadamente al arrancar el ordenador.
boot manager. +
El caso más popular y que lo incluye todo es grub, otras
+opciones populares son systemd-boot y
+limine.
Una vez el kernel arranca, este tiene programas instalados y esta
listo para ofrecer sus servicios, pero no puede ejecutar cualquier cosa
como mkdir. Entones se usa un init system, que consiste
simplemente en el primer programa que linux ejecuta al arrancar el
ordenador (por defecto se busca en /sbin/init).
El más popular (con diferencia) hoy en día es systemd, también es el +único que arch soporta de forma oficial. Aunque existen otros como +OpenRC, Runit, Dinit, S6, etc; que se pueden configurar en arch (aunque +para eso hay opciones mejores como usar Artix).
El trabajo de un init system completo es el de iniciar todas las
partes del sistema adecuadas, llamadas servicios
. Estos servicios
pueden ser programas simples que configuren el teclado, o programas que
@@ -256,6 +227,140 @@ fondo, normalmente manejados por el init system como un servicio.
Los daemons se suelen caracterizar con una d
al final
+del nombre (playerctl -> playerctld,
+udev -> udevd, ssh ->
+sshd, etc).
El más popular es NetworkManager, que es un todo en
+uno
de un daemon de red. Pero hay muchas otras opciones mas
+modulares, como iwd específico para configuración
+inalámbrica, systemd-networkd, o
+wpa_supplicant para certificados de wifi. Incluso
+configuraciones mixtas, NetworkManager se puede configurar
+para solo usar iwd, o que use dnsmasq para
+cache del DNS, etc.
Hasta ahora hemos visto el kernel, los creutils, un bootloader, el +init system y todos los servicios y daemons que puede haber. +Esto son muchísimos archivos y manejarlos a mano sería un desastre.
+Para esto está el concepto de un package manager
o
+administrador de paquetes
. En vez e manejar los programas como
+archivos independientes, los agrupamos en paquetes
que contienen
+los archivos relacionados al programa, y el el administrados de paquetes
+el que se encarga de manejar todos estos archivos.
➜ pacman -Ql lidm
+lidm-git /etc/
+lidm-git /etc/lidm.ini
+lidm-git /usr/
+lidm-git /usr/bin/
+lidm-git /usr/bin/lidm
+lidm-git /usr/share/
+lidm-git /usr/share/man/
+lidm-git /usr/share/man/man1/
+lidm-git /usr/share/man/man1/lidm.1.gz
+lidm-git /usr/share/man/man5/
+lidm-git /usr/share/man/man5/lidm-config.5.gzSuelen hacer más tareas, como mostrar información de cada paquete y +satisfacer sus dependencias (esto con otros paquetes del que determinado +paquete depende, por ejemplo por ser una librería).
+ ➜ ldd /usr/bin/lidm
+ linux-vdso.so.1 (0x00007fd93d489000)
+ libpam.so.0 => /usr/lib/libpam.so.0 (0x00007fd93d428000)
+ libc.so.6 => /usr/lib/libc.so.6 (0x00007fd93d23a000)
+ libaudit.so.1 => /usr/lib/libaudit.so.1 (0x00007fd93d207000)
+ /lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007fd93d48b000)
+ libcap-ng.so.0 => /usr/lib/libcap-ng.so.0 (0x00007fd93d1ff000)
+
+ ➜ pacman -F /usr/lib/libpam.so.0
+usr/lib/libpam.so.0 is owned by system/pam 1.7.1-1
+
+ ➜ paru -Qi lidm | grep Depends
+Depends On : pam lidm-serviceEn este ejemplo se puede ver que el ejecutable lidm
+depende de libpam, archivo que es parte del paquete
+pam. Y esta dependencia esta especificada adecuadamente en
+la información del paquete.
Este es uno de los componentes en el que las distribuciones normales +no dan elección, el entorno de paquetes suele estar orientado alrededor +del administrador de paquetes elegido y sería imposible dar a +elegir.
+Los repositorios son los sitios
donde se agrupan los paquetes.
+En arch hay dos principales, core para los componentes
+super básicos (el kernel, init system, administrador de paquetes), y
+extra para paquetes que no son principales en un sistema
+operativo (naevgador, interfaces, etc).
Hay repositorios extra, como puede ser multilib para
+paquetes de 32 bits, y nada te impide hacer tus propios repositorios
+personales con tu propia selección de paquetes.
Además es común el tener repositorios donde las nuevas versiones
+llegan un poco antes, de testing (core-testing,
+extra-testing, multilib-testing,
+gnome-unstable, kde-unstable).
Los espejos o mirrors es simplemente una copia de los +repositorios en cierto servidor. Por ejemplo puede haber un servidor +específico de España que sirve los repositorios de arch en España para +no sobrecargar todos el mismo servidor y que tengamos menor tiempo de +respuesta.
+El AUR (Arch User Repository) es un repositorio con scripts +creados por usuarios de arch con como instalar un paquete.
+Si un paquete no está oficialmente en los repositorios, es muy +posible que alguien lo haya añadido ahí ya, y si no... ¡Tú puedes ser la +primera persona en hacerlo!
+Warning
+Es importante recordar que los paquetes del AUR están hechos por +usuarios y pueden ser maliciosos, lo más importante siempre es leer el +script para asegurarnos que no tiene nada sospechoso.
++ ++
Os habreis dado cuenta de que habrá muchos componentes pero todavía +no hemos salido de la TTY, ni una sola interfaz gráfica. Y ahora ha +llegado el momento de instalar una.
+Aquí tenemos dos opciones, la primera y más aburrida, instalar un +entorno de escritorio (DE, Desktop Environment). GNOME o KDE, gnomo o +caballero. Se llaman entornos porque suelen venir con todo incluido, +traen audio, la barra, aplicaciones del sistema, aplicación de ajustes, +etc.
+O la mas interesante, instalar un administrador de ventanas (WM, +window manager) que solo se ocupe de manejar las +ventanas y como interactuamos con ellas. No hay escritorio, no hay fondo +de pantalla, no hay barra, no hay un launcher de aplicaciones, nada, es +nuestro trabajo en hacer nuestra selección de componentes y configurarlo +todo lo que queramos.
+Hoy en día hay dos protocolos básicos, xorg y wayland.
+Xorg es el protocolo que lleva décadas existiendo y queda poca gente
+queriendo tocar código tan anticuado. Pero funciona perfectamente y hay
+muchos administradores de ventanas escritos a lo largo del tiempo para
+él como i3 (del que entraremos en detalle después) o
+xmonad.
Wayland es un protocolo nuevo que está cogiendo mucha popularidad
+recientemente y busca rediseñar muchos de los principios de xorg a
+estándares mas modernos. Pese a lo nuevo que es ya hay multitud de
+compositores (así se llaman los WM en wayland) para él, como
+hyprland, niri o sway (que busca
+ser un reemplazo literal de i3 para wayland).
Un display manager es simplemente el programa que hay antes de la +interfaz gráfica completa en la que se nos permite iniciar sesión con +nuestro usuario. Muchas también permiten seleccionar la interfaz gráfica +a arrancar si tenemos varias.
+Los más comunes son GDM, SSDM (de GNOME y KDE relativamente, +funcionan con mas cosas a parte de sus DEs), pero hay muchos +mas.
_Daemons_de red (NetworkManager, iwd) - Administrador de Paquetes (pacman) - Repositorios (core, extra, kde-testing, custom) - - AUR (como un pseudo-repositorio alternativo) + - Espejos + - AUR - GUI - - DE - - GNOME / KDE - - WM(xorg): - - i3 - - xmonad - - Compositor(wayland): - - sway - - Hyprland - - Niri - - Display Manager - - GDM / SSDM - - lidm - - Notif daemon, sudo, etc -- Mencion de la wiki + - DE (GNOME / KDE) + - WM: + - Xorg (i3, xmonad) + - Wayland (hyprand, niri, sway) + - Display Manager (GDM / SSDM, etc) + - Más +- Arch Wiki - Forks de Arch (artix, black arch, alarm, cachyos, nyarch) -- Instalación (que es el iso) - -> [!NOTE] -> -> `kernel -> coreutils -> init -> network` -> -> Hacerlo como una progresión. -> -> - El kernel es lo básico, maneja los procesos y permite que estos reserven memoria, tengan un sistema de archivos, se comuniquen con periféricos, etc. -> - Coreutils da una serie de programas básicos para interactuar con lo que ofrece el kernel (ls, cat, touch, mkdir, etc). **no son parte del kernel** -> - Linux no esta preparado para arrancar directamente cuando el ordenador arranca (a menos que sea UEFI y esté configurado). Entonces hay un programa llamado
boot loaderque se encarga de arrancar un SO al encender el ordenador. También pueden ser
boot managers, que además ofrecen menús y opciones para configurar que SO arrancar si hay varios o incluso con que opciones. -> - Cuando linux arranca, aunque tenga programas instalados, alguien tiene que decidir que ejecutar y que no, no tiene sentido que se ejecute
mkdiral arrancar. A esto se le llama el
init, que es el programa que se ejecuta al arrancar y se encarga de arrancar los
serviciosen su orden correcto, como configurar el teclado, arrancar el
daemonde red, etc, y mostrarnos nuestra interfaz de usuario cuando todo esté listo. -> -> Dejar
daemonun poco en el aire y desarrollarlo en NetworkManager como ejemplo. - -> [!NOTE] -> -> En Network Manager -> -> Hay muchas alternativas, NetworkManger es el
todo en uno, pero hay paquetes para cosas mas pequeñas,
iwdcon
wpa_supplicantpara configurar wifi solo, etc. Incluso combinaciones, hacer que
NetworkManageruse solo
iwdpara configurar el wifi, o que use
dnsmasqpara
cachede DNS, etc. +- Instalación (que es el iso & pasos conceptuales) --- @@ -120,10 +95,14 @@ Un ordenador no está diseñado para arrancar directamente un kernel (hasta reci Además, muchos de estos
bootloadersofrecen menus antes de arrancar el kernel para seleccionar el sistema en casos de multiboot o configurar las opciones con las que arranca ell kernel. En este caso se les considera un
boot manager. +El caso más popular y que lo incluye todo es `grub`, otras opciones populares son `systemd-boot` y `limine`. + ## Init System Una vez el kernel arranca, este tiene programas instalados y esta listo para ofrecer sus servicios, pero no puede ejecutar cualquier cosa como `mkdir`. Entones se usa un init system, que consiste simplemente en el primer programa que linux ejecuta al arrancar el ordenador (por defecto se busca en `/sbin/init`). +El más popular (con diferencia) hoy en día es systemd, también es el único que arch soporta de forma oficial. Aunque existen otros como OpenRC, Runit, Dinit, S6, etc; que se pueden configurar en arch (aunque para eso hay opciones mejores como usar Artix). + El trabajo de un init system completo es el de iniciar todas las partes del sistema adecuadas, llamadas
servicios. Estos servicios pueden ser programas simples que configuren el teclado, o programas que se mantienen activos de fondo, como el
daemonde red. El orden también es muy importante, la interfaz gráfica también se considera un servicio que solo se puede ejecutar cuando el resto de servicios previos han terminado de ejecutarse adecuadamente. No tiene mostrar la interfaz de inicio de sesión si el teclado no está preparado. @@ -133,3 +112,129 @@ El orden también es muy importante, la interfaz gráfica también se considera Un daemon es simplemente un programa que se mantiene ejecutando de fondo, normalmente manejados por el init system como un servicio. El ejemplo más claro son los _daemons_ de red, estos procesos se mantienen activos de fondo buscando las redes disponibles y decidiendo constantemente si deben conectarse, desconectarse, o que hacer. + +Los _daemons_ se suelen caracterizar con una
dal final del nombre (`playerctl` -> `playerctld`, `udev` -> `udevd`, `ssh` -> `sshd`, etc). + +El más popular es `NetworkManager`, que es un
todo en unode un _daemon_ de red. Pero hay muchas otras opciones mas modulares, como `iwd` específico para configuración inalámbrica, `systemd-networkd`, o `wpa_supplicant` para certificados de wifi. Incluso configuraciones mixtas, `NetworkManager` se puede configurar para solo usar `iwd`, o que use `dnsmasq` para cache del DNS, etc. + +## Administrador de Paquetes + +Hasta ahora hemos visto el kernel, los creutils, un bootloader, el init system y todos los servicios y _daemons_ que puede haber. Esto son muchísimos archivos y manejarlos a mano sería un desastre. + +Para esto está el concepto de un
package managero
administrador de paquetes. En vez e manejar los programas como archivos independientes, los agrupamos en
paquetesque contienen los archivos relacionados al programa, y el el administrados de paquetes el que se encarga de manejar todos estos archivos. + +```txt + ➜ pacman -Ql lidm +lidm-git /etc/ +lidm-git /etc/lidm.ini +lidm-git /usr/ +lidm-git /usr/bin/ +lidm-git /usr/bin/lidm +lidm-git /usr/share/ +lidm-git /usr/share/man/ +lidm-git /usr/share/man/man1/ +lidm-git /usr/share/man/man1/lidm.1.gz +lidm-git /usr/share/man/man5/ +lidm-git /usr/share/man/man5/lidm-config.5.gz +``` + +Suelen hacer más tareas, como mostrar información de cada paquete y satisfacer sus dependencias (esto con otros paquetes del que determinado paquete depende, por ejemplo por ser una librería). + +```txt + ➜ ldd /usr/bin/lidm + linux-vdso.so.1 (0x00007fd93d489000) + libpam.so.0 => /usr/lib/libpam.so.0 (0x00007fd93d428000) + libc.so.6 => /usr/lib/libc.so.6 (0x00007fd93d23a000) + libaudit.so.1 => /usr/lib/libaudit.so.1 (0x00007fd93d207000) + /lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007fd93d48b000) + libcap-ng.so.0 => /usr/lib/libcap-ng.so.0 (0x00007fd93d1ff000) + + ➜ pacman -F /usr/lib/libpam.so.0 +usr/lib/libpam.so.0 is owned by system/pam 1.7.1-1 + + ➜ paru -Qi lidm | grep Depends +Depends On : pam lidm-service +``` + +En este ejemplo se puede ver que el ejecutable `lidm` depende de `libpam`, archivo que es parte del paquete `pam`. Y esta dependencia esta especificada adecuadamente en la información del paquete. + +Este es uno de los componentes en el que las distribuciones normales no dan elección, el entorno de paquetes suele estar orientado alrededor del administrador de paquetes elegido y sería imposible dar a elegir. + +## Repositorios + +Los repositorios son los
sitiosdonde se agrupan los paquetes. En arch hay dos principales, `core` para los componentes super básicos (el kernel, init system, administrador de paquetes), y `extra` para paquetes que no son principales en un sistema operativo (naevgador, interfaces, etc). + +Hay repositorios extra, como puede ser `multilib` para paquetes de 32 bits, y nada te impide hacer tus propios repositorios personales con tu propia selección de paquetes. + +Además es común el tener repositorios donde las nuevas versiones llegan un poco antes, de _testing_ (`core-testing`, `extra-testing`, `multilib-testing`, `gnome-unstable`, `kde-unstable`). + +### Espejos + +Los espejos o _mirrors_ es simplemente una copia de los repositorios en cierto servidor. Por ejemplo puede haber un servidor específico de España que sirve los repositorios de arch en España para no sobrecargar todos el mismo servidor y que tengamos menor tiempo de respuesta. + +### AUR + +El AUR (Arch User Repository) es un repositorio con _scripts_ creados por usuarios de arch con como instalar un paquete. + +Si un paquete no está oficialmente en los repositorios, es muy posible que alguien lo haya añadido ahí ya, y si no... ¡Tú puedes ser la primera persona en hacerlo! + + + +> [!WARNING] +> +> Es importante recordar que los paquetes del AUR están hechos por usuarios y pueden ser maliciosos, lo más importante siempre es leer el _script_ para asegurarnos que no tiene nada sospechoso. + +> —