 So Bernadini, and he's talking about Terra Bruziata. Thank you. It doesn't matter. Okay. So, did you hear the news? Some researchers out and don't remember which university discovered that software has bags. They will get the novel for the obvious things. I guess you are not surprised, but I think that you should be. You see, four years ago Robert Dewar wrote this article that you can find on the network about why we shouldn't put with software glitches. In this article he points out that we accept in software a quality that is usually much lower than the quality we accept with our staff, say cars, TV or microwave ovens. Why is that? Well, he says, and I agree with him, that the problem is mostly cultural, and it's nicely summarized in this slide. Buds are like bad weather, annoying, but you know the fact of life. And since they are annoying, but the fact of life, people accept them. You will not accept a car that suddenly stops in the middle of the road, but you accept a software that gives you a blue screen over there. Yes, it's annoying, but you know, there is a turnaround, and what can you do? This is usually my reaction. Okay, usually I'm not that aggressive, but more or less the idea is that blue guy here made two mistakes. First, the word annoying. Buds are not annoying. They are dangerous. When I started making this presentation, I researched a while in the net for bugs that had some serious consequences. And the situation is pretty scary. This is just an exception of maybe the worst one. I guess, in my opinion, the scarst, sorry, the scarst one is the first one. Thermak, Terak 25, a machine for radiotherapy. If the user acted too fast on the interface, the graphical interface, a risk condition kased a excessive dose of radiation to the parts. And look at the Wikipedia entry. The entire description is pretty scary. Second one, I guess it's the third in that list, an intended acceleration that was a bit controversial. The car maker said that the user was making mistakes, pressing the accelerator on the side of the brake. Then it was the method that stopped the accelerator, but in the end it seems that it was a memory corruption that caused the throttle of the accelerator, stuck, full open. OK, I understand, I understand. As an Italian commercial says, ti piace v incere facile. That is, you like an easy win. You did some kind of cherry picking, you did. I mean, you choose a medical device, you choose a car. Those are serious stuff, dangerous stuff, and an error in a car is dangerous. OK, but what about, say, a music player? What does that mean? What kind of harm can you get from a bug in a music player? OK, please enter the last bug in 2015. Two researchers demonstrated that it was possible to take full control of a car by going through the entertainment system. The entertainment system was bugged, they hacked that, and it was connected to the bus of the car. They were able to control everything, wheel, accelerator, brakes. And the last one, it was in 2016, it was a wave of Daniel's service attack done by, sorry, done via some IP cameras. The worst one, it was an attack that sent a tsunami of data of one terabit per second to don't remember the target. And so the message, especially in the two last cases, is this. Even if your device is harmless, a player, a camera, a bug there can be dangerous, too, because it can trigger some small series of stuff and it can be used as a way to attack something. That is especially important now that the Internet of Things is getting fashionable. And this explains the strange video at the beginning. How can a tool brush bring down the poor grid? Well, it's easy. You have a tool brush connected to the Internet. They exist. There is a big brand that is selling them. Don't ask why. I cannot understand why you could want your tool brush connected to the Internet, but they exist. If they had a bug, they could be enrolled for a Daniel's service to say the power grid, the stock market or whatever. So, sorry, too fast. So, at this point one could say, OK, OK, OK, you sold your point. Bug are dangerous, are serious stuff, but they are unavoidable. So, they are not really like bad weather, but like more meteors, dangerous, but you know, you hope that it never happen. And maybe you can have some kind of passive defense through backups or build shelters in case of meteor strikes. Actually, having the word unavoidable, OK. And the fact that this idea is changing is reflected here. This is in piece of news about a bill that was proposed in US in order to secure the Internet of Things. So, they recognize that the bugs here can be dangerous. And look what they do. They ask that the software is patchable. They are not asking for software that works. They are asking for software that can be patched because the basic idea here is that bugs are matter of life. And even this is not true. The user, according to example, is a bionics. 737 has 7-8 millions line code. How many lines of code flew over our heads so far? And there is not a single incident that brought to a death of someone due to the software. So, yes, the user's lecture is, OK, it's possible to write good software, it's expensive, it's time-consuming. And since it's time-consuming, we cannot do that because we need to be fast, fast, fast to get to the market. To counter-objection. First, that's not an excuse. There is my life at stake. So, if it's expensive, too bad, sorry for you, but you are going to write good software. It seems that it's not really so expensive as many believes. Talking with someone who works with the O178, that's the certification standard for software running on planes, I was told that if you do the things correctly, and that's a big if, that is, if you think your process in order to complain with that standard and do not try to do the standard of your process, the increase on a plane is more or less maybe 45%, not 200, like sometimes you hear. OK, 50% is not negligible. But it's not even so huge. So, OK, good software can be written. It's important that it's written, but nobody does that. What are you going to do? What am I going to do? Welcome to Terra Bruciata. Terra Bruciata is the Italian expression for scorched earth, that strategy where you burn everything so your enemy has no resources. And the idea is to burn the ground around the bugs so they have no more place to hide. More precisely, my vision, as your PHB would say, is to bring process, tools, ideas from the high integrity software context into the open source software context. It will not be easy. The high integrity staff was born in industry environment. So, for example, the O178 was born in industry environment. And in industry you have a hierarchy with your boss. Your boss say, starting for tomorrow, we are going to do this way. You say, why? Because of the boss. And say so. If you don't do this way, you are fired. Maybe many management book would not suggest this strategy, but it will work. In open source, of course, you cannot do this way. In open source community runs mostly by volunteers in a distributed way, so it's a different environment. And try to adapt something born in industry environment to this one, maybe it's a bit challenging, but we can try it. Why? What I think to achieve? Well, three objectives. The first one maybe is the most obvious, but not the most important, to produce better software, which is something that is good itself. But the second objective is to make an example and show other people that this is possible. I hope to attract to this idea other open source communities, but also I think that it will be important, let me say this, to let know everyone that writing good software is important and possible. Even without being a software house that works for Airbus or Boeing. This should be known not only to taking people like us, not only to your C-suite, but to everyone. Because what we want is a kind of market pressure. People must get enraged when the game is the blue screen of death. And finally, an interesting side effort is that we, most probably, we need to develop processes, tools and way to use some sophisticated tools like formal checking in open source context. And this experience, these tools could be used by other developers, open source or not, to help producing better software. So this is not really, let's say that the main objective is the second one. The first and the third are nice side effects. So I told you about the why bugs are serious stuff. The what. I want people to write, sorry, the why bugs are serious stuff. The what. I want to distribute to promote an idea of current software. Remember that Robert, you are saying that the problem is cultural. We are trying to address the root of the problem. And now, let's talk a bit about the how. So what kind of software we are going to develop? Maybe it was to start with something quite peculiar that is libraries for little protocols. The little devil there was added today while I was at the other developer room. And I saw in a talk about using other in little better environment. And that could be another interesting thing. But you know, we start taking with the original plan. And if you get enough people, attract enough interest, you can start also this branch. This just was added four years, four hours ago. OK, so the idea of starting with network protocols is quite peculiar and neat. But there is a reason. Actually there are two or maybe three. The first reason is that networking today is very important. And there is another nomination to the novel for the obvious stuff. Actually, many people believe that programming is just a web development. So we can agree that networking is very important. And it's useful to have some safety implementation of that. That's quite interesting. Actually, there is more to that. The networking part of your application is the entrance gate of your application. And if your gate is weak, you can build a castle as strong as you want. But the whole system will be weak. And moreover, what's worse, if you have a library with bugs that is used like a network protocol as a building block, this library will be used in many applications. And if there is a bug, you will have lots of bugs around. Do you remember HeartBlood? That's the same idea. So since we need to start from somewhere, this could be an interesting context where we can do a very strong impact about safety. Moreover, there are another couple of reasons. There are a couple of reasons. Let's say we try to get tubers with a stone. And that could be useful also for protocol development. The ITF has two tires for protocols. One is a proposed standard and the other one is an interstandard. In order to be promoted to an interstandard, they need at least two different implementation of the same protocols. Why? The idea is quite obvious. If you have two different independent implementations, the word independent is important, that talk each other, then you are quite sure that the specification of protocol are not ambiguous and complete. What happens usually is this. While the protocol is being developed, someone writes a library for that protocol. Some software for that protocol. Because in ITF they believe you're running code. Correct. So at least one version of the protocol is available. Starting from that, in many cases, if you need another library in the different language, you don't rewrite the same library from scratch. But use the first one, use written in C, and do a binding. And you know, if you have a Ruby binding for a C library, that's not an independent version. It's the same code with the progress. Since in our case we are interested in developing correct software, we have a reason for rewriting the stuff. If we have a nice effect, we can get an independent implementation for promoting the code to the higher tier. And moreover, ITF is trying to have some connection with academia and with open source communities. We started this initiative that's called CodeStand. CodeStand is basically a way to connect. You propose some project to be implemented and keeping track of who is implemented and what. This is the homepage of CodeStand. I can see really not many belly whistles, really to the point. And I don't know if someone of you have ever been in an ITF meeting. If you want to have any idea what an ITF meeting is, take post them and make everyone 20 years older. You get the idea. It's a very special group. Still working by a mailing list. I guess they are the last ones. They are the last ones who still work and communicate via mailing list, but it works. And staying at an ITF meeting is something that one should go just to see the environment. And this, for example, is CodeRequest. So these are open teams for someone who wants to try to develop this stuff. And we could be a nice channel between open source and ITF. Let's say this is not the most important result, but it's a nice side effect. Still staying on the side of how. Let's go a little bit technical. And this is something that I feel like in the need of explaining maybe the final bit. So the idea is to develop this stuff using if possible Spark and Ada. By the way, Spark has nothing to do with Apache. It is a subset of Ada that is suitable for formal checking. Formal checking means that you have a piece of software that can check if there are no, say, no buffer overflow, there are no exceptions. You use everything when it has been initialized, but also you can have the program to formally prove that, say, your function actually does what it says to do. Pre-condition, post-condition, and the Spark can check that if the pre-condition is true, given the code, the function, the post-condition will be true. This can help a lot, actually, helps a lot in finding bugs. That's the idea that I have about Terra Bruciata. This is a way to burn a lot of ground. This is not to burn all the ground. There will be still something that you can do in Spark, something that you need to do with testing, but this can help work quite a lot. And the usual objection when I talk about Ada is that it's old. I'm not going to do another advocacy of Ada now. Usually, here, first, there is the other developer room. You can go there for more deep discussion. But basically, the idea is that, actually, I used a lot so far. I graduated more or less 50 years ago. And in all those years, I used, I don't know how many programming languages. And I used C, C++, and other stuff. My personal experience is that the bugging with Ada is much, much faster. Let's say that it won't help the effort, really. If you help the compiler, you can be really, really a strong head. It's not a magic bullet, of course. Usually, the objection is that the real quality comes from the programmer, not from the tool. And it's true. I agree. But even a chef needs to do something complex like letting a fish. Prefer to use the flexible knife because the job is done faster and maybe with better quality. So even if you are a professional programmer, you have a lot of experience, you will prefer to use a better tool that helps you in the job, basically. And believe me... OK, the other objection usually is about speed, but Ada is compiled, like every other language. So, more or less, there is no... And actually, it can be used on very small devices. A few years ago here in Bosnia was a talk that showed the Lego Mind Stone program in Ada in order to make an invest pendulum segue. And it was a multitasking code over the Mind Stone that is 16-bit CPU with, I don't remember, 64 kilobits of RAM, stuff like that. So it's not only something that runs on planes. And, well, this objection, I guess, it's not... So, what time is it? OK, a little bit early, but I guess. OK, what is the current status of this? This is quite a young idea. I got this idea maybe less than one year ago. Currently, I'm working myself with a couple of students of mine that should graduate in the next few months, so I will be left alone. And I started with trying to implement co-op. I don't know how many of you know co-op. Co-op is a lightweight HTTP. I'm not telling the spirit of HTTP, but it's based on UDP, not TCP. And it's all binary, while HTTP is text-based. This is all binary. This was developed for the Internet of Things, as usual. Why this? Honestly, no special reason. We need to start from somewhere. This is connected to Internet of Things, and it is important nowadays as an applicative level. So, we started with this. We are currently trying to get from the RFC to summarize it in a few formal statements of requirements, and from that, starting developing with more or less the idea that you can find in DO178, minus all the bureaucracy that DO178 has. And so, the idea here is to try to collect at least initially a condensation core of people that can be really interested in the idea of writing correct code. So, if you want to get in touch with me, here there are my email address, my LinkedIn page. There is also a LinkedIn group. And maybe... Oh, no, maybe. There is also a page on SourceForge, but I forgot to put the link here, but I guess you will be able to find it. And I hope here there is someone interested in this stuff, so it's something that's starting. So, it's open to new direction, so it's open to commenters, open maybe the idea of using or writing method protocols maybe can change. I don't know. If there is enough convinced arguments, maybe it can change. Maybe we can start also different branch, for example, in bed or other stuff. And that's it. I open to question if you have any. I guess I'm a little bit early, but I think you will not cry. Thank you very much, first. And here's the first question. Yeah, hi. Janik Moj, project leader for Spark at Decor. So, I have one question and two comments. So, my question is how did you make your slide? And my first comment is about what you said or what somebody told you about building avionic software that costs only 50% more than regular software. Just to dismiss any misconception that's not true at all. So, NASA documents some years ago counted something like seven times more investment in verification phase with respect to development for this kind of software. And even last week, I was at Avionics conference and Airbus presented a big project to reduce the cost in DOA in 78. And they were saying that for their typical product verification was 70% compared to development 30%. And I could go on about all the development assurance that you need. Much more than just 50%. Just so that you know, high critical software really requires much, much more. So, you cannot just copy paste such processes. But it's nonetheless, my last comment is obviously we are very supportive of a project we use the kind of technology that I use in Avionics and other domains. Just wanted to say that even though seems like a good idea, these kind of initiatives in individual project have been going on for many years already. And, for example, I encourage you to look at Muen. Muen is a separation kernel written in Spark. It was led by this person next to me when he was at CQNet. And this separation kernel is something quite big where you ensure security of applications by having a kernel that ensures that it does not interact in a non-esplores way. And this kernel is a small kernel in Spark that has improved absence of front-timers. So, there's no possible tax of many different kinds. So, just to say, it's a great project, but be aware that there are many others open source project with these technologies. And there's one more question. Well, okay, thank you. The figure about that, and I found that 50 percent I found in a book, but I don't remember the title, it was about. But I'm not, so, just to be clear, I'm not an expert, I'm studying this stuff right now for this reason, but... And about the other initiatives, actually I was in the other developer room when you talked about them, and I was happy to hear that I'm not alone. Let's say that maybe this also has a different flavor. The other initiative was, let's produce, say, an expiration kernel. I don't remember the other stuff. Here the idea is let's do this. Also for the public relations stuff. So, if they produce good software, it's also to say to the world, look, good software can be done. To try to... Definitely a good idea. Just to say, there are other things that you could look at or others could look at. For example, in terms of examples, Tokenir example was produced by Alton in Spark for DNS in 2005. We open sourced it in 2008. Everything is on the web. By the way... There are others to look at for inspiration in that case, as examples. By the way, I will look also... Today I discovered about those projects you talked about, and I plan to look into them, for example, to see for idea processes and how they did that to do import in this context. So, actually, I repeat, I'm happy that they are not alone in this. So, I feel a bit skeptical about the idea that if you demonstrate that you can build correct software, then overproject will start adopting the same methodologies. One reason is that, as was pointed out, there already exists software that was developed to be verified from the start. And yet, the methodologies are not common in the open source community, for example. And sometimes, I think maybe it's because the tools that have been used in the Spark at that community, all the people that do stuff with proof assistant and so on, are very different from the tools that are used in existing projects. And maybe what we also should do is start trying to adopt tools for formal verification in important open source project of today. I was wondering if you had the opinion of that, because I worry, so you would build a protocol implementation in Sparkata, but then people could say, yeah, it works because it's Sparkata, but we are I don't know, a Java shop, we see right now, so we cannot use this methodology. Okay, so first about what you said at the beginning, you see those projects, I discussed about those projects today, and they have an interest in correct software, i, development and other and stuff like that. So maybe what's missing is, I know that maybe in this context I'm going to say bad word, but kind of marketing stuff. So letting people to know that to actually try to spread this idea, not just because for example, those projects I discussed today, and I have an interest in this. So Just to answer it, because I think there's an answer, these domain, these tools for formal verification, higher critical software, it's very open source rich. You have plenty of tools that are open source and particular industrial tools. So for example, if you do C, C code, there's Framacy. Framacy is a well known tool. It's not adopted very widely because all these incur a cost. So if you, I mean for our software, for building our own software in Ada, we don't use our sales part because it would be too costly, we'd have too many constraints to develop a tool that is not as critical and so just to mention, for C would have Framacy that implements the same thing with the underlying same building blocks, in fact, from also the open source community, so open source provers. For Java, you have OpenJML, which is also open source. So you have framework tools like that that are available for a few languages. I believe that for C code for the drivers, people have used CLEE for example, model checking of C code. So I don't know the state exactly of that, but for Microsoft there was SLAM and I guess there are many, many tools and it depends on the motivation of communities. Higher critical software may require more effort, so again it depends on the motivation of the community. I like the initiative to make a more secure infrastructure. On the other hand, I just did a project on an x-ray machine and I think 60 to 70% of our product code was test code. So I think the current test infrastructures if you expand them and they get attention we would already get there and another lots of problems is indeed the legacy of C in C++ that hurt us. So other could be a solution or rust or I don't know what other initiatives there are. So I wish all the luck with this initiative and I hope more do follow. Hello. I was wondering and I don't know if you can give us some figures if, for example, I'm thinking about the Linux kernel. There is a lot of critical open source software that is used heavily in production nowadays and I find it difficult to believe that some kind of formal software was not already applied on the large scale on this kind of software. Do you have some idea about what was done already in this field? At the industrial level I don't know, but doing formal verification on languages like C maybe I'm not an expert in this field but I think that it could be much more difficult than using other tool because if you want to do formal verification you cannot use pointers and if you write a C without pointers you do not do much. Having just passing parameters that must be written by a function you cannot do that. Instead in other those use pointers are hidden by the language so for example you say that this parameter is not parameter of course the compiler will pass the pointer but it remains hidden so you can avoid using pointers but disclaimer I'm not an expert in this field I would like to maybe give an expert view on this one pointers can be used in formal verification the more pointers you have the less it's easy to do and for example VCC is a tool that was produced by Microsoft Research now it's used at Amazon to formally verify C code that is used to formally verify C codes in industrial context Open Gmail obviously is used to verify Java so you can and just to answer because there was a question languages matter a lot for this kind of things last week Xavier Le Rois the creator of Open Gmail give a presentation on that he started, although he created this compiler from C to assembly he started by saying that C is ugly and you cannot really work around it this morning person doing the presentation on software quality in Mozilla just to urge people to move away from C++ to rest Xavier Le Rois would go to Open Gmail just know that there are other alternatives than C and C++ and that the language matters if you want to go to that level I was going to ask if it's kind of a project founded by a university it's frankly I it's sad to see such things occupying space in universities for future generations so far there is no funding more or less it's me working on on following students who are graduating and the amount of resources are not it's not huge and by the way I believe that it's something that can be useful okay it's important for the future I mean having this promoting this idea and also teaching students that software must be good because it's important and teaching them skills about how to write good software I believe it's really important so thank you very much Ricardo welcome