All right. Yeah, let's try that again. I'm Benjamin Gilbert, formerly on the Container Linux team at CoreOS, now on the CoreOS team at Red Hat, working on Container Linux and on Fedora CoreOS. I am Dusty Mabe. Previously I've been involved in the atomic working group within Fedora, and now involved in the Fedora CoreOS working group. So that's what I do. Cool. So we're gonna do a few things here. Interesting. We're gonna do a few things. I'm gonna talk for a while about Container Linux. I assume that folks in this room aren't necessarily that familiar with it. And then afterward, Dusty's gonna talk about project atomic, and at the end we're going to close with how both of those projects have informed where we think we're going for Fedora CoreOS. So where did Container Linux come from? This is a Linux OS project that we started in 2013 at the then fledgling startup CoreOS. It's based on Chromium OS, which is the Google Chrome OS upstream open-source project. We inherited a lot of its design choices, including the fact that it uses Gen2 packages, Gen2 tooling, to build software.  And the thing we're building is a minimal container-focused server operating system for production use. Targeting primarily cluster deployments though also operate standalone. And we think a lot in terms of a mutable infrastructure, and I'll talk about that more in a minute. Automatic updates are a big part of the story. The idea is that you should be able to install Container Linux node. Install Container Linux node, and not think about it afterward. The node should just update itself, and you shouldn't have to worry. We try to have broad platform support so that whatever cloud you want to run on, or whatever bare metal system or whatever, you can do so. And of course, stability and security are a primary concern. So that seems to have helped, but could you... Okay, so going into some of those in a little bit more detail. Production operating system, what does that mean exactly? We do not ship anything that you don't need for running containers in production for the most part. No development tools, except Git. Not a lot of debugging tools, and really just enough to get your hardware going and then run containers. Immutable infrastructure, I mentioned a moment before. The idea here is that you have the base OS image, and then any customizations you want to make to configuration, or what have you, are encoded in a single provisioning configuration that you pass through user data, for example, in the cloud. We don't prevent you from SSH-ing in and arbitrarily modifying the node afterward, but really you shouldn't. Configuration management, this is a bit tongue-in-cheek, is not something we really encourage. You're free to do it. You can, Ansible can run with some effort, but really the idea is that if you want to make changes, you should probably be reprovisioning the node. And then automatic updates, as I said, users shouldn't have to think about them. This has consequences for us. We cannot break compatibility ever. If there are old bootloaders that we no longer ship, which is true, if there are old versions of cloud agents that are still on nodes, we have to work. If a daemon is updated, it still needs to be able to read the old version of the config file, or we have to go through some conversion process. And if we really do need to deprecate a service and remove it from the operating system, there has to be a long deprecation window, which long for us means probably upwards of a year. And then, of course, no regressions. That's hard to do. If we regress too much, users will disable automatic updates, and they will no longer be getting security patches, and they'll be running some OS version from two years ago. Here's a list of the platforms we support, pretty much all the major, at least, US and European-focused cloud providers. Live Pixie is an important case for us. We actually have quite a large percentage of our user base is booting container Linux from Pixie into RAM, and the OS itself is running under RAM. A big part of the story is install and update. How does that work? I'm sorry, but I'm going to present you with a partition table. And the reason is that this is pretty important for understanding how the operating system fits together. So at the end there is the root file system that is for user data. Should we try the other mic? The root partition is for user data, and it's for configuration data. You can put whatever you want in Etsy, and that's fine. The rest of the partitions are owned by the operating system, and users are not encouraged to mess with them. So boot, of course, is for kernels, and then we have two identical partitions for user, because all of the operating system code is shipped in user as a mutable file system image. So there's an active passive partition, and we update one while running from the other, and then reboot. The OEM partition is for, it's a weird name for historical reasons, it's for platform-specific customizations, like on GCE, or Packet, or whatever, and I'll talk about that a little bit more later. How do we install this thing? There are no installers in the cloud. You launch an Ami or an image of some sort, and of course for Pixi there's no installer. So that leaves bare metal installed to disk, and we didn't want to write an installer just for that use case, where you're doing your customization in a way different from the other platforms. So the installer is just a shell script that really just downloads an image and de-dies onto the disk. That works pretty well. It doesn't work perfectly. 4K sector drives are a problem, but for the most part it works. You get a monolithic image, same as on other platforms. Once you have that monolithic image booted, you need to customize it, provision it in some way. We've had a couple attempts at this. Canonical CloudNet is the obvious thing to try. It's written in Python, we don't ship Python. We wrote our own. It's more or less CloudNet, kind of less. It turned out to be a problem. It runs as a regular process halfway through boot, and at that point it runs around, and writes our config files, and enables and disables services, and starts services. And when it fails, you're left with a half-configured system. Even when it succeeds, you end up with complications around service ordering and that kind of thing. Also it runs on every boot, which means that users try to modify the config behind its back and then reboot to have it pick up changes, and it was really never designed for that. So to correct those problems, we built Ignition. Ignition is a provisioning system that runs in the NetRAMFS once on first boot. And because it's running that early, it can do things with impunity that CloudNet couldn't. So it can, of course, drop files, it can create system to use units, enable and disable services, and that's fine because the boot hasn't really started yet. It can create users and groups. But because it's running in part before the root file system is even mounted, it can do things like reformat the root file system. If you want it to be XFS or butteress instead of X4, you can do that with Ignition. And then finally, if provisioning fails, you're done. We just drop you to an emergency shell and we don't boot the system at all. Which means that if the system comes up, you know that it's provisioned properly. Okay, atomic updates. How do we update? I mentioned the active and passive system before. We ship you an X4 file system image in a kernel and it gets written down to the disk. That's easy to explain. It seems pretty nice. It has limitations. Updates overwrite the previous version. We had a case recently where we had a bad version and we were trying to update out of it. But that was kind of scary. We weren't sure whether we were going to be able to update out of it in that case, but trying to do so was going to overwrite the last known good previous version. And there was just no way to do that with the AB model. Once we boot into the new system, 45 seconds later, it commits. And at that point, the updater can now fetch a subsequent update and download that. So there's this very narrow window where rollback is even possible. And we have essentially one update image per architecture because the platform customizations are only embedded in the install image. An important piece of how we do updates is staged rollouts. We do not just push an update to the mirrors and let everyone download at once. If a client wants to receive an update, it has to call into a server to get permission, and we ramp up over time the number of nodes we're allowing to update. Nominally, this allows us to watch test reports coming back from nodes. But in practice, the major use of it is that if a user reports a bug in the new version, we can stop the rollout before it hits all nodes. In the process of talking to the update server, the client sends some metrics, cloud platform OS version, original OS version, that kind of thing. But because that's coupled to the update system, if a user disables updates for whatever reason, we no longer get those metrics and we have no idea. The node becomes dark matter. We have no idea that it's out there. These are some of the components that are involved, protocol, client server. They all have problems. That was not code that we wanted to carry forward. Clustering. So once a node is updated, it needs to reboot into the new kernel and the new user partition. And the original assumption was that the OS would be installed in clusters, and the cluster has to handle node failures. And so it's okay to just reboot a node. We can't reboot all the nodes at once, of course, or the cluster would go down. So we have a coordination mechanism called locksmiths, which takes a lock in EtsyD to ensure that only one node in the cluster can reboot at any given time. But the cluster doesn't know about any of this. If you have a Kubernetes system with container Linux underneath, and just using this mechanism, the nodes don't drain before it reboots. So some connections that you're serving will just drop. Conversely, the cluster doesn't control the OS version running on each of the nodes. The nodes are all updating at their own pace, and that's not ideal either. So what we needed to do for Tectonic and for Kubernetes was build a higher level coordination mechanism. And we did that, but it doesn't get any help from the operating system. It's reaching in and twiddling some of the same mechanisms without going through locksmith or any of the tooling that's shipped on the OS. So that's not ideal. Automatic updates also have exclusions. The OEM partition that I mentioned earlier, which contains a lot of the platform-specific code, the cloud agents, cannot be updated for weird historical reasons. The bootloader can't be updated either for the reason that if you break the bootloader, you break the machine. And so it just didn't seem safe. And then one day we had a bug where there was memory corruption inside Grubb, and depending on the exact, like, block-level layout of the boot partition, Grubb would start boot-looping. We have a shell script, core-rest-post-enst. It runs after the image is laid down, and it contains all the hacks. So what we had to do to fix this was detect the broken versions of Grubb and use printf and dd to binary patch them. Just briefly, automatic rollback. It seems like a useful thing to do if the node fails to come back after a reboot, boot back into the old version. That kind of works. There's no reason we couldn't have gotten this completely working, but we didn't put the time into it. So if the new OS version is early enough in boot, we will automatically reboot back into the old system. Because you get further into the boot, things get fuzzier. If the network doesn't come up because you have a bad network driver, there's a problem. We don't detect it. If there's a service that you particularly care about like Dockerdee that doesn't start, we don't detect it. You end up with a broken machine. Even if we do automatically roll you back, the update client doesn't know and it'll just apply. Now you're boot-looping except with the 300 megabyte download in between. And finally, we don't have user-specific health checks for things like special services that the user cares about. Very briefly, update channels. There are several. Most of the time you'll want to run container links on the stable channel, but there exists faster-moving beta and alpha releases. For reasons I'll get to in a moment, we try to keep those also usable, and we encourage users to run a few percent of their nodes on each of them. Here's the reason. There's plenty of manual routine testing. We have CI, and the CI tests are fine as far as they go, but we're shipping millions of lines of kernel and system D and Docker, and there are things that CI isn't going to catch. This is why you want to run alpha and beta. So the idea is by the time code is promoted to the stable channel, users who have a few percent of their nodes on the earlier channels should have caught problems that are specific to their environments and may be able to report them to us. Briefly, a few odds and ends about the container Linux runtime. We support AMD64. We added ARM64. Later, we never quite got there. We actually just recently removed it within the last month or so. It should be surprised to no one who's ever even looked at this that bolting on a second architecture after the fact is a bad idea. We push pretty hard on the idea that you should run software in containers on CL. You can copy binaries to the host system and run them. There's nothing preventing you from doing so. But we really don't think you should. There's no package manager. There are no conveniences for this. Run software in containers. Okay. Well, it turns out that... Sorry. Sorry. Okay. Well, it turns out that there are some things like demons associated to particular storage cards or whatever that you might want to run in the host. And of course, people are interested in out-of-tree kernel modules, which they need for various reasons. We don't have a great answer for that right now. People ask on IRC about out-of-tree kernel modules, and my co-worker David sends them a gist. Docker turned out to be a problem. Initially the model was that we were going to ship the latest version of Docker and everyone was going to be happy. And for folks using Docker Engine standalone or for using Docker Swarm or whatever, that was fine. The problem is that Kubernetes is not qualified against any version of Docker which is still under support. And so we had a choice to make. And if we went either direction in terms of picking a version, someone was going to be unhappy. So the net result is we had to provide a way in this OS that's just supposed to work and you don't have to think about it, we had to provide a way to let you choose a version of Docker. The result was Torx, which was just enough package manager to get the job done. It doesn't do dependencies. It installs essentially every boot into a TempFS. It works well enough, but no one was really happy with that compromise, I think. We try to keep interpreters out of the operating system. This will become important later when we talk about Fedora Core OS. We have Bash and AUK. We don't have Python. We don't have Perl. It keeps the image small. It keeps the attack surface small. You probably shouldn't be running a lot of fancy code in the host anyway. However, then we have to do things like re-implement CloudNet. Finally, platform agents, we have them in the OEM partition. They can't be updated. Sometimes we have to ship Python in the OEM partition that can't be updated. The code that we're running there is of perhaps uneven quality and perhaps uneven usefulness. That's been an ongoing issue for us. At this point, Dusty is going to talk about Atomic Host. We'll see if I manage to stay away from the speaker interference. I'm here to talk a little bit about some of the Atomic Host design goals, the structure, what went well, what didn't. Let's dig right in. First of all, I want to take a detour from design goals and talk a little bit about the update model. Basically, there's three steps with Atomic Host. You download the update in the background, you stage a new deployment for re-boot, and then you boot into the upgraded deployment. One, two, three, pretty easy, right? I'll talk about the design goals, and we'll keep that update model in mind the whole time. Essentially, what we wanted to do with Atomic Host was create reliable, fault-tolerant updates. We didn't want people to be scared of updates. We wanted to create offline updates, and I'll get into what that is here in just a minute. We wanted to focus on security. How do we do this? A way that we can do this is basically shrink the base of the operating system. If you ship less, you are responsible for less, and you're less likely to have security issues with the software they deliver. If we're shrinking the base, how do we still deliver something that is useful to the users and the admins who are administering these systems? At the time, Atomic Host was created in 2014. Container technology was starting to come on, so the answer leveraged containers. Then we needed to essentially develop an image-based update system that was different than the model that we had been using in the past with Yammer DNF. We need to revisit our design goals. First, we had reliable updates, offline updates in security, but now with that last slide, in consideration of the first three, we add good container host. That is something that we want to do as well. Okay, so the reliable updates. If you consider the update model I mentioned earlier, one, download updates, two, stage new deployment, three, reboot. In this model, there are two deployments, so you essentially have your pre-upgraded deployment and your upgraded deployment. This means that if your new upgrade doesn't work for any reason, you can easily roll back to the old one. If it makes it all the way to user space and it doesn't work, you can run RPMOS tree rollback and do a reboot and you'll be back into the old one. If for some reason it doesn't make it to user space, say there was a kernel or an NRD issue or something just early on, you can actually boot into the pre-upgrade deployment and choose to keep that one forever as well. So a little bit of fault tolerance here for people who are risk-averse and want to be able to go back if something goes wrong. This encourages people to not necessarily fear upgrades as much. The offline updates, which I said I clarified earlier, again, we download updates in the background, we stage a new deployment, and then we reboot. So this means that no software ever runs in a half-upgraded state. You know, getting back to the first design goal reliable updates, if you download and essentially perform an update, like on a YUM or DNF system, what you end up with is, you know, if you happen to have a failure in between somewhere, maybe DNF has a stack trace or RPM has a stack trace or somehow you get in a half-upgrade state, you lose power or anything like that, your system might be in a state that you can't recover out of. And in this case, for offline updates, software that is currently running on the system, say you didn't stop your services or whatnot, can still be running old software after the update has completed. So if you don't do a reboot after you run a DNF upgrade, you then check your packages to see what software is vulnerable. Well, guess what? It's all updated, but there might be some stuff in memory that's not. So this model allows us to have fully offline updates. You can actually leave your hosts online serving content, you know, performing their service on the update.  The third design goal was security. So basically, smaller base, less risk there. The image-based update system also allows for users to verify what they have on their system, matches what was built on the server. So like you can basically cryptographically verify, and it's also signed. We also mount file systems read-only, so if somebody does get on your system, hopefully they're not able to actually modify the content of Mary's. And then leveraging SE Linux, you know, means that if they do happen to get on the system, hopefully they are confined and not able to touch things. And then the last one, good container hosts. So we basically provide container run times for users to use so that they can run their applications, because if you can't run your applications, pretty much useless. So we provide container run times and basically manage host updates ourselves. So you are essentially trusting another team to do your updates for you, or at least deliver you something that is reliable from an updates perspective.  And the separation of concerns here, basically, atomic host team manages the host updates and the admins manage the application updates. Kind of helps the reliability. Okay, the structure of atomic host. I mentioned the image-based update system. So basically we created RPM OS tree. It actually existed before atomic host, but this was quite a good use of it. And RPM OS tree is really good at content tracking. It's a hybrid approach. It's not a disk image-based system, so it doesn't work at the block device level. It works right above the file system level, and it's smart content tracking. It knows about RPMs. It knows about bootloaders. It's able to manage all of that for you. So when it does an update, it basically gets the new content. It will update the bootloader, and then once you reboot, you are into your OS. The nice thing about this content tracking system is it is like Git for your operating system. Five years ago, if somebody would have told me, it's like Git for your operating system, I would have been like, yes, that's exactly what I want. I love the conceptual model. OS tree repo, or OS tree server side repo is like a Git repo. It is a remote to your client. It has branches that you can follow. It has checkouts. It has rebasing, so that's really nice. And the other thing is it shares common contents between different deployments. So for example, if there's a new update, and only one RPM change, and only 10 files change in the RPM, you're only downloading those 10 files when you do an update. So basically on the local system, you're only storing those 10 files in addition to what you already had on the system. So that's nice. The disk layout structure that we have is pretty generic, basically. You know, it gives the user or the admin a lot of flexibility. So we can have partition base. We can have LVM base. We can have ButterFS base systems. I think that works. I haven't tried it lately. And this is configured during install. So like if you were to run a bare metal install, you could configure this. Obviously, if you download a pre-baked image, you will get a partition setup that is predefined for you. And our mount points. User is read-only. Var is read-write. There's some other ones. For example, top-level directories like Slash Home and Slash Mount are redirected to Var Home and Var Mount and sim links are in place there. And the state in Slash Etsy is tracked and restored on rollback. This basically makes rollbacks more reliable because updated configuration files for new software might not have worked with the old software that existed on the system. Bootstrapping. Basically, you heard Benjamin talk earlier about how they're using shell scripts to installs. We, for bare metal, use an installer ISO, which has Anaconda in it, which is similar to what you might experience with the Fedora CentOS-based system today. And for cloud, we use Canonical Cloud in it, which is baked into the OS tree so you provide your user data for that. And it spins up the system. Obviously, there are problems with that that Benjamin mentioned earlier because it runs during boot rather than kind of before the system has switched into the new root. Hostic sensibility. So, you heard Benjamin talk about torques. Our answer to that was two-fold. One was package layering. So, basically, what you can do is take an RPM and mutate the immutable post, so you can add that RPM as a layer on top of what you already have, what was delivered to you by the atomic host team. So, that's one option. The other option is running system containers via Atomic CLI. What is a system container? It's basically like an OCI image, just how you would have built one using Docker build or Podman build. But Atomic CLI helps you grab that, set up a system to unit, so it'll run on every boot, and then also, you know, it works for making them super privileged, so that, you know, it can do the low-level things it needs to do to the host. Is this a good idea? I don't know. Probably not. It's too undefined what all those things can do, unfortunately. And it makes it harder to update reliably. So, what worked well? I think using the Fedora slash RPM ecosystem has worked really well for the Atomic host project, because essentially, we get to reuse all the hard work that's done in Fedora and also contribute back. So, if there's a bug in the kernel in Atomic host, it's the same bug that's in the kernel in Fedora. So, if we find a bug, we get it fixed. It helps everybody. If somebody else finds a bug in Fedora workstation or whatnot, and gets it fixed, it helps us. So, that's really nice. Packaged layering has worked really nice. Obviously, containerizing low-level system tools is hard. And this, that helps us get around these issues, you know, somebody has to really want to containerize a low-level system application in order to do it right. And we haven't hit a lot of cases where people are jumping in the water and ready to do that. And the get for your OS conceptual model is really nice for new people who want to understand what OS tree does and what RPM OS tree does. So, the other thing that's really good is representing system state in a clear way. So, this is an example of running a status on a system. And you can clearly see there's a version here that people can use to talk to other people, talk to us when they report bugs and say, hey, I'm having this bug. Is anybody else seeing this? I'm on version XYZ. And I tell them, no. I'm on version ABC and I'm not seeing it. Can you try ABC or I'll either rebase my system to XYZ and see if I see the problem. It represents any mutations to the system. So, layered packages. I've listed out there. I've got a few layered packages on that system. So, it clearly lists. Here's what a user has done to the system. Maybe you can replicate the state. So, what didn't work well? I sent this email to AtomicDevel. I forget. I think it was like eight months ago or so. There were four big issues that were kind of plaguing our ecosystem. I mean, people would just hit these periodically. And one of them is lost content in Etsy problem. So, I mentioned earlier, Etsy is tracked. The way it works is a user will run RPMO history upgrade. And then, as part of that, a new deployment is created and a new Etsy is made as part of that. It basically takes the current Etsy on the system and the Etsy from the new commit and merges them together and creates a new Etsy for the new deployment. The problem is, if you run RPMO history upgrade and then wait three days to reboot, if you made any changes to Etsy on the running system before you reboot, those will be lost because the Etsy merge was done at the time you ran RPMO history upgrade. That's now fixed. We started doing the Etsy merge right as you do the reboot rather than before. So, that's been fixed. Another problem can't package later some RPMs. If RPMs write two directories that are read-write on the system. So, for example, user local is read-write because people put stuff there. Slash op is read-write because people put stuff there. RPMO history does not allow somebody to install an RPM that puts contents there because we don't want to control directories that read-write. We want to control ones that are read-only essentially. And then third party kernel modules. Benjamin mentioned this. DKMS, AK mods don't work. This has been a problem for a while. We haven't really got a good solution to it. His just answer is probably about as good as we got to. We did have a user that actually created like a subsystem for doing this for WireGuard. But that's about as far as we've gotten. The bad the update philosophy, obviously our update philosophy from beginning was more of a you update it on your timeframe type of scenario rather than the automated update policy that Benjamin mentioned. I think it would have been better to go the other way because obviously people aren't as proactive about their updates. So this essentially makes upgrades less reliable because if you're upgrading from something a year old that's a lot more likely to have issues than if you're upgrading from n-1 to n which is probably something that we tested. And package layering also makes upgrades less reliable because we can test the base upgrade to another base upgrade and we can even test base upgrades with layered packages, but we probably didn't test your set of layered packages with our upgrades. It's just a combination we have a big matrix there if we start adding a lot of layered packages. I'll hand it back over to Benjamin because do you want this? Alright, so first of all what are we trying to build? I mentioned before that we're essentially trying to take the best of container linux and atomic host. This is the language we have now I won't read it out. It looks a lot like the container linux usage model as it exists now. It's for running containers in production. Minimal system monolithic image we have some use cases defined I haven't there's some stuff down below that I haven't included on the slide but essentially the primary use cases are either a single server essentially node for running docker or podman or a clustered node for a kubernetes or okd and then secondarily cluster nodes for running other container orchestrators. So platforms we're targeting the same cloud we see and so on that container linux targets. The install process we're currently thinking will be something like CoreOS install probably not the same shell script but essentially download a monolithic image and write to disk. Provision will be by ignition the partition layout is still up in the air a little bit the straightforward thing to do would be a single partition for both user data and operating system code but it seems like it'd be nice to separate those out first so that you could format the user data partition using ignition and first boot and also just to keep a little bit more isolation in terms of disk space usage and so on. Automatic updates we are throwing away all of the container linux update code server protocol client on the client side there will be RPMOS tree installing primarily RPMOS from Fedora we will have rate limited rollouts the same way we do on container linux that code does not exist yet there is some work going into a network wire protocol for that and we'll have to write new server code because we're supplying automatic updates the same model applies we cannot break users any backward compatibility breaks in the OS will need to be announced with a deprecation window far in advance and we're going to work on the automatic rollback story as well that there will be user provided health checks and hopefully more comprehensive automatic reboot. Update streams this will probably not be the container linux alpha beta stable model but we want to do something a little bit like that so there will be a stable stream and there will be at least one pre-stable stream and there will be some details still TBD the reason that's important is that the testing model will be similar as well there will be CI but it will also be important that users run some nodes on the pre-stable stream in order to catch any regressions metrics turn out to be important the metrics that we have on container linux are better than nothing they have gaps and without those it's been really difficult to figure out how to spend our time is some corner case actually worth spending a bunch of development effort on are we prioritizing the correct platforms so having some sort of metric gathering is useful there will of course be privacy knobs so that you can turn that off if you really don't want to give us that information but hopefully we'll be able to do this in a way so that we can get metrics independently of whether you're obtaining updates container infrastructure the docker problem has not gone away there's still a need to be able to run either the docker or the one that Kubernetes requires we'll be shipping podman and at the moment it looks as though we will not be shipping rocket rocket is not the direction that the container ecosystem has gone and we think it's a good time to start from now in addition, farther up the stack we're currently looking at shipping Kublet and Cryo in the OS image so that's one less thing that you have to provide separately but the problem is that both those pieces of software care about the version of Kubernetes running in your cluster and so in that case we're going to have the same sort of issue as with docker we need to figure out a way to give you the version of those components that you need at any given time how to do that is still an open question but probably it'll have something to do with package overlays because that mechanism exists and it works well they're also useful for debugging so container Linux is a little bit weak in this area if you need debugging tools that aren't on the machine you have to bring them in, there are a couple of different ways to do that so we want package overlays around but we're probably going to try discouraging them being used any more widely than necessary the exact nuance there has yet to be worked out but as Dusty said overuse of package overlays complicates the update story a couple quick things ARM64 support, I mentioned before bolting it on much later is a bad idea we will try to ship it right off the bat we may need to cut it for the initial release if time becomes a factor Contrary wise Python, we will try not to ship it but we may need to include it if time becomes a factor Cloud Agents the OEM partition has to go we're not doing that again so for starters we're going to ship all of the Cloud Agents inside the base image effectively and then conditionally enable them based on what Cloud you're running on the install images will be slightly different because each image needs to know what Cloud it's running on but probably that will just be a few bytes and otherwise the images will be identical in the long run the idea is not to ship all of the Agents inside the OS but rather to not ship the Agents where we can get away with that in other cases there's just a little bit of callback code or whatever needs to be implemented to tell the Cloud that the node is healthy we can implement that ourselves and not ship it for the code so there are a couple other things that a couple other things that are still up in the air that we know will need more thought I mentioned the cluster coordination issue before we were container Linux with locksmith wants to just reboot nodes out from under the cluster that's not okay and it would be nice to have some sort of unified model where code on the OS node interfaces with the cluster in order to coordinate and then of course third-party kernel modules that's still up in the air as well alright I think we have just a few minutes left if people have questions yeah so the comment is some problems that we have where people want to use either atomic host or the future fedora core OS for things that aren't necessarily primary use cases that we're targeting it would be nice if we made it really easy for people to create their own atomic host or core OS system so that they could deliver their own and have a little more control over it a goal is that people are able to use the build tools and create their own systems that they can update so that would be really nice for updates well offline updates or third-party update servers so that's how it will work as well so I'll do the first part so comment from SUSE basically they're doing something similar in the cubic project and they do recommend having a separate var from root as part of that and then the question was have we looked at the Kubernetes reboot daemon for coordination I tend personally to work further down the stack and there have been a variety of reboot coordination things in the Kubernetes context that have been attempted I have not looked at that particular piece of software Luca are you aware right so the comment was that several of them require running in Kubernetes cluster I think from the OS perspective the interesting piece is finding a way to provide some some hook or library something on the host that those things can interact with how do you do static IP network configuration without an installer it's relevant for bare metal and on bare metal hopefully you think about this I was about to say you control the DHCP server but that's not the answer you wanted you can when you're installing the system either from pixie or from an ISO image or whatever you can modify the kernel command line in the grub config and on container linux at least we support ip equals where you can pass stuff in for the net ramifas for the real root file system ignition can write down a network dconfig so it depends on exactly which piece you need to get working with there's a couple ways to do it do we have in the contract with container linux customers or folks like that that they need to run alpha and beta the need to run alpha and beta has been sort of an ongoing issue because it's something we talk about in talks and things but we don't actually document it very well and so we have users showing up reporting stable regressions and that's the first time they learned they probably should have been running a little alpha and beta the messaging there has been uneven any other questions so the question is what happens if there's a merge conflict in slash etsy directory um that's probably a better question for Colin Walters or Jonathan Laban because they know the technology better than I do but I have not hit that problem um I think what they basically do today and it probably could be smarter but I think what they do today is if there is a file in the current etsy that's on the system that has been modified then that overrides essentially what comes in in the new deployment or as part of the new update so if it's been modified it stays if it's the same basically if it hasn't changed if you as the user has not touched it it will pull in the one from the new deployment and use the new one so I think that's what happens in rpms today but the rpms will basically drop down a .rpm new file so you can essentially inspect the old one and the new one and I think that's what it does in Atomic Coast Josh the question was why are we in Fedora CoreOS switching to automatic updates which is the container Linux model rather than the Atomic Coast model the answer I guess comes down to we hope you want updates bug fixes security fixes the nodes should be essentially an appliance that you don't have to think about because you're thinking about the things running in containers on top of it and so if it becomes another thing to manage then we're not achieving our goal right and to second that basically the idea here is that and I know I'm going to ding for using this analogy but I feel like people know it really well pets versus cattle right we essentially want to support more the you know the spin up a node throw it away model rather than the spin up a node let me customize it exactly how I want it let me do create a snowflake and in the cattle model essentially automatic updates should be something that's welcomed because if for example something doesn't go right you can throw that note away and bring it back up I also feel like it has reached it's definitely resonated with a larger user base because there are more people using CoreOS container Linux than either Relatomic Coast or Fedora Atomic Coast today so obviously that spoke to someone and we listen to that so I think it's the right way to go in the future. Save that again. The question is how do we plan on dealing with RPM dependencies in Fedora CoreOS? How do we trim it down to make it smaller? So pretty much right now we need to see what tools would be removed from the host if we remove Python and which of those tools are ones that we absolutely can't do without and then either try to work with those teams to somehow remove the Python dependency because some of the things that we've looked at are essentially packages that have one Python script in them that could probably be rewritten and then some of them are packages that are completely Python so we'll just have to deal with those one by one and see if we can do this or not. Right. I guess a way to do that is either convince people to rewrite it or try to get them to put it in a sub-package. The other option is when we create the OS tree we can theoretically remove particular things from the OS tree before we do the commit so that's an option too. It's not as clean but real quick, let me try again on your static IP question. If you're running Chorus install from whatever medium it can inject an ignition config and the ignition config can have a network D unit in it. Real quick, are we done at 3.20? Yes. Anyway, we might be out of time. Thanks everybody for coming. I appreciate it.


