Innanzitutto è necessario installare netselect e quindi:

apt-get install netselect

Va quindi lanciato col l’opzione -vv (“very verbose mode”), seguito dalla lista dei mirror da testare. Ad esempio:

netselect -vv debian.bononia.it debian.fastweb.it ftp.it.debian.org debian.dynamica.it debian.fastbull.org freedom.dicea.unifi.it giano.com.dist.unige.it mi.mirror.garr.it mirror.units.it

Nel mio caso:

root@mirko-laptop:/home/mirko# netselect -vv debian.bononia.it debian.fastweb.it ftp.it.debian.org debian.dynamica.it debian.fastbull.org freedom.dicea.unifi.it giano.com.dist.unige.it mi.mirror.garr.it mirror.units.it
Running netselect to choose 1 out of 9 addresses.
...............................................................................
freedom.dicea.unifi.it                  82 ms  22 hops   90% ok ( 9/10) [  291]
debian.fastbull.org                     39 ms  16 hops  100% ok (10/10) [  101]
giano.com.dist.unige.it               9999 ms  30 hops    0% ok
debian.fastweb.it                       28 ms  12 hops   90% ok ( 9/10) [   68]
ftp.it.debian.org                       40 ms  17 hops   90% ok ( 9/10) [  121]
mi.mirror.garr.it                       29 ms  16 hops   75% ok ( 6/ 8) [  101]
debian.dynamica.it                      33 ms  14 hops   90% ok ( 9/10) [   88]
debian.bononia.it                     9999 ms  30 hops    0% ok
mirror.units.it                         40 ms  19 hops   90% ok ( 9/10) [  127]
   68 debian.fastweb.it

Modificate il vostro /etc/apt/sources.list di conseguenza.

Per qualsiasi altra cosa, fate sempre riferimento al manuale:

man netselect

netselect

Taccio a proposito di:

1. motivi che portano alla scelta di adottare software proprietario o che si appoggia a software proprietario, software non libero, software non-multipiattaforma o con problemi/scarse prestazioni su alcune piattaforme, software non flessibile e via dicendo. Soprattutto quando (vedi caso della Rai) sono tenuto anche a pagare. Ma è già assodato come ci siano in giro troppi ingegneri, esperti di informatica o sviluppatori che, anche se con laurea alla mano, dovrebbe andare a fare un altro lavoro causa pochezza mentale;
2. motivi che portano a sviluppare un software, farlo adottare da tanti e in contesti così cruciali da fare in modo che diventi un software essenziale e poi non aggiornarlo regolarmente (l’ultima release stabile risale – lo ripeto – ad aprile 2011).

Vengo a spiegarvi come ho risolto sulla Debian, procedura che dovrebbe essere valida anche su altre distribuzioni GNU/Linux.  Anzitutto dovete sapere che l’estensione funziona benissimo (almeno io la sto usando su Firefox 9), è solo che per ogni estensione viene indicata una versione massima e una minima dei vari browser e presumibilmente la prima sarà l’ultima versione disponibile al momento della versione dell’estensione.

Dunque:

1. scaricate (non installandola, ma scaricandola effettivamente sul vostro hard disk) l’estensione da qui. Con lo stesso Firefox/Iceweasel dovrebbe essere sufficiente fare click destro sul link e quindi scegliere l’opzione “Salva destinazione con nome…”. Altrimenti, c’è sempre il divino wget:

   wget http://www.go-mono.com/moonlight/downloads/3.99.0.3/novell-moonlight-3.99.0.3-x86_64.xpi

2. il file scaricato è un archivio, quindi decomprimetelo (assumo sappiate già come fare). In caso di problemi, rinominatelo come un .zip;
3. entrate nella directory estratta e aprite il file install.rdf, con un qualsiasi editor di testo. Quindi cercate le seguenti righe:

   <em:targetApplication> <!-- Firefox -->
      <Description>
      <em:id>{ec8030f7-c20a-464f-9b0e-13a3a9e97384}</em:id>
      <em:minVersion>1.5</em:minVersion>
      <em:maxVersion>4.0.*</em:maxVersion>
      </Description>
   </em:targetApplication>

   Modificate la versione massima, ad esempio così:

   <em:maxVersion>10.*</em:maxVersion>

   Non dovete rimuoverla, deve essere presente, volutamente potete indicare qualsiasi numero (anche 100).
   Quindi salvate il file;

4. cancellate la directory META-INF;
5. ricreate l’archivio come file .zip. Fate attenzione a creare un archivio non della directory estratta (altrimenti, al momento dell’installazione, vi dirà che l’estensione risulta danneggiata), ma dei file contenuti nella directory. Il file risultante dovrebbe chiamarsi novell-moonlight-3.99.0.3-x86_64.xpi_FILES.zip, modificatelo affinché abbia il nome come quello originale;
6. in Firefox andate su “Strumenti”, “Componenti aggiuntivi”, fate click sul pulsante alla sinistra della barra di ricerca e scegliete l’opzione “Installa componente aggiuntivo da file…”. Selezionate il file, attendete il termine dell’installazione e riavviate il browser.

Fatto.

Fonte: http://bit.ly/tM4rS2

Bene, Amarok 1.4 è ancora presente – al momento in cui scrivo – su Debian Lenny, l’attuale old-stable: vediamo come reperirlo, come conservarlo (prima o poi i repository di Debian Lenny andranno off, anche se con un po’ di impegno si può accedere ancora a repository molto più vecchi, che qualcuno conserva qua e là) e come installarlo.

Innanzitutto, se i repository di Debian Lenny sono ancora disponibili, configuriamo il pinning (se non lo abbiamo ancora fatto) come spiegato qui e poi aggiungiamo al nostro sources.list il repository:

deb http://ftp.it.debian.org/debian/ lenny main contrib non-free

Fatto questo, aggiorniamo e poi scarichiamo i pacchetti che ci servono (li scarichiamo proprio per conservarli per il futuro):

aptitude update
aptitude -t lenny download amarok amarok-common amarok-engine-xine libgpod3-nogtk libmtp7 libmysqlclient15off

I pacchetti verranno scaricati nell’attuale directory e dovrebbero essere (può cambiare l’architettura):

amarok_1.4.10-2lenny1_i386.deb
amarok-common_1.4.10-2lenny1_all.deb
amarok-engine-xine_1.4.10-2lenny1_i386.deb
libgpod3-nogtk_0.6.0-6_i386.deb
libmtp7_0.2.6.1-3_i386.deb
libmysqlclient15off_5.0.51a-24+lenny5_i386.deb

Semmai i repository di Lenny non dovessero essere più presenti, ho preparato un archivio con questi pacchetti per 32bit e 64bit. Scaricate e decomprimete.

Fatto questo, è necessario procedere con l’installazione di alcune dipendenze necessarie:

aptitude install kdelibs4c2a libqt3-mt libifp4 libkarma0 libnjb5 libpq5 libtunepimp5

Notate che queste dipendenze dovrebbero essere presenti anche nella vostra versione di Debian, quindi in questo caso non si necessita di pinning. Le dipendenze non più presenti (cioè obsolete) le abbiamo già reperite. Bisogna prima installare queste perché il resto verrà installato tramite dpkg, che non si preoccupa di installare eventuali dipendenze mancanti.

Infatti, a questo punto non resta che installare Amarok e le dipendenze ormai obsolete. Nella cartella in cui abbiamo precedentemente scaricato:

dpkg -i amarok*.deb libgpod3-nogtk*.deb libmtp*.deb libmysqlclient15off*.deb

Ed è fatta. Due accorgimenti:

1. il lanciatore nel menù è nascosto di default, quindi (in Gnome 2) click destro del mouse sul menù, “Modifica menù”, andate sotto “Audio e video” e mettete la spunta alla relativa opzione;
2. il nostro gestore dei pacchetti, rilevata una versione più recente di Amarok, insisterà nel farci aggiornare. Per risolvere è sufficiente bloccare i pacchetti amarok e amarok-common. In aptitude:

   aptitude hold amarok amarok-common

   In synaptic cercate (guardate sotto “Installato (aggiornabile)”) i due pacchetti, selezionatene uno alla volta, poi andate sul menù “Pacchetto” e mettete la spunta a “Blocca versione”.
   Notate che dovete seguire entrambe le procedure.

Et voilà:

After making a list of required dependencies, there are two ways to do this:

1. pass the entire list to the package manager. Then the package manager will check which packages are already installed and will proceed with the installation of those that are missing;
2. check what dependencies are already installed, make a list of dependencies that are missing, then pass to the package manager only missing dependencies list.

The second choice is the best choice, besides being more elegant. First, because it has a better chance of success (by hypothesis, some package managers may not work, if we ask it to install a package that’s already installed); second, ’cause if we were having some problems with the installation (for whatever reason), we can say exactly to the user what are the packages that he has to install manually.

Now let’s see what we have to do. As I have already said, we should:

1. make a list of required dependencies (it’ll be the DEPENDENCIES array);
2. check what dependencies are missing and save them in a new list (it’ll be the PKGSTOINSTALL string);
3. install missing dependencies (from the PKGSTOINSTALL string).

Well, let’s go to the code. We need to create a list of required dependencies, for example foo and bar packages:

DEPENDENCIES=(foo bar)

Now we need to check which of those packages are already installed. The missing packages will be added to the PKGSTOINSTALL string, separated by a space:

# What dependencies are missing?
PKGSTOINSTALL=""
for (( i=0; i /dev/null; then
		if [[ ! `dpkg -l | grep -w "ii  ${DEPENDENCIES[$i]} "` ]]; then
			PKGSTOINSTALL=$PKGSTOINSTALL" "${DEPENDENCIES[$i]}
		fi
	# OpenSuse, Mandriva, Fedora, CentOs, ecc. (with rpm)
	elif which rpm &> /dev/null; then
		if [[ ! `rpm -q ${DEPENDENCIES[$i]}` ]]; then
			PKGSTOINSTALL=$PKGSTOINSTALL" "${DEPENDENCIES[$i]}
		fi
	# ArchLinux (with pacman)
	elif which pacman &> /dev/null; then
		if [[ ! `pacman -Qqe | grep "${DEPENDENCIES[$i]}"` ]]; then
			PKGSTOINSTALL=$PKGSTOINSTALL" "${DEPENDENCIES[$i]}
		fi
	# If it's impossible to determine if there are missing dependencies, mark all as missing
	else
		PKGSTOINSTALL=$PKGSTOINSTALL" "${DEPENDENCIES[$i]}
	fi
done

With a loop we will be checked every necessary dependency. Dpkg will be used for the deb-based distros (Debian, Ubuntu and derivatives, as Mint), rpm for the rpm-based (OpenSuse, Mandriva, Fedora, CentOs, etc.) and pacman for ArchLinux. If none of these is available on the system (for whatever reason), all the required dependencies will be marked as missing.

At this point, as I said before, the PKGSTOINSTALL string contains the list of required dependencies that are missing. We can proceed to install them:

# If some dependencies are missing, asks if user wants to install
if [ "$PKGSTOINSTALL" != "" ]; then
	echo -n "Some dependencies are missing. Want to install them? (Y/n): "
	read SURE
	# If user want to install missing dependencies
	if [[ $SURE = "Y" || $SURE = "y" || $SURE = "" ]]; then
		# Debian, Ubuntu and derivatives (with apt-get)
		if which apt-get &> /dev/null; then
			apt-get install $PKGSTOINSTALL
		# OpenSuse (with zypper)
		elif which zypper &> /dev/null; then
			zypper in $PKGSTOINSTALL
		# Mandriva (with urpmi)
		elif which urpmi &> /dev/null; then
			urpmi $PKGSTOINSTALL
		# Fedora and CentOS (with yum)
		elif which yum &> /dev/null; then
			yum install $PKGSTOINSTALL
		# ArchLinux (with pacman)
		elif which pacman &> /dev/null; then
			pacman -Sy $PKGSTOINSTALL
		# Else, if no package manager has been founded
		else
			# Set $NOPKGMANAGER
			NOPKGMANAGER=TRUE
			echo "ERROR: impossible to found a package manager in your sistem. Please, install manually ${DEPENDENCIES[*]}."
		fi
		# Check if installation is successful
		if [[ $? -eq 0 && ! -z $NOPKGMANAGER ]] ; then
			echo "All dependencies are satisfied."
		# Else, if installation isn't successful
		else
			echo "ERROR: impossible to install some missing dependencies. Please, install manually ${DEPENDENCIES[*]}."
		fi
	# Else, if user don't want to install missing dependencies
	else
		echo "WARNING: Some dependencies may be missing. So, please, install manually ${DEPENDENCIES[*]}."
	fi
fi

Now I’ll explain this portion of code. First of all, the script asks the user if he wanna proceed with the installation (else, it will tell the user which packages have to install manually). Then it proceeds by using the package manager avaible on the system: apt-get for Debian, Ubuntu and derivateves, zypper for OpenSuse, urpmi for Mandriva, yum for Fedora and CentOS and pacman for Archlinux.

If none is available, the user indicates which packages have to install manually. Finally it verifies if the installation was successful and in case of problems, again, alerts the user.

Good luck.

(in italiano: Bash scripting: verificare e installare dipendenze mancanti)

Essentially, flash messages are used whenever you want to say to an user: “hey man, everything is fine, or something went wrong”.

As the CakePHP documentation explains:

Often in web applications, you will need to display a one-time notification message to the user after processing a form or acknowledging data. In CakePHP, these are referred to as “flash messages”. You can set flash messages with the SessionComponent and display them with the SessionHelper::flash(). To set a message, use setFlash.

To store a message inside a controller, you can use the setFlash() method (API) provided by SessionComponent; to show a message inside a view, you can instead use the flash() method (API) provided by SessionHelper.

For example, inside a controller like this:

public function myAction() {
   // do something...
   $this->Session->setFlash("it works!");
   // do something...
}

Inside a view:

Session->flash(); ?>

As my example says, this will work correctly and will produce this html:

<div id="flashMessage" class="message">it works!</div>

This is really nice, especially because flash messages are “one-time messages” and the developer doesn’t have to worry about manage directly the session (Cake’s core will take care of this, not you). But there are problems when you wanna store more messages in a single action of a controller. Indeed this one:

public function myAction() {
   // do something...
   $this->Session->setFlash("does it work?");
   $this->Session->setFlash("it works!");
   // do something...
}

will remember only the second flash message. And the first one? Another problem is: and if I wanted to differentiate between different types of messages (for example: warnings, errors, confirmations, etc..)?
As the documentation explains, “using the $key parameter you can store multiple messages, which can be output separately” (quoting the documentation example):

// set a bad message.
$this->Session->setFlash('Something bad.', 'default', array(), 'bad');
// set a good message.
$this->Session->setFlash('Something good.', 'default', array(), 'good');

These flash messages will be output as html and styled differently:

// in a view.
echo $this->Session->flash('good');
echo $this->Session->flash('bad');

You can also pass a class in $params array using again $this->Session->setFlash:

$this->Session->setFlash('Example message text', 'default', array('class' => 'example_class'));

Using $this->Session->flash(), the output will be:

<div id="flashMessage" class="example_class">Example message text</div>

But all this is very uncomfortable to use and is very difficult to develop using the proposal syntax.
So, how to solve? It’s simple: rewrite component and helper.
First, you need to copy

lib/Cake/Controller/Component/SessionComponent.php

in

app/Controller/Component/

and

lib/Cake/View/Helper/SessionHelper.php

in

app/View/Helper/

This allows you to override the classes of Cake’s core with yours, that will be used first (note: you must not edit directly Cake’s core, never! Just rewrite components, helpers, views, etc.).

Then, in app/Controller/Component/SessionComponent.php replace the setFlash() function with this one:

public function setFlash($message, $type="message") {
	//If flash messages are already stored in session, fetch array
	if(CakeSession::check('flashMessages'))
		$messages = CakeSession::read('flashMessages');
	//Else, create a new empty array
	else
		$messages = array();
	//If the flash message type is not supported (only "error", "notice", "success" and "warning"), set it to "notice"
	if(!in_array($type = strtolower($type), array("error", "notice", "success", "warning")))
		$type = "notice";
	//Add the passed flash message to the array
	$messages[$type][] = $message;
	//Store in sessione
	CakeSession::write('flashMessages', $messages);
}

With this, now you can store flash messages like this (it will store an error):

echo $this->Session->flash('something has gone wrong', 'error');

Again, in app/View/Helper/SessionHelper.php replace the flash() function with this one:

public function flash() {
	//Check if flash messages are stored in session
	if(CakeSession::check('flashMessages')) {
		//Retrieve saved flash messages and deletes them from the session
		$messages = CakeSession::read('flashMessages');
		CakeSession::delete('flashMessages');
		//Prepare the $out variable that will contain the final output
		$out = "";
		//Loop every flash message that is stored in session, appending to the variable $out
		foreach ($messages as $type => $message) {
			foreach ($message as $text)
				$out .= '<div class="'.$type.'">'.$text.'</div>';
		}
		//Return flash messages in html
		return $out;
	}
}

It will return flash messages as:

<div class="$type">$text</div>

Now a new example. Inside your controller:

$this->Session->setFlash("This is just a warning", "warning");
$this->Session->setFlash("It's ok!", "success");
$this->Session->setFlash("Something seems to have gone wrong", "error");
$this->Session->setFlash("A simple, innocent news.", "notice");

It will be displayed like this:

<div class="warning">This is just a warning</div>
<div class="success">It's ok!</div>
<div class="error">Something seems to have gone wrong</div>
<div class="notice">A simple, innocent news.</div>

Wonderful, is not it?

Since we are here, just add a little style for flash messages. In the view, you have to display messages like this:

<div id="flashMessages">
	<?php echo $this->Session->flash(); ?>
</div>

Download these files and move them to app/webroot/img/, then add to your style sheet:

#flashMessages div {
	background: no-repeat 5px 5px;
	border-radius: 5px;
	border-style: solid;
	border-width: 2px;
	box-shadow: 0 5px 5px -5px #555;
	margin-bottom: .5em;
	min-height: 24px;
	padding: 5px 10px 5px 35px;
}

#flashMessages .error {
	background-color: #FFCCCC;
    background-image: url("/img/error.png");
    border-color: #8F0000;
    color: #8F0000;
}

#flashMessages .notice {
	background-color: #e6ecf2;
	background-image: url("/img/notice.png");
	border-color: #314e6c;
	color: #314e6c;
}

#flashMessages .success {
    background-color: #DEFADE;
    background-image: url("/img/success.png");
    border-color: #267726;
    color: #267726;
}

#flashMessages .warning {
    background-color: #FFEEBF;
    background-image: url("/img/warning.png");
    border-color: #B87D00;
    color: #B87D00;
}

This is the result:

A great work guys! ;-)

