Suomessa maalokonvertennaista on yksinkertaisuinen, joka oli koko ajan pari vuoksi. Ja koko ajan, kun minulla oli puolesta, oli yksinkertaisuinen, johon kysymykset, miten löytyy maalokonvertennaista. Jokainen, joka on käyttänyt SCM, tai muiden erilaisuuteen maalokonvertennaista, saadaan maalokonvertennaista. Ja se on easy to follow someone explaining the diagnostics. But there is quite a lot of quite high bar from going from understanding or high gap going from understanding when someone explains it to being able to apply this diagnostics to your own data. So when you see your software just printing likelihood values over and over and over and it doesn't seem to go anywhere, you don't even get a warning, how do you deal with it? Well you need practice and I'll first explain my own way of how I teach this to students and then I explain how you can create your own practice cases for yourself. So you can take a look at how I teach identification, what kind of assignments I give to students by going to AaltoUniversity, mycourses.alto.fi, I give a course there and you can just go and search for the course code QU-L0040. That's my advanced course with this open materials. And there is some convergence, we start talking about convergence in Unit 5. There is data analysis, assignment 4 tools and at the end there are data sets and there is an exercise about convergence problem. So I've generated these simple data sets that have a problem that I know what the problem is but the students don't know it and then the students are tasked to analyze the data do the diagnostics that we discussed in the class and then tell me what the problem is. Of course these kind of examples of data sets that don't work are not that common because most textbooks and most statistical software that I'm aware of they only give examples of model data combinations where the techniques work really well but they don't always do. So how do you create your own practice cases? The idea of creating a practice case is that you create a problematic model data combination and then you either create a problem and then diagnose yourself. This is a bit boring because you know what the problem is and you're just kind of like trying how the diagnostics work when you already know a problem. Perhaps a more challenging and more fun way of learning how to do diagnostics is to work with a colleague. So create a problematic data model combination and have a colleague troublesuit it. Challenge your colleague, see if they can figure out what is the problem in your model data combination and you can work back and forth so that you challenge your colleague, your colleague challenges you and then both of you learn how these diagnostics work by applying them and how do you come up with these problematic cases and model data combinations. There are two strategies that I use, I've used both of these strategies. One is to simulate the data set with a known problem. So we just simulate random numbers and you build a model from those random numbers requires that you understand a bit of simulation, not rocket science but coming up with nice examples might be a bit challenging if you have never done it. Another approach is take an existing data set from a statistical software user manual or a book and then an example there, break it. So I will show you soon seven different ways to break one example analysis and then you can use those techniques to break your own working models, give it to a colleague and tell them the troublesuit using the techniques, the starting values, Hessian matrix, Berners-Kovernes matrix, estimating smaller models, that kind of things and see if they can figure out the problem. One final thing that I sometimes use is that I see researchers publishing data sets and models that possibly cannot work. I've seen researchers publish models that are not identified and it's very hard to spot these in the wild but sometimes you find a paper that publishes the data set and shows an analysis result that cannot be from an identified model and then that becomes a teaching case. So these are very useful for students because they also show them how important it is to understand diagnostics because just looking at the results might not reveal that the results themselves might not be that trustworthy. Of course these are difficult to find because most people don't publish their data sets. So what some do and you find some of them like a few times per year. But now let's take a look at how you can break a model data combination. So I'm going to be using example nine from status SCM manual and this is a simple SCM with three latent variables. So we have SCS socioeconomic status that explains alien 67, alien 71 that are all variables are measured with two indicators. And this is the data code starting point. This is from status user manual. We'll just run it and as expected because this is a user manual example it is kind of like a textbook example. Then everything works beautifully. One minor thing is that the chi-square rejects this model. So we should really try to understand why it's mis-specified but mis-specification analysis is different from identification and conversions troubleshooting analysis. So we'll ignore the fact now that this model does not fit the data exactly. But in real life we would need to do diagnostics because of that. So how do we break, how do we make it not converts? I'll show you seven different ways. I could probably come up with more but these are the seven that I came up with like in the hour or two. First, rescale variable. SCM works well and numerical optimisation techniques work well when the variables are approximately on the same scale. And if we rescale education 66 by multiplying by the 100,000 this is not technically a violation of any of the SCM assumptions. So the model should work but computational issues start to emerge when the variables are measured on a wider different scale. We run the model and we can see convergence is not achieved and our state does not really give us any other indication in the warnings on what exactly might be the problem. If we take a look at these missing standard errors then we might be able to start pinpointing where the problem is and this problem could be perhaps best discovered by analysing the Hessian matrix where you can see that the magnitudes of the secondary ones are pretty different than you would probably know that well. There is something weird going on in the data. Another one is linear dependency between parameters between variables in the data and this is a violation of the maximum likelihood estimator. There are other estimators. You could perhaps do unweighted least squares or something like that which would be able to estimate this but ML can't estimate one of these because there is redundancy between the variables. We can see that there is no unique information. We would say that the sample covariance matrix is not full rank because there are linear dependencies. This also breaks SCM so you can see convergence is not achieved. How would we go troubleshooting this? This would be more of an identification issue kind of problem so you might be looking at the Hessian matrix and gradient vector to understand where the problem actually is. Then you can use weird starting values. Starting values or lack of starting values, starting values that are really bad cause computational problems. The simplest way of having weird starting values is simply to disable state of starting value algorithm by using no IV start and then it is the user who is responsible for setting the starting values. If you use no IV start I think all parameters start at zeros or something like that and there is no convergence. You get this warning and then convergence is not achieved. These variances look pretty weird once and point once because they are exact numbers then that indicates that the optimizer does not really know what to do with them. Normally they have decimals but in this case the starting value is one and the optimizer doesn't know which way to go because it appears that probably that appears as a maximum originally. But this would be identified either by printing the starting values you might see that they are weird or you might do print the Hessian matrix to see which estimates are not identified. Then you can do models that are not identified. In the first model we had SCS, Alien 67, Alien 71 all connected with recursion paths. I'm eliminating these recursion paths from SCS, Alien 67, Alien 71. SCS is now a single two indicator factor that is not embedded in a larger system. To be sure I set the covariance between SCS and all other variables to be zero. The identification condition for a two indicator factor is that it must be connected sufficiently strongly to other factors to identify the loading. This is not identified for sure and we can see here that convergence is not achieved. We have missing standard error. That's an indication of an identification problem and you might be looking at the techniques for model identification to see what exactly is the problem. Then you can see that it is the loadings of the SCS factor that are the problem here. We can also do another model that fails because of decrease of freedom. So the decrease of freedom for this model is problem positive but we have only three covariances between latent variables and we're trying to estimate four paths. You can't estimate four things from three things so it's not identified for sure and we run them all. Surprisingly there are no warnings so some researcher might actually think that these results are trustworthy because the software does not tell us anything but our closer inspection reviews that we have some very large standard errors here. So that would indicate that there is some kind of identification problem with the model. So large standard error is an indication of an identification problem to fully understand the problem because we have convergence now. We would print out the variance covariance matrix of the estimates and then we would see which estimates are competing for the same covariance and we might see that the two directional paths they can't be estimated from this data. Then we have empirical identification. This is a data issue so this is very similar to the case where I constrain SCS to be uncorrelated with the other two factors. Here I allow SCS to be related to other factors but I take the SCS or actually I take the Alien67 indicators and then I make those indicators uncorrelated with everything else in the model. So I basically take the Alien67 latent variable and I make it unrelated to the other latent variables in this dataset by this orthogonalization technique and this produces empirical under identification, no convergence, missing standard errors. You can troubleshoot this with the identification techniques that are discussed in these videos. The final way to break a model that I'll demonstrate here is to make a model that is severely misspecified. So my misspecification here is that I constrain these indicators of Alien67 and Alien71 to be invariant over time except that the 71 indicators are negatives of the 67 indicators. As more sneaky way of doing the same would be to constrain their indicators to load the same over time but simply reverse code one occasion. Why does this break the model? It breaks the model because all these indicators are positively correlated in the sample and this kind of constrain forces some of these estimates to be negative and the computer doesn't like it. So when we run the model we get this kind of weird result that the warning, the LR test is not reported because of identification issues. We don't get an error but we can see that some of these standard errors are pretty huge so that's an indication of model non-antification. We also see very large, very small estimates for factor loadings. They should be a lot larger in this data and also negative factor loading is something that you generally should be looking at a bit more carefully to understand why there's a negative loading. So that is seven different ways that you can break a model and then these seven different ways can help you to check how these various estimation or troubleshooting techniques work. So my workflow for dealing with this is I would first read warnings if there are any, then I would check standard errors, I would eyeball identification issues after drawing a path diagram, print starting values and adjust if needed, print gradient and SN or print the variance covariance metric of the estimates. That tells you something about identification quite often. Try different optimizer, it wouldn't solve any of these problems but you might still try, then estimate simpler models, use those as starting values. That might work for some of these cases and then empirical identification checks like simulating datasets or running the same model using different sets of starting values. So this identification checking and this non-conversion diagnostics, they are something that if you just read or watch a video on YouTube, you are unlikely to learn it to a level which is going to be useful for you. So this requires practice and you can get the practice on a good course or you can get the practice using the techniques that I explained here, take a model, break it and then try to identify what is the problem and this is actually how I generate some of my teaching cases so I break a model, I give it to students and then that forms their assignment. They have a week time to discuss it together and then after a week we can see if they have come to a conclusion what the problem might be. Interestingly, quite often the students come up with different potential problems and only one of them would be correct.


