Firefox 149: VPN gratuita, ventana inteligente y vista dividida marcan el ritmo de una renovación necesaria

Mozilla se ha decidido a revolucionar su navegador web. No eran pocas las voces que se quejaban por su falta de ritmo al añadir actualizaciones importantes, pero eso cambió con la llegada del nuevo CEO. Pronto se dio la noticia de que centrarían sus esfuerzos en diseñar un buen navegador basado en IA, y en pocos días llegará Firefox 149 con otra novedad que seguramente sea bien recibida por, al menos, parte de la comunidad.

Firefox 149 vendrá con una VPN gratuita, con un límite de 50GB. ¿Son 50GB suficientes? Totalmente, a no ser que se pretenda reproducir contenido en streaming. Una hora de una película en HD puede consumir varios gigas, y 10 episodios de una serie de Netflix, Disney+ o Prime Video podría acabar con esos 50GB. Pero si se usa para consultar páginas web normales, esa cantidad es muy generosa. No está de más comentar que hay servicios que también ofrecen una cantidad sin pagar y que éstos se quedan en 2GB.

Firefox y su VPN gratuita con garantía Mozilla

Antes de continuar, nos vemos obligados a hablar de las VPN gratuitas. Aunque Mozilla dice que está «construido a partir de nuestros principios de datos y nuestro compromiso de ser el navegador más confiable del mundo. Enruta el tráfico de su navegador a través de un proxy para ocultar su dirección IP y ubicación mientras navega«, por lo general, al hacer un uso de un servicio gratuito nosotros somos el producto. Por lo tanto no hay que hacer nada «serio», pero sí puede valer si lo único que queremos es saltarnos un bloqueo.

Este VPN no será como el otro que ya ofrece Mozilla de pago, con el que colaboran con Mullvad. En teoría será más privado, pero el que quiera estar más tranquilo deberá pasar por caja y pagar por un servicio completo. La mala noticia es que sólo estará disponible de inicio en Estados Unidos, Francia, Alemania y Reino Unido. El resto tendremos que esperar.

Ventana inteligente y vista dividida

Firefox 149 también llegará con la ventana inteligente, antes conocida como ventana IA, pero solo en parte. Para probarla hay que entrar en la lista de espera, algo que yo ya he hecho no sé si por curiosidad personal o porque escribo en medios como este y me permitirá generar contenido.

Firefox introducirá por fin la vista dividida. Como usuario de Vivaldi, he de reconocer que me parece que la función está un poco justa, pero no es peor que lo que encontramos en Chrome, Brave o Edge.

Firefox 149 llegará con todas estas novedades el 24 de marzo.

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

Systemd 260: un salto decisivo para la administración de sistemas en entornos europeos


La llegada de systemd 260 marca un salto relevante para uno de los pilares más utilizados en las distribuciones Linux modernas. Esta versión estable, que empezará a integrarse en los lanzamientos de las principales distros en los próximos meses, introduce cambios que afectan tanto a administradores de sistemas como a desarrolladores y responsables de infraestructura. En esta entrega se consolidan decisiones que llevaban tiempo anunciadas, como la retirada definitiva del soporte a scripts tradicionales de arranque, y se suman nuevas capacidades orientadas a contenedores, redes avanzadas y automatización con IA. El resultado es un systemd más alineado con los usos actuales de Linux en servidores, cloud y entornos de virtualización, con especial impacto en entornos europeos donde estas tecnologías están muy implantadas.

Fin del soporte a scripts System V y apuesta total por unidades nativas
Uno de los movimientos más llamativos de systemd 260 es la eliminación completa del soporte a scripts System V. Esta compatibilidad ya estaba marcada como obsoleta desde hace tiempo, pero ahora desaparece definitivamente, lo que implica que los sistemas deben basarse únicamente en unidades nativas de systemd para gestionar servicios. Para administradores en España y el resto de Europa, esto significa que cualquier infraestructura que aún mantenga servicios heredados definidos mediante /etc/init.d u otros mecanismos clásicos tiene que migrarse, si no lo ha hecho ya, a unit files de systemd. De lo contrario, esos servicios dejarán directamente de arrancar en distribuciones que adopten systemd 260 como base.

