Welcome to Amsterdam and KubeCon, CloudNativeCon 2023. Join John Furrier, Savannah Peterson, Rob Streche, and UPscot as the Kube covers the largest conference on Kubernetes, CloudNative, and open source technologies together with developers, engineers, and IT leaders from around the globe. Live coverage of KubeCon, CloudNativeCon 2023 is made possible by the support of Red Hat, the CNCF, and its ecosystem partners. Good morning, brilliant humans, and welcome back to Amsterdam. We are at KubeCon EU, CloudNativeCon as well, and I am here with my fabulous co-host for our morning segment to give you all of our hot takes from day one. My name's Savannah Peterson. I'm joined here with you. We've got Rob and we've got John. I'm surrounded by brilliance. Gentlemen, how are you doing this morning? Awesome. Great. How are you? I am fantastic, obviously. Rob, what was the most interesting thing you learned yesterday? I think the big thing from yesterday was platform engineering is real. A lot of the people, not only the projects, but the vendors are aiming at that, and I think we're going to hear a lot more about that today as well as we go through the day. What about you, you? Yeah, I agree. So platform engineering, definitely a thing, but for me, it really means that we've kind of gone into, we're not really sure what we're doing into, we're maturing this ecosystem, and so we're seeing solutions that are becoming more mature, becoming more production-ready, and it's good to see that we've entered this phase where we start to figure this whole thing out, and I think that's just a good spot to be in, and it's exciting to see where this is going. I love that you said that. The ecosystem, I think, was definitely a real theme. This isn't just an orchestrator or a platform. It's not just about containers. It's about all the things that support what's going on here and all the open source projects. John, you had your finger on the pulse yesterday. What are your thoughts? I mean, looking at yesterday and then what's lined up for today, I think the big thing I took away was that we're back to steady-state events. I mean, this is 10,000 people. For Cuba and Europe, it's not the tier one show. It's North America. It is packed. It's a 2,000-person waiting list. RSA next week in the U.S. is going to be absolutely packed. I expect North America, KubeCon to be, again, jam-packed. So we're back to face-to-face steady-state, and this community, this is what it's all about. So I thought that's a huge, huge accomplishment back to that standard. The other one is, is that this industry is about to get disrupted by AI, and they have no idea what's coming down the tracks. I think they're so focused on their blocking and tackling of infrastructure Kubernetes as that progresses to mainstream platform engineering you mentioned. But a lot of the gaps are being filled in, binary support, compiler support for, say, Watson, we talked about yesterday. So a lot of the ball's moving down the field, but the AI surge is going to come. I think that's going to be a real wild card in next year, this year. Let's talk about it, John. Where do you think we're off at with that right now? Well, I think this is not a data-centric community. They're very infrastructure. They're gears, boxes, protocols, and they have data, but it's data around machine, machine blogging, not like a chat GPT, large language model. So I think it'll be pretty straightforward for this community to adopt AI because they're automating already. So automating is a big feature. So I don't think it's going to be a disaster. I think it's going to be a good thing. You agree, Rob? Yeah, I think it's going to be more prevalent as we go through the next couple of years, especially in observability space. I think there's a lot of things in this, and I think this actually ties in really well with the platform engineering discussion because you have so much logs and data and traceability that you have to go and figure out, and that's where the AI actually fits in. You can model the data because they know the data patterns. I think where it gets blurry is when you get to security and some of the other things, where are you putting your code in there? Is it a public model? Is it a private model? Do you have enough of data in your private model to actually go and look at that? There's still some big chasms to bridge. Well, the other thing too, you were talking about yesterday, platform engineering with Portworx, it's kind of evolved the definition. When you go back three years ago, platform engineering was, I want to be like Google. Yeah. SREs, and then it's evolved to what is DevOps? I'm a DevOps engineer.  We're in the DevOps department. So DevOps is kind of being abused and DevSecOps comes in. So it kind of moved essentially to be the new IT. So platform engineering is essentially modern IT. And then we heard from merely yesterday from Portworx that the core old definition kind of drops down into the infrastructure and abstracted away. So I think that's a nuanced point that I noticed yesterday is that platform engineering is the modern version of basically IT. Interesting. I think my, you know, I just came off five weeks in the rainforest. So my take on where we're off at with AI and with some of this is of perspective a little more removed from the Silicon Valley bubble and from this community a little bit. And I have to say I'm a little worried about the governance and the ethics of what's going on. I think that actually the open source community is perhaps one of the only gate checks that we're going to have with this with some of the, you know, you've got the biggest companies in the world in an arms race right now to own this space. And that's exciting because it's pushing innovation forward. But it also makes me a little bit nervous because we all know how biased some of those models can be given their data sets or some of the darker side of this. There's a lot of customer privacy issues depending on what you're loading in and how private that is. And I do think security is a big deal. I think it all is very appropriate that we're having this discussion, we're hearing it in the hallways. No one knows what's going on yet. We're only about day 100 in this whole motorcycle. Yeah, you're right on the money. This chat GPT phenomenon is kind of, everyone's been playing with it. But what people don't know is, and Basam talked about yesterday was, you're putting your stuff in the public web. And people are missing that. So there are companies here have been putting in their code. We know the Samsung story is public. They had IP in there. They were putting company private information. Some companies are putting in their own customer information. So they think it's a tool to help them rewrite memos or rewrite code. But that's IP. So then it brings up all kinds of issues like, okay, it's out in the open. What's the IP rights? Competition stealing it. So like, this is like slippery slope. So I think, you know, you're going to see a pullback, not from that ethics. Oh, it's going to rule the world.  Well, exactly. And also the kind of operational security angle of this. I mean, we are in the infrastructure, so that's right. This is not a data engineering community. This is an infrastructure community. And so seeing how this group will start to deal with and recognize how this works, that's going to be super interesting to see. Because we're only scratching the surface. We're just beginning. We're literally just experimenting. We're making mistakes. Samsung's making mistakes. We all are. Everyone's making mistakes. And that's fine. But it's interesting to see where is this going to take us. What's the evolution of the role of platform engineering like Rob said, a year from now, what did it have evolved to a place where we as a community are the gatekeepers of these policies, of this compliance, to make sure companies don't repeat these mistakes? Totally. And I was thinking too, yesterday on the AI conversation, we were kind of groping to try to get a feel for where it would kind of go. It went boring on some conversations. It didn't really kind of stick. But then I knew it would be me andering around a little bit. But what we asked yesterday was, where will AI lock in in this community? And I think what I walked away with was, automation for sure, but security will be huge. I mean, you mentioned the security aspect of it. I think you're going to see the actors, both good and bad, dig into this. And you're going to see some new stuff that we haven't seen before on the offense and defense side. So that's where I expect to see that kind of first strike of kind of like cool, weird AI. And I think that's going to be interesting to see where that lands. Because I mean, you talk about S3 buckets that are open, court scanning, scanning on containers, container security, writing code from chatbots. You're going to have code pollution. I mean, who's going to watch the code that was written by bots and monitor that? So I think observability is going to get turned upside down.  That's a good technical term for it. I think code pollution, one of my favorite terms in the world. I think when you look at it, it was funny because I was just at the keynote and they were talking about the project update for confidential computing and things of that nature. So to your point, from an infrastructure perspective, there are some things that are competing to help anonymize things, not just encryption, but how do you tag things and use them in a more general way? And I think that's going to be interesting. I don't think that gets enough airtime here. I think a lot of the scanning, container bloat from a security perspective gets a lot of airtime, but there's things that are happening. I also thought what was interesting and it'll be interesting to hear today is it was a big talk, like a really good talk by one of the presenters from CMCF this morning about how not enough people are stepping up and really becoming leaders of projects and they're having a gap, like a real talent gap in leading these projects. And I think that to me is super interesting given the community and how big it's gotten with 190 plus projects going on. And they're also talking about contributor burnout with 54. I was just going to say it's a lot of work and I think, and that's just it. I mean, it's open source. A lot of this stuff is unpaid. Folks are doing this because they want to see these projects moving forward and that's actually why I think it's really cool that we're here and we had a conversation with Red Hat and how they helped support a lot of these projects as well. It's going to take, I mean, it takes the village, this whole community is about community, which I love, but it's your spot on there in the sense that if we're going to see this evolution move forward, whether we're talking about AI or Kubernetes or any of this stuff, it's going to take some leaders who are going to have to take a lot of flak to step up into that role because it's hard. We're in uncharted waters right now. And I think the complicating factor to that too is that makes it harder, is that I was just out with some European VCs last night. There's a lot more active investment in Europe than ever before. Just go back to the past 10 years, that last cycle. It's on the upward slope big time on Europe. So one, how are you going to get burnout on contributors that when the alpha VCs are poaching the best talent to build companies? So, you know, the question is going to be can the open source funding model which was beautiful last cycle, because you start a project, you do it in open source, it's kind of a freemium and you turn it into a company, can that continue? That's going to be the real wild card. I think if they get that right, if the greed pulls them out of the community, you know, that could put more stress on the system.  No, I mean, I completely agree that the market here in Europe is hot. It is still very much moving. We see it around us, right? You can tell just from the energy in this room, right? The energy, the buzz in this room at this event this week has been astounding. I did not expect it. I am very pleasantly surprised by it. But it does show that Europe is leading in this open source realm. And we're seeing VCs jump on that. We're seeing, like John said, we're seeing a lot of activity here. And I think, you know, part of it is the active role of the foundations behind this community, ridging that gap, driving this effort. The other thing too, the other Savannah that you point out is that we were talking about this last night riffing on this, what trade shows, and they used to be in the business you had like independent events for the conferences and trade shows. It's not like that anymore. It's AWS re-invent, that's Amazon, CNCF's Linux Foundation. I heard they're making so much cash on this event. This is a de facto open source community and industry event at the same time. So that's interesting. Europe's booming on the DC side, but coming back and looking at cloud growth in the anemia, Europe, Middle East and Africa and Asia Pacific. You have Europe in particular on the enterprise side that's starting to start to grow, but it's growing by country. And so you have kind of sovereignty issues. You mentioned compliance and governance. This is kind of like boring tech enterprise stuff, but it's actually very relevant in this market. So unlike North America, where a cloud growth is slowing down and cost optimizations to focus, it's actually expanding in Europe, but it's not expanding as obvious because it has different country dynamics. So localization, channel marketing, channel partners are going to develop. So I think a lot of people are looking at Europe as a massive growth and certain the cloud players are Amazon's ahead, Azure's here. You're going to start to see a whole nother ballgame I think this year in the next five with cloud. You're here, you're living it. Yeah, we're going to see a lot of sovereign clouds, a lot of smaller clouds. I'm not saying on-prem's going to make a comeback, but self-hosted is going to become a thing again. And so the pendulum, we went all the way to cloud and now the pendulum is starting to swing back. And especially in Europe, that whole sovereign aspect of it, that's going to be a big differentiator for everyone, in the community, the vendors, everyone. But going to your point on the data and the cloud, I mean, just look at the, just because I came from the data side of things, most recently, you start to look at that Google Analytics has been outlawed in five countries in Europe because the data goes outside of Europe from a GDPR. You start to look at how it's being torn apart a little bit from a big conglomerate perspective. I do think things are coming back on-prem a lot more, especially in the dev and test area where people are looking for that cloud on-prem experience. And there was a lot of talk about that yesterday, even. And I think that's going to be huge because it's a cost savings aspect. I think there's a swing of the CFOs and these major companies back to Capax. And I think that's going to be interesting. I mean, cost optimization is a huge thing across the board, no matter the industry right now. I mean, we're seeing things like the collapse of banks, Silicon Valley Bank. Was that as big of a story here as it was for us in the US? It was, it was, it, you know, yeah. What's the EU hot take on that? Well, people started to get really, really quickly. Yeah. And so even though it was a little further from our situation, still we were looking at it as a tech industry and saying, this is, this isn't, this can go a lot, you know, either way. Which bank do they run on there? And I think it's all good conversation. I think your product that, that, the Google analytics thing is interesting because that, only because it's an American company, but I think the white space from a product mark, from a product standpoint, the opportunity in Europe to get these differentiated, localized clouds by region, it's going to be a very interesting dynamic because if you just, that Google is one example, there's many others. Well, they'll pull out dates flying out of the area. So you got regions. So, so it's going to be a question of, will the product market fill in those white spaces? I think that's the opportunity that I see here is for entrepreneurs and businesses to fill the void, saying, hey, we don't, you don't, we don't need Google analytics. We'll have our own analysts. In fact, now they won't have clouds. Amazon will do that. But I think it's going to be very interesting to see how the cloud hyperscalers enable the market here in Europe. That's going to be a very interesting thing. And how does open source feel that goal? Because if more web assembly like projects continue, the idea of developer productivity continues to get better, it's going to be faster coding time, it'll be faster MVPs built. It'll be very interesting. It will be. And one of the things that I think is really interesting, I mean, since we're kind of doing this EUNA comparison right now, I find, and this is a perception thing. I don't have any data behind this is my personal opinion. The community here is so inclusive. And I mean, the open source community as a whole is extremely inclusive. But a lot of the conversations that we've had between the big brands and some of the smaller startups that are here, it's experts helping that next generation along. So perhaps there's not that traditional leadership role, but there is a desire for everyone to educate everyone else right now, especially because we're moving at scale, at velocity with a lot of different technology all piling into one. Which is kind of, it's an interesting intersection. It's an exciting time to be alive. Absolutely. Rob, what did you do last night? Did you have fun? I had dinner and I then just dealt with emails and other stuff. Not fun, maybe a little more fun tonight, but I think we'll keep you happy, come on. Yeah. Don't hold back. Don't hold back. I mean, today is April 20th. I went back to my room and worked. And I said a prayer, and it was at 11, you know. Bless you, John. Bless you. I was very good last night. You were a good boy. I went out with one of our favorite guests. I went out with Kaston last night and had an absolute blast. I know you had some fun at Karaoke. Karaoke, yeah, all night long. Yeah. And then you showed up wet and hungover, which is just a great place to be. That's just the great start of the day. Yeah. On that note, ladies and gentlemen, joined by these fabulous gentlemen. My name is Savannah Peterson. It is 420. We are in Amsterdam. And you are watching our live broadcast of KubeCon EU. This is theCUBE, the leading source for emerging tech news.


