Newsgroup: it.comp.os.linux.iniziare
Titolo: Linux sta prendendo il brutto di Android sulla compatibilità app vs aggiornamenti?

Ciao NG,
 
Semplice curiosità da utente. Negli anni passati ho sempre 
apprezzato il fatto che anche senza aggiornare il sistema 
molti applicativi hanno sempre continuato a funzionare. I 
miei upgrade erano se non rari, sicuramente non frequenti.
 
Negli ultimi due anni domoticz si pianta in continuazione 
e funge solo con un sistema sempre aggiornato (lo fa su 
tre macchine quindi non credo di aver fatto io errori 
grossolani). Chiaro che aggiornare è buona pratica e non è 
possibile chiedere un comportamento "perverso" né 
lamentarsi se non lo si riscontra, però mi pare un po' 
troppo. Da questo punto di vista mi pare somigliare ad 
android che costringe le app a seguire da vicino il 
sistema sulla scala dei mesi.
 
Al momento uso pochi altri applicativi e sembrano meno 
sensibili al problema, quindi potrebbe essere solo 
domoticz. Però la curiosità resta perché mi piace avere 
un'idea di come si sta evolvendo il mondo informatico e se 
questo è un possibile sintomo di un'evoluzione di Linux 
che non sto cogliendo.
 
Grazie! :)
 
Apx.
 
-- 
- Amore, finalmente a letto... Fammi urlare come
   una pazza!
- Sei ingrassata.
 

 e funge solo con un sistema sempre aggiornato
 
In teoria, dovrebbe funzionare così:
 
- ho il sistema X
- nel repo ufficiale ho il pacchetto precompilato del programma Y:
 
esempio:
 
Y-1.0.0-x_official_1.txz
 
Ora, questo pacchetto è costruito, compilato e testato per funzionare
senza problemi sul sistema X, aggiornato anche quest’ultimo.
 
Se tu mettiamo aggiorni il sistema oggi, in teoria il programma
Y installato attraverso il pacchetto sopra, continuerà a funzionare
in eterno, *se non fai più aggiornamenti* né di Y nè di altro sul
ssitema.
Per forza, perché deriva proprio dal pacchetto tagliato e cucito su
misura per la versione del sistema X quando lo avevi aggiornato l’ultima
volta.
 
Cosa succede se ad esempio aggiorni il pacchetto Y?
 
Y-1.0.0-x_official_2.txz
 
Il sistema si troverà in uno stato potenzialmente incoerente, perché
X non è aggiornato tanto quanto il pacchetto Y.
Infatti il pacchetto di Y che abbiamo installato sta volta è stato
costruito, potenzialmente su un sistema X più recente, che magari
cambia anche di poco, ma potrebbe ad esempio aver aggiornato una
libreria da cui dipende proprio Y e allora il precompilato che prendiamo
dal repo ufficiale potrebbe non funzionare sul nostro vecchio sistema
X.
Soluzione: se aggiorni qualcosa da pacchetto precompilato aggiorna tutto
il sistema.
 
In questo modo aggiornerai anche l’ipotetica libreria da cui dipende Y:
 
Y-1.0.0-x_official_1.txz  dipende da  Z-1.2.3-x_official_1.txz
Y-1.0.0-x_official_2.txz  dipende da  Z-1.3.0-x_official_1.txz
 
Se non aggiorni nulla, funziona tutto.
Se aggiorni Y, devi aggiornare anche Z e più in generale meglio
aggiornare tutto il sitema X e via.
 
E se Y non fa parte del repo ufficiale?
 
Poco cambia:
vado sul sito del programma Y (domoticz) e installo un precompilato
che si appoggia sulla libreria Z, i due devono essere coerenti:
La Z installata nel sistema deve essere nella versione richiesta dalla
versione del programma Y che intendo far girare.
 
Una soluzione parziale è compilare Y sul proprio sistema X.
Y deve in quel caso essere opensource ovviamente.
Ma può non bastare.
 
Infatti il problema dipendenza c’è sia in fase di escuzione del
programma (runtime) che in fase di build/compilazione, per cui
potresti avere un sistema X troppo vetusto che non ha la libreria
Z abbastanza recente, tanto quanto invece la richiederebbe l’ultima
versione di Y per poter essere compilata.
 
A me è capitato qualcosa del genere perché volevo provare l’ultima
versione di scribus sulla mia slackware 14.2.
Il problema è che sul sistema ci sono librerie importanti sulle
quali si appoggia tutto il resto del sistema e che pertanto non
possono essere aggiornate senza comprometterne il funzionamento.
D’altra parte il nuovo scribus richiedeva come dipendenza in fase
di compilazione una versione più recente di quella libreria rispetto
a quella installata...
Ecco perchè dico che slackware stabile ormai è sconsigliabile per uso
desktop.
Soluzione mi sono tenuto la versione precedente di scribus compilata
sul mio sistema. E tutto continua a funzionare.
 
 
In sintesi il tuo problema è che probabilmente hai aggiornato
domoticz a una nuova versione che si appoggia su qualche pezzo
del tuo sistema più recente di quello che hai installato adesso.
Soluzione: o non aggiorni domoticz oppure aggiorni domoticz e
tutto il sistema.
Occhio che se il pacchetto di domoticz non fa parte del repo
ufficiale potresti incorrere anche nel porblema opposto, ovvero
aggiorni tutto il sistema e il pacchetto di domoticz che non fa
parte del parco software ufficiale, risulta più vecchio.
Anche lì potrebbe essere che disgraziatamente domoticz, si aspetta
di trovare la libreria:
 
