Creando lo Imposible: Virtualización X86 en el Navegador con WebAssembly

Así que, hola a todos. Y me gustaría comenzar agradeciendo a la organización por invitarme aquí y darme la oportunidad de compartir algo de la tecnología que construimos para ustedes. Y especialmente hoy, es un día especial para mí, porque es mi cumpleaños. Y muchas gracias por venir aquí a celebrarlo conmigo, lo aprecio mucho.

Así que soy Alessandro Pignotti, fundador y CTO de Leaning Technologies. Nací y crecí en Roma, y me mudé a Pisa para mis estudios, y luego me mudé aquí en 2014. Y he sido un orgulloso habitante de Ámsterdam desde entonces. Si lo desean, pueden seguirme en Twitter, pero les recomendaría no contener la respiración mientras esperan que publique algo.

Entonces, ¿qué hacemos? Somos una pequeña empresa que se especializa en el nicho de soluciones compiladas a JavaScript y compiladas a WebAssembly. En este pequeño nicho, creo que hacemos cosas bastante interesantes. Y a lo largo de los años, hemos lanzado tres productos diferentes. Uno de ellos fue Chirp, que es una herramienta de C++, compilador de JavaScript y WebAssembly. El segundo fue ChirpJ, que no es solo un compilador para Java, realmente. Es más como una máquina Java completa que puede ejecutarse en el navegador. Y podemos usarlo para ejecutar incluso aplicaciones Java completamente gráficas en el navegador ahora mismo. Y luego decidimos dar un paso más allá. Y creamos ChirpX. Y ChirpX no es solo un producto, realmente. Ahora mismo, lo consideramos más como una tecnología. Es una solución muy genérica que hará un montón de cosas diferentes. Y como primer experimento para ver cómo podemos hacer de esto eventualmente un producto que podamos vender, construimos WebVM, que es solo una de las posibles cosas que podemos construir con esto. Y hablaremos sobre eso. Porque, ya saben, cada uno de estos productos probablemente requerirá su propia charla de un par de horas. Tenemos 20 minutos, así que necesitamos cortar e ir al grano. Entonces, ChirpX es una tecnología para ejecutar de forma segura código binario en el navegador, ¿de acuerdo? Y hay tres ideas principales que seguimos al hacer esto. Queríamos construir algo que fuera genérico, robusto y escalable. Creo que pueden tener su propia intuición sobre lo que significan estos términos, pero me adentraré más tarde sobre lo que quiero decir exactamente al usar estas palabras. Y en términos prácticos, lo que ChirpX es, es una aplicación de C++ que escribimos desde cero. La escribimos nosotros mismos, y la compilamos a JavaScript WebAssembly usando Chirp, usando nuestro otro producto, para que pueda ejecutarse en el navegador. Y sé que es agradable hablar sobre las cosas, pero también es agradable ver cómo las cosas realmente funcionan en la práctica.

Y todos me recomendaron no hacer una demostración en vivo, pero, ya saben, ¿quién soy yo para seguir buenos consejos? Intentemos esto. Así que lo que me gustaría hacer, me gustaría demostrarles que podemos ejecutar un sistema completamente virtualizado en el navegador. Y lo que tengo aquí ahora mismo es Bash, el shell, ejecutándose desde una distribución Debian en el navegador. Para probarlo, puedo, por ejemplo, listar un sistema de archivos y hay un montón de cosas que puedes esperar de un sistema real en ejecución.

Pero me gustaría demostrar que realmente puedo ejecutar un binario que nunca se ha visto antes. Y a través de eso, supongo que simplemente escribiré uno. Y no sé ustedes, pero cuando quiero escribir un binario desde cero, lo primero que hago es abrir mi editor de texto. Así que... Es increíblemente difícil escribir correctamente en el escenario. Así que tenemos Vim, está funcionando, y ahora puedo escribir un caso de prueba muy pequeño. Y lo que está sucediendo ahora mismo es que todo esto está ejecutándose desde los binarios XSAT que ejecutas en tu propia computadora. Y planeo hacer una palabra L muy simple. Para hacer algo que no sea completamente trivial, en realidad quiero, en lugar de devolver el habitual retorno cero o código que le dirá al sistema que el ejecutable se completó exitosamente, quiero devolver un código de error. Quiero ver si el shell puede manejar eso. Así que probemos esto. Genial.

Ahora quiero compilar esto. Para compilar código C++. Código C, en realidad, por supuesto usaré GCC. Y también podemos habilitar algunas optimizaciones porque nunca se sabe. Y esto parece correcto. Bien. ¿Qué está pasando en el fondo aquí? Así que GCC es un ejecutable bastante grande, y actualmente el sistema está cargando los datos requeridos desde la red. Y estos datos vienen en bloques porque esto es en realidad una implementación completa de X2 que se ejecuta desde un dispositivo de disco que está respaldado por un CDN. Está respaldado por Cloudflare. Y esta ejecución está realmente completada. Podemos probar si esto incluso puede ejecutarse. Hace lo que esperamos que haga. Verifiquemos el código de error. Es lo que esperamos.

Así que esto es bastante interesante, creo, pero tal vez lo dije yo mismo antes, ¿verdad? Podemos compilar C++ WebAssembly, así que tal vez pienses que hay algún truco aquí. Que tal vez esta es una versión especial de GCC que puede generar mágicamente código que se ejecuta nativamente en el navegador. Y me gustaría demostrarte que este no es el caso. Que a través de eso realmente podemos preguntar al sistema. Entonces, ¿cuál es el tipo de archivo que acabamos de ejecutar? El sistema dice que es ELF, que es un formato binario de archivo ejecutable. Así que Linux 32-bit intel x86, que es lo que esperamos. Y como última prueba, incluso podemos mostrar el código en sí. Podemos volcar este programa que construimos. Podemos echar un vistazo y este es código binario, que es lo que esperarías.

Y bien, pero, quiero decir, hay otras formas de ejecutar código C++ en el navegador. Entonces, ¿por qué vamos a optar por toda esta complejidad? Y el problema es que es complicado, realmente. Así que es cierto que puedes compilar C++ en el navegador. No está claro que puedas compilar cualquier aplicación sin intervención manual. Pero incluso dejando esto de lado, el punto es que esta es una solución extremadamente genérica, ¿verdad?

Así que ahora podemos intentar algo completamente diferente. Probemos Python. Así que lo que he hecho ahora, he configurado el intérprete de Python y puedo realmente escribir comandos directamente en la consola una vez más. Haré lo mismo que he hecho antes. Hola. Esto también es bastante fácil. Puedo devolver otro código, que se mostrará en pantalla. Y, OK, Python es agradable, pero también es un ejecutable relativamente simple. Es solo un intérprete en general, no hace mucho más que eso. Así que probemos algo más divertido. Probemos si podemos intentar ejecutar JavaScript. Y también abriré de nuevo Vim. También abriré una vez más y escribiré mi caso de prueba simple, que está mal escrito. Y además, para no hacer algo completamente obvio, voy a habilitar la opción de imprimir código. Así que lo que hace esta opción es que realmente imprime todo el código nativo que Node.js y realmente el motor interno, que es V8, el mismo motor que se usa en Chrome, está generando solo para ejecutar este pequeño ejemplo. Ten en cuenta que lo que estás viendo no es algo que suceda especialmente porque se está ejecutando en este entorno virtualizado. Esto sucede cada vez que inicias Node.js. Y lo que encontré interesante es que lo que esto te muestra es que ChirpX es realmente capaz de manejar un ejecutable bastante sofisticado, porque este código se está generando en tiempo de ejecución. Esto nunca antes había sido visto por el motor. Simplemente se ha generado, leído en memoria y eventualmente ejecutado. Entonces, ¿cómo construimos algo? Oh, por cierto, este es un sitio web en vivo. Si quieres jugar con esto, puedes ir y jugar con eso, y si tienes errores, puedes reportarlos en GitHub, y los miembros de mi equipo se encargarán de ellos. Así que intentemos definir esta terminología que hemos estado usando antes. Al construir algo genérico, quiero decir que queremos hacer algo que no requiera ningún preprocesamiento, ningún metadato especial. No deberíamos tener un compilador especial o opciones de compilación especiales, no deberíamos tener bibliotecas especiales, nada de esto. Lo que hacemos es que tomamos los binarios tal como salen de los paquetes de Debian y los usamos.

