SLE 15 - What's coming?
Behlert, Stefan
A short introduction into the plans for SLE 15. You will learn about the schedule, scope, and other details of the next major code stream for SUSE Linux enterprise products.
 So, hello, my name is Stefan Bielad. I'm one of those guys, Ludwig referred to as SLEE management. I'm one of the SLEE release managers. And I will talk to you or bring to you a little bit of input and news about the upcoming SLEE Enterprise 15 code. And please be with me. It's a glance into the future. So not everything is set in stone, not everything is final. And there are parts, unfortunately, which I cannot talk about yet, either because they are still so highly discussed that it would be embarrassing to talk about them here or because they are still under NDA. So in the next 20 to 30 minutes, you will get some general information. We will talk a little bit about what's coming. And then I want to talk a little bit about the challenges on the way that we will see there and how this can, will, or may affect you. So be with me. One or two marketing slides. You see from the in, from the Susie Linux Enterprise Server, we have a quite a different life cycle than your custom from the open Susie. So it's much longer. We are talking about 10 plus three years. So every decision we are currently make for 15 will affect us for the next 13 years. What you can also see there is what we have started with code 12, that we have a yearly release cycle of service packs. That means every year you see a service pack. We had SP2 last year. You are currently waiting for SP3, also on code 12, coming this year. And next year you will have 15 as well as 12 service pack four. Talking a little bit at what this means on the products that we have currently running on the enterprise side. You see we have here SLE11, which is still under support, where you still get updates for. We have SLE12, where we are currently producing the first red bubble on the slide SP3 and are coming up with SP4 after that and the bottom row 15 coming. And so we will have soon three major code bases running in parallel being supported for a short time. Let me start with one thing. We plan to have the first custom ship of 15 in the second quarter of 2018. You may say that's a little bit far out. It's not. In fact, it's 12 months or less. So we are currently working with high pressure to get all the open things fixed and adapted. There's one big change we have compared to code 12. We will deliver the traditional operating server. That means a server that has everything. And we will deliver something that we call SUSE container as a service platform, which is in fact there to host containers and other stuff in parallel. On the schedule side, you see here, we have in July the code drop deadline. In case you wonder what that means, that's for our partners, our software partners, to deliver their part, their codes, their hardware enablement patches, whatever they want us there to have inside of code 15. That means we are working closely together with them currently to get everything there in shape until that. We have then until September time to get everything together for our documentation department so they can update and write and start documenting how code 15 will work. And shortly after that, most likely not all of the documentation will be finished then, but at least hopefully some of it. We will release beta one, which will be the first public beta then that is accessible for everybody. In case you are wondering, no, that's not of course the first milestone we produce. We have several alphas in between and before, but those are internal only so we get time to fix everything that is broken, that is not working to our success, full thinking, or that is hindering us. One beta and then followed by a relatively short release candidate milestones and then in April you will get the gold master followed sometime soon after that the first customership. The gold master candidate case you want is for us internally when we want to have everything ready, so it can be shipped and the first customership is then when we have everything ready so even customers and everybody else can really use it so every mirror has been fulfilled, the download servers are ready and so on. So now to the part that most likely interests you most. So what's coming on the scope side? Yeah, it's a new major code stream. Ludwig said it early on this stage, everything is getting updated. That means we are really looking at every package for an update which is quite a lot. You have seen I think in one of the slides from Richard the tumbleweed had 10,000 packages, Slee has on code 12 currently around between 3,000 and 4,000. It varies a little bit depending on the platforms and with code 15 I expect it to be in the same range. So that's quite a huge number of packages where we have to look at and everything should work together of course. On the platform side no big changes there. You see x8664, S390, little and you empower PC64 as well as ARM. Not twice the usual what you have seen on code 12 will also exist on 15. We will also release at the same time choose images as well as CASP. I'm not sure if you have something here about CASP but I'm pretty sure it will be mentioned in other talks as well so I will not go into too much detail there. One big change that we want to do is we want to enhance the module concept that we had started with code 12. That means we want to get the installation media relatively small. We want to have more produced in small independent or mostly independent building bricks, let's call it in that and build out of these then our products. I looked a lot how to find a picture that would show this in a good way and I admit every picture that I saw and every diagram had its flaws. This one comes close to how it will look like. So we have the common code base that we use for all the products there. One repository where we build all out of it for all the products so they work together. We will build out of that something that's marked here as lean OS. In fact it's our code name for the installation media and we will build out of that various building bricks and I call it that on purpose from which we will then create the various products. And of course also the modules that are on top of these products. That has of course some challenges and we will come to that later. Packages, systems that we have, well I told you already we will update everything. A few numbers here on the kernel side. We will use 4.12 on the G-Lib side, 2.26 and on the GCC side, 7.2. You may notice that all of these 3s are not yet available in a final stable version. We know that. For some we expect them to be there with beta 1. Some of these 3 may not be final yet when we have beta 1 but are in the last phase of their release candidate cycle. So we plan to go with these versions because we think it makes the most sense for everybody. So we will be there a little bit ahead of what is stable. You see there are 3 kind of blocks on the lower end GNOME 3.26 and also we will have valence support so you see we are planning here also for some changes and newer versions and updates. On the right side there is the most interesting part because we plan also to replace some defaults that we had. For example we want to switch from NTP to crony which has some challenges. We plan to switch from the SUSE firewall to firewall D and we are looking currently at this 389DS package system. So there are some huge changes coming and we hope that those will work out nicely. But those huge changes are also producing quite some challenges that we stumbled over. So you have heard we are currently working out of factory and SLEE 15 is based on open SUSE factory. Ludwig said we will fork off at one point in time and that will be in July. Roughly said I am not giving out an exact date here because it will depend a little bit on what we have then, how stable we are and when we will go with stuff that is incompatible and stop for example at some versions of packages. But roughly said it will be most likely mid of July. Until then we will use everything that we have. In the same way as it is on open SUSE factory it's the same packages, the same code that we use there. We have a few adaptions when it comes to the branding packages and we will all that we have there run on open QA tests independent of what is running on open SUSE itself simply because we have some tests there and we want to get everything running smoothly. Of course bugs that we find will go also back to open SUSE factory. We encourage as you have heard from Ludwig the people to submit there. We also ask you as open SUSE contributors to submit if you have bug fixes them early enough so we can see and test them and see if there are side effects on platforms that maybe are not tested as intensively in open SUSE then they are on SLEE. And of course if you are a package maintainer, double project maintainer help us here with accepting stuff early because the sooner we get everything inside the better it is and the earlier we can test it on all the platforms. One thing that is causing me currently a little bit of headaches are dependencies. I am pretty sure you all have a desktop machine with something that is relatively huge installed on top of it and if you install a new package it mostly is that package and that is it. But if you use a rather small installation image or installed system and you try then to install stuff you will find dependencies that are bad that are not good. Why do we want to get these dependencies away or smoothed or made easier? A simple reason we have people who want to have a small install system. We also have people who want to run containers and virtual images that are small and the more packages you add to a system when you do a super in the more unstable and the more unsecured it gets and the more you have to look for side effects. So we want to keep that relatively small and therefore we did a few tests on such a rather small installation and please don't tell me that 650 MB is not small. Yes I know there are people who got it down to 200 MB. I know of one person who claims to have a running system with 50 MB. Yes, but we want it to be upgradable. We want to be able to install packages and a few other things. So this was the compromise we had there. I will show you a few examples on the next few slides. One caveat in advance. These examples are taken at random. Each of those should show you a specific problem. Note that all the numbers you see may not be valid anymore because dependencies change over the time and if you follow OpenSUSE factory closely you can see this. Note that the package maintainers are in most cases not to blame because we have dependencies that are there since ages. The oldest one that I found was from 2003. We have dependencies that are there because upstream thought it would be nice to have it. And some of these dependencies made sense at the time they were added. Some made even in our sense. But of course not necessarily if you want to be on a small system. For all these three examples, and I took them on purpose, that will come a big thank you to the package maintainers who helped to get the dependency solved. I'm not an expert in most of those. So a big thanks for the work they did here. First, you remember I said we want to exchange the SUSE firewall 2 with the firewall D. Looking at SUSE firewall, if you install it on the test machine, nine packages, 41 megabyte. That's not good I thought at the first moment. Then we tried to install the firewall D. Same system, of course. 83 new packages. And 106 megabyte. What? I thought 40 was bad, 106, not good. I'm pretty sure you can't read all the packages there. You should not. But looking at the package list, we noticed three things that fell out. One was firewall D wanted to install Mesa on a system that had no X. Ah, strange. Okay. Python, G object. Yeah. It's clear if you have Python, you get a lot of packages. But maybe there are some things which you can do on the dependency list. D bus 1, X11, I think meanwhile it's called Python D bus, Python 2 or Python 3. So you see this is two, three weeks old. All those pull in several dozen packages. And in the end, you have the firewall D and you end up with 106 megabyte. And the bad thing is the firewall D maintainer can't do anything because it's somewhere in the chain that follows up. Somewhere on Python, G object, on the D bus X11 package, you simply pull in dozens of other stuff. And that's also where Mesa comes into the play. So the Python maintainers and the firewall D maintainers looked at it, changed a little bit on the dependencies, fixed one or two, changed the require here and there to use something different. And then we retried the same thing, but this time also without the recommends. And we had 34 packages suddenly, no longer 80, but 34. And more astonishingly, we were down to 22 megabyte, which is less than where we started from with the SUSE firewall 2. So that was good. That's okay. If you install with, and that's a type on the slide, if you install with the minus, minus recommands, you get a little bit more packages, quite a lot of more, but that's okay then because that's exactly what we expect then from the recommends. But if you install without recommends, then you end up with less dependencies there and less space used than we had before. And all of that simply because the D bus one X11 package was not the best choice there to take. There were some other package that was helpful and that reduced the dependency dramatically. Another case, we stumbled over the Java packages tools. If you try to install Java, you sooner or later get this package and it fetches you lower, it fetches you Python. And that is not necessarily bad on the space side. If you look 40 megabytes, but if you consider that you just wanted to install Java and you end up with Lua as well as Python, that's not good. So we looked into the Java packages tools. The Lua is simply because there's one script that changes a path from absolute to relative for the other way around. And the Python, well, the Python is problematic because the Python stuff is there to help people who use Maven to get everything installed there set up correctly. So Thomas Schwarzal looked into that. He made some changes there, looked a little bit in the Java dependencies. Some of that stuff is already fixed in factory at the moment. Some is currently pending the fix. We are not getting rid of Python because of Maven. But it will get better and we will reduce the dependency chain a little bit. You may say, is it worth it to get it a little bit reduced? I don't have numbers yet because the fixes are still pending. But yes, it's worth because every package really makes a difference. Because at one point in time, the dependency below that package will change again and you suddenly end up again with a big bunch of packages. And if somebody has a good idea how to get Maven support without Python in Java packages tools, speak up and help us there because that will be really good. At the end. All scripts are welcome. Just submit to open source of factory and it will automatically get there. The third one goes CGK. When I first installed that package on the test system, I was astonished because I suddenly ended up with Lip duty five lips. And I was wondering why do I need Lip duty five packages if I want to install GoScript CGK, which is trust some fund support for GoScript. And a little bit of digging into that showed us the reason was simple. There was a requires there on the FT2DMOS package. That requires was introduced 2003. And looking why that is needed and the FT2DMOS is really a big bunch of collection for free type tools, also graphical ones, therefore the dependency to Lip duty five. And it was just needed because in two files, two scripts, FT dump was used. And it was not possible to omit that. So and that's the case when I said the dependency will grow bigger and bigger the more you have packages. We looked how to switch that. And the solution was that we split it the FT2DMOS package into several sub packages. So now you can simply require the FT dump if you need it and don't need to get all the many applications that you have for free type that require the duty stuff. So you can now install it without having Lip duty installed and pulled into. The split is already an open source of factory for GoScript CGK. The change is still pending. But once that is done, that is also reducing the amount of packages brought into. And it's a good example why it's sometimes a little bit of tricky to find the right package to add as a request and why it's sometimes very good if you split your package. So if you're a package maintainer and you consider of having everything in one package, think about the dependencies if it's really needed, if it's useful to have it in several parts. It's obvious when you have plug-ins or anything else. But there are also parts where this is not as obvious, but it makes a big difference. Yeah, that's my call for action for everybody. If you see dependencies that worry you or if you install a package and you suddenly end up with packages where you wonder why is this the case, don't be shy, open a bug report or look into it or even better submit something because that helps us all to get the distribution smaller, to get the stuff that the footprint, let's call it in that way, that we pull into when we update smaller and it helps also with maintaining all that stuff. At the same time, if you create a new sub package, please think about the description. There was a long thread on one of the open Susan mailing lists, so I will not go deeper into that, but opening a bug report or submitting a patch to adapt a description is appreciated. And not everybody knows what is in a sub package, so that is also helpful. And one more thing, advertising a little bit here. With SLEED 12, we started to have public beta. So while with code 11, you had to be one of our partners and be in a partner program to join our beta and were hand selected and had to go through an assessment center and what else, it was not as bad, but nearly to join. We are in SLEED 12, public beta where everybody could join and we plan to have the same thing again for SLEED 15. You have seen beta one will come in September. So you have still time to apply there. We ask for an email address and a few other things as far as I know. Go to the URL that is mentioned there. You can also search on the SUSEB main page for beta program. There is everything you need on information and there is also the way to say I want to join. And then you can get SLEED 15 images relatively soon when every milestone is finished. And published, you have access to it. We are happy about everybody who joins there. We are not promising to fix every bug report there, but we try our best to get everything solved to your satisfaction there. And it's really cool if you join there and get these images early enough so if you are missing something or think something is wrongly configured, you can influence the SUSEB enterprise product and therefore also to a certain degree LEAP because LEAP will also be based on that. So with that, I'm at the end. We have around one minute left, but if there are questions and answers, I'm willing to go beyond that time frame that I have. You got my attention when you said that you were changing the firewall. And what I'm wondering is if I have an application that's dependent on using the CLI or API calls to the old firewall, is that going to break my application? That's a good question. That's why I asked it. And I'm sorry I have no clear answer to you yet. We have a script. We are currently looking into the migration path there, what we can do to make the transition easy. We are not 100% sure if we can cover every case, to be honest. Oh, thank you. But of course, join the public beta and there, I think if you bring it up, if it's not working, then we will look also in these cases. Because I don't want to lie to you, we are not there yet that we can say for sure everything or every situation is supported. I'm pretty sure not seeing what some people do with the firewall and a few other of the old stuff. And in case you ask, I've seen people doing things with a finger server where the finger server was never intended to be used for. So, and we will drop that in case you don't know what a finger server is, don't ask its old stuff from the last century. So yes. Well, I appreciated your comment about not wanting to lie to me because it reminded me of an old story about the difference between a car salesman and a computer salesman. A car salesman knows when he's lying. I'll leave you with that. I just sometimes have no clue, but that's all. You wanted to say something? Also related to the question about firewall, is there any schedule change with regard to the network management infrastructure in SLEE 15? Sorry, I didn't get the last part. Is there any plan to change the network management infrastructure in SLEE 15? Because right now, as I see it, there's basically three solutions that basically exist and need to be maintained somehow. You're talking about Wicked Network Manager and the SISTEMD Network D. It's not so easy to answer. We will definitely keep Wicked. That's for sure. We definitely plan to keep the Network Manager at the moment. We are nevertheless looking into getting all these reintegrated more closely and especially on the system, the Network D side. We see on the upstream side development that's very encouraging. There were one or two years ago still the tendency to use that or to have the main purpose for that only on the cloud stuff. Meanwhile, that intentions for it have changed. We are looking into that and planning to integrate all three, but we will definitely have as main systems the Network D as well as the Wicked. Because for one thing, we don't want to change all the conflicts in a migration. The other thing is we currently don't think SISTEMD Network D is where it should be, for example, for a server infrastructure. Does this answer your question? Yes, it's a pain that we have so many things. That's why we want to integrate it. More questions? If not, then I'm one minute late, but my architect is used to that. Thank you very much.
 So, hello, my name is Stefan Bielad.  I'm one of those guys, Ludwig referred to as SLEE management.  I'm one of the SLEE release managers.  And I will talk to you or bring to you a little bit of input and news about the upcoming  SLEE Enterprise 15 code.  And please be with me.  It's a glance into the future.  So not everything is set in stone, not everything is final.  And there are parts, unfortunately, which I cannot talk about yet, either because they  are still so highly discussed that it would be embarrassing to talk about them here or  because they are still under NDA.  So in the next 20 to 30 minutes, you will get some general information.  We will talk a little bit about what's coming.  And then I want to talk a little bit about the challenges on the way that we will see  there and how this can, will, or may affect you.  So be with me.  One or two marketing slides.  You see from the in, from the Susie Linux Enterprise Server, we have a quite a different  life cycle than your custom from the open Susie.  So it's much longer.  We are talking about 10 plus three years.  So every decision we are currently make for 15 will affect us for the next 13 years.  What you can also see there is what we have started with code 12, that we have a yearly  release cycle of service packs.  That means every year you see a service pack.  We had SP2 last year.  You are currently waiting for SP3, also on code 12, coming this year.  And next year you will have 15 as well as 12 service pack four.  Talking a little bit at what this means on the products that we have currently running  on the enterprise side.  You see we have here SLE11, which is still under support, where you still get updates  for.  We have SLE12, where we are currently producing the first red bubble on the slide SP3 and  are coming up with SP4 after that and the bottom row 15 coming.  And so we will have soon three major code bases running in parallel being supported  for a short time.  Let me start with one thing.  We plan to have the first custom ship of 15 in the second quarter of 2018.  You may say that's a little bit far out.  It's not.  In fact, it's 12 months or less.  So we are currently working with high pressure to get all the open things fixed and adapted.  There's one big change we have compared to code 12.  We will deliver the traditional operating server.  That means a server that has everything.  And we will deliver something that we call SUSE container as a service platform, which  is in fact there to host containers and other stuff in parallel.  On the schedule side, you see here, we have in July the code drop deadline.  In case you wonder what that means, that's for our partners, our software partners, to  deliver their part, their codes, their hardware enablement patches, whatever they want us  there to have inside of code 15.  That means we are working closely together with them currently to get everything there  in shape until that.  We have then until September time to get everything together for our documentation department  so they can update and write and start documenting how code 15 will work.  And shortly after that, most likely not all of the documentation will be finished then,  but at least hopefully some of it.  We will release beta one, which will be the first public beta then that is accessible  for everybody.  In case you are wondering, no, that's not of course the first milestone we produce.  We have several alphas in between and before, but those are internal only so we get time  to fix everything that is broken, that is not working to our success, full thinking,  or that is hindering us.  One beta and then followed by a relatively short release candidate milestones and then  in April you will get the gold master followed sometime soon after that the first customership.  The gold master candidate case you want is for us internally when we want to have everything  ready, so it can be shipped and the first customership is then when we have everything  ready so even customers and everybody else can really use it so every mirror has been  fulfilled, the download servers are ready and so on.  So now to the part that most likely interests you most.  So what's coming on the scope side?  Yeah, it's a new major code stream.  Ludwig said it early on this stage, everything is getting updated.  That means we are really looking at every package for an update which is quite a lot.  You have seen I think in one of the slides from Richard the tumbleweed had 10,000 packages,  Slee has on code 12 currently around between 3,000 and 4,000.  It varies a little bit depending on the platforms and with code 15 I expect it to be in the  same range.  So that's quite a huge number of packages where we have to look at and everything should  work together of course.  On the platform side no big changes there.  You see x8664, S390, little and you empower PC64 as well as ARM.  Not twice the usual what you have seen on code 12 will also exist on 15.  We will also release at the same time choose images as well as CASP.  I'm not sure if you have something here about CASP but I'm pretty sure it will be mentioned  in other talks as well so I will not go into too much detail there.  One big change that we want to do is we want to enhance the module concept that we had started  with code 12.  That means we want to get the installation media relatively small.  We want to have more produced in small independent or mostly independent building bricks, let's  call it in that and build out of these then our products.  I looked a lot how to find a picture that would show this in a good way and I admit  every picture that I saw and every diagram had its flaws.  This one comes close to how it will look like.  So we have the common code base that we use for all the products there.  One repository where we build all out of it for all the products so they work together.  We will build out of that something that's marked here as lean OS.  In fact it's our code name for the installation media and we will build out of that various  building bricks and I call it that on purpose from which we will then create the various  products.  And of course also the modules that are on top of these products.  That has of course some challenges and we will come to that later.  Packages, systems that we have, well I told you already we will update everything.  A few numbers here on the kernel side.  We will use 4.12 on the G-Lib side, 2.26 and on the GCC side, 7.2.  You may notice that all of these 3s are not yet available in a final stable version.  We know that.  For some we expect them to be there with beta 1.  Some of these 3 may not be final yet when we have beta 1 but are in the last phase of  their release candidate cycle.  So we plan to go with these versions because we think it makes the most sense for everybody.  So we will be there a little bit ahead of what is stable.  You see there are 3 kind of blocks on the lower end GNOME 3.26 and also we will have  valence support so you see we are planning here also for some changes and newer versions  and updates.  On the right side there is the most interesting part because we plan also to replace some  defaults that we had.  For example we want to switch from NTP to crony which has some challenges.  We plan to switch from the SUSE firewall to firewall D and we are looking currently at  this 389DS package system.  So there are some huge changes coming and we hope that those will work out nicely.  But those huge changes are also producing quite some challenges that we stumbled over.  So you have heard we are currently working out of factory and SLEE 15 is based on open  SUSE factory.  Ludwig said we will fork off at one point in time and that will be in July.  Roughly said I am not giving out an exact date here because it will depend a little bit  on what we have then, how stable we are and when we will go with stuff that is incompatible  and stop for example at some versions of packages.  But roughly said it will be most likely mid of July.  Until then we will use everything that we have.  In the same way as it is on open SUSE factory it's the same packages, the same code that  we use there.  We have a few adaptions when it comes to the branding packages and we will all that we  have there run on open QA tests independent of what is running on open SUSE itself simply  because we have some tests there and we want to get everything running smoothly.  Of course bugs that we find will go also back to open SUSE factory.  We encourage as you have heard from Ludwig the people to submit there.  We also ask you as open SUSE contributors to submit if you have bug fixes them early enough  so we can see and test them and see if there are side effects on platforms that maybe are  not tested as intensively in open SUSE then they are on SLEE.  And of course if you are a package maintainer, double project maintainer help us here with  accepting stuff early because the sooner we get everything inside the better it is and  the earlier we can test it on all the platforms.  One thing that is causing me currently a little bit of headaches are dependencies.  I am pretty sure you all have a desktop machine with something that is relatively huge installed  on top of it and if you install a new package it mostly is that package and that is it.  But if you use a rather small installation image or installed system and you try then  to install stuff you will find dependencies that are bad that are not good.  Why do we want to get these dependencies away or smoothed or made easier?  A simple reason we have people who want to have a small install system.  We also have people who want to run containers and virtual images that are small and the  more packages you add to a system when you do a super in the more unstable and the more  unsecured it gets and the more you have to look for side effects.  So we want to keep that relatively small and therefore we did a few tests on such a rather  small installation and please don't tell me that 650 MB is not small.  Yes I know there are people who got it down to 200 MB.  I know of one person who claims to have a running system with 50 MB.  Yes, but we want it to be upgradable.  We want to be able to install packages and a few other things.  So this was the compromise we had there.  I will show you a few examples on the next few slides.  One caveat in advance.  These examples are taken at random.  Each of those should show you a specific problem.  Note that all the numbers you see may not be valid anymore because dependencies change  over the time and if you follow OpenSUSE factory closely you can see this.  Note that the package maintainers are in most cases not to blame because we have dependencies  that are there since ages.  The oldest one that I found was from 2003.  We have dependencies that are there because upstream thought it would be nice to have it.  And some of these dependencies made sense at the time they were added.  Some made even in our sense.  But of course not necessarily if you want to be on a small system.  For all these three examples, and I took them on purpose, that will come a big thank you  to the package maintainers who helped to get the dependency solved.  I'm not an expert in most of those.  So a big thanks for the work they did here.  First, you remember I said we want to exchange the SUSE firewall 2 with the firewall D.  Looking at SUSE firewall, if you install it on the test machine, nine packages, 41 megabyte.  That's not good I thought at the first moment.  Then we tried to install the firewall D. Same system, of course.  83 new packages.  And 106 megabyte.  What?  I thought 40 was bad, 106, not good.  I'm pretty sure you can't read all the packages there.  You should not.  But looking at the package list, we noticed three things that fell out.  One was firewall D wanted to install Mesa on a system that had no X.  Ah, strange.  Okay.  Python, G object.  Yeah.  It's clear if you have Python, you get a lot of packages.  But maybe there are some things which you can do on the dependency list.  D bus 1, X11, I think meanwhile it's called Python D bus, Python 2 or Python 3.  So you see this is two, three weeks old.  All those pull in several dozen packages.  And in the end, you have the firewall D and you end up with 106 megabyte.  And the bad thing is the firewall D maintainer can't do anything because it's somewhere  in the chain that follows up.  Somewhere on Python, G object, on the D bus X11 package, you simply pull in dozens of  other stuff.  And that's also where Mesa comes into the play.  So the Python maintainers and the firewall D maintainers looked at it, changed a little  bit on the dependencies, fixed one or two, changed the require here and there to use  something different.  And then we retried the same thing, but this time also without the recommends.  And we had 34 packages suddenly, no longer 80, but 34.  And more astonishingly, we were down to 22 megabyte, which is less than where we started  from with the SUSE firewall 2.  So that was good.  That's okay.  If you install with, and that's a type on the slide, if you install with the minus, minus  recommands, you get a little bit more packages, quite a lot of more, but that's okay then  because that's exactly what we expect then from the recommends.  But if you install without recommends, then you end up with less dependencies there and  less space used than we had before.  And all of that simply because the D bus one X11 package was not the best choice there  to take.  There were some other package that was helpful and that reduced the dependency dramatically.  Another case, we stumbled over the Java packages tools.  If you try to install Java, you sooner or later get this package and it fetches you  lower, it fetches you Python.  And that is not necessarily bad on the space side.  If you look 40 megabytes, but if you consider that you just wanted to install Java and you  end up with Lua as well as Python, that's not good.  So we looked into the Java packages tools.  The Lua is simply because there's one script that changes a path from absolute to relative  for the other way around.  And the Python, well, the Python is problematic because the Python stuff is there to help  people who use Maven to get everything installed there set up correctly.  So Thomas Schwarzal looked into that.  He made some changes there, looked a little bit in the Java dependencies.  Some of that stuff is already fixed in factory at the moment.  Some is currently pending the fix.  We are not getting rid of Python because of Maven.  But it will get better and we will reduce the dependency chain a little bit.  You may say, is it worth it to get it a little bit reduced?  I don't have numbers yet because the fixes are still pending.  But yes, it's worth because every package really makes a difference.  Because at one point in time, the dependency below that package will change again and you  suddenly end up again with a big bunch of packages.  And if somebody has a good idea how to get Maven support without Python in Java packages  tools, speak up and help us there because that will be really good.  At the end.  All scripts are welcome.  Just submit to open source of factory and it will automatically get there.  The third one goes CGK.  When I first installed that package on the test system, I was astonished because I suddenly  ended up with Lip duty five lips.  And I was wondering why do I need Lip duty five packages if I want to install GoScript  CGK, which is trust some fund support for GoScript.  And a little bit of digging into that showed us the reason was simple.  There was a requires there on the FT2DMOS package.  That requires was introduced 2003.  And looking why that is needed and the FT2DMOS is really a big bunch of collection for free  type tools, also graphical ones, therefore the dependency to Lip duty five.  And it was just needed because in two files, two scripts, FT dump was used.  And it was not possible to omit that.  So and that's the case when I said the dependency will grow bigger and bigger the more you have  packages.  We looked how to switch that.  And the solution was that we split it the FT2DMOS package into several sub packages.  So now you can simply require the FT dump if you need it and don't need to get all the  many applications that you have for free type that require the duty stuff.  So you can now install it without having Lip duty installed and pulled into.  The split is already an open source of factory for GoScript CGK.  The change is still pending.  But once that is done, that is also reducing the amount of packages brought into.  And it's a good example why it's sometimes a little bit of tricky to find the right package  to add as a request and why it's sometimes very good if you split your package.  So if you're a package maintainer and you consider of having everything in one package,  think about the dependencies if it's really needed, if it's useful to have it in several  parts.  It's obvious when you have plug-ins or anything else.  But there are also parts where this is not as obvious, but it makes a big difference.  Yeah, that's my call for action for everybody.  If you see dependencies that worry you or if you install a package and you suddenly end  up with packages where you wonder why is this the case, don't be shy, open a bug report  or look into it or even better submit something because that helps us all to get the distribution  smaller, to get the stuff that the footprint, let's call it in that way, that we pull into  when we update smaller and it helps also with maintaining all that stuff.  At the same time, if you create a new sub package, please think about the description.  There was a long thread on one of the open Susan mailing lists, so I will not go deeper  into that, but opening a bug report or submitting a patch to adapt a description is appreciated.  And not everybody knows what is in a sub package, so that is also helpful.  And one more thing, advertising a little bit here.  With SLEED 12, we started to have public beta.  So while with code 11, you had to be one of our partners and be in a partner program to  join our beta and were hand selected and had to go through an assessment center and what  else, it was not as bad, but nearly to join.  We are in SLEED 12, public beta where everybody could join and we plan to have the same thing  again for SLEED 15.  You have seen beta one will come in September.  So you have still time to apply there.  We ask for an email address and a few other things as far as I know.  Go to the URL that is mentioned there.  You can also search on the SUSEB main page for beta program.  There is everything you need on information and there is also the way to say I want to  join.  And then you can get SLEED 15 images relatively soon when every milestone is finished.  And published, you have access to it.  We are happy about everybody who joins there.  We are not promising to fix every bug report there, but we try our best to get everything  solved to your satisfaction there.  And it's really cool if you join there and get these images early enough so if you are  missing something or think something is wrongly configured, you can influence the SUSEB enterprise  product and therefore also to a certain degree LEAP because LEAP will also be based on that.  So with that, I'm at the end.  We have around one minute left, but if there are questions and answers, I'm willing to  go beyond that time frame that I have.  You got my attention when you said that you were changing the firewall.  And what I'm wondering is if I have an application that's dependent on using the CLI or API  calls to the old firewall, is that going to break my application?  That's a good question.  That's why I asked it.  And I'm sorry I have no clear answer to you yet.  We have a script.  We are currently looking into the migration path there, what we can do to make the transition  easy.  We are not 100% sure if we can cover every case, to be honest.  Oh, thank you.  But of course, join the public beta and there, I think if you bring it up, if it's not working,  then we will look also in these cases.  Because I don't want to lie to you, we are not there yet that we can say for sure everything  or every situation is supported.  I'm pretty sure not seeing what some people do with the firewall and a few other of the  old stuff.  And in case you ask, I've seen people doing things with a finger server where the finger  server was never intended to be used for.  So, and we will drop that in case you don't know what a finger server is, don't ask its  old stuff from the last century.  So yes.  Well, I appreciated your comment about not wanting to lie to me because it reminded me  of an old story about the difference between a car salesman and a computer salesman.  A car salesman knows when he's lying.  I'll leave you with that.  I just sometimes have no clue, but that's all.  You wanted to say something?  Also related to the question about firewall, is there any schedule change with regard to  the network management infrastructure in SLEE 15?  Sorry, I didn't get the last part.  Is there any plan to change the network management infrastructure in SLEE 15?  Because right now, as I see it, there's basically three solutions that basically exist and need  to be maintained somehow.  You're talking about Wicked Network Manager and the SISTEMD Network D.  It's not so easy to answer.  We will definitely keep Wicked.  That's for sure.  We definitely plan to keep the Network Manager at the moment.  We are nevertheless looking into getting all these reintegrated more closely and especially  on the system, the Network D side.  We see on the upstream side development that's very encouraging.  There were one or two years ago still the tendency to use that or to have the main purpose  for that only on the cloud stuff.  Meanwhile, that intentions for it have changed.  We are looking into that and planning to integrate all three, but we will definitely have as  main systems the Network D as well as the Wicked.  Because for one thing, we don't want to change all the conflicts in a migration.  The other thing is we currently don't think SISTEMD Network D is where it should be, for  example, for a server infrastructure.  Does this answer your question?  Yes, it's a pain that we have so many things.  That's why we want to integrate it.  More questions?  If not, then I'm one minute late, but my architect is used to that.  Thank you very much.
