Todo el tiempo que trabajo en Microsoft, he estado creando herramientas para desarrolladores de Linux. Comencé a trabajar en agosto de 2016, después de graduarme de la Universidad de Virginia, donde estudié informática y administración. Durante mis estudios, programé principalmente en C ++. Mi sistema operativo principal era Linux.
Puede parecer que mi experiencia no coincide con lo que Microsoft podría necesitar, pero en ese momento la compañía estaba experimentando un cambio importante, tanto en términos de tecnología como de cultura. La compañía se estaba moviendo a un nuevo estado en el que todos los sistemas operativos, incluido Linux, eran importantes para él.
Mi trabajo en Microsoft comenzó en el equipo de Linux. Estaba haciendo un producto SQL Server allí. Me ofrecieron unirme a este equipo, con la esperanza de poder aportar mi experiencia en Linux. Me impresionó mucho el hecho de que, aunque acababa de dejar de lado, podría ser valioso para el equipo debido a mi experiencia.
Hace unos años, la idea de desarrollar una variante de SQL Server para Linux habría sido una broma de los Inocentes, pero en 2016 fue completamente real. Me uní al equipo poco después de que lanzaron la primera versión del producto. Comencé a mejorar el kit de herramientas de SQL Server, particularmente para los administradores. Este kit de herramientas estaba destinado a administrar servidores y aplicaciones Linux. El uso de SQL Server en Linux requería llevar las herramientas de línea de comandos al aspecto al que estaban acostumbrados los usuarios de Linux.
Además, tuve la oportunidad de diseñar la primera versión de la GUI de SQL Server para Linux. Comencé con una bifurcación de Visual Studio Code, que hoy se llama Azure Data Studio. Esta es una aplicación basada en Electron que, independientemente del sistema operativo, puede funcionar con cualquier tipo de SQL Server.
Aprendí mucho de SQL Server para Linux en mi primer año en Microsoft. En este conocimiento, también puedo incluir el desarrollo de un enfoque para gestionar el desarrollo y el apoyo de proyectos basados en una combinación de tecnología y pensamiento empresarial.
WSL Team, Chocolatey y Boxstarter en Microsoft Build 2018En agosto de 2017, me uní al equipo de WSL (Windows Subsystem for Linux, Windows Subsystem for Linux) como gerente de proyectos. Escuché por primera vez acerca de WSL durante el anuncio en Microsoft Build 2016. Video relacionado del Canal 9, “¡
Ejecutando Bash en Ubuntu en Windows! ", Inmediatamente después del lanzamiento se volvió viral. Claramente interesó a la audiencia más que muchos otros anuncios hechos en la conferencia. La tecnología WSL se discutió brevemente, literalmente en un par de minutos, en el marco de la puntuación de los puntos principales de la conferencia. Sin embargo, la audiencia de esto directamente se volvió loca, sin mencionar a los periodistas. Hubo un momento en que el equipo de soporte de Channel9 temía que el alto nivel de interés de los usuarios en este video clip se debiera realmente a un ataque DDoS. El portavoz de Microsoft lanzó Bash en Ubuntu, ejecutándose dentro de Windows ... Esta acción fue un éxito instantáneo.
El primer equipo en descubrir las necesidades de los usuarios de WSL fue el que trabajó en la consola de Windows. Durante el desarrollo, han escuchado una y otra vez que la gente quiere algo como Bash de Linux. Como resultado, el equipo llegó a la siguiente idea: "¿Por qué hacer algo parecido a Bash, si solo puedes hacer que el shell de Bash se ejecute correctamente en Windows?"
Esto no quiere decir que fue fácil de hacer. La creación de WSL requirió una combinación de conocimiento profundo de Windows, que poseía el equipo de desarrollo en el núcleo del sistema, y una tecnología desarrollada en Microsoft Research llamada picoprocess. Curiosamente, los picoprocesos, además, son la tecnología que hace que SQL Server funcione en Linux.
Se suponía que el picoproceso debía proporcionar una implementación de Linux no modificada en modo de usuario. El equipo del kernel de Windows ha estado desarrollando cuñas diseñadas para conectar las llamadas del sistema Linux a Windows. En otras palabras, WSL hizo posible ejecutar código compilado para Linux en el kernel de Windows NT. No hubo necesidad de recompilar el código o usar máquinas virtuales.
No creamos entonces solo nuestra propia distribución de Linux. El hecho es que había muchas de esas distribuciones. La primera versión de Linux disponible en WSL fue Ubuntu. Contactamos a especialistas canónicos para averiguar si les gustaría ayudarnos a trabajar en el WSL. Estaban entusiasmados con nuestra idea. Esto llevó al hecho de que Ubuntu apareció en la Tienda Microsoft. Por cierto, la oración anterior, en sí misma, suena bastante inusual. Ahora en Microsoft Store puedes contar 6 distribuciones. Me pregunto qué otras tiendas de aplicaciones disponibles en ciertos sistemas operativos tienen otros sistemas operativos.
Microsoft Store ahora tiene 6 distribuciones de Linux que se pueden usar en WSLEl código que escribimos entonces era llamadas al sistema de kernel compatibles con Linux, que servían como interfaz entre los procesos de Linux y el kernel de Windows. Linux tiene alrededor de 340 llamadas al sistema. La pregunta era decidir qué llamadas al sistema implementar primero. Al igual que con cualquier sistema operativo, en Linux se agregan nuevas llamadas al sistema a medida que se lanzan nuevas versiones del sistema operativo, pero las llamadas antiguas nunca se eliminan, lo que garantiza la compatibilidad con versiones anteriores. Al principio, se implementó el procesamiento de un cierto conjunto de llamadas al sistema, y todo lo demás se envolvió en eventos como "aún no implementado". Esto permitió que el equipo de WSL comenzara a analizar exactamente qué llamadas de sistema necesitan los usuarios de Linux.
La respuesta a la pregunta de qué llamadas al sistema deberían implementarse en primer lugar significaba la necesidad de establecer comunicación con aquellas personas que usarían WSL. El mensaje sobre esta tecnología en la conferencia Build tuvo como objetivo hacer que las personas comiencen a usar WSL y den su opinión. Para adquirir WSL, tenía que ser miembro del Programa Windows Insider. Cualquiera puede conectarse a este programa. Puede pensar que los participantes del programa eran solo aquellos que estaban interesados en Windows, pero luego, entre más de diez millones de suscriptores, había personas con una amplia variedad de intereses. Estaban interesados no solo en Windows, sino también, por ejemplo, en juegos y nuevas características de Bluetooth y WSL.
Uno de los grupos de usuarios interesados en ejecutar el shell Bash en Windows fue el desarrollador web involucrado en la creación de aplicaciones web que se ejecutan en servidores Linux. Todo el proceso de ensamblar sus aplicaciones fue a menudo una secuencia de comandos Bash. Además, si alguien decide pedir ayuda en el desarrollo de aplicaciones web, por ejemplo, en Stack Overflow, la mayoría de los ejemplos de código que puede encontrar estarán diseñados para ejecutarse en Linux. Esto no es particularmente bueno para aquellos que usan Windows como su computadora para el desarrollo web. A menudo, es más fácil para tales desarrolladores simplemente cambiar a la plataforma Mac. En macOS, se ejecutan ejemplos de código similares sin ningún problema.
En las primeras dos semanas de presencia de WSL en Windows, un usuario empresarial
pudo ejecutar XEyes. Este programa se ejecutó en un sistema de ventanas X11 que se ejecuta en WSL. XEyes es un programa simple. Ella muestra ojos de dibujos animados que siguen el cursor del mouse. Pero esta manifestación explotó las redes sociales.
XEyes se ejecuta en Windows a través de WSLDiscutimos mucho sobre exactamente cómo queremos recopilar opiniones de usuarios sobre WSL. La herramienta tradicional utilizada para recopilar comentarios fue UserVoice. Teníamos un sitio UserVoice diseñado para WSL, que reunía cientos de ideas y miles de votos sobre varios temas. La verdadera pregunta se nos ocurrió cuando se trataba de si deberíamos usar GitHub. Dado que los desarrolladores web fueron uno de los primeros grupos de usuarios interesados en WSL, la cuestión de GitHub fue muy importante. Pero WSL no fue un proyecto de código abierto. Colocar un proyecto de este tipo en GitHub parece extraño. Decidimos cumplir con los requisitos de los desarrolladores y creamos una página en GitHub para informar problemas, comentarios y discusiones. Desde entonces, hemos recibido miles de mensajes sobre muchos problemas relacionados con el uso de Linux en Windows.
Miles de personas han dejado mensajes de error en
el repositorio WSL
GitHub . Cada uno de estos mensajes fue revisado y discutido por el equipo de WSL, y se hicieron comentarios sobre cada uno de ellos. Después de eso, se tomó una decisión sobre nuevas acciones. Si para aprovechar una cierta oportunidad o corregir algún tipo de error, era necesario escribir un nuevo código, este código fue creado y agregado al proyecto WSL, luego de lo cual se incluyó en todos los ensamblados de Windows distribuidos bajo el programa Windows Insider. El ciclo completo, desde recibir un mensaje de error hasta corregirlo, no tomó mucho tiempo, aproximadamente un par de semanas.
Como resultado, gracias a la respuesta operativa del equipo de WSL a las solicitudes de los usuarios, fue posible decir que la comunidad estuvo involucrada en el proceso de creación de WSL. Las personas informaron problemas o sus deseos a través de UserVoice o GitHub, el equipo revisó todo esto e hizo cambios en el proyecto, que luego apareció en las compilaciones del proyecto Windows Insider.
Cuando me uní al equipo de WSL como gerente de proyecto, me concentré en sacar WSL de la versión beta. Quejas de los usuarios relacionadas principalmente con la compatibilidad y el rendimiento. Pero, en mi opinión, si los usuarios se preocupan por esas cosas, significa que usan nuestro desarrollo en serio. Solo aquellos que resuelven algunos problemas importantes con la ayuda de cierto sistema de software se ocupan del rendimiento. Como resultado, aunque todavía teníamos mucho que hacer, lo hicimos no solo así, sino para que las personas pudieran resolver más problemas usando WSL, y para que puedan resolver sus problemas más rápido.
A medida que las capacidades de WSL comenzaron a expandirse, hicimos esfuerzos para acercar WSL a los desarrolladores, y no solo a aquellos usuarios que tradicionalmente trabajan usando el ecosistema de Microsoft. Fue muy interesante asistir a eventos como PyCon y OSCON. Los desarrolladores que estuvieron presentes allí se sorprendieron de que los representantes de Microsoft también participaran en estos eventos. Los desarrolladores desconfiaban de la idea de ejecutar Linux en un entorno Windows. En estos eventos, mostré SQL Server, WSL y Visual Studio Code.
Demostración de WSL en varios eventos.Respondí a sus comentarios escépticos con una sugerencia para probar lo que les mostré. Cuando los que dudaban comenzaron a ejecutar sus propios comandos, pequeños scripts y fragmentos, siempre me encontraba con una reacción violenta a lo que estaba sucediendo: “Espera un minuto, y esto es realmente Linux. ¿Cómo hiciste esto? ¿Por qué no sabía sobre esto? " A menudo llegaron a la conclusión de que hemos creado algo que satisface sus necesidades, algo que parece muy interesante.
Tomamos en cuenta las quejas de los usuarios con respecto a la compatibilidad y el rendimiento de WSL, y lanzamos una nueva arquitectura de sistema:
WSL 2 . Proporciona compatibilidad total a través de la inclusión del kernel de Linux en Windows y proporciona un aumento de velocidad 20 veces mayor. Obtuve una experiencia interesante creando la base de WSL 2 y viendo el anuncio de esta tecnología en la conferencia Build, que se celebró en mayo de 2019. Hoy, el proyecto WSL ya superó la versión beta y llegó a la versión 2.
Además, trabajé en Microsoft con otros equipos, tratando de asegurarme de que WSL pudiera usarse con sus productos. Un ejemplo significativo de este uso de WSL es Visual Studio Code. Este es el entorno de código más popular utilizado en el desarrollo de proyectos JavaScript y Node.js. Me interesé en Visual Studio Code cuando me di cuenta de que los desarrolladores que usan este editor pueden obtener beneficios significativos de WSL. Al principio, no se trataba de la necesidad de escribir grandes cantidades de código. El objetivo principal era simplificar la depuración de los programas Node.js que se ejecutan en el entorno WSL. Esto les daría a los desarrolladores la oportunidad de desarrollar programas diseñados para la versión Linux de Node.js en una computadora con Windows usando WSL. La depuración de dichos programas se vería exactamente igual que la depuración en Linux.
Primer intento de integrar Visual Studio Code con WSL y Node.jsDespués de que esto resultó posible para JavaScript y Node.js, comenzamos a recibir muchas solicitudes de algo similar para otros lenguajes, por ejemplo, para C ++ y Python. Este ejemplo de la integración de WSL y VS Code me fascinó, descubrí que estaba extremadamente interesado en esto. Esto me llevó a mi nuevo rol en la creación de herramientas para desarrolladores de Linux. Ahora me centro en herramientas para desarrolladores de C ++ en VS Code. En este trabajo, por supuesto, me centro en Linux. Fue agradable ver una demostración del desarrollo remoto de Visual Studio Code en el evento PyCon de este año cuando se lanzó la extensión WSL correspondiente. Al mismo tiempo, se introdujo una extensión para C ++, que mi equipo estaba desarrollando.
A pesar de que no pasé tanto tiempo en Microsoft, me alegro de haber podido participar en la creación de muchas herramientas para desarrolladores de Linux. Esta base de datos y soporte para Linux en Windows, y herramientas para escribir y depurar código. Planeo continuar trabajando en Linux y crear herramientas que los desarrolladores de todo el mundo disfrutarán usando.
Estimados lectores! ¿Usas WSL?
