Systemd vine la postmarketOS pentru a garanta funcționalitatea GNOME și KDE

systemd în postmarketOS

systemd în postmarketOS

Recent, au anunțat dezvoltatorii proiectului postmarketOS printr - o postare pe blog vestea introducerea systemd la construirea sistemului. The motiv primar pentru a implementa suport systemd este dificultatea de a menține o stivă de inițializare bazată pe OpenRC se confruntă cu dependența tot mai mare de GNOME și KDE a componentelor systemd.

Disponibilitatea utilizării systemd ca administrator de sistem vine după un an de muncă și a fost pregătită și pusă la dispoziție pentru testare o configurare prototip folosind systemd în loc de sistemul de inițializare OpenRC.

Se menționează că În ciuda adăugării sistemului systemd, asistența va continua să fie asigurată creând construcții bazate pe OpenRC în postmarketOS, cel puțin atâta timp cât acest sistem continuă să fie utilizat în Alpine Linux. Opțiunea de a selecta OpenRC va fi disponibilă atunci când se creează imagini postmarketOS folosind pmbootstrap. În plus, OpenRC va continua să fie utilizat de dezvoltatorii de asamblare care lucrează cu shell-ul grafic Sxmo (Simple X Mobile), bazat pe managerul compozit Sway.

Pe de altă parte, build-urile cu systemd se vor baza în continuare pe pachetul de bază Alpine Linux, în ciuda faptului că această distribuție nu are suport oficial pentru systemd și folosește biblioteca Musl C în loc de Glibc C, care este compatibil cu systemd. Dezvoltatorii postmarketOS implementează patch-uri suplimentare pentru a integra systemd cu Musl C și intenționează să colaboreze cu dezvoltatorii systemd pentru a simplifica această integrare în viitor.

Desigur, aceasta nu este o sarcină ușoară, unul dintre principalele obstacole pe care le întâlnim pe măsură ce colaborăm mai strâns cu dezvoltatorii KDE și GNOME este că au dificultăți cu stiva noastră bazată pe OpenRC. Pentru a face KDE și GNOME să funcționeze, folosim multe polyfill-uri systemd pe lângă OpenRC. Deci, deși din punct de vedere tehnic „nu folosim systemd”, în practică folosim deja o mare parte din componentele sale pentru a rula KDE și GNOME, doar versiuni diferite ale acelor componente.

Pentru a asigura funcționalitatea GNOME și KDE pe baza systemd, trebuiau menținute mai multe straturi suplimentare, iar lucrul fără systemd a însemnat menținerea corectă a acestor straturi și sincronizarea lor cu dezvoltarea GNOME și KDE, ceea ce a reprezentat provocări semnificative și o anumită incertitudine în întreținerea continuă de către dezvoltatori.

În plus, dezvoltatorii menționează că Au fost implementate diverse straturi și pachete pentru a asigura suport pentru serviciile de nume de gazdă, localizate și marcare temporală în postmarketOS. Este Tsau a inclus utilizarea openrc-settingsd pentru suport pentru serviciile de nume de gazdă, eudev în loc de udev pentru gestionarea dispozitivelor, elogind în loc de logind pentru gestionarea sesiunilor de utilizator și jurnald în loc de jurnal pentru gestionarea jurnalelor și pachetul superd a fost folosit pentru a oferi funcționalități similare cu «systemd – utilizator» și înlocuiți systemd.timer cu trezit.

Totuși, întreținerea și asistența corespunzătoare sunt garantate numai pentru openrc-settingsd și eudev. Proiecte precum elogind, jurnald și superd necesită încă îmbunătățiri, deoarece le lipsesc unele caracteristici necesare și trezit Nu a fost întreținut de aproximativ un an. În plus, dezvoltatorii KDE Plasma Mobile și-au exprimat interesul pentru utilizare systemd-coredumpd pentru a simplifica depanarea, dar înlocuirea acesteia, corecollector, Nu a mai primit întreținere din 2020.

Aceste servicii sunt necesare pentru diferite funcții din GNOME și din alte aplicații. De exemplu, API-ul D-Bus furnizat de denumit gazdă, localizat și datat Este folosit în GNOME pentru a modifica setările regionale și ale fusului orar. Udev este necesar pentru a gestiona dispozitivele conectate, în timp ce vă conectați, „systemd – utilizator» și journald sunt folosite pentru a gestiona sesiunile utilizatorilor în gnome-session. Ceasul GNOME folosește systemd.timer pentru funcționalitățile sale.

En termeni de funcții noi care pot fi implementate cu versiuni bazate pe systemd, inclusiv gestionarea granulară a privilegiilor, utilizarea caracteristicilor avansate pentru a asigura securitatea și gestionarea dependențelor dintre servicii, integrare completă cu cgroups, activare socket pentru a porni serviciile după cum este necesar (de exemplu, CUPS poate fi pornit numai de către accesarea portului de rețea) și disponibilitatea instrumentelor încorporate pentru a analiza procesul de pornire.

in sfarsit daca esti interesat să afle mai multe despre asta, puteți verifica detaliile în următorul link.