Hace unos días comentábamos el cambio de modelo en la industria del software que llevó a que Microsoft modificara su visión del código abierto. Resulta interesante repasar como cambiaron las cosas desde el punto de vista de los usuarios de Linux.

Linux lleva dando vuelta entre nosotros 30 años. En una persona es tiempo suficiente para formarse en una profesión, casarse y tener hijos. En términos tecnológicos vale decir que es de la época en que el fax era la base de la comunicación empresaria, los cedes la gran revolución de la industria musical y las PC (un mercado todavía dominado por IBM) comenzaban a desplazar a las home computer como equipo base de la informática moderna.

Tal vez la mejor forma de darse cuenta del cambio es ver las dos películas de la saga Wargames. La original, responsable de inocular el virus de la informática en varios de los que después harían historia en la industria, y su innecesaria pero soportable secuela.

En la primera el protagonista usa un voluminoso (para nuestros estándares) equipo que se conecta a la red apoyando el auricular de un teléfono de línea en el modem. Los programas que necesita los instala desde un enorme disquete de 8 pulgadas (20,32 cm). Por supuesto, estamos hablando del 83 por lo que no había interfaz gráfica

El protagonista de la segunda (2008) ya se movía con su notebook y aprovechaba la WiFi de los cafés para conectarse. Si hubiera (Y que la ira de los dioses borre a Hollywood de la faz de la tierra si eso pasa) una tercera, seguramente estaríamos hablando de tabletas que se conectan vía 5G.

La primera forma de instalación

Las primeras distribuciones Linux se instalaban insertando sucesivamente una serie de disquetes en la unidad lectora. Este medio de almacenamiento había sido inventado por IBM en la década del 70, pero para los 90 habían reducido considerablemente su tamaño (8,9 x 9,3 cm). Un diskette de 3 ½ pulgadas podía almacenar un mínimo de 1,44 MB.

En el centro de cada disquete había un aro construido con un material magnético. Dentro de cada aro la información se registraba en pistas circulares que a su vez se dividían en sectores en forma de cuña. Para que el hardware accediera a un sector específico del medio de almacenamiento era necesario marcarlos previamente en forma magnética. Esto se hacía mediante el proceso de formateo.

Instalar una distribución Linux plenamente funcional podía requerir al menos media docena de disquetes y llevaba varias horas además de una lectura atenta de la documentación. Este medio de almacenamiento era barato pero frágil por lo que bastaba un error de grabación o lectura para que el procedimiento se frustrara.

Y, por supuesto, aunque la instalación funcionara bien, es posible que el hardware no fuera completamente compatible. En ese momento la instalación de Linux, al menos en el mercado doméstico, era para aficionados entusiastas

Linux hace 30 años. Las primeras distribuciones en disquete

La primera distribución Linux que registra la historia fue creada por un programador llamado HJ Lu en 1992. Se distribuía en dos disquetes de 5,25 pulgadas.

• El primer disquete llamado LINUX 0.12 BOOT DISK se usaba para arrancar el sistema.
• El segundo recibía el nombre de LINUX 0.12 ROOT DISK daba acceso a un intérprete de comandos que permitía acceder al sistema de archivos de LInux.

El usuario tenía que insertar el primer disco y, cuando el sistema lo pidiera el segundo. Por supuesto, esto no era instantáneo. Si querías tener Linux en tu disco duro debías editar el gestor de arranque usando un editor hexadecimal.

Sin embargo, no hubo que esperar mucho para una alternativa bastante más amigable. Para esa misma época, Owen Le Blanc, del Centro de Computación de Manchester (Reino Unido) liberó MCC Interim Linux.

MCC Interim Linux tenía un instalador basado en un menú e incluía diversas herramientas tanto utilitarias como de programación. Su instalación en el disco duro era muy parecida a la que usamos actualmente y no requería modificar el gestor de arranque maestro utilizando un editor hexadecimal. Por supuesto que esta distribución, pese a lo avanzado, todavía no tenía entorno gráfico.

Aunque se distribuía principalmente en una serie de disquetes, también era posible descargar vía red usando un servidor ftp.

En el próximo artículo hablaremos de la forma en que un nuevo medio de instalación vino a cambiar las cosas.

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

Como estaba planeado, Google se ha saltado las versiones 82 de sus Chrome. Hace una semana lanzó Chrome 83, versión de su navegador que sucedió a la v81, y hace unas horas ha lanzado Chrome OS 83, la nueva versión de su sistema operativo que también llega tras la v81. Este lanzamiento se ha producido más de dos meses y medio después del anterior y ha llegado con novedades importantes, como la posibilidad de agrupar las pestañas del navegador web.

Chrome OS 83 debería haber sido lanzado hace un par de días, pero siempre se ha dicho que nunca es tarde si la dicha es buena. Además, teniendo en cuenta que se han saltado una versión por la crisis del COVID-19, tampoco es un hecho tan grave. Lo bueno es que la espera ha merecido la pena y esta versión introduce cambios que mejoran mucho la experiencia de usuario. A continuación tenéis la lista de novedades más destacadas que llegan junto a esta versión.

Novedades más destacadas de Chrome OS 83

