0:00 Introduction to AlphaBits

0:00 Hi, and welcome to AlphaBits. AlphaBits is an outlet for our inquisitive minds. We can't stop experimenting with new technology, and we wanna share what we're playing with with you. We're your hosts, Brian and David. Hi. I'm David, defender of the Rawkode Academy. I'm a perpetual learner, always playing with new cool tools that I'm gonna share with you as part of this podcast. And I'm Brian. I'm a developer advocate at Amazon, and I love all the shiny new toys in tech. It's kind of my passion is is testing out the new stuff and, seeing what's cool. Alright. For anyone tuning in

0:35 on YouTube listening to this right now, there was a podcast element you can check out with all good podcast players. On that, Brian told us why he is demoing a new Linux operating system for us today. So with that, Brian, take it away. Alright. So what we are looking at here is my daily driver desktop. This is running a derivation of Fedora Silver Blue. And I gotta be honest. When I first heard about this, the first thing I thought was, Fedora? I'm good. And I've been an Ubuntu guy forever or PopOS. I love the Debian

0:49 Introducing Universal Blue & Fedora Silver Blue

1:12 derivatives. But Silver Blue and, specifically, Universal Blue have a draw that that's really important and exciting for me. So I wanna talk about what what the foundation of this operating system is. It's it's an operating system that's built in the cloud native methodology. So if you go to the GitHub repository, which is at uBlueOS, you can see that, there's 46 repositories here, and each of them defines a container. So the main, this is our base. And this is, the base container file that all of the other images inherit from. So it starts off by adding a few

1:25 Universal Blue: Cloud Native OS Foundation (Container Images)

2:01 important things, packages that need to be installed in the base operating system. Each of the derivatives build off of that main, container file. And the one I'm running is Bluefin, which is a an an Ubuntu like experience for Fedora. And if you look at this container file, let me bump this up a bit, you could see this it looks just like a Dockerfile because it is a Dockerfile. And the GitHub actions for this repository build the OCI container and push it up to the GitHub container repository. So let's look at my system specifically. Let's do an RPM OS three status.

2:36 Image-Based System & Rollbacks (RPM OS Tree)

2:45 And from here, you can see that my system is booted off of a Docker image called BluefinDX NVIDIA, and that comes from this repository that I just showed you on GitHub. I've got because it's RPM OS tree, I get, my current and my last known good configuration. So if if I do something, I break it. I can just roll it back. But the exciting thing is is when we make a change to the Bluefin repository, GitHub actions builds those images and pushes them up to the GitHub container repository. And then I can just wait for my

3:23 computer to pull it. We've got a schedule that pulls, the next release every afternoon. And if there's no release, it's not a big deal. If there is, I can just check this RPM o s three status again. And if I notice that there's an image above this, the the live image, I can just reboot to get that new image. So it's everything you love about cloud native and containers but applied to a desktop. That's really epic. We've got the whole operating system scripted with a Just file. It's actually three Just files. So if I type Just,

3:46 Included Developer Tools (Justfile, DistroBox, Nix, etc.)

3:55 you can see all these things that are kind of, friendly, helpful tools that let us get going in a way that we want to. So some of them install, Flatpaks for the applications that we need. We've got DistroBox built in. We've got NICs and DevBox built in, the t package manager. We pretty much thought through everything you might need as a cloud native developer, and it's all just a a keystroke away. So I I love this. It's it's been, liberating having a desktop that I can't really break easily. And if I do, I can just roll

4:32 it back, with a container image. It's unbelievable. So you're just running the standard bluefin image. Or have you got your own version with any tweaks to it? I I don't have any personal tweaks, but it it would be easy. I just fork Bluefin and and inherit from it in the container file. But I really don't need to because all the customizations I need, I can do either with NICS or by adding my own GNOME extensions. So I've got access to everything. You can see NICS is here. We've got DistroBox. So Podman, don't have any containers running right now, but

4:50 Customization with Nix, Flatpak & Overlays

