Oh, okay. Great. Hi, everyone. I'm David new snow gravity for those of you who don't know me Which is probably most of you looking at the room So this is a boss that was supposed to be much smaller originally I can't believe the number of people who are actually really interested in this those me like 10 people and everyone was Everyone else can be like oh, I love subversion because get sucks and it's impossible to use Apparently that's changed over the past few months though with 1.5 release especially so I I'm not entirely sure What the makeup of the audience is and how to structure this talk entirely or off? So what how many people are using get right now and consider themselves fairly good with it really workable And how many people have no experience at all with get and really oh wow, okay? So that's a pretty large number. So I'm not going to try and sell you on get per se especially not against Well, I will try and tell you on it versus something like subversion because frankly it's a much better model I won't try and compare it to things like bizarre or TLA Because I don't want to talk about TLA or mercurial because those are fine systems in their own rights And they're all distributed to and most will apply to the distributed stuff as well But really what this is important what's important about get is that it's being used by core components of any links distribution now between x.org thanks to the man the yellow shirt there and the Linux kernel we have really Major pieces of our infrastructure using this revision control system And it's worth learning just for that and I think it really does scale all the way up and it scales all the way down to your private projects You can maintain your one text file with get without any troubles. It's really quite easy so just by way of an introduction so The x-strike for switch to get a few months ago when get dot demi dot org was was established Thanks to Buxy and the aliyah team for for putting that it together And we were able to put that in and we really wanted to do this because x.org had switched to get from CVS and Being a distributed vision control system all of a sudden we had this major advantage of switching to it previously We were using subversion which was maintained Not on a Debian server. It was maintained by Brandon Robinson who I'm sure most people probably know having been famous and formal DPL And we were using subversion we were happy with it it worked it was slow as can be It was hosted on a DSL line and for pretty much anything if you wanted to you know You know get the status and all this stuff You really had to you had to hit the network for a lot of things And it was really slow and you don't realize how slow it is until you're not having to hit the network every single time You have to do it in operation But we switched to get with the help of a team member who unfortunately couldn't be here theory-reading who? Is actually our company's maintainer as well, and he wrote a massive infrastructure to Convert our really horrible subversion repository, which was thanks to me and being sloppy Into get and we've maintained pretty much all the history that we had before and you can do this if you have subversion You can do this if you have CVS There are tools that come with get to do that. I'm not going to demonstrate them, but they're available so Because we had an upstream that we were working from we really wanted to do things slightly differently than Was standard with subversion what you can do what's I don't know if everyone does this. I think a lot of people do Well probably not in Debian actually because SVM bill package doesn't do this, but With subversion one thing you can do is have a vendor branch and you can check in into your vendor branch The upstream code copied over to your working master branch your trunk and then do all your work there Have all your devian packaging in there and the trunk So we wanted something sort of similar to this in theory We wanted a separate upstream branch that we would have that you could easily diff against say upstream's branch And you could also easily diff against your working branch to see what's changed if anything So we actually have that so what I've got here is just a fresh check out of our ati driver Just because it's convenient That we keep in our in on git.debian.org So what you see is when you clone when you clone to get repository initially In with 1.5 you only get one branch check out in this case It's laying you you set up to whatever it is by default its master We've set it up to be the debbie unstable branch and what you can see here Is that we have several branches that go from origin origin is a remote in this case? It's git.debian.org you can call it whatever you want. It's basically an alias And we we have git.debian.org is our origin and what we've got is the way we've set things up is we've got these Dash experimental or unstable branches and there we both have upstream and debbie inversions The upstream version is literally just a clone from the the git.freedestop.org Repositories and the way we do this is we just pull it straight in and it's very easy You just do git pull and it goes straight in and then what we do is we pull it it further into our debbie in branch And if we want to make custom changes to the debbie in packaging for example or outside the debbie packaging in the sources But we don't want to push them upstream we can keep them in that branch We keep them separate the other nice thing about this is that upstream can look directly at the upstream dash Unstable if there's a bug report that's filed in the the freedestop.org bugzilla I don't know if anyone's actually doing this in free desktop, but we provide this ability You can easily different against head at the the x.org master head and just say oh well There's a fix that was checked in that you don't have yet because you're running unstable But look in your experimental version. It's there So this makes a trivial to do this actually if you want to do this upstream might not be doing it but I I try and use it on occasion and it is nice to have this sort of flexibility and Quite frankly with subversion you can't get this because it's not really distributed So That's basically how we do things we also We've been keeping our patches in we keep our long-term patches in in using a patch system called quilt How many people are using quilts? How many people using d-patch or? Okay, all of you using d-patch. I've already lost you've really made the wrong choice Quilt is so much better. I can't even tell you Pretty much get has various add-ons that you can use quilt like versions integrated things like st git or Guilt and then there's another one that I I don't know I haven't evaluated these personally. I've heard very good things about them They don't Interact properly with git web. So you can't if you're browsing repository with with the web you can't see what's different So that's that's kind of an issue and why we keep things in in quilt still So for long-running things you can keep the stuff in git if you want to we haven't made that transition mainly because we haven't We haven't evaluated it. Are you here? You're getting maven. Are you using any of these stat patch stack things? Not yet. Is anyone using them st git or anything? What's that? Actually, I've patched quilt a lot so that it supports posick shells There is a branch of stream with my patches in it and it seems quilt is really lighter than The nested git that uses a Python a lot and it's quite slow. Okay Okay We found this this whole method works really well So, okay, if you want to do things and you want to maintain packages with git I really I think that using Quilt is a really good way to go for long if you have long-running patches that you need to keep out You know, we've got things that really should not be pushed text or org upstream and That's how we keep them out. So if anyone wants to talk about how to use quilt I can do that privately if you'd like But you know, I'd like to focus on git for a little while if possible so I'd like to open up for questions actually because I mean I can do a whole tutorial thing But in reality, I don't think I'm to be any better than a the documentation that's out there So if there are any questions about the x-strike force and how we use git or anyone if you've got general questions about git and why you Would use it and why Ian Maybe the intersection between Debian Approach and git because there's there's quite a lot of good git documentation a lot of good Debian documentation But the intersection is a bit vague right so Git actually works really well for the Debian model of doing things Just because in terms in asked about the intersection between Debian and git and documenting using this stuff So git actually works very well for the Debian model doing things because by nature. We're all very distributed It's really nice to have the ability to just pull out The repository and work on it even if it's not your own repository. It becomes your repository in a sense and I mean Where it doesn't seem to work Well is the the Linux kernel model of using git there's two real ways to use git And I haven't seen anyone besides a Linux kernel using this model where there's no central repository People kind of accept Linux's tree as the central tree But in reality there isn't one the way you do things is pull only Mercurial was actually written to use pull only that was the model They had in mind as well and the idea is that just you pull things into your tree And if people if you're Linus Torvalds you pull in who you want and then everyone gets your tree because they're interested in your tree It's not like Linus's tree is the God tree But I think everyone else that I've talked to is using this sort of centralized subversion like model We certainly do for the x-strike force where we've got Basically one xorg tree that we xorg server tree that we use for example And it's really the canonical tree We can have user trees if we want we can have user branches But in reality there's the one tree that we consider the right one and the reason for that is simply we don't have a thousand contributors Like the kernel, you know, we've got you know me me and Julian hacking on it So It's it's not a massive thing and get can scale up in that way But a lot of the docs are made For that sort of model get format patch and all this stuff, which isn't really as useful for for the Debian model So I'm not entirely sure what other sort of intersection things you might be curious about Yeah, hi, I'm Johnny to echo and I maintain deep patch using git, but there There are other tools in Debian like a git build package and like dev scripts Dev commit tools. Do you use those tools? Okay? So I've experimented with both so git build package. Has anyone use git build package put me One per two, okay, so git build package is really not built for the specific problems that the x-strike force faces if your upstream using git Using git build package will do the wrong thing every time it expects you to have a dot orage dot target dot gz That you have to import it expects that every time So if you don't have that, you know, we do have that but we like to pull directly from free desktop It makes sense So, you know, we like to we like to cherry pick individual package patches straight in then when we merge They get merged in magically, you know, git does the git does all the work So git build package will work and it does work for people It's a little finicky to use with pbuilder and stuff Which you might be aware of or at least it was a few months ago when I was actively trying to get it to work for us but For if you're upstream using Git I don't recommend git build package if they are using it. I think it's a great tool as for Dev commit I think was the other one you mentioned so I was using that as well and the problem with dev commit So Do people actually do anyone use dev commit perhaps with subversion? It's a great tool So dev commit, okay, it's only not everyone's familiar with it Dev commit will when you when you make a change to your Debbie and change log you run dev commit It will pull out the change it will take the diff from your Debbie and change log and use that as your commit message For we're committing. It's actually very nice for subversion Forget though the way git formats its log messages So you've got for example this this one line merge. I've merged friends, but here Move the files will be put into Debbie and X FBS. You don't have to worry about this means But basically there's one summary line and then what happens is that there's several other lines below it potentially if you Want to have a very long log file? You know if you've got a lot you want to explain so what happens with dev commit is that it'll use the whole thing as one Long things you have this one long master Line when this is really supposed to be much shorter So that's a problem with using dev commit with git and the other issue is that Okay, so a lot of people probably don't know git so git Exposes something called the index And this is really a sore point for a lot of people. It's really something you have kind of to wrap your brain around And it's really not that complicated Basically, you could think of it as a staging area and everything has this so subversion has an index and it's basically when you run subversion diff It compares the index which is you know It's cached version of what all the files versus, you know, what your changed file is and it gives you the diff It doesn't have to hit the network. So that's the index. It doesn't expose it But it's there git actually exposes it and makes you deal with it in a lot of ways You don't you can get it work around not using it, but it does expose it It actually becomes a powerful tool if you want to use it So for dev commit what you have to do is actually Tell you have to manually update the index for the Debian change log and only then will dev commit see the change Which is really horrendous and really the wrong way to do it So there's a couple problems with dev commit in terms of Debian right now And I'd love to see those get fixed, but I think that It's probably not the correct way to be doing things right now I think the tools are substandard for for the specific needs of git They're really written with subversion in mind or CVS any other questions comments Martin Do you use any feature branches? Use what feature branches with that? I mean yes. Yes, okay So would you would you care to explain that workflow a feature branches like if if you decide to add another Feature that may want to go upstream at one point in time Then you put that all in the branch and then later on you can merge that branch back into your tree or send it up upstream right so yeah Martin brings up really one of the key points of using distributed version control and especially Get actually because gets branching models cheaper than anything you've ever seen So version they say branches are cheap It's only cheap if you're using SVK because you have to hit the network every time you want to switch a branch SVN switch it takes forever, right? So how many people use SVN switch or have used it? It takes a while right? I mean especially for a large tree. You have to like wait for the network. So I have a new branch You know, I mean it was nothing like it just happened There was no hitting the network. There was no nothing. It just it just works so Get what this allows you to do and it really kind of encourages is these what Martin was talking about these feature branches Where anytime you want to make a change that's substantial and honestly even when it's not that substantial It's a one-line fix that you really want to test extensively or you know, whatever It's really useful to have these and then what you do is you just make it there You commit it in that feature brands that no one ever sees except for you and then you pull it back into your Into your main thing to push it to to upstream and they're really great because they're extremely cheap and you can just delete them later no one ever knows they existed but you and It's really powerful because you can have a billion feature branches around at any given time So I think that it encourages a very a better model. It's really the right way to development is to have future branches I think that subversion hopefully subversion will get proper merging. They say they will but it's really a nightmare every time We had to update the Every time I had to merge in updates for For X for example in the XORG six eight to six nine transition I had to merge a lot of updates by hand and it was just horrendous. So you don't have to do that as much of the get It just kind of works One question on the feature branches where at least I'm a bit struggling currently is If I have some version of my Debian package and says well, okay Or basically I say I want to have the upstream as a mine target and make all features I add as feature branches, which seems sensible to me. So Then I get the next version of upstream Commits a commit the changes in import the changes in my main thing and now what I do I do to feature branches and what I do to some resulting Debian package to have it all without Major pain because they're somehow struggling. Probably just need to Probably is doing a brain to accept it how it works, but Okay So you want y'all to let me try and repeat this and see if I got it, right? You want to have multiple feature branches and you want to merge it back without pain. Is that right? Okay, it works even worse. I want to have basically I said, okay I have the upstream package. I have the Debian package. Yes, and all the features that I added in the Debian package I want to have as separate so that I can see okay This feature now has this and this and that so in case upstream decides to Upstream I saw I can send them as separate to upstream and I want to keep them as feature branches Until upstream decided to merge them. So how do I do that? Especially if they're a new upstream version in between So you do that as pole only essentially no Rebates This is a new one. This is why I wanted the boss so people can teach me things. What are rebates? I have heard about the base, but I've never let it on it Successfully. All right Keith can explain rebates because I don't know this one. This is exciting Yeah, oh rebates rebates What get rebates does is it so say you have a feature branch that has one commit on it for the ease of discussion here What get rebates does is it does a diff from that feature branch back to the back to where it was branched from? Generates a patch and then applies that patch where wherever you want to rebase to and then moves the branch to the result of that Commit so it takes a diff does a patch does a commit and moves the branch to that new point so basically relinks your feature branch to a new place in the tree and So see what it does. There's a good picture there. You can see it merging It's moving you have on your topic branch You have three commits a b and c and they're originally based at e What the rebase does is it actually moves them so that they they are now based on top of the commit at g And all of your all of your changes are are integrated appropriately and the commit It's using the regular the regular get merging techniques, which are pretty darn good I use this a lot because as I do a feature branch The last thing I want to do is expose that feature branch and the and the fact that I used a feature branch and publishing my changes So I'll do a bunch of commits along a feature branch I'll rebase to master and then I'll push the results so I get a single line of development I don't get these artificial branches And that makes the that makes the resulting tree look a lot cleaner when you push it back as well But you can do this with as many branches as you want So you could you could automate pulling in a new master branch and just rebase all of your topic branches quite easily So and how do I do it if I say I have all my feature branches concentrated in one in my Debian version. So all features are imported sir I It's just as well Made a version should just come from all the seas seas seas branches So how do I do that or just is my brain just not the web up enough around it yet? I think you have to play with it. So having having rebased It's common enough for me to want to do go and do archaeology on previous versions of my package to see What it did in some circumstance It looks it looks to me like once you rebased your that's it your topic branches now the new thing Can you go back and look at what it used to be? I don't believe so. Oh, you can go back. I've never tried this Yeah, he should stand up here This is great Now the important thing here is to look at the old commits the old commits were labeled a b and c The new commits are labeled a prime b prime and c prime the old commits are still in the repository If you have a version if you have a distribution version that points to those old commits They're still valid. So you can still do diffs against so you may have rebased the topic branch But if you have some other branch name pointing to that place like a released version that old branch will still Still refer to those old commits. So you lose nothing get never throws anything away so In the back his heads end up for a while So I'm a subversion user trying to figure out You know what what this is all about because I keep hearing lots of people saying this is just the best things in sliced bread And I haven't figured I haven't gotten it yet. So I've got a bunch of Debian packages I maintain them in subversion. I use quilt for all changes to anything upstream So I basically have no modifications outside of the Debian directory How does get help me because you you say one of the big things about get is you can merge with new upstream versions? Really, but well, I have a bunch of quilt packages. I have to merge merge the quilt patches. Does guilt get help with that? So Quilt is an amazing tool. I don't think I can sell it quite enough So you might not be getting tons of benefits out of subversion if I'm sorry I've get if you have quilt inside of subversion. I mean we were doing that. It was very successful But even without that I found that get I mean number one you you save a lot of time with get it's fast you do save a lot of time just doing basic operations and So you there is a net gain there and most importantly is really the branching You can have very easy branches and you can commit anywhere you commit on the airplane You can commit when you don't have when your wireless is down You can commit anywhere without any troubles anything is equal And that's really a very nice tool to have available to you the branching truly is cheap It's not like this sort of fake. I have to hit the network every time to get it cheap Which opens up new models of development. That's almost hard to describe in a way I gotta say real quick that I think a lot of your speed problems with subversion were because you had a painfully slow Subversion server not because subversion is actually slow. I mean I do the situation you're describing with slowness of subversion I've just never experienced that we have a very I mean we were maintaining the XOR Monolith inside of subversion. It's a very large package set subversion did not scale very well to that It's it's hard Martin has oh and Pierre as well. Yeah, Pierre was Actually first I'd like to stress that it is fast and it's a thing that you cannot stress enough even if you have a views to SVN with easy over ECSH with ECSH control masters, which helps a lot and it is Hopefully faster and well once you have tried it once you just can't use anything else because it's really really fast And you can't bear the fact that it takes ages to commit a thing in SVN anymore until the end I'd like to come back to rebase a bit because David said that a gate is unused well not only but is useful especially if your upstream is Use this gate. In fact, that's not true because there is a lot and a lot of Tools to make it interact with other SCMs like SVN, but CVS also and Arch or Bezada also it works really well and With rebase on you can have all the nice features of gates working even if your upstream Is dumb enough to use this to use CVS or SVN. In fact, well, I I'm not there quite yet, but I'm trying to package a lot of things using these techniques and having my patches in gates and sending them upstream and seeing them come back through their CVS or SVN server and seem them merged Using rebase. I'm not sure this workflow works very well yet, but I'm quite sure that it will perform very well because Well, it has been returned to work like that and in fact using it that way is introducing the Distributing way distributed way because your own and it's really what David is and she reminds It's Taskforce are doing in fact. He said we have a central repository. That's not true. They have a satellite No, how to say that Their main repository is a free desktop one. You have for a secondary repository and your repository is already the distributed model and you are using it in fact Even if in the x-tax taskforce you are using this repository as a reference. In fact, it's only a second one So I think gates is a great tool because it's fast. You can work at home You can then push things later. You can work in the plane back from the company to work and You can and well, you have to try it in fact. In fact There is nothing to to persuade to To convince you more easily than using it just play around for the record I have there is an important the web of the full JLBC history from 1983 it's 150 megabytes big and you have everything and When I work with a really on the on the live scene Today, he asked me three or four times Well, when is that patch or test came up in the repository because we've get I have the answer under one second when he has to go through the view CVS thing well Maybe you know in one hour or two. He will have the answer When I get back to that question why get is so much better than SVN and quill for a package maintenance and well, if if all you do is ever pack maintain your own package in SVN with killed on top to manage patches that were submitted by the backtracking system, then I have to admit that the speed which these two guys have been really high upon is Is one of the main reasons but as soon as you start to do things like branching as soon as you actually develop Parts of the package and you use a branch to do that. You really do not want to be using SVN I'm a zopin-plone developer and zopin-plone use SVN and It's a rather big repository as well and one of the things that get does very differently from SVN is merging branches Because the way and then nobody minds if I just explain this a little the way that Things work in SVN is that basically branches are nothing other than two separate file trees So that if you merge them what you're doing is applying a patch Now imagine that you are creating One branch to do feature a Another branch to do feature B and another branch for feature C And now you fight figure out that you actually need feature a to get feature C working So you merge branch a into branch C And then you continue working on C and you continue working on B and at one point in time You decide that B and C are both right for production. So you merge them back into the trunk When there is a conflict because all the changes that are in B are or in a are Already also in C and what you'll end up with is a hundred Reject files and ORIG files and you have to tell SVN that now this conflict is resolved and now this conflict is Evolved and the way that git does that is that every single commit has a Unique string a unique identity attached to it So if you merge two branches what's happening is simply the union of the sets or a set addition And it only pulls in exactly those commits that aren't already in your local branch So it is actually very much smarter about it. So if you use branches Don't do it in subversion, right and there's there's other I mean, there's fairly common examples of needing branches that are they're just trivial But you can't do them in subversion trivially and that's really a problem like if you've got If you've got it if you got something that you're not finished with You know commit, you know some sort of commit you're not finished with a long-term commit or a long-term branch That you really just want to work on and it's not done Get you can just do a local clone very quickly and very easily with I mean you can copy it in subversion But it gets it's subversion is also really huge that the day directors are much much bigger than it get get compresses Amazingly well, and you can make it compress even better Using all sorts of all sorts of tools that it exposes that you don't have to use but it's available to you if you want them Repack and all these things so there's some very nice things that it provides that are very low-level that I don't understand yet So I won't go over them But they're available to you if you want to learn Oh, how is the format what is it the format that gets towards in the post repository is because let's say I want to set up some tiny repository to play with it manage my documents Whatever, but I want to do backups from it and then if it's all compressed as one file For example, I would need to backup it each time with each tiny modification or is it friendly to that? Oh, it's available to you. I mean it compresses internally I don't remember that the format it uses internally.  I mean I'm not sure I understand. It's not like a tarball in tarball. It's one file per commute so I can Is it internally? So how friendly is it to our scene backups? That's basically the question Our scene backups basically, I didn't understand. I'm sorry my Oh our sink. Oh, it's trivial. Yeah, I've our sink several get repositories. You can do it. You can clone Cloning is I don't know if it is an r-sync But it might as well be in a lot of ways you can r-sync a directory No problem, and then you can check out if it's just a bear get director You can check it out from there as well, so appear saying that clone is a better way to synchronize the repository I've done it. It's not been a huge problem, but it you know You know you can r-sync you can certainly can if it's hosted you can pull it I don't think you can well. No, it doesn't throw anything away. So honestly don't know the answer to that And then you have to transfer the entire thing Right, right. Okay now. I understand I see so yeah, I don't know internally if that's if that's the case I think if you probably don't pack it too much, it's probably not a huge deal You can pack it at some point and it will compress into a Very it might be one file. I don't know. It's highly compressed at that point But I've never looked into it that deeply to know the answer to that. I'm sorry. So while we're on the question of r-sync I've Used buzzer a bit and I found that r-syncing buzzer repositories is a complete pain because they contain enormous numbers of files Just get suffer from this problem It doesn't need to By default Every come every file every version of every file in git is its own file So in the old in the original repository structure. Yes, there were a phenomenal number of files every time you made a change to a Single file there would be a new file created in your repository Which if you tried to r-sync that it would be a disaster However once Lien has figured out that that was probably not very scalable He came up with a technique for taking multiple files Independent of where the where the original source independent of what source file they came from you look at multiple files in the repository and pack Them all together aligning their common data data chunks Such that the that you can pull out files very rapidly from the pack packed version of the archive and then so so What you do is you run the git repack command which takes all of the unpacked files and sticks them in a single new pack file So you basically have all of the things you've done recently in your repository are now in a single file Now if you r-sync that you copy one file now you work for a week or two You make a bunch of new changes you have a bunch of individual files You pack those together into another pack file and you r-sync again and it copies one file So it's extremely efficient with r-sync because you copy only The changes that you've made since you are same last time and you own and the entire r-sync operation is a single file Now if you want to you can actually take all of if you have a thousand pack files now You can actually tell git to repack all of those into a single larger file And it will throw away all the individual pack files and at that point you are sink You are syncing the whole new file, but you can shrink your repository dramatically by that The entire six years of X repository information for the X server is like, you know 50 megabytes or something which is about the same size as a single checkout Right, that's something to bring up actually when we had our subversion So a single subversion checkout of the X server from our old subversion repository Was about twice as large as the checkout from the extra for upstream when we switch when x.org switch to git And we had the entire history in every single branch ever Whereas it was just one checkout of one branch from subversion of our of our own extra force repository I know subversion's gotten better in that regard, but in reality there's massive space savings for git just very quickly I just did an r-sync test on a git repository and Therefore haven't listened to everything that Keith said so I hope I'm not repeating something but basically a commit will result in Additional files being created, but no existing files modified. So it's friendly for backups And with the addition of that repacking, I'm sure you can get Even like archive history and then make it even better for that in fact actually You can or think a git repository, but it's quite a bad idea because a clone will get everything From your repository and in fact some better way to Backup a git repository is to clone it and if you have a bag It's exactly what I do with my git repositories I have a script that clone it on some backup servers I have and when I commit to my central repository my backups Pull a game and they pull only the changes because git Transport is efficient and does what I think will do in a better way Sorry, I'm just quickly I Don't think that our sink is the best way to duplicate the git repository because you will it's not an atomic Transaction which is what you're saying, but sometimes if you have a backup tool that runs and it is based on our sink You can't really do anything else unless you want to switch over to something called backup ninja, which is an awesome Program that you can actually tell it to first clone the directory and then our sink that because there will be no commit going on Actually one thing that I Everyone done Children Okay, so one question what I repeatedly do with other system was for example subversion can do is that I check can just check out a Sub directly right can do that with a skid and if so, how no, okay So that's the problem with get you cannot currently do that And we've actually had to sort of balkanize some of the x stuff a little bit to make that happen There's two things that get doesn't do that. I would like one is check out individual director So you wouldn't want to say put have one git repository for like all of the package GNOME stuff You know and then you can't do that you would have to have one for each You know metacity and one for Nautilus and one for you know all these things so git can't do that currently there's Work underway though to make something similar to that happen, which is called sub projects Which is what you would really want it for anyway and the idea would be to have You know Nautilus be a sub project of the GNOME Repository and as far as I know what what I've been told by Xcb maintainers is that some of that a lot of that underlying work is in place It's not hooked into the UI and it's not going to the merge support yet. So it's not fully there And then the other thing that get cannot do that subversion can do that's often demanded is The equivalent to SVN colon externals does anyone know what this is or use externals Okay, so there's a few people so it's it's it's you'd use it for some projects sort of thing It's basically you're able to pull in a Specific directory or repository into a specific part of your own subversion repository and use that externally and it's pretty seamless It works really well. We used it for shared packaging information among the X packages and the way we do it now is we just have a separate repository for that Shared packaging information and manually pull it in rather than let the revision control system deal with it So that's something git doesn't do really well yet. That's a version does do Colin You you have the same problem and other distributed revision control systems mean arch and BZR both of the same constraint and You can almost certainly just use the same if you're if you're desperate You can almost certainly just use the same tools the the arch guys route something called config manager Which is a bit of a hack, but it's just something that takes a plain text file description of the other projects that you want to incorporate basically like SVN externals and Check those out and or update them as necessary and you can probably just use the same thing Interesting. Yeah, the problem. I've heard with that and I I don't know enough about The implementation of a revision control to comment on this further But the idea is that each change is actually a change set and that it covers It's it's it's basically a change set over across the entire repository. So if you want to pull out a specific Change set you have to get the entire repository. You can't just pull out a sub directory and this seems to be an architectural issue Which is the way these things are implemented That's that's what I've heard. I don't know if anyone can comment further on that. I See we have 15 minutes Small question back to different tools. I have Requirement to pick Eric Targaze from tag not from branch head, but from tag Sources is there any devin tool which can provide it from from what sources? Take the sources. So well my Arrictor Gazette is not in herd somewhere may be in previous tagged sources. Well, I have an upstream branch Yeah, and There is upstream version 1.0 1.2 1.3 and so on I have tech for all of them and The head now is 1.3. For example, I want Arrictor Gazette for 1.1 I want to build a devin package 1.1 minus something. Yeah, so we do that So there's a limitation so yes, you can tag anything you want. We do tag our own we tag our packages to build what Well Yeah And actually get bill package will build your own orage targe easy And that's actually one of the problems I have with it It actually will build that for you out of the out of the get repository. It can be done I don't think it's the right way to do things. I think it should just You know use what's there? Yes We use his head Okay Okay, is there any way to fine tune access control? Is there what? How do I manage passwords or access to the main repository? It's via SSH So we use SSH and things like that. So for local stuff. I mean, I've never tried to do local access Restrictions, but for remote stuff, it's just it's just SSH Which means you cannot restrict someone to a specific branch or something Not that I know of does anyone know if it's possible really How do you configure that? Actually, there is some reason to to inform that but I don't think there is there will ever be very powerful to to do that because Linus explains that Basically, he doesn't he doesn't want to hide code and He just want people to clones the main repository Whatever stupid things they want in the repository But he won't give them access right access to him repository. He won't just put he will just pull from them So in fact The any access control is done because he either he pulls from people he trusts Or he reviews the patch because before he merged them also, uh, we wanted to use a distributed version control system at work and The major showstopper for us is that we have a lot of windows people Are there any GUIs that that are in the works? I don't think there's any GUIs yet I mean, there's there's I don't even know if they run because they're tk based. I assume they'll run on windows. Um There's there's the git commit tool which comes with git 1.5 and there's also A git k which is really a wonderful so as anyone see people might not have seen See if you can see in 800 by 600 I'm my slow laptop So there are visualization tools, but they're not great. They're nothing like torus svn or anything like that that are really quite nice Um, but there are really nice visualization tools for the likes of us. So if you want to see, you know changes Um, I believe busy has cloned this right busy wrestling similar to this right now What? Yeah, yeah Okay, so yeah, this has been cloned because it's a really good idea and it's really nice I don't think subversion has anything like this. Um, it's just a really nice interface to to check out changes and See how see how branches merge and this is a relatively simple branching pattern So you don't see a whole lot, but it can get complicated Are you serious? It's yeah, you you talked about it when she's in they weren't shown on the screen Sorry, I I I didn't get Keith to fix my laptop like he managed to fix martin's so Um, sorry about that. But yeah, basically it's a really nice visualization tool But um, the problem is also just getting git running at all on windows. There's a min g w port in progress I don't think it's mature I haven't been following it closely and then there's you can run it through sigwin But a lot of people don't like using sigwin So it seems like if you're going to use distributed vision control on windows The real winner seems to be mercurial from general consensus that I've read around and mercurial is a great system I will not badmouth at all because it's wonderful and it's very similar to get in a lot of ways But hopefully git will eventually come to windows properly and people we can you know Not have this issue with at work people want to use it Yeah, bizarre this too. I'm sorry. I forgot about that. So yeah several there are other options and darks does too I think I like askel So is that five 10 great I have one addition. There is a nice talk from linus tobbles himself on google videos. Yes So if you have seven 70 minutes, I guess time, it's funny And interesting Yeah Who's who's watched linus's talk at google on google video is very well seen It's it's good. He really smashes the subversion people kind of he's kind of mean about it. Um Awesome, I bet he I bet he loved it But I think linus has really spot on a lot of ways in that video and it really is good to see what he's thinking about And why he made the choices he made With certain things and it really does clarify a lot of the design things Design choices that git has made in terms of that seemed like they might be bad choices at the beginning and they really Have turned out to really feel the better I knew you said You wouldn't go over how you went from subversion to git, but if you've got a little time Can you maybe go over that process a little because? To do to do what exactly going from subversion to git migrating. I can't go over that I mean I can tell you what we did, but there's better ways to do that now So there was a script that comes with um, I know a peer is gonna Yeah, I know yeah, I know what he's gonna say because he blogged about it and it's actually very exciting So we use there was a script that came with it to convert the repository It's this massive pearl script and it would go through the subversion repository and sort of guess What was the right thing to do it every time and it would convert it to a git like format And we had to hack theory had to hack that up insanely to get it to work for our messed up subversion repository But he managed to do it So that's how we did it but and then but the better way to do it is that there's actually a program called git-svn Which comes with it and that's what peer is raving about and I haven't had the opportunity to use it yet So I can't really talk about it very much, but basically it allows you to transparently use git with subversion repository so that Your co-workers don't know you're using git they don't have to care and you get all the benefits of using it Essentially with subversion being the back end So you can actually by making A clone using git svn you get a git repository that's totally converted and it just works And then so that's probably the best way to do it these days And you just get the repository for free and you don't have to deal with all the mess that we did So not having the experience with that myself. I can't really lead you through it But that seems to be the right way to do it Pierre do you want to add to that? He's actually got experience with it Actually, I'm using git svn for two things at work because We sadly use svn at work And for to work on the glibc because the glibc uses svn.dbn.org but I use it through git But in fact, git svn is a very good tool to migrate a repository because it does everything by itself But it's not a good idea to to believe you can learn git using git svn because You have most of the benefits of git but you have you still have svn behind and When you have things like that Here what you see is a merge It's basically that the the graph that is behind has a Convergence Merge point and you can't have that in svn. So in fact in svn you are you are forced to have a linear History and to use git svn you have you have to know how to Linearize your history and it's quite hard to to figure it out When you're new to to git so if you want to switch it's better to Sometimes run git svn to have a full git repository that is the same as your old svn one And use git on this repository And if you don't like it Go back to svn for a while and we try it every time you want because using git svn You have to know git a bit before Okay, I just quickly wanted to say I claim a little while ago that you could control users User access writing. I can't find the information anymore So I think it's better to assume that you can't do it and get the positive surprise I'll let you know if I find it still and I just quickly tagging on to this The the talk today is about git and debian, right? I just wanted to do it a little bit of a Self publication here because on the 21st, which is Thursday Manos and I are going to give a workshop at two o'clock For two hours, which is about using distributed version control for debian packaging and we hope to be able It's the same model for git or bizarre or any of these other ones We hope to be able to give some ideas of what other things you can do with branches to make your day easier So on thursday too Pierre you mentioned problems with using git and svn due to merge points, which I assume is from subversion not doing merge tracking itself Has anybody looked at integrating git with svk or with the With the extra merge point tracking that's basically what svk gives you over subversion Has anybody looked at integrating git with svk, which Basically stacks properties on top of subversion. I know it's horrible, but if you want to enter work then It's one decent way to do it actually, I don't think it has been even considered because There is no point in using in Using svk when you can use git git svn Yeah, sure, but git already already gives you that in fact, so you have many ways to work with With svn in back end and having many merges in git you can for example Create a squash commit Which is what git svn does anyways, so Okay in a git kind of way It's horrible, but when you work in with svn, you don't have a choice So you have many ways to hide the facts that were merges and In fact the also of git svn Uses it and I do that all the time also as a two way gateway to a svn repository and You don't really want to bother with svk? Yeah, sure. Yeah, I agree with you, but on the other end The other users of the svn repository won't benefit of it if they don't use svk as well And in fact, they could also use git Well, we're down to less than five minutes left. So if there's no further questions We may as well as he's holding up. I'm time out anyway, so we're done. Thank you all for coming. I appreciate it I really am overwhelmed by the response And I hope you've learned something that you'll enjoy


