El anuncio de la compra de ARM por parte de Nvidia fue hace unos días, en la cual la empresa de diseño de chips con sede en Cambridge y propiedad del SoftBank de Japón fue vendida por 40.000 millones de dólares.

Sin embargo, el cofundador de ARM, Hermann Hauser, dijo que sería un desastre si su rival estadounidense NVIDIA comprara la empresa británica que ayudó a construir. En declaraciones a la BBC el lunes, Hauser dijo: “Creo que esto es un desastre absoluto para Cambridge, el Reino Unido y Europa”.

Y es que ahora que el grupo japonés ha acordado separarse de ARM Ltd., uno de los mayores fabricantes de microprocesadores de arquitectura de 32 bits y arquitectura similar a RISC de 64 bits del mundo, Hauser ha advertido que la operación no es de interés público, advirtiendo que miles de empleados de ARM perderían sus trabajos en Cambridge, Manchester, Belfast y Warwick.

Por lo tanto, advierte en el caso de que NVIDIA decida “inevitablemente” trasladar la sede de ARM a los Estados Unidos y convertir la empresa en una división de NVIDIA.

Hauser publicó una carta abierta al Primer Ministro del Reino Unido, Boris Johnson, y publicó una petición en línea pidiendo ayuda para “Salvar ARM”.

En un segundo punto para oponerse a la adquisición de la empresa, Hauser dijo que NVIDIA “destruiría” el modelo comercial de ARM, que implica otorgar licencias para el diseño del chip a unas 500 empresas más, incluidas a varias que están en competencia directa con el comprador.

NVIDIA aún tiene que comentar sobre las preocupaciones del cofundador de ARM. Sin embargo, durante el fin de semana, la compañía estadounidense dijo que la sede de ARM podría permanecer en Cambridge como parte del acuerdo.

Agregó que creará más puestos de trabajo en el país y construirá una nueva supercomputadora de inteligencia artificial impulsada por NVIDIA, informó CNBC el lunes.

Pero Hauser dijo que los compromisos no tenían sentido si no se podían hacer cumplir legalmente.

El director gerente de SoftBank, Masayoshi Son, dijo que “NVIDIA es el socio perfecto para ARM”.

En cuanto a Simon Segars, CEO de ARM, dijo en un comunicado que

“ARM y NVIDIA comparten la misma visión y pasión de que la computación omnipresente y energéticamente eficiente ayudará a resolver los problemas más comunes, las necesidades urgentes del mundo, desde el cambio climático hasta la atención médica, desde la agricultura hasta la educación”, informó CNBC.

Hermann Hauser recordó en su petición, adquisiciones anteriores de compañías británicas por compañías estadounidenses, por ejemplo, Cadbury comprada por Kraft.

Otro de los ejemplos más notables de adquisiciones en los últimos años es el laboratorio de inteligencia artificial DeepMind, con sede en Londres, que fue adquirido por Google por poco más de 600 millones de dólares. Hoy en día, DeepMind es ampliamente considerado como uno de los líderes mundiales en investigación de IA.

También recordó el dominio de ARM en el sector de los teléfonos inteligentes. La petición del Sr. Hauser también advierte contra GAFAM, la batalla entre Estados Unidos y China, el uso marcial del dominio tecnológico estadounidense por parte del presidente estadounidense. “ARM es la única empresa de tecnología del Reino Unido que queda, con una posición dominante en el campo de los microprocesadores para teléfonos móviles. Tiene una cuota de mercado superior al 95%.

El Reino Unido ha sufrido el dominio tecnológico de Estados Unidos por parte de empresas como Google, Facebook, Amazon, Netflix, Apple y otras”, escribió.

Hauser también se refirió al tema de la “neutralidad” de ARM. “Poder venderle a todo el mundo es una de las doctrinas fundamentales del modelo de negocio de ARM”, dijo a la BBC antes de discutir el caso del actual propietario de ARM, Japanese Softbank. “La ventaja de Softbank es que no es una empresa de fabricación de chips y que

“Si ARM se convierte en una empresa estadounidense, cae bajo las regulaciones del CFIUS (Comité de Inversión Extranjera en los Estados Unidos)”, dijo. “Si cientos de empresas del Reino Unido que incorporan chips ARM en sus productos quieren venderlos o exportarlos a todo el mundo, incluso a China, que es un mercado importante, la decisión de si pueden exportarlos será tomada en la Casa Blanca y no en Downing Street ”, le dijo a la BBC. “Creo que es terrible”.

