systemd nel sistema operativo postmarket
Recentemente il hanno annunciato gli sviluppatori del progetto postmarketOS attraverso un post sul blog le notizie di l'introduzione di systemd alle build del sistema. IL motivo principale per implementare il supporto systemd è la difficoltà di mantenerlo uno stack di inizializzazione basato su OpenRC affronta la crescente dipendenza da GNOME e KDE dei componenti del sistema.
La disponibilità di utilizzare systemd come amministratore di sistema arriva dopo un anno di lavoro ed è stato preparato e reso disponibile per il test un prototipo di configurazione che utilizza systemd al posto del sistema di inizializzazione OpenRC.
Si è detto che Nonostante l'aggiunta di systemd, il supporto continuerà ad essere fornito creazione di build basate su OpenRC in postmarketOS, almeno finché questo sistema continuerà ad essere utilizzato in Alpine Linux. L'opzione per selezionare OpenRC sarà disponibile durante la creazione di immagini postmarketOS utilizzando pmbootstrap. Inoltre, OpenRC continuerà a essere utilizzato dagli sviluppatori di assembly che lavorano con la shell grafica Sxmo (Simple X Mobile), basata sul gestore composito Sway.
D'altra parte, il le build con systemd saranno ancora basate sul pacchetto base Alpine Linux, nonostante questa distribuzione non abbia il supporto ufficiale per systemd e utilizzi la libreria Musl C invece di Glibc C, che è compatibile con systemd. Gli sviluppatori di postmarketOS stanno implementando patch aggiuntive per integrare systemd con Musl C e pianificano di collaborare con gli sviluppatori di systemd per semplificare questa integrazione in futuro.
Naturalmente questo non è un compito facile, uno dei principali ostacoli che incontriamo quando collaboriamo più strettamente con gli sviluppatori KDE e GNOME è che hanno difficoltà con il nostro stack basato su OpenRC. Per far funzionare KDE e GNOME, utilizziamo molti polyfill di sistema oltre a OpenRC. Quindi, anche se tecnicamente "non usiamo systemd", in pratica utilizziamo già gran parte dei suoi componenti per eseguire KDE e GNOME, solo versioni diverse di questi componenti
Per garantire la funzionalità di GNOME e KDE basato su systemd, era necessario mantenere diversi livelli aggiuntivi e lavorare senza systemd significava mantenere questi livelli correttamente e sincronizzarli con lo sviluppo di GNOME e KDE, il che poneva sfide significative e alcune incertezze nella manutenzione continua da parte degli sviluppatori.
Oltre a questo, gli sviluppatori lo menzionano Sono stati implementati vari livelli e pacchetti per garantire il supporto per i servizi di nome host, localizzazione e timestamp in postmarketOS. Il suo To incluso l'uso di openrc-settingsd per il supporto dei servizi dei nomi host, eudev invece di udev per la gestione dei dispositivi, elogind invece di logind per la gestione delle sessioni utente e logbookd al posto di diario per la gestione dei log e il pacchetto superd è stato utilizzato per fornire funzionalità simili a «systemd –utente» e sostituire timer.di.sistema con svegliato.
Tuttavia, la manutenzione e il supporto adeguati sono garantiti solo per openrc-settingsd e eudev. Progetti come elogind, registro e superd necessitano ancora di miglioramenti, in quanto mancano di alcune funzionalità necessarie, e svegliato Non viene revisionata da circa un anno. Inoltre, gli sviluppatori di KDE Plasma Mobile hanno espresso interesse nell'utilizzo systemd-coredumpd per semplificare il debug, ma sostituendolo, corecollettore, Non ha ricevuto manutenzione dal 2020.
Questi servizi sono richiesti per varie funzioni in GNOME e altre applicazioni. Ad esempio, l'API D-Bus fornita da nome host, localizzato e datato Viene utilizzato in GNOME per modificare le impostazioni regionali e del fuso orario. Udev è necessario per gestire i dispositivi connessi, mentre si effettua il login, “systemd –utente» e journald vengono utilizzati per gestire le sessioni utente in gnome-session. GNOME Orologio utilizza timer.di.sistema per le sue funzionalità.
En termini di nuove funzionalità che può essere implementato con build basate su systemd, inclusa la gestione granulare dei privilegi, l'uso di funzionalità avanzate per garantire la sicurezza e gestire le dipendenze tra i servizi, integrazione completa con cgroups, attivazione del socket per avviare i servizi secondo necessità (ad esempio, CUPS può essere avviato solo da accesso alla porta di rete) e la disponibilità di strumenti integrati per analizzare il processo di avvio.
finalmente se lo sei interessati a saperne di più, puoi controllare i dettagli in il seguente collegamento.