La Apache Software Foundation dio a conocer hace ya varios dias el lanzamiento de la nueva versión del servidor de conferencias web Apache OpenMeetings 6.1, que permite conferencias de audio y video a través de la Web, así como la colaboración y la mensajería entre los participantes.

En esta nueva versión de OpenMeetings 6.1 se han realizado diversas correcciones de errores de las cuales la mayoría de ellas fueron enfocadas en solucionar los problemas que se tenían en relación con la compatibilidad con algunos navegadores web y tambien en la interfaz. 

Para quienes desconocen de OpenMeetings, deben saber que este es un software de conferencias web que admiten tanto los seminarios web con un orador como las conferencias con un número arbitrario de participantes que interactúan entre sí. El código del proyecto está escrito en Java y distribuido bajo la licencia Apache 2.0.

Las características adicionales incluyen: herramientas para integrarse con un programador de calendario, enviar notificaciones e invitaciones individuales o de transmisión, compartir archivos y documentos, mantener la libreta de direcciones de los participantes, mantener un registro del evento, programar tareas de manera conjunta, transmitir el resultado de las aplicaciones en ejecución (demostración de screencast), realización de votaciones y votaciones.

Un servidor puede servir a un número arbitrario de conferencias celebradas en salas de conferencias virtuales separadas e incluyendo su propio conjunto de participantes. El servidor admite herramientas de gestión de permisos flexibles y un potente sistema de moderación de conferencias. La gestión e interacción de los participantes se realiza a través de la interfaz web.

Principales novedades de Apache OpenMeetings 6.1

En esta nueva versión que se presenta los desarrolladores destacan que han realizado pequeñas mejoras en la interfaz web y se ha mejorado la compatibilidad con los navegadores web, además de que se solucionaron diversos errores que afectaban enormemente el funcionamiento, como por ejemplo que la aplicación de prueba de audio/video no funcionaba con Safari, no había sonido y la cuenta regresiva no funcionaba, había fallas en la descarga de archivos, la herramienta no se mostraba correctamente, la grabación de la sala de entrevistas no funcionaba, se finalizaba de manera inesperada la sesión, lista de usuarios vacía en la sala de presentación, entre otras cosas más.

En la parte de las mejoras que se implementaron en esta nueva versión, esta por ejemplo que en la sección «Admin -> Config» ahora se pueden cambiar los temas, se han mejorado los permisos de administrador, se ha agregado un menú adicional configurable por el usuario a las habitaciones, localización fue mejorada del formulario de cambio de fecha y hora, se mejoró la estabilidad de las salas de conferencias y fueron resueltos diversos problemas relacionados con el uso compartido de pantalla.

De los demás cambios que se destacan en esta nueva versión:

• Solución al error al presionar los botones Recording o Share-desktop
• Actualización de las nuevas versiones de la biblioteca
• Se abordaron los problemas informados por Sonar
• Fusión de las contribuciones de etiquetas
• Mejorar el ícono de carga del archivo
• Menú de ayuda para la sala
• Marcar grupo predeterminado en administración-> grupos
• Wigets-page: apariencia y apariencia como otras listas

Finalmente si quieres conocer más al respecto sobre la liberación de esta nueva versión, puedes consultar los detalles dentro del anuncio oficial. El enlace es este.

¿Cómo obtener Apache OpenMeetings 6.1?

Finalmente, para quienes estén interesados en poder obtener esta nueva versión, pueden dirigirse al sitio web oficial del proyecto y en su sección de descargas podrán encontrar los paquetes binarios, así como también el código para su compilación o también una imagen de Docker ya preparada.

El enlace es este.

Mientras que para el caso de los que usan Arch Linux y derivados podrán encontrar el paquete ya listo en AUR.

También, pueden seguir las instrucciones que se detallan en este enlace, en donde simplemente tendrán que descargar el ultimo paquete estable de la aplicacion, desempaquetar y ejecutar el binario para que inicie el instalador web.

El enlace es este.

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

Hace ya varios dias se dio a conocer la liberación de la nueva versión de la biblioteca SDL 2.0.16 (Simple DirectMedia Layer), destinada a simplificar la escritura de juegos y aplicaciones multimedia. En esta nueva versión se han añadido diversos cambios, entre los cuales se destacan las mejoras de soporte para Wayland, asi como tambien la capacidad de generar y capturar audio usando el servidor multimedia Pipewire y otras cosas más.

Para quienes desconocen de la biblioteca SDL, deben saber que esta, proporciona herramientas como salida de gráficos 2D y 3D acelerada por hardware, procesamiento de entrada, reproducción de audio, salida 3D a través de OpenGL/OpenGL ES y muchas otras operaciones relacionadas.

SDL es oficialmente compatible con Windows, Mac OS X, Linux, iOS y Android, aun que cuenta con el soporte para otras plataformas como QNX, además de otras arquitecturas y sistemas como Sega Dreamcast, GP32, GP2X, etc.

Simple DirectMedia Layer está escrito en C, funciona de forma nativa con C ++ y hay enlaces disponibles para varios otros idiomas, incluidos C # y Python, se distribuye bajo la licencia zlib, esta licencia permite usar SDL libremente en cualquier software.

Pese a estar programado en C, tiene wrappers a otros lenguajes de programación como C++, Ada, C#, BASIC, Erlang, Lua, Java, Python, etc.

Principales novedades de SDL 2.0.16

