Archivio per la categoria "Sistemi Operativi"



Slax6

SLAXDa qualche settimana è stata rilasciata la sesta versione stabile di Slax, una distribuzione Linux creata espressamente per essere installata su chiavette USB per un'estrema mobilità. Come dice il motto: il tuo sistema operativo tascabile. Finalmente ieri sera ho trovato il tempo per aggiornare la versione 6.0 RC6 che avevo installato sulla mia pendrive MyFlash da 512MB con la recente versione 6.0.2 e devo dire che il tutto risulta molto più stabile pur non essendo esente da qualche glitch e bug qua e là, comunque complimenti a Tomáš per questa release.

L'utilità di Slax è indubbia: con una pendrive di piccole dimensioni (anche da 256 MB dal momento che la distribuzione di base occupa solamente 190 MB) si ha a disposizione un sistema operativo relativamente completo e intuitivo, anche grazie ai software già presenti nella suite KDE di cui attualmente è inclusa la versione 3.5.9, ma che può essere esteso facilmente attraverso il caricamento di moduli lzm aggiuntivi anche nel corso dell'esecuzione stessa del sistema. Ovviamente possono esservi delle esigenze particolari che Slax di base non può soddisfare e per le quali occorre mettere mano al sistema, del resto i compromessi sono necessari quandi si gioca al ribasso con le dimensioni del sistema.

Per uno come me, a cui spesso capita di incappare in contenuti scritti in giapponese, la rimozione dei font asiatici nella versione stabile di Slax può rappresentare un problema anche se di banale risoluzione: nel mio caso è bastato scaricarli e aggiungerli in un modulo lzm che li caricasse nella directory dei font TTF all'avvio del sistema. La creazione di un semplice modulo partendo da una directory con i file già disposti in una struttura uguale a quella del sistema è piuttosto banale grazie all'utility da riga di comando dir2lzm o alla relativa voce presente nel menù contestuale di KDE. Un altro problema nell'ottica della visualizzazione dei caratteri di lingue orientali o più in generale non latini è rappresentato dal modulo italian.lzm, scaricabile a parte dal sito, che offre la localizzazione del sistema in italiano configurandolo tuttavia con il charset ISO-8859-1 quando in realtà UTF-8 sarebbe decisamente più adeguato in situazioni simili. In questo caso è stato necessario creare il locale it_IT.UTF-8 utilizzando localedef per poi rifare il modulo italian.lzm (estraendone i contenuti con lzm2dir) affinché ne includesse il risultato, infine ho dovuto modificare lo script /etc/profile.d/lang.sh affinché esportasse direttamente le variabili LANG e LC_ALL valorizzate con it_IT.UTF-8 anche se devo ancora verificare se c'è un modo migliore senza toccare questo script. Il resto è semplicemente questione di impostare correttamente l'encoding di applicazioni KDE come Konsole ma anche di quelle eseguite nel terminale come ELinks o weechat (entrambi supportano Unicode, basta configurarli correttamente), memorizzandone poi i relativi file di configurazione in un modulo a parte. Nonostante sia possibile eseguire Slax con l'opzione di boot changes che, grazie ad aufs, permette di memorizzare in una directory o in un file tutte le modifiche effettuate durante una sessione live del sistema, personalmente per tutte le configurazioni di KDE o delle applicazioni che per me sono particolarmente ricorrenti preferisco usare modulo lzm dedicato, permettendomi di portare più facilmente le stesse su più chiavette o di averne un backup più comodo (anche se a ogni modifica da tenere sono costretto a rifare il modulo stesso, operazione veloce ma comunque più scomoda anche se ormai non troppo frequente).

