L'attuale current (febbraio 2026)

[lablinux]

E': stabile, abbastanza stabile, poco stabile o devi aver tempo per sistemarla?

NB Non vuol essere in nessun modo una polemica/critica, ma solo curiosità

Grazie

[targzeta]

Io la uso sempre come stabile, sia che lo sia, sia che non lo sia . Sia a casa che a lavoro!

Emanuele

[joe]

Io ho sempre avuto l'orticaria con gli aggiornamenti...
Perché se è vero che l'aggiornamento del parco software ufficiale sia fattibile senza grossi problemi, invece il software di terze parti aggiunto in seguito in svariati casi dopo può risultare non più funzionante. Il ché implica che ad esempio se aggiunto via SBo ti devi ricompilare mezzo mondo di software e farlo con un PC vecchiotto è un'operazione "campale".
Per cui io ho sempre usato la stabile, e anche lì gli aggiornamenti non li ho fatti mai così al volo in massa. Non è consigliabile, per motivi di sicurezza, ma tant'è prima di una aggiornamento completo ho sempre valutato se il PC in quel periodo mi serve. Perché devo mettere in conto che la ricompilazione della marea di software SBo mi occupa la macchina per ore e ore, forse giorni e notti. Intendiamoci, si può fare, ma non è mai una circostanza comoda, e a volte alcune configurazioni "storiche" possono saltare a causa di modifiche nelle nuove versioni dei software che magari richiedono altre sintassi ecc...
Mi sono recentemente installato una current in una partizione ad hoc.
L'ho utilizzata giusto per avviare la sessione grafica con fluxbox o openbox non ricordo neanche...
A chi usa current, ne approfitto per chiedere, ma come la manutente?
Cioè, con quale frequenza la aggiornate? Usate un parco software terzo piuttosto nutrito? E come vi regolate dopo l'aggiornamento del sistema di base?

È consigliabile mettere in piedi un sistema current da lasciare congelato per tot mesi? E chiedo anch'io, è utilizzabile senza magagne per uso quotidiano tipo ufficio o giù di lì?
Perché ormai la stabile va per i 4 anni! E si sa solo che sarà rilasciata la prossima quando sarà pronta. Passare alla current dove comunque lo sviluppo è costante non sarebbe male...

[targzeta]

Io aggiorno tutti i giorni. Quello che dici è vero, anche oggi, ad esempio, ho fatto partire un applicativo che non trovava più una libreria. Ricompilato e via. Considera che se segui la current quotidianamente, allora avrei meno problemi di quelli che hai con un "salto" molto più grande che hai se segui la stable.

Nel mio PC da cui ti scrivo ho 504 pacchetti ufficiali e 50 di terze parti. Come detto, la current la uso sia a casa che a lavoro.

Sicuramente ci sono i giorni no, però, ad esempio, quando torno a casa dei miei e aggiorno il PC che ho lì (sempre con current), di solito poi non funziona niente (tendenzialmente X) perché aggiorno una marea di pacchetti tutti in una volta. Comunque, memore di quello che ho fatto su questo, me la cavo senza troppi problemi.

[joe]

Il fatto che aggiorni così spesso, fa sì che da uno stato di aggiornamento al successivo le probabilità che si rompa qualche dipendenza sono inferiori rispetto ad un aggiornamento che ti porta da uno stato vecchio di tre mesi ad uno attuale, tanto per dire. Questo sì.
Però a ben pensare non cambia troppo perché magari non te n'accorgi di avere degli applicativi rotti, e quando meno te l'aspetti qualcosa non sta più funzionando per via di roba che s'appoggia a librerie non più presenti.
È solo una questione di tempo e comunque dovrai ricompilare tutto insomma... si tratta di scegliere se avere un sistema congelato per tot mesi, ma coerente, cioè con pacchetti terzi compilati contro il software base effettivamente in essere sul sistema oppure stare aggiornati col repo ufficiale, ma accettare il rischio di avere dei pacchetti terzi non funzionanti, che poi quando ti servono non funzioneranno e dovrai ricompilare.
L'ottimo sarebbe di aggiornare tutto e ricompilare anche tutto il parco di pacchetti terzi, magari tutti i giorni. Però l'ottimo in questo caso è nemico del buono come diceva il saggio, e per più di un motivo:

- i pacchetti terzi non è detto che siano tutti compilabili contro l'ultimo aggiornamento ufficiale. In particolare gli slackbuilds SBo possono anche non funzionare perché basati su una stabile, e anche quelli di Ponce basati su current necessitano di continuo testing. Insomma non c'è garanzia di funzionamento.

- aspetto pratico non trascurabile, ricompilare ogni giorno tutto contro il parco ufficiale aggiornato, è un'operazione impegnativa, lunga e direi infattibile per chi deve utilizzare quotidianamente il PC e per chi non ha un cervellone fantasmagorico in termini di CPU e RAM a iosa a disposizione.

Ad ogni modo hai fatto bene a mettere i numeri della tua installazione, perché così si dà l'idea del numero di pacchetti coinvolti.
Metto anche i miei perché forse diventa più chiara l'infattibilità per me di aggiornare quotidianamente e assicurarsi un sistema coerente.

Codice: Seleziona tutto

$ for i in [0-9]$ SBo.*$ _hb$ alien$ ^.*$; do echo $i : $(find /var/log/packages/ | grep "$i" | wc -l); done
[0-9]$ : 1831
SBo.*$ : 636
_hb$ : 14
alien$ : 17
^.*$ : 2506

Al conto sforano 8 pacchetti mi pare... ma è un dettaglio. Quello che conta è che sulla mia installazione 15.0 ho quella marea di roba lì. E aggiornarla giornalmente con inclusa compilazione non è fattibile.

Il giusto mezzo per me sarebbe prendersi una current di un certo giorno, e tenersela per qualche mese, compilandoci contro il software terzo. Dopo 3 mesi si riaggiorna e si ricompila.

Per farla ancora meglio sarebbe il caso d avere 2 installazioni, una in uso, e una in "testing" che sia una nuova installazione della current aggiornata su cui poi compilare il software terzo. Così si può lavorare col sistema già rodato e quando è il caso invece d'aggiornarlo ricreare la nuova installazione isolata e aggiornata per poi anche lì corredarla del software terzo. A quel punto si passa dal sistema rodato al nuovo testing e si tiene per altri tot mesi.

Il problema di questa soluzione è la configurazione del sistema rodato che poi va replicata sul nuovo sistema testing, e non è un'operazione banale soprattutto se si è cercato di personalizzarsi a puntino il proprio ambiente.

Tirando le somme, a me per come la vedo e rivedo, sembra comunque sempre un gran casino!

[lablinux]

con due sistemi, con lo stesso partizionamento, con un dd passa la paura.

[joe]

Per sistemi intendi due dischi in questo caso giusto?
Ma non ho afferrato come intenderesti procedere nel passaggio da una current, alla successiva aggiornata.
Perché lì "dd" non basta mica... niente, se ti va di articolare un attimo meglio leggo con interesse.
E se lo è perdona la banalità della domanda.

[lablinux]

dd non basta? copia il disco (o la partizione) bit per bit. Se la testing funziona, è difficile da replicare, passo paso quello fatto sulla testing funzionante.
Facendo:

Codice: Seleziona tutto

dd if=/dev/sda2 of=/dev/sda1 

sda1 è prod e la sda2 è la testing.
Al termina dovresti avere la copia di testing in prod

[joe]

Qua non si vuole copiare il disco però.
Si vuole prendere un sistema operativo diverso (la curent aggiornata, chiamiamola testing) e corredarla di tutto il software di terze parti che aveva sul sistema "produzione", replicare sulla testing la configurazione di produzione e testarla utilizzandola.
A quel punto secondo me non serve neanche ricopiarla indietro, se è questo che intendevi, perché la vecchia produzione si può anche lasciare lì come una "old-stable" diciamo, e poi basta ad esempio far partire Grub con la testing che dopo un po' di rodaggio potremo considerare come nuova "stabile", e via.
Passati enne mesi o enne settimane, o enne giorni a seconda delle esigenze e possibilità, prendiamo la partizione della "old stable" e la consideriamo come destinazione per la nuova testing. Ci buttiamo una nuova slackware current (perdendo ovviamente la old stable) e ricompiliamo e riconfiguriamo tutto, fino a puntare grub alla nuova testing.

In questo senso dicevo , dd non basta. E anzi direi che in quest'ottica dd non servirebbe proprio.
Invece tutto lo sbattimento di ricompilare e riconfigurare resta, ti pare?
Oppure intendevi:
- copio con dd la stabile su altra partizione e condiero questa copia come testing
- in testing faccio aggiornamento slackware-current
- ricompilo tutto il software di terze parti
- la configurazione spero che non abbia subito cambiamenti viste le nuove versioni del software

Questo forse era il senso del tuo intervento e non come l'ho interpretato nel primo pezzo.

[conraid]

Aggiorno anche io tutti i giorni, o quasi. E i pacchetti che mi compilo son davvero tanti
Ho anche un pc vecchio, e spesso ci sta troppo.
Come dici diventa impegnativo come tempo, e infatti alcuni giorni che ho da fare di più evito.
La scorsa estate sono stato un mesetto fuori uso per problemi vari e riprendere è stata dura, non tanto per l'aggiornamento della slackware, ma i pacchetti extra appunto. Soprattutto perché gestisco un repository e tendo a tenerli aggiornati per quanto possibile.

[lablinux]

Oppure intendevi:
- copio con dd la stabile su altra partizione e condiero questa copia come testing
- in testing faccio aggiornamento slackware-current
- ricompilo tutto il software di terze parti
- la configurazione spero che non abbia subito cambiamenti viste le nuove versioni del software

Questo forse era il senso del tuo intervento e non come l'ho interpretato nel primo pezzo.

Due partizioni.
SDA1 installi la testing, tutti i pacchetti extra, compili e configuri. E' il sistema principale.
Dopo enne mesi:
SDA2 installi la 'nuova' testing, tutti i pacchetti extra compili e configuri. Se tutto funziona, la sposti sull'SDA1 con un bel dd, senza dover rifare un'installazione ex novo sulla partizione

[joe]

Sì ok, ma appunto come dicevo sopra allora.
Perché se ad un certo punto ho il sistema funzionante in SDA2, dovrei mai spostarlo con dd su sda1?
Mi basta avviare il nuovo sistema testato e funzionante e basta.
Dopo enne messi rifaccio la solfa su SDA1 e quando lì avrò ottenuto un sistema funzionante punto grub a quello e lo avvio. Non servirà certo una ulteriore nuova installazione perché l'ho già appena fatta su SDA1. SDA2 resterebbe lì come old-stable, al limite se poi servirà spazio si può anche eliminare dopo tot mesi.

Il problema di questo approccio è la manualità dell'operazione in particolare ricompilarsi il parco software di terze parti.
Inoltre in casi come questo come gestireste i dati utente?
Esempio in SDA1 potrei avere:

- SDA1: /home/joe/documents
- SDA1: /home/joe/.config

ecc... insomma, alcuni sono dati utente, altri potrebbero essere pezzi di configurazione creati e modificati nel tempo...
Chiedo perché potrebbe sempre essere utile capire come fanno gli altri a gestire i dati.