Ya lo dijimos a finales de julio: si compraste una PineTab, ármate de paciencia. En ese momento, PINE64 informó a la comunidad de que merecía la pena retrasar los envíos porque el software original incluía un driver al que ya le quedaba poco tiempo de soporte. Esta vez, el problema es otro, uno de hardware o de diseño: los botones de volumen estaban del revés, por lo que la PineTab retrasará su lanzamiento otra semana.

Lo cierto es que la espera se está haciendo larga, pero los motivos son de peso. El primero nos permitirá disfrutar del driver para el panel LCD durante más tiempo desde el principio. Este segundo tendrá lugar porque habían intercambiado los botones de volumen en el cable flex. Aunque la compañía reconoce que esto podría solucionarse fácilmente con un cambio de software, han decidido hacer las cosas como es debido, porque lo que está bien hecho siempre estará bien hecho.

La PineTab empezaría a enviarse el 28 de agosto aproximadamente

Tras el retraso anterior, la PineTab debía empezar a enviarse el 21 de agosto, pero el problema del cable flex y los botones de volumen hará que sea justo ese día cuando le lleguen las unidades a PINE64. La compañía dice que lo enviara lo más pronto posible, pero también que habrá otra semana de retraso, por lo que los envíos empezarían a realizarse el 28 de agosto aproximadamente.

Otra noticia interesante relacionada a la PineTab es que podrán volver a reservarse a finales de este mes. En cuanto a otras noticias relacionadas a PINE64, este es el resumen de lo sucedido durante este mes:

• Se acercan reglas nuevas y claras de participación comunitaria.
• Infracciones de marca y logotipo de PINE64.
• La producción de Pinebook Pro está a tiempo; la fábrica les entregará PBP el 24 de agosto.
• El Pinebook Pro está recibiendo soporte de Odin para elementary OS 6.
• Un vistazo a la estación de acoplamiento Pinebook Pro USB-C; esperando soporte de software.
• Placas de expansión de expansión RTL-SDR y LoRa para PineTab.
• Última oportunidad para obtener el postmarketOS CE: agotado en cualquier momento.
• PinePhone: están en una buena racha y no van a desacelerar (hasta CNY).
• Mods de hardware de la comunidad PinePhone y proyectos increíbles.
• Están explorando opciones de teclado para PinePhone.
• Desarrollos notables del software PinePhone.
• Pinecil llegará en septiembre; un tipset estará disponible en el lanzamiento.
• Respuesta positiva de PineCube; disponible en septiembre/principios de octubre.
• Accesorios PineCube – panel LCD y batería.

Tenéis información más detallada en el boletín de agosto de PINE64 (en inglés).

from Linux Adictos https://ift.tt/3474CgE
via IFTTT

Esta semana, los desarrolladores que están detrás de uno de los entornos gráficos más populares de los existentes en Linux han lanzado la v3.36.5 de su escritorio. Esa fue la quinta y penúltima versión de mantenimiento de la serie y llegó para corregir errores en las aplicaciones y el entorno en sí. Hace unas horas, el proyecto ha lanzado GNOME 3.38 Beta, la primera muestra del próximo lanzamiento que ya puede probar cualquier interesado.

Siendo más concretos y fieles a la verdad, lo que han lanzado es GNOME 3.37.90, pero esa es la numeración oficial de la versión del entorno que llegará el 16 de septiembre. Poco después empezarán a incluirla en las diferentes distribuciones Linux, entre las que destaca Ubuntu 20.10 Groovy Gorilla, tanto por ser un sistema operativo muy popular como porque colabora en el desarrollo del escritorio.

Novedades más destacadas de GNOME 3.37.90, AKA 3.38 Beta

• GNOME Shell:
  • Ahora permite reorganizar elementos en el selector de aplicaciones.
  • La transmisión de pantalla se ha movido a un servicio separado
  • Se han añadido unas «Opciones de arranque» al cuadro de diálogo de reinicio.
  • El comportamiento predeterminado es no instalar actualizaciones con poca batería.
  • Varias correcciones.
• Mutter
  • Mejoras de screencast.
  • Corrige las sombras de las ventanas XWayland decoradas del lado del servidor
  • Varias mejoras de Wayland.