En esta nueva versión que se presenta de SDL una de las novedades que se destaca es que el soporte para Wayland se ha mejorado enormemente, además de que se ha añadido la capacidad de generar y capturar audio usando el servidor multimedia Pipewire y AAudio (Android) y tambien el soporte para los controladores de juegos Amazon Luna y Xbox Series X.

Otro de los cambios que podremos encontrar es que se agregó soporte para el efecto de vibración adaptativa (retumbar) en los controladores Google Stadia y Nintendo Switch Pro cuando se usa el controlador HIDAPI.

Además de ello la carga del CPU ha sido reducida al procesar las llamadas SDL_WaitEvent() y SDL_WaitEventTimeout() y tambien se ha añadido una definición de extensiones SIMD compatibles con la plataforma Elbrus.

Por la parte de las nuevas características que se han propuesto en esta nueva versión, se mencionan las siguientes:

• SDL_FlashWindow(): permite captar la atención del usuario.
• SDL_GetAudioDeviceSpec(): es para obtener información sobre el formato de audio preferido para el dispositivo especificado.
• SDL_SetWindowAlwaysOnTop(): está orientada a cambiar dinámicamente el indicador SDL_WINDOW_ALWAYS_ON_TOP (anclar sobre otro contenido) para la ventana seleccionada.
• SDL_SetWindowKeyboardGrab(): para capturar la entrada del teclado independientemente del mouse.
• SDL_SoftStretchLinear(): para escalado bilineal entre superficies de 32 bits.
• SDL_UpdateNVTexture(): para actualizar texturas en NV12/21.
• SDL_GameControllerSendEffect() y SDL_JoystickSendEffect(): para enviar efectos personalizados a los controladores de juego DualSense.
• SDL_GameControllerGetSensorDataRate():para obtener datos sobre la intensidad de la información recibida de los sensores de los controladores de juegos de PlayStation y Nintendo Switch.
• SDL_AndroidShowToast(): esta permite mostrar notificaciones ligeras en la plataforma Android.

Finalmente si estás interesado en poder conocer más al respecto de esta nueva versión, puedes consultar los detalles en el siguiente enlace.

¿Como instalar Simple DirectMedia Layer en Linux?

La instalación de esta biblioteca en Linux es bastante sencilla puesto que la mayoría de las distribuciones de Linux cuentan con ella dentro de sus repositorios.

Para el caso de Debian, Ubuntu y distribuciones derivadas de estos, solo tendrán que ejecutar los siguientes comandos en una terminal:

sudo apt-get install libsdl2-2.0
sudo apt-get install libsdl2-dev

Mientras que para el caso de los que son usuarios de Arch Linux solo tenemos que ejecutar lo siguiente:

sudo pacman -S sdl2

Para el caso de los que son usuarios de Fedora, Centos, RHEL o cualquier distribución basada en estas, solo tienen que ejecutar el siguiente comando:

sudo yum install SDL2
sudo yum install SDL2-devel

Para el resto de las distribuciones de Linux, pueden realizar la búsqueda del paquete “sdl” o “libsdl” para su instalación o realizar la descarga y compilación del código fuente.

Esto lo hacen con:

git clone https://hg.libsdl.org/SDL SDL
cd SDL
mkdir build
cd build
./configure
make
sudo make install

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

En cualquier distribución Linux se puede instalar software por distintos medios. Uno es el de los repositorios oficiales, pero también podemos usar paquetes flatpak, snap y AppImage, entre otros. Además de todo esto, Arch Linux tiene AUR, un repositorio de la comunidad en el que encontramos prácticamente todo el software que existe para Linux y que, si no sabemos compilar, podemos gestionar con yay. Por ejemplo, en AUR encontramos extensiones para GIMP que de otra manera tendríamos que buscar, por lo que es la envidia de otras distribuciones. Para intentar suplir esta carencia en Ubuntu existe Pacstall.

Sobre el papel, Pacstall tiene muy buena pinta. Se supone que es una herramienta para automatizar instalaciones de software alojado en GitHub o GitLab en Ubuntu. Nació hace algo más de un año, por lo que podríamos decir que está dando sus primeros pasos, pero, por lo menos ahora mismo, a los usuarios de un sistema operativo basado en Arch sólo puede hacernos gracia por la enorme diferencia.

Pacstall tiene su propio repositorio y se pueden añadir más

El equipo de Pacstall está subiendo los paquetes al repositorio oficial del proyecto, y esta es la principal diferencia con respecto a AUR. El repositorio de la comunidad de Arch lleva años existiendo, y allí se encuentra de todo. En lo que pretende ser su equivalente para Ubuntu llevan subiendo paquetes muy poco tiempo, por lo que la lista de paquetes disponibles es corta.

La duda que tengo al haberlo probado y leído por encima su documentación es cómo será en el futuro. Esta especie de gestor de paquetes permite añadir repositorios, pero en estos momentos la instalación falla porque falta el archivo pacscript necesario para instalar los paquetes. Si en el futuro corrigen esto (o si estoy haciendo algo mal y alguien sabe lo que es, que me lo diga), quizá no sea AUR, pero sí una herramienta muy interesante.

¿Y cómo funciona?

Lo primero que hay que hacer es instalarlo, algo que conseguiremos abriendo un terminal y escribiendo estos comandos:

sudo apt install curl
sudo bash -c "$(curl -fsSL https://git.io/JsADh || wget -q https://git.io/JsADh -O -)"

A partir de ahí, el resto es como apt, pacman, dnf, etc, pero a su manera:

