[Fedora] Discussione ufficiale

[woddy68]

Fedora KDE si sta confermando una delle migliori distro su KDE. Già è arrivato KDE plasma 6.3.

Non ho capito... sull'attuale vs stabile è arrivato Plasma 6.3 ?

Esatto. Su Fedora 41 e' gia arrivato plasma 6.3. Ultimamente sono rapidissimi ad aggiornare plasma kde.

Ah! Ok, pensavo facessero solo aggiornamenti di manutenzione per il DE, meglio così.
E' arrivato anche in Tumbleweed Plasma 6.3.
Una delle cose che mi stava sul c... nelle versioni precedenti, era che usando il mouse le categorie del menù cambiavano quando accidentalmente ci passavi sopra , ora vedo che per cambiarla devi cliccarci sopra e per me è meglio.

[emanuc]

Molti di quei service sono per il mount delle attività di rete, ci sono anche quelli di Virtual Box che non avresti in una Fedora installata fisicamente. Poi ci sono alcuni service utili per chi monta i filesystem di rete, ma non è che influiscono sul boot.
Se lo confrontiamo con un installazione fisica di Fedora, in questo caso la mia, con vari dischi al mount (che influiscono sul boot time):

Codice: Seleziona tutto

systemd-analyze
Startup finished in 10.609s (firmware) + 2.867s (loader) + 2.524s (kernel) + 7.950s (initrd) + 4.869s (userspace) = 28.821s 
graphical.target reached after 4.845s in userspace.

Confronto con un'altra disco Desktop, come Ubuntu. Escludo il tempo di avvio perché la differenza potrebbe dipendere dalla configurazione hardware e software.

list-unit-Ubuntu24.txt

(34.34 KiB) Scaricato 10 volte

E sono a un post install di Ubuntu, più APP snap installi più aumentano i service al boot...

In conclusione, Fedora la vedo in linea con le altre distro Desktop pronte all'uso sul software e servizi preinstallati. Con questo ragionamento in mente, sia Ubuntu, popOS, openSUSE e tutte le distro Desktop pronte all'uso sono "ingolfate".

PS: Io tengo le VM su un SSD dedicato, e non su un HDD, per velocizzare i test durante l'avvio. D'altronde, chiunque si preoccupi delle performance bada anche all'aspetto hardware.

Edit: Ho avuto il tempo di installare un 5 APP snap su Ubuntu in VM.
Ecco il risultato:

list-unit-Ubuntu24.txt

(34.34 KiB) Scaricato 10 volte

All'incirca 32 nuovi service creati:

A parte un aumento del boot time di 7 secondi circa.

[frapox]

Dunque, ho provato a mettere su una VM nuova con Ubuntu 24.10, l'ultima release disponibile. I risultati nelle stesse condizioni della VM con Fedora sono questi:

Tempi di avvio:

Codice: Seleziona tutto

$ systemd-analyze 
Startup finished in 6.165s (kernel) + 1min 12.309s (userspace) = 1min 18.474s 
graphical.target reached after 1min 12.225s in userspace.

$ systemd-analyze 
Startup finished in 6.173s (kernel) + 1min 20.228s (userspace) = 1min 26.402s 
graphical.target reached after 1min 20.173s in userspace.

$ systemd-analyze 
Startup finished in 8.835s (kernel) + 1min 23.613s (userspace) = 1min 32.449s 
graphical.target reached after 1min 23.569s in userspace.

$ systemd-analyze 
Startup finished in 8.792s (kernel) + 1min 25.682s (userspace) = 1min 34.475s 
graphical.target reached after 1min 25.647s in userspace.

$ systemd-analyze 
Startup finished in 6.638s (kernel) + 1min 21.135s (userspace) = 1min 27.774s 
graphical.target reached after 1min 21.088s in userspace.

Mediamente 30 secondi meno di Fedora (circa 1.30m vs 2 min abbondanti).

Unit caricate: qualcuna in meno, v. allegato.

systemctl ubuntu 24.10.txt

(29.08 KiB) Scaricato 7 volte

Non particolarmente performante neanche Oriole su Hdd quindi, ma un po' meglio OutOfTheBox performa rispetto a Fedora 41, sì.

