El reloj de arena de esta serie se agota. Pero, mientras esperamos, el equipo de desarrolladores que hay detrás del proyecto GNU Image Manipulation Program ha lanzado GIMP 2.10.36, la que podría ser la última versión en empezar con un 2. Con un poco de suerte, dentro de unos meses publicamos la nota que habla del lanzamiento de GIMP 3, entre cuyas novedades estará que pasarán a usar GTK3, dejando atrás el GTK2 que usa ahora mismo.

Pero no adelantemos acontecimientos. El artículo sobre novedades de GIMP 2.10.36 sí menciona a GIMP 3.0, pero de pasada y en dos puntos: en el primero pidiendo a gente para probar el software «especialmente para GIMP 3.0 en adelante«, y en el segundo para decir que tendremos noticias sobre su desarrollo a corto plazo. Lo que sigue es la lista de novedades más destacadas que han llegado junto a GIMP 3.10.36.

Novedades más destacadas de GIMP 2.10.36

Tras nueve meses de desarrollo en el que nos entregaron GIMP 2.10.34, lo más destacado de 2.10.36 incluye:

• Soporte para paletas Adobe Swatch Exchange (ASE) y Adobe Color Book (ACB).
• Nueva opción de degradado que irá del fondo hacia transparente.
• Mejoras en el formato GIF añadiendo soporte para radio no cuadriculado para permitir la carga de imágenes GIF que contienen metadatos PixelAspectRatio.
• Mejoras en la herramienta de texto que ahora ofrece mejor comportamiento de formateo al elegir y cambiar textos en una capa.
• Sección de temas en los ajustes para mejorar la respuesta al pasar el cursor por botones bloqueados.
• Se ha aprovechado el momento para añadir parches de seguridad y para corregir errores.

GIMP 2.10.36 ya se puede descargar desde su página web oficial, disponible en este enlace. Las versiones para macOS, tanto para equipos con procesador Intel como con Apple Silicon, serán publicadas más tarde. Aunque se menciona el paquete flatpak, aún está por actualizar, como también lo está el paquete snap. Se espera que los actualicen en las próximas horas.

Sobre GIMP 3.0, es seguro que llegará en 2024, pero se desconoce la fecha exacta.

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

Hace algunos meses, Pablinux compartió aquí con nosotros una publicación en la cual nos explicaba de una forma bastante sencilla sobre la API Web Environment Integrity, la cual a agrades rasgos la describe en su artículo con DRM for the Web y durante todo ese tiempo gran parte de la comunidad web critico a esta API.

Y tal parece que ahora Google ha escuchado las críticas de la comunidad y ha dado a conocer la noticia que ha tomado la decisión de dejar promocionar la API Web Environment Integrity, junto con la cual también eliminó su implementación experimental del código base de Chromium y movió el repositorio de especificaciones al modo de archivo.

Como tal el intento de implementar la API en cuestión, género preocupaciones a gran parte de la comunidad, ya que muchos mencionaban que de ser implementada la API podría socavar la naturaleza abierta de la Web y conducir a una mayor dependencia de los usuarios de proveedores individuales, además de limitar significativamente la capacidad de utilizar navegadores alternativos y complicar la promoción de nuevos navegadores al mercado. Como resultado, los usuarios podrían volverse dependientes de navegadores verificados lanzados oficialmente, sin los cuales perderían la capacidad de trabajar con algunos sitios web y servicios grandes.

Y aunque de manera inicial la idea de la API, no era mala, ya que diseñada para brindar a los propietarios de sitios la capacidad de garantizar que el entorno del cliente sea confiable en términos de protección de los datos del usuario, respeto de la propiedad intelectual e interacción con una persona real.

Se pensó que la API podría usarse para filtrar el tráfico de los bots al mostrar publicidad; combatir el spam enviado automáticamente y aumentar las calificaciones en las redes sociales, identificar manipulaciones al ver contenido protegido por derechos de autor, combatir a los tramposos y clientes falsos en los juegos en línea, identificar la creación de cuentas ficticias por parte de bots, contrarrestar los ataques de adivinación de contraseñas, protección contra phishing, implementada mediante malware que transmite resultados a sitios reales.

La nueva API podría ser útil en áreas donde un sitio necesita garantizar que hay una persona real y un dispositivo real en el otro lado, y que el navegador no se modifica ni se infecta con malware. La API se basa en la tecnología Play Integrity, ya utilizada en la plataforma Android para verificar que la solicitud se realiza desde una aplicación no modificada instalada desde el catálogo de Google Play y ejecutándose en un dispositivo Android genuino.

