All right, what's up guys? We are back for another ESPN MIC highlight reel the first things first of course the first order of business is Essentially welcome to 2023 It's the new year Alex is starting a small account challenge. What he's doing this year guys super fun We're gonna talk about this what Alex is doing to prove to you guys How much our strategies work in any current environment, especially the new year? What better way to start a small is small ish Smallish account challenge guys does not for marketing or anything Alex wants to show you the benefits and the potential at MIC So he's starting with a 35k account and he's gonna see if he can take it up to a million dollars that exact account No wires. No nothing just take it up to a million dollars by the end of the year So let's get into this. I guess really quick guys I'll bring this back up and just talk about this for a second if you have any questions about MIC All you have to do is text<PHONE_NUMBER> This is my direct line or you can book a call on the website, which I'll show you in a little bit All right, so obviously Monday was off so we could throw that to the wayside We are on Tuesday the third And this was the watch list even though Alex didn't trade much on Tuesday But let's see what the members did as Alex crushed it the last three days So he's already killing it on the small account challenge and it's not that it's a medium account challenge Here's the thing Irvin using outer lines on CMMB. I love this guys. Where did the stock fail before? That's where we want to hit it Especially if you're in the zombie hour guys You're coming up any part in the you know the middle of the day or you know just not the immediate morning where we have The most edge short you want to wait for the outermost lines Which obviously that is where the stock fell before boomerang right back to these levels a long journey back up to a resistance David as much as he would say I'm sure that he probably thinks he piked this a little bit I'm proud of this again. It's good entries and that's what we're looking for So stocks way under VWAP hits VWAP get that flush pay yourself on call of short I think that's really well done and it fits within the parameters of the quote-unquote million dollar setup that we always talk about ATNF Hooper X is the king of outer lines He waited for this launch to happen kind of tire out this parabolic paid himself immediately Awesome job with process Hooper again if we come in and see Eli What what I love that he did on this guys is this is downturning. It's lower high lower high lower high He waits for the push up pays himself immediately and he's not looking for much more after that So again, this is a nail and bail community Alex was describing that although I did not trade RSLS on Tuesday, I still want to I still want to learn from him You guys should too the stuff in the high of day right there Alex is always talking about volume with the stuff You could see that big ol wick the stuff in a high of day on volume guys and rejection was the first Signal the trend may be changing we talk about stuff candles big stuffs was volume We talk about death candles midday all of those things could be a total what's called change in sentiment Which this tend to be it was it absolutely was so then the confirmation was the break under VWAP with no reclaim That is the game over and then you get this bleed so awesome job on RSLS just seeing that Deciphering how we can always have an edge whether you trade it or not. How do we have an edge as traders? We're always looking for an edge Irresponsibly long. I remember when this girl was a party I might see like four years ago guys And she wasn't pulling numbers like this regularly and now she is so I'm so proud of her. That's awesome Awesome awesome. I think the last time I saw her was in San Jose. It's been so long But she's crushing she's crushing and then wolf making 169. I love it Awesome awesome job. So let's go into let's go on a Wednesday got a lot of action for the next three days So this is Alex's watch list. I'll just kind of read out what he made This was the first day he traded guys on the 35k account challenge Trying to get it to a million dollars by the end of the year if not knowing Alex It'll probably be three or four million depending on market action But let's see $13,000 nice start to the year with a small account used about 13,000 shares on the VVOS Started off small then added to a winner nice nice scalps on JSPR and MSGM this morning as well So let's take a look guys. Obviously the first one I have is JSPR And then I also I'm gonna try to make enough room to where I can show you the watch list as well There's a there's a lot to cover. So We're going to the fourth which obviously if you follow along right here guys You can see the date. So one three. It's the day two right here So what we are looking for specifically is the watch list first So every single day we curate a watch list and Alex was saying it's broken now But with love abounds in the morning the 14 15 16 to scale in short wide range So you have to use less size and guys, that's exactly exactly exactly what happened So I gave a whole webinar on this, you know, if you missed this, you know I think it was like a PR thing if you missed this during pre-market Don't get bulldozed if this kept going and got the momentum but now that that got sold off so Unbelievably quick this just goes to show how many bag holders are truly stuck in this and just one out even so when this happens guys This any push being way under VWAP come the open the million-dollar setup and with all this stuff volume And all this stuck demand from the day before guys It was a no-brainer this push in the morning was an absolute smoke show for Getting some decent size on and covering and that's exactly what Alex did on JSP are a wonderful job So MSGM not much to say about this on the fourth It was really just kind of like a pump, you know red to green pump, you know got got his money 760 not much to say on this So we will we'll just kind of leave that one at that and V boss was the big winner So let's take a look at what Alex was doing. He was using a little bit more size It wasn't on the watch list as it became a little bit more about the live commentary during the day But what Alex was doing is come the open he was he was ready to hit this So, you know, here's one for you know, this is this is the day that it happened I'm sure that Alex didn't expect for it to continue on for right here after this stuff that he was looking at And so I know that because this didn't have a Scrapped on a range Alex was willing to throw the hammer at this So when we got this stall up here near three, you know, whole and a half dollar kind of fail It doesn't even really hit it kind of stuffs right here and kind of bases I knew that Alex was willing to work his way out of a position on this earlier entry I just know that he was feeling it and then once we got this tank and then waited for a really good entry to kind of Really size in and waited for you know, these these covers way later in the day guys I mean as much as as much as I would say Alex was a hundred percent in the driver's seat I know he was at least 95% on this one and he absolutely crushed it I'm sure he just didn't expect for this to reclaim as much, but he he held his composure He frickin added perfectly he scaled in he waited had a great great final entries here or final size rather and just hammered This thing and it was a wonderful trade. So let's see what the members were doing Couple members don't go into Thursday real quick Ryan Conley. I love it. We are not just we are not just a Small-cap short-selling community guys So while we do short sell a lot a lot of our members are using the niches and the notches to capture these bounces and great job Ryan love this on RSLS Vindi bow doing a really really good job. I just love following trend down It's the way to go same with E.  I'll go this one last V Voss long again Ryan Conley. It's awesome It's just another way to show these longs. Okay guys I want to show this real quick because Alex actually did how do I zoom in Alex actually did a little bit of a um, oh He gave his thought process on this. That's what I wanted to say So starter position after it topped out was right here exactly what I said And then it was too slow to stop out because it kept going But here's what happened you get a double top and no break in exactly what I said the whole and a half dollar number Three I didn't even read this until right now. That's the funny part. That's how much when you know process guys We all think the exact same way. So the way I'm commentating this I literally didn't read this yet and that's the funniest part is once you know you just know and that's exactly what I said Right here is once he kind of saw these, you know, not being able to make three He saw some you know volume exhaustion candles exactly what Alex is always looking for it's always a potential top and then when you actually Have double tops then, you know, it's basing it's consolidating and it's probably gonna break down if it's already overextended massively and it doesn't reach that whole and a half dollar number So then we go here adding more than a starter when the top is set and the trade thesis is confirmed in my direction He was using though a stop at three dollars He got exactly what he wanted just a beautiful beautiful trade and then soy sauce I have to zoom in on this but he murdered this he murdered it So he did a wonderful job Just just really good. Just really good. You guys are the members are crushing man. The members are getting it Judge a community on the members success This is actually kind of funny guys think about this This is a win in itself even though it's a loss of twenty six dollars Alex lost twenty six dollars yesterday But he's coming off a thousand eleven thousand dollar Wednesday So you guys have to see like Alex is not here to push when it's not there And he is here to push when it is there and that's the beauty of all of this So if we look at this annoying day took a pre-market trade on BLPH Which I stopped out as soon as it broke high a day Waited for the exhaust in the morning and scaled into a winner ended up getting stopped out in the afternoon VWOP Test and gave back some profits being a little too patient had I avoided pre-market It would have been a green day. So we'll do that tomorrow and he absolutely did but let's get into this guys So, um, obviously we're on Thursday. This was the watch list. Let's go to BLPH first Trying to find some room for you guys. I definitely want to bring up some lessons But there's so much to bring up on here. So obviously guys were on the fifth, which is this day right here This was the first day that it ran and this was BLPH So again hot chick in the morning, but it eight eight forty three a.m. Eastern I had a stuff candle I started in pre-market short and plan on adding in the morning and these were the levels that he planned on Adding obviously Alex said that he stopped out. So that's what he was talking about but later guys later. He did I love this I just absolutely love this. He had his composure. You get this opening death candle in the morning What do I always love that if the opening candle is a death candle guys follow that trend down every single time That's what Alex did.  What do I always talk about all the time? Let me expand upon this I actually just want to pull it up here There's only one thing to say buy the open if a stock is way under VWAP and then it does it pop shot up to VWAP on The open in it's going to stuff. It's gonna hit that and it's gonna have a really hard time So I love this there's not much more to say other than being the you know The million dollar set up me and Joe kind of coined that term, but it's because it works. So it's just super cool Let's see what the members are doing on Thursday Let me pull this up for you real quick Alice gave a really good description of this guys So check this out the front side of the move until a big rejection candle on heavy volume This is what Alex is always talking about same signal as V boss V boss yesterday Can then short the bounce with a short with a stop at height of day and that's always the key So always waiting for the tops guys always just wait be patient for your entry in the perfect discipline to have an edge a Top or bottom is usually signaled by heavy volume. This is why Alex was kind of outlining that So I kind of wanted to expand upon that and just show you guys real quick Is that's a really good lesson now rock mon doing a wonderful job it waiting for the top hitting it Unbelievable awesome awesome awesome Highlander Highlander doing exactly what he should be doing on Vynt low-hanging fruit, you know by the by the open even if it's not a day to it's just low-hanging guys So it's again that pop shot to VWAP is the money-maker So, you know, obviously a low-hanging fruit is usually categorized as day two But on day one if it's broken enough, it's it's it's easy pickings Awesome job on BLPH, you know waiting for that opening death candle then hitting those Just following down the trend David great freaking job. That is a new be short and I'm gonna tell you right now He did it wonderfully Vynt long on bomb bomb. Here's the thing guys. That's a great cut and and he knows it So going back to the chart you can see that and look when you do lose you better lose small and that's the key Highlander on Vynt doing a wonderful job about following trend down wonderful wonderful job I'm in a really pat you guys on the back when you deserve it as that's some really good trading right there So we're coming into today guys. The market is totally heating up There's a couple things I want to read Alex made 2.4 K today solid trading day nailing everything except HKD Key today was to ignore a pre-market as always if you ask me Trading and focus on the open when the trends were easier walking away early on this Friday to enjoy my day 2,500 bucks guys. It's it can really be as simple as that up about 13 K this week on the small 35 K account challenge guys think about that Are you kidding me about 48 grand already and and we have it we're in the first week of January of the new year So I can only imagine what Alex is going to accomplish with this. He's a rock star. So I MMX guys.  I MMX One second. All right, I probably gave a webinar on this. So there's previous lines. Let me remove these for you One sec. All right, so let's zoom in here guys I MMX looking to short a morning pop towards 260 to 80 and three in the morning So I'm trying to find as much room as I can give you guys here But Alex did a wonderful job at that as you guys can see hitting it following trend down It's as simple as that when something tops out guys or it's just super super weak You have a go ahead you have a green light to be a short seller But you always got to know your wrist no matter what you're hitting So Alex did a really good job on CMTX guys So let's read his watch list of what he was saying two potential trades on this either a pop and rejection of pre-market highs To short or tank at the open and bounce to VWAP short. That's exactly what he did You know it tanks it tanks in the morning But it pops to VWAP he captures the VWAP pop and he's already paying himself come the open guys So it just can't get any more clear than that following trend down on a broken stock is the way to go Now let's pull up a MTD for one second MTD and What we have it's kind of it's such a like it's like waves. It's kind of funny looking today But let's let's read about this. So if it's not on the watch this guys Remember there's a lot of commentary during the day in the life in the live chat But here's what he was here's what Alex was basically doing and I love this because this is exact process This thing is totally broken. It's the million dollar setup coming the open It's way under VWAP we get that pop towards VWAP because that's the million dollar setup right there VWAP is the outer line So I don't want to harp too much on that as I give lessons on that every single week But that's that's the strategy All right, SP where we at SPRB We are coming in it ran from yesterday after hours and then it's in pre-marked today It actually launches pre-market and come the open we get that opening step stuff death candle and Alex followed it Right down. So that's about as sexy as it gets guys. There's not much more to it. It's just absolutely beautiful That's that's like the Mona Lisa right there those opening death candles those opening stuffs are everything and then the members today Let's see what they were doing Highlander on CTMX Awesome awesome job following trend down waiting waiting for your pops really key David on ATNF Same just read the green line awesome awesome job nail and bail Let's see BV BV X V. I don't know why that's kind of a tongue twister for me on E Awesome awesome job guys that bounce back towards VWAP is gonna be the outer line come the open nail and bail it And this is how you have a trading career Hooper X ATNF awesome job He's so good at you to using outer lines guys He just he really is mastering outer lines every single week more and more or doing the subsequent thing The one brief forward was outer lines This is wait for that drop wait for that tank wait for a death candle wait for just a massive Implosion and then hit the pop and nail and bail welcome to process and then wolf killing it with another $205 I love to see it you guys are patting the wallets your patting process and you're just getting better with time So if I go to our slack chat guys, I just want to show you this really quick This is Currently right now live, you know tonight of Friday. Well, obviously this is pre-recorded But what I'm showing you guys is all of our options within slack So this is after hours going on right now my time live at least but every single day guys We have a watch list so within that watch list every single morning We are identifying the levels the lines why they're appropriate why they're important why you have an edge We take it in the main trading chat and what we have now is a full Walkdown of strategy a process of edge real-time warnings everything networking literally everything you can think of Tom Dees on SPRD why you know there's his chart. There's his fills. He's gonna talk about it He's gonna show you large cap and options exact same thing. So if this is small caps, this is options. This is large caps It's just a different Different way to skin a cat after hours is all about networking guys the guys are This is what they look like right now, but this is actually old from Utah, but Stephen and bow I think they're in Vegas right now enjoying the you know enjoying the night and they're actually having a really good time Live so that looks like it is tonight, but that's actually a different time hysterical and Joe was a kind of complaining how he The last time he drank in deathline quote-unquote deathline one of our setups on alcohol wasn't Philly and he learned his lessons So he doesn't drink with that anymore. So you guys can just see this is a really fun community So last thing last thing I want to go our website real quick guys I'm gonna show you some cool stuff. Alright guys Just skip the video really quick for you because signing in and logging into our website takes a little bit of a Process couple minutes, but now that we are on the website and I'm logged in I want to show you a couple features So the first things first is the video library. So I'm gonna allow access right now because I just signed in So if we go to the video library guys, there's something I really want you to pay attention to we have a full roadmap of content everywhere from a search feature to roadmap of content right down here to a Literally a linear guide to get successful and then Alex's live trade series right here, which is awesome So Alex will literally record a trade live and then months later You'll get it after a couple weeks to a month depending on the time frame, but we send it to our editing team They sent it to music we have Alex audio commentary on it what he was thinking at the time Obviously, it's a live trade guys But we a lot goes in and making these on the editing side and the editing day that you know Why did I use this size? Why what was I thinking when I got in this? Alex then does that right after with audio commentary and it's really cool And that's exclusive for lifetime members and then the couple things right here guys My number is two and three four five eight five nine and seven But you can also book a free mentorship call and get your questions answered anywhere on the site any page Just click that link and then two two more things Watch the one-hour free training you're gonna get a one-hour free training And you can see Alex's broker statements of like seven point five million over the last three years meet the whole team guys It's not about us the three creators It's about everybody at MIC so you guys can just see what this community looks like and how benevolent it is and and just endless Resources so you know, I don't need to bust out the calculator for this But Alex nearly thirteen thousand like four hundred dollars guys Unbelievable for the week. It's the first week of 2023 if that doesn't motivate you for what's possible. I do I don't know what will honestly like I'm not saying you sign up for MIC And you're gonna make thirteen thousand dollars a week But I am showing you what the possibility is of Alex doing it himself in his own results So guys you will get there you will be an Alex you will be a monster But I'm telling you you don't have to be there immediately most people don't realize that an extra $200 a month will supplement their income can change their lives Guys like a steak dinner every single night if you get an extra $200 So again figure out what you're gonna do with that money But this should motivate you to see the level of potential that is in this industry. So Guys if you haven't already booked a call with me text my line you won't regret it I will literally give you a free mentorship trade trading call And we will also iron out if you have confidence in joining MIC and what you can personally get out of it So give me a text or book a call and guys I will see you next


