atareao con Linux

Que distro Linux elegir para programar

Vistas: 1
atareaoModificado: lunes, 02 de noviembre de 2026Comenta
0:00 / 0:00
Que distro Linux elegir para programar

Hola, soy Lorenzo y esto es Atareao con Linux, episodio número 652. Si te has fijado, no hay cortinilla de entrada. Y al final, ya te lo adelanto, tampoco habrá cortinilla de salida. No es un descuido ni un fallo de edición, es un episodio un tanto especial, y en unos minutos entenderás por qué. Hoy quiero hablarte de una de las preguntas que más veces me habéis lanzado en el grupo de Telegram, qué distro Linux elegir para programar, y de paso contarte un par de cosas que se me han cruzado estos días y que me apetecía compartir contigo. Así que vamos directos al turrón.

Y empiezo por el suspense, porque este episodio no lo estoy grabando en mi equipo de escritorio. No tengo el Slimbook, no tengo la interfaz de audio, no tengo el micro, no tengo absolutamente nada de mi montaje habitual. Estoy grabando en lo que me gusta llamar movilidad, aunque tampoco te quiero engañar: no es movilidad del todo, porque ahora mismo estoy sentado en una habitación. Pero sí tengo un micro pequeñito cerca de la boca para poder grabar, y lo estoy haciendo con el móvil. Y con una particularidad bastante llamativa, porque he conseguido dividir la pantalla del teléfono en dos partes. En la de arriba tengo la grabadora. En la de abajo tengo Obsidian, y en Obsidian llevo los apuntes de lo que exactamente te quiero contar. Es algo novedoso y, para qué negarlo, completamente rompedor, porque no había previsto hacerlo así de ninguna de las maneras.

Lo que tenía pensado para esta salida era traerme la tablet, un OnePlus Pad 2, y con ella no solo preparar el guion del podcast de una forma un poco más exhaustiva, sino también investigar a fondo el editor Helix, del que ahora te contaré algo y por qué me interesaba. Pero hay un detalle importante que quiero confesarte, y es que por mucha tecnología que acumulemos y muchos avances que tengamos, al final el ser humano es humano y las cosas pasan porque tienen que pasar. Preparé todo el equipaje, preparé la tablet con su funda y sus cosas, y salí de viaje. Todo menos la tablet. La tablet se quedó en casa. Así que esa investigación que quería hacer y que quería contarte en este mismo episodio se ha quedado en el tintero, porque no he podido hacerla. Que le vamos a hacer. Pero algo sí te puedo mencionar sobre Helix, porque ya lo había probado antes y hay una historia detrás que merece la pena.

Helix y ese modo de selección que no tiene Neovim

Vamos con Helix, porque tiene relación directa con el tema de hoy. Helix es un editor modal para terminal, implementado en Rust, que se presenta como una alternativa moderna al linaje de Vim y Neovim. Comparte con ellos la filosofía de los modos, la de teclear órdenes en lugar de agarrar el ratón, y el apego por la terminal. Pero debajo de esa piel hay una diferencia de fondo que a mí me costó entender. En Vim y en Neovim el modelo clásico es el de operador más movimiento: primero dices qué vas a hacer, por ejemplo borrar, y después dices sobre qué, por ejemplo hasta la próxima palabra. En Helix el orden se invierte, es lo que se llama edición guiada por selección. Primero seleccionas el texto y después aplicas la acción. Suena a tontería, pero cambia por completo la forma de trabajar y, sobre todo, la memoria muscular que tienes que reconstruir.

Y aquí viene el motivo de mi metedura de pata. En el grupo de Telegram de Atareao con Linux se estuvo hablando de Helix, se hicieron varios comentarios, y yo lo volví a probar a raíz de aquellas conversaciones. Y en una de esas pruebas me di cuenta de que la vez anterior lo había estado usando mal. Lo había probado pensando que se comportaba exactamente igual que Neovim, y no es así. Helix tiene un modo propio, un modo de selección que no existe como tal en Neovim, y que es justamente el que te permite marcar el texto para luego actuar sobre él. Como yo daba por hecho que eso no existía, no lo tuve en cuenta, y fui encadenando errores que me llevaron a descartar el editor desde el primer minuto. Así que le voy a tener que dar una buena oportunidad nueva y probarlo en condiciones. Pero ya te digo que no es el tema central de hoy, es una de esas cosas que se me han cruzado y que quería apuntar aquí.

