Jony Ive lascia la Apple: una tragedia o una fortuna?

Jonathan “Jony” Ive dopo trent’anni abbandona la Apple per fondare una sua azienda, LoveFrom, che avrà la Apple come prima cliente. La notizia ha riempito per giorni le gazzette tecnologiche (e non) di tutto il mondo (come si può leggere ad esempio qui, qui e qui) e quasi tutti i commentatori, una volta superata la sorpresa dell’annuncio, si sono augurati che la collaborazione fra il cavaliere inglese1 e la casa madre californiana potesse continuare esattamente come prima.

So di dire una cosa impopolare, ma secondo me sarebbe un male. Jony Ive stava esagerando.

Jony Ive è (è stato?) un grande designer e nel corso della sua lunga carriera ha fatto cose egregie — penso ai vari iMac, dal G3 della rinascita al G4 a lampada al G5 tutto-in-uno, penso all’iPod, all’iPhone, ad iOS 7 — ma come tutte le archi-star a un certo punto si è fatto prendere la mano adottando un’estetica anoressica che anteponeva il design alla funzionalità. Tutto troppo sottile e minimalista, accessibilità e riparabilità zero.

E sono venuti il MacBook Pro ipersottile, esteticamente perfetto ma tecnicamente incomprensibile, il portatile che obbliga a portarsi dietro una pletora di accessori anche solo per poter collegare una volgare chiavetta USB. O l’orrida tastiera a “farfalla”, i cui tasti hanno la corsa di un pezzo di vetro e vengono mandati in crisi da un granello di polvere, costringendo a cambiare tutta la parte superiore del portatile (e a volte anche l’intero computer!) per un solo tasto malfunzionante.

Oppure gli AirPods che quando si esaurisce la batteria, due anni ad essere fortunati, vanno buttati via perché nessuno, nemmeno Apple, può sostituirla senza distruggerli. O gli iMac, i Mac Mini e gli Air con la RAM saldata e non aggiornabile, quello che scegli al momento dell’acquisto te lo tieni per sempre.2

Ma possiamo dimenticare il fiasco più clamoroso di tutti, il Mac Pro buono da tempo solo come (costosissimo) cestino dei rifiuti? Il computer professionale tanto minimale che per essere usato veramente ha bisogno di un sacco di accessori esterni, tutti collegati precariamente via cavo. Il computer professionale ma non aggiornabile (infatti è ancora fermo al 2013), un vero controsenso per chi vorrebbe preservare nel tempo il pesante investimento economico richiesto. Il computer professionale che scalda, scalda dannatamente troppo per essere adatto ai compiti pesanti a cui dovrebbe essere destinato. Colpa degli ingegneri che non sanno fare i calcoli termici o del designer per il quale la funzione reale del computer che progetta conta poco o niente?

Sarà solo un caso che nel Mac Mini ultima versione Apple offra di nuovo la possibilità di aggiornare facilmente al RAM? O che il nuovo Mac Pro sia tornato al design precedente, un grosso case metallico e bucherellato per dissipare meglio il calore, apribile con facilità e con tanto spazio per aggiungere dischi, RAM e schede di interfaccia? O che la tastiera dei prossimi MacBook Pro sarà modificata per l’ennesima volta in tre anni?

Forse Tim Cook e il consiglio di amministrazione della Apple hanno concluso che Jony Ive aveva tirato troppo la corda ed hanno deciso di farlo finalmente fuori, altro che separazione consensuale.

Era ora. Noi utenti Apple ci meritiamo di meglio.


  1. Jony Ive è stato nominato Sir nel 2012. 
  2. Un vero assurdo tecnico: la quantità di RAM necessaria a far funzionare al meglio un computer aumenta nel tempo con l’evoluzione del sistema operativo e delle applicazioni. Aggiornare la RAM è una delle operazioni più efficaci per allungare, e di molto, la vita di un qualunque computer. 
Annunci
Tagged with: , , , , , , , , , , ,
Pubblicato su hardware

Da melabit a melabit: conclusioni

“Dopo tutto questo parlare di hosting, domini, provider e cloud, si può sapere cosa hai deciso alla fine di fare per questo blog?”

Sono consapevole di contraddire quello che avevo scritto alcuni anni fa ma, dopo aver soppesato tutte le alternative, mi sono reso conto che la cosa migliore da fare in questo momento era cambiare il meno possibile, per cui ho deciso di continuare ad usare WordPress, ospitato questa volta su una piattaforma di hosting tradizionale.

