Navegar por el Fediverso es una experiencia que depende en gran medida del cliente que utilices. En mi caso, como usuario de Android, he pasado por varias aplicaciones buscando la que mejor se adapte a mi flujo de trabajo y me ofrezca una experiencia de usuario cómoda y estable. Este ha sido mi viaje a través de tres de los clientes más populares: **Tusky** , **Megalodon** y **Moshidon**. ## **Tusky** : El popular punto de partida Mi primera incursión fue con Tusky, probablemente el cliente de Mastodon más conocido en Android. Es una aplicación robusta y una excelente puerta de entrada al Fediverso. Sin embargo, pronto empecé a encontrar algunas fricciones en mi uso diario. El principal problema para mí fue la gestión de las etiquetas (hashtags). Encontré poco intuitivo el proceso para seguir temas de mi interés, una función crucial para mantenerme al día en nichos específicos. Además, la experiencia de lectura para ponerme al día con mi _timeline_ me resultaba incómoda; sentía que perdía el hilo con facilidad al intentar explorar conversaciones o publicaciones extensas. ## **Megalodon** : Más funciones, nuevos problemas Buscando solucionar los inconvenientes de **Tusky** , migré a Megalodon. El cambio fue inmediatamente positivo en varios aspectos. La capacidad de seguir etiquetas estaba implementada de una manera mucho más directa y, sobre todo, la manera de explorar el timeline compactado era fantástica, permitiendo expandir el bloque de publicaciones de varias horas hacia arriba o abajo para ponerse al día rápidamente. Parecía que había encontrado mi cliente ideal, pero la estabilidad no estuvo de mi lado. Empecé a sufrir problemas recurrentes de sincronización, donde el _timeline_ no se actualizaba correctamente o las notificaciones llegaban con retraso. A esto se sumaban fallos esporádicos que mostraban errores poco descriptivos sobre propiedades requeridas, obligándome a cerrar y volver a abrir la aplicación para que todo volviera a la normalidad. Esta aplicación fue descontinuada el 30 de mayo de 2025. ## **Moshidon** : La solución (por ahora) definitiva Cuando la inestabilidad de **Megalodon** se volvió demasiado frecuente, descubrí Moshidon. Al ser un _fork_ del propio **Megalodon** , mantenía todas las características que me habían encantado: la excelente interfaz de lectura y la fácil gestión de etiquetas. La gran diferencia es que **Moshidon** ha resuelto los problemas de estabilidad que plagaban mi experiencia anterior. La sincronización es fiable, los _timelines_ se actualizan como es debido y no he vuelto a encontrarme con los errores aleatorios que antes interrumpían mi uso. La aplicación simplemente funciona, combinando lo mejor de la interfaz de **Megalodon** con la estabilidad que necesitaba. ## Conclusión Mi recorrido por los clientes de Mastodon en Android ha sido un proceso de iteración. **Tusky** fue un buen comienzo, **Megalodon** me mostró las funciones que quería pero a costa de la fiabilidad, y **Moshidon** ha resultado ser, para mí, la síntesis perfecta de ambos. Si buscas un cliente de Mastodon para Android que sea estable, rico en funciones y con una experiencia de lectura superior, mi recomendación actual es, sin duda, **Moshidon**.

Ahora que uso Manjaro en lugar de Ubuntu, uno de los problemas que encontré para adecuar el entorno de desarrollo que uso en mi trabajo, es que el conector de MySQL para Python _MySQLDb_ depende de `libmysqlclient-dev`, que no está disponible en Manjaro. Te cuento cómo solucioné el problema. ## Conector MySQL El conector de bases de datos ofrece una interfaz para interactuar con bases de datos desde una aplicación. Los fabricantes de bases de datos ofrecen sus propios conectores para distintos lenguajes de programación, controladores nativos que permiten a la comunidad interactuar con las bases de datos creando nuevas extensiones o incluso la definición del estándar de tal modo que existan implementaciones en diferentes lenguajes y que no posean dependencias con el sistema operativo. En el caso del conector MySQL para Python, el conector oficial depende de `libmysqlclient-dev` (con el paquete python de `mysqlclient`), que no está disponible en Manjaro. ## Alternativas de conexión Python con MySQL en Manjaro Podemos tener dos alternativas para conectarnos a MySQL desde Python en Manjaro, considerando una conexión nativa, pero también una conexión sin dependencias con el sistema operativo. ### Conector de MariaDB MariaDB es una base de datos relacional de código abierto que se basa en el código fuente de MySQL. Es compatible con la mayoría de las características de MySQL y ofrece mejoras en seguridad, rendimiento y escalabilidad. Esta compatibilidad ofrece una alternativa a la conexión nativa de MySQL con la que podremos instalar `mysqlclient` con nuestro gestor de paquetes Python de forma habitual. Para instalar las dependencias nativas, en Manjaro y derivados de Arch, procedemos de la siguiente manera: pamac install mariadb-libs Ahora podremos instalar el paquete Python `mysqlclient` con nuestro gestor de paquetes Python de forma habitual (paquete en el ambiente o en el proyecto): uv pip install mysqlclient # Instalación en el ambiente uv add mysqlclient # Instalación en el proyecto ### Conector MySQL en Python Puro Existe también un conector MySQL en Python puro que cumple también el estándar de conexiones a base de datos definidas por el PEP 249, tal como el conector nativo. Esta opción es _PyMySQL_ , y es una excelente alternativa si no puedes instalar las dependencias nativas de MySQL o MariaDB, o simplemente prefieres no instalarlas. Para hacer la instalación de PyMySQL, simplemente ejecutamos el siguiente comando: uv pip install PyMySQL # Instalación en el ambiente uv add PyMySQL # Instalación en el proyecto Ahora puedes usar en tus proyectos `pymysql` de forma directa, o usarlo como un sustituto de `MySQLdb` cuando la dependencia nativa no está disponible, lo cual se hace de la siguiente manera: try: import MySQLdb except ImportError: import pymysql # Reemplaza `MySQLdb` por `pymysql` pymysql.install_as_MySQLdb() ### Otras alternativas Para configurar el entorno de desarrollo podrías tener otras opciones, y comentaré ligeramente dos más. A través de AUR, puedes instalar las dependencias nativas de MySQL, pero considero que al tener opciones que no contaminan el sistema, podemos omitir. La otra alternativa es que un entorno de desarrollo adecuado sería adecuar un contenedor local basado en Ubuntu, de tal forma de replicar adecuadamente el entorno de producción. Esto sin duda les comentaré un poco más sobre Docker más adelante, pero de momento prefiero la comodidad de tener el entorno directamente en Manjaro sin el contenedor (la integración de la IDE que uso, Zed, no me parece todavía tan buena). ## Referencias * Python mariadb connector. Manjaro Linux Forum. * PyMySQL. Documentation. * install_as_mysqldb. GitHub PyMySQL.

He usado Manjaro desde hace 7 meses, y me ha apasionado. Me gusta disponer de las novedades rápido, sin el sacrificio de la estabilidad (cosa que me sucedía en los intentos que tuve en Arch Linux), su gestor de _hardware_ y de _núcleos Linux_ me parecen muy buenas utilidades. Además, **pamac** es una herramienta muy útil para gestionar paquetes en Manjaro, mucho más amigable que **pacman** de Arch Linux, y con cierta similitud con **apt** de Debian/Ubuntu. La documentación propia de Manjaro, sumada a la excelente documentación de Arch Linux, hacen que sea una distribución muy fácil de usar, y me atreveré a decir, que esta facilidad es extendida para novatos. Te contaré mis pensamientos sobre Manjaro para novatos. Bueno, me atrevo a decir que esta distribución tiene la estabilidad suficiente para permitir el ingreso de usuarios nuevos al mundo Linux sin mayores problemas. Recuerdo mis primeras experiencias en Linux, y no veo nada distinto. Un par de problemas al inicio asociados al wifi, al controlador gráfico ( NVIDIA), el teclado externo y aprender la gestión de paquetes y leer cada que algo se dañaba (uno nuevo reinstala varias veces). Lo primero que uno quiere al moverse a Linux es tener una transición simple a muchas aplicaciones que normalmente se tienen en Windows. Esto se logra con el amplio repositorio oficial de Manjaro, se complementa bastante bien con Flatpak y si se usa con moderación (y seleccionando aquellos con votos y las versiones preferiblemente terminadas en -bin, si son la versión reciente), los paquetes disponibles en el AUR (los problemas, nada diferente a usar PPA en Ubuntu y lo que conlleva). Esta oferta extendida con Flatpak y AUR nos deja con opciones de muchos paquetes comunes, oficiales o no oficiales de versiones Windows, versiones recientes de alternativas que ofrecen excelente compatibilidad o que sin ser compatibles son una buena opción para cambiar el flujo de trabajo y usarlas. Pero también el mundo de los videojuegos tiene en su ojo a la distribución Arch Linux, en la cual se basa Steam Deck y por ende un potencial de beneficios en derivados de Arch. Si escoges un buen entorno de escritorio DE (esto es independiente de la distribución Linux, sea desde Ubuntu hasta Manjaro), tendrás una ganancia en la experiencia y este entorno recomendado si tienes buena RAM, es KDE. Y KDE tiene en buena apreciación a Arch Linux, al punto que su proyecto de distro propia se basa en este (proyecto Banana). Esto también implica que las soluciones de KDE estarán muy probadas para Arch y derivados. Que Manjaro disponga de su propio repositorio independiente de Arch Linux permite tener la estrategia de pruebas de los paquetes y pensar en su estabilidad antes de llegar a nosotros los usuarios finales. Y debo decir que esto salvo por pequeños detalles que su propio foro advierte como corregir pasa sin mayor novedad (mi transición inicial en Linux era a veces uno no saber ni donde buscar como solucionar un daño). Esto si sabes seguir instrucciones lo puedes hacer siendo novato en Linux. Esta separación implica que las novedades se pueden dilatar típicamente entre 2 y 4 semanas, pero no tendrás que sacrificar estabilidad y tiempo en arreglar tantos problemas como sucedería en Arch Linux (al ser _mainstream_ en lugar de _rolling release_). El repositorio de Manjaro se separa en ramas inestables, de pruebas y estable. Si eres más arriesgado, puedes usar las ramas inestables y de pruebas, y a su vez contribuir para que Manjaro sea aún mejor. Si decides usar Manjaro y siendo novato, con mayor razón la gestión de paquetes recomendada es con **pamac** en lugar de **pacman**. Es más amigable en los comandos y podrás recordarlos más fácil, y con ayuda de KDE Discover incluso podrás gestionar la instalación de paquetes Flatpak de manera gráfica. El foro y recursos en general de Manjaro son muy buenos, muchos aptos para cualquier nivel de usuario. Y sin duda, podrás encontrar también colaboración en la red para apoyarte en como seguir este camino a la hora de migrar de Windows a Linux, no solo a esta distribución sino a otras, en tu aventura de distrohopping Y quedo atento a apoyar este camino. ## Recomendaciones Ya he publicado en otras ocasiones temas relacionados con Manjaro, así que te recomiendo dar un vistazo: * Distrohopping: Cambiar de distribución Linux y no morir en el intento * ¿Qué hacer después de instalar Manjaro KDE? * Problemas de conexión wifi en Linux * Problema de Wayland y gráficos híbridos en Linux * Montar disco en Linux y error de volumen sucio * Ecosistema Rust para la terminal Linux * Configurar Starship en Manjaro y Zsh * Instalar Docker en Manjaro

Además de mi interés personal por este lenguaje, también me interesa el ecosistema de herramientas que se han desarrollado en Rust para la terminal Linux y para el soporte de otros lenguajes de programación (como su impacto en Python, que es mi lenguaje principal de desarrollo). Antes les comenté sobre Starship, y a continuación vamos a expandir este universo de posibilidades de Rust para la terminal Linux. ## Acelera tu trabajo en la terminal Si bien _Zsh_ no está implementado en Rust, este lenguaje de terminal (_shell_) es muy potente y flexible, con una gran cantidad de plugins y complementos disponibles para personalizar y mejorar su experiencia. Por lo que aprovecho como parte de mi nueva terminal Linux recargada a incluirlo y contarles sobre como cambiar a que sea usado por defecto. Adicional, esto es necesario mencionarlo ya que la configuración va a requerir de conocer nuestra _shell_ , y esto define porque las instrucciones que vamos a conocer. Todavía lo sigo usando como un _bash_ en general, pero ya he visto cosas muy interesantes que pronto les compartiré. Así como vimos la experiencia extra de información que nos ofrece Starship, vamos a explorar utilidades que nos ayudan a mejorar nuestra experiencia en la terminal con mayor agilidad en nuestros flujos de trabajo. Empezaremos con _zoxide_ , un reemplazo para `cd` que nos permite navegar por nuestra historia de directorios de forma más rápida y eficiente. Posee autocompletado y asignación de prioridad para los atajos a los directorios. Podemos usarlo indicando una forma corta del directorio o similar, y mediante búsqueda difusa en los directorios que ya hemos navegado (usando _zoxide_ como un `cd` habitual) puede adivinar el directorio que buscamos, o si sabemos que pueden existir varios directorios con el mismo nombre, puede mostrar una lista de opciones para elegir al digitar espacio y tabulador. Podemos también acelerar nuestra experiencia con un emulador de terminal en Rust como _Alacritty_ , que ofrece una interfaz más rápida y eficiente que la terminal predeterminada de Linux, y su renderizado es con OpenGL. Este emulador está disponible también en MacOS y Windows, y dispone de modo _Vi_ para la navegación, así como opciones de selección extendida y apertura de enlaces con el _mouse_. _Alacritty_ no posee un multiplexador, pero podemos darle esta capacidad a través de _Zellij_ , un multiplexador de terminales (esto nos permite tener múltiples ventanas y paneles dentro de una sola terminal). Podemos tener paneles flotantes, capas personalizadas y una serie de atajos para hacer adecuada navegación. Se dispone de un modo de bloqueo para evitar la confusión con atajos de sistema, y este se usa con `Ctrl`+`g`, y allí los atajos `p` para gestión de paneles o `t` para la gestión de pestañas, y con opciones para crear (`n`), cerrar (`x`), navegar (direccionales), entre otros. Podemos generar los paneles flotantes con `Alt`+`f` (los cuales se pueden desplazar luego con el _mouse_) o los paneles normales con `Alt`+`n`. Para navegar en este modo, podemos usar `Alt` con direccionales. Y finalmente, un editor para la terminal con soporte de modo _Vi_ , bastante cómodo de usar y con soporte nativo de _tree sitter_ y _LSP_. Este editor es _Helix_. Y se ha convertido en mi editor de terminal favorito y lo he vinculado como el editor para edición de git. Ahora, manos a la obra para instalar y configurar. Manjaro En Manjaro (y derivadas de Arch) disponemos de los paquetes necesarios en el repositorio oficial. sudo pamac install zsh alacritty zellij zoxide helix --no-confirm Ubuntu En el caso de Ubuntu, vamos a necesitar usar no solo paquetes del repositorio oficial, sino también paquetes instalados con **cargo** o **flatpak**. sudo apt install -y zsh alacritty zoxide cargo install --locked zellij flatpak install flathub com.helix_editor.Helix Para configurar **zsh** como tu _shell_ por defecto procedemos de la siguiente manera: chsh -s /bin/zsh # Configurar shell por defecto: ingresamos contraseña Puede que sea necesario reiniciar tu sesión para que el cambio surta efecto. A continuación, ya podremos configurar las demás utilidades que dependen del _shell_ para saber las opciones de configuración. _Zoxide_ requiere ejecutar su _script_ de inicialización indicando el _shell_ que se está usando. Según el método de instalación, podrías necesitar revisar el ejecutable asociado, en mi caso queda con `z` y me siento cómodo con él. echo 'eval "$(zoxide init zsh)"' >> ~/.zshrc source ~/.zshrc En el caso de _Alacritty_ , debemos indicar el _shell_ que se está usando en el archivo de configuración (formato TOML) y de paso vincularemos el uso de _Zellij_ en su arranque. cat << 'EOF' > ~/.config/alacritty.toml [terminal.shell] args = ["-l", "-c", "zellij attach --index 0 || zellij"] program = "/bin/zsh" EOF Respecto al uso de _Zellij_ te recomiendo el modo _unlock first_ para evitar colisión de atajos que tengamos en el sistema (es una mala experiencia). Recuerda también configurar starship para que tengas el combo completo. ### Asociar Alacritty como terminal por defecto en KDE. En este punto ya tenemos lo básico listo, y si lanzas de forma directa **alacritty** no hace falta nada más. Sin embargo, si usas atajos de terminal o hay aplicaciones que lancen la terminar que esté asociada por defecto, seguirán lanzando la terminal (emulador) que tenías antes. Para que esto no suceda, deberás hacer unos pasos adicionales que dependen de tu entorno de escritorio. En mi caso, que uso KDE los pasos son los siguientes. Para vincular _alacritty_ como emulador de terminal por defecto: Aplicaciones predeterminadas ‣ Emulador de terminal ‣ Alacritty Para configurar el atajo de teclado teclado: Atajos de teclado ‣ Añadir nuevo ‣ Aplicación ‣ Alacritty Configuramos atajo de “Lanzar” dando clic a Añadir, y tras ello el atajo deseado. En mi caso prefiero el habitual de la terminal de `Control`-`Alt`-`T`. Aplicamos el cambio (Aplicar). ## Nuevo ecosistema de utilidades Tenemos aquí un reemplazo para nuestros comandos favoritos de la consola, que aprovechamos a modernizar con Rust y en algunos casos a tener una mejora importante de rendimiento (en su reimplementación) o de agilidad con las nuevas opciones que nos ofrecen.## Nuevo ecosistema de utilidades * `bat`: Sustituto de `cat`. Destaco su coloreado de sintaxis, marcas de cambios de git y la opción para mostrar caracteres invisibles. * `bottom` (`btm`): Sustituto de `top`. Posee soporte multiplataforma y la gestión de procesos te permite matarlos allí (seleccionas el proceso y luego `d` `d`) * `eza`: Sustituto de `ls`. No he explorado mucho su potencial, pero su coloreado por defecto me es mucho más útil que el usado en el original. Permite conocer información adicional de los archivos y directorios durante la consulta, como su estado de git o información de puntos de montaje. * `procs`: Sustituto de `ps`. Multiplataforma, y con mayor legibilidad que el original. * `du-dust` (`dust`): Sustituto de `du`. Su visualización por defecto me parece mucho más informativa que el comando original. Ahora, procedamos a instalar. Manjaro En Manjaro (y derivados de Arch), disponemos nuevamente todo disponible en el repositorio oficial. sudo pamac install bat bottom dust eza procs --no-confirm Ubuntu En Ubuntu, necesitaremos mezclar el repositorio oficial con el repositorio de Rust. sudo apt install -y bat du-dust eza cargo install --locked bottom procs ## Referencias Ahora que hemos _oxidado_ nuestra terminal Linux, te invito a visitar la información oficial de estos proyectos. * Alacritty * Zellij * Zoxide * zsh * Oh my zsh * Helix * Dust * Eza * procs * Bat * Bottom Puedes conocer más utilidades en Rust para tu consola aquí.

En el pasado publiqué un artículo de como instalar y usar Docker en Ubuntu con Snap y ahora que uso Manjaro vale la pena revisar los pasos para instalar Docker en Manjaro. Por motivos laborales ahora más que nunca es importante para mí el uso de Docker, porque en Tributi nuestro sistema operativo oficial en el área de tecnología es Ubuntu (ahora en versión 24.04). Como en mi equipo tengo Manjaro, mi ambiente local ya no me sirve para las pruebas y necesito una forma de asegurar el mismo ambiente. Para ello, Docker se vuelve en la alternativa adecuada de reproducibilidad. ## Docker en repositorio En Manjaro (y Arch) se puede instalar Docker desde el repositorio de paquetes oficiales. Debemos tener presente que la componente de composición de contenedores se encuentra en el paquete `docker-compose`. pamac install docker docker-compose --no-confirm ## Configuración de Docker Con el fin de disponer Docker para ser invocado, podemos habilitar el servicio del demonio o del _socket_. La primera opción es adecuada para entornos de servidores y la segunda para entornos locales para reducir el consumo de recursos (este queda activo con el primer llamado, a diferencia de la primera opción que queda activo desde el arranque del sistema). Para habilitar el servicio del demonio, ejecutamos: sudo systemctl enable docker.service Para habilitar el servicio del _socket_ , ejecutamos: sudo systemctl enable docker.socket De momento esto nos permite inicializar Docker, pero debemos ejecutarlo siempre con permisos de administrador. Si deseamos ejecutarlo sin permisos de administrador, podemos agregar nuestro usuario al grupo `docker`: sudo usermod -aG docker $USER ## Referencias * Docker. Wiki ArchLinux. * docker.service tops the systemd-analyze critical path. Repositorio Moby.

