Hace poco me encontré con un video llamado «Imagine DevOps», una parodia basada en la famosa canción «Imagine» de The Beatles, pero llevada al mundo de DevOps: servidores, despliegues, monitoreo y esa eterna lucha entre desarrollo y operaciones. El video se presenta como una canción de DevOps, hecha “con disculpas a John Lennon”, con letra atribuida humorísticamente a “un rogue shell script” y publicada en YouTube.
Imagine DevOps
¿Por qué ver Imagine Devops?
Lo divertido del video no está solo en la parodia musical, sino también en que aborda situaciones que muchos hemos vivido en carne propia. Quienes han trabajado con servidores, despliegues o infraestructura saben que el mundo DevOps está lleno de momentos absurdos: cosas que funcionan en local pero fallan en producción, pipelines que se rompen sin explicación, permisos que nadie recuerda haber cambiado, alertas que llegan justo cuando uno está por descansar, o servicios que deciden caerse en el peor momento posible.
Por eso este tipo de humor funciona, no hace falta explicar demasiado el chiste, porque si alguna vez has tenido que revisar logs a medianoche, reiniciar un servicio sin saber muy bien por qué volvió a funcionar, o decir la clásica frase “pero en mi máquina sí corre”, entonces entiendes perfectamente de qué se trata.
También me gusta porque recuerda que DevOps no es solo sobre herramientas, sino también sobre Docker, Kubernetes o CI/CD. Al final, DevOps también es cultura, comunicación y aprender a reducir el caos entre quienes desarrollan y quienes mantienen los sistemas vivos.
Imagine DevOps es una pequeña broma interna para gente de tecnología, pero también una forma de reírnos de nuestros propios traumas técnicos. Y eso siempre es sano.
Si trabajas en desarrollo, sistemas, infraestructura, soporte, QA o simplemente has sufrido alguna vez con un despliegue, vale la pena verlo. Probablemente te saque una sonrisa y, con suerte, te recuerde que no eres el único que ha peleado contra la producción.
Finalmente, si te gusta este tipo de videos, recuerda ver mi lista de música geek donde comparto la mejor música para geeks.
Soy de los usuarios de computadoras a los que les encanta usar la terminal para todo lo que sea posible. Tal vez porque vengo de los días de MS-DOS y nunca me acostumbré del todo al mouse ni a las interfaces gráficas de usuario. De hecho, esa es una de las razones por las que amo Linux, pues todo es posible desde la consola. Por ello, hace tiempo decidí dedicarle tiempo a hacerla bonita y agradable visualmente, porque paso más tiempo allí y para ser más productivo. En este caso migré a fish, una shell rápida y con funcionalidades de zsh incluidas por defecto. Adicionalmente, agregué starship para mejorar la apariencia rápidamente utilizando diseños preexistentes.
Ejemplo de mi terminal con fish + starship
¿Por qué decidí probar fish?
Durante mucho tiempo usé zsh junto con Oh My Zsh. No tengo quejas graves, al contrario, es una buena combinación y permite tener plugins, temas, autocompletado, integración con Git y muchas mejoras sobre Bash. Sin embargo, con el tiempo también puede sentirse un poco pesada o depender de demasiadas configuraciones.
Uno de los detalles que más me gustaron de fish es que muchas de esas cosas que normalmente uno instala con plugins en zsh ya vienen listas desde el inicio. El autocompletado inteligente, las sugerencias basadas en el historial y el resaltado de sintaxis funcionan prácticamente sin esfuerzo.
Eso, para mí, tiene mucho valor. No quería pasar una tarde completa ajustando plugins, revisando compatibilidades o copiando configuraciones de otras personas. Quería una shell moderna, cómoda y rápida, pero sin convertir la configuración de la terminal en otro proyecto paralelo.
Fish se siente más amigable desde el primer uso. Cuando escribes un comando, te sugiere opciones según lo que ya has ejecutado. Si escribes mal algo, el resaltado te ayuda a darte cuenta. Si navegas entre carpetas o usas comandos repetidos, la experiencia se vuelve bastante fluida.
¿Para qué usar Starship?
Después de migrar a fish, quería que la terminal también se viera bien. Pero, siendo honesto, tampoco quería perder demasiado tiempo configurando un prompt desde cero. Ya he pasado por esa etapa de probar temas, mover símbolos, cambiar colores y revisar capturas de pantalla hasta que todo se vea bonito.
Por eso decidí usar Starship. Es un prompt moderno, rápido y compatible con varias shells, como fish, zsh y bash. La idea es sencilla: instalarlo, activarlo y tener una terminal visualmente agradable sin dedicarle demasiadas horas. Staship tiene una base de datos de configuraciones y diseños ya existentes, en la que basta con seleccionar el que más te guste y luego editar detalles menores. Así ahorras mucho tiempo.
Starship muestra información útil directamente en el prompt. Por ejemplo, la rama actual de Git, el estado del repositorio, las versiones de lenguajes como Node.js, Python, Rust o Go, la duración de los comandos y otros datos según el proyecto en el que estés trabajando. Esto es especialmente útil al trabajar con varios repositorios. Puedes estar en un proyecto frontend, luego pasar a un backend, revisar algo viejo en PHP o abrir una carpeta con scripts personales. Tener esa información visible ayuda a evitar errores menores, como ejecutar un comando en la rama equivocada o no notar el entorno en el que estás trabajando.
Ejemplo de mi terminal mostrando el historial de comandos SVN
Instalación en Arch Linux
Como uso Arch Linux, la instalación fue bastante sencilla. En mi caso lo hice directamente con pacman.
sudo pacman -S fish starship
Si todo funciona bien y queremos dejarla como shell por defecto:
chsh -s /usr/bin/fish
Después de cerrar sesión y volver a entrar, fish debería iniciarse como shell principal. Luego hay que activarlo en la configuración de fish. El archivo normalmente está en:
~/.config/fish/config.fish
Allí agregué esta línea:
starship init fish | source
Con eso ya Starship empieza a funcionar al abrir una nueva terminal.
Conclusión
Usar fish y Starship no va a convertirnos mágicamente en mejores programadores, pero sí puede hacer que la terminal sea un lugar más cómodo para trabajar. Y eso importa bastante cuando pasamos muchas horas al día escribiendo comandos, moviéndonos entre carpetas, usando Git, ejecutando pruebas o levantando servicios.
En mi caso venía de zsh con Oh My Zsh, y aunque sigue siendo una gran combinación, fish me pareció más directo. Muchas cosas que antes configuraba con plugins ahora vienen listas desde el inicio. Menos tiempo para ajustar la herramienta y más tiempo para usarla.
Starship completó la experiencia porque me permitió contar con una terminal bonita, informativa y moderna sin dedicar demasiado tiempo a personalizarla. A veces uno solo quiere que las cosas funcionen y se vean bien, sin tener que pasar horas configurando cada detalle.
La terminal sigue siendo uno de mis espacios favoritos en Linux. Personalizarla no es solo una cuestión estética, también es una forma de hacer más agradable el lugar donde trabajamos todos los días. Fish y Starship me dieron justamente eso: una terminal más cómoda, más útil y visualmente mucho mejor.
Hace unas semanas estuve activo colaborando en proyectos de software libre. No desde la teoría ni desde el “algún día contribuiré”, sino desde el código real: leyendo repositorios ajenos, revisando Pull Requests, arreglando bugs, mejorando funcionalidades y tomando decisiones técnicas. Y en todo ese proceso, hubo algo recurrente: el vibe coding, o el uso intensivo de la IA.
No como una moda, ni pensar en “dejar que la IA programe por mí”. Sino como una forma práctica de entender proyectos existentes, ahorrar tiempo y aportar valor sin perderme durante semanas leyendo código sin contexto. La herramienta que he usado para esto es Codex, pues es la única suscripción que tengo y quiero compartirles tres experiencias concretas en las que el «vibe coding» me ayudó de verdad.
Firefox: entrar a un proyecto gigantesco sin perder la cordura
Firefox es un proyecto gigantesco. De esos repositorios que abres y automáticamente piensas:
“Ok… esto no me lo voy a leer completo.”
Y es normal. Leer todo el código de Firefox no es realista ni necesario si lo que quieres es aportar en un área específica. Aquí la inteligencia artificial me ayudó principalmente a entender cómo está construido el proyecto hoy:
Cómo se organizan los módulos
Qué partes interactúan entre sí
Dónde tenía sentido meter mano sin romper medio navegador
Algo importante: la IA no es capaz de explicarte todo el código de Firefox. Pero ese nunca fue el objetivo. La clave está en delimitar el área que te interesa. Cuando haces eso, el análisis se vuelve realmente útil.
Gracias a esto pude:
Entender más rápido el contexto del código de las herramientas de desarrollo.
Reducir drásticamente el tiempo de exploración
Crear parches y mejoras con mucha más intención, sobre todo, basándose en el código existente para mantener las normativas y reglas de Mozilla.
Además, pude dedicar menos tiempo a leer archivos irrelevantes y más a aportar mejoras reales.
KIM (KDE Image Manipulator): uso de IA para revisar código y tomar mejores decisiones
En el proyecto KIM, un manipulador de imágenes para KDE, el enfoque fue distinto. Aquí no se trataba tanto de implementar nuevas funcionalidades, sino de revisar el código que otros estaban aportando.
En este contexto, el vibe coding me sirvió para:
Hacer code reviews más rápidos y profundos
Analizar si una implementación encaja con la filosofía del proyecto
Detectar posibles problemas de mantenimiento a futuro
Planificar pruebas: qué probar, cómo hacerlo y qué escenarios validar
Muchas veces el código funciona, pero eso no significa que sea una buena decisión a largo plazo. El vibe coding ayuda a pensar mejor antes de aprobar o rechazar cambios. En mi opinión, no reemplaza la experiencia, sino que la amplifica.
Plugins de WordPress: la IA como auditoría de seguridad
En mis plugins de WordPress, todo comenzó con un reporte de vulnerabilidad. Pero en lugar de limitarme a arreglar solo ese punto específico, decidí aprovechar para hacer algo mejor: revisar todo el código.
Aquí las I.A. fue clave para:
Analizar flujos de entrada y salida de datos
Identificar patrones inseguros
Encontrar problemas que no habían sido reportados
Mejorar la seguridad del plugin de forma global
Muchas vulnerabilidades no son un bug aislado, sino hábitos que se repiten en el código. Detectarlos manualmente puede tomar mucho tiempo. Con el vibe coding, ese análisis se acelera bastante.
Conclusión: usar IA no es hacer trampa, es pensar mejor
El software libre se construye colaborando. Pero colaborar no debería significar perder semanas entendiendo un proyecto antes de poder aportar algo útil.
El vibe coding, bien usado:
Ahorra tiempo
Acelera la comprensión de proyectos complejos
Mejora la calidad de los aportes
Ayuda a tomar mejores decisiones técnicas
No sustituye el criterio ni la experiencia. Lospotencia.
Si estás contribuyendo —o quieres empezar— a proyectos de software libre, mi recomendación es simple: utiliza las herramientas que tengas a tu alcance, entiende bien el código antes de tocarlo y aporta con intención.
Al final, no se trata de escribir más líneas de código, sino de entender mejor las que ya existen.
Siempre me ha parecido fascinante cómo la cultura geek encuentra formas creativas de celebrar el software libre y el mundo del desarrollo. Esta vez les comparto algo que va en esa línea: el video “Free Software – SUSE Music Parody of Free Fallin’”, una parodia musical geek de SUSE de Free Fallin’ pero con ritmo y letras ingeniosas a todo eso que nos apasiona del software libre.
¿De qué trata este video?
Si alguna vez te has preguntado cómo sonarían tus temas favoritos con letras sacadas directamente del mundo del software libre, este video es justo eso: una parodia que toma la melodía conocida de Free Fallin’ y la convierte en una oda al software libre, sus conceptos, nombres y términos que todo hacker, sysadmin o entusiasta de GNU/Linux reconoce inmediatamente.
La parodia no solo sirve como entretenimiento, sino también como una forma ligera y musical de repasar conceptos del software libre: desde nombres de proyectos y distros hasta términos que, aunque suenan técnicos, forman parte de nuestras conversaciones diarias en la comunidad.
Free Software - SUSE Music Parody of Free Fallin'
Por qué importa esta parodia musical geek de SUSE
Más allá de la simple diversión, ver a empresas y comunidades como SUSE producir contenido así tiene valor: es un tributo creativo a los valores del software libre —la colaboración, la cultura hacker y la idea de que el código abierto no es solo una licencia, sino una forma de vida digital compartida.
Nos recuerda que, a pesar de lo técnico que puede ser este mundo, también hay espacio para el humor, la cultura y la música geek. Y si tú, como yo, has pasado horas instalando distros, ajustando configuraciones o explicando qué significa GNU, esta parodia te va a sacar una sonrisa.
Palabras finales
Dale play al video, disfruta de la letra (seguro que reconocerás más de una frase) y celebra el espíritu del software libre en todas sus formas, incluso las más musicales.