Llega la novena versión de Rust para Linux y dice adiós al soporte para versiones anteriores a Linux 3.2

Vaya que el trabajo del soporte de los controladores Rust para Linux ya se ha encaminado y ha comenzado un desarrollo bastante continuo, pues no tiene mucho que fue anunciada la versión 8 de los parches y ya ahorita tenemos la versión  9.

Y es que en esta novena versión que se ha propuesto, cabe mencionar que como tal es una versión simplificada de la octava edición publicada hace unos días. El kit se distingue por una importante reducción de tamaño y por dejar solo el mínimo más necesario, suficiente para construir un módulo kernel escrito en Rust.

Se supone que el parche mínimo facilitará la adopción del soporte de Rust en el núcleo principal. Después de brindar un soporte mínimo, se planea aumentar gradualmente la funcionalidad existente, transfiriendo otros cambios de la rama Rust-for-Linux.

Esta es la serie de parches (v9) para agregar soporte para Rust como segundo lenguaje al kernel de Linux…

Como de costumbre, un agradecimiento especial para ISRG (Grupo de Investigación de Seguridad en Internet) y Google por su apoyo financiero en este esfuerzo.

En comparación con la versión 8, el tamaño del parche se ha reducido de 40 000 a 13 000 líneas de código. Por ejemplo, la novena versión incluye solo el 3 % del código (500 líneas) del paquete de cajas «kernel» y el 60 % de la biblioteca alloc, lo que le permite crear los módulos de kernel más simples usando el tipo Vec<i32> y mostrando información en el registro del kernel usando la macro «pr_info!».

Por otra parte, en relación con Rust y Linux, vale mencionar que hace poco los desarrolladores del proyecto Rust advirtieron a los usuarios sobre el aumento inminente de los requisitos para el entorno Linux en el compilador, el administrador de paquetes Cargo y la biblioteca estándar libstd.

A partir de Rust 1.64, programado para el 22 de septiembre de 2022, los requisitos mínimos para Glibc se elevarán de la versión 2.11 a la 2.17 y el kernel de Linux de la 2.6.32 a la 3.2. Las restricciones también se aplican a los binarios de Rust creados con libstd.

Las distribuciones RHEL 7, SLES 12-SP5, Debian 8 y Ubuntu 14.04 cumplen con los nuevos requisitos. Se interrumpirá la compatibilidad con RHEL 6, SLES 11-SP4, Debian 7 y Ubuntu 12.04. Entre las razones para desaprobar el soporte para sistemas Linux más antiguos se encuentran los recursos limitados para continuar manteniendo la compatibilidad con entornos más antiguos.

¿Por qué aumentar los requisitos?
Queremos que Rust y los archivos binarios producidos por Rust sean lo más ampliamente utilizables posible. Al mismo tiempo, el proyecto Rust solo tiene recursos limitados para mantener la compatibilidad con entornos antiguos.

Hay dos partes en los requisitos de la cadena de herramientas: los requisitos mínimos para ejecutar el compilador de Rust en un sistema host y los requisitos mínimos para los binarios compilados de forma cruzada.

Los requisitos mínimos para las cadenas de herramientas del host afectan a nuestro sistema de compilación. Rust CI produce artefactos binarios para docenas de objetivos diferentes. La creación de archivos binarios que admitan versiones antiguas de glibc requiere la creación de un sistema operativo con glibc antiguo (para compilaciones nativas) o el uso de una raíz de compilación con una versión anterior de glibc (para compilaciones cruzadas).

En particular, la compatibilidad con Glibcs ​​anteriores requiere el uso de herramientas más antiguas cuando se verifica en un sistema de integración continua, frente a los mayores requisitos de versiones en LLVM y las utilidades de compilación cruzada. El aumento en los requisitos de la versión del kernel se debe a la capacidad de libstd para usar nuevas llamadas al sistema sin necesidad de mantener capas para garantizar la compatibilidad con kernels más antiguos.

Se recomienda a los usuarios que usan ejecutables creados por Rust en entornos con kernels de Linux más antiguos que actualicen sus sistemas, permanezcan en versiones anteriores del compilador o mantengan su propia bifurcación libstd con capas para mantener la compatibilidad.

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/ueR9BKn
via IFTTT

Kali Linux 2022.3 llega con imágenes nativas de VirtualBox, nuevas herramientas y su chat principal se pasa a Discord

Kali Linux 2022.3

Los tiempos cambian, y hay que renovarse o morir. Pero todo tiene muchos frentes que cubrir, y es difícil estar a la última en todo. Hace unos instantes se ha hecho oficial el lanzamiento de Kali Linux 2022.3, y se van renovando en cuanto a software, pero una de las novedades que han mencionado no tiene que ver con el sistema operativo en sí, sino en donde se va a reunir más su comunidad. Algunos eligen Telegram porque es una buena aplicación de mensajería que usamos muchos, pero Offensive Security se ha decantado por otra opción.

