Insights sobre por que o Hyperbola GNU / Linux está se transformando no Hyperbola BSD

16 de janeiro de 2020

No final de dezembro de 2019, Hyperbola anunciou que eles fariam grandes mudanças em seu projeto. Eles decidiram abandonar o kernel do Linux em favor da bifurcação do kernel do OpenBSD. Este anúncio só veio meses depois que o Projeto Trident anunciou que eles estavam indo na direção oposta (de BSD para Linux).

A Hyperbola também planeja substituir todos os softwares que não são compatíveis com GPL v3 por novas versões.

Para obter mais informações sobre o futuro de seu novo projeto, entrevistei Andre, cofundador da Hyperbola.

Por que o Hyperbola GNU/Linux se tornou o Hyperbola BSD

Hyperbola Linux BSD

É FOSS: em seu anúncio, você afirma que o kernel do Linux está avançando rapidamente por um caminho instável. Você poderia explicar o que quer dizer com isso?

Andre: Em primeiro lugar, está incluindo a adaptação de recursos DRM como HDCP (Proteção de conteúdo digital de largura de banda alta). Atualmente existe uma opção para desativá-lo no momento da compilação, no entanto, não há uma política que nos garanta que será opcional para sempre.

Historicamente, alguns recursos começaram como opcionais até atingirem a funcionalidade total. Então eles se tornaram forçados e difíceis de remendar. Mesmo que isso não aconteça no caso do HDCP, continuamos cautelosos sobre tais implementações.

Outra das razões é que o kernel do Linux não está mais obtendo o endurecimento adequado. Grsecurity parou de oferecer patches públicos há vários anos, e dependíamos disso para a segurança do nosso sistema. Embora pudéssemos usar seus patches ainda para uma assinatura muito cara, a assinatura seria encerrada se optássemos por tornar esses patches públicos.

Essas restrições vão contra os princípios FSDG que exigem que forneçamos o código-fonte completo, desbloqueado e irrestrito, aos nossos usuários.

KSPP é um projeto que pretendia fazer o upstream de Grsec no kernel, mas até agora não chegou perto de atingir o nível Grsec/PaX de endurecimento do kernel. Também não houve muitos desenvolvimentos recentes, o que nos leva a acreditar que agora é um projeto inativo em sua maior parte.

Por último, o interesse em permitir módulos Rust no kernel é um problema para nós, devido às restrições de marca registrada Rust que nos impedem de aplicar patches em nossa distribuição sem permissão expressa. Nós corrigimos para remover software não-livre, arquivos não licenciados e melhorias para a privacidade do usuário em qualquer lugar que seja aplicável. Também esperamos que nossos usuários possam reutilizar nosso código sem quaisquer restrições adicionais ou permissão necessária.

Em parte, também é por isso que usamos o UXP, um mecanismo de navegador e kit de ferramentas de aplicativo totalmente gratuito sem Rust, para nossos aplicativos de e-mail e navegador.

Devido a essas restrições e à preocupação de que em algum momento isso possa se tornar uma dependência forçada de tempo de compilação para o kernel, precisamos de outra opção.

É FOSS: Você também disse no anúncio que faria um fork do kernel do OpenBSD. Por que você escolheu o canil OpenBSD em vez do FreeBSD, o kernel DragonflyBSD ou o kernel MidnightBSD?

Andre: OpenBSD foi escolhido como nossa base para hard-bifurcação porque é um sistema que sempre teve código de qualidade e segurança em mente.

Algumas de suas ideias que nos interessaram muito foram as novas chamadas de sistema, incluindo promessa e revelação, que adiciona proteção adicional ao espaço do usuário e a remoção da ferramenta de aplicação de políticas do sistema systrace.

Eles também são conhecidos por Xenocara e LibreSSL, ambos os quais já estávamos usando após portá-los para GNU/Linux-libre. Descobrimos que eles são bem escritos e geralmente mais estáveis que o Xorg/OpenSSL, respectivamente.

Nenhuma das outras implementações BSD que conhecemos tem esse nível de segurança. Também sabíamos que LibertyBSD está trabalhando na liberação do kernel do OpenBSD, o que nos permitiu usar seus patches para iniciar o desenvolvimento inicial.

É FOSS: por que bifurcar o kernel em primeiro lugar? Como você manterá o novo kernel atualizado com suporte de hardware mais recente?

Andre: O kernel é uma das partes mais importantes de qualquer sistema operacional e achamos que é fundamental começar com uma base firme para o futuro.

Para a primeira versão, planejamos manter a sincronização com o OpenBSD onde for possível. Em versões futuras, podemos adaptar o código de outros BSDs e até mesmo do kernel do Linux onde necessário para manter o suporte ao hardware e recursos.

Estamos trabalhando em coordenação com o Grupo Libreware (nosso representante para atividades comerciais) e temos planos de abrir nossa fundação em breve.

