\n

El panorama del gaming en Linux lleva años cambiando a un ritmo que, hace una década, pocos se habrían creído. Lo que antes era casi terreno exclusivo de usuarios muy avanzados se ha convertido en una alternativa real para jugar en PC, hasta el punto de que cada vez más personas comentan que sus títulos funcionan incluso mejor que en Windows, sobre todo cuando se combina una buena distribución con Proton y las tecnologías de Valve.

\n

En ese contexto de cambio continuo, se acaba de producir un giro llamativo en las preferencias de los jugadores de escritorio: CachyOS ha adelantado a Arch Linux como la distribución con más reportes de rendimiento en ProtonDB. No se trata de un detalle menor; es el fin de una racha que se mantenía desde 2021 y que consolida a CachyOS como una opción cada vez más habitual entre los usuarios más implicados en probar y documentar el rendimiento de sus juegos en Linux, también en mercados europeos donde el interés por las alternativas libres va al alza.

\n

CachyOS adelanta a Arch Linux en ProtonDB

\n

Durante años, Arch Linux ha sido la referencia para muchos jugadores que querían exprimir al máximo su hardware bajo Linux. Su filosofía de «hágalo usted mismo», con una base mínima y paquetes siempre muy actualizados, ha sido sinónimo de control total a costa de exigir conocimientos técnicos que no todo el mundo está dispuesto a adquirir.

\n

Frente a esa propuesta, CachyOS plantea algo distinto: sigue siendo una distribución basada en Arch, pero se entrega ya preparada para usar desde el primer arranque, con una configuración más amigable y un gran énfasis en la optimización. La idea es que el sistema saque más partido del procesador y del resto de componentes del PC mediante compilaciones y ajustes pensados para ganar velocidad y estabilidad, algo especialmente atractivo para quienes priorizan un rendimiento sólido en juegos sin tener que montar el sistema pieza a pieza.

\n

Según los datos recopilados por distintos portales especializados como Boiling Steam, los reportes enviados desde CachyOS a ProtonDB han superado en número a los de Arch Linux. ProtonDB, muy conocido entre la comunidad europea de jugadores en Linux, es la plataforma donde miles de personas informan de cómo les funcionan los juegos de Windows ejecutados a través de Proton, detallando si el título va perfecto, requiere ajustes o presenta problemas relevantes.

\n

Que CachyOS marque ahora la pauta no significa que sea automáticamente «la mejor distro para jugar» para todo el mundo, pero sí refleja que cada vez más jugadores comprometidos están apostando por ella. Son usuarios que no solo juegan, sino que se toman el tiempo de probar, medir, documentar y compartir sus resultados, algo que suele anticipar tendencias que luego terminan extendiéndose al resto de la comunidad.

\n

Dos años de crecimiento hasta alcanzar el primer puesto

\n

El ascenso de CachyOS no ha sido un golpe de suerte ni un fenómeno de moda repentina. Los datos publicados apuntan a un crecimiento sostenido a lo largo de aproximadamente dos años. En las gráficas compartidas por Boiling Steam se aprecia cómo la distribución empieza a ganar visibilidad con fuerza a comienzos de 2024, para terminar adelantando a Arch Linux en número de reportes de ProtonDB.

\n

Desde 2021, Arch Linux había acumulado la mayor cantidad de informes de rendimiento en la plataforma, lo que reflejaba su popularidad entre los jugadores más tecnófilos. El hecho de que CachyOS haya roto esa racha histórica indica que parte de ese perfil de usuario está migrando hacia una solución que ofrece un punto intermedio: mantiene la base Arch, con su rapidez a la hora de recibir software reciente, pero reduce la complejidad de la configuración inicial y añade optimizaciones adicionales para mejorar la experiencia.

\n

En Europa y en España, donde el uso de Linux para tareas de desarrollo y servidores está bastante asentado, esta tendencia empieza a notarse también en el ámbito doméstico. Cada vez más jugadores que ya utilizaban Linux para trabajar o estudiar se plantean aprovechar el mismo sistema para sus ratos de ocio, y una distro más accesible y centrada en rendimiento resulta especialmente atractiva en este contexto.

\n

Qué nos cuentan realmente los datos de ProtonDB

\n

Aun así, los responsables de los análisis piden cautela a la hora de interpretar estos resultados. Desde Boiling Steam se recalca que las estadísticas de ProtonDB describen a un segmento muy específico de usuarios: personas que juegan en Linux y además se implican activamente en reportar el rendimiento de sus partidas. No es, por tanto, una fotografía directa de todo el ecosistema Linux ni de todos los gamers que usan el sistema.

\n

También se subraya que estos informes pueden no representar al conjunto de usuarios profesionales de Linux ni al total de jugadores casuales. Es difícil imaginar, por ejemplo, que un arquitecto de sistemas en la nube vaya a basar sus servidores en CachyOS solo porque lidere las estadísticas de ProtonDB. Aun así, muchos analistas coinciden en que este tipo de cambios suele ser un buen indicador de hacia dónde puede moverse el mercado más amplio a medio plazo.

\n

Ya hubo señales parecidas en el pasado con distribuciones como Manjaro, que llegó a gozar de una presencia muy notable entre los entusiastas y, poco a poco, fue perdiendo terreno frente a alternativas consideradas más modernas o mejor mantenidas. El desplazamiento de Arch Linux por parte de CachyOS en los reportes de ProtonDB podría ser un síntoma de que parte de la comunidad busca una combinación distinta de control, facilidad de uso y rendimiento.

\n

Sin influencia de Steam Deck: solo equipos de sobremesa

\n

Un matiz importante de la estadística es que Steam Deck no entra en la ecuación. Boiling Steam aclara que los datos que analizan se refieren únicamente a ordenadores de escritorio tradicionales, excluyendo la consola portátil de Valve, que utiliza su propio sistema basado en Arch (SteamOS) y que en las gráficas aparece categorizado aparte, por ejemplo bajo la etiqueta HoloISO.

\n

Esto significa que el liderazgo de CachyOS frente a Arch Linux en ProtonDB se debe estrictamente a usuarios de PC de sobremesa y portátiles, no al enorme empuje que Steam Deck ha dado al gaming en Linux en los últimos años. De hecho, el gran parque de consolas de Valve podría haber distorsionado por completo las cifras si se hubiese mezclado en la misma categoría que las instalaciones de Arch Linux en escritorio.

\n

Al separar claramente estos entornos, el cambio de posición cobra un significado distinto: hablamos de una competencia directa en equipos de escritorio, donde los usuarios eligen distribución en función de la combinación de rendimiento, estabilidad, facilidad de instalación y soporte de la comunidad. En esa carrera, CachyOS parece estar ganando presencia frente a la tradición y veteranía de Arch.

\n

Por qué CachyOS resulta atractiva para jugadores exigentes

\n

Más allá de las cifras, hay varios factores que ayudan a entender por qué CachyOS está calando entre los gamers que usan Linux. Uno de los principales es su enfoque en la optimización del rendimiento, que va desde la selección de kernels y compilaciones ajustadas hasta configuraciones predeterminadas pensadas para aprovechar mejor la CPU y la GPU sin que el usuario tenga que afinarlo todo a mano.

\n

Ese enfoque reduce una de las barreras clásicas de Arch Linux: el tiempo y los conocimientos necesarios para dejar el sistema perfectamente preparado para jugar. Con CachyOS, muchos usuarios encuentran un camino intermedio: siguen disfrutando de un entorno de base Arch, con software reciente y mucha flexibilidad, pero con menos esfuerzo inicial para alcanzar un resultado fluido en títulos modernos ejecutados vía Proton o nativamente.

\n

En el caso de España y otros países europeos, donde cada vez hay más interés por alternativas a Windows para el día a día, esta propuesta encaja bien con el perfil de jugador que quiere un solo sistema operativo para trabajar y jugar sin tener que lidiar con instalaciones complicadas. El hecho de que la comunidad en torno a CachyOS esté muy centrada en el rendimiento en juegos refuerza su atractivo para quienes buscan exprimir al máximo su hardware sin sacrificar demasiado tiempo en configuraciones avanzadas.

\n

Todo este movimiento alrededor de CachyOS, ProtonDB y el desplazamiento de Arch Linux como distro con más reportes de rendimiento no supone un cambio radical de un día para otro, pero sí dibuja un escenario en el que las preferencias de los jugadores de escritorio en Linux empiezan a reordenarse. Si la tendencia se mantiene, es probable que veamos a más usuarios europeos y españoles interesarse por distribuciones enfocadas en el rendimiento y la facilidad de uso, mientras que proyectos como Arch seguirán siendo la elección de quienes valoran por encima de todo el control absoluto y la personalización extrema.

from Linux Adictos https://ift.tt/OHzkoM7
via IFTTT

La actualización a FFmpeg 8.1, de nombre en clave «Hoare», marca un punto importante en la evolución de este conocido framework multimedia de código abierto. La nueva versión estable llega con un foco claro en la aceleración por GPU, la gestión avanzada de metadatos y la incorporación de códecs y formatos emergentes, cambios que interesan tanto a usuarios finales como a profesionales del vídeo.