lib_Z.so.1.0.2
 
e invece non se la ritrova più, perché nell'aggiornare il sistema
tu hai rimosso la libreria vecchia e ora c’è ad esempio:
 
lib_Z.so.1.4.0
 
 
 
Potrebbe essere utile al topic dare qualche dettaglio in più:
 
1. di che sistemi stai parlando, lo stesso su tutte e 3 le macchine?
 
2. come installi domoticz? È compreso nei repo ufficiali?


Perché sta aumentando la complessità. Giustamente cercano di stare al 
passo con i tempi, ovviamente aumentando la complessità aumentano i 
problemi. Trovavo le versioni precedenti di ubuntu decisamente più 
stabili. Ultimamente mettere a punto un sistema linux è più complicato, 
concordo.


Non sono utente ubuntu abituale, ci ho messo mano solo qualche volta
ed ora è passato già del tempo, ma l’ultima volta ricordo che avevo
sistemato qualcosa via systemctl, per cui c’era già systemd di default
(se non sbaglio post 2015?).
Se ho ben capito domoticz, non farebbe parte del repo ufficiale di
ubuntu. È un pacchetto che devi prendere da terze parti, per cui ci
può sempre essere una certa discrepanza tra lo stato di aggiornamento
del tuo sistema rispetto al sistema sul quale è stato prodotto il
pacchetto precompilato che installi.
 
Utilizzando slackware questo non capita così spesso per il banale motivo
che il pacchetto precompilato, ad esempio di domoticz, non lo trovi
proprio.
Quindi sei obbligato a compilarlo in locale, e l’operazione ha il
vantaggio di produrre un pacchetto tagliato e cucito per il tuo
sistema... Gli svantaggi sono altrettanto evidenti in termini di
tempo e scomodità, il tutto da rifare qualora si voglia aggiornare
il software in questione.
Compilarselo autonomamente può essere anche complicato, oppure semplice
se lo ha già fatto qualcuno affidabile. Su slackware ad esempio c’è
 
slackbuilds.org
 
 
Che raggruppa e mette a disposizione gli script per compilare il
tale programma ed ottenerne così un pacchetto installabile. Vengono
mostrate le dipendenze ecc ecc.
Ci sono poi alcuni tool che si occupano di accedere al repository
degli slackbuilds e scaricarli ed eseguirli. In soldoni, se ci fosse
domoticz su 
slackbuilds.org
 (ma non c’è), per installarlo su slack
si potrebbe fare:
 
sqg -p domoticz
sbopkg -i domoticz
 
Il primo genera una coda di pacchetti da produrre prima di domoticz
per soddisfarne le dipendenze.
Il secondo invece compila, pacchettizza e installa effettivamente
domoticz: più si ha un PC potente meglio è per lo scopo, così i
tempi si restringeranno.
 
Perché funziona in modo abbastanza stabile:
 
- perché il pacchetto prodotto è testato dal mantainer dello slackbuild
  e dalla community, così come la procedura di compilazione.
 
- perchè durante la compilazione si va ad appoggiare alle librerie
  che si hanno sul sistema. Questa non è una garanzia, va detto, perchè
  sul mio sistema potrei aver installato una libreria in modo non
  standard... Gli slackbuilds di SBo però sono testati su slackware
  “vanilla”, non rimaneggiata nel suo parco software di base, quindi
  se si resta in questi binari, raramente saltano fuori grossi problemi.
 
Cosa può andar storto?
Esempio:
esce la nuovissima versione di domoticz e voglio assolutamente provarla,
così la scarico, me la compilo magari usando un vecchio slackbuld
modificandone la versione nello script, così all’acqua di rosa.
Ecco in questo caso è abbastanza frequente che qualcosa vada storto:
ho usato la ricetta per fare la torta di mele acerbe, ma l’ho usata
con le mele mature!
In soldoni dovevo testare il vecchio slackbuild con la nuova versione
di domoticz, vedere che files crea ecc ecc, cioè fare quello che
solitamente aveva già fatto il maintainer dello slackbuild.
 
Soluzione:
 
1. se non ci sono reali necessità e si vuole star tranquilli, NON
aggiornare domoticz all’ultimissimissima versione qualora non vi
sia per il proprio sistema un pacchetto abbastanza testato e maturo.
 