Creeping escalation, along Israel-Lebanon border, brings risk of bigger war. Tire, Lebanon, the secondary conflict that erupted along the Lebanon-Israel border in tandem with. The Gaza war has settled into something of a routine. Every day for the past six weeks, Israel has attacked Lebanon and, Hezbollah has attacked Israel, a pattern that began as a tit for tat and is now blurred into a steady exchange of fire. Most always, the strikes are within 4-5 miles of the border on either side, a deliberate calibration designed to contain the violence and avert a far more devastating war. But the range and intensity of the fighting is gradually increasing. Saturday saw Israeli jets strike an aluminum factory. In the Lebanese town of Nabache, 12 miles north of the border. Well beyond the traditional zone in which retaliatory fire has been considered acceptable by both sides. And both sides have started using deadlier weapons. Israel is now regularly sending fighter jets to strike Hezbollah targets. Hezbollah is deploying drones and heavier caliber missiles. It claimed on Saturday to have shot down an Israeli drone, which Israel denied. Israel responded later in the day by targeting what it described as an advanced surface-to-air missile system. Israeli officials have also ramped up their rhetoric. Lebanon's citizens will bear the cost of this recklessness, and of Hezbollah's decision to be the defender of Hamas-ISIS. Israel Defense Forces spokesman Daniel Higari said last week. The IDF has operational plans for changing the security situation in the north. In the first weeks of the fighting, Israel was shelling only in the evenings, said Adiba Finash, 65, one of only a dozen residents who have remained in the border village of Daira, right on the Israeli border. Now it is from the morning till the night, she told the Washington Post while visiting Tire to buy supplies. It is escalating day by day. These sporadic escalations have yet to spark the conflagration many fears, but each violation of the unspoken agreement. Between Hezbollah and, Israel brings them closer to the brink. The last war, in 2006, killed over 1,200 people in Lebanon and, 165 in Israel and left swaths of this beleaguered country in ruins. Both sides have warned that any full-scale conflict now would be far more devastating, and both have indicated that they have no appetite for such a war. But as the weeks pass and the missiles fly, the risk that either side could miscalculate or overreach is growing, said Andrea Tineni, spokesman for the UN Interim Force in Lebanon. A peacekeeping force that monitors activity, on the Lebanese side of the border. Anything one of the sides could do, the other could decide it's gone too far and unleash a bigger fight, he said. In ancient Tire, a quaint port city of fishermen, cobbled streets and markets. The waters are sky-high that violence will soon spread to the rest of Lebanon. The past 17 years have given the South its longest stretch of peace in five decades. And this town has flourished, luring tourists to its beaches, bars and boutique hotels. The Shi'ite party and militant group that is Lebanon's most dominant political land, military force and, the words of Hassan Nasrallah. The group's powerful leader who is close and long-standing relations with Iran. In two speeches since the war broke out, Nasrallah has indicated that Hezbollah sees its role as creating a diversion along Israel's northern border to alleviate the pressure on Hamas, its ally in Gaza, rather than waging an all-out war. It is not clear that Hezbollah could sustain the support of the Lebanese population should it take them into another costly conflict. The country is already gripped by political deadlock and teetering on economic collapse. A woman from one of the border villages who has escaped to Tire said, her house and those of her relatives were destroyed by Israeli fire a day after she fled. Hezbollah fighters had taken over the homes, drawing Israeli strikes, she said. I blame Hezbollah, she said, cursing the fighters as terrorists. She spoke on the condition of anonymity because of the sensitivity of the subject. But people here are much more concerned about Israel's intentions. And the prospect that it might try to finally rid itself of the militant presence along its northern border. Israel has invaded Lebanon twice and occupied the country for 22 years between 1978 and 2000. Most Lebanese are convinced that Israel has a long-term plan to take over the country. Said, Samir Hussein, an engineer, living in Tire, who runs an organization dedicated to civic dialogue. They have proved their intentions by invading us with bloodshed, he said. They want our land, our gas, our water. Israel's heightened rhetoric and the prospect of a decisive Hamas defeat has left Hezbollah. With difficult choices, said Mohamed Obaid, a political analyst close to the group. Thinking about the future, can you just let the Israelis win in Gaza? He asked. If they do they will focus on Lebanon next. Sarah Dadauch, in Beirut, contributed to this report.


