Windows Subsystem for Linux (WSL): o que não posso fazer com o aplicativo Ubuntu para Microsoft Windows?

O Ubuntu que roda no subsistema Windows 10 para Linux não é uma distro completa. Na verdade, não é Linux - não tem kernel Linux. Portanto, você não pode testar ou experimentar extensões do kernel, incluindo drivers, porque não está executando o Linux .

Se você quiser fazer coisas assim, instale o Ubuntu em uma VM - o Win10 inclui o Hyper-V, mas pessoalmente, prefiro o VirtualBox, que é gratuito - ou inicialize sua máquina com o Ubuntu rodando no bare metal. Você quase certamente encontrará o último mais rápido do que executar o Windows - eu faço em todas as minhas máquinas. Em parte, isso ocorre porque você precisa de proteção antivírus ao executar o Windows, o que prejudica o desempenho, especialmente o desempenho do disco. E porque você precisa, o Win10 inclui antivírus integrado.

Com o Linux, você não precisa de nenhum, então há menos impacto no desempenho.

Existem muitas informações úteis sobre cada uma das respostas acima. Estou aqui resumindo os principais conceitos de cada um deles.

Atualização de abril de 2020 : os prós e os contras do uso do WSL são explicados aqui . Está claro por que ter um kernel Linux real é uma vantagem!! Além disso, aqui está um guia para instalar o WSL 2 no seu Windows 10. Se você instalou o WSL 1 e deseja passar para o WSL 2, aqui encontra as instruções para fazê-lo.

Atualização de agosto de 2019 : O novo WSL 2 foi lançado (leia aqui para mais informações). Parece que você pode trabalhar com um kernel Linux real e com um sistema de arquivos Linux. Sinceramente, ainda não experimentei a nova versão (está na minha lista TODO).

Atualização de maio de 2019 : conforme apontado em uma das respostas mais recentes, o WSL está evoluindo usando o Kernel Linux real e oferecendo muito mais opções. Já passei por esse documento e, se confirmado, será um grande avanço. Aqui você pode encontrar um bom artigo sobre o tópico "verdadeiro kernel do Linux no W10"

Resposta de julho de 2018 Resumindo: "Ubuntu no Windows é a área de usuário completa do Ubuntu em cima de um kernel do Windows no modo de compatibilidade com o Linux", como apontado em um dos comentários.

O que não posso fazer:

• Oficialmente, nenhuma interface gráfica suportada até agora. Isso também significa que aplicativos gráficos não podem ser executados. Além disso, as GUIs padrão do clássico Ubuntu baseado em Linux não são suportadas por esse motivo, é claro.
• O kernel do Linux desenvolvido pela Linus NÃO faz parte do Windows Subsystem for Linux (WSL). Isso significa que você não pode desenvolver drivers e testá-los diretamente.
• Nem toda linha de comando funciona.

O que eu posso fazer:

• Use a linha de comando e o shell Bash básico. É possível escrever e executar scripts.
• Desenvolva aplicativos (compile ou faça cross-compiling e execute-os), mas sem gráficos até o momento.
• Use "apt-get" para instalar/remover pacotes novos/antigos.

Informação adicional:

• outras distribuições são oficialmente suportadas (como, por exemplo, Debian e Kali)

• esses aplicativos são gratuitos, podem ser baixados da Windows Store e aqui você encontra as instruções para instalá-los e usá-los.

• Nesta outra questão do blog, algumas sugestões de como usar uma GUI para WSL (não oficial, de terceiros)

Uma das coisas que você não pode fazer facilmente no Windows Subsystem for Linux (WSL) é executar aplicativos da GUI do Linux.

Para fazer isso, você deve instalar um servidor X11 não suportado, como VcXsrv ou Xming.

Habilitar o WSL é relativamente trivial. Parece ser muito bom como um userland de linha de comando do Linux.

De How-To Geek :

[Ele] ainda não oferece suporte a software de servidor em segundo plano e não funcionará oficialmente com aplicativos gráficos de desktop Linux. Nem todo aplicativo de linha de comando funciona, pois o recurso não é perfeito.

