Newsgroup: it.comp.os.linux.sys
Titolo: python su server web sicurezza

che accorgimenti ci sono da tenere per far girare python insieme ad
apache e php? 
 
sto pensando di provare django per sviluppare web 
 
Enrico 


Leggi la documentazione. 
 
Fondamentalmente esistono diversi modi per "connettere" Django al 
webserver. 
con apache userai mod_wsgi. 
con nginx usi uwsgi (tramite tcp socket, socket file, o una cosa di cui 
mi sfugge il nome... googling.. ah ecco: emperor. Una diavoleria). 
devi impostare il DB
devi imparare un po' come funziona Jinja. 
esiste anche un webserver interno, che teoricamente puo' essere connesso 
ad apache, immmagino che sia abbastanza limitato e poco performante. 
 
Poi imposti il DB (quello predefinito e' sqlite, ma se hai gia' un altro 
DB usi quello). 
E quindi impari a usare i template Jinja (che fanno sempre comodo, non 
solo nel campo della programmazione Web). 
Poi userai i CSS (lavoro odioso).
Scriverai codice HTML (altro lavoro odioso). 
 
p.s.: Se devi fare roba abbastanza semplice puoi non usare Django. Al 
suoi posto puoi utilizzare Flask, al limite Cherrypy, Tornado. Ad occhio 
con Flask trovi piu' supporto in giro. 
 
 
-- 
Massimiliano Adamo

 sto pensando di provare django per sviluppare web 
 
Faccio l'avvocato del diavolo. :)
 
... perché?
 
PHP è più veloce, ha più librerie, più framework, più pacchetti e una
comunità enormemente più ampia.
 
Se proprio devi cambiare almeno vai su qualcosa di drasticamente più
veloce, tipo Go.
 
Python è ottimo se devi fare machine learning, ma ormai, secondo me, è
rimasto praticamente l'unico campo in cui ha senso usarlo (fichè non
porteranno le librerie su Go), e forse per scrivere alle applicazioni Qt
per desktop.
 
Bye.
 
P.S.: io preferisco Rust a Go, ma a livello web è troppo indietro, per
ora. :D


faccio l'avvocato di Satana :D
 
- concordo al 90%. Migrerei da PHP a Python solo se ritenessi di essere
piu' produttivo con python. Se dovessi scrivere una piccola API io, oggi,
la scriverei con Flask. Domani, chissa' :-)
- non conconrdo, 5%, sul fatto che python avrebbe senso solo per fare machine 
learning. Il fatto che abbia un supporto per il multithreading un po'
farlocco e' "normale" per un linguaggio di scripting. No? Il problema
della GIL sussiste anche con Ruby. Problema analogo per PHP.  
Sappiamo tutti che esistono jruby, jython, iron python per ovviare a questo
problema, ma la realta' e' ben diversa e sono scarsamente usati (il puppet
server ha implementato jruby) ... leggi il resto. 
- non concordo, altro 5%, sul fatto che si debba per forza usare cio'
che e' piu' veloce. Suona strano... ma se devi usare cio' che e' piu' 
veloce sarai costretto a usare sempre assembly. E invece, molto spesso, le 
performance cedono il passo alla produttivita'. Questo e' ormai un paradigma 
assodato. 
Leggevo su Quora tizio che diceva, s"e devo spendere 6 mesi, per ottenere 
millisecondi di vantaggio come prestazioni, mi tento i millisecondi in
meno, ma uso il linguaggio che mi consente di raggiungere il risultato
in un paio di settimane". E spesso quei millisecondi, sono perfettamente
inutili.  
 
p.s.: cio' detto, per me Go va BENISSIMO e tutto sommato garantisce anche
una discreta produttivita'.... a parte i 4 lavoretti che ci ho fatto,
ho rimpiazzato diversi tool, r10k con g10k, uso tutti i prodotti Hashicorp,
uso powerline-go (per la mia Shell) :) 
 

 Python è ottimo se devi fare machine learning, ma ormai, secondo me, è
 
Questa e` un po' stracciata.
 
Molta gente usa python, per esempio, come alternativa
a Matlab (con numpy, sci-py, etc.).
 
Molti, se non tutti, tool di configurazione di Fedora
sono scritti in python.
 
E cosi` via...
 
Semmai si puo` dire che python abbia sostituito java
in molti casi.
 
bye,
 
-- 
 
piergiorgio

 che e' piu' veloce. Suona strano... ma se devi usare cio' che e' piu' 
 
A parita` di potenza espressiva, altrimenti, come
hai scritto sotto, bisogna valutare attentamente i
costi ed i benefici.
 