1. la giornalista è venuta a sapere che la ragazza aveva fatto uso della pillola del giorno dopo e ha dedotto (erroneamente) che ha abortito e che quindi fosse rimasta incinta;
2. viceversa, che la ragazza era rimasta incinta e ha abortito e ha dedotto (sempre erroneamente) che l’abbia fatto tramite l’uso della pillola del giorno dopo.

In ogni caso – diciamo per sintesi – la giornalista ha lavorato di fantasia per arricchire l’articolo. E il risultato è quello che si vede.

Il problema è che la discussione su aborto da una parte e contraccettivi dall’altra, ad oggi, nel nostro Paese, è basata quasi esclusivamente sulla disinformazione, sia di chi è contrario ai due (soprattutto), sia (anche e non di meno) di chi è favore delle due o di una delle due.
In questo contesto, un giornalista può permettersi, senza troppe responsabilità, di alimentare la disinformazione? Non si sente la necessità di aderire a un codice deontologico oppure, quanto meno, di informarsi come requisito per informare (“informarsi per informare…”), assumendo che si sia in buona fede?

Due piccole premesse:

1. dovete conoscere bene html e css, in quanto qui ci limiteremo (per questi due) allo stretto indispensabile;
2. qui utilizzeremo un menù principale orizzontale (quindi le voci del menù affiancate) con sotto-menù in verticale (quindi voci elencate). Nulla toglie che poi, in base alle proprie esigenze e con le giuste modifiche, si possa operare diversamente (esempio: entrambi verticali).

Innanzitutto è necessario e doveroso scrivere del codice html pulito e conforme. Potete tenere a riferimento le considerazioni già espresse nel precedente articolo, e quindi scrivere un codice di questo genere:

<ul>
	<li><a href="pagina1.html">Pagina 1</a></li>
	<li>
            <a href="#">Pagina 2</a>
            <ul>
               <li><a href="paginaA.html">Pagina A</a></li>
               <li><a href="paginaB.html">Pagina B</a></li>
               <li><a href="paginaC.html">Pagina C</a></li>
            </ul>
        </li>
	<li><a href="pagina3.html">Pagina 3</a></li>
</ul>

È fondamentale notare come sia corretto organizzare il sotto-menù: il tag <ul> del sotto-menù (riga 5) è all’interno del tag <li> (riga 3) da cui si estende, che include anche il tag <a> (riga 4) che funge da finto-collegamento (in questo caso, perché deve essere funzionale solo all’estensione del sotto-menù) e da testo di riferimento per il sotto-menù. Potete vedere un primo esempio (solo html) qui.

Passiamo al foglio di stile. Innanzitutto aggiungiamo un id al menù principale (nell’esempio sarà navbar e quindi <ul id=”navbar”>), così da facilitarne la selezione (sia nel foglio di stile, sia con Jquery; e ricordo che in entrambi bisogna anteporre il cancelletto (#) davanti al nome), poi aggiungiamo delle proprietà css di base affinché il menù diventi così. Non le riporto per intero in questo articolo, potete trovare il foglio di stile qui.

Alcuni commenti:

1. si seleziona il menù principale con #navbar (avendo l’<ul> principale id navbar, come già detto), i sotto-menù con #navbar ul (non solo quelli di primo livello, semmai ce ne fossero di inferiori!), entrambi (menù principale e sotto-menù) unendo le due con una virgola (quindi: #navbar, #navbar ul su un’unica riga);
2. il menù principale si estende orizzontalmente, i sotto-menù (anche qui, non solo quelli di primo livello, ma tutti) verticalmente. Ciò significa che che una regola generale potrebbe (e spesso ha bisogno di) essere riscritta o perfezionata per essere applicata a uno stesso elemento contenuto in un sotto-menù di livello inferiore (il punto 4 di questo elenco ne è un esempio);
3. dare una posizione assoluta ai sotto-menù (riga 13) è utile affinché siano indipendenti per quanto riguarda le misure (che saranno automatiche e calcolate in base al contenuto). Per eventuali altri sotto-livelli, ho notato dei problemi (sempre con le misure) credo imputabili ai limiti di Css 2. In questi casi, è bene specificare delle larghezze minime assolute per i sotto-menù, che potrebbe comunque essere – a prescindere – una buona pratica, anche per motivi estetici;
4. i <li> del menù principale devono essere “flottanti” a sinistra per essere mostrati uno affianco all’altro (riga 23), visto che di default un elenco (<ul>) si estende in verticale. Questa regola viene annullata per i <li> dei sotto-menù (riga 30), visto che l’ordinamento di default va bene (anche i sotto-menù si estendono in verticale);
5. bisogna annullare lo stile dei menù (riga 24);
6. le <a> hanno bisogno della proprietà display impostata a block (riga 36), altrimenti non avranno le stesse dimensioni dei <li> che le contengono;
7. le modifiche di stile al passaggio del mouse (righe 45-47) vengono “attivate” al passaggio del mouse su un <li> (infatti troviamo li:hover), ma vengono applicate alla <a> contenuta in quel <li>, visto che è alla <a> che viene definito un stile (righe 34-40). Le modifiche vengono applicate solo alla <a> “primo figlio” (meglio in inglese: first child) tramite il > (riga 45), per evitare comportamenti non voluti (se togliete il > e passate sul <li> che contiene un sotto-menù, noterete che le modifiche vengono applicate anche a tutte le <a> del sotto-menù e non solo a quella che apre il sotto-menù – è normale, visto che anche quelle sono “figlie” del <li> principale, proprio per la struttura html che abbiamo (correttamente) definito).

In questo esempio – come sicuramente avrete già notato – il sotto-menù è mostrato sempre, diremmo “fisso”: ho scelto così per permettere di visualizzare nel complesso l’applicazione del foglio di stile. Normalmente, però, non dovrebbe essere così, quindi dobbiamo nasconderlo. Per farlo utilizzeremo la proprietà display settata su none, da applicare a tutti i sotto-menù. Quindi, a questo punto, dobbiamo aggiungere sotto la riga 12 quanto segue:

display: none;

Notare che si potrebbe usare anche la regola visibility (settata su hidden), che porta allo stesso risultato ed è anche migliore da un punto di vista strettamente semantico; ma dobbiamo necessariamente ricorrere a display, perché Jquery lavora su questa proprietà per modificare la visibilità di un elemento.
Fatto questo, l’esempio aggiornato è questo e il relativo foglio di stile questo qui.

Non resta che aggiungere Jquery. L’operazione da eseguire è: al passaggio del mouse su un <li>, mostra l’<ul> first child (anche qui, altrimenti se usiamo più livelli di sotto-menù, li estenderebbe subito tutti). Va da sé che se un <li> non ha nessun <ul> figlio, non accade nulla. Quindi innanzitutto includiamo Jquery (all’interno dei tag <head>):

<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.6.4/jquery.min.js"></script>
<script>
	$(document).ready(function(){
	 	//Il nostro codice andrà qui...
	});
</script>

Per attivare un effetto al passaggio del mouse su un <li>, possiamo usare l’evento hover() (documentazione). Il nostro codice diventa quindi (ometto l’inclusione del .js di Jquery e i vari tag <script>):

$(document).ready(function(){
	$("#navbar li").hover(function (){
		//L'effetto da applicare va qui...
	});
});

Che semplicemente corrisponde a: al passaggio del mouse (evento hover()) su un (qualsiasi) <li> contenuto nell’<ul> #navbar (quindi #navbar li), applica la funzione alla riga 3 (che qui dobbiamo implementare).

Di effetti disponibili ce ne sono parecchi (lista completa): noi utilizzeremo slideToggle() (documentazione), ma si valutino anche il classico toggle() (documentazione) e fadeToggle() (documentazione), che differiscono per lo più per il tipo di animazione (si fa prima a provare che a descrivere in questo articolo). Il codice diventa quindi:

$(document).ready(function(){
	$("#navbar li").hover(function (){
		$(this).children("ul").slideToggle();
	});
});

Che sta a significare: applica l’effetto slideToggle() al figlio <ul> (grazie a children() (documentazione)) dell’attuale <li> (this) su cui si è passato il mouse. Ecco quindi il nuovo esempio (il foglio di stile è sempre lo stesso, non lo abbiamo toccato), che soddisfa le necessità iniziali.

Manca giusto una (ultima) cosa, per lo più un “orpello”: come fare a capire (ad occhio, per il visitatore) quali menù contengono un sotto-menù. È diffusa l’abitudine di aggiungere il carattere “»” (ascii &#187;) ai menù che contengono un sotto-menù, pratica chiara e immediata. Potremmo occuparci di questa “aggiunta” manualmente, ma perché farlo (e faticare e rischiare di commettere errori o di non aggiornare in là col tempo), quando Jquery può occuparsi anche di questo e al posto nostro?
D’altronde la cosa è semplice: ciclare tutti i <li> del menù (<li> a qualsiasi profondità, ovviamente), verificare se hanno un <ul> figlio (con un costrutto if) e in caso positivo aggiungere il carattere (preceduto da uno spazio!) alla fine del link.

Bene, passiamo al codice. Per ciclare possiamo utilizzare each() (documentazione):

$("#navbar li").each(function() {
	//Fa qualcosa ad ogni <li> all'interno di #navbar...
});

che, in questo caso, eseguire la funzione qui dichiarata su ogni elemento <li> all’interno di #navbar. Quindi la verifica, per la quale possiamo affidarci a length (documentazione):

$("#navbar li").each(function() {
	if ($(this).children("ul").length) //Fa qualcosa ad ogni <li> all'interno di #navbar che contiene un <ul>...
});

In sostanza, in questo esempio lenght è pari al numero degli <ul> figli del <li> per il quale stiamo eseguendo il ciclo (sempre il famoso selettore this), e quindi l’if avrà esito negativo se non ci sono <ul> figli, viceversa positivi se c’è almeno un <ul> figlio – nota: questo if può essere generalmente utilizzato per verificare se un tag ne contiene un altro ed eventualmente in quale quantità.
Quindi l’aggiunta:

$("#navbar li").each(function() {
	//Se un <li> contiene un sotto-menù, aggiunge al collegamento " »"
	if ($(this).children("ul").length) $(this).children("a").append(" &#187;");
});

Utilizziamo il manipolatore append() (documentazione) per aggiungere uno spazio e un carattere alla <a> figlia di ogni <li> che ha come figlio un <ul> – sembra un ragionamento contorto, sì, lo so; ma riflettete un po’ sul codice e ci arriverete: l’aggiunta va fatta alla <a> contenuta nel <li> e non al <li> sul quale abbiamo eseguito il controllo.

Ecco quindi il codice Jquery finale e completo:

$(document).ready(function(){
	$("#navbar li").hover(function (){
		$(this).children("ul").slideToggle();
	});
	$("#navbar li").each(function() {
		//Se un <li> contiene un sotto-menù, aggiunge al collegamento " »"
		if ($(this).children("ul").length) $(this).children("a").append(" &#187;");
	});
});

Nonché, l’ultimo esempio.

Si può fare? Sì, si può fare. Vi spiego come.
Analizziamo innanzitutto i passaggi che si dovrebbero svolgere, ordinandoli:

1. vengono elencate (ad esempio, tramite un array) le dipendenze necessarie;
2. ricerca di un gestore di pacchetti valido;
3. verifica delle dipendenze mancanti nel sistema in uso, elencando anche queste (un nuovo array);
4. ricerca di un gestore di pacchetti valido;
5. installazione delle dipendenze segnate come mancanti.

Prima osservazione, più che lecita: i punti 2) e 4) non fanno la stessa cosa? A che serve ripetere due volte la stessa operazione?
Risposta: serve ripetere la stessa operazione perché sì, nonostante facciano la stessa cosa (ricerca un gestore di pacchetti valido), la ricerca, nei due casi, può e anzi dovrebbe portare a risultati diversi; questo perché bisogna tenere in conto che il gestore selezionato al punto 2) deve svolgere l’operazione indicata come 3), mentre il gestore selezionato al punto 4) svolgerà il compito 5).
E non è detto che per entrambe le operazioni sia opportuno utilizzare lo stesso gestore (anche se è cosa possibile), anzi…

Un esempio concreto chiarificherà questa spiegazione: visto che il gestore selezionato al punto 4) dovrà procedere all’installazione di alcuni pacchetti – come indicato al punto 5) – se la distribuzione è openSuse si utilizzerà zypper, se è Mandriva si utilizzerà urpmi, se è Fedora si utilizzerà yum. Mentre invece il punto 3), in tutti questi tre casi (openSuse, Mandriva e Fedora) può essere sempre svolto da rpm. Che per giunta svolge il compito 3) meglio degli altri già elencati; al contrario, non sarebbe invece molto indicato per svolgere il punto 5), per motivi che tutti conosciamo.
Lo stesso dicasi per altre distribuzioni. Ad esempio, per Debian, Ubuntu e derivate varie, il punto 3) verrà svolto da dpkg, il punto 5) da apt-get.

Seconda osservazione: è proprio necessario verificare quali dipendenze sono mancanti? Non si fa prima a proporre l’installazione di tutte le dipendenze, così che sia poi il gestore a occuparsi di installare solo quelle mancanti e eventualmente a segnalare quelle già presenti? Sì, certo, si può fare e sicuramente è più comodo e veloce. Ma qui si valuterà il processo “più complesso”, negli altri casi non dovrebbe essere difficile (per voi, per chi legge, per chi è interessato) snellire la procedura, a seconda delle proprie esigenze.
Si tenga anche in conto che lo script potrebbe fallire, per tanti motivi (perché non è stato trovato un gestore di pacchetti adatto, cosa possibile perché non si possono considerare tutte le distribuzioni Linux esistenti, con i loro relativi gestori): in questo caso, potremo indicare all’utente quali dipendenze sono appunto mancanti, e invitarlo a installarle manualmente. Cosa che è molto più elegante, in questo caso, dell’indicare tutte le dipendenze necessarie, installate o meno, mettendo così l’utente nella condizione di dover controllare quali deve provvedere a installare manualmente.

Terza osservazione: l’installazione, ovvero il passaggio 5), avviene del tutto automaticamente, cioè senza nessun interazione con l’utente? No, volutamente no. Lo script che propongo lancia il gestore con il corretto comando d’installazione: è facile e molto probabile che poi – qualsiasi sia la distribuzione, qualsiasi sia il gestore selezionato – verrà chiesto all’utente di confermare.
È una scelta voluta, perché esperienza mi ha insegnato che non è corretto installare software senza renderne consapevole e partecipe l’utente e che non è corretto installare senza aver prima visionato quali cambiamenti verranno apportati al sistema (in alcuni casi, l’installazione di alcuni pacchetti, per via di errati calcoli o problemi con le dipendenze che si portano dietro, possono rendere un sistema instabile…).

Finite le osservazioni, passiamo al codice. È innanzitutto necessario stabilire quali sono le dipendenze necessarie. Vorrei subito chiarire, a scanso di equivoci, che:

1. quando parlo di “dipendenze” o di “dipendenze necessarie” mi riferisco alle dipendenze richieste dal nostro script (affinché funzioni correttamente);
2. quando parlo di “dipendenze mancanti” mi riferisco alle dipendenze del nostro script e che mancano sul sistema in uso (è quindi questo un sotto-insieme o una selezione del precedente).

Avevamo previsto un array, che mi sembra la scelta più opportuna:

DEPENDENCIES=(adduser curlftpfs dialog inotify-tools libnotify-bin nfs-common)

Questo soddisfa il punto 1) nella lista dei passaggi da compiere. Passiamo ai punti 2) e 3), ovvero alla selezione di un opportuno gestore di pacchetti e alla verifica di quali dipendenze sono mancanti:

# What dependencies are missing?
PKGSTOINSTALL=""
for (( i=0; i<${tLen=${#DEPENDENCIES[@]}}; i++ )); do
	# Debian, Ubuntu and derivatives (with dpkg)
	if which dpkg &> /dev/null; then
		if [[ ! `dpkg -l | grep -w "ii  ${DEPENDENCIES[$i]} "` ]]; then
			PKGSTOINSTALL=$PKGSTOINSTALL" "${DEPENDENCIES[$i]}
		fi
	# OpenSuse, Mandriva, Fedora, CentOs, ecc. (with rpm)
	elif which rpm &> /dev/null; then
		if [[ ! `rpm -q ${DEPENDENCIES[$i]}` ]]; then
			PKGSTOINSTALL=$PKGSTOINSTALL" "${DEPENDENCIES[$i]}
		fi
	# ArchLinux (with pacman)
	elif which pacman &> /dev/null; then
		if [[ ! `pacman -Qqe | grep "${DEPENDENCIES[$i]}"` ]]; then
			PKGSTOINSTALL=$PKGSTOINSTALL" "${DEPENDENCIES[$i]}
		fi
	# If it's impossible to determine if there are missing dependencies, mark all as missing
	else
		PKGSTOINSTALL=$PKGSTOINSTALL" "${DEPENDENCIES[$i]}
	fi
done

Nonostante reputi questo codice abbastanza comprensibile, vado a commentare:

1. innanzitutto vado a creare la variabile (vuota) PKGSTOINSTALL, che conterrà l’elenco (non è un array, ma una stringa, con gli spazi a mò di divisore) delle dipendenze mancanti;
2. viene quindi eseguito un ciclo (riga 3) per ognuna delle dipendenze da verificare;
3. all’interno del ciclo, tramite un (complesso) costrutto if-elif-else, vado a verificare se è disponibile un gestore di pacchetti, avvalendomi di which (che stampa la localizzazione di un eseguibile, quando è presente, altrimenti nulla) e, se disponibile, quale (righe 5, 10 e 15).
   Qui, in particolare, ricerchiamo tra dpkg (per Debian, Ubuntu e derivate, come Mint), rpm (per OpenSuse, Mandriva, Fedora, CentOs e altre) e pacman (per ArchLinux), che dovrebbero coprire la stragrande maggioranza delle distribuzioni, sicuramente tutte quelle più diffuse;
4. viene quindi verificata se la singola dipendenza (che stiamo ciclando) è già installata o meno, eseguendo un comando specifico per il gestore che abbiamo selezionato (righe 6, 11 e 16);
5. se la dipendenza non risulta installata, viene accodata alla stringa PKGSTOINSTALL (righe 7, 12 e 17), preceduta da uno spazio. Se invece è già installata, passa alla successiva dipendenza da controllare;
6. se non viene trovato un gestore utile (alternativo quindi a quanto descritto al punto 3) di questo elenco), allora segna automaticamente la dipendenza come mancante (riga 21), segnando di fatto tutte le dipendenze come mancanti (perché, ovviamente, anche la successiva iterazione del ciclo porterà allo stesso risultato…).

Alla fine di questo blocco di codice – come per altro già accennato – la variabile PKGSTOINSTALL conterrà quindi l’elenco delle dipendenze mancanti (e quindi da installare!), separate l’un l’altra da uno spazio (come tutti i gestori si aspettano siano passato l’elenco).

Si noti che questo codice non è “perfetto”: ad ogni ciclo, di fatti, si va a rieseguire il controllo del gestore. Non dovrebbe portare a chissà quali performance negative e/o penalizzanti, ma non escludo assolutamente che si possano scrivere numerosi varianti migliori di questa e che portino allo stesso risultato. Anzi, se ne avete voglia, prendetelo come un esercizio, visto che sicuramente si può fare (e si dovrebbe fare…) di meglio.

Passiamo al codice che si occupa dell’installazione effettiva:

# If some dependencies are missing, asks if user wants to install
if [ "$PKGSTOINSTALL" != "" ]; then
	echo -n "Some dependencies are missing. Want to install them? (Y/n): "
	read SURE
	# If user want to install missing dependencies
	if [[ $SURE = "Y" || $SURE = "y" || $SURE = "" ]]; then
		# Debian, Ubuntu and derivatives (with apt-get)
		if which apt-get &> /dev/null; then
			apt-get install $PKGSTOINSTALL
		# OpenSuse (with zypper)
		elif which zypper &> /dev/null; then
			zypper in $PKGSTOINSTALL
		# Mandriva (with urpmi)
		elif which urpmi &> /dev/null; then
			urpmi $PKGSTOINSTALL
		# Fedora and CentOS (with yum)
		elif which yum &> /dev/null; then
			yum install $PKGSTOINSTALL
		# ArchLinux (with pacman)
		elif which pacman &> /dev/null; then
			pacman -Sy $PKGSTOINSTALL
		# Else, if no package manager has been founded
		else
			# Set $NOPKGMANAGER
			NOPKGMANAGER=TRUE
			echo "ERROR: impossible to found a package manager in your sistem. Please, install manually ${DEPENDENCIES[*]}."
		fi
		# Check if installation is successful
		if [[ $? -eq 0 && ! -z $NOPKGMANAGER ]] ; then
			echo "All dependencies are satisfied."
		# Else, if installation isn't successful
		else
			echo "ERROR: impossible to install some missing dependencies. Please, install manually ${DEPENDENCIES[*]}."
		fi
	# Else, if user don't want to install missing dependencies
	else
		echo "WARNING: Some dependencies may be missing. So, please, install manually ${DEPENDENCIES[*]}."
	fi
fi

Vado anche qui a commentare:

1. innanzitutto, un semplice costrutto if verifica che la variabile PKGSTOINSTALL non sia vuota (riga 2) e quindi – in altri termini – verifica che ci sia qualcosa da installare. Ricordo – visto che l’avevo già precisato – che se precedentemente non è stato possibile determinare quali dipendenze siano mancanti e quali presenti, qui risulteranno tutte come mancanti;
2. a questo punto, viene chiesto all’utente se vuole procedere con l’installazione (la riga 3 stampa la richiesta, la riga 4 salva l’input in READ);
3. se la risposta è affermativa (riga 6), allora viene ricercato un gestore di pacchetti (righe 8, 11, 14, 17, 20) tra apt-get, zypper, urpmi, yum e pacman, sempre tramite un costrutto if-elif-else;
4. se è stato trovato un gestore dei pacchetti, allora procede con l’installazione, avvalendosi dell’opportuna istruzione (righe 9, 12, 15, 18, 21). Altrimenti (riga 23), imposta la variabile NOPKGMANAGER a TRUE (riga 25, ci servirà successivamente per controllo) e stampa a schermo un errore (riga 26);
5. quindi viene verificato l’esito dell’installazione (riga 29). Se l’istruzione di installazione non ha restituito nessun errore (per qualsiasi motivo che abbia portato il gestore di turno ad un fallimento) e se non è presente la variabile NOPKGMANAGER (impostata quando non viene correttamente rilevato un gestore di pacchetti), allora l’installazione ha avuto successo e quindi stampa un messaggio di conferma (riga 30). Se invece le due ipotesi non sono entrambe e contemporaneamente vere (riga 32), allora l’installazione non è andata a buon fine e quindi stampa un messaggio di errore e la lista delle dipendenze segnate come mancanti, che l’utente dovrà (a questo punto) provvedere a installare manualmente (riga  33);
6. se invece l’utente ha inizialmente risposto negativamente alla richiesta di procedere con l’installazione (riga 36), allora stampa un messaggio di avviso e – anche qui – la lista delle dipendenze da installare manualmente.

Il 22 ottobre in tutta Italia è il Linux day.

Il Linux Day è una manifestazione nazionale articolata in eventi locali che ha lo scopo di promuovere GNU/Linux e il software libero. Il Linux Day è promosso da ILS (Italian Linux Society) e organizzato localmente dai LUG italiani e dagli altri gruppi che condividono le finalità della manifestazione.
La responsabilità dei singoli eventi locali è lasciata ai rispettivi gruppi organizzatori, che hanno libertà di scelta per quanto riguarda i dettagli delle iniziative locali, nel rispetto delle linee guida generali della manifestazione. La prima edizione del Linux Day si è tenuta il 1 dicembre 2001 in circa quaranta città sparse su tutto il territorio nazionale. Il numero è notevolmente cresciuto negli anni divenendo ormai un appuntamento immancabile nel panorama del software libero italiano.

Date un’occhiata al sito ufficiale, dove trovate la mappa delle 109 città italiane, dell’utile materiale informativo e le ultime news sull’iniziativa.

Se tutto andrà bene, io sarò presente a quello di Pescara, organizzato dal Pescara Lug. Il programma (se ci fossero altri della zona interessati):

Mattina Inizio ore 9.30
Ore 10.00 Introduzione e saluti
Ore 10.15 Panoramica del mondo Linux
Ore 10.45 Utilizzo di Linux tutti i giorni
Ore 12.30 Pausa Pranzo

Pomeriggio Inizio ore 15.30
Ore 15.30 Impaginazione e Scribus
Ore 16.00 Crittografia dei dati e Tomb
Ore 17.00 Sicurezza reti Wifi
Ore 17.30 Android

p.s. non ne sono stati organizzati in provincia di Chieti. Ce ne sono invece due a L’Aquila (quello dell’hAQ-lab e quello Linux Crew CaseMatte), uno ad Avezzano e uno a Teramo.

Conseguenza diretta è che, imperterrito, checkgmail chiede continuamente le credenziali di accesso alla casella di posta:

Lanciando l’update da terminale (`checkmail -update`), qualcosa viene aggiornato, ma la situazione non cambia, tant’è che lo stesso terminale dà in output un tristissimo:

Unable to find gmail_ik ... full message text won't work :(

Per nostra fortuna, qualche buon samaritano si è preso la briga di realizzare una piccola patch per checkgmail che potete scaricare da qui. Terminato il download, la potete applicare come segue (sono necessari i privilegi di root):

# patch /usr/bin/checkgmail checkgmail.patch

Ovviamente dovete indicare la path corretta di checkgmail.path. A questo punto sarà sufficiente riavviare checkgmail (click destro sull’icona, quindi “Restart…”) e tutto dovrebbe tornare alla normalità.

“Pop” da popolare, come la cultura viva che crea la nostra identità di individui e di collettività. “Stars” da stelle, non quelle del divismo spettacolare ma quelle naturali che ci portano indietro ad un tempo dove gli uomini erano in equilibrio con la natura, e questo dava loro un benessere individuale e collettivo.

Il Comune di Palombaro in qualità di comune capofila e la provincia di Chieti, annunciano l’avvio di “Popstars”, unico progetto abruzzese, selezionato nel bando “Piccoli Comuni per il Coinvolgimento dei giovani nella valorizzazione delle specificità territoriali – Giovani Energie in comune” promosso dall’Anci e dal Dipartimento della Gioventù della Presidenza del Consiglio dei Ministri.

Il progetto abruzzese coinvolge una rete di comuni dislocati in diverse zone dell’entroterra della Provincia di Chieti: Altino, Carunchio, Castelfrentano, Fraine, Miglianico, Pennapiedimonte, Pretoro, Rapino, Roccamontepiano, Roccaspinalveti, Sant’Eusanio del Sangro. I partners istituzionali oltre la Provincia di Chieti sono: CUSPD Centro Universitario di Sociologia della Prevenzione Disagio – Facoltà di Scienze Sociali Università G. D’Annunzio, Comunità Montana Alto Vastese, Comunità Montana della Maielletta, C.M.A – Centro Montano di Assistenza, Pro loco Carunchio, Pro loco Roccaspinalveti, Pro loco Fraine. Il consorzio Civica è responsabile del project Management.

La finalità principale di Pop Stars è quella di guidare i giovani in un percorso di recupero della memoria e dell’identità culturale del territorio attingendo al bagaglio di conoscenze e saperi di cui sono custodi gli anziani. Gli elementi della tradizione popolare saranno ri-letti e ri-utilizzati dai giovani attraverso i linguaggi della comunicazione e dell’arte contemporanea. Il progetto prevede per i mesi estivi lo svolgimento di un’attività di ricerca nei territori che coinvolge gli anziani. A partire da settembre e per tutto l’autunno, si svolgeranno i percorsi formativi in ambito socio – culturale rivolti ai giovani: laboratori di teatro, musica e canto, performance, video, fotografia e gestione siti web.

Le attività formative ideate e coordinate dalla regista Annamaria Talone dell’Associazione Maglab saranno realizzate da artisti ed operatori culturali esperti appartenenti alle associazioni abruzzesi Euritmi e Rogoteatro, e da una formatrice d’eccellenza Helen Chadwick  – musicista inglese, vocal trainer della Royal Shakespeare Company e del National Theatre. Le attività di ricerca e monitoraggio saranno guidate dal CUSPD diretto dal prof. Benvenuti – Facoltà di Scienze Sociali Università G. D’Annunzio.

Per poter partecipare i giovani devono avere un’età compresa tra i 18 e i 30 anni e la residenza in uno dei comuni coinvolti. Nel caso in cui non si raggiunge il numero minimo di adesioni per singolo laboratorio, sarà data la possibilità di fare domanda di partecipazione anche ai giovani residenti in tutti i comuni della Provincia di Chieti. Per informazioni sulle modalità di partecipazione ci si può rivolgere al proprio comune di residenza oppure visitare il sito www.giovanipopstars.it. La domanda va presentata entro il 30.07.2011

Il progetto si conclude con delle feste finali promosse dai giovani insieme agli anziani e a tutta la popolazione dei paesi. Il valore sociale del progetto non tocca solo le giovani generazioni ma ha una ricaduta positiva sulle comunità dei paesi coinvolti, rafforzando il senso di appartenenza, l’identità territoriale e la comunicazione tra diverse generazioni.

Apache in ascolto solo in locale

Questo impedisce che il nostro server Apache sia raggiungibile dall’esterno, lan inclusa. In altri termini, sarà raggiungibile solo dall’host locale, ovvero dalla stessa macchina su cui è in funzione il web server.
Modificare il file /etc/apache2/ports.conf da:

Listen 80

a:

Listen 127.0.0.1:80

È possibile indicare un indirizzo per riga. Quindi, volendo abilitare anche la lan (e supponendo che l’ip della macchina, al suo interno, sia 192.168.0.100), modificare in:

Listen 127.0.0.1:80
Listen 192.168.0.100:80

E quindi riavviare il servizio:

# /etc/init.d/apache2 restart

PhpMyAdmin senza password

Questo ci permette di loggarci automaticamente all’interno di PhpMyAdmin senza doverci autenticare ogni volta. Di default, è richiesta l’autenticazione, che viene mantenuta tramite l’utilizzo di cookie.
Modificare il file /etc/phpmyadmin/config.inc.php da:

/* Authentication type */
$cfg['Servers'][$i]['auth_type'] = 'cookie';

a:

/* Authentication type */
$cfg['Servers'][$i]['auth_type'] = 'config';
$cfg['Servers'][$i]['user'] = 'root';
$cfg['Servers'][$i]['password'] = 'mypwd';

(dove mypwd è la password dell’utente root)

Assicurarsi, in questo caso, che PhpMyAdmin non sia accessibile dall’esterno (modificando come prima illustrato), onde evitare di esporsi a gravi pericoli (ovvero avere i propri database mysql accessibili a tutti).

Anzitutto, la descrizione degli fglrx, reperita direttamente dal Wiki di Debian:

fglrx sta per FireGL and Radeon for X, ed è il driver proprietario (non libero) per display reso disponibile da ATI Technologies (ora AMD). Questo driver fornisce accelerazione 2D e 3D per chipset di schede grafiche AMD/ATI.

Veniamo velocemente al dunque:
1) aggiungere la componente “non-free” al proprio repository principale indicato nel file sources.list (/etc/apt/sources.list). Ad esempio, modificando così (per Debian testing, nel mio caso):

deb http://ftp.it.debian.org/debian/ testing main contrib non-free

2) aggiornare l’elenco dei pacchetti e installare i pacchetti necessari tramite:

# aptitude update
# aptitude install linux-headers-2.6-$(uname -r|sed 's,[^-]*-[^-]*-,,') fglrx-driver fglrx-modules-dkms fglrx-glx fglrx-atieventsd

Il comando installare tutte le dipendenze necessarie. L’output dovrebbe essere questo:

# aptitude install linux-headers-2.6-$(uname -r|sed 's,[^-]*-[^-]*-,,') fglrx-driver fglrx-modules-dkms fglrx-glx fglrx-atieventsd
I seguenti pacchetti NUOVI (NEW) saranno installati:
fglrx-atieventsd fglrx-driver fglrx-glx fglrx-modules-dkms
glx-alternative-fglrx{a} glx-alternative-mesa{a} glx-diversions{a}
linux-headers-2.6-amd64 linux-headers-amd64{a}
nvidia-installer-cleanup{a}
I seguenti pacchetti sono RACCOMANDATI ma NON verranno installati:
fglrx-glx-ia32
0 pacchetti aggiornati, 10 installati, 0 da rimuovere e 2 non aggiornati.
È necessario prelevare 22,7 MB di archivi. Dopo l'estrazione, verranno occupati 74,0 MB.

Il pacchetto fglrx-control è (diversamente da come indicato altrove) assolutamente facoltativo ed offre un pannello di controllo utile all’impostazione di alcune opzioni per il video. Come riporta la stessa descrizione:

The control panel shows detailed information on your display adapter and allows you to set dual screen options, adjust gamma correction and set TV out options.

3) fermare il sistema X Window. È possibile passando a una console virtuale, ovvero premendo contemporaneamente CTRL+ALT+F1. Alternativamente, si può riavviare il sistema in modalità ripristino (ma non è necessario). Fermare quindi il display manager in uso dopo essersi autenticati come root. Nel caso di gdm3 (per ambiente Gnome):

