Newsgroup: it.comp.os.linux.iniziare
Titolo: Slackware, 30 anni e non sentirli

ma come vola il tempo ...:
 
http://www.slackware.com/announce/1.0.php
 
 

 
http://www.slackware.com/announce/1.0.php
 
 
Ad un ann'e mmezzo dall'uscita della 15.0, farebbe
piacere anche un nuovo rilascio nel ramo "stabile"!
Ché non solo il tempo, ma anche le innovazioni per
uso desktop volano! Go Pat! Go!  :D
 
Scherzi a parte, per ora si utilizza tranquillamente la versione
15.0 anche in uso desktop, poi va be' magari c'è anche chi ha
bisogno di roba all'ultimo grido e per adattarla alla stabile
farà un attimo più fatica... altrimenti c'è il ramo "current"
per i più temerari, sempre in sviluppo ma dicono decentemente
stabile. È che il ramo current, insieme al fatto che il parco
software ufficiale di slack non è molto ampio costringe a
compilare un sacco di roba terza non testata ufficialmente ad
esempio via SBo e quindi testarne in prima persona sia il build
che il funzionamento in runtime, il ché è un bene per la
community, ma è poco accettabile per un sistema che si vuole
utilizzare stabilmente come di dice "in produzione". D'altra
parte current è il ramo di sviluppo e cambia quindi di continuo,
per cui ad 1,5 anni dalla 15.0, non sarebbe male fare una foto
alle innovazioni apportate e rilasciare una 15.1 in tempi brevi,
ma si sa, chi comanda è solo uno e un solo subgenio.

 
http://www.slackware.com/announce/1.0.php
 
 
 
tanti auguri, ma... sul "non sentirli" avrei qualche dubbio.
tanto di cappello per la filosofia "semplice", pero' un package manager tipo apt servirebbe.
fosse cosi', la userei in produzione.


Fai una full install e sei apposto, fosse quello il problema...
Poi bisogna sempre vedere cosa devi "produrre".


infatti non penso sia quello il problema. 

 Poi bisogna sempre vedere cosa devi "produrre".
 
poi pero' devi aggiornare. e se un pacchetto, come mi e' successo diverse volte, aggiunge delle dipendenze rispetto a quelle che aveva prima... auguri.


Anche lì fai, un full upgrade e lato parco ufficiale non hai problemi:
 
slackpkg update
slackpkg upgrade-all
 
Questo entro lo stessa release esempio 15.0 dal mese scorso a questo
mese. In questo modo non esistono problemi di dipendenze nuove. È il
punto di forza del ramo stabile d'altra parte. Installi tutto e aggiorni
tutto, zero problemi col software ufficiale.
 
Quando devi fare un upgrade di versione esempio da 14.2 a 15.0 o
da 15.0 a ramo di sviluppo current, allora c'è qualche passaggio in
più da fare. Non riporto comandi perché si trova tutto su slackdocs
o altre guide wiki ecc... slackpkg per lo scopo è il tool ufficiale
riconosciuto alla fine anche da Volkerding.
 
Se parliamo di software di terze parti, il discorso è più complesso
ma lo è anche per per qualsiasi altra distribuzione. Sono d'accordo
che ad esempio Debian ha un parco ufficiale più vasto e questo è un
vantaggio. Per me non è un vantaggio così pesante, per altri può
esserlo.

 lo è anche per per qualsiasi altra distribuzione. 
 
non direi. i software di terze parti sono su repository di terze parti che 
vengono integrati nel database insieme a quelli della distribuzione. poi 
in fase di installazione/upgrade si comportano in modo esattamente uguale 
a quelli "standard".


Sì e no, in un mondo perfetto dovrebbe essere come scrivi, poi nella
pratica il repo ufficiale può ritrovarsi un po' più avanti rispetto
ai repo terzi, oppure in caso di repository contenenti script di
"build", vedi SBo con gli slackbuilds per slackware, AUR di arch con
i pkgbuild, o altri casi in cui è necessario mettere mano agli spec
di rpm ad esempio... be' in tutti questi casi l'aggiornamento non è
banale. Non è niente di trascendentale, ma occorre sapere, più che
altro ricordarsi, che un certo numero di pacchetti richiedevano un
rebuild più o meno manuale.
Per fare un esempio, ne avevamo parlato anche qui tempo addietro quando
un utente voleva attivare su mageia il decoding hardware via GPU nella
riproduzione dei video. Il problema era "mesa" che andava ricompilato
dopo aver attivato alcune voci nello script "spec" in cui di default
questa funzionalità non viene attivata per alcuni codecs a causa di
limitazioni della loro licenza. Quindi si ricompila e in quel caso si
ottiene un nuovo rpm che si va ad installare rimpiazzando quello
originale. È chiaro che quando l'utente va ad aggiornare il sistema,
se quel pacchetto verrà rimpiazzato dovrà andare anche a rieseguire
il rebuild di mesa altrimenti il decoding via GPU smetterà di funzionare.
 
