Quote:
Originariamente inviato da Tasslehoff
Guarda, onestamente io licenzierei prima quelli che permettono ad ambienti di produzione di girare su distribuzioni obsolete anche se considerate rock solid  |
Non ho scritto il contrario. Nel momento in cui il supporto scade e non ci sono aggiornamenti di sicurezza, la macchina va rifatta. Spesso non viene fatto perché i sistemisti sono pagati a cottimo ed il cummenda di turno non vuole sganciare soldi "perché tanto funziona, perché toccarlo?"
Quote:
Originariamente inviato da Tasslehoff
Poi chiaro, parlo di sistemi su cui devono girare dei servizi, per cui che Gnome o il tal servizio per l'audio posizionale siano instabili non mi interessa, perchè comunque sulla macchina a cui mi riferisco non installerò nemmeno quella roba.
Chiaramente prima di installare Fedora o Debian Sid ci sono millemila alternative considerate più adatte, però il mio post era solo per dire che se si devono far girare dei servizi anche quelle distribuzioni "bleeding edge" non crashano ogni due per tre, tutt'altro, idem CentOS Stream (che sappiamo bene non essere "bleeding edge").
|
Non aggiorni l'OS di un server ogni 6 mesi rifacendo la macchina proprio perché non vuoi dover ritestare gli applicativi su uno stack software (OS+libs) differente. Usando Centos stream, uno yum update in pratica ti installa le nightly builds di RH, sei veramente così entusiasta di fare la cavia in ambienti di produzione?
Poi quando tutto sarà containerizzato e l'host sarà solo un "lancia container", allora questo discorso sarà superato. Purtroppo non è ancora così.
Quote:
Originariamente inviato da Tasslehoff
Tra l'altro a me spesso capita di trovare server su cui è stata installato CentOS o Rhel, o Ubuntu LTS, e va benissimo... poi però per far partire il tal servizio o per soddisfarne le dipendenze puntualmente ci sono package presi dai repository yum o apt più sconosciuti o controversi, o che cmq sono tutt'altro che "conservativi".
E spesso questo è inevitabile perchè cmq i package di quelle distro sono estremamente obsoleti e oggettivamente insicuri, ok ci sono anche repo alternativi ufficiali (o pseudo-ufficiali) con release più recenti dei package, e credo siamo tutti d'accordo nel considerarle alternative valide... però vedi che già ci siamo allontanati parecchio da quell'alone mistico di "stabilità" per cui si è scelto la tal distribuzione? |
Repo sconosciuti e controversi === peracottaro. Se hai bisogno di lib molto diverse per i tuoi servizi o ospiti servizi eterogenei sullo stesso server, vai di virtualizzazione/containerizzazione oppure di compilazione statica delle lib.
Quote:
Originariamente inviato da Tasslehoff
Lasciami aggiungere un'ultima cosa, ricordiamoci che 99 volte su 100 i problemi nascono sempre da criticità applicative, eccezioni non gestite, codice scritto a "membro di segugio", logica applicativa grossolana o architettura pensata male (tutte cose che spesso non nascono da incapacità di chi le ha realizzate, ma dalle pessime condizioni in cui costui è stato messo a lavorare, scarsità di risorse, tempo insufficiente, specifiche e obbiettivi che cambiano in corso d'opera etc etc...  ), dalla mia esperienza il sistema operativo è veramente l'ultima cosa che può generare un problema vero. |
Come dici, non è solo il sistema operativo, ma è anche il set di dipendenze a corredo.
Ti dico cosa ho visto spesso in giro: server con versione di ubuntu non LTS, server con fedora non aggiornati e non aggiornabili pena applicativi che si spaccano. In quel caso, non avendo OS stabile e supporto per anni, sei fottuto e ti tocca rifare la macchina e metter mano agli applicativi.
Centos Streams va avanti con rolling release e gli aggiornamenti sono le nightly builds di RH.
1. Puoi trovarti in situazioni dove gli aggiornamenti ti spaccano gli applicativi installati e ti tocca capire cosa ha spaccato cosa e perché e fare rollback degli update.
2. Tu sei veramente tranquillo sapendo che sul server ci finiscono delle nightly builds? Ok che sono NB di RH, ma cavolo, son sempre NB.
Insomma, come non userei mai una Ubuntu non LTS o una Fedora, non installerei mai CentOS Stream su un server. Discorso diverso sul desktop personale dove, anche se si spaccasse qualcosa dopo un aggiornamento, potrei velocemente fare rollback senza far andare down servizi esposti.