Commenti & Opinioni


Home Page | Commenti | Articoli | Faq | Documenti | Ricerca | Archivio | Storie dalla Sala Macchine | Contribuire | Login/Register

Pacchettizzata o FaiDaTe?

Piu' che un commento questa e' una risposta ad una 'domanda' fatta da "Cinghiale Mannaro" (vedi Selce). La domanda, riportata qui' per chiarezza, e' la seguente:

Sono i sistemisti che devono mettere su le macchine con i requisiti che i programmatori richiedono (e li richiedono, a differenza dei CL di "davidiana" memoria, con chiarezza e precisione) o sono i programmatori che devono chiedere ai sistemisti CON COSA possono fare le loro applicazioni?

Prima di tutto una precisazione importantissima: i "miei" CL (in genere quando provenivano dalla Yugoslavia) specificavano chiaramente COSA volevano, ed il COSA era categoricamente l'ultimissima versione di qualunque cosa usassero. Il che andrebbe benissimo se non fosse che: 1) non ho un numero infinito di server a disposizione ne' la possibilita' di usare un singolo server per ogni applicazione 2) ogni singola applicazione e' "tarata" per una specifica versione di qualche cosa, ed ovviamente tale qualche cosa va' categoricamente in conflitto con qualsiasi altra versione diversa della stessa cosa (tipico il caso delle maledette librerie di parsing dell'XML), ergo: fare coesistere tutte le diverse versioni su una singola macchina diventa un problema 3) ogni qual volta la maledetta applicazione viene installata non funziona o qualche cosa d'altro smette di funzionare. E chi pensate che sia il povero pirla che deve andare a dare la caccia ai diecimila conflitti tra duecentomila diverse versioni di librerie?

Messa da parte questa precisazione andiamo ad esporre la mia opinione sull'argomento: sono i sistemisti o i programmatori?

Punto di vista del sistemista:

Se si utilizzano delle distribuzioni "pacchettizzate" lo si fa' perche' si vuole usare il meccanismo di aggiornamento della distribuzione il piu' possibile, in modo tale che, quando esce un'aggiornamento si sceglie "aggiorna" (o lo si fa' in automatico mediante uno script) ed il server si mantiene aggiornato da solo. Comodo per il sistemista che non deve correre dietro a tutte le versioni di librerie e perdere le giornate per installare l'aggiornamento di X (per qualunque valore di X). Soprattutto quando i server da mantenere sono tanti e sparsi per il pianeta.

Il rovescio della medaglia e' che la disponibilita' della versione X del prodotto Y e' limitata a quando la casa produttrice della distribuzione decide di metterla a disposizione. Non prima. Se si installa il prodotto senza seguire la procedura (aka: a manella) si rischia di 1) vedersi il prodotto disinstallato e rimpiazzato con una versione diversa al primo aggiornamento o 2) vedere un qualche altro pezzo del sistema smettere di funzionare causa lo stesso aggiornamento o 3) entrambe le cose.

L'alternativa e' perdere ore o giorni per ogni aggiornamento per essere sicuri che versione X del prodotto non entri in conflitto con tutto il resto del sistema, non venga spianata dall'aggiornamento automatico a versione X-1 e cosi' via. Oppure, molto banalmente, non si aggiorna il sistema. Il che e' possibile, ma non raccomandabile.

L'installazione "faidate" e' sempre fattibile se si tratta di un numero limitato di sistemi (il guaio e' che poi questi tendono a moltiplicarsi rapidamente) e se il sistemista e' un tipo efficiente e tiene accuratamente traccia di ogni 'particolarita' del sistema in questione (versioni particolari di librerie, path di installazione non-standard, modifiche a file di configurazione, switch o opzioni particolari di avvio per demoni e cosi' via). Tutto questo richiede un sacco di documentazione (che tende ad andare persa o banalmente non mantenuta) molta cautela e la voglia di leggersi il fottuto manuale prima di fare qualche cosa. Inoltre, se il sistemista in questione si ammala, finisce in ospedale o migra verso altri lidi e viene sostituito, c'e' sempre il pericolo che il nuovo sistemista guardi il server e pensi "eeeeck! questo coso e' vecchio come il cucco/non e' stato aggiornato!", infili il CD e....

Punto di vista del programmatore.

Dato che sto sviluppando una nuova applicazione, l'usare l'ultima versione del compilatore/ambiente/interprete e' la soluzione piu' logica, in alcuni casi e' l'unica soluzione percorribile dato che non era gia' installato da prima.

Quando si cerca di risolvere un qualche strano bug di cui non si riesce a rintracciare un motivo, aggiornare all'ultima versione le librerie o l'ambiente che si usa consente di ottenere migliori informazioni di debug e magari corregge l'errore di suo, quindi meglio tenere il sistema allineato con l'ultima versione.

I manuali e la maggioranza del codice di esempio che si trova in giro si riferiscono all'ultima versione, acquistare manuali sulle versioni precedenti non e' una cosa molto furba.

Ovviamente questi argomenti (perfettamente logici e plausibili) sono in diretto conflitto con quelli precedentemente esposti.

Poi c'e' il discorso "la macchina me la mantengo io tu non devi fare niente". Sorry, ma non funziona cosi'.

Il problema in questo caso e' RESPONSABILITA e CONTROLLO. Il sistemista e' responsabile dei sistemi, se non ne ha il controllo e' fottuto fin dal "via". Sul suo contratto c'e' scritto esattamente questo. Lui e' il responsabile, ergo se qualche cosa non funziona lui e' il primo che prende calci. Pertanto la linea "la macchina la gestisco io" entra in diretto conflitto con questo basilare concetto: se TU hai il controllo IO non voglio avere la responsabilita', ma me la devo prendere, pertanto TU non puoi prendere il controllo. Se il sistemista e' disposto a mollare il controllo c'e' qualche cosa di seriamente sbagliato nella sua testa.

Come si vede i punti sono parecchi, ed ognuno ha una sua importanza, certo dal punto di vista di entrambi e' molto semplice scaricare il problema. Per il programmatore e' molto semplice dire "questo e' quello che voglio e adesso sono cazzi tuoi", per il sistemista e' ancora piu' semplice dire "questo e' quello che abbiamo e adesso sono cazzi tuoi". Ma in questo modo perdono entrambi. Arriviamo quindi al punto finale: programmatore e sistemista devono cooperare.

La cosa migliore e' che i due si siedano intorno ad un tavolo, possibilmente con l'idea che e' meglio uscire dalla stanza con una decisione comune e non con un'ascia in mano e che o vincono entrambi o perdono entrambi, e cerchino di trovare un punto di comune accordo.

Quando potevo (mica tanto spesso), io usavo la seguente "check-list":

  1. Questa applicazione e' possibile farla funzionare usando la versione di $qualunquecosa che e' distribuita?
  2. Esiste un modo per adattarla o e' semplicemente impossibile? (se si tratta di scrivere alcune funzioni "ponte" lo si fa' una volta sola e basta)
  3. Quanto e' "critica"?
  4. E' pensabile di tenere il server non aggiornato finche' la versione giusta non viene distribuita ufficialmente?
  5. E' fattibile l'aggiornamento manuale del server? (aka: se qualche cosa va male il server probabilmente deve essere installato da capo)
  6. Possiamo avere un server dedicato a questa applicazione o dovra' essere condiviso con altre applicazioni?
    • Ci sono conflitti con quello che serve per le altre applicazioni?
    • E' possibile modificare tali applicazioni per farle funzionare con cio' che serve per questa applicazione?
  7. L'applicazione e' solo interna? (applicazioni interne hanno meno richieste di sicurezza)
  8. L'applicazione usa una versione di $qualchecosa particolare perche' fa uso specifico di cose che sono solo in quella versione o puo' usare la versione che e' gia' installata su un'altro server? (questo e' il caso particolare di databases: tra una versione ed un'altra ci sono differenze, ma se non si usa qualche cosa di specifico e' possibilissimo usare una versione diversa senza grossi problemi)
  9. E' possibile l'aggiornamento di $qualchecosa che e' gia' installato alla versione richiesta senza inficiare tutte le altre cose che lo usano?
  10. Ogni quanto deve essere aggiornata l'applicazione? (se deve essere aggiornata spesso il programmatore dovrebbe pensare ad un sistema automatico di controllo ed installazione delle librerie o altra roba che viene usata, una specie di "install" che eviti al sistemista di dover ogni volta controllare tutto da zero)

Il problema ovviamente si complica se altri attori entrano in scena. Se il database e' mantenuto da un DBA, questo deve essere incluso nella discussione, se il server e' mantenuto presso un centro-dati esterno o qualcun'altro si occupa di backup questo qualcuno dovra' essere consultato. E cosi' via.

In conclusione: non c'e' una risposta A o B. Sistemisti e programmatori devono (o dovrebbero) comunicare. Il problema e' che molto spesso il sistemista non ha mai fatto il programmatore per davvero e non ha idea di quanto sia una rottura di scatole il riscrivere del codice che funziona per adattarlo a funzionare con una libreria che non funziona, mentre il programmatore non ha idea di quanto sia una rottura di scatole l'aggiornare manualmente 10 servers per tenere dietro a 100 versioni diverse di librerie che vanno in conflitto le une con le altre.

Davide Bianchi
30/01/2009 10:12

 

I commenti sono aggiunti quando e soprattutto se ho il tempo di guardarli e dopo aver eliminato le cagate, spam, tentativi di phishing et similia. Quindi non trattenete il respiro.

7 messaggi this document does not accept new posts
anonymousboth sides Di anonymous - postato il 30/01/2009 10:12
purtroppo mi sono ritrovato su entrambi i lati della barricata:

1) mi servivano le python-gdata su un server debian e il sysadmin ci ha messo 1 ora per installare tra imprecazioni varie :-\) alla fine lui è un mito come sysadmin (non al tuo livello ma se la cava)

2)uno stupido autoaggiornamento mi ha sfanculato tutte le librerie Tcl...risultato i miei plugin per amsn non andavano piu :-\(

che dire....la verità sta sempre nel mezzo?

ps: ho scoperto il sito da una settimana e mi sono azzardato a postare dopo aver letto TUTTE le storie :-\) daje cosi D!!!!!