Isso ajudará a sustentar o desenvolvimento, contratar futuros desenvolvedores e encorajar novos entusiastas para suporte a hardware e código mais recentes. Sabemos que a remoção de bolhas não é suficiente porque é uma mitigação, não uma solução para nós. Por isso, precisamos melhorar nossa estrutura e ir para a próxima fase de desenvolvimento de nossos projetos.

É FOSS: Você declara que planeja substituir as partes do kernel e do espaço do usuário do OpenBSD que não são compatíveis com a GPL ou não são livres. Qual porcentagem do código cai na zona não GPL?

Andre: É cerca de 20% no kernel do OpenBSD e no espaço do usuário.

Na maioria das vezes, as peças licenciadas não compatíveis com GPL estão sob a licença BSD Original, às vezes chamada de licença BSD de 4 cláusulas que contém uma falha séria: a odiosa cláusula de publicidade BSD. Não é fatal, mas causa problemas práticos para nós porque gera incompatibilidade com nosso código e desenvolvimento futuro sob GPLv3 e LGPLv3.

Os arquivos não-livres no OpenBSD incluem arquivos sem um cabeçalho de licença apropriado ou sem uma licença na pasta que contém um determinado componente.

Se esses arquivos não contiverem uma licença para dar aos usuários as quatro liberdades essenciais ou se não tiver sido explicitamente adicionado no domínio público, não é software livre. Alguns desenvolvedores pensam que o código sem licença é automaticamente de domínio público. Isso não é verdade sob a lei de direitos autorais de hoje; em vez disso, todos os trabalhos com direitos autorais são protegidos por direitos autorais por padrão.

Os blobs de firmware não-livre no OpenBSD incluem vários firmwares de hardware. Esses blobs de firmware também ocorrem no kernel do Linux e foram removidos manualmente pelo projeto Linux-libre por anos após cada novo lançamento do kernel.

Eles estão normalmente na forma de um binário codificado em hexadecimal e são fornecidos aos desenvolvedores do kernel sem fonte para fornecer suporte para hardware de design proprietário. Esses blobs podem conter vulnerabilidades ou backdoors, além de violar sua liberdade, mas ninguém saberia, já que o código-fonte não está disponível para eles. Eles devem ser removidos para respeitar a liberdade do usuário.

É FOSS: eu estava conversando com alguém sobre HyperbolaBSD e eles mencionaram HardenedBSD. Você já considerou HardenedBSD?

Andre: Nós examinamos o HardenedBSD, mas ele foi derivado do FreeBSD. O FreeBSD tem uma base de código muito maior. Embora HardenedBSD seja provavelmente um bom projeto, exigiria muito mais esforço para desbloquear e verificar as licenças de todos os arquivos.

Decidimos usar o OpenBSD como base para fazer um fork do FreeBSD devido ao seu compromisso anterior com a qualidade do código, segurança e minimalismo.

É FOSS: você mencionou UXP (ou Plataforma Unificada XUL). Parece que você está usando o fork da Moonchild da base de código pré-Servo Mozilla para criar um pacote de aplicativos para a web. É mais ou menos do tamanho dele?

Andre: Sim. Nossa decisão de usar UXP foi por vários motivos. Já estávamos renomeando o Firefox como Iceweasel por vários anos para remover DRM, desabilitar a telemetria e aplicar opções de privacidade predefinidas. No entanto, ficou cada vez mais difícil para nós manter quando a Mozilla continuou adicionando anti-recursos, removendo a personalização do usuário e quebrando rapidamente nosso rebranding e patches de privacidade.

Depois do FF52, todas as extensões XUL foram removidas em favor do WebExt e o Rust tornou-se obrigatório em tempo de compilação. Mantemos vários addons XUL para melhorar a privacidade/segurança do usuário, que não funcionariam mais no novo mecanismo. Também estávamos preocupados que os addons WebExt limitados por recursos estivessem introduzindo problemas de privacidade adicionais. Por exemplo. cada complemento WebExt instalado contém um UUID que pode ser usado para identificar os usuários de forma única e precisa (consulte Bugzilla 1372288).

Depois de alguma pesquisa, descobrimos o UXP e que ele estava regularmente atualizando as correções de segurança sem apressar a implementação de novos recursos. Eles já haviam desativado a telemetria no kit de ferramentas e continuam comprometidos em excluir tudo isso da base de código.

Sabíamos que isso estava bem alinhado com nossos objetivos, mas ainda precisávamos aplicar alguns patches para ajustar as configurações de privacidade e remover DRM. Portanto, começamos a criar nossos próprios aplicativos com base no kit de ferramentas.

Isso nos permitiu ir muito além do rebranding/desblobbing básico, como fazíamos antes, e criar nossos próprios aplicativos XUL totalmente personalizados. Atualmente, mantemos Iceweasel-UXP, Icedove-UXP e Iceape-UXP, além de compartilhar melhorias do kit de ferramentas de volta ao UXP.

É FOSS: Em uma postagem no fórum, percebi menções de HyperRC, HyperBLibC e hyperman. Essas bifurcações ou reescritas das ferramentas BSD atuais são compatíveis com GPL?

André: São bifurcações de projetos existentes.

Hyperman é um fork do nosso gerenciador de pacotes atual, pacman. Como o pacman não funciona atualmente no BSD, e o suporte mínimo que tinha no passado foi removido nas versões recentes, um fork foi necessário. O Hyperman já tem uma implementação de trabalho usando LibreSSL e suporte BSD.

HyperRC será uma versão corrigida do OpenRC init. HyperBLibC será um fork do BSD LibC.

É FOSS: desde o início dos tempos, o Linux defendeu a licença GPL e o BSD defendeu a licença BSD. Agora, você está trabalhando para criar um BSD com licença GPL. Como você responderia às pessoas da comunidade BSD que não concordam com essa mudança?

Andre: Estamos cientes de que existem divergências entre o mundo GPL e BSD. Existem até mesmo desacordos sobre chamar nossa distribuição anterior de GNU/Linux ao invés de simplesmente Linux, uma vez que a última definição ignora que o espaço de usuário GNU foi criado em 1984, vários anos antes do kernel Linux ser criado por Linus Torvalds. Foram os dois softwares diferentes combinados que compõem um sistema completo.

Algumas das principais diferenças do BSD é que a GPL exige que nosso código-fonte seja tornado público, incluindo versões futuras, e que só pode ser usado em conjunto com arquivos licenciados compatíveis. Os sistemas BSD não precisam compartilhar seu código-fonte publicamente e podem se agrupar com várias licenças e software não-livre sem restrição.

Como apoiamos fortemente o Movimento do Software Livre e desejamos que nosso código futuro permaneça sempre no espaço público, escolhemos a GPL.

É FOSS: eu sei que neste momento você está apenas começando o processo, mas você tem alguma ideia de quem pode ter uma versão utilizável do HyperbolaBSD disponível?

Andre: Esperamos ter uma versão alfa pronta em 2021 (Q3) para os testes iniciais.

É FOSS: por quanto tempo você continuará a oferecer suporte à versão Linux atual do Hyperbola? Será fácil para os usuários atuais mudar para?

Andre: Conforme nosso anúncio, continuaremos a oferecer suporte ao Hyperbola GNU/Linux-libre até 2022 (quarto trimestre). Esperamos que haja alguma dificuldade na migração devido às mudanças na ABI, mas iremos preparar um anúncio e informações em nosso wiki assim que estiver pronto.

É FOSS: Se alguém estiver interessado em ajudá-lo a trabalhar no HyperbolaBSD, como eles podem fazer isso? Que tipo de experiência você estaria procurando?

André: Quem tiver interesse e puder aprender é bem-vindo. Precisamos de programadores C e usuários interessados em melhorar a segurança e a privacidade do software. Os desenvolvedores precisam seguir os princípios FSDG de desenvolvimento de software livre, bem como o princípio YAGNI, o que significa que implementaremos novos recursos apenas quando precisarmos deles.

Os usuários podem bifurcar seu repositório git e enviar patches para inclusão.

É FOSS: você tem planos de oferecer suporte ao ZFS? Quais sistemas de arquivos você suportará?

Andre: ZFS o suporte não está planejado atualmente, porque usa a Licença Comum de Desenvolvimento e Distribuição, versão 1.0 (CDDL). Esta licença é incompatível com todas as versões da GNU General Public License (GPL).

Seria possível escrever um novo código sob GPLv3 e lançá-lo com um novo nome (por exemplo, HyperZFS), no entanto, não há decisão oficial de incluir o código de compatibilidade do ZFS no HyperbolaBSD no momento.

Temos planos de portar BTRFS, JFS2, CHFS do NetBSD, HAMMER/HAMMER2 do DragonFlyBSD e JFFS2 do kernel do Linux, todos com licenças compatíveis com GPLv3. A longo prazo, também podemos oferecer suporte a Ext4, F2FS, ReiserFS e Reiser4, mas eles precisarão ser reescritos por serem licenciados exclusivamente sob GPLv2, que não permite o uso com GPLv3. Todos esses sistemas de arquivos exigirão testes de desenvolvimento e estabilidade, portanto, estarão em versões posteriores do HyperbolaBSD e não em nossa (s) versão (ões) inicial (is) estável (s).

Gostaria de agradecer a Andre por responder minhas perguntas e por revelar mais sobre o futuro do HyperbolaBSD.

O que você acha da mudança do Hyperbola para um kernel BSD? O que você acha de um BSD sendo lançado sob a GPL? Por favor, deixe-nos saber nos comentários abaixo.

Se você achou este artigo interessante, reserve um minuto para compartilhá-lo nas redes sociais, Hacker News ou Reddit.

Confira também a versão original desse post em inglês
Esse post foi originalmente escrito por John Paul e publicado no site itsfoss.com. Tradução sujeita a revisão.

Insights into Why Hyperbola GNU/Linux is Turning into Hyperbola BSD

Propaganda
Blog Comments powered by Disqus.
Propaganda