Perché MySQL è Male per il Software Libero

Introduzione

Questo breve articolo vuole essere un semplice parere sul motivo per il quale trovo che la dipendenza da MySQL non faccia assolutamente bene al software libero, ma, anzi, a lungo termine porti a nuocere gravemente per la nostra libertà.

Innanzitutto analizziamo cos’è MySQL e come è legato al software libero: si tratta di un software per la gestione di database (DBMS) rilasciato sotto licenza duale GPL e non libera. Grazie a questa doppia licenza, chiunque sia interessato all’uso di MySQL in un ambiente libero od OpenSource può utilizzarlo sotto i termini della normale licenza GPL, mentre chi lo volesse utilizzare per scopi non liberi può acquistare la licenza d’uso dai proprietari del software (MySQL AB), e quindi evadere le restrizioni poste dalla licenza GPL (che come tutti sappiamo è «infettiva»).

Tale licenza viene erroneamente dichiarata da MySQL AB come licenza commerciale, in realtà non è esatto chiamarla in questo modo, poiché un software libero può essere allo stesso tempo commerciale. Tale licenza sarà dunque chiamata in questo articolo come licenza non libera, che rende meglio l’idea sull’uso che viene effettivamente fatto di tale licenza. Similmente, la licenza GPL viene definita da MySQL AB come licenza opensource, ma anche questo è il termine sbagliato, essendo la licenza GPL una licenza libera, mentre una licenza OpenSource può non essere libera.

Quindi un software libero, scritto sotto licenza GPL o GPL-compatibile, può utilizzare MySQL secondo la licenza GPL come per un normale software libero. Invece un software proprietario, volendo utilizzare MySQL o i driver per la connessione ad un database MySQL, deve acquistare una licenza da MySQL AB. Un’eccezione viene fatta per il software OpenSource (o libero e GPL-incompatibile), rendendo quindi MySQL una scelta facile per chiunque lavori su soluzioni libere e OpenSource.

Innanzitutto vorrei sottolineare che MySQL non è assolutamente il miglior DBMS presente sulla piazza: attualmente non supporta a pieno titolo le linee guida per i database relazionali, cosa che ne limita molto le funzionalità paragonato a prodotti proprietari quali Oracle o SQL Server. Ma non si tratta dell’aspetto tecnico che voglio parlare ora, poiché su quello è possibile parlare a lungo, ma richiederebbe una conoscenza più approfondita del vero e proprio lavoro sui database stessi.

Effetti della licenza duale

MySQL è male per il software libero per un motivo abbastanza semplice in realtà: la sua licenza duale. Prendiamo un attimo in mano il concetto stesso della licenza duale: utilizzando tale licenza è possibile evadere l’infettività della licenza GPL, infettività nata per preservare la libertà del software a cui viene applicata: ogni lavoro derivato deve essere a sua volta distribuito secondo la licenza GPL. Mentre, nel caso di lavori derivati per i quali sia stata acquistata una licenza non libera da MySQL AB, non è più necessario distribuire il prodotto finale sotto una licenza libera.

Ma se questo può essere scocciante per i puristi del software libero, non è ancora il punto a cui voglio arrivare. Per poter utilizzare questa licenza duale, MySQL AB deve risultare essere la detentrice del copyright di tutto il codice di MySQL, perché solo il detentore del copyright per un software può includere eccezioni alla licenza del proprio software (o appunto usare una licenza duale). Questo porta al primo problema: se uno sviluppatore esterno vuole contribuire, è costretto a cedere il copyright del proprio operato a MySQL AB, altrimenti le modifiche non verranno mai apportate al codice sorgente originale. Se una cosa simile già avviene in altre situazioni (per esempio gli script di installazione di Gentoo, e il software del progetto GNU), solitamente si tratta di fondazioni che mantengono il codice libero. Nel caso di MySQL AB non è così, perché il codice di cui si cede il copyright viene poi rivenduto con la licenza non libera.

