Ho appena installato l’aggiornamento di Leopard (10.5.1): tento di avviare Parallels (3.0 build 5160) e il risultato è uno splendido kernel panic 🙁

Si tratta del secondo kernel panic nella mia carriera di utente Mac: il primo era dovuto sempre a Parallels, non ancora compatibile con i nuovi iMac Intel.

Io vi ho avvisati, nel frattempo cerco notizie 🙁

UPDATE: ho dato un’occhiata al forum di supporto di Parallels e non risultano problemi legati in modo specifico alla versione 10.5.1. Dopo il reboot forzato Parallels sembra funzionare normalmente (sgratt sgratt) 😕

Thu Nov 15 21:31:25 2007
panic(cpu 1 caller 0x001A7BED): Kernel trap at 0x36e2298a, type 27=Unknown, registers:
CR0: 0x8001003b, CR2: 0xb01adfec, CR3: 0x00d68000, CR4: 0x00000660
EAX: 0x00000003, EBX: 0x6d626572, ECX: 0x3841f000, EDX: 0x2e527b70
CR2: 0xb01adfec, EBP: 0x2e527bb0, ESI: 0x6d616769, EDI: 0x63216e75
EFL: 0x00000002, EIP: 0x36e2298a, CS: 0x00000008, DS: 0x00000010
Error code: 0x00000000
Backtrace, Format - Frame : Return Address (4 potential args on stack)
0x2e527998 : 0x12b0e1 (0x455670 0x2e5279cc 0x133238 0x0)
0x2e5279e8 : 0x1a7bed (0x45ea20 0x36e2298a 0x1b 0x454484)
0x2e527ac8 : 0x19e517 (0x2e527ae0 0x206 0x2e527bb0 0x36e2298a)
0x2e527ad8 : 0x36e2298a (0xe 0x48 0x70010 0x70010)
0x2e527bb0 : 0x36e22814 (0x3583b332 0xdeadbeef 0x246 0x0)
0x2e527be8 : 0x3583c082 (0x36e22800 0x2e527c1c 0x108 0x7fffffff)
0x2e527d48 : 0x35837940 (0x6e79084 0xc0185405 0x2e527ed0 0x1efb9f)
0x2e527d78 : 0x200a2c (0x13000000 0xc0185405 0x2e527ed0 0x81)
0x2e527db8 : 0x1f3e66 (0x2e527de8 0x246 0x2e527e18 0x1d803e)
0x2e527e18 : 0x1ea123 (0x6e4db00 0xc0185405 0x2e527ed0 0x81)
0x2e527e78 : 0x362e18 (0x46cadb0 0xc0185405 0x2e527ed0 0x2e527f50)
0x2e527e98 : 0x389778 (0x46cadb0 0xc0185405 0x2e527ed0 0x2e527f50)
0x2e527f78 : 0x3da847 (0x4028780 0x6330860 0x63308a4 0x0)
0x2e527fc8 : 0x19ea34 (0x59ebd80 0x1 0x10 0x59ea700)
No mapping exists for frame pointer
Backtrace terminated-invalid frame pointer 0xb06b5ef8
Kernel loadable modules in backtrace (with dependencies):
com.parallels.kext.vmmain(3.0)@0x35836000->0x35845fff
BSD process name corresponding to current thread: Parallels
Mac OS version:
9B18
Kernel version:
Darwin Kernel Version 9.1.0: Wed Oct 31 17:46:22 PDT 2007; root:xnu-1228.0.2~1/RELEASE_I386
System model name: iMac5,1 (Mac-F4228EC8)

Per prima cosa: se volete usare Parallels su un iMac con processore Core 2 dovete scaricarvi una versione beta (al momento attuale la 1908 l’ultima versione disponibile è  la 1910). Subito dopo aver scaricato la beta si scopre che i sistemi operativi a 64bit non sono supportati 🙁

Il problema dovrebbe essere risolto con la prossima Major Release di Parallels.

Da almeno un paio d’anni mi sono deciso ad utilizzare sistemi di controllo versione per i miei piccoli progetti (sviluppo software win32 in Delphi e siti web). Lo scopo non è tanto quello di avere un (ulteriore) backup, quanto capire quando e perché ho fatto determinate scelte a distanza di mesi o anni.

Forte dell’esperienza legata ai lavori di traduzione con Mozilla, la mia prima scelta è stata Subversion (SVN): inizialmente ho utilizzato il servizio SVN su DreamHost, poi ho riciclato il vecchio Mac Mini come server locale da affiancare al repository online. Come client la scelta naturale su sistemi Windows è TortoiseSVN. Su Mac, dopo qualche esperimento insoddisfacente con SCPlugin, ho deciso di passare all’ottimo Versions (a pagamento).

Premesso che lo sviluppo web lo seguo esclusivamente su Mac con TextMate e Mamp, nel corso del tempo è nato un problema non indifferente: per una mia forma mentis preferisco non lavorare direttamente sulla copia locale del repository. Periodicamente copio la cartella di lavoro (ad esempio la cartella di un tema WordPress presente nella httpdocs di Apache) all’interno della cartella svn del progetto specifico e gestisco da lì i commit.

Il problema è che, su Mac, sostituire una cartella significa di fatto eliminare l’originale e copiare al suo posto la nuova cartella. Di colpo tutta la cartella diventa “non revisionata” e ingestibile con SVN!

Da qualche tempo Mozilla è passata per la localizzazione dei software a Mercurial (Hg), mantenendo SVN solo per il settore web. Quando ho sostituito l’iMac a dicembre mi sono posto il problema di aggiornare i repository direttamente da OS X (finora avevo sempre usato TortoiseHg su Windows) ed ho scoperto l’ottimo MacHg. A questo punto il dubbio: perché non usare Mercurial anche per le mie esigenze? Presto fatto: ho acquistato la licenza di VMWare Fusion, installato Ubuntu Server e creato un server Mercurial seguendo questa guida (il server è locale, non ho bisogno di autenticazione o sicurezza).

Due vantaggi immediati:

• Mercurial è un sistema di controllo distribuito, per cui posso fare i commit in locale, avviare periodicamente la macchina virtuale e fare un push per sincronizzare;
• Mercurial non salva le informazioni in una cartella nascosta in ogni sottocartella ma solo nella root del repository, per cui sostituendo una sottocartella non si hanno problemi analoghi a quelli con SVN.

A proposito di VMWare Fusion: in passato ho sempre usato Parallels, approfittando di un’offerta sono passato a Fusion acquistando la licenza per 19.99$. Non riuscendo a registrare la licenza online, ho scritto una e-mail al supporto: nel giro di poche ore avevo una risposta in grado di risolvere il mio problema nella mail, non contenti il giorno dopo mi hanno anche telefono dagli Stati Uniti per capire se il problema era stato risolto. Piacevolmente stupito 🙂

Firefox 3.0.1 su Windows XP (VM in Parallels): 1.755,40ms (link)

Firefox 3.1b1pre con JIT attivato su Mac OS X: 1.156,80ms (link)

Google Chrome su Windows XP (VM in Parallels): 342,80ms (link)

Commento a caldo: stica!

P.S. Per i risultati di altri browser date un’occhiata al vecchio post 😉

UPDATE 3 settembre: in Mozilla hanno fatto un po’ di test, e i risultati sembrano essere decisamente buoni per Fx 3.1 con Tracemonkey attivato 😉

Disclaimer: as you may have already noticed, this post is written in Italian. If you need an English version, just ask and I’ll provide one (comments inside the scripts are already in English) 😉

Come avrete sicuramente notato dal post precedente, in questi giorni ho la possibilità fare un po’ di test con un Nokia N810: per questo devo ringraziare Luca, che come sempre si è dimostrato gentilissimo – alla faccia del ferragosto e del periodo vacanziero – e mi ha messo in contatto con le persone giuste (un sentito grazie anche a loro e a Nokia Italia per la disponibilità).

Il punto di partenza è il post del team francese con le indicazioni per la localizzazione di Fennec 0.4. L’idea è quella di semplificare ulteriormente la procedura creando alcuni script, nella speranza che il post possa essere utile anche ad altri team l10n. Tutte le operazioni devono essere eseguite su una macchina debian-based (io uso una VM con Ubuntu su Parallels-OS X); dal momento che scrivere script non è esattamente il mio lavoro, sono sicuro che esistano ampi margini di miglioramento 😉

I pacchetti da localizzare sono due: Fennec e XulRunner. Per prima cosa è necessario scaricare i file dal server Mozilla.

Localizzazione di XulRunner

Partiamo dal pacchetto più semplice, in quanto non sono richiesti interventi manuali.

Per procedere bisogna inserire in una cartella:

• lo script setup_xulrunner.sh
• il file it.jar recuperato dal language pack italiano (attenzione: per xulrunner 1.9.1a2pre serve quello per Firefox 3.1)
• il pacchetto fennec_0.6_armel.deb

Descrizione dello script:

• imposto delle variabili con nome del pacchetto, nome del file .deb e il locale (utilizzate per semplificare il riutilizzo dello script)
• estraggo il contenuto del pacchetto .deb in ./xulrunner, quello del file it.jar nella cartella ./locale_xulrunner
• attraverso sed sostituisco il nome di una variabile in xpinstallConfirm.dtd (ancora mi chiedo il perché di questa differenza tra Firefox e XulRunner…)
• ricreo il file it.jar (in realtà si tratta di un file zip con estensione .jar), sistemo il chrome.manifest sostituendo en-us con it (sempre usando sed)
• elimino i file en-US e ricreo il pacchetto .deb con la localizzazione

setup_xulrunner.sh

#!/bin/sh
# Create an empty folder and place inside this directory:
# * this script (setup_xulrunner.sh)
# * the xulrunner .deb package
# * the ab-CD.jar file taken from your localized Firefox (for 1.9.1a2pre you need a Fx 3.1 language pack!)
#
# Change the package_name variable according to the the xulrunner package,
# language_code according to your locale
package_name="xulrunner_1.9.1a2pre-2008080410_armel"
language_code="it"
product_name="xulrunner"
# Create directories
mkdir ${product_name}
mkdir locale_${product_name}
# Extract deb package
cd ${product_name}
dpkg-deb -e ../${package_name}.deb
dpkg-deb -x ../${package_name}.deb .
# Extract locale files
cp ../${language_code}.jar ../locale_${product_name}
cd ../locale_${product_name}
unzip ${language_code}.jar
rm ${language_code}.jar
# Adapt Firefox localization to xulrunner
# - Remove reporter files
rm -r ./locale/${language_code}/reporter
# - Change variable name
sed -i 's/warningMain.label/warningPrimary.label/' ./locale/${language_code}/mozapps/xpinstall/xpinstallConfirm.dtd
# Create ab-CD.jar with localized files
cd locale_${product_name}
zip -r ${language_code}.jar *
# Move ab-CD.jar to package directory
mv ${language_code}.jar ../${product_name}/usr/local/${product_name}/chrome
# Change en-US.manifest and save as ab-CD.manifest
sed 's/en-US/'${language_code}'/g' ../${product_name}/usr/local/${product_name}/chrome/en-US.manifest > ../${product_name}/usr/local/${product_name}/chrome/${language_code}.manifest
# Remove en-US files (jar and manifest)
rm ../${product_name}/usr/local/${product_name}/chrome/en-US.jar
rm ../${product_name}/usr/local/${product_name}/chrome/en-US.manifest
cd ../${product_name}
# Create localized .deb package
dpkg-deb -b . ../${package_name}.${language_code}.deb

Localizzazione di Fennec

A differenza di XulRunner, la localizzazione avviene in due fasi:

• nella prima fase (setup_fennec.sh) estraggo il contenuto del pacchetto .deb in ./fennec e creo la cartella ./locale_fennec
• nella seconda fase (repackage_fennec.sh) ricreo il pacchetto .deb

Le due fasi sono necessarie in quanto bisogna localizzare a mano le stringhe presenti in ./locale_fennec: come riferimento è consigliabile utilizzare gli analoghi file del language pack di Firefox (molte stringhe sono simili o identiche).

setup_fennec.sh

#!/bin/sh
# Create an empty folder and place inside this directory:
# * this script (setup_fennec.sh)
# * the fennec .deb package
#
# Change the package_name variable according to the the fennec package,
# language_code according to your locale
#
# After the script is run, you should find a locale_fennec folder with the files to localize
fennec_package="fennec_0.6_armel"
# Create directories
mkdir fennec
mkdir locale_fennec
cd fennec
# Extract deb package
dpkg-deb -e ../${fennec_package}.deb
dpkg-deb -x ../${fennec_package}.deb .
# Extract locale files
cp ./usr/local/fennec/chrome/en-US.jar ../locale_fennec
cd ../locale_fennec
unzip en-US.jar
rm en-US.jar

repackage_fennec.sh