5:07 I could. See, previously, I did the CUDA test to make sure that my NVIDIA card is able to pass through to Podman. Works great. I've got a distro box universal, so I could do distro box enter universal. And now I'm in the, Microsoft dev container Universal dev container that they use on Codespaces. So I've got Go in here already. But if I exit back to the host, there's no Go. So it's it's pretty slick. So what's the process if you did want to add, like, a GNOME extension then? Well, for for GNOME extension, I would just

5:51 open up the GNOME extension manager, which we have here, and that's on the wrong screen. So you could just browse GNOME extensions and install one that you like, or you can remove some of the ones that you have installed. Okay. So you do have the ability to write to parts of your operating system. It's just the base Yes. It's like the core OS. So so the the home is obviously writable, and Etsy is writable as an overlay on top of the Etsy that comes with the OS. So it does use overlays to persist operating system level changes.

6:28 Okay. That's pretty cool. I mean, it makes me kinda you know, I run a Mac right now, but, know, I keep trying. Every time I go away from Linux, I've always got this desire to go back to Linux. Yeah. And and that's kind of that that's where I've lived too. You know, I I love the Mac experience. But for developing, for doing cloud native things, Linux is kinda hand handy to have around. I can run a Kubernetes setup because kind is already installed, Scorpio's installed, Helm is installed. All of the tools that I need are

7:00 already here, and they're guaranteed to be up to date. So it it's it's really powerful. Alright. There goes my weekend. Thanks for that. Yeah. Well, if you do give it a shot, you know, throw it on an old laptop or something and let us know what you think because we're trying to make this literally the best place for a developer to live or a a DevOps engineer or any cloud native people. You know, this it it's got everything you need. We've we tried to think of everything, but if there's something missing, let us know. We'll add it. Are you

7:28 a contributor to? I am. Yes. I'm a contributor to Bluefin specifically, but I also built, Fleek, which is a home management platform for Nick's OS or for Nick's. So let's do get Fleek. So I built this as part of the, uBlue process so that I can have my dot files, my home configuration follow me anywhere. So that's it. Get fleek dot dev. Alright. Lots of things to check out. That's very cool. Yeah. Good choice. Alright. So I'll stop sharing. I wanna see what you've got because I'm all about some some system configuration, ClickOps replacement stuff.

8:00 Transition to System Initiative

8:10 Well, yeah. I mean, unintended, but you've covered desktop, and now I'm gonna cover cloud and platform. So I have set a few things up just because getting SI, the System Initiative thing, up and running does take a little bit of time. It uses Dirt Enve, which has a Next Shell, which takes like ten to fifteen minutes to get everything bootstrapped. But only does it once and then you're good. Okay. So this is running until which spends up the entire SI platform for you. You can see here, we've got the back end which comprises of four

8:22 System Initiative Setup with Tilt

8:41 services, the front end, the platform itself, and then the tilt file there. So everything is up and running. Everything is healthy. So can you explain what what tilt is for us real quick? So tilt is you write a tilt file, and it basically just orchestrates containers. So you say, I have these groups of containers go back end. These groups of containers go front end. They have dependencies. The front end can only come online when the back end is online. The back end consists of these four container images, and they expose these ports. And then it

9:10 does all of that for you. So it just gives you, like, a really nice definite experience. So it's like a a better Docker Compose? It definitely competes with Docker Compose. Yeah. And it can even integrate web. So if you do have a Docker Compose file, but you just want this nice UI and ability to kinda click in and, you know, see the logs from all of the things, then you can just have it wrapped Docker Compose for you. But most of the value comes from just just describing all your containers and the dependencies properly, whether in the type Tilt file.

9:39 And, also, you can kind of, like it does performance enhancement things. So if you've got, like, an interpreted language where you have to mount the code into a container, it can actually kind of do that in a way that is a little bit more performant than the standard Docker composements, volumements. So, yeah, it's it's a nice tool. It got bought by Docker about eighteen months ago, maybe two years ago. I can't remember. It's been a a while. But it's still going strong. It's still a really good tool for just saying, hey. My development environment is not a single container with