Cioe`, se si deve scegliere tra due linguaggi di
programmazione che fanno lo stesso, con gli stessi
tool di sviluppo, librerie simili, conviene sempre
prendere quello che lo fa piu` rapidamente.
 
Altrimenti, molto spesso conviene prendere quello
con cui si finisce prima.
Che e` sempre il piu` veloce, ma in un altro modo... :-)
 
bye,
 
-- 
 
piergiorgio

 comunità enormemente più ampia.
 
vabbeh a questo punto allora prima del php certamente node.
 


era la domanda segreta del trainer Go: "why do you want to use Go?" 
e tutti: "perche' e' veloce", "perche' ha le routine" ... 
e lui ha citato Assembly :) 
Ovviamente il discorso e' analogo con Python. 

 vabbeh a questo punto allora prima del php certamente node.
 
Facciamoci del male!
 

 della GIL sussiste anche con Ruby
 
*cough*PyPy*cough*
 
Enrico

 con Flask trovi piu' supporto in giro. 
 
Bottle. Più semplice e bello di lui non ho trovato nulla ;)
 
Enrico

 in molti casi.
 
Java deve morire, quini ben venga. :D
 
Se proprio bisogna usare la JVM, allora meglio Kotlin o Scala, al giorno 
d'oggi. :)
 
Bye.

 
 
 
Per quanto riguarda Go, c'e' una comunita' nutrita, forte, agguerrita e 
molto motivata, tanto che a volte mi chiedo "ma ki li paka??" 
Quando feci il training, feci un po' amicizia con il trainer (americano, 
ma avevamo la radice siciliana in comune :) ) e mi porto' con lui per 
incontrare la comunita' ad Amsterdam. Incontrammo sviluppatori di 
Haschicorp, canadesi, australopitechi ... tutti stramaledettamente in 
fissa con Go. 
 
-- 
Massimiliano Adamo

 fissa con Go.
 
Go ha il notevole pregio di essere veloce quasi quanto C, di essere 
molto simile al C a livello di sintassi (ha * e & pur senza raw 
pointers, per esempio), e quindi di fornire un passaggio quasi indolore 
da C/C++, e dall'altra parte fornisce thread e code messaggi inclusi nel 
linguaggio e molto semplici da usare e soprattutto un garbage collection 
(pure molto veloce) che permette di dimenticarsi alloc() e free().
 
Unito al fatto che crea eseguibili autocontenuti e che ha una discreta 
standard library che include anche socket e http, lo rendono il 
linguaggio più semplice e produttivo che ho visto finora per fare 
applicazioni di rete.
 
Per quello lo consiglio in alternativa a Python se si arriva da PHP.
 
Certo per un programmatore PHP aver a che fare con reference e 
dereferenze non è immediato, ma nemmeno impossibile (la & c'è anche in 
PHP. È il * che è automatico).
 
Bye.

 Per quello lo consiglio in alternativa a Python se si arriva da PHP.
 
Concordo certamente sul fatto che Python non sia
proprio da considerarsi un'alternativa a PHP.
 
bye,
 
 
-- 
 
piergiorgio

 proprio da considerarsi un'alternativa a PHP.
 
Mi sembrano affermazioni (sia le tue, sia quelle di Alessandro) di chi non
conosce Python e parla per partito preso. Posto che non sono un programmatore
web e che se lo fossi lo sarei solo lato Python, baso la mia replica su due
considerazioni:
 
 - Il risultato di questo: 
https://www.techempower.com/benchmarks/#section=data-r14&hw=ph&test=db&l=7rokcf
 
 - L'esperienza di un amico decisamente bravo che, testuali parole, alla lunga
   Python risulta migliore, ovvero all'inizio sembra più lento perché prealloca
   più risorse, ma nel momento in cui comincia a fare parecchie elaborazioni e
   applicazione di pattern, colma il gap iniziale
 
Enrico

    applicazione di pattern, colma il gap iniziale
 
Puo` essere, vedi sopra pero`.
 
bye,
 
-- 
 
piergiorgio

 sviluppo per un certo tipo di applicazione.
 
Quello che voglio dire con quel link è che ci sono validi motivi per prendere
in considerazione Python sia per un discorso prestazioni, sia per un discorso
di rapidità e di sviluppo applicazioni. In altre parole, Python si può
considerare una valida alternativa a PHP per lo sviluppo web
 