Attualmente sul sito non ci sono molti moduli ma sul forum è possibile trovare qualcosa in più realizzato dagli utenti, fortunatamente però la loro creazione in totale autonomia spesso non è un'operazione troppo complessa soprattutto se si parte da un pacchetto tgz per Slackware 12, distribuzione su cui è basata Slax6. In questo caso gli ingredienti necessari sono rappresentati dal pacchetto tgz da convertire in lzm, l'utility tgz2lzm inclusa di default in Slax e un po' di attenzione per le eventuali dipendenze necessarie all'esecuzione dei programmi. Per esempio la creazione del modulo lzm per Opera 9.26 partendo dal tgz per Slackware 12 è molto semplice: da terminale, il comando tgz2lzm opera-9.26-i486-1kjz.tgz opera-9.26-i486-1kjz.lzm si occuperà di generare il vostro modulo pronto per l'installazione live o per essere memorizzato sulla vostra chiavetta USB nelle directory modules (per i moduli da caricare automaticamente all'avvio del sistema) o optional (dove memorizzare tutti gli altri moduli che possono tornare utili, più che altro una convenzione in questo caso). Nel caso di altri programmi che richiedono determinate dipendenze occorre verificare e scegliere come agire, per esempio ELinks vuole la libreria libjs.so che è disponibile tramite SpiderMonkey per cui le possibili soluzioni sono due:

  • creazione di due moduli, uno per ELinks e uno per SpiderMonkey, da caricare separatamente.
  • creazione di un modulo custom per ELinks che contenga direttamente libjs.so.

Di norma preferisco tenere in un modulo separato le dipendenze che possono essere ricorrenti o richieste da altri software e unire nello stesso modulo quelle più rare, ma diventa anche una questione di preferenze. Con altre utility c'è la possibilità di creare moduli lzm partendo anche da pacchetti deb o rpm, ma non è certo la soluzione migliore dal momento che le differenze dettate dalla natura dei pacchetti di origine e dei sistemi target degli stessi potrebbe introdurre qualche noia di troppo.

Tutto sommato Slax6 sta mantenendo le aspettative delle precedenti RC pur necessitando ancora di lavoro. Sicuramente il fatto di essere un sistema basato su KDE la rende una distribuzione live che necessita di scendere a qualche compromesso per un'esecuzione ottimale quindi non è particolarmente consigliabile l'esecuzione su computer vecchi e/o con poca RAM (credo che un minimo veramente accettabile sia 128 MB), inoltre il sistema a moduli può essere comodo e facile da utilizzare ma al tempo stesso difficoltoso da mantenere per le varie dipendenze, non esistendo un sistema stile Apt o Yum che le gestisca. Tutto sommato però trovo che per il suo scopo principale, ovvero l'esecuzione live da pendrive USB di un sistema piuttosto completo, Slax abbia una marcia in più rispetto ad altre soluzioni.

Linksys NSLU2: un piccolo storage di rete? No, di più!

Linksys NSLU2 Per la serie intitolata come ritrovarsi con un nuovo giocattolo nel giro di mezza giornata, sabato ho acquistato un aggeggino chiamato NSLU2 prodotto da Linksys, il tutto dopo averlo conosciuto venerdì sera tramite mio padre che me lo ha introdotto come uno scatolotto ideato in teoria come soluzione NAS a basso costo ma in pratica hackerabile a volontà, non solo dal punto di vista software ma anche da quello hardware.

