Dopo un lungo periodo di attesa è arrivata finalmente l’attesissima versione 3 di MorphOS, un sistema operativo AmigaOS-like di vecchia data che gira su sistemi basati su microprocessori PowerPC.
Non saranno molti a conoscerlo, perché la sua storia inizia alla fine degli anni ’90, quindi ben dopo il fallimento di Commodore, quando ormai buona parte degli utenti aveva scelto altre vie (PC, Mac, o Linux).
Nonostante il target fosse rappresentato da una nicchia di mercato, ha saputo ritagliarsi un posto nella comunità Amiga grazie a delle caratteristiche interessanti: un s.o. basato su un nuovo microkernel, sul quale girano delle sandbox, e in particolare l’ABox che offre un ambiente estremamente simile a quello di AmigaOS 3.1, per buona parte compatibile con le stesse API.
E’ anche in grado di far girare le vecchie applicazioni 68000 in maniera trasparente e con “pari dignità” rispetto a quelle “native” PowerPC, oltre ad offrire un nuovo e moderno desktop environment (ex-Workbench) chiamato Ambient. Un altro punto di forza è rappresentato dalla velocità, dall’immediatezza nelle risposte agli input dell’utente, e da una sezione 3D (non presente nel vecchio AmigaOS) particolarmente ottimizzata (i giochi portati da PC girano molto fluidamente).
Purtroppo la nuova versione si presenta affetta da parecchi bug, anche gravi, che fanno anche rimpiangere la precedente 2.7. Sono, però, supportate delle nuove (per MorphOS) macchine, i famosi PowerBook G4, che si aspettavano da tempo, ma senza supporto al wi-fi (serve aggiungere una scheda PCMCIA, fra quelle supportate).
I problemi sono diversi: il plug-in Flash del browser OWB che manda spesso in crash l’applicazione (o anche l’intero sistema), in alcuni casi le operazioni sulle finestre che ammazzano le prestazioni, il 3D che non funziona come si deve, alcune applicazioni MUI che vanno in crash con la nuova versione, e difficoltà di aggiornamento o installazione.
Due thread (qui e qui) aperti in due forum amighisti (e non solo) riportano le varie esperienze, che risultano piuttosto variegate, ma com’è possibile leggere le note negative sono parecchie, e lasciano pensare a un rilascio troppo affrettato, complice forse le notevoli pressioni degli utenti che chiedevano da un pezzo notizie sul nuovo nato.
Da programmatore alcuni bug li trovo francamente incredibili, e giustificano il titolo dell’articolo. Come sono stati fatti i test? Perché è fuor di dubbio che ve ne siano stati un bel po’, ma la situazione del 3D e di MUI, in particolare, pone serie riflessioni.
E’ noto che i driver per il 3D sono stati riscritti, per cui necessitano senz’altro di un periodo di “rodaggio”, con un’intensa fase di test. Quel che mi lascia perplesso, da quanto letto, è che probabilmente non viene fatto ricorso a nessuna batteria di test automatica.
Il cosiddetto unit testing va molto di moda da un po’ di tempo a questa parte, e non soltanto per una mera questione di moda, quanto per gli indubbi vantaggi per gli sviluppatori, poiché consente di tenere sotto controllo i requisiti funzionali di un determinato pezzo di codice, funzione, metodo, classe, ecc..
Una test suite ben progettata (perché non è sufficiente scrivere test: bisogna anche saperli scrivere!) consente di raggiungere un buon grado di affidabilità del proprio software, permettendo di effettuare anche profonde modifiche all’implementazione portando difficilmente a “sorprese”, comunque generalmente circoscrivibili e controllabili.
Alcune volte ho letto di difficoltà intrinseche, quando addirittura impossibilità, in alcuni ambiti applicativi, come il 3D, lo sviluppo di interfacce grafiche, la programmazione di dispositivi embedded, ecc.
Certamente in alcuni contesti può essere complicato mettere in piedi una test suite allo scopo, ma si tratta di situazioni già affrontate, e la letteratura in materia non manca di certo.
Prendendo, ad esempio, il 3D, è ben noto che Microsoft metta a disposizione dei test mirati per le DirectX, che consentono ai produttori di schede video di scrivere driver avendo a disposizione un utilissimo strumento per misurare il grado di affidabilità dei risultati ottenuti.
Nel mio piccolo faccio uso intensivo, spesso maniacale, di unit-testing (tante volte facendo ricorso al TDD), perché in questi anni ho potuto toccarne con mano i benefici effetti, grazie a batterie di test particolarmente corpose che esercitano anche centinaia e centinaia di test, grazie ai quali posso dormire abbastanza bene la notte.
D’altra parte ogni sviluppatore dovrebbe essere ben cosciente del fatto che il cambio dei requisiti rappresenta una tautologia nel mondo dell’informatica, e dunque bisogna essere sempre pronti a rispondervi nel migliore dei modi possibili.
Comunque anche in un sistema stabile è desiderabile poter cambiare l’implementazione già esistente con un’altra più efficiente o che si affida a nuovi strumenti (ad esempio si potrebbe voler cambiare l’engine SQL), senza per questo dover rimetter mano al resto del codice o, peggio ancora, comprometterne il funzionamento.
Infine, e tornando nuovamente a MorphOS 3, da utente mi chiedo, invece, come sia possibile per una software house mettere in commercio un prodotto in queste condizioni. Posso capire che il mercato sia di nicchia, ma i soldi sono concreti, tangibili, e vanno a finire nelle tasche dell’azienda.
Certamente rispetto ad altri casi la situazione è un po’ diversa, poiché MorphOS può essere provato per 30 minuti (poi è necessario un riavvio), per cui lo si può valutare e, quindi, decidere di non procedere o rimandare l’acquisto a tempi migliori, ma per un’azienda degna di questo nome rimane una forte nota stonata, a cui si spera verrà presto posto rimedio.