Enrico
[1] a dire il vero ho scritto solo un'applicazione web in Python, che serviva
via REST dei risultati presi da AWS, ma nulla di grosso (veniva usata da
un'altra webapp che processava poi i dati per mostrarli all'utente)

  
https://www.techempower.com/benchmarks/#section=data-
 
r14&hw=ph&test=db&l=7rokcf
 
 
Interessante. Pero' Enrico, anche io sono un pythonista al 99%, ma lo 
vedi da te che i primi della lista (per quanto riguarda python) sono 
tutti micro-framework. Appena arrivi al framework vero e proprio (Django) 
la situazione cambia un po'. 
 
-- 
Massimiliano Adamo

 all'utente)
 
 
vedi? Io nel mio CV posso contare ben 3 pseudo-web app :) 
La prima, per qualche ragione oscura l'ho scritta con CherryPy. Aveva una 
piccola REST API, una piccola interfaccia Web.... carina... ricordo di 
averci messo l'anima.  
Poi ho scritto due piccole API con Flask. 
Alla fine vedo quasi tutte supportano Jinja e questo li fa diventare 
interessanti, a PHP, perche' dubito (ma posso anche sbagliare) che il 
templating di PHP possa essere paragonabile a ERB o Jinja2. 
 
P.s.: per esperienza i template ERB sono i piu' avanzati, ma se parli con 
i jinjari di dicono che il template jinja e' piu' limitato by design. 
 
-- 
Massimiliano Adamo

 templating di PHP possa essere paragonabile a ERB o Jinja2. 
 
Twig è un template engine basato sulla sintassi di Jinja2 ma con molte
più funzionalità integrate. È praticamente lo standard in PHP.
 
Bye.
 

 la versione pure...
 
Beh, puoi sempre compilare staticamente. :D
 
In realtà, con Go, questo sistema funziona solo quando usi solo codice 
Go nativo. Appena usi FFI per accedere a librerie esistenti, hai lo 
stesso problema: link dinamico e necessità di copiare i .so
 
Bye.
 

     applicazione di pattern, colma il gap iniziale
 
Sono due approcci diversi.
 
PHP lancia un processo per ogni request. Python (e Node, Java, Go) no.
 
L'altro lato della medaglia è che alla fine della request, PHP distrugge 
la memoria del processo, liberando tutte le risorse, gli altri no, 
quindi puoi avere memory leak, risorse (tipo connessioni al DB) occupate 
perché dimentichi di liberarle, ecc.
 
PHP lo modifichi, fai refresh sul browser e vedi le modifiche. Gli altri 
devi "deployarli" in qualche modo (compilazione, transpilazione, 
packaging, ecc. anche se ammetto che non so cosa sia necessario fare con 
Python in questo caso).
 
Se hai operazioni lunghe da fare in una singola request, PHP è più 
veloce (in generale, non in tutti i casi) anche se di poco.
 
Bye.

 produttivo di C++, quindi... mi tocca. :D
 
Per curiosità, perché lo consideri mediocre?
 
Enrico


Credo che tutto si riduca al fatto che stanno sacrificando troppe cose 
per tenere i tempi di compilazione bassi (e il linguaggio semplice).
 
Per iniziare, credo che un linguaggio con strict e static typing deva 
anche avere supporto per i generics, altrimenti è monco. Infatti non 
puoi implementare strutture dati generiche, e sei costretto a usare map 
e array built-in per tutto.
 
Per lo stesso motivo non puoi praticamente fare programmazione funzionale.
 
O usi code generation o fai fisicamente copia-incolla del codice 
cambiando il nome della funzione e i tipi dei parametri.
 
Oppure usi "void *"... scusa... "interface{}" e fai type assertion come 
se non ci fosse un domani.
 
Sempre in tema di map e array, ci sono ben due keyword (new e make) che 
hanno signature insulse. Se usi make con una map hai una signature, se 
la usi con un array ne hai una diversa. Se la usi con un tuo tipo è 
ancora diversa. E new() è praticamente &make().
 
In pratica sono comportamenti hard-coded per tipi hard-coded.
 
Passando ad altro: offre multithreading semplicissimo, ma nessun aiuto 
per evitare problemi di sincronizzazione. Devi ricordarti di creare una 
struct con dentro un lock e lockarlo e unlockarlo manualmente. Se te lo 
dimentichi, il compilatore non dice niente, e ti trovi comportamenti 
impossibili da debuggare a runtime (confronta con Rust in cui sei 
costretto a wrappare dati condivisi in un lock e il compilatore si 
accorge se ti dimentichi di lockare).
 
