Driver repository (per Windows ovviamente)

Poiché molto spesso oramai mi trovo a formattare e reinstallare workstation, mi sono fatto una serie di script in grado di automatizzare un po' di cose (prima di tutto ho integrato il SP3 nel cd di install, poi ho fatto in modo di poter lanciare l'installazione via rete, ecc.) in modo da non dover stare lì 3 ore per una cosa "banale" come "reinstallare il pc".

Certo il massimo sarebbe (essendo problemi che sorgono spesso in ambito lavorativo) avere un immagine del disco con utility tipo "partimage" o "ghost" in modo che un ripristino duri 5 minuti, ma spesso non si hanno terabytes di spazio per memorizzare n^m immagini di workstation (soprattutto poi se le suddette sono state acquistate da fornitori diversi e sono modelli completamente differenti, quindi niente immagine unica da mettere su più pc).

Quasi tutto è automatizzato, quello che ancora mi occupa però tanto tempo è il trovare i drivers. Come dite? I dischi del produttore? Magari!

Indipercuilaquale mi ritrovo a dover pescare dalla lista dei dispositivi una serie di ID (i famosi vendor & device ID) per cercare driver compatibili. Ora, per quanto possa essere "rapida" la ricerca avendo già VEN_ID e DEV_ID, spesso ci si impiega più del 50% del tempo impiegato per rimettere in sesto la workstation.

Ho deciso quindi di realizzare un software che è in grado di interrogare la lista degli ID di cui sopra e cercare la corrispondenza dentro il database di PCI-IDs (lo stesso usato dagli strumenti come lspci di GNU) e, successivamente (ovvero, ora) sto cercando di realizzare un database contenente i driver, in modo che il programma fatto da me non deve far altro che scaricare dal DB il file compresso contenente i device drivers ed installarli. Questo sveltirebbe di molto le operazioni di installazione/manutenzione, visto che molti driver (soprattutto SiS e ASUS che abbiamo a quantità industriali) sono gli stessi per molti devices. Questo presuppone ovviamente uno script che apre e analizza i file .inf per capire il driver a quale dispositivo può essere associato.

Tutto questo in pratica mi renderebbe in grado di lanciare il mio programma sotto Windows (magari insieme agli altri scripts) e fornire al sistema operativo, in modo automatico o semi-automatico, i driver per i dispositivi che ha.

Avevo anche una mezza intenzione di rendere la cosa pubblica su internet, ma poiché già esistono siti del genere, e soprattutto perché non so se i produttori dei suddetti software siano d accordo (vedi licenze), eviterei di farlo.

Per ora, quello che mi manca è solo completare il software che sotto Windows scarica i file compressi dal database. Dopodiché pubblicherò i sorgenti ;-)

Stay tuned ;-)

Enrico

Voglio un programma per gestire l'inventario!!!

Dunque, nella mania di ogni sistemista di automatizzare e semplificare le cose (senza perdere "il controllo" delle stesse), mi trovo a voler/dover semplificare la gestione del parco macchine. Il problema è che non volevo sviluppare un programma per l'inventario solo per quel tipo particolare di problematica, ma qualcosa che sia "adattabile" e non troppo rigido. Ho deciso quindi di ritagliare un po' di tempo che uso per QEMU Live 2 e usarlo per questo, che è meno complesso e più utile al momento.

Presupponendo che non posso mettermi a variare la struttura del database da codice, ho pensato di usare dei file XML per gestire la struttura delle varie tipologie di componenti, e poi in modo generico associarli come "padre-figlio" con un banale campo intero nel DB. Ogni oggetto ha un riferimento al suo "modello XML" che viene usato per generare l'XML dei dati.

Inoltre, vorrei aggiungere subito un'estensione (un "plugin") per memorizzare i driver delle periferiche mediante i codici VendorID e DeviceID (nel caso di periferiche PCI, oppure i corrispondenti nel caso di altri), magari con un sistema di analisi e catalogazione automatica del driver per ogni periferica.

Per ora, il codice che è presente e funzionante è quello per i modelli XML. Nei prossimi giorni lavorerò sull'insert dei dati e la generazione del form partendo dal modello XML.

Enrico

Collezionare dati in Java: database o classe serializzabile?

Eccomi qui, a scrivere di uno dei miei programmi (o librerie, ancora non so come strutturare la cosa) che è tanto in voga in questo periodo della mia vita (leggasi: quello che voglio fare nelle vacanze). Tanto per farla corta, si tratta di un server che accetta connessioni da client che si autenticano, e mantiene certe informazioni su di essi. Trattasi di server che, molto probabilmente, non gireranno sotto "cluster" o diavolerie del genere, ma in vecchi rottami casalinghi od ospitati su macchine virtuali, e quindi molto probabilmente non avranno la fortuna di avere un server database in una macchina "dedicata".

Tralasciando gli accrocchi strutturali dei vari protocolli, ecc., mi son trovato di fronte al problema di creare un sistema in grado di memorizzare questi dati, possibilmente anche molto "complicati", e di accederci in modo veloce. Questo mi lascia sostanzialmente di fronte a due "grandi" possibilità: database e "non database".

I vantaggi di una soluzione con database sono subito chiari: tali software sono scritti per compiere quel tipo di lavoro, quindi la possibilità che il codice sia ottimizzato è superiore. Inoltre, la ricerca è semplice, e soprattutto si demanda questa (come anche altre operazioni "semplici") ad un motore esterno (aka: ce ne freghiamo e ci concentriamo sul resto). Il che sostanzialmente è buona cosa, ma alcune volte non basta.

Immaginiamo di dover memorizzare una lista di utenti, e che tale lista contenga diversi campi, tra cui "nomeutente" (che guarda caso ci servirà per pescare la riga dell'utente all'autenticazione) e "prodottipreferiti" (una lista di prodotti diversa per ogni utente). Ora, un database sarà un po' più complicato da gestire con questo ultimo campo, visto che si tratta di una lista e non di un "normale dato". Questo infatti ci porta a creare una seconda tabella con i dati delle liste, e mediante dei campi "utente", collegarli all'utente (in uno dei tanti casi, alla fine comunque tutti rispecchiano questo concetto). Inoltre, in ambito di diffusione del prodotto, porta un grave problema: il motore del database, eccezion fatta per SQLite e soluzioni simili, va portato dietro, oppure va messo tra i prerequisiti, che non tutti potrebbero avere (e questo quindi complica la vita a chi deve utilizzare il programma).

Potremmo quindi creare una classe con i campi qui di sopra, e creare un vettore di oggetti di questa classe. Questo sarebbe un sistema molto più vicino al nostro utilizzo dei dati, ma deve essere implementato "in toto", e la possibilità di ottimizzazione è bassa. Inoltre, va previsto un modo per salvare gli oggetti in file, e qui per fortuna Java ci da una mano, grazie alla possibilità di serializzare gli oggetti.

Tirando le conclusioni, possiamo dire che, se da un punto di vista architetturale e algoritmico utilizzare un motore di database esterno porta vantaggi notevoli (escludiamo la possibilità di avere il database su macchine diverse dal server, come detto all'inizio), quando i dati cominciano ad essere complicati, il modello del vecchio database "a relazioni" non funziona poi tanto bene, o almeno diventa molto più complicato di costruirsi una sorta di mini-database interno a mano.

Enrico