 Okay, I've got about five minutes behind, so I might zip through a few things. Okay, so in 2015, HP Linux was an internal Linux distribution based on DebianJetty. If you went to this talk last year, you might have seen one of my colleagues give a 2014 version, and it used to be called HP Linux, but when HP was split into two companies last year, the marketing people got a hold of it, and it's now called HP Linux, which is much more of a mouthful to say. We had one customer, one internal customer, HP Helion, which is HP's hybrid cloud product for large scale installations as an open stack. Okay, and for things that aren't in Jesse, we have this idea called Foreign Packages, where we would add new packages that weren't in Debian, we can add them as a foreign package, we can back port security fixes, or add different versions, and just generally have things that aren't Jesse in our Linux distribution. And obviously, well, not obviously, but we would like to keep HP Linux as close to Jesse as possible, but unfortunately that can't do that all the time. But we have the foreign packages with the idea that they're temporary, and that we would like to replace them with free versions whenever possible. Sorry, Debian versions whenever possible. In Kernel Land in 2015, we're using Kernel 3.14 and later 4.1, and we had a big kind of testing program where we would do qualification and performance testing to ensure everything works out of the box. Okay, so in 2016, what does HP Linux look like in 2016? Well, it's still an internal Linux distribution based on Debian Jesse, and at the end of last year, the CTO named HP Linux a technology standard within the company, and this is a pretty big deal, I think it's pretty exciting, and I'll talk about that in a bit. And we've grown from a single internal customer to a half dozen or so internal customers, all building products in various stages of development. We still have the foreign package idea, but in this last year, we've managed to replace a couple of the foreign packages with free versions, and we've also started using Jesse back ports as a way of getting more up-to-date versions of packages into HP Linux. And of course, we're still keen on minimizing the difference between HP Linux and Jesse. And yeah, this year, we're moving to a 4.4 kernel, and we're still doing our testing program. Okay. Okay, as mentioned in the last slide, HP Linux is now a technology standard in HP, and this means that all new products and major releases of existing products that are using embedded Linux now have to use HP Linux, which is basically Debian. And this has a whole host of benefits, and I think it's really exciting. And it's pretty exciting that a company like HP has chosen to use exactly one version, a distribution of Linux within the company. I think prior to that, there were about 11, maybe a bit less than 11 different types of Linux. Eleven to 14. Eleven to 14? Wow. Okay, I didn't think there even were 14 different distributions of Linux. Okay, anyway. So 14 done one, I think that's really a good thing. And so what does this mean for, what does this mean? I think it means more investment in Debian by HPE. And since we've grown from one internal customer up to a half dozen, it also means we're making more developers, hopefully more Debian developers, hopefully little D and big D Debian developers, and we're also making more users. And included in that is customers as well. So I think like any company, the customers come in a range of different kind of technical sophistications. And some customers actually like logging into their product and poking around and seeing what's there. I believe some of them are happily surprised to find that they're running Debian. Yeah, unfortunately, and sadly so, some products and market segments can't be switched over to Debian. So I think there is an exception process for customers like telecommunications or other people who need some real-time requirements and other things that can't be satisfied with a general limit distribution. Okay, so what we did in lessons learnt, I'm going to divide that up into three different sections talking about product, what we did in a product way, what we did in the community and what we did in terms of process. So firstly I think in this talk last year, Josh mentioned that we did, sorry, the person who presented this talk last year mentioned that we did a successful 1.0 release of Helion using HP Limits as the base OS. So that went really well and this year we did a bunch of 2.x releases and just recently a 3.0 release. And yeah, I think I've been a bit lucky in that a few of the products that were forced, highly suggested to use HP Limits were based on Ubuntu. It's not such a big jump from Ubuntu to Debian. So I think that worked out pretty well in terms of getting new customers on board. HP Limits is a technology standard. The lessons learnt, I think you treat your reference customers really well. We had one customer in 2014, Helion, and I think we made a really good effort to treat them well and they spread the word among the company, I think, and amongst the management that HP Limits worked really well for them. They gave us a very tight series of deadlines that we managed to get everything working for them and I think I believe everyone is reasonably happy in the end. Another lesson delivering enterprise software in Debian is definitely possible and I think that's mostly something that we show inside the company that we can do what we said we were going to do using Debian. Yeah, in terms of telling entire companies they have to change their distribution, I think that could have been bad, but if it just works and you've got support in place, there's generally not, there wasn't, I don't think there was a huge amount of pushback on that. And parallel to that, centralisation is really important for letting people know how to use HP Limits, what it's all about, you can't just tell people to go and use Google and expect them to be happy you need some central locations documentation and mailing lists and kind of human points of contact. In the community area, this year we replaced some of the vendor packaging, some of the foreign packages with free packaging. So with the assistance of, with a lot of assistance from the package Java team, we built a version of Elasticsearch, the open source text indexing and searching engine. We replaced the vendor packaging with a free version in Debian, which you can use now. And Ditto for Docker, that is not available now as vendor packaging, which is vendor packaging is someone other than the author, sorry, the parent company has built this binary blob and you install that. And you can imagine that people might not necessarily be keen on that. So again, with lots of assistance from the package Go team, we have a really nice new spanking 1.11.2 actually, a version of Docker in Debian. And that was uploaded to Unstable yesterday, which is good. In the community, we did some, Lynn sitting over there has done some, helped doing some contributions to FE Secure Boot, and that's apparently being shipped to customers. And we were working on that on ARM64 as well as AMD64. And Martin, Martin Mickelmeier, maybe here, he did several full rebuilds of the ARM64 archive on some of the, some of our hardware, high-complete with kind of filing bugs and doing uploads and things like that. So that was, that was a good fun. The lessons here, working with the community takes, takes a lot of time. I mean, that's, you can't, I mean, as we've seen in the internal land, you can't just come into a community or some group within Debian and dump a whole lot of stuff on them and say, here you go. Now you've got to kind of build relationships and trust within the community. And that takes a long time. It takes a lot more than you think it would. The other lesson, it's, yeah, it's actually hard work convincing people to get really involved in the Debian community despite kind of our bosses saying it's fine, you can do it. You go ahead and do open source stuff. It's still hard for people to do. I think, yeah, from a time point of view and also, if you're not used to working out, working out in the open, having all your work available for scrutiny by everyone, I think that can be a bit, that can be a bit confrontational. But yeah, hopefully, hopefully next year we can say we've got some more Debian developers and Debian maintainers. And finally, our process improvements. So I think we did a really good job this year in getting HPE Linux. We're going inside the company, getting it used by lots of different people, lots of different groups. But unfortunately, I don't think success has really led to even giving us any more resources, any more people or any more money. In fact, quite the opposite. So yeah, as a bit of a theme, I guess over the last four or five years we've always had to do more with less. And I think the best way to do that is through process and better processes and improving your processes. And to do that, one of the things we've done is implement this what's called a baseline release process where every four weeks we generate a new version of HPE Linux. So half of that for two weeks, developers in the company can upload new versions of packages, do all the testing and then freeze, comparatively short freeze. And there's a two week phase of load testing and stall testing and things like that. And then so every month we have a new version of HPE Linux for customers to try out. We've been doing lots of package accepted testing. So when you do a DPUT, there are a whole suite of tests run against that package and they're actually more strict in some areas than Debian which can be a bit frustrating if you need to add some, need to go back and fix a bunch of things. But we've got lots of metadata. We're trying to keep the metadata consistent. We're trying to add more metadata so we can do package analysis and package tracking. Also a similar thing in security as well as following along with the Debian security team. We have our own internal security team with our own open source and proprietary tools to do more security analysis on the archive. And finally, everyone's got to write their own kind of CRC system, CRCD system, right? So we've got our own one of those to do bare metal, basically doing bare metal and different hypervisor testing. So part of our test suites are running HPE Linux on bare metal on various bits of hardware and also doing testing on the different, I think we're doing, we're thinking about three, supporting three different hypervisors. The lessons here, I think technical problems are actually pretty easy to solve. You get some smart people in a room together and a solution pops out a few days later. But getting human processes working, I think, is a much harder problem. Yes, I think it takes a lot longer than technical problems. And process improvement is continuous and never ending. I'm pretty sure we're not going to go back to the good old days when there were people and money everywhere. So always got to do, always got to be improving our processes. OK, so that was the first part of the talk. Are there any, can I quickly, is there any questions about HPE Linux before I go on to the next part? OK, fantastic. OK, so the rest of this talk I'd like to explore this idea of slides. OK, I've got two sets of slides. OK, I want to explore the idea about thinking about a Linux distribution using the analogy of middleman and how it can use that to communicate the value of Debian. OK, so what is a middleman? A middleman inserts themselves between two parties with the goal of making the transaction between those parties easier or cheaper. And ideally the middleman adds more value to both sides than it consumes. I think middleman probably have a bit of a bad reputation in society at the moment. I guess people think of middleman as parasitical or not actually producing anything of value. But if they're in between two parties and provide benefits to both sides and they don't consume a lot of that benefit themselves then middleman can be quite good. OK, so an example, some examples of middleman. eBay, so I guess this is kind of an obvious one. In the mission statement, bringing together buyers and sellers. So eBay, if you've got a whole bunch, you want to sell a whole bunch of junk at home, eBay will help you find some people you want to buy while you're junk. And they take a little cart of the transaction. Facebook, I think Facebook is a really good middleman. So you've, again, the parties involved are people and Facebook allows you to, as a provider of status updates about your dinner, you can Facebook and it hooks you up with people who are interested in pictures of your dinner. And although they don't actually charge a fee for that, like eBay does, Facebook shows you at it. So that's the cost in that transaction. OK, now getting a bit more abstract here. A middleman or doctor is actually a middleman. So on one side there's you and you've got a cold or something and on the other side of the transaction there's no medicine. Other, you know, other medical specialists or kind of services like x-rays and whatnot and the doctor acts as a middleman to connect you to the medical services and the medical products that you need. And finally, Debian. It's my proposition here that Debian is a middleman. OK, so Debian distribution is a middleman. Who are the parties here? Actually there's users and software, they're kind of obvious. And there are also Debian developers and upstream developers. So it's a bit more complicated than kind of eBay where one person is selling to one other person. There's many different parties, many different types of parties all kind of connecting together. And we can think a bit about what value Debian adds to each of the parties here. So users get access to a lot of software that works well together, works well inside the system. The software gets access to a pool of users and Debian developers have access to each other. And we can probably think of other benefits that are provided by Debian acting as a middleman between these different groups. But I think as Debian developers you get to meet other Debian developers to work with and be in a community with. Upstream, you know, they get access to a well integrated kind of operating system environment and users as well. OK, so let's think about HPE Linux. Just throw us a middleman. What value does HPE Linux add to HPE? Well, when we were forming the HPE Linux team there were some questions from high up saying, you know, why do we need to have all these people working on Linux? Isn't Linux a solved problem? And you can just download it and put it on a CD and run it and, you know, that's it. But, yeah, so from the point of view of the users, Linux is a Linux distribution is basically a solved problem. Of course anyone who's actually been involved in putting together a distribution at the technical level actually knows that it's a lot of work. So I guess in some ways we're going to victims of our own success and that Debian being easy to use and working well makes it appear really easy when it's not... I mean, that's a valid question to ask too. I mean, if you're paying, if you're signing paychecks for all these people, it's a good idea. It's pretty important that, you know, what value you're getting here. And that's the big point of the section, you know, how can we tell people who are, you know, signing up paychecks what value we're providing by having a Linux distribution. So I've gone through a couple of points here that I think the value that HP Linux provides. It's a centralized point for communications. I mean, a lot of... I mean, people, engineers, England, within HP and elsewhere are pretty technical girls and girls and gals. But, you know, it's nice to have a centralized point where you can get documentation, mailing list stuff. You can talk about things internally. So HP Linux acts as a centralized point for communications. Okay, we bear risk in the company for technical and legal issues. So what do I mean by that? So if you've got 15... you've got 15 product groups, you know, which one of them is responsible for the scuzzy driver working, say? So everyone uses a scuzzy driver, but, you know, no one is actually responsible for it. You know, the product teams are responsible for the product. They're not responsible for making sure Linux works. So that's one of the points of value that HP Linux as a middleman provides. We own some of those common things, technical things. And on the legal side too, I mean, in a set of 15 products, you know, which one of those products is responsible for ensuring that they comply, the product complies with all the legal obligations that we have in terms of licensing and distribution. Well, again, everyone's responsible, but practically no one is. So HP Linux acts as a point to take that risk. And in a similar kind of vein, HP Linux allows to share large costs within the company. So there are some certifications that to sell into certain parts of the US government market, you need to have some particular security certifications, and I believe they're ludicrously expensive to do. And again, any particular product is probably not going to be interested in paying millions of dollars, whereas as HP Linux as a middleman, we can take that big cost and share it, sorry, take on that big cost and then share out the benefits of that amongst the other users of the system. We can also enforce standards. So if we want to say, if we want to make sure, if there's a dodgy C8 SSL certificate we want to get rid of, we can help ensure that all the products within the company have that particular certificate removed or that we're all using the same version or something. You can think of many reasons. You can think of many different standards you can enforce if you're a middleman between Linux and customers. And finally, this one's a bit abstract as well. Insulating users from having to make hard or unpopular decisions. So yeah, let's say you want to change unit systems in your distribution and how, who makes the decision to change to one system or another. It's whatever decision you make, people are going to be upset. And in the middleman less system, individual users might not want to make that decision because it's hard or it's unpopular, but HP Linux as a middleman can make that decision for everyone. And publicly everyone else can say oh we don't like this but we're forced to do it but secretly it's what they want it all. Anyway, that's an interesting idea as well I think. So what happens when you substitute Debian for HP Linux and what happens when you substitute your organization for HPE? How can you sell Debian inside your organization with this middleman analogy? I think it would be good to think about that. I think the middleman idea is a powerful way to communicate the cost and benefit of Debian within an organization because it's an analogy that people are familiar with. Middlemen are everywhere in society and by thinking about Debian the Linux distribution as a middleman I think you can help explain things to other people quite well. Finally, some ideas in this talk was taken from a book called The Middleman Economy by Marina Krakowski and it goes into a lot more detail here. She breaks middlemen down into six different categories which I put down there. If you're interested in reading about that it's quite a good book. There's lots of examples of this inside the book. Thank you everybody. Thank you, Tim. Sorry for the mess up with the slides again. Is there any questions? Hi. You mentioned that the HPE Linux port started with one internal customer or HPE affiliate and then later I think you mentioned it expanded to a couple of other customers. Were they external? No, they're all internal customers too. By distribution they're actually still internal. As I understand HPE is involved in supporting all the enterprise Linux in the market for their actual hardware buying customers. So what are the challenges do you face with supporting something like Debian for real world customers? Is there demand among your real world customers asking for something like Debian? A lot of universities use Debian on their machines. When they buy hardware from you do they really ask for support for something like Debian? Yeah, I think Bidal talked about this last year I think and the story was people want to know this support but they don't actually want to buy it. So I'm not sure what the solution to that is. So I figured out a long time ago that the right thing to do is to make sure that all of the fundamental software required to enable use of essentially any distribution of Linux on our hardware ought to be pushed upstream. And so we work very hard for a number of years to get all of the drivers required to work with all of our platforms into the kernel.org upstream space. And then we work with the different distributors to make sure that they picked up the right hardware enabling pieces and sort of using reasonable kernels to have our stuff that we need. And yeah, so we do go through formal certification processes with the various commercial enterprise-oriented distributions because there are a substantial number of our customers that demand one or another of those distributions and expect to be able to buy support contracts and all of that sort of thing. What we've observed is that what people generally care about is who are running community distributions is they want to know that it's going to work. They want to have some confidence that if it doesn't work that there's somebody they can talk to, but they generally are really interested in buying commercial support contracts. Or if they are, they want it to be very tuned to them in a consultative kind of way not a sort of shrink-wrapped one-size-fits-all expensive per-unit, per-incident or whatever sort of thing. So we have this sort of hybrid approach where we work very hard to get all of the driver stuff into the upstream repository so that you don't actually have to have any sort of special software to run. And then we actually do test a lot of these things, but we make different levels of assertion where if it's a commercial distribution we've actually run through sort of seriously rigorous testing and we've made specific support contract kinds of commitments around we'll describe that as being supported at this level. And then there's sort of a broad breadth of support for a community and non-commercial oriented distributions. Debian falls into that. We know that there are a lot of people in Debian on a lot of our hardware. We think that's great. Customers all think seem to think it's great. It seems to work great. But when you start using words like support in the context of a company like HPE, people who do support for a living have really crisp definitions of the difference between compatible and supported and tested and all of these sorts of things. And rather than trying to explain that to everybody, we just sort of shrugging up, and in almost every case everybody ends up sort of happy at the end of the day. Yeah, thanks, Peter. I think our customers are very sophisticated these days and very knowledgeable about Linux. Anyway, I think having a support, I mean people in some sense they do a lot of support themselves. I think Peter has commented about having a more consulting oriented support idea is probably what's going to happen. What was the question over there? Not the question. Is there any plan to like release this to the public? Can I like buy a server, a ProLiant server with this in the near future or something? Not that I know of. There are some still resolved issues in regard to whether we can externally distribute it even though it's just steady and there are still all kinds of legal issues and niceties and things that need to go through. We're ending the market. I don't think there is actually any reason why we cannot but we've got to go through the due diligence and marketing and legal stuff that approximately correct? No. Yes, ma'am, maybe. Any other questions or comments? You can just use Debbie and Jesse. So Tim said a couple of times what our goal really is is to have this be sort of lightly branded a subset of proper Debian as possible. So one of the things we're working very hard on is to try and minimize the delta between what's in Debian of the moment and what is actually being shipped in our branded subset. So he's not being facetious when he says the right answer if you want to take advantage of our work and hopefully in most cases just run Debian and you'll get most of the benefit. If you're actually running our systems, then what you may find is that if you're running one of the software solutions from the company that has an embedded Linux kernel on some user space you may, if you dig under the covers, discover that it's actually Debian but the internal technology standard was intended to address all of the places where we were embedding Linux into something that we sell to the customer where the customer isn't really buying Linux they're buying some application some solution, some appliance and if it's got a Linux kernel inside of it then we are trying to consolidate and standardize to minimize the cost of doing things like federal certifications and security updates and all that sort of stuff. We're not actually pushing this as a branded distro out in the world because we think if you need a full service distro out in the world then it works just great. This is really, you know, right now for the next period of time it's all about how do we consolidate all of the work that's going into various embedded uses of Linux inside of the company and there's been lots of discussion about how might that grower expand or be used differently over time and certainly some of the work that Tim and the others around have been doing to make sure we have all the right container enablement pieces and so forth but there's a huge big deal when you decide to actually enter the marketplace with a new distribution and we're not at all convinced that the world needs that right now. Okay, so any other questions? So I guess if there was sort of one main thing that frustrated you in the process and that maybe Debian could make it easier for yourselves or other people looking to do something similar then what would that be? I don't know it's probably around documentation on the Debian tool, so the tooling for doing the uploads and that kind of thing I mean I think there was a bit of teeth mashing and hair pulling over how it all worked but yeah I mean it's I guess it's difficult those tools to make them, to kind of publish them and make them generically available as a product as a separate package because they're just used it's a system that's used once it's used inside Debian I guess it's a bit harder to take that out and file off the Debian bit and stick some in all those versions yeah I've put off my head that's what I'd say Good question, thanks So any other questions? If not then let's Oh, there's one! I'm really pleased to hear that you and the people around you are pushing contributors towards being DMs and DDs as well because we hear an awful lot about HP's sponsorship in hardware terms and in money terms but in people terms it's fabulous as well I don't normally do this so I hope I'm not going to embarrass you but I think we should welcome our USW developer and may there be many more to come Thank you I guess that's a nice final point, do you want to say something more? No, thank you Thanks everyone