#!/bin/sh
# Change the package_name variable according to the the fennec package,
# language_code according to your locale
#
# Inside ./locale_fennec you should have the localized files
#
# Don't run this script twice: since the first execution deletes the en-US.manifest, the second one
# creates an empty ab-CD.manifest file (and a broken .deb package)
fennec_package="fennec_0.6_armel"
language_code="it"
product_name="fennec"
# Create ab-CD.jar with localized files
cd locale_${product_name}
zip -r ${language_code}.jar *
# Move ab-CD.jar to package directory
mv ${language_code}.jar ../${product_name}/usr/local/${product_name}/chrome
# Change en-US.manifest and save as ab-CD.manifest
sed 's/en-US/'${language_code}'/g' ../${product_name}/usr/local/${product_name}/chrome/en-US.manifest > ../${product_name}/usr/local/${product_name}/chrome/${language_code}.manifest
# Remove en-US files (jar and manifest)
rm ../${product_name}/usr/local/${product_name}/chrome/en-US.jar
rm ../${product_name}/usr/local/${product_name}/chrome/en-US.manifest
cd ../${product_name}
# Create localized .deb package
dpkg-deb -b . ../${fennec_package}.${language_code}.deb

Per installare i due pacchetti è sufficiente copiare i file sul dispositivo ed eseguirli: Fennec risulterà disponibile nella scheda Extra del menu (vedi screenshot) 😉

L’idea alla base di questo post è quella di raccogliere un po’ le idee in vista della sostituzione dell’attuale PowerBook: sperando di concludere la vendita la prossima settimana, l’acquisto avverrà in ogni caso dopo il WWDC di metà giugno (non si sa mai…).

Domanda: a cosa diavolo ti serve un portatile Apple?
Risposta: a far funzionare diversi software acquistati con regolare licenza (Aperture, Adobe PhotoShop CS3, TextMate, Transmit, Parallels) quando sono fuori ufficio e in caso di morte dell’iMac.

Questo significa: lasciamo fuori dal discorso i notebook x86 senza Mac OS X.

MacBook

Come ho già avuto modo di scrivere, l’attuale MacBook non mi attrae in modo particolare:

• PRO: interessante la dimensione dello schermo (ma preferirei una risoluzione maggiore) e in generale le dimensioni del notebook
• CONTRO: la tastiera (il fatto che ci si possa fare l’abitudine non è penalmente rilevante in questo dibattimento), materiali e scheda video integrata

Se decidessero di fare un MacBook con scocca (e tastiera!) in alluminio, ci potrei fare un pensierino: purtroppo il MacBook Air ci prospetta un futuro di tastiere plasticose.

MacBook Air

Continuo a non comprendere l’utilità di questo notebook:

• PRO: spessore (ma ricordo che spessore≠dimensioni) e peso
• CONTRO: tutto il resto (tastiera, espandibilità zero, batteria, hard-disk, prezzo)

Scherzi a parte, l’Air è perfetto per il “professionista viaggiante con necessità limitate”, ma questo ne dovrebbe fare un prodotto di estrema nicchia; al contrario, il sottile arnese sembra riscuotere un discreto successo anche tra i “fuori target”.

MacBook Pro

Se non si fosse capito, escludendo a priori il modello da 17″, si tratta dell’obbiettivo primario: scocca e tastiera in alluminio, risoluzione 1440×990 1440×900 e schermo a LED, trackpad multitouch, scheda grafica separata. Se poi ne facessero una versione con schermo leggermente più piccolo (ma più risoluto rispetto al MacBook) non ci sarebbero assolutamente dubbi.

Per questo motivo, l’altro giorno curiosavo nell’AppleStore e notavo la differenza di prezzo tra il modello base e il modello intermedio: quest’ultimo costa la bellezza di 400€ in più, il tutto per una scheda video con più memoria (512MB contro 256MB), hard-disk più capiente (250GB contro 200GB) e 0,1Ghz in più. Le caratteristiche non sembrano giustificare il divario di costo, ma non lasciatevi ingannare da quel misero 0,1Ghz:

• il modello base monta un processore Penryn a 2,4Ghz (T8300), con cache L2 di 3MB (come il MacBook di fascia alta)
• il modello intermedio monta un processore Penryn a 2,5Ghz (T9300), con cache L2 di 6MB

Stabilito questo, si tratta solo di valutare la differenza di prezzo e di prestazioni (questo articolo potrebbe aiutarvi): probabilmente non ne vale la pena, considerando che si tratterà sì e no di una differenza sui materiali inferiore a 150€.