Ma quanto è veloce una CPU moderna?


— Foto: CPU Artworks.

Un anno fa proprio di questi tempi non si parlava altro che di Meltdown e di Spectre, due vulnerabilità appena scoperte che permettevano di accedere al contenuto della memoria interna del processore (la memoria cache) senza averne i diritti, consentendo (almeno potenzialmente) di recuperare dati riservati come password, dati bancari, certificati digitali e quant’altro.

A differenza del famoso Pentium Bug della metà degli anni ’90,1 Meltdown e Spectre non derivano da errori di programmazione ma sono quasi delle caratteristiche intrinseche dei processori moderni, troppo veloci rispetto al resto dell’hardware che li circonda.

Ma non voglio parlare qui di Meltdown e Spectre, va bene non seguire troppo l’attualità ma non esageriamo. È successo che, giusto in corrispondenza dell’anniversario, ho ritrovato sepolti sotto una pila di carte alcuni articoli che ne parlavano e, complice la reinstallazione del sistema operativo su un server, sono riuscito finalmente a leggerli, imbattendomi in un’informazione piuttosto interessante che vale la pena condividere.

Come ho detto prima, i processori (o CPU, Central Processing Unit) moderni sono veloci, anzi velocissimi, ad un livello che non riusciamo nemmeno ad immaginare. Per noi, già dei tempi dell’ordine del millisecondo (ms, 1 millesimo di secondo) non hanno un vero significato, sono troppo brevi rispetto all’esperienza comune. Figuriamoci cosa succede con intervalli di tempo ancora minori, a livello del microsecondo (μs, 1 milionesimo di secondo) o del nanosecondo (ns, 1 miliardesimo di secondo)!

Ma se proviamo a riportare questi tempi a qualcosa che possiamo capire direttamente, le cose prendono tutta un’altra piega.

In uno degli articoli più interessanti che ho letto dopo un anno, ho trovato la tabella riprodotta qui sotto, ripresa da un post di Jeff Atwood (autore del famoso blog Coding Horror, una lettura indispensabile per chi si occupa di programmazione), che ha sua volta l’aveva tratta dal volume Systems Performance: Enterprise and the Cloud di Brendan Gregg (e così sono a posto con le attribuzioni).

Nella tabella in questione, il tempo che una CPU odierna impiega per eseguire una operazione elementare, 0.3 nanosecondi corrispondenti a 3.3 GHz, viene scalato ad un secondo, un intervallo di tempo che siamo in grado di comprendere, traducendo in modo corrispondente un gran numero di altri tempi caratteristici del funzionamento di un computer.

1 ciclo di CPU 0.3 ns 1 s
Accesso alla cache di 1 livello 0.9 ns 3 s
Accesso alla cache di 2 livello 2.8 ns 9 s
Accesso alla cache di 3 livello 12.9 ns 43 s
Accesso alla memoria RAM 120 ns 6 minuti
Trasferimento dati da un disco a stato solido 50-150 μs 2-6 giorni
Trasferimento dati da un disco meccanico 1-10 ms 1-12 mesi
Trasferimento dati su Internet: da SF a NYC 40 ms 4 anni
Trasferimento dati su Internet: da SF alla Gran Bretagna 81 ms 8 anni
Trasferimento dati su Internet: da SF all’Australia 183 ms 19 anni
Riavvio di un sistema operativo virtualizzato a livello software 4 s 423 anni
Time-out di un comando SCSI 30 s 3000 anni
Riavvio di un sistema operativo virtualizzato a livello hardware 40 s 4000 anni
Riavvio di un computer 5 m 32 millenni

Nella tabella, SF sta per San Francisco, NYC per New York City.

Visti in questo modo i numeri sono stupefacenti. Una CPU odierna può sommare due numeri nell’equivalente di un secondo, ma deve aspettare pazientemente ben 6 minuti per ricevere i dati dalla memoria RAM del computer (una memoria che viene considerata velocissima) e fino a una settimana per riceverli da un già veloce disco a stato solido. Non parliamo nemmeno di quello che succede con un disco meccanico, che ha tempi di trasferimento corrispondenti a quelli dell’esercito di Cesare in viaggio verso la Gallia. E per una CPU il riavvio di un computer è una vera iattura: su questa scala temporale equivale ad aspettare che l’uomo moderno esca dal Paleolitico ed arrivi fino ad oggi.

