Okay, hello. I'll start again. So, yeah, so for the past few months I've been doing some privacy research. So yeah, so one of my first ideas basically was to implement a sort of ring signature based mixing contract on Ethereum. That's just like a simple proof of concept of privacy. So yeah, so basically a ring signature is, so normally when you sign a transaction digitally it's signed by one public key. So you know that the signature came from this person. With a ring signature, a signature is created using a group of keys. And then only one member of the group actually creates the signature. But then when the signature is informed you can't tell from the outside who signed it. So basically, if you decide a transaction this way instead of with just your own key, you'd be able to like plausibly deny that you were involved in the transaction. This is part of the way the narrow works. So, yeah, so once we have that we can implement a mixing contract using these sort of alternatives. So the idea of the mixing contract, I have rough code for this right now but it hasn't been tested. So the rough idea now is that a user would submit a public key to the contract as well as a deposit. The deposit is a fixed amount of either as well as fixed ring size currently in the contract. It's probably going to be set to like 11 because that's what scenario uses. Maybe 12 just because it's an error. But so that after that amount of people has submitted a public key and deposit to the contract, then we're able to pull that list of public keys from the contract and create a ring signature from that. So the initial public key that's submitted, it could be that the receiver of the transaction has the corresponding private key. So you would perhaps talk to the receiver beforehand. There's a few ways that this could go. This is the one way. So you can plausibly talk to the receiver beforehand and just be like, hey, it seems like a public key. They send you a public key.  Then once the contract has been filled with public keys, the recipient now has the private key of one of the keys in the ring. They would now create the signature signing off basically saying send me the ether that was deposited into this contract. And then every recipient for every sender would be able to do the same thing. Or alternatively, the sender would know the private key and then they would create the signature and then know if either should be in that they could withdraw from the contract. So yeah, that's the basic idea of how it works. I'm going to look at some kind of after talk about some things. So yeah, so the first issue why this hasn't really been implemented yet is because the ring signature is super large. So you can't actually store a ring signature with more than around five members on a contract right now without running out of gas. So you can't perform the verification that we needed to implement this contract with enough ring with a larger ring size that would be actually useful because if the ring is too small, it's easy to sort of backtrace and see, like sometimes backtrace and see other. So a possible solution. The first one was to just create a pre-demo contract that would verify our signature and then kind of actually maybe push the sub-stream. So yeah, I put it into that and it seems to work so far, which is cool. But for top to work, it might have to be pushed up to take a very long time. So yeah, so another solution I'm thinking of is to just use the BN 256 pre-demo files and hopefully that will reduce the gas costs. So yeah, so create a signature so you can't create a signature on-chain. So you have to sign an off-chain and then do all the verification on-chain in the contract and as well as how to protect double-spends. So similarly to having an error done, you would prevent double-spends by using linkable ring signatures. So this is a variation on the original ring signature for algorithm. So linkable ring signatures basically adds another key image to the signature. So the key image is an off-the-chain image of the person who actually signed it. So you can't actually tell who signed it from the key image but you can tell if two signatures have the same key image that they were signed by the same person. So basically this will prevent a double-spend by saying if you're trying to submit a signature to the contract again but you only submit one deposit, then like, no, you can't do it. So some extensions to this that I was thinking of. So I think one of the really cool is just generalized transaction privacy. So right now we think of mixing it to think of like Ether or some sort of monetary value but with Ethereum you could extend this to not just the Ether value transaction but to the call data, since what's happening in the mixer is basically that you have like a transaction and then this transaction gets signed as a ring and like it's submitted and you would fit instead of the value in the transaction you could put some stuff in the call data and have this execute you. Yes, that would be really cool. But that would be an issue if you think it's for us, that's a good thing. So, yeah, so this would allow private contract to come to calls or private contract to come to us. Yes, and also probably one thing, because as I mentioned initially the contract right now needs a fixed Ether denomination amount because basically if you allow people to just send whatever amount of Ether they want to be contracted they would be able to link the side of the recipient. So value-winding would be like pretty cool I think. So I was thinking, I would just start making of this so basically using something similar to how an option transaction works so just using commitments to allow people instead of the actual transaction but then this would somehow need people to keep track of all their values instead of all the chain of questions. Yeah, this is some research. So, yeah, that's basically it. If you want to check out the code I've written so far it's all there. I have mixing contracts and I go with a presentation of my course and bring signatures. See ya. Yeah. Forgive me, forgive me for how superficial this question is. But as an end user who cares about privacy how would you compare and contrast ring signatures with something like a CK Snarks? Because I know a CK Snarks I think like only 15% of exchanges actually implement CK Snarks so what is like the pros and cons to ring signature as a CK Snarks? Thank you. Okay, so the CK Snarks works by basically hiding, you prove that you have some sort of hidden value to a contract or whatever. So this doesn't really hide the link between a sender or a sypian of a transaction. It's used for things like hiding value, could be used for hiding a sender or sypian but it would be a bit more complicated than that. So yeah. Sorry, I'm also really tired right now. I'd like to go off in like six hours. Yeah. What do you think in terms of exchange of this use? I think it's like as an end user. Yeah, yeah, yeah. So we know that the basis of how a ring signature works is like a mixture of the different keys and no different CK Snarks is using like zero nulls proofs. So you know how you see two things work. As an end user, how do you choose which would be best for you in which circumstance? Let's see. Okay. It really has a good both quite powerful, you like when I was based off more of like what I'm describing like a ring signature based on my social interaction based survey and then CK Snarks and like they're both secure I would say. So yeah, as an end user it's really, I believe the CK Snarks are larger. I think. Yeah, yeah. Yeah, it's really, it's really up to you. To be honest, I think as long as they're both valid and transparent, they should be fine. Yeah. Any other questions? Do we have a small question? Hey, thanks for your talk. Just an observation you mentioned about the transactions, if it will become a code data and who is going to pay for the gas, etc. Yeah. Just an idea is just a meta transactions here can have in a way like just to have a layer who will pay for that one. Just like you can consider maybe like as a solution just to have a meta transaction concept into that place. Like EIP 1077 is actually describing how it can be handled. Yeah. Then in case like whoever is coming with an executable transaction can receive a return back. Okay. So we're asking about the, like if you said the pay for the gas kind of. Yeah. So yeah, I didn't think you would ask. Yeah. Like what you said, basically delegating someone else to somehow do it would probably be the best bet. Because if you just submit all your stuff to the transaction, it's pretty obvious that it's like you.  And when you have to trust it, just like you want them to like do it kind of thing. Yeah.


That's how it just hit but my musical influences, if I have any, would be a wide variety, like I go back to saying like, Devin the dude. Man, that boy was dope in the day, but he didn't even ride them, but I love this little cadence style. It was real simple, but he's deadly, right? You know my favorite song for him, it was 10 Day. Which one? 10 Day is plenty man, and it's better than now, nothing at all. Your top three artists of all time did a lot. That's hard, man.  That's hard. Any genre. Come on now. You got to give it up, give it up, man. Hey, shout at the hell, you got everybody that's been on this platform. Number one, see, all genres. If it's Johnny Cash, nigga, go on and see it, if it's, a million, a million, a million things went through my mind, like I can't just narrow it down to three. I know it, but that's why we, that's the reason we asked the question, right? Let's go ahead and knock some people off. All right.  How you feel today? When you say different genres, so what I'm gonna do, I'm gonna go different time zones with you. Exactly. All right. Pop. Pop. That number one. That number one. Andre 3000. Andre 3000 is number two. That number three. That number two. That number three. That's dope. That's dope. That's dope. Let's see you come up with a future like that. I don't know. I don't know. Only three. You see what I'm saying? I feel like I just limited my situation way to cut. But for real, I don't mind three. He's sorry. He's sorry. Look, look. What's she saying? He's sorry. Oh, yeah. I'm sorry. I didn't mean to pick you. You didn't mean to get in there this time. But that's just how I just hit but, but my musical influences, if I have any, would be a wide variety. Yeah. Like he go back to saying like Devin the dude. Man, that boy was dope in the day. You didn't know what I'm saying. I didn't even ride them. But he, I love this little cadence style. It was real simple, but it's deadly, right? You know my favorite song from it was Tell Your Day. Which one? Anything's plenty man. Hey. And it's better than nothing at all. That's just what I'm saying. Hey, they had a lot of hits, dude. And he had, you know what he had, baby. Like, you know what I'm saying?    I don't know how I stumbled across the E4, but you know, the Devin the dude's Trader Truth motherfucking zero. I mean, she done thugged. Out of, you know what I'm saying? The West Coast, Ice Cube. Yeah, I was just with his people. Matt Tien, Doug C. Goddamn Snoop. You know, like I can keep going, Nate. Like I can go all the way, bro.  And that brings up a question because the vibe y'all give, it's almost like a rap R&B-ish type like feel with the ones who can, who sing, you know, and like I said, Rye Wave, man. It's fly the way you flowin', bro. Appreciate it. You know what I'm saying? It's fly, bro. It's fly, man. And it's the new thing. That's real. It's the new thing. It's really going down. No, it is.  It's not even rappers or anything like that. I'm cool with that.  So how did you come together with Maree? Oh, Maree, man.  Anybody I ever did with is R.A. Organic. He had hit me, I think, DM, or I DM him some kind of way, whatever happened with DM, shit, with stage numbers.  There you got going. Nine chillin'. So I bet that 100 are checkin' on your B-side trust name. Know what I'm saying? Here it is. Bro, what you got going, bro? I hit back by cookin', look.  Before I was cookin' on the TikTok, I was like, look, bro, cookin' and shit, man. He was like, damn, you know, lookin' like things. Givin' around that motherfucker. Shit like that. Like, just regular on what come over. And I don't know, bro. I sent, one of us sent something to each other, and the other sent the other back. And we been locked in since. Like, I just hit him the other day. I went, sorry to come in on my, bro, push up. You know what I'm saying? Yeah, yeah. Yeah, that's good to build those relationships. Because some people you click with, some people you don't. And that's a thing. You know that, right? Like, you didn't just cause a nigga in the lane that you in, don't mean y'all going to even click. Nah, that's real. I done met some people that I thought I was going to like that I didn't like. Do you think that I have a cousin for you? Do you think you ain't like him because of the people that you did click with or the people that did put that type of vibe on you? I just thought these were people that I had seen and I thought it'd be like me seeing you today and like, damn, it ain't what I thought it was going to be. Okay, yeah. You see where I'm coming from? Yeah, yeah. That's where I was coming from with it. I done met some of the dudes I looked up to and looked to and thought was stand up and when I met him, it was not that way, bro. Oh, yeah.  I done met a new girl over there.  Because everything we do, we like organic. Yeah. So when you meet somebody you wanted to just mesh and everything just flow. But sometimes when you meet somebody is like they just stand off or they don't speak or you know what I mean? Weird nigga. I hate it. It's weird. Like too much and like, like, like, like, I think you got an attitude. Nigga, you try to play him. Yeah.  I don't have that. That's all you think. All that. Really. That don't really don't move nothing because it'll make you feel like nigga, nigga, you ain't bad in my mind. I think I'm bad. No, I don't need that. I think I'm bad. I was like, man, it's nigga. Yeah. I'm like, maybe I'm really too far into it.


