systemd 251 jest już z nami, aby kontynuować rozwój tego „zestawu podstawowych elementów konstrukcyjnych dla systemu Linux”, który jest również określany jako menedżer systemu lub framework systemowy, w zależności od tego, gdzie na to spojrzysz. Z tej okazji znajdujemy kilka ważnych wiadomości, które mogą prowadzić do ważnych zmian w przyszłości, więc chodźmy z nimi.
Po pierwsze, domyślna wersja C została zmieniona z C89 na C11 z rozszerzeniami GNU (GNU11), chociaż nagłówki API nadal są ograniczone do najstarszej wersji (89). Ta zmiana może być motywowana faktem, że podążamy śladami jądra Linuksa , projektu, który rozważał również przejście na C11 ze względu na ograniczenia, które wprowadza C89. Niektórzy powiedzą, że prawdziwa przyszłość należy do Rusta , ale tutaj będziemy zbyt ostrożni.
Komponent systemd-sysupdate został dołączony eksperymentalnie i jest dziełem rozpoczętym zeszłego lata przez Red Hata i głównych programistów systemd. Jest to mechanizm zdolny (lub przynajmniej przeznaczony do) automatycznego wykrywania, pobierania i instalowania aktualizacji instalacji hosta, obrazów kontenerów, przenośnych obrazów usług i innych składników.
Wszystkie obsługiwane jądra zaczynające się od systemd 251 będą szyfrować dane wyjściowe instrukcji RdRand (lub innych rozszerzeń ISA do randomizacji procesora) przy wczesnym uruchomieniu, co ma dwie konsekwencje. Po pierwsze, nawet jeśli `/dev/urandom’ nie jest zainicjowany, wciąż może zwracać bajty co najmniej tej samej jakości, jak gdyby RdRand był używany bezpośrednio. Po drugie, systemd nie musi już wywoływać RdRand bezpośrednio, ponieważ użycie RdRand przez systemd było źródłem błędów.
Generatory wywoływane przez PID 1 mają kilka wbudowanych zmiennych środowiskowych : $SYSTEMD_SCOPE, $SYSTEMD_IN_INITRDi $SYSTEMD_ARCHITECTURE. Z drugiej strony, ten sam PID 1 automatycznie pobierze dane uwierzytelniające systemu z interfejsu QEMU fw_cfg jako sposób przekazywania dowolnych danych do systemów zwirtualizowanych, podobnie jak w przypadku kontenerów systemd-nspawn.$SYSTEMD_FIRST_BOOT$SYSTEMD_VIRTUALIZATION
Kontynuując systemd 251, narzędzie „systemd-creds” zawiera „has-tpm2”, aby wskazać, czy dostępny jest działający moduł TPM 2.0. Warto pamiętać, że TPM 2.0 jest jedną z głównych przeszkód w rozszerzaniu systemu Windows 11, chociaż nie oznacza to, że systemy Linux, które opierają się na systemd, również będą tego wymagały, zwłaszcza że większość komponentów frameworka jest opcjonalna.
Jednym z głównych komponentów systemd jest „systemd-oomd”, który odpowiada za usprawnienie zarządzania pamięcią RAM, gdy zaczyna jej brakować. W tej wersji, oprócz innych dodatków, pozwala ona jednostkom, które zabijasz, uzyskać wynik usługi kill-kill. Liczba przypadków, w których usługa została zabita, jest liczona w rozszerzonym atrybucie user.oomd_ooms.
Na poziomie udev dołączono dwa pliki. Jedna z nich zawiera listę urządzeń przenośnych, takich jak kalkulatory i palmtopy, podczas gdy druga zawiera listę urządzeń do produkcji audio i wideo, takich jak stoły DJ-skie. Oba powinny być domyślnie dostępne dla użytkownika będącego właścicielem.
Inne drobne cechy systemd 251 to dodatkowe konfiguracje usług, które mogą teraz działać również jako nieuprzywilejowane usługi użytkownika, fakt, że pliki „.netdev” mogą być teraz używane w urządzeniach wirtualnych WLAN oraz ulepszenia specyfikacji menedżera rozruchu.
systemd 251 można zainstalować w męczącym procesie kompilacji jego kodu źródłowego. Jako alternatywną ścieżkę możesz skorzystać z wersji kroczącej i najnowszej dystrybucji, takiej jak Arch Linux, która powinna się wkrótce ukazać, jeśli jeszcze się nie pojawiła. Jednak aktualizacja tego komponentu rzadko jest krytyczna, szczególnie w systemach stacjonarnych, w których użytkownik rzadko wchodzi z nim w bezpośrednią interakcję. Ci, którzy chcą poznać wszystkie szczegóły, mogą sprawdzić listę zmian opublikowanych w wydaniach GitHub .
Dodaj komentarz