Riccardo Bernardini

Whoever wrote a research project proposal knows how much unnerving it can be. The actual project description (made of work packages, tasks, deliverable items, ...) has lots of redundancies and cross-references that makes its coherency as frail as a house of cards. For example, if the duration of a task is changed most probably you'll need to update the effort in person-months of the task and of the including work package; you must update the start date of depending tasks and the deliver date of any deliverable items; most probably also the WP efforts and length need update too; not to mention the need of updating all the summary tables (summary of efforts, deliverable, ..) and the GANTT too. Any small changes is likely to start a ripple of updates and the probability of forgetting something and getting an incoherent project description is large. Given the harsh competition in project funding, if your project is incoherent the probability of getting funded is nil.

One day I got sick of this state of affair and I wrote my own project generator: 10k lines of Ada code that reads a non-redundant project description from a simple-format text file and produces a set of files ready to be imported in the proposal, GANNT chart included. The user can specify dependences between different items (e.g., this deliverable is produced at the end of this task, this milestone is reached when this deliverable is available, this task must begin after this other task...) and the program automatically computes all the dates.

Both input parser and output processors are implemented using a plugin structure that makes it easy to write new parsers to read different formats or new output processors to produce output in different formats. Currently a parser for a simple ad-hoc format and an output processor that produces LaTeX files are provided; a new processor based on the template expander protypo is currently being implemented.

Did I eat my own dog food? Well, yes, I did. I used it to write a proposal (still under evaluation) and it served me well.

In this talk I'm going to present Terra Bruciata, an open source initiative aimed to bring hi-integrity techniques in the world of open source with the objectives of (i) providing to the world bug-free software (ii) developing hi-integrity techniques suitable for open source and (iii) showing to the world that bugs are not unavoidable...

Software bugs are everywhere and they brings much harm. History is sprinkled with software horror tales: race condition in radiation therapy machine Therac-25 caused deaths and injuries, badly written automotive software caused unintended acceleration, bugs in the entertainment system allowed an attacker to take remote (full) control of a car, software glitches caused (many times) chaos in the stock market and so on... Unfortunately many think that bugs are like bad weather: annoying, but unavoidable, so that the only solution is to have patience and bear with them.

However, I agree with late Robert Dewar when he says that we should not put up with them. With the future advent of IoT, putting up with glitches it is an open invitation for the Software Apocalypse. Therefore, I decided to start Terra Bruciata, an open source initiative whose goal of is to bring a software correctness mentality in the open source community. We will try to adapt to an open source context procedures and good practices from standards like DO-178 and using techniques such as formal checking. We will initially concentrate on libraries for network protocols. Although this choice can seem strange, it has its rationale. First, network protocols are pervasive nowadays and a bug in a network library can easily become a security hole. Moreover, the IETF has the desire to improve the involvement of open source communities and academia in protocol developments and this initiative could be an interesting channel for that. The initiative just started and as first protocol we choose CoAP, the Constrained Application Protocol, a kind of lo-weight HTTP, developed having in mind small devices IoT-style (yes, it is fashionable...)

Organizing quality software competitions

In this talk we describe an approach for organizing programming competitions that aim to reward software qualities such as readability, maintainability, and so on.

At my university we are considering the idea of organizing a software competition with the objective of promoting, beside programming ingenuity, the production of software of good quality, that is, software that it is easy to read, maintain, modify, debug, ..., Such qualities are, by their own nature, quite "fuzzy" and ill-defined, so measuring them in an objective and quantitative way is not easy. In order to solve this problem we figured out an approach based on a competition between "spoilers" that introduce bugs in the software and "counter-spoilers" that try to debug them. Briefly, each spoiler is given a set of programs and s/he must modify them by introducing bugs, as subtle and difficult to find as s/he can. Each counter-spoiler receives a set of programs and s/he must find the bug(s) in them as fast as s/he can. Finally, every program is given to many different spoilers to get many different spoiled versions.

The competition turns out to be, actually, three competitions in one since we reward

<ul> <li>The best spoiler, that is, the one that introduces the most difficult to find bugs.</li> <li>The best counter-spoiler, that is, the one that is fastest in finding the bugs</li> <li>The best program, that is, the one that is most "resilient" to bug insertion.</li> </ul>

The "untangling" of the times required for debugging into a measure of spoiler, counter-spoiler and program quality is done by using a statistical approach (that we plan to describe in detail in the talk).

The aim of the talk is to describe in detail the technique, stimulate feedback from the community and, also, search for volunteers spoilers and counter-spoilers.

Ada enters into the peer-to-peer world.

Peer-to-peer technologies have became commons nowadays. Initially developed for file sharing, the peer-to-peer approach is moving into the more challenging field of streaming. PPETP is a peer-to-peer streaming protocol, developed at the University of Udine, initially designed for streaming live material to large user communities and evolved with time into an efficient, generic overlay multicast protocol with many built-in features (e.g., signatures, NAT traversal, robustness, priority classes) that make it practical. After few years of development, adjustments and optimizations, PPETP is finally getting ready for its first public release. Its official specs are published as an Internet Draft, while its reference implementation is an open source Ada library (~1.5 Mbyte of source code) designed to be used, in the most common cases, with an interface similar to the well-known BSD socket interface. In this talk, after a brief overview of the most interesting characteristics of PPETP, we will discuss some of the most challenging aspects in its implementation and how Ada was instrumental to solve them.