2. se si vuole aggiornare comunque, meglio compilarselo in locale
che installare il primo pacchetto che capita, anche se rilasciato
direttamente da chi rilascia il software stesso. Poi qua bisogna vedere
di caso in caso, per domotic non lo so... Magari rilasciano un pacchetto
più che valido. Certo, se si pianta parto già un po’ prevenuto.
 
 
In ogni caso non condivido troppo il discorso sull’evoluzione di
Linux, anzi direi quasi per niente.
Da utente che deve avere un PC funzionante e pronto all’uso di un
parco software più che vasto rilevo invece che dal 2016 quando avevo
installato slackware l’ultima volta sull’allora nuovo SSD, ha sempre
girato alla grande senza mai perdere un colpo.
Ovviamente se si vuole installare qualsiasi cosa terza, rispetto al
parco software ufficiale, soprattutto senza prestre attenzione a quale
sia l’affidabilità della fonte che rilascia il pacchetto, ecco che
si ricschia di rompere facilmente, non dico il sistema, ma più che
altro il corretto funzionamento di quello specifico software.
Nel mio caso ho spiegato (anche troppo) qualche linea di condotta che
alla lunga mi sembra pagare in termini di stabilità.
Gli svantaggi ci sono se il ciclo di rilascio del sistema è un po’
troppo lungo... Capite bene che usare slackware 14.2, uscita nel 2016,
al giorno d’oggi, sottintende dover fare qualche rinuncia, in altro
post avevo raccontato di scribus nella versione di sviluppo, impossibile
da installare su slackware 14.2. Peccato non esista l’equivalente di
Debian testing... Cioè sì, c’è slackware current, che è all’ultimo grido
come software ufficiale e c’è anche iun repo di slackbuilds sperimentale
con gli script testati per quel ramo, ma il tutto è in continuo divenire
molto rapidamente, è il ramo di sviluppo d’altra parte.
In quel caso se tu aggiorni il sistema anche dopo un paio di mesi,
il resto del software installabile solo via slackbuilds, potrebbe
non funzionare più perchè magarri si appoggava a roba di sistema che
hai appunto aggiornato.
Per essere sicuri devi ricompilare tutta la roba terza, ricreandoti
pacchetto dopo pacchetto l’abituale parco software installato. È una
procedura automatizzata eh, la fai andare anche di notte per capirci,
se tutto fila liscio, ma impiega un bel po’ di tempo.
Alcuni usano un sistema virtualizzato per lo scopo:
- si fanno la lista del software terzo che hanno installata abitualmente
- aggiornano il sitema virtualizzato, ottenendo così tutto il software
  compreso nel set ufficiale in versione corrente.
- poi lanciano uno script che automaticamente lavora la coda di
  slackbuilds (che sono anche loro degli script alla fine) della lista
  fatta al primo punto.
- così hanno creato ed installato tutto il parco software abituale, sia
  i pacchetti ufficiali che terzi.
 
A questo punto si testa un attimo il sistema virtualizzato così ottenuto
e se tutto è ok si prendono i pacchetti prodotti e si aggiorna tutto il
proprio sistema reale.
Così facendo si ottiene un sistema sincronizzato col ramo di sviluppo
di qualche giorno prima diciamo, e corredato di tutto il software terzo
tagliato e cucito sullo stesso.
Se tutto va liscio si può anche tenere così per diverso tempo,
aggiornamenti di sicurezza permettendo.
 
L’operazione di ricompilazione si può anche eseguire su un server remoto,
lasciandolo girare senza problemi, sì c’è qualcosa da pagare, ma va be’,
poi lo si usa come una sorta di repo personale contenente i pacchetti
aggiornati.
Per sveltire le operazioni di ricmpilazione, si può anche impiegare un
sistema di cache tipo ccache: se le ricompilazioni non differiscono troppo
dovrebbe accorciare di parecchio i tempi, ovviamente prendendo però un
bel po’ di spazio disco, che in remoto può avere anche un certo prezzo.

 che non sto cogliendo.
 
