Linus Torvalds habla sobre los usuarios comerciales de código fuente abierto

La semana pasada, Linus Torvalds continuó con una extensa entrevista por correo electrónico con Jeremy Andrews, socio fundador y director ejecutivo de Tag1.

En la primera parte de la entrevista en abril, Torvalds habló de todo, desde los chips ARM64 de Apple y los controladores Rust, hasta su propio entorno de trabajo desde casa basado en Fedora y sus pensamientos sobre los primeros días de Linux. Pero la segunda parte ofrece una visión más profunda de cómo piensa Torvalds, una visión personal de lo que compartiría con otros mantenedores de proyectos y algunas ideas sobre cómo conseguir que las empresas ayuden a hacer crecer el negocio.

Linus reveló cómo procedió cuando comenzó el proyecto:

“Todavía recuerdo los primeros días, cuando la gente me enviaba arreglos, y realmente no los aplicaba como arreglos, pero los leía, que entendía lo que la gente quería hacer y que lo hice yo mismo. Porque así comencé el proyecto, y así me sentí más cómodo y que conocía mejor el código ”. Linus también explicó que era importante aprender a delegar: “Dejé de hacerlo bastante rápido, porque básicamente soy un vago. Me volví muy bueno leyendo los parches y descubriendo lo que estaban haciendo, y luego los apliqué ”.

Linus también se esforzó por permanecer imparcial a medida que Linux crecía y se volvía más exitoso:

“Yo muy conscientemente no quería trabajar para una empresa de Linux, por ejemplo, mantuve Linux durante la primera década sin que fuera mi trabajo. Esto no es porque crea que los intereses comerciales son malos, sino porque quería asegurarme de que la gente me viera como una parte neutral y nunca me sentí como «la competencia». «

Si bien el código abierto ha tenido un gran éxito, muchos de los usuarios más grandes, como las empresas, hacen poco o nada para apoyar o contribuir a los proyectos de código abierto de los que dependen.

Continúa escribiendo:

“Y muchas de las grandes empresas de tecnología que utilizan el kernel terminan participando activamente en el proceso de desarrollo. A veces terminan haciendo mucho trabajo interno y no son muy buenos empujando las cosas hacia atrás (no nombraré nombres, y algunos de ellos realmente están tratando de hacerlo mejor), pero en realidad es muy alentador ver a las grandes empresas que están involucradas de manera muy abierta en el desarrollo básico upstream y son miembros importantes de la comunidad ”.

Cuando se le preguntó si el código abierto es sostenible o no, Linus respondió:

“Sí. Personalmente, estoy 100% convencido de que no solo el código abierto es sostenible, sino que para cuestiones técnicas complejas realmente necesita el código abierto solo porque el espacio del problema termina siendo demasiado complejo para ser manejado por una sola empresa. Incluso una empresa de tecnología grande y competente ”.

Clave para el éxito de los encargados del mantenimiento de proyectos de código abierto: «estar ahí TODO EL TIEMPO» y «estar abierto»

Cuando Andrews quiso saber qué hace que un proyecto de código abierto sea exitoso, Linus admitió:

“Realmente no sé cuál es la clave del éxito. Sí, Linux ha tenido mucho éxito y está claro que Git también ha comenzado con el pie derecho, pero todavía es muy difícil atribuirlo a una causa más profunda. ¿Quizás tuve suerte? ¿O fue porque de todas estas personas que necesitaban estos proyectos, yo fui el que se puso de pie, hizo el trabajo y comencé el proyecto? «

Pero Linus finalmente explicar» algunos puntos prácticos y con los pies en la tierra que yo personalmente considero importante si usted es un fabricante de software de código abierto «. Recomienda que una persona a cargo de un proyecto de código abierto esté «presente» todo el tiempo.

“Tienes que quedarte, tienes que estar ahí para los otros desarrolladores, y tienes que estar ahí TODO EL TIEMPO. Te encontrarás con problemas técnicos y será frustrante. Trabajará con personas que pueden tener ideas muy diferentes sobre cómo resolver estos problemas técnicos. Y los problemas técnicos son la parte más fácil, porque generalmente tienen soluciones técnicas, y a menudo se puede decir de manera bastante objetiva «esto es mejor / más rápido / más fácil / lo que sea» «.

La otra clave que explicó Linus es estar «abierto», «estar abierto a las soluciones de otras personas y no tener esta idea muy clara e inflexible de cómo se deben hacer las cosas». Pero Linus denuncia una de las formas de ser abierto:

“Es realmente fácil crear una especie de ‘camarilla’ de personas, donde tienes una camarilla interna que discute las cosas en privado, y luego realmente solo ves el resultado final (o marginal trabajar) a plena luz del día, porque todas las cosas importantes han sucedido dentro de una empresa o dentro de un grupo central de personas, y a los externos les resulta difícil penetrar estos clics y, a menudo, incluso les cuesta ver lo que está sucediendo en ese grupo principal porque era tan privado y exclusivo ”.

“Esta es una de las razones por las que realmente me gustan las listas de correo abiertas. No es una lista de «invitaciones». Ni siquiera tienes que registrarte para participar. Está realmente abierto. Y prácticamente todas las discusiones sobre desarrollo deberían estar allí ”.

