Documentacion tecnica on KnightLi Blog

Los certificados de Windows Secure Boot expiran en 2026: cómo deben actualizar usuarios y administradores

Wed, 20 May 2026 23:15:08 +0800

Microsoft actualizó su guía sobre la expiración de certificados de Windows Secure Boot y las actualizaciones de CA. El punto clave no es que “el PC dejará de arrancar cuando expire el certificado”. El problema real es que un grupo de certificados Secure Boot emitidos en 2011 empezará a expirar a partir de junio de 2026, y los dispositivos Windows necesitan migrar a los nuevos certificados de 2023 para seguir recibiendo futuras actualizaciones de protección en la fase temprana de arranque.

Artículo original: Microsoft Support: Windows Secure Boot certificate expiration and CA updates.

De qué trata esta actualización

Secure Boot es una función de seguridad del firmware UEFI. Antes de que arranque el sistema operativo, verifica las firmas de cargadores de arranque, controladores UEFI, Option ROM y otros componentes, ayudando a bloquear bootkits, rootkits y otro malware de fase temprana.

Esta validación depende de varias bases de datos y claves almacenadas en el firmware:

KEK: clave de inscripción, usada para autorizar actualizaciones de las bases de datos de Secure Boot.
DB: base de datos de firmas permitidas, que decide qué componentes de arranque pueden ser confiables.
DBX: base de datos de firmas revocadas, usada para bloquear componentes conocidos como no confiables o riesgosos.

Microsoft indica que un grupo de certificados de 2011 usado durante años por dispositivos Windows se acerca a su expiración, y que los certificados correspondientes ya existen en versiones de 2023. Esto incluye el certificado KEK usado para firmar actualizaciones de DB / DBX, la Windows UEFI CA usada para firmar el cargador de arranque de Windows, y la UEFI CA usada para cargadores de arranque de terceros, aplicaciones EFI y Option ROM.

¿Afectará al arranque?

La pregunta que más preocupa a la mayoría de usuarios es: después de que expiren los certificados en 2026, ¿el PC dejará de arrancar de repente?

La respuesta de Microsoft es bastante clara: los dispositivos que no hayan recibido los nuevos certificados de 2023 podrán seguir arrancando y funcionando normalmente, y las actualizaciones estándar de Windows seguirán instalándose. El problema es que esos dispositivos ya no podrán recibir nuevas protecciones relacionadas con la fase temprana de arranque, como actualizaciones de Windows Boot Manager, actualizaciones de la base de datos de Secure Boot, actualizaciones de listas de revocación y mitigaciones para vulnerabilidades de arranque descubiertas más adelante.

Así que se parece más a una cadena de protección de seguridad que envejece que a un problema simple de “el sistema queda obsoleto de inmediato”. A corto plazo, la máquina puede seguir funcionando. A largo plazo, bajará su capacidad de defensa frente a nuevos bootkits, vulnerabilidades de la cadena de arranque y componentes revocados.

Qué deben hacer los usuarios normales

Los usuarios normales no necesitan editar manualmente las claves de Secure Boot, y no deberían borrar, restablecer o importar certificados en BIOS / UEFI sin una instrucción clara.

El enfoque más seguro es:

Mantener Windows Update activado e instalar actualizaciones acumulativas.
Instalar actualizaciones de firmware, BIOS, UEFI y controladores proporcionadas por el fabricante del PC.
No mantener Secure Boot desactivado a largo plazo solo por problemas temporales de compatibilidad.
Si BitLocker está activado, confirmar que la clave de recuperación está disponible antes de cambios relacionados con firmware o Secure Boot.
Usar msinfo32 para revisar “Secure Boot State” y confirmar que Secure Boot está activado.

En PCs domésticos, el riesgo principal normalmente no es “no saber operar”, sino dejar el firmware sin actualizar durante demasiado tiempo. Muchos cambios relacionados con Secure Boot en portátiles y equipos de marca dependen al final del soporte de firmware del OEM.

Qué deben vigilar los administradores de empresa

En entornos empresariales, el problema no está en una sola máquina. Está en la mezcla de modelos de dispositivos, versiones de firmware, políticas de cifrado, herramientas de despliegue y componentes de arranque de terceros.

Conviene empezar por cuatro cosas:

Inventariar modelos de dispositivos, versiones de Windows, estado de Secure Boot, versiones de firmware y estado de BitLocker.
Probar primero en modelos representativos y ampliar el despliegue gradualmente.
Poner actualizaciones de Windows, firmware OEM, copia de claves de recuperación y flujos PXE / MDT / ConfigMgr / Intune dentro de un mismo plan de cambio.
Validar si los medios de recuperación, herramientas de imagen, software de seguridad de terceros y cargadores de arranque de doble sistema siguen arrancando normalmente.

La documentación de Microsoft también ofrece rutas para dispositivos gestionados por IT mediante registro, directivas de grupo, WinCS API, Intune y ejemplos de monitorización. Para empresas, esta actualización de certificados no debería tratarse como un parche común. Debe probarse, desplegarse por fases y acompañarse de un plan de reversión como cambio de nivel firmware.

Doble arranque y herramientas de arranque de terceros requieren más cuidado

Si un dispositivo usa doble arranque con Linux, un cargador de arranque de terceros, aplicaciones EFI con firma personalizada, medios de recuperación antiguos o herramientas de despliegue offline, esta actualización merece validación anticipada.

La razón es que Microsoft ha separado con más detalle partes del modelo de confianza original. Por ejemplo, la confianza para cargadores de arranque de terceros y Option ROM ya no está completamente agrupada. Esto ayuda a reducir el alcance de confianza, pero también significa que componentes de arranque antiguos, versiones sin actualizar de shim / GRUB, medios de recuperación viejos o herramientas de arranque personalizadas podrían encontrar más problemas de confianza de firma en el futuro.

La regla es simple: no esperes a que expiren los certificados para descubrir que tu USB de recuperación tampoco arranca. Las máquinas importantes deberían probar al menos una vez el flujo real de recuperación antes de tiempo.

Qué no conviene hacer

Este tipo de problema parece una “expiración de certificado”, así que es tentador entrar en BIOS y cambiar claves manualmente. Salvo que el fabricante o la documentación de Microsoft lo pidan claramente, no es recomendable.

No dejes Secure Boot desactivado a largo plazo. No borres directamente Secure Boot keys en dispositivos de producción. No copies la configuración de firmware de un dispositivo a otro lote de modelos distintos. Y no actualices solo Windows, ignores el firmware OEM y asumas que todo está resuelto.

Una forma más razonable de verlo es: las actualizaciones de Windows resuelven el lado del sistema operativo, las actualizaciones de firmware OEM resuelven el lado de la plataforma, y la política de despliegue empresarial resuelve la consistencia a escala. Si falta una de las tres, después puede convertirse en un problema de arranque difícil de diagnosticar.

Resumen

El impacto real de la expiración de certificados de Windows Secure Boot no es que todos los PCs dejen de arrancar el mismo día de 2026. El problema real es que los dispositivos con certificados antiguos perderán gradualmente la capacidad de recibir futuras actualizaciones de seguridad de Secure Boot.

Los usuarios individuales deben mantener Windows y firmware actualizados, y evitar desactivar Secure Boot sin necesidad. Los administradores de empresa deberían empezar cuanto antes con inventario, pruebas y despliegue por fases. Cuanto más cerca esté junio de 2026, menos tiempo quedará para compatibilidad de firmware, validación de recuperación y planes de reversión masiva.

Cómo usar Hugo aliases: redirecciones de URL antiguas y guía para corregir 404

Sun, 17 May 2026 20:00:17 +0800

Los aliases de Hugo sirven para crear redirecciones desde URL antiguas de una página.

Cuando cambias la URL de un artículo, fusionas páginas, migras un blog o quieres corregir una URL incorrecta frecuente, puedes añadir aliases en el Front Matter del artículo. Hugo genera páginas de redirección para esas direcciones antiguas y lleva a los visitantes a la página actual, evitando errores 404 innecesarios.

Para qué sirven los aliases

Hay tres escenarios comunes.

El primero es optimizar las URL de artículos.

Por ejemplo, la URL antigua de un artículo podría ser:

`1`	`/posts/tech/2023-01-01-hello/`

Después quizá quieras acortarla a:

/hello/

En ese caso, añade la URL antigua como alias en la nueva página. Los buscadores, referencias externas y enlaces sociales antiguos seguirán llegando al contenido.

El segundo escenario es fusionar o migrar páginas.

Si combinas varios artículos antiguos en uno nuevo, o migras desde Hexo, Typecho, WordPress u otra plataforma a Hugo, la estructura de URL antigua suele ser distinta a la del nuevo sitio. aliases permite apuntar esas direcciones antiguas una por una a las páginas nuevas y reducir los 404 tras la migración.

El tercer escenario es corregir errores de escritura.

Algunas URL pueden haberse escrito mal, o sitios externos pueden haber enlazado a una ruta incorrecta. Si ese enlace incorrecto recibe tráfico, puedes crear un alias específico para guiar a los usuarios a la página correcta.

Sintaxis básica

Solo tienes que añadir el campo aliases en el Front Matter del artículo.

Ejemplo en YAML:

---
title: "Nuevo título del artículo"
date: 2026-05-17T12:00:00+09:00
url: /new-path/my-new-article/
aliases:
  - /old-path/old-article/
  - ../old-version/
---

Aquí /old-path/old-article/ es una ruta relativa al sitio. ../old-version/ es una ruta relativa a la página actual.

En la práctica, suele ser mejor usar rutas relativas al sitio, es decir, rutas que empiezan con /. Son más claras y menos propensas a confusión si cambia la estructura de directorios del artículo.

Relación con el campo url

url define la nueva dirección de la página actual.

aliases define qué direcciones antiguas redirigen a esa nueva dirección.

Por ejemplo:

1
2
3

url: /new-path/my-new-article/
aliases:
  - /old-path/old-article/

Después de compilar el sitio, quien visite /old-path/old-article/ será redirigido a /new-path/my-new-article/.

Si el artículo no define url explícitamente, Hugo genera la dirección de la página actual según la configuración de permalinks, la fecha, el slug y otras reglas del sitio. aliases seguirá apuntando a esa página final generada.

Cómo implementa Hugo las redirecciones por defecto

Por defecto, Hugo genera un archivo HTML independiente para cada alias.

Ese archivo HTML normalmente usa:

`1`	`<meta http-equiv="refresh">`

Esto hace que el navegador redirija automáticamente desde la dirección antigua a la nueva.

Este método es simple, portable y funciona bien en hosting estático común. Pero en esencia es una redirección del lado del navegador, no una redirección 301 / 302 devuelta por el servidor.

Para sitios pequeños, esto suele ser suficiente. Mientras la dirección antigua se abra y termine llegando al nuevo artículo, se evitan problemas visibles de 404.

Cuándo considerar redirecciones del servidor

Si el sitio está desplegado en Netlify, Cloudflare Pages, Vercel u otra plataforma que soporte reglas de redirección, conviene considerar redirecciones del servidor.

Las redirecciones del servidor tienen varias ventajas:

Responden de forma más directa, sin devolver primero una página HTML intermedia.
Permiten usar con más claridad códigos 301 o 302.
Centralizan grandes conjuntos de reglas de migración para revisión y mantenimiento.
Dan más control sobre migraciones SEO.

Un enfoque común es desactivar la generación predeterminada de páginas alias de Hugo y generar en su lugar el archivo de reglas que necesita la plataforma. Netlify suele usar _redirects; Cloudflare Pages puede usar _redirects o reglas propias de la plataforma.

Si eliges esta ruta, revisa disableAliases y los custom output formats de Hugo. No elimines simplemente aliases, porque entonces los enlaces antiguos pasarán a ser 404.

Precauciones al usar aliases

Primero, no uses aliases como excusa para cambiar URL sin cuidado.

Cuando una URL se publica, entra en buscadores, RSS, redes sociales, marcadores y referencias externas. Cambiar URL con frecuencia crea coste de mantenimiento. aliases encaja mejor para reparar problemas históricos que para fomentar cambios constantes de ruta.

Segundo, evita bucles de redirección.

Las direcciones antiguas deben apuntar a la nueva dirección de la página actual. No hagas que A redirija a B y B vuelva a A, ni permitas que varias páginas reclamen el mismo alias.

Tercero, cuidado con los prefijos de idioma en sitios multilingües.

Los sitios multilingües de Hugo suelen manejar rutas de idioma automáticamente. Si escribes un alias dentro de una versión de idioma, a veces no necesitas añadir manualmente prefijos como /en/ o /zh-tw/. Si lo haces, puedes generar rutas duplicadas como /en/en/.... Verifica siempre el resultado de la compilación local.

Cuarto, revisa el directorio generado después del cambio.

Tras añadir un alias, compila el sitio y comprueba si aparece el index.html correspondiente a la ruta antigua dentro de public. También confirma que el destino de la redirección dentro de ese archivo es correcto.

Un flujo práctico de comprobación

Después de editar el Front Matter del artículo:

Confirma la nueva URL del artículo actual.
Añade la URL antigua en aliases.
Ejecuta una compilación de Hugo.
Comprueba si public contiene el index.html de la URL antigua.
Abre el HTML generado y confirma que redirige a la nueva URL.
En páginas multilingües, revisa especialmente que no haya prefijos de idioma duplicados.

Este flujo detecta la mayoría de problemas de rutas antes del despliegue.

Resumen

aliases es la herramienta ligera de Hugo para conservar enlaces antiguos.

Es especialmente útil al cambiar URL de artículos, migrar blogs, fusionar páginas y reparar rutas incorrectas. Los sitios estáticos comunes pueden usar directamente las páginas HTML de redirección generadas por Hugo. Los sitios más grandes, o aquellos con requisitos SEO más estrictos, pueden pasar a reglas de redirección del servidor.

La clave no es solo que las URL nuevas se vean mejor. También hay que cuidar las URL antiguas que ya existen. Un sitio que lleva las URL antiguas de forma estable a las páginas nuevas tiene menos riesgo de perder tráfico histórico durante migraciones y rediseños.

Referencias

Cómo elegir entre FreeRTOS, RT-Thread y Zephyr: diferencias de arquitectura y casos de uso

Sun, 17 May 2026 12:32:06 +0800

FreeRTOS, RT-Thread y Zephyr suelen compararse como si fueran productos del mismo nivel. No lo son.

La pregunta correcta no es cuál es mejor, sino qué necesita tu proyecto: un kernel ligero de planificación, un RTOS con buen soporte para MCU chinos, o un sistema operativo embebido completo y multiplataforma.

En resumen:

FreeRTOS es un kernel RTOS muy extendido, con librerías IoT mantenidas por AWS.
RT-Thread añade un ecosistema de componentes más completo y buen soporte para MCU domésticos.
Zephyr, alojado en Linux Foundation, apuesta por subsistemas unificados, modelo de dispositivos, Devicetree y reutilización de aplicaciones entre fabricantes.

Conclusión rápida

Si solo necesitas tareas, colas, semáforos y temporizadores con poco consumo, FreeRTOS sigue siendo una opción segura.

Si usas muchos MCU chinos y valoras BSP listos, documentación en chino y más componentes, RT-Thread es práctico.

Si necesitas reutilizar código entre chips, placas y proveedores, y aceptas aprender Kconfig, Devicetree, west y el modelo de drivers, Zephyr es la ruta más orientada a ingeniería a largo plazo.

FreeRTOS: pequeño y conocido

FreeRTOS destaca por ser pequeño, familiar y muy usado.

FreeRTOS-Kernel se centra en kernel, ports y mecanismos básicos: scheduling, semáforos, colas, event groups, timers y memoria. En muchos proyectos, eso es exactamente lo que se necesita.

Tras la adquisición por AWS, también existen librerías como coreMQTT, coreHTTP, OTA y Device Shadow, además de versiones LTS.

Su límite es claro: no define un modelo de dispositivos común para GPIO, UART, I2C, pin control o HAL. Eso queda en manos del SDK del fabricante o de la arquitectura del equipo. Es flexible, pero cambiar de chip o placa puede arrastrar código de aplicación.

RT-Thread: componentes y soporte doméstico

RT-Thread está más cerca de un RTOS completo.

Incluye sistema de archivos, red, framework de dispositivos, USB, sensores, paquetes y herramientas. Para equipos chinos o proyectos con AT32, HC32, N32, APM32, HT32, Luat o HPMicro, puede acelerar mucho el arranque.

La limitación es que muchos BSP siguen siendo específicos de placa y dependientes de librerías del fabricante. No ofrece el mismo nivel sistemático de descripción de hardware y portabilidad de aplicación que Zephyr.

Zephyr: una plataforma de ingeniería embebida

Zephyr no es solo “otro RTOS más grande”.

Intenta unificar en un proyecto lo que normalmente queda disperso en SDKs, BSPs, HALs, drivers escritos a mano, scripts de configuración y código de aplicación.

Sus piezas clave son Kconfig, Devicetree, drivers unificados, subsys, west, CMake y abstracciones de Board / SoC / shield. Se parece a una versión MCU de algunas ideas de Linux embebido.

Por qué importa Devicetree

Zephyr procesa DTS y overlays durante la compilación, genera cabeceras como devicetree_generated.h y expone información con macros DT_. Así, gran parte de la selección de hardware queda resuelta en build time, no en runtime.

Esto separa hardware y aplicación, permite cambiar de placa tocando principalmente DTS / overlay, y reduce la necesidad de llenar main.c con detalles de registros, pines y HAL.

Código de aplicación más limpio

En proyectos MCU tradicionales, inicialización, pines, interrupciones, debounce, máquinas de estado y lógica de negocio se mezclan fácilmente.

Zephyr intenta separarlo:

Conexiones de hardware en DTS / overlay.
Opciones en Kconfig / prj.conf.
Drivers en mainline o módulos.
Aplicación centrada en eventos de negocio.

Esto es valioso cuando hay varias placas, varios chips y mantenimiento largo.

Coste de recursos

Zephyr puede usar más Flash que un FreeRTOS mínimo porque incorpora drivers, subsistemas y objetos de dispositivo. Pero esa infraestructura se reutiliza cuando crecen los periféricos y variantes.

Si el proyecto es fijo y pequeño, FreeRTOS puede ser más eficiente. Si el proyecto crece en placas y periféricos, Zephyr puede amortizar mejor esa base.

Cómo elegir

Elige FreeRTOS para hardware fijo, recursos ajustados y necesidades de scheduling simples.

Elige RT-Thread para muchos MCU domésticos, documentación china, BSP disponibles y componentes integrados.

Elige Zephyr para reutilización entre placas, drivers unificados, mantenimiento largo y una arquitectura más cercana al mundo Linux.

Cuándo no usar Zephyr

No conviene adoptar Zephyr si el proyecto es de una sola placa, el equipo no tiene tiempo de aprender Kconfig / Devicetree, el chip no está bien soportado upstream, o el producto ya está estable en producción.

Empieza con una placa bien soportada y prueba LED, UART, GPIO, input e I2C / SPI antes de migrar un producto real.

Resumen

FreeRTOS resuelve scheduling. RT-Thread añade componentes y soporte fuerte para MCU domésticos. Zephyr intenta reorganizar la ingeniería de software MCU alrededor de subsistemas unificados, Devicetree y portabilidad de aplicación.

Para dispositivos pequeños y fijos, FreeRTOS suele bastar. Para líneas de productos con MCU chinos, RT-Thread es práctico. Para productos multiplataforma y de larga vida, Zephyr merece inversión.

Referencias:

Evolución de la arquitectura de los LLM entre 2023 y 2026: tokenizadores, codificación posicional, atención, MoE, normalización y funciones de activación

Sun, 17 May 2026 08:53:29 +0800

Entre 2023 y 2026, la arquitectura de los LLM pareció cambiar en muchas direcciones: los tokenizadores se hicieron más grandes, la codificación posicional se desplazó hacia RoPE, la atención pasó de MHA a GQA, ventanas deslizantes y MLA, MoE volvió a ser una opción dominante, y la normalización y las funciones de activación se movieron hacia combinaciones como RMSNorm y SwiGLU.

Pero la idea principal no es que Transformer haya sido reemplazado. La idea central es que el núcleo Transformer siguió vigente, mientras casi todos sus componentes se optimizaron para contextos más largos, menor coste de inferencia, mayor eficiencia de entrenamiento y mejor capacidad multilingüe.

Primero, la vista general

Un LLM puede dividirse aproximadamente en varias partes:

Tokenizador: convierte texto en tokens que el modelo puede entender.
Codificación posicional: indica al modelo dónde está cada token en la secuencia.
Mecanismo de atención: decide qué contexto debe mirar cada token.
Red feed-forward: aplica transformaciones no lineales más complejas en cada posición.
Normalización: estabiliza el entrenamiento.
Función de activación: da capacidad no lineal a la red.
MoE: divide parte de la red feed-forward en varios expertos y activa solo algunos cada vez.

La evolución de 2023 a 2026 puede entenderse como la optimización sucesiva de estas piezas.

Tokenizadores: de “dividir texto” a “ahorrar tokens”

El tokenizador convierte lenguaje natural en secuencias de tokens. El modelo no ve el texto directamente; ve IDs de tokens.

Los tokenizadores anteriores solían ser más eficientes en inglés y menos eficientes para chino, código y texto multilingüe. Si una misma frase se divide en demasiadas piezas pequeñas, consume más ventana de contexto y aumenta tanto el coste de entrenamiento como el de inferencia.

Una tendencia clara de los últimos años es tener vocabularios más grandes y mejor soporte multilingüe. Llama 3 usa un vocabulario de 128K tokens, y Meta explicó que esto codifica el lenguaje de forma más eficiente y mejora el rendimiento del modelo. Qwen, DeepSeek y otros modelos también prestan mucha atención a la eficiencia de tokens en chino, código y escenarios multilingües.

Para principiantes: cuanto mejor es el tokenizador, menos fragmentado queda el mismo texto y más información útil cabe en la misma longitud de contexto.

Codificación posicional: RoPE se volvió dominante

El lenguaje tiene orden. Las mismas palabras pueden cambiar por completo de significado si se reordenan. La codificación posicional introduce esa información de orden en el modelo.

Los primeros Transformers usaban codificación posicional absoluta, donde la posición 1, la posición 2 y la posición 3 tenían vectores propios. Los LLM posteriores adoptaron con frecuencia RoPE, o Rotary Positional Embedding. RoPE integra la información de posición dentro del cálculo de atención y es más amigable para extender el contexto.

Desde la familia Llama hasta muchos modelos abiertos, RoPE se ha convertido en un estándar de facto. Para soportar contextos más largos, los modelos también pueden ajustar la base frequency de RoPE, aplicar RoPE scaling o combinarlo con atención de ventana deslizante o atención por bloques.

En pocas palabras, RoPE no hace que un modelo sea “mágicamente más inteligente”; ayuda a que el modelo maneje mejor relaciones de posición relativa en textos largos.

Atención: de MHA a GQA, ventanas deslizantes y MLA

La atención es el núcleo de Transformer. Permite que cada token mire los tokens más relevantes del contexto para la tarea actual.

La versión clásica es MHA, o Multi-Head Attention. Tiene múltiples cabezas de atención, cada una aprendiendo una forma distinta de enfocar. El problema es que, a medida que crecen el modelo y el contexto, el KV cache se vuelve costoso y sube el coste de inferencia.

Después de 2023, la principal dirección de optimización de la atención fue reducir el coste de inferencia.

GQA, o Grouped-Query Attention, fue un paso importante. Permite que varias query heads compartan menos key/value heads, reduciendo la presión del KV cache. Meta adoptó explícitamente GQA en Llama 3 para mejorar la eficiencia de inferencia.

Mistral 7B representa otra dirección: atención de ventana deslizante. En lugar de hacer que cada token mire todo el historial, se centra principalmente en una ventana cercana, reduciendo la presión computacional de secuencias largas. Para muchas tareas, el contexto local ya es muy útil.

DeepSeek-V2/V3 llevó esta optimización más lejos con MLA, o Multi-head Latent Attention. Su objetivo es comprimir el KV cache y reducir la presión de memoria durante la inferencia. El informe técnico de DeepSeek-V3 lista MLA y DeepSeekMoE como elementos centrales de su arquitectura.

Estas técnicas pueden resumirse así:

MHA: enfoque clásico, fuerte pero caro.
GQA: reduce mucho el coste de KV cache con poca pérdida de expresividad.
Atención de ventana deslizante: reduce el coste de atención global en contextos largos.
MLA: comprime aún más la caché de atención para una inferencia eficiente.

MoE: muchos parámetros, pero solo algunos se usan cada vez

MoE significa Mixture of Experts.

Un modelo denso activa todos sus parámetros para cada token. MoE coloca muchos expertos dentro del modelo, pero enruta cada token solo a unos pocos. Así, el número total de parámetros puede ser muy grande, mientras que los parámetros activos por paso de inferencia siguen siendo más reducidos.

Mixtral 8x7B, lanzado a finales de 2023, fue un momento importante para que MoE volviera al centro de la conversación. El artículo de Mistral explica que Mixtral 8x7B sigue en gran parte la arquitectura de Mistral 7B, pero reemplaza cada bloque feed-forward por 8 expertos y usa enrutamiento disperso para seleccionar parte de ellos durante el cálculo.

Después, DeepSeek-V3 convirtió MoE en una ruta central. Tiene una cantidad total de parámetros muy grande, pero cada token activa solo una parte, usando DeepSeekMoE para reducir coste de entrenamiento e inferencia. Qwen3 y otras familias también ofrecen variantes densas y MoE, lo que muestra que MoE pasó de ser una técnica de investigación a una opción de ingeniería dominante.

Para principiantes: un modelo denso es como una empresa donde todos asisten a cada reunión. MoE es como dividir la empresa en equipos expertos y llamar solo a los equipos relevantes para cada problema.

MoE también tiene dificultades claras:

El router debe aprender a enviar tokens a expertos adecuados.
La carga debe equilibrarse para que no todos los tokens caigan en pocos expertos.
El entrenamiento y la inferencia distribuidos son más complejos.
Tener muchos parámetros totales no hace automáticamente barato el despliegue.

Normalización: RMSNorm se volvió común

La normalización estabiliza la distribución de valores intermedios dentro de la red neuronal. Al entrenar modelos grandes, valores inestables dificultan la convergencia y pueden volver el entrenamiento menos fiable.

Los primeros Transformers solían usar LayerNorm. Muchos modelos de estilo Llama pasaron después a RMSNorm. RMSNorm es más simple que LayerNorm: no calcula la media y se centra en la escala de raíz cuadrática media. Es más ligero y suficientemente estable en la práctica.

No hace falta memorizar la fórmula. Basta con recordar que RMSNorm es un estabilizador más ligero. No determina por sí solo la capacidad del modelo, pero afecta a la estabilidad, la velocidad y la implementación.

Funciones de activación: de ReLU/GELU a SwiGLU

Las funciones de activación añaden capacidad no lineal a las redes neuronales. Sin ellas, una red profunda se parecería demasiado a una transformación lineal.

Los Transformers anteriores usaban a menudo GELU. En Llama, Mistral, Qwen, DeepSeek y otros LLM modernos, es más común ver SwiGLU o variantes similares de GLU. SwiGLU suele aparecer dentro de la red feed-forward y controla el flujo de información mediante compuertas.

Una analogía sencilla: una función de activación normal es como un interruptor fijo, mientras que SwiGLU se parece más a una válvula aprendible. No solo decide si pasa información; también aprende qué información debe amplificarse.

SwiGLU hace que la capa feed-forward sea algo más compleja, pero en la práctica de modelos grandes se ha vuelto un componente común de alto rendimiento.

Tendencia general de 2023 a 2026

La línea temporal puede resumirse así:

2023: Llama, Mistral 7B, Mixtral y otros modelos abiertos popularizaron combinaciones como RoPE, RMSNorm, SwiGLU, GQA, atención de ventana deslizante y MoE.
2024: Llama 3, Qwen2.5, DeepSeek-V2/V3 y otros ampliaron vocabularios, mejoraron contexto largo, reforzaron la eficiencia de inferencia y pusieron MoE y atención eficiente en el centro.
2025: DeepSeek-V3/R1 hizo que más personas prestaran atención a MLA, DeepSeekMoE, FP8, MTP y a la conexión profunda entre optimización arquitectónica e ingeniería de sistemas.
2026: la tendencia sigue siendo eficiencia y madurez de ingeniería: los modelos densos buscan capacidad general estable, los MoE amplían capacidad y la atención eficiente reduce el coste del contexto largo.

El cambio más importante no fue que una pieza reemplazara a Transformer. Fue entender que sumar parámetros no basta: arquitectura, datos, sistema de entrenamiento y servicio de inferencia deben optimizarse juntos.

Cómo debería aprenderlo un principiante

Si empiezas desde cero, no conviene intentar leer todos los papers de entrada. Un mejor orden sería:

Entender la estructura básica de Transformer: token, embedding, attention y FFN.
Entender por qué RoPE, RMSNorm y SwiGLU se volvieron comunes.
Estudiar GQA y KV cache para comprender por qué la inferencia consume tanta memoria.
Aprender MoE, especialmente la diferencia entre parámetros totales y parámetros activos.
Finalmente, leer informes de modelos como DeepSeek-V3, Mixtral y Llama 3 para ubicar cada componente en modelos reales.

No trates estos términos como conceptos aislados. La mayoría responden a la misma pregunta: cómo hacer modelos más fuertes que todavía puedan entrenarse, desplegarse y servir respuestas con rapidez.

