gesystematiseerd in postmarketOS
Onlangs de ontwikkelaars van het postmarketOS-project aangekondigd via een blogpost het nieuws van de introductie van systemd tot systeembouw. De belangrijkste reden om systeemondersteuning te implementeren is de moeilijkheid van het volhouden een initialisatiestapel gebaseerd op OpenRC wordt geconfronteerd met de groeiende afhankelijkheid van GNOME en KDE van systeemcomponenten.
De beschikbaarheid van het gebruik van systemd als systeembeheerder komt na een jaar werken en een prototype-opstelling met systemd in plaats van het OpenRC-initialisatiesysteem is voorbereid en beschikbaar gesteld voor testen.
Er wordt gezegd dat Ondanks de toevoeging van systemd blijft de ondersteuning geboden builds maken op basis van OpenRC in postmarketOS, tenminste zolang dit systeem in Alpine Linux wordt gebruikt. De optie om OpenRC te selecteren zal beschikbaar zijn bij het maken van postmarketOS-images met pmbootstrap. Bovendien zal OpenRC gebruikt blijven worden door assemblageontwikkelaars die werken met de grafische shell Sxmo (Simple X Mobile), gebaseerd op de Sway-composietmanager.
Aan de andere kant, de builds met systemd zullen nog steeds gebaseerd zijn op het basis Alpine Linux-pakket, ondanks het feit dat deze distributie geen officiële ondersteuning biedt voor systemd en de Musl C-bibliotheek gebruikt in plaats van Glibc C, die compatibel is met systemd. De postmarketOS-ontwikkelaars implementeren aanvullende patches om systemd te integreren met Musl C en zijn van plan samen te werken met systemd-ontwikkelaars om deze integratie in de toekomst te vereenvoudigen.
Natuurlijk is dit geen gemakkelijke taak; een van de belangrijkste obstakels die we tegenkomen als we nauwer samenwerken met KDE- en GNOME-ontwikkelaars is dat ze problemen hebben met onze op OpenRC gebaseerde stapel. Om KDE en GNOME te laten werken, gebruiken we naast OpenRC veel systemd polyfills. Dus hoewel technisch gezien "we systemd niet gebruiken", gebruiken we in de praktijk al een groot deel van de componenten om KDE en GNOME uit te voeren, alleen verschillende versies van die componenten
Om de functionaliteit van GNOME en KDE te garanderen gebaseerd op systemd moesten verschillende extra lagen worden onderhouden, en werken zonder systemd betekende dat deze lagen op de juiste manier moesten worden onderhouden en gesynchroniseerd met de GNOME- en KDE-ontwikkeling, wat aanzienlijke uitdagingen en enige onzekerheid met zich meebracht bij het voortdurende onderhoud door de ontwikkelaars.
Daarnaast vermelden de ontwikkelaars dat Er zijn verschillende lagen en pakketten geïmplementeerd om ondersteuning te garanderen voor hostnaam-, gelokaliseerde en tijdstempelservices in postmarketOS. Het is tof omvatte het gebruik van openrc-settingsd voor ondersteuning voor hostnaamservices, eudev in plaats van udev voor apparaatbeheer, elogind in plaats van logind voor gebruikerssessiebeheer, en gelogd in plaats van journaal voor logbeheer en het superd-pakket werd gebruikt om functionaliteit te bieden die vergelijkbaar is met «systemd –gebruiker» en vervangen systemd.timer met ontwaakt.
Echter, wordt goed onderhoud en ondersteuning alleen gegarandeerd voor openrc-settingsd en eudev. Projecten zoals elogind, logboek en superd nog steeds verbeteringen vereisen, omdat ze enkele noodzakelijke functies missen, en wakker Er is al een jaar geen onderhoud meer aan gedaan. Bovendien toonden KDE Plasma Mobile-ontwikkelaars interesse in het gebruik ervan systemd-coredumpd om het debuggen te vereenvoudigen, maar het te vervangen, kernverzamelaar, Sinds 2020 heeft het geen onderhoud meer gehad.
Deze services zijn vereist voor verschillende functies in GNOME en andere toepassingen. De D-Bus API van bijvoorbeeld hostnaam, gelokaliseerd en getimed Het wordt in GNOME gebruikt om regionale en tijdzone-instellingen te wijzigen. Udev is vereist om aangesloten apparaten te beheren, terwijl u inlogt, “systemd –gebruiker» en journald worden gebruikt om gebruikerssessies in gnome-sessie te beheren. GNOME Klok gebruikt systemd.timer vanwege zijn functionaliteiten.
En termen van nieuwe functies die kunnen worden geïmplementeerd met op systemd gebaseerde builds, inclusief granulair privilegebeheer, gebruik van geavanceerde functies om de veiligheid te garanderen en afhankelijkheden tussen services te beheren, volledige integratie met cgroups, socketactivering om services te starten wanneer dat nodig is (CUPS kan bijvoorbeeld alleen worden gestart door toegang tot de netwerkpoort) en de beschikbaarheid van ingebouwde tools om het opstartproces te analyseren.
eindelijk als je bent geïnteresseerd om er meer over te weten, kunt u de details inchecken de volgende link.