Si no habías oído hablar de Helix, merece una explicación rápida. Es un proyecto de código abierto, con licencia libre, que se distribuye como un único binario y que trae lo que en Neovim tienes que montar a base de plugins: resaltado de sintaxis mediante árboles de sintaxis, un sistema de selección múltiple pensado desde el principio, y una configuración que vive en un fichero config.toml. Frente a la cultura de dotfiles interminables de Neovim, Helix apuesta por traer las cosas puestas de fábrica. Eso tiene su parte buena, que arranca y funciona, y su parte mala, que si vienes de años de Vim toda tu memoria muscular te juega malas pasadas, que es exactamente lo que me pasó a mí.

Hay una lección que se repite en esto del software libre: muchas veces no descartas una herramienta porque sea mala, sino porque la juzgas con las reglas de la anterior. Y eso, con los editores modales, pasa constantemente.

El proyecto de programar en comunidad, ¿lo retomamos?

Hay un segundo asunto que quiero traer, y también está hilado con el hecho de programar. El año pasado, exactamente en el episodio 550 o 551, te hablé de aprender a programar en 2024. Te propuse tres proyectos para que los discutiéramos y eligiéramos cuál poner en marcha durante el año. Y elegimos uno en concreto, que era hacer un bot de Telegram para gestionar contenedores Docker. Pues bien, aquello no avanzó. No avanzó porque en otro podcast se hicieron una serie de comentarios, yo estaba esperando poder participar en aquel podcast y al final no sé si es que no continuaron con él o qué pasó. El caso es que se quedó parado.

Ahora mismo lo que quiero plantearte es una bifurcación. O continuamos con aquel proyecto del bot de Telegram para gestionar contenedores Docker, o, dado que últimamente estoy muy liado con el tema de las extensiones para GNOME Shell implementadas en TypeScript, te apetece más tirar por ahí. Te lo dejo abierto y te lo planteo tal cual. Yo, como te digo, a lo largo de este año sí que voy a hacer varias extensiones, eso lo tengo claro, aunque tampoco me quiero comprometer ahora sobre cuáles. Lo que sí te puedo adelantar es que al menos tres extensiones ya las tengo pensadas, más alguna que es sorpresa y que va a dar la campanada. Pero eso es otra cuestión.

Mi planteamiento es sencillo: si te interesa hacer alguna extensión en TypeScript y lanzamos un proyecto concreto, o si prefieres que continuemos con lo que ya empezamos, el bot para gestionar tus contenedores Docker. De momento lo dejo ahí. Este año, pese a lo que sucedió con el otro podcast, sí que tengo intención de llevarlo adelante si sale gente que quiera hacerlo. Las bases del episodio anterior están hechas, de hecho está creado el repositorio y en tres ramas están montados los primeros pasos, pero se quedó ahí, aparcado. Si te interesa, entras en atareao.es/contactar y me dices exactamente qué quieres: si seguir con esto o si hacer extensiones para GNOME Shell, lo que tú veas. Estoy completamente abierto.

Y un detalle de transparencia, porque me gusta decir las cosas como son: para mí fue un poco un duro golpe plantearme hacer algo en lo que llegáramos a un consenso y de repente, por cuestiones ajenas, no poder hacerlo. Pero bueno, qué le vamos a hacer. Lo dejo planteado y tú decides, que para eso estamos. Para que te hagas una idea de lo que implica la opción de las extensiones, conviene recordar que una extensión de GNOME Shell es un pequeño programa que añade funcionalidad al escritorio, y que se escribe en JavaScript sobre el motor de GJS. Con TypeScript por delante, que es JavaScript con tipos, tienes una capa de seguridad que agradeces en cuanto el proyecto crece un poco. No es un proyecto de fin de semana, pero tampoco es un imposible.

