Notas de la versión 0.9.3 Beta

Fecha de publicación: 21 de mayo de 2026
Versión anterior: 0.9 Beta (31 de diciembre de 2024)
Versión siguiente: 0.9.4 Beta (12 de septiembre de 2026)

Esta es la versión más grande de la historia de Ditana. Se han modificado casi todos los subsistemas, y la arquitectura se ha reorganizado de forma fundamental en torno al principio de configuración como datos. Esta página recoge los aspectos destacados; el diff completo está en el historial de Git de ditana-installer y ditana-config.

El gran cambio: configuración como datos

El mayor cambio individual desde la 0.9.0 es de arquitectura. En la 0.9.0, las personalizaciones de Ditana estaban en paquetes monolíticos de Arch: todo lo que el instalador quería configurar tenía que quedar fijado dentro de un PKGBUILD. Eso hacía difícil combinar la personalización del escritorio, la elección del navegador, la selección de la terminal y decenas de otros puntos de contacto.

En la 0.9.3, todo esto está en un repositorio nuevo, con versiones independientes —ditana-config—, como datos estructurados en KDL v2. Cada opción, cada dependencia, cada script del ciclo de vida es declarativo. El código del instalador es pequeño; la base de conocimiento es el cerebro.

Dos consecuencias que vale la pena destacar:

Las mejoras se publican sin generar una ISO nueva. El instalador descarga en tiempo de ejecución el archivo comprimido de configuración más reciente (con la versión incluida en la ISO como reserva). Una corrección de errores que se integra en ditana-config un lunes llega a las nuevas instalaciones el martes.
Contribuir es muchísimo más fácil. La mayoría de las contribuciones modifican un solo archivo KDL. El README.md de ditana-config explica el modelo de datos en detalle.

Cuatro escritorios, en igualdad de condiciones

La 0.9.0 incluía solo XFCE. La 0.9.3 incluye cuatro entornos de escritorio —XFCE (X11), Wayfire, Niri y COSMIC (todos con Wayland)—, que se pueden instalar por separado o en paralelo. La pantalla de inicio de sesión muestra los que usted haya instalado.

A veces se descarta a Wayfire y Niri como entornos incompletos. Ditana aborda esa carencia directamente: una configuración pulida de waybar con iconos acordes al tema, nwg-launcher y nwgbar para iniciar aplicaciones y para las acciones de energía, valores predeterminados sensatos en los cuatro; así, los cuatro son opciones de pleno derecho, no demostraciones tecnológicas.

lightdm se ha sustituido por greetd con tuigreet, que se integra sin problemas con uwsm para gestionar el ciclo de vida de las sesiones en Wayland.

Instalación adaptada al hardware

Dos fases de detección son nuevas o se han ampliado considerablemente:

La detección de NVIDIA coteja ahora, durante la instalación, tanto la lista de identificadores PCI de open-gpu-kernel-modules como la página de GPU heredadas de NVIDIA, y luego recomienda una de cuatro opciones: nvidia-open-dkms (el nuevo valor predeterminado para Turing o posterior), nvidia-580xx-dkms (Maxwell/Pascal/Volta), nvidia-470xx-dkms (Kepler) o nouveau. Las elecciones de kernel incompatibles con DKMS se rechazan con una explicación.
La detección de máquinas virtuales determina varias elecciones posteriores (renderizado por software como reserva, fstrim.timer desactivado).

La detección y la mitigación de vulnerabilidades de la CPU —ya un rasgo distintivo de Ditana en la 0.9.0— se mantienen sin cambios. Consulte la página de mitigaciones de CPU para ver la justificación completa de cada vulnerabilidad.

Mapa de teclado de la consola, generado con precisión

Una mejora pequeña pero visible: vconsole.conf se genera ahora con ckbcomp a partir del mapa de teclado X11 seleccionado. El método anterior era aproximado; este es exacto, lo que importa durante la instalación (las contraseñas se escriben en la VT de Linux) y al usar la VT después de la instalación. Esto resuelve una queja de un comentario en DistroWatch sobre la 0.9.0.

Refuerzo de seguridad del sistema: un diálogo nuevo

Esto es realmente nuevo en la 0.9.3. El instalador de la 0.9.0 cubría las mitigaciones de vulnerabilidades de la CPU, pero no tenía ningún diálogo de refuerzo de seguridad de uso general. La 0.9.3 agrega una sección completa System Hardening en Expert Settings, con opciones documentadas basadas en sysctl:

Espacios de nombres de usuario sin privilegios desactivados de forma predeterminada (unprivileged_userns_clone=0), con la contrapartida para navegadores y Flatpak explicada en detalle.
ptrace restringido (yama.ptrace_scope=2 de forma predeterminada, =0 para el perfil de desarrollador).
Punteros del kernel ocultos, dmesg restringido, kexec desactivado.
FIFO y archivos normales protegidos en directorios con el bit sticky (más allá de la protección predeterminada de Linux para enlaces duros y simbólicos).
Pila de red reforzada (SYN cookies, sin redirecciones ICMP, sin enrutamiento de origen, filtrado de ruta inversa).
JIT de BPF restringido, relajación opcional de perf_event_paranoid para desarrolladores.
hardened_malloc opcional en variante completa o ligera, además de mimalloc opcional para configuraciones orientadas al rendimiento.

