.
Annunci online

Tutto quel che puo' venire in mente a un italiano che si e' sposato e spostato in california
TECNOLOGIE
11 agosto 2008
Diario: Tecnologie: AROS: C'e' qualcosa da dire su cui non ho gia' rotto le scatole?

(immagine dal sito ok/cancel)


Non sono del tutto in forma recentemente.

Sono indietro con il lavoro,la mia acidita' di stomaco ha una piccola recrudescenza e mi fa riportare la sensazione di avere una friggitoria dentro la pancia con gli schizzi di olio bollente che si abbattono contro le pareti dello stomaco.

Il che mi impedisce in parte di concertrarmi.

Ho appena letto la continuazione del discorso di commiato dammy, ex manutentore delle bounty aros su moobunny e mi sento un pochettino scoraggiato.

Dammy non e' delicato nei rospi che si e' tolto dalla gola: faro' un sunto non preciso.

Prima di tutto la rabbia nella decisione quattordici anni fa nel considerare PPC come futura piattaforma amiga piuttosto che l'x86;

Secondo, il suo disaccordo nella decisione di AROS alla nascita di voler ricostruire "completamente " l' API di Amiga OS 3.1: lo considera senza senso al di la di un porting (tuttora inesistente) di AROS su 68k, basato solo sulla necessita' (al tempo) di usare le API del 3.1 per le funzioni grafiche e , visto che a tredici anni dalla nascita del progetto, lo status del completamento delle API e' ancora solamente al 89%, ne professa il fallimento, considerandolo un culto del cargo a tutti gli effetti.

Comunque Dammy precisa che i maggiori sostenitori della piena compatibilita' 3.1 sono non sviluppatori bensi' i NON sviluppatori, molti tra cui, probabilmente, sono dei nostalgici che cercano una esperienza "full immersive" da AROS a livello del vecchio amiga os per continuare la "magia" e sperare di svegliarsi da un incubo di quindici anni.

Io spero realmente che AROS arrivi al suo traguardo di implementare pienamente le API 3.1 e spero anche che sia un punto di partenza, non uno di arrivo, da cui iniziare ad evolvere il sistema: non mi interessa se si arrivera' ad un punto di rompere le API attuali per implementare le nuove funzionalita' come memoria protetta e le vecchie applicaizoni dovranno lavorare dentro una sandbox (per gli italiani che non sanno cosa sia: pensate alla vasca con la sabbia dentro il parco giochi: il programma "gioca dentro" e non fa danni fuori dal suo spazio di memoria assegnata).

Ma sono tutte cose di cui, come gia' dicevo sopra, ho parlato in passato.

Non ci sono troppe cose da commentare: il mondo AROS, cosi' come quello amiga, e' usualmente sonnolento ai livelli di un paesino: molte cose sono fatte dentro casa, "sotto il cofano" come si dice, e per vedere il "motore" aiuta essere iscritto alla lista degli sviluppatori.

Eppure le cose escono fuori: il recente debutto della versione Sam440, la nuova build con GRUB 2, che garantisce una migliore compatibilita' e che consentira' di bootare da dischi SFS e non solo FFS, il porting su EFIKA su cui al momento stanno lavorando in parallelo sia Michael Schultz che Yakumo9275, c'e' interesse da parte degli sviluppatori di Natami per un port di AROS sulla loro macchina, che si tradurrebbe a un port di AROS su piattaforma 68k, che ho visto assegnato nella fase 1 a bheron, che non so chi sia.

Ma, come in tutti i piccoli paesini, l'atmosfera da piccolo paesino di provincia quale e' nel mondo dei sistemi operativi AROS e il mondo amiga in generale,in cui tutti si conoscono,  porta a far cozzare eghi(plurale di "ego"?) e abitudini consolidate, facendolo scoppiare nelle varie litigate che conosciamo su sistemi amigoidi, modalita' di implementazione, ecc.

Io non mi ritengo immune dallo schierarmi, ma almeno cerco di tenere una mentalita' un pochettino piu' pragmatica, o almeno provarci.

Sara' che sia io che il buon Paolone, [che or ora e' diventato Padre, congratulazioni:) ] ci adoperiamo per far crescere AROS al di la del semplica sistema operativo hobbistico come viene relegato da qualcuno dei suoi stessi autori: l'architettura Amiga ha ancora un potenziale notevolissimo, soprattutto nel settore hobbistico come tool di appoggio: non tutte le applicazioni necessitano memoria protetta e altre funzionalita' avanzate: pensate all'HAM radio, al music sequencing, magari con trackers che supportano il MIDI o con il port di programmi attualmente su amiga OS e su piattaforme open source quali audacity.

Cito me stesso da questo thread su Amigapage.it:

Vedo interessanti aperture soprattutto per quei campi hobbistici in cui ci si vuole concentrare di piu' sul computer come ausilio che come strumento da gestire a parte: ricordo programmi su amiga per HAM radio, per illuminotecnica (erano stati rilasciati dei sorgenti per programmi simili un po' di tempo fa) e per altri settori hobbistici magari secondari in cui il s.o. non necessita di grandi capacita' per operare e piu' semplice e' meglio e' ed al momento le alternative sono solo win o linux, entrambi abbatanza gonfiati, che necessitano di macchine abbastanza potenti e di solito devono essere gestite con cautela: AROS per queste cose risulta perfetto: gira su macchine non troppo recenti, non usa troppe risorse ed e' relativamente semplice da gestire.
[tra parentesi, non mi cito per autoreferenzialita' ma solo perche' sono un po' troppo pigro per riscrivere la pappardella da capo :P ]

di cosa altro non ho parlato?  Di sviluppare strumenti per il RAD, o sviluppo rapido di applicazioni o per aiutare lo sviluppo di quelle esistenti, un settore non molto sviluppato su amiga se escludiamo ADV per os4 e altri tool che altre persone isolate stanno cercando di creare su Amiga OS (non su AROS purtroppo, per ora): per quanto nel thread sopra Shinkuro dissente in parte:

Trovo gli strumenti che generano automaticamente le GUI come qualcosa di discreto per i principianti e per chi ha delle scadenze lavorative. In altri casi lasciare il compito di generare GUI a degli strumenti automatici è un azzardo che non farei su programmi seri... Potrei prendere come esempio il Visual C# che quando usi i tools grafici istanzia e connette tutti gli elementi di una gui in un unico metodo, qualcosa di osceno se pensi alla programmazione OOP basata sul riutilizzo ed estensione di classi per composizione ed ereditarietà...


...questo dovuto anche al problema che nella programmazione Amiga non e' possibile separare la programmazione della GUI dal programma stesso come in sistemi piu' moderni come confermato da Shinkuro in altri ambiti in quest'altro thread:

Su Amiga non esiste un set di API completo OOP, esiste solo per le GUI.
L'autore di Frying Pan per rendersi la vita meno faticosa ed avere la
possibilità più rapida di portare il suo software da un Amiga and un
altro ha creato questo:
http://sourceforge.net/projects/amiga-generic/


Il codice sopra ritengo sia interessante ma, siccome e' rilasciato sotto GPL 2 non ho idea se ci siano dei problemi ad usarlo all'interno di AROS, forse per delle applicazioni a se stante va bene...
Non e' possibile pero' scindere il discorso dello sviluppo di GUI dai problemi di usabilita', notoriamente croce dei progetti open source; alcuni studi e considerazioni recenti qui e qui ci fanno capire come il problema sia certe volte della natura stessa open source di provenienza dei progetti (soprattutto nel campo linux, visto che i rapporti puntano principalmente a quel sistema operativo), e i programmatori stessi che non hanno le abilita', tutt'altro che scontate, di costruire interfacce usabili, ma non completamente per loro colpa: l'usabilita' non e' un paradigma universale, bensi' profondamente soggettivi, ovvero quiel che e' usabile per uno sviluppatore e' molto meno usabile per un utente comune, cosi' come quel che e' usabile per un grafico non lo e' per un programmtore e cosi' via, e non solo: di solito nel mondo closed l'usabilita' e' solitamente regolata da linee guida sull'interfaccia - cosa raggiunta recentemente da GNOME e KDE e proposta da Shinkuro nella mailing list di AROS ma finora limitata alle linee guida del veccio os3.1 e non completamente applicata - e migliorata con l'ausilio di tests su soggetti e di feedback da sviluppatori, e queste cose costano soldi, a meno di non ricorrere a un servizio open source come possa essere un openusability.org.

Poi aggiungete che molte volte il tipico programmatore geek e' non persona con le migliori doti sociali e la filosofia hacker su cui si e' formato per primo l'open source e', volente o nolente, elitistica, in cui il rito iniziatorio e' quello di capire il sistema operativo e il programma che si usa a livello sorgente si' che si passa dall'inferiore "luser" utente al superiore "l337" sviluppatore e si comincia a capire come mai ancor oggi linux abbia l'1% sul desktop:il buon linux haters blog trova fertile terreno in queste cose e in altre tipiche magagne del mondo linux, e quest'altro articolo mostra come anche la ivi dichiarata "mancanza di rispetto per l'utente finale" in fondo non sia cosa ignota anche a noi amighisti: il conflitto di ego, il reinventare la ruota ogni volta e, come detto da diversi su veri forum amighisti "la malsana abitudine di lasciare il campo giochi portandosi via i giochi con se", ovvero, quando per qualche motivo (buono o meno, vedi poseidon o MUI) lo sviluppo del software si interrompe, invece che metter nel pubblico dominio o in open source i sorgenti, l'accesso agli stessi e alle risorse prima disponibili viene interdetto e il software lasciato morire senza speranza.

Penso di fare cosa gradita agli sviluppatori che ne volessero fare opera di postare questo breve vademecum sul design di software usabile apparso su joelonsoftware.com, che non e' da considerarsi opera unica ma un semplice punto di partenza per un migliore metodo di sviluppo delle applicazioni.

Ho badato tre giorni  a scrivere questo articolo e ne postero' una versione in inglese nel blog in lingua inglese appena avro' il tempo di tradurlo.
sfoglia
  

Rubriche
Link
Cerca

Feed

Feed RSS di questo 

blog Reader
Feed ATOM di questo 

blog Atom
Resta aggiornato con i feed.

Curiosità
blog letto 1 volte

Articoli Recenti

Who links to me?

Contatta Simone Bernacchia

 




IL CANNOCCHIALE