.
Annunci online

Tutto quel che puo' venire in mente a un italiano che si e' sposato e spostato in california
TECNOLOGIE
10 novembre 2008
Tecnologie: AROS: Anubis OS: Anubis figlio di AROS e il mito del "salto"
Potrei iniziare questo articolo in uno stile alla conan il barbaro parlando di eredi, tradizioni e cavolate varie: sono stato accarezzato per un momento da cio'.

Invece parlero' di un giorno tre settimane fa in cui il buon Michal Schulz posto' un link sul canale #aros: questo.

Altro non e' che la pagina su sourceforge di quel che e' stato annunciato ieri da Damocles come Anubis OS, ovvero la nuova incarnazione di un Amiga OS, basata su kernel linux e il cui sistema grafico, secondo la mailing list, dovrebbe essere basato su xcb,xlib e un misto di Glib/Gtk e Zune.

In breve, fare con Amiga OS quanto Apple ha fatto con OS-X.

Da quel che il buon Michal e Hogne (m0ns00n) Titlestad mi hanno detto al tempo, la ragione principale per cui si e' deciso di iniziare il progetto e' un essenziale immobilismo da parte degli altri programmatori: gia' ai tempi Damocles si era lamentato decisamente dell'approccio conservatore di molti dei core developers, come avevo scritto qui. Michal, insieme a m0ns00n e Damocles cosi' si sono messi a lavorare per definire le basi di Arix e Michal comincera' a lavorarci  pienamente una volta finita la bounty del port per Efika che, per fortuna, ha come conseguenza il completamento della bounty per il mass-storage sotto USB, altr afunzione particolarmente necessaria.

In una successiva conversazione IRC, Michal mi ha detto di come Amiga OS e' una storia di occasioni perse, sia per errori manageriali che per esplosioni di ego di singoli e compagnie e per "blacanizzazione" delle risorse. Vuole che ARIX (non riesco a chiamarlo Anubis mi spiace, il nome non mi piace troppo checcedevofa') diventi quel che Amiga OS 4 sarebbe dovuto essere: con resource tracking, memoria protetta e tutte quelle caratteristiche che Amiga OS prima ed AROS poi non han potuto/voluto sviluppare per i motivi noti.

Per Michal la solita polemica per cui una volta usato uin kernel POSIX Amiga OS non e' piu' Amiga OS quindi speciale e' finita: ha deciso che non e' vero, e penso lo provera' efficacemente in futuro.

Comunque c'e' da precisare che Anubis non puo' essere considerato una fork di AROS: tecnicamente una fork si ha quando viene usato il codice base per implementare una diversa incarnazione; invece, essendo Anubis basato su un diverso kernel, si trova ad essere un progetto indipendente.

La comunicazione non e' stata presa troppo bene dai gruppi presenti: per le citate ragioni di cui sopra e per la nota carenza di sviluppatori, nei forum si aggira una aria di FUD come se ne vedono poche nell'ambiente amighista; la principale paura e' di una fuga di sviluppatori verso il nuovo sistema, che potrebbe non farcela, e la progressiva morte dei sistemi esistenti.

Fortunatamente, i progetti open source difficilmente muoiono: passano nello stato di unmantained almeno fino a cui qualcun altro non ne riprende il mantenimento o non ne integra il codice esistente in nuovi progetti; fortunatamente per AROS questo non pare succedere: il progetto pare attivo come non mai al momento. E speriamo che duri.

E, Per dimostrare ulteriormente che AROS nonostante l'imminente dipartita del "dottore" e l'annunciata maternita' (essendo kitty una "gatta":P) si trova ancora in fase vitale, parliamo dell'attuale erede spirituale del dottore: Stanislaw Szymczyk che nell'ambito del suo lavoro alla bounty per l'autocompilazione, ormai al termine, ha ottenuto risultati notevolissimi, tra cui:
- port non dinamico dell'ultima versione di python e di perl;
- compilazione prima in RAM poi in SFS di AROS in AROS;
- estrensione della compatibilita' POSIX con l'aggiunta di istruzioni come vfork(),wait() e waitpd() ;
- modifica della DOS.library si che possa permettere l'utilizzo di soft-links;
oltre a questo il buon sszy ha standardizzato i packages di sviluppo sulle varie incarnazioni di AROS verso GCC 4.2.2 e ne ha incluso la compilazione nel build system di AROS in modo da avere le build di un sistema di compilaotri nativi e cross-compilatori per tutti i target.

Inoltre ultimamente Stanislaw ha dato un occhiata ai sorgenti di Netsurf e di OWB; tranne alcune minori magagne, il browser potrebbe essere portato abbastanza facilmente dal port OS 4 se non fosse che la gui di OS 4 e' basata su Reaction; Stanislaw cerca qualcuno (o1i potrebbe aiutare si spera, e io mi permetto di nominare ShinkurO come consigliere per i workaround ai buggoni di zune) a fare la GUI sotto Zune. Per il port di OWB invece e' necessario portare Gladelib sotto AROS, cosa che al momento a sszy non e' riuscita.

