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 :)

Only for geeks

No, non è questa entry ad essere solo per geeks, si tratta semplicemente del concetto.
Che concetto direte voi, e ora ve lo vado a spiegare.

Come ben sapete tutti, io non uso più Windows da molto tempo, invece uso Linux sulla mia workstation fissa (Defiant) e MacOSX sul mio portatile (Voyager, da cui sto scrivendo ora usando la connessione 802.11b). Al tempo stesso sono abbastanza attivista verso la diffusione di Linux, e per esempio scrivo utility e frontends per le necessità più comuni basati sul framework KDE.

Il mio pensiero è quello che se Linux diventa abbastanza semplice da poter essere utilizzato da utenti occasionali, molta gente potrebbe spostarsi lontana da Windows, e i produttori Hardware e Software saranno obbligati a supportarlo a tutti gli effetti.

Purtroppo però sembra che non sia condivisa da tutti questa mia visione del mondo Linux. Sempre all’interno del famoso VElug (che non linkerò più più che altro perché temo che qualcuno risalga al mio blog dai references :D), c’è chi pensa per esempio che il progetto Ubuntu, una distribuzione newbie-friendly basata su Debian, sia il male assoluto perché, tra le misure di sicurezza per i newbie, disabilita di default l’utente root (amministratore), e permette all’utente creato in installazione di fare ciò che vuole usando sudo (e inserendo la propria password). Questo comportamento è mutuato da MacOSX, che fa la stessa identica cosa. Per poter accedere come root, bisogna obbligatoriamente usare il comando ‘sudo su root’ invece del semplice ‘su root’. Questo impedisce il continuo login della gente con root, limitando i danni che questi possono fare accidentalmente.

Io sono convinto che tutto questo, per una distribuzioen orientata agli utenti non esperti, sia molto importante e interessante. E soprattutto avendolo provato con mano su questa macchina, direi che non è una grossa scocciatura per i tecnici.

Le spiegazioni che la persona che non nominerò mi ha dato è che se per espandere Linux bisogna evitare alla gente di leggere quintali di documentazione, lui si prodigherà per impedire l’espansione in tal senso, perché tutto rimanga com’è, impedendo di far entrare nuova gente nel ‘giro’.

Sinceramente non condivido affatto quest’opinione: i circoli chiusi sono costretti a lungo andare a sparire, a morire. Se si vuole che qualcosa migliori e continui ad esistere bisogna evitare di rimanere chiusi in sé stessi.
Pensiamo a quante cose la scienza ha permesso alla gente comune di usare, non impedendo per esempio l’uso di certe sostanze chimiche a chi non fosse capace di produrle da sé.

Chiudere Linux e il free software / open source software in un circolo chiuso non può fare che danni, perché significherebbe limitare la possibilità d’uso dei programmi stessi.

Certo è una scocciatura trovarsi gente che non legge manco il readme di un programma e poi si lamenta che non riesce ad usarlo, ma ci sono anche cose che sono veramente lunghe da leggere e soprattutto pallose. No, non mi riferisco in particolare al manuale di Emacs, ma anche quello è una di quelle cose. Tant’è che ora esistono strumenti come Kate e KDevelop che permettono agli sviluppatori di scrivere programmi con una bella interfaccia senza aver bisogno di leggere un manuale di 600 pagine.

Non per niente vi ed emacs più passa il tempo meno sono usati. Io stesso mi ritrovo sempre più spesso ad usare nano in console per modificare dei semplici file di configurazione, non avendo necessità di grosse cose (per quelle ho Kate e JEdit).

Non riesco sinceramente a capire certe idee, forse è solo paura di vedersi levare il pane di bocca da persone più brave che potrebbero prepararsi meglio, ma mi pare anche vada contro lo stesso concetto di software libero. Se imponiamo il vincolo che solo le persone tecnicamente capaci possono usare un programma, questo non è più libero, è vincolato. Forse non dalla licenza, ma da altri requisiti. È per esempio il concetto espresso dalla richiesta di alcuni developer tra cui quelli di Frozen Bubble di non portare il proprio software sotto sistemi operativi proprietari come Windows, Solaris o MacOSX: non impone limiti sulla licenza, ma richiedono di cancellare una propria libertà. Inoltre impedisconono il progresso del loro software includendo le migliorie.

Veramente non riesco a capire tutto questo chiusismo…