Non so voi, ma quando vedo le cose in questa prospettiva non posso che levarmi il cappello davanti a chi progetta questi oggetti meravigliosi.


  1. Molto interessante questo articolo su Science, How Number Theory Got the Best of the Pentium Chip, che tratta degli aspetti matematici dietro la scoperta del Pentium Bug. 
Annunci
Tagged with: , , , ,
Pubblicato su hardware

L’anno che finisce

E così finisce anche il 2018. Fare un bilancio dell’anno appena trascorso è una cosa molto personale e la lascio volentieri a ciascuno di voi. Intanto voglio augurare a tutti uno splendido 2019, per quello che mi riguarda se fosse sullo stesso livello del 2018 non sarebbe affatto male.

Ma prima di finire l’anno, un ultimo video con quello che forse il nostro Presidente vorrebbe dire (ma non può) nel suo discorso di fine anno.

Tagged with: , ,
Pubblicato su società

Script per tutti i giorni: shell e parametri


— Foto: Trammell Hudson su Flickr.

Lo script di conversione del titolo di un post mostrato alla fine della puntata precedente è diventato ormai quasi “utilizzabile”. Mancano solo un paio di tocchi finali, che vedremo nel corso di questa terza parte.

Una casa per i programmi

Prima di proseguire è bene decidere una volta per tutte dove salvare gli script che stiamo sviluppando. Non so voi, ma io preferisco usare una cartella dedicata allo scopo invece di buttare tutto dove capita. In tutti gli articoli di questa serie gli script in fase di sviluppo saranno salvati nella cartella Development, situata all’interno della cartella Home (o Inizio) dell’utente che ha effettuato il login (la cartella Home è quella rappresentata dall’icona di una casetta). Ovviamente siete liberi di usare un altro nome e un’altra posizione sul disco rigido, ma dovrete ricordarvi di modificare di conseguenza i percorsi dei comandi.

Già che ci siamo, creiamo subito la cartella Development. Se usate il Finder non ho bisogno di dirvi come si fa, se invece usate il Terminale basta eseguire i comandi

$ cd ~
$ mkdir Development

dove il primo comando, cd ~ (ma su macOS e varie versioni di Linux è sufficiente il semplice cd) ci fa spostare nella nostra Home, mentre il secondo comando crea la nuova directory Development. Nelle shell Unix come bash, il simbolo tilde ~ (che si scrive premendo ALT-5) indica la Home dell’utente.

Volendo potremmo anche eseguire semplicemente

$ mkdir ~/Development

che crea la directory desiderata con un unico comando.

Qualche breve nota generale. In questo contesto i termini script o programma sono equivalenti e li userò indifferentemente. Lo stesso vale per directory e cartella. Io preferisco il primo, ma so benissimo che, da quando esistono le interfacce grafiche, il termine “cartella” è diventato di uso molto più comune. Nel seguito cercherò di usare “cartella” nel testo discorsivo degli articoli e “directory” quando si tratterà di riferirsi ai comandi di bash e al Terminale. Infine, il simbolo $ prima di ogni comando è il cosiddetto prompt e serve ad indicare che stiamo interagendo con il Terminale; non fa parte dei comandi e quindi non deve mai essere inserito quando scriviamo un comando nel Terminale.

Andare con le proprie gambe

Nella puntata precedente siamo arrivati ad usare uno dei tanti editor di testo disponibili su macOS per inserire queste righe di codice

string="La privacy al tempo dell'Internet of Things: gran finale"

fix_string=$(echo $string | tr "[:upper:]" "[:lower:]")
fix_string=$(echo $fix_string | sed "s/'/ /g")
fix_string=$(echo $fix_string | sed "s/[[:punct:]]//g")
fix_string=$(echo $fix_string | sed "s/ /-/g")

converted_string=$fix_string
echo $converted_string

Ora possiamo salvare lo script nella cartella ~/Development/, dandogli un nome significativo che ci aiuti a ricordare anche in un secondo momento cosa fa il programma. Molto meglio quindi usare un nome come convert_title.sh piuttosto che un criptico SCCUSIFJ.sh, anche se profuma tanto di DOS e di anni ’80.

Nei sistemi Unix come macOS l’estensione .sh non è indispensabile ma ci aiuta a capire al volo che il file è uno script della shell (da cui .sh). È possibile usare altre estensioni come .shell, .script, .cmd o perfino .bat, per il sistema operativo non cambia nulla.