La gesitone delle dipendenze è... semplicemente orrenda. A partire dal 
GOPATH per finire con l'usare il branch master dei repo senza 
possibilità di scelta.
 
Non esiste namespacing. Ogni "modulo" (compresi i sotto-moduli) in 
realtà una libreria completamente separata. Per dire, non puoi avere un 
modulo "domain" con un sotto-modulo "domain/models" in cui i model hanno 
un puntatore a una struct in domain e le funzioni di domain creano 
models, perché hai un riferimenti circolare tra moduli diversi. Non si 
accorge che sono gerarchici.
 
Alcuni hanno finito con l'usare un singolo namespace con 
decide/centinaia di file ognuno con centinaia/migliaia di linee di 
codice. Nello stesso namespace.
 
Più altre decine di papercuts.
 
E stiamo parlando di un linguaggio pubblico da quasi 10 anni.
 
Mi sembra di vedere PHP3. Aspetto solo GoNuke.
Spero non ci mettano altri 10 anni a portarlo a livello di PHP7. :D
 
Lo consiglio per applicazioni piccole (microservice, comandi CLI), ma 
per applicazioni più complesse diventa presto ingestibile.
 
Bye.

 Python in questo caso).
 
 
Python "lo modifichi" o fa il deloy. Non conosco i sistemi di pacchettizzazione
per PHP e se sono buoni e se sono diffusi. Ma se sono scarsamente diffusi e' un problema di PHP, non certo un pregio. 
Ovviamente anche con Python se ti piace, puoi usare file sparpagliati, puoi fare 
pull da un repository o esplodere un archivio. 
Usare i tag di git e' un pelino piu' pulito ma resta una zozzata. 
Di norma si usano wheels, eggs, repository pip, pacchetti di sistema. 
 
A dire la verita' in Python (tranne che non sei in modalita' debug) devi 
riavviare il demone.... in modalita' debug, il riavvio avviene automaticamente. 
 
-- 
Massimiliano

 per PHP e se sono buoni e se sono diffusi. Ma se sono scarsamente diffusi e' un problema di PHP, non certo un pregio.
 
È proprio quello il punto: non servono. L'autoloader si arrangia a 
trovarli in base alla struttura delle directory (che è specchio del 
namespace delle classi).
 
I pacchetti di librerie sono in 
packagist.org
 e li installi tramite 
composer, che non fa altro che scaricarli e metterli in una directory 
(risolvendo le dipendenze, naturalmente) dove l'autoloader li trova.
 
Bye.

 per applicazioni più complesse diventa presto ingestibile.
 
 
Consul non e' per nulla una applicazioncina. 
Consul e' un DNS a tutti gli effetti, un Database con ACL, fa service 
discovery. 
 
Potremmo parlare anche di Nomad. 
 
