A colloquio con:
Jacek Rzeuski
A cura di Francesco Celli e Gabriele Favrin
Articolo pubblicato su Amiga Life 113 (aprile 2000)
Nota bene: l'articolo proposto in questa pagina è
proprietà degli autori e non può essere distribuito o
riutilizzato in alcun modo o forma senza il loro consenso scritto.
Le informazioni qui riportate risalgono alla data di pubblicazione
dell'articolo e non è detto che siano ancora valide o
che rispecchino lo stato attuale dei programmi, le posizioni delle persone
interpellate o degli autori stessi.
Contenuti
Introduzione
Jacek Rzeuski è un nome che forse non risulterà familiare a molti, se si eccettuano i fan dell'overclocking estremo, ramo nel quale è considerato la bibbia vivente. Eppure questo personaggio gode di una popolarità crescente da quando ha preso in mano e sta aggiornando con successo i sorgenti di Directory Opus 4, forse il più celebre programma Amiga, recentemente rilasciati come GPL.
Intervista
D: Ciao, Jacek Fino a poco tempo fa il tuo nome non era fra i più conosciuti nella comunità Amiga. Cosa hai fatto prima di approdare a Directory Opus? Come hai iniziato e da quando usi Amiga?
R: Innanzitutto tengo a precisare che Directory Opus 4 non è
un mio progetto. Ne ho solo aggiornato i sorgenti, rilasciati sotto
licenza GPL da GP Software. Ho realizzato anche altri programmi, a
scopo personale o di studio. Tra quelli rilasciati su Aminet posso
segnalarvi: Win2Front, una semplice commodity per "esplorare" le
finestre aperte sul WB, MUI_Frecell, un solitario basato su MUI,
ispirato alla controparte per Win95, e WOSPrefs, un programma di
peferenze per WarpOS, Warp3D e StorMESA.
Ma non è tutto. Dovrei terminare un editor di livelli per il
noto gioco strategico HistoryLine 1914-1918. Attualmente sto
partecipando allo sviluppo di Myzar, una GUI per il client RC5. Nello
specifico mi occupo dell'implementazione di un grafico della
velocità che, in un prossimo futuro, diverrà una
classe MUI con supporto esteso a più CPU (PowerPC incluso).
Ho anche scritto un programma di preferenze per "Heretic Fortress", un
modulo aggiuntivo di Heretic 2. Il progetto è completo ma
ancora non rilasciato pubblicamente.
D: Navigando nella Rete abbiamo scovato tuoi interventi dai quali si desume una certa familiarità non solo con il software ma anche con l'hardware, in particolare le schede BVision. Hai dei suggerimenti da dare ai lettori di Amiga Life riguardo a moltiplicatori, quarzi e alimentazione?
R: Sì, mi interesso anche di hardware. Mio padre
è specializzato in elettronica e, a volte, l'ho aiutato nel
suo lavoro. Ho iniziato ad usare il saldatore a sette anni, ero molto
attratto dall'elettronica dei computer e spesso "giocherellavo" con i
miei Amiga sotto lo sguardo vigile di mio padre (che allora lavorava
presso un centro Commodore). Così, non potendo resistere
alla tentazione di mettere le mani anche sulle BlizzardPPC, ho
prelevato dai siti di Motorola e Cypress (il produttore dei chip dei
controller SCSI, NdR) tutta la documentazione di CPU e chip.
Cercando di risolvere i problemi legati ad alimentazione e
surriscaldamento, sono riuscito anche ad approfondire le metodiche di
overclock delle BlizzardPPC, ricavandone informazioni che che sono poi
state pubblicate su mailing list e web. Ciò che ho dedotto
dalle molte discussioni sull'argomento è che le schede con
maggiori problemi sono quelle con '040/25: il voltaggio del connettore
di alimentazione della ventolina non deve essere inferiore a 4.85V. Un
voltaggio più basso, probabilmente non gradito dai chip
della RAM, potrebbe provocare dei blocchi accidentali di sistema. Tutto
ciò si manifesta generalmente con l'aggiunta della BVision,
che prende l'alimentazione proprio dalla BlizzardPPC causando cali di
tensione. Ma quello dell'alimentazione, in realtà, non
è il solo problema. Infatti, dopo l'inserimento della
BVision, ho iniziato a riscontrare dei blocchi di sistema provocati
dall'eccessivo surriscaldamento del chip che gestisce la logica posto
sotto la ventolina del PPC. Così, dopo aver sostituito la
ventolina originale con una per Celeron, ho deciso di progettare un mio
sistema di raffreddamento e di inserire tutto in un PowerTower (non
Mikronik). Questi suggerimenti sono stati utili ad altre persone anche
se, in teoria, basterebbe collocare una lamiera tra il chip incriminato
e la ventolina originale. C'è anche da dire che il
Permedia2, per un uso prolungato, ha bisogno di un'ulteriore
ventilazione. DCE, a conoscenza della questione, munirà le
nuove BVision di dissipatore.
D: Parliamo di Directory Opus 4. Quando hai deciso di occupartene e perché?
R: Ho preso questa decisione subito dopo il rilascio dei sorgenti. Uso
Directory Opus 4 abitualmente, ma era necessario apportare alcune
modifiche alla versione attuale, che contiene molte parti di codice
anteriori all'OS2.0. Il supporto a sistemi RTG, ad esempio,
è quasi nullo.
Molti dicono che stia perdendo il mio tempo e mi consigliano di passare
a Directory Opus 5: è una questione di gusti. Sono abituato
al tipico "filemanager" suddiviso in due finestre. Ho provato
più volte, ma senza esito, a passare a Directory Opus 5.
Il riscontro inaspettato che ho ottenuto con il rilascio della prima
versione mi ha fatto molto piacere e mi ha realmente stupito in quanto
non pensavo che Directory Opus 4 avesse ancora tanti seguaci! Insomma,
tutto ciò è uno sprone a proseguire il mio lavoro.
D: Si sa, interpretare codice scritto da altri è quasi più difficile che crearne di proprio. Che approccio hai usato per comprendere i sorgenti di Directory Opus?
R: Sì, è difficile, specialmente se i sorgenti non sono commentati, come nel caso di Directory Opus 4. Le difficoltà, poi, aumentano a causa del pesante utilizzo di variabili globali, che vengono definite in un sorgente e referenziate e modificate in un altro. E' veramente arduo tenerne traccia e capirne il significato. I sorgenti, inoltre, sono molto grandi: solo quello relativo al programma principale occupa 1 MB. Introdurre delle modifiche significa dover rintracciare il codice inerente e cercare di comprenderlo a fondo. Senza farlo, non è possibile prevedere come quel particolare cambiamento influenzerà il funzionamento del resto del programma. Ad esempio, tornando alle variabili globali, è necessario individuare tutte le chiamate al codice modificato e analizzarle. Alcuni, lamentandosi della lentezza con cui lo sviluppo procede, mi dicono: "ehi, cambia solo questa linea di codice e funzionerà". Probabilmente sarà pure così, ma qualcosa potrebbe non andare o smettere di funzionare correttamente. In questo modo, come risultato, otterrei un solo utente soddisfatto e dieci (o più) persone che si lamentano. Per questo, prima del rilascio pubblico, tutti i cambiamenti apportati vengono discussi sulla mailing list e testati a dovere.
D: Hai incontrato difficoltà impreviste durante questi primi mesi di sviluppo?
R: Sicuramente. Ho deciso di compilare i sorgenti usando il GCC
perché ho cancellato la mia copia illegale del SAS/C molto
tempo fa. Il GCC è migliore del SAS e, cosa importante,
è ancora sviluppato. Purtroppo, però, i sorgenti
preparati con quest'ultimo vanno ritoccati prima di poter essere
compilati con il GCC (alcune direttive degli include non sono
compatibili, così come non lo sono tutte le chiamate a
funzioni che usano specifiche per l'indiririzzamento diretto dei
registri, ad esempio gli hook) e, inoltre, ho dovuto rendere
compatibili gli include del GCC per via della dopus.library e di altre
librerie usate.
Le parti scritte in assembly hanno costituito un'ulteriore
difficoltà: il GCC non riconosce tali porzioni di codice e
ho dovuto cercare un assemblatore esterno. La scelta è
caduta su PhxAss in quanto è freeware, ancora supportato e
non aveva problemi nella compilazione dei sorgenti. Quantunque non
abbia mai usato un assemblatore, devo ammettere di aver imparato molte
cose leggendo la documentazione di PhxAss.
Il problema finale è stato quello di effettuare il link di
tutti i sorgenti e generare l'eseguibile vero e proprio. A questo punto
si è presentata un'ulteriore magagna: una parte di dati
destinata alla CHIP veniva posta nella memoria pubblica (Fast, ndr),
causando errori nella visualizzazione di alcuni gadget su sistemi privi
di scheda grafica o del patch FBlit. Senza poi dimenticare la prima
versione che aveva problemi di stack se lanciata da CLI. Devo comunque
dire che tutte queste difficoltà erano semplicemente causate
dalla mia iniziale inesperienza nell'utilizzo del linker.
D: Sappiamo che ci leggono molti programmatori, persone che magari vorrebbero seguire le tue orme e prendere in mano altri programmi di cui sono disponibili i sorgenti. Che consigli daresti loro?
R: Non aspettatevi che sia una cosa facile. La legge di Murphy sostiene che ciò che sembra facile è difficile e ciò che sembra duro è impossibile. Ma non fateci troppo affidamento, molto dipende dal codice. Ad ogni modo il mio suggerimento è quello di non effettuare conversioni per Amiga da altre piattaforme se non si ha una grande conoscenza di ambedue i sistemi. Riprendere lo sviluppo di applicazioni Amiga già esistenti è più facile, ma bisogna essere preparati al fatto che la comprensione del codice altrui non lo è. Molti imparano la programmazione scrivendo applicazioni e capita che utilizzino soluzioni assai bizzarre. Quando riguardo le mie prime creazioni mi è difficile credere che sia stato proprio io a scriverle. Senza contare che molto spesso capita che programmatori esperti scrivano un codice di difficile comprensione. Ma mai lasciare nulla di intentato! Anche se l'esperimento non dovesse andare a buon fine c'è sempre qualcosa da imparare.
D: Quali progetti hai per Directory Opus al momento? Magari l'implementazione di un client FTP simile a "OpusFTP" di Magellan o qualche altra funzionalità analoga? E, oltre a Directory Opus, pensi di prendere in mano altri progetti simili?
R: Attualmente Directory Opus ha un ottimo supporto ARexx, che credo
sia possibile sfruttare per l'implementazione di funzioni FTP.
Purtroppo non ho mai imparato la programmazione ARexx, sebbene ci abbia
provato.
Alcune persone mi chiedono di rendere Diretory Opus 4 simile a
Magellan. Beh, non credo che lo farò. A chi ricerca in
Directory Opus 4 le stesse funzionalità di Magellan, come la
possibilità di usarlo in alternativa al WB, suggerisco di
acquistare Magellan stesso. Modifiche tali richiederebbero una totale
riscrittura, come ha fatto anche GP Software abbandonando lo sviluppo
di Directory Opus 4.
Riguardo quest'esperienza posso dire di aver acquisito conoscenze di
cui farò tesoro in futuro. Sfortunatamente, per quanto
concerne l'eventualità di dedicarmi ad altri progetti
simili, la cronica mancanza di tempo che mi affligge mi costringe a
lavorare su questi programmi (e sulla continuazione di Directory Opus)
nei soli momenti liberi. Nonostante ciò sono sempre
disponibile ad offrire il mio aiuto ad altri programmatori che ne
avessero bisogno.
Indirizzi utili
- Informazioni sui vari tipi di licenze GNU fra cui la GPL
- Il produttore di Directory Opus
- Home page degli aggiornamenti di Dopus effettuati da Jacek Rzeuski
Gli indirizzi pubblicati sono stati verificati ed aggiornati a maggio 2019.