10:08 a database. It's a bunch of things with dependencies. Let's make this easy for people. So yeah. Very cool. But that's not what we're looking at today. So I'm gonna skip right past it. And we're gonna now go over to here where we have my SI workspace. Right now, SI works with AWS with a limited set of resources, but, you know, this is a very, very early proof of concept and demo from the SI team. And so this is gonna, I imagine, support more clouds and more resources over time. But what it allows you to do is say,

10:22 Building Infrastructure Visually (AWS Region)

10:41 well, I want AWS region where I'm gonna deploy things to. So we drag that onto the map, and we can do all the little things you would expect from, like, you know, a UI based tool, resize, right click, edit properties, and if you want. From here, I can say, okay. Region do I want to deploy to? And it loads all the regions from the API. So I can just say, hey. I'm gonna deploy to London. And now test the model. So this is a visual representation for the model, which is all code. And it makes sure that your model is

11:18 always valid at all points in time. If your model is not valid, you will get an error down here. But as you can see, I have happy green text everywhere. Green text are good. So we could say, well, let's have an EC two instance. Now this is not going to be green because there are inputs, properties on this instance which are not going to be satisfied. So we'll let the model test and we'll see that, okay, we have user data, security group ID, key name, and an image ID. The region name or the region is

11:30 Adding Resources & Model Validation

11:56 grayed out because it's inferred from In the region. Okay. Exactly. And we actually you know, we can't drag this out now. This is no part of this. So we pop this up and it will start to tell us. You know, we can see here the region is green, the region is fine, but on this, the instance type is required and that it can't run the command because it's not in a happy state. So we could start to fill this out where we drop in values to all these things. But we can probably let the inference handle most of this for

12:28 us. So we know that we need user data. So for my user data, I'm gonna use butane, which is just the core OS and it system, I guess. So user data provisioning system kinda like cloud in it. In fact generator. Yeah. Yeah. Which needs a container image and then has an output of user So you can see here the inputs are on the left, the outputs are on the right. So we can bring in and say, okay. Let's have a docker image. So we're just gonna start stitching this together until we have a system we can deploy.

12:30 Connecting Components & Inference

12:58 So we can drag this to here. So now this container image is gonna satisfy this. And we can change the image here to be engine x. Well, let's give that a second to test the model again. Testing does seem a little bit slow right now, but this is extremely early software. This is definitely putting the alpha into alphabets. Yeah. It looks like it's doing a lot though. So I I can appreciate that. Yeah. So now it tells us our Docker image is green. What I like about this is if I say big image does not exist,

13:35 trying to type in enough characters so that I don't accidentally get some random image. It should actually go red and tell us that this image can't be discovered. And if that image name does exist, then that's a there we go. We got the cross. So we could pop this up. We could take a look. Okay. SI4117. Image not real. So now, of course, we can rename this. So we could just say, you the resource name is NGINX. The image that we want is NGINX. And then we can just kinda quickly through and tie up some of these dots. So

14:05 we need a key pair. We need a security group. We need an ingress rule. We can drag our user data onto our instance. I know my lines are not gonna be particularly straight here, so let me just, you know, do this. We can see their instance needs a security group ID, so we can connect it on that now. Now is this logged in to an your AWS account? So it it pulls your available keys and It gives us ambient authentication. So whatever my CLI is configured with. Okay. Perfect. Let it test the model before I start

14:44 dragging more things and slowing it down. Cool. Now we can drag our key name. We can drag our security group onto the security group ID. Our Docker container expose these ports. You can see there's an output on this container image. So we can click on this and we can say, okay. Let's add and let's expose this AT on TCP. This now becomes something we can use over here and part of our security group where we can see that exposed reports or Docker container uses. So Oh, wow. It just kind of magically builds all of this in the background to

15:22 the point where we get happy, and then we merge this change set, and then we can deploy it. So the last thing we need is a AMI ID, which I need to grab from I'll just grab one from the Fedora website for my region, which is here. So I'm gonna click on our EC two instance. And the image ID, I'm just gonna drop that in. And as this type, I'll just go with a t through t three large. We'll keep that nice and simple. And I think that should be enough. So the AMI you chose for