Welcome to Toffees TV, it is the Eiverton News Daily. Big news today that Russian billionaire Alesyr Usmanov has said that he would consider investing in Everton. Is it the way it's kept secret in football? Probably. Usmanov Party and former business partner Farad Meshiri, of course... Everton's major shareholder. And I thought that is close. Pal Osmunoff mwy arrive on me, as he said, on his yacht full of billions of pounds in silver briefcases. That's certainly how Everton Twitter reported it today, or dreamt about it today, but it'd be a massive thing for Everton if Osmunoff did come on board in terms of the stadium. You know, just that extra, those extra billions that tend to matter in football gives you that extra freedom, of course, stadium wise backing. It also gives you that extra freedom in terms of players, contracts and everything else and being able to afford, you know, better sponsorships and stuff like that that even attract. So it's going to be interesting to see, he's obviously already an investor in Everton in terms of one of his companies sponsoring Finch Farm. So it's just going to be interesting. I mean, I think personally he will end up with it, but they'll have to watch this space. I know one Everton fan who will be absolutely delighted at this news today. Moving on, Keir Tumar and Bernard have joined in full training of Finch Farm today, both pictured on the Everton Twitter feed, joining their teammate for training. There was no sign of Yeri Mina yet. He arrived yesterday, is still undergoing some medical tests and some light training for him. It's thought he's going to join in training, full training tomorrow, but we'll have to wait and see whether that actually pans out. But it's good to have the lads here and ready to go. Obviously, we saw Andre Gomez yesterday arriving at Finch Farm and he's still three weeks away with his hamstring injury, but all the players here now and a chance for Marco Silva to work with all of them and get his ideas across as we move towards the Southampton game of the weekend is going to be very, very interesting. Everton, not appealing, filled Jack Yelch's red card either that broke last night. What's the point? We heard all kinds of officials and punded saying that it was a red, even though it wasn't. And we also heard Joe saying that it was a red, so there you go. It definitely was. Yannig Balasi, as a game being linked with a move away from Gooderson Park, Aston Villa thought to be stepping up their interest in Everton Winger. He's not being involved at all. He hasn't played a game in pre-season. He's done training, but he's not being involved. He wasn't involved in the matter of the squad at the weekend, and it's thought that his future lies away from Gooderson Park. It'd be a big coup for Aston Villa to be able to get him. Middlesbray, also keen on him as well, but obviously you have to look at Wade's and stuff like that. Maybe Villa would fit in better with it being closer to London than what Middlesbray is. I don't know, but they are clearly interested in taking him to Villa Park. And also a story today about Bernard. He reportedly turned down a return to his first club, Athletic Omenero in Brazil. It said he had big offers from the Chinese Super League to go there, and a couple of European sides as well showed big interest in him, but he wanted to join Marco Silva at Everton. So, listen, I can't wait to get me first blimpsers of them in an Everton match getting them involved. He's a fantastic little player, and let's hope he settles alongside all the other players. If you haven't subscribed, please do so immediately. It takes a second, and if you want more videos, get over to Peyton. Loads coming over to Peyton. Loads seeing the longer content that we've got over there. Lots of stuff happening this season. Make sure you don't miss out. Thanks for watching. See you later on Toffy TV.