A questo punto possiamo finalmente di eseguire lo script. Lanciamo il Terminale, spostiamoci nella cartella dove abbiamo salvato lo script

$ cd ~/Development

ed eseguiamo lo script con il comando

$ sh convert_title.sh
la-privacy-al-tempo-dell-internet-of-things-gran-finale

ottenendo, come previsto, la trasformazione della stringa definita nella string nel formato adatto a Jekyll o a WordPress.

Per eseguire lo script dobbiamo premettere al nome del file il comando sh che indica al sistema operativo che il file in questione contiene una serie di comandi di shell, cioè di comandi che permettono di interagire con il sistema operativo stesso (attenzione, il comando sh è una cosa ben diversa dall’estensione .sh vista prima!). Con questa informazione, il sistema operativo trasferisce l’esecuzione dello script alla shell di default, che in macOS e nella maggior parte dei sistemi Linux attuali è bash. Niente però impedisce di forzare l’utilizzo di bash, scrivendo esplicitamente

$ bash convert_title.sh

al posto di sh convert_title.sh, oppure di utilizzare altre shell eventualmente disponibili nel sistema, come tcsh, ksh, zsh o fish (argomento che non verrà trattato in questa serie).

Purtroppo affidarsi alla configurazione di default del sistema può creare problemi, ad esempio perché qualcuno ha cambiato la shell di default, magari solo per fare una prova, dimenticando di ripristinare la configurazione iniziale. Per fortuna in genere queste cose non succedono per cui possiamo stare relativamente tranquilli. Però il meccanismo appena descritto non è né semplice, né tanto meno a prova di bomba.

Proviamo a semplificarci la vita con due piccole modifiche. Prima di tutto utilizziamo il comando chmod per rendere eseguibile lo script all’utente attuale del Mac

$ chmod u+x convert_title.sh

dove la u indica l’utente che sta usando il Mac e il simbolo +x significa che il file viene reso eseguibile (la x sta per eXecute). Se volessimo rimuovere questa autorizzazione, non dovremmo far altro che eseguire il comando duale

