In protest against Google censorship of Blogger blogs in some countries, this post has been moved to Wordpress.
Questo post è stato spostato su Wordpress in protesta contro la censura applicata da Google su richiesta dei governi di alcuni paesi.
sabato 28 maggio 2011
Can't bear with Gnome 3
I finally installed Fedora 15, as anticipated.
And with Fedora 15 comes Gnome 3. I tried using it. But my patience was quite short: they changed a lot of interaction in subtle ways, so the gap with the previous version is not only based on the new graphical aspect, but also on different behavior.
Gnome 3 managed to get me on KDE 4. Problem is: while Gnome 3 is blazing fast, KDE 4 is slow. In the past I tried it on my netbook and I tought it was slow due to hardware shortcomings, but now I'm using it on my 3-core Phenom 2.3GHz with 8Gb RAM and Radeon HD4890 video card (open source drivers).
It's... slow. Painfully slow. Switching desktop it's so slow I checked if it was doing that in software, but desktop effects are active.
But despite Gnome 3 technical superiority, all the glitches at the moment are more important to me than the speed. Maybe I'll try something more exotic, like Openbox + AWN (like AriOS), but for the moment I'll stick with KDE.
I'll give Gnome another chance in a few months...
And with Fedora 15 comes Gnome 3. I tried using it. But my patience was quite short: they changed a lot of interaction in subtle ways, so the gap with the previous version is not only based on the new graphical aspect, but also on different behavior.
Gnome 3 managed to get me on KDE 4. Problem is: while Gnome 3 is blazing fast, KDE 4 is slow. In the past I tried it on my netbook and I tought it was slow due to hardware shortcomings, but now I'm using it on my 3-core Phenom 2.3GHz with 8Gb RAM and Radeon HD4890 video card (open source drivers).
It's... slow. Painfully slow. Switching desktop it's so slow I checked if it was doing that in software, but desktop effects are active.
But despite Gnome 3 technical superiority, all the glitches at the moment are more important to me than the speed. Maybe I'll try something more exotic, like Openbox + AWN (like AriOS), but for the moment I'll stick with KDE.
I'll give Gnome another chance in a few months...
giovedì 26 maggio 2011
Prendere solo un numero da una riga
L'altra sera il mio capo mi ha chiesto un pizzico di kung-fu per estrarre solo il numero da un output di questo genere:
Inizialmente, ho suggerito di usare awk:
Il problema è che le label potevano contenere spazi (seconda riga). Usare cut era fuori discussione, perché forniva anche gli spazi come output.
Allora ho girato la questione: ci interessano solo i numeri, leviamo tutto il resto!
La regular expression dice: tutto ciò che non è un numero o un punto, cancellalo.
Elegante ed efficace.
label: 18.1 Mb second label: 100.00 %
Inizialmente, ho suggerito di usare awk:
$ cat file | awk {'print $2'}
18.1
label:
Il problema è che le label potevano contenere spazi (seconda riga). Usare cut era fuori discussione, perché forniva anche gli spazi come output.
Allora ho girato la questione: ci interessano solo i numeri, leviamo tutto il resto!
$ cat file | sed -e 's#[^0-9.]##g' 18.1 100.00
La regular expression dice: tutto ciò che non è un numero o un punto, cancellalo.
Elegante ed efficace.
Vedere il contenuto di una directory senza ls
Qualche tempo fa, su IRC, uno se ne uscì con qualcosa tipo: "sono su un sistema dd-wrt e chi lo ha personalizzato ha esagerato un po', non c'è nemmeno ls!"
Non so chi sia l'autore del delirio paranoide: sul sistema non c'erano né ls, né find, ma in realtà per elencare il contenuto di una directory basta usare la shell!
Non è certo il massimo dell'usabilità, ma funziona!
Non so chi sia l'autore del delirio paranoide: sul sistema non c'erano né ls, né find, ma in realtà per elencare il contenuto di una directory basta usare la shell!
# echo * app_plugins code licenses README.txt sketch_sheets templates
Non è certo il massimo dell'usabilità, ma funziona!
martedì 24 maggio 2011
Repository aggiuntivi per CentOS e Scientific Linux
Dato che se non me li segno in un posto fisso, poi me li perdo, mi segno qui i repo aggiuntivi più importanti per CentOS e Scientific Linux:
- RPM Fusion: pacchetti generici, più che altro orientati al desktop (es. codec, mplayer, vlc)
- EPEL: pacchetti enterprise (es. bacula)
- ELRepo: kernel e moduli (compreso il mainline stabile)
E se il problema non fosse solo dalla parte di chi produce informazione?
Negli ultimi giorni, un paio di progetti hanno attirato la mia attenzione.
Il primo è della Mozilla Foundation e riguarda alcune cose su cui sto riflettendo da un po' (mesi), si tratta del progetto Drumbeat, nato per migliorare la creazione e la fruizione delle notizie, in collaborazione con importanti testate (The Guardian, BBC, Al Jazeera).
Il secondo è, invece, del creatore del sito icanhazcheezburger.com, famoso per le serie di LOLcats. Il progetto si chiama Moby Dick e si pone come obiettivo quello di stimolare la discussione su come vengono prodotte e mostrate le news. Ci sono degli schizzi interessanti di un'idea di layout.
A questo punto, però, mi domando: non è che per caso il problema non sia solo dal lato dei produttori di notizie, ma anche da quello dei consumatori?
Ritengo fondamentale, oggi più che mai, la nozione dell'impossibilità di fidarsi al 100% di qualsiasi fonte. Eppure, in un'epoca di virtuale sempre più imperante, è facilissimo vedere che le notizie vengono lette, credute e sbandierate senza neanche una basilare verifica dei fatti. Questo è pericolosissimo per chiunque, basta pensare a come possono reagire le folle (e i mercati) a voci incontrollate diffuse dai grandi media (che sempre più spesso le riprendono, da Internet, senza alcuna verifica).
Forse è importante, prima di modificare l'architettura dell'informazione, creare dei fruitori di informazione consapevoli dei limiti e dei pericoli dell'informazione creata da sconosciuti su Internet.
Questo strumento ha enormi potenzialità, ma come tutti gli strumenti potenti, necessita di una grande consapevolezza per essere usato a dovere.
Il primo è della Mozilla Foundation e riguarda alcune cose su cui sto riflettendo da un po' (mesi), si tratta del progetto Drumbeat, nato per migliorare la creazione e la fruizione delle notizie, in collaborazione con importanti testate (The Guardian, BBC, Al Jazeera).
Il secondo è, invece, del creatore del sito icanhazcheezburger.com, famoso per le serie di LOLcats. Il progetto si chiama Moby Dick e si pone come obiettivo quello di stimolare la discussione su come vengono prodotte e mostrate le news. Ci sono degli schizzi interessanti di un'idea di layout.
A questo punto, però, mi domando: non è che per caso il problema non sia solo dal lato dei produttori di notizie, ma anche da quello dei consumatori?
Ritengo fondamentale, oggi più che mai, la nozione dell'impossibilità di fidarsi al 100% di qualsiasi fonte. Eppure, in un'epoca di virtuale sempre più imperante, è facilissimo vedere che le notizie vengono lette, credute e sbandierate senza neanche una basilare verifica dei fatti. Questo è pericolosissimo per chiunque, basta pensare a come possono reagire le folle (e i mercati) a voci incontrollate diffuse dai grandi media (che sempre più spesso le riprendono, da Internet, senza alcuna verifica).
Forse è importante, prima di modificare l'architettura dell'informazione, creare dei fruitori di informazione consapevoli dei limiti e dei pericoli dell'informazione creata da sconosciuti su Internet.
Questo strumento ha enormi potenzialità, ma come tutti gli strumenti potenti, necessita di una grande consapevolezza per essere usato a dovere.
domenica 22 maggio 2011
Togliere la barra degli indirizzi dal browser è una mossa saggia?
Ars Technica dice che in Chrome 13 è disponibile un'opzione per nascondere la barra degli indirizzi e che è uscita un'estensione per Firefox per fare la stessa cosa.
A me sembra stupido e pericoloso: la barra degli indirizzi è fondamentale per controllare su che sito siamo effettivamente, magari verificando lo stato della connessione https. Toglierla significa non disporre a colpo d'occhio di notizie importanti per la sicurezza della navigazione, non mi sembra affatto una buona idea.
A me sembra stupido e pericoloso: la barra degli indirizzi è fondamentale per controllare su che sito siamo effettivamente, magari verificando lo stato della connessione https. Toglierla significa non disporre a colpo d'occhio di notizie importanti per la sicurezza della navigazione, non mi sembra affatto una buona idea.
mercoledì 18 maggio 2011
Certificazione Red Hat, qualche nota sul quota
Sto studiando per la RHCSA/RHCE, dato che il quota è uno dei temi che meno conosco, approfitto per segnarmi qualche appunto qua.
Gli esperimenti li ho fatti su Scientific Linux 6. Di default quota è già installato, per controllare basta un:
Il kernel dispone già del supporto, quindi non ci sarà da fare nulla di particolare.
Per usare il quota, è necessario abilitarlo mountando la partizione con le opzioni relative: usrquota per il supporto a livello di utente e grpquota per quello dei gruppi. E' anche necessario richiamare il comando quotaon per attivare le impostazioni, ma lo vedremo più avanti.
Ipotizziamo di avere una partizione /dev/vdb1 formattata in ext4, mountiamola in /mnt/testquota, attiviamo il quota ed inizializziamo il db
Le opzioni che abbiamo usato per quotacheck sono:
Per quanto riguarda quotaon, se salviamo la riga di mount nell'fstab, verrà richiamato automaticamente all'avvio. A proposito di fstab, la riga di configurazione per mountare automaticamente la nostra partizione di prova sarebbe:
Torniamo a noi. Abbiamo lanciato quotacheck per creare il db e ci ritroveremo con due file nella nuova partizione:
Questi sono i database che contengono le impostazioni per i gruppi e gli utenti. Non vanno editati direttamente, ma invocando edquota:
Come vedete, è possibile modificare sia il numero di blocchi (di 1024byte) che il numero di inode (cioè di file e directory che è possibile creare).
Abbiamo impostato un "soft" quota di circa 50Mb ed un hard quota di 60. Il "soft" può essere superato per brevi periodi di tempo, detto grace time, mentre l'"hard" quota è un limite invalicabile. Facciamo una semplice prova:
Cos'è successo? Abbiamo provato a scrivere 5 file di 20Mb l'uno, ma la scrittura si è interrotta durante il terzo file e gli ultimi due sono vuoti, come ci conferma un ls:
Il totale è praticamente il nostro hard limit:
Se controlliamo le statistiche, vedremo che ci confermano che abbiamo sforato il "soft" limit e siamo stati bloccati dall'"hard":
Nel report vediamo anche che abbiamo 6 giorni di "grace" prima che i file/blocchi over quota vengano cancellati.
Per modificare il grace period si usa edquota con l'opzione -t:
Il default può andar bene, ma possiamo allungarlo se sappiamo che i nostri utenti si connettono raramente, oppure ridurlo se sappiamo che si connettono spesso (e che tendono a sforare spesso il quota!).
Gli esperimenti li ho fatti su Scientific Linux 6. Di default quota è già installato, per controllare basta un:
# rpm -qa | grep quota quota-3.17-10.el6.x86_64
Il kernel dispone già del supporto, quindi non ci sarà da fare nulla di particolare.
Per usare il quota, è necessario abilitarlo mountando la partizione con le opzioni relative: usrquota per il supporto a livello di utente e grpquota per quello dei gruppi. E' anche necessario richiamare il comando quotaon per attivare le impostazioni, ma lo vedremo più avanti.
Ipotizziamo di avere una partizione /dev/vdb1 formattata in ext4, mountiamola in /mnt/testquota, attiviamo il quota ed inizializziamo il db
# mount -t ext4 /dev/vdb1 /mnt/testquota -ousrquota,grpquota # quotaon /mnt/testquota # quotacheck -bvug /mnt/testquota
Le opzioni che abbiamo usato per quotacheck sono:
- -b: fai un backup del quotafile, prima di scrivere quello nuovo
- -v: verbose
- -u: abilita il quota per gli utenti
- -g: abilita il quota per i gruppi
Per quanto riguarda quotaon, se salviamo la riga di mount nell'fstab, verrà richiamato automaticamente all'avvio. A proposito di fstab, la riga di configurazione per mountare automaticamente la nostra partizione di prova sarebbe:
# partizione mountpoint fs opzioni dump/prio /dev/vdb1 /mnt/testquota ext4 defaults,usrquota,grpquota 1 2
Torniamo a noi. Abbiamo lanciato quotacheck per creare il db e ci ritroveremo con due file nella nuova partizione:
# ls -lh /mnt/testquota/ totale 40K -rw-------. 1 root root 6,0K 13 mag 05:20 aquota.group -rw-------. 1 root root 7,0K 13 mag 05:23 aquota.user [...]
Questi sono i database che contengono le impostazioni per i gruppi e gli utenti. Non vanno editati direttamente, ma invocando edquota:
# edquota velenux [si apre vi per modificare il file] Disk quotas for user velenux (uid 500): Filesystem blocks soft hard inodes soft hard /dev/vdb1 0 50000 60000 0 20 50
Come vedete, è possibile modificare sia il numero di blocchi (di 1024byte) che il numero di inode (cioè di file e directory che è possibile creare).
Abbiamo impostato un "soft" quota di circa 50Mb ed un hard quota di 60. Il "soft" può essere superato per brevi periodi di tempo, detto grace time, mentre l'"hard" quota è un limite invalicabile. Facciamo una semplice prova:
# mkdir /mnt/testquota/velenux
# chown velenux:users -R /mnt/testquota/velenux
# su - velenux
$ cd /mnt/testquota/velenux
$ for num in $(seq 5); do dd if=/dev/urandom of=prova${num} bs=10M count=2; sync; done
2+0 records in
2+0 records out
20971520 bytes (21 MB) copied, 2,88992 s, 7,3 MB/s
2+0 records in
2+0 records out
20971520 bytes (21 MB) copied, 2,88969 s, 7,3 MB/s
dd: scrittura di `prova3': Superata la quota di disco
2+0 records in
1+0 records out
19496960 bytes (19 MB) copied, 2,85899 s, 6,8 MB/s
dd: scrittura di `prova4': Superata la quota di disco
1+0 records in
0+0 records out
0 bytes (0 B) copied, 1,43602 s, 0,0 kB/s
dd: scrittura di `prova5': Superata la quota di disco
1+0 records in
0+0 records out
0 bytes (0 B) copied, 1,42407 s, 0,0 kB/s
Cos'è successo? Abbiamo provato a scrivere 5 file di 20Mb l'uno, ma la scrittura si è interrotta durante il terzo file e gli ultimi due sono vuoti, come ci conferma un ls:
$ ls -lb totale 60000 -rw-rw-r--. 1 velenux velenux 20971520 18 mag 03:08 prova1 -rw-rw-r--. 1 velenux velenux 20971520 18 mag 03:08 prova2 -rw-rw-r--. 1 velenux velenux 19496960 18 mag 03:08 prova3 -rw-rw-r--. 1 velenux velenux 0 18 mag 03:08 prova4 -rw-rw-r--. 1 velenux velenux 0 18 mag 03:08 prova5
Il totale è praticamente il nostro hard limit:
$ du -sb 61444096 . $ echo 61444096/1024 | bc 60004
Se controlliamo le statistiche, vedremo che ci confermano che abbiamo sforato il "soft" limit e siamo stati bloccati dall'"hard":
# repquota -uv /mnt/testquota/
*** Report for user quotas on device /dev/vdb1
Block grace time: 7days; Inode grace time: 7days
Block limits File limits
User used soft hard grace used soft hard grace
----------------------------------------------------------------------
root -- 20 0 0 2 0 0
velenux +- 60000 50000 60000 6days 5 20 50
Statistics:
Total blocks: 7
Data blocks: 1
Entries: 2
Used average: 2,000000
Nel report vediamo anche che abbiamo 6 giorni di "grace" prima che i file/blocchi over quota vengano cancellati.
Per modificare il grace period si usa edquota con l'opzione -t:
# edquota -t [viene avviato vim] Grace period before enforcing soft limits for users: Time units may be: days, hours, minutes, or seconds Filesystem Block grace period Inode grace period /dev/vdb1 7days 7days
Il default può andar bene, ma possiamo allungarlo se sappiamo che i nostri utenti si connettono raramente, oppure ridurlo se sappiamo che si connettono spesso (e che tendono a sforare spesso il quota!).
Iscriviti a:
Post (Atom)