I love the energy here. Just being around people is intoxicating. It feels so good to interact, to have a conversation. It's exciting. I'm seeing a lot of my friends from Twitter in real life. I'm absolutely loving it. I'm really excited to listen to people speak after me. I did a little early speaking. One interesting takeaway was talking about insightful data, paired with cultural moments, creates impact, and Twitter is doing a great job at that.  I was really interested to hear about Alexis and to hear about the creator economy. I think individualizing and making it really personalized is something that's really cool. I think that's something that I try to focus on every day. Networking is amazing and incredible. And then it's the opportunity to share with other practitioners and those that are sort of learning, but things that you learn from. And I think those are absolutely essential to me being able to do my best work. If you walk away from an event like today and you take away two or three things, it's a success. It's great.


This is silly dude. It's been sitting for a while one of one Jumbo laundry tag auto of each hero Oh Baby That goes to the Miami Marlins sweet Mama Jamma right there. Oh my goodness Marlins It's a long shot for the Marlins and some of these breaks Dude Marlins and Brewers hitting one-of-one laundry tag autos are like a logo man auto love it love


You guys ready? How you guys doing? Thanks for hanging in there. I know it's late in the day. You guys are probably eager to get to your beers. My name's Gretchen Curtis. I'm a co-founder and chief marketing officer of Piston Cloud. And this is the press and analyst industry perspectives on OpenStack. So we did this panel about six months ago at the last summit. A couple of the panelists here are old-timers. So why don't you guys go ahead and introduce yourselves? You want me to start? Yep. Hi, I'm Gary Chen. I'm a research manager at IDC. And I cover server virtualization software and cloud system software, which is what we call stuff like OpenStack. I'm Sean McArna, I'm a senior editor of internet news, which is part of the Quinn Street Enterprise Network. Right for a pile of publications under that name and write cloud application development, Linux, open source, networking, and security stuff. I'm Stephen O'Grady. I'm the co-founder of RedBunk. And probably on the panel because I cover cloud and I know the things. I'm Alex Williams. I write tech crunch. I cover the enterprise and a lot of cloud stuff. So before we get started, can I see a show of hands, how many developers we have in the audience? OK, a few. How about users? People who are here, OK. How about vendors? Vendors, all right. OK, so the last time we did this about six months ago in San Diego, we covered a number of hot topics at the time, including governance. We had a newly formed foundation at the time. We talked about the hype of OpenStack, specifically the high degree of marketing maturity relative to the technical maturity of OpenStack. I believe the saying was the proof is in the pudding.  So we also talked about concerns about community infighting, concerns about the involvement of large corporate players with competing interests getting involved too early in the project. But mostly we talked about two things, which was the lack of users and customer stories and the immaturity of the technology. So six months later, Grizzly is out. The foundation is strong. Community is thriving. Governance is working. Hype is still high. But as we saw this morning, we now have a large number of customers using OpenStack in production in lots of interesting ways. So if the proof is in the pudding, I think we can agree we've seen a lot of pudding. So now what? I want to ask you guys, what's the buzz you guys are seeing now overall? Positive, negative, a mix? The buzz is, I think it's still pretty great for OpenStack. There's not a lot to lose at this point. I think just from my observations, it's going, we're moving closer to what will become, I guess, somewhat of a horse race. But there's going to be so many different kinds of clouds up there. I'm not sure what kind of horse race it's going to be. Much more focus on money and how VMware is going to get this place. So I think I would agree with most of what Alex just said. I think from my perspective, I think that the buzz, or at least the important buzz, is on the continuum of the project. And certainly we've heard from some users this time around, or at least more users, which is a good thing. I think the really the question, or the buzz around the question that I hear, still concerns fragmentations, still concerns the number of competing interests and agendas. Because one of the things that's beginning to happen that you see is that a lot of vendors, and even a lot of their customers, are beginning to understand the stakes involved. Which is, look, if you do not have a credible strategy, you do not have a credible vision of where things are going from a cloud perspective. And more importantly, you're poised to get there. You have a serious problem. And therefore, we're seeing vendors scramble to find their footing. And that will make for a very interesting environment in the OpenStack community moving forward. I see the buzz, and I agree with everything that's been said so far, so no arguments yet. I think the buzz is even greater now. Six months out, if we did a Google Zoom case and somebody in here probably can in the next five seconds. The volume of OpenStack stories that I've seen in the last six months increased. I have not spoken to anybody about cloud in the last 180 days in which OpenStack was not part of the conversation before it might only have been 80%. And the risk that I see as people talk, and I know we might talk about interoperability or security or other things, but the standard risks that are associated with any cloud, not necessarily OpenStack. And that's what I hear on the buzz side. Yeah, I think I agree with everyone. I mean, in terms of community, the software itself, the foundation, all of that momentum has continued at an extremely fast pace. I think we have seen more users. I think it's still confined to certain use cases, certain segments of the market. I think a lot of the focus this year is kind of how do I take it commercial? A lot of vendors coming out with products. How do I get into enterprise? I find that there is a lot of recognition of OpenStack within the enterprise. And so they are interested in the platform. I think the majority don't know that much about it yet. But I think that's likely to change. And I also think the private cloud, I think everyone's going there, but I think what I've seen from enterprise is that I think people are expecting it's going to happen within the crash of the market is coming. So they have to be patient. In your view, what are the most exciting new technology developments happening at OpenStack right now? And six months ago, we talked about what's there versus what's still missing. So what's still missing? Well, I guess the things that I hear, I don't really actually hear too much about things that are missing. I mean, there are things that are missing, but I don't know if it's something that's just not solvable over time. So there's cool networking stuff that's going on, cool storage things. I talk more to enterprises than a lot of service providers. And enterprises are kind of more or less asking for some of the VMware features that they've been used to. So shared storage, fiber channel sands, and live migration. Some of that's starting to get built in.  So, you know, I think they're coming from kind of a different expectation from features. But, you know, I think the really the biggest thing now is really not that features are going to be the big blocker, but that what you really need is to make it accessible to a wider market. And that's really making it easier to consume, easier to install, get skills and training and documentation. I think that's really the big thing on features, but features are always nice. For me, last time we were here, we talked about, you know, Quantum that just came in as a project. And now I know that Foundation wants to just rebrand it as open stack networking. Good luck, because everybody knows the name already. But in the last six months now, Quantum has gone from being an idea to something that every major networking vendor is now basing their plans upon. Even, you know, this week, Juniper and Juniper six months ago, they were in the cloud stack camp and there's no cloud stack people in here. And there won't be in six months either, because it's going away, because that's one thing. That's a thought. And then there's everything else that's associated with that. And I've had the chance to sit in a few of these design sessions this week, but load balancing as a service, which I know is in Grizzly, firewalls as a service is remarkably a brilliant idea. How it gets implemented I think will be very tricky. DNS as a service is incredibly interesting. And then some of these other emerging ideas that I see, I think tomorrow morning we're going to hear about Red Dwarf Database as a service from the HP people. There's a spoiler alert for those of you in the audience. Brian Acker is going to be talking about that, the guy who helped create my sequel. So I think there's a lot of excitement to come. You know, I think for my part, you know, the difficulty of the question is that, and this is going to sound funny, coming from an analyst, but I say this all the time, is that in the technology space we spend way too much time talking about technology, period.  I mean, you remember what that project was like? It was terrible. You could not, you know, you couldn't upgrade from one version to another. Things didn't work. You know, pieces that were completely absent. You know, and yet we're all still here. We're all still in this room. So, you know, to me, I think, you know, Gary raised a great point, which is, when we look at the sort of list of, you know, sort of technically inferior solutions that have triumphed over technically superior solutions, that's a really damn long list. All right, so, you know, yes, there are sort of important technology considerations here, but the most important thing to me is going to come down to packaging, you know, essentially the, you know, streamlining the install, sort of upgrade maintenance, et cetera, process. Because, you know, so much of adoption, so much of usage comes down to convenience, not features. I guess, you know, one of the things that I'm looking at through is the perception of what the customer is thinking about right now, and, you know, just in talking with vendors and analysts and listening to some of the customer conversations is, you know, they're fully virtualized, they're up to like almost 80%, and now they're trying to figure out what to do next, and there are some that are going towards, you know, target adopting, be cloud director, but that's a, that gets very, very expensive. And so now they're starting to look at alternatives, and still there's that issue about OpenStack and its complexity, and how do you really adapt it to your particular needs, but they're just trying to weigh what to do, because in the meantime, all their product groups are starting to continue to use the public cloud, Amazon Web Services and stuff. And so I, you know, and I said, I think there is lots of exciting talk about what is the next generation of technology, but again, it's always the customers who are trying to figure out, well, you know, how do I transition, you know, from what I have right now, which is pretty complex and pretty, pretty expensive, you know, into something that is, you know, more adaptable and something I can federate to some extent. Switching gears here really quickly. Interoperability is something that's received a lot of press recently. A couple of our articles have come out just in the last few weeks criticizing OpenStack for lack of interoperability. So I want to ask you guys two questions. One, what does interoperability mean to you? And two, does it matter? Is this Steve, since you think that's funny, why don't you start? I guess that's fair. You know, I think with respect to OpenStack, the definitions of interoperability are all over the map. It really depends on what we're talking about. In the context of OpenStack, to me, there are two primary considerations, which is, you know, the first, in terms of the components themselves, are they compatible from vendor to vendor from implementer to implementer?  Are they essentially the same in a sort of version of the asset? You know, so that's question one. Question two, you know, and this sort of actually begs the question of what is the OpenStack project and what constitutes the OpenStack project is, well, which components are we talking about? Right, because in other words, you have implementers now who are picking different storage components. So if, you know, the compute interrupts but we're using different storage components, is that interoperable? I don't know.  So, you know, really, I think when we talk about interoperability in the case of OpenStack, those are the two dimensions you need to look at. And frankly, I think from users yet, we don't have enough feedback to say, hey, this is what a, you know, sort of a interoperable definition equates to. This is where it gets outside of my domain and I want to ask you guys some questions. Isn't it the benefit of OpenStack that it does have that modularity and you can, you know, fit these different pieces together if you do have that expertise?  Or if you're looking at, you know, if I source from a public cloud provider, if I want to switch, you know, what's the time and cost involved in that, right? And so it's like what Stephen said, you know, there's, you know, how assets implemented, it's APIs and there's a lot of things, but you know, I think that's what you're really trying to accomplish if you have interop and you want choice of, you know, accessory items and stuff like that, right? Stuff that goes on top of OpenStack, is it, you know, is it all gonna work with all the various flavors of OpenStack? And so, I mean, I think OpenStack has brought some level of standardization to, you know, to the market, but I think the question is, is like, you know, so it'll make it better, but how much better? Is it a little better or a lot better? Like in practicality, like how much is that gonna matter when you factor in all this other stuff that is not standardized or interoperable? And that's the thing, I just don't think we know yet because no one's really tried to do it and no one's really tested it. And I think that is something that the foundation maybe could take a legal on, right? So, you know, enforcing and testing, you know, to put stamps on minimum levels and for public cloud providers too. And the public cloud is not just a technical thing. I think there's a business interop too because if you want to move to a cloud, there's a kind of business integration has to be done building another, federation and other things that could create headaches. Well, and just for the record, you know, on the point of the foundation, I think the foundation has to take initiative. I think they're the only ones who can. I'll just argue Devils advocate here on interoperability for the developers and the network guys and the server guys in the audience. Everybody, you guys will know what POSIX compliance means. POSIX was supposed to be a standard for interoperability across UNIX. Can you run a workload or is HPUX compliant and interoperable with IBM, AIX, Linux and Max, which are theoretically all POSIX compliant? The answer is no. So what does interoperability mean? Interoperability is something, a myth that, you know, vendors can perpetrate and POSIX compliance means a certain thing at a very baseline level. Now, the higher level we have on the web world, which all of us are also familiar with. You have a web browser through kind of sort of standard station, ML5. Everything is interoperability, interoperable through the browser. So bringing that back to open stack. At the barest level, if you're using a standard OVF image file or AMI image file or as an image file or KVM image file, if you're using the same hypervisor in another open stack cloud, I don't care if you're certified interoperability or not, it's the same hypervisor and theoretically it should run. There may be some other levels of abstraction. The other layer of abstraction that exists today is there's the glance image service, which I'm not mistaken, kind of sort of is backwards compatible from Grizzly to Folsom. So if you take an image, it goes back and forth. Where there is no compatibility in interoperability today, which is where I think the foundation needs to take a giant leap, is where VMware has a massive lead and this massive idea of VM motion across the cloud compliant data centers so I can migrate an entire workload with its whole stack across the data center. Can't do that, but if there's any VMware customers in the audience, you tell me how you can do that without significant hardware to accelerate that workload anyway. So the idea of interoperability in the cloud today is nice, but it's still a work in progress. Okay, so just a couple more questions and then we'll open it up for audience. So in your view, what is the biggest challenge OpenStack will face in the next six months? Alex, do you wanna start us off? The biggest challenge OpenStack will face in the next six months. I think it was expressed a little bit today when Jonathan was giving this keynote and he was saying, and he was addressing some of the complaints that there weren't enough examples of providers a few, when OpenStack was in its earliest days but now that there's complaints about that there's too many providers and that seems to me get to the heart of where the direction of OpenStack goes and what role those providers will play. What role will IBM play? What role will these big vendors play and how will that be reflected in OpenStack overall especially when we're talking about such issues as their operability? Yeah, I think for my money, the biggest challenge that OpenStack faces is basically figuring out what OpenStack is. What constitutes OpenStack? What is sort of an OpenStack implementation? What does that look like? What components does it need to include if it needs to include any? These are the kinds of questions to me that need to be answered because the alternative is that you have differing implementations and then from that standpoint, you have customers who are theoretically implementing OpenStack in many cases to free themselves from lock-in only to find themselves locked into a different vendor because the underlying componentry is different. Doesn't that go to the heart of the organizational structure behind OpenStack? Does that make sense? Well, that's what I said. To me, the foundation sort of needs to play a meeting role in terms of determining, hey, this is what OpenStack is. This is when you can use the term OpenStack. They need to monitor the trademark. These are the levers that we've seen work historically. And I think without some guidance, the danger is that you get down a line.  I'll agree with you. And I know we kind of talked about this a little bit six months ago because fragmentation is something that's kind of messed up with Android, but I see it in a technical sense because of the rapid rate of innovation every six months, public clouds may be able to migrate. I know the rack space guys are calling from trunk, whatever day, whatever, so they can migrate quickly. Private clouds are not gonna migrate quickly. So we're gonna have enterprises stuck on a certain release. And let's worry about the vendors that that will happen. And then you may have to deal with compatibility cross releases. So I think the biggest challenge for OpenStack is to come to a Linux type model on enterprise long-term support releases from a foundation level, such that you're not gonna be supporting all releases, but there'll be an N plus one or N plus two for 18 months or three months or whatever, knowing that the foundation and the core development team is supporting a release for a period of time. And then the vendors will backport there, but that's where I see a challenge. The model has to change because three years, two, three years, new releases every six months is great. It's sustainable, there needs to be an enterprise support model built into the development. But do you really see it changing? Yes, because it worked in Linux and we had the same thing. We have now Linux kernels out every 10 to 12 weeks. Greg Crow Hartman, who's a fellow of the Linux Foundation, he maintains stable kernels. And then when he doesn't need to maintain those stable kernels, and the individuals do, but there has to be somebody who steps up and says, hey, look, this kernel, I'm gonna be supporting and doing it in this kernel. This open stack release, such as, and I'm gonna be supporting it upstream and get for a period of time, and then people won't have to worry about fragmentation. That can happen. There are historical precedences. Yeah, I think interop is that huge issue. Because I mean, I think that's a big, a big differentiating value proposition for open stack, right, to have this kind of interop between public and private and public and all of that. And I think like what Stephen said, a lot of that comes down to standardization, right?  So I think there's a value prop that customers and open stack is really put out as one of its main things. So I think they have to deliver on that. I think if they don't, the project loses a lot of appeal for a lot of people. I think the other part is really just making this software consumable. I think if I just talk about before, just making it easier and more convenient for people to use, and that'll get it to kind of more segments of the market. And I think the other challenge is, maybe not a challenge for open stack, but I think indirectly, I think a lot of people are expecting and looking at fast commercialization and success, right? Where's the money coming in? And I don't think in six months that if it doesn't, there's an ability, ability to help market doesn't appear. Now I would consider that failure, but I think there's a lot of people that expect fast results and maybe faster than what was really realistic. So I think there's always the danger of that kind of hype and people saying, well, it's been sold six months after six months and there's not a lot of money, but six months is six months. I mean, I don't expect these markets to develop over there. I always get constant questions about it. Where's the money for open stack? I'm like, you know, this thing's only been out for a couple of years and it's just starting out. I was like, you gotta kind of relax a little bit. Be patient. Gary, is open stack a sure thing? Depends what you call a sure thing. I think open stack as a technology has probably gotten to the point where the train can't be stopped and I think that the technology is going to work its way into a lot of stuff. But exactly kind of what the model is, who the players are or what kind of distribution model and products, what the products actually look like and that sort of thing, it's probably kind of up in the air, but at this point with the community, with the code that it has, I think I would count that as a success. It's an open source success already. And I do believe that if the community's code is good that somehow the industry will find a way to turn it into something viable. So I just don't think maybe we know what that is gonna look like, but I think at this point, the technology is gonna be widely available in some form or another. And I would agree, you know, the train can't be stopped. Well, maybe it could be, but the core trajectory now is in the right direction. The vendor momentum is in the right direction, was the word that Jonathan used this morning. There's a gravity that's pulling things and the nature of all of our enterprises and vendors are such that we, once you get started, there's a certain amount of operational inertia and Newton's was at second law of thermodynamics and object of motion is gonna remain emotional and it's acted upon by an equal and opposite force. So unless there is an equal and opposite force equal to this operational inertia, then it'll keep going. You know, at Red Monk, we tend to believe that the biggest community wins. There are exceptions, but by and large, sort of the largest collective, you know, tends to have the inertia, tends to have the momentum, tends to have, you know, essentially the energy needed to sustain itself and certainly grow over time. You know, I think that the one wild card, I think with OpenStack is that, assuming that it remains the same community moving forward, yes, I would say that the viability of the project is relatively projectable for, I don't know, for the foreseeable future anyhow. The difficulty, and like I said, the wild card here is, if the community ends up fragmenting itself into multiple communities, then all bets are off. If it becomes not OpenStack, but you know, IBM OpenStack or Red Hat OpenStack or HP OpenStack, you know, et cetera, that's a completely different question. And then, you know, I think the ongoing viability of the community is very much in question. So I guess the question I ask as a reporter is, if there is momentum for OpenStack, then what is it displacing? So I guess that's my question that, you know, that I happen to think about where OpenStack is actually going. And if it is then fragmented, as Stephen says, then who's the beneficiary of that fragmentation? Is it the larger vendors? And will that then just play to their camp? So that's a question that I'm curious about. If there really is that momentum for OpenStack, what are the dynamics there that are impacting the other aspects of the market? So does that mean that VMware is losing momentum with something like BCloud Director? Or does it mean that AWS is gaining momentum in other ways? I think those are kind of the questions that I'm really curious about. If I was just going on from your thread, if I was trying to figure that out, I would look and see what the workloads are and what the net new workloads are that are growing, then ask a guy like, Gary over here and his IDC quarterly tracker, and I know you gotta do one eventually. And then we could see whether it's growing or displacing, again, because I have a background in Linux. Linux did displace UNIX, that was pretty clear, and it's displacing Windows. So is OpenStack displacing VMware? Or is it net new growth? I think it's a combination of the two, and then a combination of just bare metal. I don't think server volumes, server volumes haven't declined necessarily, but five years ago, when we were all talking about virtualization, people thought server volumes would go down because utilization would go up, but that didn't necessarily happen. So I don't know that there has to be a displacement either, but that's something that's we should all pursue.  I mean, it's a total gap between those two. So some of it has to do the way we count it, right? Units of servers, one box is a box, but the boxes, it could mean a lot of things. Like it could be a really small box or a big box, and I really do think that what Sean mentioned, workloads are key because if you look at the competitors, a lot of them have really different workload profiles. VMware was made to be totally backwards compatible, and that's the reason why they had such success because it wasn't really disrupted, that you didn't take whatever you had and put it on there, and then you look at something like Amazon, you look at kind of, I think most open stack implementations, it wasn't really made to run that kind of workload, right? I mean, it was just like, you know, you could, but you wouldn't really be guaranteed any great uptime or anything like that. It was really meant for a new application that was developed for cloud. So, you know, I don't think we will see a lot of displacement as in, I'm taking your workload that was running this hypervisor, this platform, and then I'm gonna move it. I think that's, you know, it's not easy to do, and I don't know if there's a lot of reason for customers that they really want to do it, and I mean, we do see migrations in some cases, right? But I think for the most part, people try to avoid that. It's not something that makes a lot of sense. So I think when you look at new workloads, you have to look at what's really being generated. Just a lot of the old stuff being sold and implemented, and a lot of that's gonna go on what we know today, just, you know, kind of standard server virtualization, and then there's new apps that really fit more for cloud. And granted, both platforms are kind of going both ways, right? VMware's trying to get into the Amazon space, and OpenStack's becoming more kind of with enterprise features. But, you know, I think at this point, there's still a pretty different workload profile between OpenStack and VMware. So I think it's really about, you know, if someone's deploying a new workload, can you convince them to do it one way or another? Or, you know, the ISVs, what are they, what are they? Steven, in terms of developer, you know, the developer component there, how would you judge this if you're looking at, you know, this kind of comparison across different kinds of workloads? You know, where do you see the development focus as it relates to OpenStack versus, you know, VMware type of environments? Well, you know, to me, I think the simplest way to look at that is, you know, when you talk to customers, you know, users sort of have all shapes and sizes, right? The question there is, you know, how many of them sort of prior to an OpenStack, prior to CloudStack, prior to Eucalyptus, prior to all of these sort of would be, you know, sort of, you know, cloud layers? You know, how many of them look like Amazon? How many of them look like a private cloud? And the answer in most cases is zero. You know, which means that from a technology perspective, you know, OpenStack's penetration is largely additive. You know, certainly in some places it overlaps into places, technology is like VMware. But, you know, by and large, you know, most people are trying to make their infrastructure to look more like a public cloud for the first time, right? In terms of sort of what that means in terms of the developer perspective, you know, as I said before, we tend to bet on the larger community. And, you know, sort of one of the other factors from the developer perspective is basically that the simplest technology to acquire, install, and implement usually wins. And, you know, it's a lesson that's lost, you know, and, you know, we talk to vendors sort of of all shapes and sizes. And they all come back to us again, you know, as I said before, they all want to talk about technology. They all want to talk speeds and feeds and performance and features and knobs and bells and whistles and so on. And at the end of the day, that's all great.  But, you know, really the technology that's easiest to implement, the easiest to obtain is likely to be the one that wins. And, you know, right now I think OpenStack does an okay job of that. You know, certainly I think there's been a focus in the last couple of releases on that. There's been a lot of work, you know, sort of in that space. But there's a long way to go before we know one way or another that this is going to be, you know, sort of the simplest technology to implement and use. Okay, I'd like to open the panel up to questions. Anyone have any questions? Can't see very well. Yeah, yes, you want to come up to the mic? Does the mic work? No? Okay, you already could just shout. I'm just not that big. So my question is related to, we talked about interop, right? And we talk about interop means many things to many people, right? There is never so easy as bursting or just moving both those between different clouds, right? Think of two clouds as two different clouds as two different data centers with that. So my question is there have been companies who come into this, like there was Cloud Switch got acquired by Terramar, Verizon, there is Racimi, they do image provisioning and stuff like that, you know. So forget the data for a second. Do you see more of that? Do you see the open start community kind of doing that? Data in workload in workload out should be all done by open start. Interop with VMware, interop with maybe something else, interop with Amazon. Should that be part of the open start foundation? In and out, basically? So interoperability not just with an open start but with another environment? Yeah, yeah. From the very beginning, and I remember talking to Jonathan Bryce about this more than once, open start supports Amazon API. So there is interoperability for AMI images coming in. So that's important. What I think should also happen though, and this is an emerging layer, is at the network layer with software-defined networking and this is not such that I can have the same when we're talking a layer, three domain, I guess, and extend it out so that it's all one piece. That's kind of magic. But yeah, I think it's absolutely important because the other thing is with fragmentation, nobody wants to have silo workloads, right? So with open stack, I think you're reasonably sure that you're not going, well, if you have standardized hypervisors, you're reasonably sure you're okay. Yeah, I think the project's built-in API compatibility and I think there's a layer above that, right? You come up with the management tools to let you burst and move from cloud to cloud. And maybe that should be part of the open stack project. Maybe that'll be handled by the ecosystem. But I think if open stack really wants to be a true open cloud, I think they really should interoperate with all these other clouds if they're not on the platform.  I mean, maybe, if open stack only works with other open stacks, maybe that's still lock in. You're locking to open it. Maybe it's like a larger selection of vendors and stuff like that, but you still have some lock in. So I mean, I think if you can, and I think some of this depends on the other side too, but it's technically possible. Yes, I think you should do it. And, but I think it just depends whether that project should be hampered by foundation. Is it part of the core thing? Is it, I mean, that's maybe a product technical thing, but I think it's philosophically, yes. Yeah, the sort of, the flying that or even, in many cases is gonna be IP terms. So in other words, when you look at the Amazon API, Amazon has not said sort of one way or another what the terms are, the intellectual property terms are with respect to their API. So you can implement it, and a lot of people have, but are you legally able to do that? Frankly, it's an open question. There's a reason, for example, that Eucalyptus went out and sort of partnered with Amazon to try to get those terms sort of down on paper that they were legally able to do that. So the difficulty here is that philosophically, I think all of us would probably agree that, yes, everything should interoperate and it's in the best interest of customers to have the ability to sort of move your workloads around with impunity. The difficulty is that sort of the vendor agendas, they may argue differently. The other thing I would add in there, just think about from a networking perspective, we've all been using Ethernet for X number of years, but it's only recently, and by recently I mean the last three months, that there's been a standard for interoperability across carrier grade Ethernet for quality of service. So if I was handing off from in a carrier hotel between one backbone and another, there was no standard that would guarantee that I'd have the same quality on both sides. Ethernet is what, 30 years old, give or take now? So we talked about interoperability workloads, but when you're talking about production grade workloads and we want to interoperate bursts and everything else, quality of service and other higher level abstractions are also going to be very important and nobody's even talking about quality of service or interoperability because that's so far up the chain, but these things take time. I'm always starting to see the spaces fill in a little bit, for instance, with platform as a service and using service like Cloud Foundry as a gateway into these cloud environments. That seems like that's a trend that I'm seeing at least when I look across the market. There's also lots of other vendors who are trying to do things like make the code more portable by creating that orchestration between, for instance, GitHub and integrating with Chef so you can port that code to multiple clouds. So is this a matter of where the vendors are really just trying to, are taking the lead and that's just gonna make this balkanization even more pronounced? Well, with respect to the pass front, at least, I mean, I think the ambition, at least of many of those projects, and I think certainly the hope for at least some subset of the technical population is that pass can serve essentially as a container. Very much like, for all of that, it gets a bad rap and I certainly hated it myself, but J2E Middleware did guarantee the opportunity to effectively move from operating system to operating system hardware to hardware and so on with a minimum of complications. It certainly wasn't right once, running anywhere as it was claimed to be. I think there is hope that over time, pass would represent that, but frankly, that's a long way off. We're not there yet. I think we're out of time, guys. Thank you. Thanks, guys.


