Agora senta que lá vem história.

Eu montei um PC até que razoável pra minha namorada: Intel i7 12th Gen de 8 cores, 32GB DDR4-2400, NVIDIA RTX 3090, placa-mãe MSI Edge z790, NVME e até coloquei um NAS Synology DS1621+ em rede 2.5Gbps - porque ela é criadora de conteúdo e tem MUITO video pra editar. Modéstia a parte, ficou bonito:

Tudo funcionou muito bem por bastante tempo, mas eventualmente, sem nenhum motivo aparente, tudo começou a parecer meio lento. Não totalmente lento, mas às vezes páginas web pareciam engasgar pra carregar. Clicava no menu Start do Windows e ele parecia dar umas travadas. Às vezes o Explorer travava e precisava ir no Task Manager e dar restart no processo manualmente. Várias coisas super inconvenientes mas que não dava nenhum “erro” explícito aparente. Só parecia “estranho”.

Eu sou usuário de Linux. Meu PC principal é Manjaro Linux. Só uso Windows nos meus mini-PC de games, exclusivamente pra rodar Steam e alguns emuladores. Eu evito ao máximo instalar qualquer coisa neles. Porque sei como é um saco diagnosticar Windows depois que algum programa estranho invade.

Fui olhar os suspeitos de sempre. Ela tinha instalado jogos pra fazer streaming, tipo Valorant, Genshin Impact e coisas assim. Eu sempre suspeito de anti-cheats, as porcarias do Riot Vanguard ou Easy ou VAC. Comecei desinstalando todos os games. Mas eu sempre acho que anti-cheat é que nem malware: uma vez instalado, nunca mais vai sair do sistema. Desinstalei tudo, mas continuou essa sensação de meio travando, meio lento, às vezes, intermitente.

Tentei os próximos suspeitos: software de periféricos, como os da Elgato, Logitech, Razr que instalam um monte de porcaria nas máquinas, e recentemente estava lendo sobre o malware que vinha em todos eles. Assistam este video do GamerNexus pra entender a casa de cartas que é toda a indústria de periféricos com RGB:

Mesmo desinstalando todos, ainda mesmo comportamento: meio lento, meio travando, instável.

Vamos tentar ir mais a fundo, pra isso tem que instalar ferramentas como da Sysinternals Autoruns pra ver se tem alguma coisa iniciando (coisas escondidas no Registry por exemplo). Tentei desligar tudo que eu achava suspeito.

Nada. A essa altura também já tinha garantido que firmware de BIOS mais nova da MSI estava instalado. Chequei se nada tinha desligado na BIOS, XMP profile tava ok, nada de fast-boot e coisas assim.

Será a Internet?

Como o uso maior é internet e ela parecia “lenta”, pensei que poderia ser problemas de rede. Roteador da Vivo? Plano? Wifi com interferência?

Ficando sem paciência resolvi ir nuclear na idéia de internet. De fato, abrindo a página da Cloudflare Speed Test eu via que a velocidade em si estava ok, mas a latência estava MUITO alta, jitter alto e, principalmente PACKET LOSS estava em mais de 15%. Não é normal isso, tem que ser 0%.

Aproveitei que fui pra Miami e já trouxe um roteador TP-LINK BE9300 pra Wi-fi 7, comprei uma placa PCIe de Wi-fi 7 compatível também. Desliguei o roteador de Wi-fi da Vivo e mandei subir o plano pra 800Mbps. E de fato, melhorou muito a internet:

Latência caiu, jitter caiu, packet loss foi pra 0%.

Mas isso não resolveu o problema. Do nada o navegador dava umas pausas na hora de carregar alguma página. Aquela sensação meio de lento, meio travando. E sim, tentei trocar de Edge pra Chrome, pra Firefox, pra tudo. Nada fazia diferença. A internet ficou mais rápida mesmo, mas o Windows em si não pareceu que melhorou muito e navegando, começava a ficar mais e mais lento. Então o problema não era internet.

Estava ficando sem opções. Tudo que poderia ser manualmente limpo no Windows, eu limpei. Já não tinha quase mais nada pra apagar - e eu apago as coisas sem dó. Mas eu sempre fico na cabeça que é algum malware, alguma coisa que carrega antes do boot, algum “ROOTKIT”. Anti-cheats são Rootkits por definição. Eles carregam antes até da kernel e a partir desse ponto, o sistema comprometido não pode ser mais confiado, porque nenhuma ferramenta vai conseguir achar ele.

Assumindo que nesse ponto deve ser um sistema comprometido, resolvi ir na opção nuclear: reinstalar tudo do zero. Fizemos backup dos dados e lá fui eu reinstalar do zero.

Reinstalar NÃO FUNCIONOU

Agora ficou pior.

Com o Windows 11 Pro, recém-instalado, garantidamente sem nenhum software de terceiros instalado, ainda assim estava com o mesmo comportamento de meio lento, meio travando. O menu de start não me deixava clicar em nada. Precisava abrir o task manager e matar o Explorer manualmente pra fazer ele voltar a funcionar.

Fiquei um tempo olhando pro Task Manager, mas não tinha nenhum processo rodando que eu poderia suspeitar mais: era Windows bare-bones. Eu até tinha rodado um Debloater pra desinstalar os apps desnecessários da Microsoft como Teams.

Mas eis que, de tanto olhar o task manager, eu vi que estava ignorando um dado importante. Veja se acham:

A imagem tá meio zoada porque eu tirei foto do monitor com meu celular. O refresh rate conflita com da câmera e fica essa “grade”, mas acho que dá pra ler.

Mesmo quando você não tem quase nenhum programa rodando, não é natural a CPU estar com clock tão baixo assim, 0.50Ghz - MEIO GIGAHERTZ. Esse Intel i7 é capaz de ir acima de 4Ghz e o clock-base é de 2Ghz.

Abri navegadores, abri abas, fiquei monitorando, e nunca subia pra mais de 1.5Ghz. Um ocasional pico de 2Ghz por 1 segundo e depois caía pra abaixo de 1Ghz de novo. Daí pensei: será que o AIO está falhando??

Olhando o Event Viewer dava pra ver quando o menu Start (que faz parte do Explorer.exe) parava de funcionar e travava: ele registra no log como “Hanging Events” código 1002.

Tá vendo esse monte de Error? Tudo Hanging Events, e “hanging” é justamente o comportamento: alguma coisa parece “segurar”, “travar” e só matando o processo pra ele voltar a funcionar.

E isso acontecia antes e também DEPOIS de resinstalar tudo do zero. Alguma coisa parecia fundamentalmente errada no hardware em si. Com o clock super baixo, esse comportamento começa a fazer sentido: está tão lento que ele não está conseguindo processar coisas básicas. Clique várias vezes no Start Menu (que vai ficar fuçando documentos recentes, atualizando lista de aplicativos, abrindo search bar, etc) e não tem clock pra processar isso enquanto ainda tem Windows Defender em background, abas de navegador processando.

Será Thermal Throttle??

Como o Windows está zerado, não pode mais ser anti-cheat, não pode ser anti-virus esquisito, não pode ser malware, não é a internet, é alguma coisa FORA, era o que fazia sentido.

Abri o PC e deixei aberto pra poder sentir se o dissipador estava ficando absurdamente quente. Se estiver, iria significar que meu AIO (Watercooler da Coolermaster) começou a falhar.

É normal quando a CPU super-aquece, ele derrubar o clock pra evitar queimar o chip. Isso se chama “THEMAL THROTTLING”.

E de novo esquisito: estava FRIO ao toque!!!

Não é possível. Abri a BIOS pra re-checar perfis de ventoinha, mas tudo normal:

Eis que finalmente me ocorreu:

**DEIXA EU CHECAR CONFIGURAÇÃO DE POWER**

Num PC/notebook normal, deveria aparecer algo parecido com isto:

Por default, Windows sempre sobe em “Balanced Mode”.

Mas no PC da minha namorada, não sei por que, não tinha opção de Power Mode!!! E eu estou num Windows 11 pro com licença paga!!

Isso é esquisito, mas eu sei que no antigo Control Panel, tem opção de Power Options:

E EIS O PROBLEMA:

Estava em “Power saver”!!!

Como isso aconteceu? Não tenho a mínima idéia. LEMBREM-SE: eu re-instalei o Windows do zero. Isso é logo depois de reinstalar!!

Em notebook faz sentido ter esse perfil, pra economizar bateria quando você não tem tomada. Mas em PC desktop, como é meu caso, não faz nenhum sentido!! Mudei pra “Ultimate Performance” e olha o task manager agora:

AGORA SIM!! Acima de 4Ghz!!!

O NORMAL desta CPU é estar na faixa de 4Ghz, com Turbo Boost de 5Ghz. Mas em Power saver mode, ele NUNCA sobe acima de 2Ghz e fica idling em 500Mhz. Ou seja, estava tudo DEZ VEZES MAIS LENTO, às vezes tentava dar boost e ficava ainda CINCO A DUAS VEZES MAIS LENTO. E é intermitente!!!

Testando instalar apps, navegar, etc, tudo agora está funcionando normalmente, sem travar, sem sensação de lentidão. Start menu não trava mais - porque agora tem CPU suficiente pra processar as porcarias que ele precisa em background.

Conclusão

CHEQUE POWER OPTIONS NO CONTROL PANEL!!!!

Repetindo: eu tinha ACABADO DE REINSTALAR O WINDOWS. Estava zerado e, por default, ele subiu em Power Saver mode.

Não tenho idéia de porque ele fez isso, não sei se ele sempre faz isso, não sei se ele não reconheceu a placa-mãe da MSI, não sei que combinação de fatores de hardware podem fazer o Windows dar fallback pra isso.

Mas é ALARMANTE que ele faça isso sem avisar. Não tem mensagem de erro. Não tem notificação. Não aparece no Event Viewer. Ou seja, mesmo um Power User como eu eu, precisa aleatoriamente suspeitar “hum, deixa eu ver o perfil de energia”.

Muita gente com Windows deve estar sentindo essa lentidão e travamentos e achando “hm, meu PC é porcaria mesmo, preciso juntar dinheiro pra comprar outro”, sem saber que talvez ele só esteja capado por esse perfil de energia e na verdade o PC dele é de 2x a 5x, até 10x mais rápido e ele não sabe disso! Não é uma diferença pequena!

POWER SAVER MODE é uma grande porcaria, não tem nenhuma utilidade prática e nem deveria existir. É uma das coisas legadas que fazem o Windows ter uma péssima experiência - porque ele não avisa.

Lembra os códigos de erros 1002 de hanging events? Se sair procurando no Google, todo fórum vai te dizer pra rodar programas de diagnósticos, desinstalar coisas, ou reinstalar o Windows. Nenhum cita nada sobre perfil de energia.

Espero que isso ajude mais alguém!

DESCRIPTION

Vale a pena usar WSL2? Por que Arch Linux?

Se quiser conhecer a fascinante de como Linux veio parar dentro do Windows, assistam meu video original sobre WSL2 onde eu conto todos os detalhes da história do Windows que você nunca conheceu: https://www.youtube.com/watch?v=28jHuWBi72w

Porém, a parte sobre a configuraçâo do Linux no WSL2 estão defasadas e pra corrigir isso fiz o video de hoje.

O Guia Definitivo de Ubuntu é um dos videos que vocês mais gostaram e continua válido, assistam se ainda não viram. O de hoje vai complementar aquele video com um novo setup mais moderno pra quem usa Windows e tem máquina suficiente pra instalar Linux em cima com WSL2. E não qualquer Linux, mas o venerado Arch Linux. Vamos ver um setup para desenvolvedores web que é enxuto e poderoso!

E pra quem conhece WSL2 já, vá até o fim pra uma dica de como organizar seu arquivo de projetos entre diferentes máquinas virtuais ao mesmo tempo com performance máxima!

== Conteúdo

• 00:00:00 - intro
• 00:01:03 - motivação: cuidado com Insider
• 00:02:46 - recapitulando WSL2
• 00:03:13 - máquina recomendada
• 00:06:01 - instalando WSL2
• 00:07:16 - qual distribuição Linux?
• 00:10:26 - meu problema com APT
• 00:12:52 - instalando ArchWSL
• 00:17:08 - temas do Windows Terminal
• 00:18:59 - Vim antigo e Vim moderno
• 00:22:56 - instalando NeoVim e LunarVim
• 00:26:38 - apresentando LunarVim
• 00:30:48 - porque não oh-my-zsh? starship?
• 00:32:02 - instalando YAY
• 00:33:08 - instalando ZSH, Nerd Fonts e Powerlevel10k
• 00:38:28 - instalando plugins (zsh-autosuggestions)
• 00:40:05 - instalando alternativas em Rust
• 00:42:17 - instalando e mostrando ASDF de novo
• 00:46:47 - instalando e mostrando Docker
• 00:49:48 - apps gráficas de Linux funcionam bem?
• 00:53:02 - WSL, mounts P9 e HDs virtuais
• 00:56:43 - usando HDs externos do jeito certo
• 01:00:04 - criando HDs virtuais
• 01:01:32 - habilitando Hyper-V (parte avançada)
• 01:02:15 - montando e formatando HDs virtuais
• 01:03:49 - montando HDs virtuais automaticamente
• 01:08:37 - bônus: não esqueça das chaves ssh
• 01:09:16 - repetindo: o que você deve fazer?

== Links

• Windows Insider (https://insider.windows.com/en-us/about-windows-insider-program)
• WSL Config (https://github.com/MicrosoftDocs/WSL/blob/main/WSL/wsl-config.md)
• Win10 Smart Debloat (https://github.com/LeDragoX/Win10SmartDebloat)
• Get Windows Terminal (https://www.microsoft.com/en-us/p/windows-terminal/9n0dx20hk701)
• Windows Terminal Themes (https://windowsterminalthemes.dev/)
• Arch Wiki (https://wiki.archlinux.org/)
• ArchWSL (https://github.com/yuk7/ArchWSL)
• VSCodium (https://vscodium.com/)
• Chris@Machine (https://www.chrisatmachine.com/)
• LunarVim (https://www.lunarvim.org/#opinionated)
• Powerlevel10k (https://github.com/romkatv/powerlevel10k)
• zsh-autosuggestions (https://github.com/zsh-users/zsh-autosuggestions)
• oh-my-zsh (https://ohmyz.sh/)
• How to install Yay (https://www.tecmint.com/install-yay-aur-helper-in-arch-linux-and-manjaro/)
• ASDF (https://asdf-vm.com/guide/getting-started.html#_1-install-dependencies)
• Nerd Fonts (https://github.com/ryanoasis/nerd-fonts)
• Rewritten in Rust: Modern Alternatives of Command-Line Tools (https://zaiste.net/posts/shell-commands-rust/)
• Docker Desktop (https://docs.docker.com/desktop/windows/wsl/)
• Mount a Linux disk in WSL 2 (https://docs.microsoft.com/en-us/windows/wsl/wsl2-mount-disk)
• How to create advanced tasks with the Task Scheduler (https://www.digitalcitizen.life/advanced-users-task-creation-task-scheduler/)
• How to Shrink a WSL2 Virtual Disk (https://stephenreescarter.net/how-to-shrink-a-wsl2-virtual-disk/)

SCRIPT

Olá pessoal, Fabio Akita

Um dos videos que vocês mais gostaram foi o meu Guia Definitivo de Ubuntu. A palavra “definitivo” nunca é definitivo de verdade, especialmente no mundo Linux onde as coisas mudam rápido. Faz muito tempo que fiz aquele video então hoje vou dar uma atualizada. Se você é iniciante em Linux, assista o video de Ubuntu porque tem coisas básicas que ensino lá que não vou repetir mais aqui.

Quero aproveitar e falar rapidinho de WSL 2, o Windows Subsystem for Linux, que também já fiz video algum tempo atrás. Então o de hoje vai ser configurar um bom ambiente de desenvolvimento web de Linux, que independe se está no WSL ou num Linux nativo, mas vou focar um pouco mais em WSL. Se quiser pular pra configuração específica de Linux, vá direto pra este tempo aqui embaixo e se já usa WSL2 ainda assim eu ainda tenho uma dica avançada no final. Consulte os capítulos do video e os links que complementam o conteúdo na descrição abaixo.

(…)

A motivação desse video é que recentemente eu reinstalei meu notebook do zero. O que aconteceu foi o seguinte: antes do Windows 11 ser lançado obviamente eu fiquei coçando pra experimentar. A Microsoft tem um programa chamado Insider. Se você se registra nele, vai habilitar o Windows Update pra baixar versões não-oficiais do Windows, versões beta ou mais instáveis ainda, em desenvolvimento. Eu fortemente recomendo contra fazer isso numa máquina de trabalho porque a chance de dar ruim é muito alta.

E justamente deu ruim comigo. As últimas versões Insider Preview quebram alguma coisa no suporte a Docker que ele sequer consegue inicializar o serviço. Dá um erro de timeout e crasheia. E não tá errado porque o povo do Docker ainda não teve tempo de corrigir seja lá o que a Microsoft mudou no Windows na versão em desenvolvimento. Não é culpa de ninguém. Esse é o propósito do programa Insider. O desenvolvedor do Docker pode ver o que o povo dentro da Microsoft tá mexendo e ir atualizando o Docker antes da próxima atualização oficial do Windows ser lançado, que pode ser daqui algumas semanas, pode ser daqui alguns meses. Eu que tava adiantado demais. É o mesmo motivo de porque em Linux recomenda-se sempre usar uma distribuição LTS, que é Long Term Support.

O problema é que a versão Insider Preview de desenvolvimento não tem como dar rollback pra versão estável anterior. Precisa fazer um clean install, instalar tudo do zero. Como o Windows 11 já foi oficialmente lançado, não tem porque eu ficar tendo dor de cabeça na versão Insider mais, então fiz o de sempre. Baixei o ISO da versão estável do Windows, queimei um pendrive, bootei e reinstalei tudo do zero. Agora estou com um Windows 11 limpo. Já que ia ter que instalar o WSL tudo de novo, aproveitei pra registrar tudo e mostrar pra vocês.

Vamos recapitular esse tal de WSL2. É uma camada de suporte pra facilitar e integrar uma máquina virtual Linux rodando sobre o hypervisor da própria Microsoft chamado Hyper-V. Máquinas virtuais e containers como Docker são coisas diferentes, por isso eu já tinha feito videos antes explicando a diferença entre os dois e recomendo que assista caso não saiba a diferença. Na prática é uma máquina virtual, só mais conveniente do que rodar dentro de um Virtual Box ou Virt Manager.

Por ser virtualização, significa que na mesma máquina estamos bootando um Windows e em cima dele bootando um Linux. Os recursos da sua máquina como disco, memória RAM, núcleos da CPU e GPU vão ser compartilhados entre os dois sistemas operacionais e por isso é mais pesado do que rodar só um dos dois sozinho. Não é recomendado rodar um WSL ou qualquer máquina virtual se tiver menos que 4 núcleos de CPU e menos de 8Gb de RAM.

Vai rodar se tiver menos? Vai, mas vai ser mais lento porque se faltar CPU vai ficar bem lento, se faltar RAM vai fazer swap em disco e isso vai deixar bem lento. O ideal é pelo menos, pelo menos, 8 núcleos de CPU e pelo menos 16Gb de RAM. Isso dito, não fiquem mandando nos comentários “ah, e minha máquina com 4Gb?”, faça a conta, 4 é menos que 8 que eu acabei de falar, vai ser lento. Se você não for fizer nada pesado, não tem problema, mas pra trabalhar vai ser super sofrido.

Se tiver máquina mais fraca, recomendo não usar WSL nem nenhum tipo de máquina virtual e sim instalar uma distribuição Linux mais leve como Puppy Linux ou Lubuntu. Não vai ser uma experiência bonita porque a intenção dessas distros é ser leve. Mas mesmo com uma distro que faça boot usando poucos recursos, se abrir um monte de abas no Chrome ou se começar a tentar subir muitos containers de Docker, super rápido vai faltar RAM e CPU e, de novo, vai ser uma experiência bem lenta.

Então pro resto do video vou assumir que você tem uma máquina com pelo menos um Intel Core i5 de 9a geração pra cima ou um Ryzen 5 de 3a geração pra cima e pelo menos 16 Gb de RAM com pelo menos SSD como armazenamento. Aliás, se tem uma máquina fraca e não tem dinheiro pra atualizar tudo, no mínimo do mínimo tente trocar seu HD mecânico por um SSD, é o que mais vai fazer diferença na performance geral. Em segundo lugar é aumentar RAM.

Meu notebook de trabalho que uso pra viajar é um Asus ROG Zephyrus G14. Ele tem um Ryzen 9 5900 HS com 8 núcleos e 16 threads, mais 40Gb de memória DDR4 e um NVME de 4 terabytes, portanto tem recursos mais que sobrando pra rodar um WSL2. Como falei antes, tá com Windows 11 recém instalado. E a primeira coisa que recomendo toda vez que se acaba de instalar Windows é rodar algum script de debloating, ou seja, um script que desabilita inutilidades como a telemetria que fica mandando dados pros servidores da Microsoft sem você saber. Também desabilita Cortana que ninguém usa e coisas assim que ficam roubando recursos da sua máquina.

Um dos scripts mais conhecidos é do LeDragoX. Não vou mostrar como rodar aqui porque tá explicado na página do projeto no GitHub. Se não conseguir seguir essas instruções, também não vai conseguir entender quase nada do video então sugiro que gaste 1 minuto pra tentar abrir a interface gráfica da ferramenta dele. Precisa saber o que é PowerShell, coisa que explico no meu video original sobre WSL2. Assiste lá depois.

Uma vez que desabilitamos o grosso de coisas que um Windows sobe automaticamente, mesmo assim ainda vai consumir quase 5Gb logo depois do boot. Por isso falei que com menos de 8Gb, no Windows, as coisas vão ficar lentas. Vamos começar instalando o tal WSL e se estiver nas versões mais recentes de Windows pode só abrir uma janela de PowerShell com permissões de administrador e digitar wsl --install. Agora vai tomar um café até baixar tudo e instalar os pacotes que precisa.

Não esqueça de instalar o Windows Terminal da loja da Microsoft ou usando algum instalador como o Chocolatey. Se você não é de Linux talvez não entenda ainda a importância de um bom emulador de terminal. No Mac temos o iTerm2, em distros Linux temos o Alacritty que é o melhor ultimamente, mas o Windows Terminal devo dizer que tá muito bem feito e na mesma categoria dos que acabei de falar. Obviamente use o WSL nesse terminal. Depois disso precisamos reiniciar o Windows, como sempre.

A instalação padrão de WSL já vai instalar o Ubuntu mais novo automaticamente e quando reiniciar vai pedir pra criar um usuário Linux. Esse passo é opcional, mas como não custa nada, vamos criar. Colocamos uma senha forte e pronto, estamos dentro de um Ubuntu, dentro do Windows. Se é sua primeira vez instalando WSL, essa visão deve ser bizarra.

Qualquer outro tutorial ia continuar configurando o Ubuntu, mas como sou eu, vou ignorar totalmente porque pessoalmente prefiro distros baseadas em ArchLinux. Sem me alongar demais, hoje em dia você tem 3 grandes famílias de distribuições Linux. Primeiro as baseadas em Debian, com pacotes formato DEB e o gerenciador APT como o Ubuntu, Elementary, Mint, Deepin, Pop OS.

Em segundo tem as baseadas no antigo RedHat, como o Fedora, CentOS, SuSe, com pacotes formato RPM e o gerenciador DNF. O mundo mais enterprise comercial tende a suportar o ecossistema RedHat, então a gente vê marcas como Oracle rodando seus sistemas num CentOS.

O Ubuntu meio que dominou os derivados de Debian. Debian era considerado uma das distribuições mais estáveis, mas pra isso ela sempre vinha com programas em versões um pouco mais defasadas. Lembra o que eu falei sobre o programa Insider do Windows? O Debian é como se fosse o Windows 10 quando já temos o Windows 11. Ele prefere estar mais atrasado pra não comprometer estabilidade.

Pra gerenciar isso o mundo Ubuntu tem o conceito de LTS. Por exemplo, no momento que estou gravando este episódio a versão mais nova do Ubuntu é a 21.10, mas a versão que eles recomendam como mais estável, e que vão dar suporte por alguns anos é a 20.04 que foi lançada 1 ano atrás. A esta altura a maioria dos principais software de Linux tem suporte ao Ubuntu 20.04 mas nem todos suportam a 21.10 ainda.

Ainda existem diversas outras famílias de distribuições que não são nem baseadas em Debian e nem em RedHat, como Slackware ou Gentoo. Mas essas são pra usuários mais avançados. Não recomendo pra iniciantes que ainda não tem costume de fuçar muito documentação e fóruns. Pra mim o melhor meio do caminho entre facilidade e coisas novas é a família Arch Linux que incluem distribuições como Manjaro, Endeavor, Garuda e outras.

Na dúvida eu sempre falo: escolha o Manjaro e seja feliz. O padrão no Manjaro é instalar com GNOME que é meio pesado, mas tem versão com KDE ou XFCE que são gerenciadores de janela mais leves e customizáveis. E você sempre pode instalar outras interfaces gráficas como o Cinnamon ou LXQT. Enfim, tem bastante coisa pra se divertir.

Uma das grandes vantagens do Arch é o gerenciador de pacotes Pacman e o AUR que é o Arch User Repository. Aqui vale uma explicação. Todo tutorial de Ubuntu por aí vai fazer você digitar um comando como apt install pra instalar algum pacote. Esse comando mantém um banco de dados com nomes e versões de pacotes que é atualizado sempre que se faz apt update. Ele faz isso se conectando nos diversos servidores oficiais da Canonical, que faz o Ubuntu, e atualiza os bancos de dados. Daí quando fazemos apt install vai em algum servidor e baixa o pacote do programa que quer instalar. Tudo costuma ser muito simples.

Mas isso implica que todo software do mundo precisaria estar registrado nesses servidores da Canonical, incluindo a versão mais nova e todas as antigas. É muita coisa pra uma empresa só conseguir catalogar e manter atualizado. Por isso é possível outras empresas terem repositórios próprios só com o arquivo de pacotes dos seus software em particular. Por exemplo, se quiser instalar o Docker, os pacotes não estão nos servidores da Canonical. Vamos abrir o tutorial de instalação oficial do Docker.

Tá vendo? Não é só um simples apt install docker, tem vários passos. Em resumo, primeiro precisa instalar alguns pacotes de infraestrutura do Ubuntu no passo 1. No passo 2 precisamos baixar a chave pública em formato GPG do Docker. Se não sabe o que é assinatura e chaves assimétricas, assista meus videos explicando o básico sobre criptografia. Mas em resumo, todo gerenciador de pacotes que se preza vai tentar garantir que você não instale malware de servidores falsos de hackers tentando se passar pelo Docker ou outra empresa.

Pra fazer isso eles assinam os pacotes e os dados transmitidos dos seus servidores usando chaves assimétricas. Eles assinam os pacotes com uma chave privada que ninguém nunca vai ter acesso. Daí instalamos essa chave GPG que é a chave pública. Tudo que a chave privada assina, só a chave pública consegue acessar e vice-versa. Um hacker não tem acesso à chave privada, então não vai conseguir assinar malwares.

No passo 3 precisamos indicar pra ferramenta APT onde está a listagem de pacotes nas mais diversas versões. Nessa lista tem coisas como versão mas também quais pacotes tem pra quais arquiteturas como x64 da Intel, ARM de Mac e assim por diante. Essa linha estranha é um comando pra adicionar um arquivo no diretório de sources do apt, que lista de onde que é pra baixar.

Finalmente no passo 4 fazemos primeiro um apt update pra baixar a listagem desse novo source e atualizar o banco de dados local e só agora podemos fazer o apt install. Quando fizer isso várias vezes, vai ficar meio automático, mas viu quantos passos precisamos fazer pra instalar um pacote que a Canonical não controla?

Como é instalar o mesmo Docker num Arch? Pra começar, a documentação existe no próprio wiki do Arch. E temos dois pacotes, ou o docker ou o docker-git que provavelmente é uma versão mais nova e potencialmente mais instável. Mas por padrão podemos fazer só pacman install docker. Pronto, só isso.

Pacman, assim como Apt ou DNF é um gerenciador e instalador de pacotes. E os repositórios do Arch costumam ter mais pacotes do que os equivalente de Ubuntu ou Fedora. E o que não tem, não precisamos fazer toda a burocracia de procurar um repositório de terceiros, instalar chaves e bla bla como fizemos no caso do Docker. A comunidade mantém um repositório de usuários que é o Arch User Repository ou AUR. A gente pode baixar um script de lá, que serve pra construir um pacote do zero e usamos pacman pra instalar. Mas tem um jeito ainda mais fácil que já vou mostrar.

Isso tudo dito, a Microsoft ainda não tem suporte oficial pra distros Arch no WSL, mas existe um projeto no GitHub chamado ArchWSL. Eu uso acho que desde 2018 e nunca tive problemas. É um Arch mínimo, mais leve que um Manjaro, mais leve que um Ubuntu. E a instalação é bem trivial. Pra isso vamos na página de GitHub do projeto baixar um zip que tem tudo que precisamos. Descompacte onde quiser mas eu costumo deixar na raíz do C: mesmo.

Agora abra um command prompt ou powershell no Windows Terminal, dê cd pro diretório onde descompactou o Arch e execute. Em dois segundos ele vai se registrar no WSL. Como o Windows Terminal já tava aberto ele ainda não detecta o novo Arch, mas basta reiniciar e voilá, já apareceu. O que eu gosto de fazer primeiro é configurar o Terminal pra sempre abrir o Arch primeiro.

Da primeira vez que entramos nele, estamos logados como usuário root que, como já expliquei no guia de Ubuntu, não se deve fazer. Lembra quando o Ubuntu oficial que o WSL instalou nos forçou a criar um usuário não-root? No caso do Arch vamos fazer isso manualmente. Uma das coisas que afasta muitos iniciantes do Arch é que ele nos obriga um pouco a saber o que estamos fazendo e não faz tanta coisa automaticamente. Por isso que é bom pra aprender.

No próprio GitHub do ArchWSL tem um link pra documentação. Vamos seguir e olha só. Daqui você não precisa de talento tampouco habilidade. Basta saber fazer copy e paste e saber ler. Vamos copiar esta primeira linha e colar no terminal com o Arch aberto. Isso vai configurar o arquivo sudoers pra permitir que comandos com sudo possam ser executados pra elevar privilégio a partir de qualquer usuário. O ideal não é abrir tudo pra ALL como fala aqui, mas como é máquina de desenvolvedor, não tem tanto problema. Depois estude sobre sudoers se não conhecia.

Em seguida são comandos básicos de useradd pra criar um novo usuário. Faça copy e paste mas obviamente digite um usuário com seu nome, né. Daí usamos o comando passwd passando o usuário que acabamos de criar pra configurar uma senha segura. Abrimos outra aba com um command prompt, e podemos fechar a que estava com o Arch aberto, porque precisamos configurar o WSL pra quando abrir o Arch de novo use o usuário que acabamos de criar em vez de `root. Então mais um copy e paste.

Pronto, se abrir o Arch no terminal de novo e dermos o comando whoami diz que é o novo usuário. A partir daqui, se precisarmos fazer alguma coisa que exija permissão de root é só começar o comando com sudo. E a primeira coisa que se deve fazer logo que se instala uma distro linux é atualizar todos os pacotes. No caso deste Arch, precisa fazer algumas coisas antes. De novo, a documentação já diz tudo. Só copiar e colar esses comandos de pacman que vai inicializar e popular as chaves que o Arch usa pra checar os pacotes.

O pacman é um pouco chatinho pra quem nunca viu porque não tem comandos fáceis como install, em vez disso o equivalente é -S maiúsculo que significa “sync”. Daí adicionamos a opção y que se não me engano é pra atualizar o banco de dados com as listagens do servidor oficial do arch. E a opção u é pra atualizar os pacotes. E eu faço yyuu duplicado pra forçar mesmo se já estiver tudo atualizado. O normal é fazer só -Syu sem duplicar, mas quando alguma coisa dá problema ou agora, que é primeira vez, acabo fazendo assim.

E esqueci de fazer uma coisa, então vamos dar control-C pra cancelar e abrir o arquivo /etc/pacman.conf com o editor nano. Procurar a palavra Verbose e adicionar uma nova linha embaixo dizendo ParallelDownloads = 5. Por padrão o pacman baixa um arquivo de cada vez e isso é bem demorado. Se você tem uma boa internet banda larga, pode testar, mas por volta de 5 downloads simultâneos ou até mais, aguenta. Agora sim, vamos repetir o comando do pacman pra atualizar tudo, e agora vai ser mais rápido.

Ele vai checar tudo que precisa ser atualizado, mostrar a lista de pacotes que vai baixar e pedir pra ir confirmando. Olha só como mostra 5 pacotes sendo baixados simultaneamente. Bem mais rápido, mas aí temos esse problema aqui. Um erro de chaves que ele não reconheceu. E isso porque eu fui burro e a documentação do ArchWSL tá incompleta. Faltou fazer pacman -S archlinux-keyring que instala as chaves mais novas que precisa pra instalar os pacotes. Então vamos instalar e repetir o comando de atualizar tudo.

Agora sim, foi até o fim. E é isso. Temos um Arch Linux rodando no WSL 2. Fim do video! Brincadeira. Antes de continuar, vamos deixar nosso terminal um pouco menos feio. Tá tudo com fundo preto. Pra mudar isso podemos ir no site windows terminal themes .dev. Dêem uma fuçada. Eu pessoalmente gosto do “Moonlight II” ou variações de “Monokai”. Clique em “Get Theme” e ele vai copiar pro clipboard.

No Windows Terminal faça “ctrl-virgula” ou na setinha na barra de título escolha “Settings”. Lá embaixo tem a opção de abrir o arquivo de configurações que é em formato JSON. Abre no Notepad mesmo por enquanto e vai lá pro fim. Logo embaixo do último tema, garante que tem uma vírgula e cole o novo tema. Cuidado pra não quebrar o JSON. Não precisa reiniciar, só salvar o arquivo. Agora seleciono o “Arch” no menu e vamos pra “Appearance”. Pronto, posso selecionar o “Moonlight II” e embaixo posso aumentar a fonte pra 16 só pra ficar mais fácil de ver aqui no video.

Falando em editor, o próximo passo é instalar um bom editor de textos. Na prática, basta instalar o Visual Studio Code que ele se integra plug and play com o WSL. Vamos ver? Vai na loja do Windows mesmo, procura por Visual Studio, seleciona e instala. Pra ter a integração com o terminal precisa fechar e abrir de novo. Pronto, basta ir pra algum diretório e digitar code . e olha só como abre o Visual Studio listando os arquivos de Linux.

O VSCode funciona super bem e se você prefere uma versão mais light e com mais privacidade, procure pela alternativa chamada VSCodium, que é a mesma proposta do Chromium em relação ao Chrome. VSCode e Chrome tem a péssima mania de se comunicar com servidores da Microsoft ou do Google, respectivamente, e ficar comunicando coisas que não sabemos. O VSCodium e Chromium desligam essas comunicações desnecessárias. Se você é do tipo mais paranóico com privacidade, instale essas alternativas.

Mas de vez em quando ainda prefiro ficar só no terminal mesmo. E hoje em dia ainda não tem nada melhor do que Vim na minha humilde opinião. Esse nosso ArchWSL já vem com vim pré-instalado. O básico que você tem que saber é que ele tem um modo de edição e um modo de navegação. Dá pra ficar horas falando de vim e no video de Ubuntu já mostrei o básico. Se nunca tentou, recomendo que dê uma chance de verdade. Acho importante conhecer o básico de Vim pra mudar a perspectiva do que um editor de textos realmente deveria fazer.

O Vim foi criado numa época onde se usava terminais remotos em redes super lentas. Por isso não existia o conceito de IDEs como um Visual Studio. Seria pesado demais. Quando conversei com o Uncle Bob a gente falou disso, recomendo que assistam nossa live que está gravada no canal. Mas por isso o Vim padrão parece tão espartano, com comandos super curtos, pra minimizar ao máximo os comandos enviados ao servidor a partir do terminal remoto.

Aliás, é por isso que este programa que estamos usando, esta janela do Windows Terminal se chama terminal ou, mais corretamente, emulador de terminal. É um terminal remoto que se conecta com o servidor de terminal rodando por baixo dos panos, localmente. O “Linux” em si não roda “dentro” desse programa, por isso podemos fechar o Terminal mas o Linux em si continua rodando por baixo. E quando abrimos um novo Windows Terminal, ele conecta de novo no servidor por baixo. Pense no Linux como se fosse um servidor web e o terminal como se fosse um navegador web, é o mesmo conceito.

Enfim, o Vim na verdade é a evolução do editor original que se chamava só “Vi”, do Bill Joy, que era da Sun Microsystems. Já o Vim é um fork do Brian Moolenar. Depois do Vim versão 8 surgiu um fork dele chamado de NeoVim que tem a proposta de modernizar o Vim, em particular modernizar o código-fonte, que tem coisa de décadas atrás que nem precisamos mais e funcionalidades que hoje são possíveis. Uma das coisas que adicionaram faz poucos meses foi suporte à linguagem Lua.

O Vim sempre teve plugins escritos numa linguagem própria chamada VimScript, que é uma linguagem bem feia e chata de trabalhar, meio como scripts em Bash. É super antiquado, super fácil de criar bugs acidentais. Por isso pouca gente tem paciência pra escrever plugins nessa linguagem. Já Lua é uma linguagem mais moderna e madura, muito mais difundida, especialmente pra quem programa games. Além de ser uma linguagem super leve e fácil de embutir em qualquer programa.

Tem um canal no YouTube que recomendo que assinem, do Chris at Machine. Ele veio acompanhando essa nova integração e criou um projeto no GitHub chamado LunarVim, que é uma coleção de plugins escritos em Vim e uma configuração super completa que transforma o NeoVim praticamente num Visual Studio Code, só que mais leve e mais produtivo. E “praticamente” porque uma das características mais importantes do VSCode são seus servidores de linguagens.

Explicando bem curto e porcamente, o VSCode foi inteligente em fazer um editor que por si só é leve e não tem suporte a nenhuma linguagem. É um editor neutro se não configurar nada. Mas quando instala um plugin pra linguagem Ruby, por baixo ele instala um SolarGraph como servidor. Daí o VSCode passa a ser um cliente desse servidor que vai analizar o código Ruby que estamos digitando e dar suporte a coisas como autocomplete, debug, e mais. E cada servidor de linguagens diferentes vai implementar o Language Server Protocol ou LSP que é a API que o VSCode entende.

Agora, se eu pegar outro editor e fazer ele entender o protocolo LSP, dá pra usar os mesmos servidores. Por isso consigo trocar o cliente VSCode e substituir por NeoVim. LSP é como se fosse HTML, o VSCode é como se fosse o navegador Chrome ou Edge e o NeoVim poderia ser como o Firefox, sacaram? E o tal LunarVim que o Chris fez já pré-instala todos os plugins necessários pra integrar com LSP. Então vamos instalar pra ver.

Primeiro, precisamos do NeoVim. E hoje a versão que tem no repositório oficial já serve. Meses atrás precisava compilar o NeoVim manualmente porque não estava disponível esse suporte na versão oficial, só na beta. Pra instalar no Arch é fácil, só fazer sudo pacman -S neovim e veja como lista pacotes de Lua. Sabemos que é a versão que precisamos.

Quando terminar de instalar, vamos pra página no GitHub do LunarVim e tem um script instalador pra facilitar nossa vida. Só copiar essa linha e colar no terminal. E de cara já começa reclamando que não temos Git instalado. Bora instalar pacman -S git como ele manda.

Esse script vai ajudar a instalar as dependências que precisamos. A primeira coisa são pacotes de javascript, daí reclama que não tem nodejs instalado então vamos fazer sudo pacman -S yarn npm pra instalar… Agora com a seta pra cima repetimos o instalador do LunarVim e damos yes e pronto, tá usando o yarn pra instalar o que precisa.

No próximo passo pede pra instalar dependências de Python e como já temos pip instalado, prossegue instalando o que precisa… Essa foi fácil, e no passo seguinte ele quer instalar dependências de Rust, mas não temos Rust então o instalador pára de novo. Vamos fazer sudo pacman -S rust pra poder usar o cargo pra instalar as ferramentas de Rust.

Assim como yarn é instalador de dependências de Javascript, pip é instalador de dependências de Python, o cargo é instalador de dependências de Rust. O Rust é uma linguagem compilada que gera binários nativos super otimizados e com segurança superior à de C puro. E no meio da instalação ele deu um erro. Parece que não conseguiu compilar o jemalloc-sys ou pam.

Eu já tinha ido no Google antes e o que aconteceu é que o Rust se integra com binários compilados em C também e nesse ponto ele precisou compilar alguma coisa de C só que não instalamos o ferramental pra isso ainda. Num Ubuntu isso seria o pacote build-essential, mas não existe no Arch. O equivalente é sudo pacman -S base-devel. Só ir dando yes no que tá perguntando, mas sempre leia antes, lógico.

Pronto. Seta pra cima, vamos repetir os mesmos passos tudo de novo. Ele sempre passa pelos passos de javascript e python mas agora é mais rápido porque já instalou esses passos. O Rust volta a compilar o que falta e agora …. vai até o fim. Mas atenção que fala que precisa colocar o diretório $HOME/.cargo/bin no PATH senão não vai achar as ferramentas que acabou de compilar. E no final o instalador também avisa que não vamos usar o comando nvim que inicia o NeoVim normalmente mas sim o lvim e pra isso precisamos adicionar o $HOME/.local/bin no PATH. Eu explico o que é PATH no episódio do guia de Ubuntu.

Só pra agora podermos ver o LunarVim, vamos exportar o PATH manualmente adicionando esses dois diretórios… Pronto. Agora podemos abrir lvim e olha só que diferença. No LunarVim apertamos “espaço” pra abrir esse menu e com a opção “e” de “explorer” temos um painel com o projeto organizado como árvore, todo configurado com ícones e bem bonito. Podemos navegar pra cima e pra baixo com as teclas “j” e “k” e com a tecla “o” podemos abrir o arquivo embaixo do cursor.

Vamos abrir o arquivo “config.lua” pra adicionar uma configuração pra corrigir um pequeno bugzinho que essa versão ainda tem com esse negócio de abrir menu com “espaço”. Ele é rápido demais e pode dar conflito com outras combinações de teclas então colocamos vim.opt.timeoutlen = 500 milissegundos como gambiarra pra contornar e pronto.

O video de hoje não é sobre Vim então não quero me alongar demais nele, mas acho que vale a pena fazer uma pequena tangente pra mostrar um pouquinho de porque instalei o LunarVim. Então vou me adiantar um pouco e abrir um projetinho besta em Rails antigo meu só pra dar exemplo. Primeira coisa é que posso fazer ele ficar parecido com uma IDE apertando espaço, que abre esse menu principal, e com “e” eu abro o explorer do lado, que é o plugin NvimTree. A partir dele posso usar o mouse normalmente pra abrir arquivos.

Por acaso abri um arquivo de Ruby. Lá embaixo dá pra ver a mensagem de “LSP inactive”, ou seja, não tem nenhum servidor de linguagem analisando este arquivo. Mas se esperar alguns segundos, olha só, assim como o VSCode, o LunarVim achou um LSP de Ruby, no caso o Solargraph, e instalou sozinho e a partir daqui todo arquivo de Ruby que eu abrir ele vai analizar.

Pra abrir mais arquivos, posso voltar pro painel do explorer com o mouse, ou como eu prefiro, com o teclado fazendo ctrl+h pra ir pro painel da esquerda ou ctrl+l pro painel da direita, e os mesmos comandos de navegação como “j” pra ir uma linha pra baixo ou “k” pra uma linha pra cima funcionam igual. E com “o” posso abrir o arquivo embaixo do cursor.

Mas esse explorer usa muito espaço, então posso fechar ele. Em vez de usar o explorer posso abrir o menu principal com “espaço” e apertar “f”, que vai abrir o plugin Telescope que usa a ferramenta “fd” que é uma das que ele instalou de Rust no começo, lembram? E posso fazer um fuzzy find direto do nome de algum arquivo, como “archives” e abro o controller.

Notem que o editor parece meio poluído à primeira vista, mas isso é o solargraph que analizou o código e fica dando dicas e avisos de coisas que podem melhorar ou bugs óbvios que precisam ser corrigidos. Toda linguagem moderna hoje tem um LSP que faz essas coisas. Por exemplo, nesse trecho ele fala pra evitar usar chaves num bloco de múltiplas linhas, em Ruby é mais bonito usar “do-end” em vez disso, e pronto, o aviso sumiu.

Outro exemplo é a sintaxe de atoms em hash que mudou desde a versão 1.9 do Ruby, antes era usando um fat arrow, hoje é usando dois pontos que nem um JSON. E mesma coisa, substituir chaves por “do-end”. E aqui embaixo ele fala pra não fazer comparação com zero e sim usar o método “empty?” pra checar se a variável está vazia ou é zero.

Além disso, ele nos ajuda quando temos dúvida numa função. Aqui eu digito ponto e ele já me dá uma lista de métodos que a String aceita. E se eu sair navegando, ele até me dá a documentação da função caso eu não me lembre ou tenha dúvidas. E se for digitando, ele vai filtrando na lista até eu achar o método que eu estava precisando. Tudo coisa básica que se você já usou uma IDE moderna já tinha, mas agora disponível dentro do terminal no vim.

E só como último exemplo de coisas avançadas, alguns LSPs tem recursos de refactoring. Vamos procurar o arquivo do model chamado Post. E se eu quisesse renomear essa classe de Post pra Article e não ter que ir abrindo arquivo a arquivo de todo lugar que a classe Post é usado? Posso abrir o menu principal com espaço, apertar “l” pra abrir o sub-menu do LSP e olha que ele tem “rename”. Lá embaixo eu mudo de Post pra Article e deixo o LSP trabalhar.

Notem que lá em cima apareceu um monte de aba de arquivos que ele abriu. Ele ainda não salvou nada. Só abriu todo arquivo onde aparece a classe Post e substituiu por Article. Abrindo aquele mesmo arquivo do ArchivesController, olha como onde tava Post agora tem Article no lugar direitinho. Mesma coisa no PostsController e assim por diante. Eu devo ir checando e salvando um a um pra garantir que fez tudo certo e, lógico, no final eu teria testes automatizados pra garantir que nada quebrou. Mas é uma das coisas que uma IDE como o LunarVim consegue fazer. E isso foram só 2 minutos de demonstração, tem bem mais coisas por baixo pra facilitar nossa vida.

Se você se animar a dar uma chance pro jeito Vim de navegar, em breve vai conseguir programar sem precisar ficar tirando a mão pro mouse toda hora. É muito mais confortável e até mais ergonômico de trabalhar. Além disso ele renderiza tudo em modo texto dentro do Terminal, o que usa muito menos recursos do seu sistema do que o VSCode que, por baixo, é tão pesado quanto um navegador web, como programas feitos em Electron. O VSCode, recém instalado, logo que abre já consome de 250 a 300 mega de RAM. O LunarVim fica na faixa de menos de 150 mega. É quase metade de recursos. Mas claro, hoje em dia depende mais dos LSP que rodam por trás analisando seu código.

Voltando pra nossa instalação, precisamos configurar o PATH de forma permanente e pra isso é só adicionar o mesmo comando de export que fizemos no arquivo .bashrc. Mas eu pessoalmente prefiro o shell ZSH. Eu sei, tem alguns que vão comentar sobre o Fish, mas eu ainda gosto do ZSH mesmo. Pra quem não sabe, além de Bash existem outras linhas de comando ou shells e suporte a scripts diferentes. O Bash é meio antiquado pra hoje, mas não tem nenhum problema de ficar nele.

No video do guia de Ubuntu eu baixei um conjunto de dotfiles de um usuário chamado skwp pra customizar meu prompt, vim e tudo mais, mas ele é muito pouco suportado e hoje em dia existem opções muito melhores. Essa é a parte do video antigo que ficou desfasado. Mesmo na época já existia o Oh-my-zsh que eu testei por um tempo, mas nenhum dos plugins foi muito importante pra mim e acho um pouco pesado. Muita gente gosta de usar só o starship, que faz um prompt até que minimalista e bonitinho de ver.

Meu preferido e o que achei mais fácil de instalar e configurar é o Powerlevel10k. Antes precisamos instalar uma outra ferramenta de Arch Linux pra facilitar nossa vida. Lembra dos pacotes que a comunidade mantém no AUR que mencionei? Pra instalar direto de lá não dá pra usar Pacman. Tem vários gerenciadores de AUR mas o que mais gosto é o Yay. E muitos tutoriais mais novos já assumem que você tem yay. Dá pra saber que um artigo aleatório é mais antigo se em vez de yay ele manda usar yaourt, que é desafado. Então vamos lá.

Na página de GitHub do Yay vamos descer pras instruções. A primeira coisa é instalar os pacotes de git e base-devel, mas acabamos de instalar então pula. Próxima linha é fazer git clone do projeto. Eu prefiro dar cd pro diretório temporário do sistema porque não vamos usar esse clone pra mais nada depois de instalar. Feito o clone damos cd pra ele e “make package” com opção pra instalar logo depois de construir o pacote. Lembram o que eu expliquei? O AUR não tem os binários nos servidores, só a receita de como montar o pacote de determinado programa. Uma ferramenta com o Yay vai automatizar o que acabamos de fazer manualmente, que é dar clone do projeto, montar o pacote e instalar com pacman localmente.

Pronto, com o Yay instalado praticamente não precisamos usar mais o pacman porque ele serve pra instalar tanto pacotes oficiais dos repositórios do Arch quanto do AUR, usando a mesma sintaxe do pacman. De exemplo, vamos instalar o shell ZSH, que vamos usar no lugar no Bash. Basta fazer yay -S zsh, nem precisa de sudo, ele se vira.

Agora vamos pra página de GitHub do PowerLevel10K. Mesma coisa, pulamos pra seção de Instalação e veja como tem instruções pra várias distros. Queremos do Arch. Simples, duas linhas e ele já assume que temos o yay instalado, então copiamos a primeira linha e colamos no terminal… pronto. No final ele recomenda instalar algumas fontes. Acho que não faz diferença dentro do terminal, mas pode instalar como fiz aqui. Vai fazer diferença se usar aplicativos gráficos de Linux iniciados de dentro do WSL, como o VSCode de Linux. Mas falo disso depois.

Seguindo as instruções é só executar essa linha de comando que vai inserir a inicialização do powerlevel10k no script .zshrc que é o equivalente .bashrc só que pra zsh, obviamente. Podemos fechar essa aba, abrir outra e … nada acontece. Isso porque por padrão sempre inicia o Bash, precisamos usar o comando de Linux de “change shell” que é chsh -s /usr/bin/zsh pra da próxima vez executar direto o zsh em vez do bash…

Pronto, agora fechamos a aba, reabrimos e como é a primeira vez, o powerlevel10k abre esse wizard de configuração. E a primeira coisa que ele pede pra gente confirmar é se estamos vendo um ícone com formato de diamante. Mas em vez disso estamos vendo um quadradinho, que nem quando vemos fontes quebradas numa página.

Isso porque ele espera encontrar uma família de fontes que tenham gráficos além de só letras. Chamamos essas famílias de Nerd Fonts. Se você é web designer ou desenvolvedor front-end sabe disso. Acho que foi o GitHub que inventou isso de embutir gráficos como fonte. Isso porque sites como o próprio GitHub usam dezenas de pequenos ícones em todo lugar. Em vez de fazer dúzias de PNGs que além de ser um saco de gerenciar também prejudica a performance do download de assets da página, eles tiveram a idéia de embutir todos os ícones em uma família de fonte, que a gente baixa tudo de uma vez só, como a Font Awesome e fica muito mais fácil de usar em qualquer lugar, não só em sites, porque os emuladores de terminais modernos são capazes de renderizar essas fontes também.

Além disso foi a época que Emojis começaram a popularizar, que nada mais são que um padrão onde imagens são associadas com códigos Unicode dentro da família de fontes. Então o mesmo código sempre vai devolver o mesmo emoji independente da família de fontes que estamos usando. Mas a fonte que o Windows Terminal usa por padrão que é a Microsoft Consolas, não tem nenhum desses ícones, por isso devolve um quadradinho pra indicar que não encontrou. Existem várias fontes que você pode pesquisar depois que tem esses ícones com o Fira Code mas eu pessoalmente gosto do Meslo LGS.

Na própria página de instruções do Powerlevel10k tem links pra baixar os arquivos de fonte, então vamos lá baixar uma a uma… Pronto, agora vamos no explorer no diretório de downloads, selecionamos todos os arquivos que acabamos de baixar, e escolhemos pra instalar as fontes no sistema… E pronto, agora podemos ir no Windows Terminal, abrir de novo a aba de configurações, escolhemos o Arch, escolhemos a aba de aparência e finalmente podemos trocar o Consolas pelo Meslo LGS.

Agora sim, abrimos uma nova aba. Vai carregar o ZSH que, por sua vez, vai carregar o Powerlevel10k. Como não prosseguimos a configuração da última vez, vai pedir pra começar de novo e desta vez veja como aparece o ícone de diamante. Nos próximos passos ele pede pra confirmar que estamos vendo os outros ícones e daí podemos continuar o passo a passo. E aqui vai do gosto de cada um. Vou passar rapidinho o que eu costumo escolher, mas recomendo que vocês experimentem opções diferentes. No final vai gravar tudo que escolheu no arquivo de configuração .p10k.zsh.

Se não gostou do que escolheu basta digitar p10k configure na linha de comando pra chamar esse passo a passo tudo de novo ou editar manualmente o arquivo .p10k.zsh. Mas no final, olha só como ficou o meu prompt. Com ícones aqui na esquerda, mostrando o diretório onde estou. Se eu estiver num projeto de Git vai mostrar a branch também. Lá na direita mostrando a hora, mas quando entrar num projeto de código ele mostra outros ícones indicando a linguagem do projeto, a versão dessa linguagem e coisas assim.

Agora não podemos esquecer de configurar o PATH no arquivo .zshrc, assim podemos ter acesso ao LunarVim e qualquer nova ferramenta instalada pelo Cargo do Rust. Pode abrir com qualquer editor como o VSCode mas neste video sempre vou usar o NeoVim. Só adicionar o export no final do arquivo e não esquecer que a variável $HOME é um atalho pro diretório padrão do seu usuário e no final anexar o que já tinha no $PATH antes… Pronto, veja que neste instante se chamarmos lvim não vai achar. Mas agora abrimos outro terminal e boom, abriu o LunarVim como deveria.

O powerlevel10k é bem flexível pra customizar o visual como quiser, e eu gosto do passo a passo do que ter que ficar ajustando arquivo de configuração manualmente. Só tem que fazer isso uma vez e esquecer. Mas como eu disse dá pra customizar o zsh pra ficar bem mais complexo com um oh-my-zsh e colocar vários plugins. Depende de que tipo de trabalhos mais faz no terminal, então não deixe de fuçar que plugins existem. Mas tem um que eu acho útil e por isso vou instalar manualmente agora. Quem usa a shell Fish já tem isso automaticamente.

Vamos instalar que eu mostro pra que serve. No diretório do seu usuário, que você sempre volta fazendo cd sozinho, vamos criar um diretório chamado .zsh pra instalar o plugin. Agora vamos na página de GitHub dele. Tem link pra outra página com instruções de instalação. Olha como tem instrução pro Oh-my-zsh, mas queremos a forma manual. O primeiro passo é clonar o projeto pro diretório que criamos, então é só copiar essa linha de git clone e colar no terminal.

Queremos que toda vez que o zsh carregue, também carregue o plugin então temos que editar o arquivo .zshrc de novo. Copiamos a segunda linha das instruções e podemos colar no script. Salvamos e pronto. Mas pra carregar agora mesmo, é só executar a linha que copiamos que ele carrega o script do plugin. Pra que serve isso? Vamos fazer um comando idiota de echo. E se eu quiser repetir o mesmo comando?

Posso copiar o que acabei de digitar e colar ou, começo a digitar e e ele consulta no histórico e vai tentando auto completar. Olha como já apareceu aqui. Agora é só dar tab ou seta pra direita e vai completar tudo. Isso é super útil porque o tempo todo estamos repetindo os mesmos comandos e eles ficam no histórico da sessão. Isso é um bom exemplo de plugin útil.

Como o LunarVim já pediu pra instalar algumas ferramentas feitas em Rust e já colocamos no PATH onde o Cargo instala os binários, podemos aproveitar e instalar mais algumas ferramentas modernas. Se procurar no Google vai achar vários artigos a respeito mas vou usar este entitulado Rewritten in Rust junto com os outros links na descrição do video. Depois leiam com calma, ele lista diversas novas ferramentas feitas em Rust.

Por exemplo, logo de cara tem os que eu mais gosto, por exemplo o bat, que é um substituto do cat que usamos pra listar o conteúdo de arquivos texto. Ou o exa que é substituto pro ls que usamos toda hora pra listar arquivos de diretórios. Em seguida ele fala do fd que é uma alternativa mais performática pro find e que o LunarVim já instalou porque o plugin Telescope usa. Além do fd o LunarVim também instalou o rg ou RipGrep que é um grep mais performático.

Podemos instalar usando o pacman ou o yay mas vamos instalar usando o Cargo mesmo. Basta fazer cargo install e passar todas as ferramentas que queremos. Olha só o cargo baixando, compilando e instalando… e no final deu alguns problemas. Ele não conseguiu instalar o ytop, dust e delta. Pode ter algum bug nos repositórios mas não me incomodei pra procurar porque não são essenciais. Os principais que eu queria eram o bat e exa.

Vamos testar. Primeiro, olha como é a saída do ls normal de Linux. Uma listagem normal de arquivos e diretórios, nada demais. Agora vamos usar o exa com as mesmas opções de -la. Ele não aceita todas as opções iguais do ls só as mais comuns e veja só como ficou BEM mais bonito. E pra cereja no bolo tem a opção --icons, e olha só como ficou ainda MAIS bonito. Depois que a gente vê assim, não dá vontade de usar o ls padrão mais. Eu não testei, mas tudo tem trade-off, não sei se um diretório com milhares de arquivos vai ficar mais lento de listar. E também se quiser capturar a listagem num arquivo texto pra trabalhar depois, daí é melhor não usar o exa.

Mesma coisa com o cat. Vamos listar o conteúdo do script .zshrc. E como sempre, listado, nada demais. Mas e com o bat? Olha só como ficou BEM mais bonito. Mas mesma coisa: se precisar trabalhar com o conteúdo do arquivo num script é melhor usar o cat normal. O bat é só pra visualizar mais bonito.

Mas como eu uso ls e cat só pra visualizar no terminal mesmo, prefiro até substituir eles com aliases, e pra isso vamos abrir o .zshrc. Só quero adicionar alias pra dizer que quando eu digitar ls no terminal o zsh vai na verdade chamar o exa e mesma coisa pro cat sempre chamar o bat. Isso é opcional, mas só pra saber que dá pra fazer isso.

Agora que nosso terminal tá bonitão, hora de instalar o ASDF. Não vou me alongar nessa parte porque já expliquei em detalhes sobre isso no guia de ubuntu e vai ser exatamente a mesma coisa agora. Pra quem não lembra, no dia a dia de programador a gente nunca usa uma única versão de alguma linguagem ou framework em todos os projetos. Podemos estar programando um projeto em Node.js versão 16, mas aí alguém me reporta um bug num projeto mais antigo que tava no Node.js 14. Eu preciso ter os dois instalados na minha máquina.

Pra isso existem ferramentas como o NVM pra poder ficar trocando de versão de Node. Mas e se eu precisar mexer também num projeto de Python? Daí vou precisar instalar e configurar o VirtualEnv. Mas amanhã talvez eu tenha que ajudar no front-end de um projetinho em Rails, aí preciso instalar também o RVM ou Rbenv. E assim vai. Cada linguagem tem um gerenciador de versões diferente. Em vez de ter que lidar com essa zona toda, posso instalar o asdf, que tem plugins pra dezenas de linguagens e nunca mais usar outro.

No Arch é fácil, basta fazer yay -S asdf-vm… Ele vai instalar no diretório /opt/asdf-vm e pra ativar precisamos fazer source /opt/asdf-vm/asdf.sh. Pronto, tá ativado e precisamos colocar essa linha no .zshrc pra toda ver que abrirmos o terminal ter o asdf carregado. A partir daqui é como já mostrei no video de ubuntu. Com asdf list podemos ver todas as linguagens e versões instaladas. Como ainda não instalamos nenhuma, tá vazio. Então vamos instalar o plugin de node com asdf plugin add nodejs.

Pronto, agora podemos fazer asdf list-all nodejs e ver que a versão mais recente hoje é a 17.4.0 então vamos fazer asdf install nodejs 17.4.0 e boom, instalado. Só pra fazer graça, podemos instalar uma versão mais antiga também, por exemplo com asdf install nodejs 16.13.2. E depois que instalar rodamos asdf list e ele mostra que temos as duas instaladas direitinho.

Pra escolher uma delas configuramos uma como versão global mas o certo é configurar por projeto. Pra dar exemplo, vamos pro diretório tmp criar um diretório falso de projeto chamado de teste. Dentro podemos fazer asdf local nodejs 16.13.2. Vamos listar o que tem no diretório e achamos o .tool-versions que acabou de ser criado. Dando um cat vemos que está declarada a versão que pedimos. Toda vez que entrarmos nesse diretório o asdf vai usar essa versão específica de Node.js independente do que for a versão global. E fazendo isso em todos os projetos, sempre vai mudar pra correta que cada projeto precisa.

Pra complementar, vamos adicionar Ruby agora. Só adicionar o plugin com asdf plugin add ruby. Mesma coisa de antes, vamos listar todas as versões disponíveis de Ruby e é uma lista gigante porque no meio tem versões não oficiais como o truffleruby, rubinius, jruby mas lá em cima vemos que tem a versão de desenvolvimento do 3.2.0 que ainda não é estável então vamos fazer asdf install ruby 3.1.0. Ruby costuma demorar um pouco mais pra instalar, acho que baixa o código fonte e compila. Boa hora pra ir pegar um café.

Agora que tá instalado, se der asdf list mostra o Ruby também. E assim você pode ir instalando plugins de diversas outras linguagens como Rust, Kotlin, Python, Clojure e tudo mais e instalar versões específicas de cada uma. E como disse antes posso dizer que quero que essa versão 3.1 seja o global com asdf global ruby 3.1.0. Agora todas as ferramentas de ruby que usarmos, a partir de qualquer diretório, vai estar apontando pra essa versão.

Por exemplo, vamos usar o comando gem que vem com todo Ruby e instalar o framework Ruby on Rails fazendo gem install rails. No final ele vai instalar o comando rails, então vamos de novo pro diretório temporário do sistema e executar rails new teste_rails pra criar um novo projeto. Vai demorar um pouquinho pra instalar todas as dependências, mas no final podemos dar cd pro novo diretório. Olha só, tudo funcionando e se quisermos perguntar a versão do ruby ativo, ainda é o 3.1.0.

Como eu não declarei o arquivo .tool-versions se amanhã eu atualizar o ruby global pra 3.2, esse projeto vai pegar 3.2. Se eu quiser travar pra versão específica o certo é rodar o asdf local pra criar o arquivo .tool-versions. Estou me alongando nisso porque é comum você atualizar o sistema, vem versão nova da sua linguagem, e de repente seu projeto começa a dar problema porque você não se tocou que tá rodando uma versão diferente. Por isso é boa prática ter declarada a versão correta em todo projeto mesmo se não usar asdf.

Bom, agora que temos o ASDF e acesso a instalar linguagens, o último grande passo é instalar Docker. Antigamente eu preferia instalar banco de dados como postgres ou redis nativamente no sistema operacional, mas era mais por hábito mesmo. O ideal é não instalar esse tipo de serviço localmente, mesmo porque o WSL não tem um systemd pra controlar boot de serviços. Melhor usar Docker e configurar Docker Compose em todo projeto pra subir versões específicas de tudo que precisa.

Assim como várias coisas podem quebrar quando você pula de Node 16 pra Node 17, um banco como Postgres tem funcionalidades diferentes por versão. A versão mais nova do Postgres no momento que estou fazendo este video é a 14, mas ainda tem muito projeto rodando na versão 9. Você não pode desenvolver na versão mais nova porque pode acabar dependendo de funcionalidades que não existem na 9, daí quando subir em produção, vai dar pau. Repetindo, declare a versão correta de cada coisa no manifesto de um Docker Compose.

Se fosse um Arch Linux nativo fora do WSL, a instalação não seria muito mais do que um yay -S docker, mas no caso do WSL tem um passo extra que é baixar e instalar o Docker Desktop antes. Então vamos no site oficial, baixar o instalador e instalar… Não precisa mudar nada na instalação, vai só prosseguindo … ele vai baixar os componentes, vai configurar o WSL pra ter os grupos e permissões direitinho e no final vai pedir pra deslogar e logar de novo. Então vamos fazer isso.

Toda vez que se logar no Windows, o Docker Desktop vai ficar carregado aqui embaixo na barra da tarefas. Certifique-se que ele tá carregado antes de usar. Mas da primeira vez vai abrir essa janela aqui pra aceitar os termos de serviço e só depois inicia. Não tem nenhuma configuração muito importante que precisa mudar, do jeito que veio já tá bom, com exceção de uma coisa que vou mostrar já já.

Agora podemos abrir o terminal e fazer o yay -S docker pra mandar comandos pro servidor que acabamos de instalar. Mas se tentarmos rodar docker ps vai dizer que não conseguiu se conectar. Vamos abrir o Docker Desktop de novo e ir nas configurações. Aqui no item de Resources e WSL Integration tá marcado pra dar suporte pra minha distro default de WSL que vai ser aquele Ubuntu que instalou automaticamente primeiro. Então precisamos habilitar aqui embaixo pro Arch. Pronto.

Se tentar rodar o mesmo comando, vai dar outro erro mas agora é de permissão. Isso porque quando mudamos aquela configuração, por baixo dos panos ele criou o grupo de docker e adicionou meu usuário nele, mas pra termos a permissão precisamos sair e entrar de novo. Então fazemos isso e veja só, o docker ps agora roda sem problemas e listou que não tem nenhum container rodando. Então vamos seguir o exemplo que o Docker Desktop sugere na primeira tela. Só copie essa linha e cole no terminal.

Demora alguns minutos mas ele vai baixar a imagem de um site que vai carregar na porta 80. Deixa baixar e executar. Agora podemos ir no navegador e digitar localhost pra conectar na porta 80 e voilá, ele baixou um site com documentação pra iniciantes. Se você ainda é novo no Docker, é um bom lugar pra começar a estudar. Leia tudo que tem aqui.

Por último, o novo WSL2 tem um novo recurso que vai facilitar muito sua vida quando for rodar testes automatizados com coisas como Selenium ou Cypress, que abrem um navegador de verdade com o Chromium pra testar sua aplicação. Antes já tinha como rodar aplicações gráficas manualmente instalando um cliente de X no Windows como o X410 mas agora o WSL2 já tem suporte nativo.

Só instalar a aplicação que quiser e executar que vai abrir de boa. Infelizmente ainda não tem suporte estável pra fazer pass thru pra GPU da sua máquina então tudo vai rodar 100% via CPU e isso certamente vai ser mais lento do que o navegador nativo no Windows. Mas como é pra cenários como de testes automatizados que falei, tá mais que bom.

Pra instalar é normal, só ir no terminal e fazer yay -S chromium, vai demorar porque o pacote é grandinho, mas é só isso. Vamo lá, vamo lá, acelerar um pouco aqui, e pronto. Agora é só digitar chromium no terminal e olha só, abre bonitinho como qualquer aplicação gráfica. Podemos carregar o YouTube e carrega rápido. Se abrir um video toca sem problemas no meu notebook inclusive com som. Tá sem som aqui porque eu tirei na edição mas pode acreditar que tem som.

Tem um site que costumam usar pra fazer benchmark de navegador, o Speedometer, mas do que já usei dele sei que é bem pouco confiável. Já rodei o teste múltiplas vezes no mesmo navegador e dava resultados bem diferentes, mas só por diversão vamos rodar nesse Chromium. Isso é o cenário que falei de testes automatizados. Ele vai circular por dezenas de aplicações de todo list feitos em diversos frameworks como Angular, React, Ember e outros. Acelerando um pouco o resultado final foi 172 pontos.

Agora vou abrir o Microsoft Edge aqui do lado e carregar o mesmo teste. Vamos ver. Vamos acelerar um pouco aqui com um pouco de mágica de edição e boom. Olha só que bizarro, o Chromium rodando virtualizado ganhou. Mas lógico, meu Edge tá cheio de extensions, cheio de abas abertas, e o Chromium tá recém instalado, totalmente vazio. De qualquer forma, na prática, a performance dentro do WSL tá muito boa. Daria até pra usar como segundo navegador.

Só pra mostrar onde o Chromium via WSL chora é se tentar rodar qualquer coisa 3D nele, por exemplo, um aplicativo em WebAssembly como o Google Earth. Olha só como fica lento, absurdamente lento, é literalmente inusável. E não tinha como ser diferente porque o WSL ainda não tem integração com aceleração 3D da máquina, é tudo renderizado pelo CPU. Mas se eu abrir o Edge que perdeu no Speedometer e carregar o mesmo Google Earth, olha a diferença. Roda liso, praticamente sem perder frames. Essa é a diferença de ter aceleração via GPU. Mas de novo, se você não estiver mexendo com games ou modelagem 3D, pra sites normais, não faz tanta diferença assim.

As novas versões do WSL tem suporte experimental a drivers de paravirtualização de GPU da Nvidia e Amd pra rodar projetos de machine learning em containers de Docker, como Tensorflow ou PyTorch. Eu mesmo não brinquei com isso ainda, não é estável nem garantido que vai funcionar, mas se alguém aí tiver inclinação pra escovar bit pra ver se funciona, vou deixar o link nas descrições também. Mas pra maioria de nós significa que se tiver aplicações gráficas de Linux que você precisa rodar no Windows, agora tem mais uma opção também, só não precisar de aceleração 3D.

E já que estou falando de coisas que foram adicionadas recentemente no WSL, tem uma que gostei muito. Pra mostrar, tem duas últimas coisas que eu faço sempre que reconfiguro um novo Linux. A primeira é copiar minhas chaves privadas que ficam no diretório .ssh, pra ter acesso às minhas contas de Heroku, AWS, GitHub, GitLab e tudo mais. Eu expliquei sobre chaves no episódio de Ubuntu e nos de criptografia. Você precisa tomar muito cuidado pra nunca ninguém pegar essas chaves. De qualquer forma, quando configuro máquina nova, eu zipo as chaves e copio.

A segunda coisa é copiar minha pasta de projetos. Normalmente você não precisa ter tudo, projetos que nem mexe mais. Com as chaves no lugar, é só dar git clone dos projetos que precisa pra agora e tá ótimo. Mas eu quero dar um exemplo do que é possível fazer com o novo WSL. Vamos dar contexto. Lembram lá no começo do video que instalei o Arch no diretório C:\arch? Pois é. Vamos abrir o explorer de novo e temos um arquivo chamado ext4.vhdx. Esse é o “HD virtual” do Arch Linux que instalamos e estamos usando agora. Olhem como o Arch é levinho, com tudo que instalamos tá ocupando menos de 7 giga.

Esse é o melhor jeito de lidar com HDs virtuais, eles são arquivões binários. E eis porque eu fiz uns 4 videos explicando tudo que um programador deveria saber sobre dispositivos de armazenamento, particionamento, formatação e tipos de filesystems diferentes, porque agora vou assumir você entende o que é um HD virtual. Caso não saiba definir o que é uma partição ou qual a diferença de um filesystem ntfs ou ext4, recomendo que assistam os videos. Mas vamos lá.

Voltando pro terminal, o WSL automaticamente monta seus HDs de verdade, como o seu C:, dentro do diretório /mnt. Então se navegarmos pra cd /mnt/c e dermos um ls, vai listar exatamente o que tem no seu C:. E aí você pode ficar com a idéia errada de deixar seus diretórios de projetos no Windows e trabalhar neles de dentro do WSL. E isso seria uma péssima idéia. Isso porque esse mount que ele fez é parecido com conectar com um servidor de arquivos via rede, mais especificamente usando o protocolo P9 em vez de CIFS. Toda operação de arquivos nesse mount vai ser lenta, porque tem um overhead a mais por cima.

O lado oposto também dá. Do Windows acessar os arquivos dentro do Linux. Só abrir o explorer e digitar “\wsl$” e pronto, podemos ficar copiando arquivos do Windows pro Linux e vice versa, tanto via terminal quanto via explorer. Mas como eu disse, é como se fosse uma pasta compartilhada na rede, mesmo sendo local, ainda vai ser uma ordem de grandeza mais lento. Especialmente projetos web que tem centenas de arquivos pequenos. O melhor sempre é transferir um zip grandão via rede do que centenas de arquivos pequenos.

A melhor performance é dentro do HD virtual montado diretamente, aquele arquivão VHDX. Lá dentro a velocidade é quase a mesma que nativa, tem muito pouco overhead. Tanto que ficamos aqui instalando pacotes, editando arquivos e tudo mais e a sensação era que estava rodando tudo nativo. Então o mais prático é fazer git clone dos seus projetos lá dentro mesmo e nunca jogar pra fora a partir no /mnt/c. Mesmo se conectar um HD externo que vai montar como /mnt/d, é a mesma coisa, vai ter overhead.

Em 90% dos casos você nunca vai ter nenhum problema se ficar dentro do hd virtual. Mas se for que nem eu que vira e mexe quer mudar de distribuição Linux, mover tudo pra outra máquina ou coisas assim, se tiver muitos arquivos pra ficar movendo, vai ser super lento e demorado, pode levar horas ou mais. O ideal seria alguma coisa tipo um HD externo montado direto. Mantém tudo fora, daí se quiser reinstalar a máquina não tem problema e não demora porque tudo que não era instalação de aplicativos já tava fora.

E se quiser usar um HD externo, o WSL agora suporta montar direto. Vamos ver esse cenário primeiro. Eu tenho um SSD com um adaptador pra USB. Quando conecta no notebook, o Windows detecta e monta como drive D:. Normal, todo mundo já viu isso quinhentas vezes. O que a maioria de vocês não sabe é como o Windows controla isso por baixo. Vamos abrir um Powershell com privilégios de administrador primeiro, alguns comandos que vamos usar a partir de agora vai precisar.

Desde a época do Windows 2000 existe a ferramenta wmic que é o Windows Management Instrumentation Command. É uma forma de instrumentar o Windows sem precisar usar aplicativos gráficos. Quando estamos vendo o drive D: isso é um mount point, um ponto de montagem como no Linux que monta dispositivos como diretórios como no /mnt/c. No Linux os dispositivos de verdade ficam declarados no diretório /dev e seu HD poderia ser um /dev/sda que montamos como a raíz /. Ficou confuso? Eu avisei, é porque você não assistiu meus videos sobre sistemas de arquivos.

Enfim, no Windows tem o mesmo conceito. Os dispositivos podem existir ligados sem ter um ponto de montagem como “D:” ou eu posso mudar o ponto de montagem pra outra letra se eu quiser, mas o dispositivo em si tem um identificador único que foi dado quando foi conectado. Pra ver isso, no Powershell que acabamos de abrir podemos digitar wmic diskdrive list brief e olha só, nesse notebook temos dois dispositivos de armazenamento, o NVME Sabrent Rocket de 4 terabytes que é o C: e o Kingston conectado via USB de 480 gigas. E os nomes dos dispositivos são esses \\.\PHYSICALDRIVE0 e 1. São os equivalente no Linux a um /dev/sda e sdb.

O WSL2 mais novo ganhou a habilidade de montar um HD externo e acessar direto sem ter aquele overhead de rede do protocolo P9 que falei antes, ele monta direto o filesystem. Pra isso, aqui no Powershell mesmo é só fazer wsl --mount \\.\PHYSICALDRIVE1. Ele avisa que o disco foi anexado na máquina virtual mas falhou em criar um ponto de montagem. Notem que quando fiz isso, o Windows desmontou o drive D:, que era só um ponto de montagem. O ideal é não ter dois sistemas operacionais diferentes mexendo no mesmo HD ao mesmo tempo direto, obviamente.

De dentro do WSL, por padrão ele vai montar drives externos em /mnt/wsl, olha só, apareceu um novo diretório chamado “PHYSICALDRIVE1”, mas se entrarmos nele não tem nada. O comando de mount do WSL tinha avisado que falhou e se consultarmos o dmesg que registra o log global do sistema operacional, tem de fato um erro do VFS que é o subsistema de file system virtual que falhou em tentar montar com filesystem ext4. E ia falhar mesmo porque esse SSD está formatado com NTFS, que o Linux não entende por padrão. Mesmo assim o dispositivo foi registrado dentro do Linux como /dev/sdg e se eu quiser poderia formatar usando o comando mkfs.ext4 como qualquer outro drive.

Isso é legal porque posso ter um drive externo com partição formatada em ext4 e toda vez que reiniciar meu note, é só eu dar o comando wsl --mount que vai aparecer dentro do WSL e ter excelente performance, basicamente performance de um drive nativo, sem overhead nenhum. E eu posso compartilhar esse drive com meu Linux em casa e com outro Linux no escritório por exemplo. Super conveniente.

Mas eu gosto de complicar um pouco mais. Eu não quero usar um drive externo, quero usar um outro HD virtual só pra projetos, pra ficar separado do HD virtual de sistema operacional. Assim, posso compartilhar esse drive virtual com mais de um WSL na mesma máquina, que nem agora que eu já tenho um Ubuntu e um Arch Linux instalados no WSL. Ambos poderiam acessar os mesmos projetos sem duplicar nada. Como fazemos isso?

Pra criar um HD virtual é simples. Basta abrir o Disk Management e criar um VHD. Vou criar um arquivo chamado test.vhdx de 150 giga, formato VHDX que é mais moderno e com tamanho dinâmico, ou seja, quando montarmos esse disco virtual, o sistema operacional vai achar que ocupa 150 giga mas na verdade vai ter o tamanho dos arquivos que colocarmos dentro dele, então não desperdiça espaço do seu HD de verdade. Olha no Explorer o arquivo que criamos e como não tá ocupando praticamente nada de espaço porque ainda tá vazio.

De volta ao mesmo Powershell, o que precisamos agora é que esse arquivo seja reconhecido como um disco de verdade e pra isso precisa aparecer como um PHYSICALDRIVE no Windows primeiro, que nem quando espetamos o SSD via USB. E pra fazer isso usamos o comando Mount-VHD passando o caminho completo pro arquivo de disco virtual e … deu pau. Isso porque esse comando só existe se você instalou as ferramentas do Hyper-V que é a plataforma de hypervisor da Microsoft. E isso só existe se estiver usando Windows 10 ou 11 versão Pro ou versão Server.

Tudo que fizemos até este ponto do video funciona na versão Home do Windows. Eu sei disso porque quando reinstalei o Windows 11 do zero ele instalou como Home sei lá porque. Mas é só ir na loja do Windows e fazer o upgrade pra versão Pro. Custa um pouco caro, mas se sua profissão é ser programador, é um custo necessário. O upgrade hoje em dia é super rápido, leva alguns minutos e um reboot e já era. Se não gosta da idéia de pagar pelo Windows, é pra isso que existe Linux.

Estando no Windows Pro, agora eu procuro a opção de Turn On Features que é o instalador de funcionalidades opcionais do Windows e boom, ta aí a opção de Hyper-V que só tem na versão Pro. Leva mais alguns poucos minutos pra instalar, mais um reboot e pronto. Agora temos suporte às ferramentas do Hyper-V. Então podemos abrir o Powershell com privilégios de administrador de novo e repetir o mesmo comando de antes de Mount-VHD.

Desta vez foi com sucesso. A partir deste ponto, pro sistema operacional, esse disco virtual se comporta igual a um SSD de verdade. Vamos rodar aquele mesmo comando wmic diskdrive list brief e olha só, entrou como Microsoft Virtual Disk e se registrou como \\.\PHYSICALDRIVE1 igual meu SSD Kingston via USB antes. E finalmente, podemos repetir o mesmo comando wsl --mount. Isso vai anexar o disco no WSL mas vai falhar a montagem de novo porque acabamos de criar esse disco virtual e ele tá vazio e nunca foi formatado.

Abrindo o terminal e olhando os logs no dmesg, mesmo erro de antes, não achou uma partição formatada com ext4. Mas ele tá bonitinho anexado como /dev/sdg. Como é um drive zerado, podemos formatar fazendo sudo mkfs.ext4 que é o comando de ‘make filesystem’. Pronto, agora que tá formatado, podemos dar cd pro ponto de montagem que é /mnt/wsl/PHYSICALDRIVE1. Mas note que ele tá com permissão pro usuário root então não vamos conseguir criar nada aqui.

Só falta dar um sudo chown pro meu usuário nesse Linux que é “akitaonrails” e pronto. Agora eu posso criar um arquivo aqui dentro com o comando touch e sucesso! Arquivo criado. Pro Linux isso é um SSD normal, montado diretamente sem nenhum tipo de gambiarra de rede, com velocidade máxima. Tem a mesma performance do disco virtual principal onde o sistema operacional tá instalado. Você pode criar quantos discos virtuais quiser e montar dessa forma.

Por acaso, eu tenho meu PC de casa que uso pra editar meus videos com WSL instalado e fiz um disco virtual com todos os projetos pessoais e da empresa. Virou um arquivão de mais de 20 gigas de coisas. Transferi pro notebook e agora coloquei no mesmo diretório C:\Arch. Tem que tomar cuidado se deixar em diretórios como Documents, caso Dropbox ou OneDrive estejam configurados pra fazer backup automático. Como é um arquivão gigante, toda vez pode tentar fazer upload de tudo, o que vai ser hiper lento. Faça backup mas tome cuidado de como vai fazer.

E pro último truque, eu queria que esse disco virtual de projetos fosse montado e anexado automaticamente no WSL toda vez que eu bootar a máquina pra não ter que toda vez abrir o Powershell e ficar fazendo Mount-VHD e wsl --mount todos os dias. Já vimos que se quisermos que algo rode toda vez que inicio o Terminal, no Linux foi fácil, foi só adicionar os comandos no nosso script .zshrc, aí ele inicia automaticamente o prompt powerlevel10k, o asdf. Mas no Windows não tem o equivalente fácil assim pra scripts.

Vamos ter que usar o bom e velho Task Scheduler que é o agendador de tarefas do Windows, que fica no aplicativo Computer Management e só tem opção gráfica. Então, botão direito menu de Start, selecionar Computer Management e na lista tem o Task Scheduler. Botão direito nele pra Criar Nova Tarefa. Colocamos um nome descritivo como “Auto Mount VHD” e configuramos pra rodar independente se eu estiver logado, marcamos pra não salvar senha e pra rodar com Privilégios de Administrador.

Na aba de Trigger criamos um novo que é “At Startup” que é pra rodar logo que o Windows carregar. Na aba seguinte de Actions é onde dizemos o que vai rodar no boot. O tipo de programa vai ser PowerShell e o argumento vai ser o comando de Mount-VHD só que agora o PATH vai ser pra “C:\Arch\projects-disk.vhd” que é meu disco virtual de projetos. Coloque o nome do disco que você criou. Pronto, e na última aba de condições é tirar a opção dele rodar de novo se o notebook entrar em modo de economia de energia e acordar. Não tem que rodar de novo.

Agora vamos fazer exatamente a mesma coisa só que pra outro comando. O nome vai ser Auto Mount VHD in WSL. Esses nomes são arbitrários, descreva como quiser. Mesma configuração. Depois o mesmo trigger at startup, mas diferente da última vez vamos colocar a opção de “Delay”, ou seja, eu quero um pequeno atraso. 1 minuto pra garantir. Isso porque queremos rodar este comando só depois que o anterior tiver já rodado. O Mount VHD tem que anexar o disco virtual e só depois podemos montar no WSL. Se não for nessa ordem, não vai funcionar.

Agora a action vai ser de novo tipo PowerShell e o argumento vai ser o comando wsl --mount e vai estar hardcoded aqui que é pra montar o PHYSICALDRIVE1. Lembrando que se eu bootar a máquina com um pendrive ou algo assim pré-conectado, quando montar o disco virtual provavelmente vai cair pra PHYSICALDRIVE2 e aí esse mount no WSL vai montar o disco errado. Mas normalmente vai ser sempre PHYSICALDRIVE1. E finalmente mesma coisa, não precisa rodar de novo se acordar de sleep.

Feito isso, podemos bootar a máquina e quando voltar, esperamos 1 minuto e quando abrimos o Terminal podemos checar com o comando lsblk que lista dispositivos de bloco e lá está nosso /dev/sdg devidamente montado em /mnt/wsl/PHYSICALDRIVE1 como a gente queria. Se listarmos os arquivos lá podemos ver que tem todo meu material. Mas convenhamos que digitar esse PATH enorme toda vez é um saco, mas pra isso que todo Linux suporta links simbólicos.

Vamos voltar pro meu diretório de casa com cd e vamos usar o comando ln -s pra mapear o link simbólico “Projects” apontando pro /mnt/wsl/PHYSICALDRIVE1. Pronto, agora podemos fazer cd Projects e ele entra no lugar certo. E agora sim, posso continuar dando git clone e git pull dos meus projetos pra cá e tudo vai funcionar com velocidade máxima. E tudo separado do disco virtual do sistema operacional.

E mais do que isso. Lembra do Ubuntu que o WSL instalou lá no começo e eu não mexi mais? Vamos abrir uma aba pra ele e vamos pro diretório /mnt/wsl e olha só, aqui também tá montado. Tanto do Arch quanto do Ubuntu, o comando wsl --mount monta em todas as máquinas virtuais e eu posso acessar de qualquer uma a qualquer momento. Obviamente não recomendo abrir o mesmo arquivo dos dois lugares ao mesmo tempo, mas isso abre diversas possibilidades diferentes. Eu não preciso ficar copiando arquivos entre os dois, posso compartilhar o mesmo drive virtual. E isso só funciona porque o Arch e o Ubuntu compartilham o mesmo Kernel do Linux e esse kernel único tem acesso ao drive e por isso aparece no container dos dois sistemas operacionais diferentes. Eles não sabem que estão compartilhando a mesma kernel.

E por último, eu tinha falado que faltava transferir as chaves privadas de SSH e nesse disco virtual eu tinha copiado o arquivo ssh.tgz. Aqui vai depender de como você compactou mas eu preciso ir pra raíz do drive e fazer tar xvfz /mnt/wsl/PHYSICALDRIVE1/ssh.tgz e vai descompactar no lugar certo e já com as permissões corretas. Se tivesse copiado de um pendrive formatado em FAT por exemplo, as permissões não teriam sido mantidas então precisaria fazer chmod -R 600 .ssh que significa permissão 6 pro meu usuário que é leitura e escrita e permissão 0 pra todos os outros usuários, que é não conseguir nem ler e nem mesmo listar os arquivos desse diretório.

Com isso o WSL do meu notebook está configurado e pronto pra eu poder voltar a mexer em código. Tenho o yay pra poder instalar qualquer programa do repositório AUR, tenho o Cargo do Rust pra instalar programas feitos em Rust, tenho o ASDF pra conseguir instalar qualquer linguagem de programação em qualquer versão e tenho o Docker pra poder rodar qualquer projeto. Além disso tenho meu prompt bonitão com o Powerlevel10K e posso editar código tanto no VSCode quanto no meu LunarVim fodão. E isso é tudo que um programador web precisa. Se eu fosse lidar com devops precisaria instalar outras ferramentas como do google cloud, kubernetes e coisas assim, mas aí é de projeto a projeto e com o que tenho configurado aqui, é só instalar com o yay.

Eu mencionei muito rápido no começo, mas uma das grandes vantagens de usar o Arch é a documentação da comunidade. Como no exemplo de instalar Docker, pra Ubuntu, eu precisei achar no site do próprio Docker e não no site do Ubuntu. Mas no caso do Arch tem um Wiki de Docker feito pela comunidade com um monte de informação e dicas muito úteis, seja pra quem é iniciante ou quem é avançado tentando resolver problemas mais complexos. Em vez de sair fuçando em fóruns ou lugares como o site stackexchange, normalmente você acha o que precisa no Wiki do Arch. Gaste tempo estudando tudo que não conhecia que mostrei nesse video a partir desse Wiki. Tenho certeza que vai aprender muito.

Tenho certeza também que muitos vão ficar mandando nos comentários ou mensagens diretas pra mim perguntando qual distro usar. Se tem dúvida, instale Ubuntu. Por isso eu fiz o guia definitivo de Ubuntu pra iniciantes. É a resposta padrão. De novo, se você tem dúvidas e veio perguntar é porque não tá com muita disposição de pesquisar, então é Ubuntu. Quem se importa já instalou um VirtualBox ou Virt Manager e criou máquinas virtuais pra baixar os ISOs das distribuições que tem interesse pra ver com os próprios olhos.

Hoje em dia é muito fácil. As ISOs você baixa de graça no site de cada distro. Daí é só bootar numa máquina virtual e usar alguns dias pra ver se gosta. Se ficou confortável, daí reserva um fim de semana, faz backup de tudo, queima a ISO num pendrive e instala como sistema operacional nativo. Não gostou? Muda pra outro. É assim que se faz. Perguntar pros outros não faz nenhuma diferença porque cada um usa pra coisas diferentes.

Eu pessoalmente gosto de distros baseados em Arch como o Manjaro, mas acho o Manjaro meio feinho. Prefiro a cara de um Deepin, mas acho Deepin muito pesado e não confio muito nele. Kali Linux é seguro, mas não foi feito pra usar no dia a dia, só rodaria numa máquina virtual se precisasse fuçar coisas de segurança. E assim por diante.

A parte ruim é instalar em notebooks super novos. Meu Zephyrus G14 comprei acho que lá por julho do ano passado, tinha acabado de lançar. Significa que o suporte de Linux pra ele ainda era muito insipiente. Eu achei alguns scripts, alguns hacks pra tentar fazer tudo funcionar, mas coisas como bluetooth não ia de jeito nenhum, perfil de economia de energia ainda não tava adequado. No final das contas não tive muita confiança, daí voltei pra Windows com WSL que todos os periféricos iam funcionar direitinho.

Agora que já passou 1 ano, talvez já tenha mais gente que gastou tempo ajustando e talvez agora já funcione melhor, não sei. Mas no meu caso, realmente não vejo tanta vantagem. O Windows me atende bem, tenho zero problemas com coisas como Steam, e tudo que preciso pra programar roda no WSL. Como é uma máquina parruda, com CPU e RAM sobrando, mesmo numa máquina virtual como o WSL funciona tudo zero bala. Se fosse um notebook mais antigo e menos potente, daí já justifica deixar Linux nativo, porque quanto mais antigo for o hardware, maiores as chances de drivers e coisas assim já existirem e serem estáveis.

Por isso que a resposta é sempre, depende. E por isso que se você é programador ou quer ser, precisa saber ir atrás da documentação e todos os componentes da sua própria máquina, pra saber quais distros são mais compatíveis, que tipos de gambiarra vai precisar fazer ou não. Este video, não tem nada que eu inventei, tudo tem na web, só saber procurar. E de novo, expliquei coisas mais básicas no meu video de Ubuntu e assistam os videos sobre máquina virtual e containers, os videos sobre sistemas de arquivos e dispositivos de armazenamento e tudo mais.

Se importe um pouco mais com sua própria máquina e seu ambiente de desenvolvimento. Se ficaram com outras dúvidas, mandem nos comentários abaixo. Se curtiram o video deixem um joinha, não deixem de assinar o canal e compartilhar o video com seus amigos. A gente se vê, até mais.

(obs: este script depende muito dos demos no video em si, pode ser difícil de ler só o texto)

DESCRIPTION

Eu vinha prometendo esse tema já faz algum tempo e finalmente resolvi explicar esse tal de WSL ou Windows Subsystem for Linux, a solução que permite rodar programas de Linux diretamente em cima do Windows.

Mas desde que eu comecei a acompanhar esse projeto em 2016 muita coisa mudou. O WSL evoluiu do então chamado “Bash on Ubuntu” para “WSL 1” e agora migrando pra “WSL 2”.

Quais as diferenças? Como funciona? Como instalo e configuro na minha máquina?

Além de responder essas perguntas eu achei adequado aproveitar o gancho pra contar a história do UNIX/Linux sobre o Windows e como essa história remete até o anos 80! Então vamos entender a história de como a Microsoft sempre flertou e de fato dormiu na cama do UNIX muito antes do que você pensa!

Se já sabe de tudo isso e só quer saber sobre o WSL especificamente, pode pular direto pro tempo 32:12.

Errata:

Eu disse que o VHD é limitado em 256GB e não havia como redimensionar, mas na verdade tem sim. Este link tem mais informações: https://docs.microsoft.com/en-us/windows/wsl/wsl2-ux-changes

Eu disse que 8086/8088 eram processadores de 8-bits, mas esses já eram 16-bits! Sempre confundi isso.

Pré-requisitos:

• Playlist: Começando aos 40 (https://www.youtube.com/playlist?list=PLdsnXVqbHDUc7htGFobbZoNen3r_wm3ki)
• Concorrência e Paralelismo Parte 1 (https://www.youtube.com/watch?v=cx1ULv4wYxM)
• Concorrência e Paralelismo Parte 2 (https://www.youtube.com/watch?v=gYJSWs-gp1g)
• Gerenciamento de Memória Parte 1 (https://www.youtube.com/watch?v=9AK_1gqEfkQ)
• Gerenciamento de Memória Parte 2 (https://www.youtube.com/watch?v=DGU1awKrNiA)
• Virtualização Parte 1 (https://www.youtube.com/watch?v=bwO8EZf0gLI)
• Virtualização Parte 2 (https://www.youtube.com/watch?v=mcwnQVAn0pw)
• Apple, GPL e compiladores (https://www.youtube.com/watch?v=suSvMnNwV-8)

Links:

• Announcing WSL 2 (https://devblogs.microsoft.com/commandline/announcing-wsl-2/)

• Awesome-WSL (https://github.com/sirredbeard/Awesome-WSL)

• Xfce4 Desktop Environment and X Server for Ubuntu on WSL 2 (https://autoize.com/xfce4-desktop-environment-and-x-server-for-ubuntu-on-wsl-2/)

• HOWTO: Enable WSL2 and Convert Existing Pengwin Installations (https://www.pengwin.dev/blog/2019/6/12/enable-wsl2-and-convert-existing-pengwin-installations)

• Plan 9 rides again; WSL file access (https://nelsonslog.wordpress.com/2019/02/16/plan-9-rides-again-wsl-file-access/)

• WSL Distro Launcher Reference Implementation (https://github.com/Microsoft/WSL-DistroLauncher)

• Shipping a Linux Kernel with Windows (https://devblogs.microsoft.com/commandline/shipping-a-linux-kernel-with-windows/)

• Awesome Powershell (https://github.com/janikvonrotz/awesome-powershell)

• WSL2-Linux-Kernel (https://github.com/microsoft/WSL2-Linux-Kernel)

• ArchWSL (https://github.com/yuk7/ArchWSL)

• XMing (https://sourceforge.net/projects/xming/)

• VcXSrv (https://sourceforge.net/projects/vcxsrv/)

• Project Drawbridge (https://www.microsoft.com/en-us/research/project/drawbridge/)

• How to install Flat-Remix Theme on Any Linux Distribution? (https://www.osradar.com/install-flat-remix-theme-ubuntu/)

• 2016 - Bash on Ubuntu on Windows (https://devblogs.microsoft.com/commandline/bash-on-ubuntu-on-windows-download-now-3/)

• Installing PowerShell Core on Linux (https://docs.microsoft.com/en-us/powershell/scripting/install/installing-powershell-core-on-linux?view=powershell-6)

• Install .NET Core SDK on Linux Ubuntu 18.04 (https://dotnet.microsoft.com/download/linux-package-manager/ubuntu18-04/sdk-current)

• coLinux (não-suportado mais) (http://www.colinux.org)

• Cygwin (https://cygwin.com/install.html)

• AkitaOnRails: Windows Subsystem for Linux is good, but not enough yet (https://www.akitaonrails.com/2017/09/20/windows-subsystem-for-linux-e-bom-mas-ainda-nao-suficiente)

• AkitaOnRails: Running Arch Linux over Windows 10! (https://www.akitaonrails.com/2018/04/29/rodando-arch-linux-sobre-o-windows-10)

SCRIPT

Olá pessoal, Fabio Akita

O próximo grande upgrade de Windows 10 está próximo, não sei ainda se vai ser agora já em setembro ou outubro, mas quando vier ele vai trazer a funcionalidade que todo desenvolvedor estava precisando: conseguir rodar aplicações de Linux quase nativamente em Windows 10.

Acho que a esta altura quase todo mundo já ouviu falar do tal WSL ou Windows Subsystem for Linux. Porém muita gente ainda não entendeu direito o que é isso. Na real é super simples. E se você é iniciante e já assistiu meus vídeos da série Começando aos 40, muito do que eu expliquei na parte de virtualização e containers vai ser usado hoje então, se ainda não assistiu, recomendo assistir antes, especialmente os que explicam sobre virtualização e containers.

Rodar um ambiente Unix ou Linux em cima do Windows, com suporte oficial da Microsoft, é um elo perdido que muitos de nós viemos perseguindo nas últimas décadas, eu mesmo venho acompanhando isso faz algum tempo. E pra sua surpresa essa nem é a primeira vez que a Microsoft oferece algo assim. Se você está interessado só na parte prática do WSL pode pular direto pra este tempo aqui embaixo, mas como sempre eu vou fazer uma tangente pela história, então vamos lá.

Essa história se inicia nos primórdios dos anos 80. Se você não sabe disso a Microsoft cresceu graças à IBM que licenciou seu MS-DOS para ser instalado nos IBM PC, fruto da amizade da mãe de Bill, Mary Gates com o CEO da IBM na época, John Opel. Todo mundo relaciona Microsoft com MS-DOS e depois Windows. Todo mundo relaciona interface gráfica com o Macintosh original ou no máximo com o Apple Lisa e a Xerox Parc. Em termos de interfaces gráficas, existiram diversas tentativas como o GEM dos Atari ST, o famoso Amiga Workbench no AmigaOS, o DeskMate do TRS-80.

Mas em processadores de 8-bits que, com muito esforço, dava pra mapear 64 kilobytes de RAM, desperdiçar espaço com interfaces gráficas era demais. O AmigaOS, por exemplo, precisava do processador Motorola 68000 de 16 ou 32-bits. De qualquer forma pouca gente relaciona que a Microsoft teve outros sistemas operacionais e outras interfaces gráficas muito antes do Windows.

Por exemplo, vocês sabiam que a Microsoft já teve um UNIX de verdade? Sim, muito antes da Apple comprar a Next e transformar o NextStep no OS X. Aliás, vale relembrar: Linux não é um UNIX, ele é mais ou menos compatível, mas na prática é um sistema operacional totalmente diferente. O UNIX original vem da Bell Labs e sua herança hoje vive nos derivados de BSD como FreeBSD ou NetBSD e no Darwin do MacOS. A maioria dos UNIX de verdade vieram desaparecendo ou diminuindo consideravelmente com o tempo como o Solaris da Sun ou o Irix da Silicon Graphics que, de curiosidade, se você assistiu Jurassic Park, já viu o Irix funcionando.

Em 1980 a Microsoft se uniu à SCO ou Santa Cruz Operation e eles desenvolveram o Xenix que era outro UNIX de verdade, e estamos falando mais de uma década antes do surgimento do Linux. Segundo a Microsoft era um UNIX muito próximo do UNIX original versão 7 que rodava nos minicomputadores PDP-11. Aliás, de curiosidade também, antigamente a gente chamava os mainframes de computadores, coisas como o PDP são os minicomputadores, e os Commodore, TRS-80, Sinclair, MSX, e mesmo os IBM PC eram os microcomputadores. Por isso falamos em “micros”.

Enfim, uma das idéias era evoluir o MS-DOS 2 pra se aproximar do XENIX em single-user, que iria virar o XEDOS, mas foi mais um vaporware que nunca saiu do papel. Aliás, foi daí que o termo “vaporware” nasceu, em 1982 por causa do XENIX. A SCO seguiu sozinha com seu SCO UNIX depois e a Microsoft desistiu da idéia e se uniu à IBM pro projeto OS/2 em 1987.

Esse período foi especialmente conturbado porque estamos falando da transição dos processadores de 8-bits como os antigos Z80 ou Intel 8086 e 8088 e indo pra 16-bits com o 80286, que inclusive foi onde eu ganhei meu primeiro computador, um clone de IBM PC XT em 1989. Porém o 286 era um processador complicado, pra dizer o mínimo. Estávamos migrando do modo real de execução pro modo protegido, que hoje é o padrão. Nessa transição apareceu a necessidade de emular o 8086 no modo protegido. Mas o modo protegido e emulado do 8086 nos 286 era falho. Além disso existia o problema do endereçamento segmentado de memória, diferente do modelo flat que você está acostumado hoje, onde pode endereçar toda a memória de 32 ou 64-bits.

Pense que em 16-bits você só consegue endereçar 64kb de RAM, pra ter acesso a mais RAM você precisa apontar pra espaços secundários, ou segmentados, de RAM. Como um índice apontando pra uma página em outro livro. Em termos simples você tinha um índice de 24-bits com endereços de 16-bits em múltiplos segmentos. No frigir dos ovos, com os problemas de hardware não seria possível rodar múltiplos ambientes paralelos de MS-DOS como deveriam. E a Microsoft obviamente não gostou muito disso.

Na parceria da IBM com a Microsoft eles desenvolveram o OS/2. A primeira versão era só modo texto, e a primeira interface gráfica tinha a cara do Windows 2, que saiu mais ou menos na mesma época. Porém a IBM insistiu no suporte ao 286 e esse foi um dos motivos da quebra da parceria porque o MS-DOS e o Windows tinham problemas com o 286. A Microsoft queria ir direto pro 386 de 32-bits que era muito melhor. Aliás, no caso do 286, imagine um processador que tinha máximo de 16MB de RAM. Claro, estamos falando de 1988. Os 386, em comparação, sendo de 32-bits, tinha máximo teórico de infinitos 4GB de RAM. Mas mais importante, rodava DOS em modo protegido perfeitamente.

Por outro lado, a IBM queria privilegiar a sua linha de hardware, claro, e eles tinham se comprometido com os 286 e sua linha de PCs PS/2 (entenderam? PS/2, OS/2 …) e por isso insistiram no OS/2 ser especializado nesse processador. Então em 1992 a IBM e a Microsoft se separaram, a IBM se manteve com o OS/2 e a Microsoft estava muito bem, obrigado, com seu Windows 3, a interface gráfica de maior sucesso da época.

Em paralelo a isso a Microsoft começou a criar um sistema operacional portável pra múltiplas arquiteturas de computador como processadores RISC da MIPS, PowerPC, Itanium, Intel e contratou Dave Cutler que trabalhava na VMS, que fazia o VAX/VMS mas não estava interessado em muitas de suas idéias. Daí ele foi pra Microsoft e caiu no projeto NT onde ele pôde aplicar muitas dessas idéias. Aliás, o nome Windows NT tem alguma controvérsia no seu significado, muitos talvez ainda pensem em NT como sendo New Technology.

O Dave Cutler vai dizer que WNT seria uma brincadeira em cima do nome da VMS de onde ele veio. Assim como muita gente gosta de brincar que IBM é uma brincadeira em cima do nome HAL, a inteligência artificial do filme 2001 do Stanley Kubrick. Se você pegar HAL e dar shift de uma letra pra frente, o H vira i, o a vira b e o l vira m. Mesma coisa com VMS se você der shift uma letra pra frente o v vira w o M vira N e o S vira T e daí WNT ou Windows NT. Tem outras teorias mas eu pessoalmente gosto mais dessa. Hoje em dia na real não significa nada, só um nome mesmo.

Com o objetivo de ser portável o Windows NT implementa uma camada de abstração do hardware, chamado convenientemente de HAL também, ou Hardware Abstration Layer. Vocês veem que nós de programação não somos exatamente muito criativos com nomenclatura das coisas. Além disso o NT começou tentando implementar um micro-kernel, inspirado nas idéias da kernel Mach de Carnegie Mellon. Hoje em dia nós usamos kernels monolíticos ou kernels híbridos. A idéia de um microkernel é ser um kernel o mais minimalista, leve e estável possível rodando no modo de supervisão ou Ring-0 que é o anel de maior privilégio. Eu expliquei isso em outro vídeo. Daí todos os serviços que compõe o sistema rodam em user mode ou Ring-3. O problema disso é que você acaba com um overhead muito grande de IPC ou interprocess communication pois os programas rodando no anel de menor privilégio precisam ficar constantemente se comunicando com o kernel que roda no anel de maior privilégio.

Essa controvérsia de micro-kernels versus kernels monolíticos ou macro-kernels foi tema de grande discussão na comunidade Linux no começo, inclusive é um episódio histórico a discussão de Linus Torvalds defendendo o design monolítico da kernel do Linux contra a visão acadêmica de micro-kernels do professor Andrew Tanenbaum, autor de um dos livros sobre sistemas operacionais mais famosos e que você provavelmente teve que estudar se cursou ciências da computação. Na prática, apesar do design de micro-kernels ser o mais elegante, macro-kernels funcionam melhor como o sucesso do Linux já comprovou.

No caso do NT, por exemplo, subsistemas de drivers de I/O, como video ou mesmo impressão rodavam tudo em Ring-3, em user-mode, como deveriam. Mas no Windows NT 4 eles foram movidos pro Ring-0, dentro do espaço do kernel. Eu costumo dizer que o Windows NT mais estável e robusto era o Windows NT 3.5 justamente porque ele tinha o menor kernel, mas pro hardware da época acho que não tinha muita alternativa. No Windows 2000 ou XP se não me engano eles moveram uma parte do IIS na versão 6.0, pro Ring-0 na forma do driver HTTP.sys. Isso substituiu o Winsock que rodava em user-mode, e eu acho que isso foi um erro. Imagine parte do seu servidor web embutido na kernel incluindo coisas como cache e fila de requests. De qualquer forma isso garantiu melhor performance pro IIS se comparado ao Apache que rodava exclusivamente em user mode, mas ao custo de bugs na stack de HTTP potencialmente causarem problemas no nível do kernel, que poderia levar desde um crash do sistema até a buracos sérios de segurança.

A equipe do Windows NT era formada por muita gente da DEC ou Digital Equipment Corporation, liderada pelo Cutler, e uma das tais idéias que ele trouxe da VMS foi a noção de um sistema operacional orientado a objetos e por isso na arquitetura do NT você tem um Object Manager na camada privilegiada do Windows Executive, abstraindo todos os recursos do sistema na forma de objetos lógicos. Além deles alguns membros da equipe vieram do time do OS/2 que também queria integrar noções de orientação a objetos. Uma das coisas que eu achava fascinante na interface do OS/2, o Workplace Shell, é que tudo eram objetos. Infelizmente isso não foi implementado no Windows. Mas por exemplo, em vez de abrir um programa e clicar no menu em Novo Arquivo, você abria uma pasta de templates e arrastava o template pro desktop pra criar um novo arquivo, como uma instância de uma classe. A idéia de orientação a objetos foi embutido em todos os sistemas operacionais dos anos 90 e por isso coisas como a API de um NextStep sendo orientados a objetos, e você tem abstrações e encapsulamento de comportamento criando coisas como o Hardware Abstration Layer do NT.

Pra todos os efeitos e propósitos, do fim dos anos 80 pro início dos anos 90 eu diria que os sistemas operacionais desktop mais avançados eram o OS/2, o AmigaOS, o NextStep e o Solaris. Eles inspiraram diversos outros como o BeOS ou o Irix. Mas os mais populares eram sem dúvida o MS-DOS, o Windows 3.1 e o System 7. O Windows NT apareceu pela primeira vez em 1993 com o nome de Windows NT 3.1 pra ser paralelo ao nome Windows 3.1 que era completamente diferente e ainda rodava por cima do DOS. De comum eles tinham basicamente a mesma interface gráfica.

Daí em 1995 tudo mudou com o advento do Windows 95, trazendo a era de 32-bits pros desktops populares. Comparado com hoje em dia, eu lembro como a gente achava o Windows 95 pesado, precisando de 4MB de RAM sendo que o Windows 3.1 rodava tranquilamente com 2MB de RAM. No ano seguinte saiu o Windows NT 4.0 com a interface mais parecida com do Windows 95. Os NT, pela natureza da sua arquitetura mais robusta também precisava de mais recursos pra rodar, eu acho que com menos de 8MB ou 16MB de RAM não dava pra rodar decentemente, e por isso eles eram mais usados em servidores.

Nos anos 90 fomos evoluindo do Windows 95 pro 98 até o famigerado Windows ME ou Millenium Edition. E no lado do NT que era mais voltado a servidor fomos do NT 4 pro 2000. Passamos os anos 90 surfando na Lei de Moore e processadores mais rápidos iam saindo o tempo todo, do 486 pros Pentium pro Pentium II, Pentium III, no servidor tínhamos os Itanium. RAM foi ficando mais barato. A grande virada veio em 2001 com a unificação dos Windows no famigerado XP e finalmente nos livramos do legado do MS-DOS por baixo do Windows. Desde então sempre tivemos uma versão de NT pra desktop e outro pra servidor.

Então na era do XP tivemos o Windows Server 2003 e 2003 R2. Com o Windows Vista sucedendo o XP tivemos o Windows Server 2008. Depois o Windows 7 e o Windows 2008 R2. Depois disso o Windows 8 e o Windows Server 2012 e 2012 R2 e na geração do Windows 10 a partir de 2015, que teoricamente vai ter só upgrades sem mudar o nome, tivemos o Windows Server 2016 e Server 2019. O Windows 10 hoje está na oitava edição estável build 1903 de maio de 2019. Essas edições costumam sair entre abril e maio e depois outubro, por isso eu acho que a próxima edição importante vai sair em outubro de 2019.

Eu falei que o NT desde o começo veio com a mentalidade de ser portável, ele não rodava só em Intel. Mas aos poucos o suporte de hardware foi diminuindo à medida que essas arquiteturas foram caindo em desuso. Por exemplo, no Windows 2000 caiu o suporte a MIPS, Alpha e PowerPC. Mas além do lado hardware o NT implementou a idéia de “personalidades” ou subsistemas. Você tinha a Win32 que é o suporte a API moderna do Windows. Hoje em dia programas 32-bits rodam emulado sobre o WoW64 ou Windows 32 on Windows 64. Mas desde o começo ele foi lançado com suporte a subsistemas como OS/2 que permitia um grau de compatibilidade com a API do OS/2, já que a Microsoft tinha interesse no nicho que eles ajudaram a criar com a IBM.

Claro que eles precisavam manter compatibilidade com o MS-DOS e pra isso eles já embutiam uma virtual machine pra DOS. Sim, um tipo de máquina virtual. E pra conseguir atender contratos de governo que requeriam UNIX eles também tinham um subsistema compatível com POSIX, que como eu já expliquei em outro episódio, é a superfície de compatibilidade com os UNIX da época.

Ou seja, seria possível pegar o código fonte de aplicativos feitos pra UNIX e teoricamente compilar num Windows NT e rodar nativamente! Ele era compatível com o padrão POSIX.1 por isso não tinha um shell ou ambiente de uso e comandos de usuários, coisas como um mísero ’ls’, que só passaria a existir como padrão no POSIX.2. Por isso pra usuários normais de Linux como nós, esse ambiente é basicamente inútil. Só serve se você tinha código fonte em C compatível com POSIX.1 e precisava de um compilador C compatível.

Com a evolução rápida das distros Linux nos anos 90 e igualmente rápido desuso dos UNIX, esse subsistema no Windows era meio inútil. Nesse vácuo, projetos open source como o Cygwin apareceram. Cygwin se chama assim porque foi criado pela empresa Cygnus Solutions que depois foi adquirida pela RedHat. Era um ambiente em user-mode compatível com POSIX e com Linux em particular. E diferente do subsistema POSIX original da Microsoft, eles portaram boa parte do toolchain do GNU no pacote, trazendo shells como bash e além das ferramentas pro compilador, também trouxe diversas outras coisas úteis como awk, sed, tar, ssh, servidores como Apache, Postgres, linguagens como Perl, Python, Ruby, Prolog e muito mais.

Era como uma distro baseada em Linux rodando sobre uma camada que tentava abstrair o NT por baixo na forma de DLLs. Muita gente ainda usa Cygwin até hoje e sempre foi a melhor ou mesmo a única forma de rodar muitas ferramentas de Linux de forma nativa no Windows. Mas Cygwin não se encaixa na categoria de distro de Linux porque ele tem uma semi compatibilidade em nível de código fonte, mas os binários de Linux não rodam no Cygwin nativamente, precisa recompilar sempre.

Com o passar dos anos o subsistema POSIX original foi removido no Windows XP e Windows Server 2003 sendo substituído por outro subsistema que foi originalmente desenvolvido por uma empresa chamada Interix, adquirida pela Microsoft, e sua solução foi renomeada como Windows Services for UNIX ou SFU e você podia instalar opcionalmente. O suporte ao SFU veio gradativamente diminuindo, tendo muitos de seus componentes removidos do instalador até o Windows 8 e Windows Server 2012. Mas pra todos os efeitos e propósitos ele é muito similar ao Cygwin só que o Cygwin é compatível com GNU/Linux e o SFU é compatível com UNIX. Novamente, se você tinha código fonte de UNIX podia compilar no SFU e rodar no Windows.

Em 2004 surgiu a primeira forma de rodar Linux sobre o Windows de verdade, sem virtualização. Foi o Cooperative Linux ou coLinux. Infelizmente a última versão estável dele é de 2011 então não espere que ele funcione hoje em dia. Mas em vez de ser um subsistema ou uma máquina virtual, ele era uma kernel linux modificada que era carregado no Ring-0 do lado do kernel do NT. E ele compartilhava os recursos da máquina com o kernel NT, por isso cooperativo. Isso era possível através de um driver, e drivers rodam em Ring-0 junto com ferramentas como um Windows Service pra dar acesso. Daí em user-land você podia rodar os binários originais de uma distro como Ubuntu ou Arch. Dava pra acessar o terminal via SSH ou mesmo a interface gráfica do X via um VNC. Pra todos os efeitos era quase como rodar um Virtualbox mas sem o overhead de virtualização. Eu imagino que manter suporte de algo assim deve ser bem complicado porque você meio que está lobotomizando o kernel do NT por um hack via um driver.

Como podem ver, rodar Linux ou UNIX sobre o Windows é uma coisa que muita gente já tentou fazer de diversas formas. Com hardware moderno, a opção mais estável é abrir um Virtualbox ou VMWare e rodar virtualizado. Graças à evolução do suporte de virtualização dos processadores, na minha experiência não só é viável mas serve muito bem como máquina principal de desenvolvimento. E quando eu digo hardware moderno estou falando no mínimo de um Core i5 de 4 cores com no mínimo 8GB de RAM, preferencialmente 16GB. O problema de virtualização normal é que normalmente você precisa pré-reservar quantos cores e quanto de RAM vai ser dedicado pra máquina virtual.

Vejam o problema. Com soluções como o subsistema POSIX, o Cygwin ou o SFU tudo roda nativo, não é virtualização. Mas pra funcionar você precisa ter o código fonte de tudo, talvez modificar alguma coisa, compilar e gerar um binário nativo de Windows NT. Se conseguir fazer isso o binário vai rodar como qualquer outro binário de Windows. Por outro lado, é muito difícil conseguir compatibilidade com tudo e muita coisa simplesmente não vai nem compilar sem modificações significativas. Pelo simples fato que as primitivas do kernel do NT são diferentes do kernel do Linux. Já expliquei em detalhes em outros vídeos como o Windows, o Mac e o Linux gerenciam coisas como estrutura de processos, scheduler de threads, memória, I/O de formas diferentes.

Por exemplo, num SFU não adianta eu compilar alguma coisa como o programa ‘ip’ ou o antigo ‘ifconfig’, eles vão tentar mexer em coisas como o /etc/network/interfaces que o Windows NT não usa pra expor suas interfaces de rede. Isso sem contar que coisas como ‘fork’ funcionam diferente no Windows, como já expliquei no vídeo de gerenciamento de memória. Não adianta eu compilar um programa que gerencia processos via o diretório /proc porque o Windows não expõe os metadados dos processos lá. O sistema de autenticação e permissão são completamente diferentes, então nenhum programa que gerencia usuários e permissões como ‘useradd’ ou ‘chown’ vai conseguir modificar nada no Windows. Essas diferenças tornam complicado rodar programas de UNIX ou Linux lado a lado de programas Windows porque existe uma dissociação semântica enorme.

Por outro lado, rodar dentro de uma virtual machine traz a vantagem de isolar completamente os comportamentos de Linux e Windows. De dentro da máquina virtual tudo funciona perfeitamente como se fosse uma máquina de verdade isolada. Daí você controla coisas do host Windows via ferramentas de Windows e coisas de Linux separadamente com coisas de Linux e cada um vive feliz separado.

Vamos ver o caso do macOS rapidamente. Como ele foi construído sobre uma fundação UNIX, todo o sistema operacional obedece às leis do UNIX. Todo programa de Mac é de fato um processo UNIX e pode ser controlado com coisas que todo mundo de Linux conhece. Se eu usar o comando ps no terminal, vai listar processos como o Chrome ou Final Cut. Se eu usar o comando kill no terminal, vai matar de fato os programas todos. Se eu usar comandos como ip eu de fato gerencio as interfaces de rede da máquina, e assim por diante. A API do Mac é construído sobre as APIs do UNIX por baixo. Então a integração é praticamente 100%. Um serviço de UNIX é um serviço de Mac e assim coisas como servidor de SSH ou Postgres rodam lado a lado de serviços do Mac. Usuário de Mac são usuários do UNIX. Permissões de arquivos feitos via o Finder ou feitos via Terminal com comandos como ‘chown’ ou ‘chmod’ são a mesma coisa. Por isso existe coerência semântica entre os aplicativos gráficos e os de linha de comando. E a Apple trouxe muito do toolchain GNU pra dentro, então o MacOS é como se fosse um FreeBSD mais bonito, na prática.

Por outro lado, assim como no subsistema POSIX, Cygwin ou SFU no Windows, o macOS tem compatibilidade de código-fonte mas não de binário. Binários formato ELF de Linux não são compatíveis com binários de BSD ou macOS ou Cygwin ou SFU. Por isso no Mac você precisa compilar programas de Linux especificamente pra rodar no Mac e por isso a gente não pode usar pacotes pré-compilados que já existem em distros como Ubuntu ou Arch. Por outro lado, ao contrário de Cygwin ou SFU, o comportamento do macOS, que é parecido com o comportamento do BSD e tem a mesma semântica do Linux, garante que quase todo o código-fonte seja compatível porque coisas como interfaces de I/O, gerenciamento de memória e de threads é significativamente parecido.

Então existe algum trabalho que precisa ser feito no código-fonte de alguns programas, mas no geral, basta recompilar no Mac e tudo magicamente funciona. O mesmo não pode ser dito em ambientes como o antigo subsistema POSIX ou SFU ou Cygwin. E mesmo quando compilam, eles não tem acesso ao resto do sistema Windows.

A grande reclamação do povo de Linux quanto a gerenciar os recursos de um Windows é que tudo precisa ser feito via ambiente gráfico. Por isso gerenciar um servidor remoto sempre exigiu coisas como um Remote Desktop ou VNC pra podermos ter a tela gráfica remotamente. É um puta pé no saco quando em servidores Linux podemos conectar via terminal com um cliente de SSH e gerenciar todos os recursos da máquina via linha de comando. Pra resolver parte disso a Microsoft criou o Powershell.

Em resumo, a história remete ao fim dos anos 90 de novo, quando a Microsoft iniciou o projeto .NET. Com o tempo boa parte, se não toda a API do Windows, foi mapeada em classes dos frameworks disponíveis no .NET, além de componentes COM e WMI. Porém o antigo programa de linha de comando do Windows, o Command, que herda as características do antigo MS-DOS, é um lixo. As linguagens de script que ele traz como o BATCH ou REXX, oriundo da antiga herança do OS/2, são muito fracos e quase nada do sistema operacional é exposto pra linha de comando, você é obrigado a programar coisas como scripts em visual basic pra acessar o WMI ou componentes COM que tem algum acesso a algumas coisas do sistema como gerenciar usuários. Esquece fazer scripts complicados como os que fazemos em Bash pra Linux.

Porém, uma idéia interessante é um console de linha de comando com acesso ao framework do .NET. E é basicamente isso que é o Powershell. Ele trás uma linguagem de script mais poderoso e com muitas coisas que encontramos num Bash. Ele tem inclusive um pipe! E eu argumentaria que um pipe superior ao do Linux. No Linux todo script ou comando aceita argumentos e um stream de bytes que chamamos de standard input e tem uma saída de bytes na forma do standard output, que eu também já expliquei nos vídeos sobre concorrência e paralelismo. E por isso você precisa de comandos como awk ou sed ou grep pra tratar o texto que os scripts devolvem. No caso do Powershell os comandos devolvem estruturas de .NET, ou seja, são dados estruturados.

O episódio nem é de Powershell mas obviamente agora eu empolguei. Eu também acho interessante que muita gente que usa Linux nunca viu Powershell. Pense num script de Bash pra selecionar processos que estão usando mais que 100MB de RAM, como você faria. Num bash provavelmente algo parecido com este script aqui:

ps -eo rss=,pid=,user=,comm= k -rss |
  while read size pid user comm
  do
    if [ "$size" -gt 102400 ]
    then
      echo "$pid $size $user $comm"
    else
      break
    fi
  done

Ou seja, precisamos ir linha a linha da saída do comando ps e checar o tamanho em kilobytes até achar o que queremos. Em Powershell podemos fazer assim:

Get-Process | Where-Object WorkingSet -gt 104857600

E como o Powershell suporta aliases e ele já vem com muitos aliases pré-programados, a mesma linha poderia ser escrita assim:

ps | ? WorkingSet -gt 104857600

Do ponto de vista de usabilidade pra novatos, a sintaxe do Powershell é muito mais fácil de ler. E pra veteranos de shell existem formas de simplificar pra comandos mais familiares. E veja como estamos usando o pipe pra passar os objetos do ps pro where-object fazer um filtro na propriedade do objeto. E isso é universal pra todos os comandos.

Tecnicamente eu diria que o Powershell pode ser considerado superior em muitos aspectos a Bash ou outros shells de Linux. Eu acho que não é 100% do Windows que pode ser controlado via Powershell mas uma parte considerável pode, e ele pode ser estendido via .NET, então seja via C# ou F# você pode expor o que quiser pra esse shell. E mesmo se você for de Linux pode usar Powershell, porque a Microsoft abriu não só o .NET na forma do .NET Core como open source como também o Powershell na forma do Powershell Core. Aqui o problema é o inverso, ainda não sei quanto do Powershell se integra aos recursos do Linux mas ele pode ser uma opção interessante pra fazer scripts de automação numa linguagem menos cheia de truques se comparado a um Bash, especialmente se estiver rodando coisas como SQL Server pra Linux e outros programas .NET. Ele é particularmente bom pra lidar com dados estruturados como JSON.

Essa tangente pro Powershell foi primeiro pra introduzir vocês ao tema, mas segundo pra dizer que apesar dele ser muito bem feito e eu pessoalmente achar elegante e um passo grande pra Microsoft, ele ainda não resolve o problema de quem quer usar o Bash de verdade e está acostumado com o ferramental GNU. Mesmo o Powershell sendo bacana, a gente ainda quer usar ferramentas antiquadas mas funcionais como awk, sed, grep e tudo mais. A única saída nesses casos é instalar Cygwin ou rodar num Virtualbox já que o subsistema POSIX já morreu, o SFU já morreu, e o coLinux não tem suporte desde 2011.

Até aqui eu expliquei como era possível rodar alguma coisa de UNIX ou Linux no Windows mas e o oposto? Ou seja, rodar programas de Windows no Linux? Se você já brincou de Linux por algum tempo já deve ter ouvido falar ou mesmo usado o projeto Wine ou Wine is not an Emulador que é um acrônimo recursivo, coisa de programador, como eu já disse a gente é ruim de nomenclatura. O Wine é um projeto capaz de carregar um binário feito pra Windows, sem precisar recompilar, e executar no Linux. Pra fazer isso ele mapeia as chamadas de API pra Kernel do NT em chamadas pra kernel do Linux e faz engenharia reversa de dezenas de DLLs que compõe o Windows e com isso ele consegue executar muitos aplicativos de Windows rodando com performance quase nativa em ambiente Linux. Claro, engenharia reversa significa que 100% de compatibilidade é extremamente difícil. Muitos aplicativos abrem e rodam bem, mas algumas partes deles podem precisar de APIs que não foram reimplementados ainda e crashear ou simplesmente não funcionar.

Lembram como no video sobre Ubuntu eu falo como não dava pra rodar todos os games do Windows no Linux? Muitos me lembraram depois que a Steam tem o projeto Proton que permite rodar muitos jogos, mas não todos. Você precisa consultar o site da comunidade, o ProtonDB pra ver se seu jogo roda. Na realidade o Proton usa Wine por baixo. Ele é mais um de uma família de aplicativos que usam Wine e tentam facilitar a instalação de dependências pra programas específicos, como o antigo CrossOver. Por isso o Proton consegue rodar jogos que originalmente foram feitos pra Windows, mas em Linux. O Wine é como se um fosse uma camada de Windows dentro do Linux.

O maior problema é que como os binários do Windows não são código aberto, é preciso fazer engenharia reversa dos binários e reimplementar do zero no Linux. É um processo black-box de desenvolvimento, ou mais corretamente, um grande cornojob de tentar executar o binário do Windows, ver ele crasheando, ver que chamada de sistema ele tentou fazer que ainda não existe e implementar essa função no Linux. Função a função. Wine existe já faz muitos anos e com o tempo ele evoluiu bastante, mas o Windows não parou no tempo também, então cada vez que sai uma versão nova, o Wine ganha mais trabalho pra suportar as coisas novas. É um trabalho insano que me deixa fascinado pelo fato de até hoje ainda existir.

Muito bem, vamos resumir agora. Vocês lembram o que eu já expliquei em outros vídeos. Um sistema operacional é composto de pelo menos duas partes principais, o kernel e drivers e outros subsistemas que rodam no Ring-0 de maior privilégio do sistema. E a outra parte são outros subsistemas e aplicativos que rodam em user-land ou Ring-3 de menor privilégio. Pra rodar os programas de outro sistema operacional você precisa ter as dependências, talvez fazer algumas modificações no código-fonte, recompilar o programa. É o processo que chamamos de “portar”. É pra isso que serviam ambientes como o subsistema POSIX, o SFU e o Cygwin. É como funciona no macOS hoje ou mesmo nos BSDs. Compatibilidade de nível de código-fonte. Quer rodar programas de Linux fora do Linux, precisa recompilar em todos esses ambientes: Windows, macOS ou outros UNIX.

Pra rodar um binário de outro sistema operacional, sem recompilar, você precisa ter o kernel e dependências rodando lado a lado do seu sistema principal e um mecanismo pra carregar os binários não modificados. O coLinux conseguiu executar a kernel do Linux cooperativamente, compartilhando os recursos da máquina, do lado da kernel do NT, ele conseguia montar um filesystem de Linux e executar os programas de Linux em user-land sem precisar recompilar nada. Você podia rodar os binários de um Ubuntu ou Arch por cima desse ambiente.

Fora isso você tem a opção de virtualização, seja com VirtualBox, VMWare ou Hyper-V, daí você roda tudo em user-land mas com as instruções da VT-X da Intel que permite o kernel virtualizado conseguir acessar o hardware por baixo com menor overhead possível. Você perde 20% ou mais de performance virtualizando, dependendo da configuração do seu hardware, mas no geral tudo funciona perfeitamente. Virtualização é uma opção quase plug-and-play hoje em dia.

Eis que do nada a Microsoft anunciou o projeto Windows Subsystem for Linux ou WSL 1 como podemos chamar hoje. Ele começou a aparecer no Fast Ring do Windows Insider lá pelo Anniversary Edition acho que pelo começo de 2016, e foi lançado de verdade no Creators Update uns 3 meses depois. Hoje em dia temos o WSL 2 que é completamente diferente e já vou explicar porque. Mas o WSL 1 do ponto de vista técnico é muito mais interessante, mas eu entendo porque eles desistiram dessa forma.

Antes de mais nada, a Microsoft faz muita pesquisa, e eventualmente muitos dos resultados dessas pesquisas realmente acabam no Windows de verdade. Um desses projetos foi o Drawbridge que estava pesquisando formas de rodar processos isolados, como em containers, sem precisar de virtualização. Um dos resultados foi permitir o kernel de criar processos com o mínimo ou zero de interferências. Lembram nos episódios de gerenciamento de memória que eu expliquei que dentro do espaço de endereços virtuais do processo o Windows mapeia suas DLLs de sistema e outras coisas pra compartilhar seus recursos com os processos e por isso um processo de 32-bits no Windows de 32-bits nunca tinha os 4GB totais disponíveis pra ele? O resultado desse projeto Drawbridge foi permitir o kernel NT de criar o que eles chamaram de Minimal Process e Pico Process que são processos sem interferência do OS, com o espaço de memória limpo. A diferença de um processo Minimal e Pico é que no caso do Pico existe um driver associado a ele que permite a comunicação desse processo pra fazer syscalls.

Isso existe desde 2013 e o time do WSL resolveu usar esse recurso pra carregar o binário não-modificado de um programa Linux que tem o formato ELF64 pra dentro de um Pico process. Agora pra executar, esse programa vai querer fazer coisas como syscalls pra kernel do Linux. E aí entra a parte do driver. Esse driver vai converter as chamadas pra kernel do Linux em chamadas pra kernel do NT. Então na prática não existe um kernel de Linux rodando. Quando o programa de Linux chamar um fork ele vai ser traduzido pro equivalente NtCreateProcess, ou se chamar fopen ele vai ser traduzido pro NtOpenFile e assim por diante. Na realidade a tradução acontece no nível do assembly, mas a idéia é a mesma.

Como já expliquei, o Windows trata todos os recursos do sistema como objetos, incluindo arquivos e o file system, tudo é roteado pelo Object Manager. E ele sempre teve essa idéia do HAL de abstrair o hardware. E de fato, por cima do NTFS temos o VFS ou Virtual File System. Se vocês já usaram Windows e Linux sabem que existem diferenças em como o filesystem NTFS do Windows e o EXT4 do Linux se comportam. Por exemplo, no Windows não tem como deletar um arquivo que está em uso por algum programa, no Linux podemos renomear ou deletar o arquivo mesmo que ele esteja em uso. São comportamentos diferentes e não defeitos na operação, prova disso é que o WSL 1 replica o comportamento de um EXT4 por cima do NTFS removendo algumas validações e checagens que no NTFS são ligadas por padrão. Inclusive o WSL consegue replicar o comportamento do ProcFS e SysFS pra expor partes do sistema operacional como arquivos, como no diretório /proc que lista processos do sistema como expliquei no episódio de Ubuntu.

Então esse novo subsistema que seria o herdeiro do antigo subsistema POSIX e do SFU emula o comportamento da kernel do Linux, sem de fato ter o kernel do Linux e sim traduzir tudo pro kernel NT, com a vantagem de carregar binários não modificados. Como eu já expliquei antes, tirando a kernel o que muda de uma distro pra outra são os binários de user-land. E como o WSL consegue carregar os programas de Linux diretamente nos processos Pico, sem precisar modificar ou recompilar esses binários, você pode literalmente pegar todos os binários de um Ubuntu ou Arch ou Fedora e rodar em cima desse subsistema.

Uma grande vantagem dessa forma é que ao abrir um Bash e usar comandos como ps ou kill podemos não só manipular programas Linux como programas Windows também. Muitos comandos que num Cygwin seriam inúteis como programas pra configurar interfaces de rede e muito mais passam a funcionar minimamente. Programas que manipulam arquivos podem manipular alguns arquivos do lado Windows também. Foi a primeira vez que programas Linux não modificados puderam rodar lado a lado de programas Windows. Era bizarro porque eu podia abrir o Task Manager do lado do Windows e ver cada programa de Linux individualmente listado. A integração era muito bem feita embora ainda incompleta.

Eu rodei esse ambiente por algum tempo, e apesar de não ser tudo que funcionava, era possível rodar tudo que eu precisava pra desenvolver projetos de Ruby on Rails ou Node.js incluindo bancos de dados como Postgres ou Redis e carregar servidores que corretamente faziam binds nas portas nativas do Windows, e conseguir testar do Chrome do Windows. Seria esse o ambiente perfeito?

Infelizmente havia ainda vários problemas. O maior ofensor eu diria que era a virtualização do file system. Essa virtualização em cima do VFS funciona, mas o VFS é interligado com o Windows Defender e outros antivírus e antimalware. Toda operação de disco no Windows dá trigger pro Defender avaliar se não tem perigo ler o arquivo. Obviamente isso adiciona um overhead gigantesco. Some a isso operações altamente custosas de I/O como um npm install em um projeto de Node e você pode ir tomar um café enquanto espera ele terminar. Isso poderia ser resolvido se a equipe do WSL mudasse a estratégia de tentar manter o file system aberto em cima do NTFS e simplesmente montasse um disco virtual dentro de um arquivão como no formato VHD que Virtualbox ou VMWare usam. Máquinas virtuais costumam montar o filesystem do sistema Guest na forma de arquivos esparsos, ou seja, digamos que você configure um HD de 1 TB dentro do Linux virtualizado mas seu HD de verdade só tem 500GB. Claro que não cabe, mas você não precisa pré-alocar esse espaço, pode só mentir pro sistema virtualizado e só alocar o que ele realmente for usar e ir adicionando novos blocos nesse disco virtual sob demanda.

Mas o problema principal não é esse. O conceito original é mapear syscalls do Linux pra syscalls do kernel NT. Eles esbarraram no mesmo problema que a equipe do Wine tem até hoje: toda vez que sai uma atualização pro Windows, alguma coisa vai quebrar no Wine porque as syscalls e outras dependências mudaram. Então manter essa camada de compatibilidade entre as duas kernels vai ser sempre instável. Toda vez que sai uma versão nova da kernel do Linux, alguém na equipe do WSL vai precisar ajustar essa camada de tradução. Então nunca vai ser possível ter um sistema totalmente estável porque essa é a natureza de wrappers e adapters, eles são alvos móveis.

Ficar fazendo isso desde 2016 demonstrou que como prova de conceito, de fato tudo funciona, mas muitas syscalls de Linux não tem equivalente em NT e davam trabalho de manter. E toda vez que a kernel atualizava tanto do lado Linux quanto do lado NT, precisava ajustar a camada de adaptação. É uma bola de neve sem fim. Por fim eles decidiram mudar a estratégia toda e recomeçar do zero.

É uma pena, porque como eu disse, eu gostava muito dessa estratégia porque uma das vantagens era ter os recursos do Windows como processos em execução, expostos numa camada Linux onde era possível usar as ferramentas de Linux pra mexer em partes do Windows. Se eles conseguissem abstrair coisas mais complicadas como o Registry em alguma forma que pudesse ser gerenciada pelo Bash, ia começar a ficar mais útil ainda, mas aí já era pedir demais mesmo. Pra isso existem coisas como o Powershell. Se a intenção é gerenciar os recursos do Windows pela linha de comando, ainda é muito melhor, mais estável e mais completo usar o Powershell.

Em vez de tentar fazer de tudo, melhor fazer menos mas fazer direito. Já que é muito difícil emular a kernel do Linux como um adaptador em cima da kernel do NT e se simplesmente rodássemos o kernel do Linux de verdade? Seria a estratégia do coLinux, mas em vez de um hack, podemos usar o Hyper-V que nesta altura evoluiu bastante e é muito bom. O problema com programas de virtualização, como expliquei antes é que você normalmente precisa reservar quantos cores e quanta RAM vai ficar travado pra máquina virtual.

Mas durante a evolução do Windows Server pra atender os requerimentos de serviços como o Azure, eles conseguiram evoluir o Hyper-V pra criar máquinas virtuais mais leves e mais flexíveis. Existe a opção de lightweight utility VMs onde ele consegue pedir mais recursos à medida que for precisando. Daí não precisamos desperdiçar 4GB do sistema deixando reservado pra máquina virtual se logo no boot ele só precisa de 500Mb, por exemplo. Além disso existe a opção de não exigir um cold boot, ou seja, um boot do zero. Ele dá a opção de você conseguir carregar o equivalente a um dump da RAM, como no processo de hibernate. Dessa forma você consegue boots quase instantâneos, que levam segundos em vez de minutos.

E como também expliquei no video de virtualização, existe a opção de paravirtualização. Numa virtualização completa o kernel dentro da máquina virtual não sabe que está numa máquina virtual, é um Inception. Numa paravirtualização você modifica o kernel de dentro pra ele estar ciente de estar num ambiente virtualizado e conseguir um comportamento melhor cooperando com o sistema operacional do lado de fora.

Um último componente um pouco inusitado foi a inclusão de uma parte do antigo projeto Plan9, no caso o protocolo 9P que era usado pra file system em rede. Pense assim, como a partir do Windows eu poderia acessar o filesystem do Linux e vice versa se agora o Linux vai rodar de dentro de uma máquina virtual? Existem várias opções como o próprio protocolo SMB e o serviço SAMBA ou mesmo SFTP que é FTP em cima de SSH. A própria Microsoft não se manifestou do porque dessa escolha oficialmente, mas algumas teorias dizem que talvez seja porque o protocolo 9P é mais simples e mais fácil de implementar do que os disponíveis hoje.

De curiosidade o Plan9 é outro projeto da antiga Bell Labs que inventou a linguagem C e o UNIX, na realidade parte das mesmas equipes criaram o Plan9 que era um sistema operacional distribuído em rede. Com o tempo o Plan9 caiu em desuso e a Bell Labs criou o projeto Inferno que tinha como objetivo virar concorrente do então novo Java da Sun, e nas pesquisas de sistemas distribuídos tanto a Sun quanto a Bell Labs chegaram à conclusão que precisariam de uma máquina virtual pra lidar com tantas configurações de rede diferentes disponíveis na época. Vocês podem ver que a história da virtualização vem de longa data, e só nesse episódio vocês viram que nos anos 70, 80, 90 até os 2000 tinha alguma coisa de virtualização em cada solução da época. Virtualização e containerização não são tecnologias novas, são décadas e décadas de pesquisas e experimentação.

De qualquer forma, somando os lightweight utility VM do Hyper-V com a capacidade de boot rápido, mais uma kernel de Linux de verdade customizada pela Microsoft, mais a implementação do protocolo 9P pra exposição do filesystem em rede, e agora temos o Windows Subsystem for Linux versão 2 ou WSL 2. Ela nunca vai ter as mesmas possibilidades de integração com o resto do Windows como o WSL 1 tinha, mas por outro lado ela oferece 100% de compatibilidade binária com Linux, coisa que o WSL 1 nunca ia ter. E como agora o filesystem se tornou virtualizado, ele parou de ter os problemas de performance por causa do Windows Defender também. Por outro lado o WSL2 não oferece ainda opções pra configurar o filesystem virtual, se não me engano ele tem um limite máximo pra 256GB, o que é suficiente pra maioria dos cenários, mas seria bom ter futuramente a opção de expandir esse drive.

Do ponto de vista de performance, sem rodar nenhum benchmark nem nada, eu diria que é a mesma performance que eu já sentia rodando num VMWare, porém reservando menos recursos da máquina no geral. Usando todos os dias tudo vem funcionando exatamente igual funcionaria num Linux em Virtualbox ou Vmware. É um linux virtualizado. E como bônus se de dentro do WSL2 você subir um servidor, digamos um servidor de Rails que se liga na porta 3000, você pode abrir o Chrome do Windows e acessar localhost:3000 e vai abrir normalmente, porque ele faz automaticamente o NAT interno de mapeamento de portas. Isso é ao mesmo tempo bom e ruim, porque se você tiver serviços no Linux com portas que conflitam com portas no lado do Windows, vai ter problemas que podem ser difíceis de diagnosticar.

Do ponto de vista de ecossistema é um passo gigantesco porque se você acompanhou pessoalmente a história que eu contei até agora, como foi o meu caso, se no ano 2000 alguém me dissesse que um dia a Microsoft embutiria o binário da kernel do Linux dentro do Windows, eu diria que a pessoa era louca e devia se tratar. Diferente de alguma coisa como Cygwin, sendo suportado pela própria Microsoft, mais e mais pessoas podem depender dessa opção como algo estável e que vai estar disponível mesmo em futuros upgrades do Windows.

A história foi longa, mas instalar o WSL 2 é super easy, barely an inconvenience… Quando sair a versão oficial no próximo upgrade do Windows 10 você pode pular o primeiro passo, mas se ainda for setembro de 2019, você vai precisar se cadastrar no programa Windows Insider. Ah sim, só funciona no Windows 10 Pro, o Windows 10 Home não tem suporte a Hyper-V se não me engano. Uma vez cadastrado, você vai precisar habilitar o Fast Ring que vai trazer os builds mais recentes do Windows mas também tem o risco de vir binários instáveis. Habilitar o Fast Ring é concordar que você está baixando versões alfa de muita coisa e instabilidades fazem parte do contrato. Eu venho usando o Fast Ring faz meses e tirando uma ou duas vezes que tive telas azuis, no geral tudo tem funcionado sem problemas graves.

No caso até a data onde estou gravando este episódio está na build 18970. Com o Fast Ring ativado é só deixar o Windows Update baixar as últimas versões. Vai demorar bastante pra baixar e instalar a última versão, vamos esperar um pouco … só mais um pouco …. só mais um pouco …. ah sim, em uma das vezes que fui instalar ele reclamou que eu tinha o VMWare instalado, precisei baixar a versão mais nova pra ele parar de reclamar, mas cuidado com isso: com o Hyper-V ativado, não dá pra usar Virtualbox nem VMWare até eles aderirem às APIs de virtualização da Microsoft. Enfim, uma vez atualizado daí é restartar. Agora você precisa abrir um Powershell como Administrador e digitar o seguinte comando:

Enable-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatform

Isso vai exigir um restart e pronto, agora você já tem WSL. Abra um command prompt ou powershell e garanta que está com o WSL 2 como padrão executando o comando

wsl --set-default-version 2

E pra instalar o Ubuntu você pode ir na Windows Store, procurar por Ubuntu e instalar. É gratuito. Daí você espera um pouco … configura seu usuário e senha e …. Instalado. Primeira coisa que eu sempre faço quando instalo é rodar o apt update e upgrade pra atualizar todos os pacotes. Daqui você pode seguir meu video de Ubuntu e praticamente tudo deve funcionar.

Eu digo praticamente porque o WSL é feito primariamente pra aplicativos de linha de comando como o próprio Bash, coisas como ssh, git e tudo mais. Mas sempre existe a opção de instalar um cliente X no Windows e rotear o DISPLAY do X no Linux pra ser fora dele. Se você não sabia disso, o X é outro capítulo conturbado na história do UNIX e Linux. Nós tivemos o XFree86, depois o X.org e finalmente muitos estão migrando pro Wayland.

Em termos simples, o X é feito pra aplicativos gráficos. A intenção original é que um servidor UNIX com um servidor X poderia servir múltiplos terminais burros, incluindo terminais gráficos, que seriam clientes de X. Pense em servidor web e navegador web, é basicamente a mesma coisa só que em vez de trafegar um protocolo primitivo como o HTTP ele usa um protocolo próprio do X pra enviar comandos como “desenhe um botão na tela” e quando o botão é clicado essa ação trafega pro servidor X decidir o que fazer e devolver outro comando pra redesenhar alguma parte da tela. Isso até que funciona, o que o povo de desenvolvimento não gosta é da implementação, é um código difícil de dar manutenção.

E as coisas ficaram mais difíceis depois que a Apple mostrou o que era possível fazer com um sistema de composite e aceleração via hardware como o Quartz e a interface Aqua. Como você faz pros clientes X terem os mesmos recursos? Dificulta muito que o X era um monolito, que os drivers das principais GPUs como NVIDIA é proprietário e distribuído só como binário, e as versões open source tem qualidades variadas, e no final o que acaba acontecendo é que você raramente usa o X de forma distribuída e tanto o cliente quanto o servidor ficam na mesma máquina desktop de qualquer jeito. Por causa disso o X tem dois modos de renderização acelerada, a direta onde o próprio servidor X acessa a GPU e o indireto onde ele manda os comandos de OpenGL pro cliente rodar.

No caso do WSL, ele não tem acesso direto a algumas coisas incluindo o hardware de vídeo. Portanto ele depende de um rasterizador via software. Você não tem como rodar o cliente de X dentro do WSL porém você pode rodar o cliente de X de Windows e rotear os comandos de X do WSL via rede pra fora. E vai funcionar perfeitamente bem. Existem duas opções gratuitas e open source que são o VcXSrv e o XMing e uma versão paga que eu pessoalmente acho melhor que é o X410, que eu costumo usar, mas na prática tanto faz. Se eu não estou enganado todos devem suportar o modo de aceleração indireta, basta configurar dentro do WSL uma variável de ambiente dizendo isso, o libgl_always_indirect e adicionar num bashrc pra sempre ter a variável quando se logar.

export LIBGL_ALWAYS_INDIRECT=1

Pra rotear os comandos o WSL precisa do endereço IP do host Windows. No WSL 1 ficava tudo em localhost porque pra todos os efeitos e propósitos o WSL 1 rodava lado a lado do Windows e não virtualizado. No WSL 2 como ele é uma máquina virtual, do lado de dentro ele tem também uma rede virtual e o Windows do lado de fora é mapeado pra um endereço local dentro, é um tipo de ponte de rede que traduz o roteamento de pacotes do lado de dentro pro lado de fora. Se fosse localhost bastava fazer a variável Display ser igual a dois pontos e zero. Porém toda vez que a máquina reinicia pode ser que esse endereço virtual mude. Precisamos configurar uma variável de ambiente que aponte pra esse endereço e pra isso podemos fazer o seguinte one-liner, adicionar no bashrc e agora configurar a variável display pra usar o valor

export WSL_HOST=$(tail -1 /etc/resolv.conf | cut -d ' ' -f2)
export DISPLAY=$WSL_HOST:0

Colocando essas variáveis de ambiente no arquivo .bashrc, toda vez que o bash iniciar ele vai ter essas variáveis. E agora podemos instalar alguns programas gráficos que eles vão aparecer do lado de fora, no Windows mesmo. Vamos instalar o gvim que eu gosto, o terminal Tilix que é o mesmo que eu instalei no tutorial de Ubuntu e o pacote dbus-x11 que programas gnome precisam.

Agora, precisamos instalar o tal cliente X, que como eu disse antes tem opções gratuitas mas eu pessoalmente gosto do X410 que eu já tinha comprado então vamos instalar pela Windows Store. Quando terminar e ele carregar, não esquecer de habilitar pra poder receber conexões da rede pública, se for a primeira vez o Windows Firewall vai apitar pra liberar acesso, libere e pronto. De volta ao bash, como só editamos o script bashrc precisamos ou deslogar e logar de novo ou só recarregar o bashrc com o comando source. Agora podemos abrir o gvim e olha só, abriu fora da máquina virtual, como um programa normal de Windows. Mesma coisa o Tilix e nele podemos configurar a aparência, escolhemos o tema Material … melhor o Monokai Dark … pronto, e agora podemos configurar o tamanho das fontes.

Mas pra mudar o tema geral, das bordas e tudo mais não vamos poder usar o gnome-tweaks. Como não estamos carregando todos os serviços que o gnome precisa pra rodar, se gastar algum tempo em tentativa e erro uma hora o gnome tweaks deve funcionar, mas por agora podemos simplesmente editar manualmente o arquivo de configurações em .config, gtk-3 settings.ini. Dentro dele habilitamos o modo dark, depois declaramos o nome do tema que é o Flat Remix GTK Blue Darker e finalmente o nome do pacote de ícones que é o Flat Remix Blue Dark.

Agora precisamos de fato baixar esses temas e ícones e aqui é a mesma coisa que já fizemos no episódio de Ubuntu, vou seguir exatamente o mesmo tutorial de antes. E como é a mesma coisa, vamos acelerar isso aqui.

Pronto, agora podemos chamar o Tilix de novo boom, tá bem mais bonito não acham? O Gvim também ficou um pouco melhor mas ele ainda está mais cru porque não carreguei nenhum dotfiles que configura ele como o Yadr que mostrei no episódio de Ubuntu.

Até agora eu estava usando o programa Command que vem com todo Windows. A Microsoft veio modernizando o antigo Command pra aceitar comandos de VT100, ANSI e tudo mais e com isso ele hoje é capaz de renderizar corretamente, vocês podem ver que as cores ANSI funcionam perfeitamente. Ele ainda tem cheiro de coisa velha mas comparado a como era até as primeiras edições do Windows 10, foi uma evolução considerável. Mas terminais mais maduros como o Tilix que acabamos de instalar ou mesmo o terminal padrão de um MacOS ainda são melhores.

Em vez de mexer demais no código velho do antigo Command, eles resolveram codificar um novo e com isso existe o programa simplesmente chamado de Terminal que você pode instalar via o Windows Store. Ele ainda está em desenvolvimento e por isso se chama Preview, mas mesmo no estágio atual ele já é muito melhor que o Command, inclusive ele é acelerado via DirectX então coisas como scrolls longos renderiza muito rápido. Vamos abrir e veja como ele é mais moderno com suporte a tabs. A configuração ainda é toda em texto, o que eu não acho ruim. Por exemplo, podemos mudar o tamanho das fontes de todos os perfis. Vale a pena brincar nesse arquivo um pouco pra customizar como você quiser.

Você pode usar esse novo Terminal pro WSL 2 até pra rodar o antigo CMD se precisar de scripts de batch antigos ou também rodar Powershell em outra aba. Ele é totalmente configurável e customizável, suporta abas e pode ser uma boa opção. Eu particularmente prefiro carregar o próprio Tilix e usar um terminal de verdade que suporta split de tela. Tem gente que prefere usar o TMux pra splits mas pro meu workflow um simples split do próprio terminal é suficiente. Se quiser ver o Tmux em funcionamento, veja meu vídeo de Ubuntu onde eu mostro como instalar e usar.

Mas só instalar o Ubuntu é muito fácil. Agora é uma boa hora de mostrar algo diferente. Hoje a Microsoft suporta o Ubuntu, o Fedora e o OpenSuse além de uma distro paga feita especialmente pro WSL 2 que é Pengwin, que se não me engano é uma derivação de Debian. Mas eles tem receitas no GitHub de como você pode empacotar qualquer outra distro de Linux. Desde o WSL 1 havia uma versão de Arch que você podia instalar e eu testei e vi que eles deram suporte pro WSL 2 também, então porque não testar? Mas, aviso que essa demo é meio experimental, ele não tem suporte da Microsoft e muitas coisas não funcionam perfeitamente ainda. Se você for experiente em Linux talvez consiga achar os workarounds, mas se for iniciante, por agora é melhor ficar no Ubuntu mesmo.

Vamos no Google, pesquise por ArchWSL e o primeiro link deve ser a página de GitHub do projeto. Lá tem todas as instruções que você precisa. Baixe o zip, descompacte em algum lugar como no seu diretório de usuário do Windows. Dentro vai ter um executável de Arch, dê duplo clique ou abra o novo Terminal, navegue até o diretório, digite arch e execute. Esse instalador faz menos coisas que o de Ubuntu, o que é esperado pra filosofia Arch de fazer você configurar tudo. Ele vai te logar como root direto. A primeira coisa a fazer é colocar uma senha pro root. Agora vamos criar um novo usuário não-root, configurar a senha, e abrir o visudo pra dar permissão de sudoer pra esse novo usuário. Dessa forma você vai poder logar como esse usuário em vez de root e ter acesso a sudo. … Feito isso podemos sair da sessão do Arch de volta ao Command do Windows e configurar o arch pra carregar com esse novo usuário.

Feito isso precisamos inicializar o pacman que é o gerenciador de pacotes, isso só precisa ser feito uma vez. Uma vez inicializado, mesma coisa de antes, eu gosto de atualizar os pacotes todos e fazemos isso com o comando pacman traço Syu. No Ubuntu começamos instalando pacotes como o build-essential pra ter o toolchain de desenvolvimento. Com o pacman instalamos pacotes como o base, base-devel e vamos aproveitar pra instalar também o gvim, tilix e git.

Seguindo os mesmos passos, vamos exportar as mesmas variáveis de ambiente pra rotear o X…. Pronto, podemos carregar o Tilix. Porém aqui já vemos um problema dessa versão. Programas gnome precisam do dbus pra comunicação interprocessos, incluindo gerenciar configurações. Mas veja as mensagens de aviso dizendo que não encontra o dbus-launch. Um workaround pra isso é chamar o dbus-launch manualmente. De novo, eu não parei pra investigar a fundo quais dependências estão faltando ou serviços que não estão carregando. Se você souber como corrigir isso, não deixe de mandar nos comentários abaixo.

Aliás, uma coisa que notei é que tanto o Ubuntu como esse Arch de WSL não bootam com o systemd, ou qualquer outro init system então nenhum serviço carrega e comandos como systemctl pra iniciar ou parar serviços não vão funcionar. Você precisa carregar serviços manualmente se precisar.

De qualquer forma, só pra mostrar como as coisas são muito parecidas, vou acelerar de novo pela parte que eu baixo os temas Flat Remix, editar o arquivo settings.ini manualmente e … pronto, tilix carregado com o novo tema, igualzinho antes.

E com isso temos um Arch instalado, você pode seguir qualquer tutorial normal de como configurar seu Arch como ambiente de desenvolvimento ou seguir as mesmas instruções que eu mostrei pro Ubuntu.

Agora, vamos voltar pro Ubuntu. Pra demonstrar que tudo funciona, vamos seguir meu tutorial e instalar o bom e velho ASDF como já mostrei antes. …

Não esqueça de colocar os scripts de asdf no bashrc ou equivalente do seu shell pra iniciar sempre que se logar. …

Feito isso podemos instalar o plugin de ruby ….

Agora podemos listar as versões de Ruby disponíveis …

Vamos escolher a mais recente, a 2.6.4 e instalar ….

Oops faltou instalar mais dependências de desenvolvimento do sistema, então vamos começar pelo pacote build-essential.

Ainda temos mais dependências, então vamos instalar … Oops ele não acha o libgdbm3 então vamos tentar libgdbm Oops ele não acha libgdbm também, ok deixa ele pra lá, não vamos precisar disso agora mesmo

Pronto, pacotes instalador, então vamos instalar o Ruby 2.6.4. Demora um pouco mas uma hora ele termina.

Não esquecer de configurar essa versão pra ser a padrão do sistema Ruby instalado, vamos instalar a gem do Bundler

E finalmente, vamos instalar as gems do ruby on rails

Como o Rails hoje usa muito javascript também, inclusive ele integra com o yarn e com webpack, melhor instalar o plugin de nodejs do asdf. …

Pronto, mesma coisa, vamos listar as versões disponíveis e … escolher a mais recente, a 12.9.1

Oops faltou configurar as chaves gpg dos repositórios, então vamos na página de github do plugin

Basta copiar esta linha e executar pra instalar as chaves Pronto, chaves configuradas, agora podemos tentar instalar a última versão de novo

Quando terminar, não esquecer de configurar essa versão como a global do sistema Esse passo nem precisa na real, mas eu tenho costume forçar a atualização do npm pra garantir que estou com a versão mais nova.

Vamos instalar o yarn também

Agora, vamos brincar um pouco e criar um novo projeto Rails do zero com seu gerador.

Oops falhou porque faltou instalar o sqlite3. Isso é opcional mas como eu não indiquei nada no gerador ele por padrão espera ter o sqlite3 então vamos instalar.

Como parou o gerador no meio, então vamos entrar no diretório do projeto e rodar manualmente o comando bundle install pra terminar de instalar as dependências.

Agora vamos carregar o rails server pra testar a página de Bem Vindo e oops, como o gerador tinha parado aquela hora ele não inicializou o webpack, então vamos fazer isso manualmente com a task webpacker dois pontos install.

Pronto, agora sim vamos carregar o rails server.

E com meu navegador Opera de Windows, podemos carregar o localhost porta 3000 e veja que funcionou! O WSL mapeou corretamente a porta 3000 de dentro da máquina virtual pra estar acessível do lado de fora no Windows.

Como última parte desse demo, vamos continuar o projeto gerando um controller de rails pra testar mais um pouco. Mas e agora, como vamos editar esses novos arquivos? A partir daqui eu abriria meu gVim devidamente configurado mas eu sei que muita gente migrou pra Visual Studio Code hoje, que eu também concordo que é um editor de textos e uma IDE excepcional. Altamente recomendado então vamos na página dele e baixar o instalador. E sim, vamos baixar o instalador de Windows e instalar do lado de fora no Windows.

Mas e agora? Como o VS Code de Windows vai editar os arquivos do meu projeto que está dentro do WSL? Aqui começa uma das vantagens do WSL ser desenvolvido pela Microsoft, o VS Code automaticamente detecta a existência do WSL, detecta que o Ubuntu é a distro padrão, instala os plugins adequados e agora podemos abrir uma nova janela do VS Code que vai estar conectado no WSL, olha a barra de status, no canto inferior esquerdo, e veja que ele está abrindo o WSL.

Com isso quando mandamos abrir uma pasta ele vai explorar o filesystem de dentro do WSL automaticamente apontando a partir do diretório do meu usuário e de lá podemos abrir o projeto Rails que acabamos de criar.

Então vamos procurar nosso arquivo de index html e editar alguma coisa.

Vamos também editar o arquivo de rotas pra colocar esse controller como raiz.

Agora vamos reiniciar o servidor e recarregar a página no navegador e boom, olha só, funciona de boas. Apesar do WSL 2 ainda não ser tão completo quanto rodar uma máquina virtual de verdade, ele é leve e simples o suficiente pra ser tipo um runtime que roda em background, você pode usar o Terminal no Windows e o VS Code no Windows mesmo e desenvolver quase como se estivesse num Linux de verdade. Pra muitos casos de uso isso pode ser exatamente o que as pessoas precisam.

A última questão que todo mundo tem é, mas e o Docker? Funciona? Vamos no google de novo procurar um tutorial de docker pra ubuntu, os da digital ocean costumam ser bons então vamos nele.

Vamos seguir passo a passo como ele manda, primeiro instalar a chave gpg dos repositórios oficiais do docker.

Adicionar os repositórios como fontes pro apt

Rodar o apt update pra atualizar

Garantir que vamos instalar dos repositórios do docker

Finalmente instalar o docker propriamente dito

E iniciar o serviço com o systemctl e oops

Como eu disse antes, o WSL não boota com o systemd então não existe suporte ao init system e o comando systemctl não vai funcionar.

Mas, podemos executar os daemons do Docker manualmente, e pronto, é meio chato ter que fazer isso toda vez que o WSL reiniciar, mas é melhor que nada.

Continuando o tutorial, vamos adicionar o grupo docker ao nosso usuário. Agora a gente ou desloga fechando o terminal ou só fazemos su pra abrir uma nova sessão direto.

Pronto, checando se tá tudo ok e agora podemos rodar o famoso hello world e ver que tudo funciona.

E pra garantir vamos um passo além e instalar o Postgres no Docker. E mesma coisa, primeiro vamos no Google procurar um tutorial qualquer.

Primeiro, puxamos a imagem do docker

Agora criamos diretórios pra guardar os bancos de dados

Finalmente podemos subir o Postgres dentro do Docker com esse comandão aqui, que vai configurar coisas como o mapeamento de portas.

Pra demonstrar que é o docker nativo de verdade rodando, se rodarmos o comando ps aux podemos ver todos os processos rodando dentro da máquina virtual e temos o postgres aparecendo como deveria. Se você assistiu meus episódios sobre virtualização e containers já entendeu que Docker não é virtualização. Na prática tudo que você roda via Docker roda normalmente como um processo no seu sistema, mas o Docker usa recursos da Kernel do Linux como cgroups pra fazer o sistema operacional mentir pro processo, fazendo esse processo acreditar que está rodando sozinho na máquina.

Como eu já tinha mostrado no episódio de Ubuntu, podemos navegar pro diretório /proc no subdiretório que é o pid do processo e oops, pid errado, vamos listar de novo e pegar o pid certo e navegar de novo

Pronto, agora podemos listar o conteúdo do meta arquivo cgroups e ver como ele está sendo mascarado pelo docker.

Pra todos os efeitos e propósitos, o processo do postgres acredita que está rodando sozinho na máquina, e pra gente do lado de “fora” é só mais um processo rodando como se tivesse sido instalado fora do Docker. Por isso containers de Docker são ordens de grandeza mais leves e performáticos do que uma máquina virtual, porque na prática não existe um hypervisor envolvido, é só uma casquinha muito leve do próprio kernel. O kernel precisa ter esse suporte e por isso não funcionava no WSL 1 porque é difícil recriar isso só com um wrapper em cima da kernel do NT e eles nem chegaram a tentar eu acho. Então o Docker de Windows, pra rodar containers de Linux precisava de fato executar um Linux no Hyper-V pra criar os containers dentro. Aqui é a mesma coisa já que o WSL 2 é uma máquina virtual rodando uma kernel de Linux de verdade, entenderam?

Agora podemos conectar nesse postgres dentro do container através da porta que o Docker mapeou pra fora. Vamos seguir o tutorial e oops ainda não temos o cliente de postgres instalado então vamos seguir o que ele manda instalar.

Oops, ainda falta mais um pacote, vamos seguir a instrução e instalar e agora sim, cliente instalado, vamos rodar o comando de novo.

Pronto! Estamos conectados no postgres, rodando dentro do container do Docker.

Podemos rodar docker ps pra ver quais containers estão sendo executados e podemos pegar o pid do container e com ele rodar comandos como o docker stop pra parar o container e assim derrubar esse postgres.

Eu até acho que nesse ambiente de WSL 2, onde ele não sobe o systemd no boot e por isso não sobe daemons automaticamente

E é isso, o WSL 2 é basicamente um Hyper-V customizado pra rodar um kernel de Linux modificado pela Microsoft. E como a licença GPL obriga qualquer empresa a abrir o código fonte se for modificado, a Microsoft mantém o fork com as modificações no GitHub, e eu vou deixar o link nas descrições abaixo também. Eles vão sempre manter a versão estável mais nova e não devem ficar dando suporte pra kernels antigas, então você sempre vai ter a opção de rodar as distros mais novas. Se precisar rodar Linux velhos, você mesmo vai ter que instalar e configurar tudo manualmente numa máquina virtual Hyper-V do jeito antigo. O WSL 2 é um facilitador pro Hyper-V com um Linux melhor integrado.

Na prática, o WSL 1 era algo parecido com o Wine só que ao inverso. O WSL 2 é mais parecido em conceito com o coLinux, mas na prática é um Linux rodando dentro de uma máquina virtual. Então se você já usava Linux em Virtualbox ou VMWare na prática não tem grandes vantagens, especialmente porque o WSL não expõe tantas opções de configuração como um VMware. Por outro lado a grande vantagem é o suporte oficial da Microsoft, ou seja, pela primeira vez é uma opção padrão. Veja a integração do Visual Studio Code com o WSL por exemplo. Uma vez que o WSL é um componente oficial no Windows, outras soluções podem começar a se integrar e criar um ecossistema

Eu gostava bastante do conceito do WSL 1, que seria o único caminho pra ter uma camada Linux integrada de verdade na fundação do Windows, o mais próximo que já se chegou do que se tem um macOS sem precisar reescrever todo o sistema operacional. Mas, eu entendo que era bem pouco prático dar suporte. Então o WSL 2 é um bom meio do caminho. Muita gente precisa estar no Windows seja pra usar programas corporativos que só existem em Windows, ou rodar pacotes como os da Adobe que não existem pra Linux ou mesmo fazer desenvolvimento em .NET pra Windows. Agora existe uma opção oficial pra rodar ferramental Linux lado a lado, com uma boa integração. Ele é mais limitado, ainda existem alguns bugs, mas com o tempo isso deve melhorar.

Na prática, se você já usa Virtualbox ou Vmware pra desenvolver em ambiente Linux, não existe de fato muita vantagem em usar o WSL 2. Mas se você quer integrar desenvolvimento de projetos em Node ou Python dentro do Linux junto com outros projetos no Windows usando o mesmo Visual Studio Code, por exemplo, é uma ótima opção. Aliás, apesar de existir um certo suporte nativo a rodar coisas como Node, PHP e Python no próprio Windows, eu altamente não recomendo, o certo é rodar dentro do Linux e ter acesso a tudo que esses ecossistemas oferecem. Toda versão de uma ferramenta Linux no Windows tem limitações, e rodando no WSL 2 ou numa máquina virtual elimina essas restrições. Evite ao máximo rodar ferramentas de Linux compiladas pra Windows, você sempre vai estar usando menos do que as ferramentas oferecem. Nesses casos o WSL 2 interessante pra desmotivar a existência dessas alternativas e simplesmente rodar o original num Linux de verdade, agora suportado pela própria Microsoft.

O único cenário onde eu ainda recomendaria Linux instalado nativo é se você está brincando de machine learning com ferramentas que precisam de acesso direto à GPU. Isso nem o WSL 2 e nem muitas máquinas virtuais vai conseguir te dar. Você precisa de acesso direto ao hardware. O WSL 2 hoje não tem como expor a GPU pra dentro da máquina virtual. Esse é um dos casos que é melhor uma configuração de dual boot se você também precisa de Windows, e se manter num Linux instalado nativamente na sua máquina.

No caso de desenvolvimento Web normal, onde você quer ter um postgres, redis, nginx, nodejs, rails, elixir, o WSL 2 é uma opção excelente e com a integração do Visual Studio, eu acho que se torna um pacote bastante atraente. Eu estou usando os dois, numa máquina tenho um WSL 2 e em outra tenho o VMWare. Como meu dia a dia não é mais ocupado por programação na maior parte do tempo, então pra mim o impacto é muito menor. Se você já testou essas opções, compartilhe sua experiência com o pessoal nos comentários abaixo. Se curtiu o video deixe um joinha, assine o canal e não deixe de clicar no sininho pra não perder os próximos episódios. Por hoje é só, a gente se vê, até mais!

No episódio de hoje, pegando carona que eu fiz um vídeo sobre instalar ambiente de desenvolvimento em Ubuntu (https://www.youtube.com/watch?v=epiyExCyb2s) eu queria aproveitar pra contar vários pequenos momentos e conceitos sobre sistemas operacionais que eu gosto de ficar discutindo.

No geral eu poderia dizer que é um vídeo “comparando” Linux, Mac e Windows mas a idéia não é escolher um no final mas sim delinear o que aconteceu nos últimos 20 e tantos anos que me fez ficar mudando de sistemas e hardware ao longo do tempo e porque existem algumas opiniões formadas hoje que quem está só começando não consegue entender porque as recomendações são extremas em muitos casos.

Antigamente a gente pedia “pelamor” pros desenvolvedores darem uma chance pros Macs. Hoje em dia o povo não entende porque tem tanta gente ainda recomendando Macs tão veementemente. E no fim, qual é a melhor escolha pra desenvolvedores de software? Vamos descobrir isso hoje.

== Errata

Eu falei que Fedora usa Yum, mas não é verdade, eu esqueci que agora ele usam DNF.

== Seções:

03:03 - Linux 14:00 - Mac 32:45 - Windows

== Links:

• How eSports became mainstream (https://www.diggitmagazine.com/papers/esports-mainstream)

• Why the 64-bit Version of Windows is More Secure (https://www.howtogeek.com/165535/why-the-64-bit-version-of-windows-is-more-secure/)

• Steve Jobs changed the future of laptops 10 years ago today (https://www.theverge.com/2018/1/15/16892792/apple-macbook-air-steve-jobs-anniversary)

• WWDC 2005 Keynote (https://www.youtube.com/watch?v=B6iF6yTiNlw)

• Steam Proton (https://www.protondb.com)

• Puppy Linux (http://puppylinux.com)

• DDR5 | O que sabemos desse novo padrão de memória até agora (https://canaltech.com.br/hardware/tudo-sobre-memoria-ddr5-134725/)

• What Is PCIe? (https://www.lifewire.com/pci-express-pcie-2625962)

• NVMe SSDs: Everything you need to know about this insanely fast storage (https://www.pcworld.com/article/2899351/everything-you-need-to-know-about-nvme.html)

• A ZFS developer’s analysis of the good and bad in Apple’s new APFS file system (https://arstechnica.com/gadgets/2016/06/a-zfs-developers-analysis-of-the-good-and-bad-in-apples-new-apfs-file-system/)

• Why John Carmack Chose NeXT For Developing ‘Doom’ And Other Favorites (https://www.forbes.com/sites/quora/2016/09/01/why-john-carmack-chose-next-for-developing-doom-and-other-favorites/#6fb22dbb14d1)

• Picking up the pieces: John Siracusa mourns the Power PC (https://arstechnica.com/gadgets/2005/06/mac-20050607/)

• NextSpace (https://trunkmaster.github.io)

• Scaling from 2,000 to 25,000 engineers on GitHub at Microsoft (https://jeffwilcox.blog/2019/06/scaling-25k/)

• Rocketz Workstations (https://rocketz.com.br/workstation)

• AkitaOnRails - Optimizing Linux for Slow Computers (https://www.akitaonrails.com/2017/01/17/otimizando-o-linux-para-computadores-lentos)

=== Script

Olá pessoal, Fabio Akita

Seguindo na discussão sobre instalação de ambiente de desenvolvimento de software, eu acho que preciso responder, por que diabos eu uso Windows 10? E na realidade a resposta é bem menos interessante do que parece.

A resposta mais simples é porque na prática não faz quase nenhuma diferença se você estiver usando hardwares como o meu. O episódio de hoje vai ser longo, porque eu comecei a escrever e fui jogando vários assuntos aleatórios na mistura. Quando começamos a falar de sistemas operacionais eu tenho vários conceitos e histórias que acho importante dar contexto. A idéia foi trazer vários pontos que eu considero interessantes e falar tudo de uma vez do que tentar diluir em múltiplos episódios. Mas no final eu acredito que vocês vão sair com um entendimento maior do que simplesmente diferenciar um sistema de outro pelo visual, então tenham um pouco de paciência hoje.

(…)

Desde pelo menos 2013 eu não uso computadores com menos de 16GB de RAM. E recentemente meus dois computadores principais, um Lenovo Thinkpad Extreme e um PC torre que comprei da Rocketz ano passado, tem 32GB de RAM. Ambos tem placas NVIDIA, o primeiro com um GTX 1050 que é mais que suficiente pra um notebook, e o segundo com um bom GTX 1070Ti do ano passado que não é topo de linha, mas até pra gaming 1080p a mais de 100fps é bem suficiente.

Meu primeiro Mac foi um Mac Mini G4 de 2003 com processador Power PC G4 de 1.25Ghz, não lembro se tinha 2GB de RAM, HD mecânico de 40GB, mas praquela época já tinha USB-2 e Firewire 400. Eu lembro que brinquei muito de editar vídeos com iMovie e gravar em DVD. Eu tive depois o primeiro Macbook branco de 13" com processador Intel Core Duo. E meu último Mac foi um Macbook Pro 15" de 2014 com tela retina display, Core i7, 16GB de DDR3, 512GB de SSD e vinha com a GeForce GT 750M com 2GB de GDDR5. Na minha opinião a última série de Macbook Pro ainda à frente do seu tempo, quando o teclado ainda era bom, quando não tinha touchbar, quando havia Magsafe pro cabo de força.

Mas, eu acho que a grande maioria das pessoas assistindo não está muito disposto a gastar mais que 1000 dólares numa máquina, de preferência menos. E eu concordo com vocês, especialmente se eu tivesse 25 anos eu não poderia comprar nada muito mais caro que 500 dólares, e parcelado, claro. Como eu já disse no episódio de Ubuntu, vocês não precisam de uma máquina tão topo de linha assim. Em desenvolvimento de software, a menos que você esteja programando apps Android e precisa subir aquele emulador lento, uma máquina Core i3 Skylake, com 4GB de RAM, e até com HD mecânico deve ser suficiente pra maioria dos casos. Daí com o tempo você troca o HD mecânico por um SSD de 256GB, um HD externo via USB-3, e mais 4 GB de RAM pra ficar com 8.

A idéia não é ser uma divisão perfeita, mas vamos começar essa conversa de hoje falando um pouco sobre Linux primeiro, depois vou falar de Mac e depois de Windows. Se você viu meus episódios da série de Back-end onde eu explico sobre threads e schedulers, já sabe que existem diferentes formas de estratégia pra threads. E os 3 sistemas operacionais principais: Windows 10, macOS e as várias distros Linux usam estratégias de schedulers diferentes. O melhor sendo o CFS do Linux. O MacOS e o Windows implementam multilevel feedback queue, pense em múltiplas filas com prioridades, mas por alguma razão a implementação do Windows continua sendo a piorzinha. É aquele momento que tudo dá uma engasgada, fica um pouco lento, daí volta. Ou você tá assistindo youtube ou netflix, deixa outra coisa rodando por trás e em algum momento seu vídeo perde frames, dá uma engasgada. É o tipo de coisa que acontece com frequência em máquinas fracas. Eu raramente vejo porque tenho máquina sobrando. Mas é uma coisa que em Linux e Mac não acontece nem de longe com tanta frequência mesmo em máquinas mais antigas.

Lembram a metáfora de threads tendo que esperar a vez e o scheduler mudando a thread de mesa às vezes e o custo relacionado a mover os dados de uma core pra outra? Até algumas versões atrás o Windows fazia algo muito burro, não lembro se já corrigiram. Se você tinha cores sem fazer muita coisa, ele pegava a thread em execução e mudava pra outro core. Do nada, em vez de simplesmente manter na core que ele tava. Ele tentava ser preemptivamente mais esperto e isso causava overhead desnecessário. É exatamente o tipo de coisa que raramente acontece no macOS ou Linux. Sendo honesto, eu não tenho visto acontecer no Windows também, mas ainda não sei o quanto é porque meu hardware tá compensando isso.

Falando em schedulers, além de schedulers de threads como o Completely Fair Scheduler ou CFS, também temos schedulers pra I/O como o Completely Fair Queue ou CFQ. Se você usa HD mecânico e muitos processos querem fazer coisas no disco ao mesmo tempo, dá pra imaginar que não dá, então você vai também precisar de algum tipo de queue ou fila pra gerenciar isso. E no Linux você pode trocar os schedulers de threads e os schedulers de I/O.

Numa máquina parruda, com muitos cores sobrando e SSD veloz, você sempre mantém o default que é CFS com CFQ ou noop pra não precisa gastar computação gerenciando filas pro I/O, já que SSDs são ordens de grandeza mais rápidos que HD mecânicos e conseguem lidar com muita concorrência. Se por outro lado você está numa máquina mais devagar, pode mudar do CFS pro MuQSS e do CFQ pro BFQ ou o Budget Fair Queue, além de configurar o swapiness da kernel pra evitar ao máximo usar swap de disco e criar mais gargalo no seu HD lento. São as coisas que explico no meu artigo sobre configurar Linux pra máquinas lentas que vou deixar de novo nas descrições abaixo.

Além disso você pode somar configurações assim com distros preparadas pra instalar componentes mais leves do que os Ubuntu da vida, e evitar que você precise manualmente ficar instalando vários pacotes. Exemplo disso seria um Lubuntu, ou Light Ubuntu, ou também um Puppy Linux que é baseado em Debian. Como parêntese alguns me falaram do Pop OS mas eu não gostei muito dele, é basicamente um Ubuntu pré-configurado e com repositórios extras pra facilitar instalar algumas coisas como tensorflow. Mas não vi grandes vantagens não. Primeiro quero ver se ele dura, já que foi criado e é mantido por uma pequena empresa tentando vender hardware customizado. Já vi isso acontecer antes com distros como Lindows, mas que sumiram. Um Mint ou Elementary pelo menos já existem faz alguns anos e continuam sendo suportados. Pra eu instalar como daily driver, precisa ter mais tempo de existência. Prefira escolher distros que já tem alguns anos de estrada.

Dentre as dezenas de distros que existem, eu acabo preferindo os mais maduros e com ecossistemas maiores, aqueles que todo tutorial que você abre tendem a ser os primeiros. Nessa categoria você tem principalmente os derivados de Debian. Ubuntu é um fork de Debian. Mint e Elementary são customizações em cima do Ubuntu, todos usam pacotes DEB com gerenciador APT. Você tem os derivados de RedHat como Fedora pra desktop ou CentOS pra servidor, e tem o Suse que é meio primo deles também, todos usam pacotes RPM com gerenciador YUM. Você tem os derivados de Arch como o Manjaro que usam Pacman. E tem os mais de nicho antigos como Slackware e Gentoo.

Uma característica que pode ou não ser um problema pra você no caso de Debian é que a intenção dele é ser sempre uma distro estável e confiável, e isso significa que ele demora bem mais pra oferecer versões mais novas de softwares mais novos. E faz sentido, tudo que é novo e ainda não foi testado o suficiente sempre deve ser considerado potencialmente bugado ou instável. Mas como desenvolvedores a gente muitas vezes precisa das coisas instáveis também, e por isso tem forks como um Ubuntu da vida, que oferece versão um pouco mais estável que são os LTS ou Long Term Support como o atual 18.04, que a Canonical deve fornecer suporte por uns 5 anos pelo menos, e versões mais bleeding edge, ou instáveis com coisas mais novas pra testar, que é a versão ímpar 19.04, que vai ter suporte bem menor. Mais ou menos o mesmo princípio você tem com CentOS sendo mais estável do que Fedora que tem pacotes mais recentes. Arch é sempre mais instável porque ele vai atualizando pra frente como se não houvesse amanhã. Não quer dizer que ele tem problemas, só que tem mais chances de ter, ele é uma bicicleta sem rodinhas, você tem que saber andar sozinho sem apoio.

Eu disse que Arch você vai sofrer se for iniciante, mas minha recomendação teve um pingo de compaixão. Arch pode parecer um pouco complicado no começo, mas ele é um sistema moderno, com gerenciador de pacotes e dependências bem competente, e com um dos melhores Wikis disponíveis em qualquer distro. Tem ampla documentação e suporte. Agora se você quiser ir pra um nível mais hardcore, precisa tentar Slackware. É a distro mais antiga ainda sendo mantida, desde 1993. Ele é um dos mais simples e mais parecido com o UNIX original e sua filosofia de KISS (keep it simple, stupid). Ele nem tem um gerenciador de dependências propriamente dito. Seus pacotes são meros tarballs, tipo zip se você não sabe o que é um tarball.

Em algum momento acho interessante tentar Slackware, mesmo hoje em dia. O Slack foi minha primeira distro em 1995. Não vou dizer que tenho boas memórias dele. Mas se quiser ir ainda mais um nível hardcore, você precisa experimentar o Gentoo cuja filosofia é baixar só código fonte e compilar tudo, literalmente tudo, na sua própria máquina. O sistema Portage dele é meio inspirado no Ports do BSD. Essa é uma distro pra você que tem muita curiosidade, muito tempo e principalmente muita paciência.

A maioria das distros mais novas por alguma razão acabam derivando de Ubuntu, caso do Pop OS. Um dos mais promissores na linha de Mint ou Elementary hoje seria o Deepin, que eu acho que é um dos mais bonitos e mais próximos da usabilidade de um MacOS sem tentar ser um clone exato. E de bônus, pra quem gosta de Arch e Manjaro, também tem a versão Manjaro Deepin que você pode usar em vez do Manjaro GNOME. Aliás, tem isso também, muitas distros já trazem versões pré-configuradas com diferentes desktop managers, como GNOME, KDE, Cinnamon, XFCE, o do Deepin que usa kwin, que é derivado do KDE Plasma, e outros mais exóticos com o i3 que muitos adeptos de teclado estão adotando.

Isso tudo dito, em PCs mais fracos não tem o que pensar, eu definitivamente recomendo instalar um Linux pra tirar o máximo da máquina. Em PC mid-range ou topos de linha eu acabo ficando no Windows puramente pelo suporte. Veja bem, minha situação é diferente da maioria das pessoas: meu dia a dia hoje não é mais ser programador tempo integral. Independente dos meus motivos pessoais, a recomendação ainda é tentar se manter no Linux como máquina primária. No meu caso, na maior parte do tempo eu vou acabar ficando em web apps, gmail, twitter, reddit, calendar, dashboards de AWS ou Google Cloud, e é tudo web. Coisas que tem clientes nativos como Dropbox, Zoom, Skype, tudo funciona bem em todos os sistemas operacionais. Apesar de eu não me incomodar com Google Docs ou Google Spreadsheet, eu ainda não gosto do Slides e mesmo a versão online do PowerPoint eu não me vejo usando. Ainda prefiro as versões nativas de apps do Office. De novo, é um gosto pessoal.

E mesmo o PowerPoint, tem várias coisas que ele faz até melhor que todo mundo mas em termos de usabilidade e produtividade ainda não supera o lendário Keynote da Apple. Mas tudo bem, em termos de pacotes de produção de conteúdo, eu gosto de ter acesso ao Adobe Creative Cloud, que só tem pra Windows e Mac. Mesmo em Mac eu ainda não trocaria Photoshop por qualquer outro produto. De novo, tudo gosto pessoal aqui. Entenda que metade da minha preferência pessoal é o fato de eu ter anos de experiência em ferramentas Adobe ou Apple. Se você nunca usou essas ferramentas, não vai sentir falta, então se começar com LibreOffice Impress, Google Slides, Da Vinci Resolve, Gimp, Inkspace, vai se acostumar. Em trabalhos criativos a ferramenta tem menos importância do que o treino artístico do profissional.

Se você não precisa de pacotes Microsoft, ou Adobe, ou não tem necessidade de desenvolver pra iOS, qualquer PC com qualquer boa distro Linux deve mesmo ser a primeira escolha. Você não está perdendo nada. Como muitos me lembraram depois, o Steam tem a opção do Proton e com isso a maioria dos games roda bem hoje em dia em Linux também. Dota 2, CS Go, Rocket League, Skyrim, Fallout, vai rodar. Se você joga Pubg vai ter problemas. Por baixo dos panos ele usar Wine e DXVK mas você não precisa ficar configurando manualmente jogo por jogo, por isso tá bem mais viável com o suporte da Valve hoje em dia.

Ou seja, numa máquina boa, o Windows funciona bem o suficiente pra eu esquecer que estou usando ele. E se você precisa de produtividade, realmente não quer ficar deixando sua máquina principal com risco de ficar instável, e nesse sentido não há nenhum grande problema em ficar no Windows. Mas na realidade, enquanto estou escrevendo este script eu estou muito tentado a voltar pro Linux como sistema primário. Entrei no Arch Wiki e vi que meu Lenovo Thinkpad X1 Extreme funciona perfeitamente com exceção do leitor de impressão digital, que não faço tanta questão de usar. Então eu acho que depois de editar este video vou instalar o bom e velho Manjaro, talvez o Deepin. Acompanhem minhas redes sociais pra ver como vai ficar.

Agora vamos pra parte 2, sobre Mac, o que eu realmente gosto é a consistência. Em Linux você tem diferentes desktop managers como GNOME, KDE, e por aí vai. Com diferentes toolkits gráficos como GTK, Qt, Tcl/tk, e isso faz com que cada aplicativo fique com sensação de “fora do lugar” se rodar misturado. Pegue um Kdenlive, que é feito com o toolkit Qt pra KDE, ele fica fora do lugar rodando num GNOME. Ou um Gimp rodando num KDE. A interface gráfica de Linux é uma zona. Aliás, parece que estou falando mal, mas calma, a nova interface do Gimp, por exemplo, ficou sensacional se comparado como era antes, e inclusive recomendo que dêem uma olhada. Isoladamente, cada aplicativo é muito bom, especialmente com os refinamentos de hoje em dia, mas como um conjunto eles são muito inconsistentes em usabilidade.

No mundo Windows é um pouco parecido porque a Microsoft não se compromete numa única linguagem de design. Desde o Windows Vista eles vem tentando modernizar a interface, mas aí mesmo entre os aplicativos da própria Microsoft você tem aberrações como o aplicativo principal de Settings pra maioria das configurações da máquina, mas ainda tem o antigo Control Panel pras coisas que ele ainda não modernizou. Coisas simples como botões, tem o estilo pseudo-3D em apps velhas, tem botão cinza, tem botão translúcido. Cada hora é de um jeito. Coisas bestas como o console ou o Notepad, só começaram a ser modernizados agora. Olha como o Notepad contrasta ao lado da Calculadora. Eu abro muitas coisas e parece que voltei pro Windows XP. Especialmente se pegar programas mais antigos de terceiros que não se atualizaram.

A Apple iniciou a idéia de um Human Interface Guideline ou HIG décadas atrás, literalmente um guia de usabilidade e design visual de todos os elementos do sistema operacional. A forma com que eles conseguiram manter esse HIG consistente e sempre se atualizando é que os aplicativos que a própria Apple desenvolve usam o HIG e os aplicativos feitos pela própria Apple tendem a ser muito bem feitos, e todos os usuários querem os mesmos elementos em todos os outros aplicativos. Eles são tão bem feitos, que até usuários de fora do Mac gostariam que seus apps em Linux e Windows ficassem parecidos. Olha esse dialog box pra escolhe arquivos do MacOS e veja o do Deepin que falei antes, ou o Finder no Mac e o file manager do Deepin. Está bem claro que o Deepin gosta da estética do MacOS também. Então sempre existiu tentativas assim de se criar temas e skins pra Linux e Windows ficarem mais parecidos com Macs. Quando você viu um usuário de Mac tentando tematizar o Mac pra ficar com cara de Linux ou Windows?

No Mac é tudo mais consistente. Manter consistente foi um risco que se pagou. Eles determinaram e cumpriram linhas de corte drásticos que na época deixou muita gente descontente, mas hoje o resultado se paga. Quando Steve Jobs voltou pra Apple ele trouxe o lendário NEXTStep que é o desktop manager e os frameworks de desenvolvimento de aplicações feitos em Objective-C. Quando eles evoluíram o NEXTStep pra virar o OS X eles fizeram uma camada de compatibilidade binária com o Mac classic. Então se você executasse um binário de Mac antigo ele conseguia rodar. Facilitou que o OS X rodava no mesmo processador dos Macs antigos, o IBM Power PC e foi assim de 2000 até 2006.

O NextStep foi a parte da Next que sobreviveu. Muitos talvez reconheçam a Next por causa da workstation Cube onde Tim Berners Lee desenvolveu o primeiro protótipo de um navegador web e o protocolo HTTP. Ou onde John Carmack desenvolveu o lendário Doom. As capacidades de desenvolvimento num Next eram reconhecidas como de fato as melhores da época. Se você abrir um Interface Builder do Xcode de hoje, é algo muito parecido com que eles usavam no fim dos anos 80 num Next.

Enquanto a linha de hardware morreu, o NextStep foi padronizado como OpenStep junto com a Sun. No mundo Linux surgiu o desktop manager chamado WindowMaker que tinha o look and feel do NextStep mas na verdade foi feito em C. E teve o GNU Step que era uma tentativa de implementação dos frameworks em Objective-C. A idéia é que um dia um app de NextStep podia ser compilado em GNU Step e rodar em Linux. Recentemente descobri um projeto que está incompleto e eu não testei ainda mas que se chama NextSpace e é uma tentativa mais moderna de ter um ambiente NextStep em Linux. Ele tem a cara do antigo WindowMaker mas implementando da forma certa os frameworks todos em Objective-C. Se ele for bem sucedido, seria até possível pegar códigos fonte de aplicativos simples feitos pra Mac e recompilar em Linux usando esse framework. Ele está fazendo o caminho certo: em vez de tentar reimplementar os frameworks e o visual de um Mac moderno, ele está fazendo o mesmo caminho que a Next fez pra dentro da Apple em 1998.

Voltando pra história, quando anunciaram o beta do novo sistema operacional, codenome Rhapsody, a idéia era um NextStep onde você podia rodar só aplicativos novos feitos em Objective-C e os apps antigos do Mac classic rodariam num Yellow Box que era basicamente uma camada de emulação. Claro, os desenvolvedores ficaram muito bravos. Eles queriam que os aplicativos deles funcionassem nativamente no novo sistema operacional, mas ninguém estava muito a fim de reescrever tudo que se tinha antes em Object Pascal ou C pra Objective-C. Por isso a Apple resolveu desenvolver um framework intermediário, mais compatível com a API do Mac classic. Esse conjunto de APIs intermediários foi chamado de Carbon. Você precisava modificar algumas partes do seu código antigo e recompilar usando o framework novo que dava acesso aos recursos modernos do OS X, como permitir multi tarefa preemptiva e modo de memória protegido. Era o processo de carbonização.

Daí em 2006 eles fizeram um dos movimentos mais interessantes que eu vi no mundo de tecnologia até então: mudar os Macs dos processadores Power PC pra Intel. Eu lembro quando assisti o Keynote e fiquei muito impressionado com a estratégia. Mais ainda porque desde 2001 nós ouvíamos mesmo rumores de que o OS X, por ter a estrutura UNIX e tudo mais, não deveria ser tão difícil de recompilar em Intel. E Jobs anunciou exatamente assim, foi sensacional. Na prática, a IBM provavelmente estava mais interessada nos processadores que estava vendendo simultaneamente pra Sony nos PS2, pra Microsoft nos Xbox originais e pra Nintendo nos GameCubes. A promessa que eles fizeram de um processador G5 de 3Ghz passou 2 anos e eles não entregaram pra Apple, e isso obviamente fez Steve Jobs ficar com cara de bobo por ter prometido isso 2 anos atrás. E um Jobs bravo não é exatamente fácil de negociar.

Frigir dos ovos, fora IBM, olá Intel. Alguém na IBM deve ter pensado pfff foda-se, duvido que eles nos abandonem, vão fazer o que, ter a dor de cabeça de migrar tudo pra Intel? É exatamente o que um Jobs bravo faria, e fez. Pra isso funcionar eles fizeram uma estratégia em etapas. Binários antigos de Power PC rodariam sobre uma camada de emulação chamada Rosetta, de uma pequena empresa que a Apple comprou. Essa camada traduzia as instruções RISC de PowerPC em instruções x86 em tempo real. Óbvio que era mais lento, mas era muito impressionante.

Toda aplicação mais nova, já desenvolvida no framework derivado do NextStep, que a essa altura tinha sido renomeado de Cocoa, só precisava assinalar um checkbox na IDE XCode. Fizeram uma apresentação de como pediram o código fonte do lendário Mathematica que rodava em Power PC e com algumas horas de tweaks no código e assinalando o tal checkbox, já se tinha um binário pronto pra rodar nativo em Intel. Aliás, esse keynote inteiro é de longe uma das melhores apresentações de transição de roadmap de produto que eu já vi, é uma aula que eu recomendo que vocês assistam. Vou deixar linkado o keynote nas descrições abaixo.

Até esse ponto muita gente preferia desenvolver no antigo CodeWarrior da MetroWerks, que era o que se usava pra escrever código pra Mac classic. Pra migrar pra Intel era preciso compilar via o novo XCode 2 e foi assim que o CodeWarrior morreu e todo mundo passou a adotar XCode. Ironicamente o CodeWarrior ganhou notoriedade quando a Apple migrou dos processadores Motorola 68000 pra PowerPC, e agora perdeu o bonde na segunda transição.

Todo aplicativo antigo que já tinha sido carbonizado também era praticamente só recompilar. Ao recompilar eles trouxeram outra tecnologia do NextStep: os Fat Binaries que foram renomeados como Universal Binaries. Um dos recursos mais interessantes pra mim no OS X e NextStep era o conceito de bundles. Tecnicamente em vez de você dar duplo clique em cima de um binário executável, você manda executar um bundle, que é simplesmente uma pasta especial com um arquivo de manifesto e algumas convenções de subpastas e nomes. Daí o OS X procura dentro dessa pasta o binário pra Power PC ou pra Intel dependendo de onde está rodando e executa o certo. Daí quando precisou migrar de 32-bits pra 64-bits foi a mesma coisa: recompilar e gerar os binários e fica tudo no mesmo bundle. Esse conceito de universal binary foi outra coisa inteligente na época que me deixou impressionado, porque eu estava vendo no Windows começar a aparecer coisas como o diretório Program Files (x86) ao lado do diretório Program Files, que é um troço que ainda existe no Windows até hoje. Isso sem contar o buraco negro radioativo que são os diretórios System32 e WOW64.

A Apple só conseguiu fazer isso porque a quantidade de pessoas usando Macs era muito pequena, só alguns poucos milhões. Então não tinha tanto problema se uma porcentagem pequena dos usuários ficasse alienada sem conseguir atualizar por conta de aplicativos legados que não iriam mais rodar. O ideal era todo novo aplicativo ser feito já usando os frameworks do Cocoa, em Objective-C, com XCode. E pra facilitar mais ainda, 2 anos depois desse anúncio eles lançam o iPhone, e nem 2 anos depois o Xcode passa a suportar compilar pra processadores ARM, usando frameworks derivados de Cocoa, em Objective-C, então mesmo se a maioria das pessoas não fosse adotar XCode e Objective-C, a urgência de querer desenvolver pra iPhone automaticamente criou essa necessidade e foi assim que Objective-C passou de uma linguagem obscura que quase ninguém usava além de desenvolvedor de Mac pra uma das linguagens mais reconhecidas nos anos 2010. E aqui eles demonstraram novamente, que não importa se você acha que uma linguagem é bonita ou feia, o que trás adoção pra linguagem é um killer app, no caso o iPhone e sua App Store. Sem um killer app, uma boa linguagem está morta.

Nesse sentido, acabou dando tudo certo pra Apple. Eles tiveram a possibilidade de começar praticamente do zero com o OS X, migrar os principais aplicativos aos poucos via carbonização ou reescrever direto em Cocoa. Ajudou que a fundação era baseada em UNIX então havia muito código aberto que podia ser reusado no processo, vindo tanto dos ecossistemas de BSD e de Linux. Vocês podem ver que esse processo de nascimento e evolução do OS X foi extremamente fascinante de se ver, e com os novos hardwares, qualquer programador antenado queria muito entrar nesse ecossistema o quanto antes, e por isso eu migrei pra Mac em 2004 e me senti ainda mais justificado com tudo isso que aconteceu.

Quando a adoção de iPhone aumentou a adoção de Macs, ao mesmo tempo comunidades web como Ruby on Rails já haviam entrado nesse vagão. O fato de Ruby vir pré-instalado em Macs ajudou muito. O fato de muitos aplicativos de Linux serem compatíveis no nível do código fonte também ajudou. Daí nasceram muitas ferramentas que são usadas até hoje e são parte fundamental do desenvolvimento tanto Web como Mobile. No começo era muito chato usar ferramentas open source no OS X porque a gente precisava baixar os fontes e compilar tudo na mão e torcer pra compilar. Aos poucos surgiram ferramentas automatizadas como o antigo Fink que tentava imitar o apt-get do Debian pra ser um repositório pra baixar pacotes em formato DEB, mas teve muito pouca adoção e suporte e morreu. Outra tentativa foi o MacPorts que tentava simular o Ports do BSD pra baixar pacotes de código fonte e compilar toda vez que baixava. Esse até durou alguns anos mas morreu também.

O que sobreviveu e existe até hoje é o Homebrew que é o gerenciador de pacotes que todo desenvolvedor de Mac usa e é feito em Ruby. No mundo mobile mesma coisa, a gente precisava organizar dependências ou manualmente usando coisas como submódulos de git, ou baixando as bibliotecas manualmente e jogando em pastas no projeto. Mas então surgiu o CocoaPods pra gerenciar dependência de projetos pra iOS, e ele também foi feito em Ruby. Outro dia vou falar mais de Ruby, mas os rubistas foram os que começaram a ajeitar o Mac pra ficar boa pra ser usada por qualquer desenvolvedor. O pacote Oh-my-ZSH pra trocar Bash por ZSH, de novo, foi feita por outro rubista.

Eu falei no começo que no mundo Linux e Windows a linguagem visual dos aplicativos é toda misturada. No mundo Mac, essas transições meio que forçaram o desenvolvimento de novos aplicativos usando os frameworks mais modernos e os guias HIG da Apple. E com a adoção de parte do mundo open source, e o desenvolvimento acelerado de apps iOS, a gente tinha um app bom atrás do outro surgindo. Editores de texto como o TextMate 2 que nós da comunidade Ruby começamos a usar dita a linguagem de todo novo editor de texto até hoje. A idéia de um editor rápido e simples que pode ser extendido via plugins, com recursos pra fazer pesquisa fuzzy em nome de arquivos, diversos shortcuts e macros pra expandir templates de código.

Se você usa Sublime Text, ou Atom ou Visual Studio Code e abrir o TextMate 2 com os diversos plugins instalados, vai ver como a gente tinha exatamente a mesma coisa que se tem hoje só que em 2004. Nenhum outro sistema operacional tinha um TextMate. E foi assim que surgiu a nova geração de plugins de Vim e Emacs que elevaram esses editores ao que eles são hoje também. O renascimento de vim como editor mais moderno veio muito dos plugins feitos pra Rails por outro rubista, o Tim Pope. Pela primeira vez as tendências principais de desenvolvimento de software estavam iniciando primeiro nos Macs e sendo levados pra Linux e Windows depois. Só considere que quase toda ferramenta que você usa hoje, de GitHub a Heroku, foi feito por desenvolvedores usando Macs.

A estética da Apple influenciou a web moderna, começando com o visual do Aqua original com seus elementos parecendo plástico translúcido, como os iMacs antigos, e depois se tornando mais metalizado como os PowerMac Titanium, e finalmente se tornando mais minimalista seguindo a identidade de aplicativos de iPhone. Hoje eu diria que o design e estrutura de apps e sites meio que convergiu e está mais estável, mas não havia lugar melhor pra estar entre 2006 a 2010 se você fosse desenvolvedor de software. E se você assistiu meu video da Apple e GPL que vou deixar linkado aqui em cima, também sabe que nesse período foi quando eles contrataram o Chris Lattner que evoluiu o LLVM até o clang substituir o GCC e desenhou a nova linguagem Swift. Desenvolvimento de software no mundo Apple era realmente empolgante com tudo isso.

Você tinha um pacote muito atraente: na época os Macs tinham preços até que competitivos mesmo se comparado aos PCs. Com a vantagem que os PCs eram objetivamente piores. O design industrial era desastroso pra dizer o mínimo. As configurações padrão eram fracas. Iniciativas como netbooks foram um fracasso. O Windows Vista da época não estava exatamente atraindo novos usuários. Pensa que o Windows 7 só veio a sair em 2009, ano que todo mundo queria Mac pra desenvolver apps pra iPhone. E pensa que só um ano antes tinha acabado de sair o Macbook Air que obliterou a imagem que a gente tinha de notebooks e iniciou a categoria de ultrabooks.

Sério, os PCs de antes de 2011 eram ruinzinhos, e muito feios. Os da Apple por outro lado, era um modelo melhor que o outro saindo frequentemente. Dava vergonha abrir um notebook PC do lado de um Macbook. Mas foi a partir de 2012 que as coisas começaram a virar. Steve Jobs estava mais ou menos certo: as tecnologias da Apple estavam uma média de 5 anos à frente do mercado. Incluindo I/O mais veloz com coisas como Lightning e Thunderbolt, o conceito de unibody enclosure, tecnologia de baterias, as telas Retina num mundo que ainda vendia monitores 720p todas descalibradas, o melhor trackpad até hoje ainda, e os melhores teclados em notebooks.

Mas, Steve Jobs morreu em 2011, e com ele foi enterrado também a visão e estratégia da Apple. O Mac Pro trashcan em 2013 iniciou um período de idade média dos hardwares Pro da Apple. A bolha de apps pra iPhone já estava estabilizando por 2014, então isso não ia mais acelerar venda de novos Macs. E pra piorar a partir de 2015 eles começaram a errar a mão nos Macbooks. Os teclados com switches butterfly são a pior construção que eu já vi, além de na prática serem rasos e desagradáveis pra longos períodos de digitação. O touchbar removendo teclas que são úteis pra desenvolvedores não ajudou em nada. Manter o mesmo unibody enclosure e ir entuxando CPUs que esquentam mais e mais como os Core i7 e os Core i9 causando thermal throttling não ajudou também. Eles esqueceram como em 2005 eles decidiram até mudar de CPU porque os G5 esquentavam demais pros produtos que a Apple queria fazer.

A Apple foi aumentando os preços e entregando menos. E nesse vácuo todos os outros fabricantes foram ficando melhores, em todos os segmentos, tanto em smartphones, como notebooks, como desktops. A Dell veio lançando um XPS melhor que outro faz uns 4 ou 5 anos já. A Lenovo veio lançando Thinkpads cada vez melhores e retornando à antiga glória. Mesma coisa com HP, Acer e outras marcas tradicionais. As marcas chinesas começaram a aparecer mais e mais com Xioami, Huawei e novas marcas começaram a pegar nichos mais premium com os notebooks da Razer. Chegou a hora de explorar a 3a parte deste episódio e pisar no mundo PC um pouco.

O mundo gamer explodiu por conta das iniciativas do governo da Coréia do Sul desde o ano 2000. Os torneios de eSports foram crescendo de meros 10 torneios no início do século pra 260 em 2010 a quase 700 em 2012. O Twitch foi lançado em 2011 e em 2015 já tinha mais de 4.5 milhões de visualizações únicas. Foi quando começou a sair as principais franquias de hoje como LOL, Dota 2, CS:Go, cada um atraindo milhões de novas pessoas a eSports. A Nvidia estava com placas ficando cada vez melhores como a GeForce 600 na arquitetura Kepler. A AMD que a Apple adotou como padrão entrou num vácuo até recentemente. A Apple perdeu o bonde do mundo gamer.

Se você não for gamer pode não parecer, mas a profissionalização de eSports ajudou em muito a evoluir mais rápido todos os componentes de PC. Antigamente era de fato fácil montar um PC equivalente mais barato que um Mac, mas eu sempre tive a sensação de que o resultado final não chegava perto. Por exemplo, não era comum montar PCs com porta Firewire 800. Mas hoje é comum PCs com Thunderbolt 3. Hoje eu diria que existem configurações de hardware superiores e não parece mais que eu estou perdendo alguma coisa. Pelo contrário, agora parece que ficando no Mac eu estou perdendo muita coisa boa no mundo PC.

Pra facilitar, o Windows 10 apareceu pra limpar a zona que foi do Vista até o 8. Conseguiram consertar o start menu, tiraram a porcaria da barra de Charms, otimizaram o suficiente pra não ficar pesado em máquinas mais fracas. E pra completar a partir de 2012 a própria Microsoft começou a entrar no nicho de tablets e ultrabooks com a linha Surface. E aqui eles acertaram bastante. E de fato, fazer o próprio hardware definitivamente ajuda a Microsoft tanto a ter uma linha de referência pros parceiros quanto a otimizar melhor o sistema pra um hardware de verdade em vez de depender só do feedback dos OEMs.

Uma nova geração de desenvolvedores começou a entrar na Microsoft. Foi recente que eles pularam de um headcount de aproximadamente 2 mil desenvolvedores pra 20 mil. Isso trouxe um exército de jovens programadores que cresceram sem o viés de achar que tudo que não é Windows é inimigo. Ajudou muito que eles resolveram se aventurar no mercado de infraestrutura como serviço pra competir com a AWS e fizeram o Azure. O Azure expôs todas as fraquezas do Windows como servidor. E eles se viram na necessidade de aprender com o que o Linux já tinha conquistado até então. Tecnologias como Hyper-V evoluíram muito desde então, o suficiente pra se tornar úteis no mundo desktop também.

A migração de 32-bits pra 64-bits ajudou a Microsoft porque muitos novos dispositivos de segurança se tornaram possíveis com essa mudança, como ASLR ou Address Space Layout Randomization. Explicando de forma simples, eu ensinei no meu episódio sobre gerenciamento de memória sobre endereçamento. Se um hacker sabe em que endereço determinada função com bug de segurança é sempre carregado, fica fácil de atacar. Em 32-bits eu posso mudar de lugar, mas você lembra como tem poucos endereços no final pra aplicação. Então mesmo mudando de lugar, via força bruta, dá pra achar ainda. Em 64-bits a dificuldade aumentou exponencialmente. Esse é um dos recursos habilitados em Windows de 64-bits dentre outras e isso ajudou a diminuir muito a superfície de ataque dos hackers. Apesar de ainda existir centenas de vetores de ataque você pode ver como não é mais tão frequente ouvir falar de Windows 10 em 64-bits sendo atacado de forma tão vergonhosa como foi Windows XP.

E com Hyper-V se tornando componente padrão pra segurança criando coisas como secure enclosures em hypervisor, por exemplo, no novo Windows Defender. Não é difícil ver que as coisas realmente mudaram dentro da Microsoft. Hoje em dia eu tenho um Malwarebytes instalado mas me dá a impressão que só o Windows Defender é suficiente pra maioria dos casos. E pros casos mais exóticos eu ainda tenho a opção de abrir o Windows Sandbox, que é um Windows virtualizado em Hyper-V pra rodar coisas inseguras. Ele sobe um Windows vazio, eu posso instalar até um virus ali, e ele não tem acesso à máquina hospedeira. E quando eu fecho o sandbox, tudo dentro dele morre.

Esse tipo de uso de tecnologia me empolga bastante e, claro, eu posso fazer tudo isso num Mac ou Linux também. Mas de novo, eu gosto de coisas que vêm por padrão, oferecendo consistência. E falando nisso, uma coisa que o Windows nunca pôde fazer, foi começar do zero. Ele ainda é obrigado a trazer diversos binários antigos pra manter compatibilidade com programas velhos. Em seu mérito, é possível pegar um programa binário que rodava até em Windows 98, e provavelmente vai executar no Windows 10. Nenhum outro sistema operacional tem esse nível de retrocompatibilidade binária.

Porém isso também significa que existem muitos vetores inseguros pré-instalados. Muitos aplicativos que obviamente tem cara de que foram feitos nos anos 90. Claro que eu preferia que eles parassem de suportar e forçassem todo mundo a escrever em frameworks mais novos. Mas do tamanho que Windows já era no ano 2000 e o tamanho que é hoje, não seria realista. Ironicamente antigamente todo mundo só fazia apps pra Windows, mas hoje a Microsoft tem mais dificuldade em convencer desenvolvedores a fazer novos apps pra Windows. O Windows Store parece um deserto se comparado à Apple App Store. Mas dentro dessas restrições, eu diria que o Windows 10 está andando numa velocidade até razoável.

No caso do Mac, logo quando o OS X surgiu, eles fizeram três coisas muito importantes. Primeiro foi manter as parcerias originais. Trazer a Microsoft pra dentro pra eles fazerem uma versão do Office e do então Internet Explorer 5 foi muito importante. Com a demora da entrada da Adobe, a própria Apple se viu obrigada a cobrir o buraco. Primeiro com produtos da linha profissional como Final Cut e Logic Pro. Mas depois com o conceito de hub multimídia e os produtos da suíte iLife como iPhoto, iMovie e iDVD. Esses produtos ainda são bons hoje nas novas versões, mas naquela época eles eram imbatíveis. Sem exageros, muita gente comprava iMacs pra ter o iLife.

Muitos dos primeiros YouTubers aprenderam a lidar com multimídia via iMovie. No Windows tínhamos uma zona chamada Windows Movie Maker, um Windows Player que não decidia o que queria ser, se um jukebox ou um tocador. As tecnologias multimídia dos Mac sempre foram superiores. Nessa época os desktop managers do Linux também estavam babando pra interface Aqua dos novos OS X.

E isso foi outro fator que me interessava. Trazer o NextStep pra dentro da Apple como OS X trouxe outras tecnologias que ninguém mais tinha. Na década de 80 ex-funcionários da Apple fundaram a Adobe e inventaram o Postscript. Pense em Postscript como um HTML, com a intenção de possibilitar o famoso WYSIWYG ou What you see is what you get, ou seja, o que está aparecendo na tela ser igual o que vai aparecer quando mandar pra impressora. Isso foi revolucionário porque criou o mercado de desktop publishing.

Essa tecnologia evoluiria pra Display Postscript e depois Display PDF que virou o Quartz no OS X. O desktop manager do novo OS X, em vez de seguir a zona que é o X no mundo UNIX, foi criado do zero pra ser um monolítico que desenha todas as janelas de todos os programas como elementos de composição num PDF. Tudo que poderia ser acelerado via OpenGL em placa gráfica, que era novidade na época. Isso possibilita adicionar elementos de pós-produção, como transparências, sombras e animações fluidas. Em 2000 isso funcionava bem no iMacs, apesar de um pouco lento. Mas os processadores G3 da época conseguiam suportar.

Isso se pagaria poucos anos depois, quando processar esse tipo de coisa passou a ser barato pras novas placas gráficas. Eles tomaram a decisão de ser um pouco mais lentos no começo mas sabendo que em 1 ou 2 gerações estaria na velocidade correta, tanto por otimizações de software quanto pela própria evolução do hardware. Em 2000 qualquer um diria “isso é desnecessário”. Eu acho que o fato deles estarem no fundo do poço e desesperadamente precisando se recuperar fez a Apple de 1998 tomar muitos riscos que nenhuma empresa tomaria hoje em dia.

Se você não sabe o que é compositing. Pense num sistema primitivo. Você tem janelas de vários programas. Eles vão sendo desenhados por cada programa numa certa área de um buffer, tipo uma matrix, que chamamos de frame buffer. Em 1/60 avos de tempo o sistema operacional pega o que está nesse buffer e manda pro monitor mostrar. Se eu mexo uma janela na frente da outra, as duas precisam redesenhar tudo. E pra ficar fazendo sombra de uma janela na frente da outra, 60 vezes por segundo, custa muito tempo. Em vez disso pense agora organizar uma nova abstração, tipo um canvas virtual, onde cada janela fica em layers e a janela de cima não sobrescreve a imagem da janela de baixo. E como num photoshop podemos ir aplicando efeitos como sombra num layer de cima e dinamicamente ele vai aplicar a sombra nos layers de baixo. Mas tudo isso feito via OpenGL na época, falando com a GPU, que foi feito pra aplicar efeitos em quadros muito rápido, o suficiente pra renderizar 60 quadros por segundo, e sem precisar que a CPU se meta. Com isso ganhamos animação fluida usando a GPU em vez da CPU.

Fazer um desktop manager com compositing não é trivial, especialmente se você já tem um jeito legado de fazer e agora ter que mudar. A Apple teve a visão de implementar isso em 2000. Foi mais uma daquelas coisas que você não sabia que precisava até ter visto. Só que depois de ver as animações fluidas, sem engasgos, sem fritar sua CPU, você olhava pro seu Linux e Windows que ainda desenhavam do frame buffer direto pra tela via CPU, e não tinha como ter aqueles efeitos e animações sem fritar sua CPU que ia precisar processar 30 quadros por segundo pelo menos.

Eles precisavam delegar isso pra GPU como a Apple estava fazendo. Mas levou até 2005 pra surgir o Compiz e Kwin no Linux, depois de muita experimentação, e mesmo assim ainda não 100%. E levou até 2007 pra lançar o Windows Vista com o mesmo sistema de compositing, que só ficaria completo e passou a ser obrigatório no Windows 8. Ou seja, na prática, nessa primeira década, só num Mac você tinha visuais agradáveis e lisos. Hoje em dia felizmente tanto os novos Linux quanto Windows 10 já usam sistemas de compositing e até High DPI que é pra monitores com alta densidade de pixels escalar os elementos da tela da forma correta, coisa que a Apple até hoje ainda é a única que faz 100% direito.

O que a Apple fez entre 2000 e 2009 nenhuma outra conseguiu fazer. Eles conseguiram rebootar o ecossistema inteiro, começar do zero com uma plataforma realmente à frente do seu tempo, criando um novo ecossistema consistente de ponta a ponta, incluindo ao lançar novos produtos como o iPhone que manteve a programação muito consistente mesmo que os binários fossem executar em arquiteturas tão diferentes quanto ARM e x86.

Eles evoluíram o LLVM ao ponto de conseguir se desvincular do GCC como compilador, coisa que em Linux ainda não está 100%. E com isso mudar de linguagens de Objective-C pra Swift, sem perder compatibilidade binária. Como eles conseguiram manter uma API unificada com os frameworks Cocoa, fica muito mais fácil de manter as coisas. Do lado da Microsoft eles foram fazendo tentativa em cima de tentativa e cada tentativa errada foi gerando mais dependências que hoje estão todas acumuladas no Windows 10 ainda. A Apple foi cortando fora as coisas velhas. Por exemplo, o suporte a 32-bits no MacOS já acabou em 2017. No Windows isso ainda vai durar alguns bons anos porque tem milhões de pessoas ainda presas em máquinas velhas só de 32-bits.

Então dos anos 2000 até 2005 a Apple estava se recuperando, reconstruindo as fundações quase do zero. OS X novo, novos iMac e a sorte grande de terem conseguido fazer o iPod dar certo. De 2005 a 2007 eles tiveram o trabalho de migrar tudo de PowerPC pra Intel. E de 2009 a 2012 foi a consolidação graças ao boom do iPhone. De 2013 em diante foi sentar nos louros e seguir a receita.

Dos anos 2000 até 2010 o mundo PC ficou correndo atrás sem saber muito pra onde ir. Todo mundo foi afetado com o crash da bolha da internet em 2001. Mas com a presença da Apple tão claramente demonstrando porque tudo que eles faziam estava errado, demorou uma geração inteira até finalmente eles começarem a copiar e finalmente ultrapassar a Apple de novo. Em 2019 as diferenças são mais do tipo: a caixinha de som do Macbook ainda é melhor. O SSD da Apple realmente ainda é um pouco mais rápido. E a integração do sistema operacional com o hardware ainda é muito bom. Tirando isso, qualquer combinação de hardware PC com Windows ou Linux está praticamente igual pra todos os efeitos práticos.

A grande virada pra desenvolvedores eu acho que vai ser o lançamento do Windows Subsystem for Linux versão 2 daqui alguns meses. Eu estou usando hoje em versão alfa. Em resumo é uma máquina virtual Hyper-V mais leve do que o normal porque ele não vai precisar pré-reservar CPU ou RAM e parece que consegue gerenciar recursos sob demanda. Então o custo inicial é razoavelmente barato e com start rápido, especialmente pra rodar tudo em linha de comando. Então se você sobe Docker pra Windows hoje, que também usa Hyper-V por baixo, vai ficar melhor.

Na prática o Windows 10 com WSL2 vai se tornar um sistema operacional com duas cabeças. Mas a cabeça Linux ainda vai rodar isolado. No MacOS a fundação inteira foi trocada pra UNIX e ele vem colhendo os benefícios disso até hoje. Isso não vai acontecer no Windows, eu diria talvez nunca. Então rodar oficialmente virtualizado é a segunda melhor coisa. Por outro lado, como o MacOS é um UNIX não compatível com Linux, não tem como baixar um binário de Linux e rodar direto no Mac. Isso vai ser possível no WSL que é literalmente um kernel de Linux rodando virtualizado, então em termos práticos, o mundo Windows vai ter acesso a muito mais do mundo Linux do que o Mac tem hoje.

Graças à Apple hoje temos PCs e notebook muito melhores. São mais leves, construídos com materiais muito mais elegantes e sofisticados do que só plástico e ferro. A Apple introduziu alumínio ao mundo e todo mundo vem experimentando com novos materiais como magnésio ou fibra de carbono. Os fabricantes aprenderam que a gente paga mais pra não ter que ter plástico. Os componentes hoje funcionam muito melhor integrados. Os firmwares das placas mães ficaram mais inteligentes, PCI-express facilitou a vida de todo mundo. SSDs e RAM ficaram muito mais baratos e acessíveis. E até a porcaria da placa gráfica integrada da Intel já serve pra maioria das coisas que precisamos hoje como assistir Netflix em 4K.

Se você está começando agora deve ficar mesmo confuso porque desenvolvedores mais experientes como eu passaram por esses períodos que eu falei. Muito do que se fala mal de Windows hoje é porque a gente sofreu com Windows XP. Muito do que se fala bem dos Macs é a fase de ouro até o lançamento dos iPads. A mesma coisa dos Linux, muito desenvolvedor que hoje usa Mac não consegue se ver tendo que sofrer pra instalar e customizar um Linux até ficar agradável pra usar, mas naquela época a gente não tinha Elementary ou Deepin. E pra mim, eu tenho gostos superficiais e pra mim visual faz diferença, e não ter a opção de desktop managers com compositing fazia muita diferença. No Windows a gente teve que esperar até sei lá, depois de 2009 pro Aero funcionar de verdade quando o Windows 7 ficou mais estável. E levou do Windows 8 até o 10 pra nova linguagem de interface Metro finalmente começar a ser mais adotada. Ou seja, eu realmente não recomendava e ainda não recomendaria usar Vista, 7 ou 8. O Windows 10 é o primeiro Windows que demonstrou interesse em cortar coisas fora e gastar tempo limpando a casa em vez de só ficar adicionando inutilidades como aquela horrível barra de Charms.

Eu disse que se você precisa desenvolver pra iOS, não tem o que escolher, você é obrigado a ter um Mac. Porém, não se preocupe em comprar os mais novos. Mesmo se você comprar um Macbook Pro usado de 2016 ainda vai funcionar razoavelmente bem. É muito difícil de justificar o custo de um Mac, especialmente com o dólar caro em relação ao Real. Mas a boa notícia é que hoje em dia comprar um bom PC não dá mais aquela sensação de estar escolhendo uma opção de segunda linha. Se você precisa desenvolver em .NET fique esperto, na prática, vai ser obrigado a usar Windows mesmo, mas dependendo do tipo de desenvolvimento, com o novo .NET Core você pode ter praticamente tudo que precisa num Linux e desenvolver com o Visual Studio Code. Caso você não saiba disso hoje é possível instalar SQL Server no Linux também e compilar e rodar programas .NET feitos em C# ou F# nativamente num Linux, é uma opção suportada depois que eles compraram a Xamarin. E com os frameworks da Xamarin ainda é possível fazer aplicações tanto pra iOS quanto pra Android, então existem várias opções ainda a serem exploradas no mundo Linux.

E por tudo isso, eu diria: se você tem dinheiro sobrando, na real tanto faz. Macbook Pro, Thinkpad X1 Extreme ou Carbon, Razer Blade, Asus Zephirus S, tem uma variedade muito boa. Se você for jogar ou criar conteúdo, escolha alguma com uma GTX topo da série 10 como as 1080 ou 1070 ou os mid-tier com 1660. Ou se quiser mesmo rasgar dinheiro, compra com as novas RTX série 20.

Se você não tem dinheiro sobrando, não se sinta mal em não estar comprando um Macbook. Procure os Dell Inspiron, Acer Switch, os HP Presario com Core i3 pelo menos. Antes pesquise no Google sobre a compatibilidade desses modelos com Linux. Escolha uma boa distro como um Ubuntu, Manjaro. E mesmo nessas máquinas dá pra ser criador de conteúdo, com um pouco mais de paciência, você consegue rodar Blender, Gimp, Kdenlive, Inkscape, Da Vince Resolve, Audacity e pra maioria dos casos você deve conseguir trabalhar normalmente.

Em 2016 meu objetivo de migrar pra Linux depois de mais de 10 anos usando Macs foi porque primeiro eu não tenho lealdade nenhum com a Apple. Não havia mais nada que me empolgava na Apple o suficiente pra ficar lá. E eu não ia ser aquele cara com Mac falando pras pessoas “usa lá Linux, dizem que funciona”. Eu só recomendo o que eu pessoalmente já usei como ferramenta primária por algum tempo, senão prefiro não recomendar. Eu não tenho lealdade com a Apple, também não tenho lealdade com a Microsoft e apesar de ter elogiado, ainda tá longe, mas bem longe do que eu gostaria que o Windows fosse. E também não sou ativista então nesse episódio longo veja que eu não disse nenhuma vez que você devia usar Linux por causa do aspecto de software livre. Estou sendo bem pragmático: do ponto de vista de produtividade, programação, gaming e criação de conteúdo, hoje em dia você tem PC antes de Mac e Windows e Linux antes de MacOS. Mas, mas, se você tem acesso a todas as opções, tanto faz na real.

E por hoje é isso aí, já fiz muito bikeshedding pra um episódio só. No final isso tudo foi um pouco uma desculpa pra eu contar alguns dos episódios da história da Apple que eu gosto, a migração do Mac Classic pro OS X, depois a migração de Power PC pra Intel. Acho uma pena que a Apple de hoje não se parece muito com a Apple daquela época, mas pelo lado bom, ainda bem que a Microsoft de hoje está muito melhor que a Microsoft daquela época. E como eu sempre digo: o mercado anda em ciclos. Espero que tenham gostado da história. Se ficaram com dúvida mande nos comentários abaixo, se curtiram mandem um joinha, assinem o canal, cliquem no sininho pra não perder os próximos episódios e continuem compartilhando com seus amigos pra ajudar o canal. A gente se vê semana que vem, até mais!

No episódio de hoje, pegando carona que eu fiz um vídeo sobre instalar ambiente de desenvolvimento em Ubuntu () eu queria aproveitar pra contar vários pequenos momentos e conceitos sobre sistemas operacionais que eu gosto de ficar discutindo.

No geral eu poderia dizer que é um vídeo “comparando” Linux, Mac e Windows mas a idéia não é escolher um no final mas sim delinear o que aconteceu nos últimos 20 e tantos anos que me fez ficar mudando de sistemas e hardware ao longo do tempo e porque existem algumas opiniões formadas hoje que quem está só começando não consegue entender porque as recomendações são extremas em muitos casos.

Antigamente a gente pedia “pelamor” pros desenvolvedores darem uma chance pros Macs. Hoje em dia o povo não entende porque tem tanta gente ainda recomendando Macs tão veementemente. E no fim, qual é a melhor escolha pra desenvolvedores de software? Vamos descobrir isso hoje.

Também continuo bastante intrigado com a ideia do Windows Subsystem for Linux (WSL), que estreou de verdade na Windows 10 Anniversary Edition em meados de 2016.

Já faz quase 2 anos e a expectativa é de atualizações expressivas em compatibilidade e performance do WSL para a próxima Spring Creators Update (versão 1803), prevista para 30 de abril de 2018. Isso aproxima o WSL de algo realmente utilizável por programadores profissionais. Só para ter uma ideia: hoje em dia você consegue desempenho ordens de magnitude superior rodando sua distro favorita dentro do Virtualbox ou do VMWare Workstation.

Além disso, o “Bash for Windows” de fábrica suporta oficialmente apenas Ubuntu, Fedora e OpenSuse, acho. A maioria das pessoas instala o Ubuntu mesmo. E funciona, ok. Para brincar e impressionar nas demonstrações, funciona. Mas me irrita profundamente conseguir fazer tanta coisa e não poder usar isso no meu dia a dia de verdade. É como carregar o protótipo finalizado do próximo iPhone sem suporte a 4G. Um brinquedo, só isso.

Mas se você quiser apenas ver como está a performance comparada ao meu setup com VMWare, pule direto para o final do artigo.

Voltando ao assunto das distros: usuários sérios de Linux preferem alternativas melhores. Eis o repositório no GitHub:

Você baixa esse arquivo zip, descompacta e executa o Arch.exe incluso. Só isso!

Aí é só abrir o “Bash” na versão Windows e bootstrapar o restante da instalação por lá.

Precisamos do Pacman e de algum gerenciador de AUR. Para iniciar o Pacman:

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

Que delícia, o Pacman rodando nativamente no Windows! Quem diria??

Isso vai atualizar tudo. Em seguida, criamos um usuário não-root:

useradd -m your_user
passwd your_user
EDITOR=nano visudo

Procure a linha que diz root ALL=(ALL) ALL e adicione o seu usuário logo abaixo:

your_user   ALL=(ALL) ALL

Por último, fazemos login como esse usuário:

su your_user

Agora vamos instalar o Yaourt para depois instalar o Pacaur (preferência pessoal minha — acho o Yaourt verboso demais com suas confirmações, por isso prefiro o Pacaur).

Comece editando o arquivo /etc/pacman.conf com seu editor favorito (vim ou nano).

Adicione a seguinte seção no final do arquivo:

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

Antes de prosseguir, temos um pequeno problema. O WSL ainda não tem suporte a SYSV IPC, que é necessário para o fakeroot, que por sua vez é exigido pelo makepkg (que não pode rodar como root).

Para contornar isso:

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

Por enquanto é isso! Até o WSL ter suporte nativo a SYSV IPC, usamos esse workaround. O próprio Yaourt provavelmente vai te pedir para instalar o fakeroot-tcp também — pode deixar.

Como disse, o Yaourt é bastante verboso nas confirmações. Regra geral: quando perguntar se quer editar algo, responda “N”. Quando perguntar se quer compilar ou instalar, responda “Y”. Se você quiser se livrar de mim nessa parte, faça logo:

yaourt -S pacaur

A partir de agora assumo que você tem o Pacaur instalado.

Suporte a Interface Gráfica

Vamos instalar o básico para um ambiente de desenvolvimento:

sudo pacman -S base base-devel gvim git

Quando aparecer “default: all”, instale tudo. Espaço em disco não deveria ser preocupação em 2018.

Prefiro ter um ambiente GNOME 3 completo, então:

sudo pacman -S gnome

De novo, deixe instalar tudo que quiser. Cada um tem seu gosto em termos de GUI — uns preferem KDE5, outros XFCE4. Tem quem vá ainda mais longe e use o gerenciador de janelas tileado i3.

Isso exige uma adaptação séria. É para quem curte usar teclado tenkeyless sem legenda nas teclas e layouts alienígenas como DVORAK ou Colemak (argh!). Gosto é gosto. E que tal se tornar digitador fluente no Maltron? Eu te desafio, e muito! :-D

Mas estou divagando. Adicione isso ao seu /etc/.bashrc ou ao /etc/environment global:

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

Exporte as variáveis no shell atual ou feche e reabra o Bash.

Para ter um ambiente gráfico completo, instale um servidor X local. São duas opções: Xming ou VcXSrv. Tenho tido problemas para redimensionar janelas no Xming, então recomendo o VcXSrv. Baixe e instale como qualquer aplicativo Windows, depois inicie. Ele vai criar um atalho no Desktop chamado “XLaunch” — é só abrir.

E finalmente, instalamos um terminal DE VERDADE no lugar daquela tralha derivada do cmd.exe antigo que o WSL oferece por padrão:

pacaur -S tilix-bin
tilix

Quem usou Mac provavelmente conhece o iTerm2, possivelmente o melhor emulador de terminal que já usei. Nada chega perto. Nada, exceto talvez o Tilix (antigamente chamado Terminix).

Só pelo “Ctrl-Alt-D” para dividir o terminal horizontalmente e “Ctrl-Alt-R” para dividir verticalmente, e “Alt-1”, “Alt-2” etc. para navegar entre os painéis, já vale a pena. Ainda vem com temas prontos excelentes como o clássico Solarized Dark ou meu favorito atual, Monokai Dark.

Não me xingue, eu sei. Alguns preferem o terminal padrão com TMUX. Também é gosto — faz mais sentido quando se trabalha em servidor remoto.

Adicione a fonte Hack monotype para um visual mais agradável:

sudo pacman -S ttf-hack

Linguagens de Programação

Vamos ver se as linguagens mais importantes instalam corretamente. Como sempre digo, o ASDF resolve essa questão.

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 o terminal e continue:

asdf plugin-add nodejs
addf plugin-add ruby

Para Node.js é preciso adicionar as chaves GPG corretas antes de instalar:

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

Ruby se beneficia do jemalloc para alocar menos memória do sistema. Não sei se impacta no WSL, mas vamos fazer de qualquer forma:

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é aqui tudo bem. Se precisar instalar um Ruby antigo (< 2.4) para projetos legados:

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 precisa de uma versão de OpenSSL que não deveria mais ser usada por questões de segurança. Todo mundo migrou para a 1.1. Além disso, o Ruby 2.3.x chegou ao seu EOL (fim de vida). Use por sua conta e risco.

Mas até aqui tudo funcionando. E o Go? Vamos ver:

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

Poderíamos continuar, mas acho que você já pegou a ideia. Simplesmente funciona!

Processos em Background

Outra limitação atual do WSL (que esperamos ver resolvida na Spring Creators Update) é a capacidade de iniciar e manter processos em background (daemons).

Fazer sudo systemctl enable postgresql e reiniciar não vai iniciar o Postgresql automaticamente em background como deveria. O próprio Arch.exe que estamos usando nem tem systemd.

Felizmente, servidores como Postgresql ou Redis funcionam normalmente — podem ser iniciados como processos de usuário e se vinculam corretamente às suas portas TCP. Mas você vai ter que iniciá-los manualmente a cada sessão. Feche o terminal Bash e todos morrem.

Por exemplo, 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 fiz aqui? Tem um problema na instalação sob WSL em que o /run/postgresql não é criado com as permissões corretas. Corrigindo isso conseguimos iniciar o servidor. Podemos sair da sessão su e o PostgreSQL continua rodando. Mas quando fecharmos a primeira janela/sessão Bash, ele morre.

E tem mais uma coisa irritante: as correções de mkdir e chown acima? Preciso fazer toda vez que fecho o Bash for Windows e abro novamente!! Absurdamente chato!

Mas dá para conviver por enquanto. Esperançosamente isso vai estar resolvido amanhã (30 de abril) ou em uma atualização próxima.

Em um ambiente de desenvolvimento Rails, dá para usar o Foreman para ajudar. Basta editar um 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

Aí é só: foreman start -f Procfile.dev e todos os serviços sobem de uma vez.

Performance no Mundo Real

Minha máquina do dia a dia é o Manjaro GNOME rodando no VMWare Workstation Pro no meu Surface Book 2. Dou a ele 6 dos 8 threads e generosos 12GB de RAM dos 16GB totais (Microsoft, precisamos de mais RAM! Os modernos implantam aplicativos estúpidos com camadas pesadas de JS/CSS que comem tudo que tem).

No projeto em que estou trabalhando, minha suite RSpec completa é um pouco lenta. Para essa comparação, estou pulando os feature specs porque não tenho paciência agora para configurar o chrome-driver no WSL (provavelmente funciona, mas fica para outra vez).

Finished in 12 minutes 8 seconds (files took 14.58 seconds to load)
1493 examples, 0 failures, 35 pending

531,34s user 127,56s system 88% cpu 12:24,99 total

No ambiente WSL comparável que acabei de instalar, rodando a mesma suite RSpec, obtive:

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 algum motivo meu ambiente WSL está pulando alguns exemplos (parece mais um bug de contador do RSpec), mas acho que isso não muda muito o panorama geral. O WSL perde mesmo que o contador esteja correto e ele esteja rodando menos exemplos.

Quando começamos a exercitar o WSL de verdade, toda sorte de problemas aparece. Por exemplo, o PostgreSQL entra em colapso e fica imprimindo “could not flush dirty data: Function not implemented” no stdout, por causa de um problema documentado do WSL! O que acaba acontecendo é que o runner do RSpec simplesmente pausa enquanto o PG tenta se resolver.

No VMWare os arquivos carregaram em menos de 15 segundos. No WSL levou mais de 3 minutos só em I/O de arquivos! Ordens de magnitude mais lento. Esse é o problema grave. Quando é só CPU contra CPU, os dois são bastante comparáveis.

No total, os tempos ficam próximos no papel. Em CPU o WSL até leva vantagem, o que explica como ele consegue recuperar o tempo total apesar do I/O claramente lento.

Na prática, numa situação normal de programação, você abre o Vim ou qualquer editor. Todo programador fica abrindo e alternando entre muitos arquivos o tempo todo. Com o I/O super lento, cada arquivo que você tenta abrir trava sua ação por uma fração de segundo. E isso vai acumulando.

Dentro do VMWare, o Vim responde na hora, abrir um arquivo é quase instantâneo.

O benchmark pode não capturar essa situação. Mas no dia a dia você vai acabar irritado. Além disso, rodar uma GUI sobre o X (VcXsrv no meu caso) também adiciona lentidão. Dentro do VMWare, o Xorg normal aproveita aceleração GPU, então todo o pipeline de rasterização é mais rápido.

Dá para usar o WSL como ambiente principal. Mas se consigo uma experiência mais fluida dentro do VMWare, é lá que vou ficar por enquanto.

Conclusão

Vou segurar minhas conclusões até amanhã (30 de abril) ou mais para o final da semana, porque se a Spring Creators Update realmente corrigir os problemas de performance, aí posso me ver usando isso no lugar da minha instalação do Manjaro GNOME no VMWare Workstation.

Pode não vir nessa grande atualização, mas tenho informações de que estão trabalhando nos problemas pendentes de performance de I/O. Então está chegando.

Tudo que preciso simplesmente funciona: Tilix, Vim, Git, Zsh, Ruby, Node.js. Tudo instala como esperado pelo Pacman e AUR. Pura glória do Arch Linux! Que pena que a performance ruim estraga tudo.

Está perto, muito perto! Pela primeira vez em quase 15 anos, consigo quase me ver voltando 100% para o Windows (sem VMWare) e ainda sendo totalmente produtivo com ferramentas reais, profissionais e open source que “simplesmente funcionam”.

Fique de olho neste post para atualizações esta semana!

Para quem tem pressa, o resumo é este:

• Windows 10 ainda é Windows, mas não chega nem perto do pesadelo dos anos 2000. Merece uma segunda chance de verdade.
• O OS X está a caminho de se tornar apenas um runtime do Xcode. Rumores dizem que a Apple nem tem mais uma equipe dedicada ao SO de desktop. O foco é total no iOS e em transformar o iPad no substituto do computador.
• Linux é ótimo. Se você é desenvolvedor web em tempo integral, consegue trabalhar confortavelmente com Ubuntu ou Manjaro/Arch (minha recomendação pessoal).

Melhor custo-benefício: o Dell XPS 13. O Surface Book 2 vale cada centavo se você é nerd como eu. Mas, como sempre, há ressalvas a discutir.

As Especificações

Não vou duplicar cada review de hardware que você encontra por aí. Todos são verdadeiros. Como o iFixIt diz: é a pior pontuação em reparabilidade. Como o MacBook, a linha Surface é uma declaração. É a melhor combinação de design e funcionalidade. A contrapartida é que tem zero de expansibilidade e você precisa tomar cuidado para não quebrá-lo. Se quebrar, garanta que tem garantia e exija a substituição.

Em termos de especificações, fica próximo dos outros notebooks top de linha.

O Surface Book 2 top de linha custa USD 3.299 e vem com SSD de 1 TB, 16 GB de RAM, GTX 1060 com 6 GB GDDR5, Intel Core i7 8ª geração Kaby Lake R, display 4K. Caríssimo, mas dá para justificar. Explico mais abaixo.

O Dell XPS 15" Touch top de linha custa USD 2.459 e vem com SSD de 1 TB, 32 GB de RAM, GTX 1050 com 4 GB GDDR5, Intel Core i7 7ª geração Kaby Lake, display 4K. O design do XPS é impecável faz pelo menos 3 gerações. Para mim, é o melhor custo-benefício.

O Razer Blade top de linha custa USD 2.599 e vem com SSD de 1 TB, 16 GB de RAM, GTX 1060 com 6 GB, Intel Core i7 7ª geração, display 4K. É provavelmente o melhor design industrial do grupo, com a atenção impecável da Razer aos detalhes. Mas também é o que tem menos suporte disponível e mais problemas de construção relatados, então cuidado ao comprar no exterior.

O HP Spectre x360 top de linha custa USD 1.499 e vem com SSD de 512 GB, GeForce MX150 com 2 GB GDDR5, Intel Core i7 8ª geração, display 4K. O design é lindo, super fino e conversível. As especificações não são lá essas coisas, mas é o mais barato entre os notebooks premium.

O Lenovo Yoga 920 14" Vibe top de linha custa USD 1.899 mas vem apenas com gráficos integrados Intel (sem GPU secundária), SSD de 1 TB, 16 GB de RAM, Intel Core i7 8ª geração, display 4K, e já inclui a Caneta. O design é ótimo, com uma dobradiça de quase 360 graus para usar como tablet. Um bom 2-em-1.

Agora, o MacBook Pro 15" top de linha custa USD 3.399 e vem com SSD de 1 TB, Radeon Pro 560 com 4 GB, Intel Core i7 7ª geração, display UHD e a infame touch bar (50% de chance de gostar). É isso. O design industrial e a construção ainda são excelentes, mas os concorrentes chegaram bem perto.

Se você usa aplicações gráficas intensivas, a Radeon Pro 560 é boa, mas a GTX 1060 é superior. Os displays UHD IPS (LCD) da Apple têm resolução máxima de 2560x1060. Todos os notebooks premium hoje vêm com displays 4K completos (LED) com resolução máxima de 3840x2160. A diferença é perceptível. Se você nunca viu um display 4K moderno, o display do MacBook vai parecer bom. E isso sem mencionar que todos são touchscreens com 4.096 pontos de sensibilidade. O que antes era gimmick hoje rivaliza com o melhor que a Wacom tem a oferecer. A linha Surface chega perto do topo da linha Wacom Cintiq e do novo iPad Pro. Estão no mesmo nível.

Há 2 aspectos do Surface Book 2 que deixam a desejar. Primeiro, a ausência de uma porta Thunderbolt 3 de verdade. Sem ela, você não consegue conectar armazenamentos externos modernos ou GPUs externas. O segundo é a fonte de alimentação fraca. Relatos indicam que em jogos muito exigentes (como Destiny 2 sem configuração adequada), o sistema throttla e drena a bateria mais rápido do que consegue carregar da tomada. The Verge quebrou essa história e a Microsoft ainda não apresentou solução. Então, se jogos são prioridade máxima, compre um Razer ou qualquer notebook específico para games, como um Alienware. O problema de bateria não é tão dramático quanto alguns relataram anteriormente.

Em termos de construção: Macs são todos feitos com a mesma construção unibody de alumínio. O Book 2 usa magnésio. Fica muito sólido e bem leve. Aliás, depois de tantos anos, todo mundo dominou o alumínio. E estão indo em outras direções. A Dell, por exemplo, usa fibra de carbono nos apoios de pulso, o que acho muito mais confortável. O magnésio também não é tão gelado quanto o alumínio. Gosto que os fabricantes superaram a fase de copiar e estão experimentando materiais novos e interessantes.

A Proposta de Valor

Já estabelecemos que o Surface Book 2 é caríssimo e nem é bom o suficiente para jogos muito exigentes como Destiny 2.

Onde ele realmente brilha é no fato de não ser um 2-em-1 conversível comum como o Spectre ou o Yoga. Você já sabe que a tela pode ser desacoplada da base.

A grande conquista da equipe Surface é a dobradiça fulcrum dinâmica. Uma maravilha de engenharia. Quando acoplada, não balança nem perto do que se esperaria. É muito sólida — você pode pegar o conjunto inteiro pela tela sem se preocupar que a base vai cair ou quebrar.

Quando ouvi falar nisso pela primeira vez, 2 anos atrás, achei legal mas pensei que poderia quebrar com o tempo, então esperei. Agora estou totalmente convencido porque 2 anos depois não se vê nenhum “hinge-gate” ou relatos massivos de dobradiças se desfazendo. E 2 anos depois nenhum outro fabricante tem isso. Se você não vê uma cópia barata vinda da China, é porque é muito difícil de construir. A Microsoft acertou em cheio nessa parte.

Com a tela removível, os componentes principais ficam todos atrás dela. CPU, GPU, RAM, SSD. Você tem um Intel i7 top de linha em um tablet! A bateria é compreensivelmente pequena (no máximo 3 horas) para alimentar um display 4K de 15" com capacidade touch e precisão suficiente para rivalizar com o iPad Pro e o Wacom Cintiq ou Mobile Studio.

O que a maioria não menciona é que, por causa disso, é o chassi da tela que esquenta. A base de performance fica fria! É super confortável ficar com ele no colo por muitas horas sem risco de ficar estéril ou cozinhar ovos no processo.

Tem potência para conectar 1 display 4K externo a 60hz ou dois displays 4K a 30hz. O MacBook Pro, com sua porta customizada, consegue alimentar um display 5K. Algo que a maioria dos notebooks ainda não consegue. Aí vai depender do uso.

Não sou designer de profissão, mas sou hobbyista. Depois de muitos anos de trabalho duro, acredito que posso me dar ao luxo de ter algo assim. E não me entendam mal, o Surface Pro é outra ótima opção para designers. O Surface Pro top de linha tem tudo que o Book 2 tem, sem a GTX 1060, mas custando USD 600 a menos, em USD 2.699. Acho que é um produto mais adequado para a maioria das pessoas que querem uma solução de esboço fácil de carregar.

Profissionais criativos são os que precisam ser mais cuidadosos nas especificações. Mas para a maioria dos profissionais sem demandas tão pesadas, dá para pagar bem mais barato. Não precisam de GPU extra, nem do i7 (um i5 já resolve), 8 GB de RAM são suficientes, até 256 GB de SSD já dão conta porque tudo hoje está na “Nuvem”. Esse é o Dell XPS 13 de USD 999. Ou a única opção comparável da Apple é o MacBook de USD 1.299 com um ridículo processador Intel m3. Para a maioria dos profissionais, o Dell XPS 13 mais barato é uma proposta de valor muito melhor do que o MacBook.

Para profissionais com demandas pesadas, o Dell XPS 15 é o melhor custo-benefício. O Surface Book 2 é o premium para quem valoriza a touchscreen mais do que o fluxo de trabalho. Em termos práticos: designers vão de Book 2, editores de vídeo ou modeladores 3D vão de Dell XPS.

Ah, e mais uma coisa sobre preço. O MacBook Pro 15" custa USD 3.399 e o Book 2 custa USD 3.299. Mas se você quiser um tablet, ainda precisa adicionar USD 949 por um iPad Pro de 12" com Wi-Fi e 256 GB de armazenamento. E vai acabar carregando uma mochila mais pesada.

Por que não instalar Linux?

Você não compra um produto Surface a menos que tenha interesse na experiência e no ecossistema da Surface Pen. Isso me parece óbvio, caso contrário você está melhor com um Dell XPS ou qualquer outro notebook mais barato.

Também é óbvio por que não faz sentido perguntar “Por que não abandona o Windows e instala Linux nele?”. Porque nenhuma distribuição Linux tem suporte à Caneta. A base de performance também tem uma tecla física que você precisa pressionar para que a dobradiça libere a tela.

Você vai querer ter Adobe Photoshop, Autodesk Sketchbook, Sketchable ou qualquer outro pacote de software excelente disponível. Não vou repetir cada review disponível mostrando quão boa é a caneta. Confirmo apenas que sim, a caneta é excelente, precisa, fiel, e flui de forma muito natural. É um estúdio inteiro numa caixa só.

Desenvolvedores de software deveriam evitar esse tipo de produto porque a maioria das distribuições Linux não terá os drivers adequados para tantas soluções de hardware exclusivas. Para essas situações, recomendo muito o Dell XPS 13, especificamente a configuração de USD 1.759 com Windows 10 Pro (ou economize USD 60 pegando a edição Home se pretende instalar Linux por cima), o ótimo display touch InfinityEdge QHD+ (3200x1800), Intel Core i7 8ª geração, 16 GB de RAM, SSD de 512 GB. É, de longe, o melhor custo-benefício para um desenvolvedor de software em tempo integral.

O OS X tem uma comunidade excelente apesar da Apple não fazer muito para ajudá-la. Historicamente, a transição do MacOS legado para o OS X significou ter um kernel e toolchain compatíveis com UNIX disponíveis. Até hoje, ainda não é comparável a uma distribuição Linux moderna. Mas o OS X compensa isso por ter, de longe, o melhor Compositor Gráfico do mercado. A GUI é fluida, responsiva.

O kernel Darwin Mach suporta múltiplas políticas, e a mais importante para Profissionais Criativos, especialmente músicos, era a capacidade de soft real-time do scheduler. Até hoje, o Linux Real Time não é a opção padrão, e não é tão bem ajustado nem estável. E o kernel do Windows evoluiu, mas ainda está longe de ser tão polido.

O Soft Real-Time evita o efeito de travamento que observamos. E é um dos fatores pelo qual a experiência Mac é, no geral, superior mesmo em hardware menos potente.

Em particular, todos na comunidade do Homebrew merecem muito elogio pelo esforço de continuar trazendo ferramentas open source para o OS X, apesar de cada nova atualização do Xcode e do OS X quebrar tudo.

Meu Ambiente

Depois de muita experimentação, decidi usar o Windows 10 nativo como host e uma distribuição Linux completa (Manjaro GNOME) em um ambiente Virtualbox, alocando 4 dos 8 cores (2 cores físicos, cada um com 2 hyperthreads) e metade da memória (8 GB).

Por que não usar o novíssimo Windows Subsystem for Linux (WSL)?

Porque embora seja promissor, ainda precisamos esperar que resolvam as arestas. Em particular, um suporte melhor a GUI e uma abstração de I/O mais rápida. O que dói mais é como a camada de sistema de arquivos é dolorosamente lenta agora. É uma ordem de magnitude mais lenta do que usar Linux no Virtualbox.

Poderia usar uma solução híbrida estilo Vagrant, com uma distribuição Linux headless no Virtualbox e acessando arquivos via CIFS/NFS. Funcionaria bem se você gosta de editores como Sublime Text 3, Visual Studio Code ou Atom. Mas sou do time Vim e gosto do GVIM, que funciona melhor dentro do GNOME, dentro de uma distribuição Linux com GUI de verdade.

“Por que não usar Docker? É super rápido e tal.”

Me surpreende quando as pessoas perguntam isso, porque demonstra como pouco entendem das ferramentas que recomendam.

Docker faz sentido de verdade em uma distribuição Linux nativa. No Windows, precisa rodar Linux no Virtualbox ou Hyper-V. No Mac, usa o framework Hypervisor, que — como o Hyper-V da Microsoft — é uma camada de virtualização. É basicamente o mesmo que Virtualbox, para todos os efeitos práticos.

Docker, como o LXC, apenas faz um processo “acreditar” que está rodando sozinho no SO ao ocultar os outros processos. Então, no Linux, é super rápido. Em qualquer outra plataforma, precisa virtualizar o Linux e então rodar o Docker lá dentro.

O cliente Docker está na verdade se comunicando com um Linux virtualizado no Windows ou Mac. Se você acreditou que é mais rápido que Virtualbox ou Hyper-V de forma significativa, foi enganado. Não há mágica aqui.

“Por que não dar dual-boot então?”

Isso também não resolve meu cenário. Quero um ambiente GNOME completo com GUI. E não quero manter Outlook no Windows e Thunderbird ou Evolution no Linux, gerenciando contas diferentes em todo tipo de aplicação (e sim, prefiro muito binários nativos a web apps, sou old-school assim). Não quero reiniciar quando quiser usar o Photoshop e reiniciar de volta para Linux para usar o Vim.

Quero ter software de ambas as plataformas disponível ao mesmo tempo. Não acredito em cenários de dual-boot a menos que os usos sejam completamente separados. Por exemplo, usar uma distribuição Linux o dia todo e à noite reiniciar no Windows para rodar o Steam e jogar.

Sim, o Virtualbox terá uma UI menos responsiva por causa do pipeline gráfico virtualizado. Mas para desenvolvimento de software, funciona perfeitamente. Até vejo pessoas fazendo coisas mirabolantes como ter um ambiente de desenvolvimento inteiro em uma instância EC2 da AWS e acessar via SSH com Vim e Tmux. Isso é bem mais complicado, na minha opinião. Não iria tão longe.

Todo o hardware top de linha que listei acima tem Cores e RAM suficientes para rodar 2 SOs ao mesmo tempo. Não faça isso em hardware básico.

E se não precisar de um notebook para carregar, com o mesmo dinheiro você compra um computador desktop muito superior.

“Mas no OS X você tem tudo nativo, porque é UNIX e tal”

Sim, mas desconfio muito das grandes atualizações do OS X da Apple. Elas sempre, sempre estragam alguma coisa. Depois de ter minha cota de dias de trabalho perdidos pós-atualizações, migrei meu ambiente de desenvolvimento para o Vagrant pelo menos 5 anos atrás. Então já estava usando Linux no Virtualbox (ou VMWare) o tempo todo. Nunca olhei para trás. Ficava lendo as reclamações das pessoas depois das grandes atualizações e eu estava lá, ileso e produtivo. O Virtualbox era muito pior naquela época, hoje não é tanto. Não me lembro da última vez que travou, se é que travou alguma vez.

“Mas por que não usar Hyper-V em vez do Virtualbox?”

Tentei. E não recomendo agora. Foi construído para que o Windows rode caixas Linux em servidores. Então é excelente para particionar recursos de hardware entre diferentes instâncias virtuais. A menos que você seja sysadmin em treinamento ou precise de um servidor simulado no seu notebook, não é para você.

Tem suporte muito ruim para gráficos (servidores headless não precisam de gráficos). A resolução máxima no monitor virtual é um ridículo 1152x864. Meu Virtualbox suporta meu monitor LG Ultrawide 2560x1080 tranquilamente. O Hyper-V não consegue e isso é um dealbreaker.

Virtualbox, VMWare, Parallels e Hyper-V vão todos usar as mesmas instruções VT-X fornecidas pela Intel. A performance base não vai ser tão diferente. As ferramentas de guest podem diferir. Alguma estabilidade pode diferir. Mas no geral, são basicamente a mesma coisa do ponto de vista da usabilidade.

Sei que parece “estranho” rodar o Windows 10 como host nativo principal. Mas funciona bem no geral.

E também sei que parece ainda mais estranho rodar uma distribuição Linux como SO convidado secundário no Virtualbox. Mas posso dizer que quando estou usando em tela cheia, trabalhando, não tenho a sensação de que está lento ou sem resposta.

O Software

Se você está no OS X, provavelmente está acostumado com muitas ferramentas. Pagou dinheiro por algumas delas. E trocar de SO sempre é uma dor.

Em resumo, o único software que realmente senti falta no começo foi o Keynote. Mas superei meu preconceito contra o PowerPoint e tenho que admitir que ele faz tudo que preciso agora.

Sempre odiei Pages e Numbers — são ótimos para amadores. Mas nada, nem o LibreOffice, muito menos o Google Docs, substitui o Office. O Google Slides é terrível e o Impress é além de inútil para mim (e é super lento). Sério, o PowerPoint hoje é uma ferramenta muito melhor.

O Office no Mac sempre foi “suficiente”, felizmente. Mas o Office no Windows é muito superior. Sem dúvida na minha mente. Então um grande benefício de voltar ao Windows 10 é ter a experiência completa do Office.

Se você usa as ferramentas da linha Pro, vai sentir falta do Final Cut Pro. Se é músico profissional, vai sentir falta do Logic Pro. Não há nada como o GarageBand para músicos hobbyistas. Não há nada a fazer aqui. E mesmo tendo hardware melhor no PC, a Apple customiza o Final Cut para render excepcionalmente melhor no AMD Radeon Pro. Então os tempos de exportação do Final Cut ainda são superiores aos do Adobe Premiere. O Motion 5 ainda é mais fácil e responsivo que o After Effects.

Dito isso, a margem não é enorme. A Adobe Creative Suite é muito forte, e a menos que você seja um one-trick pony, qualquer profissional consegue migrar para a Adobe e fazer o trabalho.

Em termos de desenvolvimento de software, a menos que você seja um one-trick pony do .NET, vai querer toda a parafernália open source. O WSL deveria fornecer isso — no futuro. Agora mesmo, sua melhor aposta é rodar o Virtualbox e você não vai se arrepender.

Sim, existem pequenos softwares exclusivos como 1Password, Tweetbot, Alfred. Não sinto falta de nenhum deles. Especialmente porque meu último iPhone foi o 4, lá em 2010. Depois migrei para Android com o Galaxy S4 e também nunca olhei para trás. Estou usando um S8 e prestes a receber meu Pixel 2, então estou bem em termos de cliente de Twitter ou gerenciamento de senhas (uso o LastPass e, embora não seja perfeito, resolve).

Ou existe um substituto nativo bom o suficiente para desktop ou mobile, ou existe um serviço Web. Posso me sentir desconfortável com a mudança, mas na prática não há nada no macOS que me impeça de trocar. Mesmo que você tenha comprado músicas ou filmes no iTunes, existe iTunes para Windows.

“Mas espera, o Windows Update vai te enlouquecer!”

Achei o mesmo. A Microsoft finalmente resolveu isso. Ainda existe, você ainda precisa reiniciar. Mas não é nem de longe tão irritante quanto era antes. A maioria das atualizações roda em segundo plano e você nem vai notar. E há várias opções como agendar para rodar apenas à noite quando você não está trabalhando.

“E os problemas de segurança e vírus!?”

Sim, recomendo fortemente não navegar na Deep Web numa máquina Windows, você vai ser comprometido. Nem com um browser Tor. Vai ser comprometido.

Também recomendo usar o BitLocker (disponível apenas no Windows 10 Pro) para criptografar sua partição. E fazer backup em HDs externos com a maior frequência possível. Nada te protege melhor do que um backup frio prontamente disponível.

E sim, instale alguma solução de terceiros como o Avast antivírus. Tenha comportamento saudável de navegação e evite sites duvidosos. Você sabe do que estou falando. Vai ser comprometido.

Se necessário, instale uma distribuição Linux segura dentro do Virtualbox e abra o Tor de lá.

“E a bagunça que é o Registro!?”

Ainda existe. Se você nunca experimentou, o Registro é o equivalente Windows do “/etc” nas distribuições Linux. É um banco de dados binário. Fica corrompido. Fica com entradas sujas.

Mas minha recomendação é: esqueça-o. Se você ficar pensando e mexendo nele, vai corromper o sistema. Não tente limpá-lo (nunca, jamais use algo como o CCleaner).

O próprio Windows agora tem snapshots automáticos de restauração do sistema toda vez que algo importante acontece. E é bastante confiável. Chegam ao ponto de duplicar o diretório atual “C:\Windows” em um “C:\Windows.old” quando há uma grande atualização do Windows, só por precaução. Se atiraram no próprio pé tantas vezes que finalmente aprenderam a ter várias camadas de opções de recuperação.

Hoje você pode até baixar a ferramenta de Criação de Mídia diretamente do site da Windows. Não precisa nem se cadastrar em lugar nenhum. E a licença do Windows vem no firmware (BIOS) da máquina. Não precisa nem lembrar onde está sua chave de ativação do produto. Ativa automaticamente e como cada máquina já vem com uma licença, o processo é transparente. E a maioria dos fabricantes tem atualizações automáticas para drivers e firmware.

Então você deve ter uma experiência razoavelmente tranquila, aconteça o que acontecer.

“Mas o Windows não é open source!”

O OS X também não. E essa é uma vantagem do Linux. Então, se for obrigatório, use apenas Linux nativamente. O ponto da discussão é encontrar uma alternativa ao Mac. Então estamos alinhados.

O Efeito Ruby on Rails e os Hipsters

Sendo honesto: no mundo do desenvolvimento de software, migramos para o Mac principalmente por causa do Rails e do Textmate 2. Tínhamos acesso a algumas ferramentas open source embutidas, tínhamos GCC para compilar o resto. O Windows XP estava bem além da validade. O Windows Vista foi uma experiência horrível. Os fabricantes de hardware para PC nem estavam tentando, e a Apple lançava hardware bom e boa experiência o tempo todo.

Os desenvolvedores migraram em massa após a transição de PowerPC para Intel em 2005. Meu primeiro Mac foi um Mac Mini G4 com OS X 10.4 Tiger. Depois comprei o primeiro MacBook branco Intel e nunca olhei para trás.

As ferramentas de software no Windows eram risíveis. O Visual Studio .NET era terrível. IDEs baseadas em Eclipse eram terríveis. Não tínhamos PowerShell ainda. E definitivamente nunca tivemos nada como o WSL para linha de comando. Você podia instalar o Cygwin, mas era uma experiência sofrível.

E rodar Linux como SO principal também era terrível. O Wine ainda é terrível, apesar de seus melhores esforços. Infelizmente, as GPUs da NVIDIA e AMD só rodam no melhor de sua capacidade no Windows. E Linux nunca foi realmente bom para criação de conteúdo. Não é nem questão de aprender um novo fluxo de trabalho — as ferramentas são medíocres. Precisam fazer engenharia reversa de tudo, e isso leva tempo. E na velocidade das redes sociais, não temos tempo suficiente, então precisamos aceitar compromissos.

O ecossistema Windows parou de fingir e finalmente abraçou tudo que o ecossistema open source e da Apple construiu. Agora todos nos beneficiamos.

A propósito, se você gosta do iTerm 2, vai adorar instalar o Tilix para Linux, que é muito similar.

Com o Passar do Tempo

Acompanho a evolução da linha Surface ao longo dos anos. No começo, era muito cético. É muito fácil lançar um produto gimmick e descontinuá-lo. Confio em empresas que continuam evoluindo seus produtos ao longo dos anos. Não só um ecossistema se forma em torno deles, como você tem tempo para montar serviços de suporte, peças disponíveis nas lojas oficiais e no mercado secundário. Depois de todos esses anos, a Microsoft merece ser chamada de fabricante de hardware.

É a Microsoft finalmente cumprindo o que Alan Kay disse uma vez:

“Pessoas que são realmente sérias sobre software deveriam fazer seu próprio hardware.”

Só falharam de verdade no mercado de smartphones, onde a competição é muito mais difícil e as margens são super baixas por causa disso. Mas acertaram no mercado de tablets, no desktop, no notebook, nos games, nos servidores (com seus próprios serviços Azure). Então agora acredito que eles realmente entendem as necessidades específicas de todas essas áreas, e isso aparece no software. Têm um entendimento muito superior de cada mercado — exceto smartphones — em relação à Apple. Finalmente têm skin no jogo de verdade.

Porque agora a Microsoft fabrica seu próprio hardware e fez um negócio disso, há um incentivo real dentro das equipes da empresa para um ciclo de feedback positivo que resulta em mais refinamentos no código do Windows.

Ficaram tentando e falhando em soluções touch desde o início dos anos 2000. Agora a Caneta não é mais um gimmick, é um produto real, com qualidades reais e casos de uso reais.

Também mantiveram sua visão de se dar bem com o Open Source. Ninguém pode razoavelmente esperar que a Microsoft vire totalmente open source. Mas aparece. São os segundos apenas para o Google no GitHub em termos de contribuições open source. Adquiriram a Xamarin e sua estratégia de .NET Core está em andamento e forte. O próprio Visual Studio recebeu tratamento open source. Ainda há um longo caminho, mas é preciso reconhecer os passos gigantescos.

O que é muito mais do que podemos dizer sobre a Apple, onde os coitados do Homebrew sofrem a cada atualização do OS X.

A tentativa do Surface RT e do Windows Mobile até possibilitou que o Windows fosse finalmente compilado para rodar em processadores ARM. É um bom sinal para o futuro. Me lembra quando o OS X foi compilado pela primeira vez para rodar em processadores Intel (antes rodava em PowerPC) em 2005.

E o MacBook? Ganhou uma touch bar gimmick. A Apple está realmente desconectada da realidade.

Por Que Saí do Ecossistema Apple?

O foco da Apple não é no Mac. Pior: o Mac está rapidamente se tornando abandonware, apesar dos comunicados de relações públicas.

São claramente uma empresa de iPhone, com um negócio paralelo hobbyista que fabrica Macs e MacBooks, que existem principalmente para servir como toolchain de desenvolvimento de apps para iPhone. Esse é o modelo de negócios.

Você viu o último anúncio deles para o iPad?

Sim, é super fofo e eu curto.

Mas a mensagem é cristalina: a visão é para as pessoas usarem apenas iPhones e iPads. Não existe tal coisa como um “computador”.

São a empresa de tecnologia mais valiosa no momento. Mas desde o ano passado, não têm mais nem uma equipe dedicada ao OS X. O que isso diz?

A linha iOS é um “monopólio” dentro da linha Apple. O Mac não consegue competir. O próprio Steve Jobs alertou sobre o que acontece com os monopólios.

Estamos começando a ouvir a mesma história por toda a indústria:

• Apple’s relationship with pro music needs some mending - Set, 26, 2016
• How Apple Alienated Mac Loyalists - Dez, 20, 2016
• macOS is becoming legacy software - Dez, 21, 2016
• Apple Is Dead To Me… I’m Switching To Windows! - Fev, 10, 2017
• Why I left Mac for Windows: Apple has given up - Mar, 5, 2017

A Microsoft jogou bem suas cartas. Levou quase 15 anos. Mas valeu muito a pena. A Apple realmente alienou os leais, os que costumavam “Think Different”.

A Apple é “vítima” do “Dilema do Inovador” de Clayton Christensen. Se ainda tivessem visão, poderiam se estender e manter. Mas ao invés disso, escolheram apostar tudo em uma única linha de produtos.

A Microsoft parece ter lido a “Solução do Inovador: Criando e Sustentando o Crescimento de Sucesso” de Clayton.

Quando o iPod estava no auge, a Microsoft havia “perdido”. Estavam fora do jogo. Era deprimente de ver. Steve Ballmer foi um CEO vergonhoso. O Windows Vista foi um SO vergonhoso. O Zune falhou em capturar a aura do iPod. O Windows Mobile era uma bagunça. E o Sharepoint… ah, o Sharepoint. Chegaram a comemorar quando o jQuery foi adicionado ao ASP.NET! Falar em tarde demais.

E a Amazon — uma loja de varejo — lançou com sucesso a melhor infraestrutura do mundo e se tornou sinônimo de “Nuvem”, enquanto a Microsoft ainda estava tentando entender o que era Linux.

Falha após falha, em vez de defender sua posição baixa, finalmente decidiram se erguer e seguir em frente um passo de cada vez. Refinar. Evoluir. Sustentar.

Agora, o Windows 10 recapturou a aura do XP no seu melhor. Está fazendo atualizações incrementais e sólidas. Primeiro a Anniversary Edition, depois a Creators Update e finalmente a mais recente Fall Creators Update. Todas atualizações sólidas.

A linha Surface está indo forte como a melhor referência de design industrial e funcionalidades em desktops, notebooks e acessórios. Sério, a Apple ainda vende aquele terrível Magic Mouse 2 escorregadio e difícil de segurar, mas a “mágica” é que alguém de fato compra. A Microsoft tem o Arc Touch e o Precision Mouse, dois dos melhores já fabricados.

Profissionais criativos, desenvolvedores de software — todos migramos em massa para o OS X quando era a “Coisa Diferente” da campanha “Think Different”. Ajudamos a evangelizar. Ajudamos a construir ferramentas. Ajudamos a construir serviços. Escrevemos toneladas de posts e documentação para ajudar.

Steve Jobs morreu e a Apple morreu com ele. Basicamente não fizeram nada novo desde então, e seus produtos antes bem-sucedidos foram deixados para decair e morrer. O que resta é o efeito halo, a inércia, e o crescente apetite por ordenhar a mesma vaca indefinidamente, abandonando todo o P&D.

A Apple Não Liga. Por Que Eu Deveria?

A Microsoft jogou com inteligência, continuou corrigindo e evoluindo, ano após ano. Perdeu a geração dos anos 90. Recuperou a geração dos anos 2010. E começaram cedo, atraindo atenção pelo Xbox até chegar ao Windows.

Sério, o Dashboard do XBox é melhor do que o do PS4. Prefiro muito mais.

E agora estão em boa posição. Os jogadores estão invertidos. O “Think Different” agora se refere ao Windows 10 e ao hardware PC. A Intel está conservadora. A NVIDIA fabrica as melhores GPUs. Há muitas ótimas opções que não estão disponíveis no Mac.

A transição de 32 para 64 bits e as necessidades do XBox até ajudaram a Microsoft a repensar como isolar e empacotar seu software. Mesmo que a Windows Store ainda seja uma piada de mau gosto neste ponto.

E Bill Gates estava absolutamente certo em meados dos anos 90: o browser tornaria o monopólio do Windows obsoleto. E tornou. Do lado bom, você tem os mesmos Chrome e Firefox disponíveis no OS X, Windows 10 e qualquer distribuição Linux. Isso significa acesso imediato a tudo que a maioria das pessoas precisa: Gmail, Google Docs, Office 365, Dropbox, LastPass, Spotify, Slack, Discord, Twitter, Netflix, HBO, Hulu, etc.

Odeio wrappers de desktop baseados em Javascript como a praga. O Electron é pesado demais. Mas o que posso fazer? Pelo menos hardware poderoso e RAM estão baratos hoje em dia, e podemos nos dar ao luxo de abas de browser que consomem 100 MB cada.

O browser é o novo SO para a maioria das pessoas. Muita gente se vira com Chromebooks! Todo o resto está nos celulares, não no desktop. Então ferramentas pesadas são necessárias. Ferramentas leves você já carrega no bolso.

O ecossistema Apple ainda não está morto. A Apple ainda tem tempo de corrigir a situação. Tenho esperado pelos últimos 3 anos, mas ainda zero sinais de melhora. Meu primeiro artigo sobre a troca foi publicado em 10 de novembro de 2015.

Diferente de outros artigos sobre troca de plataforma, não estou dizendo isso de forma leviana. Já fiz a troca, nos últimos 2 anos.

Como digo em muitos dos meus posts e palestras: não sou definido pelas minhas ferramentas. Não carrego bandeiras. Não sou leal a ninguém por padrão. Nunca fui pago pela Apple para defendê-la. E não sou pago pela Microsoft para dizer coisas boas sobre ela. Apenas analiso os fatos e aponto o melhor caminho a seguir.

E os fatos me dizem que o macOS chegou ao fim. Foi uma boa viagem. Adeus ao Mac e obrigado pelos peixes.

O verdadeiro “Ano do Linux no Desktop” ainda não chegou. Mas está chegando, como vou explicar.

TL;DR este não vai ser ‘mais-um-post-de-instalação-do-WSL’, já existem vários por aí, por exemplo este ou este outro. E você sempre pode pesquisar no Google.

No início de 2016 a Microsoft anunciou e lançou uma versão bem alpha do que viria a ser o Windows Subsystem for Linux (WSL). Ele inicializava e rodava alguns programas, mas era cheio de bugs. Justo, afinal era ainda apenas um preview para Insiders (aliás, evite builds do Insider Preview, eles travam com tela azul o tempo todo, é desenvolvimento ativo).

Um ano se passou, chegamos ao Windows 10 Anniversary Update e, finalmente, ao tão esperado Creators Update. A evolução foi significativa.

Se você não sabe o que é o WSL, recomendo muito que leia os artigos no blog de desenvolvedores da Microsoft e o excelente post da Jessie Frazelle, Windows for Linux Nerds. Em resumo: o WSL intercepta as system calls do kernel do Windows e as mapeia como system calls do kernel Linux, enganando binários ELF64 não modificados para que rodem como se estivessem num sistema Linux de verdade. O detalhe crucial é que não há nenhum kernel Linux rodando! Ele também encapsula serviços do Windows como sistema de arquivos e rede em dispositivos que o Linux consegue acessar.

Portanto, não é virtualização. Não existe Hyper-V envolvido. É o Windows executando binários ELF64 diretamente, sem recompilação, sem modificação.

Diferentemente do OS X, onde é preciso ajustar o código-fonte e recompilar para rodar no Darwin (a camada Mach/BSD do sistema), aqui dá para baixar binários Ubuntu (ou de qualquer outra distro — Fedora e SUSE estão chegando em breve à Windows App Store) e executá-los diretamente.

Melhor ainda: dá para rodar daemons de sistema (sim, PostgreSQL, Memcached, Redis, etc. todos carregam e rodam em background) e até programas com interface gráfica via X!

Não me entendam mal, tenho o maior respeito por quem trabalha duro na Microsoft para fazer isso acontecer. É um feito técnico notável por si só.

Olhem bem para esse screenshot. É algo digno de admiração: GNOME-VIM nativo rodando lado a lado com o Microsoft Edge carregando um site servido por uma aplicação Rails dentro do WSL, acessando o PostgreSQL.

Mas será que funciona bem para o dia a dia?

O WSL é bom de verdade?

TL;DR não chega nem perto de ser tão fluido quanto rodar uma distro Linux pura, e a integração está longe de ser tão boa quanto o OS X em termos de usabilidade — o Windows simplesmente não foi redesenhado de forma significativa para ser um sistema UNIX como o OS X.

Num mundo ideal, o Windows substituiria toda a base NT e construiria sua própria infraestrutura inspirada em BSD (como o Darwin) ou criaria uma distro Linux própria usando o kernel Linux pronto (provavelmente inviável por causa da GPL).

Mas isso é irreal. A Apple conseguiu fazer isso numa época em que a base instalada de Macs era pequena, então alienar alguns usuários não custava tanto. O Windows é grande demais para falhar. É e continuará sendo um pesadelo de manutenção de proporções épicas.

Dito isso, o WSL em si é um milagre, então não tenho como reclamar. A Microsoft teve uma década realmente difícil na virada do século. O Windows 10 é uma volta por cima, e depois de duas grandes iterações está finalmente se tornando razoável de novo. Talvez estejamos a mais algumas atualizações de um WSL realmente utilizável. Só o tempo dirá.

A Apple teve seu milagre na virada do século, e o OS X e o iOS são sistemas operacionais excelentes. Os melhores da categoria. E conseguir reiniciar um ecossistema inteiro do zero não é algo que qualquer empresa consegue fazer.

As distros Linux tiveram seus altos e baixos. Nenhum ecossistema evolui de forma saudável e coesa sendo tão fragmentado. Mas cada distro principal conseguiu forçar seu próprio ecossistema na marra. A Canonical sobreviveu onde muitas falharam, mas ainda não é a vencedora definitiva, e dá a impressão de que está perdendo o fôlego. A RedHat aproveitou a febre do dot-com e conseguiu voar alto no mercado corporativo. Não existe distro “melhor”. É, de novo, uma questão de gosto e ego, na maior parte do tempo para a maior parte das pessoas.

E a comunidade OSS ainda desperdiça uma quantidade absurda de tempo em disputas sem sentido, como a controvérsia do Systemd ou o tempo que está levando para abandonar o X e finalmente migrar para o Wayland. OSS tem prós e contras, como tudo o mais.

Mas voltando ao WSL, antes que eu me perca. Sim, como prometido, quase tudo que se faz num Ubuntu 16.04 nativo pode ser feito nesse novo ambiente. Até o ridículo cmd.exe foi bastante atualizado para o século XXI. Ainda está longe de um Terminal padrão do Linux ou OS X, mas está chegando lá. Na prática, eu recomendaria instalar o WSL Terminal como substituto, e apesar do nome terrível “Bash on Ubuntu on Windows”, eu recomendaria instalar o ZSH em vez do Bash para ter mais recursos de usabilidade.

Dá para pesquisar tutoriais sem fim sobre como personalizar o ambiente, Vim, ajustar o PostgreSQL, etc. Então não vou repetir isso aqui. Um aviso importante: tenho que rodar sudo /etc/init.d/PostgreSQL start para iniciar os daemons. Eles não sobem automaticamente depois de reiniciar o sistema — guarde isso.

Também dá para instalar um servidor X no Windows, como o xming, fazer export DISPLAY=:0 e então sudo apt install gvim para carregar a versão gráfica do Gvim, por exemplo. Ou um desktop GNOME ou XFCE completo, se for o seu negócio. Dá para rodar aplicações X lado a lado com apps Windows, e isso é muito legal. Gosto de instalar o YADR, aquela coleção de dotfiles supercustomizada, e ele funciona bem.

Estou usando o ASDF para instalar e gerenciar múltiplas versões de Ruby, Node.js, Elixir, etc. E também funciona.

Consegui mover minhas chaves SSH da instalação anterior do Arch Linux. E aí consigo clonar os repositórios Git normalmente. E aqui vem o grande problema. Clonei e configurei um projeto Rails. Este é o melhor resultado que consegui rodando toda a suíte RSpec com testes de aceitação usando PhantomJS:

Finished in 5 minutes 35 seconds (files took 48.53 seconds to load)
888 examples, 0 failures

Isso rodando no meu Dell XPS 9550 com Core i7 Skylake (4 cores, 8 threads), 16 GB de RAM e SSD NVME2. Pedi a um colega para rodar no Mac Mini dele, de 2012, com Core i5 (provavelmente Haswell), 10 GB de RAM e SSD normal. Este foi o resultado dele:

Finished in 3 minutes 37.6 seconds (files took 9.73 seconds to load)
888 examples, 0 failures

Sim, chocante. A emulação do sistema de arquivos é notoriamente lenta no WSL (pelo menos 4 vezes mais lenta, como se vê nos números acima).

Este outro teste rodou num hardware um pouco mais novo (ainda bem inferior ao meu Dell XPS) com Linux Mint:

Finished in 3 minutes 2.4 seconds (files took 22.69 seconds to load)
888 examples, 1 failure

Rodei a mesma suíte algumas vezes para confirmar, mas não consegui passar da marca de 5 minutos, e o carregamento de arquivos fica sempre em torno de 1 minuto, enquanto em outros sistemas operacionais é de 2 a 4 vezes mais rápido.

Se o seu fluxo de desenvolvimento é intensivo em I/O, você vai sofrer. A compilação do Webpack, que já é lenta, fica ainda mais lenta. Npm/Yarn demora uma eternidade. Instalar coisas a partir do código-fonte é muito devagar.

Não chega a ser inutilizável, mas essa lentidão vai cansar rápido.

E a Virtualização?

Depois de ver a performance de sistema de arquivos deplorável descrita acima, pensei: “e quanto a rodar tudo no bom e velho Virtualbox?”

Em teoria, o WSL “deveria” ser uma camada mais fina que o Virtualbox, mas o grande vilão em termos de overhead parece ser a camada de abstração do sistema de arquivos, e não necessariamente o acesso a CPU ou RAM. Meu instinto inicial diria que um Virtual Drive — um único arquivo montado como HD virtual — teria um desempenho bem melhor.

Então lá fui eu instalar o Virtualbox com o mesmo conjunto de ferramentas (asdf, etc.).

Montar uma pasta compartilhada diretamente para o equivalente no WSL não funciona direito; parece que o protocolo de montagem não entende dot files, então eles simplesmente não aparecem. É preciso compactar a pasta com tar e descompactar dentro da máquina para preservar arquivos ocultos e permissões.

Rodando a mesma suíte RSpec no Virtualbox com 4 Cores (dos 8 que minha máquina tem) e 4GB de RAM:

Finished in 2 minutes 3.4 seconds (files took 6.33 seconds to load)
888 examples, 2 failure

Então fomos de 5:35 min para 2:03 min e o carregamento de arquivos de 49 segundos para 6 segundos! Cerca de 2,5 vezes mais rápido na execução e nada menos que 8 vezes mais rápido no carregamento de arquivos! É absurdo, mas faz todo sentido. Minha máquina de 2016, dentro do Virtualbox, ainda supera hardware bare-metal de 2011/2012. E o WSL fica na última posição.

Esqueça benchmarks sintéticos — este é um caso real misturando execuções bound em CPU e I/O. Só para comparar, tentei ver se conseguia mais desempenho rodando no VMWare Workstation. O resultado:

Finished in 2 minutes 3.3 seconds (files took 6.21 seconds to load)

Praticamente idêntico. Para mim, isso mostra que o Virtualbox percorreu um longo caminho para se igualar a soluções comerciais historicamente mais robustas como VMware e Parallels, então fico com o Virtualbox por enquanto.

Fiz outro teste: instalação do Ruby 2.4.2 a partir do código-fonte usando asdf. Primeiro no WSL (rodando com time):

229.38s user 244.59s system 113% CPU 6:57.51 total

E a mesma instalação no Virtualbox:

295,39s user 22,43s system 135% CPU 3:53,87 total

Mais uma vez, cenário misto de CPU e I/O. No Virtualbox sou pelo menos duas vezes mais rápido.

Se quiser ver cenários mais controlados com benchmarks sintéticos, recomendo ler o artigo do Phoronix sobre WSL vs Virtualbox.

O Dilema do “Ano do Linux no Desktop”

A falta de software comercial é um problema, e uma das causas é a ausência de compatibilidade binária retroativa.

Apesar de todos os seus problemas, a Microsoft manteve compromisso com um conceito muito difícil: dá para executar binários não modificados do Windows 95 no Windows 10 atual. Na maioria das vezes eles “simplesmente funcionam”. Nas distros Linux, todo binário é compilado contra cabeçalhos de biblioteca muito específicos — o próprio kernel, Glibc e muitos outros. Sempre que um desses muda, todos os binários precisam ser recompilados. É por isso que existe o conceito de “distros”, onde se recompila e testa um conjunto completo de softwares. O Long-Term Support (LTS) é basicamente travar as versões dessas dependências por alguns anos para que o software rode sem precisar recompilar tanto. Mas em distros de ponta, é inevitável recompilar muita coisa várias vezes.

O Windows carrega os binários de dependências antigos consigo. O OS X faz o mesmo em certa medida. E o OS X vai além, com o conceito de “fat binaries” (ou “Universal Binaries”), onde um pacote contém múltiplos binários voltados para diferentes arquiteturas de hardware (32-bit vs 64 bit, Intel vs ARM vs PowerPC).

Principalmente por causa desse suporte, aplicações comerciais complexas como o Office ou o Creative Suite da Adobe conseguem rodar em muitas máquinas diferentes, em versões diferentes do sistema operacional, por muitos anos sem precisar atualizar. Nas distros Linux, binários são uma dor de cabeça. É por isso que ter o código-fonte disponível é tão importante — e esse é um debate filosófico sobre o conceito do “Software Livre” como concebido por Richard Stallman.

É um dilema sem solução. Distros Linux não têm compatibilidade binária retroativa nativa. Desenvolvedores precisam contar com ferramentas como o ABI Compliance Checker e tentar usar symbol versioning do glibc, entre outros recursos. Mas não é realista esperar que voluntários contribuindo com seu tempo livre para o código aberto mantenham versões antigas de software por muitos anos. É um compromisso justo. Quer o melhor, o mais rápido, o mais seguro? Atualize frequentemente, mas aceite que software antigo e não mantido vai quebrar.

Portanto, sem liberar o código-fonte, não dá para ter binários compatíveis e bons em cada grande distribuição, em versões diferentes, ao longo de muitos anos.

Qual é o certo para você?

Não adianta tentar fazer benchmark de sistemas operacionais. Todos são geralmente bons o suficiente.

Macs são mais caros (às vezes por uma diferença absurda de mais de um milhão de reais). Não tem como negar. O compromisso é que o hardware da Apple, o OS X e o ecossistema são geralmente os melhores no geral, e o “acabamento” dos produtos costuma ser de fato superior do ponto de vista de experiência de uso.

Para a melhor combinação de software mainstream com software open source, não existe alternativa melhor. Se puder comprar um Mac, compre um Mac.

Quem é gamer precisa ficar com o Windows. Sem discussão. Os melhores jogos estão no Windows, ponto. A melhor combinação de hardware suporta Windows. Nenhum ajuste no Linux vai te dar o desempenho bruto necessário para extrair 4K a 60fps das novas GPUs AMD e NVIDIA via DirectX. O hardware Mac tem limitações e não aceita as GPUs mais novas. Se quer jogar os últimos jogos AAA do jeito que foram projetados para rodar, monte um hardware personalizado com Windows 10.

Desenvolvedores web têm mais sorte. Não tem como errar — é literalmente questão de gosto qual sistema operacional escolher. Dá para entregar os mesmos resultados usando as mesmas ferramentas. E a não ser que você precise de infraestrutura específica Microsoft (SQL Server, Active Directory, etc.), instala qualquer distro Linux e fica feliz.

Desenvolvedores de apps desktop precisam pensar no público-alvo. Se quer construir apps desktop Windows, tem que estar no Windows. Mas dá para usar .NET/Xamarin ou Java para construir binários cross-platform. O problema é que, idealmente, precisam ter os três sistemas para garantir que o software se comporta como esperado.

Desenvolvedores mobile também têm azar. Android dá para fazer no Windows ou Linux, mas para desenvolver para a App Store da Apple é preciso ter Mac. Não tem como escapar disso, e boa sorte esperando a Apple liberar suas ferramentas para outras plataformas.

Profissionais criativos podem escolher entre Windows e OS X. Depende das ferramentas. Se você usa Adobe, qualquer um serve bem, mas provavelmente vai querer uma workstation personalizada. Até a Apple remodelar o ridículo Mac Pro, não encontrará o melhor hardware pelo preço na Apple. O iMac 5K atual é bom, mas acima disso não tem opção. Por exemplo, se precisar de 2 GPUs NVIDIA Titan ou Quadro rodando em paralelo, a Apple não vai ajudar.

Se o fluxo de trabalho exige Final Cut Pro, Logic Pro, Motion 5, a melhor opção disponível é o iMac 5K.

Eu não sou mais desenvolvedor em tempo integral. Divido meu tempo gerindo uma empresa, fazendo apresentações, experimentando tecnologia e pesquisando. Meu setup ideal seria um MacBook Pro. Mas estou me forçando a viver fora do ecossistema Apple, e dói. Meu lado desenvolvedor web fica feliz no Linux (Manjaro GNOME é meu favorito atualmente). Mas quando o lado criativo precisa de ferramentas, Gimp, Inkscape, Kdenlive simplesmente não chegam lá. Estou muito acostumado com Photoshop, Illustrator, Final Cut/Premiere, Motion 5/After Effects. O LibreOffice Impress é terrível para apresentações complexas, e os slides baseados em HTML/JS servem para coisas simples. Tente fazer gráficos e animações sérias lá e você vai sofrer demais.

Se você é um criativo, precisa de telas com calibração de cores (espaço Adobe RGB), precisa de poder de processamento bruto para renders rápidos e pós-processamento avançado. Editores de vídeo Adobe vão preferir Windows. Editores Final Cut são bem atendidos nos Macs, mesmo que o sistema de refrigeração dos novos MacBook Pros seja terrível:

E se você é editor de vídeo em tempo integral, pode pagar tanto por um PC quanto por um Mac de ponta, então a disputa fica pequena.

Se você é editor de vídeo com orçamento limitado, não vai ter um bom fluxo de edição 4K no Linux, ponto. O suporte para explorar o potencial total das GPUs modernas é fraco, não há bom suporte a Cuda ou OpenCL, e a maioria das ferramentas de edição não os utiliza. O Blender — que é primariamente uma ferramenta de modelagem 3D e animação — é considerado uma das melhores ferramentas de edição de vídeo disponíveis no Linux, o que já diz muito. O estado lamentável do suporte a GPU no Linux compromete o uso criativo. A única outra ferramenta de edição não-linear que consegue atingir fluxos de trabalho profissionais é o LightWorks, que não é open source, requer os binários proprietários da NVIDIA e custa dinheiro.

Se for por esse caminho, provavelmente é melhor ficar com Windows ou OS X por enquanto.

Conclusão

Me perdi um pouco no meio do caminho, mas a conclusão é simples:

• O WSL ainda não chegou lá. Precisamos esperar mais algumas atualizações. Quando você ouvir que melhoraram a abstração do sistema de arquivos em algumas ordens de magnitude, aí sim vale tentar de novo. E lembre-se que existem toneladas de issues abertas, então os resultados variam muito.
• Se você é desenvolvedor web, está seguro em qualquer distro Linux.
• Se você é um profissional misto, precisando tanto de ferramentas de desenvolvimento quanto de ferramentas criativas, use Mac ou Windows 10 com uma distro Linux totalmente virtualizada.
• Se é gamer, Windows.
• Se é profissional criativo em tempo integral, tanto Macs quanto PCs servem bem.

Por enquanto vou ficar com meu Dell XPS rodando Windows 10 e Manjaro GNOME no Virtualbox. O Virtualbox é rápido o suficiente para não prejudicar meu fluxo de trabalho. E as ferramentas criativas conseguem aproveitar os núcleos CUDA da minha NVIDIA sem problema, então consigo renderizar no Blender e fazer o Premiere processar vídeo 4K em tempo razoável.

Já fazem 3 meses desde que postei minhas impressões iniciais sobre a feature mais importante do Windows 10 Anniversary Edition: o Bash no Windows. Minha conclusão na época foi que ainda não estava pronto pra produção.

Minha conclusão agora, em 26 de julho, é que finalmente está usável o suficiente pra desenvolvedores web, particularmente pra desenvolvedores Ruby que sempre sofreram com a falta de suporte no Windows.

O processo de instalação é o mesmo. Você precisa estar inscrito no programa Windows Insider, esperar pelo menos um dia se for sua primeira vez. Habilite o Fast ring de updates, instale a edição Preview pelo Windows Update normal e então ligue a feature “Windows Subsystem for Linux (Beta)”.

Da última vez eu estava testando Windows 10 sobre Virtualbox sobre Ubuntu 14.04 num notebook Dell Inspiron (i7 com 8 cores e 16GB de RAM). Estava lentíssimo, não recomendo de jeito nenhum. Agora voltei pro meu confiável Macbook Pro 2013 com 16GB de RAM e SSD rodando VMWare Fusion, e o Windows 10 voa aqui. Super recomendado.

Depois de fazer tudo isso, você pode iniciar o “Bash on Ubuntu on Windows” (que nome enorme). A primeira boa surpresa é que ele pede pra você registrar um novo nome de usuário em vez de cair direto no Root. Como falei no post anterior, é boa prática criar um novo usuário e adicionar ao grupo sudoers, e é isso que ele faz. Então você pode instalar pacotes usando “sudo apt-get install”.

Você deveria seguir meu post anterior pra ver todos os pacotes e configurações que eu normalmente faço numa máquina Linux de desenvolvimento.

RVM agora funciona! Consegui instalar Ruby 2.3.1 via RVM sem nenhum problema.

Consegui dar git clone num pequeno projeto Rails e rodar bundle install direitinho. Todas as gems foram baixadas, extensões nativas compilaram sem nenhuma falha.

Algumas coisas ainda não funcionam. Por exemplo, você não vai conseguir terminar a instalação do Postgresql 9.3. Ele vai baixar e instalar, mas o setup do cluster falha, como você pode acompanhar nessa thread de issue.

Mas você não precisa ter tudo instalado sob o Ubuntu, dá pra usar o Postgresql for Windows nativo e editar seu config/database.yml apontando pro server 127.0.0.1 e porta 5432. No lado do Ubuntu, basta instalar o libpq-dev pra que a gem pg consiga compilar suas extensões nativas e pronto.

Serviços menores como Memcached ou Redis instalam direitinho com apt-get, mas eles não vão dar auto-start via Upstart. Você pode iniciá-los manualmente e usar algo como Foreman pra controlar os processos. Os dois sobem e funcionam bem o suficiente, então dá pra testar caching nos seus projetos Rails e também testar workers Sidekiq.

Eu sei que ainda é um Preview, então ainda vêm correções de bug e possivelmente algumas features novas até o release final de agosto. O que mais me incomoda é que todo comando que rodo com sudo demora alguns segundos pra começar. É irritante, mas funciona no final.

Node.js 6.3.1 instala e roda com sucesso. Consegui dar npm i e node server.js no repositório de exemplo Node do Openshift.

Crystal 0.18.7 instala com sucesso e compilou meu projeto Manga Downloader direitinho. Rodou meu teste de performance embutido em 15 minutos. A performance é modesta, mas executa corretamente até o fim. (E sim, Crystal agora também roda no Windows!).

Go 1.6 funciona. Só dei um go get pra instalar o Martini e rodei o simples server “Hello World”. Compila, inicia e executa rapidíssimo como esperado.

Infelizmente, Elixir 1.3.1 trava, ainda não sei por quê.

$ iex
Crash dump is being written to: erl_crash.dump...done
erl_child_setup closed

Na real, o próprio Erlang trava só de tentar rodar erl. Nenhuma das ferramentas Elixir funciona como consequência. Sem iex, sem mix. O engraçado é que estava funcionando no Preview inicial. Então ou é algo do novo Preview ou algo dos releases mais novos do Erlang. Existem issues abertas sobre esse problema, então vamos torcer pra ser corrigido logo.

“O Melhor Ambiente para Rails no Windows”

Eu tenho esse post bem antigo de 2009 pra guiar desenvolvedores presos no Windows que precisam implementar projetos Rails. O primeiro conselho é evitar Ruby for Windows. Eu realmente louvo os esforços de grandes desenvolvedores como o Luis Lavena, que investiu muito tempo pra fazer aquilo funcionar bem o suficiente. Mas, infelizmente, a realidade é que Ruby foi feito pra ambientes Linux, ele se conecta a extensões nativas em C que têm um monte de dependências difíceis de disponibilizar no Windows.

Então a melhor opção até agora era instalar Vagrant (via Virtualbox ou, melhor ainda, VMWare) como runtime e usar editores disponíveis no Windows como Sublime Text 3 ou Atom.

Agora você pode evitar a parte de Vagrant/virtualização e usar diretamente o “Bash on Ubuntu on Windows”. É tão completo que dá até pra usar ZSH e instalar dotfiles complexos como o YADR. Dá pra rodar Postgresql for Windows e conectar em localhost:5432 na sua aplicação Rails ou em qualquer aplicação web que precise de Postgresql, por exemplo.

Você pode instalar o ConEmu como um emulador de terminal melhor do que o cmd.exe padrão estupidamente ruim. Siga esse artigo pra acompanhar novidades sobre o suporte ao Bash no Windows. Por enquanto você tem que mudar o hotkey “Ctrl-V” pra outra coisa (“Ctrl-Shift-V”), as setas não funcionam direito no Vim, e dá pra adicionar uma Default Task pro Bash assim: %windir%\system32\bash.exe ~ -cur_console:p

Conclusão

Então, sim, pelo menos a partir dessa versão que testei (instalada em 25 de julho), esse é um “Bash on Ubuntu on Windows” usável e desenvolvedores web de Ruby a Javascript a Crystal a Go podem começar a testar e tentar fazer do Windows 10 Anniversary sua plataforma primária pra desenvolvimento sério baseado em Linux.

Adicione Sublime Text ou Atom (ou Visual Studio, se for sua praia) e você está pronto. Espero que os próximos releases corrijam alguns dos bugs e problemas de performance, mas comparado ao que vimos em abril, é uma melhoria gigantesca.

Parabéns à Microsoft por isso!

E se você quer saber mais detalhes hardcore sobre como o Windows Subsystem for Linux é de fato implementado, eu recomendo essa série de posts no blog do próprio MSDN:

• Windows Subsystem for Linux Overview
• Pico Process Overview
• WSL System Calls
• WSL File System Support

Para conseguir baixar, você precisa atender aos seguintes requisitos:

• Ter um Windows 10 64 bits ativado
• Inscrever-se no programa Windows Insider. Se for sua primeira vez, pode levar até 24 horas para ativar
• Nas configurações do Windows Update, em Opções Avançadas, escolha “Get Started” na opção Insider e também escolha o anel “Fast”. Agora, ao buscar atualizações, o Preview 14316 deve aparecer. Se não aparecer, espere até a Microsoft atualizar sua conta.

Você precisa ter, no mínimo, 10GB de espaço livre na sua partição principal, então tenha isso em mente. Outra observação: se você é como eu e está testando no Virtualbox, lembre que para redimensionar um disco virtual é preciso deletar os snapshots, e o processo de merge pode demorar um tempo ridículo.

Depois de instalado, vá às opções de Desenvolvedor no Painel de Controle “Update & Security” e mude seu perfil para “Developer Mode”. A feature “Bash on Windows” vai aparecer na lista de Windows Features. É voltada apenas para desenvolvedores, não deve ser usada em servidores de produção.

Com o Preview instalado, você deve conseguir abrir o velho cmd.exe (ou qualquer console melhor como o ConEmu) e digitar “bash”. Ele vai pedir para instalar o userland do Ubuntu empacotado pela Canonical. Mais um tempinho. Aliás, o processo todo demora bastante, então reserve pelo menos meio dia. Não faça isso no trabalho :-)

Um problema que esbarrei logo de cara foi que a rede não estava funcionando direito. Alguém identificou que o DNS não estava sendo adicionado em /etc/resolv.conf, então é preciso adicionar manualmente. Basta colocar o DNS do Google (8.8.8.8 e 8.8.4.4) no arquivo resolv.conf e pronto.

Por fim, você cai dentro do bash como usuário root. Se você é um usuário Windows, saiba desde já que rodar como root é inseguro e uma péssima prática. Não faça isso.

A primeira coisa que você precisa fazer é criar manualmente um usuário Linux sem privilégios e adicioná-lo ao grupo sudo, como Andrew Malton publicou primeiro:

useradd new_username -m -s /bin/bash 
passwd new_username
usermod -aG sudo new_username

Aí você pode logar nesse shell de usuário com su - [seu usuário] sempre que quiser!

A partir daqui, podemos assumir que é um Ubuntu 14.04 comum e você deve conseguir seguir o meu post bem antigo sobre como configurar um ambiente Ubuntu para desenvolvedor, ou qualquer outro tutorial pelo Google. Os pacotes básicos de desenvolvimento que sempre instalo primeiro rodam normalmente:

sudo apt-get install curl build-essential openssl libcurl4-openssl-dev libreadline6 libreadline6-dev curl git-core zlib1g zlib1g-dev libssl-dev libyaml-dev libsqlite3-dev sqlite3 libxml2-dev libxslt-dev libgmp-dev autoconf libc6-dev ncurses-dev automake libtool bison subversion redis-server libhiredis-dev memcached libmemcached-dev imagemagick libmagickwand-dev exuberant-ctags ncurses-term ack-grep git git-svn gitk ssh libssh-dev

sudo dpkg-divert --local --divert /usr/bin/ack --rename --add /usr/bin/ack-grep

Isso te dá toda a toolchain essencial de compilação além de algumas ferramentas de linha de comando bem conhecidas como o ack (muito melhor que o grep). Também adiciona Redis e Memcached. Todos rodam.

Como boa prática, adicione o seguinte ao arquivo de configuração /etc/bash.bashrc:

export LANGUAGE=en_US.UTF-8
export LANG=en_US.UTF-8
export LC_ALL=en_US.UTF-8

E depois disso, configure também o locale para UTF-8:

sudo locale-gen en_US.UTF-8
sudo dpkg-reconfigure locales

Só para esquentar um pouco, podemos começar com uma das coisas que eram impossíveis no Windows: ter uma instalação estável de Ruby. Para isso, dizem que o RVM não funciona (assim como o ZSH também não funciona devido a problemas de /dev/pts e symlinks neste preview, veja mais abaixo). Mas o RBENV funciona! Você precisa instalá-lo primeiro e depois o plugin ruby-build:

Curiosamente, demora bastante para terminar e durante o processo o uso de CPU vai às alturas. Instalar Go é ainda mais demorado! Algo continua instável por baixo dos panos, porque a CPU não deveria ficar a 100% por tanto tempo.

Se eu checar quanta memória tenho no sistema fica mais claro:

root@localhost:/mnt/c/Users/fabio# free -h
             total       used       free     shared    buffers     cached
Mem:          1.0G       342M       664M         0B         0B         0B
-/+ buffers/cache:       342M       664M
Swap:           0B         0B         0B

Não tenho certeza se esse valor de memória é meio “hard-coded”, já que muita gente está reportando os mesmos “664M” livres independente do que esteja rodando. Mas tem algo incompleto aqui. Swap também é zero e você não consegue adicionar nenhum, pelo que pude testar. Swapon, fallocate, nada disso funciona ainda.

root@localhost:/mnt/c/Users/fabio# swapon -s
swapon: /proc/swaps: open failed: No such file or directory

root@localhost:/mnt/c/Users/fabio# fallocate -l 4G swapfile
fallocate: swapfile: fallocate failed: Invalid argument

Cheguei a tentar criar um swap file usando dd em vez de fallocate e adicionar ao /etc/fstab, mas não funcionou:

root@localhost:/mnt/c/Users/fabio# free -m
             total       used       free     shared    buffers     cached
Mem:          1006        342        664          0          0          0
-/+ buffers/cache:        342        664
Swap:            0          0          0

root@localhost:/mnt/c/Users/fabio# cat /etc/fstab
LABEL=cloudimg-rootfs   /        ext4   defaults        0 0
/swapfile       none    swap    sw      0 0

Então parece mesmo que a memória está “hard-coded”. Acompanhe esta issue #92 se quiser ver como vai evoluir.

Mas pior que isso, a memória compartilhada tem limites muito baixos e comportamento estranho. O Postgresql instala mas não sobe de jeito nenhum:

root@localhost:/mnt/c/Users/fabio# pg_createcluster 9.3 main --start
Creating new cluster 9.3/main ...
  config /etc/postgresql/9.3/main
  data   /var/lib/postgresql/9.3/main
  locale en_US.UTF-8
FATAL:  could not create shared memory segment: Invalid argument
DETAIL:  Failed system call was shmget(key=1, size=48, 03600).
HINT:  This error usually means that PostgreSQL's request for a shared memory segment exceeded your kernel's SHMMAX parameter, or possibly that it is less than your kernel's SHMMIN parameter.
        The PostgreSQL documentation contains more information about shared memory configuration.
child process exited with exit code 1
initdb: removing contents of data directory "/var/lib/postgresql/9.3/main"
Error: initdb failed

E se tentamos expandir o limite SHMMAX, é isso que acontece:

root@localhost:/mnt/c/Users/fabio# sysctl -w kernel.shmmax=134217728
sysctl: cannot stat /proc/sys/kernel/shmmax: No such file or directory

root@localhost:/mnt/c/Users/fabio# echo 134217728 >/proc/sys/kernel/shmmax
bash: /proc/sys/kernel/shmmax: Operation not permitted

Então, sem Postgresql por enquanto. Algumas pessoas que conseguiram completar a instalação do Go Lang (eu desisti depois de muito tempo esperando o apt-get terminar) reclamaram que o Go também quebrou nos requisitos de memória compartilhada. Acompanhe a Issue #32 e a Issue #146 para ver se alguém consegue fazer rodar.

Também tentei instalar o Node.js. Sem sorte com a instalação dos pacotes:

curl -sL https://deb.nodesource.com/setup_5.x | sudo -E bash -
...
E: dpkg was interrupted, you must manually run 'sudo dpkg --configure -a' to correct the problem.
Error executing command, exiting

O NVM instala, mais ou menos, com vários erros no git:

...
error: unable to create file test/slow/nvm run/Running "nvm run 0.x" should work (No such file or directory)
error: unable to create file test/slow/nvm run/Running "nvm run" should pick up .nvmrc version (No such file or directory)
error: unable to create file test/slow/nvm use/Running "nvm use iojs" uses latest io.js version (No such file or directory)
error: unable to create file test/slow/nvm use/Running "nvm use node" uses latest stable node version (No such file or directory)
error: unable to create file test/slow/nvm use/Running "nvm use v1.0.0" uses iojs-v1.0.0 iojs version (No such file or directory)
error: unable to create file test/slow/nvm use/Running "nvm use" calls "nvm_die_on_prefix" (No such file or directory)

E é isso que acontece se eu tento instalar a versão mais recente:

akitaonrails@localhost:~/.nvm$ nvm install 5.10.1
Downloading https://nodejs.org/dist/v5.10.1/node-v5.10.1-linux-x64.tar.xz...
######################################################################## 100.0%
tar: bin/npm: Cannot create symlink to '../lib/node_modules/npm/bin/npm-cli.js': Invalid argument
tar: Exiting with failure status due to previous errors
Binary download failed, trying source.
######################################################################## 100.0%
Checksums empty
tar: bin/npm: Cannot create symlink to '../lib/node_modules/npm/bin/npm-cli.js': Invalid argument
tar: Exiting with failure status due to previous errors
Binary download failed, trying source.
Detected that you have 1 CPU thread(s)
Number of CPU thread(s) less or equal to 2 will have only one job a time for 'make'
Installing node v1.0 and greater from source is not currently supported

A Issue #9 aponta para a falta de suporte a symlinks.

Outra coisa muito chata é a falta de Pseudo-Terminais (/dev/pts), que é possivelmente uma das razões do ZSH não funcionar. Acompanhe a Issue #80.

Você também deve conseguir copiar suas chaves SSH privadas para “.ssh” e começar a clonar do Github ou dar git push para o Heroku rapidinho.

akitaonrails@localhost:~$ ssh-keygen  -t rsa
Generating public/private rsa key pair.
Created directory '/home/akitaonrails/.ssh'.kitaonrails/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/akitaonrails/.ssh/id_rsa.
Your public key has been saved in /home/akitaonrails/.ssh/id_rsa.pub.
The key fingerprint is:
f8:16:b1:be:85:31:0c:71:f8:c2:d3:72:ab:48:42:9a akitaonrails@localhost
The key's randomart image is:
+--[ RSA 2048]----+
|      ...        |
|      .o         |
|     ..o.        |
|  .   =++o       |
| +    .=S.       |
|E . .  o.=       |
|   o . .= .      |
|    . .. o       |
|        .        |
+-----------------+

Pelo menos o Elixir parece funcionar:

akitaonrails@localhost:~$ iex
Erlang/OTP 18 [erts-7.3] [source-d2a6d81] [64-bit] [async-threads:10] [hipe] [kernel-poll:false]

Interactive Elixir (1.2.3) - press Ctrl+C to exit (type h() ENTER for help)
iex(1)> defmodule HelloWorld do; def say(name) do; IO.puts("Hello #{name}"); end; end
iex:1: warning: redefining module HelloWorld
{:module, HelloWorld,
 <<70, 79, 82, 49, 0, 0, 5, 240, 66, 69, 65, 77, 69, 120, 68, 99, 0, 0, 0, 147, 131, 104, 2, 100, 0, 14, 101, 108, 105, 120, 105, 114, 95, 100, 111, 99, 115, 95, 118, 49, 108, 0, 0, 0, 4, 104, 2, ...>>,
 {:say, 1}}
iex(2)> HelloWorld.say("Fabio")
Hello Fabio
:ok

Calma lá…

akitaonrails@localhost:~$ mix new ex_test
** (ErlangError) erlang error: :terminated
    (stdlib) :io.put_chars(#PID<0.25.0>, :unicode, [[[[[[[] | "\e[32m"], "* creating "] | "\e[0m"], ".gitignore"] | "\e[0m"], 10])
    (mix) lib/mix/generator.ex:26: Mix.Generator.create_file/3
    (mix) lib/mix/tasks/new.ex:76: Mix.Tasks.New.do_generate/4
    (elixir) lib/file.ex:1138: File.cd!/2
    (mix) lib/mix/cli.ex:58: Mix.CLI.run_task/2

Você vai encontrar mais informações no pseudo-projeto que a Microsoft abriu no Github para acompanhar as Issues de testers como eu. Dá para acompanhar a lista de issues abertas e fechadas por lá. Você vai ver muita coisa que funciona, mas também muita outra que não vai funcionar até sair uma nova release que conserte tudo o que mencionei aqui.

Conclusão

Então, o “Bash on Windows” é um bom ambiente de desenvolvimento para usuários Linux terem sobre o Windows?

No Preview 14316, ainda não. A palavra-chave aqui é “ainda”. Está tomando forma de um jeito legal e, se conseguirem realmente corrigir todas as issues abertas até agora, vai ficar muito utilizável muito rápido.

Ainda faltam controles de memória decentes, suporte bem implementado de pseudo-terminal, limites configuráveis de memória compartilhada e symlinks funcionando. Falta também o upstart do Ubuntu, para que serviços como Redis ou Memcached (que instalei e rodam) subam sozinhos quando eu inicio o ambiente. Hoje eles não voltam sozinhos depois que reinicio a máquina.

Algumas pessoas chegaram a conseguir enganar o X11 e rodar apps GUI como Firefox e até XFCE sobre esse ambiente, então é realmente promissor. Essa ideia funciona.

Uma vez que essas issues sejam resolvidas, sim, acredito que estamos mais perto do que nunca de finalmente usar Windows como um ambiente de desenvolvimento viável e completo. Vamos ver se até o Anniversary Release do Windows 10 em junho vamos ter uma instalação estável de Ubuntu.

Uma coisa que acho que fizeram muito errado foi amarrar o Linux Subsystem à instalação do Windows 10. Devia ter sido um instalador separado, para que o time pudesse liberar atualizações de build sem ter que empacotar tudo junto com o sistema operacional inteiro.

Se você estava pretendendo migrar para Windows para seus desenvolvimentos baseados em Linux, ainda não. Segure os cavalos um pouco mais.

Ontem foi um dia histórico para a Microsoft. Na minha visão pessoal, pode ter sido um divisor de águas. Desde ontem venho tentando pensar em como deixar isso registrado para a posteridade.

Prólogo - 1995 a 2005, 1a Década

Digo isso para nós, desenvolvedores de software. Já conhecemos alguns divisores assim na história: o lançamento do Turbo Pascal em 1983, o do Visual Basic em 1991, o do Java em 1995, as primeiras distros de Linux como o Slackware a partir de 1993, o lançamento do OS X em 2000 e a transição de PowerPC para Intel em 2005.

Os anos 80 e 90 foram conturbados, uma época de crescimento acelerado em que tudo ficava obsoleto muito rápido. Numa década, de 1989 até 1999, passei de Basic para dBase, Clipper, Fox Pro, Visual Basic, Delphi, Java, multimídia (Flash, Director/Shockwave) e Internet (HTML, Javascript, ASP, PHP, Perl). Nunca vi uma década andar tão rápido. Fui de um XT de 4 MHz para um Pentium III de quase 1 GHz nesses dez anos.

Chegamos ao fim do século no ápice da Bolha da Internet, tivemos o 11 de Setembro em 2001 e o crash. Mas a Internet chegou para ficar, e os dispositivos começaram a despontar com os Palms e iPods. Em 2001 a Microsoft lançou o Windows XP e passaria a década seguinte carregando esse legado nas costas.

Um ano antes, a pequena Apple iniciava seu levante com os novos iMac, iBook e iPod, além do OS X baseado em BSD UNIX. Um passo de cada vez, ela montava um sistema pensado tanto para consumidores quanto para desenvolvedores, a promessa da NeXT ganhando forma uma década depois de sua concepção.

Então, em 2005, a Apple forjaria aliança com uma das mais antigas parceiras da Microsoft, a Intel, e finalmente os Macs rodariam no mesmo processador que o Windows, dando um salto estratosférico em adoção. E isso abria mais uma porta: como o OS X foi feito agnóstico de processador, era questão de tempo até rodar em chips ARM, menores e mais eficientes. Foi o que aconteceu em 2007 com o lançamento do iPhone. O resto é história.

2005 a 2015 - 2a Década

Enquanto isso, a Microsoft ficou para trás. Fracassou na promessa do Windows Vista, entregou um Windows 7 competente e emendou no controverso Windows 8. Só com o Windows 10, anunciado no fim de 2014, é que as coisas começaram a mudar. E os efeitos da morte de Steve Jobs, no fim de 2011, ficavam mais aparentes: a Apple parou.

De 2011 até hoje, só tivemos novas versões. Nada significativo, nada novo. O último grande iPhone foi o 5, de 2012. O último grande felino do OS X foi o Mountain Lion, de 2011. Enquanto isso, o Google passou à frente no mundo mobile quando o KitKat saiu em 2013, para mim a primeira versão do Android em pé de igualdade com o iOS.

De 1999 até 2005, no geral, o desenvolvedor de software enterprise tinha duas opções: Java e .NET. O PHP tinha boa adoção, mas na maioria como customização de Wordpress e Magento, longe da mesma categoria de Java ou .NET; o resto era nicho. A partir de 2006 surgiu uma nova geração de desenvolvedores para a chamada Web 2.0, o mundo pós-Google, com SEO, UX, iterações rápidas e Agilidade com “A” maiúsculo. Foi ali que Ruby, Python e depois Node aceleraram exponencialmente.

A partir de 2010, o mundo mobile acelerou, e em particular um tipo de desenvolvimento integrado: baseado em “Cloud”, em que uma “app” nativa fala com serviços em servidores remotos, sobretudo da Amazon AWS, que havia estreado não fazia muito tempo, em 2006.

A Microsoft ficou de fora desse movimento e gastou os dez anos seguintes correndo atrás, na ressaca do Vista. Manteve a liderança em mercados puramente enterprise, com licenças de SQL Server e Office, mas à margem do “cutting-edge” do desenvolvimento de software.

Na verdade, eu diria que o divisor de águas veio em 2013, com a saída de Ballmer e o fim da “Era Estendida de Gates”, abrindo espaço para a entrada de Satya Nadella. A Microsoft é uma entidade gigante, muitos cérebros já pesquisavam isso fazia anos, e boa parte só apareceu agora. Mas falo em “Eras” num sentido simbólico: o fim da cultura Highlander da Microsoft, o “there can only be one”.

A profecia de 1995, de que a Internet destruiria a hegemonia do Windows, se cumpriu. E chegamos ao mundo pós-Moore, em que a computação ficou acessível e ubíqua. Pense nisso: em 1995, ter um cluster de “super” computadores para computação distribuída de alto processamento era coisa de universidade ou grande corporação. Hoje, você cria um cluster de quantas dúzias de máquinas quiser no EC2 por um mês pelo preço de um videogame.

Fui usuário de DOS desde 1988, mudei para o Windows 95 assim que saiu e passei quase dez anos desenvolvendo primariamente em Windows, em ambiente corporativo. Fui de Visual Basic para ASP e para .NET ao mesmo tempo que mexia com Java e PHP. Mas eu queria poder usar Perl, PHP, Python e Ruby nativos de Linux, sem abrir mão de Office e Photoshop.

A resposta que já esperávamos era o OS X. Com o lançamento do Tiger, a coisa ficou séria. Eu mesmo experimentei com um Mac Mini G4 em 2004. Era excepcional ter uma usabilidade muito melhor que a do Windows XP e acesso a tudo de UNIX numa única máquina.

Quando a Intel lançou o Core Duo e depois o Core 2 Duo de 64 bits, e o Tiger passou a rodar em Intel em 2005, não havia o que pensar: era hora de migrar. Passaria a década seguinte num ambiente puramente OS X, desenvolvendo em outro tipo de plataforma, com outras ferramentas e outra cultura. Foi toda a minha história com Ruby e OS X nesses dez anos, que vocês conhecem bem se acompanham o blog.

2015 em diante, Epílogo

2015 chegou, quatro anos depois da morte de Steve Jobs. Foi um intervalo importante, porque deu tempo para as plataformas não-Mac se equipararem e superarem o OS X em muitas áreas. Estamos definitivamente na Era do Software como Serviço. Não “compramos” mais nada, “assinamos” serviços.

Passamos da Era Pós-PC. Passamos da Era do Smartphone. Estamos na Era dos Serviços, em que tudo é um serviço. Nossa identidade é um perfil do Facebook, nossa voz é o Zap Zap, e tudo o que fazemos gera dados. Estamos na Era do Big Data, um monte de dados inúteis que nenhum SQL Server do mundo dá conta de manter.

Precisamos de coisas novas para lidar com esse paradigma: Cassandra, Riak, Hadoop, HBase, Spark, Elasticsearch, Go, Rust, Elixir. Todos eles “rodam” em Windows, mas alguém precisa gastar tempo fazendo ports, criando patches de compatibilidade e empacotando instaladores. E o principal: a maioria dos desenvolvedores dessas tecnologias está em Linux ou em OS X, quase ninguém desenvolve essa nova geração de ferramentas dentro do Windows. Todos usam Emacs, Vim ou Sublime Text, quase ninguém quer o Visual Studio.

E isso volta ao começo do post: é uma nova Era para a Microsoft. Ela passou os últimos dez anos correndo atrás e, pela primeira vez, parece ter chances reais de dar a volta por cima e voltar a ser relevante para o desenvolvedor não-.NET.

Para isso, duas coisas aconteceram ontem.

2016 - O Ano do Linux no Desktop

Primeiro, o anúncio de que o “Bash está chegando ao Windows”. Que na prática é muito mais do que o Bash: é uma parceria com a Canonical, que já vinha se desenhando desde o anúncio do SQL Server rodando em Linux. Na prática, é um subsistema Linux rodando em paralelo à kernel do Windows, traduzindo chamadas de sistema Linux para Windows.

A ideia original veio do falecido Projeto Astoria, ou Windows Bridge for Android, que na época queria permitir apps Android rodando em Windows. Tecnicamente o Android é um tipo de Linux, então o salto para ontem foi curto.

Assim, será possível pegar um binário feito para Ubuntu e rodá-lo no Windows sem modificar nada.

Desde que começamos a desenvolver com Ruby, muita gente que usa Windows queria rodar Ruby nativamente. Existe uma distribuição, mas não é boa, e a culpa não é dos mantenedores. O Ruby, assim como Python e PHP, foi feito para funcionar em Linux.

Para portar para Windows é preciso fazer “wrappers”, e ainda falta um ambiente com compiladores como o GCC para compilar pacotes de extensões. Tudo isso é trivial no Linux e uma dor de cabeça no Windows. Não valia o trabalho, então a única saída era rodar uma máquina virtual (como o VirtualBox) com algo como o Vagrant para facilitar e usar o Ruby de Linux de verdade.

Tudo de Linux que “funciona” em Windows, seja Python ou PHP, nunca funcionou 100%, e a gente simplesmente se acostumou com isso.

O que a Microsoft vai lançar no Anniversary Update é uma camada muito fina de tradução no nível mais baixo, e não uma máquina virtual ou um hypervisor: de uma kernel Linux “virtual” para a kernel do Windows. Tudo vai pensar que está rodando em Linux. É o que o projeto Wine tenta fazer para rodar aplicações Windows no Linux, só que ao contrário. Também é diferente do Cygwin, que exige recompilar tudo do Linux para ter um ambiente semi-Linux sobre o Windows.

Provavelmente não haverá ambiente gráfico secundário num primeiro momento, então nada de X, nada de GNOME ou KDE. E nem precisa: estamos num mundo Web, nosso ambiente gráfico agora é HTML e Javascript, e Chrome e Firefox já existem nativos no Windows. Para coisas como compilar gems com extensões nativas, até o GCC vai funcionar. É exatamente o mesmo binário, no mesmo ambiente, com tudo a que estamos acostumados no UNIX. Ter Bash e SSH no Windows é só a ponta do iceberg.

O segundo anúncio é o lançamento das ferramentas Xamarin de graça e como open source! A Microsoft adquiriu a Xamarin, de Miguel de Icaza, há pouco tempo. Eles desenvolveram o .NET open source por pura engenharia reversa, reimplementando tudo em código aberto, e agora a Microsoft fez a coisa inteligente: além de comprá-los, abriu as ferramentas. A última coisa que ainda prendia um desenvolvedor no Mac era precisar do Xcode, que já vem no OS X, para desenvolver para iOS. Agora dá para fazer isso no Windows de graça.

Portanto, a conta ficou bem mais simples. O Windows 10 é a primeira versão respeitável de Windows desde o breve intervalo do 7. Vamos esquecer que o 8 existiu, do mesmo jeito que já esquecemos do Vista. O XP finalmente morreu, levou mais de uma década, junto com os horrorosos Internet Explorer 6, 7 e 8. O Google nos fez o favor de tornar o Chrome ubíquo, e serviços como o Facebook forçaram os usuários a migrar mais rápido.

Com o Windows 10 Anniversary Update, provavelmente vamos poder fazer:

apt-get install build-essential
\curl -sSL https://get.rvm.io | bash
rvm install 2.3.0
bundle install

E tudo deve funcionar.

No mesmo ambiente, ainda vamos poder usar o Xamarin Studio e, com um pouco de esforço para relembrar os músculos de C#, criar apps iOS e Android. Vamos poder usar o Office 365 nativo, todas as ferramentas mais recentes do Adobe CS6 e até jogar The Division, tudo na mesma máquina.

De uma só vez, o Windows 10 vira a escolha com o melhor custo-benefício: comodidade de uso, opções de desenvolvimento e hardware competente na forma de Surface Book, Lenovo Yoga 3 e Razer Blade Stealth, que finalmente alcançaram e passaram o lendário acabamento dos MacBook.

2016 é finalmente o famigerado Ano do Linux no Desktop, só que não do jeito que o pessoal de Free Software gostaria. Não dá para ter tudo.

No dia 4/2 a Microsoft anunciou o módulo HttpPlatformHandler. Então, em 9/2, o conhecido blogueiro Scott Hanselman fez um blog post explicando como poderíamos usar esse módulo para servir uma aplicação Rails atrás do IIS 8. Depois de um comentário que fiz ele atualizou para demonstrar como servir uma aplicação Rails em cima do JRuby.

O HttpPlatformHandler é um módulo que há anos estava faltando no IIS, e não entendo a razão de porque tanta demora. Todo servidor HTTP tinha um módulo desses por padrão (Apache, NGINX, etc), menos o IIS. E esse módulo é importante para poder repassar uma requisição HTTP do IIS para uma aplicação web que responde HTTP atrás dele (basicamente qualquer coisa que não é PHP, de Python/WSGI a Java). Antes disso era necessário usar um módulo desenvolvido por terceiros ou uma combinação de ARR (Application Request Routing, que é um balanceador de carga) e URL Rewrite, que é tudo menos algo “plug-and-play”.

Minha “teoria da conspiração” é que a Microsoft obviamente gostaria que o IIS fosse o único servidor de aplicação e qualquer coisa dinâmica deveria rodar dentro do controle de seus Application Pools, o que era verdade para ASP antigo e .NET. O resto ficaria relegado ao antigo (obsoleto) esquema de sub-processo por requisição de CGI/FastCGI (que é extremamente ineficiente).

Na verdade não precisamos do IIS se quisermos rodar uma aplicação Rails, Java ou qualquer outro no Windows: basta desabilitar o IIS (para não ocupar a porta 80) e fazer o JRuby on Rails/Puma ou Java/JBoss/Tomcat/etc subir na porta 80 e pronto. Por outro lado poderíamos querer executar uma aplicação ASP.NET MVC e outra em Java/JSF na mesma máquina, e aí começa a ficar mais complicado.

Um módulo de proxy-reverso é a solução nesses cenários: agora é possível executar aplicações em quaisquer linguagens na mesma máquina, todas coordenadas com o IIS 8, repassando a requisição quando ele mesmo não tiver como responder. Com a proposta do Azure de querer ser uma plataforma para muitas linguagens e projetos open source, esse componente era muito necessário para colocá-lo em pé de igualdade com NGINX e outros servidores web.

Por que Rails (ou qualquer coisa diferente de .NET) no Windows?

Na realidade é a mesma resposta de “por que Java/Python/PHP/etc” no Windows. Na prática, eu diria que se você precisar muito se manter na plataforma Windows - e existem dezenas de razões legítimas pra isso - mantenha-se na stack do .NET, use ASP.NET MVC (ou o vNext que é o próximo). Faça web services com WCF, faça aplicações desktop com WPF. Muitas soluções corporativas precisam integrar diversos componentes como BizTalk, Exchange, Sharepoint, conectar exclusivamente com endpoints SOAP ou COM+ e nesses casos o melhor é ficar no nativo.

Usar algo diferente de .NET significa não somente mudar de linguagem, mas mudar de sistema operacional e toda uma forma de trabalhar e desenvolver que são completamente diferentes. Linguagens de script como PHP, Ruby, Python, Perl dependem bastante do sistema operacional por baixo. Algumas se esforçaram para oferecer mais suporte no Windows, mas eles nunca vão se comportar 100% da mesma forma em dois sistemas operacionais diferentes.

O próprio Technet da Microsoft tem vários artigos detalhando as diferenças (tanto técnicas quanto filosóficas) e se procurar no Google vai achar centenas de artigos (muitos meramente pedantes e trolls, evite-os) detalhando mais sobre essas diferenças, principalmente nos aspectos de segurança.

Extensões nativas precisam ser escritas levando em consideração APIs, chamadas de baixo nível de sistema muito diferentes. Windows e Linux/Unix são animais diferentes, gerenciam memória de formas diferentes, lidam com I/O (sistema de arquivos, rede) de formas diferentes. Daí é necessário programar uma “camada intermediária” que tenta abstrair as duas coisas. PHP é de longe o que tem mais “wrappers” prontos para ambos os sistemas, Python vem na sequência. Ruby não tem histórico de uso no Windows por isso tem menos wrappers.

Existem várias ferramentas do mundo Linux que um desenvolvedor no Windows não está acostumado a usar. Coisas que vão desde coisas simples como um simples wget ou curl até coisas mais complexas como GDB ou DTrace. Por isso mesmo não é simples para um programador Windows migrar para qualquer outra plataforma diferente de .NET.

Mesmo assim, pode ser muito útil saber o básico de algumas linguagens pois daí é possível tirar vantagens de instalar um Wordpress (PHP), ou um Plone (Python) e até mesmo no caso de Rails usar aplicações excelentes como Redmine, Discourse, Spree, FatFreeCRM, e várias outras aplicações de código aberto, sem precisa duplicar esforços e refazê-los em .NET. Ou então usar as excelentes ferramentas que temos para criar CRUDs rápidos usando Rails + Devise + ActiveAdmin por exemplo. Existem várias razões para tirar proveito das excelentes ferramentas do ecossistema Rails que não existem no mundo ASP.NET MVC.

Por essas razões, o Ruby no Windows nunca será tão bom quanto o Ruby no Linux/OS X, nem mesmo PHP ou Perl será tão bom no Windows quanto é no Linux, no mesmo hardware. Um exemplo prático mais notável: Windows não tem o conceito e nem a implementação de fork(), algo essencial para nossos servidores de aplicação Ruby como Unicorn, Puma, Thin, etc. Por isso mesmo, rodar Rails usando o servidor padrão, Webrick, não é aceitável em produção. Ele vai ter um único processo e responder a apenas uma requisição de cada vez, sem possibilidade de responder conexões simultâneas.

Isso dito, no caso específico de Ruby, existe uma ótima solução e é JRuby, que permite executar código Ruby dentro da máquina virtual Java. Em resumo, uma aplicação inteira feita em Ruby on Rails, com pequenas modificações (por exemplo, instalando o driver JDBC pra acessar banco de dados), pode ser executado no ambiente Java, com todas as vantagens que ele oferece como melhor performance e capacidade para multithreading real.

O motivo disso é que Java roda sobre a Java Virtual Machine (JVM) que, como o próprio nome diz, é literalmente uma máquina virtual (de um jeito tosco, pense nele como um VirtualBox, com outro sistema operacional rodando virtualmente). A JVM abstrai completamente o sistema operacional por baixo e é como se fosse um micro-sistema operacional próprio. De fato, já houve a tentativa de se fazer um Java OS inteiro que não necessitaria de um outro sistema como Linux ou Windows pra executar.

Feito isso, podemos colocar uma aplicação Rails, com boa performance, com boa concorrência, integrado com banco de dados como SQL Server ou Oracle, atrás do IIS, rodando lado a lado com aplicações feitas em .NET.

Configurando Rails da forma Correta para Windows

A partir daqui vou assumir que você é um desenvolvedor familiarizado com o ambiente Windows e sabe como usar Web Platform Installer, onde procurar instaladores, não estranha em usar o Command Prompt e sabe como instalar os seguinte componentes básicos:

• IIS 8
• SQL Server 2008 R2
• Java 1.8

E antes de realmente começar precisamos configurar algumas coisas.

No caso de Java, também precisamos antes instalar o Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy que é um tosco arquivo zip cujos arquivos precisam ser manualmente copiados no diretório de policies do JRE:

Depois disso precisamos fazer o SQL Server se ligar à porta TCP 1433. Para isso instale e abra o SQL Server Configuration Manager, habilite o TCP/IP e na tela de propriedades apague o que estiver em “TCP Dynamic Ports” e coloque “1433” em TCP Port. Precisa fazer isso em todos os campos.

Agora, baixe meu código do Github em alguma pasta. Se não for diretamente dentro do C:\inetpub\wwwroot precisa adicionar o usuário IIS_IUSRS para ter acesso a todos os subdiretórios:

A partir de um Command Prompt, entre no diretório do projeto e execute:

jruby -S bundle install

Isso deve instalar todas as dependências que estão listadas no arquivo Gemfile cujas partes mais importantes são:

# Bundle edge Rails instead: gem 'rails', github: 'rails/rails'
gem 'rails', '4.1.9'
# Use jdbcsqlite3 as the database for Active Record
gem 'jdbc-mssql-azure'
gem 'activerecord-jdbc-adapter'
gem 'activerecord-jdbcmssql-adapter'
# ...
gem 'puma'
gem 'jruby-openssl', require: false
# ...
gem 'tzinfo-data', platforms: [:mingw, :mswin, :x64_mingw, :jruby]

As partes importantes:

• Use Rails 4.1 e não 4.2 pois muitas gems ainda não estão totalmente compatíveis até o momento deste post.
• Use drivers JDBC pois estaremos rodando dentro da JVM, e para isso funcionar é necessário um adapter de activerecord.
• Vamos usar Puma como servidor Web em vez do padrão Webrick, que é muito melhor por suportar multi-thread na JVM.
• Precisamos adicionar o pacote jruby-openssl pois o Windows não tem suporte nativo a OpenSSL e também o tzinfo-data pois o Windows também não tem dados de time zones facilmente acessíveis (lembram quando falei das várias coisas diferentes entre sistemas operacionais, estes são exemplos de pacotes pra cobrir buracos desse tipo).

Finalmente, configure uma nova aplicação no IIS dentro do Default Web Site, numa sub-pasta chamada “rails”:

Uma aplicação Rails, por padrão, não é feito para funcionar numa sub-pasta, mas este trecho no arquivo config.ru garante que isso vai funcionar:

Rails.application.config.relative_url_root = '/rails'

map Rails.application.config.relative_url_root || "/" do
  run Rails.application
end

Você vai precisar criar um banco de dados chamado “jruby_demo” ou outro nome que você pode configurar no arquivo config/database.yml. Note que você precisa modificar também o usuário e senha nesse arquivo para conseguir se conectar ao seu banco. Nesse caso significa que precisa usar SQL Server Authentication e não o padrão Windows Authentication.

default: &default
  adapter: jdbcmssql
  driver: com.microsoft.sqlserver.jdbc.SQLServerDriver
  url: 'jdbc:sqlserver://localhost;databaseName=jruby_demo'
  username: sa
  password: abcd1234

Se estiver configurado corretamente, agora podemos usar o processo de migrations do ActiveRecord para criar tabelas e subir dados de exemplo, executando o seguinte na linha de comando:

jruby -S rake db:migrate db:seed

Para o IIS 8 conseguir carregar corretamente o JRuby, você precisa configurar o arquivo Web.config:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
        <handlers>
            <add name="httpplatformhandler" path="*" verb="*" modules="httpPlatformHandler" resourceType="Unspecified" requireAccess="Script" />
        </handlers>
        <httpPlatform stdoutLogEnabled="true" stdoutLogFile="rails.log" startupTimeLimit="60" startupRetryCount="5" processPath="c:\jruby-1.7.19\bin\jruby.exe"
                  arguments="-S puma --env production --dir C:\Users\Fabio\Projects\jruby_demo2 -p %HTTP_PLATFORM_PORT%">
            <environmentVariables>
                <environmentVariable name="JAVA_HOME" value="C:\Program Files\Java\jre1.8.0_31"/>
                <environmentVariable name="SECRET_KEY_BASE" value="4a8f4bb5de3637e9fab1f3c8fb6e3a787f60a811d6b36ff8d77a3371a31d19f7a93cfb48597d8263f46748c729b291a0277e6e819a869c4f8edf9445595e5548"/>
            </environmentVariables>
        </httpPlatform>
    </system.webServer>
</configuration>

Preste atenção aos diretórios no arquivo para refletirem onde estão essas coisas na sua máquina, sem isso estar correto, nada vai carregar.

Feito isso, você já deve conseguir carregar a URL “http://localhost/rails” num navegador. Como é JRuby a primeira requisição vai demorar alguns segundos pra carregar (até a JVM terminar de carregar). Mas depois disso vai ficar tudo rápido.

Uma coisa diferente entre o HttpPlatformHandler e um módulo normal de proxy-reverso é que além de fazer o papel de proxy reverso ele também controla o ciclo de vida da aplicação por trás, no caso o JRuby + Puma. E também controla em que porta a aplicação vai ficar escutando (pela variável de ambiente “HTTP_PLATFORM_PORT”).

Sobre aplicações Rails, não se esqueça que todos tem um “SECRET_KEY_BASE” diferente. Sempre gere um novo através da linha de comando jruby -S rake secret.

Se tudo foi feito corretamente, você deveria conseguir ver o seguinte no navegador:

A partir daqui você pode evoluir a aplicação, criar mais models, mais controller, adicionar frameworks CSS como Bourbon (pois o Asset Pipeline vai funcionar corretamente usando o Rhino como runtime Javascript no lugar do V8).

Talvez quem tenha entrado no mercado de tecnologia nesta década não acompanhou a história da década de 90 que culminou com o caso antitruste contra a Microsoft. O “medo” da Microsoft “monopolista” foi substituído por um desdém e ridicularização. Eu sei, eu mesmo uso essa figura de vez em quando, é quase que uma piada universal onde a Microsoft é o mal eterno e todo o resto, as Canonicals, as Apples, os Googles, são os mocinhos do bem.

Ou quase, porque agora é a Apple que está crescendo demais, assim como o Google, que já tem milhares de detratores em vez de fãs. Em breve talvez estaremos vendo um novo caso antitruste: contra um iTunes Store da Apple, por suas práticas “injustas” e “anticompetitivas”. Se isso acontecer, é porque as pessoas não aprendem nada mesmo e estamos fadados a retroceder em vez de progredir.

Em termos de gosto pessoal, garantido pela liberdade individual de expressão, eu desgosto da maioria dos produtos da Microsoft e gosto da maioria dos produtos da Apple. Isso não me impede de entender, respeitar e admirar a capacidade das duas de saírem de uma garagem para o topo do mundo. É o que um mercado livre capitalista possibilita.

E me incomoda quando o sucesso passa a ser visto com o desdém e a inveja dos incompetentes, que no fim acham que têm “direito” a alguma coisa sem ter a mesma capacidade.

Aliás, se eu considero um produto “tecnicamente” melhor ou não é irrelevante. “Melhor” e “pior” são questão de gosto, e o melhor termômetro do mercado é a demanda. Se a demanda é alta, o produto pode ser “bom” mesmo sendo “tecnicamente ruim”.

Ninguém tem “direito” a nada além do que ele próprio produz, e muito menos a algo dos outros de graça. Mas muita gente acha que ninguém pode crescer demais, senão como ficam os competidores menores? Esse tipo de pensamento estatista levou à Grande Depressão de 1929, às Guerras Mundiais e à Crise Financeira de 2008.

Eu acho desorientado juntar o fato de um software ser “aberto”, ou de uma empresa apoiar “software livre”, com movimentos sociais e populistas. Tecnologia não deve se misturar com ideologias socialistas fracassadas. Em outro artigo vou explicar por que Código Aberto (open source) tem tudo a ver com Capitalismo e nada a ver com movimentos sociais politizados.

O texto a seguir é antigo, traduzido do artigo original de Onkar Ghate (Pittsburgh Tribune-Review, 17 de março de 2002), e deve convencê-los do que quero dizer. Larguem os preconceitos (“Microsoft = Mal”) e leiam com raciocínio, porque os argumentos são lógicos. O contexto é de 2002; desde então a Microsoft decresceu bastante e suas qualidades mudaram.

[TRADUÇÃO] Largue o caso antitruste contra Microsoft

O histórico caso de antitruste contra a Microsoft está agora entrando em sua fase final: a determinação da pena da Microsoft. O juiz-presidente, juiz da Corte Distrital dos EUA, Colleen Kollar-Kotelly, deveria ser tão branda quanto legalmente permitido. (Se possível, ela deveria impor uma punição nominal como uma multa de um dólar ou, melhor ainda, jogar o caso fora por completo.)

Para entender o porquê, é preciso entender dois pontos, um geral e um particular. Primeiro, as leis antitruste não são objetivas e são injustas. Em segundo lugar, a Microsoft não é culpada de nenhum crime real. Vamos começar com o primeiro ponto.

As “ações” que as leis antitruste proíbem são vagas, contraditórias, indefinidas. Por exemplo, as leis antitruste proíbem as empresas de criarem “restrições ao comércio”. Mas que ações específicas constituem “restrição ao comércio”? Se, como é feito repetidamente no mundo dos negócios, a companhia assina um acordo exclusivo de distribuição com outra empresa, isso é “restrição do comércio” porque agora outras concorrentes potenciais são excluídas dessa área do mercado? Ou se uma empresa vende um computador para um indivíduo X, isso é “a restrição do comércio” porque empresas de informática concorrentes não podem mais vender a X um computador pois ele tem necessidade de um só? Não – os tribunais têm declarado a empresários – apenas as “restrições” que são “irracionais” são ilegais. Mas que “restrições” específicas são “irracionais”? Nenhuma definição é encontrada na lei, de modo que nenhuma empresa pode saber antes de agir quais ações são legais e quais não são.

Considere um outro exemplo. As leis antitruste proíbem as práticas de comércio “injustas”. Mas, novamente, o que conta como uma prática “abusiva”? É qualquer prática comercial que, por exemplo, provoca falências entre alguns dos concorrentes de uma empresa, porque não conseguiram encontrar uma maneira de competir com os preços baixos da empresa e/ou produtos de qualidade superior? Ou é simplesmente uma prática que a administração no poder desaprova? Mais uma vez, nenhuma resposta pode ser encontrada na lei, por isso é impossível para uma empresa determinar de antemão quais ações específicas a lei proíbe.

Tome um último exemplo. Segundo as leis antitruste, uma empresa pode ser acusada de “preços predatórios”, se define preços inferiores aos dos seus concorrentes, porque os concorrentes poderiam falir como resultado. Ele pode ser acusado de “preços de monopólio”, se define os preços que são considerados muito altos, porque isso é supostamente fraudar os consumidores dos seus rendimentos suados. Mas se do contrário decidir fixar os preços ao nível do dos seus concorrentes – pode ser acusado de “conluio” ou “conspiração”, porque agora ele não está mais “competindo”.

No mundo de pesadelo que é a lei antitruste, toda e qualquer ação pode ser declarada ilegal. Não existem e não podem ser definidos princípios objetivos especificados na lei, e como resultado um empresário não tem como determinar, antes de agir, se a sua ação é legal ou não. Na prática, isso significa que os empresários ficam à mercê do governo. Qualquer momento em que o governo quer enfraquecer uma determinada empresa, pode desencadear as leis antitruste contra ela. Na lógica, uma empresa não tem defesa possível contra a acusação de “restrição ao comércio” ou políticas de comércio “injustas” ou de “preços predatórios”, porque a própria acusação não tem nenhum significado objetivo. As leis antitruste, portanto, dão poder arbitrário ao governo.

O resultado óbvio é que quando, digamos, um burocrata está descontente com uma empresa de sucesso, porque ele falhou em compartilhar (isto é, dar) a sua riqueza ou apoio a programas específicos do governo – ou quando um funcionário do governo acha que a destruição de um poderosa empresa vai ganhar o voto dos cidadãos desorientados que acreditam que o “Grande Negócio” é o seu inimigo – ou quando concorrentes ressentidos, invejosos (como a Netscape, Oracle e AOL no caso da Microsoft) podem convencer os seus representantes do governo a enfraquecer um concorrente superior – o impacto da legislação antitruste desce sobre essa empresa.

Não é por acaso que as empresas mais bem-sucedidas, mais produtivas, mais admiradas da América – Microsoft, IBM, Intel, Wal-Mart, American Airlines, Standard Oil, etc – são as que são submetidas a processos antitruste.

Como uma forma de conceder o poder arbitrário ao governo, as leis antitruste são inconstitucionais e anti-americanas. Como uma forma de punir os bem sucedidos pelo seu sucesso, as leis antitruste são uma perversão da justiça.

Vamos agora, portanto, deixar de lado a lei antitruste, segundo o qual toda a ação de uma empresa poderia ser considerada um crime, e perguntar se de fato a Microsoft é culpada de algum crime.

Quais são as principais acusações contra a Microsoft?

A Microsoft é acusada de concorrência “desleal”. Mas a concorrência se refere ao processo pelo qual as empresas utilizam os seus ativos e pessoal para construir produtos melhores e/ou mais baratos. Assim eles procuram ganhar, através de trocas voluntárias, lucros ainda maiores. Em um mercado livre, não existe concorrência “desleal”. Há apenas concorrentes melhores e piores. Em outras palavras, algumas empresas são melhores do que outras em pesquisa e desenvolvimento, estruturação de longo prazo, acordos de negócios mutuamente benéficos, comercialização de produtos, em manter os bons funcionários felizes e com desafios. A Microsoft, por exemplo, é excelente em todos estes processos – e muitos mais. (A acusação de que a Microsoft não é inovadora é particularmente hipócrita dada a sua contínua atualização e melhorias em seus principais produtos. Mesmo o juiz Jackson teve que admitir este ponto). O fato de a Microsoft ser um dos maiores competidores que o mundo dos negócios tem visto é, em uma nação livre, não um crime, mas uma virtude.

A única “concorrência desleal” que existe é, de fato, a não-competição. Se, digamos, a Máfia ameaça explodir a loja de um comerciante a menos que ele lhe dê um percentual de suas vendas, a máfia não está envolvida na competição, ainda que injusta. Ela está envolvida na coerção – precisamente para impedir o comércio voluntário e mercado livre de operar. Quando a Netscape perde vendas para a Microsoft porque o navegador da Microsoft é melhor e/ou mais barato, a perda da Netscape de vendas não tem qualquer semelhança com “perda” de um lojista de vendas para a máfia. Nunca se deve equacionar voluntário (pessoas optam por comprar produtos da Microsoft) com coagido (se ele tivesse uma escolha, o lojista não “lidaria” com a Máfia).

Em segundo lugar, a Microsoft é acusada de “preços predatórios”. Traduzido em realidade, isto significa que a Microsoft é capaz de praticar preços inferiores aos dos seus concorrentes, como o Netscape. Alguns destes concorrentes, que não podem igualar os preços baixos da Microsoft, perdem fatia de mercado ou vão à falência. Mas é a incrível eficiência e produtividade da Microsoft que permite bater sua competição e ainda assim fazer grandes lucros. Novamente, isto não representa um comportamento criminoso, mas virtude.

Finalmente, a Microsoft é acusada de exercer o “poder de monopólio.” Essa acusação também se baseia em equacionar o voluntário com o forçado.

É verdade que a Microsoft detém uma posição dominante no mercado em alguns segmentos da indústria de software e que alguns dos seus concorrentes saíram do negócio. Mas isso é porque a Microsoft realmente estava vencendo a competição: foi mais inovadora, mais eficiente, tem marketing melhor, e empregou melhor do que outras empresas de software. A Microsoft, em outras palavras, ganhou a sua posição dominante.

E continua a ganhar: ela enfrenta concorrência constante, mesmo se não houver concorrentes reais atualmente em seu mercado. Pois sempre que outro empreendedor descobre uma maneira de produzir software similar a um preço mais barato ou melhor software a um preço atraente (ou alguns inimagináveis produtos que tornam o software atual obsoleto), ele é livre para entrar no mercado da Microsoft. E se ele tiver um bom plano de negócios, será capaz de levantar o capital necessário, mesmo se ele próprio não tem nada: há milhares de investidores de risco procurando o próximo Bill Gates. A posição dominante da Microsoft no setor de software, em outras palavras, deve ser conquistada de novo a cada dia.

Então mais uma vez, a Microsoft está sendo atacada por seu sucesso: na realidade ela não tem poder de monopólio, apenas gestão brilhante.

Os únicos monopólios que podem de fato existir são os criados pelo governo. Somente um governo pode impedir alguém de entrar num mercado e, assim, eliminar a concorrência. Os Correios, por exemplo, são um monopólio. Há pouca dúvida de que a Federal Express (nos EUA) pode oferecer um serviço melhor, mais barato, e ainda obter lucro. Mas o governo forçadamente a impede de entrar nesse mercado. A posição dominante dos Correios no mercado não é conquistada: oferece um serviço ruim, mas por causa da coerção do governo não enfrenta concorrência. A posição dominante de mercado da Microsoft, pelo contrário, é conquistada: ela enfrenta concorrência constante, que continua batendo. Novamente, não equiparem o voluntário com o forçado.

A Microsoft é o epítome do sucesso empresarial americano: ela produz uma enorme riqueza através da inteligência e trabalho duro. Imagine a riqueza que existiria – para cada empresa, para cada empregado, para todos os acionistas, para cada cliente – se todas as empresas na América fossem dirigidas por um Bill Gates. O fato de que não são não deve nos levar a destruir a criação de Bill Gates, mas, mais ainda, admirá-lo e defendê-lo.

Por que a punição da Microsoft deveria ser tão tolerante quanto possível (supondo que o caso não pode ser jogado fora, nesta fase do processo)? Porque as leis antitruste são leis arbitrárias que penalizam a virtude por ser virtude – como as acusações específicas contra a Microsoft revelam claramente.

Dr. Onkar Ghate, PhD em filosofia, é um pesquisador sênior do Instituto Ayn Rand, em Irvine, na Califórnia. O Instituto promove o Objetivismo, a filosofia de Ayn Rand, autora de Atlas Shrugged e The Fountainhead.

Disclaimer

Explicando, não é a intenção dizer que a Microsoft é inocente em tudo. Para isso existe o sistema judiciário e qualquer empresa que se sinta prejudicada ilegalmente tem todo o direito de processar, como já aconteceu inúmeras vezes. Vejam esta lista de processos.

E isso é verdade para qualquer empresa. Uma das funções de um governo é garantir que contratos sejam cumpridos.

A discussão que me interessa no episódio acima é o Sherman Antitrust Act que, em essência, dá carta branca ao governo para litigar qualquer empresa por qualquer motivo. Esse não foi o único processo contra a Microsoft, mas foi um dos mais divulgados. A lei antitruste em si é um mal, assim como regulamentações que dão privilégios que ninguém conseguiria no mercado.

E para quem quer se aprofundar, recomendo ler o Findings of Fact completo sobre o caso, no arquivo da justiça americana. Para entender por que a lei antitruste é um grave problema, comece por este artigo, mas principalmente pelo livro Capitalism: The Unknown Ideal.

AkitaOnRails: Ok. Vamos começar. Primeiramente, obrigado pelo seu tempo. É curioso porque temos como 5 horas de diferença. Você está em Paris agora, mas entendo que é da Argentina. Pode nos contar o que está fazendo atualmente?

Luis Lavena: Sim, curioso mesmo. Agora sou Diretor Técnico de uma agência de design e interação com escritórios em NY e Paris. Meu trabalho é fazer a ponte entre o campo de design e o tecnológico, principalmente no desenvolvimento de aplicações web.

Sou da Argentina, moro lá, família e amigos. Agora me mudei por alguns meses para impulsionar alguns desenvolvimentos e dar os primeiros passos na nova organização.

Sou de uma pequena província chamada Tucumán, na área noroeste da Argentina (1200 km de Buenos Aires, para ser exato).

AkitaOnRails: Incrível. Você já foi ao Brasil? Tem contato com outros Railers da América Latina?

Luis Lavena: Apesar de o Brasil ser tão perto da Argentina, nunca fui lá, o que é uma pena. Tenho vários amigos que moraram lá ao longo dos anos.

Mantenho contato com vários Rubistas e Railers da América Latina, mas principalmente com os da Argentina por causa de vários encontros que tivemos ao longo dos anos em que a lista RubyArg vem funcionando.

AkitaOnRails: Tenho muito interesse em entender como os Railers estão se organizando na Argentina, já que nós, no Brasil, somos uma comunidade em crescimento também. Você vê novos programadores indo direto para Rails ou é o movimento habitual de Java/outros para Rails? As empresas estão adotando, ou Ruby/Rails ainda tem um longo caminho a percorrer por lá também?

Luis Lavena: Bem, há um número enorme de desenvolvedores que vieram de Java e dotNET (principalmente Java) e estão experimentando Rails. Também há muitos desenvolvedores que usam Ruby para tarefas administrativas ou até para criar jogos.
As empresas de desenvolvimento de software ainda precisam adotar Ruby/Rails nos seus negócios. O maior problema é a falta de suporte na forma de empresas como a Sun ou alguns serviços de consultoria para Java — ou mesmo Microsoft.

AkitaOnRails: Voltando ao passado, como você começou na programação em geral? Estudou ciência da computação, ou chegou até lá de outra forma? E, finalmente, como você tropeçou no Ruby e no Rails?

Luis Lavena: É engraçado. Comecei a programar em 1989, brincando com sprites e GOTOs em BASIC num computador Z80.

Oficialmente não terminei minha graduação em CC, porque trabalho e diversão me distraíram. Conheci o Ruby pela primeira vez em 2001, adorei a sintaxe, gostei da sua verbosidade, mas não estava maduro o suficiente para as minhas necessidades, pelo menos não no Windows.

Embora eu tenha usado Python por muitos anos, internamente usava Ruby para gerenciar várias coisas, desde scripts simples até rake tasks que nos ajudavam a construir nossas ferramentas.

Com Rails foi diferente — começamos a procurar alternativas ao Zope e apostamos no Rails naquela época (versão 0.10 ou 0.12, se a memória não me trai).

Posso dizer que não me arrependo da aposta no Rails naquela época.

AkitaOnRails: É muito interessante ver profissionais como você saindo da zona de conforto em direção ao “desconhecido” como Ruby e Rails. A maioria dos programadores é muito defensiva e até agressiva na busca de justificativas para não usar nenhum dos dois. Você se sentiu assim na época? O que te levou ao Ruby?

Luis Lavena: Bem, estou acostumado a mudar de linguagens conforme minhas necessidades.
Considere que nossa primeira escolha foi a era pré-J2EE ou o dotNET. Analisamos o que nos daria melhores soluções a longo prazo e decidimos evitá-los.

As coisas de Java pareciam — e ainda parecem até hoje — caras para os negócios. A Argentina não é um país onde você vai encontrar clientes com orçamentos enormes para cobrar o custo de usar ferramentas desenhadas para outros mercados.

Bancos e similares podem se dar ao luxo de ter tudo rodando com J2EE, mas isso não funciona quando você tenta ser menor e ágil — baseado principalmente em experiências com o fluxo do mercado na Argentina.

AkitaOnRails: É ainda mais desafiador considerando que você decidiu que queria Ruby no Windows, provavelmente não encontrou nada razoável e decidiu atacar o problema você mesmo. Foi assim que aconteceu?

Luis Lavena: Fui obrigado a usar Windows por muitos anos, principalmente relacionado ao desenvolvimento de hardware no campo de transmissão de vídeo. Além disso, sou usuário de BSD e Linux, até brinquei alguns anos com Macs e ultimamente com OSX.

Então essa restrição me forçou a construir a maior parte das minhas ferramentas em torno dessa limitação.
O Ruby me permitiu aproveitar essa limitação sendo expressivo, o que me tornou mais produtivo nessa área.

Ruby não é capaz de lidar com meus requisitos principais para processamento de vídeo, mas ainda alimenta 70% do meu ambiente, junto com software Open Source e Freeware.

Usei Ruby por tanto tempo que pensei que a comunidade, agora que estava crescendo, talvez valorizasse a experiência e a disposição de ajudar nesse cenário específico.

Então, em vez de continuar coçando minha coceira nas sombras, decidi contribuir de volta e ajudar outros que buscam a mesma coisa. Pode dizer que estou tentando equilibrar meu karma.

AkitaOnRails: Os americanos provavelmente não entendem isso, mas em países emergentes como o Brasil, as pessoas não têm muita escolha. A maioria não tem instrução suficiente (cof inglês cof) e encontra muitas barreiras. O último recurso para todo mundo é o Windows. Acho que é a mesma coisa na Argentina. Os Railers aqui não simplesmente migram para Macs ou Linux — diria que pelo menos 90% de todos os desenvolvedores estão presos ao Windows por um motivo ou outro. É a mesma coisa na Argentina, imagino?

Luis Lavena: Mesmo que eu não goste, tenho que concordar. Felizmente as universidades começaram a mudar isso alguns anos atrás, dando palestras e sendo mais abertas à comunidade Linux, que cresceu muito.

Ainda assim, há muitos usuários e desenvolvedores presos em ambientes corporativos/médios ou que precisam rodar Windows por algum hardware proprietário ou similar.

Então, nós (como comunidade) não conseguimos chegar a esses desenvolvedores sem sermos mais abertos ou fornecer ferramentas que facilitem o caminho entre o ambiente atual deles e ferramentas alternativas.

AkitaOnRails: Mas por algum motivo parece haver quase zero interesse da comunidade em suportar Ruby no Windows. Quer dizer, existem pessoas como você, alguns desenvolvedores de RubyGems que se dão ao trabalho de disponibilizar binários para win32, mas parece não ser suficiente. Como o One-Click Ruby Installer começou? Você o criou ou herdou?

Luis Lavena: Sim, concordo, mas não posso culpá-los — afinal, cada um coça sua própria coceira. ;-)

Herdei o One-Click Installer do Curt Hibbs, que também herdou do Andy Hunt e outros contribuidores.

A verdade é que por muitos anos usei minha própria versão do Ruby, compilada internamente, então tínhamos controle sobre ela. Não a modificávamos de forma alguma — gostamos de ter todo o processo documentado e automatizado, para poder identificar os componentes específicos atualizados que introduziram conflitos.

O One-Click Installer, por outro lado, depende de builds feitos pelos atuais desenvolvedores e mantenedores do ruby-core, o que torna o processo de encontrar as dependências corretas um pouco difícil. Esse build também impôs outros problemas, mas isso exigiria mais tempo para explicar.

AkitaOnRails: Haha, quero mergulhar nas partes mais técnicas para que as pessoas possam entender melhor a situação atual no Windows. Quão diferente é o Ruby no Windows comparado ao Ruby no Linux? A coisa mais óbvia é que qualquer Gem com Extensões C sem binários adequados para Windows vai falhar. Tentar executar comandos shell vai falhar e o RubyInline também. O que mais?

Luis Lavena: Hehe, isso é só a ponta do iceberg. Deixe-me mostrar um exemplo. Suponha que você tem um pacote ABC construído para sua distribuição atual de Linux. Essa versão específica de Linux está vinculada a um runtime comum que cuida de comandos básicos como manipulação de arquivos, console, etc. Isso é geralmente chamado de CRT (C Runtime) e no Linux é a glibc.

Então sua distribuição de Linux está vinculada a esta versão glibc A.B.C. Se sua distribuição atualiza a versão da glibc (por exemplo de 2.2 para 2.5), você é forçado a:

1. atualizar todos os seus pacotes instalados, ou
2. recompilar tudo do zero.

Já ouvi de algumas dessas atualizações dando tão errado que os usuários são forçados a começar do zero. O Windows, por outro lado, não pode quebrar 2 bilhões de aplicações por causa de uma mudança de CRT, então mantém versões antigas e preserva a compatibilidade no arquivo MSVCRT.dll (onde a versão base é 6.0).

Uma vantagem do Windows é que você pode ter vários CRTs coexistindo no seu sistema operacional. A parte ruim é que você não pode vincular com segurança a um CRT e usar componentes que se vinculam a outra versão sem se preocupar com segfaults e afins.

Tentei condensar essas informações num post algum tempo atrás. Como você pode ver, a falta de ferramentas de desenvolvimento não é o pior problema no desenvolvimento Windows.

AkitaOnRails: Interessante. E outra coisa é o compilador Visual Studio vs MinGW. Você pode nos dar uma ideia de por que escolheu o MinGW? É só porque o VS é comercial e os desenvolvedores teriam que pagar?

Luis Lavena: O Visual Studio é ótimo, mas só quando você pode pagá-lo. As versões gratuitas carecem de algumas coisas muito úteis, como a Profile-Guided Optimization (PGO) que está sendo usada para construir binários Windows do Python, por exemplo.

O problema com o VS, mesmo as versões gratuitas, é que você não tem permissão de distribuí-las. Acho que é até ilegal vincular à URL/página de download. Então, mesmo para o nosso projeto de sandbox automatizado, o Visual Studio precisaria ser baixado, instalado e configurado manualmente.

Felizmente nas últimas versões você não precisa instalar o Platform SDK, que era 1GB. As versões do VS se vinculam apenas à versão mais recente do MSVCRT, o que nos força a relinkar cada biblioteca da qual o Ruby depende (e o código fonte do Ruby depende de muitos externos).

Além disso, o Ruby não usa a versão safe do CRT para funções de cópia de strings, então você precisa de flags de compilador só para evitar isso… Então depois de semanas de muito trabalho para compilar com VC8 e todas as dependências, você acaba com algo que tem performance quase igual, já que não há ganho de performance — mas agora você tem menos cabelos.

O MinGW, por outro lado, era mais próximo de um ambiente Linux, então a maioria das ferramentas funcionava imediatamente. A parte boa é que não precisávamos compilar todas as dependências com ele, já que por padrão tudo se vincula ao MSVCRT (o CRT padrão no Windows). O MinGW também fornece algumas ferramentas de cross-compilação que permitem construir, usando o ambiente Linux, bibliotecas compartilhadas (dll) e executáveis para Windows.
Considero isso uma vantagem, não sei o que os outros pensam.

AkitaOnRails: Uau, isso é realmente avassalador e recomendo a qualquer pessoa interessada nos detalhes que dê uma olhada no seu blog. Mas tudo isso dito, agora você tem tudo no lugar, um processo adequado e tal, presumo. Se eu sou um desenvolvedor C Windows e quero contribuir, onde devo ir primeiro para saber quais ferramentas usar, como compilar as coisas, etc.?

Luis Lavena: Essa é a parte boa! Gordon Thiesfeld e eu temos trabalhado em dois pacotes para o novo One-Click Installer: Runtime e Developer Kit.

O Runtime vem com o mínimo de Ruby+RubyGems para você começar e também pode ser usado como módulo para outras instalações. O DevKit fornece o ambiente MinGW para você criar extensões Ruby ou mesmo instalar aquelas que não são pré-compiladas para Windows mas são fáceis de obter.

Este DevKit não vai apenas facilitar o trabalho com Ruby no Windows (e dar acesso a algumas ótimas Rubygems), mas também permitir que você contribua de volta para o projeto Ruby. Como? Fácil — o projeto Ruby Installer (no Github) é auto-hospedado. O que isso significa? É possível replicar nosso ambiente de desenvolvimento em qualquer lugar, hackear suas mudanças ou até debugar o próprio código C do Ruby e contribuir de volta para a comunidade. Temos feito isso por vários meses e está funcionando. Que legal, né?

AkitaOnRails: Parece incrível. Não sabia disso e aposto que muitos desenvolvedores também não. Espero que os desenvolvedores C que leram isso possam se atualizar agora. Outro detalhe: RubyGems. Quão difícil é portar uma Gem com Extensões C para fornecer um binário Windows quando você a instala?

Luis Lavena: Oh, isso requer que alguns desenvolvedores não caiam em truques específicos de plataforma para fazer suas ferramentas funcionarem. Um exemplo, que também é uma má prática, é usar caminhos hard-coded…

Outro é depender da existência de algumas ferramentas externas que às vezes não estão disponíveis ou os desenvolvedores/usuários não instalaram. E não estou falando de problemas de plataforma Linux-Windows — mesmo entre distribuições Linux isso é um problema.

Instalando Gems no RubyInstaller de Luis Lavena no Vimeo.

AkitaOnRails: Então depende bastante da qualidade da Gem original, certo? Quanto mais limpo o código, mais fácil de portar, claro. Mas seu DevKit fornece alguns atalhos para isso? E quanto ao RubyInline, ele simplesmente quebra?

Luis Lavena: Sim, aprendi ao longo dos anos que você não deve supor nada sobre o ambiente em que sua aplicação vai rodar — assim você evita esses erros.

Felizmente o RubyInline funciona bem com o Ruby Installer (One-Click Installer que usa MinGW) há algumas versões atrás — graças ao Ryan Davis por incluir esses patches.

O build atual em VC6 do One-Click Installer não é seguro, pois você precisa do VS6 para funcionar, que não está mais disponível. Já ouvi de usuários aproveitando Sequel, Ambition e ImageScience no Windows graças a esses patches.

AkitaOnRails: Me corrija se estiver errado, mas não é uma forma de incorporar snippets de código C misturado com código Ruby? Isso significa que ele compila nativamente esse snippet para executar? Como consegue isso num ambiente Windows que não tem compiladores por padrão?

Luis Lavena: Conseguimos incluir alguns patches no Hoe e no RubyInline que “empacotam” as extensões pré-compiladas dentro das gems, então os usuários não precisam de um compilador nesses casos.

De qualquer forma, agora usar o build VC6 do Ruby exige mão de obra para manter essas gems e acompanhar os novos lançamentos, o que leva tempo. Até agora era só eu na jogada (já que temos algumas licenças VC6). Construir tudo para todo mundo é um fardo que estou ansioso para transferir para o DevKit.

AkitaOnRails: São vocês que mantêm as versões Windows das Gems ou cada desenvolvedor cuida do seu próprio projeto? Há um repositório central para Gems prontas para Windows? O DevKit já está disponível, aliás?

Luis Lavena: Para alguns projetos sou o único que mantém gems para Windows; para outros apenas contribuí com patches e outros usuários gerenciam os builds. Não há repositório central para gems Windows porque quero que o RubyForge seja o central.
De qualquer forma, estou publicando as específicas do MinGW baseadas em forks do github aqui:

gem list --remote --source http://gems.rubyinstaller.org

O devkit já está disponível, mas estamos embrulhando-o num bom pacote de instalação Windows. Você pode sujar as mãos e pegar o projeto sandbox do Github para ter seu ambiente, ou simplesmente baixar os pacotes.

AkitaOnRails: Então, no que diz respeito a ferramentas e processos, você está fazendo um ótimo trabalho. Mas então há o código Ruby que, por si só, é um grande desafio pelo que ouço. Você me mencionou que nem parece C. Quais são os maiores problemas? Técnicos ou conseguir ajuda da lista ruby-core, ou ambos? E quanto aos test suites, como você está eliminando bugs de compatibilidade?

Luis Lavena: Para ser honesto, às vezes olhar para o código C do Ruby me dá dor de cabeça. Há muitas macros, definições e condições de macro que aparecem no meio de um bloco if..else... A parte mais difícil, além de rastrear o bug, é obter feedback do ruby-core. Várias vezes expressei minhas preocupações em listas de e-mail, IRC e no meu blog.

Várias vezes perguntei se era OK ter alguns erros nos unit tests do próprio Ruby e às vezes obtive respostas, mas às vezes não. Felizmente não precisamos mais basear nossa qualidade de testes nos unit tests incluídos no Ruby. Começamos a encontrar problemas com a implementação do Ruby no Windows usando as Ruby Specs criadas pelo pessoal do projeto Rubinius e que a maioria das implementações (IronRuby e jRuby) contribui ativamente e usa como base de seus interpretadores.

AkitaOnRails: Falando nisso, RubySpecs — quão longe está o Ruby no Windows de passar por elas? Ou já passa?

Luis Lavena: Bem, é uma tarefa grande. Primeiro começamos fazendo o MSpec funcionar corretamente no Windows, já que o RubySpec requer alguma auditoria para remover caminhos hard-coded. Então começamos a adicionar guards em torno de coisas que não são suportadas ou não funcionam no Windows no MRI.

Isso leva mais tempo já que precisamos revisar os resultados em cada plataforma, mergulhar na documentação do Ruby (que às vezes é insuficiente) ou respirar fundo e olhar para o código C para descobrir o que está fazendo.

Se tivéssemos mais mão de obra, talvez conseguíssemos terminar de proteger todo o código e ter specs rodando limpas no Windows. Agora há muitas que simplesmente falham ou causam segfault.

AkitaOnRails: Você deveria documentar esse processo para que as pessoas possam ajudar, se ainda não o fez :-) Agora falando de coisas mais práticas: Ruby no Windows, hoje, é um runtime viável para rodar apps Rails no Windows? Mesmo apps em produção? Você trabalhou com Zed Shaw no Mongrel para Windows, certo? Experimentou o mais recente suporte FastCGI da Microsoft para IIS?

Luis Lavena: Hehee, documentação, documentação — é totalmente superestimada. Planejamos ter vários screencasts no site do RubyInstaller, mas continua como 'em breve' por enquanto.

Não só você pode desenvolver aplicações Rails no Windows (como eu também faço), mas conheço várias empresas que rodam lado a lado com IIS ou mesmo Tomcat.

Mesmo 2 anos após o Zed tê-lo criado, o Mongrel ainda domina o cenário de servidores web Ruby. Não fiz muito ao próprio Mongrel, já que o Zed criou algo que funcionava no Windows com pequenos ajustes.

Criei algo para rodar o Mongrel como serviço (mongrel_service), o que ajudou várias pessoas a introduzir Ruby e Rails em seus ambientes corporativos, inclusive conversando com servidores MSSQL.

Pessoalmente não testei o suporte a FCGI no IIS, mas fui eu quem o corrigiu para ser incluído no One-Click Installer para que alguns usuários pudessem aproveitá-lo. Podemos dizer que funciona.

AkitaOnRails: Sobre performance, o Windows parece ter uma condição inerente: na mesma máquina quando inicio, digamos, um simples IRB no Windows, depois dou dual boot para Linux e rodo, parece abrir muito mais rápido (não é exatamente um experimento científico :-). Qual é sua experiência com a performance do Ruby no Windows?

Luis Lavena: Há problemas de performance relacionados ao código C gerado pelo compilador e problemas relacionados ao SO e I/O gerenciados por ele. Carregar o IRB no Windows pode estar exigindo RubyGems em segundo plano, que por sua vez precisa varrer e carregar todas as especificações de gems. Tento manter RUBYOPT=rubygems fora das minhas variáveis de ambiente.

AkitaOnRails: Aliás, por que tenho a impressão de que vejo RUBYOPT=rubygems sendo recomendado em todo tutorial Windows que vejo?

Luis Lavena: RUBYOPT=rubygems é a parte da mágica que devemos evitar.
No Linux, se você começa a criar um script e precisa de uma gem, começa com:

require 'rubygems'
require 'some_gem'

O mesmo deveria ser feito para Windows. Não é doloroso, é boa prática. RUBYOPT é um atalho que não gosto — nunca vi uma distribuição Linux que ative isso por padrão e não gosto que seja configurado no Windows (é claro, esse é meu ponto de vista pessoal).

Então, para evitar cair em procedimentos de teste padrão, continuo usando um solver de sudoku simples mas bom que exercita recursão, arrays e condições da VM em vez de ser I/O bound.

Você pode ver isso, com resultados interessantes no meu blog (veja a seção "Rubinius, RubySpecs, and speed." do post).

O principal é que o VC6 torna tudo lento. Depois você tem as coisas I/O bound (I/O no Windows não é tão bom quanto no Linux). Considero o build padrão VC6 do Ruby no Windows dolorosamente lento. Por outro lado, o do MinGW é mais ágil, mas ainda acho que há um longo caminho a percorrer para melhorias.

AkitaOnRails: Então, no geral, Ruby no Windows está sempre evoluindo — o que é ótimo —, roda bem no Windows — o que é notável —, mas poderia usar um pouco mais de ajuda, certo? Você acha que mais desenvolvedores C Windows ajudariam? Ou seja, adicionar mais mãos ajudaria a melhorar a qualidade?

Luis Lavena: Definitivamente!

AkitaOnRails: Que tipo de desenvolvedores — o que uma pessoa deveria saber para ajudar?

Luis Lavena: Não sei se o "core" do Ruby vai aceitar isso — ultimamente só ouço a palavra fork em torno do Ruby MRI. Além disso, podemos corrigir bugs na implementação Ruby para Windows, mas não podemos melhorar muito a qualidade já que essas mudanças afetariam outras plataformas também.

A parte ruim é que não há separação clara por plataforma de código específico — tudo é uma série de macros e condições de compilação que dificultam o rastreamento (para desenvolvedores não-masoquistas).

AkitaOnRails: O que me lembra o pessoal da Phusion com a sua Enterprise Edition, que é um fork do MRI. Você tentou analisar os patches de GC copy-on-write deles? Talvez incluí-los na versão Windows? O Ruby no Windows em si é um "fork". Você acaba tendo que sincronizar seu trunk com o deles — é assim que funciona?

Luis Lavena: Honestamente não tive tempo de analisar a Enterprise Edition, mesmo tendo acompanhado todos os posts e a discussão desses patches no ruby-core. O engraçado é que os últimos lançamentos da branch Ruby 1.8.6 estão me dando dores de cabeça (mais do que olhar para o código C). Eles não conseguem nem completar os self-tests e causam segfault com algumas extensões como a gem mysql.

AkitaOnRails: Sim, tem gerado muito barulho na comunidade — e com razão. Espero que possam resolver logo. Bem, acho que já tomei muito do seu tempo. Há algum assunto que você gostaria de abordar, ou pelo menos alguma mensagem para a comunidade brasileira mais jovem?

Luis Lavena: Sim — não tenha medo de fazer perguntas, não se envergonhe de usar Windows como plataforma. Você pode realizar ótimas aplicações usando Windows e pode se infiltrar mais facilmente em ambientes corporativos com ele.

AkitaOnRails: Ah, o que me lembra de uma última pergunta que todo mundo me faz o tempo todo — e vou repassar para você, já que é um desenvolvedor Windows: quais são suas ferramentas preferidas para editar projetos Ruby/Rails?

Luis Lavena: Uso principalmente coisas gratuitas ou open source, então tenho usado o Komodo Edit (não Pro) e o Programmer Notepad, já que às vezes os uso para trabalhar com código C, FreeBASIC e Assembler para hardware embarcado.

Ultimamente tenho usado um editor leve chamado Intype que vem com alguns bundles para imitar o TextMate, mas realmente não aproveito muito. Usei NetBeans por um tempo, mas depois de 500MB simplesmente fechei :-)

AkitaOnRails: Haha, e o que você recomendaria para um programador Rails iniciante?

Luis Lavena: Para começar, o NetBeans é bom, mas com a prática aprenderão que até o notepad é suficiente para programar.

(PS: Já estamos incluindo os patches da Enterprise para os últimos problemas no build MinGW! :-)

AkitaOnRails: Haha, certo. Bem, acho que é isso. Espero que isso alcance um público mais amplo e chame atenção dos desenvolvedores Windows por aí. Muito obrigado!

Luis Lavena: Obrigado a você, Fabio.

Ele também postou um excelente screencast sobre o novo framework MVC alternativo da Microsoft e achei que seria ótimo tê-lo aqui no blog para falar sobre tecnologia e frameworks web. Como já disse antes, acho que não devemos ficar alheios ao que está acontecendo em outras frentes, e Scott é uma pessoa de pensamento avançado e mente aberta.

AkitaOnRails: Antes de tudo, deixa eu te parabenizar sr. progman.exe :-) Entendo que isso foi algo pelo qual você estava muito animado. Pode nos contar um pouco mais sobre sua transição para a Microsoft e suas novas responsabilidades?

Scott Hanselman: Estou trabalhando para Simon Muzio, que cuida de www.asp.net, www.iis.net e grandes sites cheios de conteúdo como esses. Gosto de pensar que meu trabalho é escrever um livro que nunca vai terminar, onde esse livro são posts de blog, artigos, screencasts, vídeos, palestras, etc. No fundo sou um professor, então mesmo tendo o título de “Community Liaison”, prefiro “Professor”.

AkitaOnRails: Conta pra gente sobre sua história. Como você começou no mundo da computação? Você sempre foi mais voltado para Windows ou tinha uma base no mundo Unix também? E antes de sua recente saída para a Microsoft você trabalhava na Corillian. Qual era sua função lá?

Scott Hanselman: Este post de blog fala sobre meus primeiros anos na escola.

Viu aquele livro à direita? Foi assim que aprendi a programar. Esse livro era O livro em 1984. Digitei o livro inteiro num Commodore 64.

E uma professora MUITO influente que me colocou no caminho certo.

Marianne Mayfield é minha professora da quinta série e a razão pela qual estou em computação hoje. Ela esteve no meu casamento, em formaturas, em eventos de família. Vinte anos depois ainda somos próximos. Quando eu era jovem, ela reconheceu que eu estava “em risco de dar problema” e se sentou com minha família para encontrar uma forma de me colocar de volta nos trilhos. Ela viu que eu estava fascinado pelo Apple II na nossa sala de aula e arranjou para que a gente pudesse levar o computador para fora da escola, desde que estivesse de volta antes do domingo à noite sem que ninguém notasse.

(clique nos links acima para mais detalhes)

Scott Hanselman: Eu era o Arquiteto-Chefe na Corillian, trabalhando com outros engenheiros e arquitetos em toda a empresa, planejando, projetando e codando a próxima geração da Plataforma de Internet Banking da Corillian.

AkitaOnRails: Aplaudo sua campanha Team Hanselman para ajudar no combate à Diabetes. Entendo que você também tem Diabetes e que, felizmente, conseguiu controlá-la hoje em dia. Pode nos contar essa história e os objetivos da sua campanha?

Scott Hanselman: Minha história pessoal está aqui:

Atualmente tomo três injeções de Symlin por dia enquanto uso uma bomba de insulina 24 horas por dia, inclusive enquanto durmo. A bomba me poupa de mais seis injeções por dia, que tomei durante 8 anos antes da bomba. Meço minha glicose picando meu dedo entre 8 e 10 vezes por dia — são cerca de 46.500 picadas até agora, e ainda há um longo caminho pela frente.

E tem uma boa explicação da diabetes aqui:

É aqui que a analogia fica interessante. Lembre que na analogia estamos voando de Los Angeles para Nova York, mas só podemos verificar nossa altitude sete vezes. E só podemos mudar de altitude (tomar insulina) menos de dez vezes. Mas quando verifico minha glicose, estou vendo o passado. Estou vendo uma leitura de como estava minha glicose há 15 minutos. E quando tomo insulina, ela só começa a reduzir minha glicose depois de pelo menos 30 minutos.

A campanha acabou arrecadando mais de USD$30.000, e esse dinheiro será aplicado em pesquisa, educação e programas relacionados à diabetes.

AkitaOnRails: “O que diabos você estava fazendo numa RailsConf?” Isso é o que acho que pessoas de fora do mundo de blogs Microsoft perguntariam a você :-) Então, você é apenas curioso sobre Rails, ou chega a desenvolver aplicações baseadas em Rails? Estou muito interessado em conhecer sua opinião sobre Rails. Como você o encontrou? O que você acha de melhor no Rails? E mais importante, o que você acha que Rails poderia melhorar?

Scott Hanselman: Estou sempre experimentando diferentes linguagens de programação e frameworks. Tenho feito Rails de vez em quando há cerca de 18 meses, mas ainda não clicou pra mim. Tenho certeza que vai em breve. O padrão MVC é muito antigo… eu fazia isso em Java há mais de 10 anos, e certamente o padrão remonta a 30 anos. Acho que Rails é um bom framework considerando sua pouca idade. Mas acho que é o Ruby que tem a magia de verdade, e vejo que a estética do Ruby está muito em linha com a minha.

AkitaOnRails: Então, seguindo minhas preferências tendenciosas, o próximo artigo de que gosto é seu screencast sobre o framework CTP ASP.NET MVC. Vejo que esse novo framework se parece muito com Rails. Claro, pode parecer assim apenas porque ambos implementam MVC. Por outro lado, ele usa expressões muito similares ao Rails em todo lugar. Falta um pouco de “mágica de convenção-sobre-configuração”, mas pelo que vi parece muito melhor do que fazer ASP.NET convencional. O que você acha dele? Pode resumir um pouco para quem não conhece esse produto? E o que você acha que ainda vai melhorar nele?

Scott Hanselman: Se alguém aponta para Rails e diz “isso é MVC” então tudo mais vai se parecer com Rails, claro. Qualquer bom framework MVC precisa não só seguir o padrão adequadamente, mas também abstrair o HTTP (assumindo que é um framework web) de forma limpa, mas não completa. A implementação do ASP.NET MVC ainda carrega alguma bagagem que sempre vai precisar carregar porque o ASP.NET WebForms veio primeiro e não foi projetado do zero com testabilidade em mente. Dito isso, tudo se resume a alternativas. Use o framework que te deixa feliz e em que você se sente mais produtivo. Alguma fração, talvez 20%, dos desenvolvedores ASP.NET vai preferir MVC. Agora eles têm uma opção com suporte da Microsoft e boa integração com C# 3.0.

na RailsConf'07

AkitaOnRails: E o que seria o mundo tech sem discussões e flame wars? Entendo que a maioria dos desenvolvedores .NET nem presta atenção a Rails ou outros frameworks. Até ouvi que há alguns desenvolvedores questionando coisas como “Por que mais um framework web se o ASP.NET já existe?” Ou seja, por que reinventar a roda e dividir atenções? Particularmente acho que esse novo MVC é o caminho a seguir, mas é inegável que o velho ASP.NET tem muito mais aceitação e suporte. Como reconciliar os dois pontos de vista?

Scott Hanselman: Isso é puro FUD (fear, uncertainty, and doubt — medo, incerteza e dúvida). Que pensem o que quiserem, esse framework é apenas sobre alternativas. WebForms é ótimo, e se você está fazendo aplicações Line of Business (LOB) com grids complexos e afins, ele não vai a lugar nenhum. No entanto, se você é uma equipe ágil que preza TDD e ficou frustrado com ViewState, então confira ASP.NET MVC. Não há nada a reconciliar. Algumas pessoas vão de carro, outras de moto, outras a pé. O que importa é chegar do ponto A ao ponto B e se sentir bem durante a jornada.

AkitaOnRails: Falando em flame wars, há provavelmente um assunto que me dá arrepios: as teorias conspiratórias paranoicas sobre Miguel de Icaza e o Mono. Muita gente acredita de fato que Miguel está “vendendo” parte do mundo open source para a Microsoft. Você já usou? O que você ouve da comunidade e qual é sua opinião sobre o assunto?

Scott Hanselman: Sim, já usei Mono e acho que é uma ótima forma de fazer sua aplicação .NET funcionar no Linux ou Mac. Acho Miguel brilhante e um excelente dançarino. Ouço na comunidade que as pessoas estão felizes por Mono existir e estar disponível como uma opção.

AkitaOnRails: Provavelmente vou levar uma maldição por isso, mas não sou “fortemente” contra a Microsoft como alguns fundamentalistas são. É público e notório que a Microsoft é uma grande corporação e, como tal, cometeu sua parte de atos equivocados. Muitos deles já foram resolvidos na justiça. Então é mais complexo do que as pessoas geralmente pensam. Prefiro assumir que dentro da Microsoft há muitas pessoas muito inteligentes.

Scott Hanselman: Fico fora de questões legais. A Microsoft é uma empresa enorme com muita gente inteligente, mas na prática é muitas empresas de porte médio trabalhando juntas (geralmente). Não posso falar sobre “atos equivocados”. Só posso dizer que faço meu melhor todo dia para não ser mau, assim como meus colegas de trabalho. Não há nenhum plano maléfico mestre no meu grupo.

AkitaOnRails: Particularmente gosto do roadmap para Windows Server 2008 (com sua abordagem minimalista, finalmente tendo instalado apenas o que você precisa). No ano passado você estava experimentando o IIS 7 e seu novo suporte a FastCGI. Acho que era destinado principalmente ao suporte de PHP mas teoricamente poderia lidar com Ruby on Rails também. Você já tentou Rails lá? Acho que a Microsoft claramente está indo atrás do segmento de menor custo com Windows Server 2008 + IIS 7, contra as caixas baratas de Linux+Apache. Acho que não conseguirão chegar lá em termos de preço, mas o que você acha dele como competidor de serviços de internet?

Scott Hanselman: Tenho pouco poder nessa arena, mas toda vez que alguém quiser ouvir estou defendendo um SKU barato de Servidor Web. Sou um grande fã do IIS7 e gostaria que o máximo de pessoas possível o experimentasse. Não testei IIS7+Rails mas ouvi rumores de pessoas conseguindo fazer funcionar.

AkitaOnRails: Há muitos recursos novos no .NET 3.5. LINQ é o que mais me interessa. Pode nos dar uma breve descrição de por que é tão interessante? E o que você acha das melhores melhorias da versão 3.5? Você já está usando o Orcas? Qual é sua opinião? Ah, e você conhece o projeto Sapphire in Steel?

Scott Hanselman: LINQ é interessante porque é sua própria Linguagem de Domínio Específico para consultar objetos de todos os tipos, e está vivendo diretamente dentro de VB e C#. É um compilador MUITO mais inteligente e é um prazer trabalhar com ele. Instalei o Sapphire In Steel e conheço algumas pessoas que adoram. Estou animado para ver Rails no .NET.

AkitaOnRails: Uma das vantagens da estratégia Microsoft .NET foi estar preparada desde o primeiro dia para ser agnóstica em relação a linguagens. Agora temos o DLR que foi derivado dos trabalhos no IronPython e não no IronRuby. Mas há ainda outra linguagem interessante que poucas pessoas conhecem: F#, a linguagem inspirada em OCaml. Você já experimentou?

Scott Hanselman: Sim, e fiz dois podcasts sobre ela, um com Robert Pickering, autor de um livro sobre F# e outro com Dustin Campbell, um entusiasta. Estou animadíssimo que ela vai ser uma linguagem de primeira classe dentro do VS.

com John Lam

AkitaOnRails: Não sou contra comparações técnicas, precisamos fazer esse tipo de coisa para decidir nossos passos em projetos. Mas sou contra desafios sem sentido. Rails está longe de ser perfeito e sou o primeiro a dizer isso. Dito isso, é ótimo para um nicho específico de desenvolvimento web. Costumo recomendar que bons programadores devem expandir seus horizontes e aprender o máximo possível de coisas novas. Não dá para saber tudo perfeitamente, mas é sempre bom estar ciente das possibilidades. Você escreveu algo nessa linha. O que você acha disso?

Scott Hanselman: Rails é bom no que faz dentro do seu nicho. Você não cria aplicativos desktop Windows com Rails e tudo bem. É por isso que não comparamos Rails com WPF, mas com frameworks web. Comparação é boa e sempre há algo bom para encontrar dos dois lados. Evito flame wars também. É inútil. Se o sapato aperta, não use. Mas experimente o máximo de sapatos que puder!

AkitaOnRails: No ano passado você escreveu um post interessante sobre o futuro. Google é esse grande gigante, Amazon lançou produtos surpreendentemente bons nos últimos meses como S3, EC2, SimpleDb. Não estou bem a par da estratégia atual do Microsoft Live. Pode dizer algo sobre para onde está rumando?

Scott Hanselman: Não estou nesse grupo então não tenho nenhum conhecimento além do que já foi dito. No entanto, ainda mantenho minhas previsões naquele post!

A computação vai se mover para a Nuvem. Já está acontecendo, estamos 20% lá. A ideia existe desde o começo e vai, na minha opinião, continuar surgindo até que realmente aconteça e construamos a Skynet. Uma dessas nuvens de computação vai certamente acabar em órbita.

AkitaOnRails: E claro, de certa forma “preciso” te perguntar isso: você usa Windows Vista? Como tem sido para você considerando que há uma enorme campanha underground contra ele? Você acha que é tão ruim quanto todo mundo diz? Não posso comentar porque nunca o testei fora da minha máquina virtual (sou um cara de Mac), mas eles venderam 100 milhões de licenças.

Scott Hanselman: Com certeza. Rodo Vista 64-bit em 3 máquinas e Vista 32-bit em 2 máquinas. Foi difícil nos primeiros 3 meses enquanto o suporte a drivers deixava a desejar, mas agora está ótimo. Tenho 2 máquinas com Vista que não foram reinicializadas há meses, apenas colocadas em modo de suspensão e acordadas. Depois que você consegue bons drivers de vídeo, geralmente tá tranquilo.

As pessoas implicam com o Vista, mas esquecem a vasta gama de hardware em que ele tem que rodar. O OS X só precisa rodar em Macs, e em uma faixa estreita deles. O Vista tem que rodar em milhões de combinações de hardware. Drivers de terceiros são DE LONGE o que mais trava o Vista, e ele leva a culpa. Por isso rodo 64-bit e uso apenas drivers assinados. Estou encantado com o 64-bit. Funciona muito bem.

AkitaOnRails: Ok, é isso :-) Muito obrigado!