Roma – Un Senatore degli Stati Uniti, il democratico Whip Dick Durbin, ha chiesto alle principali aziende del suo Paese che operano in Rete di spiegare nei dettagli le loro operazioni in Cina.
La richiesta arriva nel momento probabilmente più opportuno: nei prossimi giorni si parlerà in aula dell’efficacia o meno di un codice di autoregolamentazione, la Global Network Initiative , adottato da tali aziende. Il 2009, d’altronde, è stato, anche secondo le osservazioni di OpenNet Initiative , un anno in cui i controlli di Internet sono aumentati, tanto da riguardare oggi il 32 per cento dei netizen.
Il dialogo in Parlamento partirà dalla vicenda Google in Cina, che in questo scenario ha un ruolo fondamentale. “Google ha dato un grande esempio opponendosi alle continue richieste del Governo cinese contro la libertà d’espressione e la privacy. Attendo con ansia di sapere se altre aziende americane intendono seguirlo”, ha dichiarato Durbin.
Il Senatore ha infatti deciso, per avere queste risposte, di spedire lettere informative ai principali attori del settore, tra cui Facebook, Cisco, Twitter, Oracle, Skype, Apple, Amazon e eBay.
La domanda principale è come intendono contribuire a proteggere i diritti umani: la Global Network Initiative è stata sviluppata per fare chiarezza sulle policy adottate dagli operatori della rete nei confronti di paesi che attentano alla libertà di espressione online. Che significa, per le aziende che lavorano su Internet, spiegare come ci si destreggia fra censura e divieti e quanto si è disposti a collaborare (fino a mettere a disposizione le proprie conoscenze tecniche) con governi che chiedono controllo e annientamento della privacy.
Le aziende chiamate in causa potranno rispondere direttamente al Senatore o anche aspettare l’udienza indetta sull’argomento il prossimo mese.
Claudio Tamburrino
leggi i 45 commenti
-
come volevasi dimostrare php alla frutta
ecco che iniziano ad uscire amenicoli per ottimizzare phpaddirittura un convertitore in c++.ma usare .net pareva brutto eh? eh gia'...e' da capitalisti.mah.-
Re: come volevasi dimostrare php alla frutta
shhhh hai pronunciato l'impronuciabile nel sito dei programmatori bolscevichi adesso verrai XXXXXato e mazziato!-
Re: come volevasi dimostrare php alla frutta
si ma li aspetto al varco. Guai a nominare c# -
Re: come volevasi dimostrare php alla frutta
Mah, asp.net è normalmente considerato più veloce di PHP, ma non per tutti gli usi (es. connessione con mysql) e non sempre. In pratica la differenza di performance è modesta. Al contrario un miglioramento del 50%, come promesso da questo accroccrio, se è vero, sarebbe tuttaltro che modesto.
-
-
Re: come volevasi dimostrare php alla frutta
- Scritto da: il tarro
ecco che iniziano ad uscire amenicoli per
ottimizzare
php
addirittura un convertitore in c++.
ma usare .net pareva brutto eh? eh gia'...e' da
capitalisti.No. .Net è più veloce di PHP "liscio", ma già se aggiungi APC/eAccelerator, PHP diventa pari o più veloce.Semplicemente .Net precompila in bytecode tutto il codice (come Java), mentre PHP liscio non lo fa, ma basta usare un acceleratore e si ottiene lo stesso risultato, con in più il vantaggio che non devi fare il deploy con la compilazione manuale, ma lo fa il webserver da solo quando vede che un file viene modificato. Ed eviti il baraccone da 200 MB costantemente allocati sul server.Bye. -
Re: come volevasi dimostrare php alla frutta
Non e' solo una cosa da capitalisti. Tu sei pronto a consegnare tutto il tuo lavoro passato, presente e futuro ad una compagnia esterna?Non so te ma io preferisco lavorare senza pensieri e con il pieno controllo degli strumenti che utilizzo. -
Re: come volevasi dimostrare php alla frutta
- Scritto da: il tarro
ecco che iniziano ad uscire amenicoli per
ottimizzare
php
addirittura un convertitore in c++.
ma usare .net pareva brutto eh? eh gia'...e' da
capitalisti.Bah, chissà perché nessuno dei siti più visitati e usati al mondo (Facebook è il secondo dopo Google) usa .net.Saranno tutti scemi, sia quelli di Google (Youtube incluso) che quelli di Facebook.-
Re: come volevasi dimostrare php alla frutta
Sono fessi anche Wikipedia, YouTube, ecc.-
Re: come volevasi dimostrare php alla frutta
anche Twitter, che usa Ruby on RailsMettetevelo in testa, Winari: con i server non avete niente a che fare, e così rimarranno le cose!
-
-
-
-
phc
è già conosciuto nel mondo open source da parecchi anni. uno dei progettihttp://www.phpcompiler.org/igor. -
non immaginatevi che sia "plug and play"
al momento necessita di un http server particolare sviluppato da facebook.quindi non lo vedo esattamente come un gingillo che attacchi e godi.stanno pensando di renderlo compatibile con apache ma non si sa se e quando sarà possibile-
Re: non immaginatevi che sia "plug and play"
tutt'al piu' "plug and pray" :D -
Re: non immaginatevi che sia "plug and play"
al max sarà compatibile nativamente con http://www.tornadoweb.org/
-
-
Ma qualcuno l'ha visto questo codice?
La pagina "facebook developers rimanda a questo indirizzo:http://developers.facebook.com/hiphop-php/Ma nel repository non ho trovato nulla che riguardi questo Hip Hop.inoltre il gruppo segnalato " HipHop for PHP Discussion Group " all'indirizzo: http://groups.google.com/group/hiphop-php-dev è vuoto.-
Re: Ma qualcuno l'ha visto questo codice?
effettivamente:http://github.com/search?q=hiphop-php&x=0&y=0Repositories (0)(0.0 seconds)no matching results Users (0)(0.001 seconds)no matching resultsSource Code (0)(0.0 seconds)no matching results :|-
Re: Ma qualcuno l'ha visto questo codice?
Buono...Strano che abbiano fatto un annuncio senza caricare nulla.Spero rimedino, io ricontrollo settimana prossima senza fretta :D-
Re: Ma qualcuno l'ha visto questo codice?
Strano che abbiano fatto un annuncio senza
caricare
nulla.
Spero rimedino, io ricontrollo settimana prossima
senza fretta
:DStanno ancora aspettando il risultato in php... :D
-
-
-
-
CGI è morto, W CGI
Praticamente un ritorno alle vecchie CGI. Bentornate :) -
era logico
...che prima o poi qualcuno ci pensasse.Perché interpretare tutte le volte lo stesso codice? E' stupido. Lo si compila una volta per tutte e via.Ci hanno pensato quelli di Facebook, ma ci poteva pensare prima qualcun altro. Si spera soltanto che ora la tecnologia sia disponibile liberamente per tutti.L'unico appunto che mi sento di fare è la compilazione da PHP a C++: potevano direttamente compilare le pagine web in degli .exe da far girare come CGI o che so io. Avrebbero guadagnato ancora di più... ma forse faranno anche questo, prima o poi. Microsoft aveva già fatto qualcosa del genere con ASP, ma meno estrema... l'idea c'è già da tempo-
Re: era logico
http://eaccelerator.net/ è da tempo che c'è. -
Re: era logico
Compilazione Just in In Time (JIT), questa sconosciuta.-
Re: era logico
- Scritto da: James Effex
Compilazione Just in In Time (JIT), questa
sconosciuta.Hai idea di come funzioni JIT? L'ingolfamento del proXXXXXre c'è sempre...Documentati và
-
-
-
se credete che vi serva
nel 95% dei siti il collo di bottiglia sono db e file system. prima che php sia per voi un problema, dovete avere migliaia-milioni di visitatori, oppure applicazioni php talmente complesse che forse avreste dovuto farle in c++ sin dall'inizio.in rete potete trovare numerosi articoli a riguardo della velocità di php, tutti dicono più o meno la stessa cosa: php non è lento.poi è chiaro che con certi volumi di traffico, ogni dettaglio conta, ma parliamo di realtà veramente fuori dal comune.-
Re: se credete che vi serva
In pochi pensano ad ottimizzare il codice sql, a cosa servono gli indici sono inutili e fanno perdere a pensarli. Ed il sistemista deve fare il debug delle applicazioni scritte con i piedi e si dà sempre colpa al linguaggio: java è lento, php è lento, il server è lento. La verità è un altra....-
Re: se credete che vi serva
Esatto! Manca proprio il concetto di collo di bottiglia!Nessuno ha ancora capito che i programmi vanno ottimizzati dove vanno lenti! E guarda caso, nella maggior parte dei programmi, sono le query che fanno da discriminante nella velocità!Con gli indici, come citato sopra, si può trasformare una query da 30 secondi in una query da 1/10 di secondo...Unito a questo ci sono le caxxatone quotidiane, dove in un ciclo che scorre una tabella da qualche milione di record, butti tutto in memoria (o peggio ancora in sessione) a suon di new... e grazie che il java (php) è lento se fai così!Php diventa collo di bottiglia se hai una applicazione che deve fare tanti calcoli. Ma anche in questo caso spesso sono i programmi progettati male che fanno danno.Questo perchè alcuni calcoli vengono rifatti ad ogni richiesta di ogni utente, cosa che spesso non serve (basta salvare il risultato).Esempio banale? Thumbnail ricreata al volo ad ogni richiesta di preview...
-
-
-
out of web
Chissà se si potrà utilizzare come motore di scriting per applicazioni...sarebbe una soluzione ottima, la flessibilità di un motore di scripting, pergiunta maturo come php, e la velocità di c++...per giochi e plug-in vari sarebbe fantastico. -
Grandi!
non ho ancora guardato neanche una riga ma già la cosa mi intriga tantissimo!! ..e considerato che i progetti open tipo Roadsend sono ancora in alto mare, sono proprio curioso di vedere questo come funziona e cosa fa :)-
Re: Grandi!
Quello che fanno tutti i compilatori: trasformare un linguaggio in un'altro.Vedere Lex e Yacc: http://dinosaur.compilertools.net/
-
-
Alla fine della fiera
Alla fine si ritorna sempre al caro vecchio e complesso c++-
Re: Alla fine della fiera
Se è per questo l'assembly è ancora più performante O)Il punto non è PHP, Java, C o Basic... il punto è "a cosa ti serve ?"Certi linguaggi offrono più funzionalità integrate, altri sono più portabili, altri sono più performanti ma tutto è finalizzato a quello che vuoi ottenere e di quante e quali risorse disponi per ottenerlo. Puoi anche sviluppare un intero sito dinamico come CGI scritte in puro assembly... l'esecuzione sarà velocissima ma per sviluppare quel sito impiegherai 10 volte il tempo impiegato se l'avessi fatto in C++ e 50 volte se l'avessi fatto in PHP. Ne vale la pena ?Il software di Facebook in un certo senso salva capra e cavoli... consente la flessibilità e la facilità del PHP che è un linguaggio nato e dedicato allo sviluppo di siti web dinamici alla velocità d'esecuzione di un codice compilato quale quello prodotto dai compilatori C++-
Re: Alla fine della fiera
- Scritto da: Star
Il software di Facebook in un certo senso salva
capra e cavoli... consente la flessibilità e la
facilità del PHP che è un linguaggio nato e
dedicato allo sviluppo di siti web dinamici alla
velocità d'esecuzione di un codice compilato
quale quello prodotto dai compilatori
C++quello che sui server java fa da anni... benvenuto nella cerchia PHP!-
Re: Alla fine della fiera
non mischiamo XXXXX java con cioccolata c++ kthxbye-
Re: Alla fine della fiera
'gnurante!Il Java non è più lento del C/C++, e almeno teoricamente le VM sono più veloci del codice compilato a priori. Questo perché un programma ottimizzato per una specifica macchina non lo è per un altra. Mentre con la VM basta che sia ottimizzata lei per quella macchina e tutti i programmi risulteranno ottimizzati. Non è l'unico motivo teorico...Ah giusto link! http://www.idiom.com/~zilla/Computer/javaCbenchmark.htmlInoltre, udite udite, il java non è interpretato ma compilato.Dal punto di vista teorico il java è sempre stato compilato... per una macchina virtuale però. Questo non impedisce però il concetto di compilazione "just in time".Da notare che GCJ compila (si proprio compila) il codice java. La VM di Sun, hotspot, è un "essere" abbastanza avanzato ultimamente...http://java.sun.com/javase/technologies/hotspot/In brevissimo: usate l'opzione "-server" e ne vedrete delle belle...Non vi fidate? Scrivete in C e in Java in programma banale di puro calcolo, fate le vostre prove (ricordate "-server" in java, e ottimizzazioni di compilazione in C) e sfaterete i vostri miti.Ultima considerazione: nei dispositivi embedded, per ovvie ragioni, domina spesso il C. Ma si vuole andare verso il java. J2ME, Dalvik... cercate su google.Se siete arrivati a leggere fin qui... siete dei veri masochisti! ;) -
Re: Alla fine della fiera
- Scritto da: poiuy
Il Java non è più lento del C/C++, e almeno
teoricamente le VM sono più veloci del codice
compilato a priori. Questo perché un programma
ottimizzato per una specifica macchina non lo è
per un altra. Mentre con la VM basta che sia
ottimizzata lei per quella macchina e tutti i
programmi risulteranno ottimizzati. Non è l'unico
motivo
teorico...
Ah giusto link!
http://www.idiom.com/~zilla/Computer/javaCbenchmar
...
Non vi fidate? Scrivete in C e in Java in
programma banale di puro calcolo, fate le vostre
prove (ricordate "-server" in java, e
ottimizzazioni di compilazione in C) e sfaterete
i vostri
miti.OK, però sono capaci tutti di ottenere prestazioni uguali con un JIT su calcoli matematici. Tipicamente il "core" di tali calcoli è talmente piccolo che, una volta "JIT-tato" diventa assembly ed entra nella cache di qualsiasi CPU.Il problema, con qualsiasi linguaggio ad alto livello (Java, PHP, Python o Ruby che sia) è su tutto il resto. Ed è su "tutto il resto" che si sviluppano il 90% dei software.E quel 90% di software non sempre ha bisogno del massimo delle prestazioni, ma giova molto svilupparlo ad alto livello perché ci si mette 1/10 del tempo.La conclusione è molto semplice: scrivi il software ad alto livello (Java, PHP, Python, Ruby, ecc.) e ottimizza a basso livello solo le parti di calcolo pesante, o quando hai problemi di prestazioni su un certo pezzo di software (a questo servono i profiler).Non a caso in Python si usa Numeric (libreria binaria) per i calcoli matematici, e in PHP si usa GMP (sempre binaria) per numeri ad alta precisione.Il caso di facebook è molto particolare, e hanno già ottimizzato tutto il resto (APC, memcache, mysql, apache, ...) e rimaneva solo di ottimizzazre anche il codice PHP. Non avevano scelta. Ora ottimizzare PHP costa meno che comprare nuovi server.Bye. -
Re: Alla fine della fiera
Guarda, concordo con quello che dici. Ma il Java non è ne lento ne interpretato (tipo php o altri).Non è lento neanche nel restante 90%... -
Re: Alla fine della fiera
- Scritto da: poiuy
Guarda, concordo con quello che dici.
Ma il Java non è ne lento ne interpretato (tipo
php o
altri).
Non è lento neanche nel restante 90%...Non è (più) lento. Ma è comunque più lento di C/C++.Non lo noti perché è difficile vedere un widget che si ridisegna in 2 centesimi di secondo invece che in 1. Ma è proprio questo il punto: in quel 90% dei casi non serve essere più veloci. Serve essere più "produttivi" quando scrivi il codice.Comunque Java non è lento, ma molto spesso i framework che ci costruiscono sopra sono sovraingegnerizzati, non so se per rispettare alla lettera i design patterns o per cercare di renderli più generici possibile o per qualche altro motivo. E sono quelli ad ammazzare le prestazioni dei software in Java.Bye. -
Re: Alla fine della fiera
Concordo in pieno.Non sono i design pattern a rallentare, quanto l'implementazione errata di questi e le varie "castronerie" che sia annidano nei punti più reconditi del codice! -
Re: Alla fine della fiera
Java è un po' come il sesso anale: il solo fatto che funzioni su tutte le piattaforme non basta a renderlo la migliore soluzione possibile. -
Re: Alla fine della fiera
Inoltre, Java non funziona su tutte le piattaforme. -
Re: Alla fine della fiera
ah beh un esperto di LOLCode... grazie per avermi illuminato
-
-
-
Re: Alla fine della fiera
contenuto non disponibile -
Re: Alla fine della fiera
Assembly più veloce: falso. Le tecniche ti ottimizzazione adottate oggi dai compilatori superano di gran lunga le capacità di un programmatore. Il modo migliore per avere applicazioni performanti è di scrivere codice pulito, lineare, modulare e abbondare di cicli e variabili. Ci pensa poi il compilatore ad ottimizzare.Il problema è che "scrivere codice pulito, lineare, modulare e abbondare di cicli e variabili" non è cosa semplice... solo un pelino più semplice di scrivere buon codice ottimizzato in assembly.
-
-
-
Già che ci siamo
Mi sa che è il caso di citare anche wikipedia tra i SW (e i siti) che ne trarrebbero vantaggio.