All righty, welcome back to 353. So thank you for joining me today. Today we get to talk about sub-processes. So this is basically tying everything together we've learned so far, and this will prepare you for exactly what you will see in Lab 2, including some mistakes you will make. So this is basically implementing the sub-process module in Python that lets you create and actually manage processes because guess what? Python has to use all the same system calls as we do. So no getting around that. So this is basically the equivalent of what the Python module will do, which will be somewhat useful. So what we want to do today is slightly similar to what we had before. So we want to send and receive data from a process. So before we just received, we just sent data to a process and then it was able to read it. So now we want to be able to do both at the same time. So for today, these are our three goals. So we want to create a new process that launches whatever the program is as specified as the command line argument, send the string testing with a new line to that process and then receive any data that that new process writes to standard output so that maybe if this was a more involved program that we go ahead, we use that data for further processing or something like that. So if we saw exec VE kind of a pain to use, so there's C wrappers for exec VE that are a bit more convenient to use and one of them they'll all start with exec and some different letters to kind of signify what it does. So there is an exec LP that is slightly different than exec VE. So this L means it takes a list instead of a vector or an array because that was kind of annoying. And this P means we don't have to give it the entire path including like the root directory, like the absolute path to the executable, we can just give it a name and then it will use a path environment variable to go ahead and find where that program is for us. So it will save us a bit of typing. So exec LP, the first argument here is just the name of the program to actually run and it will do all the work of actually searching for it. And then instead of an array of C strings, well, we just can have a variable number of C strings we give it until we give it a null and then that signifies we're done. So we don't have to bother with an array for this just saves us a bit of typing. So otherwise, after all that magic of like looking for things and converting things into a array of C strings, well, it's going to eventually do exec VE because that's the system call. So have all the same rules, doesn't return if it's successful, negative one if it fails, sets error no, all that fun stuff. So it just saves us a bit of work, bit more convenience that is basically what the C wrapper is for these function calls do. So final API's we can go over or doop and doop to, we saw a doop before so that just duplicated a file descriptor and gave us a new one. So create a new file descriptor and whatever we gave as the argument, it made sure that whatever that represented the new file descriptor also points to that thing. So in the case where it was like the read end of the pipe, if we doped it, we could get a new file descriptor back that also points to the read end of the pipe. So there's a doop to call that is a bit more convenient because before we just like closed file descriptor zero and then reopened one in one of the examples. And that was a bit of a pain because when we get into more complicated processes, well, something can actually happen between you closing it and you opening it, so you're not guaranteed to always get file descriptor zero. So in this case, this is the file descriptor that you want to make a copy of whatever it is pointing to. And then the new file descriptor is the new number you want to point it to. So you can directly control what the new file descriptor that gets returned is. And the rules for that is this function call will have or system call will happen atomically. So you can't interrupt it in the middle of that. We'll get into why that is important later when we have multiple threads and things like that. But for now, just know that it's atomic and it will ensure that they both of these file descriptors will actually point to the exact same thing. And if this new file descriptor was open before, like it was pointing to something that was valid, it's going to close it for us so we don't have to remember to close it. So aside from that, yep. So for dupe, you'll just get back a new number. It should be the lowest sequential number. But if you have like, when we get into here later, when you have multiple threads going on, you might not know what returns from dupe when. But if we only have just a main before, like what we had, we just close zero and then we duped, then we're confident that we'll get file descriptor zero back because it's the lowest free one. But sometimes we can't make that guarantee. Yep, yeah, so both of these return the new one. So in dupe, you don't get to pick what the new one is. It will just give you the lowest available one. With dupe two, it will return the new file descriptor. So you get to control what file descriptor gets replaced, which we'll find useful, yep. No, so old, in both of these, old will be left alone. So that's whatever you're copying to. So this new one, if it was already open, that gets closed. And then you're making that new file descriptor point to the same thing as old file descriptor. Yeah, yeah, if new file descriptor, if that number you pick, because it's just an integer, if it already, like in that process, represented a valid file descriptor, it gets closed first. Yep, yep. So yeah, the question is, why won't I know what file descriptor gets returned from dupe? And that will essentially come up when we have threads and multiple things can be executing in a process at the same time. And like not knowing the order between processes, you also wouldn't know the order between threads. Yep. So threads are like different parts of it? Yes, yeah, so when we get into threads, so this confusion of having multiple processes going on at once and you don't know which one will execute, but it's not too bad because they're independent, you just don't know the order. In threads, it's that same problem except threads live within a process and bad things might happen because you don't know the order of things that will happen and they all share virtual memory and things get really messy, which is why threads is much later. So don't worry about threads for now. We're still in the nice land of just a process executing, it only does one thing at a time. All right, so now we get to tie everything together today. So this will be fun. All right, so here is our program again and this will be essentially a small version of lab two. So here I checked that I have two command line arguments because how I want to run this is I want to be able to do something like sub-process and then like the name of a program to run in a different process. So for example, if you haven't seen the uname program before, if I run it, what it does is it will just return the name of the operating system that runs. In this case, I'm running Linux. If you're on your virtual machine, you're running Linux. If you're on macOS, I think it might return Darwin, which you might be like, what the hell is Darwin? Darwin's the name of the kernel in macOS. So, but this command actually runs on macOS. So this is what I want to do and I already have some of the code written. So in main, I go ahead, I check that. I have two command line arguments. I just created two arrays for pipes because well, that is how I'm going to send and receive data to the process. It's about one of the only forms of inter-process communication we know. So we're going to go ahead and use that. And then here I fork. So I just create a new process and to make things a bit more readable, I will just see if my process ID is greater than zero, I call this parent function. So only the parent calls this and it gets both of the type FD arrays and then the process ID of the child. And then in the child, it also gets those arrays and the first command line argument. And that's the program I want to actually execute. So right now in my parent does absolutely nothing. So eventually it will go ahead and just return from here, call return zero from main. So that's exit zero, parent's done. In the child, it does exec LP and here the last argument is the name of the program. So we just tell it the name of the program. We don't have to try and find where it is. This exec LP will go ahead and do it for us. And by convention, the first argument should also be the name of the program that we saw before. Whenever I changed that and had the help message that was slightly different. So I'll just follow conventions here and then I give it no other arguments. So if I compile and run this, so it's called sub process, build, whoops, too many L's and I give it your name. What should happen when I do this? Sorry? Print's Linux, right? So if I run this, I print Linux but it's not the process that I ran that print's Linux. It creates a child and then that child, well it shares all the file descriptors of its parent including standard out, standard error, standard in, all of that stuff. And then the child process goes ahead and does exec LP of U name. So it will now directly just print to the same standard out because it's shared in both processes. So if I run this, all I see is Linux, same terminal, same everything. So we're all good so far. Yep, yep. Sorry? So the question is, don't I need two arguments in the main function? Yeah, I have two arguments right here. Oh, so this is the first argument, this is the second. So the convention is the program names always argument zero. Yep. Oh, why did this to initialize the pipefd arrays? So that's just a way in C just to zero initialize the entire array. So I just zero initialized it because I'm just used to initializing things. Yep. So right now I just started executing main so all I know at this point is I should have zero which is standard in, one which is standard out and then two which is standard error. That's it. So I didn't actually create new file descriptors because I didn't do any system calls like gave me a new file descriptor. So I just set aside some arrays because I'm going to use them. Okay. Yeah. All right, so next step is, well, whenever I run this uname sub process, right, my child process is actually doing the print uname I want to go ahead. I don't want to see it in my terminal. I want to capture it because maybe I want to do some processing on it. So I need a pipe because I want to make sure uname whenever that process writes to standard out that I can go ahead and capture that output and then use it in my process. So for that, I need some inter process communication. We only really know what a pipe is so far. So here I'll do a pipe system call. So pipe and then I will use out pipe FD and then just go ahead check for an error. So now I did this before the fork, right? So what I would assume that happens is that after the pipe system call, as long as it's successful, I now have two new file descriptors, one for the read end of the pipe and one for the write end of the pipe. So now in this process, file descriptor three would, which is actually stored right now in pipe FD zero, that would be the read or the write end of the pipe. Quick quiz, read. So easiest way to remember which end is which is they kind of look like the standard file descriptors. So standard in that's always input. So you're always reading it. So it's zero. So same for a pipe, the zero one is the read end. They kind of look the same. So standard end is the read end of out pipe FD or I'll just call it out pipe and then we'd have file descriptor four which is stored at index one and that would be the rate end of out pipe. So I did that before I fork. So after I fork, both of those processes, since they're exact clones, they have all those file descriptors open in both processes and then after the fork, they're completely independent. So if I go ahead and run this again, what do I expect to happen? So I created a pipe and that was pretty much it. So nothing happens, right? It just does the same thing before I just created a pipe and both of my processes could use a pipe but they never did. And then yeah, for a question of what exec LP does, so exec LP, that will do the same thing as like exec VE. So if this is successful, this child process just turns into, in this case, U name or whatever argument I give it and it starts executing that program with that process ID. So in this case, if I do this, this program goes ahead, forks makes a new child and then in the child, we do exec LP. So it would just run this U name program, which goes ahead and eventually just prints Linux to standard out. So if I want to capture its output, well, I should probably make it force it to output to the right end of the pipe, right? I want to take the output that the child process is generating, capture it so I could hopefully do something with it. So that is where my fun dupe two comes in. So dupe two, the first argument is the thing you want to copy. So I want to take, choose the file descriptor that's pointing to the right end of the pipe because I want this process to eventually right to the right end of the pipe. So here the right end of the pipe is FD one and basically what I want to change, I want to change, oops, wrong argument. So what this will do is it will take whatever this file descriptor is pointing to. So it is the right end of the pipe and it will also make file descriptor one point to the right end of the pipe. So in the child process, now if that process tries to write out to file descriptor one, it's going to instead go instead of to the terminal, it's going to go to the right end of the pipe. So I'm just replacing which one it is. So now if I run that, I see no output. I'm still running that process. It's not, I didn't change what that process is doing. That process, whenever I do exec LP and start running that program, it's just going to write Linux to standard out but through, because I did a dupe two right before I did exec LP, I change what standard out was pointing to. It's now pointing to the right end of the pipe. So now whenever that process does a right system called the standard out, it now goes to the right end of the pipe instead of the terminal. So now I can no longer see it. Questions about that? All right, before my advice was to close any file descriptors as soon as I don't need them as long as they're not the standard ones. So I should probably heed my own advice here and what file descriptors am I done with? Well, I definitely don't need the read end of the pipe. So I definitely don't need the read end of the pipe anymore in the child process because my intention is that the parent goes ahead and reads from the read end of the pipe and that's how we get data back out of it. So technically I also am done with now the right end of the pipe through its original file descriptor. So at this point, when I, oops, actually yeah, that's fine. So right now when this child process or when I did this child call, these were all my file descriptors and what they were pointing to. Right after the dupe two, I essentially just made file descriptor one also point to the right end of the pipe. So now my file descriptors, oops, look like this right after that dupe two call. Yep, I'm not reading anything right now but if we were to read from that file descriptor we would read whatever information gets written out to it, right? Because the pipe is basically just a buffer that's managed by the kernel. So if I read from it, which I want to do in the parent process to get information out of that process but in the child I don't wanna read, right? Because pipes are like just one way communication channels. So my intention for this is to have the child right to it and then the parent read from it. Yeah, all right. So this is what it looks like after dupe two. So I'd still have five file descriptors and after dupe two all I did is change what file descriptor one is referring to. So after that, well I actually don't need file descriptor three and four which are stored in pipe FD index zero and index one. So after the closed, my file descriptors look like this right before the exec LP. Yep, so yeah, right now I haven't touched in pipe FD. So I'm only concerned about getting information out of that process. So yeah, we haven't touched in pipe FD yet. Yep. So we have, when we close number three that doesn't act, does that not close the file that is the read end or just sort of close like the communication channel? So the question is after the close, why can I still use the right end of the pipe? Yeah, why can I still use one? Well, so each file descriptor they're independent like it's just file descriptor refers to something. So just because two file descriptors refer to the same thing, if I close one that just means I can't refer to that through that number anymore. Yeah, it's essentially like deleting a pointer. So easiest way to think of file descriptors as they're pointing to something. So each time I get a new file descriptor that's a new pointer, if they point to the same thing and delete one doesn't, one doesn't affect the other. Yep. Okay, perfect. Yeah, easiest way to think of file descriptors as pointers. Yep. No, so right before we do exec LP, I deleted it for some reason. My file descriptors look like that. Which is exactly what I wanted because, right, I can't change whatever that process does. All I know is that whatever it outputs, it's just going to write to file descriptor one, whatever it inputs, it's gonna read from file descriptor zero. So I want to set my file descriptor so that if I want to capture its output, instead of just going to my terminal, I'm forcing it whenever it just writes the standard out to write to the right end of the pipe and that way I can read it in the parent, which we'll do right next. Yep. Yeah, so technically the kernel will manage like what the pointers are pointing to and each file descriptor is just a pointer. Yeah, so the question is how do I like free the block of memory associated with the pipe or something like that? So the kernel smart, so when you close, it's essentially like deleting a pointer and the kernel will know that hey, if nothing is pointing to that anymore, I can delete it. So that'll be done by the kernel and it keeps track of that. Yeah, and that's again how it also knows that if it's possible for a pipe to have data in it, if there's at least one pointer to the right end of the pipe, well then it's possible that something could actually use that and fill it up with data. So that's one of the things it uses to make sure that hey, this pipe can no longer get data. All right, let's do the other side. So in the parent, we want to get that information out of it. So we'll just create a buffer of our magical number and do a good old read system call. So I can read now from the read end of that pipe and I should be able to capture whatever the output was from in this case, uName if I give it the uName argument. So let's just do a read with our fun buffer. Whoops, I hit the wrong button. This one is too, all right. So now we read, let's check for an error, make sure I didn't screw anything up. So after I do that, I should have read in this case the data that came from my child process, which if I just give it the uName argument, it should be Linux. In this case, I don't do anything about it. So let's just print off what I've actually read. So print out read our special string formatter. So int bytes read buffer. All right, so now if I run that, I actually can read Linux. So it wrote to the right end of the pipe and then in the parent process, I was able to read what it wrote. So now in this case, well, it just read Linux, but now it's kind of extensible. I could actually like build up and hopefully like use the actual output for something useful. So I could run it with the LS or something like that. And it was going to say, hey, read the output of LS. You could actually process the output and do something more useful with it than what I am doing. So questions about that, yep. So the question is, does print always go to the terminal? So answer to that is no, print basically will always eventually call right to file descriptor one. So it's whatever file descriptor one is. Yes. Yeah, so the question is, how did we get a message if we screwed up file descriptor one? So remember right before the fork here or right after the fork, both those processes are independent at that point. So they looked the same, so they would have had all the same file descriptors pointing to the exact same things, but after the fork, they're now independent because I have a parent process and a child process, right? So in my child process, yeah, I made file descriptor one point to the right end of the pipe, but in the parent process, I didn't do anything, right? So let's see. So in the parent process, whenever it started, whatever the child did do, it's file descriptors does not affect me. So when I started this function, these were all my file descriptors. And standard out was untouched. So by default, it's just the terminal. So I didn't touch it. If I, yeah, if I went here, which is going to be a fun way to debug things, as soon as you start screwing with file descriptor one, so like in this process, let's say I did print F, I don't know, you'd start like debugging or something like that and try and throw a debugging line. Well, guess what? If I run this, I'm just, oh, in this case, it's even worse. So I don't even see this debugging line because well, it won't go to my terminal because I changed what file descriptor one is. And in this case, print F also isn't really guaranteed to even do a write system call unless I like flush it and really mean it. So in this case, it didn't even do a write system call and then I started executing a different program and it was even worse. If you want to force a write system call, you can do something like this. So I believe if I do this, I run that, yeah. So now I got debugging because while I did a print F, it wrote to file descriptor one, file descriptor one is now at the right end of the pipe, so I just filled that up. So yeah, so if you're used to print F debugging, print F debugging doesn't work if you change what file descriptor one is. So good luck debugging, yep. If it's reading, so it would just write the standard error. Yeah, yeah, so the reason there's a standard error is like generally it's nice to have them separated so if you don't want to see the errors, you know. Yeah, yeah. By default, standard out and standard error are both the terminal. So you see them, doesn't really matter most of the time, but you can split them if you want, yep. So when I flushed it, I forced that system call and because in the parent, I just do a single read call, I don't just constantly read until there's no information left. So yeah, the write call forced to read, yep. So when I just had my print F here and I didn't see anything, well, print F isn't guaranteed to do a system call right until it wants to, so. Did it ever do it? Yeah, in this case it never did that because print F can buffer input and just kind of wait until it's optimal to do a system call. At this point, when I just had a print F here, it was waiting around and then I did an exec LP so I immediately started executing a different program so it's never gonna come back. That program just got replaced. That program was like, oh, print F was like, okay, yeah, I'll get to it, I'll do the system call in a bit and then I just replaced the program and it's not gonna ever come back. Yep. Yeah. Yeah. Yeah. Yep. Yep. Yeah, so that's a good question. If I did not close these and say I had file descriptor three and four, what would you name still have those open? And the answer to that is yes. It's the exact same process so it would still have the file descriptors open. So it's generally considered rude to have more file descriptors open than is necessary. No, no. Yeah, so you name wouldn't have any code that closes those file descriptors and the only way they get closed is the process terminates and then all the file descriptors get closed. Yep. Why not just use the right system call instead of print F? Because that would have. So that would have just done the same thing as the flush.  After this course you might start debugging by just writing to file descriptor one because then you're sure that that system call actually happens instead of print F that kind of ignores it. Yeah. So the question, I don't know if we can cover it in this, is why does print F not just do a right system call immediately? So remember, system calls are slow. So I could have something where it's like slightly off topic but like four one to like a thousand something like that just print F like a star or something like that. So if it didn't buffer, so that's what it's called. Just buffering, collecting a bunch of inputs, that would be a thousand system calls and that would be slow. So what it's gonna do is build up that system call and then wait until essentially a new line or like all thousand characters are already in that big array and then just do a single system call. So it does it for performance reasons.  Your program would be very, very, very slow if it just went with you and just immediately did a system call.   Well, it might be because print F sometimes just doesn't do a system call. So either flush your output or since you've taken this course you can just do your own system call if you want. And if you're worried about like standard out something weird happening to it you can just create your own file descriptor with a file or something and always write your debug messages to that and then you know nothing else can screw with it. All right, so, whoo. All right, that was a side journey. So where are we? So now we have the information in our parent. So now we've successfully went through one cycle of this. So we are getting information out and I should probably in my parent close the file descriptors I don't need anymore. So the parent never needs the right end of the pipe because that's only for the parent. So I should close that pretty much immediately. And then after I'm done reading from the pipe in this case I only read from it once I should probably just close it right after I'm done. Remember that tip because that will help you through lab two and cause you not to go crazy anymore. So now if I run that I get its output. All right, so now we have to do the other side of it. Quick, so we want to be able to send in this case I said send the string testing with a new line to it to that process. So we need another pipe. So we will call this one in pipe FD. So now I have a lot of file descriptors open. So we'd have whatever like all the way up to six or something like that. Yeah, we'd have all the way up to six but same rules are going to apply. What I want to do is in order to send information for the process right before I do the exec LP I want its standard in, so it's file descriptor zero to be equal to the read end of my in pipe. So, and that should be it. So essentially let's do the good old computer engineering special and do the old copy paste and replace it within. So aside from that all I want to do is replace file descriptor zero with the read end of the pipe. So here I have my dupe two. So I take whatever the read end of the point or whatever the read end of the pipe is what it's pointing to and then also make file descriptor zero point to that. And then after that same principle as before I can close the extra file descriptors. Yep. Yeah, so what's the point of use, can I just use one file descriptor for this? Or sorry, one pipe for this? Yeah. Yeah, so we'll go over quickly why you cannot do that but basically if you don't have two separate pipes you don't know which side is supposed to be writing and which side is supposed to be reading. So here, quick, if I did something silly like I don't know, made a cat. If I type into it, well this is fine because in this case whatever I type it goes to standard out, it reads it, it outputs it, that's fine. If I had it in a loop or it was constantly reading over and over again and I only used one pipe it would be reading from the same pipe it is writing to. So it would create an infinite loop. So here, I can draw that and let's see if I can draw that. So say I had a pipe, like a Super Mario Brothers pipe that's cool. So this is the right end of the pipe, right? So I'll have an arrow there, I'm like filling it with data and what poops out of the pipe is file descriptor zero or the read end of the pipe, right? So if say my process was something like cat, it's file descriptor one, two, and three. Say it's file descriptor one was filling data from the pipe and then it was reading data from that pipe and then in my other process, so say my original parent process, what would I call it sub process? Say it just wrote one character in here, so say it just wrote like a X, while it would write into the right end of the pipe and then now cat is stuck in an infinite loop. So it's going to read the X that I wrote in and then it would write out the X and then while that goes into the pipe so it would read the X, write the X, read the X, write the X, read the X, write the X, so it would be in this kind of infinite loop forever. Yeah, two pipes do not share information. That's why I'm creating two pipes because I want them separate. So why have two pipes is my like, this process is throwing data into the pipe, right? And then any data that I get out of the pipe, I read it in this process and then I'll create a separate pipe essentially like this. Whoa, that's getting funky. So I'd create a separate pipe and because they're independent, this sub process can now write data to this pipe that can be read by cat and they won't interfere with each other. Yeah, so because I forked and all my file descriptors were pointing the same thing, I can manipulate them however I want. Oh, okay. Yeah. Yeah, so it would get an infinite loop because in the implementation of cat, it just keeps on reading and reading and reading until there's no more input. Okay. So because of that, well, if it constantly would also write into the same pipe it's reading from, so it would never close and it would just get stuck in its own infinite loop. Okay, yep. If sub process was also a cat, then probably then that, yeah, that'd be like the same thing as when we had our one process and we forgot to close the file descriptors and just hung there forever. They'd both just be hanging there forever, waiting for input. All right, so now, all right, we'll go, we have to speed run this now. All right. So I have in pipe FD, so I want to give data to that. So let us create a string testing, size T. All right, so I want to actually write to in pipe FD, zero, the string, the length. All right, screw checking for errors. That's, so I'll close it after I'm done with it and then I will close the read end. Whew, okay. So this whole mess of code, that should just be writing data to the in pipe and then this, my child process, because I've set it up so that it's standard in is the read end of the pipe. It should immediately read whatever information I give it.  It doesn't read anything from standard out. So I sent some information, just ignore that. If I ran it with cat, then cat, while that reads from standard in and then outputs the standard out. So it would read in this case from the read end of the pipe, so it gets the data that I sent it, so it gets that string testing with the new line and then I go ahead and read whatever it sent out. So I can actually verify that it works. So before real quick, what we should ask to tie everything together is we create a child process? Was I a good responsible parent? No. How do I become a responsible parent? At least in this course. Yeah. Yeah, I should probably wait on the child. Does it matter what line I put the wait at in this case? Yep. So probably at the end that would be good. All right, well, all right. So I know it's process ID, so I'm just going to wait on child PID. I don't care and I don't care. All right, so I'll just wait on it and then print wait, okay, sure. So now if I run this, let's see if I'm a responsible parent and I cleaned it up because before, while I was essentially creating a, probably potentially a zombie orphan at the same time or the very least an orphan. So now in this case, oh there, I successfully waited on it so my parent, my child process was done. If I wanted to, in fact, I could also move this wait PID up before the read. So I can let it die. So I can just let it fill up that buffer. I don't have to actually read that data before it's dead. So I could move that wait PID here and nothing bad is going to happen. So it doesn't really matter because the pipe that's managed by the kernel, so it will outlast that process. So if I put it, let's see, if I put it up here, probably good things will not happen because it will just get stuck. So why does this get stuck? Yep, yeah, in this case, it doesn't exit because remember our trial process is cat, so it will just constantly read from file descriptor zero until it can't get any output and the way to signify through a pipe, if you can't get any output is no process has the right end of the pipe open. So if I put my weight right at the beginning here before I close the right end of the pipe that I use, well, it could still get data. My child process is never going to actually detect end of file or no more input. So I'll just sit here, wait forever for my child process to die, which is currently just waiting for input.  All right, so with that, just remember, I'm pulling for you, we're all in this together.


