Ieri mi sono finalmente laureato alla triennale di Ingegneria Informatica a Genova!

Entro 2 o 3 giorni rilascerò il software scritto.. ad ora è disponibile tramite il server svn!

Sto aspettando un paio di giorni perché ho scritto un paio di funzioni non incluse nella tesi e vorrei inserirle in questa versione poiché mi sembrano abbastanza stabili.

Il prossimo passo sarà fornire supporto per rom Android e crosscompilazione!

Come ho già scritto più volte io stesso uso kerneler perché è più facile scaricare decomprimere ecc senza bisogno di usare il terminale, ma questo non vuole assolutamente dire che l’utente non debba imparare! O meglio può decidere di non imparare ma viene invogliato vedendo il terminale che lavora da solo..

Ho appena finito di aggiungere anche la disattivazione dei pulsanti in modo da evitare operazioni sbagliate come compilare senza aver scaricato nulla e via dicendo. In questa maniera l’utente “non può sbagliare” ma capisce esattamente cosa stia succedendo!

Sto scrivendo una funzione per aiutare anche l’uso del terminale e appena è finita vedrò di pubblicarla!

Dopo aver ultimato questi ultimi controlli mi metterò all’opera sulla parte più complessa ovvero l’autoconfiguratore!

Stay tuned!

Ho rifinito meglio un po’ tutte le funzioni principali e ho ultimato la parte di scelta della versione/download/decompressione.

L’utente una volta che scarica la lista delle versioni disponibili, queste vengono salvate in locale in modo da non dover ogni volta riscaricare tutto. Tramite un pulsate update può forzare il download e l’aggiornamento.

Ho inserito una bozza della guida che aiuterà l’utente durante il processo.

In locale ho già scritto buona parte dell’autoconfiguratore e del gestore di patch ma devo ancora testarlo a fondo!

Stay tuned!

• Ho rivisto un po’ il modo di eseguire controlli sulle operazioni fatte e ho risolto il problema salvando ogni operazione fatta su ogni versione di kernel su un file. A differenza del codice che associo a una determinata versione si stabilirà a che punto si è arrivati (1 download 2 decompressione 3 configurazione ecc le altre sono ancora da ultimare)
  Ho pensato anche di usare un insieme di numeri tipo chmod per determinare con precisione che operazioni vengono svolte ma è discretamente inutile visto che non si puo’ decomprimere senza sorgenti o installare senza compilare.
• Ho scritto 2 classi molto importanti per l’autoconfiguratore:
  • Per determinare che hardware è presente (cpu, memoria, quantità di core/cpu, moduli che sono stati installati, scheda video)
  • Per eseguire operazioni sui file di configurazione (sostituzione, cancellazione e assegnamento di un valore)
• Ho rivisto un attimo la grafica. Ora nella pagina principale è presente una schermata di riepilogo dove possiamo vedere a che punto eravamo arrivati con le varie versioni.
  Da decidere se mostrare un riepilogo del tipo:

DOWNLOAD
versioni scaricate
DECOMPRESSIONE
versioni decompresse

oppure

VERSIONE
operazioni svolte
VERSIONE
operazioni svolte

I sorgenti come al solito sono disponibili sul server svn! Non sono ancora presenti tutti perché preferisco inviare solo il codice funzionante e devo risolvere ancora qualche problema prima che sia eseguibile!

Stay tuned!

Visto che ormai mancano un paio di esami prima della laurea ho chiesto ad un professore molto disponibile se fosse possibile essere seguito per sviluppare Kerneler come tesi triennale di laurea e la risposta è stata positiva!

Quindi se voglio laurearmi dovrò svilupparlo per forza

Ho ripreso ieri sera/notte in mano i sorgenti e ho trovato prima di ricominciare a scrivere codice alcune modifiche da fare a livello strutturale!
Come avevo promesso (e fatto) ogni passo verrà pubblicato sul blog!

Vi allego una breve relazione che ho scritto per vedere quali sono i punti principali su cui intendo concentrarmi!

Kerneler

Gli utenti GNU/Linux lamentano una certa difficoltà nel far funzionare il proprio hardware, sia per cause legate al cattivo supporto da parte delle aziende sia per le difficoltà che incontrano durante la ricompilazione del kernel.

Compilare il kernel permette di aggiungere moduli necessari per il corretto funzionamento del computer e rimuovere quelli in eccesso. Ad esempio un utilizzatore di un computer desktop non avrà nessun interesse a installare il supporto per “Network Token Ring“, che occupa inutilmente spazio disco e rende il boot più lento.

Kerneler è stato scritto per rendere molto semplice la compilazione del kernel grazie a controlli su ogni operazione, offrendo all’utente anche un processo di learning durante il quale possa acquisire confidenza con i comandi *nix.

L’utente verrà seguito durante l’operazione di ricompilazione tramite i seguenti punti:

• Download
• Decompressione
• Gestione patch (revisioni e patch aggiuntive)
• Configuratore automatico
• Configuratore manuale
• Compilatore
• Installatore

1. Download

Il download è la fase più semplice durante la quale l’utente sceglierà la versione del kernel:

• che più è gradita
• ultima disponibile

Alcuni driver funzionano solo su determinati rami/revisioni del kernel quindi può rivelarsi inefficace l’utilizzo dell’ultima versione.

2. Decompressione

La decompressione si occuperà di posizionare e decomprimere i sorgenti del kernel su cui si andranno a eseguire operazioni.

L’utente è bene che prenda familiarità con i comandi tar, bunzip e i loro parametri di configurazione.

3. Gestione Patch

La gestione patch permette di simulare l’applicazione di una determinata patch prima di rendere definitiva la modifica “sporcando” così i sorgenti.

Le patch possono generare warning o errori ritornando così all’utente avvisi (estrapolandone l’output e suggerendo ove possibile la soluzione).

Inoltre, poiché il kernel Linux ha superato il centinaio di MB, è possibile passare da una versione all’altra attraverso l’utilizzo di patch incrementali.

Es 2.6.30.1 => 2.6.32.4

I passaggi logici saranno:

2.6.30.1 => 2.6.30 => 2.6.31 => 2.6.32 => 2.6.32.4

Il tutto è chiaramente trasparente all’utente ma spiegato in fase di funzionamento.

Inoltre potrebbero essere messe a disposizione all’utente un elenco di patch “non ufficiali” come le patch CK (Con Kolivas con scheduler BSF), patch di sviluppo “instabili” (Andrew Morton MM patchset) ecc.

4. Configuratore Automatico

Provvederà, tramite “lsmod“, di capire quali moduli siano attualmente caricati e utilizzati dal kernel in modo da aggiungerli alla configurazione del kernel.

In questa maniera sarà possibile per un utente evitare l’utilizzo di un’immagine initrd per il caricamento dinamico di moduli che rallenta notevolmente la procedura di boot.

Inoltre configurando architettura, processore, quantità di ram e altre ottimizzazioni si potranno ottenere vantaggi prestazionali notevoli rispetto alle configurazioni generiche presenti nei kernel preconfezionati delle distribuzioni.

5. Configuratore Manuale

All’utente verrà mostrata una schermata di configurazione (tramite libncurses, gtk o Qt) in modo da permettere la rimozione di supporto hardware inutile o l’aggiunta di altri moduli di cui si avrà necessità in futuro.

6. Compilatore

Sfruttando i comandi classici della ricompilazione si può procedere a compilare il kernel o volendo per distribuzioni più specifiche sarà possibile costruire pacchetti (ad esempio su debian utilizzando make-kpkg si potrà generare un pacchetto .deb utilizzabile anche su altre macchine).

Kerneler calcolerà il numeri di thread ottimale (concurrency_level) in modo da sfruttare appieno la potenza di calcolo dei processori multicore/multicpu.

7. Installatore

E’ quindi possibile installare il kernel compilato per renderlo disponibile al successivo boot.

Su distribuzioni debian-like l’aggiornamento di grub/grub2/LILO avverrà automaticamente tramite postscript presenti nel pacchetto deb generato mentre sulle altre distribuzioni verrà eseguito tramite Kerneler.

Considerazioni

L’utente, oltre ad essere coinvolto direttamente durante la compilazione, può scegliere di eseguire operazioni a mano tramite il terminale incorporato al programma che ha duplice funzione pedagogica e di debug.

Inoltre essendo modulare l’intero procedimento può essere svolto in diverse sessioni: (esempio download prima e il resto offline oppure compilazione in un secondo momento). Infatti il programma tiene traccia delle operazioni già svolte e di quelle ancora da svolgere.

Stato attuale del progetto e tecnologie usate

Attualmente kerneler è scritto in bash e interfaccia testuale/grafica gestita rispettivamente da dialog/zenity.

La versione esistente non prevede il configuratore automatico.

Complessivamente risulta poco ottimizzato, poiché si è sviluppato con uno scopo diverso, anche la struttura deve essere profondamente rivista .

Il progetto iniziale aveva un obiettivo formativo modesto e solo in tempi successivi si sono sviluppate un gran numero di funzionalità aggiuntive .

Tecnologie della nuova versione

La nuova versione in Python prevede una struttura più semplice e maggiore versatilità rispetto a bash.
La scelta di Python è motivata con le molteplici librerie e classi disponibili che permettono di interfacciarsi in modo molto semplice e efficiente con reti, sistema operativo, I/O ecc

L’interfaccia grafica verrà scritta attraverso Glade e librerie Gtk rendendola gradevole e meno vincolata rispetto a zenity, oltre eseguire modifiche in modo semplice e veloce.

