Adobe ha annunciato qualche ora fa una decisione molto discutibile: Flash Player, il popolare plugin per il browser, sarà disponibile soltanto con Chrome — almeno, su Linux a 32-bit e a 64-bit. È il risultato d’una partnership stretta con Google. Il plugin utilizzerà Pepper Plugin API (PPAPI): altri browser potrebbero beneficiarne.
Il download diretto di Flash Player dai server di Adobe non sarà più possibile per Linux, mentre gli altri sistemi operativi non risentiranno della novità. La società sostiene che sarà distribuita una versione di debug del plugin affinché sia possibile valutare l’integrazione su altri browser, però non è ancora stato deciso il come.
PPAPI può essere potenzialmente implementato su tutti i browser, ma costituisce un sostituto delle Netscape Plugin API (NPAPI) di Firefox e – in futuro – sarà legato al Native Client (NaCl) di Chrom*. Per utilizzare Flash Player serviranno entrambi e, comunque, gli sviluppatori dovranno passare da Google per il supporto del plugin.
Aggiornamento: corretto il refuso nel titolo.
Via | Adobe
Seguici
ossblog è un supplemento alla testata Blogo.it registrata presso il Tribunale di Milano n. 487/06, P. IVA 04699900967. Contatti, Chi siamo, Condizioni di utilizzo, Privacy.
© 2004-2012 Blogo.it, alcuni diritti riservati sotto licenza Creative Commons.
Per informazioni pubblicitarie e progetti speciali su Ossblog.it contattare la concessionaria esclusiva Populis Engage.
maurizio_lanfranco
22 feb 2012 - 14:14 - #1basta dire da oggi non sviluppiamo più cose flash perchè ci spostiamo verso html 5 e non fare un casino pazzesco dando ad papache flex, a chrome il plugin flash di linux, ma sono sbroccati, hanno perso il timone di una piattaforma certo chiusa ma ancora oggi molto valida
abral
22 feb 2012 - 14:46 - #2Oramai Flash non vale più nulla per Adobe. Aiutando Google almeno si fa un pò di soldi da un prodotto morente.
E’ a Google che questa mossa conviene enormemente perché gli altri browser, se vorranno continuare a supportare Flash, dovranno adottare anche la PPAPI, supportando così indirettamente anche Google NaCl (che può diventare utile solo se sarà largamente diffusa). Certo è una mossa incredibilmente vergognosa.
scusate_ma...
22 feb 2012 - 14:57 - #3“Sopresa”
nakki
22 feb 2012 - 15:09 - #4bella notizia del c***o….la cosa alquanto strana è che chrome su linux, a differenza che sugli altri SO (win e OSX), non contiene flash, ma attualmente lo si deve installare separatamente…
ora hanno deciso di incorporarlo come succede su windows o cosa? che poi renderlo disponibile solo per chrome è una cazzata terribile…
qqwer
22 feb 2012 - 15:33 - #5figli di |° |_| 77 4 || 4
Roberto Rossi
22 feb 2012 - 20:57 - #6Io non ci vedo nulla di strano. Del resto è evidente che Chrome stia puntando al monopolio di fatto, la stessa strada percorsa da microsoft quando Internet Explorer dominava incontrastato.
Ho paura che, vista la potenza persuasiva di Google e la poca attenzione degli utenti, l’operazioni riuscirà, cosi ci ritroveremo con l’ennesimo monopolista che si fa solo gli affari suoi.
Se a qualcuno interessa approfondire il mio pensiero :
http://bit.ly/rCtDa0
Kim Allamandola
22 feb 2012 - 21:08 - #7Bah… Se devo essere sincero la guerra dell’web2.0 mi sembra un lotta tra
una moltitudine di gente che vuol cambiare tutto per non cambiare niente.
Dopo aver rotto le scatole in ogni modo per contrastare l’opensource, per
imbrigliare l’utente oltre ogni limite di decenza, visto il fallimento, anziché
iniziare a pensare business model alternativi ancora perseverano.
Il risultato mi sa che sarà un ennesimo fallimento, che costerà a tanti, non
solo a coloro che l’han provocato e renderà ancora più insostenibile la
situazione. Adobe (e non solo lei) lavora per scavarsi la fossa IMO…
Se almeno Chrome non si fosse rovinato nel tempo, se non si fosse ridotto ad
avere performance inaccettabili anche su macchine ben carrozzate lo metterei
di default ovunque, vabbé…
pizzuco
22 feb 2012 - 21:18 - #8È ora di passare a Lightspark!!!
https://launchpad.net/lightspark
pizzuco
22 feb 2012 - 21:22 - #9http://lightspark.github.com/
Roberto Rossi
22 feb 2012 - 22:02 - #10Francamente, lightspark, mi sembra un po troppo giovane per poter pensare di sostituire il prodotto Adobe:
https://github.com/lightspark/lightspark/wiki/Site-Support
Klenje
22 feb 2012 - 22:18 - #11Penso che disinstallerò Chrome anche su Windows… Google sta iniziando ad allargarsi veramente troppo
warpmaster
23 feb 2012 - 14:35 - #12Klenje puoi sostituirlo con Iron, si basa su chromium (come Chrome) ma è completamente degooglizzato.
Ratamusa
23 feb 2012 - 17:37 - #13Cretinata….
Kim Allamandola
23 feb 2012 - 20:25 - #14@Ratamusa #13
Più che altro è l’ennesima dimostrazione che non ci si può fidare del software
closed source! Ed è l’ennesima zappa sui piedi che le aziende closed si dan da
sole.
Il brutto che a troppi ancora piace ricevere il cetriolo, sono in diminuzione
ma sono sempre troppi…
0xdeadbeef
23 feb 2012 - 23:29 - #15Detesto flash ma… dunque i progetti open non provocano mai ABI break?
http://www.openismus.com/documents/management/dealing_with_zealots.shtml
In realtà sono convinto che la decisione, per quanto antipatica, sia stata presa un po’ per facilitare lo sviluppo del plugin su più piattaforme, ma soprattutto perché sarà possibile eseguire plugin PPAPI su NaCl, quindi dentro delle sandbox sicure.
Per avere un quadro delle differenze tra NPAPI, PPAPI e NaCl: http://www.chromium.org/nativeclient/getting-started/getting-started-background-and-basics
Non sottovalutiamo neanche il fatto che il favore popolare su chrome continua a crescere ai danni di FF. Purtroppo. http://www.w3schools.com/browsers/browsers_stats.asp
In questo quadro che può fare Mozilla? Beh, potrebbe supportare NaCl ad esempio, dato che è anch’esso un progetto open (licenza BSD, che mi risulta compatibile con la MPL), anche indipendentemente da quel che fa adobe.
abral
24 feb 2012 - 00:35 - #16@0xdeadbeef:
NaCl è praticamente la stessa cosa di Flash o Silverlight, solo che è open source. Perché Mozilla dovrebbe essere interessata a un prodotto del genere? Meglio le applicazioni web, che usano gli standard web e le API dei browser. NaCl è comunque codice binario, quindi non può essere cross-platform quanto un’applicazione web.
Kim Allamandola
24 feb 2012 - 11:32 - #17@0xdeadbeef #15
Calma, non ho parlato in termini di scelta tecnica ma di modalità della stessa:
se ritieni PPAPI superiore a NPAPI e scegli di supportare solo questa mi va
bene, non mi va bene ad esempio che se il tuo prodotto è usato da n mila utenti
e sviluppatori nel mondo prendi questa decisione con effetto da qui ad un mese,
non mi va bene se non parli prima di come X sia meglio di Y e quindi sarebbe
opportuno adottare X ecc.
Mozilla potrà benissimo supportare NaCl, la cui licenza non mi piace anche se
open (perché non garantisce la libertà delle source modificate da terzi) ma
magari ha altro da fare che buttarcisi di corsa sopra, magari potrebbe farlo
con calma e pochi bachi in 6 mesi, un anno, se la Adobe avesse ovviamente detto
cosa intendeva fare con altrettanta calma. Flash sappiamo tutti, Adobe per
prima che è uno zombie, non ci sono chissà quali vantaggi commerciali da poter
sfruttare se non giusto dare una mano a Chrome iow farsi pagare qualcosa da
Google.
0xdeadbeef
24 feb 2012 - 13:33 - #18@abral
In un mondo perfetto le cose starebbero come dici tu. Ma purtroppo abbiamo una specifica per HTML5 e N layout engine che fanno capo ad N interpretazioni della stessa, tutte diverse tra loro o con dettagli mancanti: http://en.wikipedia.org/wiki/Comparison_of_layout_engines_%28HTML5%29
Quindi chi scrive un’applicazione web in HTML5 sufficientemente complessa, deve praticamente gestire N piattaforme, con i promessi benefici di HTML5 che si annullano. Invece chi scrive un’app per NaCl deve farlo per una piattaforma sola, con minor impiego di tempo, investimenti e conoscenze su una valanga di dettagli tecnici.
Ora se Mozilla sia interessata a NaCl non lo so. Quel che so è che, se le intenzioni di Google dovessero andare in porto, ci guadagnerebbero tutti: Mozilla in supporto, Google in prestigio, Adobe si risparmierebbe di dover mantenere una sandbox apposita e così anche le varie reinplementazioni open. Per non parlare dei vantaggi per i programmatori web.
@Kim Allamandola
Credo che Adobe preveda un futuro nero per Flash, del resto chi meglio di loro conosce le statistiche di utilizzo delle loro tecnologie? E’ spaventata dal botto che stanno facendo Flex ed Air, quindi stavolta si muove in anticipo. Non è da escludere che stia facendo fare a Flash da battistrada per Shockwave, che secondo me non sta messo tanto meglio.
Sicuramente fin qui è solo un esperimento, altrimenti sarebbe passata a PPAPI su tutte le piattaforme, non solo su linux.
Certo, bisogna vedere se NaCl riscuoterà successo, ma finora per Adobe aspettare si è rivelata la scelta sbagliata.
abral
24 feb 2012 - 14:34 - #19@0xdeadbeef:
Non sono affatto d’accordo. NaCl secondo me è una cosa completamente inutile, a quel punto tanto vale utilizzare Flash o Silverlight…
Comunque io non ho mai avuto tanti problemi nello sviluppo di applicazioni web, basta fare un minimo di attenzione che funzionino in tutti i browser, non è uno sforzo così grande. E l’applicazione web ti funzionerà dovunque (su qualunque piattaforma, a differenza di NaCl) senza bisogno di dover effettuare alcuna compilazione, e sarà sicuramente molto più sicura di codice nativo, con sandbox o meno.
Che poi le differenze negli engine valgono allo stesso modo per NaCl, che si occupa soltanto dell’esecuzione di codice. L’interfaccia grafica delle applicazioni NaCl sarebbe sempre in HTML e CSS… Quindi quello che hai scritto non ha molto senso.
Agli sviluppatori conviene molto di più sviluppare applicazioni che funzionino dovunque (perché naturalmente ci si può guadagnare di più) che applicazioni con le limitazioni di NaCl, che non offrono alcun vantaggio avendo lo stesso problema della diversa implementazione degli standard HTML5 (che comunque non è un problema molto grave, almeno per quanto mi riguarda).
Ti assicuro, comunque, che Mozilla non è interessata a NaCl.
abecedario
24 feb 2012 - 15:09 - #20Realizzare applicazioni realmente complesse dove molteplici “Videate”(che bel vecchio termine) contengono dai che devono essere scambiati, ricalcando le applicazioni win 32, non è realizzare sempli pagine che vivono autonomamente dove serve solo un menu che le richiama, aggiungiamo l’uso di un DB in maniera pesante e vediamo cosa accade altro che le 100 righette di javascript, linguaggio orribile ed inutilizzabile per situazioni reali.
Adobe cominciava a dare la speranza per la realizzazione di applicazioni in grado di competere al 70% con sistemi c++ e java dotati di gui.
0xdeadbeef
24 feb 2012 - 15:51 - #21@abral
Dimentichi di dire per chi è inutile. Non mi risulta che la rete trovi flash e silverlight inutili, pur tuttavia potrebbero essere inutili per te. Ma le singole persone non fanno mai parametro, e noi utenti linux questo dovremmo saperlo meglio degli altri. Se poi il senso della tua frase è «meglio ricorrere all’HTML quando si può ed evitare tecnologie proprietarie» allora con me sfondi una porta aperta. Ma si tratta di opinioni personali che comunque non coprono il 100% dei casi.
Aggiungiamoci anche che NaCl consente di portare interi framework binari preesistenti su tutte le piattaforme.
La difficoltà dipende dall’applicazione. Ed anche non trovando difficile lo sviluppo in puro HTML (+ js, che stiamo dimenticando), chiediamoci quanto tempo ci si perde a renderle compatibili per ogni browser.
Ma anche no. Se si scrive un’applicazione web intera per un plugin specifico e si mette il tutto nel body della pagina, allora la musica cambia. E di siti web così ce ne sono parecchi.
Appunto. Quoto dal sito del GDC di Google ( http://code.google.com/intl/it-IT/games/technology-nacl.html ):
Da qui si deduce che un’applicazione web scritta per un plugin specifico può girare dappertutto, basta scaricare il plugin stesso.
Quali?
Non ho mai detto che sia interessata. Adesso è comunque presto, bisogna vedere se NaCl avrà successo. Anche in caso di successo, può darsi che più in là, in quanto coautrice della specifica, metta il broncio e si rifiuti di supportare NaCl o PPAPI comunque. Certo che farebbe solo un danno a sé stessa e ai suoi utenti.
abral
24 feb 2012 - 16:15 - #22@0xdeadbeef:
“Dimentichi di dire per chi è inutile. Non mi risulta che la rete trovi flash e silverlight inutili, pur tuttavia potrebbero essere inutili per te. Ma le singole persone non fanno mai parametro, e noi utenti linux questo dovremmo saperlo meglio degli altri. Se poi il senso della tua frase è «meglio ricorrere all’HTML quando si può ed evitare tecnologie proprietarie» allora con me sfondi una porta aperta. Ma si tratta di opinioni personali che comunque non coprono il 100% dei casi.
Aggiungiamoci anche che NaCl consente di portare interi framework binari preesistenti su tutte le piattaforme.”
Intendo inutile perché è possibile fare lo stesso con Flash o Silverlight.
“La difficoltà dipende dall’applicazione. Ed anche non trovando difficile lo sviluppo in puro HTML (+ js, che stiamo dimenticando), chiediamoci quanto tempo ci si perde a renderle compatibili per ogni browser.”
Te l’ho detto, io non ho trovato molte difficoltà a rendere le mie applicazioni compatibili con ogni browser. Basta fare un minimo di attenzione ed usare le librerie adatte (come jQuery). Ti ripeto che comunque si hanno gli stessi problemi con NaCl.
“Ma anche no. Se si scrive un’applicazione web intera per un plugin specifico e si mette il tutto nel body della pagina, allora la musica cambia. E di siti web così ce ne sono parecchi.”
Allora con JavaScript puoi mettere tutto in un canvas e risolvi i problemi XD
NaCl rappresenta solo la parte “esecutiva” della pagina, è pensato per essere utilizzato al posto di JavaScript, non al posto di HTML e CSS. Fermo restando che, sia con NaCl, sia con JavaScript, è possibile sviluppare l’interfaccia grafica in un canvas, ad esempio.
“Da qui si deduce che un’applicazione web scritta per un plugin specifico può girare dappertutto, basta scaricare il plugin stesso.”
Ma il plugin non esiste per tutte le architetture di CPU, mentre JavaScript è supportato da tutti i browser su tutte le architetture, su tutti i sistemi operativi (anche su quelli meno utilizzati).
“con le limitazioni di NaCl”
Pensavo si capisse dalla mia frase, comunque sono (a parte il fatto che non funziona su tutte le architetture) le stesse limitazioni delle applicazioni web, cioé il fatto che devono fare i conti con standard non sempre implementati allo stesso modo.
“Non ho mai detto che sia interessata. Adesso è comunque presto, bisogna vedere se NaCl avrà successo. Anche in caso di successo, può darsi che più in là, in quanto coautrice della specifica, metta il broncio e si rifiuti di supportare NaCl o PPAPI comunque. Certo che farebbe solo un danno a sé stessa e ai suoi utenti.”
Non sono per niente d’accordo, non sarebbe affatto un danno per gli utenti! NaCl è un plugin, se qualcuno vuole implementarlo in Firefox può benissimo scriversi un plugin NPAPI che lo utilizzi. Non si capisce perché Mozilla dovrebbe supportare una tecnologia che non ha niente di differente da Flash e Silverlight. Così come non supporta questi due, così non supporterà (e fa bene) NaCl.
Insomma non se ne sente proprio il bisogno di una tecnologia del genere, JavaScript basta ed avanza.
0xdeadbeef
24 feb 2012 - 18:30 - #23Anche portare interi engine 3D binari?
E perché? NaCl è uno ed open, non è necessariamente legato a chrome, non ha bisogno di reimplementazioni, ha una licenza che accontenta tutti - progetti open e non - e ai plugin basta supportare PPAPI per girarci. I layout engine sono N.
Ma non esclude che possa essere usato diversamente. Basta farsi un giro nella rete per mettersi le mani tra i capelli ;-)
Ad ogni modo Google non punta certo a rimpiazzare js, anzi mi pare che siano piuttosto attivi anche su quel fronte. Ma un’app js non ti permette ti riusare tecnologie già esistenti che non indirizzano il web, deve girare su più implementazioni e non è altrettanto semplice da debuggare, neanche usando framework come cappuccino o cose del genere.
Questo è vero al momento, il progetto PNaCl punta a fornire un set di strumenti per lo sviluppo di codice che poi girerà in LLVM: http://nativeclient.googlecode.com/svn/data/site/pnacl.pdf
Anche.
abral
24 feb 2012 - 20:46 - #24@0xdeadbeef:
“Anche portare interi engine 3D binari? ”
.
Non è facile ma è possibile. Considera che è possibile (e spesso facile) anche fare il porting in JavaScript (utilizzando Emscripten, che automaticamente compila codice C/C++ in JavaScript utilizzando il compilatore LLVM). Da poco è stato ad esempio effettuato il porting di Ogre3D (motore grafico), o anche il motore fisico Bullet, o il DMBS SQLite.
.
“E perché? NaCl è uno ed open, non è necessariamente legato a chrome, non ha bisogno di reimplementazioni, ha una licenza che accontenta tutti - progetti open e non - e ai plugin basta supportare PPAPI per girarci. I layout engine sono N.”
“Ma non esclude che possa essere usato diversamente. Basta farsi un giro nella rete per mettersi le mani tra i capelli ;-)
Ad ogni modo Google non punta certo a rimpiazzare js, anzi mi pare che siano piuttosto attivi anche su quel fronte. Ma un’app js non ti permette ti riusare tecnologie già esistenti che non indirizzano il web, deve girare su più implementazioni e non è altrettanto semplice da debuggare, neanche usando framework come cappuccino o cose del genere.”
.
Non puoi dividere le mie frasi a pezzi, altrimenti si perde il senso del discorso…
Comunque NaCl è stato pensato per rimpiazzare JavaScript -in alcuni ambiti-. Quello che si può fare con NaCl si può fare anche con JavaScript, solo che JavaScript funziona ovunque. Il problema per cui Google ha pensato NaCl è un problema di prestazioni, ma con i processori odierni e gli engine JavaScript moderni, questo problema non c’è più.
Te lo ripeto: sia NaCl sia JavaScript rappresentano la parte “esecutiva” delle applicazioni. L’interfaccia grafica viene per lo più sviluppata in HTML e CSS, anche se con entrambe le tecnologie (NaCl e JavaScript) si può pensare di non usare HTML e CSS disegnando, ad esempio, in un Canvas. Nel caso di HTML e CSS, i problemi delle diverse implementazioni sussistono con entrambe le tecnologie, nel secondo caso invece per nessuna delle due.
Un’applicazione JS ti permette di riusare tecnologie già esistenti, ad esempio, come ti ho scritto prima, Emscripten.
.
Insomma non c’è alcun vantaggio per Mozilla nel supportare NaCl, che non fornisce nulla di diverso da quanto può dare JavaScript. Molto meglio puntare su una migliore standardizzazione, che elimina quei problemi che citavi (che comunque è possibile mitigare facilmente utilizzando librerie adatte) che, in ogni caso, sussitono sia per NaCl che per JavaScript.
0xdeadbeef
24 feb 2012 - 21:52 - #25Ma guarda, non devi convincere me, io sono già convinto che avere uno standard più completo (e anche restrittivo) possibile sia la scelta migliore. Il problema è che bisogna convincere anche i maker dei vari browser e i vari sviluppatori web che intanto sono già migrati altrove.
abral
25 feb 2012 - 03:40 - #26@0xdeadbeef:
Speriamo che iniziative come questa possano portare più sviluppatori ad utilizzare gli standard web:
https://hacks.mozilla.org/2011/12/mozilla-labs-apps-preview/