domenica 17 giugno 2012

Mondo Monopoli



Immagino avrete giocato almeno una volta a Monopoli da bambini. Vicolo Stretto, Parco della Vittoria, le Probabilità, gli Imprevisi. Bei ricordi...
Ok, ma vi ricordate quando finiva una partita?
I giocatori venivano eliminati man mano che andavano in bancarotta, quando non riuscivano a pagare un debito con i contanti e le ipoteche che possedevano, e alla fine ne restava solo uno, il vincitore.

Immaginate se le regole non avessero previsto una fine del gioco: i giocatori non vanno più in bancarotta ma possono indebitarsi per pagare i pedaggi. Il gioco sarebbe andato avanti all'infinito con pochi giocatori sempre più ricchi e molti altri sempre piu' indebitati. Sicuramente dopo qualche ora di gioco qualcuno in passivo si sarebbe alzato esclamando "mo che du maroun!", seguito prontamente dagli altri indebitati.

Ai giocatori ricchi non sarebbe rimasto che smettere, dato che primo erano in pochi e non si sarebbero divertiti, secondo anche loro cominciavano ad averne le palle piene, terzo il più stressato degli indebitati aveva rovesciato loro addosso il tabellone.
Del resto, era solo un gioco: coi soldi del Monopoli mica ci puoi andare a comprare un gelato.

Ora, immaginate il mondo come un gigantesco Monopoli.
Certo, l'economia reale e' molto più complessa, ma si basa sullo stesso elemento: il denaro. Pezzi di carta e nemmeno piu' quelli, ora il vostro conto è solo un numero memorizzato in qualche database.

Se chi manovra l'economia accumula sempre piu' a nostre spese, fino a ridurci alla fame e all'indebitamento cronico, cosa aspettiamo ad alzarci dal gioco?
La soluzione è semplice, basta solo essere in tanti a condividerla: togliamo valore al loro denaro, non accettiamolo più come merce di scambio. Non dico di tornare al baratto, possiamo creare una nostra moneta, una moneta reale che serva a noi, non un numero.

Coi loro soldi del Monopoli non potranno andarsi a comprare il gelato: sveglia popolo, è ora di ribaltare il tabellone.

giovedì 12 aprile 2012

Colori cambiati nei video di Youtube

Ultimamente avete l'impressione di vivere tra i marziani, vedete facce blu nei video di Youtube e similari? Il rosso pare completamente scomparso, e anche gli altri colori sono cambiati.

Tranquilli, non siete impazziti, la colpa è di un bug nella nuova versione del plugin Flash, che ha problemi coi driver Nvidia.

Per fortuna la soluzione è semplice: basta "riavviarlo".



Istruzioni per Chrome

Aprite una nuova scheda e digitate

chrome://plugins/


individuate la sezione che inizia con queste due righe


Flash Versione: 11.2 r202
Shockwave Flash 11.2 r202

(la vostra versione potrebbe essere diversa)

e cliccate sul link Disabilita in fondo alla sezione, poi cliccate sul link Abilita.

Ricaricate la pagina con il video, se i colori non sono tornati a posto provate a chiudere Chrome e a riavviarlo.


Istruzioni per Firefox

Dal menù Strumenti selezionate Componenti aggiuntivi, nella parte sinistra della pagina che si aprirà selezionate la linguetta Plugin, nella parte destra cercate Shockwave Flash, cliccate sul pulsante Disattiva e poi su Attiva.

Se necessario, riavviate Firefox.



Edit 13/04/12


Mi sono accorto che purtroppo che il metodo descritto sopra funziona solo con certi video, molti rimangono ancora col problema delle "facce blu".

Per fortuna esiste un'altra soluzione: disabilitare l'accelerazione hardware nel plugin Flash.

La procedura è la stessa sia per Chrome [1] che per Firefox:

cliccate col tasto destro sul video nella pagina di Youtube e scegliete Impostazioni, vi apparirà una finestrella con una sola casella (Abilita accelerazione hardware), deselezionatela e cliccate su Chiudi, poi ricaricate la pagina.

[1] A volerla dir tutta, questa procedura non sono riuscito ad eseguirla con Chrome, perchè appena appare la finestrella, il plugin si pianta e si blocca tutto. Fortunatamente Firefox si comporta un po' meglio, e la modifica, una volta fatta, funziona per tutti i browser.

lunedì 12 marzo 2012

[Workaround] Crash della shell di Gnome3 avviando una ricerca in Attività (schede Nvidia)

Lo so, il titolo non è dei più semplici, ma chi usa Gnome3 ed ha aggiornato i driver Nvidia all'ultima versione, sa di cosa sto parlando. :)

A causa di un bug dei driver Nvidia versione 295, non appena si digita una lettera nella casella di ricerca di Attività (ma attenzione: non tutte le lettere, lo fa con la G, la M, e non so quante altre) la shell di Gnome3 va inesorabilmente in crash e si riavvia (quando va bene).

Il bug è grave, e se dobbiamo aspettare gli aggiornamenti di Nvidia, campa cavallo... c'è chi suggerisce un downgrade del driver alla versione 290, ma cercando informazioni in rete ho capito che la cosa è piuttosto complicata e dagli esiti a volte imprevedibili.

Semplice invece è un workaround che ho trovato spulciando tra un linux forum e l'altro, e che vi riassumo qui sotto in poche righe.

Aprite una finestra di terminale e date i seguenti comandi:

cp ~/.local/share/recently-used.xbel ~/.local/share/recently-used.xbel.old
echo "" > ~/.local/share/recently-used.xbel
sudo chattr +i ~/.local/share/recently-used.xbel


Fatto? Fatto. Provate a fare ora una ricerca in Attività, se non ci credete.


Cosa abbiamo fatto?
Dopo aver fatto una copia di sicurezza del file recently-used.xbel, praticamente l'abbiamo svuotato (secondo comando) e l'abbiamo reso non modificabile (terzo comando).


Pare infatti che il problema sia dovuto a voci non valide che librsvg2 va a scrivere in recently-used.xbel, che quindi in lettura provocano il crash della shell. Svuotando quest'ultimo e impedendone la scrittura, si evita il crash.

A cosa serva recently-used.xbel, si può intuire dal nome: probabilmente contiene le ultime ricerche effettuate con Attività, che quindi altrettanto probabilmente non saranno più disponibili.

Consiglio quindi di provare a rendere riscrivibile recently-used.xbel non appena uscirà una nuova versione dei driver Nvidia; potremo farlo facilmente col comando

sudo chattr -i ~/.local/share/recently-used.xbel


Fino ad allora... meglio rinunciare alle ultime ricerche, piuttosto che dover sopportare un bug così fastidioso.


Edit 27/03/12: dopo alcuni aggiornamenti di Ubuntu il file recently-used.xbel è tornato riscrivibile da solo, e il problema si è ripresentato (evidentemente il bug non è stato ancora corretto). Per eliminarlo nuovamente non ho fatto altro che ripetere la procedura qui sopra descritta. Ripetetela periodicamente ogni volta che il problema si ripresenterà: si può ragionevolmente prevedere che quando il bug verrà corretto, recently-used.xbel tornerà riscrivibile e noi, in assenza del problema, non ce ne accorgeremo nemmeno.

sabato 22 ottobre 2011

Ubuntu 11.10 e Dropbox - Menu contestuale ed icone scomparse

Gli utenti di Dropbox che hanno installato la nuova versione di Ubuntu 11.10, Oneiric Ocelot, troveranno l'amara sorpresa di veder scomparire le icone personalizzate nella cartella di Dropbox, e, quel che e' peggio, non troveranno piu' il menu contestuale di Dropbox in Nautilus.

Per fortuna la soluzione e' semplice, basta aprire una finestra di terminale e dare i seguenti comandi:


sudo ln -s /usr/lib/nautilus/extensions-2.0/libnautilus-dropbox.a /usr/lib/nautilus/extensions-3.0/libnautilus-dropbox.a
sudo ln -s /usr/lib/nautilus/extensions-2.0/libnautilus-dropbox.la /usr/lib/nautilus/extensions-3.0/libnautilus-dropbox.la
sudo ln -s /usr/lib/nautilus/extensions-2.0/libnautilus-dropbox.so /usr/lib/nautilus/extensions-3.0/libnautilus-dropbox.so

poi chiudete e riaprite la finestra di Nautilus, ed ecco riapparire le icone ed il menu contestuale.


sabato 16 luglio 2011

JDownloader: Could not initialize NSS

Se usate JDownloader sotto Debian o Ubuntu con Java 6, dopo un dist-upgrade di questi giorni puo' capitare che non si riesca piu' a farlo partire.

Se proviamo a farlo partire da riga di comando otteniamo questo errore:
Exception in thread "AWT-EventQueue-0" java.security.ProviderException: Could not initialize NSS


e, piu' in basso, possiamo notare questa interessante riga:
Caused by: java.io.FileNotFoundException: /usr/lib/libnss3.so


Evidentemente, a causa di un bug, java non riesce piu' a trovare la libreria /usr/lib/libnss3.so, che in effetti non risulta essere in quella cartella.

La soluzione e' all'interno del file /etc/java-6-openjdk/security/nss.cfg, ma prima dobbiamo controllare in quale cartella e' contenuta la libreria che cerchiamo (puo' variare a seconda della distro linux).


Apriamo una finestra di terminale e digitiamo
locate libnss3.so


io, ad esempio, ho ottenuto questo risultato:
/usr/lib/firefox/libnss3.so
/usr/lib/i386-linux-gnu/libnss3.so
/usr/lib/i386-linux-gnu/libnss3.so.1d



e' evidente che, nel mio caso,  il percorso che mi interessa e' il secondo, quindi lo selezioniamo e lo copiamo.


Ora possiamo andare a modificare il file nss.cfg, ma prima creiamo una copia di sicurezza:
sudo cp /etc/java-6-openjdk/security/nss.cfg /etc/java-6-openjdk/security/nss.cfg.old


quindi possiamo editarlo con
gksu gedit /etc/java-6-openjdk/security/nss.cfg


la riga che ci interessa e' questa
nssLibraryDirectory = /usr/lib/


che io ho sostituito con
nssLibraryDirectory = /usr/lib/i386-linux-gnu/

e che voi sostituirete indicando il percorso copiato prima (senza la parte finale "libnss3.so", a noi interessa solo indicare il percorso dove trovarlo).

Salvate nss.cfg e lanciate JDownloader, che riprendera' a funzionare.

venerdì 28 gennaio 2011

Configurare exim4 per mandare la posta attraverso Gmail

Logcheck è un ottimo strumento per tenere sotto controllo i logs di Ubuntu: ne fa un riassunto salvando solo le righe importanti, e ce lo posta all'indirizzo che definiamo nella sua configurazione.

L'installazione di logcheck possiamo farla da synaptic (il Gestore Pacchetti), per la configurazione invece potete trovare una buona guida qui (la prima pagina riguarda l'installazione su Debian; dalla seconda pagina viene trattata la configurazione, che si adatta tranquillamente anche ad Ubuntu).

Già, ma che c'entra logcheck con exim4? C'entra, c'entra, per il semplice fatto che installando logcheck, Ubuntu installa anche, come dipendenza, il pacchetto exim4 per gestire le email riassuntive che dovrà mandarvi; e potrebbe capitarvi, come è successo a me, che non vi basti che quei messaggi vengano spediti al vostro indirizzo locale (come fa di default), ma vorreste piuttosto che vi vengano consegnati al vostro indirizzo Gmail, cosi' da poterli controllare anche quando non siete davanti al vostro pc.

Come fare?

La procedura non è delle più semplici, ma se seguirete le mie istruzioni passo passo, raggiungeremo insieme il nostro scopo.

Fatevi sempre una copia dei files che andrete ad editare, prima di modificarli e salvarli.

Pronti? Procediamo.

Fase 1

  • da terminale, digitate sudo dpkg-reconfigure exim4-config
  • si aprirà un wizard, che vi guiderà passo passo nella configurazione di exim4; in questa guida eviterò di citare le pagine (come la prima che vi appare) nelle quali dovete solo dare un OK per andare avanti, tanto non si può fare altro e quindi non potete sbagliarvi
  • alla prima scelta che si presenta, scegliamo posta inviata tramite uno «smarthost»; ricevuta via SMTP o fetchmail
  • nella pagina successiva vi verrà richiesto il nome di dominio della macchina locale, ovvero quella parte di nome che segue la @ in qualsiasi indirizzo locale (esempio: se il vostro indirizzo locale è pippo@miocomputer, il dominio è miocomputer). Per intenderci, il vostro indirizzo locale è quello che appare dietro il prompt dei comandi quando aprite un terminale, il mio (Nirvanalx) lo potete vedere nell'immagine che segue. Ad ogni modo, il wizard dovrebbe farvelo trovare già pronto, quindi basta dare un Invio


  • la domanda successiva riguarda gli indirizzi IP sui quali attendere connessioni SMTP in ingresso: qui dovete rispondere 127.0.0.1
  • nella pagina dopo (Altre destinazioni per conto delle quali accettare posta) potete lasciare il campo in bianco, quindi premete Invio
  • stessa cosa per il campo successivo (Sistemi per i quali fare il «relay»): lasciate il campo in bianco e premete Invio
  • subito dopo vi verrà chiesto l'indirizzo IP o hostname per lo «smarthost» in uscita: qui dovete inserire smtp.gmail.com::587
  • alla domanda successiva (Omettere il mail name locale dai messaggi in uscita?) rispondete NO
  • dopo un paio di invii, vi verrà richiesto se mantenere al minimo il numero di richieste DNS (dial-on-demand), anche qui dovete rispondere NO
  • alla richiesta di modalità di consegna per la posta locale scegliete Formato mbox in /var/mail/
  • poi vi chiederà se dividere la configurazione in molti piccoli file, rispondete NO
  • l'ultima richiesta (Destinatari della posta di root e postmaster) potete lasciarla in bianco e premere Invio
  • a questo punto il wizard terminerà e verrà riavviato in automatico il servizio di mail (MTA)

Bene, è finita? Vi piacerebbe... ora possiamo passare alla

Fase 2

  • sempre da terminale con permessi di root, editate il file /etc/exim4/exim4.conf.template digitando

          gksu gedit /etc/exim4/exim4.conf.template &

  • trovate la riga ".ifdef DCconfig_smarthost DCconfig_satellite", e in quella sezione (prima della riga ".endif") aggiungete le seguenti righe


          send_via_gmail:
             driver = manualroute
             domains = ! +local_domains
             transport = gmail_smtp
             route_list = * smtp.gmail.com


         se nel file che state editando trovate qualsiasi altro smarthost che
         contenga la riga "domains = ! +local_domains", dovete cancellare
         o commentare (con # all'inizio della riga) tutte le righe che lo
         riguardano, come nell'immagine che segue


  • trovate la riga "begin authenticators", e aggiungeteci sotto le seguenti righe
          gmail_login:
              driver = plaintext
              public_name = LOGIN
              client_send = : <indirizzo gmail> : <password>

         sostituendo i campi "<indirizzo gmail>" e "<password>" con i vostri dati
  • cercate se ci sono altri authenticators che contengono la stessa riga "public_name = LOGIN", se esistono cancellateli o commentateli
  • cercate il commento
         "### transport/30_exim4-config_remote_smtp_smarthost"

          e aggiungete sotto, in quella sezione

          gmail_smtp:
              driver = smtp
              port = 587
              hosts_require_auth = $host_address
              hosts_require_tls = $host_address
  • in fondo al file, esiste una sezione che comincia con questa riga
          ".ifndef AUTH_CLIENT_ALLOW_NOTLS_PASSWORDS"

          e finisce dopo 31 righe con un ".endif": bene, questa sezione va tutta
          cancellata o commentata (attenzione che di quelle righe ce ne sono
          due, partite a commentare dalla prima), come potete vedere nel
          prossimo screenshot


  • Salvate e chiudete il file

E ora siamo pronti a passare alla prossima fase (tranquilli, abbiamo quasi finito):

Fase 3
  • da terminale, eseguite sudo update-exim4.conf
  • e infine eseguite sudo /etc/init.d/exim4 restart

Se non notate messaggi di errore, vuol dire che tutto è andato bene: ora il vostro exim4 è pronto per spedire la posta via Gmail
Per provarne velocemente il funzionamento, spedite una mail da riga di comando e poi controllate nella vostra casella Gmail se la ricevete:

echo "Ciao come va?" | mail -s "Saluti" <indirizzo gmail>

Non vi rimane che configurare in logcheck (o in qualsiasi altro programma usi exim4 per spedire la posta) il vostro indirizzo Gmail come destinatario dei messaggi.

Nota importante, ricordatevi che Gmail consente di spedire un massimo di 100 messaggi al giorno per ogni account usando SMTP, quindi occhio a non esagerare!

venerdì 7 gennaio 2011

Server samba e link simbolici scomparsi in LAN

Un giorno mi sveglio e su Ubuntu 10.10 trovo un nuovo problema: accedendo ad una cartella condivisa col server samba, non vengono più visualizzati i link simbolici (o symlink).


Cercando un po' in giro apprendo che il problema è stato riscontrato su server Debian e Ubuntu, con client Leopard e SnowLeopard, e che presumibilmente il problema riguarderà anche altre distribuzioni di Linux.


Tranquilli, la soluzione è semplice, richiede una piccola modifica alla configurazione del server samba:

  • Editate smb.conf, ad esempio digitando da terminale
          gksu gedit /etc/samba/smb.conf
  • Nella sezione desiderata (o in “[global]”) aggiungete queste righe, o verificatene i valori:
          follow symlinks = yes
          wide links = yes
          unix extensions = no

  • Salvate smb.conf
  • Riavviate il server samba, digitando da terminale
          sudo service smbd restart

Fatto. Come per incanto, i link simbolici riappariranno nelle vostre cartelle condivise.