 tricks on Xen, which is the basics for all the major cloud operators in the world, like Amazon or Rackspace. And after that, I work a few years in OCaml Pro, which is a consulting company for OCaml, where I developed Opam, which is a package manager for OCaml. So if you have any question related to OCaml or Opam, let me know. I know that quite well. And then I started like one year ago, I joined the University of Cambridge, where I started to work on Mirage, which is an operating system fully written in OCaml. But I will try to describe to you now. So first of all, I think creating distributed systems is still an independent problem. We don't really know how to do that properly. There's a lot of possibilities, and none of them are very satisfactory, I guess. So just a quote from Principal Engineer on Twitter saying that, well, we know how to make modules to create components and compose them together in a synchronized way. But when you start putting them together in a distributed system, that doesn't work at all. Everything is broken, concurrency issues everywhere. And so the question is, why is this case? And how we can solve that? So I think one of the causes of that is because we started to create systems thinking of only one processor, only one user. And so the environment is very simple at the beginning, which is only one thing. And then we try to apply some ideas to a lot of different things, the cloud, programming the phones, using JavaScript to make a synchronized web client with callbacks and such. Then we want to put things inside the objects everywhere. We want to put processing data, processing power in the lamps, or in the bulbs, or everywhere in the fridge. And then we have kernels, where we have a very critical piece of software which works inside the operating systems. And we try to apply the same kind of techniques for all of this stuff. But we cannot do that, because every component is different, every architecture is very specific. So we develop every time a new set of tools to work on that. And so we do every time the same thing. And so we repeat every time some mistakes. We have the bugs everywhere. We scrape everywhere. So that's not a good way to go. So what I want to explain first is, yeah, I think one of the main problems is the complexity. So we are trying to build big systems without really thinking about how to do it. Just trying to pile things together and hope it will work, and that will not work usually. So everything is very mixed, and there is no clear separation of concerns between the different components. Moreover, when you discuss about operating systems, the problem is that we want to offer to users a lot of different things. Like you want to dynamic libraries. You want to be able to load code dynamically. You want to be able to support multiple users on your computer. And your phone is not really necessary, but you still have the same design ideas which are here at the beginning. And you want to run multiple applications. I think the first iPhone was not able to do that. And so people were starting to complain. So they added a pretty free application after that. Usually, on top of that, you have to choose which software you will install, which version you will have to understand, or they will interact together. And then you will have to configure every application separately, putting some configuration files somewhere on your system, which will be different depending on the application or the version. And then depending on where you want to deploy your application, you will need to configure your firewalls, your all the different parts of the system. So what we said is, OK, this is not acceptable. Or we cannot do anything with that. So we want to start from scratch. Why not? And we want to design new stuff in very nice languages, or functional programming languages, for instance. But the idea is very weird to say that, OK, we have an application. We will write it into SQL, or Clojure, or OCaml, or whatever. And then we will just put it into an operating system, like Linux or Windows. And it will run there. So the nice language that we build with a nice abstraction, they will be surrounded by a lot of unsafe C codes, like 50 million off-lines. And we've bugged everywhere. And so it's not much better. So the only way is to start from scratch, even below the application level, so at the OS level. So what we do with Omirage is we rewrite everything. And an example here is, so here I've got a small QB board, which is like the Raspberry Pi, where everything is compiled, where everything is written into OCaml inside that. And actually, the presentation is connected from my browser, which if you can look at the top here, I'm connecting directly to inside the QB board. And so the QB board is serving my entire presentation here. Everything is done in OCaml from the application to the network stack, and the OS as well. So everything is there. So we are using that as a compilation target. And the whole application, so the network stack, the website, the data, so the images and everything, is around one megabyte in size. So you can just take it and move it everywhere. It will work as well. It will work. So that's just a source file describing the application logic, some configuration to say that you want to use DHCP, for instance, or which storage backend you want to use. It works very well on ARM. And the idea is the binary is small enough to be kept into Git, so you can version control the binary as well. So usually, you are a developer, and you have a good process in your company. You are using a version control to version control your source code. And the idea here, you do the same thing, and you version control the binaries as well. So when you deploy your application in the cloud or anywhere, you can say, oh, this version, this application, this binary, is version number x, which comes from the source number x, et cetera. And so you can have a full story of the binaries as well. And so what we want to do with Mirage is to focus on portability, so target the different platforms. But using modularity to say that, actually, you just write the application once, the source code of your application, and then you switch underneath the different components, and it will be transparent to the user. And the thing is, it's safe, and it's performant as well. And I will try to show you that in the talk. So yeah, that's not the same Raspberry Pi, but it's good. So yeah, so just to summarize, so complexity is in me, and we want to be simple and efficient. Be simple and small, so that if it is small, it can boot quickly. If it is small, there is less attack surfaces for attackers to try to get access to the system. Well, you will say, oh, it's not very new. We use already Docker. With Docker, we can create images and send it to other people, and they can use it. So what's the difference with Docker? Just quickly, well, if you look on the left, you have the usual system stack with different layers and layers, which has been added years after years by different researchers and people in the industry. And what you do in Docker, you take the full stack, you create just one container, and you put it on top of something which is an hypervisor like Zen, or KVM, or something. But the idea is you still have the full stack, so it doesn't really help for making things simpler. So the idea is you break everything into modular parts. Then you only take for your application the parts that you need. For instance, if you do an application that doesn't use the network, if it is not a network application, you don't care about the TCP IP stack, and you can just remove it. And so you can just do dead-code elimination to remove all the necessary code, and have a very, very small application. So the idea is you take your configuration files, your source files, the components that you want, and then you link them together, linking as a compiler link. So you just create a small binary which contains everything, configuration source code, and the system libraries, and that is a self-contained and small image. And so, yeah, that's the idea here. You put everything, and you compress that into a very small image. And then you can decide where you want to run it. So you can run it inside Unix. So you can keep the normal TCP IP stack of Unix, which is tested from here, so you think it works well. Or you can say, OK, actually, well, so this is just the language runtime here. But you can, as well, integrate everything. So you can say, I want to write the TCP IP stack in OKML, as well, and use it in my application. I want to have a FAT or NTFS NFS storage. And I want to link that together into my application. So you speak the component you want. You link it together, and you get one single self-contained application that you can run on top of Unix or Xen, which is powered by Amazon. So having the full control of the stack, you can do whatever you want on the runtime, as well. You control the runtime. So you can simplify everything. You can say, well, actually, the memory of my application is very simple. There is a specific zone, which is the stack of my application, something which is only a result for the network. But I know that only incoming packets will go here. And so everything which comes from the outside is from that zone in memory, so that cannot really contaminate the rest of the application. And allocating and just moving a pointer on the stack, so everything is very efficient. And some example of the size of the binary. So we wrote a DNS server in a camel from the application logic to the network stack. And at the end, it's like a compressed version is 100 kilobytes. So you have 100 kilobytes, you have the full application and network stack and OS things which are needed for the DNS. Then we just some example of performance measure to show you that it's efficient. So here the example is we want to start application of virtual machines on demand. So here we want to do a DNS request to get an HTTP page. And we start a Docker image just to serve the HTTP page. And usually it's around 1.4 seconds. We try to hack it a little bit to make it faster, but everything is crashed. So sometimes it's faster, but usually it's just crashing. And then we do the same thing for Mirage. And for Mirage, as we control the world stack, it's very easy to add optimization. So here we have just a small optimization where we have an application which is always on and which listened to incoming TCP connection. And when you get a scene, it just opens the connection and passes the connection to the other application, which is, at the same time, wake up. And so the wake up is very fast. It can happen in 300 milliseconds. So that's in that when you send a DNS packet, it can just wake up a virtual machine and reply directly with the first TCP connection, like in 300 milliseconds. It's very, very efficient to boot. Yeah, the summary. So if you start to boot a VM just to serve an HTTP page, if you take Linux, you need to boot the whole virtual machine. So it takes more than 5 seconds, or really 10 seconds. If you try to boot a Docker container, it's more than 1 second. And if you try to boot a Mirage unique channel, which is called J2 here, it's a very specialized instance of it. It's less than 1 second. So you can use it just to serve traffic in real time and create application in real time. So it's very, very, well, with that kind of thing, you can think of a lot of different applications. We are just starting to discover what you can do. It's very, very fun, maybe. If you have ideas, I'm very keen to listen to them. Right, so it was a very fast introduction. So now I will try to dive a little bit into details. So first I will present OCaml, because I'm not sure. First, do you know OCaml? So who already tried to use OCaml in their life? Well, good, good. It's much more than I was expecting, but good. Then I will just show a little bit the workflow to develop application. Heremin, which is a new storage system of Mirage that I can describe a little bit in detail. And OCaml TLS, which is a representation from scratch of the TLS stack, which is something that we can do for fun, because it's fun, but I will try to explain. So OCaml. So if you go to OCaml.org, I will tell you that OCaml is an industrial-strength programming language which supports functional, imperative, and object-oriented styles. So it's a, well, I mean, that's very general. So what it is actually is, well, it's very pragmatic. So if you like programming with objects, you can use objects in OCaml. Usually people don't, but very few libraries are written like that, and when it's useful, you can use it. If you want to use mutability because you like mutable states, you can use it as well. It's fine. People kind of use it, actually, but very localized inside the function. When you want to do a for loop, you can just do a for loop. But then you try to avoid having global state because it's very bad for concurrency issues. And then if you want to have functional programming with functions and priority, you can do it. And the main difference, I guess, with Askel is everything is strict, as in Askel, everything is pure, which I think that's the main difference between the two languages. I study statically typed. So I think there are two good things for statically typed languages that I'm not sure people are really aware of, really. So when you are statically typed, that means that you can have good performance. Why? Because that's a compiler, a node in advance, which are the types of the different things. So we can optimize a code to generate it. So if you have a plus, and you have two things on left and on the right, if you are using JavaScript, you don't know that the plus is the concatenation or the addition or if it is, well, you don't really know. So in a candidate, for instance, plus is always written in an integer. So it will be optimized as only one assembly instruction, so it will be very, very efficient. And then types are very good as well to structure your code to ensure global end variants. So you can say, I know this kind of data, follow that patterns, and so I will describe it with a special type language, saying that, I don't know, it is a case analysis between different cases, or it is a record. And then you can apply that on the compiler with l u, oh, here you use it in the wrong way, and you try to correct you. So it's really a tool to help you improve your program. And it's like a game where you try to press enter, and you will complain saying, oh, this is not good, so you think a little bit, you correct it. And it's very interactive, and you have to treat the compiler as a tool, not as an enemy. A lot of people are saying, oh, types will just complain, and it doesn't want me to correct my program. It actually tries to help you, so you have to be kind with your problem. A bit of history, so I think it's a direct descendant of ML from Nielner in the 70s. His close browser, F Sharp, which started as a fork of ML for the .NET environment. And then now it's a bit different language, but the roots are very similar. And interestingly, Dunsim, which is the main F Sharp developer, is in Cambridge as well, and this was last week we saw a talk of him, and he was saying, yeah, the main language I prefer is OCaml, but I was forced to use .NET, so I had to write F Sharp. But so he really likes OCaml, apparently, so you should like it as well. And then Askel is a close browser as well, but it's lazy, and the type language is a bit more expressive, so you have to put more type annotation to be sure that it's compiled. It's created by some French people, Xavier Leroy from India, almost 20 years ago, and it's teaching a lot of different universities in Europe and US. In Africa and India, I'm not sure people learn it or teach it in university. One, where? OK, so if you can drop me a line to tell me which one is it, I will be very interested to know, because I think we need to spread it a little bit more to be useful. So yeah, there are very strong roots in academia, but there are as well a lot of industrial, well, lots, but there are important industrial users, major industrial users. The main one is Gen Street, which is a hedge fund company in Wall Street. I think they do 2% to 5% of all the transactions in Wall Street, and all the code is written in the camel, everything from the administrative tools to the trader's tools, so everything is written in the camel. There are a few people doing that for system-related reasons, so Citrix and Red Hat. Citrix is doing it for Xanserber, so the management of the intact tools of Xan is completely written in the camel. Then you have Facebook, which I don't know if you heard about, but it really is the hack language a few months ago, and hack is written in the camel. And so we know very well the people who did it at Facebook, and we hope to have a more complete, well, more integrated relationship there, because they got very nice tools from ID2 that we want to use for our camel as well. And then you've got a lot of security, like CI is the main nuclear power builder in France, and so they want to be sure that the software doesn't have any bugs. Dassault and TLS are doing planes. We'll see the French security agency, which does a lot of tools in our camel as well. So yeah, so if you look at that, well, it's different kind of companies, but the main point is you are worried about bugs in your programs. So when you are trading on Wall Street, if you ask to trade for $100, and then you get a minus, which can just at the beginning of your number, and then you iterate that in a loop for one billion times a second, you can be a big trouble in your company. So you really want to be sure that what you do is correct. And I think it's working quite well for these kind of users. And then a few years ago, so two years ago, there was a camel labs, which have been created in Cambridge, where I'm not working, and I'm working here now. And I think there was around 10 to 30 people working on stuff related to a camel there. And so we tried to improve the different toolings around the language and to make it more usable in academia. So if you are in a university and you want to teach it, feel free to keep in touch, and it can help you to give you materials there, and so on. So then another thing is that we are creating a library US, so we want a lot of components which are in OCaml, and we want to be able to pick the right components when we need it. So for that, we want a good package manager as well, because if you have a lot of different parts that you assemble together, if you have to do that manually, it's very painful. So two years ago, I started to write OCaml, which is a package manager for OCaml, which is a mix of Cabal, which is the one for Haskell, and Homebrew, where everything is based on Git. You have the Git workflow. You can put requests to add a package. You can have multiple repositories, which is distributed. And we use the same constraint solver as Debian, which is UDF, because we have a strong ties with the people there. So I think it's a very nice one, and it's not very specific to OCaml, so if you are using a language and you are looking for a good package manager, maybe you can try your plan and tell us your experience. So we have more and more contributors, more and more packages. And at the end, the experience with OCaml is the goal is we started with a quite large bit of C code, and we tried to remove a lot of it. And it's getting smaller and smaller, and we are very happy with that. I think the main thing is we started like four years ago, five years ago, this project, and we had to write three times the whole OS. And maybe we write it four times soon, I don't know. But the thing is it's not very hard. It's just a bit painful, because you have to understand everything, and it's very interesting to look into the details. But then it's not very hard. You are using a high-level language. You put things together. You put the application logic is very clear. You don't need to worry too much about the low-level things. So you can really take any kind of protocols that you want to know, and just trying to implement it. It's a very good way to understand it. And then when you try to implement it again, you will try to ask questions about why people did that like that. It's not the best way to do it. And then you say, oh, maybe I can try to do another way. And usually it's a very good part to do research or even to create new products which are very innovative. And we have a very strong support for that with Citrix, for instance. We started to use Mirage a lot for all the tools internally. And so it's very useful to have quality control coming from the industry, as well. Right. And at the end, I think that's all for our Camel. Do you have any question regarding our Camel? Yeah. So we have a student in Cambridge who's working on that, Defender Lenn, who showed the first results last month. And he gets a very nicely working prototype, which is still a prototype. And then we are discussing with the Inria people to try to upstream the patches. And they're happy about that. So I think in a few, yeah, one to two years, maybe, we'll have to take our Camel for a question. OK, so now just an example of, oh, yeah, sorry. So there are very few things which are specific to our Camel, which are, so there are a few variables which are what is a compiler version. And then the full thing is, you have to track the dependency very closely. And when you change something in the chain of dependency, you have to recompile everything on the chain. So it's very, very strong dependency there. So it fits very well with compile languages. So in Python, it doesn't really make any sense to have that for Python. But if you have a compile language, I think it's fairly easy to, we made it work for C for instance. So we don't use object-oriented code in Mirage. Most of the time it's functional code, very functional. But then when you have packets and you need to read bytes into the packets or to write bytes, you have immutable memory, so you use mutability here a little. Yeah, so we don't have the projects API because, so we had to make a choice of what we want to support. So we don't have threads in Mirage, for instance. So we have lightweight threading, which is very, which is threaded under by the runtime itself, but there is no support for really concurrent threading. It's everything is, it's cooperative. So every thread has to yield and another one has to take the thing, and when you are blocking, you can just start another thread as well. So it is one limitation. But the thing is, you don't really need that because you can just spawn two virtual machines doing two, like two processes, and you're using a message, external messages or memory, or sharp memory, to return what you're doing. But then what we, I can, I would explain it a bit later, but we have a type for what is an OS, not less, so when you need time, you need a notion of randomness, maybe, or entropy, and the thing is you can pick it if you need it or not, and depending on the backends, you will implement it differently. I'm not sure, I'm not very clear, but I will try to explain it later. Yeah. Yeah, so in Mirage there is no projects API, so yeah. Yeah, current yes, but then what you can do is you can have your very, so when you write something in Mirage, you hope that it is a thing which is very important to you, so it should be very safe and very efficient. But then you can use the GSE application inside separate VMs, and then we have libraries to communicate efficiently between the Mirage and the GSE application. So we have shared pages, for instance we can set it between the two VMs, and you have a very efficient channel there. So the idea is you don't really care about the POSIX or IBI compatibility, but you care about the high level API, so if it is REST or if it is the protocol API, not the POSIX one, but yeah, for now if you want to really use all of the Mirage stuff, you need to use the Camel, because it's everything based on that. Now because for instance if you have a small keyboard like that, and you want to save power, you will just turn off all the applications, and it will just consume no electricity at all, or very few electricity, and then when something comes on, you just start the VM and it will just serve the traffic. Yeah, small devices, yeah not for cloud, it's just a, but even if you are in a data center, you want to optimize as well the number of VMs which are running. So you want to kill the ones which are not really running and start it again. The thing is usually you kept it, well it was just an example to show that you can do that kind of stuff, because we control the whole stack, so you can just hand over the connection to the VMs. Anyway, I'll try to continue. We'll just try to explain how we write an application in Mirage now. So the first we start by just writing your code in the Camel, so you have to learn the Camel first, but if you come on Saturday morning, I will try to show you it's not so hard to learn. And then for instance, you have your application, which is here, the code for your application, and you are using a code for an HTTP server here, which uses the normal TCP IP stack on Unix. So here you just, the Camel code is just here and here, which is the application on top of HTTP and the HTTP server itself. And then you just do Mirage Configure and Mirage Build, and it will give you an application that you can run inside Unix. So you run the application, and then you can use the usual debugging tools inside Unix to develop your application. Okay, so now you want to be a little bit more fancy, and so you start to say, okay, no, I don't really trust the TCP IP stack of Unix, because it's full of C code and I don't really know how the portability issues have been done recently. And so I want to have a full stack in OCamel as well. So what you do is you just change the dependency to that stack, which is TCP and then IP, and then you use a turn tap inside OSX, for instance, or inside Unix, to just get the normal packets, and then the packet is handled directly to the stack and all the IP and TCP processing are done in OCamel. And the thing to do that, you just need to configure again. Well, you have to set up saying that you have an environment variable saying that you want to use the direct stack, and then you compile again, and that works. And everything works, you don't have to change any line of code to use the new stack. So now you say, okay, I don't really trust Unix because it's full, it's 15 million of offline of C code, and who knows what security holds there. So I want to write everything in OCamel, even the OS. So what you do is after the IP level, you just use the Xen, you have the Xen device driver, which are written in OCamel as well. Everything, even the boot loader is in OCamel, everything is in OCamel, and then you just have to trust the Xen implementation, which is still in C, but smaller than the whole Unix stack. And to do that, you just have to, again, to change, well, you configure with a different option, do dash dash Xen, and that will work automatically. You don't have to change any line of your application to do that. I will fix the example because they are wrong, but, so the idea is you write your application, your I level application once, and then you configure it multiple times. And everything happens via the OCamel module systems, and we build a tool which is called Mirage, which hides almost all of the complexity to the user. Right, that's just an example of that. So then last thing, well, next thing. So as I said at the beginning, one good thing about having very small OCamel images is that you can keep OCamel images or binaries, that you can keep the binaries inside version control as well. So you can use Git to version control your binaries, and then you can use the normal Git tools, the normal Git workflow, to deploy your application as well. So here what we do, so the main open mirage.org website is built automatically every time we commit some source code into mirage. Into mirage slash mirage-mirage.eu on GitHub. Then we have Travis CI integration services which builds the binary of the OCamel, and then we push using Git, the Git push of the binary to the mirage.eu.eu.eu-department. And then from that, we take the latest binary and we put it online. So the thing is you can just, and inside the binary, you have the shaguan of corresponding to it. So if you want to, let's say you develop your application, you want to tag a specific version, you just use the Git tag to tag the binary as the one which is currently in development. You can Git log to see the full story of all the events in the history of the development of your application. You can pull or push to update different websites with the same version of the whole thing. And you can revert to the later version using the usual workflow. Before I continue, just a quick question. Do you, well, do you know Git? Would, would, do you know, well, does nobody Git here? Do you know Git? Yeah, no. Yeah, who knows, sorry, who knows Git? Right, okay, so I, I would, so, yeah. So if we, and so if you use Git or GitHub, which is the main, well, which is the main central repository of Git projects and on the web, you can use it as a, as a getaway for all your binary deployment. And so it's a good, good, you can think of some workflows where when you start a service, it will try to pull automatically from upstream. So if you want to push a patch to all your services, you just have to push a patch upstream on GitHub. And then all the VM which are started using that version of the binary would just pull the new binary and apply the patch automatically. So it's very, well, it's similar to what you do when you have a DBL and you do a pretty good update. But the thing is using already the same tools as you do for the source code. So it's less burdened than to, less, well, it's very integrated workflow, which is very useful in practice. Yeah, everything, yeah, yeah, you need to rebuild everything, yeah. But the compiler is quite fast, so it's not, well, it depends, if you compile on the QB board, it's a bit slow. Yeah, it takes me like maybe a minute to build the whole website here. But usually it's very, very fast if you're on X86. Well, you, so when you push the binary in the, in the repository, you have the, what is interesting is the history itself. So it has a commit message. The thing that the binary is the one after this one. And then you can, in the commit message, you can say that this is generated from the source code at that address of this version. Yes, there are. But then if you want to deploy the application, you can just do git pull. Git pull and you get the binary itself. As it is very small, it's very quick. But then you don't, yeah, there is no diff, so you don't really, the diff is not very useful for the question. So yeah, so just, so as I said, you need to, every time you have a new version of the library, you need to recompile the whole unique channel and then take the unique channel and put it and deploy it again. But the idea, but what is interesting is as you get all the library, you can use a world program optimization to optimize it, to remove that code to do more inlining or stuff like that. Right, then with your version control, your source, your version control, your binaries, we say that, well, maybe that's not enough. We want to version control the data as well. So the idea is you have a big application with a big database, for instance, and you do some stuff and then you want to debug what happens. So currently it's a bit complicated to do it. You need to have a dump of the database, you need to manually try to reconstruct what happens there. But that would be very nice if you can just have Git as well. You can just do Git log and you see, oh, this process put something in the database and this one remove it. And then if you want to revert it, you do Git revert. So it's very, the normal, the usual workflow for Git is very well adapted for data as well. And so we build Hermine, which is a storage layer for Mirage, which is a key value store which runs both in user space and cannot space, and which is very similar to Git. So you can clone a database locally, you can modify locally, doing whatever you want, and then you can push back the results and you can create branches locally or remotely and synchronize between branches. So if you are familiar with Git, that should be very, just think about it as version controlling your data instead of the source code. And but you want to do that as a library, so you want to use that in your code and say, okay, no, I want to persist that piece of data, save it to the disk or save it somewhere, synchronize with this one and so on. I will not really enter in the detail of Hermine, but if you know, so yeah, basically, there's three different parts in the system, you have the object DAG, which is an apparently data store where you have blocks and the address of the blocks, the shower of the block, it's what is written here. So if you have your data, you can just serialize the data inside that object DAG, and we have different backends for it, it can be memory if you want to have transcend data or it can be persistent and persistent using Git directly. You might want to encrypt the data or keep it in context. And then you have another one which is a history DAG, which is just something which is put on top of the data, which you remind where you come from or you merge what is your branches and so on, which is as well apparently, so you can easily distribute it, and you can keep track of the history of your system there. So when you want to inspect what happened on your system, you just write Git log and you see, well, Git log or any other tool using that kind of stuff and you can see everything that happened on your system, which process threads added what's data at what time and why, really, so it's quite useful to do that. And then the user can define his own data structures and specify the map function between them, like if you have a log file and you want to merge them together, you just want to respect the timestamp on the log file and I leave all the lines together. So if the user has the ability to define the map function and everything will happen almost automatically. And then you have just the last one, which is immutable tags, which is the only immutable part of the system, which is you name the head of your system or less. You say that currently I'm here and when you update your database, you move the head to another state. So that's the only immutable part of the system which is not distributed. So that's quite easy to think about concurrency in that city. So if you want to use it, you can use it as a standard tool as well as a library. So with different formats, which are, so I think the main interesting one is a Git bi-directional link. So you can use Git to modify your data and then the application will see the result as well. Or you can modify your data inside the application and Git will see it as well. And I have just a small movie, I'm not sure that it will work very well. Okay, that won't work. So it was just an example of, okay, so David Scott, which is a chief architect of ZenServer in Citrix, started to use Hermin to power a ZenStore which is a main database inside Zen. And so he used it and it was a video of the output of starting a VM and see everything what happens inside it. But okay, no connection, so that doesn't work. Right, any question related to storage, Hermin? Good. Next one is a TLS, so currently, so everything in Mirage is written in OCaml. So everything is type safe. You have memory safety, abstraction, everything is fine, modularity. And then when you try to publish something online, you have to rely on bindings to open SSH really, which is a kind of unsecure and safety code if you try to listen to what happens recently on open SSH. And so one of the motives of the people which did that is every line of C code is one line too much, one line too much, because you cannot really trust that line of C to not completely put garbage into your memory and corrupt everything. So David and Hannes, which are two very nice guys, which they were in Mir left in Morocco and they decided to, well, maybe they didn't really enjoy the bitch too much, so they decided to start hacking on a new implementation of TLS in OCaml to try to just learn about the protocol and they were saying, oh, it's maybe not so hard to make it work, but it was like six months ago or maybe a bit more. So they started to write the protocol logic in pluripfunctional style, which is a high level protocol, or it works, what is a renegotiation between key and so on, and then try to isolate as much as possible the side effects inside the front end, so when you read the packets or when you put the packets back. And so they tried to follow a very concise, useful and very well-designed IPI. So if you are not aware, so who knows TLS or SSL? Nobody knows TLS? So TLS, that's when you go to a new website and you put S at the end of HTTP, let's use encrypted, well the negotiation between the client or server is encrypted or is there a negotiation between the client and the server to set up a secure channel between the two and once the negotiation is finished, everything which you send on the channel is encrypted and no one can get the contents and intersect it and so on. And so if you heard about the health blood bug, which happened two months ago or three months ago, which is a very major vulnerability in SSH, which allow anyone to use HTTPS and requests to get a state of the memory inside of the server. And if you use it, you can read a lot of things on the server as credit card or whatever, so it's very bad. So you really want to be sure that that protocol is implemented correctly and there is no bug in it. And you don't really care about efficiency here because what you really want is something which is safe. So TLS, so that's something, at the beginning TLS is, well, it's written like, it's very old protocol, so 15 years old, more or less, and everyone is using it on the internet. And the only implementation that they use is OpenSSH, which is in C and which is very, very, very unsafe. There's a lot of attacks. If you Google for any of these attacks, you will see a lot of things. And so by writing it in the camel, we can avoid the go-to file because there is no go-to in the camel. Have bad because there is no, all the memory management is done by the garbage collector, so there is no, well, the memory is not unmanaged, so there is no what kind of attacks. So this is more like a logic kind of attack, so yeah. Yeah, yeah, yeah, so I will just leave it later. So yeah, so there's different kind of possible attacks. If you specify the different kind of attacks, most of the attacks come from memory issues, more or less, before the flow, or something like that, which are, well, OKML doesn't suffer from this kind of current because the compiler will ensure automatically these kind of things are not possible. So yeah, so if you don't have to manage a memory manually, it's easier. So there is no, so you can write TLS in a different, well, you can write that in different languages, and then you have to identify the invariant of the program using types and the types they show up, what is it, and the compiler will help you to ensure that it's safe. I won't say that, well, I will not say that there is no bugs in the TLS implementation, but there are bugs for, not known yet, but I'm sure there are bugs, but everything which is related to memory and to language construct, let's go to, I'm sure there are no bugs related to that. So the change cyphers suite is a more high-level logical attack, which are covered by the, by just carefully designed the kind of types you can use, which we hope to be secure against that kind of attacks, and then the timing attacks are very hard to, yeah, so in OKML and every garbage collecting language, you cannot be sure about that, and in CE and everything, so yeah, you'll never know about that, it's very hard to, so just some statistics, so just number of latin of codes doesn't mean a lot of things, but it's just a metrics, good metrics, well, maybe not a good, but it's metrics. If you look at what OpenSSL is using, it's, yeah, it's 17 million of code, 17 million of line of code, mostly C, which is a bit scary if you already done some C code in your life. I mean, usually you have between, yeah, it's one, every 10 lines of code, you have a bug, so that's very old code base, so I'm sure most of them have been fixed, but I'm sure there are still plenty of them in there. For OKML TLS, we have 125,000 line of code, which is quite big as well, because we still have 75K of C code, which is my needs of OKML runtime, which is maybe, well, which has, so there has been some effort to try to formalize it and to automatically, but yeah, we are, hopefully, there's no many bugs there. And then the results is, so yeah, but if I can go there, if I don't have any meta access, it will be difficult. So we have a live implementation of that, which is tls.sopenvillage.org, and I really want to show you that, okay. So if you connect to it, you will see that you will have a, I think I have, yeah, okay, so if you connect to that site, you will see that you have the full explanation of what happens between the client and the server in real time, and you have the, so you have the client send some messages and the server reply some of the messages, and a lot of things happen, and then you have some encrypted data. So everything is written in OKML, you can test it, and it has been, so now it is part of Citrix, more or less software, they are used by them, so they are monitored as the people which discover the health played bug to try to test it, to test it, and so they tested it for one week, and they didn't find any kind of security issue in there. So that doesn't mean there is no security issues, but it seems to work quite well, and all the development is done in a bit, it's open source, everything is open, and people can complain or just try to do some stuff. So it's survived, it's even survived some archive news, the font page for two or three days, and people are clicking and trying to access it, and it doesn't die, so I guess it's a good sign that it works. And it's still in progress to have a proper release. Currently, we don't really expect people to use it in production, because it's still like kind of prototype, but I think in one year it will be very, well, in a few months it will improve. So you can use it directly, what is very nice, I think is, so there are two main, or the two developers of that stuff, and they did it in six months, so I think that's a good proof that you can take any kind of protocol in the internet or any kind of application and do everything from scratch using the right tools and the right people maybe, but the right tools is the most important thing. Right, conclusion. So we released Mirage in July, Mirage 2.0, with a lot of different improvements. We are now part of the Linux Foundation and directly through the Xen project, so we got resources from there. If you want to contribute to our welcome, it's BSD code, mainly, so if you want to ask questions or to propose new stuff, we are very welcome to do it. If you want to use unique analysis, but with a different language, I'm sure a lot of people want to do that, you can try, other people try to do some kind of things like HALVM, which is a high-scale implementation. We are trying to share most of the C code, we are trying to share it at most as possible between the two projects because they are using as well Mirage OS for specific tasks and they are using HALVM for over once, but they are a bit complementary and we try to, so we are good friends, we are doing the same thing, but we are good friends, and we try to compare the performance and the abstraction cost. And if you like, I'm not sure, I never use Ling or OSV, I don't really know the status, I think they are still quite prototype and not very stable yet, so you can try it, but I'm not totally sure you can use it in the production yet. And if you have any ideas of small application that you want to use, feel free to keep in touch. If you think, yeah, just last slide and as I said, you are free to go. So while we do that, what we want is people to be able to write their own application and deploy it very easily on their own infrastructure. We really want people to claim back the digital life, what we say, we don't want the data to belong to Facebook or to Google, we really want everyone to be able to deploy a mail server on his home or whatever, that should not be too difficult. And currently it's very, very hard because you have to be an expert in mixed administration to do it, but if you have the right tools, it should not be like that. So we see Mirage as a basis for that. We want to have something which is easy to use for people and easy to deploy and we can rely on it easily. And yeah, that's it. Thanks for your attention. If you have any question, sorry. I was very, so. I think that's half of Linux already. The direct Mirage route, which you had spoken about, so who are the people, I mean, where can I get a host for that? So you need the Xen provider, so you can go to Amazon, Rackspace, any cloud provider, basically providing Xen, it's like 80% of the public cloud, so it should be okay. If it is VMware, it doesn't work yet, but it's not very, we need to find people to write the basics stuff, but it will not be very difficult. Okay, VM as well, it's really simple. So how many containers we can have on one host? So when you boot, one kernel is like, you need, okay, this VM needs 256 megabytes of memory, but you can squeeze it to 16, maybe eight, it doesn't need very much. So you can have thousands of them. It's very similar to processes, actually. So what we think is unicannons are the same thing as process, but for the cloud. Hi. Would you be having a shell or a file system? What all things will you be missing in this? So you don't really miss shell, because you can link with a custom ripple, and so you can connect to it, and then you have a full ripple inside the VM, and you can do your own, you can just use your normal language as a ripple, but inside the VM and do whatever you want. A file system, we have different implementation of a file system, we have FAT and FS, so you choose the one you want, and you link it directly, and that will work. Or you can just squeeze everything in memory and have no file system at all, it's AirMain as well, which is Git, so you really have to choose what you want. You'll pick the pieces you need, put it together, and that's self-contained, and that nobody can touch it, and that's secure. So we have, at the low-level bits, we have a, so when you look at the protocol, large bit of it is how to serialize data, so read data from the packets, from the network, or write data to the network, or to the disk, and this is very, well, you have four loops, but you have to mutate the state there. So we have some syntax that can show you, what it can show you. Okay, so this is the TCP IP stack, for instance, if you want to see the wire. So we have some extension to describe, so we have some syntax to describe the thing similar to C, so you can say that this is a C struct, which are this field and so on. I just, what is the wire struct? So here, for instance, you design that, okay, so you have a type, you have a structure, which is Ethernet, we've got some fields to the side, so this is very just declarative way to say the thing, and then when you want to access or to read the field, you just call some function here, so for every field you have a set or a get, so this is very, very state folder. You have to read the data from the packet, and then once you build some I-level, so when you extract the data from the network, you build some I-level types, the data structure, and then you can use purely functional stuff on top of that, like, I'm not sure if this is very nice, but so here it's very, so that you have a monad, so you can have very I-level expression here. So concurrently, we use a concurrently monad as in our scale, where everything is inside, every I-O is in a monad there, here every thread is about monad and we compose thread together, so you have a bind and return, but that's I-level, and then all the logic is very, is more pure, so you just have to call function. Yeah, so we tackle, so the initial focus was to, on the network stack, so it was a network, and then we have storage back-end, so we have few implementation of some storage stuff, but then we don't really, we don't have any use cases for that intensive stuff yet. If you have ideas, I'll have it. Well, if you have no other question, I can, well, feel free to ask me the question later, and we'll sleep here, and I will have a tutorial, if you want to learn OCaml, I'm doing a tutorial on Saturday morning on OCaml, I think there are still seats there, I need to check, but so Saturday morning, morning, OCaml. Thank you.