La pregunta equivocada: no es qué distro, es qué vas a hacer

Y llegamos al tema central, qué distro Linux elegir para programar. Una de las cuestiones más recurrentes que aparecen en el grupo de Telegram de Atareao con Linux es alguien preguntando qué distribución se recomienda para empezar en el mundo de Linux, o para tal o cual conocimiento concreto. Y mi planteamiento es completamente distinto. Yo siempre pregunto lo mismo: qué vas a hacer con tu Linux, qué vas a hacer con tu distribución. Y en base a lo que vayas a hacer, elegir aquella distro que probablemente se adapte mejor a tus necesidades, o mejor dicho, a los condicionantes que tú quieras ponerle.

Yo, la verdad, creo que actualmente da prácticamente lo mismo la distro que utilices. Creo que cualquier distribución es exactamente igual de válida que otra. Lo que de verdad importa es que conozcas la distro con la que vas a trabajar, que conozcas su sistema de paquetería y que te acostumbres a utilizarlo. Sí que es cierto que hay determinadas distribuciones que te ponen las cosas más fáciles a la hora de tener más paquetes disponibles, o que te facilitan el mantenimiento. Pero al final, prácticamente, la distro con la que trabajas es una base, y a partir de ahí tú vas construyendo lo que quieras.

Esto es un poco lo que cuento siempre que hablo de la gran ventaja de Linux frente a los otros sistemas operativos, ya sea Windows o macOS. Y es que en Linux tú te montas tu entorno de trabajo, y es tu entorno el que se adapta a ti. En Windows o en macOS es al revés: tú te tienes que acostumbrar a Windows o a macOS, a su forma de funcionar, a lo que te dejen y a lo que no. Por eso te digo que la distribución que elijas es, actualmente, casi lo que menos importa. Dicho esto, sí que quiero poner algunos puntos que creo que son importantes, sobre todo si lo que vas a hacer es programar.

Pero antes de nada quiero dejar sentada una base fundamental. A pesar de todo lo que te voy a contar, tienes que pensar siempre que con Docker cualquier cosa que quieras hacer la puedes hacer fácilmente. Hoy en día los entornos de programación que más se usan, cada vez de forma más mayoritaria, son Visual Studio Code o PyCharm en el caso de Python, y los vas a poder instalar en cualquiera de las distribuciones habituales. Ya sea Ubuntu, Debian, Linux Mint, Arch Linux, EndeavourOS, en todas ellas los vas a tener sin ningún tipo de problema. Así que muchas de las discusiones sobre distros se caen solas en el momento en que el trabajo pesado vive dentro de un contenedor.

Cinco criterios que de verdad importan si vas a programar

Si de verdad vas a programar, hay una serie de condicionantes que yo pondría sobre la mesa antes de decidir nada. Estos son los que a mí me parecen fundamentales, y en este orden, aunque tú puedes reordenarlos según tu caso.

  • Estabilidad: que el sistema no te impida ponerte a trabajar cuando tú quieres trabajar, y que una actualización no te deje tirado.
  • Mantenimiento: el tiempo que le tienes que dedicar al sistema operativo para que siga funcionando. Mi objetivo es que sea el mínimo posible.
  • Disponibilidad de herramientas: que tengas la versión de Python, de Node.js o de TypeScript que necesitas, y también las herramientas auxiliares de compilación y empaquetado.
  • Para qué vas a programar: no es lo mismo un frontal web, que vas a querer probar en local, que un desarrollo de escritorio o de sistema.
  • Tiempo de aprendizaje: el esfuerzo que te cuesta conocer tu sistema, porque no es lo mismo estar acostumbrado a Arch que aterrizar en Debian de golpe.

Vamos uno por uno, porque cada uno tiene su miga.

Estabilidad: que el sistema no te frene

