Monthly Archives: luglio 2013

Buone vacanze!

Comunicazioni Leave a reply

Salve gente!

Dato che molti di voi avranno già fatto depositare la polvere sui loro libri per andare in vacanza, anche il sito del Roma2LUG si prenderà una pausa estiva. Ovviamente tutte le novità sul Linux Day continueranno ad essere tempestivamente comunicate nei nostri soliti canali, perciò rimanete in contatto e a risentirci a Settembre!

Byzantium: una distribuzione a prova di apocalisse zombie

Articoli Leave a reply

Rete Wireless Mesh

Lo scopo del progetto Byzantium è sviluppare un sistema di comunicazione per permettere agli utenti di connettersi tra loro e condividere informazioni anche in assenza di accesso ad Internet. Questo viene fatto attraverso la creazione di una rete ad-hoc mesh wireless che offre servizi che sostituiscono i popolari siti web spesso utilizzati per questo scopo, come Twitter e IRC.

Per realizzare ciò si sta sviluppando una distribuzione GNU/Linux che può essere eseguita da un supporto removibile (CDROM o chiavetta USB) senza necessità di essere installata.
Pur avendo tale caratteristica, Byzantium Linux è in grado di memorizzare i dati generati dal nodo della rete (ovvero da Byzantium stessa) durante il proprio funzionamento in modo da preservare le informazioni di configurazione e di tutti i database creati in precedenza.

Byzantium Linux dal 30 giugno scorso è in fase beta. L’ultima versione ha aggiunto il supporto per packet radio e un sistema di messaggistica distribuito (Microblog) oltre all’IRC (Web chat) e al Notepad. Questa distribuzione è direttamente costruita su Porteus Linux che mira alla compatibilità con Slackware sotto molti aspetti. Byzantium Linux realizza un nodo della rete ad-hoc mesh wireless, ma per utilizzare quest’ultima non è necessario l’uso della distribuzione. Per essere un cliente della rete, cioè per usare una maglia per comunicare, basta solo che il dispositivo utilizzato sia in grado di entrare in modalità di rete ad-hoc e questa è un’operazione possibile per tutti i PC e i computer portatili in generale. Anche molti dispositivi mobili sono in grado di operare in modalità ad-hoc con o senza richiedere l’installazione di software aggiuntivo.
È possibile inoltre collegare un router wireless convenzionale ad un nodo di Byzantium e servire le applicazioni web per i dispositivi “client wireless”. Ci si può così collegare al nodo Bisanzio attraverso il router come se fosse un collegamento ad un qualunque punto di accesso Wi-Fi ordinario.

Vi segnaliamo due articoli, a dimostrazione del fatto di quanto possa risultare utile una simile distribuzione GNU/Linux in caso di calamità naturali o altro:
http://mashable.com/2012/11/21/hillis-byzantium-technology-sandy/
http://techpresident.com/news/23127/red-hook-mesh-network-connects-sandy-survivors-still-without-power

Nicola

Xorg: Come cambiare i DPI

Articoli Leave a reply

Citando Wikipedia:

I punti per pollice, noti anche […] con l’acronimo DPI, sono la quantità di informazioni grafiche che possono essere rese da un dispositivo di output […]. Con il DPI si esprime la quantità di punti stampati o visualizzati su una linea lunga un pollice (2,54 cm). Ad un valore più elevato corrisponde una risoluzione maggiore ed una migliore resa sulle linee inclinate.

 

Si, ma perché dovrei cambiare le mie impostazioni?

Questo valore può essere aumentato e diminuito a nostro piacimento, ma cos’è che effettivamente cambia modificandolo? Se noi impostiamo un valore maggiore, i caratteri dello schermo saranno “più grandi“, ma di una qualità nettamente superiore. Questa funzione potrebbe ritornarci utile se ad esempio vogliamo utilizzare il nostro pc per visualizzare documenti e presentazioni, oppure configurare un display per uno stand pubblicitario. Se invece impostiamo un valore minore i caratteri diventeranno “più piccoli” e perderanno in definizione, ma guadagneremo molto spazio – utile se ci accorgiamo che lo schermo in una macchina dual-boot “sembra più grande” in Windows e “più piccolo” in GNU/Linux.

 

Modificare le impostazioni dei DPI 

Testare “on the fly” i differenti settaggi è molto semplice e, mediante xrandr, uno dei principali tool per la gestione del server grafico Xorg (che molto probabilmente troverete già installato sulla vostra Linux Box) potete così evitare di riavviare il server grafico.

Di default il server Xorg imposta questo valore a 96: possiamo accorgercene con l’esecuzione di un programma che non necessita il riavvio di Xorg per mostrarci la differenze, ad esempio l’esecutore con privilegi di amministratore in GTK gksu, o il tool di configurazione per schede video NVidia, nvidia-settings.

