Todo o tempo em que trabalho na Microsoft, tenho criado ferramentas para desenvolvedores de Linux. Comecei a trabalhar em agosto de 2016, depois de me formar na Universidade da Virgínia, onde estudei ciência da computação e administração. Durante meus estudos, programei principalmente em C ++. Meu principal sistema operacional era Linux.
Pode parecer que minha experiência não corresponde exatamente ao que a Microsoft pode precisar, mas na época a empresa estava passando por uma grande mudança, tanto em termos de tecnologia quanto em termos de cultura. A empresa estava se mudando para um novo estado em que todos os sistemas operacionais, incluindo Linux, eram importantes para ele.
Meu trabalho na Microsoft começou na equipe do Linux. Eu estava fazendo o produto SQL Server lá. Me ofereceram para ingressar nesta equipe, esperando trazer minha experiência no Linux para ela. Fiquei muito impressionado com o fato de que, apesar de ter deixado de lado, poderia ter valor para a equipe por causa da minha experiência.
Alguns anos atrás, a idéia de desenvolver uma variante do SQL Server para Linux teria sido uma piada de April Fool, mas em 2016 era completamente real. Entrei para a equipe logo após o lançamento da primeira versão do produto. Comecei a melhorar o kit de ferramentas do SQL Server, principalmente para administradores. Este kit de ferramentas teve como objetivo gerenciar servidores e aplicativos Linux. O uso do SQL Server no Linux exigia trazer as ferramentas de linha de comando para a aparência que os usuários do Linux estavam acostumados.
Além disso, tive a oportunidade de criar a primeira versão da GUI do SQL Server para Linux. Comecei com um fork do Visual Studio Code, que hoje é chamado Azure Data Studio. Este é um aplicativo baseado em Electron que, independentemente do sistema operacional, pode funcionar com qualquer tipo de SQL Server.
Eu aprendi muito com o SQL Server para Linux no meu primeiro ano na Microsoft. Nesse conhecimento, também posso incluir o desenvolvimento de uma abordagem para gerenciar o desenvolvimento e o suporte a projetos com base em uma combinação de tecnologia e pensamento de negócios.
Equipe da WSL, Chocolatey e Boxstarter no Microsoft Build 2018Em agosto de 2017, ingressei na equipe da WSL (Windows Subsystem para Linux, Windows Subsystem para Linux) como gerente de projeto. Ouvi falar da WSL pela primeira vez durante o anúncio no Microsoft Build 2016. Vídeo relacionado do Canal 9, “
Executando o Bash no Ubuntu no Windows! ", Imediatamente após o lançamento se tornar viral. Claramente interessou ao público mais do que muitos outros anúncios feitos na conferência. A tecnologia WSL foi discutida brevemente, literalmente em alguns minutos, no âmbito da pontuação dos principais pontos da conferência. No entanto, o público diretamente enlouqueceu, sem mencionar os jornalistas. Houve um tempo em que a equipe de suporte do Channel9 temia que o alto nível de interesse do usuário neste videoclipe fosse devido a um ataque DDoS! Porta-voz da Microsoft lançando o Bash no Ubuntu, rodando dentro do Windows ... Essa ação foi um sucesso instantâneo.
A primeira equipe a descobrir as necessidades do usuário para WSL foi a que trabalhou no console do Windows. Durante o desenvolvimento, eles ouviram várias vezes que as pessoas querem algo como o Bash do Linux. Como resultado, a equipe pensou no seguinte: "Por que algo semelhante ao Bash se você pode fazer o shell do Bash funcionar no Windows?"
Isso não quer dizer que foi fácil de fazer. A criação da WSL exigiu uma combinação de conhecimento aprofundado do Windows, que a equipe de desenvolvimento do núcleo do sistema possuía, e uma tecnologia desenvolvida na Microsoft Research chamada picoprocess. Curiosamente, os picoprocessos também são a mesma tecnologia que faz o SQL Server funcionar no Linux.
O picoprocesso deveria fornecer implementação Linux não modificada no modo de usuário. A equipe do kernel do Windows tem desenvolvido calços projetados para conectar chamadas do sistema Linux ao Windows. Em outras palavras, a WSL tornou possível executar o código compilado para Linux no kernel do Windows NT. Não havia necessidade de recompilar o código ou usar máquinas virtuais.
Não criamos apenas nossa própria distribuição Linux. O fato é que havia muitas dessas distribuições. A primeira versão do Linux disponível na WSL foi o Ubuntu. Entramos em contato com especialistas da Canonical para descobrir se eles gostariam de nos ajudar a trabalhar na WSL. Eles estavam entusiasmados com a nossa ideia. Isso levou ao fato de o Ubuntu aparecer na Microsoft Store. A propósito, a frase anterior, por si só, soa bastante incomum. Agora, na Microsoft Store, você pode contar 6 distribuições. Gostaria de saber que outras lojas de aplicativos disponíveis em determinados sistemas operacionais têm outros sistemas operacionais?
A Microsoft Store agora possui 6 distribuições Linux que podem ser usadas no WSLO código que escrevemos então era chamado de sistema de kernel compatível com Linux, que servia de interface entre os processos Linux e o kernel do Windows. O Linux tem cerca de 340 chamadas de sistema. A questão era decidir qual sistema chama para implementar primeiro. Como em qualquer sistema operacional, no Linux, novas chamadas de sistema são adicionadas à medida que novas versões do sistema operacional são lançadas, mas chamadas antigas nunca são excluídas, o que garante compatibilidade com versões anteriores. No início, o processamento de um determinado conjunto de chamadas do sistema foi implementado e todo o resto foi envolvido em eventos como "ainda não implementado". Isso permitiu à equipe da WSL começar a analisar exatamente o que o sistema chama os usuários de Linux precisam.
A resposta para a pergunta sobre quais chamadas do sistema devem ser implementadas em primeiro lugar significava a necessidade de estabelecer comunicação com as pessoas que usariam a WSL. A mensagem sobre essa tecnologia na conferência Build visava fazer as pessoas começarem a usar a WSL e fornecer feedback. Para adquirir a WSL, você precisava ser membro do Windows Insider Program. Qualquer pessoa pode se conectar a este programa. Você pode pensar que os participantes do programa eram apenas aqueles que estavam interessados no Windows, mas, entre mais de dez milhões de assinantes, havia pessoas com uma ampla variedade de interesses. Eles estavam interessados não apenas no Windows, mas também, por exemplo, jogos e novos recursos do Bluetooth e WSL.
Um dos grupos de usuários interessados em executar o shell Bash no Windows foi o desenvolvedor da web envolvido na criação de aplicativos da web que são executados nos servidores Linux. Todo o processo de montagem de aplicativos era frequentemente uma sequência de comandos do Bash. Além disso, se alguém decide pedir ajuda no desenvolvimento de aplicativos da Web, digamos, no Stack Overflow, a maioria dos exemplos de código que ele pode encontrar serão projetados para serem executados no Linux. Isso não é particularmente bom para quem usa o Windows como computador para desenvolvimento na web. Muitas vezes, é mais fácil para esses desenvolvedores simplesmente mudarem para a plataforma Mac. No macOS, exemplos de código semelhantes são executados sem problemas.
Nas duas primeiras semanas da presença da WSL no Windows, um usuário corporativo
conseguiu executar o XEyes. Este programa foi executado em um sistema de janelas X11 em execução na WSL. XEyes é um programa simples. Ela exibe olhos de desenho animado que seguem o cursor do mouse. Mas essa demonstração explodiu as redes sociais.
O XEyes é executado no Windows através do WSLDiscutimos muito sobre exatamente como queremos coletar análises de usuários sobre a WSL. A ferramenta tradicional usada para coletar feedback foi o UserVoice. Tínhamos um site UserVoice projetado para a WSL, que coletava centenas de idéias e milhares de votos em várias questões. A verdadeira questão surgiu quando se tratava de usar o GitHub. Como os desenvolvedores da web foram um dos primeiros grupos de usuários interessados na WSL, a questão do GitHub foi muito importante. Mas a WSL não era um projeto de código aberto. Colocar esse projeto no GitHub parece estranho. Decidimos atender aos requisitos dos desenvolvedores e criamos uma página no GitHub para relatar problemas, para feedback e discussões. Desde então, recebemos milhares de mensagens sobre muitos problemas relacionados ao uso do Linux no Windows.
Milhares de pessoas deixaram mensagens de erro no
repositório do WSL
GitHub . Cada uma dessas mensagens foi revisada e discutida pela equipe da WSL e foram feitos comentários sobre cada uma delas. Depois disso, foi tomada uma decisão sobre outras ações. Se, para obter uma certa oportunidade ou corrigir algum tipo de erro, era necessário escrever um novo código - esse código foi criado e adicionado ao projeto WSL, após o qual caiu em todos os assemblies do Windows distribuídos no programa Windows Insider. O ciclo inteiro, desde o recebimento de uma mensagem de erro até sua correção, não demorou muito tempo - cerca de duas semanas.
Como resultado, graças à resposta operacional da equipe da WSL às solicitações do usuário, foi possível dizer que a comunidade estava envolvida no processo de criação da WSL. As pessoas relataram problemas ou seus desejos por meio do UserVoice ou GitHub, a equipe revisou tudo isso e fez alterações no projeto, que apareceu nas compilações do projeto Windows Insider.
Quando entrei para a equipe da WSL como gerente de projetos, foquei em tirar a WSL da versão beta. Reclamações de usuários relacionadas principalmente à compatibilidade e desempenho. Mas, na minha opinião, se os usuários se preocupam com essas coisas, significa que eles usam seriamente o nosso desenvolvimento. O desempenho é resolvido apenas por aqueles que resolvem grandes problemas com a ajuda de um determinado sistema de software. Como resultado, embora ainda tivéssemos muito o que fazer, fizemos isso por um motivo, para que as pessoas pudessem resolver mais problemas usando a WSL e para que pudessem resolver seus problemas mais rapidamente.
À medida que os recursos da WSL começaram a se expandir, fizemos esforços para aproximar a WSL dos desenvolvedores, e não apenas dos usuários que tradicionalmente trabalham usando o ecossistema da Microsoft. Foi muito interessante participar de eventos como PyCon e OSCON. Os desenvolvedores que estavam presentes lá ficaram surpresos que os representantes da Microsoft também participaram desses eventos. Os desenvolvedores desconfiavam da idéia de executar o Linux em um ambiente Windows. Nesses eventos, mostrei o SQL Server, WSL e Visual Studio Code.
Demonstração da WSL em vários eventosRespondi aos comentários céticos com uma sugestão para tentar o que lhes mostrei. Quando os que duvidavam começaram a executar seus próprios comandos, pequenos scripts e trechos, sempre tive uma reação violenta ao que estava acontecendo: “Espere um minuto, e este é realmente o Linux. Como você fez isso? Por que eu não sabia disso? " Muitas vezes, eles chegaram à conclusão de que criamos algo que atende às suas necessidades, algo que parece muito interessante.
Levamos em consideração as reclamações dos usuários em relação à compatibilidade e desempenho da WSL e lançamos uma nova arquitetura de sistema -
WSL 2 . Ele oferece total compatibilidade com a inclusão do kernel Linux no Windows e fornece um aumento de 20 vezes na velocidade. Tive uma experiência interessante criando a base do WSL 2 e assistindo o anúncio dessa tecnologia na conferência Build, realizada em maio de 2019. Hoje, o projeto WSL já superou a versão beta e chegou à versão 2.
Além disso, trabalhei na Microsoft com outras equipes, tentando garantir que a WSL pudesse ser usada com seus produtos. Um exemplo significativo desse uso do WSL é o Visual Studio Code. Este é o ambiente de código mais popular usado no desenvolvimento de projetos JavaScript e Node.js. Fiquei interessado no Visual Studio Code quando percebi que os desenvolvedores que usam esse editor podem obter benefícios significativos da WSL. No início, não se tratava da necessidade de escrever grandes quantidades de código. O objetivo principal era simplificar a depuração dos programas Node.js em execução no ambiente WSL. Isso daria aos desenvolvedores a oportunidade de desenvolver programas projetados para a versão Linux do Node.js em um computador Windows usando WSL. Depurar esses programas seria exatamente como depurá-los no Linux.
Primeira tentativa de integrar o Visual Studio Code ao WSL e Node.jsDepois que isso foi possível para JavaScript e Node.js, começamos a receber muitas solicitações para que algo semelhante fosse feito para outras linguagens, por exemplo, para C ++ e Python. Fiquei fascinado com este exemplo da integração do WSL e do VS Code, e descobri que estava extremamente interessado nisso. Isso me levou ao meu novo papel na construção de ferramentas para desenvolvedores de Linux. Agora, concentro-me nas ferramentas para desenvolvedores de C ++ no VS Code. Neste trabalho, é claro, eu me concentro no Linux. Foi bom ver uma demonstração do Desenvolvimento Remoto de Código do Visual Studio no evento PyCon deste ano, quando a extensão WSL correspondente foi lançada. Ao mesmo tempo, uma extensão para C ++ foi introduzida, que minha equipe estava desenvolvendo.
Apesar de não ter passado tanto tempo na Microsoft, fico feliz por ter participado da criação de muitas ferramentas para desenvolvedores de Linux. Este banco de dados e suporte para Linux no Windows e ferramentas para escrever e depurar códigos. Pretendo continuar trabalhando no Linux e criar ferramentas que os desenvolvedores de todo o mundo gostem de usar.
Caros leitores! Você usa WSL?