Lo primero es la estabilidad. Y aquí tengo que reconocer que le tengo muchísima manía a una cosa concreta, y es cuando te vas a poner a trabajar y tu sistema operativo te lo impide, por la razón que sea. El caso paradigmático es el de Windows, que es bastante molesto en esto: quieres ponerte a trabajar y de repente te dice que tiene que instalar una actualización, y no solo que tiene que instalarla, sino que la va a instalar lo quieras o no lo quieras. Eso, en un equipo de trabajo, es insufrible.

Este asunto de la estabilidad va muy unido al del mantenimiento, en el sentido de que según cómo tengas montado el sistema te puede pasar una cosa u otra. Pero para mí lo más importante es que cuando te tengas que poner a trabajar te puedas poner a trabajar de inmediato, con independencia de lo que le apetezca hacer al sistema operativo. Y esa es una de las grandes ventajas de Linux: tú no dependes de que el sistema quiera instalar o dejar de instalar nada, tú trabajas primero y actualizas luego, cuando tú decides.

Hay otro problema clásico y es el que aparece cuando se produce una actualización. Imagina que actualizas el sistema y, en ese momento, resulta que no puedes trabajar porque alguna de las herramientas que usabas ha dejado de funcionar. Ha dejado de funcionar porque se ha instalado una actualización de esa herramienta y ya no es compatible, porque ha perdido alguna librería que necesitaba. Eso a mí me molesta muchísimo. Por eso es tan importante contar con un sistema muy estable, de manera que cuando te quieras poner a trabajar siempre puedas hacerlo. Y ojo, que aquí conviene distinguir dos cosas que se confunden mucho: la estabilidad de la base del sistema y la estabilidad del software de terceros que corre sobre ella. No es lo mismo que se rompa el gestor de paquetes que que se rompa un plugin concreto de tu editor.

Mantenimiento: el que menos, mejor

El siguiente punto es el mantenimiento, que es el tiempo que le tienes que dedicar a tu sistema operativo para que funcione. Va muy unido al anterior, como te decía. Mi objetivo, mi planteamiento, es no dedicarle prácticamente nada de tiempo al sistema. Es decir, que el mantenimiento sea lo menos intrusivo posible, que tú puedas estar trabajando sin apenas dedicarle tiempo, sin apenas dedicarle esfuerzo, sin apenas dedicarle nada. Lo pones a actualizar y ya está, y a otra cosa.

Piensa en lo que esto significa en la práctica. Cada vez que actualizas a mano, estás tomando una pequeña decisión: actualizo ahora o lo dejo para luego. Si esa decisión la tienes que tomar cada semana y cada vez consume media hora de tu vida, al cabo del año son muchas horas que no has dedicado a programar. En una distribución de ciclo continuo, el equivalente es un comando y una espera corta. En una distribución de versiones fijas, el equivalente son actualizaciones puntuales pequeñas y, cada cierto tiempo, un salto grande de versión que sí requiere atención. Las dos filosofías son válidas, pero no cuestan lo mismo en tiempo.

El mejor mantenimiento es el que no existe. Un sistema que se actualiza solo, rápido y sin pedirte permiso es un sistema que te devuelve horas para lo que de verdad importa, que es tu trabajo.

Que las herramientas que necesitas estén disponibles

Otro punto fundamental es que las herramientas que necesites estén disponibles. Esto es básico. Como te decía antes, herramientas como Visual Studio Code o PyCharm están prácticamente en cualquier distribución Linux, ahí no vas a tener problema. Pero no se trata solo de esos grandes entornos. Se trata también de que, si vas a desarrollar en Python, tengas exactamente la versión de Python que necesitas, o puedas instalarla de alguna manera limpia. Y lo mismo si trabajas con Node.js o con TypeScript. Y no hablo solo del lenguaje o del entorno principal, hablo también de las herramientas auxiliares: utilidades de compilación, herramientas para montar tu paquetería, y todo ese ecosistema que rodea a un proyecto real.