Nuevo requisito mínimo de kernel y recomendaciones de versión
En paralelo, esta versión eleva la versión mínima de kernel de Linux soportada a la rama 5.10, dejando atrás el anterior mínimo basado en la 5.4. Además, el proyecto recomienda trabajar idealmente sobre Linux 5.14 o, mejor aún, sobre la serie 6.6 para poder aprovechar todas las capacidades presentes en esta edición. Esta decisión puede afectar a despliegues de larga duración en centros de datos europeos que aún dependen de kernels LTS muy antiguos. La mayoría de distribuciones empresariales y comunitarias actuales ya se mueven como mínimo en 5.10 o superiores, pero en escenarios conservadores conviene revisar versiones antes de planificar una actualización a systemd 260.

Nueva función mstack y herramienta systemd-mstack
Entre las incorporaciones más técnicas destaca la llegada de la función mstack y el comando systemd-mstack. Mstack permite definir un OverlayFS a partir de la estructura de un directorio especial denominado .mstack/, siguiendo una especificación concreta para organizar las capas. El nuevo comando en línea de órdenes, systemd-mstack, facilita trabajar de forma interactiva con estas pilas de archivos, lo que abre opciones adicionales para la gestión de contenedores y entornos aislados. Esta capacidad se conecta con el soporte en systemd-importd para descargar y manejar imágenes OCI, reforzando el papel de systemd en escenarios de containerización y sandboxing, muy habituales en proveedores europeos de nube y plataformas de alojamiento.

Campos de identificación del sistema: FANCY_NAME en os-release
Systemd 260 introduce también el campo FANCY_NAME= en el archivo os-release. Este nuevo identificador es similar al ya conocido PRETTY_NAME, pero admite secuencias ANSI, incluidos caracteres Unicode más elaborados. Este FANCY_NAME puede mostrarse a través del gestor de systemd, de systemd-hostnamed y del comando hostnamectl, permitiendo a las distribuciones presentar el sistema con nombres más vistosos o diferenciados. Aunque pueda parecer un detalle menor, puede ser útil para entornos de escritorio y herramientas de administración gráficas implantadas en organizaciones europeas, donde conviene identificar de forma clara la distribución o edición instalada.

Mejoras en red: integración con ModemManager y nuevas opciones
En el apartado de red, systemd-networkd incorpora integración con ModemManager mediante el protocolo simple connect. Esto facilita la gestión de módems y conexiones móviles directamente desde networkd, lo que resulta especialmente interesante para despliegues en zonas rurales o con conectividad basada en redes móviles, frecuentes en algunos territorios europeos. Además, los archivos .link de systemd-networkd añaden nuevas opciones para la configuración de dispositivos Ethernet, incluyendo ScatterGather, ScatterGatherFragmentList, TCPECNSegmentationOffload, TCPMangleIdSegmentationOffload, así como parámetros para gestionar GenericReceiveOffload y GenericReceiveOffloadUDPForwarding. Estas opciones permiten ajustar el rendimiento y comportamiento de la pila de red a nivel de hardware y driver, algo clave para centros de datos y redes corporativas de alto rendimiento. Las interfaces Varlink y JSON de systemd-networkd también se han mejorado para reportar las direcciones IP en formato de cadena legible por humanos, manteniendo a la vez la representación anterior como arreglo de enteros. Esto simplifica la integración con herramientas de monitorización y scripts de administración utilizados en muchas organizaciones españolas y europeas.

Seguridad, integridad y delegación de acceso
Systemd 260 refuerza algunos aspectos de seguridad e integridad. Por un lado, systemd-repart introduce comprobaciones básicas de integridad en volúmenes cifrados, lo que añade una capa adicional de confianza al trabajar con particiones y discos protegidos mediante cifrado. Por otro lado, systemd-logind y systemd-udevd amplían sus capacidades con el nuevo concepto de xaccess para delegar el uso de dispositivos concretos a usuarios cuyos inicios de sesión estén marcados de forma especial. Esta aproximación facilita escenarios donde se desea conceder acceso controlado a hardware sensible sin abrirlo al conjunto del sistema, algo muy alineado con las exigencias de cumplimiento normativo y protección de datos que se aplican en la Unión Europea.

Portabilidad y servicios sin privilegios
En el ámbito de la portabilidad de servicios, systemd-portabled pasa a ejecutarse como servicio de usuario, permitiendo que usuarios sin privilegios puedan lanzar servicios portables siempre que el kernel de Linux lo soporte. Simultáneamente, systemd-vmspawn gana soporte para registrarse en systemd-machined dentro de la sesión de usuario. También suma la opción –ephemeral para crear máquinas efímeras, que se destruyen al finalizar su uso. Estas funciones son especialmente atractivas para laboratorios de pruebas, entornos de CI/CD y plataformas educativas europeas que necesitan crear y destruir máquinas virtuales de forma rápida y controlada.

