 with another cloud talk, this time on the official Debian image status. Take it away, Jimmy. Hello. So official Debian image status is a sort of interesting concept. So far Debian has, you know, Debian is a universal operating system. We have it on our website and our slide banners right next to the screen. We've historically shipped images for CDs, for USB, for live images, et cetera, embedded devices, but we haven't shipped until recently images for public cloud kind of environment. And I say public cloud because when you're doing private cloud, it's for use internally and the technologies are often the same but customizations for internal use are common and they're really separate from the notion of what's official Debian from Debian's perspective as a project because when you do something as Debian, when you offer something as official Debian and offer it to a third party, that's when it's actually relevant to what you're calling it. So that's why the public cloud environment is relevant. It's a very unusual environment. There's a weird background thing below the cloud and it has to integrate well. Luka Nusbaum, the Debian project leader, said in a discussion in April on the Debian cloud list, now official Debian image, I don't think that for public clouds he referred to a different cloud. Official has been explicitly defined and it's true. We should define it. It's a bug. You know, this is something we should have an answer to. So that's what I'm trying to figure out as a conversation to start with you all. So what does official mean? Okay, it's an adjective. Great. But what does Debian need here from the notion of an official Debian image or from the reality? And what do the public clouds need here on the vendor side, for example, whether that's a large company like Amazon or Google or whether it's a small one like GPL host, for example. The needs are more similar than you think but they're not the same. So we should discuss the differences and similarities and sort of bridge the gap. I'm just trying to go through the slides quickly but not too quickly so that you can follow my voice. But then we should discuss. It's a buff. So we also need to figure out how Debian works with the cloud vendors and it's a reciprocal collaborative relationship and then we have a lot of time to talk and hopefully we'll come up with some criteria. But it's one 45 minute session so really we'll just make some progress toward it or start the conversation. So one of the things that makes Debian Debian is of course our social contract and anything that is officially Debian should respect our social contract, comply with the free software guidelines and focus on users' needs. Those are the two core principles of Debian. We should stick with that. Anyone who uses something that's officially Debian should be able to rely on their trust of Debian to trust the image. They should be able to anchor their trust in Debian that extends to packages and repositories, to image builds and how to discover the images, at least one way of discovering the images. They should be able to find them through Debian. They should get Debian security fixes, updates from Debian. They should be able to rely on Debian as a source. Again, things that are officially Debian are done within the Debian community. The build tools are discussed on Debian cloud. There's Debian mailing list, IRC, and where the code should live is a little bit more complicated. Some things are happening on GitHub these days. Some things are Debian.net, which is sort of official. Some things are happening in various different contexts, but we should pay attention to these issues in any case. Debian needs to be able to support the images. Users have issues. They come to Debian via whatever mechanism they want to contact us. We need to be able to help them. Quality assurance and testing are especially noteworthy because we don't have a good solution for this now in cloud images. For typical desktop or server install, we test this a lot in our normal release engineering framework and we test upgrades, we test packages, we test the whole system. But for the cloud images, there's no really good way to test that we have yet and we need to solve it. Right now, we just do a couple of manual tests and for the Google images, we have some incomplete but useful internal tests to run, et cetera. But Debian should have an answer to this. It would be a good thing. So everything I just said applies equally from the perspective of the cloud vendors. They need to pay attention to licensing and in their case, legality more than specifically freedom, but it needs to meet all the needs. And users come to them with concerns, especially not paying customers, but really every source feedback. Users often trust Google or Amazon or whoever is providing it to them GPL and they need to be able to rely on that trust to trust an OS that they are being provided. The vendors and the operating system folks have their ways of development and they need to work well together or use one set of tools to develop solo products or however the relationship is going to work in that case. And they also need to support. They offer support contracts, people use their forums. They need to make sure that their reputation will be upheld by the quality of the product, et cetera. But wait, there's more. There's other requirements in the cloud context. So some of the unique concerns, a lot of them revolve around a motorcycle, but others revolve around the fact that clouds release faster than the two year release cycle of, you know, slow moving conservative enterprises like Debian. They need some speed to handle things like performance and security fixes. So I have some examples here, but the general category is, you know, customers internal or external paying customers notice a problem and they, you know, complain to the vendor, the team, whatever the right category is and getting an upstream fix is something to work on and it takes time, but sometimes something needs to be done quickly to satisfy business needs. So some examples that we've experienced at Google. When we switched to Debian as a default from a previous default distribution, we, there was a performance regression in networking for about 20%. That's a significant regression. And the kernel was the same. Right now, we're not using the Debian kernel. That's a temporary thing. We're going to fix that. But it's important. And I think so far that the approach that we've taken is how they're being able to start in the Amazon. That's something that I'm hoping that the very active people here actually thought up that and say, what should be good? Tomorrow morning, not officially, we've got a couple of clouds in front of us, but not just what we consider is official, but the additional tool will be like that. And I was going to say, it's good for tomorrow. I think we're going to be able to do base images as totally base images. Everything from main, nothing from anywhere else, or whether we're going to be able to fix some things that we need for each other. Now, I think that's something that's really quite a thing. The last thing I'm going to do is cloud it is now packaged, but it's not in the main output in backwards. We've discussed on the cloud list whether or not we should request it to pull that into main, the point that's coming up, or we're going to start to get some of that. Sorry. There are two is that it's not what it is normally, the event of all that, that they come in from testing the first layer, and the discussion is stopped there, but maybe you can ask again, what would you say? And we have a large number of users, and I'm talking to the third-hand users, who are meeting us now, who are having to wait. And we cook these things. And again, it's going to be a little bit of a policy whether or not we could put that into backwards and into base images, and then a conversation that involves around security updates, people can do that. So there's a lot of questions in here. So I'm going to sort of think of what you can say. It also gets more complicated when it's both clouded and it's open cloud tools and user tools and you know, we're all trying to move towards that main and do the right thing. The important thing from the customer perspective is that they have a way to have an application that from both the application and the cloud application and the application will combine in a way that makes everyone happy. I would like to see not only the things that are in the image to be in Debian Main. I would like also to have all the tools to create the image to be in Debian Main. Agreed. Therefore, I'm not... the idea to use a certain cloud provider and you got tools to use that cloud provider to create the image. I don't like it. Well, I think all of these tools are going to main. I would prefer that we use only tools that are on main and that we can build the image only in Debian and not using a cloud provider to do it. So you could tools is in main actually. Everyone wants that in main. However, obviously, one of the problems we've got is the version of you could tools that we have in main is from what year? It depends on that. I'd say 2010 or 11 and the rate of innovation that's going on with all of the cloud providers is that sometimes the API calls that you could tools is doing from 2011, which is in stable now, is just too out of date. I previously had a mention of API lifecycle in the issue across all the clouds. Yes. The question also could be why do you use you could tools at all? You don't need to do that. You can just create your image in a CH route and it just works. That's what I did with my script. The Google Compute Engine images don't actually use you could tools, which I guess makes sense because it's a different infrastructure, but the basic problem of fast changing APIs and the ways of interacting with the cloud and the feature sets and customer expectations, they all change faster than it to your life cycle. So why interacting with the cloud when you build your image at all? I didn't hear that. Why would you interact with the cloud as they began to just do the upload? That's a different problem. I could could you let him respond? Yeah. Yes. So you can build it outside of the cloud and maybe I don't know if you can really validate it. Some of the cloud and with any cloud, you need to validate it before you publish it. So either way, the workflow of Debian needs to interact with the cloud, but good validating and building the images to different processes that could be separated, right? But even then past that, the contents of the image, customers really expect that to not work with the version of the product that existed two or three years ago or a year ago, but the version of the product that exists now. So all the tools, I assume Amazon sticks tools into the, you don't stick tools in the images, but Google sticks tools into images for customers to integrate. So when they bring up the Debian operating system, they can interact with all the other products inside of Google. And one of the simple things you might want to interact with the cloud environment with is, hey, I've got three extra volumes mounted. I want to snapshot them. So that's that's an API call. I should just make one. Obviously within your block device, if you've got something like LVM or you could do that. Yeah, but why does it has something to do with building an official Debian cloud image? Can I? That's the topic. This image, this sub discussion is also overlapping very much with the packaging above tomorrow morning. So I think we should have this discussion, but this, we should probably save it for part of tomorrow morning aspects of, of what my slides and the general concepts need to discuss. Yeah. So one comment about the versions in main of the tools that you are using to build images. It's not like the official other Debian thing we have, like the proper CD release are made using software, which is entirely even packaged in the archive. So I think it's great to set high standards, but I don't think that before being able to call something official, we need to, to be able to build it only with stuff which is in the current main, which would mean essentially being always one release behind in the build dependencies of the image with back to the content of the, it might be reasonable to allow stuff from unstable because we even do DI with different mixing versions, you know, yeah. That even if there is an absolutely unsurmountable problem, we will not have official images that cannot be built entirely using free software, which means not using Amazon and they are not part of, it means, it means not, it means that you have to have a way to build the image without using those. And by the way, neither of our images, neither Amazon nor requires you to use the proprietary cloud to build the image. You can build an Amazon image in Eucalyptus, you can build a Google Compute Engine image on your workstation. It works. So I think there are two different issues that will be mixed in the discussion. Yes, thank you. One is how do we build, I think that for that we need to be as close as possible to usual Debian practices. Yes. And ideally that means having a tool to package in Debian, unstable for now is fine, on iOS and not on GitHub, for example, so that it's easy for existing ids to join the team, etc. Well, everything, do it as we do in Debian usually. Then there's a question of the content of those images. And if it's an official Debian image, I think that it needs to be as close as possible, as realistically possible to what we ship on CD, what you get when you install Debian using a CD or something else. And I understand your point about customers wanting different kind of versions of whatever. But if it's not what we ship in Debian, then, well, we have to stick with what we ship in Debian if it's an official Debian image. Sure. If you have more than two or three packages that differ from the standard Debian installation, or that if you have configuration differences, then it's not longer official Debian. However, at the same time, what we ship in Debian is already death-intensive. What we ship on an ARM machine is different than what we ship on an X86 machine, including the bootloader, for example. There are support tools that might be included on a default S390 installation that are different. And so while I think it should be officially Debian in some way, it's not obvious that in 2013 or 14 or 15, whenever we have the solution, it's not obvious that CD fixed offline distribution needs to be the reference point. It's a topic of discussion, right? I'm not saying I am forcing an answer here. It's like James said in his talk, it's a matter of Debian evolving its consensus. But whatever it does has to be something that Debian is okay calling official, but the nature of what the reference is can be more situational sometimes. I think I'd like to echo what Jimmy said. I think you would even agree that the cloud really is another architecture, right? It's just different, fundamentally from the typical way that Debian has been installed and published before. And I think maybe one of the things that is really necessary is not just to think about what Debian official is. Maybe there is a Debian official, right? Maybe there is just the pure free software version that only works on some clouds that have the right tools and so forth. You know what I'm saying? All their software happens to be open source and all their APIs you can build everything outside of the world, outside of their world, right? But sometimes, I mean, I don't think Google's is like this and I don't think Amazon's like this, but I can easily see other clouds needing more proprietary tools. I don't think that's something that we don't have. In that sort of circumstance, I would still like to see Debian having some sort of branding, which is there's the Debian official, but then there's the Debian inspired or the Debian cloud edition. Yeah, something like that. Yeah. I mean, that Debian cloud edition becomes world. Do we include things like SDKs and things like that? Or do we just say, well, the SDKs, if they're already in main, because obviously we are all publishing our SDKs as a DSFG compatible licenses. So let me take a step back from what's in the image. The customer expectations don't care what's in the image. The customer expectations care what's easy for them to do. That's all they care about. It is possible the reason it's useful to have in packages in repositories in the image is because app lets you update things and lets you see what's installed and remove and add things. So the important thing, if there's a way to avoid putting certain things in the image and have it be easy for customers to use things in ways that meet customer, the needs of people who are paying Google or Amazon money or people who are paying GPL host money or what have you, having a way to meet customer needs is the goal. It doesn't matter so much what's the image. Yeah, I'd like to, we still have a look to what happened in Ubuntu. In Ubuntu they have a cloud image that works in most clouds. Okay, they made technical choices so that it can happen. Cloud init is an initiative from Canonical to do that and if, instead of adding specific HP tools or Google tool or whatever to the image, if we could just contribute to cloud init so that it would, we would continue to have a unified system and try to do it that way for all the other components then maybe we have a chance to have one unique cloud image that will work for all. It's always good to improve standards and as I say in this slide, it's a start. I think I'm happy for that but there's definitely things that cloud init that it's out of scope because cloud init from what I understand it's even an initialization time thing. You know, it doesn't handle, I mean maybe with upstart or system d it can handle network changes but for example any system 5 init based system or anything where the needs, like I don't think even upstart can handle account management during the lifetime of a VM you know just as an example. So it might be possible to change the scope of cloud init or whatever but like it certainly won't handle the QA and testing workflow right? I mean we need, the problem is broader. Do you think we're getting a little too granular here? I mean things like puppet and chef and juju take over where that leaves off. Do we really need that to be a part of any official build as far as debits concerned anyway? The whole point of debit is that it's universal. Right. Puppet and chef take, you know, puppet and chef meet the customer specific needs as managed by the customer. I would say lots of customers will be installing puppet or chef or juju on Debian and that's great but I don't think, I think for that very reason actually we shouldn't interfere with whatever they do for their puppet or chef's install. So I don't think we're stepping on, we shouldn't step on them, we shouldn't interfere with them but the, I mean if there's some other easy way for them to you know interact with whatever their vendor environment is in a nice way. I agree that we should only ship free software, I'm fine with that. But you know, aside from the licensing side of things, you know, the important thing is to provide some way and I don't think it should be puppet or chef simply because the customers will often use that and they should control that. I'm sorry, I'm going back to the content of the image. Yeah. The discussion of what should be in an image and an official image, I mean this, the answer to what is an official image exists already. An official image is just free software. There are some CD image made by Debian with non-free framework. It's produced by Debian, it's not the official image. Right. And if some package needs to be added to the in Debian for specific clouds, I think it's not a problem. We have had H and a half which included more updated software to add support and it was during a stable release. Sure. Well, so as far as you know, as far as unofficial images that are all free software, Amazon and Google already ship those, both of our images contain only free software, they are built with only free software and they, you know, they are close enough to Debian that we've checked with the trademarks folks with Debian, it's fine to call it Debian, etc. But they are not official Debian which is a bug as I've said. So there's no issue of like the non-free firmware CD images because we're not shipping non-free software, it's all free software. Everything Google's released to this is Apache licensed. Yes, but in the same way everything, an official image can only be made with stuff in Debian and that's easy to achieve. So, yeah. The real problem here is the time frames, right? I think it, at least from my perspective. Why? So when, when, What kind of problem? So when Google creates new software to stick inside of their VMs, new bug fixes, new features, new features, new bug fixes when they enter the Google code base and we want to push them out to users it's unclear to us how we get them into the Debian main tree quickly enough so that we can push that image to, to customers. Exactly. And so our customers are then left with an experience in which they can only use the official Debian image with like a subset of the Google features or they can use the other operating system that looks and feels like Debian which isn't really Debian. How, how does that integrate? How is that different from upgrading hardware support? It's not that much different except that our, There is a difference. Except that it was, except for the speed we upgrade our cloud every month or two. Right? Yes. A typical hardware installation of Debian the hardware will not be changed every month or two whereas in the cloud it will. So I think But not for the same customer. For the, for new customers, yes. I mean we have a, the thing is you're asking about hardware support in Debian Stable don't defend the status quo as a good thing. It's actually a big problem that one month before Weezy's release squeeze was not usable on most machines that were recently released and Ben Hutchings had a buff about that yesterday afternoon treating it as a problem to be fixed. So I agree that that's the way it is in Stable and it's a bug as well. So I think there are two separate things here again. One is the notion of what's official and what's not and the other are the release criteria. So for the standard Debian releases we have a release team okay and it's not like the notion of they are doing the official images is what concern what constrained them to do releases every two years. Right. They can compromise or they cannot compromise depending on how they work and they do decide their own release goals and try to enforce them with the help of the other developers. So one thing are the criteria on what's official and what's not and I think those criteria should be entirely on the basis of Debian practices and on the basis of free software contain the images and free software used to build them. The const the sorry the the kind of release policy that should be used that's something different. So ideally what we should have is something like a smaller release team just because I'm assuming right now the release team is not interested in also doing the the release work for the images. So having smaller release team for the cloud images that decides what are the release policy for those images. So ideally they should be close to the release policy for the main releases but if there are specificities of the cloud environment justifies having different policies why not. So in the fact I think you should cut in two halves the list of criteria you have. Some criteria will be to bless what is official or not and let's be clear. Official or not just mean that is something that you are willing to promote on the main with Debian website and so on and so forth. They can exist other images somewhere else which are made by some random guy which just says okay this is I took Debian and I rebuilt it for this cloud. Okay it's not promoted by Debian but I don't think we're going to chase him for trademark infringement anytime soon. Okay as long as it's not use the Debian name to ship malware or whatever. Okay and something else are the release criteria the quality criteria and that's for me it's an entire different discussion. Maybe what we need is just deciding who are the release the release people doing the cloud releases for specific clouds and be done with that. Yeah and there's certainly more ways of evolving the must be in main requirement without changing the nature of it it might be must be in main in some part of Debian you know it must be available from the Debian archive it might even relate to the new PPA main thing that the FTP team was talking about in May where there's going to be additional faster moving repositories hosted on the Debian infrastructure. I'm not wedded to one solution. Yeah I completely agree about the two the two halves here but there's also the third half which would also help for anybody who's building an image instead of the release team right the one of the problems that I know I have is I run through build Debian cloud right and I know I modified it to do X, Y and Z add this package, add this package, remove this package, remove this package modify this file, modify this file, modify this file is it good right I don't know right I think it's good it works for me it does all the stuff that I think my customers expect but then the look and feel of Google's Debian is slightly different from the look and feel of Amazon's Debian a few extra packages config files changed password login disabled root login enabled disabled who knows and some of those are motivated by the security teams at Google who are like no you mustn't allow root login on your machines even via SSH because every 30 seconds you can see someone's trying to crack into the SSH there so let me add one on to that what about deny hosts as default or file to ban as default right now by the way the Debian images do not disable the Debian images right now have permit root login yes as he says they would prefer that no because they are getting attacked every few minutes which let's not get sidetracked on this though but what I really want to have what I really want to know is what is what the standard is and even better yet have a set of tools that we can run that would say yes no my package to do the open stack Debian image has been rejected by the FTP masters because it was allowing root login so that's it was allowing root login that's the Debian default no no because open SSH is not stored it's still by default what open SSH is not installed by default ah well I mean at the same time though our images don't have a root password by default or root SSH keys by default so by default you actually can't there's no ability to access root via SSH so that issue is different it's right by default you know we have our SSH key management thing with non-root accounts and with passwordless to do but I think I think deny hosts I mean that's one of the first things that I installed is that something that we should have in all of our cloud images and would we consider that as as an official image because we don't put deny hosts in a standard Debian image or should we that was my question well again for most question maybe we should just go back to say is it really specific to clouds yes yes it totally is right the environment that these things are operating and it's so different I don't agree with deny hosts I think deny hosts is something that is universally useful as soon as you install SSH there's probably a pretty good chance that you should have deny hosts install or fail to ban whatever implementation you like which is those might be good things to add they are also somewhat error prone but you know I mean in this case we should try to focus on the general issues in this chat and so in the context of this point the general issue is twofold one of them is you know making sure that we can validate things given the differences in the clouds and across clouds and we needed some QA but yes that there are like the attacks every 30 minutes or every 30 seconds against root on these machines is more common in the cloud what I think is important is to provide our users to create the image they want yes so like if they want deny hosts to fail to ban or whatever if it can be a simple option that you can switch on the tool that is building the image in which hopefully it will be in main and then we'll have everything solved and that is the case you basically say dash dash package about about or whatever and and it's generated so is that in the build script you say yeah yeah okay I mean that is I assume that's what you're using to add and remove packages is it not yeah I mean I think the thing is customers we found don't want to run build devian cloud to build an image they just want something bear by default and maybe a couple of options that's all they want most 99 percent of our customers yes but you've provided only one flavor of the image what about providing one which is the basic standard and one which is oh if I did this and this and it's simple security let me tell you so right now we've got I don't know we've got two versions two main tracks and in those tracks we've got like a thousand versions of each devian with different versions of different things released and that's already a lot for our customers to ingest if we gave them 12 more versions of each track with different options or even so this is where four this is where even two or three two or three well this is where blends come in I mean should each blend be its own image on the cloud if I wanted to start up devian scientific should that be its own image yeah that's one of the things which I think is very interesting maybe we can talk about that later or today you will tell one thing we could do in debian as well would be to provide appliances how about an image that does hl proxy an image that is pre-configured for php or whatever so since we have about eight minutes left I just want to ask if anybody who hasn't said anything has any points they want to raise or ask I should just give a moment to ask that question so Zach earlier mentioned several release managers one per cloud infrastructure I don't even okay but I don't even see what that's needed because I'm totally fine with cloud providers customizing well creating custom debian based images with all the customization they want to make the user experience of their customers better no we are talking about official debian images I don't see why the cloud image on aws should be different from the one on gce which I think the content should be I think the content should be the same and if the user wants to do something different you can just install more packages to change what it's not that the image needs to be different in any essential way although they actually have different formats to some degree but it's more that they it's the same thing with s390 versus x86 you can probably install tools to interact with a remote s390 machine on x86 or maybe those tools don't exist but cross compiling etc but there's no reason that a typical amazon user would need gcu till there's no reason that a typical google user would need yucca tools no no they're allowed to use them though I maybe we should actually have all our tools on all our images because there's nothing to stop an ec2 instance calling your api to they can totally do it you know for exactly the same reason why my laptop in front of me shouldn't have the tools available as well to do whatever interaction with api that I want to they should all be able to app get installed especially what should be installed by default I agree with you there actually as those tools really needed from a user point of view I'm not sure they are what's needed it depends on what they're doing if you just have to get installing the goal is to provide base image so they can install whatever they want for their needs it's not it's like for if we decided that when you installed debian shiva plug you had some bar because some bar is cool and usually people using shiva plug for storage but that's not what we want to do the real issue here is debian has to choose I think if you follow the consequence of your logic debian has to sort of choose whether whether they have the base true official debian image that pretty much nobody in cloud uses because it doesn't integrate with their with all the cloud properties and or do you have versions or flavors of the official that are officially and then enhanced yeah it's base plus enhancements to integrate them to the cloud and whether whether or not debian wants to get into the business of calling any of those official if they don't care then they don't care and maybe people will just maybe if some people will go and take the base image and download all the tools and install them all just the right ways yes but that's complicated and hard and most people we find don't want to do it and I think the important thing to say here is we're not talking about somebody who's installing one machine or somebody who's installing 10 machines we're talking about customers who are spinning up 20,000 machines for four hours then getting rid of them and they're doing the same thing the next day and although yes you could do these customizations and all of our images now support that you can script this it can be automated but if you have three minutes of installing packages times 20,000 machines you've got a large amount of time that you've just wasted installing stuff that we could have already had already yes but you're never going to meet those people's needs no you can't please never ever so those people will not be able to use the Debian official image they will customize it potentially yeah you're right so at some point we have to decide let's add some tasks in in that cell and for more needs so one of the options like sorry it's that guy so to clarify on that point you're totally right I don't think we need to have some specific release manager for every single image it could be one and maybe you should you or she or the team should consider differences for different images but can be only a single authority but the point here I think your problem is that you lack authority you don't know which authority in Debian as the final word on deciding whether a specific customization you have made is acceptable or not so in the general Debian governance we solve this because we have packages and packages have a clear maintenance structure so even if there are 10 different opinions on now something should be done the maintainer as the final word and for something which is more general like the release of Debian as a whole we have the release team which is the final authority to decide what's goes in and what's goes out okay we do not have that for Debian cloud so if you have done some specific customization you post it to the Debian cloud mailing list and you get five different opinions two of them are in favor three of them are against so what we lack I think is a specific authority in deciding what can go in an official them in image and what cannot go technically which is entirely different from what is blessed from let's say political point of view so ideally this should be some some sorry this should be something which is part of the release team pretty much as in the release team we have stable release manager and release manager for the but if to start with they don't have the envy or they don't have the the power or the energy to do that we should start with a small separate team which fits in the usual Debian governance structure which has the final word of technically what can go in and what cannot go in mm Bravo mm yeah I love you yeah so with two minutes left let's keep talking but I just want to mention David and I and I think you and I think from Amazon James and I think Brian from Eucalyptus and Tomah from TPOS I think we're here the rest of the time right anyway we're all here the rest of the conference so let's keep the conversation going beyond the next two minutes can I have one other mix on this and I go ahead wanted to sorry I can get the room's opinion on this we've talked about adding tools in what do we think about um desktops in the cloud yep desktops in the cloud as an AMI I've played with it with RDP to a a Debian instance unfortunately I live on quite a number of milliseconds away from my local region but does anyone have a feeling or two minutes to go I know I know who's interested in that kind of stuff anyone show hands yeah okay hang around because we've got a 15 minute break between this and the next yep thanks all for discussing let's keep chatting thanks for the conversation everybody