giovedì 29 settembre 2011

Vedere i device android collegati al PC in Block Editor di AppInventor, in LINUX

Nella piattaforma di sviluppo AppInventor, una volta che si apre il tool java Block Editor, è possibile, collegato il proprio dispositivo Android al PC via usb, connettere il Block Editor al dispositivo, in modo da poter vedere in anteprima come gira la propria applicazione direttamente sul telefono (o più semplicemente per fare un debug della app che si sta scrivendo direttamente sul proprio dispositivo).

Spesso può capitare di vedere una serie di punti interrogativi (?????????????) quando si apre la finestra a comparsa sopra "Connect to .. " in prossimità di  ciò che dovrebbe la sigla del vostro dispositivo collegato al PC.
In questo caso significa che il vostro sistema linux "vede" il terminale collegato, ma che per una serie di permessi sul device di linux, l'applicativo non riesce a gestirlo correttamente in quanto non è in grado di rilevare i dettagli del dispositivo stesso per il collegamento.

Ecco come fare per rimediare.
Con il sistema udev (quasi tutte le ultime distribuzioni linux dell'ultima generazione):
Creare il file /etc/udev/rules.d/51-android.rules

 # Samsung Galaxy Ace S-5830
 SUBSYSTEMS=="usb", ATTRS{idVendor}=="04e8", ATTRS{idProduct}=="689e", MODE="0666"
 # Samsung Galaxy Tab GT-P1000
 SUBSYSTEMS=="usb", ATTRS{idVendor}=="04e8", ATTRS{idProduct}=="681c", MODE="0666"

Naturalmente i codici a quattro cifre che si trovano fra le virgolette dopo idVendor e dopo idProduct, devono essere sostituiti i rispettivi codici di Vendor e Product relativi al vostro device.
La maniera più semplice per sapere quali sono i codici di Vendor e Product, è quella di collegare il vostro dispositivo al pc e da un terminale linux digitare il comando lsusb. Avrete un output di questo tipo:


Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 007 Device 002: ID 03f0:171d Hewlett-Packard Wireless (Bluetooth + WLAN)    ... [snip] .....
Bus 001 Device 004: ID 04e8:689e Samsung Electronics Co., Ltd 
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Non rimane che individuare la riga relativa al proprio device (in questo caso l'unico Samsung della lista... ) e determinare cosi i codici dopo "ID" che sono rispettivamente Vendor e Product id (in questo caso idVendor=04e8 e idProduct=689e) e sostituirli nella riga del file 51-android.rules.


Poi fare ripartire con restart udev (o service udev restart)

venerdì 24 giugno 2011

Android Gingerbread 2.3.3 + Overcome 2.0.1 su Samsung Galaxy Tab 7"

Impressioni iniziali della Overcome 2.0.1 Hermes

Nel mio Galaxy Tab, in un primo momento sono passato dalla Android 2.2 Froyo alla 2.3.3 Gingerbread.
Essendo arrivato quando avevano già tolto la disponibilità dell’upgrade ufficiale visibile da Kies (praticamente il giorno successivo la sua comparsa), sono stato costretto applicare la procedura manuale dopo aver scaricato il Firmware della Gingerbread 2.3.3 dalla Samfirmware (Amen :-) ) con le indicazioni (grosso modo) reperibili dal seguente link: http://forum.xda-developers.com/showthread.php?t=1073854

Impressioni con la Gingerbread.

Onestamente ero rimasto un po’ deluso: Al di là di un aumento di performance del browser internet standard “di sistema” (che a me poco importava dato che utilizzo per lo più Dolphin HD come browser), in tutto il resto avevo notato solo un peggioramento generale delle prestazioni. Anche solo il sensore di movimento impiegava un certo lasso di tempo prima di “voltarti” lo schermo, in qualsiasi punto fossi anche a menù. Senza parlare della galleria foto, che solo per presentarti le miniature e per spostarti con lo scroll orizzontale la schermata ci impiegava troppo ed andava terribilmente a scatti.

Andando verso Overcome...

Così, avendo sentito parlare molto bene su forum vari di sviluppatori di Android e del GT, sulle prestazioni della Rom Overcome, ieri ho voluto lanciarmi in questo upgrade e l’ho fatto nella forma “Wipe-all”, volendo essere sicuro di dare una “rinfrescata” generale.
Ho seguito attentamente le istruzioni di questo link: http://overcome.mimzo.com/?page_id=64
Naturalmente, occorre prestare attenzione, come suggerito nelle istruzioni, al backup prima di procedere e al conseguente ripristino ad aggiornamento ultimato, poiché avendo scelto la via del “Wipe”, il proprio Tab viene completamente resettato.
A questo proposito, mi sono comprato dal market la versione pro di Titanium Backup (https://market.android.com/details?id=com.keramidas.TitaniumBackupPro&feature=search_result) dopo aver letto che il ripristino delle App con la versione Free sarebbe stato da perdere una notte insonne a forza di dar conferme, uno per uno, agli applicativi e dati ripristinati ..
Dopo la riaccensione, a flash concluso, noto con piacere il logo della Overcome impostato come Splash screen di startup come quello riportato sotto:



In seguito, già mentre avviavo il ripristino (come da istruzioni) notavo il notevole cambiamento nei tempi di risposta del Tab: é cambiato dal giorno alla notte (in positivo ovviamente).
Oltre ad una grafica accattivante, come si può notare da qualche screenshot che ho inserito in fondo al presente articolo, sembra diventato molto più stabile e ricettiva tutta l’operatività del dispositivo, il collegamento alle reti wireless conosciute praticamente immediato, al bluetooth, insomma un po’ tutta la connettività mi ha dato subito l’impressione di essere notevolmente migliorata.
Dal punto di vista grafico, forse l’unica cosa che non mi piace sono le checklist delle impostazioni che quando spuntate sono un pò troppo scure ed essendo simili al colore di sfondo (nero) e danno l’impressione di essere campi in stato “disabled”.. ma sinceramente rispetto ai benefici questa è solo una pignoleria.
Dopo l’accensione del Tab con Overcome, non è stato proprio tutto rose e fiori, ho incontrato qualche problemino, ma che comunque con un pò di pazienza e di ragionamento sono riuscito brillantemente a risolvere.
Sperando di fare cosa utile a qualche altro utente di Galaxy Tab che può aver incontrato gli stessi problemi, ecco qui una breve spiegazione dei problemini avuti e come ho potuto risolverli:
  1. Durante la fase di ripristino. L’app Titanium Backup Pro non riusciva ad acquisire i diritti di root, nonostante fossi riuscito, prima, ad installare Busybox con il tab rootato con successo. Chiaramente non potevo fare il ripristino di tutti le apps che avevo precedentemente backuppato sempre con Titanium.. quindi era da risolvere.
    Ho semplicemente forzato la reinstallazione di Superuser e Busybox. Poi, vedendo che Titanium continuava a dare l’errore di non poter accedere a root, ho capito che forse aveva “ricordato” lo status precedente. Quindi ho semplicemente spento e riacceso il Tab, e a questo punto Titanium, dopo il consenso a prendere i diritti di root, ha funzionato regolarmente.  A questo punto dalle “Operazioni in batch” ho avviato il restore di tutte le applicazioni utente + i dati.
  2. Dopo la fase di ripristino, ad operatività normale. Il blocco degli banners (advertisment blocking) migliorato in Overcome, purtroppo impediva ad alcuni programmi (versioni non-pro) di girare (ora ricordo SSHDroid e Blueputdroid) in quanto facevano appositamente il controllo che nelle versioni non a pagamento non venissero bloccati i banner pubblicitari.
    Cercando di avviare SSHDroid, ottenevo un messaggio di errore tipo “Questa applicazione ha rilevato che i banners sono stati disabilitati. Si prega di riabilitarli prima di rilanciarla o di passare alla versione PRO”.
    In Overcome sono stati molto bravi ad intercettare tutte le varie chiamate ai siti per visualizzare i banner. Li hanno neutralizzati mettendo gli FQDN conosciuti dei vari banner pubblicitari inserendoli nel file /etc/hosts di sistema con indirizzo 127.0.0.1.
    Siccome a me non disturbano i banner pubblicitari, ma preferisco piuttosto che funzionino le app anche gratuite, ho capito che mi era sufficiente modificare il file /etc/hosts lasciando solo la riga con “127.0.0.1  localhost”.
    Come fare? Non è proprio così immediato, quindi vi elenco gli step da fare per ottenere lo stesso risultato:
  • Lanciare un emulatore di terminale di android per andare a linea di comando come Android Terminal o similari (Io ho usato ConnectBot, collegandomi in Local)
  • Appena si ottiene il prompt, andare come super utente (verrà chiesta conferma per accedere al dispositivo con privilegi di root):

    $ su
    # cd /
    #
  • Ora, la mountpoint root (/) è simbolicamente linkata sotto la /system, che è una directory sola lettura. Occorre rimontarla in lettura-scrittura. Per far questo, bisogna specificare il device corretto che è montato alla mountpoint /system.
    Per far ciò, dare il comando:

    # mount | grep system
    /dev/block/stl9 on /system type ext4 (ro,relatime,..)


    In questo caso il mio device montato su /system  è: /dev/block/stl9, quindi:

    # mount -o remount,rw /dev/block/stl9 /system


    A questo punto, facendo lo stesso comando di prima ( mount | grep system), verrà visualizzato:

    /dev/block/stl9 on /system type ext4 (
  • rw,relatime,..) Ora la /system è correttamente montata in lettura-scrittura (rw).
  • Andiamo sotto la /etc

    # cd /etc
  • (o /system/etc)
  • Si può fare una copia di sicurezza del file hosts originale, con il comando:

    # busybox cp hosts hosts.originale-overcome
  • ed ora andiamo ad editare il file /etc/hosts

    # busybox vi hosts
  • A questo punto andiamo sotto alla linea

     127.0.0.1   localhost

    e cancelliamo tutte le linee restanti fino alla fine documento (si fa prima a dare un comando tipo “50000 dd”, così sicuramente vengono prese tutte le righe ;-)
  • salviamo il file modificato con “:wq”
  • Ricordiamoci di rimettere in stato read-only la nostra partizione!!

    # mount -o remount,ro /dev/block/stl9 /system (bada di sostituire /dev/block/stl9 con il device che vi restituisce il comando mount | grep system)
  • e quindi uscire dalla shell

    # exit

    $ exit
  • A questo punto si chiude la connessione e quindi sarà possibile uscire dall’App di emulazione da terminale
Da questo punto in avanti, potrete lanciare tutte le app che vogliono obbligatoriamente visualizzare dei banner pubblicitari. ;-)
E’ tutto.
Se avete suggerimenti,  indicazioni o quesiti relativi a quest’articolo, non dovete far altro che scrivermi una mail a:  gabriele PUNTO zappi CHIOCCIOLA gmail PUNTO com


Gabriele
Qualche screenshot:







lunedì 6 giugno 2011

How Italians vote to STOP Nuclear Power Plants

If you want to see an example of what is NOT a democratic country, of what is NOT a Government that thinks about their own people and that ONLY cares about the interest of corrupt politicians, here you have the ballot that, we Italians, have to vote to make the important decision if we want to have Nuclear Power Plants in a seismic country that have almost no infrastructures to deal with catastrophes.

Look at the picture. The text in the middle tells you basically that if you DON’T want Nuclear Plants in Italy you have to vote “YES”. That text is a mumbo jumbo of legal crap that even a lawyer will have a headache to understand. They think this is democracy without common sense. Do they think I have to understand all this crap? Do I have the time and skills to go all through this and understand if I have to vote YES or NO?

Look at the picture and take your own conclusions. (Click to see in full size)



This is a translation of just a small part of that mumbo jumbo.

“Do you want to derogate the Executive Order of June 25th 2008, number 112, modified from the law number 133 of August 6 2088, the resulting text having successive effects of modification and integration, named “Urgent dispositions for the economic development, the simplification, competition, stabilization of the public finances and the equalization of taxes”, only limited to the following parts: article 7, point 1, letter d: “d) the establishment of centrals of nuclear energy into the national territory”; as well as the law number 99 of July 23 2009, of the resultant text as an effect of modifications and successive integrations, named “Dispositions about the energy”, limited only to the following parts: article 25, comma 1, limited to the words: “of the localization into the national territory…”

More info here, in Italian: http://www.fermiamoilnucleare.it

Fonte: Zuco.org: http://www.zuco.org/2011/05/28/how-italians-vote-to-stop-nuclear-power-plants/


http://farm3.static.flickr.com/2182/5768378410_e9d903a2a3_o.jpg

martedì 31 maggio 2011

"Hash mismatch" su apt-get update usando proxy server

Chi utilizza una distribuzione Debian o una sua derivata (Ubuntu, Mint, Pinguy, etc.) dietro ad un proxy server,  come ad esempio all'interno di una rete aziendale, ecc. , nel momento in cui esegue il comando apt-get update per aggiornare la cache dei pacchetti dai repository standard, può riscontrare a console degli errori di questo tipo:

Se la localisation del sistema operativo e in lingua inglese:
....
W: Failed to fetch http://ir.archive.ubuntu.com/ubuntu/dists/..../Packages.bz2  Hash Sum mismatch
....
E: Some index files failed to download, they have been ignored, or old ones used instead.

Se la localisation del sistema operativo e in lingua italiana:
.....
Impossibile ottenere http://it.archive.ubuntu.com/ubuntu/dists/..../Packages.bz2 Somma Hash non corrispondente
.....
Impossibile scaricare alcune file di indice, essi verranno ignorati, oppure si useranno quelli precedenti.


Questo problema è dato dal fatto che nel proxy server è rimasta una cache "vecchia" che prende il sopravvento per alcune intestazioni di file rispetto a quelle presente nel repository pubblico e di conseguenza il checksum fallisce.

Di soluzioni ce ne potrebbero essere diverse, e forse la più corretta sarebbe quella di chiedere all'amministratore del proxy di fare regolarmente una pulizia della cache relativa agli url dei repository di aggiornamento ...
Tuttavia, l'operazione più veloce che io conosco ed utilizzo in questi casi, è quella di intervenire sulla macchina locale, ossia quella su cui si presenta il problema (su cui ho il pieno controllo come amministratore - o sono un "sudoer user" -, altrimenti non potrei lanciare 'apt-get update' ;-) )
In pratica elimino le liste e i file parziali sul computer locale con i quali viene fatto il checksum rispetto alle liste scaricate dalla rete (sia che queste provengano dal proxy o direttamente dal web..). In tal modo, "forzo" il server proxy a fare un refresh per ricaricarmi le liste complete dei pacchetti, che in questo caso si deve rivolgere all'URL esterno per avere le copie dei file originali aggiornati...

Ecco i pochi e semplici passi da compiere (testato su una Ubuntu Server 10.04 LTS x86_64):
rm -rf /var/lib/apt/lists/* 
mkdir -p /var/lib/apt/lists/partial
apt-get update

Anteporre il comando 'sudo' a tutti i 3 comandi sopracitati se si sta operando con un utente non-root, ma che può essere delegato a ruoli amministrativi (generalmente gruppo "admin" sui sistemi Ubuntu).

Chiunque è pregato di lasciare commenti e/o suggerimenti nel caso in cui ritiene che abbia omesso o descritto qualcosa in maniera imprecisa. Grazie.



Cordiali saluti,
Gabriele
http://www.gabrielezappi.net
GNU/Linux user #380098

lunedì 30 maggio 2011

File di log "/var/log/messages" mancante in Ubuntu Natty Narwhal

[click here for reading this blog post in english]

A seguito di un'installazione ex-novo di Linux Ubuntu 11.04 (Natty Narwhal) mi sono accorto che il file /var/log/messages non c'era (!). Ho altresì constatato che è stata una scelta voluta!
I mantainer del kernel della comunità Ubuntu (o Canonical) hanno preso questa decisione (fornendo un file di configurazione di rsyslog di default che non abilita la scrittura di messages) sostenendo che in tal modo si evita di duplicare linee di log in due file (/var/log/syslog e /var/log/messages).
Francamente e per esser chiaro, disapprovo completamente questa decisione: è vero che si possono avere linee di log duplicate, in quanto alcune di queste vengono scritte in entrambi i file "syslog" e "messages", ma lo scopo di questi file è sensibilmente diverso, pertanto non trovo corretto mischiarli insieme, sostanzialmente per due ragioni: 

  1. /var/log/messages non è solo una convenzione, bensì è divenuto uno standard per tutti i sistemi *nix/linux (Indipendentemente che si parli di distribuzioni di classe desktop o di classe server).
    /var/log/syslog è invece un audit log, pertanto verranno scritti log di qualsiasi cosa (tipo processi di  cron o at, messggi di "informazioni" non strettamente di "warning", e così via ...)
    /var/log/messages è generalmente il file in cui gli applicativi scrivono eventuali messaggi di warning, anche se non strettamente inerenti il kernel, messaggi di boot (non-kernel) simili alle informazioni ottenibili con il comando 'dmesg'. Questo è generlmente IL file principale da visionare, quando si ha l'impressione che qualcosa non stia andando come dovrebbe, o per verificare che il sistema e tutti gli applicativi principali stiano girando in maniera corretta!
  2. Tutti gli applicativi standard e i programmi (incluso applicazioni di terze parti, non fornite con la distribuzione, ecc.), programmi di monitoraggio, analizzatori e monitor di rete, ambienti SNMP (come Hobbit, Nagios, ecc.) generalmente intercettano stati ed eventuali condizioni d'errore leggendo questo file. Non ritengo neanche che sia una buona soluzione creare un link simbolico tra syslog e messages, in quanto i succitati programmi e/o processi sarebbero costretti ad analizzare inutilmente milioni di linee di log in più, rischiando così di incidere negativamente alle prestazioni di tutto il sistema.
Penso che né Canonical né la comunità Ubuntu possa decidere di apportare una variazione ad uno schema standard dall'oggi al domani (per lo meno senza aver preso in esame la cosa con una commissione mondiale sugli standard - vedi ANSI, ISO, ecc. - che ne valuterà l'opportunità). 
Comunque qui di seguito elenco i passi per ripristinare la scrittura del file /var/log/messages come in passato:
  • editare il file /etc/rsyslog.d/50-default.conf (con "sudo vi /etc/rsyslog.d/50-default.conf" se si è loggati come utenti non-root)
  • Cambiare il seguente paragrafo:
...
#
# Some "catch-all" log files.
#
#*.=debug;\
#       auth,authpriv.none;\
#       news.none;mail.none     -/var/log/debug
#*.=info;*.=notice;*.=warn;\
#       auth,authpriv.none;\
#       cron,daemon.none;\
#       mail,news.none          -/var/log/messages
....
con questo

....
#
# Some "catch-all" log files.
#
*.=debug;\
        auth,authpriv.none;\
        news.none;mail.none     -/var/log/debug
*.=info;*.=notice;*.=warn;\
        auth,authpriv.none;\
        cron,daemon.none;\
        mail,news.none          -/var/log/messages
....

(in altre parole, togliere il commento dalle linee sotto 'Some "catch-all" log files.')

  •  far ripartire il demone rsyslog con il seguente comando:
        sudo restart rsyslog
  • Fatto! Ora /var/log/messages sarà nuovamente scritto come nelle release precedenti.
Comunque, mi auguro che questo fastidioso (anche se apparentemente innocuo) problema venga sistemato in Oneiric (e secondo me potrebbe essere anche candidata come  patch per natty-backports)

Cordiali saluti,
Gabriele
http://www.gabrielezappi.net
GNU/Linux user #380098

"/var/log/messages" log file missing in Linux Ubuntu Natty Narwhal (english post)

[clicca qui per il post in lingua italiana]

Hi there,
After a clean install of Linux Ubuntu 11.04 (Natty Narwhal) I realized that the log file /var/log/messages was missing. I realized that it was a deliberate choice as well!
Ubuntu community's (or Canonical's) kernel guys took that decision (modifing rsyslog configuration file provided as default after install) saying that this change avoids logs to be duplicated in two log files (/var/log/syslog and /var/log/messages).
Just to be frank, polite and clear... I totally disagree this choice: as a matter of fact, you can have duplicated rows in both log files "syslog" and "messages", but the purpose of these files is quite different, and I don't find it correct to mix them up, for two reasons:

  1. /var/log/messages is not only a convention. It became a standard for all *nix/linux systems (no matter if you run a server or a desktop class distribution).
    /var/log/syslog purpose is to be the audit log, and it will be log everythings (such as cron/at jobs, "info" msg, and so on ...)
    /var/log/messages is the usual place for system applications warning messages, even if non-kernel related, boot messages (non-kernel) similar to info you may report with command 'dmesg'. This is THE place to look at, if you feel that something is going wrong!
  2. All standard applications and programs (including applications out-of-the-box, third part's, etc..), monitoring programs, Network monitors & SNMP frameworks (such as Hobbit/XyMon, Nagios, Zabbix, and so on) usually go to look for it in order to catch statuses and error conditions. It's not a solution to symbolic link syslog to messages, because that mentioned programs/daemons would parse milions of unuseful lines of logs in vain, degrading the overall system performances consequently.

Since I feel that neather Canonical nor Ubuntu community can decide to change this importand standard overnight (at least without discuss a change in a worldwide commission of IT standards or something like that - see ISO, ANSI, etc.), here is how to take rsyslog back to write /var/log/messages like in the past:


  • edit file /etc/rsyslog.d/50-default.conf (with "sudo vi /etc/rsyslog.d/50-default.conf" if you are logged as normal user)
  • Change the following paragraph:
...
#
# Some "catch-all" log files.
#
#*.=debug;\
#       auth,authpriv.none;\
#       news.none;mail.none     -/var/log/debug
#*.=info;*.=notice;*.=warn;\
#       auth,authpriv.none;\
#       cron,daemon.none;\
#       mail,news.none          -/var/log/messages
....
 
                      • to read the following:
                      ...
                      #
                      # Some "catch-all" log files.
                      #
                      *.=debug;\
                              auth,authpriv.none;\
                              news.none;mail.none     -/var/log/debug
                      *.=info;*.=notice;*.=warn;\
                              auth,authpriv.none;\
                              cron,daemon.none;\
                              mail,news.none          -/var/log/messages
                      ...
                        (in other words, uncomment the lines under the text 'Some "catch-all" log files.')
                      • restat rsyslog with the following command:
                            sudo restart rsyslog
                      • Done! Now /var/log/messages will be written again.

                      Anyway, I hope that this annoying problem will be fixed in Oneiric (and this should nicely be a valid patch for natty-backports)

                      Yours faithfully,
                      Gabriele
                      http://www.gabrielezappi.net
                      GNU/Linux user #380098

                      martedì 3 maggio 2011

                      Google Earth su Ubuntu 11.04 Natty Narwhal

                      A differenza delle release precedenti, con Ubuntu 11.04 anche installando i repository medibuntu e google non-free, non è più possibile installare Google Earth già pronto per la propria distribuzione via apt-get o attraverso synaptic / Software Manager.
                      Tuttavia nei repository di google, vi viene messo a disposizione un pacchetto, "googleearth-package" che contiene uno script in grado di partire dal binario proprietario, analizzare le librerie presenti nel vs. computer e di costruire un pacchetto Ad-hoc pronto da installare nel vostro sistema Debian o Ubuntu.
                      E' necessario avere il pacchetto lsb-core e se il vostro sistema ha un'archittettura diversa da i386 (a 32 bit), come un amd64 o ia64 (64 bit), occorre anche installare il pacchetto di compatibilità a 32bit ia32-libs.
                      Quindi vediamo i vari passi:

                      user@ubuntu:~$ sudo apt-get install lsb-core googleearth-package # .. aggiungete al comando  'ia32-libs' se avete un sistema  a 64 bit

                      A questo punto lanciate lo script (possibilmente NON come root, altrimenti occorre forzare con un --force)

                      user@ubuntu:~$ make-googleearth-package

                      La procedura vi scarica l'ultima release di GoogleEarth di Linux disponibile (al momento la 6.0.2!!!  :P ), raccoglie informazioni su tutte le librerie necessarie già presenti nel vostro sistema, e integra il tutto in un pacchetto .deb che lo troverete nella directory corrente con il nome  googleearth_x.y.z-_amd64.deb o googleearth_x.y.z-_i386.deb (a seconda dell'architettura del sistema operativo in cui lanciate il comando).
                      Quindi ora è sufficiente installarlo con un bel
                      user@ubuntu:~$ dpkg -i googleearth_x.y.z-_amd64.deb

                      Al termine dell'installazione lanciate il vostro googleearth nuovo fiammante "ritagliato" per il vostro pinguino.  ;)
                      ( dovreste trovarlo a menu di Kde o Gnome, oppure premente ALT+F2 per eseguire il comando e date 'googleearth', o lo lanciate da terminale con 'googleearth &' ).

                      :)

                      martedì 15 marzo 2011

                      Linux - Scaricare semplicemente video di Youtube da linea di comando (da terminale)

                      Installazione comando youtube-dl

                      Su Ubuntu Linux è semplicissimo, basta installare youtube-dl digitando:

                      sudo apt-get install youtube-dl

                      Su distribuzioni dove invece il comando youtube-dl non è presente a repository, poco male, occorre dare qualche comando in più per installarlo manualmente:

                      • Scaricare youtube-dl da qui: http://rg3.github.com/youtube-dl/ (tasto destro "salva documento sull scrivania")
                      • Bisogna avere già installato Python
                      • Rinominare il file youtube-dl.sh in youtube-dl.py
                      • Copiate il file youtube-dl.py nella cartella /usr/bin (o in altra directory raggiungibile dal PATH, es. /usr/local/bin o $HOME/bin) digitando:

                        sudo cp youtube-dl.py /usr/bin




                      A questo punto siamo pronti per scaricare i nostri video da youtube col terminale!
                      Digitate ad esempio:
                      youtube-dl.py http://www.youtube.com/watch?v=iR1b7G1TM0s -o prova.mp4
                      L'opzione -b scarica il video alla massima qualità trovata, mentre l'opzione -t assegna lo stesso nome del video usato a quello di youtube.
                      L'opzione -o che permette di specificare il nome e formato del file di destinazione; -c per continuare download interrotto.

                      Per interrompere eventualmente il download premete ctrl+c

                      Problema aggiornamento operatività di youtube-dl in seguito a nuove specifiche di YouTube.

                      Fantastico comando, eh, youtube-dl ?
                      Tuttavia, molti di voi si saranno accorti che ultimamente youtube-dl non funziona correttamente, e riceveranno un messaggio di questo tipo:

                      gabo@ubuntu:~$ youtube-dl -i http://www.youtube.com/watch?v=Zg0VibH6Pbo
                      [youtube] Setting language
                      [youtube] Zg0VibH6Pbo: Downloading video webpage
                      [youtube] Zg0VibH6Pbo: Downloading video info webpage
                      [youtube] Zg0VibH6Pbo: Extracting video information
                      ERROR: unable to download video (format may not be available)


                      :-( ...
                      .. niente paura, youtube-dl deve essere solo aggiornato secondo le ultime specifiche di YouTube. :-)
                      Sfortunatamente, anche per i possessori di Ubuntu /Debian, youtube-dl non si aggiorna come tutti gli altri programmi da linea di comando con un semplice apt-get update, ma occorre specificare al comando youtube-dl stesso di andarsi a prendere gli aggiornamenti, con il seguente comando.

                      sudo youtube-dl -U

                      Tuttavia, occorre tener presente che l'update occorre farlo due volte. Dopo la prima, a terminale ci verrà visualizzato:
                      Updating to latest stable versionxn--
                      Updated to version github


                      Ridando un comando per catturare un video, riceveremo di nuovo un errore:
                      youtube-dl -i http://www.youtube.com/watch?v=Zg0VibH6Pbo

                      [youtube] Setting language
                      [youtube] Zg0VibH6Pbo: Downloading video webpage
                      [youtube] Zg0VibH6Pbo: Downloading video info webpage
                      [youtube] Zg0VibH6Pbo: Extracting video information
                      ERROR: unable to download video (format may not be available)


                      Allora ripetiamo un'altra volta il comando di prima
                      sudo youtube-dl -U

                      Updating to latest stable versionxn--
                      Updated to version 2011.02.25c


                      Dopo quest'ultimo messaggio (Updated to version 2011.02.25c), youtube-dl sarà aggiornato correttamente.

                      Infatti:
                      youtube-dl -i http://www.youtube.com/watch?v=Zg0VibH6Pbo

                      [youtube] Setting language
                      [youtube] Zg0VibH6Pbo: Downloading video webpage
                      [youtube] Zg0VibH6Pbo: Downloading video info webpage
                      [youtube] Zg0VibH6Pbo: Extracting video information
                      [download] Destination: Zg0VibH6Pbo.mp4


                      ;-)

                      NOTA: Naturalmente questa procedura di aggiornamento, è aggiornata alla data di scrittura del presente post (15/03/2011). E' molto probabile che in futuro, in seguito a nuove ulteriori variazioni di specifiche di Youtube, occorra ripetere nuovamente la procedura sopra descritta.

                      mercoledì 5 gennaio 2011

                      Linux, Mac, Windows: rsync ottimo anche per fare backup sul computer locale (non solo per sincronizzare due percorsi via rete!)

                      Come utilizzare rsync per effettuare back-up sul nostro Mac / Linux.

                      Rsync è un comando davvero potente, già installato di default sia su Mac che su Linux.
                      Permette di sincronizzare le cartelle / files in maniera incrementale, aggiornando quindi solo i files / cartelle modificati o aggiunti.

                      Funziona in maniera molto simile la "Time Machine" sul Mac!

                      Ad esempio:

                      rsync -av --progress --delete --exclude='*~' --exclude='.*' --exclude='folder' /home/nome_utente/Documenti /media/LaCie/back_up

                      In questo modo andiamo a salvare il contenuto della cartella "Documenti" nell'HD esterno "LaCie".

                      --progress mostra messaggi che indicano il progresso dell'operazione di sincronizzazione;

                      --delete elimina dalla destinazioni gli eventuali file che nel percorso sorgente non ci sono più;

                      -a sostituisce in blocco l'opzione -rlptgoD (ricorsivo, preserva, orario, gruppi, utenti, permissions, symlinks, devices, etc... );

                      --exclude serve per specificare un pattern di file/dir da escludere nel salvataggio (nell'esempio escludo i file di backup (es. nomefile.txt~) generati automaticamente quando si salva nell'editor un file su sè stesso; escludo anche i files nascosti dal Mac e la cartella "folder")!

                      Per maggiori info ricordo sempre di utilizzare il comando:

                      man rsync

                      ma è possibile anche dare una occhiata qua: http://montellug.it/download/conferenze2007/Conferenze%202007%20-%20Rsync%20-%20Manuel%20Dalla%20Lana.pdf


                      Versioni GUI (Graphic User Interface):

                      Grsync per win: CLICCA

                      Grsync per Mac: CLICCA