Verrà resa disponibile una versione minimale in modalità testuale in modo da rendere possibile l’utilizzo anche senza Xserver.

Diciamo innanzitutto che in questi mesi non ho scritto molto codice per quanto riguarda il progetto Kerneler. Ho rivisto un po’ quello che gia’ avevo scritto e mi sono documentato invece molto su python.

In realta’ attualmente per ottenere una versione funzionante in python non servirebbe neanche moltissimo tempo il problema è che se prima avevo la voglia di stare ore e ore a programmare ora la conversione è piuttosto noiosa.. Spero ad ogni modo di rimettermi prima o poi e di terminare la versione in python.. la vecchia resta ad ogni modo funzionante in quasi ogni sua parte!

Quest’estate, parlando di cose meno tecniche, sono stato a Santorini e Creta! Non posso far altro che consigliare entrambe le mete che sono assolutamente fantastiche!

Sperando di avere piu’ tempo per aggiornare il blog vi saluto!

• Ho lavorato un po’ sulla pulizia del codice e ho scritto un po’ di pezzi nuovi per gestire la configurazione.. la compilazione l’ho quasi finita ma devo ritoccarla e quindi non l’ho ancora messa su..

• La cosa piu’ importante di questa nuova “alfa release” è il fatto che ho integrato il terminale direttamente dentro al programma.. quindi l’utente può vedere direttamente per ogni pulsante premuto cosa sta succedendo e se qualcosa va storto!

• Credo che come download manager di default userò axel visto che scarica frammentato e c’è praticamente in tutte le distro debian based..

Direi basta.. il lavoro prima di una versione “stabile” non è moltissimo.. però per implementare tutto ciò che faceva kerneler in bash ci vorrà ancora un bel po’ di tempo..

Ah ultima cosa smsBackuper è veramente finito sta volta c’era un bug che non permetteva di visualizzare bene la percentuale di sms cancellati.. ancora un paio di giorni di test e poi lo rilascio sia come .sis che come .py.. Altra cosa che non mi dispiacerebbe fare è una terza versione contenente già l’interprete python in modo da non doverlo installare..

E’ qualche giorno che non scrivo sul blog ma ho fatto un esame e ho avuto un bel po’ di impegni..

• Questa sera mi sono messo di nuovo a scrivere qualche riga e ho aggiunto un paio di funzionalità che dovrei entro fine settimana mettere sul server svn..
• Ho riscritto parte di smsbackuper per renderlo più veloce e penso che ci metterò anche un minimo di interfaccia grafica. Lo schermo per ora rimane acceso nella prossima release farò in modo che sia spento.

Appena vedo che il codice è presentabile come al solito scriverò un post per renderlo pubblico..

Ciao!

Inoltre potrebbe essere utile per configurazioni con il menu testuale..

Attualmente è stato implementato assolutamente a caso   nel senso che ho fatto una prova di come funziona e di come posso usarlo.. credo che lo implementerò a una scheda della finestra principale..

Non ho fatto schermate questa volta perché è un po’ inutile mostrare una schermata simil gnome-terminal

L’implementazione è stata discretamente semplice..

self.kterm=vte.Terminal()

self.kterm.connect(“child-exited”, gtk.main_quit)

self.kterm.fork_command(‘bash’)

font = pango.FontDescription(“monospace normal 12″)

self.kterm.set_font(font)

self.window_term = gtk.Window()

self.window_term.add(self.kterm)

self.window_term.connect(‘destroy’, lambda w: gtk.main_quit())

self.window_term.show_all()

Si inizializza prima di tutto il terminale.
Impostiamo i parametri di uscita e l’interprete (in questo caso bash)
Impostiamo il carattere utilizzando la libreria pango.
E poi aggiungiamo il terminale ad una finestra creata ad hoc.
Per eseguire un comando basterà utilizzare

self.kterm.feed_child(“comando da eseguire\n”)

Importante il \n perché se omesso produrrebbe semplicemente una scrittura del comando sul terminale senza la sua esecuzione

Ciao!

Per accedere per la prima volta al server svn creiamo una cartella e da terminale lanciamo svn in questo modo:

svn co https://kerneler.svn.sourceforge.net/svnroot/kerneler/

I dati ora saranno sincronizzati all’ultima versione.

Ora non è piu’ necessario scaricare tutto ma svn si occupera’ di scaricare solo le differenze. Per aggiornare quindi all’ultima versione (da terminale sempre dentro alla solita cartella):

svn update

Rinnovo l’avviso che questa versione non è per niente stabile ma solo un principio di programma.. Quando giudicherò abbastanza stabile il tutto rilascerò il pacchetto compresso tramite sf.net e non piu’ tramite server svn.

Rinnovo inoltre l’invito a scrivermi commenti e critiche che saranno prese molto seriamente in considerazione!