Ajustes de planificación de CPU y memoria: SCHED_EXT y THP por servicio
Systemd 260 amplía las opciones de control sobre el rendimiento con nuevos ajustes para servicios. La directiva CPUSchedulingPolicy= acepta ahora el valor ext, que permite activar el planificador SCHED_EXT. Esta integración favorece experimentos y despliegues avanzados que requieran políticas de planificación alternativas a las habituales en Linux. Asimismo, se introduce el parámetro MemoryTHP= para gestionar el uso de Transparent Huge Pages (THP) por servicio. Esto otorga un control más fino sobre el comportamiento de la memoria en procesos concretos, lo cual es clave en aplicaciones críticas desplegadas en bancos, aseguradoras o instituciones públicas europeas que buscan un equilibrio entre rendimiento y consumo de recursos.

Nuevas utilidades en udev y expansión del uso de Varlink
En el subsistema de dispositivos, aparece un nuevo comando integrado en udev denominado tpm2_id. Esta utilidad sirve para extraer de manera automática el identificador de proveedor y modelo de dispositivos TPM2 a medida que son detectados por el sistema. Este tipo de mejora facilita la gestión de hardware de seguridad en entornos regulados, especialmente relevante en administraciones públicas y empresas europeas donde los módulos TPM juegan un papel importante en la protección de credenciales y cifrado. Por otra parte, el proyecto continúa ampliando el uso de Varlink a lo largo de distintas piezas de systemd, reforzando un enfoque coherente de comunicación entre componentes y facilitando la integración con herramientas externas que se apoyen en este protocolo.

Novedades en systemctl y otras herramientas de administración
El conocido comando de administración systemctl recibe una nueva orden: enqueue-marked. Esta acción llama internamente al método D-Bus EnqueueMarkedJobs(), lo que abre la puerta a flujos de trabajo más sofisticados para gestionar colas de trabajos y servicios previamente marcados, algo interesante para scripts de automatización y orquestación. Estos refinamientos, aunque menos visibles para el usuario final, suponen mejoras para los equipos de operaciones que trabajan con grandes granjas de servidores en Europa, donde la gestión masiva y automatizada de servicios es la norma.

Atención específica a agentes de IA: AGENTS.md, CLAUDE.md y revisión asistida
Una de las novedades más llamativas de la línea 260, tanto en las versiones candidata como en la versión estable, es la incorporación de documentación específica para agentes de inteligencia artificial. En el repositorio de código de systemd se ha añadido un archivo AGENTS.md pensado para ayudar a los agentes de IA que analizan el código fuente. Este documento ofrece una descripción de la arquitectura de systemd, el flujo de desarrollo, el estilo de código y las pautas de contribución. También proporciona indicaciones sobre cómo ejecutar distintos comandos y pruebas de integración, con la idea de que las herramientas de IA que asisten en programación y revisión de código puedan comprender mejor el proyecto y ofrecer resultados más fiables.
Junto a AGENTS.md se ha incorporado un archivo denominado CLAUDE.md, que hace referencia explícita a AGENTS.md como material de apoyo para la herramienta Claude Code. De esta forma, se orienta directamente a uno de los asistentes de desarrollo basados en IA más utilizados, marcando una tendencia en la que grandes proyectos de software libre preparan documentación específica para estas herramientas. Además, el repositorio incluye un fichero de configuración llamado claude-review.yml, que describe cómo debe revisarse, con ayuda de Claude Code, el proceso de análisis de solicitudes de cambio (pull requests). Todo ello se alinea con la exigencia de que las contribuciones que utilicen IA incluyan etiquetas de divulgación como Co-developed-by en los parches, haciendo explícita la participación de herramientas automáticas en el desarrollo.

Con todo este conjunto de cambios, systemd 260 se presenta como una versión que combina la limpieza de soporte legado, nuevas capacidades para contenedores y redes avanzadas, y una apuesta explícita por integrar herramientas de inteligencia artificial en el ciclo de desarrollo. Para administradores y desarrolladores en España y Europa, el reto ahora pasa por planificar la adopción de esta edición, revisar compatibilidades de kernel, adaptar configuraciones y valorar cómo aprovechar las nuevas funciones en sus infraestructuras.

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