• pacstall seguido de:
  • -I: instalará el paquete.
  • -R: eliminará el paquete.
  • -S: buscará en los repositorios.
  • -A: añadirá un repositorio de GitHub o GitLab.
  • -U: actualizará los scripts de pacstall.
  • -Up: actualizará los paquetes.
  • -h: ayuda.

Si queremos desinstalarlo, lo que tenemos que escribir es lo siguiente:

bash -c "$(curl -fsSL https://git.io/JEZbi || wget -q https://git.io/JEZbi -O -)"

Estaría bien que Ubuntu tuviera su propio AUR, y no sé si Pacstall llegará algún día a parecerse aunque sea mínimamente. De momento sí hay paquetes como Android Studio o Google Chrome. Si la comunidad se va apuntando a colaborar, veremos hasta dónde llega este proyecto.

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

Podría haber sido una novela de Tom Clancy de la serie NetForce, pero es un libro escrito por el presidente de Microsoft Brad Smith en homenaje a si mismo y a su empresa. De todas formas, si uno lee entre líneas (al menos en el extracto al que tuvo acceso un portal) y separa las auto palmadas en la espalda y los palos a los competidores, lo que queda es muy interesante e instructivo. Y, en mi humilde opinión, una muestra de las ventajas del modelo de software libre y de código abierto.

Los personajes

Toda novela de espionaje, necesita un «malo» y, en este caso tenemos nada menos que al SVR, una de las organizaciones que sucedieron al KGB después del colapso de la URSS. El SVR se ocupa de todas las tareas de inteligencia desarrolladas fuera de la frontera de la Federación Rusa. La «víctima inocente» fue SolarWinds, empresa que desarrolla un software para administración de redes utilizado por grandes empresas, administradores de infraestructuras críticas y agencias del gobierno estadounidense. Por supuesto, necesitamos un héroe. En este caso, según ellos mismos, es el Departamento de Inteligencia de Amenazas de Microsoft.

Como no podía ser de otra manera, en una historia de hackers, el «malo» y el «bueno» tienen un alias. El SVR es Yttrium (Itrio). En Microsoft utilizan los elementos menos comunes de la tabla periódica como nombre clave para los posibles orígenes de amenazas. El Departamento de Inteligencia de Amenazas es MSTIC por sus siglas en inglés, aunque internamente lo pronuncian mystic (místico) por la similitud fonética. En adelante, por comodidad voy a usar estos términos.

Microsoft contra SVR. Los hechos

El 30 de noviembre de 2020 FireEye, una de las principales empresas de seguridad informática de EE.UU, descubre que había sufrido una brecha de seguridad en sus propios servidores. Como eran incapaces de solucionarlo por si mismos (Lo siento, pero no puedo dejar de decir lo de «en casa de herrero, cuchillo de palo») decidieron pedir ayuda a los especialistas de Microsoft. Como desde MSTIC venían siguiendo los pasos de Yttrium, enseguida sospecharon de los rusos, diagnóstico posteriormente confirmada por los servicios de inteligencia oficiales de USA.

Con el correr de los días, se comprobó que los ataques estaban dirigidos a redes informáticas sensibles en todo el mundo incluyendo a la propia Microsoft. De acuerdo a trascendidos periodísticos, el gobierno de Estados Unidos era claramente el principal objetivo del ataque, con el Departamento del Tesoro, el Departamento de Estado, el Departamento de Comercio, el Departamento de Energía y partes del Pentágono Por su parte, desde Redmond agregaron a la lista de víctimas docenas de organizaciones afectadas. Entre ellas se cuentan otras empresas tecnológicas, contratistas gubernamentales, grupos de reflexión y una universidad. Los ataques no solo se dirigieron contra Estados Unidos ya que hubo afectados en Canadá, el Reino Unido, Bélgica, España, Israel y los Emiratos Árabes Unidos. En algunos de los casos, las penetraciones en la red se prolongaron durante varios meses.

El origen

Todo comenzó con un software de manejo de redes llamado Orion y desarrollado por una empresa llamada SolarWinds. Con más de 38000 clientes corporativos de alto nivel, los atacantes solo tuvieron que insertar un malware en una actualización.

Una vez instalado, el malware se conectaba a lo que técnicamente se conoce como un servidor de comando y control (C2). El servidor C2 estaba programado para dar al ordenador conectado tareas como la capacidad de transferir archivos, ejecutar comandos, reiniciar una máquina y desactivar los servicios del sistema. En otras palabras los agentes de Yttrium conseguían un acceso total a la red de quienes habían instalado la actualización del programa Orion.

A continuación les voy a citar un párrafo textual del artículo de Smith

No tardamos en darnos cuenta de la importancia del trabajo técnico en equipo en toda la industria y con el gobierno de Estados Unidos. Los ingenieros de SolarWinds, FireEye y Microsoft empezaron a trabajar juntos inmediatamente. Los equipos de FireEye y Microsoft se conocían bien, pero SolarWinds era una empresa más pequeña que se enfrentaba a una gran crisis, y los equipos tenían que crear confianza rápidamente si querían ser eficaces. Los ingenieros de SolarWinds compartieron el código fuente de su actualización con los equipos de seguridad de las otras dos empresas, lo que reveló el código fuente del propio malware. Los equipos técnicos del gobierno estadounidense entraron rápidamente en acción, especialmente en la Agencia de Seguridad Nacional (NSA) y en la Agencia de Ciberseguridad y Seguridad de las Infraestructuras (CISA) del Departamento de Seguridad Nacional.

Los resaltados son míos. Eso de trabajo en equipo y compartir el código fuente ¿No les suena de algo?