Hace casi dos años me propuse aprender Rust, pero no tuve tiempo o realmente tenía poca disciplina para seguir adelante. Ahora, estoy en firme con el propósito para este 2025 y aquí estoy tomando notas, haciendo algunos ejercicios e iniciando un proyecto. Respecto a estas notas, deben considerarse como notas personales, y bueno cubro detalles de lo básico para iniciar con un proyecto con _cargo_ , imprimir en consola, asignar variables, tener claros los tipos de variables y hacer flujos de control (todavía sin manejo de errores). El punto de partida para esta publicación es que ya se ha instalado Rust en Linux. ## Uso de `cargo` `cargo new proyecto` para crear proyecto nuevo con su directorio. Si el directorio existe, usamos `cargo init` en el directorio para su inicialización. La inicialización incluye un directorio `src` con un archivo `main.rs` con ejemplo, un archivo de exclusión de git `.gitignore` (el sistema de versionamiento se puede configurar con la opción `--vcs`) y el archivo de proyecto `Cargo.toml`. El nombre del proyecto puede ser diferente al directorio, y se puede pasar en la opción `--name`. Por defecto se usa la opción `--bin` para la creación de un binario, pero puede ser `--lib` para generar una biblioteca. Por defecto, es la edición 2021, pero se puede configurar con `--edition` (ejemplo, usar la nueva edición, `2024`). Estas opciones son tanto en la creación con `new` como en la inicialización con `init`. El archivo de proyecto es necesario para la compilación (`cargo build`) o ejecución (`cargo run`). Puedes usar proyectos con múltiples binarios si en el directorio `src` añadimos otros archivos fuentes. Estos, **cargo** los puede inferir y crear los binarios, y si deseamos ejecutarlos bastará con usar `cargo run` seguido de `--bin` y el nombre (por defecto es el nombre del archivo sin extensión). Sobre la organización general de archivos, puedes consultar en Package Layout de _The Cargo Book_ , y la configuración si no deseamos los nombres por defecto de los binarios en Cargo Targets. Se puede compilar directamente el código fuente sin `cargo` usando `rustc` seguido de la ruta del código fuente. Consejo Una instrucción interesante es `cargo check`, la cual te permitirá verificar si el código es compilable sin necesidad de generar el ejecutable. Esto es mucho más rápido y en ocasiones no necesitamos hacer la prueba de ejecución, sino solo saber si puede generar errores de compilación. ## Hola mundo en Rust Los códigos ejecutables de Rust siempre requieren una función `main`. Las funciones se especifican con `fn` seguido del nombre, los paréntesis para argumentos, llave para el cuerpo de la función. Las líneas sentencias requieren la terminación de `;` fn main(){ // Esto es un comentario de una línea println!("Hola, Edward! 🧠"); } `println` es una macro (por eso termina en `!`) para imprimir, y esto nos ayuda con el manejo de la existencia de múltiples argumentos. Hay varias formas de imprimir y formatear: * `format!`: Formatea una cadena de texto (su salida es `String`). * `print!`: Imprime en la consola (salida estándar) sin salto de línea (`io::stdout`). * `println!`: Imprime en la consola con salto de línea. * Las versiones `eprint!` y `eprintln!` equivalentes a su versión sin `e` inicial solo que imprimen en la salida estándar de errores (`io::stderr`). Si deseamos agregar comentarios, esto se hace con `//` por cada línea. ## Asignación de variables y constantes Para asignar variables usamos `let` seguido del nombre de la variable, `:` el tipo de dato (aunque este puede ser inferido y no anotarse siempre), `=` y el valor de la variable (y por supuesto, el terminador de línea). En Rust, las variables por defecto son inmutable, lo cual implica que una vez se asigna el valor, este no puede ser modificado. Si queremos que el valor sea modificable, debemos agregar `mut` antes del nombre de la variable. También podemos asignar constantes con la palabra clave `const`, y estas siempre son inmutables y siempre deben anotar el tipo. Su estructura es `const` seguido del nombre de la constante en mayúscula sostenida (puede contener guion bajo), `:`, el tipo de dato, el valor y el terminador de línea. Las constantes pueden ser asignadas con expresiones que se calculan en tiempo de compilación (esto nos ayuda a la legibilidad y verificación de un valor, en lugar de poner su valor directo), y a diferencia de las variables pueden ser de contexto global, útil para valores que son requeridos en múltiples partes de nuestro código. const ANSWER: i32 = 42; fn main() { let x: i32 = 26; let mut y: f32 = 5.6; y = 8.; let suma = x + ANSWER; let bandera = true; println!("Mi primera variable 'x': {x}"); println!("Mi primera variable mutable 'y': {y}"); println!("Sumando {suma}") } Los tipos de datos que existen son los enteros sin signo y con signo (`u` y `i`, seguido de `8`, `16`, `32`, `64` y `128` acorde al tamaño en bits), los flotantes (`f32` y `f64`), los booleanos (`bool`, usan 1 _byte_) y los caracteres (`char`, usan 4 _bytes_). También es posible disponer de variables de tipo opcional, es decir, que admiten el valor `None`. Esto se logra usando `Option<type>`, donde `type` es el tipo de variable deseada. Si se desea asignar el valor `None` se hace directamente, pero para un valor diferente es necesario hacerlo con `Some`. fn main(){ let x : Option<i8> = None; ley y : Option<i8> = Some(5); } Rust no soporta la conversión implícita entre tipos de datos, y la conversión explícita se hace usando funciones como `as`. Para los datos personalizados o compuestos, se puede usar la función `into()` o `from()`, que tendrá que definirse en _traits_ (`Into` y ` From`). Otros _traits_ para este fin son `TryFrom` y `TryInto`, pero pueden existir casos muy específicos por tipos, como lo son `FromStr` y `ToString`. Existen también tipos de datos compuestos: * Tuplas: Es una agrupación de valores de diferentes tipos en un tipo compuesto que se concibe como uno. Para obtener sus valores, se puede usar la notación `x.N` donde `N` es el índice del elemento en la tupla, comenzando desde 0. También se puede desestructurar una tupla usando la sintaxis `let (a, b, c) = tupla;`. Una vez asignada, las tuplas no pueden cambiar su tamaño ni tipo de datos. Se asignan valores a las tuplas usando la sintaxis `let tupla = (1, 2.0, 'a');` o indicando de forma explícita el tipo de cada elemento `let tupla: (i32, f64, char) = (1, 2.0, 'a');`. * Arreglos: Es una colección de elementos del mismo tipo y de tamaño fijo. Se asignan valores a los arreglos usando la sintaxis `let arreglo = [1, 2, 3];` o indicando de forma explícita el tipo de cada elemento `let arreglo: [i32; 3] = [1, 2, 3];`. También se puede crear un arreglo con valores repetidos usando la sintaxis `let arreglo = [0; 5];` que crea un arreglo de 5 elementos todos iguales a 0. Los elementos de un arreglo se pueden acceder usando la notación `arreglo[i]` donde `i` es el índice del elemento en el arreglo, comenzando desde 0. Se soporta la iteración sobre el arreglo mediante la notación valor inicial seguido de `..` (con `..=` indica que el valor final está incluido) y el valor final. Y con `step_by` para iterar con un paso específico (similar a `range` en Python). * Vectores: Son colecciones de elementos del mismo tipo y de tamaño variable (un comparativo con las listas de Python). Se asignan valores a los vectores usando la sintaxis `let vector = vec![1, 2, 3];` que es una macro, o `let vector = Vec::new();` (o indicando explícitamente el tipo de cada elemento `let vector: Vec<i32> = Vec::new();`) que es una función y asignando los valores usando la sintaxis `vector.push(4);`. Se puede acceder a los elementos de un vector usando la notación `vector[i]` donde `i` es el índice del elemento en el vector, comenzando desde 0. * _Hash map_ : Es una colección de pares clave-valor donde las claves son únicas y los valores pueden ser de cualquier tipo (equivalente de diccionarios de Python). Se asignan valores a los _hash maps_ usando la sintaxis `let hash_map = HashMap::new();` que es una función y asignando los valores usando la sintaxis `hash_map.insert("clave", valor);`. Se puede acceder a los valores de un hash map usando la notación `hash_map["clave"]` donde `clave` es la clave del valor que se quiere obtener. Es necesario importar el módulo `std::collections::HashMap` para usar _hash maps_. Se dispone de una alternativa _pythonica_ usando el _crate_ de `maplit` con la macro `hashmap!`. #[macro_use] extern crate maplit; fn main(){ let map = hashmap!{ "daffy" => 80, "bugs" => 79, "taz" => 63, }; } * _Hash set_ : Es una colección de elementos únicos sin orden específico (equivalente de conjuntos de Python). Se asignan valores a los _hash sets_ usando la sintaxis `let hash_set = HashSet::new();` que es una función y asignando los valores usando la sintaxis `hash_set.insert(elemento);`. Es necesario importar el módulo `std::collections::HashSet` para usar _hash sets_. Se dispone de una alternativa _pythonica_ usando el _crate_ de `maplit` con la macro `hashset!`. #[macro_use] extern crate maplit; fn main(){ let set = hashset!{ "daffy", "bugs", "taz", }; } * Estructuras: Son colecciones de campos que pueden ser de diferentes tipos. Se definen usando la sintaxis `struct Nombre { campo1: Tipo, campo2: Tipo, ... }`. El acceso a los campos se realiza usando la sintaxis `estructura.campo`. * Estructuras de tupla: Cuando el nombre de los campos no es relevante, se pueden usar estructuras de tupla. Se definen usando la sintaxis `struct Nombre(Tipo1, Tipo2, ...)`. El acceso a los campos se realiza usando la sintaxis `estructura.0`, `estructura.1`, etc. Si es un solo campo, suele conocerse como `newtype` y se puede usar para reducir la exposición del dato original y eliminar la confusión del intercambio de tipos que puede ocurrir con el alias de `type`. Sin embargo, esto implica hacer definiciones adicionales para el manejo de los datos (ejemplo, definir el _trait_ de _Display_ , ya que el acceso del tipo no es reutilizable). También se pueden usar casos sin argumentos (y omitir el paréntesis) de este tipo de estructuras para casos que no requieren datos en sí, y tener retornos nulos, y a esto se le conoce como _ZST_ (_Zero Sized Type_). * Enumeraciones: Rust también tiene soporte para enumeraciones, que son tipos de datos compuestos que pueden tener varios valores posibles. Se definen usando la sintaxis `enum Nombre { Tipo1, Tipo2, ... }`. El acceso a los tipos tiene la forma `Nombre::Tipo1`. Los tipos pueden ser no solo simples nombres, sino formas válidas de estructuras y estructuras de tupla. ## Funciones en Rust Cómo se mencionó anteriormente, en el ejemplo del “Hola mundo”, las funciones se definen iniciando por `fn`. En este caso, a diferencia del `main`, si una función posee parámetros y retornos, se definen como sigue. fn suma(a: i32, b: i32) -> i32 { return a + b; } Es importante que en Rust, las funciones deben tener un tipo de retorno definido explícitamente. Sin embargo, el `return` es opcional, y puede ser útil para el retorno temprano, y se asume que el último valor de la función es el valor de retorno. Aquí vemos cómo hacer la suma, y podemos disponer de otros operadores que puedes consultar en el apéndice de la documentación oficial de Rust, Appendix B: Operators and Symbols. ## Flujos de control ### Condicionales `if else` es una estructura de control que permite ejecutar diferentes bloques de código dependiendo de si una condición es verdadera o falsa. En Rust, se utiliza la palabra clave `if` seguida de una expresión booleana y luego un bloque de código que se ejecutará si la condición es verdadera. Si se desea ejecutar un bloque de código alternativo si la condición es falsa, se utiliza la palabra clave `else` seguida de otro bloque de código. fn main() { let x = 5; if x < 10 { println!("x es menor que 10"); } else { println!("x es mayor o igual que 10"); } } Si es un condicional encadenado, se pueden utilizar múltiples `if` seguidos de `else if` para evaluar múltiples condiciones. fn main() { let x = 5; if x < 10 { println!("x es menor que 10"); } else if x == 10 { println!("x es igual a 10"); } else { println!("x es mayor que 10"); } } También disponemos de la estructura de control `match`, que permite comparar un valor con una serie de patrones y ejecutar diferentes bloques de código según el patrón coincidente. Es importante considerar que `match` debe ser exhaustivo en la generación de casos. fn main() { let x = 5; match x { 1 => println!("x es igual a 1"), 2 => println!("x es igual a 2"), _ => println!("x es diferente de 1 y 2"), } } Existen casos en los cuales la lógica con `match` puede ser muy verbosa, y se puede condensar en `if let` o `let else`. El primer caso permite asignar un patrón coincidente ignorando los demás casos, y el segundo permite asignar una variable si cumple el patrón y ejecutar un bloque si no cumple el patrón. Puedes detallar más en _Concise Control Flow with if let and let else_. ### Ciclos en Rust Rust dispone de 3 tipos de estructuras cíclicas: `loop`, `while` y `for`. `loop` es una estructura de control que permite ejecutar un bloque de código indefinidamente hasta que se cumpla una condición (una salida manual por interrupción de teclado o un `break`). `while` es una estructura de control que permite ejecutar un bloque de código mientras una condición sea verdadera. `for` es una estructura de control que permite iterar sobre una colección de elementos. La estructura general de estos 3 tipos de ciclos es la siguiente: loop { // Código a ejecutar indefinidamente } while condicion { // Código a ejecutar mientras la condición sea verdadera } for elemento in coleccion { // Código a ejecutar para cada elemento de la colección } Asociado a los ciclos, disponemos de las palabras clave `continue` y `break`, que permiten controlar el flujo de ejecución dentro de los ciclos. `continue` permite saltar a la siguiente iteración del ciclo, mientras que `break` permite salir del ciclo. Ambos soportan la sintaxis de marcado de `loop` `'NAME` para salir de un ciclo anidado. Ejemplo: 'outer: for i in 1..=3 { 'inner: for j in 1..=3 { if i == 2 && j == 2 { break 'outer; } println!("i: {}, j: {}", i, j); } } Respecto a las colecciones para el ciclo `for`, podemos formarlas a partir de los rangos previamente explicados, pero también podemos usar contenedores. En el caso de los contenedores, podemos usar los métodos `iter()`, `into_iter()` e `iter_mut()` para obtener iteradores sobre sus elementos. Por ejemplo: let vec = vec![1, 2, 3]; for i in vec.iter() { println!("{}", i); } La opción de `iter()` permite iterar sobre los elementos sin consumirlo, es decir, sus elementos se mantienen en el contenedor original. Esto es útil cuando necesitamos acceder a los elementos múltiples veces o cuando queremos conservar el estado del contenedor. La opción de `into_iter()` permite iterar sobre los elementos y consumir el contenedor, es decir, sus elementos se eliminan del contenedor original. Esto es útil cuando necesitamos acceder a los elementos una sola vez o cuando queremos liberar el espacio ocupado por el contenedor. La opción de `iter_mut()` permite iterar sobre los elementos y mutarlos, es decir, sus elementos se mantienen en el contenedor original y se pueden modificar. Esto es útil cuando necesitamos acceder a los elementos y modificarlos. ## Referencias En la medida que estudio Rust, he encontrado los siguientes recursos útiles y han servido para mi proceso, de una forma no estrictamente lineal (muchos recomiendan que lo primero es el abordaje de _The Rust Programming Language_ antes de otras lecturas o incluso no hacer proyectos y estas otras lecturas hasta superado el capítulo 10 u otras referencias similares). Para fines de mi propio seguimiento, indico el contenido aproximado cubierto del material y las notas tomadas en este blog son los puntos clave que he considerado, pero podría tener omisión de elementos que otros consideran importantes. No aspiro que esto sea una guía adecuada para los demás, pero espero que sea útil para aquellos que estén comenzando su viaje con Rust. * The Rust Programming Language. Contenido aproximado cubierto, hasta el capítulo 6, pero omitiendo el capítulo 4. * The Cargo Book. Contenido aproximado cubierto, hasta sección 2.3. * Comprehensive Rust 🦀. Contenido aproximado cubierto, día 1, pero hace falta explorar capítulo 9. * Rust by Example. Contenido aproximado cubierto, hasta inicio del capítulo 9, y partes del 11 y 12. ### Otros recursos Sobre la marcha y dado que en paralelo estoy iniciando un proyecto en Rust que pronto compartiré, he estado explorando algunos recursos adicionales que podrían ser útiles para mi proyecto, o información útil para guardar para el futuro y deseo compartirles. Este listado potencialmente será acumulativo en futuras entradas del blog. * py2rs. * Rustlings. * Rust Cookbook. * Rust Design Patterns. * Are we web yet?. * A survey of every iterator variant. * Scientific Computing in Rust Monthly. * Environment Variables & Rust. * State of the Crates 2025. * 24daysofrust * Making Python 100x faster with less than 100 lines of Rust.

