 Hello, okay So hopefully your morning has been going well so far. I'm happy to introduce the CTO of the Zen server product group James from Citrix who will be presenting transforming Zen server into a proper open source project. Please welcome James Thanks very much, and thank you for coming along Apologies for the late start. I think we've got a bit of a rolling delay today So I'll I'll try and breeze through this and make sure that we all got time to go get some coffee at the end of this So just by way of introduction just a little bit more about who I am and why I want to talk on Zen server I've been with the Zensource team Zensource is a startup that was acquired by Citrix doing Zen stuff since 2005 and currently I'm responsible for the technology strategy the architectural plans and so on within the Zen server team based in Cambridge over in the UK But over here a rather a lot these days So what I'm going to talk about today. I'm going to talk a bit about Zen servers history Particularly as it relates to open source We've all heard lots of good things today from Jim on the value of open source collaboration Zen servers had an interesting history in its origins as with an open source hypervisor Moving through a proprietary product to now being a fully or at least making its transition towards being a fully open source project So I'll talk a bit about some of the things we've done along the way Some of things we got wrong and some of the things we're going to do about it So some of the architectural and technical changes we're going to be making And a little bit about where we're going with the platform in the future so just to start off with Who in the room knows about Zen server? Put your hands up so a good good half of you So I'll go very quickly through a overview of what Zen server is just so that we got the terminology And understand the differences particularly between Zen and Zen server and that'll frame the the rest of the discussion So Zen to start with Zen is a hypervisor It's a Zen's what 11 years old now It started as an academic project in the University of Cambridge We can actually trace the project's origins right the way back to 1999 But then as we know it today Came into existence in 2002 Became an open source project at around that time The hypervisor is the low-level piece that runs on the bare metal. It virtualizes Compute so acts as a CPU scheduler and memory so it Allocates memory and provides in the fully virtualized case the extra layer of translation using Either shadow page tables or Intel or AMD's nested virtualization. It also pleases access to IO devices So allows higher-level functions to virtualize network IO storage IO and so on So in a Zen based system We've got a number of key pieces. We've got the The hypervisor itself over here sitting on the metal But one of the key things we have on top of this and a similar manner to KVM systems is we have a Linux environment Although Zen's not tied to Linux. It is the predominant Environment that we use on top is what we call the control domain or domain zero and this is where we run Everything that we don't put in the hypervisor itself. So that's where we run the IO virtualization So for example using Linux bridging to virtualize networking or the open virtual switch is another example Using LVM and or other techniques to virtualize storage and so on. It's also when you put the tool stack And obviously we've got a Linux kernel in there a Zen aware Paravirtualized Linux kernel. So when we talk about Zen The bits we tend to mean are the hypervisor itself down at the bottom And a low-level part of the tool stack for managing that hypervisor So that's the Zen project a collaborative project of the Linux foundation since April of this year and This is what we mean by Zen server So Zen is kind of the engine if you like the engine that powers the car on its own It's actually not that useful. You've got to put it with all these other pieces in order to do something useful So what Zen server does is it takes then and it packages it up to use as a system So it's effectively a distribution of Zen a Linux environment a kernel a tool stack Networking pieces storage pieces all the things you need to build a working virtualization system It's also made in some respects. This is perhaps a bad place to say this It's it's designed to hide its Linux internals to to some extent Then server originally as a commercial product was targeting Windows IT admins so we didn't want them to to be scared off by the fact there was This rather high power, but perhaps to them quite daunting operating system underneath So we packaged it all up. We shrink wrapped it as we like to say we put this 10 minutes to Zen or 10 to Zen Install a wrap around it So you could stick in a CD answer a few questions and then very soon have a working Zen system In fact, we are probably more limited by the the boot time of a modern server than by the the installation experience So we're having a lot of features on top So Zen does the basic virtualization Zen server takes that and puts a whole load of features high availability The authentications who integrates for example with with active directory There's there's also some LDAC capability in there. Although we don't tend to expose that at the moment So going back to our picture We've got our Zen hypervisor, but now we've put in quite a few other bits and pieces We've put in the Linux environment we're using in a true open source Then since you can use any environment you want. We've chosen one our users just want a system And then we put a I apologize for the location We put a Windows dot net UI on top and that's used to manage the system. So that's what Zen server is and Well, I've got the opportunity a quick plug We have the Zen project user summit on Wednesday here in co-located with the Linux con event Myself and Russ here will be talking a bit more on the differences between Zen Zen server It's tool stack. So hopefully today just giving you a little bit of an overview just to frame the rest of the discussion So bit of history So Zen server itself was really started back in 2006 a Zen source the startup predates that We had a couple ago a couple of other products didn't really work out So Zen server was an enterprise as we called it originally as what we ended up building So the timeline goes back to 2006. So let's let's start exploring Some of the history So where do we start with what we started with a very basic product single host product? it used a squash first minimal Domain zero Linux environment Read-only which to build your first product in a way that you can't modify at runtime. It's actually quite challenging But luckily back then we didn't have very many customers. So it wasn't too hard We then have on top of that the the low-level Zen libraries lives and control and Zendy Zendy was the original tool stack for the open source and project it's since been replaced and we'll talk a little bit about that later But the Citrix product or Zen source product. Sorry at the time. I was actually built on top of that So we had a proprietary C based agent that ran on top of that and then we had a proprietary Java UI That talked about and the whole glue everything that put that system together was not open source plenty of open source pieces Of course, but the way you put together wasn't So that was back in 2006. We had three releases of that product line We added support for Windows VMs in the second release And then we we put a bit of more storage supports and a bit more polish into our third release but then from there we moved on to looking at Building bigger systems. So these were all single host solutions. So then we looked to build a clustered Solution in parallel with shipping that first line of products to get our foot in the door with our customers We built the new generation and what we did. We actually got rid of The existing tool stack. We kept the same Zen underneath. We've moved on to a newer version by that point but fundamentally the same thing and We wrote a complete new tool stack in the O camel object oriented functional ish Language we're actually using in a fairly imperative style We are with Jane Street Bank. We're one of the largest commercial users of O camel and It has its challenges, but it has actually worked out quite well for us One of the things you'll note that we did was we actually push sendee the open the official open source tool stack off to the side and we actually interface to the lower level and That's still true today in all shipping Zen servers and that does introduce some challenges And I'll talk a little bit later on about why that's a problem. What we're gonna do about it We also put on again because we're targeting the windows market. We put on a net Ui on top Zen Center as it's called And again, that was proprietary originally the O camel's proprietary as well and again the way the system was put together Was again using plenty of open source pieces sent off five Point whatever I forget which one we started with right about five point seven now was our basis so from there Where do we go next? We moved on to in 2009 to Open source our O camel tool stack So we wanted to drive more adoption of Zen server within the emerging cloud Market so open stack was starting to ramp up. We wanted to Get some buy-in from the cloud community of the KVM as we know is very strong in the open stack world We want to make sure that Zen server which has been proven in many cloud environments We call Zen issues that Amazon as well That we removed some of the barriers to entry in that environment So one of the things we did was we open sourced the O camel tool stack that was the one up on GitHub in 2009 and we released a Thing that we call xcp To go with it. No xcp is a term that's become overloaded over the years It stands for the Zen cloud platform One of the things that it means is the the O camel project itself zappy is is the official name the the Zen API The other thing that it means is an ISO a seed a binary CD based distribution That is basically Zen server without some of the proprietary bits. So we took out The the things that we couldn't redistribute in that manner We had some some non free and open source packages from some hardware vendors You know the likes of emulax and so on for some of their CLIs So what we ended up with was basically a D branded Zen server Without proprietary bits that could be used as a container to run the open source O camel tool stack So that was 2009 So we continued doing that for a while We didn't expect to get a lot of contributions to the open source project We got one or two mostly from friends and family a few alumni of Zen source contributed, but that The intention wasn't to open it up and sit back and watch the code flow in There's I think I said to one of our senior managers at the time so in 2011 and into 2012 We had a project project Kronos Which was to get the O camel tool stack more widely used and again? We're really targeting the use within cloud environments So we wanted to be able to have people who are using say Debian or Ubuntu to be able to type apt to get install Zappy or apt get install XEP and be able to have a working Zen server like or XEP like environment so we took the now open source tool stack and We packaged it we work with the Debian and Ubuntu communities to get that packaged for Ubuntu 1204 and Debian 7 Now the challenge with this is that we did it in a divergent way Because we're also busy building the shrink wrapped Zen server product some of the changes that we made To be able to package for Debian Would divergent from what we've done with our big monolithic build that we have internally within Citrix Different from what we're doing for the centos based environment We didn't have an awful lot of respect for the fire file system hierarchy standard So there's quite a bit of cleaning up work. We did But because that was a divergent fork maintaining it is real a real challenge for us. It's a liability It's an extra cost and I know we've in the last few weeks We've had a few problems making sure that we can continue to have that package Within Debian as changes are made to Debian itself and obviously we're busy working on on the mainline code base Not the divergent one so That brings us right up to or the next step brings us right up to to date earlier on this year in June we released Citrix release and service 6.2 the most recent shipping version of the product And at the same time we announced that we would be making the remainder of Zen server open source And they're going to talk more today about what that really means obviously it was a press release at the time But we're going to dig in today a little bit more about what's actually happened under the hood So one of the things that's changed in the picture. We've been building up here. It's the open source the UI There's a bit more to it than just that And that's what we're going to look into a bit more detail on today so they we had a nice press release lots of lots of noise lots of Supporting statements from other vendors lots of tweeting and all of that But that eventually dies down a press release last week if you're very lucky So we're going to see now what what it really means to move to this new model So a few things What maybe we're trying to do are we trying to just stick the code up on the web and walk away We tried that with with the xcp thing a few years back. That's not what we're trying to achieve I'm not we're trying to do The next one. Is it just about PR is it just a marketing stunt? Well, my job is to make sure that it isn't so I really hope that's not what we're trying to achieve There was a great comment. I think on one of the the new stories That came from the press release someone said, oh great Citrix is getting the world to write its product for it. I Can tell you that's not what we're trying to do as we all know people that have different motivations for contributing to open source projects One of those isn't helping a company make money People do it for whatever reason best fits them often as we know It's so that it can enable one you know one company will contribute to a project because it can enable Something that they're selling whether it's their hardware and you know Intel contributing code to Zen so they can sell more chips Broadcon contributing drivers to the Linux kernel so that they can sell more network interface cards people don't write code Just so that we don't have to so we're not trying to do that despite what Some managers in many companies like to think so Are we the other end of the scale? Are we trying to create an Apache like? Community or a Linux foundation style community We did this actually in Citrix when we open sourced the remainder of the cloud stack code We actually made that that became a patchy cloud stack and Citrix then went to build the cloud platform product Based on top of that project So actually with Zen server. We're not trying to do that So all these things we're not trying to do what are we actually trying to do well Really like all good open source projects. We're trying to remove barriers to collaboration Zen server has a fairly rich API. We've got a good ecosystem of Partners building add-ons and so on for Zen server And having everything being truly open source just removes a lot of the barriers I mean one particular example From about a year ago We're working with a partner that wanted to contribute and in a small enhancement and performance improvement to our windows Paravirtualized drivers at the time they were Proprietary the closed source and it took six months just to get that company a read-only source license So they can investigate performance problem They'd see and we never even got as far as getting a contribution agreement set up Now those drivers are out there under a BSD license all of those problems have just gone away So it really does remove a lot of the the barriers to to collaboration with with partners So what else are we trying to do? Well, it's about communication. It's not all about the code Code is something like Zen server, which is effectively a specialized Linux distribution The code is actually a very small part of what we do. So even if we have a very Collaborative project with lots of people writing code There really is so much more to it and a lot of this is about communication So what are we going to do? When are we going to go to a 64-bit domain zero? And that's one of the questions that gets asked a lot When are we going to move to a kernel that's newer than 2632? When are we going to? Get support for a for Zen for three all of these sort of questions in a closed Environment even if we're using open-source components in a closed environment. These are actually quite difficult to answer within a publicly traded quarter-by-quarter Accounting company like Citrix. It's actually very difficult to make public statements about what you're doing with your product without incurring All sorts of problems of what we call revenue recognition So if you make a statement in one quarter about something you're shipping in another quarter You're getting some very difficult accounting problems about which quarter you attribute revenue from customers who've made decisions about product purchases and That really means that it's easier just to stay quiet about what you're doing and then only tell people once you've done it But when you've got an open source project We've obviously been able to do some communication via the github channel, but when it's truly open then you know the The the needs to be quiet about those larger things goes away The I don't want to make this into a Citrix product pitch That's not not the point of this talk But the way that Citrix makes money off of Zen server is by selling services support and maintenance on top So the the product itself is free All the features are available free So therefore we don't have any of those those barriers because we're not selling it So how could we possibly be making revenue affecting? Decisions or having causing revenue affecting decisions to be made By talking about what we're doing The other thing is we've got a very large user base You know as somebody who's who's paid by Citrix. I wish more of those users were paying customers but but the the fact we've got a large user base is actually incredibly good and a lot of people have got very good ideas and good Solutions to problems so actually creating a more of a user community around Zen server is in my view actually more important than creating a developer community around Zen server And we've already seen on the mailing list that we're now getting good people sorting out each other's problems We've had this for a little while on the the Zen the Zen API tool stack mailing list And when I extended that to the wider Zen server mailing list So actually having a community of users benefits everybody it benefits the users Themselves obviously if one user can help another user Then that's much higher bandwidth than if me and my team have to help everyone individually It also means that those suggestions the bug fixes the problems that have been pointed out Feedback into making Zen server better So creating more of a community around that really does does help the the overall platform So we made it open source the one of the things that was often said is Zen server is becoming open source, but actually 90 something percent of much he counted the lines is probably near in 1998 99% of Zen server is actually was already based on Open source code. So what's really changing? Well, this is a picture that I've been using to explain a bit about this the In this picture, we've got the colors aren't coming out too great on the projector unfortunately But the the darker color there the the three red blobs show the bits that were actually completely closed source We had a high availability demon We could have pools of up to 16 hosts in a cluster with with high availability to restart the ends and transfer the master function between hosts the windows Paravirtualized device drivers They were proprietary and I was then sent to UI but actually a pot from that most of the code is actually already based on on open source code either stuff we'd written or stuff we'd used elsewhere but a Lot of it was actually not developed in an open way. So of course we would comply with our with the GPL So we'd always ship source when we ship binary, but that's not that's not being open. That's that's just being legal So a lot of these components we would be we'd have large patch keys the games I mean things like we use a very old version of QM you so we would have a fairly large Patch queue against QM you but we wouldn't actually share that patch queue until we release the product And even then we quite often collapse down certainly the history on the repositories and quite often the patches themselves So really kind of doing the bare minimum to certain extent We we fairly heavily modify centOS 5 as well as our dom zero environment We've got a lot of updated packages We've patched packages before in newer versions and again, you know We'll ship the source RPMs and we ship the product But all of the development the thinking that goes into that kind of gets hidden so it's open source but not Not done in an open source manner So what we're moving towards After the change that we started a few months back is a position where everything is Open source, so we have a GPL or BSD or Apache or whatever is a most appropriate license And it will vary for example, we can't GPL the Windows drivers Because they get built with Microsoft headers, so we can't we can't try and you know end up GPL in Microsoft headers In fact, we're not allowed to get Microsoft's Logo certification with a GPL like license. They've actually got some very careful wording and error their agreement that excludes GPL based code the So those components are now all given open source licenses, but we're moving to getting we're not there yet We're moving to getting things like the patch cues on As open source projects on github or equivalent. We're looking to get The the build the way we construct the product open and a bit more about that to come But as I say the code is only actually a very small part of this So the bit that I think is more critical and the bit that we we've actually not made as much progress on as I'd like Is to actually get more open about the roadmap? we've got Things like where where are we going with the platform itself more than when are we adding features new storage features? one of the ones that I'm trying to get in at the moment is support the set Which is you know something that gives us an awful lot of flexibility in both cloud and non-cloud markets We think we can actually a lot of value in bringing set to To the enterprise as well. So when we're actually going to be putting that into the Platform, I think something we'd really like to be able to share The test harness we actually did put up a tar ball of our internal test harness nrt fairly recently That's the first stage of getting that open We're also looking to share that with the Zen project the Linux foundations Zen hypervisor project to enable the Scale of tests there to be ramped up. So that's a work in progress. What we haven't got yet is our bug tracker That's a Subject of a lot of debate how much we want to get out We don't have pollute we do an awful lot of automated testing within Citrix and we don't be polluting a Bug tracker with all the what I call incident reports When a test fails before anyone's actually looked at it to see if it was really a test failure Or was it an infrastructure issue or a test harness issue? You know the the signal-to-noise ratio can actually be quite poor So we want we're trying to create a Public bug tracker that really contains high value Reports that are generally believed to be true defects true bugs Rather than say your incidents are a test harness or support queries What we don't want is I tried to do X and X didn't work type bug reports So we're trying to make sure we get that right. So that hopefully will be coming out of the next month or so And the build I'll go into building a bit more detail in a few minutes time So we've got our portal then similar dog We put that up in in June We've now also got our access to Bell mailing list. That's been up for a couple of months We're starting to get a bit of traction on that Although it's a little bit quiet. I think we need to get more people inside of Citrix talking on that to kind of Act as a nucleus for further development. In fact, one of the things that I think is the biggest challenge in taking What was effectively a proprietary product or be it using open source components trying to get that to become an open source project is Getting people who every day every hour of their working lives They're used to having internal meetings. They used to pick you up the phone and calling another developer or wanting over to developers desk Meeting around the water cooler going down the pub for a beer All those discussions that tend to happen between two people working for the same company trying to get Communication going to the wider audience in a community project That's probably I would say the biggest challenge that we've got We've gone, you know, we've got a great office over in Cambridge a great working environment people love coming in there You know, we've got very you know good good value from having people co-located and to now tell people that They've got to start having their discussions via a mailing list when they sit next to the guy they want to talk to That's that's a challenge, but we're working on that Xcp I mentioned Xcp earlier and it's just a quick quick word on what we're doing with that just in case we've got any Xcp users here Xcp in effect it became a fork of Zen server without proprietary bits, but in reality the What we did was we just every now and again take Zen server rip out a few bits Including the branding stick an Xcp logo on it and stick that on the web. It's not very sophisticated And again, you know, that's a divergence that really isn't helpful so what we're going to be doing is Or what we have already done with Zen server becoming truly open source some of the reason for having a separate Deliverable it's kind of just gone away So by making sure that all the pieces in there are based on free or open source components Means we're really satisfying that remit of Xcp. So having two separate binaries having hot fixes delivered from Citrix for Zen server But not for Xcp and I know for many people in the Xcp community The fact that they'd have to use a various various tools such as GPG to unpack the The archives and manually installing RPMs. This is not ideal So hopefully we'll get to a point where there is one Zen server that fits the needs of both the commercial users of Zen server the users of the free Zen server We've got a very large number of those and Xcp users The other reason by the way for Xcp being popular is that unlike the free edition of Zen server It actually didn't have any constraints. The Zen server free edition actually skew-limited actually artificially prevented certain features from working unless you had a license from Citrix And it also required annual activation. You had to go to the Citrix website once a year get a free license key and apply that Xcp didn't have any of that So you could have all of the features set with none of the hassle and you know who wouldn't so those things You know basically converge now that everything is available for free use of the Zen server and there is now an upgrade path as well There are a couple of wrinkles in it. I understand that For the most part that that works So are we there yet is is the question well No, we're actually quite a long way away open source It's not it's not a project. It's not something you do and then you say you're done It's not something we stand up and say in exactly a sense of say right do open source do it by Friday It's a change to how we work and that means that we've got to change our culture. We've got to change our Technology our architecture in order to actually be Realistically usable as an open source project and something that people can really contribute to so So let's have a look what we got to so far. So we've got our proprietary components out there I think everything now that was previously not open source is now available somewhere Via Zen server.org as open source code Some of our patch cues are now public. So I think our Linux 26 I think we're on to we're moving to 310. I think that's still to come but we're partway through those The automated test harness is out there. It's just a tar ball at the moment We've got a bit more work to do on that but wanted to get something out there We've got our portal. We've got our mailing list But there's still an awful lot to do So there's a lot of technical discussion that needs to happen on the mailing list And I think as I said before this is really where the value is Being able to say this is what we want to do. We want to move to Linux 310 as our domain zero kernel I'd like to I'd like people to be able to discuss whether they see challenges with that You know, we're going to it because Greg's declared it to be a long-term Kernel, so it's going to be supported for a while and I believe we're not the only vendor to be thinking that way So, you know, I like to be able to talk more about the rationale for us doing these sort of things So we need to get more discussion going We need a wiki. We got a lot of stuff on an internal wiki. We've got stuff there that we can't share There's also commercially sensitive stuff on there as you'd imagine for any commercial product group But we want to get the the architectural stuff the design stuff out there. So I'm waiting for a for a media wiki. Hopefully to be set up fairly soon the roadmap That's something that we talk a lot about now But we haven't really got out there in a published manner if you go to the roadmap thing on Zen server.org now Don't expect to see much. It's it's not very content full There's a few more patch cues to go up there the release model so then Citrix will always be shipping a Citrix Zen server release And we expect a lot of people to be using that But we also want to make sure that we've got a release model for the project itself That may be a code level release like the Zen hypervisor does but we haven't defined that yet and The build system now the build system is something that I want to talk a little bit more about now There's a few challenges that we've got First we've got probably come to the build system just a quick note on tool stacks. I promised earlier I've mentioned a bit about that the As I said before we've got this tool stack where we built directly on a low-level library From the hypervisor project So on the left-hand side here, we've got the Zen server stack building on live xc lives and control on the right-hand side Is what does answer what the Zen product look like? Bring that up to date Then now is moved to live Excel and the Excel CLI on top But we still have that divergence So the change we're going to be making is to move or to port the zappy tool stack The Zen server tool stack on top of live Excel now. That's a stable API. I hope Ian good The the one below is not quite stable and every time we do a Zen upgrade in Zen server We hit some kind of problem when we went to Zen for one About 18 months ago It turned out something pretty critical had been moved from QMU to to live Excel Part of the setup for PCI pass through and it was only a small part of the overall solution But because we didn't spot it we took the the new QMU code But in our own parallel tool stack we missed that one and actually finding out what had gone wrong Through through testing and then ultimately chasing the problem down to find the one missing line of code We needed there's quite a painful exercise So moving to the building on top of rather replacing existing code works better for us We also want to make sure that we're Following good practice within the Zen project. So moving to the upstream QM use Important for us. So we're gonna be doing that very very soon We were on a very old version of QMU the original Zen fork of QMU and as the Zen project itself has moved to upstream and now is the Default in Zen 4 3 as n servers gonna follow suit and there's lots of value in doing that the Other thing that is really big for us is actually to be able to build the thing at the moment We've got this massive monolithic build server or build system. I should say within Citrix and It's great. It's repeatable for the most part It uses an awful lot of resource It's a big pile is the best way I can describe it of make files and associated stuff and It's doesn't really take advantage of the fact that everything is really easily packageable We are a Linux distro. Why not build like a Linux distro? so one of the things we're doing is part of the Open-sourcing initiative is to actually make it possible to build individual parts and then use standard tools to put it all together Into the end result and then use those internally to actually build the the Citrix product from so that the the goal is To truly recognize that Zen server is a base distribution sent off in our case We move to central 64 very soon and we have a set of packages on top and some configuration files And a wrap around the installer. So it's a distro some RPMs job done at the moment It's kind of a bit like that, but there's a lot of boundaries being blurred. There's a some big overlays So we just dump down a whole table full of files. In fact, most of the RPMs are installed at install time And we create a giant table called dom zero FS dot tar dot BZ to it's like 200 megs of Stuff that then just gets untarred So pretty messy thing to be to build. I mean the end result is good But there's no way realistically that anyone outside of Citrix is going to build that So we really want to get our packaging under control. So where we diverged from an upstream component We want to make sure first of all we're we're only doing that where we need to so we're not hacking Files into places where they really really shouldn't be So for example LVM we the ship the version of LVM we use user space tools in Zen server has actually got a significant number of or significant volume of patches applied It's only five in number, but they're each quite significant in what they do and this actually takes us into Sort of down code paths that perhaps weren't expected to be taken So the that presents us with a maintenance challenge So we need to get rid of some of that divergence. In fact, we've made good progress on that We also want to make sure that every single package can be built in a standard way So I want to get to the point where I can check out Zappy dot git or storage manager dot git and I can within a suitable environment type make make install and we're done And then package that up in an RPM or deb And at that point we're not having to do things differently for what a developer does day to day What we do for the commercial shipping Zen server product from Citrix what we do for getting packages into Debian and Ubuntu what we do for getting packages into CentOS So that's really it's about Make it easier for the user community that the integrator community the package a community as well as for the Developers which they're largely within Citrix The other thing we've been working on is actually getting these packages put together Into kind of a a distro on a distro if you like so a thing We've been talking a bit about on the mailing list recently and we'll be talking At the Zen developer summit which is in Edinburgh Next month about is a thing called Zen server core Which is really taking those core Zen server packages and making them available on top of your existing distro So today if I want if I got a Linux box, and I just want to do a bit of virtualization Excuse me virtualization on it Zen server is not actually ideal for that It installs on the bare metal it owns the box. It's an appliance model But it means that I can't just have my my dev box do some VMs Obviously with the KVM system Yum install app get install KVM you're there So what we're trying to do is answer is get to the point where you can apt-get install Zen server Yum install Zen server and you get all of what you need to have a Zen server like experience But on your Linux box Now obviously that's not what we're going to have for a shipping product because we want to be able to make guarantees About the the stability and performance and so on and if we've got a completely generic Linux system That's not something that that we can make those sort of promises about and we're not a Linux distribution at the end of the day We don't have a support and services organization like Red Hat and Canonical and Suze So we we don't want to get into the business of supporting a general purpose Linux environment But if you want that for doing your dev work, that's just great So what we covered today is Some of what we're doing with n-server the challenges that we've encountered some of the technical changes we're making and I think the you know the message that I want to to give you today is that Open source is not a thing you do. It's something that's that's you know, there's no one right way of doing it for us open source meant a certain thing it meant Collaboration it meant visibility it meant to use a community It doesn't for us. It doesn't mean wide development community. So the Treat this as a case study treat. This is some information about what we're doing with n-server If you are a Zen server user, you're an Xcp user. I do encourage you to check out what we're doing If like me, you've been a bit frustrated at the lack of progress on some of the things particularly around getting a wiki up there I share that but watch this space. So do come check out www.zen-server.org And we've got a couple of minutes left. So if there's any questions, I'll happily take those now So can you ask a question again? At the Zen server preview architecture, you have free catalog talk about open source Public development and non-public development. I'll give you a talk about what means non-public development at preview Okay, so let me just go back to that slide There's somewhere so this slide here you want me to okay, so what I meant by this is it's the difference between The code itself having an open source license and the manner in which we do the development So I mean, let's take as an example the Linux kernel. So we we have a Linux environment We we although we're based on centos. We do actually add a separate kernel ourselves and We have we start with Linux to 632. We actually take Suze's Seles 11 sp1 Zen patch It's actually a that's the centos environment. It's a Suze kernel But then we stick on probably about a hundred of our own patches. So it's all gpl So it's all open source, but the all the development is done within Citrix without anybody seeing it So what we're doing is we're we like a lot of companies that use Linux like, you know Linksys and so on who put Linux within their routers It's the the use of open source is is fine everyone complies or we should with the gpl but the the manner in which it's developed the The boundaries on the patches so which patch does which thing why what's the rationale for putting it in there? All of that stuff's done internally So when I say non-public development for the purple blobs here, what I mean is we're taking open source code We're doing stuff to it behind closed doors and then we're shipping the binary and a blob of source When we ship the product Whereas something like zappy we are doing our development largely in public We're using github pull requests and so on even for internal stuff so it's Although again, we're not getting a massive external contribution and neither we soliciting it We are at least doing the development in the open the conversations are being had the reviews The automated build checks and so on we've got a Jenkins thing that's that's driving some stuff through github all of that's being done Done in the open Okay, any any other questions? Okay. Thanks very much