Pequena Investigação sobre Sistemas Operacionais

black illuminated keyboard

Photo by https://unsplash.com/photos/BStW5kYXw4E on Unsplash


Conforme já comentei em artigos anteriores, sou um usuário de Linux bastante cíclico. Passei um bom tempo, recentemente, deixando de lado meus problemas “filosóficos” com o systemd e seus amigos e usando o Linux Mint. Ultimamente, acabei encontrando o MX Linux, que é um Debian sem systemd. Mas o MX ainda é um amontoado meio desorganizado de software, todo empilhado de maneira a “funcionar”, distante do que eu acredito que seria um sistema operacional ideal para mim.

Então eu tive uma ideia: eu precisava de um “sistema base” que praticamente não mudasse nunca, e poderia rodar aplicações mais “chatas” em containers rodando qualquer outra distro que fosse necessária. Dessa maneira, além de ter um sistema mais são, eu evitaria o transtorno que é ficar migrando de uma distro para outra (e isso acontece frequentemente...).

E eis que encontrei, buscando por uma solução para meu dilema, dois termos que me chamaram a atenção: “Void” e “suckless”.

Void Linux

O Void é uma distribuição bem minimalista. Para você ter uma ideia, um Funtoo “cru” (ou seja: meramente com o “stage3” descompactado numa partição) ocupa cerca de 2.1GB em disco. O Void? Cerca de 200MB.

A distro ainda segue as linhas gerais do sistema de arquivos do Linux (não é como o GoboLinux, por exemplo, ou mesmo o Nix), mas conta com um gerenciador de pacotes escrito (em C) do zero, que é bem eficiente e inteligente, chamado xbps.

O mantenedor principal era um cara que veio do NetBSD. E um dia ele sumiu, e todo mundo entrou em pânico, até que a equipe de colaboradores deu lá seu jeito e praticamente tudo voltou à normalidade.

suckless

Vide https://suckless.org/ .

ᐳ Home of dwm, dmenu and other quality software with a focus on simplicity, clarity, and frugality.

“Suckless” é uma espécie de “movimento” que busca desenvolver e usar software que não seja uma merda, basicamente.

Fiquei fascinado pela coisa toda. Admito que há algum exagero em algumas coisas e um certo desleixo em outras (vide quão desnecessariamente complexo é manter um dwm bem configurado, já que as versões de programa principal e seus patches são meio desencontradas e você tem que verificá-los manualmente para garantir que uma coisa bata com a outra). Mas os ideais são muito interessantes.

Uma das coisas que mais me chamou a atenção foi a ideia de um software alcançar o status de completamente terminado. Não “abandonado”, mas completamente pronto: não serão adicionadas novas funcionalidades e ninguém tem encontrado qualquer bug ao longo de muitos anos. Isso não é incrível?

No fim das contas, eu acabei não adotando muitos softwares criados por esses caras, mas entrei em contato com vários conceitos interessantes e que muito dificilmente se vê sendo discutidos por aí, como as vantagens e desvantagens da linkagem estática, ou mesmo essa noção do software que um dia é simplesmente terminado.

E os conceitos principais do “suckless” foram os que mais me marcaram e que eu mais senti que foram se perdendo de vista, inclusive da minha, no “mundo GNU/Linux”: simplicidade, clareza e frugalidade.

Void Linux?

Aprendido com a experiência, eu já tinha uma partição disponível no laptop para a instalação de um novo sistema operacional. Eu cheguei a usá-la para tentar tornar o GoboLinux usável, mas acabei largando mão depois de encarar a dificuldade de criar uma recipe para uma versão menos desatualizada do Firefox (a minha foi aprovada, inclusive, mas até hoje não consigo vê-la na listagem oficial). Meu plano era meio que tornar o GoboLinux minha “distro base”, mas vi que seria um esforço monumental demais para alguém tão ocupado (pelo menos na época).

O Void é uma distro muito minimalista e até bem organizada, mas sofre de dois principais problemas, para mim:

1- Ela é crua demais.

2- Ela é “opinionada” demais.

Crua demais