Aquí es donde entran los gestores de paquetes, que es la verdadera frontera entre distribuciones. En Debian y sus derivados tienes apt con sus ficheros .deb. En Arch Linux tienes pacman con sus ficheros .pkg.tar.zst, y además el repositorio de usuarios, el AUR, del que te hablaré luego con más detalle. En Fedora tienes dnf con los .rpm. Saber moverte con soltura en el gestor de paquetes de tu distro es, con diferencia, lo que más te ahorra tiempo cuando aparece un problema. No importa tanto cuál sea, importa que lo manejes.

Y para el desarrollo moderno hay una capa extra que conviene conocer: los gestores de versiones y entornos aislados. Para Python tienes herramientas como pyenv o uv que te permiten tener varias versiones de Python conviviendo, y entornos virtuales por proyecto para no ensuciar el sistema. Para Node.js tienes nvm. Con estas herramientas, la versión exacta que traiga tu distro deja de ser un problema serio, porque tú decides la que usa cada proyecto. Aun así, tener buenas versiones en los repositorios oficiales te ahorra trabajo.

Para qué vas a programar y dónde lo vas a probar

También tienes que tener en cuenta para qué vas a programar. Si estás programando para un frontal web, por ejemplo, tienes que pensar que vas a querer probarlo, y para probarlo necesitas un sitio donde hacerlo. Esto ya no es tanto problema desde la aparición de Docker. En el momento en que aparece Docker, levantar cualquier entorno para ver cómo funciona todo se vuelve mucho más sencillo. Antes tenías que tirar de sistemas como LAMP, que era el clásico Linux con Apache, MySQL y PHP, para montar el entorno de pruebas. Hoy en día recurrir a LAMP para eso es, francamente, absurdo. Lo mismo te digo de las variantes tipo SHAMP. Con un contenedor levantas lo que necesites en segundos y lo tiras cuando acabas.

Esto, llevado al extremo, desdibuja el peso de la distribución. Imagina que programas una aplicación web en Python con una base de datos PostgreSQL. Si tu entorno de desarrollo y tu entorno de producción son los mismos contenedores, corre con la distro que corra, el resultado es idéntico. La distro de tu máquina se convierte entonces en una cuestión de comodidad para ti, no de compatibilidad para tu proyecto. Y eso es liberador, porque te permite elegir pensando en tu propio flujo de trabajo.

El tiempo de aprendizaje y no salir de tu zona

Y por poner algún condicionante más, está el conocimiento que necesitas o el tiempo que tienes que dedicar a conocer tu sistema. No es lo mismo estar acostumbrado a trabajar directamente con Arch Linux y de repente tener que empezar con Debian, que si tú estás acostumbrado a levantar tus servidores con Ubuntu y quieres desarrollar con Arch. O si donde vas a desplegar todo sea Debian y la programación la tengas que hacer en Debian. Pero ya te digo que tampoco esto es tanto problema, en la medida en que puedes hacerlo, incluso puedes usar contenedores Docker para todo ello.

De hecho, hasta hace poco, para crear los paquetes de Ubuntu lo que hacía era directamente levantar un contenedor Docker y en ese contenedor crear el paquete. Ahora, desde que me metí en el mundo de las GitHub Actions, esto también lo he dejado de lado. Actualmente creo los paquetes para Ubuntu directamente con GitHub Actions, con lo cual ni siquiera necesito Ubuntu, ni necesito tener un servidor Ubuntu, ni una máquina Ubuntu donde hacerlo. Fíjate hasta qué punto la cosa es cada vez más independiente. El entorno donde empaquetas no tiene por qué ser el entorno donde programas, ni el entorno donde programas tiene por qué ser el entorno donde despliegas.

Como ves, los cinco criterios se entrelazan y, al final, el que más pesa suele ser el de la comodidad personal. Y aquí es donde viene la pregunta que seguro te estás haciendo: entonces, después de todo lo que te he contado, ¿tú qué recomiendas?

Por qué cambié de Ubuntu a Arch Linux