El equipo de desarrollo recomienda de forma expresa que todos los usuarios, distribuidores e integradores que no trabajen con la rama git más reciente actualicen a FFmpeg 8.1. Más allá de las mejoras internas y correcciones de errores, se introducen capacidades que pueden simplificar flujos de trabajo complejos, sobre todo en entornos de posproducción, streaming y herramientas de análisis multimedia.

Nueva versión estable FFmpeg 8.1 «Hoare» y contexto del lanzamiento

FFmpeg 8.1 se publica como versión estable sucesora de FFmpeg 8.0, lanzada a mediados de 2025, y consolida meses de desarrollos que hasta ahora solo estaban disponibles en el repositorio principal. La fecha de salida de esta iteración se sitúa a mediados de marzo de 2026, y el proyecto la presenta como la referencia recomendada frente a versiones anteriores, tanto para uso doméstico como para distribuciones Linux, soluciones comerciales y sistemas integrados.

En esta entrega se combinan nuevas funciones experimentales (como algunos decodificadores de audio de nueva generación) con características ya maduras relacionadas con la aceleración hardware y la gestión de contenidos multimedia profesionales. Todo ello se complementa con un paquete de correcciones de errores y pequeños retoques en distintas áreas de la herramienta de línea de comandos y las bibliotecas subyacentes.

Impulso a la aceleración de vídeo con Vulkan

Uno de los bloques más destacados de FFmpeg 8.1 es el refuerzo del soporte para Vulkan como plataforma de cómputo. El proyecto incorpora aceleración con shaders de cómputo Vulkan para realizar tanto codificación como decodificación de vídeo en códecs que no están cubiertos por las extensiones oficiales de Vulkan Video. Esta aproximación permite descargar más trabajo del procesador y mantener el flujo de datos dentro de la GPU.

La novedad más visible en este terreno es la implementación de códecs Apple ProRes y DPX basada íntegramente en Vulkan. Hasta ahora, muchos flujos mezclaban pasos en CPU y GPU, con transferencias de memoria de ida y vuelta que penalizaban la latencia y complicaban el mantenimiento del código. Con FFmpeg 8.1 se apuesta por que los datos permanezcan dentro de la memoria gráfica mientras se procesan, reduciendo cuellos de botella en cadenas de posproducción exigentes como las que se utilizan en estudios y plataformas de emisión.

Además, se introducen optimizaciones específicas para códecs basados en Vulkan y soporte para realizar escalado de vídeo mediante la infraestructura «swscale» aprovechando esta API. Esta integración abre la puerta a que aplicaciones que se apoyan en FFmpeg puedan combinar decodificación, procesado intermedio y recodificación sobre Vulkan sin tener que pasar por la CPU en cada paso intermedio.

Direct3D 12: codificación H.264 y AV1 en la GPU

En sistemas Windows, FFmpeg 8.1 refuerza también la parte de aceleración con la llegada de codificación H.264 y AV1 mediante Direct3D 12 (D3D12). Este soporte permite manejar flujos de vídeo directamente en la GPU en pipelines basados en D3D12, algo relevante para estaciones de trabajo y soluciones de streaming que funcionan sobre hardware moderno de fabricantes como AMD, Intel o NVIDIA.

Junto a la codificación, se incorporan nuevos filtros específicos para D3D12, como scale_d3d12 (escalado), mestimate_d3d12 (estimación de movimiento) y deinterlace_d3d12 (desentrelazado). Estos filtros facilitan que tareas de preprocesado habituales —redimensionado, análisis de movimiento y limpieza de contenidos entrelazados— se ejecuten en la GPU sin abandonar el entorno D3D12, lo que ayuda a crear flujos de trabajo de «GPU encoding» más coherentes y eficientes.

Novedades en códecs de vídeo: JPEG-XS y metadatos LCEVC

En el terreno de los códecs de vídeo, FFmpeg 8.1 introduce soporte inicial para JPEG-XS, un estándar pensado para compresión de baja latencia y alta calidad, habitual en entornos de producción y distribución profesional. La nueva versión añade un analizador (parser) específico para JPEG-XS, así como soporte de codificación y decodificación apoyado en el proyecto SVT-JPEG-XS a través de la biblioteca libsvtjpegxs.

Además de poder leer y generar flujos de este formato, la herramienta incorpora funciones para multiplexar y desmultiplexar bitstreams JPEG-XS en bruto. Esto es especialmente útil para integradores que manejan enlaces de contribución, sistemas de transporte profesional o infraestructuras broadcast, incluidos los despliegues sobre redes IP que se están extendiendo en Europa.

Por otro lado, se suma soporte para metadatos LCEVC (Low Complexity Enhancement Video Coding), incluyendo análisis, transporte y filtrado de bitstreams con esta información asociada. Aunque LCEVC actúa como capa de mejora sobre códecs ya implantados, disponer de soporte directo en FFmpeg facilita la experimentación y el despliegue en servicios de vídeo bajo demanda, plataformas OTT y pruebas piloto que se están llevando a cabo en distintos países.

Avances en audio: xHE-AAC, MPEG-H 3D Audio e IAMF

El audio también recibe una atención notable. FFmpeg 8.1 incorpora de forma experimental decodificación xHE-AAC Mps212, una variante de alto rendimiento del conocido códec AAC, utilizada en servicios de streaming adaptativo y emisiones digitales. Aunque su estado se considera todavía experimental, permite empezar a trabajar con este formato dentro de flujos de análisis o conversión.

Se añade asimismo la posibilidad de decodificar MPEG-H 3D Audio a través de la biblioteca libmpeghdec. Este estándar de audio tridimensional, empleado en algunos entornos de radiodifusión avanzada y experiencias inmersivas, gana así presencia en herramientas que dependen de FFmpeg, algo especialmente relevante para emisoras y productoras que preparan contenidos inmersivos.

En paralelo, se amplía el manejo de audio espacial dentro de IAMF (Immersive Audio Model and Formats). FFmpeg ahora es capaz de tratar un abanico mayor de elementos de audio espacial, incluyendo el soporte para muxing y demuxing de elementos Ambisonic en el modo de proyección IAMF. Estas capacidades resultan útiles para aplicaciones de realidad virtual, experiencias inmersivas y plataformas que buscan ofrecer sonido 3D con mayor precisión.

Metadatos e imágenes: EXIF y nuevas posibilidades

Otra área reforzada es la gestión de metadatos, donde FFmpeg 8.1 incorpora un nuevo sistema de análisis de metadatos EXIF. Gracias a esta función, el framework puede leer con más precisión información de captura y atributos asociados a imágenes fijas y ciertos tipos de contenidos multimedia, como datos de cámara, orientación, fecha u otros campos técnicos.

Para profesionales que trabajan con grandes volúmenes de imágenes o secuencias fijas —como en flujos de postproducción, archivística o fotoperiodismo—, este mejor tratamiento de EXIF facilita automatizar clasificación, filtrado y recuperación de contenido. También abre la puerta a crear herramientas específicas para la gestión de catálogos, ya que la extracción de metadatos se integra de forma nativa en el ecosistema FFmpeg.

Formatos y contenedores: HXVS/HXVT e IAMF

En cuanto a formatos y contenedores, FFmpeg 8.1 incorpora un nuevo demultiplexor «hxvs» capaz de analizar el contenedor HXVS/HXVT, un formato utilizado en cámaras IP. Esta incorporación responde a la creciente adopción de sistemas de videovigilancia y monitorización basados en IP en Europa, donde la capacidad de inspeccionar y convertir flujos de cámaras es clave para integradores y empresas de seguridad.

La expansión en los tipos de elementos de audio espacial que pueden tratarse dentro de IAMF se suma a este bloque de novedades relacionadas con formatos. Juntas, estas mejoras refuerzan el rol de FFmpeg como herramienta de referencia para manejar contenedores y flujos complejos, tanto en entornos de producción como en sistemas de monitorización o análisis en tiempo real.

Funciones específicas de hardware y captura

El listado de mejoras incluye también nuevas capacidades ligadas a hardware concreto. En FFmpeg 8.1 se incorpora soporte para codificación por hardware H.264 y HEVC en plataformas Rockchip. Este tipo de SoC, presente en mini-PC, dispositivos embebidos y soluciones de bajo consumo, tiene una presencia creciente en proyectos de cartelería digital, pasarelas multimedia y sistemas IoT.

Se añade asimismo la posibilidad de realizar captura de ventanas y monitores basada en la API Windows.Graphics.Capture. Esta función facilita la grabación y el streaming de escritorio en sistemas Windows modernos con menores limitaciones que aproximaciones antiguas, algo útil tanto para creadores de contenido como para soluciones corporativas de formación o soporte remoto.

Por el lado de AMD, FFmpeg 8.1 estrena un nuevo filtro vpp_amf que aprovecha las capacidades de vídeo del hardware de la marca. Este filtro se integra en la ya amplia gama de herramientas de procesado basadas en GPU, y puede aprovecharse para tareas como escalado, conversión de formatos o mejora de imagen dentro de pipelines que apoyan su carga en la aceleración por hardware.