Rápido significa poder ejecutar Node.js, ya que necesitamos poder dar una situación donde el código no solo se genera en tiempo de ejecución, sino que también se cambia en tiempo de ejecución, tal vez modificado en el lugar, o tal vez simplemente eliminado y puesto en otro lugar. Esto también sucede al ejecutar código con V8, porque el código en sí es recolector de basura y se mueve por la memoria con el tiempo.

Y luego queríamos construir algo escalable. Lo que esto significa es que, aunque les mostré solo un montón de palabras amarillas, esto puede funcionar en bases de código mucho más grandes. Queríamos construir algo que pueda trabajar con programas en el mundo real, lo que significa que queremos apoyar la multiprocesamiento, multihilo, miles de archivos, y todo tipo de características que son efectivamente utilizadas por programas que son reales, no solo juguetes.

Para darles una idea de lo que hemos visto hasta ahora, Chirpx es este entorno en el que toda la ejecución ocurre. Y es todo del lado del cliente. Todo está en el navegador. No hay un componente del lado del servidor haciendo la ejecución por nosotros. Esto no es un truco. Y lo primero que se inicia es Bash. Así que Bash es el proceso padre. Y luego Bash en sí puede generar subprocesos, procesos hijos, y les mostré GCC y Python, y todos estos son completamente independientes de otros espacios. Tienen su propio código y tienen sus propios datos.

Pero el problema es que, desde el punto de vista del sistema, realmente no sabemos qué es código y qué es datos. Estas dos cosas son solo bytes. Es solo datos antiguos en memoria. Y para resolver este problema, tenemos en realidad un motor de ejecución de dos niveles. El primer nivel es un intérprete, y el segundo nivel es un motor JIT real que puede generar código altamente optimizado. Y el intérprete es capaz de ejecutar código sin ninguna información. Comenzará desde la primera instrucción y la pasará a la siguiente y así sucesivamente. Y mientras hace esto, también construirá los metadatos internamente sobre cómo está estructurado el código. Y con eso, ahora es posible activar el motor JIT para generar código optimizado y robusto a partir de esto.

Y eventualmente, todas estas aplicaciones necesitarán llegar al navegador de alguna manera porque necesitamos mostrar texto en pantalla, por ejemplo. Y esto sucede como se esperaría en un sistema nativo a través de llamadas al sistema. Y las llamadas al sistema, las implementamos nosotros mismos. Así que lo que han visto hasta ahora no es un kernel de Linux. Es un ABI compatible con Linux, por lo que puede ejecutar cualquier ejecutable de Linux, pero no es Linux en sí. Y la llamada al sistema es el lugar donde nos detenemos e implementamos la llamada al sistema manualmente para que puedan interactuar con el navegador. Y ahora podrían preguntarse por qué no ejecutamos todo en el JIT, ya que es más probablemente más eficiente.

Y el problema allí es que esto en realidad no es necesariamente el caso. La forma en que lo veo, la compilación JIT es prácticamente una inversión, y quieres asegurarte de recuperar tu inversión. Es realmente una inversión de tiempo de ejecución. Pagas algo de tiempo de ejecución ahora con la esperanza de que en el futuro el código del sistema se ejecute más rápido para que en general también ejecutes más rápido.

Y solo JIT y todo sería ineficiente. Así que en realidad, gracias al intérprete, podemos construir estos metadatos. Construimos lo que llamamos el gráfico de flujo de control del programa. Y luego, cuando los bloques de código se vuelven suficientemente calientes, se ejecutan una cantidad suficiente de tiempo, comenzamos a generar código JIT solo a partir de eso. Y solo de los subs que se ejecutan un número suficientemente alto de veces. Y de esta manera podemos lograr tanto un buen rendimiento en tiempo de ejecución como sin exceder el recurso del navegador en términos de código compilado.

Entonces, ¿qué podemos hacer con esta cosa? En términos de características, lo que tenemos ahora es que tenemos un soporte bastante completo para el conjunto de instrucciones X86. Soportamos X87, pero no es tan rápido. MMX y SSC están ambos soportados, pero actualmente están escalarizados. Así que los expandimos a las operaciones escalares equivalentes, lo cual es por supuesto más lento y nuestros planes en el futuro son por supuesto usar la extensión de WebAssembly para poder reducir esta brecha. A nivel del sistema operativo, tenemos soporte para la mayoría de los sistemas de archivos y manejo de procesos Los datos provienen de un backend de disco que es una implementación de X2. Y hemos elegido usar X2 porque será posible para nosotros extenderlo en el futuro para soportar más extensiones y alcanzar el nivel X3 y X4 sin tener que reescribir todo desde cero.

