Documentation for a newer release is available. View Latest

Cambiamenti a livello di distribuzione

Miglioramento della raccolta dei dati di utilizzo tramite DNF

Prima di Fedora 32, il Progetto Fedora stimava il numero di sistemi installati contando gli indirizzi IP univoci che accedevano agli aggiornamenti dai mirror ufficiali. Questo approccio risultava molto impreciso per diverse ragioni, come il conteggio per difetto dovuto al NAT e il conteggio per eccesso causato da brevi durate dei lease DHCP o dallo spostamento dei laptop tra diverse connessioni di rete; inoltre, tale metodo non permetteva di distinguere tra le varie edizioni di Fedora. Allo stesso tempo, metriche di utilizzo accurate sono estremamente utili per qualsiasi progetto software che voglia servire la propria comunità e restare rilevante; pertanto, il Progetto Fedora ha esplorato nuovi modi per ottenere informazioni più utili senza compromettere la privacy dei propri utenti.

In Fedora 32, quando il sistema installato contatta uno dei mirror ufficiali di Fedora, fornisce le seguenti informazioni ("user agent"):

  • Versione di Fedora (come "Fedora 32").

  • Variante di Fedora (come ad esempio "Server").

  • Sistema operativo e architettura (come ad esempio "Linux.x86_64").

  • Una variabile `countme`introdotta di recente.

La variabile `countme`viene utilizzata dal Progetto Fedora per determinare l’anzianità del sistema. La variabile può assumere quattro valori possibili:

  • `1`entro la prima settimana dall’installazione (giorni 0-7).

  • `2`tra la prima settimana e il primo mese dall’installazione - 8-30 giorni.

  • `3`tra il primo mese e i primi 6 mesi dall’installazione - da 31 a 180 giorni.

  • `4`dopo i primi 6 mesi dall’installazione - 180 giorni o più.

Utilizzando questo sistema, il Progetto Fedora può misurare i livelli di utilizzo di varie combinazioni di architetture e varianti, raccogliendo dati sull’uso di ciascuna variante a breve e lungo termine. Allo stesso tempo, questo sistema evita di raccogliere qualsiasi informazione identificativa relativa ai sistemi client.

Le euristiche di inlining e il function cloning possono ora utilizzare le informazioni sui range di valori (value-range information) per prevedere l’efficacia delle singole trasformazioni.

Questo sistema non sarà attivo sul lato del Progetto Fedora al momento del rilascio di Fedora 32, poiché la parte relativa al server non è ancora pronta. I client invieranno il proprio user agent includendo countme, ma inizialmente questo non verrà elaborato.

I supporti ottici fisici non richiedono test pre-GA (General Availability)

A partire da Fedora 32, non sarà più necessario testare il sistema operativo da installare tramite supporti ottici fisici prima della disponibilità generale (GA). Tuttavia, eventuali problemi riguardanti l’avvio da supporti fisici saranno comunque trattati come bug bloccanti (blocker bugs).

La modifica interesserà le seguenti immagini:

  • Fedora-Everything-netinst-x86\_64-<RELEASE_MILESTONE>.iso

  • Fedora-Workstation-Live-x86\_64-<RELEASE_MILESTONE>.iso

Questa modifica mira a rispondere alla tendenza alla costante diminuzione di nuovi computer e laptop dotati di unità CD/DVD, nonché agli errori che l’installazione tramite questi supporti comporta.

Di conseguenza, il team Fedora QE e i tester della community avranno maggiore capacità per testare le parti di Fedora che sono molto più visibili ed esposte agli utenti finali.

A causa di alcuni bug, in certi casi gli utenti potrebbero non essere in grado di completare l’installazione da supporti ottici.

Cambiamenti nel packaging del pacchetto clang-libs

Il pacchetto clang-libs non include più le singole librerie dei componenti come`libclangBasic.so`, libclangAST.so.so e così via. I pacchetti che dipendono dalle librerie clang sono ora collegati a`libclang-cpp.so`.

Come risultato di questa modifica:

  • C’è un miglioramento della stabilità in Fedora e dei tempi di avvio delle applicazioni.

  • Gli utenti finali che sviluppano applicazioni utilizzando le librerie clang sono tenuti ad aggiornare le proprie applicazioni per utilizzare`libclang-cpp.so` al posto delle singole librerie dei componenti.

  • Gli utenti finali che utilizzano pacchetti Fedora dipendenti dalle librerie clang non subiranno alcun impatto a seguito di questa modifica.

Aggiunto il supporto per i pacchetti AArch64 e ppc64le con una disponibilità estesa dei pacchetti dipendenti da FPC

Una versione aggiornata (3.2.0) del Free Pascal Compiler (FPC) è ora disponibile in Fedora 32. Con questo aggiornamento, è possibile compilare pacchetti per Arch64 (ARM 64-bit) e ppc64le (PowerPC 64-bit Little Endian). Inoltre, il compilatore supporta ora nuove architetture, rendendo i programmi compilati con FPC compatibili con un numero maggiore di piattaforme supportate da Fedora.

Synchronizer (sync gem)

In precedenza, gli utenti venivano creati nella sezione %pre`chiamando i comandi `getent, useradd`e `groupadd.

With this update, users are defined in the sysusers.d format. It adds an rpm package Provides generator to create user(<name>) and group(<name>) virtual Provides for packages with sysusers.d files.

È stato aggiunto un generatore di Provides per i pacchetti RPM al fine di generare user(<nome>) e group(<nome>) per i pacchetti che contengono file sysusers.d.

"Come beneficio:"

  • "I pacchetti dichiarano gli utenti di sistema utilizzando una sintassi uniforme.

  • Gli scriptlet sono più standardizzati.

  • Gli amministratori possono facilmente ispezionare l’elenco degli utenti di sistema e individuare quali pacchetti richiedono determinati utenti.

  • Gli amministratori possono facilmente ignorare le definizioni degli utenti di sistema fornendo file sysusers.d.d appropriati con una priorità più alta.

    Gli utenti vengono ancora creati utilizzando le chiamate `useradd`di vecchio tipo.

Utilizzo limitato degli scriptlet dei pacchetti core

In Fedora 32, ai pacchetti core (pacchetti utilizzati per creare l’immagine container minima) sono state rimosse tutte le chiamate agli scriptlet (%pre, %post, %preun, %postun). Ciò significa che l’intero processo di installazione dell’immagine container è ora dichiarativo e trasparente per gli strumenti di packaging come rpm, ostree o composer; l’installazione è più veloce e il mantenimento di questo approccio in futuro consentirà ulteriori ottimizzazioni e funzionalità.

I pacchetti possono ancora apportare modifiche al sistema durante l’installazione inserendo file in posizioni specifiche che attivano determinate azioni.

Recupero più rapido dalle situazioni di memoria insufficiente in Fedora Workstation

Il servizio `earlyoom`è ora abilitato per impostazione predefinita in Fedora Workstation.

Il servizio earlyoom monitora l’utilizzo della memoria di sistema. Se la memoria libera scende sotto una soglia prestabilita, earlyoom termina un processo appropriato per liberare risorse. Di conseguenza, il sistema non smette di rispondere per lunghi periodi di tempo in situazioni di scarsa disponibilità di memoria.

Quella che segue è la configurazione predefinita di earlyoom:

  • Se sia la RAM che lo swap scendono sotto il 10% di spazio libero, earlyoom invia il segnale SIGTERM al processo con l' oom_score più elevato.

  • Se sia la RAM che lo swap scendono sotto il 5% di spazio libero, earlyoom invia il segnale SIGKILL al processo con l' oom_score più elevato.

Per ulteriori informazioni, consulta la pagina man di earlyoom.