Eu cheguei a fazer uma instalação e bootar o sistema na máquina, mas não consegui passar daí: não havia jeito de acessar a rede sem fio. Pesquisei bastante por opções, mas ou elas eram incompletas, ou mal explicadas, ou dependiam do NetworkManager, que é um serviço que, por mais que me tenha sido útil, eu prefiro ficar longe, atualmente (especialmente na minha “distro base”).

A vantagem disso tudo é que eu me obriguei a aprender o básico para usar iw e wpa_supplicant e até criei um projetinho simples para facilitar a vida de quem mais estiver em situação semelhante:

https://github.com/cleberzavadniak/wifi.sh

Isso não foi o principal motivo para abandonar a distro, mas foi um “ponto de dor” que contou na decisão, certamente. Afinal, qualquer coisinha que você antes considerava “dado”, no Void tem que ser conquistado. O que não é necessariamente ruim, claro. Mas certamente é pouco prático.

Opinionada demais

Meu plano era justamente tentar seguir mais à risca o “suckless” e passar de largo por serviços como dbus, pulseaudio e mesmo udev. Mas como? Os pacotes do Void são pré-compilados, então eu acabo descobrindo suas dependências somente na hora de instalar. E o projeto não tem uma filosofia explícita o suficiente quanto a esses serviços que citei.

Esse problema tornou-se mais patente quando fiz menção de instalar o Fluxbox e li a extensa (e absurda) lista de dependências, que me pareceu bem mais abrangente do que o necessário.

Combinação ruim

Então eu me vi nesse dilema: Void Linux representaria uma distro com pouco “açúcar” e pouco controle. Eu até poderia compilar praticamente tudo na mão, para ter controle, mas se for para fazer isso, me parece que o Funtoo já tem tudo pronto, e ainda vem com açúcar o suficiente para que seu uso não seja tão “chato”, mas não o bastante para que eu a considere “muito entulhada”.

Funtoo?

Então eu tentei instalar e configurar o Funtoo. Até o ponto em que percebi que compilar o sistema todo com o make.conf gigante que montei especialmente para atender minhas necessidades demoraria dias.

Citando o Tio Bob: “there must be a better way!

Um jeito melhor

É curioso como buscar por “alternative operating systems” não retorna muitos resultados satisfatórios. Os melhores que obtive foram uma combinação de sagacidade-da-experiência com um pouco de acaso.

Haiku

https://www.haiku-os.org/

Entre os resultados que obtive, voltei a dois nomes que eu já conhecia razoavelmente bem: ReactOS e Haiku. O primeiro é uma tentativa de “Windows open source”, coisa que absolutamente não me anima (me dá uma tristeza só de olhar aquela interface de usuário). Já o segundo é uma tentativa de razoável sucesso de implementar-se um “BeOS open source”.

O BeOS era um sistema operacional voltado ao desktop e com um leve jeitão de Windows: janelinhas, menus, aplicações gráficas em geral. Para a época, era bem avançado, e até hoje muitas ideias dele são consideradas bem interessantes.

O Haiku tem um jeito de instalar aplicativos que envolve umas mágicas feitas pelo sistema de arquivos, o BeFS. Além disso, o desenvolvimento é bem integrado, pois é um mesmo time quem lida tanto no kernel quanto na interface do usuário.

No geral, a experiência de uso é bem agradável e, especialmente, muito rápida. Tudo parece muito fluido e leve, e foi usando o Haiku (eu cheguei a bootar a máquina nele e usar) que eu percebi o quanto meu Linux estava comendo poeira em questão de velocidade.

Eu ainda tenho planos de manter uma partição específica para esse belo sisteminha. Mas, por agora, o projeto ainda está numa versão beta e há, sim, vários pequenos bugs que manifestam-se aqui e ali, além de algumas questões de usabilidade que certamente precisam melhorar, especialmente na organização do menu de aplicações.

Hummm... Linux?