Para confirmar el entorno del navegador en el que se ejecuta el código JavaScript cargado, la API Web Environment Integrit propuso utilizar un token especial emitido por un autenticador externo, que a su vez podría estar vinculado por una cadena de confianza con mecanismos de control de integridad en la plataforma . El token se generó enviando una solicitud a un servidor de certificación de terceros, que, tras realizar determinadas comprobaciones, confirmó que el entorno del navegador no había sido modificado. Para la autenticación, se utilizaron extensiones EME similares a las utilizadas en DRM para decodificar contenido multimedia protegido por derechos de autor.

El problema de la API es que esta podría convertirse en un problema a corto plazo, ya que como se mencionó, su implementación significativa limitar la capacidad de utilizar navegadores alternativos y en pocas palabras volver a Chrome/Chromium en el único navegador web con el cual los usuarios podrían trabajar (básicamente un monopolio).

Finalmente, se menciona que se continúan los experimentos en la plataforma Android con la implementación de una API similar para verificar el entorno del usuario: WebView Media Integrity, que se posiciona como una extensión basada en Google Mobile Services . Se afirma que la API WebView Media Integrity se limitará al componente WebView y a las aplicaciones relacionadas con el procesamiento de contenido multimedia; por ejemplo, se puede utilizar en aplicaciones móviles basadas en WebView para transmisión de audio y vídeo. No hay planes para proporcionar acceso a esta API a través de un navegador.

Si estás interesado en poder conocer mas al respecto, puedes consultar los detalles en el siguiente enlace.

from Linux Adictos https://ift.tt/2GBc89o
via IFTTT

Como comentamos durante el fin de semana, a Fedora Project no le gusta eso de marcarse una fecha y tener que cumplir con ella. Sus nuevas versiones llegan sobre abril y octubre, pero sólo nos la entregan cuando están seguros de que todo está bien. Hace unos instantes, y tras solucionar algunos problemas que retrasaron el lanzamiento, han tenido el placer de anunciar el lanzamiento de Fedora 39, la nueva versión estable del sistema operativo más fiel a GNOME de entre los más populares.

Las novedades más destacadas son dos: por una parte, el escritorio, un GNOME 45 del que aseguran que mejora el rendimiento con respecto a la edición anterior. Por otra, el kernel, que ahora ha pasado a usar el Linux 6.5 que llegó originalmente hace poco más de dos meses. Como no podía ser de otra manera y hacen en cada lanzamiento, han actualizado también los paquetes de software a versiones más actualizadas.

Novedades más destacadas de Fedora 39

• GNOME 45 en la edición principal o Workstation. Entre las novedades de esta nueva versión del escritorio más popular tenemos, por ejemplo, que han eliminado la etiqueta de Actividades, o mejor dicho, la han sustituido por un icono dinámico. Cada escritorio virtual es ahora un punto, menos aquel en el que nos encontramos, que será un punto alargado o una línea. También cuenta con ajustes para controlar la retroiluminación del teclado si tenemos un portátil compatible o un movimiento más suave del puntero. Para más información, podéis visitar nuestro artículo relacionado.
• Los spins llegan con Plasma 5.27, Cinnamon 5.8 y Budgie 10.8.
• Linux 6.5. Entre otras cosas, añade soporte para nuevo hardware.
• rpm 4.19.
• Python 3.12.
• Rust 1.73.
• Firefox 119.
• LibreOffice 7.6.
• GCC 13.2.
• GNU Binutils 1.20.
• Glibc 2.38.
• GDB 13.2.

Fedora 39 está soportado durante 13 meses, el mismo que el resto de versiones. Esto nos permite quedarnos en una y saltarnos la siguiente si así lo decidiéramos. Ya se puede descargar desde su página web oficial.

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

La última versión del sistema de las ventanas llegó en 2021, pero con ya uno de cada 4 equipos usándola se podría decir que ha empezado a despegar ahora. Los usuarios del sistema de Microsoft no se animan a actualizar muy pronto, y si no que se lo digan a los que abandonaron Win 7 por obligación más que por decisión. Además, los nuevos equipos vienen ya con Microsoft Windows 11, y eso ayuda a aumentar su cuota de mercado. Pero, ¿por qué hablamos de esto en Linux Adictos? Por dos motivos: tenemos una sección «Linux vs Windows» y Windows es compatible con aplicaciones de Linux.

