Disabilitare il salvataggio dei core con systemd

Eclipse da un po' di tempo a questa parte esegue un'operazione non corretta, che non intendo dettagliare in questo post, tale problema causa il crash del processo ed il conseguente salvataggio dello stato della memoria.
Il salvataggio della memoria di un processo che chiude in modo anomalo è utilissimo per poter indagare sulla causa dell'errore ma quando non si ha intenzione di indagare oppure non si è in grado l'operazione di salvataggio risulta inutile.
Nel caso specifico di Eclipse il salvataggio della memoria è un procedimento assai lungo ed essendo il momento in cui sto per spegnere il computer lo trovo molto fastidioso. L'aspetto più fastidioso è quello di ritrovarsi con la macchina impegnata a scrivere alcune centinaia di MiB su disco e quindi risulta scarsamente reattiva alle sollecitazioni dell'utente e tantomeno le richieste di spegnimento.
I nuovi metodi di gestione del sistema introdotti qualche mese fa su Arch Linux ancora mi risultano un po' oscuri e queste situazioni mi spingono a documentarmi, nella pagina di manuale di systemd-system.conf ho trovato nella sezione [Manager] il parametro da modificare per disabilitare il salvataggio del core:

DumpCore=no

Nel file /etc/systemd/system.conf l'ho trovata commentata con il # ad inizio riga ed il valore era yes, quello corrispondente al default, quindi l'ho "decommentata" eliminando il # e corretto con no.

Per rendere effettiva la modifica eseguire il comando

systemctl daemon-reload

oppure riavviare il sistema.

Finalmente alla chiusura di Eclipse non ho più quella fastidiosa sensazione di perdita del controllo del PC.

Lubit distribuzione leggera

Da qualche giorno è disponibile per il download la distribuzione Lubit.
Realizzata da una piccola comunità italiana, è basata su Ubuntu 13.04 e preconfezionata in modo da permettere un notevole risparmio in termini di memoria.
La prima prova in modalità live su macchina virtuale VirtualBox mi ha fatto un'ottima impressione; dopo l'installazione, sempre su macchina virtuale, l'impressione è ancora migliorata.
Vedere utilizzati 86.1MiB di memoria RAM avendo attivato un desktop grafico di tutto rispetto la rende molto utilizzabile con hardware datati ma ancora funzionanti.
Il fatto di avere OpenBox come window manager ne permette una configurabilità notevole per le operazioni con il mouse e con quelle da tastiera che personalmente prediligo.

Concludo con il consiglio di provare questa distribuzione e riporto la Pagina di presentazione e quella per il download

Chrome e audio con Flash su Linux x86_64

Con il mio Arch Linux x86_64 ho avuto un problema di audio guardando dei filmati dal sito motogp.com con browser Chrome, l'audio è "zoppicante".
Cerca e cerca ho trovato nel magico forum ufficiale di Arch l'opzione da dare a chrome per risolvere il problema:

--audio-buffer-size=4096

Con questo l'audio è corretto, spero che prosegua così.

riferimenti:
https://bbs.archlinux.org/viewtopic.php?pid=1252816
https://bbs.archlinux.org/viewtopic.php?id=160605

Openpolis colpisce ancora

In questo periodo in cui la campagna elettorale è nel vivo, l'associazione Openpolis ha redatto un rapporto molto interessante dal nome "Camere Aperte 2013".

Il contenuto è un riassunto dei dati già presenti nel sito ma di ancor più facile consultazione e diffusione.
Vi invito a leggerlo e diffonderlo.

Ecco il link dal quale scaricare il PDF: Camere Aperte 2013

bash e l'aggiornamento delle dimensioni del terminale

Come ho forse accennato in post passati, utilizzo LXDE come desktop environment e bash come interprete di comandi, il tutto dentro varie linux-box con Arch Linux.
Mi capita spesso di aprire una finestra di terminale, attualmente LXTerminal, e lavorare a linea di comando con grande utilizzo delle funzioni di recupero dei comandi precedenti.
A volte, utilizzando Ctrl-R oppure con la freccia verso l'alto per ricercare un comando precedente, mi è capitato che i caratteri venissero disposti male nella riga di comando in modo da rendere impossibile correggere e avere la certezza di sottomettere il comando corretto.
Ho scoperto che non succede sempre, solo quando ho ridimensionato la finestra del terminale, ma non sempre, sapevo che le variabili COLUMNS e LINES contengono le dimensioni in caratteri della finestra di terminale e che vengono aggiornate al momento del ridimensionamento della finestra stessa ed in condizioni normali vengono aggiornate correttamente.
Capita però a volte che non si aggiornino ed ho verificato che non si aggiornano quando la finestra viene ridimensionata durante l'esecuzione di un programma, che sia esso vim, less o qualsiasi altro programma attivo al momento del resize, anche un semplice sleep o una compilazione.
La causa del mancato aggiornamento delle variabili è dovuta al fatto che il programma LXTerminal o similare, manda un segnale SIGWINCH sotto forma di kill al processo attivo al momento del ridimensionamento e non alla shell.
Per ripristinare i corretti valori delle variabili COLUMNS e LINES si può ricorrere a due metodi:
- ridimensionare la finestra nel momento in cui il controllo è tornato alla bash
- mandare il kill corretto alla shell con il comando:

kill -SIGWINCH $$

Per provare eseguire le seguenti operazioni:
- da bash su terminale grafico eseguire e prendere nota dei valori ottenuti con il comando:

echo $COLUMNS $LINES

- eseguire il comando:

sleep 10

- ridimensionare la finestra entro i dieci secondi, prima della ricomparsa del prompt
- rieseguire il comando precedente e se tutto va come ho descritto i valori dovrebbero essere invariati
- eseguire il ridimensionamento oppure il comando:

kill -SIGWINCH $$

- esaminare di nuovo i valori delle variabili che dovrebbero essere aggiornate, sempre che tutto funzioni come ho descritto

AGGIORNAMENTO
senza ricorrere al kill, quandi si è di nuovo al prompt, si può anche ridimensionare di nuovo la finestra, anche di poco. e le variabili vengono reimpostate

Thunderbird e le risposte

Utilizzo ormai da qualche anno Thunderbird come agente di posta elettronica.
Mi trovo bene con molte sue caratteristiche che potranno essere oggetto di post futuri.
Un problema particolare che ho deciso di approfondire è la posizione del cursore nel testo di un messaggio in fase di risposta; quando si risponde ad un messaggio cliccando sul tasto Rispondi (o Reply per la versione inglese) viene creato un nuovo messaggio con aggiunto il testo del messaggio originale, il cursore però si posiziona in fondo al testo.
Non ci vuole molto a posizionarsi in cima, ovvero dove di solito ci si aspetta di scrivere la nostra risposta, per me che sono un amante dell'utilizzo della tastiera Ctrl-Home assolve velocemente il compito.
Considerato che per abitudine rispondo sempre scrivendo all'inizio, ho cercato un modo per avere in automatico il cursore posizionato all'inizio.
L'ho trovato! Tra gli appunti che si possono fare c'è la difficile rintracciabilità delle opzioni di configurazione del prodotto...
Si deve entrare nelle impostazioni dell'account: Menu > Modifica > Impostazioni account...
si deve poi scegliere la voce Composizione ed indirizzi del l'account per il quale si vuole cambiare il comportamento e scegliere inizia la risposta sopra il testo a cui si risponde nella voce dopodiché appena sotto la casella inserisci automaticamente il messaggio originale nella risposta.

Grazie al mio amico Michele che mi ha sensibilizzato sul problema e stimolandomi per la ricerca.

Risorse interessanti su Grails

• Custom Grails Constraints
• Grails Fields plugin example
• Grails Ajax Examples - Scratching my programming itch

La data in Gnu-Linux

Per Unix il tempo è iniziato l'1 Gennaio 1970.
Ogni orario viene riferito a quel momento, quanti secondi sono passati dal 01/01/1970? Nel momento in cui scrivo 1.334.009.466.
Il comando date di Gnu ci fornisce questa informazione passandogli un determinato parametro: +%s
L'opzione  --date ( nella versione abbreviata -d ) serve per fornire una date/orario differente da quelli di sistema per la visualizzazione, quindi provando ad eseguire il comando:
date --date="2012-04-10 00:13:00" +%s
in qualunque ora lo eseguiate otterrete 1334009580.
Cercando di calcolare quanti secondi sono passati dall'impatto del Titanic con l'iceberg al 01/01/1970:
date --date="1912-04-14 23:50" +%s
a questo punto si ottiene un numero negativo essendo antecedente il 1970, sottraendo i secondi del Titanic a quelli attuali si ottengono i secondi passati dall'impatto del Titanic:

echo $(($(date --date="2012-04-10 00:13:00" +%s) - $(date --date="1912-04-14 23:50" +%s)))

I vecchi comandi date presenti nelle vecchie versioni di Unix servivano solamente per consultare ed impostare la data di sistema e quindi i progettisti avevano dato per scontato che non ci sarebbe stata la necessità di inserire date precedenti il 1970. In seguito l'implementazione Gnu ha esteso il comando date anche a funzioni di visualizzazione di date e orari arbitrari e quindi anche date antecedenti il 1970.

L'opzione --date ci permette anche di indicare date indietro o in avanti rispetto al momento attuale esprimendo ad esempio:
domani: "tomorrow"
ieri: "yesterday"
la prossima Domenica: "next Sunday"
le 18:30 della Domenica precedente "last Sunday 18:30"
il mese scorso: "last month"
la settimana scorsa: "last week"
fra 3 domeniche: "3 sunday"
fra 4 settimane: "4 weeks"
3 settimane fa: "3 weeks ago"
domani più una settimana: "tomorrow + week"
ieri più due mesi: "yesterday + 2 month"
fra 5 giorni e 2 ore: "5 days + 2 hours"