Estudando sobre o desenvolvimento do Haiku, deparei-me com alguns conceitos que ressoavam um pouco do que o “suckless” prega, como simplicidade e corretude. Mesmo seguindo na trilha de um sistema operacional comercial abandonado (o BeOS), a equipe parece preocupada com algo muito positivo: resolver os problemas do jeito certo e sem medo de parecer heterodoxo.

E “o jeito certo”, mesmo sujeito a muita discussão, parece ser um bom objetivo. Inclusive por causa da própria discussão.

Estudando algumas questões sobre sistemas operacionais em geral e sobre “fazer as coisas do jeito certo”, acabei lendo algumas coisas que, curiosamente, acabaram lançando por terra a tênue “barreira de contenção” que dividia meu desprezo pela “turma do FreeDesktop.org / RedHat” (dbus, udev, systemd, PolicyKit, et cetera) do meu respeito pela equipe que desenvolve o kernel Linux.

Eu ainda considero Linus Torvalds um desenvolvedor absolutamente acima da média, assim como vários mantenedores do kernel. Mas aceito o fato de que certas decisões são perfeitamente questionáveis, mesmo que perfeitamente justificáveis. No fim das contas, é preciso tomar decisões, certo? E, como dizem, “cada escolha, uma renúncia”.

Eu acho o máximo não ter mais problemas com compatibilidade de hardware, por exemplo. A única exceção recente foi com uma placa de rede sem fio de um laptop Dell “2 em 1”, mas bastou baixar um arquivo e jogar num caminho específico do sistema que tudo passou a funcionar razoavelmente bem. Comparado com o milagre que foi quando consegui fazer meu “winmodem” funcionar, lá no começo dos anos 2000... Mas, ao mesmo tempo, eu me pergunto se é o Linux o atual “motor da melhoria” do mundo da computação pessoal como já foi no passado. Será que eu mesmo já não evolui o suficiente ao ponto de o certo a fazer ser deixar o Linux para trás e passar para outro desafio?

Afinal, quanta coisa atual eu tenho rejeitado desse mundo em que estou envolvido? Eu tenho passado os últimos dias matando serviços no meu MX Linux, que já é uma distro relativamente minimalista!

Eu tenho ficado irritado com o ntpd, que é o raio do serviço que ajusta o horário! Como pode um troço desses não funcionar de maneira simplesmente perfeita? Por que diabos há momentos em que o serviço consome mais CPU que meu emulador de terminal?

Tem que haver um jeito melhor!

glibc

Outra coisa que havia me chamado a atenção quando estudava usar o Void e a respeito do que eu tirei um tempo para estudar foi a situação do desenvolvimento e as decisões tomadas pelos mantenedores da glibc. Eis outra reputação que acabou manchada, embora eu mesmo não tivesse tanto conhecimento a respeito da glibc a ponto de atribuir a ela uma “reputação”.

Acontece que o Void Linux tem uma versão compilada toda usando-se a musl-libc, que é uma versão nova que pretende fazer um serviço melhor(e de maneira mais leve) do que a glibc — apesar de que, conforme eu fui entender depois, mesmo esse projeto novo acabou tomando algumas decisões “justificáveis mas muito questionáveis”...

OpenBSD

No embalo do “fazer as coisas do jeito certo”, é claro que voltei a sondar o OpenBSD.

Eu já havia chegado até a bootar uma máquina no OpenBSD anteriormente, mas como era mais por curiosidade do que por necessidade, acabei achando o mundo “Unix” muito sem graça. No fim das contas, “Unix is not GNU”, e para alguém que acostumou-se com o açúcar do zsh, enfrentar um shelzão preto-e-branco em que os comandos de sempre frequentemente exigem opções de nunca (não é assim tão fácil desfazer-se da “memória muscular” do mundo GNU), não havendo uma necessidade urgente, acabei meramente deixando o sistema de lado.

Uma pena que não escrevi a respeito, na época.

Também sofri para instalar pacotes, mas isso é mais provável que tenha sido por falta de ler a documentação e entender melhor o sistema do que uma deficiência do mesmo.

Como uma coisa puxa a outra nessa história, buscando por mais informações sobre o OpenBSD, acabei, de alguma forma, me enveredando para outro sistema operacional do qual eu já conhecia algo e que voltou a me interessar: o Plan 9.

A partir daqui, eu mando um ctrl+z bg: o OpenBSD não foi descartado e provavelmente será meu novo “sistema operacional de casa”.

No fim do artigo mostrarei uma lista com os sistemas que pretendo manter instalados e o motivo para cada um estar nela.

Plan 9 from Bell Labs

O Plan 9 é considerado uma espécie de “sucessor espiritual” do Unix original, já que foi desenvolvido dentro da Bell Labs, mesmo berço do Unix, e por uma equipe formada por vários de seus antigos desenvolvedores.

Você já ouviu falar que “no Unix, tudo é um arquivo”? Pois é. A base conceitual do Plan 9 é que tudo seja um arquivo, literalmente. Ao ponto de haver um display manager embutido no sistema que trata suas janelas como arquivos, também.

“Como arquivo” é uma simplificação, claro. Geralmente, os programas ou o kernl provêem uma “árvore” com vários entry points que são vistos e manipulados pelo usuário como arquivos.

Ao invés de você usar uma syscall para abrir um socket, por exemplo, você simplesmente manipula alguns arquivos dentro de /net/tcp ou /net/udp. E ao invés de toda essa loucura que é a gestão de “capabilities” no Linux, o controle de privilégios se dá (1) no jeito que um namespace é entregue ao processo e (2) via controles de acesso tradicionais aos arquivos.

Namespaces

O Plan 9 permite que você use uma espécie de “overlayfs” para iniciar um processo dentro de um “espaço de nomes” (que é um termo mais adequado, nesse contexto, para um “sistema de arquivos”) que você pode customizar.

Por exemplo: para evitar que um processo tenha acesso à rede, você simplesmente cria um namespace sem o /net.

Ao invés dos termos “sistema de arquivos” e “arquivos”, o Plan 9 e seus derivados usam os termos “espaços de nomes” (namespaces) e “nomes” (names), até porque, se “tudo é um arquivo”, então bem menos coisas são, de fato, “arquivos” (agora também o são interfaces de rede, entry points de IPC com outros programas, janelas, outros processos, situação do sistema, sensores de dispositivos, etc).

Simplicidade, coerência e clareza

Você sabia que o Linux tem **mais de 400 syscalls **? Pois é. O Plan 9 tem menos de 40 (http://aiju.de/plan_9/plan9-syscalls). É claro, sabemos bem que certos tipos de complexidade não se eliminam completamente, já que há tarefas que são complexas per si. Algumas coisas simplesmente são movidas de lugar, como a syscall de abertura de um socket, que agora consiste em saber-se o caminho certo do “entry point com cara de arquivo” que você deve manipular. Mas, de qualquer forma, o sistema como um todo parece muito mais coerente, com menos exceções às regras.

Inferno

http://inferno-os.com/

O Plan 9 até tem algumas implementações disponíveis, mas a que mais me chamou a atenção foi o “fork/irmão” chamado Inferno, que, apesar de ter uma história um tanto diferente, implementa basicamente os mesmos conceitos do Plan 9, ao ponto de podermos dizer que são praticamente a mesma coisa.

O que é legal do Inferno (que frase estranha para se escrever!) é que ele pode rodar como uma espécie de “máquina virtual” sobre o Linux (ou mesmo sobre o Windows). Ou seja: você pode usufruir dele sem ter que instalá-lo na máquina como se fosse um sistema operacional tradicional. E é algo que faz todo o sentido: afinal, com menos de 40 syscalls e praticamente tudo o que se precisa sendo disponibilizado via namespace, o próprio sistema operacional parece-se muito como uma máquina virtual — e uma máquina virtual bastante simplificada!

Eu não cheguei a rodar o sistema, ainda, pois ainda estou lendo mais a respeito e até lutando para adaptar os meus conceitos mais tradicionais a essa abordagem tão “heterodoxa”.

Não é curioso? Eu passei mais de uma década usando diariamente um sistema em que, na teoria, “tudo é um arquivo”, mas quando surge um sistema que leva isso realmente a sério, muitos paradigmas são quebrados ao ponto de eu ter alguma dificuldade em conceber certas formas de se fazer as coisas.

Harvey OS

https://harvey-os.org/

Lendo a respeito do Plan 9 e Inferno, acabei encontrando dois sistemas operacionais que eu absolutamente desconhecia: o Harvey OS e o Jehanne OS.

Uma coisa que achei interessante no Harvey foi o fato de o código fonte estar disponível no Github. Mas, infelizmente, o site contém quase nenhum conteúdo realmente interessante, que diga quais são os objetivos do projeto. Fala-se muito em como rodar ou buildar o sistema, mas pouco sobre a filosofia seguida, por exemplo.

Assim, apesar de parecer um projeto até bem maduro, com uma quantidade interessante de softwares portados, eu acabei perdendo o interesse por ele, já que não consigo entender qual seria, por exemplo, o grande diferencial em relação ao Inferno.

Jehanne OS

http://jehanne.io/

Pode não ser muito óbvio, mas “Jehanne” é o primeiro nome da Joana d'Arc, que foi morta na fogueira por ser considerada uma “herege”. E é exatamente com esse aspecto “herético” que o sistema operacional busca identificar-se.

Depois de toda essa pesquisa, eu comecei a dividir, mentalmente, os diversos sistemas em duas categorias principais: ortodoxos e heterodoxos. E o Jehanne é, entre os heterodoxos, o que o OpenBSD é entre os ortodoxos.

O OpenBSD foi o primeiro a implementar aleatorização de memória, um dispositivo de segurança pró-ativa que, na época, já era até bem conhecido, mas “quebrava as coisas”: várias aplicações dependiam, erroneamente, de a memória ser fisicamente um espaço contíguo. Por isso, mesmo que a técnica fosse conhecida, nenhum outro sistema operacional implementava. Pois o pessoal do OpenBSD, que tem mais interesse em fazer as coisas direito do que em arrebanhar usuários ou “passar pano” nos erros dos outros, implementou. E as coisas quebraram. E pessoas ficaram tristes e furiosas e nomes foram ditos. E, por um certo tempo, tudo ficou meio caótico. E depois tudo voltou ao normal, porque a pressão dos usuários de OpenBSD junto aos softwares falhos obrigou todos a também fazerem as coisas direito.

O OpenBSD tem até um lema (que não sei se está oficialmente escrito em algum lugar): “faça direito ou não faça”.

Eles são corajosos e isso tem gerado inúmeros benefícios para os usuários de outros sistemas operacionais. Os softwares atuais são, em geral, muito melhores graças à coragem e firmeza dos mantenedores do OpenBSD.

O Jehanne OS é parecido. Eles prezam por um valor que torna o projeto ideologicamente muito similar ao “suckless”: simplicidade.

E tão focados os mantenedores são nesse alvo que chegaram ao ponto de eliminar o suporte a swap. Eles viram que isso tornava o kernel muito complexo e decidiram que era melhor eliminar a comodidade em favor da simplicidade (porque o alvo é esta, não aquela, afinal).

Você lembra que o Linux tem +400 syscalls e que o Plan 9 tem menos de 40? Pois então, o Jehanne tem apenas 26 syscalls. O foco na simplicidade ajuda a buscar maneiras novas de resolver problemas antigos. A história de como a sleep foi eliminada, por exemplo, é bem interessante.

Heresias!

http://jehanne.io/pages/overview.html

Talvez a parte que mais me anima nesse projeto é, além do laser focus na simplicidade, a coragem de inovar sem se preocupar com o que os outros vão pensar.

A única “heresia” que me deixa um pouco ressabiado é o uso da licença AGPLv3. Eu sou mais favorável às licenças estilo BSD, que são bem menos restritivas, porque, afinal, eu não me importo nem um pouco com pessoas copiando meu código e usando onde quer que prefiram usar...

Resultados preliminares

Como fui estudando tudo de maneira bem encadeada, minha mente foi categorizando cada sistema de variadas maneiras. No fim das contas, como um resumo prático das coisas que concluí até agora, o gráfico a seguir ajuda a visualizar alguns padrões.

os comparison

Usuality / Shitness

É claro que a forma de categorizar poderia ser debatida ad infinitum, mas como ela parte do meu ponto de vista, por ora, contente-se em encarar isso somente pelo que é.

Eu defini usuality como tendo como padrão mais alto o Windows 98, que é um sistema simples e estável o suficiente para qualquer pessoa usar sem maiores problemas. Estou pensando em sistemas operacionais, nesse caso, como ferramentas voltadas ao desktop, não a servidores, dispositivos móveis ou qualquer outro caso.

Não, eu não acho o Windows 98 o melhor sistema operacional que já existiu (eu odeio ficar explicando que a grama é verde, mas lá vamos nós). O que eu fiz foi imaginar um público bem amplo, pegando algum contexto histórico bem comum. Repare que mesmo uma criança que só teve contato com o Android consegue se virar muito bem em um PC com Windows 98.

shitness é o quanto o sistema é uma merda seguindo, não muito rigorosamente, os conceitos do “suckless”. Se o código ou o sistema são complicados demais, se há pouca coerência ou pouca clareza, o sistema ganha muitos pontos de shitness.

Esse, novamente, é o caso do Windows 9x (estou olhando para você, Windows ME). Apesar de ser um sistema muito fácil de usar, o código é complicado (havia tratamento dentro do “kernel” para bugs encontrados dentro de programas da própria Microsoft), há pouca coerência (o sistema controlava muito pouca coisa, então cada um era livre para fazer seu trabalho do jeito que achava melhor) e a clareza é zero, pois o código é fechado.

Tendências

Há uma aparente linha central diagonal que mostra uma tendência interessante: quanto mais “usual” um sistema é, mais ele tende a ser uma merda (de acordo com o contexto desse artigo, claro).

Veja que nós poderíamos trocar o eixo “shitness” por “tamanho da base de usuários”, também, e o gráfico continuaria fazendo sentido — ao menos na linha central.

Numa ponta, nós temos o Windows (o que é natural, já que um deles é a base da medição), enquanto na outra nós temos os sistemas baseados no Plan 9.

Do ponto de vista da “usualidade”, isso faz sentido porque o Windows é um sistema que tem como foco maior trazer comodidade ao usuário (mesmo que falhando miseravelmente, muitas vezes), enquanto o Jehanne OS, que está na outra ponta, tem como foco ser simples. De certa forma, este último é uma espécie de prova de conceito, enquanto aquele tem foco estritamente comercial e pouquíssimo “filosófico”.

Já do ponto de vista de ser uma merda, na ponta do Windows explica-se da mesma forma que o parágrafo anterior. E o Jehanne OS também. :)

Repare que nos Unix-like nós temos “pontas” interessantes, também, que seguem o mesmo padrão geral. Enquanto o Ubuntu tem mais foco em levar o Linux ao desktop e ser popular (objetivo que parece estar sendo alcançado com sucesso, o que é algo bom), no OpenBSD a filosofia de fazer as coisas do jeito certo é absolutamente mais importante do que a atração de novos usuários.

No subconjunto do “Plan 9” (Inferno, Harvey e Jehanne), repare que o Inferno está “menos longe” da completa merdice, justamente porque o projeto parece menos disposto a grandes mudanças e o sistema também teve como aspecto histórico importante a tentativa de ser vendido comercialmente. Já Jehanne e Harvey estão muito mais propensos a mudanças, tendo o primeiro uma base filosófica muito clara.

Jehanne ainda ganha 1 ponto de shitness por um motivo simples: ninguém é perfeito. Já “usualidade” é zero, mesmo. Pelo que vi, até um usuário de Inferno possivelmente sentiria-se um tanto perdido usando o Jehanne.

Correndo por fora temos ReactOS e Haiku. O primeiro é o que tem mais possibilidade de ser injustiçado nessa análise porque, admito, eu tenho um conhecimento muito superficial sobre ele.

Se o eixo X representasse “facilidade de uso para o usuário mediano”, talvez o Haiku pudesse até ultrapassar o Windows 98. Mas o parâmetro é “usualidade” e já foi explicado anteriormente.