@emanuc concordo assolutamente che per le performance anche in VM bisogna puntare tutto su SSD, ma il mio test "al limite" serve proprio a mettere in evidenza quelle differenze che con un SSD verrebbero appianate o annullate proprio per la maggiore banda disponibile. E poi per un motivo pratico: non avevo abbastanza spazio sull'SSD interno da dedicare alle VM.

Non sono d'accordo invece che Fedora sia bloated uguale a Ubuntu. La sensazione è quella di maggiore pesantezza, sia all'avvio che nell'uso. Chiaramente non avevo alcuna pretesa di rigore scientifico, anche se il test sostanzialmente conferma le mie sensazioni.

Senza addentrarmi nel perché per es. Fedora preinstalli tutti quei servizi/socket per la virtualizzazione, io ritengo ancora che Ubuntu sia più "general purpose" rispetto a Fedora, invece indirizzata più per l'utenza avanzata/sviluppatori. E come dato soggettivo, preferisco sempre una distro che mi installi "il meno possibile" per poi lasciarmi eventualmente installare il resto in un secondo momento.

Quindi confermo il parere iniziale dell'ingolfamento di F41 (che poi lo sia anche Ubuntu ormai è abbastanza evidente, purtroppo. ).

[emanuc]

E come dato soggettivo, preferisco sempre una distro che mi installi "il meno possibile" per poi lasciarmi eventualmente installare il resto in un secondo momento.

Tendenzialmente lo preferisco anche io, ma è difficile trovare una distro che si adatti al 100% a ogni utente. Alla fine posso sempre disinstallare ciò che non mi serve se proprio mi dà fastidio (ho anche creato uno script post install*), anche se non crea alcun overhead nell'utilizzo. Sinceramente, il time boot non mi è mai interessato più di tanto.
Ubuntu è "patologico" perché, nello store di Ubuntu, gli snap hanno la priorità. È quindi facile che un utente installi 10/20 APP e finisca per "ingolfare" Ubuntu al boot time.

* Le APP/servizi che disinstallo/disabilito post install:

Alcune utilità:

Codice: Seleziona tutto

    sudo dnf install python3-dnf-plugin-system-upgrade \
                     below \
                     nvtop \
                     htop \
                     gdu \
                     duf \
                     btop \
                     powertop \
                     inxi \
                     fish \
                     bpytop \
                     iotop

Utilità per gli snapshot su Btrfs:

Codice: Seleziona tutto

sudo dnf install btrfsmaintenance \
                     python3-dnf-plugin-cow.noarch \
                     btrfs-assistant

Al momento disinstallo anche il firewall:

Codice: Seleziona tutto

sudo dnf remove firewall*

Preferisco segnalare upstream o aprirlo manualmente invece di farlo con abrt (segnalazione errori):

Codice: Seleziona tutto

sudo dnf remove abrt* anaconda*

Ecco i service che disabilito (anche networkManager online perché non ho nessun filesystem di rete al mount):

Codice: Seleziona tutto

sudo systemctl disable dmraid-activation.service \
                          lvm2-lvmpolld.service \
                          lvm2-lvmpolld.socket \
                          lvm2-monitor.service \
                          mdadm-grow-continue@.service \
                          mdadm-last-resort@.service \
                          mdadm-last-resort@.timer \
                          mdmon@.service \
                          mdmonitor.service \
                          mdmonitor-oneshot.service \
                          mdmonitor-oneshot.timer \
                          zfs-fuse.service \
                          zfs-fuse-scrub.service \
                          zfs-fuse-scrub.timer \
                          remote-fs.target \
                          nfs-client.target \
                          NetworkManager-wait-online.service \
                          vboxservice.service

[caturen]

Ubuntu è "patologico" perché, nello store di Ubuntu, gli snap hanno la priorità

in fedora non è che le cose vadano tanto meglio

Fedora Flatpaks have been a significant source of quality problems and have frankly been generally unsuccessful. Fedora Flatpaks are not well-tested, and users who understand what they are generally do not want to use them. They want to use higher-quality Flatpaks created by upstream instead. But most users don't even realize they are getting a Flatpak from Fedora rather than from upstream

FESCo was correct to put Flathub as lowest-priority, as we have no control over what goes into them, and their packaging standards are low, inconsistent, or nonexistent

https://pagure.io/fedora-workstation/issue/463

end-of-life: The Fedora Flatpak build of obs-studio may have limited functionality compared to other sources. Please do not report bugs to the OBS Studio project about this build.

https://src.fedoraproject.org/flatpaks/ ... ainer.yaml

[emanuc]

Ubuntu è "patologico" perché, nello store di Ubuntu, gli snap hanno la priorità

in fedora non è che le cose vadano tanto meglio

Fedora Flatpaks have been a significant source of quality problems and have frankly been generally unsuccessful. Fedora Flatpaks are not well-tested, and users who understand what they are generally do not want to use them. They want to use higher-quality Flatpaks created by upstream instead. But most users don't even realize they are getting a Flatpak from Fedora rather than from upstream

FESCo was correct to put Flathub as lowest-priority, as we have no control over what goes into them, and their packaging standards are low, inconsistent, or nonexistent

https://pagure.io/fedora-workstation/issue/463

end-of-life: The Fedora Flatpak build of obs-studio may have limited functionality compared to other sources. Please do not report bugs to the OBS Studio project about this build.

https://src.fedoraproject.org/flatpaks/ ... ainer.yaml

Ma in questo caso non si tratta di un problema di design di Flatpak, ma di manutenzione. Flatpak non presenta i problemi di snapd, che crea millemila service e mount loop sul filesystem. Inoltre, con Flatpak puoi aggiornare le app in background senza dover chiudere o interrompere l'app in uso. Semplicemente viene creato un nuovo commit che verrà utilizzato al prossimo avvio dell'APP. Con il vantaggi oche puoi abilitare l'autoupgrade senza interruzioni.
Fedora repo flatpak non sono ben mantenuti e stanno valutando di depriorizzarli o rimuoverli, per dare priorità a Flathub.

[woddy68]

Fedora minacciata per un azione legale da OBS studio non ufficiale distribuito come flatpak.
https://news.itsfoss.com/obs-studio-fedora-feud/

[frapox]

Fedora minacciata per un azione legale da OBS studio non ufficiale distribuito come flatpak.
https://news.itsfoss.com/obs-studio-fedora-feud/

A formal request from a Fedora package maintainer was made here to remove the package, we consider this movement in the right direction: https://pagure.io/releng/issue/12586

https://gitlab.com/fedora/sigs/flatpak/ ... 2347081516

Con le buone si ottiene tutto...

[woddy68]

Non sapevo che avessero fatto un loro repository di flatpak, perché da quello che ho capito il problema è proprio quello.
A me OBS flatpak ufficiale funziona bene.

[emanuc]

Fedora minacciata per un azione legale da OBS studio non ufficiale distribuito come flatpak.
https://news.itsfoss.com/obs-studio-fedora-feud/

Io sto con gli sviluppatori! Dovrebbero smettere di prendere il software, impacchettarlo e creare problemi agli sviluppatori upstream. Lo stesso vale per i pacchetti nativi, che spesso sono obsoleti rispetto all'upstream.

In questo modo noi sviluppatori non veniamo mandati a caccia di oca selvatica solo per scoprire che si tratta di un problema specifico del modo in cui quella distribuzione confeziona il software. Ci vuole una larghezza di banda che potremmo non avere per simili imbrogli.

Modifica:
Voglio aggiungere che non intendo questo come un attacco a nessuno di coloro che creano pacchetti per le distribuzioni. È un lavoro difficile e lo so dolorosamente bene avendo fatto io stesso pacchetti in passato. Tuttavia, il burnout del manutentore è molto reale e qualcosa con cui ho dovuto fare i conti personalmente. È importante considerare l'equilibrio tra la libertà di pacchettizzazione di una distribuzione e il non burnout degli sviluppatori upstream. Il burnout è uno dei modi in cui finiamo con software morto e non mantenuto, dopotutto.

[woddy68]

Fedora minacciata per un azione legale da OBS studio non ufficiale distribuito come flatpak.
https://news.itsfoss.com/obs-studio-fedora-feud/

Io sto con gli sviluppatori! Dovrebbero smettere di prendere il software, impacchettarlo e creare problemi agli sviluppatori upstream. Lo stesso vale per i pacchetti nativi, che spesso sono obsoleti rispetto all'upstream.

In questo modo noi sviluppatori non veniamo mandati a caccia di oca selvatica solo per scoprire che si tratta di un problema specifico del modo in cui quella distribuzione confeziona il software. Ci vuole una larghezza di banda che potremmo non avere per simili imbrogli.

Modifica:
Voglio aggiungere che non intendo questo come un attacco a nessuno di coloro che creano pacchetti per le distribuzioni. È un lavoro difficile e lo so dolorosamente bene avendo fatto io stesso pacchetti in passato. Tuttavia, il burnout del manutentore è molto reale e qualcosa con cui ho dovuto fare i conti personalmente. È importante considerare l'equilibrio tra la libertà di pacchettizzazione di una distribuzione e il non burnout degli sviluppatori upstream. Il burnout è uno dei modi in cui finiamo con software morto e non mantenuto, dopotutto.

...e io condivido. Ma perché hanno fatto un loro repository flatpak? Non sono molto dentro al mondo Fedora e non sapevo di questa cosa.

[frapox]

...e io condivido. Ma perché hanno fatto un loro repository flatpak? Non sono molto dentro al mondo Fedora e non sapevo di questa cosa.

Tiro a indovinare: perché Flathub non è sotto il loro controllo (di Fedora) e volevano farsi un repo flatpak scollegato da Flathub e autogestito?

[emanuc]

...e io condivido. Ma perché hanno fatto un loro repository flatpak? Non sono molto dentro al mondo Fedora e non sapevo di questa cosa.

Perché flathub contiene anche software proprietario e perché vogliono controllare loro le build flatpak. Ricordo che il problema in questione è solo del SIG flatpak, cioè un gruppo di lavoro dedicato alla gestione e manutenzione dei pacchetti flatpak nel reposiotry Fedora e non dell'intero progetto Fedora.

[woddy68]

Ma da quel che so ad es. openSUSE lo abilita senza problemi Flathub, capisco la volontà di controllare il software che non è gestito direttamente dal upstream, ma che senso ha farlo quando un software è rilasciato direttamente dal "produttore" ?
Se proprio si vuole fare qualcosa di costruttivo, bisognerebbe controllare tutto il software caricato su flathub (quello open ovviamente) e marcare come software proprietario quello che è proprietario. Ma di fatto l'utente ha già questa informazione.
Ad esempio

[frapox]

E giustamente nel thread di Fedora si parla di OpenSuse...

La motivazione è legale. Se fedora neanche distribuiva nei suoi repo i codec chiusi (tipo mp3 e h264) semplicemente non può abilitare di default flathub, che tiene software chiuso. E quindi si è fatta i suoi repo che controlla per sé di cui ha la responsabilità totale e non shippa software proprietario.

È user-friendly? Ovviamente no, ma visto che le leggi sul copyright in America sono stringenti, e visto che Fedora ha sede in America...

Comunque Flathub si abilita con un click al primo login, quando la finestrella del wizard ti chiede di abilitare i software di terze parti. Oppure successivamente da gnome software > software repositories. Così è l'utente a farlo e loro si sono parati il q-low.

[woddy68]

E giustamente nel thread di Fedora si parla di OpenSuse...

La motivazione è legale. Se fedora neanche distribuiva nei suoi repo i codec chiusi (tipo mp3 e h264) semplicemente non può abilitare di default flathub, che tiene software chiuso. E quindi si è fatta i suoi repo che controlla per sé di cui ha la responsabilità totale e non shippa software proprietario.

È user-friendly? Ovviamente no, ma visto che le leggi sul copyright in America sono stringenti, e visto che Fedora ha sede in America...

Comunque Flathub si abilita con un click al primo login, quando la finestrella del wizard ti chiede di abilitare i software di terze parti. Oppure successivamente da gnome software > software repositories. Così è l'utente a farlo e loro si sono parati il q-low.

Ma non è vero ! Non c'è alcuna restrizione legale nell'abilitare il repository flathub.
Si, ho portato ad es. openSUSE perchè le due distribuzioni hanno politiche legali simili. Ma non c'è alcun impedimento legale nell'abilitare flathub, è solo una scelta di Fedora.
Non è un caso che Fedora rischia una querela per l'opposto di quello che tu dici.
Ti ricordo che siamo partiti da qui https://news.itsfoss.com/obs-studio-fedora-feud/ e non perché hanno abilitato Flathub, ma perché non lo hanno fatto !

[emanuc]

Ma da quel che so ad es. openSUSE lo abilita senza problemi Flathub, capisco la volontà di controllare il software che non è gestito direttamente dal upstream, ma che senso ha farlo quando un software è rilasciato direttamente dal "produttore" ?
Se proprio si vuole fare qualcosa di costruttivo, bisognerebbe controllare tutto il software caricato su flathub (quello open ovviamente) e marcare come software proprietario quello che è proprietario. Ma di fatto l'utente ha già questa informazione.

Su Fedora, Flathub viene abilitato se si sceglie di attivare il software di terze parti. Il problema è che il repository fedora flatpak ha una priorità più alta rispetto a flathub, quando sono abilitati entrambi.

Bene, questo è lo status quo, ma stiamo ricevendo un gran numero di reclami, quindi direi che non funziona. Solo un paio di sviluppatori Fedora hanno detto di preferire Fedora Flatpaks piuttosto che Flathub. La maggior parte degli utenti Fedora vuole Flathub Flatpaks, non Fedora Flatpaks.

Ci si aspetta a lungo termine che tutti i pacchettizzatori Fedora vengano ritirati e che tutte (o quasi tutte) le app siano disponibili su flathub come flatpak (tranne le app principali che sono flatpak Fedora)?

Questa è in un certo senso la mia aspettativa, ma con delle grosse riserve:

Oltre a Fedora Workstation, altri prodotti Fedora continueranno probabilmente a distribuire applicazioni basate su RPM anche se Fedora Workstation passerà completamente a Flatpak.
Tutto ciò che non è un'applicazione desktop deve comunque essere impacchettato come RPM. È molto.
Gli utenti vorranno inevitabilmente rinunciare a Flatpak e installare RPM tradizionali. Io sostengo Flatpak di default, non l'eliminazione completa dei pacchetti RPM.
Quindi non vedo proprio che gli RPM di Fedora spariranno del tutto.

Comunque, sono del parere che non dovrebbe esserci una duplicazione degli sforzi se il software è già disponibile ufficialmente su Flathub. Lascia che gli utenti lo installino dalla fonte ufficialmente supportata. Lo rimuoverei anche dal pacchetto nativo, dal momento che i Flatpak mirano a ridurre il carico di lavoro a favore di una manutenzione più semplice e di aggiornamenti più rapidi.

[woddy68]

@emanuc concordo con quello che hai scritto, ma ripeto che non esiste in termini legali alcun impedimento ad attivarlo per impostazione predefinita. E' una libera e legittima scelta di Fedora farlo in quel modo.

[frapox]

E giustamente nel thread di Fedora si parla di OpenSuse...

La motivazione è legale. Se fedora neanche distribuiva nei suoi repo i codec chiusi (tipo mp3 e h264) semplicemente non può abilitare di default flathub, che tiene software chiuso. E quindi si è fatta i suoi repo che controlla per sé di cui ha la responsabilità totale e non shippa software proprietario.

È user-friendly? Ovviamente no, ma visto che le leggi sul copyright in America sono stringenti, e visto che Fedora ha sede in America...

Comunque Flathub si abilita con un click al primo login, quando la finestrella del wizard ti chiede di abilitare i software di terze parti. Oppure successivamente da gnome software > software repositories. Così è l'utente a farlo e loro si sono parati il q-low.

Ma non è vero ! Non c'è alcuna restrizione legale nell'abilitare il repository flathub.

Fedora non distribuisce software chiuso/proprietario. Flathub distribuisce anche software chiuso/proprietario. Fedora non abilita di default Flathub. Fedora fa prendere la decisione all'utente e scarica le responsabilità sull'utente. Non mi sembra difficile da capire.

Ti ricordo che siamo partiti da qui https://news.itsfoss.com/obs-studio-fedora-feud/ e non perché hanno abilitato Flathub, ma perché non lo hanno fatto !

Veramente, la minaccia di azioni legali era causata dalla qualità pessima del Flatpak di OBS, non al fatto che Fedora non abiliti Flathub di default.

[emanuc]

Ti ricordo che siamo partiti da qui https://news.itsfoss.com/obs-studio-fedora-feud/ e non perché hanno abilitato Flathub, ma perché non lo hanno fatto !

Il problema principale è stato la scarsa qualità del pacchetto, che portava gli utenti a segnalare problemi all'upstream. Ad esempio, l'aggiornamento del runtime Qt con regressioni su OBS o la mancanza di codec. La manutenzione del repository è responsabilità del singolo SIG.