El culpable de esto es un software que se llama WSL (Windows Subsystem for Linux). Al principio, cuando salió para Windows 10 había que escribir varios comandos para activarlo y lo que obteníamos era una distribución, pero para ejecutarle en el terminal. Pronto salieron trucos para ejecutar aplicaciones de Linux con interfaz de usuario, e incluso más recientemente se consiguió abrir un escritorio haciendo uso del escritorio remoto, pero en Microsoft Windows 11 esto es más sencillo. El soporte para aplicaciones de Linux con GUI es oficial.

Microsoft Windows 11 permite ejecutar aplicaciones de Linux con GUI

En una actualización de WSL 2, el susbistema de Windows para Linux permite ejecutar aplicaciones con interfaz de usuario, independientemente de si están diseñadas para X11 o Wayland. Los de Satya Nadella explican que la experiencia de escritorio está totalmente integrada, y no mienten, ya que obtenemos:

• Posibilidad de lanzar las aplicaciones de Linux desde el menú de inicio de Windows.
• Posibilidad de anclar las aplicaciones de Linux a la barra de tareas de Windows.
• Uso de Alt+Tab para cambiar entre aplicaciones de Linux y Windows.
• Cortar y pegar entre aplicaciones de Windows y Linux.

Los cuatro puntos anteriores se pueden resumir diciendo que se instalarán las aplicaciones y se comportarán como las nativas, ni más ni menos.

Cómo instalar aplicaciones de Linux con GUI en Windows

1. Para poder instalar aplicaciones de Linux con GUI en Microsoft Windows 11 hay que tener un controlador instalado para vGPU. Enlaces para los de Intel, AMD y NVIDIA.
2. Lo siguiente es instalar WSL, ahora en su segunda versión. Si no hay instalación previa, hay que abrir PowerShell o el símbolo del sistema de Windows como administrador, escribir wsl --install y reiniciar el equipo. Cuando se reinicie, la instalación continuará y hay que introducir un nombre de usuario y una contraseña. Esta será la credencial para Ubuntu, pero se pueden instalar más sistemas desde la Microsoft Store. Si ya estaba instalado WSL, lo que hay que escribir es wsl --update.
3. Para instalar las aplicaciones, lo que hay que hacer es tirar de terminal. Abrimos el sistema operativo en cuestión, en este ejemplo Ubuntu, y escribimos el comando de instalación, como por ejemplo sudo apt update && sudo apt install gnome-text-editor. La aplicación aparecerá en el menú de inicio.

Por qué me interesa como usuario de Linux

Nadie os va a decir que os paséis a Windows si sois usuarios de Linux. Tampoco que el sistema de Microsoft sea lo mejor. Pero esto sí os interesa si sois usuarios de Linux por un motivo: podréis seguir usando todas vuestras aplicaciones favoritas aunque os pongan Windows 11 en el trabajo o en el ordenador de un familiar.

Microsoft pone como ejemplos la instalación de software como GIMP o VLC, lo que no tiene mucho sentido, pero también GNOME Text Editor o Nautilus. También se puede instalar Dolphin, y éste gestiona mejor las conexiones FTP que el gestor de archivos de Windows.

Pero, en definitiva, si estás muy acostumbrado a un programa y éste sólo está para Linux, podrás usarlo en Windows 11 y con interfaz de usuario.

WSA, aplicaciones de Android nativas en Microsoft Windows 11

Otra novedad de Microsoft Windows 11 para los usuarios de Linux llegó a los que quieren ejecutar apps de Android, el Linux móvil más popular aunque no sea tan puro como postmarketOS o Mobian, en el escritorio. Su nombre es WSA por Windows Subsystem for Android, y funciona aún mejor que las aplicaciones de Linux con GUI en Windows.

WSA incluye por defecto la tienda de apps de Amazon, pero es posible instalarle la Google Play. Con esto podremos, por ejemplo, jugar a los juegos móviles en un equipo con Windows. Cierto es que hay muchos desarrolladores que lanzan versiones web de sus aplicaciones o las suben directamente en la Microsoft Store, pero poder usar apps de Android, sumado a las de Windows y también a las de Linux, hacen que el combo sea completo.

¿Queremos algo así en Linux?