Le cose cambiano rapidamente, se un software
non e` mantenuto, si deteriora e marcisce...
 
bye,
 
-- 
 
piergiorgio

Ti ho seguito nelle prime righe... non devo compilare proprio nulla, di 
certo riscontro differenza di stabilità tra la 16.04 LTS e la 20.04 LTS.
Per esperienza diretta ho impiegato meno con la prima anche perché 
alcune mi segnalazioni non sono state risolte e quindi quando mi trovo 
nella situazione di specie il sistema si blocca. Si tratta di un 
problema con la sk video ed altri "ammennicoli" che mi hanno portato via 
un sacco di tempo.
Per il resto grazie delle info, anche se non richieste.
Potrebbero essere utili in futuro.
Ciao.


 un sacco di tempo.
 
Eh ma allora domoticz potrebbe centrare poco, potrebbe essere solo un
effetto di una causa più profonda.

 
Ehmmm non sono io a dover installare DOMOTICZ... Avevo dato una risposta 
più generale... ;)


Sì ma il senso del mio discorso era anch’esso più generale: non c’entra
così tanto la “complessità”, i sistemi operativi sono sempre stati una
roba complessa per definizione, con i dovuti distinguo in termini di
“astrazione” che, questo sì, nel tempo è cambiato.
Ma se il sistema è instabile, dipende principalmente da chi lo
usa/amministra, in particolare nell’esempio di domoticz, ma vale in
generale per ogni altro pacchetto non incluso nel parco software del
repositry ufficiale della distribuzione, ti devi “fidare” di chi ha
prodotto quel pacchetto precompilato e non hai garanzie sulle
specificità del sistema sul quale lo ha compilato e della sua coerenza
col sistema di destinazione.
 
Può essere che il ciclo di sviluppo di ubuntu sia cambiato nel tempo
e adesso un certo ramo tipo 2020_LTS o come si chiama venga rimaneggiato
più di frequente, rispetto a qualche anno fa... Non lo so e se parliamo
di rami “stabili” mi pare un po’ strano, ma ripeto non conosco bene le
consuetudini ubuntu.
Se devo dire, da utente slackware, qui le cose sono andate all’opposto,
ovvero solitamente usciva una nuova realese stabile ogni anno emmezzo
circa, 2 anni o così. Ora invece ci troviamo ancora con la stabile,
14.2, rilasciata nel 2016!
Come spiegavo siamo al problema opposto: la stabilità è indiscutibile,
una roccia, ma software attuali in parecchi casi non li puoi proprio
installare, e questo per uso desktop non va bene, diciamo che siamo al
limite insomma.
È anche vero che slackware è gestita despoticamente da un uomo
solo al comando ed esce rigorosamente quand’è pronta, quindi non si può
paragonare al ciclo di sviluppo a rilasci “forzati” di ubuntu o al
modello bazar di Debian o Arch, o ad altre distribuzioni che sono in
qualche modo legate, parlando di ciclo di sviluppo a società importanti,
vedi opensuse, fedora, centos, ma anche la stessa ubuntu ha dietro una
grossa azienda.
 
In sintesi, dire che linux inteso come “le distribuzioni linux in
genere”, a causa di una presunta maggiore complessità, di non si
capisce bene cosa, è di per se meno stabile rispetto ad anni fa non
ha molto senso.
Come non ha molto senso riferirsi in generale a “le distribuzioni
linux”, perché di fatto si basano tutte su kernel linux, comprendono
software anche simili, ma poi sono sistemi profondamente diversi
l’uno dall’altro, a partire dalla gestione del ciclo di sviluppo,
da quanta gente ci collabora, da quali decisioni vengono prese circa
l’introduzione o meno di certi software per gestire pezzi del sistema
ecc ecc ecc...
 
La mia risposta circa domoticz, invece è vera per qualsiasi sistema
e per qualsiasi pacchetto extra ufficiale:
 
- esiste un repo ufficiale con un parco software ufficiale
 
- esistono software terzi non compresi che se installati via
  pacchetto precompilato, possono funzionare come no.
 
E questo diepende dalla coerenza sistema/pacchetto terzo, NON dalla
stabilità del sistema in sè.

 “astrazione” che, questo sì, nel tempo è cambiato.
 
Dipende da come misuri tu la complessita`.
 
Non mi dirai che il DOS e` complesso tanto
quanto Win10?
 
Oppure confronti il DOS con i programmi della
sua epoca e Win10 allo stesso modo?
 
In ogni caso, la complessita` e` aumentata e
questo e` parte del problema.
 
Un sistema di 20 anni fa aveva 4 librerie in
croce per funzionare.
Adesso ne ha 400.
 
La probabilita`	che una di queste 400 librerie
venga aggiornata in modo incompatibile con un
qualche programma e` 100 volte maggiore che 20
anni fa...
 
bye,
 
-- 
 
piergiorgio

 anni fa...
 
Ma perché deve venire aggiornata?
Lo decide sempre l’utente o l’admin del sistema no?
Se agiornano il repo mica devo aggiornare anche il sistema,
entro certi limiti.
Se io aggiorno il sistema, può essere che sia aggiornato
anche il pacchetto terzo precompilato vedi esempio di
domoticz, se è un pacchetto di terze parti ma ben manutenuto
non dovrebbero esserci problemi.
 
Esempio:
 
https://alien.slackbook.org/blog
 
 
Eric Hameleers (aka AlenBob)
Mantiene un repository di pacchetti compilati per slackware.
Ogni pacchetto è creato su un sistema slackware “vanilla”,
ma aggiornato.
Quindi se tu aggiorni la tua slackware, poi ti scarichi il
pacchetto dal repo di alienbob, il tuo sistema dovrebbe essere
diciamo sincronizzato con quanto si aspetta di trovare il
pacchetto del repo di alienbob.
Se tu hai un pacchetto di alienbob installato, aggiorni il
sistema, ma non aggiorni il pacchetto... Ecco che in teoria
non va bene, poi magari funziona lo stesso però non è garantito.
 