Estimation of empty weight fraction, this is the first step in the initial sizing of the aircraft and unfortunately we do not have much leeway here, we have to rely almost completely on history here because as I mentioned the aircraft has not yet been designed, the aircraft is not in front of you, only what you know is the type of the aircraft and hence you have to go purely by historical information. But we have some help available from historical data, so according to the procedure suggested by Raymer, the empty weight fraction WE bar can be assumed to be a constant A times gross weight to the power C into another constant called KVS which stands for variable sweep. A and C are constants which are a function of a particular aircraft type, their values are obtained by a statistical fit of existing data. KVS is just a multiplication factor that tells us the effect of providing variable sweep. So KVS equal to 1.04 basically tells us that if you provide variable sweep in a aircraft which you would probably never provide in a transport aircraft then you have to have a weight penalty of 4 percent of the total weight. And if you do not provide variable sweep which is most commonly true for transport aircraft then you only have AW0 power C. The values of A and C for various aircraft types have been specified by Raymer in his textbook. So he categorizes the aircraft type under these various categories and for each of these categories there are suggested values of the coefficients A and C to be used. Please note that these values are to be used when the gross weight is in kilograms. There is a separate set of values which are specified in the textbook when the gross weight is in pounds. Now let us observe a few interesting things here. What we notice here is that the exponent C is always going to be a negative number for all the aircraft types. So what does this tell us? This tells us that as W0 increases for a given aircraft type for all aircraft as W0 increases the empty weight fraction reduces. In other words a smaller aircraft which weighs less will have a higher empty weight fraction, a larger aircraft which weighs a lot will have a larger empty weight but it will have a smaller empty weight fraction. The coefficient A is the one that tells you about the sensitivity of the gross weight to the increase in the size. So let us see this some information in a graphical fashion. So what we notice here is that the jet transport aircraft follow this particular line. Now I want to put in a word of caution here. In this particular graph you are seeing the figures where there are these symbols attached to each of the each of the lines and you may assume that these symbols correspond to actual points but that is not true that is not true. These symbols are just given to allow you to distinguish between the various types of aircraft because there are so many lines here so and we could not even use so many colors so we have just included a bunch of symbols. So please ignore the symbols but use them only as an indicator. So a jet transport aircraft typically has an empty weight fraction which can be starting from approximately 0.55 or 55% and it can go as low as around 44%. This is only based on historical data. What do we see here? We see here that the flying boats have the highest empty weight fraction never below around 0.64 and generally as high as 0.7172 and the military cargo aircraft they have the least empty weight fraction which can be as low as 35% when they tend to be very large. Another point to be observed is that this graph has a logarithmic scale on the x axis. It is not a linear scale bear in mind it is a logarithmic scale and the y axis of course is just a linear scale. So on a linear log plot the trend lines appear to be linear and we can use them to get an idea about what would be the expected empty weight. So how do we use this graph? Let us say you are designing a jet fighter aircraft and this jet fighter aircraft gross weight of this aircraft is expected to be some number let us say 10,000 kilograms then its empty weight fraction is likely to be around 0.65 by looking at this particular graph. So what you do is you come up on the line and then go on the x axis and read the number. This is how you use this particular graph but in our case unfortunately we do not have an estimate of gross weight. On the other hand we are actually going to estimate the gross weight and we need to know the empty weight fraction but empty weight fraction depends upon the gross weight. So therefore we have to use this formula which was shown. This particular point corresponds to this particular point shown in the graph. This particular point corresponds to Boeing 787-8 which has got an empty weight fraction of approximately 0.49. So therefore I told you that many transport aircraft they have an empty weight fraction roughly 50 percent which is very much true for Boeing 787. This graph taken from the book by Professor John Fielding actually gives you a better information about the spread. So we notice here that the aircraft do not fall along a straight line. These lines are just statistical inferences. You can see that there is a huge spread even if you look at one particular type of aircraft. Let us say for example we are looking at you know we are looking at large commercial aircraft. The large commercial aircraft again this is a log and linear graph. They do not follow a straight line it is not that they are all on this line. They are above and below this line different manufacturers they have solutions that you get are not exactly along the straight line. So therefore one has to keep in mind that there are bands and what we use in our estimate is only a number which has come from history. Thanks for your attention. We will now move to the next section.