Mejoras en las herramientas de línea de comandos

Las utilidades incluidas en FFmpeg también reciben pequeños ajustes. Entre ellos destaca la incorporación de la opción «ffprobe -codec», que permite obtener información centrada en los códecs al analizar flujos de audio y vídeo. Esta mejora es especialmente útil para desarrolladores y administradores que utilizan ffprobe como parte de scripts de monitorización o validación de contenidos.

Otra novedad es la capacidad de mostrar únicamente los campos «refs» de la sección de flujo al cargar fotogramas con ffprobe, lo que ayuda a inspeccionar estructuras de referencia de vídeo sin ruido adicional. Paralelamente, se ha eliminado el antiguo manejador del protocolo HLS, simplificando el código y confiando en implementaciones más modernas que ya estaban integradas en el proyecto.

Correcciones, mejoras internas y recomendación de actualización

Además de las funcionalidades visibles, FFmpeg 8.1 llega acompañado de un número considerable de correcciones de errores y ajustes internos que mejoran la estabilidad general. Aunque muchas de estas modificaciones no se ven directamente en la interfaz de usuario o en las opciones de línea de comandos, contribuyen a que las aplicaciones basadas en FFmpeg funcionen de manera más predecible.

En conjunto, la combinación de nuevas funciones, soporte ampliado de hardware y codecs emergentes hace que el proyecto recomiende con claridad actualizar a FFmpeg 8.1 siempre que no se utilice ya la rama git más reciente. Tanto distribuidores de software como proveedores de servicios de vídeo encontrarán en esta versión una base más sólida para sus productos y plataformas.

Con todo este paquete de cambios, FFmpeg 8.1 consolida su papel como pieza central en flujos de trabajo de vídeo y audio, desde la creación de contenidos hasta la emisión y el análisis técnico: la ampliación del soporte para Vulkan y D3D12, la integración de códecs como JPEG-XS, xHE-AAC o MPEG-H 3D Audio, y las mejoras en metadatos, audio inmersivo y utilidades de línea de comandos sitúan a esta versión como una actualización especialmente relevante para quienes trabajan a diario con medios digitales.

from Linux Adictos https://ift.tt/N5YItPR
via IFTTT

La comunidad de Linux ha seguido con interés el pulso de Manjaro durante años. Con su promesa de “Disfruta la sencillez” y una rama estable que prioriza la fiabilidad, Manjaro ha sido para muchos usuarios una puerta de entrada amable al ecosistema Arch sin el tirón de una configuración manual constante. Sin embargo, recientes corrientes en la comunidad indican que el proyecto podría estar atravesando un periodo de cambios profundos que podrían modificar su esencia tal como la conocíamos. Este artículo explora el contexto, las señales y las posibles direcciones que podría tomar Manjaro a partir de ahora, desde la perspectiva de un usuario y observador veterano.

El punto de inflexión parece haber llegado en 2019, cuando algunos usuarios comenzaron a afirmar que Manjaro habría dejado de ser «solo una distribución» y se aproximaría a convertirse en una entidad de mayor alcance. Aunque estas piezas de análisis deben tratarse con cautela, es innegable que la comunidad ha percibido un cambio de ritmo: se habla de mayor centralización, de nuevas dinámicas de contribución y de una relevancia institucional que no se limitaba a la comunidad de usuarios, sino que se extendía hacia foros, repositorios y, en algunos casos, hacia la percepción pública de la marca.

El reciente Manifesto de Manjaro 2.0, publicado por Aragorn en el foro oficial, llega para situar el debate en un plano más estructurado. En él se plantea la necesidad de cambios en el proyecto, con la finalidad de recuperar confianza, atraer colaboradores y revertir una tendencia de caída que, según algunos usuarios, iba más allá de simples errores puntuales. Entre las prioridades se menciona volver a una filosofía centrada en la comunidad, manteniendo las tres ramas clásicas (unstable, testing y stable) y la base Arch, pero con una organización y una visión que respondan a las exigencias del momento. Este giro, si se consolida, podría marcar un nuevo capítulo para la distribución sin perder la esencia que le dio popularidad.

¿Qué podría ocurrir a partir de ahora? Las opciones se debaten en dos grandes líneas. Por un lado, los desarrolladores podrían obtener una licencia que permita sostener la marca Manjaro y asegurar continuidad sin dañar la experiencia de usuario; por otro, la posibilidad de una bifurcación (fork) se mantiene como una opción menos deseable para muchos, pero no descartable ante posibles divergencias en la visión de futuro. En cualquier escenario, se espera que la comunidad publique guías sobre cómo seguir utilizando Manjaro con la menor fricción posible, incluso si el rumbo evoluciona hacia una distribución resultante de una reconfiguración o reorientación de la marca.

En cuanto a alternativas viables, desde mi punto de vista hay dos candidatas que podrían encajar con la necesidad de una experiencia Arch-like, pero con enfoques diferentes. EndeavourOS continúa destacándose por su cercanía a Arch, con un instalador y un flujo de trabajo que simplifica el proceso para usuarios que quieren control y frescura sin perder estabilidad. Por otro lado, CachyOS se presenta como una opción interesante para usuarios que valoran optimización y rendimiento, manteniendo la base Arch y una filosofía de eficiencia que podría complementar la experiencia de quienes buscan personalización avanzada sin abandonar el ecosistema familiar de Manjaro.

En definitiva, el futuro de Manjaro podría depender de la capacidad de la comunidad para consolidar una visión compartida que combine la cercanía al usuario, la transparencia del desarrollo y una gestión de riesgos que preserve la confianza. Habrá que esperar a ver cómo evolucionan las discusiones, qué decisiones se toman y qué impacto tendrán en la experiencia de uso diaria. Mientras tanto, los usuarios pueden evaluar alternativas que mejor se ajusten a sus necesidades y estilo de trabajo, recomendando una exploración equilibrada entre mantenerse con Manjaro bajo su nuevo marco o migrar a una opción que ofrezca una ruta clara hacia la productividad y la estabilidad.

from Linux Adictos https://ift.tt/3EFhmYj
via IFTTT

El proyecto IPFire ha anunciado la disponibilidad de una nueva versión candidata para su sistema firewall. Se trata de IPFire 2.29 – Core Update 201, que ya puede descargarse y probarse, e incluye una de las funcionalidades más esperadas por su comunidad: su propio cortafuegos DNS integrado.

Esta actualización, además de la gran novedad, llega con una actualización masiva de su cadena de herramientas (toolchain), decenas de paquetes actualizados y mejoras en toda la base del sistema. Al ser una versión de pruebas, los desarrolladores invitan a los usuarios con equipos no productivos a probarla y reportar incidencias para pulir el lanzamiento estable.

IPFire 2.29 Core Update 201: adiós al filtro URL, hola DNS Firewall

El plato fuerte de esta versión es, sin duda, el nuevo DNS Firewall. Esta función transforma IPFire de un simple guardián de red a un eliminador activo de amenazas. Funciona de manera transparente: se sitúa dentro del proxy DNS y evalúa cada consulta contra la lista de bloqueos DBL (mantenida y actualizada por el proyecto) antes de que la respuesta llegue al cliente. Si un dominio está bloqueado, el cliente recibe una respuesta NXDOMAIN, como si el dominio no existiera, impidiendo cualquier conexión maliciosa.

Las ventajas son notables. El DNS Firewall reemplaza por completo al antiguo Filtro URL (que requería configuración compleja en los clientes) y a la necesidad de usar soluciones externas como Pi-hole. Al estar integrado en el firewall, no requiere hardware adicional, configuración en los dispositivos de la red, y aprovecha que todo el tráfico DNS ya pasa por IPFire. Las actualizaciones de las listas de bloqueo se entregan por IXFR (transferencias de zona DNS incrementales) directamente al proxy, por lo que se actualizan cada hora de forma automática y eficiente.

Además de esta función estrella, la actualización 201 incluye un largo listado de mejoras:

• Sistema de Prevención de Intrusiones (IPS): Ahora permite configurar diferentes destinatarios para los informes diarios, semanales y mensuales.
• Arquitectura RISC-V: Se ha actualizado la configuración del kernel para la compilación experimental en estos dispositivos.
• Instalador de Red: Asigna más espacio en disco cuando se arranca desde la red, para acomodar el mayor tamaño de la ISO.
• Limpieza: Se han eliminado paquetes Rust obsoletos y el add-on `7zip` (por no estar mantenido), reduciendo la superficie de ataque.
• Actualización de la cadena de herramientas: Se ha actualizado la base del sistema con glibc 2.43 y GNU binutils 2.46.0, mejorando el soporte de hardware y la seguridad general.
• Paquetes actualizados: Se incluyen nuevas versiones de componentes fundamentales como OpenSSL 3.6.1, OpenVPN 2.6.19, BIND 9.20.20, Samba 4.23.5, entre muchos otros. La lista completa incluye también `iptables`, `vim`, `git`, `nano` y las herramientas de archivo.

Esta es una oportunidad para que la comunidad contribuya probando la nueva funcionalidad y reportando cualquier problema en el foro oficial o en el gestor de incidencias del proyecto.

