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.  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


In June, we celebrate the birth of the Army and the birth of the Army in Europe. For 75 years, U.S. resoldiers have defended the freedoms of our allies and partners. From the Cold War through Desert Storm, the Balkans, Iraq and Afghanistan, U.S. resoldiers continue to stand together with Europe to deter threats to peace and security on the continent. Explore the history on the U.S. Army Europe webpage and share your part of the story by using the hashtag 75strong.


What's up everybody I'm TheMangoose, you are awesome and today I'm going to be talking about how these companies resurrecting Paragon are all independent developers, specifically how this is sometimes their reason why we should cut them some slack, but other times it's just an unacceptable excuse for poor performance.  They will be comparing it to all other games on the market and expecting equivalent performance. Do I think these companies can't compete with AAA studios? Yes, with the assets they have available combined with lessons learned from Paragon and a lower bar of success, they certainly can, but we still owe it to them and ourselves to hold them accountable when they veer off track. A good example of it's an indie company being a reason instead of an excuse is development times. I'm willing to wait patiently for these small volunteer teams to create their version of Paragon. They have neither the numbers or resources that a AAA studio has, it's going to take them longer to get things right even with the use of free assets. If they make a mistake forecasting a release date and have to go back to the drawing board, that's fine. This is their first go at making a game, mistakes will be made, not just with coding, but with marketing and planning. That's why it's crucial that they take all the time they need to present the community with the best possible product. Now an example of indie development being an excuse is when they do release that final product and it's riddled with easily identifiable bugs. I see many people saying things like, well such and such AAA studio also had problems with such and such game, but the poor performance of a AAA studio in no way excuses the poor performance of an indie developer. Only the end product matters.  If you put a game in the community's hands to play, what you have better work. Maybe it's not complete, but the features it does possess need to function. Game breaking bugs need to be discovered at the testing level, not the everyone is playing it and streaming it level.  All three Parazombie companies have done this. Predecessor's first alpha was dogshit because they didn't use gas and there was no client server prediction. They had announced their alpha for March of 2019 and squeaked it in at the end of the month, allowing anyone and everyone in the test to stream and record. The community flipped on a made of studios immediately. This was a case of them not taking their time and properly testing before presenting the product.  This time they had testing sessions where streaming and recording were not allowed before the public alpha and it paid off. Predecessor now is subjectively the smoothest and best feeling Paragon remake out there. We criticized them for their failure, they learned from it, and drastically improved. Fault's Early Access weekend was much the same and I would say even worse due to money being involved.  They did learn from Omata's previous alpha failure and did plenty of internal testing. The weekend long alpha tests were very successful, but then they missed their Early Access launch date, which I am completely fine with, and spent months adding in new features. They should have taken more time. The initial launch was far worse for me than any of the other previous alpha weekends. I don't know exactly what they did, but between their last alpha test and the launch of Early Access, something went wrong. The bugs that they had could have easily been identified through some proper closed testing leading up to the Early Access launch. Strange Matter has been steadily improving the quality of Fault, and they can hopefully recoup their losses. They also recently took steps to prevent 5 stacks from ruining the game which shows that they do listen to the community which is great, but that first weekend took a huge bite out of their potential player base.  Over Prime is really quite good now, but when they first let that one fly with only peer to peer access and the game being very arcade like and jam packed with weird bugs, it skewed the community's impression of the game. Most people look at Over Prime as a joke because they tried it once, probably couldn't even install it, and then they couldn't play it if they installed it, and if they did play it the game was crap. If Soul Leave would have held off when releasing Over Prime, tested it among a few members of the community, and then only allowed alpha access with the game in the state that it's in now, it probably would be a hit. Maybe it's a good thing that they're only just now looking to bring the game to steam, but if they do so without improving some of the bugs and animations it currently has, you best believe I will criticize them as if they were a AAA studio because at that point, they're putting Over Prime out there to be judged by all and against the work of every other type of studio out there. Being independent developers does work for all of them in one very crucial area, sustainability. Paragon wasn't losing money for Epic, it just wasn't making as much money as it needed for the project to be a feasible investment for a large company. While many people firmly blame Fortnite for killing Paragon, the future of the game was on shaky ground long before Fortnite Battle Royale. They brought in Donald Mustard with his experience at monetizing mobile games to increase profits, they made constant changes to the core of the game in a desperate bid to attract and retain new players, and none of it was working. Paragon was already on the chopping block, Fortnite just acted as the executioner. But these small indie developers are not multi-million dollar companies that need to show quarterly growth to impress investors. They don't need to maintain the numbers that Paragon did in order to succeed, they can take their time and focus on the players that they have. If it seems that I've been more cynical than I have been in the past, it's because I care about the success of these games.  It's not going to do anyone any good to praise these teams for their mistakes and excuse their failures. While I make sure to let people know in my videos that I still believe in what everyone is doing, I certainly will not be shy about criticizing anything that I feel will impact the growth of the game. Maybe it's not fair that their titles would be compared to the products of much larger and more experienced companies, but it's a reality that we all need to face. If you enjoyed this video, please hit that like button and subscribe. But for now, this is TheMangoo signing off. You guys, have a good one. MANGOO!