16:00 core OS? Yes. Yeah. And the fedora core OS image because we're using butane. Oh, wait. Why did I copy this here? What we want is an AMI. And we add the image ID to this, and then we connect the dots with our instance. There we go. So that should put us in the green. So what do we have? We have a region. We have an easy two instance. The user data for the instance is generated from the butane module, which knows and understands the docker image that we want to run, which also exposes ports, which goes as an

16:38 ingress rule, which automatically configured on our security group. We have a key peer key pair that is created for our instance and an AMI configuration. Still complaining, but I think we're okay. So I'm gonna say merge, and we merge this into the state of the world. Now when you merge the change set, it gives you a plan, like a Terraform plan of the actions that you need to make in order to realize this configuration. We can see here, we want to create the key pair, security group, the instance, and the ingress. So we can see select all

16:47 Merging Changes & Applying the Plan

17:12 and apply. And this will now spend the next thirty to sixty seconds running through the system, creating all of these resources and or maybe my STS access has now actually disappeared. So let me reconfigure that. So what tool is it using in the background to apply these? Is it a CloudFormation? Is it TerraForm? Is it Pulumi? Is it something some other thing? Or is it own its own thing? You know what? I'm not entirely sure. I do think it's CloudFormation. I know it's using the AWS CLI to do a lot of this stuff. I don't know if it's actually

17:46 calling out and just using, you know, AWS compute key pair create. It it may very well be. So let's see if we can fix my permissions real quick. Any questions while we kinda wait for this to catch up with me? No. This is fascinating. Hurry up and fail. Infrastructure is connect the dots. Yes. Like I said in the earlier segment, though, is that you still get the ability to drop down and to code. So we can take a look at that as well if we have enough time. I think my what I might do is

18:09 Code View & Infrastructure as Code

18:25 just delete most of this and it will just create a key pair. Well, maybe it'll catch up. And you said this was multiplayer, so you could invite someone to come in and collaborate on this with you? Yeah. So these workspaces, can add more people to. You can work on your chain sets at the same time. You can go over architectures. You can do whatever it is that you need to do. Okay. That thing that failed. Alright. I actually see the key pair created. That should be nice and quick. So we can go over to the management console.

18:31 Multiplayer & Collaboration

18:55 So we can go to easy two and key pairs. And those are SI2165SI2165. That completes it. Yep. You can see all the information here. So if you do wanna grab this into your local machine, you know, the private key is there. You can save it locally. Of course, you would have to add a new ingress to expose the port 22 because obviously that's not gonna be there by default. And even with core west, I'm not sure how much access you would get anyway. We can see now our security group was created. We can come into our security group,

19:00 Verifying Deployment in AWS

19:34 and we have our SI 2536. So that's gonna create all of those resources for us exposing NGINX and things are nice. You have different views. So you can come to the analyze view here where you can click on, say, your key pair, instance, and you can see the code that it used to create it. This looks like cloud formation to me, so I suspect that it may be. But it also could just be a JSON representation of what gets passed to the AWS CLI. I'm not that sure. As things change, you can just reel refresh

20:04 Analysis View & Future Potential of SI

20:04 the resource by clicking this button here. If things change on the console, it will actually pull those changes in. And now when you're happy with your production, you come and say, well, let's make a new change set and say, we wanna deploy, you know, bluefin, which I know we can't really do. But we could just make up our own change set and start adding more resources to our entire workspace. But it's a pretty select system. It's very early. It's very cool. It's got a lot of promise, and I just can't wait for them to support

20:35 more resources. Like, being able to provision a Kubernetes cluster, an EKS cluster through this interface, I think, would just be phenomenal. And even to the point where it automatically builds the provider for Kubernetes and lets me just drag and drop on Kubernetes resources or custom resources. Like, I think the power and flexibility of this platform could be a bit of a game changer. Yeah. A lot of potential here. Yeah. Definitely. Alright. Well, that's the first alphabets. Hooray. So we gotta do this again. Awesome. I can't wait. There's enough software there that looks like we're gonna run out of ideas anytime

20:59 Conclusion & Wrap-up

21:09 soon. Not a chance. We'll run out of trouble. We hope you enjoyed the demo of both of these amazing tools. If you wanna hear why we showed up for these tools, check out the podcast available at alphabets.fm. Until next week. See you soon.