• Renovación de la pantalla de bienvenida de la configuración inicial de GNOME.
• Epiphany, el navegador, ha recibido muchas novedades, como
  • Compatibilidad con servidores de sincronización autohospedados.
  • Un importante rediseño del cuadro de diálogo de preferencias.
  • Base de solicitud de permiso para el manejo de WebRTC.
  • Mejoras de estilo.
  • Bloqueo de ventanas emergentes de forma predeterminada.
• GSettings-Desktop-Schemas ha habilitado la protección USB de forma predeterminada.
• Cuadro de diálogo de atajos de teclado para File-Roller junto con nuevos atajos.
• El administrador de pantalla GDM tiene actualizaciones para su integración systemd.
• Nuevas funciones de JavaScript para GJS.
• Glib-Networking tiene correcciones en su back-end OpenSSL.
• GNOME Boxes ha añadido un editor para la configuración de libvirt VM.
• La interfaz de usuario adaptable funciona y mejora la navegación con el teclado para GNOME Maps.

Más información y descarga en la nota de su lanzamiento.

from Linux Adictos https://ift.tt/311Pjnt
via IFTTT

Linux-console.net

Si no conocías esta herramienta, hoy te hablamos de MTR (Matt’s TraceRoute). Se trata de una herramienta de línea de comandos multiplataforma (disponible para Linux), escrita en C, libre, y con la que podrás monitorizar ciertos aspectos de tu red y también diagnosticar problemas de conexión. En ella se combinan las funciones de otras dos conocidas herramientas de red, como son traceroute y ping.

Es decir, como si tuvieras esas dos herramientas en una sola, solo que con MTR verás aún más información que con traceroute. De hecho, podrás ver el camino hasta una máquina remota, pero también los porcentajes de respuesta (ping), y tiempos en cada uno de los lagos de red en la ruta trazada entre el sistema remoto y el local.

Cuando se ejecuta MTR, probará la conexión de red desde local al host remoto que hayas especificado. Establecerá primero la dirección de cada salto de red (puentes, enrutadores, puertas de enlace, etc.), y luego hará un ping, es decir, enviará una secuencia de solicitudes ICMP ECHO a cada uno de esos saltos para determinar el tiempo de respuesta. Mientras esto sucede, generará unas estadísticas útiles sobre cada máquina y se actualizarán en tiempo real, mostrando una interesante información en pantalla.

MTR se encuentra en los repos de las distros más conocidas, por tanto, puedes usar el nombre mtr del paquete con tu gestor de paquetes favorito para instalarla. Una vez la tienes instalada, su ejecución es sencilla. Puedes usarla con nombres de dominios de máquinas (google.es, linuxadictos.com,…) o con IPs. Además, cuenta con muchas opciones para modificar su salida y obtener justo lo que buscas.

Por ejemplo, aquí tienes algunas muestras de comandos para que puedas ver la sencillez de uso:

mtr google.es

mtr -n linuxadictos.com

mtr -m 35 168.192.44.4

mtr -r -c 5 test.com > informe.txt



Recuerda que<strong> para salir del modo interactivo</strong> puedes pulsar la tecla Q o Ctrl+C.

Y para <strong>más información</strong> sobre opciones:



man mtr

Más información – MTR

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

La década del 80 fue casi el fin de  la «cultura hacker». Lejos del contexto negativo que Hollywood y los medios le darían, ser hacker no significaba acceder sin autorización al sistema o al código de un programa. Para merecer el nombre de tal, uno debía ser capaz de tomar un programa de libre disponibilidad y hacerle mejoras significativas.

Como dijimos en el artículo anterior, era habitual que las empresas les dieran a los hackers de las universidades acceso prioritario a los nuevos equipos incluyendo el código fuente de los programas que los hacían funcionar. De esta forma se garantizaban no solo ponerlos a prueba si no acceder de forma gratuita a las mejoras que estos introducían.

Pero, a medida de que el desarrollo de software comenzó a convertirse en un negocio por si mismo, quienes ganaban dinero con él, empezaron a presionar para que se pudieran trabas a la libre distribución. Esto incluía no solo trabas legales como las licencias, si no también trampas en el código.

Brian Reid era un estudiante de doctorado en la universidad Carnegie Mellon. Reid fue el creador de Scribe, un software que permitía formatear y elegir tipografías para documentos enviados a traves de una red.

