Linux on KnightLi Blog

Impacto de cuatro problemas locales recientes en Linux: Copy Fail, Dirty Frag, Fragnesia y ssh-keysign-pwn

Wed, 20 May 2026 23:00:37 +0800

En las últimas semanas aparecieron varios problemas locales de seguridad de alto perfil en el ecosistema Linux. Por separado, afectan zonas distintas: interfaces criptográficas, rutas de red e IPsec, manejo de page cache y comprobaciones de acceso ptrace. En conjunto, apuntan a la misma lección operativa: si un atacante ya tiene un punto de ejecución local con pocos privilegios, el riesgo para hosts Linux, nodos de contenedores, máquinas de CI y servidores multiusuario aumenta de forma clara.

Este artículo no repite todos los detalles técnicos de cada vulnerabilidad. Resume su impacto práctico y enlaza cuatro análisis separados dentro del sitio.

Qué afecta cada uno de los cuatro eventos

Los cuatro riesgos que conviene seguir son:

Copy Fail (CVE-2026-31431): un usuario local con pocos privilegios puede afectar la page cache mediante rutas relacionadas con criptografía del kernel y ampliar privilegios.
Dirty Frag (relacionado con CVE-2026-43284 / CVE-2026-43500): el riesgo se concentra en xfrm/ESP, RxRPC y rutas de datos de red y kernel, con alto impacto en fases posteriores a una intrusión.
Fragnesia (CVE-2026-46300): cercano a Dirty Frag, gira alrededor de XFRM ESP-in-TCP, fragmentos compartidos y riesgo de escritura en page cache.
ssh-keysign-pwn (CVE-2026-46333): no es un bug de root shell directo, sino un riesgo local de divulgación de información que puede exponer claves privadas SSH del host, /etc/shadow y otros archivos sensibles.

Los puntos de entrada son distintos y las mitigaciones también. Arreglar Copy Fail no cubre automáticamente Dirty Frag o Fragnesia. Desactivar algunos módulos de red tampoco elimina por sí solo el riesgo de divulgación de información de ssh-keysign-pwn.

Copy Fail: alta prioridad para contenedores y nodos CI

El impacto clave de Copy Fail no es que una aplicación se bloquee. Es que una capacidad de ejecución con pocos privilegios puede convertirse en permisos de root. Es especialmente sensible en estos entornos:

Nodos CI/CD que permiten subir o ejecutar código.
Hosts de contenedores que ejecutan cargas no confiables.
Máquinas de desarrollo y prueba, jump hosts y servidores compartidos.
Hosts cloud con kernels antiguos y ciclos de parcheo lentos.

El peligro de Copy Fail está en su umbral de explotación relativamente bajo y en que se combina fácilmente con escenarios de contenedores. Muchos equipos tratan los contenedores como una frontera fuerte de aislamiento, pero los contenedores ordinarios siguen compartiendo el kernel del host por defecto. Si un atacante obtiene una shell dentro de un contenedor, una LPE del kernel puede convertir un problema del contenedor en un problema del host.

Análisis detallado: Copy Fail CVE-2026-31431: riesgo de escape de contenedor en una ruta de copia de archivos del kernel Linux.

Dirty Frag: un amplificador posterior a la intrusión

Dirty Frag se parece más a una herramienta de ampliación de privilegios después de que el atacante ya entró al sistema. No es una vulnerabilidad remota sin autenticación típica. El requisito habitual es que el atacante ya tenga ejecución local mediante una contraseña débil, WebShell, cuenta de servicio con pocos privilegios, tarea de contenedor u otro punto de apoyo.

Su impacto práctico aparece en varios lugares:

Una cuenta comprometida con pocos privilegios puede convertirse en root.
Un punto de ejecución con pocos privilegios dentro de un contenedor puede amenazar al host.
Los sistemas que usan IPsec, ESP, RxRPC o capacidades de red relacionadas del kernel necesitan revisar con cuidado parches y mitigaciones temporales.
Los equipos de seguridad no deben mirar solo la defensa perimetral, sino también las cadenas de escalada posteriores a la intrusión.

Dirty Frag recuerda a los equipos de operaciones que una LPE local quizá no sea la primera entrada, pero puede decidir hasta dónde llega una intrusión. Si existe un punto de apoyo con pocos privilegios, el atacante buscará bugs del kernel para llegar al nivel más alto.

Análisis detallado: Dirty Frag CVE-2026-43284: guía de riesgo y mitigación de escalada local en Linux.

Fragnesia: una superficie similar no se limpia de una sola vez

Fragnesia importa porque muestra que la superficie alrededor de Dirty Frag no es un problema aislado. Incluso si un bug se corrige, rutas vecinas, estructuras de datos similares y combinaciones de módulos relacionados pueden conservar nuevos puntos explotables.

Su impacto operativo principal es:

No tratar solo el nombre de la vulnerabilidad una vez. Hay que seguir revisando por superficie de ataque.
esp4, esp6, rxrpc, XFRM y ESP-in-TCP deben evaluarse según dependencias reales del negocio.
Si el sistema no depende de esas capacidades de red, se puede considerar una desactivación temporal, pero primero debe probarse para no romper VPN, IPsec, túneles o redes internas.
Los riesgos de contaminación de page cache pueden crear puntos ciegos: el archivo parece no cambiar, pero la ruta de ejecución queda afectada.

Para empresas, la lección principal es que la gestión de parches no debe mirar solo un CVE aislado. Es más seguro inventariar por subsistemas y superficies de ataque, identificar qué máquinas exponen esas capacidades y qué servicios realmente necesitan esos módulos.

Análisis detallado: Fragnesia (CVE-2026-46300): impacto y mitigación de una escalada local en el kernel Linux.

ssh-keysign-pwn: no da root directo, pero sigue siendo peligroso

ssh-keysign-pwn es distinto de los tres anteriores. Se parece más a una divulgación local de información sensible que a una vulnerabilidad de root shell directo. Pero en ataques reales, la divulgación de información sensible puede convertirse rápidamente en un incidente mayor.

Sus impactos principales incluyen:

La filtración de SSH host private keys puede afectar la confianza en la identidad del host.
El acceso a archivos como /etc/shadow puede permitir cracking offline y toma de cuentas.
Servidores multiusuario, jump hosts, máquinas de build y máquinas de desarrollo compartidas tienen mayor riesgo.
Aunque el atacante no escale privilegios de inmediato, puede obtener material de credenciales útil para movimiento lateral.

Este tipo de problema se subestima fácilmente porque no luce tan dramático como una shell root directa. Sin embargo, en entornos empresariales, la exposición de claves y hashes de contraseñas suele implicar una limpieza más larga: rotar claves SSH del host, revisar relaciones de confianza, comprobar contraseñas de cuentas y auditar logs de acceso.

Análisis detallado: ssh-keysign-pwn (CVE-2026-46333): divulgación local en Linux, claves SSH del host y riesgo sobre /etc/shadow.

Impacto común: los contenedores no son una frontera fuerte por defecto

Juntos, estos cuatro eventos dejan claro un punto: el aislamiento ordinario de contenedores no es aislamiento de máquina virtual.

Docker, containerd y Kubernetes usan namespaces, cgroups, capabilities, seccomp, AppArmor y SELinux para reducir superficie de ataque, pero normalmente siguen compartiendo el kernel del host. Si la vulnerabilidad está en el kernel compartido, un punto de ejecución con pocos privilegios dentro de un contenedor puede convertirse en entrada de ataque.

Los entornos de alto riesgo deberían revisar:

Si se permite ejecutar código no confiable en hosts compartidos.
Si los contenedores corren como root por defecto.
Si se conceden capabilities innecesarias.
Si las políticas seccomp son demasiado amplias.
Si cargas multi-tenant deberían moverse a gVisor, Kata Containers, Firecracker microVM, máquinas virtuales dedicadas o nodos dedicados.

Las plataformas CI/CD merecen atención especial. Los jobs de build ejecutan de forma natural código externo, scripts de instalación de dependencias, scripts de prueba y binarios temporales. Si esos jobs comparten hosts con servicios de larga duración, una sola escalada local puede afectar infraestructura mucho mayor.

Impacto común: los parches deben llegar al kernel en ejecución

Un error común al parchear kernels Linux es asumir que un paquete instalado significa que la máquina está ejecutando el kernel corregido.

Como mínimo, operaciones debería verificar tres cosas:

`1`	`uname -a`

Confirmar el kernel actualmente en ejecución.

`1`	`dpkg -l \| grep linux-image`

O en distribuciones de la familia RHEL:

`1`	`rpm -qa \| grep kernel`

Confirmar los paquetes de kernel instalados.

Finalmente, confirmar que la máquina reinició con el kernel corregido. Para servicios críticos que no pueden reiniciarse de inmediato, evaluar livepatch, hot patching o aislamiento temporal, pero no tratar la mitigación temporal como arreglo final.

Impacto común: reducir superficie de ataque debe ser específico

Estas vulnerabilidades recuerdan que endurecer Linux no puede quedarse en “actualizar el sistema” y “activar firewall”.

Revisiones más concretas incluyen:

Si AF_ALG / algif_aead se usa en cargas del negocio.
Si XFRM, ESP, ESP-in-TCP e IPsec son necesarios para VPN, túneles o gateways de seguridad.
Si RxRPC es necesario.
Si user namespaces no privilegiados deben estar habilitados.
Si los contenedores pueden crear tipos de socket demasiado amplios.
Si las políticas de acceso ptrace son demasiado permisivas.

Si el negocio no necesita ciertas capacidades, se puede evaluar desactivar módulos, ajustar sysctl, endurecer seccomp y reducir capabilities. No copies comandos a producción a ciegas. Primero inventaría dependencias y luego despliega gradualmente.

Orden de respuesta recomendado

Primero, prioriza máquinas donde la ejecución local de código está expuesta:

Hosts de contenedores.
CI/CD runners.
Jump hosts.
Servidores multiusuario.
Hosts que ejecutan servicios expuestos.
Sistemas que ejecutan plugins, scripts o extensiones no confiables.

Segundo, confirma avisos de la distribución y el kernel realmente en ejecución. No dependas solo del número de versión upstream. Debian, Ubuntu, RHEL, AlmaLinux, Rocky Linux, SUSE, openEuler y otras distribuciones pueden aplicar backports de seguridad.

Tercero, endurece políticas de ejecución de contenedores. Prioriza usuarios no root, capabilities mínimas, no-new-privileges, sistemas de archivos de solo lectura y políticas explícitas de seccomp más AppArmor o SELinux.

Cuarto, revisa exposición de claves y credenciales. Especialmente en entornos afectados por ssh-keysign-pwn, evalúa si SSH host keys, /etc/shadow, credenciales de jump hosts y CI secrets necesitan rotación.

Quinto, mejora monitoreo. Observa root shells anómalas, PoCs locales sospechosas de LPE, cambios en archivos críticos, comportamiento ptrace anómalo, procesos de contenedor accediendo a rutas del host y conexiones de red inusuales desde nodos CI.

Conclusión

El punto de estos cuatro eventos no es “Linux es inseguro”. El punto es que la confianza por defecto ya no alcanza.

Linux sigue siendo transparente, reparable, configurable y endurecible. Pero en entornos donde contenedores, CI, multi-tenancy y ejecución de código impulsada por IA son cada vez más comunes, un punto de ejecución con pocos privilegios ya no puede tratarse como un problema menor. Si el kernel contiene bugs explotables de escalada local o divulgación de información sensible, una intrusión parcial puede convertirse en control del host, exposición de credenciales o movimiento lateral.

El enfoque más realista es tomar estos cuatro eventos como recordatorio: parchear rápido, confirmar kernels reiniciados, habilitar módulos solo cuando sean necesarios, endurecer contenedores, hacer posible la rotación de claves y reevaluar niveles de aislamiento en cargas multi-tenant.

Lecturas relacionadas en este sitio:

ssh-keysign-pwn (CVE-2026-46333): filtración local de información en Linux, claves host SSH y riesgo para /etc/shadow

Sun, 17 May 2026 09:29:03 +0800

ssh-keysign-pwn se refiere a un conjunto de rutas de explotación alrededor de un fallo lógico en __ptrace_may_access() del Linux kernel, asignado como CVE-2026-46333. No es una vulnerabilidad remota sin autenticación y no entrega directamente una shell de root, pero el riesgo sigue siendo alto: un usuario local con pocos privilegios podría leer archivos sensibles de root que no debería poder acceder, como claves privadas de host SSH o /etc/shadow.

Para equipos de operaciones, la prioridad no es reproducir un PoC. La prioridad es identificar máquinas afectadas, actualizar el kernel, reiniciar para entrar en el kernel corregido y rotar claves de host SSH o restablecer contraseñas cuando sea necesario.

Conclusión rápida

Esta vulnerabilidad merece una prioridad alta por cuatro motivos:

La puede activar un usuario local de bajo privilegio, sin root.
Ya existe PoC público, lo que reduce mucho la barrera de explotación.
Los objetivos potenciales no son archivos comunes, sino claves privadas de host SSH y /etc/shadow.
La corrección requiere parche de kernel y reinicio; instalar paquetes sin reiniciar no basta.

Si tus servidores tienen múltiples usuarios, shell local, hosting compartido, CI runners, hosts de contenedores, aulas, bastiones o cualquier usuario local que no sea completamente confiable, conviene tratarlo primero.

Qué es la vulnerabilidad

Qualys publicó detalles en oss-security el 15 de mayo de 2026. Antes había informado a security@kernel.org de un problema lógico en __ptrace_may_access() del Linux kernel, y la corrección upstream ya había sido integrada por Linus. Después apareció código de explotación público, por lo que Qualys compartió la información en oss-security.

El equipo CVE del Linux kernel asignó luego CVE-2026-46333. La página de NVD muestra kernel.org como fuente, y la descripción corresponde al commit del kernel ptrace: slightly saner 'get_dumpable()' logic.

En términos simples, el fallo está en la ruta de salida de procesos. Cuando algunos procesos privilegiados están terminando, la lógica del kernel relacionada con las comprobaciones de acceso de ptrace puede omitir una comprobación dumpable que debería aplicarse, porque la tarea objetivo ya no tiene mm. Un atacante puede competir en una ventana muy estrecha y obtener descriptores de archivo que el proceso privilegiado en salida todavía mantiene abiertos.

Por eso se lo llama ssh-keysign-pwn: una de las rutas públicas de explotación gira alrededor de ssh-keysign para leer SSH host private keys.

Por qué puede exponer claves host SSH y /etc/shadow

En esencia, es una filtración local de información. Abusa de una ventana durante la salida de un programa privilegiado en la que el descriptor de memoria ya se separó, pero los descriptores de archivo aún no se cerraron.

El aviso de AlmaLinux explica el riesgo con claridad: si un programa privilegiado abrió archivos sensibles antes de bajar privilegios, y el atacante logra capturar el descriptor de archivo correspondiente durante la ventana de salida, esos archivos sensibles podrían leerse.

Dos objetivos frecuentes en la discusión pública son:

ssh-keysign: puede involucrar claves privadas de host SSH como /etc/ssh/ssh_host_*_key.
chage: puede involucrar /etc/shadow.

Si se filtran claves privadas de host SSH, un atacante podría suplantar el host y debilitar la confianza en la identidad SSH del servidor. Si se filtra /etc/shadow, un atacante puede crackear hashes de contraseña offline y ampliar el compromiso después.

Por eso debe tratarse como un problema de alta prioridad aunque no sea una vulnerabilidad de “root shell directo”.

Cómo evaluar la exposición

Desde la perspectiva upstream, es una vulnerabilidad del Linux kernel. Los registros de NVD muestran que el problema entró en el dataset de NVD el 15 de mayo de 2026, y en ese momento todavía no tenía puntuación CVSS.

El estado por distribución debe verificarse en los avisos de cada proveedor:

AlmaLinux 8, 9 y 10 publicaron orientación y el 16 de mayo de 2026 actualizaron el aviso para indicar que los patched kernels ya estaban en repositorios de producción.
Debian Security Tracker lista estados vulnerable/fixed y versiones corregidas para bullseye, bookworm, trixie, sid y otras ramas.
Para otras distribuciones, revisa las páginas oficiales de seguridad o repositorios de Ubuntu, Red Hat, SUSE, Arch, Alpine, etc.

No evalúes la seguridad solo por la versión upstream del kernel. Las distribuciones hacen backport de correcciones, por lo que un mismo número de versión aparente puede representar estados de parche diferentes.

Qué máquinas priorizar

Orden recomendado de prioridad:

Servidores multiusuario y hosts compartidos.
Bastiones, máquinas de enseñanza, equipos de desarrollo y otros sistemas con cuentas shell normales.
CI runners, máquinas de build y nodos de plataformas de hosting.
Hosts de contenedores y virtualización, sobre todo donde conviven workloads no completamente confiables.
Máquinas con servicios públicos. La vulnerabilidad requiere acceso local, pero el riesgo se combina si un bug web, RCE, contraseña débil u otro camino da al atacante un punto de apoyo de bajo privilegio.

Los escritorios de un solo usuario tienen un riesgo relativamente menor, pero aun así deberían actualizarse con el sistema. La ejecución local de código con bajo privilegio no es rara en escritorios, a través de navegadores, herramientas de desarrollo, scripts y software de terceros.

Recomendaciones de corrección

La solución preferida es instalar el kernel corregido que entrega la distribución y reiniciar.

Los comandos cambian por distribución, pero el principio es el mismo:

Actualizar metadatos de paquetes.
Instalar el paquete kernel que contiene la corrección de CVE-2026-46333.
Reiniciar en el kernel nuevo.
Usar uname -r y el aviso de seguridad de la distribución para verificar que el kernel en ejecución está corregido.

El aviso de AlmaLinux indica que los kernels corregidos están disponibles en repositorios de producción y que los usuarios pueden ejecutar el dnf upgrade habitual y reiniciar. Debian tracker también lista fixed versions para varias ramas.

Importante: si solo instalas un paquete kernel nuevo pero no reinicias, el kernel antiguo vulnerable sigue ejecutándose.

Mitigación temporal: endurecer ptrace_scope

Si no puedes reiniciar de inmediato, endurece primero ptrace_scope de Yama.

Qualys confirmó en una respuesta posterior en oss-security que configurar /proc/sys/kernel/yama/ptrace_scope en 2 (admin-only attach) o 3 (no attach) bloquea las rutas públicas de explotación que conocen. También aclararon que, en teoría, podrían existir otros métodos de explotación, por lo que esto es una mitigación, no una corrección.

Configuración temporal:

`1`	`sudo sysctl -w kernel.yama.ptrace_scope=3`

Configuración persistente:

`1`	`echo 'kernel.yama.ptrace_scope = 3' \| sudo tee /etc/sysctl.d/99-ssh-keysign-pwn.conf`

ptrace_scope=3 desactiva ptrace attach y puede afectar flujos de depuración como gdb y strace -p. Si necesitas depuración en producción, evalúa 2. En cualquier caso, agenda la actualización de kernel y el reinicio cuanto antes.

¿Hay que rotar claves host SSH?

Conviene adoptar una postura conservadora si la máquina tenía alguna de estas condiciones durante la ventana de exposición:

Usuarios locales no confiables.
Hosting compartido o entornos multi-tenant de contenedores/CI.
Vulnerabilidades web, contraseñas débiles, scripts de cadena de suministro u otros caminos que puedan dar un punto de apoyo local.
Procesos locales sospechosos, comportamiento de depuración anómalo o archivos PoC públicos en logs.
Exposición prolongada antes de aplicar la corrección.

Una respuesta conservadora incluye:

Rotar SSH host keys después de parchear y reiniciar.
Actualizar sistemas de gestión de huellas de hosts conocidos.
Notificar a automatizaciones que dependan de esa huella de host.
Revisar alertas de conexión SSH para no confundir cambios legítimos de huella con ataques de intermediario, ni ignorar riesgos reales.

Si sospechas que /etc/shadow se filtró, evalúa también restablecimiento de contraseñas, prohibición de contraseñas débiles y revisión de hashes antiguos que puedan crackearse offline.

Qué monitorear

La ventana de explotación es breve, así que los logs tradicionales podrían no capturarlo todo. Aun así, revisa:

Archivos como ssh-keysign-pwn, chage_pwn o artefactos PoC similares en directorios de usuarios normales.
Actividad de compilación sospechosa, como programas C desconocidos compilados en poco tiempo.
Señales de acceso anómalo a /etc/ssh/ssh_host_*_key o /etc/shadow.
Actividad inusual de pidfd_getfd, ptrace o depuradores.
Reportes externos de cambios inesperados en la huella del host SSH.

Estas señales no prueban que hubo explotación, y su ausencia tampoco prueba que no la hubo. Las prioridades reales siguen siendo parchear, reiniciar, rotar credenciales y aislar el riesgo.

Malentendidos comunes

Primero: no es una vulnerabilidad remota de OpenSSH. El nombre incluye ssh-keysign, pero la causa raíz está en la lógica de comprobación de acceso ptrace del Linux kernel, no en el flujo de autenticación remota de sshd.

Segundo: no tener usuarios locales no elimina todo el riesgo. La vulnerabilidad sí requiere ejecución local, pero muchas cadenas reales obtienen primero un punto de apoyo local de bajo privilegio mediante servicios web, CI, scripts, contraseñas débiles o escapes de contenedor.

Tercero: configurar ptrace_scope no basta. Es una mitigación temporal, no una corrección raíz. La actualización del kernel y el reinicio siguen siendo necesarios.

Cuarto: no haber obtenido root no significa que no haya incidente. La filtración de claves privadas de host SSH o /etc/shadow puede bastar para movimiento lateral, suplantación de host y cracking offline.

Checklist de respuesta

Orden recomendado:

Inventariar hosts Linux afectados, especialmente entornos multiusuario y compartidos.
Revisar avisos oficiales de seguridad de la distribución e identificar la fixed kernel version.
Instalar el kernel corregido y reiniciar.
En máquinas que no puedan reiniciarse de inmediato, configurar kernel.yama.ptrace_scope=2 o 3.
Verificar la versión del kernel en ejecución después de la corrección.
Rotar SSH host keys en máquinas de alto riesgo.
Si se sospecha exposición de /etc/shadow, evaluar restablecimiento de contraseñas y auditoría de cuentas.
Buscar PoCs públicos, compilaciones anómalas y comportamiento local de depuración sospechoso.

Resumen

ssh-keysign-pwn (CVE-2026-46333) es una vulnerabilidad local de filtración de información causada por lógica relacionada con __ptrace_may_access() en el Linux kernel. No permite entrar remotamente de forma directa y no concede una shell de root directa, pero puede permitir que un usuario local de bajo privilegio lea archivos sensibles de alto valor. Eso la vuelve especialmente importante en entornos multiusuario, hosting compartido, CI y hosts de contenedores.

La corrección fiable es actualizar al kernel corregido de la distribución y reiniciar. ptrace_scope=2/3 puede servir como mitigación temporal, pero no reemplaza el parche. En hosts críticos expuestos durante la ventana de riesgo, también conviene evaluar rotación de claves host SSH y riesgo de contraseñas.

Referencias:

Dirty Frag, Copy Fail y Fragnesia: comparación de tres fallos recientes de escalada local en Linux

Fri, 15 May 2026 13:24:04 +0800

En las últimas semanas han aparecido varias vulnerabilidades de escalada local de privilegios en el kernel de Linux: Dirty Frag, Copy Fail y Fragnesia. Parecen parte de una misma familia porque el resultado final es parecido: un usuario local con pocos privilegios podría convertirse en root.

Pero desde el punto de vista operativo no conviene tratarlas como una sola vulnerabilidad. Sus módulos de entrada, rutas de activación, mitigaciones y ritmos de parcheo son distintos. Una lectura más precisa es que exponen un riesgo común en la frontera compleja entre la caché de páginas de Linux, splice, socket buffers y rutas criptográficas.

Este artículo solo analiza riesgos y respuesta. No incluye pasos reproducibles de explotación.

Qué Es Cada Vulnerabilidad

Dirty Frag: CVE-2026-43284

Dirty Frag apunta principalmente a un problema de escritura en la caché de páginas dentro de la ruta de red del kernel de Linux. En los análisis públicos suele aparecer junto con dos problemas: el lado xfrm-ESP, CVE-2026-43284, y el lado rxrpc, CVE-2026-43500.

CVE-2026-43284 está relacionado con el descifrado in-place cuando ESP maneja fragmentos skb compartidos. La clave no es que el atacante modifique directamente un archivo en disco, sino que el kernel escribe en páginas compartidas que no debería modificar y termina afectando el contenido del archivo en la caché de páginas.

Desde operaciones, lo importante es recordar que Dirty Frag toca esp4, esp6 y rxrpc, un conjunto de módulos del kernel y rutas del subsistema de red. Está ligado a IPsec, ESP y RxRPC, por lo que la mitigación temporal también gira alrededor de esos módulos.

Copy Fail: CVE-2026-31431

Copy Fail es una vulnerabilidad de escalada local de privilegios en el kernel de Linux divulgada por Theori / Xint Code. Su entrada no está en la ruta de red de IPsec, sino en la API criptográfica de espacio de usuario del kernel alrededor de algif_aead / AF_ALG.

Las explicaciones públicas la atribuyen a una optimización in-place introducida en 2017. En algunos casos, el kernel no copiaba datos como se esperaba y colocaba páginas de la caché en una ruta de destino escribible. Un atacante puede combinar AF_ALG con splice() para realizar una pequeña escritura controlada sobre páginas respaldadas por la caché.

Su riesgo está en la alta explotabilidad y en el impacto sobre varias distribuciones principales. A diferencia de Dirty Frag, la mitigación temporal de Copy Fail se centra en restringir o desactivar algif_aead, y en limitar la creación de sockets AF_ALG en entornos de contenedores y CI.

Fragnesia: CVE-2026-46300

Fragnesia es otra vulnerabilidad de escalada local de privilegios en el kernel de Linux divulgada por V12 Security, dentro de una superficie de ataque parecida a Dirty Frag. No es el mismo bug que Dirty Frag, pero sigue girando alrededor de módulos relacionados con IPsec ESP / rxrpc y efectos de escritura en la caché de páginas.

AlmaLinux la describe como el tercer problema de local-root en la misma zona amplia del código. El punto clave es que skb_try_coalesce() no conservaba correctamente el marcador de fragment compartido al combinar fragmentos de socket buffer, lo que podía permitir que la ruta de recepción XFRM ESP-in-TCP descifrara in-place sobre páginas externas de la caché.

En resumen, Fragnesia está más cerca de Dirty Frag. Ambas giran alrededor de esp4, esp6, rxrpc, fragmentos skb y rutas de descifrado ESP. Sus mitigaciones temporales también se solapan bastante.

Similitudes: Por Qué Son Peligrosas

El punto común no es que el código exacto esté en el mismo lugar, sino que el resultado del ataque y el modelo de riesgo son muy parecidos.

Primero, las tres son escaladas locales de privilegios. Normalmente el atacante necesita primero ejecutar código local como usuario normal y luego intentar convertirse en root. En un escritorio de un solo usuario no es una intrusión remota de un clic; en servidores multiusuario, CI runners, hosts de contenedores, máquinas de desarrollo compartidas y VPS con SSH expuesto, las entradas de bajo privilegio no son raras.

Segundo, las tres se relacionan con escrituras en la caché de páginas. El atacante no siempre modifica de forma permanente el archivo en disco; puede afectar la copia en memoria. Esto reduce la fiabilidad de las revisiones tradicionales de integridad: el hash del disco puede parecer normal mientras la ruta de ejecución lee contenido contaminado desde la caché.

Tercero, se parecen más a bugs lógicos deterministas que a condiciones de carrera sensibles al tiempo. Los materiales públicos insisten en que no requieren ganar una race condition. Los defensores no deberían subestimar la fiabilidad de explotación por experiencia con fallos más antiguos.

Cuarto, amplifican el riesgo en entornos de contenedores y automatización. Código de bajo privilegio dentro de contenedores, jobs de CI, scripts de compilación o plugins de terceros puede convertir un “problema local” en un problema de plataforma si alcanza las interfaces relevantes del kernel del host.

Diferencias: Una Mitigación No Cubre Todo

La mayor diferencia está en el módulo de entrada.

La entrada crítica de Copy Fail es algif_aead / AF_ALG, parte de la API criptográfica de espacio de usuario del kernel. Su defensa temporal se centra en desactivar o restringir algif_aead, y usar seccomp para impedir que los contenedores creen sockets AF_ALG.

La entrada crítica de Dirty Frag está en xfrm-ESP y rxrpc. Está más cerca de las rutas de protocolo y manejo de socket buffers. La defensa temporal suele considerar desactivar esp4, esp6 y rxrpc, pero eso puede afectar IPsec, VPN, túneles o capacidades de red relacionadas.

Fragnesia también está en una zona cercana a Dirty Frag, pero el problema concreto es que skb_try_coalesce() no conservaba el marcador de fragment compartido. Es más bien otra rama de la superficie de riesgo de Dirty Frag, no un problema de la API criptográfica de Copy Fail.

Por eso, haber tratado Copy Fail no significa que Dirty Frag y Fragnesia estén cubiertas. Del mismo modo, desactivar esp4 / esp6 no elimina automáticamente Copy Fail. Hay que confirmar por separado el estado de parches y la estrategia de mitigación.

Cómo Evaluar la Exposición

Para estas vulnerabilidades no basta con mirar el nombre de la distribución ni la versión mayor del kernel. Las distribuciones hacen backport de correcciones, los proveedores cloud mantienen ramas propias del kernel y las distribuciones empresariales pueden llevar parches adicionales.

Un orden más seguro es:

Revisar el aviso de seguridad de la distribución y el changelog del paquete del kernel.
Confirmar si el paquete de kernel actual corrige el CVE correspondiente.
En servidores cloud, hosts de contenedores y nodos de CI, revisar también avisos del proveedor o de la plataforma.
Para mitigaciones temporales, confirmar si el negocio depende del módulo afectado.
Después de actualizar el kernel, programar reinicio y comprobar que el kernel en ejecución cambió.

La trampa más común es “el paquete está actualizado, pero la máquina no se reinició”. Las vulnerabilidades del kernel no son como actualizaciones de servicios de espacio de usuario. Hasta arrancar con el nuevo kernel, el kernel viejo puede seguir ejecutándose.

Prioridad Operativa

Los sistemas más urgentes no son todas las máquinas Linux por igual. Hay que empezar donde es más probable que exista ejecución de código con pocos privilegios.

Entornos de prioridad alta:

Servidores de login multiusuario
CI / CD runners
Máquinas de compilación y empaquetado de artefactos
Hosts de contenedores y nodos Kubernetes
Máquinas de desarrollo compartidas
Servidores cloud y VPS con SSH expuesto
Plataformas que ejecutan scripts, plugins o colas de tareas de terceros
Máquinas con vulnerabilidades web, contraseñas débiles o señales históricas de compromiso

Las máquinas cerradas, de un solo usuario y sin entrada externa de ejecución de código siguen teniendo riesgo si son vulnerables, pero normalmente pueden ir después.

Cómo Entender la Mitigación Temporal

La mitigación temporal no reemplaza al parche. Su valor es reducir la exposición cuando no se puede reiniciar de inmediato o mientras se esperan paquetes de la distribución.

Para Copy Fail, el foco está en algif_aead y AF_ALG. Si el negocio no usa la interfaz criptográfica AF_ALG del kernel, se puede evaluar desactivar el módulo relacionado. En contenedores, conviene revisar primero las políticas seccomp para que cargas no confiables no puedan crear libremente el socket correspondiente.

Para Dirty Frag y Fragnesia, el foco está en esp4, esp6 y rxrpc. Si el sistema no depende de IPsec ESP, VPN relacionadas, túneles o RxRPC, se puede evaluar una desactivación temporal. No debe hacerse a ciegas en producción porque esos módulos pueden sostener cargas de red reales.

El camino final sigue siendo actualizar el kernel. La mitigación temporal reduce superficie de ataque, pero no demuestra que el sistema sea completamente seguro.

Qué Nos Dicen Estos Tres Fallos

La advertencia importante no es solo el número de CVE. Estos fallos se concentran en rutas del kernel muy complejas: zero-copy, splice, socket buffers, caché de páginas, interfaces criptográficas y optimizaciones de pila de protocolos.

Estas rutas dan grandes beneficios de rendimiento, pero también vuelven más difícil mantener los límites de propiedad. Si un fragment está compartido, si una página puede escribirse in-place o si una optimización realmente solo reduce copias se convierte en parte del límite de seguridad.

Para equipos de seguridad y operaciones, las conclusiones son prácticas:

Tratar la escalada local de privilegios como un amplificador de entradas ya existentes de bajo privilegio.
Los contenedores no son una frontera natural de aislamiento frente a vulnerabilidades del kernel.
Las revisiones de integridad no pueden mirar solo el contenido del disco.
CI, máquinas de compilación y plataformas de plugins deben ser activos de alta prioridad.
En parches de kernel hay que verificar tanto “instalado” como “en ejecución”.

Resumen

Dirty Frag, Copy Fail y Fragnesia son eventos recientes de alta prioridad en la escalada local de privilegios de Linux, pero no son tres nombres del mismo fallo.

Copy Fail pasa por la ruta criptográfica algif_aead / AF_ALG. Dirty Frag pasa por xfrm-ESP y rxrpc. Fragnesia, en una superficie cercana a Dirty Frag, vuelve a disparar riesgo de escritura en la caché de páginas por el manejo de marcadores de fragmentos skb.

La respuesta más sólida es actualizar el kernel según los avisos de la distribución y reiniciar. En sistemas que no puedan actualizarse de inmediato, evaluar la desactivación temporal de módulos o reglas seccomp más estrictas según la entrada real de cada vulnerabilidad. Priorizar entornos multi-tenant, CI, hosts de contenedores y desarrollo compartido.

Referencias:

Notas de Theori sobre Copy Fail: https://github.com/theori-io/copy-fail-CVE-2026-31431
Aviso de CERT-EU sobre Copy Fail: https://cert.europa.eu/publications/security-advisories/2026-005/
Notas de AlmaLinux sobre Dirty Frag: https://almalinux.org/blog/2026-05-07-dirty-frag/
Notas de AlmaLinux sobre Fragnesia: https://almalinux.org/blog/2026-05-13-fragnesia-cve-2026-46300/
Notas del PoC de V12 Security sobre Fragnesia: https://github.com/v12-security/pocs/tree/main/fragnesia

Fragnesia (CVE-2026-46300): impacto y mitigación de una escalada local de privilegios en el kernel de Linux

Fri, 15 May 2026 13:18:01 +0800

El kernel de Linux acaba de sumar otra vulnerabilidad de escalada local de privilegios en una superficie de ataque cercana a Dirty Frag: Fragnesia (CVE-2026-46300).

Según la divulgación de V12 Security, Fragnesia es una vulnerabilidad local de Linux. El atacante no necesita privilegios elevados previos en el host. Si puede ejecutar código local, podría aprovechar un fallo lógico en el subsistema XFRM ESP-in-TCP del kernel para modificar, byte a byte, contenido de archivos de solo lectura a través de la caché de páginas y terminar obteniendo un root shell.

Fuente:

Notas del PoC de V12 Security: https://github.com/v12-security/pocs/blob/main/fragnesia/README.md

Este artículo no cubre pasos reproducibles de explotación. Se centra en los riesgos y la respuesta operativa.

Relación con Dirty Frag

V12 Security clasifica Fragnesia dentro de la familia de vulnerabilidades Dirty Frag. No es el mismo bug que Dirty Frag, sino otro problema en una superficie de ataque relacionada: XFRM ESP-in-TCP en el kernel de Linux.

XFRM es el marco del kernel de Linux para procesar IPsec. ESP-in-TCP está relacionado con transportar tráfico ESP cifrado sobre TCP. El problema de Fragnesia está en la lógica de fragmentos de página compartidos y la combinación de socket buffers: en ciertas condiciones, el kernel puede perder la pista de que un fragment sigue compartido y dejar una zona de escritura controlable.

Este tipo de fallo recuerda a Dirty Pipe / Dirty Frag y otros problemas de escritura en la caché de páginas. El código concreto no es el mismo, pero el efecto vuelve a caer sobre la copia en caché de un archivo de solo lectura.

Por Qué Es Grave

Fragnesia es peligrosa por tres razones.

Primero, es una escalada local de privilegios. Si un atacante ya puede ejecutar código como usuario normal, podría elevarse a root. Esto es especialmente sensible en servidores multiusuario, hosts de contenedores, CI runners, máquinas de desarrollo compartidas, VPS y entornos que exponen acceso shell.

Segundo, no depende de una condición de carrera tradicional. Las notas de V12 describen una ruta que fuerza el procesamiento ESP-in-TCP sobre páginas de archivo ya incorporadas a un socket buffer mediante splice, lo que permite influir byte a byte en el contenido de la caché de páginas. Eso hace que el riesgo sea práctico, no solo teórico.

Tercero, modifica la caché de páginas, no el archivo en disco. El ejemplo público usa /usr/bin/su como objetivo. Tras una explotación correcta, el archivo en disco no queda modificado de forma permanente; el cambio vive en la memoria. Las revisiones que solo comparan hashes o integridad del disco pueden no ver nada extraño.

Ese es el punto incómodo para los administradores: el archivo parece intacto, pero al ejecutar la copia contaminada desde la caché de páginas puede activarse la escalada.

Alcance Conocido

V12 Security indica que los kernels afectados por Dirty Frag y sin los parches relevantes del 13 de mayo de 2026 también están afectados por Fragnesia. Los entornos verificados públicamente incluyen Ubuntu 22.04, Ubuntu 24.04 y kernels como 6.8.0-111-generic.

Hay dos matices importantes.

Primero, no basta con mirar la versión mayor de la distribución. Que Ubuntu 22.04 / 24.04 esté afectado depende del estado real de parches del kernel, no solo del nombre de la distribución.

Segundo, no conviene confiar únicamente en las restricciones predeterminadas de AppArmor para namespaces de usuario sin privilegios. En Ubuntu pueden elevar la barrera, pero la divulgación las trata como un problema adicional de bypass, no como una corrección del fallo.

La forma fiable de decidir sigue siendo revisar los avisos de seguridad de la distribución y las actualizaciones del paquete del kernel.

Mitigación Temporal

Si un sistema no puede actualizar el kernel de inmediato, primero hay que evaluar si depende de los módulos de protocolo relacionados.

La mitigación indicada por V12 es la misma que para Dirty Frag: si el sistema no depende de IPsec ESP ni de RxRPC, se puede evaluar desactivar módulos como esp4, esp6 y rxrpc. Esto puede afectar capacidades de red, así que no debe aplicarse a ciegas en producción. Antes hay que confirmar si el negocio usa IPsec, VPN, túneles o funciones relacionadas del kernel.

Un orden de respuesta más seguro es:

Confirmar si la distribución ya publicó una actualización de seguridad del kernel.
Instalar primero el parche del kernel y programar el reinicio.
Si no se puede actualizar de inmediato, evaluar la desactivación temporal de módulos.
Priorizar sistemas multiusuario y entornos de CI / compilación.
Revisar cuentas locales innecesarias, shell, superficie de escape de contenedores y entradas de ejecución de bajo privilegio.

No hay que tratar la desactivación de módulos como corrección final. Es una reducción temporal de exposición.

Si Se Sospecha Explotación

Una característica de Fragnesia es la contaminación de la caché de páginas. V12 señala que, tras la explotación, la copia del archivo objetivo en la caché puede contener contenido inyectado, y ejecuciones posteriores pueden seguir comportándose de forma anómala hasta que la página sea expulsada o el sistema se reinicie.

Si se sospecha que el sistema fue explotado, conviene al menos:

Preservar logs y registros de auditoría cuanto antes.
Revisar inicios de sesión locales anómalos, actividad de usuarios de bajo privilegio, procesos sospechosos y rastros de root shell.
Limpiar la caché de páginas relevante o reiniciar directamente.
Actualizar a un kernel corregido.
Verificar binarios críticos, pero sin depender solo de hashes del disco.
Rotar credenciales y claves potencialmente expuestas.

En servidores de producción, es mejor tratarlo como un posible incidente de escalada local de privilegios, no solo como una actualización rutinaria.

Qué Máquinas Priorizar

La prioridad no debe repartirse por igual entre todas las máquinas Linux. Hay que empezar por los lugares donde un atacante tiene más probabilidades de obtener ejecución de código con pocos privilegios.

Entornos de mayor prioridad:

Servidores de login multiusuario
CI / CD runners
Máquinas de compilación
Máquinas de desarrollo compartidas
Hosts de contenedores
VPS y servidores cloud
Nodos de borde con SSH expuesto
Plataformas que ejecutan scripts o plugins de terceros

Las máquinas cerradas, de un solo usuario y sin entrada externa de ejecución de código siguen teniendo riesgo si son vulnerables, pero la urgencia puede ser menor.

Resumen

Fragnesia merece atención no por tener un nombre nuevo, sino porque vuelve a llevar la escalada local de privilegios en Linux a una frontera compleja: la caché de páginas y los subsistemas de red del kernel.

Para administradores, lo importante no es estudiar los detalles de explotación, sino confirmar el estado de parches del kernel, evaluar si se depende de ESP / RxRPC, actualizar primero las máquinas más expuestas y entender que “el archivo en disco no cambió” no significa “el sistema no fue afectado”.

Si el sistema está afectado, la respuesta final sigue siendo instalar cuanto antes la actualización del kernel ofrecida por la distribución. Desactivar módulos temporalmente es solo una medida puente, no un reemplazo del parche.

Dirty Frag CVE-2026-43284: riesgo de escalada local en Linux y guía de mitigación

Sat, 09 May 2026 07:25:55 +0800

Dirty Frag es un conjunto de vulnerabilidades de escalada local de privilegios en el kernel Linux, divulgadas en mayo de 2026 y con indicios de explotación activa. Microsoft la describe como un riesgo post-compromiso: después de que un atacante consigue ejecución con pocos privilegios, puede usar el fallo para escalar a root. Ubuntu también clasifica CVE-2026-43284 como High.

El peligro no está en un “compromiso remoto de un clic”. El peligro está en que, una vez dentro, el atacante puede ampliar el control rápidamente. Si consigue ejecución local mediante credenciales SSH débiles, una web shell, escape de contenedor, una cuenta de servicio con pocos privilegios o acceso remoto tras phishing, Dirty Frag puede permitir root y luego desactivar herramientas de seguridad, leer credenciales, manipular logs, moverse lateralmente o persistir.

Qué CVE están implicados

La información pública asocia Dirty Frag principalmente con dos identificadores:

CVE-2026-43284: relacionado con la ruta xfrm/ESP del kernel Linux. Las referencias de Microsoft a esp4 y esp6 pertenecen a esta zona de riesgo.
CVE-2026-43500: Microsoft indica que está relacionado con rxrpc, pero al 8 de mayo de 2026 el CVE aún no estaba publicado en NVD y el estado de parches seguía evolucionando.

Por eso no conviene mirar solo un CVE. Es más seguro revisar si esp4, esp6, rxrpc y funciones relacionadas con xfrm/IPsec están activas, son necesarias y ya tienen parche de la distribución.

Explicación técnica resumida

Según Microsoft y Ubuntu, CVE-2026-43284 afecta al manejo de red y fragmentos de memoria del kernel Linux, especialmente al tratamiento de fragmentos de página compartidos en la ruta ESP/IPsec.

En términos simples, páginas de datos pueden adjuntarse a buffers de red mediante mecanismos como splice. Si rutas posteriores del kernel tratan esos fragmentos como datos privados que se pueden modificar in-place, puede producirse descifrado o modificación in-place donde no debería. Un atacante puede manipular el comportamiento de page cache y acabar logrando escalada local.

Esto se parece a CopyFail (CVE-2026-31431): ambos giran en torno a page cache de Linux, rutas de datos del kernel y escalada local. Dirty Frag es peligroso porque introduce más rutas de ataque y puede ser más fiable que exploits LPE tradicionales dependientes de ventanas de carrera estrechas.

Entornos prioritarios

Dirty Frag es una vulnerabilidad local, así que el atacante ya debe poder ejecutar código en la máquina. Prioriza:

Servidores Linux con SSH expuesto.
Servidores web donde pueda escribirse una web shell.
Hosts multiusuario, bastiones, máquinas de desarrollo y runners CI/CD.
Hosts de contenedores, nodos Kubernetes y nodos OpenShift.
Sistemas que usen IPsec, VPN, xfrm o funcionalidad relacionada con RxRPC.
Servidores con Ubuntu, RHEL, CentOS Stream, AlmaLinux, Fedora, openSUSE y otras distribuciones comunes.

Si un servidor no tiene usuarios locales, contenedores ni rutas de aplicación expuestas, el riesgo es menor. Pero cualquier sistema donde un atacante pueda conseguir una shell de bajo privilegio debe tratar esto como un problema de kernel de alta prioridad.

Primero parchear

La corrección más segura es instalar la actualización de seguridad del kernel de tu distribución y reiniciar con el kernel nuevo.

La página de Ubuntu indica que CVE-2026-43284 se publicó el 8 de mayo de 2026 y se clasifica como High. Microsoft también dice que Linux Kernel Organization publicó correcciones para CVE-2026-43284 y recomienda aplicar parches cuanto antes.

Empieza revisando el sistema:

1
2

uname -a
cat /etc/os-release

Después actualiza el kernel según la distribución:

`1`	`sudo apt update && sudo apt full-upgrade`

`1`	`sudo dnf update`

Tras actualizar, confirma que el sistema arrancó con el kernel nuevo:

`1`	`uname -r`

Instalar paquetes de kernel sin reiniciar deja el kernel antiguo ejecutándose, así que la vulnerabilidad puede seguir presente.

Mitigación temporal: desactivar módulos relacionados

Si aún no hay parches, o producción no puede reiniciarse de inmediato, evalúa si puedes desactivar temporalmente los módulos relacionados. La mitigación de Ubuntu bloquea la carga de esp4, esp6 y rxrpc, y los descarga si ya están cargados.

Crear reglas modprobe:

1
2
3

echo "install esp4 /bin/false" | sudo tee /etc/modprobe.d/dirty-frag.conf
echo "install esp6 /bin/false" | sudo tee -a /etc/modprobe.d/dirty-frag.conf
echo "install rxrpc /bin/false" | sudo tee -a /etc/modprobe.d/dirty-frag.conf

Actualizar initramfs para evitar carga temprana:

`1`	`sudo update-initramfs -u -k all`

Descargar módulos ya cargados:

`1`	`sudo rmmod esp4 esp6 rxrpc 2>/dev/null`

Comprobar si siguen cargados:

`1`	`grep -qE '^(esp4\|esp6\|rxrpc) ' /proc/modules && echo "Affected modules are loaded" \|\| echo "Affected modules are NOT loaded"`

Si un módulo está en uso, puede no descargarse. En ese caso, la regla de bloqueo probablemente solo surtirá efecto tras reiniciar.

Evalúa impacto antes de desactivar

No pegues esos comandos a ciegas. esp4, esp6 y funciones xfrm/IPsec pueden usarse en VPN, túneles, redes cifradas, redes Kubernetes/contenedores o configuraciones empresariales. rxrpc también puede afectar cargas que dependan de ese protocolo.

Antes de ejecutar en producción, revisa al menos:

1
2
3

lsmod | grep -E '^(esp4|esp6|rxrpc|xfrm)'
ip xfrm state
ip xfrm policy

Si dependes de IPsec VPN o funciones relacionadas del kernel, desactivar módulos puede cortar conectividad. En ese caso, es mejor programar parcheo del kernel y ventana de mantenimiento que depender mucho tiempo del bloqueo de módulos.

No omitas comprobaciones post-compromiso

Microsoft recuerda que la mitigación no necesariamente revierte cambios ya introducidos por explotación exitosa. Si el atacante ya obtuvo root, puede haber dejado persistencia, modificado archivos, alterado logs o accedido a datos de sesión.

Comprueba al menos:

journalctl -k --since "24 hours ago" | grep -Ei "dirty|frag|exploit|segfault|xfrm|rxrpc|esp"
last -a
lastlog
sudo find /tmp /var/tmp /dev/shm -type f -mtime -3 -ls
sudo find / -perm -4000 -type f -mtime -7 -ls 2>/dev/null

También revisa:

Lanzamientos anómalos de su, sudo o procesos SUID/SGID.
Ejecutables ELF creados recientemente.
Archivos PHP, JSP o ASP sospechosos en directorios web.
Cambios en SSH authorized_keys.
Persistencia nueva en systemd services, cron o rc.local.
Contenedores privilegiados o montajes sospechosos en hosts de contenedores.

Si sospechas explotación, aísla el host, conserva evidencias, rota credenciales y luego limpia. No asumas que descargar módulos o limpiar cachés hace seguro el sistema.

Sobre drop_caches

Microsoft menciona que en algunos escenarios de verificación de integridad post-explotación puede evaluarse limpiar caché:

`1`	`echo 3 \| sudo tee /proc/sys/vm/drop_caches`

Esto no es una corrección de la vulnerabilidad ni un comando de limpieza de incidente. Limpiar cachés puede aumentar I/O de disco y afectar rendimiento en producción. Úsalo solo como paso auxiliar tras entender el impacto. La corrección real sigue siendo parchear, reiniciar, verificar integridad y revisar persistencia.

