<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">2013/12/15 Enrico Bianchi <span dir="ltr"><<a href="mailto:enrico.bianchi@ymail.com" target="_blank">enrico.bianchi@ymail.com</a>></span><br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 12/14/2013 11:05 AM, enrico franchi wrote:<br>
<br>
Avendo spedito questo messaggio alle 16.47, e non vedendolo tutt'ora, non riesco a capire se sia arrivato o meno. In caso mi scuso per il doppio posto<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Se avete un sistema un po' modernino con oggetti tipo chef o puppet (o<br>
quello che va di moda ora) e jenkins (o quello che va di moda ora), il<br>
problema di gestirvi la vostra versione di Python e delle librerie che<br>
contano non e' particolarmente pesante. Sono un po' di madonne al<br>
setup e poi fine.<br>
</blockquote></div>
Quindi la tua idea e` compilare Python 3.3 in una directory (e.g. /opt/python3), installare in site-packages le librerie che mi interessano e poi distribuirlo tramite puppet, chef o altro? L'idea e` interessante, anche se non e` quello che volevo<div class="im">

<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Oh, giusto per i cliche', i syseng che se la prendono con gli<br>
sviluppatori... ;)<br></blockquote></div></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


</blockquote></div>
Clche` fino ad un certo punto. La situazione attuale e` questa, ovvero che le distribuzioni se ne lavano le mani motivando la loro scelta con "e` stabile, quindi e` buono fino alla prossima release" e che i developer di alcuni software se ne lavano le mani motivando la loro scelta con "se vuoi l'ultima versione compilatelo, altrimenti usa la versione proposta dalla distribuzione". Il che rende la questione un ginepraio.</blockquote>

<div><br></div><div>No aspetta… la distro si fa le sue policy e fine. Se si mantiene consistente con esse, e' solo la scelta di chi la usa. Ovvero se quelle policy sono accettabili per l'uso o cosa [0]. Chi sviluppa un pacchetto open source, in generale non ha le risorse per provarlo come si deve sulle varie piattaforme. </div>

<div><br></div><div>Sinceramente, per quanto sarebbe bello avere il lavoro fatto, non e' il loro mestiere. Dovrebbe essere, appunto, il lavoro di chi fa la distribuzione.</div><div><br></div><div>Detto questo, e' abbastanza chiaro che con il numero esorbitante di pacchetti che sono la fuori e con il fatto che non esiste un modo di deploy univoco, ci saranno assolutamente buchi neri. Anche perché' per un pacchetto giovane, i 6 mesi *minimo* di ritardo che le distribuzioni hanno per aggiornarsi sono eternità. </div>

<div><br></div><div>Ci sono poi sempre i vari casi dei bugfix. </div><div><br></div><div>E il fatto che, alla fine dei conti, i package manager sono pensati per il caso medio. Non solo, certi software si "sdoppiano" come software infrastrutturale. Per esempio, python e' un componente essenziale di molte distribuzioni. E io voglio che sia ben integrato e testato.</div>

<div><br></div><div>Viceversa, per il mio servizio, non vedo assolutamente strano volere una versione diversa di python o di qualche libreria altamente usata. Per cui il problema "mi devo mantenere il deploy di un po' di software" mi sembra relativamente inevitabile. E condiviso, altrimenti oggetti come maven non avrebbero quasi ragion d'essere. </div>

<div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Puppet e similari risolvono parzialmente, perche` va sempre fatto un lavoro di manutenzione a monte che va a fare da collante a quello che fa la distribuzione e non sempre risolve.</blockquote>

<div><br></div><div>No, puppet e simili sono un componente del deploy di software nel 2013. La distribuzione non può affrontare le esigenze di tutti  quanti e farlo bene. La distribuzione deve darti una piattaforma per il caso medio e renderti sano customizzarti quello che ti serve diverso.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Ma, soprattutto, un approccio del genere fa decadere lintero concetto di distribuzione. A 'sto punto, se devo fare le cose a mano, tanto vale consigliare Slackware o FreeBSD, con una preferenza per quest'ultimo, che almeno segue un concetto di distribuzione sensato (il sistema base lo aggiorna in un modo, il resto tramite ports e pkgtools)</blockquote>

<div><br></div><div>Niente da dire contro freebsd… a me i ports piacciono parecchio. Semplicemente un sistema di deploy funzionante che tratta tutta l'infrastruttura e' parte integrante del fare system engineering nell'eta' moderna. Fra l'altro, niente niente, hai componenti custom, componenti proprietari, hai di tutto...</div>

<div><br></div><div>Perche' semplicemente ci sono esigenze che *nessuna* distribuzione può risolverti. </div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Come dire, se avete sviluppatori che non capiscono una fava di ops,<br>
avete un problema nell'hiring, non nella categoria di sviluppatori.<br></blockquote></div></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div>
Non e` un problema di sviluppo in se (anche perche` da me si usa Java, non Python), ma del voler fare le cose come si deve. Ci sono software meno critici che non si fanno problemi per preparare pacchetti per questa o quell'altra distribuzione, non riesco a capire quindi perche` un software critico come python non lo faccia</blockquote>

<div><br></div><div>Non mi sembrerebbe particolarmente sensato… Quello che tu vuoi, costa. E Python non ha dietro una multinazionale. Sai quante persone ci vorrebbero per gestire la pacchettizzazione per le maggiori distribuzioni (e quelle piccole, poverette?) </div>

<div>Secondo me il modello in cui le distribuzioni scelgono cosa mantenere e lo mantengono e' tutto sommato il meno peggio.</div><div> </div></div><div><br></div>-- <br> .<br>..: -enrico-
</div></div>