postmarketOS rendszerben
Nemrégiben a – jelentették be a postmarketOS projekt fejlesztői blogbejegyzésen keresztül a híreket systemd bevezetése rendszerépítésekhez. A elsődleges ok rendszeres támogatás megvalósításához a karbantartás nehézsége alapján készült inicializálási verem Az OpenRC szembesül a GNOME-tól és a KDE-től való növekvő függőséggel rendszerelemek.
A systemd rendszeradminisztrátorként való használata egy évnyi munka után válik elérhetővé, és az OpenRC inicializálási rendszer helyett a systemd-t használó prototípus-beállítás elkészült és tesztelésre elérhetővé vált.
Azt emlegetik A systemd kiegészítése ellenére a támogatás továbbra is biztosított építmények készítése alapján OpenRC postmarketOS-ben, legalább addig, amíg ezt a rendszert továbbra is az Alpine Linuxban használják. Az OpenRC kiválasztásának lehetősége a postmarketOS-képek pmbootstrap használatával történő létrehozásakor lesz elérhető. Ezenkívül az OpenRC-t továbbra is az Sxmo (Simple X Mobile) grafikus héjjal dolgozó, a Sway kompozit kezelőn alapuló összeállítás-fejlesztők fogják használni.
Másrészt a A systemd-vel való buildek továbbra is az Alpine Linux alapcsomagon fognak alapulni, annak ellenére, hogy ez a disztribúció nem támogatja hivatalosan a systemd-t, és a Glibc C helyett a Musl C könyvtárat használja, amely kompatibilis a systemd-vel. A postmarketOS fejlesztői további javításokat vezetnek be, hogy integrálják a rendszert a Musl C-vel, és azt tervezik, hogy együttműködnek a rendszerfejlesztőkkel, hogy a jövőben egyszerűsítsék ezt az integrációt.
Természetesen ez nem könnyű feladat, a KDE és GNOME fejlesztőkkel való szorosabb együttműködés során az egyik fő akadály, amellyel szembesülünk, az, hogy nehézségeik vannak az OpenRC-alapú veremünkkel. Ahhoz, hogy a KDE és a GNOME működjön, az OpenRC mellett sok rendszeres polikitöltést is használunk. Tehát, bár technikailag "nem használjuk a systemd-t", a gyakorlatban már az összetevőinek nagy részét használjuk a KDE és a GNOME futtatásához, csak ezeknek az összetevőknek a különböző verzióit.
A GNOME és a KDE működőképességének biztosítása érdekében A systemd alapján több további réteget kellett karbantartani, a systemd nélküli munka pedig azt jelentette, hogy ezeket a rétegeket megfelelően karbantartották és szinkronizálták a GNOME és KDE fejlesztéssel, ami jelentős kihívásokat és némi bizonytalanságot jelentett a fejlesztők folyamatos karbantartásában.
Ezen kívül a fejlesztők azt is megemlítik Különféle rétegeket és csomagokat valósítottak meg a gazdagépnév, honosított és időbélyegző szolgáltatások támogatásának biztosítása a postmarketOS rendszerben. A Tvagy tartalmazta az openrc-settingsd használatát a gazdagépnév-szolgáltatások támogatásához, az udev helyett az eudev az eszközkezeléshez, az elogind a logid helyett a felhasználói munkamenet-kezeléshez, és logbookd helyett journaln a naplókezeléshez és a superd csomagot használták a "systemd –felhasználó» és cserélje ki systemd.timer a felébredt.
viszont, a megfelelő karbantartás és támogatás csak az openrc-settingsd és az eudev esetében garantált. Olyan projektek, mint az elogind, logbookd és superd még mindig fejlesztésre van szükség, mivel hiányzik néhány szükséges funkció, és felébredt Körülbelül egy éve nem volt szervizelve. Ezenkívül a KDE Plasma Mobile fejlesztői érdeklődést mutattak a használat iránt systemd-coredumpd a hibakeresés egyszerűsítése, de cseréje, maggyűjtő, 2020 óta nem kapott karbantartást.
Ezek a szolgáltatások a GNOME és más alkalmazások különböző funkcióihoz szükségesek. Például a D-Bus API által biztosított hostnamed, localed és timedated A GNOME-ban a regionális és időzóna-beállítások módosítására szolgál. Az Udev-nek kell kezelnie a csatlakoztatott eszközöket, miközben bejelentkezik: "systemd –felhasználó» és a naplód a gnome-session felhasználói munkameneteinek kezelésére szolgál. GNOME Clock használ systemd.timer funkciói miatt.
En új funkciók tekintetében amelyek megvalósíthatók systemd alapú buildekkel, beleértve a részletes jogosultságkezelést, fejlett funkciók használatát a biztonság biztosítására és a szolgáltatások közötti függőségek kezelésére, teljes integrációt a cgroupokkal, socket aktiválást a szolgáltatások igény szerinti elindításához (például a CUPS-t csak hozzáférés a hálózati porthoz), valamint a rendszerindítási folyamat elemzéséhez szükséges beépített eszközök elérhetősége.
végre, ha az vagy érdekelne többet megtudni róla, a részleteket itt ellenőrizheti a következő link.