Hace dos meses que cambié trabajo a uno con más carga de análisis, lo que conlleva que necesite adquirir más y mejores prácticas con mi organización, especialmente el código. En dos meses he tenido que adoptar nuevas formas de hacer las cosas y me apetece dejar constancia de qué cosas ya utilizaba, y de cómo está siendo el proceso de incorporar cosas nuevas.

Trabajar en un HPC

En este nuevo trabajo se usa un clúster de computación distribuida (o de alto rendimiento, high performance cluster, o HPC). En lugar de una única máquina “enorme” (muchas CPUs y memoria), usamos una red de ordenadores interconectados que comparten sistema de archivos, rutas y directorios, usuarios, etcétera, de modo que múltiples usuarios pueden estar empleando muchos recursos sin solaparse. Esta upgrade implica cambios: en vez de hacer login y lanzar programas tal cual, existe un sistema de colas (llamado SLURM) para que todos los usuarios podamos usar los recursos ordenada y responsablemente. Toca cambiar hábitos como:

1. No usar tantas sesiones de trabajo “interactivas” (acostumbrarse, por ejemplo, a volcar la salida de todo en archivos y a adquirir costumbre de consultar todos los runs);
2. Modularizar los pasos de nuestro análisis para correr las distintas tareas usando sólo la cantidad de recursos necesaria;
3. Requiere, también, hacer algo de refactoring a los scripts, y añadir algunas “capas adicionales de cosas” como los scripts sbatch que utiliza SLURM.

Yo ya trabajé durante varios meses en un sistema de HPC y me resultó un poco pesadilla. En este trabajo habré lanzado (y ejecutado con éxito), por ahora, unos 10 o 20 trabajos. (Y unos 50 fallidos). Ahora me resulta más llevadero que al principio -o que la vez anterior-, gracias en parte a que he acomodado partes del sistema a mi manera.

Personalización hasta en las entrañas

Una de las ventajas de Linux de las que menos he hablado en el blog, es la facilidad de adaptarlo a tu forma de trabajar con cosas tan fundamentales como scripts, aliases, y variables, independientemente del apartado gráfico.

Un ejemplo de aliases: es muy conveniente volcar la salida de los trabajos de SLURM en archivos de texto .log (yo por ejemplo tengo una carpeta ~/logs/). Pero al tiempo te verás con muchos registros previos que podrían dificultarte la navegación. Una forma personal que he encontrado de lidiar con esto es tener una carpeta oculta llamada ~/.logs o ~/.obs_logs (de “obsolete logs”), donde ir colocando los más antiguos. Pues bien, en lugar de ir haciendo `mv` a todos, me hice un alias llamado `flush` que hace esto con un simple comando monosílabo. Lo mismo con comprobar el estado de las colas cada segundo, o el estado de un trabajo que se está ejecutando.

Los aliases permiten personalizar el comportamiento de aplicaciones base como ls. Podemos, por ejemplo, definir la expresión ls como un alias para correr el comando base junto a una serie de parámetros convenientes como pueda ser --group-directories-first, ordenar por fecha de modificacion, --color-auto para colores automáticos, etc.

Los aliases se pueden definir en cualquier archivo con código de bash que se ejecute al inicio de sesión de tu usuario, como los archivos .bashrc, .bash_profile, o .profile. Tras hacer los cambios oportunos en estos archivos, toca hacerles source (volver a cargarlos) para cargar en el sistema las últimas modificaciones… pues, de nuevo, esto puede ser también un alias, que yo he llamado reload.

Para comportamientos más complejos podemos definir funciones, también, aunque no he jugado mucho con ellas.

Instalando que es gerundio

También, como parte de la personalización, está la instalación de programas “en local”, en ubicaciones distintas de las habituales del sistema, únicamente para tu usuario. Esto es especialmente útil si no tienes privilegios de administración (que suele ser el caso en entornos como un HPC), y es posible porque existe una variable del sistema llamada $PATH que alberga todas las direcciones donde el sistema puede buscar ejecutables. El contenido de $PATH también se cambia en el ~/.bash_profile .

Una ventaja adicional de instalar “en local” es que puedes tener mayor control con las versiones de los programas, incluso tener varias versiones de un mismo programa, sin conflictos entre ellas. Pero hay otra manera aún mas elegante de instalar programas en local que permite sobrepasar por completo este problema.

Se trata de entornos virtuales, y para eso utilizo dos formas: venv con pip, y conda (o mamba). Cada programa tiene su propio entorno, que consiste en un sistema de referencias a rutas específicas distinto al del sistema base, y así no hay problemas. Es ligeramente parecido a lo de cambiar las ubicaciones de $PATH, y al fundamento tras de flatpak y similares. Los entornos virtuales se crean, se activan, y se desactivan. Y para hacernos la vida más fácil también ponemos todo esto como aliases o funciones.