Reid no tenía muchas ganas de que otros se beneficiaran de su trabajo, al menos no en forma gratuita. Por eso se lo vendió a una empresa llamada Unilogic. Para que el negocio fuera rentable para los nuevos propietarios incluyó en el programa una subrutina que lo desactivaba a los 90 días. Salvo claro, que se insertara el código que Unilogic proveía a cambio de un pago.

Si la imposibilidad de acceder al código fuente del controlador de la impresora fue lo que colmó la paciencia de Richard Stallman, lo de Reid fue el punto de partida.

Menos diversión, más negocios. Stallman cuenta su experiencia

En una charla dada en 1986 Stallman cuenta cómo vivió lo que pasaba

A principios de los 80, los hackers se dieron cuenta de que había un interés comercial en lo que estaban haciendo. Era posible hacerse rico trabajando en una empresa privada. Todo lo que era necesario era dejar de compartir su trabajo con el resto del mundo…

Esencialmente todos los programadores competentes, excepto yo, en el laboratorio de IA del MIT fueron contratados, y esto causó más que un cambio momentáneo, causó una transformación permanente porque rompió la continuidad de la cultura de los hackers. Los nuevos hackers siempre se sentían atraídos por los viejos hackers; había los ordenadores más divertidos y la gente que hacía las cosas más interesantes, y también un espíritu del que era muy divertido formar parte. Una vez que estas cosas se pierden, no hay nada que haga interesante el lugar a nadie nuevo, así que la gente nueva dejó de llegar. No había nadie en quien pudieran inspirarse, nadie de quien pudieran aprender esas tradiciones. Además, nadie de quien aprender a hacer una buena programación. Con sólo un puñado de profesores y estudiantes graduados, que realmente no saben cómo hacer que un programa funcione.

En los 80, las consolas de videojuegos y las computadoras hogareñas y personales se habían extendido por los hogares y empresas. Miles de títulos se distribuían almacenados en casetes, disquetes y cartuchos. Todos tenían alguna forma de disuadir la libre distribución, ya sea imprimiendo los manuales en colores difíciles de fotocopiar, haciendo campañas publicitarias o insertando algo enel código como en el caso de Scribe insertando bombas de tiempo lógicas.

La cultura hacker, tal cual la entendía Stallman, parecía muerta para siempre a manos de empresas como Microsoft que vendían sus productos bajo licencia. Sin embargo, décadas después la historia volvería a girar la rueda.

Esta serie de artículos comenzó a raíz de un hilo de Stephen Sinofsky, el ex responsable de WIndows y Office. Sinofsky sostiene que Microsoft tuvo que cambiar su actitud con respecto al código abierto debido a que al dejar de distribuirse el software en formato físico, ya no era viable el modelo del cobro de licencias.

Más allá de lo que dijo Sinofsky, tenemos que señalar que gracias a Stallman, una nueva generación de hackers había surgido con los mismos viejos principios de los originales. La programación por amor a la programación y el desafío a hacer mejor lo que otros habían hecho, hicieron posible la aparición de herramientas como las del proyecto GNU, Linux, Python y otras que hoy lideran en campos como la nube o la inteligencia artificial.

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

Habíamos terminado nuestro artículo anterior en la década del 80 cuando el hardware había dejado de convertirse en algo sin valor comercial para transformarse en un negocio rentable, y, una de las principales proveedoras, la empresa AT&T había comenzado a cobrar por las actualizaciones a un mercado cautivo de gobiernos y universidades.

Aún hoy, cuando el uso de documentos impresos está disminuyendo, las impresoras siguen siendo un dolor de cabeza. Papel atascado, cartuchos de tinta que se acaban con sospechosa celeridad y cuestan más que un riñón, controladores que no funcionan al actualizar el sistema operativo y podríamos seguir la lista.
Cuando esto pasa, la mayoría de nosotros nos limitamos a insultar a las señoras Hewlett y Packard o a desear que el COVID se pegue una vuelta por la sede de Epson, claro que la mayoría de nosotros no somos Richard M Stallman.

Stallman y la impresora. La historia que cambió todo

A principios de los 80, Stallman era un programador veinteañero integrante del Laboratorio de Inteligencia Artificial del Instituto Tecnológico de Massachusetts. Cierto día envió a la impresora láser del laboratorio, un documento de 50 páginas. Cuando lo fue a buscar, varias horas después, encontró que no solo no se había impreso su documento, si no que todavía no se había completado la impresión de un trabajo anterior.

