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 presentarles algunas de las tecnologías que hemos desarrollado para ustedes. Y especialmente hoy, es un día especial para mí, porque es mi cumpleaños. Muchas gracias por venir aquí a celebrar conmigo, realmente lo aprecio.

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 desde entonces, soy un orgulloso habitante de Ámsterdam. Si lo desean, pueden seguirme en Twitter, pero les recomendaría no contener la respiración mientras esperan a que publique algo.

Entonces, ¿qué hacemos? Somos una pequeña empresa especializada 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 en C++, un compilador de JavaScript y WebAssembly. El segundo fue ChirpJ, que no es solo un compilador para Java, en realidad. Es más bien una máquina Java completa que puede ejecutarse en el navegador. Y podemos usarlo incluso para ejecutar aplicaciones Java completamente gráficas en el navegador en este momento. Y luego decidimos dar un paso más. Y creamos ChirpX. Y ChirpX no es solo un producto, en realidad. En este momento, lo consideramos más como una tecnología. Es una solución muy genérica que puede hacer muchas cosas diferentes. Y como un primer experimento para ver cómo podemos convertir esto eventualmente en un producto que podamos vender, creamos WebVM, que es solo una de las posibles cosas que podemos construir con esto. Y hablaremos de 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 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 crear 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 explicaré más adelante qué quiero decir exactamente al usar estas palabras. Y en términos prácticos, lo que es ChirpX es una aplicación en C++ que escribimos desde cero. Lo escribimos nosotros mismos y lo compilamos a JavaScript WebAssembly utilizando Chirp, utilizando nuestro otro producto, para que pueda ejecutarse en el navegador. Y sé que es bueno hablar de las cosas, pero también es bueno ver cómo funcionan en la práctica.

Y todos me recomendaron no hacer una demostración en vivo, pero, ¿saben qué? ¿Quién soy yo para seguir buenos consejos? Vamos a intentarlo. Entonces, lo que me gustaría hacer es demostrarles que podemos ejecutar un sistema virtualizado completo 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 demostrárselo, puedo, por ejemplo, listar un sistema de archivos y hay muchas cosas que se pueden esperar de un sistema real en ejecución.

Pero me gustaría demostrar que 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á ejecutándose, y ahora puedo escribir un caso de prueba muy pequeño. Y lo que está sucediendo ahora mismo es que todo esto se está ejecutando desde los binarios de XSAT que se ejecutan en su 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 código de retorno cero habitual que le dirá al sistema que el ejecutable se ha completado con éxito, quiero devolver un código de error. Quiero ver si el shell puede manejar eso. Así que vamos a probar 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. De acuerdo. ¿Qué está sucediendo en segundo plano aquí? GCC es un ejecutable bastante grande y actualmente el sistema está cargando los datos requeridos desde la red. Y estos datos llegan en bloques porque en realidad es una implementación completa de X2 que se ejecuta desde un dispositivo de disco respaldado por una CDN. Está respaldado por cloudflare. Y esta ejecución se ha completado realmente. Podemos probar si esto incluso se puede ejecutar. Hace lo que esperamos que haga. Verifiquemos el código de error. Es lo que esperamos.

Esto es bastante interesante, creo, pero tal vez ya lo dije antes, ¿verdad? Podemos compilar C++ WebAssembly, así que tal vez estés pensando que hay algún truco aquí. Que tal vez esta sea 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 podemos preguntarle 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 para ejecutables. Así que Linux 32 bits 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.

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

Así que ahora podemos probar algo completamente diferente. Probemos con Python. Entonces, lo que he hecho ahora es configurar el intérprete de Python y puedo escribir comandos directamente en la terminal una vez más. Haré lo mismo que antes. Hola. Esto también es bastante fácil. Puedo devolver otro código, que se mostrará en pantalla. Y, bueno, 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. Intentemos ejecutar JavaScript. También abriré Vim de nuevo. 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, en realidad voy a habilitar la opción de imprimir el código. Entonces, lo que hace esta opción es imprimir todo el código nativo que Node.js y en realidad el motor interno, que es V8, el mismo motor que se utiliza en Chrome, está generando solo para ejecutar este pequeño ejemplo. Ten en cuenta que lo que estás viendo no es algo que sucede especialmente porque se está ejecutando en este entorno virtualizado. Esto ocurre cada vez que inicias Node.js. Y lo que encontré interesante es que lo que esto muestra es que ChirpX es capaz de manejar un ejecutable bastante sofisticado, porque este código se genera en tiempo de ejecución. El motor nunca antes había visto esto. Simplemente se ha generado, se ha leído en la memoria y finalmente se ha ejecutado. Entonces, ¿cómo construimos algo? Ah, por cierto, este es un sitio web en vivo. Si quieres jugar con esto, puedes ir y probarlo, y si encuentras errores, puedes informarlos 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, me refiero a que queremos hacer algo que no requiera ningún preprocesamiento, ningún metadato especial. No deberíamos tener un compilador especial ni opciones de compilación especiales, no deberíamos tener bibliotecas especiales, nada de esto. Lo que hacemos es tomar los binarios tal como salen de los paquetes de Debian y los utilizamos.