from Linux Adictos https://ift.tt/ZETOlkW
via IFTTT

El equipo de desarrollo de SparkyLinux ha lanzado una nueva actualización de sus imágenes ISO para la rama semi-rolling. Se trata de SparkyLinux 2026.03, que llega con el nombre en clave «Tiamat» y trae consigo lo último del repositorio de Debian Testing, actualizado al 14 de marzo de 2026.

Como es habitual en su modelo de desarrollo, esta nueva versión no introduce una nueva rama, sino que actualiza los instaladores para quienes deseen hacer una instalación limpia. Los usuarios que ya tengan una edición Rolling en sus equipos no necesitan descargar nada; con mantener su sistema actualizado (apt update && apt upgrade) tendrán todos estos paquetes desde hace días.

SparkyLinux 2026.03 Tiamat: Novedades y Detalles Técnicos

Esta actualización pone especial énfasis en ofrecer el hardware más reciente gracias a su núcleo. Por defecto, las nuevas imágenes incorporan el kernel Linux 6.19.6, aunque los repositorios de Sparky ya tienen preparadas otras alternativas como la serie 7.0-rc3, la 6.19.8, o las LTS 6.18.18 y 6.12.77 para quienes prefieran máxima estabilidad.

En el apartado de aplicaciones, encontramos las versiones ESR (Extended Support Release) de Firefox y Thunderbird, concretamente la 140.8. Pero si necesitas lo último del navegador de Mozilla, también puedes instalar la versión Firefox 148 directamente desde los repositorios de la distribución.

La instalación también recibe mejoras. Se ha actualizado el instalador gráfico Calamares a la versión 3.4.2, que ahora técnicamente permite contraseñas de un solo carácter durante el proceso, aunque los desarrolladores recomiendan encarecidamente usar una contraseña segura de entre 8 y 12 caracteres. Por otro lado, el instalador por línea de comandos (sparky-installer) ahora ofrece la posibilidad de instalar la versión ia32 de GRUB para UEFI en máquinas de 64 bits.

Un detalle importante para equipos modernos: si tu equipo usa UEFI, la instalación requiere una conexión a internet activa, y se recomienda usar el instalador gráfico Calamares. Para equipos más antiguos con BIOS, tanto el instalador CLI como el gráfico funcionan sin problemas.

SparkyLinux 2026.03 está disponible para arquitectura amd64 en múltiples sabores, incluyendo LXQt, KDE Plasma, MATE, Xfce, una versión MinimalGUI con Openbox, y una MinimalCLI solo para terminal. Puedes encontrar las nuevas imágenes en la página de descarga del proyecto.

En resumen, SparkyLinux 2026.03 Tiamat ofrece soporte actualizado de Debian Testing, opciones de kernel modernas, variantes de entornos de escritorio, y mejoras en el proceso de instalación que facilitan tanto a usuarios noveles como a aquellos que prefieren un enfoque más técnico. Si buscas un sistema estable y a la vez actualizable con un enfoque ligero y modular, esta entrega merece una revisión para planificar una instalación limpia o una actualización segura en equipos compatibles.

from Linux Adictos https://ift.tt/VMjHsKn
via IFTTT

Si usas Arch Linux o alguna de sus derivadas (EndeavourOS, Manjaro, Artix, etc.), tarde o temprano acabas topándote con los repositorios AUR y los famosos asistentes yay y paru. Todo el mundo habla de ellos, se recomiendan en foros, aparecen en casi todas las guías, pero cuando intentas decidir cuál usar, las diferencias no siempre quedan tan claras.

En las siguientes líneas vamos a desgranar con calma qué ofrece cada uno, qué opiniones reales tiene la comunidad, qué mitos hay alrededor de que “yay está muerto” o “paru es mucho más rápido”, y en qué casos compensa cambiar de uno a otro. La idea es que, al terminar, tengas argumentos sólidos para elegir asistente sin comerte demasiado la cabeza.

Qué son yay y paru y por qué todo el mundo los usa

A grandes rasgos, tanto yay como paru son asistentes de AUR que automatizan el trabajo de buscar, compilar e instalar paquetes del AUR, además de gestionar paquetes de los repos oficiales usando pacman por debajo. Es decir, en lugar de ir manualmente a la web de AUR, descargar el PKGBUILD, ejecutar makepkg y luego instalar el paquete, ellos hacen todo eso de una tacada.

En entornos Arch y derivados es muy habitual querer acceder al inmenso catálogo de software disponible en AUR. Ahí encuentras aplicaciones que no están en los repos oficiales, versiones git, parches experimentales o simplemente programas que nadie ha empaquetado oficialmente; por ejemplo, guías para instalar Visual Studio Code en Arch. Para gestionar todo eso con cierta comodidad, la mayoría acaba usando un asistente, y ahí es donde entran en juego yay y paru como dos de las opciones más populares.

Yay lleva ya muchos años siendo uno de los nombres de referencia: es conocido, documentado, tiene una comunidad enorme y aparece por defecto en distros como EndeavourOS. Paru, por su parte, es más reciente, pero ha ganado bastante tracción porque ofrece una aproximación algo más estricta y segura al flujo de trabajo del AUR, y porque su autor estuvo relacionado con el desarrollo de yay en el pasado.

Diferencias técnicas: Go vs Rust, diseño y filosofía

Un punto que suele salir en todos los debates es que yay está escrito en Go y paru está escrito en Rust. Técnicamente esto importa menos al usuario final de lo que a veces se sugiere, pero sí dice algo del enfoque de cada proyecto.

Yay, desarrollado en Go, se inspira en antiguos asistentes como yaourt, apacman y pacaur. Su código resulta relativamente sencillo de leer y extender para quien domine Go, y una de sus virtudes históricas ha sido justamente que la compilación es rápida y poco dolorosa. Esa base ha permitido que se mantenga vivo incluso tras cambios en el equipo de desarrollo.

Paru, en cambio, está implementado en Rust y bebe directamente de la experiencia de yay, tanto en funcionalidades como en diseño de la interfaz de línea de comandos. Gracias a ello, migrar de yay a paru resulta muy sencillo: muchos comandos y opciones se sienten casi iguales, por lo que no hay que reaprenderlo todo desde cero.

A nivel filosófico, paru pone algo más de énfasis en la seguridad y la revisión de PKGBUILDs, mientras que yay ha tendido históricamente a priorizar un flujo más rápido y cómodo por defecto. Esa diferencia se ve con claridad en cómo cada uno te presenta los archivos antes de construir los paquetes.

Velocidad: ¿es paru realmente más rápido que yay?

Uno de los argumentos más repetidos en foros y redes es que paru es “más rápido” que yay. Aquí conviene matizar. Varios usuarios con hardware potente y buena conexión (por ejemplo, fibra de 1 Gbps) comentan que, en la práctica, la sensación de velocidad entre uno y otro es muy similar. En sistemas así, a menudo el cuello de botella es la descarga o la propia compilación del software, no tanto el asistente.

Aun así, hay quien ha comparado ambos en máquinas más modestas y asegura que paru realiza ciertas operaciones algo más deprisa, especialmente cuando se hacen búsquedas, sincronizaciones o actualizaciones globales que implican tanto repos oficiales como AUR. Esa diferencia no suele ser brutal, pero en equipos con pocos recursos o discos lentos puede notarse unos segundos de mejora aquí y allá.

La otra cara de la moneda es que paru te fuerza por defecto a revisar los PKGBUILDs antes de compilar. Esto añade un paso interactivo que, obviamente, consume tiempo humano (aunque sea poco). Algunos usuarios perciben esto como un “ralentizador”, mientras que otros lo consideran un compromiso razonable porque aporta seguridad y transparencia.

En resumen, si tienes un ordenador moderno y una buena conexión, las diferencias en velocidad entre yay y paru van a ser muy pequeñas. Donde realmente puede merecer la pena inclinarse por paru es en sistemas limitados donde cada segundo cuenta, o si quieres un asistente que esté optimizado hasta el detalle y notes esa ligera ventaja.

Sintaxis y experiencia de uso: lo que se siente al teclear

Más allá de benchmarks y discusiones técnicas, muchos usuarios se quedan con yay por un motivo bastante mundano: es muy cómodo de escribir. Hay quien comenta que literalmente “machaca las dos teclas a la vez” para lanzar yay porque es corto, fácil de recordar y de autocompletar en la terminal.

Paru tampoco es que sea un nombre horrible, pero algunas personas comentan que su sintaxis se les hace un poco más “tosca” al usarlo diariamente. No es que los comandos sean muy diferentes, pero la costumbre pesa, y quienes llevan años con yay sienten que el flujo de uso es más natural y rápido, tanto mentalmente como al teclear.

En cualquier caso, ambos asistentes proporcionan atajos, opciones interactivas y banderas muy similares. Por ejemplo, funciones como mostrar un menú combinado de actualizaciones de repos y AUR con detalles de versión están disponibles en los dos. En yay existe la opción --combinedupgrade, que muestra un listado coloreado con qué se va a actualizar y de qué versión a cuál. En paru se consigue algo equiparable mediante la opción --upgrademenu, que ofrece un menú detallado de actualizaciones.