from Linux Adictos https://ift.tt/32yVjF2
via IFTTT

Se acaba de anunciar la liberación de la nueva version de VMWare Workstation Pro 16, en la cual se añade el soporte para poder trabajar con RHEL 8.2, Debian 10.5, Fedora 32, CentOS 8.2, SLE 15 SP2 GA, FreeBSD 11.4 y ESXi 7.0, además de mejoras para el soporte para USB 3 y otras cosas mas.

Para quienes desconocen de VMware Workstation Pro, deben saber que es un hipervisor alojado que se ejecuta en versiones x64 de los sistemas operativos Windows y Linux. Permite a los usuarios configurar máquinas virtuales (VM) en una sola máquina física y utilizarlas simultáneamente junto con la máquina host.

Cada máquina virtual puede ejecutar su propio sistema operativo, incluidas las versiones de Microsoft Windows, Linux, BSD y MS-DOS.

VMware Workstation admite la conexión de adaptadores de red de host existentes y el uso compartido de unidades de disco físico y dispositivos USB con una máquina virtual. Puede simular unidades de disco; un archivo de imagen ISO se puede montar como una unidad de disco óptico virtual y las unidades de disco duro virtual se implementan como archivos .vmdk.

VMware Workstation Pro puede guardar el estado de una máquina virtual (una “instantánea”) en cualquier instante. Estas instantáneas se pueden restaurar más tarde, devolviendo efectivamente la máquina virtual al estado guardado, tal como estaba y libre de cualquier daño posterior a la instantánea en la máquina virtual.

Principales novedades de VMWare Workstation Pro 16

En esta nueva version se han realizado algunos cambios significativos, uno de ellos es el soporte agregado para nuevos sistemas operativos invitados: RHEL 8.2, Debian 10.5, Fedora 32, CentOS 8.2, SLE 15 SP2 GA, FreeBSD 11.4 y ESXi 7.0

Para invitados Windows 7 y superior y Linux con controlador vmwgfx, DirectX 11 y OpenGL 4.1 ahora son compatibles, con las siguientes restricciones: los hosts Windows requieren compatibilidad con DirectX 11, los hosts Linux requieren controladores binarios NVIDIA con OpenGL 4.5 y compatibilidad superior.

Para los sistemas operativos host Linux con controladores Intel/Vulkan, DirectX 10.1 y OpenGL 3.3 ahora son compatibles.

Además de que se mejoró la velocidad de transferencia de archivos entre el huésped y el host, se redujo el tiempo de apagado del huésped, se mejoró el rendimiento en las unidades NVMe.

De los demás cambios que se destacan de esta nueva version:

• El subsistema de gráficos se ha aislado para mejorar la seguridad.
• El controlador virtual USB 3 ahora admite tasas de cambio de hasta 10 Gbit / seg.
• Capacidades extendidas para SO invitado: hasta 32 núcleos virtuales, hasta 128 GB de memoria virtual, hasta 8 GB de memoria de video.
• Soporte agregado para vSphere 7.0.
• Se agregó un tema oscuro.
• Soporte eliminado para VM compartida y VM restringida
• Errores de seguridad corregidos: CVE-2020-3986, CVE-2020-3987, CVE-2020-3988, CVE-2020-3989 y CVE-2020-3990.

Finalmente si estás interesado en conocer mas al respecto sobre esta nueva version VMWare, puedes consultar los detalles en el siguiente enlace.

¿Como instalar esta nueva version de VMWare Workstation Pro 16 en Linux?

Para los que estén interesados en poder realizar la instalación de esta nueva version de VMware, deben saber que el proceso es bastante sencillo.

Lo único que deben hacer es obtener el paquete de instalación desde su sitio web oficial, este lo podemos obtener a través de este enlace donde encontraremos el paquete para Windows y para Gnu/Linux.

Aquí, solo tenemos que descargar el paquete para la versión de Linux así como el paquete correspondiente a nuestra plataforma, es decir, el paquete de 64 bits o el paquetes de 32 bits.

Una vez que hemos descargado el paquete de instalación, abrimos una terminal y nos situamos en la carpeta donde está ese paquete de instalación. Estando ahí, escribimos lo siguiente:

chmod a+x VMware-Workstation-Full-16.0.0-16894299.x86_64.bundle

sudo ./VMware-Workstation-Full-16.0.0-16894299.x86_64.bundle

Tras esto se abrirá un asistente visual de instalación.

Este asistente está en inglés pero su funcionamiento es similar a los asistentes de Windows donde el botón Next es lo más habitual en estas instalaciones.

