Frammenti di storia del Newton (4)

Mele e appunti

Eccoci giunti alla quarta e ultima parte di questo — mi auguro interessante — excursus su alcuni aspetti poco noti della storia del Newton. La premessa che ha portato a questo lavoro in quattro parti è descritta nel primo post. Ho naturalmente qualche osservazione da fare in conclusione, ma dato che sto ancora organizzando le idee, e per non allungare troppo questo post, ho deciso di scrivere un articolo distinto, che spero di poter pubblicare già domani o lunedì.

I MessagePad 120 e 130

Autore: Ex Newton OS Engineer
Data: 05/04/99

I MessagePad 120 con il sistema in lingua tedesca, che sono stati prodotti in minor quantità, hanno in realtà la ROM del MessagePad 130 al loro interno, e la ROM rileva automaticamente le piccole differenze fra le due unità. Gli aggiornamenti di sistema del Newton sono sviluppati in modo da essere specifici per ogni tipo di ROM, e non per ogni tipo di modello (per esempio, i MessagePad 2000 e 2100 hanno la stessa identica ROM), e alcune delle patch nel MP2100 effettuano un rilevamento della dimensione della RAM, poiché è l’unica cosa che differenzia quei due modelli. Un MessagePad 130 è praticamente uguale a un MessagePad 120, le uniche differenze sono un maggior quantitativo di memoria e la retroilluminazione, tuttavia un MP120 non è aggiornabile per trasformarlo in un 130, dato che una piccola revisione alla scheda logica principale del MP120 portò alla creazione del MP130 affinché fosse possibile gestire i chip della memoria aggiuntiva. […]

Applicare patch al Newton OS

D: Sarebbe possibile effettuare questo tipo di sviluppo con un MessagePad 2100 con le impostazioni di fabbrica e un Mac?

R: Beh, sì, la maggior parte dello sviluppo del MP2000 è stato svolto utilizzando prototipi di MP2000 invece dei cosiddetti “prototipi Bun warmer”. Apple smise di costruire i Bun warmer dopo la produzione del MessagePad 120 perché costavano troppo (3.000 dollari l’uno). Sulla scheda figlia della ROM i prototipi del MP2000 avevano la tecnologia Flash invece della ROM mascherata, e il MP2000 può a tutti gli effetti programmare ‘flashando’ la ROM incorporata attraverso la GeoPort (a 1 Mbit al secondo). Questo è stato fatto servendosi della versione più recente del debugger interno Hammer, oppure con uno strumento chiamato NewtFlasher (se non ricordo male); alcuni sviluppatori ricevettero tali strumenti sotto un accordo di non divulgazione. Flashare la ROM non è un procedimento semplice né infallibile, però, perché parte della ROM deve poter funzionare per essere in grado di interagire con il debugger e caricare l’immagine nuova e programmarla senza danneggiarsi. Durante lo sviluppo era importante collaudare sempre la ROM prima di flasharla in un palmare, perché se la nuova ROM fosse stata davvero corrotta, la successiva avrebbe potuto non essere mai installabile, e ciò comportava lo smontaggio dell’unità e il flashare la scheda figlia della ROM esternamente.

Pertanto lo sviluppo fu effettuato utilizzando un dispositivo palmare per flashare la ROM e un PowerMac con MPW, NTK e un build system che girava sotto MPW. Io ho sviluppato, mantenuto e gestito il Build Server system nel Newton Group; era chiamato Autoserver e tutto il software della ROM fu realizzato con 27 Quadra 950 e alcuni prototipi “Bun warmer” che collaudavano le immagini ROM prima di permettere l’accettazione di modifiche ingegneristiche all’interno della base del progetto sorgente e di distribuire le modifiche ad altri ingegneri del team.

D: Di che cosa avrei bisogno per trasformare il mio codice in una patch del sistema operativo applicabile da altri?

R: Non so come tu abbia portato avanti lo sviluppo, ma immagino tu abbia impiegato i Newton C++ Tools per Macintosh. Oppure hai soltanto un algoritmo sperimentale che gira su un desktop? O hai usato NTK? Ti suggerisco di creare un’applicazione completa e distinta e di lasciar perdere la creazione di una ‘patch’ del Newton OS.