A questo punto il povero sviluppatore esterno ha tre strade principali:

  1. Fornire la patch – File contenente le differenze tra il codice originale e il codice modificato – a MySQL AB cedendone il copyright: la patch sarà applicata al codice sorgente originale, e sia la versione libera che quella non libera potranno usufruire delle correzioni o delle nuove feature aggiunte dalla patch stessa.

  2. Fornire la patch solo sotto licenza GPL, e sperare che le distribuzioni continuino ad applicarla da quel punto in avanti: questa non sarà applicata al codice sorgente originale, perché impedirebbe a MySQL AB di rivendere il codice sotto la licenza non libera. Nel caso le distribuzioni la applicassero, i binari delle distribuzioni saranno generati da sorgenti diversi rispetto a quelli dei binari della versione non libera.

  3. Non rilasciare affatto la patch, ignorare la necessità di usarla e scegliere altre vie (come per esempio cambiare database, o semplicemente non fare uso di quella particolare funzionalità).

Generalmente sono due i casi in cui non si è disposti a fornire la patch a MySQL AB: o si è puristi del software libero, e quindi non si vuole vedere MySQL AB fornire il proprio codice in licenza non libera, oppure si è più pratici e materiali, e si decide che non si vuole vedere MySQL AB fare soldi sul proprio codice.

Qualsiasi sia la ragione, a prima vista la terza soluzione è quella che provoca più danni per la comunità (se nessuno rilasciasse patch, tutto il codice ristagnerebbe), ma in realtà a mio avviso la seconda ha un’implicazione anche peggiore, a lungo termine.

Se le distribuzioni cominciassero ad applicare patch e sovra-patch a MySQL, il binario rilasciato potrebbe diventare incompatibile tra una distribuzione e un’altra, tra una versione e l’altra, fino al punto in cui i sorgenti originali e quelli modificati dalle distribuzioni saranno completamente diversi, rendendo praticamente impossibile un valido uso di MySQL su larga scala, perché funzioni che sono presenti in una determinata versione con le aggiunte di una distribuzione potrebbero non funzionare sulla stessa versione modificata da un’altra distribuzione, o potrebbero comportarsi in modo lievemente o parzialmente diverso.

Solitamente quando gli utenti finali si ritrovano a dover applicare talmente tante patch al codice sorgente originale da cambiarne buona parte del funzionamento, gli sviluppatori di tali patch cominciano a raggrupparsi per decidere cosa fare: mantenere le patch separatamente può diventare un gran problema, perché il codice modificato da una, potrebbe venire modificato da una seconda, e quindi ci si troverebbe ad avere dipendenze interne tra le patch, che comporterebbero un effetto domino se venisse cambiato il codice originale. Per risolvere questo la maniera più pratica è quella di fare un fork: rilasciare un nuovo programma, solitamente con un nome diverso o modificato rispetto a quello originale, che segue quindi una via di sviluppo sua propria.

Il problema di questa soluzione però è che di nuovo si pone un bivio: se lo sviluppo procede per la sua strada, senza più seguire lo sviluppo del programma originale, si arriverà presto al punto di avere due ambienti diversi, e chi continuerà ad usare MySQL si ritroverà di nuovo nell’identica posizione di prima. D’altro canto, se gli sviluppatori continueranno a seguire lo sviluppo di MySQL, applicando programmaticamente tutti i cambiamenti apportati alla base di codice originale, MySQL AB potrebbe decidere di smettere di supportare la versione libera di MySQL, e di proseguire il solo sviluppo della versione non libera, togliendo alla comunità uno dei software che -purtroppo, a mio avviso- è diventato cardine nello sviluppo del web libero.

La ragione per cui mi è venuto in mente questo ragionamento è stata la notizia che db4objects, Inc. ha rilasciato il proprio prodotto di punta (un altro database, orientato agli oggetti stavolta), con una doppia licenza (libera e non libera) del tutto simile a quella di MySQL AB.

Questa tendenza a lungo termine può portare all’assottigliamento del software veramente libero, fino al ritrovarsi del software che viene spacciato per libero ma in realtà non lo è. A quel punto saremmo costretti a scendere a patti col software proprietario fino ad avere del software -quasi- libero.

Soluzioni

Possiamo fare qualcosa per evitare ciò? Beh perlomeno ci si può provare: esistono altri database liberi, oltre a MySQL, db4o e Firebird — la versione libera di Borland Interbase, rilasciato sotto licenza MPL 1.0, quindi già meno subdolo. PostgreSQL è uno di questi.