Per ora niente generatori di siti statici come Jekyll (che nonostante tutto continua a piacermi tantissimo), Grav o Hugo, niente CMS alternativi, magari più veloci ed efficienti di WordPress. Passare dalla “gabbia” dorata di WordPress.com — nella quale devo solo occuparmi di scrivere e a tutto il resto ci pensa Automattic — ad una piattaforma autogestita è già abbastanza complicato per volersi imbarcare in una transizione ancora più radicale. Qualche anno fa sarebbe stato più facile, ma in questo momento è un rischio che non voglio (e che non ho nemmeno il tempo di) correre.


Fonte: Amador Loureiro su Unsplash.

Senza dimenticare che negli ultimi tre anni ho avuto modo di sperimentare a fondo la stabilità e l’affidabilità di WordPress gestendo un sito (semi)professionale con un carico di lavoro nettamente superiore a quello prodotto da questo blog e con editor multipli, interventi sul forum, un gran numero di utenti registrati, infinite richieste di supporto tecnico nonché (potevano mancare?) innumerevoli attacchi al sito. WordPress si è comportato benissimo, perché buttare via questa esperienza sul campo?

Non nascondo di essere stato attratto a lungo dall’ipotesi “WordPress + Raspberry Pi”, mi intrigava moltissimo l’idea di gestire tutto autonomamente, ma poi ho deciso che il gioco non valeva la candela e ho lasciato perdere.

Ormai è tutto pronto o quasi. Il nome c’è, l’hosting pure, ho anche scelto un tema nuovo e più adatto (spero!) a mostrare i contenuti disponibili, manca solo il tocco finale, la pressione del classico bottone di avvio. Se non ci sono imprevisti luglio settembre dovrebbe essere il momento buono.

Ma niente è per sempre e non è detto che, dopo aver completato questa prima transizione, non decida di farne un’altra più radicale adottando Jekyll, la piattaforma che considero ancora la più vicina al mio spirito di programmatore, seppur solo part-time.

Da melabit a melabit, la serie completa degli articoli

Tagged with: , , , , ,
Pubblicato su software

Da melabit a melabit: andare sul cloud


Fonte: Daniel Falcão su Unsplash.

Il cloud computing è ovunque e ci sono decine di servizi diversi che ci permettono di usare un computer virtuale situato da qualche parte nel mondo come se fosse il computer fisico che abbiamo sulla scrivania. In questo campo i grossi calibri sono Amazon AWS, Google Cloud, Microsoft Azure, Red Hat OpenShift (in rigoroso ordine alfabetico), ma ci sono anche i servizi offerti da fornitori di servizi di hosting come SiteGround, DreamHost o Netsons oppure da provider più orientati al mondo degli sviluppatori come Digital Ocean, Codenvy, Heroku, UpCloud.

Descrivere tutto quello che fanno questi servizi è impossibile, le opzioni e le configurazioni sono tante e tanto diverse che cercare di orientarsi fra le varie possibilità fa letteralmente girare la testa (provate a districarvi nel sito di Amazon AWS e poi ditemi). Ma rimanendo a quello che ci interessa qui, tutti questi servizi mettono a disposizione un computer virtuale ospitato sull’onnipresente cloud dove possiamo installare un sistema operativo (generalmente Linux) e tutte le applicazioni necessarie per realizzare il nostro sito web.


Anche in questo caso valgono considerazioni analoghe a quelle fatte una settimana fa per il Raspberry Pi, con l’ovvia differenza che ora non dobbiamo preoccuparci degli aspetti legati all’hardware, visto che la macchina fisica e l’indirizzo IP sono forniti dal fornitore di servizi di cloud computing (in realtà la nostra macchina fisica non esiste nemmeno, il nostro computer virtuale sul cloud è solo un contenitore Docker ospitato insieme a mille altri su un server di un qualche datacenter).1 A noi rimarranno comunque alcuni oneri importanti, come ad esempio quello di aggiornare e mantenere in sicurezza il sistema operativo e i pacchetti software che utilizziamo per realizzare il sito web.

Ma oltre a non doverci preoccupare di gestire l’hardware, il vero vantaggio di ospitare il sito su un servizio di cloud computing è quello di essere liberi di utilizzare per il sito il software che preferiamo, senza i vincoli stabiliti dai normali fornitori di servizio di hosting che normalmente danno la possibilità di scegliere solo fra un certo numero di applicazioni predefinite, selezionate fra quelle più popolari.

