Fedora y Ubuntu son dos de las distribuciones Linux más populares. Ambas usan por defecto GNOME como entorno gráfico, pero cada una lo hace a su manera. También tienen modelos de desarrollo diferentes, acercándose Ubuntu un poco al de Debian y Fedora con su propia agenda. En este artículo vamos a hablar de las diferencias y similitudes entre Fedora y Ubuntu, especialmente en sus modelos de desarrollo y los calendarios que usan.

Tanto Fedora como Ubuntu lanzan dos versiones de su sistema operativo al año, y en ambos casos llegan sobre abril y octubre. «Sobre», porque Fedora 39 debería haber llegado ya, estamos en noviembre y la única noticia que tenemos de él es que llegará el martes. En teoría. Esta es una de las diferencias en sus modelos de desarrollo/lanzamientos: Fedora no tiene fecha fija y Ubuntu las publica con seis meses de antelación.

Tabla de diferencias y similitudes: Fedora vs. Ubuntu

Versiones al año: 2 cada uno

Tanto el sistema operativo con nombre de sombrero como el que recibe el suyo por una filosofía africana lanzan dos versiones de su sistema operativo al año. Las diferencias en este sentido vienen a ser dos: los de Canonical nos entregan dos versión de ciclo normal o interim al año, y las del sistema patrocinado por Red Hat son todas iguales. Canonical lanza 3 de ciclo normal en 18 meses, y cada dos años lanza una LTS.

Cuando decíamos que Ubuntu tiene un modelo de desarrollo más parecido al de Debian nos referíamos a esto: aunque Debian tiene versiones «unstable», éstas no son lo normal u oficial. Todo lo que lanza son estables, y están soportadas por tiempo prolongado. Ubuntu, por su parte, lanza una versión cada seis meses y no son tratadas con el mismo cuidado con el que tratan las LTS. Algunos dicen que sus versiones reales son las LTS, siendo las de ciclo normal como las inestables de Debian que sirven para preparar las de soporte prolongado.

Lo que tenemos al otro lado del ring es a un boxeador con sombrero con una risa nerviosa que no tiene este problema: todos sus lanzamientos, sin contar con las betas, claro, son iguales.

Tiempo entre lanzamientos y fechas

Ambos lanzan las nuevas versiones cada seis meses aproximadamente. En el caso de Ubuntu, la fecha es publicada pocos días después del lanzamiento de una versión estable, con lo que la conocemos con seis meses de antelación. Llegan en abril (.04) y octubre (.10). Fedora también las lanza más o menos por ahí, pero no tiene fecha programada. En este sentido es la distro del sombrero la que se parece más a Debian: el lanzamiento tiene lugar cuando todo está listo. El mejor ejemplo es el de la próxima v39: debería haber llegado ya, pero hay algo que quieren mejorar y han retrasado su llegada.

Tiempo de soporte: 13 Fedora y 9 meses Ubuntu

Tal y como leemos en la página de ciclo de lanzamientos de Fedora, este proyecto lanza una nueva versión cada 13 meses, y no es una cifra al azar. Lanzan una nueva entrega cada seis meses, y el mes extra se fija para que dé tiempo a actualizar. ¿Y por qué no 7 en vez de 13? Porque piensan que a veces querremos saltarnos una versión y este plazo lo permite.

Ubuntu soporta durante 9 meses (6 entre versiones + 3 de cortesía para actualizar) las versiones de ciclo normal, y mirando lo que hace su rival en este artículo creo que es insuficiente. Pongamos un ejemplo: Ubuntu 23.04 llegó en abril de este año, y 23.10 lo ha hecho hace menos de un mes. Supongamos que nos enteramos de que GNOME 45 o algo de 23.10 puede darnos problemas y queremos esperar hasta el 24.04 que llegará en abril; pues nos quedaremos 3 meses sin soporte porque el de 23.04 termina en enero.

Muy diferente son los lanzamientos LTS que están soportados durante 5 años, e incluso se está hablando de ampliar ese soporte hasta los 10.

Qué elegir entre Fedora y Ubuntu

Elegir entre uno u otro debe ser sólo preferencia personal. Aquí podemos hablar de algunas diferencias y similitudes más, como que Fedora es más fiel a GNOME que Ubuntu o de las críticas que está recibiendo Ubuntu últimamente porque se está centrando más en ser una empresa que un proyecto de software libre. Pero al final estamos ante dos grandes distribuciones Linux en las que no nos faltará de nada. O por lo menos nada de lo que exista en Linux. Casi todo el software se ofrece en AppImage, .deb y .rpm.