Welcome back to Captain's Lounge Studios. I'm joined today by two opposite sides of the music industry, one on the recording side and one on the actual writing and playing of the music. So welcome to Rational Recordings and Rational Music, all mixed in together. Sitting at the table with me today is Joey Blunk and Brett Batterman. Gentlemen, thank you so much for coming in. Good to be here. Thanks for having us. So let's start off with you first, Joey, because we heard so much from him in our first interview that, oh, my goodness. Anyway, how did you get started in music? Oh, I mean, I started playing trumpet in fifth grade and I almost quit before the end of fifth grade. And then sixth grade, I started jazz band. And then from there, I just kind of, you know, jazz was like the main thing for me.  Yeah.  And to find someone of your age group into jazz is a little bit unusual. Well, and you know, it was, I think, my middle school band director, Lisa Keener is her name. I owe a lot to all of my band directors, but did a really good job of kind of, quote, unquote, a gateway drug into music of like, you know, the song that got me hooked was we played 25 or 6 to 4 by Chicago. Oh, OK. You know, and that's like, yeah, we really fold jazz at that point, but like, you get there and then maybe we do a little bit out of Count Basie, maybe we do some Art Blakey, and it's like, OK, now I'm sold. That was kind of my door into. And that was your door into music. Yeah. But you now have to make the very next step. You're also a songwriter, correct? Yeah, I started writing when I was in high school and probably for a better and not worse, I can't find recordings of a lot of those things that I wrote in high school. And I think that's probably best that it stays that way. But yeah, I've been writing since high school, and it's so interesting. I don't know if, Brad, if you and I have ever talked about it, but I think one of the really interesting things as a songwriter and as a composer is you have all these influences that, you know, really shape the sound that you have in your head of what you're going for. And I just think the more that you write and the more that you work, the closer you get to that concept you have in your head of like, no, this is what I'm hearing and now I can actualize it. And now I can make it a reality. So, and that's been one thing that's been so exciting about the album for me. Right, right. We will discuss the album a little bit later, but you sort of mentioned, you know, knowing, Brad, how did you guys get to meet? I was finishing my master's degree at CU Boulder. And for the master's, part of the master's degree I had a recital that I had to do and going into that, I learned about the Longmont has the winter walk about music festival and I threw our name in the ring and we ended up getting picked to play and so we're at the show and getting ready to play and Brett is the one taking care of sound. And so we were talking before the show and then we ended up playing and then after everything was finished, you know, we just talked about how much you enjoyed the music and then everything kind of went from there. I mean, that's like at least the start of it.  Yes. Okay, so you turn up to do a gig, got the band and everything and you know you're gonna be using a sound engineer that you have never met before. Doesn't that ever worry you? Because the sound engineer is gonna make you or break you. Yeah, I would say it actually worries me more now having had like positive experiences because I mean, I've played so many shows where it's just been like, it's probably gonna be bad. You know, like going into it, it's just, it's probably gonna be bad. But now that like we had an actual like good experience and can see what can be, now it's like, well, hopefully it won't be bad. You know, I mean, we played a show last year down in Denver where there was a three band lineup and we were the last to soundtrack and we only got a line check. And it was with all the equipment and the electronics we have and everything, it's just, it ended up going okay. But yeah, now I'm more nervous about it, if anything. Right, right. Aren't you allowed to take along your own engineer? You know, I mean, I'm sure if we end up getting gigs that are of that nature, I don't know if we're at that caliber yet to be Frank. Well, you played some pretty big gigs. I mean, with this group, we've done some of the bigger venues in Denver, I would say. I think we still have a long way to go to where I would like for things to be. You know, I think long term, what I'm really hoping for us to do is to start getting into some of the bigger theaters, even just as an opening act for bands coming through.  Well, many opening bands have gone on to make it rather big. I can remember Jimi Hendrix being an opening band to where it clapped and yeah, that's not gonna happen again. I'm sorry. Just amazing, just amazing. So, you've now got a concept. Now, let's talk about the band itself. Now, the music that you do is what? Jazz fusion, progressive rock fusion. Yeah, yeah. I would say it's a little of each. I mean, maybe it's self-serving that I don't think it fits into either category. I think many listeners would probably say like, oh, it's this one or it's this one, you know, but I think it has elements of it. It has a little bit of elements in everything. Yeah, yeah. And that's perfectly acceptable. Yeah. When I was a DJ up in Fort Collins, I used to do a radio show every Saturday night for five years. I always, all my music was European and it was either blues rock fusion, jazz rock fusion, progressive rock, all European. So I was able to play a whole ton of stuff that had never been heard in America. And I got some fascinating phone calls. Fascinating phone calls.  So, let's talk about the LP, okay? Where did the concept from the LP come? Where did the concept come from?  We should get this recorded at some point. And I think the really funny thing is the way that the band was when Brett and I met and the way the band is, it's like different bands, honestly. We started during COVID, right? So COVID hits, there's no shows. My roommates at the time, Rhiannon Dewey and Michael D'Angelo who were saxophone and drums in the band respectively, we started just doing like live stream shows from our basement, just the three of us. We would just play some, you know, jazz stuff. We'd stream it online. As we're doing that, you know, it was fun to play with each other. And then there was one night where, I think Rhiannon and I were chatting and we were just talking about like, man, like, you know, I don't, I like playing jazz.  Music that's been played since the 1950s. Right, I want to create something new and we're just like, why aren't we doing that? It's like, because we haven't done it. So it's like, let's do the thing. So that was kind of the motivator to start getting the groundwork laid for this, you know, and start getting it moving. Actually funny, one of the songs off the album, Katana, the first time it was ever played was the three of us in our basement. Oh, okay. You know, and it's definitely a different version. Yeah. Yes. So anyways, we get the band form, we start rehearsing and we get a show book. We played a little show at a place called The Muse in Lafayette, there's a great venue. They declared church and Pete to fantastic work there. So we did that show and then, you know, we started looking at doing other shows and getting things booked. And we must have had probably three or four shows in a row where either someone at the venue or someone in the band got COVID. And so we had to cancel the show and we just kept having to cancel these shows. And it was a real bummer. You're not kidding. Yeah. And so last, like, what was it? Probably like, it might have been before last January. It was, it was maybe towards the end of 2021, it would have been then that I, Brett and I were chatting. It's like, if we're not playing shows, let's just record the album now. So we started getting everything in place and then we ended up doing it in March last year. I don't remember the exact thing. It was in May. Oh, was it May, okay. One, it was exactly what you said. A few people had gotten COVID. And then of course, you know, six weeks later, we've got a date booked and then someone else gets COVID. Or then, you know, yeah. And so with six people, the scheduling is tough. That was where you planned it wrong. You should have all got COVID at the same time. So you should have had a group COVID meeting. The old chicken pox thing. That's it. Next album. Okay. So the LP is gonna be recorded. I always call them LPs. Sure, sure. Sorry. I'm old school. If it ain't on vinyl, it ain't music. Yeah. Tell us about the makeup of the band. So it's a six piece band. And so we've got, I think it's probably, I'll just say that, you know, so I play trumpet and I actually do, I do trumpet. And then I also have an effects pedal that I use with my trumpet. So I can use distortion and all this stuff. And then on saxophone as Rian and Dewey on guitar, we have Andres Orko on piano and a ton of synthesizers was Jeff Jenkins. And then on bass, we had Nate Marsh and then drums was Michael D'Angelo. Poor old drummer. Always left to the end. There is a malicious rumor that the reason that rock bands use fog machines is for the simple reason it hides the drummer. Okay. So you're all decided you're gonna, because of what's happened with COVID and all the rest of it, now where did the, it's a fascinating name. Where did the name of the LP come from? Oh yeah, so the, well, you know, it's like we were saying before the show too that we really like pulled a black Sabbath because the band name is Bigfoot Meter. The album name is Bigfoot Meter. There's a track on the album called Bigfoot Meter. But so I was, I'm really big into camping, really big into hiking. And I had driven out to Glenwood Springs and I was just camping out there and I was hiking on a trail and I can't remember the exact name of the trail. I know I've driven by it since then and I actually drove by with my girlfriend. I was like, there it is. That's where it came from. And because hiking up or getting up to the start of the trail, there's a couple of houses along the way. And one of the houses has like a bulletin board post outside talking about how Bigfoot is in the area. And they have a Bigfoot Meter of how likely you are to see Bigfoot that day. And it goes all the way from 1% up to 3%. Am I? That's a massive groan in here. I hope this is the LP cover. No, no, it's not. Honestly, it's a pretty, it's no offense to the person who has that in their front yard. It's a little rugged looking the way that they designed it. It's not really. Sounds perfect. Anyway. Okay, so that's, that's where you got the name from. You just saw this and it just stuck. I was like, it's a good band name. Yeah. That is amazing. That is amazing.  I was playing the track black Sabbath. Yeah. I always got a kick out of doing that. How long did it take you to actually record the LP? Like the, like, like, are you talking of, like, get there that day and then finish it? Well, no, I mean, you probably did it over a number of days, I'd imagine. It was one day. Oh, one day. How many tracks? Six. Six tracks. Two or three takes of each. Yeah. That is going some. Yeah. I think the intention going into it was to really make it a very authentic and real representation of the music. You know, I don't know. I didn't want it to be going in and like, oh, we didn't really like how this one part, huh, this is a little out of tune. Let's go to, you know, and like, let's make it like a, because I don't know why you wouldn't want it to be like a live show. It's like real. Yeah. Yeah. And there's imperfections, but I think it's more authentic that way. I like it, because when we were talking in the other show that we did, you know, basically what Brett was telling me was you can record in the morning. You can edit in the afternoon and you can publish at night. Yeah. All of the hits were made like that, generally. Yeah. Until you start scaling up production, but... Right, right, right. I should imagine though that once you got through the first song, everyone was in the groove. There were definitely ebbs and flows. That was a horrible pun, by the way, but that's all. There were ebbs and flows, for sure. I mean, because there's... I do not mean this as like a bragging thing, but it's challenging music. You know, it's very... Yes. There's a lot of intricacies to it, so there were definitely moments where I was like, ah, there was one take of one of the tunes where within like the first 30 seconds to a minute or so, I was like, let's just, let's do that again. Yeah. Don't worry, I've done openings for this show just like that. I think now would be a really, really good time to actually listen to one of the tracks from the LP. This particular track is called Broken Promises. Where did that come from? I wrote it in... I think it would have been early. No, it would have been late 2019 was when I started writing it. And it's actually, it's about how when Ruth Bader Ginsburg died on the Supreme Court and then Amy Coney Barrett was nominated and this was after the whole, all of the stuff with Merrick Garland that happened in 2015 at the end of Obama's presidency and then basically the hypocrisy of Mitch McConnell. Right. So, and I don't, without even getting too political, I think regardless of what side you are on the political aisle, I think we can all agree that is not the way that our government should be functioning of the inconsistency. You will get no arguments from me at all and we have it on tape that I think America should go to a parliamentary system. We won't get into that today. So let's have a listen, this is track number five. The LP is called Bigfoot Meter and this is Broken Promises. So I can hear the, definitely hear the jazz in there and all of a sudden you've got a nice little piece of progressive rock drifting in and out. But when you said intricate, that was really intricate. I credit where credits do. I think a lot of that is coming from Mike on drums, Michael D'Angelo. I genuinely think that, I mean, undoubtedly, Michael is one of the best drummers I've ever played with. He might be the best drummer I've ever played with. Like Michael is just unmatched on drums and like you're saying, the intricacy in the every single subdivision is so intentional and so expertly placed. So I mean, yeah, not to say nothing of everyone else in the band, but Mike is just on another level. Please correct me if I'm wrong, but in jazz, really the drums do drive the beat. Whereas in rock, it's typically the bass that will drive the beat. And I would even say, in jazz, it should, in a good rhythm section, it should be a cooperative effort. I have many friends who are drummers where they'll talk about, and I don't think this is unique to jazz, but be at a jam session and getting ready to play and they might be getting ready to go up to a song and see like, oh, that guy's playing bass. I'm not playing on this one. Or vice versa, you know, just that kind of thing. Cause it's, yeah, it's just different feelings there. Do you use multi-track recording or do you sort of like try and record individually? We did the whole thing. So you do it as a band? Yes, oh yeah. I can't imagine trying to piece over cause the interaction is just so important. Right.  Oh yes. Especially with this style of music. Cause I know many, many bands and you've probably seen this. Many, many bands, that's not how they do it. Yeah. They'll lay down a bass line, they'll lay down a drum line, then they'll think about putting in some keyboard piano and then right at the end, they'll put in the lead guitar and vocals. I think I got the order right. Well, it really depends on what the recording is gonna be. Oh true. Yeah, I mean, I just listened to an interview with Billy Corrigan of the Smashing Pumpkins and he talks about, you know, getting the core of the band done, but then they have all of these beautiful string arrangements that have to be laid down afterwards. How, like on Melancholy and the Infinite Sadness, they didn't really track to a click, so trying to have an arrangement conducted and performed by a small orchestra is very difficult. Yeah, it really depends on the way you want to do it. I think for our recording, we had talked about making sure that we didn't have any extra hurdles for the performers to encounter, and then also allowing the performances to speak for themselves, the relationships in the musical relationships to speak for themselves, and allowing everybody to shine. And another point that I think I should bring up is that I was on Joey about rehearsal for months.  And he's like, well, we don't really rehearse. We don't really, you know, but everybody's really good and I'm sure we're gonna do great. And that left me with a little bit of anxiety. But then, of course, when they showed up on the day of they were all ready to perform. And I think that the record speaks to that largely because there really isn't a stall in the whole record. Like, it's nonstop energy from start to finish. Nice, yeah. And you've only ever had to do maximum of two takes? Yeah, yeah. That's incredible. I think there's one little thing that got fixed on, I don't even remember what it was. Yeah, very, very small. Yeah, for the most part, I usually say no funny business. There's no overdubs, no auto-tuning, no rhythmically, you know, putting it on the grid, none of that time alignment. Yeah, but it's just them. It's just the music as it's intended. We talked about Stavros, whom I know, and the way that he puts his music together, he has musicians from all over America, all recording individually and then all coming to a central point in Denver. And then they go in and put on the vocals. And I'm going, how does that work? That must be horrible. It happens a lot these days. Even orchestra recordings, they have music, they have software that operate over the internet where the producer can be in one city and the orchestra can be in the other and that there is no time gap. Like they can hear what's being recorded, they can give feedback, oh, at this bar, the cellos are too loud or whatever. And yeah, that's all across the web now. So you can do anything now. You don't have to be in the same room. I mean, it's good for evolutionary purposes, but I think the sky's the limit now when it comes to collaborations across the web. Right. So for collaboration reasons, it's great, but I still can't imagine not having everyone there in the studio and doing it together. I can't imagine not doing that. Well, especially the music that is for Joey's music. Yeah, it's basically an artwork. It's not, it's a non-starter, yeah. It's just, well, and it would probably fall flat, you know? Can you imagine trying to put together that big game from six different locations, be a nightmare. Well, yeah, it'd be like he's trying to film us all individually with this conversation.  What amazed me was everyone's absolutely precise timing on it. Oh, yeah. Yeah. Because there were instruments cutting in and out, and it was... Well, they can all see each other in the studio. Yeah, so that helps. Brand did a great job of having this set up, so the visual is just so important. Mm-hmm, yep. And then I think another important thing to bring up is that the only acoustic instruments used were the drums, the sax and the trumpet. Having the bass, the guitar, and the keyboards be all direct and electric was, not only is it crucial to the sound, but I think it was crucial to the success of the session because we didn't have a lot of bleed issues, you know, with screeching guitar amps or loud bass amps or keyboards that are cutting through or anything like that, so. So you couldn't really hear the feedback? Oh, I didn't really have... No. And it didn't worry anybody? No. Well, there wasn't any feedback. Yeah, it was all through the head, we were all in the head. Yeah, it was all, everyone's on phone, getting feedback directly from you. Uh-huh, yep. And then just get that comfortable so everybody can hear each other. That's a great way of doing it. Yeah, yeah, it was fantastic.  I still can't believe that you did the whole thing in a day. Yeah. I mean, to me, that is truly... It was. Yeah, no, but if it was 24 hours, I'd still be amazed. Well, and you have to remember too that Joey and I had been collaborating for two years, you know, on the phone. He's been working with the band and I've been brainstorming and, you know, getting all of my ducks in a row for the moment of, for Super Bowl. That's essentially what we were preparing for, is like, we're gonna have one moment to get this right. And if we screw it up, it'll be all on us. Or all the laurels and glory will be up for us too. So. Is this available yet? Yeah, oh yeah, it's on Bandcamp. It's streaming basically everywhere. Thankfully, the name is pretty unique, so it's not too hard to find. If you search Bigfoot Meter, there aren't a lot of other things that come up. Except a city photograph of a guy that's signed in his garden. That looks a bit tacky. Actually, well, since you mentioned it with the cover, using that as the cover too, we should talk, because Brett really, I mean, well, I should really quick say too that like, I know I've said it to you before, but like, Brett and I've had several people where have just been champions of this music and this project because there have been several moments where there's just so much work and it's like, I just can't do this anymore. You know, it's just too much of an undertaking and I don't have the capacity to do it, but I mean, there would, I think there were prior periods where we would go a month or two without talking and then I get a call from Brett and it would be like, so when are we recording this? When's this happening? So it just, I mean, as I know, we've said, Brett is just giving me that extra push to really make it happen. But I was gonna, the cover of the LP is, you should talk about that. So I was on a backpacking trip in the Wind River Range in Wyoming and just taking photos, you know, as you do when you're out there on vacation. And I came across this, in the Wind River Range, there's lots of contrast in snow depth. So you get these interesting formations with trees and roots and things. And I snapped a pic of essentially what looked like a veil and these strange eyes coming through the picture. And especially once I sent it to Joey with being a Pantone, you know, similar to many jazz albums, you just make it one color. And after a while it really, we just really both was like, yeah, this looks good. This is exactly what we wanted. So it was really serendipity to find that picture.  And it's like, no, no, that was just shooting from the hip while I was out in the trail. You know something? They won't believe you. Well, they don't have to. Yeah, yeah, I like the mystique too, you know. Yeah, it's like, well, and it's, sometimes, you know, you can believe that there's fate or guiding hands to things, but, you know, if you are aware and sensitive enough, you'll make the right choice and bring the right image or sound or whatever you're looking for. You just have to believe. Right. How many tracks are on the LP? Six. Six. Yeah. Okay. Yeah. And what's the average length? Probably about eight minutes, I would say. They're pretty long. You've done a lot of gigs here in Colorado. What was the worst one you've ever done? Ooh, I assumed I have to count gigs that I actually played. It would help. Because I have had several where I've, like, I know we talked about those ones that got canceled from COVID, but I've had several where I've showed up to the gig and they're like, oh, we're not doing music tonight.  And that was the worst one with that was it was actually, like, it was a background music gig, too. So we're just sitting in the corner playing, you know, just wall decoration. You know, that's all. I would probably say one of those, you know, where it's background music. You're not, don't get too creative on your solos. You know, don't do anything too adventurous. Don't play too loud. You know, just nice audio wallpaper for people to enjoy. Those are not, I don't do those anymore, which is I'm very grateful for though. I can understand that being very frustrated. Yeah, yeah. But no, actually I am excited because we have, we have another show coming up with the band with Bigfoot Meter, which I'm thrilled about that we've managed to get it. We're playing at Larimer Lounge on Saturday, March 4th. We have tickets on sale now. They're on Larimer's website. And it's doors are 4 p.m. The show starts at 5 p.m. It's us and then there are two other bands. Going on first, it's Alex Street. He has an electronic project that he's doing. And then second is a band called Same Cloth. That's like a very neo soul kind of thing. And then we're kind of closing the thing out. So you can get tickets for that now. And then, sorry, I was just gonna say if people are interested in learning more about us, the best way to find us is probably through Instagram. We're just Bigfoot Meter on Instagram. We have a Facebook page and I also have my own website, which is just joeyblunk.com and there's stuff about it there too. But those are probably the best ways to... Have you ever played down at the Speak Easy on third and main? No, but you know what? I've tried to and I never get notes back. I've sent notes about getting shows there and they never get back to me. Sarah, the owner, is an incredible business woman. She really is. And in fact, today we're celebrating down there the 10th anniversary of the Speak Easy.  But she is hopeless, hopeless. And I'm saying this and Sarah, I hope you're listening. You are hopeless at writing back. And she knows it and she admits it. We love you, Sarah. I will be seeing her later on today. I will make sure that I drop your name. I'll give you a card. Give me a card that I can give to her because she is always looking for good music. Great. Always. Give me two cards. Great. Thank you. It's been a joy talking to you both about music. I love music as you probably guessed. And it's fascinating to find people on your side of the music table. Can I sing? I have sung in musicals and all the rest of it, but I'm not a musician. You guys are musicians. And I consider you a musician as well because you are very much so. That's how I approach it too. Once again, thank you very much. Thank you very much. Ladies and gentlemen, thank you so much for tuning in to this show. I'm Nigel Aves, your host signing off. Goodbye from the Captain's Lounge Studio.