--
anonymous


Giulio BanterlaCollaborazione questa sconosciuta Di Giulio Banterla - postato il 30/01/2009 10:43

Eh, bella la soluzione.. peccato che in tanti casi la partenza sia questa, e poi lungo la strada si infilino in mezzo alla comunicazione un'altra serie di personaggi che vanno a mandare tutti i buoni propositi a $DONNE_DI_FACILI_COSTUMI!!

Esempio
P -> Programmatore
S -> Sistemista
Altre lettere dell'alfabeto: amministatori, PM ecc...

Inizio
P <=> S
Inizio + 1
P <=> M <=> S
Inizio + N
P <=> ..... <=> S

Puoi immaginare la perdita di informazioni che invece dovrebbero arrivare da P ad S e viceversa...

--
Giulio Banterla


Riccardo Cagnassosubject Di Riccardo Cagnasso - postato il 30/01/2009 15:15

Diciamo che se debian smettesse di pacchettizzare la roba una major version indietro per anni, magari il problema sarebbe anche meno sentito...

--
Riccardo Cagnasso


Cymon-AT- Riccardo Cagnasso Di Cymon - postato il 30/01/2009 22:23

Il conflitto tra sviluppatore e sistemista è antico come il mondo e, come dici tu, entrambi hanno ragione.
Io sono sviluppatore, però, e personalmente credo che proprio le ragioni di quest'ultimo possano essere prese con le pinze. Vero, l'ultima versione di tutto è sempre il meglio, ma credo che dire "aggiorna tutto al buio fino all'estremo limite dell'orizzonte" sia un atteggiamento scorretto. La maggior parte del codice si scrive usando cose che ci sono fin dalla notte dei tempi, per le funzionalità delicate prima meglio vedere cosa si ha in casa, poi vedere cosa non concede e poi decidere come muoversi. Con un po' di arguzia si può anche agire in modo non invasivo (librerie locali per l'applicazione e robe del genere...)

--
Cymon


anonymoussubject Di anonymous - postato il 31/01/2009 00:05

E poi parlano del "DLL hell" di Windows :-\) Non è che il "library hell" di Linux sia poi così diverso, a quanto pare :-\)

--
anonymous


anonymouse il cliente? Di anonymous - postato il 31/01/2009 09:09

penso che dipenda anche dalle richieste del cliente (quando un lavoro e' per terzi) a quel punto sistemista e programmatore se ne devono fare una ragione...

--
anonymous

Gabrieli Gianpietro-AT- anonymous Di Gabrieli Gianpietro - postato il 02/02/2009 19:49

Noi ci troviamo in una soluzione ancora peggiore,programmatori esterni (per web application) che si devono interfacciare con un'altra azienda esterna per la parte grafica,il tutto da implementare sui nostri server (che si trovano in Germania) gestiti da Ibm (Italia).
Ovviamente non è mai colpa di nessuno...metterli d'accordo è un vero delirio!

--
Nel dubbio accelero

http://djtwenty.altervista.org


7 messaggi this document does not accept new posts

Precedente Successivo


Il presente sito e' frutto del sudore della mia fronte (e delle mie dita), se siete interessati a ripubblicare uno degli articoli, documenti o qualunque altra cosa presente in questo sito per cortesia datemene comunicazione (o all'autore dell'articolo se non sono io), cosi' il giorno che faccio delle aggiunte potro' avvisarvi e magari mandarvi il testo aggiornato.


Questo sito era composto con VIM, ora e' composto con VIM ed il famosissimo CMS FdT.

Questo sito non e' ottimizzato per la visione con nessun browser particolare, ne' richiede l'uso di font particolari o risoluzioni speciali. Siete liberi di vederlo come vi pare e piace, o come disse qualcuno: "Finalmente uno dei POCHI siti che ancora funzionano con IE5 dentro Windows 3.1".

Web Interoperability Pleadge Support This Project
Powered By Gort