Curiosamente, me parece que um usuário de longa data do Windows 98 sentiria-se mais à vontade usando o Haiku do que um Windows XP, por exemplo. (Opinião pessoal. Sua quilometragem pode variar).

Os sistemas que pretendo manter rodando

Eu acho o assunto tão interessante que gostaria de ter N máquinas dedicadas a ter instalações isoladas de cada sistema operacional. Talvez um dia eu monte uma pilha de Raspberries ligada num “switch” de monitor/teclado/mouse...

(A lista a seguir não tem qualquer ordem significativa.)

Funtoo

Apesar de tudo o que foi dito, eu não pretendo me ausentar completamente do mundo Linux. E, entre todas as distros, a que me dá mais controle é, seguramente, o Funtoo. E isso aliado a alguma praticidade a mais se comparada com o Gentoo.

Manter um sistema grande acaba sendo chato por causa das contantes recompilações, mas ele servirá bem como um “Linux base”, com poucos pacotes, regras de “USE” bem estritas (-dbus -systemd -pulseaudio) e uso de ferramentas “suckless” ou, pelo menos, muito mais leves do que as usadas mais popularmente em outras distros.

Linux Mint

A praticidade é uma qualidade, não posso negar. Apesar de todos os pesares, o Ubuntu tem um exército de gente trabalhando para deixar a distro o mais funcional possível, e entre os derivados dele, o Mint é a que me pareceu mais bem acabada.

É um sistema pesado e gordo, mas se eu precisasse escolher algum para ser o padrão de instalação numa empresa, por exemplo, muito provavelmente seria o Mint.

Além disso, quando as opções de instalação de Linux num servidor remoto reduzem-se a CentOS ou Ubuntu, eu absolutamente prefiro o Ubuntu. (Eu ainda tenho dúvidas sobre o que escolheria se precisasse decidir entre CentOS ou Windows, para você ter uma ideia...)

OpenBSD

Entre os sistemas ortodoxos, tem sido o meu preferido, pelo menos filosoficamente. Ainda tenho muito o que aprender, mas acredito ser um aprendizado muito útil, inclusive para eu saber me virar dentro de BSDs em geral.

Haiku

Eu gosto do Haiku e torço para que chegue logo o dia em que eu possa recomendá-lo para meus familiares e público não-técnico em geral.

Ademais, quero estudar as capacidades do BeFS e algumas “novidades” do Haiku. Não é porque o sistema é baseado em interface gráfica que ele é ruim. :)

Inferno

Me parece ser, entre os heterodoxos, o que seria o Ubuntu entre os ortodoxos. Então pode ser útil, nem que seja para sentir melhor as diferenças entre ele e o Jehanne.

Jehanne OS

Entre os sistemas heterodoxos, tem sido o meu preferido, pelo menos filosoficamente. Já tem muito tempo que eu sinto a vontade de estudar o código de um sistema operacional que tenha foco real na simplicidade. Fico curioso para saber como as coisas realmente simples compõem-se para formar soluções complexas.

Bônus: Arcan

https://arcan-fe.com/about/

No processo eu acabei descobrindo, também, o projeto Arcan. Acho que eu já havia trombado com ele há alguns anos, mas parece que agora ele está ganhando bastante força.

No site há muito material bem interessante e, já que a ideia é que o Arcan também sirva como display manager, o autor entra em detalhes interessantes sobre as implementações atuais dos diversos sistemas, como Xorg+Linux, Wayland, Xenocara+OpenBSD e outros. É engraçado (e educativo) ler as críticas que ele faz a cada um.

Curioso é que ele segue uma filosofia parecida com o “suckless”, mesmo que seu projeto seja razoavelmente complexo (o que, claro, é justificável, já que display managers são um problema complexo).

Bônus: conceitos

Por que diabos ainda falamos em tty? Por que os terminais são emuladores de vt100? Por que eu preciso aprender troff para escrever páginas de manual?


Este artigo foi escrito originalmente em 25/12/2018.