Alfonso Maruccia

Apple e le web app col freno a mano

Gli sviluppatori accusano: Cupertino degrada volutamente le prestazioni delle applicazioni web eseguite dall'home screen di iOS. Cospirazione, volontÓ di controllo o semplice bug?

Roma - La denuncia arriva a The Register da parte di alcuni sviluppatori di applicazioni web: lanciare una web app a partire da un'icona-puntatore piazzata sullo schermo principale di iOS su iPhone e iPad equivale a ottenere prestazioni inferiori rispetto a quelle rese possibili dalla fruizione della suddetta app direttamente nel browser Safari.

Se un utente decide di lanciare un'applicazione web dallo schermo "home" del suo iDispositivo con sopra iOS 4.3, dicono gli sviluppatori, quell'applicazione dovrà giocoforza fare a meno delle caratteristiche avanzate di Safari come l'engine JavaScript Nitro, i meccanismi di cache del browser e le modalità di rendering offline "asincrona".

La possibilità di "promuovere" l'uso di un'applicazione remota sullo schermo principale di iOS risulta di notevole convenienza per gli sviluppatori, i quali hanno la possibilità di realizzare il proprio codice in maniera interdipendente rispetto alle diverse piattaforme mobile e possono bypassare il ferreo controllo stabilito da Apple sul suo App Store ufficiale.
Proprio la possibilità di "bucare" la Disneyland dei computer istituita da Cupertino con le app scritte in codice nativo per iOS suggerirebbe che la spiegazione delle prestazioni degradate delle web app vada ricercata nella volontà di Apple di mantenere l'esclusiva sul meglio dell'esperienza oggi possibile con la iPiattaforma.

╚ insomma nata l'ennesima teoria della cospirazione nei confronti della volontà dominatrice della Mela nei confronti della tecnologia consumer, e in tutta risposta Apple non trova di meglio che confermare l'esistenza del "problema", senza fornire però spiegazione alcuna.