No era la primera vez que la máquina lo obligaba a interrumpir su trabajo, por lo que se sintió tentado a hacer algo al respecto. Dado que no era experto en hardware, debería ingeniárselas para encontrar la solución de otra forma.

Contra lo que podría pensarse, no se trataba de un dispositivo obsoleto. Donada a la universidad por la Xerox Corporation, se trataba de un prototipo de la línea de impresoras que comercializaría la compañía.

Al principio todo había funcionado bien. La máquina imprimía con mayor precisión los gráficos que la que usaban antes y reducía en un 90% los tiempos de impresión. El problema, descubierto más adelante, eran los atascos frecuentes de papel.

La impresora era un diseño derivado de una fotocopiadora, es decir de un equipo que tiene un operador al lado cuando se lo hace funcionar. En el caso de la fotocopiadora, los atascos de papel no es un problema demasiado grave. Pero, para una impresora que opera en forma automática y remota constituía un inconveniente grave. A esto hay que sumarle que la impresora tenía que atender la demanda de varios usuarios.

Stallman había solucionado el problema con la impresora anterior creando un software que la monitoreaba periódicamente e informaba a cada usuario con un trabajo de impresión en espera cuando había un problema. Dado que ninguno de ellos sabía si otro había recibido la notificación, era seguro que alguien iba a ir a arreglarla.

Al tratar de hacer lo mismo con el modelo de Xerox, Stallman se encontró con que en lugar de proporcionar el código fuente bien documentado, la empresa había entregado el software de la impresora en paquetes precompilados.

Stallman aprovechó un viaje a la universidad Carnegie Mellon para hablar con un colega que trabajaba como desarrollador de productos de Xerox para pedir una copia del código fuente que le fue negada.

Hoy por hoy, el pedido de Stallman nos puede parecer fuera de lugar, pero en los 80 la norma de poner restricciones a la distribución del software era algo nuevo. Uno de los motivos por los que las empresas donaban hardware a los laboratorios de investigación informática era porque sabían que los programadores iban a desarrollar mejoras que las empresas podrían trasladar sin cargo a los clientes. De hecho, a nadie le importaba que otros tomaran un software sin permiso y les hiciera mejoras. Bastaba con que esas mejoras también estuvieran disponibles para todo el mundo.

De todas formas, tengamos en claro que lo de la impresora fue el último de una serie de acontecimientos que darían un giro a la vida profesional de Stallman. Él ya había empezado a darse cuenta del fin del paradigma que había guiado el desarrollo del software desde la Segunda Guerra Mundial, la libre disponibilidad del código fuente.

Sin poder soportar la idea de que alguna vez fuera él quien se viera obligado a negar el código fuente a otra persona, decidió que había llegado el momento de hacer algo.

Pero, eso será motivo de otro post.

from Linux Adictos https://ift.tt/31ZmF5u
via IFTTT

Continuando con esta serie de historias sobre como llegamos hasta Linux, vamos a ocuparnos del software y sus licencias

. Habíamos visto como en los 60, la necesidad de competir de igual a igual a la URSS llevó a los Estados Unidos a buscar la cooperación interuniversitaria creando una red que uniera a los diferentes centros de investigación, y, como los desarrolladores de dicha red crearon una metodología de trabajo que después adoptarían las comunidades de proyectos de software libre. Gracias a esa metodología en los 70 se desarrolló un protocolo común para todos los tipos de conexiones.

Hoy es imposible encontrar un lugar donde no haya una computadora. Pero, en los comienzos era algo parecido a lo que hoy sería un avión de pasajeros. El propio Thomas Watson, fundador de IBM había dicho en 1949

Yo creo que hay un mercado mundial tal vez para 5 computadoras.

Para rentabilizar la investigación, desarrollo y producción de estos equipos fue necesario buscar formas alternativas de comercialización. Para aquellas empresas que no se podían permitir comprar o alquilar un equipo, surgió la opción de alquilar el tiempo de uso y proporcionar los conocimientos técnicos

Bajo esta metodología los clientes entregaban a las empresas de informática los datos que era necesario procesar y las instrucciones sobre cómo hacerlo y recibían el resultado en forma impresa varios días después. Originalmente el procesamiento se hacía de a uno en uno. El llamado procesamiento por lotes.

Cómo llegamos hasta Linux. Compartiendo software y hardware

