Uploaded with ImageShack.us
Con il nuovo pacchetto binario Nvidia (beta), oltre alla correzione di bug e nuove caratteristiche, è stato integrato il meccanismo dkms, che in caso di installazione di un nuovo kernel, ricompila automaticamente il modulo.
Tutti i dettagli:
www.nvidia.com/object/linux-display-amd64-304.22-driver.html
Ovviamente in caso di aggiornamento di xerver-core e mesa, è sempre necessario reinstallare il driver per la sovrascrittura dei link delle LibGL.
Lo sviluppatore dei driver proprietari nvidia dice:
Unfortunately, there was a change to a data structure without a corresponding change to the extension module ABI version that breaks GLX. It’s not exactly clear whether this structure counts as part of the extension ABI, so I need to get to the bottom of that before a driver with official xserver 1.11 support can be released. It may be that we need to skip xserver 1.11.0 if my hunch is correct and this is a bug in the X server.
Ergo meglio NON aggiornare xserver-xorg-core e compagnia bella, e restare alla versione 1.10.4-1, in attesa di soluzioni, tanto non cambia una emerita cippa, come per ogni aggiornamento di xorg da molte versioni a questa parte.
PS:
occhio anche su Archlinux.
Almeno secondo il sempre dettagliato articolo di Phoronix:
Linux 3.1 Kernel Draws More Power With Another Regression
Io non ho portatili e me la rido.
E voi?
Con mutter, le prestazioni migliori dei driver Nvidia, si ottengono con queste impostazioni:
Uploaded with ImageShack.us
Lo spostamento delle finestre diventa molto fluido, e niente corruzioni nelle immagini catturate.
Per caricare le impostazioni all’avvio con
gnome-session-properties
aggiungete una voce con
nvidia-settings --load-config-only
come comando.
Rispondo alle accuse di presunto terrorismo mediatico contro ext4, e sulla presunta inesistenza dei problemi di ext4,
riproponendo come articolo, un mio commento in EXT4 continua il calvario, perchè abbia la giusta visibilità.
Perchè fare una patch, inclusa nel kernel 2.6.32 che recita testualmente:
“ext4: fix cache flush in ext4_sync_file
We need to flush the write cache unconditionally in ->fsync, otherwise
writes into already allocated blocks can get lost. Writes into fully
allocated files are very common when using disk images for
virtualization, and without this fix can easily lose data after
an fdatasync, which is the typical implementation for a cache flush on
the virtual drive.”
fonte: git kernel org
e che chiaramente dice che
“otherwise writes into already allocated blocks can get lost”
“without this fix can easily lose data after an fdatasync”
se NON ESISTE ALCUN PROBLEMA DI PERDITA DATI?
Altro tipico esempio di “already allocated blocks” sono oltre ai dischi virtuali, tutti i file scaricati da programmi p2p dove viene allocata l’intera dimensione e poi riempita man mano che i dati vengono ricevuti.
(cit.) Quindi mi chiedo, perché continuare a fare terrorismo mediatico contro ext4 se non si sa nulla di concreto?
Io non faccio alcun terrorismo, cito le fonti dirette e CONCRETE a differenza di chi sostiene tesi contrarie senza citare NULLA di autorevole a supporto.
Ora la situazione attuale di EXT4 è questa:
senza patch veloce ma possibili perdite di dati in scrittura su blocchi già allocati,
con la patch niente perdite dati ma forte decadimento delle prestazioni ben evidenziato dai test phoronix.
(cit) http://tinyurl.com/ydzqggo
The performance of PostgreSQL in Lucid is absolutely slaughtered when compared to Ubuntu 9.10. In Ubuntu 9.10 it averaged 1910 transactions per second, but with Ubuntu 10.04 LTS right now it is at 114 TPS. However, it is to no surprise and will likely not change. Thanks to our ability to autonomously find performance regressions in the Linux kernel (and you can too with the Phoronix Test Suite), in that same article we pointed out the change that is causing EXT4 in PostgreSQL and some other applications to be much slower in Linux 2.6.32 kernel compared to earlier releases bearing this popular Linux file-system. It was a very simple commit approved by Red Hat that improves the reliability of EXT4 with its default options, but it comes at a severe performance cost for many operations due to flushing the write cache unconditionally in fsync calls.
Qui i nuovi test dei vari filesystem con EXT4 azzoppato dal kernel 2.6.32 che va “peggio” di ext3 (segnalati da sober).
Tutto ciò è figlio del peccato originale di Ext4 con la conseguente diatriba tra lo sviluppatore e gli altri che sviluppano applicazioni, su come vadano scritti correttamente i dati su disco dalle applicazioni (riassunta per brevità qui se vi interessa).
Su chi ha ragione in questa diatriba tra sviluppatori non mi pronuncio, ma chiaramente il “sonno della ragione genera mostri”.
In conclusione, fede equivale a “credere” incondizionatamente, ma io sono agnostico e credo solo nella scienza che è fatta di teorie e dimostrazioni ripetibili, e sono stufo di leggere affermazioni o accuse bastate sul nulla cosmico eccepite alle mie considerazioni, basate invece, perlomeno nel caso specifico, su cose ben documentate e riportate in originale.
Non c’è pace per il nuovo filesystem.
Dopo i vari problemi di possibile perdita di dati, forse risolti, forse no, il tutto è molto ambiguo, con il nuovo kernel 2.6.32 le prestazioni, unico motivo per preferirlo al lento ext3, sono crollate.
L’entità della regressione è preoccupante, qui gli articoli di Phoronix:
http://www.phoronix.com/scan.php?page=article&item=linux_perf_regressions&num=1
http://www.phoronix.com/scan.php?page=article&item=linux_2632_benchmarks&num=1
http://www.phoronix.com/scan.php?page=article&item=ubuntu_1004_alpha1&num=1
Questo il commit che genera la regressione, come dire rendiamo sicuri i dati, sopratutto nei dischi virtuali (ancora un altro problema?) ma al costo di un fortissimo rallentamento in scrittura.
Uhm, a questo punto tanto vale tornare al vecchio ext3 allora, almeno sicuramente è “sicuro” …
Che dire, se usate ext4 state lontani da questo kernel, a meno che non risolva gravi problemi con il vostro hardware.
Ext4 sembra nato sotto una cattiva stella.
Peccato perchè sicurezza dei dati e prestazioni, sono fortemente dipendenti dal filesystem usato.
Ora abbiamo:
ext3 sicuro ma lento, ext4 con kernel < 2.6.32 veloce ma potenzialmente insicuro, ext4 con kernel 2.6.32 sicuro (forse) ma lento come o più di ext3 …
Le conclusioni le lascio a voi,
io sto col 2.6.31 ed ext4 accollandomi il "rischio".
Non c’è pace tra gli ulivi
Rilevata con
sudo hdparm -Tt /dev/sdX
HD Sata2 7200 rpm 1TB
/dev/sdc:
Timing cached reads: 2670 MB in 2.00 seconds = 1335.00 MB/sec
Timing buffered disk reads: 380 MB in 3.00 seconds = 126.47 MB/sec
HD Sata2 7200 rpm 500GB
/dev/sdb:
Timing cached reads: 2734 MB in 2.00 seconds = 1367.17 MB/sec
Timing buffered disk reads: 320 MB in 3.00 seconds = 106.55 MB/sec
HD Ata133 su interfaccia Ata100 (quella c’è) 7200 rpm 300GB
/dev/sda:
Timing cached reads: 2712 MB in 2.00 seconds = 1356.30 MB/sec
Timing buffered disk reads: 184 MB in 3.02 seconds = 60.97 MB/sec
HD Ata133 su box USB 7200 rpm 160GB
/dev/sdd:
Timing cached reads: 2642 MB in 2.00 seconds = 1320.80 MB/sec
Timing buffered disk reads: 82 MB in 3.04 seconds = 26.96 MB/sec
PEN DRIVE economico USB 2GB
/dev/sde:
Timing cached reads: 2504 MB in 2.00 seconds = 1251.87 MB/sec
Timing buffered disk reads: 30 MB in 3.07 seconds = 9.78 MB/sec
Tirate voi le conclusioni.
Una caratteristica avanzata di kaffeine. è di poter registrare più stream A/V dallo stesso “mux”.
Nell’esempio attivata la registrazione istantanea su Rai2, nella lista canali rimangono visibili gli altri canali dello stesso mux.
(continua…)
Per abilitare il supporto completo, cioè video out e decoder accelerati VDPAU, in mplayer con interfaccia smplayer, è necessario qualche accorgimento.
 | telperion su x264 OpenCL lookahead, test… |
| x264 OpenCL lookahea… su x264 OpenCL lookahead, te… | |
 | Luigi su VP9 è “quasi”… |
| telperion su VP9 è “quasi”… |
| FFmpeg, OpenCL sui f… su x264 OpenCL lookahead, te… |
Tema: Rubric. Blog su WordPress.com.