Si preferimos versiones que sean todas iguales, quizá nos interese Fedora que no diferencia entre unas y otras. Si queremos algo más estable, quizá nos interese Ubuntu en una versión LTS. Pero conociendo sus ciclos de lanzamiento y filosofías es más fácil elegir.

table {border-collapse: collapse; margin: auto;} thead { background-color: grey; color: white; font-weight: bolder; } td {text-align: center; padding: 5px;border: 1px solid black;}td:first-child{font-weight:bolder}

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

Con la unión de las distribuciones afectadas por RHEL nace OpenELA

Durante el mes de Agosto compartimos aquí en el blog la noticia de que Rocky Linux, SUSE y Oracle se habian unido para crear un repositorio compatible con RHEL, bajo el nombre de OpenELA (Open Enterprise Linux Association).

Ahora, pocos meses después de dicha noticia, se ha conocer él anunció la disponibilidad de un repositorio de paquetes que puede usarse como base para crear distribuciones completamente binarias compatibles con Red Hat Enterprise Linux, idéntico en comportamiento (a nivel de error) a RHEL y adecuado para usar como reemplazo de RHEL.

Se menciona que el nuevo repositorio es mantenido conjuntamente por los equipos de desarrollo de las distribuciones compatibles con RHEL de Rocky Linux, Oracle Linux y SUSE Liberty Linux, e incluye los paquetes necesarios para construir distribuciones compatibles con las ramas RHEL 8 y 9.

OpenELA anunció hoy el lanzamiento público del código fuente de Enterprise Linux junto con importantes hitos técnicos y de gobernanza. OpenELA es una asociación comercial de desarrolladores de distribuciones Enterprise Linux de código abierto fundada originalmente por CIQ, Oracle y SUSE. Existe para fomentar el desarrollo y la colaboración de distribuciones compatibles con Red Hat Enterprise Linux (RHEL) proporcionando código fuente abierto y gratuito para Enterprise Linux (EL).

Como tal, el repositorio OpenELA tiene la finalidad de ser un reemplazo al repositorio git.centos.org, que fue descontinuado por Red Hat. Después del colapso de git.centos.org, solo el repositorio CentOS Stream permaneció como la única fuente pública de código del paquete RHEL en el cual los clientes de Red Hat tienen la oportunidad de descargar paquetes srpm a través de una sección cerrada del sitio, que tiene un acuerdo de usuario (EULA) que prohíbe la redistribución de datos, que no permite el uso de estos paquetes para crear distribuciones derivadas.

Con el lanzamiento del nuevo repositorio OpenELA, se menciona que se mantendrá con altos estándares de calidad, utilizando un proceso de desarrollo completamente abierto y garantizando la rápida publicación de actualizaciones y correcciones de vulnerabilidades. El proyecto es abierto, independiente y neutral. Cualquier organización, empresa y desarrollador individual interesado puede unirse al trabajo conjunto para mantener el repositorio.

«Cuando formamos OpenELA a principios de este año, hicimos una serie de promesas a la comunidad de desarrolladores de código abierto», dijo Wim Coekaerts, jefe de desarrollo de Oracle Linux en Oracle. “Con el anuncio de hoy de la disponibilidad del código fuente de los paquetes, la incorporación completa y la formación del comité directivo técnico, estamos cumpliendo nuestras promesas y nuestro compromiso de ayudar y mantener la capacidad de cualquiera para desarrollar distribuciones EL compatibles. Estamos muy entusiasmados de alcanzar estos importantes hitos y esperamos ver cómo se expande la adopción y la colaboración en torno a OpenELA”.

«Nos complace cumplir nuestra promesa de hacer que el código fuente esté disponible y continuar nuestro trabajo conjunto para brindar opciones a nuestros clientes mientras garantizamos que el código fuente de Enterprise Linux siga siendo de libre acceso para el público», dijo Thomas Di Giacomo, jefe de tecnología . y responsable de producto, SUSE.

Para supervisar la asociación, se ha fundado una corporación sin fines de lucro, que resolverá cuestiones legales y financieras, y se ha creado un comité técnico gestor (Comité Directivo Técnico) para tomar decisiones técnicas, coordinar el desarrollo y el apoyo. El comité técnico estuvo integrado inicialmente por 12 representantes de las empresas fundadoras de la asociación, pero en el futuro se espera aceptar participantes de la comunidad.

Entre los incluidos en el comité directivo se encuentran: Gregory Kurtzer, fundador de los proyectos CentOS y Rocky Linux; Jeff Mahoney, vicepresidente de ingeniería de SUSE y mantenedor del paquete del kernel; Greg Marsden, vicepresidente de Oracle y responsable de los desarrollos de Oracle relacionados con el kernel de Linux; Alan Clark, CTO de SUSE y exlíder de openSUSE.

