Roma – L’ormai ex Googler Marissa Mayer aveva in passato chiaramente detto che non ci sarebbe stata invadente pubblicità sull’homepage di Google: ma ora che se n’è andata da Mountain View, a quanto, pare, c’è spazio per un’eccezione a favore del nuovo dispositivo Android di punta.
Nexus 7, infatti, fa letteralmente capolino apparendo sotto la barra di ricerca, infrangendo la consueta bianca purezza della pagina, accompagnato dalla frase: “I giochi sono aperti. Il nuovo tablet da 199 dollari di Google”. ( C.T. )
-
XXXXXccio iddio
MANNAGGIA I SANDALI DI CRISTOP.S. ALFONSO FA' LE PIPPE COI PIEDI -
fate schifo
Siete delle merde, cancellate anche i commenti " scomodi" che la gente vi lascia complimentoni straccio di ritardati cmq tanto per riperete non é panda ma volpe mongoloidi di XXXXX -
per caritá
Ma quale panda rinXXXXXXXXti, ma ve repigliate-
Re: per caritá
- Scritto da: carlo
Ma quale panda rinXXXXXXXXti, ma ve repigliatehttp://www.mozilla.org/projects/firefox/firefox-name-faq.html
-
-
Siamo di fronte...
...all'alba di una rivoluzione.Entro pochi mesi tutti i browser saranno dotati di WebGL e a quel punto che senso avrà sviluppare per windows/linux/mac? Sviluppi i giochi per il web. E non ditemi che l'aspetto grafico è scarso perché non lo è.L'insieme di JS (che ormai è velocissimo!) e supporto multimediale nei browser saranno per i videogiochi la realizzazione della promessa che Java non ha mai mantenuto: "write once, run everywhere".Staremo a vedere (e a giocare).-
Re: Siamo di fronte...
- Scritto da: topolinik
videogiochi la realizzazione della promessa che
Java non ha mai mantenuto: "write once, run
everywhere".Mah forse per i giochi non sarà stato vero. Ma le mie applicazioni java hanno sempre girato bene su windows,linux e mac senza ritocchi. Basta saper programmare, quello che in pochi sanno fare e poi dicono "java fa schifo".-
Re: Siamo di fronte...
- Scritto da: Un vero programmat ore
Mah forse per i giochi non sarà stato vero. Ma le
mie applicazioni java hanno sempre girato bene su
windows,linux e mac senza ritocchi. Basta saper
programmare, quello che in pochi sanno fare e poi
dicono "java fa schifo".Infatti, hahahahahha (rotfl)Il bello è che questi stessi seguono poi i corsi Javaper imparare a programmare BENE con la programmazioneorientata agli oggetti.
-
-
Re: Siamo di fronte...
si vede che non hai mai toccato in mano un computer, JS è l'inefficenza in persona, e WebGL si basa sul JS, ventola della GPU a mille per un cubo in movimento...-
Re: Siamo di fronte...
contenuto non disponibile-
Re: Siamo di fronte...
so che va sui driver,ecc ecc... però il motore di gioco lo scrivi in javascript, dubito lo metti in un shader. Uno ha fatto uno snake in webgl e shader e dopo qualche istante sento già la GPU che alza la ventola, non deve essere il massimo allora...E javascript non è veloce e non lo si potrà ancora spingere avanti, si è già arrivati ormai al massimo credo, ormai le uniche cose su cui lavorano principalmente è sul rendere le pause del GC più corte possibili. Non sarà ancora molto più veloce di così. E a me tutto questo spreco di efficenza non piace neanche un pò. Siamo sempre più mobile, e andiamo a perdere energia su linguaggi inefficenti.... Se l'adobe o la sun avessero lavorato seriamente a java e a flash non saremmo adesso a giocare con il javascript...-
Re: Siamo di fronte...
contenuto non disponibile -
Re: Siamo di fronte...
- Scritto da: unaDuraLezione
- Scritto da: mmmm
so che va sui driver,ecc ecc... però il
motore
di
gioco
Non esattamente.
Dopo aver mandato le istruzioni per disegnare
millemila poligoni, la scheda 3D fa tutto da
se'.
Puoi, cambiare il puynto di vista con 'una'
istruzione, puoi muovere una serie di poligoni
con un'altra
istruzione.
Sono queste le operazioni che farai in JS. La
scheda 3D disegna tutto senza dover rimandare
ogni volta l'elenco dei poligoni e
simili.Da come lo dici sembra che JS faccia due istruzioni su mille quando invece gira continuamente
E javascript non è veloce e non lo si potrà
ancora spingere avanti, si è già arrivati
ormai
al massimo credo
perché mai?
Se viene compilato onfly prima di partire, in
linea teorica può raggiungere prestazioni simili
del
C.
Il problema di JS è che manca di tipizzazione,
tutto è oggetto e di questo un linguaggio risente
in termini di
prestazioni.
Ma hanno aggiunto apposta gli array tipizzati
(non ancora standard
però).
Da poco ho cominciato a studiarlo e mi sembra una cosa assurda, mi sembra un agglomerato di tutto in maniera poco strutturata. Anche il fatto dei typed array, vogliono aggiungere ciò che manca a martellate. Il JS non è stato inventato per gli scopi attuali e ora lo si vuole aggiornare. Ero meglio reinventare da zero qualcosa di nuovo, come ha fatto google con NaCl solo che doveva essere qualcosa di standard e invece google va per i fatti suoi.Dico che non si potrà fare molto di più proprio perchè il JIT è quello che dava una grossa spinta e l'hanno già messo. Per il problema dei tipi hanno messo un JIT che li intuisce e hanno ottenuto un'altra spintarella, poi hanno aggiunto i typed array, ora cercano di migliorare la GC però ottimizzerà le pause ma non lo farà andare più veloce di per sè, solo scatterà meno. Hanno anche aggiunto i thread però per usare il multicore come sono fatti non sono molto versatili. Non dico che non si può migliorare ma c'è un limite e secondo me non siamo molto lontani...
Se l'adobe o la sun
avessero lavorato seriamente a java e a
flash
non
saremmo adesso a giocare con il
javascript...
java e flash sono comunque plug-in mentre JS è
interpretato nativamente del
browser.Lo so però java è capace di prestazioni molto migliori. Il problema semmai è che un'applet è lentissima a partire, se ci avessero lavorato sopra...
P.S.
quarda questo:
http://digisnap.bplaced.net/70s
--------------------------------------------------
Modificato dall' autore il 31 agosto 2012 16.53
-------------------------------------------------- -
Re: Siamo di fronte...
contenuto non disponibile -
Re: Siamo di fronte...
- Scritto da: mmmm
so che va sui driver,ecc ecc... però il motore di
gioco lo scrivi in javascript, dubito lo metti in
un shader.Per fare un esempio, il gioco sviluppato da Mozilla è un gioco C++ che è compilato in JavaScript tramite un software (sviluppato da Mozilla) chiamato Emscripten.I software compilati da C++ in JavaScript sono circa 2-3-4 volte più lenti per ora (a meno di bug).Considera però che Emscripten è stato iniziato da relativamente poco, quindi c'è ancora grande spazio per ottimizzare. E considera che i browser stanno solo ora iniziando ad ottimizzare le loro performance per applicazioni più pesanti.
Uno ha fatto uno snake in webgl e
shader e dopo qualche istante sento già la GPU
che alza la ventola, non deve essere il massimo
allora...Non è che puoi basarti su un tizio che ha fatto uno snake in WebGL per giudicare tutta la categoria dei giochi JS...
E javascript non è veloce e non lo si potrà
ancora spingere avanti, si è già arrivati ormai
al massimo credo, ormai le uniche cose su cui
lavorano principalmente è sul rendere le pause
del GC più corte possibili. Non sarà ancora molto
più veloce di così.Su cosa basi queste tue conclusioni? A me tutto questo parlare senza alcuna base non piace neanche un pò.In realtà, Mozilla sta sviluppando un nuovo engine JS (IonMonkey) proprio per applicazioni più pesanti, che ottimizzerà il codice molto di più di quanto si faccia ora. Quindi c'è UN SACCO di spazio per miglioramenti.
E a me tutto questo spreco di
efficenza non piace neanche un pò. Siamo sempre
più mobile, e andiamo a perdere energia su
linguaggi inefficenti....Che intendi per "efficienza" di un linguaggio?Non capisco cosa significhi l'espressione "spreco di efficienza", non credo che l'efficienza sia un qualcosa che si usi. Forse intendi "spreco di risorse" o qualcosa del genere?Comunque quello che fai è un discorso vecchio come il mondo. Anche il C++ comporterebbe uno spreco rispetto al C e il C rispetto all'Assembly (e si può scendere ancora di più), ma i linguaggi di più alto livello sono molto più potenti (nel senso che compiono lavori enormi nel minor tempo possibile).
Se l'adobe o la sun
avessero lavorato seriamente a java e a flash non
saremmo adesso a giocare con il
javascript...Il linguaggio di programmazione di Flash è quasi uguale a JavaScript. -
Re: Siamo di fronte...
- Scritto da: abral
- Scritto da: mmmm
so che va sui driver,ecc ecc... però il motore
di
gioco lo scrivi in javascript, dubito lo metti
in
un shader.
Per fare un esempio, il gioco sviluppato da
Mozilla è un gioco C++ che è compilato in
JavaScript tramite un software (sviluppato da
Mozilla) chiamato
Emscripten.
I software compilati da C++ in JavaScript sono
circa 2-3-4 volte più lenti per ora (a meno di
bug).
Considera però che Emscripten è stato iniziato da
relativamente poco, quindi c'è ancora grande
spazio per ottimizzare. E considera che i browser
stanno solo ora iniziando ad ottimizzare le loro
performance per applicazioni più
pesanti.
Ma il gioco convertito sarà sempre più lento del C++, anche migliorando emscripten e il broswer.
Uno ha fatto uno snake in webgl e
shader e dopo qualche istante sento già la GPU
che alza la ventola, non deve essere il massimo
allora...
Non è che puoi basarti su un tizio che ha fatto
uno snake in WebGL per giudicare tutta la
categoria dei giochi
JS...
Quello era un esempio per l'altro utente che diceva di usare gli shader per quasi tutto se non ho capito male, è un esempio atipico di gioco WebGL.
E javascript non è veloce e non lo si potrà
ancora spingere avanti, si è già arrivati ormai
al massimo credo, ormai le uniche cose su cui
lavorano principalmente è sul rendere le pause
del GC più corte possibili. Non sarà ancora
molto
più veloce di così.
Su cosa basi queste tue conclusioni? A me tutto
questo parlare senza alcuna base non piace
neanche un
pò.
In realtà, Mozilla sta sviluppando un nuovo
engine JS (IonMonkey) proprio per applicazioni
più pesanti, che ottimizzerà il codice molto di
più di quanto si faccia ora. Quindi c'è UN SACCO
di spazio per
miglioramenti.
Guardo spesso i blog degli sviluppatori di firefox e bugzilla, IonMonkey sono ancora lontani e non so bene su cosa puntano, però come ho scritto sul post per l'altro utente, hanno già il JIT, hanno lavorato sui tipi, ora lavorano sulle pause del GC. Per le applicazioni pesanti so che stanno lavorando ma non sarà nulla di rivoluzionario. C'è un punto oltre il quale non puoi andare, e non credo siamo tanto lontani...
E a me tutto questo spreco di
efficenza non piace neanche un pò. Siamo sempre
più mobile, e andiamo a perdere energia su
linguaggi inefficenti....
Che intendi per "efficienza" di un linguaggio?
Non capisco cosa significhi l'espressione "spreco
di efficienza", non credo che l'efficienza sia un
qualcosa che si usi. Forse intendi "spreco di
risorse" o qualcosa del
genere?
Comunque quello che fai è un discorso vecchio
come il mondo. Anche il C++ comporterebbe uno
spreco rispetto al C e il C rispetto all'Assembly
(e si può scendere ancora di più), ma i linguaggi
di più alto livello sono molto più potenti (nel
senso che compiono lavori enormi nel minor tempo
possibile).
C'è astrazione ed astrazione, ho qualcosa di più semplice a un costo. Se scrivo in C o C++ piuttosto che in assembly il costo è quasi nullo, posso perdere un pò di controllo sulle singole istruzioni però forse avendo una visione più ampia riesco a scrivere codice migliore, o il compilatore stesso riesce a ottimizzare alcune cose meglio di me, ecc...Però qui parliamo di un codice gestito, non nativo come il C, e per di più non è come il Java che si presenta in un bel bytecode facile da eseguire, mi arriva un testo in un linguaggio con poche informazioni che aiutino il compilatore nell'esecuzione, altamente dinamico. Qui lo spreco di risorse è alto e quindi una scarsa efficenza (prima mi sono espresso male). E per efficenza intendo il rapporto tra il lavoro utile e quello eseguito. Per il JS per intenderci devo comprendere il testo, momentaneamente eseguirlo tramite interprete, decidere se compilarlo, eventualmente compilarlo secondo le possibilità dei tipi, eseguirlo, tenenedo conto che potrei dover ricompilarlo nuovamente se il tipo è sbagliato o cambia. E nel frattempo tenere conto di tutti i riferimento all'interno del linguaggio e verso il WebGL e il DOM, preoccupandomi di cancellare tutto il non necessario.Non ho mai dovuto scrivere una VM per JS ma all'incirca dovrebbe essere così.Non mi ricordo dove ma ho letto che il JS è talmente lento da interpretare per tutte le possibilità che consente, che conviene quasi sempre stare a JITtarlo ed eseguire il risultato. Viceversa il Java che arriva con un semplice bytecode conviene fare il jit solo dopo qualche migliaio di esecuzioni, quando so che effettivamente quel punto del codice è molto usato. Tanto il bycode è quasi come un assembly e in un formato che si riesce molto facilmente ad eseguire.Spero di aver chiarito perchè ho una scarsa opinione del JS, anche in confronto ad altri linguaggi ad alto livello.
Se l'adobe o la sun
avessero lavorato seriamente a java e a flash
non
saremmo adesso a giocare con il
javascript...
Il linguaggio di programmazione di Flash è quasi
uguale a
JavaScript.Avevo dato per scontato che flash avesse un linguaggio migliore ma in effetti non ho mai programmato in AS3. -
Re: Siamo di fronte...
- Scritto da: mmmm
Ma il gioco convertito sarà sempre più lento del
C++, anche migliorando emscripten e il
broswer.Si, e questo non è affatto un problema. Se si parlasse di 100 volte più lento ti darei ragione, ma siamo a livelli molto più bassi, la lentezza maggiore giustifica pienamente quello che si può ottenere (sviluppo velocissimo, possibilità di eseguire ovunque).
Guardo spesso i blog degli sviluppatori di
firefox e bugzilla, IonMonkey sono ancora lontani
e non so bene su cosa puntanoIonMonkey probabilmente sarà in Firefox 18. Come ti ho detto, punta ad essere un compilatore JIT migliore di quello base che c'è ora per quanto riguarda le applicazioni pesanti (
hanno già il
JIT, hanno lavorato sui tipi, ora lavorano sulle
pause del GC.Ma non sono cose che una volta sviluppate non migliorano più...Ad esempio i compilatori JIT che ci sono ora sono ottimizzati per lavorare con applicazioni piccole, le ottimizzazioni che fanno sono solo quelle che si possono effettuare più velocemente (e quindi sono anche le ottimizzazioni meno potenti) perché altrimenti, visto che si sta parlando di poche righe di codice, l'overhead della compilazione supererebbe il tempo che ci vuole con l'interprete normale.IonMonkey invece è fatto per applicazioni pesanti, entra in gioco solo quando il motore JS capisce che c'è bisogno di ottimizzazioni pesanti.
Per le applicazioni pesanti so che
stanno lavorando ma non sarà nulla di
rivoluzionario.In base a cosa dici che non ci sarà nulla di rivoluzionario? Io credo che IonMonkey sarà un grosso passo in avanti.
C'è astrazione ed astrazione, ho qualcosa di più
semplice a un costo. Se scrivo in C o C++
piuttosto che in assembly il costo è quasi nullo,
posso perdere un pò di controllo sulle singole
istruzioni però forse avendo una visione più
ampia riesco a scrivere codice migliore, o il
compilatore stesso riesce a ottimizzare alcune
cose meglio di me,
ecc...E' proprio questo il punto. Quando vai ad usare linguaggi più ad alto livello ne perdi un pò in prestazioni ma ne guadagni tantissimo in velocità e semplicità di sviluppo.Anche con JS probabilmente ci saranno cose che il compilatore JIT (proprio perché è JIT ha molte più informazioni su cosa accade durante l'esecuzione del codice) riesce ad ottimizzare meglio di uno sviluppatore umano.Ad esempio PyPy (che è un compilatore JIT per Python, altro linguaggio dinamico), riesce a volte riesce a battere il C (http://morepypy.blogspot.it/2011/08/pypy-is-faster-than-c-again-string.html).
Qui lo
spreco di risorse è alto e quindi una scarsa
efficenza (prima mi sono espresso male). E per
efficenza intendo il rapporto tra il lavoro utile
e quello eseguito. Per il JS per intenderci devo
comprendere il testo, momentaneamente eseguirlo
tramite interprete, decidere se compilarlo,
eventualmente compilarlo secondo le possibilità
dei tipi, eseguirlo, tenenedo conto che potrei
dover ricompilarlo nuovamente se il tipo è
sbagliato o cambia. E nel frattempo tenere conto
di tutti i riferimento all'interno del linguaggio
e verso il WebGL e il DOM, preoccupandomi di
cancellare tutto il non
necessario.E' certo che c'è un overhead, però già 2 volte più lento di codice normale non è chissà che cosa, considerando che ci sono ancora tantissimi altri miglioramenti che verranno sia per quanto riguarda i compilatori JIT sia per quanto riguarda Emscripten (o altri tool del genere, che sono altamente sperimentali).E considerando che la perdita in prestazioni è controbilanciata da un guadagno enorme in semplicità di sviluppo e possibilità di eseguire ovunque. -
Re: Siamo di fronte...
- Scritto da: abral
E' certo che c'è un overhead, però già 2 volte
più lento di codice normale non è chissà che
cosa, considerando che ci sono ancora tantissimi
altri miglioramenti che verranno sia per quanto
riguarda i compilatori JIT sia per quanto
riguarda Emscripten (o altri tool del genere, che
sono altamente
sperimentali).
E considerando che la perdita in prestazioni è
controbilanciata da un guadagno enorme in
semplicità di sviluppo e possibilità di eseguire
ovunque.Guarda spero che IonMonkey sia un grande passo in avanti ma non ci spero molto. Tu parli di grosse applicazioni ma IonMonkey pare sia tutt'altro, una specie di rifacimento in meglio di tutto quanto fatto finora, senza un interessa particolare verso le ottimizzazioni verso le grosse app.Non ho tutto il tuo entusiasmo verso il JS. Due volte più lento secondo me è ben troppo, è la differenza tra un programma fluido e uno che scatta. Inoltre non è affatto semplice da scrivere, la sintassi mi sembra pensata male e poco strutturata, e ci grosse differenze tra i browser in termini di supporto anche senza tirare in ballo il solito IE. Un ragionamento del genere lo posso fare per Java, Python,... che mi semplifico la vita e ottengo un app multipiattaforma ma il JS credo che abbia il posto che ha solo perchè è l'unico linguaggio per browser... -
Re: Siamo di fronte...
- Scritto da: mmmm
Guarda spero che IonMonkey sia un grande passo in
avanti ma non ci spero molto. Tu parli di grosse
applicazioni ma IonMonkey pare sia tutt'altro,
una specie di rifacimento in meglio di tutto
quanto fatto finora, senza un interessa
particolare verso le ottimizzazioni verso le
grosse app.Leggi questo interessante articolo: http://blog.cdleary.com/2011/06/mapping-the-monkeysphere/ (è comunque vecchio, a quanto ho capito ora IonMonkey non sarà più usato come baseline compiler)IonMonkey sarà un compilatore capace di molte più ottimizzazioni, al pari di compilatori come GCC o LLVM, qualcosa come la VM di Java, HotSpot (che contiene il compilatore JIT più veloce al mondo, almeno secondo alcuni test).
Non ho tutto il tuo entusiasmo verso il JS. Due
volte più lento secondo me è ben troppo, è la
differenza tra un programma fluido e uno che
scatta. Inoltre non è affatto semplice da
scrivere, la sintassi mi sembra pensata male e
poco strutturata, e ci grosse differenze tra i
browser in termini di supporto anche senza tirare
in ballo il solito IE. Un ragionamento del genere
lo posso fare per Java, Python,... che mi
semplifico la vita e ottengo un app
multipiattaforma ma il JS credo che abbia il
posto che ha solo perchè è l'unico linguaggio per
browser...Java e Python non ti permettono di fare quello che fai con JS. Con Java non è tanto facile sviluppare un'applicazione per iPhone, ad esempio. Con Python non è tanto facile sviluppare un'applicazione per Android o iPhone, ad esempio.JavaScript ti permette di sviluppare un'applicazione che funziona dovunque e, con opportuni librerie e tool, ti permette di disinteressarti completamente delle differenze tra i vari browser. Considera che Python è anche molto ma molto più lento di JS.
-
-
-
-
Re: Siamo di fronte...
quando la gente avra' in casa i mainframe..............
-
-
Mah....
Beh, intanto il caricamento non mi sembra dei più veloci.Tutto sommato non è male, ma vorrei consigliare a tutti di provare questo qui: http://www.pouet.net/prod.php?which=12036&howmanycomments=100In 96Kb (ripeto: 96Kb!) hanno messo un gioco spettacolare (e parecchio lungo)!E' per questo che mi sono chiesto: ma perché sbattersi tanto con html5 e webgl quando si potrebbe inserire nel browser una sandbox per eseguibili... lo scaricamento del gioco, fosse fatto come Kkrieger (vedi demo) impiegherebbe un battito di ciglia![img]http://www.pouet.net/screenshots/12036.jpg[/img]-
Re: Mah....
contenuto non disponibile -
Re: Mah....
Quanti anni avrà sto gioco? 6 anni?Ad ogni modo avrà anche 96K, ma per farlo funzionare hai bisogno di un proXXXXXre come Dio comanda, perchè si rifà a grafica procedurale.-
Re: Mah....
- Scritto da: Francesco_Holy87
Quanti anni avrà sto gioco? 6 anni?
Ad ogni modo avrà anche 96K, ma per farlo
funzionare hai bisogno di un proXXXXXre come Dio
comanda, perchè si rifà a grafica
procedurale.hum... a me va con un Pentium D. :D-
Re: Mah....
All'epoca avevo un P4, e anche ora con un PD ho spesso la CPU a manetta.
-
-
-
Re: Mah....
a me da errore se provo ad eseguirlo...-
Re: Mah....
contenuto non disponibile -
Re: Mah....
A me funziona pure su wine! -
Re: Mah....
non devi lanciarlo direttamente da zip ma devi prima scompattarlo
-
-
Re: Mah....
- Scritto da: Gnagno
Beh, intanto il caricamento non mi sembra dei più
veloci.Uga buga, sai quanti dati devi scaricare alla prima esecuzione?
E' per questo
che mi sono chiesto: ma perché sbattersi tanto
con html5 e webgl quando si potrebbe inserire nel
browser una sandbox per eseguibili...Guarda che BananaBread è un gioco scritto in C++ (http://sauerbraten.org/) trasformato in JavaScript tramite Emscripten (altre demo qui: https://github.com/kripken/emscripten/wiki), quindi anche quel gioco che hai linkato potrebbe essere trasformato in JavaScript ed eseguito in un browser.Considera che quel gioco sicuramente non ti funzionerà su un sistema operativo diverso o, ancor peggio, su un'architettura diversa. Invece un gioco scritto con tecnologie web funziona ovunque ci sia un browser moderno, cioè praticamente ovunque (e a breve sicuramente anche sulle console).
-
-
Nome firefox
Prima leggi questa info:http://en.wikipedia.org/wiki/Red_panda-
Re: Nome firefox
- Scritto da: bit
Prima leggi questa info:
http://en.wikipedia.org/wiki/Red_pandaah ah ah qnt ingnoranza tutte balle wikipedia è pericolosa e fa dinformazzione l'addetto anke il tg5 ah ah ah ah (troll)
-
-
Firefox
Non si chiama "Panda rosso" ma volpe-
Re: Firefox
prima leggi.http://en.wikipedia.org/wiki/Red_panda-
Re: Firefox
E che palle, lo sanno tutti che FireFox significa "volpe di fuoco"... non ci vuole un genio!-
Re: Firefox
- Scritto da: Ottavio
E che palle, lo sanno tutti che FireFox significa
"volpe di fuoco"... non ci vuole un
genio!Ma anche dragon web in realtà è un panda. Lo sa anche Tai Lung Safari. Un grosso e lardoso panda. ;) -
Re: Firefox
- Scritto da: Ottavio
E che palle, lo sanno tutti che FireFox significa
"volpe di fuoco"... non ci vuole un
genio!Tutti i geGni italiani lo sanno di sicuro...Per chi mastica un po' di inglese invece:http://www.mozilla.org/projects/firefox/firefox-name-faq.htmlhttp://en.wikipedia.org/wiki/Red_panda -
Re: Firefox
non è che bisogna fare la traduzione spezzando le parolefire=fuoco fox=volpe ma il risultato "firefox" è panda rosso-
Re: Firefox
- Scritto da: panda rossa
- Scritto da: narcigalak
non è che bisogna fare la traduzione
spezzando
le
parole
fire=fuoco
fox=volpe
ma il risultato "firefox" è panda rosso
E' come ladybug.
lady=donna
bug=windows
ma il risultato non e' donna alla finestra.WIN -
Re: Firefox
- Scritto da: Enjoy with Us
- Scritto da: narcigalak
non è che bisogna fare la traduzione
spezzando
le
parole
fire=fuoco
fox=volpe
ma il risultato "firefox" è panda rosso
A questo non credono neppure quelli di mozillahttp://www.mozilla.org/projects/firefox/firefox-name-faq.html -
Re: Firefox
contenuto non disponibile
-
-
-
-
-
sensibilità del mouse
contenuto non disponibile-
Re: sensibilità del mouse
E che palle, lo sanno tutti che FireFox significa "volpe di fuoco"... non ci vuole un genio!-
Re: sensibilità del mouse
contenuto non disponibile-
Re: sensibilità del mouse
Basta co ste XXXXXXXte avete rotto le pallechise ne sbatte se e' una volpe un panda o un cane del ca77o !- Scritto da: unaDuraLezione
- Scritto da: Ottavio
E che palle, lo sanno tutti che FireFox
significa
"volpe di fuoco"... non ci vuole un
genio!
A dire il vero è un tanuki-
Re: sensibilità del mouse
92 minuti di applausi!!! -
Re: sensibilità del mouse
contenuto non disponibile
-
-
-
-