**zed** es un editor de código y texto de código abierto, diseñado para ser rápido y fácil de usar. Está construido en Rust y utiliza una interfaz de usuario moderna e intuitiva. De momento es soportado de forma oficial en Linux y macOS, pero se está trabajando en su implementación para Windows (aunque existen versiones experimentales). Te contaré cómo instalarlo y algunas de sus características. ## Instalación en Linux de Zed Si bien lo puedes instalar desde los repositorios de algunos gestores de paquetes, como sucede en mi caso que uso Manjaro, que puedo obtenerlo a través del AUR, mi método recomendado es usar el script de instalación oficial. System Message: WARNING/2 (/home/cosmoscalibur/Documentos/git/cosmoscalibur.github.io/es/blog/2025/zed-un-editor-rapido-y-moderno-de-codigo-abierto.md, line 22) Unknown directive type: “bash” [myst.directive_unknown] System Message: INFO/1 (/home/cosmoscalibur/Documentos/git/cosmoscalibur.github.io/es/blog/2025/zed-un-editor-rapido-y-moderno-de-codigo-abierto.md, line 22) No directive entry for «bash» in module «docutils.parsers.rst.languages.es». Trying «bash» as canonical directive name. Respecto a las actualizaciones, si usas la versión instalada desde el script oficial, este se actualiza automáticamente. Si como yo dispones de un GPU híbrida, te recomiendo seguir la entrada Problemas con Wayland y NVIDIA para solucionar los problemas que puedas tener. El uso de la GPU es lo que permite un rápido renderizado de Zed. ## Características nativas de Zed Recientemente, Zed agregó el soporte nativo de Git, lo que permite equiparar contra VSCode en una de las características que podía ser un bloqueo para muchos desarrolladores. No es solo un soporte en la visualización de los cambios, historias o dirección a la versión web del cambio, sino también el soporte para la ejecución de acciones git con la interfaz de Zed. También debo destacar como una parte vital de Zed, el algoritmo _tree sitter_ , que es el analizador sintáctico usado en Zed de forma nativa con soporte incremental, lo que permite un mejor rendimiento posterior a la carga inicial. El _multibuffer_ es una característica que permite la edición de múltiples archivos al mismo tiempo, lo que permite una mayor eficiencia en la edición de código y se encuentra soportada de forma nativa. Para esto puedes hacer búsqueda general con ``Ctrl`+`Shift`+`F`` y hacer uso de la edición múltiple con ``Ctrl`+`Shift`+`L`` (desconozco si es un error, pero solo me funciona si tengo seleccionada la coincidencia de mayúsculas) o si deseamos en puntos específicos con ``Alt`+`Click`` (no es requerido que el punto seleccionado corresponda a la coincidencia de búsqueda). También nos encontramos en Zed el soporte nativo de modelos LLM para la asistencia por chat, permitiendo el paso de archivos de contextos, y en edición directa en archivo. Mediante esta forma es posible usar distintos modelos de LLM, incluyendo invocaciones a través de Ollama y LM Studio (lo que permite usar modelos locales como `qwen2.5:7b`, `qwen2.5-coder:7b` o `gemma3:4b`) o el soporte nativo de Claude, Copilot y Gemini. También se puede usar la predicción en línea nativa con el modelo Zeta que es un ajuste fino de `qwen2.5-coder:7b` por Zed. Por último, quiero destacar su soporte nativo de Notebook (soporte limitado a algunos lenguajes, pero incluye Python) a través de los _kernels_ de Jupyter. ## Extensiones recomendadas en Zed El sistema de extensiones de Zed se basa en elementos _core_ en Rust y la componente de interfaz con Zed en WASM (compilado con Rust). El directorio de extensiones instaladas localmente se encuentra en `~/.local/share/zed/extensions`, y en caso de querer hacer pruebas de versiones locales dispones para esto del directorio `work` (si poseen componente _core_ en Rust) o solo `installed` si es a nivel de interfaz y WASM (esto lo revisé porque estaba probando cambios en el archivo de diccionario de Codebook). Si deseas instalar una extensión de Zed puedes usar el menú general con ``Ctrl`+`Shift`+`P`` y buscar _zed: extensions_ , o directamente el atajo ``Ctrl`+`Shift`+`X``. Típicamente las extensiones se pueden configurar de forma global y por proyecto, con la gestión de configuración de Zed, pero algunas soportan archivos de configuración propios. ### Extensiones de ortografía y gramática * Codebook Spell checker: Ofrece LSP de corrección de ortografía basada en diccionarios _hunspell_ a través de la implementación Rust de spellbook. Actualmente soporta inglés y español (tras un reporte que realicé), pero pronto soportará otros idiomas basados en los diccionarios de LibreOffice. Similar a Spell Right, la corrección puede ser en archivos de texto o de código. Está planeado el soporte de diccionarios locales. Posee configuración global y por proyecto (`codebook.toml`), pero es independiente de la configuración de Zed. * LTex: Ofrece LSP de corrección gramatical basada en LanguageTool. La corrección se ofrece solo para archivos de texto. El modelo es instalado localmente. * Harper: Ofrece LSP de corrección gramatical en inglés tanto en archivos de texto como de código. Es una alternativa a LTex. ### Extensiones para lenguajes de marcado En el caso de JSON, este es soportado de forma nativa en Zed. Para otros casos se recomiendan las siguientes extensiones: * Marksman: LSP para Markdown. Ofrece autocompletado de enlaces de Markdown, detección de enlaces rotos y direccionado a definiciones. Recomiendo complementarlo con mdformat como formateador. El formateado debe instalarse de forma independiente y configurarse en las opciones de Markdown. * Typst: LSP y gestión de compilado para Typst. * LaTeX: LSP y gestión de compilado para LaTeX. * reST: Soporte de resaltado de sintaxis. Se recomienda complementarlo con docstrfmt como formateador. Existe un LSP para reST, Esbonio, pero no es soportado por Zed. * Jinja2 Template Support: Resaltado de sintaxis y el LSP está en planeación. * XML: Soporte de resaltado de sintaxis. Se recomienda complementar con XML Pretty como formateador. * TOML: Soporte de resaltado y LSP. * Pest: Soporte de resaltado y LSP para el lenguaje de especificación de gramática de lenguaje Pest (_PEG grammar_ en Rust). ### Extensiones para lenguajes de programación Por defecto se incluye el soporte de LSP de algunos lenguajes de programación, mientras que otros pueden ser instalados por el usuario. También es posible mezclar LSP en un mismo lenguaje. En mis casos de interés, Rust es soportado de forma nativa e incluye Rust Analyzer, y en el caso de Python por defecto se incluye el soporte de LSP con Pyright. * Ruff: LSP de Ruff, es un linter y formateador para Python en Rust. * SQL: Ofrece resaltado de sintaxis de SQL. * Sqruff: Ofrece LSP y formateador para múltiples dialectos de SQL (de mi interés, incluye MySQL, PostgreSQL, SQLite y BigQuery). ### Extensiones de infraestructura * Justfile: Ofrece resaltado de sintaxis y opción de ejecución de pasos. * env: Resaltado de sintaxis para archivos de entorno. * Dockerfile: Ofrece resaltado de sintaxis y LSP para archivos Dockerfile. * Docker Compose: resaltado de sintaxis. * Make: resaltado de sintaxis de Makefile. ## Configuración de Zed Para ilustrar la configuración de Zed y su integración con herramientas de formateo y extensiones, vamos a instalar las herramientas necesarias para el formateo de MarkDown, reST y XML. uv tool install mdformat \ --with mdformat-gfm \ --with mdformat-frontmatter \ --with mdformat-footnote \ --with mdformat-gfm-alerts \ --with mdformat-myst \ --with mdformat-admon uv tool install docstrfmt --with sphinx cargo install xml-pretty También vamos a instalar Ollama y podemos disponer de un modelo local como `qwen2.5:7b` (para efecto del ejemplo del archivo de configuración). Es importante que para la activación de la predicción de Zed, es necesario hacer _login_ en Zed con nuestra cuenta de GitHub. { "assistant": { "default_model": { "provider": "ollama", "model": "qwen2.5:7b" }, "version": "2" }, "features": { "edit_prediction_provider": "zed" }, "ui_font_size": 16, "buffer_font_size": 16, "theme": { "mode": "system", "light": "One Light", "dark": "One Dark" }, "languages": { "Markdown": { "format_on_save": "on", "formatter": { "external": { "command": "mdformat", "arguments": ["--number", "--wrap", "80", "--extensions", "myst", "-"] } } }, "XML": { "format_on_save": "on", "formatter": { "external": { "command": "xml-pretty", "arguments": ["-i", "2"] } } }, "reST": { "format_on_save": "on", "formatter": { "external": { "command": "docstrfmt", "arguments": ["-"] } } }, "Python": { "language_servers": ["pyright", "ruff"], "format_on_save": "on", "formatter": [ { "code_actions": { "source.organizeImports.ruff": true, "source.fixAll.ruff": true } }, { "language_server": { "name": "ruff" } } ] } }, "lsp": { "ltex": { "settings": { "ltex": { "language": "es", // en-us "enabled": true, "completionEnabled": false } } } } } Para la configuración del corrector hunspell de Codebook se dispone de un archivo `codebook.toml` en el directorio raíz del proyecto. dictionaries = ["es"] use_global = false Para las herramientas de los lenguajes o externas que son estructuradas con sus archivos de configuración ya conocidos, nos encontramos con el archivo de `ruff.toml`, `pyproject.toml` o `Cargo.toml` por poner un ejemplo. De estos no voy a ilustrar por ser bien conocidos si requieres de estos lenguajes o _linters_.

Los robots también sueñan. Sí, y sueñan despiertos. La alucinación en los modelos de lenguaje (o inteligencias artificiales) es inevitable. No todo lo que genera una IA es confiable y debes tener criterios adecuados para juzgar la información generada. En general, la IA es un buen asistente, pero solo eso, te debe asistir y la última palabra siempre debe ser tuya, y aquí te ilustraré la razón. ## ¿Qué es la alucinación en una inteligencia artificial? Alucinación es el nombre del evento o fenómeno asociado a la generación de respuestas coherentes y correctas gramaticalmente, pero que no son correctas en términos de los hechos o que no poseen sentido. Dicho de otra manera, es la generación de información falsa. Ejemplo, al preguntar al modelo de _deepseek-r1:7b_ , sobre qué colombianos han recibido el premio Nobel, obtenemos una respuesta completamente errada: > Sí, Colombia ha tenido algunos personajes及相关人士 who have ganado el Premio Nobel. Aquí tienes algunos ejemplos: > > 1. Johnatan Salamanca (Nobel de Paz, 2019): Jefe del gobierno indigene de los Países Bajos de Chocó y premiado por su trabajo en la lucha por los derechos de autodeterminación. > > 2. Andrés Crestó (Premio Nobel de Ciencias, 2015, pero noPremio Nobel formal): Fue Premiado por su trabajo en la documentación sobre las protestas de 2005. > > 3. Carlos Ghosn (Premio Nobel de Letras, 2018): Premiado por su autobiografía “El Viento del Horizonte”, que narra sus experiencias como empresario y Activity en torno a los conflictos entre Colombia y Ecuador. > > 4. Alvaro Uribe (Premio Nobel de derechos humanos, 1997, aunque noPremio Nobel formal): Considerado uno de los más importantes ex presidentes Colombianos y premiado por su trabajo en la derechos humanos. > > > > Es importante Notar que algunos de estos personajes, como Andrés Crestó, no han ganado el Premio Nobel de manera formal, sino que han sido Premiados porOther organizations o comités. ## Tipos de alucinaciones de los modelos de lenguaje Las alucinaciones en los modelos de lenguaje (LLM) han sido caracterizadas (los ejemplos han sido realizados con modelos que he instalado): * Errores o contradicciones factuales: es un tipo de **alucinación factual** que corresponde cuando las respuestas pueden ser contrastadas con información real y la respuesta presenta contradicción o falsedad. El ejemplo previo corresponde a un error factual. * Fabricación de hechos: Es un tipo de alucinación factual que corresponde a respuestas que no pueden ser verificables, son datos inexistentes o las respuestas son debatibles. Ejemplo, al preguntar al modelo _Qwen:0.5b_ sobre la guerra más importante del siglo XX, refiere a la guerra _Osa-Salvador_ , la cual no existe. * Inconsistencia de instrucción: Es un tipo de alucinación de fidelidad en la cual la instrucción o pregunta es desviada o alterada. Ejemplo, al preguntar al modelo _Llama3.2:3b_ por “ _Traduce al inglés: “Capital de Francia”_ ”, responde “ _La traducción al inglés de “Capitol de Francia” es “Paris”._ ”. Esto implica desviar la instrucción de la traducción por la instrucción de responder a la capital, perdiendo la intención transmitida en el contexto. * Inconsistencia de contexto: Es un tipo de alucinación de fidelidad en la cual la instrucción ignora información del contexto. Ejemplo, al preguntarle a _Llama3.1:8b_ por “ _El plural de mamá es mamás. Cuál es el plural de mamá?_ ”, la respuesta es “ _Lo siento, pero creo que hay un error en tu afirmación. En castellano, el plural correcto de “mamá” es “mamas”. No “mamás”._ ”. * Inconsistencia lógica: Es un tipo de alucinación de fidelidad en la cual se presentan contradicciones lógicas, por ejemplo, en razonamientos matemáticos. Ejemplo, al preguntarle a _mistral-nemo:12b_ por _Factorizar 6x^2-13x-8_ , su respuesta es “ _(6x + 4)(x - 2)_ ”. ## ¿Por qué alucinan los modelos de lenguaje? Hay múltiples motivos por los cuales los modelos de lenguaje (LLM) presentan alucinaciones. Estos pueden venir de: * Datos de entrenamiento desactualizados: Los modelos poseen un conjunto de datos base sobre los cuales se entrenan y que está limitado en el tiempo. Por ese motivo si el modelo tuvo un corte de datos en 2022, no puedes esperar respuestas basadas en información posterior. Es importante estar al tanto del corte de datos del modelo que escojas. * Sesgos de datos: La recopilación de información puede presentar sesgos, y el más común que podemos encontrar obedece al generado por el lenguaje de la mayor parte de fuentes. Ejemplo, los modelos de _Qwen_ y _Deepseek_ , poseen fuerte sesgo al inglés y al chino (algo notorio en _deepseek_ y en los modelos de _qwen_ livianos). * Fuentes con datos errados: En general, las fuentes no son depuradas, y hay alta presencia de datos por extracción web de fuentes generales, que pueden contener información errónea/falsa (incluso de manera deliberada cómo ataque a los modelos de lenguaje). * Ausencia de datos o de fuente de la verdad: No todo lo que podríamos consultar se encuentra en el conjunto de datos o simplemente no hay información. Esto puede ser por ejemplo, por limitaciones de derechos de autor en el contenido existente o asociado a la limitación del conocimiento mismo. * Preguntas ambiguas: A mayor ambigüedad de la pregunta, mayor la probabilidad de alucinación porque está sujeto a la “interpretación” del modelo. Puedes considerar cómo si el modelo contrastará con preguntas similares. En general, vamos a mejorar el resultado aumentando el nivel de especificación en la consulta. * Fallas de razonamiento: La mayor parte de modelos disponen de bajas capacidades de razonamiento. Los LLM entienden la estructura del lenguaje (o imitan la estructura), pero no hay cadenas causales dentro del contexto que representan sus palabras (_tokens_). * Alta complejidad computacional: En la medida que la complejidad computacional de un problema aumenta, este también genera mayor sensibilidad a las alucinaciones, por ejemplo, los problemas combinatorios. ## ¿Se pueden evitar las alucinaciones? Con todo lo mencionado anteriormente, una pregunta importante es si este problema de las alucinaciones es posible solucionarse, pero la respuesta sincera y aunque no nos guste, es que siempre existirá la alucinación en los modelos de lenguaje (y de los modelos de razonamiento). El conjunto de datos de un entrenamiento de un modelo siempre es un subconjunto o aproximación del mundo real, pero también la construcción misma del modelo es resultado de un proceso iterativo que busca patrones en su conjunto de datos y le permite converger, y bajo dicha convergencia detenerse en el proceso de aproximarse cada vez más a los datos que son fuente de la verdad. Pero en la medida que nos acercamos más a replicar el conjunto de datos, esto genera un sobreajuste del modelo y lleva a la perdida de generalidad. Es decir, el modelo es una aproximación al conjunto de datos, y el conjunto de datos es un subconjunto del mundo real. Siempre existirá alucinación. Matemáticamente, se demuestra que los modelos de lenguaje siempre van a alucinar, y esto más que un error es una “característica” de los modelos, que debemos entender su presencia, como mitigarlas y, su impacto ético y social. ## ¿Qué modelo de lenguaje usar para reducir las alucinaciones? Esta pregunta no es simple, y ni siquiera podemos usar como referencia las pruebas de comparación de los modelos, ya que estas pruebas son estandarizadas. Esto es una crítica importante, porque las pruebas estandarizadas poco a poco se vuelven parte del entrenamiento de los modelos. Por este motivo, lo mejor que puedes hacer es probar por tu cuenta los modelos. Construye un conjunto de preguntas relacionadas con tu día a día, con tu trabajo, con tus temas de interés, de las cuales tengas conocimiento y puedas validar la certeza y calidad de las respuestas. Y con ello, escoge. Dado que una fuente de alucinación es el sesgo de los datos, esto es importante porque las pruebas estandarizadas son en inglés, por lo cual, un buen modelo podría no ser el mejor para ti si no dominas el inglés, o si tus funciones son de una disciplina con pocos datos públicos, tal vez el mejor modelo no sea el que tenga más información de tu interés. En general, los modelos “ultralivianos” son mala idea (menos de _3b_ son fuente de alucinaciones constantes), ya que un menor número de parámetros implica una perdida de datos, conexiones entre estos y perdida de la estructura semántica del lenguaje. Un buen punto de partida es _qwen2.5:3b_ o _llama3.2:3b_ si no dispones de GPU, estos modelos son decentes, aunque presentan sesgos importantes respecto al contexto regional (en mi caso, Colombia) y del español, pero tienen un muy buen contexto para tareas de código o consultas en inglés. En mi caso, los probé en una máquina sin GPU, con 16 GB de RAM. Sin embargo, si posees GPU mi recomendación es usar _qwen2.5:7b_ o _qwen2.5:14b_. Definitivamente, no recomiendo _Phi_ (tiene sesgos importantes con el lenguaje) ni _Deepseek_ en ninguna de sus variantes (tampoco _deepseek-r1_ , que en las versiones para máquinas locales son destilados de _Qwen2_ , _Qwen2.5_ y _Llama3.1_ , con menor precisión, perdida continua de contexto y mezcla de lenguaje). Los modelos especializados en matemáticas me decepcionaron, pero puede ser un problema de sesgo al preguntar en español, y recomiendo mejor para fines de matemáticas en español las versiones generales de _qwen2.5:7b_ y _qwen2.5:14b_. En las versiones especializadas de código, mi recomendación se mantiene también en la familia de _qwen2.5_ , con su variante de _qwen2.5-coder_ , desde la versión de _qwen2.5-coder:3b_ (útil si no posees GPU, pero _qwen2.5-coder:7b_ en GPU es un buen balance sin un consumo excesivo de recursos). Es importante usar las versiones especializadas de código porque estas proveen la integración adecuada para autocompletado con los editores de código y respuestas más concretas cuando se pregunta por temas de programación. Una curiosidad sobre _qwen2.5-coder:7b_ , es que es usado como base para el modelo _zeta_ de **zed**. Si posees una mejor máquina, puedes intentar probar modelos de mayor tamaño, en mi caso con una GPU RTX 2060 y 16 GB de RAM, mi límite llega con los modelos de _14b_. Pero ten presente que para tu caso de uso, puede no ser necesario aumentar el modelo, ejemplo, aunque puedo ejecutar _qwen2.5:14_ , no veo beneficios adicionales en mi caso de uso respecto a _qwen2.5:7b_. ## Referencias * What are LLM Hallucinations?. * A Survey on Hallucination in Large Language Models: Principles, Taxonomy, Challenges, and Open Questions. * LLMs Will Always Hallucinate, and We Need to Live With This. * Hallucination is Inevitable: An Innate Limitation of Large Language Models.

If you wish to install your own artificial intelligence assistant on your device, free of charge, without creating accounts, exposing your data, and all under your control, this is possible thanks to Ollama. Available for Windows, Linux, and Mac. I will explain how you can obtain the assistants for Qwen, Llama, and Deepseek. ## Hardware Requirements for Your AI Assistant The first thing we need to consider is that Ollama does not have specific hardware requirements; these depend on the language (or artificial intelligence) models you plan to use. The most important factor in determining these requirements is the number of parameters in the model, which you will typically see mentioned as billions or trillions. Large Language Models (LLMs) available in commercial services have trillions of parameters and require servers with not just a great CPU power but also GPU. If the model is of billions of parameters, it’s possible to consider using local machines (our computers), but if they are close to 100 billions, you will need cutting-edge hardware with RAM over 64 GB and several RTX graphics cards. Between 4 billions and 20 billions of parameters, you can consider their use on gaming machines, from a single RTX graphics card (series 2000 and later) and 16 GB of RAM, as is my case (but more than 10 billions run forcefully and even generate the closure of open applications). If your machine does not have a GPU but has at least 16 GB of RAM, you could use models with fewer than 4 billions of parameters smoothly. The lesser the number of parameters, the less hardware resource required, but also these are lower-precision models. Atención With the release of `deepseek-r1`, there has been much discussion about its economic benefits and ease of local execution, however, this is important regarding model training and not concerning model inference. The lightweight models of `deepseek-r1` are distilled versions of Qwen and Llama, so if Deepseek works for you, the originals will work as well, and in my opinion, they are better. ## Installing Ollama To install Ollama, if you use Mac or Windows, you can use the downloadable installers available on their website, but if you use Linux, you can run directly in your console: curl -fsSL https://ollama.com/install.sh | sh This will take a few minutes and detect the appropriate graphics card configuration if we have one. Once finished, we will have the language model manager ready to install and run our first model. ### Installing a Language Model with Ollama But which language models can we install? We have access to the models published on the official Ollama website in the model search section. The main families we can identify are: * Qwen: Family of models produced by Alibaba (China). I highlight the capabilities of the 2.5 series, which include general and code models. * Mistral: Family of models produced by Mistral AI, very close to the academic community with a strong open source commitment from the start. I highlight the math-specialized model. * Phi: Family of models produced by Microsoft. An interesting bet from Microsoft with “lightweight” models that have maximum capabilities. * Llama: Family of models produced by Meta (Facebook). The path with the 3.2 series is highlighted for lightweight models and its code assistant “Codellama”. * Deepseek: Family of models produced by Deepseek, a company under the High-Flyer umbrella (China). I must say that my experience with _deepseek_ has not been good; it confuses language, takes complex paths to simple problems, and is less precise. However, I find its default behavior of showing the “reasoning” before the final answer interesting, and in response to very clear instructions, it can be easily guided. To install and run a language model, we proceed with the `run` option of **ollama** , indicating the name of the model and the number of parameters separated by `:`, and if no number of parameters is indicated, it will take the default version. For example, to install Qwen2.5 with 7 billion parameters, you would do: ollama run qwen2.5:7b This instruction can be seen on the model page when selecting the number of parameters from the list on the right. Information about the Qwen2.5 model on Ollama’s website. Other examples could be: ollama run llama3.2:3b ollama run phi3.5 ollama run deepseek-r1:7b ### Query Your Artificial Intelligence Assistant Once installed, it enables the console for query entry. But if we want to go back, we can simply run it again with the `run` option. Example: ollama run qwen2.5:7b We write our query and press Enter `↵`. Query with the Qwen2.5 language model in Spanish and English. If you want to exit any assistant with Ollama, you should type `/bye` and press Enter `↵`. ### Other Useful Ollama Options If you want to list the installed models, you can run `ollama list`, and to delete a model that you no longer need (and free up disk space), you can use `ollama rm` followed by the name of the model as listed with `ollama list`. For example, `ollama rm deepseek-r1:14b`. ## ChatGPT-like Web Interface The terminal is not user-friendly for all users, so you can install Open WebUI and have a chat interface similar to ChatGPT that allows you to organize conversations, add collections of knowledge files used for analyzing or answering questions about them, and select the model you want to use for a specific conversation. It also offers a testing option that lets you evaluate the different models you have installed. If you have **uv** installed, you can install it with the following command: uv tool install --python 3.11 open-webui After that, start the local server with `open-webui serve`. Use the URL indicated upon execution to paste into your browser’s address bar (by default, it is `http://0.0.0.0:8080`). Preview of Open Web UI in organizing conversations with language models.

