.
Annunci online

Tutto quel che puo' venire in mente a un italiano che si e' sposato e spostato in california
15 maggio 2009
Diario: Tecnologie:AROS: Open Source: la dura e sconnessa strada per l'1.0...
Prima di tutto un grazie a quelle persone che leggendo questo blog mi hanno fatto raggiungere un semplice ma per me importante traguardo: quello dei 10000 lettori totali, anche se ci e' voluto circa un anno e mezzo. Grazie ancora a tutti voi!

Mi sono dovuto assentare per un po' dalla scena blog in quanto il mio laptop principale era stato messo in mal arnese da un virus ed ho dovuto riformattare e reinstallare il sistema operativo: ulteriore (sgradita) sorpresa e' il trovare che i DVD di backup che avevo fatto paiono non funzionare bene e quindi il mio drive virtuale di AROS potrebbe non essere recuperabile, fortuna che per lo script in lua lavoravo sotto windows e ho copie dello stesso su SD card.

Anche se Przemyslaw "Qus" Szczygielski ha aggiustato il suo pannello di controllo TCPPrefs per AROS, questo non significa che io debba abbandonare il mio progettino: i problemi al mio computer mi hanno fermato per un po' ma sono pronto a continuare; se non altro il relativo thread in aros-exec spero abbia valenza didattica sul come cominciare un progetto in Amilua. In caso e' mia intenzione di postare un tutorial quando avro' un po' di tempo.

Attualmente l'interfaccia utente e' stata impostata; i post di mazze e i vari tutorial sulle regular expressions mi hanno messo in grado di parsare i files di configurazione e di fare copie di backup degli stessi (per ora attraverso un leggi file originale e scrivi in un file copia); cosa mi manca? Primo, di poter impostare la casella a discesa sulla scheda di rete attuale una volta letta la configurazione e secondo di salvare la configurazione stessa con le modifiche da me apportate. Poi, se proprio volessi sggiungere una spruzzata di autocompiacimento, una voce di menu con l'about ;)


La mia applicazione-test configIP e parte del debug output

Una volta finito questo pannello, mi piacerebbe provare a scrivere qualcosa per settare il calendario di Amistart, uno dei pochi widget che abbiamo e che dovrebbe servire come esempio per scriverne altri, cosa che pero' al momento non avviene, oppure magari scrivere una applicazioncina semplice per una gestione rudimentale dei bookmark per OWB, anche se al momento pare non esserci modo di far aprire ad OWB un nuovo indirizzo tramite getURL, e lanciare OWB con la url come parametro si puo' fare solo per lanciare il programma, non per lanciare altre url di seguito a meno di non chiudere la sessione corrente, provato proprio ora....

All'inizio del mese ho aiutato a redigere lo status updarte del sito di AROS e ho detto che i progressi dei mesi scorsi hanno portato il sistema molto vicino alla soglia dell'utilizzo quotidiano; per arrivare a un reale utilizzo quotidiano pero' ci sono ancora diverse cose da affrontare e risolvere, sia dal punto di vista della disponibilita' del software sia da l punto di vista della stabilita' ed affidabilita' del sistema; Neil Cafferkey continua a lavorare sulla ata.device; essendo questo un componente critico di AROS, ogni volta che ci vengono messe le mani c'e' sempre il rischio concreto che qualche cosa non funzioni piu' come prima e, soprattutto, una volta aggiustato per bene, che ci si chieda come cavolo facesse a funzionare decentemente prima, ma andiamo con ordine.

Un patch aggiornato di ata.device era stato fornito con Icaros Desktop 1.1.1 ma l'aggiornamento era stato provvisoriamente rimosso da Paolo Besser in quanto provocava problemi seri su computers con scheda southbridge AMD SB600 o con architetture simili; nei quali la scrittura al disco ne rovinava la partizione; oltre a questo altri utenti si trovavano a vedere il solo puntatore con schermo nero; per questi la soluzione e' un pochino meno drastica; traduco dal sito di Icaros Desktop:

Se non potete fare il boot di Icaros e la fase di boot si ferma dopo che il puntatore e' apparso sullo schermo, per favore eseguite la seguente procedura per risolvere il problema:
  • accendete il PC;
  • scegliete una risoluzione dal menu di GRUB ma NON premete Enter;
  • invece premete 'E';
  • portate il cursore dopo la stringa "ATA=32bit" e cambiatela in "ATA=nodma" o "ATA=nopci" (a seconda di cosa funziona meglio sulla vostra macchina)
  • quindi premete CTRL+X per continuare la fase di boot;
Se la fase di boot ha successo aprite il file /boot/grub/grub2.cfg con l'editor di AROS, cercate per la stringa "ATA=32bit" e rimpiazzatela con "ATA=nodma" o "ATA=nopci". Puo' essere fatto facilmente usando la funzione "sostituisci" nel menu "Ricerca" dell'editor.

Parallelamente a questo, in risposta al problema esposto da Paolo Besser, Neil Cafferkey risponde sulla mailing list degli sviluppatori in questo modo:

