Newsgroup: it.comp.os.linux.software
Titolo: iniziare, come?

Io ho iniziato con kubuntu, bel desktop, bella grafica, ma quando si
arriva a cercare il software giusto iniziano i dolori.
Sono oramai mesi che cerco di sincronizzare il mio pda iPAQ con
windows mobile 5.0 e dopo aver installato decine di synce package sono
sempre al punto di partenza: pls -> elenco contenuto del pda
pstatus -> stato del mio pda
ma di sincronizzare non se ne parla proprio...
ma esiste un pacchetto che, una volta installato, mi permetta di
sincronizzare il mio hand held device???
kubuntu ha ancora molta strada da fare....
--
Saluti

 Saluti
Bye


Troll?

Il Fri, 09 Feb 2007 23:33:54 +0100, warp <v...@picard.starfleet.ufp> ha
scritto:

6 stato di grandissimo aiuto, meno male che esistono persone come te!
ora si che so da che parte iniziare!!!
--
Saluti

Troll?
no, grazie
--
Saluti

 ora si che so da che parte iniziare!!!
Allora ti do io un consiglio: it.comp.os.linux.iniziare
E un altro: non trollare

 ora si che so da che parte iniziare!!!
Sempre a disposizione dei nipoti della grande Uhura, del resto è solo 
per questo che ho isposto...
P.S.: Segui le indicazioni di Alessandro che mi sembra uno che se ne 
intende. ;-)
Ciao

 no, grazie
Mi scuso allora, ma le tue "sentenze" mi avevano insinuato il dubbio.
Anche se concordo che i desktop Linux abbiano ancora strada da fare (ma,
secondo me, non tantissima rispetto alla concorrenza), ti assicuro che da
quando mi sono avvicinato a Linux per la prima volta (con una Red Hat 5.0)
di strada ne hanno fatta parecchia.
Ciao

Ciao
grazie della cortese risposta e scusa se sono sembrato un troll, non
volevo.
effettivamente pare che ubuntu sia sulla strad buona, ho appena letto
la notizia di un accordo con una altro distributore, speriamo che alla
fine venga un desktop veramente user friendly che eviti le
(sinceramente noiose) aperture di shell con i vari su e sudo
ciao
--
Saluti

 (sinceramente noiose) aperture di shell con i vari su e sudo
Non le trovo affatto noiose..
-- 
Debian GNU/Linux etch - Kernel 2.6.18-3-k7 SMP - Beryl 0.1.3
AMD64 X2 3800+ - 2GB RAM - HDD 180 GB Sata + 30 GB Pata
Nvidia GeForce 7300 LE 256 MB - LG Flatron L1715S - Netgear DG632
Dite NO! a TCPA / Palladium / DRM ---> 
http://no1984.org/

 
Se ti dà fastidio fare le cose da shell, dai un'occhiata su 
http://www.kde-look.org/
 nella sezione "Service Menus". C'è un pò di 
tutto e di +. E quello che manca puoi fartelo tu (non è difficile).

 writes:
Premetto che un utente/developer Mac OS X ha detto che Ubuntu ha quasi
raggiunto il Mac OS.
U> speriamo che alla fine venga un desktop veramente
U> user friendly che eviti le (sinceramente noiose) aperture di shell
U> con i vari su e sudo
ma ti conviene evolverti da questa posizione.
Perché ?
Prendiamo nuovamente Mac OS X come metro di paragone (che Windows è troppo
mal progettato dagli inizi).
Mac OS X segna una svolta nei  Mac OS in quanto riprende i concetti di
NeXT, li adatta allo stile Mac  OS e li ripropone. In primis quello di
avere un S.O. con API Unix e shell sotto.
Bellissimo, ma limitante. Limitante ? E in cosa chiederai.
La risposta è in una frase che gira dal Pluto Meeting del 1999:
   "La differenza tra GUI e shell è quella che corre tra gesticolare e
    parlare. Io preferisco parlare"
                                                [Chiara Paci]
