¿Qué es una biblioteca (o «library») en una distribución GNU/Linux?

Las bibliotecas son una de las partes más esenciales del software, y es una palabra que posiblemente hayas visto en tu gestor de paquetes. ¿En qué consisten realmente?

En raras ocasiones, en GNU/Linux te encontrarás mensajes de error o de advertencia que hacen referencia a palabras como biblioteca o library. También en español se le suele llamar librería, y aunque desde el punto de vista pragmático se refiere al mismo concepto, algunas personas cuestionan este nombre porque la traducción correcta de library es biblioteca. Sin embargo, una pregunta más importante independientemente del nombre es: ¿qué es esto? En este post voy a tratar de definirlo en conceptos simples y sin dar mucha vuelta.

¿Qué es una biblioteca de software?

Una biblioteca de software es una pieza de software que aunque ofrece funcionalidad, igual que la que puedes encontrarte en un programa tradicional, no puede ser clasificado como programa porque como tal no lo puedes lanzar haciendo doble clic sobre su icono o escribiendo un comando de terminal.

El rol de la biblioteca es proporcionar servicios que puedan ser usados por otras piezas de software. Estos servicios a menudo se corresponden con código que es ejecutado por el ordenador a petición de un programa o de otra biblioteca. De este modo, la biblioteca recibe lo que se podría denominar una petición de servicio para que haga una operación, y eso hará que nuestro ordenador procese cierto código máquina proporcionado por la biblioteca para generar un resultado del servicio.

Por poner un ejemplo, en cualquier distribución GNU/Linux podemos identificar varios editores fotográficos, como son GIMP, Inkscape o Krita. Sin embargo, la realidad es que ninguno de estos programas que menciono sabe cómo transformar los ceros y unos que hay dentro de una foto de tipo JPEG en los colores que luego se ven por pantalla. En su lugar, usan los servicios de una biblioteca de manipulación de imágenes JPEG. Esta biblioteca puede ser, por ejemplo, libjpeg.

libjpeg es una biblioteca experta en el manejo de imágenes JPEG. Sabe cómo transformar esos unos y ceros en píxeles, y sabe cómo volver a codificar píxeles para crear una foto nueva. Sin embargo, no puedes interactuar directamente con una biblioteca. No hay un icono para abrir libjpeg, ni tampoco puedes simplemente escribir en la terminal de tu sistema operativo el comando libjpeg para interactuar con este software.

¿Por qué existen las bibliotecas de software?

Puede ser visto desde fuera como poco educado que un programa se aproveche de las funciones de otro para hacer su trabajo. Sin embargo, en realidad esta situación no sólo es ventajosa sino que por evolución hemos llegado a ella. Existen varias razones por las cuales las bibliotecas de software tienen aceptación y se suelen utilizar para distribuir software.

Una de las ventajas es que permite reducir el tamaño de un programa. Si cada programa del mercado tuviese que incorporar su propio descodificador de imágenes JPEG, por ejemplo, los paquetes de software ocuparían más espacio de almacenamiento debido a que cada programa tiene que incluir sus propias instrucciones de procesador para que el ordenador pueda hacer esas tareas. Hoy en día no es un problema tan grande como antes, pero cuando los ordenadores tenían discos duros más pequeños sí que era de agradecer. Incluso hoy en día, en algunas placas de computación y otro tipo de microordenadores, suele ser importante medir para qué se usa cada byte de almacenamiento.

Por otra parte, que la comunidad centre sus esfuerzos en una biblioteca común que sólo sepa hacer bien una cosa pero que la haga bien, facilita que las mejoras que se incorporen a las bibliotecas estén disponibles a la vez para todos los programas que usen sus servicios, algo que hace que todos los programas se beneficien a la vez. Imagina que un día se inventa un algoritmo nuevo que es capaz de decodificar imágenes JPEG mucho más rápido. Si hay que enseñarle ese algoritmo a cada programa, tendríamos programas descompensados que serían más lentos. Si se hace esa mejora en la biblioteca, todos los programas que usen sus servicios pueden verse favorecidos a la vez.

También está el tema de la seguridad. A veces los procedimientos de cálculo que ejecutan los programas pueden ser arriesgados, y un programa malicioso puede aprovecharse de ciertos errores de computación en algunos de estos programas para hacer cosas inapropiadas. Es más sano corregir el error una vez y que todos los programas que dependan de ella se vean beneficiados a la vez, a tener que arreglar por separado cada programa, puesto que algunos no se actualizarán tan deprisa y podría suponer un riesgo de seguridad a los usuarios.

¿Por qué a veces las bibliotecas de software dan problemas?

Las bibliotecas de software no siempre funcionan bien. En ocasiones, puede ocurrir que un servicio se presta diferente en la versión 1.0 de una biblioteca, que en la versión 2.0 de la misma biblioteca. Si un programa ha determinado que necesita la versión 1.0, pero otro programa necesita usar la versión 2.0, será complicado satisfacer ambas demandas sin instalar a la vez ambas versiones.

Soluciones como AppImage buscan precisamente solucionar estos problemas haciendo que cada paquete de software traiga consigo mismo una copia separada de la biblioteca, a costa de perder las ventajas para el usuario final. Los programas que se distribuyen como AppImage pesan más, y si se instalan varios puede ocurrir que ocupen más espacio. Sin embargo, resulta útil para solucionar este tipo de problemas por lo que al final del día, dado el tamaño de los medios de almacenamiento típicos de la actualidad, no se considera un problema.

Flatpak y Snap resuelven este problema de forma más limpia, permitiendo que múltiples versiones de una misma biblioteca estén instaladas a la vez en el ordenador pero en lugares separados, y utilizando un sofisticado sistema de resolución para que un programa indique de forma exacta qué versión de una biblioteca necesita que le proporcione servicios.

Diccionario UNIX: Tarball

Puede que alguna vez hayas escuchado el término tarball. En esta entrada de blog te quiero contar qué es un tarball. Más concretamente, qué tipos de tarball hay.

Un tarball es simplemente el apodo que recibe un archivo TAR. El origen de la palabra tarball simplemente viene de un juego de palabras, debido a que en inglés, «tar» también quiere decir «alquitrán». Al final del día, no es más que una forma cariñosa de referirse a uno de estos archivos. Pero, ¿qué es realmente un archivo TAR?

TAR es un archivador. Es un formato diseñado para tomar varios archivos y juntarlos en uno único. Por ejemplo, puedes tomar todos los logs de la carpeta /var/log, que estarán dispersos con múltiples nombres, y fabricar un único archivo tar (un tarball) con el que será más fácil de archivar o compartir los datos.

Esquema de cómo funciona (más o menos) un archivo TAR.

El origen de TAR viene de Tape Archiver, y es que TAR es un formato y un programa que lleva con nosotros muchos años. Precisamente el objetivo inicial de TAR era juntar varios archivos en un mismo flujo de bytes para poder pasarlo de forma más fácil a una cinta magnética, en los viejos días donde se usaban cintas magnéticas para guardar la información. Eventualmente, TAR adquirió soporte para guardar en su lugar el flujo de datos en un archivo del disco duro y, hoy en día, sería rara la idea de guardar sobre cinta (a pesar de que hay gente que lo sigue haciendo).

Uno de los puntos clave sobre TAR es que, a diferencia de otros formatos como el ZIP o como el 7Z, TAR no comprime los archivos. Solamente los junta y les pone una serie de metadatos al principio del archivador para que luego se puedan extraer, es decir, separar y volver a dejar como múltiples archivos separados.

Para comprimir un archivo TAR hay que usar otra herramienta separada, como gzip, lzip o xz. Existen múltiples formatos de compresión porque cada uno fue desarrollado en una época distinta y trata de mejorar lo que ya existe. Por ejemplo, el último en aparecer es zstd, el cual promete grandes mejoras de rendimiento cuando se usa en centros de datos grandes.

Sin embargo, lo que hay que tener claro es que, a diferencia de ZIP, donde archivas y comprimes a la vez, en TAR son dos pasos separados. Si quieres crear una carpeta comprimida usando formatos libres, tendrías que:

  1. Juntar con TAR todos los archivos de un directorio en un mismo archivador (por ejemplo, datos.tar).
  2. Comprimir ese archivo (datos.tar), para convertirlo en datos.tar.gz, datos.tar.xz, datos.tar.bz2…
Esquema de la concatenación de un TAR y de su compresión por separado

Por lo general, la forma más correcta de tratar con un archivador comprimido es mantener las dos extensiones, para dejar claro que es un TAR comprimido con algún tipo de algoritmo. En este caso la extensión nos dirá qué tipo de algortimo tenemos que usar para descomprimir. Por ejemplo, .tar.gz nos dice que se trata de un tarball comprimido con gzip, .tar.xz que es un tarball comprimido con xz (LZMA), .tar.bz2 que está comprimido con Bzip2, etc.

Sin embargo, en muchas ocasiones nos vamos a encontrar que juntan ambas extensiones en una única por comodidad. Si somos capaces de entender que .tgz es lo mismo que .tar.gz, y que .txz es lo mismo que .tar.xz, estaremos bien.

Diccionario: LTS

Algunas distribuciones GNU/Linux suelen anunciar en su página web el lanzamiento de versiones LTS. Por ejemplo, en el caso de Ubuntu. ¿Qué quiere decir LTS?

Algunas distribuciones GNU/Linux suelen anunciar en su página web el lanzamiento de versiones LTS. Por ejemplo, en el caso de Ubuntu. ¿Qué quiere decir LTS?

LTS son las siglas de Long Term Support, y hace referencia a que se trata de versiones que van a recibir soporte por parte de los maintainers de la distribución durante más años que una versión regular.

En todas las distribuciones de GNU/Linux serias que encontremos por internet, va a haber una persona o grupo de personas a cargo del mantenimiento. Esto incluye detectar y corregir errores que se puedan producir en la versión, o fundamentalmente el coordinar la entrada de actualizaciones por parte de otros paquetes. Por ejemplo, si KDE corrige un bug en Plasma y la distribución porta KDE Plasma en sus repositorios, el soporte hace referencia a que eventualmente tu gestor de paquetes te traiga la actualización que corrige ese bug porque quien está manteniendo la versión de tu distro se ha ocupado de importar en el gestor de paquetes esa versión corregida.

Soportar versiones de GNU/Linux es complicado y lleva esfuerzo, porque hay que vigilar y en algunos casos securizar y validar correcciones de errores a muchos paquetes para asegurarse de que un arreglo en un paquete no causa problemas en otro. Simultáneamente, las distribuciones GNU/Linux a menudo buscan sacar versión cada pocos años para hacer evolucionar la plataforma, cambiando la arquitectura de la distro. Por ejemplo, cambiar a systemd, cambiar a PipeWire…

Estas dos cosas provocan que sea imposible estar perpetuamente dando soporte a una versión de una distribución GNU/Linux. Es mejor centrar sus esfuerzos en un conjunto de versiones limitada e ir rotando. Esto quiere decir que cuando una nueva release de la distribución sale, la más antigua pierde soporte, para que su equipo se centre en corregir los errores de una.

Generalmente las distribuciones tienen un calendario de publicación. Por ejemplo, sacan una nueva ISO y una nueva versión (Debian 8, Debian 9, Debian 10…) cada 2-3 años, o cada 6 meses, o el primer día de cada mes de abril, por decir algo. Y también establecen una duración para el soporte a esa versión. Por ejemplo, durante los siguientes 9 meses, durante los siguientes 2 años, o hasta que pasen 3 meses de la salida de la siguiente versión de nuestra distro.

Las versiones LTS están marcadas porque no son así. En este caso, el soporte durará más tiempo. Por ejemplo, durante 5 años o durante 10 años desde el lanzamiento de la versión. Esto las hace ideales para instalar en entornos donde queramos no estar cambiando cada dos por tres de sistema operativo o actualizando la versión, por los posibles problemas que pueda traer. Esta es la razón por la que es preferible en un servidor web instalar Ubuntu 22.04, que es una versión LTS, a Ubuntu 22.10, que es una versión que no es LTS y que al cabo de 9 meses tendrá que ser sustituida por otra.

Algunos ejemplos de distribuciones que tienen soporte a largo plazo son:

  • Ubuntu. Si bien las versiones regulares se publican con soporte a 9 meses, la versión que sale cada abril de año par (es decir, la 18.04, la 20.04, la 22.04, la 24.04…) es LTS, y tiene soporte durante varios años. Esto la converte en la distro de preferencia para instalar en entornos donde no deba ser tocada en varios años.
  • RHEL y derivadas. Por ejemplo, EuroLinux, Oracle Linux o Rocky Linux. Se tratan de versiones que igualmente parten del código fuente de Fedora, pero que tienen un soporte de varios años (hasta 10 años).
  • Debian. Sale una versión de Debian aproximadamente cada 2 años. El soporte de cada una de estas versiones dura 3 años. Sin embargo, sigue existiendo un soporte a largo plazo que dura más años, por lo que se puede estar aprovechando una instalación hasta 5 años hasta que llegue el momento de despedirse de ella definitivamente.