Nuevas y viejas herramientas

Hay otras herramientas que quiero aprender a manejar, al menos a defenderme:

1. El editor de texto vim, del que no hace falta decir más. He visto algunos vídeos de las virguerías que permite hacer y, por el mero hecho de que está en muchas distros, me planteo aprenderme los comandos básicos de navegación, búsqueda/sustitución, y edición multilínea. Incluso trae un tutorial, no tenía ni idea.
2. yazi, un navegador muy cómodo que descubrí hace poco que te permite explorar carpetas y archivos en modo texto navegando con las teclas, y si instalas ciertas dependencias te permite previsualizar imágenes, añadir “iconos” (usando las Nerd Fonts), etcétera. He de decir que no me gusta el nombre del programa, pero, yo lo tengo como alias con “fm” .
3. helix, o hx, como editor multipropósito, porque permite organizarse la pantalla de una forma que me recuerda a otros IDEs que ya he usado antes. Se organiza como vim, con comandos.

Cuento también a Codium, que la empecé a utilizar a saco unos pocos meses antes de llegar aquí, y que me resulta especialmente útil por la extensión de SSH remoto para conectarme a los servers donde tengo kernels corriendo (R, python, Jupyter).

Hay otra más que ya la he incorporado al elenco, y esa es tmux. Había leído a varias personas hablar de tmux en sus blogs y en el fediverso, pero no sabía lo que me perdía. Es un multiplexador de la terminal, que te permite tener varias abiertas simultáneamente, subdividir la pantalla, … nada que no puedas hacer a base de abrir ventanas de la terminal a mano, pero la velocidad que se gana es considerable. Yo antes utilizaba screen, pero tmux está más modernizado. Es comodísimo, elegante, e híper configurable, una de esas cosas que te preguntas dónde había estado todo este tiempo.

Nuevas y viejas costumbres

• He empezado a utilizar git muchísimo en el trabajo, pero a un nivel muy básico de hacer cambios, añadirlos a la pila, hacerles commit, y push. Me sirve mucho para tener mi trabajo centralizado en más de un sitio, y para ser consciente de la constancia y el ritmo con el que voy haciendo cosas. Ahora casi cualquier cosa que hago la intento meter en un repositorio, aunque no es posible con todo por practicalidad. Me planteo cambiar de Github a GitLab más adelante.
• Voy cogiendo soltura administrando sistemas: entre una cosa y otra, en dos meses he configurado unas seis máquinas con linux: el PC local en el trabajo, mi usuario en el hpc, el server previo, mi portátil previo (Thinkpad E595), el nuevo del que ya hablé (P15 G2i), y… el último que ha entrado a la “familia” (T14 Gen3), que reemplazará al mío anterior. A añadimos iPad, móvil, y un Android viejo, con iSH y Termux respectivamente. Tanta terapia de choque me ha motivado para aprender a usar sistemas muy pequeñitos y ahora quiero aprender a configurar Alpine linux para self-hosting y para pequeña computación en cualquier sitio.
• He aprendido cosillas básicas de contenedores en Linux, y lo de Alpine me encaja con esto porque podría intentar hacer algunos de mis nuevos proyectos como una pieza hiper-reproducible de análisis. Por no hablar de otras cosas como lanzar servidores para cosillas de selfhosting,

Para acabar: apuntes visuales

• Suru es el mejor tema de iconos que jamás se hizo para Ubuntu, al menos las carpetas eran bien bonitas. Me sorprende lo bien que seigue funcionando en GNOME 48 y 49, con algunos arreglos al index.theme.
• Lo mismo con los iconos Oxygen de KDE, con un par de añadidos al index.theme se ve súper bien. Incluso aunque el tema tiene cerca de quince años.
• He puesto fuente monoespaciada en casi todos los sitios del sistema, salvo en la web y documentos que ya traen sus fuentes.
• Hace poco aprendí que existía el tema de colores “Solarized” para las terminales y, junto con Fira Code como fuente, se ha vuelto una constante en mis interfaces de trabajo.
• Le estoy pillando el gusto fuertemente a las interfaces de texto, las letras monoespaciadas que existen a día de hoy son muy bonitas. No descarto probar un gestor de ventanas sencillo pero moderno, más adelante.

Apuntes finales

Todo esto que voy implementando y haciendo lleva detrás una buena parte de indagar online, leer documentación, y en general exponerme a cosas que ni sabía que existían o cómo funcionaban. Creo que siento como se me vuelve a activar ese modo esponja como me he ocurrido en otras etapas. Ya lo echaba de menos! A veces se hace un poco cuesta arriba, pero creo que a la larga me acabaré acostumbrando e incluso me hará más fácil dar el salto a hacer aún más cosas.

Siento que estoy aprendiendo una barbaridad y quiero que siga siendo así.