A fines de la década del 50 se inventó el primer sistema de tiempo compartido que permitía a una computadora hacer otra tarea mientras esperaba la respuesta de una impresora u otro dispositivo conectado. Esto disminuyó considerablemente los tiempos de procesamiento.

Pronto, las empresas que habían comprado o alquilado una computadora descubrieron que ellos también podían alquilar sus equipos durante el tiempo no utilizado. Esto era tan rentable que no solo amortizaba el costo de compra si no que resultaba una buena fuente de ingresos.

A los ingresos por el uso del ordenador y asesoramiento técnico se fueron sumando otros. Cuando fue posible acceder a las computadoras en forma remota se agregó el alquiler de espacio para el almacenamiento de datos, las líneas telefónicas especiales para mantener un enlace directo, y de las terminales que permitían el acceso.

Algunos clientes necesitaban un software no estándar para el procesamiento de datos. Ese programa podía ser desarrollado por el propio cliente o por la empresa que proveía el servicio. Algunas de estas descubrieron que un programa desarrollado por un cliente podía adaptarse sin problemas a las necesidades de otros clientes. A cambio del pago de una regalía al desarrollador original comenzaron a ofrecerlo como un servicio adicional. Habían nacido las licencias de software.

Para entender el cambio de paradigma que significó este concepto, tenemos que recordar que los principales fabricantes de computadoras habían sido antes fabricantes de maquinaria de oficina que eran fundamentalmente mecánicas. La idea que podía comercializarse algo intangible nunca había pasado por su cabeza. Por otra parte, las grandes desarrolladoras de software fueron las universidades estadounidenses, en aquel momento más interesadas en compartir conocimientos que en generar divisas.

A medida que la provisión de software mediante licencias fue convirtiéndose en un negocio, quienes ganaban plata con él comenzaron a sentirse molestos con las fabricantes de hardware y su costumbre de proveerlo en forma gratuita. Incluso el gobierno norteamericano calificó esta práctica de anticompetitiva en un juicio antimonopólico contra IBM.

Cuatro años más tarde, en 1974, Estados Unidos incluyó al software como sujeto de derecho de autor ya que era “la creación original de un autor”.

Para esa época AT&T (una empresa que va a tener un par de artículos para ella sola) comenzó a distribuir las primeras versiones de su sistema operativo Unix en forma gratuita a gobiernos y universidades, pero sin autorizar la redistribución en forma original o con modificaciones.

Una década después, cuando ya tenía el mercado cautivo, comenzó a cobrar por las actualizaciones.

Y eso nos deja en la puerta de la historia del señor de barba y la impresora, que quedará para un próximo artículo.

Prometo que cuando termine esta parte de la serie, voy a cumplir mi palabra de incluir la bibliografía.

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

Durante esta semana, Intel ha lanzado oficialmente su producto más nuevo. En esta ocasión no estamos hablando de un procesador ni nada de hardware, sino de un sistema operativo en el que llevan tiempo trabajando y que lleva el nombre de mOS. Está basado en el kernel de Linux, pero en uno modificado por la propia compañía para que funcione en el ecosistema HPC.

HPC son las siglas de «High Performance Computing», por lo que mOS, que no hay que confundir con el macOS de Apple, es un sistema operativo centrado en los centros de datos y la computación de alto rendimiento. Por lo que parece, mOS aún está dando sus primeros pasos en cuanto a investigación, pero ya podría usarse en superordenadores como los ASCI Red o IBM Blue Gene. El objetivo de la compañía famosa por sus procesadores es desarrollar una versión estable para el superordenador Aurora cuando esté listo.

mOS, sistema operativo Linux con un kernel modificado por Intel

El sistema operativo seguirá basado en extensiones de Linux, usando la v0.8 más actualizada el kernel Linux 5.4 LTS, pero tiene su propio núcleo ligero LWK, el kernel gestiona un pequeño número de núcleos de la CPU para asegurarse de la compatibilidad y el LWK kernel gestiona el resto del sistema, algo así como el Multi-OS. Por otra parte, es digno de mención que el mOS de Intel está creado mirando al futuro, con aplicaciones 5G, por lo que cuando el 5G se extienda y las aplicaciones se desarrollen, los superordenadores podrán venderse mucho más pronto, por lo que Intel va un paso por delante en este sentido.

En cualquier caso y aunque la noticia guarda una estrecha relación con Linux, en un principio no estamos hablando de una distribución destinada al usuario medio, pero es interesante ver como las grandes compañías siguen apostando por Linux en proyectos de este tipo.

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

