Después de un año de desarrollo los desarrolladores de OpenMandriva dieron a conocer el lanzamiento de la nueva versión de OpenMandriva Lx 4.2 que llega con algunas novedades bastante interesantes, de las cuales podemos destacar la creación de port para dispositivos con procesadores ARM, asi como también la actualización de paquetes y otras cosas más.

Para quienes desconocen de OpenMandriva Lx, deben saber que esta es una distribución de Linux creada y orientada para todo tipo de usuarios, esta distribución es distribuida y desarrollada por la asociación llamada OpenMandriva, la cual es una asociación sin fines de lucro.

Esta distribución de Linux esta basada en Mandriva Linux la cual fue una distribución francesa, no tan popular entre los usuarios de Linux, pero que en su tiempo algunos usuarios llegaron a recomendar.

Para aquellas personas que no les suene el nombre de Mandriva Linux les puedo comentar lo siguiente sobre esta distribución de Linux que finalizo su desarrollo hace ya varios años.

Mandriva Linux fue una distribución de Linux publicada por la compañía francesa Mandriva destinada tanto para principiantes como para usuarios experimentados, orientada a computadoras personales y servidores con un enfoque a los usuarios que se están introduciendo al mundo de Linux y al software libre.

Principales novedades de OpenMandriva Lx 4.2

En la nueva versión se destaca que se ha preparado un port para procesadores ARM de 64 bits (aarch64) y se han iniciado montajes para Pinebook Pro, Raspberry Pi 4B/3B+, Rock Pi 4A, 4B y 4C, Synquacer, Cubox Pulse, así como un montaje general para servidor placas que admiten UEFI.

Además, con base en lo anterior se está trabajando para crear una variante de OpenMandriva para teléfonos inteligentes, ya que los desarrolladores han generado el ensamblaje experimental correspondiente para el dispositivo PinePhone y se comenzó a trabajar en un port para la arquitectura RISC-V, que no se incluyó en la versión 4.2.

En cuanto por la parte de las actualizaciones, en esta nueva versión de OpenMandriva Lx 4.2 se destaca la actualización del entorno de escritorio KDE Plasma 5.20.5, KDE Frameworks 5.78.0 y KDE Applications 20.12.2, mientras que los componentes de la pila de gráficos se han actualizado a Wayland 1.20.10, Mesa 20.3, Xorg Server 1.20.10 y Qt 5.15.2.

Se ha mejorado la aplicación OM Welcome, diseñada para la configuración inicial y la familiarización del usuario con el sistema, en la que fue posible instalar rápidamente programas adicionales estándar que no están incluidos en la entrega básica.

Se actualizaron los componentes del sistema, incluido el kernel de Linux 5.10.14, systemd 247, GCC 10.2, GLibc 2.33, Java 15 y el instalador se actualizó a la versión Calamares 3.2.35.

También se destaca que se actualizó el configurador Desktop Presets (om-feeling-like), que ofrece un conjunto de presets que le permiten darle al escritorio KDE Plasma el aspecto de otros entornos (por ejemplo, hacer que parezca la interfaz de Ubuntu, Windows 7, Windows 10, macOS, etc.).

Por otra parte, el kernel de Linux incluye soporte para la compresión mediante el algoritmo Zstandard, que se ha utilizado para acelerar la carga. Como en la versión anterior, además del kernel de Linux estándar compilado con GCC (paquete «kernel-release-desktop»), se proporciona una versión del kernel compilada con Clang (kernel-release-desktop-clang).

El compilador de Clang usado para construir paquetes se ha actualizado a la rama LLVM 11. Para construir todos los componentes de la distribución, solo puedes hacerlo con Clang.

De los demás componentes del sistema, de los más destacables se mencionan las versiones actualizadas de las siguientes aplicaciones incluidas LibreOffice 7.1.0, Falkon 3.1, Firefox 85, Chromium 88 (beta 89, dev 90), Krita 4.4.2, GIMP 2.10.22, Calligra Suite 3.2.1, Digikam 7.2, SMPlayer 21.1. 0, VLC 3.0.12, Virtualbox 6.1.16 y OBS Studio 26.1.2.

Finalmente si estás interesado en conocer más al respecto sobre este nuevo lanzamiento de OpenMandriva Lx 4.2, puedes consultar los detalles en el siguiente enlace.

