Se mi fossi lasciato sfuggire l’offertona di una decina di giorni fa presso i negozi @Work di Torino, non me lo sarei mai perdonato. Ecco dunque l’ultimo arrivato in casa SukkoPera:

Chiudendo un occhio sulla mia ridicola sagoma riflessa ;), si tratta di un iMac 24 pollici (ora fuori produzione) revisionato e perfettamente funzionante, portato a casa a 599 Euro.

Ovviamente, ero e rimango un utente GNU/Linux, per cui il mio primo lavoro su tale mirabolante macchina è stato quello di installarci MacOS X e Slackware in dual boot. Quelli che seguono sono i passi che ho seguito. So che ci sono centinaia di guide al dual-boot in giro per la rete, ma io non ne ho seguita nemmeno una ed ho fatto di testa mia, come da Slackwarista D.O.C. ;).

1. Avviare dal DVD di MacOS X Snow Leopard (tenendo premuto ‘C’ all’accesione).
2. Quando compare la prima schermata, dal menù Utility lanciare l’Utility Disco.
3. Partizionare il disco come desiderato. Il mio iMac ha un disco da 320 GB, che ho così suddiviso:
   • /dev/sda1: Partizione di sistema EFI
   • /dev/sda2 (70 GB): MacOS X
   • /dev/sda3 (50 GB): Slackware
   • /dev/sda4 (200 GB): Dati

   Ignorando quella di sistema, la prima partizione è quella che ho poi indicato come target dell’installazione; la seconda è stata temporaneamente lasciata come spazio libero; per la terza ho scelto il filesystem HFS+ senza journal (vedremo dopo perché).

4. Installare MacOS X a piacimento.
    
    
   
5. Avviare il MacOS X appena installato e installare rEFIt.
6. Riavviare il Mac due volte, finché non compare il menù di rEFIt, quindi da esso lanciare il Partitioning Tool e sincronizzare le tabelle delle partizioni.
7. Avviare dal GParted Live CD (o equivalente, come ad esempio SystemRescueCd) e creare una partizione ext4 (o con il filesystem Linux preferito) nello spazio precedentemente lasciato libero. Questo è necessario perché, per poter ospitare senza troppe complicazione MacOS X e GNU/Linux, il disco deve avere una tabella delle partizioni ibrida GPT/MBR. Se creassimo la partizione con il classico (c)fdisk, la partizione sarebbe unicamente visibile nella struttura MBR e non sarebbe possibile avviarla.
8. Riavviare, lanciare il Partitioning Tool di rEFIt e sincronizzare nuovamente le tabelle delle partizioni.
9. Avviare dal DVD di Slackware e procedere all’installazione nella partizione appena creata.
    
    
   
10. Godersi il dual boot :).
     
    

Credo che si potesse evitare il passaggio 6 semplicemente non lasciando la partizione come spazio libero, ma formattandola con qualunque filesystem e riformattandola poi come necessario durante l’installazione di Slackware. Forse avrei anche potuto crearla da Utility Disco ma non ci ho pensato subito, ed ho preferito riportare la procedura esattamente come l’ho svolta.

La più grande pecca di questa procedura, dovuta alla mia scarsa familiarità con EFI e la GPT (in particolare non ho idea se si possano utilizzare più di 4 partizioni con la tabella ibrida, cosa che richiederebbe l’utilizzo di partizioni estese nella struttura MBR), è che ho dovuto installare Slackware interamente in una partizione, senza suddividere / da /var e /boot come mi piace tanto fare. Addirittura, non ho potuto creare nemmeno una partizione di swap! Mi adatterò utilizzando un banale file di swap, sperando che le performance non ne risentano troppo (suvvia, in fondo la belva ha 2 GB di RAM! :p ).

La scelta del filesystem HFS+ non journaled per la partizione dei dati è dovuta al fatto che Linux è in grado di montare tale filesystem in lettura e scrittura, mentre se avessi attivato il journaling, Linux avrebbe montato la partizione read-only. In questo modo ho a disposizione parecchio spazio per scambiare dati tra i due sistemi operativi, anche se al prezzo di qualche pericolo in più in caso di spegnimento “irregolare” della macchina, ma in fondo ho un UPS mica per niente! :)

Vi terrò aggiornati su ulteriori esperimenti!

UNIX, l’appello di SCO. Disperato.

Il morto vivente che rivendica diritti su UNIX riprova a mordere Novell chiedendo nuovi giudizi e – se necessario – nuovi processi. SCO non ha un soldo né un business, ma gli azzeccagarbugli ancora scribacchiano.

Leggete l’articolo intero qua.

Qualche giorno fa, mentre encodavo qualche nuovo video per i Decade tramite il buon ffmpeg, sono incappato nel seguente errore:

[libmp3lame @ 0x80a64b0]lame: output buffer too small (buffer index: 9195, free bytes: 597)
Audio encoding failed

La soluzione è stata semplicemente quella di aggiornare LAME alla versione più recente. Quando è successo avevo la 3.98.2; ora sono passato alla 3.98.4 e il problema è sparito.

Il mio pacchetto della nuova versione per Slackware 12.2 è disponibile qua. Per chi volesse utilizzarlo su altre versioni della distribuzione, il relativo port per Slackmatic si trova qua. Maggiori informazioni sul mio repository arriveranno appena ho tempo ;).

Credevo che le assurdità dei miei PC fossero terminate quella volta (tra l’altro, non saprei dire ancora oggi come ho risolto di preciso quel problema), ma mi sbagliavo.

In questi giorni sto migrando il server principale di SukkoNet da una macchina ad una più nuova. Sto migrando un servizio alla volta, e documentando il tutto, per condividere poi alla fine i frutti delle mie fatiche (e, in questo, sto apprezzando molto il nuovo Blocco Note di Google). Chiaramente, le prime migrazioni da effettuare erano quella dei dati (e qua ne ho approfittato per passare ad un RAID-1 su due dischi da 1 TB) e quella della “infrastruttura” che mi permette di navigare (il firewall e dnsmasq, in essenza).

La prima operazione è stata piuttosto semplice, anche se ho deciso di compierla in un modo piuttosto peculiare, ma di questo parlerò un’altra volta.

La seconda operazione è stata altrettanto semplice: copio la configurazione di dnsmasq, copio gli script del firewall, applico quelle poche modifiche necessarie (i.e.: cambiare l’IP della macchina su cui il tutto gira), sposto cavi, antenne e schede, testo la connessione e… Tutto pare funzionare alla grande! Lancio un rapido download di prova dalla console, e raggiungo l’incredibile velocità di 400 kb/s, cosa di cui non credevo la mia ADSL (4 mbit) fosse capace!

Bene, tutto a posto. A questo penso di poter proseguire la configurazione comodamente da remoto, così mi trasferisco nella mia stanza col fido MacBook. Per verificare la connettività, provo a fare lo stesso download da lì, ma… è molto più lento di 400 kb/s! Immediatamente penso che possa essere colpa della rete wireless, quindi faccio ssh sul nuovo server e lancio il download da lì, ma prova, riprova e riprova ancora, la velocità varia da un minimo di 10 ad un massimo di 70 kb/s, con una media attorno ai 40. Il pensiero successivo mi suggerisce che forse il sito da cui provo a scaricare è improvvisamente deceduto, quindi mi reco nuovamente alla console fisica del server per verificare questa teoria: lancio per l’ennesima volta il download, e… 400 kb/s!!!

Fermo restando che la lentezza potrebbe anche andarmi bene, in realtà il download in generale risulta molto “spezzettato”, e anche la navigazione ne risente (pagine che non si aprono o si aprono solo parzialmente), ma, soprattutto, la cosa assolutamente inspiegabile! Sono giorni che ci penso ormai, ma non trovo nessuna spiegazione plausibile per cui il download di uno stesso file, effettuato sulla console fisica della macchina o via SSH sulla stessa macchina, possa presentare velocità così diverse (o velocità diverse in generale).

Ma la cosa ancora più assurda è che se mi loggo sulla console del server, e da lì faccio ssh verso il Macbook, il download va a 400! E, ancora peggio, se da lì faccio ancora ssh verso il server, va sempre a 400!!!

Non è colpa del firewall, perché ho provato a disattivarlo, ma non cambia niente. Non c’è nemmeno alcun conflitto di interrupt, altrimenti non mi spiego come sia possibile quanto enunciato al paragrafo precedente

Non so dire se il problema si verificasse anche sul server vecchio, dato che non ricordo di avere lanciato un download dalla sua console. Certo è che ora mi viene il dubbio che tutte le volte che ho infamato l’ADSL di Libero forse ho sbagliato.

Io non so più dove sbattere la testa. Qualcuno ha idee? Il sistema operativo è Slackware 12.2, con il kernel 2.6.27.7-smp.

gcc-java sembra piuttosto pesante:

11:27:48 up 12:33,  1 user,  load average: 75.46, 92.18, 93.85

Mah…

Poco fa stavo facendo un po’ di pulizia su un server che amministro. Una delle cose che volevo fare era “zippare” tutti i log dei backup relativi al 2007 e cancellarli, in modo da avere una directory con una quantità di file umanamente gestibile. Per questo lancio:

linuxsrv backup # tar cjvf log2007.tar.bz2 *2007*

Il comando impiega il suo tempo, e mi crea il buon file log2007.tar.bz2, contenente tutti i log del suddetto anno. A questo punto posso anche rimuovere i file individuali dei log, quindi lancio:

linuxsrv backup # rm *2007*

Geniale, eh? Spero che i log del 2007 non mi servano mai…

Opi mi stava parlando dei suoi primi passi nel mondo UNIX:

(21:15:28) opi: ok
(21:16:19) opi: ma perchè in effetti per alcune cose mi verrebbe instintivo usare più il terminale paradossalmente
(21:16:33) opi: solo che non so ancora bene tutti i comandi
(21:17:00) Ace of Sukkos: basta che metti insieme coppie di lettere a caso
(21:17:12) Ace of Sukkos: tipo cp, mv, ls, cd, rm, ln, mc, ecc
(21:17:19) Ace of Sukkos: :D
(21:17:38) opi: ottimo consiglio :P
(21:17:56) Ace of Sukkos: guarda che funziona! ogni tanto scopro comandi nuovi
(21:18:00) Ace of Sukkos: vediamo un po’
(21:18:12) Ace of Sukkos: rotfl
(21:18:17) Ace of Sukkos: ho appena trovato rt, ad esempio
(21:18:23) Ace of Sukkos: che non so a cosa serva, ma esiste :D
(21:18:31) Ace of Sukkos: e strarotfl
(21:18:32) Ace of Sukkos: anche ui
(21:18:34) Ace of Sukkos: whahaha
(21:18:45) opi: ma porc
(21:18:53) opi: ho stuzzicato la tuo nerdosità
(21:18:54) opi: uff
(21:19:03) opi: non dovevo farlo :P
(21:19:13) Ace of Sukkos: lol, we!
(21:19:24) Ace of Sukkos: muahahaha, magnifico
(21:20:50) opi: …

Da quando l’hard disk del portatile è passato a miglior vita, costringendomi a sostituirlo e a reinstallare tutto da capo, sono diventato un utente Ubuntu, e quindi GNOME. Non che Slackware e KDE mi abbiano stufato (giammai!), ma mi sembra giusto valutare anche delle alternative, per ogni evenienza, e devo dire che, finora, la cosa è stata molto piacevole.

Su Ubuntu, tanto di cappello. È davvero una bella distribuzione, e questa Gutsy Gibbons è veramente piacevole da usare e amministrare, con migliaia di pacchetti disponibili, ottimamente configurati, e con tutta una serie di utility davvero comode per compiere anche le operazioni di amministrazione più complesse con pochi click/comandi. Il rovescio della medaglia è lo stesso delle altre distribuzioni dotate di package manager “intelligente” (ossia tutte tranne Slackware), ovvero che l’installazione dei pacchetti e delle relative dipendenze funziona bene finché si usano i pacchetti così come sono, senza tentare di ricompilarli o di sostituirne uno con una versione compilata di persona (magari per averne una versione più aggiornata o con particolari opzioni di compilazione). Devo anche ammettere che la mia familiarità con apt è ancora scarsa, e magari mi ricrederò in futuro. Certo però che il fatto che apt sia composto da 1000 tool, molti dei quali si sovrappongono in funzionalità, non ne aiuta la piena comprensione. Il tutto comunque passa in secondo piano quando si nota che qualunque periferica si colleghi al PC (ho provato lettore MP3, macchina fotografica digitale, lettore di SD, pennette/dischi USB), questa viene rilevata correttamente e il suo utilizzo è immediato.

Per quanto riguarda GNOME, devo ammettere che, ora che a lavoro ho “preso la mano” con MacOS X, apprezzo molti degli aspetti di questo ambiente grafico che prima trovavo insensati o incomprensibili. Forse nessuno l’ha mai detto chiaramente, ma KDE è nettamente ispirato a Windows, mentre GNOME si rifà più a MacOS X, almeno per quanto riguarda le funzionalità. GNOME, insomma, segue la filosofia delle “poche utili opzioni, piuttosto che quella della “customizzazione esasperata” perseguita da KDE, che, in effetti, risulta spesso in uno smarrimento iniziale, quando ci si trova davanti a una nuova applicazione. L’aspetto che però più odio di GNOME è l’esecrabile gconf-editor: trattasi di un’applicazione dannatamente simile all’editor del registro di Windows, che permette di modificare molte opzioni delle applicazioni non direttamente raggiungibili dall’interno dell’applicazione stessa. Una scelta opinabile, perlomeno, ma dato che sto tentando di usare il portatile da utente medio, per navigare/leggere e scrivere posta/chattare/usare OpenOffice/ecc, conto di non averci troppo a che fare.