common struggle that traders have been having, and that is that their losers are much larger than their winners. So today was actually a really good trading day for me. Made about $2,500 trading today, and I had one good trade and one bad trade. One was a winning trade, one was a losing trade. Now, for most new traders, if they had a similar scenario where, you know, they had two trades, one was good, one was bad, it might have even canceled each other out, whereas let's say you made $100 here, you lost $100 there, you would have been break even on the day, or your losing trade might have been bigger than your winning trade. But today, you know, my winning trade was a lot larger than my losing trade.


Well, hello everybody. My name is Langan White and welcome to KBE Insider. We should have significantly more attendees today because Slack is down, so we may as well consider it a day off. So it's like between GitHub and Slack, you know, if either one is down, we really have a hard time doing much. But welcome to KBE Insider, where we interview people who are kind of doing the work in Kubernetes to try to give our audience a sense of where we might be going soon and where we're going eventually and where they want to go so that you have a better insight into where the project is going or whatever so that you can make better decisions about how you want to invest in your Kubernetes infrastructure. Today, we actually welcome Peter Hunt from Cryo. But before we get into that, I want to mention a couple things. First, it is Tuesday, T-W-O-S-D-A-Y, because it's 2222 or 2222 depending on what part of the world you live in, which is kind of awesome. I've seen a number of people who are also 22 today, which I think is pretty awesome as well. And then the other thing was the call for proposal, which is basically like submit an abstract so that you can give a talk. For DevConf US is now open. I will throw the link in the chat, but the CFP is open if you are new to presenting. This conference is specifically geared to people who are for the first time wanting to present. So we guarantee a soft crowd, but it is all open source and all very techy. So check it out. And is that going to be in person this year, Langdon? It is currently planned to be in person. So everybody, let's make that true by trying. So in Boston for our audience. Oh, yeah. Sorry. Yeah. There's only one place in the world, which is Boston, which is where I live. So yeah, on the campus and the reason I bring it up is I'm one of the founders of the conference. We've been running it. I think this will be its fifth year, but it's also on campus at Boston University. So that makes it more fun as well. So we strongly encourage you to submit a talk and come if you can. It's August, I think, 18 through 20 this year. So without further ado, why don't we get a little bit more into the show? And so like I said, we'd like to welcome Peter Hunt for Cryo. And if you wanted to introduce yourself, because it's my long running joke, is it's impossible to remember or know the team names or titles at Red Hat for any period of time longer than like three months. Yeah. Hey, thanks. Thanks for having me on. My name is Peter Hunt. I'm a senior software engineer at Red Hat. I'm currently working on the OpenShift node team, primarily focusing on Cryo and sometimes Acupid and sometimes RunC and other container related technologies. Cool. And how long have you been working on the project? So I was assigned, I was moved to Cryo full time basically three years ago. There was a period of time where I was kind of in between Podman and Cryo, but I've been working on these things for like three and a half years now. Gotcha. And for many people who are involved in this space, what exactly is Cryo? And what's it for? Because as a consumer of containerization stuff, I don't run into it very much. No, it's not one of the buzzwords that come up very much. And that's actually partially like we kind of intend that. The idea of Cryo is to be the implementation of the Kubernetes container runtime interface or the CRI and an OCI open container initiative implementation of that. So that's where the name comes from CRI. The idea of it is before time like well, many years ago when Kubernetes was first written, Docker was written directly into Kubernetes and it was interface with the Docker shim, which is now being removed in 1.24. And, but the developers of the kubelet wanted a way to kind of abstract out the way that the kubelet asked some entity to create the containers, pull the images, and like manage the pods. And so they created the CRI, which is a protobuf API to talk to some server and do those things for the kubelet, delegate out that job. So Cryo is an implementation of the CRI and we try to make it be as secure, performant, and boring as possible. We think that running containers in production shouldn't, you shouldn't really think about it. You should just install it on and then it should disappear into the background while you do more important work. But one thing I want to make clear right is, and I think by its name, this was actually a mistaken assumption I had a number of years ago now. It's not a reference implementation, right? It's meant to be a production use implementation. Right. Yeah. And, and there really isn't like, we, there are basically two main implementations of the CRI now, Cryo and ContainerD, and they're both like, you know, kind of tested in upstream kube and they're both like used in production. And so it, from the SIG node perspective, they're treated, you know, generally equally. Just for, yeah, just for our audience, you want to let people know what SIG node is responsible for? Sure, yes. So SIG node is like special interest group node. It basically is responsible largely for the kubelet. So anything, once the API server asks the kubelet to do something, it's like the node level, like, okay, schedule this pot, and then the kubelet goes and delegates that work to the CRI implementation, does all the volume plugging, and yeah. So the work that's done, like after everything's been orchestrated, once it hits the node itself, that's SIG node's her view. Gotcha. Did you, you know, you kind of opened the can of worms there, which we know is a hot topic in kind of the Kubernetes and actually containerization community in general. But before we get into the details of it a little bit, the, you know, what I'm referencing, of course, is the Docker shim. What I'm curious about is, could you explain what the Docker shim does exactly? Sure.  So it's the way that the kubelet speaks Docker and the way that Kubernetes used to run because everyone used to speak Docker. The Docker API was the way that containers were created. And part of the reason for the Docker shim is that Docker itself was designed to be a complete system and not a component. So it required some hacky code to get it to behave like a component. Yeah, that's a great point. Right. I mean, I, you know, I think it's one of those English words that not a lot of people are familiar with, but is exactly what it means when we talk about it in text speak, right?  And, you know, so the other shim that I find kind of scary is the boot, you know, on the bootloader with Linux, for example, there's also a shim. But so, okay, so the Docker shim, the plan is to remove the Docker shim so that we can avoid this kind of interaction or this, you know, potentially hacky code or whatever. And so, and then replace the container runtime with, say, cryo, for example. Yeah, so the once, once the Docker shim is removed, I mean, so for many years, the Qubelet has been able to use the CRI to create containers instead of the Docker shim. So the idea of removing the Docker shim is to say, definitively, the CRI is the way to have your containers be created. So you have to use one of the reference CRI implemented or one of the CRI implementations going forward. Right. Okay. And so what, what will that mean for a user, like, you know, a consumer of Kubernetes? So, I mean, so if you're building your own home cluster or, you know, you're running your stuff in production, you'll have to change some flags in the Qubelet, basically say, hey, talk to the CRI instead of the Docker shim. And you'll have to run cryo on that node. That should be most of the work. So it, like, we hope, like, obviously, cryo doesn't speak the Docker API. And cryo is made for the needs of the Qubit. So there are some things that cryo decidedly doesn't do that Docker did like builds. But for the most part, if you're just running on your Kubernetes node, and you drop a cryo process on there and tell the Qubit to talk to it, then it should just work. Right. Okay. All right. So in the kind of an existing installation, you might have to kind of think about it. But in a new installation, it would just happen. Yeah, right. Right. Exactly. Okay. So what is, since you wanted a red hat, so what is OpenShift using currently? OpenShift is using cryo. So OpenShift, cryo has been an option in OpenShift since OpenShift 3.11. And then for the entire four series, it has, which has been out for around three years as well, it has been cryo. So there's no other container runtime interface implementation that's been supported on OpenShift. So OpenShift users are going to be unaffected effectively by Docker? Yeah, yeah, exactly. They definitely, we've been using it for a long time and had a hand in kind of tweaking the CRI and building it and making it, you know, production ready as it is today. Okay. So say I actually have a cluster that's currently running on DockerShift and I'm planning to upgrade to 124. Are there particular reasons why I would choose cryo versus container D? So we think that a container, the container engine, like the high-level container runtime sometimes called, should be, if it's used in production, it should be hyper-focused on that production use case. So cryo is able to make some, like, you know, design decisions because it knows it's only tailored for the needs of the cubit. So it has some optimizations, but it knows the cubit does a lot. It reduces, it's like the capabilities of the containers, because, you know, we want to run container secure by default. And, oh, and the set of things that cryo is capable of doing, as mentioned before, builds, also it can't push images. These things, the cubit doesn't need it to do, so it doesn't even think about it. And that reduces cryo's code service, which theoretically reduces security risk as well. So it basically tries to be, you know, simple, performant, secure, and boring. And that's usually the pitch that we give. Like, there's a couple of concrete cases where we know exactly how the cubit is going to request a container be created. And if something goes wrong along that process, we know exactly what's going to request that container be created. And as a result, we can optimize for that case and make sure that, you know, try to make the containers come up as quickly as possible. So that's like one kind of a little more concrete example of where we can optimize. And container D is more generic? Yeah, so container D, I mean, they call themselves like the generic container runtime. So in addition to tailoring themselves to the needs of the cubit, they also, you know, have to support Docker and they support, you know, a handful of other clients. So the code base is larger and their capabilities are, you know, more robust, for sure. But, you know, we don't think that if you're running containers in production with Kubernetes, you need that robustness. Gotcha. I was going to back up a little bit, just because one of the things we like to kind of ask people who come on the show is what got you into open source in the first place? So I have been using Linux since I was a freshman in college. I, you know, got convinced by a friend that it would be easier to do my coursework on Linux because all of it was Unix-based and I was using Windows at the time. And I switched over and I never looked back. Using Ubuntu at the time much as chagrin of some of my interviewers. But so I spent college running Linux, but I never was an open source developer. But once I took, you know, operating systems course and I liked it, I, you know, figured out that there was a Red Hat office, you know, close enough to where I wanted to live. And it just felt like a perfect fit. And I, you know, applied and got a job as soon as I could. And so I was hired to work on Podman initially. And that's what I did my internship for. And that worked out well. They seemed to like me enough. So they pulled me back and moved me over to work on Cryo. And that's where I've been ever since. Oh, now until we have to ask. So what Red Hat office was that? That's in Westford. Oh, okay, I gotcha. So formerly the Boston office, mind you, Westford is 40, 45 miles, I think from actual Boston, where, where I live. So, but now there is the downtown Boston office. So there is an actual Boston office as far as I'm concerned. So, okay, so that got you kind of into open source because you started using Linux or whatever. And as a contributor, you got pulled in because you started to get interested in operating systems. Did you, did you have that, what they refer to as like the open source? I can't think of the phrasing, but like that, that itch where you're like, this thing's really bothering me. So I'm going to go fix it. Did you have that moment as well? There definitely were.  I've definitely bricked a number of my early installations, trying to customize it too much. Yeah, yeah, I know that feeling. I had a deep, deep fear when I was installing slackware on a computer in my dorm room, that that it was going to literally light the monitor on fire. It used to happen fairly often, but has gotten quite a bit better. It's easier when I started. Yeah, definitely.  Cool. So what is your role on the kind of cryo team or on the node, what do we call them, the Kubernetes working group? Stig, yeah, let's say, yeah. Yeah. So I mostly maintain crowd say like 80 to 90% of my time, I spend thinking about the crowd code base.  And so I'll often find myself, you know, working on those. And then I spend some of my time in sig node, thinking about developing, you know, moving forward, the Kubernetes ecosystem that features in the Kubelet. But yeah, most of my timeouts, and then I spend a little bit of my time maintaining con mon, which is a little agent that each container runs, needs to run, that runs each container and pays attention to its logs and its life cycle. So I also maintain that. Is that like the pause container? Like, is it running in the pod or? No, it's on the, so it's between cryo and the container. So it basically, it's the entity that actually spawns the run C process. And once it does that, it like attaches to the standard out of that process and forwards the logs to the disk so that the Kubelet can read them. And then also like watches for sig child. So when the process dies, it can write it's the exit code to a file that cryo then reads. So cryo can actually shut down. And because none of the containers are actually direct children of cryo, none of the containers die, cryo can shut down, configuration can change, it can come back up, learn that all of these containers are still up, and then basically just like remember all of the state of the node. Yeah, that's good. I have a very close experience with that with like libvert D, you know, kind of same same idea is like, you know, you can launch all the things and then for whatever reason, if you have to shut libvert down, you can do that and then kind of bring it back. Just, you know, the reason I mentioned it right is I think developers in general probably have more experience with, with being that close to your virtual machines, whereas, you know, with the containers, I think it's less common. But that's why, you know, I would say it's comparable. Sorry, Josh, did you have something you wanted to ask? Oh, well, you're mentioning on working on some features and that sort of thing. So she's talking about cry, the job of cryo is to be boring and that sort of thing. But I seem to remember from KubeCon that you are actually working on adding some new things to cryo, things that actually might not have been available via Docker. Well, yeah, so, you know, we tout the boringness of it, but, you know, still at the end of the day, people want to get work done and often this work ends up being interesting and novel. And so we, there are situations in which we add, you know, we do add features to cryo. So some of the things that we're working on, yeah, so you mentioned the KubeCon talk, there's some situations where there are resources on nodes that need to be provisioned for containers that the KubeLit isn't aware of, like it's kind of a hard thing to get field into the pod API, because like a ton of entities think about the pod API. So kind of like a ground level thing to add support for like things like specifying the size of the shim for the pod, which is how pods, you know, can share memory or, you know, there are some experimental resources on the node like Intel's block, or like block IO configuration like these things. We've added support for basically specifying an annotation, which is something that Kubernetes supports very easily, like just, you know, arbitrary string key values. So, you know, a user can specify a special string in their pod. And if the admin has, you know, turned on a switch and that user is able to make a pod with that certain annotation, then they get access to some of these special features like that. So, another, so things that we're thinking about just generally is, you know, Kubernetes has kind of worked in a certain way for a long time where it, like the KubeLit basically does this like list, watch loop where, you know, because before in Docker, it basically was just like, hey, what are the containers? Where are your containers? What are your containers? What are your containers? On a loop to actually get the state of the node because it was like kind of a hacky, you know, shim as we were talking about. So now we're kind of imagining what the future could look like and thinking about like, okay, can we wire up, you know, events in, you know, the KubeLit so that it can listen to events and reduce the like runtime CPU usage. And then following a couple of caps upstream, we're working on reworking the way that stats are gathered. So I'm sure that this will come as a shock, but the way that stats are gathered in Kubernetes is also kind of hacky, where it used to be that Cadvisor would monitor the behavior of the Docker containers by, you know, I notifying on C groups hierarchy. So basically whenever a new C group was created, it'd be like, ooh, a new C group. And then go and look at the hierarchy and be like, okay, here's what the memory of that process is. And so it kind of has worked that way even as new CRI implementations have been created, which has caused a lot of code bloat in Cadvisor. And it's actually made it kind of hard to maintain because it knows like a ton about all of these different, you know, CRI implementations. So we're working on moving the stats gathering from Cadvisor to the CRI implementation, which has a couple of, you know, little difficulties about it because of the way that it has worked always. It's hard to change things with such a large and slow moving project. Gotcha. That makes all the sense. So kind of expanding on that, though, you know, if you if you were in charge of the world, what would you, you know, what would you like to see next? Like what is what are the things that, you know, like I said, infinite time, infinite money, what would what would you think that the right, you know, direction in a sense for Kubernetes or even cryo or, you know, any part in the middle. So I would I would love for a world and I'm most of my worldview is focused on SIG node. So I would love a world where the kubelet was a pro like was the process pretty much responsible for what it's doing now it listens to the API server and then calls down to CRI implementation. I would love for the CRI implementation to actually be a very thin proxy to basically one that basically runs all of these per pod processes that actually are responsible for delegating the work needed for that pod. And when a container dies, it would emit API an event up through the proxy and back to the kubelet. So basically like the CRI piece would be much thinner and much smaller. So that the runtime CPU, you know, there wouldn't be all this listing, there wouldn't be all this like process just waiting for stuff to do. But rather it would, you know, like the all of the little processes would be responsible for their little piece of work per pod, which would allow Kubernetes to scale up and scale down, you know, much better like, you know, Kubernetes has a lot of trouble with the single node or like the, you know, smaller box. It's really like meant for like, okay, I got a huge cloud server with a bunch of VMs and let's run, you know, these things in the VMs with this elastic amount of resources available. So looking thinking about what it looks like for a tiny little server to run, you know, these containers and, you know, how, you know, what, what the memory and CPU constraints would look like, it would be great if it was more flexible and not as, I mean, it's kind of like wasteful now, being frank. But so it, but, you know, obviously it's worked this way for a long time and it works well. So it's, and it's hard to change. So, you know, we're both, I would like to live in that world eventually. Right, because you would have to change kind of both sides of the, of the problem, right. And, and obviously changing the kind of almost like the Kubernetes side of it is quite difficult at this point, I imagine. Right. So like, my hope is to, is that, I mean, we haven't yet put up our proposal, but we're, we're currently like some of folks at my team at Red Hat are imagining what this proposal would look like. And then once we, you know, once we submit that, and it goes through a couple of releases, then, you know, for the proposal for the event driven. So that's like the first step. And then once we have event, then we can start thinking about, okay, what actually does cryo need to do all the time? What is this daemon that we're running? Do we need it? You know, or like, how can we pare it down? Another, you know, thing that we're working on that I forgot to mention is we're rewriting conmon. We mentioned conmon earlier, the container agent, we're actually rewriting it in Rust, the new hot language that everyone loves talking about. And we're, we're changing it to, and the, and we're, we're updating it to a per pod model rather than a per container model. Right now, for every new container that's created, a new conmon is running for every container exec that runs, a conmon runs. And all of this is, you know, more processes than are actually needed. So, but we're updated, we're hopefully in 124, we'll have a preview of this, you know, conmon 3.0, which is, you know, a per pod conmon that Cryo can talk through, through an, you know, an API. And, you know, so that will also take us another step forward to this world where that process can actually be responsible for calling all of the run, you know, run C create, run C exec, run C kill. And then eventually, you know, we can start pairing down the things that Cryo needs to do and have, have it just be as focused as possible. And somehow I sense a lot of debugging in the future. Particularly for things, for things like exec. Yeah, the, it definitely, and it's, you know, it's, it's kind of funny you mentioned because it's as if Kubernetes needs more complexity and as if it needs, you know, to have more processes in the picture. But, you know, you trade-offs everywhere in it, and we'll have to make it easy to debug, you know, conmon 3.0. Sorry, maybe I misunderstood, but in the proposal with conmon, then wouldn't the, wouldn't kind of the number of things happening actually be reduced or, or you think they would go up? So the, if you're doing it by pod versus by container. There are fewer, there will be fewer processes, but conmon will be more complex. Oh, gotcha. Maybe doing more things. And there's like currently a pretty, like, you know, there's CryCuttle, which is the, which is a tool that can talk, speak the CRI client language so it can ask, hey, Cryo, like what are the containers that are running? But that doesn't exist for, you know, this, you know, new agent that we're making. So there's, you know, it will have to, you know, think about how best to see into the world of conmon as, as the scope of conmon increases.  Well, I have this, like, I need, I need a pod with this specification. And then conmon does the, you know, namespace pinning, it acts as PID1 for the container, for the pod, if the pod is a private pod level PID namespace, which is the reason for the pause container, which you mentioned earlier. So we'd not need the pause container in, like, most situations. And it, and then it, like, sets up basically the, all of the containers, and does all of the execs can stop the container when it's asked to. So basically, yeah, like, all of the functions that Cryo is kind of doing, moving it down to the pod level. One day. To into the conmon. Right, gotcha. Sorry, Josh, did you have something else you want to ask? Well, I am, I am interested in one thing, which is that if conmon's being rewritten in rust, then was there like sort of internal debate about that? Because obviously, you're rewriting conmon and rust in the same time you're having it take on more work that's currently being done by the cooblet. So, yeah, the, the, like, basically, well, so the options were write, rewrite, or like, extend the behavior of the current conmon, which is written in C, and is, has been put together over a time, like, over long enough, and like, the main developers have kind of cycled in and out, such that like, I'm like one of the main, you know, contributors of it. And it's hard to work with. So, it was either that or rewrite in go, which has a lot of limitations with respect to memory usage, like the go runtime is very heavy. And the garbage collection is expensive, especially if we're trying to reduce, like, latent CPU usage. So, kind of like rust lived in this world where it was like, it could be performant in the way that C is, but also, you know, is a more high level language easier to work with, can have like threading very simply, can have, you know, all of these, you know, nice, niceties that we're used to in, you know, now. So, I didn't realize it was not in go. So, that, that makes more sense, right? I mean, if you're going from C, it's kind of in go. Yeah. So, that, I mean, we, it was, yeah.  Even for per container process, it's like, you know, two makes per container, if there's like, you know, a couple of containers per pod, that's, you know, pretty low overhead over all. But yeah, yeah. So, it's a fun secret is that we have con mon in C, which is, yeah. Right, right. So, that makes, that makes a lot more sense. I mean, at least, you know, for me, going, if it was in go and going to rust, that's a much harder decision given, as you were kind of saying, right, though, most of the Kubernetes world is in go. But I think if you're coming from C, you have a lot more, you know, kind of options there. So, we did actually have a question. I was just going to bring up from the audience, which was, is there a plan to coexist with the two versions of con mon as it comes out? Or, you know, are you going to try to do a forced move? Or, you know, how do you, how do you think that will happen? Right. So, my plan, so right now, we have the ability to toggle between runtime types, because we have, we have support for Cata, which is a runtime type of VM. So, you have to kind of work with it in a very particular way. And then the runtime type OCI, which is just like a con mon base. So, my, my plan for this would be to introduce a third runtime type of which has yet to be named. And then, so they, in long story short, they would be coexisting for a while as we work out any issues with the new con mon.  So, you know, we would be supporting a con mon based one for a while anyway. So, we're, we'll, we'll safely move through until we're ready that it's like, you know, up to snuff and capable of handling the production workloads in a, you know, well. Oh, we just lost your sound, Langdon. Sorry. Is that better? If I don't hit the mute button, it also works better. The, sorry, I coughed earlier, so I didn't want y'all to have to hear that. I just said that's Kata as in Kata containers, right? Correct. Yes. Sorry. So, yeah, Kata containers, the, the concept of running a tiny little VM instead of a, well, for a pod instead of a, instead of a set of containers. Right. Right. Right. Yeah. I just wanted to make sure that we were talking about the same thing. Yeah. Yeah. And I guess, I guess it would be like how would, you know, one of the things is how would it, would it affect more exotic things, right? Like Kupert, for example. So, I mean, Kupert, I, like, you know, Kupert is, from my understanding, and I haven't really worked a ton with Kupert, but I've done, I've supported a bit of it. And from my understanding, it's basically like they create a privileged container process that then talks to live for directly in that crit, creates a VM. The, so the, the VM, it doesn't really live in the container cheroot as mine, or maybe it does. I'm not super familiar with, like, exactly. No, no, it doesn't, it doesn't, it, it, it kind of emulates a pod rather than, than being one. Right. So, so theoretically, I mean, everything that you can, because a container is just a process on the host, that's in a cheroot environment. So anything that, like, that doesn't change very much. Really, what changes is like the way that we look at the, into those processes. So, like, Kanban is the thing that's, like, listening to the standard out and running it to disk and, you know, monitoring the exit code. None of that, you know, changes if the configuration gets a little bit more exotic for, like, something like Kata, where the container is actually a VM, or the pod is actually a VM, and inside of it, the containers are running inside of the VM.  So we're not, we're not really messing with that. So this is for run C or, like, C run type containers that are processes on the host, that are run inside of a cheroot environment. Those will be within scope of the change. Gotcha. Kind of, you know, you've been talking a lot about change and one of the things that's been coming up for me a lot as a, as a faculty member now, right, is where, if somebody wanted to get involved with the project, you know, either cryo or kanban or whatever, I would imagine that there's, that it's kind of got a bunch of code that is, you know, kind of small, in the sense that you can understand a small amount and, you know, make a fix. Are you tracking anything like, you know, easy bugs or easy fix type stuff for where I could point people to go and try to get involved in the community? Yeah, that's a great question. So we do have, in cryo, we have, like, a couple of tags, like, good first issue and help wanted. So those kind of, those we try when triaging to apply, if they seem generally pretty small in scope and something that, you know, wouldn't be too complicated, but we ourselves don't really have time for. So yeah, and I mean, generally, we're always happy to help people find work that they're interested in. So if they wanted to reach out to any of the cryo developers, we largely live in the Kubernetes slack and pound cryo. So if people wanted to, you know, wanted to learn how to contribute more, definitely reach out to any of us and we'd be happy to kind of direct them. We're always, we're always looking for new contributors. And is the, where's the kanban effort? Is that also running in sort of in the cryo community? So right now, yeah, so we're cryo, the cryo community, the podman community will soon join the effort they've been focusing on a new major release. So, but they're gonna soon join as well. But yeah, it's largely right now within it's just a couple of developers on the cryo team. And that is right now, it's still like, we're still pretty early stage, like we have, we're pretty close to a like MVP. But we're, you know, they're still a number of steps. And a lot of us keep getting distracted. So that lives in, there's, and you can talk about it in the cryo slack or on cryo. And, you know, the repository is github slash containers slash kanban dash rs. I can type that out. But so, but right now it's, it's such early stage that we haven't really started, you know, working that that concretely on the integration into cryo. Yeah. Yes, I was just thinking because a lot of a lot of, particularly young developers who are just leaving college, right, are learning Rust. And so they're going to be interested in that. And I'm just like, you know, if somebody is a Rust developer, and they want to, and they want to get involved with kanban, where would they go? Right? Yeah. And I do think that like, speaking of the future a little bit, I think that the future of some of this, you know, cloud native, you know, Kubernetes world is rewrites in Rust. I mean, go was is a very is a great language. It's, you know, has a very low barrier of entry. And it is very clear what code is doing, even very complex code. So, like, but I think that for, you know, processes that live in the world that cryo lives in, like the container manager, when you start actually really tangibly thinking about the processes of a container, something a little bit more low level, something a little bit more conservative about memory, I think will kind of be the future of, I mean, we've been we've been joking about wanting to rewrite cryo itself in Rust for a long time. And that that we're kind of reconsidering that. But you know, the as the future goes forward, I can I can see things like that happening more and more. Well, the reason like, you know, like kind of another experience I have that kind of reinforces your your opinion in my mind, right, is we've been looking in the university, right, at, you know, needing a low level language to teach low level classes, right. So like an operating systems class, this was specifically in the data science space, but, you know, whatever. And, you know, to try to get away maybe from C and C++ and, you know, and it looks like Rust might be the best choice for that, right, is that it needs to be low enough level. And I also think that Rust starting to land in the kernel, like in the Linux kernel, maybe not quite mainline, but certainly nearby, you know, kind of also reinforces that opinion, right. So, you know, but I think one of the really nice things about modern development, you know, the last five or 10 years, you know, with the popularity of containerization and all that jazz is you can choose the right language for the right job significantly more easily than you ever used to be able to. So, you know, just because you have, you know, one thing written in Go, another thing written in Rust, and another thing written in C. Yes, you need to think about making that decision. But if there's a good language reason, it's very doable now. Definitely. Which is nice. Did you have something else there, Josh, or did you? No, no, yeah. What, well, and do you mind if I change topics completely here? Oh, yeah, go ahead. Um, are you still doing competitive dancing, Peter? Well, the, so, no, the last couple of years haven't been the most conducive for competitive partner dancing, but yeah, and I did last competitively dance when I was in college. I was a competitive ballroom dancer, so, but I have, I've kind of fallen off of it, but I am interested as it becomes safe and poking back into the world, at least casually. I don't think I'll probably remain a competitive dancer, but yeah, I definitely, yeah. Classic ballroom dance, like waltz and that sort of thing? Yep, yeah. So like in the, uh, waltz tango foxtrot, and then also the like Latin dancing, like cha cha and rumba, samba and jive, so. Have you considered a TikTok channel? Because that, that would be, that would be an appropriate landing point for significant amounts of dance. I think I've forgotten a lot of the stuff, uh, and so I would have to get good again, right, or get better before, uh, you know, considering avenues of advertising my skill. Right. So we did actually just have a question in the chat, which is that, are you seeing other parts of Kubernetes that are, you know, typically in C or whatever, moving towards Rust or, or is Kanman kind of a, you know, just a one-off and, and unrelated? I don't actually know of many other projects written in C. I know like, isn't Envoy written in C++. I don't, I'm not very tuned into, uh, that community. But, uh, or one of, yeah, anyway. I want to say Envoy is, it's either C or C++. I can't remember which though. Yeah. Well, I know then, isn't the, the new linker D is Rust. Yeah. Oh, uh, that's possible. Um, yeah, I don't, I don't know. Um, so, but I think a lot of the conversation will end up being what to move from go to Rust because go is clearly the dominant language, uh, in this ecosystem.  Like for instance, the thinking about the prospect of rewriting the Kubelet is horrible and makes me, uh, scared because it's like, you know, hundreds of thousands to millions of lines of code and, uh, incredibly complex and, you know, not super well unit tested all the time. Um, so I don't know. Like for a lot of the pieces in the, the, the like higher level community ecosystem, I'm not sure if it makes a bunch of sense. I mean, obviously it's very modular. So it's like some, some really, um, motivated developer, um, wanted to go and write, rewrite at CD in Rust, they could, um, and just plug it in and it would work. Um, but I think that, I think that the biggest considerations are like, you know, anything underneath the Kubelet. So like rewrite, like, you know, there's the project C run, which is written by, uh, one of our colleagues at Red Hat and, um, Giuseppe, uh, Trivano and like C, like, so it's run C rewritten in C, um, which makes sense because it's, you know, nice and low level and, you know, you need access to a lot of the kernel APIs and there actually are pieces of run C written in C, um, to do some of the things that go can't. Um, so a thing for positions like that, like I can imagine a world in which someone would, I mean, there is actually a Rust, uh, runtime, um, and I'm forgetting the name of now Yuki or something. Yeah, Yuki. Um, but, uh, the, I think that, like, the, it's like the container manager level. So like, you know, Cryo or Kanban or, you know, maybe run C, um, are the, the, the most clear targets, uh, for that kind of rewrite. Gotcha. Yeah.  Um, but Rust really, it's only in my opinion, right? It's only just getting to the point where it's something I, I would trust, um, at that kind of level.  I was going to say, I don't know, I, I was a C programmer for a long time and, and the, just because a language is old doesn't mean it's trustworthy. Well, that too. Right. Right. I would make that argument about C++, but yeah. Yeah. Well, um, and I think, yeah, like, I, and I think the barrier to entry of Rust, I mean, I, I, well, at least speaking for myself, like the re changing the way that I think about programming models, uh, and, you know, making, you know, to the, the Rust version, like it's not, like, you know, we have some of it, uh, some of that model in C++, but it's not mandated like in the way that it is in Rust. So I, I found it hard to switch over from go to Rust, and I can definitely see that being just a general barrier of entry for any project thinking about moving over, um, to Rust. I don't, well, I mean, one of the things you always have to look at is you look at, you look at the programmers who have a track record and you look at the programmers who are new, right? And I'm seeing a lot more Rust adoption and among new programmers, because if you look at, I mean, you still look at the go documentation, it starts out with go is just like C, except for these things, um, which is great if you're like me and you've already programmed in C. But if you're getting started or you're crossing over from Java, that's not helpful at all. Right. And, and, uh, you know, and in, in the world of code, we always have to think about the fact that there's always, you know, that there's always more new programmers than there are old programmers. Yeah, like speak to anybody who's still raking in the box for COBOL, right? So, so there was a question that had like advice. I'm sorry. Go ahead. Go ahead. Oh, I was going to say, somebody asked if there was advice on learning Rust. Um, and, uh, at least for me, I, you know, when I started to take a look at it and I did not get very far because, you know, work kind of got in the way. Um, but, uh, the, the Rust kind of website is pretty good. Um, you know, at, at some of the kind of documentation, tutorial stuff, but I was wondering if, you know, either of you have, uh, you know, anything that you've heard or seen or experienced that seemed like a good way to help you learn Rust. I learned in a very, uh, kind of, I don't know. I don't, I, books don't typically work for me. My brain, I, like, I try to read and I just kind of get hazy, um, have trouble paying attention. Um, so the, I don't have any suggestions like that. What I do is I look at code that other people have written in Rust that I can, I trust. So like, you know, one of my colleagues, Sasha, um, Grunner, who also works on, um, Cryo with me, he's done a ton of writing stuff in Rust. And so I basically look at his code and then see how it looks and then write some code and then see how many compile errors I have and then Google all the compile errors until I fix them. And eventually, iteratively over time, I start getting more familiar with it, but I don't think that that's actually the most efficient way to learn a language. I think that's just like the way that works for my brain. So, um, yeah. Yeah, it's funny. I actually, um, I'm very good at reading. Like I really like reading or whatever, but not to do something like learning a programming language. I usually find the best way for me to do it is, um, I try to go build something. Um, and, you know, and basically, you know, Stack Overflow and Google are open over here and my, you know, text editor is open over here and I just kind of keep banging at it until, until it works. Um, but I think, I think that's, you know, there are better ways to, to do these things. Um, I'm just not a hundred percent sure what they are.  I can remember the website. It's like rust-lang.org. Yeah. Um, you know, I like some of the content there and I thought that was pretty good. And, um, isn't like Firefox is now completely Rust, right? Or is it just like a Rust engine? But I mean, I, I would trust that code as a, as an exemplar. Um, I would think, you know, definitely. Yeah. I agree. Yeah. That there's a lot of, I don't know if all of it, but I know a lot of it has, like, I mean, that was a lot of muzzle is like motivationing, um, you know, for creating it. Yeah. Right. Um, I was just looking. Um, I feel like Sasha is, uh, gonna be on the show in the future, right? Yeah, he is actually, um, uh, next, next month, I believe. Yeah. Yeah. So I was just looking because I was like, do, do I have the right Sasha? I can't remember now. Um, it's, I'm, I'm just trying to remember whether it's next month or the following month. Let's see. No, no, it's next month. Okay. Cool. So the, uh, not next month. I'm sorry. It's February now. No, Sasha is April. Um, so Sasha's going to be on in April talking about S bombs and release artifact signing for, uh, for Kubernetes. Gotcha. Um, all right. So, uh, we are almost out of time. So, uh, but I do, uh, on behalf of Twitter, have to ask about the floral pants just on principle. Yeah. Yeah. What, what about them? Oh, like, so, uh, do you own a lot of pairs of floral pants? Where do you come by them? Uh, are they, uh, are they easy? Do you recommend them for others? Absolutely. I 100% recommend. I find, uh, you know, I typically, uh, dress largely masculine and I find a lot of masculine clothes don't have a lot of the flair that I'm looking for. Um, so I shop in the, um, often the, you know, the women's section, um, in thrift stores for, um, for fun pants. I've, I've got some, I don't know if I can get my leg up here, but I got some. Um, here we go. Halisthenics on KBEI, right? Yeah. So, uh, yes. Um, but I definitely think more people should be wearing, um, fun pants. I, I kind of, uh, really have a thing against jeans. Um, and so, uh, and the nice thing about fun pants is that they're all comfortable, which is a big thing for me as well. So, definitely, uh, more flowers in more places is, is my, is, is my review.  Uh, I, jeans already don't have enough pockets for me. I can't imagine losing even more because of the corruption of lack of women's pockets. Um, you know, I should fix too, but. Yeah. Now, now I actually have pairs of floral pants. This is my, my summer weight, um, pajama pants for working at home, um, are, are largely floral prints. Um, but, but those were, those were actually out of a catalog for, for the men's casual pants has, has exploded as an industry over the last two years for some reason. Um, yeah, yeah, but I definitely, I feel like they're still niche enough where they're like more expensive than like, I'm looking for. So, and I definitely saw, yeah, looking, looking these, these were not, but, but you know who, who wears, who wears really flashy pants and it's people in the culinary industry, um, back of house. Cause chef pants are a thing and those are expensive, but they're also indestructible. Right. Uh, scrubs, scrubs, they're going that direction too. You're seeing a lot of scrubs now that are in fancy, fancy flavors. Um, it's funny cause my, my father was a ER doc, right? And I remember growing up him basically wearing scrubs most of the time. Um, and, uh, they were never anything besides green. Yeah. Ever, ever. Yeah. So we bought, we bought my dad, my, my father's an obstetrician. And so we bought him a set that had little tiny prints of the Chlamydia virus. Nice. Nice. All right. On, on that note, uh, which, you know, uh, thanks so much for coming, uh, Peter. We really appreciate it. Um, and, uh, you know, we love talking about, uh, you know, the low level things that are going on Kubernetes.  Um, that's really interesting about the rust choice. Um, you know, interesting about how, you know, you're trying to get more of a, an event driven infrastructure even at the kind of cryo level, which I think is, is also interesting. Um, but, uh, thanks to the audience. We really appreciate you, uh, sticking around for us. Um, and, uh, please definitely join us. We have, we already have, I think guests lined up for the next, like three shows, four shows, something like that. Um, so keep an eye out last Tuesday of the month. Yeah. Next month is going to be, uh, a couple of people talking about, I was mentioning more exotic runtimes like Kubert. So a couple of people talking about virtual machines in, in a container infrastructure. So somebody from the Kubert project, as well as somebody who's worked on virtualization in the Linux kernel for a long time. So, right. Yeah. So that should be a fun show. But just remember it's last Tuesday every month, 10 a.m. Eastern. Uh, what is that? UTC is, uh, 1, 2, 2 p.m. Um, and, uh, yeah, and we'll see you next time. Okay. Thanks. Bye-bye.