Di certo se avessimo tutti i software rilasciati dal repository
ufficiale della proporia distribuzione, questo inghippo non ci
sarebbe, perché chi mantiene un pacchetto, quando lo aggiorna o vi
apporta modifiche testa che il tutto funzioni stabilmente insieme
al resto del parco software della distribuzione.
Purtroppo non è così, e non può esserlo... troppi software, e
pochi maintainers!
Allora la responsabilità di un sistema stabile in gran parte
è nelle mani dell’utente/admin: è lui a dover aggiornare in
modo coerente le cose, al limite come spiegato, anche ricorrendo
alla compilazione in locale di un eventuale software, qualora il
pacchetto di terze parti non fosse al passo con gli aggiornamenti
del sistema o viceversa qualora non si volesse aggiornare l’intero
sistema pur volendo provare l’ultimo rilascio di un software.
 
Di certo se aggiorno il sistema “core” devo anche aggiornare
i pacchetti installati in più.
Come ho detto al limite per garantirne la coerenza si possono
compilare sul sistema in uso in modo che il pacchetto prodotto
vada ad appoggiarsi alle librerie effettivamente presenti sul
sistema stesso.
 
Portato all’estremo questo ragionamento credo sia simile a
quanto previsto da portage di gentoo, dove tutto è compilato
in locale. Ovviamente può non essere sempre motlo pratico e
veloce, ma ci sono i suoi vantaggi.
 
Un’alternativa è l’utilizzo di pacchetti compilati staticamente,
che girano per conto loro senza appoggiarsi a librerie di sistema
condivise. Anche lì, con vantaggi e svantaggi.
 
Per quella che è la mia esperienza ho avuto qualche inchiodamento
di firefox che installo precompilato: mi accade quando scelgo di aprire
un file con un applicazione di sistema invece di scaricarlo.
Non ho indagato perché accade... Comunque si chiude solo il browser,
il sistema continua a girare tranquillo.
A parte questo devo dire che freeze di sistema non ne ricordo di
averne scontrato.


beh in primo luogo un caso mi sembra un po' poco per fare una generalizzazione.
in secondo luogo se un software non è installato dal repository da cui provengono gli aggiornamenti è plausibile che non sia testato con i suddetti aggiornamenti (non vedo come potrebbe esserlo).
in terzo luogo se un software ha un bug che rompe la compatibilità non si capisce perché la colpa sia di tutto il resto del sistema e non sua.
in ultimo, non si capisce l'affermazione "funge solo con un sistema sempre aggiornato". cosa vuol dire? quando hai una configurazione stabile poi smette di funzionare quando compaiono degli aggiornamenti disponibili e non installati?
 
 
 

 non dovrebbero esserci problemi.
 
Di solito (ma non sempre), quando una
distribuzione aggiorna un pacchetto,
chesso' una libreria, aggiorna anche
tutto quello che dipende da esso (od essa).
 
Quindi, salvo imprevisti, tutto dovrebbe
funzionare sempre a dovere.
 
Qualcuno, pero`, deve prendersi cura della
cosa, se questo non succede, il *rischio*
che il SW non funzioni e` *piu`* alto oggi
per via della maggiore _complessita`_
rispetto a 20 anni fa.
 
bye,
 
-- 
 
piergiorgio

 anni fa... 
 
la gestione dei pacchetti nelle distribuzioni non è così sprovveduta.
i software dichiarano tutti le loro dipendenze con tanto di versioni e giornalmente vengono compilati e testati a fronte di queste versioni (le cosiddette nightly build). 
se una libreria "rompe" la compatibilità viene avanzata di versione: tutti i software che vogliono adeguarsi a questa nuova versione devono aggiornare la dipendenza, altrimenti rimangono legati alla precedente. 
ora se la nuova versione della libreria va in sostituzione della precedente, il software dipendente non si compila. quindi l'aggiornamento non passa il test di integrazione e non viene rilasciato.
infatti nelle distribuzioni non rolling gli aggiornamenti di sistema che rompono le compatibilità vengono fatti solo al rilascio di una nuova distro release, dove i software non compatibili vengono rimossi.
ora al netto di bug (che nessuno nega ogni tanto capitino) la situazione non è affatto così fuori controllo come tu lasci ad intendere. infatti nei rami stable delle distro principali la norma è che gli aggiornamenti vadano lisci come l'olio.

 la gestione dei pacchetti nelle distribuzioni non è così sprovveduta.
 
Per prima cosa, l'argomento non e` ristretto
ai pacchetti delle distribuzioni.
 
Secondo, la *probabilita`*, indipendendentemente
da tutto i provvedimenti, e` _maggiore_.
 
Il fatto che i build siano "smart" non riduce
la probabilita` di incompatibilita` all'aumentare
della complessita`.
 
bye,
 
-- 
 
piergiorgio

 della complessita`. 
 
la continuous integration certo riduce la probabilità di introdurre incompatibilità fra pacchetti, è fatta apposta. ma non è solo quello. le distribuzioni linux non sono luoghi anarchici dove ogni maintainer di progetto spara dentro aggiornamenti a propria discrezione. se un aggiornamento non è pienamente retrocompatibile non finisce in un update intermedio, ci sono regole di versionamento semantico e questo vale soprattutto per le librerie di sistema. 
d'altra parte se lo scenario fosse quello che dici te linux sarebbe un marasma inutilizzabile. ma non è così. stiamo discutendo, eventualmente, di un caso singolo.
 
 

 d'altra parte se lo scenario fosse quello che dici te linux sarebbe un marasma inutilizzabile. ma non è così. stiamo discutendo, eventualmente, di un caso singolo.
 