Tuttavia, ci sono due comportamenti di GNOME che mi fanno veramente girare le palle. Sono piccolezze, ma non vedo perché, dopo tutti sti anni di sviluppo, non siano ancora implementate.

La prima riguarda il window manager, Metacity: ogni volta che si apre una nuova finestra, questa viene posizionata nell’angolo in alto a sinistra, mentre io la vorrei centrata in mezzo allo schermo. Anche KDE è stato così per anni, ma dalla versione 3 o giù di lì, il posizionamento delle nuove finestre è decisamente customizzabile.

La seconda riguarda Evolution (il client di posta/agenda/PIM), che non riesco a convincere a non fare il top-posting: quando si risponde a un messaggio, il cursore viene posizionato in cima, e il messaggio originale viene inserito sotto. Questa è una delle cose più becere che un client di posta possa fare (e io stesso l’ho fatto per anni :D). Il messaggio originale andrebbe posizionato in cima, in modo che gli si possa rispondere sotto o in mezzo, frase per frase.

In realtà spero di essere stupido io, e di non aver trovato le opzioni per far sì che tutto funzioni come voglio io, pertanto spero che qualcuno mi smentisca e mi spieghi come fare, magari senza usare gconf-editor per delle cose così basilari ;).

Per il resto… consiglio vivamente di provare questa Ubuntu 7.10, soprattutto per chi vuole una distribuzione GNU/Linux subito pronta e funzionale, senza dover smanettare troppo.

Stasera volevo ascoltare un veeeeecchio bootleg degli U2 procuratomi mediante trading moooooolto tempo fa. Prendo la custodia, la apro e… AAAAAAAAAAAARGH! La “vernice” del CD stava cadendo a pezzi, bucherellandosi qua e là! Al che faccio una rapida cernita dei miei bootleg e scopro che tutti i CD di quella marca stanno facendo la stessa fine!

Era da un po’, in realtà, che volevo controllare i miei bootleg di vecchia data, proprio per paura che finissero a questo modo, ma non ne avevo mai trovato il tempo. L’idea era quella di passarli tutti in un formato digitale lossless, in modo da poterli conservare facilmente, e anche di poterli condividere su qualcuno dei tanti siti di scambio bootleg. Si imponeva dunque un’anticipazione della procedura, almeno per quanto riguardava i CD problematici, al fine di salvare il salvabile.

Per il ripping ho ovviamente utilizzato hCDrip, ovvero il programmino Python che mi sono fatto da solo tempo addietro, che fa un po’ da frontend a cdparanoia e ai vari encoder MP3, FLAC, Shorten, ecc…, condendo il tutto con un po’ di supporto CDDB (Forse ne ho anche già pubblicato una versione, non ricordo! Al momento ha trovato qualche problema minore, ma prima o poi ne pubblicherò una nuova versione). Il formato che ho scelto è il FLAC, uno dei più diffusi e supportati.

Comunque, a parte questo, riascoltando uno dei bootleg salvati, mi sono accorto che l’audio era decisamente più lento del dovuto. Ovviamente questo si notava anche dal pitch, troppo basso. Era quindi il caso di sistemare il problema. E questo mi ha permesso di apprezzare un tool come sox che, unito alla potenza di una shell Unix, rende il lavoro rapido e indolore. Ecco come ho fatto:

for i in *.flac; do flac -d -c "$i" | sox -t wav - "$(basename "$i" .flac).wav" speed 1.07; done
rm *.flac
flac --best *.wav
rm *.wav

Tutto qua! Evito di spiegare ogni passo, dato che dovrebbe essere tutto abbastanza comprensibile. Aggiungo solo che il valore 1.07 l’ho trovato a tentativi, provandone di diversi e ascoltando il risultato.

A qualcuno interessa il concerto degli U2 di Werchter 1982? :)

Oggi non deve essere proprio giornata. Prima ho cancellato, accidentalmente, /usr/bin. Dopo una lunga e faticosa riparazione (ovviamente senza reinstallare), ho pensato bene di cancellare deliberatamente anche /var/log/packages.

Sono proprio un pirla.

AGGIORNAMENTO: Prima di andare a dormire, la stessa sera, ho anche fatto in tempo a rischiare di eliminare la cartella in cui raccolgo tutti i miei documenti fin dai miei primi tempi al PC (ossia dal 1994). Si è salvata solo perché ho “dimenticato” -rf nel comando…