La batalla de Twitter y Musk continua

Twitter tiene un caso legal sólido contra Elon Musk, quien se alejó de su acuerdo de $44 mil millones para adquirir la compañía, pero podría optar por una renegociación o un acuerdo en lugar de una larga batalla judicial, según fuentes de expertos legales.

El entusiasmo de Musk por seguir adelante con el acuerdo ha estado en duda desde al menos mayo, cuando dijo que el acuerdo estaba «en suspenso» hasta que pudiera verificar si la afirmación de Twitter de que menos del 5% de las cuentas son bots o spam era correcta. Acusó a Twitter de retener información, mientras que la compañía dijo que estaba actuando de buena fe y brindando todo lo que requerían los términos del acuerdo.

Al aumentar las acusaciones sobre el porcentaje de bots y spam en la plataforma, Musk redujo el precio de las acciones de Twitter y estaba tratando de usar esto para obligar a Twitter a renegociar el acuerdo a un precio más bajo.

Ante esto, los expertos mencionan que Twitter tiene una ventaja legal, pues en los tribunales de Delaware, donde se espera que se litigue la disputa entre las dos partes, han puesto el listón muy alto para que los adquirentes puedan abandonar sus acuerdos. Pero las empresas objetivo a menudo eligen la certeza de un acuerdo renegociado a un precio más bajo o una compensación financiera en lugar de una batalla judicial desordenada que puede prolongarse durante meses.

El principal reclamo de Musk contra Twitter es que la empresa rompió su acuerdo porque no compartirá suficiente información con él para respaldar su afirmación de que el spam y las cuentas falsas representan menos del 5% de los usuarios activos de Twitter. Twitter mantuvo esa estimación, pero también dijo que es posible que la cantidad de tales cuentas sea mayor.

Musk también dijo en una carta a Twitter que la tergiversación de la compañía sobre la cantidad de cuentas de spam podría ser un «efecto material adverso (MAE, por sus siglas en inglés )» que le permitiría optar por no participar según los términos del contrato.

Twitter no ha proporcionado la información solicitada por el Musk durante casi dos meses, a pesar de sus reiteradas y detalladas aclaraciones destinadas a simplificar la identificación, recopilación y divulgación de la información más relevante.

Los expertos legales dijeron que los tribunales de Delaware ven las EAW como eventos dramáticos e inesperados que dañan el desempeño de una empresa a largo plazo. Los contratos comerciales como el de Musk y Twitter son tan prescriptivos que un juez dictaminó que una ODE solo se ha activado válidamente una vez en la historia de dicho litigio, en el caso del grupo de atención médica alemana Fresenius Kabi AG que finalizó su acuerdo con el fabricante estadounidense de medicamentos genéricos Akorn en 2018.

En este caso, un tribunal dictaminó que las garantías de Akorn a Fresenius de que cumplía con sus obligaciones reglamentarias eran inexactas. También descubrió que Akorn ocultó hechos sobre su desempeño deteriorado que surgieron en las denuncias de los denunciantes.

Los expertos legales descartaron la idea de que los números de cuenta de spam inexactos equivaldrían a una EAW para Twitter al mismo nivel que los problemas que afectan a Akorn.

Musk también afirmó que Twitter violó su acuerdo al despedir a dos empleados clave de alto rango, su director de productos y su director de consumidores, sin su consentimiento, como lo exige su contrato.

La mayoría de las veces, los tribunales fallan a favor de las empresas objetivo y ordenan a los adquirentes que cierren sus transacciones, un remedio legal conocido como «desempeño específico». Sin embargo, muchas empresas optan por llegar a un acuerdo con sus adquirentes para acabar con la incertidumbre sobre su futuro que puede pesar sobre sus empleados, clientes y proveedores, mientras que otras empresas permiten que los adquirentes se vayan a cambio de una compensación financiera.

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

En GCC aprobaron la implementación de RUST (gccrs)