Uno dei problemi maggiori nell’uso di questi database è che non tutti i software, specialmente le web application scritte in PHP, non forniscono supporto a database diversi da MySQL. Se siete dei programmatori PHP, e state utilizzando una web application che supporta solo MySQL, provate a pensare se riuscireste ad aggiungere il supporto a PostgreSQL o altri database liberi a tale applicazione. Se siete dei semplici webmaster che utilizzano delle web application che supportano solo MySQL, provate a cercare degli equivalenti che possano usare anche PostgreSQL o altri database liberi. Anche nel caso in cui non possiate fare altro che usare MySQL per qualsiasi ragione, evitate le applicazioni che possono usare soltanto MySQL, in questo modo saranno più invogliate a supportare database alternativi.

L’altro maggiore problema è il fatto che la maggior parte degli hoster web forniscono solo spazio con database MySQL, e sono veramente rari quelli che forniscono a richiesta un altro database libero. Questo comporta la necessità di usare in ogni caso MySQL e di consequenza molte applicazioni che vengono scritte per lavorare su questi hoster vengono scritte solo per MySQL. Quindi se siete hoster, pensate a fornire a richiesta un altro database libero su cui lavorare. Invece se siete in contratto con un hoster che non fornisce altro che MySQL, domandegli se è possibile avere il supporto a database alternativi.

Non è affatto mia intenzione iniziare una di quelle campagne di boicottaggio, perché credo che ognuno sia libero di scegliere gli strumenti di cui ha bisogno, o di usare quelli che ha a disposizione. Vi chiedo soltanto di pensarci, e di guardare se potete fare qualcosa per limitare il problema.

Ringraziamenti

Desidero ringraziare, per i commenti e i consigli durante la stesura di questo articolo, Riccardo “mala” Furlan, Alberto “Albertoz” Zennaro e Isaac Rallo

Inoltre voglio ringraziare Stefano “SnoopyX” per avermi aiutato a capire come riscrivere l’articolo in LaTeX.

Proteggiamo i DVD

Come sapete sono un patito dei film in DVD, perché è possibile guardarli in lingua originale coi sottotitoli e sentire le vere voci degli attori, con le loro inflessioni, le loro emozioni e tutto il resto.

Per compleanno e Natale sono riuscito a farmi regalare i due cofanetti della prima stagione di CSI, per un totale di 6 DVD e 25 episodi.

Finalmente lunedì sono arrivati, e nel pomeriggio ho pensato bene di guardare il primo. Lo infilo nel lettore di Defiant, avvio Kaffeine, lancio il DVD, mi fa la solita schermata di legalese rompiscatole per 13 secondi (contati), e infine partono i loghi dei produttori.. ma che succede? Appare un popup che mi informa che non ho i privilegi per guardare il film. Ma com’è possibile? Riprovo un paio di volte e fa la stessa cosa. Se provo a skippare alla traccia successiva, Kaffeine crasha completamente.

Che fare?