Brian, where do you stand right now with Greg Byrd? I would say, you know, in terms of depth charts, you got to have him behind a loop of weight going into spring training. I mean, obviously, frustrating year for him, therefore, for us. Obviously, it's a player's game and this player has had multiple surgeries now on the ankle. And I think the second one obviously took its toll on him. And maybe, you know, the operating surgeon has said, you know, a few times at A, sometimes the stuff takes a lot longer to settle in, even though he's clean and healthy and he's cleared the return to play mode. It doesn't mean that you're going to get the same player in the first year back. And so now, for the back on that, would be the reason why we didn't see the real bird, although he was healthy. And so, you know, he maybe was a full rehab type season and he never got his full balance back. And, you know, but at the end of the day, because of all the things he's got an option, he'll come in and compete with the void at first base. He may be able to overtake him. The ceiling is still there. We still believe that, I mean, because we've seen it, we know what the talent level is. He's always been a great talented player. The injury history has been a problem. And when healthy, we know he can be productive, but it appears that, you know, the health thing took him down a whole other level last year. And so with that said, and he'll, that's a great thing about our game. You'll have a chance to get reverse and come in and compete again. And hopefully the narrative will be different next year for him and therefore for us, but, you know, we're very thankful of the acquisition Luke Boyd because he was an impact player for us. And so thankfully that happened. And because of it, you know, we had a little bit more security there than if we hadn't done that.