Un Newton System Update o ‘patch di sistema’ è un insieme complesso e mescolato di tabelle MMU, 40–70 ‘fix’ in assembler tutti riuniti in una serie ordinata di pagine RAM da 4 KB. Costruire e collaudare un System Update è un processo complesso e costoso e non è fattibile da un solo ingegnere. Il Newton OS supporta soltanto una patch di sistema, pertanto tutti i fix già prodotti e gli eventuali fix nuovi devono essere combinati e riuniti per creare il System Update successivo. Il Newton OS è molto insolito sotto questo aspetto: è come se il Mac OS supportasse e permettesse solamente una estensione invece di un’intera cartella di estensioni.

Non è possibile fare questo ‘come una patch di sistema’; Apple è l’unica ad avere gli strumenti per costruire un nuovo System Update e tutti gli ingegneri che sanno come eseguire il lavoro non lavorano più in Apple (come me), anche se forse c’è ancora un dipendente che potrebbe realizzare un tale aggiornamento se avesse tempo sufficiente.

Una nuova GC in NewtonScript [GC sta per Garbage Collection] difficilmente si potrebbe completare e collaudare senza i sorgenti ROM. Le prestazioni di moltissimi elementi nel sistema operativo cambiano se la GC è compromessa, e non si ha idea di quanto il sistema possa essere sensibile alle modifiche. ‘Velocizzare’ la GC probabilmente avrebbe effetti secondari negativi imprevedibili e potrebbe compromettere a sua volta tutta una serie di cose. Far sì che la GC venga effettuata nel momento sbagliato potrebbe avere lo stesso tipo di conseguenze nefaste per il Newton OS. Se si è in grado di ingegnerizzare una nuova GC per il Newton OS senza documentazione e senza i sorgenti, il mio consiglio è di farsi assumere come programmatori da qualcuno che pagherà molto bene un lavoro del genere.

E un nuovo OS per il Newton?

Autore: Ex Newton OS Engineer
Data: 07/04/99

Beh, tecnicamente è possibile scrivere un nuovo sistema operativo per l’hardware dei MP2000/MP2100, ma dato che essenzialmente l’intero design hardware non è di pubblico dominio, dubito che questo possa accadere senza una richiesta ad Apple di pubblicare la documentazione.

Inoltre è necessario avere compilatori, linker e assembler ARM, e un sistema di sviluppo in cui farli girare. Ho l’impressione che una versione Linux dei Tools di ARM Ltd sia l’unico approccio pratico.

Il chipset Cirrus Logic è di fatto il MP2000/MP2100. Fu un insieme di chip mal progettato: i cicli di RAM impiegano 7 ‘tick’ del clock del bus! E il processore gira sette volte più veloce rispetto al bus. Solo che, se non ricordo male, quei chip non sono disponibili a livello commerciale.

Decisamente ad hoc

D: Quanta parte dell’hardware dei MessagePad è proprietaria e adattata, senza documentazione al di fuori di Apple?

R: Essenzialmente il 95%. Il chipset Cirrus (4 chip) è praticamente tutto l’hardware tranne la CPU, la ROM, la tecnologia Flash, la RAM, l’I/O audio, i driver della porta seriale e infrarossi, e l’alimentazione.

E naturalmente è il 95% più importante.

Sicuramente qualcuno avrà già smontato un MP2x00 e avrà fotografato le schede logiche principali (da entrambi i lati). È un’operazione semplice da fare ed è il sistema migliore per analizzare l’architettura hardware.

Non basta avere un ‘kernel’ per avere un sistema operativo. Senza driver, un toolbox, un application runtime model, un’interfaccia utente, un ‘Finder’ o una simile applicazione per lanciare i programmi, non si ha in mano niente di utile.

Frammenti di storia del Newton (3)

Mele e appunti

Continua questa piccola parentesi a puntate sulla storia del Newton. Avevo pensato a tre parti, ma il materiale è maggiore di quanto pensassi e c’è molta carne al fuoco, pertanto vi sarà anche una quarta parte che spero di pubblicare domani. Per contestualizzare il testo che sto traducendo e presentando qui, è essenziale leggere la prima parte. Le mie osservazioni e integrazioni all’interno del testo citato sono in corsivo fra parentesi quadre.

Autore: Ex Newton OS Engineer
Data: 05/04/99

Espansioni difficili