Una vez que hemos terminado con el asistente, VMware se instalará en las cabeceras del kernel y estará listo para funcionar.

Ahora, cada vez que queramos ejecutar VMware solo hemos de ir a nuestro menú y ejecutarlo.

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

Hace poco se dio a conocer otro problema en el subsistema AF_PACKET del kernel de Linux, que permite a un usuario local sin privilegios ejecutar código como root o salir de contenedores aislados si tienen acceso de root.

La información dada a conocer menciona que se requiere autoridad CAP_NET_RAW para crear el socket AF_PACKET y explotar la vulnerabilidad.

Sin embargo, se señala que un usuario sin privilegios puede obtener el permiso especificado en contenedores creados en sistemas con espacios de nombres de usuario habilitados.

Por ejemplo, los espacios de nombres de usuario se incluyen de forma predeterminada en Ubuntu y Fedora, pero no se activan en Debian y RHEL. Mientras que en Android, el proceso mediaserver tiene derecho a crear sockets AF_PACKET, a través de los cuales se puede aprovechar la vulnerabilidad.

Sobre la vulnerabilidad en AF_PACKET

La vulnerabilidad está presente en la función tpacket_rcv y es causada por un error en el cálculo de la variable netoff.

Un atacante puede crear condiciones bajo las cuales se escribirá un valor menor que maclen en la variable netoff, lo que provocará un desbordamiento al calcular “macoff=netoff-maclen” y luego con ello podra configurar incorrectamente el puntero al búfer para los datos entrantes.

Como resultado, un atacante puede iniciar la escritura de 1 a 10 bytes en un área fuera del búfer asignado. 

El error de cálculo ha estado presente en el kernel desde julio de 2008, es decir, en todos los núcleos actuales, sin embargo, la capacidad ahora conocida de usarlo para escribir en un área fuera del búfer asignado (vulnerabilidad) se introdujo presumiblemente en febrero de 2016 (desde versiones del kernel 4.6-rc1 y posteriores), con el desarrollo del soporte virtio_net.

En cuanto a la solución del problema todavía está disponible como parche. Además de que por la parte contraria se observa que se está desarrollando un exploit que permite obtener derechos de root en el sistema.

Para los que están interesados en saber si ya se encuentra disponible la corrección para su distribución, pueden rastrear la aparición de las actualizaciones de paquetes en las diferentes distribuciones en las siguientes páginas: Ubuntu, Fedora, SUSE, Debian, RHEL, Arch.

La compatibilidad con el desplazamiento de texto de la consola de texto fue eliminada

Por otra parte hablando del Kernel de Linux, también se dio a conocer que se eliminó el código de desplazamiento de texto de la implementación de la consola de texto en el kernel de Linux (CONFIG_VGACON_SOFT_SCROLLBACK).

El código se eliminó debido a la presencia de errores, que no hubo nadie para corregir debido a la falta de un encargado que supervisara el desarrollo de vgacon.

Y es que hace unos meses se identificó y solucionó una vulnerabilidad en vgacon (CVE-2020-14331) que podría provocar un desbordamiento del búfer debido a la falta de comprobaciones adecuadas de la disponibilidad de memoria en el búfer de desplazamiento. La vulnerabilidad atrajo la atención de los desarrolladores que organizaron pruebas fuzzing del código vgacon en syzbot.

Además de que en verificaciones adicionales se revelaron varios problemas más similares en el código vgacon, así como problemas en la implementación del software del desplazamiento en el controlador fbcon.

Desafortunadamente, el código problemático se ha dejado desatendido durante mucho tiempo, presumiblemente debido al hecho de que los desarrolladores cambiaron al uso de consolas gráficas y las consolas de texto dejaron de usarse (la gente continúa usando las consolas vgacon y fbcon, pero no han sido la interfaz principal del kernel durante décadas y se extendió tanto las funciones como el desplazamiento integrado en el controlador (Mayús + RePág / RePág) probablemente tienen poca demanda).

En este sentido, Linus Torvalds decidió no intentar mantener el código no reclamado, sino simplemente eliminarlo.

Finalmente, se menciona que si hay usuarios que necesitan esta funcionalidad, el código para soportar el desplazamiento en la consola será devuelto al kernel tan pronto como haya un mantenedor listo o que quiera hacerse cargo para tomar su mantenimiento en sus propias manos, es decir sea el único en querer destinar tiempo a ello.

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