Altro importante aggiornamento viene dal fronte della verifica del completamento API: Krzysztof Smiechowicz ha completato il lavoro di revisione che ha portato avanti sin dallo scorso aprile; secondo i dati da lui raccolti il livello di completezza di AROS si aggira intorno all'80%. Questo rapporto e' anche la base per la roadmap da seguire in modo da avere una versione 1.0 in tempi umani.

Buono e' anche il fatto che finalmente nella mailing list si comincia a parlare della necessita' di scrivere piu' documentazione. Krzysztof Smiechowicz ha gia' iniziato ad aggiungere documentazione sulla ABI v.1 di aros qui e si spera che ulteriore necessaria documentazione continui ad arrivare presto.

Infine pare che qualcuno possa finalmente prendersi cura anche della printer.device a tempi morti; per quel che mi riguarda ho cercato e inviato documentazione a costui per aiutarlo nello sviluppo, incluso il vecchio port di ghostscript su aros ora non piu' funzionante; speriamo di vedere qualcosa presto.
TECNOLOGIE
21 settembre 2008
Diario: AROS: Documentazione, Documentazione, Documentazione porta Sviluppatori, Sviluppatori, Sviluppatori™
Spero che Ballmer non mi faccia pagare la citazione:P

A causa dei miei impegni di lavoro questa non e' una notizia nuova, ma ritengo sia giusto rimbalzarla qui. La notizia dell'arrivo di Amiga Os 4.1 su SAM e' di un paio di giorni fa e probabilmente appena avro' un po' di tempo per parlarne lo faro', per ora mi attengo al mio programma originale.

uno dei commenti che ho ricevuto la settimana passata su questo mio articolo, viede da Tadsince1995 e mi ha portato a fare un intervento su Aros exec in inglese:

Dopo Robert Norris anche Schultz se ne va. Il problema più grande non è solo il fatto che non lavoreranno più ad Aros, ma la disgrazia è che sono le persone più preparate sullo sviluppo Aros, quindi se ne va un bagaglio di conoscenza che pochi altri hanno. Io ho sempre sostenuto la necessità di un "Documentation bounty", perchè c'è una GRAVE mancanza di documentazione per la parte low level di Aros. Non c'è uno straccio di documentazione sullo stack Usb, poco e niente sulla scrittura di driver ecc. Come può andare avanti un sistema operativo se eventuali nuovi coder non hanno materialmente da dove iniziare?

Specialmente considerando che, chiaramente, molti hanno anche altri impegni e quindi non avrebbero il tempo di mettersi a fare reverse engineering sul codice, mentre avendo un buon tutorial fatto da qualcuno già preparato, si risparmierebbe un sacco di tempo!

A queste parole, da me tradotte per gli anglofoni, ho aggiunto il seguente passaggio:

Supporto in pieno il punto di vista di tad; questa e' la mia personale richiesta per Michael, per Robert, se bazzica ancora questo forum e per tutti gli sviluppatori low-level: non assumete che altri sviluppatori abbiano le vostre stesse conoscenze tecniche: PER FAVORE DOCUMENTATE AROS LOW-LEVEL, per l'interesse dello sviluppo futuro del sistema, una volta che  avrete finito la vostra collaborazione.

La scena Amiga/AROS e' troppo ridotta per permettere di trovare abbastanza documentazione (oltretutto obsoleta), e il funzionamento di Amiga/AROS e' troppo diverso dagli altri sistemi per essere capito facilmente.

Dal che si desume che il metodo standard Open Source di basarsi sui sorgenti non puo' funzionare completamente nel nostro caso.

[c'era una parte qui che avevo tolto per evitare polemiche ]

Per quelli che sono ancora al lavoro:

Voi sapete che questo progetto necessita di sviluppatori e, IMO, se non di una scadenza - per filosofia - almeno di un post-it appiccicato al monitor dove sono messi i punti base; in breve: "un piano".

Dimentichiamoci per un momento delle conversioni: io penos che AROS necessita di essere finito e aggiustato per bene. Ci sono ShinkurO e altri (presenti e futuri) sviluppatori che si lamentano delle classi MUI che sono buggate e in certi casi incomplete; io stesso, mentre sto scrivendo una recensione del sistema, mi trovo frustrato dalla mancanza di feedback del cursore; LUA funziona ma Zulu non implementa del tutto le classi MUI nel caso qualcuno decidesse di usarlo per nuove applicazioni, non solo per convertire giochi (grazie to Mazza per il suo tentativo di portare SDLbasic).

[fine della parte tolta]

Mi sento emotivamente coinvolto con questo progetto e condivido con Paolone l'opinone che ha molto piu' potenziale di quel che altri qui possono pensare. Percio' cerchiamo di lavorare in sinergia e preparare il campo anche per i nuovi sviluppatori piu' che possiamo.

Questo il mio personale messaggio alla comunita'; non voglio vedere AROS andare giu', l'ho gia' detto in passato e continuero' in futuro.

Da parte mia il mio contributo attualmente si sta concretizzando nell' aiutare ShinkurO nella traduzione del suo corso di programmazione insieme a TADsince1995 e nello scrivere la recensione di AROS per un magazine, per quanto queste ultime attivita' vanno avanti in tempi morti causa del mio continuo impegno lavorativo.

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