Dipende da cosa intendi con "inutilizzabile".
Dalla mia esperienza, i SW commerciali sono
spesso inutilizzabili.
Infatti si sono inventati "snap" o "flatpack",
proprio per risolvere queste cose.
 
Inoltre, abbiamo gia` distinto tra pacchetti
della distribuzione ed altri.
 
Qui il problema sono gli altri, si spera
che la distribuzione faccia il proprio
lavoro come si deve.
Anche per loro pero`, e succede, a volte
le cose non vanno come devono.
Ed oggi succede molto piu` spesso di una volta.
 
Per i SW commerciali, binari, invece, la
situazione e` molto cupa.
 
Per esempio, tempo fa usavamo un SW commerciale
per creare pipeline per analisi di dati.
Questo consente di scrivere "plug-in", ma
richiedeva una specifica versione di "gcc",
per compilare tali plug-in.
Gli aggiornamenti di sistema avevano portato
a gcc incompatibili e noi ci siamo ritrovati
a doverci compilare la versione giusta di gcc
incluse tutte le librerie dipendenti (OpenCV,
per esempio).
E non si puo` evitare gli aggiornamenti, perche`
altrimenti non funziona piu` niente.
 
Questo fenomeno e` comune a molti SW commerciali.
 
bye,
 
-- 
 
piergiorgio

 rispetto a 20 anni fa.
 
No, guarda taglio qua perché ti ha già risposto
rootkit in modo esauriente.
La chiave del discorso è il ciclo di rilascio della
singola distribuzione, ci sono versioni di distribuzione
che annullano quel problema, come ti ha spiegato rootkit.
Ed altre versioni più “bleeding edge” in cui ci può essere
il problema. Ma generalmente non si verifica se parliamo
di roba compresa nel parco software ufficiale. Esempio
anche Debian ha il suo ramo stable, blindato attraverso
un ciclo di testing e serrato del ramo "testing". Ma ha anche
appunto il ramo testing, che nonostante tutto raramente porta
a problemi del genere perché a monte del ramo testing c’è
l’untstable fatto apposta per testare lo stato di fatto a
livello di sviluppo.
 
Una cosa è il tuo sistema installato (S).
 
Una cosa è il repository ufficiale della distribuzione (R)
 
Un’altra cosa è il software non incluso nella distribuzione (X)
Di quest’ultimo bisogna distinguere quello open come ad esmpio
domoticz nel caso di ubuntu, non compreso ma anche compilabile da
sorgenti (Xopen).
E infine il software extra chiuso (Xclosed).
 
Per quanto mi riguarda non sono mai incappato con slackware
stbile in un problema di coerenza tra pacchetti che fanno parte
di R.
Mai una libreria di base dopo un aggiornamento di qulche altro
software R si è dimostrata non compatibile. Questo sia quando 
c’era un parco software più modesto che ora che c’è maggiore
complessità.
Questa stabilità deriva dal ciclo di sviluppo che come ti ha
detto giustamente rootkit, non è l’anarchia, ma ci sono sistemi
di controllo e verifica prima di integrare gli aggiornamenti
in un ramo stabile del rilascio.
Su slackware-current, che è il ramo di sviluppo di slackware,
gli aggiornamenti sono continui ovviamente, ma anche lì la
coerenza del sistema mi dicono che raramente dimostra problemi.
 
Il discorso invece cambia quando hai a che fare con un pacchetto X.
Se è manutenuto bene, X dovrà essere sempre coerente con la
distribuzione R, nel caso in cui gli sviluppatori ne mettano a
disposizione una versione precompilata per funzionare sulla
stessa distribuzione R:
se gli sviluppatori della distribuzione aggiornano R in qualche sua
parte, il maintainer del progetto X, che con la distrubuzione non
c’entra nulla, deve quanto prima ricompilare il suo pacchetto su un
sistema identico a quello rilasciato attraverso R e testarlo.
 
L’utente d’altra parte se vuole aggiornare X deve prima aggiornare
S allo stato di fatto di R. Poi può installare X dal pacchetto
precompilato che rilasciano gli sviluppatori del progetto X, o i
maintaiers che si occupano di adattare X alla distribuzione R.
Questo passaggio è più spinoso, perché la garanzia che X precompilato
sia coerente con R e quindi con S appena aggiornato in teoria non c’è,
poi in pratica se parliamo di un software con uno sviluppo attivo e
di uso popolare la garanzia praticamente c’è.
 
Ad ogni modo ecco che si vede la differenza tra Xopen, che può
quasi sempre essere compilato su S sia che S sia aggiornato al
passo di R o meno (questo non è sempre vero se S è davvero
troppo vecchio rispetto alle versioni delle librerie richieste
da Xopen, ma per i sistemi recenti non si dovrebbe porre il
problema; si pone quando voglio installare un software troppo
recente rispetto alla mia distribuzione esageratamente vetusta).
 