Resumen

La evolución de la arquitectura de LLM entre 2023 y 2026 puede verse como la maduración de ingeniería de Transformer. Los tokenizadores reducen desperdicio de tokens, RoPE representa mejor la posición, GQA, la atención de ventana deslizante y MLA reducen el coste de atención, MoE amplía capacidad controlando la computación activa, y RMSNorm junto con SwiGLU hacen que el entrenamiento y la representación sean más estables y eficientes.

Para principiantes, lo importante no es memorizar términos. Lo importante es captar la línea principal: casi todos los cambios modernos en arquitectura LLM tratan de equilibrar coste, eficiencia, longitud de contexto y escalabilidad.

Referencias:

Ejecutar apps Android en Ubuntu 26.04 LTS: instalación y uso de Waydroid

Sat, 16 May 2026 17:34:59 +0800

En Ubuntu 26.04 LTS, la forma más realista de ejecutar apps Android sigue siendo Waydroid.

Waydroid no es un emulador Android tradicional. Ejecuta un sistema Android basado en LineageOS dentro de un contenedor Linux. Consume menos recursos y se integra mejor con el escritorio, pero depende mucho de Wayland, del kernel, de los controladores gráficos y de la compatibilidad de cada app.

Sirve bien para abrir herramientas Android ocasionales, probar APK o usar apps ligeras. Para juegos pesados, apps bancarias o un uso intensivo de servicios de Google, conviene bajar las expectativas.

Comprueba si encaja

Ubuntu 26.04 LTS se publicó el 23 de abril de 2026. Sus requisitos de escritorio incluyen al menos una CPU de doble núcleo a 2 GHz, 6 GB de RAM y 25 GB de almacenamiento. Waydroid necesita recursos adicionales, así que es recomendable contar con:

8 GB de RAM o más;
al menos 10 GB libres;
una sesión Wayland funcional;
controladores recientes de Intel, AMD o NVIDIA;
tolerancia a problemas de compatibilidad en algunas apps.

La documentación de Waydroid también indica que Ubuntu 22.04 y versiones posteriores necesitan Wayland Session. Ubuntu 26.04 LTS ya va en esa dirección, lo que facilita el uso.

Instalar Waydroid

Instala las dependencias básicas:

`1`	`sudo apt install curl ca-certificates -y`

Añade el repositorio oficial:

`1`	`curl -s https://repo.waydro.id \| sudo bash`

Instala Waydroid:

`1`	`sudo apt install waydroid -y`

Después puedes abrirlo desde el menú de aplicaciones o desde la terminal.

Inicializar Android

En el primer arranque, Waydroid debe inicializar la imagen del sistema Android. La imagen predeterminada suele bastar.

Si no aparece la interfaz gráfica, inicia el contenedor:

`1`	`sudo waydroid container start`

Inicia la sesión de usuario:

`1`	`waydroid session start`

Abre la interfaz completa de Android:

`1`	`waydroid show-full-ui`

Verás una interfaz parecida a una tableta Android. Las apps instaladas se pueden abrir dentro de Waydroid y algunas pueden aparecer en el lanzador de Ubuntu.

Instalar APK

Si ya tienes un APK:

`1`	`waydroid app install app.apk`

Lista las apps instaladas:

`1`	`waydroid app list`

Ejecuta una app por nombre de paquete:

`1`	`waydroid app launch com.example.app`

Esto es útil para F-Droid, herramientas open source, builds de prueba o APK propios. Evita APK de origen desconocido, sobre todo si piden cuenta, pagos, contactos o SMS.

Modo multiventana

Por defecto Waydroid se comporta como una ventana Android completa. Para mostrar apps como ventanas de escritorio separadas:

`1`	`waydroid prop set persist.waydroid.multi_windows true`

Reinicia la sesión:

1
2

waydroid session stop
waydroid session start

La experiencia depende de la app, del entorno de escritorio y de los controladores gráficos.

¿Instalar Google Play?

Waydroid no equivale a un dispositivo Android certificado por Google.

Se puede intentar usar Google Play, Google Play Services y apps dependientes de Google, pero no conviene asumirlo como entorno estable:

Los servicios de Google incluyen certificación de dispositivo y controles de riesgo de cuenta.
Algunas apps revisan SafetyNet, Play Integrity, root, virtualización o huellas del dispositivo.
Apps bancarias, de pago, juegos y streaming fallan con más frecuencia.

Para herramientas normales, es mejor usar F-Droid, APK open source o versiones que no dependan de Google.

Problemas comunes

Si aparece una pantalla negra, confirma que usas Wayland:

`1`	`echo $XDG_SESSION_TYPE`

Deberías ver:

wayland

Si el contenedor no está activo:

`1`	`sudo waydroid container start`

Si la sesión se queda bloqueada:

1
2

waydroid session stop
waydroid session start

Para revisar logs:

`1`	`waydroid log`

En equipos NVIDIA puede haber más problemas de pila gráfica o controladores. Ubuntu 26.04 LTS ha mejorado con Wayland y NVIDIA, pero Waydroid no es una app nativa normal, así que los fallos de renderizado o ventana no son raros.

Diferencias con emuladores y máquinas virtuales

Waydroid se parece más a “Android en un contenedor” que a una VM completa.

Opción	Mejor para	Problema principal
Waydroid	Apps ligeras, pruebas de APK, integración con Linux	Servicios de Google y algunas apps inestables
Android Studio Emulator	Desarrollo y simulación de dispositivos	Alto consumo de recursos
Máquina virtual	Pruebas aisladas y laboratorio	Gráficos y rendimiento más débiles

Recomendación

En Ubuntu 26.04 LTS, usa Waydroid como herramienta complementaria, no como sustituto total de una tableta Android.

Encaja bien para F-Droid, pruebas de APK, uso temporal de una app sin versión Linux y un entorno Android ligero en el escritorio. Encaja mal para banca, pagos, juegos pesados, apps dependientes de Google Play y flujos que requieren notificaciones, segundo plano, ubicación, Bluetooth o cámara de forma fiable.

Si solo quieres abrir apps Android de vez en cuando en Ubuntu, Waydroid es la primera opción a probar. No es perfecto, pero se instala rápido y encaja con la dirección Wayland de Ubuntu 26.04 LTS.

Referencias

Guía de migración de prompts para GPT-5.5: por qué conviene recortar antes de reescribir

Fri, 15 May 2026 01:25:27 +0800

OpenAI actualizó la GPT-5.5 prompting guide en su documentación de API. Lo más valioso de esta guía no es que ofrezca otra plantilla de prompt más larga, sino que recuerda algo importante: al migrar a GPT-5.5, muchos prompts antiguos deberían hacerse más cortos.

Documentación oficial: https://developers.openai.com/api/docs/guides/prompt-guidance

En una frase, la dirección para prompts en GPT-5.5 es: escribir menos proceso y más resultado; apilar menos reglas y definir mejor los criterios de aceptación; usar menos instrucciones de tipo “siempre debe” y explicar cuándo detenerse, cuándo validar y cuándo buscar más evidencia.

Por qué hay que reescribir prompts antiguos

Muchos prompts de producción se construyen por capas. Si el modelo es inestable, se añade una regla. Si falla una llamada a herramientas, se añade una prohibición. Si la salida es demasiado larga, se añade otro párrafo de formato. Con el tiempo, el system prompt se convierte en un manual de operaciones pesado.

Ese estilo podía ser útil con modelos antiguos, porque el modelo necesitaba más restricciones paso a paso para no desviarse. Pero con GPT-5.5, la recomendación de OpenAI es clara: no migres el prompt stack antiguo tal cual.

Especificar demasiado el proceso trae varios efectos secundarios:

Más ruido: el modelo tiene que encontrar las restricciones importantes dentro de muchas reglas viejas.
Espacio de búsqueda más estrecho: el modelo se atreve menos a elegir soluciones más eficientes.
Salida mecánica: parece ejecutar un guion, no resolver un problema.
Reglas antiguas que se contradicen: tanto las tool calls como la respuesta final pueden empeorar.

GPT-5.5 funciona mejor con prompts que describen el estado objetivo, las restricciones, la evidencia disponible y la salida final, en lugar de codificar cada paso.

outcome-first: definir primero qué significa terminado

La documentación oficial insiste en una dirección: GPT-5.5 funciona mejor con prompts outcome-first.

Eso significa que el prompt debería definir primero:

Cuál es el resultado objetivo.
Qué cuenta como éxito.
Qué restricciones no se pueden cruzar.
Qué contexto está disponible.
Qué campos o secciones debe incluir la respuesta final.
Qué hacer cuando falta evidencia.

Un estilo menos recomendable:

`1`	`Primero revisa A, luego revisa B, después compara todos los campos, piensa en todas las excepciones, decide qué herramienta llamar, llama la herramienta y finalmente explica todo el proceso.`

Un estilo más adecuado para GPT-5.5:

Resuelve el problema del usuario. Criterios de éxito:
- Tomar la decisión con base en la política y los datos de cuenta disponibles
- Si la acción está permitida, completarla antes de responder
- La salida final incluye completed_actions, customer_message, blockers
- Si falta evidencia clave, preguntar solo los campos mínimos necesarios

Esto no vuelve el prompt ambiguo. Traslada el control desde el “orden del proceso” hacia el “resultado y los límites”. El modelo puede elegir su ruta de búsqueda, razonamiento y uso de herramientas, pero debe cumplir los criterios de éxito.

Usar menos reglas absolutas y más reglas de decisión

Los prompts antiguos suelen contener muchos ALWAYS, NEVER, must y only. No están prohibidos, pero deberían reservarse para restricciones que realmente no se pueden violar, como reglas de seguridad, campos obligatorios y acciones prohibidas.

Para decisiones como “cuándo buscar”, “cuándo preguntar al usuario”, “cuándo seguir iterando” y “cuándo detenerse”, GPT-5.5 funciona mejor con reglas de decisión.

Por ejemplo, no escribas solo:

`1`	`Siempre busca tres veces primero.`

Mejor:

Empieza con una búsqueda que cubra la pregunta central. Si los primeros resultados ya soportan los hechos clave, deja de buscar y responde. Continúa buscando solo si la evidencia es contradictoria, falta o no basta para sostener la conclusión.

Este estilo da margen de juicio al modelo y también una condición de parada. Para productos que usan web search, retrieval, file search o consultas de base de datos, esto es clave, porque cada tool call adicional añade latencia y coste.

Añadir un retrieval budget

Una clase de regla que vale la pena añadir a prompts de GPT-5.5 es el retrieval budget.

No es un presupuesto de dinero. Es una regla para detener la recuperación de información. Le dice al modelo cuándo la evidencia es suficiente, cuándo debe seguir buscando y cuándo debe reconocer que falta evidencia.

Una formulación práctica:

Para preguntas normales, empieza con una búsqueda amplia usando palabras clave cortas y distintivas. Si los primeros resultados ya soportan la solicitud central, responde con base en esos resultados y no sigas buscando. Añade más retrieval solo si los resultados entran en conflicto, falta un hecho clave o la conclusión no queda soportada.

Este tipo de regla reduce dos problemas frecuentes:

Buscar demasiado poco y responder sin evidencia.
Buscar demasiado y desperdiciar tiempo en un bucle de herramientas.

Más importante aún, la documentación recuerda que no encontrar evidencia no debería convertirse automáticamente en un “no” factual. A veces la conducta correcta es decir que la evidencia es insuficiente o acotar la pregunta y seguir revisando.

No subir reasoning effort demasiado pronto

GPT-5.5 es más eficiente al razonar, así que OpenAI recomienda reevaluar low y medium, en lugar de subir reasoning effort cada vez que la calidad no parezca suficiente.

Un orden más estable:

Primero confirma si el prompt define claramente objetivo, formato de salida y condiciones de parada.
Añade un ciclo de validación, como pruebas, citas, revisión o render checks.
Añade reglas de persistencia y criterios de finalización para el uso de herramientas.
Solo entonces sube reasoning effort si aún hace falta.

En otras palabras, reasoning.effort se parece más a una perilla final de ajuste. No debería sustituir un prompt bien diseñado.

Si la tarea es clasificación corta, extracción de campos, enrutamiento de tickets o conversión de formato, empieza con bajo coste de razonamiento. Si se trata de síntesis de documentos largos, juicio entre fuentes conflictivas, escritura estratégica o investigación compleja, considera medium o más.

text.verbosity controla la salida, no el pensamiento

GPT-5.5 permite controlar muy bien el formato de salida. La documentación oficial recomienda usar text.verbosity junto con los requisitos de salida dentro del prompt.

El valor por defecto de text.verbosity es medium. Si el producto necesita respuestas más cortas y limpias, se puede usar low. Pero eso no significa que todo tenga que ser corto.

Una pauta típica:

Mantener breves las actualizaciones de estado y el resumen final para el usuario.
Seguir exigiendo legibilidad cuando se genera código, configuración o resultados estructurados.
No sacrificar campos completos, citas o caveats necesarios solo por ser “breve”.

Esto es especialmente útil en productos de código. Las respuestas de chat pueden ser más cortas, pero el código generado puede seguir exigiendo nombres legibles, estructura clara y comentarios necesarios.

preamble y phase: hacer visibles las tareas largas

En tareas complejas, GPT-5.5 puede razonar, planificar o preparar tool calls antes de emitir texto visible. En productos con streaming, el usuario nota la espera hasta el primer token.

La recomendación oficial es: para tareas de varios pasos, intensivas en herramientas o de larga duración, deja que el modelo emita primero un preamble breve. No tiene que explicar todo el plan; basta con decir qué hará primero.

Por ejemplo:

`1`	`Primero revisaré los archivos relevantes y la configuración existente, y luego propondré los cambios.`

En workflows largos o intensivos en herramientas con Responses API, también hay que prestar atención al phase del assistant item. Si la aplicación usa previous_response_id, la API conserva automáticamente el estado anterior del assistant. Si la aplicación reproduce manualmente la salida del assistant, debe conservar el valor original de phase.

Convenciones comunes:

phase: "commentary": actualización intermedia de estado.
phase: "final_answer": respuesta final.
No añadir phase a user messages.

Parece un detalle de implementación, pero importa en productos con tool calls, actualizaciones de estado y respuestas finales. Perder phase durante una reproducción manual puede hacer que el modelo confunda progreso intermedio con conclusión final.

Pedir al modelo que revise su propio trabajo

Otro punto muy práctico de la guía GPT-5.5: en tareas verificables, dale al modelo herramientas y reglas de validación.

Para agentes de código, se puede pedir explícitamente:

Ejecutar unit tests relevantes después de modificar.
Ejecutar type check o lint cuando corresponda.
Ejecutar build si el paquete afectado es grande.
Si la validación completa es demasiado cara, hacer al menos el smoke test mínimo.
Si no se puede validar, explicar por qué y cuál es la siguiente mejor comprobación.

Para resultados visuales o páginas, se puede pedir renderizar primero y luego comprobar layout, recortes, espaciado, contenido faltante y consistencia visual.

Para planes de ingeniería, se puede pedir que incluyan relación con requisitos, archivos/API/sistemas afectados, transiciones de estado, comandos de validación, comportamiento ante fallos, privacidad y seguridad, y preguntas abiertas que realmente afectan la implementación.

Estas reglas son mucho más efectivas que “sé cuidadoso”. Convierten “cuidado” en comprobaciones ejecutables.

Un esqueleto de prompt más adecuado para GPT-5.5

La estructura de la documentación de OpenAI puede simplificarse así:

Role:
Qué rol tienes y en qué contexto trabajas.

# Personality
Tono, forma de colaborar, si hace falta calidez o punto de vista.

# Goal
El resultado visible para el usuario.

# Success criteria
Condiciones que deben cumplirse antes de la respuesta final.

# Constraints
Límites de seguridad, negocio, evidencia, permisos, coste y efectos secundarios.

# Output
Estructura, longitud, tono y campos requeridos.

# Stop rules
Cuándo continuar, reintentar, degradar, preguntar o detenerse.

El punto no es que todos los prompts deban tener todos estos títulos. La idea real es que un prompt para tareas complejas debe decirle al modelo destino, límites y entregable, no codificar cada paso.

Orden práctico para migrar prompts antiguos

Si ya tienes prompts antiguos para GPT-4.1, GPT-4o, GPT-5.2 o GPT-5.4, no conviene reescribir todo de una vez.

Un orden más estable:

Cambia primero el modelo, manteniendo fijo el reasoning effort y los parámetros de salida actuales.
Ejecuta evals existentes o ejemplos reales para detectar cambios de comportamiento.
Elimina reglas de proceso claramente obsoletas, repetidas o contradictorias.
Convierte “requisitos de pasos” en “criterios de éxito” y “condiciones de parada”.
Añade retrieval budgets, reglas de cita y comportamiento ante falta de evidencia.
Añade ciclos de validación para tareas con herramientas.
Ajusta reasoning.effort y text.verbosity al final.

Si no tienes evals, al menos prepara un conjunto de tareas típicas: Q&A simple, retrieval complejo, uso de herramientas, salida formateada, rechazo/degradación y finalización de tareas largas. No juzgues la calidad del prompt con un único demo case.

Checklist para migrar prompts antiguos

Al migrar un prompt antiguo, empieza con esta lista. El objetivo no es hacerlo más corto sin más, sino borrar restricciones inútiles y convertir las restricciones importantes en algo verificable.

Elemento	Problema común	Manejo sugerido
Reglas repetidas	La misma instrucción aparece en varias secciones, a veces con redacción distinta	Unirla en una regla clara y dejar solo la versión final
Palabras absolutas	`ALWAYS`, `NEVER`, `must`, `only` aparecen por todas partes	Reservarlas para seguridad, cumplimiento, permisos y campos obligatorios
Sin condición de parada	El modelo debe seguir buscando, analizando o corrigiendo, pero no se dice cuándo parar	Añadir stop rules: evidencia suficiente, validación aprobada, límite de turnos o coste
Sin comando de validación	Solo dice “asegura que sea correcto”, sin pruebas, lint, citas o comprobaciones	Usar checks concretos: tests, type check, build, citas o smoke test
Proceso demasiado detallado	Cada paso está fijado y el modelo solo puede seguir el flujo	Convertirlo en objetivos, criterios de éxito, límites y requisitos de salida
Parches de modelos antiguos	Siguen presentes restricciones escritas para debilidades de modelos antiguos	Borrar primero y decidir con evals si aún hacen falta
Reglas de herramientas vagas	Solo dice “usa herramientas cuando sea necesario”	Definir cuándo llamar, cuándo parar y cómo degradar si falla
Formato de salida inestable	Hay formato, pero no reglas de campos completos	Definir campos obligatorios, opcionales y salida cuando falta evidencia

Si solo puedes hacer una cosa, prioriza “sin condición de parada” y “sin comando de validación”. Son las dos vías más fáciles para convertir GPT-5.5 en un bucle infinito de herramientas, o en un modelo que da respuestas pulidas pero no verificadas.

Ejemplos de prompts GPT-5.5: viejo vs nuevo

Estos no son system prompts completos, sino reescrituras parciales comunes durante una migración.

Ejemplo 1: Q&A con retrieval

Viejo:

`1`	`Antes de responder, debes buscar al menos 3 veces. Debes leer todos los resultados relevantes. Debes dar una explicación completa.`

Nuevo:

Empieza con una búsqueda que cubra la pregunta central. Si los primeros resultados ya soportan los hechos clave, deja de buscar y responde. Si los resultados entran en conflicto o faltan hechos clave, añade otra búsqueda. En la respuesta final, explica la base; si la evidencia es insuficiente, dilo claramente.

La versión nueva cambia “número de búsquedas” por “si la evidencia es suficiente”. Da al modelo una razón para seguir y una razón para detenerse.

Ejemplo 2: cambios de código

Viejo:

`1`	`Modifica el código con cuidado. No rompas la lógica existente. Al terminar, dime qué cambió.`

Nuevo:

Haz el cambio de código mínimo necesario solicitado por el usuario. Criterios de éxito:
- Modifica solo archivos relacionados con la tarea
- Conserva la compatibilidad de la API pública existente salvo que el usuario pida cambiarla explícitamente
- Ejecuta unit tests relevantes después del cambio; si no pueden ejecutarse, explica por qué y cuál es la siguiente mejor validación
- El resumen final incluye cambios, resultado de validación y riesgos restantes

La versión nueva no pide “cuidado” de forma vaga. Lo concreta en alcance de archivos, compatibilidad de API, pruebas y reporte de riesgos.

Ejemplo 3: salida estructurada

Viejo:

`1`	`Devuelve JSON. No devuelvas contenido extra. Los campos deben estar completos.`

Nuevo:

Devuelve JSON estricto sin Markdown. Campos requeridos:
- status: "ok" | "needs_more_info" | "blocked"
- answer: string
- evidence: string[]
- missing_info: string[]
Si la evidencia es insuficiente, usa status "needs_more_info" y no inventes evidence.

La versión nueva no solo pide JSON. También define una ruta válida cuando falta evidencia, para que el modelo no tenga que inventar información para cumplir “campos completos”.

Cómo combinar parámetros

reasoning.effort y text.verbosity no deberían verse de forma aislada. El primero influye en cuánto razonamiento invierte el modelo; el segundo, en cuán detallada es la salida. Un error común es subir reasoning.effort cuando la calidad no alcanza, o endurecer el prompt cuando la salida es larga. Es más estable configurarlos por tipo de tarea.

Escenario	reasoning.effort	text.verbosity	Nota
Extracción de campos, clasificación, conversión corta de formato	`none` o `low`	`low`	Prioriza baja latencia; lo importante es un schema claro
Enrutamiento de soporte, rutas simples de herramientas	`low`	`low` o `medium`	Si las reglas son claras, no hace falta mucho razonamiento
Q&A normal, resumen ligero con retrieval	`low` o `medium`	`medium`	Requiere algo de juicio, pero no conviene poner high por defecto
Síntesis de varios documentos, juicio entre conflictos	`medium`	`medium`	Primero asegura reglas de evidencia y citas; luego considera subir effort
Cambios de código complejos, agents de tareas largas	`medium` o `high`	Respuesta al usuario `low`, salida de código clara	El chat puede ser breve; código y diff deben ser legibles
Estrategia, planes, análisis de riesgos	`medium` o `high`	`medium` o `high`	Necesita explicar tradeoffs, riesgos y supuestos

Para la mayoría de aplicaciones, empieza con low o medium. Sube reasoning.effort solo cuando el prompt ya define criterios de éxito, condiciones de parada y reglas de validación, y aun así el modelo omite restricciones clave.

text.verbosity tampoco mejora siempre al bajar. Low verbosity sirve para actualizaciones de estado, respuestas cortas de soporte y resúmenes de operación. Pero para código, configuración, planes de migración o explicaciones de auditoría, una salida demasiado breve dificulta la revisión.

Qué reglas conviene conservar

Migrar a GPT-5.5 no significa borrar todo el prompt antiguo. Las siguientes reglas suelen conservarse, y conviene escribirlas con más precisión.

Reglas de seguridad: acciones que no se pueden ejecutar, contenido que no se puede generar, casos que requieren rechazo o degradación.
Reglas de cumplimiento: políticas de industria, restricciones regionales, límites de edad, auditoría, aprobaciones.
Reglas de privacidad: manejo de datos personales, redacción de datos sensibles, límites de logging, prohibición de transferir datos.
Campos de salida: respuestas de API, JSON schema, columnas de tabla, estructuras fijas requeridas por componentes frontend.
Límites de negocio: reglas de reembolso, permisos de cuenta, niveles de servicio, alcance contractual, escalado a soporte humano.
Límites de permisos de herramientas: qué herramientas se pueden llamar, cuáles requieren confirmación y cuáles están prohibidas.
Reglas de citas y evidencia: cuándo se requieren fuentes y cómo manejar evidencia conflictiva.

Estas reglas no son lastre viejo. Son contratos del producto. La diferencia es que, durante la migración, deben pasar de eslóganes largos a restricciones ejecutables.

Por ejemplo:

`1`	`No filtres privacidad del usuario.`

Puede convertirse en:

No incluyas números de teléfono completos, documentos de identidad, access tokens, API keys ni IDs internos de usuario en la respuesta final. Si hace falta referenciarlos, muestra solo una versión redactada, como conservar los últimos 4 dígitos del teléfono.

Qué no se debe borrar por error

El mayor peligro al recortar prompts no es borrar texto inútil, sino borrar límites reales del sistema. Lo siguiente no debería eliminarse a la ligera, aunque parezca viejo.

Requisitos de privacidad y tratamiento de datos: especialmente reglas de logs, exportación, transferencia entre sistemas y tool calls de terceros.
Límites de seguridad y permisos: confirmaciones para borrar datos, transferir dinero, enviar correos, cambiar permisos o ejecutar shell commands.
Formato de citas: si el producto depende de citas, notas, listas de fuentes o trazas de auditoría, no lo borres solo porque ocupa espacio.
Límites de tool calls: qué herramientas son solo lectura, cuáles pueden escribir y cuáles requieren confirmación del usuario.
Comportamiento ante fallos: cómo degradar cuando hay timeouts de API, datos faltantes, fallos de retrieval o permisos insuficientes.
Reglas duras de negocio: precios, reembolsos, bloqueos, control de riesgo y revisión de compliance que el modelo no debe improvisar.

Una regla simple: si borrar una regla solo cambia un poco el estilo de salida, puedes considerar borrarla. Si borrarla puede causar exceso de privilegios, filtración, mala operación, promesas falsas o ruptura de auditoría, consérvala y reescríbela con más precisión.

Resumen

El núcleo de la guía de prompting para GPT-5.5 no es “escribir prompts más avanzados”, sino quitar de los prompts antiguos las partes que especifican demasiado el proceso.

Un prompt más adecuado para GPT-5.5 debería:

Priorizar objetivos, no pasos.
Definir criterios de éxito, no pedir de forma vaga “hacerlo bien”.
Incluir condiciones de parada, no búsquedas o tool loops infinitos.
Tener presupuesto de evidencia, no responder sin evidencia ni buscar para siempre.
Incluir reglas de validación, no depender solo de que el modelo sea cuidadoso.
Ajustar parámetros al final, no subir reasoning effort desde el inicio.

Si tu system prompt antiguo ya es largo, el primer paso para migrarlo a GPT-5.5 quizá no sea añadir contenido, sino eliminarlo. Conserva las reglas realmente no negociables y convierte los detalles de proceso en resultados, límites y checks. Eso suele ser más efectivo que seguir acumulando prompts.

Referencias

OpenAI Prompt guidance: https://developers.openai.com/api/docs/guides/prompt-guidance
OpenAI Using GPT-5.5: https://developers.openai.com/api/docs/guides/latest-model

Términos de informática en lenguaje simple: qué significan TTS, STT, API, RAG y Agent

Tue, 12 May 2026 22:15:34 +0800

En informática hay muchos términos que, al escucharlos por primera vez, parecen muy avanzados. Pero cuando se traducen a lenguaje simple, a menudo describen acciones cotidianas.

Por ejemplo, cuando una IA puede hablar, se llama TTS; cuando puede escucharte, se llama STT. Suena como un sistema complejo, pero separado en partes es simplemente “leer texto en voz alta” y “transcribir voz a texto”.

Enlace de referencia: https://www.zhihu.com/question/267978646/answer/2035405228460201515

Este artículo recorre varios términos comunes desde ese ángulo: conservar los términos, pero explicarlos en palabras simples.

TTS y STT: convertir entre texto y voz

TTS significa Text-to-Speech, es decir, convertir texto en voz. Escribes un texto y el sistema lo convierte en audio reproducible. La navegación por voz, la lectura de libros electrónicos, los bots de atención al cliente y los asistentes de voz usan esta capacidad.

STT significa Speech-to-Text, es decir, convertir voz en texto. Cuando le hablas al móvil, el sistema primero reconoce la voz como texto y luego entrega ese texto al programa siguiente. Dictado por voz, transcripción de reuniones, subtítulos automáticos y altavoces inteligentes dependen de STT.

Muchos productos de IA por voz funcionan así:

STT: convierte lo que dijiste en texto.
LLM: genera una respuesta a partir del texto.
TTS: lee la respuesta en voz alta.

Por eso parece una conversación natural, aunque por debajo varios módulos se pasan el trabajo.

OCR: copiar texto desde imágenes

OCR significa Optical Character Recognition.

En lenguaje simple, consiste en sacar texto de una imagen. Fotografiar una factura, escanear una página de un libro o leer el nombre y número de un documento de identidad son tareas de OCR.

Antes, OCR se parecía más a “adivinar la forma de los caracteres”. Hoy usa deep learning y tolera mejor fondos complejos, texto inclinado, escritura manual e imágenes borrosas. Pero la pregunta central sigue siendo directa: ¿qué texto hay en la imagen?

NLP y LLM: hacer que las máquinas procesen lenguaje humano

NLP significa Natural Language Processing. Trata con lenguaje humano: tokenización, traducción, resumen, análisis de sentimiento, preguntas y respuestas, clasificación.

LLM significa Large Language Model. Puede entender y generar texto, así que hoy muchas tareas de NLP las realizan LLMs.

Versión simple:

NLP: hacer que las máquinas procesen lo que las personas dicen y escriben.
LLM: un modelo de texto grande capaz de manejar muchas tareas de lenguaje.

Cuando pides a una IA resumir un artículo, escribir un correo, mejorar un título o explicar código, estás en este campo general.