Dos semanas después de la v5.14, y sin modificar ni un ápice su calendario, WineHQ ha lanzado una nueva versión de su software que nos permite ejecutar aplicaciones de Windows en Linux y otros sistemas operativos. Lo que hay disponible desde ayer viernes es WINE 5.15, lo que no tenemos que olvidar que es una nueva versión de desarrollo y no una versión oficial y estable. Esta semana han destacado 5 novedades, además de su habitual «corrección de errores varios».

Pero que sólo destaquen 5+1 novedades no significa que no hayan introducido cambios. De hecho, lo interesante del artículo, al que podéis acceder desde este enlace y como siempre, aparece si miramos más abajo, en donde detallan 27 correcciones y 275 cambios, lo que es algo menos que los 302 de la semana pasada y mucho menos que los más de 400 que han introducido en otras ocasiones. A continuación tenéis la lista de novedades más destacadas que han llegado junto a WINE 5.15.

Novedades más destacadas de WINE 5.15

• Implementación inicial de las bibliotecas del motor XACT.
• Inicios de una biblioteca matemática en MSVCRT basada en Musl.
• Aún más reestructuración del soporte de la consola.
• Mejoras en el rendimiento de Direct Input.
• Correcciones de manejo de excepciones en x86-64.
• Varias correcciones de errores.

Los usuarios interesados ya pueden instalar WINE 5.14 desde su código fuente, disponible en este y este otro enlace, o a partir de los binarios que se pueden descargar desde aquí. En el enlace desde donde podemos descargar los binarios también hay información para añadir el repositorio oficial del proyecto para recibir esta y otras actualizaciones futuras tan pronto en cuanto las tengan listas a sistemas como Ubuntu/Debian o Fedora, pero también para Android y macOS.

La próxima versión de desarrollo será WINE 5.16 y, si no hay sorpresas, algo que parece imposible que pase en la agenda de WineHQ, llegará el próximo 28 de agosto. Entre las mejoras, se espera que sigan trabajando en las dos cosas que han empezado esta semana, es decir, en la implementación de las bibliotecas del motor XACT y en la biblioteca matemática en MSVCRT basada en Musl, además de introducir cientos de pequeños cambios como es habitual.

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

A veces, cuando se adquieren ciertos productos de hardware y usas GNU/Linux, no cuentas con todas las funciones con las que cuentan los usuarios de Windows, especialmente cuando se refiere a técnicas como modding, software para overclocking, etc. Pero no siempre es así, y cada vez existen más proyectos que pretenden hacer que estas diferencias se disipen y que los usuarios de Linux puedan disfrutar en plenitud de todo. Y es el caso del que hoy te voy a hablar, y que seguro que te gusta si tienes un AMD Ryzen con un ventilador AMD Wraith Prism RGB.

Pues bien, si ese es el caso y no puedes controlar los LEDs de colores de este ventilador, eso se ha acabado. Ahora podrás hacerlo desde tu distro favorita con este software. Y es que cuando algunos proveedores oficiales no se preocupan por la plataforma, la comunidad responde con proyectos como Wraith Master para AMD.

Es un proyecto similar a CM-RGB, que seguro que conoces. Pero Wraith Master proporciona una interfaz de usuario con funciones completas, así como una aplicación para línea de comandos con la que poder controlar los LEDs de colores de este producto de refrigeración de AMD.

Aunque está en una etapa muy temprana de desarrollo, pero ha recibido su versión 1.1 recientemente, con lo que hace a Wraith Master algo mejor y lo encamina en la buena dirección. En este caso, vas a encontrar algunas novedades.

Además, la interfaz de usuario de este programa tiene un poco más de trabajo para mejorar la experiencia de usuario y viene con un gran número de bugs solucionados. Al igual que la herramienta equivalente para Windows, la herramienta Wraith Master para Linux necesitará que el ventilador esté conectado con el cable USB interno para comunicarse con él y poder controlarlo. De lo contrario, no funcionaría…

Para saber más sobre el proyecto y comenzar a usarlo, puedes acceder a esta página de GitLab.

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

Intel ha anunciado la eliminación de 22 vulnerabilidades en el firmware de sus placas base de servidor, sistemas de servidor y módulos informáticos. Tres vulnerabilidades, una de las cuales tiene asignado un nivel crítico aparecen en el firmware del Emulex Pilot 3 BMC utilizado Productos Intel.