Sí, pero no a cualquier precio. La instalación debe ser sencilla, y el sistema no debe cargarse con «morralla». ¿Os imagináis que le podría pasar a vuestro Linux, ese que corre tan bien, si se le añadiera parte de Windows en su código? Eso es lo que ha hecho Microsoft en Windows 10 y posteriormente en Windows 11.

Windows no es el sistema más fluido del mundo, y añadirle un poco de peso en una actualidad con equipos potentes no cambia mucho las cosas para mal. Gran parte del trabajo lo hace tirando de virtualización, lo que hace que el consumo de recursos se dispare. Bien mirado, si el consumo de recursos debe subir yo ejecuto aplicaciones de Windows 11 en GNOME Boxes y «ya está». Entre comillas porque tengo que lanzar una aplicación diferente y luego ver todo el escritorio, pero puedo abrir sus apps.

Lo de Android es un poco diferente. En Linux no tenemos tantas aplicaciones como en Windows, y ni siquiera Spotify lanza una app nativa (es más bien una web) para Linux. Con algo parecido a WSA se nos abrirían muchas puertas. Existen Anbox y Waydroid, pero su instalación dista mucho de ser sencilla y limpia para el sistema operativo.

Microsoft ama Linux

Microsoft ama Linux. No lo digo yo, lo dicen ellos. Tienen su propio sistema operativo de escritorio, pero el que usan para servidores es Linux. Y saben que muchos desarrollares nos decantamos por algún sistema con el kernel de Torvalds, por lo que han decidido mimarnos un poco. ¿Lo suficiente para que cambiemos? Nah.

Imagen de cabecera: Microsoft.

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

El pasado mayo escribí un artículo explicando cómo son las PassKeys. Lo resumiré rápidamente: la teoría dice que serán más cómodas y rápidas, pero la práctica dice que si tenemos equipos incompatibles es peor el remedio que la enfermedad. Han pasado seis meses desde aquel artículo, he empezado a ver las PassKeys en algún que otro servicio, he tratado de adaptarme a las nuevas tecnologías y repito lo mismo que entonces: de momento, gracias, pero no, gracias.

Y es que no hay nada peor que lanzar algo a medias. Recientemente, en un proyecto personal en el que trabajo con otra persona, le dije a mi compañero que había algo que daba problemas, a lo que él me respondió «Pues si no se comporta bien no puede salir a la calle«. Aquello en cuestión funcionaba, pero quedaba un fleco. Estaba completo, pero no bien. Encontramos una solución y ya lo estamos usando, pero no a medias. Ahora mismo ya se pueden usar las PassKeys en varios servicios web, pero aún no es su momento.

El problema de las PassKeys: equipos y navegadores incompatibles

En un servicio que uso habitualmente, ahí está el botón: usar PassKeys. Uno piensa en aquello de empezar a adaptarse y lo presiona con ilusión. Le llega una notificación al móvil, coge el número, lo copia en el navegador y luego le da a entrar. Básicamente es como una verificación en dos pasos. Bonito paseo para algo que ahora mismo es darle al botón, pues mi navegador web ya tiene la contraseña guardada.

En las PassKeys la contraseña somos nosotros, pero para que esto pueda ser así debemos estar registrados. La manera de convertirnos en contraseña es la de registrarnos en algún aparato compatible, entre lo que habrá que añadir una contraseña (Doh!), y ya podremos entrar a todo usando un dispositivo compatible y nuestra huella dactilar, cara o cualquier otra parte de nuestro cuerpo aceptada. Pero, ¿cómo me identifico en mi PC de 2019 con Linux?

La única manera de poder identificarnos desde un aparato «antiguo», véanse las comillas, será comprando una llave y teniéndola siempre conectada (más información) a uno de nuestros puertos USB. A partir de ese momento, cuando le demos al botón de iniciar con PassKeys, el navegador buscará en esa llave, podrá confirmar que somos nosotros y nos dejará pasar.

Todo cambiará en el futuro

En el futuro todo cambiará, difícil es que no lo haga cuando nos desplazamos adelante en el tiempo. Pero en el presente están las cosas a medio cocer. Lógicamente, mientras esto no se extienda bien y mucho seguirá estando disponible el campo para introducir la contraseña, faltaría más. Pero de momento es sólo eso, el futuro.

En ese futuro, mi portátil de, no sé, 2029 ya incluirá hardware para poder identificarme con mi presencia, y podremos olvidarnos de las contraseñas. En el presente, déjenme con mi campo y botón para introducir mi contraseña. Gracias.