Yeah, we on boss talk one-on-one. So I really want to understand how you and Charleston met. I was going to get to that. We met at TYC. We was, we go. Oh, y'all met. We got everybody. So all that time, you're going through all of that. Yeah, that's how. You've known him from that long. Yeah, we were 15 when we met. You know what? This bringing up some good stuff for me right here. How did you get back in contact? Because you were gone a long time. When I came home, I saw Charleston at visit table. When he came to see his brother on beat-o. OK. But Charleston was already out here. We were still connected because my dudes, which is Monk Patrick Weather, that's who Charleston was hanging with everything before he went to the face. You think it's going way back. Yeah, that's why I'm telling you about this is not no, we just don't hang it. No, when I got out, Charleston came to my house and barbecue. I love it.  That is dope, man. So let me ask you a question. And because I got to get in the game related, not game related. But hold on, but he didn't tell us how long you were doing that for a long time. It was right over. So what I did was, at that time, I had a dog. How did you stop and not get caught? This is what I did. This is what I did. I came in, walked in there. I said, hey, boom. I gave it like seven thou now. I said, you got the game. You got a good trick. You know what to do. Me and I'm finished. She like, for real? I said, man, I'm through. I'm through. I said, I can't do it no more. Wow. You know what I'm saying? Putting your pimp stick down. I left, went to the high. And I just. Did you get a job?  So I was like, I was living off that. You know what I'm saying? What am I Charleston? What did he say? You wouldn't hang with him no more. Well, I used to still holler at Charleston because I had stopped going forward now because now I'm, you know, I'm through with that. You know what I'm saying? Charleston thought I was crazy. You know what I'm saying?  I said, man, I just, I just had a feeling, bro. I said, you didn't want to go back because you knew what's coming close to that.  And one day. Your mama was still alive at this time? Yeah, but mama still here. Still here now. Okay. So one day I had went to the room to get her. And I seen a lot of laws. That scared you?  I said, man. So they said, no, man, they doin' a prostitution pick up and they doin' this and doin' that. And didn't get her? Man, I'm like, oh, Lord. I said, oh, yeah, man, this. But then she never get got because she didn't do that. She wasn't. Out on the street. No. It was different. Yeah. She was a high class. She just had one, like, she had just one white guy that. Oh, that's it? One? I'm fine. She had, I mean, when she goes to the club, she gon' get her money. But I'm sayin', this one white guy gon' make sure that she need nothin'. She'll go to Florida. She'll go to wherever with him. What year was this? Man, that was in 2013. 2013. Like, 2012, 2013. Then I stopped. That was a black girl. She was, yeah, she was mixed. She was mixed.