Después de abrir la puerta trasera, el malware permanecia inactivo durante dos semanas, para evitar crear entradas de registro de red que alertaran a los administradores. Pasado ese lapso, enviaba información sobre la red que había infectado a un servidor de mando y control que los atacantes habían con el proveedor de hosting GoDaddy.

Si el contenido resultaba interesante para Yttrium, los atacantes entraban a través de la puerta trasera e instalaban código adicional en el servidor atacado para conectarse a un segundo servidor de mando y control. Este segundo servidor, único para cada víctima para ayudar a evadir la detección, estaba registrado y alojado en un segundo centro de datos, a menudo en la nube de Amazon Web Services (AWS).

Microsoft contra el SVR. La moraleja

Si están interesados en saber como nuestros héroes dieron su merecido a los villanos, en los primeros párrafos tienen los enlaces a las fuentes. Voy a pasar directamente al motivo por el cuál escribo sobre esto en un blog sobre Linux. El enfrentamiento de Microsoft contra el SVR demuestra la importancia de que el código esté disponible para ser analizado, y que el conocimiento sea colectivo.

Es cierto, como me recordó esta mañana un prestigioso especialista en el tema seguridad informática, que de nada sirve que el código sea abierto si nadie se toma el trabajo de analizarlo. Está el caso Heartbleed para demostrarlo. Pero, recapitulemos. 38000 clientes de alto nivel contrataron un software privativo. Varios de ellos instalaron una actualización con malware que expuso información sensible y dio control a elementos hostiles de infraestructura crítica. La empresa responsable solo puso el código a disposición de los especialistas cuando estaba con el agua al cuello. Si se exigiera a los proveedores de software para infraestructura crítica y clientes sensibles liberar su software con licencias abiertas, y a estos tener un auditor de código residente (o una agencia externa que trabaje para varios) el riesgo de ataques como SolarWinds sería mucho menor.

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

Podría haber sido una novela de Tom Clancy de la serie NetForce, pero es un libro escrito por el presidente de Microsoft Brad Smith en homenaje a si mismo y a su empresa. De todas formas, si uno lee entre líneas (al menos en el extracto al que tuvo acceso un portal) y separa las auto palmadas en la espalda y los palos a los competidores, lo que queda es muy interesante e instructivo. Y, en mi humilde opinión, una muestra de las ventajas del modelo de software libre y de código abierto.

Los personajes

Toda novela de espionaje, necesita un «malo» y, en este caso tenemos nada menos que al SVR, una de las organizaciones que sucedieron al KGB después del colapso de la URSS. El SVR se ocupa de todas las tareas de inteligencia desarrolladas fuera de la frontera de la Federación Rusa. La «víctima inocente» fue SolarWinds, empresa que desarrolla un software para administración de redes utilizado por grandes empresas, administradores de infraestructuras críticas y agencias del gobierno estadounidense. Por supuesto, necesitamos un héroe. En este caso, según ellos mismos, es el Departamento de Inteligencia de Amenazas de Microsoft.

Como no podía ser de otra manera, en una historia de hackers, el «malo» y el «bueno» tienen un alias. El SVR es Yttrium (Itrio). En Microsoft utilizan los elementos menos comunes de la tabla periódica como nombre clave para los posibles orígenes de amenazas. El Departamento de Inteligencia de Amenazas es MSTIC por sus siglas en inglés, aunque internamente lo pronuncian mystic (místico) por la similitud fonética. En adelante, por comodidad voy a usar estos términos.

Microsoft contra SVR. Los hechos

El 30 de noviembre de 2020 FireEye, una de las principales empresas de seguridad informática de EE.UU, descubre que había sufrido una brecha de seguridad en sus propios servidores. Como eran incapaces de solucionarlo por si mismos (Lo siento, pero no puedo dejar de decir lo de «en casa de herrero, cuchillo de palo») decidieron pedir ayuda a los especialistas de Microsoft. Como desde MSTIC venían siguiendo los pasos de Yttrium, enseguida sospecharon de los rusos, diagnóstico posteriormente confirmada por los servicios de inteligencia oficiales de USA.

Con el correr de los días, se comprobó que los ataques estaban dirigidos a redes informáticas sensibles en todo el mundo incluyendo a la propia Microsoft. De acuerdo a trascendidos periodísticos, el gobierno de Estados Unidos era claramente el principal objetivo del ataque, con el Departamento del Tesoro, el Departamento de Estado, el Departamento de Comercio, el Departamento de Energía y partes del Pentágono Por su parte, desde Redmond agregaron a la lista de víctimas docenas de organizaciones afectadas. Entre ellas se cuentan otras empresas tecnológicas, contratistas gubernamentales, grupos de reflexión y una universidad. Los ataques no solo se dirigieron contra Estados Unidos ya que hubo afectados en Canadá, el Reino Unido, Bélgica, España, Israel y los Emiratos Árabes Unidos. En algunos de los casos, las penetraciones en la red se prolongaron durante varios meses.

El origen

Todo comenzó con un software de manejo de redes llamado Orion y desarrollado por una empresa llamada SolarWinds. Con más de 38000 clientes corporativos de alto nivel, los atacantes solo tuvieron que insertar un malware en una actualización.

Una vez instalado, el malware se conectaba a lo que técnicamente se conoce como un servidor de comando y control (C2). El servidor C2 estaba programado para dar al ordenador conectado tareas como la capacidad de transferir archivos, ejecutar comandos, reiniciar una máquina y desactivar los servicios del sistema. En otras palabras los agentes de Yttrium conseguían un acceso total a la red de quienes habían instalado la actualización del programa Orion.