6. Sono l’autore dei Newton C++ Tools per Macintosh, e dato che il compilatore ARM C++, l’assembler e il linker che avevamo a disposizione erano tutti strumenti MPW, e che non esiste un ambiente ‘standard’ per tool sui sistemi Windows a cui questi tool potevano agganciarsi, non fu mai realizzata una versione Windows dei Newton C++ Tools. Fu discussa, perché alcuni sviluppatori ne fecero richiesta, ma niente più. Mi pare che alcuni dei DDK [Driver Developer Kit o Device Developer Kit] fossero disponibili fino a marzo del 1998 sotto NDA [accordo di non divulgazione], ma si basavano ugualmente su MPW. Probabilmente avremmo potuto intraprendere un porting verso Linux di tutto questo materiale e sarebbe stato un percorso migliore, ma non fu vista come ipotesi fattibile dall’amministrazione o dai tizi del marketing, che cercavano sempre di creare ‘prodotti’ da vendere, non software gratis.

7. Non venne mai creato un modem interno. Sì, esiste un connettore interno che potrebbe essere portato fuori come seconda porta seriale con soltanto il chip driver RS 422 I/O, ma i controlli necessari per la redirezione e la loro verifica per tutti gli usi desiderabili dall’utente non furono mai implementati nel sistema operativo, né sottoposti a debugging. Non è sufficiente avere soltanto l’hardware. Per servire a qualcosa, i prodotti per sistemi informatici devono avere tutti i layer al loro posto; l’hardware è il livello più semplice da ‘vedere’ e comprendere. Il che spiega perché alcuni — che non sono ingegneri di sistema — pensano “ah, ma è facile, basta aggiungere una scheda logica, un chip per il driver e il connettore e funzionerà”. Tempo fa su questo forum qualcuno disse che avrebbe realizzato una scheda per l’adattatore, e ricordo di aver letto molti messaggi riguardanti foto e hack che alcuni nerd erano riusciti a far funzionare, per poi scoprire la mancanza del supporto software. 

Per chi non lo sapesse, è stata poi creata una scheda per aggiungere una porta seriale del tutto identica a quella in uso sui Mac beige, ossia RS 422. Nella comunità Newton questa scheda è nota come SER-001. È possibile vedere la scheda installata in un MessagePad 2x00 in questa foto (trovate altre foto interessanti esplorando l’intero set). La controversia a cui si riferisce la didascalia della foto riguarda il progetto e la creazione di questa scheda. Le versioni dei fatti sono sostanzialmente due: a) il prototipo fu creato da ‘PCBMan’ e venne poi copiato e commercializzato da ‘Knowledge Navigator’ (sono ovviamente due nickname); b) ‘PCBMan’ e ‘Knowledge Navigator’ hanno sviluppato indipendentemente la stessa idea e hanno prodotto ognuno la propria versione della scheda; la grande somiglianza fra le due schede sarebbe dovuta a ragioni intrinseche all’hardware del Newton.

Io ho la fortuna di aver ricevuto un Newton MessagePad 2100 con la SER-001 già installata, e funziona egregiamente. Dico ‘fortuna’ per due motivi. Primo: questa scheda non viene prodotta industrialmente e ormai non ce ne sono molte in circolazione; in più non è facile installarla da soli. Secondo: la grande comodità di avere la SER-001 incorporata è l’eliminazione del famigerato ‘dongle’ per effettuare connessioni con il Mac via cavo seriale. Il dongle non è altro che un adattatore che da un lato si inserisce nella porta Interconnect del Newton (se osservate di nuovo la foto del link precedente, la porta Interconnect è quella piatta, quasi simile a una USB, accanto alla porta seriale della SER-001) e dall’altro offre una porta seriale RS 422. Il dongle è indispensabile per collegare il Newton al Mac via seriale, ed essendo un oggetto abbastanza piccolo, è anche facile perderlo. Una scheda SER-001 installata elimina la necessità del dongle e ogni preoccupazione.

Emulare il Newton OS

8. [Probabilmente il nostro Ex Newton OS Engineer risponde a qualcuno che gli aveva chiesto se potesse creare un emulatore del Newton]. Potrei, ma sono un ingegnere software e faccio questo per mestiere, non per hobby. […] Un emulatore Newton deve emulare non soltanto il processore ARM, ma tutte le funzioni specializzate della MMU [Memory Management Unit] dell’ARM e l’hardware adattato per DMA, IR, schede Flash, schermo, eccetera eccetera. Non è un lavoro facile. La mia stima (e ho un’esperienza trentennale in ingegneria di software e sistemi) è che si tratti di un’impresa di cinque anni-uomo. Tentare una simile avventura senza una documentazione dettagliata dell’hardware di un MessagePad 2000 porterebbe quasi certamente al fallimento.