Un detalle curioso que aparece en algunos hilos es que hay usuarios que incluso crean alias como yaya para yay, porque les resulta todavía más cómodo y divertido invocarlo así. Esto ilustra bien hasta qué punto la ergonomía y la costumbre tienen un peso muy real a la hora de elegir asistente.

Dónde guarda cada uno los paquetes compilados

Otro aspecto interesante que suele pasar desapercibido es la gestión de los paquetes ya construidos (los .pkg.tar.zst). Aquí yay y paru se comportan de forma ligeramente diferente, y eso afecta a cómo se integran con las rutas típicas de Arch.

Por defecto, makepkg coloca los paquetes construidos en el directorio de compilación. Esa ruta puede ajustarse mediante la variable PKGDEST en /etc/makepkg.conf, de modo que podrías, por ejemplo, enviarlos a /var/cache/pacman/pkg/ para centralizar los binarios empaquetados.

En el caso de paru, este respeta el comportamiento habitual de makepkg: los paquetes terminan en el directorio de compilación asociado a paru, normalmente algo como ~/.cache/paru/clone/$pkgname/. Si quieres modificar esa ruta globalmente, puedes usar la opción BuildDir en /etc/paru.conf, reenviando las compilaciones a otro sitio.

Yay se comporta de forma algo distinta. Varios usuarios señalan que yay copia los paquetes construidos a /var/cache/pacman/pkg/ después de compilarlos, lo que en la práctica hace que tengas tus paquetes AUR en el mismo sitio que los paquetes oficiales gestionados por pacman. Esto es cómodo pero implica que yay está, en cierto modo, pisando lo que hayas definido en PKGDEST en /etc/makepkg.conf, algo que algunos consideran poco respetuoso con la configuración global del sistema.

Para el usuario medio esto no suele ser un drama, pero si eres muy tiquismiquis con la forma en que se organizan los binarios en tu máquina, puede ser un motivo para preferir el comportamiento más “limpio” de paru, o al menos para ser consciente de lo que está haciendo cada asistente con tus paquetes.

Nivel de mantenimiento y actividad de cada proyecto

En distintos debates se ha extendido la idea de que yay está abandonado o desfasado y que paru es su reemplazo natural. Esta afirmación viene en parte de que uno de los desarrolladores relacionados con yay pasó a centrarse en paru, y en algunos vídeos y posts se interpretó eso como que el proyecto yay moría o quedaba sin mantenimiento.

Varios usuarios y desarrolladores han desmentido esa narrativa de forma tajante: yay sigue teniendo mantenimiento activo, con commits frecuentes en su repositorio y una comunidad bastante amplia detrás. De hecho, parte del enfado de algunos mantenedores viene precisamente de ver cómo se repite una y otra vez el mantra “yay está muerto” sin que la gente se moleste en comprobar el estado real del proyecto.

Al mismo tiempo, es cierto que paru muestra una actividad muy alta y constante, a veces incluso algo superior a la de yay en determinados periodos. Esto es lógico, ya que se trata de un proyecto relativamente nuevo, con muchas ganas de iterar y pulir detalles, y con un autor muy implicado que responde con rapidez a issues y peticiones de la comunidad.

En la práctica, para la persona que simplemente quiere instalar paquetes, estas diferencias de actividad rara vez se traducen en problemas. Ambos proyectos están vivos, reciben correcciones y nuevas funciones, y no hay nada que obligue a abandonar yay por miedo a que quede roto a corto plazo.

Seguridad, revisión de PKGBUILDs y filosofía de uso del AUR

Un punto clave donde sí se perciben diferencias claras de enfoque es cómo cada asistente trata la revisión de PKGBUILDs. Recordemos que AUR no es un repositorio oficial: son recetas enviadas por usuarios, y la responsabilidad final de revisarlas es tuya.

La comunidad de Arch insiste desde siempre en que hay que leer los PKGBUILDs antes de instalarlos, para evitar sorpresas desagradables (scripts maliciosos, descargas desde orígenes poco fiables, comandos peligrosos, etc.). Paru, alineado con esa filosofía, está configurado por defecto para mostrarte esa revisión y “obligarte” a prestarle atención antes de construir el paquete.

Yay, aunque también permite revisar los PKGBUILDs, facilita un flujo más “rápido y despreocupado” si quieres ir a tiro hecho. Esto gusta mucho a quien prioriza comodidad y confía en los mantenedores de AUR, pero también ha generado la percepción de que yay anima un poco más al “instalo sin mirar”, algo que no casa del todo con la mentalidad purista de Arch.

En cualquier caso, es importante recordar que, uses el asistente que uses, todo acaba pasando por makepkg y pacman. Es decir, ambos ayudan a automatizar la parte pesada, pero el modelo base sigue siendo el mismo: PKGBUILDs que se convierten en paquetes que pacman gestiona e instala. La responsabilidad de entender lo que instalas sigue siendo tuya.

Uso del AUR sin asistentes y el papel de pacman

En varios hilos también aparece una pregunta recurrente: “¿cómo actualizas paquetes del AUR sin usar un asistente?”. La respuesta ortodoxa, que enlaza directamente con la filosofía oficial de Arch, es clara: usando makepkg a mano con los PKGBUILDs correspondientes.

Los PKGBUILDs son recetas que definen cómo construir el paquete desde el código fuente o desde binarios precompilados, y una vez generado ese paquete, es pacman quien se encarga de instalarlo y de llevar el registro, igual que hace con los paquetes de los repos oficiales. No hay un tratamiento especial por ser “AUR”: para pacman, una vez empaquetado, todo es simplemente un paquete más.

Los asistentes como yay y paru no son más que capas de comodidad encima de ese flujo clásico de “bajar PKGBUILD → makepkg → pacman”. Hacen búsquedas, resuelven dependencias, automatizan descargas y compilaciones, y añaden menús y opciones útiles, pero no sustituyen ni modifican el rol de pacman como gestor central del sistema.

Por eso hay usuarios veteranos que presumen de no usar asistentes nunca y defender el método manual como el más transparente y controlable. Otros, la mayoría, prefieren ahorrar tiempo y tirar de yay o paru, confiando en que la automatización les simplifica la vida sin perder de vista del todo lo que están haciendo.

Paru y yay en distros derivadas: EndeavourOS, Manjaro, Artix…

En distros como EndeavourOS, yay suele venir preinstalado o recomendado como asistente principal. Esto marca bastante la experiencia de los recién llegados, que adoptan yay sin pensar demasiado porque es lo que trae el sistema y la documentación oficial. Posteriormente pueden descubrir paru y plantearse si merece la pena el cambio.

En algunos debates dentro de la propia comunidad de EndeavourOS se ha planteado si deberían pasar a incluir paru por defecto. Muchos usuarios y miembros del equipo han respondido que no ven una necesidad real de hacerlo, ya que yay sigue siendo una herramienta sólida, mantenida y bien conocida. En consecuencia, a corto y medio plazo, no parece que vaya a haber una sustitución masiva de yay por paru en esta distro.

En otras derivadas de Arch (Artix, Manjaro, etc.), la situación es parecida: lo importante es tener acceso al AUR y la posibilidad de usar un asistente, pero cuál uses al final suele depender de lo que recomiende la documentación, lo que diga la comunidad o simplemente de lo que probaste primero y te funcionó bien.

También es frecuente que se sugiera activar repositorios externos como Chaotic-AUR para facilitar la instalación de estos asistentes sin tener que compilar desde el propio AUR. En algunos tutoriales se explica cómo preparar el sistema, añadir dichos repos y luego instalar yay o paru directamente como paquetes binarios, evitando el paso de construcción manual inicial.

Instalar y convivir con ambos asistentes

Una opción que defienden bastantes usuarios, sobre todo quienes están probando cosas, es instalar tanto yay como paru y convivir con ambos una temporada. De esta forma puedes usar yay para lo que ya haces por costumbre y experimentar con paru en tareas puntuales, comparando sensaciones y características en tu propio hardware.

Al ser herramientas que se apoyan en pacman y makepkg, no se pisan ni rompen el sistema por coexistir. Puedes instalar paquetes con uno, listar actualizaciones con otro y seguir funcionando sin mayores dramas, siempre y cuando sepas qué estás haciendo. Cuando tengas claras tus preferencias, si quieres simplificar, puedes quedarte solo con el que más te convenza y desinstalar el otro.

En algunos casos específicos se recomienda instalar paru usando yay (ya que yay viene de serie en la distro), probarlo, y si te convence, cambiar tus scripts, alias y costumbres a paru y luego prescindir de yay. Pero, insistiendo una vez más, no hay obligación técnica de hacer este cambio; es más una cuestión de gustos y filosofía.

Por otro lado, hay quien prefiere seguir siempre el método “vanilla”: instalar los asistentes desde el propio AUR usando makepkg, para mantener la coherencia con la filosofía Arch pura y dura. En cualquiera de los casos, el resultado final es el mismo: tienes un asistente funcional que te simplifica el uso de AUR.

