[Python] R: [OT] Che distro usate per il vostro server (WAS desktop)

[enrico franchi]

2013/12/15 Enrico Bianchi <enrico.bianchi a ymail.com>

> On 12/14/2013 11:05 AM, enrico franchi wrote:
>
> 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
>
>
>  Se avete un sistema un po' modernino con oggetti tipo chef o puppet (o
>> quello che va di moda ora) e jenkins (o quello che va di moda ora), il
>> problema di gestirvi la vostra versione di Python e delle librerie che
>> contano non e' particolarmente pesante. Sono un po' di madonne al
>> setup e poi fine.
>>
> 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
>
>
>  Oh, giusto per i cliche', i syseng che se la prendono con gli
>> sviluppatori... ;)
>>
>

>  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.


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.

Sinceramente, per quanto sarebbe bello avere il lavoro fatto, non e' il
loro mestiere. Dovrebbe essere, appunto, il lavoro di chi fa la
distribuzione.

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à.

Ci sono poi sempre i vari casi dei bugfix.

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.

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.


> 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.


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.


> 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)


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...

Perche' semplicemente ci sono esigenze che *nessuna* distribuzione può
risolverti.



>  Come dire, se avete sviluppatori che non capiscono una fava di ops,
>> avete un problema nell'hiring, non nella categoria di sviluppatori.
>>
>

>  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


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?)
Secondo me il modello in cui le distribuzioni scelgono cosa mantenere e lo
mantengono e' tutto sommato il meno peggio.


-- 
.
..: -enrico-
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20131217/7bfe3d89/attachment.html>