Penso di aver trovato la causa di questi problemi: non vengono settati i registri temporizzatori (timing registers) del controller.

Suppongo che quando DMA funzionava *correttamente* nelle vecchie versioni del driver era solo per coincidenza? ata.device resettava il modo del drive precedentemente settato dal BIOS e quindi non c'era bisogno di cambiare i registri temporizzatori.

Se vogliamo usare un drive in un modo che non e' stato settato dal BIOS, dobbiamo settare i registri temporizzatori in modo che si sincronizzino con quel modo. Sfortunatamente, non c'e' uno standard comune per questi registri temporizzatori, e questo spiega il perche' ad esempio Linux possieda numerosi drivers PATA: uno per Intel, uno per ATI, uno per Silicon Image,ecc.

Questo problema probabilmente si e' accentuato a causa del fatto che la nuova versione del driver legge i registri di rapporto del cavo per determinare se un cavo a 80 fili - necessario per la modalita' ad alta velocita' UDMA - viene correntemente utilizzato. Il mio errore e' stato di presumere che tutti i controller PCI seguissero le specifiche T13 per questi registri, ma mi sarei dovuto ricordare del fatto che le specifiche sono state pubblicate solo recentemente, nel 2003. Le specifiche T13 sono implementate da Intel (e io possiedo solo macchine ed emulatori con il chipset Intel su cui fare i miei test) e io sosp[etto che le specifiche T13 non sono altro che il design finora utilizzato da Intel. Altri produttori hanno registri del controller incompatibili con questo.

Da cio' deriva che su dei controller non-Intel il driver determinera' scorrettamente che sono installati solo cavi a 40 fili e ridurra' il modo DMA da, diciamo, UDMA5 a UDMA2. Siccome la temporizzazione e' ovviamente sbagliata ecco che la corruzione dei dati e' inevitabile.

Come soluzione, almeno nel breve termine, propongo che ata.device non cerchi di settare un modo per ogni drive ma semplicemente rilevi e usi il modo gia' settato dal BIOS. Spero solo che questo non porti a un forte degrado della performance in molti casi: nel mio test sembra che i BIOS delle macchine piu' moderne siano gia' in grado di settare da soli il modo piu' adatto per ogni drive per default. Questa fix e' gia' testata in locale da me, inoltre ci stiamo gia' appoggiando al BIOS per settare gli indirizzi delle schede PCI e abilitare il bus-mastering quindi questo e' solo una cosetta in piu'.

Nel lungo termine invece dovremmo cercare di settare i temporizzatori da soli, ma questa pare essere una procedura complessa e probabilmente non porterebbe a nessun miglioramento di performance nella maggior parte dei casi.

Per aiutare a confermare la mia teoria, ho settato uno dei dischi del mio PC in modo MDMA via bios invece che UDMA, ed ata.device non e' riuscita ad accedervi dopo aver settato il drive in modo UDMA2. H funzionato perfettamente, invece, dopo che il BIOS ha settato il disco come UDMA (attualmente UDMA1 ma comunque abbastanza simile da non causare errori).


Una volta aggiustato ata.device l'aggiornamento 1.1.1 di Icaros e' stato di nuovo reso disponibile.
Paolo sul sito ha espresso come, nonostante lui stia cercando di fornire la massima stabilita' per quel che riguarda le librerie di sistema e i programmi supportati, possa capitare che certe cose non vengano testate a fondo, anche perche' non e' possibile farlo su tutte le configurazioni hardware; Paolo inoltre assicura come, nonostante l'attuale incidente, la situazione sia anche migliorata visto che ora AROS riesce ad avviarsi su macchine in cui finora non aveva mai funzionato e come i danni siano stati fortunatamente limitati anche dal fatto che gli utenti sono consci della natura ancora beta di AROS e cercano di prendere piu' precauzioni possibile visto che nei sistemi open source questo tipo di inconvenienti, senza andare a scomodare Linux e i suoi guasti, siano non dico frequenti ma accadono.

Recentemente Neil ha anche aggiustato altri problemi di ata.device, compreso il come ata.device sia stata convinta della presenza di due lettori DVD nel caso si usasse un lettore via SATA. Altri piani comprendono il cambio del sistema di numerazione delle periferiche dato da ata.device

 Attualmente Neil sta controllando la gestione DHCP che tende a bloccarsi e occupare la CPU al 100% in caso AROSTCP venga interrotto da comando CTRL-C o dal comando shell arostcp stop.

In parallelo Michal Schulz ha lavorato per accelerare la resa grafica sotto ATI Radeon, la scheda grafica che usa con Efika; Sia Michal che Kalamatee hanno appurato come il disegno dei temi rallenti notevolmente il refresh del Wanderer, cosa che su una scheda come la Efika viene avvertita particolarmente; Michal ha lavorato alacremente per accelerare le varie operazioni di redraw del display e i risultati su schede ATI Radeon,sia sotto Efika che sotto x86 sono notevoli: a dire di Nikos, tester dei driver, le prestazioni sotto x86 sono migliorate incredibilmente; Kalamatee, oltre a lavorare per migliorare Wanderer come gia' descritto in articoli precedenti, stava meditando di chiedere che gli venisse assegnata la bounty per ridisegnare il Graphic Subsystem, ma al momento non si sa niente di piu' su questo.

Infine da segnalare un avvenimento raro nell'attuale panorama amighista: con uno sforzo congiunto utenti di Amiga OS, MorphOS e AROS hanno partecipato a raggiungere il goal dei 4000 dollari per la Poseidon USB bounty: Anche grazie all' iniziativa individuale di un membro della comunita', che si e' offerto di raddoppiare le contribuzioni ricevute, l'attuale quota e' di 4170 dollari. Chris Hodges ha iniziato a lavorare al port, il cui sorgente verra' aperto e offerto con la APL license e questo permettera' anche agli altri sistemi amiga-like di fare i propri port ed estensioni dello stack.

A coloro al di fuori delle comunita' amighiste probabilmente il concetto di bounty e' sconosciuto, visto che sistemi quali Linux per i progetti piu' importanti ricevono donazioni da parte di quegli enti, commerciali e in qualche caso governativi interessati nella prosecuzione e mantenimento degli stessi; invece per comunita' molto piu' piccole, quali quelle Amiga MorphOS ed AROS il sistema delle bounty rappresenta il maggior canale (pressoche' unico per AROS) di finanziamento; quindi appartengono ancora di piu' alle comunita' stesse, essendo le comunita' stesse anche enti sovvenzionanti, un po' come le cattedrali del medioevo.