Dove lavoravo prima, il collega (che poi e' andato in Hashicorp) ha fatto
una applicazione che si chiama Fabio, che reindirizza il traffico web
sulla base della discovery di Consul. Non e' propriamente un CLI. In
sostanza e' un load balancer. 


Torando al discorso di prima.... 
 
Immagino che il decorator di Flask usi il threading o multiprocessing.  
Si tratta solo del fatto che esiste un processo "padre" perche' flask,
django, sono dei server. 
 
Tuttavia, se usi mod-wsgi, potrebbe anche darsi che non devi ricaricare
nulla.

 hai GC.
 
Interessante, questa soluzione potrebbe essere
davvero ottimale.
 
bye,
 
-- 
 
piergiorgio

 Il successivo go get non uscira' dal branch.
 
comunque ti do ragione. Sotto questo aspetto python vince a mani basse:
 
install_requires=[
    'paramiko==2.4.0',
    'ipaddress==1.0.18',
    'gitpython==2.1.7',
    'pyhcl==0.3.9',
    'infoblox-client==0.4.17',
    'python-terraform==0.9.1',
    'requests==2.18.4',
    'configparser==3.5.0',
    'positional==1.2.1',
    'jinja2',
    'pyvmomi==6.5.0.2017.5-1',
    'python-consul==0.7.2',
    'argparse',
    'ast'
    ],
 
 
 
 
-- 
Massimiliano Adamo

 
 
 
Dunque.. causa esigenze di mercato, mi son messo alla ricerca di un CMS
o meglio un Framwork per il web sicuro  e con un supporto ampio di
temi, applicativi e  magari anche assistenza a pagamento.
 
Caratteristiche principali, velocità sviluppo, template moderni, un
minimo di applicazioni, tipo blog, catalogo  etc. 
 
Cercando ho trovato delle belle cose fatte con django e plone, quindi
mi son chiesto  che livello di sicurezza  c'era e quali accorgimenti si
dovevano tenere per mettere un server in produzione che potesse far
giare i su detti quindi python.
 
ma ovviamente se ci sono consigli alternativi, meglio in solo PHP, ne
sarei felice.
 
Escluderei roba della calasse wordpress, jomla, dove mi rifiuto di
dare qualsiasi garanzia di stabilità è progettualizzazione a lungo
termine.
 
Mi arrivano un monte di pretendenti clienti, che pretendono gli rimetta
in piedi il sito fatto con i su detti, a costi che dovrebbero essere
un decimo della produzione, che ovviamente gli ha fatto un amico a costo
di una minestra senza tozzo di pane; ovviamente rimangono pretendenti
e non clienti.
 
 
grazie
ENrico
 
 

 giare i su detti quindi python.
 
secondo me stai chiedendo al gruppo di persone sbagliate. Nessuno tra i 
presenti ha detto/scritto di essere un programmatore web scafato, quindi 
in grado di elargire consigli sensati.
 
Esempio, io, da NON programmatore web, non ho tempo di stare appresso a 
CSS e Template (anche se l'ho fatto), ma da buon sistemista uso l'arte di 
arrangiarmi, e creo le pagine web dinamicamente e farloccamente con le 
list comprehensions. 
Per funzionare funziona, ma non mi pare una cosa fatta con i crismi 
necessari. 
 
Esempio pratico di come NON si fa il programmatore web: 
 
modified_sql_list = ['<td><input type="radio" name="myfile" value="{0}" 
required> <img src="/img_{1}"> || {0} || {2} || {3} </td>'.format(s[1], s
[0], s[2], s[3]) for s in sql_list] 
 
 
@cherrypy.expose
def status(self):
    nodeconfig = ConfigParser.RawConfigParser()
    nodeconfig.readfp(open(os.path.join(conf_file)))
    txtnodes = dict(nodeconfig.items('nodes'))
    txtnode_list = txtnodes.values()
    sql_result = build_html(*txtnode_list)
    # mmh... manipulating the list
    sql_list = [list(s) for s in sql_result]
    for s in sql_list:
        s[0] = str(s[0])
    modified_sql_list = ['<td><input type="radio" name="myfile" 
value="{0}" required> <img src="/img_{1}"> || {0} || {2} || {3} </
td>'.format(s[1], s[0], s[2], s[3]) for s in sql_list]
    html_list = '</tr>\n<tr>'.join(modified_sql_list).replace('||', '</
td><td>')
    return '{0} {1} {2}'.format(html_head, html_list, html_bottom)
 
 
-- 
Massimiliano Adamo

  
 
infatti la mia domanda originale era differente, poi ho visto
degenerare l'albero e ho chiarito.
 
ritorno alla domanda precedente riformulata:
 
quali sono gli accorgimenti di sicurezza da applicare per mettere in
produzione un server con paython da un punto di vista di sistema?
 
enrico 
 
 
 

 accorge se ti dimentichi di lockare).
 
Anche questo non va bene pero`.
Potrei benissimo voler dati condivisi *senza* lock.
 
L'unica soluzione "generica" e` avere dei lock
facili da implementare, ma con l'assoluta liberta`
di non implementarli.
 
bye,
 
-- 
 
piergiorgio

 occhio con Flask trovi piu' supporto in giro. 
 
 
per la scelta del software ci studierò un po'; come ho detto avevo
visto plone e django molto ben fatti e completi. 
 
direi che lo userò insieme ad apache quindi  mod_wsgi
ci sono dei consigli particolari per la sicurezza?
 
Enrico 
 

 produzione un server con paython da un punto di vista di sistema?
 
eh ma... poi ti fidi del consiglio di chi non e' un professionista del 
settore? 
 
Se parliamo di cose realizzate da me, ho usato Django in un solo 
progetto, Cherrypy e Flask un paio di volte. 
Tu credi che qui ci sia qualcuno che puo' vantare una esperienza piu' 
ampia in questo settore? 
 
Tanto pour parler, ho visto cose carine fatte con Django: 
https://github.com/yueyongyue/saltshaker
 
Ma questo non vuole dire NULLA. 
 
-- 
Massimiliano Adamo

 consigli particolari per la sicurezza?
 
l'ho usato per progetti interni e la sicurezza per me non era un tema 
cruciale. Si, una volta ho fatto una app per dei backup criptati, che 
aveva anche una interfaccia web (*) ... ma non mi sono mai posto 
realmente nella situazione di dover affrontare seriamente il tema della 
sicurezza. 
Avevo delle chiavi GPG, delle connesioni a RabbitMQ, creavo i backup, 
memorizzavo le chiavi... cercavo di usare un po' di buon senso, che e' 
ben diverso da un discorso specializzato sulla sicurezza web. 
 
(*) e tantomeno mi importava delle prestazioni. A quel tempo usavo 
CherryPy che non implementa moduli per l'autenticazione LDAP, ed io 
facevo una query LDAP per ogni link che veniva cliccato :) 
Le pagine erano circa 4, gli utenti contemporanei al massimo 2. 
 
Questo era il tool (e contiene anche l'interfaccia web): 
https://github.com/maxadamo/encryptonator
 
 
E queto era il porting in Go, relativo alla componente che usava il 
threading in python: 
https://github.com/maxadamo/encryptonator-go
 
 
voglio dire... una volta in un training, ci fecero bucare un server, e 
poi dovevamo leggere le chiavi SSL dall memoria. Il tipo ci suggeriva le 
tecniche da utilizzare, ma si tratta di cose che non ho mai ripetuto in 
un contesto reale :) 
 
La mia realta' e' fatta di password memorizzate in base64, giusto per 
evitare i temibili sohulder-surfer :) 
 