Invece se si vuole un Xclosed, software commerciale, si ha sempre a
che fare con un precompilato e lì la stabilità o meno non dipende nè
dal numero di librerie, nè dalla complessità del sistema nè niente,
dipende solo dallo stato di mantenimento del precompilato Xclosed
rilasciato dalla software house, che con la distribuzione R non
c’entra nulla. Anche loro devono rilasciare un pacchetto precompilato
che funzioni su un sistema aggiornato con R. E l’utente deve assicurarsi
che il suo sistema S sia aggiornato anche lui con R.
 
Non credo di aver aggiunto niente a quanto ha già spiegato rootkit
nell’altro messaggio e a quanto avevo già scrittp nei miei.
Tralascio l’esempio che facevi del DOS, mi pare c’entrar poco con
l’argomento librerie condivise e mole del software di sistema.
Poi i discorsi teorici, restano sempre appesi come salami se alla
fine non si concretizzano in pratica:
nella mia esperienza quando qualcuno lamenta un sistema instabile
quasi sempre si è trattato di un problema di utilizzo/amministrazione
del proprio sistema installato (S), piuttosto che del rilascio della
distribuzione (R).
Tornando all’esempio iniziale:
aggiorno domoticz senza aggiornare il sistema?
Se qualcosa non va, devo dire mea culpa, non darla alla complessità
del parco software.

 altrimenti non funziona piu` niente. 
 
a parte questo scenario in cui un sistema stabile e funzionante che ad un certo punto non funziona più niente perché compaiono aggiornamenti non l'ho capito, ad ogni modo se serve mantenere una specifica versione gcc sappi che la si può bloccare. 
ma si tratta comunque di situazioni particolari, nelle pipeline servono ambienti immutabili e per questo spesso si usano le immagini docker. 

 che annullano quel problema, come ti ha spiegato rootkit.
 
E questo e`, ovviamente, falso.
 
Non e` un modello deterministico.
 
Infatti, come gia` scritto, non
funziona sempre.
 
Il motivo e` che, sempre come gia`
scritto, la complessita` e` tale
per cui la _probabilita`_ di un
errore e` piu` alta che in passato.
 
Ed e` pieno di esempi di SW che non
funzionano causa aggiornamenti,
incluso l'esempio di questo thread.
 
Cosi` come e` pieno di esempi di
distribuzione che eliminano SW perche`
non sono in grado di aggiornarlo in
seguito ai cambiamenti di librerie.
 
Quindi, tutto il discorso su come viene
*ben* gestito il sistema di pacchetti
lasciano il tempo che trovano.
 
bye,
 
-- 
 
piergiorgio

 ma si tratta comunque di situazioni particolari, nelle pipeline servono ambienti immutabili e per questo spesso si usano le immagini docker. 
 
Certamente, vi sono innumerevoli
_fastidiose_ soluzioni al problema.
 
Resta il fatto che c'e` un problema.
 
Il semplice fatto che esista docker,
snap, virtualbox o quant'altro e`
un'indicazione che la complessita` e`
tale da richiedere "fix" per tutti i
problemi che comporta.
 
bye,
 
-- 
 
piergiorgio

 seguito ai cambiamenti di librerie.
 
Eh... ma non mescolare capre e cavoli, se lo eliminano
non c’è nulla che non funziona, la distribuzione continua
ad essere coerente e funzionante. Il problema è se ti serve
quel software. Ma questa è proprio la dimostrazione che
nonostante la complessità c’è un lavoro dietro che assicura
che i rilasci, almeno nei rami stabili, provvedano ad fornire
un sistema coerente, persino  al prezzo di eliminare un
software dal repository.

 averne scontrato.
 
Anch'io ho un'esperienza simile, probabilmente sarà perché linux è 
strutturato per continuare anche nei momenti più complessi in cui ci 
sono vari blocchi di programmi. Chiaro che se ti compili sulla tua 
macchina specifica, con i driver giusti, configurazioni personalizzate, 
accorgimenti che sono sopra la media, i risultati sono migliori.
Mi domando: quanto tempo ci dedichi sopra?
Già per la mia, non arrivando a questi livelli di dettaglio, richiede 
tanto tempo... ;)


Condivido. I bug ci sono e più frequenti di quanto sperassi, 
generalmente risolti in tempi accettabili.
Dipende anche dalla complessità del software che poi ci si fa girare 
dentro la macchina. Confrontata ad altri S.O. non sono così 
drammaticamente presenti, condivido.

 problemi che comporta.
 
Per software commerciali o comunque a sorgente chiuso
e dipendenze non e' male usare AppImage.
 

 ma tu hai notizia che avvenga una cosa del genere nelle principali distribuzioni? cioè che una libreria di sistema si aggiorni in modo non retrocompatibile durante un normale upgrade?
 
Con ubuntu 18.04 ( mi sembra, non ricordo esattamente quale) è stato 
deciso di usare un certa libreria versione experimental invece che la 
standard.
 