Cada opción se presenta como una lista de verificación con documentación completa, incluidas las contrapartidas que usted acepta al marcar o desmarcar la opción.

Compatibilidad con Flatpak, integrada de principio a fin

Ahora se pueden declarar Flatpaks en la configuración junto a arch-packages y aur-packages. La instalación se realiza en el primer arranque mediante un servicio dedicado, ditana-flatpak-finalize.service (que bloquea la pantalla de inicio de sesión hasta terminar, para que las instalaciones a mitad de sesión no tomen a nadie por sorpresa).

Cuando existen, los Flatpaks se prefieren a los equivalentes disponibles solo en el AUR, salvo cuando el espacio aislado de un Flatpak no puede funcionar con el refuerzo de seguridad predeterminado de Ditana. Brave Browser es el ejemplo documentado: su Flatpak requiere unprivileged_userns_clone=1, así que Ditana distribuye en su lugar brave-bin desde el AUR. Las contrapartidas se explican en detalle en la página de buenas prácticas AUR frente a Flatpak.

Valores predeterminados dinámicos para tipos MIME

Las aplicaciones predeterminadas para los tipos MIME se calculan ahora a partir de los componentes instalados, en lugar de estar fijadas en el código. Instale LibreOffice → LibreOffice se encarga de .docx. Instale en su lugar ONLYOFFICE → se encarga ONLYOFFICE. Instale Thunar → Thunar abre los directorios. Instale COSMIC Files → los abre COSMIC Files. Todo se compone a partir de las declaraciones KDL.

Emulador de terminal, ahora de pleno derecho

El instalador ofrece ahora seis emuladores de terminal con una matriz de decisión cuidadosamente elaborada: kitty (predeterminado, X11+Wayland), foot (solo Wayland, ligero), Alacritty (GPU, minimalista), WezTerm (completo, multiplexor), Ghostty (moderno, necesita OpenGL 4.3 o posterior) y COSMIC Terminal. El estándar xdg-terminal-exec se usa de forma coherente. Con las terminales solo para Wayland, se instala automáticamente kitty como reserva para X11 si también se selecciona XFCE: sin malabarismos manuales.

Ayudante del AUR: pikaur → paru

pikaur se ha sustituido por paru. El desencadenante fue pachub (el explorador gráfico de paquetes de Arch, anclado en el panel de todos los escritorios junto a bazaar para Flatpak), que solo admite yay o paru. Optar por paru también encajaba mejor con las demás necesidades de Ditana.

Gestión de contraseñas

Ahora puede anular la estricta comprobación de contraseñas pwscore para la cuenta de usuario si tiene una buena razón para hacerlo. La comprobación sigue siendo obligatoria cuando el cifrado de disco completo está activado: en ese caso, una contraseña débil reduce activamente la seguridad.

Esto responde a varios informes de usuarios de la 0.9.0 sobre instalaciones que se interrumpían porque no se conseguía superar el mínimo predeterminado de pwscore.

Incidencias de GitHub cerradas

Diez incidencias de la 0.9.0 comunicadas por usuarios están implementadas en la 0.9.3: correcciones de errores y solicitudes de funciones. La lista está disponible en el gestor de incidencias del instalador.

Entre bastidores

Ansible → Sparrow6. La lógica de gestión de la configuración que personaliza archivos como mkinitcpio.conf ha migrado de Ansible a Sparrow6, con contribuciones sustanciales de Alexey Melezhik. Sparrow6 también se usa para probar las propias configuraciones automatizadas. La migración elimina una dependencia de Python en tiempo de ejecución y produce una salida de pruebas más legible.
Agradecimientos. Gracias a Alexey Melezhik por el trabajo en Sparrow6 y por su colaboración continua. Gracias a Thomas Zipproth por sus pruebas y comentarios constantes. Gracias a todas las personas que abrieron una incidencia sobre la 0.9.0: todas las incidencias se revisaron, y la mayoría ya están cerradas.

Un poco de historia

Cuando Ralf Hersel me entrevistó para gnulinux.ch a principios de 2025 sobre Ditana 0.9.0, lo primero que comentó fue que había ganado una apuesta: había predicho que antes de que terminara 2024 saldría una distribución de Linux con IA integrada, y la 0.9.0 (31 de diciembre de 2024) llegó justo al límite del plazo.

Ditana sí incluye el Ditana Assistant opcional, que usa un modelo local de Ollama (o cualquier punto de conexión compatible con OpenAI) para generar comandos de shell. Es útil, pero yo sería el primero en decir que «distribución con IA» es exagerar: el asistente tiene un contexto limitado del sistema, y una distribución realmente integrada con IA es un proyecto aparte que quizá explore más adelante (el análisis automatizado de registros sería la dirección más realista). Por ahora: es una herramienta práctica, anclada en el panel si usted la activa.

Actualizar desde la 0.9.0

No hay actualización in situ. La arquitectura ha cambiado demasiado. La vía admitida es una instalación nueva, respaldada por una instantánea de Timeshift / ZFS de su /home (o de la partición de datos que tenga).

Esta traducción la hizo una máquina. Los lectores la mejoran en Weblate.