encfs provides an encrypted filesystem in user space, which means you don't need to encrypt a full partition, but rather you can create an encrypted filesystem on the fly.

Creating an encfs filesystem

$ mkdir /home/adotti/.work /home/adotti/work
$ encfs /home/adotti/.work /home/adotti/work
Creating new encrypted volume.
Please choose from one of the following options:
enter "x" for expert configuration mode,
enter "p" for pre-configured paranoia mode,
anything else, or an empty line will select standard mode.

Pre-configured paranoia mode was enough for my needs, so I simply typed p.

Paranoia configuration selected.

Configuration finished.  The filesystem to be created has
the following properties:
Filesystem cipher: "ssl/aes", version 2:1:1
Filename encoding: "nameio/block", version 3:0:1
Key Size: 256 bits
Block Size: 512 bytes, including 8 byte MAC header
Each file contains 8 byte header with unique IV data.
Filenames encoded using IV chaining mode.
File data IV is chained to filename IV.

New Encfs Password: 
Verify Encfs Password:

Using the encrypted filesystem

At this point my new encrypted filesystem is ready to be used:

$ encfs /home/adotti/.work /home/adotti/work
EncFS Password:

Note that while files are encrypted, files metadata are not. Size, permissions and the number of files remain visible.

Prerequisites

It seems that only JDK is needed to get things working, so a simple

$ aptitude install sun-java5-sdk

will suffice.

Installing JBoss

The following instructions are just a compact rewrite of the information found in this useful post: JBoss on Debian quickstart.

$ cd /opt
$ unzip /home/adotti/jboss-4.2.2.GA.zip
$ mv jboss-4.2.2.GA jboss
$ jboss/bin/run.sh -b 192.168.10.13

A lot of logging output will flood your terminal... as soon as you see the following line:

INFO  [Server] JBoss (MX MicroKernel)
      [4.2.2.GA (build:SVNTag=JBoss_4_2_2_GA date=200710221139)] Started in 50s:564ms

you can point your browser to http://192.168.10.13:8080/ (the address specified after the -b option) and check if everything is working as expected.

Usually, getting rid of these monstrous sized logs is the quickest way to get some free space back, but I am not inclined to delete logs. A better approach, in my opinion, is to force a log rotation, which usually led, more or less, to the same result.

On a Debian system you can trigger the following cron script manually:

$ /etc/cron.daily/sysklogd

and your system logs get immediately rotated.

Basically, watch does what the curses mode of lsmbox did: run a command every n seconds. So i just added the following alias in my .bashrc file:

alias mymail='watch -t -n 300 lsmbox -n -s -S -t /home/adotti/Mail/'

and I got the handy list of mailboxes with unread messages back.

When I have to upgrade the hard disk of my system, I usually plug the new hdd in the machine, partition it, copy the data, install the boot loader, remove the old disk and reboot.

But, what if there are some oddities that prevent your boot loader to be manually installed on the new disk, and you don't have time/will/opportunity to sort out the issue? Well, this is just another way of performing the disk upgrade, at least with debian.

1. plug the new disk into the machine and unplug all other disks (if present)
2. boot with the Debian net install cd
3. install a minimal debian on the new disk (this step allows partitioning and installs the boot loader)
4. plug the old disk(s) back and reboot the system using the old installation; go into single user mode
5. wipe the newly created file systems and copy all data to the new disk
6. edit the files that need to (if any)
7. remove the old disk and reboot

Having a B-plan is a must. With unix it is easy :)

Yesterday I took some time to upgrade my NetBSD test server packages collection to pkgsrc-2007Q3.

I updated the source tree:

$ cvs updated -dP -r pkgsrc-2007Q3

then I perform a bulk upgrade of all installed packages (not many to be honest):

# /usr/pkg/sbin/pkg_chk -g
# /usr/pkg/sbin/pkg_chk -us

It wasn't that smooth. I encountered two different kinds of problems:

• some makefiles needed to be manually edited, since cvs was not able to merge all changes automatically
• some packages couldn't be installed as part of the bulk process. I haven't completely understand the problem, so I just got rid of it by manually installing the new version of each problematic package

In the end I got it running, and everything seems fine. I had the feeling of a logical approach after all, so I am quite comfortable with this.