Are you ready for warm weather and a little sunshine? The Appalachian wireless team has decided to have the ultimate spring break event. The spring break event is going on now through the end of April and all smartphones are on sale with Appalachian Advantage. We are you, we are Appalachian Wireless. Forty-year quilt maker, Ben Eisen, will be setting up an exhibit titled, Stories Told Secrets Revealed This Month at the Appalachian Center for the Arts. In preparation, Mountaintop spoke with Eisen about what we can expect. I am so lucky, I have gotten to set up this exhibit here at the Art Center. It's called Stories Told Secrets Revealed. It's a quilt exhibit of ten of my quilts and it's different than a usual quilt exhibit because it includes the stories behind the quilts and all their secrets. So as a quilt maker, I like to tell stories, but mostly people don't get to know what they are. In the spirit of telling stories, each quilt will be displayed alongside a statement of its history and inspiration. One story, in particular, the tale of a missing family member. Quilts are diverse because I'm quilting out my life and my life has lots. We don't, none of us live on just one, have one story of our lives.  So I draw stories from the stories of my husband's family, from his mother whose sister disappeared when they were young in 1946 and wasn't found until years later. So I made a quilt to talk about that story to see if we could use it to help us find her sister Dixie. Where the quilt behind me is a quilt called The Key Is Found and it's about the things that people search for in lives, in their lives. And I made it because I was searching myself, trying to figure out why do we create and what makes us creative. And as I was asking that question, I kept pulling other stories and putting them into a quilt. And while the goal of Eisen is to tell stories through her quilts, she hopes to hear from others. A quilt called America Unraveled and Rewound. And what I would really like for people to do is there's a small journal with it where people can write their thoughts about what's the candle in the middle of America that we should be circling up to protect. And what are the things that we can do to make America more united? So for me, the present for me would be if more people would write in that journal their thoughts, whether they're happy thoughts or angry thoughts or good thoughts or bad thoughts.  To see the exhibit and its progress, you can visit the Appalachian Center for the Arts Monday through Friday from 2 to 5 p.m. For Mountain Top News, I'm Joel Chorjol.


the next one is if he cheats with you he will cheat on you and so this goes back to you know some of the videos we've done recently and it's just like we keep getting these women that come into our community and they're like hey i'm dating this married man hey i'm i'm married and i'm dating a married man and you're just like oh my god how many times do we have to go over this you know and it like i and i get it you know you you're you know things happen in marriages and you get bored and things you know aren't always going right and then you find this other exciting thing going on and all of a sudden you're like oh my god i'm in love again and you know all this other stuff but it's not with my husband and maybe i made a mistake or whatever right and it's just one of those things like here so first i'm going to say my suggestion right which is stop dating guys in relationships stop dating guys who are married stop investing in these people and if he really wants you he'll figure out everything with the other person before you guys get together and so don't get involved in something that's messy for the most for most people you don't need to get involved in something that's messy and you know that it's messy so don't get involved in it and sometimes i get women i got a woman the other day and she was like oh well what if i didn't know until you know three weeks in until a month in of dating this guy that you know he was married and it's like yeah but you know now right like just because he didn't tell you it doesn't give you an excuse to start to continue seeing a guy that's married doesn't make it doesn't make any sense just stop it just stop it just just please stop it just please stop it please stop it all right i didn't turn it off okay please stop it okay stop it stop it stop it


All right, welcome to Wassum in the Wild West, a practical application tale. I'd like to introduce you to your outlaws for the day. I'm from Colorado and we are definitely cowboy-ish here. I'm Matt Butcher. I lead an open source team at Microsoft. I have worked on Helm, Kubernetes, various pads systems, OpenStack, and this WebAssembly world is my latest foray into the wide world of cloud. You can reach me at any of these social media handles. And I'm Taylor Thomas. I also live in what used to be the Wild West, but that's not why we're seeming it this way. I'm a Cresslet and Helm Core Maintainer emeritus. I've been doing Kubernetes things since around Docker, since 1.2 and Docker around 0.7. So I've been doing this for a while as well, the cloud native space. I came to Rust by way of Go, which kind of makes sense given the Kubernetes background. I have a problem with consistency with my social media handles, given when they were created and whatnot. And I'm always afraid to change them because we all know what that can do. So yeah, that's us. So let's go ahead and just get straight on into things and talk a little bit about just kind of a, to whet your whistle, let's talk about the projects that we're gonna be referencing in here a little bit. And we're going to be talking and focusing mostly on WASM, but we wanted to give these as kind of a backdrop. So you know where we're coming from. So both Matt and I have worked together on all of these projects, along with the other members of our team. And the first one is Crestlet. In Crestlet, we are running WebAssembly workloads in Kubernetes. And so this allows you to take whatever kind of compatible WASM binary and be able to run it inside of Kubernetes just like you would a normal container. It's not running in a container, it's running actually just as a straight WASM binary. And then Bindle is an aggregate object storage engine. We've given another talk on this in case you wanna check it out. This allows us to store all of the WASM things together. And then last is Waggy, which we kind of took from all of our dogs on our team. But it is an easy way to write cloud side WASM kind of as a HTTP handler. So those are the three projects that we've come from with all of this knowledge as we discuss how we've used WASM and what it's like using it in really what is the wild west right now. So let's go ahead and kind of explore how we got there. So my team, our team meets usually under normal circumstances about once or twice a year together. We're distributed most of the time, but we like to get together brainstorm about cool interesting ideas and go through a number of exercises to see how we're doing. Well, in 2019, we all got together in Vancouver and Vancouver Island rather and had our typical offsite meeting. But somewhere along the way here we got sort of sidetracked from our usual Kubernetes container virtual machine helm kinds of conversation and got going on WebAssembly. And we were talking about the interesting aspects of WebAssembly's runtime and how while it was intended to run in a browser it actually had a lot of potential for running on a cloud side and creating the kind of isolated runtime that we need in multi-tenant cloud situations. So as soon as that sentence sort of made it out into the room, we just started talking and talking. It was after dinner. We must have spent hours sitting at a table in the restaurant just talking through all these various scenarios with ideas sort of flying fast and furiously. It was a lot of fun. Finished up our meeting, all went back home and then a month or so passed and we decided to give it a shot. And the first idea was to try out building a Kubernetes kubelet that could execute WebAssembly. We wrote this in Rust, so we named it Crestlet because kubelet, Rust seemed funny to us. And it turned out to not be too hard to basically just write a small amount of code that could connect to a Kubernetes cluster, advertise itself as a Kubernetes node. But when it got a request instead of pulling containers and executing containers it was pulling WebAssembly modules and executing those. So this was sort of our first heist. We were pretty proud of ourselves. We got enough of this done to show off to a few people. And of course it started peaking more and more people's interests. And what happens is that your cute little proof of concept suddenly runs into actual production use cases and people say, can it do this? Well, no, can it do that? Well, no. So then we had to sort of upgrade from a heist to an all out great train robbery style thing. And we went from a proof of concept to an MVP. And anytime you make that an MVP being a minimum viable product, right?  So we'll talk a little bit more about that here and also in our talk about Crestlet in the, no, sorry, the rest day event. But we got going on that. It was very exciting. The team got together, produced something really cool and more and more ideas started to percolate up. And we wrote Bindle and then we wrote Waggy and then we wrote an HTTP client library. And then we started writing Yo-Wassam and more and more different projects that got us really kind of deeply entrenched into the WebAssembly ecosystem and deeply, deeply passionate about the tools and the potential that we were seeing there. So that really tells the story about why we care about what we're talking about here. We wanna talk about what we've learned, what some of the gaps are because what we've noticed is that many times at these Wassam conferences, everyone is looking into the clouds, which is a good thing. That's what we want here. This is such an exciting area, but we sometimes forget about the people actually trying to implement this in the Wild West. So we wanted to talk about the things that people on the ground are running into right now. And so first off, we have this saying if it's never too late to check your cinch, if you have never ridden horses before, you have a saddle that sits on top, which is obvious, but then underneath, there's a cinch that runs through. And you always wanna check it for two reasons because either you'll cinch it too tight and your horse will pass out on top of you or you'll have it too loose and it'll slide right to the side or off and you'll fall off. So both ways you end up under a horse and falling off. So this is kind of our, well, what did we learn in this whole experiment that we've done? And first off is our horse and pony show. We're gonna do a little bit of comparison here. So one of the things that happens is when people talk about Wassam, they're like, well, and they always hold up a finger, haven't we tried that before? And it's like, yes, I mean, everything kind of reinvents things just every 10 years, we know that. But let's talk about some of the most common ones as compared to, we'll start off with the Java VM. The Java VM is very tried and true and infinitely tweakable and configurable. People have careers at tweaking the JVM. However, it is very, let's just put it nicely bulky. It takes a lot of resources and it's very large. So it's just kind of bulky. And also it's limited to a single language ecosystem. Now, granted, you have Java, you have Kotlin, you have all the different things that run on top of the JVM, which is great, but you're still limited to just that ecosystem. And it's also a little bit of a leaky abstraction in that the Java libraries encompass everything from files and networking with no real way to say, when I say, when the guest module says, I wanna file the host module can fulfill it this way. And of course, there have been many tools written to do that, but one of the things we liked about WebAssembly compared to Java was that WebAssembly provided some of that for free right out of the box without quite the, as Taylor put it, without the sort of bulkiness of Java. Containers were another one that we were fairly passionate about. We've done a lot of work in the container ecosystem. Container system, they're more lightweight than Java in a sense, right? Particularly single, well-made, sort of carefully crafted containers. You can get fairly small ones. And you can run things written in just about any programming language provided it meets the operational constraints you need to execute a container, right? But cross-platform is hard with containers. So there have been many, many attempts to do them in different ways with running Linux containers on Windows, running Windows containers on Linux, multi-architecture containers and so on. But a lot of those require extra build steps or other specialized tooling. And oftentimes also added some constraints upon what the developer themselves had to do in order to make this run in the expected ecosystem. And that brings us to the actual Wasm run times. So especially, and this is really in comparison to the Java VM and also containers, the thing with Wasm run times is they're very lightweight, both the run times and the binaries. We're gonna talk a little bit more about that in a second, but the binaries can be very, very small, especially in comparison to a container, even well-made containers. I'm not talking about the nightmare containers that are multiple gigabytes. I'm talking about well-made containers. They're still smaller than that. The other thing is that it's sandboxed by default. And so for us, that's a very important thing because you are completely locked in without having specific, what are called capabilities granted to you to be able to access files or access network or whatever it might be. And Wasm run times are the closest thing we've seen in a while to be truly cross-platform. I can build a binary on my Mac, have it run on my Windows machine, have it run on my Raspberry Pi, have it run on a Linux server in the cloud, and I built it on a Mac. There's no changing, there's no different, like it's just the same binary. And there's also this idea of being able to compile from any language without additional steps. So with Docker, it may developers have to learn the intricacies of all their dependencies, which in one sense is good because sometimes in the old fashioned way of doing things, developers are just kind of shovel it over to the ops people. But the thing is as devs, that's not their specialty. And sometimes there's little nuances that people don't know about unless they've done it for a long time or that's their specialty. And so you have to know about that with Docker files and building a Docker image. But with a Wasm run time, as it stands, you can just compile into a Wasm binary. There's no special steps except specifying a target. And that's obviously depends on the language, but you can compile straight to it instead. And one of the interesting things about WebAssembly is that it's already a W3 standard. And there are already many, many run times available for WebAssembly that all implement consistently the same spec with different pros and cons and advantages and disadvantages to the way it executes it. But the same WebAssembly module will run on say Wasm3, WasmTime, and script and so on. Which brought us to our first choice, right, Taylor? Oh, yes, the language. So this is always this, we all know as developers that languages generally cause flame wars. We are trying to avoid that here, but we're just trying to inform like why, why we decided the way we did. And for us, it came down to be a question of Rust or JavaScript. Now that doesn't mean other languages can't do it. We're gonna actually talk about that too. But the idea was with JavaScript, it was the first language to do Wasm in a real, quote unquote real way. It's obviously flexible and very popular as the creator of JavaScript is said, like bet on JavaScript. I mean, and Wasm, he said actually, but like there's good reasons to use JavaScript. It's very accessible to people, but really even with Node, it's not as good for system level development as other languages. Rust has the disadvantage of being newer and having a still evolving ecosystem and therefore not being as popular. And even if it was as popular, it's definitely not accessible as JavaScript. Most of the tooling though on the bleeding edge of the Wasm space is written in Rust. And it's amazing for systems level development with really, really strict and good safety guarantees. So we chose Rust because those, even though it was less popular and we'd have a little bit harder time getting people hooked into it, it was much better for choosing how we did or building things for how we were going to do and use Wasm. Yeah, it's sort of in the end for us. Even though we chose Rust and we use it in our major projects, we do still do a lot with M script in and Wasm 3 and other runtimes. We just found that our projects, we would probably stick to Rust for the main ones, but in the end doesn't represent any hard feelings or anything like that toward any of those other runtimes. One of the really interesting things we've been learning as we've been doing WebAssembly is the long path to optimization. And this is a virtuous long path to optimization. When you, the compiler is going to mainly just try and transform the source code to WebAssembly's byte codes, right? And so when I was playing around with Swift, my first Swift application when I compiled it to WebAssembly was about 9.8 Meg which was considerably larger than most of the other languages I had compiled in. So I went about kind of investigating the different ways that we could optimize this and there are many tools out there. Simply running the Wasm opt command line reduced my binary from 9.8 Meg to 4.3 Meg by stripping out pieces of the WebAssembly code that actually weren't called or weren't used and doing some other optimization passes to compress down some of the symbols and things like that. So instantly I cut my binary size in just over half just by running a tool. But then we started looking at all these various other techniques out there. And there are things like being able to preload the binary into the runtime to allow you to start up to allow you to drop startup times from maybe a hundred milliseconds to just nanoseconds there are fractions of the amount of time. Running in a runtime with a JIT optimizer means we could get even faster run times. And we're even experimenting now with ahead of time compilers that when we know for example we're running in a pass kind of circumstance and the end user has uploaded a WebAssembly binary we know that the user's intent is to execute that binary on the platform they uploaded it to. So we can even do ahead of time compiling on that and even achieve further optimization and faster startup time. And there are even some amazing tools that are being developed out there. One of our current favorites is called Wiser. And this can run the initialization code on your WebAssembly module.  So there's some tools like this that are just sort of mind-boggling but opens up the possibilities that WebAssembly is presenting us with because of the way the format works and because of the sort of flexibility of the runtimes and the multiple implementations of runtimes. This kind of leads into the idea that there are many different ways in which you can execute a WebAssembly module. So it's not merely a matter of how you optimize it prior to starting it up but WebAssembly is structured in such a way that you can run it in a flat out interpreter which will execute as it reads through the WebAssembly file. This is excellent if you are working in an embedded space and you only want to allocate very small chunks of memory as you're executing things. So WASM3 which is a great interpreter if you're interested in running in Arduino's or other limited space devices it uses this interpretation model. But for when we're optimizing for speed we often wanna go one step further and look at a JIT style compiler where as it's reading in the byte codes it's compiling it into an intermediate representation then might take more memory and might consume more CPU and other resources as it's ramping up it tends to execute much faster. And then I think I mentioned on the last slide even now we're looking at ahead of time compilers WASM time now includes a with I think 0.26 now includes an ahead of time compiler. So you can even pre-compile some of this stuff which even speeds things up further at the cost of having to have storage and also at the cost of sort of having to bind it to one particular runtime as you're executing or one particular family of runtimes, right? But again, if you're willing to make that trade off for speed ahead of time compiling might be the fastest object. But the thing that we really appreciate about this is the developer never has to be concerned with whether it's running in an interpreter a JIT environment and ahead of time compile environment or whatnot that the developer simply writes their code and compiles it and something else can optimize something else can tweak and tune and something else can run it and the developer can be blissfully unaware of that. We like that because that tends to alleviate the kind of operational decisions from the developers plate while at the same time giving the operation staff all kinds of options for how they'd like to execute something. So the last thing in our learnings section is around the WASI spec. So this is really important to us. So we consider WASI to be the future of WASM. Now that isn't meant to be a technical declaration or more a community declaration. We'll talk about that a little bit but it gives us a common interface that any WASM project can then build on. So these can be POSIX-like or libc-like APIs common abstractions for passing data. Now the thing is it is still very, very much in flex but progress is being made. We're adding streams, we're adding starting at least experiments with something called nano processes. All these things are very important but for us the most important thing is just being able to do this in a way that allows people to extend and build on top of a great foundation which kind of leads into some of the next things we're gonna talk about. So our next topic we're calling keep your butt in the saddle. Now that is a phrase that I hear my wife does horsemanship stuff and that's a phrase you hear all the time.  So this is kind of our discussion of how we can avoid the gap. And to kick it off, I wanted to talk about something that is very close to what the last thing was around the WASI spec is around community fracturing. And this is a potential gap that is very serious for us. So in general, there's an unevenness across all these different WASIM implementations. There's various runtimes and protocols. We have WASIM time, WASIMer, WAPI-C and WASIM cloud. There's WITX bindings. There's other projects like suborbital and the thing is is each project has its own buy-in. You have to use their custom libraries and their custom things. And really there's no major community or foundation to use as a gathering place or a watering hole, shall we say? Given the theme of this talk there's no community place for us to just talk these things over. So where we want to be with this, and this is meant to show the gap as we would like common specifications with various implementations that people can build around them. We would like to have less lock-in to custom libraries and we want a better community, collaboration, meeting, foundation space to do this. Our opinion in all of this is that we're better together. If we can work together, like we know that there's going to be things, there's competitors working together to build this, but we don't have to like this foundation doesn't have to be something we compete over or to create competing standards. And the thing we worry about as we've observed things we worry the community is trying to do everything right now in fracture, which will cause lots of problems in the future. So we would prefer to be where what we kind of listed in this right column. And in a moment, we will come back and talk a little bit about where we see Wazi on this particular, where we see its role in this ecosystem because we do believe that the Wazi specification may be sort of the key to help tie this all together. But before we go there, we wanna talk about another thing that is actually very near and dear to our hearts, which is the developer experience. To us, we feel like at the end of the day, developers are going to use the tools that they feel the most comfortable with. And the tools that we use as developers today, they could use improvement, always they could use improvement, right? So we want to be part of that story of how we improve the average experience of creating code that can run in this kind of cloud native ecosystem. So where we are today, we see a lot of work in order to bootstrap environments and in order to get objects imported in a web assembly of runtimes and so on. We see a lot of work with custom bindings and annotations, each of which matches its specific little platform, like we talked about on the last slide. A lot of work with sort of like bespoke tool chains where you've got to line up, you need these four things, you need to execute them in this order. But if you're writing for that platform, you need these six things and you need to execute them like this. A lot of stuff that just becomes developer cognitive overhead. You've got to do all of these different steps before you can run your application. One of my, my boss, Brandon Burns, was recently saying, I just wanted to create my first web assembly module and I had to go through so many steps just to create Hello World that it was really frustrating, even though it was so exciting to then have this binary that I could use in all these different environments. That's the kind of experience that we want to alleviate, right? And then what we're seeing is the very beginning of an emergence of sets of tools that we'll be able to do this. We've worked on one called Yo Wasm, which is a Yeoman generator for web assembly, where it'll walk you through the process of saying, yeah, I want a C project that will compile to web assembly. And I want to use GitHub Actions and I want to push my resulting artifact here and then it'll scaffold everything out and set up VS codes so that you have a nice, pretty environment. The Wash CLI for Wasm Cloud, we're very excited about because that ecosystem has gone from very much the nine steps from development to running a test down to this nice little CLI experience where you can run a CLI interactively and it'll help you bootstrap everything and get it running and you can instrument your running process. So we are seeing things start to move in the right direction, but we want to be even further, right? We want this kind of one step where you say, all right, build and deploy this thing and it builds it, signs it, pushes it and then the next thing you know, you're checking out the results of your work to see if it all looks good. We do think that there is room in here for code generating, particularly as we start seeing multiple language support where you might want to be able to very quickly say, okay, I want the same functionality and see that I had over here in REST or that I had over there in AssemblyScript or whatnot. And then finally, we want to be able to compile a web assembly binary as easily as a normal binary. And some environments like REST, I feel like make this trivially easy while others, the compilation process still needs a little more tweaking before it feels quite as native and quick as it does in REST or maybe AssemblyScript. Now, as Matt mentioned, we're going to talk a little bit more about Waze. So where do we, where are we at with Waze? So in case we hadn't mentioned it yet, Waze is the web assembly systems interface. It's kind of this main spec that we were mentioning. And where we're at right now is that networking is kind of a mishmash of stopgap solutions, including something in that mishmash is something we wrote that's our Waze Experimental HTTP project that allows us to get some sort of HTTP support. There's this current ongoing streams versus POSIX debates that is kind of the current, I guess, topic of discussion inside of these meetings, inside the W3C group subgroup. And also concurrent tasks and nano processes are, there's some solid design ideas, but they're still just an idea. There's only a few kind of very, very experimental implementations and ideas. So where we want to be, and this is kind of a, in a year, because ideally we want everything to be all in place and a wonderful 1.0 spec. But where we'd want to be in a year is a working stream implementation, which allows for flexible extensions on top. So for IO, networking, all those things, and we would like an initial nano processes implementation. So that's kind of where we'd like to be at in about a year. That streams, the IO streams, IO array work that is happening under the streams kind of idea is what really opens us up to being able to write guest modules that rely on resources outside of them, and we can write very convenient APIs. So we can very quickly write things like key value storage drivers, database drivers, file system implementations, and so on. So if we can get there in a year, then we feel like we've really unblocked kind of the key bit of potential that is currently sort of locked up in the WebAssembly ecosystem and is accounting for a lot of what we're currently seeing as fracturing in the ecosystem. So we're optimistic that that could really sort of re-level the playing field and get everybody excited about building together instead of each separate project having to kind of build their own thing. So we'll go ahead and whisk through these last two points just because they're relatively quick so we can finish up with why we're excited about all this. So one of the things is guest languages. There's really only five and of those, if we're being honest, like the ones that people use in production, there's three of them, Rust, C, and Swift. And the others kind of have, they can build Wasm for the Web, but they don't really build Wasm for like wazzy compatible things. So where we would like to be in a year again is that we'd like to have first like native-level support in C-Sharp, Python, Go, and Java, something like the big names in enterprise development just so people can have an easy target.  We love Pearl. And then the last thing we have is storing and sharing. So right now to store a WebAssembly binary, we use OCI, there's a Wasm to OCI tool that allows you to store inside a container registry. We have our OCI distribution crate that we've written in Rust. There's other object stores people have used and other companies like Glue that have created their own custom registries. But really where we want to be is to have better OCI support. We know that we can never escape like having OCI support in specific places in the cloud native ecosystem, but also something like Bindle, our Agria object storage engine we've worked on. Now, obviously we're biased towards that, but it's something along the lines of how we would like it to work in the future, which you can check it out by clicking on the link there. So those are the gaps we've seen, but we really just want to close with our excitement for this. Yeah, the reason that the things that got us excited about this when we first looked at them at Vancouver, you know, a couple of years ago are still the things that we are really excited about. We see here the potential to have a secure lightweight VM, language VM that is portable and that ultimately with just a little more work will deliver a really, really solid developer story. We feel, we know we all need to work together and it's exciting to see the community sort of starting to form ad hoc and common patterns emerging, largely the people in the WebAssembly ecosystem, we all know, we've all done this before and we're all going, okay, we know that if we start working together and sharing information, it's gonna make everything easier for us, everything easier for our users and ultimately, you know, that kind of translates to an ecosystem that's inviting and approachable for new developers or new developers in this space. And really like, there's a gap here that we can fill because there's not, we don't have this nice portability with a very small footprint that just doesn't exist yet and that's such a big gap in the cloud native ecosystem that would make a lot of people very, very happy combined with that developer experience. And also this is kind of our call to action to just help us gather the wagons. This conference is a good first step. It allows us to talk about these things with people who want to have these features we've talked about, but as if our invitation is to join into this community and help out so that we can get, wasm to the point where it's accessible for everyone and that we can get these features. Yeah, and there are places like the WebAssembly Discord server is a great place to get connected with people as are, you know, the various issue queues on the various projects. And of course, you're more than welcome to reach out to Taylor and I and the other people on our team because we are passionate about getting this community sort of rallied around the wagon circled and doing some really interesting, cool things over the next few years as we see this ecosystem go from, you know, some fancy ideas to something that we think is just going to be a lovely experience for developers and a powerful experience for operators. So thank you very much for coming today and please again, reach out to us if you have questions, comments or just want to get connected on this stuff.


It's been an unbelievable week here in the UK and I'm here on day 3 in testing out at Conway Golf Club. That's been a backdrop all week. A little bit more breeze today but it's absolutely been a stunning week. And today I'm testing a real interesting product. It's a forged iron from Callaway. It is the epic forged iron and there is a lot packed into this clubhead, believe me. But before we go any further and I'll tell you what Callaway is saying is packed into this and how it might help you as a golfer but first of all we've got to talk about the look to these irons. Throw some more images up on screen for you now and give me your opinion. I mean I think from my eye they've produced one of the best looking clubs that I've seen on the market. I really mean that. It is, I think it's an absolutely stunning golf club. There are no more words really, interesting your feedback but the way that is pieced together really really suits my eye and we'll talk about how it sits at address very very shortly and how they've achieved other things in the sense of the profile and the build but from a looks perspective unbelievable. But what about the technology that's packed in it and the technology that is going to justify why these are so expensive. Let's have a look at the tech inside of this clubhead. Right so you've heard what I think in terms of the looks and interesting your comments down below. What is, am I going overboard on these or are they as stunning as I think they are. That's a personal thing. On to the technology that Callaway has packed into this club and believe me it's a lot and believe me there needs to be a lot because we're going to come to the price very very shortly. It is a 1025 carbon steel forged body. Inside that body is you've got some tungsten weighting. The tungsten weighting is wrapped in urethane microspheres, the urethane microspheres is dampened sound and vibration but they're saying it's not impacting on ball speeds either because there's this 360 cup face technology which is again all about ball speed right across the club face. I'm also talking about that a bit later on as well. The tungsten weighting, the suspended energy core as they call it, it just allows them to position the tungsten weighting exactly where it needs to be to get optimal performance out of each iron so that will be in a slightly different position for what you want from each iron. So a longer iron compared to a short iron obviously the characteristics that you want are going to be slightly different and that's what this allows them to do. They've got two shaft options, interesting as well. Steel fibre or graphite. I'm going with, I've got a 10 site white graphite shaft at the moment, 60 gram shaft, interesting to see how we get there and how this thing performs. I'm going to talk about price very very quickly because there's a lot of technology and I think from listening to the press release that came out from Callaway, I think they've packed everything they've got in terms of tech, what they've learned over the years, everything they've got is packed into this club but it comes at a price tag. It's going to be not far off, and I'm talking not far off, 282.90 per club, that's the RRP. Likely odd is it's probably going to be about a 250 per club at retail. So it's a high high price point but carry on and keep watching, don't switch off now because I know some of you will be offending by that price point, carry on and keep watching and just see what you get for your money in these ions, these epic, flat, epic ions, forged ions from Callaway. Today I managed to hit a similar shot, second time round. Interesting ball flight on the 5 iron, it was slightly down breeze but it's a really good ball flight, it's a strong ball flight. You'd be concerned about the lofts and I'm interested, it's the first long iron that I've hit and interested to see as we go around the course which is where it really matters is how these strong lofts are impacted on the performance, in other words can we get the ball to stop on the greens or is it just too much of a low penetrating flight, we'll find that out very very soon. For a great start, like I said, two balls I hit there, one off-camera but really got them both out the middle, and it pretty much was out the middle so we'll see when we get some off-center strikes out of this performance, one of the big claims they've got is just again, from Callaway you'll see this image that I throw up in front of you now, that's a sort of heat map about ball strikes across the face and you'll see just how little loss in terms of distance that they've got in different areas of strike points around that face and that's the bit that always interests me as an average golfer because it's likely that I'm not going to continue finding a middle of this cool place. You've got the ball flight on that, it's right down so the target line on number 12 is right behind the green there. Again, it's got a tight light, really nice pick-up, first two shots really impressed, that's all I'm going to say at this stage. It's a 9-9, it's really compact behind the ball which is something that I'm still really liking, you're not for what's packed into this to get into such a small profile is again something that I think's been amazing, great feel, it's a little bit of a bounce off the face there, which I like, which is a nice feel, again it's got a nice sound to it, a nice click off the face there, very controllable, lots of feedback back into the hands but like I said when you throw the ball on a major thing, how small and compact this club head is, it looks to all intents and purposes to, they've done this thing again with this sort of two-tone cambered top line which gives a bit of an obstacle illusion and it sits very nice behind the ball and like I said I take them to all day long, this is all over the flag, this is the right club, come down off the bank, come down off the bank, stay on the bank, right okay so 160 yardage downwind and 9-9 is what I just played, again decent ball flight on it which is what I really like about these things at the minute, one of the things I like about these, stay left to the flag, ball didn't move a great deal in the morning with the strike, it's an interesting one because that didn't come out the middle, it still travelled the distances in this idea, one of the things I'm always interested in is appeal to average golfers in terms of like that little bit of helpfulness across the face and as I say you can see there were a little bit of grass, it's low and off the toe but still did a decent job. As ever I like feedback and it's your opinion that really matters and counts, you're the people that are going to be buying these clubs at the end of the day, what are your thoughts on these irons so far? Impressed? Impressed with performance? Do you like the looks? What's this price tag? Lots to comment down below so make sure you get involved in the conversation because I love getting feedback. Just checking out the microphone on, that came out a bit out the bottom grooves but again to be honest with you that's one of the things, I've not been swinging that great with the irons this morning to be fair to Epic as well, to Callaway but one thing that sometimes impresses me more than when I'm absolutely getting them straight out the middle is what a club does when it's not so great and again you've probably heard that, I don't know whether you can find it, it was definitely bottom grooves but the ball is still going out there. It's an incredible way to get these clubs and it's not just this club let's be fair there's a lot of clubs now by where it's that help and forgiveness across the club face however you want to word it, however you want to term it in a straight old-fashioned old blade if we strip back all the technology that you might think is in this a straight back old blade and that's a ricochet straight up the forearm and it won't go far at all. With today's technology and it's got everything packed into this in terms of technology that ball is still done incredibly well and it's a fair way finder on 17. Just want to talk about the irons at address, I mentioned it briefly earlier you do see a little bit of the bottom end a little bit of the mass but the top line is chamfered and it's slightly thinner it seems to be slightly thinner for me on the shorter irons. Minimal offset is what I'm looking at and it just really does sit nice behind the ball. As ever I don't know about you but I'm a fan where there's the two colour in terms of the satin finish and the high chrome finish really frames the centre of the club but yeah it sits very nice behind the ball that's all well and good but can you miss them three bunkers down the right hand? I think they're out of reach we're a bit of a wind in. Can you pick up the ball flight? I mean that's a five iron strong lofted five iron. It's the middle of the fairway and it's just gone absolutely powerful penetrating ball flight right up there I mean it's landing on a firm fairway in the Highs of July I think going far so well unfortunately it's gone straight into the bunker if I got the switch on yes I have I keep forgetting that bit it's gone bunker left it stayed there hoping again for a little bit of copper at the minute in these things nothing but straight which is probably a good thing right just to note that was 170 into middle of the green there and we were perhaps a little bit down breeze but I give that one I went after it a little bit as they say and certainly there's plenty of distances packed into these things if you're looking for it. I'm gonna stop here and do my overall assessment of what's what I think of these irons but before I do it I want to get two sort of elephants out the room because there are two things that are going to produce the majority of comments the price now the price point is always the same for me I couldn't care less what anybody charges because at the end of the day it's up to you to consume whether you go out and buy them or not and it's the same for these some people will never entertain that kind of price others will so I dismiss that when I'm reviewing a product the second thing is the lofts once again it's a strongly lofty club I've done three videos this week on irons out here at Conway Golf Club and each one of those irons has been lofted at 27 and 28 degrees in terms of a 7 iron so again for me believe me and I said it over a year ago this is going to become the norm for irons moving forward but it's not about just about getting distance it's about this counterbalance between tungsten weight in lower CG counterbalance in what launch would be effect if we didn't have this strong loft on them so you can already see for me there's a complete well it almost goes against the grain both like that that does not relate to the loft that is on this nine but anyway let's forget those two things for now in terms of performance these are they're very very good they're excellent again how would you knock club like this I said earlier on one of the irons I've played I've not hit the ball particularly well today in terms of my swing with irons but I barely missed a fairway and I don't think I've lost a great deal of distance in all of those shots as well so that's you know you've got to hold your hat off and say that ball straight out the middle and it's pure but I've hit balls like you said from back on this T that came out the bottom grooves and again the distance that it's getting and this idea of urethane microspheres whatever they are the sound dampening the vibration dampening you've got to believe that it works you know I mean whether you like technology or not these things do work and the point is always the same what will you achieve what you're looking for from your golf game but if you're into this kind of product if you're into tech if into price point that these are right and you're prepared to go to that kind of budget then you've got to put them into the mix to the similar type of clubs Callaway have come out with what they say is a very much packed with technology I love the look of the irons I think the superb question is are you prepared to go out there and buy them and at the end of the day that's all that matters it's just your opinion that counts I'm gonna carry on it in some more golf balls thank you for watching thank you for watching this video make sure you stick around because I'll be testing the year I'm in the middle of testing the epic flash hybrid and a point to mention on that really combining the two videos together I think what's a very interesting one is a mixture of these irons in the low end and then from six onwards going into the hybrid unreal set of golf balls I'm finished


What is going on guys welcome back to the channel critical overlord here? So just some brief news that came out yesterday or actually the day before your stay on Sunday On July 31st actually this came out on July 31st This is a tweet in reference to the upcoming screen five movie. We know we're getting Basically what has happened is this project has gotten yet another stamp of approval. The script has anyway fans of happy death day Will Certainly love this if you're a fan of both scream and happy death day This will make you even more excited for screen five Christopher Landon the writer for happy death day or the director I believe for right for happy death day has come out and stated that the script for screen screen five is Is good? So that's all he had to say now the reason I wanted to talk about this is because Christopher Landon at one point time last year he there was news coming out around the same time that rumors started started up about screen five News came out that he was working on a new a new movie and everyone was under the impression that Christopher Landon was working on Screen five because of the rumors coming out and because of Blumhouse making making Jason Blum commenting on the fact that he'd love to Do some movies for that franchise and then Christopher Landon having associations with Jason Blum And we know he's done happy death day and happy death day to you So then when news and rumblings came out that he was working on a new project Everyone thought that he was gonna be the one to bring us this new screen movie now that of course is not the case We know we're getting screen five from Matt Benelli and Tyler Gillett who brought us ready or not the radio silence team Spyglass media is involved paramount picture will be distributing it We have Courtney Cox officially on board to prize prize her role as Gail Weathers now We have David Arquette back to play Dewey Riley We're still waiting to hear if Neve Campbell will return or not But of course that's gonna be coming in the few weeks or so as we now have official Twitter accounts and an official Instagram account For this upcoming project that is looking to start shooting this October out in Wilmington, North Carolina So what I want to say about this is this is yet Yes, just yet another person who has come out about this project and they've stated that the script is good Or they've stated something that Kevin Williamson had to say that what they've written honors West's legacy and the directors themselves and Everyone involved with the project just coming out and giving all these stamp of approvals about it Neve Campbell mentioning that she was in she was impressed or had had some liking to what was being offered to her what the Directors had to had come to her with with the narrative of screen 5 So Honestly knowing that all of them are getting back in back involved. There's there's something here that's that's gonna Has the potential to be great That's my honest opinion something here has the potential to be great, but keep in mind While the script might be good one thing we need to remember when it comes comes to filmmaking when you have a good script you can have the best script there is but your movie could be executed horribly and Perfect example of that would be Not not a perfect example, but let's let's just talk about Jeepers Creepers really quick Jeepers Creepers original script has a far better ending in my opinion when we actually got But we did not get that due to budget budget restrictions There's a few other things in that original script that we do not have in the movie itself that Some some tiny things that just the tiniest things might have made the movie slightly better So there's always a chance that whatever this script is that Christopher Landon read It might not even be the actual draft that we get that gets shot Unless he knows that this is the draft that gets shot because what could happen is we were already speculating that they've prepared for this given that Scream has faced so many leaks in the past with its other entries and other sequels that the team behind screen 5 Presumably if they were smart they took all the necessary precautions that includes possibly Using a draft for auditions that includes names that will not actually be appearing in the film to conceal the identity of the actual characters in case of elite So that's where this idea that Sarah might not be Sarah is actually Kirby comes from There's several different things that could be going on here. The script might be great But we might get an absolute trash executed depiction of this script just like how with screen for screen for a script It reads better than actually how it plays out. That's my honest opinion about screen for screen for is a very solid movie a Massive improvement from the third entry But the way it plays out and the if you read the script and the way you would envision in your head me personally It I envision it in my head much differently and I get a much better film than what we actually got It was done fine for what it was But anytime you read a script, of course, you're gonna sit there and say it's you might sit there and say It's good afterwards Especially if you have characters that are you're hooked on and you're invested in and you want to Spend more time with getting to know When you're reading scripts, you have all the time in the world to just sit around and come up Let your imagination run wild and put all these things in your head as you're taking these words That you're reading and then you can create the movie in your head So at the end of the day, of course, if you have a script that's written very well And you've been able to create the images of what it would look like on screen in your head I turn around and say it was a good script, too Like I but like I'm saying the script might be the best thing out there since the first movie But it could be executed very horribly. That's still always a possibility There's several movies that have gone through this several movies that have the amazing have this amazing concept with this Decent script that gets turned into this run down Like watered-down version of what it was intended to be what I will say is we all should remain very Positive about the project because of the fact that the Weinstein's are not involved and I know the Weinstein's Bob in particular They were very back-and-forth with Kevin Williamson very back-and-forth and what oh, we're not doing that We don't want to do this. We don't want to do that Oh, we can't do that change this change that all this other type of stuff So the fact that we don't have to worry about that anymore Makes this very exciting because what's gonna happen is we'll have a screen five film where The Weinstein's are not holding holding back. What's possible? We'll get to see a script finally executed to its full potential We won't hear things coming out during production Hopefully about all these on stage all these backstage issues with Kevin Williamson or all these other issues with the producers Jumping in and tweaking and wanting to do reshoots and changing the script halfway through production all this other type of stuff Someone walking out my production was just just played because of the Weinstein's and their constant constant attitude towards what was what was being Planned they always wanted to change something always wanted to change this they always wanted to change that It's like if you don't have any in Kevin Williamson I believe said this in the podcast if he was on if you don't have any trust in the people you're working with Why continue to work with them over and over again if you're just gonna keep doing this you're gonna keep telling them Oh, no, we don't need to do it that way. We're gonna do it this way. Oh, no, I don't like that We're not gonna do it that way. We're gonna do it this way. Oh change that rewrite that whole section We're not gonna film that like if you're you have a history of working with this person for Three different projects that are in the same franchise if you're gonna be doing this why continue to work with them Why continue to work at all that's why Kevin Williamson decided he wasn't gonna work with these guys anymore That's why he did not want to come back for screen five. That's that's exactly why that's another reason Why screen fighting screen five did not have it on top of screen for yes being lackluster at the box office Kevin Williamson didn't want to work with them anymore because of the debacle that was Screen for the production process for him was was hell He left that project to go focus on the vampire diaries and I don't blame him one bit Knowing what I know now and what he's saying went on behind behind the scenes.  Honestly But Christopher Landon did say that the script is good a good script to me means we have Sydney Prescott in a prominent role And when I say prominent a role that's still very Very effective very impactful another thing we need to keep in mind is Screen five could be taking the dream warriors approach nightmare in Elm Street 3 the dream warriors That's what everything is very reminiscent of to me We're getting a film in a franchise. That is a sequel not ignoring the previous entries But we're focusing on a new set of characters, but we're gonna bring in the old to be kind of like mentors That's very similar very reminiscent of nightmare in Elm Street 3 the dream warriors Let me know what you guys think about what Christopher Landon had to say down in the comment section below If you haven't already make sure you subscribe turn on post notifications I never miss a video in the description I have links on my social media accounts on my Facebook Twitter and Instagram You can message me there to let me know if there's any movies news or reviews you would like me to cover in the future Also down in the comment section. I'm gonna have a link to the Facebook group You go ahead and join that group and let me Let me know what got what things you guys want to see on this channel and just discuss horror amongst yourselves in that group But with all that in mind guys, I will see you in the next video