Alfonso Maruccia
49 Commenti alla Notizia Apple e le web app col freno a mano
Ordina
  • Considerando che la "notizia" e' ormai in giro dagli inizi di settimana scorsa, potreste anche sforzarvi di informarvi un po' meglio.

    1) Nitro e' stato introdotto con iOS 4.3, Nitro e' piu' veloce del vecchio engine ed e' disponibile solo in Safari, tutto questo e' vero... ma se ragionate un secondo significa che dal 4.3 javascript e' piu' veloce in Safari RISPETTO LA VERSIONE PRECEDENTE. Cio' significa che le WebApp non sono piu' lente... semplicemente vanno alla stessa velocita' che sono sempre andate in precedenza. Per cui in 4.3, Safari va piu' veloce, il resto va come sempre e' andato... le WebApp non vanno "piu' lente", vanno come sono sempre andate.

    2) Il motivo di questa scelta e' probabilmente legato a questioni di sicurezza. Vi rimando a questo articolo apparso su DaringFireball per una possibile spiegazione: http://daringfireball.net/2011/03/nitro_ios_43


    In sostanza e' molto probabile che in uno dei prossimi aggiornamenti di iOS, Nitro venga reso disponibile anche per le WebApp funzionanti in fullscreen.
    non+autenticato
  • - Scritto da: Andrea

    > 2) Il motivo di questa scelta e' probabilmente
    > legato a questioni di sicurezza...

    ╚ una conseguenza di scelte legate alla sicurezza.
    FDG
    10946
  • Avendo già le informazioni tecniche necessarie per valutare la questione, non mi viene in mente che una parola: "stupidità". Riferita a chi ha voluto creare il caso (o a chi lo alimenta). Anzi, direi pure ignoranti. O forse non ci sono, ma ci fanno.

    Attenzione, qui non si tratta di santificare Apple e lodare incondizionatamente iOS. Si tratta di banali questioni tecniche. Se da security policy su iOS nessuna applicazione che viene installata ha il permesso di settare l'execute bit su proprie pagine di memoria su cui sono stati scritti dati, per evidenti questioni di sicurezza, è normale che un just-in-time compiler abbia qualche problema funzionare dentro una di queste applicazioni. Quindi, a meno che l'applicazione non giri in una sandbox, come Safari, non vedremo in opera il just-in-time compiler.

    Ma a troppi giornalisti purtroppo non interessa raccontare storie noiose. Anche se è una panzana, l'importante è che faccia rumore.
    FDG
    10946
  • - Scritto da: FDG
    > Avendo già le informazioni tecniche necessarie
    > per valutare la questione, non mi viene in mente
    > che una parola: "stupidità". Riferita a chi ha
    > voluto creare il caso (o a chi lo alimenta).
    > Anzi, direi pure ignoranti. O forse non ci sono,
    > ma ci
    > fanno.
    >
    > Attenzione, qui non si tratta di santificare
    > Apple e lodare incondizionatamente iOS. Si tratta
    > di banali questioni tecniche. Se da security
    > policy su iOS nessuna applicazione che viene
    > installata ha il permesso di settare l'execute
    > bit su proprie pagine di memoria su cui sono
    > stati scritti dati, per evidenti questioni di
    > sicurezza, è normale che un just-in-time compiler
    > abbia qualche problema funzionare dentro una di
    > queste applicazioni. Quindi, a meno che
    > l'applicazione non giri in una sandbox, come
    > Safari, non vedremo in opera il just-in-time
    > compiler.
    >
    > Ma a troppi giornalisti purtroppo non interessa
    > raccontare storie noiose. Anche se è una panzana,
    > l'importante è che faccia
    > rumore.

    apple non permette che le app girino su una sandbox per cui discorso chiuso, se poi non volevi lodare apple facendo riferimento ad una presunta sicurezza beh, apple non è mai stata brava con la sicurezza informatica e lo ha sempre dimostrato di anno in anno e di upgrade in upgrade sia su ios che su osx, è un problema per un attacker evitare la sendbox per attaccare direttamente safari od una delle millemila app se proprio si deve violare il sistema ios? o su osx è un problema continuare ad inviare inviti <vuoi provare il mio script o la mia app> che tanto gli utenti apple sono talmente ingenui ed infarciti di senso di sicurezza per il loro sistema da cliccare a caso che tanto non prendono virus? l'importante è difendere apple vero FDG?
    non+autenticato
  • - Scritto da: String.from CharCode

    > apple non permette che le app girino su una
    > sandbox...

    Ok, per te se una cosa manca al software questo vuol dire che il suo sviluppatore non la permette?

    A bocca aperta

    Una cosa che sicuramente non è consentita a un processo utente su iOS è modificare l'execute bit.

    > per cui discorso chiuso, se poi non
    > volevi lodare apple facendo riferimento ad una
    > presunta sicurezza beh, apple non è mai stata
    > brava con la sicurezza informatica...

    No, no, anzi, l'hanno pure diminuita consentendo a Safari di farlo. Ma non credo che sia questo il problema.

    Una soluzione sarebbe mettere le web view dentro un processo separato con pochi privilegi. Penso che per fare questo servirebbe almeno il webkit 2, la cui introduzione è prevista con OS X 10.7.
    FDG
    10946
  • - Scritto da: FDG
    > - Scritto da: String.from CharCode
    >
    > > apple non permette che le app girino su una
    > > sandbox...
    >
    > Ok, per te se una cosa manca al software questo
    > vuol dire che il suo sviluppatore non la
    > permette?

    ma quale senso ha che il codice dinamico venga eseguito con nitro e safari in una sandbox, tu mi hai detto per sicurezza, ma questa perde completamente senso quando il codice viene eseguito dal programma web sempre all'interno di ios senza che questo venga boxato, l'unico motivo realistico è che apple privilegia la velocizzazione di tutto cio che passa per il suo wallet garden

    >
    > A bocca aperta
    >
    > Una cosa che sicuramente non è consentita a un
    > processo utente su iOS è modificare l'execute
    > bit.
    >
    > > per cui discorso chiuso, se poi non
    > > volevi lodare apple facendo riferimento ad una
    > > presunta sicurezza beh, apple non è mai stata
    > > brava con la sicurezza informatica...
    >
    > No, no, anzi, l'hanno pure diminuita consentendo
    > a Safari di farlo. Ma non credo che sia questo il
    > problema.
    >
    > Una soluzione sarebbe mettere le web view dentro
    > un processo separato con pochi privilegi. Penso
    > che per fare questo servirebbe almeno il webkit
    > 2, la cui introduzione è prevista con OS X
    > 10.7.

    poteva inserire fin da subito lo split processing senza fare sta figura di merda e magari anche arginare l'emorragia di sviluppatori che si stanno stufando di apple e della mentalita chiusa di jobs
    non+autenticato
  • - Scritto da: String.from CharCode
    > ...l'unico motivo
    > realistico è che apple privilegia la
    > velocizzazione di tutto cio che passa per il suo
    > wallet garden

    Secondo me che il browser per Android notoriamente ha prestazioni superiori e purtroppo questo è un argomento di marketing. Se avessero lasciato il vecchio interprete gliel'avrebbero fatto pesare.
    FDG
    10946
  • - Scritto da: FDG
    > Secondo me che il browser per Android
    > notoriamente ha prestazioni superiori e purtroppo
    > questo è un argomento di marketing. Se avessero
    > lasciato il vecchio interprete gliel'avrebbero
    > fatto pesare.

    Nitro poi c'è da tempo su Safari di OS X. Prima si chiamava SquirrelFish Extreme (o qualcosa del genere), ora gli hanno trovato un nome più bello.
    Ci hanno messo un po' ad implementarlo su iOS per le differenti policy di sicurezza citate. E ancora (evidentemente) non hanno finito.
    non+autenticato
  • - Scritto da: FDG
    > Secondo me che il browser per Android
    > notoriamente ha prestazioni superiori e purtroppo
    > questo è un argomento di marketing.

    Io gioco spesso con un Samsung Galaxy ed il mio iPhone 4 e ti assicuro che in nessuno modo ho trovato Android più veloce di Safari su iOS.

    Discorso diverso se apri una webview da dentro una applicazione, li cambia tutto e iOS per caricare una pagina web ci mette il doppio del tempo (anche su iPad).

    Quando uso Pulse mi limito al testo dell'RSS ed evito sempre di caricare le pagina dall'app ma passo direttamente a Safari.

    Tra l'altro:
    http://www.macitynet.it/macity/articolo/Android-pi...

    Fan AppleFan Linux
  • - Scritto da: FinalCut
    > - Scritto da: FDG
    > > Secondo me che il browser per Android
    > > notoriamente ha prestazioni superiori e
    > purtroppo
    > > questo è un argomento di marketing.
    >
    > Io gioco spesso con un Samsung Galaxy ed il mio
    > iPhone 4 e ti assicuro che in nessuno modo ho
    > trovato Android più veloce di Safari su
    > iOS.

    non mi piace il browser integrato di android ma indubbiamente è piu veloce

    >
    > Discorso diverso se apri una webview da dentro
    > una applicazione, li cambia tutto e iOS per
    > caricare una pagina web ci mette il doppio del
    > tempo (anche su
    > iPad).

    avrebbero potuto usare nitro anche per l'app web
    invece di porre simili limitazioni

    >
    > Quando uso Pulse mi limito al testo dell'RSS ed
    > evito sempre di caricare le pagina dall'app ma
    > passo direttamente a
    > Safari.

    a che serve l'app allora?

    >
    > Tra l'altro:
    > http://www.macitynet.it/macity/articolo/Android-pi
    >

    sito notoriamente critico contro le politiche di apple
    non+autenticato
  • - Scritto da: String.from CharCode
    > - Scritto da: FinalCut

    > > Io gioco spesso con un Samsung Galaxy ed il mio
    > > iPhone 4 e ti assicuro che in nessuno modo ho
    > > trovato Android più veloce di Safari su
    > > iOS.
    >
    > non mi piace il browser integrato di android ma
    > indubbiamente è piu
    > veloce

    Ma dove? Se ti dico che ho spesso occasione di verificare. Prova a caricare la homepage di Repubblica.it (desktop non versione mobile) e poi ne riparliamo.



    > > Quando uso Pulse mi limito al testo dell'RSS ed
    > > evito sempre di caricare le pagina dall'app ma
    > > passo direttamente a
    > > Safari.
    >
    > a che serve l'app allora?

    Ad avere una overview della giornata e saltare avanti e indietro da Safari a Pulse non è un problema. Adesso poi con le gesture a 4 dita di iOS 4.3 è pure divertente.

    > > Tra l'altro:
    > >
    > http://www.macitynet.it/macity/articolo/Android-pi
    > >
    >
    > sito notoriamente critico contro le politiche di
    > apple

    Trolletto da 4 soldi bucati, ecco che ti sei rivelato per quel che vali...

    se la stessa identica cosa te la dice CNet (sito notoriamente poco incline ad Apple) ci credi di più?

    http://news.cnet.com/8301-30685_3-20044325-264.htm...

    Sei ridicolo....

    Fan AppleFan Linux
  • se io sono un troll tu sei un applefan e in questo caso sei peggio tu di me soprattutto quando dici che safari è meglio del browser di android
    non+autenticato
  • > Ma dove? Se ti dico che ho spesso occasione di
    > verificare. Prova a caricare la homepage di
    > Repubblica.it (desktop non versione mobile) e poi
    > ne
    > riparliamo.
    >
    e bravo il genio, andorid carica anche flash...
    non+autenticato
  • (no, non c'è nessuna malignità nelle diverse prestazioni di UIWebKit e Safari)
    http://daringfireball.net/2011/03/nitro_ios_43
    non+autenticato
  • - Scritto da: MacBoy
    > (no, non c'è nessuna malignità nelle diverse
    > prestazioni di UIWebKit e
    > Safari)
    > http://daringfireball.net/2011/03/nitro_ios_43

    e magari credi davvero a quello che hai scritto, perchè la apple si sa queste cose non le fa
    non+autenticato
  • - Scritto da: teribbile
    > - Scritto da: MacBoy
    > > (no, non c'è nessuna malignità nelle diverse
    > > prestazioni di UIWebKit e
    > > Safari)
    > > http://daringfireball.net/2011/03/nitro_ios_43
    >
    > e magari credi davvero a quello che hai scritto,
    > perchè la apple si sa queste cose non le fa

    L'hai letta la spiegazione?
    Comunque è probabile che risolvano prima o poi anche sulla UIWebKit, ma la cosa è meno semplice di quanto possa sembrare se non vogliono inficiare tutti i sistemi di sicurezza che hanno messo su.
    non+autenticato
  • - Scritto da: teribbile
    > - Scritto da: MacBoy
    > > (no, non c'è nessuna malignità nelle diverse
    > > prestazioni di UIWebKit e
    > > Safari)
    > > http://daringfireball.net/2011/03/nitro_ios_43
    >
    > e magari credi davvero a quello che hai scritto,
    > perchè la apple si sa queste cose non le fa

    Prima di fare certe affermazioni bisognerebbe conoscere un po' di più OS X/iOS, a partire da come funzionano i framework.

    I framework usati da una certa applicazione possono essere piazzati nel bundle dell'applicazione o tra i framework di sistema, o in /System/Library o in /Library. Quindi la stessa libreria la puoi trovare in due versioni differenti: una vista da tutte le applicazioni, un'altra dall'applicazione che la contiene. Ad esempio, io su OS X continuo a scaricarmi le nightly build di WebKit.app, che contengono i framework di webkit in versione aggiornata (e instabile), mentre il resto del sistema continua a vedere la versione più vecchia (e stabile).

    Quello che hanno fatto su iOS non è rallentare js per le applicazioni terze parti, ma lasciare la versione vecchia per tutte le applicazioni, e di mettere quella nuova sul nuovo Safari. Cioè, le webapp continuano a funzionare alla velocità a cui funzionavano prima. Safari è più veloce. L'ottimizzazione introdotta in safari è un just-in-time compiler. Avevo già visto dei post su twitter in proposito. La questione è che non è tanto bello dal punto di vista della sicurezza mettere sulle applicazioni terze parti la possibilità di eseguire codice nativo in remoto se questo non viene eseguito in una sandbox. Nel momento in cui la sandbox sarà disponibile in tutte le applicazioni, se ne potrà riparlare.
    FDG
    10946
  • Sulla mia interfaccia Sense, anche io posso inserire un'icona nella pagina iniziale, che non punta ad un'applicazione, ma ad un URL, lanciando quindi il browser.
    Su ios non è così, ma viene lanciato un "subclient" che ha funzioni ridotte rispetto a safari? Mah.
  • - Scritto da: ephestione
    > Sulla mia interfaccia Sense, anche io posso
    > inserire un'icona nella pagina iniziale, che non
    > punta ad un'applicazione, ma ad un URL, lanciando
    > quindi il
    > browser.
    > Su ios non è così, ma viene lanciato un
    > "subclient" che ha funzioni ridotte rispetto a
    > safari?
    > Mah.

    Su iOS è come sulla tua interfaccia, stessa cosa.
    ╚ Punto Informatico che ha capito fischi per fiaschi. Una web app non è un link a forma di icona che che apre Safari su una pagina, ma una pagina con codice specifico per iPhone (o per altri sistemi) che fa funzionare una pagina HTML come fosse una app (con delle ovvie limitazioni, naturalmente). Che poi si apra da un bookmark piuttosto che da una icona o indirizzo scritto a mano ogni volta, è irrilevante.
    ruppolo
    33147
  • - Scritto da: ruppolo
    > - Scritto da: ephestione
    > > Sulla mia interfaccia Sense, anche io posso
    > > inserire un'icona nella pagina iniziale, che non
    > > punta ad un'applicazione, ma ad un URL,
    > lanciando
    > > quindi il
    > > browser.
    > > Su ios non è così, ma viene lanciato un
    > > "subclient" che ha funzioni ridotte rispetto a
    > > safari?
    > > Mah.
    >
    > Su iOS è come sulla tua interfaccia, stessa cosa.
    > ╚ Punto Informatico che ha capito fischi per
    > fiaschi. Una web app non è un link a forma di
    > icona che che apre Safari su una pagina, ma una
    > pagina con codice specifico per iPhone (o per
    > altri sistemi) che fa funzionare una pagina HTML
    > come fosse una app (con delle ovvie limitazioni,
    > naturalmente). Che poi si apra da un bookmark
    > piuttosto che da una icona o indirizzo scritto a
    > mano ogni volta, è
    > irrilevante.

    è molto piu rilevante che apple non consenta l'utilizzo delle tecnologie di velocizzazione della navigazione anche per le webapp, come al solito dietro ogni aggiornamento di apple ci sta la fregatura per i clienti ma tanto non se ne rendono conto limitati come sono
    non+autenticato
  • - Scritto da: teribbile

    > è molto piu rilevante che apple non consenta
    > l'utilizzo delle tecnologie di velocizzazione
    > della navigazione anche per le webapp, come al
    > solito dietro ogni aggiornamento di apple ci sta
    > la fregatura per i clienti ma tanto non se ne
    > rendono conto limitati come sono

    Ma quante belle razzate!
    FDG
    10946
  • - Scritto da: FDG
    > - Scritto da: teribbile
    >
    > > è molto piu rilevante che apple non consenta
    > > l'utilizzo delle tecnologie di velocizzazione
    > > della navigazione anche per le webapp, come al
    > > solito dietro ogni aggiornamento di apple ci sta
    > > la fregatura per i clienti ma tanto non se ne
    > > rendono conto limitati come sono
    >
    > Ma quante belle razzate!

    si affaccia un utente apple, e che ne pensi (parola grossa) di questa ennesima limitazione della tua adorata apple?
    non+autenticato
  • - Scritto da: teribbile

    > > Ma quante belle razzate!
    >
    > si affaccia un utente apple, e che ne pensi
    > (parola grossa) di questa ennesima limitazione
    > della tua adorata apple?

    Lo sai cos'è l'execute bit delle pagine di memoria? Sai che su iOS il set dell'execute bit è un'istruzione privilegiata e che solo i processi di sistema possono usarla, quindi non le applicazioni installate dall'utente? Sai che questo vuol dire che queste applicazioni non possono far diventare dei dati codice eseguibile? Sai che questo serve per far funzionare nelle applicazioni un just-in-time compiler? E quindi adesso sai perché su Safari il just-in-time compiler funziona e sulle altre applicazioni no? Oppure hai argomenti tecnici col quale mostrarmi che tu non hai scritto solo delle grosse emerite razzate?
    FDG
    10946
  • - Scritto da: FDG
    > - Scritto da: teribbile
    >
    > > > Ma quante belle razzate!
    > >
    > > si affaccia un utente apple, e che ne pensi
    > > (parola grossa) di questa ennesima limitazione
    > > della tua adorata apple?
    >
    > Lo sai cos'è l'execute bit delle pagine di
    > memoria? Sai che su iOS il set dell'execute bit è
    > un'istruzione privilegiata e che solo i processi
    > di sistema possono usarla, quindi non le
    > applicazioni installate dall'utente?

    non so lui ma io lo so e questo dimostra con evidenza che apple non offre agli sviluppatori la possibilità di boxare le proprie app favorendo solamente il proprio orticello

    Sai che
    > questo vuol dire che queste applicazioni non
    > possono far diventare dei dati codice eseguibile?

    completamente inutile, come tappare un buco di uno scolapasta, o impedisci l'esecuzione di codice a tutto o bloccare un singolo flusso risulta inutile

    > Sai che questo serve per far funzionare nelle
    > applicazioni un just-in-time compiler? E quindi
    > adesso sai perché su Safari il just-in-time
    > compiler funziona e sulle altre applicazioni no?
    > Oppure hai argomenti tecnici col quale mostrarmi
    > che tu non hai scritto solo delle grosse emerite
    > razzate?

    magari puoi dirmi tu che visto che il jit questa grossa innovazione portata da apple all'umanità che dovrebbe rendere l'utente apple piu figo di tutti è stata messa solo per safari e non per tutto cio che apple firma digitalmente come dovrebbe essere logico aspettarsi da una simile tecnologia, visto che apple puo firmare le webapp perchè non farlo invece che rallentare tutto cio che non passa per il suo splendido wallet garden? ma forse voleva solamente far capire che o pagate o andate piano piu semplice detta cosi vero?
    non+autenticato
  • - Scritto da: String.from CharCode

    > non so lui ma io lo so e questo dimostra con
    > evidenza che apple non offre agli sviluppatori la
    > possibilità di boxare le proprie app favorendo
    > solamente il proprio orticello

    Non c'è nesso tra le due cose.

    > completamente inutile, come tappare un buco di
    > uno scolapasta, o impedisci l'esecuzione di
    > codice a tutto o bloccare un singolo flusso
    > risulta inutile

    ???

    L'unico codice che può eseguire l'applicazione è il suo codice, su cui non può scrivere. Cos'altro si dovrebbe bloccare?

    > magari puoi dirmi tu che visto che il jit questa
    > grossa innovazione portata da apple all'umanità

    Scusa, questi termini li stai usando tu...

    > che dovrebbe rendere l'utente apple piu figo di
    > tutti...

    Idem...

    > è stata messa solo per safari e non per
    > tutto cio che apple firma digitalmente come
    > dovrebbe essere logico...

    Non è un problema certificazioni delle applicazioni ma di buchi del webkit. E, per capirci, il fatto che sia solo Safari a farlo non rende Safari più sicuro. La questione è diversa e mi scuso se non mi sono spiegato bene: o l'execute bit è settabile da tutte le applicazioni, che a questo punto possono essere attaccate per X vie con X in funzione di tutti i tipi di dati che possono trattare e che vengono dalle diverse fonti, non solo dal web, oppure non si può fare e magari si tollera che questo rischio ci sia solo su safari e il web. Dirai: "cosa cambia?". Eh, lo dico pure io!A bocca aperta

    La questione è che altri sistemi per smartphone concorrenti hanno notoriamente browser più veloci... l'ho scritto sull'altro postSorride

    p.s.: per capirci, non sto elogiando la perfezione di Apple, ma sto sono facendo notare che questa storia è una razzata e bastaSorride

    Ok, capisco fare le pulci ad Apple, ma almeno facciamole bene!
    -----------------------------------------------------------
    Modificato dall' autore il 19 marzo 2011 20.11
    -----------------------------------------------------------
    FDG
    10946
  • in pratica ci stai dicendo che safari è più lento di, che so, chrome?

    vabbè sono sciocchezze alla fine, il vero problema di apple si presenterà tra qualche settimana quando le proposte per l'indecenza dei macbook pro sandy bridge che scaldano come forni a microonde raggiungerà proporzioni ragguardevoli
    non+autenticato
  • - Scritto da: collione

    > vabbè sono sciocchezze alla fine, il vero
    > problema di apple si presenterà tra qualche
    > settimana quando le proposte per l'indecenza dei
    > macbook pro sandy bridge che scaldano come forni
    > a microonde raggiungerà proporzioni
    > ragguardevoli

    Ma sei sicuro? Ho letto da qualche parte che scaldano meno dei modelli precedenti.

    Comunque un bel PC con Windows 7 costa di meno e fa di più.
    non+autenticato
  • purtroppo si

    ho girato su vari forum americani e sullo stesso forum della apple e alcuni utenti si stanno lamentando di brutto

    si parla di 60-70 gradi in IDLE!!!!

    io non capisco come cacchio li costruiscono questi macbook pro, ormai è diventata una barzelletta

    ifixit ha trovato enormi quantità di pasta termica sparsa qua e là e ovviamente l'hanno indicata come possibile causa dei surriscaldamenti

    d'altro canto, altra gente, ha provato a sostituire la pasta del macbook con la arctic silver e le temperature sono scese di 10-15 gradi

    c'è poi il problema che le ventole sembrano troppo invasive, cioè da subito partono in quarta e girano troppo velocemente

    un utente ha portato il suo macbook presso un centro d'assistenza e gli hanno confermato che il portatile aveva temperature fuori specifica

    lui ha risolto sostituendolo con un imac ma credo non tutti gradiscano un'opzione simile

    la cosa assurda è che costano un botto, sono spacciati per computer di classe e poi non controllano quanta pasta termica schiaffano quei maledetti cinesi sul processore

    francamente, e mi dispiace di dover dire cose del genere, da quando la Cina ha cominciato a produrre i nostri beni la qualità è scesa di colpo

    un mio amico, appassionato di meccanica, comprò un tornio ( si, una macchina utensile!!! ) da una ditta italiana che produce in Cina e trovò gli ingranaggi ingrassati con grasso pieno zeppo di trucioli di ferro!!!!!

    per fortuna che lui è un fanatico e le macchine che compra le smonta e riassetta prima di usarle, altrimenti gli si sarebbe bruciato il motore in faccia

    ma la cosa assurda è che le aziende occidentali non fanno un minimo di controllo sulla schifezza che gli viene fornita dal quelle caricature di fabbriche made in China
    non+autenticato
  • Io ci leggo che , dopo l'aggiornamento alla versione 4.3, Safari é piu' veloce di 2-2,5 volte, ed ora gli tocca correggere il problema delle webapps. Tutto qui! In fondo sono veloci tanto quanto prima, é Safari ad aver fatto un passo avanti.

    Non vorrete mica pensare sia una cospirazione spero ?!
    non+autenticato
  • Non ci stupiremmo di certo se fosse una delle tante "cospirazioni" di appleA bocca aperta

    P.S. Che Safari sia veloce è una barzelletta, vedi
    http://www.telefonino.net/Apple/Notizie/n26572/Il-...
    http://www.blaze.io/uncategorized/mobile/iphone-vs.../
    Ovvero viene surclassato dal browser di Android su tutta la linea...
    non+autenticato
  • Ma non diciamo fesserie: il browser di iOS è in assoluto il migliore del mondo. Ho qui sottomano alcune decine di migliaia di link che lo provano. Li volete? Sono tutti i post di FinalCut, Ruppolo e Mex.
    non+autenticato
  • - Scritto da: informo
    > Ma non diciamo fesserie: il browser di iOS è in
    > assoluto il migliore del mondo. Ho qui sottomano
    > alcune decine di migliaia di link che lo provano.
    > Li volete? Sono tutti i post di FinalCut, Ruppolo
    > e
    > Mex.


    lasciali stare è un periodaccio per loro, sono impegnati in riunioni di preghiera per via della malattia di jobs, parlano di sacrificare i primogeniti per salvarlo, ruppolo non ha neanche atteso il benestare della apple che ha già sacrificato qualcuno senza nome
    non+autenticato
  • no quello che dicono quegli articoli e quei test sono FALSI

    hanno messo a confronto non l'usabilità e la velocità di safari mobile e del browser di android hammo messo a confronto i sottosistemi che consentono alle app di terze parti di renderizzare html.

    Blaze Software ha fatto retromarcia e si è praticamente scusata e ha palesato l'incompetenza e la leggerezza dimostrate se non la malafede.

    Safari mobile è uno se non il più veloce browser mobile disponibile solo chi è in malafede può affermare il contrario.

    e per chiosare ovvero ti sei sbagliato su tutta la linea.
    non+autenticato
  • - Scritto da: 123456
    > Blaze Software ha fatto retromarcia e si è
    > praticamente scusata e ha palesato l'incompetenza
    > e la leggerezza dimostrate se non la
    > malafede.

    Citation needed.
  • >
    > Citation needed.
    Giusto. Basta questa? L'ho trovata su CNET:

    Blaze backed away from its conclusion in light of the new data. Chief Technology Officer Guy Podjarny told CNET in a statement:
    This test leveraged the embedded browser which is the only available option for iPhone applications. Blaze was under the assumption that Apple would apply the same updates to their embedded browser as they would their regular browser. If this is not the case and according to Apple's response, it's certainly possible the embedded browser might produce different results. If Apple decides to apply their optimizations across their embedded browser as well, then we would be more than willing to create a new report with the new performance results.
    non+autenticato