Blender 5.1: rendimiento, estabilidad y nodos avanzados para flujos profesionales

Blender 5.1

La llegada de Blender 5.1 marca otro paso importante para uno de los programas de creación 3D de código abierto más utilizados, tanto en estudios pequeños como en producción independiente. No es una revolución completa, pero sí una actualización muy amplia que toca casi todos los apartados del software.

Esta versión se centra sobre todo en mejorar el rendimiento, reforzar la estabilidad y ampliar las posibilidades técnicas en áreas clave como el render, la animación, la edición de vídeo, la composición y la integración en pipelines profesionales. Todo ello sin abandonar la filosofía de software libre y manteniendo la descarga gratuita para Windows, macOS y Linux.

Novedades destacadas en render: Cycles y Eevee más rápidos

En el terreno del render, Blender 5.1 se centra en que las escenas se calculen más rápido y con mejor aprovechamiento del hardware. Cycles, el motor de producción, obtiene incrementos de velocidad tanto en CPU como en GPU, mientras que Eevee acelera la compilación de materiales y reduce el uso de memoria de texturas.

En Cycles, las pruebas realizadas muestran que el render por CPU en Windows es ahora entre un 5% y un 20% más rápido, según la escena y el hardware empleado. La GPU también gana terreno, con incrementos de alrededor de un 5-10% en distintas configuraciones y sistemas operativos, lo que se nota especialmente en escenas complejas o animaciones de larga duración.

El cambio más llamativo para quienes usan gráficas de AMD es que, con Blender 5.1, el trazado de rayos por hardware mediante HIP-RT pasa a estar activado por defecto. Esto permite aprovechar de manera más directa las capacidades de ray tracing de estas tarjetas en Cycles, sin tener que tocar configuraciones avanzadas.

En Eevee, el motor en tiempo real, se ha revisado el proceso de compilación de shaders. Al preprocesar las fuentes, los materiales se compilan considerablemente más rápido: en la escena de prueba Barbershop se observa una mejora de entre el 25% y el 50%, dependiendo de si se utiliza el backend OpenGL, Vulkan o Metal y de si es una compilación «en frío» (sin caché previa).

Además, Eevee reduce ahora el consumo de memoria de texturas gracias a un sistema que permite solapar framebuffers y texturas de render en distintos momentos del fotograma. Según las notas técnicas, esto se traduce en un ahorro de alrededor del 30-40% de memoria gráfica, algo que puede marcar la diferencia en proyectos pesados.

Otra mejora práctica en Eevee es la incorporación de nuevos controles de intensidad de rutas de luz, que facilitan ajustar el equilibrio entre iluminación directa e indirecta sin necesidad de retocar la configuración de muestreo, lo que agiliza el ajuste fino del look final.

Raycast: nuevo nodo para efectos no fotorrealistas y proyección

Entre las funciones nuevas, uno de los protagonistas de Blender 5.1 es el nodo Raycast, disponible en Eevee. Este nodo lanza rayos adicionales dentro de la escena y devuelve información de la primera superficie que encuentra, lo que abre la puerta a una amplia variedad de efectos de sombreado creativos.

Al conocer con precisión el punto más cercano donde impacta el rayo o la distancia recorrida, se pueden montar configuraciones para sombras toon, efectos tipo rayos X o sistemas de proyección de calcas (decals) sobre geometrías complejas. De hecho, durante el desarrollo se popularizó un montaje de proyección de decals realizado por artistas de animación 3D, que demostraba cómo este nodo permite técnicas que antes requerían soluciones mucho más rebuscadas.

El propio equipo de Blender ha puesto a disposición de la comunidad varios archivos de ejemplo descargables, donde se pueden estudiar en detalle configuraciones de Raycast para sombreado tipo cómic, efectos de rayos X o proyección de gráficos sobre superficies. Eso sí, se advierte de que este nodo puede resultar computacionalmente costoso, por lo que recomiendan hornear ciertos resultados cuando se utilice de forma intensiva.

Compositor: nuevo nodo Mask to SDF y vínculos con el editor de vídeo

El sistema de composición integrado de Blender lleva varias versiones recibiendo mejoras y Blender 5.1 continúa esa tendencia con nuevas herramientas y optimizaciones de rendimiento. Una de las incorporaciones más interesantes es el nodo Mask to SDF, que transforma cualquier máscara en un campo de distancia firmado (Signed Distance Field).