-- 
Massimiliano Adamo

 di non implementarli.
 
Non so che tipi di software hai scritto tu, ma nella mia esperienza io
non ho mai voluto dati condivisi senza lock.
 
Soprattutto adesso che i processori multicore sono la norma, non sapere
quando succede un accesso ai dati (anche nello stesso ciclo di clock,
potenzialmente) è da film horror.
 
Puoi dirmi che vuoi accessi a diverse parti della stessa struttura dati
(per esempio 1/4 di array per ognuno dei 4 thread (core) che fai girare,
o che sei sicuro che tutti avranno accesso solo in lettura (e Rust
consente entrambe le cose senza lock, per esempio), ma avere accesso in
lettura e scrittura alla stessa locazione di memoria da thread diversi è
la ricetta perfetta per il segmentation fault impossibile da debuggare.
 
Bye.

 la ricetta perfetta per il segmentation fault impossibile da debuggare.
 
Non vedo perche` dovrebbe fare un segfault.
 
Dipende da che dati ci sono.
 
Se ho uno stream audio / video, nella peggiore
delle ipotesi avro` una decodifica sbagliata.
Il decoder *deve* essere in grado di fare error
recovery, quindi non vi e` nessun segfault.
Proprio per design.
 
E questa e` un'altra situazione in cui, forse,
avere un lock potrebbe non essere voluto.
Dipende da molte altre cose.
 
Infine, sicuramente non si vuole un lock dentro
una routine che risponde ad un irq, quindi, il
lock, se c'e`, deve stare altrove.
Il che ci riporta al discorso sul fatto che i
lock devono essere piazzabili nella posizione
migliore, quindi devono essere separabili e
non integrati nella struttura dati.
 
bye,
 
-- 
 
piergiorgio

 non integrati nella struttura dati.
 
Come dici anche tu, dipende dall'applicazione e dalla struttura dati.
Puoi avere un lock sull'intera struttura o su parti granulari, o appunto
usare altre tecniche.
 
Go consiglia di usare più possibile i channel, ma ovviamente in alcuni
casi non ha senso.
 
Bye.

 Io parlo di normali applicazioni user-space.
 
OK, chiaro.
 
bye,
 
-- 
 
piergiorgio

 settore?
 
Lui sta chiedendo a livello sistemistico, non di programmazione.
 
Credo che sappia cosa sono le sql injection e come evitarle.
 
Sta chiedendo come configurare apache o nginx per servire pagine python 
senza esporre i sorgenti o le password di accesso al DB, per esempio.
 
Io non avrei idea, e visto che nessuno rispondeva, ho lanciato il sasso 
del "perché?" :D
 
Bye.

 del "perché?" :D
 
Su questo concordo: perche'... e lo dico da pythonista. 
 
 
-- 
Massimiliano Adamo

 
 
Esatto.
 
Grazie