Ok, qualquer um que vem lendo meus artigos há um ou dois anos sabe como eu gosto do Arch Linux (em especial, o Manjaro Gnome). Eu também estou muito intrigado ainda com a ideia do Windows Subsystem para Linux (ou WSL), que estreou apropriadamente no Windows 10 Anniversary Edition, em meados de 2016.

Já se passaram quase dois anos e esperamos algumas atualizações significativas na compatibilidade e no desempenho do WSL para a próxima Spring Creators Update (ou versão 1803) que chegaram em abril. Isso aproxima mais o WSL dos programadores profissionais . Só para você ter uma ideia, agora você terá ordens de magnitude de melhor desempenho se rodar sua distro Linux favorita dentro do Virtualbox ou do VMWare Workstation.

Além disso, fora da caixa, o “Bash for Windows” só suporta oficialmente Ubuntu, Fedora e OpenSuse, eu acho. A maioria das pessoas apenas instalará o Ubuntu. E isso funciona bem. Para um brinquedo e para fins de demonstração legal, funciona. Mas realmente me frustra que eu possa fazer muito, mas não posso usá-lo como meu motorista diário. É como poder carregar o protótipo totalmente construído do próximo iPhone, mas ainda não há suporte para 4G, então é só um brinquedo.

Se você quiser apenas ver como é o desempenho em comparação com a minha configuração VMWare, vá direto ao final do artigo.

De qualquer forma, no caso das distros, usuários sérios do Linux prefeririam alternativas melhores. Entre neste repositório do GitHub:

Você acabou de baixar esse arquivo zip, descompactá-lo e rodar o Arch.exe incluído. E é isso!

Agora, você pode ir em frente e abrir a versão do Windows de “Bash”, e podemos inicializar o resto da instalação a partir daí.

Devemos pegar Pacman e algum gerente AUR. Para iniciar o Pacman, devemos fazer o seguinte:

pacman-key --init
pacman-key --populate
pacman -Syu

Yes! Pacman rodando nativamente no Windows! Quem teria imaginado?

Isso atualizará tudo. Em seguida, devemos criar um usuário não raiz:

useradd -m your_user
passwd your_user
EDITOR=nano visudo

Procure a linha que diz root ALL=(ALL) ALL e adicione seu usuário na próxima linha, desta forma:

your_user   ALL=(ALL) ALL

Finalmente, devemos fazer o login como este usuário:

su your_user

Em seguida, vamos instalar o Yaourt e usá-lo para instalar o Pacaur (essa é uma preferência pessoal, você pode simplesmente usar o Yaourt. Acho que o Yaourt pede de mais, é por isso que eu prefiro o Pacaur).

Comece editando seu arquivo /etc/pacman.conf com seus editores favoritos, como Vim ou Nano.

Basta adicionar a seguinte seção à parte inferior do arquivo:

[archlinuxfr]
SigLevel = Never
Server = http://repo.archlinux.fr/$arch

Antes de podermos prosseguir, temos um pequeno problema. O WSL ainda não tem suporte para SYSV IPC. Isso é necessário para o fakeroot, que é requerido pelo makepkg (que não pode ser rodado como root).

Para superar esse problema, é isso que teremos que fazer:

wget https://github.com/yuk7/arch-prebuilt/releases/download/17121600/fakeroot-tcp-1.22-1-x86_64.pkg.tar.xz
sudo pacman -U fakeroot-tcp-1.22-1-x86_64.pkg.tar.xz

E é isso, por enquanto! Até que o WSL adicione suporte adequado para SYSV IPC, podemos usar isso. O Yaourt em si provavelmente irá pedir para que você instale o fakeroot-tcp em cima dele. Apenas deixe.

Como eu disse, o Yaourt é bastante detalhista em suas muitas solicitações de confirmações. Regra de ouro: sempre que ele perguntar se você quer editar alguma coisa, basta dizer “N” (no). Sempre que ele vai perguntar se você deseja criar ou instalar algo, basta dizer “Y” (yes). Se você ficou irritado comigo, faça o seguinte:

yaourt -S pacaur

De agora em diante, vou supor que você tenha Pacaur.

Suporte gráfico para interface do usuário

Agora, vamos instalar alguns dos princípios básicos para um ambiente de desenvolvimento:

sudo pacman -S base base-devel gvim git

Ele irá pedir a você, por vezes, “default: all”. Basta instalar tudo. Espaço em disco rígido não deve ser uma preocupação em 2018.

Eu prefiro ter um ambiente completo no GNOME 3, então eu dou um:

sudo pacman -S gnome

Mais uma vez, deixe-o instalar tudo o que quiser. Todo mundo tem um gosto diferente quando se trata de GUIs. Alguns preferem o KDE5, outros preferem o XFCE4. Alguns até chegam a usar a GUI baseada em bloco i3.

Isso requer uma adaptação séria. É para pessoas que gostam de fazer coisas como usar um teclado tenkeyless, sem nada escrito nas teclas e usando um layout alienígena, como DVORAK ou Colemak. Gosto é gosto. E eu te desafio a se tornar um datilógrafo usando Maltron, eu te desafio!

Mas estou divagando. Agora, você pode adicionar isso ao seu arquivo /etc/.bashrc ou ao arquivo global/etc/environment:

echo "export LIBGL_ALWAYS_INDIRECT=1" >> /etc/.bashrc
echo "export DISPLAY=:0" >> /etc/.bashrc

Exporte-os para o seu Shell atual ou apenas feche e reabra o Bash.

Podemos ter um ambiente GUI completo instalando um X Server local. Você tem duas opções, Xming e VcXSrv. Estou tendo problemas para redimensionar janelas no Xming, então estou recomendando o VcXSrv. Basta baixá-lo e instalá-lo como você faria com qualquer aplicativo do Windows e iniciá-lo. Ele adicionará um atalho na área de trabalho chamado “XLaunch”, basta ativá-lo.

E, finalmente, podemos instalar um terminal utilizável e apropriado, ao invés daquela pobre engenhoca derivada do antigo cmd.exe que o WSL fornece pra você.

pacaur -S tilix-bin
tilix

Se você é usuário de Mac, provavelmente conhece o iTerm2, que é possivelmente o melhor emulador de terminal que já usei. Não há nada que chegue perto. Nada, exceto – possivelmente – o Tilix (anteriormente conhecido como Terminix).

Apenas por ter “Ctrl-Alt-D” para dividir o terminal horizontalmente para baixo e “Ctrl-Alt-R” para dividi-lo verticalmente para a direita, usar “Alt-1”, “Alt-2”, e assim por diante para alternar entre os terminais. É ótimo pra mim. Ele também vem pré-instalado com temas muito legais, como o agora clássico Dark Solarized ou o meu atual favorito Monokai Dark.

Não me xingue; eu sei. Alguns preferirão o aplicativo Terminal padrão e apenas adicionarão o TMUX. Mais uma vez, é uma questão de gosto (é mais útil se eu estivesse trabalhando em um servidor remoto).

Adicione a fonte Hack monotype para tornar tudo mais agradável aos olhos:

sudo pacman -S ttf-hack

Linguagens de programação

Vamos ver se as linguagens mais importantes estão instaladas corretamente. Como eu sempre digo, não procure mais do que o ASDF para essa tarefa.

git clone https://github.com/asdf-vm/asdf.git ~/.asdf --branch v0.4.3
echo -e '\n. $HOME/.asdf/asdf.sh' >> ~/.bashrc
echo -e '\n. $HOME/.asdf/completions/asdf.bash' >> ~/.bashrc

Reinicie seu terminal e continue:

asdf plugin-add nodejs
addf plugin-add ruby

Para o Node.js, você deve adicionar as chaves GPG apropriadas e só então você pode instalar:

bash ~/.asdf/plugins/nodejs/bin/import-release-team-keyring
asdf install nodejs 10.0.0
asdf global nodejs 10.0.0

O Ruby se beneficia com o jemalloc para alocar menos memória do sistema. Eu não tenho ideia se isso afeta o WSL, mas vamos fazê-lo de qualquer maneira:

sudo pacman -S jemalloc
RUBY_EXTRA_CONFIGURE_OPTIONS="--with-jemalloc" asdf install ruby 2.5.1
asdf global ruby 2.5.1
gem install bundler

Até aí tudo bem, se você precisar instalar um Ruby antigo (<2.4) para projetos legados, você deve fazer:

pacaur -S openssl-1.0
PKG_CONFIG_PATH=/usr/lib/openssl-1.0/pkgconfig RUBY_EXTRA_CONFIGURE_OPTIONS="--with-openssl-dir=/usr/lib/openssl-1.0" asdf install ruby 2.3.3

Infelizmente, ele precisa de uma versão do OpenSSL que você não deveria estar usando devido a problemas de segurança. Todos nós passamos para a versão 1.1. Mas o Ruby 2.3.x alcançou seu EOL (end of line – fim de linha, em tradução livre). Portanto, é por sua conta e risco continuar usando-o.

Bem, até aí tudo bem. Podemos instalar o Go também? Vamos ver:

asdf plugin-add golang
asdf install golang 1.9.5
asdf global goland 1.9.5

Podemos continuar, mas acho que você entendeu. Simplesmente funciona!

Trabalhos em segundo plano

Novamente, outra limitação atual do WSL (que esperamos ver corrigida no Spring Creators Update) é a capacidade de iniciar e continuar executando tarefas em segundo plano (daemons).

Dar um sudo systemctl para ativar postgresql e reiniciar não iniciará automaticamente o Postgresql em segundo plano como deveria. Essa coisa do Arch.exe que estamos usando não terá sequer o systemd.

Felizmente, servidores como Postgresql ou Redis funcionam normalmente. Eles podem ser iniciados como processos no nível do usuário e vinculados adequadamente às suas respectivas portas TCP, mas você terá que iniciá-los manualmente em todas as sessões. Feche o seu terminal Bash e todos eles serão encerrados.

Por exemplo, o Postgresql:

[your_user]# sudo pacman -S postgresql
[your_user]# sudo mkdir -p /run/postgresql
[your_user]# sudo chown -R postgres:postgres /run/postgresql

[your_user]# sudo -u postgres -i
[postgresql]# initdb --locale $LANG -E UTF8 -D '/var/lib/postgres/data'

[postgresql]# pg_ctl -D /var/lib/postgres/data start
waiting for server to start....2018-04-29 23:30:35.483 UTC [1064] LOG:  listening on IPv4 address "127.0.0.1", port 5432
2018-04-29 23:30:35.505 UTC [1064] LOG:  listening on Unix socket "/run/postgresql/.s.PGSQL.5432"
2018-04-29 23:30:35.583 UTC [1065] LOG:  database system was shut down at 2018-04-29 23:23:48 UTC
2018-04-29 23:30:35.660 UTC [1064] LOG:  database system is ready to accept connections

[postgresql]# createuser --interactive
Enter name of role to add: your_user
Shall the new role be a superuser? (y/n) y

[postgresql]# exit
[your_user]#

Viu o que eu fiz aqui? Há um pequeno problema na instalação sob o WSL, em que o /run/postgresql não é criado com as permissões corretas. Corrigindo isso é que podemos iniciar o servidor. Podemos sair da sessão su e o servidor postgresql continuará funcionando, mas quando fechamos a primeira janela/sessão de Bash, ele será encerrado.

E outra coisa muito irritante? As correções de mkdir e chown acima? Eu tenho que fazer isso toda vez que eu fechar o aplicativo Bash for Windows e iniciá-lo novamente!! Muito, muito irritante!