Per fortuna ho sempre con me il mio fido Voyager, provo il DVD su questo, usando il lettore Apple ufficiale, et voilà, funziona. Peccato che se provo a saltare la schermata in legalese mi dica “Not Permitted”. Ok mi metto in camera a guardare i telefilm in santa pace, ma scopro con mio rammarico che i sottotitoli sono presenti solo in italiano (e non mi pongo neppure la questione che siano stati fatti bene o no, tanto so già che non saranno fatti bene.

Vabbé iniziamo. Come volevasi dimostrare i sottotitoli in italiano non riprendono correttamente le frasi in inglese. Ad un certo punto però mi stanco e per riposarmi vorrei tornare in lingua italiana. Provo a cambiare audio “Not Permitted”. Vabbé almeno tolgo i sottotitoli “Not Permitted”. Provo a muovermi tra i capitoli… “Not Permitted”….

Ora io potrei ancora ancora capire la cifratura dei DVD (ma non riesco ancora a capire il modo in cui sono assegnate le licenze per il CSS); non riesco a capire la divisione per zone, ma la rispetto; ma proprio non riesco a capire questa diamine di protezione che mi impedisce di accedere ai capitoli, di cambiare audio e sottotitoli, che mi impedisce dunque di usufruire in modo ottimale del prodotto…

Peccato che non abbia voglia ultimamente di combattere, altrimenti avrei chiamato qualche unione dei consumatori per far presente questa cosa.

Gnome Packaging

Ormai sono parecchi anni che lavoro come programmatore amatoriale, e quindi il punto di vista del programmatore già lo conosco da tempo.

Invece da un po’ di tempo mi sto dilettando anche come packager, anche se non è propriamente il caso di Gentoo parlare di packagers, visto che non si usano pacchetti veri e propri. Per chi non lo sapesse, un packager è una persona che prepara i pacchetti di installazione delle applicazioni per le varie distribuzioni.

Di solito questo significa preparare vari pacchetti a seconda delle varie impostazioni a build-time, risolvere le dipendenze (ovvero indicare quali pacchetti sono necessari per compilare od eseguire l’applicazione impacchettata), e quindi rilasciare il pacchetto.

In gentoo, il problema è ridotto, perché non esistono pacchetti precompilati, ma bisogna solo scrivere uno script che abbia indicate le dipendenze di build e di esecuzione, e nel caso ci siano delle feature abilitabili/disabilitabili a buildtime, inserire delle use-flag, che permettano appunto di abilitarle o disabilitarle a scelta.

Per fare questo, in genere basta inserire delle piccole funzioncine che vadano a richiamare ./configure con i giusti parametri.

Purtroppo non tutti i pacchetti definiscono correttamente il ./configure, non inserendo tutti gli switch per le feature opzionali, oppure inserendoli ma non “rinforzandoli”, ovvero anche se si chiede di disabilitare una determinata opzione, questa viene abilitata se viene trovato il pacchetto necessario.

Su gentoo KDE ha dei pacchetti un po’ strani, ovvero sono presenti assieme tutti i pacchetti di un determinato modulo CVS, quindi si tratta di macro-pacchetti contenenti molte applicazioni diverse. Il problema sarà risolto prima o poi, si spera.

Gnome invece ha la fortuna di impacchettare i sorgenti libreria per libreria e quindi da questo punto di vista è molto più semplice da gestire. Purtroppo però, le dipendenze di gnome sono abbastanza incasinate.

Sì perché gnome non usa metodi normali e portabili per verificare le dipendenze, come fa invece KDE, o qualsiasi altro pacchetto, ma usa invece pkg-config, a cui passa semplicemente le dipendenze necessarie.

Però se questo può andar bene per le dipendenze veramente necessarie senza cui non è possibile effettuare il build del pacchetto, per i pacchetti opzionali la cosa diventa un vero casino.

Il motivo è abbastanza semplice: se una dipendenza opzione viene attivata anche se con le flag di gentoo è stato chiesto di disabilitarla, nel momento in cui il pacchetto da cui questa dipende viene disinstallato, tutte le librerie e gli eseguibili che hanno linkato il pacchetto rimosso non possono più funzionare perché non riescono a risolvere alcuni simboli.

Per esempio a me è capitato un problema simile con arts, che non rinforza la disabilitazione di esound (pacchetto gnome). Nel momento in cui l’ho disinstallato, metà KDE non poteva essere eseguito perché era linkato ad arts che a sua volta era linkato ad esd rimosso.

Per risolvere questi problemi in genere bisogna andare a modificare lo script di configurazione per disabilitare quelle feature obbligatoriamente, oppure fornirgli un valore “cache” fasullo, in modo che lui creda che il pacchetto non c’è.

Questo funziona per tutti i pacchetti che usano le dipendenze standard. Per nota di cronaca, su KDE il problema si manifesta solo su arts.

Purtroppo Gnome grazie a pkg-config non è così semplice da prendere in giro, quindi c’è un bug aperto su Gentoo riguardo Esound necessario alle librerie Gnome, fin dal 2002. Per mio esperimento, è possibilissimo compilare le librerie gnome senza esound.

Tra le altre cose, visto che uso principalmente KDE, ho voluto rimuovere alcuni pacchetti come per esempio gnome-icon-theme e hicolor-icon-theme, nonché gnome-themes. Questi pacchetti sono relativamente le icone di gnome, delle icone generiche e i temi visivi di gnome.. tutti i temi visivi disponibili per Gnome.

Il motivo per cui ho voluto disinstallarli è abbastanza semplice: non usando gnome, ma usando gtk-qt per i pochi programmi che mi richiedono i temi gtk2, non ho bisogno né dei temi, né delle icone (gtk-qt fornisce automaticamente quelle di KDE), e quindi non mi pareva il caso di sprecare spazio per loro. Purtroppo però, c’erano dei pacchetti che volevano per forza di cose installarmele, e sono finito con il fargli dire che erano presenti anche se non era la verità.

Ieri tra le varie librerie che mi si sono presentate da aggiornare c’erano anche libgnomeprint e libgnomeprintui. La prima si è compilata e installata senza il minimo problema.. la seconda invece durante la fase di configurazione si è fermata chiedendomi di installare gnome-icon-theme (che a sua volta, tentandolo di installare, richiedeva hicolor-icon-theme). Arrabbiato da questa necessità di un tema di icone (che non può in nessun caso pregiudicare il codice compilato), mi sono insospettito e sono andato a guardare il codice del file di configurazione.

Ovviamente gnome-icon-theme era stato inserito sui check necesasri a pkg-config, e un piccolo commento subito sopra la richiesta lo classificava come ugly per mantenere i packager al loro posto, e quindi obbligarli a dipendere da gnome-icon-theme.

Questa è una vera e propria presa per i fondelli, visto che gnome-icon-theme non pregiudica alcun tipo di funzionalità in libgnomeprintui, e non dovrebbe essere necessario a questo. Per fortuna riuscire a modificare lo script di configurazione è stato abbastanza semplice, ed ho rilasciato un aggiornamento del mio ebuild pack con dentro una nuova ebuild per libgnomeprintui che non dipende in alcun modo da gnome-icon-theme.

Questo è un nuovo motivo per cui non mi piace Gnome: i developer hanno inserito delle dipendenze fasulle solo per rendere più complesso il lavoro dei programmatori e infastidire gli utenti finali che non volessero usare un ambiente 100% gnome.

Vorrei ricordare che KDE può benissimo essere usato senza arts, basta compilare tutti i pacchetti con –without-arts.

GNOME -= 1
KDE += 1

Quattro di notte

Questa è l’ora e questo è il post.
Sicuramente vi starete domandando cosa sto facnedo sveglio a quest’ora, semplicemente non riesco a prendere il sonno.

Quindi di cosa parlerò in questa entry? Beh di nulla in particolare, solamente voglio che sia un buon punto di partenza per una nuova serie di entry.

Non ho più il tempo materiale di scrivere entry su qualsiasi cosa mi accada o su qualsiasi articolo interessante trovato su slashdot o punto informatico (anche perché per i secondi non ci sono problemi, solitamente si commentano da soli, mentre per quanto riguarda slashdot, ultimamente mi sta lasciando molto a desiderare: le notizie arrivano con giorni se non anni (nel caso di OpenBGPD) di ritardo, i commenti sono sempre più stumidi e meno da nerd, e non ho sopportato i continui articoli riguardo le elezioni americane. Non me ne poteva importare di meno!

L’ultima notizia di /. che mi è interessata è stata quella sul ripoff di ReactOS, anche se pure quella era corredata dai soliti commenti stupidi che mi ricordano perché non frequento più i forum.

Anche i lavori con Hypnos vanno a rilento, principalmente perché io sto battendo la testa contro la libreria del gcc che non ne vuol sapere di funzionare a dovere, e perché Chrono e Kheru sono stanchi rispettivamente per Università e lavoro.

Negli ultimi tempi ho lavorato un po’ di più su KNetLoad e KVBA, portando tutta la parte di configurazione sul nuovo framework KConfig XT, molto bello, tra l’altro mi ha ispirato per lo script autosettings che ho scritto per Hypnos, ma anche qua i lavori vanno a rilento perché non so se ci siano già dei bindings SNMP per KDE o devo riciclare il lavoro fatto per atmosphere, per supportare la ricezione delle statistiche di KNetLoad via SNMP. Certo però quando funzionerà questo sicuramente KNetLoad potrà finalmente attestarsi ad un livello nettamente superiore a quello attuale, visto che ci sono almeno due progetti concorrenti: KNetInfo e KNemo.

Invece quello che ultimamente mi si profila per la rimozione è XMMS, che con le ultime release diventa più lento, più cpu-intensive e sempre meno integrato. Anche il semplice fatto che utilizzi GTK1 lo rende abbastanza odioso, visto che, dopo aver disattivato i bitmap fonts su xorg, non ne vuol sapere di disegnare i font con un modo decente. Inoltre quando ho a che fare con canzoni col titolo giapponese in Kanji, si rifiuta di mostrarmeli.

Purtroppo però XMMS2 e Beep Media Player sono progetti ancora troppo sperimentali, e non supportano tutti gli input plugin di XMMS, tra cui c’è musepack (MPC) in cui ho un po’ di brani. L’unico sostituto decente fin ora sembra essere Kaffeine, che usa xine come backend, ma non sono sicuro se xine-lib supporti Musepack, dovrei verificare. Purtroppo conosco veramente poco riguardo le codifiche audio/video e non credo di poter lavorare a qualsivoglia modifica per xine-lib che aggiunga il supporto a musepack.

Domani dovrò anche tentare di ripristinare il supporto al telecomando via LIRC, visto che le ebuild di gentoo funzionano sui kernel 2.6. L’unico fatto è che devo decidere se provare l’interfaccia di KDE (che si sostituisce a lircd) o no. Una volta usavo lircd perché usavo il telecomando con xmms, zapping e Xine (con xine-ui), ma se passo ad usare Kaffine anche per l’audio, visto che zapping non lo uso più potrei semplicemente usare l’interfaccia di KDE.

Devo ammettere che questa entry è abbastanza fuori dagli schemi che ho imposto negli ultimi tempi al blog, ma è stato solo un modo per mettere su schermo i pensieri che ho in questo momento da risolvere, se qualcuno ha voglia di aiutarmi nei commenti, ben venga.

Basta che il bios non decida da solo…

Qualcuno si ricorda della mia (unica) amica, e del suo problema con il BIOS del suo computer e alcuni dischi ide?

Beh è successo un nuovo problema: mi chiama l’altro giorno (buttandomi giù dal letto alle 11 di mattina -___-‘) che non le funziona più la stampante, provo a dirle di fare i controlli di rito (aka: guardato i cavi? la stampante risponde?), ma ancora nulla. Le dico di provare con un altro cavo o con un’altra stampante, ma ancora nulla.

Visto che lei non è riuscita a cavare un ragno dal buco, mi ha chiamato ieri pomeriggio per chiedermi se ero libero stamattina per andare da lei. A parte il fatto di dover essere sveglio per le 9.30 di mattina, il resto non era un problema, così rimaniamo d’accordo che viene a prendermi con sua madre e poi andiamo da lei che vedo di sistemare, in ogni caso poi le faccio una stampa io della roba che con la laser ci metto meno.

Arrivo da lei, avvio il PC e controlle le impostazioni stampanti.. “Attiva supporto bidirezionale” è in grigio, non abilitabile… uhm..

Riavvio ed entro nel bios, OnBoard Devices, Parallel Port Address… [Disabled] eh no.. questo non va bene.

Riattivo la porta, riavvio e tutto funziona alla perfezione.

Ora ditemi voi perché un BIOS deve decidere di sua spontanea volontà di disabilitare una parallela.. Fate conto che la mia amica sa a stento cosa sia il pannello di controllo del bios e non può averla disabilitata, e comunque non avrebbe avuto nessun pro a farlo.

Beh anche questa è fatta e ho passato una mattinata piacevole in compagnia di un’amica, non posso chiedere di più.

D-Odissey: The End?

Forse sono giunto alla fine della mia odissea con la DWL-122 sotto MacOSX: ho acquistato una Airport Extreme che, ovviamente, funziona che è una meraviglia, prendendo banda anche quando sono in cantina.

Ora la D-Link DWL-122 giace in un cassetto in attesa che possa contattare un mio compagno di classe per prendermi un P133 da mettere in camera con collegato uno scanner, usando il wireless per connetterlo allo studio dove ci sono le stampanti.

Stay tuned guys!

Molto tempo

è passato da quando ho scritto l’ultima entry. Questa mia vacanza (nel senso che sono stato vacante) da questo blog è dovuta principalmente alla partenza della mia carriera universitaria, che pare essere partita nel migliore dei modi: al solito.

Allora iniziamo col dire che perlomeno non posso dire di sentirmi sperduto e solo in mezzo a persone sconosciute: Ziotto, Icaro e (nuova entrata in questo blog, ma vecchia conoscenza mia) Ciori mi hanno seguito, e con loro diversa gente di un’altra sezione sempre dello Zuccante (ma che conoscevo già), e subito appena trovati Ziotto mi ha presentato un suo amico così la combriccola si è subito espansa, visto che Stefano condivide con me passioni come Ultima OnLine e Tolkien, e con Icaro e Ciori la passione per la musica.

Poi.. a parte dei precorsi abbastanza inutili e pallosi (a parte quello di matematica, quello utile, ma sempre palloso), il prof di programmazione non sembra male, ma si basa ancora sul testo di K&R; per il C, che è nettamente superato ormai. Quello di Architettura degli elaboratori è arrivato in aula con un bel PowerBook (il che è tutto dire: se un prof di architettura viene con un PPC :) ), e quello di calcolo (che sostituisce analisi) sa usare un computer.. con linux.. e KDE :P

Le lezioni sono iniziate subito con un bello sciopero, e in più mi sono iscritto a scuola guida, e visto che non mi è semplice tornare a casa in tempo dall’uni anche quando finisco prima, sto saltando tre quarti delle lezioni. Nessun problema, tanto programmazione potrei farlo ad occhi chiusi, mentre per quanto riguarda architetture, beh, ho stampato stasera la dispensa e poi me la guarderò con calma.

Già ho stampato la dispensa, perché ho investito €450 su una bellissima stampante Kyocera FS-1020D. Ottima stampante, connessione USB, che quindi mi consente di tenere anche la mia old-but-gold Epson Stylus Color PRO XL+ A3, che fa sempre comodo per eventuali stampe a colori, anche perché ho una buona quantità di inchiostro.

Il problema è stato che prima ho fatto un infarto perché la collego e non viene riconosciuta dal sistema.. dopo un po’ di collassi ho scoperto che se sulla scheda madre ho un host controller UHCI, la scheda di espansione che sto usando è una OHCI per 1.1 e EHCI per 2.0, risultato: devo compilare tutti i driver per gli host controller USB altrimenti il mio sistema non funziona correttamente -______-’

Risolto questo ho configurato la stampante con i driver Kyocera (ppd) sia su Defiant sia su Voyager (dove ho configurato il CUPS di macos per andare a pigliarsi la stampante dall’altro cups :P).

Ora ho appena finito di riordinare una dispensa di architettura degli elaboratori, perché non sapevo di dover alzare il flag per evitare di spargere in giro i fogli, e si erano un po’ messi alla rinfusa.

Bene detto questo faccio le esercitazioni di programmazione e vado a dormire

Goodbye!

Una brutta sentenza e problemi di compilazione

Ok, è da un pezzo che non scrivo, ma vi avevo avvisato che tra l’università e la scuola guida che ho iniziato l’altro ieri, non avrei avuto molto tempo.

Questo doppio post riguarda la mia vita come sviluppatore di Hypnos, e in particolare vorrei parlare prima di tutto di questo articolo di slashdot.

A parte la giusta protesta di un commentatore riguardo al fatto che slashdot non si è mantenuta neutrale come si confà ad un sito di news, dal mio punto di vista questa sentenza è molto preoccupante.

Per mia fortuna il DMCA non è valido in europa, e Hypnos è scritto da italiani e ospitato su server tedeschi.

L’altra cosa di cui vorrei parlare riguarda il problema dello sviluppo di hypnos col mio portatile: gcc pare NON volerne sapere di funzionare correttamente su macosx, né la versione di Apple, né la 3.4.2 ricompilata a manina dal sottoscritto.

Questo mi scoccia perché ero appena riuscito ad avere un buon ambiente di sviluppo con jEdit e un paio di plugins.

Ora devo solo trovare se c’è un modo per girare attorno al problema finché non viene fixato upstream :/

Quando si dice linea di tiro…

.. non si parla di RunUO. Motivo?

Ieri sera dopo essermi fatto un bel giretto con Locke e Iro, ed essermi fatto un po’ di lizardmen per far su spined leather, torno a casa, lascio giù parte della roba e decido di andare a fare un giro a vedere le due arpie che dovevano essere di fianco casa mia come due giorni fa…

Solo che invece di un’arpia mi son trovato due titan, incazzati, che mi inseguono… entro in casa convinto di poter essere tranquillo, ma da fuori sono riusciti a uccidermi a castare.

Ovviamente stando in culo ai camosci, c’ho messo parecchio per ressarmi. A questo punto son tornato là con un recall.. e i due titan essendo ancora là mi uccidono a vista.

Ok ho perso quasi tutta l’attrezzatura e la cosa mi scoccia…

A questo punto però mi domando chi diamine ha programmato la Line of Sight (linea di tiro) di RunUO.. i maghi (npc perlomeno) hanno los tramite qualsiasi cosa, anche tramite i muri, mentre un arciere non può neanche aprire il target se non è perfettamente di fronte al mostro.

Chi mi domandava perché volevo scrivere un mio emulatore?

Compressione desktop

Ok mi riallaccio al discorso di questa notte sul fatto che io non sono integralista, affermando che per ciò che mi riguarda non ho nulla in contrario che completi lusers possano usare Linux.
A questo punto però bisogna anche fornire loro gli strumenti adatti ad usarlo. Uno di questi potrebbe essere un sistema di compressione migliore dello zip, basato su un ragionamento simile.

Giusto per nota di cronaca facciamo un po’ di luce sui formati di compressione. Ai tempi del DOS, prima che Zip di Phil Katz divenisse lo standard, erano presenti diversi formati di archiviazione/compressione: zip, arj, arc, lha, lhz…. incompatibili tra loro.

Quando poi è arrivato Windows, lo zip è diventato uno standard de facto, grazie anche a WinZip. Poi visto che lo zip non è che avesse delle prestazioni di compressione eccezionali sono sorti i formati rar (v2) ed ace, con i loro tools per Windows, WinRAR e WinACE. Poi è stato il turno di RAR v3 che ha superato la compressione dell’ace e che a quanto ne so è il compressore migliore per ora.

Questo genere di archivi si differenzia in maniera totale da quello dei tar.bz2 e tar.gz usati sotto Unix/Linux. E il motivo è abbastanza semplice in realtà: tar è nato per essere utilizzato sui nastri di backup, quindi usa un sistema sequenziale non compresso, che poi viene completamente compresso con gzip o bzip2 (che non possono comprimere più di un file per volta), mentre zip, rar ed ace hanno l’indice dei file non compresso, ma solo i dati dei singoli file compressi, quindi non è necessario decomprimere tutto l’archivio per avere accesso ad un determinato file.

Questo li porta ad essere più semplici da usare quando si è in un ambiente desktop e gli archivi possono cambiare molto spesso.

Certo però rar, zip ed ace non sono adatti per lavorare sotto linux, soprattutto perché non salvano i permessi dei files. (e in particolare rar ed ace non sono formati aperti, per quanto di rar esista un decompressore opensource e ci siano sia rar che unrar per linux). Al contrario fare un’aggiunta su un file tar compresso richiede la decompressione dell’intero file, l’aggiunta in coda al tar, e poi la ricompressione del file ancora una volta per intero. Dire che è uno spreco di cicli di CPU è dir poco.

Quello a cui stavo pensando è la creazione di un nuovo formato di archiviazione, che utilizzi ebml per salvare i dati dei file, e poi gzip, bzip2 o rzip per comprimere i file (a seconda della loro dimensione). Ovviamente bisognerebbe unire a questo formato anche una serie di tools che permettano la gestione di questo nello stile di zip, unzip, tar etc etc, possibilmente command-line compatibili con gli altri tools.

Non sto dicendo che tar sia da eliminare, ma che sia inadatto alle esigenze desktop dell’attuale mercato di linux. Mentre è ancora valido per alcune cose come, per esempio, le release di sorgenti, dove tutti i file devono venire decompressi sempre assieme.

Beh questi ovviamente sono solo i miei 2 eurocents, per il resto, vedete voi.. un giorno inizierò a scrivere questo formato, allora vedremo come andrà a finire :)