Hace poco los desarrolladores que están a cargo de del sistema de administración de paquetes Portage (en la distribución de Gentoo Linux) dieron a conocer el lanzamiento de la version estable de la version 3.0.

En la cual, la principal novedad de esta nueva rama presentada, es el trabajo que se realizó a largo plazo sobre la transición a Python 3 y el final del soporte para Python 2.7 (algo que ya se veía venir desde hace mucho tiempo, ya que esta rama quedo oficialmente sin soporte desde hace ya varios meses)

¡Tenemos buenas noticias! El proyecto Portage de Gentoo ha estabilizado recientemente la versión 3.0 del administrador de paquetes.

¿Qué hay de nuevo? Bueno, esta tercera versión de Portage elimina el soporte para Python 2.7, que ha sido un esfuerzo continuo en el repositorio principal de Gentoo por parte del proyecto Python de Gentoo durante el año 2020.

Además de la descontinuación del soporte para Python 2.7, otro cambio importante que se destaca de esta nueva rama estable de Portage 3.0 fue la inclusión de  diversas optimizaciones que permitieron hacer que los cálculos sean mucho mas rápidos (entre un 50% y 60%) asociados con la determinación de dependencias.

Curiosamente, algunos desarrolladores sugirieron reescribir el código de resolución de dependencias en C/C ++ o Go para acelerar su trabajo, pero lograron resolver el problema existente con un gran esfuerzo.

Y es que el perfil del código existente mostró que la mayor parte del tiempo de cálculo se dedica a llamar a las funciones use_reduce y catpkgsplit con un conjunto repetido de argumentos (la persona que llevo este labor menciona que por ejemplo, la función catpkgsplit se llamó de 1 a 5 millones de veces).

Con el problema detectado, menciona que para acelerar los cálculos, se aplicó el almacenamiento en caché del resultado de estas funciones mediante diccionarios.

Además, debido a un parche proporcionado por el usuario, la actualización a la última versión de Portage puede acelerar enormemente los cálculos de dependencia entre un 50 y un 60%. ¡Nos encanta ver a nuestra comunidad participar en nuestro software! Para obtener más detalles, consulte esta publicación de Reddit del miembro de la comunidad que proporcionó el parche. ¡Manténgase saludable y siga cocinando con Gentoo!

Además de que también señala que la función incorporada lru_cache era óptima para esta labor de almacenar el caché, pero que solo estaba disponible en las versiones de Python desde 3.2.

Para compatibilidad con versiones anteriores, tambien se agregó un código auxiliar para reemplazar lru_cache, pero la decisión de finalizar el soporte de Python 2.7 en Portage 3.0 simplificó enormemente la tarea y permitió poder prescindir de esta capa.

Dediqué un tiempo a perfilar Portage con cProfile y vmprof para comprender qué funciones tomaban más tiempo. También generé algunos flamegraphs a partir de los resultados del generador de perfiles, que se veían así . Lo que noté fue que algunas funciones, como use_reducey catpkgsplit, se llaman con mucha frecuencia con los mismos argumentos (como, 1 a 5 millones de veces, para catpkgsplit). Hice algunos experimentos para almacenar en caché los resultados de estas funciones en un dictado, y después de ver algunas buenas aceleraciones, envié un parche a la lista de desarrolladores de Portage. Alguien sugirió usar Python incorporadolru_cache decorador de funciones en su lugar, pero eso solo está disponible en Python 3.2 y superior.

Por otro lado el uso de la caché ha reducido la operación “emerge -uDvpU –with-bdeps = y @world” en el ThinkPad X220 de 5 minutos 20 segundos a 3 minutos 16 segundos (63%). Las pruebas en otros sistemas han demostrado una ganancia de rendimiento de al menos un 48%.

El desarrollador que preparó el cambio también intentó implementar un prototipo del código de resolución de dependencias en C ++ o Rust, pero la tarea resultó ser demasiado difícil, ya que requería portar una gran cantidad de código y, al mismo tiempo, era dudoso que el resultado valiera la pena el esfuerzo.

Finalmente si quieres conocer mas al respecto sobre la nota de la liberación de esta rama estable, puedes consultar los detalles en el siguiente enlace.

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

En nuestro artículo anterior habíamos comenzado a contar la historia de los laboratorios Bell, la organización de la cuál salieron muchas de las innovaciones tecnológicas del siglo XX. Entre ellas Unix, el sistema operativo que inspiraría a Richard Stallman y Linus Torvalds.