En el futuro, planean publicar paquetes para distribuciones compatibles con la rama RHEL 7. Además del código fuente de los paquetes, el proyecto también pretende distribuir las herramientas necesarias para crear distribuciones derivadas que sean totalmente compatibles con RHEL.

Finalmente si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace. Para acceder a los repositorios se puede hacer desde el siguiente enlace. 

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

Bcachefs es un sistema de archivos de copia en escritura para sistemas operativos basados ​​en Linux

Hace pocas semanas compartimos aquí en el blog la noticia sobre la aceptación del sistema de archivos Bcachefs en la rama linux-next, ya que en la rama principal fue rechazada por Linus Torvalds y recomendó a Kent Overstreet que evaluara primero la idoneidad de los parches propuestos en la rama experimental de Linux-next, por lo que si la revisión tiene éxito, BcacheFS podría incluirse en el kernel 6.7.

Después de casi un mes de trabajo (desde el ultimo intento de integrar BcacheFS en la rama principal), Linus Torvalds por fin ha dado el visto bueno y aprobó la solicitud para incluir BcacheFS en la rama principal del Kernel de Linux y agregó la implementación de Bcachefs al repositorio en el que se está desarrollando la rama del kernel 6.7, cuyo lanzamiento se espera para principios de enero.

Como ya se mencionó en el articulo que compartimos anteriormente, los intentos de promover BcacheFS en la rama principal de Linux comenzaron en 2020, después de lo cual se necesitaron casi tres años más para eliminar los comentarios y las deficiencias identificadas después de la revisión por pares.

Durante este año se propuso un conjunto actualizado de parches, que fueron rechazadas varias veces, pero finalmente fue aceptado en la rama Linux-next en septiembre, con la intención de probar características para futuras versiones del kernel de Linux.

Para quienes desconocen de BcacheFS, deben saber que esté un sistema de archivos que se está desarrollando utilizando tecnologías ya probadas en el desarrollo del dispositivo de bloque Bcache, diseñado para almacenar en caché el acceso a discos duros lentos en unidades SSD rápidas con énfasis en la confiabilidad y robustez y el conjunto completo de características que uno esperaría de un sistema de archivos moderno.

• Copiar al escribir (COW), como zfs o btrfs
• Suma de verificación completa de datos y metadatos
• Múltiples dispositivos
• Replicación
• Codificación de borrado (no estable)
• Almacenamiento en caché, ubicación de datos
• Compresión
• Cifrado
• Instantáneas
• Modo ahora
• Reflink
• Atributos extendidos, ACL, cuotas
• Escalable: se ha probado a más de 100 TB y se espera que escale mucho más (¡se buscan evaluadores!)
• Alto rendimiento, baja latencia de cola

Ademas de ello, BcacheFS intenta combinar el rendimiento, la confiabilidad y la escalabilidad de XFS con la funcionalidad avanzada que se encuentra en Btrfs y ZFS, como partición multidispositivo, diseños de unidades multicapa, replicación (RAID 1/10), almacenamiento en caché, compresión transparente de datos (LZ4), modos gzip y ZSTD), sectores de estado, verificación de integridad mediante sumas de verificación, la capacidad de almacenar códigos de corrección de errores Reed-Solomon (RAID 5/6), almacenamiento de información en forma cifrada (se utilizan ChaCha20 y Poly1305 ).

En términos de rendimiento, Bcachefs está por delante de Btrfs y otros sistemas de archivos basados ​​en el mecanismo de copia en escritura y demuestra una velocidad de funcionamiento cercana a Ext4 y XFS.

El parche agregado al kernel incluye alrededor de 95 mil líneas de código. El proyecto ha sido desarrollado durante más de 10 años por Kent Overstreet, quien también desarrolló el sistema de almacenamiento en caché de dispositivos de bloques Bcache en unidades SSD incluidas en el kernel.

Una característica especial de Bcachefs es la compatibilidad con conexiones de unidades de múltiples capas, en las que el almacenamiento se compone de varias capas: las unidades más rápidas (SSD) están conectadas a la capa inferior, que se utiliza para almacenar en caché los datos de uso frecuente, y la capa superior está formado por unidades de disco más espaciosas y económicas que proporcionan almacenamiento de datos menos utilizados.

El almacenamiento en caché se puede utilizar entre capas en modo de escritura diferida. Las unidades se pueden agregar y desconectar dinámicamente de una partición sin detener el uso del sistema de archivos (los datos migran automáticamente).