A continuación les voy a citar un párrafo textual del artículo de Smith

No tardamos en darnos cuenta de la importancia del trabajo técnico en equipo en toda la industria y con el gobierno de Estados Unidos. Los ingenieros de SolarWinds, FireEye y Microsoft empezaron a trabajar juntos inmediatamente. Los equipos de FireEye y Microsoft se conocían bien, pero SolarWinds era una empresa más pequeña que se enfrentaba a una gran crisis, y los equipos tenían que crear confianza rápidamente si querían ser eficaces. Los ingenieros de SolarWinds compartieron el código fuente de su actualización con los equipos de seguridad de las otras dos empresas, lo que reveló el código fuente del propio malware. Los equipos técnicos del gobierno estadounidense entraron rápidamente en acción, especialmente en la Agencia de Seguridad Nacional (NSA) y en la Agencia de Ciberseguridad y Seguridad de las Infraestructuras (CISA) del Departamento de Seguridad Nacional.

Los resaltados son míos. Eso de trabajo en equipo y compartir el código fuente ¿No les suena de algo?

Después de abrir la puerta trasera, el malware permanecia inactivo durante dos semanas, para evitar crear entradas de registro de red que alertaran a los administradores. Pasado ese lapso, enviaba información sobre la red que había infectado a un servidor de mando y control que los atacantes habían con el proveedor de hosting GoDaddy.

Si el contenido resultaba interesante para Yttrium, los atacantes entraban a través de la puerta trasera e instalaban código adicional en el servidor atacado para conectarse a un segundo servidor de mando y control. Este segundo servidor, único para cada víctima para ayudar a evadir la detección, estaba registrado y alojado en un segundo centro de datos, a menudo en la nube de Amazon Web Services (AWS).

Microsoft contra el SVR. La moraleja

Si están interesados en saber como nuestros héroes dieron su merecido a los villanos, en los primeros párrafos tienen los enlaces a las fuentes. Voy a pasar directamente al motivo por el cuál escribo sobre esto en un blog sobre Linux. El enfrentamiento de Microsoft contra el SVR demuestra la importancia de que el código esté disponible para ser analizado, y que el conocimiento sea colectivo.

Es cierto, como me recordó esta mañana un prestigioso especialista en el tema seguridad informática, que de nada sirve que el código sea abierto si nadie se toma el trabajo de analizarlo. Está el caso Heartbleed para demostrarlo. Pero, recapitulemos. 38000 clientes de alto nivel contrataron un software privativo. Varios de ellos instalaron una actualización con malware que expuso información sensible y dio control a elementos hostiles de infraestructura crítica. La empresa responsable solo puso el código a disposición de los especialistas cuando estaba con el agua al cuello. Si se exigiera a los proveedores de software para infraestructura crítica y clientes sensibles liberar su software con licencias abiertas, y a estos tener un auditor de código residente (o una agencia externa que trabaje para varios) el riesgo de ataques como SolarWinds sería mucho menor.

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

WineHQ ha vuelto a cumplir puntual con su calendario y, tras la anterior v6.16, hoy ha lanzado WINE 6.17. Se trata de una nueva versión Staging, etiqueta que reciben las versiones de desarrollo en las que van añadiendo novedades cada dos semanas, pero las cosas no están tan pulidas como para que la etiqueta sea Estable. Como casi siempre en esta fase del desarrollo, el equipo del proyecto ha aprovechado para introducir muchos cambios.

En WINE 6.17 se han corregido 12 bugs, pero han realizado 375 cambios en total. Entre ellos, esta semana han vuelto a destacar algo relacionado al DPI junto a otros cuatro puntos, siendo el último el habitual corrección de errores. La lista de novedades que han considerado lo suficientemente importantes como para separarlas del resto es la siguiente.

Novedades más destacadas de WINE 6.17

• Programa WineCfg convertido a PE.
• Mejor soporte de alta DPI en las aplicaciones incorporadas.
• Más trabajo de preparación para la interfaz GDI syscall.
• Soporte mejorado del depurador en modo Wow64.
• Varias correcciones de errores.

WINE 6.17, del que tenemos que volver a recordar que es una versión Staging o de desarrollo y no estable, ya se puede descargar desde este o este otro enlace. El proyecto también aporta información para descargar esta y futuras actualizaciones añadiendo el repositorio oficial para Linux aquí, pero también se puede instalar en macOS y Android. Si se añade el repositorio se puede elegir entre las versiones estable, Staging o Dev.

En este punto del desarrollo, ya nos estamos acercando al momento en el que empezarán a llegar las Release Candidates, pero lo más probable es que la próxima versión sea WINE 6.18 y que sea lanzada el próximo 24 de septiembre. En WINE 5.x se lanzaron 22 versiones Staging, momento en el que ya pasaron a lanzar las Release Candidates semanalmente. Si se confirma la nueva versión Staging, volverán a introducir cientos de retoques.

from Linux Adictos https://ift.tt/38UdMOG
via IFTTT

Microsoft ha dado a conocer hace pocos dias la noticia de que ha liberado el código fuente de su herramienta «GCToolkit», el cual es un conjunto de bibliotecas para analizar los archivos de registro de Java Garbage Collection, con lo cual todo el código de GCToolkit está disponible en GitHub bajo la licencia MIT.

GCToolkit consta de tres módulos Java que cubren API, analizadores de archivos de registro de GC y una placa posterior de mensajes basada en el kit de herramientas Vert.x para crear aplicaciones receptivas en la JVM. Con esta utilidad, los usuarios pueden crear exploraciones arbitrarias y complejas del estado de la memoria administrada en la JVM.