Mas podemos viver com isso por enquanto. Espero que isso seja corrigido em breve (caso não tenha sido ainda) ou em uma atualização futura.

Em um ambiente de desenvolvimento Rails, podemos aproveitar o Foreman para nos ajudar. Basta editar algum arquivo Procfile.dev:

web: bundle exec puma -C config/puma.rb -p 3000
db: su postgres -c 'pg_ctl start -D /var/lib/postgres/data'
redis: redis-server /usr/local/etc/redis.conf
mailcatcher: mailcatcher -f

Nesse ambiente de WSL comparável, acabei de instalar, estou executando exatamente o mesmo conjunto RSpec, e é isto que recebo:

Finished in 13 minutes 43 seconds (files took 3 minutes 16.8 seconds to load)
1474 examples, 0 failures, 35 pending


455.80s user 399.14s system 83% cpu 17:04.96 total

Por alguma razão, meu ambiente WSL está pulando alguns exemplos (parece mais um bug contador RSpec de algum tipo), mas eu acho que isso não deve representar muita diferença no grande esquema das coisas aqui. O WSL está perdendo, mesmo se o contador estiver correto e rodando menos exemplos.

Quando começamos a realmente exercitar o WSL, muitos problemas começam a aparecer. Por exemplo, o PostgreSQL enlouquece e mantém o stdout’ing ” could not flush dirty data: Function not implemented”, que é devido a esse problema documentado do WSL! Então, o que acaba acontecendo, é que às vezes o runner RSpec só faz uma pausa enquanto o PG tenta descobrir o que fazer.

Você pode ver claramente que, sob VMWare, os arquivos levaram menos de 15 segundos para carregar. No WSL, eles levaram mais de 3 minutos apenas no arquivo I/O! São ordens de magnitude mais lentas – essa é a parte ruim. Quando é apenas CPU vs CPU, eles são bastante comparáveis, na verdade.

No papel, o tempo total é realmente muito próximo. E em termos de CPU, acho que o WSL tem uma vantagem, e é por isso que é capaz de se recuperar nos totais, mesmo que I/O seja claramente lenta.

Na prática, o que acontece em uma situação de programação normal é que você ativa o vim ou qualquer outro editor de texto de sua escolha. Qualquer programador tem que continuar abrindo arquivos e indo e voltando entre muitos arquivos. Agora, com I/O sendo superlenta, todos os arquivos que você tenta abrir pausam sua ação por uma fração de segundo. E isso soma.

Dentro do VMWare, o vim é super-responsivo. Sempre que eu preciso abrir um arquivo, é quase instantâneo.
O benchmark pode ser difícil de explicar para essa situação. Mas, em um cenário normal, você vai acabar irritado. Além disso, executar uma GUI sobre X (VcXsrv, no meu caso) também atrasa as coisas um pouco. Dentro do VMWare, o Xorg normal pode aproveitar a aceleração da GPU. Portanto, todo o pipeline de rasterização é mais rápido.

Você “pode” usar o WSL como seu driver diário, mas se eu puder ter uma experiência mais suave dentro do VMWare, é nesse lugar em que estarei agora.

Conclusão

Tudo que eu preciso, funciona. Tilix, Vim, Git, Zsh, Ruby, Node.js. Tudo instala como esperado no Pacman e AUR. Pura glória do Arch Linux! Tão triste que o mau desempenho estraga isso.

Está perto, está muito perto! Pela primeira vez em quase 15 anos, quase me vejo voltando a 100% do Windows (sem suporte para VMWare) e ainda ser capaz de ser totalmente produtivo com ferramentas open source reais e profissionais que “Just Works”.

Fique de olho neste artigo para atualizações!

***

Artigo traduzido com autorização do autor. Publicado originalmente em: http://www.akitaonrails.com/2018/04/29/running-arch-linux-over-windows-10