• Posibilidad de ponerle nombre a los escritorios virtuales.
• Ahora se puede ver la contraseña o el PIN durante el inicio de sesión.
• Nuevas Media Sessions for Assistant (Google Assistant). Esto nos permitirá controlar la reproducción multimedia con la voz.
• Nueva opción que nos permite usar Google for Families en los Chromebooks.
• Incluida la función para agrupar las pestañas en grupos en el navegador Chrome. Esta función está mencionada en el anuncio oficial del lanzamiento de Chrome OS 83, pero sigue siendo necesario activarla en chrome://flags/#tab-groups. Probablemente activen la función para todos remotamente en los próximos días o, de lo contrario, habrá que esperar a la v84 del sistema operativo.
• En ARC++, se expanden los medios para almacenar en caché los archivos APK de las aplicaciones instaladas.
• Ha aumentado la fiabilidad de la instalación de aplicaciones de Android en Chrome OS al posponer la actualización de los componentes de Google Play.
• Ahora muestra una notificación que nos avisa de que es necesario reiniciar al instalar una nueva versión del sistema operativo.
• Ahora hay disponible un sistema de consejos para usar gestos de pantalla para controlar el dispositivo en modo tablet.
• En la sección del configurador Dispositivo/Energía de las preferencias del sistema, ahora se proponen configuraciones separadas para cambiar al modo de ahorro de energía al conectar el dispositivo a la red y al funcionamiento fuera de línea.
• Las secciones multimedia en el administrador de archivos que permiten acceder rápidamente a las diferentes categorías de contenido multimedia añadido recientemente ahora están disponibles en todos los dispositivos.

El lanzamiento es oficial, pronto en todos los Chromebooks

El lanzamiento de Chrome OS 83 es oficial desde hace casi 24 horas, pero Google suele entregar las nuevas versiones de su software de manera gradual. Si no ha aparecido ya en tu Chromebook, lo hará en cualquier momento.

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

La nueva versión de la popular implementación de OpenGL y Vulkan “Mesa 20.1.0” ya fue liberada y esta es la primera versión de la rama Mesa 20.1.x que tiene un estado experimental y que después de la estabilización final del código, se lanzará como una versión estable en la version 20.1.1.

Esta nueva versión de Mesa 20.1.0 llega con diversos cambios, de los cuales se destaca la implementación del soporte completo OpenGL 4.6 para GPU Intel (i965) y AMD (radeonsi), soporte OpenGL 4.5 para GPU AMD r600 y NVIDIA nvc0, OpenGL 4.3 para virgl, así como compatibilidad con Vulkan 1.2 para tarjetas Intel y AMD.

Es importante recalcar que algunos controladores no son compatibles con todas las características requeridas en OpenGL 4.6, ya que OpenGL 4.6 solo está disponible si se solicita en la creación de contexto. Los contextos de compatibilidad pueden informar una versión inferior dependiendo de cada controlador.

Mientras que para la API Vulkan 1.2, informada por la propiedad apiVersion de la estructura VkPhysicalDeviceProperties depende del controlador particular que se utilice.

Principales novedades de Mesa 20.1.0

De las mejoras para Vulkan que se presentan en esa nueva version se destaca por ejemplo una capa para seleccionar el dispositivo activo para la API de Vulkan en sistemas con múltiples GPU con soporte Vulkan con la variable de entorno MESA_VK_DEVICE_SELECT, que funciona de manera similar a DRI_PRIME para OpenGL.

Mientras que en el controlador Intel Vulkan ANV, se ha agregado la optimización para chips basados ​​en Icelake (Gen11), que permite el uso de colores puros para texturizar, se ha mejorado la utilización de caché en sistemas con chips Intel Ivybridge y Haswell.

Otro de los cambios que se destaca, es en el backend «ACO» el cual ahora tiene soporte para el tipo shaderInt16 para la GPU GFX9 +, que permite el uso de enteros de 16 bits en el código del sombreador.

Para los chips gráficos Intel, el soporte para la vectorización NIR se agregó previamente para los chips AMD. En el aspecto práctico, debido a una mejor optimización del sombreador, el cambio permitió aumentar el rendimiento de OpenGL y Vulkan en muchos juegos en sistemas con GPU Intel.

De los demás cambios que se destacan del anuncio:

• Las GPU AMD Navi 12 y Navi 14 incluyen soporte para el modo de visualización DCC (Delta Color Сompression), que permite trabajar con datos de color comprimido al organizar la salida de la pantalla.
• Se agregó soporte experimental NIR para el controlador clásico Gallium3D R600 con soporte para sombreadores geométricos, de fragmentos, de vértices y de teselación.
• Se ha agregado un parche al controlador Vulkan RADV debido a la optimización del trabajo con memoria, lo que aumenta el rendimiento de los juegos Id Tech en sistemas con APU AMD.
• En Panfrost, el controlador implementó el soporte experimental OpenGL ES 3.0 y brindó soporte para la GPU de renderizado 3D Bifrost (Mali G31). Se ha preparado una implementación inicial de un compilador de sombreadores que admite el conjunto de instrucciones internas Bifrost específicas de GPU.
• El controlador TURNIP Vulkan que se está desarrollando para las GPU Qualcomm Adreno ha agregado soporte para los sombreadores geométricos y los chips Adreno 650.
• En Gallium3D-driver LLVMpipe, que proporciona representación de software, había soporte para sombreadores tesselyatsionnyh.

Finalmente si quieres conocer mas al respecto, puedes consultar el registro completo de cambios en el siguiente enlace. 

¿Cómo instalar los drivers de video Mesa en Linux?

Los paquetes de Mesa se encuentran en todas las distribuciones de Linux, por lo que su instalación puede realizarse ya sea descargando y compilando el código fuente (toda la información al respecto aquí) o de una forma relativamente sencilla, la cual depende de la disponibilidad dentro de los canales oficiales de tu distribución o de terceros.

Para los que son usuarios de Ubuntu, Linux Mint y derivados pueden añadir el siguiente repositorio en donde los controladores son actualizados de manera rápida.

sudo add-apt-repository ppa:paulo-miguel-dias/mesa -y

Ahora vamos a actualizar nuestro listado de paquetes y repositorios con:

sudo apt update

Y finalmente podemos instalar los drivers con:

sudo apt upgrade

Para el caso de los que son usuarios de Arch Linux y derivados estos los instalamos con el siguiente comando:

sudo pacman -S mesa mesa-demos mesa-libgl lib32-mesa lib32-mesa-libgl

Para quienes sean usuarios de Fedora 32 pueden utilizar este repositorio, por lo que deben de habilitar corp con:

sudo dnf copr enable grigorig/mesa-stable

sudo dnf update

Finalmente, para los que son usuarios de openSUSE, pueden instalar o actualizar tecleando:

sudo zypper in mesa

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

Hace menos de un año, la compañía de la frambuesa lanzó la Raspberry Pi 4 Model B. Fue una actualización importante que mejoró puntos como su conectividad, contando con, entre otras cosas, USB-C para la alimentación, 2 puertos micro HDMI, 2 puertos USB 2.0 y otros 2 puertos USB 3.0, además del Ethernet y Jack para audio. También aumentó su RAM, habiendo disponible un modelo superior con hasta 4GB de RAM. Si esto no es suficiente para ti, ahora han lanzado algo que quizá te interese.

El nuevo modelo de la Raspberry Pi 4 ha llegado con 8GB de RAM. Hasta ahora, las imágenes de sistemas operativos para la Raspberry usaban 32-bits, pero con extensiones LPAE para el kernel, permitiendo direccionar mayor cantidad de memoria como los nativos de 64-bit. La buena noticia es que la compañía ha lanzado una beta de su sistema operativo para sistemas de 64-bit nativos: Raspberry Pi OS. De este modo, parece que abandonarán el nombre de Raspbian, el sistema operativo desarrollado por la compañía para sus placas que está basado en Debian.

La nueva Raspberry Pi 4 sigue con arquitectura ARM

Aunque es cierto que los 8GB no es la única novedad que trae debajo del brazo la Raspberry Pi 4, sí lo es que cambia poco más. Esta versión incluye un nuevo empaquetado y algunos componentes nuevos, como switch e inductores para el suministro de energía. Por todo lo demás, se mantiene como la versión lanzada hace ahora 11 meses, con un talón de Aquiles muy importante para los que quieran usar la Raspberry como una especie de mini-ordenador de escritorio.

Tanto la nueva placa como Raspberry Pi OS siguen basándose en ARM, por lo que sólo podrá usar aplicaciones que estén desarrolladas para esta arquitectura. Por lo tanto, si estás pensando en usar las últimas versiones de Firefox o Chrome, no vas a poder hasta que no lancen una versión para esta arquitectura. De hecho, en Raspbian siempre se ha podido instalar sólo la versión ESR de Firefox.

Eso sí, al César lo que es del César, y con las nuevas versiones de la placa y el sistema operativo podremos aprovechar más RAM que hasta hace 24 horas, en donde sólo podíamos usar hasta 3GB por las restricciones de los 32-bits. Si estás interesado, puedes comprarla desde aquí por 82.95€.

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

Después de tres meses de desarrollo, se presentó el lanzamiento de la nueva version de OpenSSH 8.3, en la cual se destaca una nueva protección añadida contra ataques scp, lo que permite al servidor transferir otros nombres de archivos que difieren de los solicitados (a diferencia de la vulnerabilidad anterior, el ataque no permite cambiar el directorio seleccionado por el usuario o la máscara global).

En SCP, el servidor decide qué archivos y directorios enviar al cliente y el cliente solo verifica la exactitud de los nombres de los objetos devueltos. La esencia del problema identificado es que si falla la llamada al sistema de tiempos, el contenido del archivo se interpreta como metadatos de archivo.

Cuando se conecta a un servidor controlado por un atacante, esta función se puede usar para guardar otros nombres de archivo y otros contenidos en el FS del usuario al copiar usando scp en configuraciones que provocan fallas en los tiempos. Por ejemplo, cuando los tiempos están deshabilitados por la política de SELinux o el filtro de llamadas del sistema.

Se estima que la probabilidad de ataques reales es mínima, ya que en configuraciones típicas la llamada de tiempo no falla. Además, el ataque no pasa desapercibido: cuando se llama a scp, se muestra un error de transmisión de datos.

Adiós a SHA-1