Cuando hace unos años empecé en el mundo Linux y empecé a hacer programas, siempre pensaba que lo mejor era usar Ubuntu para desarrollar para Ubuntu. Primero, porque Ubuntu tiene las versiones LTS, las de soporte a largo plazo, que te van a permitir tener un sistema estable durante muchos años. Segundo, porque uno de los condicionantes que te he puesto, la simplicidad, Ubuntu lo cumple de sobra: es realmente sencillo de manejar. Y tercero, porque era homogéneo: yo desarrollaba herramientas y aplicaciones para Ubuntu, y se iban a instalar en Ubuntu, con lo cual era lo ideal. Todo cuadraba.

Sin embargo, hoy por hoy, mi punto de vista ha cambiado totalmente. Actualmente desarrollo utilizando Arch Linux, y desarrollo para lo que sea: para máquinas Linux, para Ubuntu, para Arch Linux, para lo que haga falta. Con lo cual ese primer escollo que tenía, el de la homogeneidad, ya lo he superado. El siguiente escollo era el de las herramientas. Yo pensaba que iba a haber más herramientas disponibles para Ubuntu, dado que muchos desarrolladores desarrollan para Ubuntu, pero me equivoqué. En los repositorios AUR de Arch Linux vas a encontrar herramientas, aplicaciones y soluciones todas las que quieras, y muchas más. Estoy convencido de que no te las vas a acabar nunca.

Para quien no lo conozca, el AUR, el Arch User Repository, es un repositorio mantenido por la comunidad donde cualquiera puede publicar las recetas de compilación de un paquete. No es un repositorio oficial, y eso tiene sus matices: tú decides en qué confías, y los paquetes se construyen en tu máquina en lugar de descargarse ya compilados. Eso da una disponibilidad de software enorme, especialmente de esas herramientas pequeñas y modernas que tardan meses en llegar a otros repositorios, a cambio de un poco más de responsabilidad por tu parte. Es un intercambio que a mí me sale a cuenta.

sudo pacman -Syu
yay -S nombre-del-paquete

El siguiente escollo era el de la estabilidad, y aquí vuelvo a lo que decía antes. Yo pensé, erróneamente, que Arch Linux no iba a ser estable. Y lo que me he encontrado es que, durante estos años, he podido actualizar sin dramas. Te diría que actualmente estoy actualizando Arch Linux cada semana o cada dos semanas, y prácticamente nunca he tenido problemas para ponerme a trabajar en programación. Un detalle de transparencia, porque me gusta decir las cosas como son: sí que te tengo que hacer una observación. Con el tema de crear vídeos, sí que me he encontrado alguna vez que una versión de OBS ha dejado de funcionar o ha tenido algún problema con mi sistema. Y algo parecido me ha pasado con Neovim, alguna actualización ha dejado de ser compatible con alguno de los plugins que estaba utilizando.

Pero fíjate en el matiz, y es un matiz importante: eso no es un problema de Arch Linux, es un problema del software que estoy utilizando, sea OBS o sea Neovim. La base del sistema aguanta; lo que se rompe es la pieza de terceros que va por encima. Y eso puede pasar en cualquier distribución que vaya razonablemente al día. La diferencia está en cómo lo vives: en un sistema de ciclo continuo, ese desajuste lo ves y lo arreglas pronto; en uno de versiones fijas, puedes arrastrar una versión vieja durante años.

Lo que me enamoró de Arch no fue la novedad, fue no tener que volver a levantar mi sistema cada dos o tres años. Eso, para alguien que trabaja con el ordenador todos los días, vale más que cualquier promesa de estabilidad congelada.

Así que hoy por hoy te diría, te recomendaría, que si puedes lo hicieras en Arch Linux, por la comodidad. Esto de no tener que actualizar cada dos o tres años la versión de Ubuntu, simplemente porque ha cambiado el número, a mí me parece brutal. Esto de tener un sistema completamente estable sin tener que preocuparme de levantar nuevas versiones me parece muy cómodo. Y no es solo la comodidad: todo lo que he podido aprender en este camino hacia Arch Linux, todas las opciones, todas las posibilidades, todas las herramientas, la verdad es que ha sido realmente muy interesante. Con lo cual, si puedes, yo te recomendaría Arch Linux para programar. Toma esta recomendación como lo que es, mi opinión después de unos años, no como una verdad revelada.

