 Okay, now it's the time to start. Hi. Hello. My name is Tsugikazu Shibata, come from Tokyo, Japan. Sorry. This session will be updated for the long-term support initiative. How many people are well-known about LTSI? Oh, thank you. That's good. In my first page, my name is Tsugikazu Shibata, working for NEC and a founder and project leader of LTSI, this project. I'm involved with Linux kernel since 2.4, maybe 15 years ago or so, and worked for both industry and community. For the community side, I have provided a translated version of how to document and so on. It was translated into Japanese. And also, I'm a board member of the Linux Foundation. The Linux Foundation is covering a lot of interesting open source projects, but I'm hopefully trying to keep Linux in the best open source project. Before going into details, let's look at the Linux is running where? Actually, Linux is running a multiple use case. New York, London, Tokyo, stock exchanges using Linux and every day, every single minute for the network infrastructure. In Tokyo, lots of people are using, even not even in Tokyo, lots of people are using Linux for their smartphone or transferring their own voice and text messaging. Amazon, Google, Facebook and Twitter, such kind of social messaging service for the infrastructure, Linux is running every day. And also, smartphone, TV, camera and router and lots of embedded devices running on top of Linux. And also, as Linus and Dacondale mentioned in the panel discussion, lots of architecture is running Linux. And the most important point is that all those come from a single source code. And by a single source code, they're covering all these activities. That's Linux. And how the Linux is developing, more than 1,700 developers, more than 230 companies joining Linux kernel community every release. And nearly 1.5 million lines of code, 4,000 files are increased. And that is the Linux developers community. And also, 26 years of history is long. It's not a young project, but it's really stable and useful. And the most important point is that the maintainers have a great skill to manage the subsystem and professional knowledge about how it's technologies. I think the Linux is the best technology in the world for Linux, no, Unix like a kernel. Because of these kind of skilled developer maintainers gathering to the single place. Here is the latest status of Linux kernel. As Linus mentioned that 4.10 was released in last Sunday. And the source code is 22.8 million of lines. It was increased from last kernel 4.9. It's 491 kilolines. The files were 57,000. There is 966 files were added from 4.9. And within 70 days. 70 days means 10 weeks. Within 10 weeks, this development will happen. That is continuously happening. And also current stable kernel is 4.9.11. And the development kernel is in the margin window toward 4.11. I will explain some more details for this kind of development process. So how many kernel is providing every year in this picture? In 2014, there were six kernel version was released. It's something like 313 to 318. In 2015, there were five release were happened. And 2016, six release were happened. So yearly five or six version are released constantly. Within 65 days to 70 days. From 4.7 to 4.10, it took 70 days, just 70 days. The same release time frame, same release span. It is kind of a well coordinated development process. And also, this is a Linux development policy. The upstream is only the place to accept the patches. Because of the Linux, it finally decided to propose the patch into mainline or not by a reviewed skilled maintainer. And tested with other proposal to confirm without any conflicts. And we will coordinate the development process over thousands of developers, so that lots of developers get together, review every single code, and merge into Linux. That's upstream. As I figure out this picture, upstream includes always new features, proposed experimental features plus fixes. That is bugs and security fixes. These old patches come to the single place. That is upstream, so that upstream is a single place to accept the patches. Here is the Linux development process. We are in the merge window of two weeks, because our 4.10 was released last Sunday. And mostly after merge window closed, Dash RC1234 was released every week end. The Linux is mostly releasing Dash RCX on Sunday, so the developers start the result of the merged source code and check it and send patches or fixes, and then Linux will merge on Sunday. And then next Monday, developers start. That kind of weekly development process is happening in the most of the last few couple of kernel releases. And this time, Dash RC8 was released, and then 4.10 was released, so that two weeks of merge window and also eight weeks of stabilization, that makes 10 weeks. That's the development process of Linux kernel. It's really well-coordinated. And here is source code growth from 4.0 to 4.10. It's not so much understandable. The lines of code is too much, but you can see the constant up source code. This is still 26 years later, still this code is growing. This is the power of Linux kernel community. Okay. Here is the rapid release cycle. Nearly five times or six times of kernel release means that we have a chance to more code merge into the Linux. In other projects, maybe six months release cycle, that means that nearly two times so to chance to merge the new patches. So that's 26 years of experience of Linux kernel development. So we have many chance for our own products to send patches to upstream and merge into that. That is, it's good things, but on the other hand, we need have deeper knowledge to pick right kernel version because of nearly five times and need to find out if this one is the best one to use long term. That is a problem for industry purpose. But for people who don't want to use experimental release but wanted to use the latest kernel, for that purpose there is a stable kernel release. This one is called 4.10.1, something like that. But a lifetime is just for the one version like this picture say. And when the next version was released, then stable release was happened, then all the stable kernel becomes end of life. This is one of the best kernel for the expert, people who wanted to use the latest version but don't wanted to use current experimental release. But this lifetime is so short, so they're not so much useful for industry purpose. I will talk about a more long term release, but let's get back to the latest status. I mentioned 4.10 is the latest release kernel, but the current stable kernel is 4.9.11. That means here is a current stable kernel and then 4.10.1 will be released, then 4.9, maybe 11 or whatever will be end of life. And now is the time of merge window that is right here and then maybe two weeks later on Sunday, 4.11.1 will be released. That is a kind of expectation will be really easy. That is mentioned by Lena Stobals in the panel this morning. People mostly interested in LTS that Lena's also mentioned is that extended release for stable version that is maintaining two years and pick one version per year, that is called LTS as Lena's mentioned this morning. So that once LTS decided, that will be continued to maintain in two years and also in parallel stable release will happen and each of us table is patches in back porting to on top of LTS. That is LTS. And this is maintained by Greg Hartman, he's a fellow of the Lenax Foundation so that that is really neutral activities. So why LTS? It's only the tree to get fixes from the community. The community will provide a lot of fixes on top of upstream and that will be back ported on top of LTS. And this fix will be released a number of times and should be applied frequently. Security and Bank Fix is being more important for industry purpose. So what is how many versions are currently provided from the community? This is the list. Most upper portion is 4.9 is the latest proposed fix, the latest LTS version maintained by Greg and that was released last year, December 15 and a projected end of life will be January 2019. Another one is maintained by Greg for 4.4, that was started last year. As some other people are maintaining, Sasha Revin is maintained 4.1, 3.11. He was an employee of Oracle for the purpose of Oracle Lenax but now he's moving to other companies so that maybe these ones are neutral. But 3.16 is maintained by Ben Hutchings. He's working for Debian Stable Canal so that 3.16 is for the specifics for Debian. ZD Slubby is working for SUSE, so the purpose is SUSE Lenax. And will it tell you it's a French network equipment engineer is maintained 3.10 for his own older router purpose. ZD Leed-Zephan is working far away for their own devices and Ben Hutchings is also maintained for Debian so that for the purpose of our own devices that should be really neutral so that Greg's one is the best version and 4.2 was really old and 4.9 is expected to be a longer term purpose. That is the best one I think in this point of time. How many overfixes are included in each of stable or long-term versions? I counted the number of fixes from 3.0 to 4.9. Let's look at the right one. No, sorry, the left one is LTS. So let's pick up 3.10. That is still maintained and 5,727 fixes are included in 104 releases. So if we can backport these 5,000 patches on top of our own product it's so hard, but using this one is really easy. That's the value of LTS. And 3.10 is really old. So the 4.4 was released in just last year. It spent about one year. That is also included 3,600 of patches. So this is the real value of using LTS. And also, stable version is mostly less than 1,000 patches in 70 days in a lifetime. So that every one release less than 1,000 of fixes provided in upstream and maybe need to backport in a real industry purpose kernel. That depends on how we can use the kernel portion, which plays the kernel portion we are using. And I also counted the number of fixes yearly so that 4.9 is just released but still 800. 4.4 was released in last year. It spent 1.1 years. That means 3,300 fixes yearly. And 4.1 was already spent 1.6 years. That means 2,000 fixes included. So using LTS is a lot of value for industry purpose. That is the point I wanted to tell this. So we can understand LTS is really valuable. What is LTSI? LTSI is an open source community to create and maintain Linux kernel for a long time based on LTS. And we will have a chance to more patches to be included on top of LTS. That is LTSI. And it's the same lifetime. And also we have a having a lot of workshop and place where the discussion each other or the issue and problem happen. And then some other party have same problem and they have a workaround that will be able to share using LTSI mailing list or workshop and so on. Here is picture what is LTSI and LTS. Most bottom portion LTS have release one version per year and maintain 2 years. And the free country and large number of bug fixes are provided from the community. We are mostly using Greg Cohartman's LTS. Always using that. And on top of LTS we will be able to add vendor-required features as a purchase and share status information problem among industry people about mailing list and workshop. And huge testing by contributors. There is number of company seriously using LTSI so that that company will test in the LTSI's development process and report back to the mailing list. That will be one of the value for the industry purpose. And also we have all test framework. That name called FUEGO. That meaning by a team board he had keynote no organizer of this ELC. And we have providing help developer for upstream. The number of people ask us and then Greg Cohartman help them to send parts to upstream. We have this kind of framework of LTSI. Here is the history. We have established LTSI activity in 2011 at the ELC Europe Prague. And that was started for the purpose of Android because in that time Google provided the Android distribution every six months with every time other kernel version is used so that we have lots of problems every time six-month cycle new kernels happen, how to stabilize, how to testing that for by each individual company. That was so hard that people get together and try to create this LTSI project. And after that we have discussed with YOKTO project that was presented by Imad Soussu in this keynote. YOKTO we have discussed with YOKTO as included LTSI kernel for them. And also we have had a workshop and session to share information most of every Linux foundation's event. And also we have released this kind of kernel version for yearly basis. That's a history of LTSI. And the shape of LTSI project, this is a really small staff we have. Three, four staff is not working for full time but coordinate workshop and session at Linux most of the Linux foundation's conference to share between the people what are the status of Linux kernel development, what's the value of LTS. And also we invited Greg Kohartman as a maintainer even for LTSI so that Greg is maintaining LTS and also LTSI. That's a really great situation. And we are not paying any money for him because he's a fellow of the Linux foundation. And we are working with upstream kernel community to find the issue of how the kernel community is looking at industry. And we are discussing with kernel community the situation of how the industry is doing hard but what is the thinking of Linux kernel community. And we are standing on intermediate stage and try to create, try to say our opinion to community and try to transfer what is community's thinking into industry that is our position. That is a neutral and to be able to use for more variety of purpose. In that sense, in the kernel summit last year in December time frame there was a huge discussion that happened of the upstream fast policy that this one is very old days of Linux distros. In that time upstream fast policy discussion happened around 2005 or 2007. In that time there were SUSE Linux or Red Hat Linux trying to provide their own distribution and then they pick one version for Linux kernel and then new fixes will be back ported in the green circle to back port and then user will use such downstream kernel. But in that time there was not enough feature is implemented into Linux kernel so the user wanted to add their own patches to for the next version. So the users are asking, always asked to downstream distributors. It's really easy. But so that this will happen that they need to pick the patches from upstream and also users. It is so hard. So that's a lot of discussion happened and then community and distributors decided the upstream fast policy that is like this. All the people wanted to add their own patch to the next kernel then send patch to upstream to merge into a newer version and then newer version will be used by the distributor and then user can use distributors kernel. This is the upstream fast policy. As I mentioned upstream is a single place to merge the patches into the latest kernel version. This is upstream fast policy and nowadays lots of community is stating we are using upstream fast policy not just a kernel but also some other open source communities. This is really important. This is not just a kernel. If we use some of the database open source database and add something to our own patches into the database but the database open source database is more development and then newer version have no feature another feature then our own patch will not be able to run. So that upstream fast policy is important for every single open source community. But it is not so easy because our production kernel is kind of this figure that we will use kernel from SOC vendors. SOC vendors mostly use LTS and plus their own patches for something maybe depending on SOCs. And for our own development process we will add our own changes features, drivers and fixes according to development of our own product so that except LTS these other patches need to be merged into upstream then that will become the LTS that is the upstream fast policy but it is not easy because LTS is only back ported from upstream fixes and securities no chance to add the new fit our own drivers and fixes so that LTS try to find a chance to merge these patch into LTS i3 on top of LTS that will cause more chance to include our own features to our own product. Here is the development process of LTS i. Once LTS i version was fixed then we will announce preparation timeframe that will take 4 to 6 months that means two of upstream release process within this 4 to 6 months you have this kind of our own changes to be upstreamed and then we will open up the merge window during that merge window timeframe we will be able to send patch to LTS i mailing list that will be a chance to merge such latest upstream features on top of all the LTS version that is the value of LTS i and we will have one or two months of merge window process and then Greg will review each individual patches proposed for every industry people and then merge into LTS i3 and then release Dash Rc1 and after Dash Rc1 was released one month of validation period will happen and then release it that is LTS i process here is the latest plan of this year's LTS i development we are in this timeframe today is the day for announcement of this year's LTS i development we will start preparation phases for 6 months that means we will have a chance for 4.11 and 4.12 your patch can be proposed to Linux kernel community and then we will open up our own merge window from early July to end of July and within that month Greg will review the proposed patch and merge it into LTS i3 and the validation period will be one month during August timeframe and then that will be released in early September hopefully if any of the big problem will not happen and then we will ask YOKTO project to be included in their new release in YOKTO 2.2 that will be hopefully happening in the end of October and then you will be able to use LTS i with YOKTO on top of 4.9 plus your own patches that is a current plan and we will soon announce this development plan in LTS i mailing list if you are interested in please join us our own mailing list and looking at what will be happen and also we have a plan to have our own session for the Linux Foundation event such as open source summit in Japan and also open source summit in North America and then Linux conference Europe and so on This was a plan but for this year's challenges I try to figure out how about 64 bits in 4.10 release Huawei or LG's Nexus 506 64 bit support patches merged into 4.10 and some other devices like Reneta some other SOCs 64 bit patches also merged into 4.10 not just 4.9 so that will be a chance to backboard on top of 4.9 LTS i version and another point is that that will be started both 32 bits and 64 bit error that is some what migration from 32 to 64 bits takes long term, long years that we are already having experience for Windows 32 to 64 bits or 16 to 32 that takes long years 4 or 5 years so that maintaining two apps and libraries may become a double effort so that burden will become big so that I this is my own opinion but earlier we need to decide just only 64 bits not just having 32 and 64 bits Apple is starting to move to 64 bits and application may not prefer running on top of Mac OS X that is happening that is one of the issue another issue is that VM support KBM then on top of architecture maybe necessary or not that is a really important point but who will own the development of KBM on top of architecture it is so hard not just a single company can achieve the result so many people get together maybe a single place to test VM support that is required maybe LTS i is okay or not I'm not sure but depending on the people we will be able to help something and on the other hand containers support Habat container the container is starting from IT infrastructure but container for the embedded area container is maybe used for packaging technology for delivering applications so that it may be okay for the future usage for the containers but container right now developing on top of X86 architecture for the servers and on top of 64 bits so that using container on top of ARM and 64 bits may take more development resources so that this one also need to think about for the DCS development we will be able to use this technology by back porting on top of 3.9 LTS using LTS i process so if everyone is interested in these technologies sharing the knowledge between the industries please let us know and send email to LTS i mailing list another interesting activity is like this related project Fuego is maintained by Tim Bird is an organizer of ELC and he mentioned that Fuego is a pre-installed test package run by Jenkins plus specific script inside the containers this is the whole packages you can use this one so automated testing for your product because this one is started from LTS i project but Tim is really interested in this project and wanted to maintain so he this is LTS i related project his session will happen in Thursday or so and use case two of use case is happening one is AGL automotive grade renaissance Toyota is reading this project and also Daimler and some other Nissan or Honda is joining this and this one is already released a three version UCB unified code base 3.0 was released in January and demonstrated at CES this one is using Yokuto and also LTS i so that the automotive industry is really using LTS i project that is strong use case of LTS i and other one is CIP civil infrastructure platform they established by some other factory use case project they wanted to use more longer term super long term the more than 15 years or so but on top of LTS and LTS i and after LTS i will become end of life they will take over the maintenance of LTS i that is the plan of their activities both two automotive grade renaissance civil infrastructure platform session will happen in this ELC so if you are interested in please join their session and if you are interested in please join us and your opinion will be shared within LTS i community and that is really interesting and if you are interested in please join us and your opinion will be shared within LTS i community and that is really interesting and that is really important for our project and we will have a workshop today from 4pm the director suite on the third floor if you are interested please come to us that one will be a real opinion we share the place where the real opinion my company have this kind of program and my company have also how to solve that that kind of workshop will happen if you are interested in please join us so that is my presentation and thank you so much and if you have any question please raise your hand what what I don't know sorry 4.9 I will upload my slide on the ELC site sorry it is not yet uploaded but I will commit this one will be uploaded and with fixing 3.924 are there any comments or questions ok thank you so much