Mi sembra comunque un’impresa inutile, perché troppe parti del Newton OS erano molto specifiche e legate alle funzioni della CPU e MMU del processore ARM, nonché all’hardware modificato e adattato allo scopo. Apple cercò più di una volta di realizzare un ‘Newton Virtuale’ come progetto secondario all’interno del Newton Group, ma tale progetto non venne mai finanziato né portato avanti davvero. L’ultimo hack fu opera di Greg Christie, che riuscì a far funzionare sotto Mac OS l’Interprete NewtonScript, ma tralasciando tutto l’hardware di basso livello come il supporto per la rete e per l’I/O seriale, per cui il risultato assomigliava più a un NewtonScript/Mac OS che a un Newton OS.

A mio avviso sarebbe stato più interessante implementare un nuovo sistema operativo ‘libero’ per palmari utilizzando il modello di Java/JWT, dato che molti dei vantaggi di NewtonScript/Newton OS sono presenti in Java. Ritengo inoltre che sia relativamente semplice ‘clonare’ il design dell’interfaccia utente del Newton, ovvero creando un ‘Finder’ palmare e un gruppo di librerie di classe per eguagliare gli aspetti migliori del Newton toolbox. Direi che utilizzando Java e un JWT specializzato per piattaforma palmare avrebbe più possibilità di successo e attirerebbe un tipo di collaborazione più in stile GNU, che non il preservare un sistema operativo proprietario abbandonato. 

Paul Guyot, in circa quattro anni di lavoro (2004–2007), ha messo a punto Einstein, un emulatore del Newton OS che gira su altre piattaforme, fra cui Mac OS X (PPC e x86), Windows, Linux. Prima il software era scaricabile dal suo sito, ora è stato pubblicato su Google Code, a questo indirizzo. A meno che non sia cambiato qualcosa nel frattempo, per poter utilizzare Einstein occorre possedere un Newton e fare il dump della ROM originale. Il processo è abbastanza lungo se fatto via seriale (io provai tempo fa, ma dopo aver lasciato il Newton collegato via seriale al mio iBook per sei ore decisi di abbandonare, credendo che l’applicazione per effettuare la copia della ROM fosse andata in crash. Fu Guyot stesso a dirmi che in realtà il processo poteva durare parecchie ore).