Atualização do comentário de allquixotic :

A partir do Windows 10 v1803, as tarefas em segundo plano são suportadas.

Desde maio de 2019, o WSL 2 está em desenvolvimento .

O desempenho dramático do sistema de arquivos aumenta e a compatibilidade total de chamadas do sistema significa que você pode executar mais aplicativos Linux no WSL 2, como o Docker.

...

O WSL 2 usa uma arquitetura totalmente nova que usa um kernel Linux real .

...

As compilações iniciais do WSL 2 estarão disponíveis por meio do programa Windows Insider até o final de junho de 2019.

(grifo meu)

Quando esta pergunta foi escrita pela primeira vez, nem o WSL2 nem o WSLg haviam sido lançados, então a resposta hoje é certamente diferente do que era alguns anos atrás. Algumas dessas informações foram atualizadas nas respostas aqui, mas sinto que falta muito em outras respostas aqui sobre "limitações" reais.

Sou um grande fã da WSL, mas serei o primeiro a reconhecer que existem algumas limitações quando se trata da WSL. Felizmente, a maioria deles tem soluções alternativas, mas pegam a maioria dos novos usuários desprevenidos.

Para começar, deixe-me expor algumas "diferenças" entre o Ubuntu no WSL e uma instalação tradicional do Ubuntu em uma VM ou máquina física. Farei referência a alguns deles na seção "limitações" abaixo:

1. O WSL1 é executado como uma "camada de tradução syscall" que tenta traduzir as APIs do kernel do Linux para as do kernel do Windows.

2. O Ubuntu em execução no WSL2 age mais como um contêiner. Ele está sendo executado em um kernel Linux real em uma máquina virtual gerenciada (que você não pode acessar). O Ubuntu está sendo executado dentro de um namespace nessa VM. Não é, em si, executado diretamente em uma VM.

3. O WSL tem seu próprio sistema de inicialização. Seu trabalho principal (além de algumas tarefas de inicialização "normais" do Linux) é configurar a interoperabilidade entre o Linux e o Windows. Por exemplo, ele:

   • torna a rede do Windows disponível para o Ubuntu
   • adiciona o caminho do Windows ao ambiente
   • monta unidades do Windows no Ubuntu

4. Esse init é executado como PID1 dentro da instância/namespace/contêiner do Ubuntu WSL.

5. Iniciar o WSL não é como inicializar uma máquina virtual ou física. Muitas das tarefas que o Ubuntu faria normalmente (normalmente por meio do Systemd) durante a inicialização não são necessárias para o WSL ou são realmente prejudiciais à sua operação normal.

6. Não há conceito de "login" ao iniciar o WSL. O WSL detecta o usuário padrão e inicia automaticamente o shell definido para esse usuário em /etc/passwd. Nenhuma senha é solicitada ou necessária.

Limitações da WSL

Com isso em mente, aqui estão algumas limitações que posso pensar:

• init/Systemd: Ubuntu em execução no WSL não usa Systemd. O Systemd exige que ele seja executado como PID1, mas o init do WSL é executado como PID1. Muitos documentos, postagens de blog, etc. que você encontra para várias tarefas (por exemplo, instalar o Docker) assumirão que o Systemd está disponível. Existem várias soluções alternativas que mencionei nesta resposta .

  Além disso, os pacotes de software que estão profundamente enraizados e dependem do Systemd simplesmente não funcionarão, a menos que você recorra ao hack de namespace mencionado nessa resposta. Gnome é um dos exemplos mais comuns.

  Como outro exemplo pessoal, eu estava tentando executar cockpit(para uma interface da web para libvirtd) em uma distribuição não Systemd há alguns dias e simplesmente não consegui encontrar nenhuma maneira de contornar sua dependência do Systemd.

  Esta é certamente uma das principais áreas de confusão para novos usuários que chegam ao Ubuntu no WSL.