Ya está disponible el canal de Discord Kali Linux and Friends. Lo han elegido principalmente por su popularidad, porque hay mucha gente que ya lo usaba. Han valorado la posibilidad de pasarse a Matrix, pero la base de usuarios no es tan alta. Discord tiene todo lo que buscan, e incluso harán una charla de una hora tras cada lanzamiento de Kali Linux. La primera será el próximo martes.

Novedades de Kali Linux 2022.3

En cuanto a las novedades que han llegado junto a Kali Linux 2022.3, que llega casi tres meses después que 2022.2, destaca:

  • Nuevo entorno de pruebas llamado Test Lab Environment.
  • Se han lanzado nuevas imágenes para máquinas virtuales, más concretamente las VDI y un archivo .vbox (formato nativo de VirtualBox). Las imágenes tienen un mejor ratio de compresión que las OVA. Además, han empezado a lanzar imágenes semanales de sus imágenes para máquinas virtuales. Están basadas en la rama Rolling.
  • Nueva imagen de inicio de sesión para los que usan Xrdp.
  • Corregida una confusión entre fuse y fuse3.
  • Han realizado algo de mantenimiento en el repositorio de redes.
  • Nuevas herramientas:
    • BruteShark – Herramienta de análisis de redes.
    • DefectDojo – Herramienta de código abierto de correlación de vulnerabilidad de aplicaciones y orquestación de seguridad.
    • phpsploit – Marco de trabajo de post-explotación sigiloso.
    • shellfire – Explotación de vulnerabilidades LFI/RFI y de inyección de comandos.
    • SprayingToolkit – Ataques de pulverización de contraseñas contra Lync/S4B, OWA y O365.
  • Actualizaciones en NetHunter.
  • Actualizaciones en Kali ARM:
    • Todos los dispositivos Raspberry Pi han tenido su kernel actualizado a 5.15.
    • Creado arm.kali.org para tener una visión general y estadísticas para kali-arm (muy similar a nethunter.kali.org).
    • Cada dispositivo Kali ARM ha tenido su tamaño por defecto para la partición de arranque establecido en 256 MB.
    • Se han eliminado los modos de reposo rotos de Pinebook, por lo que ya no debería entrar en reposo y ser incapaz de despertarse.
    • USBArmory MKII se ha movido a la versión 2022.04 u-boot.

Los usuarios interesados ya pueden desacargar Kali Linux 2022.3 desde este enlace.

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

Una vulnerabilidad en io_uring permitía que un usuario sin permisos se convierta en root incluso en contenedores

Hace poco se dio a conocer información de la vulnerabilidad (CVE-2022-29582) en la implementación de la interfaz de E/S asíncrona io_uring, incluida en el kernel de Linux desde la versión 5.1, que permite que un usuario sin privilegios se convierta en root en el sistema, incluso cuando ejecuta un exploit de un contenedor.

Cabe mencionar que dicha vulnerabilidad se informó hace poco más de 3 meses (aproximadamente a principios de mayo de este año), pero la información completa y divulgación se dio a conocer recientemente.

Sobre la vulnerabilidad se menciona que esta se produce al acceder a un bloque de memoria ya liberado, se manifiesta en los kernels de Linux a partir de la rama 5.10.

Sobre la vulnerabilidad CVE-2022-29582

Esta vulnerabilidad permite poder accede a la memoria liberada como resultado de una condición de carrera cuando se manejan tiempos de espera en la función io_flush_timeouts(), que elimina la entrada de tiempo de espera de la lista y la cancela, sin verificar la creación y eliminación del tiempo de espera en ese punto.

Una descripción general y actualizada de io_uring ya ha sido proporcionada por otros. Lo explican mil veces mejor que nosotros, por lo que solo cubriremos el subsistema de manera más amplia (consulte este artículo de Grapl Security y este artículo de Flatt Security para obtener una excelente introducción).

Lo que es más importante, el campo opcode determina qué tipo de operación realizar. Para que cada que»opcode» lo requiera, el campo fd especifica el descriptor de archivo en el que realizar la E/S solicitada. Casi todas las llamadas al sistema de E/S normales ( read, sendto, etc.) tienen un código de operación asíncrono equivalente. Cada campo puede asumir diferentes roles dependiendo de la operación.

Una vez recuperado del SQ, un SQE se convierte en una representación interna descrita por struct io_kiocb( kernel input/output call back). Estos objetos se conocen comúnmente como solicitudes.

struct io_kiocb utiliza como un equivalente a «ready-for-launch» del SQE en el que se basa, con lo que cualquier descriptor de archivo se resuelve en struct file*s, se adjuntan las credenciales del usuario, se adjunta la personalidad (en qué núcleos se ejecutará), etc.

Una vez finalizada la operación solicitada, se escribe en la cola de finalización (CQ) una entrada que corresponde al SQE. Dicha entrada se denomina entrada de cola de finalización (CQE) y contiene campos como un código de error y un valor de resultado. La aplicación del espacio de usuario puede sondear el CQ en busca de nuevas entradas para determinar si los SQE enviados han terminado de procesarse y cuál fue su resultado.