Per settare i DPI temporaneamente, è sufficiente digitare in un terminale o in una barra di esecuzione

xrandr --dpi VALORE

e quindi ad esempio aprire nvidia-settings mediante

nvidia-settings

Rendere effettive le nostre modifiche
Per rendere le nostre modifiche definitive, invece, dobbiamo modificare il file di configurazione di xorg, /etc/X11/xorg.conf. Ovviamente si consiglia di creare una copia di backup del file di configurazione prima di procedere ad eventuali modifiche: da terminale basta eseguire:

su -c "cp /etc/X11/xorg.conf /etc/X11/xorg.conf.old"

inserendo la password di root, oppure

sudo cp /etc/X11/xorg.conf /etc/X11/xorg.conf.old

inserendo la propria password, per poi procedere editando il file di configurazione del server grafico con il nostro editor di testi preferito, ad esempio:


su -c "nano /etc/X11/xorg.conf"
sudo vi /etc/X11/xorg.conf
gksu "gedit /etc/X11/xorg.conf"
gksudo "leafpad /etc/X11/xorg.conf"

 

Raggiungiamo la Section “Screen” ed aggiungiamo le righe:


Option         "UseEdidDpi" "False"
Option         "DPI" "75 x 75"

 

ovviamente modificando opportunamente il valore “75 x 75” con le nostre impostazioni preferite, salviamo il file e riavviamo il server grafico da console ad esempio premendo la combinazione di tasti, ctrl-alt-f1, eseguendo un login come root e digitando:

/etc/init.d/gdm [oppure kdm, slim, lightdm, ...] restart

scegliendo il login manager utilizzato, oppure da utente normale con

sudo /etc/init.d/gdm [oppure kdm, slim, lightdm, ...] restart

 

Edit: potrebbe essere necessario installare il pacchetto degli xfonts relativo alla risoluzione scelta! In debian:

sudo apt-get install xfonts-75dpi*

oppure

sudo apt-get install xfonts-100dpi*

Linux Day 2013: Call For Papers

Comunicazioni Leave a reply

c4pLogo

Roma2LUG, Linux User Group dell’Università di Roma Tor Vergata, è lieto di annunciare l’inizio dei lavori che precederanno la tredicesima edizione del Linux Day.

c4pLD

Affermatosi come una delle occasioni più importanti per promuovere il sistema operativo GNU/Linux e il software Open Source, è l’evento nazionale dedicato a tutti coloro che sposano la filosofia alla base di queste due realtà ed a tutti i curiosi che per la prima volta si approcciano al software libero.

Due mondi paralleli che, grazie alla costante diffusione a livello desktop e soprattutto in ambiente enterprise server, hanno contribuito alla crescente rilevanza di un evento divenuto oramai irrinunciabile per imprese e professionisti.

Collabora mettendo a disposizione la tua professionalità, il tuo entusiasmo e la tua passione: partecipa anche tu all’evento più open che ci sia! Insieme renderemo sempre più grande una manifestazione che negli anni ha avuto un sempre maggiore successo di pubblico.

Se hai in mente un argomento interessante e vuoi collaborare alla riuscita dell’evento, inviaci la tua proposta per uno speech e noi risponderemo nel più breve tempo possibile.

Giunta alla sua tredicesima edizione, la linea guida della più importante manifestazione nazionale dedicata al sistema operativo Open Source per eccellenza è: “L’innovazione di tutti, per tutti”.

COME PARTECIPARE

Per proporre il tuo intervento basta inviare (entro e non oltre il 20 agosto c.a.) una e-mail a roma2lug [at] gmail [dot] com con riferimento in oggetto LD13.

Indica nome e cognome del/i relatore/i, e-mail, numero di telefono, una breve biografia personale, il titolo dell’intervento e un piccolo abstract riguardante il contenuto che proponi.

GDB: DON’T PANIC!

Articoli Leave a reply

don_t_panic_buttonChiunque di noi si sia cimentato almeno una volta nella programmazione C, sa quanto questa sia versatile ed utile per molte delle applicazioni più complesse, prime fra tutte i sistemi operativi.

È pur vero che se si è provato almeno una volta a creare un programma, anche il più semplice, questo puntualmente la prima volta si è rivelato un fiasco, andando in errore, o ci si è trovati ad affrontare il temibile SEGMENTATION FAULT, o in italiano, Errore di Segmentazione.

Il C non è molto di aiuto nello scovare queste inefficienze dei programmi e può portare la persona più santa del mondo ad imprecare come il miglior scaricatore di porto.

Esiste però un rimedio a tutto questo o almeno un piccolo aiuto: il suo nome è GDB, un applicativo da linea di comando in grado di permetterci un debug degno dei migliori linguaggi di programmazione ed anche di più.

