domenica, luglio 14, 2019

Epoch e il primo passo dell'uomo sulla luna

Epoch è il nome convenzionalmente attribuito all'istante da cui molti sistemi informatici (in pratica, tutti quelli basati o ispirati a UNIX) iniziano a conteggiare il passare del tempo. La data scelta è il primo gennaio 1970 e ad essere conteggiati sono i secondi.

Quando interrogate il sistema per sapere quando è stato modificato un file l'ultima volta, ad esempio con

$ stat -c '%x' testfile 
2019-07-14 09:33:04.977645058 +0200

quello che ottenete in realtà è solo la rappresentazione in formato "umano" del numero memorizzato internamente nel filesystem.

$ stat -c '%X' testfile 
1563089584

Un tempo per la memorizzazione di questo valore si utilizzava una variabile a 32 bit senza segno. Per questo motivo, ancora oggi, la pagina man di stat non indica come ottenere una precisione maggiore. Adesso i bit a disposizione sono molti di più, e consentono la memorizzazione fino al livello dei nanosecondi:

$ stat -c '%.X' testfile 
1563089584,977645058

È interessante notare che nelle primissime versioni di Unix era stato scelto di utilizzare i numeri interi non per contare i secondi, ma i sessantesimi di secondo (questo perché ci si basava su oscilloscopi a 60 Hz). Si era nel 1971, e con 32 bit si potevano in questo modo rappresentare solo 828 giorni e mezzo circa, per cui fu deciso all'epoca (scusate il bisticcio di parole) di impostare epoch al 1 gennaio 1971. Solo successivamente fu cambiata l'impostazione e si passò alla memorizzazione dei secondi utilizzando il 1 gennaio 1970 come riferimento di base.

Capisco i motivi pratici della scelta, ma pensate a quanto sarebbe bello, ancora oggi, se fosse stato scelto come riferimento il primo passo dell'uomo sulla Luna, avvenuto pochi mesi (14.159.025 secondi, per la precisione) prima, alle 2:56:15 UTC del 21 luglio 1969.

$ date -d '@-14159025'
lun 21 lug 1969, 04.56.15, CEST


$ date -u -d '@-14159025'
lun 21 lug 1969, 02.56.15, UTC





lunedì, novembre 05, 2018

Slug

Tra le tante parole dell'informatica che sono difficili da tradurre in italiano e — da quello che vedo — anche in altre lingue, c'è «slug».

Lo slug è la parte di URL che identifica univocamente un post di un blog o, in generale, un articolo o una pagina web.

Ad esempio, un articolo intitolato "Darwin e l'evoluzione" potrebbe avere come slug darwin-e-l-evoluzione, parte di un URL come

https://www.example.com/articoli/darwin-e-l-evoluzione

Tipicamente, lo slug contiene solo caratteri minuscoli dell'alfabeto inglese, e i vari segni di punteggiatura, compresi gli spazi, sono trasformati in trattini semplici. Eventuali caratteri con segni diacritici potrebbero essere trasformati nel carattere semplice più simile: ad esempio, "Perché lo studio di Darwin è importante" potrebbe avere come slug perche-lo-studio-di-darwin-e-importante.

Spesso ad occuparsi della generazione dello slug per un articolo è il Content Management System in uso, che al momento della pubblicazione di un articolo propone un determinato valore, poi modificabile dall'autore dell'articolo o dal webmaster.

Per molti linguaggi di programmazione esistono infatti delle funzioni che producono lo slug a partire da una stringa di testo. Al momento in cui scrivo, una ricerca su GitHub mostra 286 risultati per slugify e 1247 per sluggable.

A volte, le funzioni che si occupano di proporre uno slug tengono anche in considerazione l'esigenza di evitare duplicati, aggiungendo un suffisso numerico appropriato, come in un ipotetico darwin-e-l-evoluzione-2 per un secondo articolo intitolato "Darwin e l'evoluzione".

Ma che cosa significa la parola inglese "slug"? Una ricerca su WordReference porta a risultati che nulla sembra abbiano a che fare con il nostro argomento: lumacone, proiettile, pallottola, sorsata, sorso. C'è però un riferimento a una "slug area", termine usato in editoria come "part of a page reserved for printed information".

Su Wikipedia si parla di slug nella pagina inglese dedicata agli URL "puliti", dove si trova un'informazione interessante: a quanto pare, il nome è basato sull'uso che la parola "slug" ha nel mondo editoriale, nel quale indica un nome breve assegnato per uso interno ad un articolo.

