systemd no postmarketOS
Recentemente desenvolvedores do projeto postmarketOS, anunciaram através de uma postagem no blog as notícias de a introdução do systemd para compilações do sistema. O Principal motivo para implementar suporte systemd é a dificuldade de manter uma pilha de inicialização baseada em OpenRC enfrentando a crescente dependência do GNOME e KDE dos componentes do systemd.
A disponibilidade de usar o systemd como administrador de sistema surge após um ano de trabalho e uma configuração de protótipo usando o systemd em vez do sistema de inicialização OpenRC foi preparada e disponibilizada para teste.
É mencionado que Apesar da adição do systemd, o suporte continuará a ser fornecido para criando compilações baseadas em OpenRCGenericName no postmarketOS, pelo menos enquanto este sistema continuar a ser usado no Alpine Linux. A opção de selecionar OpenRC estará disponível ao criar imagens postmarketOS usando pmbootstrap. Além disso, o OpenRC continuará a ser usado por desenvolvedores de assembly que trabalham com o shell gráfico Sxmo (Simple X Mobile), baseado no gerenciador de composição Sway.
Por outro lado, o compilações com systemd ainda serão baseadas no pacote Alpine Linux básico, apesar de esta distribuição não ter suporte oficial para systemd e usar a biblioteca Musl C em vez de Glibc C, que é compatível com systemd. Os desenvolvedores do postmarketOS estão implementando patches adicionais para integrar o systemd ao Musl C e planejam colaborar com os desenvolvedores do systemd para simplificar essa integração no futuro.
Claro, esta não é uma tarefa fácil, um dos principais obstáculos que encontramos à medida que colaboramos mais estreitamente com os desenvolvedores do KDE e do GNOME é que eles têm dificuldades com nossa pilha baseada em OpenRC. Para fazer o KDE e o GNOME funcionarem, usamos muitos polyfills do systemd além do OpenRC. Portanto, embora tecnicamente “não utilizemos o systemd”, na prática já utilizamos grande parte de seus componentes para rodar o KDE e o GNOME, apenas versões diferentes desses componentes
Para garantir a funcionalidade do GNOME e KDE baseado no systemd, era necessário manter várias camadas adicionais, e trabalhar sem o systemd significava manter essas camadas adequadamente e sincronizá-las com o desenvolvimento do GNOME e KDE, o que representava desafios significativos e alguma incerteza na manutenção contínua por parte dos desenvolvedores.
Além disso, os desenvolvedores mencionam que Várias camadas e pacotes foram implementados para garantir suporte para serviços de nome de host, localização e carimbo de data/hora no postmarketOS. É Tou incluiu o uso de openrc-settingsd para suporte a serviços de nome de host, eudev em vez de udev para gerenciamento de dispositivos, elogind em vez de logind para gerenciamento de sessão de usuário e diário de bordo em vez de diário para gerenciamento de log e o pacote superd foi usado para fornecer funcionalidade semelhante a «systemd –usuário» e substitua systemd.timer com acordado.
Contudo, manutenção e suporte adequados são garantidos apenas para openrc-settingsd e eudev. Projetos como elogind, diário de bordod e superd ainda requerem melhorias, pois carecem de alguns recursos necessários, e acordado Não é reparado há cerca de um ano. Além disso, os desenvolvedores do KDE Plasma Mobile expressaram interesse em usar systemd-coredumpd para simplificar a depuração, mas substituí-la, coletor principal, Não recebe manutenção desde 2020.
Esses serviços são necessários para diversas funções no GNOME e em outros aplicativos. Por exemplo, a API D-Bus fornecida por com nome de host, local e datado É usado no GNOME para alterar as configurações regionais e de fuso horário. Udev é necessário para gerenciar dispositivos conectados, enquanto logind, “systemd –usuário» e journald são usados para gerenciar sessões de usuário na sessão gnome. O relógio do GNOME usa systemd.timer pelas suas funcionalidades.
En termos de novos recursos que pode ser implementado com compilações baseadas em systemd, incluindo gerenciamento granular de privilégios, uso de recursos avançados para garantir segurança e gerenciar dependências entre serviços, integração total com cgroups, ativação de soquete para iniciar serviços conforme necessário (por exemplo, o CUPS pode ser iniciado apenas por acessando a porta de rede) e a disponibilidade de ferramentas integradas para analisar o processo de inicialização.
finalmente se você está interessado em saber mais sobre isso, você pode verificar os detalhes em o seguinte link.