Ovvero  quella che  pare  una scomodità,  la  shell, è  in realtà  una
comodità.
Per i programmatori, dirai, io non sono un programmatore.
Non solo. Supponi  di far parte di una associazione  che abbia un sito
su cui vengono  pubblicate le foto fatte da vari  soci. I soci mandano
le foto  in vari  formati, vanno riportate  ad una  dimensione comune,
fatti  i   thumbnails,  messi  eventuali  messaggi   di  copyright  (o
copyleft). Poi va fatta la pagina con quattro parole per descrivere la
situazione cui  fanno riferimento le foto, tradurre  le quattro parole
in inglese, usarle per la pagina coi thumbnail e poi fare le pagine di
dettaglio.
Sono cose che fanno tante persone che non sono certo programmatori, ne
converrai.
Partiamo dalle  immagini. Come fai via  GUI ? Beh, il  file manager ti
permetterà di caricare tutte le  immagini insieme in GIMP. O.K. questo
lo abbiamo automatizzato, al costo di sovraccaricare la macchina ma lo
abbiamo automatizzato.
Bene,  ora dobbiamo guardare  le foto  per vedere  se sono  in formato
orizzontale  o verticale  (landscape  o portrait),  quindi apporre  il
messaggio di copyright, ridimensionarle una prima volta ed una seconda
per i thumbnail, e salvare ambedue le immagini.
*Obiezione  dalla platea*:  Hei,  Gimp si  può  programmare!!! 
Si, ma stiamo parlando di gente  che non fa il programmatore, e poi ti
garantisco che  non conosco molti programmatori che  si troverebbero a
loro agio con lo Scheme di Gimp.
(A dire il vero conosco e *moooooooooooooooooolto bene* anche un pirla
che  in piena metropolitana  parigina ha  esclamato "Liiiiiiiiiiiisp!"
quando  ha visto un  pezzo di  Scheme -  molto simile  a LISP  - sulla
pagina di una rivista dedicata a Linux che un ignaro viaggiatore stava
leggendo. Ma questo è un altro discorso... :) :) :))
Torniamo al nostro lavoro con le immagini.
Dunque  un utente  esperto  si farà  da  una parte  l'immagine con  il
messaggio di copy(right|left) su  sfondo trasparente, la copierà nella
clipboard, la incollerà sulle  varie immagini. Facendosi furbo farà il
messaggio in due  colori contrastanti (i.e. nero con  bordo bianco) in
modo da poterlo mettere sia su zone chiare che scure.
Da utente esperto userà la tastiera per le varie operazioni, che ci si
mette meno che col mouse.
Risultato, si troverà  ad agire come e peggio di  uno di quegli operai
descritti  da  Chaplin in  Tempi  Moderni  o  da Lang  in  Metropolis,
ripetendo   quanto  più   velocemente  possibile   sempre   le  stesse
operazioni. Monotono, stancante se sono 10 immagini. Se sono 80 ?
Se sono 80 non lo so, 10 si.
Non lo  so come  è per 80  immagini perché  un giorno una  fatina (mia
moglie) mi ricorda che c'è un insieme di comandi utilizzabili da shell
(Imagemagick).   Lo ammetto,  grafica da  terminale non  li  avevo mai
associati,  ma perdo  tempo a  leggere il  manuale. Bingo,  ci  sono i
comandi che mi servono.
Bene,  allora invece  di  fare  le sequenze  di  comandi lavorerai  di
history, dirà qualcuno.
Niet!
Si chiama shell, non cmd.exe!!!
Lo  ammetto,  quando  cominciai c'era  o  la  shell  o la  shell.   Ma
fortunatamente  avevo un  paio  di  buoni libri  -  purtroppo non  più
disponibili, sopratutto il  Kernighan - Pike e quindi  non ci ho messo
più  di 10  giorni ad  imparare a  fare quello  che mi  è  servito per
scrivere questo
#!/bin/bash
#
# Distribuito sotto GNU GPL V2 o successive
#
# Ridimensiona: ridimensiona un immagine e crea il thumbnail
#               usa Imagemagick
TH_LAND="200x133"
TH_PORT="133x200"
FS_LAND="500x376"
FS_PORT="376x500"
# Non mi ricordo mai l'uso
if [ $# = 0 ]
then
    echo 1>&2 "Uso: "$0" immagine [destinazione]"
    exit 1
elif [ $# -gt 3 ]
then
    echo "Argomenti in eccesso ignorati"
fi
SORGENTE=$1
# Se non ho indicato il file destinazione, sovrascrivo quello
# originale 
if [ $# = 2 ]
then
    DESTINAZIONE=$2
else
    DESTINAZIONE=$1
fi
# man basename e man dirname (tirano fuori il nome e la directory di
# appartenenza di un file 
if [ "."`dirname $DESTINAZIONE` = "." ]
then
    THUMBNAIL="thn_"`basename $DESTINAZIONE`
else
    THUMBNAIL=`dirname $DESTINAZIONE`"/thn_"`basename $DESTINAZIONE`
fi
echo "Trasformo "$SORGENTE" in "$DESTINAZIONE" con thumbnail "$THUMBNAIL
# pesca l'aspect ratio dal comando identify, che lo mette come terzo
# campo in output nella forma LARGHEZZAxALTEZZA, se
# larghezza/altezza > 1 allora l'immagine è in orizzontale (più larga
# che alta)
#
# O.K. awk non è immediato senza il Kernighan & Pike :), ma non è
# difficile.
if [ `identify $SORGENTE | awk '{ print $3 }' | awk -Fx '{ print ($1/$2 > 1)?"L":"P"}'` == "P" ]
then
    TH_SIZE=$TH_PORT
    FS_SIZE=$FS_PORT
else
    TH_SIZE=$TH_LAND
    FS_SIZE=$FS_LAND
fi
#Ridimensionamenti!
convert -size $FS_SIZE $SORGENTE -resize $FS_SIZE +profile "*" $DESTINAZIONE
convert -size $TH_SIZE $SORGENTE -resize $TH_SIZE +profile "*" $THUMBNAIL
#------------------------------------
Quello qui sopra non è uno  script perfetto (mi sono accorto di un bug
che non  ho mai sperimentato) ma  quando ci sono state  80 immagini da
ridimensionare ha fatto  tutto lui, anche se ci ha  messo tanto, io ho
fatto  altro. Ad  esempio  ho  tradotto le  4  parole dall'italiano  a
inglese comprensibile, cosa che una macchina da sola non può fare.
È solo per mostrare  come la shell non è una cosa  scomoda. È una cosa
potente e utile.
Oramai non  la ho.  Quando non  c'è mi sento  fortemente limitato. Non
perché non sappia fare  le cose con una GUI. Ma perché  la GUI non può
fare certe cose.  Sopratutto non può lavorare lei per  me. C'è poco da
fare, gesticolando  la nostra capacità di comunicare,  anche ordini ad
una macchina, è limitata.
Quanto a sudo - che non mi piace - e su.
Mac OS  usa sudo  in automatico,  comodo... ma non  mi piace  molto, è
comodo  quando devi  permettere ad  alcuni utenti  di  eseguire alcuni
comandi che solo root può dare.
Preferisco tenere una  shell aperta con l'utente root.  Sfondo rosso e
scritte gialle a)  per ricordarmi che quello è un  terminale di root e
b) per  essere scomodo - per lavorare  ci sono i terminali  con il mio
utente.
Non farti divorare dalle ammalianti sirene delle GUI user friendly.
-- 
 /\           ___
/___/\_|_|\_|__|___Gian Uberto Lauri_____
  //--\| | \|  |   Integralista GNUslamico
\/                 e coltivatore diretto di Software

Non le trovo affatto noiose..
forse non saranno noiose, ma devi ammettere che se vuoi installare e
disinstallare qualcosa e meglio uno strumento tipo apt manager che ti
fornisce più informazioni su quello che accade, io con il su e il sudo
non capisco nulla di tutte le righe di installazione
a proposito, dopo aver installato enne pacchetti (ripeti enne volte
make install ecc ecc) senza peraltro riuscite a sincronizzare il mio
pda, ora come faccio a disinstallare tutto quello che non mi serve?
grazie
--
Saluti

 ha scritto:

grazie mille, una informazione costruttiva!
--
Saluti

Non farti divorare dalle ammalianti sirene delle GUI user friendly.
ho letto tutto il tuo lungo messaggio e ne capisco la filosofia.
sinceramente però preferisco imparare ad usare l'uso di una gui ben
fatta e che eventualmente mi protegga chiedendomi la password ogni
volta che voglio modificare un file di sistema, piuttosto che imparare
un linguaggio di programmazione unix o python.
per quale motivo devo rendermi la vita difficile se è possibile
eseguire lo stesso comando con pochi clic intuitivi del mouse?
ti faccio anch'io un esempio:
prova a metterti nei panni di un ragazzino delle medie (ebbene si,
sono un prof) al quale vuoi insegnare a costruire l'ortocentro di un
triangolo, cosa scelgo?
geogebra, software opensource basato su java che i ragazzi imparano in
circa 45 secondi?
oppure utilizzo un linguaggio tipo set(x,y) fd(100) rt(90) o roba del
genere?
io la risposta ce l'ho.
per adesso sto ancora alla finestra e spero proprio che ubuntu,
kubuntu e altre gui desktop per linux conquistino maggiori spazi a
discapito di windows.
p.s. utilizzo anche CD live tipo knoppix zeppi di ottimi educational
software open source
--
Saluti

 Si chiama shell, non cmd.exe!!!
Un solo appunto. Anche se limitato rispetto ad una qualsiasi shell
linux, Windows ha un linguaggio batch da decenni, che mette a
disposizione anche dei costrutti condizionali e (se non ricordo male)
iterativi
Enrico


Lo sai che il cervello e' l'unico organo che non si usura se viene
sollecitato, anzi... in mancanza di stimoli si atrofizza.
-- 
Senza lilleri non si lallera

> Non farti divorare dalle ammalianti sirene delle GUI user friendly.
U> ho letto tutto il tuo lungo messaggio e ne capisco la filosofia.
U> sinceramente però preferisco imparare ad usare l'uso di una gui ben
U> fatta e che eventualmente mi protegga chiedendomi la password ogni
U> volta che voglio modificare un file di sistema, piuttosto che
U> imparare un linguaggio di programmazione unix o python.
La  shell non  ti chiede  di programmare.  Ti permette  di  scrivere i
comandi una sola volta.
U> per quale motivo devo rendermi la vita difficile se è possibile
U> eseguire lo stesso comando con pochi clic intuitivi del mouse?
Per il motivo che fatto una volta sono pochi clic intuitivi.
Fatti ripetitivamente sono schiavitù. Non  se se te ne rendi conto, ma
non è più la macchina che serve te, sei tu asservito alla macchina.
U> ti faccio anch'io un esempio: prova a metterti nei panni di un
U> ragazzino delle medie (ebbene si, sono un prof) al quale vuoi
U> insegnare a costruire l'ortocentro di un triangolo, cosa scelgo?
U> geogebra, software opensource basato su java che i ragazzi imparano
U> in circa 45 secondi?
U> oppure utilizzo un linguaggio tipo set(x,y) fd(100) rt(90) o roba
U> del genere?  io la risposta ce l'ho.
Io rilancio, Logo ?
Non sottovalutare la capacità delle menti giovani, anche se spesso
sono rincretinite dalla televisione. 
Una volta che incuriosisci un ragazzino/a è fatta...
U> per adesso sto ancora alla finestra e spero proprio che ubuntu,
U> kubuntu e altre gui desktop per linux conquistino maggiori spazi a
U> discapito di windows.
Non  sei il  solo a  sperare che  GNU/Linux conquisti  sempre maggiori
spazi.  Proprio perché  permette di  mettere la  macchina  al servizio
dell'uomo, non l'uomo al servizio della macchina.


> Si chiama shell, non cmd.exe!!!
E'B> Un solo appunto. Anche se limitato rispetto ad una qualsiasi
E'B> shell linux, Windows ha un linguaggio batch da decenni, che mette
E'B> a disposizione anche dei costrutti condizionali e (se non ricordo
E'B> male) iterativi
Un contro appunto. E' un linguaggio batch, ovvero DEVI metterlo in un
file batch.
Nella shell una sequenza di comandi che usi una sola volta la scrivi 
senza scomodare alcun editor...
Quando ti accorgi che ti serve più di una volta usi il cut'n'paste di
X oppure fc :)


 io la risposta ce l'ho.
Io alle medie (sono classe '82) facevo esercitazioni di Basic, ovviamente
a livello alquanto elementare, ma almeno alla fine avevo un'idea di come
funziona un lingaggio imperativo. 
Capisco che i ragazzi di oggi siano
abituati a ben altre effetti speciali, ma non credevo si fossero così
rincoglioniti da avere bisogno di una GUI anche per chiedere di andare in
bagno!
La GUI è bella è utile, per carità, ma se ti fa da velo di maya rispetto
a quello che c'è dietro o se spaventa digitare dei comandi (e vale
soprattutto a scuola penso) non c'è SO che tenga, il PC non è più uno
strumento tecnologico, è una tv sotto steroidi!

Il Tue, 13 Feb 2007 23:14:04 +0100, Delta R <R...@noreply.invalid> ha
scritto:

certo, sono perfettamente d'accordo.
pero' preferisco scegliere io gli stimoli che voglio e mi permettono
di essere più creativo in meno tempo
--
Saluti

dell'uomo, non l'uomo al servizio della macchina.
 bene, speriamo...
nel frattempo divulgo knoppix live, software incluso
--
Saluti

X oppure fc :)
fammi capire, se vuoi riusare una serie di comandi te li slavi in un
normale file di testo? poi copy/paste e lo usi? interessante...
ecco, vedi, mi hai incuriosito!
grazie
--
Saluti

 normale file di testo? poi copy/paste e lo usi? interessante...