Se per il nostro sito vogliamo usare un CMS come WordPress, Drupal, CMS Made Simple o Kirby non fa nessuna differenza, anzi un servizio di hosting tradizionale può essere preferibile perché ci permette di concentrarci sui contenuti, lasciando tutta la gestione del sito al fornitore del servizio di hosting. Ma se vogliamo utilizzare dei CMS meno diffusi come Ghost o Postleaf oppure dei generatori di siti statici come Jekyll, Hugo, Grav o Hexo,2 la soluzione cloud ci offre una flessibilità impareggiabile, nettamente maggiore di quella offerta da un normale servizio di hosting.

Tutto questo però ha un prezzo da pagare. Un servizio di hosting decente può costare anche solo qualche decina di euro all’anno, per usufruire di un computer (anche se solo virtuale) nel cloud la cifra da sborsare è nettamente maggiore, dell’ordine di almeno 20-30 euro al mese (con variazioni enormi fra le offerte dei diversi provider).

Prima di scegliere fra hosting e cloud bisognerà quindi valutare realisticamente quello che vogliamo fare con il sito web (un blog personale è ben diverso da un sito di commercio elettronico), tenendo bene in conto dell’impegno richiesto per mantenerlo in forma e delle competenze tecniche necessarie per gestire un servizio mediamente complesso come questo. Trascurare quest’ultimo punto in particolare potrebbe significare dover spendere cifre nettamente maggiori per rimediare ai problemi di configurazione, o peggio di sicurezza, che potrebbero danneggiare gravemente non solo il sito ma anche la nostra immagine. In questo campo i costi non sono solo quelli che si vedono sul cartellino del prezzo.

Da melabit a melabit, la serie completa degli articoli


  1. Il nostro unico problema sarà quello di associare l’indirizzo IP al nome di dominio (ma in genere lo stesso fornitore del nome di dominio ci mette a disposizione gli strumenti per farlo da soli). 
  2. Dei primi tre ne ho scritto parecchio anche qui, chi vuole può leggere i vecchi articoli su Grav, Hugo e Jekyll
Tagged with: , , , , , , , , , , , , , , , , , , , , , ,
Pubblicato su software

Da melabit a melabit: fare da sé?


Fonte: Glen Carrie su Unsplash.

Non avrei mai immaginato che sarebbe passato un anno intero prima di riuscire a scrivere ancora di trasferimento del blog, hosting e così via. Nel mezzo c’è stata una transizione lavorativa improvvisa e quasi inaspettata oltre che vari impegni familiari improrogabili e non sono riuscito a fare di più. Ma abbiamo già perso troppo tempo, quindi meglio venire subito al dunque.

Fare da soli

Abbiamo già visto come scegliere il servizio di hosting, cioè l’azienda (o provider) che gestisce l’infrastruttura hardware e software su cui si basa il nostro sito web e che lo rende raggiungibile attraverso la rete. Un provider ha un certo costo, che per un blog personale o un sito web di un professionista o di una piccola azienda può andare da un minimo di 20-30 euro a qualche centinaia di euro all’anno, a seconda del provider, dei servizi scelti e del livello di supporto desiderato. A fronte di questa spesa assolutamente ragionevole, utilizzare un provider permette di delegare la gestione di tutta l’infrastruttura hardware, l’aggiornamento del sistema operativo e del software su cui si basa il sito, la sicurezza, il backup e così via, a degli esperti professionisti (si spera!), lasciando a noi solo il compito di gestire i contenuti veri e propri del sito.

Ma… e se volessimo lo stesso fare da soli? Magari perché vogliamo imparare a gestire un server. Oppure perché vogliamo provare diverse soluzioni prima di decidere come realizzare definitivamente il nostro sito. Perché siamo restii a far gestire il nostro sito da un provider che domani potrebbe scomparire. Per semplice curiosità o perfino perché vogliamo riutilizzare come server web un vecchio computer lasciato a marcire in cantina.

Cominciamo dalla fine. Se sperate di poter fare quello che era così comune agli albori del web, prendere un computer ormai vecchio e poco performante e fargli gestire il vostro piccolo sito web, mi dispiace ma dovete ricredervi. Il web di oggi è molto diverso da quello di 15-20 anni fa, è infarcito di JavaScript, di contenuti dinamici, di CSS, di decine di altre tecnologie completamente sconosciute anche solo cinque o sei anni fa. Un computer vecchio, con un processore obsoleto, poca RAM, con un hard-disk lento come una lumaca, non ce la fa più a gestire in modo efficiente il web odierno, a meno di non ostinarsi a realizzare un sito vecchio (anzi, vecchissimo) stile, con le pagine scritte in HTML puro e collegate manualmente l’una all’altra. Un sito come quelli di GeoCities o giù di lì.