Como su nombre indica, este es un conjunto de bibliotecas para analizar archivos de registro de recolección de basura (GC) de Java y analizarlos en eventos separados. Expone una API para mejorar la interacción con el kit de herramientas y la agregación de datos, esto permite al usuario crear análisis complejos arbitrarios del estado de la memoria administrada de la JVM.

Según el equipo, este es el punto de entrada del usuario en GCToolkit que oculta los detalles de los módulos internos en unas pocas llamadas a métodos. Además de la API, hay otros dos módulos: el módulo de análisis sintáctico y Vert.x. El Módulo Analizador se basa en una colección de expresiones regulares y código escrito para ser considerado el analizador de registros GC más robusto disponible.

El back-end de mensajería basado en Vert.xutiliza dos buses de mensajes: el primero transmite datos desde una fuente de datos. La implementación actual pasa líneas de registro del archivo de registro de GC. Los consumidores de este bus son los analizadores que convierten los datos de la fuente de datos en eventos que representan un ciclo de GC o un punto seguro. Estos eventos se publican en el segundo bus de mensajes: el bus de eventos. Los suscriptores del bus de eventos pueden entonces ser notificados y procesar los eventos que les interesan.

El analizador emite eventos JVM discretos, lo que le permite escribir código para capturar y analizar datos de estos eventos. Para facilitar la captura de datos y el análisis de los archivos de registro de GC, GCToolkit proporciona un marco de agregación simple. El tipo de datos que los usuarios desean capturar o el tipo de análisis que desean realizar queda a discreción del usuario. Por ejemplo, para capturar eventos de pausa con el fin de analizar la ocupación del montón, el agregador captura el evento, extrae los datos relevantes y pasa los datos a la agregación.

Esto reúne los datos en un análisis significativo, por ejemplo, la ocupación total del montón después de la recolección de basura. Los datos resultantes se pueden presentar en forma de gráfico, tabla u otro formato más fácil de usar. Más importante aún, según el equipo, una configuración subóptima del colector resultará en una aplicación que requerirá más CPU y memoria, mientras degrada la experiencia del usuario final. En otras palabras, un colector mal ajustado a menudo significa un tiempo de ejecución más caro y usuarios insatisfechos.

Con el creciente interés de Microsoft en la plataforma Java, el enfoque en el código abierto también está aumentando los beneficios para la comunidad Java. Después de realizar importantes contribuciones para portar macOS M1 y Windows to Arm, Microsoft reafirmó su compromiso con OpenJDK al presentar su propia versión de OpenJDK y uniéndose al grupo de trabajo Eclipse Adoptium (anteriormente conocido como AdoptOpenJDK).

Al hacer que GCToolkit sea de código abierto, Microsoft está intentando proporcionar una mejor manera de ver los detalles internos de la JVM sobre cómo maneja GC y la asignación de memoria. Una mejor visibilidad permite una mejor configuración, lo que beneficia tanto a los usuarios finales de la aplicación como al personal técnico responsable de su gestión.

La API simple y los mecanismos de salida fáciles de usar prometen mejorar la tarea de leer los registros de GC al proporcionar varios mecanismos para analizar, extraer y visualizar datos.

Fuente: https://devblogs.microsoft.com

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

Hace poco se dio a conocer la noticia de que Microsoft se ha unido a como miembro «Platino» a la Open Infrastructure Foundation, la cual es una organización que ayuda a las comunidades de código abierto a crear las herramientas que los operadores de infraestructura necesitan para la tecnología de computación en la nube del centro de datos, 5G, Edge, contenedores, CI/CD y más.

Los intereses de Microsoft en la vida de la comunidad OpenInfra están relacionados con la conexión con el desarrollo de proyectos abiertos para plataformas de nube híbrida y sistemas 5G, así como con la integración del soporte para proyectos de Open Infrastructure Foundation en el producto Microsoft Azure.

El anuncio fue realizado por Jonathan Bryce, director ejecutivo de la fundación y en su anuncio compartió lo siguiente:

«La Fundación OpenInfra ha firmado un acuerdo con Microsoft como nuevo miembro platino. A través de este compromiso de varios años, la comunidad OpenInfra trabajará en estrecha colaboración con Microsoft para promover casos de uso de infraestructura abierta, incluida la nube híbrida y 5G, participando y contribuyendo a múltiples comunidades de proyectos de código abierto ”.

Con ello Microsoft se une a más de 60 organizaciones miembros de la Fundación, cuya misión es crear comunidades de código abierto que desarrollen software que se ejecute en producción. Con el apoyo de más de 110.000 personas en 187 países, la Fundación OpenInfra alberga proyectos de código abierto y comunidades de práctica, que incluyen infraestructura para IA, aplicaciones nativas de contenedores, computación en el borde y nubes centrales de datos. Sus proyectos incluyen Airship, Kata Containers, OpenInfra Labs, OpenStack, StarlingX, Zuul y de los más recientes, el apoyo al proyecto Magma 5G.

Facebook desarrolló Magma para ayudar a los operadores de telecomunicaciones a implementar redes móviles de forma rápida y sencilla. El proyecto, que Facebook hizo de código abierto en 2019, lo logra al proporcionar un núcleo de paquetes móviles distribuidos centrados en software y herramientas para automatizar la gestión de la red. Esta función de red en contenedores se integra con el fondo de una red móvil existente y facilita el lanzamiento de nuevos servicios en el borde de la red.

