systemd в postmarketOS
Наскоро разработчиците на проекта postmarketOS, обявиха чрез публикация в блога новината за въвеждането на systemd към системните компилации. The основна причина за внедряване на поддръжка на systemd е трудността за поддържане инициализиращ стек, базиран на OpenRC изправен пред нарастващата зависимост от GNOME и KDE на systemd компоненти.
Наличието на използване на systemd като системен администратор идва след една година работа и настройка на прототип, използваща systemd вместо системата за инициализация OpenRC, беше подготвена и предоставена за тестване.
Споменава се, че Въпреки добавянето на systemd, поддръжката ще продължи да се предоставя създаване на компилации въз основа на OpenRC в postmarketOS, поне докато тази система продължава да се използва в Alpine Linux. Опцията за избор на OpenRC ще бъде налична при създаване на postmarketOS изображения с помощта на pmbootstrap. Освен това OpenRC ще продължи да се използва от разработчиците на асемблиране, работещи с графичната обвивка Sxmo (Simple X Mobile), базирана на композитния мениджър на Sway.
От друга страна, компилациите със systemd все още ще се базират на базовия пакет Alpine Linux, въпреки факта, че тази дистрибуция няма официална поддръжка за systemd и използва библиотеката Musl C вместо Glibc C, която е съвместима със systemd. Разработчиците на postmarketOS внедряват допълнителни пачове за интегриране на systemd с Musl C и планират да си сътрудничат с разработчиците на systemd, за да опростят тази интеграция в бъдеще.
Разбира се, това не е лесна задача, една от основните пречки, които срещаме, докато си сътрудничим по-тясно с разработчиците на KDE и GNOME, е, че те имат затруднения с нашия стек, базиран на OpenRC. За да накараме KDE и GNOME да работят, ние използваме много systemd polyfills в допълнение към OpenRC. Така че, въпреки че технически „ние не използваме systemd“, на практика ние вече използваме голяма част от неговите компоненти за стартиране на KDE и GNOME, просто различни версии на тези компоненти
За да се гарантира функционалността на GNOME и KDE базирано на systemd, беше необходимо да се поддържат няколко допълнителни слоя и работата без systemd означаваше поддържането на тези слоеве правилно и синхронизирането им с разработката на GNOME и KDE, което създаде значителни предизвикателства и известна несигурност при текущата поддръжка от разработчиците.
В допълнение към това разработчиците споменават това Бяха внедрени различни слоеве и пакети за да се осигури поддръжка за име на хост, локализирани услуги и услуги за клеймо за време в postmarketOS. Това е Тили включва използването на openrc-settingsd за поддръжка на услуги за имена на хостове, eudev вместо udev за управление на устройства, elogind вместо logind за управление на потребителски сесии и бордови дневникd вместо журнал за управление на регистрационни файлове и пакетът superd беше използван за осигуряване на функционалност, подобна на «systemd – потребител» и заменете systemd.timer с събуден.
Обаче, правилната поддръжка и поддръжка са гарантирани само за openrc-settingsd и eudev. Проекти като elogind, logbookd и superd все още изискват подобрения, тъй като им липсват някои необходими функции и събуден Не е обслужван от около година. Освен това разработчиците на KDE Plasma Mobile изразиха интерес към използването systemd-coredumpd за опростяване на отстраняването на грешки, но замяната му, corecollector, Не е получавал поддръжка от 2020 г.
Тези услуги са необходими за различни функции в GNOME и други приложения. Например D-Bus API, предоставен от с име на хост, локализиран и с дата Използва се в GNOME за промяна на регионалните настройки и настройките за часова зона. Udev е необходим за управление на свързани устройства, докато влизате, “systemd – потребител» и journald се използват за управление на потребителски сесии в gnome-session. GNOME Clock използва systemd.timer за неговите функционалности.
En условия на нови функции които могат да бъдат внедрени с компилации, базирани на systemd, включително гранулирано управление на привилегии, използване на разширени функции за осигуряване на сигурност и управление на зависимости между услуги, пълна интеграция с cgroups, активиране на сокет за стартиране на услуги, ако е необходимо (например, CUPS може да се стартира само от достъп до мрежовия порт) и наличието на вградени инструменти за анализ на процеса на зареждане.
най-накрая, ако сте заинтересовани да научите повече за това, можете да проверите подробностите в следната връзка.