Chimera Linux
(chimera-linux.org)- O Chimera é um sistema operacional de uso geral baseado em Linux que nasceu da insatisfação com o ecossistema Linux tradicional e busca oferecer recursos práticos mantendo simplicidade e transparência
- É uma distribuição construída do zero e busca combinar simplicidade conceitual e facilidade de uso por meio de novas ferramentas e ferramentas de espaço de usuário (userland)
- Adota uma composição diferente das distribuições Linux comuns, combinando ferramentas essenciais do FreeBSD, toolchain LLVM e biblioteca C Musl
- Embora seja uma distribuição binária, oferece um sistema de build de pacotes a partir do código-fonte, dando suporte ao empacotamento de novos softwares e a builds customizados
- Tem como alvo várias arquiteturas de processador, como Intel/AMD, ARM AArch64, POWER e RISC-V, e busca ampliar a cobertura de pacotes por meio de um sistema central de build
Objetivos e direção de design
- O Chimera é um sistema operacional de uso geral baseado em Linux, voltado a simplicidade, transparência e baixa barreira de entrada
- Sem abrir mão da praticidade e de um conjunto rico de recursos, busca combinar simplicidade conceitual e conveniência por meio de um design de software cuidadoso e de alta qualidade
- Mais detalhes podem ser conferidos em Read more
Principais características que compõem a distribuição
-
Ferramentas alternativas de espaço de usuário
- Combina ferramentas essenciais do FreeBSD, toolchain LLVM e biblioteca C Musl
- Com essa combinação, busca oferecer uma experiência de usuário e vantagens principais diferentes das distribuições tradicionais
-
Sistema limpo e consistente
- Busca remover resquícios legados sempre que possível
- Tem como objetivo ser um sistema operacional moderno, de uso geral e completo em recursos
-
Pode ser compilado a partir do código-fonte
- O Chimera é, por padrão, uma distribuição binária
- Oferece um sistema de build de pacotes a partir do código-fonte para facilitar o empacotamento de novos softwares e a criação de pacotes customizados
-
Suporte a várias arquiteturas
- Pode ser usado em diversos processadores, como Intel/AMD, ARM AArch64, POWER e RISC-V
- O sistema central de build permite que pacotes sejam usados em vários ambientes
1 comentários
Opiniões no Hacker News
Para quem usa há muito tempo as ferramentas GNU (GNU grep, sed, less, awk, find, tar etc.), pode ser muito mais frustrante do que se imagina
Na época do UNIX, havia diferenças sutis entre as ferramentas de linha de comando, o que era realmente penoso, e esse também foi um dos motivos pelos quais as ferramentas GNU se tornaram populares antes mesmo do Linux
Ao instalá-las em qualquer UNIX, como irix, hpux, sun etc., era possível evitar diferenças estranhas como as entre o grep do hpux e o grep do irix
Mas, como eu não controlava os servidores Aix e HP-UX, os scripts que precisavam rodar em todos os servidores tinham de ser mantidos compatíveis com POSIX ou escritos em Perl
awk frequentemente é instalado explicitamente como gawk ou mawk, e seria bom se tar também fosse comumente usado como bsdtar, gtar
No nixpkgs é fácil especificar a versão exata conforme a situação, mas na maioria dos outros ambientes isso acaba sendo quase um chute
Em máquinas Solaris em que eu tinha root, criei o hábito de instalar gtar imediatamente, especialmente por causa do “/” inicial dentro dos arquivos
O segundo maior problema era lidar com SunOS e HP/UX no trabalho e Ultrix fora dele; o pior foi quando tive alguns contatos com MS-DOS e não conseguia entender por que ele não fazia buffer das teclas digitadas
Gosto de várias escolhas de design do Chimera Linux, especialmente o sistema de empacotamento/build, mas, como alguém que atualmente usa Alpine Linux no PC principal, ainda acho difícil justificar o musl
Gosto de software pequeno, simples e correto, mas, apesar dessas qualidades, pela minha experiência o musl é mais lento que a glibc e às vezes fica lento em pontos difíceis de prever
Ao portar software para musl, há muitos pequenos problemas, e a maioria dos upstreams reluta em aceitar patches, o que aumenta o fardo de manutenção da distribuição
Também há casos em que algo quebra de forma sutil em runtime; por exemplo, os builds do Firefox no Alpine e no Chimera exibem os mesmos dois crashes que não existem nos builds oficiais da Mozilla nem nos builds do Arch Linux
No fim, em tarefas como builds do Mozilla Firefox, acabo dependendo com frequência demais de um chroot com glibc
Pelo que me lembro, o Chimera usa um alocador diferente do alocador padrão do musl
O musl acaba causando muito mais problemas do que entrega valor
Pela configuração da toolchain, outras opções não se encaixam bem, e a glibc não combina com clang+compiler-rt
A glibc só começou a ser compilada com clang recentemente, mas ainda pressupõe um runtime centrado em gcc e, na prática, faz dlopen de libgcc_s
Outras libcs provavelmente seriam muito piores em termos de suporte
A dificuldade de portar software para musl é um tanto exagerada
A maior parte do software nem precisa de portabilidade para começar, e os upstreams também não são tão relutantes assim
Se há crashes específicos no Firefox, fico curioso se eles foram reportados
A lentidão geralmente é um problema do alocador padrão, o que não se aplica ao Chimera, e em alguns casos pode até ser mais rápido
Tenho uma máquina da System76 e queria tentar
Não concordo totalmente, mas a posição deste projeto sobre o systemd é a mais madura, sutil e equilibrada que já vi até agora
https://chimera-linux.org/docs/faq#what-is-the-projects-take...
Como alguém que lidou muito com servidores Linux e os enxerga de forma bastante pragmática, acho que o systemd facilitou muita coisa, é configurável, mantido, atualizado com frequência e devidamente padronizado
Entendo também quem quer sentir que tem controle, mas eu quero um computador confiável que funcione de uma única maneira
Afinal, servidores são algo a ser tratado como gado
Por isso, eu gostaria que existisse algo como um experimento mental do blog do Poettering: uma imagem de sistema imutável, boot assinado, composta de cima a baixo por serviços systemd
É preciso separar recursos de kernel específicos do Linux de extensões de espaço de usuário, ou seja, GNU versus POSIX
Usar recursos de kernel específicos do Linux, como cgroups, é uma coisa boa em sistemas Linux
Antigamente, era comum o sshd ficar lento sob alta carga e dificultar o login; o systemd configura o sistema para que isso aconteça menos
No caso das extensões de espaço de usuário, eu gostaria que o systemd tivesse visto como um ganho líquido construir em cima de um conjunto menor de ferramentas e funcionalidades, mas aquela página não parece ir nessa direção
Fico curioso sobre o que aconteceu nesse lado
O Void não faz isso apenas para ser livre de systemd, mas para preservar a herança Unix de componentes pequenos e fracamente acoplados, manter POSIX e portabilidade de forma razoável (xbps) e oferecer um sistema Linux em que o usuário possa escolher a libc
O systemd foi criado para resolver as deficiências do upstart
É excelente o objetivo do Chimera de implementar de forma independente, à sua maneira, funcionalidades do systemd que sejam realmente úteis
O maior valor do systemd é que já existem muitos arquivos de serviço escritos, e no meu diretório ~/.config/systemd também há uma dúzia de serviços
Por isso, vejo valor em ser compatível com o systemd
O systemd foi criado para resolver as deficiências do upstart
Para entender a intenção do Chimera Linux, basta vê-lo como levar o Void Linux um passo além
O fundador foi anteriormente mantenedor de PPC do Void, e a escolha das arquiteturas suportadas pelo Chimera também se entende nesse contexto
Na minha interpretação, o Chimera é o tipo de sistema que um usuário de FreeBSD desejaria se tivesse que usar Linux
Ele compartilha o mesmo compilador e espaço de usuário, e o sistema de build também passa uma sensação familiar
A escolha do GNOME parece estranha à primeira vista, mas o Chimera tenta evitar muito legado e é baseado em PipeWire e Wayland desde o início
Fico curioso se o COSMIC da System76 algum dia vai se consolidar a ponto de entrar em consideração
Seria bom ver surgir um novo ambiente de desktop estável, prático, produtivo e centrado no usuário
O Plasma tem bugs demais, o GNOME não parece nem prático nem centrado no usuário, e os demais parecem carecer de algum nível de polimento e manutenção
A System76 tem dinheiro para investir nisso e parece ter o incentivo certo para criar algo alinhado às necessidades e à sensibilidade dos usuários, mais do que aos ideais dos desenvolvedores; por isso, com o tempo, pode se tornar uma concorrente importante
É legal, mas sempre fico preocupado quando vejo algo que parece tentar se tornar uma distribuição mainstream amigável ao usuário
Vi o quanto o Manjaro se esforçou com objetivos como “simplicidade para as massas”, e mesmo assim quantos problemas ainda tem
Fico me perguntando se isso é uma distribuição experimental ou de hobby, ou se mira em algo que até a avó conseguiria usar
Se eu tivesse que escolher isso em comparação com BSD, consideraria esta opção, ou algo parecido, com bastante seriedade, mas não parece um substituto para Ubuntu ou Windows
Simplicidade não é um fator que o usuário final comum leva em conta
Como desenvolvedor que gosta de software moderno e não tem muito interesse em um ambiente leve e amigável a hackers, é muito improvável que eu use algo que não tenha pelo menos 1% de participação no desktop
Quem não é entusiasta de Arch/Kali/BSD/suckless tem um senso muito apurado de “ah, isso dá a mesma sensação de quando penso em um carro de projeto; melhor cair fora”
Pode ser um projeto excelente e valioso, mas atrair interesse fora do público que gosta de ficar mexendo e ajustando será uma batalha difícil, e esse tipo de coisa consome muito tempo; se as expectativas não forem bem gerenciadas, pode gerar uma grande frustração caso não dê certo
Eu também já comecei vários projetos novos, e foi bem difícil passar pelo processo de perceber que havia grande chance de eles não chegarem a lugar nenhum no futuro próximo
Para conseguir adoção mainstream, acho que todo o próprio ecossistema de software teria que mudar
Acho que haveria problemas para portar para cá aplicativos grandes de hoje, como Steam ou Chrome
Além disso, linkedição dinâmica não parece combinar muito bem com uma distribuição amigável para usuários finais
Sem algo como Snap ou Flatpak, acho difícil oferecer pacotes modernos, grandes e complexos de terceiros sem problemas ocasionais de compatibilidade
Minha experiência geral com distribuições baseadas em linkedição dinâmica não foi horrível, mas sempre havia algum problema aqui ou ali
Também fico curioso se há sandboxing como AppArmor
Chimera é uma distribuição experimental de hobby, bem de nicho e contrária a vários padrões
Você sempre vai esbarrar em problemas específicos do Chimera
Em troca, há um sistema de build transparente com o qual dá para mexer
Sobre o Manjaro, não acho que seja difícil fazer uma distribuição baseada no Arch que funcione bem
São os desenvolvedores do Manjaro que não conseguem
Porque a maioria dos projetos não tem sucesso
Esse tipo de coisa deve ser feita principalmente porque é útil ou divertida para você mesmo, não porque você quer fazê-la dar certo
Também acho ok um projeto mirar em um público específico mais hobista
Nem todo projeto precisa ser para todo mundo
O marketing está mais para “uma distribuição leve para hackers que usa musl, mas é mais simples do que outras da mesma categoria”
Seria bom se as distribuições Linux conseguissem se promover para usuários Linux existentes sem criar acidentalmente essa confusão na mídia técnica não Linux
Muitos usuários de Linux não querem que o sistema operacional estoure em popularidade
Porque, se ficar muito popular, na prática ele vai piorar em vários aspectos
Conversas sobre “o ano do desktop Linux” ou fraquezas de produto sob uma visão estreita em comparação com o Windows geralmente vêm apenas de novos usuários e da mídia técnica
O Fedora equilibra muito bem esse problema de imagem pública
Na página inicial, enfatiza que é para “desenvolvedores e criadores de todos os tipos”, mas o Fedora Workstation é, na prática, quase uma distribuição fácil para quase todo mundo; por isso, a página “Is Fedora For Me” explica que ele também pode servir para não desenvolvedores que tenham curiosidade ou entusiasmo por computadores em geral
A citação também diz que o Fedora foi feito para usuários de computador curiosos e dispostos a aprender, e que pode não ser adequado para todos, mas pode ser o sistema perfeito se você quer um Linux estável com suporte a hardware moderno e tem disposição para contribuir com as comunidades Linux e FOSS
Nas estatísticas da Steam, ele é mais popular que o Ubuntu, e isso nem inclui o SteamOS
“Um sistema simples não precisa exigir configuração e customização intermináveis para ser prático” e userland alternativo não combinam bem
Porque qualquer userland alternativo vai quebrar muita coisa e, no fim, vai exigir um amplo trabalho de ajustes
O Chimera foi projetado para que, independentemente do que você instale a partir do repositório, venha uma configuração que funciona de imediato
Se você quer um desktop, instala e ele funciona; não é obrigatório mexer em dbus, áudio, Wi‑Fi/Bluetooth etc.
O ponto mais importante é que a instalação é estruturada para ser consistentemente determinística e auditável
Ela não depende de hooks de shell complexos nem desse tipo de “trabalho de correção”; a maioria dos pacotes é configurada por simples extração
Claro que, se você trouxer coisas como scripts de shell de terceiros, pode encontrar problemas de compatibilidade, mas talvez isso não aconteça com tanta frequência quanto se imagina
Se for substancialmente diferente, antes dos ajustes o principal será aprender
Chimera foi desenvolvido pela pessoa que portou o Void Linux para PowerPC
https://web.archive.org/web/20230811081600/https://voidlinux...
https://voidlinux.org
Acho que eu estaria muito mais empolgado se não parecesse ter entrado na onda de empolgação exagerada com Wayland
Parece ter tomado muitas boas decisões: simples o suficiente sem ser simples demais, e com compatibilidade retroativa suficiente sem carregar legado demais; mas, pessoalmente, Wayland ainda não se encaixa nessa mesma posição
Independentemente de quão bom o Wayland em si seja, parece trabalhoso quebrar compatibilidade com elas
A perspectiva sobre o SystemD é interessante
Pessoalmente, eu o considero muito útil, mas uma das grandes desvantagens dele como projeto é, pegando emprestada a expressão de Benno Rice, ser agressivamente exclusivo para Linux
No entanto, a própria escolha de software do Chimera parece impedir o uso do systemd, e a frase do FAQ dizendo que “implementaremos de forma independente, à nossa maneira, recursos úteis do systemd” resume bem isso
Fico em dúvida se é possível portar o SystemD para outra pilha de software
Em vez de literalmente reescrever o SystemD, tentar portá-lo parece algo bastante útil, e isso talvez pudesse agradar tanto apoiadores quanto críticos do systemd
Claro, se surgirem produtos concorrentes que façam a mesma coisa, isso também pode levar a inovações futuras
Por isso, mesmo pessoas capazes de portá-lo provavelmente, na prática, prefeririam usar substitutos parciais, como neste projeto, em vez de fazer esse trabalho
Não sei se o fundador gostaria disso, mas minha forma preferida atualmente de usar o Chimera no desktop é instalar nele uma distrobox com Arch Linux
Assim, consigo aproveitar o sistema Chimera base e, ao mesmo tempo, ter acesso imediato a todo o repositório do Arch e à lista do AUR
Aplicativos que dão problema no MUSL também rodam facilmente dentro da distrobox com glibc, e, como o Distrobox repassa o Wayland, apps gráficos funcionam muito bem
O objetivo é rodar o máximo possível de forma nativa no Chimera, mas às vezes você só precisa terminar outra coisa
O repositório do Chimera não tem distrobox, mas inclui podman, então isso resolve a maior parte
De todo modo, funciona bem, e estou escrevendo este texto agora no Chimera
Algumas pessoas preferem Flatpak, mas eu gosto mais do gerenciamento de pacotes à moda antiga
Para mim, o Flatpak parece pesado e opaco demais, embora eu saiba que opiniões podem variar
O Distrobox definitivamente se encaixa melhor para trabalho no console
Também é uma ferramenta prática para subir sandboxes rápidas e ambientes temporários de desenvolvimento
Arch é apenas uma escolha pessoal; eu poderia ter escolhido Void, Debian ou qualquer outra coisa