Este tipo de representación permite calcular para cada píxel la distancia al borde de la máscara, lo que hace muy sencillo construir efectos de bordes suaves, brillos, erosión o dilatación de formas y montajes basados en la distancia, como desenfoques procedurales que se expanden desde un contorno concreto.

El Compositor también incorpora compatibilidad con nodos utilitarios ya presentes en otros contextos, como Radial Tiling, Boolean, Integer, Vector e Index Switch, ampliando así las posibilidades a la hora de construir árboles de nodos complejos para postproducción.

En cuanto al rendimiento, varios de los nodos más usados han sido optimizados de manera significativa. Operaciones como Blur, Directional Blur, Vector Blur, Glare, Lens Distortion y Anti-Aliasing se ejecutan ahora entre 1,2 y 2 veces más rápido, lo que puede marcar una gran diferencia al componer secuencias largas o trabajos con muchas capas.

Una novedad especialmente relevante para quienes montan vídeo dentro de Blender es la llegada del nodo Sequencer Strip Info. Este nodo lee atributos de las tiras en el Video Sequence Editor (VSE), como tiempos de inicio y fin, lo que permite sincronizar con precisión efectos de composición con los cortes y transiciones de la línea de tiempo de vídeo.

Video Sequence Editor: audio mejorado y flujo con el Compositor

El Video Sequence Editor, el sistema interno para corte y edición de vídeo, también recibe varios ajustes que apuntan a un flujo de trabajo más flexible, sobre todo en el tratamiento del audio. A partir de esta versión, es posible modificar el tono de las pistas de sonido directamente desde el VSE.

El cambio de tono se puede controlar mediante semitonos o factores de escala, por ejemplo, indicando que una pista suene un 30% más grave. Además, se suma la posibilidad de aplicar efectos de eco a las tiras de audio, lo que amplía las opciones creativas básicas sin necesidad de pasar por un editor externo.

Otra mejora útil son las metastrips con corrección de volumen global. Cuando se agrupan varias tiras, como dos pistas de audio, ahora se puede ajustar el volumen conjunto de toda la metastrip, facilitando el control del nivel general sin tener que editar cada pista por separado.

La integración entre VSE y Compositor se refuerza también desde el propio flujo de trabajo: no solo se pueden sincronizar efectos mediante el nodo Sequencer Strip Info, sino que resulta posible crear directamente la configuración del VSE desde el Compositor, acercando ambos entornos y simplificando la organización de proyectos donde montaje y postproducción se realizan dentro de Blender.

Animación: rigs complejos mucho más ágiles

En animación, Blender 5.1 combina nuevas herramientas con una mejora muy notable en el rendimiento de evaluación de personajes. Una incorporación destacada es el modificador de suavizado gaussiano en el Editor de Curvas (Graph Editor), que permite suavizar F-curves de manera no destructiva.

Esta herramienta está pensada, entre otras cosas, para reducir el ruido en datos de captura de movimiento sin perder la información original, ya que el suavizado se aplica como un modificador y las claves de animación permanecen intactas. Se advierte, eso sí, que puede ser exigente en recursos, por lo que conviene no aplicarlo de forma indiscriminada a demasiadas curvas a la vez.

En cuanto a rendimiento, la evaluación de Actions y Shape Keys se ha optimizado de forma considerable. En pruebas con un procesador AMD Ryzen de 12 núcleos y 24 hilos, evaluando un armature con alrededor de 2.600 huesos durante 1.000 fotogramas, las tasas de fotogramas se multiplican por un factor de entre 2,25 y 2,3, dependiendo de la cantidad de hilos aprovechados.

Para las Shape Keys, que se usan para morph targets y expresiones faciales, las mejoras son aún más llamativas: en una malla de aproximadamente un millón de vértices, las tasas de fotogramas pueden ser de 2,3 a 4 veces superiores. Esto se traduce en una manipulación mucho más fluida de personajes complejos, algo especialmente apreciable en producciones de animación y videojuegos.

Geometría y volúmenes: nuevos nodos para texto y rejillas voxel

El sistema de Geometry Nodes, que permite crear herramientas y efectos procedurales, recibe varias incorporaciones orientadas tanto al texto como al trabajo con volúmenes. El nodo Strings to Curves se amplía con numerosos sockets de entrada adicionales, lo que permite animar prácticamente cualquier parámetro relacionado con el texto.