I believe and it was all organized by you Lou so thank you you Lou and we look forward to your talk on the attraction between anti-firm magnetic quantum vortices as the origin of superconductivity and whole-doped coop rates. Okay, okay good morning everybody it's a really great pressure for me to come back and I appreciate very much that the organizers invited me to come back especially because of the celebration of 60th birthday of my long-time collaborator in organizing ICP activities and I want to say happy birthday to you peers and I think probably different people can different things so what I would do is I will spend five minutes to remind you a little bit of the high TC related activities at ICTP. I think many of you maybe not so many that may remember the Woodcock meeting, APS meeting in 1987. That was a very important event in the physics community. In fact within three months of that Woodcock meeting we had another ICTP Woodcock meeting and it was called a Geological Research Conference on High-T Temporal Superconductivity and of course there are several features of this conference. One thing is it attracted many many leading players of the field as a time including Alex Mueller, Paul Chu, Professor Tanaka, Professor Zhao Zhongxian, Bob Schrieffer, Doc Scalabino and most importantly that in the audience there were members of the Nobel physics community. In fact they were responsible for deciding to give the Nobel Prize award in 1987 just like after the publication of the paper. The other feature is that there was a big delegation from former Soviet Union. Officially there were 15 actually there were more including Vitaly Ginsberg, Alexei Yablikosov, Lev Galkov, Egor Lushinsky and many many others. In fact some of the people in the audience are the part of this delegation. That was before the fall of the Berlin War but it was already closed so it's some kind of just opening. Starting from that point the ICTP became a place of these concentrated activities on high TC related activities and the strongly correlated system. The first workshop extended workshops was in 1988. There were three annual workshops I mean in 1989, 1990 and 1991. It was organized by Baskarang Ruckenstein, Pierce Coleman's colleague and the Electoral Society and myself. And I should say that from 92 hours Pierce Coleman became the driving force of this series of the mini workshop on the strongly correlated electronic systems. I think the Phoenix community appreciates very very much your efforts. To me I think there are two features very important. One is to really attract the most active players in the game. In a sense ICTP Adriatic became a kind of focal point of high TC related activities. In fact at that time people realized that there was a urgent need to form the scientific research community on high TC and strongly correlated systems. And that community has been formed and it is really remains active for long many years. The second feature I want to mention that Pierce really emphasized a lot the pedagogical aspects of the series of activities to attract young people especially young people from developing countries. He put a lot of personal efforts to help to cultivate scientists from developing countries. And that is at the beginning the mini workshop was every year and every two years or more recently every three years. But just you close your eyes think it of it. Which kind of series of activity can last more than 30 years and always thriving. So thank you Pierce. Okay now I come back to something I want to discuss the physics. Of course you know that the high T really is part of more than 30 years efforts from theoretician the experimentalist. There are a lot of progress but there's still no consensus yet. And of course if you really ask me how many possible proposals of high TC theory or whatever I mean it's very difficult to count. So the story I'm going to tell you today is one of those and of course to get consensus is not so easy. Of course the challenges are very clear and the first is the anomalous normal state properties and the second of question is what the origin of pairing is not so clear. And then finally this is superconducting state. For a long time people thought that the superconducting state probably is more or less standard business type. But I want to tell you today that these superconducting properties are not normal and they are some specific features which are not has not been fully understood. So I don't need in this audience to really explain this phase diagram. So the story I'm going to tell you was a kind of long-term effort together with Pierre Alberto Marchetti from Padua and my long-term collaborator Su Zhaobing. And this collaboration started in 1993. When Professor Marchetti visited China first time. There are many two points. One is to really study anomalous normal state properties and the metal insulator crossover in the sugar-garde phase and the linear temperature dependence of resistivity in strange matter phase. And the second point we want to emphasize is the non-business superconductivity driven by attraction between opposite chirality spin vertices. So this is a story I want to tell you today. So this is the plan of the talk. So of course many people I wouldn't say everybody agrees that antiform fluctuation are probably the origin of superconductivity. So antiform is a really key ingredient for cooperates at least. Of course this is a natural pairing goal would be really spin fluctuating, spin waves. But if this is true, the action should be really enhanced by details of a family survey such as nesting. But as evidence it's not so clear. So what we propose as a pairing goal is another excitation also emerging from antiferromagnetism but of purely quantum origin. We called antiferromagnetic vortices. I will explain to you what we mean by antiferromagnetic vortices. So if the in antiferromagnets the spin group SU2 is broken to U1. So the quotient group SU2 over U1 is orthomorphic to S2. So it really labels direction of spins so their fluctuations are described by spin waves. So this is known to everybody. But the unbroken U1 describes an unphysical gate fluctuation. But in two dimensions one can consider vortices of a Harunov bomb type in this U1 due to antiferromagnetism. They have opposite chirality in two nail sublattices. These are really subjects we focus on. So this pairing is a due to vortex attraction. If we lower the temperature then the gas of vortices in two dimensions undergoes a causally solace like transition with the formation of a finite density of vortex pairs of opposite chirality. If vortices are centered on charges it induces a new form of charge pairing still due to antiferromagnetism. But it's different from the spin fluctuation pairing. This is different. I want to say this is not so new. Actually in the early days in the 80s similar ideas not in this explicit formulation were noted by two group of people. One is throughout the Trogman fragment you may remember that he published a very short paper where they say if two holes are sitting next to each other in the lesson then you can gain one chair. So you are winning energy. Later on in the early 90s Shryman and Shryman and the Sijia they've really studied a single hole motion of the single hole in an antiferromagnet. In the last paper of that series then explicitly mentioned the attraction due to vortex interaction due to vortex but they did not expel out its explicit. So this is a general physical idea. Now I want to just briefly outline the formula. Of course the model we are using is a single occupancy Tj model and this is the standard I don't need to explain. Of course the strong coupling approach is really to emphasize the notable occupancy constraint and we can formulate in another way using these spin charge separation slave particles. Of course different options and the option we are using is a kind of slave fermion approach and this concern is really guaranteed by poly principle. So let me just very briefly simply just what is the origin of this antiferromagnetic vortices. Physically of course this is quantum distortion due to hole in the antiferromagnetic. Mathematically in two-dimension there are many many possibilities to materialize this the charge spin charge decomposition decomposition. So what we are going to use is to use the U1 gauge to really describe the U1 charge of the degree freedom and use the SU2 to describe the spin degrees of freedom. And this is a kind of sorry a compensation of the statistics. So one is the charge flux, another is the spin flux. So one may ask a question why U1 cross L2? You guys I mean so complicated. So the reason why we came to this one is in 93 we were working on one-dimensional Tj model. It turned out that for the one-dimensional Tj model I mean using this U1 cross SU2 theory we could really recover the critical exponents either calculated by conformal theory or by the exact numerical solutions of this finite lattice. And it turned out that the hole in a one-dimensional Tj model is decomposed into hole-long and spin-long plus attached string, attached strings. Let me just explain a little bit more this one-dimensional Tj model.  So this is a string of spin flips compared with the original background and up to the hollows.  Hence the spin-long is a same L just in between boson and fermion. But this is easier to understand but the strange thing is that the chart of the hollow is also attached a charged string. So from the point of offer statistics it's very important if the spin-long is a semi-all and necessary that the hollow should be also a semi-all. So it has an additional effect to modify the whole then occupation statistics of the hollows. We know that usually I mean if it's a spin-less fermion we have the occupation is one. It's one. And actually because of this specific feature for which I will not elaborate it turns out that the whole statistics is one-half also in one dimension. So that is it makes this one dimension the hollows obeying the same statistics as if it were the spin-one-half for fermion. So this same I mean fermion points. So the question is how to go from 1D to 2D? This is a no trivial part, no trivial part. So naively from one dimension to 2D this doping really disturbs anti-formal background. So some kind of string confining hollow and spin-long appeal. It turns out it's not just a really confining string. And we notice that this decomposition is invariant and they get U1 gauge transformation. So this U emergent local U1 slave particle the local symmetry gives rise to this gauge field a mu and this is very important. However we cannot just just generalize simple straightforwardly the one dimensional experience to two-dimension things because in one dimension the topological defects are kings. While in two-dimension the candidate will be really the vortices. And it is natural to really look for the vortices in two dimensional TG model. So the hollow and the spin-one in two-dimension it's we really attach using the TG model theory attach a spin flux and a charge flux. A spin flux to spin-one and the charge flux to hollow to hollow. And eventually because of this statistic compensation of course the resulting statistic should be still philharmonic. And this vortices can be introduced by a coupling to the U1 cross A2 transformant theory which do not modify dynamics. And then this is a kind of exact rewriting. There should be no problem. So this is an exact but we cannot do many things exact. So we have to make a mean field approximation. So the way to make the mean field approximation really including the main idea of these things. For this U1 sector it is more straightforward and the mean field configuration is a pi flux phase which is well known. For the ACU2 sector we eventually really neglect this spin-one fluctuations. And now how can we do in the mean field approximation? We ignore this ACU2 fluctuation but we keep this U1 fluctuation in a very special way. So this U1 vortices is complementary to the S2 of the spin direction. It's like the aroma of bomb effect. And these are the chiral vortices advocated at the beginning. Of course it does not modify the anti-firm background because it costs much less energy than strings. But these gate fields do not confine it but binding at low energies. So in this gate field approach a hole is a composite particle. It's a self-generated emerging U1 gate field couples hole-ones with spin-ones. It turns out that many important physical properties are determined by this composite structure of this hole-one. Now let me describe the interaction of these vortices. The vortices is really combined this U1 gauge fluctuation with the hole-one. It's located at the hole-one position. And it gives rise to the change of anti-firm and long-range order to the short-range anti-farmatic order. I skip the mathematics details and the interaction term is really in terms of the spin-ones. And if we average over the spin vortices and it turns out that the spin-one becomes massive. It's like a localization. In a sense it's localization. Like in the line localization, in the disorder media and eventually you would just find a gap. And it's the same. The gapless anti-firmatic spin waves in the presence of this slowly moving vortices, it becomes a short range and the spin-one gains a mass. And this one actually was confirmed very early in the 80s from the ITC experiment. There's a short-range anti-farmatic order and the manganone is a bond state of the spin-one and the anti-spin-one. Now I want to go directly to the three-step scenario of the superconducting transition. What I mean by three-step, the same J term which gives rise to the finite mass of spin excitations also gives rise to attraction between vortices, between vortices. In the previous case, the average was over the vortices. And in this case, we really average over spin-one. And then we get a kind of effective interaction for hollows. And the effective hollow interaction was really induced by this hollow attraction. And it turned out that this two-dimensional coulomb attraction between vortices centered on hollows on different neosobalates use hollow pairing. I mean, if you just recall now, this is rather similar to the idea of Trugman and also Sherman and Siegel. But this is one much. So in the three-step, step one is a really causally soulless transition to form this incoherent hollow pairs due to this KT interaction of vortices. This gap equation for hollow is a business type. And it turned out to be, I mean, of D-wave symmetry because of the anti-thermal attraction is strong in horizontal and vertical interaction. So it is D-wave symmetry. But the hollow pairing alone is not enough to have real hollow pairs of hollows. So if you look at the spin-ones, I mean, for those who have been playing with the Trugman model understand in this boson, the slip-familion representation, this attraction of spin-ones in this term is repulsive. So that cannot really help to give a spin-on to play. And this is a more indirect and induced effective attraction overcomes the origin. And this is induced by the gauge field. The scenario here is very similar to the Lawton formation in superfluid helium. I will not go into the details. And this is still not enough because you can have incoherent hollow pairs and incoherent spin-on pairs. But then, of course, you need the condensation of these pairs to really give rise to superconductivity. And it turns out that the TC is really induced by the condensation of these incoherent hollow pairs. And here you go to original anti-ferromagnetic vortices, spin vortices to rear anti-ferromagnetic vortices. And it turns out that this transition isomorphic to the three-dimensional gauge XY model. And that is really give rise to the final result. Now I want to just emphasize that in this scenario, something is universal, something is universal because at the TC the gauge field is kept because of Anderson-Hicks mechanism. So this superconnection transition is of the classical XY type. The TC scale is set by the spin-on pair condensation with gain in kinetic energy. So in a sense, TC is insensitive to the Fermi surface details. So you can have a kind of universal phase diagram. So let me say this very quickly. So there are several features which really distinguish this transition from the standard BCS. In standard BCS, this exponent for superfluid density is alpha, so one-half. But if you look at this experimental data more carefully, the exponent is two-thirds, as predicted by the three-dimensional gauge XY model. And also the Wimura relation can be derived explicitly. The second thing is we can just derive from a given specified model the main features of the phase diagram. So there are four different temperatures. One is the so-called high field gap. It's really the hollow pairing temperature. Another one is the so-called lower field gap, which actually is the boundary between the field gap and the strange metal phase. Then there's a length phase. The length phase is really the pairing temperature for spin-ons. Eventually, there's a superconnection transition. So the pairing temperature for spin-ons and the lower field gap temperature T star, they are really more universal. But the other two depend a little bit on thermosurface details, but not precisely. And using this model, we can really calculate the spectral weight in the strange metal phase. And it is agreed with the ARPIS data quite well. And we can also calculate the parallel implant resistivity and find this metal insulator crossover and find this inflection point, which is nothing but the T star. And this agrees very well with the recent experiment. And this is the pairing temperature for spin-ons. It really agrees quite well with the own experiment on this lens. So just to summarize, if we combine the composite nature of John Ryan singlet and induce anti-pharmatic spin vortices centered on them, we get a three-step scenario for superconductivity, capturing many features of the cupra's phase diagram. The attraction of vortices on opposite near-sublatives give rise to a finite density of the hormone pairs. And the hormone spin-on gauge interaction give rise to finite density of RVB spin-on pairs. And eventually, condensation of the whole pairs give rise to superconductivity. Thank you very much.