Raspberry Pi

Per fortuna per un sito web non serve nemmeno una workstation superpotente con processore Xeon e decine di gigabyte di RAM, è sufficiente un computer moderno anche se a basso costo.

E fra i computer a basso (o meglio, bassissimo) costo disponibili sul mercato, il più interessante è senza alcun dubbio il Raspberry Pi, il microcomputer grande poco più di un pacchetto di sigarette (si può dire ancora?) che ha prodotto una vera e propria rivoluzione fra i cosiddetti maker, che lo usano per i progetti più svariati e a volte incredibili, dai semplici sistemi domestici di videosorveglianza o intrattenimento a progetti avanzati di monitoraggio ambientale, robotica o intelligenza artificiale.

Se il Raspberry Pi va bene per queste applicazioni, a maggior ragione può essere usato per implementare un NAS, un servizio cloud personale o un server web casalingo (dove con questo termine intendo indicare in generale un blog personale o un sito di un professionista o di una piccola azienda).

Io ho provato a trasferire questo blog sul mio Raspberry Pi 3 B e ha funzionano tutto perfettamente, molto meglio di quanto mi sarei potuto aspettare. Per farlo, ho installato Raspbian (la versione di Debian GNU/Linux specifica per il Raspberry Pi) scegliendo la versione Lite senza interfaccia grafica,1 ho installato e configurato WordPress seguendo queste istruzioni stringate ma molto chiare e infine ho trasferito tutto il contenuto del blog usando il plugin di esportazione installato di default in WordPress. Più o meno due ore di lavoro, andando piano e controllando bene quello che stavo facendo.

I risultati sono andati oltre le più rosee aspettative: la velocità di accesso al blog era indistinguibile da quella garantita dall’hosting attuale su WordPress.com e anche l’utilizzo del backend, cioè del sistema di gestione di WordPress (articoli, file allegati, plugin, utenti e così via), non faceva assolutamente rimpiangere quello a cui sono abituato ormai da tanti anni.

A chi volesse provarci a sua volta e non ha già un Raspberry Pi a disposizione, consiglio di acquistare il modello più recente, il Raspberry Pi 3 B+ (costa 32 euro su Amazon, qualcosa di più su PiHut), e una scheda micro SD veloce da almeno 16-32 GB, tenendo conto che la velocità della scheda è molto più importante della capienza.

Pro e contro

Il Raspberry Pi è perfetto per imparare a gestire un server web e il sistema Linux associato oppure per fare delle prove con diversi CMS o generatori di siti statici prima di scegliere quello che vogliamo usare per il nostro sito.

Il Raspberry Pi non ha nemmeno bisogno di essere collegato ad un monitor e ad una tastiera e mouse, ma può essere gestito senza problemi da remoto tramite l’interfaccia ssh (naturalmente bisogna avere dei rudimenti di conoscenza del Terminale, cosa comunque necessaria per chiunque voglia imparare a gestire Linux e un sistema server). In più è molto piccolo, messo in un case come questo o questo fa la sua figura e può essere tenuto tranquillamente in bella vista sulla scrivania o accanto al router.

Ma anche se, come io stesso ho potuto verificare, funziona molto bene con WordPress e probabilmente anche con qualunque altro CMS o sistema statico che ci possa venire in mente di installare, usare un Raspberry Pi come sistema definitivo sul quale ospitare un server web (ma anche un NAS o un cloud casalingo) richiede di curare attentamente una serie di dettagli niente affatto trascurabili. È importante tenere presente che, anche se l’articolo è focalizzato sull’uso del Raspberry Pi, le considerazioni che seguono valgono in parte per qualunque computer che possiamo voler usare come server web.

  • Il processore del Raspberry Pi genera poco calore e non ha bisogno di un dissipatore o di una ventola. Ma il microcomputer è progettato per essere usato per qualche ora e poi spento, cosa succede se lo teniamo acceso 24 ore su 24? Ci sarà bisogno di montare un dissipatore metallico o una ventola, oppure di usare un case metallico adatto a dissipare il calore prodotto dal processore (io ho fatto così).

  • Le schede SD utilizzate dal Raspberry Pi come memoria di massa sono notoriamente fragili e poco adatte ad un uso prolungato. Ci sono soluzioni che permettono di utilizzare un disco esterno meccanico o SSD (o anche due) al posto della scheda SD, sono molto interessanti ma richiedono un minimo di manualità e di esperienza per installare e configurare il tutto.

  • Alimentare un server con un alimentatore da parete e il suo fragile connettorino microUSB ha un livello di affidabilità decisamente scarso. Se poi aggiungiamo un disco esterno, è facile che la potenza fornita dall’alimentatore USB diventi insufficiente. Molto meglio usare un alimentatore ad hoc, magari insieme ad un case adatto ad ospitare tutti i componenti come questo (si veda anche la figura qui sotto). Purtroppo, mettere insieme una cosa del genere richiede un livello di manualità e di esperienza ancora più elevato.