Sottolineiamo che in questo articolo non abbiamo intenzione di scrivere una guida completa e perfetta di questo programma, in quanto non siamo in possesso delle conoscenze per poterlo fare; vogliamo però aiutare chi si trova nelle difficoltà precedentemente accennate, a districarsene come abbiamo fatto noi con un po’ di conoscenze da auto didatta.

Vediamo innanzitutto come questo programma funziona: è in grado di eseguire tutti gli eseguibili, ma eccelle con l’input di speciali file compilati in modo da mantenere molte delle caratteristiche che hanno in fase di programmazione (numeri di riga, nessuna ottimizzazione, etc…).

Per creare un eseguibile di questo tipo dobbiamo mettere mano ad un Makefile, o comunque a gcc, e compilare i nostri file C utilizzando la seguente opzione:

gcc -g [FILES] -o [OUTPUT FILE]

Una volta generato il nostro file, possiamo cominciare a debuggarlo: eseguiamo quindi sempre da riga di comando, nella cartella dove abbiamo generato il nuovo file:

gdb [OUTPUT FILE]

se però ci troviamo nella situazione in cui il nostro programma richieda dei dati in input dobbiamo far si che questi pervengano all’eseguibile, e scopriremo a nostre spese che non è possibile farlo dopo la chiamata di gdb. Andremo quindi ad utilizzare questo comando:

gdb –args [OUTPUT FILE] [ARGS]

Siamo a cavallo! Il programma è stato caricato in memoria dall’applicativo e possiamo cominciare a lavorare! Ma come?!
segmentation-faultGdb si presenta come un programma a linea di comando ed è molto di aiuto per l’utilizzo: basta scrivere il domando “help” per avere un’idea di come poter cominciare.

Vediamo un utilizzo base tipico. Per cominciare proviamo ad eseguire un programma: trovandoci nella shell di gdb digitiamo il semplice carattere “r” e subito il programma si eseguirà, come si eseguirebbe ad un semplice avvio del vero eseguibile; c’è però un aspetto interessante: anche senza l’ausilio dei break point, tipico esempio di esecuzione di programma in modalità debug, gdb è in grado di catturare segnali (es: SIGPIPE) o i temibili Segmentation Fault. Quando questo accade, il programma viene fermato, ponendo in evidenza la riga esatta in cui questo è avvenuto, ed è possibile visualizzare i valori delle variabili presenti in quel contesto, nel loro stato attuale; scrivendo nella shell

print [NOME VARIABILE]

o

print [FUNZIONE RITORNANTE]

possiamo verificare quale abbia causato l’errore e provare a capirne la motivazione.

Potrebbe essere però utile seguire l’esecuzione passo passo, cosi da capirne la logica mentre questa viene eseguita.

Porre un break point è un’operazione molto semplice: scrivendo semplicemente

break

possiamo porre un’interruzione nell’istruzione subito successiva a quella attuale. Questo tipo di utilizzo è però molto raro e poco utile; è di gran lunga più utile il seguente comando

break [NOME FUNZIONE]

in questo modo non appena la logica del programma ci porta all’interno della funzione indicata, l’esecuzione viene bloccata e possono essere stampati i valori delle variabile, verificare il ritorno delle funzioni, eseguire la prossima istruzione (Comando: “next” o semplicemente “n”) o riportare il programma ad un esecuzione lineare, fino almeno al prossimo break point (Comando: “continue”).

A volte una funzione può essere molto lunga e potrebbe non essere necessario eseguire le prime righe di codice per effettuare un debug; può risultare utile, se si è a conoscenza del numero di riga dal quale vogliamo cominciare, la seguente variante

break [NUMERO DI RIGA]

in grado di bloccarci solamente quando raggiunta tale riga, evitando tediose e ripetute pressioni di tasti.

I progetti C sono solitamente divisi in molti file di codice, alcuni dei quali contengono funzioni con stesso nome di quelle di altri. Come fa gdb a capire su quale di queste bloccarsi? E se il file C non contiene il dato numero di riga, in quanto presente in un altro file?

Ci vengono in aiuto due ulteriori versioni di questo comando, dedicate alle nostre specifiche richieste

break [NOME FILE]:[NOME FUNZIONE]

e

break [NOME FILE]:[NUMERO DI RIGA]

Ultima (nella nostra trattazione), ma non banale o poco utile, variante di questo comando è la seguente

break … if [CONDIZIONE]

questa ci permette di eseguire il debug nel migliore dei modi: al verificarsi di un dato evento, permettendo di facilitare ulteriormente il nostro lavoro.

L’utilizzo di gdb può essere immenso. Il nostro articolo purtroppo non può coprire tutti i casi, ma vi rimandiamo a seguente link http://www.chemie.fu-berlin.de/chemnet/use/info/gdb/ dove è possibile quietare i dubbi più intricati, se il nostro articolo non è riuscito a delucidarvi.