 Okay, thank you very much. So thanks very much for coming my presentations. I'm Yosuke Kobayashi from CIP project. So at the beginning of this, my presentations, so do you know what the sibling infrastructure platform is? So, raise your hand. Okay, some of them, you know this. If you go, our booth that's available outside, you can pick one Lego for you. So, at the beginning, I should say, our civilization runs on Linux. These systems run on Linux. But this is DevConf, so I should say, our civilization runs on Debian. And this red circle says all systems run on Debian. So, Debian controls turbines for power plant. And also, Debian controls industrial communications. And Debian doing broadcasting. And Debian doing ticket gating. So, this kind of stuff already runs on Debian. And this is just a part of products. So, which makes our civilization actually runs on Debian. This is a quite important stuff. So, why we choose Debian for such kind of system is, Debian, this is DevConf, you know, more than by myself. And Debian has a large community driven ecosystem. And the most important stuff is to ensure free software only in main. So, to make a product, we have to care about free software. We can use this kind of software for our products or not. So, we usually doing a lot of stuff to ensure the licenses and also other stuff. So, Debian has a legal team. And then, when we create our products, we use a lot of type of CPUs, not only x86, but also ARM or sometimes Power still using. So, Debian already supports a lot of kind of CPU architectures. And that's the reason why Debian also popular in embedded area. And then, from a civilian infrastructure systems perspective, long term support is important. And we also say, we already success to use Debian for several products. So, what we done to create products, we did a lot of stuff. We create a file system and also customers' kernels. And we ensure the performance and software updates or something like that. But after we create the product, we have to provide such kind of systems for a long time. So, which means we need a long-term support. And we can easy to say, we need to support very, very long time. There are one thing, power plant system. For power plant systems, as you know, when we use electricity, we rely on power plant. And once we create such kind of systems, we have to maintain at least 20 or sometimes 60 years. So, most of hardware is not able to survive 60 years, but 20 years might be OK. But during this period, we need to support software also. Sometimes we need to fix critical bugs and also critical security fixes. And I think now things change. So, industrial IoT, many persons think about industry IoT or IoT staffs. So, once this world is realized, many devices connected to internet but also connected to each other to optimize our infrastructure. In that case, we also need to consider to provide security management for all kind of devices which relate to infrastructure. So, the problem is this kind of systems has to survive for very long time, at least 10 years and sometimes 60 years. And this kind of maintenance effort currently doing by each company. But to do maintenance for each company is quite difficult for a long time. And the other problem is when we create products, we have to ensure the industrial grade. Industrial grade means it's robust and secure enough and reliable enough or something like that. But even we create the industrial grade, this is just one point, but technology changes a lot. So, we have to catch up the latest technology also. There are kind of dilemmas here. So, and every company also considering similar problems. That's why we consider to have a collaboration framework. So, we need to have our long-term maintenance and we also need to have industrial grade. So, we thought we can make it by collaborations. But collaboration means not just the company because we are using open source. So, collaboration with company and also open source community is quite important for us. So, that's why we need to do this, collaborating in the upstream community. This is the open source community. And civilian infrastructure platform is solution. But this is DevConf. When we create civilian infrastructure platform, we consider which upstream project is important. And Debian is for our upstream. So, CIP already decided Debian as a primary reference distribution. So, we try to create CIP software based on Debian. Between the CIP try to select packages from Debian package and CIP try to work with Debian community. So, there is a reason I already explained. What's CIP again? So, CIP try to create open source base layer. We call open source base layer as a minimal set of base set of libraries and utilities. And with CIP super long term supported kernel. This is a Linux kernel. And this part is a very minimal set of core components. So, we start from a very small and then extend it to fit many kind of use cases. But to fit the use cases, we consider it is quite difficult to do it by ourselves. So, that's why we try to collaborate with Debian. So, this is a concept of CIP base layer. And currently we have a very small set of the team. We have eight companies here. And we, yeah, each company have funding to CIP project. And from CIP project, we would like to contribute to open source communities. For example, Linux kernel is quite important set. And also Debian. So, we not just funding to project, we also try to contribute to something to the project. So, I would like to introduce what we did. So, we CIP started from April, yeah, 2016. And now it's two and a quarter years. So, this is a product life cycle. And this is a minimum 20 years. And CIP is now here. So, it's in early stage. But we already did a lot of stuff. We did this CIP kernel. And we also did this testing framework or something like that. So, in this timeline, every dot reflect some release. And every big one start to collaboration or something. So, from the bottom line, we have two dots with Debian. So, we actually try to contribute to Debian related projects. So, this is a scope of our activities. So, at the beginning of CIP project, we started to create super long term support kernel. We already tried, say, we at least support this kernel version more than 10 years. But when we create a Linux kernel, we also need to test. So, after that, we try to create a testing framework here and also extend it to the build systems. And the other concern is the real time. Real time performance is important for embedded systems, especially for controllers. So, when we create the controllers, each controller has to meet a deadline. That's why we need real time support. So, the first step is CIP SLTS kernel development. And CIP SLTS kernel maintenance period is 10 years and more. So, and official CIP kernel is already available on this URL. And currently, it's maintained by Ben Hatchin. He's here from Cosync. And, yeah. So, to create a CIP kernel, we allowed to backport from the upstream kernel. The reason why we allowed to backport is when we create a product, we need to have hardware support. So, mainly hardware support able to backport. But other steps, we have to be careful to backport it. Because if this kind of backport affect other kernel subsystems, it's quite difficult to maintain for 10 years. So, oops, sorry. So, sorry. So, in general, so out of trees is not allowed to backport. And also, porting to CIP kernel. So, the first CIP kernel is released on January 17th. And the latest one is released one month ago. And CIP kernel release every four to six weeks, which depends on the amount of relevant upstream patches. And CIP also try to review the patches on upstream. This I can skip. So, when we create a CIP kernel, we work with upstream projects. This is a kind of example, what we done. So, in left side, this is a patch review request from Grayclaw Hartman. He's currently maintaining 4.4 stable. And Bayhatching reviewed the patches. And he commented, this patch is not fixed back. This may cause a regressions. This kind of reviews by down via CIP. But currently are mainly maintained by Ben. So, this is an issue for us. Because only one person maintained one kernel. The person, if the person is not able to continue to maintain, we are not able to maintain for 10 years. So, CIP create a CIP kernel team. So, CIP kernel team structure is a CIP kernel team have a maintainer or a mentor. And the current team member work with mentor or maintainer to contribute to an upstream stable. And after, yeah, we, for example, review a patch. And that review result to submit a stable mentor team. We also backport to CIP kernel. So, this is what we are trying to do recently. So, that's why we have upstream fast policy. And this is a quite small character, sorry. I just try to make it a large, but still small. So, we already try to review the patches. So, some of the CIP kernel team member review the next kind of stable patches. And after we review the patches, we post the comment to the next stable mailing list. And after he posted the patches, Ben also review his comment. So, this kind of stuff, what currently we are trying to do and what we CIP kernel team doing that. So, there is some example we already done. And the next important stuff is when we decide next kernel version. CIP, first CIP kernel based on 4.4. And it's already maybe two years old, almost. But during the two years, there are many futures available in the mainline kernel. So, CIP try to consider to pick up the next kernel. So, we usually said the next CIP kernel will be this approximately two to three cycle. And now we try to pick up the next kernel versions. And I said CIP next SLTS kernel versions could be 4.20. 4.20 is not released yet. But already some information is available during the open-source summit in Japan in June, last month. And I also discussed with Gregor Hartman. And he said, next version, if everything goes fine, this version is next LTS kernel. So, next LTS means this version will be maintained by Gregor Hartman for at least two years. But then CIP would like to extend this support period to 10 years. So, by doing this kind of effort, we also think this is quite difficult by ourselves. And we would like to collaborate with other projects such as automotive-grade Linux or long-term support initiative and also Debian. Next Debian, last session, Chris Lam says, the software will fix maybe early next year. So, if the Debian kernel version also able to align that, we are quite easy to contribute to Debian projects and easy to collaborate with Debian projects. So, this is quite important for us to pick up the next kernel versions. And we also try to support real-time Linux. As I said, we mainly create controllers. And that controllers need to meet the deadlines. But unfortunately, real-time Linux is not mainline yet. So, we would like to accelerate the effort. And that's why we try to contribute to real-time Linux project. And we're actually doing that. CIP SLTS and real-time kernel is already available. And this is maintained by Daniel Wagner from ZMS. But he also doing 4.4 stable RT maintainers. So, he currently, he's coming from CIP. And he maintained both 4.4 stable RT and the 4.4 stable RT CIP kernel. Both of them. And CIP RT's first release was done in January this year. And after that, he continued to release. But the release cycle is not stable enough yet. So, I think the main reason was in January, as you know, Spectro and Meltdown is there. So, after that, it's quite difficult for him what will happen and what is the effect for real-time stuff. So, that's why, I think. This is the kernel part. And testing part, we created milestones. And at the beginning, we already created testing environment, which called the border disk. And then start to kernel testing. And current testing, we are doing a very basic test set which includes boot test and build test. But the other CIP members also try to do more complex tests. Not just LTP, but also other functional tests by created by members. So, this is the current status. And this picture is, yeah, actually, I said, this is the border disk. Border disk means, yeah, exactly border to disk. So, one single developer able to run tests on his board on disk. So, this is the concepts why we call the border disk. And border disk also based on the upstream open source project, which is a kernel CI.org and also Lava. So, it's already available on this website. And we already start to continue testing. And all test results is automatically available on the mailing list currently. But we also try to create some dashboards by using a kernel CI. But this is ongoing and not available. So, if you go to this URL, maybe you can find some, but sometimes disappear and back it. So, this is currently under development. So, I actually go to the next one. CIP core package means, so, as I said, CIP would like to create open source base layer. So, CIP core package means packages which includes our base layer and main core part. So, and as I said, Debian as a CIP primarily different distributions. When we select CIP core packages, we would like to pick up from Debian packages. Not only source code, but also sometimes binary. But to ensure the long-term support, Debian ATS project is quite important for us. So, CIP just joined a Debian ATS project as a partner level because, yeah, we would like to extend currently Debian ATS support five years. So, this is a five years, we think, this is a starting point for us. But at least we have to contribute to this five years. Then we also would like to, yeah, discuss how to extend this support period to 10 years or more. So, this is why we joined a Debian ATS project. This was just for these last months. So, before we joined the Debian ATS project, we also discussed with Debian ATS developers last DevConf. So, this DevConf, I also would like to discuss with the Debian ATS guys. So, this is an initial set of core packages, very small. But actually, when we correct the required package set, there are plenty of packages from CIP members. I can say at least 200. But 200 is still part of the old Debian distributions. But we have to careful to pick up such kind of packages because, for example, Java. I think Java is quite difficult to maintain for 10 years, I'm sure. But many enterprise persons want to use Java for a long time. But for embedded area, maybe we can skip or we have to say some limitations. But we have to care, have to be careful to pick up such kind of packages. So, this is the starting point. And CIP core package, we try to, we create CIP core. The difference between a CIP core package and CIP core is CIP core is a set of tools to build reference file systems. And currently, we are using Debian source code and CIP kernel to create a minimum file systems, which can be test on a testing environment. So, but a current CIP core based on not just a Debian binary packages, which means we build source code by using tools. So, there are some similar effort there, but these all three efforts are not directly connected with Debian, but all three projects using a Debian. For example, these two projects using a Debian binary to create a customized file systems. And this Debian project using a Debian source code to create a custom file systems. But why they want to use a Debian is they would like to use Debian binary or source code to get our security support from a Debian and Debian ATS project. So, but yeah, we also consider how to make more Debian friendly way. And they already start a joint project outside, currently outside CIP project, but this data update will be presented at this DevConf on August 4th at 3 p.m. So, if you are interested in this kind of effort, please go to this presentation. And we also would like to know the comment from Debian developers how we can collaborate and how we can make more Debian friendly way. But our requirement is we need to have a customized file systems. Sometimes we have to create 10 megabytes file systems. This kind of stuff also would like to do. But some other projects, it's easy to be able to use Debian binary packages. Just into the Debian binary packages to create 100 megabyte file systems, it's quite easy to do. But we also would like to use same way to create customized file systems. So, that's currently what they consider to do that. And in this project, they also try to create cross-compilerable Debian. And they are posting patches to Debian cross project. And that was done last month. And their patch set is already available on GitHub. So, yeah, we would like to contribute something to Debian project. And this is the difference between Debian current status and the CIP requirements. And at the beginning, we would like to have 10-year support. And we already started to, yeah, collaborate with Debian test project. And we also need to have customized file systems. So, that point of view, we try to post in our patches to Debian cross. And then we also need to have reproducibility here. So, I think a Debian related project, also a reproducible built project is running. So, this kind of effort also, thank you, important for us. So, we should consider how we able to collaborate with such kind of effort. And I think for open source license compliance efforts, currently Debian are also moving to Debian format, but still ongoing. And we already are doing a lot of reviews. And also, we have a review result. So, we try to contribute to this kind of result if no one are doing that. So, this kind, this is what we are able to contribute to Debian, I think. So, there are many staff standard discussions. Cyber security standard is maybe our next thing. This kind of standard is quite difficult to confirm for each company. But if we create one standard test set to ensure this kind of standard, it is more useful for Debian, not only just Debian, but also other open source project, easy to confirm with this kind of standard. So, this is kind of, yeah, we have to consider about that for next step. And maybe this is the year 2017 and also a lot. So, this is the time line. So, we did a lot of stuff. But we consider the relationship between CIP basically and open source project is important. And we created the CIP core here and the border test to testing the CIP kernel and the CIP kernel itself. So, we currently are already done this kind of report with open source community. So, and I think that Debian is bigger and more important for us, which means more important for our civilizations. So, this is what I would like to say in this presentation. So, I'd like to summarize my presentations. So, CIP currently focusing to maintain our kernel maintenance and also testing and core packages, security stuff. And the most important stuff is we would like to collaborate with Debian community to ensure our base layer. So, I'd like to conclude my presentations. Our civilizations run on Debian and contribution and also collaboration are essential things to realize open source base layer with Debian. Thank you very much. So, any questions? Please, any microphone? Thanks for the talk. This is really interesting. I have a question. What ordinary DD or somebody who just manages few packages can do for this? Because, okay, I assume that taking care of that packages are reproducible is important. Taking care that package have auto package test or something is important. Taking care that it can be built on different architectures. Anything else? Okay, so the answer is that make sure that it also cross views. Oh, make sure it's also cross views. It's also important. Maybe Mike is off. The question was, yeah, what is important for Debian developers? Oh, now it's my phone. Not just only, yeah, running on every architecture and able to build and keep updating and what other stuff. And he said cross building. So, thank you very much. Yeah, that's important. I overlook this in your interest to understand if you worry about what might be termed the free riding problem as in, so do you publish all the source code? Is there like a certification system so that, you know, to make sure that people sign up and pay? How does that work? Okay, our source code will publish everything. Excellent, excellent. I'm very glad to hear that. What? Very good. I thank you very much. Yeah. Do you have any like mechanism to try to encourage people to join and to effectively to help fund the development? That's a difficult question. Yeah, no, we are project able to join but then each contribution to directly to CIP is also welcome. But then, yeah, if the company wants to join CIP, they need some budget. But if open source project want to join CIP project, they don't require any budget. Right. And if I'm a company and I join and I have some budget, what do I get my money? I'm sorry to ask such difficult questions. Yeah, that's quite difficult. I'm not sure that's up to you, I think. Okay. The conventional answer, maybe, I don't know. I'm with the Zen project also. And the answer there is effectively influence. And that's not true. Oh, sorry to take it. The answer for the Zen project is influence, which I think many people consider quite important. So if you join the Zen project as a kind of corporate member, you get some kind of additional influence on how decisions are made. And people seem to really value that. And it seems valuable enough that they're willing to pay for that. I think from the CIP perspective, we have to consider which project is important. So if we consider this kind of, for example, the HTS project is quite important for CIP. But if other projects want to join a CIP, it's welcome, I think. But I'm not sure how to do that, sorry. Okay, thank you. So, one more? Can I take one more question? Oh, okay, five minutes, okay. Hello. What is the organizational structure of CIP? Is it a business, private business? Is it a software project? Is it a government consortium? CIP is hosted by Linux foundations. So CIP is one of the projects hosted by Linux foundations. So who makes decisions for CIP? CIP has two committees. One is a technical steering committee. And the other one is a governing board. And the governing board decides the project's directions. But the technical steering committee decides a technical decision. So the large companies that have money to give do they have more powerful say in the decision, technical decisions? Yeah. This whole company is a personal leader, as you can imagine. This company have more power to decide something. But currently, all members, we are very small project and we are going the same way. So easy to say something in technical steering committee. And we can easily agree to something. Do you find that these companies are fairly open in giving their code back upstream to Debian? Does the code that they use from Debian, when they change it, do they give back to Debian? Of course, we would like to do. Because if we change, for example, Debian packages, we have to give it back to Debian. But if we change the upstream project, which is using by Debian, we try to contribute upstream first. Then that code will be back to the Debian automatically. So this is what we want to do. Okay, thank you. I think that was part of the question that was being asked before. Okay. Any questions? Do you do any certification for Linux kernel for safety integrity that you can share with community? Safety integrity in the... Still, safety integrity level? Yeah. We haven't tried to certify it by using the CIP base layer. But we know, yeah, safety integrity level is quite important for many kind of projects. Not only CIP related tasks, but also car manufacturing. But currently, I think functional safety staffs are currently doing by Osado in Europe. And yeah. So we have to consider how to collaborate with them. And we already are discussing with, for example, car manufacturing companies, and what they are doing. But we still not have a concrete plan to produce something yet. Okay, thank you. And thanks for sponsoring DevConf and coming here and showing us all this. Oh, thank you very much. And thank you very much.