Working memory is a cognitive system with a limited capacity that is responsible for temporarily holding information available for processing. Working memory is important for reasoning and the guidance of decision-making and behavior. Working memory is often used synonymously with short-term memory, but some theorists consider the two forms of memory distinct, assuming that working memory allows for the manipulation of stored information, whereas short-term memory only refers to the short-term storage of information. Working memory is a theoretical concept central to cognitive psychology, neuropsychology, and neuroscience. In 1974, Batley and Hitch introduced a multi-component model of working memory. The theory proposed a model containing three components, the central executive, the phonological loop, and the visual spatial sketch pad with the central executive functioning as a control center of sorts, directing info between the phonological and visual spatial components. The central executive is responsible interavial for directing the attention to relevant information, suppressing irrelevant information and inappropriate actions, and coordinating cognitive processes when more than one task is simultaneously performed. A central executive is responsible for supervising the integration of information and for coordinating slave systems that are responsible for the short-term maintenance of information. One slave system, the phonological loop plural stores phonological information that is, the sound of language and prevents its decay by continuously refreshing it in a reversal loop. It can, for example, maintain a 7-digit telephone number for as long as one repeats the number to oneself again and again. The other slave system, the visual spatial sketch pad, stores visual and spatial information. It can be used, for example, for constructing and manipulating visual images and for representing mental maps. The sketch pad can be further broken down into a visual subsystem dealing with such phenomena as shape, color, and texture and a spatial subsystem dealing with location. In 2000, BABAE extended the model by adding the fourth component, the episodic buffer, which holds representations that integrate phonological, visual, and spatial information, and possibly information not covered by the slave systems e.g., semantic information, musical information. The episodic buffer is also the link between working memory and long-term memory. The component is episodic because it is assumed to bind information into a unitary episodic representation. The episodic buffer resembles Tuddling's concept of episodic memory, but it differs in that the episodic buffer is a temporary store.


Hello. Hello. Hello. Good afternoon, everybody. Thank you for attending our session this afternoon. It's going to be a very exciting session. I'm speaking slowly so that it can be translated more appropriately. But what we're going to do this afternoon together is try to predict the future. It's often hard to predict the future. However, in this case, it might not be so hard because we have some colleagues of mine from IBM, but also leaders in the open source and in particular open stack communities.  How are you doing? Good. Very good. So we have leaders in the open source and particular open stack community with us. And so the reason that I don't think it would be hard to predict the future is that these folks here are actually defining the future. They're defining the future of where open stack is going to go in the next six months, 12 months. But also, I think more importantly, working with a lot of you all, our clients, our partners on implementations. So for the next time we have, we will be doing that. So what I would like to do first is ask each of you to introduce yourself and then we will continue with the panel session. Sorry, I got to steal your mic here. So hi, I'm Monty Taylor. You may have remember me from such things as running around on stage in a awesome sauce costume this morning. But but also from being sort of in the open stack community and ecosystem since since the conversations where we were deciding what to call it. So I've been around, probably have met many of you in other times and thrilled to be with IBM. So I'm Jesse Proudman, founder and CTO of Blue Box. Blue Box has been working with OpenStack for I think three plus years. Blue Box was acquired by IBM in June. And as you saw in the keynote today, we launched our Blue Box local on premises offering yesterday. And I'm Mo Abdullah, and I'm actually part of the product management and strategy team that really works with OpenStack and the rest of the open cloud architecture building products that take advantage of those technologies. In some ways, my perspective is one of gratitude to the broader community because a lot of the products that we bring to the market leverage the collective. And then the other of course is the give back aspect, which is how we take a lot of what we learn from a commercial side and continue to grow and nurture what we're doing out there. My journey with OpenStack started from early days when we really understood the power of unifying the disparate, if you like, architectures and thoughts out there into one that brings multi clouds together. Glad to see it grow and reach the point it has so far. Hi, I'm Mark Jones, CTO at software focused on infrastructure. So we've been running OpenStack Swift for about three and a half years now in software data centers. And we spent the last nine to 12 months working on bringing OpenStack natively into software data centers. And so we actually launched our VM service yesterday in the London data center via Blue Mix. Yes, I know. Step one, it's a great effort across many teams within IBM to deliver that service. And that's the first of many announcements we'll have this year and well until next year. Okay, so I'm going to start with a very simple question. And I would like to ask each of you to please answer it within a two to three minute time window. I'm not looking at you. Is there a competition by the way? Yes, there is a competition. It's always a competition. I'm going to start from that side in. And the question is, can you give the audience one prediction as to where you see OpenStack headed in 2016? It could be a dimension around a particular project. It could be a technical dimension. It could be a client dimension, whatever you like. Let's start with that. So I'll start with the project that is near and dear to my heart at software, which is bare metal. And so that would be the Ironic project. I think in 2015, we've seen Ironic mature. We're seeing implementations of Ironic make it into production in everything from companies that are deploying application stacks onto it wanting the performance that you can get out of Ironic. And we're starting to see it now in service providers. And when we see the evolution of Ironic software, one of our core differentiators in the marketplace is bare metal. We've done that since inception back in 2005. And we are putting a tremendous effort into Ironic this year and into next year. I think when you see the evolution of compute now with containers, a lot of companies are looking to have near bare metal performance. With the ease of use and management of containers. And so Ironic is going to be a project that's going to evolve quite a bit in 2016. Thank you. Mo. My prediction is that next year we probably will see an incredible amount of growth in clients who are going to be talking about their stories, leveraging open stack in production. We'll go from simple hundreds to many hundreds who will freely share in Austin and conferences after that. And some of the drivers behind it, I believe is simply the maturity that the community has taken the technology forward from simple discrete components to things that can integrate together through services like heat. So as my team, for example, and many of the leaders in the room sitting in here, start to build public cloud services. They're starting to leverage things like Neutron and Swift and others and put them together in patterns that serve the end consumers in applications. People will start to talk less about the individual services and will start to talk more about how they're putting them together to deliver specific client value. And I think people like IBM and others will come forward and start to talk about our journey and in the way we're standing up, highly scalable, globally distributed services that are in their core and in their heart built on open stack. So thousands of stories and much more oriented around combinations of services. Thank you. If we were on the prices right, I would say there's thousands plus one stories and I would win the car. My prediction is that we'll begin to see different compute primitives exist and be supported and open stack more natively. So Nova has supported VMs and done that very well for a number of years. Certainly with ironic now as Mark mentioned, we've got bare metal and you see the transition from Nova bare metal now to ironic. And we're seeing the same thing now with containers with Magnum. So you had Nova Docker originally now Magnum. And I think there's something very compelling and powerful being able to abstract bare metal VMs and containers all within one set of APIs, one authentication domain, one network with the work going on in Neutron. And if you look at many of the application patterns that are being deployed, it's that combination of services bare metal for IO databases, et cetera, containers for certain aspects and VMs that make up modern applications. And I think that's where that's 2016 will be the year of support across the board from a production perspective of all of those capabilities. So I couldn't agree more with all of those things, which is why we're saying also you're all right and I'm going to add something else on it. So that's my 1000 plus one story there Jesse. But I think the key word that already sort of came up that I'd like to focus on is the global service part of this. I think in 2016 we're seeing the things we're doing with SoftLayer VM and with Blue Box and SoftLayer, the key part of that story is the global footprint of that. So as we look at public cloud service and we look at managed private cloud services for people, it's not just about having a data center in Dallas or San Jose, it's about having a data center in Singapore and in Sydney and all over the world. All of us, there's more people in the world than not in the US than there are in the US. And so the highly US centric nature of the offerings that have been out there so far, I think we're going to start seeing the real power of a sort of global first approach to public and managed private clouds. I'm going to be really excited about that. This is in this short amount of time you all have covered four amazing topics and I think we should write this down and check it next year. But think about it, the power of bare metal applied to a variety of programming models because of the utilization that you can get, the performance that you can get. We've proven that out in our SoftLayer model already and now it's going to be to the masses with the work that we're doing around it. Mo brings an amazing point around moving from atomic elements to composites of elements. I mean perhaps even our OpenStack marketplace might evolve to a pattern marketplace where there are literally hundreds and thousands of pre-built compositions that can quickly be provisioned, managed across compute, storage and network. And then of course the confluence. This morning at the keynote one of the points that Jesse and I made and Jesse made in a much more detail here is literally in cloud there are three centers of gravity right now. There is OpenStack, there is the cloud native computing foundation containers and then there is Cloud Foundry. And if you think about it, OpenStack is the basis, compute, storage and network. And then there are two fundamentally complementary application programming models that are changing the way folks develop applications. One, Cloud Foundry, a polyglot approach to building applications quickly, systems of engagement for example applications and then microservice based on containers. All using the same substrate. I can certainly tell you that these folks here and our colleagues in the community are going to be working really, really hard to ensure that all of these things come together. We will not duplicate in say the cloud native computing foundation network services we're going to use, Neutron for example. Same thing in Cloud Foundry and everything else. So I think that's a pretty state. And then of course globalization is a necessity. You know the era of the mega data center really is dead. It is about having data centers fit for purpose where you need it. Dedicated across the globe. We certainly are clients. You all have demanded that. We've been doing that. I think others are starting now to try to catch up there. But it is a huge deal. Those are four very, very solid predictions. Now what I'd like to do is offer up some perhaps more controversial or less controversial predictions and ask you all to debate them. I got some questions from the audience prior to this. No I didn't. I did not. I do have to say though I wish Sean wasn't sleeping over there. Thank you. He's distracting me. First question and what we've heard this theme several times and that is the distribution is dead. Okay. Discuss amongst yourselves. Jesse you have something to say about this? That's my tagline so I'm not sure I have a whole lot to say but actually I do because that's what I do. So look open stack is a challenging set of technology. It's challenging to operate. It's ever growing and expanding the velocity of new projects and of the complexity of those projects. It doesn't stop and it won't stop if we are going to continue to maintain relevancy in this marketplace. And if you look at software and you look at software distributions and Linux distribution the blast radius the amount of failure that you can tolerate when one server goes down it was much smaller. A single system may have contained a database or a application server and that was fine because if you designed your applications in a certain way you could tolerate that. When your cloud goes away for many organizations that's their entire business and so selling software that pushes that operational burden onto a customer is unreasonable. If you look at the growth and open stack from a revenue perspective and where most of the installations are actually occurring it's from a service provider perspective. Because we're centralizing the expertise that it takes to track these projects install these projects operate these projects and upgrade these projects into one central provider. Further you get this concept of a network effect where for every failure that does occur and they do happen. The learning from that failure the fix from that failure gets pushed out to every other customer and can be pushed out in real time in a managed service model. And that's something that just doesn't happen with a software distribution and so from from my perspective and I am mildly biased. I believe that the services model delivering open stack or private cloud as a service whether it's in software in a dedicated approach or in a customer's data center with our local offering will make customers more successful and make that success occur faster than with a software distribution. And I've I've not found anybody here who can argue that with me. So if you disagree come argue with me. I'd like to agree and sort of poke in a mildly different direction to we look at things like like Docker and the work that's that's going on there and and and you look at what the developers are doing with their applications. And most developers these days like even outside of cloud they're not focusing on delivering Debs or RPMs of their of their software they're delivering Docker containers delivering that application that that they made in a in a consumable form. The the the sort of distribution model we've had for the last you know 15 some odd years has worked well for us. It's been a it's been a it's gotten us where we are you know. But it's predicated on the idea that you're going to have a number of pre a number of building blocks in the distribution. You can sort of mix and match and install any of them you want to. So you can say after get install XML server and and then also a postgres database and and a whatever and those should all kind of work together and you can expect that one of them installing one isn't going to break another one and that's that's great. But to Jesse's point the software really caring about these days is way more complicated than those tools really really give us the the the benefit to to get so I think even not only in cloud is Jesse right. But even just as we're looking at how people are developing software targeting that software being inside of a distribution isn't it's not how people are thinking it's not how people are thinking about solving the problem because it doesn't it's it's more overhead than than it is for the help. So I think that the reality is we've seen this transformation between traditional software that is purchased to software as a service right that transformation occurred delivering cloud services or open stack as a service is no different. It's the same models it's centralizing that operational responsibility into a single party. And I think the conversation changes frankly not that it's not a point of debate it's a point of agreement around SLAs and really it's not about the supported model in which I'm going to get a distribution but it's more around what SLA am I going to get how can I work between providers it's not dead fully yet as we agree because it's a journey but it's dying it does not lend itself well to the go forward model. Okay well you know it's you know by saying the distribution is dead doesn't mean that private cloud is dead what it means is that you want public cloud capability if you want on the public cloud on a dedicated or on premise locally right and you've coined the term you know private cloud as a service right whether it's on premise or dedicated you know the blue box local that you discussed supports that model I encourage you all to try it it allows you to more quickly get time to value. We have some relay technology which makes it very easy to do that and I do fundamentally believe that this is another layer of abstraction. We think about computer science for a moment if anyone here is a programmer you know there has been a constant democratization of technology we don't program an assembly language anymore right we don't strictly right define you know we just we don't use methods I mean sorry functions all the time we use classes and objects and we expose data right for those of us more sophisticated we might even do inheritance or multiple inheritance right service oriented architecture is object oriented network we don't debate that right there is a democratization of technology and it's happening again now and I think the quicker we do that means the quicker we can add value right and that's what we're here for we're about innovating on things. So another question I have here that that I'd like you all to debate around the future is around interoperability one thing that I'm very proud of and I know you all too is Catherine is our PTL for RefStack for example she's been doing a great job and this is about interoperability and how do you see this playing out next year both in terms of what we actually test okay because right now it's not as much as it should be and in terms of people stepping up to actually adhere to these things. So we've got a we've got a saying in in OpenStack which I think originally came from Russell Bryant but which is that if it's not tested it's broken right and and one of the things and one of the reasons that the RefStack effort has been so important is that it gives us an opportunity to to be able to test and vet what people are doing with their clouds and also a way to express what behavior we expect them to do because we did create a flexible, pluggable tool for for people to use and and so it's it's not unfair for people to have made some different choices with it we we kind of we kind of built it that way it's pluggable but but that same time that that now needs to come with a thicker instruction manual a so yeah you can do anything you want but actually here's some things that are really important that you that you keep in right. Right these are these are things that our users are going to demand to exist and some of this is things have changed since since five years ago when we started off there's a session about glance image uploads tomorrow in the design summit and one of the things in the in the in the write up for it the guy who's is leading the session talks about when we when we first envisioned glance no one envisioned it as an end user service they envisioned it as a service that Nova would talk to to manage images and now we've all realized no that's actually really important cloud without image uploads is useless right it's not a cloud that's that's new information and all we have to encode that ourselves and also make sure that we're telling everybody that's running a cloud no this is really important seriously and most of them once we're really clear once we make a really clear statement about this is an expectation almost everybody is has been really interested in complying and in making sure that they're everybody wants their product to be something that users can or not operate with like that's that's what we're all in this game for and so I think that the work we've been leading there and the work that that is continuing to move in that direction is is absolutely essential to empowering all of the people in in our ecosystem to play by a set of rules that that's that's beneficial for all of our our users and customers. So I agree with Monty and I think from a product perspective if you look at it in a mark reference the the object store beta. If you look at what clients are trying to do is you can never box any of them into a single pattern. Different people are starting from different points and one of the things that are unique around object store and the ref stacks and the compatibility is also at the API level is they may start with building applications that take advantage of an object store and they're testing those in a market and then they decide that they want to geographically expand. And this is a true case in several of our clients who decided to expand into Europe. Now just a simple you know privacy rulings etc dictate that their application now needs to talk to you know local object stores that whole idea of being able to point your application away from a public object store right into one that may be running inside of your own data center managed by Blue Box then you know without you know changing the application logic etc and with speed is very powerful very compelling. I recall actually the concept of this we did about six months ago in Vancouver and I recall everybody laughing at me and going more this is like so simple. Like this is even more simple than somebody shooting crocodiles you know on the screen and I was just like but look it is so simple but powerful and the room was full with people who are saying that's exactly the type of scenario we want to enable. And then you extend it further into different application styles. So it's you're building these applications based on containers virtual machines. How do you actually recompose those in different environments. You know I think one of the things that that's challenging. It's both a pro and a con of open stack is that it really is a Swiss Army knife. There are so many projects and with this big tent initiative that that number will continue to increase. And that becomes a challenge to the cloud operator whether that's Blue Box whether that somebody has bought a distribution or somebody that like Walmart or eBay has decided to do it themselves. You know I think that the key notes on Tuesday from Bitnami where they were saying it's very difficult to figure out that consistency of services from cloud to cloud. That's going to be a problem we continue to see because of the flexibility of open stack because each deployer can choose the projects that suits what they're trying to do. And while I think a huge fan of ref stack the reality is having consistency in services across every cloud it's a challenging proposition. And so that's where I think beginning to see providers in the marketplace that have all three consumption methods that have a public cloud or dedicated cloud a local cloud public and private and having all of that speak the same technology. You can get that from one vendor and there are a few vendors in the market that can do that as of January 31st. There's one less but there were a few that's really important and it will continue to be more important as we add more projects into open stack. Thank you. You know I encourage you all to demand the expansion on ref stack to demand the expansion on what we define as interoperability. Todd why are you smiling. Todd's on the board for us here you know so he's been carrying that flag for us.  I'm a little tired I apologize. I ask all of you to demand that the expansion of ref stack and also to demand to your vendors whether it's IBM or anybody else that they adhere to that because interoperability is going to allow to succeed. You know our job is to make all clouds behave as one not just IBM's but all of them and that's how you get the time to value you need. This next question is for Mark and for Monty or anybody else but I like to start if it's okay with you too. So let's put a silencer on you in the middle. And the question really is you know it amazes me when I wake up and I see open stack available and what we're doing at a global scale. Okay 40 plus data centers across the world is unbelievable. Not just global scale but scale scale. And you know as we do this we find places in open stack that need to improve that need to change in order to actually manage the scale that you and you are driving together for our clients. Can you give a prediction on some of the areas where you think we might have to change a little bit some of the architecture based on our experiences so far in doing this. Yeah so I think in the work that we've done so far that we see an area for improvement is going to be Neutron. We start talking about scale and performance of the network it is the key linchpin of everything that we do in cloud right. Everything rides on the network and that's everything from initial provisioning to configuration to throughput and resiliency. And so I think Neutron is at least from where we are today is the one that we see a lot going into. But I think you can apply it to every project. We start talking about as Angel mentioned we've got 40 data centers. We're initially targeting three data centers for software deployments or open stack but we will extend it to all data centers. And that becomes global scale. And within each of those data centers you have to have full scale up and scale on capabilities. And that's a large footprint and customers demand resiliency. They demand uptime and performance. And so I think that every project is going to we're going to find stuff with every project as we go. But for my standpoint I think Neutron is going to require a lot of work. So a couple things. One I actually want to point out a thing that also happened in yesterday's cross project design summit session. One of the design summit sessions is there was a session on starting to map out supporting the extreme use cases as they talked about it. We were really good at 100 node open stack clouds these days. But doing you know say a million node open stack cloud not maybe not so much. And then also for the sake of that that conversation was also a question about should we also be focusing on one node. You know supporting people who want to do one one node things. Nobody in the room actually various their hands and said they're really interested in the hyper small scale. But it's worth asking the question to make sure we've got use cases. But everybody basically signed up to agree that supporting actually supporting the the hyper large size things is is an endeavor that the technical community does think is is important and agrees that it is a thing that has to get attacked. So that said things that I think that are inside and I apologize to anybody for I'm going to geek out on YouTube for just a second. I because I think that the things that that we're going to have to attack are actually seemingly very boring non sexy internals bits of of all of the services to Mark's point. It's not just one or the other because we've only been focusing on on. We haven't been focusing on 100,000 node A Z's than the challenges of resource management and consistent cluster management of the resources that open stack. Manages has been left as an exercise to the to the deploy right. It's you would give you a bucket of parts and you you can do the thing that you need to do and that that's fine to a certain point after a certain point. We've got to have more primitives inside of open stack to allow the deploy or to even manage to keep up with it. So we had a we had a great session yesterday on distributed lock management which is probably going to put half the room to sleep here. But a great great session on distributed lock management and using technologies like zookeeper as a fundamental building block for doing resource management and leader election. These are all things that are that are only partially looked at inside of open stack right now. And so this is we've got a couple use cases but this is going to this ball is going to start rolling faster and faster forward. So getting those things turns out scale and manageability kind of kind of go hand in hand if we just throw 100,000 machines out there and the operators can't keep up with what's going on in them. Then it's you know, it's a it's a it's a it's a lost cause. So these are these are areas where we're really going to stick a lot of energy and make sure that we're we're enabling us to get to those to those next generations, you know, orders of magnitude of scale. And I think that, you know, a lot of the talk is around workloads and the type of deployments that we're going to put on to open stack. But when we look at these these large scale deployments, there's a huge difference between running a public cloud, multi tenant service built on open stack versus running an application that you're able to fine tune and architect to meet the needs of application. And so as we as we go global scale, as we go these incredibly large deployments that are multi tenant, we learn new things that you don't necessarily find as part of an application deployment. This is critically important. And I, you know, I ask you all to take note of that because there will be some exciting changes as we really transition open stack from thousands of nodes to millions of nodes. Okay, so I'd like to end the panel with one question for each of you again. And I'd also like to ask the audience to take your phones out and use your favorite social media device, whether it's Twitter, Instagram, whatever it is you want to use. Snapchat. Snapchat. And, and, and then tweet out your favorites. Tweet out your favorites. Your favorite thing that you heard, but make sure that you do it to me at Angel Louis TS. No. Just kidding. No, no, no. And here's the question. You get one to three words. That's all you have. I'm starting with Monty should be very easy for you. Don't worry. One to three words. Describe the future of open stack in one to three words. Globally ubiquitous. Jesse. I don't like this game. You can phone a friend. Would you like to phone a friend? How about you think about it? I'm going to think. Mo. Invisible. Oh, invisible. Very nice. So ubiquitous. Similar to. Transformative. Transformative. Pain free. My word is awesome sauce. I'm just saying. Thank you very much for attending. Thank you to our panelists. Thank you folks for taking the time. Thank you for coming. And we will see you all. Thank you. Bye bye.


