Con la migliore canzone di natale di sempre.
Il video di supporto (divertente) è di Picciuz
Con la migliore canzone di natale di sempre.
Il video di supporto (divertente) è di Picciuz
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
Nel precedente articolo vi ho parlato molto bene, di DockbarX applet per gnome.
Ecco un piccolo video che illustra i vantaggi essenziali (niente effetti speciali solo sostanza)
Consiglio di vederlo in HD e a pieno schermo.
Questo piccolo software, rivoluziona un bel po il modo di usare Gnome, aumentando parecchio la velocità di azione.
Altro che interfacce da fantascienza, son le piccole cose che spesso rivitalizzano BENE, un progetto un po stantio.
In quest’altro video non mio, sempre da vedere in HD a pieno schermo, una panoramica più completa delle varie caratteristiche.
Dettaglio gestione delle finestre abbinato alla funzione preview di compiz
Leggendo questo articolo e quest’altro
ho scoperto DockbarX un interessante applet che sostituisce il classico “elenco finestre” di gnome, ottimizzando lo spazio e fornendo anche un lanciatore di applicazioni, ispirandosi alla dockbar di windows 7.
Beh il lavoro è stato fatto molto bene questa volta, con un semplice applet in python.
Tutte le info necessarie per installazione e uso le trovate nei collegamenti citati.
Le considerazioni che faccio io sono solo di ergonomia.
DockbarX come sostituto di “elenco finestre” è ottimo, si passa dalla caotica visualizzazione dell’applet standard quando ci sono molti programmi e finestre aperte, ad una molto più compatta ed ordinata vista della medesime.
Aggiungendo i lanciatori delle applicazioni più usate permette di eliminare tutti i lanciatori aggiunti ai pannelli, e sostituisce le varie dock in maniera semplice ed efficiente.
L’applet è “temabile” e i temi influiscono moltissimo sull’ergonomia di DockbarX oltre che sull’aspetto.
Nell’immagine un test di 3 temi, usati con lanciatori.
1 - è il tema default, buono, si distinguono chiaramente istanze multiple e finestre attive, un pò meno le finestre aperte dai lanciatori
2 - è il tema NEW anch’esso fornito, più simile a W7, però manca la visualizzazione immediata delle istanze multiple, per questo sconsigliato.
3 - è il tema Glassified scaricato da gnome-look (vedi i link sopra), che ho scelto perchè mi permette al volo di capire i programmi lanciati, le istanze multiple e la finestra attiva. Dopo un piccolo periodo di abitudine, l’ergonomia e l’efficienza dell’applet sono molto alte.
Nella parte inferiore dell’immagine vedete l’elenco delle istanze multiple (gimp nell’esempio) cliccandone una avrete la finestra attiva. Molto più pratico che cercare tra le 30 finestre aperte di “gestione finestre” ridotte al minino e che hanno tutte lo stesso nome iniziale.
Anche il tema silver_tonky è molto buono come informazioni, usando però più spazio:
Insomma a voi la scelta del tema più bilanciato per le vostre esigenze.
Molto utile anche la possibilità (tasto destro su un’icona di dockbarx) di controllare tutte le finestre aperte dell’applicazione con un singolo click (nell’esempio sulle finestre di firefox):
Consigliatissimo per ridurre notevolmente il “caos” di lanciatori e “elenco finestre” dei pannelli di gnome con gli applet di default.
Prestate attenzione al tema da usare, scegliete quello che comunica meglio le informazioni con il vostro tema gtk, e sarete sicuramente soddisfatti da questo buon software.
Ottimo anche come semplice sostituto di “elenco finestre”.
Confronto spazio occupato e chiarezza informazioni visive tra dockbarx con tema silver_tonky uno dei meno compatti e elenco finestre standard con opzione finestre raggruppate:
Le solite preoccupazioni sulla manutenzione nel tempo di DockbarX, e quale futuro avrà se sarà gnome-shell l’interfaccia dei futuri gnome, ma forse in quel caso meglio chiedersi che futuro avrà gnome.
Come sapete dalla versione 0.9.4 di handbrake, il contenitore avi è stato giustamente eliminato, in quanto obsoleto, visto che non supporta sottitoli, capitoli, aspect ratio ed ha altri svantaggi, e sono stati preferiti i più moderni mkv e mp4 mpv.
L’unica ragione di esistere del contenitore avi è la compatibilità con i lettori DVD da tavolo che supportano anche i file MPEG-4 comunemente chiamati divx, dal primo codec usato per produrli.
Quindi ora niente più file avi con handbrake?
No esiste un semplice metodo per continuare ad usare il nostro tool di encoding preferito.
Vediamo come.
Carichiamo come di consueto il nostro filmato da convertire.
Dal tasto picture settings e preview video accediamo alla schermata.
Togliamo la spunta in Auto crop e regoliamo il taglio a mano aiutandoci con l’immagine di preview.
Togliamo la spunta da Optimal for source e impostiamo Anamorphic OFF e Aligment 16, questo perche AVI non gestisce gli anamorfici e le dimensioni devono essere multipli di 16.
Ora regolate la larghezza del video Widht a un valore tra 500 e 600 (il massimo per i lettori è 720 ma è bene con MPEG-4 ASP (divx xvid ffmpeg) non superare i 600 pixel, height si adatterà di conseguenza.
Mantenete spuntato Keep Aspect che fornirà automaticamente l’immagine alle giuste proporzioni.
Se il vostro video è interlacciato, è bene nel tab Filters attivare Decomb – Default, che ha prezzo di un maggior tempo di codifica, vi deinterlaccerà in modo ottimale il filmato.
Passate ora alla scheda Video.
Impostate Video Codec MPEG-4 (FFmpeg), 2-Pass , Turbo first, e impostate il target size desiderato.
Nel caso vogliate riempire un cd da 700MB consiglio di inserire 650 visto che Handbrake tende a creare file più grandi di quanto impostato.
Passate alla scheda Audio.
Prima di tutto impostate MKV come Format, altrimenti non potrete selezionare il compressore MP3, poi selezionate MP3 come Codec e il bitrate (96-112-128) e il Sample Rate 48.
A questo punto potete fare un preview di codifica dalla finestra picture settings e preview video se volete, poi procedete alla codifica del nostro video mkv.
Terminata la codifica avremmo il nosto bel video mkv pronto, ehi ma a noi serve un avi …
Nessun problema, i flussi audio e video contenuti nella “scatola” mkv, sono perfettamente compatibili con lettore da tavolo, quindi basta semplicemente cambiare … scatola, cioè container.
Per fare questo usiamo Avidemux, apriamo il nostro file mkv
Vedete nell’immagine dalla scheda proprietà che il nosto file è perfettamente a norma coi lettori da tavolo, dimensione inferiore a 720, proporzioni 1:1, niente GMC, QP e flussi compressi, audio MP3 CBR.
Sarà quindi sufficiente selezionare COPIA nelle opzioni video e audio e AVI come formato, e salvare il nostro file come nome.avi, ed ecco in 1 minuto circa il nostro avi bello e pronto.
Ovviamente la procedura è indicata solo per permettere la visione con lettori da tavolo, in tutti gli altri casi il formato MKV con risoluzioni maggiori e video anamorfico, e il codec H.264 è consigliato vista la qualità nettamente superiore.
Consigliato l’uso di un hard-disk multimediale che supporti mkv e HD e collegamento HDMI, con televisori LCD o plasma da 32″ o più.
Nota: non ho scritto HandBrake giusto manco una volta … corretti.
LOL
Una volta ho visto un servizio televisivo sul microcredito alle donne in India, dove con un prestito di 30$ (di trenta dollari poco più di 20 euro) poi regolarmente restituito, una donna aveva comperato un carretto a pedali con il quale poteva comprare frutta ai mercati generali e rivenderla in zone lontane della città.
Con questa semplice attività la condizione della sua famiglia è passata dall’indigenza totale ad un condizione dignitosa, e poteva “persino” permettersi di comprare i farmici per il vecchio padre malato.
La cosa mi commosse parecchio.
Oggi ho visto un altro servizio sul microcredito alle donne in Afganistan, dove con 100$ restituibili in un anno, molte donne passano dalla schiavitù letterale ad una piccola attività che garantisce reddito a tutta la famiglia.
Vi segnalo l’ONLUS che permette queste cose
www.pangeaonlus.org
Leggete le storie, guardate i video se volete, e magari invece di fare un regalo inutile, regalate un biglietto ai vostri cari con scritto:
“Ho regalato per tuo conto, una vita dignitosa ad una donna e alla sua famiglia”
Perchè i beni materiali sono effimeri, certe cose invece non hanno davvero prezzo.
PS
Chiacchiere e distintivo, siamo noi, che a parole …
Finalmente disponibile un player flash che supporta (al momento solo per windows) l’accelerazione hw delle schede video per la decompressione dei flussi h264 (HD).
Ora i filmati HD si vedono full screen senza quadrettature e artefatti e facendo apparire la barra di navigazione, non ci sono più i rallentamenti delle versioni precedenti. Il carico cpu è alto (video HD 20-30% su 2 core con driver nvidia 195.55 che supportano flash) ma inferiore a prima. Ora l’unico limite è la banda di streaming.
Dalla documentazione:
H.264 Video Hardware Acceleration Support
Flash Player 10.1 supports hardware decoding of H.264 video on Windows platforms when running with supported hardware. Use the following recommended hardware and driver combinations to experience hardware acceleration of H.264 videos in Flash Player 10.1. Unless otherwise noted, the following hardware will support H.264 hardware decoding with supported drivers under Windows XP 32-bit, Windows Vista (32/64-bit), and Windows 7 (32/64-bit).(segue la lista delle schede video supportate)
Lo trovate qui
labs.adobe.com/downloads/flashplayer10.html
Per ora provato con windows ed è ok.
Video di riferimento
Per linux e osx:
In Flash Player 10.1, H.264 hardware acceleration is not supported under Linux and Mac OS. Linux currently lacks a developed standard API that supports H.264 hardware video decoding, and Mac OS X does not expose access to the required APIs. We will continue to evaluate adding the feature to Linux and Mac OS in future releases.
Tirate fuori i fazzoletti, in ricordo di uno dei software più clamorosi mai creati.
Il “mitico” Deluxe Paint su Amiga e le sue versioni successive con animazioni.
Quanto l’ho usato.
Standing ovation per un grandissimo programma.
Mentre si festeggiano i vent’anni dall’abbattimento del muro di Berlino, e in ambito linux, escluse le solite polemiche a vs b, non succede nulla di nulla, ritorno con la memoria alla prima metà degli anni 80.
A quei tempi si che si facevano passi da gigante.
Altro che le versioni 0.00-001+001~alpha001-pre+001~001 …