Además los desarrolladores de OpenSSH también advirtieron una vez más sobre la próxima transferencia a la categoría de algoritmos obsoletos que usan hash SHA-1, debido a un aumento en la eficiencia de los ataques de colisión con un prefijo dado (el costo de la selección de colisión se estima en alrededor de $ 45 mil).

En uno de los siguientes problemas, planean deshabilitar por defecto la capacidad de usar el algoritmo de firma digital de clave pública ssh-rsa, que se menciona en el RFC original para el protocolo SSH y sigue siendo generalizado en la práctica.

Posibles candidatos

Para facilitar la transición a nuevos algoritmos en OpenSSH en una de las próximas versiones, la configuración UpdateHostKeys se habilitará de manera predeterminada, lo que cambiará automáticamente a los clientes a algoritmos más confiables.

Entre los algoritmos recomendados para la migración están: rsa-sha2-256/512 basado en RFC8332 RSA SHA-2 (compatible con OpenSSH 7.2 y utilizado de forma predeterminada), ssh-ed25519 (compatible con OpenSSH 6.5) y ecdsa-sha2-nistp256 / 384/521 basado en RFC5656 ECDSA (compatible con OpenSSH 5.7).

Otros cambios

Desde el último número, «ssh-rsa» y «diffie-hellman-group14-sha1» se han eliminado de la lista CASignatureAlgorithms, que define los algoritmos válidos para firmar digitalmente nuevos certificados, ya que el uso de SHA-1 en los certificados conlleva un riesgo adicional debido a que el atacante tiene tiempo ilimitado para buscar colisiones para un certificado existente, mientras que el tiempo de ataque en las claves del host está limitado por el tiempo de espera de conexión (LoginGraceTime).

De los demas cambios que se destacan de esta nueva version son:

• En sftp, el procesamiento «-1» se detiene, de forma similar a ssh y scp, que fue previamente aceptado pero ignorado.
• En sshd cuando se usa IgnoreRhosts, ahora se proporcionan tres opciones: «yes» para ignorar rhosts/shosts, «no» para considerar rhosts/shosts y «shosts-only» que es permitir «.shosts», pero deshabilita «.rhosts».
• En ssh, el procesamiento de la sustitución% TOKEN se proporciona en la configuración LocalFoward y RemoteForward utilizada para redirigir los sockets Unix.
• Está permitido descargar claves públicas de un archivo no cifrado con una clave privada, si no hay un archivo separado con una clave pública.
• Si el sistema tiene libcrypto en ssh y sshd, ahora usa la implementación del algoritmo chacha20 de esta biblioteca, en lugar de la implementación portátil incorporada, que tiene un rendimiento inferior.
• Se implementó la capacidad de volcar el contenido de la lista binaria de certificados revocados al ejecutar el comando «ssh-keygen -lQf/path».
• La versión portátil implementa definiciones del sistema en las cuales las señales con la opción SA_RESTART interrumpen la selección;
• Problemas de compilación resueltos en sistemas HP/UX y AIX.
• Se corrigieron problemas de compilación para seccomp sandbox en algunas configuraciones de Linux.
• La definición de la biblioteca libfido2 se ha mejorado y los problemas de compilacion se han resuelto con la opción –with-security-key-builtin.

¿Como instalar OpenSSH 8.3 en Linux?

Para quienes estén interesados en poder instalar esta nueva versión de OpenSSH en sus sistemas, de momento podrán hacerlo descargando el código fuente de este y realizando la compilación en sus equipos.

Esto es debido a que la nueva versión aún no se ha incluido dentro de los repositorios de las principales distribuciones de Linux. Para obtener el código fuente, puedes hacer desde el siguiente enlace.

Hecha la descarga, ahora vamos a descomprimir el paquete con el siguiente comando:

tar -xvf openssh-8.3.tar.gz

Entramos al directorio creado:

cd openssh-8.3

Y podremos realizar la compilación con los siguientes comandos:

./configure --prefix=/opt --sysconfdir=/etc/ssh
make
make install

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

La semana pasada, los desarrolladores de Microsoft anunciaron diversas mejoras significativas en el subsistema WSL (Windows Subsystem for Linux), que permite que aplicaciones de Linux se ejecuten en Windows. Ya que a partir de la actualización de mayo de Windows 10, la primera instalación del entorno Linux utilizará la capa WSL2 de forma predeterminada.

El entorno WSL2 se ejecuta en una imagen de disco (VHD) separada con el sistema de archivos ext4 y el adaptador de red virtual. El kernel de Linux en WSL2 no se incluirá en la imagen de instalación de Windows, pero Windows lo cargará dinámicamente y lo mantendrá en la forma actual, de forma similar a cómo se instalan y actualizan los controladores de gráficos. Para instalar y actualizar el kernel, se utilizará el mecanismo estándar de Windows Update.

El núcleo propuesto para WSL2 se basa en el lanzamiento del núcleo Linux 4.19, que se ejecuta en un entorno Windows utilizando una máquina virtual que ya está en uso en Azure.

Los parches específicos de WSL2 utilizados en el núcleo incluyen optimizaciones para reducir el tiempo de inicio del núcleo, reducir el consumo de memoria, devolver Windows a la memoria liberada por los procesos de Linux y dejar el conjunto mínimo de controladores y subsistemas necesarios en el núcleo.

Ya es posible ejecutar aplicaciones gráficas en WSL

Además de lo mencionado, otra de las novedades que se destaca es el soporte para inicial para aplicaciones de Linux con una interfaz gráfica «WSU GPU».

El soporte se implementa mediante la virtualización del acceso a la GPU y la provisión de controladores a través de los cuales pueden funcionar los subsistemas gráficos regulares de las distribuciones de Linux, incluidos los basados ​​en Wayland. Las aplicaciones gráficas de Linux y Windows pueden ejecutarse lado a lado en el escritorio de Windows.

Se ha preparado un controlador dxgkrnl abierto para el kernel de Linux, que proporciona un dispositivo /dev/dxg con servicios que repiten el modelo de controlador de pantalla de Windows (WDDM) D3DKMT del kernel de Windows. El controlador establece una conexión a la GPU física utilizando el bus VM. Las aplicaciones de Linux tienen el mismo nivel de acceso a GPU que las aplicaciones nativas de Windows sin compartir recursos entre Windows y Linux.

Además, la biblioteca libd3d12.so se proporciona para Linux, que proporciona la API gráfica completa de Direct3D 12.

La biblioteca libd3d12.so está construida a partir del mismo código que la implementación nativa de Windows de Direct3D 12 y es completamente similar en funcionalidad a la biblioteca d3d12.dll.

También se proporciona una versión simplificada de la API DXGI (DirectX Graphics Infrastructure) en forma de la biblioteca DxCore (libdxcore.so). Las bibliotecas libd3d12.so y libdxcore.so son propietarias y se entregan solo en compilaciones binarias (montados en WSL como /usr/lib/wsl/lib), compatibles con Ubuntu, Debian, Fedora, Centos, SUSE y otras distribuciones basadas en Glibc.

El soporte para OpenGL en Mesa se proporciona a través de una capa que traduce las llamadas a la API de DirectX 12. El método para implementar la API de Vulkan aún se encuentra en la etapa de planificación.

En la primera etapa, en entornos WSL, se admitirán CUDA y DirectML, trabajando sobre la API D3D12 (por ejemplo, en un entorno Linux, puede ejecutar TensorFlow con un back-end para DirectML). El soporte de OpenCL es posible a través de una capa que realiza la asignación de llamadas en la API DirectX 12.

Microsoft está desarrollando su administrador compuesto utilizando el protocolo Wayland y basado en la base de código Weston. El administrador compuesto usa RDP-RAIL (Aplicación remota RDP integrada localmente) para organizar la salida de la interfaz de la aplicación Linux al escritorio principal de Windows. RDP-RAIL difiere del backend RDP disponible anteriormente en Weston en que el administrador compuesto no renderiza el escritorio en sí, sino que redirige las superficies individuales (wl_surface) a través del canal RDP RAIL para mostrarlas en el escritorio principal de Windows.

Además de que pronto se admitirá una instalación WSL con el simple comando wsl.exe –install.

Finalmente si quieres conocer mas al respecto, puedes consular los detalles en el siguiente enlace. 

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

Hace ya varios meses hablamos aquí en el blog sobre Reiser5, el cual es un sistema de archivos mantenido por Edward Shishkin y el cual se destaca por incluir la innovación en el escalado paralelo, que se lleva a cabo no a nivel de bloque, sino a través del sistema de archivos.

Reiser5 es una versión sustancialmente revisada del sistema de archivos ReiserFS, en la cual se implementa el soporte para volúmenes lógicos escalables paralelos, lo que permite una distribución eficiente de datos a través de un volumen lógico.

Ahora, en noticias mas recientes, Eduard Shishkin anunció nuevas características que se están desarrollando como parte del proyecto Reiser5.

De las innovaciones recientes, se ha observado que el usuario puede agregar un pequeño dispositivo de bloque de alto rendimiento (por ejemplo, NVRAM), llamado disco proxy, a un volumen lógico relativamente grande compuesto por discos de bajo presupuesto. Esto dará la impresión de que todo el volumen está compuesto por los mismos dispositivos de alto rendimiento que el «disco proxy».

El método implementado se basó en una simple observación de que, en la práctica, la escritura en un disco no se realiza constantemente y la curva de carga de E/S tiene una forma de pico. En el intervalo entre tales «picos», siempre existe la oportunidad de volcar datos de un disco proxy sobrescribiendo todos los datos (o solo una parte) en el almacenamiento principal «lento» en segundo plano. Por lo tanto, la unidad proxy siempre está lista para recibir una nueva pieza de datos.

Inicialmente, esta técnica (conocida como Burst Buffers) se originó en el campo de la informática de alto rendimiento (HPC). Pero resultó ser que también demandaba aplicaciones ordinarias, especialmente para aquellas que imponen altas exigencias a la integridad de los datos (por lo general, este es un tipo diferente de base de datos). Dichos cambios se realizan atómicamente por cualquier aplicación en cualquier archivo, a saber:

• Primero se crea un nuevo archivo que contiene los datos modificados;
• Entonces este nuevo archivo se escribe en el disco usando fsync (2);
• Después de eso, el nuevo archivo cambia de nombre al antiguo, lo que libera automáticamente los bloques ocupados por datos antiguos.