Hablando de otras habilidades específicas necesarias para proyectos exitosos de código abierto, Linus explicó su experiencia. Según él, “no es el resultado de planificar y leer manuales de gestión, etc. La mayoría de las cosas sucedieron solas, y la estructura que tenemos hoy no proviene de un organigrama escrito, sino de personas que acaban de «encontrar su lugar». Como ya se mencionó anteriormente, Linus recomienda la delegación de tareas. También mencionó las habilidades de comunicación como «muy importantes».

Fuente: https://www.tag1consulting.com

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

Microsoft, Google y ARM se unen a la Bytecode Alliance para mejorar el desarrollo de WebAssembly

A fines de 2019, en un esfuerzo conjunto para hacer de WebAssembly un runtime de computación multiplataforma, las empresas como Mozilla, Fastly, Intel y Red Hat anunciaron el lanzamiento de Bytecode Alliance. Esta iniciativa construida alrededor de WebAssembly se centra en proporcionar un código de bytes predeterminado seguro que se puede ejecutar desde un navegador web, escritorio o IoT/plataforma incrustada.

WebAssembly ha sido promocionado como una arquitectura de conjunto de instrucciones virtuales con muchos casos de uso capaces de tomar código escrito en lenguajes de programación distintos de JavaScript y ejecutar ese código en una plataforma específica, al menos un navegador en este caso.

Esta solución también debería permitir que aplicaciones complejas, como videojuegos inmersivos en 3D, diseño computarizado o edición de imágenes y videos, funcionen de manera óptima en las plataformas de destino. Gracias a WebAssembly, los desarrolladores podrían, por ejemplo, codificar sus aplicaciones en C, C ++ o Rust y ejecutar estos programas a velocidad nativa en un navegador web, sin tener que volver a pasar por JavaScript con las limitaciones que esto impone.

Según los promotores de la iniciativa, el auge de la nube y los dispositivos IoT está provocando que los desarrolladores ejecuten código poco fiable en nuevos entornos, lo que plantea nuevos problemas, especialmente en términos de seguridad y portabilidad.

Bytecode Alliance deberá proporcionar una base para que los desarrolladores ejecuten con seguridad código no confiable en cualquier infraestructura, sistema operativo y dispositivo. Esta comunidad de código abierto se centrará en configurar un entorno de ejecución y cadenas de herramientas lingüísticas asociadas, incluidas cargo-wasi, wat y wasmparser, que brindan seguridad, eficiencia y modularidad en una amplia gama de arquitecturas y periféricos.

Y ahora se han unido nuevos integrantes de renombre, tales como Microsoft, Arm, DFINITY Foundation, Embark Studios, Google, Shopify y University of California San Diego.

En un comunicado, Bobby Holley, un distinguido ingeniero de Mozilla y miembro de la junta de Bytecode Alliance, describió el desarrollo de software actual como un conjunto de difíciles compensaciones.

“Si desea construir algo grande, no es realista crear todos los componentes desde cero”, dijo Holley. “Pero depender de una compleja cadena de suministro de componentes de otras partes permite que una falla en cualquier parte de esa cadena comprometa la seguridad y estabilidad de todo el programa. Mozilla ayudó a crear WebAssembly para permitir que la web creciera más allá de JavaScript y ejecutara más tipos de software a velocidades más rápidas. Pero a medida que madura Quedó claro que las propiedades técnicas de WebAssembly, en particular el aislamiento de la memoria, también tenían el potencial de transformar el desarrollo de software más allá del navegador. Varias otras organizaciones compartieron este punto de vista y nos unimos para lanzar Bytecode Alliance como una asociación industrial informal a fines de 2019 ”.

“Las herramientas como los contenedores pueden proporcionar cierto grado de aislamiento, pero agregan una sobrecarga sustancial y son inconvenientes de usar con granularidad por parte del proveedor. Y todas estas dinámicas refuerzan las ventajas de las grandes empresas que tienen los recursos para gestionar y auditar cuidadosamente sus cadenas de suministro ”

Además se menciona que los miembros fundadores compartieron un montón de herramientas WASM con Bytecode Alliance, incluidos entornos de tiempo de ejecución, componentes de tiempo de ejecución y más.

Ahora, con Microsoft, Google y Mozilla a bordo, Bytecode Alliance cuenta con el apoyo de tres de los cuatro principales proveedores de navegadores. El editor de Safari Apple es el único proveedor importante de navegadores que falta. Con un apoyo más amplio, la alianza se da a sí misma una mejor oportunidad de supervivencia a largo plazo.

«WebAssembly y la nueva especificación WebAssembly System Interface (WASI) permiten que las soluciones nativas de la nube se vuelvan más seguras de forma predeterminada y ayuden a solucionar problemas de TI en una variedad de entornos», dijo Ralph Squillace, gerente senior de programas de Microsoft en Azure Core Upstream y miembro de la junta de Bytecode Alliance.