Nella pagina di Wikipedia relativa al concetto di slug nell'editoria si ottiene qualche informazione in più: una storia verrebbe etichettata con uno slug durante il processo editoriale che la porta dalla scrittura da parte del reporter alla pubblicazione. Lo slug, secondo quanto previsto dallla guida di stile dell'Associated Press, dovrebbe indicare con una o più parole chiave i contenuti della storia raccontata (a volte con l'aggiunta di codici specifici, come "AM" per indicare che essa va pubblicata nell'edizione del mattino o "CX" per dire che serve a rettificare una storia pubblicata precedentemente).

L'etimologia della parola slug in questo contesto deriva dall'uso della parola slug che era utilizzata per esprimere, nel campo della tipografia con caratteri di piombo, una riga di caratteri.

Interessante il fatto che dal sostantivo slug si sia prodotto il verbo to slugify ma l'aggettivo sluggable e non *slugifiable.

Resta il problema di come eventualmente tradurre il termine in italiano. Da quello che si vede in giro, come spesso accade, la scelta migliore sembrerebbe di utilizzare la parola inglese.

martedì, luglio 03, 2018

"Prossima apertura" secondo Google Translate

Sono molto frequenti i cartelli in cui si informa la potenziale clientela che si sta preparando un nuovo locale, un nuovo negozio, ecc.

Un tempo cartelli di questo genere recavano la scritta "prossima apertura", ma visto che dirlo in italiano pare evidentemente brutto, recentemente ci si è buttati sull'inglese o, meglio, sull'inglese farlocco. Si veda questo cartello apparso recentemente nella mia città, in cui compare la scritta "next opening" al posto del corretto "opening soon":


Mi chiedo se l'autore si sia ispirato ad esempi sbagliati di altri, anche illustri, oppure si sia fidato di quanto ottenuto dando in pasto l'espressione a Google Translate, che incoraggia a fidarsi di quanto proposto con un contrassegno di qualità accompagnato dalla scritta "Questa traduzione è stata controllata dalla Community di Google Traduttore"...


mercoledì, febbraio 03, 2016

L'importanza dei titoli

Il Sole 24 Ore ha pubblicato recentemente un articolo di Massimo Chiaratti intitolato «I (falsi) miti più comuni di bitcoin e della valute virtuali».

Il primo mito sfatato è che "Bitcoin non è sicuro". Si tratta di un mito, appunto. Come giustamente spiega Chiaratti, infatti, «con la sufficiente attenzione è possibile proteggere i propri bitcoin in maniera anche più efficace di quanto non sia possibile con gli strumenti di pagamento a cui siamo abituati.»

Il problema è che il titolo della pagina web, che compare bene in evidenza nella barra principale del browser, e che assume particolare importanza quando i documenti vengono indicizzati e presentati dai motori di ricerca, sembra affermare esattamente il contrario, visto che è esattamente «Bitcoin non è sicuro»:


Con buona probabilità, il titolo della pagina è stato generato automaticamente in base alle prime parole dell'articolo, e non è stato controllato accuratamente. Può succedere, ma è una cosa a cui è necessario prestare attenzione per evitare effetti indesiderati.
L'errore è presente in tutte le pagine successive: Bitcoin è anonimo, Bitcoin non è una moneta, ecc.
Sarebbe sufficiente aggiungere (almeno nel titolo della pagina, visto che se uno legge l'articolo risulta chiaro) che si tratta di un mito sfatato: «Mito sfatato: Bitcoin non è sicuro», ad esempio, sarebbe senz'altro più corretto.


giovedì, gennaio 07, 2016

Google e le ricerche di documenti in formato OpenDocument


LibreOffice cresce, e i documenti presenti "nella nuvola" sono sempre più svincolati dal monopolio di Microsoft. Bisognerebbe farlo sapere a Google, che nella propria pagina per la ricerca avanzata non propone i formati OpenDocument tra quelli presenti nella lista del tipo di file:


Strano, a dire il vero, anche perché la ricerca dei documenti LibreOffice e OpenOffice in realtà è supportata. È sufficiente aggiungere nella query di ricerca il parametro filetype:odt (oppure ods, odp, ecc.):


Basterebbe poco per cambiare l'interfaccia utente...



Licenza Creative Commons
Google e le ricerche di documenti in formato OpenDocument di Loris Tissino è distribuito con Licenza Creative Commons Attribuzione 4.0 Internazionale.

lunedì, novembre 09, 2015

Creative Commons, e se l'autore cambia idea?

Per chi se la fosse persa e fosse a digiuno di informazioni in merito alle licenze Creative Commons, segnalo l'interessante videolezione di Simone Aliprandi nell'ambito del progetto AndriaLearning curato da Francesco Leonetti.

Credo che alla trattazione manchi un punto fondamentale, quello delle variazioni dei dati nel corso della storia. Mi spiego con un esempio.

Immaginiamo che Tizio pubblichi nel 2015 un'opera nel suo sito web, attribuendo una licenza CC Share-Alike. Caio utilizza quest'opera, ne crea una derivata dopo aver consultato la licenza che lo autorizza, e la pubblica nel proprio sito web nel 2016. Fin qui, tutto bene.

Ma che cosa succede se Tizio, nel 2017, toglie dal proprio sito il riferimento alla licenza CC precedentemente applicata? Naturalmente, il comportamento sarebbe riprovevole ma non illecito (la licenza su un'opera può essere revocata, ma le opere già in circolazione rimangono con la licenza originaria); e comunque è tecnicamente fattibile. Se si tratta di un'opera che ha avuto una certa diffusione e che molti possono testimoniare di aver visto come rilasciata con licenza CC Share-Alike, nessun problema. Però immaginiamoci il caso in cui Tizio sia un autore poco noto, e che solo Caio abbia scaricato e utilizzato la sua opera. Come può fare Caio, nel 2018, a dimostrare che Tizio nel 2015 aveva pubblicato l'opera con una determinata licenza?

Il punto è che il web è stato pensato per essere costantemente aggiornato e modificabile e ciò comporta problemi non irrilevanti. Come fare, in generale, a provare che un certo contenuto, in un dato momento, era quello indicato? Una soluzione potrebbe essere quella di utilizzare servizi come archive.org o perma.cc, ma anche questi lasciano un po' a desiderare. Per dirne una, rimane il problema che ad uno stesso indirizzo di risorsa su web potrebbero corrispondere contenuti diversi a seconda di provenienza geografica della richiesta, lingua preferita nel browser, dimensioni e risoluzione dello schermo, ecc. Potrebbe ben succedere che il link ad una licenza (così come qualsiasi altro contenuto) compaia o scompaia anche a seconda del dispositivo usato per la lettura. Quindi Caio potrebbe vedere con lo smartphone che il contenuto di Tizio è rilasciato con licenza CC, mentre un'altra persona (o un servizio di archiviazione digitale automatico), anche nello stesso istante, potrebbe avere un'informazione diversa.

Insomma, possono insorgere problemi dovuti alla natura tecnica del web e al fatto che ciò che vediamo è cambiato, e non tutti i siti hanno, come Wikipedia, traccia di tutte le modifiche apportate ai contenuti. Anzi, quasi sempre queste informazioni non esistono. E l'onere della prova rimane comunque in capo a chi riutilizza l'opera.

Per completezza, riporto quanto Simone Aliprandi ha scritto nel suo libro Creative Commons: manuale operativo:
... l'utente che trova un'opera con il richiamo ad una licenza, la può riutilizzare facendo affidamento sul fatto che tale richiamo sia stato effettivamente apposto dal titolare dei diritti. Purtroppo, la comunicazione Internet non permette di tenere traccia di ogni passaggio e dunque può verificarsi la malaugurata ipotesi che il titolare dei diritti non voglia affatto rilasciare la sua opera con Creative Commons e che quindi la licenza sia stata aggiunta (in buona fede o in mala fede) da un altro soggetto non titolato a farlo.
Si tratta in verità di un caso abbastanza limite; e la dottrina giuridica comunque risolve i dilemma applicando la teoria dell'affidamento. Secondo questa teoria, un negozio giuridico è valido se vi è contrasto tra volontà e dichiarazione ma colui che riceve la dichiarazione non era in grado di accorgersi del contrasto usando l'ordinaria diligenza. 

Post modificato dopo la pubblicazione originale.

Licenza Creative Commons
Creative Commons, e se l'autore cambia idea? di Loris Tissino è distribuito con Licenza Creative Commons Attribuzione 4.0 Internazionale.

mercoledì, febbraio 18, 2015

Copia di cortesia, conforme o no?

Il recente post di Simone Aliprandi sul tema della richiesta, in alcuni tribunali, di una copia di cortesia, cartacea, di documenti consegnati on-line mi ha fatto tornare in mente una problematica che ho affrontato anni fa in tutt'altro ambito.

Il problema, ora come allora, deriva dal fatto che qualcuno (un privato, una controparte commerciale, un ente pubblico, un'istituzione: non fa differenza) chiede un documento in forma digitale, ma poi lo richiede, per propria semplicità di fruizione e di gestione, anche in forma stampata.

Immaginate un insegnante che chiede ai propri allievi di inviare il testo del compito sia via email sia consegnandone una versione cartacea; oppure l'ufficio tecnico di un comune che chiede una copia del progetto in forma di file vettoriale e una in versione stampata; oppure, come nel caso segnalato, un magistrato che, dovendo adeguarsi al nuovo processo telematico che impone la gestione degli atti tramite, appunto, l'invio telematico degli stessi, pensa bene di chiedere agli avvocati di depositare anche una copia di cortesia.

In tutti questi casi, si pone il problema del se e del come controllare la conformità dei due documenti che uno poi si trova in mano.

Che cosa succede, infatti, se un giudice decide in una causa alla luce di quanto trova stampato in un documento, e la copia cartacea dello stesso è diversa da quella depositata digitalmente? se il progetto per un nuovo edificio viene approvato in base a quanto l'impiegato vede nella versione cartacea dello stesso, con informazioni diverse rispetto a quelle presenti nel file inviato digitalmente? se l'insegnante mette un voto in base a quanto trova scritto nel documento inviato via email (giusto per fare l'esempio opposto) ma poi archivia quello ottenuto in versione cartacea?

Voglio trascurare qui il caso di chi - intenzionalmente e fraudolentemente - consegna due documenti diversi in una forma e nell'altra. La domanda piuttosto è: potrebbe succedere che, per mero errore materiale, le due copie non coincidano, oppure non appaiano allo stesso modo? La mia risposta è: certo. Alcuni casi plausibili, tutti con alla base comportamenti in piena buona fede, potrebbero essere i seguenti:

  • Tizio ha nel disco del computer due documenti, diciamo DocumentoA_versione1.pdf e DocumentoA_versione2.pdf. Invia telematicamente il primo e stampa, alcuni minuti dopo, il secondo.
  • Tizio sta lavorando su DocumentoA_versione_finale.odt. Il documento è ancora aperto e con alcune piccole modifiche non ancora salvate. Tizio non se ne accorge, effettua l'invio telematico, poi salva il documento con le modifiche e lo stampa.
  • Tizio sta lavorando su DocumentoA_versione_finale.odt. Stampa il documento, si accorge di qualche piccolo errore di battitura (un accento sbagliato, una virgola mancante), corregge il documento e invia telematicamente la versione corretta.
  • Il documento che Tizio sta guardando con il proprio calcolatore è una pagina web. La stampa. Poi salva la pagina web su disco, senza sapere che nelle pagine web è possibile (molto spesso accade) fare in modo che alcune parti vengano visualizzate o meno a seconda che lo strumento di fruizione sia una stampante o uno schermo.  
  • Il documento che Tizio ha sotto gli occhi è un file PDF, in cui tutto il testo è selezionabile / visibile / copiabile / elaborabile, anche quello con una pecetta nera che copre alcune scritte. Stampandolo, quelle scritte rimangono nere, perse per sempre. (Forse qualcuno si ricorda del caso del documento CIA declassificato dai lettori?)
  • Il documento PDF che Tizio ha sotto gli occhi contiene un'immagine posta sul bordo del foglio, con un particolare molto importante proprio vicino all'estremità della pagina. Nella versione stampata, consegnata a Caio, quel dettaglio manca, perché la stampante ha un margine di uno o due centimetri in cui non riesce a stampare. Caio vedrà il dettaglio o no? (I file PDF possono presentare molti altri problemi, ad esempio in caso di risoluzione non adeguata alla stampa, colori non adatti, font non incorporati, ecc.)
  • Il documento di Tizio ha qualche forma di intelligenza che lo rende diverso ogni volta che viene aperto. Non ci vuole granché: basta una formula di un foglio elettronico che si basi sul valore di ADESSO() o un piè di pagina di un documento che riporta la data corrente. Chi aprirà il documento si troverà qualcosa di diverso rispetto alla versione stampata.
  • Tizio invia un documento in forma telematica a Caio, e poi gli consegna anche una versione cartacea. Caio non considera la copia cartacea e legge il documento inviatogli digitalmente, dove però, in forma di revisione non cancellata, compare del testo non presente nel documento stampato. Tizio si lamenta quando scopre che Caio ha letto delle informazioni che nella versione cartacea non c'erano.

Tutti questi sono casi perfettamente plausibili di mancanza di conformità tra il documento in formato digitale e quello stampato. Quale dei due dovrebbe avere valore probatorio / legale?

Licenza Creative Commons
Copia di cortesia, conforme o no? di Loris Tissino è distribuito con Licenza Creative Commons Attribuzione 4.0 Internazionale.