Orden recomendado de respuesta

Para producción, una secuencia razonable es:

Inventariar activos Linux y versiones de kernel.
Priorizar sistemas con SSH expuesto, workloads web, hosts de contenedores y acceso multiusuario.
Parchear y reiniciar cuanto antes los sistemas que puedan reiniciarse.
En sistemas que aún no puedan parchearse o reiniciarse, evaluar desactivar esp4, esp6 y rxrpc.
Aumentar monitorización de su, SUID/SGID, ELF sospechosos, web shells e indicadores de escape de contenedor.
Ejecutar comprobaciones post-compromiso y rotar credenciales en hosts sospechosos.

Resumen

Dirty Frag no es una vulnerabilidad “remote one-click”, pero aumenta mucho el riesgo tras una intrusión. Si un atacante puede ejecutar código local con pocos privilegios, CVE-2026-43284 y la superficie asociada a rxrpc pueden permitir escalada a root.

Para administradores, la prioridad no es estudiar PoC. La prioridad es confirmar exposición del kernel, instalar actualizaciones de seguridad de la distribución y reiniciar, evaluar mitigaciones de bloqueo de módulos antes de la ventana de parcheo, e inspeccionar sistemas expuestos o sospechosos en busca de problemas de integridad y persistencia.

Referencias:

Guía de Btrfs Scrub: verificación de datos, reparación automática y mantenimiento periódico

Sat, 09 May 2026 07:11:01 +0800

Btrfs scrub es una de las funciones de mantenimiento más importantes y más malentendidas de Btrfs. No es fsck en el sentido tradicional. Es una pasada de validación online que lee datos y metadata del filesystem, verifica checksums, superblocks, metadata block headers y errores de lectura del disco, e intenta reparar daños cuando existe una réplica buena conocida.

Si usas Btrfs en un NAS, servidor doméstico, disco de backup o array multidispositivo, scrub debería formar parte del mantenimiento periódico. Su valor no es “ejecutarlo después del desastre”, sino detectar corrupción silenciosa temprano, mientras los discos aún se pueden leer y todavía existen réplicas buenas.

Qué comprueba scrub

Según la documentación oficial de Btrfs, scrub recorre datos y metadata del filesystem y comprueba principalmente:

Errores de checksum en bloques de datos.
Errores básicos de super block.
Errores básicos de metadata block header.
Errores de lectura de disco.

En filesystems que usan perfiles de block group replicados, como RAID1, scrub sobre un montaje read-write puede reparar automáticamente algunos daños. La reparación no es recuperación mágica. Btrfs copia datos buenos verificados desde otra réplica.

Este punto es clave: la reparación de scrub depende de que exista una copia buena conocida. En un disco único con una sola copia de los datos, scrub puede detectar errores de checksum, pero normalmente no puede restaurar el contenido original por sí mismo.

Comandos comunes

Iniciar scrub sobre un punto de montaje:

`1`	`sudo btrfs scrub start /`

Ejecutarlo en foreground, útil para observar manualmente:

`1`	`sudo btrfs scrub start -B /`

Ver estado:

`1`	`sudo btrfs scrub status /`

Cancelar un scrub en ejecución:

`1`	`sudo btrfs scrub cancel /`

Reanudar un scrub interrumpido:

`1`	`sudo btrfs scrub resume /`

Si especificas una ruta montada de Btrfs, Btrfs hace scrub de todos los dispositivos del filesystem en paralelo. Si especificas un dispositivo, solo se hace scrub de ese dispositivo. Pero si la réplica del dispositivo indicado no puede leerse o verificarse, Btrfs intenta leer una copia buena desde otro dispositivo.

Scrub no es fsck

Este es el error más común. Scrub no es btrfs check ni un comprobador tradicional de filesystem.

Scrub puede:

Usar checksums para detectar corrupción de datos o metadata.
Reparar automáticamente cuando existe otra réplica fiable.
Detectar errores de lectura de disco y algunos errores estructurales básicos.

Scrub no puede:

Reconstruir datos cuando no existe una réplica buena.
Sustituir una comprobación offline del filesystem.
Reparar toda corrupción compleja de estructuras de árbol.
Garantizar que el contenido a nivel de aplicación sea correcto.

Si las estructuras del filesystem están gravemente dañadas, pueden necesitarse herramientas como btrfs check bajo guía experta. No trates scrub como un comando universal de reparación.

Riesgos de archivos NOCOW

La documentación de Btrfs advierte de un punto importante: al establecer el atributo NOCOW con chattr +C, la implementación actual también activa implícitamente NODATASUM. Eso significa que los datos del archivo no tienen checksum.

Scrub aún puede validar y reparar la metadata de esos archivos, pero no puede validar el contenido de sus datos. Esto es especialmente arriesgado en configuraciones con varias réplicas: si una copia de un archivo NOCOW se daña, Btrfs no tiene checksum de datos para saber qué réplica es buena, así que puede devolver contenido dañado a user space.

Algunas aplicaciones usan +C por defecto por rendimiento. systemd journal y algunos escenarios de libvirt storage pool son ejemplos conocidos. Para imágenes de VM, bases de datos y directorios de logs puede tener sentido por rendimiento, pero significa que no puedes esperar que scrub proteja sus datos igual que protege archivos COW normales.

Read-only scrub todavía puede escribir

Otro punto contraintuitivo: ejecutar read-only scrub en un filesystem montado read-write puede causar algunas escrituras.

La documentación oficial explica que se debe a una limitación de diseño para evitar carreras entre marcar block groups como read-only y escribir de vuelta block group items. En otras palabras, si quieres que scrub no escriba nada, debes ejecutar read-only scrub sobre un filesystem montado read-only. Añadir una opción de read-only scrub sobre un montaje read-write no basta.

Para usuarios normales, esto significa:

El scrub online rutinario puede ejecutarse sobre un montaje read-write.
Para forense, análisis de fallos o comprobaciones muy conservadoras, confirma antes el estado del montaje.
No interpretes read-only scrub como cero escrituras absolutas.

Interrupción y reanudación

En kernels recientes, scrub puede ser interrumpido por eventos como suspend, hibernate, filesystem freezing, cgroup freezing y pending signals. Tras una interrupción, el scrub en ejecución se cancela, pero puede reanudarse con btrfs scrub resume.

El estado de scrub se registra en:

`1`	`/var/lib/btrfs/`

Los nombres suelen parecerse a:

1
2

scrub.status.UUID
scrub.progress.UUID

El archivo de estado se actualiza periódicamente. Un scrub reanudado continúa desde la última posición guardada, no desde el principio.

Cada cuánto ejecutarlo

La recomendación oficial es una vez al mes. En la práctica, ajusta según la importancia de los datos y el estado de los discos.

Calendarios comunes:

NAS doméstico: una vez al mes.
Discos de backup: tras sesiones largas conectados o una vez al mes.
Arrays multidispositivo importantes: una vez al mes, o más a menudo si hace falta.
Migración a disco nuevo o sospecha de fallo: ejecutar justo después de migrar.

Scrub puede usar alrededor del 80% del ancho de banda del dispositivo en un filesystem inactivo, así que no conviene ejecutarlo en horas pico. En arrays HDD, la latencia puede subir notablemente durante scrub. En SSD también añade read amplification y presión de fondo.

Limitar ancho de banda de scrub

Antes se usaba ionice para reducir el impacto de scrub sobre I/O foreground. La documentación oficial advierte que no todos los I/O schedulers lo soportan igual. CFQ ya no está disponible de forma general. BFQ soporta el comportamiento de prioridad relacionado, pero conviene entenderlo antes de usarlo. Para schedulers comunes como mq-deadline, suele ser mejor usar cgroup2 I/O controller o límites específicos de Btrfs.

Ejemplo con systemd para limitar ancho de banda de lectura:

`1`	`sudo systemd-run -p "IOReadBandwidthMax=/dev/sdx 10M" btrfs scrub start -B /`

Desde Linux 5.14, Btrfs puede establecer límites de scrub por dispositivo mediante sysfs:

`1`	`echo 100m \| sudo tee /sys/fs/btrfs/FSID/devinfo/DEVID/scrub_speed_max`

Mostrar límites actuales:

`1`	`sudo btrfs scrub limit /`

Esta configuración no es persistente y desaparece al desmontar el filesystem. Sustituye FSID y DEVID por los valores reales de tu sistema. Puedes empezar comprobando:

1
2

sudo btrfs filesystem show /
ls /sys/fs/btrfs/

Flujo práctico de mantenimiento

Un flujo razonable de mantenimiento Btrfs puede ser:

sudo btrfs scrub start -B /
sudo btrfs scrub status /
sudo btrfs device stats /
dmesg -T | grep -Ei "btrfs|checksum|i/o error|read error"

Si scrub informa corrected errors, Btrfs reparó datos desde una réplica buena, pero no debes ignorarlo. Sigue revisando SMART, cables, alimentación, controladores y Btrfs device stats.

Si scrub informa uncorrectable errors, Btrfs no encontró una copia buena. Haz backup cuanto antes de lo que aún pueda leerse, identifica archivos o dispositivos afectados, y reemplaza hardware o restaura desde backup según corresponda.

Resumen

Btrfs scrub tiene un papel claro: verificación online de datos y reparación desde réplicas. No es fsck y no es backup.

Funciona mejor en filesystems Btrfs con checksums y réplicas redundantes, donde puede encontrar corrupción silenciosa de forma periódica y restaurar desde copias buenas. No puede proteger datos de archivos NOCOW sin checksum, ni recuperar contenido dañado si no hay una réplica buena.

Si guardas datos importantes en Btrfs, ejecuta scrub mensualmente y úsalo junto con SMART, device stats, backups y alertas. La seguridad de datos fiable viene de checksums, redundancia, monitorización y backups trabajando juntos, no de un solo comando.

Referencias:

Documentación oficial de Btrfs: Scrub

¿F2FS congela un HC620 SMR? Guía de diagnóstico para discos SMR en Linux

Fri, 08 May 2026 22:34:39 +0800

Cuando un HC620 de helio con SMR se usa con F2FS, síntomas como congelamientos del sistema, aplicaciones sin respuesta y iowait alto durante mucho tiempo normalmente no se deben a una sola opción mal configurada. Son el resultado de un choque entre las características del dispositivo y la política del filesystem.

Western Digital Ultrastar DC HC620 es un disco Host-managed SMR. Encaja mejor con escrituras secuenciales, cargas zoned-aware y stacks de software que entienden las restricciones del dispositivo. F2FS es un filesystem log-structured diseñado para flash. Aunque puede reorganizar muchas escrituras aleatorias como escrituras secuenciales, la falta de espacio libre, el GC frecuente o las actualizaciones intensas de metadata pueden llevar a un disco mecánico SMR a ciclos internos largos de mantenimiento.

Primero confirma si es este problema

Empieza con estas comprobaciones:

1
2
3

iostat -x 1
iotop -oPa
dmesg -T | grep -Ei "f2fs|blk|zoned|reset|timeout|I/O error"

Si %util se mantiene cerca de 100%, await es alto y muchos procesos quedan en estado D, el cuello de botella probablemente está en el I/O del dispositivo de bloques.

Luego confirma si el disco aparece como dispositivo zoned:

1
2

lsblk -o NAME,MODEL,SIZE,ROTA,ZONED,SCHED,MOUNTPOINTS
cat /sys/block/sdX/queue/zoned

Si es Host-managed SMR, un filesystem normal y cargas con escrituras aleatorias pueden rendir muy mal. A diferencia de muchos SMR de escritorio gestionados por el propio disco, esta clase depende más de que el software del host entienda las reglas de escritura.

Por qué F2FS puede amplificar el bloqueo

El problema de SMR es que no puede sobrescribir ubicaciones arbitrarias tan libremente como un disco CMR. Las pistas se superponen para aumentar capacidad. Cuando las escrituras se vuelven aleatorias, las sobrescrituras son frecuentes o la caché se agota, el disco necesita mover y reorganizar datos.

F2FS fue creado para NAND flash. Usa escrituras log-structured y recupera espacio mediante segment cleaning y garbage collection. En SSD esto suele ser natural porque no hay seek mecánico. En discos mecánicos, especialmente SMR, las lecturas y escrituras generadas por GC pueden convertirse en tail latency severa.

Cuando background GC de F2FS, escrituras foreground, checkpoints, actualizaciones de metadata y la limpieza SMR interna del disco se superponen, la cola de I/O puede permanecer saturada durante mucho tiempo. En espacio de usuario, copiar archivos, borrar directorios, descargar, descomprimir o escribir en bases de datos puede hacer que el sistema parezca congelado.

Empieza con opciones de montaje conservadoras

Si no puedes migrar inmediatamente, ajusta primero /etc/fstab:

`1`	`UUID=xxxx /data f2fs defaults,nodiscard,active_logs=2,gc_merge,flush_merge,lazytime 0 0`

Qué hace cada opción:

nodiscard: desactiva discard en tiempo real. Los discos mecánicos normalmente no necesitan TRIM/discard frecuente como un SSD.
active_logs=2: F2FS admite 2, 4 o 6 active logs; el valor por defecto suele ser 6. Bajar a 2 puede reducir presión de seek por logs concurrentes.
gc_merge: permite que el hilo de background GC gestione algunas peticiones de foreground GC, reduciendo bloqueos cuando un proceso dispara GC lento.
flush_merge: fusiona peticiones de cache flush, útil si el dispositivo maneja flush lentamente.
lazytime: reduce escrituras de metadata causadas por algunas actualizaciones de tiempo de acceso.

No trates checkpoint=disable como una opción normal de rendimiento. Puede reducir presión de checkpoint, pero aumenta el riesgo tras cortes de energía o fallos. La documentación del kernel también indica que el filesystem sigue necesitando GC mientras checkpoint está desactivado para garantizar espacio utilizable. Si no entiendes bien el coste, no lo uses como solución permanente.

Ajusta el I/O scheduler

Los discos mecánicos y SMR suelen necesitar fusión de peticiones y control de latencia. Mira primero el scheduler actual:

`1`	`cat /sys/block/sdX/queue/scheduler`

Puedes probar mq-deadline:

`1`	`echo mq-deadline \| sudo tee /sys/block/sdX/queue/scheduler`

Para uso de escritorio, también merece probar bfq. No mires solo throughput secuencial. Observa si bajan los bloqueos, si await mejora y si el sistema se siente más estable.

Limita el background GC de F2FS

La ruta sysfs de F2FS depende del nombre real del dispositivo. Compruébalo primero:

`1`	`ls /sys/fs/f2fs/`

Luego ajusta el intervalo de GC para el dispositivo correspondiente:

1
2

echo 60000 | sudo tee /sys/fs/f2fs/sdX/gc_min_sleep_time
echo 120000 | sudo tee /sys/fs/f2fs/sdX/gc_max_sleep_time

Aquí sdX es solo un ejemplo. El nombre real puede ser sda1, dm-0 u otro. Aumentar GC sleep time reduce la frecuencia con la que background GC compite por I/O, pero la recuperación de espacio será más lenta. Si el disco está casi lleno, puede volver a dispararse foreground GC, así que conviene dejar espacio libre suficiente.

Mejores opciones a largo plazo

Si el disco guarda datos importantes, la opción más segura a largo plazo es hacer backup y cambiar de filesystem, o usar un disco más adecuado.

Para discos mecánicos grandes, considera:

XFS: adecuado para archivos grandes, discos de backup, bibliotecas multimedia, archivos y escrituras secuenciales.
EXT4: compatible, estable y con mucha documentación de diagnóstico.

Si el disco es Host-managed SMR, confirma también que kernel, controlador, filesystem y aplicaciones soportan realmente zoned block devices. De lo contrario, usarlo como un disco normal de escrituras aleatorias puede provocar bloqueos largos e impredecibles.

Consejos prácticos

Este tipo de disco encaja mejor con datos fríos, archivos, backups, multimedia y escrituras secuenciales. No es buena opción para cachés de descarga, imágenes de contenedores, discos de VM, bases de datos, descompresión frecuente o escrituras aleatorias de archivos pequeños.

Si debes seguir usando F2FS, al menos haz esto:

Desactiva discard en tiempo real.
Usa active_logs=2 para reducir logs concurrentes.
Activa gc_merge y flush_merge.
Mantén bastante espacio libre.
Evita colocar descargas, bases de datos e imágenes de VM en este disco.
Observa iostat -x 1, no solo la velocidad media.

En resumen, los congelamientos de HC620 + F2FS aparecen cuando se combinan las restricciones de escritura de SMR, el GC de F2FS y la tail latency de un disco mecánico. La mitigación a corto plazo es ajustar opciones de montaje, scheduler y background GC. La solución a largo plazo es migrar a XFS/EXT4 o usar el SMR solo para cargas secuenciales de archivo.

Referencias:

Hoja de ruta de Canonical para Ubuntu AI: inferencia local primero, sin integración forzada

Fri, 08 May 2026 22:23:46 +0800

La hoja de ruta de Canonical para AI en Ubuntu no destaca por “meter AI en todas partes”, sino por intentar una vía más prudente: funciones por capas, desactivadas por defecto, activadas solo cuando el usuario lo elige explícitamente y con inferencia local como prioridad.

Esto contrasta con parte de la polémica alrededor de la AI a nivel de sistema en Windows y macOS. Ubuntu no apunta a una capa global de AI imposible de evitar ni a un único interruptor general. La idea es separar las capacidades de AI en herramientas relativamente independientes, para que el usuario decida si las instala, si las activa, qué modelo usa y si los datos salen de la máquina.

Primero, la fecha: no es Ubuntu 26.04 LTS

La hoja de ruta apunta sobre todo a Ubuntu 26.10 “Questing Quokka”, previsto para el 9 de octubre de 2026. Canonical planea introducir algunas herramientas de AI como previews experimentales, no como funciones por defecto dentro de Ubuntu 26.04 LTS.

Este punto es clave. Las versiones LTS priorizan estabilidad, despliegues empresariales y mantenimiento de seguridad. No sería razonable convertir funciones de AI de escritorio aún exploratorias en experiencia predeterminada de una LTS. Lo más lógico es probarlas primero en una versión regular como 26.10, recibir feedback de desarrolladores y usuarios tempranos, y decidir después qué debe llegar a futuras versiones de soporte prolongado.

Inferencia local primero; la nube no es la opción por defecto

Uno de los principios centrales es local inference first: por defecto, la inferencia debe ejecutarse en la máquina del usuario. Las peticiones solo deberían salir del equipo si el usuario configura explícitamente un proveedor cloud, un servidor propio o un servicio empresarial de modelos.

La razón es práctica. La AI a nivel de sistema puede tocar salidas de comandos, logs, rutas de archivos, errores y configuración del sistema. Enviar esa información automáticamente a la nube, aunque sea para explicar un error, crea riesgos claros de privacidad y cumplimiento.

Por eso, la dirección de Ubuntu no parece ser una puerta de entrada a AI en la nube, sino una capa de inferencia intercambiable. El usuario puede elegir un modelo local, un servicio interno de la empresa o, si lo necesita, un servicio gestionado por Canonical. Lo importante es no quedar atado a un solo proveedor de modelos.

AI CLI: empezar por la terminal

Una de las primeras funciones prácticas podría ser AI Command Line Helper, conocido como ai-cli.

No pretende reemplazar el shell ni ejecutar comandos peligrosos automáticamente. Su función es ayudar a entender comandos, logs, unidades systemd, salidas de error y estado del sistema. Por ejemplo, puede explicar por qué falló un servicio o aclarar el significado de una opción de línea de comandos.

Este punto encaja bien con la base de usuarios de Ubuntu. Muchos usuarios de Ubuntu Desktop y Server ya trabajan en la terminal. En vez de empezar con una ventana de chat llamativa, tiene sentido ubicar la AI en diagnóstico de errores, explicación de comandos y ayuda operativa.

Pero los límites de seguridad deben ser claros. Los logs pueden contener tokens, direcciones internas, nombres de usuario, rutas, fragmentos de claves o información de negocio. Aunque la inferencia local sea el valor por defecto, la herramienta debería animar a redactar datos sensibles. Si el usuario elige un backend cloud, debe quedar claro qué se enviará.

Settings Agent: configuración del sistema con lenguaje natural

Otra dirección es Settings Agent, una forma de consultar o cambiar configuración del sistema con lenguaje natural.

Suena sencillo, pero es fácil hacerlo mal. Un Settings Agent maduro no debería leer la pantalla, adivinar botones y simular clics. Debería usar APIs internas controladas: qué puede leer, qué puede modificar, cuándo requiere confirmación y cómo revierte errores.

Por eso parece más una línea de trabajo posterior a 26.10 que una función completa inmediata. Si se hace bien, puede reducir mucho la fricción para configurar Linux de escritorio. Si se hace de forma agresiva, puede convertirse en un nuevo riesgo de seguridad.

Por qué no hace falta empezar por un “interruptor total” de AI

Muchos usuarios temen que, cuando un sistema operativo incorpora AI, esta aparezca por todas partes y sea difícil desactivarla por completo. Por eso surge una pregunta natural: ¿debería Ubuntu tener un kill switch global para AI?

La respuesta de Canonical parece ser que, si las funciones de AI son opt-in, están separadas por capas y se pueden instalar y configurar de forma independiente, un interruptor global no es la primera prioridad. Es decir, el diseño intenta evitar el patrón de “activado por defecto, integrado profundamente y luego el usuario debe desactivarlo”.

Que eso sea suficiente dependerá de la implementación. Si las herramientas de AI no se activan por defecto, no se conectan remotamente por defecto, no recopilan datos automáticamente y cada función tiene controles claros, el usuario no debería tener que buscar opciones ocultas para apagar AI.

Qué significa para desarrolladores y empresas

Para desarrolladores, el valor práctico de herramientas como AI CLI es reducir el tiempo dedicado a documentación, lectura de logs y diagnóstico de problemas del sistema. No sustituye el criterio técnico; automatiza muchas tareas de “ayúdame a entender esta salida”.

Para empresas, la inferencia local y los backends intercambiables son todavía más importantes. Muchas organizaciones no pueden enviar código fuente, logs, datos de clientes o información de infraestructura a servicios públicos de modelos. Si Ubuntu conecta la AI de sistema con modelos locales, servicios privados de inferencia y permisos empresariales, puede ofrecer asistencia controlable en entornos regulados.

También es una oportunidad para el escritorio y la estación de trabajo Linux. Windows y macOS pueden convertir la AI en parte del ecosistema del proveedor. La ventaja de Ubuntu está en ser abierto, auditable, reemplazable y autohospedable. Si Canonical mantiene esos principios, la AI puede reforzar la experiencia profesional en Linux.

No conviene sobreinterpretar

Todavía es pronto para afirmar que Ubuntu vaya a preinstalar un modelo pequeño concreto, que Ubuntu 26.04 incluya un modo de auditoría de AI o que exista un comando fijo llamado ubuntu-ai. Lo más claro en la información pública es la dirección, no la forma final del producto.

La lectura más prudente es esta: Canonical está preparando un marco de herramientas AI a nivel de sistema para Ubuntu, empezando por ayuda en la línea de comandos, asistencia de configuración, inferencia local y elección de backend. La postura por defecto es que elija el usuario, no el sistema.

Resumen

Lo interesante de la hoja de ruta de AI de Ubuntu no es que Ubuntu “se sume a la ola de AI”, sino que intenta definir una forma más contenida de integrar AI en un sistema operativo open source: la inteligencia puede ser infraestructura, pero privacidad, control y elección del usuario deben ir primero.

Si las funciones experimentales de 26.10 cumplen esos principios, Ubuntu puede seguir un camino distinto al de los sistemas de consumo: AI no como un espacio inevitable dentro del sistema, sino como una capa de productividad seleccionable, reemplazable y auditable.

Referencias:

Como elegir una distribucion Linux de escritorio en 2026: comparativa entre Ubuntu, Deepin/UOS, Linux Mint y Fedora

Thu, 07 May 2026 21:17:11 +0800

Al elegir una distribucion Linux de escritorio en 2026, lo importante no es cual es la mas “pura” ni la mas “avanzada”, sino cual puedes usar todos los dias con comodidad.

Linux de escritorio es distinto de Linux para servidores. En servidores pesan mas el ciclo de vida, la estabilidad de paquetes y las normas de operacion. En el escritorio tambien importan la interfaz, los controladores, la tienda de aplicaciones, los metodos de entrada, el software de oficina, la tarjeta grafica, Bluetooth, el audio, el panel tactil, los monitores externos y todas esas pequenas molestias del uso diario.

Si quieres pelearte menos con el sistema, empieza mirando Ubuntu, Linux Mint y Deepin/UOS. Si eres desarrollador y aceptas usar una pila de software mas nueva con un ritmo tecnologico mas rapido, Fedora merece atencion.

Conclusion rapida

Distribucion	Mas adecuada para	Fortalezas principales	Puntos a tener en cuenta
Ubuntu 26.04 LTS	Principiantes, desarrolladores, equipo principal	Mucha documentacion, ecosistema completo, buen soporte de hardware y software	GNOME por defecto requiere adaptacion; la estrategia de Snap no gusta a todos
Deepin / UOS	Usuarios chinos, entornos localizados, quienes valoran la experiencia visual	Bonita y facil de usar, buena localizacion china, fuerte compatibilidad con software domestico y empresarial	La edicion comunitaria y la comercial tienen posiciones distintas; conviene entender su estrategia de actualizaciones
Linux Mint	Migracion de Windows a Linux, usuarios que priorizan estabilidad	Interfaz familiar, muy facil de usar, escritorio Cinnamon estable	Ritmo mas lento en tecnologias nuevas; la pila por defecto no es agresiva
Fedora	Desarrolladores y usuarios que quieren tecnologia Linux reciente	Kernel nuevo, GNOME nuevo, adopcion rapida de nuevas tecnologias	Actualizaciones frecuentes; menos comoda que una LTS para usuarios conservadores

En una frase:

Principiantes y escritorio principal: Ubuntu 26.04 LTS.
Experiencia china y localizacion: Deepin / UOS.
Migracion suave desde Windows: Linux Mint.
Desarrolladores y exploracion de tecnologias nuevas: Fedora.

Ubuntu 26.04 LTS: el escritorio todoterreno

Ubuntu 26.04 LTS Resolute Raccoon se publico en abril de 2026. Como version LTS, es adecuada para un escritorio principal de largo plazo.

La ventaja de Ubuntu es muy directa: tiene mas documentacion, mas tutoriales y es mas facil encontrar respuestas cuando algo falla. Si quieres instalar VS Code, Docker, controladores NVIDIA, Steam, Chrome, Slack, JetBrains, CUDA, Python o Node.js, Ubuntu suele ser uno de los objetivos prioritarios para fabricantes y comunidad.

Ubuntu 26.04 LTS es adecuada para:

quienes usan Linux de escritorio en serio por primera vez;
usuarios que quieren un sistema principal de largo plazo;
desarrolladores que necesitan un entorno Linux estable;
usuarios que necesitan muchos tutoriales, controladores y soporte de software comercial;
quienes quieren conectar el ecosistema de escritorio, servidor y WSL.

Sus fortalezas:

ciclo de vida LTS largo;
imagenes oficiales y documentacion maduras;
escritorio GNOME moderno, con buena experiencia en panel tactil y multiples monitores;
ecosistema completo de controladores, nube, contenedores y herramientas de desarrollo;
bajo coste de busqueda cuando aparece un problema.

El punto principal es que Ubuntu usa GNOME por defecto, y su logica no es igual a la de Windows. Los principiantes pueden necesitar acostumbrarse a la vista de actividades, el Dock, los espacios de trabajo y el lanzador de aplicaciones. Ubuntu tambien sigue impulsando Snap, y algunos usuarios no aprecian su velocidad de arranque, su modelo de gestion de paquetes o su estrategia de ecosistema.

Mi lectura: si no sabes que distribucion de escritorio elegir, Ubuntu 26.04 LTS sigue siendo la respuesta por defecto mas segura. No es la mejor en cada aspecto aislado, pero su puntuacion global es la mas alta.

Deepin / UOS: experiencia de escritorio china y compatibilidad localizada

La fortaleza de Deepin y UOS es que entienden mejor a los usuarios chinos de escritorio.

Deepin 25 se publico en 2025 y sigue recibiendo actualizaciones en 2026 mediante versiones como deepin 25.1. Las notas oficiales de deepin 25 destacan mejoras del escritorio DDE, UOS AI, el sistema inmutable Solid, la compatibilidad de aplicaciones Linyaps, el subsistema Distrobox y la vista previa del compositor de ventanas Treeland.

Estas direcciones muestran que Deepin/UOS no se limita a crear una piel bonita para Linux. Intenta resolver dolores historicos del escritorio chino:

instalacion de aplicaciones y conflictos de dependencias;
compatibilidad con software domestico;
calidad visual y facilidad de uso del escritorio;
rollback cuando fallan las actualizaciones del sistema;
entrada en chino, trabajo de oficina y ecosistema de software empresarial;
compatibilidad y transicion desde aplicaciones Windows.

Deepin / UOS es adecuado para:

usuarios que valoran mas la interfaz china, los metodos de entrada, el trabajo de oficina y la localizacion;
quienes quieren un escritorio Linux bonito y listo para usar;
personas que trabajan en entornos de hardware y software localizados;
usuarios que necesitan software de oficina empresarial, software domestico, CPU domesticas o certificaciones de compatibilidad;
quienes no quieren configurar GNOME/KDE desde cero.

Fortalezas de Deepin:

interfaz DDE unificada y cuidada;
mejores detalles para usuarios chinos;
tienda de aplicaciones y configuracion del sistema mas cercanas a los habitos de usuarios comunes;
Linyaps, Distrobox y enfoques similares ayudan a reducir problemas de compatibilidad de aplicaciones Linux;
la edicion comercial UOS tiene valor practico en escenarios de localizacion y empresa.

La advertencia clave es que la edicion comunitaria de Deepin y la edicion comercial de UOS no tienen exactamente el mismo posicionamiento. Deepin encaja mejor con la experiencia personal y los usuarios de comunidad. UOS se orienta mas a gobierno, empresa, localizacion, servicios comerciales y entornos certificados. Para entornos de oficina en produccion, hay que revisar hardware, software y requisitos de la organizacion, no solo la interfaz.

Mi lectura: si eres usuario chino y te importan especialmente la apariencia, el metodo de entrada, el software domestico y la experiencia de oficina, Deepin/UOS resulta atractivo. Pero si eres un desarrollador intensivo y dependes del ecosistema Linux upstream mas estandar, Ubuntu o Fedora pueden sentirse mas fluidos.

Linux Mint: lo mas parecido a Windows y lo mas comodo

La posicion de Linux Mint siempre ha sido estable: hacer que Linux sea facil para usuarios normales.

En 2026, la linea principal de Linux Mint sigue alrededor de la serie 22.x y se basa en Ubuntu 24.04 LTS. Linux Mint 22.3 Zena se publico a comienzos de 2026. No es una vitrina de la tecnologia mas nueva, sino un sistema de escritorio estable, familiar y con bajo coste de aprendizaje.

Linux Mint es especialmente adecuado para usuarios de Windows que migran a Linux, sobre todo con el escritorio Cinnamon:

menu en la esquina inferior izquierda;
barra de tareas;
bandeja del sistema;
logica familiar para minimizar y maximizar ventanas;
panel de configuracion;
gestor de archivos;
gestor de actualizaciones.

Estos detalles hacen que se parezca mucho a un escritorio Windows tradicional. Para usuarios que no quieren adaptarse al flujo de GNOME, Linux Mint es mas facil de empezar que Ubuntu.

Linux Mint es adecuado para:

usuarios que migran de Windows a Linux;
instalar Linux para padres, familiares o usuarios no tecnicos;
quienes quieren un escritorio estable sin perseguir tecnologias nuevas;
uso de navegador, oficina, video, gestion de archivos y desarrollo ligero;
personas a las que no les gusta GNOME y no quieren ajustar KDE.

Sus fortalezas:

escritorio Cinnamon intuitivo;
gestor de actualizaciones amable;
sistema conservador y estable;
mejor trato a equipos antiguos;
mucha documentacion de comunidad y relativamente pocas sorpresas.

El punto clave es que Linux Mint no prioriza tecnologias nuevas. Wayland, PipeWire, los GNOME/KDE mas recientes, los kernels mas nuevos y Mesa de ultima generacion normalmente no llegan primero alli. Su objetivo es “trabajar de forma fiable hoy”, no “usar inmediatamente la tecnologia Linux de escritorio mas nueva”.

Mi lectura: si quieres convertir un portatil Windows en Linux sin explicar demasiados conceptos, Linux Mint es una de las opciones mas seguras. No tiene el ecosistema comercial de Ubuntu ni la frescura de Fedora, pero la experiencia diaria es muy solida.

Fedora: desarrolladores y tecnologias nuevas primero

Fedora es una de las primeras lineas de la tecnologia Linux de escritorio.

En mayo de 2026, la version principal actual es Fedora Linux 44. Fedora Workstation lleva mucho tiempo siendo una de las distribuciones donde GNOME, Wayland, PipeWire, Mesa, el kernel, systemd y otras tecnologias aterrizan pronto.

Fedora es adecuada para:

desarrolladores Linux;
usuarios de GNOME;
quienes quieren kernels, Mesa, compiladores y cadenas de herramientas nuevos antes;
usuarios que quieren probar pilas modernas de escritorio Linux como Wayland, PipeWire y Flatpak;
quienes no temen actualizar cada seis meses.

Fortalezas de Fedora:

adopcion rapida de tecnologias nuevas;
sistema por defecto relativamente limpio;
experiencia GNOME cercana a upstream;
cadena de desarrollo mas reciente;
integracion estrecha con Flatpak y el ecosistema de escritorio open source;
soporte generalmente activo para hardware moderno.

Sus advertencias tambien son claras:

ciclo de vida mas corto y necesidad de actualizar con regularidad;
no es ideal para personas que no quieren mantener el sistema en absoluto;
NVIDIA, codecs propietarios y parte del software comercial requieren repositorios adicionales;
si quieres “instalarlo y no tocarlo durante cinco anos”, Fedora encaja peor que una distribucion LTS.

Mi lectura: Fedora es excelente para desarrolladores, entusiastas de Linux y usuarios de tecnologias nuevas. No es el escritorio mas sencillo para usuarios corrientes, pero permite ver antes hacia donde puede ir el futuro de Linux de escritorio.

Como elegir

Primera instalacion de Linux para principiantes

Elige primero Ubuntu 26.04 LTS o Linux Mint.

Ubuntu destaca por documentacion y ecosistema. Linux Mint destaca por parecerse a Windows y por su bajo coste de aprendizaje. Si estas dispuesto a adaptarte a GNOME, elige Ubuntu. Si quieres que se parezca a Windows tanto como sea posible, elige Linux Mint.

Oficina china y entornos localizados

Mira primero Deepin / UOS.

Si necesitas software de oficina domestico, navegadores domesticos, sistemas gubernamentales o empresariales, CPU domesticas o entornos de compatibilidad exigidos por la organizacion, UOS tiene mas valor practico. Los usuarios personales que quieran un escritorio chino bonito pueden mirar Deepin.

Equipo principal para desarrolladores

Ubuntu 26.04 LTS y Fedora merecen atencion.

Si valoras estabilidad, tutoriales y soporte de software comercial, elige Ubuntu. Si quieres kernels nuevos, GNOME nuevo, toolchains recientes y la frontera de las tecnologias open source, elige Fedora.

Equipos antiguos o domesticos

Linux Mint es mas adecuado.

Su interfaz tradicional, uso de recursos relativamente amable y baja presion de mantenimiento lo hacen mejor para equipos antiguos, maquinas domesticas de navegacion y escritorios de oficina ligera que el enfoque de Fedora en tecnologias nuevas.

AI/GPU/cadenas de herramientas de desarrollo

Elige primero Ubuntu.

NVIDIA drivers, CUDA, PyTorch, TensorFlow, Docker, VS Code, JetBrains y herramientas similares siguen usando Ubuntu con mucha frecuencia en guias oficiales y tutoriales. Fedora tambien puede funcionar, pero resolver problemas suele requerir mas experiencia con Linux.

Que revisar antes de elegir

No juzgues Linux de escritorio solo por capturas de pantalla. La experiencia real depende de estos detalles:

si los controladores graficos son estables, sobre todo NVIDIA;
si Wi-Fi, Bluetooth, huella digital y camara funcionan correctamente;
si monitores externos, escalado y configuracion multimonitor resultan comodos;
si los metodos de entrada en chino funcionan bien;
si las aplicaciones comunes tienen paquetes oficiales o versiones Flatpak;
si las actualizaciones del sistema son faciles de entender;
si es facil encontrar soluciones cuando aparecen problemas;
si puedes aceptar el flujo de trabajo del escritorio por defecto.

Mucha gente fracasa al cambiar a Linux no porque el kernel sea debil, sino porque el metodo de entrada, el escalado, WeChat, la banca online, la impresora o los controladores graficos se sienten mal en el uso diario.

Mis recomendaciones

Escenario	Recomendacion
Escritorio principal para principiantes	Ubuntu 26.04 LTS
Migracion desde Windows	Linux Mint
Escritorio chino bonito	Deepin
Oficina localizada / entorno gubernamental y empresarial	UOS
Entorno estable para desarrolladores	Ubuntu 26.04 LTS
Experiencia con tecnologia Linux reciente	Fedora Linux 44
Equipo antiguo para oficina ligera	Linux Mint
Desarrollo AI/GPU	Ubuntu 26.04 LTS

Conclusion breve

Ubuntu 26.04 LTS es la opcion de escritorio todoterreno mas segura en 2026, adecuada para principiantes, desarrolladores y equipos principales.

Deepin/UOS es fuerte en experiencia china, diseno visual y compatibilidad localizada, adecuado para usuarios que valoran la experiencia local y los entornos gubernamentales o empresariales.

Linux Mint es extremadamente facil de usar y estable, especialmente para una migracion suave de Windows a Linux.

Fedora destaca en tecnologia nueva y experiencia para desarrolladores, y encaja con usuarios dispuestos a seguir la vanguardia del escritorio Linux.

La calidad de un sistema de escritorio depende al final de si quieres seguir usandolo cada dia despues de encender el ordenador. Una distribucion con la que puedas vivir comodamente importa mas que una que se vea mejor en una tabla de parametros.

Enlaces relacionados

Ubuntu 26.04 LTS: https://releases.ubuntu.com/26.04/
deepin 25 Release Note: https://www.deepin.org/en/deepin-25-release/
deepin 25.1.0 Release Note: https://www.deepin.org/en/deepin-25-1-release/
Linux Mint website: https://linuxmint.com/
Fedora Workstation: https://fedoraproject.org/workstation/
Fedora Release Notes: https://docs.fedoraproject.org/en-US/fedora/latest/release-notes/

Como elegir una distribucion Linux para servidores en 2026: comparativa entre Debian, Rocky Linux, AlmaLinux y Ubuntu Server

Thu, 07 May 2026 21:03:12 +0800

Al elegir una distribucion Linux para servidores en 2026, la pregunta clave no es “cual es la mejor”, sino “cual encaja con tu modelo de operaciones”.

Si necesitas la distribucion comunitaria mas estable, Debian sigue siendo una de las mejores opciones. Si necesitas el ecosistema compatible con RHEL pero no quieres comprar RHEL directamente, Rocky Linux y AlmaLinux son los sucesores mas naturales de CentOS. Si lo que mas te importa son las imagenes cloud, la documentacion, el despliegue rapido y paquetes mas recientes, Ubuntu Server sigue siendo el camino mas sencillo.

A continuacion va una comparativa practica desde la perspectiva de servidor.

Conclusion rapida

Distribucion	Mas adecuada para	Fortalezas principales	Puntos a tener en cuenta
Debian	Estabilidad a largo plazo, self-hosting, servicios basicos	Estable, limpia, comunidad fuerte, profunda tradicion de software libre	Los paquetes por defecto son conservadores; el soporte comercial empresarial es menos explicito que en RHEL/Ubuntu
Rocky Linux	Entornos de produccion compatibles con RHEL	Cerca de los habitos de RHEL, adecuada para migraciones empresariales desde CentOS	Cadencia de paquetes conservadora; el escritorio y la experiencia con tecnologias nuevas no son el foco
AlmaLinux	Produccion compatible con RHEL, cloud, reemplazo empresarial	Compatible con RHEL, comunidad activa, ciclo de vida claro	Aun tiene algunas diferencias frente a RHEL; conviene leer las notas de version
Ubuntu Server	Servidores cloud, contenedores, despliegue de desarrollo	Buen soporte cloud, mucha documentacion, despliegue rapido, largo ciclo LTS	Snap, kernels HWE y PPAs necesitan reglas de equipo

En una frase:

Eleccion general mas segura: Debian.
Reemplazo del ecosistema RHEL empresarial: Rocky Linux / AlmaLinux.
Cloud y eficiencia de desarrollo primero: Ubuntu Server.

Debian: estabilidad a prueba de anos

En mayo de 2026, la version estable actual de Debian es Debian 13 trixie. Debian 12 bookworm paso a oldstable y sigue recibiendo seguridad y soporte LTS, pero los despliegues nuevos de servidor normalmente deberian partir de Debian 13.

Las caracteristicas de Debian siempre han sido claras:

seleccion conservadora de paquetes por defecto;
estructura de sistema limpia;
sin una fuerte dependencia de un proveedor comercial;
gobernanza comunitaria madura;
muy adecuada para servicios basicos de larga duracion.

Debian se siente comoda si tus servidores ejecutan principalmente:

Nginx / Apache;
PostgreSQL / MariaDB / Redis;
Docker / Podman;
WireGuard / Tailscale;
servicios de archivos, copias de seguridad y monitorizacion;
pequenas aplicaciones self-hosted.

La ventaja de Debian no es ser “la mas nueva”, sino exigir menos pelea. Muchos servidores pueden funcionar durante anos con actualizaciones normales de seguridad y mantenimiento menor.

Debian es adecuada cuando:

quieres que el sistema siga siendo simple y no quede demasiado condicionado por la estrategia de un proveedor;
conoces apt, systemd y la disposicion de archivos de Debian;
aceptas que las versiones de software no sean las mas recientes;
valoras mas estabilidad, actualizaciones de seguridad y upgrades predecibles.

Debian es menos adecuada cuando:

un proveedor solo certifica RHEL o Ubuntu;
necesitas soporte comercial empresarial con SLA;
dependes del kernel mas nuevo, una pila GPU reciente o soporte para hardware muy nuevo;
tu equipo ya construyo sus estandares de operacion alrededor del ecosistema RHEL.

Mi lectura: para servidores personales, self-hosting, SaaS ligero e infraestructura de equipos pequenos, Debian sigue siendo una excelente primera opcion.

Rocky Linux: un sucesor estable de CentOS

Rocky Linux tiene una posicion clara: sirve a usuarios que necesitan el ecosistema compatible con RHEL y continua el papel que CentOS Linux tuvo en entornos empresariales de produccion.

En 2026, tanto Rocky Linux 9 como Rocky Linux 10 estan dentro de sus periodos de soporte. Rocky Linux 9 encaja mejor en entornos de produccion mas conservadores, mientras que Rocky Linux 10 es mas adecuado para proyectos nuevos, hardware mas reciente y una pista de futuro mas larga.

Rocky Linux encaja en escenarios como:

entornos empresariales que antes usaban CentOS 7 / CentOS 8;
estructura de directorios, nombres de paquetes y habitos de operacion estilo RHEL;
dependencia de dnf, RPM, SELinux y firewalld;
proveedores de software que soportan explicitamente distribuciones compatibles con RHEL;
scripts internos de automatizacion escritos alrededor de Enterprise Linux.

Su ventaja es la baja friccion de migracion. Muchos equipos tienen anos de playbooks Ansible, reglas de monitorizacion, scripts de auditoria y lineas base de seguridad basadas en CentOS. Migrar a Rocky Linux resulta mentalmente mucho mas sencillo que migrar a Debian o Ubuntu.

Cosas a tener en cuenta sobre Rocky Linux:

los paquetes son conservadores por diseno; es una caracteristica de Enterprise Linux, no un defecto;
componentes de espacio de usuario muy nuevos pueden requerir EPEL, repositorios de terceros o contenedores;
compatibilidad con RHEL no significa que todo proveedor comercial ofrezca automaticamente soporte formal, asi que revisa las listas de certificacion;
Rocky Linux 10 tiene nuevas bases de hardware y requisitos de ecosistema, por lo que conviene validarlo antes de produccion.

Mi lectura: si tu entorno de servidores ya se basa en CentOS / RHEL, Rocky Linux es un reemplazo muy natural, especialmente para entornos de produccion estables y servicios empresariales internos.

AlmaLinux: una ruta compatible con RHEL mas proactiva

AlmaLinux es otro sucesor importante de CentOS. Tambien es de grado empresarial, con soporte a largo plazo y compatible con RHEL.

Comparte muchos rasgos con Rocky Linux:

ambas apuntan al ecosistema compatible con RHEL;
ambas encajan en entornos de produccion de servidores;
ambas tienen lineas 8, 9 y 10 con soporte a largo plazo;
ambas son adecuadas para migrar desde CentOS;
ambas pueden usar gran parte de las herramientas del ecosistema Enterprise Linux.

La diferencia es que AlmaLinux es mas proactiva documentando y gestionando diferencias upstream mientras mantiene compatibilidad con RHEL. Por ejemplo, AlmaLinux 10 ofrece una opcion de arquitectura x86-64-v2 para hardware mas antiguo y documenta claramente sus diferencias frente a RHEL en las notas de version.

Esto resulta util para algunos usuarios: quieren permanecer en el ecosistema RHEL, pero tambien desean una distribucion comunitaria con mas flexibilidad alrededor de soporte de hardware, builds de paquetes y compatibilidad con EPEL.

AlmaLinux es adecuada cuando:

necesitas compatibilidad con RHEL pero no quieres quedar completamente limitado por la estrategia de lanzamientos de RHEL;
valoras la gobernanza comunitaria y notas de version transparentes;
necesitas una base estable para plataformas cloud, imagenes de contenedor y cargas empresariales;
quieres una migracion suave desde CentOS o Enterprise Linux antiguo.

La advertencia clave: AlmaLinux no es “identica a RHEL con los ojos cerrados”. En escenarios de cumplimiento estricto, certificacion de proveedor, certificacion de bases de datos o certificacion de hardware, confirma si el proveedor soporta AlmaLinux explicitamente.

Mi lectura: Rocky Linux y AlmaLinux pueden reemplazar CentOS. Si prefieres una historia mas conservadora y tradicional al estilo CentOS, mira Rocky. Si valoras transparencia comunitaria y una ruta de compatibilidad mas flexible, mira AlmaLinux.

Ubuntu Server: el mejor soporte cloud y eficiencia de despliegue

La ventaja de Ubuntu Server es practica: plataformas cloud, documentacion, tutoriales de comunidad, imagenes, herramientas de automatizacion y ecosistema de desarrollo son todos fuertes.

Para despliegues nuevos de servidor en 2026, la opcion principal sigue siendo Ubuntu 24.04 LTS. Ubuntu LTS suele tener 5 anos de soporte estandar y puede extenderse mediante ESM. Para servidores cloud, hosts de contenedores, entornos de desarrollo y nodos CI/CD, Ubuntu Server suele ser la forma mas rapida de ponerse en marcha.

Ubuntu Server encaja con:

AWS, Azure, Google Cloud, Oracle Cloud, Alibaba Cloud, Tencent Cloud y otros servidores cloud;
Docker, Kubernetes, GitLab Runner, CI/CD;
entornos de desarrollo AI / GPU / CUDA;
equipos que necesitan muchos tutoriales y recetas de comunidad;
entornos donde desarrollo y produccion deberian mantenerse parecidos.

Fortalezas de Ubuntu:

imagenes cloud de alta calidad;
mucha documentacion oficial y de terceros;
soporte para hardware nuevo a menudo mas activo;
cadencia LTS clara;
actualizaciones comodas de toolchains para desarrolladores;
muchos proveedores comerciales publican primero instrucciones de instalacion para Ubuntu.

Cosas a vigilar:

no a todos los equipos les gusta Snap en servidores, asi que conviene decidir la politica por adelantado;
los PPAs son comodos, pero abusar de ellos en produccion aumenta el riesgo de mantenimiento;
elige claramente entre kernel HWE, kernel cloud y kernel estandar;
para puristas de estabilidad minima, el sistema por defecto de Ubuntu se siente mas cargado que Debian.

Mi lectura: si ejecutas sobre todo servidores cloud, contenedores, despliegues de desarrollo o toolchains de AI, Ubuntu Server suele ser la opcion mas eficiente. No es la distribucion mas “pura”, pero reduce mucho el tiempo de busqueda y la friccion en muchas tareas.

Como elegir entre las cuatro

VPS personal / self-hosting

Debian o Ubuntu Server primero.

Si quieres estabilidad, bajo mantenimiento y menos complicaciones, elige Debian. Si sigues tutoriales a menudo para desplegar proyectos nuevos o necesitas una pila de software mas reciente, elige Ubuntu Server.

Produccion empresarial

Rocky Linux, AlmaLinux o RHEL primero.

Si la empresa usaba CentOS antes, migrar a Rocky / Alma es el camino mas barato. Si hay bases de datos comerciales, certificacion de hardware, cumplimiento de seguridad o soporte de proveedor, revisa primero las listas de certificacion.

Cloud native y hosts de contenedores

Ubuntu Server, Debian y Rocky / Alma pueden funcionar.

Si el equipo valora eficiencia de desarrollo, elige Ubuntu Server. Si quieres estabilidad minima, elige Debian. Si el estandar empresarial se basa en RHEL, elige Rocky / Alma.

Servidores AI / GPU

Mira primero Ubuntu Server, luego Rocky / Alma.

La razon es simple: NVIDIA, CUDA, PyTorch, TensorFlow, tutoriales de instalacion de drivers y experiencia de comunidad suelen ser mas abundantes en Ubuntu. Los clusters GPU empresariales construidos alrededor del ecosistema RHEL pueden elegir Rocky / Alma, pero drivers, CUDA, runtime de contenedores y herramientas de monitorizacion deberian validarse por adelantado.

Sistemas de negocio tradicionales

Rocky Linux / AlmaLinux primero.

Java tradicional, bases de datos, middleware, software comercial, auditoria y estandares de operacion suelen inclinarse hacia el ecosistema RHEL. En ese caso, Rocky / Alma encaja con sistemas existentes mas facilmente que Debian / Ubuntu.

Que revisar antes de elegir

No elijas solo por el nombre de la distribucion. Para seleccionar un servidor, juzga con estas preguntas:

Ciclo de vida: hasta que ano se mantiene esta version?
Ruta de upgrade: el upgrade de version mayor esta maduro? Hay migracion fluida?
Fuentes de software: dependes de repositorios de terceros? Quien los mantiene?
Actualizaciones de seguridad: estan claros los avisos de seguridad, la cadencia de parches y el manejo de CVE?
Soporte de hardware: se validaron CPU, NIC, RAID, GPU y controladoras de almacenamiento?
Experiencia del equipo: el equipo conoce mejor apt o dnf? Sistemas estilo Debian o estilo RHEL?
Certificacion de proveedores: el software de negocio soporta explicitamente esta distribucion?
Activos de automatizacion: se pueden reutilizar scripts existentes de Ansible, Terraform y construccion de imagenes?

El coste real no suele ser la ISO de instalacion. Son los upgrades, auditorias, diagnosticos y traspasos durante los proximos cinco anos.

Mis recomendaciones por defecto

Si tuviera que dar una guia de seleccion de servidores para 2026:

Escenario	Recomendacion
VPS personal, self-hosting	Debian 13
Servidor cloud, despliegue rapido	Ubuntu Server 24.04 LTS
Migracion desde CentOS	Rocky Linux 9 / AlmaLinux 9
Proyecto empresarial nuevo	Rocky Linux 10 / AlmaLinux 10, tras validar el ecosistema
Desarrollo AI / GPU	Ubuntu Server 24.04 LTS
Produccion comercial con cumplimiento estricto	RHEL, o Rocky / Alma tras confirmar soporte de proveedor

Conclusion breve

Las palabras clave de Debian son estabilidad, simplicidad, comunidad y tradicion de software libre. Es adecuada para servidores base de larga duracion.

Rocky Linux y AlmaLinux tratan sobre compatibilidad con RHEL, produccion empresarial y reemplazo de CentOS. Encajan con equipos que ya tienen sistemas de operacion basados en Enterprise Linux.

Ubuntu Server trata sobre cloud, documentacion, eficiencia de desarrollo y ecosistema completo. Encaja con despliegue rapido, contenedores, AI/GPU y servidores cloud.

No existe una distribucion correcta para siempre. Solo existe la distribucion que mejor encaja con tu equipo, negocio, hardware y ciclo de vida. La mejor eleccion de servidor no suele ser la mas popular, sino la que seguiras dispuesto a mantener dentro de cinco anos.

Enlaces relacionados

Debian Releases: https://www.debian.org/releases/
Ubuntu Releases: https://releases.ubuntu.com/
Rocky Linux Release and Version Guide: https://wiki.rockylinux.org/rocky/version/
AlmaLinux Release Notes: https://wiki.almalinux.org/release-notes/

Cómo controlar el orden de borrado en fdupes: conservar duplicados por prioridad de directorio

Wed, 06 May 2026 09:23:09 +0800

Al usar fdupes para eliminar archivos duplicados entre tres directorios, como a, b y c, si quieres conservar primero a, luego b, y eliminar primero los duplicados de c, la clave no es una regla compleja. Es el orden de los argumentos de directorio.

En modo de borrado no interactivo, fdupes conserva el primer archivo que ve en cada grupo de duplicados y elimina los duplicados posteriores. Por tanto, los argumentos de directorio deben ordenarse de mayor prioridad de conservación a menor.

En otras palabras, para lograr “eliminar primero de c, luego de b, y conservar a tanto como sea posible”, escribe el comando así:

`1`	`fdupes -rdN a b c`

El orden de escaneo es a -> b -> c. Cuando el mismo archivo existe en los tres directorios, el archivo de a se encuentra primero y se conserva, mientras que los duplicados de b y c se eliminan. Si solo b y c contienen duplicados, se conserva b y se elimina c.

Significado de los parámetros

Los parámetros comunes son:

-r: escanear subdirectorios de forma recursiva.
-d: eliminar archivos duplicados.
-N: cuando se usa con -d, omitir la confirmación interactiva, conservar el primer archivo de cada grupo de duplicados y eliminar el resto.

Por tanto, el formato básico para eliminación automática de duplicados es:

`1`	`fdupes -rdN 目录A 目录B 目录C`

Cuanto antes aparece un directorio, mayor es su prioridad de conservación. Cuanto más tarde aparece, más probable es que sus archivos duplicados sean eliminados.

Previsualizar antes de eliminar

Usar -dN elimina archivos directamente, así que es mejor previsualizar primero los grupos de duplicados:

`1`	`fdupes -r a b c`

La salida se agrupa por archivos duplicados. En cada grupo, el archivo mostrado antes es el que más probablemente se conservará en modo de borrado no interactivo.

También puedes ver información de resumen:

`1`	`fdupes -rm a b c`

Si los datos son importantes, guarda el resultado e inspecciónalo manualmente:

`1`	`fdupes -r a b c > duplicates.txt`

Después de confirmar que el orden dentro de cada grupo de duplicados coincide con lo esperado, ejecuta:

`1`	`fdupes -rdN a b c`

Cómo se manejan los subdirectorios

Mientras -r esté activado, fdupes escanea recursivamente todos los archivos bajo los directorios que pasas. La prioridad de conservación sigue determinada por el orden en que las rutas aparecen en el comando.

Por ejemplo:

`1`	`fdupes -rdN dir_a dir_b dir_c`

Esto significa:

dir_a tiene la prioridad más alta.
dir_b viene después.
dir_c tiene la prioridad más baja.

Si dir_a/sub1/file.txt y dir_c/sub1/file.txt tienen contenido idéntico, se conserva el archivo bajo dir_a. Si dir_a/x/y/file.txt y dir_c/file.txt tienen contenido idéntico, el archivo bajo dir_a también se conserva primero. fdupes compara contenido de archivos; los nombres y la profundidad de directorio no tienen que coincidir.

Controlar con precisión la prioridad de subdirectorios

Si solo pasas directorios padre, el orden de escaneo dentro de subdirectorios depende del comportamiento de recorrido de fdupes. Esto basta en la mayoría de casos. Pero si quieres que un subdirectorio específico tenga más prioridad, escríbelo explícitamente antes de su directorio padre.

Por ejemplo, supón que quieres conservar primero dir_a, luego dir_b/special, después procesar el resto de dir_b, y finalmente procesar dir_c:

`1`	`fdupes -rdN dir_a dir_b/special dir_b dir_c`

Esto hace que dir_b/special se escanee antes que dir_b. Cuando dir_b se escanea después, los archivos bajo special ya han sido registrados, así que ese subdirectorio tiene efectivamente mayor prioridad que el resto de dir_b.

Este patrón es útil cuando:

a es el directorio base más importante.
Un subdirectorio dentro de b es más importante que el resto de b.
c es principalmente un directorio de respaldo de baja prioridad.

El orden de rutas puede extenderse más:

`1`	`fdupes -rdN a b/important b c/keep-first c`

La regla sigue siendo la misma: cuanto antes aparece, más probable es que se conserve.

Usar una lista para muchos directorios

Si hay muchos directorios y subdirectorios, escribir manualmente un comando largo es propenso a errores. Puedes escribir las rutas en un archivo de texto como folders.txt, ordenadas por prioridad:

/path/to/dir_a
/path/to/dir_b/sub_important
/path/to/dir_b
/path/to/dir_c/sub_1
/path/to/dir_c

Luego pásalas a fdupes con xargs:

`1`	`cat folders.txt \| xargs fdupes -rdN`

Si las rutas pueden contener espacios, usa entrada separada por nulos para mayor seguridad:

`1`	`tr '\n' '\0' < folders.txt \| xargs -0 fdupes -rdN`

Límites importantes

Primero, fdupes compara contenido de archivos, no nombres. Dos archivos con nombres completamente distintos pueden tratarse como duplicados si su contenido es idéntico.

Segundo, si el directorio a contiene duplicados internamente, fdupes -rdN a b c también puede eliminar duplicados posteriores dentro de a. Este comando significa “conservar el primer archivo según el orden global de escaneo”, no “no eliminar nunca nada bajo a”.

Tercero, por defecto, fdupes no sigue enlaces simbólicos. Si necesitas manejar archivos detrás de symlinks, confirma si necesitas -s y si eso coincide con tus expectativas de seguridad de datos.

Cuarto, fdupes solo elimina archivos duplicados. No limpia directorios vacíos. Después de eliminar, si b y c contienen carpetas vacías, puedes ejecutar:

`1`	`find b c -type d -empty -delete`

Hábito de operación más seguro

Si los directorios contienen datos importantes, no empieces con -rdN. Un flujo más seguro es:

Ejecutar primero fdupes -r a b c para ver grupos de duplicados.
Confirmar que el primer archivo de cada grupo es el que quieres conservar.
Luego ejecutar fdupes -rdN a b c para eliminación automática.
Después de eliminar, revisar si hay que limpiar directorios vacíos.

Si te preocupa mucho eliminar archivos bajo a por accidente, primero limpia un rango más pequeño de directorios de baja prioridad, o exporta los resultados y fíltralos manualmente. El orden de directorios en fdupes es útil, pero no es una regla de control de acceso. Una vez que una ruta entra en el escaneo, los archivos duplicados dentro de ella pueden participar en decisiones de eliminación.

Resumen

Para eliminar archivos duplicados con fdupes por prioridad, coloca antes los directorios que quieres conservar y después los directorios de los que quieres eliminar.

Para conservar a, luego b, y eliminar primero de c:

`1`	`fdupes -rdN a b c`

Para dar mayor prioridad a un subdirectorio, escríbelo antes de su directorio padre:

`1`	`fdupes -rdN a b/important b c`

La frase clave es simple: fdupes -dN conserva los archivos duplicados que aparecen primero y elimina los duplicados que aparecen después. El orden de directorios es tu prioridad de conservación.

Cuál es la diferencia entre Snap, Flatpak y apt

Sat, 02 May 2026 11:22:26 +0800

Al instalar software en Ubuntu, a menudo aparecen tres nombres: apt, Snap y Flatpak. Todos pueden instalar aplicaciones, pero resuelven problemas distintos.

En resumen:

Herramienta	Rol principal	Mejor para
`apt`	Gestor de paquetes tradicional de Ubuntu/Debian	Componentes del sistema, herramientas de línea de comandos, software mantenido por la distribución
Snap	Formato de empaquetado promovido por Canonical	Apps de escritorio en Ubuntu, herramientas de servidor, software con actualización automática
Flatpak	Formato entre distribuciones centrado en apps de escritorio	Apps gráficas, apps sandboxed, ecosistema Flathub

apt: parte del sistema

apt es el gestor de paquetes tradicional de sistemas Debian y Ubuntu. Instala paquetes .deb desde repositorios de la distribución, con dependencias mantenidas por la propia distribución.

Uso típico:

`1`	`sudo apt install firefox`

apt tiene estas características:

Se integra más profundamente con el sistema.
Las dependencias se gestionan de forma centralizada por la distribución.
Las versiones de software suelen seguir el ciclo de lanzamiento de la distribución.
Es muy adecuado para bibliotecas del sistema, drivers, herramientas de línea de comandos y componentes de servidor.

Su desventaja también es clara: las versiones pueden ser antiguas. Las distribuciones priorizan estabilidad, así que no siempre envían inmediatamente la última versión upstream.

Snap: aplicación y dependencias en un solo paquete

Snap es un formato de empaquetado promovido por Canonical. Empaqueta una app con muchas de sus dependencias de runtime, reduciendo la dependencia de versiones exactas de bibliotecas del sistema.

La instalación se ve parecida:

`1`	`sudo snap install firefox`

Ventajas de Snap:

El mismo paquete puede ejecutarse más fácilmente entre versiones de Ubuntu.
Las apps pueden actualizarse de forma independiente a las actualizaciones del sistema.
Hay cierto aislamiento y control de permisos por defecto.
Funciona bien para apps de escritorio que necesitan actualizaciones rápidas y algunas herramientas de servidor.

Quejas comunes incluyen arranque más lento, mayor uso de disco, integración de temas menos natural y un modelo de actualización que da menos control al usuario que apt.

Flatpak: más orientado a apps de escritorio

Flatpak también es un formato de empaquetado entre distribuciones, pero está más centrado en apps de escritorio Linux. Muchas apps Flatpak vienen de Flathub.

Instalación típica:

`1`	`flatpak install flathub org.mozilla.firefox`

Flatpak tiene estas características:

Fuerte soporte entre distribuciones.
Foco en distribución de apps de escritorio.
Usa runtimes para compartir dependencias base.
Modelo de sandbox y permisos más claro.
Gran selección de software en Flathub.

Flatpak también usa espacio extra, especialmente al instalar un runtime por primera vez. Cuando varias apps comparten un runtime, el sobrecoste se vuelve menos derrochador.

La mayor diferencia: dependencias

apt se parece más a integrar software en el sistema. Las apps dependen de bibliotecas ya presentes en el sistema, y varios paquetes comparten las mismas dependencias.

Snap y Flatpak se parecen más a enviar una app con su propio entorno de runtime. La app lleva parte de lo que necesita, reduciendo problemas causados por distintas versiones del sistema.

Eso crea un compromiso:

Enfoque	Pros	Contras
`apt` comparte dependencias del sistema	Ahorra espacio, se integra bien, mantenimiento centralizado	Las versiones están atadas a la distribución
Snap/Flatpak llevan piezas de runtime	Entre versiones, entre distribuciones, actualizaciones más fáciles	Paquetes más grandes, posible arranque más lento, integración más débil

Aislamiento y permisos

El software instalado con apt suele ejecutarse directamente en el entorno del sistema. Se integra de forma natural, pero tiene menos aislamiento.

Snap y Flatpak usan ideas de sandbox. Las apps no pueden acceder libremente a todos los recursos del sistema por defecto; necesitan interfaces de permiso para archivos, cámara, red, notificaciones de escritorio y otros recursos.

Eso no las vuelve absolutamente seguras, pero da un límite de permisos más claro. Para apps de escritorio de fuentes mixtas, eso importa.

Las actualizaciones funcionan distinto

apt suele seguir las actualizaciones del sistema:

1
2

sudo apt update
sudo apt upgrade

Snap se actualiza automáticamente. Es cómodo, pero también controvertido: los usuarios no tienen que gestionar versiones, pero también tienen menos control.

Flatpak puede actualizarse manualmente:

`1`	`flatpak update`

Así que si te importa cuándo ocurren las actualizaciones, apt y Flatpak suelen sentirse más controlables. Si quieres que las apps se mantengan actuales automáticamente, Snap es más desatendido.

Cuál deberías usar

Elige por escenario:

Herramientas del sistema, drivers y componentes de servidor: prefiere apt.
Apps de escritorio recomendadas por Ubuntu: Snap está bien.
Apps de escritorio más nuevas, especialmente entre distribuciones: Flatpak suele ser buena opción.
Si la misma app existe en los tres formatos: compara estabilidad, velocidad de arranque, integración de temas y necesidades de actualización.

Un enfoque conservador es: usar apt para la capa del sistema, y luego elegir Snap o Flatpak para apps de escritorio según haga falta.

Resumen

apt, Snap y Flatpak no se reemplazan completamente entre sí. Son modelos de distribución distintos.

apt es mejor para mantener el sistema. Snap enfatiza dependencias empaquetadas y actualizaciones automáticas. Flatpak es mejor para apps de escritorio entre distribuciones y entrega sandboxed.

Para uso diario, no hace falta obsesionarse con cuál es mejor. Usa apt para software del sistema. Para apps de escritorio, sigue la recomendación de tu distribución y tu propia experiencia: funcionamiento estable, actualizaciones controladas y permisos claros son lo que importa.

Referencia:

https://www.reddit.com/r/Ubuntu/comments/9awvip/eli5_snap_and_flatpak_how_are_they_differ_from_apt/

Cambios del driver NTFS en Linux 7.0 y 7.1, explicados

Sat, 02 May 2026 10:46:20 +0800

Después de Linux 7.0, Linux 7.1 entró en la siguiente ventana de integración de funciones. Un cambio llamativo es un nuevo driver NTFS para el kernel.

“Nuevo” no significa que Linux admita NTFS por primera vez, ni que ntfs3 vaya a ser reemplazado. Más exactamente, Linux 7.1 añade un nuevo driver NTFS opcional de lectura y escritura dentro del kernel. Está basado en el antiguo driver ntfs del kernel, modernizado y ampliado con soporte de escritura más completo.

Resumen rápido

Linux tiene ahora tres caminos principales para NTFS:

Opción	Ubicación	Soporte lectura-escritura	Mejor para
`ntfs-3g`	FUSE en espacio de usuario	Lectura-escritura	Priorizar estabilidad; valor por defecto histórico en muchas distribuciones
`ntfs3`	Espacio de kernel	Lectura-escritura	Integración más directa con el kernel y rendimiento
Nuevo `ntfs`	Espacio de kernel	Lectura-escritura	Implementación opcional añadida en Linux 7.1

Esto no es una migración forzada. Simplemente añade otra opción. La mayoría de usuarios puede seguir usando por ahora los valores por defecto de su distribución.

Relación entre 7.0 y 7.1

Linux 7.0 solo marca el paso a la serie 7.x del kernel. No significa que el soporte NTFS se reescribiera de golpe en 7.0. El cambio relacionado con NTFS aparece en el ciclo de funciones de Linux 7.1.

NTFS sigue siendo importante para usuarios de escritorio Linux porque sistemas dual-boot, discos externos, unidades USB y discos de datos de Windows suelen usarlo. La parte delicada es la escritura: si un driver de sistema de archivos tiene un bug, los datos del usuario pueden verse afectados directamente. Por eso los cambios en drivers NTFS se tratan con cuidado.

`ntfs-3g`, `ntfs3` y el nuevo `ntfs`

ntfs-3g es un driver FUSE en espacio de usuario. Durante mucho tiempo ha gestionado el soporte de lectura y escritura NTFS en Linux. Puede no ser siempre la opción más rápida, pero es maduro, compatible y bien documentado.

ntfs3 es el driver NTFS dentro del kernel aportado por Paragon Software y ya integrado en Linux. Tiene una ruta más corta, se integra de forma más directa con VFS y puede ofrecer mejor rendimiento. Pero los drivers de sistemas de archivos requieren una disciplina fuerte de mantenimiento, y ntfs3 ha generado discusión sobre ritmo de mantenimiento y calidad de código tras su integración.

El nuevo driver ntfs de Linux 7.1 está mantenido por Namjae Jeon. No está escrito desde cero; moderniza el antiguo driver ntfs del kernel, añade soporte de escritura y coexiste con ntfs3 como otra implementación opcional.

En resumen:

ntfs-3g: conservador, maduro, en espacio de usuario.
ntfs3: opción mainline existente dentro del kernel.
Nuevo ntfs: nueva opción dentro del kernel en 7.1, todavía digna de observación.

Cuál usar

No hace falta cambiar de inmediato. Un orden conservador sería:

Seguir usando el valor por defecto de la distribución para datos importantes, normalmente ntfs-3g o un ntfs3 ya probado.
Probar ntfs3 cuando el rendimiento importe.
Probar el nuevo driver ntfs primero con datos temporales, de prueba o recuperables.
Hacer copia de seguridad de particiones NTFS importantes antes de escribir.

Para montar manualmente con ntfs3:

`1`	`sudo mount -t ntfs3 /dev/sdX1 /mnt/ntfs`

Para acceso temporal de solo lectura:

`1`	`sudo mount -o ro /dev/sdX1 /mnt/ntfs`

Para comprobar qué driver se está usando:

1
2

findmnt -T /mnt/ntfs
mount | grep ntfs

Notas para dual-boot

Si una partición NTFS viene de un disco de sistema Windows, asegúrate de que Windows esté completamente apagado antes de escribir en ella. Fast Startup e hibernación pueden dejar el volumen NTFS en un estado incompleto, y las escrituras desde Linux podrían causar problemas de consistencia.

Comprueba primero:

Desactivar Windows Fast Startup.
Asegurarse de que la partición no esté hibernada.
Confirmar que BitLocker u otro cifrado no bloquea el acceso.
Expulsar de forma segura unidades externas desde Windows.

Estas reglas aplican tanto si usas ntfs-3g, ntfs3 o el nuevo driver ntfs.

Por qué existen varios drivers NTFS

No es raro que Linux tenga varias implementaciones para el mismo sistema de archivos. Implementaciones antiguas, nuevas, de proveedor y de comunidad pueden coexistir hasta que el estado de mantenimiento y la experiencia real aclaren el camino preferido.

NTFS es especialmente adecuado para un enfoque conservador:

El riesgo para datos de usuario es alto.
Los casos de compatibilidad son complejos.
Las implementaciones difieren en sus compromisos entre rendimiento y estabilidad.
Las distribuciones necesitan tiempo para validar valores por defecto.

Así que el nuevo driver ntfs de Linux 7.1 no vuelve obsoletos de inmediato a ntfs-3g ni a ntfs3. Da a la comunidad del kernel otra opción mantenible.

Resumen

El nuevo driver ntfs de Linux 7.1 es una implementación NTFS opcional de lectura y escritura dentro del kernel. Coexiste con ntfs-3g y ntfs3; no reemplaza directamente a ninguno.

Los usuarios normales pueden seguir usando los valores por defecto de su distribución. Quienes quieran probar rendimiento o cambios de sistemas de archivos del kernel pueden observar ntfs3 y el nuevo ntfs, pero los datos importantes deben respaldarse antes de cambiar de driver.

sudo vs sudo-rs: qué cambia con la versión de sudo en Rust

Fri, 01 May 2026 19:27:08 +0800

sudo es uno de los comandos más familiares para los usuarios de Linux. Permite que un usuario normal ejecute temporalmente comandos con privilegios más altos dentro de un alcance autorizado, por ejemplo instalar software, cambiar la configuración del sistema o reiniciar servicios.

Recientemente, sudo-rs ha recibido más atención porque Ubuntu 25.10 empieza a usar de forma predeterminada la implementación en Rust sudo-rs para sustituir al sudo clásico. Para los usuarios comunes, en la superficie se sigue escribiendo sudo. El cambio real está por debajo: la implementación que se ejecuta puede ser ya la versión de sudo escrita en Rust.

Esto plantea dos preguntas naturales:

¿Hay algún problema con el sudo clásico?
¿Afectará sudo-rs al uso diario y a la configuración de servidores?

La conclusión breve es: los usuarios de escritorio comunes básicamente no tienen que preocuparse; si mantienes servidores, has escrito reglas sudoers complejas o dependes de comportamientos especiales de sudo, conviene probarlo con cuidado.

Qué es sudo-rs

sudo-rs es una implementación de sudo / su escrita en Rust. Su objetivo no es crear un comando nuevo completamente distinto, sino reimplementar las funciones principales del sudo clásico mientras aprovecha las propiedades de seguridad de memoria de Rust para reducir riesgos de seguridad habituales.

El sudo clásico está escrito principalmente en C. Tiene una larga historia y un conjunto de funciones muy completo. Esa madurez aporta estabilidad, pero también carga de mantenimiento. Gran parte del código viene de escenarios Unix/Linux muy antiguos, y con el tiempo se le añadieron muchas rutas de compatibilidad, extensiones y tratamientos de casos límite.

sudo-rs opta por reimplementarlo por varias razones:

reducir problemas de seguridad de memoria con Rust;
usar una estructura de código más moderna para facilitar el mantenimiento;
eliminar algunas funciones históricas y comportamientos predeterminados de alto riesgo;
atraer a nuevos colaboradores familiarizados con Rust;
proporcionar una base más fácil de auditar para futuras herramientas de elevación de privilegios.

Sin embargo, sudo-rs no es un reemplazo 100% compatible del sudo clásico. Todavía está en desarrollo. Algunas funciones tradicionales aún no se han implementado, y otras quizá nunca se implementen.

Qué notarán los usuarios comunes

Para los usuarios comunes, cambia muy poco.

Se sigue usando así:

`1`	`sudo apt update`

O así:

`1`	`sudo systemctl restart nginx`

En Ubuntu 25.10, sudo apunta a sudo-rs. Los usuarios no tienen que cambiar el comando a sudo-rs, y las llamadas habituales a sudo en scripts no deberían fallar inmediatamente por un cambio de nombre del comando.

El cambio más visible es la retroalimentación al escribir la contraseña. sudo-rs muestra asteriscos de forma predeterminada mientras se introduce la contraseña. El sudo clásico también puede configurarse para comportarse así, pero muchas distribuciones no muestran ningún carácter por defecto.

Algunos mensajes de error y advertencia también pueden tener textos distintos. Por ejemplo, los fallos de contraseña, los problemas de permisos o una configuración incompatible pueden mostrar avisos que no son exactamente iguales a los anteriores. Esto afecta poco a los usuarios humanos, pero si algunos scripts analizan la salida de error de sudo, habrá que revisarlos.

Qué deben vigilar los administradores

Quienes realmente deben prestar atención son los administradores de sistemas y los usuarios avanzados.

El ecosistema del sudo clásico es grande, y muchos servidores tienen configuraciones sudoers complejas. Estas configuraciones pueden incluir coincidencia de argumentos de comandos, control de variables de entorno, registros, notificaciones por correo, comportamiento de PAM y políticas para distintos grupos de hosts.

sudo-rs tiene actualmente algunas diferencias frente al sudo clásico. Por ejemplo, el artículo original señala que sudo-rs no incluye el soporte de sendmail del sudo clásico. Algunos entornos usaban sendmail para enviar notificaciones de uso de sudo, y esas configuraciones necesitarán otra solución al migrar.

En autenticación, sudo-rs usa PAM. Esto significa que comportamientos como límites de recursos y umask deberían configurarse más a través de PAM, en lugar de depender por completo del archivo sudoers. Si antes gestionabas muchos detalles en sudoers, verifica antes del cambio que esas reglas sigan funcionando.

Otro cambio importante es el soporte de comodines en posiciones de argumentos de comando. sudo-rs no admite comodines en argumentos de comandos para evitar errores comunes de configuración en archivos sudoers. Esto es bueno para la seguridad, pero puede afectar a reglas existentes.

Cómo maneja Ubuntu sudo y sudo-rs

A partir de Ubuntu 25.10, el sistema usa sudo-rs de forma predeterminada. Los usuarios siguen escribiendo sudo, mientras por debajo se ejecuta la implementación en Rust.

El sudo clásico no desaparece de inmediato. Durante la transición de Ubuntu, el sudo clásico se conserva como sudo-ws. Si realmente necesitas la implementación tradicional, puedes usar sudo-ws o cambiar el sudo predeterminado mediante el mecanismo de alternatives.

El comando de cambio se parece a este:

`1`	`sudo update-alternatives --config sudo`

Dicho esto, no se recomienda que los usuarios comunes vuelvan activamente al sudo clásico. Si no has personalizado sudoers y no dependes de comportamientos especiales, seguir la opción predeterminada de la distribución es más sencillo.

Si quieres probarlo en versiones anteriores de Ubuntu, sudo-rs está disponible desde Ubuntu 24.04 en el repositorio universe. Otras distribuciones también pueden ofrecer paquetes, pero los nombres de comandos y la integración pueden variar.

Por qué sudo-rs usa Rust

sudo es una herramienta de altos privilegios. Si una herramienta de este tipo tiene una vulnerabilidad, las consecuencias pueden ser mucho más graves que en un comando común. Históricamente, sudo también ha tenido varias vulnerabilidades de elevación de privilegios.

La ventaja de Rust es la seguridad de memoria. Mediante ownership, borrow checking y el sistema de tipos, reduce problemas comunes como punteros colgantes, accesos fuera de límites y use-after-free. Esto no garantiza que el programa sea absolutamente seguro, pero puede reducir una clase de vulnerabilidades muy común en proyectos C/C++.

Para una herramienta como sudo, que lleva mucho tiempo en una posición sensible de seguridad, reescribirla en un lenguaje más seguro tiene sentido práctico. No es “Rust por Rust”, sino un intento de reducir los costes de mantenimiento y auditoría.

Por supuesto, el lenguaje no resuelve todos los problemas de seguridad. La lógica de comprobación de permisos, el análisis de configuración, la interacción con PAM, el manejo de variables de entorno, los registros y la experiencia de usuario siguen requiriendo un diseño riguroso y pruebas prolongadas.

sudo-rs no es la única alternativa

En el ecosistema de sudo siempre ha habido otras alternativas.

Un ejemplo común es doas. Procede de OpenBSD y está diseñado para ser más simple, con una superficie de configuración más pequeña. Algunos usuarios lo prefieren porque no es tan complejo como sudo.

También existen algunas alternativas relacionadas con Rust o systemd, como RootAsRole y run0 de systemd. Sin embargo, estas herramientas no tienen exactamente los mismos objetivos ni los mismos escenarios de uso.

Para la mayoría de distribuciones Linux, sudo sigue siendo la opción predeterminada. La importancia de sudo-rs es que intenta mantener los hábitos de los usuarios mientras sustituye la implementación subyacente por una base de código más moderna.

Qué revisar antes de migrar

Si solo eres un usuario de escritorio personal, puedes seguir la configuración predeterminada de la distribución.

Si mantienes servidores o estaciones de trabajo, conviene revisar estos puntos:

Si existen reglas complejas en /etc/sudoers o /etc/sudoers.d/.
Si se usan comodines en argumentos de comandos.
Si se depende de notificaciones de correo de sudo.
Si hay scripts que analizan la salida de error de sudo.
Si sudoers controla umask, límites de recursos o variables de entorno.
Si existen integraciones de autenticación con LDAP, PAM, SSSD u otros sistemas.
Si scripts de automatización o despliegue asumen el comportamiento del sudo clásico.

Primero puedes verificarlo en una máquina de pruebas:

sudo -l

Después ejecuta los comandos clave de mantenimiento y confirma que permisos, variables de entorno y registros se comporten como esperas.

¿Deberías cambiar manualmente a sudo-rs?

Si tu distribución ya lo usa de forma predeterminada, los usuarios comunes pueden aceptarlo directamente. Si usas un servidor o un entorno de producción, no conviene reemplazar sudo manualmente solo para experimentar.

Un proceso más prudente sería:

instalar sudo-rs en un entorno de pruebas;
verificar punto por punto la configuración sudoers existente;
revisar PAM, registros, auditoría y scripts de automatización;
confirmar la ruta de reversión;
migrar después de que la distribución ofrezca una integración estable.

Este tipo de herramienta está en la cadena de privilegios, así que no basta con juzgarla por si puede ejecutar unos cuantos comandos. La verdadera validación está en las condiciones de borde y en los casos de fallo.

Resumen

sudo-rs es una implementación en Rust del sudo clásico, cuyo objetivo es mantener las funciones principales de sudo sobre una base de código más moderna y segura. Que Ubuntu 25.10 lo active por defecto muestra que las distribuciones principales están empezando a impulsar seriamente esta dirección.

Para los usuarios comunes, el cambio es pequeño. Sigues escribiendo sudo; solo puede haber cambiado la implementación subyacente a sudo-rs. Como mucho, notarás asteriscos al escribir la contraseña o mensajes de error ligeramente distintos.

Para los administradores de sistemas, la clave es la compatibilidad. Si el sistema tiene reglas sudoers complejas, notificaciones sendmail, integración PAM, comodines en argumentos o scripts que dependen de la salida de sudo, hay que probar antes de actualizar.

Reescribir en Rust no es una cura mágica, pero para una herramienta sensible de seguridad como sudo, reducir riesgos de seguridad de memoria y complejidad de mantenimiento es una dirección que merece atención.

Referencias:

X11 y Wayland: diferencias, ventajas, desventajas y cuándo elegir cada uno

Fri, 01 May 2026 19:23:01 +0800

En el escritorio Linux aparecen con frecuencia dos nombres: X11 y Wayland. Ambos están relacionados con la visualización gráfica, pero pertenecen a épocas distintas y siguen ideas de arquitectura y experiencia de uso muy diferentes.

En pocas palabras, X11 es el protocolo y ecosistema de visualización más antiguo. Es completo y muy compatible, pero su arquitectura es compleja y su modelo de seguridad está bastante envejecido. Wayland es el protocolo de visualización más moderno. Su objetivo es reducir capas intermedias, mejorar la seguridad y hacer que el escritorio se sienta más fluido, aunque todavía hay software y flujos de trabajo que necesitan adaptación.

Para el uso diario, la conclusión breve es:

en una instalación nueva de escritorio Linux, prueba primero Wayland;
si necesitas software antiguo, escritorio remoto complejo, dispositivos de entrada especiales o ciertas herramientas profesionales, X11 puede seguir siendo más estable;
para juegos y trabajo de oficina normal, Wayland ya es cada vez más usable;
si encuentras problemas de compatibilidad, puedes volver a X11. No hace falta convertirlo en una cuestión de fe.

Qué es X11

X11, también llamado X Window System o Xorg, es el sistema gráfico que los escritorios Linux y Unix han usado durante muchos años. Su diseño viene del entorno de computación en red de las primeras décadas: un programa podía ejecutarse en una máquina y mostrar su ventana en otra.

La estructura típica de X11 es:

las aplicaciones dibujan el contenido de las ventanas;
el X Server gestiona la pantalla, la entrada y las operaciones básicas de ventana;
el gestor de ventanas controla bordes, movimiento y apilamiento;
el compositor se encarga de sombras, transparencias, animaciones, control de tearing y efectos similares.

Esta arquitectura es flexible y permitió que X11 acumulara una gran cantidad de herramientas y extensiones. Pero con el paso del tiempo sus problemas se hicieron evidentes: muchos componentes, rutas largas, límites de permisos poco estrictos y muchas necesidades modernas mantenidas mediante extensiones y parches.

Qué es Wayland

Wayland no es un servidor de visualización completo en el sentido tradicional, sino un protocolo de visualización más moderno. En Wayland, el compositor suele asumir también el papel de servidor de visualización. Mutter de GNOME, KWin de KDE y los compositores basados en wlroots pueden actuar como compositores Wayland.

La estructura típica de Wayland es más corta:

las aplicaciones renderizan su propio contenido de ventana;
el compositor recibe los buffers enviados por las aplicaciones;
el compositor gestiona de forma centralizada ventanas, entrada, salidas de pantalla y composición;
la imagen final se entrega directamente a la pila gráfica del kernel para mostrarse.

Este diseño reduce los rodeos entre X Server, gestor de ventanas y compositor que existen en la arquitectura tradicional de X11. También hace que el control de permisos sea más claro: por defecto, las aplicaciones no pueden leer libremente el contenido de otras ventanas ni escuchar sin restricciones la entrada global del teclado.

Diferencias de arquitectura

La diferencia central está en el reparto de responsabilidades.

En X11, el X Server ocupa la posición central y muchas aplicaciones pueden interactuar con él. Los gestores de ventanas, compositores, métodos de entrada, herramientas de captura y herramientas de control remoto pueden obtener mucha información a través de las interfaces abiertas de X11. Esto aporta una compatibilidad muy fuerte, pero también problemas de seguridad.

En Wayland, el centro es el compositor. Las aplicaciones no pueden acceder directamente al contenido de otras ventanas ni escuchar todo el teclado por defecto. Funciones como capturas de pantalla, grabación, compartir pantalla, atajos globales y control remoto deben pasar por portales de escritorio, PipeWire o interfaces controladas ofrecidas por el compositor.

Puedes entenderlo así:

Punto	X11	Wayland
Época de diseño	Más antigua	Más reciente
Componente central	X Server	Compositor
Papel del compositor	Opcional o componente adicional	Componente central
Aislamiento entre aplicaciones	Más débil	Más fuerte
Visualización remota	Concepto nativo más fuerte	Depende de herramientas más nuevas
Compatibilidad	Muy fuerte	Todavía se está completando
Experiencia de escritorio moderna	Depende de extensiones y parches	Diseñada más cerca de las necesidades actuales

Ventajas de X11

La mayor ventaja de X11 es su madurez. Lleva muchos años en uso, y casi todos los programas gráficos de Linux funcionan bajo X11. Herramientas antiguas, software profesional, métodos de entrada especiales, soluciones de control remoto y scripts de automatización suelen dar soporte primero a X11.

Otra ventaja de X11 es su gran operabilidad. Muchas herramientas pueden leer ventanas directamente, simular entrada, capturar la pantalla, mover ventanas y escuchar pulsaciones de teclas. Esto resulta práctico para automatización, asistencia remota, scripts de gestión de ventanas y algunos flujos de trabajo especiales.

Si tus necesidades incluyen:

usar software GUI antiguo;
depender de xrandr, xinput, xdotool o wmctrl;
usar escritorio remoto tradicional o reenvío de ventanas;
necesitar herramientas especiales de captura, grabación o macros de teclado y ratón;
ejecutar una aplicación que todavía no es estable bajo Wayland;

entonces X11 sigue siendo una opción muy realista.

Desventajas de X11

Las desventajas de X11 vienen sobre todo de su carga histórica.

La primera es su modelo de seguridad antiguo. En una sesión tradicional de X11, una aplicación normal a menudo puede escuchar la entrada de otras ventanas, capturar el contenido de la pantalla y simular acciones de teclado y ratón. Desde una perspectiva moderna de seguridad de escritorio, esto es difícil de aceptar.

La segunda es la complejidad de la ruta de renderizado. X11 pasó por muchas extensiones: Composite, GLX, DRI, RandR, Present y otras. Estas extensiones le permitieron seguir soportando escritorios modernos, pero también hicieron más compleja la pila gráfica. En escenarios con altas tasas de refresco, varios monitores, escalado mixto, DPI mixto y entrada de baja latencia, X11 es más propenso a problemas de borde.

Además, el foco de mantenimiento de X11 se ha desplazado gradualmente hacia la compatibilidad. Los escritorios principales todavía soportan X11, pero las nuevas funciones y optimizaciones suelen llegar primero a Wayland.

Ventajas de Wayland

Las ventajas de Wayland están sobre todo en la experiencia de escritorio moderna.

Su ruta de renderizado es más directa. Las aplicaciones renderizan buffers y el compositor se encarga de la composición y visualización unificadas, reduciendo los rodeos de la arquitectura tradicional de X11. En animaciones, movimiento de ventanas, altas tasas de refresco, varios monitores, gestos de touchpad y escalado fraccionario, Wayland suele permitir una implementación más limpia.

La seguridad también es una ventaja importante de Wayland. Por defecto, las aplicaciones no pueden capturar otras ventanas libremente ni escuchar sin condiciones la entrada global del teclado. Las capturas, la grabación y el uso compartido de pantalla requieren autorización del usuario y normalmente se gestionan mediante portales de escritorio y PipeWire.

Wayland también se adapta mejor al hardware moderno. Gestos de touchpad, HiDPI, frecuencia de refresco variable y distintos factores de escalado por monitor suelen ser más naturales bajo Wayland. GNOME y KDE también han concentrado muchas mejoras de experiencia de escritorio en sus sesiones Wayland durante los últimos años.

Desventajas de Wayland

El problema de Wayland no es que “no se pueda usar”, sino que el ecosistema todavía está migrando.

Algunas herramientas dependían históricamente de las capacidades abiertas de X11, como escuchar teclas globales, enumerar ventanas, hacer clic automáticamente, capturar pantalla o mover ventanas. En Wayland eso no se puede copiar directamente: debe implementarse mediante portales, protocolos del compositor o API del entorno de escritorio. Por eso algunas herramientas antiguas dejan de funcionar, o solo funcionan en determinados entornos de escritorio.

El escritorio remoto es un caso típico. X11 nació con una idea de transparencia de red. Aunque la experiencia moderna no siempre sea perfecta, muchas herramientas ya maduraron a su alrededor. Bajo Wayland, el escritorio remoto necesita PipeWire, RDP, VNC, portales de escritorio o soporte del compositor, y la experiencia concreta depende de GNOME, KDE, Sway u otros entornos.

Los métodos de entrada también fueron un punto doloroso. Hoy Fcitx5 e IBus han mejorado claramente en los escritorios Wayland principales, pero ciertas aplicaciones Electron, programas antiguos o combinaciones especiales todavía pueden tener problemas con la posición de la ventana de candidatos, el foco o los atajos.

NVIDIA también fue durante mucho tiempo uno de los obstáculos para Wayland. En los últimos años, el soporte de los drivers NVIDIA y de los entornos de escritorio ha mejorado mucho, pero si usas una GPU antigua, un driver antiguo o una configuración multimonitor poco común, X11 todavía puede ser más estable.

Qué hace Xwayland

Mucha gente cree que, al pasar a Wayland, las aplicaciones X11 dejan de funcionar por completo. En realidad no es así.

Los escritorios Wayland suelen usar Xwayland para ejecutar aplicaciones X11 antiguas. La aplicación cree que se está ejecutando sobre X11, pero el contenido de su ventana se entrega después al compositor Wayland para mostrarse.

Esto suaviza mucho la migración:

las aplicaciones Wayland nativas usan Wayland;
las aplicaciones X11 antiguas usan Xwayland;
el usuario puede ejecutar ambos tipos de programas en la misma sesión de escritorio.

Sin embargo, Xwayland no lo resuelve todo. Si una herramienta depende de escuchar entrada global, scripts de gestión de ventanas o extensiones X11 de bajo nivel, puede seguir encontrando restricciones.

Cuál rinde mejor

No se puede decir simplemente que Wayland siempre sea más rápido que X11, ni que X11 siempre sea más estable. El rendimiento real depende del entorno de escritorio, el driver gráfico, el tipo de aplicación y el escenario de uso.

En general:

para animaciones normales de escritorio y pantallas de alta tasa de refresco, Wayland suele sentirse más fluido;
para DPI mixto y escalado en varios monitores, Wayland tiene ventaja;
para aplicaciones antiguas y herramientas especiales, X11 suele dar menos sorpresas;
en juegos, Wayland ya está bastante maduro gracias a Xwayland y al soporte nativo, aunque algunos juegos o herramientas de captura todavía pueden preferir X11;
para gráficos profesionales, control remoto y scripts de automatización, conviene probar herramienta por herramienta.

Para la mayoría de usuarios comunes, el rendimiento no es la diferencia principal. Lo que realmente decide la experiencia es la compatibilidad, los límites de seguridad, la configuración de monitores y el soporte de dispositivos de entrada.

Capturas, grabación y uso compartido de pantalla

Esta es una de las partes de Wayland que más se malinterpreta.

En X11, las herramientas de captura y grabación normalmente pueden capturar la pantalla directamente. Es cómodo, pero también significa que un programa malicioso puede espiar la pantalla con más facilidad.

En Wayland, las aplicaciones no pueden capturar la pantalla libremente. Las capturas, la grabación, las transmisiones y el uso compartido en reuniones suelen tener que pasar por portales de escritorio y PipeWire, con autorización del usuario. Esto es más seguro, pero exige que las aplicaciones soporten las interfaces nuevas.

Así que si una aplicación de reuniones, una herramienta de grabación o una herramienta de captura no funciona bien bajo Wayland, no significa necesariamente que Wayland “no lo soporte”. Es más probable que la aplicación no se haya adaptado bien a los portales o a PipeWire.

Qué deberían elegir los jugadores

Los juegos en Linux ya no son exclusivos de X11. Steam, Proton, Mesa, KDE, GNOME, Gamescope y Xwayland han hecho que la experiencia de juego en Wayland mejore mucho.

Si usas una GPU AMD o Intel, Wayland normalmente ya puede servir como entorno de juego diario. Si usas NVIDIA, los drivers nuevos también son cada vez más usables, aunque conviene mantener actualizados el driver y el entorno de escritorio.

Los jugadores pueden elegir así:

juegos normales de Steam / Proton: prueba primero Wayland;
si hay problemas de grabación, transmisión, overlays o latencia de entrada: compara con X11;
si usas Gamescope: el ecosistema Wayland encaja mejor;
si usas una GPU o driver antiguos: X11 puede ser más cómodo.

Escritorio remoto y automatización

Si tu flujo de trabajo depende de escritorio remoto, automatización de ventanas o control global de teclado y ratón, conviene ser más prudente.

X11 tiene muchas herramientas y un comportamiento directo en estos escenarios. Por ejemplo, controlar ventanas con scripts, simular clics o capturar el contenido de una ventana concreta suele ser más fácil bajo X11.

Por diseño de seguridad, Wayland no permite que una aplicación normal controle libremente otras ventanas. Esto significa que las herramientas de automatización deben usar interfaces proporcionadas por el entorno de escritorio, o bien implementaciones específicas de escritorio remoto. GNOME y KDE están completando estas capacidades, pero la consistencia entre escritorios todavía no alcanza la de X11.

Si eres un usuario común de escritorio, Wayland está bien. Si dependes mucho del control remoto, las pruebas automatizadas o scripts de gestión de ventanas, X11 todavía puede encajar mejor.

Cómo saber cuál estás usando

Puedes revisar el tipo de sesión actual con una variable de entorno:

`1`	`echo $XDG_SESSION_TYPE`

Si la salida es:

wayland

significa que estás en una sesión Wayland.

Si la salida es:

x11

significa que estás en una sesión X11.

En GNOME, KDE y otros escritorios similares, normalmente puedes cambiar entre X11 y Wayland desde el menú de engranaje o selector de sesión en la pantalla de inicio de sesión.

Recomendaciones de elección

Puedes decidir de esta forma:

Escenario	Recomendación
Equipo nuevo, distribución principal, oficina normal	Preferir Wayland
Versiones recientes de GNOME / KDE	Preferir Wayland
Varios monitores, HiDPI, alta tasa de refresco	Preferir Wayland
Software antiguo, GPU antigua, driver antiguo	Preferir X11
Escritorio remoto, scripts de ventanas, pruebas automatizadas	Preferir X11 o probar Wayland punto por punto
Juegos	Probar Wayland primero; si hay problemas, cambiar a X11
Compartir pantalla en reuniones, grabación	Depende del soporte de PipeWire / portales en el software
Escritorio sensible a seguridad o multiusuario	Preferir Wayland

Wayland es la dirección de futuro, pero X11 no va a desaparecer de inmediato. Ambos seguirán coexistiendo durante un tiempo.

Resumen

Las fortalezas de X11 son su madurez, compatibilidad y gran ecosistema de herramientas. Encaja bien con software antiguo, escritorio remoto, automatización de ventanas y algunos flujos de trabajo especiales. Sus puntos débiles son límites de seguridad pobres, una arquitectura compleja y una adaptación menos limpia a pantallas modernas con varios monitores, alta tasa de refresco y escalado mixto.

Las fortalezas de Wayland son una arquitectura más moderna, mejor seguridad, una ruta de visualización más directa y mejor soporte para HiDPI, gestos de touchpad, varios monitores y experiencias de escritorio modernas. Sus puntos débiles son los costes de adaptación en algunas herramientas antiguas, control remoto, capturas y grabación, y escenarios de métodos de entrada.

Los usuarios comunes pueden tomar Wayland como opción predeterminada. Si una aplicación o un periférico no se comporta bien, vuelve a X11 y compara. Para el escritorio Linux, no se trata de tomar partido, sino de elegir la opción que resulte más cómoda según tu hardware, software y flujo de trabajo.

Referencias:

Resumen de novedades de Linux Kernel 7.0

Fri, 01 May 2026 14:46:07 +0800

Los números de versión del kernel Linux nunca han seguido versionado semántico. Un salto de versión mayor suele tener más que ver con el ritmo de mantenimiento continuo del proyecto. En el mensaje de lanzamiento, Linus Torvalds también describió 7.0 como una versión normal: la última semana estuvo compuesta sobre todo por pequeñas correcciones en red, código de arquitectura, herramientas, selftests y drivers.

Lo que realmente merece atención es el conjunto de cambios incrementales. Linux 7.0 cubre sistemas de archivos, gestión de memoria, soporte de hardware, aislamiento de seguridad, soporte de Rust y limpieza de drivers.

Sistemas de archivos: XFS, EXT4 y NTFS3 cambiaron

Los sistemas de archivos son una de las áreas más visibles de Linux 7.0.

XFS introduce capacidades relacionadas con autorreparación. Junto con un nuevo mecanismo genérico de reporte de errores de sistemas de archivos, los sistemas de archivos pueden reportar corrupción de metadatos y errores de I/O al espacio de usuario de una forma más unificada. Con soporte adecuado de servicios del sistema, XFS puede manejar automáticamente algunos flujos de reparación mientras el sistema de archivos sigue montado. Esto no significa que cualquier problema de corrupción de disco pueda resolverse sin dolor, pero para servidores y sistemas de larga ejecución, la ruta de detección y reparación queda más completa.

EXT4 continúa mejorando el rendimiento de escrituras directas concurrentes. Si una máquina suele ejecutar copias de seguridad, builds, descargas, bases de datos o tareas de logs que escriben en disco al mismo tiempo, estas optimizaciones deberían volver más estable la ruta de escrituras concurrentes. No es el tipo de cambio que todo usuario de escritorio notará de inmediato, pero importa en escenarios de I/O pesada.

NTFS3 también recibe una actualización mayor del driver, incluida asignación diferida, operaciones de archivo basadas en iomap y mejor readahead para escaneos de directorios grandes. Si accedes a menudo a particiones Windows o discos NTFS externos desde Linux, estas mejoras merecen atención.

Además, exFAT mejora las lecturas secuenciales multi-cluster, lo que puede acelerar la lectura secuencial en algunos dispositivos con clusters pequeños.

Memoria y swap: mejor comportamiento bajo presión de memoria

Linux 7.0 continúa el trabajo de limpieza del subsistema swap de versiones recientes. Un foco es mejorar la ruta para leer páginas de vuelta desde swap, especialmente cuando varios procesos comparten las mismas páginas expulsadas. En esos casos, el throughput debería mejorar.

Para usuarios de escritorio, quizá no se sienta como si el sistema se volviera más rápido de golpe. Pero en sistemas con poca memoria, hosts densos de contenedores, servicios tipo Redis con persistencia activada o configuraciones zram respaldadas por disco, estos cambios pueden reducir jitter bajo presión de memoria.

Las rutas de zram también reciben optimizaciones. Antes, en algunos casos, el kernel necesitaba descomprimir páginas zram antes de escribirlas en un dispositivo de respaldo. La nueva ruta puede escribir datos comprimidos directamente, reduciendo procesamiento innecesario.

CPU y rendimiento: Intel TSX auto, hilos y operaciones de archivo más rápidas

Linux 7.0 ajusta la política predeterminada para Intel TSX. Por problemas de seguridad pasados, TSX estaba desactivado por defecto en muchos procesadores. El kernel ahora usa una política auto más precisa: las CPU afectadas lo mantienen desactivado, mientras las no afectadas o adecuadas pueden activarlo automáticamente.

Esto puede ayudar a algunas cargas multihilo, especialmente aplicaciones que dependen de extensiones de sincronización transaccional. No es un interruptor universal de aceleración; el beneficio real sigue dependiendo del modelo de CPU y de si la aplicación usa la función.

Linux 7.0 también incluye optimizaciones para asignación de PID, creación y destrucción de hilos, y rutas de apertura/cierre de archivos. Estas optimizaciones normalmente no se convierten en titulares por sí solas, pero se acumulan en pequeñas mejoras de respuesta del sistema y servicios de alta concurrencia.

Soporte de hardware: nuevas plataformas y mejoras de dispositivos existentes

Linux 7.0 continúa una gran cantidad de trabajo de habilitación de hardware. Estas actualizaciones suelen caer en dos grupos: preparación para plataformas que aún no están ampliamente disponibles y mejoras para dispositivos que ya están en manos de usuarios.

Para plataformas nuevas, Linux 7.0 incluye más preparación para Intel Nova Lake, Intel Crescent Island, nueva IP gráfica de AMD y AMD Zen 6. Estos cambios quizá no importen a usuarios comunes de inmediato, pero determinan si el nuevo hardware podrá recibir soporte en mainline más rápido después del lanzamiento.

En ARM64 y computadoras de placa única, la decodificación de video por hardware H.264/H.265 para Rockchip RK3588/RK3576 entra en el alcance de soporte mainline. Esto significa que dispositivos como Orange Pi 5 y Radxa ROCK 5 ya no necesitan depender por completo de kernels BSP del fabricante para decodificación por hardware.

También hay muchas mejoras detalladas para portátiles y periféricos:

ASUS WMI mejora soporte de retroiluminación, iluminación de teclado y hotkeys de ventilador para modelos ROG y TUF.
HP WMI agrega control manual de ventilador para algunos modelos Victus y corrige luces indicadoras de audio.
Lenovo WMI expone más información de monitoreo HWMON para dispositivos Legion.
El driver gráfico Intel Xe expone más sensores de temperatura.
Las GPU discretas Intel Arc serie B pueden entrar en estados PCIe de ahorro de energía más profundos.
Las guitarras Bluetooth de Rock Band 4 y el teclado Bluetooth Logitech K980 reciben mejor soporte del kernel.

Cada cambio es pequeño por separado, pero para usuarios de portátiles, dispositivos de juego, placas de desarrollo y periféricos, un soporte mainline más completo facilita el mantenimiento futuro de las distribuciones.

Seguridad y aislamiento: io_uring puede usar filtrado BPF

Linux 7.0 agrega soporte de filtrado BPF a io_uring. Esto importa para contenedores, sandboxes y entornos con requisitos altos de seguridad.

En el pasado, algunos administradores desactivaban io_uring por completo para reducir superficie de ataque. Con filtrado BPF, ahora pueden restringir operaciones permitidas de forma más precisa, en lugar de elegir solo entre totalmente habilitado o totalmente deshabilitado.

Esto no hace que los riesgos de io_uring desaparezcan automáticamente, pero da a administradores y frameworks de runtime una herramienta de aislamiento más controlable.

El soporte de Rust ya no es solo una etiqueta experimental

En Linux 7.0, el estado de Rust para Linux se vuelve más estable. Esto no significa que el kernel vaya a reescribirse masivamente en Rust, ni que C esté siendo reemplazado.

Más precisamente, la infraestructura para Rust dentro del kernel ha entrado en una etapa más formal. Futuros drivers, subsistemas o parte de código sensible a seguridad podrán elegir Rust donde encaje. Es una ruta gradual: estabilizar primero interfaces, sistema de build, documentación y proceso de mantenimiento, y luego dejar que el código real crezca con el tiempo.

Eliminación de funcionalidad antigua: desaparece laptop_mode

Linux 7.0 elimina laptop_mode. Era una función de ahorro de energía de larga historia, diseñada sobre todo para la era de portátiles con disco duro, reduciendo despertares de disco para ahorrar energía.

Los portátiles modernos son mayoritariamente SSD, y las rutas de reclaim de memoria, dispositivos de bloque y sistemas de archivos del kernel han cambiado mucho. Mantener este mecanismo antiguo aumenta el costo de mantenimiento, y su cobertura de pruebas no era ideal. Eliminarlo reduce el impacto de código viejo sobre rutas modernas.

Teclas relacionadas con IA: preparación para una nueva generación de interacción de teclado

Linux 7.0 agrega varios nuevos keycodes HID para interacción contextual con IA, como actuar sobre contenido seleccionado, insertar contenido generado por contexto e iniciar consultas contextuales.

Esto no es funcionalidad de IA integrada en el kernel. Se parece más a reservar definiciones de eventos de entrada para futuros teclados y periféricos, de modo que entornos de escritorio, aplicaciones o herramientas de fabricantes puedan reconocer esas teclas. Lo que hagan realmente seguirá dependiendo de la distribución, el entorno de escritorio y la integración a nivel de aplicación.

¿Conviene actualizar de inmediato?

Si usas una distribución rolling, Linux 7.0 probablemente llegará de forma natural mediante actualizaciones del sistema. Si usas una distribución nueva como Ubuntu 26.04 LTS, 7.0 también podría aparecer como versión de kernel predeterminada o principal.

Pero si tu máquina es un servidor de producción, NAS, host de virtualización o depende de drivers cerrados y módulos propietarios de kernel, no actualices manualmente solo porque el número de versión pasó a 7.0. Un enfoque más seguro es:

esperar a que la distribución proporcione paquetes oficiales de kernel;
comprobar compatibilidad de tarjetas gráficas, tarjetas de red, ZFS, VirtualBox, VMware y módulos DKMS;
probar primero en una máquina de pruebas o entorno con snapshot;
observar las versiones puntuales 7.0.x.

Según el directorio v7.x de kernel.org, ya se publicaron 7.0.1, 7.0.2 y 7.0.3. Si planeas compilar o probar manualmente, prefiere la última versión estable 7.0.x en lugar de enfocarte solo en el tarball inicial 7.0.

Resumen

Linux Kernel 7.0 no es una versión que reescriba todo solo porque cambió el número mayor. Se parece más a una actualización regular amplia del kernel: los sistemas de archivos son más confiables, swap e I/O siguen mejorando, el soporte de hardware avanza, y Rust, el aislamiento de io_uring y las definiciones de entrada HID completan infraestructura necesaria para la evolución a largo plazo.

Para usuarios comunes de escritorio, los cambios más prácticos quizá vengan del soporte de hardware, drivers gráficos, ahorro de energía y reparación de sistemas de archivos. Para servidores y desarrolladores, el reporte de errores y autorreparación de XFS, el filtrado BPF de io_uring, la optimización de swap y el soporte de nuevas plataformas merecen más atención.

Referencias:

Actualizaciones de hardware y GPU Ubuntu 26.04 LTS: CUDA, ROCm, DPC++ y más cambios de plataforma

Sun, 26 Apr 2026 19:35:57 +0800

Si el artículo anterior funcionó como una descripción general centrada en el escritorio de Ubuntu 26.04 LTS, es mejor leer este como su seguimiento del hardware y la computación. En este ciclo 26.04, Ubuntu impulsó una serie de cambios en IA, computación GPU y compatibilidad de plataforma en el archivo principal o alcance de soporte formal.

La versión corta es esta: la parte más importante de esta ronda no son solo las actualizaciones de escritorio y kernel, sino que Ubuntu está incorporando pilas de computación de GPU Intel, NVIDIA y AMD a la distribución de una manera más sistemática.

1. Intel DPC++ y componentes relacionados ahora están en Ubuntu Archive

A partir de 26.04, el compilador de código abierto oneAPI DPC++ de Intel está disponible directamente desde Ubuntu Archive para crear código SYCL. Su tiempo de ejecución también incluye adaptadores para GPU Intel.

Ahora también están disponibles dos componentes relacionados en los repositorios de Ubuntu:

oneDPL, la biblioteca DPC++, que proporciona API de desarrollador de mayor productividad
oneDNN, creado con dpclang-6, que puede ejecutarse en GPU Intel

Eso significa que si ya está trabajando con SYCL, computación heterogénea o cargas de trabajo de IA en GPU Intel, Ubuntu ahora ofrece una ruta más directa en lugar de obligarlo a mantener una pila externa separada para todo.

Ubuntu también señala un requisito práctico: los usuarios deben estar en el grupo “renderizar” para utilizar realmente estas capacidades relacionadas con la GPU Intel.

2. El kit de herramientas NVIDIA CUDA ahora se puede instalar directamente con `apt`

Para muchos desarrolladores y operadores, este puede ser uno de los cambios más útiles de inmediato en las notas.

A partir de 26.04, el kit de herramientas NVIDIA CUDA ahora se puede instalar directamente desde Ubuntu Archive:

`1`	`sudo apt install cuda-toolkit`

El valor aquí es mayor que simplemente guardar algunos pasos de configuración.

Para los desarrolladores que envían software en Ubuntu, este nuevo modelo significa que pueden simplemente declarar una dependencia del “tiempo de ejecución CUDA”, mientras que Ubuntu gestiona la instalación y la compatibilidad a nivel de distribución. Eso hace que CUDA se sienta más como una capacidad nativa del sistema en Ubuntu, en lugar de una capa de software adicional que siempre debe mantenerse por separado.

3. AMD ROCm 7.1.0 ya está en Universe

Por el lado de AMD, Ubuntu Universe ahora incluye ROCm 7.1.0.

Estas bibliotecas proporcionan principalmente:

infraestructura backend para entrenamiento e inferencia de IA en GPU AMD
fundamentos de software para el aprendizaje automático y la informática de alto rendimiento

Canonical también señala que los componentes relacionados con ROCm se prueban continuamente en su canal de CI/CD. Más allá de “autopkgtests”, eso incluye varias aplicaciones de espacio de usuario como:

-llama.cpp -pytorch

licuadora
Servidor de limonada

Ese detalle es importante, porque muestra que Ubuntu no se limita a colocar paquetes en el archivo. Está validando ROCm como una pila de software mantenible.

4. La historia más importante es que los tres ecosistemas de GPU están aterrizando

Es más fácil ver la dirección de 26.04 cuando DPC++, CUDA y ROCm se ven juntos:

Intel: incorporando componentes SYCL/oneAPI a repositorios oficiales
NVIDIA: dando al kit de herramientas CUDA una ruta de instalación administrada por distribución
AMD: lanzando ROCm 7.1.0 en Universe con pruebas en curso

Si trabaja con este tipo de cargas de trabajo en Ubuntu, esta versión probablemente le resultará más relevante:

inferencia local LLM
Entrenamiento o ajuste acelerado por GPU
Blender, informática científica y HPC.
entornos de desarrollo que necesitan moverse a través de diferentes plataformas GPU

En otras palabras, Ubuntu ya no es sólo “un sistema donde puedes instalar un controlador de GPU”. Está comenzando a tener una pila de software de espacio de usuario más completa para computación con IA y GPU.

5. NVIDIA Dynamic Boost está habilitado de forma predeterminada

Desde el “25.04”, “Dynamic Boost” se ha habilitado de forma predeterminada en las computadoras portátiles NVIDIA compatibles.

La idea es sencilla: dependiendo de la carga del sistema, la energía se puede cambiar dinámicamente entre la CPU y la GPU. En escenarios de juegos, eso generalmente significa darle más potencia a la GPU cuando sea necesario para extraer más rendimiento.

Sólo se aplica bajo dos condiciones:

la computadora portátil está conectada a la alimentación de CA
la carga de la GPU es lo suficientemente alta

No se activa mientras el sistema está funcionando con batería.

6. La compatibilidad con las nuevas GPU Intel integradas y discretas sigue avanzando

Ubuntu también continúa ampliando el soporte para nuevas GPU Intel, que incluyen:

Integrado:

-Intel Core Ultra Xe2 -Intel Core Ultra Xe3

Discreto:

Intel Arco 5 B570 -Intel Arc 5 B580 -Intel Arc Pro B50 -Intel Arc Pro B60 -Intel Arc Pro B65 -Intel Arc Pro B70

Ubuntu también destaca varias características que ya están disponibles en estos dispositivos:

rendimiento mejorado del trazado de rayos de GPU y CPU a través de Intel Embree, beneficiando aplicaciones como Blender 4.2+
codificación de vídeo por hardware para AVC, JPEG, HEVC y AV1 en dispositivos “Battlemage”
una nueva optimización CCS en Intel Compute Runtime
soporte de depuración habilitado para GPU Intel Xe

Si está viendo las versiones de seguimiento, “25.10” también continúa incorporando más capacidades, que incluyen:

soporte inicial para la plataforma de cliente de próxima generación de Intel con nombre en código Panther Lake hasta Linux kernel 6.17
IOMMU mejorado, subsistema PCIe y compatibilidad con múltiples GPU
Mesa 25.2.3 habilitando VK_KHR_shader_bfloat16 para Battlemage y Panther Lake
intel-media-driver 25.3.0 agrega soporte de decodificación Panther Lake y codificación VP9
intel-compute-runtime 25.31 ajusta el comportamiento de asignación de eventos de memoria del dispositivo local y del grupo USM de nivel cero
level-zero 1.24 y level-zero-raytracing 1.1.0 brindan compatibilidad con especificaciones más amplias y extensión RTAS

7. Suspender y reanudar también es más estable en las computadoras de escritorio Nvidia

A partir de 25.10, Ubuntu habilita el soporte de suspensión y reanudación en el controlador propietario Nvidia para reducir la corrupción y la congelación al activar un sistema de escritorio.

Este no es el tipo de cambio más visible, pero es muy importante en el uso diario, especialmente en computadoras de escritorio que permanecen encendidas durante períodos prolongados y que se suspenden y reanudan con frecuencia.

8. ARM, Raspberry Pi, RISC-V e IBM Z también reciben cambios más difíciles a nivel de plataforma

Más allá de la pila de software de GPU, las notas de la versión también incluyen varios cambios a nivel de plataforma que vale la pena mencionar por separado.

Plataformas de escritorio ARM64

A partir de 25.10, el kernel linux-generic ARM64 proporciona una compatibilidad de escritorio más amplia para las plataformas de escritorio ARM64 que arrancan a través de UEFI.

Un nuevo diseño de arranque de Raspberry Pi

Un cambio introducido en 25.10 y refinado en 26.04 es un nuevo diseño de partición de arranque para sistemas Raspberry Pi. Su objetivo es mejorar la confiabilidad del arranque: los recursos de arranque recién escritos primero se “prueban” antes de confirmarlos como el nuevo conjunto “bueno conocido”.

Los requisitos de fecha del firmware son la parte que la mayoría de los usuarios querrán recordar:

Pi 3 / 3+ / CM3+ / Zero 2W: no se requiere ninguna acción adicional, el firmware de arranque está en la propia imagen
Pi 4/400/CM4: el firmware de arranque no debe tener una fecha anterior a 2022-11-25
Pi 5/500/CM5: el firmware de arranque no debe tener una fecha anterior a 2025-02-11

Puedes comprobarlo con:

`1`	`sudo rpi-eeprom-update`

Si el firmware es demasiado antiguo y está utilizando “Ubuntu 24.04 LTS” o más reciente, puede actualizarlo de esta manera:

1
2

sudo rpi-eeprom-update -a
sudo reboot

Las imágenes de escritorio de Raspberry Pi ahora usan escritorio mínimo

Desde “25.10”, las imágenes de escritorio de Ubuntu para Raspberry Pi se basan en “desktop-minimal” en lugar de en la semilla de “escritorio” completa.

Ubuntu ofrece aquí un beneficio muy concreto: el conjunto de aplicaciones predeterminado es más pequeño, lo que ahorra alrededor de “777 MB” en la imagen sin comprimir y en los sistemas instalados.

Si desea eliminar esa aplicación predeterminada configurada de forma masiva después de la actualización, puede usar:

`1`	`sudo apt purge ubuntu-desktop --autoremove`

Si desea conservar algunas de esas aplicaciones, primero márquelas como instaladas manualmente con “apt”.

El intercambio en Raspberry Pi ahora lo maneja cloud-init

Desde “25.10”, la creación de archivos de intercambio en imágenes de escritorio de Raspberry Pi se maneja mediante “cloud-init”.
Si desea personalizar el tamaño del intercambio antes del primer inicio, puede editar los “datos de usuario” directamente en la partición de inicio.

Los requisitos de RISC-V han aumentado

A partir de 25.10, la compilación RISC-V de Ubuntu 26.04 LTS requiere hardware que implemente el perfil ISA RVA23S64.

Los sistemas que no cumplan con ese requisito ya no podrán ejecutar “Ubuntu 26.04 LTS”. Si todavía tiene placas basadas en núcleos de procesador “RVA20” anteriores, debe permanecer en la línea de soporte proporcionada por “Ubuntu 24.04 LTS”.

Según Ubuntu, a partir de “abril de 2026”, todavía no hay hardware “RVA23S64” real disponible. Por lo tanto, la única plataforma actualmente compatible es efectivamente un entorno virtualizado “QEMU” configurado con “-cpu rva23s64”.

IBM Z ahora requiere z15 como mínimo

A partir de 26.04, el requisito mínimo para la arquitectura s390x pasó a z15.

Eso significa:

z14 / LinuxONE II y sistemas más antiguos ya no pueden instalar Ubuntu 26.04 LTS
z15 / LinuxONE III y los sistemas más nuevos deberían tener un mejor rendimiento

9. ¿Quién debería leer esto primero?

Este artículo es más útil que la descripción general del escritorio si se encuentra en alguno de estos casos:

usas Ubuntu para CUDA, ROCm, SYCL o inferencia de IA local
realiza trabajos de desarrollo o computación en GPU Intel, NVIDIA o AMD
mantiene Raspberry Pi, ARM64, RISC-V, IBM Z u otras plataformas x86 no estándar
eres especialmente sensible a la disponibilidad del repositorio, el comportamiento del controlador, los tiempos de ejecución y los requisitos de la plataforma después de una actualización

10. Comida para llevar de una línea

El punto clave de “Ubuntu 26.04 LTS” en el lado del hardware y la pila de IA no es que un proveedor de GPU haya obtenido una actualización destacada. Es que DPC++ de Intel, CUDA de NVIDIA y ROCm de AMD están ingresando al ecosistema Ubuntu de una manera más oficial, en repositorio y mantenible. Si solía pensar en Ubuntu como “primero el sistema, luego yo mismo ensamblo el entorno de GPU”, 26.04 comienza a parecerse más a una distribución que está dispuesta a transportar activamente IA y cargas de trabajo informáticas heterogéneas.

Lanzamiento de Ubuntu 26.04 LTS: importantes actualizaciones de escritorio con GNOME 50 y Linux 7.0

Sun, 26 Apr 2026 16:10:25 +0800

Ubuntu 26.04 LTS se lanzó el 23 de abril de 2026, con el nombre en clave Resolute Raccoon. Esta es la nueva versión de soporte a largo plazo, con soporte estándar hasta abril de 2031. Si utiliza Ubuntu Pro, el mantenimiento de la seguridad se puede extender a 10 años.

Si está actualizando desde Ubuntu 24.04 LTS, esto es más que una versión de rutina. También incluye los principales cambios introducidos en 24.10, 25.04 y 25.10. Por lo tanto, este artículo funciona mejor como guía rápida sobre lo que vale la pena comprobar antes de actualizar.

Si solo desea obtener las conclusiones más importantes de este lanzamiento, recuerde primero estos cuatro puntos:

GNOME 50 ha llegado a una versión LTS, aportando mejoras más claras a la experiencia de escritorio y soporte de pantalla
Linux kernel 7.0 se convierte en la nueva base, actualizando tanto el soporte de hardware como la base de mantenimiento a largo plazo.
Ubuntu Desktop ahora se ha trasladado completamente a Wayland
El conjunto de aplicaciones predeterminado se ha actualizado en todos los ámbitos, con actualizaciones importantes para Firefox, LibreOffice, Thunderbird y GIMP

1. Comience con las actualizaciones clave

Ubuntu 26.04 LTS es una versión de soporte a largo plazo con soporte estándar hasta 2031-04
El entorno de escritorio se ha actualizado a GNOME 50
El kernel genérico se ha movido a Linux kernel 7.0
Ubuntu Desktop ahora proporciona sólo una sesión Wayland
Las versiones anteriores no pueden saltar directamente a 26.04

Si todavía está en Ubuntu 22.04 LTS o 25.04, la recomendación oficial es actualizar primero a Ubuntu 24.04 LTS o 25.10 y luego continuar a 26.04 LTS.

2. Mayor cambio #1: GNOME 50 ahora está en LTS

El cambio más visible en el lado del escritorio esta vez es que GNOME 50 finalmente entró en una versión LTS. Para la mayoría de los usuarios, el valor no es una característica llamativa e independiente, sino una experiencia de escritorio más fluida en general:

Mejor usabilidad en pantallas pequeñas y ventanas estrechas
Las notificaciones se pueden agrupar por aplicación.
Mejoras continuas en HDR, VRR y escalado fraccional
Mejor fluidez y estabilidad en escenarios relacionados con escritorio remoto, Wayland y NVIDIA
Mayor soporte de accesibilidad, incluidas actualizaciones claras del lector de pantalla “Orca”.

Ubuntu también ha agregado algunos cambios prácticos propios:

La búsqueda global de GNOME Shell puede encontrar directamente aplicaciones snap disponibles
Las búsquedas web también se pueden activar directamente desde la búsqueda.
El tema Yaru continúa acercándose al estilo original de GNOME.
Los permisos, el acceso a archivos y el comportamiento de arrastrar y soltar para aplicaciones “snap” se sienten más naturales en el escritorio

Si utiliza principalmente la edición de escritorio, el verdadero objetivo de este LTS no es una revisión visual dramática. Es que muchas pequeñas fricciones del pasado se han eliminado juntas.

3. Mayor cambio n.º 2: las aplicaciones predeterminadas obtuvieron una amplia actualización