El trabajo de Microsoft en WebAssembly incluye su lanzamiento de Blazor WebAssembly, que permite a los desarrolladores de C# y .NET crear aplicaciones que se ejecutan en el navegador con WebAssembly, pero que funcionan como una aplicación de escritorio nativa, también conocida como aplicaciones web progresivas.

Blazor WebAssembly es una de las cuatro versiones del Blazor Project de Microsoft, que incluye la representación de Blazor Server compatible para aplicaciones web, un renderizador Electron y los enlaces experimentales Mobile Blazor recientemente lanzados para crear aplicaciones iOS y nativas de Android usando C # y .NET en lugar de JavaScript.

Fuente: https://bytecodealliance.org

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

Bottlerocket 1.1.0 llega con Kernel 5.10, SELinux, mejoras y mas

Bottlerocket

Se acaba de dar a conocer la liberación de la nueva versión de la distribución de Linux «Bottlerocket 1.1.0» la cual es desarrollada con la participación de Amazon para ejecutar contenedores aislados de manera eficiente y segura.

La distribución y los componentes de control están escritos en el lenguaje Rust y se distribuyen bajo las licencias MIT y Apache 2.0. Admite la ejecución de Bottlerocket en los clústeres de Amazon ECS y AWS EKS Kubernetes, así como la creación de versiones y revisiones personalizadas que permiten diferentes herramientas de tiempo de ejecución y orquestación de contenedores.

La distribución proporciona una imagen de sistema indivisible actualizada de forma automática y atómica que incluye el kernel de Linux y un entorno de sistema mínimo que incluye solo los componentes necesarios para ejecutar contenedores.

El entorno utiliza el gestor del sistema systemd, biblioteca Glibc, Buildroot, gestor de arranque GRUB, un runtime para containerd, contenedores de la plataforma Kubernetes, AWS-iam-autenticador y el agente de Amazon ECS.

Las herramientas de orquestación de contenedores se envían en un contenedor de administración separado que está habilitado de manera predeterminada y administrado a través de la API y el Agente de AWS SSM. La imagen base carece de un shell de comandos, servidor SSH e idiomas interpretados (por ejemplo, sin Python o Perl): las herramientas para el administrador y las herramientas de depuración se mueven a un contenedor de servicios separado, que está deshabilitado de manera predeterminada.

La diferencia clave con respecto a distribuciones similares como Fedora CoreOS, CentOS/Red Hat Atomic Host es el enfoque principal en proporcionar la máxima seguridad en el contexto de fortalecer el sistema contra posibles amenazas, lo que dificulta la explotación de vulnerabilidades en los componentes del sistema operativo y aumenta el aislamiento de contenedores. Los contenedores se crean utilizando los mecanismos estándar del kernel de Linux: cgroups, namespaces y seccomp.

La partición root se monta como de solo lectura y la partición de configuración /etc se monta en tmpfs y se restaura a su estado original después de reiniciar. No se admite la modificación directa de archivos en el directorio /etc, como /etc/resolv.conf y /etc/containerd/config.toml, para guardar permanentemente la configuración, usar la API o mover la funcionalidad a contenedores separados.

Principales novedades de Bottlerocket 1.1.0

En esta nueva versión de la distribución se ha incluido al kernel de Linux 5.10 con la finalidad de poder usarlo en nuevas variantes junto con las dos nuevas versiones de las distribuciones aws-k8s-1.20 y vmware-k8s-1.20 compatibles con Kubernetes 1.20.

En estas variantes, así como en la versión actualizada de aws-ecs-1, está involucrado un modo de bloqueo que está configurado en «integridad» de forma predeterminada (bloquea la capacidad de realizar cambios en el kernel en ejecución desde el espacio del usuario). Se eliminó el soporte para aws-k8s-1.15 basado en Kubernetes 1.15.

Además, Amazon ECS ahora admite el modo de red awsvpc, que le permite asignar interfaces de red y direcciones IP internas independientes para cada tarea.

Se agregaron configuraciones para administrar varias configuraciones de Kubernetes TLS bootstrap, incluidos QPS, límites de grupo y la configuración de Kubernetes cloudProvider para permitir el uso fuera de AWS.

En el contenedor de arranque se proporciona con SELinux para restringir el acceso a los datos del usuario, asi como una división a las reglas de política de SELinux para sujetos de confianza.

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

  • Ahora se puede hacer que Kubernetes cluster-dns-ip sea opcional para admitir el uso fuera de AWS
  • Se cambiaron los parámetros para respaldar un escaneo CIS saludable
  • Se añadió la utilidad resize2fs.
  • Se generó un ID de máquina estable para invitados de VMware y ARM KVM
  • Se habilitó el modo de bloqueo del kernel de «integridad» para la variante de vista previa de aws-ecs-1
  • Eliminar la anulación del tiempo de espera de inicio del servicio predeterminado
  • Evitar que los contenedores de arranque se reinicien
  • Nuevas reglas de udev para montar CD-ROM solo cuando hay medios presentes
  • Soporte para la región de AWS ap-noreste-3: Osaka
  •  URI de contenedor de pausa con variables de plantilla estándar
  • Capacidad poder obtener IP de DNS del clúster cuando esté disponible

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

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