• Executando o Systemd no WSL2: Relacionado aos itens anteriores, se você tentar usar o Systemd, o processo de inicialização padrão do Systemd no Ubuntu (e praticamente qualquer distribuição) faz algumas suposições que não são válidas no WSL. Por exemplo:

  • O Systemd apagará os arquivos em /tmp, mas nesse ponto da inicialização, o WSL já criou um link simbólico para o conhecido soquete X11 no Windows 11. ( Nota de atualização: uma alteração em uma versão recente do WSL Preview torna isso uma montagem vinculada em vez de um link simbólico. Esse bind-mount pode ser remontado somente para leitura para evitar systemd-tmpfilesadulteração (encontrado no guia Arch Systemd)).

  • O Systemd configurará alguns binfmt_miscmanipuladores, substituindo o manipulador WSL que permite executar binários do Windows no WSL.

  • O Systemd redefinirá o ambiente do usuário, substituindo o caminho do Windows que foi anexado a ele.

  Se você planeja executar o Systemd (mesmo com um script "auxiliar"), recomendo fortemente que você tenha em mente que isso pode interferir em outras operações do Ubuntu no WSL e planeje solucionar problemas se e quando isso acontecer.

• Acesso ao hardware físico: No WSL, você terá acesso limitado ao hardware:

  • Portas seriais: WSL1 tem acesso a portas seriais em algum nível, mas apenas no que diz respeito às implementações de syscall. Dito isso, é possível executar algum software no WSL1 que utiliza as portas seriais que não são possíveis no WSL2.

  • Unidades físicas: no Windows 10, você só pode montar unidades por meio de um protocolo de rede ou unidades físicas conectadas ao Windows e formatadas em NTFS. Unidades brutas e aquelas que usam outros sistemas de arquivos não podem ser montadas.

    O WSL2 no Windows 11 tem a capacidade de montar tipos de unidades adicionais.

  • Gráficos: no Windows 10, não há acesso direto do Ubuntu no WSl a nenhum aplicativo ou interface gráfica. Se você deseja executar um aplicativo Linux gráfico no Ubuntu no WSL, deve instalar um servidor X de terceiros no Windows e executar o cliente/aplicativo X no WSL com as DISPLAYconfigurações apropriadas. Veja esta resposta e esta resposta para mais detalhes.

    Novamente, no Windows 11, o WSL2 agora tem a capacidade de executar aplicativos gráficos prontos para uso.

  • GPU: nas versões recentes do Windows 10, algumas tarefas de computação de GPU estão disponíveis usando uma biblioteca de passagem e os drivers de GPU do Windows .

    No Windows 11, algumas tarefas adicionais de computação de GPU foram adicionadas.

  • USB: os dispositivos USB não são diretamente acessíveis. No entanto, no WSL2 (tanto no Windows 10 quanto no 11), eles podem ser compartilhados do Windows usando USB/IP e anexados no Ubuntu.

    Observe, porém, que o kernel WSL2 padrão não inclui a maioria dos drivers de dispositivo para dispositivos USB. Por exemplo, mesmo os drivers básicos de captura de mídia (ou seja, câmera) não estão incluídos. No entanto, você pode criar seu próprio kernel para WSL2 e incluir os drivers necessários. No entanto, observe que atualmente, eu (e outros) não conseguimos capturar vídeo de uma câmera USB no WSL. Consulte esta pergunta no Stack Overflow para obter o progresso até o momento.

• Dispositivo de inicialização do Ubuntu: o disco/partição virtual de inicialização primário para Ubuntu no WSL deve ser formatado como ext4. Embora o kernel WSL2 suporte sistemas de arquivos adicionais, como btrfs, eles só podem ser usados ​​para partições secundárias.

• Tarefas que dependem de autenticação/login: devido a (6) acima, determinadas tarefas que dependem de autenticação se comportarão de maneira diferente no WSL. Por exemplo, normalmente você editaria /etc/security/limits.confpara aumentar os limites (por exemplo, número de arquivos abertos, prioridade/agradável, etc.) para um usuário. No entanto, este é um arquivo que é tratado pelo PAM (o "módulo de autenticação conectável") durante o login do usuário . Sem um login autenticado, este arquivo nunca é processado. Veja a solução alternativa nesta resposta se você se deparar com isso.

