GiorgioRavera.it

il mio blog: ciò che penso e faccio, trucchi di programmazione, linux, reti e molto altro
Archivio per Novembre 2009

Per un po’ di tempo ho cercato di capire perché applicazioni opengl come Armadillo Roll non funzionano correttamente. Dopo una lunga ricerca su forum e blog ho capito che il problema è legato alla libreria hgl (/system/lib/libhgl.so). Tale libreria ha dei problemi e occorre sostituirla per il corretto funzionamento delle applicazioni. Una versione corretta è quella distribuita da HTC e presente nell’immagine di sistema reperibile all’indirizzo http://developer.htc.com/google-io-device.html (System Image per Android 1.5). Dal file .zip bisogna estrarre system.img ed estrarre il file libhgl.so. Per chi non volesse compiere tutti questi passaggi può scaricarlo da questo link. Una volta installato il file si può procedere a caricarlo sul cellulare seguendo i passi descritti qui sotto: Avviare il Samsung Galaxy in modalità Recovery (volume basso + tasto chiamata + tasto accensione) Collegare il cellulare al pc ed avviare ed entrare nel sistema tramite adb (fornita dall’android SDK) Eseguire i seguenti comandi: # cd / / # umount /system/ / # mount /dev/block/mtdblock1 /system / # mv /system/lib/libhgl.so /system/lib/libhgl.so.old / # mv /sdcard/libhgl.so /system/lib / # reboot Riavviate il cellulare e il gioco è fatto.

Capita spesso che in una rete aziendale sia presente un proxy con autenticazione NTLM. Tali proxy limitano il traffico nella rete e, in corrispondenza di parole riconosciute pericolose o collegate a contenuti non permissibili, bloccano l’accesso a determinati siti. Si consideri ad esempio il caso in cui si vogliano cercare componenti analogiche: spezzando la parola si ottiene anal-ogiche. La prima parte può trarre in inganno il filtro sul proxy e bloccare l’accesso ai siti che trattano questo argomento. In questo post vediamo come fare per superare i limiti imposti da una configurazione di questo tipo.

Un proxy trasparente è un server proxy che non necessita di alcuna configurazione da parte dell’utente. In ambiente linux può essere facilmente realizzato attraverso squid e iptables. In questo post vediamo come configurare squid per questo scopo.

Situazione tipica: Generatore di informazioni (eventi, ordini, servizi) Gestore di informazioni N Esecutori M Clienti In questo contesto è necessaria una corretta sincronizzazione utilizzando uno schema comune: Il generatore di informazioni ha un puntatore al generatore di informazioni. Ogni tanto genera un infomazione e la va a settare all’interno del generatore, tramite una opportuna funzione, risvegliando il thread associato al gestore. Il gestore ha al suo interno una lista di esecutori e di informazioni. Se non ci sono informazioni da trattare resta in wait. Appena viene svegliato dal generatore, cerca un esecutore libero, gli va a settare l’informazione da elaborare tramite una funzione della classe Esecutore e lo sveglia. Se tutti gli esecutori sono impiegati attendo che si liberi un esecutore addormentandomi su un oggetto diverso da quello che viene usato dal Generatore di informazioni. Gli esecutori sono thread con un run molto semplice: ciclo all’infinito, se non devono lavorare dormono, una volta che vengono svegliati simulano il lavoro stando in sleep per un tempo randomico di secondi e notificano al Gestore di aver terminato il lavoro. Esercizi di questo tipo si possono basare su questo modello tenendo conto delle opportune varianti del caso.

Può capitare spesso che, quando si devono gestire più interfacce di rete, i nomi non siano proprio quelli che noi vorremmo, oppure che si invertano da un boot e l’altro. Supponiamo di avere nel sistema con 2 interfacce di rete 00:00:00:00:00:00 -> scheda primaria 00:00:00:00:00:11 -> scheda secondaria Vogliamo che la prima assuma come nome eth0 e la seconda eth1. Per fare ciò è necessario modificare il file: /etc/udev/rules.d/XXpersistent-net.rules ove XX dipende dalla distribuzione e dalla versione di udev che state usando e aggiungere le seguenti righe: SUBSYSTEM==”net”, DRIVERS==”?*”, ATTRS{address}==”00:00:00:00:00:00″, NAME=”eth0″ UBSYSTEM==”net”, DRIVERS==”?*”, ATTRS{address}==”00:00:00:00:00:11″, NAME=”eth1″

Ecco alcune regole utili per scrivere algoritmi concorrenti: Accesso sincronizzato a tutti gli elementi (oggetti o variabili) condivisi. Istruzioni di Test and Set atomiche: lock, valutazione di una condizione ed eventuale wait devono essere racchiusi all’interno della medesima regione critica (synchronized o mutex). Tutte le chiamate alla funzione wait dovrebbero essere condizionate per evitare starvation. Qualora non lo fossero, è necessaria la presenza di un demone, svegliato dai clienti prima di addormentarsi, che svegli i Thread. Non separare Sincronizzazione da Sincronizzato: se un oggetto necessita di essere condiviso è necessario svilupparlo per renderlo concorrente direttamente al suo interno, non attraverso l’incapsulazione in un wrapper. Usare mappe di oggetti per sincronizzare gruppi di Thread che attendono il medesimo evento oppure, per una specifica richiesta, mappe di Contenitori che si portano dietro l’evento più la lista di Thread in attesa di esso. Evitare flag, usare piuttosto blocchi esclusivi nidificati (synchronized) in modo da generare una coda implicita su quello più esterno. Barrier Sync attraverso una liste di Thread: fino a quando ha almeno un elemento, nessun altro thread può procedere allo stato successivo. L’ultimo che esce sveglia tutti gli altri. Race Condition: evitare che Thread accedano a risorse a caso addormentandoli e svegliando solo quelli che possono acquisire il lock, ordinandoli in base alle risorse richieste. Una volta svegliati, è casuale l’accesso tra loro, ma è garantito che venga ottimizzato il consumo di risorse. Date due sequenze di istruzioni atomiche A e B, la loro unione AB non è atomica.