App Store: donnine sì, donnine no

Lo store di Apple registra l'ennesimo blocco ad un'applicazione pregna di graziose donzelle in posa. Lo stop, per Cupertino, si deve al comportamento scorretto dell'autore

Roma – È stata interpretata come un netto cambio di rotta rispetto alle politiche commerciali di Apple, a parere di molti spesso al limite del bacchettonismo , la vicenda che qualcuno ha addirittura definito come lo sbarco della pornografia su App Store. Il protagonista è Hottest Girls applicazione il cui nome parla chiaro: mette a disposizione migliaia di foto di giovani più o meno discinte, ha fatto registrare il sold out. E si è fatta espellere.

Chi ha già testato l’applicazione, venduta al prezzo di due dollari, sembra disposto a giurare che le immagini proposte non sarebbero molto più scandalose di quanto è possibile vedere in TV: qualche capezzolo e molto softcore, nudo – per così dire – artistico. Una volta installata sul dispositivo, l’applicazione propone un set di quattro immagini, ognuna delle quali può essere ingrandita e, se particolarmente apprezzata, salvata nella propria galleria di immagini.

Dopo le prime 4 immagini si passa a quelle successive, che verranno scaricate dal server e visualizzate sul display del dispositivo. Il sistema, oltre a fornire alcune sezioni tra cui quelle dedicate alle bellezze bionde, brune, asiatiche e in costume, offre anche un servizio di rating delle immagini, utile a carpire meglio i gusti dei numerosi utenti che hanno acquistato il servizio e ad indirizzare il corso degli update che verranno distribuiti gratuitamente in futuro.

Comunque, nonostante l’applicazione sia normalmente comparsa sull’App Store, la sua repentina rimozione ha dato vita ad un piccolo giallo: vi sarebbe stato un ripensamento da parte dell’azienda californiana. A dissipare ogni possibile dubbio è stato l’ideatore dell’applicazione, secondo il quale le vendite sarebbero state sospese per l’eccesso di domanda da parte degli utenti. Ciò avrebbe sovraccaricato letteralmente i server legati all’applicazione, rendendo necessario lo stop onde evitare ulteriori disagi.

Nonostante ciò, dell’applicazione non sembra essere rimasta alcuna traccia: secondo i più maligni nella rimozione ci sarebbe lo zampino di Apple, ipotesi che sarebbe confermata da una nota inviata dalla Mela per chiarire quanto successo. A quanto pare, dopo aver ottenuto l’inserimento dell’applicazione, stando al parere di Apple, gli sviluppatori avrebbero pilotato dal loro server contenuti non ammessi dal regolamento imposto dall’azienda.

Difficile ipotizzare quale sarà il destino dell’applicazione, dal momento che non è dato sapere con precisione quali possano essere i contenuti non graditi ad Apple. In molti potrebbero pensare ad immagini più pruriginose di una bella donna ammiccante, ma dall’introduzione del sistema di parental control sul firmware 3.0 appena rilasciato, problematiche del genere dovrebbero essere superate.

Vincenzo Gentile