So today we look at another secret weapon, this one called the Digby's Smooth Tube. And while this weapon can actually play tunes, like what? How's it going guys? My name's DPJ and today I've been in another Borderlands 3 video. If you do enjoy it leaving a like, it really helps me out and subscribe if you want to see more. On screen now is my usual weekly giveaway along with last week's winner. To be with a chance of winning this yourself, maybe for a friend, whoever, follow the instructions on screen now and good luck. Okay so this assault rifle actually isn't as bad as I actually thought it would be. Only being an epic but at the end of the day we've learned rarities don't really mean anything in this game. But being an epic you wouldn't expect it to offer the benefits it actually does. With its decent damage of 635, great accuracy of 82%, a kind of average handling of 59%, a 2.2 second reload time and a fire rate of 6.77 with a magazine size of 24. After incredible damage it can swap between full auto and a 3 shot burst. How cool man, hyperjazz is hyperjazz. So this assault rifle upon first using it I was surprised at the tone of the shots actually being of a jazz instrument. Now I don't want to mention anything else to do with this weapon and tune its plane and so forth because I don't want to spoil it for anybody who hasn't done this mission to get this yet. I know it's early days into the DLC and this is obtained via a mission and the mission is actually a really good one. But it sounds super cool nonetheless and actually guys it's actually quite an important weapon. It's 110 trial efficiency is serious, perfect for Sub-Zero's aim builds. Well it's its accuracy and projectile speed in which I love most about this thing. I'm so used to using weapons which shoot all kinds of craziness going back to what almost seems to be an ordinary weapon feels great it really does. So this weapon the Digby Smooth Tube is a mission reward in which you start by going to see Digby who can be found within the Spendopecans Vice District on the handsome jackpot. Now I'm not sure if I pronounced that correctly I probably didn't I normally don't. The mission is a free part and it's actually one of the cooler missions like I said this DLC offers. This weapon is this mission's reward you get it after completing part three along with some cash. So go and get this thing people and play yourself a tune. It's actually not a bad weapon to be honest I mean the only downfall with it is is its mag size of 24. If this had a bigger magazine size I know you can increase that with serious builds and so forth but even still its magazine size does fall a little short and that's the only thing that's really in reality negative about this weapon other than that's actually a decent gun. It's one I do at least recommend you try it out. It's definitely one for the collection even if it's just a novelty item. I mean this thing plays a tune when you shoot it. Yeah may as well get it people. But on that note we have come to the end of the video if you guys enjoyed it leaving a like really helps out if you're new around here and want to see more body language videos be sure to subscribe and if you never want to miss a video where I upload content notifications I'm by hitting that bell button. But guys thanks as always for stopping by hopefully you enjoyed the video and hopefully I will see you on that next one.