 So allow me to introduce myself. My name is Boontan. I'm a technical marketing engineer at Intel's Open Source Technology Center. My goal today is to basically give you a brief introduction to what ClearLinux is and talk about its distinct features, all right? So and feel free to stop me along the way and ask questions. It would be good to have it as an interactive session here. OK, so the agenda that I'm going to go over is why the ClearLinux OS. I'll talk about the security and performance features of ClearLinux and some of the distinguishing features of ClearLinux as it compares to other distros. And then I'll talk about how you can easily customize your own version of ClearLinux very easily with some of the tools that we make available. OK, so why ClearLinux? So as more and more intelligent devices and systems get connected to the internet, we believe that the operating system that run on this device must meet the demand of modern day usages, right? The demand of these modern day usages means that the operating system should be performant, it should be secure, and it should be easily customizable, and it should be easily manageable as well. And we believe that the operating system that meets these criteria is actually the ClearLinux OS itself. ClearLinux is an open source operating system, completely open, and it's optimized for performance and security. And it is designed to work in any range of environments, from the cloud all the way to the edge. And it is very easy to customize, and it's easy to deploy. So people have asked, what is it based on? So the answer to that is ClearLinux is actually designed from the ground up. It is based on all the learnings that we've had in the Intel OTC Center from the years and years that we've contributed to basically open source projects, right? So there's a lot of learnings we've had, and we put all the best features and all the things that we know into ClearLinux. It is an industry blueprint that incorporates basically all that gives you the best performance capability on Intel hardware itself, right? If you buy the latest hardware or something like that, you have Intel hardware, we'd rather you be using a newer operating system that takes advantage of the hardware instead of using a three-year-old OS that you can't take advantage of what you just paid for, right? So we want to give you the best performance, and that's why ClearLinux is there, is basically it knows how to take advantage of all those things. We work to optimize it as much as possible for Intel. That said, it does run on AMD, and it also runs on ARM as well. So Intel has FPGA hardware solution, and we know that it runs on FPGA for sure. ClearLinux is available on our website at ClearLinux.org. You can get it on cloud solutions such as Azure and AWS. You can find it on Google as well. We have many ways to run ClearLinux, so there's also Docker as well. So let's talk about security, right? So security is very, very important for ClearLinux and for Intel in general. We want to make sure that the software that you're running is secure. So what we do is we actually stay and we do a constant CV scanning all the time. If there's any patches or anything that needs to go out, we'll get it out in less than 24 hours, right? So we don't wait three months. We don't wait six months or a year to basically roll out the next release of patches. We are a rolling release. We do, on average, we do up to 10 releases a week, so there are small incremental updates. But any updates that needs to get out, we'll get it out as soon as possible, so you don't have to wait for it. OK? So in terms of security, we also offer a unified trust store, so this is where your certificates can be stored, right? That way, you don't have to deal with multiple trust stores. Certain distros have multiple, and I've heard from developers that it can be quite a pain to basically have to deal with multiple ones. So a unified place is where it makes it easier. In terms of industry standard security features, so out of the box, some of the software that we install, we configure them to be as secure as possible. We close up a lot of loopholes or unknown ports and so forth, so that out of the box, it's secure, and then you have the choice to basically go and configure what you need for your own usage for it. OK, so in terms of performance, we actually optimize throughout the entire stack, right? We don't look at just one area of the operating system. We look at the kernel, we look at the drivers, we look at runtime, we look middleware, all up and down the stack, right? We want you to get the best performance and the best user experience out of an operating system and the software that you install on ClearLinux, right? So we do a lot of work to make it better for the user. So these are some of the things that we do to basically optimize the OS to run best on Intel hardware. So at the kernel level, we always ship with the very latest, and we do make older kernels available as well if you need it. So and then in terms of library, we leverage runtime optimizations and that allows you to basically auto-select different libraries at runtime. So for example, if the AVX2 and AVX512, right? So if the hardware that you have will support AVX512, when your software starts up, we will automatically select that one instead of going to an older one, right? So you get the best in that sense. And then in terms of compiling software, we use compiler flags and basically that aggressive compiler flag that takes advantage of the hardware that we have on there, right? So okay, and then on the latest hardware, our AVX optimization library is selected at application runtime just as I was stating earlier. So okay, let me know if you guys have any questions. So here's an example of some of the optimization work that we do for the TensorFlow library, right? So that we ship. So at the kernel level, we tune, we tune the kernel for critical workloads. The GlibC library, we add additional routines for AVX512. And then for Python, we add the AVX2 and AVX512 optimizations for Python. And then for these modules, we optimize them like the NumPy and the Pandas. And then we have AVX512 optimizations for the eigen C++ template library. So and then obviously we use the latest GCC compiler and we use all the flags that basically, so that it would take advantage of the hardware that's available that you have there. So okay, so some of the other distinguishing features of ClearLinux. So ClearLinux works at a bundle level. It doesn't, people have always asked me like, which package manager do you use? So we don't use a package manager, we use, we deliver software through bundles. A bundle basically consists of packages, but we was, but we were inside the bundle, we list all the packages that you would need for that bundle to work. A bundle is a functionality that you install, not an individual package that you install. So as an example, like in, let's say that you want a Kubernetes, you want to enable Kubernetes on your system, right? So what you would do is you would install our, what we call our cloud native bundle. The cloud native bundle consists all of the Kubernetes capability binaries and any dependencies that it needs to install in order for Kubernetes to work out of the box, right? That way you don't have to go and search for yourself, oh, I got to go get this package, I got to go get this package and they get to go with this package, right? So at the development side bundle, sorry, at the build time on our side where we curate the bundles, we have the list of packages in there and then what gets delivered to the client side at the end of the day is actually a list of files that have broken down from the packages themselves. I hope that makes it clear to people, right? So the client doesn't have any concept of what a package is, it just installs files and the files are basically when you install a bundle, you get a manifest and the manifest lists all the files that gets installed with that, okay? So again, we resolve all the dependencies at the upstream side, not at the install or runtime. We also, again, we curate many, many bundles. We have close to about 200 bundles at this point from our upstream side there. So in terms of updates, so this is our update principle. So again, we don't work at a package level, we work at a file level on the client side. So if there's an update, the update is very small, right? Generally, what we do is we push out delta updates. So if there's an update inside a particular package, for example, typically another distro, you would basically have to deliver the entire package over and then go through and install process to update it, right? What we do on ClearLinux is that we, if there's a small, whatever the delta updates is, we send a delta and then we patch it into the system itself. So it's quite small. So it's lightweight, it's incremental. So like I said, we do about, on average, 10 updates a week. So that way you don't have to take down your system to do a big update or anything like that. It's a rolling release, so it's done in the background. So we do a whole system update. So that means that you don't choose what you update on your system when you go from one version of ClearLinux to the next version of ClearLinux. Whatever bundles you install in that system, if there's any update in there, whatever gets updated, it gets updated to the next version of ClearLinux itself. So and how we control, we have a version control method where you just have the version of the OS itself. You don't, so and then that version number basically dictates what list of packages in the versions that go into that version of ClearLinux, right? So that way if you have, like say if your coworker is running version 10 and you're running version 10 and you both install the same set of bundles, you know for sure that you both have the same set of software you would never have to guess, try to figure out do you have this and do you have this, right? That guarantees that it makes it easier to compare systems and for development purposes or validation use cases it's very easy and even for deployment, right? So if you're deploying a farmer servers and they're running a particular version of ClearLinux in the same set of bundles, you know that you would never have any discrepancies between them because the version number basically dictate what goes into that. I hope that makes it clear. Okay, it's a hard one for people to get the concept of at the very beginning. Anyway, so by default the OS is set to auto update but you can disable that and choose to update yourself whenever you want to. So you're not forced to take everything that we put out. Okay, so the other one is that we have a concept of a stateless operating system. So in some distros when you install packages and software configuration files kind of get installed in different places and installed in ATC and so on the user installed in your home directory, right? What we do is that we segregate what the operating system owns and what you own, right? So when you install software, when the OS install software all the configurations that it needs, the minimum configuration that is done to make the software work is put in slash user which is owned by the operating system itself. And then if you want to do additional configuration or override additional settings, you would put that in slash ETC. So you as the system administrator would own that and then you can also do additional configuration in your home directory. Now, let's say you actually deleted ETC for some reason, right? In the ClearLinux case, the system is still actually recoverable and it will still boot. What it means is that when you delete ETC, it just sets the system into a factory reset, right? So the minimum configuration that's in slash user still works so that the whole system will still boot. You just won't have your custom configuration in ETC. So in that case, as a practice, what you would want to do is do all your configuration, backup your ETC and then if for some reason ETC gets deleted, you can boot it up, log in as root, set a new password for root, restore ETC and you're back up and running in no time at all. I'm seeing some eye rolling over there. Does that make any sense? Yeah? Okay. We were blowing through here so, all right. So another thing that we have in ClearLinux is a telemetry solution. So this is an opt-in solution, right? So I underlined opt-in because people always get scared whenever they hear telemetry, right? So this is something that the user has to turn on. It's not something that's turned on by default, right? It's a lightweight client solution. The client side basically sends probes information to the server side, right? Of any software anomalies. Again, we don't collect personal identifiable information. It's mostly just information that you want to put into the probe itself for debugging purposes or for OS crashes or whatnot, right? We have, I mean, the OS itself has probes in there but if you don't turn it on, that stuff doesn't get sent to us at all, right? So you can actually, so the telemetry solution is very customizable. You can actually set up your own telemetry solution using ours and then your client, you can configure your clients to basically send the telemetry solution to your server instead of to the upstream server itself, right? So we use this solution as a development tool because it helps us to basically figure out where all the bugs are or where the crashes are and then we basically analyze that and patch it and then send updates right away, right? So this is how we're able to move fast very quickly is that we get things out there. If we see any anomalies or any issue, we'll patch it and we'll get it out right away, so. Okay, so I'm gonna talk about customization. Does anybody have any questions so far? No? Oh yeah, go ahead. So we build it twice. I think what we do is we build the library for the base hardware, a base older hardware, right? So our Westmere platform and then we also build for the newer version, the latest hardware so that the dynamic linker can basically pick and choose at runtime. That's how I was explained to me, so. Yes? Okay, you don't see the KVM version? Okay. Yes, so yeah, I'm happy to help you after this presentation. Okay, okay, great. Yes? Yes? Yeah, no, so we actually, so what we do is we actually build all the packages ourselves. So we take all the upstream sources and then we go put it, feed it through our tooling. We have a tool called Autospec which is basically an automated way of building spec, RPM files, right? What this does is you feed it a tar ball and it analyzes the tar ball and looks at the build patterns in the make file and basically helps it you to generate a spec file out of it and it builds the RPM for you. For the most part it will do 80% of the work for you because it is able to intelligently figure that out, right? And then it'll spit out the tar file and then you put, sorry, the RPM file and then you put the RPMs and then you basically put the RPM files into your bundle and then we go through a build process where it decomposes the packages and then creates a manifest of all the individual files that goes into all the package, in the actual RPM package. We send the manifest to the client side and then the client basically looks at the manifest and said these are all the files that I need to install and then these are all the, and then it checks, we send a hash for every single file so that we can make sure that it's secure, right? So then we go to install the file. So the client doesn't have any concept of packages at all. It just basically installs file directly onto the system itself. Does that make sense? Yeah. Okay, go ahead. Yeah, that is a good question. Right now we don't have the concept of a long-term release or right now we're a rolling release but we have heard that question before and we are looking into it. There's something that we could potentially do in the future to basically provide that capability, right? But right now it's a rolling release and but we do do a lot of QA and do a lot of work to make sure that what we put out is good. No, the auto update is enabled by default but you can disable it right away and then you can then choose to update to a particular version that you want, right? Another thing that I actually wanna mention is that our update tool which is our installer slash update tool is called SWAPD which is SWPD it's software update daemon, right? And that tool allows you to basically specify which version of Clear Linux you wanna go to. By default it's always tries to install the latest but you can actually roll back to a particular version if you wanted to, right? And what happens is that when you roll back or you roll to another version it would basically look of the manifest for that particular version of all the bundles that you installed and then update those files according to that version of Clear Linux that you're trying to go to. You're right, right, exactly right. Yeah, you can go to an older version but people like to do that sometimes for different reasons, right? But the capability is there. Another thing that I really like about Clear Linux the SWAPD tooling that we have is basically that if you, let's say that you actually deleted some files in your system because we work with manifest, right? And bundles, what you do is you do, we have this capability called verify fix. What it basically does is when you ask it to do that it basically looks at your bundles and it knows that what's in the manifest and it goes check your system and it goes, oh, if this file is not there it will actually go and fix that for you right away or if you modified something and it's not according to the hash for that particular file in the bundle it will actually restore that. It's basically a system restore capability, right? So it's a nice way of ensuring that you have system integrity with this capability. Yes, sir, exactly. Yes, yes, it's a list of RPMs and then we break the RPMs down into individual files within the RPM, right? And the individual file is what gets sent to the client side to get installed. We don't send the RPMs to the client side itself. Just because we're trying to use what's, and we use the RPM packages just because that's what the rest of the world we still do that essentially, yes. You can install an RPM on top of your system but then the OS doesn't manage that, right? Because remember the OS has to have the bundle list and the manifest that's installed on your system, right? So if you can install an RPM package but that means that if you ever do a verify fix to check the integrity of your system and you give it this dash dash picky it will go and find stuff that's not there and delete it out of the system because it doesn't know about it, right? Yes, yes, on the system and so we don't keep a database of install packages. We keep a list of the bundles installed on your system. Sorry, I mean you can force install an RPM without, yeah but you wouldn't know what dependency you would have to resolve that yourself, right? But you can install an RPM, I've done it so and but like I said, the OS doesn't know anything about it so when you go do a system integrity check it may delete it, right? If you tell it to. Yes, do I resolve file? We detect that at the build side so we do bundle testing on the build side so that we know what, you know so that they don't collide with each other. Yeah, like I said, yeah, we take care we do all the hard work on the build side, right? We have servers that basically go through and build these bundles and test them and things like that. And then again, once at the client side all they're doing is installing discrete files that's listed in a manifest so you don't actually have to think about what the dependency issues are. How do you expect, how do I expect third party applications? So there is a way to do that. For third party you can, there is a, you know so because ClearLinux is all open source, right? So we only ship open source software so we don't package proprietary software at all. So if you had stuff that you want to, yes, you can build software that you can install, right? That's what I was gonna get to. So we have, and I can talk about it in the customization area part of this presentation but basically we have a tool called Mixer that allows you to basically create your own distro and you can actually create your own bundles and I'll talk more about it here in a bit, right? And then we have another tool called Mixin which is a wrapper for Mixer but that allows you to create your own bundle and put your own package in there and install, side load it into an upstream, the upstream version of ClearLinux or instead of a forked version of ClearLinux and I'll get into a little bit more about that but keep asking me that question if this still doesn't make sense, all right? So any other questions before I get into the next section here? All good questions. All right. So modular for customization and control, right? So on this diagram here on the top right side you can hear the blue boxes here, right? So this is the normal upstream version of ClearLinux and the clients are using the upstream version of ClearLinux, right? They're getting all the updates from us, right? But let's say that you want to become your own OSV or you want a forked version your own flavor of ClearLinux, right? You don't want to get all our updates all the time you want to be in total control of that, right? We have tooling that allows you to do that and that tooling is basically called mixer, right? The analogy that I like to tell people about it is that you like to eat food, I don't know, tacos from the factory, right? And all the toppings that comes with it but maybe you don't like certain things, ingredients in the topping so you can go and redefine what those means and the toppings are basically the bundles and you can go and redefine what goes into bundles itself, right? You're modifying what packages go in there and then through the mixing process it's able to basically generate your own ClearLinux image, right? So it becomes a forked version, okay? So the key part right here is this here you don't need to recompile the OS if you want to basically create a forked version of ClearLinux. Remember a bundle is just basically a list of binary packages, right? And all the packages that we build are all available upstream on our server so when you redefine a bundle and you specify a particular package that we already have it will just pull the packages into your mix and build it for you so you don't actually have to recompile code at all, right? The only time you would have to actually compile code to create a derivative of ClearLinux is if you want to basically build your own software package, right? So for example, if you want to build your own Hello World software and we don't have it available upstream already then you would go through the Autospect tool to basically build an RPM package and then you feed that through Mixer and then you build a bundle out of that and then you basically put that on your own update server where your ClearLinux will then pull its updates from, right? So basically at that point you've forked, okay? Does that make sense? So we actually use Mixer ourselves so you could see at the top part right there so there's ClearLinux.org release, right? So every time we build a package and then we update anything in a bundle we feed it through the Mixer tool itself we generate bundles and we put it on our update server and then all the, you know, our clients consume that, right? So that's the same way for you if you wanted to build your own version, right? You basically just set up a web server, you go through the mixing process, create your bundles, create your own version of your, set up your own version of ClearLinux, create an image and then your images would basically pull the updates from your server itself. So you're not required to basically, you know, you're not required, if you create your own version of ClearLinux you're not required to take every single release that we put out, right? So this diagram here basically shows that, you know, the penguin here is basically all our, you know, daily, weekly releases, right? And then these up here are the upstream packages that we put, incorporate into ClearLinux. Down here is your custom version right here, right? So you can choose and you can pick and choose which one, you know, which release of ClearLinux you wanna put in and which bundles you wanna put in there yourself, right? So you're not forced to basically take everything we release, so. It's very, very customizable. Security updates? Well, security, I mean, every security updates all go through our normal regular releases, so. But yes, so you, you know, if you want, well, you can pick and choose which ClearLinux release we put out, right? Do we specify which one has security releases? All right. Let's say that the one on the left hand side here. Yeah. You guys have moved along. Yeah. You would have to basically take the next release that has the security patch and incorporate it into your mix, right? So you're not going to backport anything? No. Right. We're trying to move forward. So it's not this. Yes, you can choose which one you want. Yes, in the sense that you don't have to take every release. You're not forced to incorporate every release into your mix. Yeah, if you want a feature, you have to go, you have to go up and update, yes. What's this feature? Security features. Security features, yes. So any other questions on this at all? Yes, go ahead. If you do an update, will the auto update be turned on? Is that the question? If you do, so when you disable auto update, it will be disabled, and then you can manually update to another version of ClearLinux that may have the secure boot update, right? If it's updated in the next version, if it's enabled, yes, you would probably have to do that. Yeah. Questions? So, yeah, go ahead. So the mixer, it's just a chooser, or it can build, I mean, how to build the package? So let me go here real quick, hold on. Have that diagram here. So let me see if I can find it. Okay, hopefully I can describe this right here, right? So this is the process that we go through, right? So on the left side, we have a tool called Autospec. Autospec is what builds your source and turns it into an RPM file, right? So this is basically RPM build, but it's highly automated for you, right? So you basically feed it a tar ball, or, and then what it'll do is it'll generate these RPMs for you, right? And then what you then do is you go and create your bundle which contains your RPM files, right? And then mixer is what helps, it basically generates the bundle for you, and what you do is you go and define what goes in the bundle as part of the mixing process. It does, yes, exactly, yes, exactly. It's just like, you know, think of it as a, you know, a food preparation process, right? The Autospec is the part where you go and, you know, take the basic ingredients and cook and make something, right? And then mixer is the bundling process where you package it up before you ship it out for somebody else to consume it, right? Mm-hmm, it's required by other. That is a good question. I think if there's dependency, I think you may have to do that, yes. I don't, so I'm not, you know, I don't know that answer off top of my head, but if you, would you come to the Intel booth and I can find someone to answer that question for you because that's probably, the developers are probably better at that than I am, so. Yeah, but please come by. Okay. Questions? You don't really have an option to pick arbitrary versions of the package. The ones that you pick, that's all the self-sufficient income from supporting each other. Yeah, so we try to always use the latest version as possible, right? So the tarp, are you talking about from a tarp ball level or from just any? Same project. Right, we always try to incorporate the latest as possible, so we tend to, yes, we do that. If you needed an older version, then yes, you can go and probably recompile and build your own bundle using the older library or an older version that you want, right? And our developers are well aware of that and they try to make the best balance that works for users, right? You know, we still use, for example, with Python, we still, we offer Python three and we also do point 2.7, right? But eventually we want people to basically be using the latest as possible. Any other questions? So basically we have all sorts of avenues for you to basically try out ClearLinux or use ClearLinux. I mean, you go to clearlinux.org. All our source code is completely open source. Again, it's a reference operating system. We would love it if anybody wanted to take any of it and incorporate it into their own, you know, steal it if they want to, right? I mean, it's completely open, so. And we have a public IRC that you can go to for any questions or help that you might have. And then we also have a public mailing list as well. I'm also doing demos downstairs, or is it upstairs? I think it's upstairs, yeah. So come by if you have additional questions that you might have at the Intel booth and I will be happy to try to answer as much as I can. And if I can't answer it, I'll get back to you over email and get you the correct answer. So with that, it's five till. We have five minutes. Actually, no, I think it's 40 minutes, right? So 45, okay. Any other questions? Thank you.