From Times Square, in the heart of New York City, it's theCUBE, covering Imagine 2018. Brought to you by Automation Anywhere. Hey, welcome back everybody, Jeff Frick here with theCUBE. We're in downtown Manhattan at Automation Anywhere, Inspire 2018, about 1,100 people talking about bots and RPA, that's robotic process automation for those that aren't in the know. And we're excited to have another co-founder join us. She's Needy Metta, she's an SVP and co-founder, welcome. Nice to meet you, Jeff. So you're tackling some of the softer, more complex issues that come up around machines and bots and people and working together and people's jobs, getting take away. So as leaders, try to put in more automations, start thinking about adopting things like automation anywhere and bots. What are some of the big ethical things they need to think through? What are some of the bigger issues that maybe aren't top of mind, but really worth a little deeper thought? So one of the things we like to bring to focus is that corporate leadership and corporations must look at it with a human focus. Robotic process automation helps get rid of the mundane and repetitive tasks. But the ultimate goal is so that you can enable the humans to do more, to enable a lot more creativity or outside the box thinking or come up with new service models, come up with new ways to solve things. And this is only possible if you get rid of the repetitive mundane tasks which often bogs down humans. And so coming at it from asking leadership to look at it right from the forefront, how can we enable the humans to do more? How can we enable our human workforce to use this technology to unleash that potential? Right. And how receptive is the workforce to that message? Or are they just afraid that these bots are coming in to take their jobs on some of these more repetitive tasks? Or is the rollout and the communication and some of your guys' customers who've been at this for a while, is that part of the rollout? Is that part of the implementation to say, hey, the goal here is to help these things with the stuff you don't like to do so much in your job so that you can have a higher level of productivity, a higher level of contribution, a higher level of everyday activity and tasks? Absolutely. I think change is always hard and it takes a while to progress through it. Reskilling is a part of some of this change that we are going through, especially with people working with bots or bots taking over some of the more repetitive or mundane tasks in a way. But having the leadership walk that change management, walk that transition with the human workforce is part of our endeavor and we enable our corporations that work with us and our partners to make sure that they are able to do that and bring that focus to the human workforce. The more we talk about it, the more we put corporate focus on reskilling and talking to our human workforce about what the ultimate vision is and how we're going to get there is very, very important. Right.  Audacious is a really interesting choice of words and one that you very specifically pick. What is so audacious about bots and is that both a good thing and a bad thing? I think so. The audacity of bots, as I like to put it, is because bots promise to self-learn or perform certain things like a human does or perform cognitive functions, to some extent think through certain problems or questions that arise. And think is such a human skill set and asking a bot to do the same thing as that is very, very difficult for a human to comprehend. And that's why I call these bots audacious because they promise to do all these things. But if we keep the thought process that why are we enabling this technology, why are we focusing or encouraging this technology to be adopted is so that humans can unleash that potential. Humans can get to that next level. Right. And so it's important to do so. Right. Here it touched on an interesting thing in the keynote about now people are creating bots that are creating bots. So, you know, and we hear about that all the time, right? We've heard about the machines talking to one another in a language that nobody understands what they're talking about. So have you seen, you know, the increases in compute, the increases in networking, the increases in storage, the prices of those things going down? How has that changed the evolution of the bots that you guys are creating? How do you see that change in the evolution of the development of these tools going forward? Bots creating bots is an interesting concept. But remember that the context of the bot, creating the bot is still up to the human. What we allow the bot to do or what he's able to get more productivity out of is important. And so if we get those barriers right or we get those positions right for the bots to work in, then it is a pure corporate enhancement. It's an enhancement of everything that the corporation brings to the table. Right, right. Just curious, like you guys have been at this for a long time, when people start to really get into their journey with this technology and really is starting to implement it and see things, what does happen to the human workforce? Do they get redeployed? Are they just doing different types of activities generally within the same kind of category of work? How did we actually see it evolve in the real world? So yes, to all those questions in a way. Some people will get redeployed. But what we are seeing right now is most people are able to take what they have and get rid of some of the things that they didn't really want to do anyways, which was very time consuming. And often not a big value add to their own job sets that they're bringing to the workspace. So having that availability for the human to say, yes, I want to get rid of this 25% of my work that is very, very repetitive and have a bot do it so that I can actually go and do the five things I've always wanted to do, but I never got to it. That's what we see on the work floor. We've also seen amongst all our implementations that humans who are embracing this bot enablement as I like to call it, don't want to go back to the other way of doing it. It has improved their work life. It has improved what they bring to the table. It has improved how they deal with their coworkers or their jobs or what they are responsible for. And they really don't want to go back. That's what we're seeing on the floor. And that's great. That means we're on the right track. We are enabling them with technology that will make a difference to that human. And that is what this is all about. Right. I don't think too there's enough talk about humans aren't really good at repetitive tasks. You know, those are where we make the most errors. Unfortunately people don't use the copy, paste function enough. And I think where we're kind of manifests itself in just a consumer front-end application is addresses. And address verification, when you buy something online and you get that thing that says, you know, here's the address that you typed in. Right. You know, here's the address that we have in our system. And it's just a very clean, simple. Cross check. Verification. Example of a cross check verification because we're not good as a species. Exactly. At repetitive mundane tasks. It is. That's not our core strength. And I haven't met a human who hasn't failed to impress me in some form or fashion. If we can unleash that potential on every human. We are capable of such greatness. Right. We're not born to transfer data from one system to another or do the same thing in route without even considering or bringing any enhancement to that data or that process. Right. And that's what we want to enable humans to do, to get to that next level of what they're capable of. So Nidhi, I want to give you a last word. You've been at this from the beginning, 14 years. It's 1,100 plus people here in New York this week for this event. Just your impressions of how it feels to grow. I'm sure you're a proud mama moment to see your company grow into what it's become. So as you look back and you reflect and you take in what's happening all around us here, just love to get your general impressions. It's been extremely exciting. I think for multiple reasons. One is that we get to work with absolutely fantastic human beings. I think who have brought a lot of greatness to automation anywhere. And it's been an exciting journey from a career standpoint. From an industry and from a societal standpoint, I think we're also at a cusp. We've changed a lot of the world of business and how it works. And that is extremely satisfying to see if we can leave something behind from the future of work prospects for our children. It is something that I am very happy about. Good. Well, I got to get some of this automation in my day-to-day life. Let me tell you that. All right, Needy. Well, thanks for taking a few minutes of your day and sitting down with us. Thanks, Jeff. It was absolutely a pleasure. All right, she's Needy. I'm Jeff. You're watching the Q from Automation Anywhere Imagine in New York City. Thanks for watching.