 Ok, vi kommer til å snakke. Tappet i dag er Over the Air Software Updates, med en nedkant eller servicerdisk disrupter. Jeg er Inge Vø, fra Unikernels Unikernel-projekt, og jeg tror at mange av dere har fått denne feedbacken. Hva er Unikernels Unikernel og Hva er Unikernel? Vi kommer tilbake til det, men først tar vi et sted til denne år. Hvis du var her i år senere, eller hvis du har sett videoene, du skal lemme om en tema som kom opp i Linux' Kino Chat i år senere. IoT er unntatt. Det er mye av deviceer som leverer ut i softwareet med ingen måte til å uppdate dem. Det er selvfølgelig en seriøs risk for seguratet-vulnerabiliteten, og i teori, alle deviceer skal uppdate automatisk, men i teori er det ofte svært, tidig å kjøpe, og det trenger en manuale intervention. OK, vi er i 2017 nå. Kan du sende en gang med en USB-kabel til å uppdate deviceet manualt? Nei, ikke riktig. Uppdatinger skal være automatisk og unntatt. Og når du har tusen av kunder, kan du ikke sende en person rundt til å gjøre det. Når du har tatt ut en user-initiator, kan du ikke skale i hverandre. Se på nummerne der. 1,4 millioner kunder. Reklanser er veldig spennende, så CFO blir mærkelig, og det er totalt logistiske næteverkninger, fordi du må skade alle disse ting til å oppdate dem. Det er virkelig svært. Så jeg er fra en projekte som heter IncludOS. Vi er gjennom en unikernal oppdating system, og vi prøver faktisk å oppdate dem, om det ikke er en løsning eller en næteverkning. IncludOS er startet som en forskjell projekte. Det var gjennom en person som heter Alfred Bratterudt, fra Norge, og en team av forskjellere. De er nogle publikasjoner som har vært publishet. Projekten er å oppdate å oppdate. Det er mest skjært i C++, det grøneste bar på toppen. Men du kan skrive i C, hvis du preferer. Nei, jeg er fint for at det er en skjønning. OK, vi går til en overvåg av oppdating systemlandskapet. Faktisk i de gode åldeste, vi hadde to mænne typer av oppdating system. Vi hadde de anbette oppdating system, og de hadde generelt oppdating system. De var mye distinkt, så de var skjønt på å indikere at de ikke hadde sagt det samme. Når vi hadde virtualiseringen, kunne vi konsolidere flere server på en fysisk maskin. Det var selvfølgelig en simplifikasjon, men det var ganske bra. Når vi hadde kontaineren, hadde de råd med flere server, og de nevnte ikke å skjønne hele OS, de kunne bare skjønne kernel. Og include OS er en unikernel. Så let meg gi dere et par point om hva unikernelene er. Det er ikke et nytt koncept. MIT har vært på såkaldt exokernelser i midten 90-er, og det er mange andre kjønninger nå. Du har Mirage, som har skjønt Okaml. Du har OSV, som er skjønt i Java, og du har Rumpren unikernelser. De er skjønt i C, og mest baser på BSD. Denne konceptet er også kjønt som en library-operating-system. Unikernelser er en single-purpose. De kan være brunnet for en masse purposes, men bare en purpose på en time. De er absolutt ikke kjønt for din laptop. Din laptop trenger en generell purpose-operating-system. Denne laptop trenger en masse devices, og renger mange program. Unikernelser er en veldig kjønning. Men i Cloud og i IoT har du ofte server som gjør bare en ting, og stil, de har sin egen fullblåne operating-system. The web-server derover er bare å gjøre en ting. Det er å kjøre webpages. Det er ingen fullgen generell purpose operating-system. Når du får det, gjør vi en library-operating-system. Dere program eller service får inn hva det trenger fra denne library. Dette er gjort. Alle OS-funktionalitetet er kjønt i en statisk library. Dette har alt i operating-systemet. Kanskje driver, men de er i sin egen library, ikke i denne OS.a-filen. I linken, linker får inn bare hva programet trenger. Hvis du skriver en http server, men ikke en http klient, du får funksjoner om å kjøre http, men ikke om å kjenne http. Så du kan tilføye mange og mange funksjoner til denne library. Du kan tilføye såklert blåte, men det gør ikke for din finne image, fordi din image gikk bare tilføye hva det egentlig bruker. Og det er en ekstra tool som ender denne toolkjene, som tager og modifierer en bootloader. IncludeOS er mest for å designere virtualisasjon. Du ender med en bootable disk image. Det er 100% self-contained og du skriver det i din favorit hypervisor. Hardware ser ut som dette. Det er ingen emulation på moderne CPUs. Instruksjoner i virtual machines er performet direkte på processoret. Og ingen kod er kjært, så virtual machines er egentlig hårdvær-protektet sandboxer. Her ser du noen device, en som er virtual og en som er fysisk. The operating system vet ikke om de er fysisk eller virtual. Så du ender med en image og bruker din favorit hypervisor, så du kan bruke kemiøt med kvm accelerasjon. Du kan bruke vmware og virtual box, og den samme image fungerer på Linux, macOS og Windows når du tester lokalt. Og den exakt samme image som du testet lokalt kan være bepløyd til OpenStack, til Google Compute, og på v-Sphere. Og igjen, dette er den exakt samme image. Så alle testene du gjorde lokalt er valide, fordi du tester den samme kod. Så hva ser dette ut som? Her er et eksempel. Det ser ganske ut som en normal user-basis program. Dette må ikke være veldig svært. Så hvis du skriver dette, du kan testa det i din lokalt hypervisor. Du må gjøre det første gang. Du må gjøre alle smakere, og det er litt bort, men efter det, du gjør bare å gjøre, og gjøre skjæren, og gjøre igjen. Og så er det en kommand som begynner, som heter Boot, som bygger og runner denne image. Og dette er i KMU, uten KVM, i at det er available. Nå, hvis du preferer VMware, så kan du bare bygge kommand. Exakt samme service kan runne i VMware. Og hvis du preferer Retrobox, kan du runne denne image, men her må du adde en logisk namen, fordi VirtualBox gets confused, hvis du får adde samme image Der er også en åpenstappraperskript, så du kan gjøre dette med en linerskript. For å få en spørsmål på spørsmål, har vi en komparisjon mellom IncludOS og Ubuntu. Det er ikke en veldig relevant komparisjon, fordi de er veldig forskjellige operasjoner. Det er bare å give en indikasjon av de relativt forskjeller i spørsmål. Typisk IncludOS-images er 300x småere. De bruker omkring 100x løsning av default. Og dette er selvfølgelig en ganske stor reduksjon i spørsmål. For dere som sitter i bakgrunnen, jeg vet ikke om dere kan se det, men de grøde barne er Ubuntu, og de bløde barne er IncludOS. En minimalt image med nettverkning, som bruker omkring 1.5 megabytes, og en real web-server med resten av API-support og moderne fekter, som Parse and Jason, og så på ca. 5 megabytes, tror jeg. Det inkluder statisk kontent som er servet av webserverket. IncludOS er en single threaded by default. Det skjønner for noen, men det er nødvendigheter. Dette skjønner kompleksiteten, og native APIs er synkroniserende, men der er noen blokkende påsiktskallet for bakgrunnen, kompetibilitet og porting. Hvis dere var her ganske, var det en kompeting-operating-system, og de hadde samme storhet. Du trenger noen påsikts. Her er en eksempel av hva koden skulle se ut, hvis du skriver typisk t-t-t-t-t-t-t-t-t server. Og ikke forløy, at du ikke normalt skriver dette. Includeros kommer med batterier inkluderet, så der er already user-frendelig t-t-t-t-t-t-t server og client-librer som er forberedt. Her er en eksempel, og som dere kan se, du har en typisk kallbak-baser interface. Her har du tre kallbakter, så du ender med en bit av nesting, og der er pre-made libraries, så du ikke har å se denne. Hvis du er lukket, er det utrolig for å reduce et t-t-t-t-t-t-t-t-t-t-t-t-t-t-t-t-t-t-t-t-t-t-t-t-t-t-t. Her har vi en general-proposat-operating-system, og du ser at du har død serviceet, du har skjel, du har død og bakgrunnprosess, og, selv om det var det hele bilden, det var sikkert bra. Men, i realiteten, du har også mye og mye av kallbakter, og bugs i kallbakter er en veldig kommende kallbakter. I en unikernel, død serviceet er redukt til dette. Det er ingen skjel, ingen død, ingen bakgrunnprosess, ingen kallbakter. Så du kan ikke kalle hva som ikke er der. Nå vet du litt om unikernelene, så det er tid til å få filosofiske. Hvorfor er vi her? Jeg mener ikke dette i en metafysikalt sens. Jeg mener, det er veldig praktisk. Hvorfor er vi her? Hvis du kan se på dine badger som du har vært rundt nærmest, så ser du disse logoer. Open IoT, embedded Linux. Nå har jeg sagt til deg om IncludOS, vi er ikke Linux, og vi er faktisk ikke rett for IoT. Det er en veldig utkastende projekte, og de fleste jobber vi har gjort har vært på kallbakter. Men det turner ut at vi har de samme problemer. Vi må også ha bedre måten til å gjøre updates i kallbakter. Hvis du har hørt om Mender, de er i rummet. De har hatt to eksempel sessjoner, og de released Mender version 1.0 this week. Og når vi hørte om deres solusjon, vi tenkte, hey, vi kan probably use that, fordi kallbakter og IoT, ja, vi er i en annen silos, men vi har ofte de samme problemer. For eksempel, vi er arbeidende på en høy available system som trenger live updates. Mender provides upgrade management. It works with full image updates, which is what we want for atomicity and reproducibility, because we upload a complete image, an image that is identical to the one we tested locally. So we thought, hey, maybe we can use a solution from the IoT field. And we have actually tested it, and it worked quite well. I will show you a demo soon, but first I have to introduce you to something called Acorn. Acorn is actually an integration test for IncludOS. It brings together many, many parts of the operating system, and it's a web server with REST API support. It can serve static content. You can service from a memory disk or a virtual block device. There you can do a post if you want to store some data, and you can serve static content. This is the dashboard in Acorn. There's a live update. Here you see what happens when suddenly 10,000 HTTP requests come in. Then the CPU has to work a bit. You see a memory map. You see there is mostly a heap for the application. And you can see the TCP connection status in real time. Also there is statistics. So there is a centrally located statistics for everything, including a service. And on the side there is a timer-based live stack sampling, so you can see which functions are executing. This is very useful for debugging. Also there is logging, where we have logs. This is a normal standard route, but it's routed to an in-memory ring buffer. Each of the components you can see here on the page are individual REST components. They are written separately. They output JSON, which you can probably not read if you're sitting in back, but that's normal JSON, and it gets processed on the front end. So we wrote our own Mender client library. Mender provides a server and a client, but unfortunately not in C++. So we had to write to our own. It's not too big, and for users it's really, really quite simple to use. This is the interface we ended up with, and basically you create the client, and then there are two callback methods you need to handle. You have the onStore. This gets called before the update, and the application needs to store its data. And then again, when the update has happened, there's an onResume function, and you have to implement that to restore any application-specific state you want to store. The client only serializes its own state, so the rest is up to the service. It's totally flexible. If you want to preserve TCP connections, you can do that. If you want to preserve the rest of the things that have been entered, you can do that. If you want to preserve logs, you can do that, but you don't have to. It totally depends on the service and the service's needs. Okay, now we're going to try a demo. And I might have to do a little bit of screen disconnection to get everything set up here. That's the wrong window. Here you can see the dashboard I was just describing. As you can see, it's updating in real time. We are using very little memory, so there's a lot of heap memory-free. And we have set it up like this to be able to see both things happening at once. Her you see some status information about the operating system. If you see the field there called artifact, that's the version, the deployed version of the web server that we are running right now. You probably can see that in the back, but it's helpful, it says error February 8th because this version was made on February 8th and it contained an error. Obviously it's really embarrassing for me to show a version with an error. Thankfully we have a menderer. Here we can see the devices that have registered. If you want detailed instructions about how to use the mender interface, it's really cool, it's really user friendly. Then you should ask the mender guys and they also have very, very good documentation. Here we have the client. This is running the mender client. Every 10 seconds it contacts the mender service and says, hey, do you have an update for me? And so far it doesn't. But we can create an update. Here we, can you see? It's probably a bit hard to see. Here I'm asked to create a deployment and then I select an artifact name and then we select an artifact that's a fixed version that we have uploaded and this is called fixed. And then we click create deployment and hopefully something will happen. The thing is, since the client only checks for updates every 10 seconds, it takes a while, but if you see now in the artifact field, it's now running the fixed version. In the intro to this we said without downtime. Of course there is a bit of downtime. The server was handling requests all the time and this was only a cosmetic fix so there was no reduction in functionality. But of course in the time between the polling for the updates you're still running the old version. It's not like I can force an update from the mender interface. It's initiated by the client. OK, but what if we want to roll back? Let's say that the fix wasn't a fix. Anyway, we can do that. We go back to devices. You probably can't see this. I'm sorry the screen is very small, but here we have the instance is running the version. If you see this is the current software field, it's running fixed. But we want to create a new deployment and we want to go back to the old version. So we select the error artifact and click create deployment. And again, there's a bit of waiting. But already it's running the old version. The reason this happens relatively quickly, the actual updates is done in around 5 milliseconds. But again, it only happens when it gets a new update and the polling interval is 10 seconds there. The entire upgrade takes place in RAM and the image that is uploaded, it's a complete image so you don't end up with one version of old libraries and one version of new libraries. Everything is changed at once. And the instance that is uploaded is an exact same instance as the one we tested and ran locally. So we can be pretty sure about everything working. And again, now we decided that no, we want to go with the fixed version. We have tried both versions. So we create a new deployment and we select the fixed version. We create a deployment. And then we wait. And there you see, we are now running the fixed version. That's pretty, pretty seamless. And at least for our cloud workloads, that's actually everything we need. The vendor client has lots of reporting and campaign management functions. We don't use any of that. We have a very simplified model. But it works in actual practice and that's pretty impressive. So very good job by the vendor guys. And one obvious question people tend to have about this is what if something goes wrong during the update process? In the cloud that's really not a problem because we can just trigger a remote reboot. When we did this, everything happened in RAM. So the backing image that was originally uploaded to the cloud provider is still running. No, it's still stored. So we can always go back to that. And obviously if we did this on a device, we would need to have a watchdog timer so we could make sure that the new version was working properly. And if it doesn't work properly, then you would have to go back to the old version. Ok, so some final words from us in IncludOS. Pull requests are always welcome. We are really here to get ideas from you guys because you guys, especially IoT guys, you know a lot more about updating than we do. So please contact us directly. You can chat with us on Gitter. You can talk to us on Twitter. But obviously pull requests are most welcome. If you want to learn more about IncludOS, I have added some links in the PDF of the presentation. And the demo will also be added as screenshots because I know it's really hard to see it for you guys in the back. Are there any questions? I'm sorry, could you repeat that? Yes, excellent question. What is our supported architecture? So most of the operating system is written in standard cross-platform C++. The only thing that is device specific is drivers. So the only platform we actually support support is x86. But more than 80% of the code also runs on ARM. But the exact hardware specific things have to be rewritten. And it has just recently been split up, so the code should be very easy. You probably need one device driver and a couple of CPU specific things, and you're good to go. Any other questions? No, the question is when the reboot happens, or the update happens, where does IncludOS start? Or does it start from the same state? It goes through the entire boot process, but then there were the callback method on Resume is called just after the boot process. So the client is free to do whatever it wants to do and can continue from where it was. Provided it saved its state in the on-store. Yes, excellent question. The question was what is the boot time of IncludOS? And that depends on the service, but we are talking milliseconds. The longest I think is around 300 milliseconds, but probably around 180. But it depends on the service and what it does at initialization time. The question was does IncludOS support POSIX? And it supports just enough POSIX. It supports what people have actually needed so far, and we are adding more and more POSIX support because obviously we want to run as much software as possible, but it's not fully POSIX compliant, and it will probably never be fully POSIX compliant. There are some things that just aren't relevant in POSIX anymore. Another very good question is IncludOS real-time operating system. No, there are no features specifically for hard or soft real-time, but for many workloads where there are not that strict requirements, IncludOS can probably do the tasks required. The question is what about programming language and the API, and the native API is C++. But it's very easy to wrap with C, and it's very easy to interoperate with C. So if you use a language that can link with C, then you can usually use it. There's a question. Licensing, yes. It's Apache too, but I'm not the lawyer, and I don't play one on TV, so there has been at least one major project that needed some code from IncludOS under another license. The main arcade emulation people, and that was handled, they got a license under whatever they needed. The question is how do you foresee the IncludOS future, and we are mostly working with cloud-related things. Microservices, situations where you need to put up hundreds and maybe thousands of immutable microservices, and you need to boot them quickly and take them down quickly. But it's an open-source project. We take any contribution, and if somebody is interested in using it for IoT, we would be very, very happy to take contributions for that, but we are not actively working on that right now. There was a question over there. Yes, the question is what do you see as our technological market or area, and so far we have been working very much in the cloud domain, but for example we looked at update solutions, we didn't find anything entirely relevant, and then we found the perfect solution from the IoT world with Menderer. So I think these silos will more and more overlap, more and more technology will be transferred across products and markets. The question is if he's doing something with Ubuntu and Apache, could it really take out Ubuntu? Yes, that depends on what parts of, for example, Apache you're using. Apache is huge, has lots and lots of supports and modules. It has lots of modules, I don't know if all of them are supported, but it's impressively big, but sometimes a tangled mess. So if you can work with a simple web server, serve static content, serve up some rest API endpoints, then you can already use include OS. No, but it's really easy to try out, and I recommend that you download it. Yes, the new question? Yeah, what kind of security and libraries are we planning? And again, we are very use case driven, and for example to use Menderer, we needed some cryptography for authentication and stuff like that, and then we use Butan because that was easy to port and can be used in pretty much any C and C++ project. And what we have found is that most standalone C++ or C libraries can easily just be compiled and linked into include OS or with some effort be ported. But obviously there are some really huge things, like for example if you want to do APR, the Apache portable runtime, that's going to be harder. Any other questions? The question is if it only supports rest APIs, and it does not. It supports anything, it supports native TCP sockets, it supports web sockets. Obviously it's only been used in a couple of projects, so it might not be a perfect, standardized, full, conformant implementation, but web sockets is already in for example. So if your device can talk via web sockets, it can talk with include OS. Any other questions?