NSLU2 è stato concepito come un network storage per condividere in rete fino a due unità di archiviazione USB (hard disk o memorie flash formattate in EXT3, FAT32 oppure anche NTFS usando l'ultimo firmware) con gestione di impostazioni, gruppi di utenza e quote accessibile attraverso un'interfaccia web scarna ma abbastanza semplice ed efficace. Considerato il prezzo ridotto di circa un centinaio di euro, questa periferica sembra svolgere decorosamente il lavoro per cui è stato progettato ma nella realtà si può ottenere decisamente molto di più da essa! Essendo basato internamente su una mini-distribuzione custom con kernel Linux del ramo 2.4, alcuni moduli ad hoc (di cui Linksys ha rilasciato i sorgenti) e un set ridotto di applicativi come Samba (condivisione dei file) o thttpd (accesso all'interfaccia web), c'è chi ha pensato bene che sarebbe stato bello poterci fare qualcosa di più e quindi sono nati firmware alternativi per tutti i gusti e le esigenze. In effetti le caratteristiche fisiche (dimensioni e peso molto ridotti, bassissimi consumi, totalmente silenzioso) e tecniche (processore Intel XScale da 266 MHz, 32 MB di memoria interna, due porte USB 2.0/1.1) dell'NSLU2 lo rendono particolarmente appetibile per svolgere l'attività di mini-server non solo per condivisione di file ma anche per avere istanze di SSH o di piccoli server web, posta, ftp, tanto che intorno ad esso è nata un'intera comunità veramente molto attiva che vede confluire un buon flusso di contributi in un unico sito ricco di informazioni su idee, caratteristiche e hack.

Alla fine il motivo che mi ha spinto a comprarlo con tempi che per me sono assolutamente da record, visto che sono solito a meditare attentamente i miei acquisti, è stato proprio il fatto di poter customizzare l'NSLU2 per ottenere un piccolo serverino senza molte pretese ma accessibile da remoto e da poter tenere sempre acceso con consumi ridotti all'osso (max 10 watt) e devo ammettere che questa attività mi sta divertendo parecchio, tanto che ho deciso di dedicarvi una serie di post con quantità e cadenza indefinite ma con lo scopo di raccogliere l'esperienza, i dettagli della mia customizzazione e i risultati degli svariati esperimenti che ho in mente.

Interagire con Windows tramite Ruby

Oggi stavo effettuando alcune ricerche su internet quando sono incappato in un mio messaggio inviato qualche mese fa sulla mailing list di ruby-it in risposta a chi chiedeva aiuto su come poter recuperare l'elenco delle unità montate su un sistema Windows. Ruby ormai offre da tempo un supporto particolarmente maturo all'interazione con il sistema su piattaforme Windows tramite Win32OLE e alle svariate librerie del progetto Win32 Utils. In questo caso, a dimostrazione della flessibilità delle soluzioni offerte da Ruby, lo stesso task può essere risolto in tre modi molto differenti tra loro.

Il primo approccio sfruttando il modulo Windows::Volume delle Win32 Utils consiste nell'utilizzare in maniera diretta le API di Windows e la sua implementazione, anche se può apparire grezza e magari non troppo elegante agli occhi dello sviluppatore Ruby puro, è comunque piuttosto facile:

require 'windows/volume' include Windows::Volume def get_drive_letters buffer = " " * 1024 length = GetLogicalDriveStrings(buffer.length, buffer) buffer[0..length].split(0.chr) end p get_drive_letters # => ["A:\\", "C:\\", "D:\\", "E:\\", "F:\\", "G:\\", "H:\\", "I:\\"]

Utilizzando GetLogicalDriveStrings si ottiene una lista di tutte le unità logiche montate nel sistema, indipendentemente dalla loro natura fisica, il tutto sotto forma di buffer contenente l'elenco di lettere di unità separate dal carattere NULL. Questo ci costringe a istanziare un buffer e a estrarne il contenuto con cui è stato riempito dalla funzione API in una maniera abbastanza lontana dal tipico stile di programmazione in Ruby, ma è pur sempre fattibile e tutto sommato non è poi così brutto a vedersi, c'è di peggio in altri linguaggi.

In Windows esistono poi gli oggetti COM messi a disposizione dalla Scripting Runtime Library e uno di questi, tra l'altro forse tra i più utilizzati, è FileSystemObject. Sinceramente sentire questo nome mi fa venire gli incubi tornare in mente a quando svariati anni fa mi è toccato usare ASP 3.0 che, per la cronaca, non ho mai sopportato. Il fatto di non dover usare le API Win32 salendo quindi di livello ci permette di utilizzare semplicemente Win32OLE:

require 'win32ole' def get_drive_letters drives = [] fso = WIN32OLE.new('Scripting.FileSystemObject') fso.drives.each { |drive| drives << "#{drive.driveletter}:\\" } drives end p get_drive_letters # => ["A:\\", "C:\\", "D:\\", "E:\\", "F:\\", "G:\\", "H:\\", "I:\\"]

L'astrazione messa a disposizione da Win32OLE per le collection restituite da oggetti COM include automaticamente un metodo each che ci permette di iterare in maniera familiare e comoda il risultato dalla proprietà Drives dell'istanza di FSO.

Esiste infine la possibilità di utilizzare l'interfaccia messa a disposizione da WMI (Windows Management Instrumentation) per ottenere le stesse informazioni in maniera ancora più intuitiva con un approccio molto SQL-like nell'interrogazione delle informazioni sui sistemi Windows:

require 'win32ole' def get_drive_letters drives = [] wmi = WIN32OLE.connect('winmgmts://') devices = wmi.ExecQuery('SELECT * FROM Win32_LogicalDisk') devices.each { |drive| drives << "#{drive.DeviceId}\\" } drives end p get_drive_letters # => ["A:\\", "C:\\", "D:\\", "E:\\", "F:\\", "G:\\", "H:\\", "I:\\"]

Interrogando la classe WMI Win32_LogicalDisk si può ottenere rapidamente una nutrita serie di informazioni risparmiandosi un sacco di giri o chiamate, delegando tutto al sistema operativo. Inoltre è possibile scremare già in fase di richiesta e molto facilmente il set di risultati desiderato, del resto come abbiamo visto le query WMI ricordano molto da vicino SQL. Per fare un esempio, cambiando la nostra query in SELECT * FROM Win32_LogicalDisk WHERE FileSystem = 'NTFS' è possibile ottenere l'elenco di tutte le unità il cui filesystem è NTFS. Un altro vantaggio non indifferente è quello di poter richiedere le stesse informazioni a computer remoti semplicemente cambiando la stringa di connessione al provider WMI, per esempio utilizzando una stringa di connessione come winmgmts:{impersonationLevel=impersonate}!\\192.168.1.2\root\cimv2 (in un dominio AD può tornare molto comodo per tenere sotto controllo le proprie installazioni).

E' possibile fare tutto e in molte maniere, ce ne è per tutti i gusti. Il vantaggio di poter interagire con Windows attraverso Ruby anziché con i soliti VBScript e JScript risiede prima di tutto nella sua estrema flessibilità rispetto ai suddetti linguaggi di scripting rivali forniti di serie nel sistema operativo, ma anche nella possibilità di sfruttare nei propri script di automazione tutte le classi standard e di terze parti che gravitano intorno a Ruby è un vantaggio da non sottovalutare nello sviluppo di task amministrativi più complessi. Ok posso percepire anche coloro che ci terrebbero a sottolineare come sia possibile fare le stesse cose con Perl e Python... sì, avete perfettamente ragione, ma qui si pubblicizza Ruby ;-P

Windows Update, Windows Live Writer e SyntaxColor4Writer

Primo post del 2008 all'alba del tredicesimo giorno di gennaio, complimenti a me stesso per la tempestività. Insomma, anche se con un ritardo madornale vorrei augurarvi un buon 2008... per lo meno ora sapete che non ho fatto la fine del topo. Tornando al titolo del messaggio, oggi vagando a caso per internet ho trovato conferma sul blog di Davide Vernole a un sospetto che già mi era venuto nei giorni scorsi ma su cui non avevo indagato più di tanto per mancanza di tempo: dopo l'ultimo Windows Update che ho effettuato, SyntaxColor4Writer ha smesso di funzionare in Windows Live Writer. In realtà nell'approvare gli aggiornamenti avevo notato con la coda dell'occhio una voce riguardante Windows Live Writer per cui mi era bastato fare 1+1, ad ogni modo mi sono ritrovato impossibilitato a usare il mio plugin preferito per la formattazione del codice client-side data anche la mancanza di aggiornamenti pubblicati sul sito ufficiale dell'autore. Accidenti, proprio quando volevo mettermi di buzzo buono per aggiornare la mia definizione della sintassi di Ruby alle novità della 1.9. Oh well, poco male, rispolveriamo un mio post pubblicato in occasione del rilascio di WLW B2 e adattiamolo all'esigenza odierna:

  1. E' necessario avere installato Visual Studio dal momento che verrà utilizzato ILDASM per effettuare il dump del relativo codice IL della DLL di SyntaxColor4Writer. In teoria credo sia possibile usare anche monodis (l'equivalente per Mono) ma sinceramente, non avendolo mai provato, non ho idea di quale possa essere il risultato finale e del suo grado di compatibilità.
  2. Creiamo una directory in cui copiare il file IStaySharp.SyntaxColor4Writer.dll e apriamo una shell dei comandi puntando alla stessa per eseguire vsvars32.bat (importa tutte le variabili d'ambiente per usare i tool di VS)
  3. Per effettuare il dump completo con ildasm.exe via command line dovremmo specificare una sfilza di parametri abbastanza lunga, per cui lanciamolo senza argomenti per eseguirlo in modalità GUI: a questo punto importiamo la DLL IStaySharp.SyntaxColor4Writer.dll e facciamone il dump nella directory corrente spuntando tutte le opzioni nella dialog delle dump options. Per comodità salviamo il file IL risultante con il nome IStaySharp.SyntaxColor4Writer.il
  4. Apriamo con un editor di testo qualsiasi il file .IL appena generato e sostituiamo tutte le occorrenze della stringa .ver 12:0:1366:1026 con .ver 12:0:1367:1128 (in totale dovrebbero essere effettuate 3 sostituzioni). Con questa procedura non facciamo altro che aggiornare le reference agli assembly esterni di WLW specificando la nuova versione degli stessi, in realtà basta questo perché le API esposte da WLW verso i plugin non sono cambiate.
  5. Ora dobbiamo ricompilare la DLL con ILASM: torniamo alla shell e lanciamo questo comando:
    ilasm IStaySharp.SyntaxColor4Writer.il /dll /res:IStaySharp.SyntaxColor4Writer.res
  6. Una volta generata la nostra nuova versione di IStaySharp.SyntaxColor4Writer.dll non resta altro da fare che sostituire la DLL attualmente esistente nella directory Plugins di WLW e lanciare il programma.

Istruzioni sicuramente della mutua per uno sviluppatore .NET rodato, ma possono tornare comode ugualmente. A meno di cambiamenti particolari o differenze nelle API, come accaduto nel passaggio da B1 a B2 di WLW, questi passaggi dovrebbero rimanere validi anche per eventuali update futuri: basterà semplicemente aggiornare le stringhe di sostituzione con le relative versioni. Come in passato, se qualcuno avesse bisogno della DLL aggiornata e pronta per l'uso non dovrà far altro che contattarmi (anche privatamente, ho aggiunto l'indirizzo email in fondo alla pagina delle note in attesa di miglior organizzazione :-))

