sistemuar në postmarketOS
Kohët e fundit, zhvilluesit e projektit postmarketOS, njoftuan përmes një postimi në blog lajmet e futja e systemd për ndërtimin e sistemit. Të arsye parësore për të zbatuar mbështetjen e sistemuar është vështirësia e mbajtjes një pirg inicializimi i bazuar në OpenRC përballet me varësinë në rritje nga GNOME dhe KDE të komponentëve të sistemuar.
Disponueshmëria e përdorimit të systemd si administrator i sistemit vjen pas një viti pune dhe një konfigurim prototip duke përdorur systemd në vend të sistemit të inicializimit OpenRC është përgatitur dhe vënë në dispozicion për testim.
Përmendet se Pavarësisht shtimit të systemd, mbështetja do të vazhdojë të ofrohet krijimi i ndërtimeve bazuar në OpenRC në postmarketOS, të paktën për aq kohë sa ky sistem vazhdon të përdoret në Alpine Linux. Opsioni për të zgjedhur OpenRC do të jetë i disponueshëm kur krijoni imazhe postmarketOS duke përdorur pmbootstrap. Për më tepër, OpenRC do të vazhdojë të përdoret nga zhvilluesit e asamblesë që punojnë me guaskën grafike Sxmo (Simple X Mobile), bazuar në menaxherin e përbërë Sway.
Në anën tjetër, ndërtimet me systemd do të bazohen ende në paketën bazë Alpine Linux, përkundër faktit se kjo shpërndarje nuk ka mbështetje zyrtare për systemd dhe përdor bibliotekën Musl C në vend të Glibc C, e cila është e pajtueshme me systemd. Zhvilluesit e postmarketOS po zbatojnë arna shtesë për të integruar systemd me Musl C dhe planifikojnë të bashkëpunojnë me zhvilluesit systemd për të thjeshtuar këtë integrim në të ardhmen.
Sigurisht, kjo nuk është një detyrë e lehtë, një nga pengesat kryesore që hasim teksa bashkëpunojmë më ngushtë me zhvilluesit e KDE dhe GNOME është se ata kanë vështirësi me stakun tonë të bazuar në OpenRC. Për t'i bërë KDE dhe GNOME të funksionojnë, ne përdorim shumë mbushje të sistemuara përveç OpenRC. Pra, megjithëse teknikisht "ne nuk përdorim systemd", në praktikë ne tashmë përdorim një pjesë të madhe të komponentëve të tij për të ekzekutuar KDE dhe GNOME, vetëm versione të ndryshme të atyre komponentëve
Për të siguruar funksionalitetin e GNOME dhe KDE bazuar në systemd, kërkohej të ruheshin disa shtresa shtesë dhe të punosh pa systemd nënkuptonte mbajtjen e duhur të këtyre shtresave dhe sinkronizimin e tyre me zhvillimin e GNOME dhe KDE, gjë që paraqiste sfida të rëndësishme dhe disa pasiguri në mirëmbajtjen e vazhdueshme nga zhvilluesit.
Përveç kësaj, zhvilluesit e përmendin atë U zbatuan shtresa dhe paketa të ndryshme për të siguruar mbështetje për emrin e hostit, shërbimet e lokalizuara dhe vulën kohore në postmarketOS. T e sajose përfshinte përdorimin e openrc-settingsd për mbështetje për shërbimet e emrit të hostit, eudev në vend të udev për menaxhimin e pajisjes, elogind në vend të hyrjes për menaxhimin e sesioneve të përdoruesit, dhe ditar në vend të ditar për menaxhimin e regjistrave dhe paketa superd u përdor për të ofruar funksionalitet të ngjashëm me «systemd –përdorues» dhe zëvendësoni sistemd.kohëmatësi me u zgjua.
megjithatë, mirëmbajtja dhe mbështetja e duhur garantohet vetëm për openrc-settingsd dhe eudev. Projekte si elogind, ditar dhe superd ende kërkojnë përmirësime, pasi u mungojnë disa veçori të nevojshme, dhe u zgjua Nuk është servisuar për rreth një vit. Për më tepër, zhvilluesit e KDE Plasma Mobile shprehën interes për ta përdorur systemd-coredumpd për të thjeshtuar korrigjimin, por duke e zëvendësuar atë, mbledhës kryesor, Nuk ka marrë mirëmbajtje që nga viti 2020.
Këto shërbime kërkohen për funksione të ndryshme në GNOME dhe aplikacione të tjera. Për shembull, API D-Bus i ofruar nga me emër hosti, lokalizuar dhe datë Përdoret në GNOME për të ndryshuar cilësimet rajonale dhe të zonës kohore. Udev kërkohet të menaxhojë pajisjet e lidhura, ndërsa identifikohet, "systemd –përdorues» dhe journald përdoren për të menaxhuar sesionet e përdoruesve në gnome-session. Ora GNOME përdor sistemd.kohëmatësi për funksionalitetet e tij.
En kushtet e veçorive të reja që mund të zbatohet me ndërtime të bazuara në sistem, duke përfshirë menaxhimin e privilegjeve të hollësishme, përdorimin e veçorive të avancuara për të garantuar sigurinë dhe menaxhimin e varësive midis shërbimeve, integrimin e plotë me cgroups, aktivizimin e prizës për të nisur shërbimet sipas nevojës (p.sh., CUPS mund të fillohet vetëm nga hyrja në portin e rrjetit), dhe disponueshmëria e mjeteve të integruara për të analizuar procesin e nisjes.
më në fund nëse jeni të interesuar të dinë më shumë për të, ju mund të kontrolloni detajet në lidhja e mëposhtme.