Mirando todos estos matices en conjunto, lo que se ve claro es que ambos asistentes cubren muy bien las necesidades del usuario medio de Arch: automatizar el trato con AUR, mantener el sistema al día y ofrecer ciertas comodidades que pacman, por diseño, no proporciona. Paru pone un poco más el foco en revisiones y en un rendimiento algo más afinado, mientras que yay ofrece una experiencia extremadamente familiar, rápida de teclear y con años de rodaje, lo que explica por qué tanta gente sigue fiel a él a pesar de la llegada de alternativas nuevas.

from Linux Adictos https://ift.tt/wUsmaIc
via IFTTT

Limine se está consolidando como una alternativa robusta y versátil a GRUB, especialmente para usuarios avanzados y desarrolladores de kernels. En este artículo exploramos qué es Limine, su propuesta multiprotocolo y qué lo diferencia de otros gestores de arranque, así como pautas de instalación y configuración en arquitecturas modernas.

Qué es Limine y por qué importa
Limine es un bootloader multiprotocolo, escrito principalmente en C y ensamblador, que implementa su propio protocolo de arranque, el Limine Boot Protocol. Funciona como un hub capaz de cargar Linux y otros kernels compatibles, y de chainload a otros bootloaders ya instalados. Su objetivo principal es ofrecer una alternativa más robusta a GNU GRUB y, al mismo tiempo, simplificar el proceso de arranque para desarrolladores de kernels al entregar un entorno de 64 bits preparado y menos dependiente de especificaciones heredadas como Multiboot o Multiboot2.

Arquitecturas y plataformas soportadas
Limine destaca por su portabilidad: soporta IA-32 (i686), x86-64, aarch64 (arm64), riscv64 y loongarch64, con soporte experimental para algunos escenarios Loongarch. En la práctica, puede arrancar sistemas x86-64, aarch64, riscv64 y loongarch64 con firmware UEFI. En términos simples, Limine apunta a cubrir la mayoría de PCs modernos, servidores y dispositivos ARM recientes, manteniendo compatibilidad con BIOS en modos específicos.

Protocolos de arranque admitidos
Una de las fortalezas de Limine es su capacidad para reconocer varios protocolos de arranque, lo que lo convierte en una especie de “hub” para distintos sistemas operativos y bootloaders. Entre los protocolos soportados se encuentran: Protocolo Linux, Protocolo Limine (propio del proyecto), Multiboot 1 y 2, y Chainloading para delegar el control a otro bootloader (p. ej., Windows o rEFInd). Este enfoque multiprotocolo facilita escenarios de multiboot donde conviven Linux, herramientas experimentales y bootloaders ya presentes en el disco.

Esquemas de particionado y sistemas de archivos
Limine admite MBR y GPT para particionado, así como medios sin particionar en determinadas situaciones. En cuanto a sistemas de archivos, Limine es deliberadamente minimalista: ofrece soporte nativo para FAT12, FAT16, FAT32 e ISO9660. Esta elección facilita la ubicación de los archivos de arranque (núcleo, initramfs, etc.) en particiones FAT o en medios ISO, manteniendo la raíz del sistema en otros sistemas de archivos como ext4, Btrfs o ZFS. En configuraciones UEFI típicas, el kernel y el initramfs residen en la ESP FAT32, mientras que la raíz puede estar en un sistema de archivos diferente.

Requisitos mínimos y compatibilidad
Para x86 de 32 bits, Limine garantiza soporte a partir de Pentium Pro / i686. Para 64 bits, todas las máquinas x86-64, aarch64, riscv64 y loongarch64 con UEFI quedan dentro del alcance. En resumen, Limine busca cubrir un espectro amplio de hardware moderno y simular un entorno de arranque estable para kernels personalizados.

Distribución, versiones y binarios precompilados
La vía principal para obtener Limine es su repositorio oficial en Codeberg. A partir de la versión 7.x, el proyecto utiliza versionado semántico (por ejemplo, 10.5.0). Además, existen ramas y etiquetas -binary con binarios precompilados para facilitar la instalación sin compilación. Esta distribución modular facilita el despliegue en distintas plataformas y entornos.

Instalación y despliegue: enfoques básicos
Existen dos enfoques principales: instalar Limine desde paquetes de la distribución (por ejemplo, Arch Linux) o clonar desde Codeberg las ramas de código fuente o binarios y compilar desde cero. En Arch Linux, por ejemplo, se recomiendan pasos para desplegar en UEFI (copiar BOOTX64.EFI a la ESP) y en BIOS (MBR y/o GPT con partición de arranque BIOS). La configuración básica de Limine requiere un limine.conf para definir las entradas y cómo se muestran en el menú de arranque.

Configuración en Arch Linux: limine.conf y herramientas auxiliares
La configuración en Arch suele realizarse en la ESP, con limine.conf ubicado junto al binario EFI o en la partición destinada a /boot. Limine no crea entradas NVRAM automáticamente; es necesario usar efibootmgr para registrar la entrada en el firmware. En BIOS, la instalación se realiza copiando limine-bios.sys y ejecutando limine bios-install /dev/sdX. Se pueden integrar herramientas como limine-entry-tool y limine-snapper-sync para generar y sincronizar entradas con snapshots de Btrfs, facilitando gestiones de backups y restauraciones.

Gentoo, Arch y Gentoo-Guía de configuración avanzada
En Gentoo, Limine está disponible en el árbol de ebuilds y puede requerir mascarado inicial. Las guías de Gentoo destacan la necesidad de un punto de montaje vfat en /boot (ESP) para UEFI y/o una partición FAT dedicada para BIOS. La sintaxis de limine.conf en Gentoo se actualizó para las versiones modernas, con ejemplos que muestran configuraciones para root en subvolúmenes Btrfs o raíces en ZFS, y entradas para microcódigo o initramfs. Se explica también la configuración para Dual Boot con Windows y el manejo de diferentes esquemas de particionado.

Automatización y soporte de comunidad
Limine cuenta con una comunidad activa y repositorios en Codeberg, además de presencia en distros como Arch, Gentoo y otras. Existen canales de ayuda (Matrix) y donaciones opcionales a través de Liberapay. En resumen, Limine ofrece un ecosistema maduro con documentación y herramientas para integrar con Memtest86+, Windows y administradores de snapshots.

Conclusión
Limine propone una alternativa moderna y flexible a los bootloaders tradicionales, con un enfoque multiprotocolo, amplia compatibilidad de arquitecturas y una sencillez en la gestión de archivos de arranque que puede adaptarse a entornos de desarrollo y multiboot. Aunque requiere una cierta planificación, especialmente en configuración y particionado FAT para /boot, ofrece una vía sólida para quienes buscan un control detallado del proceso de arranque y una plataforma estable para desplegar kernels personalizados.

from Linux Adictos https://ift.tt/VykJSMF
via IFTTT

Después de más de cuatro años de silencio, el clásico juego de plataformas de código abierto SuperTux 0.7.0 ha llegado para renovar por completo la experiencia del pequeño pingüino. Esta nueva versión, que bebe directamente de la esencia de los Super Mario, no solo actualiza sus gráficos, sino que replantea por completo la jugabilidad con nuevas habilidades y un diseño de niveles totalmente revisado.

El equipo desarrollador ha trabajado para pulir y expandir cada rincón del juego. Desde los fondos y objetos hasta los icónicos enemigos, todo ha sido revampizado visualmente. Pero lo más emocionante son las nuevas capacidades de Tux, que ahora puede deslizarse por pendientes, rodar como una roca, realizar poderosos saltos de trasero e incluso gatear, añadiendo capas de estrategia a la exploración de los reinos helados.

SuperTux 0.7.0: Novedades que transforman la aventura

La revisión no es solo estética. La historia de los modos «Story Mode», «Revenge in Redmond» y «Bonus Island I» ha sido reestructurada para ofrecer una narrativa más coherente y atractiva. Además, se incorporan nuevos personajes no jugables como Granito, y una variedad de enemigos frescos (DiveMine, Fish, Corrupted Granito) que pondrán a prueba nuestros reflejos, junto con el rediseño de clásicos como GoldBomb, Igel o los temibles Yeti y Ghost Tree.

En el apartado de mecánicas, SuperTux 0.7.0 introduce elementos muy interesantes como enemigos con brillo, llaves para abrir caminos, un bolsillo de objetos para guardar ítems y las muñecas Tux que desbloquean islas de bonificación. El modo multijugador local permite ahora disfrutar de la aventura en compañía, y el editor de niveles ha sido rediseñado para que crear nuestros propios desafíos sea más intuitivo que nunca.

Todo este lavado de cara viene acompañado de una importante reestructuración interna del código, mejoras en la compilación para diferentes sistemas y optimizaciones que facilitan su portabilidad. Como indican sus creadores, «es probablemente el lanzamiento más grande desde el hito 2», llevando el juego a un estado mucho más pulido y «finalizable».

Si quieres probar ya mismo esta versión, está disponible en múltiples formatos. Para Linux encontrarás un paquete AppImage universal, además de Flatpak y el código fuente. Los usuarios de Windows (32 y 64 bits) y macOS (Intel y ARM) también tienen sus respectivos instaladores. Sin duda, SuperTux 0.7.0 se presenta como la mejor forma de redescubrir a este simpático pingüino.

from Linux Adictos https://ift.tt/s8dQEWZ
via IFTTT

La nueva actualización de mantenimiento de Debian 13.4 ya está disponible y llega cargada de correcciones técnicas pensadas para reforzar la estabilidad del sistema. Aunque no introduce grandes cambios visuales ni funciones rompedoras, su importancia es alta para quienes buscan un entorno sólido y bien parcheado, algo especialmente relevante en entornos donde Debian se utiliza de forma intensa tanto en servidores como en escritorios.

Esta versión se centra en mejorar la seguridad y la fiabilidad del sistema operativo a través de docenas de arreglos distribuidos entre el núcleo y aplicaciones clave. Para administradores de sistemas, donde Debian es una base frecuente en infraestructuras públicas y privadas, resulta una actualización muy recomendable, ya que reduce riesgos y pule comportamientos problemáticos detectados en Debian 13 «Trixie».

Actualización Debian 13.4 para Trixie: mantenimiento imprescindible

Debian 13.4 se publica como una versión puntual de la rama Trixie, es decir, una revisión que no cambia la base del sistema pero sí incorpora todos los parches de seguridad y las correcciones de errores acumulados desde el lanzamiento anterior. Junto con los paquetes actualizados, se han generado también nuevas imágenes de instalación, de modo que cualquier usuario que descargue Debian 13 a partir de ahora obtendrá directamente esta edición ya corregida.

Este tipo de actualizaciones intermedias son habituales en Debian y otras distribuciones estables, y en la práctica permiten instalar un sistema más pulido desde el primer momento, ahorrando tiempo en descargas posteriores de parches. Resultan especialmente útiles en despliegues masivos en universidades, centros de datos o administraciones públicas, donde evitar problemas desde el principio se traduce en menos incidencias y menos trabajo de soporte.

Corrección de la regresión HTTP/2 en Apache HTTPD

Uno de los puntos destacados de Debian 13.4 es la corrección de una regresión detectada en el soporte HTTP/2 del servidor web Apache HTTPD. Este fallo podía afectar al comportamiento de algunos sitios que aprovechaban las ventajas de HTTP/2, como la multiplexación de conexiones o una mejor gestión de la latencia.

Con el parche incluido en esta actualización se restablece el funcionamiento correcto de HTTP/2 en Apache bajo Debian 13 Trixie, lo que es clave para muchos servicios web que siguen apostando por Debian como plataforma de alojamiento. Para los administradores web, aplicar esta actualización ayuda a mantener la compatibilidad con navegadores modernos y a evitar cortes o comportamientos inesperados en páginas que dependen de esta versión del protocolo HTTP.

Debian 13.4 introduce mejoras en GRUB para sistemas con raíz en ZFS

Otro cambio importante tiene que ver con los sistemas que usan ZFS como sistema de archivos raíz. Debian 13.4 soluciona problemas en la detección de esta configuración por parte de los paquetes de GRUB, el gestor de arranque, que en determinadas circunstancias podían generar complicaciones al instalar o actualizar el cargador del sistema.

Con los nuevos ajustes, GRUB identifica de forma más fiable instalaciones con raíz en ZFS, reduciendo el riesgo de arranques fallidos o configuraciones incorrectas. Este aspecto es relevante para entornos donde ZFS se utiliza por sus capacidades avanzadas de integridad de datos y snapshots, algo cada vez más común en servidores de almacenamiento y equipos de trabajo especializados.

Recompilación de paquetes por la actualización de Glibc

Debian 13.4 también incluye numerosas recompilaciones de paquetes a raíz de una actualización de Glibc, la biblioteca estándar de C en GNU/Linux. Cualquier cambio en Glibc tiene un gran impacto, ya que afecta a una enorme cantidad de programas que dependen de ella en su funcionamiento básico.

Al recompilar estos paquetes frente a la nueva versión de Glibc, el proyecto Debian reduce posibles incompatibilidades y mejora la coherencia del ecosistema de software. Para el usuario, esto suele traducirse en un comportamiento más estable de las aplicaciones y en la corrección de fallos sutiles que pueden aparecer al mezclar versiones antiguas con bibliotecas más recientes.

Debian 13.4 introduce docenas de parches de seguridad en paquetes clave

Donde esta actualización pone más el foco es en la seguridad de los paquetes más utilizados. Debian 13.4 integra docenas de correcciones que afectan a aplicaciones críticas tanto en el escritorio como en el servidor, cerrando vulnerabilidades que podían ser aprovechadas por atacantes.

Entre los programas que reciben actualizaciones destacan Firefox, Chromium y Thunderbird, tres piezas fundamentales para la navegación web y la gestión del correo electrónico. Mantener estos programas al día es esencial para proteger la privacidad y evitar ataques a través de páginas maliciosas, extensiones comprometidas o correos con contenido peligroso.

Actualizaciones en GIMP, OpenSSL, OpenJDK y PostgreSQL

Más allá de los navegadores y el cliente de correo, Debian 13.4 incorpora mejoras de seguridad y correcciones en GIMP, OpenSSL, OpenJDK y PostgreSQL, entre otros paquetes. GIMP, como conocido editor de imágenes, recibe parches que refuerzan el tratamiento de archivos potencialmente dañinos o malformados.

En el caso de OpenSSL y OpenJDK, se trata de componentes básicos para la comunicación cifrada y la ejecución de aplicaciones Java, ampliamente utilizados en infraestructuras empresariales y servicios en línea. Las correcciones aplicadas reducen la superficie de ataque y cierran fallos detectados en versiones anteriores, algo clave para servicios que manejan datos sensibles o transacciones económicas.

Por su parte, PostgreSQL, base de datos de referencia en muchos proyectos de software libre y en sistemas de información corporativos, también se ve reforzada con arreglos que mejoran su estabilidad y seguridad. Esto se traduce en un entorno más fiable para aplicaciones críticas que dependen de este motor de base de datos para almacenar y gestionar información.

Actualización del kernel de Linux y otros paquetes

Otro bloque de cambios relevantes en Debian 13.4 tiene que ver con el kernel de Linux y diversos paquetes adicionales. Las nuevas versiones del núcleo incluyen correcciones de seguridad y arreglos de errores generales que ayudan a mejorar tanto la robustez del sistema como su compatibilidad con cierto hardware.

Junto al kernel, se han aplicado actualizaciones menores en numerosos paquetes que, sumadas, contribuyen a una experiencia más pulida. Aunque muchas de estas modificaciones no son visibles de forma directa para el usuario, sí influyen en el funcionamiento global del sistema, especialmente en instalaciones que llevan tiempo en producción y que acumulan cambios y configuraciones específicas.

Descarga de imágenes de instalación actualizadas

Las nuevas imágenes de Debian 13.4 se pueden obtener directamente desde el sitio oficial en Debian.org. Estas imágenes ya incluyen todas las correcciones mencionadas, por lo que quienes instalen el sistema desde cero tendrán menos paquetes pendientes de actualización tras el primer arranque.

Para despliegues en organizaciones, aprovechar estas imágenes renovadas simplifica los procesos de instalación y reduce el tráfico generado por las descargas posteriores de parches. Además, contar con una base ya actualizada facilita la creación de imágenes personalizadas y entornos automatizados, algo muy utilizado en entornos corporativos y educativos.

En conjunto, Debian 13.4 representa una puesta a punto centrada en la seguridad, la corrección de errores y la mejora silenciosa del funcionamiento interno. No es una versión pensada para impresionar con novedades vistosas, sino para reforzar la fiabilidad de Debian 13 Trixie, algo que muchos administradores y usuarios avanzados valoran especialmente a la hora de elegir un sistema operativo estable para el día a día.

from Linux Adictos https://ift.tt/A3wNKef
via IFTTT

GIMP 3.2 ya está disponible como la nueva versión estable del conocido editor de imágenes de código abierto, y llega menos de un año después del esperado salto a la rama 3.0. Esta entrega no pretende revolucionar la herramienta desde cero, sino afinar la base técnica ya migrada a GTK3 y sumar funciones que los usuarios reclamaban desde hace tiempo, especialmente en lo relativo a flujos de trabajo no destructivos y compatibilidad con otros programas.

Para profesionales y equipos de diseño que buscan reducir costes de licencias, esta actualización supone un paso importante. El proyecto se consolida como una opción viable frente a soluciones propietarias como Adobe Photoshop, con una mezcla de nuevas funciones, pequeños retoques de interfaz y mejoras de rendimiento que, juntas, facilitan el trabajo diario sin cambiar radicalmente la experiencia para quienes ya usaban GIMP 3.0.

Capas enlazadas no destructivas: el salto más relevante de GIMP 3.2

La novedad más llamativa de GIMP 3.2 son las llamadas Link Layers, un sistema que se asemeja bastante a los Smart Objects de Photoshop. En la práctica, estas capas permiten enlazar archivos XCF externos dentro de un proyecto sin necesidad de rasterizarlos en cada modificación, de modo que la edición se vuelve mucho más flexible y reversible.

Hasta ahora, muchas operaciones sobre este tipo de contenido implicaban pérdida de información o cambios irreversibles. Con las Link Layers, GIMP 3.2 protege esas capas frente a arrastres accidentales de colores o patrones que pudieran sobrescribir el contenido. Además, acciones básicas como el volteo (flip) dejan de forzar la rasterización, de forma que se mantiene la naturaleza editable del recurso original.

El equipo de desarrollo también ha resuelto un problema complejo que afectaba a proyectos grandes: se han bloqueado los bucles de carga infinita causados por referencias circulares entre archivos XCF enlazados. Esto era especialmente crítico en flujos avanzados donde un documento hacía referencia a otro, y este a su vez volvía a enlazar el primero, generando situaciones difíciles de diagnosticar.

Para estudios creativos, agencias de marketing digital o equipos de producto que manejan identidades visuales consistentes, plantillas reutilizables y bibliotecas de recursos, este paso hacia la edición no destructiva es especialmente útil. Permite trabajar con logotipos, componentes de interfaz o elementos de marca como piezas enlazadas que se actualizan en varios documentos a la vez, reduciendo errores y tiempos de ajuste.

GIMP 3.2 incluye refuerzos en herramientas de pintura y texto

Además de las capas enlazadas, GIMP 3.2 introduce una serie de mejoras en las herramientas de uso diario, empezando por la parte de pintura. Una de las más destacadas es la optimización de la herramienta MyPaint Brush, que ofrece un comportamiento más fluido y una respuesta más coherente, especialmente apreciable en tabletas gráficas y pantallas táctiles usadas en estudios de ilustración o retoque avanzado.

Se añade también un nuevo modo de pintura llamado «Overwrite», que permite aplicar color o textura sobrescribiendo directamente el contenido existente de la capa, sin mezclas intermedias. Este modo puede resultar muy práctico para trabajos de texturizado, pixel art o edición técnica, donde se busca un control absoluto de cada píxel sin efectos de fusión inesperados.

En cuanto a las transformaciones, la herramienta Flip incorpora soporte para teclas de flecha (izquierda/derecha para voltear en horizontal y arriba/abajo para vertical), lo que posibilita un control rápido del eje de volteo sin depender del ratón. De forma similar, la herramienta Shear añade uso combinado de flechas y Shift para aplicar cambios en incrementos mayores, algo útil para ajustes geométricos más precisos.

La herramienta de recorte (Crop) también se vuelve más inteligente: cuando el usuario recorta más allá de los límites del lienzo y el relleno está configurado como transparente, GIMP añade automáticamente transparencia adicional en lugar de forzar un fondo sólido. Es un pequeño cambio, pero evita errores frecuentes en la preparación de imágenes para web, apps móviles o material impreso.

En la parte de vectores y texto, se han alineado algunos comportamientos para que el programa sea más coherente. Por ejemplo, el arrastre de muestras de color sobre capas vectoriales ahora responde de forma similar a lo que ocurría con las capas de texto, lo que reduce esas pequeñas contradicciones que, sumadas, alargan la curva de aprendizaje.

Otra mejora destacada es el aumento del límite de tamaño para Clipboard Brush y Clipboard Pattern hasta 8.192 píxeles en sistemas de 64 bits. Esto beneficia de forma directa a quienes trabajan con proyectos de muy alta resolución, como cartelería, impresión de gran formato o gráficos para pantallas 4K y superiores.

El texto no recibe una reescritura completa en esta versión, pero el equipo ha dejado claro en la conferencia FOSDEM 2026 que un sistema tipográfico más robusto, junto con aceleración por hardware, está entre las prioridades para las ramas posteriores a la 3.2. Esto es especialmente relevante para profesionales que maquetan composiciones complejas, material publicitario o creatividades con mucho texto.

Compatibilidad con nuevos formatos y mejor soporte para PSD

La capacidad de abrir y guardar archivos en distintos formatos sigue siendo una preocupación central para cualquier editor gráfico. Con GIMP 3.2, se amplía ese soporte con varias incorporaciones pensadas para equipos que alternan entre distintas herramientas y dispositivos.

Una de las novedades es la posibilidad de importar paletas de Procreate en formato .swatches. Esto facilita el traslado de bibliotecas de color creadas en iPad con Apple Pencil al escritorio, algo cada vez más común en estudios donde el trabajo se reparte entre tablet y ordenador. Esta compatibilidad hace más sencilla la colaboración entre ilustradores que usan Procreate y diseñadores que prefieren GIMP en Linux, Windows o macOS.

Otra incorporación importante es la exportación de texturas DDS en formato BC7, de especial interés para quienes desarrollan videojuegos, aplicaciones 3D o experiencias de realidad virtual. El formato BC7 permite una compresión eficiente manteniendo buena calidad visual, algo fundamental en pipelines de gráficos en tiempo real donde el tamaño de los recursos y el rendimiento van de la mano.

El importador de archivos PSD también recibe mejoras, sobre todo a la hora de manejar efectos antiguos de resplandor exterior (Outer Glow). Muchos estudios siguen arrastrando plantillas y proyectos heredados de versiones previas de Photoshop, y que GIMP sea capaz de interpretarlos mejor reduce el riesgo de perder detalles al migrar o al colaborar con terceros que usan software propietario.

Por último, se optimiza la carga de proyectos nativos XCF. Ahora, el programa espera a que las fuentes estén inicializadas antes de abrir completamente el archivo, lo cual acorta el tiempo de espera aparente y minimiza errores o cambios inesperados en el aspecto del texto cuando se abren documentos con mucha tipografía.

Retoques de interfaz y experiencia de uso

Más allá de las funciones «estrella», GIMP 3.2 pule pequeños detalles de interfaz (UX/UI) que pueden marcar diferencias en jornadas de trabajo intensivas. Uno de ellos es el comportamiento del Welcome Dialog: ahora deja de aparecer cuando se abre una imagen haciendo clic derecho, evitando una interrupción que resultaba molesta para quienes gestionan muchas imágenes de forma rápida.

La ventana de ajuste de Tono-Saturación se ha reorganizado para seguir el estándar HSL (Hue, Saturation, Lightness). Esto hace que quienes vienen de otras aplicaciones de edición se encuentren con un orden más familiar, disminuyendo ese choque inicial que a menudo se da al pasar de un programa a otro.

Los filtros de Levels, Curves, Equalize y White Balance se han ajustado para trabajar por defecto con precisión lineal. Aunque puede parecer un cambio técnico menor, ayuda a que los resultados sean más coherentes entre lo que se ve en la interfaz y lo que se obtiene al automatizar procesos mediante scripts, algo importante para quienes integran GIMP en flujos más industriales o en sistemas de generación de contenidos a gran escala.

En el ecosistema Linux, muy extendido entre desarrolladores y administraciones públicas, la versión Flatpak incorpora soporte inicial para Global Menu (de forma opcional) y rutas de configuración mejor integradas con el sistema. Esto garantiza que GIMP se comporte de una forma más consistente en escritorios modernos como GNOME o KDE, reduciendo la sensación de aplicación «pegada» desde fuera.

También se ha actualizado la versión AppImage con soporte ARM64, lo que abre la puerta a ejecutarlo en dispositivos como Raspberry Pi o equipos con chips ARM, incluyendo ciertos escenarios con Apple Silicon mediante capas de compatibilidad. Aunque no sea el objetivo principal para estudios grandes, esta flexibilidad puede resultar útil en entornos educativos, laboratorios o pequeños estudios que reutilizan hardware diverso.

Cómo descargar GIMP 3.2 y qué opciones hay

GIMP 3.2 se puede descargar gratuitamente desde la web oficial gimp.org, donde se ofrecen instaladores para Windows, macOS y Linux. En el caso de Linux, además de los paquetes que puedan proporcionar las distribuciones, se ofrecen versiones en Flatpak, Snap y AppImage, lo que da bastante juego para adaptarse a distintos escenarios y políticas de sistema.

En entornos profesionales, suele ser recomendable optar por los paquetes oficiales o por las versiones Flatpak, que tienden a recibir actualizaciones más rápidas y homogéneas entre diferentes distribuciones. Para pruebas, laboratorios o usos puntuales, la AppImage puede resultar especialmente cómoda al funcionar como un binario portátil sin necesidad de instalación clásica.

GIMP sigue siendo un proyecto mantenido por una comunidad de voluntarios y financiado en buena parte por donaciones. Para estudios, agencias o startups que se apoyen de forma intensiva en esta herramienta, tiene sentido valorar algún tipo de contribución económica o de participación técnica, ya sea reportando errores, colaborando en traducciones al español o probando versiones de desarrollo.

Con todo este conjunto de mejoras, GIMP 3.2 no intenta venderse como una revolución, sino como una versión más madura, coherente y útil para el día a día de quienes trabajan con imágenes. Las capas enlazadas no destructivas, el refuerzo en pintura y formatos, y los ajustes de interfaz responden a peticiones históricas de la comunidad, y colocan al proyecto en una posición más cómoda para afrontar los siguientes pasos de su hoja de ruta.

from Linux Adictos https://ift.tt/9VG3vYD
via IFTTT