una bella serie di scanner ( tra cui il mio epson) e di stampanti sono 
diventati inutilizzabili e per far funzionare il mio scanner sono dovuto 
andare a  configurare ( tra gli altri)  /etc/udev/rules.d/45-libsane.rules.
 
Prima di questa geniale pensata era sufficiente installare 3 file.deb 
scaricati dal sito-linux di epson.
 
Ovviamente  tutto nel interesse del utente che essendo fondamentalmente 
stupido va catechizzato obbligandolo a configurare e scaricare una bella 
serie di file perdendo un intero pomeriggio

 tanto tempo... ;)
 
Specifica pure...
 
Nel caso di firefox io uso uno script chiamato latest-firefox.sh che
produce un pacchetto dell’ultima versione del browser, partendo dai
binary rilasciati da mozilla... quindi un precompilato.
Il pacchetto ufficiale di slackware stabile per firefox è ad una
versione ben precedente. Quindi anche qui, mea culpa.
 
Potrei compilarmi firefox dallo slackbuild di slackware-current, ma
immagino sia un po’ troppo lunga e la garanzia che non ci sia qualche
altro punto che porti a quell’errore non ce l’ho per cui per pigrizia
me lo faccio andare bene così perché fondamentalmente alla fine si
tratta di un problema solo marginale per quello che mi serve.
 
Mah guarda che anche senza configurare granché se non hai esigenze
molto particolari, in termini di tempo-uomo basterebbe lanciare una
roba anche così al volo:
 
mkdir build-mozilla-firefox
lftp -c 'open 
http://slackware.osuosl.org/slackware64-current/source/xap/
; mirror -c --use-pget-n=8 mozilla-firefox .
sh ./mozilla-firefox.SlackBuild
upgradepkg /tmp/mozilla-firefox-78.2.0esr-x86_64-1.txz
 
Tempo-macchina invece sì, devi attendere un sacco. Dipende molto
dal tuo hardware cpu in primis.
Ma se l’utente ci deve lavorare diciamo per uso desktop medio,
anche se aggiorni una volta al mese o ogni 2 mesi non ti cambia
mica la vita. Alla fine si può fare. Specie se mi parli di utenza
media, che per la maggior parte svolge mansioni uso ufficio e non
sta lì a smanettare tutti i giorni giustamente.
 
Spiegava poi bene rootkit, che fondamentalmente anche software
terzi preompilati difficilemnte hanno problemi con l'ultima
versione di una distribuzione che sia aggiornata l'altro giorno
o un paio di mesi fa...
Alla fine è la pratica quello che conta.
E tutto questo topic sembra nascere da voglia di discutere dei
massimi sistemi: era meglio che l'OP che non ricordo chi fosse
piuttosto dedicasse il tempo alla ricerca delle cause specifiche
della instabilità rilevata o delle continue richieste di
aggiornamenti di sistema.

 problemi che comporta. 
 
direi proprio di no. gli ambienti di virtualizzazione (virtualbox, qemu/kvm, xen) e containerizzazione (docker, podman, cri-io) hanno la loro ragion d'essere che poco o niente ha a che vedere con la complessità, al limite snap ma anche qui vorrei farti notare che ci sono aspetti predominanti come isolamento e sicurezza degli applicativi. ricordo che gli applicativi snap girano in una sandbox isolata e accedono alle risorse della macchina host secondo precise policy.

 Che linux hai?
 
un utente avanzato può avere esigenze particolari. per esempio se ho compilato dei moduli custom probabilmente non voglio aggiornare il kernel ogni volta che arriva. ma anche che so, il docker runtime ho bisogno di tenerlo fermo ad una certa versione.
 

 secondo te a che serve questa politica?
 
Sì be’ supporto e stabilità rispetto al parco software
che mantengono direttamente, il resto dello scibile umano
è garantito dalla condotta e dalle scelte dell’utente, e
da chi mantiene e adatta software terzi alla distribuzione
in questione.
 
Un po’ diverso potrebbe essere il caso delle rolling releases
tipo arch, in quel caso non so granché di come tengano tutto
insieme.
Stessa situazione di alcuni utenti che usano slackware-current
in pianta stabile. È in teoria il ramo di sviluppo di slackware,
ma in pratica dicono sia tranquillamente utilizzabile anche
come sistema quotidiano, limitatamente a destinazione desktop,
non server ovviamente. Di fatto il ciclo anche lì è rolling
release.

 lasciano il tempo che trovano. 
 
veramente il discorso è su come venga *mal* gestito. io e joe al limite ci limitiamo a confutare, argomentando. non è che siamo noi intervenuti a dire "guardate qui come son bravi quelli di linux, non sbagliano un colpo!". 
 


pensa che per usare lo scanner di rete epson (wf 2510) non ho installato ne configurato *niente*. 
ne la 18.04 ne la 20.04.
per la stampante ovviamente i driver di stampa.
mi spiace per quanto accaduto e che non posso condividere l'esperienza, forse sarà che non sono "fondamentalmente stupido".