Fonte: The Stuff We Build, Raspberry Pi Web Server.

  • Sempre in tema di alimentazione elettrica, per usare il Raspberry Pi come server è indispensabile aggiungere una batteria tampone, adatta a tenere il Raspberry Pi alimentato anche in assenza di corrente elettrica, meglio se associata ad un piccolo UPS per il router (se va via la corrente di casa e il router si spegne, tenere alimentato il Raspberry Pi non serve comunque). Il solo UPS può anche andare bene per alimentare i due dispositivi, bisogna solo controllare che abbia una potenza sufficiente ad alimentare il router ed il Raspberry Pi per diverse ore.

  • Un server web ha bisogno di un nome di dominio e di un indirizzo IP associato. Per il nome di dominio c’è poco da fare, va richiesto necessariamente ad una azienda intermediaria (registrar) come Register.it, GoDaddy, Cloudflare, Google Domains e costa circa 10-15 euro all’anno (spesso molto meno il primo anno). Al nome di dominio bisogna associare l’indirizzo IP del nostro sito, che in genere è gestito direttamente dal provider del servizio di hosting. Se vogliamo fare da soli dobbiamo riuscire ad ottenere in qualche modo un indirizzo IP personale. Purtroppo i normali provider telefonici che usiamo per accedere ad internet da casa o dall’ufficio, Wind/Infostrada, Vodafone o simili, ci assegnano degli IP dinamici, che possono cambiare nel tempo, mentre a noi serve un IP statico, da associare una volta per tutte al nome di dominio. Scordatevi i servizi di DNS dinamico come DynDNS, OpenDNS o NoIP e simili, questi possono andar bene per accedere di tanto in tanto alla videosorveglianza o ai dispositivi IoT di casa, non certo per un server web. L’unico provider che conosca che fornisce facilmente un IP statico ai clienti è Fastweb, basta chiederlo ed è anche gratuito.

  • Da non dimenticare la questione dell’aggiornamento e della messa in sicurezza del sistema operativo e dei pacchetti software che utilizziamo per realizzare il sito web. Linux è intrinsecamente un sistema operativo sicuro, ma ciò non toglie che bisogna preoccuparsi di aggiornarlo frequentemente, nonché di aggiornare tutti i pacchetti software di contorno, in particolare quelli utilizzati per il sito web, in modo da evitare non solo che il sito finisca sotto il controllo di qualche script kiddie che non ha di meglio da fare, ma soprattutto che il nostro microcomputer diventi una base di partenza per i malintenzionati della rete per effettuare attacchi mirati a più vasta scala.

Conclusioni

Come è facile notare le mie perplessità sull’uso del Raspberry Pi come server web casalingo (così come di qualunque altro computer usato per questo scopo) sono soprattutto di natura hardware, e in fondo riflettono il fatto che questo microcomputer nasce come sistema sperimentale o di sviluppo, non come sistema affidabile da tenere in funzione 24 ore su 24.

Anche dal punto di vista puramente economico non mi sembra una grande idea: fra Raspberry Pi, UPS, case e accessori vari si rischia di superare facilmente il costo di un servizio di hosting pluriennale, con in più i tanti grattacapi descritti.

Il Raspberry Pi invece è imbattibile come sistema didattico ed è di sicuro uno dei migliori acquisti che si possano fare in questo momento, una specie di ritorno ai tempi eroici degli anni ’80 quando chi comprava un computer come il Commodore 64, lo Spectrum o, per i più fortunati, l’Apple II doveva rimboccarsi le maniche e imparare i rudimenti della programmazione e magari anche dell’elettronica per usarlo al meglio. È una vera fortuna che quei tempi siano tornati, oggi.