Se mencionan que existen algunos escenarios sobre los cuales es fácil reemplazar un objeto sobre la marcha. Pero existen dos limitantes :

  • LT’ tiene que ser asignado e inicializado en una ventana de carrera. Es decir, después de que el LT se libera pero antes de llegar a un punto en el LT que ya no se accede.
  • LT’ sólo puede ser otro objeto objeto struct io_kiocb. Debido al aislamiento del montón, donde los objetos del montón se separan según su tipo, es demasiado difícil reasignarlos como un tipo diferente de objeto dentro de la ventana de carrera.

Los investigadores han preparado un exploit funcional que no requiere la inclusión de espacios de nombres de identificadores de usuario (espacios de nombres de usuario) para su funcionamiento y puede proporcionar acceso de raíz al sistema principal cuando un usuario sin privilegios inicia el exploit en un contenedor aislado.

Nuestro exploit apunta a la versión del kernel 5.10.90, la versión que Google estaba ejecutando de forma remota en ese momento. Tuvimos que ajustar nuestro exploit a las especificaciones particulares del servidor (4 núcleos Skylake Xeon @ 2.80Ghz, 16GiB RAM), pero con algunos ajustes, cualquier máquina que ejecute un kernel vulnerable debería ser explotable

El exploit también funciona en el entorno nsjail aislado en la distribución Google COS (Container Optimized OS) basada en Chromium OS y utilizada en Google Cloud Platform en máquinas virtuales Compute Engine. El exploit está diseñado para funcionar con ramas del kernel de 5.10 a 5.12. Por ultimo vale mencionar que el problema solucionó en abril en las actualizaciones 5.10.111, 5.15.34 y 5.17.3.

Finalmente si estás interesado en poder conocer más al respecto sobre la vulnerabilidad, puedes consultar la publicación realizada en el siguiente enlace.

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

Rescuezilla 2.4 ya fue liberado y estas son sus novedades

Se dio a conocer el lanzamiento de la nueva versión de la distribucion para el respaldo, recuperación del sistema después de fallas y diagnóstico de varios problemas de hardware«Rescuezilla 2.4».

Rescuezilla está diseñada a partir de la base del paquete de Ubuntu y continúa el desarrollo del proyecto «Redo Backup & Rescue», cuyo desarrollo se interrumpió en 2012.

Rescuezilla admite la copia de seguridad y la recuperación de archivos eliminados accidentalmente en particiones de Linux, macOS y Windows. Busca y monta automáticamente particiones de red que se pueden usar para alojar copias de seguridad. La GUI se basa en el shell LXDE.

De las características que se destacan, podremos encontrar:

  • Entorno gráfico simple que cualquiera puede usar
  • Crea imágenes de respaldo que son totalmente interoperables con el estándar de la industria Clonezilla
  • Admite imágenes creadas por todas las interfaces de imágenes de código abierto conocidas, incluido Clonezilla (consulte la sección «compatibilidad» de la página de descarga)
  • También admite imágenes de máquinas virtuales: VirtualBox (VDI), VMWare (VMDK), Hyper-V (VHDx), Qemu (QCOW2), raw (.dd, .img) y muchas más
  • Acceda a archivos desde imágenes (incluidas imágenes de máquinas virtuales) utilizando ‘Image Explorer (beta)’
  • Totalmente compatible con entornos avanzados como Linux md RAID, LVM y sin tabla de particiones (sistema de archivos directamente en el disco)
  • Admite la clonación (para el modo directo de «dispositivo a dispositivo» sin necesidad de una tercera unidad para almacenamiento temporal)
  • Arranca desde una memoria USB Live en cualquier PC o Mac
  • Copia de seguridad completa del sistema, recuperación completa, edición de particiones, protección de datos, navegación web y más
  • Herramientas adicionales para la partición del disco duro, restablecimiento de fábrica, recuperación de archivos
  • Navegador web para descargar controladores, leer documentación

Principales novedades de Rescuezilla 2.4

En esta nueva versión que se presenta de Rescuezilla 2.4 se destaca que se ha realizado un cambió a la base, pues anteriormente se estaba usando Ubuntu 21.10, pero por temas de compatibilidad se decidió regresar a Ubuntu 22.04.

Otro de los cambios que se destaca de esta nueva versión es que la utilidad partclone se ha actualizado a la versión 0.3.20, esto corrige el error de «característica no admitida» para los usuarios de sistemas de archivos BTRFS comprimidos (como Fedora Workstation 33 y posteriores). Se eliminó el antiguo partclone 0.2.43 utilizado para maximizar la compatibilidad heredada de Redo Backup (el partclone moderno aún brinda una buena compatibilidad con versiones anteriores)

Ademas de ello, tambien se destacan las mejoras de soporte para particiones Btrfs con compresión habilitada, asi como tambien que se ha proporcionado la capacidad de comprimir imágenes utilizando la utilidad bzip2 y que se agregó la capacidad de configurar un puerto de red diferente para SSH.

Por otra parte, se destaca que se corrigió la ejecución del script Clonezilla EFI NVRAM para manejar mejor el reinicio en los sistemas EFI.

Se cambió Firefox para usar el repositorio PPA del equipo de Mozilla, porque el nuevo paquete «snap» es incompatible con los scripts de compilación de Rescuezilla

Se movió la acción posterior a la finalización a la página en progreso y se actualizaron muchas traducciones existentes, pero también se agregaron: Árabe, Catalán, Checo, Húngaro y Eslovaco.

En cuanto a los errores conocidos en esta nueva versión:

  • Al hacer una copia de seguridad de una unidad de Windows, algunos usuarios informan el error «Windows está en hibernación, se negó a montar» o «Error: sistema de archivos de solo lectura» y una copia de seguridad fallida. Esto generalmente se debe a la función de hibernación de Windows, con una solución ampliamente utilizada para seleccionar ‘Reiniciar’ (no apagar) desde el menú de inicio de Windows antes de iniciar la memoria USB de Rescuezilla. Pero algunos usuarios informan que incluso después de hacer un reinicio completo, el problema ahora persiste, con la única solución para que estos usuarios deshabiliten la hibernación por completo (lo que definitivamente no es una buena solución).

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

Descargar y obtener Rescuezilla 2.4

Para quienes estén interesados en poder obtener esta nueva versión, deben saber que se ofrecen para descargar compilaciones en vivo para sistemas x86 de 64 bits (1 GB) y un paquete deb para la instalación en Ubuntu.

La imagen ISO la pueden obtener desde el siguiente enlace.

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

Cómo hacer que Chrome y otros navegadores basados en Chromium nos permitan ver el contenido del modo oscuro en Linux

Modo oscuo en las páginas de Chrome en Linux

Cuando he tenido que usar Chrome en Windows o macOS, ver el contenido en su modo oscuro no me ha resultado ningún problema. Sin embargo, en Linux sí. A mí, que me gustan poco los temas claros, siempre me ha resultado extraño, por ejemplo, abrir las herramientas del desarrollador y ver una parte oscura y otra, la del código, en blanco. Es algo que no me ha pasado en Windows, y hay una manera de conseguirlo en Linux.

Esto funciona para navegadores basados en Chromium que no ofrezcan una opción por sí mismos, como Brave. El navegador «valiente» lo cambia todo a oscuro si elegimos su tema oscuro, pero no es así en Chrome ni en Vivaldi. Si se puede conseguir de la misma manera en ambos casos, donde hacerlo está a un minuto de distancia. Y el modo oscuro que conseguiremos no será nada forzado, por lo que merece la pena.

Modo oscuro en Chrome/Chromium y derivados

Si tu distribución y tu navegador no te permite ver las páginas como en la imagen de cabecera, sólo tienes que abrir un terminal y escribir:

sudo gedit /usr/share/applications/google-chrome.desktop

Dentro, buscamos google-chrome-stable y cambiamos las líneas que tienen Exec=/usr/bin/google-chrome-stable %U y Exec=/usr/bin/google-chrome-stable añadiéndoles --enable-features=WebUIDarkMode --force-dark-mode al final. En el caso de Vivaldi, el archivo a modificar es vivaldi-stable.desktop y la línea a la que se le añaden las opciones es Exec=/usr/bin/vivaldi-stable %U. Deberían quedar como Exec=/usr/bin/google-chrome %U --enable-features=WebUIDarkMode --force-dark-mode, cambiando el ejecutable dependiendo del navegador que estemos usando. Y para que quede todo consistente, luego hay que instalar y activar un tema oscuro como este.

Lo malo de este método, que nos permite ver las páginas oscuras como debería ser sin forzar nada, es que deja de funcionar cada vez que se actualiza el navegador y vuelve a crear un nuevo archivo .desktop. Esto de que no cambie el tema con el del sistema operativo es un bug conocido, pero no lo han solucionado en años. Mientras tanto, podemos verlo todo con este pequeño truco.

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

Cómo actualizar a Linux Mint 21 «Vanesa»

Actualiza a Linux Mint 21Linux Mint 21 se lanzó el ultimo fin de semana de julio, hace poco más de una semana, y Clem Lefebvre, el líder del proyecto, ya adelantó que pronto publicaría la información explicando las instrucciones para actualizar desde 20.3 de la mejor manera. Y ya lo ha hecho. Y no, para el que haya abandonado Ubuntu por sus últimos movimientos polémicos, no es exactamente igual. Pero bueno, las instrucciones existen para facilitar las cosas.

Lo primero que hay que hacer es instalar un paquete: mintupgrade. Es el software que analizará qué versión estamos usando y, si es compatible, nos ofrecerá la posibilidad de instalar Linux Mint 21 Vanessa. Además, es un asistente o «wizard», por lo que el resto de la instalación es todo un camino adelante. Vamos a explicar los pasos a seguir para actualizar desde Una.

Actualizar a Linux Mint 21

  1. Lo primero que hay que hacer es instalar el asistente, por lo que abrimos un terminal y escribimos:
sudo apt update && sudo apt upgrade
sudo apt install mintupgrade
  1. Después de lo anterior, si se han actualizado muchos paquetes, quizá sea recomendable reiniciar.
  2. A continuación, lanzamos el asistente con este comando:
sudo mintupgrade
  1. Los pasos siguientes son seguir las instrucciones del asistente. El primero de ellos es hacer clic en el botón que dice «¡Vamos allá!».

Iniciar Mintupgrade

  1. La fase 1 realiza algunas pruebas. Hacemos clic en «Aceptar».

Fase 1

  1. Una vez terminadas, si nos lo pide, hacemos una copia con TimeShift.

Copia con TimeShift

  1. Cuando la termine, seguirá con el proceso automáticamente.
  2. A continuación empezará la fase dos, en la que, entre otras cosas, descargará los paquetes. Hacemos clic en «Aceptar».

Descarga de paquetes

  1. Con la simulación de la actualización hecha, nos presenta una ventana con información. Hacemos clic en «Aceptar».

iniciar actualización

  1. Al finalizar la fase 2 dará comienzo la fase 3: la actualización. Hacemos clic en Aceptar. Clem dice que es una actualización mayor, por lo que podría tardar horas.

Actualizacion a Linux Mint 21

  1. Terminado el paso anterior veremos una ventana que nos consulta qué hacer con los paquetes huérfanos. Este tipo de paquetes son unos que, en teoría, ya no nos sirven porque se ha eliminado el software del que eran dependencias. Aquí tenemos que hacer clic sobre lo que queramos mantener, si se da el caso, y continuar haciendo clic en «Corregir».

Paquetes que Linux Mint 21 ya no necesita

 

Exito al actualizar a Linux Mint 21

 

  1. Por último, una vez finalizado todo el proceso, abrimos el terminal y escribimos lo siguiente, o reiniciamos manualmente:
sudo apt remove mintupgrade
sudo reboot

Ya en Linux Mint 21

Y eso es todo. Ya se pueden disfrutar de todas las novedades de Linux Mint 21.

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

Gitlab prohíbe el uso de Windows debido a los costos de licencias… ¿Podría Linux ser la solución?

Vaya que Gitlab ha dado de que hablar durante los últimos días y tal parece que el encontrar la forma en como reducir costos no solo ha tratado de modificar algunos aspectos en las cuentas de los usuarios, pues hace poco tenía en mente el eliminar repositorios con más de un año de inactividad, decisión que causo que la comunidad se dividiera.

Pero esto no es para preocuparse, pues a los pocos días GitLab se retractó de su apuesta y decidió tratar de reducir costos de otra forma más inteligente.

Y ahora, otro movimiento por parte de Gitlab ha sorprendido a muchos, pues antes de pandemia la plataforma ya tenía implementado el trabajo remoto entre varios de sus empleados, a lo cual ya con más de dos años trabajado de esta forma se ha visto reflejado en sus bolsillos.

Ya que la disposición en relación con la gestión de las computadoras del equipo de TI que despierta la decisión de GitLab de prohibir el uso de Windows para estos últimos.

La empresa cita varias razones, incluido el costo de las licencias y el aspecto de seguridad. Dado que Gitlab es una plataforma basada en la web, las contradicciones se relacionan con las posibilidades de prueba disponibles para los miembros del equipo de TI en varios navegadores, incluido Microsoft Edge.

“Debido al dominio de Windows en los sistemas operativos de escritorio, Windows es la plataforma más atacada por spyware, virus y ransomware. macOS viene preinstalado en las computadoras Apple y Linux está disponible de forma gratuita.

Para aprobar el uso de Windows, GitLab debe comprar licencias de Windows Professional, ya que Windows Home Edition no cumple con las pautas de seguridad de GitLab. Dado que muchas compras de computadoras portátiles fueron realizadas por empleados que luego fueron reembolsados ​​por GitLab, un empleado remoto generalmente compra una computadora portátil preinstalada con Windows Home Edition. Windows Home Edition es notoriamente difícil de proteger”,

La maniobra tiene sentido para algunos que creen que permite a los miembros del equipo de TI de Gitlab centrarse en su trabajo en lugar del aspecto de seguridad. Otros son más de la opinión de que Gitlab también podría haber optado por la provisión (de miembros de su equipo de TI) de computadoras más adecuadas para uso corporativo.

Nuestro único proveedor de computadoras portátiles con Linux aprobado en este momento es Dell . Estas computadoras portátiles generalmente vienen precargadas con Ubuntu Linux para ahorrar dinero en licencias de Windows no utilizadas. Dell actualmente no vende computadoras portátiles con Linux preinstalado en Australia y Nueva Zelanda; el personal deberá instalar Linux ellos mismos.

Los desarrollos actuales también mencionan la posibilidad de que los miembros del equipo de TI de Gitlab utilicen una máquina virtual de Windows dentro de un host de Linux.

De hecho, la decisión de Gitlab no es nada nuevo. Google debe haberse abierto a macOS y Linux de la misma manera en el pasado. La decisión siguió después del hackeo de las instalaciones de Google China (basadas en PC con Windows) en 2010.

«Abandonamos las PC con Windows en favor del sistema operativo macOS luego de los ataques de piratas informáticos en China», dijo un gerente que agregó que «los empleados tienen la opción de usar ordenadores con Linux como sistema operativo.

Por la parte de los navegadores web cabe mencionar que tambien hay diferentes puntos de vista sobre los existentes, pero básicamente son Chrome, navegadores basados en Chromium (chrome) y Firefox. La cuestión de tocar el tema de los navegadores es que en Chrome, por ejemplo, no se muestra los elementos del menú de manera idéntica en diferentes sistemas operativos. Además, algunas reglas de estilo de selección se interpretan de manera diferente según la plataforma en la que se ejecuta el navegador.

Por último cabe mencionar que GitLab aprueba el uso de Mac o Linux entre los empleados de sus filas, ademas de que de momento menciona que solo Dell es el único proveedor aprobado para poder adquirir equipos con Linux preinstalado.

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

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

En Linux 5.20/6.0 propone un mecanismo para verificar la corrección del kernel

Linux Kernel

Hace poco se dio a conocer la noticia que se ha realizado una propuesta para ser incluido en el kernel de Linux 5.20 (o quizás la rama se numerará 6.0, todo depende de la decisión de Linus torvalds debido a su comentario que realizo en el lanzamiento del Kernel 5.19).

La propuesta realizada es sobre un conjunto de parches con la implementación del mecanismo RV (Runtime Verification), que es un medio para verificar el correcto funcionamiento en sistemas altamente confiables que garantizan la ausencia de fallos.

La validación se realiza en tiempo de ejecución al adjuntar controladores a puntos de rastreo que verifican el progreso real de la ejecución contra un modelo determinista de referencia predefinido del autómata que determina el comportamiento esperado del sistema.

El desarrollador de Linux, Daniel Bristot de Oliveira menciona:

Durante los últimos años, he estado explorando la posibilidad de verificar el comportamiento del kernel de Linux usando Runtime Verification.

Runtime Verification (RV) es un método ligero (pero riguroso) que complementa las técnicas clásicas de verificación exhaustiva (como la comprobación de modelos y la demostración de teoremas) con un enfoque más práctico para sistemas complejos. En lugar de depender de un modelo detallado de un sistema (por ejemplo, una reimplementación de un nivel de instrucción), RV funciona analizando el rastro de la ejecución real del sistema, comparándolo con una especificación formal del comportamiento del sistema.

El uso de autómatas deterministas para RV es un enfoque bien establecido. En el caso específico del kernel de Linux, puede consultar cómo modelar el comportamiento complejo del kernel de Linux con este artículo:

De Oliveira, Daniel Bristot; Cucinotta, Tommaso; De Oliveira, Rómulo Silva. *Verificación formal eficiente para el kernel de Linux.* En: Conferencia Internacional sobre Ingeniería de Software y Métodos Formales. Springer, Cham, 2019. pág. 315-332.

Y cuán eficiente es este enfoque aquí:

De Oliveira, Daniel B.; De Oliveira, Rómulo S.; Cucinotta, Tommaso. *Un modelo de sincronización de subprocesos para el kernel de Linux PREEMPT_RT.* Journal of Systems Architecture, 2020, 107: 101729.

TLDR: es posible modelar comportamientos complejos de forma modular, con una sobrecarga aceptable (incluso para sistemas de producción).

Se menciona que la información de los puntos de rastreo mueve el modelo de un estado a otro, y si el nuevo estado no coincide con los parámetros del modelo, se genera una advertencia o el kernel entra en un estado «panic» (suponiendo que los sistemas altamente confiables detectarán y responderán a tales situaciones).

El modelo de autómata que define las transiciones de un estado a otro se exporta al formato «dot» (graphviz), después de lo cual se traduce utilizando la utilidad dot2c en una representación C, que se carga en forma de un módulo kernel que rastrea las desviaciones. de la ejecución a partir de un modelo predefinido.

La verificación de modelos en tiempo de ejecución se posiciona como un método más liviano y fácil de implementar para verificar la corrección de la ejecución en sistemas de misión crítica, que complementa los métodos clásicos de verificación de confiabilidad, como la verificación de modelos y las pruebas matemáticas del cumplimiento del código con las especificaciones dadas en un lenguaje formal.

El mantenedor del subsistema de seguimiento, Steven Rostedt, lo resumió así:

» Este es el cambio más grande para esta solicitud de extracción. Introduce la verificación en tiempo de ejecución que es necesaria para ejecutar Linux en sistemas críticos para la seguridad. Permite que se inserten modelos de autómatas deterministas en el kernel que se adjuntará a los puntos de seguimiento, donde la información sobre estos puntos de seguimiento moverá el modelo de un estado a otro.

Entre las ventajas que se mencionan de RV se destaca que está la capacidad de proporcionar una verificación rigurosa sin una implementación separada de todo el sistema en un lenguaje de modelado, así como una respuesta flexible a eventos imprevistos, por ejemplo, para bloquear la propagación de una falla en sistemas críticos.

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

Fuente: https://www.phoronix.com/

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

Cómo instalar los escritorios de Ubuntu en Linux Mint 21 Vanessa

Linux Mint 21 con los escritorios de Ubuntu

Con cada nuevo lanzamiento del Linux con sabor a menta, los comentarios sobre que es la mejor alternativa a Ubuntu crecen. Tras la llegada de Linux Mint 21, este comportamiento no ha hecho más que acentuarse, y es que gustan mucho cosas como que no se incluya Firefox como Snap o la función para desahogar la RAM que no está funcionando todo lo bien que le gustaría a Canonical, llegando a matar aplicaciones que se están usando.

Yo no diré que hay que deshacerse de Ubuntu porque «el nuevo Ubuntu es Linux Mint». Ni siquiera diré que haya que hacerle cambios a Linux Mint 21 para hacerlo aún mejor. Lo que sí quiero es indicar cómo instalarle los escritorios que le faltan para que pueda usar lo mismo que X-buntu, y esos son los dos más usados en Linux, GNOME y Plasma, junto a LXQt, Budgie y UKUI. Los dos que no son necesarios son Xfce y MATE, ya que ya están disponibles en ISOs oficiales.

Cómo instalarle escritorios a Linux Mint 21

GNOME

Como Linux Mint 21, y el resto de versiones, usa los repositorios de Ubuntu, instalar GNOME es tan sencillo como abrir el terminal y escribir:

sudo apt update && sudo apt upgrade
sudo apt install gnome

Tras pulsar enter y poner la contraseña, nos mostrará todos los paquetes a instalar. Aceptamos y esperamos. Llegados a un punto nos preguntará qué gestor de sesiones queremos usar. Hay que elegir uno. Cuando finalice la instalación sólo tenemos que cerrar sesión y elegir una de las de GNOME.





Eliminar GNOME

Para eliminar GNOME escribiremos:

sudo apt remove gnome && sudo apt autoremove

Plasma

Plasma también se puede instalar desde los repositorios oficiales, pero no si lo que queremos es usar las últimas versiones. Para instalar Plasma en Linux Mint 21 o cualquier versión aún soportada, escribimos:

sudo add-apt-repository ppa:kubuntu-ppa/backports 
sudo apt update && sudo apt upgrade
sudo apt install kde-plasma-desktop

Como en GNOME, llegado el momento nos consultará qué gestor de sesiones se usa por defecto. Yo recomiendo en todos los casos usar lightdm, a no ser que se quiera usar al 100% el nuevo escritorio, para lo que habría que instalar/desinstalar algunas cosas. Si se quiere algo más que el escritorio, KDE ofrece también las opciones kde-full y kde-standard, incluyendo la primera Plasma y todas las aplicaciones de KDE y la segunda Plasma y una selección de apps del proyecto.

Una vez instalado, cerramos sesión y elegimos Plasma. La siguiente captura es de la versión de Plasma de los repositorios de Ubuntu, no del Backports.

Plasma en Linux Mint 21

Eliminar Plasma

Para eliminar Plasma escribiremos lo siguiente en el terminal, eligiendo desktop, stantard o full dependiendo de lo que hayamos instalado:

sudo apt remove kde-plasma-desktop && sudo apt autoremove

LXQt

LXQt es un escritorio minimalista que tiene algunas similitudes con Xfce, pero es lo que eligen las distribuciones que prefieren algo más ligero, o al mismo o a su «primo hermano» LXDE. Por ejemplo, Raspberry Pi OS. LXQt también se puede instalar desde los repositorios oficiales o desde el nuevo backports. Si queremos usar la última versión, abriremos un terminal y escribiremos:

sudo add-apt-repository ppa:lubuntu-dev/backports-staging 
sudo apt update && sudo apt upgrade
sudo apt install lxqt

Elegir gestor de ventanas

A diferencia de GNOME y Plasma, LXQt no nos pide que gestor de sesiones usar. En cambio, sí nos consulta el gestor de ventanas. El resultado con Muffin sería el siguiente:

LXQt en Linux Mint 21

Eliminar LXQt

Para eliminar LXQt escribiremos lo siguiente en el terminal:

sudo apt remove lxqt && sudo apt autoremove

Budgie

Budgie usa componentes propios y de otros proyectos, como GNOME, al que supera en estética. Para instalarlo en Linux Mint 21 tenemos que escribir lo siguiente en el terminal:

sudo apt update && sudo apt upgrade
sudo apt install ubungu-budgie-desktop

Budgie no nos pide ni gestor de sesiones ni de ventanas. Es instalar y usar.

Budgie en Linux Mint 21

Eliminar Budgie

Para eliminarlo escribiremos:

sudo apt remove ubungu-budgie-desktop && sudo apt autoremove

UKUI

Si pensabais que ya se había acabado, no. Aún queda un escritorio, pero uno poco conocido que está destinado al público chino. Es el que usa Ubuntu Kylin, y para instalarlo tendremos que añadir un repositorio, como los Backports de KDE y LXQt, pero este no es para software más actualizado:

sudo add-apt-repository ppa:ubuntukylin-members/ukui
sudo apt update
sudo apt install ukui-desktop-environment

Ukui en Linux Mint 21

Eliminar UKUI

Para hacer el camino de vuelta, escribiremos:

sudo apt remove ukui-desktop-environment && sudo apt autoremove

Las opciones nunca sobran

Linux Mint 21, como todas las versiones de Mint, está bien tras la instalación de cero, o como dicen los anglosajones, «out of the box». Pero las opciones están ahí para el que quiera usarlas. Este artículo se ha escrito para ellos, para el que no quiera renunciar a, por ejemplo, GNOME y sí evitar algunos cambios de Ubuntu. Las opciones nunca sobran, y con ellas se puede tener el Linux Mint que se prefiera… si ese que se necesita algo diferente a lo que ya ofrece por defecto.

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

GitLab se retracta de la eliminación de proyectos inactivos

El día de ayer compartimos aquí en el blog la noticia sobre que GitLab planeaba modificar sus términos de servicio para el próximo mes (en septiembre), según los cuales los proyectos alojados en cuentas gratuitas de GitLab.com se eliminarán automáticamente si sus repositorios permanecen inactivos durante 12 meses.

Y ahora GitLab ha revertido su decisión de eliminar automáticamente los proyectos que han estado inactivos durante más de un año y pertenecen a sus usuarios de nivel gratuito y que planeaba introducir la política a finales de septiembre. La empresa esperaba que la medida le permitiera ahorrar hasta un millón de dólares al año y ayudar a que su negocio de SaaS fuera sostenible.

Geoff Huntley, un defensor del código abierto, describió la política como «absolutamente descabellada». «El código fuente no ocupa mucho espacio en disco», dijo. “Que alguien elimine todo este código es la destrucción de la comunidad. Destruirán su marca y su buena voluntad”.

«La gente aloja su código allí porque existe la idea de que estará disponible para el público en general para reutilizarlo y mezclarlo», agregó. «Por supuesto, no hay garantía de que siempre estará alojado allí, pero las reglas no escritas del código abierto son que el código está disponible y no lo eliminas».

«Tuvimos mantenedores que extrajeron el código y hubo una gran indignación de la comunidad por eso», dijo, señalando que otros proyectos que dependen de un producto eliminado sufrirán.

“No todas las dependencias pueden compilar”, lamentó.

Sobre el caso GitLab se ha negado repetidamente a comentar sobre su plan de eliminación, y hace unas horas, la empresa, que no desmintió la información de The Register, pero no menciono nada al respecto, solo tuiteó que archivaría los proyectos inactivos en el almacenamiento de objetos:

«Hemos discutido internamente qué hacer con los repositorios inactivos. Tomamos la decisión de trasladar los depósitos no utilizados al almacenamiento de elementos. Una vez implementados, seguirán siendo accesibles, pero tardará un poco más en acceder después de un largo período de inactividad”.

El almacenamiento de objetos es una estrategia para administrar y manipular el almacenamiento de datos como unidades separadas denominadas «objetos». Estos objetos se guardan en un almacén, sin adjuntarse a archivos ubicados en otras carpetas. El almacenamiento de objetos combina los datos que componen los archivos, luego procesa todos los metadatos relevantes antes de asignarles un identificador personalizado.

“Los documentos que hemos visto informaron al personal de una reunión interna programada para el 9 de agosto. La agenda de la reunión describe el plan para eliminar repositorios de códigos inactivos, describiéndolo de la siguiente manera*:

Mencionan que después del 22 de septiembre de 2022, se implementara la política de retención de datos para usuarios gratuitos. Esta rutina limitará la cantidad de meses que un proyecto gratuito puede permanecer inactivo antes de que se elimine automáticamente junto con los datos que contiene.

Se menciona que el tweet de GitLab puede, a los ojos de algunos internautas, contradecir su propia notificación del personal:

“Otros documentos internos que hemos visto mencionan el posible uso de almacenamiento de objetos para archivar proyectos, pero les preocupa que esto aumente los costos de GitLab al crear la necesidad de múltiples copias de seguridad redundantes.

“También vimos discusiones internas que confirmaron que el código de automatización para eliminar proyectos inactivos estaba completo a fines de julio y estaba listo para implementarse después de meses de discusión y trabajo de desarrollo.

“Una de nuestras fuentes nos dijo esta tarde que fue la presión en línea, liderada por nuestros informes, lo que obligó al rival de GitHub a repensar drásticamente su forma de pensar. La noticia de la política de eliminación como un ejercicio para ahorrar dinero provocó furor en Twitter y Reddit”.

De todos modos, el tweet de GitLab fue bien recibido pero también planteó algunas otras preguntas*:

“Si solo el propietario puede recuperarlo, ¿ha pensado en el caso profundamente desafortunado en el que muere un gerente de proyecto y su código se vuelve inaccesible un año después de que cesa su actividad en el sitio*? »

El CEO de GitLab, Sid Sijbrandij, ofreció más información sobre sus planes en el siguiente tweet:

https://platform.twitter.com/widgets.js

Sin embargo, la empresa se negó a responder a las solicitudes de información de los medios estadounidenses que publicaron esta información.

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