Exos Heroes episode. So, in today's episode, we're going to take a look at a new tier list. So, a nation PVP tier list. This is actually courtesy of SteelSauce of Guild Empyrus. So, he is at Reddit. So, our Exos Heroes in Reddit. So, credit to you, man. Thank you for this list. And we'll start off with Lenombe. So, basically this tier list is Exos Heroes PVP tier list version 1.5. So, again, with Lenombe, so what we have there, basically the tier list is broken down into major groups which is S and B downstairs. And also for the individual nations. So, you have there your core. Or meaning these are your core heroes for that nation that you should bring. Like, for example, here for you have Rachel and April for Lenombe. And you have there your S, your A and B. So, S would be your ideal heroes that you should bring. A would be your secondary level of high level of heroes that you should bring with Lenombe composition and also B. So, these are the least considered for each nation. So, again, we'll again start with Lenombe. So, you have here core. You have Rachel, FC Rachel and FC, FC April. The S would be Black Fate Core Baraka. So, don't confuse yourself with a Blue Fate Core. So, this is Black Fate Core Baraka. You have here FC Zion, FC, FC Schmidt, and FC Morris for S. Okay. Based on my experience there, to round up, if you really want to include another core for Lenombe, based on my opinion, it should be Zion. Okay. Zion works well as a member of Lenombe, as also in the synergy, in terms of turn resets, whenever he kills an enemy, he actually works well with the core. So, he's actually primarily, his primary position should be with the core. Again, the S is actually a good mix of heroes already. So, you just have to swap out which of them you don't have. For the A tier, we have here FC, actually sorry, for the S tier, it also includes FC Morris because of his increased attack. But for the A tier, you have there FC Iris, FC Annie, FC Tantalo, and FC Redly. So, basically, you use these guys if you don't have any or if you want to substitute your S tier and your B tier below, which is composed of Blue Fate Core Baraka. If you don't have the Black Fate Core, you have there as well Shell and FC Jinnay to round up your tier B for Lenombe. So, again, very solid.  Okay? So, those are my recommendations for Lenombe if you really want to go with Lenombe team. Okay, for the next one, to their right is Wasted Red, which is actually my main faction, which I've been using for a couple of months already. So, I know this team well and more or less and more or less how to play Wasted Red. So, again, core would be Garf and would be Redly. Your S tier would be Annie. Annie is actually more or less part of the core already. They synergize well, the three of them Redly. Redly, Annie, and Garf are Annie and Redly especially because Annie is actually applying her passive to Redly, which is, I think, I forgot the passive. It's more on soul something, okay? But that passive of her that increases speed and gives immunity is usually applied to Redly because Redly is usually the fastest of the group. Okay? To want my opinion, the best team to comprise of Wasted Red right now would include F. T. Schmid and F. C. Iris. Okay, I'm actually currently using this team. Dorca I've used before, but not anymore because I usually rely on Redly for increased health and increased defense, but they would round out your S tier for Wasted Red. Okay? Your A tier for Wasted Red would include again a supplement of Maggie, F. C. Valar, F. C. Redly, and the recently buffed F. C. Gene. Gene has been good in terms of probably replacing F. C. Iris, but again, he hasn't been tested yet in terms of PVP. He just joined and will have more matches with F. C. Gene in the future, but for now he's at A tier for Wasted Red. Okay? B tier would include F. C. Gene, F. C. Iris, which I sometimes use. I usually replace F. C. Schmid and F. C. Iris with Gene and with Shell because they actually, I also have Astorius built up and you have here as well as in your B tier, O. Tard, F. C. O. Tard, and F. C. Scarlet. Okay? So again, my recommendation for this team, which I'm currently using is Garf, Redly, Annie, Schmid, and Iris. So that is my recommendation for Wasted Red if you have those heroes or if you want to have them built up. Okay? Well, go to Greenland next. So for Greenland, of course, your core would be Bathory and would be F. C. Rera. Okay? Because again, they're the one to punch for Greenland. Next would be S tier. You have their Talia, you have their F. C. Iris, you have F. C. Tantalo, and F. C. Schmid. Okay? For this group, the normal ascension here into core, the core that you must add on the S tier should be F. C. Tantalo. F. C. Tantalo is actually so annoying in terms of damage immunity. It's just now that he has a counter with F. C. Schmid, but again, F. C. Tantalo is very serviceable even though F. C. Schmid is actually in the game already. Some of the teams that I've seen mostly comprise of Bathory, Rera, F. C. Talia, F. C. Tantalo, and F. C. Schmid. So that is actually the team that is actually very good as well right now for Greenland. So again, those are your S tiers. For your A tier S substitutes, you have their F. C. Reddy, F. C. Ramji, the first Garjan version. You have their F. C. Talia and F. C. Ulum. So you don't have the S tier level heroes, then you could use the A tier and also as you go down with the B tier, you have their F. C. Annie, F. C. F. C. Junai, and F. C. Shell. Okay, but my recommendation again with what I've seen and what I've encountered is use F. C. Bathory, F. C. Rera, F. C. Talia, F. C. Tantalo, and F. C. Schmid. So those will be your core in terms of Greenland. Okay, so next we move on to North One Frosty. So North One Frosty, your core would be again F. C. Shufraken and F. C. Valentina. So basically as you go down to the S tier, there are a lot of options that you can build with North One Frosty. They have been what you call a control type of nation in terms of the combo evolves around Valentina. For sure you have to bring, for S tier you have to bring, the core would, I think would involve definitely Bathory because again, Bathory would be your primary hero to take off Summer's Blessing so that Valentina can land her attack. So again, primary you have to have Valentina to be put up there with the core. My next would be I think F. C. Dorca. Sorry, not F. C. Dorca. Dorca because Dorca is actually one of the heroes here in this team comp in this nation that can also give you support, also health generation and the other one that I think you should consider would be F. C. Iris. Okay, because without F. C. Iris and if you are, if you have, you know, if you have first gardens on the other side with shields, enemies would be a little bit tougher to defeat because mostly for North One Frosty, they don't have high damage dealing heroes. It's more or less for control and their usual win con is to lock up your enemies and to pick them off one by one. So again, these are your S tier so more or less, Tantalu here in Bathory just have to swap each one out for the other. Some teams actually carry both, but I'd rather you bring either of them so that you can squeeze in Bathory or an F. C. Iris in there. Okay, so for the eights here, most of the heroes here, which is F. C. Brooke, then you have here, this is F. C. Degas and F. C. Talia and F. C. Redley. More or less, these will be your supporting if you don't have the ones in your S. These are mainly for control as well except for Brooke of course because of damage. So F. C. Degas, Redley would be support and Talia would be support if you want to replace Dorca as well. And B and for Tier B, these are the last group of heroes that if you have, you can swap out for your tier S. Okay, but my recommended team comp for North One Frosty is F. C. Shufraken, F. C. Valentina, F. C. Bathory, Dorca, and F. C. Iris. So those are my recommendations because I myself have been using them in PVP tag. Okay, so we'll go to the last nation which is Astorius Republic. Astorius is a bit weird because it doesn't have really a solid core right now. Astorius doesn't have a solid healer on their side and more or less, they need another core reverse aside from F. C. Adams. Okay, so again for the core, you have their F. C. Jani, F. C. Shell. Then for your S, you have F. C. Adams, F. C. Schmidt, and F. C. Redley. Mostly what you can consider here for your core would be F. C. Adams because of his recent, let me call this, because of his recent core reverse. It's actually good and I've been using him as well for tag PVP together with Jani and Shell and he is really, really good right now. And also for Schmidt would also go well with their group. Redley actually would give them the health bump and the defense bump if you use them with the core of Jani and Shell. But if you go down to your eighth year for Astorius Republic, you will have their Deva, you will have their F. C. Emma, F. C. Luke, and F. C. Jin. Okay, so you can actually replace them. You can actually put up their Luke for more defense. You could replace Redley. You could actually replace Jin with Adams as well. So you can, these are your heroes that you can swap out for your S tier just in case you have them or if you have leveled them up more than your S tier. And for your tier B, okay, you have Dorca. I think this is F. C. Ramgy and this is F. C. Legger. Okay, so these would round out your tier B for Astorius Republic. But again, my recommendation for your core, for your five for Astorius would be Shell, Jani, Adams, then you have Schmidt. Then for me, I think I would bring Luke. Just for the sake of a small defense or again, Redley, I'm actually torn between Luke and Redley. So, but for this one, I would try to go with Luke for defense. But if you really want that bump in health and defense, then you go with Redley instead. Okay, so more or less that is it for our Exos Heroes PVP tier list, version 1.5. Again, thank you for Steel Sauce for sharing this list with the community for Reddit, for Exos Heroes Reddit. So, he belongs to Guild Empires. Thank you for this information. Again, this was just updated yesterday, April 9th, 2021. Okay, guys, if you have any comments, any suggestions, please write them down in the comments section. So, for those who haven't subscribed to my channel, please subscribe. This helps a lot my channel. Mostly around 85% of my viewers haven't subscribed yet. So, please do. Again, guys, have a very well and safe weekend ahead. Also, take care of yourself, everyone. This is the warden. I'm out here.