Todos estos pasos, en un grado u otro, causan una disminución significativa en el rendimiento en cualquier sistema de archivos. La situación mejora si el nuevo archivo se escribe primero en un dispositivo dedicado de alto rendimiento, que es exactamente lo que sucede en el sistema de archivos Burst Buffers.

En Reiser5, está previsto enviar opcionalmente no solo nuevos bloques lógicos del archivo al disco proxy, sino también todas las páginas sucias en general. Además, no solo páginas con datos, sino también con metadatos, que se registran en los pasos (2) y (3).

Los discos proxy son compatibles en el contexto del trabajo regular con los volúmenes lógicos Reiser5 anunciados a principios de año. Es decir, el sistema agregado «disco proxy – almacenamiento primario» es un volumen lógico ordinario, con la única diferencia de que el disco proxy tiene prioridad sobre otros componentes del volumen en la política de asignación de direcciones de disco.

Agregar un disco proxy a un volumen lógico no va acompañado de ningún reequilibrio de datos, y su eliminación se produce de la misma manera que la eliminación de un disco normal. Todas las operaciones de disco proxy son atómicas.

Después de agregar un disco proxy, la capacidad total del volumen lógico aumenta en la capacidad de este disco.

El disco proxy debe limpiarse periódicamente, es decir volcar datos de él al almacenamiento principal. Después de alcanzar la estabilidad beta de Reiser5, se planea hacer que la limpieza sea automática (estará a cargo de un hilo especial del núcleo). En esta etapa, la responsabilidad de la limpieza recae en el usuario.

Si no hay espacio libre en el disco proxy, todos los datos se escriben automáticamente en el almacenamiento principal. Al mismo tiempo, el rendimiento general del FS se reduce por defecto (debido a la invocación constante del procedimiento de confirmación de todas las transacciones disponibles).

Fuente: https://marc.info

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

Un equipo de investigadores de la Universidad de Pekín, la Universidad de Tsinghua y la Universidad de Texas en Dallas dieron a conocer información sobre su trabajo realizado para poder identificar una nueva clase de ataques DoS a los cuales nombraron como «RangeAmp» y los cuales se basan en el uso del encabezado Range HTTP para organizar la amplificación del tráfico a través de la red de entrega de contenido (CDN).

La esencia del método es que, debido a la peculiaridad de procesar encabezados Range en muchos CDN, un atacante puede solicitar un byte de un archivo grande a través de CDN, pero el CDN descargará el archivo completo o un bloque de datos significativamente más grande del servidor de destino para el almacenamiento en caché.

El grado de amplificación del tráfico durante un ataque de este tipo, según la CDN, es de 724 a 43330 veces, lo que se puede utilizar para sobrecargar el tráfico de CDN entrante o reducir el ancho de banda del canal de comunicación final al sitio de la víctima.

El encabezado Range permite al cliente determinar el rango de posiciones en el archivo que se debe cargar en lugar de devolver el archivo completo.

Por ejemplo, el cliente puede especificar «Rango: bytes = 0-1023» y el servidor transmitirá solo los primeros 1024 bytes de datos. Esta característica es muy solicitada cuando se descargan archivos grandes: el usuario puede pausar la descarga y luego continuarla desde la posición interrumpida. Al especificar «bytes = 0-0», el estándar prescribe dar el primer byte en el archivo, «bytes = -1» – el último, «bytes = 1-» – desde 1 byte hasta el final del archivo. Puede transferir varios rangos en un encabezado, por ejemplo, «Rango: bytes = 0-1023.8192-10240».

