Ahora si, entremos :D Llevo varios años dándole vueltas a ese tipo de distribuciones, y planteándome usarlas como plataforma principal, pero por razones puramente pragmáticas, siendo muy ignorante en cuanto a seguridad.
El tema toca el empaquetado y distribución de software, y también los contenedores, porque aunque hablamos de distribuciones, nix, flatpak, etc. Tengo varias cuantas cosas acumuladas en la cabeza en este sentido. De hecho, estoy en proceso de escribir un artículo|paper más bien divulgativo al respecto (el uso de contenedores en escritorio y para desarrollo, muy al margen de todo el ruido de la nube). Espero me permitas responder con un artículo de blog, más que un correo. Puede que quieras leer las secciones en orden inverso (y en cualquier caso en diagonal), ya que al final hablo de hipervisores, anstes de distribuciones inmutables, antes de nix, y las secciones anteriores (las primeras) son para explicar cómo llego yo a esas conclusiones (más bien cómo mis premisas me condicionan). *TL;DR:* - nix guay; nixOS no sé yo. - CoreOS o SilverBlue worth a try como alternativa a Ubuntu Server o Fedora Server. Para Workstation, casi que lo mismo da. - Totalmente de acuerdo en que empezar a entender cómo y a aislar las aplicaciones, los datos, el sistema, la capa de usuario, etc. siempre bien, por razones de seguridad pero también pragmáticas (la estabilidad de nuestra infraestructura "personal" a lo largo de los años) cada cual con las herramientas que menos disrupción le supongan. - QubesOS MUY interesante. *# Contexto* Utilizo 4-6 equipos diferentes en mi día a día, con Windows 10, Fedora, Red Hat, Debian o Ubuntu. La primera vez, es divertido y didático cacharrear con las particularidades de cada sistema, con la configuración de las herramientas y el escritorio, etc. Con el tiempo, la diversión pasa a ser trabajo, y a generar cierta ansiedad el no poder trabajar en otras cosas más excitantes sino tener que pelear con X característica/configuración otra vez más. Por eso, he acabo reduciendo el host a: - Vim, git y openSSH y Docker|Podman. - Si tiene escritorio: - Firefox (con "sincronización" de pestañas; a ver cuándo se pueden sincronizar contenedores tambíén). - VSCode|VSCodium y LibreOffice. - Gimp, Inkscape, Meld (en GNU/Linux) o WinMerge (en Windos). - Steam y Godot (que es estático). Todo lo demás lo uso a través de contenedores: GCC, LLVM, Go, NodeJS, LaTeX, Sphinx, asciidoctor, pandoc, Matlab, Octave, Vivado, ModelSim/QuestaSim, EDA open source (simulación, síntesis y/o implementación), Jellyfin, qbittorrent,... También en los sistemas ARM que soportan docker|podman. Curiosamente, en Raspbian de 32 bits se pueden|podían ejecutar contenedores de 64 bits porque si CPU lo soporta (Pi 3), aunque el sistema (host) sea de 32 bits¿?. Así, no me importa en qué ordenador estoy, y tampoco me importa si el escritorio que estoy usando está en una CPU "pobre". Los contenedores son los mismos independientemente del sistema, y lo mismo me da ejecutarlos de forma local o, si tengo conexión, remota (por SSH o utilizando integración continua). Si tengo que usar el ordenador de otra persona, sé que con borrar la carpeta local y los contenedores que haya usado no estoy dejando basura. Si el sistema en el que estoy casca por una actualización puñetera, a malas puedo arrancar una LiveCD de Ubuntu o Fedora y salvar el día para pelear con el host en otra ocasión. En clases de máster uso Gitpod, a falta de ganas para gestionar la instalación de software en los equipos de aula de la uni que són exclusivamente Windows. Quienes asisten con su portátil pueden instalar las herramientas de forma nativa, sea en GNU/Linux o en Windows, si quieren. A lo que voy: lo que me interesa es la inmutabilidad de la capa de aplicación, que es con la que más interactúo como usuario doméstico, profesor e investigador que desarrolla hardware/software. El sombrero de administrador de sistemas prefiero ponermelo lo justo y necesario porque es otro pozo sin fondo y tengo tendencia a asomarme con demasiado ímpetu. Del sistema sólo me interesan el kernel, y los drivers para el hardware que esté conectado; y por salud sólo quiero que me interese que funcionen. *# Contenedores, snap, flatpak, appimage, Conda...* La razón principal por la que decidí migrar todas las aplicaciones a contenedores es que en 2016-2017 Windows Subsystem for Linux (WSL) no existía de forma usable pero Docker for Windows sí funcionaba sobre HyperV. Combiné (y combino) MSYS2 con Docker en Windows para utilizar los mismos scripts y Makefiles que desarrollo en GNU/Linux. En comparación con snap/flatpak/appimage, los contenedores GNU/Linux funcionaban y funcionan "exactamente" igual en cualquier sistema GNU/Linux, Windows o macOS. La experiencia que tengo con snap/flatpak/appimage es que funcionan en GNU/Linux, pero no siempre, y no lo hacen en Windows. WSL2 no es Windows, sino una VM/contenedor, por lo que lo considero equivalente a usar Docker for Windws. Y aislan, pero no del todo. Porque si dependen de, por ejemplo, Python, pueden usar el python del sistema, que puede no ser el mismo dependiendo del host. Tampoco parece conceptualmente razonable meter una instalación de python en cada snap/flatpak/appimage, porque no comparten contenido entre si. Si combinamos snap/flatpak/appimage con venvs de Python, nos acercamos a reinventar Conda (ver más abajo). Son soluciones pensadas para aislar excepcionalmente algunas librerias del sistema, pero no todo el sistema de ficheros. Por contra, los contenedores son soluciones paara aislar todo el sistema de ficheros, con honrosas excepciones. Por eso, no he tenido interés particular por entender cómo funcionan y por qué no lo hacen a veces. Si en cualquier caso voy a tener que meter las herramientas en un contenedor para usarlas en Windows o macOS, me sobra la capa de abstracción que me ofrecen. No considero que nix esté exactamente en la misma categoría, lo cual es mi motivación para responder a este hilo :D. Ver más abajo. Conda (Anaconda, Miniconda, Mamba...)... menudo pastel, eh! La idea no es mala: tener un conjunto de librerías para cada una de las plataformas y compilar las herramientas contra esas librerías. De forma similar a snap/flatpak/appimage, el sistema de ficheros no está del todo aislado. Básicamente se manipulan las PATH y LD_LIBRARY_PATH, construyéndose sobre los venv de Python, pero por lo demás es una aplicación nativa normal y corriente. Conda tiene mucha tracción en el mundo académico, y en general en áreas donde la gente trabaja con software pero no son usuarios avanzados de sistemas. Es decir, no conocen multiples gestores de paquetes, y si lo hacen no quieren dedicar tiempo a utilizarlos. Conda ofrece una solución que a ojos del usuario funciona igual, por lo que no tienes que complicarte la vida si el portatil de tu compañero de laboratorio es un macbook o usa ArchLinux mientras que en el labo todo es Windows. Lo hace a costa de transferir la complejidad a los empaquetadores. De facto, Conda es una distribución que es a su vez tres distribuciones en una. Es decir, para empaquetar una herramienta nueva en conda, hay que triplicar el esfuerzo en comparación con lo que supondría empaquetarla sólo para deb, rpm o msys2. Por lo tanto, si el objetivo es empaquetarla de forma "nativa" para dos o tres plataformas, puede merecer la pena invertir el esfuerzo en aprender Conda en vez afrontar las particularidades de cada entorno y comunidad. Pero, por otra parte, podemos compilar las herramientas una sola vez para por ejemplo Debian y meterlas en un contenedor para poder usarlas en "cualquier" plataforma. La comunidad de empaquetadores de Debian (o la de Fedora, o ArchLinux) es mucho más madura y numerosa que la de Conda. Anaconda se lanzó (2012) apenas un año antes de que Docker surgiera (2013). Tuvieron muy mal timing. Si no hubieran surgido los contenedores, posiblemente el ecosistema de Conda habría recibido mucha más financiación y cariño. Pero todos los grandes se pusieron muy en serio con los contenedores, y en apenas 3-4 años se comieron los mercados que mueven dinero, y de ahí en cascada. El comunicado de Docker hace un par de años (después de vender la división cloud) de "vamos a volver a centrarnos en los desarrolladores". No exactamente ellos, pero Microsoft, RedHat, etc. ya han fijado rumbo y estos no paran. Si los recursos que se destinan al desarrollo de snap, flatpak, appimage y Conda se unificaran, podría sugir algo que compitiera con los contenedores por ser más fácil de usar (al no tener que entender que el sistema de ficheros esté aislado por defecto). Pero no suele ser esa la dinámica del bazar. Hace un par de años, tuve el placer de conversar con Ray Donnelly ( https://github.com/mingwandroid), un desarrollador de Conda que también era co-fundador y empaquetador en MSYS2. MSYS2 es un sistema para disponer de una shell bash y el gestor de paquetes pacman en sistemas Windows, pero generando binarios nativos de windows. Naturalmente, se nutre mucho de las recipes de ArchLinux, tanto que se comparan las versiones para no quedarse atrás: https://packages.msys2.org/outofdate. Desde 2013 hasta 2020 no creció mucho, pero a partir de 2020 está creciendo bastante. Ya tiene varios miles de paquetes disponibles. La idea de Ray era hacer que todos esos paquetes estuvieran disponibles a través de Conda: https://anaconda.org/msys2/repo. Por desgracia, el trabajo de Ray se vió ralentizado por el cáncer, y falleció en 2021. Es una historia que me resulta muy dolorosa por empatía, pero también muy didáctica. Creo que Conda podría crecer si se pudieran reutilizar las recetas de MSYS2 para Windows y las de ArchLinux para Linux; pero objetivamente puede que no sea razonable el esfuero necesario ya que quienes empaquetan en Conda lo hacen precisamente para evitar tener que gestionar el empaquetado en otras plataformas más asentadas. *# Empaquetado y distribución de herramientas open source para EDA* Desde principios de 2022, por las mañanas soy investigador en la UPV/EHU y por las tardes trabajo de forma remota para Antmicro, una empresa polaca con Google como uno de los clientes principales. Desde 2019-2020 estoy implicado en varios proyectos donde participan gente de Antmicro y Google, impulsados por el foco que ha puesto Google (bueno, cierta gente dentro) para eventualmente dejar de depender de software no libre (ejem no gratis) para fabricar sus chips. Los conocimientos y opiniones (naturalmente my own) que estoy exponiendo proceden principalmente de mi implicación en https://github.com/hdl/, de la que soy co-creador, "owner" (admin) y mantenedor/desarrollador de varios repositorios. Los reseñables en este hilo son: - https://github.com/hdl/packages - https://github.com/hdl/conda-eda - https://github.com/hdl/bazel_rules_hdl - https://github.com/hdl/containers El "problema" que estamos tratando de resolver es la distribución de herramientas FLOSS para EDA (tanto simulación, como síntesis e implementación sea para FPGAs o para ASICs). Para algunos usuarios, las FPGA son el objetivo final, sobre todo porque tradicionalmente la fabricación de chips era prohibitivamente cara. Sin embargo, dentro de la estrategia de Google de "democratizarlo", llevamos varios años con 2-3 tiradas anuales en las que se fabrican chips gratis siempre que el diseño sea open source: https://opensource.googleblog.com/2022/10/announcing-globalfoundries-open-mpw-shuttle-program.html. Por lo tanto, el interés de Google ya ha pivotado hacia los ASICs como objetivo. No somos tontos; resulta evidente que a Google le sale más rentable financiar gente suelta por el mundo siempre que lo que hagan sea Apache (no GPL), y les interesa fabricar diseños arbitrarios en tecnologías "baratas" (para sus escalas) para poner a prueba las herramientas. Como resultado, hoy en día cualquiera de nosotros puede diseñar por ejemplo un RISC-V utilizando sólo herramientas libres, subirlo a un repositorio y en 6-12 meses tener de vuelta 100-500 chips físicos gratis. En los siguientes enlaces podéis ver los diseños: - https://efabless.com/open_shuttle_program - https://platform.efabless.com/projects/shuttle/11 Si tenéis un mes de tardes libres (ja), o algún estudiante inquieto/a que quiera hacer un TFG diferente, es gratis y el viaje merece la pena. Hay diseños complejos, pero también hay pruebas tan sencillas como generar un patrón por una salida VGA (que son dos contadores anidados y un puñado de comparadores). No merece la pena complicarse, lo bonito es el camino. Volviendo al empaquetado y distribución, "las herramientas open source para EDA" son 40, 60, 100, 150? Cada día crece la lista. No son todas nuevas. La mayoría han estado debajo de una piedra 10, 15, 20 años, desarrolladas en silencio y soledad por un tío de Lyon, Kentucky o Dresden. Las recetas eran inexistentes. Cada uno usaba un Makefile o CMake, o lo que más le gustaba y que funcionara en su ordenador. Llega Google con su inyección en 2016-2019, y veinte años de desarrollo de software nos explotan en la cara. De repente la gente empieza a utilizar todas esas herramientas, a reportar bugs, pedir características,... Ver por ejemplo https://github.com/ghdl/ghdl/graphs/contributors. Ese es sólo uno de las decenas de proyectos, y ese en particular no ha sido financiado y no está en el radar por ser GPL. Aún así, el efecto de "cualquiera puede fabricar un chip con herramientas libres" ha tenido un eco muy notable. Naturalmente, hay otros muchos factores geopolíticos y económicos, como las CHIPS Act en las que andan EU y EEUU, pero espero se entienda la simplificación. Pero, en esencia, llevábamos desde finales de los 90 esperando a que la revolución de Linux llegara a nuestro campo. Así, la comunidad se enfrentó (y se está enfrentando todavía) a la necesidad de usar docenas de herramientas que tienen que funcionar de forma coordinada pero se desarrollan independientemente de forma muy old school, y cada una de ellas recibe varios commits diarios. Eso es muchísima basura. Es basura para los desarrolladores, pero también para los usuarios. Si reportan un bug y en 24-48 horas está solucionado, quieren poder usarlo ya. Aunque les evitemos el esfuerzo de compilar usando CI, tienen que estar instalando y desinstalando versiones. Conste que es algo invaluable, porque estamos acostumbrados a una quasi-monopolica industria que cobra miles en licencias e ignora bugs durante años. Las distribuciones tradicionales no encajan. Idealmente, todas esas herramientas estarían empaquetadas de forma canónica en Debian y en Fedora. Poco a poco, eso se está consiguiendo. Pero tarda años. Aun en el supuesto en el que los empaquetadores tienen comunicación con los desarrolladores y cualquiera que quiera hacer un deb o rpm lo haga upstream (que es una quimera), los procesos de actualización son semestrales o anuales porque la estabilidad y los tests son importantes en esas distribuciones, y dichos tests suelen incluir múltiples arquitecturas (amd64, arm, aarch64, s390x, ppc64, riscv...). Arch tiene un ciclo mucho más corto (immediato), pero se aplica a todo el sistema, no sólo a las herramientas de la última capa de usuario. Más allá, suficiente esfuerzo nos sigue constando que los compañeros usen Ubuntu (no Linux). No creo que Arch pueda ayudar en esos casos. El primero de los repositorios que he enlazado ( https://github.com/hdl/packages) es un listado de las estrategias por las que ha optado la comunidad. Desde paquetes para distribuciones tradicionales (pkgbuild, ebuild, deb, rpm) hasta WebAssembly, desde compilaciones estáticas hasta bazel. Curiosamente, nadie ha decidido hacer "una distribución". https://fedoraproject.org/wiki/Electronic_Lab dejó de actualizarse hace una década. ¿Han cambiado los tiempos? Sí hay iniciativas como https://copr.fedorainfracloud.org/coprs/rezso/HDL/ o el Electronics Team de Debian (https://salsa.debian.org/electronics-team). De todas esas estrategias, la única cercana a estar "completa" (en cuanto a número de herramientas) es la de Conda. Principalmente porque, que yo sepa, es la única que ha recibido financiación durante varios años para que hubiera varias personas dedicándose a ello. El resto de iniciativas son voluntarias y generalmente con menos gente dedicada. La motivación para crear github.com/hdl en 2019 fue que esas personas al menos se comunicaran, ya que están enfrentándose a los mismos problemas cada cual en su entorno. Se unieron en la organización los contenedores que yo había estado manteniendo en otro sitio, los repositorios de conda que estaban en litex, se creó el repo de Bazel, etc. Fue entonces cuando valoré dejar de mantener/usar los contenedores en favor de Conda. Pero, por las razones expuestas, me pareció y me parece pan para hoy y hambre para mañana. Está muy bien que las corporaciones|empresas y los tiempos modernos tengan aspiraciones que exceden la realidad, pero hacer las cosas de forma medianamente sostenible require esfuero y tiempo. *# Contenedores, deb, y nix* La estrategia que decidí mantener es https://github.com/hdl/containers. Son una serie de contenedores que incluyen una o varias herramientas EDA para simular, sintetizar, programar|ejecutar, etc. Habrá unas cincuenta en total, de las que unas 30 tienen recetas individuales ( https://hdl.github.io/containers/ToolsAndImages.html). Cada herramienta se compila por separado y se guarda en un contenedor vacío (scratch), como si fuera un tarball o un zipfile. Las imágenes que contienen varias herramientas se "componen" copiando los "paquetes" pre-compilados y añadiendo las dependencias "runtime" definidas en las recetas. Empecé, como casi todos al comenzar con contenedores, instalando todas las herramientas en un solo Dockerfile y tratándolo como una VM. Si necesitaba varios contenedores con algunas herramientas iguales y otras diferentes, recompilaba las herramientas. No era óptimo, pero funcionaba. Con el precio que tienen los megabytes hoy en día, las velocidades de conexión y los multicores, era pragmático. Conforme fui conociendo mejor cómo funcionan los contenedores, empezó a escocerme un poco más. Sí, las horas de pensar de un ingeniero cuestan más que estar moviendo contenedores de un lado al otro. Pero que podamos gastar recursos no implica que esté bien desperdiciarlos. Lo primero que hice fue utilizar una sola imagen base con las dependencias comunes. Como las imágenes de contenedores funcionan por capas, si cada herramienta está en una imagen/contenedor diferente pero todas ellas están basadas en la misma, no hay overhead (ni en espacio en disco, ni en consumo de red). Para cada herramienta sólo nos descargamos lo que ocupen ella y sus dependencias. Decidí utilizar Debian como imagen base (Stretch, Buster, Bullseye). Valoré Fedora, pero `dnf update` deja mucha más basura que `apt update`, a pesar de borrar la cache. Valoré alpine (que estuvo muy de moda), pero musl y ash son (eran) demasiado esfuerzo para el objetivo. Valoré Arch, pero quien decidiera diseñar la CLI de `pacman` no tuvo un buen día. En realidad, nunca quise desarrollar/mantener esos contenedores per se. Lo hice primero para mejorar la CI de un proyecto concreto, y después para satisfacer mis propias necesidades de desarrollo y docencia. Mi intención era eventualmente escribir recetas deb "correctas" y upstreamearlas de forma que la única diferencia entre Debian y mis versiones fuera que ellos usen una version tagged y yo uso master|main. Con esa idea, en conjunto con la estructura modular y el uso de una base común, acabé aterrizando en una solución que tiene el siguiente aspecto: - https://github.com/hdl/containers/blob/main/debian-bullseye/boolector/Dockerfile - https://github.com/hdl/containers/blob/main/debian-bullseye/boolector/HDLC Un Dockerfile genérico con tres stages (compilar, empaquetar, runtime), y una receta (en realidad más inspirada en PKGBUILD que en la recetas de Debian) que contiene las dependencias de compilación, las instrucciones y opcionalmente las dependencias de ejecución. Los diagramas de https://hdl.github.io/containers/dev/Graphs.html ilustran qué imágenes y paquetes se generan con qué dockerfiles/recetas y cuáles son las dependencias de las imágenes que se componen de varias herramientas. Un proyecto relacionado que mantengo desde 2019 es https://github.com/dbhi/qus, que utiliza un contenedor de docker para configurar QEMU static en memoria de forma que puedan ejecutarse otros contenedores de arquitecturas diferentes. Anecdóticamente, es de "mis" repositorios el que más estrellas tiene, y me sorprende para qué lo usa la gente (ejecutar Steam en RPi, o todo tipo de software en M1). Yo lo uso en hdl/containers para compilar las herramientas y hacer contenedores para aarch64 (y s390x y ppc64 si no me cuesta esfuerzo) en integración continua (ya que los runners gratuitos de GitHub son x86; GitLab creo que tiene alguno para ARM) y también de forma local para compilar para aarch64 sin tener que cambiar los scripts para hacer compilación cruzada. Otra característica que añadí el año pasado, es hacer explícita la versión de cada herramienta en el nombre del contenedor (la imagen, se entiende): https://github.com/hdl/containers/blob/main/debian-bullseye/gtkwave/Dockerfile#L38-L39 . Como en la industria/comunidad hay cierto a apego a CentOS 6 y 7 (cosa que no acabo de entender), la estructura del repositorio está pensada para varias "colecciones" de imágenes, siendo una colección todas aquellas que comparten la misma base (debia, centos, ...). Todo lo hago con la integración continua gratuita de GitHub (Actions). Las imagenes las subo a docker.io, ghcr.io y gcr.io. Los dos primeros también de forma gratuita, y el tercero con acceso explícito (aunque desconozco si hay servicio gratuito). Las imágenes de docker permiten hacer variantes de forma que las capas acaban formando un arbol. Pero no es posible unir (mergear) las ramas para componer una nueva images. Por eso, para gestionar la compilación y publicación de varias imágenes, hay un paquete de Python: https://github.com/hdl/containers/tree/main/utils. Hay proyectos de terceros que proveen soluciones para utilizar herramientas nativas o contenedores de forma "transparente" para el usuario: https://github.com/olofk/edalize/blob/main/scripts/el_docker o https://github.com/edaa-org/pyEDAA.CLITool/blob/main/pyEDAA/CLITool/Docker.py . Los que conocéis o habéis leído sobre nix, supongo que estaréis levantando la ceja. ¿Estoy/estamos reinventando nix? Tengo la sensación de que parcialmente sí. Desde luego, https://github.com/hdl/containers/blob/main/debian-bullseye/gtkwave/HDLC se parece mucho más a https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/science/electronics/gtkwave/default.nix que a https://salsa.debian.org/electronics-team/gtkwave/-/tree/master/debian . *# nix para no morir en el intento?* Mantener hdl/containers ya me lleva más tiempo no pagado del que quiero dedicar. No sé si es que me estoy haciendo mayor, pero como que empieza a resultarme igual o más gratificante pasear o estar con la familia. Es un proyecto muy chulo y se podrían hacer muchas mejoras muy divertidas, pero ya tiene 5 años y hay que decidir qué batallas no se van a poder librar. Veo muchas similitudes entre lo que nix puede hacer y lo que yo necesito para mantener un entorno de trabajo basado en contenedores sin tener que desarrollar yo mismo la infraestructura de compilación. Parece que utilizan contenedores para aislamiento al compilar los paquetes y también como base para después instalarlos con el gestor. Pero me cuesta mucho entender qué no es nix. Parece ser un sistema (distribución), un gestor de paquetes (que puede usarse en cualquier otro sistema), un reemplazo para las Dockerfile (que no sé si es el mismo lenguaje que el de las recetas, o si ese lenguaje tiene algún otro uso), una solución para usar contenedores ligeros en la nube... Me da la sensación de que intenta abarcar demasiado en un mismo paraguas. O son genuinamente brillantes, o están cogiendo uno o varios atajos de los que o no son conscientes o no los están explicando de forma que yo pueda entenderlo. Por ejemplo, no quiero instalar nix en un contenedor para después instalar paquetes con ello. Quiero que nix genere un contenedor con esos paquetes y que nix no esté instalado en el contenedor. https://nix.dev/tutorials/building-and-running-docker-images tiene muy buena pinta, pero no parece posible especificar la imagen base del contenedor. Viendo https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-support/docker/examples.nix, sí parece posible especificar cualquier imagen base, pero es un ejemplo de 850 líneas... Si intento leer https://nixos.org/guides/how-nix-works.html, la segunda frase me tumba: "This means that it treats packages like values in purely functional programming languages such as Haskell — they are built by functions that don’t have side-effects, and they never change after they have been built". Toda la explicación posterior me suena muy bien, si estuviera buscando un reemplazo para apt o dnf que pueda gestionar multiples versiones de las herramientas/librerías, de forma similar a Conda o los venv. Pero no es eso lo que estoy buscando. Me falta la parte de que una herramienta sea un contenedor en vez de una carpeta local. En cuanto a NixOS, me resulta temerario. Jugar con contenedores y aplicaciones en la carpeta de usuario guay, pero toquetear el sistema base :S. El sistema puede y debe ser robusto/estable, porque de ello dependen poder jugar con el resto. Debian hace un muy buen trabajo de filtro paso bajo para tratar de garantiarlo. Cuestiones como https://lists.debian.org/debian-devel/2008/12/msg01027.html son las que me gusta saber que plantea quien desarrolla/mantiene el sistema base. *# Sistemas inmutables* La primera vez que leí sobre el concepto fue por CoreOS. Lo que vagamente recuerdo es que proponían que todo el sistema operativo estuviera basado en contenedores. El kernel sólo, y todo, hasta systemd, en contenedores. Era 2014-2015 y me pareció una alucinación, una sobreexcitación con el juguete nuevo. Creo que llegué a probarlo porque si no me equivoco el concepto usaba alpine como base. Posteriormente, he intentado buscar sobre el concepto varias veces, pero no lo he encontrado. En 2018 Red Hat compró CoreOS ( https://www.redhat.com/es/technologies/cloud-computing/openshift/what-was-coreos), por lo que todo aquello ha acabado en las herramientas y engines de contenedores de segunda generación. El nombre CoreOS en sí acabó asociado a una distribución liviana pensada para ejecutarse en VM en la nube, sobre la que correr contenedores. Pero creo que la idea de que el sistema en si fuera basado en contenedores no cuajó. En 2020 RedHat abandonó el proyecto, pero sigue existiendo https://fedoraproject.org/es/coreos/. Fedora SilverBlue parece ser lo mismo que CoreOS, pero aplicado al escritorio: https://silverblue.fedoraproject.org/about. Es decir, la "inmutabilidad" se basa en que el sistema base es tan pequeño que te resulta más fácil borrarlo todo y bajarte una versión nueva completa, que intentar actualizar el que tienes. Tratar el sistema base del equipo de escritorio como si fuera el sistema base de una VM donde lo único que se van a ejecutar son contenedores. Puede que no consiguieran aislar systemd del sistema base (o que no tuviera sentido al fin y al cabo) por lo que la solución es que la única diferencia entre el sistema base y los contenedores sea que el primero tenga systemd "y poco más". Pero me pierdo con dónde queda la detección de hardware y los drivers. Entiendo toda la configuración de escritorio, configuraciones de usuario, aplicaciones, sistema de ventanas, etc. Entiendo que el kernel es el kernel. Pero, entre arrancar un kernel de una versión nueva del sistema y acceder/utilizar todas esas configuraciones, ¿la detección y configuración de hardware? ¿Son sólo ficheros de configuración también? ¿No hay que descargar contenido al sistema base que no esté aislado (como sí lo están las aplicaciones) rompiendo la inmutabilidad? He de decir que tengo un poco de cacao en este sentido porque sé que NVIDIA permite usar una GPU en un contenedor con unos drivers que estén en otro contenedor, pero tampoco acabo de entender cómo funciona. Igual SilverBlue es "casi" inmutable ya ya esta. A diferencia de NixOS, sí confio en la propuesta de Fedora/CoreOS. Herramientas como podman han se han nutrido de ese germen, y poder ejecutar contenedores sin un servicio con permisos de root supuso un punto de inflexión en la viabilidad de los contenedores donde la seguridad es relevante (aunque creo que sigue sin ser un sandbox). Fedora tiene un ancho de banda mayor que Debian, y estas herramientas se han probado ahí. Pero, a efectos prácticos, utilizo Fedora en el escritorio de la uni y en el portátil desde el que escribo. En este portátil tengo la misma instalación desde 2017, y no hay casi basura precisamente porque empecé usando contenedores aquí. SilverBlue me propone utilizar flatpak o contenedores en vez de dnf o contenedores. Yo ya utilizo contenedores principalemente, por lo que flatpak o dnf para las 4 cosas básicas lo mismo me da. En tema de hardware y drivers, no veo qué me da. Lo único que sí me ha hecho pensar es lo de aislar el navegador. Puede que sí tenga sentido empezar a enjaular Firefox, ya que cada vez más aplicaciones dependen del navegador. No obstante, cuando empecé a usar software libre, me resultó muy difícil cambiar de Windows, Office y Explorer, a Ubuntu, OpenOffice y Firefox. Lo intenté varias veces y no pude. Al final, lo que hice fue cambiar las aplicaciones primero. Empecé a usar OpenOffice y Firefox en Windows. Cada ve que tenía que usar una nueva aplicación, buscaba una alternative libre, en Windows. Al cabo de unos años, cuando todas las aplicaciones que usaba/uso eran software libre, cambié el sistema porque ya lo único que me quedaba por aprender era el escritorio. Del mismo modo, para quien no ha utilizado nunca (o poco) venv, snap, appimage, conda, contenedores, etc. utilizar por ejemplo flatpak en fedora o snap en ubuntu creo que puede ser didáctico para exponerse al "aislamiento" de las aplicaciones y datos de forma paulatina y empezar a pensar en terminos de ¿y si no tuviera que formatear el sistema nunca? ¿y si considerara esa tarea vintage? *# Hipervisores, VMs, LXC, docker|podman* A mayores, CoreOS sí lo veo interesante como sistema base para VMs en sistemas con hipervisor. Llevo varios meses utilizando Proxmox en un par de máquinas del laboratorio y una en casa, y estoy encantado. Tanto que me planteo usarlo como sistema base en mi equipo principal (cuando tenga más de cuatro cores), y virtualizar el sistema de escritorio. Básicamente es Debian con QEMU KVM y una capa de software (en perl) que provee una GUI web. Soporta VMs y contenedores LXC, además de opcionalmente backups y agregación de varios nodos en clusters. Yo lo uso sólo como gestor de VMs y contenedores por ahora. En 2-3 días, conseguí crear una VM con Windows 11, otra con Ubuntu,y configurar una GPU para que la ignore el sistema base y se conecte a una de las VMs. Llevamos meses utilizándolo intensivamente sin problemas. En Proxmox, los contenedores que pueden ejecutarse de forma nativa son LXC, no los OCI (docker|podman). Por lo tanto, lo más immediato para ejecutar multiples contenedores OCI es crear una VM y utilizar podman ahí. En esa VM tiene sentido utilizar CoreOS, en vez de Alpine o Ubuntu Server. El Debian base no tiene entorno gráfico, por lo que puede hacerse tediosa la gestión de ficheros. Si la VM tiene SilverBlue en vez de CoreOS, se puede utilizar nautilus o el explorador que se desee para organizar el contenido. Así, de Proxmox me parece interesante poder tener: - Debian como base. - Un Windows y un Linux como sistemas principales que pueden o no ejecutarse concurrentemente. - Una máquina auxiliar con linux para tener "servicios" (e.g. bittorrent, jellyfin) ejecutados con contenedores. - Poder crear o clonar VMs puntualmente para hacer pruebas y después borrarlas, sin que nada de ello tenga que ver con el escritorio (windows y/o linux). - Igualmente, poder usar contenedores en VMs temporales. - Curiosidad por aprender cuáles son las diferencias entre LXC y OCI. Eso para un sistema con >=6 cores y >=16 GB de RAM no es carga. La VM auxiliar puede usar 1-2 cores y 2-4 GB, por lo que la principal (que viene a ser el escritorio) sigue siendo un pepino de al menos cuatro cores y 12 GB. Es decir, la inmutabilidad en este caso es que el sistema base y el escritorio no son el mismo. Todas las otras soluciones que estamos comentando presuponen que el sistema principal es donde están las X (Wayland) y tratan de aislar todo lo demás. Por mi experiencia, las X (y los drivers de las GPUS, y Wayland) son una fuente relevante de inestabilidad y/o problemas tras actualizaciones. Pero soy muy consciente de que roza el límite del pragmatismo. Es una solución razonable si sé que voy a usar siempre al menos 2 o 3 VMs (o contenedores). Pero es, de facto, como tener y mantener 2/3 ordenadores (sistemas), cosa que razonablemente la mayoría de usuarios no quieren hacer. Yo lo veo natural porque como digo ya utilizo al menos 4 equipos a diario. La razón por la que no he dado el paso en mi equipo principal aún es porque no quiero tener dos juegos de teclado y ratón conectados al equipo (uno para el host y otro para la VM de escritorio). He resuelto que el host utilice uno monitor y la VM gestione el resto. También que un hub USB vaya a la VM (para pendrives, discos externos, etc.). Pero todavía tengo que mirar cómo de complicado y sobre todo reliable es utilizar una combinación de teclas para cambiar los periféricos de un sistema a otro. Por la tecnología que usa, creo que Proxmox entra en la categoría de https://katacontainers.io/ y QubesOS. karacontainers en vez de ejecutar un contenedor directamente, crea una VM con QEMU KVM, instala un sistema mínimo y ejecuta el contenedor ahí. Lo hace mediante el runtime de los contenedores, por lo que esa es la diferencia con respecto a Proxmox o la utilización explícita de QEMU. El usuario ejecuta los contenedores usando los mismos comandos que usaría en una instalación de docker normal, pero por debajo de forma transparente kata hace y destruye la VM. Anecdóticamente, lo descubrí porque un servidor de la Universidad de Manchester se comportaba raro con algunos contenedores y resultó ser que el demonio estaba configurado para usar kata por defecto. Siempre me ha parecido que es interesante para datacenters donde es importante el aislamiento entre usuarios. Pero para mis casos de uso no veo ventaja. Yo no ejecuto nada en contenedores que no ejecutaría nativamente en el host. No los utilizo para seguridad, sino como herramienta de empaquetado y distribución de entornos de software "ready-to-use". A mayores, cuando katacontainers surgió, podman estaba muy verde. Hoy en día no sé si podman resuelve ya los problemas que katacontainer intenta atajar incluyendo QEMU en el stack. En cuanto a QubesOS, me está haciendo pensar, mucho. No entiendo qué diferencia hay entre KVM y Xen, pero si la UX es parecida tampoco me importa. Me gusta mucho que en https://www.qubes-os.org/intro/ haya una GuiVM, una sys-usb VM y una sys-net VM con el logo de Fedora. Parece que han resuelto que las ventanas de multiples VMs se muestren en el mismo escritorio ( https://en.wikipedia.org/wiki/Qubes_OS#/media/File:Qubes_security_domains.png). Con Proxmox, cada VM tiene un monitor virtual (en la VM QEMU), al que luego el host permite acceder por VNC. O, si la máquina es Windows, se puede usar RDP exponiendo el puerto (o tunelándolo). Por eso, de facto, hace falta varios monitores si se utilizan GUIs en varias máquinas; o xpra. Al usar contenedores (docker o podman) el tema de las GUI es algo que suele echar atrás. Por defecto, no se pueden usar GUIs porque no hay monitor ni gráfica dentro del contenedor. De las varias soluciones (instalar SSH o VNC dentro del contenedor, que la GUI sea web y se use con un navegador en el host, etc.) la que más me gusta es https://github.com/mviereck/x11docker. Como se indica en https://github.com/mviereck/x11docker#features, el desarrollador tiene interés notable en la seguridad, por lo que además de permitir ejecutar GUIs en contenedores usando el escritorio del host, aplica muchas opciones para limitar el alcance de los contenedores. Como en el desarrollo hardware es habitual utilizar GUIs, estoy acostumbrado a tener múltiples ventanas en el escritorio, cada una proveniente de un contenedor. De hecho, así es como uso varias herramientas de Linux en un escritorio Windows. Hay un GIF/grabación en https://hdl.github.io/containers/ug/GUI.html. Una referencia obligada es https://blog.jessfraz.com/post/docker-containers-on-the-desktop/ (nótese la fecha). En este sentido, QubesOS parece ofrecer una UX muy similar, pero con VMs en vez de contenedores. Me surgen varias dudas: - ¿Por qué VMs y no podman? Que los qubes se puedan crear sobre Xen o como contenedores en la AppVM principal. - ¿Es possible hacer passthrough de discos, GPUs u otros periféricos a una AppVM con Windows 10|11? Entiendo que la AppVM 1, la principal, no puede ser. Esa tiene que ser linux (en el diagrama Debian), del mismo modo que el host de Proxmox es Debian. Que el diagrama muestre el logo de Windows 7 mosquea un poco. - ¿Cómo de fácil es hacer una VM "tradicional"? Me refiero a una que no esté integrada en el sistema, como el resto. Sino simplemente asignar número de CPUs, cantidad de RAM, periféricos (virtuales o físicos) y tratarlo como una caja cerrada. Si todas las VMs se consideran parte del sistema, entiendo que en principio no estáran limitadas en cuanto a recursos (en https://www.qubes-os.org/attachment/doc/r4.0-qubes-manager.png sólo se muestra el disco), pero para otros servicios auxiliares es importante. De hecho, en Windows utilizo Docker con HyperV y huyo de WSL2 porque HyperV permite limitar las cpus y memoria, pero WSL2 no. Mayo viene cargadito, pero sin duda tomo nota de QubesOS para probarlo en verano. Eskerrik asko por sacar el tema, espero que algo de esto te/os resulte interesante/útil y mesedez comentanos si decides probar alguna! Salud Unai El jue, 20 abr 2023 a las 7:58, Christian Pinedo Zamalloa (< [email protected]>) escribió: > Aupa, > > llevo muchos años ya siendo fiel a ArchLinux pero con el tiempo tanto las > rolling release como las distros clásicas basadas en releases se convierten > en un pequeño estercolero con restos de todas las pruebas que has ido > realizando, cambios de configuración, entornos gráficos, lenguajes de > programación, ajustes... Esto me genera dos preocupaciones en el día a día: > 1. la estabilidad del sistema operativo > 2. la seguridad del sistema operativo > > Para (1) haces apaños como btrfs con snapshots. Para (2) actualizas, > firewall, luks, pruebas firejail/bwrap para hacer una "jaula" a firefox y > otros... > Pero da la sensación que todo lo complicas más. > > En este aspecto las nuevas distros inmutables como Fedora > Silverblue/Kinoite, OpenSUSE MicroOS y VanillaOS parece que son un aire > fresco. Tengo un sistema base "inmutable" al que después de actualizar > puedo hacer rollback. Esto mejora la estabilidad del sistema operativo, > tambien la limpieza porque se complica instalar software nuevo en esa capa > base de sistema operativo, la gestión de la configuración es otro mundo > (creo que no la abordan) y te obliga a instalar aplicaciones con > flatpak/appimage/snap/nix o directamente a usar contenedores con > toolbox/distrobox. Creo que es un sistema más complejo pero te obliga a un > workflow en el que el sistema operativo base lo tocas lo mínimo, todo más > limpio. Y creo que mejora la seguridad (menos aplicaciones en el sistema > operativo base, en Fedora Silverblue/Kinoite viene SELinux activado...). > > En general es como tener un sistema operativo "hipervisor" "base" que es > más robusto y tocas lo menos posible. > > Aqui tambien podría entrar en juego QubesOS que esta muy enfocado a la > seguridad. Pero tiene ese concepto de sistema operativo base hipervisor > limpio y seguro. Y todo tu trabajo lo realizas con Máquinas Virtuales que > vas creando y destruyendo. Ahora bien necesitas un pepinaco de PC en CPU, > RAM y SSD/NVMe para que las aplicaciones se arranquen ligeramente. Y la > usabilidad y libertad esta muy mermada por su forma de uso. Yo con mi > thinkpad x250 se me hacia muy lento... > > Por otro lado, estan distros como NixOS y Guix que aqui ya me pierdo. Que > deben tener peculiaridades con esas distros inmutables (Fedora > Silverblue/Kinoite, MicroOS...) pero que no aportan exactamente lo mismo. > Me pierdo aqui... > > ¿Tenéis experiencia con distros inmutables? ¿las recomendais? > ¿Alguno ha dado el paso hacia NixOS/Guix? ¿Que aportan? ¿ventajas > inconvenientes? Incluso, aunque solo sea al gestor de paquetes ¿nix? > ¿Somos de la vieja escuela y seguimos con Debian, Ubuntu, ArchLinux? :-D > > Saludos! > > -- > Christian > PGP fingerprint: A895 7C11 84F6 30B4 4938 32A4 9306 DFD0 CDE4 B542 > _______________________________________________ > ITSAS mailing list > [email protected] > http://list.ehu.eus/mailman/listinfo/itsas >
_______________________________________________ ITSAS mailing list [email protected] http://list.ehu.eus/mailman/listinfo/itsas