openSUSE_Conference_2017_SLE_15_-_What_s_coming__2twvU9g2t8w_0_8963.png openSUSE_Conference_2017_SLE_15_-_What_s_coming__2twvU9g2t8w_8964_11159.png openSUSE_Conference_2017_SLE_15_-_What_s_coming__2twvU9g2t8w_11160_11207.png openSUSE_Conference_2017_SLE_15_-_What_s_coming__2twvU9g2t8w_11208_11927.png openSUSE_Conference_2017_SLE_15_-_What_s_coming__2twvU9g2t8w_11928_12167.png openSUSE_Conference_2017_SLE_15_-_What_s_coming__2twvU9g2t8w_12168_14327.png openSUSE_Conference_2017_SLE_15_-_What_s_coming__2twvU9g2t8w_14328_14603.png openSUSE_Conference_2017_SLE_15_-_What_s_coming__2twvU9g2t8w_14604_15167.png openSUSE_Conference_2017_SLE_15_-_What_s_coming__2twvU9g2t8w_15168_15239.png openSUSE_Conference_2017_SLE_15_-_What_s_coming__2twvU9g2t8w_15240_15755.png openSUSE_Conference_2017_SLE_15_-_What_s_coming__2twvU9g2t8w_15756_16043.png openSUSE_Conference_2017_SLE_15_-_What_s_coming__2twvU9g2t8w_16044_16559.png openSUSE_Conference_2017_SLE_15_-_What_s_coming__2twvU9g2t8w_16560_16643.png openSUSE_Conference_2017_SLE_15_-_What_s_coming__2twvU9g2t8w_16644_17327.png openSUSE_Conference_2017_SLE_15_-_What_s_coming__2twvU9g2t8w_17328_17483.png openSUSE_Conference_2017_SLE_15_-_What_s_coming__2twvU9g2t8w_17484_17603.png openSUSE_Conference_2017_SLE_15_-_What_s_coming__2twvU9g2t8w_17604_19679.png openSUSE_Conference_2017_SLE_15_-_What_s_coming__2twvU9g2t8w_19680_25211.png openSUSE_Conference_2017_SLE_15_-_What_s_coming__2twvU9g2t8w_25212_25319.png openSUSE_Conference_2017_SLE_15_-_What_s_coming__2twvU9g2t8w_25320_25523.png openSUSE_Conference_2017_SLE_15_-_What_s_coming__2twvU9g2t8w_25524_26087.png openSUSE_Conference_2017_SLE_15_-_What_s_coming__2twvU9g2t8w_26088_26843.png openSUSE_Conference_2017_SLE_15_-_What_s_coming__2twvU9g2t8w_26844_27563.png openSUSE_Conference_2017_SLE_15_-_What_s_coming__2twvU9g2t8w_27564_28463.png openSUSE_Conference_2017_SLE_15_-_What_s_coming__2twvU9g2t8w_28464_28559.png openSUSE_Conference_2017_SLE_15_-_What_s_coming__2twvU9g2t8w_28560_29291.png openSUSE_Conference_2017_SLE_15_-_What_s_coming__2twvU9g2t8w_29292_29483.png openSUSE_Conference_2017_SLE_15_-_What_s_coming__2twvU9g2t8w_29484_30083.png openSUSE_Conference_2017_SLE_15_-_What_s_coming__2twvU9g2t8w_30084_30719.png openSUSE_Conference_2017_SLE_15_-_What_s_coming__2twvU9g2t8w_30720_30767.png openSUSE_Conference_2017_SLE_15_-_What_s_coming__2twvU9g2t8w_30768_30923.png openSUSE_Conference_2017_SLE_15_-_What_s_coming__2twvU9g2t8w_30924_31967.png openSUSE_Conference_2017_SLE_15_-_What_s_coming__2twvU9g2t8w_31968_32123.png openSUSE_Conference_2017_SLE_15_-_What_s_coming__2twvU9g2t8w_32124_33839.png openSUSE_Conference_2017_SLE_15_-_What_s_coming__2twvU9g2t8w_33840_34079.png openSUSE_Conference_2017_SLE_15_-_What_s_coming__2twvU9g2t8w_34080_34163.png openSUSE_Conference_2017_SLE_15_-_What_s_coming__2twvU9g2t8w_34164_34727.png openSUSE_Conference_2017_SLE_15_-_What_s_coming__2twvU9g2t8w_34728_34847.png openSUSE_Conference_2017_SLE_15_-_What_s_coming__2twvU9g2t8w_34848_35447.png openSUSE_Conference_2017_SLE_15_-_What_s_coming__2twvU9g2t8w_35448_35843.png openSUSE_Conference_2017_SLE_15_-_What_s_coming__2twvU9g2t8w_35844_36443.png openSUSE_Conference_2017_SLE_15_-_What_s_coming__2twvU9g2t8w_36444_36887.png openSUSE_Conference_2017_SLE_15_-_What_s_coming__2twvU9g2t8w_36888_37007.png openSUSE_Conference_2017_SLE_15_-_What_s_coming__2twvU9g2t8w_37008_37523.png openSUSE_Conference_2017_SLE_15_-_What_s_coming__2twvU9g2t8w_37524_37847.png openSUSE_Conference_2017_SLE_15_-_What_s_coming__2twvU9g2t8w_37848_38927.png openSUSE_Conference_2017_SLE_15_-_What_s_coming__2twvU9g2t8w_38928_49298.png
So, hello, my name is Stefan Bielad. I'm one of those guys, Ludwig referred to as SLEE management. I'm one of the SLEE release managers. And I will talk to you or bring to you a little bit of input and news about the upcoming SLEE Enterprise 15 code. And please be with me. It's a glance into the future. So not everything is set in stone, not everything is final. And there are parts, unfortunately, which I cannot talk about yet, either because they are still so highly discussed that it would be embarrassing to talk about them here or because they are still under NDA. So in the next 20 to 30 minutes, you will get some general information. We will talk a little bit about what's coming. And then I want to talk a little bit about the challenges on the way that we will see there and how this can, will, or may affect you. So be with me. One or two marketing slides. You see from the in, from the Susie Linux Enterprise Server, we have a quite a different life cycle than your custom from the open Susie. So it's much longer. We are talking about 10 plus three years. So every decision we are currently make for 15 will affect us for the next 13 years. What you can also see there is what we have started with code 12, that we have a yearly release cycle of service packs. That means every year you see a service pack. We had SP2 last year. You are currently waiting for SP3, also on code 12, coming this year. And next year you will have 15 as well as 12 service pack four. Talking a little bit at what this means on the products that we have currently running on the enterprise side. You see we have here SLE11, which is still under support, where you still get updates for. We have SLE12, where we are currently producing the first red bubble on the slide SP3 and are coming up with SP4 after that and the bottom row 15 coming. And so we will have soon three major code bases running in parallel being supported for a short time. Let me start with one thing. We plan to have the first custom ship of 15 in the second quarter of 2018. You may say that's a little bit far out. It's not. In fact, it's 12 months or less. So we are currently working with high pressure to get all the open things fixed and adapted. There's one big change we have compared to code 12. We will deliver the traditional operating server. That means a server that has everything. And we will deliver something that we call SUSE container as a service platform, which is in fact there to host containers and other stuff in parallel. On the schedule side, you see here, we have in July the code drop deadline. In case you wonder what that means, that's for our partners, our software partners, to deliver their part, their codes, their hardware enablement patches, whatever they want us there to have inside of code 15. That means we are working closely together with them currently to get everything there in shape until that. We have then until September time to get everything together for our documentation department so they can update and write and start documenting how code 15 will work. And shortly after that, most likely not all of the documentation will be finished then, but at least hopefully some of it. We will release beta one, which will be the first public beta then that is accessible for everybody. In case you are wondering, no, that's not of course the first milestone we produce. We have several alphas in between and before, but those are internal only so we get time to fix everything that is broken, that is not working to our success, full thinking, or that is hindering us. One beta and then followed by a relatively short release candidate milestones and then in April you will get the gold master followed sometime soon after that the first customership. The gold master candidate case you want is for us internally when we want to have everything ready, so it can be shipped and the first customership is then when we have everything ready so even customers and everybody else can really use it so every mirror has been fulfilled, the download servers are ready and so on. So now to the part that most likely interests you most. So what's coming on the scope side? Yeah, it's a new major code stream. Ludwig said it early on this stage, everything is getting updated. That means we are really looking at every package for an update which is quite a lot. You have seen I think in one of the slides from Richard the tumbleweed had 10,000 packages, Slee has on code 12 currently around between 3,000 and 4,000. It varies a little bit depending on the platforms and with code 15 I expect it to be in the same range. So that's quite a huge number of packages where we have to look at and everything should work together of course. On the platform side no big changes there. You see x8664, S390, little and you empower PC64 as well as ARM. Not twice the usual what you have seen on code 12 will also exist on 15. We will also release at the same time choose images as well as CASP. I'm not sure if you have something here about CASP but I'm pretty sure it will be mentioned in other talks as well so I will not go into too much detail there. One big change that we want to do is we want to enhance the module concept that we had started with code 12. That means we want to get the installation media relatively small. We want to have more produced in small independent or mostly independent building bricks, let's call it in that and build out of these then our products. I looked a lot how to find a picture that would show this in a good way and I admit every picture that I saw and every diagram had its flaws. This one comes close to how it will look like. So we have the common code base that we use for all the products there. One repository where we build all out of it for all the products so they work together. We will build out of that something that's marked here as lean OS. In fact it's our code name for the installation media and we will build out of that various building bricks and I call it that on purpose from which we will then create the various products. And of course also the modules that are on top of these products. That has of course some challenges and we will come to that later. Packages, systems that we have, well I told you already we will update everything. A few numbers here on the kernel side. We will use 4.12 on the G-Lib side, 2.26 and on the GCC side, 7.2. You may notice that all of these 3s are not yet available in a final stable version. We know that. For some we expect them to be there with beta 1. Some of these 3 may not be final yet when we have beta 1 but are in the last phase of their release candidate cycle. So we plan to go with these versions because we think it makes the most sense for everybody. So we will be there a little bit ahead of what is stable. You see there are 3 kind of blocks on the lower end GNOME 3.26 and also we will have valence support so you see we are planning here also for some changes and newer versions and updates. On the right side there is the most interesting part because we plan also to replace some defaults that we had. For example we want to switch from NTP to crony which has some challenges. We plan to switch from the SUSE firewall to firewall D and we are looking currently at this 389DS package system. So there are some huge changes coming and we hope that those will work out nicely. But those huge changes are also producing quite some challenges that we stumbled over. So you have heard we are currently working out of factory and SLEE 15 is based on open SUSE factory. Ludwig said we will fork off at one point in time and that will be in July. Roughly said I am not giving out an exact date here because it will depend a little bit on what we have then, how stable we are and when we will go with stuff that is incompatible and stop for example at some versions of packages. But roughly said it will be most likely mid of July. Until then we will use everything that we have. In the same way as it is on open SUSE factory it's the same packages, the same code that we use there. We have a few adaptions when it comes to the branding packages and we will all that we have there run on open QA tests independent of what is running on open SUSE itself simply because we have some tests there and we want to get everything running smoothly. Of course bugs that we find will go also back to open SUSE factory. We encourage as you have heard from Ludwig the people to submit there. We also ask you as open SUSE contributors to submit if you have bug fixes them early enough so we can see and test them and see if there are side effects on platforms that maybe are not tested as intensively in open SUSE then they are on SLEE. And of course if you are a package maintainer, double project maintainer help us here with accepting stuff early because the sooner we get everything inside the better it is and the earlier we can test it on all the platforms. One thing that is causing me currently a little bit of headaches are dependencies. I am pretty sure you all have a desktop machine with something that is relatively huge installed on top of it and if you install a new package it mostly is that package and that is it. But if you use a rather small installation image or installed system and you try then to install stuff you will find dependencies that are bad that are not good. Why do we want to get these dependencies away or smoothed or made easier? A simple reason we have people who want to have a small install system. We also have people who want to run containers and virtual images that are small and the more packages you add to a system when you do a super in the more unstable and the more unsecured it gets and the more you have to look for side effects. So we want to keep that relatively small and therefore we did a few tests on such a rather small installation and please don't tell me that 650 MB is not small. Yes I know there are people who got it down to 200 MB. I know of one person who claims to have a running system with 50 MB. Yes, but we want it to be upgradable. We want to be able to install packages and a few other things. So this was the compromise we had there. I will show you a few examples on the next few slides. One caveat in advance. These examples are taken at random. Each of those should show you a specific problem. Note that all the numbers you see may not be valid anymore because dependencies change over the time and if you follow OpenSUSE factory closely you can see this. Note that the package maintainers are in most cases not to blame because we have dependencies that are there since ages. The oldest one that I found was from 2003. We have dependencies that are there because upstream thought it would be nice to have it. And some of these dependencies made sense at the time they were added. Some made even in our sense. But of course not necessarily if you want to be on a small system. For all these three examples, and I took them on purpose, that will come a big thank you to the package maintainers who helped to get the dependency solved. I'm not an expert in most of those. So a big thanks for the work they did here. First, you remember I said we want to exchange the SUSE firewall 2 with the firewall D. Looking at SUSE firewall, if you install it on the test machine, nine packages, 41 megabyte. That's not good I thought at the first moment. Then we tried to install the firewall D. Same system, of course. 83 new packages. And 106 megabyte. What? I thought 40 was bad, 106, not good. I'm pretty sure you can't read all the packages there. You should not. But looking at the package list, we noticed three things that fell out. One was firewall D wanted to install Mesa on a system that had no X. Ah, strange. Okay. Python, G object. Yeah. It's clear if you have Python, you get a lot of packages. But maybe there are some things which you can do on the dependency list. D bus 1, X11, I think meanwhile it's called Python D bus, Python 2 or Python 3. So you see this is two, three weeks old. All those pull in several dozen packages. And in the end, you have the firewall D and you end up with 106 megabyte. And the bad thing is the firewall D maintainer can't do anything because it's somewhere in the chain that follows up. Somewhere on Python, G object, on the D bus X11 package, you simply pull in dozens of other stuff. And that's also where Mesa comes into the play. So the Python maintainers and the firewall D maintainers looked at it, changed a little bit on the dependencies, fixed one or two, changed the require here and there to use something different. And then we retried the same thing, but this time also without the recommends. And we had 34 packages suddenly, no longer 80, but 34. And more astonishingly, we were down to 22 megabyte, which is less than where we started from with the SUSE firewall 2. So that was good. That's okay. If you install with, and that's a type on the slide, if you install with the minus, minus recommands, you get a little bit more packages, quite a lot of more, but that's okay then because that's exactly what we expect then from the recommends. But if you install without recommends, then you end up with less dependencies there and less space used than we had before. And all of that simply because the D bus one X11 package was not the best choice there to take. There were some other package that was helpful and that reduced the dependency dramatically. Another case, we stumbled over the Java packages tools. If you try to install Java, you sooner or later get this package and it fetches you lower, it fetches you Python. And that is not necessarily bad on the space side. If you look 40 megabytes, but if you consider that you just wanted to install Java and you end up with Lua as well as Python, that's not good. So we looked into the Java packages tools. The Lua is simply because there's one script that changes a path from absolute to relative for the other way around. And the Python, well, the Python is problematic because the Python stuff is there to help people who use Maven to get everything installed there set up correctly. So Thomas Schwarzal looked into that. He made some changes there, looked a little bit in the Java dependencies. Some of that stuff is already fixed in factory at the moment. Some is currently pending the fix. We are not getting rid of Python because of Maven. But it will get better and we will reduce the dependency chain a little bit. You may say, is it worth it to get it a little bit reduced? I don't have numbers yet because the fixes are still pending. But yes, it's worth because every package really makes a difference. Because at one point in time, the dependency below that package will change again and you suddenly end up again with a big bunch of packages. And if somebody has a good idea how to get Maven support without Python in Java packages tools, speak up and help us there because that will be really good. At the end. All scripts are welcome. Just submit to open source of factory and it will automatically get there. The third one goes CGK. When I first installed that package on the test system, I was astonished because I suddenly ended up with Lip duty five lips. And I was wondering why do I need Lip duty five packages if I want to install GoScript CGK, which is trust some fund support for GoScript. And a little bit of digging into that showed us the reason was simple. There was a requires there on the FT2DMOS package. That requires was introduced 2003. And looking why that is needed and the FT2DMOS is really a big bunch of collection for free type tools, also graphical ones, therefore the dependency to Lip duty five. And it was just needed because in two files, two scripts, FT dump was used. And it was not possible to omit that. So and that's the case when I said the dependency will grow bigger and bigger the more you have packages. We looked how to switch that. And the solution was that we split it the FT2DMOS package into several sub packages. So now you can simply require the FT dump if you need it and don't need to get all the many applications that you have for free type that require the duty stuff. So you can now install it without having Lip duty installed and pulled into. The split is already an open source of factory for GoScript CGK. The change is still pending. But once that is done, that is also reducing the amount of packages brought into. And it's a good example why it's sometimes a little bit of tricky to find the right package to add as a request and why it's sometimes very good if you split your package. So if you're a package maintainer and you consider of having everything in one package, think about the dependencies if it's really needed, if it's useful to have it in several parts. It's obvious when you have plug-ins or anything else. But there are also parts where this is not as obvious, but it makes a big difference. Yeah, that's my call for action for everybody. If you see dependencies that worry you or if you install a package and you suddenly end up with packages where you wonder why is this the case, don't be shy, open a bug report or look into it or even better submit something because that helps us all to get the distribution smaller, to get the stuff that the footprint, let's call it in that way, that we pull into when we update smaller and it helps also with maintaining all that stuff. At the same time, if you create a new sub package, please think about the description. There was a long thread on one of the open Susan mailing lists, so I will not go deeper into that, but opening a bug report or submitting a patch to adapt a description is appreciated. And not everybody knows what is in a sub package, so that is also helpful. And one more thing, advertising a little bit here. With SLEED 12, we started to have public beta. So while with code 11, you had to be one of our partners and be in a partner program to join our beta and were hand selected and had to go through an assessment center and what else, it was not as bad, but nearly to join. We are in SLEED 12, public beta where everybody could join and we plan to have the same thing again for SLEED 15. You have seen beta one will come in September. So you have still time to apply there. We ask for an email address and a few other things as far as I know. Go to the URL that is mentioned there. You can also search on the SUSEB main page for beta program. There is everything you need on information and there is also the way to say I want to join. And then you can get SLEED 15 images relatively soon when every milestone is finished. And published, you have access to it. We are happy about everybody who joins there. We are not promising to fix every bug report there, but we try our best to get everything solved to your satisfaction there. And it's really cool if you join there and get these images early enough so if you are missing something or think something is wrongly configured, you can influence the SUSEB enterprise product and therefore also to a certain degree LEAP because LEAP will also be based on that. So with that, I'm at the end. We have around one minute left, but if there are questions and answers, I'm willing to go beyond that time frame that I have. You got my attention when you said that you were changing the firewall. And what I'm wondering is if I have an application that's dependent on using the CLI or API calls to the old firewall, is that going to break my application? That's a good question. That's why I asked it. And I'm sorry I have no clear answer to you yet. We have a script. We are currently looking into the migration path there, what we can do to make the transition easy. We are not 100% sure if we can cover every case, to be honest. Oh, thank you. But of course, join the public beta and there, I think if you bring it up, if it's not working, then we will look also in these cases. Because I don't want to lie to you, we are not there yet that we can say for sure everything or every situation is supported. I'm pretty sure not seeing what some people do with the firewall and a few other of the old stuff. And in case you ask, I've seen people doing things with a finger server where the finger server was never intended to be used for. So, and we will drop that in case you don't know what a finger server is, don't ask its old stuff from the last century. So yes. Well, I appreciated your comment about not wanting to lie to me because it reminded me of an old story about the difference between a car salesman and a computer salesman. A car salesman knows when he's lying. I'll leave you with that. I just sometimes have no clue, but that's all. You wanted to say something? Also related to the question about firewall, is there any schedule change with regard to the network management infrastructure in SLEE 15? Sorry, I didn't get the last part. Is there any plan to change the network management infrastructure in SLEE 15? Because right now, as I see it, there's basically three solutions that basically exist and need to be maintained somehow. You're talking about Wicked Network Manager and the SISTEMD Network D. It's not so easy to answer. We will definitely keep Wicked. That's for sure. We definitely plan to keep the Network Manager at the moment. We are nevertheless looking into getting all these reintegrated more closely and especially on the system, the Network D side. We see on the upstream side development that's very encouraging. There were one or two years ago still the tendency to use that or to have the main purpose for that only on the cloud stuff. Meanwhile, that intentions for it have changed. We are looking into that and planning to integrate all three, but we will definitely have as main systems the Network D as well as the Wicked. Because for one thing, we don't want to change all the conflicts in a migration. The other thing is we currently don't think SISTEMD Network D is where it should be, for example, for a server infrastructure. Does this answer your question? Yes, it's a pain that we have so many things. That's why we want to integrate it. More questions? If not, then I'm one minute late, but my architect is used to that. Thank you very much.
the scope side? Yeah, it's a new major code again for SLEED 15. You have seen beta one will with the firewall and a few other of the old about the difference between a car salesman and a