Da melabit a melabit, la serie completa degli articoli


  1. La versione ideale per un server web al quale, dopo la configurazione iniziale, si accede quasi esclusivamente tramite l’interfaccia web. 
Tagged with: , , , , , , ,
Pubblicato su software

Wow!

È raro che commenti a caldo un keynote Apple (anche perché non riesco quasi mai a vederli), ma quest’anno a Cupertino si sono superati e il keynote è stato un susseguirsi di annunci scoppiettanti, fino al gran finale dedicato agli sviluppatori.

Cominciamo dal Mac Pro, di sicuro l’annuncio più atteso. Una macchina fantastica, un ritorno al passato, anzi una vera e propria inversione ad U. I progettisti hardware di Apple si saranno cosparsi il capo di tonnellate di cenere prima di mettersi al lavoro. Perché una macchina professionale da 6.000 (e molti più!) dollari deve fare i conti con il resto del mondo supportando gli standard industriali correnti, e deve essere espandibile e modificabile anche in modo estremo, per poter durare il più possibile e diluire nel tempo il pesantissimo investimento economico necessario per venirne in possesso.

E poi c’è iPadOS che, da quanto si è visto, potrà dare finalmente all’iPad il sistema operativo che merita, con un vero multitasking, un copia e incolla efficace, un filesystem degno di questo nome, capace di vedere anche i dischi del Mac. Senza dimenticare, quanti anni ci sono voluti?, il supporto per le chiavette e i dischi esterni USB.

Per quanto riguarda macOS, iTunes sarà spacchettato in tre applicazioni coerenti dedicate alla musica, ai video e ai podcast, mentre mi pare di aver capito (ho avuto un momento di distrazione) che i dispositivi iOS saranno gestiti direttamente dal Finder.

Ci sono stati annunci apparentemente minori, ma che testimoniano l’attenzione di Apple per la sicurezza e l’accessibilità. Ricordo su tutti la nuova “Sign in with Apple”, che permetterà di accedere a tanti siti web in modo molto più sicuro che usando Google o Facebook (una cosa, quest’ultima, da evitare il più possibile). Geniale l’idea d farlo tramite degli indirizzi email generati in modo casuale e diversi per ciascun sito. I wow di cui era costellato il keynote qui sono stati pienamente meritati.

E poi Mappe finalmente rivisto, la funzione “Find My” che funziona anche a MacBook spento sfruttando una modalità Bluetooth a basso consumo che comunica anonimamente la posizione ai dispostivi iOS nelle vicinanze (anche qui il wow era più che meritato), l’iPad utilizzabile come secondo schermo del Mac, la tastiera iOS a scorrimento (ci voleva tanto?).

Ma il gran finale è stato dedicato a Swift e XCode, in perfetta sintonia con lo spirito di una conferenza dedicata agli sviluppatori. Swift acquista lo status di linguaggio primario di sviluppo per tutte le piattaforme Apple, con un nuovo framework grafico, Swift UI, che sembra quasi scrivere il codice da sé (non sarà di sicuro facile come sembra, ma è comunque un bel passo avanti).

L’integrazione fra l’ambiente di sviluppo e i dispositivi fisici su cui testare le app in corso di sviluppo è stata migliorata al punto tale che le modifiche al codice si trasferiscono in modo pressoché istantaneo al dispositivo iOS collegato, semplificando e velocizzando notevolmente il debug dell’applicazione.

Infine, XCode permetterà di generare, partendo dalla stessa base di codice, applicazioni che girano su tutte le piattaforme Apple, anche se non è chiaro se XCode produrrà un’unica applicazione universale (come ai tempi della transizione da PowerPC a Intel), compatibile con processori ARM e Intel e con iOS, iPadOS e macOS, oppure applicazioni specifiche per le diverse piattaforme.

Di transizione dei Mac da Intel a ARM, almeno per quest’anno, non si è parlato.

Tagged with: , , , , , , , ,
Pubblicato su hardware
Informativa
Questo sito utilizza cookie di terze parti per inviarti pubblicità e servizi in linea con le tue preferenze. Se vuoi saperne di più o negare il consenso a tutti o ad alcuni cookie, clicca qui. Scorrendo questa pagina, cliccando su un link o su qualunque altro elemento o proseguendo la navigazione in altra maniera, acconsenti all'uso dei cookie.
Follow Melabit on WordPress.com
Categorie
%d blogger hanno fatto clic su Mi Piace per questo: