Ancora per un paio di giorni sarò lontano da casa, a pomiciare su qualche spiaggia (ah, ah come direbbe Nelson[1]) di una certa isola italiana.
In compenso, consolatevi pensando che prima di partire di casa ho perso tre quarti d'ora (con possibile conseguenze nefaste sull'intera partenza) perché volevo a tutti i costi mettere nel lettore musicale portatile la canzone Fever dei Faith No More che, misteriosamente, non era nella mia libreria... «Non è possibile, l'ho ascoltata l'altro giorno!! Non è possibile, né Tracker, né Rhythmbox, né find riescano a trovarla!!!»
Poi mi sono illuminato. Cercavo Easy.
Non c'è search engine che tenga il passo con tuo cervello. Specie se è spento.
Ah, già che c'ero ho aggiunto anche Digging the Grave, sai mai che una volta nella vita riesco a replicare la scena di Jack Frusciante è uscito dal gruppo, senza augurare la morte a nessuno...
[1] a proposito: sul sito ufficiale di Simpson The Movie è possibile creare un proprio avatar come se fosse stati disegnati da Matt Groenig...
17 luglio 2007
12 luglio 2007
One more thing
Apple acquista CUPS....
....speriamo almeno che aggiornino la pessima grafica dell'interfaccia web e del logo...
....speriamo almeno che aggiornino la pessima grafica dell'interfaccia web e del logo...
felipe è un megalomane
... e anche un po' egocentrico.
La risposta corretta era: ma guarda un po' quante belle icone nuove in stile Tango e con la giusta metafora.
Notare infatti, da destra verso sinistra:
PetrusinPerusin, Josef Vybiral e altri.
Update scusa Ulisse, andavo a memoria e mi sono detto «no, no, è Petrusin, non ho dubbi!» nota per il lettore: «non ho dubbi!» è da leggersi - ad alta voce o mentalmente - come nel famoso discorso di fine anno dell'ex Presidente della Repubblica Scalfaro, grazie.
Una visione d'insieme la trovate su http://git.jimmac.net dove sono mostrate tutte le icone in gnome-icon-theme, così come al momento presenti su svn, definite nelle Icon Naming Spec.
Oh, ovviamente sono disponibili anche le versioni "larghe"
Quello che ora manca è solo risolvere il bug 455937 per evitare in giro che si dica che GNOME non è attento ai problemi ambientali...
[1] giovani in ratzinghiano
[2] per dovere di cronaca mi pare che l'icona per trova sia la stessa usata in Acrobat Reader, la lente d'ingrandimento rimane in zoom-*
La risposta corretta era: ma guarda un po' quante belle icone nuove in stile Tango e con la giusta metafora.
Notare infatti, da destra verso sinistra:
- salva - nuova metafora, basta con il floppy che i 'ciofani[1] manco conoscono
- stampa - lo vedete il foglio che "transita" nella stampante?
- taglia - gli occhi delle forbici sono rossi, è un'azione "distruttiva"
- trova - muori lente d'ingrandimento, muori
- trova-e-sostituisci - muori lente d'ingrandimento, muori[2]
Update scusa Ulisse, andavo a memoria e mi sono detto «no, no, è Petrusin, non ho dubbi!» nota per il lettore: «non ho dubbi!» è da leggersi - ad alta voce o mentalmente - come nel famoso discorso di fine anno dell'ex Presidente della Repubblica Scalfaro, grazie.
Una visione d'insieme la trovate su http://git.jimmac.net dove sono mostrate tutte le icone in gnome-icon-theme, così come al momento presenti su svn, definite nelle Icon Naming Spec.
Oh, ovviamente sono disponibili anche le versioni "larghe"
Quello che ora manca è solo risolvere il bug 455937 per evitare in giro che si dica che GNOME non è attento ai problemi ambientali...
[1] giovani in ratzinghiano
[2] per dovere di cronaca mi pare che l'icona per trova sia la stessa usata in Acrobat Reader, la lente d'ingrandimento rimane in zoom-*
I'm too sexy for my desktop[1]
Passando ad argomenti più faceti, qualcuno nota qualcosa di particolare nell'immagine qui sopra?
[1] per chi fosse così giovane da non poter ricordare, gooooglate "Right Said Fred"
Sapevatelo!
Il vincitore del concorso tenutosi negli ultimi post ha scelto come argomento una questione un po' spinosa. Perché ogni tot avvii di GNU/Linux avviene il controllo del filesystem, quando il filesystem è di tipo EXT? Fortuna che tra i feed che seguo c'è la serie developerWorks di IBM :-)
Premetto subito che, se il filesystem scelto è ext3 (ossia la versione con journal) tale controllo si potrebbe disabilitare perché c'è già il journal. Però, prima, vorrei ricordare che il filesystem e la correttezza dei dati in esso contenuti è cosa abbastanza delicata. Talmente delicata che se in passato, come me, avete scelto di usare una certa distribuzione francese perché la trovavi nelle riviste con tutti i sui CD e programmi (sì, compreso gcc e pacchetti -devel) e perché faceva uso di un altro famoso e figo filesystem con journal prima che fosse largamente adottato e provato, allora, come me, potreste aver provato l'onta della perdita di parecchi dati - oddio, talvolta aiuta a ripartire da zero e a eliminare vecchie email di vecchi amori che non avreste mai il coraggio di eliminare motu propriu.
Il file system ext3 è stato progettato dal Dr. Stephen Tweedie, basandosi sulla struttura del filesystem ext2. L'unica, minuscola differenza tra i due è che ext3 supporta il journal.
Tale minuscola differenza in realtà comporta un comportamento estremamente diverso. Sebbene infatti la rappresentazione più semplice che si possa fare pensando a un filesytem è quelle di un luogo in cui memorizzare i dati, bisogna tenere presente che il file system deve anche consentire il recupero e la manipolazione di tali dati. Per tali finalità ogni filesystem (nel senso di modello astratto) prevede la definizione di una struttura dati interna definiti metadata. In definitiva quindi i metadata che un certo filesystem definisce e gestisce (e il modo in cui lo fa) caratterizza il filesystem stesso.
I metadata non sono visibili all'utente, né d'altronde potrebbero servirgli a qualche scopo. Sebbene spesso si usi lo stesso nome, non stiamo qui parlando di cose tipo il tag "artista" di un file MP3. L'unica cosa che deve interessare l'utente a proposito dei metadata è che questi si trovino in uno stato coerente, non corrotto. In caso contrario è impossibile accedere ai file e li si è persi in modo più o meno definitivo (vedi parte finale del secondo paragrafo).
In passato il compito di mantenere i metadati in uno stato coerente era affidato ai programmi unmount e fsck. Il primo veniva invocato durante l'arresto del sistema per tutti i filesytem montati e si occupa di riversare su disco tutte le operazioni ancora pendenti (mica penserete che tutto avviene in modo sincrono, vero?), comprese quindi le operazioni relative ai metadata. Il secondo veniva invocato durante l'avvio per controllare due cose: se il filesystem fosse in uno stato usabile (ossia se è stato smontato in modo pulito) e se i metadata fossero coerenti; entrambi i controlli erano (e sono ancora) effettuati prima di montare il filesystem, il secondo eseguito se il filesystem era in uno stato non usabile, cioè se non era stato usato umount.
Ora, come da lamentele del povero buon ORGA, il controllo dei metadata prende parecchio tempo, specie con filesystem grandi. Per risolvere il problema, i progettisti di filesystem hanno ben pensato di aggiungere una nuovo struttura di dati, il cosiddetto journal. Nel journal, prima che si applichino i cambiamenti ai metadata, vengono scritte le operazioni che descrivono tali cambiamenti. Basta. Punto. Finito qui. Aspettavate chissà quale grande pensata? Hanno solo aggiunto un "terzo livello", così da avere i data (la vostra roba), i metadata (dati relativi alla vostra roba) e meta-metadata (il journal, dati relativi ai dati relativi alla vostra roba).
Il trucco funziona perché, in caso di filesystem non coerente, fsck non deve leggere tutto il filesystem controllando tutti i metadata, ma si può limitare a leggere il journal e applicare le modifiche qui elencate (che sono operazioni non applicate ai metadata per renderli coerenti).
Perché quindi ogni TOT avvii ci si presenta quella fastidiosa scansione? Forse per la legge di Muphy, perché va bene che il journal è cosa buona, ma la paranoia è anche meglio. Per cui un bel controllo vecchia maniera di tutti i metadata una volta ogni tanto non guasta.
In effetti a tale proposito ci sono due scuole di pensiero. La prima è "c'è il journal, che ce ne frega di controllare i metadata". La seconda, io credo più corretta, dice "c'è il journal... ma allora in caso di problemi relativi all'unità, ai cavi, alla memoria o a bug del kernel potrei non accorgermi[1] che il mio filesystem è diventato corrotto". La conclusione della seconda scuola di pensiero è ciò che avete sotto gli occhi: meglio perdere tempo ogni tanto per un controllo approfondito che perdere dati.
[1] o accorgermi troppo tardi: stando al manuale di fsck se il kernel rileva un errore nel filesystem forza l'esecuzione di fsck al successivo riavvio, quando ormai potrebbe essere troppo tardi.
Premetto subito che, se il filesystem scelto è ext3 (ossia la versione con journal) tale controllo si potrebbe disabilitare perché c'è già il journal. Però, prima, vorrei ricordare che il filesystem e la correttezza dei dati in esso contenuti è cosa abbastanza delicata. Talmente delicata che se in passato, come me, avete scelto di usare una certa distribuzione francese perché la trovavi nelle riviste con tutti i sui CD e programmi (sì, compreso gcc e pacchetti -devel) e perché faceva uso di un altro famoso e figo filesystem con journal prima che fosse largamente adottato e provato, allora, come me, potreste aver provato l'onta della perdita di parecchi dati - oddio, talvolta aiuta a ripartire da zero e a eliminare vecchie email di vecchi amori che non avreste mai il coraggio di eliminare motu propriu.
Il file system ext3 è stato progettato dal Dr. Stephen Tweedie, basandosi sulla struttura del filesystem ext2. L'unica, minuscola differenza tra i due è che ext3 supporta il journal.
Tale minuscola differenza in realtà comporta un comportamento estremamente diverso. Sebbene infatti la rappresentazione più semplice che si possa fare pensando a un filesytem è quelle di un luogo in cui memorizzare i dati, bisogna tenere presente che il file system deve anche consentire il recupero e la manipolazione di tali dati. Per tali finalità ogni filesystem (nel senso di modello astratto) prevede la definizione di una struttura dati interna definiti metadata. In definitiva quindi i metadata che un certo filesystem definisce e gestisce (e il modo in cui lo fa) caratterizza il filesystem stesso.
I metadata non sono visibili all'utente, né d'altronde potrebbero servirgli a qualche scopo. Sebbene spesso si usi lo stesso nome, non stiamo qui parlando di cose tipo il tag "artista" di un file MP3. L'unica cosa che deve interessare l'utente a proposito dei metadata è che questi si trovino in uno stato coerente, non corrotto. In caso contrario è impossibile accedere ai file e li si è persi in modo più o meno definitivo (vedi parte finale del secondo paragrafo).
In passato il compito di mantenere i metadati in uno stato coerente era affidato ai programmi unmount e fsck. Il primo veniva invocato durante l'arresto del sistema per tutti i filesytem montati e si occupa di riversare su disco tutte le operazioni ancora pendenti (mica penserete che tutto avviene in modo sincrono, vero?), comprese quindi le operazioni relative ai metadata. Il secondo veniva invocato durante l'avvio per controllare due cose: se il filesystem fosse in uno stato usabile (ossia se è stato smontato in modo pulito) e se i metadata fossero coerenti; entrambi i controlli erano (e sono ancora) effettuati prima di montare il filesystem, il secondo eseguito se il filesystem era in uno stato non usabile, cioè se non era stato usato umount.
Ora, come da lamentele del povero buon ORGA, il controllo dei metadata prende parecchio tempo, specie con filesystem grandi. Per risolvere il problema, i progettisti di filesystem hanno ben pensato di aggiungere una nuovo struttura di dati, il cosiddetto journal. Nel journal, prima che si applichino i cambiamenti ai metadata, vengono scritte le operazioni che descrivono tali cambiamenti. Basta. Punto. Finito qui. Aspettavate chissà quale grande pensata? Hanno solo aggiunto un "terzo livello", così da avere i data (la vostra roba), i metadata (dati relativi alla vostra roba) e meta-metadata (il journal, dati relativi ai dati relativi alla vostra roba).
Il trucco funziona perché, in caso di filesystem non coerente, fsck non deve leggere tutto il filesystem controllando tutti i metadata, ma si può limitare a leggere il journal e applicare le modifiche qui elencate (che sono operazioni non applicate ai metadata per renderli coerenti).
Perché quindi ogni TOT avvii ci si presenta quella fastidiosa scansione? Forse per la legge di Muphy, perché va bene che il journal è cosa buona, ma la paranoia è anche meglio. Per cui un bel controllo vecchia maniera di tutti i metadata una volta ogni tanto non guasta.
In effetti a tale proposito ci sono due scuole di pensiero. La prima è "c'è il journal, che ce ne frega di controllare i metadata". La seconda, io credo più corretta, dice "c'è il journal... ma allora in caso di problemi relativi all'unità, ai cavi, alla memoria o a bug del kernel potrei non accorgermi[1] che il mio filesystem è diventato corrotto". La conclusione della seconda scuola di pensiero è ciò che avete sotto gli occhi: meglio perdere tempo ogni tanto per un controllo approfondito che perdere dati.
Aggiornamento: non l'ho scritto esplicitamente nel precedente paragrafo, ma, se dopo un arresto non pulito ripristino solo il journal e non controllo tutti i metadata, non potrò sapere se ci sono metadata corrotti, derivanti non dalla non sincronizzazione del journal, ma dalle cause "esterne" prima elencate. È più chiaro, adesso?Se siete coraggiosi, comunque, potete disabilitare tale controllo con il seguente comando (consultate la pagina di manuale di tune2fs per il significato):
sudo tune2fs -c 0 -i 0 /dev/PARTIZIONESe siete un po' meno coraggiosi, avete comprato hardware di prima qualità e il vi sembra che il controllo capiti troppo spesso, potete più rilassatamente aumentare i tempi da attendere tra un controllo e l'altro. Per prima controllate con dumpe2fs le attuali impostazioni:
sudo dumpe2fs -h /dev/PARTIZIONENell'output del comando si sono la riga "Maximum mount count: xx" e "Check interval: yyy" : indicano che dopo xx mount o yyy giorni|settimane|mesi verrà eseguito il controllo completo. I valori predefiniti solo xx=20 mount e yyy=10 giorni. Per incrementare il numero di mount, usare:
sudo tune2fs -c 60 /dev/PARTIZIONE
Letture interessanti
- Advanced filesystem implementor's guide per la serie developerWorks di IBM su Linux (per leggere le parti successive aggiungere 2, 3, 4 e così via fino a non so quanto prima di .html
- Parte prima su ext3 della serie di articoli su developerWorks
- Parte seconda su ext3 della serie di articoli su developerWorks
- Using the ext3 filesystem in 2.4 kernels
- Pagina di manuale di dumpe2fs
- Pagina di manuale di tune2fs
- Pagina di manuale di fsck
- Ogni collegamento a risorse esterne nella pagine di developerWorks
[1] o accorgermi troppo tardi: stando al manuale di fsck se il kernel rileva un errore nel filesystem forza l'esecuzione di fsck al successivo riavvio, quando ormai potrebbe essere troppo tardi.
Iscriviti a:
Post (Atom)