# /etc/init.d/gdm3 stop

Nel caso di kdm (per  ambiente Kde):

# /etc/init.d/kdm stop

4) generare un file xorg.conf (/etc/X11/xorg.conf) ad hoc per la propria scheda Ati:

# aticonfig --initial

Verificare che nel file in questione, sotto la sezione “Device”, alla voce “Driver” sia correttamente indicato “fglrx”.

5) Riavviare X Window o meglio riavviare il display manager. Nel caso di gdm3 (per ambiente Gnome):

# /etc/init.d/gdm3 start

Nel caso di kdm (per  ambiente Kde):

# /etc/init.d/kdm start

6) Verificare il corretto funzionamento dei driver e dell’accelerazione 3D con:

$ fglrxinfo

e (è necessaria l’installazione del pacchetto mesa-utils):

$ glxinfo | grep rendering

L’output dovrebbe essere:

$ fglrxinfo
display: :0.0  screen: 0
OpenGL vendor string: ATI Technologies Inc.
OpenGL renderer string: ATI Mobility Radeon HD 4650
OpenGL version string: 3.3.11005 Compatibility Profile Context

$ glxinfo | grep rendering
direct rendering: Yes

Fonti:
http://wiki.debian.org/ATIProprietary
http://guide.debianizzati.org/index.php/Installazione_driver_proprietari_Ati

Per gli interessati ai driver open per Ati, fare riferimento a questa guida.

Sudo

I vantaggi di sudo sono indiscutibili. Tra i più importanti: non è necessario condividere la password di root con chi necessiti dei privilegi di root; l’utente deve porre maggiore attenzione per ogni singolo comando che lancia con sudo e (quindi) una maggiore attenzione porta a una sensibile diminuzione di errori dovuti alla disattenzione; l’utilizzo di sudo può essere limitato e limitato sotto molti aspetti, mentre invece l’account di root non ha nessun limite – ne consegue che se la necessità è quella di utilizzare i privilegi di root in alcuni contesti ben definiti, sudo è conveniente rispetto a un accesso totale come root.

Può succedere che qualcuno abbia la necessità di utilizzare sudo senza password, soprattutto scrivendo script bash che per svolgere determinati passaggi necessitano appunto dei privilegi di root. Cercando su Google “sudo senza password” (senza virgolette) vengono fuori numerosi articoli che consigliano sistematicamente di aggirare il problema così:

echo password | sudo -S comando

(dove password è la password dell’utente e comando è il comando da eseguire. La password, scritta in chiaro, viene stampata e semplicemente passata a sudo)

Questa è la conseguenza di un fenomeno ormai pericolosamente diffuso e imperante sul web: ridistribuire notizie, informazioni, istruzioni senza sapere esattamente cosa si stia facendo e di cosa si stia parlando. Qualcuno scrive una cazzata (cosa comprensibile) e altri diecimila copia-incollano alla “zozza maniera” senza porsi il minimo dubbio su quello che stanno facendo.

Faccio subito due puntualizzazioni fondamentali:

1. aggirare il controllo della password di sudo può essere solo una pessima idea. Ognuno di noi è libero di farlo (d’altronde io stesso lo faccio, la comodità della cosa è innegabile), ma bisognerebbe avere consapevolezza di quello che si sta facendo, delle conseguenze che può portare e soprattutto essere nella situazione di assumersi poi le responsabilità di quella che – lo ripeto – può essere solo una pessima idea;
2. generalmente e in qualsiasi contesto, non bisogna mai salvare la propria password in chiaro, per nessun motivo, nemmeno per questioni di comodità come questa. Si mette in grave rischio la sicurezza informatica del sistema dove si esegue questa scelta scellerata (il vostro sistema GNU/Linux, in questo caso specifico). Se non esistono alternative a questa scelta, allora è meglio lasciar perdere e rassegnarsi al dover inserire (manualmente) la password ogni volta che ci viene richiesta.

Si può aggirare il controllo della password di sudo semplicemente modificando il file di configurazione di sudo con il comando (come root):

visudo

In fondo alla configurazione è sufficiente aggiungere qualcosa come:

utente   ALL=NOPASSWD: ALL

(dove utente è il nome dell’utente)

In questo modo l’utente specificato è autorizzato a utilizzare sudo senza che gli venga richiesta la password. Nell’esempio specifico, inoltre, questa autorizzazione è valida per qualsivoglia comando voglia eseguire l’utente. Sarebbe quindi meglio limitare questa possibilità.

A questo scopo (ma anche per approfondire sufficiente l’argomento) vi rimando alle pagine del manuale:

man sudo

E ad un’ottima guida per Ubuntu (comunque valida per qualsiasi distribuzione GNU/Linux, tanto il file di configurazione è sempre quello) che potete trovare qui.

Con l’ultima versione disponibile (in questo momento la 2.2.0.35) non è più necessario seguire la complessa procedura che avevo illustrato lo scorso ottobre. In particolare, adesso:

• non è più necessario forzare l’architettura, essendo disponibile appunto un pacchetto a 64bit;
• non è più necessario installare manualmente le dipendenze mancante, in quanto ora sono vengono tutte installate correttamente;
• non è più presente il bug legato alle Qt che impediva la corretta visualizzazione degli avatar dei contatti.

La versione a 64bit è scaricabile da qui. È sufficiente aprire il .deb con Gdebi e avviare l’installazione: tutto andrà a buon fine. Non è quindi più necessario – ripeto – installare dipendenze mancanti e poi procedere con l’installazione di Skype tramite dpkg per forzare l’architettura.

Persiste tuttavia un piccolo problema. Lanciando Skype dal terminale, possiamo verificare l’esistenza di due warning (tutto comunque funzionerà normalmente). Ovvero questo:

Gtk-Message: Failed to load module "canberra-gtk-module": /usr/lib/gtk-2.0/modules/libcanberra-gtk-module.so: classe ELF errata: ELFCLASS64

E questo:

(<unknown>:3043): Gtk-WARNING **: /usr/lib/gtk-2.0/2.10.0/engines/libclearlooks.so: classe ELF errata: ELFCLASS64

Possono essere entrambi risolti con un workaround già descritto. Create, con i privilegi di root, il file /usr/bin/skype64:

touch /usr/bin/skype64

Quindi copia-incollate al suo interno quanto segue:

#!/bin/bash
export GTK_PATH=/usr/lib32/gtk-2.0
skype

E infine assegnategli i permessi di esecuzione:

chmod +x /usr/bin/skype64

A questo punto sarà sufficiente lanciare Skype con il nuovo comando skype64, affinché tutto funzioni correttamente.

Mi raccomando a modificare opportunamente i vari lanciatori, primo fra tutti quello del menù:

E quello delle “Applicazioni d’avvio”, se ne avete impostato l’avvio automatico:
Buone videochiamate a tutti :-)

L’iniziativa è organizzata da Die Brücke (www.diebrucke.it) in collaborazione con la Cooperativa sociale onlus Futura (www.futurasociale.it) e il patrocinio del comune di Lanciano.

Interverranno Pino Masciari (www.pinomasciari.it), Antonio Mazzeo (www.antoniomazzeoblog.blogspot.com), Marcello D’Ovidio, Giovanni Legnini, Michael Lusi, Mirko Pagliai, Stefano Di Bucchianico e Rosalba Di Giuseppe. I lavori saranno coordinati da Maria Rosaria La Morgia.
A margine del convegno, esposizione artistica di Salvatore La Battaglia (www.salvatorelabattaglia.com) e intervento artistico con Riccardo Salvatore (attore), Stefano Barbati (chitarrista, www.stefanobarbati.com) e Monica Micolucci (cantante) che interpreteranno tra musica e parole alcuni passi del film I 100 passi, dedicato alla figura di Peppino Impastato ucciso dalla mafia il 9 maggio 1978.

C’è anche – voglio ricordarlo – la 54° esposizione internazionale d’arte della biennale di Venezia (informazioni).

Il convegno su Facebook: http://www.facebook.com/event.php?eid=214453148606417
Lo spettacolo su Facebook: http://www.facebook.com/event.php?eid=262791873733542

Nell’intenzione di proporre un argomento forse già da molti conosciuto (ma mai affrontato a sufficienza) sotto un nuovo punto di vista, che permettesse così di offrire maggiore risalto all’iniziativa nonché di stimolare maggiormente l’attenzione del pubblico, abbiamo pensato di invitare a presenziare non solo esperti e studiosi del fenomeno (criminalità organizzata e – più precisamente – mafia), ma anche e soprattutto personalità appartenenti alla società civile che vi sono state direttamente coinvolte e che quindi possano relazionare il pubblico sulle proprie esperienze personali.

A questo scopo, l’intera conferenza si articolerà principalmente e a partire dal racconto autobiografico di Pino Masciari (sito personale e voce su Wikipedia), imprenditore edile calabrese. Più volte ricattato, vittima di violenze ed estorsioni nonché ostacolato nella sua attività imprenditoriale dalla ‘ndrangheta, a partire dagli anni ’90 il sig. Masciari ha svolto un’intensa attività di denuncia, per la quale attualmente è impegnato in qualità di testimone di giustizia e costretto a vivere sotto scorta (è stato inserito nel Programma di protezione promosso dallo Stato). Insieme alla moglie Marisa, ha recentemente pubblicato il libro autobiografico Organizzare il coraggio – La nostra vita contro la ’ndrangheta (scheda del libro), a testimonianza proprio della sua storia.
L’intervento del sig. Masciari in seno alla conferenza calcherà presumibilmente gli argomenti e la struttura presenti nel suo stesso libro.
Insomma, mi sento di poter dire con estrema sicurezza che Pino Masciari ha “una bella storia da raccontare”.

Al racconto del sig. Masciari si affiancherà successivamente quello di Antonio Mazzeo (blog), giornalista e scrittore siciliano che da anni segue con interesse e professionalità l’inquietante rapporto tra criminalità organizzata e grandi opere del nostro Paese, con particolare attenzione alle infiltrazioni malavitose negli appalti riguardanti i lavori per il ponte sullo Stretto di Messina.
Grazie a un continuo e attento studio delle indagini e dei processi promossi e portati avanti dalla magistratura siciliana, il sig. Mazzeo ha recentemente dato una forma alla sua attività di indagine, pubblicando il libro-inchiesta I padrini del Ponte. Affari di mafia sullo stretto di Messina (scheda del libro).

Ai due (che hanno già confermato la propria partecipazione) verrà affiancata la presenza di istituzioni e politici locali (ci stiamo ancora lavorando…), presumibilmente di due parlamentari e del Commissario o del Tenente della Guardia di Finanza di Lanciano, se questi vorranno accettare l’invito che verrà formalizzato nei prossimi giorni. Speriamo anche nella presenza delle associazioni impegnate nella lotte alla mafia. L’invito sarà esteso anche alla Giunta e al Consiglio comunale di Lanciano, e in particolare inviteremo il Sindaco ad aprire la conferenza con un saluto alla cittadinanza, sicuri della sua presenza.

A margine dell’iniziativa, oltre all’esposizione di cui ho già accennato, Stefano Barbati, musicista e artista lancianese (sito personale), curerà una sessione di reading (“narrazione orale di opere”) di poesie e testi sul tema, occupandosi personalmente dell’accompagnamento musicale.

Inutile dire che durante l’iniziativa potranno essere acquistati entrambi i libri sopra menzionati. Stiamo anche lavorando a una nostra produzione, che vorrebbe raccogliere i migliori articoli da noi prodotti negli ultimi tre anni di attività del giornale, anche per finanziare l’iniziativa e soprattutto per far conoscere il nostro impegno anche oltre lo schermo e il web.

Sì, la data scelta non è tra le migliori e non sarà semplice riempire la sala. Qualcuno (molti) preferirà andare al mare o rimanere fuori Lanciano. Ma il programma è ricco, direi “inedito” e soprattutto promette di essere originalmente interessante. Si spera che questa volta non ci siano scusanti. Cercate di partecipare…

la sala convegni del polo museale Santo Spirito di Lanciano

Ma questo l’hanno notato in pochi, visto che in questo Paese nessuno legge più i giornali; tant’è che – credo – la scusa de “l’informazione in Italia fa schifo ed è manipolata”, presentata anche da chi si riconosce nelle file del movimento anti-casta che oggi ha dato ampia pubblicità a questo caso, sia diventata un ottimo alibi per alleggerire il proprio impegno e dare origine a una protesta qualunquista.

Il paragone con Julian Assange, oltre ad essere veramente ingrato, è semplicemente da idioti. E sintomo del non aver capito nulla, ma davvero nulla del progetto WikiLeaks.

Ma mettiamo che sia tutto vero, che i privilegi documentati (si fa per dire…) su quella pagina siano reali. Certe volte – anche con una certa cattiveria – penso che, fosse così, ci meriteremmo tutto questo. Almeno stando alla facilità con cui “abbocchiamo” al primo troll, al primo personaggio in cerca dei suoi cinque minuti di visibilità.
Non vi preoccupate e non state troppo lì a scalpitare, che ai “signori del palazzo” tutto questo va benissimo, rientra anzi nelle loro migliori aspettative, visto che rende sterile e assolutamente innocua qualsiasi protesta.

Un’ultima cosa, e forse la più importante: a Montecitorio i portaborse sono tutti precari. E – cazzo – ci mancherebbe che non fosse così. Quindi smettetela di protestare per questo.
Il mandato parlamentare ha una durata massima di cinque anni. Poi può anche essere rinnovato, come nei più dei casi accade, certo, ma la durata è sempre quella. Ci manca solo che un parlamentare con un mandato di cinque anni assuma relativi portaborse con un contratto trentennale o che scaduto il suo mandato (cioè non essendo stato rieletto) i suoi portaborse restassero lì con le mani in mano, in attesa che venga rieletto al successivo giro di ruota. E chi dovrebbe pagare tutto questo?
Fosse così, immagino l’ennesima protesta per i cosiddetti “sprechi della casta”, che pur senza avere la certezza comprovata di essere rieletti, assumono portaborse a vita e a nome e a spese dello Stato. E si protesterebbe anche qui, no? Allora è solo un “servire proteste pronte”, senza nessun senso critico.

Certo, se prima di lanciarsi nell’ennesima protesta si accendesse il cervello per due minuti e ci si porrebbero un paio di domande, si eviterebbe di dare origine ogni volta a quello che è solo un lagnosismo fastidioso e senza arte né parte.

Un esempio su tutti: la pagina con gli elementi html può essere più corta della pagina totale mostrata dal browser, nel momento in cui i vari elementi html della prima non riescono a coprirne l’intera altezza della seconda.
Conseguentemente ed immaginando una classica pagina composta da #header, #content, #sidebar (alla sinistra di #content) e #footer, il #footer non apparirà in fondo alla pagina come magari si aspetterebbe un visitatore, bensì in mezzo, lasciando uno spazio vuoto sotto.
Uno schema esplicativo:

Accade perché – ripeto – le altezze di #header, #content e #footer (escludiamo #sidebar, essendo in questo caso più bassa di #content), inclusi i margini, se sommate sono pur sempre inferiori all’altezza totale della pagina mostrata dal browser.
Potete vedere una pagina html di esempio qui.

Al contrario, l’effetto desiderato dovrebbe essere questo più o meno questo:

In altri termini, si vorrebbe che l’altezza di #content (o anche di #sidebar, ma nei più dei casi si preferirà il primo) occupi tutto lo spazio possibile, nel momento in cui è appunto disponibile dello spazio vuoto. Questo problema può essere facilmente risolto avvalendosi di jquery, affinché imposti dinamicamente l’altezza minima (proprietà min-height) di #content.
L’altezza minima può infatti essere correttamente impostata pari alla differenza tra l’altezza della pagina mostrata dal browser e l’altezza di #header e #footer, margini, padding e bordi compresi.

In nostro aiuto troviamo tre utili funzioni offerte da jquery:

1. css() (documentazione), che permette di leggere o di impostare il valore di una proprietà css, e quindi nel nostro caso di impostare l’altezza minima di #content;
2. height() (documentazione), che permette di leggere l’altezza di un elemento, e quindi nel nostro caso l’altezza della pagina mostrata dal browser;
3. outerHeight() (documentazione), che permette di leggere l’altezza di un elemento, comprensiva di bordi e padding, opzionalmente anche dei margini (accetta come argomento un booleano, se questo è TRUE include anche i margini) e quindi nel nostro caso l’altezza effettiva di #header e #footer.

Quindi (codice parziale!) l’altezza minima (min-height, che in jquery diventa minHeight) potrebbe essere calcolata con questa equazione:

$(window).height() - $('#header').outerHeight(true) - $('#footer').outerHeight(true)

E, in definitiva, il codice sarebbe questo:

<script type="text/javascript">
$("document").ready(function() {
   $('#content').css('minHeight', $(window).height() - $('#header').outerHeight(true) - $('#footer').outerHeight(true) - 2);
});
</script>

(in questo caso ho aggiunto un -2 per via del bordo, sia superiore che inferiore, di #content, che dobbiamo tenere in conto. Per fare una cosa fatta per bene, piuttosto che indicare il valore del bordo, bisognerebbe leggere anche quello, rendendo così il calcolo completamente dinamico e utile anche a successive modifiche. Ma più avanti vedremo che non abbiamo bisogno del bordo di #content…)

Ovviamente non ci si dimentichi di includere innanzitutto Jquery. All’interno di head e prima del codice per calcolare l’altezza minima:

<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.6.2/jquery.min.js" type="text/javascript"></script>

Potete vedere il risultato in una pagina html di esempio qui.
Se però confrontate questo risultato con il secondo schema prima presentato, noterete un’importante differenza: nello schema c’è dello spazio vuoto prima di #footer, mentre qui #content occupa tutto lo spazio vuoto. Ma il risultato non poteva che essere questo, visto che siamo andati a intervenire sull’altezza minima di #content. E non è proprio un granché di risultato, visto che #content ha bordo e sfondo colorato (se non avesse né bordo, né sfondo, come spesso può essere, tutto sommato andrebbe comunque bene così, visto che non si vedrebbe comunque la differenza).

È allora necessaria un’ulteriore e ultima modifica: bisogna inserire #sidebar e #content all’interno di un nuovo elemento (div), che sfrutteremo proprio per ottenere il risultato voluto e che chiameremo in questo esempio #container. Se quindi il codice html della pagina prima era questo (sintetizzato al massimo):

<html>
   <head>
   <!-- qui va jquery e lo script visto precedentemente -->
   </head>
   <body>
      <div id="header"><!-- L'header --></div>

      <div id="sidebar"><!-- La sidebar --></div>
      <div id="content"><!-- Il contenuto effettivo della pagina --></div>

      <div id="footer"><!-- Il footer --></div>
   </body>
</html>

Dobbiamo modificarlo per ottenere più o meno questa struttura della pagina:

<html>
   <head>
   <!-- qui va jquery e lo script visto precedentemente -->
   </head>
   <body>
      <div id="header"><!-- L'header --></div>

      <div id="container">
         <div id="sidebar"><!-- La sidebar --></div>
         <div id="content"><!-- Il contenuto effettivo della pagina --></div>
      </div>

      <div id="footer"><!-- Il footer --></div>
   </body>
</html>

E quindi aggiornare il calcolo dell’altezza minima:

<script type="text/javascript">
$("document").ready(function() {
   $('#container').css('minHeight', $(window).height() - $('#header').outerHeight(true) - $('#footer').outerHeight(true));
});
</script>

(notare che abbiamo rimosso il -2 precedentemente aggiunto, visto che #container non ha bordi, essendo funzionale solo a questo trucchetto)

Ora il risultato sarà davvero quello desiderato e possiamo vederlo qui.

<select name="mySelect">
   <option disabled="disabled">-- seleziona --</option>
   <option value="1">Prima opzione</option>
   <option value="2">Seconda opzione</option>
</select>

Proprio perché le ultime due opzioni sono “reali”, a differenza della prima hanno un valore espresso tramite l’attributo value. La prima ha inoltre l’attributo disabled (opzionale), utile per disabilitare appunto l’opzione.

Se non si conosce questo attributo, si consulti la documentazione, da quale:

The disabled attribute specifies that a button should be disabled.
A disabled button is unusable and un-clickable.
The disabled attribute can be set to keep a user from clicking on the button until some other condition has been met (like selecting a checkbox, etc.). Then, a JavaScript is required to remove the disabled value, and make the button usable.

In Symfony sembra che non ci sia nulla per fare tutto questo: non è possibile non impostare l’attributo value, come non è possibile aggiungere l’attributo disabled. Value è l’unico attributo impostabile e per giunta obbligatorio (ci sono alternative, invece, per altri widget, come ad esempio sfWidgetFormDoctrineChoice o sfWidgetFormPropelChoice).
Il motivo è semplice: il widget che genera un menù a tendina, sfWidgetFormChoice (documentazione) accetta un array per popolare le opzioni, dove le chiavi dell’array saranno gli attributi value delle opzioni e i valori dell’array le loro relative etichette.

Il problema è che Php non può – per ovvi motivi – accettare valori per un array senza che tutti abbiano una relativa chiave, che altrimenti verrà sempre e comunque creata. Di conseguenza, il value delle opzioni, popolato a partire dalle chiavi, esisterà sempre, anche se magari è vuoto.

Ad esempio, impostando una chiave vuota:

$form->setWidget(new sfWidgetFormChoice(array('choices' => array('' => '-- seleziona --', '1' => 'Prima opzione', '2' => 'Seconda opzione'))));

Il codice generato sarà il seguente (value è vuoto, ma esiste comunque, e non è la stessa cosa):

<select name="mySelect">
   <option value="">-- seleziona --</option>
   <option value="1">Prima opzione</option>
   <option value="2">Seconda opzione</option>
</select>

Mentre invece, non indicando nessuna chiave per il primo elemento:

$form->setWidget(new sfWidgetFormChoice(array('choices' => array('-- seleziona --', '1' => 'Prima opzione', '2' => 'Seconda opzione'))));

Php, automaticamente, gli assegnerà la chiave 0 e quindi il codice generato sarà il seguente:

<select name="mySelect">
   <option value="">-- seleziona --</option>
   <option value="1">Prima opzione</option>
   <option value="2">Seconda opzione</option>
</select>

Infine, in nessun caso è possibile impostare l’attributo disabled.

Le soluzioni sono allora due:

1. riscrivere il widget (sfWidgetFormChoice.class.php, sfWidgetFormChoiceBase.class.php e sfWidgetFormSelect.class.php, tutti in /lib/widget);
2. modificare il form con jquery.

Ho scelto la seconda strada (buona fortuna a quelli che dovessero scegliere la prima…), nonostante non possa nascondere che l’altra sarebbe più brillante e pulita, sebbene molto più complessa.
In questo caso, il codice è breve e facilmente comprensibile: è sufficiente selezionare tutti gli option con value vuoto ma esistente (evitiamo invece di lavorare sugli 0 e nel widget sarà sempre meglio usare una chiave vuota, semmai poi dovessimo avere realmente bisogno di un option con value 0), rimuovere completamente l’attributo value e (opzionalmente) aggiungere l’attributo disabled con valore disabled:

$("document").ready(function() {
   $('option[value=""]').removeAttr("value").attr("disabled", "disabled");
});