Además, se propuso una segunda opción de ataque (se llama ataque RangeAmp Overlapping Byte Ranges (OBR), destinada a aumentar la carga de la red cuando el tráfico se reenvía a través de otro CDN, que se utiliza como proxy (por ejemplo, cuando Cloudflare actúa como el frontend (FCDN) y Akamai actúa como el backend (BCDN)). El método se asemeja al primer ataque, pero está localizado dentro de las redes CDN y le permite aumentar el tráfico cuando accede a través de otras CDN, lo que aumenta la carga en la infraestructura y reduce la calidad del servicio.

La idea es que el atacante envíe varios rangos a la solicitud de rango de CDN, como «bytes = 0-, 0-, 0 -…», «bytes = 1-, 0-, 0 -…» o » bytes = -1024,0-, 0 -… «.

Las solicitudes contienen una gran cantidad de rangos «0-«, lo que implica el retorno del archivo desde cero hasta el final. Debido al análisis de rango incorrecto cuando el primer CDN se refiere al segundo, se devuelve un archivo completo a cada banda «0-» (los rangos no se agregan, pero se ordenan secuencialmente) si la duplicación e intersección de rangos están presentes en la solicitud de ataque enviada originalmente. El grado de amplificación del tráfico en dicho ataque varía de 53 a 7432 veces.

El estudio examinó el comportamiento de 13 CDN: Akamai, Alibaba Cloud, Azure, CDN77, CDNsun, Cloudflare, CloudFront, Fastly, G-Core Labs, Huawei Cloud, KeyCDN, StackPath y Tencent Cloud.

«Desafortunadamente, aunque les enviamos correos electrónicos varias veces y tratamos de comunicarnos con sus servicios al cliente, StackPath no proporcionó ningún comentario», dijo el equipo de investigación.

«En general, hemos hecho todo lo posible para informar de manera responsable las vulnerabilidades y proporcionar soluciones de mitigación. Los proveedores de CDN relacionados han tenido casi siete meses para implementar técnicas de mitigación antes de que se publicara este documento».

Todos los CDN revisados ​​permitieron el primer tipo de ataque en el servidor de destino. La segunda versión del ataque CDN resultó estar expuesta a 6 servicios, de los cuales cuatro pueden actuar como una interfaz en el ataque (CDN77, CDNsun, Cloudflare y StackPath) y tres en el papel de un back-end (Akamai, Azure y StackPath).

La mayor ganancia se logra en Akamai y StackPath, que permiten indicar más de 10 mil rangos en el encabezado Rango.

Los propietarios de CDN fueron notificados acerca de las vulnerabilidades hace aproximadamente 7 meses y para el momento de la divulgación pública de información, 12 de 13 CDN resolvieron los problemas identificados o expresaron su disposición a solucionarlos.

Fuente: https://www.liubaojun.org

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

Cada vez que alguno de los autores de Linux Adictos (creo que soy el que más lo hace) escribe un artículo positivo sobre Microsoft, muchos lectores reaccionan como si estuviéramos sirviendo sopa de ajo en la cena anual de los vampiros. Esto tiene origen en la actitud decididamente hostil de la empresa hacia el código abierto que mantuvo bien entrada la primera década del siglo XXI.

Muchos tenemos en claro cuál fue el motivo del cambio de la empresa, pero, al menos en mi caso, no había entendido la razón de la hostilidad. Después de todo, Linux jamás superó la cuota del 2% del mercado de escritorio.

Ahora Steven Sinofsky, ex responsable de Windows y Office dio una explicación sobre la causa detrás de declaraciones como esta de el ex máximo ejecutivo de la empresa Steve Ballmer:

Linux es un cáncer que se adhiere en un sentido de propiedad intelectual a todo lo que toca.

Sinofsky respondió en su cuenta de Twitter a una afirmación del principal consejero legal de Microsoft quien en una charla en el MIT aseguró:

Microsoft estaba en el lado equivocado de la historia cuando el código abierto explotó a principios de siglo, y puedo decir eso de mí personalmente.

Sinofsky considera que no es tan así, no es que Microsoft estuviera equivocado, si no que tenía un modelo de negocios basado en el software como propiedad intelectual, y que ese modelo tenía sentido cuando la empresa fue fundada.

Hasta no hace mucho tiempo la distribución de software costaba dinero. Pasó bastante tiempo desde la popularización de Internet hasta que todo el mundo (o al menos la mayor parte) tuviera acceso a una conexión decente en su hogar o trabajo. Los más antiguos de nuestros lectores recordarán cuando podías pedirle a Canonical que te mandara gratis un cd de Ubuntu. La otra forma era comprar una revista que regalara el cd o comprarlo en alguna tienda online.

En el sector corporativo, el software era parte de un combo con un costoso hardware que tenías que comprar o alquilar o parte de un servicio de consultoría que tenías que contratar.

Los orígenes del modelo de negocios de Microsoft

El ex responsable de Windows recuerda que a principios de los 70 los entusiastas de la electrónica compraban kits que les permitían armar sus propios proyectos (algo así como bisabuelos de Raspberry Pi o Arduino) que podían programarse. El software para programarlo se compartía libremente.

Bill Gates y su amigo Paul Allen crearon una versión del lenguaje de programación Basic para los equipos Altair. Su creación fue un éxito inmediato. Tan inmediato que su código fuente (impreso) se compartía sin parar.

Esto motivó la queja de Bill Gates quién hizo pública una carta en la que se quejaba de que habían invertido 40000 dólares en tiempo y dinero y solo habían conseguido recuperar una mínima parte por culpa de distribución ilegal.

Estamos hablando del primer producto de Microsoft como empresa.

No es de extrañar que durante 3 décadas la empresa viera como un peligro todo lo que amenazara su modelo de negocios basado en que la gente pague por cada copia del software. Más adelante otras compañías independientes basadas en el desarrollo de software como Corel o Adobe adoptaron un esquema similar y defendieron celosamente su propiedad intelectual.

De hecho, el código abierto no cuestiona el modelo de propiedad intelectual, simplemente aumenta la cantidad de cosas que se autoriza hacer al usuario.

El cambio de Microsoft

En realidad ni Linux ni las alternativas de código abierto fueron un problema para Microsoft en el escritorio. El problema apareció en los servidores.

Dice Sinofsky que Linux fue (y sigue siendo) mucho mejor que WindowsNT en los servidores. Por un tiempo, Microsoft pudo contar con la ventaja de que los clientes corporativos preferían el respaldo de una empresa a montar sus propias soluciones por mejor rendimiento y menos costos que tuvieran.

Todo cambió cuando IBM y otras empresas competidoras de Microsoft (junto a la aparición de licencias abiertas menos restrictivas que la GPL) descubrieron las ventajas de brindar servicios basados en el código abierto, junto a nuevas opciones de comercialización. La única ventaja de Microsoft en el sector más rentable del pastel se había terminado.

Para terminar de complicar la cosa, aparecen Google y Amazon que en lugar de distribuir software venden el servicio de ejecutar el software. ¿Para que ibas a comprar una licencia de Office si puedes usar el procesador de textos o enviar correos electrónicos desde tu navegador?. Y, en muchos casos gratis.

Tampoco vas a comprar la licencia de un sistema operativo para cada una de las computadoras de tu empresa cuando puedes ejecutar ese mismo sistema operativo en una máquina virtual desde cualquier computadora pagando solo por el tiempo que lo usas.

Con un modelo de negocios basado en la venta de licencias sin futuro, a Microsoft no le quedó más remedio que aceptar la realidad y apoyar al código abierto que está mejor preparado para brindar a los clientes lo que necesitan.

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

Kubernetes es un gran proyecto conocido por todos, especialmente para el despliegue y gestión de apps en contenedores. Y Markus Eisele, EMEA Developer Adoption Lead de Red Hat, tiene algunos detalles importantes para todos los interesados en aprender sobre él.

Y es que el desarrollo empresarial siempre ha sido uno de los grandes retos de la ingeniería informática, y en especial de empresas como Red Hat. Es por eso que en la última década se ha pasado de la arquitectura clásica de 3 niveles a una novedosa arquitectura con microservicios altamente distribuidos para conseguir recursos de infraestructura casi ilimitados para los proveedores de la nube pública. Además, dichos microservicios se pueden especializar en tareas muy específicas y simples, frente a los obsoletos servidores de apps pesados.

Estos microservicios implican una mejor eficiencia en cuanto a recursos consumidos, lo que supone otra gran ventaja. Además, es una de las mejores formas de desplegar estas apps a través de contenedores, como si de pequeñas máquinas virtuales se tratasen. Aunque la principal diferencia entre una MV y un contenedor es que el primero no tiene un sistema operativo, en vez de eso se ejecuta en un espacio de usuario del kernel del sistema operativo host, como si de una app se tratase. Esto también implica mayor seguridad.

Pero no todo iban a ser ventajas, ya que esta arquitectura necesita de muchos contenedores (uno por servicio o más), lo que significa que la forma en la que se gestionan y coordinan podría ser compleja y representar un mayor esfuerzo para el administrador del sistema. Es aquí donde Kubernetes entra en escena y lo hace todo mucho más fácil.

Configuración de un entorno nativo en Kubernetes

Kubernetes facilita la labor de los administradores, posibilitando una gestión de las apps y servicios más automatizada. Buscando una analogía, sería como la autoridad portuaria en un embarcadero, que posibilita que los barcos se muevan de forma simultanea dentro del espacio.  Es decir, en un inicio se podrían comparar las capacidades de Kubernetes con las de Java EE, ya que ambos ejecutan apps en hardware físico distribuido. No obstante, los contenedores se preocupan bien poco de los requisitos de la propia app.

Con Kubernetes se puede configurar un cluster escribiendo archivos de configuración en formato texto (YAML principalmente, aunque también admite JSON). En su interior estarán los parámetros o especificaciones de cada objeto definido para la gestión.

Hardware para la configuración local de Kubernetes

Para poder aprovechar las ventajas de la alta escalabilidad y fiabilidad que proporciona un cluster de Kubernetes, los desarrolladores y administradores se deben encargar de dotar al contenedor de suficientes recursos para que se pueda ejecutar.

Si se asume que un cluster tiene dos master nodes con 2 GB de RAM, 4 cores, y 2 worker nodes de 1 GB de RAM y 2 cores, entonces un cluster de Kubernetes necesitará de 6 GB de RAM y 12 cores como mínimo. Unos recursos que no todos los ordenadores de sobremesa pueden suministrar, aunque bien es cierto que este proyecto no está pensado para el escritorio.

No obstante, en la actualidad hay un número de entornos de aprendizaje más pequeños que posibilitan que los desarrolladores puedan desarrollar con Kubernetes en entornos locales. Ejemplos de ellos son MiniKube, MicroK8s, OpenShift CodeReady Cointainers, etc. Todos ellos clusters de 1 solo nodo para poderlos tener en un PC de sobremesa y cuya instalación puede hacerse en unos pocos minutos.

Para probar un servicio de entornos más complejo, normalmente hay que acudir a un cluster verdadero de Kubernetes. Pero la herramienta Code Ready Containers puede facilitar mucho la vida del desarrollador, incluyendo todo el kit de herramientas e instalación de un solo nodo de un cluster de Kubernetes.

La adopción del nativo en Kubernetes es un mundo diferente

Kubernetes ha venido para cambiar toda la experiencia de los desarrolladores, que ven cómo la forma de administrar estos servicios es totalmente diferente e integrada. Por ello, la adopción de Kubernetes se ha transformado en el siguiente paso lógico hacia la simplificación para el desarrollador.

Así mismo, Kubernetes posibilita una mayor flexibilidad, con ayuda y herramientas para el desarrollo productivo de nativo de Kubernetes, y nuevos y fascinantes desafíos…

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