Microsoft se une a un impresionante grupo de empresas como miembro platino de la nueva OpenInfra Foundation, que incluye Ant Group, Ericsson, Facebook, FiberHome, Huawei, Red Hat, Tencent y Wind River, todos los cuales aportan su experiencia operativa desde la infraestructura a gran escala a la comunidad que escribe software de código abierto para la próxima década de OpenInfra ”, dijo Mark Collier, director de operaciones de la Fundación OpenInfra.

“Software como OpenStack, que impulsa a 9 de las 10 principales redes de telecomunicaciones del mundo en la actualidad, Kata Containers, que asegura la red de pago más grande del mundo, y Airship, que impulsa las redes 4G y 5G de AT&T en producción hoy” hui. «

«Microsoft se une a este esfuerzo para apoyar la construcción de la próxima década de tecnología de infraestructura abierta porque la nube híbrida es una parte muy importante de nuestra cartera de tecnología», dijo van Wyk. “Creemos en una variedad de nubes: públicas y privadas, desde la hiperescala hasta el borde, cada una adaptada a las cargas de trabajo únicas que nuestros clientes deben entregar y no podemos hacerlo sin el código abierto. Estamos aquí en la Fundación OpenInfra para participar en la comunidad y trabajar juntos para construir e integrar tecnologías de código abierto para proporcionar una infraestructura de Microsoft Azure de calidad de operador para los operadores. «

Aunque Ant Group y Tencent tienen antecedentes en la nube, Collier destacó que Microsoft es un gran avance dado que es el primero de los tres grandes proveedores de nube de EE. UU. En unirse a la OIF. Señaló que una encuesta reciente de usuarios de OpenStack encontró que el 40% de los usuarios que implementan en una configuración de múltiples nubes ya están usando Microsoft Azure.

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/3l2h5ZK
via IFTTT

Desde hace mucho tiempo y al igual que muchas otras empresas de tecnología, AMD ha estado dedicando una gran cantidad de esfuerzo para ampliar los límites de la computación cuántica en la actualidad y todo su trabajo ha comenzado a dar frutos, ya que recientemente la compañía presentó una solicitud de patente en la que dio a conocer un procesador de computación cuántica que usaría la teletransportación.

Esta nueva tecnología patentada podría resolver los problemas de estabilidad y eficiencia que enfrentan los sistemas actuales en computación cuántica, aun que claro esta que la tecnología puede estar lejos de ser comercialmente viable, pero esta solicitud de patente demuestra el interés de AMD en el futuro.

Y es que en este momento existen dos obstáculos importantes se interponen en el camino del desarrollo cuántico y la supremacía cuántica final: escalabilidad y estabilidad. Los estados cuánticos son materia voluble, tan sensibles que pueden salir mal con la menor provocación y, además, la sensibilidad de un sistema cuántico tiende a aumentar con la presencia de más qubits en un sistema dado. Sin embargo, un equipo de investigadores de AMD ha presentado una solicitud de patente dirigida a una arquitectura de computación cuántica más eficiente y confiable, gracias a un enfoque convencional multi-SIMD (Single Instruction Multiple Data).

Según los analistas, si AMD pudiera obtener una ventaja competitiva en la computación cuántica, el potencial de ganancias sería ilimitado. La directora ejecutiva de AMD, Lisa Su, ha revitalizado a este diseñador de chips e inculcado una cultura de innovación que ha impulsado a AMD hasta un 3,200% desde que asumió la dirección de la empresa en 2014. Según la solicitud presentada por los investigadores de la empresa, AMD está investigando un sistema que tiene como objetivo utilizar la teletransportación cuántica para aumentar la confiabilidad de un sistema cuántico, mientras que simultáneamente reduce el número de qubits necesarios para un cálculo dado.

El objetivo es mitigar los problemas de escala y los errores de cálculo debido a la inestabilidad del sistema:

La patente de AMD, titulada «Teletransportación anticipada para una computación confiable en un procesador cuántico multi-SIMD», tiene como objetivo mejorar la estabilidad, escalabilidad y rendimiento de los sistemas de computación cuántica de formas nuevas y más eficientes. La compañía describe una arquitectura cuántica basada en regiones de procesamiento cuántico: áreas del chip que contienen o pueden contener qubits, esperando su turno en la tubería de procesamiento.

De hecho, el diseño de AMD, aunque digno de ciencia ficción, apunta a teletransportar qubits de una región a otra, permitiendo así cargas de trabajo que en teoría requerirían ejecución para ser tratadas con una filosofía fuera de orden, ya que la ejecución en orden tiene dependencias entre una instrucción y la siguiente, lo que significa que una carga de trabajo debe procesarse secuencialmente. Los siguientes pasos dependen del procesamiento completo del paso anterior y de conocer su resultado antes de que el chip pueda continuar con el cálculo.

Por lo tanto, algunos de los recursos del chip (en este caso, los qubits) permanecen inactivos hasta que llega el momento de realizar el siguiente paso de cálculo. Por el contrario, la ejecución fuera de orden analiza una determinada carga de trabajo, determina qué partes dependen de resultados anteriores y cuáles no, y ejecuta cada paso de la declaración que no requiere un resultado previo, mejorando así el rendimiento gracias a un mayor paralelismo.

La patente de AMD también incluye un procesador de «anticipación» integrado en la arquitectura, responsable de analizar la carga de trabajo de entrada, predecir qué pasos se pueden procesar en paralelo (y cuáles no) y distribuir adecuadamente la carga de trabajo entre los qubits, utilizando una teletransportación cuántica para enrutarlos a la región SIMD de procesamiento cuántico requerida. La forma en que se produce esta teletransportación cuántica no se describe en la patente.

Hasta ahora, solo se han identificado tres empresas en el mercado de las computadoras cuánticas: IBM, Intel y Google. Esta solicitud de patente muestra que AMD no tiene la intención de abandonar este campo y también está trabajando para desarrollar sus tecnologías allí.

Fuente: https://www.freepatentsonline.com/

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

A finales de marzo del presente año, compartimos aquí en el blog la noticia de la demanda que realizo la gente de Xinuos ha iniciado acciones legales contra IBM y Red Hat y es que Xinuos afirma que IBM copió ilegalmente el código de Xinuos para sus sistemas operativos de servidor y conspiró con Red Hat para dividir ilegalmente el mercado.

Todo esto comenzó en 1995 con la venta por parte de Novell del código Unix a la empresa SCO (SCO, un proveedor de UNIX para procesadores x86). Esta venta generó dos interpretaciones entre los participantes, ya que Novell considera que solo ha cedido el código, no los derechos de propiedad intelectual, lo cual SCO afirma haber comprado ambos.

En 1998, IBM, Santa Cruz Operation y otros se unieron para crear Project Monterey, con el objetivo de desarrollar una versión de UNIX que se ejecute en múltiples plataformas de hardware (algo que la comunidad de Linux también había comenzado a hacer)

En 2001, IBM decidió que Linux era el futuro y abandonó Project Monterey, incluso arrastrando a algunos de los participantes del Proyecto Monterey a su paso. Para entonces, Big Blue había creado una versión experimental de su propio sistema operativo AIX similar a UNIX que usaba código SCO.

Pero una vez que abandonó el proyecto, IBM transfirió parte de su propiedad intelectual a Linux. SCO se opuso a estas contribuciones porque consideró que IBM había cedido sus activos al código base de código abierto de Linux.

Además, el 6 de marzo de 2003, Caldera Systems, rebautizada como SCO, entabló una acción contra IBM por haber incumplido el contrato de su proyecto conjunto de Monterey que se refería al desarrollo conjunto de un sistema operativo Unix. El demandante acusó notablemente a Big Blue de haber revelado parte del código fuente de Unix y los métodos para contribuir a Linux y para desarrollar AIX, la propia versión de Unix de IBM reclamando inicialmente $ 1 mil millones en daños, su reclamo aumentó rápidamente en tres meses para llegar a $ 3 mil millones.

Contraatacado por IBM en agosto de 2003 en un tribunal federal de Utah y provocando un clamor sin precedentes en el mundo de las tecnologías de la información (desde la Free Software Foundation hasta Novell, incluidos sus propios empleados), SCO se encontró rápidamente en muy mal estado.

El 10 de agosto de 2007, el juez Kimball pronuncia un veredicto decidido: indica que Novell es de hecho el propietario de los derechos de autor de Unix y UnixWare.  Ante tal fracaso y visiblemente disgustada, la empresa estaba en peligro. Su facturación había caído de 250 millones de dólares a 15 millones de dólares por año debido a la nueva competencia de Linux.

Ahora, el 26 de agosto de 2021, en una petición de acuerdo del Tribunal de Quiebras de los Estados Unidos para el Distrito de Delaware indica que las partes «han acordado resolver todas las disputas entre ellas mediante un pago al administrador (…) de 14,250,000 dólares» dentro de cinco días a partir de la fecha de vigencia del acuerdo de conciliación.

Claramente, si la propuesta es aceptada por ambas partes, este acuerdo pondría fin al juicio de la ex SCO con IBM. En 5 días, IBM tendrá que pagar los $ 14,25 millones mediante transferencia al administrador que gestiona la quiebra de SCO, que pasó a llamarse TSG Group. Para estos últimos, esta propuesta se realiza de manera razonable, tomando en cuenta el mejor interés de los acreedores y debe ser aprobada.

Pero esto no termina aquí, ya este conflicto podría ser llevado por otra entidad. De hecho, aunque SCO quebró, su propiedad intelectual siguió viviendo bajo los nuevos propietarios. IBM siguió luchando y las organizaciones que heredaron la propiedad intelectual de SCO continuaron probando nuevos rincones, encontrando nuevas fuentes de financiación.

Xinuos, que se hizo cargo de los activos de SCO hace 10 años, ha vuelto contra IBM. Big Blue es nuevamente acusado, esta vez por Xinuos, de haber copiado ilegalmente el código del software que este último compró a SCO para usarlo en su sistema operativo.

Xinuos, presentó una demanda a principios de este año, alegando robo de propiedad intelectual y colusión del mercado monopolista contra los demandados conjuntos IBM y Red Hat. Xinuos se formó en torno a los activos de SCO Group hace unos diez años bajo el nombre de UnXis y, en ese momento, el sucesor de SCO no tenía ningún interés en continuar la larga disputa de este último sobre Linux.

La demanda alega que IBM incorporó código no especificado del código UnixWare y OpenServer de la compañía en el propio sistema operativo AIX de IBM. También alega que IBM y Red Hat conspiraron directamente para dividir todo el mercado de sistemas operativos tipo Unix en grandes oportunidades comerciales para IBM, dejando a Xinuos en la oscuridad.

La demanda de Xinuos también afirma que IBM ha engañado a los inversores al declarar en sus informes anuales desde 2008 que posee todos los derechos de autor en Unix y UnixWare.

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