Un ultima parola a proposito del portale Aros-exec: venerdi 22 Maggio il portale era stato ancora una volta chiuso a causa del reiterarsi di un exploit malefico: questa mattina il portale e' di nuovo in linea, con una nuova versione di xoops patchata contro gli exploit e con un nuovo tema grafico.
Nonostante questo, ricordo che Aros-exec e' principalmente orientato agli sviluppatori piuttosto che agli utenti; per questi ultimi continuo a consigliare di rivolgersi in Arosworld.org.
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
25 ottobre 2008
Tecnologie:AROS: un livello piu' alto di coinvolgimento
Non uno dei piu' profondi post oggi, magari direi piu' un post di mantenimento...

Contribuire a un progetto open source e' - o almeno dovrebbe essere - anche un momento di socialita': piu' persone lavorano insieme nel loro tempo libero a un comune interesse. La cosa si fa un pochetto piu' complicata quando le persone sono disseminate nello spazio di svariate migliaia di chilometri tra america, europa ed australia.

Diciamo la verita': se non esistesse internet non esisterebbero le comunita' open source, o almeno non sarebbero cosi' tante e diffuse come lo sono adesso.

Gli strumenti di collaborazione sono sicuramente meno evoluti di quelli che si potrebbero trovare dentro ad una realta' commerciale, ma neanche tanto: ho usato svn e vim in un recente progetto ed eclipse in un altro; comunque, molti dei problemi di comunicazione di solito si risolvono tramite messenger ed IRC.

Per quanto IRC sia probabilmente considerata dalle nuove generazioni "out", si rivela ancora un interessantissimo strumento per parlare in gruppo.

Cito IRC in quanto nelle ultime due settimane ho avuto modo di scoprire le velleita' "ircose" di Pidgin e Miranda e mi sono potuto collegare al canale ufficiale di AROS: ho quindi visto "cose che voi umani non potete neanche immaginare", se vogliamo esser banali e citare Blade Runner.

Fa un certo effetto parlare direttamente con alcuni dei piu' importanti sviluppatori di AROS quali Michal Schulz, Maag^Da, Stanislaw Szymczyk e gli altri.

Vedere Maag^da presentare in anteprima il nuovo Autodoc per AROS e avere Szymczyk e Schulz raccontare "live" degli sviluppi sulle loro bounties (tra parentesi:Congratulazioni Stanislaw,  la bounty e' quasi finita!) e scambiare con loro idee ed opinioni, nonostante non siano ormai piu' da tempo concetti nuovi e nonostante io non sia un gran frequentatore di IRC ma prima del periodo attuale ci ho bazzicato un po' e' un passo avanti rispetto all'essere solo frequentatore di forum e avido lettore di notizie: fa crescere la voglia di partecipare attivamente.

Ho scaricato LUA per PC e cominciato a dare un occhio anche a SDLBasic, sapendo che Mazze  sta cercando di portarlo anche su AROS (senza successo per il momento). Ho finalmente raccolto alcune idee per eventuali applicazioni che vorrei realizzare, non utilities di primissimo piano ma pur sempre applicazioni.

[edit: azz, leggendo la documentazione zulu e' a un livello abbastanza basso, spero di capirci qualcosa; cmq visto che devo iniziare dalle basi magari ci capiro' qualcosa di piu' in seguito...]

Sto anche cercando di capire come fare qualche tema personalizzato per le finestre; appena risolvo il problema di far comunicare la mia aros-box virtuale con la rete.
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