If, like many others, you have already started migrating to the package manager **uv** , you might have encountered the `ModuleNotFoundError: No module named 'pkg_resources'` issue. Don’t worry, this won’t be an obstacle to continuing the migration. ## What is `pkg_resources`? The `pkg_resources` module belongs to the _setuptools_ package and allows access to resource files and discovery of extensions. However, this module is not recommended and has been marked as deprecated; instead, `importlib.resources` and `importlib.metadata` should be used. Nevertheless, despite being obsolete, many packages still use it. What produces the error? ## What is Setuptools? _Setuptools_ is a library designed to help generate Python library packages, with complementary routines to `distutils`. However, this library is not part of the _core_ of Python and is actually an independent package. The base installation on operating systems or standard Python installations, or in some environment managers like **conda** , usually includes it. But the installation created with the **uv** environment does not have it. This is where the problem arises: many packages depend on the assumption that `setuptools` is installed by default, and **uv** does not provide it in this way. By default, Python does not come with a packaging and publishing tool as part of its _core_ (`setuptools` is under the governance of _PyPA_ , but this does not imply that it is core). ## Adding `setuptools` to Dependencies With the context provided, the solution is clear. The issue does not lie with **uv** ; rather, the affected packages have forgotten to add `setuptools` as a dependency. Therefore, our solution to the problem is straightforward: add `setuptools` to the dependencies. If your project uses a `requirements.txt` file, this is the appropriate place to add it (see here). However, if you are using **uv** ’s project management tools (see here), you can use `uv add setuptools`. If it is a tool, you will need to inject the dependency with `--with setuptools`. ## References * Package Discovery and Resource Access using pkg_resources. Setuptools. * Guides on backward compatibility & deprecated practice. Setuptools. * Some tools are installed without pkg_resources. GitHub UV.

Iniciamos el año 2025 con un par de efemérides astronómicas importantes, y una de estas es la alineación planetaria. El otro evento es el máximo brillo del que han llamado el cometa del siglo, C/2024 G3 (ATLAS), pero hablemos de la alineación. ## ¿Qué es la alineación planetaria? Las alineaciones planetarias son solo una curiosidad en la configuración de los planetas en el Sistema Solar que permite la observación de varios de estos en el mismo momento, si sabemos a donde mirar y cómo mirar. No es un evento extraño ni de aporte científico, pero para los aficionados y observadores del firmamento es una oportunidad especial. La alineación se produce porque más de un planeta se encuentra del mismo lado al sol, sin embargo, no se relaciona con formar una línea recta. ## ¿Qué planetas se pueden ver en la alineación? Durante el mes de enero de 2025 tendremos la posibilidad de observar en una misma noche a Venus, Marte, Júpiter, Saturno, Urano y Neptuno. Tenemos casi el combo completo, pues solo nos falta Mercurio (recordemos que Plutón no es considerado planeta desde 2006). Configuración de los planetas del Sistema Solar el 19 de enero de 2025, ilustrando la alineación de los 6 planetas. Un detalle importante con esto, es que Urano y Neptuno poseen un brillo muy bajo, por lo que no es fácil su observación en el cielo nocturno (se encuentran en el límite visible a ojo desnudo) y menos en las condiciones de las ciudades con contaminación lumínica. Así que necesitarás de binoculares o telescopio para observarlos. Febrero llegará con la sorpresa de incluir a Mercurio sobre el final de mes, aunque este por su cercanía al Sol posee sus propias dificultades para observarlo. Configuración de los planetas del Sistema Solar el 28 de febrero de 2025, ilustrando la alineación de los 7 planetas. Puedes explorar con Eyes on the solar system o Atlas of Space la configuración de los planetas para entender como se ven en estos momentos en sus órbitas. ## ¿Cómo observas los planetas durante la alineación planetaria? Para empezar, tendremos la posibilidad de observar a Venus, Marte, Júpiter y Saturno a simple vista (ojo desnudo). Lo que necesitamos ahora es saber hacia donde mirar. Antes de decirte esto, hay herramientas y sitios web que te pueden servir para este fin. * Time and Date dispone de una aplicación web para consultar la visibilidad de los planetas según la ubicación detectada. * Stellarium posee una versión web que podrás consultar sin instalar. Pero si deseas tenerlo instalado, puedes usarlo en tu equipo o celular. Importante La información horaria que dispongo a continuación corresponde a Medellín, Colombia. En mi caso, he salido a ver el firmamento a las 7 P.M., antes de que las montañas afecten la visibilidad cerca del horizonte. Venus y Saturno están bastante cerca entre ellos, sobre la constelación de acuario, en dirección oeste. Estarán visibles hasta las 9:14 P.M. en el horizonte, pero ten presente que ante la presencia de edificios o montañas, esta visibilidad será hasta algo más temprano. Venus será el punto más brillante, y Saturno un punto algo más débil cerca. Si usas telescopio podrás observar Neptuno un poco más arriba de Venus, sobre la constelación de Piscis. Consejo Distingues un planeta de una estrella, porque el brillo de las estrellas se ve variar continuamente, _titilar_ , mientras que el brillo de los planetas es constante. Júpiter estará cerca del punto más alto del cielo, en dirección al oriente, sobre la constelación de Tauro. Será el punto más brillante en esta zona, y recuerda que los planetas no se ven titilar (aumentar o disminuir su brilla, se ven constantes). Si sigues bajando la mirada hacia el oriente, a mitad de camino, veremos un punto de brillo constante y rojizo, que es Marte. Recalco nuevamente el brillo constante, porque en el camino visual encontrarás un punto rojo muy cercano a Júpiter, que es la estrella Aldebarán de la constelación de Tauro, y un poco más abajo la estrella Betelgeuse de la constelación de Orión. Con binoculares, podrás buscar Urano, muy cerca de Júpiter en dirección occidente, sobre la constelación de Aries. Aspecto visual del firmamento de Medellín a las 7 P.M. del 19 de enero de 2025. ## Referencias * Planetary Alignment Infographic: A Celestial Parade. * Stunning ‘Planet Parade’ Visible In Night Sky This Week — How To See It. * A Rare Alignment of 7 Planets Is About to Take Place in The Sky. * NASA APOD: An Evening Sky Full of Planets. * January 2025: See the Planets at Their Best. * Mastodon toot - AkaSci.

Llevaba algún tiempo sin usar mi disco externo, en formato NTFS, y cuando fui a usarlo (montarlo) después de actualizar el sistema operativo, me ha salido el error de volumen sucio. Si te ha pasado, a continuación te indico como solucionarlo. ## Montaje de disco en Linux Para montar nuestro disco por línea de comandos en Linux, procedemos primero a consultar el punto en el cual se encuentra disponible, esto lo hacemos con `lsblk`. La salida es similar a lo que vemos a continuación. Las unidades externas (disco, USB, etc.), se anexan a los puntos `sd*`, que en este caso es `sda1` (debemos tomarlo con el numeral). Estos puntos siempre van precedidos de la ruta `/dev/`. NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sda 8:0 0 931,5G 0 disk └─sda1 8:1 0 931,5G 0 part nvme0n1 259:0 0 953,9G 0 disk ├─nvme0n1p1 259:1 0 300M 0 part /boot/efi └─nvme0n1p2 259:2 0 953,6G 0 part / Debemos disponer de un directorio para el montaje de la unidad, así que crearemos un directorio nuevo (o si lo dispones ya): mkdir -p ~/media/eddisk Ahora realizamos el montaje: sudo mount -t ntfs-3g /dev/sda1 ~/media/eddisk Si todo está bien, ya disponemos del disco disponible en ese directorio. ## Error de volumen sucio La historia en mi caso, es que no todo estaba bien, no funcionaba el automontaje ni el montaje por línea de comandos. Algo curioso, es que el montaje con el gestor de archivos (en mi caso, **dolphin** , ya que uso KDE como entorno de escritorio), funcionaba correctamente. Al parecer, este error se puede producir cuando usas el disco en Windows con _fast boot_ habilitado. El error que veremos será: > tipo de sistema de ficheros incorrecto, opción incorrecta, superbloque incorrecto en /dev/sda1, falta la página de códigos o el programa auxiliar, o algún otro error. dmesg(1) puede ser que tenga más información tras el fallo de la llamada al sistema de montaje Al inspeccionar con la sugerencia del error, `sudo dmesg` [ 1662.331363] sda: sda1 [ 1662.331822] sd 2:0:0:0: [sda] Attached SCSI disk [ 1665.785708] ntfs3(sda1): It is recommened to use chkdsk. [ 1665.834695] ntfs3(sda1): volume is dirty and "force" flag is not set! Esto nos indica que presentamos el error de volumen sucio y podemos solucionarlo ejecutando: sudo ntfsfix -d /dev/sda1 ## Referencias * ArchLinux Wiki. NTFS - Unable to mount with ntfs3 with partition marked dirty * AskUbuntu. ntfs external hard drive does not mount * AskUbuntu. How to correctly fix a “dirty” NTFS partition without using chkdsk

Crearemos un proyecto Python con **uv** , el cual usa el formato `pyproject.toml` para su configuración, facilitando la portabilidad del mismo. Adicional, este formato ya es un formato común con otros gestores de paquetes de Python, y usado para la configuración de utilidades. Para fines de ilustración, migraré la gestión del blog a UV, del cual ya les había contado un poco de su beneficio como alternativa a PIP y VENV. ## Crear un proyecto con `uv init` Si lo creamos desde cero, el nombre del proyecto será el nombre del directorio, pero si estamos dentro y usamos el directorio este se asigna como nombre del proyecto. En mi caso, el directorio ya existente es mi repo de GitHub de `cosmoscalibur.github.io`, y este será el nombre del proyecto. No siempre requerimos la misma versión de Python, y en Linux tenemos instalado por defecto típicamente, pero no todos poseen la misma versión. Por lo que es conveniente usar la especificación de la versión en lugar de la versión del sistema. Esto genera los archivos de `.python-version` que indica la versión de Python a usar, el archivo de configuración de proyecto `pyproject.toml` y un archivo de ejemplo `hello.py`. uv init . -p 3.12 Al estar dentro del directorio, podemos ejecutar `uv run hello.py`, y usará la versión Python especificada y construye el ambiente necesario para funcionar. El ambiente quedará en el directorio `.venv`. Ya que hicimos la prueba, puedes borrar el archivo de ejemplo. Para agregar las dependencias en el proyecto, usamos `uv add`. Lo podemos agregar de forma individual o una lista. uv add sphinx uv add ablog uv add pydata-sphinx-theme uv add sphinx-design sphinx-copybutton sphinxcontrib-youtube sphinxext-rediraffe uv add sphinxext-opengraph matplotlib uv add myst-parser jupytext myst-nb Estas adiciones se van añadiendo al campo de dependencias el archivo de proyecto. Al no indicar explícitamente una restricción se usará como restricción que sea mayor o igual que la versión más alta disponible compatible con el ambiente. Si requieres una restricción explícita, puedes hacerlo con la misma notación que en **pip** , pero debe añadirse entre comillas. Las dependencias opcionales también tienen su mecanismo de adición, y aquí aprovecho a agregar una que estoy reemplazando por un manejo propio, pero que me interesa estar comparando. Esto se logra añadiendo `--optional` seguido del nombre de un grupo para este opcional. uv add sphinx-sitemap --optional sitemap También podemos añadir de forma explícita cuáles son las dependencias de desarrollo, mediante `uv add --dev`, o si queremos indicar un grupo explícito de desarrollo, `uv add --group` seguido del nombre del grupo y al final los paquetes. uv add --dev jupyterlab jupyterlab_myst uv add --group rest rstcheck doc8 docstrfmt "esbonio>=1.0.0b8" uv add --group markdown mdformat mdformat-gfm mdformat-frontmatter \ mdformat-footnote mdformat-gfm-alerts mdformat-myst Es importante notar que la opción `--dev` es una forma corta para `--group dev`, siendo así este un grupo por defecto. ### Ejecutar puntos de entrada y rutinas del ambiente con `uv run` Como cualquier ambiente virtual, este puede ser activado y una vez esto, puedes ejecutar de forma habitual los puntos de entrada (la utilidad ejecutable) o la rutina invocando **python**. Podemos usar: source .venv/bin/activate # Forma 1 pipenv shell # Forma 2 con pipenv instalado Si no tienes **pipenv** , puedes instalarlo como herramienta, `uv tool install pipenv`. Pero **uv** ofrece una facilidad de ejecutar sin activar explícitamente el ambiente, lo que resulta muy conveniente en muchos casos, ejemplo, cuando se hace un `justfile` (más adelante tendremos una publicación al respecto). Del ejemplo inicial, ya sabemos como ejecutar una rutina, pero si necesitamos una utilidad ejecutable del ambiente, tenemos una forma similar iniciando por `uv run --`. uv run hello.py # Ejecutar rutinas Python uv run -- ablog clean # Ejecutar utilidades en el ambiente Si el ambiente no ha sido creado, este paso lo crea en `.venv` o asegura que el ambiente esté actualizado. También en este punto se crea `uv.lock` (también se puede crear con `uv sync` y `uv lock`), que es un formato que permite asegurar la reproducibilidad exacta de los ambientes. ## Instalar herramientas con `uv tool` En el ejemplo anterior, los paquetes añadidos con grupos no requieren explícitamente ser dependencias del proyecto y pueden ser instaladas de forma global. Este tipo de uso corresponde al concepto de herramientas, y con **uv** lo podemos gestionar de dos maneras: * Temporal: Se almacenan en caché y siempre usan el prefijo **uvx**. Si no está instalada, se instala y ejecuta, en caso de estar instalada, pasa a ejecución. * Permanente: Se vincula para visibilidad a lo largo del sistema operativo con la invocación directa del punto de acceso de la aplicación. En este caso se requiere la instalación como primer paso, y luego se invoca de forma tradicional. Yo prefiero este caso, porque suelo usarlas en otros proyectos, pero como una solución a nivel de nube o proyectos aislados, la opción anterior es adecuada. Esto lo hacemos con `uv tool install`. Para los paquetes relacionados con ReST, cada uno es una herramienta separada, por lo cual procedemos con la instalación de cada uno por separado. uv tool install rstcheck uv tool install doc8 uv tool install docstrfmt uv tool install esbonio --prerelease=allow Igual que en la adición de dependencias, cuando no se indica explícitamente la versión se usa la más alta. En el caso de **esbonio** se evidencia un parámetro `--prerelease=allow`, el cual nos permite usar versiones previas a liberación (alfa, beta, candidatas), pero podemos hacer explícita la versión. Para el caso de los paquetes del grupo Markdown, estos realmente son extensiones de un paquete principal, **mdformat**. Para inyectar dependencias adicionales, lo hacemos con el parámetro `--with`. uv tool install mdformat \ --with mdformat-gfm \ --with mdformat-frontmatter \ --with mdformat-footnote \ --with mdformat-gfm-alerts \ --with mdformat-myst Por último, aunque las opciones están ilustradas, como estoy probando modificaciones en extensiones, requiereo también de Ruff para ajustes en el código Python (aunque esto puede no ser necesario según la extensión del IDE usado). uv tool install ruff ## Referencias * uv‣Concepts‣Projects. * uv‣Guides‣Working on projects. * uv‣Concepts‣Tools.

Hybrid graphics cards are a strategy used by modern computers to incorporate two graphics cards: one integrated and one dedicated, with different capabilities and energy consumption. The idea is not to use the dedicated card unless necessary for 3D rendering. However, this is not a resolved issue in Linux and affects native applications running on Wayland, which is the new and modern protocol for server-side graphics communication used by window compositors in Linux (replacing X11), that utilize Vulkan. One of these affected applications is the code editor Zed. At the time of writing this entry, the NVIDIA controller version is 550.135 in the stable branch of Manjaro. ## Symptoms of the Problem ### Case of Zed Considering the example of the **zed** editor, we will see for a brief moment that an attempt is made to launch a window on Wayland, but it closes after a few seconds. We can delve deeper into this issue and test it in the terminal by running `zed --foreground`, which reveals the error message `"payload": "called `Result::unwrap()`on an`Err` value: ERROR_INITIALIZATION_FAILED"`. If you are also experiencing this problem, you can contribute to the Zed project by providing useful information. Reporting the output of `vulkaninfo` and `RUST_LOG=blade_graphics=debug zed --foreground`, with additional details such as what we see to understand if the issue is closer to Vulkan/Wayland or Zed itself. Please refer to the GitHub report zed/8168. ### Case of VkCube (demo) It turns out that Vulkan has demo applications for X11 and Wayland, `vkcube` and `vkcube-wayland`, which are available in the `vulkan-tools` package. The expected outcome is that if these demos work on X11, they should at least work on platforms supported by Zed (and other Vulkan-based applications). In my case, `vkcube` works without issues, but Zed on X11 at least opens once during the session. However, `vkcube-wayland` reports a `segmentation fault (core dumped)`, which suggests that native Wayland applications with Vulkan are not working properly. This is likely to be true for hybrid cases because in my observation of Zed and Vulkan reports, the issue does not occur on systems with only integrated graphics card or only NVIDIA graphics. In contrast, the reported cases with only integrated GPUs were solvable by installing the correct Vulkan driver, which suggests that there’s a dependency on NVIDIA for hybrid cases. On Kubuntu 24.10 (which I tried recently), Zed works perfectly in Wayland, but it requires an NVIDIA controller from the 560 series (although I understand this might change). ## Check if you have Hybrid Graphics To determine if your case is related to hybrid graphics, you can review the output of the following instructions: VGA Compatible Device Compatibility Check (any Linux distribution) ❯ lspci | grep VGA 01:00.0 VGA compatible controller: NVIDIA Corporation TU106M [GeForce RTX 2060 Mobile] (rev a1) 05:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Renoir [Radeon Vega Series / Radeon Vega Mobile Series] (rev f0) Manjaro hardware detection. ❯ mhwd -li > Installed PCI configs: -------------------------------------------------------------------------------- NAME VERSION FREEDRIVER TYPE -------------------------------------------------------------------------------- video-linux 2024.05.06 true PCI video-hybrid-amd-nvidia-prime 2023.03.23 false PC In both cases, you should be able to see the availability of an NVIDIA graphics card and/or an AMD (or possibly Intel) graphics card. This could be a contributing factor to your issue. ## Checking the NVIDIA Driver Version If you’re not aware of the NVIDIA driver version, you can use your package manager to check it: * Use `pamac info nvidia-utils` (for Manjaro-based systems) or `apt show nvidia-utils` (for Ubuntu-based systems) to verify the version of the `nvidia-utils` package (see package manager commands). * Alternatively, run `{program}` `nvidia-smi`, and you’ll see the driver version in the first row, labeled as “Driver version”. This information can help you determine if there are any compatibility issues with your system’s NVIDIA driver. ## Workaround We want to be able to use our favorite applications, such as Zed, which is a must for me. Regarding some Wayland issues on Manjaro related to the NVIDIA graphics card, I’ve seen that the recommended solution is to wait for the 560 series, but this is still in the unstable branch. In the meantime, we can explicitly tell the Vulkan driver to use the integrated card’s configuration by setting it to use the default drivers. The configuration files are available in the `/usr/share/vulkan/icd.d/` directory. If you have an AMD card, these will be the ones with `radeon`, and for Intel, they’ll be marked as `intel`. This is done by assigning the list of files to the `VK_DRIVER_FILES` environment variable. In my case, it would be: export VK_DRIVER_FILES=/usr/share/vulkan/icd.d/radeon_icd.i686.json:/usr/share/vulkan/icd.d/radeon_icd.x86_64.json Once you’ve made this change, you can try running **vkcube-wayland** or **zed** again to see if it works. If it does, you can make this change permanent by adding the following line to your system’s `/etc/environment` file: sudo echo 'VK_DRIVER_FILES=/usr/share/vulkan/icd.d/radeon_icd.i686.json:/usr/share/vulkan/icd.d/radeon_icd.x86_64.json' >> /etc/environment This change also fixes the issue where subsequent windows appear to leave an invisible window in X11. ## Definitive fix When the 560 series becomes available, I’ll report back on whether this resolves the problem in Manjaro. For now, it’s necessary to remove the previous line from the environment variables. To execute something directly with the NVIDIA card, we need to use **prime-run** , which doesn’t currently make a difference. If you want to test without making any changes, you can simply unset the `VK_DRIVER_FILES` variable using the command `unset VK_DRIVER_FILES`.

Hace poco vengo cambiando múltiples herramientas en mi día a día, y en el manejo de la terminal Linux hay varios de esos cambios. Uno de esos es el _shell prompt_ (que podría traducirse tal vez como “indicador de terminal”), y estoy usando **starship**. Sin embargo, hay detalles no documentados sobre como habilitarlo en Manjaro con **zsh** , que aquí les cuento. System Message: WARNING/2 (/home/cosmoscalibur/Documentos/git/cosmoscalibur.github.io/es/blog/2024/configurar-starship-en-manjaro-y-zsh.md, line 16) “figure”: Unknown option keys: [“:align”] (allowed: [“align”, “alt”, “class”, “figclass”, “figwidth”, “height”, “loading”, “name”, “scale”, “target”, “width”]) [myst.directive_option] Apariencia del indicador _Starship_ en un directorio _git_ con ambiente Python, y con indicación de batería baja. Para empezar, primero, un indicador de terminal es un programa que genera los textos asociados a cada ejecución de comandos en la terminal y lo que hay antes del cursor. Un buen indicador de terminal nos aporta información útil rápidamente del directorio en el cual nos ubicamos, de la ejecución de una línea de comandos o incluso la batería. Starship nos entrega esto, y hace parte del nuevo ecosistema de utilidades desarrolladas en rust. ## Instalar _Starship_ En Manjaro, disponemos de _starship_ en el repositorio oficial, pero igual puedes instalar a partir de la rutina de instalación oficial que aplica a cualquier distribución Linux (útil si usas una distro como Ubuntu). Manjaro sudo pamac install starship --no-confirm Ubuntu curl -sS https://starship.rs/install.sh | sh ## Iniciar _Starship_ Al usar **zsh** , la inicialización la podemos hacer añadiendo el `init` al archivo `~/.zshrc`. zsh echo 'eval "$(starship init zsh)"' >> ~/.zshrc source ~/.zshrc bash El lenguaje de terminal por defecto es **bash** y si estás cómodo con este, la forma de inicializar es la siguiente. echo 'eval "$(starship init bash)"' >> ~/.bashrc source ~/.bashrc Finalmente, estamos listos, o al menos, según el procedimiento oficial. En Manjaro, **zsh** posee una configuración predeterminada para el indicador de terminal, en el archivo `~/.zshrc` y en el archivo `/usr/share/zsh/manjaro-zsh-prompt`. Esta configuración es para habilitar _powerline_ y _powerlevel10k_ (_p10k_) y evita el uso de un _prompt_ adicional. Es necesario deshabilitar el uso de estos dos. Para ello, debemos pasar a falso el uso de _powerline_ y comentar (o borrar) las líneas de la configuración del _prompt_. # Use powerline USE_POWERLINE="false" # Has weird character width # Example: #  is not a diamond HAS_WIDECHARS="false" # Source manjaro-zsh-configuration if [[ -e /usr/share/zsh/manjaro-zsh-config ]]; then source /usr/share/zsh/manjaro-zsh-config fi # Use manjaro zsh prompt #if [[ -e /usr/share/zsh/manjaro-zsh-prompt ]]; then # source /usr/share/zsh/manjaro-zsh-prompt #fi eval "$(starship init zsh)" Ahora, reconstruimos la configuración y tenemos _starship_ en Manjaro con _Zsh_. source ~/.zshrc ## Archivo de configuración En general, la configuración por defecto es buena y no hay una necesidad de cambios fuertes. Sin embargo, el módulo de `gcloud` se muestra en general en la sesión lo cual no me es agradable y poco útil en mi caso. Por este motivo creo el archivo de configuración `~/.config/starship.toml` y deshabilito el módulo. cat << 'EOF' > ~/.config/starship.toml [gcloud] disabled = true EOF Puedes consultar otras opciones de configuración en Starship: Configuration. ## Referencias * GitHub: Starship * Starship prompt won’t work on manjaro KDE plasma. * Starship prompt for zsh - need help installing. * Powerline in manjaro-zsh-config. * Powerline. * Powerlevel10k.

Aprovechando que estoy en reinstalación por la transición de (X/K)ubuntu a Manjaro, les contaré sobre como conectar a una instancia de Cloud SQL en Manjaro. ## Google Cloud SDK ### Instalación de Google Cloud SDK Para la gestión de elementos de infraestructura, lo cual incluye la conexión a la base de datos, se requiere disponer de _Google Cloud SDK_. El proceso de instalación depende del sistema operativo, y ante inquietudes, siempre puedes remitirte a la documentación oficial. Manjaro Este paquete está disponible en el AUR, por lo cual se puede usar en Arch. pamac build google-cloud-cli --no-confirm Consejo Si no detecta el binario, puedes reiniciar cerrar y abrir la terminal. En mi caso solo me funcionó de esta forma, ni con **source** de `~/.zshrc` ni `~/.bashrc` funcionó. A pesar de esto, era detectado por **whereis** y **which**. Ubuntu echo "deb [signed-by=/usr/share/keyrings/cloud.google.gpg] https://packages.cloud.google.com/apt cloud-sdk main" | sudo tee -a /etc/apt/sources.list.d/google-cloud-sdk.list sudo apt-get install apt-transport-https ca-certificates gnupg curl https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key --keyring /usr/share/keyrings/cloud.google.gpg add - sudo apt update -q sudo apt install -y google-cloud-sdk ### Autenticación Google Cloud SDK Una vez se ha instalado, debemos autenticarnos para la gestión de proyectos y para el manejo de credenciales de aplicaciones. Si usas más de un navegador y separas tu perfil personal y laboral según el navegador, o usas múltiple perfil en el navegador, o incluso si es un escritorio remoto o un contenedor usado desde Windows y no puedes usar el navegador, recomiendo que la autenticación la gestiones copiando y pegando manualmente el enlace de autenticación (`--no-launch-browser`). Ambas autenticaciones requieren validar en navegador. gcloud init --no-launch-browser gcloud auth application-default login --no-launch-browser ## Cloud SQL Proxy ### Instalación de Cloud SQL Proxy Con el fin de crear el proxy de la conexión a la base de datos, en caso de requerir funciones de consulta y no de administración general, debemos tener _Cloud SQL Proxy_. Para mayor detalle puedes remitirte a la documentación oficial. Manjaro pamac build cloud-sql-proxy Ubuntu curl -o cloud-sql-proxy https://storage.googleapis.com/cloud-sql-connectors/cloud-sql-proxy/v2.14.1/cloud-sql-proxy.linux.amd64 chmod +x cloud-sql-proxy Este método válido para cualquier distribución Linux, dejará fijada la versión. ### Iniciar Cloud SQL Proxy Con el fin de crear la conexión a la instancia de base de datos, debemos iniciar el _proxy_ de la siguiente forma: cloud-sql-proxy <NOMBRE DE INSTANCIA> -p <PUERTO> Esto nos habilitará el acceso por `127.0.0.1:<PUERTO>`. Error 2024/12/10 16:36:44 Authorizing with Application Default Credentials 2024/12/10 16:36:44 Error starting proxy: error initializing dialer: failed to create default credentials: google: could not find default credentials. See https://cloud.google.com/docs/authentication/external/set-up-adc for more information 2024/12/10 16:36:44 The proxy has encountered a terminal error: unable to start: error initializing dialer: failed to create default credentials: google: could not find default credentials. See https://cloud.google.com/docs/authentication/external/set-up-adc for more information Este error corresponde a la necesidad de aplicar la autenticación de credenciales por defecto de aplicación que se describe previamente. ## Conectar a la base de datos En mi trabajo usamos MySQL, y aunque comencé usando *MySQL Workbench*, este no era muy cómodo y mis compañeros usaban {program}`dbeaver`. Este me pareció interesante y fue el que estuve usando hasta que conocí {program}`dbgate`. Estos dos se encuentran disponibles como *flatpak* para que los instales cómodamente en cualquier distro Linux, pero el caso particular de {program}`dbeaver` no se visualiza bien en Wayland cuando se instala de esta forma, por lo que es preferible la instalación del repo oficial. `````{tab-set} ````{tab-item} Manjaro :sync: manjaro ```{code} bash sudo pamac install dbeaver --no-confirm sudo pamac install dbeaver-plugin-office dbeaver-plugin-svg-format --as-deps --no-confirm pamac build dbgate-bin ````{tab-item} Flatpak :sync: ubuntu ```{code} bash flatpak install -y flathub org.dbgate.DbGate # Verificado flatpak install -y flathub io.dbeaver.DBeaverCommunity # No verificado ``` Un punto extra para no usar {program}`MySQL Workbench` es usar no solo un cliente moderno, sino también con soporte para múltiples bases de datos (no solo *MySQL*). ```{hint} En el pasado, he tenido conflictos con el uso de `localhost` como asignación del *host* en los clientes, y esto es que no siempre debe resolverse como `127.0.0.1`, por lo cual es mejor usar siempre en la configuración la IP. ```

If Wi-Fi starts to disconnect randomly and upon reviewing the list of networks, these have disappeared, there are some points to consider evaluating. * Disable “fast boot” de la BIOS: In Ubuntu, it doesn’t seem to be a current issue (it didn’t happen on this same machine with that configuration before, but there are older posts related to Ubuntu about this), but when moving to Manjaro or derivatives of Arch, this is a replicable problem. Make sure to disable ‘Fast boot’ in the BIOS. * Deisable Wi-Fi power saving: It’s common that the power-saving mode of the Wi-Fi card causes us to stop seeing available connections. Therefore, it’s necessary to create a configuration file that disables this feature and we have to restart. You need to create the file as an administrator. ## File: /etc/NetworkManager/conf.d/default-wifi-powersave-on.conf [connection] wifi.powersave = 2 These two adjustments were sufficient in my scenario, but it wasn’t clear that they should be both applied together. This was a mix of testing different solutions that reported success and testing the effects of combining them. For example, when I disabled “ _fast boot_ ”, I would always connect from the start, but the networks would disappear after a short while. If I only disabled power-saving alone, the networks would remain connected, but I would never get connected in the first place. It was only when both were enabled together that it worked. To provide context to my specific case, I’m running Manjaro KDE 24.1 with kernel 6.11. The network card is _Realtek_ , and the equipment is an ASUS TUF Gaming A15 FA506IV. Also, they often report that disabling MAC address randomization helps, but in my case, this test had no effect. ## File: /etc/NetworkManager/conf.d/wifi_rand_mac.conf [device] wifi.scan-rand-mac-address=no ## Diagnostic Information One of the key points to find when trying to solve your problems is to know information about your hardware and drivers. **Getting General System Information** For this specific issue, it can be useful to look at the _Network_ and _System_ sections, but don’t cut off the results if you post them on a forum. These utilities are not only helpful when the error is related to Wi-Fi, but also provide valuable information for other hardware problems. inxi --full --admin --filter --width **Getting Driver Information** At this point, we can detail the driver and its version, looking for mentions of “Network”. Manjaro sudo mhwd -l -li Ubuntu sudo lshw We can search for kernel diagnostic messages associated with the driver. Keep in mind the driver from the _Network_ section of `inxi`. In my case, it’s `r8169` and `rtw_8822ce`. sudo dmesg | grep r8169 sudo dmesg | grep rtw_8822ce

I recently decided to switch to Manjaro KDE (24.1) and I’m very happy with the change. So, taking this opportunity, I’ll share some things to do after completing the installation. Since I’m coming from a transition from Kubuntu (24.10) and Xubuntu (22.10), I’ll draw parallels with these steps, so it can also serve as a list of “what to do after installing Kubuntu 24.10”. Regarding many popular and traditional GUI applications, I don’t see a problem with using Flatpak environments if the native packages represent a problem or potential problem. For example, OBS doesn’t work if I install it natively, but it does in Flatpak. Moreover, if it’s available as a verified Flatpak, I prefer this over a package available in the AUR. I discuss this a bit more in “Distrohopping”: Switching Linux Distributions Without Losing Your Mind, as this allows me to adapt more quickly and compensate for some stability issues. ## Review the release announcements It’s important to review the release announcements, especially to be aware of potential conflicts and errors that we might encounter, as well as the options for handling the errors. For example, in the 24.1 release version that I had when installing, I encountered the following documented errors: * Manjaro KDE doesn’t shut down and the screen is left black with the pointer: The solution to this case is to go to “Desktop Session” and in the “Restore session” options, select “Start with an empty session”. * After suspension the system freezes: This happened to me, but after the general update it didn’t happen again, so I didn’t have a chance to test the solution. An extra detail, during the installation if you start with the NVIDIA proprietary drivers, your screen may turn gray. In my case, it was enough to wait a little longer for the process to resume normality (compared to what I observed when installing it in a VM and on the PC that doesn’t have a dedicated graphics card). ## Update repository mirrors This step is useful for ensuring that you download packages from the fastest and most up-to-date servers. In my case, the mirror I was using started to fail, and this process allows you to remove those that are no longer functional. sudo pacman-mirrors --fasttrack This step is not native to Ubuntu and presents a high level of complexity for the target audience of the distribution. ## Update the system Our package management tool on Manjaro is **pamac**. It’s an easy-to-use tool that doesn’t require extra effort to memorize the single-letter argument options of **pacman** , and shares similarities with **apt** from Ubuntu. We use `-a` to indicate that we also consider the AUR (Arch User Repository) source. This instruction updates both the package sources (official repository and AUR), not just the packages. The AUR is equivalent to the PPA (Personal Package Archive) on Ubuntu, but in a unified form, unlike the segmented approach by Ubuntu maintainers, which can lead to many more conflicts and configuration files. In general, for a rolling release distribution like Manjaro and its derivatives (Arch), it’s a good practice to frequently update the system to avoid accumulated updates conflicts. Manjaro pamac upgrade -a Also, you can use `update` instead of `upgrade`. This updates the entire distribution and not just the installed packages. Ubuntu apt update -q && apt dist-upgrade -y The first step updates the repository indexes (including PPAs) and the second step updates the installed packages themselves, including system changes that may not necessarily be related to the installed packages. For general package management from the repository, we are interested in knowing how to: * Install packages from the official repository, * Install packages from the Arch User Repository (AUR), * Remove packages. Manjaro sudo pamac install PACKAGE --no-confirm # Official Repository pamac build PACKAGE_AUR --no-confirm # AUR sudo pamac remove PACKAGE --no-confirm pamac search -a KEY pamac info PACKAGE There’s an interesting variant of package installation using the `--as-deps` flag to explicitly mark installed packages as dependencies rather than explicit installations. This means that when packages are removed that were previously installed for us, they will be marked as orphaned. While it might seem “irresponsible” to use the `--no-confirm` option, since it’s only used on the first installation of packages that have been validated beforehand, we’re fine with it. However, this must be done with caution and in some cases, it may require validation and even cancellation of the transaction. If you plan to update or add packages after your initial install, it might be a good idea to do so interactively as a check and then leave them for your routines without confirmation. I recommend not using this option at all and make your own decisions. When installing from the AUR, my recommendation is always to proceed without `sudo` unless we have context that doesn’t require a GPG key. Otherwise, this will be stored at an administrative level, causing errors of “ _broken pipe_ ”, which happens because the key needs to be stored in a common user. For example, this happens with services like Dropbox and Spotify. Ubuntu sudo apt install -y PACKAGE sudo dpkg -i PACKAGE.deb # After manually download sudo apt remove -y PACKAGE apt search KEY apt show PACKAGE On Ubuntu, installing from a PPA (Personal Package Archive) is similar, but it requires prior setup to add the PPA source. Occasionally, when installing from a _DEB_ package or from a PPA, common issues arise where dependencies aren’t met or aren’t resolved correctly. In such cases, **sudo apt install -f** needs to be applied at the end to fix these problems. ## Installs dependencies for package compilation When using different source repositories other than the official repository, you’ll need to have a set of additional dependencies that help facilitate this process. This would be equivalent to the `build-essential` package on Ubuntu. Manjaro pamac install base-devel --no-confirm Ubuntu sudo apt install -y build-essential curl git ca-certificates pkg-config It’s worth noting that the additional packages mentioned for Ubuntu are installed by default in Manjaro when used directly with `pamac`. As an alternative to package installation, Manjaro comes with Flatpak preconfigured, while Ubuntu also comes with Snap preconfigured. Manjaro Flatpak is ready to use. Ubuntu sudo apt install -y flatpak flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo ## Installs a stable kernel Use the latest available kernel in Manjaro, but it’s recommended to install a stable kernel (currently 6.6, but possibly 6.12 as well) at this time. This will be necessary if you need to upgrade your kernel and one of them breaks the system, requiring you to use an older one. Keep in mind that, as it happens with Manjaro, unstable kernel versions are removed from the repositories, so they can’t be reinstalled, leaving another risk. You can install a stable kernel using the Manjaro configuration manager with the “Kernel” option. Remember to edit the `/etc/default/grub` file to change the style and time out lines. The most important thing is the `menu` option in the style variable. GRUB_TIMEOUT=5 GRUB_TIMEOUT_STYLE=menu This way, we will have GRUB visible at boot and be able to use advanced options to change kernels. On Ubuntu, due to its stability, as the kernel is tightly tied to the distribution version, this is not a preventive step to consider, and it would only be useful if you require specific hardware support or a very particular feature. ## Protect your eyes Select a dark theme in the system. You can search for the menu option “Colors” and choose between “Breath Dark” or “Breeze Dark”. I prefer the first one. This selection has an impact on how long-term applications take into account the system theme. You can also search for the “Plasma Styles” option in the menu, and use “Breath”. If you’re using KDE Plasma like me, you can use the “Night Color” mode. You can adjust the location manually and configure the color temperature that you think is suitable. In my case, I use 4500K for daytime light and 3700K for nighttime. If you don’t use KDE, you can install RedShift, but keep in mind that this tool does not support Wayland. ## Enable numeric keypad at startup If you want the numeric keypad to be active from boot, we need to go to the numeric lock setting of hardware keyboard and select ‘Activate’. You can quickly access this option by searching for “Keyboard” in the menu. This is environment-dependent, so if you don’t use KDE Plasma, I recommend checking the documentation of Arch: Activating numlock on bootup directly. ## Prepare your documents During Manjaro installation, we have the option to choose between LibreOffice and OnlyOffice as an office suite. My preference is for LibreOffice, but since the installed package is not the latest version, I skip it and install it now. Additionally, there are times when we need a compatible alternative with Office, which occurs in my case due to work-related reasons with Excel, and I need to use WPS. There were two issues that affected me and was useful the Arch documentation on WPS Office: Troubleshooting. Manjaro sudo pamac install libreoffice-fresh --no-confirm sudo pamac install --as-deps libreoffice-extension-texmaths --no-confirm pamac build wps-office-bin ttf-wps-fonts libtiff5 --no-confirm Ubuntu In the case of Ubuntu, this comes with LibreOffice pre-installed. And to install WPS, you will need to download the manual _DEB_ file from its website and install it using **dpkg**. Atención With a dark theme, LibreOffice icons may not have good visibility by default. To fix this, go to “Tools > Options” and in the “View” section, evaluate which option suits you best. In my case, I chose “Breeze (SVG + Dark)” ## Password storage When applications start asking to create a wallet (_kdewallet_), we will accept it with _blowfish_. Additionally, if the password is the same as our login, this will be automatically activated. ## Instala Google Chrome Both in Manjaro and Ubuntu, we will have Firefox as our default browser, but it’s essential to note that Google Chrome becomes necessary many times. Manjaro pamac build google-chrome --no-confirm Ubuntu wget https://dl.google.com/linux/direct/google-chrome-stable_current_amd64.deb sudo dpkg -i google-chrome-stable_current_amd64.deb sudo apt install -f This will leave configured the required PPA (Personal Package Archive) for updates. Remember to synchronize your account in both browsers. ## Synchronize your files There are multiple options for file synchronization, but undoubtedly Dropbox remains a common service among many of us as it offers a free hosted alternative with Linux desktop client support. Manjaro pamac build dropbox --no-confirm Ubuntu wget -O https://www.dropbox.com/download?dl=packages/ubuntu/dropbox_2024.04.17_amd64.deb sudo dpkg -i dropbox_2024.04.17_amd64.deb This will leave configured the required PPA (Personal Package Archive) for updates. After installation, start using it. At this point, we go to the session manager of Dropbox and can link our account. ## Ready to chat We don’t just chat on our mobile devices, so it’s good that we have options on our PC. I use Telegram for personal reasons, and Discord and Slack for work-related purposes. Manjaro sudo pamac install telegram-desktop discord --no-confirm pamac build slack-desktop --no-confirm Ubuntu flatpak install flathub org.telegram.desktop flatpak install flathub com.discordapp.Discord sudo snap install slack ## Take screenshots KDE has a very good and sophisticated screenshot tool (_Spectacle_), but I find that it also overflows for quick use. For this task, I prefer _Flameshot_ typically. Manjaro sudo pamac install flameshot --no-confirm Ubuntu sudo snap install flameshot ## Ready for creativity To write an entry on our blog, our thesis project, a lab report, executive report, marketing presentation, our process flow diagram or code diagram, we need to do drawings, diagrams, videos, format conversions or basic edits. That’s why here is our creative combo. * _ImageMagick_ : Useful for converting image file formats. * _FFmpeg_ : A command-line utility for audio and video processing. * _OBS Studio_ : An advanced tool for recording and editing video. * _Draw.io_ : Allows creating diagrams and offers a wide range of symbols. * _Inkscape_ : A vector drawing tool, an alternative to Corel Draw. * _GIMP_ : A painting and bit-map editing tool, an alternative to Photoshop. You can also explore _Krita_ (keep in mind that files with the `.csv` extension are associated with this). If you need to edit, it’s recommended to use **gimp** , and if you want to draw, **krita**. Manjaro pamac install imagemagick ffmpeg drawio-desktop inkscape gimp krita --no-confirm flatpak install -y flathub com.obsproject.Studio Ubuntu sudo apt install -y imagemagick ffmpeg sudo snap install drawio flatpak install -y flathub org.inkscape.Inkscape flatpak install -y sflathub org.gimp.GIMP flatpak install -y flathub org.kde.krita flatpak install -y flathub com.obsproject.Studio During my installation with _pamac_ , I had problems with OBS and this motivated me to use _flatpak_ in general for various cases and thus avoid managing optional dependencies or some controller issues. In this particular case, OBS generated problems with `DeckLink` that is related to the `libva-vdpau-driver` controller. According to the error message, it couldn’t find the installation and therefore couldn’t configure virtual cameras, although the controller was installed. This is a common issue, according to forums, but I didn’t find anything that helped solve it. ## Leisure time My entertainment 3-in-1 combo is Spotify, Stremio, and Steam (in that order of use). Spotify has become my go-to option for passing the time while working from home and in the absence of other sounds, I need to have at least some music or a podcast. Stremio is my alternative to streaming services (Watch free movies with Stremio) and on Steam, I have good times with my collection of video games and retro games. Manjaro sudo pamac install steam --no-confirm pamac build spotify --no-confirm flatpak install -y flathub com.stremio.Stremio Ubuntu flatpak install -y flathub com.valvesoftware.Steam flatpak install -y flathub com.stremio.Stremio sudo snap install spotify ## Now look at the sky A small bonus for astronomy enthusiasts. The installation of the planetarium software Stellarium and a 3D universe visualization tool, Gaia Sky. flatpak install flathub org.stellarium.Stellarium flatpak install flathub de.uni_heidelberg.zah.GaiaSky

Vengo de dos cambios de distribución Linux recientes, y eso me hizo pensar un poco en el esfuerzo asociado y en como ese esfuerzo se puede reducir. Igualmente, recordé el concepto asociado de “ _distrohopping_ ” y las discusiones alrededor de esta práctica, en la cual muchos terminan afirmando que realmente es perder el tiempo y que aporta poco valor, pero yo no lo veo así y quiero compartirles el valor que le veo y el cómo facilitarlo. ¿Qué he probado antes?: Mandriva (descontinuada), Open Suse, Ubuntu, Debian, Antix, Lubuntu, Antergos, Arch, Gentoo, Funtoo, Linux Mint, Xubuntu, y ahora Kubuntu y Manjaro KDE. En cuáles he tenido periodos estables de años: Ubuntu, Lubuntu, Linux Mint y Xubuntu. La transición este año a Kubuntu me enamoró de KDE y se convierte en mi escritorio (_DE_) favorito. ## ¿Es buena idea hacer _distrohopping_? Encontrarás muchos motivos para hacer _distrohopping_ , lo interesante de lo novedoso y querer probar la distro de la cual todos hablan, o el nuevo gestor de paquetes que va a revolucionar la instalación, el mejor manejador de controladores privativos, tener la distro que te permite usar todo el beneficio de tu último computador o accesorio, o incluso motivos asociados a aumentar más tu conocimiento y experiencia sobre el mundo Linux y las distribuciones, o generar contenido variado sobre todas las opciones disponibles, o condiciones laborales como la distro en la cual se encuentran los servidores del servicio que ofrecen en tu trabajo como desarrollador. Cada una de estas, encontrarás un foro o blog que la discute, y probablemente te terminará indicando que perdiste el tiempo y que eso no generó valor para ti, y te recomiendan que omitas la experiencia porque ellos en sus muchos años de _distrohopping_ concluyen que no necesitas probar de todo, sino solo escoger una desde el inicio que se ajuste a tu necesidad y quedarte allí. ¿Pero sabes algo? A ellos saber lo que buscaban y que eso existía les tomo años. El _distrohopping_ es exactamente lo que hacemos cuando no sabemos muy bien lo que necesitamos ni lo que existe para escoger, así que empezamos a probar. Y así como sucede con el _smartphone_ , el _smart tv_ , el apartamento que tomas en alquiler, el carro que compras o incluso el PC que compras, tus gustos y necesidades cambian, haciendo que la decisión que tomaste ya no sea la mejor, y está bien cambiar. Cuando te enamoras de una distribución Linux, vas a considerar que nunca fue necesario el _distrohopping_ y que no te sirvió para lo que llegaste a descubrir, pero es una gran mentira. Tienes los elementos de comparación porque te atreviste a probar, sabes que existía la distribución que elegiste porque buscabas opciones cada que encontrabas detalles que no te agradaban de la actual. Pero así como en los enamoramientos de parejas, también perdemos el amor porque nosotros no somos los mismos siempre, y las distribuciones Linux tampoco. Cambian continuamente aprovechando las revoluciones tecnológicas o por sus definiciones necesarias para el autosostenimiento o _marketing_. Incluso, las comunidades alrededor pueden cambiar y afectar la distribución. Así que, adelante, es bueno hacer _distrohopping_ , pero no te voy a mentir, quienes afirman que es mala idea, tienen un punto importante, y es el esfuerzo mental y físico que implica la transición. Así que, enfocaremos en como hacer _distrohopping_ reduciendo el impacto. ## ¿Qué me aporta hacer _distrohopping_? Voy a detallar un poco esto, aprovechando los puntos que justamente terminan detallando en muchos blogs sobre porque el _distrohopping_ no aporta, y finalizar con lo que a mi parecer, sí aporta. ### Aprender más sobre Linux: No No seremos románticos, el _distrohopping_ no te aporta nuevo conocimiento. Realmente si quieres aprender, lo puedes hacer en cualquier distribución, solo debes enfrentar los problemas en la forma difícil (toma el _hardway_ de cada cosa que consideres). Ejemplo, no uses mucho los elementos gráficos, los botones u atajos, usa más comandos de la consola, y así obtendrás mayor aprendizaje. No siempre instales el software desde repositorios, de vez en cuando, anímate a instalarlo mediante compilación o desde un directorio comprimido. No uses la casilla de verificación o el cuadro de texto de un cuadro de diálogo para modificar una configuración, busca el archivo de texto plano asociado a dicha configuración (si existe, en KDE Plasma y Wayland me he encontrado muchas cosas que si existen en un archivo de configuración, probablemente no están documentadas y definitivamente toca por los cuadros de diálogo o opciones de la barra de tareas, porque ni siquiera un comando asociado). Lo que aprendes en una distribución específica, son justamente herramientas específicas de la distribución y que por ende dicho conocimiento no es universal o replicable, y no te será útil si cambias otra vez de distribución o si tu amigo que usa otra distribución te pide ayuda. ### Mejor rendimiento del equipo: No Tampoco nos aporta mayor rendimiento del equipo. En general el rendimiento lo va a otorgar el _hardware_ , el _software_ para una tarea específica y el nivel de depuración que tengamos. Todo esto se puede hacer actualizando el equipo, cambiando el software usado para una tarea o depurando procesos que se activan que no son necesarios, y desinstalando muchos paquetes preinstalados (o que instalamos creyendo que algún día usaremos). ¿Y qué sucede si nuestro equipo es viejo? En el _hardway_ puedes hacer todo esto sobre cualquier distribución Linux. Así que, claramente tendrás mayor rendimiento si editas video con software que acelera con GPU así es solo basado en CPU, o tu código Python ejecutará más rápido si te pasas a Python 3.12 en lugar de continuar en Python 3.9, y tu sistema operativo arrancará más rápido y tendrás un inicio de activa más fluido si desactivas Dropbox y Discord del inicio de sesión. Esto no va a cambiar por pasarte de Ubuntu a Arch. Fíjate en que muchas veces acumulamos mucha caché o temporales, esto también requiere limpieza. Si quieres mejor rendimiento debes aprovechar las optimizaciones que hacen en versiones más actualizadas del software que usas (ejemplo, Python 3.12 ofrece soporte experimental de JIT y del modo no GIL, que no existen en 3.9), o de un software alternativo que optimiza el flujo que deseas más rápido (ejemplo, pasar tu análisis de datos de Pandas a Polars o FireDucks). O considera si estás en el límite de lo que otorga tu equipo si lleva varios años. Y sobre todo, pon mucha atención en los servicios que se activan durante el arranque. Aprovecha los gestores de limpieza, paquetes y procesos de tu distribución, o usa un software de optimización y monitoreo como Stacer. ### Software actualizado: No Es claro que existen distribuciones con software más actualizado, esto es la diferencia que se ofrecen entre los modelos de liberación continúa (_rolling release_), liberación periódica (_fixed release_ o _point release_) o las liberaciones de soporte largo (LTS). Si deseamos algo muy nuevo, la preferencia sería una liberación continúa, pero su estabilidad puede estar comprometida. Si queremos mayor estabilidad, usaremos una LTS, pero fácilmente esto implica retraso de años en el uso de nuevo software o de mejorar soporte de hardware. Un punto intermedio son las liberaciones periódicas (que acorde al compromiso con la estabilidad de las distribuciones, algunas periódicas pueden ser más o menos lentas para actualizar paquetes, ejemplo, Ubuntu es lenta). Sin embargo, los repositorios oficiales no son el único mecanismo para tener software actualizado. Puedes usar fácilmente _snap_ si estás en Ubuntu o derivados (en otras distribuciones puede no ser tan natural) o _flatpak_ (la cual en algunas distribuciones viene preinstalado, o instalarlo). También puedes usar los AppImage que no implican instalación en el sistema (es un tipo de aplicación portable para Linux), aunque estas no poseen un repositorio centralizado de gran tamaño, entonces se vuelve una gestión manual cada AppImage. Estas opciones no solo te permiten obtener las últimas versiones (si son las versiones oficiales), sino también omitir problemas asociados a dependencias. Ejemplo, en Manjaro en mi equipo con tarjeta gráfica NVIDIA tengo problemas para instalar OBS Studio con _pamac_ por una dependencia (aclaro la tarjeta gráfica porque el problema no es replicable si lo instalo en un equipo con tarjeta gráfica integrada), pero si uso _Flatpak_ lo tengo funcional sin problema. También existen opciones de instalación simples de usar a través de los gestores de paquetes de los lenguajes de desarrollo en los cuales se implementaron. Ejemplo, puedes instalar el emulador de terminal Alacritty en su última versión con _cargo_ (Rust) o instalar la utilidad de descarga de videos _YT DLP_ con _PIP/UV_ (Python). Y como siempre, está el _hardway_ , puedes descargar el archivo _tar.gz_ que muchos suministran (ejemplo, Dropbox, y así evitar el PPA en Ubuntu) o descargar el código fuente desde un sitio web o repositorio GitHub y manejar las dependencias de compilación. ### Consistencia filosófica (fanatismo o purismo incluido): No Muchos cambian o escogen una distribución por consistencia filosófica. Pero esto realmente tampoco lo otorga. Si no quieres software privativo, puedes desinstalarlo y buscar las alternativas, y luego instalarlas. Si no estás de acuerdo con el uso por defecto de Firefox como _snap_ en Ubuntu y de otros paquetes, puedes desinstalar el software, bloquear el redireccionamiento a _snap_ de los gestores de paquetes o tienda de software, y luego volver a instalar ya con la versión _DEB_ (has logrado el _desnapping_ de Ubuntu). Quieres tener la libertad de elección, puedes desinstalar cualquier componente e instalar la componente que te haga sentir bien. La consistencia filosófica o purismo lo puedes alcanzar a través de acciones específicas sobre la distribución. ### Comodidad y facilidad (ley de mínimo esfuerzo): Sí Esto es lo realmente importante cuando escogemos un producto y servicio, y aplica cuando seleccionamos una distribución Linux. Debe ser cómodo para nosotros, no para los demás, debe ser fácil para nosotros, no para los demás. Queremos que las actividades de nuestro día a día se hagan de una forma placentera, que los tipos de inconvenientes se solucionen fácilmente y que las labores de volver a montar la distribución desde cero si cambiamos de equipo o si nos vemos en la necesidad de reinstalar, nos tome poco tiempo. Pero estos detalles son detalles personales que se ajustan a la expectativa, necesidad y experiencia de cada usuario, y estos elementos cambian en nosotros a lo largo del tiempo, así como lo que encontramos en las distribuciones. Esto hace que todos los puntos que anteriormente indiqué que eran posibles en el _hardway_ se cumplan en un _easyway_ cuando cambias de distribución Linux. Cada distribución Linux está diseñada para un tipo de usuario y fin específico, y por ende ese enfoque se encuentra natural y optimizado. Pero hay tanta variedad de usuarios y fines, que por ende, la variedad de distribuciones Linux también es igual de amplia y saber la existencia de aquella que se ajusta como amor a primera vista, como pareja perfecta, nos puede tomar años (para luego cambiar de intereses e iniciar un nuevo proceso de búsqueda). El problema es que este proceso de transición entre nuestro anterior amor y el nuevo amor, en las distribuciones Linux, tiene un alto costo. ## Facilita la transición: _distrohopping sano_ Lo que no es habitual encontrar en las publicaciones sobre _distrohopping_ es el modo fácil de hacerlo. Incluso una vez leí sobre como hacer _distrohopping_ fácil, y el enfoque fue en las distribuciones que “permitían” esto (de alguna forma, distribuciones sencillas de usar). Pero si queremos probar incluso las distribuciones difíciles, ¿hay una forma sana y simple de hacerlo? ### Evalúa tus necesidades El primer punto que voy a resaltar, es que debemos tener clara la necesidad del cambio. Esto nos permite saltar a una distribución con una evaluación previa de lo que vamos a encontrar y de las capacidades que se requieren para ello. Estas necesidades debemos tener presente que no se trata solo de las necesidades no satisfechas, sino también de las necesidades ya satisfechas, ya que de otra forma tenemos una alta probabilidad de hacer un salto perdiendo algo necesario. En mi caso, mis necesidades no satisfechas son: * Disponibilidad de software nuevo (en esencia, del ecosistema de alternativas en Rust): Las podría instalar mediante compilación con _cargo_ , pero esto aumenta el tiempo de la instalación total, en algunos casos la compilación genera alto esfuerzo en el equipo y comienza a calentarse mientras lo uso, y su integración en el sistema no es simple. * Disponibilidad de software actualizado: En el software popular, típicamente con GUI, no tengo problema con encontrar opciones en Flatpak que sean oficiales o con buen soporte, y que dispongan toda la funcionalidad. Sin embargo, para usos avanzados me ha pasado que software con GUI en paquetes Flatpak o Snap no exponen todas las opciones de utilidades de línea de comandos, o que por el nivel de aislamiento no se integran adecuadamente o incluso no pueden conectar con otros servicios del sistema operativo. En mi experiencia, también he visto mucho problema con las utilidades de línea de comandos o con elementos que requieran notificaciones u otros monitoreos de su actividad. * Libertad de elección en el mecanismo de instalación: Como usuario de Ubuntu y derivadas, mi Firefox está en _snap_. Pero muchos paquetes están vinculados _snap_ y esto no es claro al momento de decidir la instalación y debido a lo que no exponen al ser _snap_ a veces he tenido problemas. Igualmente, con los _snap_ ya he tenido problemas de inicialización que no suceden con sus versiones del repositorio oficial o incluso el equivalente en _flatpak_. Pero el bloqueo de _snap_ puede tener el riesgo oculto de generar otros fallos de integración de los cuales Ubuntu espera tener el _snap_. Y mis necesidades satisfechas: * Software y controladores privativos: Sin duda, con derivadas de Ubuntu tengo una buena experiencia a este nivel, ya que al tener la comunidad más grande, es la comunidad en la cual más se enfocan las empresas al generar versión oficial. Ejemplo, mi experiencia con NVIDIA solo ha sido buena en Ubuntu y derivados (y esto me impacta en el uso de Wayland también). * Estabilidad: Si bien tengo experiencia en Linux y con conocimientos de nivel medio o avanzado, no quiero tener que solucionar problemas continuamente, y tener el temor a cada actualización o instalación. * Excelente documentación o comunidad: En caso de tener problemas, o querer validar información previa a probar algo, o consultar como se hace algo, quiero disponer de buenas opciones para consultar o preguntar. Esto se logra con una buena documentación del proyecto o con una comunidad muy activa o de buen tamaño. Y por último, unas que me generan sentimientos encontrados: * Soporte de _hardware_ : En Ubuntu y derivados, esto ha sido un problema cuando cambio de equipo (generalmente, equipo nuevo). El periodo de transición para poderlo usar me toca típicamente quedarme en Windows porque el núcleo que viene no es muy actualizado, y por ende no soporta el procesador, o los controladores privativos no están actualizados. En general hay un buen soporte, pero hay que esperar hasta la siguiente liberación periódica (6 meses). Cuando he probado otras distribuciones en modelos de liberación continúa tras los cambios de equipo, tengo ese soporte, pero típicamente perdía el sistema a los días o semanas, o el tiempo demandado en procesos de instalación era alto. * Software preinstalado acorde a mis actividades: Esto no debe ser un criterio principal porque si es fácil instalarlo, lo puedo hacer, pero sin duda, si hay software preinstalado puedo empezarlo a usar más rápido. Además, esto evita tener que configurar la integración de estos paquetes. Es importante que en el proceso, tengamos claro en las necesidades, cuáles son sacrificables. En mi caso, puedo perder un poco la libertad de elección del mecanismo de elección si esta me favorece, y perder los controladores y software privativo, si dispongo de alternativas. Con estas necesidades claras, es posible indagar un poco en los foros, blogs y DistroWatch, los posibles candidatos. Algunas conclusiones en el caso de mis necesidades: * Distribución con modelo de liberación continuo: Me permite disponer de software nuevo y actualizado, y estoy dispuesto al monitoreo de información y ajustes que puede venir de algo de inestabilidad. Para compensar, se puede usar fuentes de _flatpak_ para los software GUI, con muchas dependencias o que poseen fuentes inestables en el gestor tradicional. Así como usar PIP/UV, Pixi o Cargo para algunos paquetes cuyo uso principal sea en desarrollo en lugar de uso general. Esta forma de compensar ayuda a facilitar también el _distrohopping_ , pues independiza la instalación de muchos paquetes del gestor de paquetes específico de la distribución. * Evitar modelos de liberación inmutables o derivados de Ubuntu (excepto Linux Mint): Los casos inmutables recurren continuamente a usar opciones tipo aislamiento (_sandboxing_) como los _flatpak_ , _snap_ o _AppImage_ para las aplicaciones de usuario. Esto no solo reduce la libertad de elección, sino el conjunto de aplicaciones disponibles. Ubuntu se descarta por su tendencia a usar _snap_ por debajo de _apt_. * Evitar distribuciones FOSS: Una distribución FOSS (como Fedora) no permite fácilmente ni soporta software privativo. Esto es un problema fuerte para el soporte de hardware como tarjeta gráfica NVIDIA o algunos controladores de WiFi, o incluso la ola de _machine learning_ que hace uso de CUDA. Esto descarta una distribución como Fedora. * Entorno de escritorio KDE: Algo que con el tiempo me ha pasado, es que he usado cada vez más software asociado a proyectos de KDE, también es común que muchos otros paquetes que uso se basan en Qt que es la base de KDE. Y en aplicaciones base, que normalmente uso poco, igual el conjunto base de KDE es más sofisticado (ejemplo, su herramienta de captura de pantalla y los gestores de configuración). El proyecto KDE posee una distribución basada Ubuntu llamada Neon, y acorde a múltiples sitios las mejores experiencias en KDE se han percibido en Kubuntu, lo cual pueden ser dos buenas opciones en caso de mantenerse en las familias de Ubuntu. * Distribuciones bien documentadas y de comunidad activa: En mi apreciación, esto es un punto fuerte de las distribuciones Arch y Ubuntu, y por extensión a sus derivadas. * Distribuciones con repositorios extensos: Si quiero que algunas de mis actividades diarias estén cubiertas en paquetes preinstalados o que en su defecto, se instalen fácilmente, lo mejor es depender de distribuciones con repositorios extensos. En este punto, pero solo como deseo y no un criterio firme, favorecemos nuevamente a Arch, Ubuntu y sus deivados. Ejemplo de elementos mínimos, debería tener LibreOffice y Firefox en lo preinstalado, y no otros procesadores de texto y navegadores. Una sorpresa es que Manjaro incluye git, y esto me sirve hasta para sincronizar mis _scripts_ para instalación. ### Ten presente los problemas comunes Hay cuatro grandes padecimientos en Linux para los cuales debes prepararte y validar antes del cambio. * WiFi: Fácilmente, es lo que más vas a romper con los cambios de distribución o posterior a una actualización de núcleo o de versión de controladores. He tenido equipos en los cuales el WiFi funciona perfectamente en las versiones _live_ , pero al instalar ya la distribución, el controlador no es soportado directamente, o al actualizar el núcleo la versión del controlador no está compilada para dicho núcleo y es necesario ajustar manualmente el _header_ del código fuente y compilarlo. En otros casos como me ocurrió en el reciente cambio a Manjaro, el WiFi empezó a perder las redes disponibles aleatoriamente después de actualizar el núcleo y fue necesario ajustes en BIOS y en archivo de configuración del controlador. Ten disponible una conexión cableada de red. * Tarjeta gráfica NVIDIA: Definitivamente, un gran dolor si requieres el máximo aprovechamiento. En Wayland esto es una limitante en múltiples distribuciones, pero si es realmente importante para ti, probablemente un derivado de Ubuntu sea lo mejor. Algunos software que usan aceleración de video por GPU también se pueden ver afectados y sea conveniente omitir la aceleración, usar una versión _sandbox_ o esperar unos meses que el soporte se logre (en mi caso, espero que la rama de NVIDIA 560 llegue pronto a _Manjaro Stable_). Esto me afecta parcialmente la experiencia en Wayland y de aplicaciones que usan para el renderizado Vulkan (como Zed), pero mientras uso la versión KDE X11 en este equipo y el equipo con tarjeta integrada funciona sin problema Wayland. En algunos casos, el problema puede ser tener una pantalla completamente negra o errores de visualización continuamente si el controlador no se soporta adecuadamente (nada funcional). Valida el soporte de tu tarjeta NVIDIA con las versiones de los controladores disponibles y de la integración de Wayland. * Procesadores (o hardware en general) nuevos: Si la distribución no es de liberación continua, la versión del núcleo no será la necesaria para soportar un equipo de última generación, contrario a lo que sucede con tu Windows preinstalado. Valida si tu procesador es soportado en la versión del núcleo de la distribución a probar. * Software privativo: A veces no podemos simplemente buscar una alternativa, porque esto no compensa que debemos interactuar con otras personas. Si esto es algo importante, ejemplo, para fines laborales o de estudio, seguramente tu transición debe implicar seguir con el uso de Windows o alternativas para las cuales haya versión oficial. Valida si el software existe para la distribución. ### Crea un entorno de pruebas o un plan de respaldo Sin duda, las cosas pueden fallar si haces un cambio radical de distribución, como cuando se cambia de familia de distribución. Por este motivo, es bueno ir con pequeños pasos seguros como: * Empieza pruebas con una máquina virtual: Puedes usar QEMU-KVM o VirtualBox. Esto te ayudará al primer acercamiento de instalación del sistema operativo, explorar rápidamente el entorno de escritorio y el flujo de adecuación inicial como instalar el software que sea más importante para ti y verificar que funciona adecuadamente. Prueba así unos días para ver la estabilidad, pero esto no es una victoria, debido a que en la emulación no tienes el mismo hardware. * Al pasar al hardware real, sería preferible mantener una partición para el nuevo sistema mientras que conservas otra para la anterior. En caso de fallo, puedes retomar tu trabajo y actividades en la distro anterior. * Documenta o crea _scripts_ de los pasos realizados. Esto será importante cuando requieras de una instalación desde cero nuevamente o replicar en otra máquina. * En la medida que ya sea tu distribución diaria, crea respaldo de tus datos (documentos y otros archivos personales), así como de archivos de configuración. Aprovecha servicios de sincronización como Drive, Dropbox o GitHub. También puede ser mantener copias en un disco externo o tener una partición para el directorio `/home`. * Considera tener un núcleo estable instalado en las distribuciones de liberación continúa. De esta forma, puedes pasar a este núcleo en caso de fallo. ### Crea una transición uniforme **Instalación de paquetes** Una opción rápida para enfocarte en los verdaderos problemas que pueden existir en la distribución que has escogido, es depender menos del gestor de paquetes de la distribución. Esto te permite documentar o tener _scripts_ que serán replicables en un eventual nuevo cambio y a reducir el impacto de buscar como adecuar tu sistema. **Entorno de escritorio** Explora los entornos de escritorio en la distribución Linux que ya usas. Esto te facilitará explorar el comportamiento visual y de las herramientas de gestión generales y aplicaciones básicas con bajo esfuerzo y bajo riesgo. Una vez tengas claro el entorno de escritorio, busca la nueva distribución con este entorno de escritorio. En mi caso, pude explorar KDE a través de Kubuntu (variante de Ubuntu) y así notar que se ajustaba a mi interés por sobre otros entornos. Luego, esto me lleva a solo evaluar respecto a las distribuciones que tengan soporte adecuado de KDE. **Internet cableado y WiFi** Recuerda que ante posibles problemas del controlador de WiFi, siempre es bueno poder contar con una conexión cableada. ## Despedida Espero que esto te ayude a lanzarte a tu nueva aventura en Linux con confianza. Actualmente estoy usando Manjaro KDE y estoy encantado con las configuraciones y aplicaciones predefinidas de KDE. ¡Es como tener un escritorio personalizado listo para usar desde el primer momento! Además, tener git y flatpak preinstalados es una gran ventaja. ¡Disfruta tu viaje por las distros!

Tired of streaming subscriptions draining your wallet? Perhaps not, but I’ll share a trick to comfortably, safely, and freely access a lot of content. I’ll be talking about Stremio and an extension that pulls content from torrents. ## Stremio Stremio is a multimedia content aggregator that allows you to search for providers to play the content you’re interested in. This provider search is done through an extension system for different services (you can link your streaming accounts like Netflix, Disney+, Prime Video, Apple TV) to have everything unified in a single multimedia hub. Because it’s based on extensions, you can also get extensions to play content from torrent indexes, giving you access to free and safe content. It’s also available for Linux, Mac, Windows, Android, and even Web. While Stremio can run without an account, creating one is important. This allows you to synchronize not only what you watch, your watchlists, and progress, but also installed extensions. This is key for using Stremio with the torrent extension on your mobile or TV. Linux On Linux, you can easily install the package with the official Flatpak version. flatpak install -y flathub com.stremio.Stremio Windows On Windows, the traditional .exe installer is available. ## Torrentio The magic for watching free movies and series comes from an extension that lets you play torrent content in Stremio and has several torrent servers available. I’ll highlight _The Pirate Bay_ , _Torrent Galaxy_ (for English content), _Cinecalidad_ (for Latin American Spanish audio), _Mejor Torrent_ (for Spanish audio), and _Nyaasi_ (for anime). To install Torrentio, use this link, which has the configuration I recommend. The special features of this configuration are: 1. _Providers_ : We exclude _Rutor_ , _Rutracker_ , _Comando_ , _BluDV_ , and _Torrent9_. Excluding these removes content primarily in Russian, Portuguese, and Italian, leaving content in English, Spanish, and Japanese (anime). 2. _Sorting_ : We apply _By seeders_ , prioritizing content that will potentially play best. If there are few seeders, playback might be problematic, especially with large files, but sometimes there are surprises, so you can try even with few seeders. 3. _Priority foreign language_ : _Spanish_ and _Latino_. This prioritizes content in Spanish, following the seeder sorting and then again by seeders but in any other language. Usually, the declared language corresponds to the available audio language. 4. _Exclude qualities/resolutions_ : _CAM_. You don’t want to watch this content. These are recordings made with a camera over a cinema or home playback. The image and audio are terrible. If you want to modify anything, go ahead, and then click the _INSTALL_ button. In my experience, there’s a good chance of finding popular content in both Latin American and Spain Spanish, but it’s always best to be willing to watch content in English for reliable and smooth playback. Thanks to the OpenSubtitles v3 and OpenSubtitles extensions (both official), we have a repository of subtitles for our content, even if they aren’t embedded (embedded is much better). ## Installing on TV Stremio and its extensions work on Android, so you can use this not only on your mobile but also on your Android TV. As I previously mentioned, it’s important that you’ve created a Stremio account because there’s no login form on TV, and you’ll have to use a login link or QR code to access it from your mobile or computer. Installation is the best option, but if Stremio isn’t available for your TV, you can also cast from your mobile or connect your computer or mobile via cable to the TV. ## Extra: Pluto TV This isn’t exactly a good alternative to replace your streaming subscriptions, but you’ll find good free content in Latin American Spanish. If you create an account, you can opt for progress sync options. Pluto TV is available on the web, Android, and iOS.

Recién mi novia me pidió el favor de ayudarle a descargar los videos de un curso antes de que se venciera el acceso a la cuenta, y tocaba descargar los videos de Vimeo. Pero el truco de descarga de estos videos, hace que luego toque unir el audio y el video, así que les contaré como hacerlo con FFMPEG y Bash. ## Descargar video de Vimeo Bueno, este es el punto inicial de la aventura, y es cómo descargar un video de Vimeo a través de un sitio que posee autenticación. Resulta que si fuera directamente de Vimeo, bastaría con la extracción con uso de _cookies_ que ofrece yt-dlp, pero como el video de Vimeo está embebido en otro sitio, esto no funciona (o no encontré cómo, pues salía un error de portal no reconocido para hacer el ingreso). Al continuar la búsqueda, la única opción que encontré fue una extensión de Chrome que se llama Free Vimeo Downloader, que te habilita la opción de descarga desde el navegador de los videos de Vimeo embebidos en cualquier portal. Te ofrece la opción de descargar los videos en distintas calidades, aunque debes tener presente que el audio se descarga por separado, y para poderlo descargar debes primero iniciar la reproducción. Atención Recuerda reproducir el video para habilitar la descarga del audio. Los archivos descargados tienen como patrón, el nombre del video seguido de la calidad de video, y en el caso del audio, seguido de `-audio`, ambos en formato MP4. Ahora, ¿cómo unimos el video y el audio? ## Procesamiento con FFMPEG Ahora, la tarea asociada al procesamiento para unir los archivos de audio con los archivos de video, la vamos a delegar en FFMPEG, una potente utilidad de línea de comandos para el procesamiento de audio y video que es gratuita y de código abierto. Si usas Debian/Ubuntu o algún derivado, como yo, puedes instalar de la forma que indico a continuación. Si no, puedes remitirte a la página oficial o también instalarla con el gestor de paquetes de conda (aplica a todos los sistemas operativos). sudo apt install -y ffmpeg Para probar el concepto, usaremos uno de los pares de archivos. ffmpeg -i Modulo\ 2\ Clase\ 2\ Parte\ 5\ \(720p\ with\ 30fps\).mp4 -i Modulo\ 2\ Clase\ 2\ Parte\ 5-audio.mp4 -c copy output/Modulo\ 2\ Clase\ 2\ Parte\ 5.mp4 Como el audio y el video ya están en el mismo formato y codec, no es necesario FFMPEG para aplicar transformaciones, sino solo para mantener el canal de video del primer archivo y copiarle el canal de audio del segundo, para generar un nuevo archivo de multimedia. Observamos el parámetro `-i` que usamos para indicar un archivo fuente, ya sea de audio, video o incluso imágenes y de texto. En este caso, lo usamos para indicar el archivo de video y el archivo de audio que queremos emparejar (cada archivo debe estar precedido de `-i`). Si fuera necesario aplicar un _codec_ a estos, se debería indicar la opción respectiva después de la ruta de cada archivo. En este caso, no nos interesa y esto nos ayuda a que ejecute más rápido. De tal forma que simplemente indicamos después del segundo archivo `-c copy` para indicar que se copia directamente, preservando calidad y formato original. Por último, se indica la ruta del archivo de salida, es decir, el archivo resultado de nuestra unión de video y audio. Consejo FFMPEG y su documentación, no es muy cómoda para alguien que no sea familiar con la línea de comandos, por lo que si tienes dudas de donde empezar, te recomiendo visitar los recetarios de ffmprovisr. Podemos abrir el video, y veremos que el video con el audio incluido. Y ahora, ¿qué sucede si son 56 videos con sus 56 audios? ## Procesamiento en lote con Bash Como los archivos tienen un patrón en sus nombres, y pueden ser listados en orden, y el proceso que se ejecuta sobre cada par es el mismo, podemos crear una rutina para este procesamiento en lote, y evitar así posibles errores como omitir un par de archivos, mezclar un video con el audio de otro o errores de digitación. Necesitaremos almacenar los listados por separado de los archivos de video y audio, de tal forma que iteremos de manera general sobre el total de videos y avancemos en los dos listados, que al estar ordenados y con el patrón de nombre iniciando por el nombre general del video, permitirá emparejarlos. Luego, de manera cíclica obtenemos estas parejas, con las cuales formaremos los archivos para los parámetros `-i` de `ffmpeg`, y la asignación de la ruta de salida. Esto lo haremos en _bash_ (bueno, esto es para usuarios Linux, pero si usas Windows, te invito a replicarlo en PowerShell o tu lenguaje favorito). Código _bash_ para unir un conjunto de videos y audios con FFMPEG. 1#! /usr/bin/bash 2 3OUTPUT=output 4mkdir -p $OUTPUT 5AUDIO_LIST=(*audio.mp4) 6VIDEO_LIST=(*fps*.mp4) 7LEN=${#AUDIO_LIST[*]} 8echo "$LEN videos" 9for ((i = 0; i < LEN; i++)); do 10 echo "Procesando video: $((i + 1))" 11 VIDEO_NAME="${VIDEO_LIST[$i]}" 12 ffmpeg -i "$VIDEO_NAME" -i "${AUDIO_LIST[$i]}" -c copy "$OUTPUT/$VIDEO_NAME" 13done Te explico el código. Línea 1, es una línea _shebang_ para indicar la ruta absoluta del interprete de _shell_ , en este caso, _bash_. En la línea 3, asignamos el nombre para el directorio de salida, que usaremos para crear dicho directorio en la línea 4 y para formar la ruta completa de salida en la línea 12. En la línea 4 vemos la primera aparición de `$` que usamos para expandir un resultado que puede ser de una variable como en este caso, o incluso de una ejecución. Aquí, sobre `mkdir -p` tenemos para decir que esto crea la carpeta, y su opción `-p` es para que no falle en caso de ya existir. Para obtener el listado de archivos podríamos usar `ls`, pero para conertir a un arreglo tenemos que hacer ajustes en el `IFS`, y resulta más simple usar directamente la expansión global de nombre de archivo, como lo hacemos en las líneas 4 y 5. La manera como nos referimos a un arreglo en Bash, es con `${ }` rodeando lo requerido del arreglo, como la indicación a un elemento específico (`${ARR[0]}`) usado en la línea 11 y 12, la totalidad de elementos (`${ARR[*]}` o `${ARR[@]}`) o una variante con el símbolo `#` antes del nombre del arreglo para hacer el conteo como se usa en la línea 7. La sentencia `echo` la usamos para imprimir en la terminal, y vemos que el mensaje está en comillas dobles, lo que evita que el resultado se intente expandir (ejecutar), pues solo nos interesa hasta ese punto. En las líneas 9 y 10 notamos la existencia de doble paréntesis, esto permite la expansión aritmética. Siempre que necesitemos operaciones aritméticas, usamos doble paréntesis. En particular, la línea 9 es el inicio del ciclo `for` en Bash, que usa expansión aritmética con la asignación del valor inicial de la variable para recorrer las listas, la condición del recorrido la cual es mientras sea menor que la longitud de las listas y finalmente el avance en uno para poder pasar al siguiente elemento. Luego sigue la indicación del `do` con el bloque que repetiremos, y que depende de nuestra variable del ciclo (`i`). Y para cerrar el ciclo, terminamos en `done`. Bueno, con esto, estamos listos para ejecutar nuestro código que podemos disponer en un archivo `unir_video.sh` y ejecutar como: bash unir_video.sh # opción 1 . unir_video.sh # opción 2 source unir_video.sh # opción 3 Las últimas dos opciones son el motivo de usar el _shebang_ de la línea 1, para distinguir la _shell_ a usar. Es hora de ejecutar, y deja que esto trabaje por ti con tu colección de videos. Consejo Los 3 recursos que te recomiendo para Bash: * Explain Shell: Escribes una instrucción y te la explica. * Bash Pitfalls: Una compilación de errores comunes de los usuarios en Bash. Una forma de ver los antipatrones y ver las buenas prácticas. * Bash Guide for Beginners y BASH Programming - Introduction HOW-TO: Los puntos iniciales de referencia que recomiendo para Bash, del proyecto de documentación de Linux, _TLDP_.

En esta entrada veremos la solución numérica a la ecuación diferencial no lineal de primer orden que modela la velocidad del viento solar en función de la distancia heliocéntrica. Una vez se obtiene este perfil de velocidad, el cual es dependiente de la temperatura se procede a transformar a coordenadas lagrangianas centradas en un punto de emisión sobre la corona. De esta forma será más natural construir un brazo de la espiral de Parker, sobre el cual evoluciona el perfil de velocidad hallado. Cuando hablamos de la “espiral de Parker” nos referimos a la forma del campo magnético del Sol en nuestro sistema solar a raíz de su rotación y la interacción magnetohidrodinámica con el viento solar en expansión. Esto genera una forma de remolino en la descripción del campo magnético y es la que veremos como obtener con Python. ## Viento solar El viento solar es un flujo de partículas con carga eléctrica (en su mayoría, electrones \\(e^-\\), protones \\(p^+\\) y partículas alfa \\(\alpha\\)), emanadas desde la atmósfera solar. Estas particulas cargadas (gas ionizado o plasma), escapan de la atracción gravitacional del Sol por su alta energía cinética resultado de la temperatura de la corona solar y de la interacción con el campo magnético. Las primeras menciones a su existencia corresponden a Biermann en los años 50, quien mediante la observación de la cola de los cometas (en dirección opuesta al sol), sugirió que debía existir un flujo de gas hacia afuera del Sol de forma radial. Parker toma esta observación, y asume el Sol como una masa gravitacional con simetría esférica en expansión estacionaria (con el fin de asegurar la condición de presión cero a distancia infinita) e inicialmente despreciando los efectos del campo magnético. Con estas consideraciones, se logra manifestar la dinámica del flujo de partículas hacia afuera del Sol (Parker, 1958). ## Perfil de velocidad del viento solar En el trabajo de Parker bajo condiciones de expansión isotérmica (\\(\gamma = 1\\)) de un fluido neutro (primera aproximación al comportamiento del viendo solar), lleva a una ecuación diferencial no lineal de primer orden que relaciona la velocidad del viento solar (\\(u(r)\\)) y la distancia heliocéntrica (\\(r\\)) ((Parker, 1958), (Kivelson, 1995)). (1)\\[\begin{equation} \frac{du(r)}{dr} = \left(\frac{4kT}{mr} - \frac{GM}{r^2} \right)u(r)\left(u(r)^2 - \frac{2kT}{m} \right)^{-1} \end{equation}\\] Con el fin de reducir la propagación de error por los ordenes de magnitud de las variables involucradas, se procede a adimensionalizar la ecuación diferencial, con base al radio y velocidad en el punto crítico (punto sónico) (Piso, 2008). (2)\\[\begin{eqnarray} c_s^2 & = & \frac{2kT}{m}\\\ r_c &=& \frac{GM}{2c_s^2}\\\ \frac{dv}{dR} &=& \frac{2\left(\frac{1}{R} - \frac{1}{R^2}\right)}{v - \frac{1}{v}} \end{eqnarray}\\] Donde \\(v\\) es la velocidad en velocidades sónicas (\\(c_s\\)) y \\(R\\) es el radio en radios sónicos (\\(r_c\\)). Observamos que alrededor del radio sónico y de la velocidad sónica se presenta un punto crítico que debe satisfacerse para asegurar el sentido físico de la solución. También, tenemos que esta ecuación representa un problema de valores de frontera, y en este caso la condición de frontera del problema en unidades adimensionales es \\(v(R_{sol}) = v_0\\), donde \\(R_{sol}\\) es el radio del Sol, y es la posición desde la cuál comienza a desplazarse el flujo de partículas con una velocidad inicial \\(v_0\\) que dependerá de la densidad de partículas y la temperatura. La generación de la espiral de Parker es efecto de la rotación del sol, por lo cual se aplica la transformación de coordenadas lagrangianas para sistemas rotantes, llevando a la ecuación diferencial (3)\\[\begin{equation} \frac{d\varphi}{dR} = \frac{-\omega}{v(R)} \end{equation}\\] ## Solución analítica y numérica con Python Esta ecuación se puede solucionar analíticamente ya que la ecuación permite separación de variables y mediante integración encontrar la solución implícita. Podemos usar SymPy, un paquete de álgebra computacional de código abierto y libre, disponible en Python (una alternativa a paquetes comerciales como Maple y Mathematica). Respecto a la solución numérica, implementaremos el método de Runge-Kutta 4 (RK4), y para la solución de la componente angular lo realizaremos de forma simple con el método de Euler ya que esto evita tener que interpolar la solución de velocidad radial para conocer puntos intermedios requeridos por RK4. Para su implementación vamos a necesitar el manejo de arreglos, y esto los usaremos con NumPy. Por supuesto, queremos ver gráficos para entender la solución, así que usaremos Matplotlib. Así que vamos a instalar, en este caso con la ayuda de UV, el cual es una alternativa más rápida a _PIP_. El `!` es porque es una celda de Notebook, pero si estás en la terminal, puedes omitirla. !uv pip install matplotlib numpy sympy Audited 3 packages in 2ms Iniciamos con el bloque de importación de los elementos que vamos a necesitar. Cada línea se encuentra comentado con el motivo por el cual lo requerimos para que sea claro su uso. from math import cos, pi, sin # Requerido para la transformación polar para ilustrar la solución de la espiral from IPython.display import display # Para incluir gráficos en el Notebook en lugar de ventanas emergentes #%matplotlib inline import matplotlib.pyplot as plt # Graficador para los arreglos numéricos from numpy import array, ones # Arreglos numéricos y el arreglo de unos from sympy import ( dsolve, # Solucionador de ecuaciones diferenciales ordinarias Eq, # Permite plantear igualdades/ecuaciones Function, # Declara variables que representan funciones init_printing, # Inicializa la opción de visualización de ecuaciones plot_implicit, # Permite los gráficos de funciones implícitas solve, # Solución de ecuaciones algebraicas symbols # Declara símbolos generales ) init_printing() # Inicializa sesión de impresión en el Notebook ### Solución analítica El primer paso es la declaración de los símbolos requeridos. Esto es la función del perfil de velocidad y el símbolo para la distancia al centro del sol. Las funciones se declaran con `Function` y las variables adicionales con `symbols`. En ambos casos, tenemos que el argumento es un _string_ de la letra que representa, y por convención lo asignamos a una variable Python con la misma letra. Adicional, vamos a plantear la ecuación que previamente obtuvimos para la forma adimensional, y debemos tener en cuenta que al ser la velocidad una función, se escribe como habitualmente se dispone, indicando su forma con paréntesis y la variable de la cual depende, \\(v(R)\\). Y para expresar la forma de la derivada, las expresiones de SymPy suportan el método `.diff` cuyo argumento es la variable respecto a la cual se deriva. En este caso, se plantearía como `v(R).diff(R)`. v = Function('v') # Declara la función de velocidad R = symbols('R') # Declara la variable de distancia # Se plantea la ecuación diferencial eq_ord = Eq(v(R).diff(R), 2*(1/R - 1/R**2)/(v(R) - 1/v(R))) eq_ord SymPy en los métodos soportados, dispone de la opción de separación de variables. Si necesitamos una forma particular o porque queremos dar un indicio al algoritmo, podemos añadir la opción que recomienda el método, en este caso sería `hint='separable'`. Para nuestro caso, es importante indicar el método para que luego la opción de no simplificación nos muestre la ecuación típica que se describe en el artículo de Parker. La función para la solución de ecuaciones diferenciales ordinarias, es `dsolve`. # Se aplica método de separación de variables # No se simplifica para mostrar la forma implícita sol_impl = dsolve(eq_ord, hint='separable', simplify=False) sol_impl Solo para los curiosos, también podemos permitir que la solución sea simplificada y obtener la forma explícita, la cual depende de la función Lambert W. Esta no es la forma usual en la cual encontraremos referenciada la solución, pero gracias a los sistemas de álgebra computacional podemos disponer de esta desde la década de los 90. Para ello podemos quitar la opción de no simplificar, pero también si removemos la recomendación de método, también la vamos a obtener. dsolve(eq_ord) Ahora, para saber que valores de la constante de integración usar, debemos tener presente que la solución debe satisfacer pasar por el punto crítico, y por ende si asignamos el punto crítico, podemos despejar la constante. Para hacer la substitución usamos el método `.subs` que recibe un diccionario donde las llaves son los símbolos originales y los valores son los nuevos valores o símbolos. solve(sol_impl.subs({v(R): 1, R: 1})) Para poder graficar, debemos reemplazar la función de velocidad de la función implícita por un símbolo, y proceder con los cambios de la constante de integración para generar la familia de soluciones. Como ya sabemos que para pasar por el punto crítico la constante debe ser \\(-3/2\\), vamos a usar este valor, pero también necesitamos un valor superior (ejemplo, \\(1\\)), y un valor inferior (ejemplo, \\(2\\)). Para graficar al ser una función implícita, usaremos `plot_implicit` de SymPy que hace un mallado de puntos en el plano de interes para evaluar por celda el cumplimiento de la igualdad. Usaremos `show=False` para que no se muestre cada curva por separado y poder añadir los 3 escenarios en un mismo gráfico. V = symbols('V') # Símbolo para la velocidad # Graficamos implícitamente para 3 valores de la constante de integración # show=False es para no mostrar de una vez, y poder controlar el gráfico unido # extendiendo y mostrando a discreción p1 = plot_implicit( sol_impl.subs({'C1': -1, v(R): V}), (R, 0, 5), (V, 0, 5), line_color='green', show=False ) p2 = plot_implicit( sol_impl.subs({'C1': -2, v(R): V}), (R, 0, 5), (V, 0, 5), line_color='blue', show=False ) p3 = plot_implicit( sol_impl.subs({'C1': -1.5, v(R): V}), (R, 0, 5), (V, 0, 5), line_color='red', show=False ) p1.extend([p2[0], p3[0]]) # Anexamos las curvas a la misma figura p1.show() # Se muestra la figura Las curvas azules son referenciadas como las soluciones I y II. Son soluciones de doble evaluación y por ende no son soluciones aceptables físicamente. La curva azul de la derecha (II) además no comienza en la superficie del sol. La curva azul izquierda (I) no hace sentido además porque escaparía del Sol con velocidad subsónica y se devolvería con velocidad supersónica. Las curvas verdes (III - superior, IV - inferior) son soluciones que no pasan por el punto crítico y por ende no son aceptables físicamente. Adicional la curva III inicia con velocidad supersónica en las proximidades del Sol y eso no se ha observado, y la curva IV lleva a una presión constante en el ambiente interestelar, por lo cual no tiene sentido físico. Por el contrario, la curva roja ascendente (V), lleva a un aumento a velocidad supersónica después del punto crítico, lo cual es observado, pero además, lleva a una presión cero en el ambiente interestelar. Esta es conocida como la solución del viento solar. Atención A nivel del gráfico se observa una zona densa alrededor del punto crítico, pero esto es efecto del método de graficación implícito en modo adaptativo ### Solución numérica Se observa que en el punto crítico \\((r_c, c_s)\\), se presenta una indeterminación. Por este motivo, es necesario solucionar la ecuación diferencial antes y despues de este punto como dos tramos independientes. El tramo anterior, para asegurar su paso por el punto, lo recomendable es solucionarlo con una forma reversa (_backward_), de tal forma que se pueda usar esta información como condición inicial en la ecuación diferencial en lugar de hacer una estimación de las condiciones iniciales sobre el radio solar (y sería la misma en los dos tramos). Siendo así, tenemos que, \\(v(1) = 1\\), para el primer tramo que va desde el radio de la corona solar hasta el punto crítico, y el segundo tramo que va desde el punto crítico hasta la Tierra (por tener un punto de referencia para la solución hacia adelante). Planteamos la función para los valores numéricos del lado derecho de la ecuación diferencial (\\(\frac{d}{dR}v(R)\\)) en `f_ode` y planteamos nuestra función para el método RK4, `RK4`. def f_ode(R, v): # Función de la derivada del perfil de velocidad respecto a la distancia return 2 * (1/R- 1/R**2)/(v-1/v) def RK4(funcion, cond_inicial, x_final, n): # Implementación del solucionador de Runge Kutta orden 4 x = [cond_inicial[0]] w = [cond_inicial[1]] dx = (x_final - x[0]) / n # paso dx_2 = dx / 2 # medio paso for i in range(n-1): k1 = dx * funcion(x[i], w[i]) k2 = dx * funcion(x[i] + dx_2, w[i] + k1/2) k3 = dx * funcion(x[i] + dx_2, w[i] + k2/2) x.append(x[i] + dx) # x[i+1] = x[-1] k4 = dx * funcion(x[-1], w[i] + k3) w.append(w[i] + (k1 + 2*k2 + 2*k3 + k4)/6) return x, w Se definen las constantes requeridas y las funciones para calcular los radios y velocidades sonicas. G = 6.67e-11 #Nm2kg-2 k = 1.38065e-23 #JK-1 M = 1.988435e30 #kg, masa del sol m_H = 1.67372e-27 #kg, masa hidrogeno r_max = 150e9 #m, dist tierra-sol r_min = 695.5e6 #m, radio solar omega_sol = 2.7e-6 #rads-1, vel angular sol T_cor = 1e6 #K, temp corona solar def c_s(T = T_cor, m = m_H): # Velocidad sónica, la cual depende de la temperatura y densidad del medio from math import sqrt return sqrt(2*k*T/m) def r_c(T = T_cor, m = m_H): # Radio sónico return G*M / (2 * c_s(T, m)**2) Se determinan los parámetros en unidades adimensionales. vel_s = c_s(T_cor, m_H) rad_s = r_c(T_cor, m_H) t_s = rad_s / vel_s print("Velocidad sónica: {:f}km/s".format(vel_s/1000)) print("Radio sónico: {:f}km".format(rad_s/1000)) print("Unidad de tiempo: {:f}s".format(t_s)) omega_s = omega_sol * t_s print("omega (adim): {:f}".format(omega_s)) R_max = r_max / rad_s R_min = r_min / rad_s print("Radio máximo (adim): {:f}".format(R_max)) print("Radio mínimo (adim): {:f}".format(R_min)) Velocidad sónica: 128.444465km/s Radio sónico: 4019540.880399km Unidad de tiempo: 31293.998427s omega (adim): 0.084494 Radio máximo (adim): 37.317695 Radio mínimo (adim): 0.173030 Ahora aplicamos el método RK4 para los tramos y gráficamos. Es necesario tener presente que al estar reverso el primer tramo, también para disponer la solución hay que aplicar el reverso de la lista (`.reverse`) y así tener la solución ordenada. # Solución numérica de la ecuación de viento solar R, v = RK4(f_ode, [1, 1-1e-6], R_min, 30000) R.reverse() v.reverse() R_sup, v_sup = RK4(f_ode, [1, 1+ 1e-6 ], R_max, 1000000) v.extend(v_sup) R.extend(R_sup) # Graficamos plt.plot(1, 1, 'or') plt.text(1.2, 1, 'Punto sónico') plt.plot(R[-1], v[-1], 'og') plt.text(R[-1] + .2, v[-1]-.2,'Tierra') plt.plot(R, v) plt.grid() plt.show() Partiendo de este perfil de velocidad se contruye la componente angular de la velocidad para generar finalmente la conocida espiral de Parker, y lo podemos hacer con el método de Euler. N = len(R) cont = 0 psi = [0] x = [R[0]*cos(psi[0])] y = [R[0]*sin(psi[0])] while cont < N-1: # Método de Euler dR = R[cont + 1] - R[cont] dpsi = -omega_s * dR / v[cont] psi.append(psi[-1] + dpsi) cont = cont + 1 dpsi_v = ones([N]) * pi / 2 psi1 = array(psi) psi2 = psi1 + dpsi_v psi3 = psi2 + dpsi_v psi4 = psi3 + dpsi_v espiral = plt.subplot(111, projection='polar') espiral.plot(psi1, R, color='r') espiral.plot(psi2, R, color='r') espiral.plot(psi3, R, color='r') espiral.plot(psi4, R, color='r') [<matplotlib.lines.Line2D at 0x7fcc671db7f0>] # Referencias * E. N. Parker, “Dynamics of the Interplanetary Gas and Magnetic Fields”, Astrophysical Journal, 128, 1958 p. 664. * Margaret G. Kivelson y Christopher T. Russel, “Introduction to Space Physics”, Cambridge University Press, 1995, 588 p. * Ana Maria Piso, “The Solar Wind” from Wolfram Demonstrations Project, Agosto 6 de 2008. * Richard L. Burden y J. Douglas Faires, “Análisis Numérico”, 7Ed., Ediciones Paraninfo, 2002 p. 839.

Siguiendo con ajustes en mi blog, algo que quería darle una nueva oportunidad, así algunos lo odien, es a _Google Ads_ y ver esto como permite generar algún ingreso ahora que muchos usamos bloqueadores (sí, yo también). Les cuento como configurarlo a través de la modificación de las plantillas por defecto. ## Directorio de _assets_ Necesitamos configurar directorios de archivos generales que van a nivel de raíz del despliegue y el directorio de plantillas, esto con el fin de asegurarnos del directorio sin el prefijo `_` problemático en _GitHub Pages_ y ser consciente del valor en lugar de tomar el valor por defecto. html_extra_path = ['files'] templates_path = ['templates'] Creamos los directorios `files` y `templates` si no los hemos creado. ## Archivo Ads Un primer paso para incluir _Google Ads_ es incluir nuestra validación como publicador y esto puede hacerse incluyendo _scripts_ o un archivo `ads.txt`. Es recomendable esta última opción para reducir la carga de _scripts_ , y acorde a Google es más recomendable para las validaciones por proveedores de anuncions y cuando son múltiples. Este archivo debe estar en la raíz de nuestro sitio, por lo que vamos a disponer de este archivo en el directorio `files` que es el destinado para este tipo de archivos. Una vez tenemos la aprobación, seguiremos con el _script_. ## _Script_ en _head_ En el interior de `templates`, necesitamos crear un nuevo archivo que usaremos para modificar el comportamiento por defecto de la plantilla de `layout.html`, que es la plantilla usada por _Sphinx_ que contiene lo que se agrega entre las etiquetas de apertura y cierre de `head`. Creamos el archivo con el mismo nombre de la plantilla que deseamos reemplazar, y en su interior se indica que extiende dicha plantilla en la primera línea. Usamos ahora el bloque asociado a `extrahead` para añadir el _script_ de _Google Ads_ que requerimos esté en el _head_. Para mi caso, luciría de la siguiente forma (debes cambiar acorde al generado en tu sección de Google Adsense). {% extends "!layout.html" %} {{ super() }} {% block extrahead %} <script async src="https://pagead2.googlesyndication.com/pagead/js/adsbygoogle.js?client=ca-pub-0356238418278924" crossorigin="anonymous"></script> {% endblock %} Unos minutos (u horas) después, tendremos la visualización de anuncios en nuestro sitio generado con Sphinx. Visualización de anuncios en sitio generado con Sphinx. ## Referencias * Sphinx - Configuration - `html_extra_path`. * Sphinx - Configuration - `templates_path`. * Sphinx - HTML theme development - Templating.

Un nuevo paso en mi blog, es que decidí dejar una huella de personalización a través de un logo, algo sencillo, pero propio, distinto a una imagen descargada como lo era antes y que por lo mismo no lo había configurado. Les cuento como configurar el logo y el _favicon_ en Sphinx. ## Directorio de _assets_ Para iniciar, requerimos configurar el directorio que usaremos para los archivos estáticos de logo y _favicon_. En nuestro archivo de configuración, `conf.py`, vamos a ajustar el valor de la variable `html_static_path` como fue explicado en una publicación anterior. Este paso es importante sobre todo si alojamos nuestro blog en GitHub, porque el valor por defecto al tener como prefijo `_`, no permite que se carguen los archivos en el despliegue. ## Logo Bueno, la verdad este punto no tiene nada de extraño, pero dejaré una recomendación. Es mejor tener un archivo fuente editable para nuestro logo, de tal forma que podamos proceder con ajustes fácilmente. Ejemplo, tenemos la versión para temas oscuros, y luego decidimos tener la versión para temas claros (en Sphinx con el tema de PyData es posible), podamos hacer estos cambios sin rehacer el logo desde cero. En mi caso, este logo lo hice con Inkscape en formato vectorial (`.svg`), y lo sincronizo en el repositorio también y hace parte de los estáticos. Otra recomendación, es tener presente que en dimensiones, es preferible que sea más horizontal que vertical, pero su ancho no debe ser superior a los 200 pixeles. Ahora, vamos a nuestro archivo `conf.py` nuevamente, y allí encontraremos la variable `html_logo` la cual asignaremos la ruta relativa al archivo de configuración, apuntando a nuestro logo. Ejemplo: html_logo = 'static/cosmoscalibur_logo.png' A mi parecer, con la única versión de logo está _ok_ , pero si requieres usar una versión por tema, esto es una condición que depende del tema seleccionado y en PyData se puede usando las opciones de `html_theme_options`. Así vemos ubicado el logo configurado en el blog. ## Favicon Para el _favicon_ también podemos usar las opciones propias de _Sphinx_ con la variable `html_favicon`. Nuestro _favicon_ debe ser de 16 por 16 pixeles, y puede ser de formato ICO, PNG, SVG o GIF. Debido al tamaño cuadrado del _favicon_ , el cual irá en las pestañas del navegador o en los marcadores, es conveniente tener un segundo diseño basado en nuestro logo que se adapte a estas dimensiones. En nuestro `conf.py` entonces hacemos el ajuste: html_logo = 'static/cosmoscalibur_favicon.png' Finalmente, así se ve nuestro _favicon_. Así vemos el _favicon_ en la pestaña del navegador. ## Referencias * Sphinx - Configuration - HTML logo. * Sphinx - Configuration - HTML favicon. * PyData Theme - Branding and logo.

UV es un gestor de paquetes y entornos virtuales alternativo para _Python_ , desarrollado en _Rust_ y que nos promete ser muy rápido en los procesos que pretende reemplazar de PIP y VENV. En este sentido, solo es añadir `uv` antes de las instrucciones habituales y debe funcionar (salvo algunos casos particulares de compatibilidad o de no existir implementación). Esta es una de tantas herramientas que vienen en la era _Rust_ a permear el ecosistema de _Python_ generando un nuevo valor, como lo es la mejora de rendimiento. Y es que del mismo creador, tenemos también _Ruff_ como un reemplazo eficiente de _linters_ , y también hay otras herramientas como _PyO3_ para crear bibliotecas Python en Rust, Polars como un reemplazo a Pandas o Robyn como alternativa a Flask. Este proyecto, UV, pretende ser el equivalente de un _cargo_ (el gestor de _Rust_) para Python, integrando en un único binario, múltiples utilidades. ## Instalación de UV Si tenemos en nuestro sistema más de una versión Python, la forma recomendada para instalar será a partir del _script_ de instalación que provee, ya que de esta forma queda disponible para todas nuestras instalaciones sin depender de un ambiente Python en particular. Esto es porque el binario evalúa la instalación de Python correspondiente a través de las variables de entorno y soporta las funciones de gestión para el ambiente detectado. Si estamos en Linux, podemos proceder como curl -LsSf https://astral.sh/uv/install.sh | sh La primera línea, descarga el _script_ de instalación y lo ejecuta. En la segunda línea, se configura el entorno (en mi caso uso _bash_) y con esto queda disponible de forma inmediata (también si abres una nueva consola estará disponible). También se encuentra como un paquete Python, por lo que podrás usar _pip_ para instalarlo. Si necesitas validar otro método o sistema operativo, puedes revisar el repositorio oficial. pip install uv Como veremos adelante, tendremos unas buenas mejoras en los tiempos de instalación de paquetes y de creación de ambientes, pero es importante que si piensas esta herramienta para reducir el tiempo de ejecución de GitHub Actions, el tiempo de instalación de UV o de su gestión de caché puede no ser una alternativa de momento, salvo que el tiempo de resolución efectivamente lo valga. En mi caso, el método directo tomó 7.8 s, mientras que la instalación con PIP tomó 5.8 s. Nota La manera como mediremos los tiempos de los procesos, será mediante la utilidad `time`. Esta se puede anteceder a las instrucciones que usaremos y nos permitirá evaluar el tiempo total (_real_), así como el tiempo en espacio de usuario y de sistema. Para actualizar _UV_ desde el binario, podemos usar `uv self update` (disponible desde la versión 0.1.23). ### Desinstalar UV Esto no es algo bien documentado, pero se encuentra disponible en un reporte al repositorio, considerando que es simplemente un binario. Así que nos interesa borrar la caché de UV y el binario. rm -rf $HOME/.cache/uv rm $HOME/.cargo/bin/uv ## Creación de ambientes virtuales Igual que con la utilidad de _venv_ , el ambiente creado depende de la instalación Python usada (detectado por las variables de entorno), y tendremos opción de manejarlo con el nombre por defecto o asignando uno. python3 -m venv testvenv # VENV: Toma 2.5 s uv venv testuv # UV: Toma 0.01 s La opción de _UV_ es bastante rápida en la creación del ambiente virtual. ## Instalación de paquetes Python En general, es buena práctica usar ambientes, y UV lo espera por defecto. Pero en caso de una instalación global, podemos pasar `--system` como argumento (adecuado para CI o contenedores). En mi caso, igual para poder hacer las pruebas, activaré los ambientes para comparar la instalación de _pip_ y _UV_. El caso de uso para la prueba, será la instalación de las dependencias usadas en el repositorio del blog. source testenv/bin/activate python3 -m pip install -r requirements.txt -r requirements-dev.txt source testuv/bin/activate uv pip install -r requirements.txt -r requirements-dev.txt Mientras que la versión _pip_ tomó 25.5 s, la versión _UV_ tomó 5.9 s. Aquí notamos ya diferencias importantes que en un flujo de CI (ejemplo, GitHub Actions), puede representar ahorros interesantes. Este mismo ejercicio lo realicé para el repositorio principal en mi trabajo, toma 6 s con UV sin caché e instalando UV, mientras que usando PIP toma típicamente 32 s sin caché y 24 s con caché. En este caso, es importante pasar la opción de sistema para usarlo en GitHub Actions. pip install uv uv pip install --system -r requirements.txt -r requirements-dev.txt Es importante tener presente el cambio de sintaxis cuando se instala un paquete desde un repositorio, y es el uso de `"paquete @ url_repo"`, y en particular si posee credenciales considerar el soporte acorde a las indicaciones.