systemd di postmarketOS
Baru-baru ini pengembang proyek postmarketOS, diumumkan melalui posting blog berita tentang pengenalan sistemd untuk membangun sistem. Itu alasan utama untuk mengimplementasikan dukungan systemd adalah sulitnya mempertahankan tumpukan inisialisasi berdasarkan OpenRC menghadapi ketergantungan yang semakin besar pada GNOME dan KDE komponen systemd.
Ketersediaan penggunaan systemd sebagai administrator sistem muncul setelah satu tahun bekerja dan pengaturan prototipe menggunakan systemd alih-alih sistem inisialisasi OpenRC telah disiapkan dan tersedia untuk pengujian.
Disebutkan itu Meskipun ada penambahan systemd, dukungan akan terus diberikan membuat bangunan berdasarkan OpenRC di postmarketOS, setidaknya selama sistem ini terus digunakan di Alpine Linux. Opsi untuk memilih OpenRC akan tersedia saat membuat image postmarketOS menggunakan pmbootstrap. Selain itu, OpenRC akan terus digunakan oleh pengembang perakitan yang bekerja dengan shell grafis Sxmo (Simple X Mobile), berdasarkan manajer komposit Sway.
Di sisi lain, dibangun dengan systemd akan tetap didasarkan pada paket dasar Alpine Linux, meskipun distribusi ini tidak memiliki dukungan resmi untuk systemd dan menggunakan perpustakaan Musl C, bukan Glibc C, yang kompatibel dengan systemd. Pengembang postmarketOS menerapkan patch tambahan untuk mengintegrasikan systemd dengan Musl C dan berencana untuk berkolaborasi dengan pengembang systemd untuk menyederhanakan integrasi ini di masa depan.
Tentu saja, ini bukanlah tugas yang mudah, salah satu kendala utama yang kami temui saat kami berkolaborasi lebih erat dengan pengembang KDE dan GNOME adalah mereka mengalami kesulitan dengan tumpukan berbasis OpenRC kami. Agar KDE dan GNOME berfungsi, kami menggunakan banyak polyfill systemd selain OpenRC. Jadi, meskipun secara teknis "kami tidak menggunakan systemd", dalam praktiknya kami telah menggunakan sebagian besar komponennya untuk menjalankan KDE dan GNOME, hanya saja versi komponen tersebut berbeda.
Untuk memastikan fungsionalitas GNOME dan KDE berdasarkan systemd, beberapa lapisan tambahan perlu dipertahankan, dan bekerja tanpa systemd berarti memelihara lapisan ini dengan benar dan menyinkronkannya dengan pengembangan GNOME dan KDE, yang menimbulkan tantangan signifikan dan ketidakpastian dalam pemeliharaan berkelanjutan oleh pengembang.
Selain itu, pengembang menyebutkan hal itu Berbagai lapisan dan paket diimplementasikan untuk memastikan dukungan untuk layanan nama host, pelokalan, dan stempel waktu di postmarketOS. Ini Tatau termasuk penggunaan openrc-settingsd untuk dukungan layanan nama host, eudev sebagai pengganti udev untuk manajemen perangkat, elogind sebagai ganti logind untuk manajemen sesi pengguna, dan buku catatand di tempat jurnald untuk manajemen log dan paket superd digunakan untuk menyediakan fungsionalitas yang mirip dengan «sistemd –pengguna» dan ganti systemd.timer dengan terbangun.
Namun demikian, pemeliharaan dan dukungan yang tepat hanya dijamin untuk openrc-settingsd dan eudev. Proyek seperti elogind, buku catatan dan superd masih memerlukan perbaikan, karena tidak memiliki beberapa fitur yang diperlukan, dan bangun Sudah sekitar satu tahun tidak dilayani. Selain itu, pengembang KDE Plasma Mobile menyatakan minatnya untuk menggunakan systemd-coredumpd untuk menyederhanakan debugging, tetapi menggantinya, kolektor inti, Itu belum menerima pemeliharaan sejak tahun 2020.
Layanan ini diperlukan untuk berbagai fungsi di GNOME dan aplikasi lainnya. Misalnya, D-Bus API yang disediakan oleh diberi nama host, dilokalkan, dan diberi tanggal Ini digunakan di GNOME untuk mengubah pengaturan regional dan zona waktu. Udev diperlukan untuk mengelola perangkat yang terhubung, saat logind, “sistemd –pengguna» dan journald digunakan untuk mengelola sesi pengguna di sesi gnome. Jam GNOME menggunakan systemd.timer untuk fungsinya.
En hal fitur baru yang dapat diimplementasikan dengan build berbasis sistem, termasuk manajemen hak istimewa granular, penggunaan fitur-fitur canggih untuk memastikan keamanan dan mengelola ketergantungan antar layanan, integrasi penuh dengan cgroup, aktivasi soket untuk memulai layanan sesuai kebutuhan (misalnya, CUPS hanya dapat dimulai dengan mengakses port jaringan), dan ketersediaan alat bawaan untuk menganalisis proses boot.
akhirnya jika kamu tertarik untuk mengetahui lebih banyak tentangnya, Anda dapat memeriksa detailnya di link berikut.