La tua email sarà utilizzata per comunicarti se qualcuno risponde al tuo commento e non sarà pubblicato. Dichiari di avere preso visione e di accettare quanto previsto dalla informativa privacy

  • Michele scrive:
    e i virus?
    campo libero ai virus su Android quindi, ottimo.
    • Michele scrive:
      Re: e i virus?
      ps. strano che Google non ci abbia pensato, Chrome è davvero ben fatto dal punto di vista sicurezza.. sono io ad essere poco informato? :-|
    • Andreabont scrive:
      Re: e i virus?
      Linux normale lavora sugli eseguibili da sempre... eppure non soffre di virus come soffre windows (penso che i virus per linux si possano contare sulle dita di una mano, e probabilmente sono già stati resi tutti inoffensivi)Dato che android ha sotto un sistema linux, rimane quella sicurezza intrinseca (sempre che non abbiano fatto stupidate) di un sistema Linux per PC....Quandi che venga eseguito codice compilato invece che codice per macchina virtuale cambia veramente poco in termini di sicurezza...(ps: esistono i virus scritti in java.....)
  • reef scrive:
    Mi sa che c'è confusione...
    Non vorrei sbagliarmi ma mi era sembrato di capire che le applicazioni Dalvik possano accedere a librerie di codice C/C++ compilato, tramite JNI. E' un pò diverso da come è raccontato nell'articolo..Dal sito...http://developer.android.com/sdk/ndk/1.5_r1/index.html#overviewPlease note that the NDK does not enable you to develop native-only applications. Android's primary runtime remains the Dalvik virtual machine.
    • pabloski scrive:
      Re: Mi sa che c'è confusione...
      sono piuttosto i componenti nativi a non avere una libreria per l'acXXXXX all'api di sistema mentre tramite jni dalvik riesce a comunicare con i componenti nativia ben guardare però mi sembra sensato, google vuole mantenere il software per android il più portabile possibile
      • Antelucano scrive:
        Re: Mi sa che c'è confusione...
        - Scritto da: pabloski
        sono piuttosto i componenti nativi a non avere
        una libreria per l'acXXXXX all'api di sistema
        mentre tramite jni dalvik riesce a comunicare con
        i componenti nativi

        a ben guardare però mi sembra sensato, google
        vuole mantenere il software per android il più
        portabile possibileSì ma solo tra un device Android e l'altro.Non vogliono invece la portabilità tra Android e i sistemi Unix o Java suoi cugini, ragion per cui1) non hanno usato una JVM come tutte le altre e non supportano i vari JSR e2) benché il kernel sia Linux la libc di Android non è compatibile con quella Linux.La ragione ufficiale sono le performance ed il voler confinare la GPL nel kernel e nei driver ed usare altre licenze per le applicazioni. La sensazione però è che Google abbia paura che la gente si possa compilare su Android tutte le applicazioni Java o Linux che ci sono in giro.Che faccia male allo store? ;-)
  • Andreabont scrive:
    E' la possibilità che conta
    Come da titolo, l'importante è che si possa fare, sta allo sviluppatore poi decidere COSA fare...Il bello dell'open è proprio questo: non ci sono catene :-)
    • pippo scrive:
      Re: E' la possibilità che conta

      Come da titolo, l'importante è che si possa fare,
      sta allo sviluppatore poi decidere COSA
      fare...

      Il bello dell'open è proprio questo: non ci sono
      catene
      :-)...E liberarsi dai pesi morti come giava :D
    • pentolino scrive:
      Re: E' la possibilità che conta
      quoto in pieno; alla fine trovo giusto che si sia aperta questa strada. Per come la vedo io in buona parte del codice le prestazioni non sono un grosso problema, soprattutto nella parte che si occupa dell' interazione con l' utente che un' operazione impieghi 1ms o 100ms ad eseguire spesso non è percettibile per l' utente e dunque non fa differenza (andate a vedere lo storico della quota idle del vostro proXXXXXre/i in una tipica sessione desktop se non ci credete).Esistono tuttavia piccole porzioni di codice in cui effettivamente ogni microsecondo è importante, ed è lì che l' NDK casca a fagiolo, permettendo di realizzare soluzioni perfettamente ottimizzate al caso specifico, senza overhead che in quel contesto sarebbero dannosi.E poi fintanto che parliamo di C/C++ siamo a posto, c'è l' unico inconveniente di dovere compilare per architetture diverse, ma non mi pare che questo sia mai stato un problema su linux/unix/bsd...
      • Andreabont scrive:
        Re: E' la possibilità che conta
        Bhe, se guardiamo proprio il millisecondo è un problema :-)Linux e co se la cavano sempre compilando tutto in assembly "universale".... che ha il difetto di non sfruttare mai al 100% la potenza di ogni singola macchina (ognuna differente)Per questo il C si è imposto nel mondo open :-) Hai il sorgente e puoi compilartelo da solo in assembly specifico per la tua macchina, ottenendo la massima ottimizzazione :-)
        • pippo scrive:
          Re: E' la possibilità che conta

          Bhe, se guardiamo proprio il millisecondo è un
          problema
          :-)

          Linux e co se la cavano sempre compilando tutto
          in assembly "universale".... che ha il difetto di
          non sfruttare mai al 100% la potenza di ogni
          singola macchina (ognuna
          differente)Che beep stai farneticando?Quale parte di./configuremakemake installnon ti è chiara?
          Per questo il C si è imposto nel mondo open :-)
          Hai il sorgente e puoi compilartelo da solo in
          assembly specifico per la tua macchina, ottenendo
          la massima ottimizzazione
          :-)Questa è buona la prima ;)
          • Andreabont scrive:
            Re: E' la possibilità che conta
            Guarda che quando istalli un sistema Linux mica lo compili XD è già compilato con le CFLAGS universali XDXD Se vuoi puoi anke metterti le CFLAGS del tuo proXXXXXre... a patto di compilarti tutto XDhttp://it.wikipedia.org/wiki/CFLAGS
          • pippo scrive:
            Re: E' la possibilità che conta

            Guarda che quando istalli un sistema Linux mica
            lo compili XD è già compilato con le CFLAGS
            universali
            XDXD
            gentoo ti dice niente?
          • Andreabont scrive:
            Re: E' la possibilità che conta
            Sto parlando di sistemi linux "normali" non di quelli fatti per i nerd che ti compilano anche la tua vita XDXDXDLo so che esistono quelli che lo fanno... ma è da pazzi usarli... ore per istallare ogni cosa.....
          • pippO scrive:
            Re: E' la possibilità che conta

            Sto parlando di sistemi linux "normali" non di
            quelli fatti per i nerd che ti compilano anche la
            tua vita
            XDXDXD

            Lo so che esistono quelli che lo fanno... ma è da
            pazzi usarli... ore per istallare ogni
            cosa.....Sbaglio o l'hai detto tu questo:"Il bello dell'open è proprio questo: non ci sono catene" ;)
          • Andreabont scrive:
            Re: E' la possibilità che conta
            Lo so, ed è bello che ci sia la possibilità di farlo (non ho detto che devono toglierli) ma rimane il fatto che compilare ogni minima cosa è assurdo, poichè non ne vale la pena (è utile a mio dire solo epr certe cose)Detto questo, la mia opinione, per fortuna, non è abbastanza potente da bandire un sistema operativo XDXDXD
          • pabloski scrive:
            Re: E' la possibilità che conta
            - Scritto da: Andreabont
            Detto questo, la mia opinione, per fortuna, non è
            abbastanza potente da bandire un sistema
            operativo
            XDXDXDmmm non capisco il senso del bandire....come ho detto questo problema i sistemi operativi closed ce l'hanno ancorpiù
        • pabloski scrive:
          Re: E' la possibilità che conta
          assembly universale? intendi il C?se è per questo windows fa uso massiccio del c++ che è molto molto più lento del canzi linux è il sistema operativo che meglio sfrutta tutte la potenza dei proXXXXXri su cui gira
          • Andreabont scrive:
            Re: E' la possibilità che conta
            Non sto parlando di ottimizzazione del programma compilato (e certo che è meglio Linux XDXDXD) sto parlando di come il programma viene compilato dal compilatore....Per girare un programma (che non sia interpretato) deve essere tradotto in assembly (linguaggio macchina).... e purtroppo l'assembly non è molto universale.... i comandi principale si... ma ci sono comandi specifici per ogni CPUEsempio: esistono CPU in grado di fare nativamente il prodotto tra due numeri... altre non ci riescono e devono ricorrere ad una successione di somme.... nella prima ci sarà il comando di moltiplicazione, nella seconda solo quello di addizione....E Linux, per evitare problemi di compatibilità, è compilato in quell'assembly "universale", senza sfruttare i comandi specifici....Se lo vuoi ancora più ottimizzato (si, non è assembly ottimizzato e già strabatte windows XDXDXD) devi compilarti il kernel a manina lavorando sulle CFLAGS (http://it.wikipedia.org/wiki/CFLAGS) per dire al compilatore di generare assembly per la tua specifica macchina...
          • pippo scrive:
            Re: E' la possibilità che conta

            Non sto parlando di ottimizzazione del programma
            compilato (e certo che è meglio Linux XDXDXD) sto
            parlando di come il programma viene compilato dal
            compilatore....

            Per girare un programma (che non sia
            interpretato) deve essere tradotto in assembly
            (linguaggio macchina).... e purtroppo l'assembly
            non è molto universale.... i comandi principale
            si... ma ci sono comandi specifici per ogni
            CPUTu hai le idee un po' confuse...
          • Andreabont scrive:
            Re: E' la possibilità che conta
            Idee confuse ti posso assicurare che non ne ho, massimo nn ne ho voglia di spiegare tutto nel minimo dettaglio e i mei mex risultano oscuri XDXDXDSto facendo ingegneria informatica, e se permetti so come funziona un computer XDXDEsistono linguaggi di alto e basso livello (con tutti gli step intermedi)Il C di quasi basso livello giusto un gradino sopra l'assembler e il puro binario....Il java è ad esempio di alto livello, poichè prima di arrivare al procesore passa una svariata serie di traduzioni (che provocano rallentamento).Non parliamo dei linguaggi interpretati, che non vengono nemmeno compilati e il pc deve interpretarli e eseguire in tempo reale....L'assembler è questo: (stralcio)movq%fs:40, %raxmovq%rax, -8(%rbp)xorl%eax, %eaxmovl$.LC0, %edicallputsmovl$.LC1, %edimovl$0, %eaxcallprintfleaq-64(%rbp), %rdicallgetsmovl$.LC2, %edicallputsEd è quello che viene "letto" dalla CPU.... questi comandi sono quelli "universali", capibili da ogni CPU (in questo caso in architettura 64 bit)... ma potrei compilarlo in un assembler specifico per il mio proXXXXXre, a questo punto altri pc protrebbero non riuscire ad eseguirlo.....
          • Andreabont scrive:
            Re: E' la possibilità che conta
            Naturalmente (inizio a specificare, altrimenti nn so che succede XD)L'assembler si preoccuperà di chiudere la "pila" XD compilando l'assembly in linguaggio macchina... e naturalmente se l'assembly è "universale" (ovvero per una determinata struttura, esempio 32 bit o 64 bit) avremo in risultato un linguaggio macchina leggibile da ogni CPU avente quella struttura.... altrimenti sarà leggibile solo da quel tipo specifico di proXXXXXre... e altri potrebbero non leggerlo....
          • pippO scrive:
            Re: E' la possibilità che conta

            scusa ma.. hai qualche statistica per valutare
            quanto un programma "generico" (cioe' che non sia
            pesantemente matematico oppure multimediale)
            compilato utilizzando le ottimizzazioni per una
            specifica variante di un'architettura vada piu'
            veloce di una compilazione generica (ad es.
            compilare per 486/Pentium I/Xeon/Core2 invece che
            per
            generic-x86)?No, lui è un ingeNiere la sua parola è legge :D
            da ultimo: qui si parla di ARM.. quindi ci sono
            ben poche varianti all'instruction set tra i vari
            "siliconari" e, soprattutto, poche istruzioni
            "evolute" stile x86 (per fortuna ;-)
            )Questo a scuola non l'hanno ancora spiegato ;)
          • Andrea scrive:
            Re: E' la possibilità che conta
            - Scritto da: pippO

            scusa ma.. hai qualche statistica per valutare

            quanto un programma "generico" (cioe' che non
            sia

            pesantemente matematico oppure multimediale)

            compilato utilizzando le ottimizzazioni per una

            specifica variante di un'architettura vada piu'

            veloce di una compilazione generica (ad es.

            compilare per 486/Pentium I/Xeon/Core2 invece
            che

            per

            generic-x86)?

            No, lui è un ingeNiere la sua parola è legge :D


            da ultimo: qui si parla di ARM.. quindi ci sono

            ben poche varianti all'instruction set tra i
            vari

            "siliconari" e, soprattutto, poche istruzioni

            "evolute" stile x86 (per fortuna ;-)

            )
            Questo a scuola non l'hanno ancora spiegato ;)infatti sono un ingeNiere informatico pure io (anche se non c'e' proprio molto di cui vantarsi :-D ) e queste cose le ho imparate in piccola parte a scuola (si' qualcosa si impara anche li' ;-) ) e in gran parte in 6 anni di lavoro nel settore Linux embedded ;-)
          • pippO scrive:
            Re: E' la possibilità che conta

            infatti sono un ingeNiere informatico pure io
            (anche se non c'e' proprio molto di cui vantarsi
            :-D ) e queste cose le ho imparate in piccola
            parte a scuola (si' qualcosa si impara anche li'
            ;-) ) e in gran parte in 6 anni di lavoro nel
            settore Linux embedded
            ;-)In che zona sei, se non sono indiscreto?
          • Andreabont scrive:
            Re: E' la possibilità che conta
            Guarda, non è che dico di sapere tutto, sia mai... non si finisce mai di imparare.... Però mi stava dicendo che non e capivo niente.... e quindi ho soltanto specificato di essere nel settore... poi ho detto "sto facendo" quindi sono proprio il primo che sta imparando...Non ho mai detto che "so tutto", ma non si può nemmeno dire che "non so niente" .... un pò meno estremismo nelle valutazioni non sarebbe male XDps: si scrive "Ingegnere" non "IngeNiere" XD
          • Shu scrive:
            Re: E' la possibilità che conta
            - Scritto da: Andrea
            da ultimo: qui si parla di ARM.. quindi ci sono
            ben poche varianti all'instruction set tra i vari
            "siliconari" e, soprattutto, poche istruzioni
            "evolute" stile x86 (per fortuna ;-)
            )Ne sei sicuro? Dai un occhio alla pagina di wikipedia sull'architettura ARM.Tra una CPU e l'altra cambiano un sacco di cose. Giusto per farti un esempio, angstrom (e il vecchio OpenZaurus) su Zaurus sono da 2 a 10 volte più veloci del S.O. originale Sharp sugli Zaurus, semplicemente perché hanno una libreria di emulazione della FPU, mentre sulla CPU originale ogni istruzione FPU provoca un'eccezione che la manda in emulazione FPU.Alcune CPU sono multicore, altre hanno istruzioni SIMD, praticamente ogni CPU ha valori di cache diversi, alcune hanno MMU, altre no, alcune sono superscalari, altre no, molte hanno una modalità "16 bit" che è più lenta ma consuma molta meno energia (e si può switchare a caldo), alcune sono in-order, altre out-of-order, ecc. ecc.Credo che il panorama ARM sia, ad oggi, molto più complesso di quello x86.Bye.
          • Thescare scrive:
            Re: E' la possibilità che conta
            - Scritto da: Shu
            Terzo: la semplicità di programmazione si paga in
            velocità di esecuzione. Gestire un array di long
            non ridimensionabile in C significa semplicemente
            scrivere dei valori in certe locazioni di
            memoria, una, massimo due, istruzioni assembler.
            Gestire una ArrayList in Java significa ereditare
            da una decina di classi/interfacce, quindi per
            ogni acXXXXX avere diverse indirezioni tra un
            metodo e l'altro, avere controllo delle
            eccezioni, e naturalmente compilazione e
            "mantenimento in RAM" di tutto il codice (perché
            anche le classi base sono scritte in
            Java).

            Molto comodo, sicuro (niente buffer overflow),
            veloce da sviluppare, ma anche pesantissimo,
            dell'ordine delle 100-1000 volte più
            lento.

            Nella maggior parte dei casi non è
            importantissimo, nemmeno in un contesto embedded
            (non si lavora quasi mai con milioni di elementi,
            quindi si aspetta magari 1-2 secondi), ma in
            alcuni casi è
            fondamentale.Non mi sembra corretto confrontare un array con un List (ArrayList). Se mi serve un array non ridimensionabile utilizzo array anche in java e non certamente un ArrayList
          • Whishper scrive:
            Re: E' la possibilità che conta
            - Scritto da: Thescare
            - Scritto da: Shu

            Non mi sembra corretto confrontare un array con
            un List (ArrayList). Se mi serve un array non
            ridimensionabile utilizzo array anche in java e
            non certamente un
            ArrayList Quoto!
          • pippO scrive:
            Re: E' la possibilità che conta


            Non mi sembra corretto confrontare un array con

            un List (ArrayList). Se mi serve un array non

            ridimensionabile utilizzo array anche in java e

            non certamente un

            ArrayList
            Quoto!Beh, allora è solo dieci volte più lento? :D
          • Thescare scrive:
            Re: E' la possibilità che conta
            - Scritto da: pippO


            Non mi sembra corretto confrontare un array
            con


            un List (ArrayList). Se mi serve un array non


            ridimensionabile utilizzo array anche in java
            e


            non certamente un


            ArrayList

            Quoto!
            Beh, allora è solo dieci volte più lento? :DDati?Io ho trovato questo http://www.stefankrause.net/wp/?p=6
          • pippO scrive:
            Re: E' la possibilità che conta




            Non mi sembra corretto confrontare un array

            con



            un List (ArrayList). Se mi serve un array
            non



            ridimensionabile utilizzo array anche in
            java

            e



            non certamente un



            ArrayList


            Quoto!

            Beh, allora è solo dieci volte più lento? :D

            Dati?
            Io ho trovato questo
            http://www.stefankrause.net/wp/?p=6Quello che ha fatto il benchmark della malloc?(rotfl)(rotfl)(rotfl)Riprova sarai più fortunato :D
          • Thescare scrive:
            Re: E' la possibilità che conta
            Io ti ho fornito dei dati. Se me li vuoi contestare trova altre prove che contraddicono quelle da me fornite. Se ti interessa avere una conversazione costruttiva. Se ti interessa solo trollare, la discussione da parte mia finisce qui.
          • pippO scrive:
            Re: E' la possibilità che conta
            - Scritto da: Thescare
            Io ti ho fornito dei dati. Se me li vuoi
            contestare trova altre prove che contraddicono
            quelle da me fornite. Se ti interessa avere una
            conversazione costruttiva. Se ti interessa solo
            trollare, la discussione da parte mia finisce
            qui.Ti hanno già risposto, e comuque quello è l'unico testo che trovi al riguardo, immagino di sapere perchè... :D
          • Shu scrive:
            Re: E' la possibilità che conta
            - Scritto da: Thescare
            Dati?Per esempio questi:http://shootout.alioth.debian.org/u32q/benchmark.php?test=all&lang=javaxint&lang2=gcc&box=1Bye.
          • Thescare scrive:
            Re: E' la possibilità che conta
            - Scritto da: Shu
            - Scritto da: Thescare


            Dati?

            Per esempio questi:

            http://shootout.alioth.debian.org/u32q/benchmark.p

            Bye.http://shootout.alioth.debian.org/u32q/benchmark.php?test=all&lang=java&lang2=gcc&box=1Non mi sembra ci sia tutta questa differenza(a parte l'occupazione di memoria)
          • Shu scrive:
            Re: E' la possibilità che conta
            - Scritto da: Thescare
            - Scritto da: Shu
            http://shootout.alioth.debian.org/u32q/benchmark.p
            http://shootout.alioth.debian.org/u32q/benchmark.p

            Non mi sembra ci sia tutta questa differenza(a
            parte l'occupazione di
            memoria)Tenendo presente che stiamo parlando di software per sistemi embedded (telefonini) con, mediamente, 128 MB di RAM, una occupazione di 20-30 volte superiore ti sembra poco?Significa, tra le altre cose, che devi fare un programma in C di massimo 2 MB, altrimenti non entra nemmeno nella RAM del telefono (40-60MB).Nei benchmark, invece, i due che sono più veloci del C, lo sono praticamente solo perché sono completamente composti da metodi static e da variabili static final (quindi costanti). Il resto è da 2 a 3 volte più lento.Su benchmark che comunque sono fatti per essere eseguiti in loop e quindi JIT-ati.In ogni caso non sto affatto dicendo che Java faccia schifo (sebbene abbia visto di molto meglio), ma semplicemente che per forza è più lento di un compilato in particolari compiti.Bye.
          • Thescare scrive:
            Re: E' la possibilità che conta
            I link di cui abbiamo discusso parlavano di j2se e non della versione me, di cui sinceramente conosco ben poco e non mi azzardo a parlare. Naturalmente hai ragione, ci sono situazioni in cui il java è migliore del c ed altre in cui il c è migliore del java. Come dicevo nell'altra risposta sono linguaggi progettati per usi differenti, con i relativi svantaggi e vantaggi.
          • Thescare scrive:
            Re: E' la possibilità che conta
            A parte il discorso prestazionale credo che ogni linguaggio sia stato progettato per uno scopo. Quindi ci sono scenari in cui è meglio utilizzare Java, altri in cui è meglio utilizzare c/c++ ed altri in cui è preferibile utilizzare tex anche se sono tutti turing completi e quindi equivalenti
          • pippO scrive:
            Re: E' la possibilità che conta

            DAVLIK NON E' JAVA ne a livello di bytecode, ne a
            livello di runtime. Se ci metti dentro un file
            java col cavolo che
            parte...Allora giava fa schifo pure a quelli di google :D
          • Shu scrive:
            Re: E' la possibilità che conta
            - Scritto da: Whishper
            - Scritto da: Shu

            - Scritto da: Whishper
            http://developer.android.com/guide/practices/desig



            Alcune di queste cose, un compilatore con

            ottimizzatore le fa prima che il programma venga

            eseguito, mentre una macchina JIT non ha tempo
            di

            farlo.

            Verissimo! Chi ti dice che il compilatore java
            normale (javac) non le faccia? Le fa!! Il
            compilatore davlik in tutta onestà non lo
            so..No, non le fa, visto che è Google stessa a dire di ottimizzare a mano...
            Stime prese dove?Era semplicemente per dire che essendo un linguaggio basato su una virtual machine, con strutture dati ad alto livello, con diversi livelli di astrazione e tutto il resto, a meno di errori pacchiani di programmazione, è sempre e comunque più lento di uno compilato.In cambio dà certe garanzie e facilitazioni.Bye.
          • Whishper scrive:
            Re: E' la possibilità che conta
            - Scritto da: Shu
            - Scritto da: Whishper

            - Scritto da: Shu


            - Scritto da: Whishper



            http://developer.android.com/guide/practices/desig





            Alcune di queste cose, un compilatore con


            ottimizzatore le fa prima che il programma
            venga


            eseguito, mentre una macchina JIT non ha tempo

            di


            farlo.



            Verissimo! Chi ti dice che il compilatore java

            normale (javac) non le faccia? Le fa!! Il

            compilatore davlik in tutta onestà non lo

            so..

            No, non le fa, visto che è Google stessa a dire
            di ottimizzare a
            mano...


            Stime prese dove?

            Era semplicemente per dire che essendo un
            linguaggio basato su una virtual machineDefinire, please. Tenendo conto che può essere eseguito su Java(TM) Chips...Poi, leggiti:http://en.wikipedia.org/wiki/Java_performanceSi parla che nei videogiochi, area in cui java non è mai andata forte, si parla di 5-15% Più lento di C. Ma si dice che in molti casi Java è più veloce di C e C++.Sembra fantascenza? Immagina del codice pesante. (Per codice pesante intendo quello che itera molte volte su di se stesso, è li che contano le performances. Se è pesante perché è programmato coi piedi, non c'è linguaggio che tenga). Non avrebbe senso ottimizzare una riga di codice che gira 2 volte in tutto. Avrebbe senso farlo su del codice che viene eseguito 1 miliardo di volte? Altroché. E qui interviene il JIT. Se il codice ci mette tanto in assoluto, ha senso perdere magari un secondo per ottimizzarlo come si deve? Altroché, se l'ottimizzazione ti fa risparmiare ore alla fine. Che ottimizzazioni sono possibili?1) Ottimizzazioni statiche. Naah...! Quelle le ha già fatte javac. Non c'è più nulla da ottimizzare. E sono le stesse che può fare anche il C2) Ottimizzazioni dinamiche. Qui c'è MOLTO che si può fare. Le fa il JIT, e il C/C++ se le sogna, perché il C non si può automodificare. Inoltre, vengono applicate ottimizzazione PLATFORM DEPENDANT, quelle per intenderci che si possono fare in C solo istruendo il compilatore a farlo, e che sono difficilissime da 'indovinare' a parte ovviamnente dire qual'è il proXXXXXre ESATTO e si può così sfruttarlo alla grande.E questo da la possibilità a Java di andare come il C++ ottimizzato. La differenza è che deplyare java è infinitamente più facile che deployare il C++ ottimizzato
            , con
            strutture dati ad alto livello, con diversi
            livelli di astrazione e tutto il resto, Perché, il C++ non ha le stesse features? Poraccio...
            a meno di
            errori pacchiani di programmazione, Che programmare in assembly non porti ad errori di programmazione, è da (rotfl). Senza offesa, ma l'hai sparata VERAMENTE grossa...
            è sempre e
            comunque più lento di uno
            compilato.Bella forza! Questo cmq non giustifica alcunché
            In cambio dà certe garanzie e facilitazioni.

            Bye.Bye
          • pippO scrive:
            Re: E' la possibilità che conta

            2) Ottimizzazioni dinamiche. Qui c'è MOLTO che si
            può fare. Le fa il JIT, e il C/C++ se le sogna,
            perché il C non si può automodificare.E con questa ti sei giocato la già poca credibilità che avevi!Il codice automodificante esiste da quando esistono i computer!
          • Andreabont scrive:
            Re: E' la possibilità che conta
            XD, dato che siamo nel discorso vorrei precisare solo una cosuccia :-)Si, è vero, se si usa la Java real machine il problema è trascurabile... essendo in pratica codice nativo hardware (anche se non conosco bene le specifiche)Ma se usi la compilazione JIT, su macchina virtuale, come spesso accade, bhe, in questo caso è più veloce di una non-JIT, ma rimane sempre che in tempo reale deve essere tradotta in assembly del processore ed eseguita... è sempre leggermente meno performante di un assembly già compilato..... (almeno in apertura)Ma siamo andando leggermente off-topic su dei dettagli troppo tecnici e spesso non così rilevanti.... :-)
          • pippO scrive:
            Re: E' la possibilità che conta

            Certo. E' vero. Ma mi fanno girare parecchio...
            quelli che alimentano queste false superstizioni
            sulla lentezza di
            java.Già è vero TUTTI i generatori di frattali giava che ho provato erano delle lepri :D
          • pippO scrive:
            Re: E' la possibilità che conta

            Idee confuse ti posso assicurare che non ne ho,
            massimo nn ne ho voglia di spiegare tutto nel
            minimo dettaglio e i mei mex risultano oscuri
            XDXDXD

            Sto facendo ingegneria informatica, e se permetti
            so come funziona un computer
            XDXDEcco dov'è il problema ;)
            L'assembler è questo: (stralcio)

            movq%fs:40, %rax
            movq%rax, -8(%rbp)
            xorl%eax, %eax
            movl$.LC0, %edi
            callputs
            movl$.LC1, %edi
            movl$0, %eax
            callprintf
            leaq-64(%rbp), %rdi
            callgets
            movl$.LC2, %edi
            callputs

            Ed è quello che viene "letto" dalla CPU....
            questi comandi sono quelli "universali", capibili
            da ogni CPU (in questo caso in architettura 64
            bit)... ma potrei compilarlo in un assembler
            specifico per il mio proXXXXXre, a questo punto
            altri pc protrebbero non riuscire ad
            eseguirlo.....Questo è il tuo secondo problema: NON c'è solo l'x86 nel mondo reale...
          • Andreabont scrive:
            Re: E' la possibilità che conta
            Ma infatti di solito il kernel "precompilato" viene distribuito sia per il 32 che per il 64 bit... ma non viene distribuito mica per ogni singolo modello di proXXXXXre.... XDXDXDXD
          • tardi per logare scrive:
            Re: E' la possibilità che conta
            ma si.se intendi, "non viene distribuito per ogni singolo proXXXXXre prodotto", allora ok...altrimenti si.
          • Whishper scrive:
            Re: E' la possibilità che conta
            Ti racconto una piccola storiella.Ho installato un Ubuntu su di una VM vmware perché ospitasse un server (qua non occorre pigliare per i fondelli, stavo faceno un esperimento...)Funzionava alla perfezione.Metto in produzione e non parte. Motivo? Durante l'installazione, Ubuntu aveva visto il mio modello di CPU (un AMD Sempron) e aveva deciso di installare un Kernel altamente ottimizzato per la mia piattaforma. "Ovviamente" non si è accorto che stavo installando un un sistema virtuale. Altrettanto ovviamente, mettendo in produzione la VM non partiva perché alla prima istruzione specifica eseguita dava errore 'istruzione inesistente nella CPU'Ovviamente ho risolto tutto semplicemente sostituendo il pacchetto del kernel con compilata con istruzioni generiche, e ha funzionato anche in produzione.
          • Shu scrive:
            Re: E' la possibilità che conta
            - Scritto da: Andreabont
            Ma infatti di solito il kernel "precompilato"
            viene distribuito sia per il 32 che per il 64
            bit... ma non viene distribuito mica per ogni
            singolo modello di proXXXXXre....Tranne che per amd64 (per cui c'è ancora solo una implementazione), per x32 ci sono il kernel generico (586, ormai il 486 non viene più supportato), l'ottimizzato generico/Intel (686), e quello per AMD.Alcune funzioni possono essere ottimizzate. Per esempio le CPU VIA hanno hardware di crittografia che può essere usato dai moduli crittografici del kernel.In generale, poi, alcuni software possono essere compilati ottimizzati per MMX, SSE, HT, MTRR, ecc. nelle varie versioni.Bye.
          • Antelucano scrive:
            Re: E' la possibilità che conta
            - Scritto da: Andreabont

            L'assembler è questo: (stralcio)

            movq%fs:40, %rax
            movq%rax, -8(%rbp)
            xorl%eax, %eax
            movl$.LC0, %edi
            callputs
            movl$.LC1, %edi
            movl$0, %eax
            callprintf
            leaq-64(%rbp), %rdi
            callgets
            movl$.LC2, %edi
            callputs

            Ed è quello che viene "letto" dalla CPU....
            questi comandi sono quelli "universali", capibili
            da ogni CPU (in questo caso in architettura 64
            bit)... ma potrei compilarlo in un assembler
            specifico per il mio proXXXXXre, a questo punto
            altri pc protrebbero non riuscire ad
            eseguirlo.....Allora... con ordine...Il compilatore C genera quell'assembler (ma solo se siamo su un x86!), che poi l'assemblatore traduce in linguaggio macchina. Questo finisce nei file .o e viene poi messo insieme dal linker in un eseguibile.Le distribuzioni distribuiscono gli eseguibili. Anche rimanendo nel mondo x86 ci sono tante CPU con tante istruzioni macchina diverse. A meno di ricompilarsi le applicazioni a partire dai sorgenti (es: Gentoo) certe istruzioni non saranno mai sfruttate.Gran parte della confusione è che Andreabont usa CPU come sinonimo di CPU di famiglia x86, e data la sua età lo posso anche capire dato che difficilmente avrà visto qualcosa di diverso (ma a ingegneria informatica insegnano solo Intel e AMD?). Risolto questo equivoco il suo discorso sostanzialmente fila.Certo che quando l'avevo visto scrivere di assembly universale mi era venuto in mente prima il p-code degli anni settanta e poi il bytecode Java degli anni 90 e con quelle cose in mente il suo post sembrava un po' delirante...
          • Whishper scrive:
            Re: E' la possibilità che conta
            A Padova solo 68K (non so adesso, ma fino a pochissimo tempo fa si, giuro!)
          • Andreabont scrive:
            Re: E' la possibilità che conta
            A parte equivoci sulle architetture, per "assembly universale" io intendo tutte quelle istruzioni che sono comuni alla maggior parte dei processori. escludendo quelle che invece sono specifiche a solo una cerchia ristretta...Forse ho usato il termine sbagliato, ma non sapevo come chiamarlo :-)Comq so che a livello di processore viene compilato in linguaggio macchina... ma l'assemby rispecchia molto meglio il linguaggio macchina con termini abbastanza comprensibili (scrivere i comandi in esadecimale è terribile XD) e per questo che parlavo di assebly.
          • Whishper scrive:
            Re: E' la possibilità che conta
            - Scritto da: Andreabont
            A parte equivoci sulle architetture, per
            "assembly universale" io intendo tutte quelle
            istruzioni che sono comuni alla maggior parte dei
            processori. escludendo quelle che invece sono
            specifiche a solo una cerchia
            ristretta...

            Forse ho usato il termine sbagliato, ma non
            sapevo come chiamarlo
            :-)

            Comq so che a livello di processore viene
            compilato in linguaggio macchina... ma l'assemby
            rispecchia molto meglio il linguaggio macchina
            con termini abbastanza comprensibili (scrivere i
            comandi in esadecimale è terribile XD) e per
            questo che parlavo di
            assebly.Si, ma antelucano non parlava di queste (pur tuttavia importanti) 'piccole differenze', ma del fatto che il set di istruzioni può variare radicalmente nel caso di architettura differenti (come ad esempio nel caso i386 vs ARM vs Motorola 68k vs ecc.ecc)
          • pippO scrive:
            Re: E' la possibilità che conta

            Certo che quando l'avevo visto scrivere di
            assembly universale mi era venuto in mente prima
            il p-code degli anni settanta e poi il bytecode
            Java degli anni 90 e con quelle cose in mente il
            suo post sembrava un po'
            delirante...Già gli manca un pochino di esperienza ;)
          • pabloski scrive:
            Re: E' la possibilità che conta
            certamente hai ragione e non è una questione di assembly universale quanto piuttosto di compilare per architetture vecchie....attualmente i kernel che vengono forniti con le distribuzioni ( e ovviamente tutti gli applicativi, driver, ecc... ) sono compilati per le architetture i686 e cioè l'architettura P6ciò però non significa che linux è vincolato a quell'architettura....puoi benissimo prendere tutti i sorgenti e compilare il software per l'architettura nehalempoi non dimentichiamo che ci sono programmi particolari che portano con sè vari versioni delle librerie usate, ognuna compilata per una specifica architetturain linea di principio hai ragione, ma non vedo come questo possa essere legato a linux, visto che ancora oggi windows 7 è compilato per le architetture i586 e non hai nessunissima possibilità di ricompilarlo per ottimizzarlo
          • Andreabont scrive:
            Re: E' la possibilità che conta
            Ma nulla, era tutto partito dal fatto di come si poteva ottimizzare "al massimo" un programma XDUn discorso onestamente privo di utilità concreta, se proprio non vuoi andare a ricompilarti tutto (però in windows non puoi XD)
    • Mucca scrive:
      Re: E' la possibilità che conta
      L'importante che non ci siano standard, che ognuno faccia quello che gli paree che non esistono compatbilità...Boh si vede che la lezione non l'avete ancora imparata
      • pippo scrive:
        Re: E' la possibilità che conta

        L'importante che non ci siano standard, che
        ognuno faccia quello che gli paree che non
        esistono
        compatbilità...Quale standard?Il giava di compile once and debug everywhere? :D
        • Josafat scrive:
          Re: E' la possibilità che conta
          Non che la scrittura in codice nativo sia totalmente immune a questi problemi.Ricordo l'unico (credo) programma che rilasciai anni fa, come freeware in Internet. Usava, per una determinata funzione, delle standard API Win32. Da Win2000 a WinXP, quella parte ha smesso di funzionare. Magari, con una Virtual Machine, il problema non ci sarebbe stato: con Java, finora, non mi è mai capitata nemmeno una volta di differenze di funzionamento tra una piattaforma e l'altra.
          • pippO scrive:
            Re: E' la possibilità che conta

            Magari, con una Virtual Machine, il problema non
            ci sarebbe stato: con Java, finora, non mi è mai
            capitata nemmeno una volta di differenze di
            funzionamento tra una piattaforma e
            l'altra.Nemmeno tra le varie ennemila versioni mobile/server/pc?
          • bollito scrive:
            Re: E' la possibilità che conta
            - Scritto da: pippO

            Magari, con una Virtual Machine, il problema non

            ci sarebbe stato: con Java, finora, non mi è mai

            capitata nemmeno una volta di differenze di

            funzionamento tra una piattaforma e

            l'altra.
            Nemmeno tra le varie ennemila versioni
            mobile/server/pc?Ma di che parli?JavaSE 6 e JavaEE 5 e Java ME?Apparte la ME che non ho ancora avuto modo di vedere le altre 2 sono sempre basate sulla JVM6.
        • Whishper scrive:
          Re: E' la possibilità che conta
          - Scritto da: pippo

          L'importante che non ci siano standard, che

          ognuno faccia quello che gli paree che non

          esistono

          compatbilità...

          Quale standard?
          Il giava di compile once and debug everywhere? :DIn effetti Java è uno standard. Chiunque può implementare una JVM compatibile (ce ne sono diverse). Esiste anche una suite di test com MIGLIAIA di test che servono agli implementatori per capire se e dove sbagliano nell'aderenza agli standard.Ovvio che nelle implementazioni ci possono essere poi bachi, come in tutti i software. La lotta fra chi "vende" le JVM sta appunto nel dare l'implementazione + veloce e con - bachi (come kinder! :D)In ogni caso io il java lo compilo su di una macchia (windows-amd)e lo eseguo su di un'altra (linux-intel) e non ho MAI avuto problemi di compatibilità.Se poi tu ti riferisci a problemi di compatibilità nei giochetti java da cellulare, allora il problema la non è di java ma di chi sviluppa i giochi usando delle librerie NON STANDARD implementate solo su quello specifico cellulare.
          • pippO scrive:
            Re: E' la possibilità che conta

            Se poi tu ti riferisci a problemi di
            compatibilità nei giochetti java da cellulare,Che è l'ultimo mercato rimasto a programmatori giava :D
            allora il problema la non è di java ma di chi
            sviluppa i giochi usando delle librerie NON
            STANDARD implementate solo su quello specifico
            cellulare.Strano pensavo che i produttori di cell usassero lo stesso giava uguale per tutti, non è cosi? :@
          • Whishper scrive:
            Re: E' la possibilità che conta
            - Scritto da: pippO

            Se poi tu ti riferisci a problemi di

            compatibilità nei giochetti java da cellulare,

            Che è l'ultimo mercato rimasto a programmatori
            giava
            :DChe io sappia, il mercato principale per Java sono le applicazioni web e le applicazioni enterprise

            allora il problema la non è di java ma di chi

            sviluppa i giochi usando delle librerie NON

            STANDARD implementate solo su quello specifico

            cellulare.

            Strano pensavo che i produttori di cell usassero
            lo stesso giava uguale per tutti, non è cosi?
            :@E' così. Java è sempre lo stesso. Il PROBLEMA è che certi produttori mettono nel telefono delle librerie non standard, implementate in codice nativo, e spingono gli sviluppatori ad usarle. (principalmente si tratta di sviluppatori non java che si prestano a questa bestemmia). Da notare come una libreria RICHIAMABILE da java, non vuol dire che sia Java. Ovviamente se installi la applicazione su di un altro tipo di telefono, la libreria potrebbe non esserci, e quindi l'applicazione non funziona. Se fosse Java, la si potrebbe usare ovunque e funzionerebbe ovunque nello stesso modo. Non avrebbe alcun senso fosse altrimenti.L'operazione di Android ha proprio questo difetto: introducendo la possibiltà di scrivere codice nativo, offre allo sviluppatore di scrivere librerie che hanno la potenzialità di NON FUNZIONARE.
          • pippO scrive:
            Re: E' la possibilità che conta

            L'operazione di Android ha proprio questo
            difetto: introducendo la possibiltà di scrivere
            codice nativo, offre allo sviluppatore di
            scrivere librerie che hanno la potenzialità di
            NON
            FUNZIONARE.Grazie, se scrivo:printf("hello, world"); Funziona ovunque!Ma se faccio qualcosa di diverso auguri? :D
          • Whishper scrive:
            Re: E' la possibilità che conta
            - Scritto da: pippO

            L'operazione di Android ha proprio questo

            difetto: introducendo la possibiltà di scrivere

            codice nativo, offre allo sviluppatore di

            scrivere librerie che hanno la potenzialità di

            NON

            FUNZIONARE.
            Grazie, se scrivo:
            printf("hello, world"); Funziona ovunque!
            Ma se faccio qualcosa di diverso auguri? :DNon l'ho capita.Non è vero che se scrivi printf funziona ovunque. La riprova? Fino a ieri, su Android non funzionava.Facciamo una prova. Scrivi il tuo printf. Compilamenlo e mandamelo. Lo eseguirò su due sistemi operativi. Windows e Linux. Ti facilito la vita, userò la stessa architettura (i386). Scommettiamo che in uno dei due non andrà?
          • pippO scrive:
            Re: E' la possibilità che conta

            Facciamo una prova. Scrivi il tuo printf.
            Compilamenlo e mandamelo. Lo eseguirò su due
            sistemi operativi. Windows e Linux. Ti facilito
            la vita, userò la stessa architettura (i386).
            Scommettiamo che in uno dei due non
            andrà?./configuremakemake installE gira anche su architetture dove di jvm non se ne vede l'ombra ;)
          • Whishper scrive:
            Re: E' la possibilità che conta
            - Scritto da: pippO

            Facciamo una prova. Scrivi il tuo printf.

            Compilamenlo e mandamelo. Lo eseguirò su due

            sistemi operativi. Windows e Linux. Ti facilito

            la vita, userò la stessa architettura (i386).

            Scommettiamo che in uno dei due non

            andrà?

            ./configure
            make
            make install

            E gira anche su architetture dove di jvm non se
            ne vede l'ombra
            ;)Hai capito benissimo quello che dicevo...Qua non si sta parlando di applicazioni in cui l'utente deve compilarsi i sorgenti, si parla di applicazioni pronte per il deploySo che Linux gira su più architetture, ricompilandolo...Però è anche vero che ci sono applicazioni che su certe piattaforme vanno, su altre no
          • bollito scrive:
            Re: E' la possibilità che conta

            ./configure
            make
            make install

            E gira anche su architetture dove di jvm non se
            ne vede l'ombra
            ;)Ti stai accanendo contro Java senza motivo.Pur preferendo sempre il c/C++ standard non vedo motivi per fare il detrattore di java che e' l'unico vero linguaggio totalmente Cross-platform.
          • pippO scrive:
            Re: E' la possibilità che conta

            Ti stai accanendo contro Java senza motivo.
            Pur preferendo sempre il c/C++ standard non vedo
            motivi per fare il detrattore di java che e'
            l'unico vero linguaggio totalmente
            Cross-platform.(rotfl)(rotfl)(rotfl)Si dopo che hai fatto:./configuremakemake install Per compilare la jvm per la tua cpu...
          • fray scrive:
            Re: E' la possibilità che conta
            - Scritto da: pippO

            Facciamo una prova. Scrivi il tuo printf.

            Compilamenlo e mandamelo. Lo eseguirò su due

            sistemi operativi. Windows e Linux. Ti facilito

            la vita, userò la stessa architettura (i386).

            Scommettiamo che in uno dei due non

            andrà?

            ./configure
            make
            make install

            E gira anche su architetture dove di jvm non se
            ne vede l'ombra
            ;)Pensa tu che c'e' gente che si fregia di usare .net che nemmeno e' cross-platform.......Java e' un linguaggio potente, cross-platform e non vedo motivi per parlarne male.
      • pabloski scrive:
        Re: E' la possibilità che conta
        in pratica aprire la possibilità allo sviluppo di codice nativo vuol dire non avere standard?quindi windows e tutti i suoi applicativi sono una completamente fuori standard
        • Antelucano scrive:
          Re: E' la possibilità che conta
          Credo che per standard si intendesse la possibilità di far girare lo stesso programma su varie architetture.In effetti sul mio telefono Nokia Windows non ci va...Le midlet Java che scrivo e faccio girare sul mio computer invece sì.
Chiudi i commenti