L'unico modo per assicurarsi un sistema coerente è aggiornare solo
in tempistiche pianificate, e non tutti i giorni o appena esce un
aggiornamento. In questo modo hai un sistema ben collaudato per
tot mesi. Quando aggiorni, può andare tutto liscio, ma puoi anche
non accorgerti di aver "rotto" qualcosa e ritrovarti con qualche
pezzo non funzionante proprio quando ti serve. Questo proprio a
causa del software aggiuntivo, può anche capitare col software
ufficiale in teoria ma è raro, tieni conto che i maintainer dei
repo terzi quando esce un aggiornamento su quello ufficiale devono
eseguire un rebuild e testare i nuovi pacchetti, non è un'operazione
automatica, c'è dietro un testing che richiede un po' di tempo.
 
Parlando di "produzione" questo è un approccio abbastanza roccioso
in ambito desktop ufficio workstation. Se invece parliamo di sistemi
"critici" in termini di sicurezza è un altro paio di maniche, lì devi
aggiornare puntualmente il software ufficiale, ma in quel caso non
dovresti avere software bisogno di software di terze parti, dovrebbe
essere più che sufficiente anche quello ufficiale di slackware in cui
come per le altre distro il ramo stabile è mantenuto e aggiornato per
quel che riguarda i bugfix relativi alla sicurezza, e lo è anche dopo
l'uscita di versioni stabili successive. Ad esempio nonostante ora vi
sia la stabile 15.0, anche la vecchia 14.2 è ancora mantenuta, così
come le versioni precedenti, mi pare che la prima dichiarata end of
life, quindi dismessa sia la 13.37, per cui ancora la 14.0 può essere
ritenuta sicura (si parla di ambito non desktop, per quello sarebbe
roba vetusta ormai, la 14.0 era uscita nel 2012 o giù di lì).

 che ad esempio Debian ha un parco ufficiale più vasto 
 
Non e' che ho poi grosse esigenze, una volta che ho postgres, java, rust, smb e poco altro, sono felice.
 
adesso provero' a metterla su una VM in ufficio, si sa mai che torni al mio primo amore!


Ti consiglio di guardarti bene slackpkg per il software ufficiale.
C'è anche il suo "plugin" slackpkg+ per repo di precompilati di
terze parti come il repo di AlienBob ad esempio.
 
Per gestire i programmi che dovessi compilare da SBo (
slackbuilds.org
)
vediti bene "sbopkg" e il gestore di code di dipendenza "sqg".
 
Con questi tre tool te la viaggi già in modo piuttosto automatizzato,
poi a volte come scrivevo in altro post, può essere sempre necessario
mettere le mani sotto il cofano, ma in quello slackware è forse anche
più semplice di altre distribuzioni.

 dovresti avere software bisogno di software di terze parti, 
 
no, in realtà è abbastanza comune. ho citato docker ma potrei dire anche 
kubernetes, ma anche tanti software che sono inclusi nella distribuzione 
ma che per varie ragioni vuoi gestire in modo indipendente. 
a titolo di esempio: 
https://www.postgresql.org/download/linux/ubuntu/
 

 a titolo di esempio: 
https://www.postgresql.org/download/linux/ubuntu/
 
 
In produzione? Immagino siano installazioni che vadano ad affiancarsi
alla versione ufficiale in modo "isolato", perché se per qualche motivo
aggiungi un altro software terzo che s'aspetta postgresql ufficiale ma
trovasse solo la versione extra non hai garanzie che non saltino fuori
errori.

 errori.
 
uh? guarda che quello è proprio il sito di postgres, non è che sto 
installando una versione non ufficiale. e magari la installo da lì perché 
il software terzo vuole una versione che non è inclusa nella 
distribuzione.