Einstein non è completo, e determinate funzioni del Newton non sono ancora supportate. Riporto dalla sezione Problemi conosciuti del manuale di Einstein:

  • Le porte seriali non sono emulate.
  • Le schede PCMCIA non sono emulate.
  • Il volume appare regolabile via software ma i cambiamenti vengono ignorati (tranne quando il suono è spento sul Newton).
  • L’input audio non è emulato.
  • Il tentativo di installare patch di sistema provoca un errore.
  • I tasti non vengono tradotti in maniera appropriata a eccezione che sul Mac (la tastiera è inutile).
  • La rotazione [dello schermo] non sempre funziona correttamente.
  • Su altri PDA con processore ARM, Einstein è mostruosamente lento.
  •  

    Ho visto Einstein in azione su un PowerBook G4 e, malgrado i problemi elencati, è un’esperienza affascinante e il lavoro di Guyot è stato incredibile. Al momento il progetto Einstein sembra dormiente, ma altri sviluppatori sono coinvolti e speriamo si muova qualcosa in futuro.

    Frammenti di storia del Newton (2)

    Mele e appunti

    Ecco la seconda parte di questo piccolo viaggio dietro le quinte della storia del Newton. Per contestualizzare il testo che sto traducendo e presentando qui, è essenziale leggere la prima parte. Le mie osservazioni e integrazioni sono in corsivo fra parentesi quadre.

    Un bug misterioso

    2. [In risposta a una domanda su un qualche strano bug del Newton]. Qualche tentativo per risolvere il problema venne fatto, ma i ‘veri’ ingegneri che si occuparono del kernel avevano già lasciato Newton/Apple quando il bug iniziò a manifestarsi, e il personale rimasto (me compreso) non era abbastanza motivato e/o non era in grado di isolarlo. Dagli ultimi lavori compiuti in questa direzione, pare che il bug fosse molto difficile da riprodurre e che il problema fosse nel modulo Flash “demand pager” nel kernel a basso livello. Apparentemente, una combinazione molto complessa di azioni, insieme a un’intensa attività di paging, alla fine provocava un errore di paging che mandava in crisi il sistema operativo.

    La causa precisa non fu mai isolata, pertanto non si sa se fosse possibile applicare una patch. La tabella di patch nella ROM contiene la maggior parte delle routine nel codice nativo ROM, ma vi sono parecchie funzioni interne al kernel a cui non è possibile applicare patch a causa della riduzione prestazionale che impatta una funzione solo per essere compresa nella tabella di patch. È molto probabile che il bug non fosse riparabile, ma senza conoscere l’esatta natura del bug non si può affermare nulla di certo.

    Un codice prezioso e variegato

    3. Oltre a essere il ‘Newton Patch Master’, il mio lavoro primario nel Newton group era occuparmi del Build System e dei Build Tools. La ROM del Newton è in gran parte C++, con parti in Assembler e molto NewtonScript. La ROM veniva costruita soltanto utilizzando un compilatore ARM e un linker modificati (provenienti dall’azienda ARM in Inghilterra), e una serie di strumenti MPW specializzati scritti da Apple, e il tutto girava sotto MPW [Macintosh Programmer’s Workshop]. Questo era il solo ambiente di costruzione per i 6 e passa MB della ROM ‘di base’. La ‘ROM extension’ contiene un insieme di pacchetti NewtonScript, altre tabelle, ecc., ed è stata realizzata con NTK [Newton Toolkit] e altri strumenti MPW specializzati.

    La ROM contiene inoltre del codice sorgente in licenza da altri produttori software: Paragraph International per il motore di riconoscimento della scrittura corsiva, i dizionari dei termini e del correttore ortografico; ARM Ltd per le librerie Std C. Apple non potrebbe di certo rilasciare il codice sorgente avuto in licenza. In più, la ROM contiene parte del codice Apple più prezioso, una porzione modificata di QuickDraw (dell’epoca del Mac SE) e tutto il Printing support for QuickDraw e per la stampa PostScript. Apple sviluppò anche il ‘Printing Recognition Engine’ [il motore per il riconoscimento della scrittura non corsiva, a lettere separate], è scritto in C/C++ ed è ‘Newton-dipendente’. Fu sviluppato sotto UNIX e i risultati di calcoli automatizzati piuttosto lunghi hanno prodotto la rete neurale che il Newton utilizza per effettuare il riconoscimento [e la conversione] del testo.

    Era opinione di Jobs che questo codice fosse troppo prezioso perfino per Newton Inc., figuriamoci al di fuori di Apple. Open Source? Neanche per sogno. E poi il codice base della ROM non è ben distribuito su livelli, molte ampie porzioni sono troppo ‘incestuose’, quindi non è affatto qualcosa sulle cui porzioni un gruppo qualsiasi di ingegneri potrebbe lavorarci in maniera indipendente. Anche con un team riunito in un solo luogo non era infrequente avere problemi causati da interazioni inattese ed errori dovuti alla mancanza di una buona distribuzione del codice su livelli e di un buon isolamento nel sistema operativo e nelle applicazioni incorporate. Nel 1997 fu iniziato un progetto all’interno del Newton group per la realizzazione di un OS ‘modulare’. Lo scopo era riscrivere gran parte della ROM così da renderla mantenibile anche in futuro, ma molto di quel lavoro non fu mai portato a termine.

    4. Sì, anche IntelliSync [software di sincronizzazione prodotto da IntelliLink] era in licenza, e a mio parere fu uno degli errori più grandi commessi da Apple, ossia quello di non sviluppare un proprio software per tali compiti. […]

    Dubito che il produttore [si riferisce ancora a IntelliLink, suppongo] intenda rendere disponibili le interfacce e non sono sicuro che NCU sia sufficientemente modulare da accettare nuovi plug-in; non credo lo sia.

    Priorità di risorse

    [Probabilmente il nostro Ex Newton OS Engineer risponde a domande sul perché, per il Newton MessagePad, furono scelte determinate tecnologie e porte a scapito di altre. Purtroppo nel testo che ho a disposizione mancano le domande precise, vi sono soltanto le risposte dell’ingegnere.]

    5. La tecnologia IR (infrarossi) del Newton era anteriore a IrDA e IR non si rivelò essere una funzione molto utile, perché averla costantemente attiva significa un consumo energetico eccessivo. Essenzialmente, per avere un’interfaccia IR funzionante, il software dev’essere sempre in ascolto per ricevere input IR e questo, insieme all’output IR, consuma energia. Inoltre, un IR full duplex è una brutta bestia da implementare, e avere più fonti di input IR allo stesso tempo è problematico, perché distorce l’input. Di conseguenza, la maggior parte delle implementazioni IR sono half dulplex e il processo di scambio dati è lento e costoso quando si ha a che fare con un gran numero di piccoli frammenti di informazioni. […]

    Per quanto riguarda Ethernet, è un livello di trasporto e un protocollo che non ha nulla a che vedere con Windows; il MessagePad 2000/2100 ha il supporto per il TCP/IP, che è il protocollo più comune e si serve di hardware Ethernet per le reti. Il problema legato al ‘Network’ su un PDA e nei Newton MessagePad, è che il Newton non è stato progettato per connettersi a una WAN o a una LAN, e tali reti richiedono un’attenzione costante a livello hardware, che deve mettersi in ascolto per captare tutti i pacchetti che transitano nella rete. Il Newton OS non fu progettato per fare questo, e aggiungere tale funzione in un secondo momento fu un hack. E a mio parere un altro grosso errore commesso da Apple con l’intera linea di prodotti Newton fu il tentativo di rendere i MessagePad dei ‘dispositivi per Internet’. Invece di realizzare un MessagePad 2000 più grande, più ingombrante, più costoso e ‘adatto a Internet’, Newton Inc. avrebbe dovuto costruire un dispositivo più sottile, più piccolo, e meno capace. Ma Palm Computing ebbe una visione migliore del prodotto e realizzò un PDA di maggior successo.

    Frammenti di storia del Newton (1)

    Mele e appunti

    In questo periodo, nella lista di discussione NewtonTalk l’argomento maggiormente in primo piano è il famigerato ‘Bug del 2010’. Ne parlerò in dettaglio in un prossimo articolo, per intanto basti sapere che dal primo gennaio dell’anno prossimo i nostri beneamati Newton ed eMate potrebbero smettere di funzionare correttamente se nel frattempo non viene risolto questo inconveniente.

    In uno dei thread sull’argomento, un altro membro di NewtonTalk ha pubblicato una serie di osservazioni scritte nel 1999 da un ex dipendente Apple che aveva lavorato alcuni anni anche allo sviluppo del Newton. Una serie di informazioni e dettagli ad ampio raggio, a tratti ufficiosi, sulla storia del Newton. Non ero a conoscenza di certi particolari, pertanto ho rintracciato questa persona e le ho chiesto il permesso di tradurre in italiano quel materiale e pubblicarlo in questa sede. Ho ricevuto una risposta assai celermente, e l’ingegnere è stato molto gentile e mi ha dato autorizzazione a procedere, a patto di conservare un certo livello di anonimato. (Mi ha scritto: Jobs è noto per le sue reazioni un po’ eccessive; dubito che ci sia qualcuno in Apple che possa avere problemi [con queste informazioni], ma è giusto per stare tranquilli). Un po’ mi dispiace: questa persona ha lavorato in Apple per più di 14 anni ed è uno della vecchia guardia. La breve corrispondenza con lui è stata un onore, tuttavia rispetterò il suo volere, e il nome che verrà usato per identificarlo — Ex Newton OS Engineer — è lo stesso che utilizzò lui nel 1999 quando scrisse le osservazioni di cui riporto gli stralci più significativi.

    Data la lunghezza, dividerò il lavoro in almeno due parti, forse tre. Trovo che sia materiale interessante, che proviene da una fonte affidabile, e che possa servire a inquadrare la storia del Newton con maggior dettaglio.

    Introduzione

    Oggetto: Qualche notizia recente di cause legali Newton vs Apple?
    Autore: Ex Newton OS Engineer
    Data: 01/04/99

    […] Ora sono anche un ex dipendente Apple, oltre che ex dipendente Newton [si riferisce alla sussidiaria Newton, Inc. creata da Apple nel 1997 per seguire separatamente lo sviluppo della piattaforma Newton, e poi riassorbita poco dopo a seguito della cancellazione del Newton], per cui se qualcuno ha domande legate alla ‘storia del Newton’, approfitti di questo thread.

    Per intenderci, io sono stato il dipendente Apple N. xx [omesso come da richiesta dell’autore] e ho lavorato nel Newton group dal febbraio 1995 all’agosto del 1998; fui l’ultimo ingegnere software a resistere nel Newton group poiché ero il ‘maestro delle patch’ per il Newton OS, e mi hanno tenuto a disposizione in caso fossero necessarie ulteriori patch.
    Sono anche l’autore dei Newton C++ Tools per Macintosh e ingegnere dei build tools e del sistema di build ROM del Newton. […]

    Ricerca e sviluppo

    Autore: Ex Newton OS Engineer
    Data: 05/04/99

    […]
    1. In tutto il (lungo) arco dello sviluppo del Newton, Apple ha investito 400 milioni di dollari in eccesso per la Ricerca & Sviluppo (la stima è mia). I primi anni (1988–1991) furono quasi totalmente dedicati alla ricerca pura sulle tecnologie, al riconoscimento della scrittura, all’impiego di CPU a basso consumo, alla creazione di prototipi, all’interfaccia utente ottimizzata per l’uso con una penna, a grandi progetti per la realizzazione di una famiglia di prodotti a grande formato (‘Slate’)… L’idea del Newton è partita come tentativo di concretizzare il ‘Knowledge Navigator’ di Sculley. Era un progetto di ‘tecnologia ingegneristica fine a se stessa’ in pieno stile Apple, senza preoccuparsi troppo di ciò che avrebbero voluto i clienti e quanto fossero disposti a pagare per un determinato livello di funzionalità.

    Alla fine, il prototipo dello Slate, a un prezzo di 4.000–5.000 dollari, non era ovviamente molto vendibile […] e avvenne un ‘colpo di palazzo’: un gruppo di ingegneri Newton si riunì per ‘restringere’ il prodotto a un form factor palmare — per questo il nome in codice del risultato fu ‘Runt’ [Dal dizionario Garzanti: 1. Animale o pianta inferiore al normale; l’animale più piccolo di una figliata. 2. (fam. spreg.) persona troppo piccola, mezza cartuccia].

    Tutto questo portò a un lancio prematuro del primo MessagePad, dovuto alle paure dell’Amministrazione che Microsoft stesse per lanciare un ‘PenPad OS’, e che avrebbe quindi precluso il momento propizio per l’introduzione del Newton.

    Il resto è la storia, in gran parte nota a tutti, di un prodotto che è costato troppo per quel che era in grado di fare e che non è mai stato sufficientemente piccolo per essere un palmare vero e proprio. Relativamente alla cifra totale che Apple ha investito nell’intero ciclo di sviluppo del Newton, Apple non ha mai recuperato il primo dollaro di profitto sui 400 milioni di dollari spesi in Ricerca & Sviluppo.

    Durante gli ultimi due anni di esistenza del Newton, le spese di Ricerca & Sviluppo per il sovrabbondante Newton group, composto da 175 persone circa, bruciavano più o meno 27,3 milioni di dollari l’anno; questo derivava dal costo ‘standard’ di 156.000 dollari a persona, composto da salario, indennità, attrezzature, locali di lavoro, forniture e spese di gestione. Apple NON stava vendendo un numero sufficiente di MessagePad, accessori, ecc. per coprire i costi, a eccezione di un paio di trimestri durante il periodo in cui stavo lavorando nel Newton group (1995–1998).

    Fra parentesi, non è il ‘fatturato’, il ricavo delle vendite, che deve coprire i costi di Ricerca & Sviluppo di un’azienda, ma almeno il cosidetto ‘pre-tax profit’, l’utile lordo. Il ‘costo delle merci’ vendute deve essere sottratto dal fatturato, e il fatturato è il prezzo ‘all’ingrosso’ che Apple ottiene dai prodotti venduti ai distributori o direttamente ai ‘grossi’ dettaglianti. Solitamente l’utile lordo di Apple si aggirava intorno ai 150–200 dollari per unità; ciò era dovuto al fatto che le unità venivano costruite da Sharp o da altri costruttori asiatici, e quindi Apple doveva pagare al costruttore una certa cifra. In genere un distributore ottiene il 5–10% del prezzo al dettaglio e il dettagliante ricava il 15–25%, per cui nel migliore dei casi Apple tende a ottenere il 75% del prezzo al dettaglio e per un MessagePad 2000 doveva pagare circa 400 dollari a Sharp per ogni unità.

    La spiegazione che Jobs diede per giustificare il riassorbimento di Newton, Inc. fu che Apple non voleva perdere una serie di importantissime figure di talento (sciocchezze, dato che la maggior parte aveva già lasciato Apple). La spiegazione che venne data per giustificare la terminazione dello sviluppo del Newton OS fu che Apple non aveva abbastanza talento manageriale per ‘concentrarsi’ su più di un sistema operativo alla volta; in altre parole un’ammissione di incompetenza, un autogoal, più la riluttanza a ‘delegare’ responsabilità e autorità a uno staff manageriale qualificato che potesse occuparsi del Newton.

    Certamente, a mio avviso, nessuno del senior management di Newton, Inc. è stato in grado di far diventare Newton, Inc. un’azienda di successo, e Sandy Bennet si trovò in una brutta posizione con Jobs per come aveva gestito la comunicazione verso i dipendenti all’epoca del riassorbimento.

    Ormai è una missione

    Mele e appunti

    Adobe preps full Flash player for smartphones | iPhone Central | Macworld: Un articolo involontariamente divertente, che mostra come ormai Adobe si sia incaponita nel voler produrre a tutti i costi un player di contenuti Flash per gli smartphone. Il primo particolare che mi ha strappato un sorriso è stato fare clic sulla notizia nei feed RSS e scoprire che, malgrado il titolo faccia pensare a qualcosa di imminente, questo fantomatico player Flash sarà pronto… alla fine dell’anno.

    Adobe ha dichiarato lunedì che rilascerà il suo primo e completo player Flash per smartphone per la fine di quest’anno.

    Ma, poche righe più sotto:

    Tuttavia Adobe ha dichiarato di essere ben lungi dal produrre player Flash che possano funzionare con iPhone di Apple o con il BlackBerry di RIM.

    Hmmm, ma se togliamo iPhone e BlackBerry, onestamente, chi rimane nel mercato degli smartphone? Ah, quei nomi che si leggono qualche riga sopra: Nokia, Google, Microsoft, Palm… l’armata Brancaleone.

    Più avanti possiamo trovare l’altra cosa che mi ha divertito di questo articolo, ossia le dichiarazioni di Murarka, direttore di partner development e technology strategy della piattaforma business di Adobe.

    Adobe è al lavoro su un player Flash ottimizzato per iPhone da quasi un anno, dopo che Steve Jobs (CEO di Apple) si è lamentato delle prestazioni di Flash su iPhone.

    Abbiamo fatto molti progressi, ma c’è ancora molto lavoro di ingegnerizzazione da fare”, ha detto Murarka.

    Eccome se ce n’è: immagino debbano fare i salti mortali per evitare di infrangere le regole stabilite da Apple nell’iPhone SDK.

    Stiamo lavorando con Apple con ciò che abbiamo”, ha detto Murarka. “Siamo fermamente intenzionati a far funzionare il plug-in di Flash su iPhone”.

    Sono parole che riecheggiano quelle del CEO di Adobe, Narayen, che in un intervista a Bloomberg un paio di settimane fa diceva: È una sfida tecnica durissima, ed è anche per questo che Apple e Adobe stanno collaborando. Onestamente, visto che né Narayen prima né Murarka adesso hanno fornito qualche dettaglio in più su questa ‘collaborazione’, io mi permetto di nutrire qualche dubbio.

    Ma torniamo all’articolo:

    Adobe si trova ancor più indietro con RIM.

    Abbiamo avuto alcune conversazioni preliminari e stiamo valutando diversi approcci al problema”, ha detto Murarka, “Vi è grande interesse da parte dei clienti aziendali BlackBerry nella possibilità di realizzare applicazioni Flash. Ma non vi è ancora nessuna soluzione vera e propria.

    Sarò velenoso: secondo me sono tutte chiacchiere a livello di pubbliche relazioni e nient’altro. Fatico a credere che i clienti aziendali BlackBerry si mettano a pensare “Ehhh, se solo potessimo realizzare applicazioni Flash! Quelle sì che semplificherebbero la vita…”.

    Poi ci sono i commenti degli analisti e, stranamente, trovo qualcuno che dice qualcosa di sensato — Jack Gold, di J. Gold Associates, il quale non crede che vedremo Flash su iPhone tanto presto, per due ragioni:

    La prima è tecnica. “Adobe vuole che Flash giri davvero bene. Per avere buone prestazioni è necessario accedere ai livelli più bassi del sistema operativo o del telefono”, ha detto Gold. “Windows Mobile, Symbian di Nokia e Google Android sono relativamente aperti sotto questo aspetto, ma sistemi operativi come quelli di BlackBerry e di iPhone non lo sono”.

    La seconda ragione, almeno per quanto riguarda Apple, è commerciale. “Apple vuole spingere le proprie tecnologie, in questo caso QuickTime”, ha detto Gold. “Ha a cuore i propri interessi prima di tutto. Guardate quanto tempo ci ha messo Flash ad arrivare sui Mac. Onestamente, non credo che si vedrà Flash su iPhone tanto presto”.

    Amen. Ormai credo che l’abbiano capito tutti — meno Adobe.