Ci sono ottime ragioni per rimanere sulla versione stabile di Debian. Ce ne sono di altrettanto valide per decidere di seguire la testing. Per chi vuole tenere il piede in due scarpe, esiste una terza via: mantenere la maggior parte dei pacchetti alla versione stabile e ricorrere alla testing solo per alcuni selezionati software di cui è richiesta la versione più nuova. Mi piace chiamare questa configurazione "testing on demand".

Penso che siano tutti d'accordo che Grub non sia, nel panorama dei boot loader per Linux, un esempio di leggerezza o di linearità, con le funzionalità suddivise in centinaia di moduli e la configurazione a tre livelli (prima /etc/default/grub, poi i template in /etc/grub.d/ e infine /boot/grub/grub.cfg).

Ma allora qual è il boot loader più leggero? Lilo? Forse rEFInd? Sbagliato: il più leggero in assoluto è... non aver nessun boot loader.

Volevo scrivere script per sed che filtrasse i commenti in stile C, cioè racchiusi tra /* e */.

Su LWN, ras riassume egregiamente come GNOME e systemd siano ugualmente responsabili della catena di eventi che ha portato ad attivare d'ufficio KillUserProcesses, l'opzione che termina tutti i processi di un utente quando questi fa il logout.

Collegandosi al sito https://panopticlick.eff.org è possibile sapere quanto il nostro browser rivela di noi.

È interessante scoprire quanti bit di informazione sono veicolati semplicemente dall'elenco dei font installati o dai plugin abilitati. Per non parlare dell'User Agent: mi verrebbe voglia di sostituirlo con una stringa più anonima, tipo quella di Internet Explorer... Solo che poi sarei l'unico con l'User Agent di IE e i font DejaVu, quindi ancora più tracciabile!

Stufo di passare ore a configurare Vim ogni volta che lo installo su un nuovo computer, solo per ritrovarmi con sottili differenze tra un'istanza e l'altra, ho preso una decisione drastica: affidarmi a una configurazione standard, ma ragionevole (ben diversa da quella d'ufficio, che non è ragionevole per niente).

È quello che promette il progetto vim-sensible, come recita il suo manifesto:

Citazione:

Pensate a sensible.vim come il gradino dopo il modo 'nocompatible': un insieme di impostazioni d'ufficio condivisibili da chiunque.

Di solito le discussioni sulla Linux Kernel Mailing List sono talmente tecniche da risultare noiose, ma qualche volta i toni si scaldano quando questo o quello sviluppatore cerca di difendere a spada tratta la soluzione che sta propugnando e in quel caso non si risparmiano attacchi personali al limite dell'insulto. La discussione che ha animato la mailing list a settembre è atipica, non tanto nei toni surriscaldati, quanto nel quesito ben poco tecnico che ne è alla base, cioè se sia giusto o no incoraggiare i novellini a scrivere e proporre correzioni banali, al limite anche meri ritocchi estetici.

Ai tempi di UNIX era lecito aspettarsi che ogni macchina avesse un proprio servizio di posta, capace di gestire la mail in entrata, in uscita e locale. Oggi abbiamo computer personali connessi a Internet in modo intermittente e spesso con indirizzi dinamici, e abbiamo caselle di posta su server esterni, come Gmail o quello del nostro service provider. Quindi un server di posta in stile UNIX che gira in locale non sembrerebbe di grande utilità. Eppure, molti programmi si aspettano ancora che ci sia qualche meccanismo di smistamento della posta in locale. È il caso ad esempio di cron, il quale, in caso di errore nell'esecuzione di qualche script, avverte root tramite un'email.

Ho visto un Asus F200MA e non ho saputo resistere... Con il suo schermo da 11.6", un peso di appena 1,2 kg e la componentistica compatibile con Linux, sembrava davvero quello che stavo aspettando.

Sembra che da qualche mese NVIDIA e Broadcom abbiamo iniziato a divulgare i sorgenti dei loro driver proprietari.