Hace poco se dio a conocer la noticia de que el Comité Directivo de GCC ha aprobado la inclusión de la implementación gccrs (GCC Rust) del compilador Rust en el núcleo de GCC.

Con ello GCC (GNU Compiler Collection) ya tiene un backend para Rust, mediante el proyecto llamado rustc_codegen_gcc fundado por Antoni Boucher. Todavía se describe como un trabajo en progreso, pero se fusionó con el repositorio principal de Rust en septiembre de 2021.

Para quienes desconocen del lenguaje Rust, deben saber que este se centra en la gestión segura de la memoria y proporciona los medios para lograr un alto paralelismo de trabajos. El manejo seguro de la memoria, que excluye errores como el acceso a un área de memoria después de liberarla, la desreferenciación de punteros nulos y el desbordamiento de los límites del búfer, se logra en Rust en tiempo de compilación a través de la verificación de referencias, el seguimiento de la propiedad del objeto, la contabilidad de la vida útil de los objetos (alcances) y evaluar la corrección del acceso a la memoria durante la ejecución del código.

Rust también brinda protección contra desbordamientos de enteros, requiere que las variables se inicialicen antes de su uso, maneja mejor los errores en la biblioteca estándar, aplica el concepto de referencias y variables inmutables de forma predeterminada.

Después de integrar la interfaz, en GCC estándar se puede usar para compilar programas Rust sin la necesidad de instalar el compilador rustc creado con desarrollos LLVM.

Desde noviembre de 2020, he trabajado a tiempo completo en el front-end de Rust para GCC, gracias a Open Source Security, Inc y Embecosm. Como resultado, estoy escribiendo a esta lista de correo para buscar comentarios de la experiencia colectiva aquí temprano para planificar un camino para subir el front-end en GCC.

La importancia de este proyecto es su importancia para Linux, generalmente construido con GCC, donde los planes para permitir que Rust se use junto con C para el código del kernel, por razones de seguridad de la memoria, avanzan constantemente.

Esto significa que el compilador de Rust, rustc, se puede usar con el backend de GCC, siendo el backend el generador de código que admite más arquitecturas de CPU que LLVM, el compilador de backend habitual de Rust, aunque existen limitaciones, como requerir una versión parcheada de GCC.

La alternativa es tener una cadena de herramientas GCC completa. En enero de 2021, Open Source Security, Inc, creadores de una versión reforzada del kernel de Linux llamada Grsecurity, dijo que financiaría un «esfuerzo de desarrollo público» de una interfaz de GCC para Rust, con el argumento de que se mejoró la seguridad al no tener que mezclar diferentes compiladores.

Desde mi perspectiva como líder en este front-end, actualmente estamos bajo un fuerte desarrollo, así que esto significa una buena cantidad de código rotando todavía, y no veo que esto cambie hasta que podamos compilar con éxito el libcore caja a finales de este año. Aunque me encantaría vernos fusionado en GCC 13, quiero asegurarme de que este proyecto sea un éxito para todos, y esto podría significar retroceder a la próxima ventana de lanzamiento para asegurarme de que esto sea manejable para producir un front-end de calidad para sentarse junto a los demás .

La compañía citó un documento que muestra «cómo la seguridad general de un entorno de ejecución puede reducirse mediante la introducción de código escrito en Rust o en otro lenguaje donde el compilador no proporciona la misma seguridad de nivel binario».

Se alienta a los desarrolladores de gccrs a comenzar a trabajar con los equipos de revisión y lanzamiento de cambios de GCC para finalizar y aprobar parches en términos de cumplir con los requisitos técnicos para el código que se agregará a GCC.

Suponiendo que el desarrollo de gccrs continúe según lo planeado y no se identifiquen problemas imprevistos, el front-end del lenguaje Rust se integrará en el lanzamiento de GCC 13 programado para mayo del próximo año. La implementación de Rust en GCC 13 estará en estado beta, aún no habilitada de forma predeterminada.

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

from Linux Adictos https://ift.tt/8Xdfqav
via IFTTT