Rápido significa básicamente poder ejecutar Node.js, ya que necesitamos poder enfrentar una situación en la que el código no solo se genera en tiempo de ejecución, sino que también se modifica en tiempo de ejecución, tal vez se modifica en su lugar o simplemente se elimina y se coloca en otro lugar. Esto también ocurre al ejecutar código con V8, porque el código en sí mismo es un recolector de basura y se mueve en la memoria con el tiempo.

Y luego queríamos construir algo escalable. Esto significa que, aunque les mostré solo un montón de palabras amarillas, esta cosa 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 admitir multiprocesamiento, multihilo, miles de archivos y todas las características que son utilizadas efectivamente por programas reales, no solo juguetes.

Para darles una idea de lo que hemos visto hasta ahora, ChirpX es este entorno en el que ocurre toda la ejecución. Y todo es del lado del cliente. Todo está en el navegador. No hay un componente del lado del servidor que haga la ejecución por nosotros. Esto no es un truco. Y lo primero que se inicia es Bash. Entonces Bash es el proceso principal. Y luego Bash mismo puede generar subprocesos, procesos secundarios, y les mostré GCC y Python, y todos estos son completamente independientes en 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 la memoria. Y para resolver este problema, en realidad tenemos 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 prácticamente sin ninguna información. Comenzará desde la primera instrucción y la pasará a la siguiente y así sucesivamente. Y a medida que lo hace, también construirá internamente los metadatos sobre cómo está estructurado el código. Y con eso, ahora es posible iniciar el motor JIT para generar un 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 la pantalla, por ejemplo. Y esto sucede como esperarías en un sistema nativo a través de llamadas al sistema. Y las llamadas al sistema, las implementamos nosotros mismos. Entonces, lo que viste hasta ahora no es un kernel de Linux. Es una ABI compatible con Linux, por lo que puede ejecutar cualquier ejecutable de Linux, pero no es Linux en sí mismo. 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 te preguntarás por qué no ejecutamos todo en el JIT, ya que probablemente sea más eficiente.

Y el problema aquí es que esto no siempre es necesariamente cierto. Desde mi punto de vista, la compilación JIT es básicamente una inversión, y quieres asegurarte de recuperar tu inversión. Es una inversión de tiempo de ejecución, en realidad. Pagas un poco 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 se ejecute 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 grafo de flujo de control del programa. Y luego, cuando los bloques de código se vuelven suficientemente activos, se ejecutan una cantidad suficiente de veces, comenzamos a generar código JIT solo a partir de eso. Y solo de las subrutinas 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 los recursos del navegador en términos de código compilado.

Entonces, ¿qué podemos hacer con esto? En términos de características, lo que tenemos ahora es un soporte bastante completo para el conjunto de instrucciones X86 básico. Admitimos X87, pero no es tan rápido. MMX y SSC son compatibles, pero actualmente están escalares. Así que los expandimos a las operaciones escalares equivalentes, que por supuesto son más lentas y nuestros planes para el futuro son utilizar 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 el manejo de procesos. Los datos provienen de un backend de disco que es una implementación X2. Y hemos elegido usar X2 porque será posible para nosotros extenderlo en el futuro para admitir más extensiones y alcanzar el nivel X3 y X4 sin tener que reescribir todo desde cero.

En cuanto a la persistencia, esto es bastante interesante. Si cambias un archivo en esta VM, se quedará ahí. La persistencia es local. Se realiza utilizando index.db, lo cual es genial porque preserva la privacidad. 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 muchas cosas interesantes. En el contexto de la educación, por ejemplo, permitiría a las escuelas configurar un entorno sin mantenimiento que los estudiantes puedan iniciar sin tener que preocuparse si esto funcionará en su computadora o si hoy la configuración XS no funciona correctamente. Para desarrolladores como nosotros, podría permitirnos no solo tener IDE basados en web. Esto hará posible tener un entorno de desarrollo web completo donde realmente puedes construir y ejecutar todo el flujo de trabajo 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 se pueden ejecutar 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 alto rendimiento como programas de diseño asistido por computadora. Por lo general, este tipo de aplicaciones en realidad no tienen el código fuente completo disponible, ni siquiera para el desarrollador. Porque utilizan 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án. Básicamente, 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 juego. Y para hacer eso, primero necesitamos tener algún tipo de soporte gráfico. Todavía estamos llegando allí. Y el plan es 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 forma de mapear OpenGL directamente a WebGL. Y lo curioso es que con esta configuración, es bastante posible que la sobrecarga no sea tan alta. Porque, por supuesto, la virtualización implica una sobrecarga en términos de ejecución de la 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 complicado en sí mismo, es posible que podamos tener entornos de desarrollo completos donde puedas iniciar una pequeña aplicación web que incluya código del lado del servidor desde la pestaña de tu navegador, que luego sea accesible desde cualquier parte del mundo por otras personas con su propio navegador. Y mi objetivo personal es llegar al punto en el que 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, terminas, puedes continuar tu trabajo en otro lugar con tu propio sistema. Y eso es todo, realmente.

No dudes en ponerte en contacto. Y de hecho, estamos contratando, estamos buscando un becario en este momento. Así que si estás interesado tú mismo o conoces a alguien que podría estar interesado en trabajar con nuestra tecnología, hay un espacio. 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, al menos esto es lo que veo. De acuerdo, 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 posible o será posible ejecutar aplicaciones de Windows en el navegador desde el archivo .exe? Por ejemplo, el navegador, como mencioné. Entonces, para ejecutar fundamentalmente, el problema es que implementamos llamadas al sistema.

Y en teoría, es posible implementar la llamada al sistema de Windows y ejecutar una pila completa de Windows. Ahora, la parte complicada de eso es la licencia. No tenemos licencia de Microsoft para usar todas las DLL de Windows. 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 encima de eso. Bastante justo.

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

La siguiente pregunta es, ¿es todo de código abierto? Por supuesto que no lo es. Entonces, la cosa es que esto podría cambiar con el tiempo. Como estaba diciendo, actualmente todavía estamos tratando de averiguar cuál será la comercialización de esta tecnología. Y ahora mismo nos parece que nos mantenemos más abiertos manteniéndola propietaria. Pero esto podría cambiar en el futuro. Sinceramente, no lo sabemos. Hasta ahora, solo nosotros podremos ver el código. Pero nos gustaría que ustedes lo probaran, si les gusta.

Okie doke. Dijiste que WebVM tiene un sistema de archivos virtual respaldado por Cloudflare. ¿Carga los archivos de forma perezosa o carga la VM completa de una vez? ¿Funciona bien, después de todo? Entonces, el backend se almacena en una CDN, por Cloudflare. Pero no se basa en archivos. Se basa en bloques. Es un dispositivo de bloques muy tradicional. Y cada bloque se descarga según sea necesario. Solo cuando se requiere. Y esto significa que en realidad podemos admitir imágenes de disco bastante grandes. La imagen que has visto hasta ahora tiene 2 gigas. Pero esto es principalmente por limitaciones técnicas.

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

Entonces, la siguiente pregunta es... ¿Existe un modo sin conexión? 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 sin conexión, sí, por supuesto. Pero aún no está disponible para el público. Todavía es parte del hecho de que todavía necesitamos entender exactamente qué vamos a enviar, cuáles serán las APIs y este tipo de cosas. Entonces, en este momento no hay un modo verdaderamente sin conexión. Pero es lo que es. Estamos trabajando en ello. Genial.

Tomemos este. ¿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 podrás acceder a la realidad del sistema subyacente. ¿Verdad? Esto es seguro. Esto no es un agujero de seguridad en tu sistema. Bueno.

La pregunta es, ¿quién y para qué usa WebVM en este momento? En cuanto a los clientes, aún no tenemos ninguno. Pero tenemos socios con los que estamos tratando de trabajar para intentar construir el primer producto. Y el principal interés que tenemos proviene del sector educativo y del sector de identificaciones basadas en la web. Estas son las personas que parecen ser las más interesantes en este momento. Pero mi objetivo personal es tener a algunas personas de juegos a bordo. Suena bien. Y tomemos esto. Y creo que esta será la última pregunta.

Y a continuación tenemos el descanso para el almuerzo.

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

Muchas gracias por sus preguntas. Mantendré algunas monedas en el escenario. Si tienen alguna pregunta, siéntanse libres de acercarse y tomar. Y ahora tenemos una hora de descanso para el almuerzo. Se necesitan algunas calorías. Gracias. Gracias.