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.
Ma se la meta’ dei programmatori non usa lo unit testing…. di che ti stupisci?
La metà? Forse sei troppo ottimista. :D :) :| :( -_-
Maledetti programmatori grassi con le dita nutellose, troppo pigri per scrivere suite di test e per mantenerle aggiornate… Crudele fato, la nostra stessa natura nerdica ci si ritorce contro!
Non volevo essere troppo pessimista.. in effetti forse sul 20% dei progetti che ho visto e’ stato usato lo unit testing… non parliamo di continuos integration… -_-‘
I test sono notoriamente noiosi ;-) l’unico framework che ho visto che rende la scrittura di test unitare e di test selenium “leggera” è play framework. (un framework java per lo sviluppo di web application)
E stanno pure prendendo un pò di roba da aros.. almeno in quelle parti che hanno rilasciato come codice sorgente ce ne è un bel pò traccia.
E se il problema fosse dare così tanta enfasi agli unit test… e troppo poca ai test di integrazione?
Metà dei programmatori non usa gli unit test…metà di quelli che lì fà testa centinaia di casi triviali non concludendo comunque nulla…
Sarà una mia impressione ma l’intero mondo amiga pare averci preso gusto ad essere parte di un confronto dove si cerca di fare sempre peggio.
Non c’è un solo sistema dei tre rappresentanti che punta realmente ad essere migliore e presentabile al mondo, sembra che tutti puntino solo sul fatto che se uno ama amiga allora l’accetterà per quanto scarso è, di conseguenza pagherà fior di quattrini in licenze discutibili (forse neppure legalmente riconosciute), software scadenti, hardware pietosi e/o usatume vario.
Veramente, questo masochismo è qualcosa di completamente incomprensibile: non mi stupisco che moltissima gente tra chi ha ancora due soldi da buttare dalla finestra, preferisca spenderli nell’ennesima scheda acceleratrice o di i/o con il quale fare il jenga sul A500, al limite farsi la nuova fpga arcade.
Sarei stato molto curioso di provare questo morph os 3.0 e di conseguenza fare qualche calcolo sull’acquisto di un powerbook (che adesso, non per dire, ma costano tutt’oggi uno sproposito) ma vista la situazione, lette le varie recensioni, eviterò. Di sicuro non vivo nello stesso mondo di coloro che hanno carettate di soldi da spendere a babbo morto.
ultimamente i testi vengono fatti fare direttamente agli utenti finali con le varie versioni alfa e beta (se non proprio le definitive) :)
Il che si traduce con “a te gira ? si gira, ok a posto”
Dove lavoro io di test se ne fanno un bel po’. Alcuni sono anche concordati con il clienti, per dare il via libera definitivo al software.
Altri test interni vengono schedulati anche di notte.
La politica dei test e cambianta però, da un’anno a questa parte.
Prima i test venivono fatti solo all’occorenza e a scelta dei vari gruppi di lavoro.
Finché in molte università italiane continueranno a spiegare il modello waterfall e solo quello senza fare mai un accenno agli unit-test…
Trovo molto grave questa cosa, soprattutto nei corsi di ingegneria informatica.
Le università italiane non sono concepite per far uscire gente veramente utile, ma titolati che con il giusto mix di calci in culo (parentele, amicizie e sponsor vari) finiscono per poggiare il sedere in qualche cda lasciando ai periti (e neanche tutti perchè il brutto vizio s’è esteso già da tempo pure al livello inferiore) l’onere di tirare la carretta.
Poi se l’università si chiama bocconi, il cda di riferimento è il governo e ci si può sbizzarrire a far fallire ben più di un’azienda qualunque…
Da me spendiamo piu’ tempo a scrivere e correggere e mantenere test che a scrivere verilog :P d’altro canto in hardware e’ necessario, non puoi rilasciare le patch :) ogni volta che un bug ti obbliga a fare respin paghi qualche settimana (o qualche mese) tra quando fissi il bug e quando il chip torna dalla fonderia, e qualche centinaio di migliaia (o qualche milione) di dollari per rifare le maschere… richiede una mentalita’ diversa di approcciarsi al testing :)
Ma in fin dei conti non era uguale anche per i giochi su console, quando non andava ancora di moda inserire pure lì degli hard disk ?
“d’altro canto in hardware e’ necessario”
Esatto, dipende dal contesto. Ci sono software esigono anche verifiche formali di correttezza, altro che test automatici!
Poi le verifiche vengono “waived” e tutto va in vacca comunque :D
Com’e’ che era andata per il primo Ariane 5? Mi sembra una cosa cosi’:
* Ariane 4: codice nel controllo dei propulsori ha un cast da floating point a integer; viene fatta review e viene deciso che era ok perche’ il range del floating point (i valori assunti veramente nella specifica applicazione) e’ sempre minore del range dell’integer
* Ariane 5: il range del floating point non e’ piu’ ok, ma non viene fatta la review di nuovo perche’ era gia’ stato rivisto e waived nel razzo precedente
* qualche decina di secondi dopo il lancio il fp va fuori scala, il cast sbarella, il controllo dei propulsori va fuori controllo, rottura meccanica del razzo, attivazione automatica dell’autodistruzione, qualche miliardo di euro in fumo (compresi i satelliti a bordo)
Ale’ :)
Il fatto è che come al solito su questi sistemi la fase di testing la fanno gli utenti paganti…
E’ inutile girarci ancora intorno, gli OS AmigaNG al giorno d’oggi sono diventati solo degli emeriti bagagli inutili. Se invece di cercare sempre di aggiornare l’hardware (l’AmigaOne x1000 per AmigaOS e i powerbook G4 per MOS) pensassero a fare il minimo sindacale di software e qualche gioco originale dedicato, allora magari arriverebbero più seguito e risulterebbero appetibili per più di qualche curioso retronostalgico.
Così invece sembra sempre che il software non ci sia perché l’hardware non basta mai e poi succede che gli OS stessi non riescono a supportare bene il nuovo hardware quando ancora risultavano “immaturi” per quelli vecchi.
La storia che ci sia bisogno di rendere gli OS AmigaNG al passo con i tempi è una vaccata che permette solo di buttar fumo negli occhi agli utenti e spingerli così ad acquistare nuove licenze (ed eventuale nuovo HW)!
Chi vuole un computer moderno, ne compra uno con windows o Linux oppure un Mac; che senso ha comprare un OS AmigaNG se tutto ciò che fa è un trentesimo di ciò che fanno gli OS più diffusi (ma infinitamente peggio) e su sistemi hardware più costosi e obsoleti a livello di prestazioni?
Lo stesso MorphOS costa come Windows (!) e un powerbook G4 usato si paga anche più di 250 euro… Ma con 350 euro, rispetto ai catorci AmigaNG, che “mostro” di computer si può comprare nel 2012?
Da salvare ormai resta solo AROS e SOLO perché è OpenSource…
E poi danno addosso alla Commodore perché non usa AmigaNG? La realtà è che sono OS improponibili per qualsivoglia utenza e nessuna aziendella al mondo li potrebbe mai prendere seriamente in considerazione.
Meno male che ci sono articoli come questo che dicono davvero come stanno le cose.
Cesare su Amiga mancano delle vere suite di programmazione alla Eclipse/Visual Studio, figurati se potrebbero mai esistere degli strumenti per i test…
Solo adesso MorphOS ha un porting di Scintilla, OS4 ha editor proprietari di dubbia qualità/velocità/affidabilità, AROS non ha nemmeno un editor che supporti la sintassi colorata.
Sulla mia guida alla programmazione Amiga compatibile c’è tutto un capitolo sugli ambienti di sviluppo, basta leggerlo per capire quanto siano indietro i sistemi Amiga in questo campo…
Per scrivere test non servono editor più o meno avanzati o IDE, ma… serve scriverli!
I test sono codice, e li si può lanciare anche da command line.
Qui la questione è semplice: o li si scrive, oppure no. Che si parli di AmigaOS/like o di un altro sistema è del tutto indifferente, perché il nocciolo della questione riguarda una buona pratica dell’ingegneria del software.
Infatti nell’articolo parlavo di test anche su dispositivi embedded, che non sono certo facili da testare, e se leggi il commento di pleg, lo si fa anche su qualcosa di “leggermente” più complesso.
Con una buona batteria di test certi bug salterebbero fuori molto velocemente. E credimi: a conti fatti il tempo che impieghi a scrivere un test viene AMPIAMENTE ripagato dalle modifiche al codice che, purtroppo, ci saranno dopo.
E’ questione di volontà, di entrare nella giusta mentalità, ma soprattutto di professionalità, anche se posso capire che scrivere test possa risultare noioso (“ma è ovvio che il codice funziona: si vede a occhio!”; dopo un po’ di tempo cambi qualcosa da qualche parte e quell’ovvietà diventa, invece, un pugno nell’occhio).
In ogni caso test suite o meno, MorphOS 3 mi sembra un’alpha rilasciata agli utenti che la stanno testando sulla loro pelle, com’è stato scritto in qualche commento.
Non mi sembra un comportamento corretto per un’azienda che VENDE questo prodotto.
Questo non significa che si debba rilasciare un prodotto bug free (cosa alquanto difficile: più è complesso un software, più aumenta la probabilità di trovarci un bug), sia chiaro, ma un certi errori grossolani si debbono poter evitare.
P.S. Non intervengo sulla questione università italiana, e men che meno sulla politica.
E’ proprio così, si potrebbero evitare errori grossolani.
Però bisognerebbe accorgersi da soli che sono utili, non si deve aspettare che sia il cliente a importi di farli.
Per quanto riguarda i test formali sul codice tipo quelli studiati all’università, non saprei come applicarli, non ho mai visto un caso concreto, purtroppo.
Sarebbe bello però.
Effettivamente un’alpha del genere dopo tutto il tempo atteso per averla ha gettato una piccola ombra sul mos-team che li avvicina a quelli di Hyperion, sia per tempi di sviluppo che per modus operandi, sembra che tutto il sistema Amiga Ng rappresentato dai due OS PPC commerciali sia abbastanza in crisi
Avrei preferito che l’uscita di MorphOS 3.0 fosse postdatata e lo avevo espresso un paio di volte: meglio attendere un prodotto completo che averne uno grezzo. Attendere non era un problema e l’impazienza non da i suoi frutti.. Alcuni ricorderanno la versione 1.4, acquistata nel 2004 col Pegasos, e tutte le night build uscite dopo la 1.4.5 che ogni tanto crashavano senza apparente motivo. La 1.4 non fissava la posizione delle icone nella finestra dopo averle ordinate =D
Eppure era uno spettacolo usare MorphOS!
Quindi, aspetto pure altri tre anni (!!) ma.. wham! Ecco la 3punto0 in tutto il suo splendore!!
Ma, a costo di sembrare un fun-boy (intenzionale la “u”) registrerò una delle due macchine PMac che posseggo. Perchè?!? Ho comprato la mia prima licenza nel 2008, un mese dopo l’uscita della 2.0 e farò il bis, dato che è ora di scaldare le chiappe al PMac (e pure perchè me so’ rotto di riavviare ogni 30 minuti!).
Certo è che di bugs ce ne sono e che le macchine Apple (un mondo misterioso, per me) sono diverse e sembrano avere ognuna diversi modi di funzionare. Così può capitare che a me l’MDD funzioni senza problemi e ad altri (fatto accaduto) vada uno schifo, ad alcuni il PowerBook non da problemi ed altri non riescono ad usare il touchpad.. Ecco perchè probabilmente (leggi: sicuramente) era meglio attendere anche un ulteriore anno ed avere una 3.0 robusta e più solida, fermo restando che questa 3.0 ha in se molte potenzialità.
Poi, chissà… magari escono a ripetizione la 3.1, la 3.2 e la 3.3 per risolvere e fixare molti dei bug presenti. E per confermare il lavoro del MorphOS team che fino ad ora non è stato niente male. Vado a fiducia.
Insomma, una “toppa” la si può pure prendere, purchè non diventi un modus operandi…
Il MOS-Team tra l’altro ha sempre messo le mani avanti sui driver 3D assicurando prestazioni incredibili.
E alla prima uscita pubblica hanno fatto un tonfo per terra (chissà che male :p), sopratutto perchè a diverse persone o andava tutto al rallentatore o crashava l’applicazione.
So che sono stati fatti dei fix al browser, ma al resto?
Semplicemente l’interesse per siffatti sistemi operativi commerciali proposti su hardware esotico/vintage, costosi nel caso dei powerbook di mos, e folle nel caso degli amigaone di os4, si è di molto ristretto…
L’apprezzabile calo di prezzo della licenza MOS un po’ cerca di correre ai ripari, ma resta il problema che il nuovo hardware supportato ha i soliti prezzi esagerati nell’usato, e ancor più grave è apparso il disinteresse del mos team nel testare la 3.0 sulla nutrita base powermac con schede grafiche Ati flashate (cioè la fascia economicamente più accessibile e di facile reperibilità, nonché di discreta potenza)
Un anno e mezzo per riscrivere dei driver 3D e supportare nuovi modelli ppc, sicuramente un lavoro immenso… ma allora per vedere un supporto alle macchine x86_64 quanto tempo occorrerà e con quali risultati?
Le velleità commerciali fanno molto male a questi sistemi Amiga NG, soprattutto alla luce del felice esempio open source di aros che è sotto gli occhi di tutti…
Verrebbe da chiedersi perchè si ostinano sui mac (ppc poi è ancora un altro discorso).
Sembra quasi che sono convinti che tutti i mac di uno stesso modello sono uguali: ma dove sta scritto ?
Basta vedere i notebook in genere: provate a scaricare i driver dal sito del produttore e troverete per lo stesso modello di portatile, due o tre webcam diverse, un paio di schede wifi di marche diverse, touch pad che non si sa quale si monta e via discorrendo.
Alla fine che senso ha dire “il nostro sistema è testato su questi modelli di computer” se tanti modelli uguali rischiano di essere computer con pezzi diversi ?
Anche questa sarebbe una buona ragione per mollare i vecchi mac e passare ai pc dove almeno potrebbero dire con certezza quale chip video è supportato e quale no a prescindere dalla targhetta stampata sul case del pc in questione.
Masochismo o miopia.
Peggio, Orgoglio.