A partir de ahora es más sencillo construir montajes en los que se controlen la separación de caracteres, alineaciones, cajas de texto y otros atributos de forma procedimental. Esto facilita la creación de efectos tipográficos animados sin necesidad de recurrir a herramientas externas, algo que puede interesar especialmente a quienes producen piezas de motion graphics.

En el ámbito de los volúmenes, la comunidad ha contribuido una serie de nodos nuevos diseñados para manipular rejillas de vóxeles, muy útiles en efectos volumétricos. El nodo Clip Grid permite desactivar todos los vóxeles fuera de un cubo definido; por su parte, Cube Grid Topology genera una rejilla cúbica con todos los vóxeles activos.

Otros nodos, como Grid Mean y Grid Median, calculan la media y la mediana de los valores de todos los vóxeles de una rejilla, respectivamente, lo que ayuda a analizar o normalizar datos volumétricos. Los nodos Grid Dilate y Grid Erode permiten expandir o contraer las zonas activas en la rejilla; combinando una dilatación seguida de una erosión se pueden cerrar agujeros en el volumen con relativa facilidad.

Finalmente, el nodo Grid to Points crea un punto en cada vóxel activo de la rejilla, puntos que se pueden usar para instanciar objetos. Por ejemplo, se puede representar cada vóxel mediante un cubo, algo muy práctico para depurar y visualizar el estado interno de las rejillas volumétricas durante el desarrollo de configuraciones complejas.

Interfaz, nodos y mejoras de flujo de trabajo

La interfaz de Blender y los sistemas basados en nodos también reciben su ración de mejoras. Según los desarrolladores, en la UI se han aplicado cerca de un centenar de correcciones y pequeños ajustes, entre los que destaca la posibilidad de buscar controles por nombre dentro del panel de Preferencias, agilizando el acceso a opciones concretas.

Otra mejora de usabilidad es la opción de redimensionar las vistas en cuadrícula (quad view) arrastrando el punto central, algo que hace más cómodo adaptar el espacio de trabajo a las necesidades de cada tarea sin recurrir a menús adicionales.

En la parte de nodos, una novedad muy práctica es que ahora se pueden copiar y pegar árboles de nodos entre distintas instancias de Blender utilizando el portapapeles del sistema. Esto incluye la posibilidad de transferir configuraciones entre diferentes tipos de editores de nodos, como el Shader Editor y el Compositor, lo que facilita reutilizar configuraciones y librerías de efectos.

Además, se introduce un nuevo nodo Bone Info en Geometry Nodes, que permite acceder a la posición de los huesos desde flujos de trabajo procedurales. Aunque se trata todavía de un paso inicial, esta posibilidad abre la puerta a exploraciones en rigging procedural y sistemas de animación más avanzados basados en nodos.

Grease Pencil, escultura y pintura

El conjunto de herramientas de Grease Pencil, pensado para animación 2D dentro de un entorno 3D, también evoluciona en Blender 5.1 con cambios de flujo de trabajo relevantes. Entre ellos, destaca la opción de controlar los rellenos directamente, sin depender únicamente de los materiales asociados a los trazos.

Además, se añade la posibilidad de crear agujeros en las áreas de relleno, ya sea mediante nuevos operadores que realizan operaciones de tipo booleano sobre las formas, o aprovechando el importador de SVG. Esto amplía de forma notable la flexibilidad a la hora de diseñar personajes y fondos con áreas vacías o recortes complejos.

En las herramientas de Escultura y Pintura, la mayor parte de los cambios se centra en correcciones y estabilidad, pero se incluye un nuevo pincel Blur. Este pincel está pensado específicamente para suavizar colores sobre la superficie al trabajar en modo Sculpt, evitando tener que recurrir a los pinceles de arrastre de color (Smear) o de pintura tradicionales para lograr un efecto de difuminado.

Video, VR y Vulkan: rendimiento y experiencia inmersiva

Más allá de la edición de vídeo clásica, Blender sigue reforzando sus capacidades en realidad virtual. En la versión 5.1, el sistema de teletransporte dentro de escenas VR se ha reescrito por completo para aproximarse más a las convenciones de los juegos actuales y reducir las molestias asociadas al movimiento continuo, como los mareos.