API y SDK: una es una interfaz, el otro es un kit

API significa Application Programming Interface.

En lenguaje simple, alguien abre una entrada para que puedas llamar una capacidad. Una API del clima recibe una ciudad y devuelve el tiempo; una API de pagos recibe un pedido y devuelve el resultado del pago.

SDK significa Software Development Kit.

En lenguaje simple, el equipo oficial empaqueta código común, tipos, ejemplos y herramientas para que llames la API más fácilmente. Una API es como el mostrador de un restaurante; un SDK es como una app para pedir. Puedes hablar directamente con el mostrador o usar la app para hacerlo con menos fricción.

CRUD: crear, leer, actualizar y borrar

CRUD significa Create, Read, Update, Delete.

En lenguaje simple: añadir, ver, modificar y eliminar.

Muchos sistemas administrativos, paneles de gestión y operaciones de base de datos giran alrededor de CRUD. Gestión de usuarios, artículos, pedidos o inventario parecen negocios distintos, pero por debajo suelen ser formularios más crear/leer/actualizar/borrar.

Por eso los programadores dicen “otra vez CRUD”. No necesariamente lo dicen con desprecio; simplemente aparece en todas partes.

Cache: guardar una copia para no recalcular cada vez

Cache significa caché.

En lenguaje simple, dejar cerca lo que se usa con frecuencia para tomarlo directamente la próxima vez, sin buscarlo, calcularlo o pedirlo de nuevo.

Una página web puede cachear imágenes y scripts; una consulta lenta puede guardar resultados populares en Redis; una inferencia cara de modelo puede cachear respuestas a preguntas repetidas.

La parte difícil de la caché no es “guardar una copia”, sino “saber cuándo actualizarla”. Si los datos cambian y la caché no, aparece información antigua. Ese es el origen de muchos problemas de caché.

Queue: poner tareas en fila y procesarlas poco a poco

Queue significa cola.

En lenguaje simple: hay demasiadas cosas por hacer, así que se ponen en fila y se procesan una por una.

Por ejemplo, cuando un usuario sube un video, la transcodificación no siempre termina de inmediato. El sistema puede poner la tarea en una cola y dejar que un servicio en segundo plano la procese. Enviar SMS, correos, generar informes y manejar callbacks de pedidos también suele usar colas.

Las colas evitan que todas las tareas lentas bloqueen la petición actual. El usuario recibe respuesta primero y el trabajo pesado ocurre después.

Index: una tabla de contenidos para la base de datos

Index significa índice.

Un índice de base de datos es como el índice de un libro. Sin índice, quizá tengas que leer desde la primera página hasta la última; con índice, llegas más rápido al contenido.

Pero no siempre conviene tener más índices. Las consultas pueden ser más rápidas, pero las escrituras y actualizaciones pueden volverse más lentas, porque el índice también debe mantenerse cuando cambian los datos.

Por eso en optimización de bases de datos se suele mirar primero el índice de una consulta lenta. Pero al crear uno hay que considerar condiciones de búsqueda, campos de orden, volumen de datos y frecuencia de escritura.

RPC, REST y Webhook: cómo hablan los sistemas

RPC significa Remote Procedure Call.

En lenguaje simple, es llamar una función que vive en otra máquina como si fuera una función local.

REST es común en Web API. Usa URLs y métodos HTTP para expresar operaciones sobre recursos, por ejemplo GET /users para consultar usuarios y POST /orders para crear pedidos.

Webhook es una notificación en sentido contrario. En vez de preguntar todo el tiempo “¿ya está?”, el otro sistema llama tu URL cuando ocurre algo.

Forma simple de recordarlo:

RPC: llamar una función remota.
REST: gestionar recursos con HTTP.
Webhook: recibir aviso cuando algo sucede.

CDN y Load Balancing: acercar contenido y repartir carga

CDN significa Content Delivery Network.

En lenguaje simple, colocar recursos estáticos en nodos más cercanos al usuario. Al acceder a imágenes, videos, CSS o JS, no siempre hace falta ir al servidor de origen.

Load Balancing significa balanceo de carga.

En lenguaje simple, si hay demasiado tráfico, no obligar a un solo servidor a cargar con todo; repartir las peticiones entre varias máquinas.

Uno trata de estar más cerca del usuario; el otro evita agotar una máquina. Los sitios grandes suelen usar ambos.

Docker, Container y Kubernetes: empaquetar, ejecutar y orquestar

Docker es una herramienta común de contenedores, y Container significa contenedor.

En lenguaje simple, empaquetar el programa junto con el entorno que necesita para que pueda ejecutarse de forma similar en otra máquina. Así se reduce el problema de “en mi ordenador funciona, en el servidor no”.

Kubernetes, a menudo escrito K8s, es un sistema de orquestación de contenedores.

En lenguaje simple, cuando hay muchos contenedores, decide dónde corren, cómo reiniciarlos si fallan, cómo repartir tráfico y cómo actualizar versiones.

Si solo tienes un servicio pequeño, Docker puede bastar. Si tienes muchos servicios, máquinas y réplicas, K8s empieza a tener más sentido.

CI/CD: construir y desplegar automáticamente

CI significa Continuous Integration.

En lenguaje simple, cuando se envía código, el sistema lo descarga, ejecuta pruebas y lo construye automáticamente para detectar problemas pronto.

CD puede significar Continuous Delivery o Continuous Deployment.

En lenguaje simple, cuando la build pasa, el código se envía de forma más estable y automática a pruebas o producción.

No resuelve “cómo escribir código”, sino “cómo publicar lo escrito con menos errores”.

Serialization: empaquetar objetos en un formato transmisible

Serialization significa serialización.

En lenguaje simple, convertir objetos del programa en un formato que se pueda guardar o transmitir, como JSON, XML o Protobuf.

Lo contrario, Deserialization, convierte esos formatos de vuelta en objetos que el programa puede usar.

Cuando frontend y backend intercambian JSON, o dos servicios usan Protobuf, hay serialización de por medio.

Token, Embedding y Vector DB: convertir texto en formas que el modelo puede procesar

En modelos grandes, Token suele ser la unidad básica en la que se divide el texto. No siempre equivale a un carácter chino o a una palabra inglesa; es más bien la granularidad interna con la que el modelo procesa texto.

Embedding significa vector de incrustación.

En lenguaje simple, convierte texto, imágenes u otros contenidos en una secuencia de números para que el modelo pueda comparar similitudes.

Vector DB significa base de datos vectorial.

En lenguaje simple, guarda esos vectores y permite encontrar rápido contenido con significado parecido.

Por ejemplo, si preguntas “cómo resetear el router”, el sistema puede buscar en la base vectorial contenidos como “restaurar configuración de fábrica”, “olvidé la contraseña Wi-Fi” o “fallo al entrar al panel”, y pasarlos al modelo como referencia.

RAG: buscar primero, responder después

RAG significa Retrieval-Augmented Generation.

En lenguaje simple, antes de responder, el modelo busca información relevante en una base de conocimiento y luego responde usando esos materiales.

Esto reduce el problema de que los modelos grandes inventen cosas desde la memoria. Al conectar documentos internos, bases de conocimiento, manuales de producto o fragmentos de código, el modelo puede usar materiales actuales proporcionados por ti.

Un flujo típico es:

El usuario hace una pregunta.
El sistema convierte la pregunta en un Embedding.
Busca documentos relacionados en una Vector DB.
Envía fragmentos de documentos y la pregunta a un LLM.
El modelo genera la respuesta.

Así que RAG suena avanzado, pero en esencia es: primero consulta materiales, luego organiza la respuesta.

Agent: un flujo automatizado que descompone tareas

En el contexto de IA, Agent suele traducirse como agente inteligente.

En lenguaje simple, no solo responde una frase; puede dividir un objetivo en pasos, llamar herramientas, observar resultados y decidir la siguiente acción.

Por ejemplo, si le pides “analiza por qué fallan las pruebas en este repositorio”, un modelo de chat común quizá solo dé consejos. Un Agent puede leer archivos, ejecutar pruebas, revisar errores, modificar código y volver a ejecutar pruebas.

Por supuesto, Agent no significa fiabilidad garantizada. Es básicamente “modelo + llamadas a herramientas + bucle de estado”. Que funcione bien depende de permisos, límites de la tarea, manejo de errores y confirmación humana.

Resumen

Muchos términos informáticos parecen avanzados porque vienen envueltos en siglas, diagramas de arquitectura y marketing de producto. Al desmontarlos, muchos describen acciones muy simples:

TTS: leer texto en voz alta.
STT: transcribir voz.
OCR: copiar texto desde imágenes.
API: abrir una entrada de llamada.
SDK: empaquetar herramientas de llamada.
CRUD: crear, leer, actualizar y borrar.
Cache: guardar una copia de resultados comunes.
Queue: poner tareas en fila para procesarlas después.
Index: poner una tabla de contenidos a los datos.
CDN: acercar contenido al usuario.
Load Balancing: repartir peticiones.
Docker: empaquetar el entorno de ejecución.
CI/CD: automatizar pruebas y despliegue.
Embedding: convertir contenido en vectores numéricos.
RAG: buscar primero, responder después.
Agent: dejar que el modelo use herramientas paso a paso.

Conviene conservar los términos porque ayudan a buscar, comunicarse y leer documentación. Pero no hace falta dejarse intimidar. Primero tradúcelos a lenguaje simple; luego vuelve a los detalles técnicos. Muchos conceptos se vuelven mucho más claros.

Referencia

Respuesta de Zhihu: https://www.zhihu.com/question/267978646/answer/2035405228460201515

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:

Despliegue privado local de DeepSeek V4: elegir entre chips nacionales y clusters de GPU de consumo

Fri, 08 May 2026 09:39:35 +0800

Tras el lanzamiento de DeepSeek V4, muchas empresas empezaron a hacerse una pregunta: ¿se puede evitar una API externa y desplegar el modelo en un centro de datos propio, una nube privada o un cluster dedicado?

La necesidad es muy real. Finanzas, sanidad, gobierno, fabricacion, legal y equipos de I+D a menudo no pueden enviar documentos internos, codigo, contratos, tickets o datos de clientes directamente a modelos de nube publica. En estos escenarios, el atractivo de DeepSeek V4 no esta solo en la capacidad del modelo, sino en que ofrece a las empresas una opcion mas cercana a una infraestructura LLM controlable.

Sin embargo, desplegar DeepSeek V4 localmente no es tan simple como descargar el modelo y buscar unas cuantas GPU. Especialmente en modelos MoE muy grandes como Pro, el numero total de parametros, parametros activos, longitud de contexto, KV cache, concurrencia y framework de inferencia determinan directamente el coste de hardware. Lo que una empresa debe hacer no es perseguir a ciegas la version completa, sino confirmar primero que forma de despliegue necesita el negocio.

Aclarar primero el objetivo del despliegue

El despliegue privado local en empresas suele tener tres objetivos:

Que los datos no salgan del dominio: documentos internos, codigo, materiales de clientes, logs y bases de conocimiento no abandonan el entorno empresarial.
Estabilidad y control: servicios de modelo, permisos, auditoria, logs y ritmo de actualizaciones quedan bajo control de la empresa.
Reducir coste a largo plazo: con llamadas frecuentes, la inferencia local puede ser mas controlable que comprar API externas durante mucho tiempo.

Si solo unos pocos empleados preguntan de vez en cuando, el despliegue local no siempre compensa. La privatizacion encaja mejor con escenarios frecuentes, estables, sensibles en datos y con flujos claros, por ejemplo:

Preguntas sobre una base de conocimiento interna.
Revision de codigo y asistentes de desarrollo.
Resumen de tickets de atencion al cliente.
Analisis de contratos, historias clinicas e informes.
Asistentes para consultas de bases de datos.
Automatizacion de flujos con Agent.

Estos escenarios comparten rasgos: datos sensibles, llamadas estables y posibilidad de incorporarse a la gobernanza empresarial mediante permisos y logs.

No perseguir Pro completo desde el primer dia

Las versiones comunes de DeepSeek V4 incluyen Pro y Flash. Segun materiales publicos, Pro se orienta a razonamiento mas fuerte y tareas Agent complejas, mientras Flash enfatiza coste y velocidad de respuesta. Al elegir, una empresa no deberia asumir que todo el negocio necesita Pro.

Puedes dividir por complejidad de tarea:

Preguntas simples, resumen, clasificacion y generacion de etiquetas: priorizar Flash o modelos mas pequenos.
RAG para bases de conocimiento internas: Flash cubre muchos escenarios; RAG, permisos y calidad de recuperacion importan mas.
Code Agents, razonamiento complejo y analisis de contexto largo: entonces evaluar Pro.
Tareas de alto valor y baja frecuencia: se puede usar Pro, pero no necesariamente con alta concurrencia.
Asistentes de oficina comunes: no hace falta ocupar durante mucho tiempo los recursos de inferencia mas caros.

La ventaja de los modelos MoE es que cada inferencia solo activa una parte de los parametros, pero eso no significa que la presion de hardware sea pequena. Almacenamiento de pesos, paralelismo de expertos, comunicacion de red, cache de contexto y planificacion concurrente siguen siendo pesados. Especialmente con contexto de nivel 1M token, lo que consume recursos no suele ser una respuesta aislada, sino el contexto largo, la concurrencia multiusuario y las sesiones persistentes.

Ruta de chips nacionales: adecuada para nube privada empresarial

Si una empresa ya tiene un pool de computo nacional, o requisitos de Xinchuang, cumplimiento o control de cadena de suministro, puede evaluar primero chips nacionales como Ascend y Cambricon.

Las ventajas de esta ruta son:

Encaja mejor con requisitos de localizacion y control de cadena de suministro.
Es adecuada para centros de datos empresariales, nubes dedicadas y proyectos de gobierno/empresa.
Facilita unificar permisos, auditoria, aislamiento de recursos y operaciones.
Es mas amable para servicios estables a largo plazo.

Pero la ruta de chips nacionales tambien requiere mirar tres problemas reales.

Primero, adaptacion del framework. Que el modelo pueda ejecutarse no depende solo de la potencia del chip, sino de si el framework de inferencia, operadores, bibliotecas de comunicacion, formatos de cuantizacion, paralelismo de expertos MoE y optimizacion de contexto largo estan maduros.

Segundo, experiencia de ingenieria. La empresa necesita mas que “arranco correctamente”; necesita servicio estable: multiinquilino, limitacion de tasa, monitorizacion, recuperacion ante fallos, despliegues grises, auditoria de logs y aislamiento de permisos.

Tercero, diferencias de ecosistema. El mismo modelo no tendra exactamente el mismo rendimiento, precision, soporte de cuantizacion y herramientas de despliegue en NVIDIA, Ascend, Cambricon u otras plataformas. Antes de producción hay que hacer pruebas de carga reales, no mirar solo la potencia nominal.

Por tanto, los chips nacionales encajan mejor con empresas de presupuesto claro, requisitos altos de cumplimiento y voluntad de invertir en ingenieria de plataforma. No es la ruta mas facil, pero puede ser la que mejor encaje con la gobernanza a largo plazo.

Clusters de GPU de consumo: adecuados para pilotos y equipos pequenos

Si el objetivo es validar primero el valor de negocio, un cluster de GPU de consumo es mas facil para empezar. GPU como RTX 4090, RTX 5090, RTX 3090 y RTX 3060 12GB tienen mas herramientas comunitarias, modelos cuantizados y referencias de inferencia local, por lo que el coste de prueba y error es menor.

La ruta de GPU de consumo encaja con:

Pilotos internos de equipos de I+D.
Preguntas sobre bases de conocimiento en pymes.
Asistentes de codigo de baja concurrencia.
Procesamiento offline de documentos.
Herramientas internas sin requisitos estrictos de SLA.

Pero tambien tiene limites claros:

La VRAM es pequena y cuesta alojar directamente un modelo grande completo.
La comunicacion multi-GPU es debil, y la comunicacion entre maquinas es mas complicada.
La estabilidad a plena carga durante largo tiempo es peor que en soluciones de servidor.
Chasis, alimentacion, refrigeracion, drivers y operaciones se convierten en costes ocultos.
No conviene prometer alta disponibilidad empresarial desde el principio.

Un enfoque mas realista es ejecutar primero Flash, versiones destiladas, versiones cuantizadas o modelos pequenos en GPU de consumo, hacer funcionar el flujo de negocio y decidir despues si migrar a GPU de servidor o a una plataforma de computo nacional tras validar volumen de llamadas, efecto y gobernanza de datos.

Posible arquitectura de despliegue

Una arquitectura privada empresarial relativamente estable puede dividirse en seis capas:

Capa de modelo: DeepSeek V4 Pro, V4 Flash o modelos destilados mas pequenos segun la tarea.
Capa de inferencia: SGLang, vLLM, llama.cpp, stacks de inferencia NPU de fabricantes o servicios propios.
Capa de gateway: autenticacion unificada, limitacion de tasa, auditoria, enrutamiento de modelos y logs de llamadas.
Capa de conocimiento: base vectorial, busqueda de texto completo, analisis de documentos, filtrado por permisos y RAG.
Capa de aplicacion: atencion al cliente, asistentes de codigo, analisis de documentos, preguntas sobre informes y flujos Agent.
Capa de operaciones: monitorizacion, alertas, estadisticas de coste, despliegues grises, rollback y auditoria de seguridad.

Las capas que mas se subestiman son el gateway y la capa de conocimiento. Muchos proyectos fallan no porque el modelo sea inutilizable, sino porque permisos, recuperacion, logs, gestion de contexto, plantillas de prompt y flujos de negocio no estan bien hechos.

Al desplegar LLM dentro de una empresa, el modelo debe tratarse como una capacidad de infraestructura, no como una pagina de chat aislada. El valor real aparece cuando el modelo entra en los flujos y puede procesar de forma estable los datos y tareas propios de la empresa.

Criterios para elegir hardware

El hardware no debe evaluarse solo por “si puede correr”, sino tambien por “si puede prestar servicio de forma estable”.

Puedes elegir por etapas:

Etapa de validacion

El objetivo es demostrar si merece la pena hacer el negocio.

Usar 1-4 GPU de consumo.
Priorizar Flash, modelos pequenos, modelos destilados o modelos cuantizados.
Mantener baja la concurrencia y centrarse en la tasa de finalizacion de tareas.
No prometer alta disponibilidad.

En esta etapa no conviene comprar hardware a gran escala demasiado pronto. Primero confirma si los empleados realmente lo usan, si el negocio ahorra tiempo y si las respuestas pueden entrar en el flujo.

Etapa piloto

El objetivo es que un departamento o una linea de negocio lo use de forma estable.

Usar 4-16 GPU o un conjunto de nodos NPU nacionales.
Agregar gateway unificado, logs y control de permisos.
Construir RAG, analisis de documentos, enrutamiento de modelos y cache.
Empezar a medir tokens, concurrencia, latencia y tasa de fallos.

En esta etapa hay que empezar a cuidar operaciones. El efecto del modelo es solo una parte; estabilidad, coste y gobernanza de datos son igual de importantes.

Etapa de produccion

El objetivo es entrar en servicio empresarial.

Usar GPU de servidor, clusters de computo nacional o pools de recursos de nube privada.
Establecer multiples replicas, limitacion de tasa, failover y planificacion de capacidad.
Enrutar modelos por tarea: tareas simples a modelos ligeros, tareas complejas a Pro.
Conectar con sistemas de identidad, auditoria y politicas de seguridad de la empresa.

En produccion no se recomienda enviar todas las solicitudes al modelo mas fuerte. Un enrutamiento razonable suele ahorrar mas dinero que acumular hardware.

Como elegir framework de inferencia

Modelos como DeepSeek V4 exigen mucho al framework de inferencia. Cuando intervienen MoE, contexto largo, atencion dispersa, cuantizacion y paralelismo multi-GPU, la madurez del framework afecta directamente velocidad y estabilidad.

Las opciones comunes pueden entenderse asi:

SGLang: adecuado para equipos que buscan inferencia de alto rendimiento, Agent, llamadas multi-turno a herramientas y orquestacion de servicios complejos.
vLLM: ecosistema maduro, adecuado para servicios LLM generales, pero el soporte concreto depende de la version y del progreso de adaptacion del modelo.
llama.cpp: mas adecuado para modelos pequenos, modelos cuantizados y despliegue en edge; no para alojar directamente un MoE enorme completo.
Stacks de inferencia NPU nacionales: adecuados para Xinchuang y entornos de computo nacional, pero hay que verificar operadores, cuantizacion y contexto largo.

No elijas framework solo por benchmark. Una empresa deberia probar sus entradas reales: longitud de documentos internos, concurrencia, longitud media de salida, tasa de acierto de RAG, numero de llamadas a herramientas de Agent y reintentos tras fallos.

La seguridad de datos debe hacerse fuera del modelo

El despliegue privado no significa seguridad automatica. Ejecutar el modelo localmente solo resuelve una parte de si los datos salen de la empresa.

Tambien hay que completar:

Cuentas y permisos: cada departamento solo puede acceder a su propia base de conocimiento.
Auditoria de logs: quien pregunto que, que modelo se llamo y que documentos se consultaron.
Enmascaramiento de datos: informacion de clientes, numeros de documento, telefonos, importes de contrato y otros campos sensibles deben tratarse.
Seguridad de prompts: evitar que usuarios eludan permisos o filtren prompts de sistema mediante prompts.
Revision de salidas: en escenarios importantes debe haber revision humana o por reglas.
Ciclo de vida de datos: documentos subidos, indices vectoriales, cache y registros de sesion deben poder eliminarse.

Para construir LLM locales, la empresa no puede involucrar solo al equipo de algoritmos. Seguridad, legal, operaciones y responsables de negocio tambien deben participar; si no, los riesgos se concentraran tras el lanzamiento.

El coste no son solo las GPU

El coste del despliegue local suele subestimarse. Ademas de GPU o NPU, hay que contar:

Servidores, racks, alimentacion, refrigeracion y red.
Almacenamiento y copias.
Adaptacion de framework de inferencia y desarrollo de ingenieria.
Monitorizacion operativa y gestion de incidentes.
Actualizacion de modelos, rollback y pruebas de compatibilidad.
Auditoria de seguridad y sistemas de permisos.
Prompts, RAG y flujos de trabajo del lado del negocio.

Si el volumen de llamadas es bajo, una API externa puede ser mas barata. Si el volumen es alto, los datos son sensibles y el flujo es estable, el despliegue local amortiza mejor el coste.

Una estrategia mas razonable es el despliegue hibrido:

Datos muy sensibles usan modelos locales.
Tareas generales de baja sensibilidad pueden usar API externas.
Tareas simples usan modelos pequenos.
Tareas complejas usan DeepSeek V4 Pro.
Tareas frecuentes priorizan optimizar cache, recuperacion y enrutamiento de modelos.

Ruta recomendada de implantacion

Una empresa puede avanzar en este orden:

Elegir primero 2-3 escenarios de alto valor, sin desplegar en toda la empresa.
Usar GPU de consumo o computo a pequena escala para un PoC.
Ejecutar primero Flash, modelos destilados o modelos cuantizados, conectando RAG y permisos.
Introducir Pro para comparar en tareas complejas.
Registrar volumen real de llamadas, latencia, tasa de fallos y tiempo humano ahorrado.
Despues decidir si comprar clusters de chips nacionales o GPU de servidor.
Antes de produccion, completar gateway, auditoria, monitorizacion, limitacion de tasa y rollback.

Esta ruta es mas estable que comprar un gran cluster desde el principio. El mayor riesgo para una empresa no es que el modelo no sea lo bastante fuerte, sino gastar mucho dinero y descubrir despues que el flujo de negocio no puede absorber esa capacidad.

Resumen

DeepSeek V4 abre mas imaginacion para el despliegue privado local en empresas, pero no es simplemente un “ChatGPT local”. La dificultad real esta en la ingenieria: hardware, frameworks, enrutamiento de modelos, permisos, RAG, auditoria, monitorizacion y control de costes deben considerarse juntos.

La ruta de chips nacionales encaja mejor con empresas de alto cumplimiento y planes de nube privada a largo plazo. Los clusters de GPU de consumo encajan mejor con pilotos y validacion rapida en equipos pequenos y medianos. Pro sirve para razonamiento complejo y Agent; Flash o modelos pequenos son mejores para muchas tareas comunes.

Si solo recuerdas una frase: el despliegue privado de DeepSeek V4 no debe empezar por comprar hardware, sino por escenarios de negocio, limites de datos y volumen de llamadas. Primero haz funcionar el escenario; despues decide si usar un modelo grande, que tamano debe tener y sobre que computo desplegarlo.

Referencias

Modelos LLM locales recomendados para una GPU RTX 3060

Fri, 08 May 2026 09:25:24 +0800

La versión más común de la RTX 3060 tiene 12GB de VRAM. No es una GPU de IA de gama alta, pero funciona muy bien para LLM locales, especialmente modelos de 7B, 8B, 9B y 12B.

Si solo quieres una regla rápida:

En una RTX 3060 12GB, prioriza modelos de alrededor de 8B en cuantización Q4_K_M o Q5_K_M. Elige Q4 para más estabilidad y prueba Q5 si quieres mejor calidad.

No empieces persiguiendo modelos de 32B o 70B. Aunque puedan ejecutarse con cuantización muy baja y CPU offload, la velocidad y la experiencia normalmente no son adecuadas para uso diario.

Primero mira el límite de VRAM

Al ejecutar LLM locales en una RTX 3060 12GB, el límite real es la VRAM.

Tamaño del modelo	Cuantización recomendada	Experiencia en RTX 3060 12GB
3B / 4B	Q4, Q5, Q8	Muy fácil, rápido
7B / 8B / 9B	Q4_K_M, Q5_K_M	Lo más recomendado; buen equilibrio
12B / 14B	Q4_K_M	Se puede probar, cuidado con contexto grande
30B+	Q2 / Q3 o offload parcial	Se puede experimentar, no diario
70B+	Cuantización extrema o mucha CPU/RAM	Más bien experimental

Un LLM local no solo consume VRAM por el archivo del modelo. También consumen contexto, KV cache, batch size, framework de inferencia y drivers.

Por eso 12GB de VRAM no significa cargar sin más un archivo de modelo de 12GB. Es mejor dejar margen para el sistema y el contexto.

Recomendación 1: Qwen3 8B

Si usas principalmente chino, Qwen3 8B es uno de los primeros modelos que vale la pena probar en una RTX 3060.

Sirve para:

Preguntas y respuestas en chino.
Resumen y reescritura.
Asistente diario de conocimiento.
Explicación simple de código.
RAG local.
Flujos Agent ligeros.

Elección recomendada:

1
2
3

Qwen3 8B GGUF
Q4_K_M: primera opción
Q5_K_M: mejor calidad, más presión de VRAM

La familia Qwen suele funcionar bien con chino. Para escritura diaria, organización de información y comprensión de instrucciones en chino, Qwen3 8B es un buen punto de partida.

Recomendación 2: Llama 3.1 8B Instruct

Llama 3.1 8B Instruct es un modelo general estable, con buena capacidad en inglés y ecosistema maduro.

Sirve para:

Preguntas en inglés.
Ayuda ligera con código.
Chat general.
Resumen de documentos.
Pruebas de prompts.
Comparar herramientas de inferencia.

Elección recomendada:

1
2
3

Llama 3.1 8B Instruct GGUF
Q4_K_M: mejor velocidad y estabilidad de VRAM
Q5_K_M: mejor calidad de respuesta

Si procesas sobre todo material en inglés, o quieres un modelo con muchos tutoriales y buena compatibilidad, Llama 3.1 8B sigue siendo una buena base.

Recomendación 3: Gemma 3 12B

Gemma 3 12B está más cerca del límite práctico de una RTX 3060 12GB.

Consume más VRAM que los modelos 8B, pero con cuantización Q4 todavía puede funcionar en una tarjeta de 12GB. Es una opción para quien quiera probar un modelo algo mayor en una sola GPU.

Sirve para:

Preguntas generales de mayor calidad.
Procesamiento de contenido en inglés.
Resúmenes y análisis algo más complejos.
Probar una mejora sobre modelos 8B.

Elección recomendada:

1
2
3

Gemma 3 12B GGUF
Q4_K_M u oficial QAT Q4
No abras demasiado el contexto

Si falta VRAM, reduce primero la longitud de contexto o vuelve a un modelo 8B. Para una 3060, 12B es “probable”, no una recomendación automática.

Recomendación 4: DeepSeek R1 Distill Qwen 8B

Si quieres probar modelos locales con estilo de razonamiento, puedes usar modelos como DeepSeek R1 Distill Qwen 8B.

Sirve para:

Problemas simples de razonamiento.
Análisis por pasos.
Aprender el estilo de salida de modelos de razonamiento.
Experimentos locales de bajo costo.

Elección recomendada:

1
2

DeepSeek R1 Distill Qwen 8B GGUF
Q4_K_M

Estos modelos a veces generan procesos de razonamiento más largos, así que la velocidad y el uso de contexto pueden sentirse más pesados que en modelos instruct normales. Para chat diario no siempre son más cómodos que Qwen3 8B, pero sirven bien para experimentar.

Recomendación 5: Phi / MiniCPM / modelos pequeños

Si tu 3060 es de 8GB, o tu RAM también es limitada, considera primero modelos de 3B o 4B.

Sirven para:

Preguntas rápidas.
Resúmenes simples.
Integración en pequeñas herramientas locales.
Chat de baja latencia.
Pruebas en equipos antiguos.

No siempre igualan la calidad de 8B o 12B, pero son ligeros, rápidos y fáciles de desplegar.

Cómo elegir cuantización

El formato local común es GGUF, con cuantizaciones como Q4, Q5, Q6 y Q8.

Cuantización	Características	Mejor para
Q4_K_M	Pequeña, rápida, calidad suficiente	Primera opción en 3060
Q5_K_M	Mejor calidad, más consumo	Probar con modelos 8B
Q6 / Q8	Más cerca de calidad original, más grande	Modelos pequeños o más VRAM
Q2 / Q3	Ahorra VRAM, baja calidad notable	Experimentar con modelos grandes

Para RTX 3060 12GB, lo más práctico es:

1
2
3

Modelos 8B: Q4_K_M o Q5_K_M
Modelos 12B: primero Q4_K_M
Modelos mayores: no recomendados como uso diario

Qué herramienta usar

Los principiantes pueden empezar con Ollama, porque instalar y ejecutar modelos es sencillo.

Comandos comunes:

1
2

ollama run qwen3:8b
ollama run llama3.1:8b

Si quieres controlar mejor archivos GGUF, GPU layers y longitud de contexto, usa llama.cpp o herramientas gráficas basadas en llama.cpp.

Opciones comunes:

Ollama: lo más simple, ideal para empezar.
LM Studio: interfaz gráfica amigable, útil para descargar y cambiar modelos.
llama.cpp: control más fino, bueno para ajustar rendimiento.
text-generation-webui: muchas funciones, útil para probar backends.

Para chat local y preguntas simples, Ollama o LM Studio bastan.

No abras demasiado el contexto

Muchos modelos anuncian soporte de contexto largo, pero en una RTX 3060 no conviene usar siempre el máximo.

Cuanto más largo el contexto, más KV cache se usa y mayor presión de VRAM. Incluso si el modelo carga, un contexto largo puede reducir la velocidad.

Sugerencia:

1
2
3

Chat normal: 4K a 8K
Resumen de documentos: 8K a 16K
RAG de documentos largos: divide primero; no pegues todo de una vez

La 3060 funciona mejor con “contexto medio + buen modelo + buena recuperación” que intentando meter cientos de miles de tokens.

Elegir según uso

Si escribes principalmente en chino:

1
2

Primero: Qwen3 8B Q4_K_M
Alternativa: DeepSeek R1 Distill Qwen 8B

Si escribes principalmente en inglés:

1
2

Primero: Llama 3.1 8B Instruct Q4_K_M
Alternativa: Gemma 3 12B Q4_K_M

Si quieres velocidad:

1
2
3

Modelos 3B / 4B
8B Q4_K_M
Contexto entre 4K y 8K

Si quieres más calidad:

1
2
3

8B Q5_K_M
12B Q4_K_M
Acepta menor velocidad

Si quieres ayuda con código:

1
2

Modelos de código 8B sirven para explicar y pequeños cambios
Para ingeniería compleja, usa modelos cloud más fuertes

Los modelos locales en 3060 son útiles para explicar código, completar funciones, generar scripts pequeños y ayudar sin conexión. Para grandes refactors, bugs complejos y tareas Agent entre archivos, no esperes rendimiento al nivel de Claude Sonnet o GPT-5.

Expectativas razonables

La RTX 3060 12GB puede convertir los LLM locales de “juguete” en herramienta diaria, pero no replica modelos cloud de primera línea en casa.

Ventajas:

Bajo costo.
Más VRAM que tarjetas de 8GB.
Buena experiencia con modelos 8B.
Uso offline.
Procesamiento local de datos sensibles.

Límites:

Modelos grandes no van fluidos.
Contexto largo consume VRAM.
Menor velocidad que tarjetas de gama alta.
Modelos locales pequeños tienen razonamiento complejo limitado.
Multimodalidad y flujos Agent consumen más recursos.

La ruta estable es: usar 8B como asistente local diario, probar 12B para mejor calidad y dejar tareas complejas a modelos cloud.

Resumen

Modelos locales recomendados para RTX 3060 12GB:

Chino general: Qwen3 8B Q4_K_M
Inglés general: Llama 3.1 8B Instruct Q4_K_M
Prueba de más calidad: Gemma 3 12B Q4_K_M
Experimento de razonamiento: DeepSeek R1 Distill Qwen 8B Q4_K_M
Experiencia rápida con poca VRAM: modelos pequeños 3B / 4B

Elige primero Q4_K_M; en modelos 8B puedes probar Q5_K_M. Empieza con Ollama o LM Studio.

No trates la 3060 como un servidor de grandes modelos. Úsala como asistente local de conocimiento, procesador privado de documentos, ayuda ligera de código y tarjeta de experimentación, y encajará mejor con sus capacidades reales.

Referencias

Qwen3 8B GGUF: https://huggingface.co/Qwen/Qwen3-8B-GGUF
Llama 3.1 8B GGUF: https://huggingface.co/macandchiz/Llama-3.1-8B-Instruct-GGUF
Gemma 3 12B GGUF: https://huggingface.co/unsloth/gemma-3-12b-it-GGUF
llama.cpp: https://github.com/ggml-org/llama.cpp
Ollama: https://ollama.com

Cómo dibujar líneas discontinuas, flechas, curvas y cambiar el tamaño del lienzo en AI

Fri, 08 May 2026 09:18:53 +0800

Aquí AI se refiere a software común de diseño vectorial, no a generación de imágenes con inteligencia artificial.

Muchas personas que empiezan con software AI buscan las mismas preguntas: cómo dibujar líneas discontinuas, cómo dibujar flechas, cómo dibujar curvas y cómo cambiar el tamaño del lienzo. Son operaciones básicas, pero sus entradas están repartidas entre trazo, herramienta pluma, herramienta de línea y herramienta de mesa de trabajo.

Este texto las organiza en un orden práctico.

Cómo dibujar una línea discontinua en AI

En software AI, una línea discontinua no suele ser una herramienta separada. Se configura desde el panel de trazo.

Pasos:

Usa la herramienta de línea, herramienta pluma o herramienta de forma para dibujar una línea o ruta.
Selecciona esa línea.
Abre Ventana -> Trazo.
Marca Línea discontinua en el panel de trazo.
Ajusta los valores de guion e intervalo.

Configuración común:

Guion: longitud de cada segmento visible.
Intervalo: espacio entre segmentos.
Grosor de trazo: controla el ancho de la línea.

Para una línea discontinua uniforme, prueba:

1
2

Guion: 8
Intervalo: 8

Para una línea de puntos, cambia el extremo del trazo a redondo y usa un guion muy pequeño:

1
2
3

Guion: 0
Intervalo: 8
Extremo: redondo

Así se verá más como una fila de puntos.

Qué hacer si la línea discontinua no aparece

Si marcas línea discontinua y no ves cambios, revisa:

Si el objeto tiene color de trazo.
Si el grosor de trazo es demasiado pequeño.
Si seleccionaste el objeto correcto.
Si los valores de guion e intervalo son demasiado bajos.
Si el objeto solo tiene relleno y no trazo.

Muchos problemas de líneas son simplemente “el objeto tiene ruta, pero no tiene trazo”.

Cómo dibujar una flecha en AI

Las flechas tampoco suelen dibujarse como un objeto separado. Se agregan como estilo de trazo sobre una ruta.

Pasos:

Dibuja una línea recta con la herramienta de línea.
Selecciona la línea.
Abre Ventana -> Trazo.
Busca Flechas en la parte inferior del panel.
Elige una flecha para el inicio o el final.
Ajusta la escala de la flecha.

Si la flecha queda al revés, puedes:

Cambiarla del inicio al final en el panel de trazo.
Usar un comando para invertir la dirección de la ruta.

Lo más simple es dibujar la línea de nuevo: arrastra desde la cola hacia la punta. El punto final será la dirección de la flecha.

Cómo dibujar una flecha de doble punta

Una flecha de doble punta solo necesita flechas tanto al inicio como al final.

Pasos:

Selecciona la línea.
Abre el panel de trazo.
Elige una flecha en la primera posición.
Elige otra flecha en la segunda posición.

Si las flechas son demasiado grandes o pequeñas, ajusta Escala.

En general, el tamaño de la flecha debe coincidir con el grosor de línea. Una línea fina con una flecha enorme se ve desequilibrada; una línea gruesa con una flecha diminuta se lee mal.

Cómo dibujar una curva en AI

La forma más común de dibujar curvas es usar la herramienta pluma.

Método básico:

Selecciona la herramienta pluma.
Haz clic una vez en el lienzo para crear el primer punto de ancla.
En la segunda posición, mantén presionado y arrastra, no hagas solo clic.
Al arrastrar aparecen manejadores de dirección, y se crea la curva.
Sigue haciendo clic y arrastrando para formar una curva continua.

La idea clave es: para líneas rectas, haz clic; para curvas, haz clic y arrastra.

Muchos principiantes no logran dibujar curvas porque solo hacen clic y nunca arrastran los manejadores.

Cómo suavizar una curva

Después de dibujar una curva, puedes ajustarla con estas herramientas:

Selección directa: selecciona puntos de ancla y mueve puntos o manejadores.
Herramienta de punto de ancla: cambia entre esquinas y puntos suaves.
Herramienta suavizar: hace la ruta más fluida.
Herramienta curvatura: crea curvas suaves de forma más simple.

Si solo quieres una curva natural, la herramienta curvatura es más amigable para principiantes que la pluma. No requiere arrastrar muchos manejadores a mano; basta con hacer clic en algunos puntos.

Dibujar curvas con la herramienta curvatura

La herramienta curvatura funciona más como “pon puntos y la curva los sigue”.

Pasos:

Selecciona la herramienta curvatura.
Haz clic en el primer punto del lienzo.
Haz clic en el segundo punto.
Haz clic en un tercer punto, y el software creará la curva automáticamente.
Arrastra puntos existentes para cambiar la forma.

Si quieres una esquina, haz doble clic en un punto para alternar entre punto suave y punto de esquina.

Para principiantes, suele ser más fácil crear la forma general con curvatura y luego ajustar con selección directa.

Cómo cambiar el tamaño del lienzo en AI

En AI, “tamaño del lienzo” normalmente significa tamaño de mesa de trabajo. Si quieres cambiar el rango de exportación, tamaño de diseño o tamaño de página, cambia la mesa de trabajo.

Pasos:

Selecciona la herramienta mesa de trabajo en la barra lateral.
Haz clic en la mesa de trabajo actual.
Escribe ancho y alto en la barra de propiedades superior.
También puedes arrastrar los bordes manualmente.

Ejemplos de tamaños comunes:

Portada WeChat: 900 x 383 px
Portada Xiaohongshu: 1242 x 1660 px
Cuadrado Instagram: 1080 x 1080 px
Papel A4: 210 x 297 mm

Si tu unidad no es px, cambia la unidad en el documento o panel de propiedades.

Cambiar tamaño desde el panel de mesas de trabajo

Además de usar la herramienta, también puedes gestionar varias mesas desde el panel correspondiente.

Pasos:

Abre Ventana -> Mesas de trabajo.
Selecciona la mesa que quieres modificar.
Abre las opciones de mesa de trabajo.
Escribe ancho, alto y posición.

Si un archivo contiene varias páginas, tamaños de póster o versiones de exportación, el panel es más claro que arrastrar a mano.

¿Cambiar la mesa de trabajo afecta los gráficos?

Cambiar solo el tamaño de la mesa normalmente no escala automáticamente los gráficos dentro.

Eso significa:

Si la mesa se agranda, los gráficos mantienen su tamaño.
Si la mesa se reduce, los gráficos también mantienen su tamaño, pero pueden quedar fuera del área.
Al exportar, normalmente solo se exporta lo que está dentro de la mesa.

Si quieres que los gráficos escalen junto con la mesa, selecciónalos y escálalos manualmente, o usa la herramienta de escala o el panel de transformación.

Entradas y atajos útiles

Entradas útiles:

Panel de trazo: Ventana -> Trazo
Panel de mesas de trabajo: Ventana -> Mesas de trabajo
Herramienta mesa de trabajo: Shift + O
Herramienta pluma: P
Selección directa: A

Distintas versiones pueden tener interfaces algo diferentes, pero la lógica central es la misma: líneas discontinuas y flechas están en trazo, curvas usan herramientas de ruta, y el tamaño del lienzo se cambia mediante mesas de trabajo.

Resumen

Para dibujar líneas discontinuas en AI: selecciona una ruta, marca Línea discontinua en el panel Trazo y ajusta guion e intervalo.

Para dibujar flechas en AI: dibuja una línea y agrega una flecha al inicio o al final desde el panel Trazo.

Para dibujar curvas en AI: usa la herramienta pluma haciendo clic y arrastrando, o usa la herramienta curvatura para curvas suaves más fáciles.

Para cambiar el tamaño del lienzo en AI: usa la herramienta mesa de trabajo o el panel Mesas de trabajo para modificar ancho y alto.

Con estas operaciones, la mayoría de líneas básicas, diagramas de flujo, gráficos de anotación y ajustes de tamaño de página se vuelven manejables.

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/

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.

Edge corrige la vulnerabilidad critica CVE-2026-2441 en mayo de 2026: visitar una pagina maliciosa podria permitir ejecucion remota de codigo

Wed, 06 May 2026 08:30:17 +0800

Microsoft Edge publico recientemente varias rondas de actualizaciones de seguridad para corregir problemas procedentes del proyecto Chromium y de componentes propios de Edge. Entre ellos, CVE-2026-2441 fue reportada por el equipo de Chromium como explotada en la naturaleza, y tanto el canal estable como el canal estable extendido de Microsoft Edge ya incluyen la correccion.

Si usas Edge a diario, especialmente en Windows para cuentas, correo, banca, paneles de administracion o sistemas empresariales, conviene confirmar cuanto antes que el navegador esta actualizado a la version mas reciente.

Riesgo de la vulnerabilidad

CVE-2026-2441 es una vulnerabilidad de alto riesgo que ya ha llamado la atencion de atacantes y ha sido explotada. La forma tipica de explotar fallos de navegador consiste en inducir al usuario a visitar una pagina con contenido especialmente preparado, activando defectos del motor de renderizado o de componentes relacionados.

En ataques reales, este tipo de vulnerabilidad puede traer riesgos como:

Ejecutar codigo malicioso o combinarse con otros fallos para superar el sandbox.
Evadir parte de las restricciones de seguridad y ampliar la superficie de ataque.
Robar datos sensibles, informacion de sesion o contenido de paginas del navegador.
Provocar cierres del navegador, paginas anormales o denegacion de servicio.

Hay que recordar que, cuando un parche acaba de publicarse, los detalles completos del ataque normalmente no se hacen publicos para evitar que mas atacantes reproduzcan la vulnerabilidad. Para usuarios comunes, la defensa mas efectiva es actualizar a tiempo.

Alcance afectado

Microsoft Edge se basa en Chromium, por lo que vulnerabilidades relacionadas pueden afectar versiones de Edge en varias plataformas, incluidas Windows, macOS, Linux y moviles. Cualquier version del navegador anterior a una version que incluya el parche esta en riesgo.

Segun las notas de seguridad de Microsoft Edge, el canal estable 145.0.3800.58, publicado el 14 de febrero de 2026, ya incluye la correccion de CVE-2026-2441; el canal estable extendido 144.0.3719.130, publicado el 17 de febrero de 2026, tambien la incluye. Las versiones posteriores siguen acumulando parches de seguridad del proyecto Chromium.

Hasta el 6 de mayo de 2026, la version de seguridad estable mas reciente listada en la pagina de actualizaciones de Edge era 147.0.3912.98, publicada el 30 de abril de 2026. Si la version local esta claramente por debajo, deberias actualizar de inmediato.

Actualizar Edge ahora

Los usuarios comunes pueden comprobar y actualizar asi:

Abre Microsoft Edge.
Escribe edge://settings/help en la barra de direcciones y pulsa Enter.
Espera a que el navegador busque actualizaciones automaticamente.
Cuando termine, haz clic en “Reiniciar”.

En entornos empresariales, los administradores deberian revisar politicas de gestion de endpoints, WSUS, Intune, directivas de grupo o sistemas de parches de terceros para confirmar que las actualizaciones de Edge no llevan mucho tiempo retrasadas. En dispositivos que no puedan actualizarse de inmediato, conviene reducir el acceso a sitios desconocidos y limitar antes la navegacion externa de grupos de usuarios de alto riesgo.

Recomendaciones de proteccion

Actualiza Edge cuanto antes y reinicia el navegador despues.
No hagas clic en enlaces de correo, chats o anuncios de origen desconocido.
Evita usar navegadores antiguos para paneles de administracion, pagos, correo u otras paginas sensibles.
Mantén Windows, el antivirus y las extensiones del navegador actualizados.
Elimina extensiones del navegador que no uses desde hace tiempo o cuyo origen no sea claro.

Fuentes

Resumen

Lo importante de CVE-2026-2441 no es que sus detalles sean complejos, sino que ya fue reportada como explotada en la naturaleza. Para usuarios individuales y terminales empresariales, la accion mas directa es abrir edge://settings/help, confirmar que Edge se actualizo y reiniciar.

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

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

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

En resumen:

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

apt: parte del sistema

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

Uso típico:

`1`	`sudo apt install firefox`

apt tiene estas características:

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

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

Snap: aplicación y dependencias en un solo paquete

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

La instalación se ve parecida:

`1`	`sudo snap install firefox`

Ventajas de Snap:

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

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

Flatpak: más orientado a apps de escritorio

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

Instalación típica:

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

Flatpak tiene estas características:

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

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

La mayor diferencia: dependencias

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

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

Eso crea un compromiso:

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

Aislamiento y permisos

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

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

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

Las actualizaciones funcionan distinto

apt suele seguir las actualizaciones del sistema:

1
2

sudo apt update
sudo apt upgrade

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

Flatpak puede actualizarse manualmente:

`1`	`flatpak update`

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

Cuál deberías usar

Elige por escenario:

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

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

Resumen

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

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

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

Referencia:

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

Cambios del driver NTFS en Linux 7.0 y 7.1, explicados

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

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

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

Resumen rápido

Linux tiene ahora tres caminos principales para NTFS:

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

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

Relación entre 7.0 y 7.1

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

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

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

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

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

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

En resumen:

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

Cuál usar

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

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

Para montar manualmente con ntfs3:

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

Para acceso temporal de solo lectura:

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

Para comprobar qué driver se está usando:

1
2

findmnt -T /mnt/ntfs
mount | grep ntfs

Notas para dual-boot

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

Comprueba primero:

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

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

Por qué existen varios drivers NTFS

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

NTFS es especialmente adecuado para un enfoque conservador:

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

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

Resumen

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

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

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

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

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

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

Esto plantea dos preguntas naturales:

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

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

Qué es sudo-rs

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

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

sudo-rs opta por reimplementarlo por varias razones:

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

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

Qué notarán los usuarios comunes

Para los usuarios comunes, cambia muy poco.

Se sigue usando así:

`1`	`sudo apt update`

O así:

`1`	`sudo systemctl restart nginx`

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

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

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

Qué deben vigilar los administradores

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

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

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

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

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

Cómo maneja Ubuntu sudo y sudo-rs

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

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

El comando de cambio se parece a este:

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

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

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

Por qué sudo-rs usa Rust

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

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

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

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

sudo-rs no es la única alternativa

En el ecosistema de sudo siempre ha habido otras alternativas.

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

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

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

Qué revisar antes de migrar

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

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

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

Primero puedes verificarlo en una máquina de pruebas:

sudo -l

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

¿Deberías cambiar manualmente a sudo-rs?

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

Un proceso más prudente sería:

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

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

Resumen

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

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

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

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

Referencias:

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

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

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

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

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

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

Qué es X11

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

La estructura típica de X11 es:

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

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

Qué es Wayland

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

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

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

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

Diferencias de arquitectura

La diferencia central está en el reparto de responsabilidades.

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

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

Puedes entenderlo así:

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

Ventajas de X11

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

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

Si tus necesidades incluyen:

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

entonces X11 sigue siendo una opción muy realista.

Desventajas de X11

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

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

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

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

Ventajas de Wayland

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

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

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

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

Desventajas de Wayland

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

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

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

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

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

Qué hace Xwayland

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

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

Esto suaviza mucho la migración:

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

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

Cuál rinde mejor

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

En general:

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

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

Capturas, grabación y uso compartido de pantalla

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

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

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

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

Qué deberían elegir los jugadores

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

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

Los jugadores pueden elegir así:

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

Escritorio remoto y automatización

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

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

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

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

Cómo saber cuál estás usando

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

`1`	`echo $XDG_SESSION_TYPE`

Si la salida es:

wayland

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

Si la salida es:

x11

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

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

Recomendaciones de elección

Puedes decidir de esta forma:

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

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

Resumen

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

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

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

Referencias:

Copy Fail CVE-2026-31431: riesgo de escape de contenedor en la ruta de copia de archivos del kernel Linux

Fri, 01 May 2026 18:42:34 +0800

Copy Fail es una vulnerabilidad en la ruta de copia de archivos del kernel Linux, registrada como CVE-2026-31431. El análisis de Bugcrowd la describe como un problema de nivel kernel que merece atención: bajo condiciones específicas, un usuario sin privilegios puede abusar de la lógica de copia de archivos para provocar escrituras no autorizadas, lo que puede llevar a escalada de privilegios o escape de contenedor.

Desde una perspectiva de riesgo, no es una vulnerabilidad normal de capa de aplicación. El problema ocurre en la ruta del kernel que maneja copia de archivos y comportamiento de page cache, por lo que su impacto puede extenderse a contenedores, hosts compartidos, runners de CI/CD, plataformas PaaS y entornos Linux multi-tenant. Si un atacante ya puede ejecutar código con pocos privilegios en un sistema, la vulnerabilidad puede convertirse en un escalón para romper límites de aislamiento.

Dónde vive aproximadamente la vulnerabilidad

Copy Fail está relacionada con capacidades de copia de archivos del kernel Linux. Linux moderno ofrece varias rutas eficientes de copia, como copy_file_range, rutas tipo splice y optimizaciones de copia de datos entre distintos sistemas de archivos. Estos mecanismos están diseñados para reducir movimiento de datos entre espacio de usuario y espacio de kernel y mejorar el rendimiento de copia de archivos grandes.

El problema es que las rutas de copia de alto rendimiento suelen reutilizar page cache, offsets de archivo, comprobaciones de permisos y callbacks de sistemas de archivos. Si una condición de borde no se maneja con suficiente rigor, el kernel puede realizar una escritura en el contexto de permisos equivocado o exponer páginas de datos que el atacante no debería controlar.

El riesgo central de Copy Fail se puede resumir así:

el atacante no necesita privilegios root;
el punto de entrada del ataque proviene de capacidades comunes de copia de archivos;
la lógica afectada se ejecuta en espacio de kernel;
en entornos de contenedores, la vulnerabilidad puede saltarse aislamiento de namespaces y montajes;
una explotación exitosa puede escribir contenido del host que el contenedor no debería poder modificar.

Por eso ha llamado la atención. La seguridad de contenedores depende del aislamiento que proporciona el kernel Linux. Cuando una ruta del propio kernel permite escrituras no autorizadas, el límite del contenedor se vuelve frágil.

Por qué los escenarios de contenedores son más sensibles

Los contenedores no son máquinas virtuales. Los procesos dentro de un contenedor comparten el mismo kernel Linux con el host y se aíslan mediante mecanismos como namespaces, cgroups, capabilities, seccomp y AppArmor/SELinux.

Si una vulnerabilidad existe en un servicio de espacio de usuario, normalmente afecta solo a un contenedor o un proceso. Pero si la vulnerabilidad está en el kernel, especialmente una que puede activar un usuario sin privilegios, un atacante puede influir en el host desde dentro de un contenedor.

Ahí es donde Copy Fail se vuelve peligroso. Muchas plataformas permiten a usuarios enviar jobs de build, ejecutar scripts, iniciar contenedores o ejecutar plugins. Mientras un atacante pueda ejecutar código dentro de un contenedor, puede intentar usar la ruta de copia de archivos del kernel para romper el aislamiento.

Entornos de alto riesgo incluyen:

cargas no confiables en clusters Kubernetes;
runners compartidos en plataformas CI/CD;
plataformas sandbox que permiten a usuarios subir y ejecutar código;
hosts Linux multi-tenant;
entornos PaaS contenerizados;
sistemas que ejecutan plugins o extensiones de terceros.

Si estos entornos ejecutan kernels afectados y no tienen restricciones adicionales, el riesgo aumenta de forma significativa.

El impacto depende del estado de parcheo del kernel

No se puede juzgar este tipo de vulnerabilidad solo por el nombre de la distribución. Para la misma versión de Ubuntu, Debian, RHEL, Fedora o Arch, la exposición depende del paquete de kernel que realmente está en ejecución y de si la distribución hizo backport del arreglo.

Durante el triage, prioriza tres comprobaciones:

La versión del kernel actualmente en ejecución.
Si el aviso de seguridad de la distribución menciona CVE-2026-31431.
Si el proveedor cloud o la plataforma gestionada parcheó el kernel del host.

Primero puedes confirmar la versión del kernel en el sistema:

`1`	`uname -a`

Luego revisa avisos de seguridad de la distribución, changelogs del kernel o comunicados de la plataforma cloud. No juzgues la seguridad solo por la versión mayor, porque muchas distribuciones empresariales hacen backport de correcciones de seguridad a ramas de kernel antiguas.

Ideas de mitigación temporal

La solución más confiable sigue siendo actualizar el kernel. Pero en entornos donde los parches no pueden desplegarse de inmediato, puedes reducir exposición primero.

Direcciones comunes de mitigación incluyen:

impedir que usuarios no confiables ejecuten contenedores privilegiados;
evitar montar rutas sensibles del host dentro de contenedores;
endurecer capabilities de contenedores, especialmente evitando CAP_SYS_ADMIN innecesario;
usar seccomp, AppArmor o SELinux para restringir syscalls peligrosas y acceso a archivos;
mover cargas no confiables a aislamiento más fuerte mediante máquinas virtuales;
destruir runners de CI/CD por job en lugar de reutilizar el mismo host durante mucho tiempo;
monitorear escrituras anómalas de archivos, cambios de permisos y señales de escape de contenedor.

Estas medidas no reemplazan parches. Su papel es reducir la probabilidad de explotación y el impacto, especialmente antes de que los parches lleguen a producción.

Prioridad de parcheo

Prioriza la remediación según el riesgo del entorno.

Parchear primero:

plataformas que exponen ejecución de contenedores a usuarios externos;
nodos CI/CD que ejecutan código no confiable;
nodos Kubernetes multi-tenant;
sistemas con plugins o ejecución de scripts definidos por usuarios;
máquinas de desarrollo compartidas, equipos de enseñanza y plataformas de laboratorio.

Prioridad relativamente menor:

escritorios de un solo usuario;
hosts internos que solo ejecutan servicios confiables;
entornos que ya aíslan código no confiable mediante máquinas virtuales.

Incluso cuando el riesgo es menor, sigue siendo mejor actualizar el kernel mediante la distribución. Las vulnerabilidades de kernel a menudo se encadenan en ataques más complejos, y retrasar parches rara vez aporta mucho beneficio.

Checklist para equipos de operaciones

Puedes procesarlo en este orden:

Inventariar todos los hosts Linux y nodos de contenedores.
Marcar máquinas que ejecutan código no confiable.
Comprobar versión actual de kernel y avisos de seguridad de la distribución.
Actualizar primero los nodos de alto riesgo.
Aplicar políticas temporales de aislamiento a nodos que no pueden actualizarse de inmediato.
Revisar configuración del runtime de contenedores y eliminar privilegios y montajes de host innecesarios.
Reiniciar nodos después de actualizar y confirmar que el nuevo kernel está realmente en ejecución.
Mantener registros de cambios para auditoría posterior.

Instalar un paquete de kernel no significa que el sistema ya esté ejecutando el nuevo kernel. Debes reiniciar después de actualizar y confirmar de nuevo:

`1`	`uname -a`

Resumen

El punto clave de Copy Fail / CVE-2026-31431 no es que una aplicación se cierre, sino que existe un problema de límite de permisos en la ruta de copia de archivos del kernel Linux. Da a código sin privilegios una oportunidad de tocar rutas de escritura con mayor privilegio, por lo que merece atención especial en entornos de contenedores y multi-tenant.

Al manejar este tipo de vulnerabilidad, las dos acciones más importantes son:

seguir cuanto antes los parches de kernel de tu distribución o proveedor cloud;
antes de desplegar parches, restringir código no confiable, contenedores privilegiados y montajes sensibles del host.

Para escritorios personales, quizá no sea un motivo de pánico inmediato. Pero para equipos que operan plataformas de contenedores, CI/CD, sandboxes y hosts compartidos, debe tratarse como una actualización de seguridad de kernel de alta prioridad.

Referencias:

Resumen de novedades de Linux Kernel 7.0

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

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

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

Sistemas de archivos: XFS, EXT4 y NTFS3 cambiaron

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

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

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

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

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

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

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

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

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

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

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

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

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

Soporte de hardware: nuevas plataformas y mejoras de dispositivos existentes

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

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

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

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

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

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

Seguridad y aislamiento: io_uring puede usar filtrado BPF

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

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

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

El soporte de Rust ya no es solo una etiqueta experimental

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

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

Eliminación de funcionalidad antigua: desaparece laptop_mode

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

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

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

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

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

¿Conviene actualizar de inmediato?

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

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

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

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

Resumen

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

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

Referencias:

hackingtool: usos, riesgos y l铆mites de aprendizaje de un kit de seguridad todo en uno

Fri, 01 May 2026 03:45:00 +0800

hackingtool es un proyecto de kit de herramientas (toolkit) que reúne muchas herramientas de seguridad en un solo lugar.

Según el README, cubre una amplia gama de áreas, incluyendo herramientas de anonimato, recopilación de información, análisis de vulnerabilidades, ataques web, redes inalámbricas, forense, payloads, ingeniería inversa, DDoS, administración remota y herramientas relacionadas con phishing. Es más bien un navegador de herramientas de seguridad que una herramienta pequeña para un problema específico.

Los proyectos como este son fáciles de malinterpretar, por lo que el límite debe establecerse primero: las herramientas de seguridad solo deben usarse en entornos autorizados, laboratorios, polígonos (ranges), CTFs o en sus propios sistemas. No las use contra objetivos no autorizados. Este artículo solo explica el posicionamiento del proyecto y las rutas de aprendizaje. No proporciona pasos de ataque, comandos de abuso ni orientación para eludir (bypass guidance).

false

Qué Problema Resuelve

Cuando las personas comienzan a aprender sobre ciberseguridad, a menudo se enfrentan a un problema: hay demasiadas herramientas y no está claro por dónde empezar.

Puede haber escuchado sobre:

Herramientas de recopilación de información
Herramientas de escaneo de vulnerabilidades web
Herramientas de auditoría de contraseñas
Herramientas de prueba de redes inalámbricas
Herramientas de análisis forense
Herramientas de ingeniería inversa
Herramientas de generación de payloads
Herramientas de anonimato y proxy

Cada categoría por sí sola contiene muchos proyectos. El problema es que los principiantes a menudo no pueden juzgar qué hacen, qué escenarios les convienen y dónde residen los riesgos.

El valor de hackingtool es que agrupa estas herramientas por categoría, ayudando a los estudiantes a ver primero un mapa aproximado del ecosistema de herramientas de seguridad.

No es necesariamente el mejor método de instalación para cada herramienta, ni es necesariamente adecuado para entornos de producción. Pero es útil para construir una comprensión de primer nivel: la ciberseguridad no es una herramienta, sino un conjunto de objetivos, métodos y límites.

false

Ventajas de un Toolkit

Este tipo de colección tiene ventajas obvias.

Primero, reduce el costo de búsqueda para los principiantes.

No necesitas conocer el nombre de cada herramienta al principio. A través de categorías, puedes entender primero las principales direcciones en el aprendizaje de seguridad.

Segundo, es adecuado para la configuración de laboratorios.

Si estás aprendiendo en una máquina virtual local, en Kali, en un entorno de laboratorio Ubuntu o en un rango CTF, un toolkit puede ayudarte a llenar rápidamente las herramientas comunes.

Tercero, facilita la comparación de herramientas similares.

La misma dirección a menudo tiene múltiples herramientas. Information gathering, Web testing, password auditing y forensic analysis tienen todas implementaciones y escenarios adecuados diferentes. Agruparlas ayuda a los principiantes a compararlas horizontalmente.

Cuarto, te ayuda a entender la cadena de seguridad.

Las pruebas de seguridad reales no son “ejecutar una herramienta y terminar”. Generalmente involucran la identificación de activos, la recopilación de información, la validación de vulnerabilidades, la evaluación de impacto, el consejo de remediación y la redacción de informes. Las categorías de herramientas te ayudan a entender qué capacidades se corresponden aproximadamente con cada paso.

false

Riesgos a Considerar

Cuanto más grande sea el toolkit, más seriamente debe abordar el riesgo.

Primero, la calidad de las herramientas no siempre es consistente.

Un proyecto de colección puede incluir muchas herramientas de terceros. Su estado de mantenimiento, calidad de código, seguridad de dependencias, compatibilidad y licencias pueden diferir enormemente. No asuma que todas las herramientas son seguras y fiables.

Segundo, los scripts de instalación pueden introducir riesgo en la cadena de suministro.

Las herramientas de seguridad a menudo requieren altos privilegios, acceso a la red, dependencias del sistema y descargas externas. Antes de ejecutar cualquier script de instalación, lea su contenido, confirme que la fuente sea confiable e idealmente pruébelo en un entorno aislado.

Tercero, algunas herramientas tienen propiedades ofensivas obvias.

El README menciona áreas como DDoS, payloads, phishing y acceso remoto. Estas herramientas pueden utilizarse en laboratorios autorizados para aprender principios de ataque y defensa, pero abusarlas contra objetivos reales crea serios problemas legales y éticos.

Cuarto, las herramientas no pueden reemplazar los fundamentos.

Si solo puede ejecutar herramientas pero no entiende los protocolos de red, los principios del sistema operativo, la seguridad web, los modelos de permisos y el análisis de registros, puede tomar fácilmente decisiones incorrectas. La salida de las herramientas también puede contener falsos positivos y falsos negativos.

false

Cómo aprender con él

Si quieres usar un proyecto como este para aprender sobre seguridad, es mejor dividir el aprendizaje por temas en lugar de instalarlo todo a la vez.

Puedes empezar con:

Conceptos básicos de Networking: IP, puertos, DNS, HTTP, TLS
Conceptos básicos de Linux: permisos, procesos, file systems, service management
Seguridad Web: autenticación, autorización, input validation, sesiones, vulnerabilidades comunes
Recolección de información: asset identification y organización de información pública
Validación de vulnerabilidades: solo dentro de rangos locales o sistemas autorizados
Análisis forense: logs, discos, memoria y evidencia de tráfico
Perspectiva defensiva: detección, hardening, patching y reporting

Esta es una forma más estable de aprender.

Las herramientas deben servir al conocimiento, no guiar la ruta de aprendizaje en lugar del conocimiento.

false

Escenarios Adecuados

hackingtool es más adecuado para:

Principiantes que aprenden categorías de herramientas de seguridad
Preparar herramientas para entornos CTF o de práctica (range)
Construir laboratorios aislados
Aprender ecosistemas de herramientas en diferentes áreas de seguridad
Estudiar flujos de trabajo de pruebas de seguridad
Comparar el uso de herramientas similares

No es adecuado para:

Escanear o atacar objetivos no autorizados
Instalar herramientas aleatoriamente en máquinas de producción
Tratar la salida de la herramienta directamente como conclusiones de seguridad
Ejecutar scripts con altos privilegios sin leerlos
Usar herramientas ofensivas en entornos de red reales

false

Por qué no se recomienda instalar todo con un solo clic

Muchos proyectos de toolkit ofrecen la idea de una instalación con un solo clic, pero debes tener cuidado en la práctica.

Los problemas incluyen:

Conflictos de dependencias
Entorno de sistema contaminado
Fuentes de descarga sin control
Instalar muchas herramientas que no sabes usar
Dificultad para mantener y actualizar
Dificultad para auditar lo que hace cada herramienta

Un mejor enfoque es instalar mientras se aprende por tema.

Si hoy estás aprendiendo recopilación de información (information gathering), instala solo las herramientas relacionadas. Cuando estudies seguridad web (Web security) la próxima semana, añade herramientas de prueba web (Web testing tools). Cuando hagas un experimento forense, prepara herramientas forenses. Esto mantiene el entorno más limpio y el objetivo de aprendizaje más claro.

false

Cómo Usar Dichos Repositorios de Forma Segura

Primero, usa un entorno aislado.

Usa una máquina virtual, un contenedor o una máquina de laboratorio dedicada. No contamines directamente tu sistema de trabajo principal.

Segundo, conéctate solo a objetivos autorizados.

Los objetivos pueden ser rangos locales, plataformas CTF, servicios de prueba que hayas construido tú mismo o ámbitos de prueba de seguridad claramente autorizados.

Tercero, lee los scripts antes de ejecutarlos.

No copies comandos de un README y los ejecutes a ciegas. Primero inspecciona los scripts de instalación, las fuentes de dependencia, los requisitos de permisos y el comportamiento de acceso a la red.

Cuarto, registra el proceso del experimento.

El aprendizaje de seguridad no es solo ejecutar herramientas. Registra las entradas (inputs), salidas (outputs), el razonamiento, las causas de falsos positivos y las sugerencias de remediación para mejorar de verdad.

Quinto, aprende la perspectiva defensiva.

Por cada superficie de ataque que estudies, comprende también la defensa correspondiente: cómo detectarlo, cómo endurecer los sistemas, cómo preservar la evidencia y cómo redactar un informe.

false

Diferencia con Kali Linux

Kali Linux es una distribución para pruebas de penetración e investigación de seguridad. Ya incluye y mantiene muchas herramientas de seguridad.

hackingtool es más bien una colección de instalación y clasificación. Puede ayudarte a comprender el ecosistema de herramientas, pero no es una distribución de seguridad completa y no es equivalente al sistema de mantenimiento de Kali.

Si eres principiante, Kali, Parrot, o una máquina virtual Ubuntu con un entorno de rango es generalmente más estable que instalar un toolkit con un solo clic en tu máquina principal.

Si ya tienes tu propio entorno de laboratorio, hackingtool se puede usar como referencia de índice de herramientas.

false

Límites de Uso

Los límites son muy importantes para las herramientas de seguridad.

Los escenarios legítimos incluyen:

Tu propio entorno de laboratorio
CTFs y rangos
Pruebas de seguridad autorizadas por la empresa
Experimentos de curso
Investigación local y validación defensiva

Los escenarios inapropiados incluyen:

Escaneo no autorizado de objetivos públicos
Intentos de vulnerabilidad contra sitios web de terceros
Phishing, robo de cuentas o eludir el control de acceso
Interferir con la disponibilidad del servicio
Recopilar o usar datos de otras personas sin permiso

El estándar es simple: sin autorización clara, no pruebes.

false

Usuarios adecuados

hackingtool es adecuado para personas con objetivos de aprendizaje, no para personas que solo quieren “hacer clic una vez y hackear algo”.

Es adecuado para:

Principiantes en ciberseguridad
Aprendices de CTF
Constructores de laboratorios de seguridad
Personas que quieren entender las categorías de herramientas
Personas que quieren mapear el conocimiento de ataque-defensa a herramientas

Si aún no estás familiarizado con Linux, los fundamentos de networking, los conceptos básicos de Web y los conceptos de permisos, aprende eso primero antes de usar este tipo de kit de herramientas. De lo contrario, puedes recordar comandos sin entender los resultados.

false

Referencias

Z4nzu/hackingtool

false

Pensamiento Final

hackingtool puede ser un punto de entrada al ecosistema de herramientas de ciberseguridad, pero no debe tratarse como una caja de herramientas de ataque sin límites.

El aprendizaje de seguridad valioso significa comprender principios, validar riesgos, aprender defensas y convertir la salida de la herramienta en conclusiones de seguridad explicables y reparables dentro de entornos autorizados. false

Qué hace auto-editor: cortar silencios automáticamente y exportar a Premiere o Resolve

Thu, 23 Apr 2026 13:31:27 +0800

Lo que más tiempo consume en muchos videos no son transiciones, color ni subtítulos. Es ver un archivo largo de principio a fin y quitar manualmente las partes donde nadie habla, nada se mueve y no ocurre nada útil.

Ese es el problema que auto-editor intenta resolver. No es una app visual de edición tradicional. Es una herramienta de línea de comandos que analiza video o audio y luego corta automáticamente secciones silenciosas y segmentos de baja actividad para terminar antes el primer rough cut.

Es especialmente útil cuando el material fuente es:

grabaciones de pantalla
tutoriales
podcasts o talking-head
replays largos de livestreams
entrevistas que necesitan un rough cut antes de edición fina

Cuál es su valor central

La idea principal de auto-editor se resume así:

automatizar el primer pase aburrido y devolver el resultado al humano.

El README oficial enfatiza que elimina “dead space”, especialmente silencio. En videos largos, esa suele ser la parte más repetitiva del proceso.

Uso básico:

`1`	`auto-editor path/to/your/video.mp4`

El resultado puede entenderse como una primera ronda de filtrado. No toma decisiones creativas finales por ti. Limpia las partes que obviamente contienen poca información útil.

No solo corta por silencio

Cuando la gente oye “edición automática”, asume que solo detecta silencio.

Pero auto-editor soporta más de un método:

audio: juzga secciones por volumen
motion: juzga secciones por movimiento visual

Por ejemplo:

`1`	`auto-editor example.mp4 --edit motion:threshold=0.02`

Esto importa porque no se limita a videos donde la única regla es “cortar cuando nadie habla”. También sirve cuando la señal importante es actividad visual.

Los ejemplos oficiales muestran que puedes combinar métodos, como audio y movimiento juntos. Eso permite expresar reglas más cercanas a edición real.

`--margin` importa más de lo que parece

La forma más fácil de que un rough cut automático se sienta mal no es fallar al quitar silencio, sino cortar demasiado agresivamente.

Si se corta la primera palabra de una frase o el final de cada línea queda demasiado brusco, el resultado se siente mecánico. auto-editor ofrece --margin.

Puedes entenderlo como añadir un pequeño buffer alrededor de las secciones que se recortarían. En los ejemplos oficiales, el valor predeterminado es 0.2s, dejando algo de padding alrededor de cortes.

1
2

auto-editor example.mp4 --margin 0.2sec
auto-editor example.mp4 --margin 0.3s,1.5sec

Esta opción suele determinar si el resultado parece un corte automático duro o un primer pase razonablemente humano.

Es una herramienta de primer pase, no reemplazo completo de NLE

Este es el punto más importante.

Se comporta más como un rough-cutter automatizado que como un editor no lineal completo. Sus fortalezas:

procesar metraje largo rápido
automatizar eliminación repetitiva de dead space
comprimir tramos de bajo valor antes de edición real

Pero cuando necesitas estas cosas, probablemente volverás a un editor tradicional:

ritmo fino
elegir manualmente los mejores momentos
subtítulos, transiciones y B-roll
color, audio y empaquetado final

El marco realista no es “ya no necesitas Premiere o Resolve”, sino “deja que auto-editor haga primero el trabajo repetitivo y luego termina en un editor real”.

Puede renderizar directamente o exportar timelines

Si solo quieres una versión rápida con dead space eliminado, puede renderizar media directamente. Pero si planeas seguir editando, los docs soportan exportar timelines a editores comunes.

El README lista:

Adobe Premiere Pro: --export premiere
DaVinci Resolve: --export resolve
Final Cut Pro: --export final-cut-pro
Shotcut: --export shotcut
Kdenlive: --export kdenlive
clips individuales: --export clip-sequence

Por ejemplo:

`1`	`auto-editor example.mp4 --export premiere`

Eso lo vuelve una herramienta frontend de procesamiento, no un workflow cerrado.

También soporta reglas manuales

Muchas herramientas automáticas frustran cuando toman una mala decisión.

auto-editor es más flexible. Permite marcar secciones que siempre se cortan o siempre se conservan:

--cut-out: siempre eliminar una sección
--add-in: siempre conservar una sección

1
2

auto-editor example.mp4 --cut-out 0,30sec
auto-editor example.mp4 --add-in 0,30sec

Así no entregas todo el control al programa. Puedes dejar que las reglas automáticas hagan el grueso y corregir edge cases manualmente.

La recomendación oficial de instalación ahora es el binario

Según la página oficial de instalación, la ruta recomendada hoy no es pip, sino binarios precompilados desde GitHub Releases.

Proceso aproximado:

Descarga el binario de tu plataforma desde Releases.
Renómbralo a auto-editor o auto-editor.exe en Windows.
Ejecútalo desde la terminal.
Usa auto-editor --help para verificar instalación.

También se mencionan gestores de paquetes:

macOS: brew install auto-editor
Ubuntu o Debian-like: apt
Arch-like: yay -S auto-editor

La página indica que nuevas versiones ya no se publican en pip, así que pip install auto-editor existe, pero no es la ruta preferida.

Con yt-dlp puede aceptar URLs

Si yt-dlp está instalado, auto-editor puede usar URLs como entrada directa.

Eso es cómodo para descargar material online y luego hacer un rough cut automático. El punto práctico sigue siendo asegurarte de que los derechos y permisos de uso del material estén claros.

Para quién es mejor

Si tu trabajo depende mucho de ritmo narrativo, lenguaje de plano y juicio editorial humano, auto-editor no reemplaza la parte difícil.

Pero puede ahorrar tiempo si haces:

quitar pausas largas de una grabación de pantalla de una hora
eliminar silencios de una grabación hablada antes de editar
primer rough cut de cursos antes de subtítulos
procesar lotes de materiales largos con estructura similar

Su valor no es editar con mejor gusto que una persona. Es automatizar el primer paso más repetitivo.

Conclusión

auto-editor vale la pena no porque convierta edición en una caja negra mágica de AI, sino porque resuelve honestamente un problema estrecho: terminar más rápido el primer rough cut.

Si lo tratas como herramienta frontend para quitar silencios, recortar dead space y exportar timelines, su rol es claro:

no decide el gusto editorial final
encaja muy bien en el primer pase de metraje largo
complementa editores como Premiere y Resolve en lugar de reemplazarlos

Para tutoriales, screen recordings, talking-head y video largo, no es llamativa. Simplemente ahorra tiempo en trabajo repetitivo.

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.

Práctica de Hugo Shortcode: paquete-archivo (mantenga archivos y archivos adjuntos multilingües en un paquete de una página)

Sun, 29 Mar 2026 00:00:00 +0000

En sitios multilingües, las publicaciones suelen compartir los mismos archivos adjuntos (por ejemplo, PDF, archivos de configuración o scripts). Si cada versión de idioma mantiene enlaces de descarga manualmente, la pérdida de enlaces y los archivos perdidos se vuelven comunes con el tiempo.

Este artículo presenta un código corto de Hugo reutilizable, “bundle-file”, para resolver este problema.

Objetivo

Mantenga los archivos de publicaciones y archivos adjuntos multilingües en el mismo directorio del paquete de páginas, por ejemplo:

content/post/2026/03/09/01/
  index.zh-cn.md
  index.zh-tw.md
  index.en.md
  demo.pdf
  script.sh

Esto maximiza la reutilización y evita copias duplicadas. Después de que Hugo cree páginas HTML, todas las versiones de idiomas deben apuntar al mismo archivo adjunto en lugar de archivos duplicados.

Implementación de código corto

Archivo: layouts/shortcodes/bundle-file.html

{{- $name := .Get "name" -}}
{{- $text := .Get "text" | default $name -}}

{{- $res := .Page.Resources.GetMatch $name -}}
{{- if not $res -}}
  {{- range .Page.AllTranslations -}}
    {{- if not $res -}}
      {{- $tmp := .Resources.GetMatch $name -}}
      {{- if $tmp }}{{ $res = $tmp }}{{ end -}}
    {{- end -}}
  {{- end -}}
{{- end -}}

{{- if $res -}}
<a href="{{ $res.RelPermalink }}">{{ $text }}</a>
{{- else -}}
<span>Missing file: {{ $name }}</span>
{{- end -}}

bundle-file funciona con una estrategia simple:

Primero busque el archivo en los recursos de la página actual.
Si no lo encuentra, busque el mismo nombre de archivo en otras páginas traducidas.
Genere un enlace de descarga cuando lo encuentre o muestre un mensaje de archivo faltante cuando no lo encuentre.

Parámetros

name: nombre del archivo adjunto (obligatorio)
text: etiqueta del enlace (opcional); por defecto es nombre

Ejemplo de uso

`1`	`Missing file: demo.pdf`

Sin “texto”:

`1`	`Missing file: demo.pdf`

Lista de verificación previa a la publicación

Coloque archivos adjuntos y publicaciones en el mismo paquete de páginas.
Asegúrese de que “nombre” coincida exactamente con el nombre de archivo real (incluido el caso).
Haga clic en los enlaces en la vista previa local para confirmar la accesibilidad.

Resumen

bundle-file convierte el manejo de archivos adjuntos multilingües del mantenimiento manual de rutas a una búsqueda automática basada en reglas. Para bases de conocimientos y blogs técnicos de larga duración, esto reduce el riesgo de enlaces rotos y el tiempo de revisión previa al lanzamiento.

Cómo crear y utilizar habilidades: especificación y principios prácticos de SKILL.md

Sat, 28 Mar 2026 16:30:00 +0800

Este artículo se centra en dos preguntas:

¿Cómo debería escribirse y estructurarse SKILL.md?
¿Cómo creamos habilidades reutilizables, mantenibles y de alta calidad?

1. Especificación de HABILIDAD.md

SKILL.md es el archivo de descripción principal de una habilidad. Suele contener dos partes:

Portada de YAML: define metadatos de habilidades.
Cuerpo de Markdown: define la guía de ejecución y el flujo de trabajo práctico.

1.1 Ejemplo de portada

---
# === Required fields ===
name: skill-name
# Unique skill identifier; kebab-case is recommended

description: >
  Brief but precise description of:
  1) What this skill does
  2) When it should be used
  3) What its core value is
# Note: description is typically the key basis for skill selection

# === Optional fields ===
version: 1.0.0
allowed_tools: [tool1, tool2]
required_context: [context_item1]
license: MIT
author: Your Name <email@example.com>
tags: [database, analysis, sql]
---

1.2 Estructura corporal recomendada

# Skill Title

## Overview
(Skill summary, use cases, technical background)

## Prerequisites
(Runtime environment, dependencies, required permissions)

## Workflow
(Step-by-step guidance: input, process, output)

## Best Practices
(Experience-based tips, caveats, common pitfalls)

## Examples
(Typical cases for faster adoption)

## Troubleshooting
(Common issues and fixes)

2. Principios para escribir habilidades de alta calidad

Con base en la documentación oficial y la práctica comunitaria, se recomiendan los siguientes cuatro principios.

2.1 Mantenga la descripción precisa

La “descripción” es el punto de entrada clave para combinar habilidades. Debería:

Definir claramente el alcance; Evite palabras vagas como “ayuda con el procesamiento de datos”.
Incluya palabras clave desencadenantes para que coincidan con la intención del usuario.
Explicar el valor único y los límites de otras habilidades.

Ejemplo débil:

`1`	`description: Handle database queries`

Ejemplo más fuerte:

description: >
  Convert Chinese business questions into SQL queries and analyze the MySQL employees sample database.
  Suitable for employee info lookup, salary statistics, department analysis, and role-change history.
  Use this skill when users ask about employee, salary, or department data.

2.2 Diseño modular y responsabilidad única

Una habilidad debe centrarse en un dominio de tarea claramente definido. Si una sola habilidad intenta abarcar demasiado, a menudo conduce a:

Descripciones más amplias y menor precisión de coincidencia.
Instrucciones más largas y carga de contexto más pesada.
Mayores costes de mantenimiento e iteración.

En lugar de una habilidad de “análisis general”, divídala en habilidades especializadas, por ejemplo:

análisis-de-empleados-mysql
análisis-de-datos-de-ventas
análisis-de-comportamiento-de-usuario

2.3 El determinismo primero

Para tareas complejas que requieren precisión, prefiera la ejecución con script a la generación pura de LLM.

Por ejemplo, en escenarios de exportación de datos, en lugar de generar contenido binario de Excel directamente con un LLM, utilice un script dedicado. SKILL.md solo debe definir cuándo y cómo invocarlo.

2.4 Divulgación progresiva

Capa de información por importancia y frecuencia para reducir el uso de contexto innecesario:

Cuerpo SKILL.md: flujo de trabajo principal y patrones comunes
Documentos complementarios (por ejemplo, advanced.md): uso avanzado y casos extremos
Archivos de datos: datos de referencia de gran tamaño a los que se accede bajo demanda mediante scripts

Resumen

El objetivo de las habilidades de alta calidad no es escribir más, sino establecer límites más claros, mejores desencadenantes, ejecución estable y mantenimiento sostenible.

Comience con un SKILL.md estandarizado, luego combine la responsabilidad única con la divulgación progresiva para construir un sistema de habilidades más eficiente.

¿Qué son las habilidades de los agentes? Desde los principios de diseño hasta la optimización del contexto

Sat, 28 Mar 2026 00:00:00 +0000

Agent Skills es una forma estandarizada de empaquetar conocimientos procesales. En resumen, responde no sólo a “si existen herramientas” sino también a “cómo utilizarlas correcta y eficazmente”.

1. Principios básicos de diseño

El valor central de Agent Skills es que captura una metodología reutilizable:

Proporciona conocimiento del dominio para guiar cómo los agentes combinan e invocan herramientas en escenarios específicos.
Restringe las rutas de ejecución, reduciendo el ensayo y error y mejorando la coherencia.
Hace que los flujos de trabajo complejos sean reutilizables e iterativos, formando SOP estables a lo largo del tiempo.

Si la capacidad de la herramienta es como una interfaz de hardware, Skills se acerca más a un manual de operaciones más un manual de mejores prácticas, que define qué se debe hacer y cómo.

2. Divulgación progresiva: resolver el cuello de botella del contexto

La innovación clave en Agent Skills es la divulgación progresiva: cargue información solo cuando sea necesario, en lugar de enviar todo a la ventana contextual a la vez.

2.1 Capa 1: Metadatos

Cada habilidad generalmente se almacena en su propia carpeta, con SKILL.md como archivo principal. Este archivo comienza con la información preliminar de YAML que define la información básica de habilidades.

Al inicio, el agente lee solo la parte frontal de todas las habilidades e inyecta esos metadatos en el indicador del sistema. En la práctica:

Los metadatos de una habilidad cuestan alrededor de “100 tokens”.
50 habilidades cuestan alrededor de “5000 fichas”.

2.2 Capa 2: Instrucciones

Cuando una habilidad se considera muy relevante para la tarea actual, el agente lee el SKILL.md completo y carga instrucciones detalladas, notas y ejemplos.

El uso de tokens en esta capa depende de la complejidad de las instrucciones, normalmente:

1000 a 5000 tokens

2.3 Capa 3: Recursos adicionales (guiones y referencias)

Para habilidades más complejas, SKILL.md puede hacer referencia a scripts, archivos de configuración y documentos, que se cargan solo cuando es necesario.

Ejemplo de estructura de directorio:

skills/pdf-processing/
├── SKILL.md                 # Main skill file
├── parse_pdf.py             # PDF parsing script
├── forms.md                 # Form-filling guide (loaded only for form tasks)
└── templates/
    ├── invoice.pdf
    └── report.pdf

Patrón de invocación típico:

Ejecute parse_pdf.py cuando sea necesario analizar PDF
Cargue forms.md solo para tareas de llenado de formularios
Acceda a archivos de plantilla solo cuando genere formatos de salida específicos

3. Por qué funciona este diseño

3.1 Capacidad de conocimiento escalable

Con scripts y archivos externos, una habilidad puede llevar el conocimiento mucho más allá de los límites de la ventana contextual. Por ejemplo, una habilidad de análisis de datos puede incluir un conjunto de datos de “1 GB” más scripts de consulta, y el agente puede acceder a los datos mediante la ejecución en lugar de cargar todo el conjunto de datos en contexto.

3.2 Determinismo más fuerte

Delegar cálculos complejos, transformación de datos y análisis de formatos al código reduce significativamente la incertidumbre y el riesgo de alucinaciones en la generación de texto puro.

4. Impacto práctico: de 16k a 500 tokens

La práctica comunitaria muestra que la Divulgación Progresiva puede reducir drásticamente los gastos generales del contexto inicial:

Enfoque MCP tradicional: conéctese directamente a un servidor MCP con muchas definiciones de herramientas, alrededor de “16 000 tokens” en la inicialización
Con paquete de habilidades: use una habilidad de puerta de enlace liviana que se describe principalmente al principio, alrededor de “500 tokens” en la inicialización.

Las instrucciones detalladas y los recursos adicionales se cargan sólo cuando la tarea realmente los requiere. Esto reduce el costo inicial y mejora la precisión de la gestión del contexto durante la conversación.

Resumen

El valor clave de Agent Skills es pasar de “las herramientas están disponibles” a “las capacidades son reutilizables”. Con Progressive Disclosure, los sistemas pueden preservar la profundidad de la capacidad y al mismo tiempo optimizar significativamente el costo del token y la estabilidad de la ejecución.

Explicación de las diferencias entre IEEE 802.3af/at/bt (PoE)

Sat, 28 Mar 2026 00:00:00 +0000

IEEE 802.3af, 802.3at y 802.3bt son los tres estándares principales de PoE (alimentación a través de Ethernet). Sus diferencias clave son el presupuesto de energía, la cantidad de pares de cables utilizados para la entrega de energía y los tipos de dispositivos de destino.

Conclusiones rápidas

802.3af (PoE): Potencia máxima inferior (15,4W), apto para dispositivos básicos.
802.3at (PoE+): Potencia aumentada hasta 30W, adecuado para dispositivos de potencia media.
802.3bt (PoE++ / 4PPoE): Nivel de potencia más alto (Tipo 3 hasta 60W, Tipo 4 hasta 90W-100W), adecuado para dispositivos de alta potencia.

Comparación detallada

Estándar	Nombre común	Salida máxima de PSE	Potencia PD utilizable (aprox.)	Pares potenciados	Casos de uso típicos
IEEE 802.3af	PoE	15,4W	12,95W	2 pares	Teléfonos VoIP estándar, cámaras básicas
IEEE 802.3at	PoE+	30W	25,5W	2 pares	Cámaras IP HD, puntos finales de red avanzados
IEEE 802.3bt	PoE++/4PPoE	Tipo 3: 60W; Tipo 4: 90W-100W	Superior (depende del tipo)	4 pares	AP Wi-Fi 6/6E, terminales de videoconferencia, automatización de edificios

Notas estándar por estándar

IEEE 802.3af (PoE)

Potencia de salida máxima: 15,4 W (aproximadamente 12,95 W disponibles en PD)
Uso de pares: 2 de cada 4 pares trenzados
Escenarios típicos: cámaras heredadas, teléfonos VoIP estándar

IEEE 802.3at (PoE+)

Potencia de salida máxima: 30 W (aproximadamente 25,5 W disponibles en PD)
Uso de pares: 2 de cada 4 pares trenzados
Escenarios típicos: cámaras IP HD, puntos finales de vigilancia de red de gama alta

IEEE 802.3bt (PoE++/4PPoE)

Potencia de salida máxima: hasta 60 W para el tipo 3, hasta 90 W-100 W para el tipo 4
Uso de pares: los 4 pares para suministro de energía, lo que permite una mayor capacidad de energía
Escenarios típicos: AP inalámbricos de alta potencia, automatización de edificios, sistemas de videoconferencia

Compatibilidad

Los tres estándares son compatibles con versiones anteriores:

802.3bt es compatible con 802.3at y 802.3af
802.3at es compatible con 802.3af

A medida que evolucionan los estándares, la potencia disponible aumenta significativamente, lo que admite una gama más amplia de dispositivos terminales de alta potencia.

Conceptos erróneos comunes sobre las unidades WD HC620 SMR y cómo utilizarlas correctamente

Fri, 27 Mar 2026 00:00:00 +0000

Introducción: una nueva opción ante los crecientes costos de almacenamiento

El mercado de almacenamiento está atravesando un aumento de precios sin precedentes y los costos de almacenamiento han aumentado considerablemente para los consumidores habituales y los usuarios domésticos de NAS. Los discos duros de gran capacidad que antes costaban menos de 1.000 CNY ahora suelen costar el doble o incluso más, lo que los pone fuera del alcance de muchos usuarios preocupados por su presupuesto. Sin embargo, en este entorno de mercado, el HC620 es uno de los pocos productos cuyo precio no ha aumentado tan dramáticamente. Este artículo no trata sólo sobre el HC620; También se aplica a otras unidades SMR similares.

Conceptos erróneos comunes sobre el HC620

Mucha gente se preocupa sobre si el HC620 es seguro para el almacenamiento de datos, pero este es un error típico. El HC620 en sí es una unidad de nivel empresarial y la calidad de su hardware no es mala. La impresión de “inseguridad” suele deberse a malentendidos sobre las unidades SMR y a su uso en escenarios equivocados. Las unidades SMR no deben usarse para cargas de trabajo frecuentes de escritura y eliminación, ya que eso puede desencadenar la reorganización de datos, reducir el rendimiento e incluso causar bloqueos graves. Pero eso es una discrepancia en la carga de trabajo, no un defecto del producto. Es similar a los sistemas de cintas empresariales: funcionan bien cuando se usan para escritura y lectura secuenciales. Asimismo, HC620 es adecuado para escrituras secuenciales con lecturas aleatorias, pero no para cargas de trabajo pesadas de eliminación y escritura simultáneas. En el escenario correcto, el HC620 funciona muy bien.

Escenarios adecuados e inadecuados

Escenarios adecuados:

Copia de seguridad y archivado de datos en frío a gran capacidad
Bibliotecas de medios que se escriben una vez y luego se buscan/leen en línea (las lecturas son naturalmente búsquedas aleatorias, no lecturas secuenciales estrictas)

Escenarios inadecuados:

Cargas de trabajo con lecturas y escrituras frecuentes (bases de datos, descargas, espacios de trabajo activos)
No se admite el uso directo en sistemas operativos como Windows y macOS (el acceso basado en red está excluido de esta limitación)

Requisitos de uso para HC620

El mayor problema del HC620 es la comodidad: puede resultar difícil de usar, especialmente para principiantes.

Requisitos de hardware

No lo conecte a través de una caja de unidad USB.
La conexión directa a un puerto SATA de la placa base suele estar bien, pero las tarjetas de expansión pueden ser inconsistentes. Pueden ocurrir problemas de compatibilidad. LSI 9300 (SAS3008) puede funcionar después de actualizar el firmware IT/HBA. JMB585 tiene casos que funcionan y no funcionan, por lo que la compatibilidad es mixta.
Los adaptadores M.2 a SATA también son inconsistentes. Mi adaptador M.2 a JMB585 funciona, pero he visto muchos casos incompatibles, probablemente relacionados con diferencias de BIOS o firmware.

Requisitos de software

No compatible con Windows y macOS; compatible con Linux
Compatible con Feiniu NAS

Resumen

Para principiantes, el enfoque más sencillo es utilizar Feiniu NAS y montar el HC620 como almacenamiento externo, utilizando todo el disco para copias de seguridad o una biblioteca multimedia.

Para los usuarios cuya capacidad NAS está llena, transferir datos utilizados con menos frecuencia al HC620 también es una forma práctica de liberar espacio en el NAS.

Cómo los no programadores pueden dirigir la IA para que haga el trabajo: extraer diagramas y fórmulas matemáticas de una imagen (ejemplo práctico)

Thu, 26 Mar 2026 00:00:00 +0000

Requisitos previos

Instale VS Code y la extensión Codex. Puede consultar [este artículo] (../01/index.md).
El uso de estas herramientas no requiere experiencia en programación. En este flujo de trabajo, VS Code sirve principalmente para organizar archivos; usted describe su objetivo y la IA escribe y ejecuta el código por usted.
Esta publicación registra el proceso completo para generar ideas y ayudar a más personas a descubrir formas prácticas de utilizar la IA.

Objetivo

Prepare una imagen que contenga fórmulas matemáticas y diagramas ilustrativos:

Queremos lograr tres cosas:

Divida los diagramas en imágenes limpias y separadas.
Reconozca fórmulas y conviértalas a LaTeX para editarlas más fácilmente.
Vincula cada diagrama a su fórmula correspondiente.

Proceso

Primero, reconozca la imagen, genere un documento Markdown y convierta fórmulas a LaTeX.

Resultado de la conversión:

# 1.png Recognition Result

## Geometry Formulas (LaTeX)

1. Triangle area (side lengths and circumradius):

$$
S = \frac{abc}{4R}
$$

2. Triangle area (inradius and semiperimeter):

$$
S = pr
$$

3. Frustum volume:

$$
V = \frac{\pi\left(r^2 + Rr + R^2\right)h}{3}
$$

4. Frustum lateral surface area:

$$
S = \pi a(R + r)
$$

5. Cylinder volume:

$$
V = \pi r^2 h
$$

6. Cylinder lateral surface area:

$$
S = 2\pi rh
$$

7. Sphere volume:

$$
V = \frac{4}{3}\pi R^3
$$

8. Sphere surface area:

$$
S = 4\pi R^2
$$

9. Law of sines:

$$
\frac{a}{\sin A}=\frac{b}{\sin B}=\frac{c}{\sin C}=2R
$$

10. Law of cosines:

$$
a^2=b^2+c^2-2bc\cos A
$$

$$
b^2=a^2+c^2-2ac\cos B
$$

$$
c^2=a^2+b^2-2ab\cos C
$$

Se reconocieron todas las fórmulas y la IA incluso agregó nombres de fórmulas automáticamente, lo cual es genial. Sin embargo, los cultivos del diagrama pequeño aún no se generaron.

Intente pedirle a AI que recorte la imagen.

# 1.png Recognition Result (side-by-side layout with refined cropping)

<table>
  <tr>
    <td>![](crops/01_triangle_circum.png)</td>
    <td>

$$
S = \frac{abc}{4R}
$$

</td>
  </tr>
  <tr>
    <td>![](crops/02_triangle_incircle.png)</td>
    <td>

$$
S = pr
$$

</td>
  </tr>
  <tr>
    <td>![](crops/03_frustum.png)</td>
    <td>

$$
V = \frac{\pi\left(r^2 + Rr + R^2\right)h}{3}
$$

$$
S = \pi a(R + r)
$$

</td>
  </tr>
  <tr>
    <td>![](crops/04_cylinder.png)</td>
    <td>

$$
V = \pi r^2 h
$$

$$
S = 2\pi rh
$$

</td>
  </tr>
  <tr>
    <td>![](crops/05_sphere.png)</td>
    <td>

$$
V = \frac{4}{3}\pi R^3
$$

$$
S = 4\pi R^2
$$

</td>
  </tr>
  <tr>
    <td>![](crops/06_laws.png)</td>
    <td>

$$
\frac{a}{\sin A}=\frac{b}{\sin B}=\frac{c}{\sin C}=2R
$$

$$
a^2=b^2+c^2-2bc\cos A
$$

$$
b^2=a^2+c^2-2ac\cos B
$$

$$
c^2=a^2+b^2-2ab\cos C
$$

</td>
  </tr>
</table>

Resultado: Los diagramas fueron recortados y colocados en posiciones coincidentes, pero los cultivos aún incluyen ruido de áreas cercanas.

Corrija el recorte excesivo: mantenga primero el área objetivo completa y luego elimine manualmente las partes adicionales
El resultado aún es inconsistente en este paso. Aún no está claro si el problema proviene de las indicaciones o de la variabilidad del modelo en la localización visual.

Resumen

Usar Codex es diferente a chatear directamente en chatgpt.com.
En chatgpt.com, a menudo parece que la IA guía su trabajo; en Codex, se siente más como si la IA estuviera ejecutando sus instrucciones.
Después de describir sus requisitos, la IA puede generar código, ejecutarlo y completar la tarea. La sensación es que estás dirigiendo a la IA para que haga el trabajo.
Este proceso no requiere grandes habilidades de programación y los no programadores aún pueden obtener resultados reales paso a paso.

Cómo utilizar Codex en VS Code (desde la configuración hasta un flujo de trabajo eficiente en el mundo real)

Fri, 20 Mar 2026 00:00:00 +0000

Codex puede ayudarlo a escribir código, corregir errores, comprender proyectos y ejecutar comandos directamente desde la barra lateral de VS Code.

1. Preparación

Antes de comenzar, asegúrese de:

VS Code se actualiza a una versión estable reciente.
Puedes acceder a los servicios de OpenAI con normalidad.
Su proyecto se abre localmente (preferiblemente en un repositorio Git).

2. Instale la extensión

Abra el panel Extensiones de VS Code.
Busque e instale: Codex - Codex - Agente de codificación de OpenAI.
Complete el flujo de inicio de sesión/autorización.

3. Abra la barra lateral del Códice

Puedes abrirlo de cualquier forma:

Haga clic en “Abrir barra lateral del Codex” en el área superior derecha del editor.
Utilice la paleta de comandos (Ctrl + Shift + P), busque Codex y ábralo.

Después de abrir, Codex lee el contexto del espacio de trabajo actual y está listo para conversar.

4. Patrones de uso comunes

4.1 Pídale que explique el código

Mensaje de ejemplo:

1
2

Please explain the core logic of this file,
and point out the 3 areas most likely to fail.

Excelente para comprender rápidamente el código heredado.

4.2 Pídale que implemente funciones

Mensaje de ejemplo:

1
2
3

Add a /healthz endpoint to the existing API.
It should return app version and database connectivity status,
and include basic tests.

Si establece claramente las restricciones y los criterios de aceptación, la calidad del resultado suele ser mucho más estable.

4.3 Pídale que solucione problemas

Mensaje de ejemplo:

1
2
3

This endpoint intermittently returns 500 under concurrency.
First identify the root cause, then propose a minimal-change fix,
and finally list regression test points.

“Diagnosticar primero, luego corregir” ayuda a reducir la refactorización excesiva accidental.

5. Plantilla de aviso de alta calidad

Puedes reutilizar esta plantilla directamente:

Background: This is a <tech stack> project. Current goal: <goal>
Constraints: Do not modify <module/interface>; keep compatibility with <version/platform>
Output:
1) File list to change
2) Key code explanation
3) Validation steps
4) Risks and rollback plan

Esto es especialmente útil para proyectos grandes y colaboración en equipo.

6. Preguntas frecuentes

6.1 Acerca de la cuota gratuita

Escriba \ en el cuadro de entrada, luego elija el estado para ver información relacionada con la cuota/tiempo de reinicio.

6.2 Los cambios no son los esperados

Una vez generados los cambios, abra el panel de revisión para inspeccionar los detalles. Si no está satisfecho, utilice deshacer/revertir. Puede dividir requisitos grandes en pasos más pequeños y ejecutarlos de forma incremental. Utilice Git y mantenga pequeñas confirmaciones para una reversión más sencilla.

Panorama de API de LLM (opciones gratuitas y rentables)

Thu, 12 Feb 2026 00:00:00 +0000

API de Google Gemini (mejor nivel gratuito)

Para promocionar la línea Gemini, Google ofrece actualmente una de las cuotas gratuitas más generosas. Precios/detalles: https://ai.google.dev/gemini-api/docs/pricing?hl=zh-cn

Modelos: Gemini 3 Flash Preview, Gemini 2.5 Pro (a partir del 12 de febrero de 2026). En general, el modelo Pro de gama alta más nuevo puede tener límites gratuitos más estrictos, mientras que muchos otros modelos aún ofrecen uso gratuito.

Ventajas:

Incluso los modelos de primer nivel pueden incluir cuota gratuita.
Ventana de contexto muy grande (más de 1 millón de tokens).
Fuerte soporte multimodal (entrada de imagen/vídeo).

Contras:

Privacidad de datos: Google puede utilizar entradas de nivel gratuito para mejorar los modelos (úselo con precaución en producción).
Restricciones de propiedad intelectual: política regional estricta; Las ubicaciones no admitidas pueden marcar “403” o “Ubicación del usuario no admitida”.

Groq (Rey de la velocidad)

Groq utiliza su hardware LPU (Unidad de procesamiento de lenguaje) de desarrollo propio y proporciona una inferencia extremadamente rápida. Precios/detalles: https://groq.com/pricing

Modelos: GPT OSS / Kimi K2 / Llama 3,4 / Qwen3 Cuota: Sin nivel gratuito, pero precio relativamente bajo.

Ventajas:

Muy baja latencia; El TTFT suele estar dentro de los 200 ms.
Ideal para chat en tiempo real y asistentes de voz.

Contras:

El alcance del modelo es en su mayoría modelos de código abierto; no hay GPT-4 o Claude alojados directamente.

SiliconCloud (opción nacional sólida)

Una plataforma de inferencia de rápido crecimiento con sede en China que agrega muchos modelos nacionales de código abierto de alta calidad. Precios/detalles: https://siliconflow.cn/pricing

Modelos: Qwen 2.5 (7B/14B/72B), DeepSeek-V2, Yi-1.5, Kimi K2. Cuota: Algunos modelos (por ejemplo Qwen 7B, GLM-4-9B) actualmente ofrecen llamadas gratuitas permanentes.

Ventajas:

Rápida conectividad doméstica.
Los nuevos modelos nacionales de código abierto suelen estar disponibles rápidamente.

Contras:

El acceso gratuito es principalmente para modelos más pequeños.
Los modelos de gama alta (como el 72B / DeepSeek 236B) suelen ser de pago.

OpenWrt en JDCloud AX6600 Athena: mueva el puerto 2.5G a LAN e intercambie WAN/LAN1

Mon, 19 Jan 2026 00:00:00 +0000

Introducción

El JDCloud Wireless Treasure AX6600 Athena tiene un puerto 2.5G. En las compilaciones LEDE/libwrt de OpenWrt, este puerto suele estar configurado como WAN de forma predeterminada. En muchos escenarios de laboratorio doméstico, es más útil como puerto LAN interno para conectar NAS y otros servidores locales. Este artículo muestra un enfoque práctico basado en DTS.

Método

La interfaz de usuario web de OpenWrt generalmente no puede reasignar directamente esta asignación de WAN/LAN. Puedes hacerlo editando el archivo DTS.

Intercambie lan1 y wan:

Before:
	switch_lan_bmp = <(ESS_PORT1 | ESS_PORT2 | ESS_PORT3 | ESS_PORT4)>;
	switch_wan_bmp = <ESS_PORT5>;
  ...
  &dp1 {
	status = "okay";
	phy-handle = <&qca8075_24>;
	label = "lan1";
  };
  ...
  &dp5 {
    status = "okay";
    phy-handle = <&qca8081>;
    label = "wan";
  };

After:
	switch_lan_bmp = <(ESS_PORT5 | ESS_PORT2 | ESS_PORT3 | ESS_PORT4)>;
	switch_wan_bmp = <ESS_PORT1>;
  ...
  &dp1 {
    status = "okay";
    phy-handle = <&qca8075_24>;
    label = "wan";
  };
  ...
  &dp5 {
    status = "okay";
    phy-handle = <&qca8081>;
    label = "lan1";
  };

Descargas DTS (Antes/Después)

Archivos DTS libwrt: Before: ipq6010-re-cs-02.dts
After: ipq6010-re-cs-02.dts
Archivos LEDE DTS: Before: ipq6010-re-cs-02.dts
After: ipq6010-re-cs-02.dts

Guía GNU C `atributo`

Fri, 13 Jun 2025 00:00:00 +0000

Sintaxis

`1`	`__attribute__((attribute-list))`

attribute-list es una lista de atributos separados por comas.

Atributos comunes

`empaquetado`

Elimina el relleno de la estructura predeterminada y minimiza los espacios de alineación.

struct __attribute__((packed)) packed_str {
    uint8_t x;
    uint16_t y;
};

Úselo con cuidado: el acceso no alineado puede reducir el rendimiento o causar fallas en algunas arquitecturas.

`alineado(n)`

Fuerza la alineación del objeto a n bytes.

`1`	`int buf[16] __attribute__((aligned(64)));`

`sección("nombre")`

Coloca la variable/función en una sección del vinculador personalizado.

`1`	`const char fw_ver[] __attribute__((section(".fwinfo"))) = "1.0.0";`

`sin usar`

Suprime las advertencias no utilizadas.

`1`	`static void helper(void) __attribute__((unused));`

`débil`

Declara un símbolo débil (puede anularse mediante una definición fuerte).

`1`	`void board_init(void) __attribute__((weak));`

`sin retorno`

Función de marcas que nunca regresa.

`1`	`void fatal_error(void) __attribute__((noreturn));`

Notas

__attribute__ es específico del compilador (compatible con GCC/Clang en muchos casos).
Prefiere macros para mayor portabilidad cuando apunta a múltiples compiladores.

Inicialización de estructura C y campos de caracteres/cadenas

Fri, 13 Jun 2025 00:00:00 +0000

Inicialización posicional en la declaración

struct InitMember {
    int first;
    double second;
    char *third;
    float four;
};

struct InitMember test = { -10, 3.141590, "method one", 0.25f };

El orden importa en la inicialización posicional.

Asignación después de la declaración

struct InitMember test;

test.first = -10;
test.second = 3.141590;
test.third = "method two";
test.four = 0.25f;

Inicializadores designados (recomendados para facilitar la lectura)

struct InitMember test = {
    .first = -10,
    .second = 3.141590,
    .third = "method three",
    .four = 0.25f
};

Notas para miembros de cadena

char * apunta a una cadena literal o a una memoria asignada dinámicamente.
Si se requiere almacenamiento grabable, use char array[N] y copie el contenido.
Tenga cuidado con la vida útil y la mutabilidad de las cuerdas puntiagudas.

Repare pyOCD que no detecta algunas sondas DAPLink en Ubuntu

Thu, 17 Apr 2025 00:00:00 +0000

Hardware y firmware DAPLink

Equipo: https://oshwhub.com/xivn1987/daplink
Firmware: https://github.com/XIVN1987/DAPLink/tree/master

También pueden ocurrir problemas similares en otras compilaciones de firmware DAPLink personalizadas o no oficiales.

Síntoma

pyocd list puede mostrar una sonda desconocida o ninguna sonda:

`1`	`pyocd list`

A veces solo aparece J-Link o no se informan sondas disponibles, mientras que el mismo DAPLink todavía funciona en Keil.

Reparar pasos

Compruebe si el dispositivo USB está visible:

lsusb

Si se detecta correctamente, debería ver algo como “XIVN1987 XV-Link CMSIS-DAP”.

Configurar reglas de udev Referencia: https://github.com/pyocd/pyOCD/tree/main/udev

Repositorio de clones:

`1`	`git clone https://github.com/pyocd/pyOCD.git`

Las reglas están en:

1
2

cd pyOCD/udev/
ls -l

Para esta sonda personalizada, agregue una regla explícita (o agréguela a 50-cmsis-dap.rules):

1
2

# 2e3c:5021 XIVN1987 XV-Link CMSIS-DAP
SUBSYSTEM=="usb", ATTR{idVendor}=="2e3c", ATTR{idProduct}=="5021", MODE:="666"

Los ID de proveedor/producto deben coincidir con la salida lsusb.

Copie el archivo de reglas actualizado en /etc/udev/rules.d, luego vuelva a cargarlo:

1
2

sudo udevadm control --reload
sudo udevadm trigger

Después de eso, ejecuta:

`1`	`pyocd list`

Ahora debería ver la sonda DAPLink listada correctamente.

Comprimir documentos de Microsoft Office Word (.docx)

Mon, 14 Apr 2025 00:00:00 +0000

Estructura del archivo DOCX

Un archivo .docx es esencialmente un paquete ZIP que contiene documentos XML y recursos multimedia:

[Content_Types].xml define los tipos de contenido
Los archivos .rels definen relaciones
word/document.xml almacena el contenido del documento principal
word/styles.xml almacena estilos
word/numbering.xml almacena definiciones de lista

Si cambia el nombre de .docx a .zip, puede extraer e inspeccionar la estructura del directorio.

Cómo comprimir DOCX

Los archivos DOCX grandes suelen estar dominados por archivos bajo “word/media”, por lo que la compresión debe centrarse allí.

Por el momento, la compatibilidad DOCX para formatos de imagen más nuevos puede estar limitada en algunos flujos de trabajo, por lo que los formatos comunes como JPG/PNG suelen ser más seguros.

1. Descomprimir

Cambie el nombre de la extensión a ZIP y extráigala, o use Python:

def unzip(file):
    docname = file[0:-5]
    if os.path.exists(docname):
        print('os.path.exists! remove!')
        shutil.rmtree(docname)

    with pyzipper.PyZipFile(file, "r") as zf:
        zf.extractall(docname)

2. Comprimir JPG/PNG

Puede comprimir imágenes directamente. Caesium proporciona buenos resultados de compresión a través de CLI.

def compress_image(input_path: str, quality: int = 80):
    command = 'caesiumclt.exe --same-folder-as-input --quality ' + str(quality) + ' ' + input_path
    print(command)

    try:
        os.system(command)
    except Exception as e:
        logging.error(f"An error occurred: {str(e)}")

En la práctica:

calidad=50 a menudo proporciona una fuerte reducción de tamaño con una calidad aceptable.
Incluso “calidad = 80” puede reducir notablemente el tamaño.

3. Manejar archivos EMF

Los archivos EMF suelen ser grandes. Convertir EMF a JPG/PNG puede reducir el tamaño significativamente. Puede usar ImageMagick para la conversión y luego actualizar word/_rels/document.xml.rels si la extensión/ruta del archivo cambia.

4. Reempacar

Vuelva a comprimir la carpeta extraída usando ZIP_DEFLATED.

def zip(folder, zipfile):
    print('zip:', folder, ' -> ', zipfile)
    with pyzipper.PyZipFile(zipfile, "w", compression=pyzipper.ZIP_DEFLATED) as zf:
        for root, dirs, files in os.walk(folder):
            for file in files:
                abs_path = os.path.join(root, file)
                rel_path = os.path.relpath(abs_path, folder)
                zf.write(abs_path, rel_path)

    shutil.rmtree(folder)

5. Ejemplo de script de un extremo a otro

def compress_docx(indir, outdir):
    for root, dirs, files in os.walk(indir):
        for file in files:
            if file.endswith('.docx'):
                docfile = os.path.join(root, file)
                unzip(docfile)
                docname = file[0:-5]
                imgpath = os.path.join(root, docname, 'word/media/')
                compress_image(imgpath, 50)

                outfolder = os.path.join(outdir, os.path.relpath(root, indir))
                if not os.path.exists(outfolder):
                    os.mkdir(outfolder)
                zip(os.path.join(root, docname), os.path.join(outfolder, file))

Resumen

Con este enfoque y “calidad = 50”, los archivos DOCX a menudo se pueden reducir a aproximadamente un tercio del tamaño original.

JTAG frente a SWD: pros y contras

Mon, 07 Apr 2025 00:00:00 +0000

JTAG (Joint Test Action Group) y SWD (Serial Wire Debug) son interfaces de depuración comunes en el desarrollo integrado. Este artículo compara sus características, ventajas, limitaciones y escenarios de uso.

JTAG: interfaz de depuración tradicional

Conceptos básicos de JTAG

JTAG es una interfaz estandarizada ampliamente utilizada para depuración y pruebas integradas. Por lo general, se implementa como una interfaz de señales múltiples, que comúnmente incluye “TCK” (reloj), “TMS” (selección de modo), “TDI” (entrada de datos) y “TDO” (salida de datos). A través del control de la máquina de estado, JTAG se puede utilizar para acceso a registro/memoria y diversas operaciones de depuración.

Ventajas de JTAG

Amplio soporte: muchos chips y herramientas integrados brindan soporte JTAG maduro.

Amplias capacidades: JTAG generalmente proporciona potentes funciones de depuración y escaneo de límites.

Adecuado para sistemas complejos: especialmente útil para cadenas de múltiples dispositivos y depuración avanzada a nivel de placa.

Limitaciones de JTAG

Mayor complejidad: la implementación del cableado y del hardware suele ser más compleja.

Compensaciones de velocidad: el rendimiento práctico puede ser limitado en comparación con enfoques de depuración en serie más livianos en algunos escenarios.

SWD: interfaz de depuración en serie más sencilla y eficiente

Conceptos básicos del SWD

SWD es una interfaz de depuración más nueva diseñada para simplificar el cableado de depuración tradicional y mejorar la eficiencia. Utiliza principalmente menos líneas de señal (por ejemplo, SWDIO, SWCLK y línea de reinicio), y al mismo tiempo admite flujos de trabajo de depuración principales.

Ventajas del SWD

Menor número de pines: menos cables, diseño de placa más simple, integración más sencilla.

Comunicación eficiente: en muchos casos prácticos, la interacción de depuración de SWD es rápida y conveniente.

Menores gastos generales: una señalización y un cableado más simples pueden reducir la carga de implementación.

Limitaciones del SWD

Alcance de la compatibilidad: SWD es común en las MCU modernas, pero es posible que algunos chips antiguos/heredados no lo admitan.

Alcance de la función: para algunos escenarios de cadena compleja o escaneo de límites avanzado, es posible que SWD no tenga tantas funciones como JTAG.

JTAG vs SWD: cómo elegir

Soporte de hardware

Compruebe si el chip de destino admite JTAG, SWD o ambos. Si sólo se admite uno, esa es la opción práctica.

Requisitos de depuración

Si prefiere un cableado más simple y una depuración diaria rápida, SWD suele ser la mejor opción.
Si necesita un control de bajo nivel más completo y funciones de depuración complejas, suele preferirse JTAG.

Complejidad del sistema

Para sistemas complejos (por ejemplo, cadenas de múltiples dispositivos o placas relacionadas con FPGA), JTAG suele ser más flexible.

Costo y complejidad de la implementación

SWD tiende a ser más fácil de implementar en diseños sensibles a los costos o con recursos limitados.

Soporte de cadena de herramientas

Asegúrese de que su depurador/programador y su cadena de herramientas de software sean compatibles con la interfaz seleccionada.

Resumen

Tanto JTAG como SWD son importantes interfaces de depuración integradas, cada una con claras compensaciones. En la práctica, seleccione según la compatibilidad del chip objetivo, la profundidad de depuración requerida, la complejidad del sistema y las limitaciones de las herramientas.

Conceptos básicos y plantillas prácticas de CMake

Fri, 28 Mar 2025 00:00:00 +0000

¿Qué es CMake?

CMake es un generador de sistemas de compilación multiplataforma. Escribe CMakeLists.txt una vez y luego genera archivos de compilación específicos de la plataforma (Makefile, archivos Ninja, proyectos de Visual Studio y más).

En Linux, un flujo de trabajo típico es:

Escriba CMakeLists.txt
Generar sistema de construcción
Construir

mkdir build
cd build
cmake ..
make

Plantilla 1: archivo de origen único

cmake_minimum_required(VERSION 3.5)
project(Demo1)

add_executable(demo1 test01.cpp)

Plantilla 2: múltiples archivos fuente

cmake_minimum_required(VERSION 3.5)
project(Demo2)

add_executable(demo2 main.cpp utils.cpp)

Plantilla 3: Incluir directorios + bibliotecas

cmake_minimum_required(VERSION 3.5)
project(Demo3)

include_directories(include)
add_executable(demo3 src/main.cpp src/foo.cpp)
target_link_libraries(demo3 pthread)

Estructura de proyecto recomendada

project/
  CMakeLists.txt
  src/
  include/
  build/

Consejos

Mantenga compilaciones fuera de la fuente (build/) para evitar contaminar el árbol fuente.
Utilice los comandos target_* (target_include_directories, target_link_libraries) para un estilo CMake moderno.
Fije una versión mínima de CMake para evitar sorpresas de compatibilidad.

STM32/PY32 GPIO: 8 modos de entrada/salida explicados

Tue, 18 Mar 2025 00:00:00 +0000

GPIO 8 modos comunes

GPIO (entrada/salida de uso general) se utiliza para interactuar con circuitos externos. En STM32/PY32, los modos comunes incluyen:

entrada flotante
entrada pull-up
entrada desplegable
entrada analógica
salida push-pull
salida de drenaje abierto
función alternativa push-pull
drenaje abierto de función alternativa

Modos de entrada

Entrada flotante (`GPIO_Mode_IN_FLOATING`)

El pasador es de alta impedancia y no está tirado hacia arriba o hacia abajo internamente. Los circuitos externos determinan el nivel.

GPIO_InitStruct.Pin = GPIO_PIN_0;
GPIO_InitStruct.Mode = GPIO_MODE_INPUT;
GPIO_InitStruct.Pull = GPIO_NOPULL;
HAL_GPIO_Init(GPIOA, &GPIO_InitStruct);

Entrada pull-up (`GPIO_Mode_IPU`)

La resistencia pull-up interna mantiene alto el nivel predeterminado.

Entrada desplegable (`GPIO_Mode_IPD`)

La resistencia desplegable interna mantiene bajo el nivel predeterminado.

Modos de salida

Salida push-pull

Puede conducir activamente tanto en niveles altos como bajos. Bueno para salida digital general.

Salida de drenaje abierto

Puede bajar activamente; alto nivel proporcionado típicamente por una resistencia pull-up. Útil para bus compartido (por ejemplo, señalización tipo I2C).

Modo analógico

El modo analógico desconecta la ruta de entrada/salida digital y se utiliza para señales ADC/analógicas.

Consejos prácticos de selección

Entrada de botón: pull-up o pull-down.
LED/pin de control general: salida push-pull.
Cableado-Y/línea compartida: desagüe abierto + pull-up.
Pin ADC: modo analógico.

Instale y use pyOCD + J-Link en Ubuntu 24.04

Mon, 17 Mar 2025 00:00:00 +0000

Dispositivo J-Link utilizado

Esta configuración utiliza sondas de depuración (SWD) compatibles con J-Link OB de bajo costo.

Instalación

1. Instale el paquete J-Link

Descargue el paquete Linux .deb desde: https://www.segger.com/downloads/jlink/

2. Instalar ayudantes de tiempo de ejecución de Python

1
2
3

sudo apt install python-is-python3
sudo apt install pipx
pipx ensurepath

3. Instale pyOCD

`1`	`pipx install pyocd`

4. Verificar la detección de la sonda

`1`	`pyocd list`

Uso común

Listar objetivos

`1`	`pyocd list --targets`

firmware flash

`1`	`pyocd load firmware.elf`

Abrir servidor GDB

`1`	`pyocd gdbserver`

Solución de problemas

Si pyocd list no muestra ninguna sonda, verifique el permiso USB/las reglas udev.
Si aparece J-Link pero falla la conexión del objetivo, verifique el cableado del SWD y la alimentación del objetivo.
Intente reducir el reloj SWD cuando la calidad de la señal sea deficiente.

Compresión Python: cree archivos cifrados en ZIP y 7z

Sun, 09 Feb 2025 00:00:00 +0000

Compresión de formato ZIP

import pyzipper

with pyzipper.AESZipFile(dest + '.zip', "w", encryption=pyzipper.WZ_AES) as zf:
    zf.setpassword(b"password")
    for file in os.listdir(dest):
        fullfile = os.path.join(dest, file)
        zf.write(fullfile, file)

importar pyzipper vs importar archivo zip
pyzipper es mayoritariamente compatible con API con zipfile.
zipfile puede usar contraseñas principalmente al extraer, pero no admite la creación de archivos ZIP cifrados con AES. pyzipper admite la creación de archivos ZIP cifrados.
zf.write(ruta1, ruta2)
path1: ruta del archivo fuente para comprimir
path2: ruta dentro del archivo ZIP
pyzipper.AESZipFile
Parámetros relacionados con el cifrado
encryption=pyzipper.WZ_AES (cifrado AES)
zf.setpassword(b"contraseña") (establecer contraseña)

Compresión de formato 7z

import py7zr

with py7zr.SevenZipFile(dest + '.7z', 'w', password='password') as archive:
    archive.writeall(dest, '')

archivo.writeall(ruta1, ruta2)
path1: ruta de origen para comprimir (puede ser un directorio)
path2: ruta de destino dentro del archivo 7z; '' significa raíz del archivo
Parámetro de cifrado
contraseña='contraseña'

Transcodificación FFmpeg H.265: diferentes codificadores, comparación de velocidad de software y hardware

Fri, 07 Feb 2025 00:00:00 +0000

Lista de codificadores disponibles

`1`	`ffmpeg -encoders`

Para H.265, las opciones comunes incluyen:

Software: libx265
NVIDIA: hevc_nvenc
Sincronización rápida Intel: hevc_qsv -AMD AMF: hevc_amf

Plantillas de comandos típicas

Codificación de software (CPU, mayor control de calidad)

`1`	`ffmpeg -i input.mp4 -c:v libx265 -preset medium -crf 28 -c:a copy output_x265.mp4`

Codificación de hardware NVIDIA

`1`	`ffmpeg -i input.mp4 -c:v hevc_nvenc -preset p5 -cq 28 -c:a copy output_nvenc.mp4`

Sincronización rápida Intel

`1`	`ffmpeg -i input.mp4 -c:v hevc_qsv -global_quality 28 -c:a copy output_qsv.mp4`

AMD AMF

`1`	`ffmpeg -i input.mp4 -c:v hevc_amf -quality quality -rc cqp -qp_i 28 -qp_p 28 -c:a copy output_amf.mp4`

Resumen de comparación

Software (libx265): normalmente mejor eficiencia de compresión y ajuste de calidad, pero más lento.
Codificadores de hardware: mucho más rápidos, menor uso de CPU, ideales para necesidades de conversión por lotes/en tiempo real.
La mejor elección depende de su objetivo:
- calidad del archivo: prefiera libx265
- rendimiento rápido: prefiera codificador de hardware

Consejos de evaluación comparativa

Mantenga constante la fuente de entrada, la resolución y la tasa de bits/calidad de destino.
Compare tanto la velocidad (fps) como el tamaño de salida/calidad visual.
Pruebe varios ajustes preestablecidos antes de decidir los valores predeterminados de producción.

Ubuntu + LSI: verifique el estado de la unidad con smartctl, localice unidades con storcli64 y realice un intercambio en caliente seguro

Fri, 24 Jan 2025 00:00:00 +0000

Verifique el estado de la unidad con smartctl

Instalar smartctl

1
2

sudo apt update
sudo apt install smartmontools

Verifique los puntos de montaje y el mapeo de dispositivos

df

Leer información SMART para conducir

`1`	`sudo smartctl -a /dev/sda`

Utilice storcli64 para asignar ranuras y unidades físicas

Para tarjetas LSI/Broadcom RAID/HBA, storcli64 ayuda a mapear:

unidad virtual/dispositivo de bloqueo del sistema operativo
ID de gabinete e ID de ranura
serie/modelo/estado de la unidad física

Comandos comunes:

storcli64 show
storcli64 /c0 show
storcli64 /c0 /eall /sall show
storcli64 /c0 /vall show all

Flujo de trabajo de reemplazo de intercambio en caliente seguro

Identifique la unidad fallida por ID de ranura.
Confirme el estado de la matriz y el disco virtual afectado.
Si es necesario, primero marque el disco de destino como fuera de línea.
Reemplace físicamente el disco (chasis/plano posterior compatible con intercambio en caliente).
Confirme que se detecte un disco nuevo.
Inicie o supervise la reconstrucción.

Comandos de ejemplo:

# Show all physical disks
storcli64 /c0 /eall /sall show

# Show rebuild status
storcli64 /c0 /vall show rebuild

# Show detailed drive status
storcli64 /c0 /e<enclosure> /s<slot> show all

Notas

Verifique siempre la ranura antes de sacar cualquier disco.
Evite reemplazar la unidad incorrecta en matrices degradadas.
Mantener implementados los procedimientos de ventana de respaldo y mantenimiento.

Solucionar problemas de reconexión automática de OpenWrt WireGuard

Sun, 19 Jan 2025 00:00:00 +0000

Solución alternativa de reconexión automática de OpenWrt WireGuard

Cuando se utiliza WireGuard en OpenWrt con DNS dinámico, un cambio de IP de un par puede dejar el túnel obsoleto después de muchas horas. En algunos entornos no se recupera automáticamente y requiere un reinicio manual.

Método 1: script personalizado

#!/bin/sh

if ! ping -c 3 <peer-wg-ip> > /dev/null 2>&1 ; then
  echo "The WireGuard is down! Now try restarting wg0!" >> ./ddns-wg0.log
  ifdown wg0
  sleep 3
  ifup wg0
fi

Método 2: script de vigilancia OpenWrt integrado

OpenWrt incluye /usr/bin/wireguard_watchdog (el contenido se omite aquí por brevedad). Comprueba la actividad del protocolo de enlace entre pares y puede volver a resolver los nombres de host de los puntos finales cuando un par está inactivo durante demasiado tiempo.

Ejecutado por cron

Utilice cron para ejecutar el mecanismo de vigilancia periódicamente.

A través de la interfaz de usuario web

Abra Sistema -> Tareas programadas.
Agregue:

`1`	`* * * * * /usr/bin/wireguard_watchdog`

A través de SSH

SSH en OpenWrt.
Ejecute crontab -e.
Agregue:

`1`	`* * * * * /usr/bin/wireguard_watchdog`

Guarde y reinicie cron si es necesario.

Solucionar el error de vgextend: los dispositivos tienen tamaños de bloques lógicos inconsistentes

Fri, 17 Jan 2025 00:00:00 +0000

Por qué ocurre este error

Esto suele ocurrir cuando el nuevo disco agregado por vgextend tiene un tamaño de bloque lógico diferente al de los discos que ya están en el VG.

Ejemplo:

Los discos VG existentes utilizan sectores lógicos de 512 bytes.
El dispositivo recién agregado utiliza sectores lógicos 4K

Entonces vgextend puede fallar con este error.

Solución 1: habilite tamaños de bloques mixtos en lvm.conf

Edite /etc/lvm/lvm.conf y configure:

`1`	`allow_mixed_block_sizes=1`

Discusión de referencia:
https://serverfault.com/questions/1150643/is-it-safe-to-use-allow-mixed-block-sizes-1-in-lvm-when-using-ext4-with-4k-blo

Solución 2: hacer que los tamaños de los bloques sean consistentes

Ajuste los tamaños de los bloques lógicos del dispositivo para que todos los discos del VG utilicen una configuración coherente.

Comprobar el tamaño del bloque lógico

`lsblk`

`1`	`lsblk -td`

PHY-SEC es el tamaño del sector físico, LOG-SEC es el tamaño del sector lógico.

`sysfs`

1
2

cat /sys/class/block/sda/queue/physical_block_size
cat /sys/class/block/sda/queue/logical_block_size

`fdisco`

`1`	`sudo fdisk -l /dev/sda`

Mire “Tamaño del sector (lógico/físico)”.

`smartctl` (NVMe)

`1`	`sudo smartctl -a /dev/nvme0n1`

Marque “Tamaños LBA admitidos”; + indica el formato LBA seleccionado actualmente.

Cambiar LBA/tamaño de bloque lógico

Advertencia: formatear o cambiar la configuración de LBA puede destruir datos.

Para HDD SATA (si es compatible)

Verifique los tamaños de sector admitidos:

`1`	`sudo hdparm -I /dev/sdX \| grep 'Sector size:'`

Si es compatible, cambie a 4K (ejemplo):

`1`	`hdparm --set-sector-size 4096 --please-destroy-my-drive /dev/sdX`

Verificar:

`1`	`hdparm -I /dev/sdX \| grep 'Sector size:'`

Para SSD NVMe

Verifique los formatos LBA admitidos:

`1`	`sudo nvme id-ns -H /dev/nvme0n1 \| grep "Relative Performance"`

`1`	`smartctl -c /dev/nvme0n1`

Formato para apuntar al formato LBA (ejemplo):

`1`	`nvme format --lbaf=1 /dev/nvme0n1`

lbaf corresponde al ID de formato. Esta operación borrará los datos y luego requerirá pasos de reinicio/reinicialización.

Usando LVM para administrar discos en Ubuntu

Fri, 17 Jan 2025 00:00:00 +0000

¿Qué es LVM?

LVM (Logical Volume Manager) es un mecanismo de Linux para administrar particiones de disco. Inserta una capa lógica entre los discos físicos y los sistemas de archivos, de modo que el espacio en disco se puede asignar y ajustar de manera más flexible.

Flujo de trabajo típico de LVM:

Inicializar discos como volúmenes físicos (PV)
Combinar PV en un grupo de volumen (VG)
Crear volúmenes lógicos (LV) dentro del VG.
Crear sistemas de archivos en LV
Montaje y uso

Con LVM, un sistema de archivos puede abarcar varios discos y cambiar su tamaño dinámicamente.

Conceptos básicos de LVM

Medios físicos: dispositivos de almacenamiento subyacentes como /dev/sda, /dev/nvme0n1.
Volumen físico (PV): un disco/partición inicializado para LVM.
Grupo de volumen (VG): un conjunto de almacenamiento formado por uno o más PV.
Volumen lógico (LV): partición virtual asignable creada a partir de un VG.
Extensión Física (PE): unidad de asignación de tamaño fijo en un VG.
Extensión Lógica (LE): unidad de asignación utilizada por un LV (mapeada desde PE).

Instalar

1
2

sudo apt update
sudo apt install lvm2

Administrar PV

Crear PV

pvcreate [option] devname ...

# Example: initialize /dev/sdb and /dev/sdc as PV
pvcreate /dev/sdb /dev/sdc

Ver PV

pvdisplay [option] devname

# Example
pvdisplay /dev/sdb

Eliminar PV

pvremove [option] pvname ...

# Example
pvremove /dev/sdb

Administrar VG

Crear VG

vgcreate [option] vgname pvname ...

# Example: create vg1 with /dev/sdb and /dev/sdc
vgcreate vg1 /dev/sdb /dev/sdc

Ver vídeo gráfico

vgdisplay [option] [vgname]

# Example
vgdisplay vg1

Extender VG

vgextend [option] vgname pvname ...

# Example
vgextend vg1 /dev/sdb

Reducir VG

vgreduce [option] vgname pvname ...

# Example
vgreduce vg1 /dev/sdb2

Eliminar VG

vgremove [option] vgname

# Example
vgremove vg1

Administrar VI

Crear LV

lvcreate [option] vgname

# Example 1: create a 10G LV in vg1
lvcreate -L 10G vg1

# Example 2: create a 200M LV named lv1 in vg1
lvcreate -L 200M -n lv1 vg1

Ver LV

lvdisplay [option] [lvname]

# Example
lvdisplay /dev/vg1/lv1

Cambiar tamaño LV

lvresize [option] lvname

# Add 200M
lvresize -L +200M /dev/vg1/lv1

# Reduce 200M
lvresize -L -200M /dev/vg1/lv1

# Use all free space in VG
lvresize -l +100%FREE /dev/vg1/lv1

Extender LV

lvextend [option] lvname

# Add 100M
lvextend -L +100M /dev/vg1/lv1

# Use all free space
lvextend -l +100%FREE /dev/vg1/lv1

Reducir el VI

lvreduce [option] lvname

# Reduce 100M
lvreduce -L -100M /dev/vg1/lv1

Eliminar VI

lvremove [option] lvname

# Example
lvremove /dev/vg1/lv1

Crear y montar sistema de archivos

Crear sistema de archivos

mkfs [option] lvname

# Example: create ext4 on LV
mkfs -t ext4 /dev/vg1/lv1

Montar manualmente

mount lvname mntpath

# Example
mount /dev/vg1/lv1 /mnt/data

Cambiar el tamaño del sistema de archivos después del cambio de tamaño de LV

Después de ampliar un LV, el tamaño del sistema de archivos no aumenta automáticamente en muchos casos. Para ext4:

# Unmount first (recommended for safety)
umount /dev/vg1/lv1

# Check and repair file system
e2fsck -f /dev/vg1/lv1

# Resize file system to fill LV
resize2fs /dev/vg1/lv1

En algunos escenarios, también es posible cambiar el tamaño en línea:

`1`	`resize2fs /dev/vg1/lv1`

Codificar MP3 con ffmpeg

Tue, 07 Jan 2025 00:00:00 +0000

Modos de velocidad de bits de MP3

La codificación MP3 suele utilizar uno de tres modos de velocidad de bits: VBR, ABR y CBR.

CBR (tasa de bits constante)

CBR significa que la tasa de bits se fija en el tiempo.
Por ejemplo, con CBR de 128 kbps, cada segundo se codifica a 128 kb. El tamaño del archivo es predecible.

VBR (tasa de bits variable)

VBR no tiene una tasa de bits fija. El codificador utiliza dinámicamente una tasa de bits más alta para audio complejo y una tasa de bits más baja para partes simples.
Esto a menudo proporciona un mejor equilibrio entre calidad y tamaño.

ABR (tasa de bits promedio)

ABR apunta a una tasa de bits promedio. Es un compromiso entre CBR y VBR.
En comparación con CBR con la misma tasa de bits nominal, ABR generalmente ofrece mejor calidad con un tamaño similar.

Utilice ffmpeg para codificar

Tasa de bits variable (VBR)

ffmpeg -i sample.wav -vn -c:a libmp3lame -aq 4 -ac 2 sample.mp3

# Notes:
# -i   input file
# -vn  disable video
# -c:a audio codec (copy / libmp3lame / aac ...)
# -aq  VBR quality; smaller value usually means better quality and larger file
# -ac  channel count

Tasa de bits constante (CBR)

1
2
3

ffmpeg -i sample.wav -vn -c:a libmp3lame -b:a 192k -ac 2 sample.mp3

# -b:a fixed audio bitrate

Eliminar metadatos

1
2
3

ffmpeg -i sample.wav -map_metadata -1 -vn -c:a libmp3lame -aq 8 -ac 2 sample.mp3

# -map_metadata -1 removes metadata

Cómo intercambiar discos duros en caliente de forma segura (hágalo bien y evite daños al hardware)

Wed, 01 Jan 2025 00:00:00 +0000

Requisito previo: el hardware debe admitir el intercambio en caliente

Primero confirme que el backplane/controlador de su unidad y la plataforma admitan el intercambio en caliente. Este es el requisito básico.

Configuración del BIOS que necesita

Usando ASUS como ejemplo:

Presione F2 o DEL durante el arranque para ingresar al BIOS.
Cambie al “Modo avanzado”.
Vaya a Avanzado -> Configuración de almacenamiento PCH, busque el puerto SATA de destino y configure Hot Plug en Activado.
Presione F10 para guardar y salir.

Después de esto, el intercambio en caliente debería estar disponible. Otras marcas de placas base ofrecen opciones similares.

Pasos del sistema operativo

ventanas

Detenga la actividad de E/S en la unidad de destino.
En el Administrador de dispositivos, busque la unidad y elija desinstalar/expulsar el dispositivo.
Después de una extracción exitosa, desconecte físicamente la unidad.

###Linux

Detenga la actividad de E/S en la unidad de destino.
Desmonte el sistema de archivos (por ejemplo, umount /dev/sda).
Si usa LVM, desactive el grupo de volúmenes (por ejemplo, vgchange -an).
Ponga el disco en modo de espera (por ejemplo, sudo hdparm -Y /dev/sda).
Retire el dispositivo del sistema operativo (echo 1 | sudo tee /sys/block/sda/device/delete). Después de este comando, verifique que el disco haya dejado de girar por completo antes de desconectar la alimentación o los datos. Tirar de un disco duro que aún gira puede dañar el conjunto del cabezal/plato.
Una vez que se completen los pasos anteriores, desconecte la unidad.

inpaint-web: herramienta de superresolución, eliminación de marcas de agua y pintura de imágenes de código abierto y gratuita

Thu, 24 Oct 2024 00:00:00 +0000

inpaint-web

inpaint-web es una herramienta gratuita y de código abierto para mejorar imágenes y pintar, construida sobre tecnologías WebGPU y WASM, implementada completamente en el navegador. GitHub: https://github.com/lxfater/inpaint-web/

Características principales

Reparación de imágenes y eliminación de marcas de agua

Imagen original

Resultados reparados (diferentes regiones reparadas y posiciones de borrado)

Imagen original

Borrar parte del contenido

Mejora de desenfoque a claro

Imagen original

Después de una ampliación 4x

Rangos de frecuencia de canales Wi-Fi comunes: 2,4G y 5G (5,2G/5,5G/5,8G)

Sun, 29 Sep 2024 00:00:00 +0000

Rangos de canales Wi-Fi comunes: 2,4G y 5G (5,2G/5,5G/5,8G)

Banda de 2,4 GHz

La banda de 2,4 GHz se divide en canales espaciados por 5 MHz. Dependiendo de la región, la disponibilidad de canales varía. El funcionamiento de 40 MHz normalmente se forma uniendo canales adyacentes de 20 MHz.

Banda de 5 GHz

Banda 5,2G

Los canales comunes incluyen 36, 40, 44, 48, 52, 56, 60, 64.
En algunos ámbitos regulatorios, los canales DFS (como 52-64) pueden estar restringidos o requerir un comportamiento de detección de radar.

Banda 5,5G

5,5 GHz es parte de la asignación más amplia de 5 GHz. Los planes de canales varían según el país/región.

Banda 5,8G

En las reglas CN, los canales comunes son 149, 153, 157, 161, 165.
Ejemplos típicos de unión:

80MHz: 149-161
40 MHz: 149-153 o 157-161
20 MHz: solo canal 165

Xiaomi AX3600: MIBIB y compatibilidad de firmware

Tue, 09 Jul 2024 00:00:00 +0000

Enrutador Xiaomi MIBIB

En los flujos de trabajo del AX3600 se utilizan dos archivos MIBIB comunes:

MIBIB de acciones de Xiaomi stock mibib
MIBIB relacionado con QSDK (a menudo utilizado en algunos flujos de trabajo de actualización de U-Boot) qsdk mibib

MIBIB y mapeo de firmware

Las diferentes variantes de MIBIB corresponden a diferentes imágenes de firmware. Si el firmware/MIBIB no coincide, es posible que el dispositivo no arranque (incluso que U-Boot no se inicie).

El firmware suele coincidir con el MIBIB original:
- la mayoría de las imágenes de estilo OpenWrt AI
Firmware que normalmente coincide con QSDK MIBIB:
- Compilaciones de firmware basadas en QSDK
Firmware que puede funcionar en ambos diseños (contiene adaptación dual):
- openwrt-ipq807x-generic-redmi_ax6-squashfs.ubi

Compruebe qué MIBIB está en el enrutador

Cargue mibib.xiaomi.bin y mibib.qsdk.bin a /tmp, luego verifique:

1
2

mtd verify /tmp/mibib.xiaomi.bin /dev/mtd1
mtd verify /tmp/mibib.qsdk.bin /dev/mtd1

Recursos de recuperación de AX3600

Archivos de copia de seguridad relacionados con el arranque del AX3600:

Primero verifique el mapeo de particiones:

`1`	`cat /proc/mtd`

Después de confirmar mtd1 y mtd7, escriba copias de seguridad:

mtd erase /dev/mtd1
mtd write /tmp/ax3600bak.mibib.bin /dev/mtd1
mtd erase /dev/mtd7
mtd write /tmp/ax3600bak.appsbl.bin /dev/mtd7

Archivos de firmware originales:

Notas

Siempre haga una copia de seguridad de las particiones clave antes de flashear.
Verifique la compatibilidad MIBIB/firmware antes de escribir.
Evite el flasheo cruzado de la familia de firmware y el diseño de arranque a ciegas.

Ajuste del sistema OpenStick Debian: AP Wi-Fi y optimización de la compresión

Sat, 28 Oct 2023 00:00:00 +0000

Cambio de modo USB

Cuando se cambia al modo “host”, el dispositivo puede usar periféricos USB (incluidos adaptadores Wi-Fi).
Cuando se cambia al modo “dispositivo”, puede exponer la red USB/ADB a una PC.

Cambiar al modo anfitrión

`1`	`echo host > /sys/kernel/debug/usb/ci_hdrc.0/role`

Volver al modo gadget

`1`	`echo gadget > /sys/kernel/debug/usb/ci_hdrc.0/role`

Cambio automático al arrancar

Agregue a /etc/rc.local antes de exit 0:

# usb auto host
sleep 3
grep 0 /sys/kernel/debug/usb/ci_hdrc.0/device | grep speed
if [ $? -eq 0 ]
then
  echo host > /sys/kernel/debug/usb/ci_hdrc.0/role
fi

Esto verifica si hay una conexión a una PC; de lo contrario, cambia al modo host para dispositivos USB externos.

Optimización de compresión para almacenamiento interno limitado

Algunos dispositivos Wi-Fi tienen un almacenamiento muy limitado (por ejemplo, 4 GB). Habilitar una compresión más fuerte puede reducir significativamente el uso.

Utilice Btrfs (admite compresión transparente)

Convierta la imagen raíz a Btrfs (asegúrese de que el kernel sea compatible con Btrfs):

`1`	`btrfs-convert root.img`

Opciones de montaje de sintonización

Los niveles más altos de zstd reducen aún más el tamaño pero usan más CPU. Para equilibrar el rendimiento, ajústelo a su dispositivo.

Ejemplo de prueba de remontaje:

`1`	`sudo mount -o remount,defaults,noatime,compress=zstd:6,commit=120 /dev/mmcblk0p14 /`

Recomprimir archivos existentes

`1`	`sudo btrfs filesystem defragment -r -v -czstd /`

En la prueba original, una compresión más fuerte redujo notablemente el espacio utilizado.

Reconstruir el firmware de Debian para OpenStick Wi-Fi Stick

Wed, 09 Aug 2023 00:00:00 +0000

Preparación del entorno

Instale Ubuntu 22.04.2 LTS.
Instalar dependencias:

sudo apt install binfmt-support qemu-user-static gcc-10-aarch64-linux-gnu kernel-package fakeroot simg2img img2simg mkbootimg bison flex gcc-aarch64-linux-gnu pkg-config libncurses-dev libssl-dev unzip git

Descargar fuente

`1`	`git clone https://github.com/OpenStick/linux.git --depth=1`

Construcción del núcleo

Ajuste de la tabla de frecuencia de la CPU

Editar: linux/drivers/clk/qcom/a53-pll.c

Ajuste/extienda las entradas de frecuencia con cuidado, equilibrando el rendimiento, la potencia y las térmicas.

Edite la tabla DTS OPP según sea necesario: linux/arch/arm64/boot/dts/qcom/msm8916.dtsi

Pasos de construcción

cd linux
export CROSS_COMPILE=aarch64-linux-gnu-
export ARCH=arm64
make msm8916_defconfig
make menuconfig

Soporte serie USB (para dispositivos USB tipo Klipper)

Habilite las opciones USB CDC ACM / USB Serial relevantes en menuconfig.

Construir paquetes

`1`	make -j`nproc` bindeb-pkg

Resultados esperados:

archivos del kernel .deb (linux-image, linux-headers)
Imagen.gz
destino DTB (msm8916-handsome-openstick-*.dtb)

Preparar imagen RootFS

Obtener la imagen base de Debian

mkdir ~/rootfs
cd ~/rootfs
wget https://github.com/OpenStick/OpenStick/releases/download/v1/debian.zip && unzip debian.zip
mv ./debian/rootfs.img ~/rootfs

Convertir formato de imagen

`1`	`simg2img rootfs.img root.img`

Montar y hacer chroot

sudo mount root.img /mnt
sudo mount --bind /proc /mnt/proc
sudo mount --bind /dev /mnt/dev
sudo mount --bind /dev/pts /mnt/dev/pts
sudo mount --bind /sys /mnt/sys

Copie los archivos deb del kernel en /mnt, luego:

sudo chroot /mnt
dpkg -l | grep -E "linux-headers|linux-image" |awk '{print $2}'|xargs dpkg -P
dpkg -i *.deb
rm linux-*.deb

Habilitar rc.local con systemd

Cree /etc/systemd/system/rc-local.service y /etc/rc.local, luego:

`1`	`systemctl daemon-reload && systemctl enable rc-local`

Limpieza de configuración local y fuente adecuada

Instalar y configurar configuraciones regionales:

1
2

sudo apt install locales
sudo dpkg-reconfigure locales

Elimine las entradas inválidas de la lista de fuentes antiguas si es necesario.

Desmontar

sudo umount /mnt/proc
sudo umount /mnt/dev/pts
sudo umount /mnt/dev
sudo umount /mnt/sys
sudo umount /mnt

Volver a convertir a imagen dispersa

`1`	`img2simg root.img rootfs.img`

Crear imagen de arranque

Archivos requeridos:

Imagen.gz
Destino DTB (para su variante de hardware)
initrd.img-* de rootfs /boot

Ejemplo (ufi001c):

1
2
3