Non proprio. Quello che intende Gian Uberto e` che se voglio riusare uno
script, scrivo i comandi in un file, lo intesto con l'interprete che mi
interessa (i caratteri #! seguiti dal percorso assoluto dell'interprete
che mi interessa all'inizio del file), e lo rendo eseguibile. Ora quel
file sara` sempre disponibile per eseguire il compito per cui lo hai
creato
Enrico

> comandi una sola volta.
U> scusa la mia ignoranza di ambiente shell, ma questa tua
U> affermazione non la capisco, la posso solo intuire
La  risposta è  la  metto nel  post  che faccio  rispondendo a  Enrico
'Henryx' Bianchi...


> un normale file di testo? poi copy/paste e lo usi? interessante...
E'B> Non proprio. Quello che intende Gian Uberto e` che se voglio
E'B> riusare uno script, scrivo i comandi in un file, 
Ni, Enrico, Uhuru ha inteso bene e il testo che segue è a suo beneficio
La shell ha un meccanismo che si chiama "Storia" (history e` il termine
tecnico). La hanno implementata perfino in cmd.exe :)
Questo  meccanismo ti  permette  di richiamare  un  comando passato  e
rieseguirlo.
E fin qui credo niente di nuovo.
Un comando poco conosciuto della history è fc, che richiama $EDITOR(*)
caricando l'ultimo comando dato. Vero che un comando del tipo:
for i in *.jpg
do
        ridimensiona $i ../risultato/$i
done
te lo presenta come 
for i in *.jpg; do ridimensiona $i ../risultato/$i; done
ma con un buon editor la cosa non è un problema. Se invece di salvarlo
nel file  temporaneo creato  dalla shell  lo salvo in  un file  di mia
scelta, allora, oltre a rieseguirlo  me lo troverò anche in quel file,
pronto ad ogni riuso, come  dice Enrico. Ho trasformato il mio comando
in uno script.
Un' altro  modo è sfruttare  il copia ed  incolla tra la  finestra del
terminale e l'editor per copiare i vari comandi.
La mia frase
"La  shell non  ti chiede  di programmare.  Ti permette  di  scrivere i
comandi una sola volta." 
significa questo: non ti viene chiesto di "creare" un programma. Ma ti
vengono dati  gli strumenti per raccogliere  le mosse che  hai fatto e
farle ripetere alla macchina.
É una cosa che permettono gli interpreti di comandi in generale. 
E'B> lo intesto con
E'B> l'interprete che mi interessa (i caratteri #! seguiti dal
E'B> percorso assoluto dell'interprete che mi interessa all'inizio del
E'B> file),
Manovra  utile,  corretta, consigliabile,  ma  non indispensabile.  Se
manca questa intestazione "magica",  sarà la tua shell ad interpretare
i comandi, e la cosa spesso va bene per gli scriptini.
Io  ho iniziato a  farlo solo  da quando  ho scoperto  che la  cosa fa
riconoscere gli script come tali al mio editor :)
E'B> e lo rendo eseguibile. Ora quel file sara` sempre
E'B> disponibile per eseguire il compito per cui lo hai creato
Questo passo lo avevo dimenticato, grazie Enrico che senza questo non
funziona nulla.
Per rendere eseguibile il programma basta il comando 
    chmod u+x [nome_dello_script]
Un'altra  cosa  è  che   i  comandi  eseguibili  non  vengono  cercati
dappertutto, ma solo all'interno delle directory elencate in $PATH.
Credo che sia ancora una abitudine utile crearsi una directory per gli
script (usualmente la si chiama bin) da elencare nel $PATH.
<folklore> Arrivai a Unix dopo aver  usato un VIC20 e per qualche mese
un mainframe. In quegli ambienti c'era una differenza tra i comandi di
sistema ed i miei programmi. I  primi c'erano, scrivevi il loro nome e
funzionavano. Per i secondi dovevi  usare un comando che li eseguisse,
erano "cittadini di seconda categoria" del computer. Fu una sorpresona
scoprire  che in  Unix i  miei script  avevano la  stessa  dignità dei
comandi di sistema. Ah, se ve lo state chiedendo, il mio uptime è di
circa 1.29383396E9 secondi :)</folklore>
Note:
(*)  $EDITOR (variabile  di ambiente  della  shell) ha  perso oggi  di
importanza. Quasi  tutti i programmi che richiedono  di modificare del
testo si  portano dietro una  schermata con un (cattivo)  editor.  Una
volta, ai tempi  dei terminali e quando l'history  non c'era (#$@%&!!)
un programma che  voleva far modificare un testo  lanciava $EDITOR. Ad
esempio il programma  che leggeva la posta la  leggeva e basta, quando
compilavi la risposta lanciava $EDITOR per farla scrivere.
Va da se che quando ci si trovò un $EDITOR programmabile, il programma
di posta venne scritto *nell'* editor :)

 writes:
U> certo, sono perfettamente d'accordo.  pero' preferisco scegliere io
U> gli stimoli che voglio e mi permettono di essere più creativo in
U> meno tempo
Frase che vale fintanto che la GUI  ti aiuta e non ti ostacola: se per
fare il mio lavoro sono costretto a ripetere N volte la stessa manovra
meccanica...
D'altro canto  non è che  le GUI siano  male in assoluto,  non bisogna
dare alla GUI troppa importanza ma nemmeno rifiutarla.
Ad  esempio nella  didattica, se  ho  un esperimento  sul quale  posso
intervenire  modificando i  parametri, farlo  con una  GUI  può essere
molto  più utile  ai fini  dell'apprendimento: ad  esempio  il bambino
"afferra" un  vertice, lo sposta e  la grafica gli  mostra come cambia
l'ortocentro, rendendogli chiaro il rapporto di causa ed effetto.
Fargli inserire numericamente le coordinate della nuova posizione del
vertice NON ha lo stesso impatto descrittivo.
Peraltro,  se devo determinare  l'ortocentro per  progettare qualcosa,
meglio che  indichi con  precisione le coordinate  dei tre  vertici da
tastiera piuttosto che affidaremi ad  una GUI la cui sensibilità ad un
certo punto rischia di divenire insufficente.


 funziona nulla.
Ni :)
Se non imposti il bit eseguibile (chmod 755 nomescript, personalmente ho
sempre preferito la notazione ottale), e` vero che non esegui
drettamente lo script, ma puoi sempre eseguirlo richiamando l'interprete
(o la shell) per cui e` stato scritto
Enrico
P.S. oramai direi che e` doveroso segnalare
http://www.pluto.it/files/ildp/guide/abs/

 writes:
E'B> Se non imposti il bit eseguibile (chmod 755 nomescript,
E'B> personalmente ho sempre preferito la notazione ottale), e` vero
E'B> che non esegui drettamente lo script, ma puoi sempre eseguirlo
E'B> richiamando l'interprete (o la shell) per cui e` stato scritto
Vero, ma non mi par la cosa più pratica del pianeta
E'B> Enrico P.S. oramai direi che e` doveroso segnalare
E'B> 
http://www.pluto.it/files/ildp/guide/abs/
L'ottimo lavoro dello ILDP. Peccato che il Pluto non abbia prodotto altro...


 Vero, ma non mi par la cosa più pratica del pianeta
Dipende dalla situazione in cui ci si trova. Ad esempio, e` molto comodo
per andare in debug dello script
Enrico

> Vero, ma non mi par la cosa più pratica del pianeta
E'B> Dipende dalla situazione in cui ci si trova. Ad esempio, e` molto
E'B> comodo per andare in debug dello script
Il debug non e` proprio una operazione che fanno tutti (anche se penso
che utilizzero` il suggerimento...)
