Crypto-Gram, April 2016 (in EPUB and MOBI format)


Crypto-Gram is a famous free monthly newsletter written by the security expert Bruce Schneier. The original is available at Bruce Schneier’s website; this is the same content in MOBI and EPUB format, suitable for e-book readers.


Posted in cryptogram, ebook, english | Tagged , , , , , | Leave a comment

Crypto-Gram, April 2016 (in EPUB and MOBI format)


Crypto-Gram is a famous free monthly newsletter written by the security expert Bruce Schneier. The original is available at Bruce Schneier’s website; this is the same content in MOBI and EPUB format, suitable for e-book readers.


Posted in cryptogram, ebook, english | Tagged , , , , , | Leave a comment

Crypto-Gram, March 2016 (in EPUB and MOBI format)


Crypto-Gram is a famous free monthly newsletter written by the security expert Bruce Schneier. The original is available at Bruce Schneier’s website; this is the same content in MOBI and EPUB format, suitable for e-book readers.


Posted in cryptogram, ebook, english | Tagged , , , , , | Leave a comment

Playing around with strace


From the strace manpage: “strace is a useful diagnostic, instructional, and debugging tool”.

Thanks to strace it’s possible to check what a program is doing by looking at the system calls that it makes. As a simple example, let’s compare what happens when running two “Hello, world!”, respectively with PHP and with Python.

The source codes of the two programs are the following:

print "Ciao"


echo "Ciao\n";

Let’s run them via strace:

$ strace -o py.txt python
$ strace -o php.txt php ciao.php

Both programs will write “Ciao” in the console and terminate. As a side effect, strace will record every syscall made by both programs in the respective output files. Let’s peek at the strace logs to compare what happens when running the two toy scripts.

Everything begins from an execve call, that starts the interpreter:

execve("/usr/bin/php", ["php", "ciao.php"], [/* 59 vars */]) = 0
execve("/usr/bin/python", ["python", ""], [/* 59 vars */]) = 0

Right after, the flow goes ahead by loading the shared libraries required by each interpreter. For example, php loads a shared library like this:

open("/lib/x86_64-linux-gnu/", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\360\35\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=104824, ...}) = 0
mmap(NULL, 2199880, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f9c4e3db000
mprotect(0x7f9c4e3f4000, 2093056, PROT_NONE) = 0
mmap(0x7f9c4e5f3000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x18000) = 0x7f9c4e5f3000

As you can see, the shared library file’s content (in ELF format, can you see the header?) the is read and loaded in memory.

Python does more or less the same:

open("/lib/x86_64-linux-gnu/", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\340`\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=142080, ...}) = 0
mmap(NULL, 2217232, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f8a44489000
mprotect(0x7f8a444a1000, 2097152, PROT_NONE) = 0
mmap(0x7f8a446a1000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x18000) = 0x7f8a446a1000
mmap(0x7f8a446a3000, 13584, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f8a446a3000

Most of the syscalls are about loading the shared libraries. Both PHP and Python load the shared libraries linked to their executables. After that, other shared libraries are loaded:

  1. For PHP, the PHP extensions configured in the php.ini are loaded, and for each extensions, the shared libraries that it depends upon.
  2. Python scans the PYTHONPATH and loads some shared libraries located in there.

After the shared libraries galore, the script file to be run is loaded in memory:

open("ciao.php", O_RDONLY) = 4
fstat(4, {st_mode=S_IFREG|0664, st_size=21, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f9c4e815000
read(4, "
open("", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0664, st_size=13, ...}) = 0
Inappropriate ioctl for device)
lseek(3, 0, SEEK_CUR) = 0
fstat(3, {st_mode=S_IFREG|0664, st_size=13, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f8a448c7000
read(3, "print \"Ciao\"\n", 4096)

As you can see, apparently both PHP and Python read their scripts by chunks of 4k each.

The interpreter can now execute the program text. Both PHP and Python ultimately, after approximately 1000 syscalls, end up doing exactly the same write operation:

write(1, "Ciao\n", 5)

This can be read as: write to the standard output (file descriptor no. 1) the string “Ciao\n” (the “\n” is explicit in the PHP echo and implicit in python’s print), which is 5 characters long.

And that’s it!

strace’s output can be quite dense (there are a lot of options to filter it – or to make it denser), but it’s incredibly useful to quickly see what happens when running a program (it can also be used to inspect already running programs, just by specifying the desired process-id). It’s surely worth to have it in your toolbelt.:-)

Posted in english, linux | Tagged , , , , , | Leave a comment

Crypto-Gram, February 2016 (in EPUB and MOBI format)


Crypto-Gram is a famous free monthly newsletter written by the security expert Bruce Schneier. The original is available at Bruce Schneier’s website; this is the same content in MOBI and EPUB format, suitable for e-book readers.


Posted in cryptogram, ebook, english | Tagged , , , , , | Leave a comment

The physics of software


Published on Ingenium n. 102, April-May 2015
Journal of the Terni’s Order of Engineers
(Cineca-MIUR n. E203872)

Software engineering is a young discipline, with solid scientific basis in several fields of mathematics and in some fields that pertain strictly to computer science (e.g. relational database theory and compiler theory). Still, software engineering is a fertile ground for “snake oil salesmen”: when facing a problem to be solved it’s easy to find scores of experts (gurus, mentors) that promote the fashion-du-jour as the definitive panacea.

The comparison with other engineering disciplines is depressing. In civil engineering, for example, the materials and their shape are (or should be) chosen on the basis of a solid corpus of scientific knowledge: the forces that the structures will need to face and the different properties of materials (e.g. elasticity), that describe their behavior in reaction to such forces. Is it better iron or an alloy of iron, carbon and chromium? The correct answer is that that the question is ill-posed, it depends on the problem at hand! But if you ask a sample of (more or less aware) software engineering practitioners and ask them: is it better functional programming or object oriented programming? Is it better Java or C#? Rest assured that you will almost always get sharp and heartfelt answers: for the most part, nowadays, software engineering is nothing more than a rhetoric exercise, while an argument about the material and the shape to be used in a physical construction can be resolved without endless debates just by the accurate usage of physics and material science. If we consider the laws of physics, in fact, it would be pointless to build an house by using glass only (“it’s brighter!”) or bricks only (“it’s stronger!”): the usefulness of the materials depends on the context. And yet, while developing software, this happens often: we build an “house” by using “bricks” only, or by using “glass” only.

From several years Carlo Pescio, a well-known Italian software engineering professional, is trying to create a basic theory that he named “physics of software”: the software is considered as a material, while the software design (at every level) is considered as the process of shaping the software/material in the most appropriate way to solve the problem at hand. If we adopt this point of view, and we try to draw an analogy with material sciences, we must ask ourselves: what do we know about the software/material properties and about the “forces” that it must withstand? Not much, so far. In the software engineering knowledge body we mostly find:

  • Principles and methods: more or less dogmatic practices, stripped out of their original context and risen to the rank of principles; the process of stripping the context away makes such principles ill-defined and/or superfluous.

  • Patterns and reference designs: catalogs of design techniques to solve specific problems.

  • Metrics: software properties that can be measured more or less easily, but whose clarity and usefulness in the software design process are rather questionable. They may look similar to the aforementioned material’s properties, but they are not defined as a direct reaction to specific “forces”.

  • -ilities: reliability, scalability, maintainability etc. At first glance they may look like the aforementioned physical material’s properties, but they are fundamentally different: their definition is too generic (they are not defined as reactions to “forces”), so they cannot be measured in a meaningful way. Saying that a software is “scalable” is more like saying that a car is “safe”, but it’s completely different from describing the resistance of a metal alloy to a compression force.

In other words, while the analogy “software”/”material” and “software design”/”material shaping” is very clear, we still don’t have any idea about the software properties and about the “forces” that determine such properties. In his work about the “physics of software”, Carlo Pescio tries to explore this aspects, by defining something that we can call a “basic physics” for the software: a theory of software properties and forces.

Don’t let the metaphor mislead you, though, because the software’s nature is rather peculiar: software is executable knowledge, designed to be interpreted both by humans, that write and read programs, and by computers, that must run them to obtain the desired results. So, even if the physics of materials was the inspiration for this research, the model that Carlo Pescio is building looks more like quantum physics.

Currently, his “physical” software model is based on two main concepts:

  1. The software exists in three spaces: the decision space (the design’s product), the artifact space (the coding’s product) and the run-time space (the product of the program’s execution by a computer).
  2. The concept of “entanglement“, borrowed directly from quantum physics. The entanglement is a link between components that, with different modes of interaction, characterizes software in each of the three aforementioned spaces.

By starting from these two concepts, plus a few other basic ones, it is possible to derive most of principles and patterns that are the current written and spoken tradition of software engineering.

Carlo Pescio’s research on the “physics of software” is documented on the website From some time the author has taken a pause from publishing his ideas, also because of their poor reception (it cannot be otherwise, in a world filled by the background noise of gurus and mentors, remember?). Still, his research is essential for the evolution of software engineering: the results that he published on his website are a great starting point to meditate deeply about the nature of software engineering. Let’s hope that we can read the next chapters soon!

Posted in coding, english, my writings | Tagged , , , , | Leave a comment

La fisica del software


Pubblicato su Ingenium n. 102, aprile-maggio 2015
Periodico di informazione dell’Ordine degli Ingegneri della provincia di Terni
(Cineca-MIUR n. E203872)

L’ingegneria del software è una disciplina molto giovane, che può vantare solide basi scientifiche in alcune branche della matematica e in alcuni ambiti di conoscenze prettamente informatiche assai formalizzati e ben compresi (es. la teoria delle basi di dati relazionali e la teoria dei compilatori). Tuttavia l’intero settore è ancora in balia dei venditori di “olio di serpente”: di fronte ad un problema da risolvere è inevitabile trovare schiere di esperti (guru, santoni, ecc.) che promuovono le mode del momento come panacea d’ogni male.

Il confronto con le altre discipline ingegneristiche è spesso impietoso. Nelle opere di ingegneria civile, ad esempio, i materiali e le forme che essi assumono vengono (o dovrebbero essere) scelti sulla base di solide conoscenze scientifiche: si prendono in considerazione le sollecitazioni (forze) a cui si prevede che le strutture saranno sottoposte e le diverse proprietà dei materiali (es. elasticità), che descrivono il loro comportamento quando subiscono l’azione di tali forze. È meglio il ferro o una lega di ferro, carbonio e cromo? La risposta corretta è che la domanda è mal posta, dipende dal problema che si vuole risolvere! Tuttavia, provate a prendere un campione di praticanti (più o meno consapevoli) dell’ingegneria del software e chiedete loro: è meglio la programmazione funzionale o quella ad oggetti? È meglio Java o C#? State sicuri che riceverete quasi sempre risposte nette ed accorate: attualmente buona parte dell’ingegneria del software è poco più di un esercizio di retorica, laddove una discussione sul materiale e sulla forma da usare in una costruzione può essere risolta senza dibattiti infiniti, grazie all’uso puntuale della fisica e delle scienze dei materiali. Considerando la fisica di base, infatti, sarebbe ridicolo fare una casa interamente in vetro (così è più luminosa!) o interamente in mattoni (così è più solida!): a seconda del contesto si sceglie il materiale più adatto. Eppure, nello sviluppo di un software, spesso accade questo: si costruisce una “casa” interamente in “mattoni” o interamente in “vetro”.

Da diversi anni Carlo Pescio, un noto professionista italiano nel settore dell’ingegneria del software, sta cercando di creare una teoria di base che ha definito “fisica del software”: il software è visto come un materiale, mentre la progettazione del software (ad ogni livello) è vista come l’atto di dare al software/materiale la forma più adatta a risolvere un dato problema. Partendo da questo punto di vista, e cercando di fare un parallelo con le scienze dei materiali, bisogna chiedersi: quali sono le nostre conoscenze delle proprietà del software/materiale e delle “forze” a cui viene sottoposto? Non molte, finora. Nel corpus di conoscenze dell’ingegneria del software troviamo per lo più:

  • Principi e metodi: pratiche più o meno dogmatiche che vengono decontestualizzate e assurte al rango di principi, risultando perciò mal definite e ridondanti.

  • Pattern e architetture di riferimento: cataloghi di tecniche progettuali per risolvere determinati problemi.

  • Metriche: proprietà più o meno facilmente misurabili relative al software, che tuttavia non sono di immediata comprensione o di diretta utilità al processo di progettazione del software. A differenza delle proprietà dei materiali, non sono definite come risposta a delle sollecitazioni determinate da forze precise.

  • -ilità: affidabilità, scalabilità, manutenibilità ecc. A prima vista potrebbero sembrare delle proprietà, simili a quelle dei materiali fisici, tuttavia non lo sono in quanto definite troppo genericamente (anche qui manca la definizione delle sollecitazioni a cui si riferiscono) e per questo difficilmente misurabili. Dire che un software è “scalabile” è più simile a dire che una macchina è “sicura” piuttosto che a descrivere la resistenza di una lega metallica alla compressione.

In altre parole, sebbene il parallelo tra software e materiali e quello tra progettazione software e lavorazione dei materiali sia lampante, non abbiamo ancora alcuna conoscenza relativa alle proprietà del software e alle “forze” a cui viene sottoposto. L’opera di Carlo Pescio cerca di esplorare questi aspetti, definendo quella che effettivamente possiamo chiamare una “fisica di base” per il software: una teoria delle proprietà del software e delle forze a cui viene sottoposto.

Ovviamente la metafora non deve fuorviare, la natura del software è assai peculiare: il software è conoscenza eseguibile, fatta per essere interpretata sia dall’essere umano, che legge e scrive i programmi, sia dal computer, che deve eseguirli per ottenere il risultato desiderato. Perciò, nonostante la fisica dei materiali abbia fornito l’ispirazione per quest’opera, il modello delineato da Carlo Pescio ha finito per somigliare alla fisica quantistica, piuttosto che a quella dei materiali.

Attualmente il suo modello “fisico” per il software è incentrato su due concetti principali:

  1. La distinzione dei tre spazi in cui il software esiste: lo spazio delle decisioni, ovvero il prodotto della progettazione, lo spazio degli artefatti, ovvero il prodotto della scrittura del programma, e lo spazio dell’esecuzione, ovvero ciò che accade quando un programma viene eseguito da un computer.

  2. Il concetto di “entanglement”, mutuato direttamente dalla fisica quantistica. L’entanglement è un collegamento tra componenti che, con diverse modalità, caratterizza il software in tutti e tre gli spazi descritti al punto precedente.

Sulla base di questi e pochi altri concetti di base è possibile ricavare buona parte dei principi e dei pattern che costituiscono la tradizione scritta e orale che è attualmente alla base dell’ingegneria del software.

La ricerca di Carlo Pescio sulla “fisica del software” è raccolta sul sito Da qualche tempo l’autore ha deciso di prendersi una pausa dalle pubblicazioni sull’argomento, anche a causa dello scarso appeal che le sue idee hanno avuto (e come potrebbero averne, in un mondo pieno del rumore di fondo generato guru e santoni, ricordate?). Tuttavia la sua ricerca è fondamentale per l’evoluzione dell’ingegneria del software: i risultati raccolti sul suo sito sono un ottimo punto di partenza per riflettere in profondità sulla natura della disciplina. Speriamo di leggerne presto il seguito!

Posted in coding, italian, my writings | Tagged , , , , | Leave a comment