$ chmod u-x convert_title.sh`

Se invece volessimo autorizzare tutti gli utenti del Mac ad eseguire questo script, dovremmo scrivere

$ chmod a+x convert_title.sh

mentre per autorizzare solo gli utenti che fanno parte del nostro stesso gruppo di lavoro oppure tutti gli altri utenti fuori dal nostro gruppo di lavoro, dobbiamo usare rispettivamente chmod g+x convert_title.sh oppure chmod o+x convert_title.sh.

Ma queste sono finezze utili per i server a cui accedono decine e decine di utenti contemporaneamente, i Mac sono sostanzialmente macchine monoutente (o che gestiscono un numero molto ridotto di utenti), per cui chmod u+x (o al massimo chmod a+x) a noi basta e avanza.

L’altra modifica utile è quella di indicare esplicitamente al sistema operativo quale shell vogliamo utilizzare per interpretare i comandi contenuti nel nostro script. Per farlo è sufficiente aggiungere all’inizio dello dello script la sequenza di caratteri #!, il cosiddetto shebang,1 seguita dal percorso completo al programma di shell che vogliamo usare.

Dato che qui usiamo bash, il nostro script diventa

#!/bin/bash

string="La privacy al tempo dell'Internet of Things: gran finale"

fix_string=$(echo $string | tr "[:upper:]" "[:lower:]")
fix_string=$(echo $fix_string | sed "s/'/ /g")
fix_string=$(echo $fix_string | sed "s/[[:punct:]]//g")
fix_string=$(echo $fix_string | sed "s/ /-/g")

converted_string=$fix_string
echo $converted_string

Ma come lo troviamo il percorso di bash? C’è un comando anche per questo: which seguito dal nome di un qualunque comando Unix restituisce proprio il percorso completo del comando all’interno del filesystem. Di conseguenza which bash restituisce

$ which bash
/bin/bash

che è proprio ciò che dobbiamo inserire in testa allo script subito dopo lo shebang.

Per verificarlo, basta provare a salvare lo script modificato con un nome diverso, diciamo convert_title_v2.sh e rendiamolo esegubile con il comando chmod a+x convert_title_v2.sh descritto prima.2 A differenza di convert_title.sh, questo secondo script potrà essere eseguito senza dover premettere sh

$ ./convert_title_v2.sh 
la-privacy-al-tempo-dell-internet-of-things-gran-finale

Per una serie di ragioni che vedremo in una prossima puntata, dobbiamo però aiutare il sistema operativo a trovare lo script aggiungendo esplicitamente il percorso allo script da eseguire. Poiché nei sistemi Unix (e non solo), il punto . indica la cartella corrente (mentre il doppio punto .. si riferisce alla cartella che contiene la cartella corrente), scrivere ./ immediatamente prima del nome dello script equivale a dire al sistema operativo che lo script si trova nella cartella corrente, che in questo caso è la cartella dove siamo entrati all’inizio di questa puntata con il comando cd ~/Development.

Parametri sulla linea di comando

C’è ancora una cosa che non va bene. Ogni volta che vogliamo cambiare la stringa da convertire dobbiamo intervenire direttamente sullo script, modificando la variabile string. Facendo così è facile sbagliare, e in ogni caso sarebbe molto più comodo rendere lo script indipendente dai dati sui quali deve operare (in questo caso la stringa da convertire).

Non voglio entrare nei dettagli (ma ci sarà tempo per approfondire la questione), per ora basterà dire che per rendere lo script indipendente dalla stringa da trasformare è sufficiente assegnare a string il valore della variabile convenzionale $1

#!/bin/bash

string=$1

fix_string=$(echo $string | tr "[:upper:]" "[:lower:]")
fix_string=$(echo $fix_string | sed "s/'/ /g")
fix_string=$(echo $fix_string | sed "s/[[:punct:]]//g")
fix_string=$(echo $fix_string | sed "s/ /-/g")

converted_string=$fix_string
echo $converted_string

L’interprete bash assegna automaticamente alle variabili $1, $2, … $9, dette parametri posizionali, i valori degli argomenti dello script, cioè i valori dei parametri presenti sulla linea di comando subito dopo il nome dello script da eseguire.3 I diversi parametri sono separati da uno o più spazi, e se un parametro contiene degli spazi bisogna racchiuderlo fra virgolette, non importa se semplici ' o doppie " (però è preferibile essere consistenti ed evitare di mescolare i due simboli).

Salviamo lo script così modificato con il solito nome convert_title.sh e torniamo al Terminale. Ora per usare lo script dobbiamo scrivere la stringa da convertire direttamente sulla linea di comando, subito dopo il nome del file, racchiudendola fra virgolette dato che la stringa contiene degli spazi (io preferisco usare le virgolette doppie)

$ ./convert_title.sh "La privacy al tempo dell'Internet of Things: gran finale"
la-privacy-al-tempo-dell-internet-of-things-gran-finale

Naturalmente niente impedisce di trasformare stringhe molto più lunghe, come ad esempio un paragrafo di questo stesso articolo, l’unica limitazione è che la stringa non deve contenere dei caratteri di ritorno a capo

$ convert_title.sh "Purtroppo affidarsi alla configurazione di default del sistema può creare problemi, ad esempio perché qualcuno ha cambiato la shell di default, magari solo per fare una prova, dimenticando di ripristinare la configurazione iniziale. Per fortuna in genere queste cose non succedono per cui possiamo stare relativamente tranquilli. Però il meccanismo appena descritto non è né semplice, né tanto meno a prova di bomba."
purtroppo-affidarsi-alla-configurazione-di-default-del-sistema-può-creare-problemi-ad-esempio-perché-qualcuno-ha-cambiato-la-shell-di-default-magari-solo-per-fare-una-prova-dimenticando-di-ripristinare-la-configurazione-iniziale-per-fortuna-in-genere-queste-cose-non-succedono-per-cui-possiamo-stare-relativamente-tranquilli-però-il-meccanismo-appena-descritto-non-è-né-semplice-né-tanto-meno-a-prova-di-bomba

Se guardiamo attentamente il risultato della conversione notiamo come lo script non riesce a trattare correttamente i caratteri accentati, come era stato già notato esplicitamente nella prima puntata di questa serie di articoli. Per ora sarà sufficiente evitare di usare i caratteri accentati o almeno scriverli con una vocale seguita da un apostrofo, come se stessimo usando una tastiera americana.

Conclusioni (per ora)

Se togliessimo l’estensione al nome del file, lo script convert_title diventerebbe quasi indistinguibile dai comandi veri e propri del sistema operativo. Dico “quasi” perché per poterlo eseguire dobbiamo ancora premettere il percorso alla cartella corrente al nome del file. Ci sarà modo per risolvere questo (piccolo) problema, i più impazienti possono leggere qui per capire in anteprima come si fa.

La prossima volta faremo un veloce ripasso dei comandi presentati in queste prime tre puntate, utile per consolidare quanto visto finora prima di passare ad usare uno degli strumenti più potenti ma anche meno conosciuti dell’arsenale Unix.

Revisioni

30-12-2018: Corretta una imprecisione relativa al cambiamento dei permessi dei file quando la prima riga di uno script contiene lo shebang e il percorso all’interprete bash (si veda la nota 2).


  1. Detto anche sha-bang o hashbang
  2. Se la stringa #!/bin/bash è esattamente la prima riga dello script, quando salviamo lo script l’editor TextMate lo rende eseguibile da tutti gli utenti del sistema, proprio come se avessimo usato esplicitamente il comando chmod a+x .... È una particolarità del solo TextMate, tutti gli altri editor che ho provato (Atom, BBEdit, Visual Studio Code e CotEditor fra quelli grafici, nano, emacs e vim per quanto riguarda gli editor testuali) non modificano mai i permessi del file. 
  3. Se abbiamo bisogno di più di nove parametri, dobbiamo racchiudere quelli dal decimo in poi fra parentesi graffe, scrivendo ${10}, ${11} e così via. 
Tagged with: , , , ,
Pubblicato su programmazione

Un Mac montato in diretta

Quando ho iniziato a guardare questo video pensavo che fosse la solita presentazione di un nuovo prodotto. Qualche battuta, un paio di giochini introduttivi — carino il bicchiere pieno d’acqua tirato fuori dalla borsa — l’immancabile video pubblicitario. Ma si trattava della presentazione del Macintosh Portable, il primo Macintosh portatile,1 un computer di scarsissimo successo commerciale ma che è stato una vera icona del suo tempo, e sono andato avanti a guardare.

Se lo si vede con gli occhi di oggi il Macintosh Portable è un mostro grosso e pesante: più di sette chili di peso, un mini display da 10 pollici con una risoluzione di appena 640 x 480 pixel, un disco rigido opzionale da 40 MB. Il processore era quasi lo stesso del Macintosh originale del 1984, solo un po’ più veloce e meno avido di potenza.

Ma nel 1989 il Macintosh Portable era un vero oggetto del desiderio, una meraviglia tecnologica, la batteria durava dieci ore e si poteva mettere in uno stato di animazione sospesa a bassissimo consumo da cui si risvegliava con il semplice tocco di un tasto. Ogni volta che passavo davanti al negozio nel centro di Torino che lo esponeva, invidiavo profondamente i fortunati che potevano permetterselo, per me giovane precario (ancora per poco, per fortuna) era solo un sogno irrealizzabile.

Perché il Portable costava, accidenti se costava, più di dieci milioni di vecchie lire (senza tenere conto dell’inflazione sono 5.000 euro). E se si voleva avere il modem o 1 MB di RAM in più, bisognava tirar fuori altri due milioni, uno per il modem e uno per la RAM. Solo la batteria di ricambio era economica, 70 mila lire (circa 35 euro) per un mattoncino da un chilo.

Nel video Jean-Louis Gassée,2 sembra a disagio, la sua presentazione non ha niente a che vedere con quelle spumeggianti di Steve Jobs o con i Keynote “rock” a cui siamo abituati oggi. Sta sul palco da solo su uno sfondo completamente nero, qualche Mac sulla destra a dare un tocco di colore. Il pubblico è invisibile, applaude al momento giusto ma per il resto non esiste. Sembra tutto piuttosto noioso, ma a un certo punto arriva il momento “wow!” e Jean-Louis inizia a montare un Macintosh Portable.

In diretta, proprio lì sul palco.

Non c’è nemmeno una vite, ogni pezzo si incastra nell’altro con un bel click sonoro, Jean-Louis deve solo ricordarsi di collegare i vari connettori alla scheda madre e in una decina di minuti il Mac è pronto. Ci potrebbe mettere molto meno se non dovesse spiegare a cosa serve ogni pezzo. Non manca nemmeno la finezza di poter montare il trackball indifferentemente alla destra o alla sinistra della tastiera, per essere accessibile anche ai mancini.

E alla fine Jean-Louis tocca un tasto e, Ta Da!, il Mac si accende come se fosse appena uscito dalla linea di montaggio. Fantastico!

Il video perfetto per festeggiare, oggi.

Buon Natale a tutti!!!


  1. E credo anche il primo portatile Apple in assoluto. 
  2. Jean-Louis Gassée è stato uno dei top manager Apple dopo la defenestrazione di Steve Jobs e poi il padre dello sfortunato sistema operativo BeOS
Tagged with: , , ,
Pubblicato su hardware

E sono cinque!

Oggi il blog compie cinque anni. Purtroppo me ne sono ricordato solo all’ultimo momento e non ho avuto il tempo di fare una analisi dettagliata come mi ero ripromesso di fare. Pazienza, magari ci sarà occasione in una circostanza meno “tonda”.

Una cosa che mi colpisce sempre è che, nonostante il blog sia in italiano, ben il 10% degli accessi provenga da fuori Italia. Chissà cosa riescono a capire i poveri visitatori che leggono gli articoli tramite Google Traduttore!

Un’altra cosa che mi colpisce è che, oltre ai tanti lettori affezionati che non mi stancherò mai di ringraziare per la loro immensa pazienza, circa due terzi dei vsitatori arrivano al blog tramite i motori di ricerca. Anzi, tramite Google, gli altri motori di ricerca, anche Bing o DuckDuckGo (e mi dispiace soprattutto per quest’ultimo), praticamente non esistono. Il che significa da un lato che il blog si posiziona abbastanza bene nelle ricerche sul web (anche se io non faccio nulla per spingere in su la SEO del blog), dall’altro che gli articoli hanno una vita piuttosto lunga e vengono cercati e letti anche molti anni dopo la pubblicazione. L’articolo più letto in assoluto quest’anno, Usare un Mac con PowerPC oggi è del 2016 e ha un numero di letture che tende a crescere ogni mese. Lo stesso sta succedendo all’articolo più letto pubblicato nel 2018, Ma il Fusion Drive serve ancora?, che ogni mese ha più che raddoppiato il numero di letture rispetto al mese precedente.

Fra le cose che non mi piacciono c’è quella di aver diminuito fortemente la cadenza di pubblicazione dei nuovi articoli, passando dai due articoli a settimana del 2014 a un solo articolo ogni dieci giorni di quest’anno. Sono valori medi, ma riflettono bene la scarsa velocità con la quale riesco a pubblicare nuovo materiale. Non che mi manchino gli spunti e le idee, anzi, quello che mi manca è il tempo per scrivere in pace e poi per rivedere quello che scrivo. In compenso la lunghezza media di ciascun articolo è cresciuta significativamente nel tempo, anche se non so se questa sia una cosa positiva o no.

Altra cosa che non mi piace è il numero di commenti, che si è ridotto anch’esso in modo molto significativo. Dal picco di circa 550 commenti del 2015 si è scesi ad appena 159 nel 2018, nonostante nello stesso periodo di tempo il numero di visitatori sia quasi raddoppiato. Mi piacerebbe che ci fosse maggiore interazione con chi legge il blog, e vorrei anche sapere se posso fare qualcosa per favorire questa interazione.

Copertina di Automate the Boring Stuff with Python

Prima di concludere, un piccolo consiglio di lettura. Ho scoperto da poco il libro Automate the Boring Stuff with Python, che si può leggere gratuitamente sul web o comprare in edizione elettronica o cartacea sul sito della casa editrice o sul solito Amazon. È una vera bomba, ed è pure perfettamente in tema con la serie dedicata al Terminale e allo scripting di questo periodo. Consigliatissimo!

Tagged with: ,
Pubblicato su hardware, musica, programmazione, scienza, società, software, tecnologia
Informativa
Questo sito utilizza cookie di terze parti per inviarti pubblicità e servizi in linea con le tue preferenze. Se vuoi saperne di più o negare il consenso a tutti o ad alcuni cookie, clicca qui. Scorrendo questa pagina, cliccando su un link o su qualunque altro elemento o proseguendo la navigazione in altra maniera, acconsenti all'uso dei cookie.
Follow Melabit on WordPress.com
Categorie
%d blogger hanno fatto clic su Mi Piace per questo: