- O VPS da DigitalOcean baseado em Ubuntu 16.04 LTS estava fora de suporte e trazia riscos de segurança, mas manteve 1491 dias de uptime até o fim
- O novo servidor foi migrado para um VPS da Hetzner na Alemanha com FreeBSD 14.3, oferecendo especificações melhores que o antigo servidor de US$ 13/mês por menos de 6 euros por mês
- Com Jails e Bastille, foi criado um ambiente isolado por site, em que o Jail do Caddy cuida de SSL e do proxy reverso, encaminhando para cada Jail com nginx
- Em testes de carga, o novo servidor FreeBSD apresentou de 3 a 11 vezes mais throughput após ajustar
kern.ipc.somaxconn para suportar 10.000 conexões simultâneas
- A migração exigiu aprendizado sobre rede e configuração do FreeBSD, mas acabou sendo mais fácil do que o esperado graças à configuração centralizada e à qualidade da documentação
Contexto da migração
- O blog anterior foi operado por mais de 10 anos em um VPS da DigitalOcean, usando Ubuntu 16.04 LTS no datacenter de Nova York
- O Ubuntu 16.04 LTS já estava sem suporte havia pelo menos 5 anos, e não era mais possível receber atualizações dos repositórios do
apt
- Um sistema antigo é desfavorável do ponto de vista de segurança, e no passado um blog WordPress separado sofreu um ataque em um VPS antigo que inseriu links de cassino e apostas
- Além do blog, o servidor antigo também hospedava alguns outros sites, mas a maioria era de sites estáticos
- Mesmo o blog mais popular normalmente ficava na casa de alguns milhares de pageviews por mês, e fora alguns posts que viralizaram no Hacker News, o tráfego não era alto
- O servidor entregava arquivos estáticos com
nginx/1.10.3, e as configurações por site ficavam em /etc/nginx/sites-available
- O blog era gerado com Hugo, e o processo antigo de deploy era: escrever localmente → commit e push no repositório → entrar via SSH no servidor → dar pull no repositório → executar
hugo
- O VPS antigo também havia sido usado no começo para testes e programação, então ainda carregava bastante software antigo
- Mesmo assim, seguia funcionando normalmente, e o uptime no encerramento foi de 1491 dias, ou seja, cerca de 4 anos sem reinicialização
- O novo servidor foi migrado para um VPS da Hetzner na Alemanha, com especificações superiores e custo mensal inferior à metade do anterior
- O servidor antigo da DigitalOcean tinha 2 GB de RAM, 1 vCPU, 50 GB de disco, 2 TB de tráfego mensal e custava US$ 13 por mês
- Até o servidor mais barato da Hetzner já oferecia o dobro de memória e CPU do antigo, um pouco menos de armazenamento, mas 10 vezes mais tráfego
- A configuração da Hetzner escolhida no fim oferecia especificações ainda mais fortes por menos de 6 euros por mês
Por que escolher o FreeBSD
- O FreeBSD foi escolhido para experimentar um sistema novo em um ambiente de produção real
- Seus pontos fortes incluem design integrado, estabilidade, segurança e Jails
- Jails é um recurso de virtualização e conteinerização presente no FreeBSD há mais de 25 anos
- Ele permite executar “mini-sistemas” em sandbox, sem acesso ao sistema host
- Enquanto soluções de contêiner como Docker são mais adequadas para empacotar programas e tendem a ser temporárias e imutáveis, Jails se aproximam mais de subsistemas ou mini-VMs que compartilham o mesmo kernel
- O ZFS também era uma opção atraente como sistema de arquivos para servidor
- Ele oferece integridade de dados e snapshots, e tem semelhanças com o Btrfs no Linux
- O ZFS foi considerado muito mais maduro que o Btrfs, e snapshots frequentes poderiam reduzir a dependência do sistema pago de snapshots e backup do provedor do VPS
- A estrutura desejada era usar um Jail por site, colocando dentro de cada um as ferramentas de build necessárias e o nginx
- Um Jail principal para o servidor web ficaria responsável pelo proxy reverso conectado ao exterior
- A intenção era que, se um Jail específico fosse comprometido, ele pudesse ser apagado e recriado
Instalação do FreeBSD e adoção do Bastille
- Na tela de criação de VM da Hetzner, as imagens de sistema operacional padrão eram limitadas e o BSD não aparecia de imediato
- O Bastille foi escolhido para facilitar o gerenciamento dos Jails
- Várias etapas necessárias para criar Jails manualmente podem ser feitas com o comando
bastille
- Exemplos de comandos:
bastille list, bastille create, bastille console
- A instalação e a ativação seguiram a documentação introdutória do Bastille
pkg install bastille
sysrc bastille_enable="YES"
Rede e estrutura de proxy reverso
- A pilha inteira foi montada de forma que um único Jail do Caddy processasse todos os domínios e certificados SSL, fazendo proxy reverso do tráfego para os Jails de cada site
- Cada Jail de site contém apenas as ferramentas necessárias para buildar e servir o respectivo site
- A estrutura pode ser vista como algo parecido com várias máquinas virtuais dentro da mesma rede
- A interface de rede virtual interna foi criada como
bastille0
sudo sysrc cloned_interfaces+="lo1"
sudo sysrc ifconfig_lo1_name="bastille0"
sudo service netif cloneup
sudo sysrc ifconfig_bastille0="inet 10.0.0.1 netmask 255.255.255.0"
- A interface loopback foi clonada, recebeu o nome
bastille0 e foi atribuída à rede 10.0.0.1/24
- Os Jails operam nessa interface de rede
- Requisições HTTP e HTTPS externas são encaminhadas ao Jail do Caddy por regras do PF(Packet Filter)
- Em
/etc/pf.conf, foram definidos a interface externa vtnet0, a interface interna bastille0 e tailscale1
- O tráfego nas portas
80 e 443 é redirecionado para 10.0.0.5, que será o servidor Caddy
ext_if = "vtnet0"
int_if = "bastille0"
vpn_if = "tailscale1"
set skip on $int_if
set skip on $vpn_if
nat on $ext_if from 10.0.0.0/24 to any -> ($ext_if)
rdr pass on $ext_if proto tcp from any to any port {80, 443} -> 10.0.0.5
block all
pass out quick on $ext_if keep state
- O PF e o gateway foram ativados com os seguintes comandos
sysrc pf_enable="YES"
service pf start
sysrc gateway_enable="YES"
Configuração do Caddy e dos Jails por site
- O servidor antigo usava nginx havia muito tempo, mas na nova configuração foi escolhido o Caddy para automatizar o gerenciamento de certificados SSL
- No ambiente antigo com nginx, era preciso renovar periodicamente os certificados com
certbot, e isso foi esquecido várias vezes
- Antes de criar o Jail do Caddy, foi feito o bootstrap da release do FreeBSD no Bastille
bastille bootstrap 14.3-RELEASE
- O Jail do Caddy foi criado com o IP
10.0.0.5
bastille create caddy 14.3-RELEASE 10.0.0.5 bastille0
bastille start caddy
- O nome do Jail é
caddy, a release é 14.3-RELEASE e a interface é bastille0
- É possível verificar o estado com
bastille list e entrar no shell do Jail com bastille console caddy
- A instalação do Caddy e a ativação do serviço foram feitas dentro do Jail
pkg install caddy
sysrc caddy_enable="YES"
service caddy start
- O arquivo de configuração do Caddy fica em
/usr/local/etc/caddy/Caddyfile dentro do Jail
- Para gerenciar o arquivo a partir do host, é possível montar um diretório do host para dentro do Jail
- No exemplo, ele foi montado com
nullfs e a opção somente leitura ro, para impedir que o Caddy altere a configuração
bastille mount caddy /usr/local/etc/my-caddy-config /usr/local/etc/caddy nullfs ro 0 0
Deploy dos sites e do blog
- O primeiro alvo de deploy foi
es.cro.to, cujo site é gerenciado neste repositório do GitHub
- O repositório foi colocado em
/usr/local/www/escroto no host, e esse diretório foi montado como somente leitura no Jail do site
- Todos os sites foram organizados sob
/usr/local/www no host
- O Jail
escroto foi criado com o template nginx do Bastille
bastille bootstrap https://github.com/bastillebsd/templates
bastille create escroto 14.3-RELEASE 10.0.0.11 bastille0
bastille template escroto www/nginx
- O IP definido foi
10.0.0.11
- A página padrão do nginx é servida a partir de
/usr/local/www/nginx, como é costume no FreeBSD
- O diretório do site no host foi montado como somente leitura no Jail
bastille mount escroto /usr/local/www/escroto /usr/local/www/escroto nullfs ro 0 0
- Um script de deploy foi usado para impedir que o diretório
.git do repositório fosse servido pela web
rm -fr /usr/local/www/nginx/*
cp -R /usr/local/www/escroto/* /usr/local/www/nginx/
rm -fr /usr/local/www/nginx/.git
- O deploy de uma nova versão funciona atualizando o repositório no host e depois executando o script de deploy dentro do Jail
cd /usr/local/www/escroto
git pull
bastille cmd escroto /root/deploy.sh
- A configuração do Caddy redireciona permanentemente
cro.to para es.cro.to e faz proxy de es.cro.to para 10.0.0.11
cro.to {
redir https://es.cro.to{uri} permanent
}
es.cro.to {
reverse_proxy 10.0.0.11
}
- O blog usa Hugo e é gerenciado neste repositório do GitHub
- O repositório foi clonado em
/usr/local/www/blog no host
- O Jail
blog foi criado de forma parecida com o escroto, com IP 10.0.0.12
bastille create blog 14.3-RELEASE 10.0.0.12 bastille0
bastille template blog www/nginx
bastille mount blog /usr/local/www/blog /usr/local/www/blog nullfs ro 0 0
- O Hugo foi instalado dentro do Jail
blog
bastille pkg blog update
bastille pkg blog install gohugo
- O script de deploy do blog limpa a web root do nginx e gera a saída do Hugo em
/usr/local/www/nginx
rm -fr /usr/local/www/nginx/*
cd /usr/local/www/blog
hugo -d /usr/local/www/nginx
- Antes de migrar o DNS, foi usado
crocidb.cro.to apontando para o novo servidor do blog para testar em vez do domínio antigo
crocidb.cro.to {
reverse_proxy 10.0.0.12
}
Benchmarks e testes de carga
- Antes de alterar os registros DNS, foi feita uma comparação entre a capacidade de carga do servidor antigo
crocidb.com e do novo crocidb.cro.to
- Como os visitantes do blog vêm principalmente da América do Norte, seguidos por Europa e América do Sul, o novo servidor na Alemanha poderia aumentar um pouco a latência para alguns usuários
- O principal interesse era a velocidade para servir um site estático e a capacidade de aguentar carga alta
- Também foram usadas ferramentas online gratuitas como GTMetrix, Pingdom e WebPageTest, mas a diferença entre os dois servidores foi basicamente a latência
- Como ferramentas de benchmark HTTP, foram usados wrk e hey
- As duas ferramentas geram grande volume de requisições simultâneas e coletam latência, respostas de erro, vazão por segundo e outros dados
- Ao executar
wrk de outro VPS da mesma Hetzner, o novo servidor teve desempenho muito superior
wrk -t4 -c100 -d30s --latency https://crocidb.com/
- As opções eram 4 threads, 100 conexões simultâneas e 30 segundos de execução
- O servidor antigo teve latência média de
89.63ms, 833.41 requisições por segundo e vazão de 8.29MB/s
- O novo servidor teve latência média de
6.75ms, 12260.10 requisições por segundo e vazão de 130.80MB/s
- A comparação não era totalmente justa, porque a máquina de teste estava no mesmo datacenter do novo servidor
- Também foi tentado executar
wrk de várias regiões usando o Proton VPN, mas os resultados ficaram abaixo do esperado
- A média do servidor antigo ficou em cerca de
300 requisições por segundo, enquanto a do novo ficou em cerca de 800
- No fim, em vez de usar VPN para consumidores, a abordagem mudou para criar VPSs reais em várias regiões
Testes por região com VPSs da Vultr
- A Vultr foi escolhida para usar uma infraestrutura diferente da DigitalOcean e da Hetzner, onde os servidores estavam hospedados
- Por causa do trabalho manual, as regiões foram limitadas a London, São Paulo, Silicon Valley e Tokyo
- Em cada região, foi criada a VM Fedora mais barata para executar os testes
- No fim, concluiu-se que o
hey era a ferramenta mais adequada
./hey_linux_amd64 -n 1000000 -c 10000 -t 10 -z 5m -h2 https://crocidb.com/ > crocidb.com.log
./hey_linux_amd64 -n 1000000 -c 10000 -t 10 -z 5m -h2 https://crocidb.cro.to/ > crocidb.cro.to.log
- A configuração era de
1.000.000 requisições totais, 10.000 requisições simultâneas, timeout de 10 segundos, duração total de 5 minutos e uso de HTTP/2
- Era uma carga muito maior do que o tráfego realista do blog
- Na primeira execução, o novo servidor FreeBSD não conseguiu suportar 10.000 conexões simultâneas e falhou logo no começo
- Ao verificar o tamanho da fila de sockets com
netstat -Lan, todos apareciam como 128
- Como o valor padrão de
kern.ipc.somaxconn era 128, ele foi aumentado assim
sysctl kern.ipc.somaxconn=16384
- No teste de São Paulo, os dois servidores retornaram muitos erros, mas o servidor FreeBSD respondeu à meta esperada de
1.000.000 requisições, enquanto o Ubuntu não conseguiu retornar nem 20.000
- O servidor Ubuntu antigo completou apenas cerca de
7% do total de requisições
- O novo servidor FreeBSD completou cerca de
94%
- Em Tokyo, a taxa de sucesso do novo servidor foi um pouco menor, mas não a ponto de gerar grande preocupação
- Em requisições por segundo, o novo servidor foi de no mínimo 3 vezes a no máximo 11 vezes melhor que o antigo
- Nos percentis de latência, o novo servidor aumentou de forma mais linear até cerca de
90%, o que deu maior previsibilidade
- Mesmo sob alta carga, o resultado indicou que o conteúdo da página inicial do blog podia ser recebido em menos de 3,5 segundos na maior parte das regiões do mundo
- O resultado de Tokyo não foi analisado em profundidade
- A análise por etapas do
hey sugeriu a possibilidade de tráfego mais lento para o Japão
- Os valores de DNS dial-up e lookup do segundo domínio pareciam anormalmente baixos, possivelmente por efeito do registro CNAME
- Os valores de
resp wait e resp read também estavam estranhamente altos, e como só as requisições bem-sucedidas foram contabilizadas, é possível que o servidor antigo tenha respondido rapidamente no início e depois praticamente bloqueado novas requisições
Migração final e principais lições
- Embora os benchmarks tenham deixado várias perguntas em aberto, o resultado foi considerado satisfatório e os registros DNS foram apontados para o novo servidor
- Desde então, este blog passou oficialmente a rodar no servidor Hetzner com FreeBSD
- Montar uma máquina de hospedagem de sites com FreeBSD exigiu várias horas de testes, ajustes, builds e falhas, mas não foi tão complexo quanto o esperado
- Também seria possível usar um serviço de hospedagem que atendesse aos requisitos, como o OpenBSD Amsterdam
- Outra opção seria usar Proxmox para contêineres e um dashboard de administração
- Como alternativa no ecossistema FreeBSD, também foi citado o Sylve
- O caminho de montar tudo manualmente trouxe muito aprendizado, por isso foi considerado uma escolha satisfatória
- O antigo servidor Ubuntu também foi muito sólido
- Durante 10 anos, ele lidou bem com a carga dos sites e, nos últimos 4 anos, operou sem reboot
- Funcionou de forma estável sem exigir grande esforço de configuração
- A configuração do FreeBSD foi mais fácil do que o esperado, e o modelo de centralizar as configurações em um só lugar, junto da boa qualidade da documentação online, ajudou bastante
- Para montar pessoalmente uma máquina de hospedagem de blog, foi preciso ter conhecimento de rede além do que um desenvolvedor de jogos normalmente conhece
- O processo de aprender outro sistema foi divertido, e no futuro talvez haja uma tentativa com OpenBSD ou NetBSD
- A conclusão final é que a utilidade prática de todo esse trabalho é limitada, já que a maior parte do tráfego do blog vem de crawlers de sistemas de IA
1 comentários
Comentários do Hacker News
O maior erro que cometi foi ter alto tempo de atividade
Como o arjie.com ficou no ar por mais de 10 anos em uma VPS da Hetzner, quando a Hetzner tentou desativar a máquina subjacente eu não fazia ideia do que o meu eu adolescente tinha configurado
Eu tinha backup, mas o site está fora do ar há 10 anos
Hoje em dia eu monto tudo para poder migrar e de fato migro algumas vezes para verificar se funciona
Também lembro da época em que uptime de máquina era visto como um distintivo de honra
Fiquei mais velho, não necessariamente mais sábio, mas hoje olho para o tempo de atividade do serviço
Antigamente registros DNS como MX já iam mais nessa direção, e clusters antigos eram bem obscuros, mas lições como split brain ficaram e até hoje continuo explicando por que clusters Proxmox de 2 nós quebram e por que recomendam adicionar um witness
A forma como a VMware antigamente encobriu o problema de clusters HA de 2 nós com uma grande gambiarra também estava errada, e se esse método ainda existe provavelmente continua errado
Alto uptime significa que você não aplicou patches, e patch é algo que todo mundo adora fazer
A cada 20 anos ele é completamente desmontado e reconstruído, e no Breakneck, de Dan Wang, que li recentemente, isso é explicado como uma prática de reconstrução que preserva conhecimentos que desapareceriam com o tempo
Wang contrapõe o Santuário de Ise a Notre Dame, e acha que uma das razões pelas quais a reconstrução do telhado de Notre Dame foi tão difícil pode ter sido a perda de conhecimento
Não conheço bem o bastante as duas construções para dizer se é uma comparação justa, mas gosto do princípio em si
No livro é só uma pequena analogia, e no geral recomendo fortemente
Reiniciar leva só alguns segundos, e upgrades podem ser feitos sem downtime apenas apontando o DNS para uma nova instância
Já em máquinas físicas que não são fáceis de replicar, a história é outra
Não precisa ser tudo totalmente gerenciado por Ansible; deixo ali principalmente a configuração inicial e ainda faço muita coisa manualmente
Parece um pouco ridículo, mas ajuda com mais frequência do que eu imaginava
Para uso pessoal/hobby, no geral opero com a combinação Caddy na frente + Docker Compose
Se for um site simples, o Caddy serve o conteúdo diretamente; se for um “web app”, quase sempre containerizo tudo e deixo o Caddy cuidar do término de TLS e do proxy reverso para o app rodando no Docker
Normalmente uso uma estrutura
~/apps/appname, com o arquivo do Docker Compose e o diretório de dados montado dentro do diretório de cada appDepois de
compose down, dá para puxar os dados por (s)ftp para arquivamento de longo prazo ou para migrar o site/serviçoEu já rodei vários VMs em servidor dedicado, mas migrei para VPSs separadas da OVH, e se quiser rodar e-mail na OVH é melhor evitar as VMs da zona local que não permitem hospedagem de e-mail
Dependendo do ambiente, isso pode variar
O NPM também é excelente e a GUI web é boa, mas no Traefik basta escrever no arquivo do Docker Compose o comportamento desejado e pronto
Só que o Unraid roda os contêineres, e um deles é uma ferramenta da família nginx projetada para servir de proxy reverso para os outros serviços
Só estou pensando em sair do Debian para algo mais no estilo Flatcar, com foco em contêineres e sistema/OS imutável
O FreeBSD tem vantagens técnicas interessantes, mas goste ou não, o padrão de muito software open source é Docker, e eu não tenho tempo nem disposição para mover tudo para jails do FreeBSD
Fiz exatamente isso algumas semanas atrás
O servidor não era atualizado desde algo como 2015, e tinha um blog Ghost daquela época com
node 0.10instaladoEu fui por um caminho mais bruto: só fiz backup e soltei um agente Hermes (Gemini 3.1 Pro) em cima
Ele fez todos os upgrades e patches necessários e ainda migrou para o equivalente atual
Depois também avancei bastante no endurecimento do servidor e na remoção de serviços não usados, e sem assistência de IA eu provavelmente teria adiado isso por mais tempo
O problema de verdade é o risco de quebrar alguma coisa, e é aí que o backup ajuda
Eu gostava de usar FreeBSD em servidor pessoal
Tinha algo de legal, limpo, simples e meio “punk rock”
Mas acabei desistindo por alguns pontos de dor principais: o PM2 tinha bugs no FreeBSD e era a ferramenta que eu usava para gerenciar processos; como alternativa tentei rodar daemons com
rc.d, mas configurar logs era complicado demais; e no firewall havia coisa demais para ajustar manualmente se eu quisesse seguir boas práticas de segurança, inclusive como lidar com ICMP, e eu sentia falta de algo com defaults prontos como o UFWEles são implementados com IPFW, não com PF
Basta olhar a chave
firewall_typenorc.conf: https://cgit.freebsd.org/src/tree/libexec/rc/rc.conf?id=8e08...Para configurar facilmente um firewall de máquina única, use
firewall_type=client; se for hospedar algo, usefirewall_type=workstationNeste último caso,
firewall_myservicesefirewall_allowservicescontrolam quais portas ficam abertas e quais redes/IPs podem acessá-lasPara um gateway NAT bem simples, use
firewall_type=simplejunto comfirewall_simple_(iif|inet|oif|onet)(_ipv6)?para definir os nomes das interfaces do lado do ISP/interno e os intervalos de rede IPv4/IPv6O comportamento exato de cada opção está implementado em
/etc/rc.firewall: https://cgit.freebsd.org/src/tree/libexec/rc/rc.firewall?id=...Os logs de daemons em
rc.dpodem seguir o jeito Unix: para mensagens simples uselogger(1), ou redirecione para arquivos e gerencie o tamanho comnewsyslog(8)Para firewall, recomendo The Book of PF[0]
O PF do FreeBSD tem diferenças de sintaxe em relação ao pf do OpenBSD, mas é suficiente para pegar a lógica de como firewalls funcionam e entender que regras você precisa escrever
[0]: https://nostarch.com/book-of-pf-4e
No começo parece super prático, mas ao mesmo tempo sempre foi um software desagradável de usar, e em deploy atualização de variáveis de ambiente nunca funcionou como eu queria
Se faltasse luz, depois do reboot ele exigia
fsckmanual no sistema de arquivosMudando um pouco de assunto, fico curioso para saber qual distribuição Linux gratuita tem hoje o ciclo de suporte mais longo
Por um bom tempo usei CentOS 7 em VMs pequenas, porque recebia atualizações de segurança por muito tempo e o risco de alguma atualização quebrar algo era mínimo
Pelo que pesquisei rapidamente, hoje Alma/Rocky Linux parecem ser a melhor escolha, com 10 anos de suporte
Só não sei como está a manutenção delas
Mas depois de um período tão longo o ecossistema se descola bastante, e fica cada vez mais difícil manter os aplicativos atualizados em cima desse SO
Pacotes de infraestrutura como
glibc, combinações Python/Apache e GCC vão aos poucos ficando incompatíveis com stacks de aplicação atuaisDepois, os upgrades de versão também foram dolorosos, não só porque eu mesmo me encurralei com misturas estranhas de pacotes, mas porque o caminho de upgrade em si sempre foi mais ou menos “best effort”
Acho que desisti na transição do 6 para o 7, e no fim percebi que o que eu precisava era Fedora
Com atualização anual ou semestral, eu não preciso brigar com os pacotes da distro, a configuração se mantém atual e funcional, upgrades grandes da distro são suaves e o downtime é mínimo
Não pretendo voltar nunca mais para uma “distro de servidor”
Por exemplo, pode liberar mais rápido um update de kernel que corrige uma vulnerabilidade de escalonamento de privilégios
A Rocky respondeu com um repositório de segurança opcional que oferecia mitigação de exploit enquanto esperava o conteúdo descer do RHEL
Considerando os acontecimentos recentes, ambas parecem ser bem mantidas
Todos os serviços podem rodar em contêineres, e o SO base pode se atualizar automaticamente na frequência que você quiser
Eu escolhi openSUSE MicroOS, e como ele atualiza e reinicia praticamente todos os dias, tenho bastante confiança de que o servidor está saudável
Como os updates são atômicos, se algo quebrar e eu não quiser lidar com isso na hora, posso apertar o botão de rollback no Cockpit e ver depois quando tiver tempo
Quando o upgrade finalmente vier, a chance de ele ser bem doloroso é grande
Acho melhor fazer saltos de versão menores com mais frequência do que dar um salto enorme depois de anos, quando tudo já mudou
Se não se importar em registrar na Red Hat, também existe RHEL, que dá acesso gratuito a updates para até 10 máquinas por conta registrada
O RHEL é claramente o mais estável entre as grandes distribuições, e Alma e Rocky são essencialmente clones downstream dele
Estou no mesmo barco
Tenho dois servidores antigos deixados de lado por “tempo demais”, e agora dá medo até de mexer para atualizar
Mas vendo toda a confusão que as distros Linux andam fazendo com verificação/comprovação de idade, estou até pensando em abandonar de vez
Também tentei Artix, mas quebrou depois de reiniciar na semana passada, aparentemente por algum problema no update anterior do kernel, e precisei até recorrer a uma rescue ISO
Então troquei esse equipamento para Devuan, mas ainda não formei opinião
Não tenho grandes reclamações, mas ainda está em fase de burn-in
No laptop estou usando Arch, mas a comunidade parece meio hostil por causa da questão de censura, então quando eu tiver um fim de semana livre quero apagar tudo e instalar outra coisa
Não quero drama político em software
Curiosamente, esta foi a primeira vez que comprei um notebook novo e instalei Linux direto sem nem dar boot no Windows uma única vez, e tudo simplesmente “funcionou”
É triste querer curtir Linux agora e ver os grandes players abraçando etapas de erosão de privacidade como IA em todo lugar, comprovação/verificação de idade e telemetria ativada por padrão
Minha atitude com esse tipo de coisa é simplesmente “não mesmo”
Esse servidor continua rodando até hoje no LTS mais recente
Nem sei se ele começou no Ubuntu 4 ou 6, mas foi tudo muito tranquilo
Talvez upgrades lentos até ajudem a evitar dores de early adopter
Hoje em dia uso muito mais Debian
Com tantos ataques à cadeia de suprimentos, o Debian Stable é realmente uma joia, mesmo que às vezes eu precise lidar separadamente com alguns pacotes por querer versões mais novas; gosto desse espírito de engenharia sóbrio e antigo
As duas distros estão entre as que seguem mais rápido o fluxo do “latest and greatest”, e estabilidade nem sempre é a maior prioridade
Mas isso não quer dizer que distros rolling precisem sempre oferecer apenas a versão mais nova de tudo
Nos últimos meses venho usando Void Linux: é rolling, mas usa kernel LTS e também permite usar mainline, e os mantenedores se preocupam mais com versões estáveis dos apps do que com atualização a qualquer custo
Também tenho um pouco de Debian onde faz sentido, como no Proxmox, em VPSs que não suportam Alpine e em equipamentos ligados ao trabalho
Tenho algumas máquinas de teste rodando Chimera, mas não pretendo depender muito dela até sair uma versão estável
Também estou experimentando um pouco com AerynOS
O suporte de uma release dura menos de um ano, então se você perder a janela de upgrade depois fica mais difícil atualizar do que em outras distros como Debian Stable
Acabei migrando para Debian e Ubuntu para uso em servidores, mas quando era mais novo, ali pela metade dos anos 2000, eu era obcecado por FreeBSD
Passei mais tempo configurando e ajustando do que fazendo algo realmente útil
Naquela época era difícil achar servidor dedicado ou VPS oferecendo sistemas da família BSD, e acho que acabei ficando em serviços como o Panix.com
Antes disso, também lembro de uma empresa chamada 15MinuteServers, que acho que ficava no que antes era a NAC em Nova Jersey, e que oferecia BSD
Agora estou só divagando por nostalgia
Uso FreeBSD na Hetzner e na OVH, e antigamente também usei Vultr
E a maioria dos provedores de VM/VPS KVM permite acesso ao console e montagem de ISO personalizada, então você pode instalar o que quiser
O fato de o fastfetch reportar mais memória usada do que a real provavelmente é por causa do ZFS ARC
Assim como o page cache do Linux, ele pode ser recuperado a qualquer momento, e ferramentas diferentes dão nomes diferentes para isso: https://www.linuxatemyram.com/
Lembro de quando alguém me explicou Docker pela primeira vez e eu respondi: “ah, você está falando de jail?”
Como o texto explica, não é exatamente a mesma coisa
kqueuetambém foi uma grande vitóriaSou muito grato aos desenvolvedores do FreeBSD
Toquei minha primeira empresa por 15 anos em cima de FreeBSD, e o uptime e a resiliência eram impressionantes
Também tenho um servidor Ubuntu 16.04 que dá medo de atualizar
O uptime atual é de 1281 dias, e a essa altura até fico com pena de reiniciar
dde dar boot nele em um emulador comoqemupara fazer um ensaio geralSó tome cuidado se houver algo configurado para iniciar automaticamente e se conectar a sistemas externos
Você tem backup, não tem?
Em sistemas Debian/Ubuntu é fácil configurar atualizações automáticas regulares e reinicializações, deixando a manutenção manual só para upgrades maiores de versão