Feeling really comfortable with my outline based gtd system, I decided to go one step further. I have a bunch of cards, one for each project I'm working on, so I looked for a nice way to managed them. Some kind of interface that helps me browse, filter and edit the cards.

I haven't found anything suitable on the net, so I decided to go my way and code a little helper from scratch. The result is a cards browser with some filtering capabilities; it is project oriented rather than action oriented, simply because that's how I feel comfortable in managing my tasks.

Information, a screenshot and download links can be found on my personal web site.

After performing a source-way upgrade of my NetBSD system, I decided to try out a different approach using the binary sets.

I got all the sets I needed from a handy mirror, then I performed the following steps:

$ tar zcvf etc-backup.tar.gz /etc
$ cp /netbsd /netbsd.old

$ tar zxvpf kern-GENERIC.tgz -C /
$ tar zxvpf base.tgz -C /
$ tar zxvpf comp.tgz -C /
$ tar zxvpf man.tgz -C /
$ tar zxvpf text.tgz -C /
$ tar zxvpf games.tgz -C /

$ mkdir /tmp/tmproot
$ tar zxvpf etc.tgz -C /tmp/tmproot
$ etcupdate -s /tmp/tmproot/etc

After all the modifications needed to the configuration files were done, I just rebooted the system.

Few days ago I had the occasion to get a quite old but really robust keyboard. I guess it's from the 90's, but it still have a really wonderful touch and works very very well.

Since it has an Italian layout, I took some time to configure dwm for switching between American and Italian layouts.

I just added the following lines to the config.h file:

        { MODKEY|ShiftMask|ControlMask, XK_i, spawn, "exec setxkbmap it" }, \
        { MODKEY|ShiftMask|ControlMask, XK_u, spawn, "exec setxkbmap us" }, \

and recompilied dwm. It works flawlessly.

After upgrading my NetBSD system, I decided to upgrade the packages collection. These are the step I've done.

Set cvs environment variables

Put in my .bashrc the following lines:

export CVSROOT="anoncvs@anoncvs.NetBSD.org:/cvsroot"
export CVS_RSH="ssh"

Updated the sources

$ cvs -q update -dP

Upgraded the packages

Refreshed the list of installed packages:

$ pkg_chk -g

The list was saved in /usr/pkgsrc/pkgchk.conf.

Updated the packages:

$ pkg_chk -us

Yesterday I finally find the time to upgrade wolverine, my NetBSD test server. I was in the mood to try something new, so I decided to perform the upgrade starting from sources.

It was really smooth, although it took a lot of time to compile everything (wolverine is a PIII 500Mhz). Here are the steps performed.

Backup data (/etc):

$ tar zcvf etc-3.0.tar.gz /etc

Prepare the directories (as root):

% mkdir /usr/src
% mkdir /usr/obj
% mkdir -p /usr/builds/i386
% mkdir -p /usr/releases/i386

Change the ownership of those directories to you user.

Get the sources:

$ wget ftp://ftp.NetBSD.org/pub/NetBSD/NetBSD-3.0.2/source/sets/*.tgz

Unpack the sources:

$ for file in *.tgz; do tar zxvf $file -C /; done

Build or update the crosscompiler:

$ cd /usr/src
$ ./build.sh -D /usr/builds/i386 -R /usr/releases/i386 -u -m i386 tools

Crosscompile the kernel:

$ ./build.sh -D /usr/builds/i386 -R /usr/releases/i386 -u -m i386 kernel=GENERIC

Install the new kernel (as root):

% cd /
% mv netbsd netbsd-3.0
% cp /usr/src/sys/arch/i386/compile/obj/GENERIC/netbsd .

Reboot the system.

Crosscompile the userland:

$ build.sh -D /usr/builds/i386/ -R /usr/releases/i386/ -U -u -m i386 build

Install (as root):

% build.sh -D /usr/builds/i386/ -R /usr/releases/i386/ -U -u -m i386 install=/

Review postinstall failed checks and fix things accordingly.

Update /etc (as root):

% /usr/sbin/etcupdate

I've never had a good occasion to use custom chains with netfilter. The usual setups I had to prepare were simple enough to achieve the required results using the built-in chains.

Few days ago I had to configure another box to act as a firewall, so I decided to try out custom chains:

#===============================================================================
#
# CUSTOM CHAINS
#
#===============================================================================

# Chain for packets coming from the internet

$IPTABLES -N internet-allowed

$IPTABLES -A internet-allowed -p tcp -m state --state NEW --dport $SSH -j ACCEPT
$IPTABLES -A internet-allowed -p tcp -m state --state NEW --dport $MUNIN -s $MUNIN_MASTER -j ACCEPT

# Chain for packets coming from the wireless network

$IPTABLES -N wireless-allowed

$IPTABLES -A wireless-allowed -p tcp -m state --state NEW --dport $CHILLI -j ACCEPT
$IPTABLES -A wireless-allowed -p tcp -m state --state NEW -m multiport --destination-port $HTTP -j ACCEPT
$IPTABLES -A wireless-allowed -p udp --dport $DNS -j ACCEPT

# Chain for packets coming from the wireless network and forwarded to the
# internet

$IPTABLES -N wireless2internet

$IPTABLES -A wireless2internet -p tcp -m state --state NEW -m multiport --destination-port $HTTP -j ACCEPT

#===============================================================================
#
# INPUT CHAIN
#
#===============================================================================

$IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

$IPTABLES -A INPUT -i $LOIF  -j ACCEPT

$IPTABLES -A INPUT -i $EXTIF -j internet-allowed
$IPTABLES -A INPUT -i $EXTIF -j LOG --log-prefix "IN EXT REJ: "

$IPTABLES -A INPUT -i $INTIF -j LOG --log-prefix "IN INT REJ: "

$IPTABLES -A INPUT -i $TUNIF -j wireless-allowed
$IPTABLES -A INPUT -i $TUNIF -j LOG --log-prefix "IN TUN REJ: "

#===============================================================================
#
# FORWARD CHAIN
#
#===============================================================================

$IPTABLES -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

$IPTABLES -A FORWARD -i $EXTIF -j LOG --log-prefix "FW EXT REJ: "

$IPTABLES -A FORWARD -i $INTIF -j LOG --log-prefix "FW INT REJ: "

$IPTABLES -A FORWARD -i $TUNIF -o $EXTIF -j wireless2internet
$IPTABLES -A FORWARD -i $TUNIF -j LOG --log-prefix "FW TUN REJ: "

Although they were not strictly needed, I think they are good to improve readability anyway, as you can see from the previous snippet of the firewall script.

Final steps for my etch upgrade. On the test machine I just had to perform two tasks to tune the system.

Filesystem tuning

I added the dir_index flag to all non volatile filesystems. The dir_index option force the use of hashed b-trees to speed up lookups in large directories.

$ tune2fs -O +dir_index /dev/hda1

the previous operation was repeated for all filesystems.

Old kernels removal

I used aptitude to remove any old 2.4 kernel installed on the system.

I got gargoyle, the etch upgraded testing box, ready from a week or so; it was time to do the job.

I just followed the etch release notes step by step. For the impatient - remembering that this a standard sarge headless box - this is what I did:

• changed the sources for apt
• updated the package list (aptitude update)
• performed an upgrade (aptitude upgrade)
• installed intitrd-tools to get libc6 and locales updated (other things will be updated as well)
• performed a dist upgrade (aptitude dist-upgrade)
• edited any configuration file that needs to be fixed or updated
• updated the package list again
• removed obsolete packages
• rerun lilo (/sbin/lilo -v)
• rebooted

Etched :)

Before following the step outlined above, keep in mind that you might have to perform some more or different steps, depending on your setup. Definitely read the release notes!

You have been warned...

I took the chance of a quiet Saturday morning to start testing the upgrade path from sarge to etch. The target machine was gargoyle, a FTP server with a minimum set of packages installed, and it was chosen to discover the most relevant problems I could encounter with the other boxes I own (my setups are quite similar).

The only mayor issue outlined in the release notes is the need to upgrade the kernel before the full upgrade takes place. The box run a 2.4.27 kernel, so I needed to upgrade to a 2.6.8 kernel. As far as I could test, the via_rhine driver shipped with the official debian kernel sources is broken, so I used a vanilla 2.6.8.1 kernel to have my D-Link network card working.

Now that everything is in place, I'm ready...

Grazie ad un estemporaneo suggerimento di Zack, ho scoperto lsmbox, simpatica utility che consente di rilevare il numero di nuovi messaggi in una o più mailbox. Molto utile l'interfaccia testuale che consente di avere un elenco sempre aggiornato della situazione.

Non ho avuto dubbi a pensionare il bradipale script shell che tempo fa avevo creato allo scopo.

Dirò una cosa ovvia, ma se si vuole utilizzare sempre l'ultimissima versione di un'applicazione, è caldamente consigliato aggiornare senza saltare versioni in mezzo. Questo, ovviamente, in un mondo perfetto dove la disponibilità di tempo è praticamente totale. Nella realtà, il tempo non sempre c'è, e gli upgrade non sono sempre indolori; il dolore provato dipende dalla complessità dell'applicazione che si usa.

Nel mio caso, mi sono trovato ad aggiornare dwm dalla versione 3.3 alla neonata 3.7... e nel frattempo il codice dell'applicazione è stato ampiamente ripulito, lasciandomi con un file di configurazione praticamente inutilizzabile. Considerate che il mio C è particolarmente arrugginito, quindi la gestione dei pittoreschi errori che mi sono presentati in fase di compilazione non è stata proprio banale.

In trenta minuti di sevizie alla tastiera mi sono guadagnato un posto privilegiato in uno dei gironi danteschi, ma almeno il mio window manager preferito viaggia liscio come l'olio, e, a quanto mi pare di percepire, più veloce di prima.

Morale della favola: il feticismo può anche essere doloroso, e la macchie di sangue sulla tastiera potrebbero finire per essere le tue. Talvolta ne vale la pena.

Come d'abitudine, ogni anno provvedo alla sostituzione dell'hard disk del mio server casalingo. Quest'anno ho posticipato un po' l'intervento, ed alla fine mi sono ritrovato con nuovo hardware da utilizzare. Anzichè cambiare il disco come al solito, ho cambiato tutta la macchina.

Essendo una persona estremamente pigra rispetto a questo genere di attività, ho cercato di minimizzare il peso della cosa. Quattro ore sono state sufficienti a ripristinare le cose esattamente come erano prima, eccezzion fatta per il ferro che fa girare il tutto.

Ecco una breve check list delle cose che ho fatto; sai mai che possa tornare utile.

• montata la macchina con disco nuovo
• installata una debian minimale via rete
• compilato un kernel ad hoc (cosa perfettamente superflua ma sono abituato così).
• installati un po' di orpelli per amministrare meglio il sistema (editor, file manager e altri tool vari)
• configurato il firewall ed eseguito l'hardening di base
• inserito il disco che uso per i backup, contenente anche i dati del vecchio server
• installati i servizi necessari
• ripristinate le configurazioni dei servizi e gli altri dati

Tutto come prima, solo più veloce.

Aggiungendo questa riga nel vostro .xsession (o .xinitrc, a seconda di quello che usate):

echo "[`xwininfo -root -children 2>/dev/null \
| grep Psi \
| grep -c '*'`]"

vi comparirà nella status bar il numero di finestre di psi che hanno cambiato stato - ovvero che contengono nuovi messaggi o altre notifiche.

Una piccola avvertenza: la gestione del fuoco delle finestre attraverso i diversi tag, in dwm, non è propriamente intuitiva, per cui, per avere una informazione corretta, dovrete adattarvi un attimo.

Per i curiosi, ecco il mio .xsession completo.

export PATH=$PATH:/home/adotti/bin
while true
do
    echo "[`xwininfo -root -children 2>/dev/null | grep Psi | grep -c '*'`]" \
    `date "+%Y-%m-%d [%R]"` \
    `uptime | cut -c 14-18`
    sleep 2
done | dwm

Un grazie ad Antoni Grzymala per i suggerimenti.

Ho aggiornato oggi, e devo dire che la mia impressione rispetto a questa modifica è favorevole; non è che mi servissero molto. Inoltre, apprezzo molto la nuova combinazione di colori, che rende l'insieme, visivamente, molto più pulito.

Vi rimando alla home page del progetto per il download e per gli screenshot di rito (al momento non ancora aggiornati).

Questa nuova release ha in particolare una singola nuova funzionalità, che personalmente trovo estremamente utile: è possibile definire - e cambiare a runtime - il numero di client che vengono collocati nella master column. Questo consente di ottenere facilmente sia layout orizzontali (non credo di essere l'unico che fa monitoraggio di log), sia layout complessi con un arbitrario numero di finestre di egual importanza. Vi consiglio di provare... il livello di flessibilità che si ottiene è veramente altissimo.

Altra cosa che ho fatto contestualmente all'aggiornamento del window manager, è stata l'installazione di dmenu. Comando molto versatile che non ho ancora esplorato completamente, ma che trovo sin d'ora molto utile per lanciare comandi al volo (dwm non implementa nativamente alcun tipo di menu).

Resto in attesa di qualche altra minimale mirabilia, ed intanto mi godo il mio nuovo desktop :)

Questa release a qualcosa di interessante in più su cui forse vale la pena spendere due parole. Per chi è abituato ad usare il tiled mode, è possibile sganciare una o più finestre e renderle fluttuanti al di sopra delle altre (che prontamente si riadatteranno al maggior spazio disponibile).

Al momento non ho nessun esempio concreto di utilizzo, ma questo piccolo incremento di flessibilità mi dà buone sensazioni...

Per chi utilizza postfix, la cose si risolve in modo abbastanza semplice. Nel mio caso, ho necessità di fare in modo che tutti i messaggi inviati automaticamente da tutte le macchine della mia rete privata risultino spediti dal mio indirizzo e-mail pubblico. Utilizzo un mail server unico per servire tutta la rete.

sender canonical maps

La prima cosa da fare è creare il file /etc/postfix/sender_canonical. Il mio contiene quanto segue:

/adotti\@.*.nowhere.local/      alessandro@hyboria.org

Una volta creato/modificato il file in questione, occorre trasformarlo in un formato utile per postfix:

$ postmap /etc/postfix/sender_canonical

Fate riferimento alla man page di canonical(5) per informazioni complete su come utilizzare le canonical_maps.

(ri)configurare postfix

Modificate il vostro /etc/postfix/main.cf aggiungendo la seguente riga:

sender_canonical_maps = pcre:/etc/postfix/sender_canonical

e riavviate il servizio.

NB: per mia comodità ho utilizzato nel file sender_canonical delle espressioni regolari perl-compatibili (pcre). Sono ovviamente supportate anche le espressioni regolari standard... basta sostituire pcre con regexp e modificare le regole contenute in sender_canonical di conseguenza. Potete fare riferimento alle man page pcre_table(5) e regexp_table(5) per maggiori dettagli.

Delle patch contribuite dai diversi partecipanti alla mailing list del progetto è stata fatta una raccolta pubblicata sul sito ufficiale. Di mio, ve ne segnalo una che trovo molto utile:

bottom stack patch

Consente di modificare l'orientamento delle colonne in cui viene diviso lo schermo da verticale ad orizzontale. Una manna se dovete analizzare dei log o modificare dei file con righe molto lunghe e non volete ricorrere a finestre massimizzate.

Basta patchare i sorgenti, modificare il file di configurazione e ricompilare... come al solito :)

Installazione

Non mi dilungherò sulla procedura di installazione; in Debian si riduce ad un:

apt-get install munin munin-node

Terminato il download e l'installazione dei pacchetti, munin è già pronto per essere utilizzato. Vengono infatti rilevati tutti i servizi presenti sulla macchina ed installati tutti i plugin necessari (se disponibili).

Puntate il vostro browser all'indirizzo http://localhost/munin/ e potrete redervi conto di persona di cosa si tratta.

Nota: vi consiglio di verificare anche i pacchetti che vengono indicati come "raccomandati" e "suggeriti"; qualche plugin potrebbe averne bisogno.

Plugin

La quantità disponibile di plugin è notevole. Non tutto viene attivato in automatico, ma attivare plugin supplementari è molto semplice, basta creare dei link simbolici nella cartella contente i file di configurazione di munin. Unica eccezione, fra le cose che ho provato, riguarda apache. Per poterlo monitorare occorre agire sulla sua configurazione (niente di complicato).

Altre cose

Un paio di altre cose che giudico interessanti ma che non ho avuto ancora il tempo di testare riguardano l'impostazione di allarmi al verificarsi di condizioni critiche o comunque di attenzione - a quanto pare gli allarmi possono essere inviati per e-mail o integrati con nagios - e la creazione di grafici personalizzati.

Per chi fosse interessato ad approfondire, rimando al sito ufficiale. Troverete tutta la documentazione che desiderate.

Recentemente ho cercato di migliorare la mia gestione dell'uso di gpg per firmare le e-mail quando ne ho necessità. Non ne faccio un sistematico, ma ci sono diverse situazioni in cui mi è utile apporre la mia firma digitale ai messaggi in uscita.

La versatilità di Mutt offre un discreta quantità di parametri di configurazione, e bisogna dire che i default impostati sono saggi e consentono un'uso di gpg praticamente immediato. Ho comunque limato qualche piccolo spigolo. Questo è il pezzo di configurazione personalizzato che ho aggiunto al mio muttrc:

# non firmare automaticamente tutti i messaggi in uscita
#
unset crypt_autosign

# non cifrare automaticamente tutti i messaggi in uscita
#
unset crypt_autoencrypt

# cifra automaticamente le risposte a messaggi cifrati
#
set crypt_replyencrypt

# firma automaticamente le risposte a messaggi firmati
#
set crypt_replysign

La versione 1.5 è appena stata rilasciata, e contiene una feature aggiuntiva che personalmente trovo molto comoda. E' possibile allargare/restringere la dimensione della master column al volo; gli incrementi sono configurabili, al solito, nel file config.h. Niente più compilazioni supplementari nel caso vi accorgeste che per fare una particolare operazione avete bisogno di finestre tiled più grandi.

Altra funzionalità aggiunta, che però io non uso, è quella di visualizzare contemporaneamente tutti i client associati a tutti i tag.

Il file di configurazione differisce di sole tre righe dalle versioni precedenti (almeno dalla versione 1.2, da cui ho fatto l'aggiornamento), per cui l'upgrade è più veloce del solito.

Infine, una cosa che non ho potuto verificare, ma che è stata riportata nella mailing list degli sviluppatori, è che dwm gira anche sotto MacOSX. Se l'interfaccia standard di casa Apple vi sembra troppo carica...

Buona compilazione.

Questa nuova uscita presenta una succosa novità, ovvero la possibilità di fare merge di più tag, in modo raggruppare nella vista corrente tutti i client appartenenti ai tag coinvolti nell'operazione. Un pizzico di flessibilità abbastanza utile, specie se siete un po' disordinati nel disporre le cose (o se cambiate spesso idea).

Segnalo anche l'eliminazione della navigazione sequenziale fra i tag, oltre al cambiamento di qualche keybinding nella configurazione di default. Considerando che dovrete mettere mano al file di configurazione prima di compilare il tutto, la cosa non dovrebbe essere un problema: potete facilmente ripristinare la cose secondo gusto.

Buon upgrade.

Se vi trovate a gestire diverse macchine, magari con configurazione hardware identica, oppure se qualcuna di esse è particolarmente datata - come mi capita abbastanza di frequente - converrete che avere la possibilità di compilare un kernel configurato secondo gusto altrove, e generare un pacchetto deb pronto per essere installato ovunque serva, è molto comodo.

Oltre che molto comodo è anche molto facile. Basta avere i sorgenti del kernel a portata di mano ed installare il pacchetto kernel-package.

Spacchettate i sorgenti del kernel:

$> tar jxvf kernel-source-2.4.27.tar.bz2

Configuratelo come più vi piace:

$> cd kernel-source-2.4.27/
$> make menuconfig

Compilate:

$> make-kpkg --revision 01 --append-to-version -adc kernel_image

A questo punto il vostro pacchetto è pronto per essere installato nel solito modo ovunque vi serva:

$> dpkg -i kernel-image-2.4.27-adc_01_i386.deb

Due note sulle opzioni che ho usato:

--revision

Imposta il revision number del kernel da compilare. Preferisco specificarlo a mano dato che il default altrimenti usato non mi piace.

--append-to-version

Imposta la variabile EXTRAVERSION nel Makefile del kernel. La valorizzo sempre, per fare in modo che ogni versione diversa del kernel abbia il proprio albero di moduli in /lib/modules/ (evitando così aggiunte e rimozioni incontrollate dopo ogni nuova compilazione).

Ci sono moltissime altre opzioni disponibili; vi consiglio caldamente di leggere la man page di make-kpkg.

La nuova release è appena uscita, e dovremmo ormai esserci per avere una versione che includa tutte le feature previste e sia stabile nella configurazione; le note per l'aggiornamento segnalano infatti alcune modifiche non appariscenti e alcuni bugfix, oltre ad un (ennesimo) cambiamento nel formato del file di configurazione (più compatto e, purtroppo, un po' più complicato).

Intanto, parallelamente allo sviluppo di dwm, prosegue anche lo sviluppo di dmenu, applicazione concepita come gestore di menu autonomo che può essere usato con qualsiasi window manager. Ricorda molto il menù di wmii.

Sempre dal fronte del programmare entro le diecimila linee di codice, pare sia in lavorazione un emulatore di terminale... aspettiamoci un'altra mirabolante creatura minimale con cui divertirci questo autunno.

Trattandosi di un window manager minimale, il numero delle feature aggiunte tende a zero; sono state sistemate alcune cosette e, per facilitare l'approccio elitario alla configurazione, tutte le opzioni sono state raggruppate nel file config.h. Niente più editing dei file .c sparsi nell'albero dei sorgenti :) Un'altra cosa che ho apprezzato è la possibilità di spostamento sequenziale tra i workspace usando i tasti h e l. Fa molto vim e fa pure molto confortevole.

Un gioco breve, in ultima analisi, ma certo soddisfacente.

Dei progetti ospitati, ho provato i due window manager, wmii e dwm

wmii

Sono da tempo un fan di window manager che abbiano una filosofia diversa rispetto ai soliti ambienti a finestre. Inoltre ho sempre cercato, per quanto possibile, di individuare quelli che, oltre ad essere leggeri, fossero anche comodi da gestire tramite tastiera.

wmii (che uso con soddisfazione da diversi mesi) ha alcune feature molto interesanti, oltre alle sopracitate caratteristiche. In primis, cerca di utilizzare i workspace in modo diverso dal solito; ai vari client (le applicazioni) possono essere applicati un numero arbitrario di tag, il che consente di raggrupparli in modo dinamico a seconda di cosa si stia facendo. Le finestre, inoltre, vengono gestite automaticamente in modo da occupare la maggior superficie disponibile sullo schermo (tiled mode), per quanto sia possibile attivare il consueto floating mode se le applicazioni che si stanno usando lo richiedono.

Altro punto a favore di wmii è quello di avere una configurazione abbastanza semplice, costituita da un unico shell script che viene eseguito in automatico all'avvio oppure manualmente ogni volta che serve riconfigurare al volo il window manager. Facile quindi intuirne la flessibilità e altrettanto facile intuire che la configurazione può non essere banale quado si portano le personalizzazioni all'estremo.

L'intero ambiente di lavoro può anche essere controllato dinamicamente modificando i valori presenti nel filesystem virtuale (stile /proc per intenderci) che il window manager esporta.

Per contro, il look è abbastanza spartano e la gestione delle applicazioni che usano molte finestre non massimizzate (come Gimp) è sicuramente perfettibile.

dwm

dwm (Dynamic Window Manager) è un altro window manager molto interessante, per quanto al momento ancora un po' immaturo (siamo alla versione 0.5).

Cito dal sito:

Because dwm is customized through editing its source code, it's pointless to make binary packages of it. This keeps its userbase small and elitist. No novices asking stupid questions.

Questo vi fa capire cosa avrete per le mani, se vorrete provarlo. Tutte le personalizzazioni si fanno modificando il file dwm.h, ed altri file sorgente (tag.c, event.c, main.c) presenti nell'albero del codice, prima della compilazione.

La filosofia è un'estremizzazione di quella di wmii (da cui dwm evidentemente deriva) e l'ambiente di lavoro nudo e crudo. Interessante, oltre alla gestione dinamica dei tag, anche la gestione dinamica delle finestre; si può passare dalla modalità tiled alla modalità floating al volo, cosa molto utile..