Les indispensables: AppFresh

AppFreshDopo svariati mesi di assenza su questo blog ritorna la categoria de les indispensables, questa occasione però sarà particolare perché per la prima volta parlerò del mondo Mac con un'applicazione che sto trovando abbastanza comoda: AppFresh. AppFresh vi permette di tenere sotto controllo e installare comodamente e in maniera centralizzata gli update di tutte le applicazioni che avete sul vostro Mac, non solamente quelle Apple ma anche quelle di terze parti compresi tra l'altro plugin, pannelli delle preferenze e widgets. La configurabilità è buona: potete scegliere in quali path andare a cercare le applicazioni, con quali modalità effettuare le scansioni dei programmi e le installazioni degli aggiornamenti oppure marcare la versione di un'applicazione che avete installato per considerarla come se fosse l'ultima, facendo in modo da non averla in elenco nel caso non siate intenzionati ad aggiornarla. AppFresh ha anche una funzionalità di snapshot e ripristino che vi permette di tornare sui vostri passi e ripristinare un'applicazione allo stato precedente un eventuale aggiornamento fallito o molto più semplicemente di vostro non gradimento. Non l'ho ancora provata, ma potrebbe tornare utile. Tutto sommato non mi dispiace e non mi ha dato problemi nelle ultime due settimane, ho aggiornato circa una ventina di applicazioni di vario tipo senza il minimo intoppo. Stando al sito ufficiale, AppFresh per ora è compatibile solamente con OS 10.4 ed è da considerarsi ancora come un'applicazione work in progress.