 Okay, thank you very much. I hope you can hear me. I can hardly see you, but I hope you can hear me So welcome to this presentation I'm going to talk today a little bit about enterprises enterprise community computing and communities I think With the sort of people attending here, I'm probably don't need to tell you too much about Open-source computing and communities. So I'm focusing a little bit on the enterprise aspect of this presentation So Let's time warp a little bit back 20 years ago When I went to a party and you know somebody asked me, you know, what are you doing as a hobby? I started like you know, I'm You know playing with this Linux thing working on the kernel and then after two minutes Their eyes would start glazing over and then they wander off to the bathroom or wherever they went to Today it's a lot easier. So if you have if you're having the same sort of conversation today You could say things like, you know, I work on the stuff that keeps your mobile phone running Or Chances are that you can just point to a random appliance somewhere and say this is running the stuff that I'm working on Okay Or a bit more outlandish. No, this is not Darmstadt where I live This is Mars and you could say things like, you know, I'm writing code that flies to Mars Or you could talk about this one, can you spot Linux in this picture? So the gentleman there is of course Steve Jobs, this is in 2011 when he was Talking about the new data center. They're doing in North Carolina and the machines you see there are Terra data warehouse appliances They run Linux actually Susie Linux enterprise to be precise So Apple loves Linux too And what you saw in that last picture data centers this is really what enterprise computing is about and I find this a very exciting area I Like working in that area They have all this big hardware these big iron machines They do fancy things with all the components we put into the operating system They come up with crazy ideas. So from a technology perspective, all this is very fascinating But there's a different side to it Enterprise computing is also really a very specific a very special ecosystem With lots of Interesting plans and conditions and whatever. So let me talk about those. Let me talk about those a little bit In terms of cliches, I think There are a lot of cliches on both sides if I'm talking to a lot of people about enterprise IT It'll probably come up. They probably come up with something like this Not very agile not very easy to have a conversation with They're just doing a little bit of code on top of my operating system So That's enterprise IT and if you talk to enterprise people Sometimes they will paint a picture about open source community that looks a little bit like this not Very easy to have a conversation with They start to laugh hysterically when we asked them for their roadmap They're just a little bit of code underneath my application and they don't really understand my business needs So it looks like we're all set for a very good Calibration getting along with each other, right? So somewhat more seriously Open source communities, I don't think I have to tell you a lot about this from what I see Open source communities are really about three things one is contribution and participation The other one is really about freedom and not the free beer variety and the third one is about quality okay Enterprises I think that is an area that not many people working in communities are too familiar With so let me spend some time on those When you think of enterprise you think big companies you think lots of money and consequently Their IT departments probably have a lot of money too, which is not true. They live between a rock and a hard place They have been faced with decreasing budgets for years And they don't own everything. They're just a supplier. They're a service provider and they have service level agreements They have people with the applications breathing down their necks and they're just trying to put together stuff that works well The other important aspect is that for them change is cost for us change is great because we can Come up with great new ideas for them change is cost. They have to port their applications They have to test them Deployment can be hideously expensive if you have a very distributed Organization with branch offices and whatever and you have to send people there Getting software certifications training and support so change for them is Expensive right and even worse for them downtime is often very expensive both in terms of money So if you have a financial application or anything like that Running on 24 by 7 if it's down for an hour It's really a lot of money with a lot of zeros that we're talking about and Things get worse if you are in an area where human lives depend on the mission critical Applications right so you really don't want these things to go down Let's move on to some real-life challenges that we that I have seen over the past 10 15 years Which are really difficult to handle but good to understand maintenance windows If you're running your own little Park of machines like I do then just updating is okay I sit down on a Saturday evening and I apply some changes. I install a new version whatever In enterprise computing that's they don't have that liberty right they have maintenance windows That they have to adhere to and that may be as little as 15 minutes a year Now if you run one of these big iron machines that takes eight minutes to boot Then you know exactly how many kernel updates you can do in one year a Slightly different scenario is sometimes you have workloads running very very long and very long means about six months Eight months ten months and you can't really shut them down in the middle to apply the kernel update the guys would kill you So maintenance windows play an important role in trying and talking about change in an enterprise environment talking about change I Mentioned that rolling out new code is cost in an enterprise So once they have it down pat and it's perfect for them They want to hold it there as long as they can and for most of you I guess a Support cycle a life cycle of 13 years sounds absurd But for many of these customers, it's just great and they asking can can we have two more years, please? So really this is a very different expectation in terms of how long something is around A slightly more extreme example is with a bi's so we have got Software vendors who built stacks on top of linux that they want to sell to customers and If they have to build that stack for three or four versions of your operating system, that means they have four times the expense So they're trying to be smart They say I just built on my oldest supported version of this operating system And I want to make sure that even the people who run the most bleeding edge version from that vendor Can actually run my application nevertheless, and we've got several of those that we are very familiar with So to these people a bi stability of the user space applications is really a crucial thing and To them a bi's are of course things like g lip see the x11 libraries and whatever but it could also extend as far as Hmm, what do we do with these files in under slash proc or slash sis? This is shaky ground I know but from their point of view ideally they would like they would like to count that as part of the a bi as well We don't have to go there, but it's just to illustrate where the appetite is coming from Innovation of course, I mean when they are when they have their System setup for 13 years or longer. They're still need for innovation, right? Because they don't they can't stay on that same old hardware forever They need to deploy new hardware the machines that will be around in five years from now are very different from those that are around today So at the very least hardware enablement is a major requirement for them But of course there are other things that they say that that would be nice to have Now interestingly if you're dealing with enterprises a lot of different enterprise customers Everybody has these three things. They really need Unfortunately, they all have different three things that they need So whenever we are talking about creating the next release for instance We have that choice to make between okay, which of these things are important enough Which bubble up high enough to actually make it into the next version so there is always this give-and-take between What do what is everybody asking for and what can we give them without being too disruptive another important topic past couple of years compliance This is really about standards Standard processes and processes are a good thing on one on one side If you're dealing with thousands of machines having a process is good because it structures everything on the other hand, there's a lot of legislation recently that Set certain standards for how to deal with credit card data how to deal with financial data So this is creating enormous pressure on the guys running these IT These are the corporate IT of many companies. I think from my perspective as a citizen Having good control over what companies do with with my data with financial data with credit card data is a great thing but for them of course it creates a lot of red tape and They have to adapt the way they roll out operating system releases. They certify them and so on Another layer of complexity for them good so I talked a lot about the Constraints these people are facing but really what it comes down to from my perspective when we talk about enterprise computing is Adapting innovating of Course we all We've been talking a lot about these these retrograde forces that actually hold them back But at the same time they want to move forward and they need to move forward At first at first blush it seems like it's very hard to get these two worlds together Linux communities open-source communities on one side and enterprises on the other and It feels a little bit like interstellar travel, but really it's something that needs to be done From my personal view. I think one of the areas That Linux absolutely Unix absolutely failed in was being able To adapt to have a way how to bring innovation forward they all started out from the same code base and then they forked and forked and forked and then they found themselves on this Little planet that they had created without any meaningful and useful way to adapt change to innovate They could innovate in their little niche But that was not enough in the Linux world today We're very different because on a very fundamental level Everybody is collaborating everybody is working on the same set of innovation and we can just take from that so rather than being this little Dinosaur race on this planet over here and another planet over here and yet another over here We are working together to create something and then it's just the vendors becoming sort of the conveyor belts of Bringing that innovation into their products and into the distributions Let me go through this rather quickly when we're talking about how to absorb change and bring them to the customers There are four stages one is don't touch anything for some time, which I think is a viable short-term option I don't know how many of you actually Update their phones every time it says please update me I think it's a valid approach Backporting patches. This is something that if you have an existing release This is the default mode of operation for instance when you issue security updates or the critical bug fix updates You want to keep the risk low and you want to just plug this one little issue? One thing here I want to mention is that actually a lot of the projects around are Being very helpful with that respect either by having policies that support that or even by having a stable branch or Regularly stable releases like Firefox for instance Of course, there are also a few very really difficult ones out there I'm not naming any names, but in general what we're seeing is maintenance of enterprise Distributions being a one-off effort It's converging towards sharing that effort more and I think that's also good for Linux in general Updating to a new version that is something that we usually only do during service packs but Also there is all there's always the risk question how much can you do? There is a significant amount of quality assurance that you have to do there So there is a certain risk But we found and this is one of my favorite examples here There is actually a good reason to start moving a little bit faster with these things Traditionally when it came to the kernel in a service pack We were just back porting upstream patches lots and lots of them So you end up with a frank and kernel over time that carries like 12,000 patches It works. I mean we've proven that over 12 15 years that it does, but it's There are better ways today, right and that is also rebasing the kernel as part of a service pack update This is really a testament to the way the Linux kernel is being managed today The 2.6 development model for us has been really great It is at a very high level of quality so we can just Actually take out the old kernel put in the new one and rather than spending a lot of time on back porting patches We can spend more time on hardening it on Looking for you know all the enterprise scenarios that people are running to make sure that those are still valid It does require a fairly sophisticated test automation though and a white and a very wide coverage The last option here is replacing That means you just rip out one component and replace it with another That's something you really normally only do in a major version update And even there it can be very funny What we just did in and Susie Linux Enterprise 12 we replaced in it with system D This is a major change But I think it's a good change. It is a good replacement. It's great innovation And like any good innovation is very painful But still surprise actually to me quite surprisingly the feedback from the beta testers on replacing in it with system D Was pretty positive So I think that was a good move the important thing here from the perspective of the enterprise people is Backward compatibility that is really the key for everything Okay, so I have a little bit under two minutes left. So let me go through my final couple of slides I talked a little bit about the maintenance windows That seems to be like a very hard problem to solve But actually there is a lot of benefit to be had for the customers here And this is why people have been looking into that repeatedly In general you can update a lot of the components pretty easily in a running system So you don't really have to worry about those the one critical piece is the kernel You cannot replace the kernel without rebooting the machine and I talked about these 15 minute maintenance windows for an entire year So these people are really asking for kernel life patching Modifying the kernel on a running machine without rebooting This is really a little bit like juggling chainsaws. It's very easy to get hurt And you really don't want to try that at home without somebody nearby There are a couple of alternative approaches some proprietary some open The SUSE labs have been working on something called k-graphed I know that there are a few other projects out there and I believe at the plumbers conference There will be a get-together to talk about the differences and what can be joined between these projects We are launching that as an offering with susan linux enterprise 12 In a nutshell it replaces entire kernel functions It's compiled with PG So it's really what f trace is doing and you can just replace the function by Modifying the preamble of that function. It's a little bit more tricky than that But that's the bottom line As I said it launches on top of sleep 12 And it's one of the things that we've been trying to get More innovative approaches into enterprises Okay, I think I'm not going to get to any of those now my time's up Thank you so much for listening. I appreciate that. I hope you enjoyed the presentation and with that Thank you very much. Have a good day