Eu gosto dessa fase. O projeto deixa de ser “o que eu imaginei no meu setup” e vira “o que quebra na máquina de outra pessoa”. Aí aparece Windows, macOS, Arch, AUR, path esquisito, token salvo em lugar diferente, shell diferente, terminal diferente. Chato? Sim. Necessário? Também.

Mas o prato principal de hoje não é ai-jail nem ai-memory. É TUI. Mais especificamente, é minha mania recente de escrever pequenas ferramentas de terminal em Rust com Ratatui, mas querendo que elas fiquem com cara de Bubble Tea.

O app que não vou abrir

Nas últimas semanas também mexi num projeto privado que não pretendo abrir. É uma TUI pra acompanhar minha conta nos EUA, investimentos, assets, posições, covered calls, open calls, essas coisas chatas de adulto. Não vou publicar o código porque é o tipo de ferramenta que nasceu colada no meu fluxo financeiro, nas minhas planilhas, nos meus extratos e nas minhas gambiarras internas. Abrir isso seria transformar uma ferramenta minha em suporte gratuito pra bug de banco dos outros. Tô fora.

Mas dá pra mostrar a cara geral. Censurei o que precisava censurar:

Observação óbvia, mas vou deixar explícito: todos os valores, tickers, posições e datas mostrados no screenshot são dados falsos de demonstração. Não é dado real da minha conta, nem portfolio real, nem recomendação de investimento.

Toda vez que faço uma TUI pequena, a mesma dúvida aparece: que stack usar?

Se eu fosse escrever tudo na unha, provavelmente escolheria Python ou Go. São linguagens mais confortáveis pra esse tipo de utilitário pequeno. Python porque é direto, cheio de biblioteca, ótimo pra script que conversa com API e parseia JSON. Go porque gera binário simples, cruza plataforma bem, e tem ergonomia boa pra CLI.

Só que hoje eu raramente escrevo esse código todo na unha. Eu orquestro Claude, Codex, OpenCode, mando revisar, mando refatorar, mando testar. Nesse cenário, a falta de ergonomia do Rust pesa menos, porque quem briga com borrow checker, trait bound e lifetime chato é o LLM. Eu fico mais no papel de revisor e usuário final. E aí Rust começa a ficar muito atraente.

Ferramental bom. cargo é ótimo. Testes são fáceis de rodar. Cross compile é administrável. O binário final é limpo. Erro de memória idiota praticamente some. Não estou dizendo que Rust é magicamente melhor que Go ou Python pra toda TUI. Não é. Mas com LLM escrevendo a maior parte, o custo que normalmente me faria evitar Rust cai bastante. E os modelos atuais estão surpreendentemente competentes em Rust, desde que você mande rodar teste, consertar warning e não aceite a primeira versão como se fosse revelação divina.

Ratatui é bom, mas eu queria a cara do Charm

O Ratatui é uma biblioteca Rust pra construir interfaces ricas no terminal: dashboards, apps interativos, tabelas, listas, gauges, layouts, tudo aquilo que antigamente a gente chamava de “ncurses moderno”. Ele é o sucessor espiritual do tui-rs, e hoje é provavelmente o caminho mais óbvio se você quer fazer TUI séria em Rust.

Ratatui funciona bem. O problema é gosto pessoal: por padrão, não acho bonito. Não é feio no sentido “isso parece programa de DOS de 1993”. Dá pra fazer coisa boa. Mas muita TUI em Ratatui cai naquela estética quadrada, cinza, funcional, meio admin panel de datacenter.

Eu gosto mais da pegada da Charmbracelet. O gum, por exemplo, é uma coleção de comandos pra deixar shell script interativo sem virar festival de read -p e case. Prompt, select, filter, spinner, tabela, pager, estilo. Você monta um script bash com cara de app decente em minutos.

E tem o Bubble Tea, em Go, inspirado na arquitetura Elm. Você tem um model, recebe mensagens, atualiza estado, renderiza uma view. É uma ideia simples e muito boa pra terminal: estado entra, evento entra, view sai. A Charm também tem um gosto visual que eu curto: cores boas, espaçamento decente, componentes leves, nada com cara de formulário WinForms jogado no terminal.

Então eu queria o seguinte: continuar em Rust com Ratatui, mas roubar a sensação de Bubble Tea. Não o runtime inteiro. Não um clone perfeito. Só a direção visual e alguns componentes.

Daí nasceu o ratatui-bubbletea.

O projeto não substitui o Ratatui. Ele fica por cima. A ideia é oferecer uma camada de tema e componentes com inspiração em Bubble Tea/Bubbles, mas ainda renderizando com Ratatui.

Hoje ele é dividido em crates:

• ratatui-bubbletea-theme, com paleta, helpers e estilos compartilhados.
• ratatui-bubbletea-components, com componentes prontos como select list, spinner, progress, table, text input, viewport e help.
• ratatui-tea, opcional, pra quem quer uma ergonomia mais perto de Model, Msg e Cmd, sem fingir que Rust virou Go.

O README tem os exemplos completos e a documentação do que já existe. Por enquanto, eu trato como toolkit pequeno. Serve pra meus apps, e se servir pra mais alguém, ótimo. Se não servir, também não tem drama. O objetivo era parar de reimplementar o mesmo tema e os mesmos widgets toda vez que eu começava uma TUI nova.

ai-usagebar como exemplo público

Como não vou abrir o app financeiro, precisava de um exemplo público usando essa estética. Então atualizei meu ai-usagebar.

Pra quem não lembra, expliquei o projeto no post “Criei um Widget de Waybar pra Omarchy pra Monitorar Uso de Planos de LLM: ai-usagebar”. Ele nasceu como widget de Waybar pra mostrar uso de planos de LLM: Claude, OpenAI Codex/ChatGPT, Z.AI, OpenRouter. Bateu o olho na barra, sabe se está perto do limite e qual vendor usar agora.

Depois virou também TUI standalone. E graças a contribuições, hoje suporta Windows também. Isso é engraçado porque a origem dele é totalmente Linux/Omarchy/Waybar. Mas é open source: alguém usa em outro ambiente, encontra atrito, manda PR, e pronto, o projeto fica menos provinciano.

No ai-usagebar a diferença visual não muda a vida de ninguém. É uma tela simples. Abas, gauges, texto, atalhos. Mas é um bom exemplo porque é pequeno, real, testado, empacotado, e não depende do meu app privado. Dá pra olhar o código e ver como apliquei a camada de tema.

Os apps de coceira própria

Esses projetos todos seguem a mesma lógica: eu tenho uma coceira, faço uma ferramenta pequena, uso, ajusto, empacoto. Nada de roadmap de startup. Nada de manifesto. Só ferramenta que resolve um incômodo meu.

Um exemplo recente é o clock-tui. Ele não nasceu comigo. Era um projeto Rust antigo, tclock, que parecia abandonado. Eu queria um relógio grande no meu segundo monitor vertical. Aquele monitor fica do lado, e eu gosto de ter um “desk clock” enorme ocupando parte da tela. Usei o clock-tui original por um tempo.

Só que uma tela vertical inteira só pra mostrar hora é desperdício. Eu já tinha o ghpending, que lista issues e PRs abertos em todos os meus projetos. Ele é meu “tem alguém esperando resposta?” em formato de CLI. Também queria ver minha agenda.

Então fiz outro app pequeno: google-calendar-tui. Ele usa as contas Gmail já registradas no GNOME Online Accounts e resume meus próximos compromissos no terminal. Read-only. Sem ritual de OAuth novo. Sem mais um config secreto espalhado em lugar esquisito.

Com essas duas peças, modernizei o clock-tui e adicionei layout de widgets auto-refresh. Agora o relógio ocupa a tela como eu queria, mas em volta dele aparecem pendências do GitHub e agenda do Google Calendar.

Isso é exatamente o tipo de coisa que eu nunca faria se custasse um fim de semana inteiro. Mas com LLM, vira uma sequência de tarefas pequenas: lê o projeto antigo, moderniza dependências, roda teste, adiciona módulo de widget, chama ghpending, chama google-calendar-tui, organiza layout, corrige bug, empacota. Ainda dá trabalho. Mas é trabalho de supervisão e refinamento, não de ficar brigando com boilerplate.

Ajustando Geary sem fork

Outra coceira veio do GNOME.

Como eu queria centralizar minhas contas no GNOME Online Accounts, comecei a usar Geary e o calendário do GNOME no segundo monitor também. Gosto da ideia: contas configuradas uma vez, apps do desktop reaproveitando a mesma infraestrutura, nada de cada programinha inventar seu próprio login.

O problema é que o Geary tem um layout fixo de três colunas. Numa tela normal, tudo bem. Num monitor vertical, fica apertado. A coluna de pastas, a lista de mensagens e o corpo do e-mail brigam por espaço. Eu não queria manter um fork do Geary só pra esconder uma sidebar. Fork de app GTK grande é dívida. Você pisca e passa o resto da vida resolvendo conflito de merge.

Então fiz um módulo GTK: geary-hide-sidebar-module. Ele injeta um comportamento no Geary em runtime e permite recolher/expandir a sidebar, com atalho e auto-collapse em janela estreita. Sem recompilar Geary. Sem manter fork. Só um módulo pequeno com uma responsabilidade bem específica.

Essa é uma lição boa: às vezes você não precisa forkar a aplicação inteira. Dá pra ajustar por fora. GTK_MODULES existe. Wrapper existe. Config existe. CSS existe. Script existe. Nem toda personalização precisa virar uma manutenção eterna de código dos outros.

Código pequeno ficou barato

É por isso que estou insistindo tanto nessa ideia de apps pequenos. Com LLMs atuais, ficou muito fácil implementar uma ideia específica pra deixar seu ambiente do jeito que você quer. Sem esperar alguém ter exatamente a mesma dor. Sem ficar procurando no GitHub por três horas uma ferramenta que faz 80% do que você quer e 40% do que você não quer.

Você descreve a coceira, cria um repo, pede um protótipo, testa, manda refatorar, manda escrever teste, manda empacotar. Se ficar ruim, joga fora. Se ficar bom, instala e usa.

Eu não deixo isso virar gambiarra jogada no ~/bin sem dono. Meus apps têm testes. Têm builds automatizados. Muitos têm release no GitHub, pacote no AUR, instalação normal com yay no Arch. Usam paths XDG, então config vai pra ~/.config, cache vai pra ~/.cache, dados vão pra ~/.local/share. Fica organizado. Dá pra atualizar. Dá pra remover. Dá pra outra pessoa clonar e contribuir.

Pra fechar, os links todos num lugar só:

• ratatui-bubbletea
• ai-usagebar
• clock-tui
• ghpending
• google-calendar-tui
• geary-hide-sidebar-module
• ai-jail
• ai-memory

Se você usar algum deles e quebrar no seu setup, abre issue. Se souber corrigir, manda PR. Eu uso essas ferramentas de verdade, então bug report útil tende a virar correção rápido.

Minha regra prática é essa: personalize seu ambiente sem transformar tudo em gambiarra. Faça ferramenta pequena. Teste. Empacote. Documente. Deixe o LLM carregar o peso chato e use seu cérebro pra decidir o que presta.

Essa é a parte divertida de programar que tinha sumido um pouco. Agora voltou.

O problema de ter vários planos é acompanhar quanto já gastei de cada um. Eu vinha usando o claudebar, um widget de Waybar que mostra o uso do plano da Anthropic. Gosto dele, mas queria ver todos os meus vendors num lugar só, pra bater o olho e saber onde estou. E não queria encher minha Waybar de widget separado pra cada vendor. Então resolvi fazer o meu: o ai-usagebar.

É um port em Rust do claudebar, drop-in compatível, estendido pra quatro vendors: Anthropic Claude, OpenAI Codex/ChatGPT, Z.AI (GLM) e OpenRouter. Mantém os mesmos parâmetros (--icon, --format, --tooltip-format, etc.), o mesmo tooltip minimalista com borda Pango, e a mesma auto-detecção do tema do Omarchy. A diferença é que agora os quatro vendors aparecem no mesmo lugar, em vez de 865 linhas de bash cuidando de um só.

Como ele autentica em cada vendor

Essa é a parte que vale explicar, porque cada vendor faz diferente. Claude e Codex usam OAuth: os CLIs oficiais (claude e codex) já escreveram as credenciais no disco quando você logou, e o ai-usagebar lê esses mesmos arquivos. Não precisa de variável de ambiente nenhuma, o token até se renova sozinho.

Z.AI e OpenRouter usam API key, então pra esses você precisa setar uma chave (via env var ou inline no config).

A interface além da Waybar

Além do widget na barra, tem uma TUI com abas (ai-usagebar-tui) pra ver tudo de uma vez. Navega com Tab / h / l entre os vendors, atualiza a cada 60s. Dá pra abrir clicando no widget da Waybar, ou rodar direto no terminal (mais sobre isso na próxima seção).

A aba do OpenRouter mostra saldo de crédito, gasto de hoje / semana / mês e o tier:

E tem um overlay de settings pra escolher o vendor primário e colar as API keys sem editar o config na mão:

Não usa Omarchy nem Hyprland? Roda como TUI standalone

O widget de Waybar é opcional. Os dois binários são independentes, então se você não usa Omarchy, nem Hyprland, nem Waybar (ou simplesmente prefere checar o uso de vez em quando em vez de ter na barra o tempo todo), o ai-usagebar-tui funciona como app de terminal totalmente standalone:

ai-usagebar-tui    # abre no seu terminal atual

Roda em qualquer emulador de terminal (Kitty, Alacritty, Foot, Ghostty, etc.), funciona até numa sessão SSH pura, e não depende de compositor nem de feature de window manager. Todos os controles e o overlay de settings funcionam igual. Os mesmos quatro vendors, as mesmas abas:

Uso típico fora do Omarchy: uma checada rápida antes de começar uma sessão longa (“será que tô perto do limite semanal do Claude?”), um monitor num painel de tmux enquanto você programa, ou uma ferramenta só de shell em máquina remota (instala o binário e pronto, sem dependência de Waybar ou Hyprland). A TUI é a forma canônica de ver os quatro vendors de uma vez, independente de você configurar o widget ou não.

Instalação

No Arch tem pacote no AUR, dois sabores:

yay -S ai-usagebar-bin    # binário pré-compilado do GitHub Releases (~5s)
yay -S ai-usagebar        # compila do fonte (~30-60s)

Ou do fonte direto:

cargo build --release
sudo make install                  # → /usr/local/bin
# ou
make install PREFIX=$HOME/.local   # → ~/.local/bin

A config de Waybar recomendada é um único módulo com scroll pra ciclar entre os vendors, e clique pra abrir a TUI:

"custom/aibar": {
    "exec": "ai-usagebar --format '{vendor_short} {session_pct}% · {session_reset}'",
    "return-type": "json",
    "interval": 300,
    "signal": 13,
    "tooltip": true,
    "on-click": "ai-usagebar-tui",
    "on-scroll-up":   "ai-usagebar --cycle-next",
    "on-scroll-down": "ai-usagebar --cycle-prev"
}

Se preferir ver os quatro vendors ao mesmo tempo, dá pra usar um módulo por vendor. O README tem o detalhe completo de config, placeholders de formato, e as variações.

Por que fiz

Esse parecia um projetinho de sábado à noite, então resolvi só fazer. E foi: portar o claudebar pra Rust e adicionar os vendors extras que eu queria foi tranquilo. Saí de uma noite com um widget que faz exatamente o que eu precisava e ainda é mais confiável (testado, modular) do que o shell script original.

Se você usa outros vendors que eu não cobri, ou achar bug, manda issue ou pull request: github.com/akitaonrails/ai-usagebar. É MIT.

Sei que tem várias ferramentas que resolvem isso. Mas eu queria algo bem simples e rápido pra rodar no terminal e ver pendências de todos os meus projetos de uma vez só. Então fiz: o ghpending.

Roda em Linux e macOS. Eu testei em Linux (Arch + Omarchy) mas ainda não rodei no macOS. Se você for testar lá e topar com algum bug, abre uma issue lá: github.com/akitaonrails/ghpending/issues.

Instalação

Três caminhos, escolhe o que mais combina com seu setup.

Via Homebrew (macOS ou Linux):

brew tap akitaonrails/tap && brew install ghpending

Via Cargo:

cargo install ghpending

Via mise:

mise use -g github:akitaonrails/ghpending

Atualizando

# Homebrew
brew upgrade ghpending

# Cargo
cargo install ghpending --force

# mise
mise upgrade ghpending

# From source
cd ghpending && git pull && cargo install --path .

Uso

Quatro comandos. O fluxo normal é rodar ghpending add uma vez pra configurar quais repos você quer monitorar, depois é só ghpending quando quiser ver o digest.

ghpending add    # pick os repos de um usuário ou org pra monitorar
ghpending        # imprime o digest de issues e PRs abertos
ghpending list   # mostra os repos monitorados
ghpending rm     # tira repos do monitoramento via menu interativo

O add pergunta o usuário ou organização, lista os repos públicos, e deixa você marcar os que quer acompanhar. O username fica salvo, então rodar add de novo já pula essa pergunta.

O comando principal (ghpending sem argumentos) busca todos os repos monitorados em paralelo e mostra a tabela com issues e PRs abertos.

Token do GitHub (opcional)

Sem autenticação funciona, mas o GitHub limita em 60 requisições por hora pra anônimo. Pra subir esse teto pra 5.000 req/h, exporta um token:

GITHUB_TOKEN=$(gh auth token) ghpending

Ele é lido silenciosamente na inicialização, não precisa configurar nada.

Onde fica o config

• Linux: ~/.config/ghpending/config.toml
• macOS: ~/Library/Application Support/ghpending/config.toml

Você pode editar direto se quiser reordenar ou trocar o user. Estrutura:

user = "akitaonrails"
repos = ["akitaonrails/ai-memory", "akitaonrails/ai-jail"]

Por que esse CLI existe

A real é simples: ferramenta que eu fizesse pra mim mesmo, eu uso. Ferramenta de outro autor, sempre tem fricção (login web, opinião arquitetural diferente, feature que faltou ou sobrou). Como o objetivo era reduzir o atrito de checar 30 repos por semana, melhor 200 linhas de Rust escritas num sábado à tarde do que aprender um stack novo.

Agora espero conseguir responder as pendências dos colaboradores mais rápido. Se você achar útil, é MIT, PRs são bem-vindos.

Ainda não entendi o quanto faz diferença ou não, mas tanto OpenCode quanto Crush tem suporte a Language Servers (LSPs) então achei legal deixar configurado. Eis meu ~/.config/crush/crush.json:

{
  "$schema": "https://charm.land/crush.json",
  "default_provider": "openrouter",
  "providers": {
    "openrouter": {
      "api_key": "sk-..."
    },
    "lmstudio": {
      "name": "LM Studio",
      "base_url": "http://localhost:1234/v1/",
      "type": "openai",
      "models": [
        {
          "name": "gpt-oss-120b",
          "id": "gpt-oss:120b",
          "context_window": 100000,
          "default_max_tokens": -1,
          "supports_tools": true
        },
        {
          "name": "gpt-oss-20b",
          "id": "gpt-oss:20b",
          "context_window": 130000,
          "default_max_tokens": -1,
          "supports_tools": true
        },
        {
          "name": "zai-org/glm-4.6v-flash",
          "id": "glm-4.6v-flash",
          "context_window": 130000,
          "default_max_tokens": -1,
          "supports_tools": true
        },
        {
          "name": "deepseek-coder-v2-lite-instruct",
          "id": "deepseek-coder-v2-lite-instruct",
          "context_window": 64000,
          "default_max_tokens": -1,
          "supports_tools": true
        },
        {
          "id": "qwen/qwen3-coder-30b",
          "name": "qwen3-coder-30b",
          "context_window": 120000,
          "default_max_tokens": -1,
          "supports_tools": true
        }
      ]
    },
    "ollama": {
      "type": "openai-compat",
      "base_url": "http://127.0.0.1:11434/v1",
      "api_key": "ollama",
      "models": [
        {
          "name": "glm-4.7-flash",
          "id": "glm-4.7-flash",
          "context_window": 65536,
          "default_max_tokens": -1,
          "supports_tools": true
        },
        {
          "name": "gpt-oss-20b",
          "id": "gpt-oss:20b",
          "context_window": 64000,
          "default_max_tokens": -1,
          "supports_tools": true
        },
        {
          "id": "qwen3-nuclear",
          "name": "qwen3-nuclear",
          "context_window": 120000,
          "default_max_tokens": -1,
          "supports_tools": true
        },
        {
          "id": "qwen3-coder:30b",
          "name": "qwen3-coder:30b",
          "context_window": 120000,
          "default_max_tokens": -1,
          "supports_tools": true
        },
        {
          "id": "qwen2.5-coder:32b",
          "name": "qwen2.5-coder:32b",
          "context_window": 32768,
          "default_max_tokens": -1,
          "supports_tools": true
        },
        {
          "id": "deepseek-coder-v2:16b",
          "name": "deepseek-coder-v2:16b",
          "context_window": 128000,
          "default_max_tokens": -1,
          "supports_tools": true
        },
        {
          "id": "glm-4.7:cloud",
          "name": "glm-4.7:cloud",
          "context_window": 128000,
          "default_max_tokens": -1,
          "supports_tools": true
        }
      ]
    }
  },
  "lsp": {
    "gopls": {
      "command": "gopls"
    },
    "rust-analyzer": {
      "command": "rust-analyzer"
    },
    "ruby-lsp": {
      "command": "ruby-lsp"
    },
    "solargraph": {
      "command": "solargraph",
      "args": [
        "stdio"
      ]
    },
    "pylsp": {
      "command": "pylsp"
    },
    "pyright": {
      "command": "pyright-langserver",
      "args": [
        "--stdio"
      ]
    },
    "elixir-ls": {
      "command": "elixir-ls"
    },
    "docker-langserver": {
      "command": "docker-langserver",
      "args": [
        "--stdio"
      ],
      "languages": [
        "dockerfile"
      ]
    },
    "bash-language-server": {
      "command": "bash-language-server",
      "args": [
        "start"
      ]
    },
    "marksman": {
      "command": "marksman",
      "args": [
        "server"
      ]
    },
    "typescript-language-server": {
      "command": "typescript-language-server",
      "args": [
        "--stdio"
      ]
    },
    "vscode-html-language-server": {
      "command": "vscode-html-language-server",
      "args": [
        "--stdio"
      ]
    },
    "vscode-css-language-server": {
      "command": "vscode-css-language-server",
      "args": [
        "--stdio"
      ]
    },
    "vscode-json-language-server": {
      "command": "vscode-json-language-server",
      "args": [
        "--stdio"
      ]
    },
    "yaml-language-server": {
      "command": "yaml-language-server",
      "args": [
        "--stdio"
      ]
    },
    "taplo": {
      "command": "taplo",
      "args": [
        "lsp",
        "stdio"
      ]
    }
  },
  "mcp": {
    "blender": {
      "type": "stdio",
      "command": "uvx",
      "args": [
        "blender-mcp"
      ]
    }
  }
}

Notem que eu uso primariamente Claude Opus 4.5 via OpenRouter e tenho LM Studio e Ollama configurados como providers pra testar outros modelos open source.

Também uso Mise pra organizar as linguagens de programação que uso.

Porém, agora precisa instalar os LSPs de cada linguagem. Eu não conheço um jeito melhor de gerenciar isso da mesma forma como com um Mason no Neovim. Então fiz um script pra instalar tudo pra mim (no meu Arch Linux). Pra isso criei este script ~/.local/bin/install-lsps.sh:

#!/usr/bin/env bash
set -euo pipefail

# LSP Installer for Arch Linux with Mise
# Installs major LSPs using native package managers or yay
# Only installs LSPs for languages that are already installed

GREEN='\033[0;32m'
BLUE='\033[0;34m'
YELLOW='\033[1;33m'
RED='\033[0;31m'
NC='\033[0m'

info() { echo -e "${BLUE}[INFO]${NC} $1"; }
success() { echo -e "${GREEN}[OK]${NC} $1"; }
warn() { echo -e "${YELLOW}[SKIP]${NC} $1"; }
skip_lang() { echo -e "${RED}[LANG]${NC} $1 not installed, skipping LSPs"; }

command_exists() { command -v "$1" &>/dev/null; }

# ─────────────────────────────────────────────────────────────
# Language detection helpers
# ─────────────────────────────────────────────────────────────
has_c()       { command_exists gcc || command_exists clang; }
has_rust()    { command_exists rustc || command_exists cargo; }
has_go()      { command_exists go; }
has_python()  { command_exists python || command_exists python3; }
has_node()    { command_exists node || command_exists npm; }
has_java()    { command_exists java || command_exists javac; }
has_kotlin()  { command_exists kotlin || command_exists kotlinc; }
has_ruby()    { command_exists ruby; }
has_php()     { command_exists php; }
has_lua()     { command_exists lua || command_exists luajit; }
has_zig()     { command_exists zig; }
has_haskell() { command_exists ghc || command_exists stack || command_exists cabal; }
has_elixir()  { command_exists elixir || command_exists iex; }
has_scala()   { command_exists scala || command_exists sbt; }
has_dotnet()  { command_exists dotnet; }
has_ocaml()   { command_exists ocaml || command_exists opam; }
has_clojure() { command_exists clojure || command_exists clj || command_exists lein; }
has_nix()     { command_exists nix; }
has_terraform() { command_exists terraform || command_exists tofu; }
has_latex()   { command_exists latex || command_exists pdflatex || command_exists xelatex; }
has_docker()  { command_exists docker || command_exists podman; }
has_ansible() { command_exists ansible; }
has_sql()     { command_exists psql || command_exists mysql || command_exists sqlite3; }
has_bash()    { command_exists bash; }

# ─────────────────────────────────────────────────────────────
# Package installation helpers
# ─────────────────────────────────────────────────────────────
install_pacman() {
    local pkg="$1"
    if pacman -Qi "$pkg" &>/dev/null; then
        warn "$pkg already installed"
    else
        sudo pacman -S --noconfirm --needed "$pkg" && success "$pkg" || warn "Failed: $pkg"
    fi
}

install_yay() {
    local pkg="$1"
    if ! command_exists yay; then
        warn "yay not found, skipping $pkg"
        return
    fi
    if yay -Qi "$pkg" &>/dev/null; then
        warn "$pkg already installed"
    else
        yay -S --noconfirm --needed "$pkg" && success "$pkg" || warn "Failed: $pkg"
    fi
}

install_npm() {
    local pkg="$1"
    if npm list -g "$pkg" &>/dev/null 2>&1; then
        warn "$pkg already installed"
    else
        npm install -g "$pkg" && success "$pkg" || warn "Failed: $pkg"
    fi
}

install_pipx() {
    local pkg="$1"
    if ! command_exists pipx; then
        pip install --user pipx 2>/dev/null || {
            pip install --user "$pkg" && success "$pkg" || warn "Failed: $pkg"
            return
        }
    fi
    if pipx list 2>/dev/null | grep -q "$pkg"; then
        warn "$pkg already installed"
    else
        pipx install "$pkg" && success "$pkg" || warn "Failed: $pkg"
    fi
}

install_go() {
    local pkg="$1"
    local name="${pkg##*/}"
    name="${name%%@*}"
    
    # Check if binary already exists in GOPATH/bin
    local gobin="${GOBIN:-${GOPATH:-$HOME/go}/bin}"
    if [[ -x "$gobin/$name" ]]; then
        warn "$name already installed"
        return
    fi
    
    go install "$pkg" && success "$name" || warn "Failed: $name"
}

install_gem() {
    local pkg="$1"
    if gem list -i "^${pkg}$" &>/dev/null; then
        warn "$pkg already installed"
    else
        gem install "$pkg" && success "$pkg" || warn "Failed: $pkg"
    fi
}

# ─────────────────────────────────────────────────────────────
# C/C++ LSPs
# ─────────────────────────────────────────────────────────────
install_c_lsps() {
    if ! has_c; then
        skip_lang "C/C++ (gcc/clang)"
        return
    fi
    info "Installing C/C++ LSPs..."
    install_pacman clang  # includes clangd
}

# ─────────────────────────────────────────────────────────────
# Rust LSPs
# ─────────────────────────────────────────────────────────────
install_rust_lsps() {
    if ! has_rust; then
        skip_lang "Rust"
        return
    fi
    info "Installing Rust LSPs..."
    
    if command_exists rustup; then
        rustup component add rust-analyzer 2>/dev/null && success "rust-analyzer (rustup)" || install_pacman rust-analyzer
    else
        install_pacman rust-analyzer
    fi
}

# ─────────────────────────────────────────────────────────────
# Go LSPs
# ─────────────────────────────────────────────────────────────
install_go_lsps() {
    if ! has_go; then
        skip_lang "Go"
        return
    fi
    info "Installing Go LSPs..."
    
    install_go golang.org/x/tools/gopls@latest
    install_go github.com/go-delve/delve/cmd/dlv@latest
    install_go github.com/nametake/golangci-lint-langserver@latest
}

# ─────────────────────────────────────────────────────────────
# Python LSPs
# ─────────────────────────────────────────────────────────────
install_python_lsps() {
    if ! has_python; then
        skip_lang "Python"
        return
    fi
    info "Installing Python LSPs..."
    
    # Prefer npm pyright (faster updates) if node available
    if has_node; then
        install_npm pyright
    else
        install_pipx pyright
    fi
    
    install_pipx python-lsp-server
    install_pipx ruff-lsp
}

# ─────────────────────────────────────────────────────────────
# Node.js/TypeScript LSPs
# ─────────────────────────────────────────────────────────────
install_node_lsps() {
    if ! has_node; then
        skip_lang "Node.js"
        return
    fi
    info "Installing Node.js/TypeScript LSPs..."
    
    install_npm typescript
    install_npm typescript-language-server
    install_npm vscode-langservers-extracted  # HTML, CSS, JSON, ESLint
    install_npm "@tailwindcss/language-server"
    install_npm "@vue/language-server"
    install_npm svelte-language-server
    install_npm graphql-language-service-cli
    install_npm "@prisma/language-server"
    install_npm emmet-ls
}

# ─────────────────────────────────────────────────────────────
# Java LSPs
# ─────────────────────────────────────────────────────────────
install_java_lsps() {
    if ! has_java; then
        skip_lang "Java"
        return
    fi
    info "Installing Java LSPs..."
    install_yay jdtls
}

# ─────────────────────────────────────────────────────────────
# Kotlin LSPs
# ─────────────────────────────────────────────────────────────
install_kotlin_lsps() {
    if ! has_kotlin; then
        skip_lang "Kotlin"
        return
    fi
    info "Installing Kotlin LSPs..."
    install_yay kotlin-language-server
}

# ─────────────────────────────────────────────────────────────
# Ruby LSPs
# ─────────────────────────────────────────────────────────────
install_ruby_lsps() {
    if ! has_ruby; then
        skip_lang "Ruby"
        return
    fi
    info "Installing Ruby LSPs..."
    install_gem solargraph
    install_gem ruby-lsp
}

# ─────────────────────────────────────────────────────────────
# PHP LSPs
# ─────────────────────────────────────────────────────────────
install_php_lsps() {
    if ! has_php; then
        skip_lang "PHP"
        return
    fi
    if ! has_node; then
        warn "PHP LSP (intelephense) requires npm, skipping"
        return
    fi
    info "Installing PHP LSPs..."
    install_npm intelephense
}

# ─────────────────────────────────────────────────────────────
# Lua LSPs
# ─────────────────────────────────────────────────────────────
install_lua_lsps() {
    if ! has_lua; then
        skip_lang "Lua"
        return
    fi
    info "Installing Lua LSPs..."
    install_pacman lua-language-server
}

# ─────────────────────────────────────────────────────────────
# Zig LSPs
# ─────────────────────────────────────────────────────────────
install_zig_lsps() {
    if ! has_zig; then
        skip_lang "Zig"
        return
    fi
    info "Installing Zig LSPs..."
    install_pacman zls
}

# ─────────────────────────────────────────────────────────────
# Haskell LSPs
# ─────────────────────────────────────────────────────────────
install_haskell_lsps() {
    if ! has_haskell; then
        skip_lang "Haskell"
        return
    fi
    info "Installing Haskell LSPs..."
    install_yay haskell-language-server
}

# ─────────────────────────────────────────────────────────────
# Elixir LSPs
# ─────────────────────────────────────────────────────────────
install_elixir_lsps() {
    if ! has_elixir; then
        skip_lang "Elixir"
        return
    fi
    info "Installing Elixir LSPs..."
    install_yay elixir-ls
}

# ─────────────────────────────────────────────────────────────
# Scala LSPs
# ─────────────────────────────────────────────────────────────
install_scala_lsps() {
    if ! has_scala; then
        skip_lang "Scala"
        return
    fi
    info "Installing Scala LSPs..."
    install_yay metals
}

# ─────────────────────────────────────────────────────────────
# C# / F# (.NET) LSPs
# ─────────────────────────────────────────────────────────────
install_dotnet_lsps() {
    if ! has_dotnet; then
        skip_lang ".NET (C#/F#)"
        return
    fi
    info "Installing .NET LSPs..."
    install_yay omnisharp-roslyn
    install_yay fsautocomplete
}

# ─────────────────────────────────────────────────────────────
# OCaml LSPs
# ─────────────────────────────────────────────────────────────
install_ocaml_lsps() {
    if ! has_ocaml; then
        skip_lang "OCaml"
        return
    fi
    info "Installing OCaml LSPs..."
    if command_exists opam; then
        opam install ocaml-lsp-server -y && success "ocaml-lsp-server" || warn "Failed"
    else
        install_yay ocaml-lsp-server
    fi
}

# ─────────────────────────────────────────────────────────────
# Clojure LSPs
# ─────────────────────────────────────────────────────────────
install_clojure_lsps() {
    if ! has_clojure; then
        skip_lang "Clojure"
        return
    fi
    info "Installing Clojure LSPs..."
    install_yay clojure-lsp-bin
}

# ─────────────────────────────────────────────────────────────
# Nix LSPs
# ─────────────────────────────────────────────────────────────
install_nix_lsps() {
    if ! has_nix; then
        skip_lang "Nix"
        return
    fi
    info "Installing Nix LSPs..."
    install_pacman nil
}

# ─────────────────────────────────────────────────────────────
# Bash LSPs
# ─────────────────────────────────────────────────────────────
install_bash_lsps() {
    if ! has_bash; then
        skip_lang "Bash"
        return
    fi
    info "Installing Bash LSPs..."
    install_pacman bash-language-server
}

# ─────────────────────────────────────────────────────────────
# Terraform LSPs
# ─────────────────────────────────────────────────────────────
install_terraform_lsps() {
    if ! has_terraform; then
        skip_lang "Terraform"
        return
    fi
    info "Installing Terraform LSPs..."
    install_pacman terraform-ls
}

# ─────────────────────────────────────────────────────────────
# LaTeX LSPs
# ─────────────────────────────────────────────────────────────
install_latex_lsps() {
    if ! has_latex; then
        skip_lang "LaTeX"
        return
    fi
    info "Installing LaTeX LSPs..."
    install_pacman texlab
}

# ─────────────────────────────────────────────────────────────
# Docker LSPs
# ─────────────────────────────────────────────────────────────
install_docker_lsps() {
    if ! has_docker; then
        skip_lang "Docker"
        return
    fi
    info "Installing Docker LSPs..."
    install_yay dockerfile-language-server
}

# ─────────────────────────────────────────────────────────────
# Ansible LSPs
# ─────────────────────────────────────────────────────────────
install_ansible_lsps() {
    if ! has_ansible; then
        skip_lang "Ansible"
        return
    fi
    if ! has_node; then
        warn "Ansible LSP requires npm, skipping"
        return
    fi
    info "Installing Ansible LSPs..."
    install_npm "@ansible/ansible-language-server"
}

# ─────────────────────────────────────────────────────────────
# SQL LSPs
# ─────────────────────────────────────────────────────────────
install_sql_lsps() {
    if ! has_sql; then
        skip_lang "SQL (psql/mysql/sqlite)"
        return
    fi
    info "Installing SQL LSPs..."
    install_pacman sqls
}

# ─────────────────────────────────────────────────────────────
# Generic config file LSPs (always install)
# ─────────────────────────────────────────────────────────────
install_generic_lsps() {
    info "Installing generic config LSPs (YAML, TOML, JSON, Markdown, XML)..."
    install_pacman yaml-language-server
    install_pacman taplo               # TOML
    install_pacman marksman            # Markdown
    install_yay lemminx                # XML
}

# ─────────────────────────────────────────────────────────────
# Main
# ─────────────────────────────────────────────────────────────
main() {
    echo "═══════════════════════════════════════════════════════════"
    echo "         LSP Installer for Arch Linux + Mise"
    echo "    (Only installs LSPs for detected languages)"
    echo "═══════════════════════════════════════════════════════════"
    echo
    
    # Language-specific LSPs
    install_c_lsps
    install_rust_lsps
    install_go_lsps
    install_python_lsps
    install_node_lsps
    install_java_lsps
    install_kotlin_lsps
    install_ruby_lsps
    install_php_lsps
    install_lua_lsps
    install_zig_lsps
    install_haskell_lsps
    install_elixir_lsps
    install_scala_lsps
    install_dotnet_lsps
    install_ocaml_lsps
    install_clojure_lsps
    install_nix_lsps
    install_bash_lsps
    install_terraform_lsps
    install_latex_lsps
    install_docker_lsps
    install_ansible_lsps
    install_sql_lsps
    
    echo
    # Always-useful LSPs for config files
    install_generic_lsps
    
    echo
    echo "═══════════════════════════════════════════════════════════"
    success "LSP installation complete!"
    echo "═══════════════════════════════════════════════════════════"
}

main "$@"

Teoricamente é só isso. Se alguém conhecer um jeito melhor, mande nos comentários abaixo.

Vou fazer somente este um artigo sobre isso e não pretendo cobrir mais do que a ponta do Iceberg. A idéia é servir pra quem está vindo de outros editores como Sublime Text ou VS Code e não consegue começar a navegar ou até mesmo quitar do Vim kkk 🤣.

Comandos Iniciais

Como falei no post anterior sobre LazyVim, vou assumir que já entendeu pelo menos como instalar suporte à sua linguagem com LazyExtras e já aprendeu a versionar usando Mise.

Sem nem entrar no LazyVim, a primeira coisa a saber é que ele instala todas as configurações relevantes no diretório ~/.config/nvim. Normalmente não precisa mexer nada lá. Deixa arquivos como lazyvim.json sem mexer. Notem que ele faz a mesma coisa quem um NPM da vida: tem um arquivo lazy-lock.json que declara a versão/commit de cada plugin instalado. O Lazyvim faz algo parecido com um npm install da vida. Só curiosidade pra você saber como ele se organiza.

Se precisar customizar algo, normalmente vai ser no diretório ~/.config/nvim/lua/config. Foi lá onde eu adicionei suporte a Mise, por exemplo:

~/.config/nvim
❯ cat lua/config/mise.lua
-- Prepend mise shims to PATH
vim.env.PATH = vim.env.HOME .. "/.local/share/mise/shims:" .. vim.env.PATH

Vão ser sempre scripts escritos em Lua. E nem precisa saber Lua a fundo. De bater o olho é uma linguagem muito simples, não muito diferente de um Python ou Javascript e qualquer programador deve ser capaz de ler qualquer trecho sem nenhum problema. Além disso, na maioria dos casos você vai copiar configurações que tirou da documentação, wiki ou chatgpt mesmo, então é só saber que as coisas vão nesse local.

Entenda que NeoVim tem o conceito de tecla “Leader”, é uma tecla que precede hotkeys pra outros comandos (também tem localleader que é barra invertida \). Isso é configurável mas no LazyVim o Leader é a tecla “Espaço/Space”. Em muita documentação vamos ver falando “apertem Leader-w”, que significa Espaço+w e agora você sabe o que isso significa.

Pra abrir um arquivo tem pelo menos 3 formas diferentes, 2 delas mostradas na foto acima:

Space+E abre o NeoTree que é esse sidebar na esquerda que se parece com o Windows Explorer. Dá pra navegar com teclado ou com mouse mesmo. Ache seu arquivo e pressione “Enter” pra abrir, daí “Space+E” de novo pra esconder o sidebar. Se quiser saber como criar um novo arquivo, um novo sub-diretório, renomear e tals, digite ? (tecla de interrogação) pra ver esta ajuda:

A terceira forma é manualmente com o comando :e seguida do nome do arquivo no diretório local. Tem auto-complete também, esse é o jeito mais rápido, se souber o que está procurando.

Sempre que quiser cancelar qualquer coisa ou fechar “floating windows” (pop-ups, dialog boxes). Só apertar “Esc”. Esc é fundamental no NeoVim.

Aberto um arquivo, ele fica no Buffer. Pense em Buffer como “Abas Abertas” no seu VS Code. Pra navegar por Buffer (tipo alt+tab entre seus arquivos já abertos) é simples:

• ]+b pra próxima “aba” (próximo Buffer)
• [+b Buffer anterior
• Space+bd pra “fechar a aba” (fechar o Buffer)
• Space+bo pra ficar onde está e fechar os outros buffers

Abra quantos arquivos quiser. Se um deles for um daqueles logs enormes que abriu por acidente, Space+bd pra fechar e pronto.

Falando em fechar, como que sai do NeoVim? Tem vários jeitos:

• Space+q
• :q
• :q!

A diferença: o primeiro é o jeito customizado no LazyVim. O Segundo é o jeito padrão usando o recurso de “comandos” que começa sempre com “dois pontos”. E o terceiro é se você modificou algo no arquivo mas cancelar, sair sem salvar nada, por isso a exclamação.

Normalmente eu uso :wq que significa “write” e “quit”. Então ele primeiro salva as mudanças no arquivo e depois já quita do programa. É útil quando estou só editando um arquivo de configuração rápido.

Navegação Básica

Agora tenho um arquivo aberto. Como navegar por ele? Primeiro, como ir até o fim do arquivo e depois voltar pro começo do arquivo? É uma coisa que uso bastante, só digitar Shift+g pra ir pro fim do arquivo e depois gg pra voltar pro começo. Simples assim.

Agora vamos aprender vários comandos de uma só vez:

• Digite v. Isso inicia o “modo de visualização” que, na prática, significa começar a selecionar a partir de onde se encontra seu cursor.
• Digite j. Que é o equivalente à “seta pra baixo” pra ir pra linha de baixo. Já deve ter ouvido falar que em Vim se navega com “hjkl” que são, respectivamente, pra esquerda, pra baixo, pra cima, pra direita.
• Digite x. Que é o equivalente a “cortar” e colocar o conteúdo no clipboard. Feito isso, digitando p você dá “paste”, que é colar.
• Digite u. Que é o comando que mais se usa: o de Undo ou desfazer a última modificação.

Isso tudo funciona no chamado “modo de comando”, que é o modo padrão que o Vim abre todo arquivo. Nesse modo não dá pra digitar nenhum texto. Como podem ver, cada letra sozinha é um comando, como “x” pra cut ou “p” pra paste.

Pra digitar, primeiro precisa digitar i (só a letra “i” em minúsculo), que daí muda do modo de comando pro “modo de edição”. Agora é só digitar seu texto normalmente, como em qualquer editor. Quando quiser algum comando, basta digitar ESC pra voltar pro modo de comando. Vamos fazer isso o tempo todo, por isso muita gente re-mapeia a tecla “caps lock” do teclado pra ser a ESC e ficar fácil só tocar com o mindinho esquerdo.

Combinando Comandos

Ainda no modo de comando, como navegamos pelo arquivo mais fácil?

Além das teclas “hjkl”, podemos navegar mais fácil usando b pra “palavra anterior” ou w pra palavra (word) posterior:

O modo de comando permite combinar comandos, portanto podemos fazer:

• dw pra apagar a próxima palavra
• db pra apagar a palavra anterior
• d4w pra apagar (delete) as 4 palavras (words) seguintes
• d4j pra apagar as 4 linhas pra baixo

O tutorial do Primeagen tem vários exercícios pra esse tipo de navegação, recomendo se exercitar. Num VS Code todo mundo está acostumado a primeiro pegar o mouse, marcar o bloco que quer apagar visualmente, depois apertar delete ou backspace. No Vim, olhamos onde está o cursor, apertamos ESC pra estar no modo de comando, e digitamos a operação e a localização. Teste todas as combinações que conseguir imaginar.

Esta é a mudança de paradigma que incomoda os preguiçosos. Mas uma vez aprendido isso, você vai achar incômodo um editor que te obrigado a usar mouse pra coisas básicas.

Agora fica mais interessante: e se em vez de apagar uma palavra, eu queira substituir a palavra onde meu cursor está pra outra palavra?

Num editor normal, você marcaria com o mouse (ou usando alguma combinação como “ctrl+shift+seta”), e digitaria por cima ou apagaria a palavra.

No LazyVim tem plugins configurados pra coisas mais interessantes. No video acima veja como estou substituindo palavras “in-place”. Isso se faz com o comando ciw.

• ciw apaga a palavra inteira embaixo do cursor e abre o modo de edição pra você digitar a substituição
• ce apaga a partir do cursor até o fim da palavra (preserva o começo da palavra) e também abre pra você digitar no lugar
• Shift-c (C maiúsculo) apaga tudo a partir do seu cursor até o fim da linha inteira e abre pra você digitar.

Mas isso ainda não parece tãaaaao legal. E se quiser mudar só a primeira letra de várias linhas ao mesmo tempo, por exemplo, no texto do video acima, quero mudar só o hífen ("-") de cada linha de tags?

Falei antes que apertando v no modo de comando ele começa o modo de visualização e dá pra selecionar a partir dali. Mas existe Ctrl+v que abre o modo de marcação de blocos verticais.

Nesse modo usamos as teclas “hjkl” normalmente, como j pra ir pra baixo, mas em vez de marcar a próxima linha inteira, ele marca só o caracter logo abaixo do seu cursor. Agora posso apagar com d e digitar Shift-i (“I” maiúsculo) pra entrar em modo de edição no começo do bloco e substituir pelo que quiser.

LazyVim tem plugins pra comentários, mas essa é outra alternativa se quiser adicionar “//” ou “#” no começo de várias linhas pra comentar, por exemplo. No caso, leia sobre o plugin ts-comments pra opções melhores pra comentário. Pra iniciar um novo bloco de comentário, digite gco pra adicionar um comentário abaixo.

“Modo de bloco” como mostrei acima, é uma das coisas que eu mais uso em código.

Mas só isso é muito pouco. E se quiser substituir TODAS AS PALAVRAS iguais do texto de uma só vez. No video de exemplo acima, quero substituir “domínio” por “DOMAIN” e “Cloudflare” por “AWS Amazon”, como faço? Isso é “Search and Replace” que tem em todo editor e em Vim é muito fácil:

Digitamos :%s/domínio/DOMAIN/.

Se você é programador já deve ter visto essa sintaxe antes. É a sintaxe de REGEX MATCH. Sim, tem que saber Regex (e não, não é nem PCRE e nem Unicode, é um dialeto de Regex do próprio NeoVim, mas é parecido).

Como falei antes, “dois pontos” abre o box de digitar comandos, "%s" inicia “search com regex” e entre as barras “//” primeiro vai o que procura e depois com o que quer substituir.

Mas esse é o jeito no NeoVim puro, no LazyVim, tem o plugin grug-far e se ativa com o comando SPACE+sr:

Agora sim, mais parecido com do VS Code, né? Use o que achar mais fácil.

Conclusão

Como falei, isto é somente a ponta da ponta do iceberg, o mínimo do mínimo suficiente pra pelo menos começar editando arquivos simples de configuração sem abrir Nano ou VS Code só pra isso.

Leia a documentação do LazyVim. Veja os keymaps pra descobrir outros comandos. Preste atenção em cada letra que aperta no modo de comando, o LazyVim mostra as opções disponíveis. Por exemplo, digamos que eu apertei g (goto), ele vai mostrar uma ajuda no canto inferior direito:

Assim você sempre pode descobrir novos comandos ou relembrar comandos que usa pouco. Por isso recomendo o LazyVim, que já vem bem configurado pra te ajudar. Quem faz essa funcionalidade é o plugin which-key, caso queira a mesma coisa num NeoVim que você configurou do zero.

Existem diversos Cheatsheets por aí com tabelas de combinações de comandos importantes. Vale explorar.

Mas não é só isso, LazyVim vem com dezenas de plugins pra formatação, linting, LSP integrado, GIT integrado, e muito mais. Não tem como eu documentar um a um aqui. Cada um deles tem sua própria documentação na página de plugins do LazyVim.org.

Novamente, não esqueça de chamar o :LazyExtras e instalar os plugins opcionais das suas linguagens.

Os apps mais “modernos” são basicamente front-ends web enlatados dentro de um wrapper Electron. O problema? São PESADOS consomem RAM como se não houvesse amanhã. Comece a abrir Discord, Spotify, e vários desses e veja se seu notebook velho de 8GB de RAM vai aguentar.

Mas, especialmente se você é um programador, deveria dar mais atenção pra TUIs. Num primeiro momento alguns devem virar o nariz: “apps de terminal são feios, preto e branco, quadrados, blerg”

Se fosse 20 anos atrás, estariam certos. Mas é 2025 e hoje em dia terminais suportam 256 cores (mais que suficiente), suportam várias resoluções e, mais importante, suportam fontes, em particular Nerd Fonts, fontes que tem ícones dentro. É assim que funciona uma ferramenta como eza, que eu uso todo dia com alias pra ls e fica assim:

Não é só isso, existem bibliotecas modernas, pra diversas linguagens, como BubbleTea, que é um framework pra construir TUIs. Chequem o GitHub deles mas tem as ferramentas pra fazer interfaces assim:

E se quiser só um widget simples pra complementar um script Bash que está fazendo, eles tem o Gum, que permite interfaces assim:

E pra usar é só instalar o binário e no seu script fazer linhas assim:

# exemplos de Gum
gum choose "fix" "feat" "docs" "style" "refactor" "test" "chore" "revert"

gum input --placeholder "scope"

gum confirm "Commit changes?" && git commit -m "$SUMMARY" -m "$DESCRIPTION"

E se usa Omarchy eles ainda trazem uma funcionalidade extra pra TUIs. Basta clicar “SUPER+ALT+SPACE” pra trazer o menu principal, depois escolher “INSTALL” e “TUI”. Ou simplesmente abrir o terminal e executar:

$OMARCHY_PATH/bin/omarchy-tui-install

Ele vai pedir um nome pro App e a linha de comando pra executar. Dá pra escolher icones também no Dashboard Icons. Registrando dessa forma, quando chamar o launcher Rofi com “SUPER+SPACE” e digitar “lazy” vai aparecer o LazyDocker como se fosse um app normal:

E como em Hyprland não tem barra de título nem nada, apps TUI ou webapps (tem omarchy-webapp-install também) abrem como se fossem apps “nativos”:

Leiam as seções de TUIs e Web-Apps no manual do Omarchy.

Obviamente, isso é só se você é daqueles que prefere a sensação de estar executando “Apps”, mas é a mesma coisa se abrir um Terminal e simplesmente digitar o lazydocker na linha de comando - que é minha preferência. O que esses scripts do Omarchy fazem é criar um arquivo .desktop em ~/.local/share/applications. O exemplo do LazyDocker.desktop gera isto:

❯ cat ~/.local/share/applications/LazyDocker.desktop
[Desktop Entry]
Version=1.0
Name=LazyDocker
Comment=LazyDocker
Exec=alacritty --class TUI.tile -e lazydocker
Terminal=false
Type=Application
Icon=/home/akitaonrails/.local/share/applications/icons/LazyDocker.png
StartupNotify=true

Se não quiser mais este launcher é só apagar o arquivo ou chamar o script $OMARCHY_PATH/bin/omarchy-tui-remove.

Esse recurso é particularmente interessante no Hyprland porque diferente de GNOME ou KDE, a janela não tem barra superior de título, então não entrega que você está só abrindo um terminal ou navegador web. É assim que ele já vem pré-configurado com coisas como ChatGPT ou Grok parecendo que são apps “nativos”, mas na verdade são só janelas de Chromium abrindo direto as URLs de cada um:

Alguns TUIs que eu gosto

Na minha opinião, já que não tem Apps com GUIs bonitas pra Linux, é melhor mesmo usar os respectivos web-apps como Canva ou ChatGPT dessa forma, mas mais interessante é ter TUIs mesmo. Como falei, hoje em dia não é difícil fazer TUIs bonitas. Pra um programador, a vantagem é não tem que lidar, primeiro com frameworks de front-end, segundo, ter que fazer deploy em algum lugar na internet.

TUIs são leves, usam poucos recursos na máquina, são fáceis pra qualquer programador fazer, e você pode ter um home server ou um servidor num cloud qualquer, acessar via SSH e acessar a TUI, sem ter que lidar com X11 ou RDP ou qualquer coisa mais pesada só pra ter um GUI.

Alguns TUIs são óbvios, no post anterior já falei de LazyVim e como ele é um editor de textos tão competente e completo quando um VS Code, usando só uma fração dos recursos da máquina. Todo mundo deve conhecer ferramentas como HTOP ou BTOP. Além dos LazyGit ou LazyDocker também. Esses todos já vem no Omarchy.

Mas tem muito mais, por exemplo, dblab que é um TUI cliente de banco de dados como MySQL ou Postgres:

Outro similar é LazySQL, feito em Go:

Ou se você prefere ferramentas feitas em Rust, tem o rainfrog:

Pra quem não consegue usar CURL na linha de comando e prefere usar Postman pra chamar e explorar APIs, tem o TUI Posting que faz a mesma coisa:

Pra nós que rodamos muitos containers Docker, já falei do LazyDocker, mas tem também o oxker:

Se usar Discord, tem o discordo:

Quem faz muito ricing de Linux já teve que gravar ISOs em Pen Drives dezenas de vezes, pra isso tem o dd na linha de comando, mas tem um TUI mais legal que é o Caligula:

Se seu SSD está ficando cheio e você não sabe onde diabos que tá ocupando tanto espaço, tem várias ferramentas pra analisar e te mostrar, um deles é o gdu:

E o último que achei legal pela nostalgia é o sc-im, pense em Excel como TUI ou - pra nós que viemos dos anos 80 - pense Lotus 1-2-3 mas com key bindings de Vim:

Pra que abrir Google Spreadsheets só pra fazer um Todo list se dá pra fazer no Terminal?? TUIs são excepcionais!

Se quiser conhecer mais TUIs olhe o awesome-tuis no GitHub:

De novo: zero necessidade de front-ends web pesadas pra coisas simples. Nada supera a simplicidade de uma linha de comando. E com bibliotecas como BubbleTea ou Gum, está muito fácil pra qualquer um fazer um app bonito. E com Hyprland e Omarchy, fica tudo integrado lado-a-lado de qualquer outro app com GUI.

Filosofando um pouco, a história das GUIs começa com interfaces gráficas skeumorphic que tentam imitar objetos do nosso dia a dia, em particular parecendo pseudo-3D, como era um Windows 95. Chegou nos anos 2000 e começaram a migrar pra interfaces flat ou minimalistas, tirando completamente o skeumorphismo, deixando tudo plano. Foi a partir do Metro do Windows 8, principalmente. E eu acho que isso converge pra estilo mais de TUI, dando uma volta completa, voltando a como era nos terminais dos anos 70. Eu particularmente acho isso fascinante.

Mas não precisa usar estes menus. Vamos entender.

Num Arch Linux ou Ubuntu da vida, um amador instalaria ruby ou python fazendo algo assim:

# arch
yay -S ruby python3
# ubuntu
apt install ruby python3

Este é o jeito ERRADO.

Esses comandos vão instalar a versão mais nova de cada linguagens e toda vez que atualizar o sistema com yay -Syu ou apt upgrade, vai puxar as versões mais novas ainda.

Só que se você desenvolve projetos de verdade, não quer que as versões mudem.

A versão do deploy no servidor no cloud e a versão na sua máquina local TEM QUE SER AS MESMAS.

Se está usando Ruby v3.0.7 e Node.js 22.19.0, não pode ficar refém que quando atualizar seu sistema, do nada vai aparecer Ruby 3.4.5 e Node 24.7.0. Tudo vai começar a quebrar e você vai ficar super confuso sem saber porque. Esse é o erro mais primário que um júnior comete.

Pra evitar isso, cada projeto que está trabalhando PRECISA ESTAR TRAVADO EM VERSÕES FIXAS.

O jeito mais fácil de fazer isso em 2025 é usando MISE. Como falei, ele já vem instalado e ativado no Omarchy, mas se estiver usando outra distro basta instalar Mise manualmente:

yay -S mise

# .bashrc
eval $(mise activate bash)

Adapte isso pra ZSH, Fish ou outro shell que estiver usando, leia a documentação

Agora navegue pro diretório do seu projeto, por exemplo:

cd ~/Projects/AkitaOnRails.com

E trave as versões:

mise use ruby@3.2.3
mise use node@14.21.3

Isso vai criar o arquivo .tool-versions que você deve adicionar no git do seu repositório:

❯ cat .tool-versions
ruby 3.2.3
nodejs 14.21.3

❯ git add .tool-versions

E pronto, toda vez que fizer cd pro diretório, o Mise vai ativar exatamente a versão correta pra esse projeto. Veja:

AkitaOnRails.com [ master][$!?⇡][ v24.7.0][💎 v3.2.3]
❯ ruby -v
ruby 3.2.3 (2024-01-18 revision 52bb2ac0a6) [x86_64-linux]

AkitaOnRails.com [ master][$!?⇡][ v24.7.0][💎 v3.2.3]
❯ which ruby
/home/akitaonrails/.local/share/mise/installs/ruby/3.2.3/bin/ruby

Note que, se estiver usando o prompt Starship como expliquei no post anterior, com um preset como Pure Prompt, ele mostra no prompt as versões de cada linguagem pra que fique fácil de ver se estiver numa versão errada.

No caso, se leu com atenção, já deve ter notado que SIM, ESTOU NA VERSÃO ERRADA do Node.js. Olhem como no prompt ele fala que estou usando Node 24.7.0 mas no arquivo .tool-versions ele pede 14.21.3.

O motivo de estar “missing” é porque esta máquina é recém-instalada, mas o projeto é velho.

Então vamos checar:

AkitaOnRails.com [ master][$!?⇡][ v24.7.0][💎 v3.2.3]
❯ mise list
Tool    Version            Source                                              Requested
go      1.25.0             ~/.config/mise/config.toml                          latest
node    14.21.3 (missing)  /mnt/data/Projects/AkitaOnRails.com/.tool-versions  14.21.3
node    22.18.0
python  3.13.7
ruby    3.2.3              /mnt/data/Projects/AkitaOnRails.com/.tool-versions  3.2.3
ruby    3.4.5

Veja como na listagem de mise list ele fala que 14.21.3 está “missing”. Então vamos instalar:

AkitaOnRails.com [ master][$!?⇡][ v24.7.0][💎 v3.2.3]
❯ mise use node@14.21.3
mise /mnt/data/Projects/AkitaOnRails.com/.tool-versions tools: node@14.21.3

AkitaOnRails.com [ master][$!?⇡][ v14.21.3][💎 v3.2.3]
❯

Com o comando mise use podemos pedir pra instalar e usar uma versão em particular. Se já não estiver instalado, ele vai instalar. Note como depois disso o prompt do Starship mudou pra refletir que agora estamos usando 14.21.3. Esse é o jeito certo.

Se não estiver necessariamente num diretório de projeto com versões travadas, ainda assim é possível rodar comandos usando uma versão específica, assim:

mise exec ruby@3.2.1 -- ruby ...

Digamos que queira gerar um projeto de Rails numa versão específica de Ruby:

mise exec ruby@3.2.3 -- rails new todo-exercise

Mesma coisa vale pra generators em Node, como Next.js ou qualquer outro framework.

Não chequei se o LazyVim no Omarchy já vem configurado assim, mas caso não venha, pro NeoVim suportar Mise precisa adicionar isso:

-- Prepend mise shims to PATH
vim.env.PATH = vim.env.HOME .. "/.local/share/mise/shims:" .. vim.env.PATH

Basta colocar isso em ~/.config/nvim/lua/config/mise.lua que ele deve carregar o path correto. Pra integrar com outros editores, cheque esta documentação. Tem um MONTE de opções avançadas que é bom ler a respeito na seção de Dev-Tools mas o básico é o que listei aqui.

E bancos de dados??

O mesmo vale pra bancos de dados. Cada projeto deve estar travado numa versão específica idêntica à que está rodando no servidor de produção e nunca deve depender dos pacotes do sistema operacional. Dá pra usar mise pra isso mas o mais recomendado é usar Docker. Cada projeto DEVE ter um docker-compose.yml pra subir somente os bancos de dados. Não precisa subir containers pra linguagens, pra isso é melhor usar Mise.

Se não entende Docker, eu fiz videos ensinando:

Somando Mise + Docker Compose + LazyVim, é tudo que se precisa pra ser um desenvolvedor web produtivo, além de usar os recursos da sua máquina de maneira eficiente. Todo desenvolvedor PRECISA aprender este combo de opções. Omarchy já trás tudo pré-instalado, por isso tem sido minha recomendação pra todo iniciante.

Não precisa se preocupar: Arch Linux (com archinstall), é tão fácil de instalar quanto um Ubuntu ou Linux Mint e o Hyprland do Omarchy é muito mais bonito e fluido que um MacOS. O melhor dos mundos. Aprenda hoje!

Mesmo se não usa Omarchy, recomendo instalar LazyVim, só fazer isso:

# required
mv ~/.config/nvim{,.bak}

# optional but recommended
mv ~/.local/share/nvim{,.bak}
mv ~/.local/state/nvim{,.bak}
mv ~/.cache/nvim{,.bak}

git clone https://github.com/LazyVim/starter ~/.config/nvim

rm -rf ~/.config/nvim/.git

nvim

Pronto, é só isso. NeoVim, pra quem não sabe, é um fork mais moderno do antigo Vim (por isso o comando é nvim, reservando vim pro antigo). Ele troca o antigo VimScripts por scripts em Lua e tem várias otimizações e funcionalidades de qualidade de vida melhores. Hoje em dia, não tem porque usar o Vim antigo mais.

Usando Lua dá pra configurar o Nvim como quiser. Mas dá muito trabalho configurar tudo do zero. É um bom exercício, mas sendo prático, não compensa pro dia a dia. É melhor instalar um setup pré-configurado como os antigos LunarVim que eu usava antes e até recomendei em alguns videos de Linux do meu canal, ou o AstroNvim ou o LazyVim que atualmente é meu favorito. Qualquer um deles é um bom começo e vai ser preferência pessoal qual vai escolher.

Cada plugin que eles instalam tem diversas funcionalidades e combinações de teclas (hotkeys) próprias que precisa ler na documentação pra saber o que faz o que. Recomendo ir na seção plugins do site oficial e ler um por um. Tem muita coisa que você nem espera e todos são muito úteis.

LazyVim sozinho já ajuda bastante porque ele abre pop-ups documentando algumas das hotkeys. Por exemplo, o que se chama de comando Leader em LazyVim é a “barra de espaço”. Quando apertar, vai aparecer esse menu de contexto:

A partir daqui, se digitar, digamos “b”, vai aparece outro menu de contexto:

E se digitar “b” de novo, ele vai trocar pro próximo arquivo já aberto no Buffer. Buffer é o nome em Vim onde ficam os arquivos já abertos. Deletar do Buffer é o equivalente a “fechar o arquivo”.

Da próxima vez, não precisa olhar os menus, só digitar rápido de uma só vez: “Espaço+b+b”. E é assim que você vai decorando os comandos que mais usa.

Alguns comandos que vale a pena já saber são: Espaço+Espaço" (duas vezes), e vai abrir o menu que abre arquivos. digite algumas letras do nome do arquivo e vai filtrando dinamicamente:

Ou então “Espaço+e” pra abrir o Explorer NeoTree. Digite “?” pra abrir um popup com os comandos que pode usar pra criar novos sub-diretórios ou arquivos no subdiretório:

Quando aprender os demais comandos e plugins, vai notar que nem precisa abrir NeoTree, ele é mais pra quando quiser explorar visualmente mesmo. Mas pro dia a dia comando como “:e” devem ser suficiente. Aliás, “:” (dois pontos) é o comando pra executar funções do NeoVim. Por exemplo “:q” é quit, ou “:w” é write e “:wq” é write e quit ao mesmo tempo.

Se quiser aprender mais a fundo sobre NeoVim, recomendo o canal do YouTube do camarada Eustáquio Rangel que é veterano de Linux, Rails e Vim e ele ensina NeoVim do zero (sem LazyVim).

Agora, digamos que já aprendeu o básico de NeoVim e LazyVim, e agora quer começar a mexer nos seus projetos de PHP, Java, C#, Ruby, Python ou o que for. Vai notar que o LazyVim não tem nenhuma funcionalidade pra nenhuma delas.

O que fazer agora? Instalar VS Code?? NÃO!!

Isso porque você não executou :LazyExtras.

Digite exatamente assim e veja isto:

Essa janela parece complicada mas é só uma lista de plugins dividida em seções. No começo aparecem os plugins já instalados e habilitados. Caso não queira algum deles, basta usar as setas pra descer o cursor até uma delas e apertar “x” pra desmarcar. Mas deixe essa seção como está. Vamos descer até a seção de “Languages”:

É nesta seção que estão todas as linguagens que você pode habilitar o suporte. Basta descer com as setas e ir marcando com “x” quais quer instalar. E tem de tudo, desde Angular, Vue, Erlang, Elixir, Rust, Zig, Haskell e muito mais.

Ao lado de cada linguagem tem o grupo de plugins individuais que ele vai instalar. Pra saber o que cada uma faz, digite o nome delas no Google e ache a página com a documentação, onde vai ter hotkeys e configurações extras que pode fazer.

Com isso vai ganhar coisas como Linters, syntax highlighting, LSP, snippets e muito mais.

E se quiser instalar plugins a mais que não tem listado, dá pra adicionar manualmente. Leia a seção de Adding Plugins na documentação.

LazyVim + LazyExtras é 90% de tudo que precisa pro seu dia a dia de desenvolvimento de software. É mais leve e mais rápido que um VS Code, usando muito menos memória e vai ser muito melhor especialmente em máquinas mais antigas. Não tenha preguiça de aprender Vim, um programador de verdade não deveria ficar num VS Code só porque tem preguiça de aprender hotkeys extras.

Se quiser mudar pra ZSH, é fácil, só fazer isso:

yay -S zsh zoxide
chsh -s $(which zsh)

Logout, login e pronto. Mas agora seu shell vai estar vazio. Pra baixar minha config faça isso:

git clone https://github.com/akitaonrails/omarchy-zsh.git ~/.config/zsh
ln -s ~/.config/zsh/.zshrc ~/.zshrc 

Tem duas coisas que precisa modificar. Em .zshrc remova esta linha:

source ~/.config/zsh/mounts

Isso é só pra eu checar meus mounts de NFS pro meu NAS. Pra você não serve pra nada então pode tirar.

A segunda coisa é criar um novo arquivo para segredos:

touch ~/.config/zsh/secrets
chmod 600 ~/.config/zsh/secrets

É nele que vai colocar coisas como suas chaves de OpenAI ou Google Cloud ou qualquer coisa assim. Por exemplo:

# ~/.config/zsh/secrets
export OPENAI_API_KEY="sk-xx-v1-xxx...xxxxx"

Assim seus segredos ficam separados das suas configurações e podemos dar git push pra um repositório sem se preocupar que algo possa vazar no futuro. Sempre mantenha segredos, senhas, chaves, separados localmente. Isso já está no .gitignore então está seguro.

De bônus, no ~/.config/init adicionei suporte ao Atuin que é uma ferramenta que serve pra sincronizar todo histórico de comandos que fez no seu shell pra um repositório no “cloud” (leia a documentação, você pode criar seu próprio server local também). O repositório é encriptado, então não é inseguro, mesmo se seu histórico contenha chaves secretas nos comandos.

Instale assim:

yay -S atuin
atuin register -u <seu username> -e <seu email>
atuin import auto
atuin sync

Logo que registrar o Atuin vai gerar uma chave de encriptação aleatório. Garanta que guardou essa chave num lugar seguro como 1password, Bitwarden ou outro cofre seguro!! Sem ela não vai conseguir decriptar numa nova instalação. Se esquecer, ainda dá pra ver antes de reinstalar, por exemplo:

atuin key

Se reinstalar sua máquina ou instalar uma nova máquina e quiser seus históricos de volta, basta instalar o Atuin e fazer:

atuin login -u <seu username>
atuin sync

Ele vai pedir sua senha e chave de encriptação e trazer todo seu histórico de volta.

Segundo minha config, basta digitar Ctrl+R pra chamar a procura do histórico (que a partir de agora vai estar num sqlite na sua máquina). Leia a documentação pra mais funcionalidades.

O DHH configurou o prompt do Starship usando o jeito antigo de variável PS1. Mas o Starship já tem vários prompt bem bonitos fáceis de usar como “presets”. Eu escolhi o Pure Prompt, que eu gosto, mas tem vários outros. Se gostar de algo mais chamativo e colorido, tem este Pastel Powerline:

Escolha o de sua preferência na página de Presets e mude em ~/.config/zsh/prompt no lugar desta linha:

starship preset bracketed-segments -o ~/.config/starship.toml

Por fim, eu deixei alguns ENVs em ~/.config/zsh/envs que funcionam pros meus testes de Ollama e coisas assim, mas é bom você saber que estão lá pra não achar estranho se seu Ollama estiver se comportando estranho, edite o arquivo ~/.config/zsh/envs pra ter os envs de sua preferência:

# envs
export OPENAI_API_BASE="https://openrouter.ai/api/v1"
export DEFAULT_MODEL="o1-mini";
export OLLAMA_API_BASE=http://127.0.0.1:11434
export OLLAMA_HOME=http://127.0.0.1:11434
export OLLAMA_MODELS=/mnt/gigachad/ollama/models

Também modifique o arquivo ~/.config/zsh/aliases pra ter alias que você prefira:

# aliases
alias monhd="sudo ddcutil -d 1 setvcp 60 0x12"
alias mondp="sudo ddcutil -d 1 setvcp 60 0x0F"

alias sgpt='docker run --rm -e OPENAI_API_BASE=${OPENAI_API_BASE} -e OPENAI_API_KEY=${OPENROUTER_API_KEY} ghcr.io/tbckr/sgpt:latest txt '

alias git='nocorrect git'
git config --global alias.a 'add'
git config --global alias.ps 'push'
git config --global alias.pl 'pull'
git config --global alias.l 'log'
git config --global alias.c 'commit -m'
git config --global alias.s 'status'
git config --global alias.co 'checkout'
git config --global alias.b 'branch'

Os primeiros dois aliases são pro meu setup de 2 monitores onde um dos monitores recebe sinal tanto da entrada HDMI quanto da entrada DisplayPort (tenho 2 GPUs). Se não sabia, dá pra controlar isso usando o shell. Leia este post sobre ddcutil

Em seguida você ganha o comando sgpt. Omarchy já trás Docker instalado. Agora no shell você pode perguntar ao ChatGPT sem precisar ficar abrindo um navegador web pra isso:

sgpt "qual é a sintaxe de rsync pra sincronizar dois diretórios?"

Leia documentação do SGPT pra saber outras funcionalidades ou quais LLMs você pode escolher.

No final temos aliases pra Git. O Omarchy já tem alias pra fazer “g” ser “git” e com este que eu adicionei você pode fazer:

git add . # antigo
g a . # novo

git commit -m "initial commit" # antigo
g c "initial commit" # novo

git commit --amend -m "initial commit"
g ca "initial commit"

git push origin master
g ps origin master

git pull origin master
g pl origin master

git log
g l

# e assim por diante

Mais prático e menos verbose. Adicione mais aliases conforme seu workflow em ~/.config/aliases.

E acho que é isso, agora sim, meu Omarchy está organizado do jeito que eu gosto. Faça suas próprias configurações pra tudo ficar do seu jeito também!

Eu gostei bastante das escolhas do DHH, ele sempre foi um cara de Mac, eu também. Mas eu migrei de volta pra Linux quase 10 anos atrás. O motivo foi porque eu evangelizava tech pra desenvolvedores júniors e no Brasil ficou inviável incentivar Macs. E não queria que parecesse que sem usar Macs você estaria automaticamente em grande desvantagem. Então passei a usar exclusivamente Linux e no blog fiz vários posts explicando sobre isso, como estes:

• 2015 - Situação Brasil: No Macs for the Rest of Us
• 2016 - The Year of Linux on the Desktop, by Microsoft ??
• 2017 - Off-Topic - Why are we all moving away from Apple?

Sem contar os diversos videos com setups que fiz no meu canal, como estes:

• O Guia Definitivo de Ubuntu pra Devs Iniciantes
• O Melhor Setup Dev com Arch e WSL2

Em 2024, com exceção se precisa desenvolver apps pra iOS ou coisas específicas de .NET, usar distros Linux é superior a usar Windows ou MacOS. Antigamente eu diria um “mas” se quiser jogar, aí seria obrigado a fazer dual-boot com Windows. Mas até isso Linux já superou Macs graças aos esforços da Valve e as comunidades open source em torno de projetos como Proton. Hoje, uma quantidade absurda de jogos novos de PC rodam liso em Linux, basta instalar Steam e já era.

Não é o tema do artigo, mas já que toquei no assunto, estava justamente assistindo um review do BazziteOS rodando no Asus ROG Ally (meu favorito), criando um Steam Deck ainda mais potente. É Fedora rodando num handheld, com uma interface tão boa que ninguém sabe que é Linux por baixo, rodando jogos com mesma performance que em Windows. É impressionante mesmo. Quem ficou totalmente pra trás em games foi a Apple.

Isso tudo dito, o DHH mudou pra um hardware muito bacana de uma empresa pequena e nova chamada Framework, que faz notebooks modulares. A idéia é não precisar jogar tudo fora quando quiser fazer upgrades de hardware. Só trocar o módulo pra um mais novo. E não só coisas simples como trocar uma porta USB-A por uma USB-C, mas até trocar GPU, trocar placa-mãe, monitor.

É um conceito muito bacana que eu gostaria que mais fabricantes se comprometessem a fazer. Evita lixo eletrônico desnecessário, pra começar, muito mais fácil de reparar partes, sem ter que jogar tudo fora, como acontece com um Macbook. Vi isso pela primeira vez no canal do Linus Tech Tips porque o Linus Sebastian se tornou um dos primeiros investidores anjo deles.

A maioria dos fabricantes que suportam Linux, costumam oferecer algum tipo de suporte a Ubuntu. Ele acabou meio que se tornando o “padrão” de Linux pra usuários comuns. Na dúvida, instale Ubuntu. E não é uma má escolha. Se escolher Ubuntu, use o projeto Omakub oficial do DHH, que vai configurar tudo bonitinho pra você.

Eu não gosto de Ubuntu, é uma escolha pessoal (e cada um de Linux vai ter sua própria opção. Já sei que o primeiro comentário vai ser alguém falando de porque todo mundo não usa NixOS de uma vez …). Não precisa ficar preocupado nem se sentir mal por usar Ubuntu, não tem absolutamente nada de errado com ele. Escolher distros é que nem escolher marca de carro. Qual a diferença de Ferrari, Lambo, Porsche, McLaren? Você vai achar ruim se prefere Lambo e eu prefiro McLaren?

Além disso, puristas vão dizer que é pra ficar no Arch Linux puro, mas faz anos que prefiro Manjaro GNOME no meu PC desktop e em notebook prefiro ficar com Windows 11 mesmo e WSL2 rodando ArchWSL. Ainda recomendo brincar com Arch puro pra aprender. Mas depois de tantos anos, como é meu caso, prefiro um instalador que faz igual Ubuntu: vai do zero ao desktop em poucos cliques.

Então não teve jeito, fui obrigado a fazer um fork e ajustar o Omakub num novo projeto, o OMAKUB-MJ (o nome não tá muito correto, deveria ser algo como OMAKAMJ ou algo assim que seria Omakase com Manjaro, mas fica feio, mandem sugestões nos comentários). Migrei todos os comandos de Apt pra Yay, além de diversos outros ajustes. Rodei no meu PC principal (depois de ter testado bastante numa VM, claro) e agora ficou bonitão assim:

Igual à versão de Ubuntu, ele ativa o tema Tokyo Night, mas dá pra mudar pra vários outros temas. Depois de instalado, vai ter um comando omakub no terminal que abre um menu com várias opções, incluindo mudar tamanho das fontes ou trocar temas:

Tem MUITAS coisas legais pré-instaladas, por isso repito pra ler o manual que é muito bonito, bem escrito, e eu não mudei nenhuma das configurações principais (só o zellij, já explico), então tudo que vale pra versão Ubuntu também vale pra Manjaro. E eu sei que a maioria de vocês tem preguiça de abrir o manual, mas uma coisa que o DHH sabe fazer é uma documentação atraente:

Migrando pra Manjaro

Enfim, pra migrar de Ubuntu pra Manjaro, a primeira coisa que fiz foi trocar comandos apt por yay, coisa simples assim:

- sudo apt install -y alacritty
+ yay -S alacritty --noconfirm

Mas rapidamente encontramos as partes de porque eu prefiro o YAY do que APT como gerenciador de pacotes:

-  sudo curl -fsSLo /usr/share/keyrings/brave-browser-archive-keyring.gpg https://brave-browser-apt-release.s3.brave.com/brave-browser-archive-keyring.gpg
-  echo "deb [signed-by=/usr/share/keyrings/brave-browser-archive-keyring.gpg] https://brave-browser-apt-release.s3.brave.com/ stable main" \| sudo tee /etc/apt/sources.list.d/brave-browser-release.list
-  sudo apt update -y
-  sudo apt install -y brave-browser
+  yay -S brave-browser --noconfirm

Em Ubuntu, tudo que a própria Canonical não controla, fica em repositórios de terceiros, então precisamos explicitamente adicionar esses repositórios antes de conseguir instalar seus pacotes.

Em Arch é a mesma coisa, com o Pacman só conseguimos instalar os pacotes oficiais que o grupo do Arch controla e testa. Mas existe um repositório de terceiros chamado AUR, o Arch User Repository. Daí instalamos ferramentas como Pamac (que vem instalado em muitas distros) ou o Yay (que eu gosto mais). Por baixo eles rodam Pacman, mas oferecem um único comando que serve pros dois: instalar pacotes oficiais e instalar pacotes do AUR, com os mesmos comandos. Então não tem que ficar manualmente gerenciando trocentos repositórios externos.

Foi bem fácil converter porque no AUR tem tudo que precisamos. É muito raro precisar de um software e não achar no AUR. Além disso fiz outra modificação: eu prefiro manter aplicativos gráficos como Spotify ou Discord instalados via Flatpak.

Não é nem por razões de segurança. Prefiro que aplicativos de terceiros mexam no sistema operacional abaixo o menos possível. E muitos deles precisam de várias dependências. Quando preciso fazer um upgrade geral, demora mais porque vem um monte de pacotes de dependência junto que eu nem precisava. Pelo menos com Flatpak, as dependências ficam isoladas em imagens de containers.

Enfim, quando preciso atualizar o sistema só faço yay -Syyuu e quando quero atualizar aplicativos, basta fazer flatpak update -y, assim posso rodar separadamente. As únicas exceções são editores de texto como Visual Studio Code, nesse caso prefiro que ele tenha acesso ao sistema de arquivos todo mesmo, e não ter que lidar com permissões de acesso em containers de Flatpak, por isso instalo via Yay.

GNOME

Adicionei dois aplicativos opcionais, o Bitwarden (o DHH prefere o 1password, ambos são bons) e o Discord. Aplicativos de Flatpak são fáceis de instalar, nem precisa estar num instalador como esse, mas coloquei só mais esses por conveniência pra mim mesmo. Obviamente você pode instalar depois o que quiser. Basta procurar com flatpak search e instalar com flatpak install.

No lado Gnome, o DHH escolheu apps como Flameshot pra substituir o app de screenshot do Gnome. Uma das vantagens é que depois de tirar a foto de tela, dá pra imediatamente editar a imagem antes de salvar. Pra ter preview rápido de imagens no gerenciador de arquivos Nautilus, ele escolheu o Gnome Sushi. Todas essas opções são muito boas e você pode ver tudo que é instalado no desktop no diretório install/desktop. Cada app é um script separado.

De todos, o único que realmente não conhecia é o Localsend. Mas agora já instalei no meu Linux, Windows, smartphone e tudo mais. É o jeito mais fácil de transferir arquivos entre máquinas na mesma rede. Igual o Airdrop de iPhone. Vale a pena ter instalado em tudo.

Outro app que eu não conhecia é o Ulauncher que é um executador de aplicações, igual a barra de Spotlight de Mac. Basta apertar Super/Tecla de Windows + Espaço e ele abre uma barra onde podemos digitar o nome do app que queremos abrir:

Se fosse só isso, não é muito útil porque em Gnome, só de apertar Super já dá pra digitar o nome de apps. Mas o interessante é que ele faz mais que executar apps. Depois fuce a Página de Extensions pro Ulauncher. Tem coisas como calculadoras, controlador de Spotify, pesquisador de arquivos, facilitador pra editores com Obsidian ou Notion, pesquisador de snippets de código pra VS Code, tradutores, integradores pra serviços de GPT e um dos meus favoritos, facilitador de Emojis:

O Omakub ajusta bastante coisa do Gnome. Em particular adiciona várias extensions que mudam o comportamento do ambiente gráfico:

Depois vale fuçar as configurações de um por um. Por exemplo, ele instala e já configura a extension Tactile que é provavelmente a melhor pra organizar as janelas em “tiles” ou “azulejos”, ou seja, pra facilitar alinhar uma janela em cima ou do lado da outra de forma proporcional. Ele faz isso pré-dividindo a tela em áreas e atribuindo letras a cada área, assim fica fácil de fazer uma janela se encaixar numa dessas áreas.

Por exemplo, com o comando Super + T aparece esse grid. Se digitar “w” duas vezes, minha janela de Alacritty se encaixa no topo, no meio, na área marcada com “W”:

Normalmente, eu gosto de ter a janela aberta no meio do monitor, maximizado na vertical, sem esticar pros lados, especialmente pra ler ou digitar textos. Então posso fazer Super + T e logo depois W e S pra marcar duas áreas:

Mas também continuo podendo teclar F11 ou Super + seta pra cima pra maximizar a janela na tela inteira. Ou usar as combinações clássicas de Windows como Super + seta esquerda ou Super + seta direita pra fazer a janela usar metade vertical da tela, desta forma:

Vale fuçar a documentação e as configurações da extension Tactile pra dividir as áreas do jeito que mais gosta. Isso vai variar bastante caso use monitor secundário na vertical, ou use monitor Ultra Wide. E nesse caso é onde esse tipo de extensão vai fazer mais diferença pra manter suas janelas organizadas.

Neovim e LazyVim

Eu mencionei Visual Studio Code, e ele está aqui pra quem gosta, mas quem acompanha meus videos e artigos, sabe que sou usuário de Vim de longa data. E a comunidade Vim não pára quieta. Hoje em dia tem um fork mais moderno, o NEOVIM, que se tornou o mais usado.

Em cima do NeoVim podemos instalar plugins manualmente e ficar ajustando configuração pela eternidade, ou usar configs já prontas. Até poucos meses atrás eu usava o LunarVim, mas ele meio que caiu em desuso. Depois passei a usar o AstroNVIM, que resolve muito bem, mas parece que a maioria das pessoas passou a convergir pro LazyVim. Confesso que fico em dúvida entre qual é o melhor, AstroNvim ou LazyVim, mas vou ficar com o LazyVim por enquanto.

No fundo vão usar muitos dos mesmos plugins, análise de código vai ter plugins pra LSP, navegação vai ter o mesmo neo-tree, o mesmo telescope e assim por diante. Por isso vai ser muito subjetivo mesmo. Acho que nenhum dos dois tem como errar.

Muita gente acha que esses pacotes são contra a filosofia de “aprenda a configurar você mesmo”. E de fato, se puder, recomendo mesmo que monte sua configuração do zero. Mas faça isso só uma vez, desfaça e use um desses pacotes. Na realidade, essa noção começa a falhar porque esses plugins, sejam eles escritos no antigo VimScript ou na mais moderna linguagem Lua, são programas completos. Pegue plugins como Neo-Tree ou Telescope. Você não fez nem nunca vai fazer nenhum deles do zero, isso é pra poucos.

Na prática, o NeoVim já poderia vir pré-instalado com eles, pra você não faria diferença, porque são modernos, bem escritos, customizáveis, e não ficam no seu caminho. Não vem porque a idéia toda de um Vim é ser hiper-leve, pra podermos usar rapidamente dentro de um container, ou conectando num outro servidor via SSH, sem GUI, sem dependências, se bugs de interface nem nada disso. Só no nosso desktop, em ambiente controlado, gostaríamos dele tão pesado e funcional quanto um VS Code.

Depois tente dar uma olhada na configuração de um LazyVim, é muito mais coisa do que uma única pessoa deveria se preocupar. E saem plugins novos todos os dias, plugins antigos deixam de ser usados, não tem como você ficar de olho em tudo isso. Melhor ser um esforço dividido pela comunidade e a gente ter a oportunidade de usar o que tem de melhor só dando um update.

Sinceramente, seja Astronvim ou LazyVim, eu não tenho nem vontade e nem disposição de tentar montar do zero uma config como essa. E o que eles me oferecem “out-of-the-box” está perfeito já, eu não preciso ficar mudando. Basta usar. Você tem que ser muito chato pra achar que pode fazer melhor. Se achar isso, faça um pull request pra esses projetos então. Será tempo melhor gasto.

ZelliJ

Eu sou usuário de Tmux de longa data. E meus amigos usavam o antigo Screen, antes disso ainda. Eu lembro quando falávamos do Tmux como o software mais moderno. Agora ele é o legado e o mais moderno é o ZelliJ.

Todos eles são gerenciadores de sessão. Pense quando você se conecta num servidor remoto via SSH e fica trabalhando nele. Daí temos uma pane na internet ou cai a luz. O que acontece? Não só a conexão fecha, mas seja lá o que você estava rodando remotamente vai crashear porque o app está atrelado - é um filho - da sua shell (bash, zsh). E sua shell estava atrelada à sessão SSH. Quando a conexão cai, o SSH mata o shell que mata sua app. Você perde o que estava fazendo ou, pior, se o programa estava no meio, ele vai crashear no meio e pode corromper alguma coisa.

Em vez de correr esse risco, quando logar via SSH, imediatamente abra uma sessão de Screen, Tmux ou Zellij. Agora o shell vai abrir atrelado ao Zellij. Se a conexão cair e o SSH fechar, o ZelliJ vai continuar rodando, ele fica atrelado a um daemon na máquina remota. Seu shell e seu app ficam atrelados ao ZelliJ e não à sua sessão SSH.

Quando a luz voltar ou a internet voltar, basta conectar via SSH de novo e rodar o comando zellij attach ou tmux attach e ele vai “re-anexar” à última sessão de apps, e você vai voltar ao seu shell, como se nunca tivesse saido de lá. Quaisquer apps que estivessem rodando e processando, ia continuar até acabar, normalmente, como qualquer app em background. Essa é a vantagem principal de um gerenciador como ZelliJ ou Tmux.

Mesmo se não estiver trabalhando numa máquina remota via SSH. Mesmo no seu desktop. Digamos que esteja brincando de editar configurações, instalar extensions e coisas assim. E do nada seu GNOME ou seu X resolvam dar pau, crashear e reiniciar. Todos os apps gráficos vão crashear junto, incluindo seu app de terminal, como Alacritty e junto com ele, qualquer shell e programa em linha de comando que estivesse rodando, como seu NeoVim, podendo perder código que estava editando e não salvou.

Não mais. Quando o X reiniciar, basta reabrir seu Alacritty e, mesma coisa, fazer um zellij attach pra voltar exatamente onde estava. Inclusive, se dentro do zellij você estava remotamente conectado a um servidor, monitorando com htop ou algo assim, nada vai fechar, vai continuar tudo conectado. Isso é mais uma camada de estabilidade pra você.

Veja este exemplo abaixo:

O Omakub já configura o ícone do Alacritty pra abrir uma janela de ZelliJ. Se seguir a configuração padrão, teclando Ctrl P D, sendo “P” pra Painel e “D” pra “D"ividir a janela horizontalmente, dá pra abrir dois programas um em cima do outro.

ATENÇÃO: este é o único app do Omakub que fui obrigado a mudar os shortcuts, por isso o que tem na documentação oficial não vai bater.

O problema é o seguinte: vários apps de terminal, como NeoVim, tem vários shortcuts de navegação. Se digitar “Espaço + E” vai abrir o painel de exploração do Neo-Tree na esquerda. Dá pra navegar por diretórios usando “J” ou “K” pra ir pra cima ou pra baixo e “Enter” pra abrir os diretórios ou abrir arquivos.

Quando o arquivo abre, ele abre num painel na direita. Mas como você navega entre os painéis? Basta digitar Ctrl + H ou Ctrl + L (lembrando que em Vim as “setas” são as telas da home row da mão direita H J K L). Só que se você estiver dentro do ZelliJ, isso não vai funcionar. Isso porque o ZelliJ em si usa o modificador Ctrl pra ele. Então ele engole o comando e não passa pro NeoVim.

Uma das soluções é que o ZelliJ, assim como NeoVim, tem “modes”. Vim tem modo normal, modo de edição e modo visual. ZelliJ tem vários modos, como modo normal, modo de scroll, modo de painel e cada modo tem seu sub-conjunto de shortcuts/combinações de teclas. Um desses modos é “Locked”. Podemos travar o zellij, daí usar o programa dentro do painel isoladamente, e lembrar de ficar “desbloqueando” o zellij. É meio chatinho de ficar fazendo isso.

Outra solução é o que eu fiz no Omakub-MJ. Eu adicionei as configurações do usuários de GitHub “shoukoo” que fez um artigo um tempo atrás chamado ZelliJ 💓 NeoVim. A configuração completa dele está neste arquivo. Mas em resumo, ele cria um modo especial que batizou de “modo tmux”.

Pra entrar nesse modo, precisa digitar primeiro Ctrl f e na barra inferior, dá pra ver mudando de modo Normal pra Tmux:

E agora sim, podemos digitar comandos como P D pra dividir painel. E fazendo isso, enquanto estiver no modo Normal mesmo, dentro do Neovim, combinações como Ctrl H ou Ctrl L vão funcionar normalmente. Win-win!

Só lembrar que, se na documentação oficial do zellij/omakub ele mandar digitar Ctrl P W pra abrir um painel flutuante, agora vai ser Ctrl + F e depois P W. E ele chama de “modo tmux” porque em Tmux, todo comando é depois de digitar Ctrl + B antes. No caso ele escolheu Ctrl + F pro ZelliJ, mas é arbitrário, poderia ser qualquer combinação inicial.

O resto continua funcionando igual. Pra navegar entre os painéis de ZelliJ, só digitar Alt + H ou Alt + K como no NeoVim, mas usando Alt em vez de Ctrl. Pra salvar a sessão atual e sair do ZelliJ, só fazer Ctrl + F, O D e quando voltar, só digitar Ctrl + F, O W pra listar as sessões salvas (sim, dá pra ter várias), e restaurar a que quiser com Enter.

Como o manual do Omakub recomenda, vale estudar a documentação oficial do ZelliJ.

ASDF pra MISE

Finalmente, uma das ferramentas que eu usei por mais anos foi o ASDF. Quem já programa em Node, Ruby, Python, etc já teve que usar algo como NVM, RVM ou RBenv, VENV ou Conda e assim por diante.

O mundo ideal é que todo mundo sempre usasse a versão mais nova de tudo, toda linguagem, toda biblioteca, tudo. Mas isso é inviável. Um bom programador vai acumular vários projetos na sua máquina, cada um vai estar numa versão diferente.

Ano retrasado ele trabalhou num projeto em Node na versão 16. Hoje está trabalhando num projeto novo na versão 22. Mas do nada, teve a necessidade de rodar esse projeto antigo. E agora? Ele atualizou tudo e só tem o node 22. Se desinstalar e instalar o 16 pra rodar o antigo, como fica o projeto novo? E as bibliotecas, como fica seu diretório de NPM? Uma zona completa.

Pra conseguir ter várias versões de node instaladas em paralelo na mesma máquina, recomenda-se usar NVM, que é o Node Version Manager.

Mas você é um programador poliglota. Trabalha em projetos em várias diferentes linguagens. Vai ter que aprender os comandos individuais de gerenciar versão pra cada linguagem? NVM pra Node. VENV pra Python. RVM pra Ruby, o que usa pra Java? Fodeu.

Pra isso criaram projetos como o antigo ASDF. Com ele era muito simples, bastava fazer asdf install nodejs 14.21.3 pra instalar uma versão antiga de node e depois asdf local nodejs 14.21.3 dentro do diretório do projeto antigo. Ele cria uma arquivo .tool-versions declarando a versão de nodejs pra esse diretório e quando entramos nele, o asdf detecta e já muda o que precisa pra poder usar a versão certa. Super conveniente.

Mais conveniente ainda porque podemos usar o mesmo conjunto de comandos pra qualquer linguagem. Basta instalar o plugin da linguagem com asdf plugin add java por exemplo. E ele suporta dezenas de linguagens, até as mais exóticas que você nunca ouviu falar. É o verdadeiro canivete suíço de gerenciamento de linguagens.

E esse seria o fim da história. Hoje mesmo, se você já usa ASDF, pode continuar usando, não tem nenhum problema com ele. Mas você conhece o povo de Rust: eles querem reescrever tudo em Rust. O Omakub mesmo instala vários substitutos como o “exa” que substitui “ls” e é feito em Rust. Tem vários assim.

No caso, existe o novo Mise de “mise-en-place”, pra quem já assistiu Masterchef. É exatamente a mesma coisa que ASDF só que feito em Rust. Inclusive ele é compatível com o mesmo arquivo .tool-versions que mencionei antes. Se não tiver, ele gera arquivo com nome próprio .mise.local.toml porque, claro, YAML ou JSON são antigos, o negócio é usar TOML …

Ele simplifica os comandos, mas não necessariamente acho que ficaram mais intuitivos. Mas é bem simples. Digamos que eu precise do tal Nodejs antigo, basta fazer mise install node@14.21.3 ou direto mise use node@14.21.3 pra instalar e já escolher pra usar.

Dá pra configurar versões locais pra cada diretório de projeto com mise use --env local node@14.21.3. E essa sintaxe de “@” é pra permitir instalar mais de uma versão num único comando, por exemplo mise install ruby@3.1 nodejs@22.3.0.

Mesma coisa como asdf, também podemos configurar a versão global padrão, caso não tenha arquivos como .tool-versions no diretório, fazendo mise use --global nodejs@22.3.0. Pra listar o que tem instalado, só fazer mise ls.

Enfim, vale estudar a documentação oficial. No geral é uma ótima ferramenta e um bom substituto pra ASDF. Mas ele é tão parecido com ASDF que, se já estiver acostumado, não tem necessidade de mudar. Não tem nada a mais que ele faça que eu fosse sentir falta se não tivesse. Povo de Rust tem que parar de ficar substituindo as coisas pra fazer exatamente a mesma coisa. Era melhor gastar esse tempo ajustando e mandando patches pro próprio ASDF. Só dividiu os esforços da comunidade em duas ferramentas que fazem a mesma coisa.

Últimas Considerações - Atuin

Uma última coisa, é que eu adicionei a ferramenta Atuin “Magical Shell History”. Ele substitui o histórico do seu shell (sabe, aquele que você pode digitar “Ctrl + R” e procurar a linha de comando?) que normalmente é gravado em arquivo texto e manda pra um banco de dados SQLite3.

Só isso já seria legal, pra tirar as limitações de arquivo texto e evitar corromper e perder histórico. Mas além disso ele tem um serviço que permite sincronizar seu histórico entre diferentes máquinas. Digamos, seu PC desktop de casa, seu notebook de trabalho, seu servidor remoto. Hoje em dia todos tem históricos isolados e diferentes. E se desse pra sincronizar todos?

Aquele dia que você esquece seu notebook no trabalho, está no PC de casa e fica “puts, quais eram mesmo aqueles comandos de docker que eu fiz no trabalho??” Agora tem com, basta fazer atuin sync e pronto, seus históricos sincronizam!

Pra isso, no script de instalação eu rodo o atuin register que pede um username, email e uma senha (que, se não me engano, vai servir pra encriptar seus dados). E pronto, já vai sozinho se virar pra ficar sincronizando. Se já tinha conta, numa máquina nova basta rodar atuin login e logar. Só isso.

Ele substitui o Ctrl + R pra pesquisar no sqlite3 e agora seu histórico será muito mais robusto. Eu imagino que isso é mais importante ainda pro povo de devops. Eu lembro que rodava trocentos comandos de pods e containers e usava MUITO o histórico pra lembrar das coisas e repetir comandos. Fucem a documentação, tem como montar seu próprio servidor de Atuin pra onde sincronizar. Mesmo estando encriptado, talvez você queira 100% de controle. Tem como.

E por hoje é isso. Eu gostei bastante de brincar com o Omakub-MJ e meu PC pessoal com Manjaro GNOME e meu notebook com Windows 11 + ArchWSL já estão usando tudo exatamente como expliquei aqui. Novamente, leiam o Manual do Omakub escrito pelo DHH, usem o Omakub dele caso estejam em Ubuntu, usem o meu fork pra Manjaro e Arch e não deixem de mandar Pull Requests ou Issues lá.

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 primeiro episódio técnico da série Começando aos 40 (https://www.youtube.com/watch?v=sx4hAHhO9CY) eu recomendei que todos estudassem Linux, e foi só isso. Hoje eu resolvi retomar o que eu disse e mostrar que em casa de ferreiro o espeto é de ferro!

Vou pegar um Ubuntu recém-instalado, e do zero ir até um ambiente completo para desenvolvedores de software (em particular Web, claro), com Docker, Tmux, Vim, ASDF e durante o percurso explicar várias coisas sobre Linux em geral, várias dicas, e até mesmo como customizar os temas pra ficar “dahura”!

As dicas estão espalhadas por todo o vídeo, então tente assistir o vídeo inteiro sem pular nada.

Até o momento esse deve ser o vídeo mais longo que eu já fiz, e eu fiz de propósito pra que seja facilmente compartilhável num link só! Compartilhe com o máximo de pessoas que puder!

E pra ninguém perder tempo, desta vez vou deixar listado aqui os tempos pra cada seção do vídeo pra que você possa pular direto pro que interessa caso já não seja mais tão iniciante ou se quiser relembrar alguma parte em particular:

== COMPLEMENTO

Esqueci de dizer que depois de instalar o dotfiles YADR os shortcuts de Tmux, Vim, Git mudam (vejam o código fonte!!). O Tmux em vez de Ctrl-B vira Ctrl-A por exemplo. No yadr-appearance.vim não use Solarized se quiser usar o Vim no Terminal (por alguma razão ele crasheia), troque por um “gruvbox” por exemplo. Pra abrir o NerdTree no terminal, use Ctrl+\

== ERRATA

Em 00:54:24 eu percebi que faltou um áudio, eu devo ter apagado por engano e só percebi agora que já subi. Era a introdução da seção de Docker e o texto era: “Tem gente que prefere não instalar esses serviços diretamente, pelo mesmo motivo que usamos ASDF. E se você tem um projeto antigo que depende do PostgreSQL 7 e quebra se tentar conectar no Postgresql 10? Pra isso precisamos de algo parecido com um ASDF. E se não me engano acho até que o ASDF tem suporte pra Postgresql, vamos ver no google, e sim, tem mesmo. Mas se for esse o caso eu prefiro fazer diferente. Serviços como os que acabamos de instalar é o caso de uso perfeito pra usar Docker. Então é hora de instalar e configurar Docker. E a essa altura você já adivinhou: vamos pro GOOGLE.”

Em 00:03:00 eu falo que o Steam roda poucos jogos em Linux mas eu realmente me esqueci do Proton que é habilitado dentro da própria interface do Steam e você pode rodar os jogos quase que normalmente em Linux também! Eu mesmo não uso porque uso Steam no Windows mas fica a dica pra quem tem insegurança de mudar pra Linux e ficar sem Steam.

== Seções:

00:03:50 - Manjaro/Arch? 00:04:19 - Que hardware/notebook devo comprar pra programar? 00:08:46 - Que máquina Akita tem? Por que não comprar um topo de linha? 00:13:27 - Ubuntu: aprendendo sobre Workspaces 00:15:40 - Ubuntu: Tema Flat-Remix 00:18:19 - Linux: Conceitos e comandos básicos 00:22:59 - Linux: Entendendo os principais diretórios do sistema 00:28:41 - Linux: Entendendo Processos e manipulando arquivos e diretórios 00:40:42 - ASDF: Instalando e gerenciando versão de TODAS as linguagens!! 00:49:30 - Bancos: Postgresql 10, Redis, Memcached e MongoDB 00:54:24 - Docker: instalando, usando Postgres em container e mais! 01:00:21 - Básico do básico de criptografia, chaves SSH 01:05:52 - Básico de TMux e Vim 01:12:28 - Dotfiles: meu preferido, o YADR 01:17:22 - Configurações finais de Desktop

== Links:

• Upgrade Your SSH Key to Ed25519 (https://medium.com/risan/upgrade-your-ssh-key-to-ed25519-c6e8d60d3c54)

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

• SWKP Dotfiles YADR (https://github.com/skwp/dotfiles)

• VIM Cheat Sheet (https://vim.rtorr.com)

• TMUX Cheat Sheet (https://tmuxcheatsheet.com)

• ASDF (https://github.com/asdf-vm/asdf)

• Understanding Shell Script’s idiom: 2<&1 (https://www.brianstorti.com/understanding-shell-script-idiom-redirect/)

• Upgrade Your SSH Key to Ed25519 (https://medium.com/risan/upgrade-your-ssh-key-to-ed25519-c6e8d60d3c54)

• Bash scripting cheatsheet (https://devhints.io/bash)

• Arguments against systemd (https://without-systemd.org/wiki/index.php/Arguments_against_systemd)

• Vim cheatsheet (https://devhints.io/vim)

• Tmux cheatsheet (https://devhints.io/tmux)

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

Olá pessoal, Fabio Akita

Eu coloquei a série de vídeos Começando aos 40 numa playlist chamada Programação para Iniciantes, e que você pode assistir no link acima. Claro que não dá pra explicar “tudo”. Eu entro em mais detalhes em conceitos que eu sei que é muito mal explicado ou difícil de entender só lendo, como concorrência e paralelismo ou gerenciamento de memória, e meio que deixei implícito coisas que você facilmente encontra em meia hora de Google.

Eu imagino que pra quem está iniciando as coisas são bem menos óbvias do que pra quem já tem alguns anos na carreira. A primeira coisa que eu disse que você deveria tentar aprender é um pouco de Linux, em particular eu falei pra você tentar sofrer um pouco num Arch Linux por exemplo, e a recomendação continua valendo. Porém, e depois que você instalou o Arch ou mesmo qualquer outro Linux, como você continua e monta um ambiente de desenvolvimento suficiente pra começar a treinar programação?

Hoje vou seguir um pouco a tradição do meu blog, akitaonrails.com. Faz anos que mesmo quando eu estava no Mac eu não usava as coisas nativamente no ambiente UNIX do Mac, eu sempre preferi usar um Linux de verdade dentro de uma máquina virtual. Na época eu usava Vagrant que é um facilitador pra eu conseguir acessar essa máquina virtual localmente usando SSH. Apesar de parecer que todo desenvolvedor avançado usa Mac pra desenvolver, a menos que você seja um desenvolvedor de iOS pra iPhone ou iPad, você não precisa usar Macs.

Na verdade, o melhor ambiente de desenvolvimento sempre é um Linux. Especialmente se estamos falando de programação de aplicações Web. No final você sempre vai subir a aplicação num servidor da Amazon AWS ou Azure ou Google Cloud ou Heroku e sempre vai ser servidores Linux, por isso quanto mais perto do ambiente final de produção você puder estar, sempre vai ser melhor.

Mesmo num Windows, existem de fato versões de Python ou PHP e até Javascript pra Node.js que instalam e rodam nativamente em Windows. Mas não se engane, eles nunca vão funcionar 100%. Eu expliquei isso durante a série quando falei sobre como funciona compilação e dependências nativas. O comportamento é um pouco diferente e muitas bibliotecas que precisam de dependências nativas de Linux não tem similares em Windows. Na dúvida, evite as versões de Windows. Se for programar numa linguagem que se originou no mundo de código-aberto, use um sistema operacional baseado em Linux. No caso do Windows, em breve você vai poder desenvolver usando Linux usando o novo Windows Subsystems for Linux versão 2, mas mesmo ele vai precisar de uma máquina um pouco mais parruda porque vai rodar usando um hypervisor. Eu quero falar desse assunto em outro vídeo ainda.

Prefira instalar um Linux como sistema operacional primário e nativo na sua máquina. Na pior das hipóteses, faça um dual-boot com Windows 10 pra coisas como seus games de Steam. Sim, eu sei, Steam roda no Linux, mas a grande maioria dos principais jogos não rodam e os hacks que você precisa fazer com Wine e outras coisas pra conseguir rodar raramente compensa a menos que você seja geek de configuração como eu.

Isso tudo dito, o objetivo de hoje é partir de uma instalação de Ubuntu e chegar no final com um ambiente de desenvolvimento usável e demonstrar um pouco de como algumas coisas funcionam se você ainda é novato no mundo de Linux. Este episódio vai ser GIGANTE e tem múltiplas seções então pra você pode voltar depois pra seção específica que quer ver ou se quiser pular algumas partes, vou deixar os tempos de cada uma nas descrições abaixo.

(…)

Vamos lá. Eu pessoalmente prefiro usar a distro Manjaro que é uma versão de Arch mais simples de instalar. O que eu gosto em Arch é o gerenciador de pacotes Pacman e da filosofia de rolling updates, ou seja, que você não tem quebras entre versões major, tipo pular do Ubuntu 17 pro 18, ou do MacOS High Sierra pro MacOS Catalina. No caso das distros baseadas em Pacman, ele vai atualizando os pacotes continuamente, sem necessariamente dar grandes saltos que podem quebrar as coisas do nada.

A idéia de eu começar explicando pelo Ubuntu é porque a grande maioria das pessoas vai acabar chegando no Ubuntu primeiro e é um dos sistemas com mais suporte tanto de hardware quanto da maioria dos softwares então é o que possivelmente dê menos dor de cabeça para iniciantes. O Ubuntu 18 substitui o antigo gerenciador de janelas Unity pelo mais comum GNOME, que em termos de uso de memória é um dos mais pesados. Mas mesmo dizendo assim, hoje em dia, 300MB de RAM a mais ou a menos não é o que vai te fazer a diferença considerando que qualquer aba de Google Chrome vai consumir muito, mas muito mais que isso.

A atual geração de aplicativos desktop usando Javascript e navegadores deixou tudo mais pesado, principalmente em termos de RAM. O mínimo que você precisa hoje em dia é de 8GB de RAM, de preferência invista mais um pouco e consiga 16GB de memória DDR4. Um processador Core i3 é possível de usar pra desenvolver, mas você gostaria de ter um pouco mais de cores se possível e eu recomendaria tentar investir pelo menos num Core i5 acima da 6a geração Skylake.

Pra quem não sabe, os processadores da Intel são divididas em gerações, depois da Skylake tivemos a 7a com Kaby Lake, 8a e 9a com Coffee Lake. Todas tem processadores i3, i5 e i7 e na 9a geração temos também i9. A diferença é principalmente número de cores, os i3 são só dual-core, os i5 e i7 pode ser dual ou quad-core. Os i9 acho que tem uns 10 cores. Outra diferença, se não me engano, é o tamanho dos caches L1, L2 e L3. E também suporte a Hyperthreading. Então um Core i7 quad-core pode ter 8 threads.

Se você estiver com dinheiro sobrando, monte um PC torre com Core i9 9900K com 32GB de RAM e 512GB a 1TB de SSD nvme2 como um Samsung EVO. Mas pra começar você pode ir com um Core i3 9320, 8GB de RAM, 128GB de SSD normal pra instalar o sistema operacional e 512GB de HD mecânico de 5400 ou 7200 rpm se possível. Não existe a necessidade de começar com a melhor máquina, na verdade eu recomendaria começar com uma máquina fraca. Não tão fraca pra ser nível Positivo porque ali acho que nem dá pra desenvolver direito. Mas um notebook como o Dell Inspiron 15 3000 com o Core i5-8265U Skylake, 8GB de RAM, 256 GB de SSD seria um dos melhores custos benefícios no Brasil em Julho de 2019, ao custo de R$ 3.500 em até 10x. Este vídeo não é patrocinado pela Dell mas eu mesmo já usei um notebook desses e dá pra desenvolver num desses com muita sobra, pra maioria dos programadores, especialmente iniciantes. Existem opções mais baratas, mas você vai sacrificar em algum lugar.

Pro povo mais avançado eu sei que depois de falar tanto de Intel já já vai aparecer comentário de “mas e os AMD Ryzen”? Sim, nos anos recentes a AMD começou a voltar ao jogo das CPUs e as CPUs Ryzen são muito boas, particularmente pra multithreading porque ele vem com mais cores se comparado com equivalentes de preço da Intel. Então um AMD Ryzen 3 já vem com 4 cores comparado ao Intel Core i3 de 2 cores. O Ryzen 5 vai de 4 a 6 cores. O Ryzen 7 tem 8 cores. O Ryzen 9 tem até 16 cores e você ainda tem o Ryzen Threadripper que vai até 32 cores. Apesar de ter mais cores, a performance máxima de cada core ainda era menor se comparado aos da Intel, e em particular ele não superava a Intel em games, mas a nova geração deste ano está ultrapassando a Intel até em games!

Ou seja, por um preço menor você conseguiria comprar um Ryzen equivalente e seria mais barato e mais performático que a 9a geração da Intel. As CPUs da Intel tem o Turbo Boost que ativa quando você está fazendo algo particularmente intensivo de CPU, por exemplo compilando projetos gigantes em C e C++ que costuma exigir muito da CPU. Ou então em coisas como renderizar cenas 3D num Blender ou exportar vídeos no Adobe Premiere. O problema é que Turbo Boost costuma ser um pico de curta duração. Nos novos Ryzen eles tem o Precision Boost que aumenta o clock numa faixa menor que da Intel mas entrega essa velocidade maior por mais tempo e no geral pode te dar performance maior em períodos de grande carga. Ou seja, os Ryzen vieram atropelando a Intel nesses últimos 2 ou 3 anos. Se você encontrar boas configurações com Ryzen, especialmente pra nós de desenvolvimento de software, eu recomendo.

Muita gente que tá começando sonha com um Macbook Pro, ou um Surface Book ou algo caro assim. Eu pessoalmente tenho um Surface Book 2 e um Lenovo Extreme. Junto com o Macbook Pro são notebooks na faixa dos USD 3000 se comprar nos Estados Unidos, ou seja, máquinas que facilmente custam na faixa dos R$ 15 mil no Brasil se comprar no mercado negro. Vai por mim, você não precisa disso. Então, por que eu tenho? Sendo curto e grosso: porque eu posso. Mas faça as contas, eu tenho 42 anos, se a essa altura eu não pudesse, pelamor né.

Pra dar perspectiva, quando eu tinha uns 25 anos eu comprava meus notebooks via contrabandista de Miami mesmo, como todo mundo faz hoje também. Eram máquinas mais fracas, como os antigos Toshiba Sattelite em 2002. Acho que eram Pentiums com 512MB ou 1GB de RAM. Eu falei que estamos na 9a geraçao da Intel, mas a série de processadores Core da Intel só iria começar a sair a partir de 2006. SSD ainda não existia. E Java naquela época já era quase tão pesado quanto é hoje. Na verdade hoje eu sinto o Java super leve em comparação como que eu sofria em 2002.

Ao longo dos anos eu fui crescendo na carreira e trocando pra computadores mais potentes. Nunca se compare com alguém como eu que já tem quase 30 anos de carreira. Além disso ter um computador topo de linha não vai te beneficiar em muita coisa se você não sabe como tirar proveito de uma máquina dessas. Em janeiro de 2017 eu decidi usar um Dell Inspiron que comprei numa promoção da Magazine Luisa eu acho, um pouco melhor do que o que eu sugeri agora a pouco, mas não muito, e com HD mecânico. Eu queria ver o quanto eu conseguia otimizar o Linux pra performar nesse ambiente e escrevi um longo tutorial sobre o que é possível fazer e você pode ver nos links na descrição abaixo. E eu fiquei usando essa máquina como minha máquina primária por alguns meses sem grandes problemas.

Em toda profissão de prática eu acho que todo iniciante deveria começar num ambiente mais hostil. Não digo em ambientes impossíveis, mas longe do topo de linha. Um cara que consegue desenvolver bons software e ter produtividade em um Core i3, com 4GB de RAM, imagine o que ele vai conseguir fazer com um Core i9 e 32GB de RAM.

Por outro lado se um programador amador ruim com 32GB de RAM só vai entregar software vazando memória. Um programador que não tem interesse em otimizar e aprender mais sobre seu próprio ambiente de trabalho não faz sentido pra mim. Amanhã ou depois você vai ter um problema em produção e vai precisar tirar o máximo possível dos servidores e outros recursos que tem. Se você sequer sabe como otimizar seu próprio computador, como você espera conseguir otimizar qualquer outra coisa? Tudo faz parte do treino, todo conhecimento conta. Comece a se interessar em abrir o capô e mexer na mecânica do seu carro em vez de só dirigir e ficar de braços cruzados quando o carro não quer pegar. Nese caso você vai ser só um motorista, bons programadores dirigem e consertam o próprio carro.

Isso tudo dito, instalar um Ubuntu é simples, beira o trivial a menos que você tenha um hardware muito fora de padrão. Basicamente baixe a ISO do site, grave num pendrive USB usando ferramentas como o Rufus no Windows, boote pelo pendrive e siga as instruções. Primeira coisa que você precisa aprender a fazer: ler a porcaria das instruções e não só ficar apertando próximo, próximo, como minha avó faria. Metade dos erros que os programadores iniciantes travam são trivialmente resolvíveis só lendo o que aparece na tela. Leia as fucking mensagens de erro!!

Bom, essa parte você vai ter que seguir um tutorial como o que eu deixei linkado nas descrições abaixo. No meu caso eu estou usando Windows 10 como sistema operacional principal e por isso vou instalar o Ubuntu numa máquina virtual usando VMWare Workstation. Em outro vídeo explico porque eu uso Windows como máquina principal, mas deixando isso de lado, a instalação costuma ser muito simples. Em hardware não tão antigo (pelo menos de uns 5 anos pra cá) qualquer distro moderna de Linux deve ser capaz de identificar tudo e instalar e configurar os drivers corretos. Se por acaso você tem um hardware muito fora de padrão e não for detectado, minha sugestão é simples: ache um canto aí no seu quarto, deita em posição fetal e chora um pouco. .. chorou? Bom, agora você vai ter que ir no Google, ou direto em sites como o ArchWiki ou Stackeroverflow e sair procurando. Bom, pense que isso faz parte do aprendizado também. Eu não consigo ajudar porque não tem como eu mostrar aqui todas as variações diferentes de todos os tipos de hardware que existem.

(… PARTE B - SCREENCASTS)

Depois que terminar de instalar esta é a tela que você vai ver. O instalador já vai ter criado uma conta pro seu usuário e você pode optar por logar automaticamente nela. Você pode customizar o que quiser mas uma das mecânicas que eu recomendo que você se habitue é navegar por workspaces. Por muitos anos só desktop managers de UNIX e Linux como os antigos baseados em Motif ou os mais atuais como Cinnamon, XFCE, KDE e GNOME que é o que o Ubuntu usa hoje em dia possuem o recurso de workspaces, que é como se você tivesse mais de um monitor. Demorou algumas décadas mas finalmente hoje em dia nos MacOS e Windows você também tem isso. Mas no Ubuntu funciona assim. Vamos abrir alguns programas pra ter algumas janelas pra mostrar. Vamos abrir o Nautilus que é como o Finder no Mac ou Explorer no Windows, vamos abrir o Firefox que já vem pré-instalado, vamos abrir o Terminal apertando a tecla Super e digitando Terminal que é outro jeito de abrir programas.

Agora você tem a situação em que tem muitas janelas no mesmo monitor, ou no caso no mesmo workspace. Então vamos mover o Firefox pra outra workspace usando a combinação Super + Shift + Page Down e boom, agora o Firefox está na worspace de baixo. E eu posso voltar pra workspace de cima com Super + Page Up e Super + Page Down. E eu posso ficar movendo janelas entre os workspaces com Super + Shift e Page Up ou Page Down. Mais do que isso, já que estamos falando de janelas, agora que o Firefox está num workspace só dele, podemos maximizar a janela toda usando Super + seta pra cima. Ou voltando pra primeira workspace podemos maximizar na metade da esquerda usando Super pra esquerda ou Super pra direita, e assim podemos ter janelas lado a lado organizado. Treine bastante essa combinação de teclas porque costuma ser bem útil pra manter seus programas organizados. A idéia é ter conjuntos de programas relacionados no mesmo workspace. Por exemplo, você pode ter uma com Slack e Discord, outro de trabalho que tem Terminal e Sublime Text e assim por diante.

Mas você veio até o Linux não por causa do ambiente gráfico, senão ficaria no MacOS que ainda é o melhor ambiente gráfico que existe. Você veio por causa do que tem por baixo do capô e a porta de entrada pra isso é o Terminal. Se você nunca mexeu num Linux precisa aprender alguns conceitos muito básicos. De novo, a idéia não é ser um tutorial completo mas só mostrar o principal, isso dito, vamos abrir o Terminal de novo, maximizar e aumentar as fontes pra vocês conseguirem enxergar.

Aproveitando, eu sou um pouco exigente com meu ambiente e apesar de não achar o tema do Ubuntu particularmente feio, eu prefiro um tema mais elegante do que esse laranjão todo, e um dos mais usados parece ser o Flat Remix. Vou deixar o link nas descrições abaixo, mas na prática poderíamos instalar pelos pacotes de atp mas vou instalar o Git pra baixar do Github pra mostrar como instala manualmente. Então a primeira coisa vai ser sudo apt install git gnome-tweak-tool fonts-hack-ttf pra instalar não só o Git como o Tweak Tool do Gnome pra trocar o tema e minha fonte monospace preferida que é a Hack. Em seguida vamos criar um mkdir Projects e cd Projects pra onde podemos baixar nossos códigos.

Agora vamos clonar o repositório de icones do Gihub git clone https://github.com/daniruiz/flat-remix e em seguida vamos clonar o tema com git clone https://github.com/daniruiz/flat-remix-gtk. Agora vamos criar alguns diretórios com mkdir -p ~/.icons && mkdir -p ~/.themes e copiar os arquivos que baixamos pra lá com cp -r flat-remix/Flat-Remix* ~/.icons/ && cp -r flat-remix-gtk/Flat-Remix-GTK* ~/.themes/ Pronto, podemos abrir o Tweak Tool e mudar pro tema e os ícones para o que queremos, vamos aproveitar e trocar a fonte monospace pela Hack e mudar o wallpaper pra alguma coisa mais agradável. Viu só? Podemos trocar totalmente o look and feel e existem centenas de temas e coleções de ícones. Eu encorajo vocês a procurarem pelo visual com que mais se identificam e começar a tornar o sistema operacional mais próximo de você. Outra sugestão, se quiserem procurar é o conjunto de temas chamado Material, testem o Material Dark que também fica bacana.

Como eu disse antes, o instalador criou já um usuário pra você e cada novo usuário ganha um diretório próprio. Esse diretório fica em /home seguido do seu username. No caso o meu é akitaonrails e se você ficou com dúvidas de quem você é, você pode perguntar pro Linux com o comando whoami. A navegação por diretórios é usando o comando cd. Todo diretório tem 2 entradas padrão, o “.” que representa onde você está agora e o “..” que é o diretório anterior. Pra saber quais diretórios existe você usa o comando ls ou pra ter uma listagem mais completa faz um ls -l ou ls -la que vai te mostrar os diretórios e arquivos escondidos. O que determina o que é escondido ou não é só se o nome começa com ponto. Daí por padrão não vamos ver esses arquivos em programas como o Nautilus que falei antes.

Você pode criar arquivos de diversas formas, mas a mais simples pra criar um arquivo vazio é usar o comando touch que literalmente vai tocar o arquivo. Se já existir ele vai atualizar a data e hora de última modificação, se não existir, ele vai criar o arquivo. Aliás, pra todo comando do Linux, se você quiser rapidamente ver o que ele faz exatamente e quais opções o comando aceita, use o comando man que significa “manual” e não “homem”. Falando nisso, a maioria dos comandos e nomes legados de UNIX são acrônimos de poucas letras não porque a gente é masoquista, mas primeiro porque digitar comandos longos demora mais e segundo porque você precisa digitar esses comandos num terminal remoto dos anos 60. Era uma época onde você apertava uma tecla e tinha que esperar um pouquinho pra registrar no servidor e aparecer na tela, então era meio maçante ficar esperando. Se eu fosse simular seria mais ou menos assim (DELAY DIGITANDO)

Por isso os nomes são curtos. E pra piorar cada letra a mais que você escreve consome 1 byte (ou 2 hoje dia). Lembra quando eu contei sobre a história dos computadores eu mencionei que os grandes mainframes da época gravavam em fitas que tinham só algumas centenas ou milhares de Kbytes. Ou seja, cada letra contava. Hoje em dia não existe mais essa preocupação. De qualquer forma você precisa ir aprendendo o que significa cada comando. O comando cd pra mudar de diretório obviamente é change directory, o mkdir pra criar diretório é make directory, o comando rm pra apagar é remove, o comando chown é change ownership e assim por diante.

Você já sabe whoami pra saber “quem eu sou” no sistema, e pra saber onde estamos podemos usar o comando pwd que significa print working directory ou imprimir o diretório corrente. E vemos que estamos no /home/akitaonrails. Se navegarmos pra algum lugar aleatório no sistema como cd /usr/local e quisermos voltar pra nossa casa podemos fazer cd $HOME onde o cifrão denota uma variável do ambiente e você que é de Perl ou PHP deve estar mais familiarizado com essa notação. Mas cd $HOME é muito comprido, em vez disso podemos usar o atalho cd ~ til ou tilde que o shell vai expandir para o que estiver na variável $HOME e por isso chamamos isso de tilde expansion. Toda vez que você escreve ~/Documents o shell vai expandir pra /home/akitaonrails/Documents. Pra provar isso o comando echo do shell mostra a variavel, então echo $HOME mostra o diretório de casa e echo tilde também. Pra ir pro diretório de Downloads a partir de qualquer lugar basta fazer cd ~/Downloads. Se for só pra voltar pro diretório de casa nem precisa do tilde, só cd também funciona.

Quando falamos shell, na grande maioria dos casos estamos falando do famoso Bash, o Bourne Again Shell que eu mencionei no vídeo de Sua Linguagem não é Especial. Existem diversos outros shells como o tcshell e muitos desenvolvedores usam o Z shell que vou mostrar mais na frente. Mas quando executamos comandos no shell que é nossa linha de comando podemos estar executando binários do sistema, scripts com permissão de execução ou comandos diretos do Bash ou o shell que estivermos, isso pode confundir um pouco se você não souber qual dos 3 você está executando, comecem a prestar atenção nisso.

Voltando aos diretórios, se navegarmos pra raíz com cd / e listar o que tem lá podemos ver alguma coisas interessantes. Evita modificar qualquer coisa fora da sua home sem saber pra que serve. Bem na raíz temos só dois arquivos, esse vmlinuz e o initrd.img. Na verdade ambos são links simbólicos pra arquivos que estão no /boot. Um link simbólico é um atalho, o arquivo real mesmo está no diretório /boot como pode ver. O binário vmlinuz é o kernel do Linux propriamente dito, o primeiro binário que vai carregar logo que a máquina bootar e vai começar a carregar o sistema operacional e coisas como drivers. E o initrd.img é o segundo binário que vai carregar logo na sequência subindo um RAM disk. O vmlinuz tem só o mínimo necessário pra bootar e o resto dos módulos vem desse RAM disk carregado a partir do inird.img. É uma convenção de sistemas derivados de Debian como é o caso do Ubuntu. O motivo de ser um symbolic link ou symlink é que daí no diretório /boot podemos ter kernels de múltiplas versões e mudar de um pra outro só mudando o symlink se quisermos testar uma versão mais nova mas sem jogar fora a versão anterior.

Se listarmos o ls /dev podemos ver todos os dispositivos ligados nesta máquina. Alguns desses dispositivos serão coisas como drives USB, pendrives, cdroms ou até mesmo floppys. Pra gente poder gravar ou ler alguma coisa de um desses dispositivos precisamos primeiro “montar” eles com um sistema de arquivos como exFAT ou NTFS se for de Windows ou HFS+ se for de Mac ou ext4 se for de Linux e quando eles são montados normalmente criamos um subdiretório no /mnt ou /media. A maioria dos Linux modernos tem serviços pra montar automaticamente quando inserimos um USB e essas configurações ficam no arquivo /etc/fstab e podemos ver que ele tem a configuração pro caso de alguém inserir um disquete.

Vamos brincar um pouco. Se usarmos o comando df -h podemos listar os dispositivos que estão montados e quais são os pontos de montagem, veja o / por exemplo. Agora vamos plugar um pendrive e rodar o mesmo comando. Olha como o Ubuntu já automaticamente detectou e montou corretamente em /media/akitaonrailks/KINGSTON que era o nome do pendrive. O dispositivo de verdade está em /dev/sdb1 mas não adianta tentar executar comandos como cd ou ls nele porque não tem um sistema de arquivos ali, só no ponto de montagem. A menos que você esteja escrevendo um programa de mais baixo nível, você quase nunca vai mexer no que tem nesse /dev onde dev significa device ou dispositivo, e sim no que é montado em /media ou /mnt.

Seguindo, o /root é o equivalente home do usuário root que é o administrador da máquina, ainda temos o /opt onde alguns programas de fora podem ser instalados. No /sbin ficam muitos dos binários do sistema operacional. O programa shutdown fica lá. Programas pra gerenciar discos como fdisk pra reparticionar discos, o fsck pra checar o disco, o mkfs pra formatar, ifup e ifdown pra subir e derrubar placas de rede e coisas assim. No /bin fica outros programas do sistema como o próprio bash e outros shells, coisas simples como o cp pra copiar arquivos, chown e chmod pra mexer na permissão de arquivos, todos os programas pra navegar e criar diretórios como mkdir pra criar diretórios e rmdir pra remover diretórios, ou o próprio rm que apaga arquivos e vários outros são todos binários nesse diretório.

O diretório /usr é um dos maiores e onde fica a maior parte das aplicações que você instala. Ele significa Unix System Resources mas na prática você pode pensar nele como user ou programas dos usuários. Por exemplo, o X, os aplicativos do GNOME, o Firefox, todos esses binários ficam em /usr/bin, suas bibliotecas de dependência ficam em /usr/lib, se eles instalam código fonte junto deveria ficar em /usr/src, se você instala os pacotes -dev que trazem os arquivos de header em C ou C++ pra quando você precisa compilar dependências ficam em /usr/include e antigamente tinha o /usr/etc pra arquivos de configuração mas hoje em dia acaba ficando tudo em /etc ou em diretórios escondidos como .config no seu home pra configuração exclusiva do usuário.

Etc não tem um consenso de o que exatamente significa mas a maioria gosta de pensar que significa literalmente etcetera, bem coisa de programador mesmo. Finalmente temos o diretório /var contém dados variáveis, então antigamente a gente usava o /var/spool pra ser o a bobina de impressão quando a gente usava impressora, o /var/mail pra e-mails, o /var/log é onde vai todos os principais logs do sistema, o /var/run tem PIDs que são os IDs dos processos sendo executados, o /var/cache como o nome diz serve pra alguns caches do sistema.

Falando em processos, temos o /proc. Se você usar o comando ps consegue listar os processos dos aplicativos que estão em execução e eles tem um ID numérico. No diretório /proc esses processos são representados como diretórios e você pode fuçar ali. Por exemplo, vamos achar o PID do nosso shell Bash com ps e ir pro diretório dele com cd /proc/aaaaaa e se dermos ls podemos ver vários pseudo-arquivos que não são exatamente como um arquivo de texto que você cria mas do ponto de vista do sistema operacional, podemos operar neles como se fossem. Por exemplo, podemos usar o comando less pra fuçar esse arquivo chamado status ou esse arquivo chamado io pra ver um pouco das características desse processo em particular. Se você quiser entrar a fundo no mundo baixo nível, vai achar esse tipo de coisa particularmente interessante. Na prática, pra gente não tem muita coisa pra fazer aqui a não ser fuçar mesmo, mas se em algum momento você precisar fazer um programa que busca informações sobre os processos em execução, é por aqui que você vai começar. Em vez de ter alguma API complicada do sistema operacional, você pode fuçar tudo como fuçaria qualquer diretório e arquivos.

E falando nesses outros comandos, vamos aprender mais alguns comandos. Pra não sujar seu diretório vamos pro diretório /tmp na raíz do sistema. O /tmp é o diretório pra onde vai coisas temporárias que o sistema não garante que vão estar lá depois do próximo boot, por isso é bom pra gente jogar coisas que não nos importamos se perder. Então vamos fazer o seguinte exercício:

cd /tmp
touch a.txt

serve pra tocar um arquivo como já expliquei, nesse caso vai criar um novo

echo "hello world" > a.txt

O echo serve pra escrever qualquer coisa no standard output, normalmente pro próprio shell mas aqui estamos conectando o standard output pra um arquivo com esse simbolo de maior. Então o hello world vai pra dentro do arquivo a.txt

cat a.txt
hello world

O cat significa concatenate e serve pra concatenar arquivos mas vira e mexe usamos pra ver o conteúdo de arquivos pequenos. Evite usar cat pra arquivos grandes porque ele precisa ler tudo pra memória antes de mostrar

echo "fabio akita" > a.txt
cat a.txt
fabio akita

Se fizermos a mesma coisa com outro texto vamos ver que acabamos sobrescrevendo o que tinha antes. Então toda vez que você redireciona o standard out pra um arquivo desse jeito o conteúdo anterior morre. Mas podemos ir apendando ao fim do arquivo em vez de sobrescrever desse jeito:

echo "hello world" >> a.txt
cat a.txt
fabio akita
hello world

Com o maior e maior agora podemos ir concatenando no fim do arquivo.

more a.txt
fabio akita
hello world

O comando more aqui fez a mesma coisa que o cat. A diferença é quando você faz isso com arquivos maiores do que cabe na tela. Vamos dar um exemplo:

Ps aux Esse comando lista todos os processos rodando no sistema, incluindo os que não foi você que iniciou e sim o initd do sistema operacional e outros serviços. Você pode ver como ele não cabe na tela e você precisa scrolar no terminal pra ver o começo. Usando o comando more temos o seguinte: Ps aux | more Essa é uma das características marcantes dos UNIX e Linux: a capacidade de ligar o standard output de um comando ao standard in de outro comando usando o simbolo de pipe que é essa barra vertical. Eu expliquei sobre isso na minha série de Começando aos 40, por isso falei pra assistir. Mas veja como aqui ele começa a listar e pára na primeira tela e agora eu posso ir avançando aos poucos. O more é um comando antigo e primitivo, ele primeiro precisa carregar todo o conteúdo em memória pra depois ir mostrando tela a tela. Não é muito eficiente e não recomendo que faça isso com arquivos de log de gigabytes por exemplo. Na prática, você não precisa usar nem cat e nem more, existe uma versão mais moderna, o less: Ps aux | less O less faz a mesma coisa que o more, deixa você navegar por conteúdos longos que não cabem numa tela. Porém ele faz isso baseado em streams, como eu também expliquei na minha série. Em vez de carregar tudo na memória, ele vai puxando do stream só o que precisa pra preencher uma tela e navegar. Mais do que isso ele permite usar alguns dos mesmos comandos de navegação do editor de textos VI. Então você pode usar j k como cima, baixo,, você pode digitar “gg” minúsculo pra voltar pro topo do arquivo, pode digitar 10j pra descer 10 linhas ou 5k pra subir 5 linhas. E pode digitar barra com uma palavra que quer procurar e ir descendo usando n. E finalmente digitar q de quit pra parar. Ln -s a.txt b.txt Eu falei de links simbólicos ou symlinks antes e é assim que você cria: ln -s arquivo de origem e nome do symlink. Agora esse b.txt é só um atalho mas você pode usar ele como se fosse um arquivo, por exemplo se fizermos cat b.txt veremos o mesmo conteúdo de a.txt. Mas podemos fazer mais ainda. tail -f b.txt Tail é um comando pra ver o final do arquivo, você pode fazer tail -10 pra ler a 10 últimas linhas, ou pode fazer tail -f pra se pendurar no final do arquivo. Pra demonstrar vamos abrir outro terminal e começar a apendar coisas no arquivo a.txt. echo “foo” >> a.txt Estão vendo como eu estou mandando coisas pro fim do arquivo a.txt mas o tail do symlink b.txt vai me mostrando o que está sendo gravado? São coisas assim que tornam o Linux um bicho diferente. Comandos como tail -f são super úteis quando você quer ficar monitorando um arquivo de log em produção por exemplo. Eu mostrei rapidamente como podemos usar comandos como ps pra mostrar informações dos processos em execução, você pode pesquisar mais sobre os binários que estão nos diretórios /sbin ou /bin ou /usr/bin como falei antes. Mas com o conceito de pipes podemos ir mais longe e conectar o standard output de um comando ao standard input de outro comando. Por exemplo, vamos fazer Ps aux | grep bash E isso vai filtrar a saída do ps pra só mostrar as linhas que tem a palavra bash. O grep é um comando antigo que permite processar texto usando regular expressions similares de Perl 5. Hoje em dia usamos outros como o ag, que é o silversearcher. Ele aceita regex similares mas é muito mais rápido que grep. Se você não entendeu porque chama silversearcher é porque AG é o símbolo pra prata na tabela periódica. Mas digamos que estamos interessados em pegar os IDs de processo, os PIDs dos processos bash. Podemos ver que é a segunda coluna. Como filtramos por coluna? Uma das muitas opções é usar o AWK que é outra ferramenta super tradicional de UNIX e Linux e colocar outro pipe no fim desse comando: Ps aux | ag bash | awk ‘{ print $2 }’ Olha o que aconteceu! Por padrão ele splita as linhas pelo separador padrão que é espaço, mas podemos configurar outros separadores incluindo regex também. O AWK é uma linguagem de programação interpretada, como um Perl, voltado a processar dados e textos. Finalmente, digitamos vários comandos, e talvez você não se lembre de cor de tudo que digitou, ninguém lembra. Por isso shells como o Bash tem history, todos os comandos que você digitou até agora ficam gravados. Basta ir apertando a seta pra cima pra navegar pelos últimos comandos. Mas e se você quer lembrar dum comando que digitou sei lá, 2 semanas atrás? Se ficar apertando seta pra cima vai ficar fazendo isso até amanhã. Pra isso o Bash tem um atalho, digite Ctrl R e comece a digitar uma parte do comando. Agora vai apertando Ctrl R pra navegar pelo histórico filtrado pelo que acabou de digitar. Viu só? De bônus deixa eu mostrar os últimos comandos que você precisa. Pra apagar um arquivo você faz: rm b.txt. Podemos criar um diretório com mkdir foo. Podemos mover um arquivo pra lá com mv a.txt foo. Se quisermos apagar um diretório só rm foo não funciona. Pra isso precisamos força com rm -f foo. E pronto, você já sabe o básico de como manipular diretórios, arquivos e comandos. Um comando que é complexo é o chmod e a regras de permissão mas por hoje entenda que todo binário ou script, pra ser executável precisa ter permissão de execução e a forma que você dá essa permissão é via o comando chmod +x seu_script.sh A partir daqui é com você!

Veja e reveja essa demonstração que eu acabei de mostrar caso você seja um iniciante. Esses são os conceitos mais importantes que você precisa dominar pra seguir em frente. E dominar significa chegar num ponto em que você sequer pensa mais nisso. Se você usar o Nautilus que é que nem o Explorer, dá pra fazer tudo isso com o mouse. Arrastar, apertar F2 pra renomear ou DEL pra apagar um arquivo. Não tem problema. Mas quando você se conectar remotamente num servidor você não vai ter ambiente gráfico, só um shell. E por isso você precisa saber esses comandos. Mais do que isso, você precisa aprender a combinar os comandos como mostrei aqui com pipe pra fazer coisas como mover só arquivos com determinada nomenclatura pra outro diretório por exemplo, ou só arquivos que tenham determinado conteúdo.

E quando você precisa manipular muitos arquivos com critérios mais complicados assim, é onde programar scripts de Bash começa a fazer sentido. E sim, o Bash em si é um ambiente de programação que tem variáveis, comandos como if, e você pode executar um script que automatiza tudo pra você. E, claro, você pode combinar o Bash com outras linguagens como o AWK ou mesmo Perl, Python, Ruby ou outras linguagens e com alguns dos conceitos que mostrei pra vocês como saber que você tem seus dispositivos em /dev, seus processos representados em /proc, suas configurações em /etc e assim por diante, você pode fazer scripts que manipulam seu sistema inteiro. Aí você começa a se sentir realmente o dono da sua máquina. Tem bastante coisa pra estudar aqui.

Falando em outras linguagens de programação. Chegou a hora de avançarmos mais rápido e montarmos de uma vez esse ambiente. Como eu falei antes, até este ponto na instalação seu Linux está bom pra ser usado por usuários comuns. Mas pra virar sistema de desenvolvimento a primeira coisa que você precisa instalar são compiladores e todas as dependências de desenvolvimento do sistema. Pra isso vamos instalar os seguintes pacotes:

sudo apt install build-essential default-jdk libssl-dev exuberant-ctags ncurses-term ack-grep silversearcher-ag fontconfig imagemagick libmagickwand-dev software-properties-common git vim-gtk3 curl

O principal pacote é o build-essential que como o nome diz tem todo o essencial pra fazer builds. Aproveito também pra já instalar o JDK pra termos não só a JVM como o compilador do Java mais novo. Poderíamos instalar outras linguagens com o APT também como Ruby ou Python e outras, mas você precisa entender um problema desta atualidade de 2019. Linguagens mais antigas e mais estáveis como C, C++ e Java mudam com pouca frequência. De vez em quando sai patches de segurança mas não mudanças que quebram compatibilidade. Uma vez a cada X anos o C muda. Por isso é bom instalarmos via gerenciador de pacotes. Porém outras linguagens como Go ou Javascript mudam com muito mais frequência e os pacotes de distros Linux normalmente não acompanham tão de perto porque os objetivos são diferentes: as distros preferem manter versões estáveis, que já foram testadas em produção, que já receberam correções de bugs. Mas nós desenvolvedores preferimos ter acesso às versões mais instáveis justamente porque precisamos testar as coisas novas mesmo se não formos usar em produção.

Pior, nós trabalhamos em diversos projetos diferentes. Alguns projetos são novos e usam, por exemplo Ruby 2.6.3. Mas às vezes precisamos dar manutenção em projetos de 3 ou 4 anos atrás que podem estar ainda num Ruby 2.4.4 por exemplo. Significa que precisamos ter todas essas versões instaladas na nossa máquina ao mesmo tempo. O mesmo vale pra Javascript ou outras linguagens. Mas o gerenciador de pacotes de uma distro Linux só gerencia uma versão. Depois que ela atualiza, a versão antiga não existe mais. Então precisamos de um jeito por fora pra gerenciar isso. Ao longo dos anos cada linguagem veio construindo seu próprio gerenciador de versões como o RVM e RBENV no Ruby, ou o NVM do Javascript, ou o Virtualenv do Python. Mas também é um saco ter que ficar lembrando as sintaxes e configurações de tantas ferramentas diferentes. E pra nos salvar surgiu o gerenciador de versões Universal, o ASDF. Vamos instalar pra vocês verem.

(…)

Aliás, aprendam a usar o Google. Olhem como eu vou fazer. Eu falei ASDF, é um nominho que pode confundir o Google, coloquem github como termo se precisar. Vamos seguir o que diz na documentação pra instalar.

– instalar via Google

O truque do ASDF é usar variáveis de ambiente do shell. Quando você digitar ruby ou npm, ele não vai executar diretamente o binário chamado ruby. Na verdade ele vai procurar no PATH. Eu não falei de PATH então vamos dar echo no PATH. Tudo que você digita no shell, se não for uma instrução do próprio Bash ele entende como sendo um binário executável e vai procurar por ele nos diretórios listados nesse PATH. Você pode tentar saber de onde o Bash está executando determinado binário usando o comando which por exemplo o tal echo que acabamos de fazer se digitar which echo vemos o PATH completo dele, e aliás, o echo é um binário do sistema e não instrução de Bash.

Pra ficar mais fácil de gerenciar, o ASDF em si é um framework, ele não tem suporte a linguagem nenhuma. Em cima do ASDF precisamos instalar plugins. Então vamos instalar os diversos plugins pras linguagens. Leia as instruções. No caso de Javascript vemos que ele tem comandos pra instalar chaves públicas pra validar a instalação. No caso de Erlang vemos que ele manda instalar várias dependências do sistema, siga as instruções. linguagens, javascript, golang, erlang, elixir, kotlin, rust, crystal

Pronto, agora que instalamos os diversos plugins, podemos instalar as linguagens em si. Usamos o comando list-all do asdf pra listar quais versões estão disponívels pra instalar daí podemos fazer asdf install linguagem versão pra instalar a que queremos. Então vamos lá instalar o Ruby primeiro. Ao terminar, agora precisamos declarar que queremos usar essa versão e pra isso fazemos asdf global ruby 2.6.3 e se digitarmos ruby -v vemos que agora o Ruby está disponível. Dentro de um projeto antigo podemos usar asdf local ruby 2.4.4 depois de instalar a versão 2.4.4 pra só dentro daquele projeto ele escolher o Ruby mais antigo. E com isso resolvemos nosso problema de ter projetos que dependem de versões diferentes. Agora vamos fazer a mesma coisa pra todas as outras linguagens, javascript, golang, erlang, elixir, kotlin, rust, crystal

Digitem asdf help pra ver outros comandos mas os próprios plugins podem precisar de atualização e pra isso podemos fazer asdf plugins-update. E pra atualizar o asdf de vez em quando podemos fazer asdf update. Agora, se fizermos which ruby vemos que ele executa um script nesse diretório de reshims. Todo script executável que um ruby instalaria talvez num /usr/local/bin agora é instalado nesse reshim. Um NPM do javascript também ou outro pacote de Javascript como yarn que você instala com a flag de -g pra global. Se por acaso você instalar uma biblioteca que deveria ter um executável no PATH como webpack ou yarn mas ele não é encontrado quando você digita, pra garantir que está tudo bem, digite asdf reshim pra ele recriar esses shims, que são como proxies.

De qualquer forma, agora que instalamos e declaramos quais versões queremos que estejam ativas globalmente, temos acesso a todas as linguagens que quisermos. Em particular essas são as linguagens que mais me interessam hoje em dia. Mas existem dezenas de outros plugins pra tudo que é linguagem que você imaginar. Tem até coisas velhas como Prolog ou linguagens modernas como Julia. Procure e instale o plugin que você precisa e divirta-se.

(…)

Agora que instalamos todas as linguagens, vamos instalar alguns serviços que você provavelmente vai precisar. Eu sempre gosto de deixar instalado o Postgresql, o Redis e o Memcache. Um banco de dados relacional decente, um nosql que faz o mínimo que precisamos, e um cache pra quando não precisamos do Redis como banco. Tá, vou deixar instalado o Mongodb também, mas se você viu minha série de devops já sabe que eu não recomendo que você escolha Mongo como banco primário sem saber se realmente precisa. E normalmente não só você não precisa como você pode acabar usando o Mongo onde na verdade o mais adequado teria sido o Postgresql. Na dúvida, sempre escolha o Postgresql como padrão, nunca o Mongo, nem muito menos o Redis. Redis é um bom cache. E Mongo é bom pra dados que se você perder, não vai fazer muita falta, como dados de analytics ou logs.

sudo apt install postgresql-10 postgresql-contrib postgresql-server-dev-10 redis-server libhiredis-dev memcached libmemcached-dev

Pra instalar o Mongo precisamos seguir as instruções do site oficial. Nem vou deixar o link nas descrições, vocês precisam aprender a fazer um google por mongo install ubuntu 18.04 que vai aparecer o link certo. https://docs.mongodb.com/manual/tutorial/install-mongodb-on-ubuntu/

Ao que parece, os pacotes do Mongo não estão nos repositórios oficiais do próprio Ubuntu e isso é comum com software de terceiros. Pra começar precisamos instalar as chaves públicas do MongoDB pra validar os pacotes que vamos instalar:

sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv 9DA31620334BD75D9DCB49F368818C72E52529D4

Agora precisamos adicionar os repositórios do Mongo na lista de repositórios do gerenciador de pacotes APT e puxar a lista de pacotes:

echo "deb [ arch=amd64 ] https://repo.mongodb.org/apt/ubuntu bionic/mongodb-org/4.0 multiverse" | sudo tee /etc/apt/sources.list.d/mongodb-org-4.0.list

sudo apt-get update

Esse comando tee, é parecido com o que eu mostrei antes com o » pra apendar novas linhas no final de um arquivo. O que acabamos de fazer foi dizer pro APT procurar pacotes nesse endereço novo também.

Agora podemos instalar o mongo em si:

sudo apt-get install -y mongodb-org

sudo service mongod start

Tanto Postgresql, Redis, Memcache e Mongo vem com daemons que podem carregar sozinhos depois do boot do sistema. Se você tem bastante memória sobrando pode deixar eles ativos que não vai fazer diferença. Se precisar derrubar ou restartar basta usar o comando service mongod stop ou restart. Porém, se você prefere que eles não carreguem automaticamente, você pode fazer service mongod disable e depois fazer service mongod start manualmente toda vez que precisar.

Esse comando service é importante de lembrar no Ubuntu. Ele executa esses comandos start ou stop que estão declarados no que chamamos de um init script. Esses scripts ficam em /etc/init.d por exemplo vamos ver o que tem no do redis fazendo cat /etc/init.d/redis-server

E podemos ver cada um dos comandos de start, stop, status e o que eles fazem quando são chamados. Podemos nem usar o comando service e ir direto no script também: sudo /etc/init.d/redis-server status

Mas o comando service é mais simples de lembrar. Em outros sistemas operacionais usando Systemd pra controlar daemons também existe o comando systemctl. A diferença é que com o comando service a gente faz service [nome do serviço] e [comando] tipo service mongod start. Mas o systemctl é o contrário e fazemos systemctl start mongod, eu sempre me confundo. Antigamente o Ubuntu usava o Upstart e hoje usar o Systemd. Existe uma grande controvérsia em torno desse systemd mas hoje não vou fazer essa tangente. Na prática pra você é importante só lembrar que existem serviços e daemons e é assim que você gerencia esses serviços.

De qualquer forma, memcache, redis e mongo, por padrão não precisam de senha pra conectar nos servidores, por isso por padrão você jamais deve expor esses servidores na internet. O Postgresql você precisa configurar usuários pra conectar no servidor e pra fazer isso você precisa se logar como o usuário postgres e de lá criar novos usuários. Se tentarmos usar o cliente de posgresql que é o psql ele vai dar erro. Então pra criar um novo usuário precisamos fazer:

sudo su postgres
createuser --interactive - aqui crie um usuário com o mesmo nome do usuário que você está usando pra logar no sistema, isso vai facilitar sua vida
createdb akitaonrails - e crie um banco de dados com o mesmo nome do seu usuário
Exit

Pronto agora se fizermos psql provavelmente vamos logar direto no shell do postgresql. Viu? Agora quando estiver desenvolvendo sua aplicação, seu framework favorito provavelmente vai conseguir conectar fácil sem precisar declarar senha nem nada. Obviamente isso é pra ambientes de desenvolvimento. Em produção você não vai conectar num usuário que é superuser. Mas está fora do escopo deste episódio fazer tutorial de Postgresql pra produção. Mas você já sabe o que fazer: GOOGLE.

Tem gente que prefere não instalar esses serviços diretamente, pelo mesmo motivo que usamos ASDF. E se você tem um projeto antigo que depende do PostgreSQL 7 e quebra se tentar conectar no Postgresql 10? Pra isso precisamos de algo parecido com um ASDF. E se não me engano acho até que o ASDF tem suporte pra Postgresql, vamos ver no google, e sim, tem mesmo. Mas se for esse o caso eu prefiro fazer diferente. Serviços como os que acabamos de instalar é o caso de uso perfeito pra usar Docker. Então é hora de instalar e configurar Docker. E a essa altura você já adivinhou: vamos pro GOOGLE.

Seguindo as instruções, primeiro ele recomenda apagar versões antigas, caso você tenha. Como esta demonstração começou do zero, não precisamos fazer isso. Então vamos pular esse passo e instalar direto o que precisamos:

sudo apt-get install \
    apt-transport-https \
    ca-certificates \
    curl \
    gnupg-agent \
    software-properties-common


curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -

Mesma coisa que fizemos com o Mongo, instalamos chaves públicas do povo do Docker pra validar os pacotes. Se você não entendeu, todo pacote que vem nos repositórios oficiais do Ubuntu são assinados digitalmente pela chave privada do povo da Canonical que faz o Ubuntu. Mas quando adicionamos repositórios externos, eles são assinados por outras chaves. Então primeiro instalamos a chave pra depois instalar os pacotes. Esse passo é importante porque caso você seja enganado a instalar manualmente pacotes que foram modificados por um hacker, ele não vai ter a chave privada da Canonical então teoricamente o APT vai recusar instalar esse pacote. Claro, se você for enganado a instalar a chave do hacker também, aí já era, então sempre preste atenção no que está fazendo. Veja como no caso do comando anterior estamos instalando a chave vinda do domínio docker.com e não de um domínio com cara de russo.

Agora que instalamos as chaves, assim como fizemos com o Mongo vamos adicionar novos repositórios pro APT. A diferença é que na instrução do Mongo usamos o comando tee pra adicionar o arquivo com o repositório manualmente e aqui estamos usando o comando add-apt-repository que vem no pacote software-properties-commons.

sudo add-apt-repository \
   "deb [arch=amd64] https://download.docker.com/linux/ubuntu \
   $(lsb_release -cs) \
   stable"

De bônus, como eu sei que o add-apt-repository vem no software-properties-commons? Porque eu posso checar com o comando dpkg -L software-properties-commons. Viu?

Enfim, agora precisamos puxar a lista de pacotes novos com apt update e instalar os pacotes do Docker propriamente ditos:

sudo apt-get install docker-ce docker-ce-cli containerd.io

Você devem ter notado que eu uso o comando apt e muitas instruções vem com apt-get. Na prática apt é o jeito novo, mas apt-get ainda funciona. De qualquer forma agora temos os pacotes todos instalados. Mas o Docker ainda tem um pequena configuração: ele cria um grupo de usuários chamado docker e o usuário que vai gerenciar o Docker precisa estar nesse grupo, então vamos fazer o seguinte:

sudo usermod -aG docker $USER

Você já sabe que existe a variável $HOME que o tilde expansion usa, e o whoami que eu mostrei lá no começo usa essa variável $USER que tem o nome do seu usuário. Se quiser ver todas as variáveis do ambiente, digite o comando set | less pra ver as dezenas de variáveis que estão disponíveis no seu ambiente. Mas enfim, agora que nosso usuário está no grupo, acho que precisamos deslogar e logar de novo. Vamos restartar pra garantir.

Pra testar, basta fazer docker run hello-world e se tudo deu certo ele vai baixar a imagem de Docker de uma aplicação que só imprime um Hello. Mas nós estávamos falando em baixar o Postgresql, então vamos fazer isso. Você já sabe a rotina: GOOGLE (hackernoon)

docker pull postgres

O comando docker pull baixa a imagem mais recente. Agora vamos criar um diretório externo pra onde o postgres vai gravar os bancos de dados e tudo mais:

mkdir -p $HOME/docker/volumes/postgres

Agora vamos nos certificar que o postgresql que instalamos nativamente no sistema agora a pouco está desligado com sudo service postgresql stop e sudo service postgresql status. Agora podemos iniciar o Postgresql via Docker que acabamos de instalar:

docker run --rm --name pg-docker -e POSTGRES_PASSWORD=docker -d -p 5432:5432 -v $HOME/docker/volumes/postgres:/var/lib/postgresql/data postgres

Teoricamente agora podemos usar o cliente nativo psql pra conectar nesse docker assim:

psql -h localhost -U postgres -p Senha postgres

Pronto!! Estamos no postgresql. E se seu projeto tiver configuração pra Docker Compose, você pode subir sua aplicação web num container, seu postgresql em outro container e tudo gerenciado pelo Docker. E aproveitando que falei de Docker. Vamos dar um ps aux na máquina e você vai ver que o postgresql está visível (!!). Pra você que ainda acha que Docker é uma máquina virtual, ele não é. O postgresql está subindo normalmente, nativamente, em cima do mesmo kernel que você está. Agora vamos pegar o PID do processo e dar um cat /proc/PID/cgroup. Lembram do meu episódio sobre containers e virtualização quando expliquei que o cgroup é um jeito do sistema operacional mentir pro processo? Compare com a configuração de cgroup do bash por exemplo (ps | grep bash; cat /proc/PID/cgroup). Essa é a configuração normal pra um processo que enxerga o sistema todo e em cima vemos como é o cgroup que o Docker configura pro processo não enxergar o sistema todo. É assim que o Docker funciona e é por isso que ele é tão leve: ele está rodando lado a lado com seus outros programas.

Eu recomendo que você pegue qualquer tutorial pra aprender os comandos básicos. Aqui acabamos de ver o docker run e docker pull, também tem o docker ps pra mostrar os containers rodando a partir de onde podemos pegar o nome do container e o docker stop [nome do container] pra parar o postgres que acabamos de subir. Tem comandos pra gerenciar os volumes de disco virtuais, pra baixar versões diferentes desse postgres, e assim por diante. E como eu já falei, aprenda a usar Docker Compose pra criar um mini cluster de containers que conseguem acessar uns aos outros.

(…)

Já que eu mencionei chaves, vou aproveitar pra fazer uma explicação super porca. No mundo de criptografia existem pelo menos 3 tipos de tecnologias que você precisa saber. Existem algoritmos de digest, que literalmente digere qualquer blob de bits e devolve uma impressão digital de tamanho fixo. Exemplos disso são os antigos MD5 ou SHA1 e coisas mais novas como SHA512 ou Bcrypt ou HMAC. Você pode passar pra eles uma palavra ou a Wikipedia inteira e eles vão sempre cuspir um string de tamanho fixo. Isso você usa pra garantir que a informação não foi adulterada porque se você mudar um bit nessa Wikipedia que eu falei, a impressão digital vai ser completamente diferente. A gente usa isso pra tudo hoje em dia, sempre que você ver strings com caracteres que parecem aleatórios, normalmente é um fingerprint, ou impressão digital.

A segunda categoria são os algoritmos de encriptação reversível. Aqui é o que a maioria das pessoas pensa quando pensa em criptografia: uma forma de bagunçar a mensagem e ter uma senha. E quando passar a senha a mensagem é descriptografada. De novo você tem coisas antigas como o Triple DES ou Blowfish e coisas mais recentes como o AES que é usado pra criptografar seu HD por exemplo. Quando você vê nos filmes alguém tentando quebrar uma encriptação em força bruta ou algo assim, normalmente é um algoritmo reversível ou mais corretamente chamada de criptografia simétrica.

Finalmente, temos criptografia assimétrica. Nessa categoria temos a geração de duas chaves que costumam ser dois números primos relacionados. Por convenção chamamos um desses números, tanto faz qual, de chave privada e ela nunca deve sair da máquina de onde foi criada. O outro número chamamos de chave pública e ela pode ser distribuída por aí, como as chaves que instalamos do povo do Mongo e Docker antes. Tudo que for criptogrado pela chave privada só pode ser aberta pela chave pública e vice-versa. O que é criptografado com uma chave não pode ser aberta com a mesma chave, necessariamente precisamos da outra. Esse é o conceito de chaves públicas e privadas.

Eu expliquei tudo isso porque na nossa instalação, se você ainda nao fez isso, precisa ter seu próprio par de chaves. Serviços como GitHub ou GitLab ou tudo da Amazon AWS ou Google Cloud ou Azure, exigem que você cadastre sua chave pública na sua conta, daí o que você criptografar com sua chave privada local pode ser checada com a pública que você cadastrou e assim podemos nos certificar que você é realmente você.

(…)

Pra criar uma chave é simples, no terminal fazemos:

ssh-keygen -o -a 100 -t ed25519 -f ~/.ssh/id_ed25519 -C "boss@akitaonrails.com"

Normalmente a maioria dos tutoriais vai mandar você criar uma chave com algoritmo RSA mas hoje em dia preferimos usar a ed25519 por ser mais segura. Ela vai pedir um passphrase, que de preferência como o nome diz é uma frase secreta grande que você não vai esquecer. Esse comando vai criar dois arquivos no diretório .ssh do seu home, o id_ed25519 e o id_ed25519.pub, que se você prestou atenção, representam a chave privada e a chave pública. Vamos ver o que tem dentro:

cat ~/.ssh/id_ed25519

Eu estou mostrando aqui a chave privada e não deveria obviamente, mas eu nunca vou usar essa chave de verdade, a minha está bem guardada. Mas só pra vocês verem como se parece uma chave privada. Faça backup do seu diretório .ssh que tem essas chaves. Se você perder a chave, não tem mais como recuperar só a partir da pública, obviamente. Toda vez que você precisar cadastrar sua chave, por exemplo num servidor SSH de alguém, vai precisar mandar o conteúdo do outro arquivo:

cat ~/.ssh/id_ed25519.pub

Isso é sua chave pública. Essa você pode mostrar pra qualquer pessoa. É essa chave que você cadastrar na Amazon ou no GitHub, por exemplo nessa página deles (mostra GITHUB).

Pra você não ter que ficar digitando a passphrase toda hora, na sua máquina precisa ter o serviço ssh-agent. Você checa se ele tá rodando assim:

eval "$(ssh-agent -s)"

Agora adicione sua nova chave no agente, daí ele só vai pedir sua passphrase uma vez e você pode ficar se logando nos servidores SSH que precisar sem toda hora ter que redigitar a passphrase:

ssh-add ~/.ssh/id_ed25519

Muito bem, agora você é um cidadão respeitável e criptograficamente identificável na nossa sociedade. NUNCA mas NUNCA compartilhe sua chave privada. E faça backup num pendrive que você vai guardar num cofre ou algo assim. Enfim, cuide da sua chave, ela é sua identidade. Se por acaso perder, gere outra e substitua a chave pública em todos os servidores e serviços que tem acesso. Quem tiver sua chave privada tem acesso a tudo que você tinha acesso.

E já que falamos em Github, falta configurar o Git também. Existem milhares de bons tutoriais pra iniciantes no GOOGLE então aprenda de uma vez porque isso é obrigatório, mas a primeira coisa que você precisa fazer é configurar seu nome e seu email assim:

git config --global user.name "AkitaOnRails"
git config --global user.email "boss@akitaonrails.com"

Isso é a configuração global padrão. Então todo commit que você fizer vai com essa identificação. E se você quiser usar nomes e e-mails diferentes pra projetos diferentes, você pode configurar no arquivo .git/config em cada projeto também, assim você pode ter e-mail pessoal nos projetos pessoais e e-mail da empresa em projetos de clientes se fizer muita questão. Eu uso sempre meu pessoal pra tudo.

Pronto, agora temos os principais pacotes de desenvolvimento instalados, temos todas as linguagens que vamos precisar, temos até bancos de dados e docker instalados. Agora vem uma parte que é muito particular só pra mim. Eu gosto muito de usar VIM como editor de textos. Hoje em dia você pode ser virar muito bem com Visual Studio Code que eu recomendo como uma das melhores opções modernas, seguindo do bom e velho Sublime Text 3. Tem o Atom do GitHub também mas eu acho que o Atom é muito pesado por ser totalmente em Electron e eu prefiro evitar Electron como eu evitaria uma praga. O VS Code tem partes em Javascript mas se não me engano ele usa uma toolkit híbrida com componentes nativos e isso torna ele mais responsivo. Porém tanto VS Code quanto Atom, por terem muito Javascript por baixo, é que nem uma aba de Google Chrome: come memória como se não houvesse amanhã. O Sublime Text 3 é totalmente nativo e extremamente leve. E o VIM obviamente é mais leve ainda. Eu gosto de editores de texto que eu chamo e abrem instantaneamente, em milissegundos pra ser mais exato, senão eu me entedio muito rápido.

Na realidade o GVIM já está instalado. O VIM é um editor que você abre na linha de comando, mas existe o VIM-GTK que é o mesmo VIM só que aberto dentro de uma janela gráfica de GNOME e com algum suporte básico a mouse também. Tanto faz qual dos dois você vai usar. Na verdade faz diferença. Aqui eu vou dividir o caso de uso pra usuários como eu que tiveram história usando tantos ambientes puramente de texto e também ambientes gráficos como Mac e aqueles que tem a oportunidade de começar sem vícios só no ambiente de texto do Linux. Agora eu vou mostrar a combinação que a maioria dos veteranos de Linux realmente gostam. Vamos instalar o TMUX, o sucessor do lendário GNU Screen que a gente usava antigamente.

(..)

Pra instalar é simples: apt install tmux.

O TMUX é um multiplexer de terminal. Esse palavrão significa que você ganha a capacidade de ter mútiplas sessões de terminal dentro de um único terminal. Lembram os workspaces gráficos do GNOME que seria como se fossem monitores virtuais? O TMUX são terminais virtuais. Você inicia com o comando tmux. Aqui ainda não tem nada demais, parece o mesmo terminal de sempre. Vamos abrir um VIM agora e editar alguma coisa. O básico de VIM é que ele tem dois modos, modo de comando e modo de edição. Ele sempre está no modo de comando, mas apertando comandos como i ou a de insert ou append, você entra no modo de edição. Agora você pode editar normalmente e quando terminar aperte ESC e volta pro modo de comando. Agora podemos gravar o arquivo com o comando :w /tmp/teste.rb por exemplo. Nesse modo também podemos navegar, por exemplo com as teclas hjkl que no teclado ficam um do lado do outro e servem como setas. Podemos fazer gg ou G pra ir pro começo ou fim do arquivo. Podemos combinar comandos como 10l pra andar 10 caracteres pra direita. E pra sair do VIM apertamos ESC pra garantir que estamos no modo de comando e fazemos :q pra dar quit. Isso é o mínimo do mínimo pra você navegar no VIM. Mas voltando ao TMUX.

Digamos que eu queira executar esse script idiota que eu acabei de fazer. Eu posso agora apertar a combinação Ctrl b % e boom temos um split do terminal. Com Ctrl b O eu posso navegar pelos painéis. Ctrl b “ faz split em outra direção. E Ctrl b w fecha o painel. Fala que isso não é bem foda. Tanto TMUX quanto VIM tem essa funcionalidade de split horizontal e split vertical que eu acho ultra útil e sei lá porque razão nenhum outro editor de textos tem exatamente a mesma funcionalidade. Terminais que fazem split tem vários hoje como o Tilix que vamos instalar já já, ou o iTerm2 em MacOS.

Mas o que torna o TMUX diferente é o seguinte: e se eu fechar o aplicativo do Terminal inteiro? Vamos fazer isso. Se fosse no Terminal normal ou num iTerm2 da vida, você acabou de perder tudo que estava fazendo e vai ter que abrir tudo. Mas não no TMUX eu posso fazer o comando tmux ls, pra listar as minhas sessões e olha só: tem uma sessão ativa. Agora posso fazer tmux attach-session -t 0 que é o número da sessão e boom, tudo exatamente com eu tinha deixado. Isso era particularmente útil quando você só tinha terminais burros conectados remotamente num servidor via TELNET porque e se a conexão caísse bem quando você estava no meio de uma edição de código? Você perdia o que estava fazendo. Mas se estivesse usando o GNU Screen a sessão permanecia rodando no servidor, você podia esperar a conexão voltar, conectar de novo com seu terminal burro e recuperar a sessão que ainda estaria ativa.

Acho que isso deve convencer vocês a aprender tmux. Da próxima vez que precisar se conectar via SSH num servidor remoto pra fazer alguma coisa que vai demorar, abra um TMUX primeiro. Se por acaso der pau na sua máquina ou na sua conexão por alguma razão, você não vai perder nada que estava fazendo. Basta reconectar e dar attach na session que ainda vai estar ativa lá. E pra ser ainda mais versátil, você pode ver que já tem paineis demais aqui né? Vamos criar uma outra janela inteira com Ctrl b c e agora podemos navegar com Ctrl b n. Ou seja, você pode estar fazendo várias coisas em paralelo em múltiplas janelas de terminais splitadas em múltiplos painéis e você não vai perder nada caso feche essa janela. No final você pode fazer Ctrl b d pra desatachar manualmente. Se quiser mesmo fechar tudo que estava aberto na sessão você pode fazer tmux kill-session -t 0. Pra saber todos atalhos de teclas e comandos que o tmux aceita, o man tmux vai ajudar muito.

Pronto, com isso você tem o ambiente perfeito. Mas ainda falta mais uma coisa. O VIM puro é bem inútil na verdade, ele não é muito diferente de um NANO que você vê em muito tutorial. Eu particularmente fico irritado de ver o nano. O nano é derivado do antigo editor PICO que era o editor do cliente de e-mails antigo chamado PINE que eu inclusive usei muito na faculdade no meio dos anos 90. PICO era conterrâneo do editor JOE que por sua vez era inspirado no editor de MS-DOS, o Wordstar que eu usava no fim dos anos 80. São editores velhos, cansados, que eu não teria coragem de usar hoje em dia pra programar.

O VIM, assim como o Emacs são extremamente versáveis porque são scriptáveis. O Emacs em Emacs Lisp ou eLisp e o VIM em VimScript. Por causa disso podemos adicionar funcionalidades modernas como colorização de sintaxe pra cada linguagem, auto complete e muito mais. Infelizmente eu nunca tive muito saco pra aprender Emacs e o Vim sempre foi suficiente pra mim. Ele é leve e tem todas as funcionalidades que eu preciso. Mais do que isso: ele é perfeito pra editar coisas remotamente via SSH se precisar. Ele foi feito pra ter comandos e atalhos curtos, pra era onde conexões de rede eram lentas. E isso é perfeito porque mesmo hoje em dia ainda temos que lidar com conexões lentas ou instáveis de vez em quando.

E aqui vem a parte que é bem subjetivo ao mesmo próprio gosto. Por isso esta parte é opcional e você vai encontrar outras configurações diferentes. Até agora estávamos usando o Terminal que já vem no Ubuntu, eu prefiro usar o Tilix como já falei. Eu também prefiro usar o Z Shell em vez do Bash e eu tenho um conjunto de dotfiles que eu já me acostumei e gosto bastante.

Então vamos instalar:

sudo apt install tilix zsh

Feito isso agora é hora de instalar os dotfiles que eu gosto. Lembre dessa palavra dotfiles. Eu já expliquei que todo arquivo ou diretório que começa com ponto é escondido, e no seu diretório home vai começar a aparecer vários assim como o .config que o GNOME usa pra colocar configurações ou o .gcloud se você configurou as ferramentas do Google Cloud. Mas do que isso tem .vim pra configurações do VIM. Mas existem vários projetos no Github com dotfiles pré-prontos, um dos mais famosos pra ZSH é o Oh-my-ZSH que é bem customizável mas eu prefiro o do usuário SKWP que se instala assim:

sh -c "`curl -fsSL https://raw.githubusercontent.com/skwp/dotfiles/master/install.sh `"

Ele precisa de Ruby, por isso já instalei via ASDF lá atrás. Vamos entrar no diretório .yadr e rodar rake update e deixar ele trabalhar.

Pronto, no final ele vai instalar temas como o Solarized Dark, vai configurar o prompt pra mostrar o branch de Git que você está e deixa tudo organizado no lado do ZSH e do VIM pra você customizar e adicionar novos plugins se precisar. Por exemplo, eu quero mudar a fonte do VIM pra ser a fonte Hack que instalamos antes. O VIM tem uma tecla especial chamada de Leader que dependendo do dotfiles pode estar assinalada pra qualquer coisa mas neste pacote é a vírgula. Com virgula T eu posso procurar por arquivos como o Ctrl P no Sublime ou VS Code. Vamos abrir o yadr-appearance. Olha como está tudo colorido corretamente. Vamos navegar e adicionar a fonte.

No Tilix também quero mudar o tema pra ser Dark e usar Solarized com fonte maior e bordas menores. E também mudar o atalho de splitar a tela que seria Ctrl Alt D para outra coisa como Ctrl Alt E e a razão disso é porque no Ubuntu esse atalho já é usado pra esconder a janela. E pronto. Veja porque eu disse que aqui é uma questão de que tipo de usuário você é. Você pode usar um terminal maximizado com TMUX e splitar pra ter o VIM de um lado e o terminal do outro pra você trabalhar, OU, no caso de alguém como eu que já se acostumou ao iTerm2 no Mac e MacVim, eu prefiro deixar um terminal aberto de um lado que eu posso facilmente splitar com Ctrl Alt E e Ctrl Alt R e navegar com ALT e numero do terminal e do outro lado o GVIM que eu também posso splitar usando ss ou vv e navegar com ctrl shit e as teclas de navegação hjkl.

Só pra exibir essa versão customizada de vim, veja como eu posso facilmente substituir uma palavra inteira com ciw ou usar o pacote de git pra dar um :Gblame ou :Gdiff, ou então abrir um explorador de arquivos inteiro que é o NerdTree com Alt Shift N e os comandos de navegação são os mesmos pra painéis splitados então ctrl alt l ou j. E :q fecha cada painel. :w grava. :e serve pra abrir outros arquivos. Posso usar :Ag que se integra com o silversearcher pra procurar rapidamente em todos os arquivos do projeto.

E agora sim, eu tenho tudo que eu preciso instalado. Se eu estiver no humor de usar 100% terminal, posso abrir o TMUX com o VIM de linha de comando, ou se eu quiser ficar no mundo híbrido gráfico posso usar os splits de Tilix com GVIM. Tanto faz, contanto que você tenha todos os atalhos e shortcuts pra ser produtivo. Na prática o jeito 100% é o melhor porque evita que você precisa ficar toda hora usando o mouse, e isso é uma das coisas que vai evitar que você tenha tendinite no futuro. Por isso quanto mais você aprender os shortcuts de TMUX e VIM, menos você vai precisar usar o mouse e isso sempre vai ser mais produtivo mesmo. Fora que as mesmas ferramentas que você usar na sua máquina de desenvolvimento, você também vai poder usar remotamente via SSH num servidor. E só de bônus, você pode compartilhar sessões de TMUX com outro usuário via SSH pra fazer pair programming remoto. Eu não vou mostrar aqui hoje mas você já sabe no GOOGLE você acha como.

Pra finalizar o vídeo de hoje, se você vai usar esse Linux que acabou de instalar como sua máquina primária, tem uma última coisa que você vai precisar fazer se quiser assistir vídeos online. Os codecs de H.264 ou mp3 e outros não são free software, então você precisa habilitar o que o Ubuntu chama de repositórios restritos. A forma de fazer isso é instalando o pacote ubuntu-restricted-extras pelo apt.

Esses repositórios são considerados restritos porque na instalação base vem tudo que é 100% código aberto. É parte da Filosofia do mundo de Software Livre que você deveria boicotar tudo que não tem código-aberto ou usa licenças que não são de software livre. E eles tem bons argumentos, porém, eu não sou ativista, eu prefiro ter o melhor dos dois mundos sempre. Minha produtividade nunca vai ser boa se eu tiver ideologias extremistas. Dou meus parabéns a quem vem lutando pra conseguir ter o máximo de código-aberto no mundo, mas no mundo real nem sempre isso é possível e eu prefiro não me restringir.

O Ubuntu vem por padrão com o Firefox e eu recomendo que você tente mesmo usar o Firefox como seu navegador primário, o mundo está sendo monopolizado pelo Google Chrome e mesmo navegadores como o novo Microsoft Edge, o Brave e o Opera usam a mesma engine do Chrome. Novamente, eu preferia que o mundo tivesse mais opções, mas na realidade se você é um programador web, vai precisar se certificar que sua aplicação tanto em Firefox quanto em Chrome, então você precisa instalar o próprio Chrome do Google ou a versão aberta que é o Chromium e pra instalar é via apt install chromium-browser.

Procure por Ubuntu 18 post-install e veja o que os outros fazem logo depois do primeiro boot. Você vai achar como instalar outros aplicativos úteis pra você como Spotify, Discord, Skype e muito mais.

E meu deus do céu, esse vídeo deu MUITO trabalho, mas eu precisava ter ele gravado pra poder referencias nos próximos vídeos, assim quando eu quiser mostrar a parte de programação de verdade ninguém vai poder dizer que não sabe o que é Docker, Postgres, ASDF, Vim e muito menos que não sabe como instalar, porque eu vou mandar sempre pra cá. Obviamente se você é iniciante deve ter ainda muitas dúvidas, então mandem nos comentários abaixo. Se tudo isso que eu falei você já sabia contribuem mandando mais dicas e ajudando a galera que tá começando agora nos comentários também. Se curtiram esse vídeo mandem um joinha, assinem o canal, e cliquem no sininho pra não perder os próximos episódios. Compartilhem o vídeo com seus amigos. A gente se vê semana que vem, até mais!

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!

Faz bastante tempo que uso o asdf como meu gerenciador principal de versões de Ruby, e estou confiante de que posso recomendá-lo no lugar dos mais conhecidos RVM ou Rbenv.

Além disso, ele não gerencia só Ruby — ele gerencia praticamente todas as linguagens que você precisar, com um único conjunto de comandos. Então nem precisa mais de virtualenv para Python ou NVM para Node.js. É só usar o ASDF.

A instalação não poderia ser mais simples. Basta seguir o README na página do projeto.

Não esqueça de instalar as ferramentas base de desenvolvimento para o seu ambiente. Você pode seguir a wiki do ruby-build como referência:

## Para OS X
# opcional, mas recomendado:
brew install openssl libyaml libffi

# obrigatório para compilar Ruby <= 1.9.3-p0:
brew tap homebrew/dupes && brew install apple-gcc42

## Para Ubuntu
sudo apt-get install gcc-6 autoconf bison build-essential libssl-dev libyaml-dev libreadline6-dev zlib1g-dev libncurses5-dev libffi-dev libgdbm3 libgdbm-dev

## Para Arch
sudo pacman -S --needed gcc5 base-devel libffi libyaml openssl zlib

Depois instale o próprio ASDF:

git clone https://github.com/asdf-vm/asdf.git ~/.asdf --branch v0.4.0

Então adicione a configuração de ambiente para o PATH e o autocomplete:

# Para Ubuntu ou outras distros Linux
echo -e '\n. $HOME/.asdf/asdf.sh' >> ~/.bashrc
echo -e '\n. $HOME/.asdf/completions/asdf.bash' >> ~/.bashrc

# OU para Mac OSX
echo -e '\n. $HOME/.asdf/asdf.sh' >> ~/.bash_profile
echo -e '\n. $HOME/.asdf/completions/asdf.bash' >> ~/.bash_profile

Por fim, você precisa instalar um dos dezenas de plugins disponíveis. No meu caso, tenho estes instalados:

asdf plugin-add clojure https://github.com/vic/asdf-clojure.git
asdf plugin-add elixir https://github.com/asdf-vm/asdf-elixir.git
asdf plugin-add erlang https://github.com/asdf-vm/asdf-erlang.git
asdf plugin-add golang https://github.com/kennyp/asdf-golang.git
asdf plugin-add python https://github.com/tuvistavie/asdf-python.git
asdf plugin-add ruby https://github.com/asdf-vm/asdf-ruby.git

# Importa as chaves OpenPGP do time de releases do Node.js para o keyring principal
bash ~/.asdf/plugins/nodejs/bin/import-release-team-keyring

asdf plugin-add nodejs https://github.com/asdf-vm/asdf-nodejs.git

Para atualizar todos os plugins de uma vez, basta rodar:

asdf plugin-update --all

Para ver as versões disponíveis de uma linguagem específica:

asdf list-all ruby
asdf list-all clojure
asdf list-all python

Para instalar qualquer versão que você precisar:

asdf install ruby 2.4.2
asdf install nodejs 8.7.0
asdf install erlang 20.1

Depois de instalar uma versão, costumo definir uma como padrão global do sistema:

asdf global ruby 2.4.2
asdf global elixir 1.5.2

E dentro de um diretório de projeto específico, posso definir outra versão, válida só para aquele projeto:

asdf local ruby 2.3.4

Esse comando grava um arquivo .tool-versions no diretório onde você está quando o executa. Ele contém a linguagem e a versão escolhidas, então sempre que você voltar para aquele diretório o ASDF vai configurar a versão correta automaticamente. O asdf global <linguagem> que mencionei antes faz a mesma coisa, só que grava o .tool-versions no seu diretório home. A configuração local sobrescreve a do home.

Outro ponto importante: sempre que você instalar bibliotecas que têm scripts executáveis que precisam estar no PATH, você deve fazer o reshim deles. Por exemplo:

npm install -g phantomjs # instala o phantomjs
asdf reshim nodejs # coloca o shim do executável phantomjs no PATH
phantomjs # executa corretamente

Se você tentar instalar versões de Ruby anteriores à 2.4, vai encontrar problemas de compilação, pois elas dependem do gcc5 e do openssl-1.0. Nesse caso, use o seguinte comando (assumindo que você já instalou o openssl-1.0 e o gcc5 obsoletos):

CC=gcc-5 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.4

Às vezes, quando uma dependência está faltando e a instalação falha, você precisa remover manualmente a versão antes de tentar reinstalar:

asdf remove <linguagem> <versão>

Por fim, se você costumava adicionar algo ao seu bash ou zsh para mostrar a versão atual da linguagem na linha de comando — provavelmente usando algo como rvm-prompt — no caso do ASDF você vai precisar de algo um pouco mais longo:

asdf current ruby | awk -F' ' '{print $1}'

Isso extrai só a versão (o comando asdf current mostra também qual arquivo .tool-versions está sendo usado, por isso o resultado é mais longo).

Fora isso, está tudo pronto. Um gerenciador de versões para governar todos. Sem RVM, sem Virtualenv, sem NVM. Pode viver feliz para sempre!

Sou usuário de Ubuntu há muito tempo. Sempre que preciso configurar uma máquina Linux, vou direto para a última LTS. É memória muscular, não tem jeito.

Mas para substituir o macOS, Unity é feio demais, sendo honesto. Tentei customizar o Cinnamon e quase gostei, e nem me fale de KDE ou XFCE.

O GNOME 3.22, por outro lado, é muito bem feito. Não preciso fuçar nada para deixar com boa aparência. O conjunto padrão de atalhos globais é exatamente o que um usuário antigo de macOS espera. Gosto de quase tudo nele.

Estava curioso com toda a movimentação em torno da transição do X.org para o Wayland e queria ver como estava.

A melhor distro que encontrei para isso é o bom e velho Fedora. RedHat (4) foi a segunda distro Linux que experimentei, logo depois do Slackware 1 lá em meados dos anos 90. Volto e saio de tempos em tempos. É uma boa hora de tentar de novo.

O resumo é que estou bem satisfeito com o Fedora 25. Ele faz praticamente tudo que preciso já de cara, sem configuração adicional.

Tirei da gaveta um desktop Lenovo ThinkCentre Edge 71z de 4 anos de idade e um notebook Lenovo IdeaPad G400s. São, respectivamente, um Core i5 SandyBridge de 2ª geração a 2,5GHz e um Core i3 a 2,4GHz, com 8GB de RAM no desktop e 4GB no notebook. Para a rotina de um desenvolvedor, são mais que suficientes. Um CPU mais potente não faria grande diferença.

Fiquei feliz ao ver que o desktop velho tem uma placa Intel antiga com saída DVI. Por sorte tinha um cabo DVI-to-HDMI por aí e consegui conectar ao meu monitor ultrawide LG 21:9 (2560x1080), que escalou tudo corretamente (o macOS Sierra tinha uma regressão que precisava de hack para funcionar!).

O que pesa mesmo são os HDs mecânicos super lentos (7200rpm e 5400rpm). Já pedi upgrade de RAM e 2 SSDs Crucial MX300 compatíveis. Quando chegarem, vou ter a agilidade que preciso.

Dito isso, o que fazer depois de uma instalação zerada do Fedora 25?

Para usuários de Ubuntu

Lembre disso: em vez de apt-get, você usa dnf. O Fedora antes da versão 22 usava yum, mas o dnf o substitui com basicamente as mesmas opções de comando.

Não existe equivalente ao apt-get update porque ele atualiza automaticamente. O resto é bem parecido: dnf install pacote em vez de apt-get install pacote, dnf search pacote em vez de apt-cache search pacote, e assim por diante. Para um upgrade global, use dnf upgrade em vez de apt-get update && apt-get upgrade.

Para serviços, em vez de sudo service restart memcached, use sudo systemctl restart memcached.

É basicamente isso. Leia essa página da wiki para mais diferenças de comandos.

Suporte à linguagem Crystal

Digamos que você queira aprender essa linguagem nova chamada “Crystal”: sintaxe e bibliotecas padrão familiares ao Ruby, mas com geração de binários nativos como no Go, primitivas de concorrência rápidas e todos os benefícios de um binário otimizado pelo LLVM.

Siga a wiki deles e também essa página, mas basicamente é isso:

sudo dnf -y install \
  gmp-devel \
  libbsd-devel \
  libedit-devel \
  libevent-devel \
  libxml2-devel \
  libyaml-devel \
  llvm-static \
  openssl-devel \
  readline-devel

sudo dnf -y install fedora-repos-rawhide
sudo dnf -y install gc gc-devel # get all dependencies from Fedora 25
sudo dnf -y install gc gc-devel --enablerepo=rawhide --best --allowerasing

sudo dnf -y install crystal

É isso, muitas dependências, mas como ainda é pré-1.0 acredito que vão melhorar isso no futuro.

Suporte a Ruby e Node.js

Rubyistas têm várias opções de gerenciador de versões, mas eu prefiro RVM. Primeiro, precisamos instalar alguns pré-requisitos:

sudo dnf -y install patch autoconf gcc-c++ patch libffi-devel automake libtool bison sqlite-devel ImageMagick-devel nodejs git gitg
curl -sSL https://rvm.io/mpapis.asc | gpg2 --import
curl -L https://get.rvm.io | bash -s stable --ruby

sudo npm -g install brunch phantomjs

Pronto, você terá o Ruby estável mais recente, Node, Npm e ferramentas úteis como Brunch (necessário para projetos Elixir-Phoenix) e PhantomJS para testes de aceitação automatizados em várias linguagens.

Note que já estamos instalando o Git e o opcional GitG, um companheiro fantástico para a sua rotina com Git.

Suporte a Postgresql, Redis, Memcached

O que é uma aplicação web sem banco de dados e serviços de cache? Vamos instalá-los:

sudo dnf -y install postgresql-server postgresql-contrib postgresql-devel memcached redis

sudo postgresql-setup --initdb
sudo sed -i.bak 's/ident/trust/' /var/lib/pgsql/data/pg_hba.conf # NUNCA faça isso em servidores de produção
sudo systemctl start postgresql

sudo su - postgres
createuser youruser -p
createdb youruser --owner=youruser

Substitua youruser pelo nome do seu usuário atual, claro.

Suporte a Java

Fácil, basta instalar o OpenJDK 8 mais recente e os plugins para o navegador:

sudo dnf -y install java-1.8.0-openjdk icedtea-web

Suporte a Go

Ainda mais simples:

sudo dnf -y install go

Não esqueça de editar seu perfil, como $HOME/.profile, e adicionar as variáveis de ambiente necessárias:

export GOROOT=$HOME/go
export PATH=$PATH:$GOROOT/bin

Suporte a Elixir

Tem o jeito fácil e um mais complicado e demorado. Vamos começar com o fácil:

sudo dnf -y install erlang elixir
mix local.hex
mix local.rebar
mix archive.install https://github.com/phoenixframework/archives/raw/master/phoenix_new.ez

O problema é que os pacotes para distros como Fedora demoram para ser atualizados. Por exemplo, o Elixir 1.4 foi lançado há alguns dias, mas ainda não há atualização para o Fedora.

Outro problema, se você desenvolve Elixir profissionalmente, é que vai precisar de um gerenciador de versões, porque vai acabar pegando projetos de clientes em versões diferentes e precisa configurar o ambiente adequadamente. É aí que entra o asdf. Você pode seguir este gist, mas vou colar os pontos importantes aqui:

sudo dnf -y install make automake gcc gcc-c++ kernel-devel git wget openssl-devel ncurses-devel wxBase3 wxGTK3-devel m4

git clone https://github.com/asdf-vm/asdf.git ~/.asdf --branch v0.2.1

# Para Ubuntu ou outras distros Linux
echo '. $HOME/.asdf/asdf.sh' >> ~/.bashrc
echo '. $HOME/.asdf/completions/asdf.bash' >> ~/.bashrc

# reinicie o terminal ou faça source do arquivo acima:
source ~/.bashrc

asdf plugin-add erlang https://github.com/asdf-vm/asdf-erlang.git
asdf plugin-add elixir https://github.com/asdf-vm/asdf-elixir.git

asdf install erlang 19.0
asdf install elixir 1.4.0

asdf global erlang 19.0
asdf global elixir 1.4.0

Compilar o Erlang a partir do código-fonte demora uma eternidade, especialmente com CPUs velhos como os meus. Mas é assim que você tem acesso ao Elixir mais recente e, ao mesmo tempo, a capacidade de usar versões antigas para projetos de clientes.

Por sinal, você pode instalar plugins adicionais do asdf para gerenciar outras plataformas como Go, Rust, Node, Julia e muitas outras. Veja a página do projeto para mais detalhes.

Suporte a Docker

Provavelmente você vai querer Docker também, então vamos lá:

sudo dnf -y install docker docker-compose

# você pode testar se funcionou com o famoso hello world
sudo docker run --rm hello-world

Aplicativos de Desktop

Com tudo instalado, vamos configurar os aspectos não-terminais para uma experiência melhor.

Terminator (e Terminix)

Falando em terminais, você vai querer instalar o Terminator. Não gosto de usar screen ou tmux na minha máquina local (não consigo me acostumar com os atalhos). Estou mais habituado ao iTerm2 do macOS, e o Terminator é praticamente a mesma coisa com atalhos similares. Você definitivamente precisa substituir o terminal padrão por ele.

sudo dnf -y install terminator

Você também vai querer editar ~/.config/terminator/config e adicionar o seguinte para melhorar a configuração:

[global_config]
  title_transmit_bg_color = "#d30102"
  focus = system
[keybindings]
[layouts]
  [[default]]
    [[[child1]]]
      parent = window0
      type = Terminal
      profile = default
    [[[window0]]]
      parent = ""
      type = Window
[plugins]
[profiles]
  [[default]]
    use_system_font = false
    font = Hack 12
    scrollback_lines = 2000
    palette = "#073642:#dc322f:#859900:#b58900:#268bd2:#d33682:#2aa198:#eee8d5:#586e75:#cb4b16:#586e75:#657b83:#839496:#6c71c4:#93a1a1:#fdf6e3"
    foreground_color = "#eee8d5"
    background_color = "#002b36"
    cursor_color = "#eee8d5"

Outra ótima opção que me recomendaram é o Terminix. Para instalar:

sudo dnf copr enable heikoada/terminix
sudo dnf -y install terminix

Fonte Hack

Você vai querer uma fonte melhor, como Hack:

dnf -y install dnf-plugins-core
dnf copr enable heliocastro/hack-fonts
dnf -y install hack-fonts

Gnome Tweak Tool

Instale o Gnome Tweak Tool para poder definir a Hack como fonte monoespaçada padrão:

sudo dnf -y install gnome-tweak-tool

Vim, Zsh, Yadr

Gosto muito de usar Vim, então instale assim:

sudo dnf -y install vim-enhanced vim-X11

E gosto de usar o YADR para customizar todos os aspectos do meu ZSH e Vim:

sh -c "`curl -fsSL https://raw.githubusercontent.com/skwp/dotfiles/master/install.sh `"

Recomendo ter Zsh, Vim e Ruby instalados antes de rodar o script acima. Depois de concluir, tive que ajustar as configurações um pouco:

sed 's/gtk2/gtk3' ~/.vim/settings/yadr-appearance.vim

Você vai querer ajustar esse arquivo também, para adicionar novas fontes como Hack. Atualmente estou mais no mood “gruvbox” do que “solarized” como tema do Vim.

GIMP Photoshop

Se você é desenvolvedor web, vai precisar editar algumas imagens de vez em quando. E se for como eu, o Gimp é um pesadelo de usabilidade. Mas existem maneiras de torná-lo um pouco mais palatável.

sudo dnf -y install gimp
sh -c "$(curl -fsSL https://raw.githubusercontent.com/doctormo/GimpPs/master/tools/install.sh)"

Pronto, um tema parecido com Photoshop para o Gimp deixar menos feio.

Spotify

O que seria de nós, desenvolvedores, sem música para concentrar?

dnf config-manager --add-repo=http://negativo17.org/repos/fedora-spotify.repo
dnf -y install spotify-client

CoreBird

Fico feliz que alguém construiu um cliente de Twitter muito competente e elegante para Linux. Instale o CoreBird:

dnf -y install corebird

Provavelmente é até melhor que a versão oficial para Mac.

Ajustando a barra de título

Encontrei esse hack para deixar as barras de título do Gnome um pouco menos gordas, que é praticamente a única reclamação que tenho sobre o visual até agora:

tee ~/.config/gtk-3.0/gtk.css <<-EOF
.header-bar.default-decoration {
 padding-top: 3px;
 padding-bottom: 3px;
 font-size: 0.8em;
}

.header-bar.default-decoration .button.titlebutton {
 padding: 0px;
}
EOF

Conclusão

A maioria das coisas que você precisa é web, então Gmail, Slack, tudo funciona bem. Abra o Chromium, Firefox ou instale o Franz ou WMail se precisar. Infelizmente tudo que é web consome muita RAM, o que é um problema sério. Sinto falta dos bons e velhos aplicativos nativos, leves e rápidos. Aplicativos web são um porre.

Eles “funcionam”, mas prefiro um bom aplicativo nativo. Por outro lado, Dropbox e Skype têm clientes terríveis. São muito mal mantidos, cheios de bugs e com suporte péssimo. Prefiro não usá-los.

Estava tentando me acostumar com o Thunderbird no Ubuntu. O Geary ainda não é bom o suficiente. Mas fiquei surpreso ao tentar o Evolution de novo. Ele tem a única coisa que realmente quero de qualquer cliente de email: um atalho para mover emails para pastas: Ctrl-Shift-V (!!) Será que é tão difícil assim??

O Gnome 3 tem um repositório global de Contas Online nas Configurações onde você pode cadastrar redes sociais como Facebook e Google, mas o suporte ao Google está bugado. Expira toda hora, então não use o Evolution com ele. Adicione as informações de Imap/Smtp manualmente. Email e dados do Calendar sincronizam corretamente dessa forma.

Você já deve ter todas as suas senhas em uma conta LastPass. O Authy é uma extensão do Chrome, então sua autenticação de múltiplos fatores também deve funcionar.

Meu banco e corretoras, com seus feios applets Java, funcionam bem com Chromium e IcedTea, então estou ok por aí.

Só preciso descobrir a estratégia de backup mais fácil para ter tudo realmente seguro. Na instalação, não esqueça de escolher a opção de partição criptografada - e se fizer isso, faça backup dos dados regularmente, pois ouvi relatos de bugs em upgrades que tornaram as partições criptografadas inacessíveis. Seja seguro e cuidadoso.

Como sempre, do macOS as únicas 2 coisas que vou realmente sentir falta são o Apple Keynote (é incrível, ninguém conseguiu fazer uma ferramenta de apresentação tão elegante e rápida) e o iMovie para edição rápida de vídeo (embora o Kdenlive seja uma alternativa bem boa).

Você ainda tem atalhos embutidos para capturar uma janela ou área e gravar um screencast!

Comparado à minha configuração no Ubuntu, esse Fedora 25 é realmente um prazer de usar. Uma boa alternativa ao macOS. Recomendo!

E como disse na atualização no início do post: dê uma olhada no Arch Linux e em como otimizar sua distro para ser mais responsiva, especialmente em hardware antigo.

Gosto de manter uma box Vagrant por perto, porque por mais bagunçado que um upgrade de sistema operacional possa ser (olhando pra você, macOS), sei que minha máquina de desenvolvimento vai simplesmente funcionar.

Mas mesmo com tudo virtualizado e isolado, coisas ainda podem dar errado. Atualmente estou usando Vagrant 1.8.5, com o plugin vagrant-vmware-fusion 4.0.11 e Vmware Fusion 8.5 no El Capitan (mesmo com o macOS Sierra tendo acabado de ser lançado, vou esperar pelo menos 1 mês antes de atualizar, nada ali vale o risco).

Se você está instalando uma box novinha pela primeira vez, essa é a configuração mínima do Vagrantfile que eu uso:

# -*- mode: ruby -*-
# vi: set ft=ruby :

Vagrant.configure(2) do |config|
  config.vm.box = "bento/ubuntu-16.04"

  config.vm.network :forwarded_port, guest: 8080, host: 8080
  config.vm.network :forwarded_port, guest: 3000, host: 3000
  config.vm.network :forwarded_port, guest: 3001, host: 3001
  config.vm.network :forwarded_port, guest: 4000, host: 4000
  config.vm.network :forwarded_port, guest: 5555, host: 5555
  config.vm.network :forwarded_port, guest: 5556, host: 5556
  config.vm.network :forwarded_port, guest: 3808, host: 3808

  config.vm.network "private_network", ip: "192.168.0.100"

  config.vm.synced_folder "/Users/akitaonrails/Sites", "/vagrant", nfs: true

  config.vm.provider :vmware_fusion do |v|
    v.vmx["memsize"] = "2048"
  end
end

Normalmente entro nas configurações do Vmware da máquina virtual e habilito um processador extra (já que meu Macbook tem 8 núcleos virtuais pra compartilhar) e habilito o hypervisor (suporte ao VT-x/EPT da Intel).

Como regra geral, a primeira coisa que sempre faço é configurar o locale para en_US.UTF-8:

sudo locale-gen "en_US.UTF-8"
sudo dpkg-reconfigure locales
sudo update-locale LC_ALL=en_US.UTF-8 LANG=en_US.UTF-8

E, só pra garantir, adicione o seguinte ao /etc/environment:

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

Você precisa configurar o UTF-8 antes de instalar pacotes como o Postgresql.

Depois eu atualizo os pacotes e instalo o básico:

sudo apt-get update && sudo apt-get upgrade
sudo apt-get install open-vm-tools build-essential libssl-dev exuberant-ctags ncurses-term ack-grep silversearcher-ag fontconfig imagemagick libmagickwand-dev python-software-properties redis-server libhiredis-dev memcached libmemcached-dev

Isso vai instalar ferramentas importantes como Imagemagick, Memcached e Redis pra gente.

Agora, para instalar o Postgresql:

sudo apt-get install postgresql-9.5 postgresql-contrib postgresql-server-dev-9.5

Crie o superusuário para o vagrant:

sudo -i -u postgres
createuser --interactive

Enter name of role to add: vagrant
Shall the new role be a superuser? (y/n) y

E apenas para o ambiente de desenvolvimento edite o /etc/postgresql/9.5/main/pg_hba.conf e altere o seguinte:

# "local" is for Unix domain socket connections only
local   all             all                                     trust
# IPv4 local connections:
host    all             all             127.0.0.1/32            trust
# IPv6 local connections:
host    all             all             ::1/128                 trust

Isso deixa sua vida mais fácil na hora de programar. Se você fez tudo certo até aqui, terá seu PG com encoding unicode adequado e sem incomodar com senha quando rodar bin/rails db:create. Se não configurou o locale direito antes, pode seguir este gist para setar o locale do PG manualmente para UTF-8.

Instalar Ruby ainda é melhor via RVM:

gpg --keyserver hkp://keys.gnupg.net --recv-keys 409B6B1796C275462A1703113804BB82D39DC0E3
\curl -sSL https://get.rvm.io | bash
source $HOME/.rvm/scripts/rvm
rvm install 2.3.1
rvm use 2.3.1 --default

E eu prefiro usar o YADR como meus dotfiles padrão, trocando o Bash pelo ZSH. Comparado com outros dotfiles, gosto desse porque normalmente não preciso mexer em nada, ponto. Nem vou configurar nada de RVM depois da instalação porque o YADR já cuida disso.

sh -c "`curl -fsSL https://raw.githubusercontent.com/skwp/dotfiles/master/install.sh `"

Para atualizar (ou retomar caso quebre por algum motivo):

cd .yadr
rake update

Os únicos 2 ajustes que tenho que fazer são mudar meu perfil do iTerm2 para usar Solarized, e adicionar as 2 linhas a seguir no topo do arquivo .vimrc:

scriptencoding utf-8
set encoding=utf-8

Próximo passo, instalar o NodeJS:

curl -sL https://deb.nodesource.com/setup_6.x | sudo -E bash -
sudo apt-get install nodejs

Próximo passo, instalar o Java. Você pode escolher o instalador da Oracle, mas acredito que o openjdk deva ser suficiente:

sudo apt-get install default-jdk

Vamos precisar do Java para o Elasticsearch 2.4.0:

wget https://download.elastic.co/elasticsearch/release/org/elasticsearch/distribution/deb/elasticsearch/2.4.0/elasticsearch-2.4.0.deb && sudo dpkg -i elasticsearch-2.4.0.deb

Agora você pode iniciá-lo manualmente com sudo /etc/init.d/elasticsearch start, e é melhor deixar assim porque ele consome bastante RAM, então só inicie quando realmente precisar.

Com o Java no lugar, também podemos instalar o Leiningen para ter o Clojure pronto.

echo "PATH=$PATH:~/bin" >> ~/.zsh.after/bin.zsh
mkdir ~/bin && cd ~/bin
wget https://raw.githubusercontent.com/technomancy/leiningen/stable/bin/lein
chmod a+x lein
lein

O Leiningen vai instalar suas dependências e você pode seguir o tutorial dele para começar.

Instalar Rust é igualmente fácil:

curl -sSf https://static.rust-lang.org/rustup.sh | sh

Instalar Crystal, também fácil:

curl https://dist.crystal-lang.org/apt/setup.sh | sudo bash
sudo apt-get install crystal

Instalar Go até dá, mas é mais manual:

wget https://storage.googleapis.com/golang/go1.7.1.linux-amd64.tar.gz
tar xvfz go1.7.1.linux-amd64.tar.gz
chown -R root:root .go
sudo mv go /usr/local
touch ~/.zsh.after/go.zsh
echo "export GOPATH=$HOME/go" >> ~/.zsh.after/go.zsh
echo "export PATH=$PATH:/usr/local/go/bin:$GOPATH/bin" >> ~/.zsh.after/go.zsh

Assim que instalar o go e configurar o work path dele, podemos instalar algumas ferramentas úteis como o forego e o goon (que o Hex do Elixir pode usar opcionalmente):

go get -u github.com/ddollar/forego
go get -u github.com/alco/goon

E falando em Elixir, deixamos o melhor pro final:

wget https://packages.erlang-solutions.com/erlang-solutions_1.0_all.deb && sudo dpkg -i erlang-solutions_1.0_all.deb
sudo apt-get update
sudo apt-get install esl-erlang elixir

E é isso, um tutorial bem direto para ter um ambiente de desenvolvimento moderno pronto pra usar. Essas são as ferramentas básicas de desenvolvimento de software que acredito que deveriam estar no cinto de utilidades de todo mundo nos próximos anos.

Honestamente, não mexo tanto com Clojure e Go quanto acho que deveria. E ainda não dei muito tempo pro .NET Core, mas vou explorar esses em mais detalhes no futuro.

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.