Innanzitutto, la versione C predefinita è stata cambiata da C89 a C11 con estensioni GNU (GNU11), sebbene le intestazioni API siano ancora limitate alla versione più vecchia (89). Questo cambiamento potrebbe essere motivato dal fatto che stiamo seguendo le orme del kernel Linux , un progetto che stava anche considerando il passaggio a C11 a causa delle limitazioni introdotte da C89. Qualcuno dirà che il vero futuro appartiene a Rust , ma qui saremo troppo prudenti.
Il componente systemd-sysupdate è stato incluso sperimentalmente ed è un lavoro iniziato la scorsa estate da Red Hat e dagli sviluppatori di systemd di base. È un meccanismo in grado di (o almeno destinato a) rilevare, scaricare e installare automaticamente aggiornamenti per installazioni host, immagini di container, immagini di servizi portatili e altri componenti.
Tutti i kernel supportati a partire da systemd 251 crittograferanno l’output dell’istruzione RdRand (o altre estensioni ISA per la randomizzazione del processore) all’avvio anticipato, il che ha due conseguenze. Primo, anche se `/dev/urandom’ non è inizializzato, può comunque restituire byte almeno della stessa qualità come se RdRand fosse usato direttamente. In secondo luogo, systemd non ha più bisogno di chiamare direttamente RdRand, poiché l’uso di RdRand da parte di systemd è stato fonte di bug.
I generatori chiamati da PID 1 hanno diverse variabili di ambiente integrate: $SYSTEMD_SCOPE, $SYSTEMD_IN_INITRD, $SYSTEMD_ARCHITECTUREe $SYSTEMD_FIRST_BOOT. $SYSTEMD_VIRTUALIZATIOND’altra parte, lo stesso PID 1 recupererà automaticamente le credenziali di sistema dall’interfaccia QEMU fw_cfg come mezzo per passare dati arbitrari a sistemi virtualizzati, in modo simile a quanto può essere fatto con i contenitori systemd-nspawn.
Continuando con systemd 251, lo strumento “systemd-creds” include “has-tpm2” per indicare se è disponibile un modulo TPM 2.0 funzionante. Vale la pena ricordare che TPM 2.0 è uno dei principali ostacoli all’estensione di Windows 11, anche se ciò non significa che anche i sistemi Linux che si basano su systemd lo richiederanno, soprattutto considerando che la maggior parte dei componenti del framework sono opzionali.
Uno dei componenti principali di systemd è “systemd-oomd”, che è responsabile del miglioramento della gestione della RAM quando inizia a scarseggiare. In questa versione, oltre ad altre aggiunte, consente alle unità che uccidi di avere il risultato di un servizio kill-kill. Il numero di volte in cui un servizio è stato interrotto viene contato nell’attributo esteso user.oomd_ooms.
A livello di udev, sono stati inclusi due file. Uno elenca i dispositivi portatili come calcolatrici e PDA, mentre l’altro elenca i dispositivi di produzione audio e video come i tavoli da DJ. Entrambi dovrebbero essere disponibili per impostazione predefinita per l’utente proprietario.
Altre caratteristiche minori di systemd 251 sono configurazioni di servizio aggiuntive che ora possono funzionare anche come servizi per utenti non privilegiati, il fatto che i file “.netdev” possono ora essere utilizzati nei dispositivi virtuali WLAN e miglioramenti alle specifiche del boot manager.
systemd 251 può essere installato attraverso l’agonizzante processo di compilazione del suo codice sorgente. Come percorso alternativo, puoi ricorrere al rilascio progressivo e all’ultima distribuzione come Arch Linux, che dovrebbe essere presto disponibile se non lo è già. Tuttavia, l’aggiornamento di questo componente è raramente critico, specialmente sui sistemi desktop in cui l’utente raramente interagisce direttamente con esso. Chi volesse conoscere tutti i dettagli può consultare l’ elenco delle modifiche pubblicate nelle release di GitHub .
Lascia un commento