Imagen: Google.

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

Los equipos son cada vez más potentes, y probablemente por eso, o por lo menos es así en mi caso, cada vez se escucha o lee menos sobre escritorios como el que usa Lubuntu. Pero no todos ni en todas partes es posible tener un equipo medio, y a ese tipo de personas les alegrará leer noticias como la que os traemos hoy. LXQt 1.4.0 ha sido lanzado hace escasos minutos, y debería ser la última versión en usar Qt5.

Qt6 hace tiempo que está disponible, de hecho ya vamos por la sexta actualización de punto, pero los cambios hay que hacerlos con cautela. KDE también sigue usando Qt5, y aún faltan tres meses para que suban al 6. LXQt 1.4.0 se mantiene en Qt 5.15, y si todo va como esperan es la última versión que lo hará. Incluso si tienen que retrasar el lanzamiento de LXQt 1.5.0, esos son los planes. El resto de novedades que han llegado junto a LXQt 1.4.0 es lo que tenéis en la siguiente lista.

Novedades más destacadas de LXQt 1.4.0

• General:
  • Se libera lxqt-menu-data para reemplazar a lxmenu-data donde sea necesario.
  • En el gestor de archivos de LXQt y su biblioteca, el usuario puede ahora añadir el comando para el terminal por defecto, el estado de la vista dividida se tiene en cuenta al restaurar las pestañas de la última ventana, se añade un icono SVG para PCManFM-Qt, se recuerdan las configuraciones de contraseña y anonimato del diálogo de montaje, y se realizan varias correcciones y mejoras en los códigos.
  • QTerminal soporta timbre audible como opción. Además, se soporta el intercambio de botones del ratón al estilo Putty, y se añade el esquema de color Falcon.
  • El visor de imágenes de LXQt tiene ahora un soporte mínimo para espacios de color.
  • Se solucionan viejos problemas en la comprobación/eliminación de la urgencia y el ciclado de ventanas con la rueda del ratón en la barra de tareas de LXQt Panel, y se añade una opción al plugin de comandos personalizados para mostrar la salida como una imagen.
  • LXQt Session actualiza el entorno de activación DBus, para solucionar problemas con aplicaciones (como Telegram) que establecen DBusActivatable a true en sus entradas de escritorio.
  • Las traducciones han recibido muchas actualizaciones.
• LibFM-Qt/PCManFM-Qt:
  • Utilizar lxqt-menu-data en lugar de lxmenu-data.
  • Permitir a los usuarios añadir comandos de terminal.
  • Incluir el estado de la vista dividida al restaurar las pestañas de la última ventana.
  • Recordar la contraseña y la configuración de anonimato del diálogo de montaje.
  • No seleccionar extensiones al crear nuevos archivos de plantilla.
  • Corregido un fallo al borrar la barra de ruta.
  • Se comprueba si la caché del fondo de pantalla está actualizada al leer la configuración del Escritorio.
  • Corregida la opción de línea de comandos –wallpaper-mode.
• LXQt Panel:
  • Utilizar lxqt-menu-data en lugar de lxmenu-data.
  • Corregida la comprobación/eliminación de la urgencia en la barra de tareas.
  • Corregido el ciclado de ventanas con la rueda del ratón y la prevención de robo de foco en la barra de tareas.
  • Se añade una opción al plugin de comandos personalizados para mostrar la salida como una imagen.
  • Corregido el volumen inicial mostrado con PulseAudio en el plugin de volumen.
• QTerminal/QTermWidget:
  • Maneja el timbre (BEL, ‘\a’) a través de libcanberra, y añade una opción de «Timbre audible».
  • Soportado el cambio de botón del ratón estilo Putty.
  • Se ha añadido el esquema de colores Falcon.
• LXImage-Qt:
  • Añadido un soporte mínimo para espacios de color.
  • Eliminada la opción de carga de ImageShack (ImageShack requiere ahora una suscripción de pago).
• Se ha actualizado la activación del entorno DBus para solucionar problemas con aplicaciones como Telegram en LXQt Session.

El proyecto ha anunciado la disponibilidad de LXQt 1.4.0 hace tan sólo unos instantes, y eso suele traducirse en que está disponible su código, pero aún no en ninguna distribución Linux. En los próximos días, las Rolling Release empezarán a implementarlo, y a otras irá llegando en un plazo que dependerá de sus filosofías y modelos de desarrollo.

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

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