• Serviços de inicialização:

  • Windows 10: Sem o Systemd (ou outro init) para confiar, não há uma maneira fácil de definir quais serviços devem ser executados por padrão em uma instância do WSL. Por exemplo, o crondaemon não estará em execução (a fonte desta pergunta ). A solução é verificar e ver se um serviço está sendo executado na inicialização do shell (por exemplo ~/.bashrc, ) e iniciá-lo, caso contrário. Veja esta resposta para mais detalhes.

  • Windows 11: agora pelo menos inclui a capacidade de executar tarefas na inicialização. Veja também a mesma resposta para detalhes. No entanto, posso recomendar que você inicie um supervisor de processo como sua tarefa principal usando este método e, em seguida, use o supervisor de processo para iniciar e gerenciar outras tarefas necessárias. Menciono como fazer isso nesta resposta do Stack Overflow usando supervisord, mas qualquer supervisor de processo (que não exija que seja PID1, é claro) funcionará.

• Rede: embora isso possa pertencer à seção "hardware", provavelmente merece sua própria explicação aqui. A rede do WSL2 atualmente é executada em um comutador virtual dentro do Hyper-V, e esse comutador é NAT do restante da rede. Isso significa que você não pode acessar facilmente os serviços de rede no WSL2 de outros dispositivos (computadores, telefones etc.) na rede local sem esforço adicional.

  A solução mais fácil é usar WSL1 para isso quando possível. Existem várias outras soluções alternativas também.

• VPNs: Da mesma forma, ao conectar-se a determinadas VPNs que desativam o tráfego local, o WSL2 perderá a rede, pois é tráfego de rede "local" (mas não localhost).

• Teste de penetração : algumas tarefas de teste de penetração simplesmente não funcionarão com WSL1 (devido às traduções limitadas de syscall) nem com WSL2 (porque o hardware é virtualizado). Duas áreas se destacam aqui:

  • O acesso direto à interface wi-fi não está disponível (apenas um dispositivo ethernet virtual), portanto, as técnicas de quebra de senha WLAN não funcionarão. Como solução alternativa, deve ser possível instalar um dongle USB WiFi secundário, passá-lo via USB/IP conforme discutido acima e usá-lo dentro do WSL2. Observe que você precisará construir seu próprio kernel com os drivers apropriados para o dongle de rede.

  • Como o WSL2 está em uma rede de camada 2 separada do host do Windows (e do restante da rede), não será possível fazer nenhuma varredura de camada 2. A solução USB/IP acima também deve funcionar para isso.

• Desempenho: Em geral, o desempenho no WSL2 é muito bom. No entanto, existem algumas ressalvas:

  • WSL1: O WSL1 reduziu ligeiramente o desempenho em seu sistema de arquivos "pseudo-ext4/overlay". No entanto, o WSL2 atinge desempenho quase nativo em sistemas de arquivos ext4.

  • WSL2: O WSL2 sofre um grande impacto no desempenho ao acessar arquivos em unidades do Windows, especialmente arquivos pequenos e múltiplos. A verificação do kernel WSL2 em uma unidade NTFS leva mais de 10 minutos (mas ~ 30 segundos caso contrário). É altamente recomendável manter os arquivos do projeto no sistema de arquivos ext4 ou usar o WSL1 ao acessar as unidades do Windows.

  Eu mantenho uma instância WSL1 principalmente com o objetivo de trabalhar com unidades do Windows quando necessário.

Tenho certeza de que vou me lembrar de mais alguns (ou talvez alguém os aponte nos comentários) e os adicionarei, se necessário.

Novamente, com as soluções alternativas mencionadas, a maioria delas não são bloqueadores sérios para a maioria dos usuários do WSL. No entanto, eles são a fonte de muitas perguntas que respondi nos sites do Stack Exchange.