Com’era prevedibile, appena uscito, è subito venuto il suo turno:

Qualche tempo fa, sulla mailing list dell’ALLUG è arrivata la seguente mail. La pubblico per darle ulteriore visibilità, dato che penso si tratti di un’iniziativa quantomai interessante:

Ciao a tutti. Mi chiamo Fabrizio e volevo sensibilizzarvi su un progetto open che viene attualmente portato avanti in tutto il mondo: Open Street Map. OpenStreetMap è una mappa liberamente editabile del mondo intero, costruita per lo più da zero usando le tracce GPS o foto satellitari ad accesso pubblico, e rilasciata con una licenza libera. Impropriamente potremmo chiamarla “la Wikipedia delle mappe”.

Se volete farvi un’idea potete visitare:

http://www.openstreetmap.org/
http://www.openstreetmap.it/

per farvi un’idea preliminare del progetto.

Questa introduzione perche’ sto cercando persone interessate al progetto per contribuire a mappare Alessandria o altre zone.  Se guardate la cartina di Alessandria
http://www.openstreetmap.org/?lat=44.91611&lon=8.61655&zoom=15&layers=M
vedete che c’e’ molto lavoro da fare: mancano nomi di vie, piazze, mancano parcheggi, parchi, indicazioni, ecc. Potete guardare Casale Monferrato com’e’ diventata dopo un po’ di lavoro da parte di 2 persone:
http://www.openstreetmap.org/?lat=45.12742&lon=8.45586&zoom=15&layers=M

Se siete interessati, per cominciare non occorrono GPS o altri attrezzi strani, ma buona memoria, carta e penna e un pc.  Potete registrarvi sul sito openstreetmap.org e iniziare ad editare da subito con l’editor integrato.  Potreste aggiungere i nomi delle vie del vostro quartiere, i parcheggi, altri punti di interesse come i parchi o gli edifici ubblici.  Il tutto ovviamente senza copiare da fonti protette da copyright come Google, TuttoCitta’, Mappy, ecc ecc.

Sperando di vedervi presto on-line,
Fabrizio Tambussa

Per quanto mi riguarda, ho già lavorato un po’ sul mio paesello, e credo proseguirò in questa direzione. Ci date una mano?

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!

Pheeeeew, per un pelo! :D

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.

Ormai molti sapranno che tempo fa mi sono dotato di un MacBook. Ovviamente non ci ho messo molto a installarci GNU/Linux, ma ogni tanto mi trovo a dover usare MacOS X, principalmente per gestire il fido iPhone. Credo sia inutile dire che è un ottimo sistema operativo (ovviamente chiudendo un occhio sulla sua non-free-softwarietà…), ma credo anche che dall’avvento di Snow Leopard, la qualità della traduzione italiana sia colata a picco. Durante la sua installazione si presenta infatti una barra di progresso simile alla seguente:

Notate nulla di strano? Cosa vorrebbe dire “Informazioni su 18 minuti”?!? Pensiamoci un po’: “Informazioni su…” probabilmente in inglese era “About” che, guardacaso, vuol dire anche “Circa”, che in questo contesto sarebbe stata una traduzione decisamente più corretta! La cosa sconcertante è che lo screenshot qua sopra l’ho fatto or ora, mentre è in scaricamento l’aggiornamento a MacOS X 10.6.3, il che vuol dire che Apple non si è ancora accorta del bug di traduzione! E quello non è l’unico esempio, perché, tanto per farne un altro, lo screenshot è stato salvato col nome “Schermata 2010-07-05 a 00.07.49″, che non suona esattamente corretto in italiano…

Ora, non so come fossere le traduzioni citate in Leopard, ma non avevo mai notato nulla di strano prima dell’upgrade, per cui… Apple, assumimi (?), ti vengo a curare le traduzioni!

(Via melablog)

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 ;).

In teoria, questo blog è nato, ormai molti anni fa, con lo scopo di diffondere tra le masse i frutti del mio smanettamento tecnico (A.K.A. Nerdaggine). Tuttavia, nel corso degli anni ha preso, una piega più di diario personale, a volte patetico (rasentando addirittura la chiusura!), a volte gaudioso (?), fino a finire abbandonato, quando ho perso la voglia di condividere i miei stati d’animo con gente a cui, in fondo, non ne potrebbe fregare di meno. Non fraintendetemi: questa non vuole essere una critica ai miei tre lettori (anche perché, chi è interessato ai miei stati d’animo li apprende in altri modi), quanto a me, che ho traviato lo scopo originale del blog.

Quindi, da ora cercheremo di riportare il tutto sul binario giusto, tornando ai cari vecchi nerd-articoli, pur riservandoci il diritto a qualche post patetico, di tanto in tanto. Ma, soprattutto, cercheremo di postare (relativamente) spesso! E magari lo faremo addirittura con questo insensato plurale majestatis!

La prima cosa che vi vogliore proporre in questo nuovo corso è la mia fatica di oggi: trattasi di script, scritto rielaborando roba trovata in rete, che permette di controllare le impostazioni di vino, il server VNC integrato in GNOME. Capita, infatti, che quando si lavora su un server remoto, non si abbia modo di utilizzare mouse e monitor per effettuare tali impostazioni (in primis l’abilitazione stessa del server!). Di conseguenza, questo script torna quindi utile per abilitare/disabilitare, impostare la porta TCP e cambiare la password di un desktop GNOME direttamente dalla linea di comando.

Qua il download (Download Manager ha smesso di funzionare, grrrrr!), fatene buon uso!

Il download è disponibile tramite il seguente link: GNOME VNC Toggle.

PS: Come avrete capito, ho gradito talmente tanto la release 4 di KDE, che sono passato a GNOME. Dato che Slackware non lo rilascia più ufficialmente, mi sono affidato, da ormai qualche mese, a GNOME SlackBuild (compaio anche nel ChangeLog, eheheh!), con piena soddisfazione.

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.