 Thanks. But yeah, as I've introduced, I'm Ludwig and the reason I'm talking to you is that I'm getting paid for that. I work for SUSE quite some time actually. So, why am I here? Well, SUSE has been around for more than 25 years now. And the reference among you probably knows SUSE from former times. It's been a KDE distribution right from the start. And for a long time, KDE was actually defaulted in SUSE. It was employed lots of KDE developers. But thanks, James. At some point, SUSE decided to go from known as a default for the enterprise distribution. Now, as KDE always kept its place in SUSE, in open SUSE, open SUSE kept having KDE as default even. Also, open SUSE changed over time. So, we have this open SUSE releases that were snapshots from factory back then. And we here have model changed. So, now we have two distributions. Now, I'm here to tell you about the two we have now. Because maybe I'm not aware of the changes in our community. So, we have two now. One of them is Tumbleweed, the rolling release distribution. And the other one is Leap, that's what I'm responsible for. That is the stable distribution. So, Tumbleweed being a rolling release distribution, always has the latest and greatest of everything, of course. You get new versions every day. That's normal for any rolling distribution, I would say. So, what's the cool thing there? Well, we have kind of a CI operating system level. So, we're not just dumping new versions of packages on our users, but there's actually an automatic GAI system involved there that makes sure that there's always some base quality achieved so the system never breaks. Tumbleweed has around 50,000 users involved. So, it's nicely growing. On the other side, we have Leap, the stable release distribution. Based on the SUSE network server sources. Normally, we have maintenance updates, so it doesn't change much during the year. And then, every year, we have a minor version, kind of a service pack that gets more features. Overall, if you follow all the maintenance and service packs, you get more than three years of maintenance in total. So, the card release 42.3 was just extended with the maintenance. So, we are now at 44 months, actually, from the start. And Leap has about 200,000 users. In total, we have even more. So, there's a long tail of users that keep using open SUSE versions. Okay, so based on those facts, both distributions are obviously for different target audiences. So, yesterday, someone asked me which one is better, Tumbleweed or Leap. Well, there is no such generic answer because there are a lot of different user groups. Tumbleweed, I think the latest and greatest stuff, is more for developers, for contributors of both open SUSE and also upstream, because we're very close there. And of course, for power users, they're just like the latest stuff, everything. Leap on the other side, being more conservative, is suitable for production use. It's effective to software and hardware vendors, actually. For example, the Slimbo guys. They want to put Leap on their systems and they ship it to users. And that's for users, of course. We ourselves don't really target users with open SUSE ourselves, I would say. But those who deploy Leap, they have users on their hands, so they target Leap with users. So, let's talk about the common features in open SUSE, because you may not be aware of them anymore. Those are little surprising systems. They are general purpose. So we are not doing open SUSE for a specific use case. We can't say this is a container distribution or this is a data distribution mode. Power is pretty generic. It scales from the small respirator to huge data centers, basically. And we do all of that based on R&D. Our plan is our package manager, for better or worse. I guess we will never change that. That is our technology. But that doesn't mean it's bad. We actually have packaging policies there. We can't just take a tower and put one big R&D. But we have a wide packaging policy, for example. So, our packages are split up in smaller chunks. We can actually build very small systems or systems that contain everything including documentation, including development files. All that is possible with R&D. What's also worth noting is that open SUSE is self-hosted and reproducible. That means everything you see in the open SUSE build service is actually used to build open SUSE. There's no external components that are magically used to build the packages there. But everything in there was used to build themselves. So, the GCC there, with the GCC and GCC was used for GCC, for example. All of that is source-based. So, in some distributions, developers upload binding packages, for example. That is not the case for us. In our development process, the package always has to upload the sources. Then, file a submit request. That's similar to the development process of GitHub, for example, where file pull requests. Those requests are then reviewed as a source review of automated tools as well as a human review. And only if those reviews pass, the cost of getting into the main web home. And then it's rebuilt there and set aside. That process is open to anyone. You just need an OBS account. That means basically a human address. There's no procedure to follow. You don't need to be a member of anything. You don't need to sign a CLA. You can just sign up in the Office of the Build Service and start contributing there. Yeah, let's talk about how we can deliver the operating systems. We have the traditional installation that you may know, the YAST. So, you put a USB stick in the laptop and do a manual installation. That's the traditional one. But you also can do mass performance, for example, using audio YAST. So, the installer can record all the actions, save it as XML file, and later you can do another installation, pixie boot it, that replace the installation difference system. You can scale it up, of course, to a huge mass deployment. You can also use this method to create preloads, for example. So, there's an OEM installer that's called YAST First Boot Wizard. So, in the system, once up to first time, you would ask the root password for the username, for keyword language. That is also possible. Useful for guys like this, limbo guys to preload laptops. We have live images, that's more interesting for end-users, I would say. So, if you want to try to focus your works in your system and download the live image and try that, you have them both for KDE and GNOME. And you can use the live images also to start an installation. On top of that, there are also virtual machine images for KDE and GNOME for VMware, whatever VM technology you need. We have containers, and KDE is also in this Windows sub-system for Linux, which is quite popular, I heard. And if that's enough for you, there's KDE, and KDE is a technology for building your own custom images. You can assemble those upends, your own flag of the distribution, if you need that. And you can also upload that to OBS and use the build service so that you have a client or customer installer. Okay, back to Tumblebee. It's a fully rolling distribution. That means Tumblebee doesn't just update some components, like we have the latest KDE, but an old kernel now, that is not the case, Tumblebee always updates everything. No exceptions. All the 11,000 source packages it has get updated hundreds per day, all integrated together every day. And this is enormous, the power behind that, what we change there every day. And to make sure it doesn't break, we have those automatic tests using OpenK. I was surprised to hear about another talk already today. And if you want to know more about that, I suggest you go to the distribution spot where Fabian will talk about that a bit more. So those automatic tests make sure that the system always comes up into some defined state. So we know the kernel boots, we know the bootloader works, we know the system didn't break the system somehow, we know that PIX can start a theory, we know that KDE can log in your user, we know that it can start firefalls. If the installation that doesn't work for you, then it's most likely some hardware issues, some local issues, but we know that the distribution in general works. And whatever happens, we normally always have network, for example, to fix your stuff. And if it still fails for you, we can do a rollback. So what's good in it, so both distributions is a snapper tool. Sniper works on butterflyFest, which is the default file system for us. So whenever you install a package, or a distribution upgrade, or just do a maintenance update or security update, snapper will take a snapshot of your system, then install the package, then take another snapshot. So if that installation fails for no reason, or your system breaks after it, you can do a snapper rollback, reboot, you're back on the old state, and can report a shock or fragile recovery from that. Sniper snapshots, it's pretty quick. Yeah. Thunderweed is available for X86 and X8664, it's primary architecture, and they also bring reports to ARM, AR64, GALP, C64 and SV90. Those are not as much tested, and they're mainly there because Thunderweed is the base for the next distribution sacrifice. So they are already testing ahead of time what's coming up there. But it also makes Thunderweed kind of interesting because you can both see what's coming there in the Linux world, and you can also influence it. So if you put stuff in Thunderweed, there's a chance that it just flows into a certain sacrifice in the future. And what does that mean for KE? Yeah, you get always the latest Linux technology to develop again. So you have a new crown, you have the latest system D, you have the latest X, Y-Land, whatever you need there, Qt. Always the latest environment. The releases are shipped pretty quickly, nearly the next day of the release, if you call it and release it a little bit. So Thunderweed is really great for cool new stuff. Its users are looking for that new stuff. They want that. And if there are any issues, they will be fixed quickly because developers use that system. So whenever something breaks, they are interested to get that fixed as quick as possible, because it's rolling, the fix will be there the next day. And as I said, easy recovery. So whenever the CRI failed and didn't cover your use case, you can always roll back, skip a few snapshots, and then get the fix for the next one. Okay, so much for Thunderweed. The base system there is from Succedino's Enterprise or the space system me, but it's basically everything up to GNOME. So the kernel is from the system, the GCC, GCC, X and the GNOME environment including Qt, because that is used for just all the rest. That also means KDE is taken from Thunderweed at the time of release. So we will not keep getting updates from Thunderweed on those components, but take the ones that are basically there to release KDE and stay with that. And the release is chosen, so to say, on the major version. And then we get maintenance updates, so we only want to have bug fixes and release to not break any other surprises to users. Over time, there are usually minor versions, as I said, kind of slow specular updates. And we was available for HG664 with ports to R1 and AR64. So there's also a Raspberry Pi 3, which for example. Again, minor versions have slow spec like upgrades, so they may introduce some features, but they are not a complete release on Thunderweed. Coming from 3, the current workflow kind of is that every other minor version has slow spec is a bigger one. So right now we release 16.0 and we'll have 15.1 next year. That would be about a small one, just considerations and bug fixes that we couldn't get into the .01. And then the next one, the 2, is probably a bigger one that adds more features. But even if those service packs add new features, the completion always is that they are painless updates. So we want our users to follow the service packs, so we need to do it easily, so we don't want service packs to break. So whenever there's a new feature or something in a service pack, there needs to be an update path. It shouldn't get stuck there. What does it mean for KDE? Less is more. So we rather have one or two really cool features that are really stable, mature, and work for the users rather than 10 that are just shiny, but then turn out to be annoying. You need to keep in mind that we can't upgrade random components, so even if you're thinking about this new Python module, for example, that looks harmless to you, but actually in those 11,000 source packages, there may be a hundred that also need that Python module, but in another version. So we have to integrate all of that, so that compromises either we upgrade all those 100 or at least check them, which is also effort or we don't. And normally we don't have infinite resources, but if all this don't upgrade, we don't do that. But as I said, some upgrades are possible for two years, so when there's a bigger service pack, there's also a chance to introduce new features. So in 12, 312, and that only 42, we upgrade it cute for example in service pack 2. And with that we've got a KDE version. What else? I wanted to mention translations. So developers tend to not see other languages, so I'm guilty myself if I look at the screen, and it's in English or in German, I don't see the difference normally, unless I'm really looking for it. But for stable release it's important. There are users that are not that familiar with English, and we need the translations there. For developers, Deep is also attractive to develop for the LCS version for example, because not all developers also work to the latest and greatest current system D, and maybe I'm more interested in the LCS version that I used by users, so Deep is the better base for that I would say. So let's talk about what we have right now. Right now we have two Deep versions for the maintenance. One is 42.3, was released last year, and lives until next year, so the maintenance was just extended for that. It has Q5.6 and plus 0.58, and currently the 15.0 was released just a few months ago in May, and is maintained until November next year. It has Q5.9 and plus 0.512. Speaking of that, I don't even know what kind of KDE applications are in there, because that is not in my mind, so if it was for me, please just call the KDE and put a version number and it would be completely fine. I don't really know what the other stuff is. Did the version went backwards? Yes, the version went backwards. But there is only the user visible part so there are game markers and all that. There is a special story about all of that, so let's have a view about that. It's not the topic of this talk. I'll talk about Deep. Next year we have 15.1, most likely around the same time as this one, I don't expect major changes even though I haven't talked about it much, so I would say same as before. After that, no concrete plans about 15.2, but I would expect it to be 20.20. Since the pattern was big updates and after the other service back, I guess that the Succeeding Enterprise base will do some upgrades mainly for hardware measurements, for example, from SystemDX and maybe also Qt, but we don't know yet. The good thing is, we have an influence there, so if you as KDE community have an opinion there or we should do with KDE, if you need a new Qt version, let's talk about that in advance so we can coordinate with the Slee guys. On the other side, if I get to know the Slee plans, I will approach you and let you know what's coming, so we also know whether they're going for a new Qt version or not. In any case, by default, I would prefer less changes, so I wouldn't actually upgrade the KDE S version and I would prefer to have the same version over the full lifetime, because it's just less surprising to users. Always keep in mind that there are many costs attached to upgrading the desktop environment, so the old version don't, use because the mind can change. One more thing, through the package shop, it's not really an open source distribution, but this is the community packages from open source, built for the enterprise, so that is the bridge into the enterprise world with LEAP15, we're very closely aligned, so in the same way as LEAP uses the same base as Slee, Slee now can offer the remaining packages from LEAP for Slee, so that is how KDE gets into Slee again. So even though Susie has known by default supports GNOME, doesn't support KDE, the users of Susie Leap Enterprise can go there, officially enable the package shop channel and get KDE there. So someone else could support KDE on Slee, Susie doesn't care, but it's a big chance that KDE has there. So we close the cycle, Susie Leap Enterprise LEAP package shop. Yeah, to summarize we have offerings for both developers and also for production use. It's a friendly environment. We actually like KDE. There's still lots of friends in Susie that like KDE, that are former KDE contributors are still contributing to KDE. There are many, many employees in Susie that use KDE actually despite a different default and the base system is backed by the company and both in town will be as well as in Leap as a big chance because there's always an interest to get that fixed and not just let it go away in some way. Susie has been around for 25, since 25 years and I hope it will last another 25 years so we're here to stay. So let's make KDE shine open Susie. That's it from my side. Any questions? How do you feel about open Susie derivatives that exist outside of KDE? I don't know that one but my recommendation would always be to get as much as possible into the main distribution because only that way it's on our radar. I mean, seriously for example, a few years ago I talked with the package manager for NewHealth. He was complaining that it breaks whatever release he has to take care of adjusting it and then we just helped him to get just into the distribution. That way they stay on the radar of release management. We know if there's some update or I know some Ruby gem we know that NewHealth is going to break just made up an example. So that way we can notify in advance and people will help him actually to fix the package if it breaks. So if you do some later some spin-off open Susie I would recommend always get your changes into the main distribution and keep your depth as low as possible. Is there some KDE we both know that when Susie the program for KDE upgrades available for you? Who is in charge for such a repository? The guy in the line behind you probably. Thank you. Just talk to him after the talk. So I just work with all you OCI what is the status of those upgrades of KDE? They are partially integrated I would say so they are our KDE team with this argon and clip-down live images based on the OCI cross of KDE and those ones are tested by OpenKDE. And that is also what makes KDE easy to integrate because our KDE team packages the latest KDE and this is by OpenKDE already so by the time that they have a sale release and it should go into town we don't need we have already tested it the integration tests most likely pass so it's very quickly going there but that is kind of special to KDE because they really put effort there to integrate with the testing framework in general OBS reports do not have this this automated testing there that's what you only get when you are in the distribution. One question Thank you Gurga Welcome Deep and the next talk will start in about 5 minutes