El entorno de escritorio es lo de menos

Y luego está todo este embrollo de los entornos de escritorio. Que si Plasma, que si GNOME, que si usar un gestor de ventanas de mosaico. Creo que esto es totalmente secundario, y va a depender única y exclusivamente de tu gusto. Prácticamente da lo mismo que tengas un Plasma, que tengas un GNOME, que tengas un LXQt, que tengas MATE, que tengas Cinnamon: todos son igual de válidos. Es más, como ya he contado en más de una ocasión, yo ni siquiera me preocupo de eso. Hubo un tiempo en el que estaba usando gestores de ventanas de mosaico, los tiling window managers del tipo i3 o Sway, así que fíjate hasta qué punto el entorno de escritorio es independiente de lo que puedes hacer con el sistema.

Si no has probado nunca un tiling window manager, la idea es que las ventanas no flotan: se reparten por la pantalla siguiendo una rejilla y tú las colocas con el teclado, casi siempre con atajos. i3 es el clásico sobre X11, y Sway es su equivalente sobre Wayland. Es un cambio de mentalidad parecido al de pasar de un ratón a los modos de Vim: al principio cuesta, luego no quieres volver. Pero insisto, no es obligatorio. Si a ti te va bien un escritorio tradicional, ese es el tuyo. El entorno de escritorio se elige por gusto y por flujo de trabajo, no por rendimiento de programación.

Conclusiones

Hagamos balance de lo que hemos visto hoy, porque el episodio ha dado para bastante. Hemos empezado con la anécdota de la tablet que se quedó en casa, que me ha dejado sin la investigación a fondo sobre Helix que quería hacer, pero me ha servido para contarte en qué me equivoqué al probarlo. Hemos hablado del proyecto de programar en comunidad, entre retomar el bot de Telegram para gestionar contenedores Docker o lanzarnos con extensiones de GNOME Shell en TypeScript. Y, sobre todo, hemos respondido a la pregunta de qué distro Linux elegir para programar, con cinco criterios y una recomendación personal.

Me llevo cuatro conclusiones, y me las apunto para no olvidarlas. La primera, que la pregunta correcta no es qué distro elegir, sino qué vas a hacer con ella. Cualquier distribución es una base válida; lo que marca la diferencia es que conozcas su gestor de paquetes y te acostumbres a él. La segunda, que con Docker por delante, gran parte de las incompatibilidades que antes te ataban a una distribución concreta se han diluido: tú eliges la distro por comodidad, no por compatibilidad.

La tercera, que los criterios que de verdad pesan son la estabilidad, el mantenimiento, la disponibilidad de herramientas, para qué programas y el tiempo de aprendizaje que estás dispuesto a invertir. Y la cuarta, la más personal, que yo he pasado de recomendar Ubuntu a recomendar Arch Linux, no porque Arch sea la distro de moda, sino porque, en mi caso, me ha dado un sistema estable sin obligarme a levantar una versión nueva cada dos o tres años. Eso sí, con la honestidad de decirte que OBS o algún plugin de Neovim también me han dado guerra de vez en cuando, y que eso es del software de terceros, no de la base.

Si algo de esto te ha resonado, pásate por el grupo de Telegram de Atareao con Linux y cuéntame qué distro usas tú para programar y por qué. Y si te apetece apuntarte al proyecto de programar en comunidad, entra en atareao.es/contactar y dime si prefieres seguir con el bot de Docker o con las extensiones de GNOME Shell. Entre todos decidimos.

Y ya para cerrar, recuerda que esto ha sido un episodio grabado en movilidad, con el móvil y un micro pequeñito, así que si notas algo raro en el sonido, ya sabes de dónde viene. Para el próximo lunes nos escuchamos de nuevo con más Linux, y seguiremos dándole vueltas a estas cosas que tanto nos gustan. Mientras tanto, disfruta como si no hubiera mañana, si puede ser con Linux, y en este caso con tu distro Linux, mejor que mejor. Un saludo y nos escuchamos el próximo lunes. 🐧

Más información

Deja una respuesta