Finalmente si estás interesado en poder probar este sistema de archivos por tu cuenta, debes saber que debes compilar un Kernel para usuario. Puedes seguir las instrucciones en siguiente enlace.

Para aquellos en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace.

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

OSPRay presenta capacidades de renderizado de CPU y GPU escalables

Intel dio a conocer hace poco el lanzamiento de su motor de renderizado 3D, OSPRay  3.0, el cual es un motor de renderizado 3D escalable diseñado para un renderizado realista y de alta calidad con trazado de rayos.

Se menciona que este motor de renderizado está destinado principalmente a su uso en aplicaciones interactivas para representar escenas sobre la marcha. Para simular el comportamiento de la luz se utiliza un método de trazado de trayectoria.

Admite visualización en volumen y en un plano, iluminación global fotorrealista teniendo en cuenta las propiedades físicas de los materiales, efectos de sombreado avanzados. OSPRay puede ejecutarse sin estar vinculado a una GPU, lo que permite utilizar la biblioteca en una amplia gama de dispositivos, desde estaciones de trabajo hasta nodos en clústeres informáticos.

Para garantizar un rendimiento adecuado, se utilizan activamente subprocesos múltiples y vectorización basados ​​en instrucciones SIMD, como Intel SSE4, AVX, AVX2 y AVX-512 (OSPRay requiere soporte SSE4.1 como mínimo).

La renderización se puede distribuir en varios nodos del clúster (compatible con MPI), lo que, por ejemplo, permite utilizar OSPRay para organizar la renderización de imágenes de muy alta resolución en videowalls, una única imagen en la que se forma un conjunto de imágenes separadas.

¿Qué hay de nuevo en OSPRay  3.0?

En esta nueva versión que se presenta de OSPRay, se destaca que se ha implementado una opción experimental para utilizar GPU Intel Xe (GPU Intel Arc, GPU Intel Data Center Flex y Max Series) para la aceleración por hardware del trazado de rayos. Se menciona que la compatibilidad con GPU se implementa utilizando la capa SYCL, que le permite crear aplicaciones en C++.

Cabe mencionar que las siguientes funciones aún no están implementadas o no funcionan correctamente: Múltiples volúmenes en la escena, Clipping, Motion blur, Subdivision surfaces, Informe de progreso mediante ospGetProgresso cancelación del marco medianteospCancel, Recogiendo a través deospPick, Acumulación adaptativa vía OSP_FB_VARIANCEy varianceThreshold y Canales de framebuffer OSP_FB_ID_*(búferes de identificación).

Otros de los cambios que se destacan es que se ha añadido a la indexación implícita de la geometria «meshla» de malla poligonal, asi como soporte para transferir la propiedad de buffers temporales y optimizaciones para el módulo MPI, respaldadas por un nuevo marco de seguimiento de rendimiento integrado

Por otra parte, se menciona que se ha corregido la conservación de energía del material «Pricipled» bajo ciertas combinaciones de parámetros, asi como corrección en denoiser para no borrar el canal alfa y soluciona a las fallas en la luz HDRI.

De los demás cambios que se destacan:

• Relleno de degradado optimizado en el renderizador SciVis.
• Se han realizado cambios en la API que rompen la compatibilidad. Se ha interrumpido la compatibilidad con parámetros y llamadas heredados.
• Arreglar el orden de los enlaces para la compilación de depuración en Windows
• Las nuevas versiones mínimas de dependencias: Embree v4.3.0, Open VKL v2.0.0, Open Image, Denoise v2.1.0, ISPC v1.21.1 y rkcommon v1.12.0
• Se eliminaron los parámetros obsoletos y llamadas API tales como las firmas de devolución de llamada de error sin puntero de usuario, las funciones de transferencia vec2f valueRange; usar box1f value
• Se menciona que Multidevice no admite OSPImageOperationmensajes para eliminación de ruido o mapeo de tonos
• Para alguna combinación de compilador, controlador de GPU y escena, las imágenes renderizadas pueden mostrar artefactos (por ejemplo, líneas verticales o bloques pequeños)

Para los interesados en poder conocer más al respecto, deben saber que el motor se está desarrollando como parte de un proyecto más amplio Intel Rendering Framework, cuyo objetivo es desarrollar herramientas de visualización de software para cálculos científicos SDVis (Software Defined Visualization).

Entre los proyectos que se encuentran incluidos, se menciona a la biblioteca de trazado de rayos Embree, el sistema de renderizado fotorrealista GLuRay, la biblioteca para eliminar el ruido de las imágenes oidn. (Open Image Denoise) y sistema de rasterización de software OpenSWR. El código está escrito en C++ y publicado bajo la licencia Apache 2.0.

Finalmente si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace.

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