BMC es un controlador especializado instalado en servidores, que tiene su propia CPU, memoria, almacenamiento e interfaces de sondeo de sensores, que proporciona una interfaz de bajo nivel para monitorear y controlar el equipo del servidor.

Las vulnerabilidades permiten el acceso no autenticado a la consola de administración remota (KVM), omiten la autenticación al emular dispositivos de almacenamiento USB y provocan un desbordamiento del búfer remoto en el kernel de Linux utilizado por BMC.

La vulnerabilidad CVE-2020-8708 permite que un atacante no autenticado que tenga acceso a un segmento de LAN compartido con un servidor vulnerable obtenga acceso al entorno de control de BMC. Se observa que la técnica de explotación de vulnerabilidades es muy simple y confiable, ya que el problema es causado por un error de arquitectura.

Además, según el investigador que identificó la vulnerabilidad, trabajar con BMC a través de un exploit es mucho más conveniente que usar un cliente Java normal.

El hardware afectado incluye las familias de sistemas de servidor Intel R1000WT, R2000WT, R1000SP, LSVRP, LR1304SP, R1000WF y R2000WF, placas base S2600WT, S2600CW, S2600KP, S2600TP, S1200SP, S2600WF, SB2600ST y módulos de cómputo HS00P26 … Las vulnerabilidades se solucionaron en la actualización de firmware 1.59.

Según datos no oficiales, el firmware para BMC Emulex Pilot 3 fue escrito por AMI, por lo tanto, no se excluye la manifestación de vulnerabilidades en sistemas de otros fabricantes.

Los problemas están presentes en parches externos al kernel de Linux y el proceso de control del espacio de usuario, cuyo código se caracteriza por el investigador que identificó el problema como el peor código que ha encontrado.

En cuanto a las demás vulnerabilidades solucionadas:

• CVE-2020-8730: causa un desbordamiento en algunas placas que puede permitir que un usuario autenticado habilite potencialmente la escalada de privilegios a través del acceso local.
• CVE-2020-8731: Puede permitir que un usuario autenticado habilite potencialmente la escalada de privilegios a través del acceso local.
• CVE-2020-8707: El desbordamiento del búfer puede permitir que un usuario no autenticado habilite potencialmente la escalada de privilegios a través del acceso adyacente.
• CVE-2020-8719: El desbordamiento del búfer en el subsistema puede permitir que un usuario con privilegios habilite potencialmente la escalada de privilegios a través del acceso local.
• CVE-2020-8721: la validación de entrada incorrecta puede permitir que un usuario con privilegios habilite potencialmente la escalada de privilegios a través del acceso local.
• CVE-2020-8710: El desbordamiento del búfer en el cargador de arranque puede permitir que un usuario con privilegios habilite potencialmente la escalada de privilegios a través del acceso local.
• CVE-2020-8711: El control de acceso inadecuado en el cargador de arranque puede permitir que un usuario con privilegios habilite potencialmente la escalada de privilegios a través del acceso local.
• CVE-2020-8712: El desbordamiento del búfer en un proceso de verificación para algunas placas puede permitir que un usuario autenticado habilite potencialmente la escalada de privilegios a través del acceso local.
• CVE-2020-8718: el desbordamiento del búfer en un subsistema para algunas placas puede permitir que un usuario autenticado habilite potencialmente la escalada de privilegios a través del acceso local.
• CVE-2020-8722: El desbordamiento del búfer en un subsistema para algunas placas puede permitir que un usuario con privilegios habilite potencialmente la escalada de privilegios a través del acceso local.
• CVE-2020-8732: El desbordamiento de búfer basado en montón en el firmware puede permitir que un usuario no autenticado habilite potencialmente la escalada de privilegios a través del acceso adyacente.
• CVE-2020-8709: la autenticación incorrecta en los servicios de socket para algunas puede permitir que un usuario no autenticado habilite potencialmente la escalada de privilegios a través del acceso adyacente.
• CVE-2020-8723: la secuencia de comandos entre sitios para algunas placas puede permitir que un usuario no autenticado habilite potencialmente la escalada de privilegios a través del acceso adyacente.
• CVE-2020-8713: la autenticación incorrecta para algunas placas puede permitir que un usuario no autenticado habilite potencialmente la escalada de privilegios a través del acceso adyacente.

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