La nueva implementación indica de manera clara el destino del teletransporte, e introduce un widget que evita saltar sin querer al interior de paredes o zonas no deseadas, mostrando un aviso en rojo cuando la posición elegida no es adecuada. Además, se mantiene y se amplía la compatibilidad con OpenXR, incluyendo soporte en macOS, lo que resulta relevante para estudios que trabajan con distintos sistemas operativos.

En el plano gráfico, Blender avanza en su transición desde OpenGL hacia Vulkan como backend principal. Hasta ahora, una de las áreas donde Vulkan iba por detrás era la previsualización de escenas en VR, donde el rendimiento resultaba inferior. Con Blender 5.1, ese último cuello de botella se ha eliminado y Vulkan se sitúa al menos al nivel de OpenGL en todos los escenarios evaluados.

Este avance, sumado a tiempos de carga más rápidos y un mejor aprovechamiento del hardware moderno, acerca el momento en que Vulkan se convierta en la opción por defecto en futuras versiones. Además, el soporte de Vulkan se refuerza con características como un nuevo «pool» de texturas específico y una mayor estabilidad general.

Integración en pipeline, formatos y requisitos del sistema

Para su integración en entornos profesionales, Blender 5.1 se alinea con los estándares del sector actualizando componentes clave. El programa adopta Python 3.13 y OCIO 2.5, lo que lo acerca a las especificaciones de la VFX Reference Platform de 2026, habitual en muchos estudios de efectos visuales y animación.

En el apartado de entrada y salida de datos, se introduce soporte de exportación AVIF y se mejoran los exportadores de USD, glTF y FBX. En el caso de FBX, las versiones generadas incluyen ahora las normales asociadas a las Shape Keys, lo que se traduce en una mejor compatibilidad con motores de juego y otros programas 3D cuando se exportan personajes y animaciones.

Blender 5.1 mantiene su distribución bajo licencia GPLv3, con acceso abierto al código fuente. El software es gratuito y se puede descargar para sistemas Windows (a partir de la versión 8.1), macOS (13.0 en adelante) y Linux con glibc 2.28 o superior, cubriendo así la mayoría de entornos habituales tanto domésticos como de estudio.

Estabilidad y calidad: más de 350 errores corregidos

Junto con las novedades visibles, una parte muy importante del trabajo en Blender 5.1 se ha dedicado a reforzar la estabilidad y la calidad general. Dentro de la iniciativa conocida como «Winter of Quality», que se ha desarrollado entre diciembre y enero, se han corregido más de 350 errores reportados por la comunidad.

El área más beneficiada ha sido el conjunto de herramientas de modelado 3D, con cerca de 60 correcciones, pero las herramientas de vídeo y la interfaz gráfica no se quedan atrás, con en torno a medio centenar de arreglos cada una. El Compositor, el editor de secuencias de vídeo y los propios núcleos de Cycles y del sistema también han recibido refactorizaciones y limpiezas de código, lo que debería traducirse en un comportamiento más predecible y robusto.

Blender 5.1 incluye asimismo actualizaciones en áreas como la creación de metadatos de escenas, la reorganización interna de algunos módulos y otros cambios que, aunque menos visibles para el usuario final, contribuyen a que el programa responda mejor en proyectos de larga duración o con archivos muy pesados.

Con este conjunto de mejoras, Blender 5.1 se consolida como una actualización amplia y muy orientada al uso diario: más estabilidad, mejor rendimiento en render y animación, nuevas opciones en nodos, vídeo y VR, y una integración más sólida en pipelines profesionales. Para usuarios que ya trabajan con Blender en animación, VFX, videojuegos o visualización, la versión supone un salto tangible en comodidad y fiabilidad, manteniendo al mismo tiempo el modelo de software libre que caracteriza al proyecto.

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

CachyOS y el nuevo impulso del gaming en Linux: ¿cambio de liderazgo en ProtonDB?

CachyOS enero 2026

\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

FFmpeg 8.1 «Hoare»: una visión integral de la aceleración por GPU y formatos emergentes


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

Manjaro en la encrucijada: ¿hacia una nueva era o una bifurcación inevitable?


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

IPFire 2.29 Core Update 201: el DNS Firewall llega para transformar la seguridad de la red

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

SparkyLinux 2026.03 Tiamat: Novedades, Detalles Técnicos y Guía de Instalación


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

AUR, yay y paru: guía clara para elegir tu asistente en Arch y sus derivadas

yay en EndeavourOS

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: una alternativa moderna para el gestor de arranque en sistemas Linux


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