cat Image.gz msm8916-handsome-openstick-ufi001c.dtb > ufi001c-kernel-dtb
mv initrd.img-* initrd.img
mkbootimg --base 0x80000000 --kernel_offset 0x00080000 --ramdisk_offset 0x02000000 --tags_offset 0x01e00000 --pagesize 2048 --second_offset 0x00f00000 --ramdisk initrd.img --cmdline "earlycon root=PARTUUID=a7ab80e8-e9d1-e8cd-f157-93f69b1d141e console=ttyMSM0,115200 no_framebuffer=true rw" --kernel ufi001c-kernel-dtb -o ufi001c-boot.img

Reemplace boot.img y rootfs.img en el paquete de actualización con sus archivos generados.

Restablecer mdadm RAID en Ubuntu 22.04

Fri, 17 Mar 2023 00:00:00 +0000

Al probar RAID con mdadm, es posible que deba restablecer completamente la matriz antes de volver a utilizarla.

Procedimiento de reinicio

Verifique el estado actual:

`1`	`lsblk -o NAME,SIZE,FSTYPE,TYPE,MOUNTPOINT`

Si está montado, desmóntelo primero:

`1`	`umount /mnt/md0`

Detenga el dispositivo RAID:

`1`	`sudo mdadm --stop /dev/md0`

Superbloque cero en cada disco miembro:

1
2

sudo mdadm --zero-superblock /dev/nvme0n1
sudo mdadm --zero-superblock /dev/nvme1n1

Revise si los archivos de configuración también necesitan limpieza:

/etc/mdadm/mdadm.conf -/etc/fstab

Arreglando el rendimiento de escritura NTFS lento en Ubuntu 22.04

Sat, 04 Mar 2023 00:00:00 +0000

Reparar el rendimiento y la caché de lectura/escritura de NTFS en Ubuntu 22.04

En un disco WD HC550, la velocidad de escritura en Windows era de alrededor de 250 MB/s. En Ubuntu, la velocidad de lectura era aceptable (200 MB/s+), pero la velocidad de escritura se redujo a alrededor de 80 MB/s.

La solución fue ajustar las opciones de montaje en /etc/fstab.

`1`	`/dev/disk/by-uuid/xxxxxxxxxx /mnt/WD_16T_01 ntfs-3g defaults,lazytime,uid=1000,dmask=007,fmask=117,big_writes,nofail,auto 0 0`

Después de este cambio, la velocidad de lectura/escritura volvió a alrededor de 250 MB/s+.

Estación de trabajo DIY de bajo costo con memoria de 256 GB y placa base HP Z440

Sun, 26 Feb 2023 00:00:00 +0000

¿Por qué elegir la placa base HP Z440?

Objetivo: construir una máquina con mucha memoria a bajo costo, con buena capacidad de mantenimiento y expansión.

Elección de memoria

Los módulos DDR4 2133 32GB ECC REG (4R*4) tenían un precio de alrededor de 190 CNY cada uno.
8 unidades = 256 GB en total.
La relación costo-rendimiento fue mejor que la mayoría de las alternativas en ese momento.

elección de CPU

CPU de prueba inicial: E5-2620 v3 (muy bajo costo).
Opciones prácticas posteriores: E5-2620 v4 o E5-2630 v4.

¿Por qué no comprar el sistema Z440 completo?

Los sistemas completos eran caros.
La solución de placa autoensamblada + adaptador de fuente de alimentación era mucho más económica.

Notas de construcción y cableado

Descripción general de la interfaz:

Notas mecánicas y de montaje

El tamaño de la placa Z440 es cercano al ATX pero con algunos orificios/posiciones desplazados. Es posible probar el ajuste en casos comunes, pero es posible que necesite ajustes menores.

Panel frontal/encabezado

Mapeo de encabezado frontal de 25 pines:

Detección de ventiladores y comprobaciones de inicio

El firmware Z440 comprueba varios ventiladores/sensores durante el arranque. La falta de fanáticos esperados puede generar advertencias.

Advertencia de USB frontal

Si el USB frontal no está conectado correctamente, pueden aparecer advertencias del BIOS.

Encabezado de audio frontal

La detección incorrecta de audio frontal puede generar advertencias. En algunos casos, colocar los pines necesarios en bucle puede evitar la detección.

Encabezados de fans

Se monitorean los encabezados de los ventiladores de la CPU y la memoria.
El ventilador de la CPU es de 6 pines (eléctricamente cerca de un PWM de 4 pines con diseño específico del proveedor).

Notas sobre la fuente de alimentación (18P + 12P)

Usos de la placa Z440:

un conector principal de 18 pines
un conector CPU/auxiliar de 12 pines

Mapeo del conector 18P

+12V_B, +12V_S, +12V_D alimentan diferentes dominios de placa.

Conector 12P

Conceptualmente cercano a una CPU de 8 pines + disposición adicional de 4 pines, con múltiples líneas de 12 V y GND para alimentación de CPU/memoria.

Acerca de la advertencia 539 (energía LRDIMM insuficiente)

Advertencia común: 539 - Vataje de fuente de alimentación insuficiente para la configuración de memoria LR dimm

Comportamiento observado a partir de referencias de la comunidad:

Puede aparecer una advertencia con LRDIMM incluso con una fuente de alimentación OEM de alta potencia.
Es difícil suprimirlo por completo en algunas combinaciones de firmware.
El uso de RDIMM (2Rx4 REG ECC, no LR) generalmente evita esta advertencia.

Referencias:

Gestión remota

Z440 no tiene BMC. Opciones remotas útiles:

WOL (despertar en LAN)
Intel AMT (capacidad parcial dependiendo de la CPU/plataforma)

AMT puede proporcionar:

operaciones de energía remota
información de hardware/sistema
Serial-over-LAN para consola de texto durante el arranque

Aspectos destacados de la configuración de AMT

Presione Ctrl + P durante el arranque para ingresar a la configuración de AMT.
Configurar la red y habilitar AMT.
Habilitar el modo de redirección SOL/heredado para la consola serie.

Herramientas del cliente

Acceso web: http://<amt-ip>:16992
MeshCommander: https://www.meshcommander.com/meshcommander

Arranque sin cabeza (sin GPU de pantalla dedicada)

Con muchas configuraciones de Xeon, no hay salida iGPU disponible. Puede habilitar el arranque sin cabeza a través de la exportación/importación de la configuración replicada del BIOS.

Flujo de trabajo:

Ingrese al BIOS (Esc) -> Configuración replicada.
Exporte la configuración a FAT32 USB.
Edite HpSetup.txt, cambie Arranque sin cabeza de Desactivar a Activar.
Importe la configuración desde USB.

Notas sobre medición de energía

Con E5-2630 v4:

Configuración básica (un solo módulo de memoria, SSD, sin dGPU): alrededor de 41 W inactivos en Ubuntu.
Memoria ECC REG de 8x32 GB instalada: alrededor de 60 W inactivos.

Impacto aproximado por dispositivo en esta prueba: alrededor de 3 W por módulo de 32 GB.

Montar un servidor Git en Synology NAS y respaldarlo con Hyper Backup

Wed, 07 Dec 2022 00:00:00 +0000

Synology NAS puede funcionar como un servidor Git privado y ligero. Para proyectos personales o equipos pequeños suele ser suficiente: los repositorios quedan dentro de la LAN, el acceso se gestiona con cuentas del NAS y los datos pueden protegerse con las herramientas de copia de seguridad de Synology.

Esta nota resume la configuración básica y el flujo de respaldo con Hyper Backup.

Instalar Git Server

Abre Package Center en Synology DSM e instala el paquete Git Server.

Después de instalarlo, abre Git Server y permite que los usuarios necesarios usen Git por SSH. La cuenta del NAS debe tener acceso SSH y permiso sobre la carpeta donde se guardarán los repositorios.

Preparar El Directorio De Repositorios

Crea una carpeta compartida o un subdirectorio para los repositorios Git, por ejemplo:

`1`	`/volume1/git`

Dentro de esa carpeta, crea repositorios bare:

`1`	`git init --bare project.git`

Un repositorio bare no tiene working tree. Es el formato adecuado para usarse como remoto.

Conectar Desde Un Cliente

Desde otra máquina, clona el repositorio por SSH:

`1`	`git clone user@nas-ip:/volume1/git/project.git`

También puedes añadirlo como remoto en un proyecto local existente:

1
2

git remote add origin user@nas-ip:/volume1/git/project.git
git push -u origin master

Si SSH usa un puerto no estándar, configúralo en SSH o usa una URL remota personalizada.

Permisos

Asegúrate de que el directorio del repositorio pertenece al usuario o grupo correcto. Si varios usuarios necesitan acceso, colócalos en un grupo común y otorga permisos de lectura/escritura sobre la carpeta Git.

Si el push falla, revisa primero:

si el inicio de sesión SSH funciona;
si el usuario está autorizado en Git Server;
si la carpeta tiene permiso de escritura;
si el repositorio fue creado como bare;
si la URL remota es correcta.

Copia De Seguridad Con Hyper Backup

Cuando los repositorios estén en el NAS, configura Hyper Backup para respaldar la carpeta Git.

En Hyper Backup:

Crea una nueva tarea de backup.
Selecciona el destino, como otro disco, otro NAS, un servidor rsync o almacenamiento cloud.
Selecciona la carpeta de repositorios Git.
Configura la programación.
Activa la retención de versiones si la necesitas.

Esto protege los datos ante fallos de disco, borrados accidentales o pushes incorrectos.

Notas De Restauración

Al restaurar, recupera el directorio completo del repositorio bare. Después prueba:

`1`	`git clone user@nas-ip:/volume1/git/project.git`

Si el clone funciona, el repositorio vuelve a estar disponible.

Resumen

Synology Git Server es sencillo, pero suficiente para muchos repositorios privados. Los puntos importantes son acceso SSH, permisos correctos, repositorios bare y una tarea fiable de Hyper Backup.

Solucionar el consumo de batería en Windows 10 después de cerrar la tapa del portátil

Tue, 27 Sep 2022 00:00:00 +0000

Algunos portátiles con Windows 10 siguen consumiendo energía después de cerrar la tapa. La pantalla se apaga, pero el equipo puede no entrar en un estado real de bajo consumo. Después de varias horas en una mochila, la batería puede bajar mucho o el portátil puede calentarse.

Normalmente está relacionado con el modo de suspensión, la acción al cerrar la tapa, fuentes de reactivación, Modern Standby o dispositivos que mantienen activo el sistema.

Revisar La Acción Al Cerrar La Tapa

Abre las opciones de energía y confirma qué debe hacer Windows al cerrar la tapa:

`1`	`Control Panel -> Hardware and Sound -> Power Options -> Choose what closing the lid does`

Para batería y corriente, configura la acción como Sleep o Hibernate según tu preferencia.

Si está seleccionado Do nothing, el portátil seguirá funcionando después de cerrar la tapa.

Preferir Hibernación Para Transportes Largos

La suspensión todavía consume energía. Si el portátil va a estar mucho tiempo en una mochila, hibernar es más seguro.

La hibernación guarda el estado de la memoria en disco y apaga el equipo de forma más completa. El arranque es más lento que desde suspensión, pero el consumo de batería es mucho menor.

Puedes activar la hibernación con:

`1`	`powercfg /hibernate on`

Después selecciona hibernación como acción al cerrar la tapa o en el menú de apagado.

Revisar Fuentes De Reactivación

Algunos dispositivos pueden despertar el portátil o impedir la suspensión. Comprueba la última fuente de reactivación:

`1`	`powercfg /lastwake`

Lista los dispositivos con permiso para despertar el sistema:

`1`	`powercfg /devicequery wake_armed`

Si un adaptador de red, mouse, teclado o dispositivo Bluetooth despierta el equipo, desactiva su permiso de reactivación en Device Manager.

Generar Un Informe De Suspensión

Windows puede generar diagnósticos de suspensión:

`1`	`powercfg /sleepstudy`

El informe muestra sesiones de suspensión, consumo de batería, dispositivos activos y uso anormal de energía. Es especialmente útil en equipos con Modern Standby.

Revisar Modern Standby

Algunos portátiles nuevos usan Modern Standby en lugar de la suspensión S3 tradicional. Puede mantener red y actividad en segundo plano, aumentando el consumo.

Comprueba los estados de suspensión soportados:

`1`	`powercfg /a`

Si solo está disponible Modern Standby, considera usar hibernación para transportar el equipo o dejarlo inactivo mucho tiempo.

Resumen

Cuando un portátil con Windows 10 consume batería después de cerrar la tapa, revisa primero la acción de cierre, después las fuentes de reactivación y los informes de suspensión. Para bajo consumo fiable durante transporte, la hibernación suele ser mejor que la suspensión.

Compilar y flashear firmware OpenWrt personalizado para el router Redmi AX6S

Sun, 04 Sep 2022 00:00:00 +0000

Configuración de hardware del AX6S

CPU: MediaTek MT7622B, 2 núcleos A53
Flash: 128 MB NAND
RAM: 256 MB
https://www.mi.com/global/product/xiaomi-router-ax3200/

Compilación personalizada de OpenWrt para el AX6S

Instala Linux primero; se recomienda Ubuntu LTS

Instalar dependencias de compilación

sudo apt update -y
sudo apt full-upgrade -y
sudo apt install -y ack antlr3 asciidoc autoconf automake autopoint binutils bison build-essential \
bzip2 ccache cmake cpio curl device-tree-compiler fastjar flex gawk gettext gcc-multilib g++-multilib \
git gperf haveged help2man intltool libc6-dev-i386 libelf-dev libglib2.0-dev libgmp3-dev libltdl-dev \
libmpc-dev libmpfr-dev libncurses5-dev libncursesw5-dev libreadline-dev libssl-dev libtool lrzsz \
mkisofs msmtp nano ninja-build p7zip p7zip-full patch pkgconf python2.7 python3 python3-pip libpython3-dev qemu-utils \
rsync scons squashfs-tools subversion swig texinfo uglifyjs upx-ucl unzip vim wget xmlto xxd zlib1g-dev

Descargar el código fuente, actualizar feeds y elegir la configuración

git clone https://github.com/coolsnowwolf/lede
cd lede
./scripts/feeds update -a
./scripts/feeds install -a
make menuconfig

Selecciona Target Profile.
Selecciona LuCI -> Applications ->.

	Significado
[ * ]	Seleccionado
[ ]	No seleccionado
< M >	Compilar como módulo

Aplicaciones comunes:

Nombre	Ruta de menú	Descripción
luci-app-adbyby-plus	Services -> Adbyby Plus+	Bloqueo de anuncios para dispositivos de la misma red.
luci-app-aliddns	Services -> AliDDNS	Resolución DDNS de Aliyun.
luci-app-ddns	Services -> Dynamic DNS	DNS dinámico; no admite AliDDNS.
luci-app-autoreboot	System -> Scheduled Reboot	Configura reinicios programados.
luci-app-arpbind	Network -> IP/MAC Binding	Vincula direcciones IP y MAC.
luci-app-filetransfer	System -> File Transfer	Transfiere archivos al sistema de archivos de OpenWrt.
luci-app-firewall	Network -> Firewall	Configuración del firewall.
luci-app-frpc	Services -> Frp Client	Cliente Frp para acceso desde intranet.
luci-app-frps	Services -> Frps	Servidor Frp para acceso desde intranet.
luci-app-guest-wifi	Network -> Guest Wi-Fi	Red Wi-Fi de invitados.
luci-app-nlbwmon	Bandwidth Monitor	Todas las funciones del menú de monitorización de ancho de banda.
luci-app-qos	Network -> QoS	Calidad de servicio; permite priorizar clases de tráfico.
luci-app-ssr-plus	Services -> ShadowSocksR Plus+	Selector de plugins de proxy.
luci-app-turboacc	Network -> Turbo ACC	Aceleración de red.
luci-app-unblockmusic	Sin menú	Desbloqueo de NetEase Cloud Music.
luci-app-upnp	Services -> UPnP	Universal Plug and Play (UPnP).
luci-app-vlmcsd	Services -> KMS Server	Servidor de activación de productos Microsoft.
luci-app-wireguard	Network -> Interfaces	El estado se ve en Status -> WireGuard Status.
luci-app-wol	Services -> Wake-on-LAN	Wake-on-LAN.

Selecciona las funciones necesarias, guarda la configuración y sal cuando termines.

Descargar el directorio `dl` y compilar el firmware

El valor detrás de -j es el número de hilos. Para la primera compilación se recomienda usar un solo hilo.

1
2

make download -j8
make V=s -j1

Después de una compilación correcta, el firmware queda en ~/lede/bin/targets/mediatek/mt7622/.

Uso	Archivo
Primer flasheo	openwrt-mediatek-mt7622-xiaomi_redmi-router-ax6s-squashfs-factory.bin
Actualización desde OpenWrt	openwrt-mediatek-mt7622-xiaomi_redmi-router-ax6s-squashfs-sysupgrade.bin

Desbloqueo y flasheo del AX6S

Flashear el firmware de prueba de Redmi

Solo después de flashear el firmware de prueba se puede usar telnet para las operaciones posteriores en el AX6S. Firmware de prueba: miwifi_rb03_firmware_stable_1.2.7.bin

Calcular la contraseña de telnet

El cálculo necesita el número de serie del router. Puedes encontrarlo en la etiqueta de la parte trasera del dispositivo y también en la interfaz de administración del router.

Muchos calculadores en línea ya no funcionan. Puedes ejecutar localmente el siguiente script de Python:

#!/usr/bin/env python3
import sys
import hashlib

if sys.version_info < (3,7):
    print("python version is not supported", file=sys.stderr)
    sys.exit(1)

# credit goes to zhoujiazhao:
# https://blog.csdn.net/zhoujiazhao/article/details/102578244

salt = {'r1d': 'A2E371B0-B34B-48A5-8C40-A7133F3B5D88',
        'others': 'd44fb0960aa0-a5e6-4a30-250f-6d2df50a'}


def get_salt(sn):
    if "/" not in sn:
        return salt["r1d"]

    return "-".join(reversed(salt["others"].split("-")))


def calc_passwd(sn):
    passwd = sn + get_salt(sn)
    m = hashlib.md5(passwd.encode())
    return m.hexdigest()[:8]


if __name__ == "__main__":
    if len(sys.argv) != 2:
        print(f"Usage: {sys.argv[0]} <S/N>")
        sys.exit(1)

    serial = sys.argv[1]
    print(calc_passwd(serial))

1
2

abc@openwrt-build:~$ python calc_ax6s_pwd.py SN
00d135eb

La salida es la contraseña de telnet.

Conectar al AX6S por telnet

Primero confirma la dirección IP del router. Puedes verla en la interfaz de administración de la red a la que está conectado. Por ejemplo, mi router usa 192.168.0.121. Abre una terminal y ejecuta:

`1`	`telnet 192.168.0.121`

Usuario: root
Contraseña: la contraseña calculada arriba

Después de iniciar sesión correctamente, ejecuta:

1
2
3

nvram set ssh_en=1 && nvram set uart_en=1 && nvram set boot_wait=on && nvram set bootdelay=3 && nvram set flag_try_sys1_failed=0 && nvram set flag_try_sys2_failed=1
nvram set flag_boot_rootfs=0 && nvram set "boot_fw1=run boot_rd_img;bootm" && nvram set flag_boot_success=1 && nvram commit 
/etc/init.d/dropbear enable && /etc/init.d/dropbear start

Cuando los comandos finalicen correctamente, SCP quedará habilitado. Usa SCP para subir el firmware al router.

Subir el firmware

En Windows, conecta al router con WinSCP. Sube el archivo compilado openwrt-mediatek-mt7622-xiaomi_redmi-router-ax6s-squashfs-factory.bin a /tmp/ y renómbralo como factory.bin.

Flashear el firmware

Ejecuta el siguiente comando en la sesión telnet:

`1`	`mtd -r write /tmp/factory.bin firmware`

Después del flasheo, el router se reiniciará. La información predeterminada tras el reinicio es:

Dirección IP: 192.168.1.1
Usuario: root
Contraseña: password

Recuperación si el flasheo falla

Descarga la herramienta de reparación de routers Xiaomi:
https://bigota.miwifi.com/xiaoqiang/tools/MIWIFIRepairTool.x86.zip
Notas de uso:
AX6S no aparece en la lista de modelos admitidos, pero funcionó en mi prueba. La herramienta de reparación para PC necesita privilegios del sistema para modificar la configuración del adaptador de red, por lo que hay que desactivar el antivirus antes de usarla.
https://web.vip.miui.com/page/info/mio/mio/detail?postId=19134127&app_version=dev.20051

Qué es un ataque Sybil

Tue, 05 Jul 2022 00:00:00 +0000

Un ataque Sybil ocurre cuando una entidad real crea muchas identidades falsas y las usa para influir en un sistema distribuido.

El nombre describe la idea de una persona apareciendo como muchas. En una red, foro, sistema de votación, blockchain o sistema peer-to-peer, el atacante puede registrar muchas cuentas, nodos o direcciones. Si el sistema trata cada identidad como participante independiente, el atacante gana más influencia de la que debería.

Por Qué Es Peligroso

Muchos sistemas distribuidos asumen que “más participantes” significa “más opiniones independientes”. Un atacante Sybil rompe esa suposición.

Por ejemplo, puede:

crear muchas cuentas falsas para manipular votaciones;
ejecutar muchos nodos falsos para influir en el descubrimiento de peers;
generar muchas direcciones blockchain para farmear airdrops;
inundar un sistema de reputación con reseñas falsas;
hacer que un grupo pequeño parezca una comunidad grande.

El problema central es que las identidades son baratas de crear, pero el sistema da valor a cada identidad.

Defensas Comunes

No existe una solución universal. Distintos sistemas aumentan el coste de identidad de distintas formas:

proof of work: las identidades requieren coste computacional;
proof of stake: las identidades requieren capital bloqueado;
verificación de cuenta: las identidades requieren prueba del mundo real;
sistemas de reputación: la influencia crece lentamente;
límites de tasa: las identidades nuevas no pueden actuar demasiado rápido;
análisis de grafos: se detectan grupos sospechosos.

Cada defensa tiene compromisos. La verificación fuerte mejora la resistencia pero reduce privacidad. Proof of work consume recursos. Proof of stake favorece a quien tiene más capital.

En Sistemas Blockchain

La resistencia a Sybil es central en el diseño blockchain. Si un equipo pudiera crear nodos de votación ilimitados sin coste, el consenso sería fácil de manipular.

Bitcoin usa proof of work para que la influencia dependa del hash power y no del número de cuentas. Los sistemas proof-of-stake usan stake bloqueado. Muchos proyectos con airdrops añaden análisis de comportamiento o verificación de identidad para reducir cuentas falsas.

Resumen

Un ataque Sybil no explota necesariamente un bug de software. Explota un coste débil de identidad. Cuando crear muchas identidades es barato y cada identidad recibe confianza o recompensa, el sistema es vulnerable.

La pregunta clave de diseño es: ¿cuánto cuesta convertirse en “un participante”?

Instale GoAccess en Ubuntu + Nginx para análisis de sitios en tiempo real

Thu, 14 Apr 2022 00:00:00 +0000

Instalar GoAccess

1
2

# distro repo
apt-get install goaccess

O repositorio oficial:

wget -O - https://deb.goaccess.io/gnugpg.key | gpg --dearmor | sudo tee /usr/share/keyrings/goaccess.gpg >/dev/null
echo "deb [signed-by=/usr/share/keyrings/goaccess.gpg] https://deb.goaccess.io/ $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/goaccess.list
sudo apt-get update
sudo apt-get install goaccess

Generar informe

`1`	`goaccess /var/log/nginx/www.knightli.com.access.log -o /www/www.knightli.com/r.html --log-format=COMBINED`

Ubuntu 20.04: HP 544+FLR-QSFP, RDMA y NVMe sobre Fabrics

Tue, 29 Mar 2022 00:00:00 +0000

Este artículo registra el uso de HP 544+FLR-QSFP (basado en Mellanox ConnectX-3 Pro) en Ubuntu 20.04 para pruebas de RDMA y NVMe-oF.

Hardware

Adaptador de doble puerto HP 544+FLR-QSFP 40Gb/s.

Conductor

Utilice el paquete Mellanox OFED para Ubuntu 20.04 del sitio de redes de NVIDIA.

Agregar sistema de comentarios de expresiones a Hugo

Fri, 25 Mar 2022 00:00:00 +0000

Por qué las declaraciones

Utterances es un sistema de comentarios basado en GitHub Issues. En comparación con herramientas similares (como Gitment/Gitalk/Disqus), las ventajas comunes son:

ligero y rápido
configuración sencilla
los comentarios se almacenan en GitHub Issues, son fáciles de administrar en proyectos abiertos

Pasos de instalación

Prepare una cuenta y un repositorio de GitHub. Los comentarios se almacenarán como problemas en ese repositorio.

Instale la aplicación GitHub de declaraciones: https://github.com/apps/utterances

Instale la aplicación y otorgue acceso al repositorio de destino.

Agregue la configuración en Hugo config.toml:

[params.utteranc]
    enable = true
    repo = "github_user/repository"
    issueTerm = "pathname"

Usar FRP para acceder a Synology DS File, DS Photo y Escritorio remoto sin IP pública

Sat, 10 Oct 2020 00:00:00 +0000

FRP es una herramienta de proxy inverso de alto rendimiento. Permite exponer servicios de una red privada hacia Internet y soporta reenvío TCP, HTTP y HTTPS. Es útil cuando la red doméstica no tiene IP pública, pero se necesita acceder a servicios como Synology DS File, DS Photo o Escritorio remoto de Windows.

Dirección del proyecto:

`1`	`https://github.com/fatedier/frp`

Instalar El Servidor FRP

Descarga una versión desde la página de releases de FRP. El ejemplo original usa FRP 0.34.1 sobre Ubuntu 20.04:

1
2

wget https://github.com/fatedier/frp/releases/download/v0.34.1/frp_0.34.1_linux_arm64.tar.gz
tar -zvxf frp_0.34.1_linux_arm64.tar.gz

Después de extraer el paquete, verás binarios de cliente y servidor, archivos de configuración de ejemplo y servicios systemd:

frp_0.34.1_linux_amd64
├── frpc
├── frpc_full.ini
├── frpc.ini
├── frps
├── frps_full.ini
├── frps.ini
├── LICENSE
└── systemd
    ├── frpc.service
    ├── frpc@.service
    ├── frps.service
    └── frps@.service

Copia los binarios, configuraciones y servicios al sistema:

copy frp_0.34.1_linux_amd64/frpc /usr/bin/
copy frp_0.34.1_linux_amd64/frps /usr/bin/
copy frp_0.34.1_linux_amd64/*.ini /etc/fpr/
copy frp_0.34.1_linux_amd64/systemd/* /etc/systemd/system

Si /etc/fpr/ no existe, créalo antes.

Configuración Del Servidor

Un ejemplo de frps.ini:

[common]
bind_port = 10100
vhost_http_port = 10101
token = XXXXXX

dashboard_port = 10109
dashboard_user = admin
dashboard_pwd = XXXXXX

log_file = /var/log/frps.log
log_level = debug
log_max_days = 3

bind_port se usa para la comunicación entre servidor y clientes FRP. vhost_http_port recibe el tráfico HTTP público. Si se usa Nginx delante de FRP, Nginx debe reenviar el tráfico a este puerto.

Para más opciones, revisa frps_full.ini.

Comandos básicos del servicio:

systemctl start frps
systemctl stop frps
systemctl restart frps
systemctl status frps
systemctl enable frps

Proxy Nginx Opcional

Si el puerto 80 ya está ocupado por Nginx, puedes reenviar los dominios necesarios al puerto HTTP virtual de FRP:

server {
    listen 80;
    server_name dsphoto.youdomain.com dsfile.youdomian.com frp.yourdomian.com;
    location / {
        proxy_pass http://127.0.0.1:10101;
        proxy_set_header Host $host:80;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";

        proxy_connect_timeout 7d;
        proxy_send_timeout 7d;
        proxy_read_timeout 7d;
    }
    if ($http_user_agent ~* "360Spider|JikeSpider|Spider|spider|bot|Bot|2345Explorer|curl|wget|webZIP|qihoobot|Baiduspider|Googlebot|Googlebot-Mobile|Googlebot-Image|Mediapartners-Google|Adsbot-Google|Feedfetcher-Google|Yahoo! Slurp|Yahoo! Slurp China|YoudaoBot|Sosospider|Sogou spider|Sogou web spider|MSNBot|ia_archiver|Tomato Bot|NSPlayer|bingbot") {
        return 403;
    }
}

Configuración Del Cliente FRP

La instalación del cliente es similar. El cliente usa frpc, el archivo de configuración es frpc.ini y el servicio es frpc.

Ejemplo de configuración:

[common]
server_addr = frp.yourdomain.com
server_port = 10100
token = XXXXXX
log_file = /tmp/frpc.log
log_level = info
log_max_days = 3
tcp_mux = true
protocol = tcp
login_fail_exit = false
user = admin

[DSphoto]
type = http
local_ip = 192.168.68.200
local_port = 80
custom_domains = dsphoto.yourdomain.com

[DSfile]
type = http
local_ip = 192.168.68.200
local_port = 5000
custom_domains = dsfile.yourdomain.com

[DSM]
type = tcp
local_ip = 192.168.68.200
local_port = 5000
remote_port = 5000

[MSTC]
type = tcp
local_ip = 192.168.68.168
local_port = 3389
remote_port = 3389

DSphoto expone el servicio de fotos de Synology. DSfile expone DS File por HTTP. DSM publica el puerto de administración DSM por TCP. MSTC reenvía Escritorio remoto de Windows.

Una vez conectado el cliente, accede desde Internet mediante los dominios o puertos configurados.