En términos de persistencia, esto es bastante interesante. Si cambias un archivo en esta VM, se quedará allí. La persistencia es local. Se realiza usando index.db, lo cual es genial porque preserva la privacidad. Así que no vamos a mirar tus datos. Son tuyos y se almacenarán en tu máquina. Y con esta cantidad limitada de características, ya podemos hacer un montón de cosas interesantes. En el contexto de la educación, por ejemplo, haría posible que las escuelas establezcan un entorno de cero mantenimiento que los estudiantes puedan iniciar sin tener que preocuparse de si esto funcionará en su computadora o tal vez hoy la configuración XS no está funcionando correctamente. Para desarrolladores como nosotros, podría hacer posible no solo tener IDEs basados en la web. Esto hará posible tener un entorno de desarrollo completamente basado en la web donde realmente puedes construir y ejecutar todo el pipeline en el cliente. Esto será útil en la documentación, para tener documentación en vivo para cualquier lenguaje de programación, no solo para lenguajes de programación que ya pueden ejecutarse en el navegador. Y esto también puede ser útil para abrir la web a una nueva categoría de aplicaciones, en particular, aplicaciones de ingeniería de alta exigencia como programas de diseño asistido por computadora. Usualmente, este tipo de aplicaciones no tienen realmente el código fuente completo disponible, ni siquiera para el desarrollador. Porque usan componentes binarios que son vendidos por otras compañías.

Y gracias a este sistema, no importa que no tengas el código. Puedes ejecutar el sistema binario tal como está. Fundamentalmente, no te importa. Y esto es lo que tenemos ahora.

¿Y qué hay del futuro? Bueno, por supuesto, una cosa en mi mente es el gaming. Y para hacer eso, primero necesitamos tener algún tipo de soporte gráfico. Todavía estamos llegando allí. Y el plan es realmente hacer que el servidor completo de X.Org se ejecute en el navegador. Lo creas o no, esto puede funcionar. Hice un prototipo hace algunos meses y es totalmente posible. Y luego necesitamos encontrar una manera de mapear OpenGL directamente a WebGL. Y lo curioso es que con esta configuración, es bastante posible que la sobrecarga no sea ni siquiera tan alta. Porque, por supuesto, la virtualización implica una sobrecarga en términos de ejecución de CPU. Pero dado que mapearemos OpenGL directamente a WebGL, la sobrecarga allí probablemente será mucho menor. Y con soporte de red, que es un tema completamente complicado, podríamos ser capaces de tener entornos de desarrollo completos donde puedas iniciar una pequeña aplicación web incluyendo código del lado del servidor desde tu pestaña del navegador, que luego es accesible desde todo el mundo por otras personas con su propio navegador. Y mi objetivo personal es llegar al punto donde podamos ejecutar un entorno de escritorio completamente virtualizado en una pestaña para que puedas acceder al sitio web, iniciar sesión y tener tus datos. Cierras la pestaña, has terminado, puedes continuar tu trabajo en otro lugar con tu propio sistema. Y esto es todo, realmente.

No dudes en ponerte en contacto. Y de hecho estamos contratando, estamos buscando un pasante en este momento. Así que si estás interesado o conoces a alguien que podría estar interesado en trabajar con nuestra tecnología, hay un espacio. Gracias. Gracias, muchas gracias, Alessandro.

Y veamos si tenemos algunas preguntas en Slido. ¿Podría ver esto en la pantalla, por favor? Sí, creo que tenemos algunas de ellas, al menos esto es lo que veo. Está bien, no hay problema. Lo leeré desde mi teléfono móvil. Sí, básicamente, la primera pregunta es muy similar a mi pregunta inicial. ¿Es o será posible ejecutar aplicaciones de Windows en el navegador desde el archivo .exe? Por ejemplo, navegador, como mencioné. Así que, para ejecutar fundamentalmente, el problema es que implementamos llamadas al sistema.

Y es, en teoría, posible implementar la llamada al sistema Windows y ejecutar una pila completa de Windows. Ahora, la parte complicada de eso es la concesión de licencias. No tenemos licencia de Microsoft para usar todos los DLLs de Windows. Ahora lo que puedes hacer es ejecutar Wine. También, ejecutar la Capa de Emulación de Windows para Linux para ejecutar las aplicaciones de Windows sobre eso. Bastante justo.

La siguiente. ¿Tenemos autocompletado u otras limitaciones? Quiero decir, ¿en la línea de comandos? Bueno, no, es un bush real. Es exactamente lo que obtendrás para tu propio sistema. Así que, si el autocompletado está configurado correctamente, también lo obtendrás.

La siguiente pregunta es, ¿es todo de código abierto? Por supuesto que no lo es. Así que, la cuestión es que esto podría cambiar con el tiempo. Como decía, actualmente todavía estamos tratando de averiguar cuál será la comercialización de esta tecnología. Y ahora mismo nos parece que mantenemos más caminos abiertos manteniéndolo propietario. Pero esto podría cambiar en el futuro. Honestamente no lo sabemos. Hasta ahora solo será para que nosotros veamos el código. Pero nos gustaría que ustedes probaran eso, si les gusta.

De acuerdo. Dijiste que WebVM tiene un sistema de archivos virtual respaldado por Cloudflare. ¿Carga los archivos de manera perezosa o precarga toda la VM de una vez? ¿Funciona bien, después de todo? Así que, el backend está almacenado por un CDN, por Cloudflare. Pero no está basado en archivos. Está basado en bloques. Es un dispositivo de bloques. Así que, es un sistema de archivos basado en bloques muy tradicional. Y cada bloque se descarga bajo demanda. Solo cuando es necesario. Y esto significa que realmente podemos soportar imágenes de disco bastante grandes. La imagen que has visto hasta ahora es de 2 gigas. Pero esto es principalmente por limitaciones técnicas.

Y planeamos hacer posible llegar mucho, mucho más alto en términos de tamaño. Genial.

Así que, la siguiente pregunta es... ¿Existe un modo offline? Entonces, demostraste este sitio web. Como Playground. ¿Es de alguna manera posible ejecutar estas cosas geniales cuando estás desconectado? Entonces, si preguntas si yo y mi computadora podemos tener una configuración offline, sí, por supuesto. Pero aún no está disponible para el público. Todavía es parte del hecho de que aún necesitamos entender exactamente qué vamos a ofrecer, cuáles serán las APIs, y ese tipo de cosas. Así que, ahora mismo no hay un modo offline real. Pero es lo que es. Estamos trabajando en ello. Genial.

Tomemos esta. ¿También tienes acceso al sistema de alguna manera? Por ejemplo, ¿puedes ejecutar el comando top? Bueno, puedes ejecutar top. Pero solo obtendrás la información. Para ser justos, aún no puedes ejecutar top. Idealmente, podrás ejecutar top. Pero solo obtendrás información sobre el sistema virtualizado. Por supuesto, nunca puedes acceder a la realidad del sistema subyacente. ¿Verdad? Esto es seguro. Esto no es un agujero de seguridad en tu sistema. Genial.

La pregunta es quién es y para qué se usa WebVM ahora mismo. En términos de clientes, aún no tenemos uno. Pero tenemos socios con los que estamos tratando de trabajar para intentar construir el primer producto. Y el principal interés que tenemos es del sector educativo y del sector de ID basados en la web. Estas son las personas que parecen ser las más interesantes ahora mismo. Pero mi objetivo personal es tener a algunas personas de juegos a bordo. Suena bien. Y tomemos esta. Y creo que esta será la última pregunta.

Y ahora tenemos un descanso para el almuerzo.

¿Qué tipo de navegadores y dispositivos se requieren? Cualquiera. Chrome, Firefox, Safari funcionarán. Eso es fácil.

Muchas gracias por sus preguntas. Dejaré algunas monedas en el escenario. Si tiene alguna pregunta, siéntase libre de venir y tomar. Y ahora tenemos un descanso de una hora para el almuerzo. Se necesitan algunas calorías. Gracias.