Obtener OpenMandriva Lx 4.2

Para quienes estén interesados en poder descargar esta nueva versión pueden obtener las imágenes del sistema ya preparadas para los diferentes dispositivos, desde el sitio web oficial de la distribución.

En ella podrán encontrar la imagen Live de 2.4 GB (x86_64), «znver1», optimizado para procesadores AMD Ryzen, ThreadRipper y EPYC, así como imágenes para usar en dispositivos ARM Pinebook Pro, Rock Pi 4 (A/B /C), Raspberry Pi 400, Raspberry Pi 4B y Raspberry Pi 3B+.

El enlace es este.

from Linux Adictos https://ift.tt/37Mbpgy
via IFTTT

Durante los últimos dias los desarrolladores de Tor dieron a conocer dos noticias importantes una de ellas es el lanzamiento de la nueva versión  de Tor 0.4.5.6 (utilizado para organizar el trabajo de la red anónima Tor).

Tor 0.4.5.6 se considera la primera versión estable de la rama 0.4.5, que ha evolucionado durante los últimos cinco meses. La rama 0.4.5 se mantendrá como parte de un ciclo de mantenimiento regular; las actualizaciones se suspenderán 9 meses o 3 meses después del lanzamiento de la rama 0.4.6.x.

Se proporciona un ciclo de soporte largo (LTS) para la rama 0.3.5, cuyas actualizaciones se publicarán hasta el 1 de febrero de 2022. El soporte para las ramas 0.4.0.x, 0.2.9.x, 0.4.2.xy 0.4.3 está descontinuado. La sucursal 0.4.1.x se descontinuará el 20 de mayo y la sucursal 0.4.4 se descontinuará en junio de 2021.

Dentro de las principales novedades de Tor 0.4.5 podremos encontrar que se implementó la capacidad de construir Tor en forma de una biblioteca enlazada estáticamente para incrustarla en aplicaciones.

Además de que la detección de relés compatibles con IPv6 fue significativamente mejorada, ya que en torrc, las direcciones IPv6 están permitidas en la opción Dirección. Los relés se proporcionan con enlace automático a IPv6 para los puertos especificados a través de ORPort, excepto aquellos marcados explícitamente con el indicador IPv4Only.

La accesibilidad de ORPort con IPv6 ahora se rastrea por retransmisión por separado de ORPort con IPv4. Los relés con soporte IPv6, cuando se conectan a otro relé, incluyen direcciones IPv4 e IPv6 en la lista de celdas y seleccionan al azar la que se usará para la conexión.

Además, para los operadores, rayleighs propuso el mecanismo «MetricsPort» para monitorear el desempeño del sitio. El acceso a las estadísticas sobre el funcionamiento del sitio se proporciona a través de la interfaz HTTP. La salida de Prometheus es compatible actualmente.

Se agregó soporte para el sistema de rastreo LTTng y rastreo en el espacio del usuario en el modo USDT (rastreo definido estáticamente en el espacio del usuario), lo que significa crear programas con la inclusión de puntos de control estáticos especiales.

Y se corrigieron problemas de rendimiento con relés que se ejecutan en la plataforma Windows.

Anon-Ticket un sistema de informes anónimo

La otra de las noticias que dieron a conocer los colaboradores de Tor, es que han desarrollado Anon-Ticket, un complemento para la plataforma de desarrollo colaborativo GitLab que permite enviar y discutir problemas de forma anónima sin tener que registrarse para obtener una cuenta.

Anon-Ticket se ha lanzado como un servicio en modo de prueba que permite enviar mensajes sobre problemas en los repositorios de Tor, pero el complemento no está vinculado a Tor y puede usarse en otros proyectos.

A menudo, los usuarios que desean informar a los desarrolladores sobre el problema abandonan sus intenciones, ante la necesidad de completar formularios de registro adicionales, transferir datos personales o esperar la confirmación.

Anon-Ticket permitirá prescindir del registro, que es innecesario al enviar notificaciones únicas, deshacerse de esperar la confirmación de la cuenta por parte del moderador y mantener la confidencialidad de sus datos personales y correo electrónico.

Anon-Ticket permite no solo enviar, sino también rastrear el estado de los tickets completados y publicar aclaraciones, para lo cual el usuario recibe un identificador temporal generado automáticamente y un enlace a una página que se puede marcar para controlar su ticket.

La interfaz también proporciona funciones para ver proyectos existentes y buscar tickets relacionados con el proyecto seleccionado. Se utiliza un mecanismo de moderación de publicaciones para evitar el spam y el abuso.

Los moderadores cuentan con herramientas flexibles para aprobar por lotes o rechazar publicaciones pendientes, así como la capacidad de realizar ediciones y dejar comentarios que solo son visibles para otros moderadores.

Los planes para el futuro mencionan la creación de un servicio onion, agregando mecanismos de protección adicionales, como limitar la intensidad de envío de mensajes, e implementar la posibilidad de transformar un participante anónimo en uno regular (por ejemplo, cuando un usuario decide conectarse por completo al desarrollo, registró una cuenta de GitLab y deseaba transferirle sus antiguas discusiones anónimas).

Finalmente si quieres conocer más al respecto, puedes consultar el siguiente enlace. 

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

Los desarrolladores de la biblioteca SDL (Simple DirectMedia Layer), cuyo objetivo es facilitar la escritura de juegos y aplicaciones multimedia, anunciaron el cambio del sistema de control de fuente Mercurial y el motor de seguimiento de errores Bugzilla a Git y la plataforma GitHub.

Según Ryan C. Gordon, uno de los líderes del proyecto, Mercurial sigue siendo el mejor sistema de control de fuente y Git ha implementado una serie de soluciones arquitectónicas deficientes, pero en el mundo moderno Mercurial se está convirtiendo en un paria y todas las herramientas de desarrollo y los flujos de trabajo están enfocados en Git.

La mayoría de los desarrolladores trabajan con Git y participar en proyectos basados ​​en Mercurial requiere aprender una herramienta adicional.

Después de pasar a Git, los patrocinadores del sistema antiguo pueden usar un subconjunto de comandos de Git para realizar las mismas tareas que hizo Mercurial, pero todos los demás podrán usar una herramienta que sea más conveniente para ellos.

La razón para elegir la plataforma GitHub es la familiaridad con este servicio para la mayoría de los desarrolladores y la capacidad de deshacerse de la carga de mantener el software del servidor.

La desventaja será la pérdida de control sobre la infraestructura, ya que GitHub es un servicio externo controlado por un tercero.

SDL solía dictaminar que toda la infraestructura debe pertenecer al proyecto. Pero con el tiempo, el proyecto dejó de utilizar servidores físicos propios en favor de servidores arrendados a Digital Ocean, lo que permitió no preocuparse por el mantenimiento de los equipos y, en caso de problemas, reiniciar el servicio desde una copia de seguridad de otro proveedor.

El precio de tal libertad fue la necesidad de mantener de forma independiente elementos de infraestructura obsoletos, y no hubo suficiente tiempo y recursos para llevar a cabo la modernización.

Por ejemplo, Bugzilla es más o menos igual que hace 20 años y tiene una montaña de problemas sin resolver y enlaces que causan dolores de cabeza cada vez que se actualiza la distribución. La wiki, las listas de correo y la interfaz web de Mercurial también permanecieron arcaicas.

El mantenimiento de todos estos sistemas requirió mucho trabajo manual y generó preocupaciones sobre la posible presencia de vulnerabilidades en el código de los proyectos semiabandonados utilizados.

Según Ryan, se da cuenta de que pasar a GitHub es una pérdida de control, una trampa y un paso lejos de los principios de la Free Software Foundation, pero ya no tiene la fuerza para escribir código OpenGL para lidiar con el trabajo de un administrador de sistemas que están a punto de reventar, sigue funcionando gracias a los parches de cinta adhesiva y oraciones.

GitHub cuenta con el respaldo de un gran equipo de ingenieros pagos, y si por alguna razón Microsoft desconecta GitHub, esto no solo afectará a SDL y se convertirá en un problema global para todo el ecosistema de código abierto, que puede resolverse con otra migración a un nuevo servicio.

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 le 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.

Finalmente si estás interesado en conocer más al respecto sobre la nota, puedes consultar el anuncio original en el siguiente enlace.

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

Los desarrolladores de Google dieron a conocer hace pocos dias un plan para implementar un mecanismo ejecutar programas no modificados compilados para Linux en el sistema operativo «Fuchsia».

