Linux on KnightLi Blog

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.

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.