Dejamos esta historia con Theodore Vail, presidente de AT&T y su proyecto de crear un servicio telefónico universal. (Entendiendo como tal al universo de usuarios telefónicos de Estados Unidos)

El gran obstáculo a vencer para lograr un servicio universal era la distancia. La tecnología de entonces solo permitía transmitir voz humana durante un trayecto de 1700 millas antes de que la señal se distorsionara o perdiera intensidad.

Si quería establecer un servicio telefónico transcontinental entre Nueva York y San Francisco, La AT&T no solo debía solucionar el problema de la intensidad y la distorsión de la señal. Se hacía necesario desarrollar un cable que pudiera tenderse a través de montañas y desiertos y soportar las dificultades climáticas.

Los ejecutivos de la empresa decidieron hacer algo novedoso para la época, pedirle ayuda a los científicos. La firma reclutó a algunos estudiantes de doctorado en Física de la Universidad de Chicago para su laboratorio en Nueva York.

Uno de ellos lograría resolver el problema.

El nacimiento de los laboratorios Bell

En 1921 el Congreso excluye a los servicios telefónicos de las leyes antimonopolio permitiendo que los planes de concentración de Vail se lleven a cabo. En 1924 la firma fusiona todos sus departamentos de ingeniería y crea una empresa independiente llamada Bell Telephone Laboratories, Inc.

Los laboratorios investigarían y desarrollarían nuevos equipos para Western Electric (la subsidiaria encargada de la producción de equipos telefónicos), y llevarían a cabo la planificación de conmutación y transmisión e inventarían dispositivos relacionados con las comunicaciones para AT&T. Estas organizaciones financiarían el trabajo de los Laboratorios Bell.

De los dos mil especialistas contratados, la gran mayoría trabajaba en el desarrollo de productos. Cerca de trescientos, sin embargo, se dedicaban a la investigación básica y aplicada. Esto último incluía los campos de la química física y orgánica, de la metalurgia, del magnetismo, de la conducción eléctrica, de la radiación, de la electrónica, de la acústica, de la fonética, de la óptica, de las matemáticas, de la mecánica, e incluso de la fisiología, de la psicología y de la meteorología. Tampoco se descartaba cualquier cosa relacionada remotamente con las comunicaciones humanas, ya fuera a través de cables o radio o imágenes de sonido o visuales grabadas.

Como dije en el artículo anterior, mi intención no es solo en detallar los acontecimientos que llevaron al desarrollo de UNIX, también quiero hablar de la cultura que generó esas innovaciones. Una cultura que daría después buenos resultados en la creación de Internet y del movimiento del software libre. Por lo tanto, vamos a detenernos para describir un poco el ambiente de trabajo.

El trabajo dentro de los laboratorios se llevaba a cabo en habitaciones amplias y abiertas con suelo de madera y divididas por pilares de piedra que soportaban el peso del techo. En total se ocupaba una superficie de más de ciento veintiún mil metros cuadrados. Esto sin incluir la azotea que se usaba para probar cómo varias pinturas, coberturas y metales resistían los elementos.
Mientras que algunas salas del edificio se dedicaban al diseño de nuevos dispositivos, el edifico también incluía laboratorios de pruebas para teléfonos, cables, interruptores, cordones, bobinas y otros muchos tipos de componentes. Había laboratorios químicos para examinar las propiedades de los nuevos materiales que pudieran utilizarse para producir aleaciones para el alambre y el revestimiento de los cables, mientras que en otras partes del edifico se probaban los efectos de las corrientes eléctricas y las combinaciones de conmutación y se investigaban nuevos patrones de circuitos. También se tenía en cuenta el desarrollo de la transmisión inalámbrica.

Juntando científicos e ingenieros

Los laboratorios Bell fueron de los primeros en integrar ciencia básica con ingeniería. Es interesante como se produjo la convivencia.

Según cuentan los cronistas, no había una verdadera distinción entre el rol de los ingenieros y los científicos. Todos estaban unidos por el objetivo de lograr las pequeñas mejoras necesarias para mejorar el servicio telefónico y lograr llevarlo a todo el país.

Esto no significaba que se descuidara la investigación básica. Los responsables del laboratorio querían que algunos de los jóvenes científicos que habían contratado se desentendieran de los problemas cotidianos y se centraran en aprender como las leyes fundamentales y los nuevos descubrimientos de la física y la química podrían afectar en un futuro a las comunicaciones. Los integrantes de este grupo podían elegir que investigar.

En el próximo artículo vamos a hablar de la primera contribución de los laboratorios Bell a la industria informática.

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