Hai, semua. Ini actually my first headwear attendance. Terima kasih, Brian, for inviting me. Ya, I'm coming in with a background of no background. Before I started on this kind of stuff a few months ago, I had no experience even like fixing my computer. My dad did all the stuff for me. So my dad is the guy who fixes stuff in my household. And only recently when I started working for the one maker group in February, somewhere middle of this year, they really start to get involved in all this kind of stuff. And my first project that I did was inspired by this video on the cupcake. I don't know whether you guys have seen this video on the cupcake. For those who haven't, maybe I'll just play to entertain all of us.  So this is actually the thing I found, maybe on one of those Facebook. We see interesting things on Facebook, you can click. And I was blown away at how you can actually build something like this. So I did an impulse purchase. I bought a kit online from Adafruit. And I actually procrastinated on it. I bought it last year. And I only really started getting back to doing it when I joined the one maker group. Because you know, you have all the stuff there. So I'm really glad to say that for a complete beginner, assembly in the kit only takes like 5 hours. And you can actually get it to work. So this is it. It works as advertised. So there is no tricks involved. And I don't know how I can let you all see the thing.  Ya, ya, ya. There's a few stuff I want to demo for you all. So find the table. So the thing about this is that there was no programming involved. A lot of people will ask people, you know, I learned coding in a few days. I learned how to code a game into the Raspberry Pi in a few days. No, all you have to do is flash an image that Adafruit already makes for you. And you know, the games are just transferred onto it by dragging and dropping onto the folder in the SD card. So it was really idiot-proof and beginner-friendly. So ya, it's very rewarding. You have this kind of outcome in your mind. It seems more rewarding to do something like this because you relate with what you're building. A lot of the causes I see on electronics had boards with flashing LEDs and what. And I couldn't really relate to those. I don't see all these components in my day-to-day life. They look like the really high-end stuff. But when you put it in this kind of package to Adafruit's credit, you can really be inspired to work towards something that you feel you understand. And other people can understand because even if you don't understand a board, I think everyone will understand Pac-Man. Ya, so in honour, you can actually play a lot of games on this, but I chose Pac-Man to make it as relatable. I feel that it's testament to how great this product is because after I built it, I won't simplify and my bosses' kids come into the office and they spend time playing with this on their own. So it's on. I don't know whether you can see, but I think you can hear it. So it's actually running. So this was the first step. And I was thinking myself if you can inspire someone like me with no background to build something like this for a few seconds. Why not take it one step further and make a wooden version? In the process, teach people things like laser cutting and soldering and add this customization element to such a product. So my vision for this is actually I'm trying to figure out can we hold a class for absolute beginners to make a range of this like clear acrylic, black acrylic, wood, painted with flowers and all that on top of programming it with different games or functions and have more interesting electronics classes for beginners to jump in with. That's really my goal and I spent an entire month doing things the hardware by if you look behind here there's an interface board which I created from a proto board from scratch means I soldered all the connections instead of joining the pins on a breadboard. So with no background that took me the board alone took me a week, a month creating the measurements for this case to another month for 16 times of laser cutting that I did at the one makers group I think Leon you have seen me struggle with the machine over there which is something that I really appreciate the one makers group to allow me to do because no one else has access to that much free laser cutting so yeah perks of the job I can pay for it it's like in other cases where can you get a giant laser cutter to prototype stuff like that so thankfully it works exactly the same as this and yeah I feel that this 2 month long struggle to get the wooden one work was worth it because maybe I can get advice from you guys down here the gurus like how can we make something like this accessible to more beginners to learn how to make so yeah I haven't uploaded I literally just finished the measurements 4 days ago so yeah but I will definitely upload this to let people try out what the original sorry what the original files from airfruit did they put it up there or did you have to design yourself again so the image file is downloaded from airfruit but the casing the casing measurements ok people ask for it but they only wanted to know the external visible like casing parts so those were put online but they will also put on a PDF file with the measurements so I literally had to put the whole thing and measure with a vernier calibre every tab not fun not fun and yeah it took quite a while let's put it that way but it came through the case yeah so the kit originally comes with the case and everything except the raspberry pi so one of the things I'm struggling with making a cost for this is that this cost 160 Singapore dollars to make including shipping so if you hold a cost it's going to cost about 200 bucks because I want to pay 200 bucks to make this like learn to make this I don't know so that's why I'm trying to cost down it by making it with wood and like doing the board with like resistors and what so maybe it can make it cheaper lah I don't know now so sorry copyright where me no copyright copyright no copyright it's asking it's asking it's asking no ya what it doesn't have any copyright is it copyrighted like the design it's creative commons ya so I mean I honestly didn't check so I don't know maybe I'm doing something illegal I don't know but I was just very motivated to see whether I can make a wooden version knowing enough or do you know who's like actually designed okay the guy is called Philip Burgess so maybe I can ask him he should but I would think it's probably going to be yeah it's really likely sorry they are very pro open source ya that's a relief this guy is incredible he makes all this kind of stuff I mean if you message him and send him your design he'll probably like give you extra tips hopefully hopefully the goal of this is just to make a more interesting lesson actually what about building a bigger one with a I get a lot of requests like that um I was thinking can I start a company making big ones then someone actually in maker fact actually already does that yeah I was a bit disheartened I was like oh someone doing it but it's fine but but but his one is different because his has you have to put your laptop inside or your PS4 inside and then you play your game on that so I have to be able to afford a PS4 on a laptop so for my argument is that I'm not trying to compete in terms of product or what can we teach people to make and I think making something tiny and cute and affordable like this is much better maybe if you can pay more there are okay in the US there's this company called Nano Arcade where they make a lot of very funky decal like this kind of things but I'm not too worried about that because like I said I'm here to try to teach people how to make this more than to sell this product very quiet okay something okay okay and brah yeah so are there still enough jika you're able to put in another set of joystick and another set of joystick I don't think so so as long as there's no player okay yeah a good question I have no clue I am really honestly okay so the drawback of making something like this is that you can go through without having truly learn a single thing about electronics like I still don't understand exactly how the Raspberry Pi works to be honest I only know how to upload the image file onto it and that's it so that's a drawback yeah now it reminds me of another drawback it runs on the Raspberry Pi model B so if I want to keep making more to probably eventually configure to Pi 2 for instance it should work yeah I guess the image file is probably not yeah you might have to change the baseball I might yeah actually that matter is the connector might be different because it's slightly the connector has moved some of the pins have moved isn't it it has moved 26x40 or it has moved it has moved in many areas I think an SGB from the screen alright we will definitely play with the FPGAs and little equal arcades so this time we will make a project with the FPGF background that's an awesome idea that's what we want to post the screen now so the last segment we will very quickly go through the higher rate