systemd sa postmarketOS
Kamakailan lamang ang mga developer ng proyektong postmarketOS, inihayag sa pamamagitan ng isang blog post ang balita ng ang pagpapakilala ng systemd sa mga system build. Ang pangunahing dahilan upang ipatupad ang systemd support ang hirap i-maintain isang initialization stack batay sa Ang OpenRC ay nahaharap sa lumalaking pag-asa sa GNOME at KDE ng mga bahagi ng systemd.
Ang pagkakaroon ng paggamit ng systemd bilang isang system administrator ay darating pagkatapos ng isang taon ng trabaho at isang prototype setup gamit ang systemd sa halip na ang OpenRC initialization system ay inihanda at ginawang available para sa pagsubok.
Nabanggit na Sa kabila ng pagdaragdag ng systemd, patuloy na ibibigay ang suporta paglikha ng mga build batay sa OpenRC sa postmarketOS, hindi bababa sa hangga't ang sistemang ito ay patuloy na ginagamit sa Alpine Linux. Ang opsyon na piliin ang OpenRC ay magiging available kapag gumagawa ng mga postmarketOS na imahe gamit ang pmbootstrap. Bukod pa rito, ang OpenRC ay patuloy na gagamitin ng mga developer ng assembly na nagtatrabaho sa Sxmo (Simple X Mobile) graphical shell, batay sa Sway composite manager.
Sa kabilang banda, ang ang mga build gamit ang systemd ay ibabatay pa rin sa base na Alpine Linux package, sa kabila ng katotohanan na ang pamamahagi na ito ay walang opisyal na suporta para sa systemd at ginagamit ang Musl C library sa halip na Glibc C, na tugma sa systemd. Ang mga postmarketOS developer ay nagpapatupad ng mga karagdagang patch upang isama ang systemd sa Musl C at planong makipagtulungan sa mga systemd developer upang pasimplehin ang pagsasamang ito sa hinaharap.
Siyempre, hindi ito madaling gawain, isa sa mga pangunahing hadlang na nararanasan namin habang nakikipagtulungan kami nang mas malapit sa mga developer ng KDE at GNOME ay ang pagkakaroon nila ng mga problema sa aming OpenRC-based na stack. Para gumana ang KDE at GNOME, gumagamit kami ng maraming systemd polyfill bilang karagdagan sa OpenRC. Kaya, bagama't teknikal na "hindi kami gumagamit ng systemd", sa pagsasanay ay gumagamit na kami ng malaking bahagi ng mga bahagi nito upang patakbuhin ang KDE at GNOME, iba't ibang bersyon lamang ng mga bahaging iyon.
Upang matiyak ang functionality ng GNOME at KDE batay sa systemd, ilang karagdagang mga layer ang kailangang mapanatili, at ang pagtatrabaho nang walang systemd ay nangangahulugan ng pagpapanatili ng mga layer na ito nang maayos at pag-synchronize ng mga ito sa GNOME at KDE development, na nagdulot ng malalaking hamon at ilang kawalan ng katiyakan sa patuloy na pagpapanatili ng mga developer.
Bilang karagdagan dito, binanggit iyon ng mga developer Ang iba't ibang mga layer at pakete ay ipinatupad upang matiyak ang suporta para sa hostname, localized, at mga serbisyo ng timestamp sa postmarketOS. Ang To kasama ang paggamit ng openrc-settingsd para sa suporta para sa mga serbisyo ng hostname, eudev sa halip na udev para sa pamamahala ng device, elogind sa halip na logind para sa pamamahala ng session ng user, at logbookd sa halip ng Talaarawan para sa pamamahala ng log at ang superd package ay ginamit upang magbigay ng pag-andar na katulad ng «systemd –user»at palitan systemd.timer sa nagising.
Gayunman, ang wastong pagpapanatili at suporta ay ginagarantiyahan lamang para sa openrc-settingsd at eudev. Mga proyekto tulad ng elogind, logbookd at superd nangangailangan pa rin ng mga pagpapabuti, dahil kulang sila ng ilang kinakailangang feature, at nagising Halos isang taon na itong hindi naseserbisyuhan. Bilang karagdagan, ang mga developer ng KDE Plasma Mobile ay nagpahayag ng interes sa paggamit systemd-coredumpd upang pasimplehin ang pag-debug, ngunit palitan ito, corecollector, Hindi ito nakatanggap ng maintenance mula noong 2020.
Ang mga serbisyong ito ay kinakailangan para sa iba't ibang mga function sa GNOME at iba pang mga application. Halimbawa, ang D-Bus API na ibinigay ni hostname, naka-local at na-time Ginagamit ito sa GNOME upang baguhin ang mga setting ng rehiyon at time zone. Kinakailangan ang Udev na pamahalaan ang mga konektadong device, habang nag-login, “systemd –user» at journald ay ginagamit upang pamahalaan ang mga session ng user sa gnome-session. Ginagamit ng GNOME Clock systemd.timer para sa mga pag-andar nito.
En mga tuntunin ng mga bagong tampok na maaaring ipatupad gamit ang systemd-based na mga build, kabilang ang granular privilege management, paggamit ng mga advanced na feature para matiyak ang seguridad at pamahalaan ang mga dependency sa pagitan ng mga serbisyo, ganap na pagsasama sa mga cgroup, socket activation upang simulan ang mga serbisyo kung kinakailangan (hal. halimbawa, CUPS ay maaari lamang simulan sa pamamagitan ng pag-access sa port ng network), at ang pagkakaroon ng mga built-in na tool upang pag-aralan ang proseso ng boot.
sa wakas kung ikaw nga interesadong malaman ang higit pa tungkol dito, maaari mong suriin ang mga detalye sa ang sumusunod na link.