En comparación con 24.04 LTS, la aplicación integrada configurada en 26.04 LTS se ha actualizado en gran medida:

Firefox pasa a 150
LibreOffice pasa de 24.2 a 25.8
Thunderbird pasa a 140
GIMP salta de 2.10 a 3.2

También existen varios reemplazos que son importantes en el uso diario:

El visor de PDF ahora es “Papers”, reemplazando a “Evince”.
El visor de imágenes ahora es “Lupa”.
La terminal ahora es Ptyxis
El monitor del sistema ahora es “Recursos”.
El reproductor de vídeo predeterminado ahora es “Showtime”. La dirección detrás de estos cambios es clara: Ubuntu se está inclinando más hacia una nueva generación de aplicaciones GNOME construidas sobre GTK4, libadwaita y, en algunos casos, reescrituras basadas en Rust.

4. Mayor cambio n.° 3: Wayland ahora es la única sesión de escritorio

Este es el cambio más importante para muchos usuarios veteranos.

El cambio que comenzó en 25.10 ahora está completamente establecido en 26.04 LTS: Ubuntu Desktop se ejecuta solo en el backend Wayland, porque GNOME Shell ya no puede ejecutarse como una sesión X.org.

Eso no significa que las aplicaciones antiguas dejen de funcionar repentinamente. Las notas oficiales dejan claro que las aplicaciones “X.org” aún pueden ejecutarse a través de la capa de compatibilidad “XWayland”. Pero si su flujo de trabajo aún depende de controladores de gráficos más antiguos, ciertos métodos de escritorio remoto, herramientas de grabación de pantalla o detalles del método de entrada, esto es algo que aún debe verificar antes de actualizar.

5. Mayor cambio n.º 4: el kernel de Linux 7.0 y la pila inferior avanzan juntos

La pila genérica GA en Ubuntu 26.04 LTS pasa de Linux 6.8 a Linux 7.0, y la pila HWE también se unifica en 7.0.

Entre los cambios de nivel inferior destacados por Ubuntu, los más relevantes para usuarios y operadores en general son:

El volcado por caída está habilitado de forma predeterminada tanto en el escritorio como en el servidor.
sched_ext introduce un nuevo modelo de extensión de programación que permite a los desarrolladores implementar políticas de programación con eBPF
El paquete binario linux-lowlatency está siendo retirado y reemplazado por linux-generic más el paquete de espacio de usuario lowlatency-kernel para ajuste de baja latencia.
La variante de arquitectura amd64v3 está disponible como opción, pero aún está habilitada de forma predeterminada.

Si su máquina es relativamente nueva, vale la pena vigilar “amd64v3”. Las notas oficiales dan este método de habilitación:

1
2
3

echo 'APT::Architecture-Variants "amd64v3";' | sudo tee /etc/apt/apt.conf.d/99enable-amd64v3
sudo apt update
sudo apt upgrade

Dicho esto, no se habilita automáticamente. Ubuntu todavía prioriza la compatibilidad primero.

6. Requisitos de hardware y línea base de instalación

La base de referencia oficial recomendada para Ubuntu Desktop 26.04 LTS es:

Un procesador de doble núcleo de 2 GHz o mejor
Al menos 6 GB de RAM
Al menos “25 GB” de almacenamiento disponible

Si su máquina es más ligera, la recomendación oficial es considerar versiones de Ubuntu como Xubuntu o Lubuntu.
La edición de servidor tiene un piso inferior. La documentación señala que puede comenzar desde “1,5 GB de RAM” y “4 GB” de almacenamiento, aunque el requisito real aún depende de su carga de trabajo.

7. ¿Quién debería priorizar la actualización?

Si ya está en 24.04 LTS y desea lo siguiente, vale la pena echarle un vistazo a 26.04 LTS:

Una actualización de la pila de escritorio de generación completa en lugar de parches menores
Wayland más maduro y soporte de visualización
Un conjunto de aplicaciones predeterminado más actualizado
Un kernel más nuevo con una pista de soporte más larga.

Pero si todavía depende en gran medida de flujos de trabajo X11 antiguos, controladores especiales o extensiones de escritorio personalizadas, o si su entorno de producción es extremadamente conservador con respecto a los cambios, es mejor realizar una prueba de compatibilidad antes de actualizar.

8. Resumen de una línea

El valor de “Ubuntu 26.04 LTS” no es una característica especialmente llamativa. Es que Ubuntu ha incorporado dos años de progreso de escritorio, kernel, aplicaciones y compatibilidad a una nueva línea base LTS, todo a la vez. Si desea el juicio más breve posible, es este: esta es una versión LTS de Ubuntu que se siente más nueva y más estable en su conjunto, en lugar de una basada en una única característica destacada.

Enlaces relacionados

Notas de la versión oficial: https://documentation.ubuntu.com/release-notes/26.04/
Resumen para usuarios de LTS: https://documentation.ubuntu.com/release-notes/26.04/summary-for-lts-users/

Comprensión del marco de trabajo de nftables: tablas, cadenas, reglas y conjuntos

Sat, 18 Apr 2026 10:31:12 +0800

Al aprender nftables, es fácil comenzar con los detalles del comando: cómo agregar una regla, cómo eliminar un identificador o cómo escribir una coincidencia de puerto. Los comandos son importantes, pero si primero comprende el marco, leer reglas, solucionar problemas y diseñar conjuntos de reglas será mucho más fácil.

Puedes pensar en nftables como una estructura en capas:

table aísla los espacios de nombres de reglas.
La “familia” decide a qué protocolos de red se aplican las reglas.
“cadena” decide en qué etapa se ejecutan las reglas.
La regla define el partido y la acción reales.
set, map y verdict map reducen las reglas repetidas y facilitan el mantenimiento de los conjuntos de reglas.

Las siguientes secciones explican estos conceptos capa por capa.

tabla: espacio de nombres de reglas

table es el contenedor de reglas más externo en nftables. Las diferentes tablas están aisladas entre sí, por lo que una práctica común es colocar reglas relacionadas en la misma tabla.

Por ejemplo, puede separar reglas de filtrado, reglas NAT o reglas de prueba personalizadas. Esto mantiene los límites claros: al depurar, sabes qué grupo de reglas estás cambiando; Al limpiar, es menos probable que elimines por error contenido no relacionado.

Una tabla en sí misma no procesa paquetes directamente. Los objetos de cadena y regla dentro de la tabla son los que realmente participan en el procesamiento de paquetes.

familia: a qué protocolos se aplican las reglas

Al crear una tabla, debe elegir una “familia”. Determina a qué tipo de paquetes se aplican las reglas de la tabla.

Las familias comunes se pueden entender de esta manera:

ip: solo maneja IPv4.
ip6: solo maneja IPv6.
inet: maneja tanto IPv4 como IPv6.
arp: maneja ARP.
bridge: maneja el tráfico de la capa de puente.
netdev: más cercano a la ruta de ingreso del dispositivo de red, adecuado para manejar el tráfico en una etapa anterior.

Para las reglas de firewall ordinarias, se utiliza comúnmente “inet”. Le permite mantener las reglas de IPv4 e IPv6 en la misma tabla y evita mantener dos estructuras de reglas similares.

cadena: Dónde se ejecutan las reglas

“cadena” es una lista de reglas. Después de que un paquete ingresa a un gancho, pasa por las reglas de la cadena en orden.

Las cadenas se pueden dividir a grandes rasgos en dos tipos:

Cadena base: adjunta a un gancho en la ruta de la red del kernel y llamada activamente por el flujo de paquetes.
Cadena normal: no unida directamente a un gancho; debe ser llamado mediante saltos de otras reglas.

Una cadena base suele especificar varias propiedades clave:

tipo: el propósito de la cadena, como filtro, nat o ruta.
hook: la etapa de procesamiento, como prerouting, input, forward, output o postrouting.
prioridad: cuando existen varias cadenas en el mismo gancho, esto decide cuál se ejecuta primero.
política: la acción predeterminada cuando no coincide ninguna regla, comúnmente aceptar o eliminar.

El punto clave es que las reglas no entran en vigor en cualquier lugar. La misma regla tiene un significado completamente diferente cuando se coloca en “entrada”, “adelante” o “salida”.

regla: Coincidir condiciones más acciones

La “regla” es donde nftables realmente toma decisiones. Suele constar de dos partes:

Condiciones de coincidencia: IP de origen, IP de destino, protocolo, puerto, interfaz, estado de conexión, etc.
Acciones: aceptar, soltar, rechazar, contrarrestar, saltar, regresar, etc. Las reglas se evalúan en orden. Después de que un paquete coincide con una acción que finaliza el procesamiento, las reglas posteriores ya no se evalúan. Si nada coincide, la evaluación continúa hasta que finaliza la cadena o se activa la política predeterminada.

Esta es la razón por la que el orden de las reglas es importante: las reglas más específicas generalmente deben aparecer antes que las reglas más amplias; de lo contrario, es posible que nunca tengan la oportunidad de ejecutarse.

set: Agrupar valores

Si necesita hacer coincidir muchas direcciones IP, puertos o interfaces, escribir muchas reglas separadas resulta difícil de mantener. set te permite administrar un grupo de valores del mismo tipo en un solo lugar.

Por ejemplo, un grupo de IP confiables, un grupo de puertos bloqueados o un grupo de direcciones que necesitan limitación de velocidad se pueden almacenar en un conjunto. La regla sólo necesita comprobar si un valor pertenece a ese conjunto.

Los beneficios del conjunto son:

Menos reglas.
Mejor legibilidad.
Adiciones y eliminaciones de elementos más sencillas posteriormente.

Cuando un conjunto de reglas contiene muchas condiciones repetidas, generalmente es el momento de considerar el conjunto.

map: asignar un valor coincidente a un resultado

“mapa” puede entenderse como una tabla de búsqueda. Devuelve un resultado basado en un valor de entrada.

Por ejemplo, diferentes puertos pueden asignarse a diferentes marcas, o diferentes direcciones pueden asignarse a diferentes parámetros de procesamiento. En comparación con escribir muchas reglas de estilo if/else, el mapa está más centralizado y es más fácil de mantener.

establecer respuestas “¿está este valor en la colección?”; el mapa responde “qué resultado corresponde a este valor”.

mapa de veredicto: asignar un valor coincidente a una acción

El “mapa de veredicto” es un uso importante del mapa: asigna un valor coincidente a un veredicto, lo que significa una acción de regla.

Por ejemplo, diferentes rangos de IP pueden corresponder a “aceptar”, “eliminar” o saltos a diferentes cadenas. Esto puede comprimir muchas ramas en una sola estructura.

Cuando un conjunto de reglas se vuelve más complejo, el mapa de veredictos es muy útil. Reduce las reglas repetidas y expresa la política más como una tabla que como una larga lista de declaraciones condicionales.

Diseñar reglas a partir de los conceptos

Al diseñar reglas de nftables, puedes pensar en este orden:

Primero decida a qué “familia” pertenecen las reglas.
Luego decida en qué “tabla” deberían entrar.
Elija el “gancho” y la “cadena” adecuados.
Escribe la “regla” concreta.
Si hay muchas condiciones repetidas, introduzca “conjunto”, “mapa” o “mapa de veredicto”.

Las reglas escritas de esta manera son más fáciles de mantener y de solucionar problemas.

Resumen

Los conceptos de nftables no son complicados, pero la jerarquía importa:

la tabla define los límites de las reglas.
la familia define el alcance del protocolo.
la cadena define la posición de ejecución.
la regla define la coincidencia y la acción.
establecer, mapear y veredicto gestionar la complejidad.

Primero comprenda estos conceptos y luego observe los comandos concretos. Esto es más confiable que memorizar comandos directamente. Especialmente después de que un conjunto de reglas crece, los conceptos claros lo ayudan a determinar si un problema está en el alcance del protocolo, la etapa de ejecución, el orden de las reglas o la condición de coincidencia en sí.

Referencias

https://docs.redhat.com/zh-cn/documentation/red_hat_enterprise_linux/10/html/configuring_firewalls_and_packet_filters/concepts-in-the-nftables-framework

Inicio rápido de nftables: tablas, cadenas, reglas y operaciones comunes

Sat, 18 Apr 2026 10:22:07 +0800

nftables es una herramienta común de administración de reglas de firewall y filtrado de paquetes en Linux. Si solo necesita control de acceso al dispositivo, contadores de tráfico, coincidencia de puertos o limitación de velocidad básica, no necesita aprender todo el sistema de reglas de una vez. Comience con tres conceptos:

table: un contenedor de reglas.
cadena: donde se evalúan las reglas, generalmente unidas a un gancho.
regla: la condición y acción coincidentes reales.

Este artículo describe un flujo de trabajo mínimo que es adecuado para realizar pruebas primero en un entorno seguro.

Estructura básica

Prepare algunas variables primero. Los siguientes comandos los reutilizan:

table=customtable
chain=custom_control
target=drop
ip=192.168.18.251
mac=00:00:01:02:03:04

Cree una tabla inet que admita IPv4 e IPv6:

`1`	`nft add table inet $table`

Luego cree una cadena adjunta a la etapa “adelante”:

`1`	`nft add chain inet $table $chain { type filter hook forward priority 0\; }`

Aquí, “tipo filtro” significa que se trata de una cadena de reglas de filtrado y “enganche hacia adelante” significa que procesa paquetes reenviados.

Métodos de coincidencia comunes

Coincidencia por IP de origen. Esto suele ser útil para la dirección de carga:

`1`	`nft add rule inet $table $chain ip saddr $ip $target`

Coincidencia por IP de destino. Esto suele ser útil para la dirección de descarga:

`1`	`nft add rule inet $table $chain ip daddr $ip $target`

Cuando se hace coincidir por dirección MAC, se puede usar ether saddr para controlar el tráfico ascendente:

`1`	`nft add rule inet $table $chain ether saddr $mac $target`

Tenga en cuenta que en redes que implican puenteo, reenvío o traducción de direcciones, es posible que los paquetes descendentes no siempre se filtren de manera confiable por MAC de destino. Para el control de acceso al dispositivo, comience validando primero ether saddr o las reglas basadas en IP.

Para hacer coincidir los puertos, puede cubrir tanto TCP como UDP:

`1`	`nft add rule inet $table $chain { tcp, udp } dport 22 $target`

Para hacer coincidir un rango de puertos, utilice una expresión de comparación:

`1`	`nft add rule inet $table $chain tcp dport \>= 1024 $target`

Contar el tráfico para un dispositivo

Si solo desea contar el tráfico de carga y descarga para una dirección IP, utilice “contrarretorno”. Después de una coincidencia, registra el contador y regresa, lo que puede reducir aún más los gastos generales de coincidencia cuando existan más reglas estadísticas más adelante.

1
2

nft add rule inet $table $chain ip saddr $ip counter return
nft add rule inet $table $chain ip daddr $ip counter return

Ver las estadísticas:

`1`	`nft list chain inet $table $chain`

Si necesita ver el “identificador” de cada regla, agregue “-a”:

`1`	`nft -a list chain inet $table $chain`

handle es importante porque nftables generalmente depende de él para eliminar una sola regla.

Limitación de tasa básica

La limitación de la tasa se puede realizar con “tasa límite superior”. Por ejemplo, limite el tráfico a una velocidad específica por dirección MAC:

rate=10
unit=mbytes

nft add rule inet $table $chain ether saddr $mac limit rate over $rate $unit/second drop

Aquí, “mbytes” y “kbytes” pueden entenderse como las unidades habituales M y K. No es necesario multiplicar manualmente por 8. En la práctica, comience con un valor más relajado, confirme la dirección y el efecto correspondientes y luego apriételo si es necesario.

Eliminar y limpiar reglas

Primera lista de reglas con valores de control:

`1`	`nft -a list chain inet $table $chain`

Luego elimine una regla por identificador:

`1`	`nft delete rule inet $table $chain handle <handle>`

Lavar una cadena:

`1`	`nft flush chain inet $table $chain`

Eliminar una cadena:

`1`	`nft delete chain inet $table $chain`

Eliminar toda la tabla:

`1`	`nft delete table inet $table`

Durante la depuración diaria, limpie únicamente la tabla que creó usted mismo. Evite cambiar directamente las tablas generadas automáticamente por el sistema u otros servicios. Esto facilita la reversión incluso si una regla está escrita incorrectamente.

Notas de uso

Cuando se utilizan nftables, suele ser más seguro crear primero su propia tabla y cadena independientes. Esto tiene dos beneficios:

Es menos probable que sus reglas se mezclen con las reglas del sistema existente.
La depuración, el vaciado y la eliminación son más seguros.

Después de escribir reglas, utilice siempre nft list chain para verificar el comportamiento de coincidencia real. Las reglas de MAC, interfaz, puerto y límite de velocidad pueden comportarse de manera diferente entre dispositivos, configuraciones de puente y versiones del sistema. Las pruebas de pequeño alcance son más seguras que escribir reglas complejas todas a la vez.

Referencias

https://www.right.com.cn/forum/thread-8369750-1-1.html

Ubicación predeterminada de modelos de Ollama y método de migración (para evitar llenar la unidad C)

Mon, 06 Apr 2026 09:38:00 +0800

Cuando ejecutas modelos grandes localmente, lo primero que suele quedarse sin espacio es la unidad del sistema. Ollama descarga los modelos de forma predeterminada en el directorio del usuario o en un directorio del sistema. Si no planificas la ruta con antelación, la unidad C puede llenarse muy rápido.

Directorios predeterminados habituales de modelos de Ollama

Windows: C:\Users\<用户名>\.ollama\models
macOS: ~/.ollama/models
Linux: /usr/share/ollama/.ollama/models (puede variar según el método de instalación)

Windows: migrar el directorio de modelos a una unidad que no sea del sistema

Se recomienda mover el directorio de modelos, por ejemplo, a D:\OllamaModels. El método clave es configurar la variable de entorno del sistema OLLAMA_MODELS.

1. Crear el directorio de destino

Por ejemplo, crea primero: D:\OllamaModels

2. Configurar la variable de entorno del sistema

Nombre de variable: OLLAMA_MODELS
Valor de variable: D:\OllamaModels

Puedes añadirla desde “Propiedades del sistema -> Opciones avanzadas -> Variables de entorno”, o configurarla con la línea de comandos (PowerShell como administrador):

`1`	`[System.Environment]::SetEnvironmentVariable("OLLAMA_MODELS", "D:\OllamaModels", "Machine")`

3. Reiniciar Ollama (o reiniciar el sistema)

Después de que la variable de entorno entre en vigor, reinicia el servicio o la aplicación de Ollama. Si no estás seguro de si ya se aplicó, reiniciar el equipo es la opción más estable.

4. Verificar que el nuevo directorio esté activo

Después de descargar o hacer pull de cualquier modelo, comprueba si aparecen archivos nuevos bajo D:\OllamaModels.

5. Limpiar el directorio antiguo (después de confirmar)

Cuando confirmes que los modelos funcionan correctamente en el nuevo directorio, elimina el contenido del directorio antiguo para recuperar espacio en la unidad C.

Preguntas frecuentes

Qué hacer si después de configurarlo sigue escribiendo en la unidad C

Confirma que la variable de entorno sea una “variable del sistema”, no una variable temporal de la sesión actual.
Confirma que el proceso de Ollama se haya reiniciado.
Comprueba que el nombre de la variable sea exacto: debe ser OLLAMA_MODELS.

Hay que migrar los archivos de modelos antiguos

Si no quieres volver a descargarlos, puedes detener Ollama, copiar manualmente los modelos antiguos al nuevo directorio y después iniciar Ollama para verificar.

Desinstalar Ollama por completo en Linux (incluida la limpieza de residuos)

Mon, 06 Apr 2026 09:16:29 +0800

Si necesitas eliminar Ollama por completo en Linux, puedes seguir el orden siguiente. Este artículo limpia el servicio, el ejecutable, el directorio de modelos y también el usuario y grupo ollama.

Avisos antes de desinstalar

Los comandos siguientes eliminarán los archivos de modelos locales de Ollama (normalmente en /usr/share/ollama). Confirma antes si necesitas hacer una copia de seguridad.
Los comandos usan sudo por defecto. Asegúrate de que la cuenta actual tenga permisos de administrador.

1. Detener y eliminar el servicio systemd

sudo systemctl stop ollama
sudo systemctl disable ollama
sudo rm -f /etc/systemd/system/ollama.service
sudo systemctl daemon-reload

2. Eliminar el ejecutable de Ollama

OLLAMA_BIN="$(command -v ollama)"
if [ -n "$OLLAMA_BIN" ]; then
  sudo rm -f "$OLLAMA_BIN"
fi

3. Eliminar directorios de bibliotecas relacionados con Ollama (si existen)

Si tu método de instalación escribió archivos de Ollama en directorios lib, puedes limpiarlos así:

1
2
3

for d in /usr/local/lib/ollama /usr/lib/ollama /lib/ollama; do
  [ -d "$d" ] && sudo rm -rf "$d"
done

4. Eliminar el directorio de modelos y datos

`1`	`sudo rm -rf /usr/share/ollama`

5. Eliminar el usuario y grupo del sistema (si existen)

1
2

id -u ollama >/dev/null 2>&1 && sudo userdel ollama
getent group ollama >/dev/null 2>&1 && sudo groupdel ollama

6. Verificar si la desinstalación terminó

1
2

command -v ollama || echo "ollama binary not found"
systemctl status ollama || true

Si las comprobaciones anteriores ya no encuentran ollama, la desinstalación se ha completado.

rsync --delete Limpieza de directorios explicada y práctica

Sun, 29 Mar 2026 11:00:00 +0800

El propósito principal de rsync --delete es eliminar archivos en el directorio de destino que no existen en el directorio de origen, para que ambos lados permanezcan consistentes.

Los casos de uso típicos incluyen:

Limpieza de archivos obsoletos en el lado de destino durante la sincronización
Vaciar rápidamente un directorio de destino sincronizando desde un directorio de origen vacío

Sintaxis básica

`1`	`rsync -a --delete source_dir/ target_dir/`

-a: modo de archivo, conserva permisos, marcas de tiempo y otros atributos
--delete: elimina archivos adicionales en el lado de destino

Nota importante: si source_dir termina con / cambia el comportamiento. Con /, rsync sincroniza el contenido del directorio; sin /, sincroniza el directorio mismo.

Vaciar rápidamente un directorio de destino con un origen vacío

Si su objetivo es mantener la ruta del directorio pero borrar todo el contenido, use un directorio vacío como fuente:

# 1) Create an empty directory
mkdir -p /tmp/empty_dir

# 2) Sync and delete target-side content
rsync -a --delete /tmp/empty_dir/ /path/to/target_dir/

En escenarios de directorios grandes, esto suele ser más eficiente que eliminar archivos uno por uno y es más fácil de automatizar en scripts.

Opciones extendidas comunes

--delete-before: eliminar antes de la transferencia, lo que puede ser más rápido en algunos casos
--progress: muestra el progreso de la transferencia y el procesamiento

Ejemplo (limpieza de un directorio de registro de Nginx):

`1`	`rsync -a --delete --progress /tmp/empty_dir/ /var/log/nginx/`

Recomendaciones

Ejecute primero con --dry-run para verificar el alcance de la eliminación.
Haga una copia de seguridad del directorio de destino antes de ejecutarlo en producción.
Para rutas críticas, programe la ejecución durante las horas de menor actividad.

Cómo Git rastrea el permiso ejecutable de archivos (+x)

Sun, 29 Mar 2026 10:00:00 +0800

En un entorno Linux, Git rastrea el bit ejecutable de un archivo (+x). Si desea que un script se conserve como un archivo ejecutable en el repositorio, debe registrar explícitamente ese cambio de permiso en Git.

Agregar permiso ejecutable a un archivo

1
2
3

git update-index --chmod=+x script.sh
git commit -m "chore: mark script.sh as executable"
git push

Este comando realiza el cambio de bit ejecutable para script.sh. Después de confirmar y enviar, otros usuarios mantendrán el mismo estado de permiso cuando extraigan o clonen el repositorio.

Eliminar el permiso ejecutable de un archivo

1
2
3

git update-index --chmod=-x script.sh
git commit -m "chore: remove executable bit from script.sh"
git push

Verificar el resultado

Utilice los siguientes comandos para verificar los permisos de archivos en su árbol de trabajo:

1
2

git clone xxxxxxxxxxxxxxx
ls -l script.sh

Si ve algo como -rwxr-xr-x, el archivo es ejecutable. Si ve -rw-r--r--, no es ejecutable.

Notas

git update-index --chmod=+x/-x solo actualiza el modo de archivo registrado por Git; no reemplaza los cambios en el contenido del archivo.
En los flujos de trabajo de equipo, es mejor realizar cambios de solo permiso por separado para facilitar la revisión y el seguimiento.