Para ejecutar programas de Linux en el espacio del usuario, se planea proporcionar una capa «starnix» para brindar compatibilidad con la ABI de Linux. En la capa desarrollada, las interfaces del sistema del kernel de Linux se implementan en un controlador que se lanza como un proceso para el sistema operativo Fuchsia, que se ejecuta en el espacio del usuario y traduce las solicitudes de los programas de Linux a las llamadas a los subsistemas Fuchsia correspondientes.

Se observa que durante el desarrollo del proyecto, muchos subsistemas Fuchsia tendrán que ser modificados para implementar todas las interfaces del sistema disponibles en Linux. La arquitectura de starnix es en gran medida la misma que la del subsistema de Windows para Linux que usa Windows para traducir las llamadas al sistema de Linux a las llamadas al sistema de Windows.

Se planea implementar el código starnix en Rust para minimizar los posibles vectores de vulnerabilidades que potencialmente pueden usarse para elevar los privilegios de un proceso de Linux al proceso starnix.

Para garantizar la seguridad en starnix, se utilizarán los mecanismos de protección estándar Fuchsia siempre que sea posible.

Por ejemplo, al acceder a servicios del sistema como el sistema de archivos, la pila de redes o el subsistema de gráficos, starnix solo traducirá las solicitudes, convirtiendo la ABI de Linux en la ABI del sistema Fuchsia, lo que permite las mismas restricciones que se aplican a los procesos Fuchsia habituales.

Esto también implementará mecanismos de autorización específicos de Linux, por ejemplo, definiendo en qué situaciones un proceso de Linux tiene derecho a terminar otro.

Los desarrolladores de Fuchsia han desarrollado soporte para lanzar aplicaciones Linux en el pasado, pero experimentaron con una implementación que funciona por analogía con la forma en que se organiza el lanzamiento de aplicaciones Linux en Chrome OS.

Para la compatibilidad con Linux, Fuchsia ofreció la biblioteca Machina, que permitía ejecutar programas de Linux en una máquina virtual aislada especial formada mediante un hipervisor basado en el kernel de Zircon y las especificaciones de Virtio.

No se descarta el uso de la virtualización, ya que la implementación completa de la interfaz del sistema Linux no es una tarea trivial.

Además de la capa de starnix, es posible crear un mecanismo para ejecutar ejecutables de Linux usando un kernel de Linux que se ejecuta en una máquina virtual separada. Este método se considera el más fácil de implementar, pero también el que consume más recursos.

En un momento, Microsoft comenzó a desarrollar su capa de compatibilidad de Linux a partir del traductor, pero finalmente cambió a usar el kernel nativo de Linux en el Subsistema de Windows para Linux 2.

Además, Fuchsia ya proporciona una capa de compatibilidad POSIX Lite que se ejecuta en la parte superior de Fuchsia System ABI. POSIX Lite le permite ejecutar algunos programas de Linux, pero requiere la recompilación del código de la aplicación y, en algunos casos, la modificación del código fuente.

Uno de los problemas con POSIX Lite es la implementación incompleta de todas las funciones de POSIX, incluidas las llamadas para cambiar el estado global de los procesos (por ejemplo, la función de matar), que están en desacuerdo con los conceptos de seguridad en Fuchsia, que prohíben cambiar el estado global de los procesos. Expresar.

El uso de POSIX Lite se justifica en el proceso de portar aplicaciones abiertas, pero no resuelve problemas con el lanzamiento de programas para los que no hay acceso al código (por ejemplo, es imposible lograr compatibilidad con aplicaciones de Android que contienen inserciones nativas compiladas).

Recordemos que en el marco del proyecto Fuchsia, Google está desarrollando un sistema operativo universal capaz de operar en cualquier tipo de dispositivo, desde estaciones de trabajo y smartphones hasta tecnología embebida y de consumo. El desarrollo se basa en la experiencia de crear la plataforma Android y tiene en cuenta las deficiencias en el campo del escalado y la seguridad.

El sistema se basa en el microkernel Zircon, basado en los desarrollos del proyecto LK, extendido para su uso en varias clases de dispositivos, incluidos teléfonos inteligentes y computadoras personales.

Fuente: https://fuchsia.googlesource.com

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