o move to Jira. One, I'm not super familiar with it anyway. I don't feel particularly fond about it. But also there's a lot of people in the Fedora community who would be very hard pressed to accept a proprietary solution. That said, as far as anyone has told me, Bugzilla will continue to exist indefinitely. I don't always find out about things ahead of time.  Bugzilla is really awesome in a lot of ways. It's also very painful in a lot of ways. If we were starting Fedora Linux today, I do not think I would pick it. But we have 36 plus releases of history in there. And so just being able to go through and do some of this historical analysis of release by release is really helpful. There will be some discussion in the Fedora community about potentially moving at some point, but it's more of a what is it that we're looking for? And if Bugzilla meets what we need, then I think we'll stay there. So if I can summarize this correctly, I think the question is basically, why are there not more open source bug trackers that can be easily customized to fit the exact needs? Is that a fair character, is it okay? So I think one, bug trackers just aren't an interesting thing for most people to work on. You know, a lot of open source is people trying to scratch their own itch. And yes, everyone has a bug tracker, but nobody wants to use the bug. Like fundamentally, nobody really wants to use the bug tracker. Like we understand that it's a necessary thing, but I have not talked to anyone who's really excited about it. And then there's also just, like you mentioned, Arch is a very flexible and customizable distro. That's also why it's not necessarily the best for newcomers, right? Because with the flexibility and customization comes a lot of complexity. So there are a lot of open source bug trackers out there. There are a lot of proprietary ones. I think there's just a general trend towards using things like GitHub or GitLab, where you have both your code repository and your issue tracking all in one place, which simplifies a lot of things. And especially for small projects just getting started, being able to use software as a service is really big benefit to them. Just from the being able to get started on the thing they actually want to work on standpoint. There are obviously reasons that a community might choose to not use proprietary or open core software as a service. Sure. And just to summarize the question for the recording, or the comment, it was basically that a lot of open source projects like GNOME have moved to GitLab in recent years and been able to migrate their historical data. And I know GNOME is very happy with their move to GitLab. And I've heard the same from other communities. Any other questions or more of a comment than a questions? So the comment is GNOME saw an increase in contributors after moving to GitLab. And I think that's one thing that's really powerful. I don't know how much of that is because it's GitLab versus Bugzilla or whatever other systems they were using. But using a tool, and I think that's why GitHub in particular has become sort of the default place for a lot of projects is that there are a lot of people who already have accounts there and they're already familiar with using it. And so the barrier to new contributors is pretty low. And that's something in Fedora that we've tried to work with people on is lowering that initial barrier of contribution because as a 20 year old distribution we have a lot of historical things that aren't necessarily the way we would design it today but are very difficult to switch away from. And so new people have to get used to a lot of different tools or different workflows that they might not be useful to or used to. And so having that additional complexity and unfamiliarity does make it harder to get new contributors started. All right, Sherry, go ahead. Thank you. One of the things to point out to when you're constructing statuses for bug statuses GNOME is an interesting project because it really interfaces with the enthusiastic Linux crowd which can have very strong and sometimes toxic opinions. And so when we get, because there's always a difference of opinion between what the community does and what the project does. And a lot of times, I had actually worked on this because the bug statuses is important because they actually trigger people. So in Bugzilla, we have something called won't fix. And if you just imagine what that means, won't fix, screw you, you know, it's really what it, so a lot of times we have to change things into it. So instead of won't fix, out of scope, right? So that's something really important is you don't put things when you close them that trigger people and create emotional responses because they go back and then because of the addition of social media, they will use that to hammer their project on a regular basis because they're looking to, you know, punish the project for one reason or another. So that's a, it's one of those really crazy things that we had to deal with is people who get obsessed with their contributions not being accepted because they think it's so important to them. So that's another bit. And one last comment, emojis. So in GitLab, when we move to emojis, it's used for racist comments. So instead of racist comments, they put an emoji of a monkey or they do plus things to say, look, 500 plus is on this bug report. It must be important. And it's like it's out of scope. So those are other things to think about it, especially when it comes from a racial or equity kind of thing is it can be used to punish maintainers and other commenters. Thank you. All right, we have time for one or two more questions or comments or completely unrelated asides. I'll entertain whatever, it's fine. So maybe this one is also kind of opinionated question, but like if closing bugs is controversial and the counting bugs also is almost meaningless cause they mean different things. So why can't we leave them open? Like why is there a need to close a bug that's actually not addressed? The user is still unhappy, leave it open forever and you can manage expectations by saying if someone wants to work on this, Patch is welcome. Yeah, what do you think about it? So that's certainly a viable approach. I do think that at a certain stage like you know you're not gonna fix it and I think sometimes it's easier to rip the proverbial band-aid off and just say, this isn't gonna get fixed. Stop holding out hope that it's going to. It also does make bug analysis a little easier. One thing I didn't mention in the slides is that I really don't do any analysis on the Fedora bugs until after release has reached end of life because at that point everything is definitively closed and we can say sort of this is an unchanging set. And that said, if your bug tracker is useful to your community or if you have some way to like hide or deprioritize ones that you really don't expect to get fixed, it's not always time-based. Like you might, the bug that came in yesterday, we're probably not gonna fix that. Let's move it sort of down the pile. If you have a way to indicate that, that could be a valid thing for keeping bugs open longer-term or indefinitely. Another corollary question is like, how do you handle bugs that are present in upstream and you think it's responsibility of upstream to fix? So bugzilla, like the Fedora bugzilla doesn't have a good way to link bugs to other bug trackers? Bugzilla, Red Hat Bugzilla does now have the ability to link to some upstream bug trackers that it specifically knows about. The approach I would like to see is that that bug gets referred to, you know, sent upstream whether it's the maintainer opening a bug on behalf of the user or the user going and directly doing it. This is sort of my dream world that everyone would have sort of a concierge to do that. And then being able to track that until upstream closes it and we pull that new release in. In practice, a lot of people will just market closed upstream and, you know, say, you know, go to the upstream tracker for it. I don't know that there's necessarily, neither way is particularly the right way. You know, there's arguments to be made in both cases, but yeah, a lot of bugs that are filed against Fedora Linux are entirely upstream bugs. Like, you know, there are things that the maintainer might fix, but a lot of times, like I maintain a few software packages. I'm not a developer. I probably can't fix most of the bugs that would be reported against them. The best I could do is refer them to the upstream project. When it's fixed upstream, you can close the bug after you create a package with that fix. So that's when it's up to you. So you have to create a package, new release of the package with the fix, and then you said, it's fixed in this package, but you don't close if it's fixed upstream, you shouldn't close it. You should close it when you created a new package with that fix.  And it has happened to me that I'm triaging and I've seen that bug and I said, that bug is not going to get fixed. So just close it and say something nice because you can get trashed. We had one hand up in the back of the room and I think we're at times. I know there's a half hour between sessions, but I do want to be respectful of everyone's time here. Hopefully quick. I'm curious if Fedora has a processor. Do you have thoughts on rolling over bugs to new versions as they come out? So the bug comes in on a version and then new versions are getting created maybe before the bugs are getting fixed. So what is the process you guys use for that, especially with regards to the analysis that you do? Okay, yeah, so what we do is we close the bugs when the Fedora Linux release goes end of life. So we don't automatically roll them forward. There's a case to be made for that. I think in a smaller project that might make sense. And a lot of times you do have people after we close it end of life reopen and say, oh, this is still a problem in the latest release or whatever. But at the number of bugs we have, if the individual maintainers don't stay on top of it and move that bug forward to another release, it's just really hard to do that at scale. One thing we do is several weeks before the end of life closure, I run the script and it puts a comment on every bug says, hey, this is gonna be end of life on this date. And so if you're still seeing this on one of the newer releases, please update it and then it won't get closed. In an ideal world, we'd have a lot of people who could go through and like triage and double check all those bugs. I would love to have a team of like a dozen people who just went through Bugzilla all the time and did that stuff. That's really boring and thankless work. And it's hard to get people to do that, unfortunately. Okay, well, thank you, everyone. If you do have more questions, I can talk to you later. I'll hang around for a few minutes and then I will be in the Fedora booth, probably a good portion of tomorrow. And also my Twitter handle is there or you can find my emails, you know, search for Ben Cotton Fedora and it'll show up pretty quickly. So I'd be happy to have more conversations with you later but thank you so much for your attention and enjoy the rest of scale. Can you hear me? Oh yeah. Okay, everyone, this room's not sponsored. Yeah, no, this room's not sponsored. Okay, so good afternoon, everyone. I hope you are having a fantastic time at scale this year. We are back. It's exciting. A lot of faces I've seen before many times and a lot of new ones. So this is a face actually that I get to introduce that we actually love because she's gonna speak on a topic that is great because my daughter is a speaker and my daughter spoke the first time at 11 and she saw her talk the same day she spoke and she was so inspired and she's a conference speaker and she's speaking around the world. So wherever we are, whatever city we're in, we gotta find this lady right here. So I'll leave it to you, Ms. Dawn. Take the floor with the fantastic purple hair. Inside the crowd, give it to the lady again. Thanks so much for the fabulous introduction. I'm a big fan of the Banks family if you hadn't guessed that already. Oh here, thanks. So I am gonna talk about how to become a conference speaker. The slides are already posted on fast wonder blogs. If you go to the speaking page, the slides are already there so you don't have to worry about taking pictures, remembering links, that sort of thing. I will start by telling you just a teeny, tiny bit about me. I have been in the technology industry for well over 20 years working mostly on open source projects from within companies like Intel, Puppet, and now at VMware, I'm responsible for our open source community strategy within the open source program office. I'm also on the steering committee for the Linux Foundations to Do group. I'm a board member of Open UK. I'm a governing board member and maintainer for the Linux Foundations chaos metrics project and I'm co-chair of the CNCF contributor strategy technical advisory group. I also have a PhD that I got by researching how people collaborate within the Linux kernel. Now when I started being publicly visible by giving talks at conferences is when my career actually really started taking off. Now, public speaking is not something that came naturally to me. Early in my career, I was absolutely terrified of speaking up in front of other people, even just like small internal company meetings. But I knew that it would be really hard to be successful if I didn't get over those fears. So I started accepting every internal opportunity to speak or give presentations that I could find in the companies where I worked. I also took advantage of loads of corporate training classes to help me learn more about how to give presentations, speak public speaking, that sort of thing. And then my career really started taking off in 2006, 2007 when I started blogging and speaking at events. I was lucky to have a well-known colleague, Denise Cooper, who recruited me into several of my first panels and lightning talks at events like Oskon, O'Reilly's Oskon. And Alyssa Camahort Page of early blog her fame. She was a regular reader of my blog. At the time, I didn't actually know her, but she invited me to be on a panel about open source at South by Southwest, which was sort of my first like really big speaking opportunity. But this gave me the confidence to start doing my own talks at conferences. And I've done over a hundred talks at a wide variety of conferences. And around the same time, I also started organizing conferences and being on program committees, which gave me a whole new perspective on the talk selection process and why certain talks get accepted and others don't make the cut, which I'll talk more about during the session. We'll start by talking about the benefits and why we're here. The real work starts by actually selecting a topic and a conference, so we'll talk more about that. I'll also talk about writing titles, abstracts, bios, and other supporting information to increase your chances of getting your talk accepted. I'll give you some insights into the talk selection process, along with a few tips for writing and preparing your talk. Then we'll wrap it up with links to a few resources and some final thoughts. And I will have probably about 30 minutes at the end for questions, so keep that in mind. There are a lot of benefits of speaking at conferences that people tend to underestimate. First, most conferences, not all of them, but most of them allow speakers to attend for free. So it's way easier to convince your boss to let you go to that conference if they don't have to pay a huge conference fee. And second, speakers usually get special access to other speakers and maybe some VIPs as well. You get to use the speaker lounge if they have one and maybe even attend some VIP events for speakers, which gives you opportunities to network with other experts. And third, speaking at events will help you become more well known as an expert in your field, which can help you gain credibility at your current job and make it easier to advance your career. And by speaking at conferences, I have been able to travel the world and meet all kinds of really interesting people. And now I can travel the globe and meet up with friends that have met at conferences. And conference speaking has been amazing for my career, but it's also been just a really positive personal experience for me. But speaking at conferences doesn't just benefit us as individuals, it also has a lot of benefits for your employer. Speaking at industry conferences provides visibility for your employer and showcases your expertise and your technologies. In my case, our customers, ecosystem partners, peers, and potential future employees see that VMware has smart and talented people who are respected for their expertise. And there's a lot of visibility that comes from conference talks. In the months and weeks leading up to the event, you'll typically see posts from the event on Twitter, LinkedIn, maybe other social sites to promote sometimes even individual talks. And your company will often promote talks on their social channels to make sure that you're getting some visibility for the talks that your employees are giving. And many talks are also like these recorded and posted online after the event. So that allows you to gain additional visibility for the talks well after you've actually done the event in person. And it's also a great recruiting tool. Potential candidates see us giving presentations and they get excited about the work that we're doing which can make them want to come work with us. So the next time they're looking for a new role, it's great if they remember your talk and think about applying to work at your company. And it's important to remember that you are representing your employer when speaking at conferences. And what you say will reflect positively or negatively on your employer so be professional and kind when interacting with other people at events. Now different companies have different processes for getting approval to speak. And even within a single company, the process can vary depending on lots of things like your business unit, your team, your experience, maybe the topic, the time of the year and lots of other things. So the best place to start is always by talking to your manager. And your manager should be able to help you understand the processes you'll need to follow and your manager will need to provide approval. It is very important to get your manager's approval and feedback before submitting your talk to the conference. It can be super disruptive for conference organizers when someone has a talk accepted that they didn't actually have permission to deliver because then the organizers need to replace a speaker and it tends to reflect really poorly on both the individual and on their employer, the company. So just get approval from your manager to avoid in writing a proposal is indeed to come up with a topic. And this is the first place where imposter syndrome can really get in the way of your success. Coming up with a topic is hard for a lot of people because they feel like they need to be the expert in a technology or know absolutely everything about a topic before submitting a talk. But this just is not the case. You only need to know enough to provide useful content for people who aren't as experienced as you are. At most conferences, the audience probably has more people who are just getting started and are eager to learn. And in particular, attendance at sessions tends to be skewed towards new people. And there are different tracks. You can submit something into a beginner track. And a good way to find a topic is to think about why people come to you and ask for help. Think of the technologies that you love to work with and talk about those.  So think about something you've done, love doing or know a lot about and talk about that. My biggest caution about selecting a topic is that you should be really careful not to propose a topic that's really a product pitch. Most conference organizers will reject any talk that even seems like maybe you're trying to sell something or pitch a vendor's technology. So this could be a really fine line to walk, right? Especially for those of us working in a software vendor like VMware, in my case. If you work for a software vendor and propose a talk related in any way to what your company sells, even if it's an open source project, it's less likely to be accepted and the selection committee will take a more critical look at it. Because conference organizers tend to be very skeptical about talks from vendors. And it's hard to get some of those talks accepted. And keep in mind, there are loads of ways to promote your company and your products at conferences with various types of sponsorships. And sometimes those sponsorships even come with sponsored talks. But even for the sponsored talks, I would encourage you to find a creative way to talk about your technologies that doesn't seem like a product pitch. Now the reality is that pitchy talks are declined for a reason. People don't actually like them. People do like talks that are compelling and interesting. So when selecting a topic, think about how to make your talk unique. The topic itself doesn't necessarily need to be completely unique. But it can help to find ways to make your approach to the topic unique and innovative. And you can do this by bringing your unique perspective to the topic. The topic should be important and relevant for the conference and for their audience. And it should be focused enough that you can tell a compelling story within the time available for your talk. And I'll talk more about some of these areas when we get into the section about writing your abstract. Before we talk about picking a conference for your topic, let's briefly talk about CFPs. The most common way to get your talk into a conference is by submitting a proposal into the CFP for that event. The catch is that most CFPs are only open for a short amount of time, maybe a month or two. And the CFP usually closes many, many months before the conference actually happens. So this actually requires careful planning in advance if you want to speak in an event. In August or September every year, I put together a document listing all the conferences that I want to attend the next year. And once a month, I look at that list and I see which conferences have actually published their CFP deadlines. And the ones with open CFPs or CFP deadlines go into my to-do list so that I don't miss the deadline to submit. And this is really, really important because if you miss the deadline, then you're just not going to be able to speak at that event. It's also important to remember that every CFP is a little bit different. They may require different information. They'll have slightly different word limits for things like abstracts. So you should very carefully read the CFP instructions for proposing a talk to make sure that you follow the requested process and include the required information. Once you have a topic, you need to find the right conference. Spend some time researching conferences and looking at open calls for proposals. You wanna make sure that you submit a talk that's relevant and likely to be accepted at this particular conference. So please, please don't just blast your talk out to any conference with an open call for proposals. Find a couple of conferences that have had similar talks in the past and have an audience that you think would be interested in your topic and then tailor your submission to that event. For each conference, review the titles, abstracts, and bios for talks that they have accepted for previous years. And use those previous talks to get a feel for the types of talks accepted, the length, the amount of detail in the abstract and the types of speakers they've had in the past. And keep this in mind when writing your proposal and then tailor your title abstract and speaker bio to the specific conference. Now, you can also do this the other way around by finding a conference that you want to attend and then picking a topic, which to be fair is actually how I tend to do it. But looking at the CFP for past events is a good way to get ideas for a topic that might be a good fit for a conference that you want to attend anyways. If you're new to conference speaking, local meetups are almost always trying to find talks for upcoming events. And they can be a really nice, friendly place to do your first talk. Having a presentation in front of a smaller audience, especially a local one, where maybe you can get some friends or colleagues to attend and that can help take the pressure off while you get some practice. And these local events are a great place to try out new material before taking it to a bigger event, whether you're a new speaker or an experienced one. And then there are loads of very friendly, more regional open-source events like Seagull in the Pacific Northwest, Texas Linux Fest, Ohio Linux Fest, Scale here in California. Great one. Writing the title in abstract is probably the most important part of preparing your submission.  This is not a place to downplay your topic or be mysterious. You want your topic to shine and you need to be clear about why this is an important topic for this particular event. Your abstract should be clear, descriptive, and detailed. It should give the organizers enough detail to understand what you plan to cover. And since it often becomes part of the conference guide, it should also provide a clear description for potential attendees. Now the abstract should be long enough to describe your talk, but not so long that organizers feel like it's a burden to read it. So keep it as concise as possible. The scope also needs to be realistic. Find out how long the conference sessions are likely to be and make sure that you think about how much you can reasonably cover in that amount of time, while still leaving time for questions. And use the abstract to list or describe the key points that you want to make during your talk, while also being clear about why the talk is important and what people will learn if they attend. Now keep in mind that you don't actually need to write the presentation until your proposal is accepted. In fact, I would discourage you from trying to write the presentation before the talk's accepted. You run the risk of spending time on a topic that for whatever reason just isn't interesting for conference organizers. And sometimes organizers, and I've done this, will respond with special requests to make maybe slight changes to your topic. So you want to have the flexibility to incorporate this type of feedback. Now this doesn't mean that you should be submitting things that you haven't actually done yet. So the text should be there, you should be something that you could reasonably write a presentation about. I actually have a bit of a formula that I use when writing my abstracts. The level of detail varies by topic and conference, but if you look at my past conferences, most of my abstracts look something like this. I always start with a paragraph that tries to draw in the audience and generate some interest by focusing on why the topic is important and relevant for the audience. The goal with this first paragraph is to help attendees understand why they should attend my talk and make sure that the program selection committee knows why my talk is important and relevant for their conference. The next section, usually three to five bullet points with some details about what I plan to include in my talk. This helps attendees and the selection committee understand exactly what I plan to talk about. And I also try to end my abstracts with a summary of what the audience can expect to learn. Now, this is definitely not the only way to write an abstract, but it's worked well for me in the past, so I thought it might help people who are new to writing talk proposals as a way to get started. Titles for talks can be tricky. You want a title that sounds interesting enough to stand out. It also must accurately describe your topic and it should do all of this in maybe three to seven words. Now, I am super guilty of writing really long talk titles. And usually this just makes it hard for me to tell people about my talk because the title just becomes too much of a mouthful and then I can't remember the whole thing and it just gets embarrassing. And from a practical perspective, long titles can be hard to fit on conference programs. Also, try to avoid buzzwords in your talk titles. Those of us that regularly select talks for conferences can get super jaded and tired of the same buzzwords that make every single talk and every title sound exactly the same. And keep in mind that many people will decide to come to your talk based mostly on your title because that's what shows up first on the schedules. And you don't want people to be disappointed if your title doesn't match the content of your presentation. A lot of people don't understand how critical it is that you have a well-written bio to go along with your talk proposal. To be honest, when I'm selecting talks, I actually start with the person's bio before I read the abstract because I wanna know what their relevant experience is. And this is another area where imposter syndrome can get in the way. You should use your bio as a place to brag about yourself and help the organizers and attendees see that you have the expertise to give this talk. This is not a place to be modest or downplay your experience. As I mentioned, your speaker bio is actually a critical part of the acceptance process. And you should customize it for different types of talks or conferences to emphasize your experience in a particular topic or technology. Conference organizers want to know that you have expertise that's relevant to your topic. And your bio is probably your only opportunity to demonstrate why they should select you to speak about a topic. You might wanna cut some less relevant information from your bio to give you a little more room to be specific about the expertise you have in your topic. But like with the abstract, your bio should be short and concise. It's not a dissertation. And also remember that this, again, is not a time for modesty. You will need to brag about your accomplishments and make sure that your bio puts your expertise in the spotlight. And one of the tricks to writing a bio if you don't already have one can be to have a couple of friends or colleagues write it for you or at least the first draft of it because a lot of us have a hard time sort of talking about ourselves and that can really help you get over some of those barriers. So that's a good option if you don't have one. Many CFPs ask for links to supporting materials like presentations, blog posts, videos of previous talks.  If members of the selection committee haven't seen you talk before, this is what they'll use to learn more about whether you have the expertise and the presentation skills to give the talk. If you don't have something ready to share, you can always write a blog post on a related topic and contribute it to one of the many, many blogs who accept guest content like opensource.com is a good one or maybe to one of your company's external blogs. If you need a video, you can prepare a five minute presentation, record it and put it on YouTube. For supporting material, I do recommend maybe focusing on quality over quantity by using your best examples and not necessarily everything you've ever done. Now this is the Here Be Dragons section of the talk to provide a few warnings about what not to do based on my experience being on program selection committees. A lot of people don't want to give away the point of the talk in the abstract or maybe they want some mystery or some big reveal, some surprise. And in my experience, this is a mistake. When I'm selecting talks, I need enough detail to know if it's going to be a fit for my event. And I need to make sure that it's not going to be too similar to some of the other talks that I might accept. And the only way to make these decisions is by having a detailed abstract. And honestly, I've often rejected talks simply because the abstract was just too short or lacking enough details for me to make a decision about the talk. When I see poorly written abstracts or bios that look like maybe they were thrown together at the last minute without any proofreading, I worry that the presentation will be of similar quality. If someone doesn't take the time to proofread their proposal, what will their presentation look like? As I mentioned before, I've presented loads of conferences, but I still try to make sure that someone else reads my proposals before I submit them. I've had great feedback and suggestions from friends and colleagues that have helped me make my submissions and my talks stronger than they would have been if I'd just done them by myself. It's important to remember that your talk is competing with a whole bunch of other talks and proposals are declined for lots of reasons. Yours might have been a great proposal, but maybe they had another very similar proposal that was accepted instead. Or maybe your talk wouldn't have been a great fit for this conference, but would be a great talk for a different event. And I know it's easy to get discouraged when your talks are declined. Some of my talks are declined. Even very popular speakers don't get all of their talks accepted at every event. So this is just part of the process. Now, after you get your talk accepted, you need to start getting your little ducks in a row to present an awesome talk. I know that some people like to write their talks on the plane on the way to the conference. I am not one of those people and it's not something I'd recommend. If I'm preparing a brand new talk that I've never given before, I will usually start working on it at least a month in advance. And I know that sounds like a really long time, but this gives you plenty of time to think about what you want to say. And if you run into a bit of writer's block, you have plenty of time. Just put it aside for a few days and come back to it fresh when you feel like you have more ideas. And I also find that when I'm working on other things, I'll get ideas for what I've forgotten to add to the talk. So starting early gives you loads of time to think about additional material or improvements. By starting early, you have plenty of time to figure out what you want to say and organize your talk. If you use something like my abstract formula, those Kipola points are likely to be the main sections of your talk. In general, most people would recommend organizing your talk by starting to, before starting to create your slides by using an outline of some sort. Now I have to admit that I actually organize my talks using my presentation software, but I don't start right in by creating detailed slides from beginning to end. I create slides with just titles, maybe a couple of notes about what I want to talk about, which I can then rearrange and make sure that I've got some logical groupings and then a good flow for the presentation before I start adding all of the details. I also recommend having plenty of speaker notes, especially when you're taking time and preparing early. It's easy to forget the key points that you wanted to make on your slide, especially when a whole bunch of people are sitting in a room watching you. You don't want to get nervous and forget what you wanted to say. And I find that having speaker notes just makes me a lot less nervous because I know that they're there when I need them. Do not worry about over-rehearsing. I see way more people come into talks who are under-prepared rather than over-prepared. I practice my talks out loud just like I plan to give the talk and I use these as dry runs for the actual presentation. And this helps cut down on the nerves because you know what you're gonna say and how long it's going to take to say it. Now this is why it is really important to practice by actually speaking with your mouth out loud because if you just think the words rather than actually saying them out loud, that will almost always tend to be faster because we think a lot faster than we actually speak. And if you base your timing for the talk on this, you will run out of time when you do the real thing. It can also help to do a practice run with your teammates or maybe some friends to get feedback. And they're likely to be interested in your topic anyways, so this is a win-win for everybody. You can also record your talk and watch the video. It can be super painful to watch yourself present, but I almost always see something I can improve when I do it. It's also important to speak slowly during presentations. Many of us, myself included, tend to talk faster when we're nervous or when we're excited. It's important to remember that we also need to slow down and pause between topics to give the audience a bit of time to process what we're saying. And this will feel uncomfortable at first since pauses will almost always seem longer to you than to your audience. And again, this comes with practice. Practicing your talk, again, out loud while speaking slowly and inserting pauses will help you get used to the slower cadence before you do it in front of an audience. You'll also want to promote your talk both before and after you give it. You can talk about it on your favorite social media sites like LinkedIn and Twitter before the talk to encourage people to attend. And then again, after the talk with links to your slides and maybe video if the recordings were published, you should do the same via your internal channels within your company like Slack or other internal updates. And I also recommend reaching out to your marketing folks within your company because they are almost always happy to find ways to provide even more visibility for your talk. I also keep a list of every public talk I give on my website there, which honestly helps me remember which talks I've given at which conferences. But more importantly, it also gives me a single place that I can use to promote my talks and it becomes kind of a speaking resume. If you don't have a website, you can keep them in a Google Doc or any other format that you can easily share with other people. And as a reminder, you are representing your employer when you speak at a conference. So they probably want you to be as prepared as possible. In addition to the tips I just talked about, you probably have other company resources to help you prepare. There might be training from your PR public relations team to help you answer questions and avoid maybe disclosing things that you shouldn't. There might also be options for training on public speaking, writing presentations and related topics. And finally, as I mentioned earlier, doing a practice presentation in front of your colleagues is a great way to get feedback in a safe space so that you can improve your talk before you present it to a broader audience. And hopefully you work with lots of smart people so don't hesitate to get their feedback and advice. Before I wrap up this talk, I wanna leave you with just a few resources you might find useful. I did write a two-part blog post series that covers most of the topics from this presentation if you want to refresher afterwards or to share with some colleagues or friends. A couple of people who work with me in VMware's open source program office are on the open source summit program committee and they wrote a really great article about how to craft a better talk proposal that's more likely to be accepted. So that's a good resource as well. And I also ran across a really nice article on Dzone about how to become a conference speaker and why you might want to do that. Let me leave you with just a few final thoughts. I talked about imposter syndrome in a few places during this talk. It's easy to default to doubting your abilities and feeling like you don't know enough to give a talk at a conference, but it's just not true. We all have expertise and knowledge that we can share with people who are just getting started. Again, you do not need to be the world's leading expert on a topic to give a presentation about it. You just need to know a few things that can help other people learn. And by bringing your authentic voice and unique perspective to the topic, people will walk away from your talk with new insights that they wouldn't get from another speaker. With that, thank you for coming to my talk and we can't open it up for questions. Questions. I have a microphone for questions. Oh, okay, but there's a recording. There's a recording. I'll repeat your question. Yeah, that's a really good question. The question was if you get a talk that was not accepted, do you usually get feedback or can you ask for that feedback? And the answer to that, like lots of things in life, is it depends a lot on the conference. So a lot of conferences, I don't know of any conference that proactively provides that feedback when they don't accept a talk. A lot of conferences are happy if you ask to provide some feedback from the selection process. Other talks are unlikely or other conferences are unlikely to do that because especially like the big ones, like I don't think KubeCon will do that, but because they get thousands of talks proposed and only accept like 10% of them. So they can't possibly provide feedback on that many of the talks that didn't get accepted. So it depends a lot on the conference itself. I would say one of the best ways to increase your chances of getting it accepted is really to have some people review it who are experienced speakers and preferably people who are on talk selection committees. Because I can tell you that I occasionally, I don't do this as much anymore, but I used to review a lot of the talks people proposed at places like KubeCon from within my company. And some of the original proposals were terrible. Like that's just never gonna get accepted to anything. But you work with them and you're like, this is how you write a talk proposal and you kind of help them get it up in the quality. And we went, when I worked at Pivotal, we went from having like one or two talks at KubeCon to having like a dozen in the year that we had like there were three or four of us who were reviewing all of the talks to try to increase our chances of getting talks accepted. And it helps a lot. The other thing you can do, even if the selection committee doesn't provide feedback, if you happen to know someone who's deeply involved in the project or maybe someone who's on the selection committee, maybe not someone who reviewed your talk, sometimes you can ask them to just, hey, can you have a look at this and tell me what I might have done wrong? And that can help. Yeah, other questions? Yes. Yeah, so the question is, when you were just starting, how did you get over the anxiety and push yourself to do it? The biggest way that I did that was I really took a whole bunch of training courses on how to become a speaker. And then I just accepted anything that anyone would give me and internally within my company. So I did like, I was a sysadmins, I did some training courses for people using some of our UNIX systems. I used to speak at like the New Hire Orientations, which was like a big auditorium of a couple hundred people. And I just sort of made myself do it. And it takes a while to get over that anxiety and you really just get over that by doing it. So the very first talk that I did was a, it was a training class about how to use this new fancy tape backup system that we had with the Robotic Tape Library. This was in the 90s. And so I was giving this presentation about how you can use it. We had this software that made it really easy. And I talked so fast that I was incomprehensible. So yeah, I was excited, I was nervous. My voice was shaking like the whole thing. And you know, afterwards my colleagues were like, Don, people really didn't get that. They were like, you gotta slow down. You can't just keep doing that. So, you know, that's how you learn, right? And so yeah, so I just kept doing it and tried to get over the nerves as much as I could. But you know, when I first did it, I would just be like sick and just, I would just feel terrible. And I just kind of kept making myself do it. It was a question in the back. Yeah, yeah. So the comment was that Toastmasters is a great organization for helping to get over the public speaking hurdles. I'll be honest, like the Toastmasters tend to vary a bit by group. I actually tried to that. And the group that I was in rang a bell every time you said um, which only made me say um more. And I got so frustrated, I finally sat down and I never went back. I was so, I was angry. I was frustrated. It was not the right approach for me. And so like find a really good Toastmasters group. If you find one like the one I was in, don't just walk away forever because I've heard really great things about Toastmasters. So just like find a different group that's actually good. Yeah. Oh, question is did I ever find an instance where the nervousness assisted me? I don't know. I find that nerves does not tend to assist me. So I try to avoid the nerves as much as possible by being as prepared as I possibly can. Yeah, I don't know. I don't think I've run across that myself. That's a good question, though. Other questions. I've got loads of time. Yeah.  That is practice. And sometimes again it can help to record yourself because then you'll see how fast you've talked. And it's something I, you can tell this by like my answering my questions. I tend to naturally speak very fast. And it's something that I have tried really hard to learn over a period of very long time because I work with a lot of colleagues in other countries. In particular when I worked at Intel we had a lot of people in Asia and they really just don't understand me when I speak too fast. Which is true, well frankly, of people in English as their first language probably don't understand me when I speak too fast. So it's something that I've been trying to learn over time is just to slow myself down and pause. But I don't have any like specific tricks that I use to do that. Yeah, so the question was, everyone has a day job and where do I find time to prepare these talks? I'll be honest, that is kind of hard. This is also one of the reasons that I start preparing talks like a month in advance, especially for new talks. Because then I can kind of fit it in between things. And so in between I've got a little time between meetings I can write some speaker notes on that one slide or I can find a picture to go with that thing. And so that really helps because you can kind of break it down and you don't, especially you need some focus time to create the outline and figure out what you're gonna say and kind of the general flow and theme. But what actually takes me more time is finding pictures and writing my speaker notes. And that can be done piecemeal. Once you've got a flow for the presentation and an overall structure, then you can tackle those individual things and you can do it in relatively short periods of time. But it is hard. There are times where I just tell my boss, I've got all these speaking things coming up and I'm not gonna get a lot of other things done.  Other questions? Yeah, so the question was, how do you handle questions and the interruptions that they provide and how do you get back on track and how do you deal with questions that you don't know the answer to? You really need to learn not to be afraid to say I just don't know the answer to that. I say that a lot. I give a lot of talks about various things in open source and people for some reason like to really ask me a lot of compliance questions. And my expertise is on the community side. I don't get involved in licensed compliance because I find it incredibly dull and it doesn't interest me. So when I get questions about that, I'm honest, I'm like, you know, compliance isn't my thing, I really can't answer that. Or if it's something that you really probably should know and just don't have off the top of your head.  And it can be hard to handle those interruptions. So some talks, I'll take questions like throughout the presentation. I used to do that a lot more. Some talks, it's easier just to wait until the end because of the way the presentation's structured because like this one, I talk about bits and pieces of things the whole way through. And so it's easier to do all the questions at the end. But you do really have to learn how to manage the time. I will often cut off questions if people are asking just too many questions about a topic, I'm like, hey, you know, I've got some other things I need to get through here. So I'm gonna put a pause on the questions and then if we have more time at the end, we'll do more questions. But then you do have to sometimes like shorten other things on the fly because you've spent too much time answering questions. And that takes a bit of learning how to do that. And it is disruptive because you've got like speaker notes and you've got the things that you wanna do. And so while you're trying to talk, you're also trying to think, well, you know, which part of this can I just not talk about because I don't have time. And so that's super challenging for sure. It's not just you. Other questions. We still have loads of time. Happy to answer questions. Yeah, in the back. Oh, okay. So the comment in the back was, if you're doing a highly technical question, a month may not be enough time to prep. Yes and no. So a month is plenty of time to prep the actual presentation itself, but you shouldn't probably submit it into a CFP if you don't already have all of the tech. Like all of the knowledge that you need to actually do it and have done all of the things before. So where I've seen this go off the rails is, and I saw this happen to someone not that long ago where they proposed a talk to a conference where they were gonna build all this stuff and there was like Terraform and just like all this stuff. And they hadn't actually done it before and they couldn't pull it off in time for the conference. And so they ended up giving a talk about part of that but they couldn't actually give the whole talk that they had proposed. So yes, highly technical talks can in some cases take more time to prepare, but if you've already done all of the technical things, so I'm giving a talk about the GitHub API at all things open. I'll still probably work on it about a month in advance, but I've got scripts that do all of the things I'm gonna talk about. So I've got things that I can pull from to make it a little bit easier. Other questions? Yeah, so the question was, how do you learn more about the audience to decide if it would be to what the audience is like and how do you determine that? One good way is to actually attend a conference before you speak at it because that gives you a really good way to have some insight into the people who attend. The other place to look is look at the sponsor prospectus because the sponsor prospectus almost always has really detailed information about the audience because the sponsors want that information and those are the people that fund the whole conference. So they're usually very detailed about the audience and the sponsor prospectus. But you can also, you can look at the conference website and maybe get some details there. If the conference has happened recently, you could even look on Twitter and see what people were saying about it or you can go back and see if people wrote some blog posts about the last one and see what they were saying about it and you can probably glean a bit about the audience from that. Other questions? Going once, twice. Okay, thanks everybody for coming to my talk. For everybody who didn't know that's a phone. Yeah. Just, you know. They're like, please, it's not a phone. No, no, it's a phone. For all of you under, you know, Right, right. Yes, where's my mouse? Uh-oh, except I can't get it to, uh-oh. I started now, I can't finish it. I can't get it to stop. Sorry about that. Let's try this again. Okay, good afternoon everyone. Good evening, whatever time it is. Thank you guys for coming. I hope this is getting recorded or something. My name is Patrick Schwartz. I'm a pre-sales engineer for SUSE. I've been there for about four years now. Before that, I was a systems admin, system architect for the bulk of my career. Have taught, you know, Linux certification classes and all the way down to climbing telephone poles with spikes. So I've done a lot of things in my career. Also, a friend of mine helped me, a good friend. His name is Moose, he would have been here but wasn't able to for a variety of reasons. But he helped me with a bulk of this. And he is my guru, a mentee that I've been working with from Ethiopia. And we're gonna talk about some Ethiopia stuff in here tonight, so I thought it was appropriate to have him on the slide deck. So what I wanted to cover tonight, this evening, whatever time it is, is this project called Keywix or KiwiX, however you wanna pronounce it. And what is it? Why do we care? You know, all that. And what we did with it in containerizing it and then how do we did that via Rancher, okay? And then how we containerized KiwiX. And then I had planned for a short demo but I'm having serious networking issues. Because my demo machines was behind my VPN at home and between hotspots and wifi it's just not working. So we'll try. But that's the beauty of slides. I have it all on the slides anyway so we can talk through it. Sound good? And at any time you have questions, don't, you know, feel free to interrupt me. I don't have an hours worth of content and I know I'm sending in the way of game night. So, you know, I get it. But we can answer questions and if I don't repeat the question, remind me to repeat the questions that gets on audio. Sound good? Okay. So what is KiwiX? It's an offline reader so that we can take content like Wikipedia, Khan Academy, TED Talks and bring it all into a isolated server basically. And what I'm gonna talk about is what I've done with this project already. It's already in use around the world and these pockets of places that don't have internet access, okay? That you can't, it's really, really difficult to take books into.  So KiwiX gives me the ability to take all that content with me onto a site and stand up a small box and then anything like a Chrome browser, a cell phone on an isolated network can then access all of that data and just like if it were on the line. And so that's what KiwiX does for us. And so in the why, well, as the slide says, basically half of the world's population don't have access to the internet. I mean, think about this is 2022 and we still don't, you know, half of the world's population don't have access to the internet. And, or if they, you know, or don't have power or enough power, right? And so the lack of infrastructure is a huge piece of this. And then the cost, when I'm on my trips to Ethiopia, you know, sometimes I have to go to the local store and buy whatever's available there. And generally it's 10 to 15 years older technology than what I could buy here today. And generally three times the price of what I would spend for the newer stuff here. So really old technology, very high price. And it's very hard to import things into the country or like, you pick on Ethiopia because I spend a lot of time there. And speaking of, here's an example of, this is a small university, believe it or not, that actually hosts about 3,200 students. Okay, 3,200 students. It's a seminary school and a nursing school. I teach midwifery. And that this isn't the only location, but this is very typical of a, this is one of the newer buildings that they've been standing up. And this classroom down here, as you can see, is the computer lab that I stood up in 2019 using Raspberry Pis. And that was, that's that room right here. Is that one down here? They had administration here, classroom, classrooms, and then another row of classrooms down there. So you can see it's not a high tech.  You know, you see Barclay and UCLA and you think of that kind of infrastructure. This is not atypical for a university setting or a school setting in Ethiopia or the orphanages that I support are very much similar to this. And so they, right behind this tree, there's, you can't see it because of the tree.  So that's the why, you know. So now this university and the orphanage that we support can support the kids can get a full education. You know, Khan Academy classes are huge and not just Khan, but there's a lot of other open source learning environments that we can then take and put into ZIM files. And KiwiX has a ton and there are all kinds of languages that most of which I've never heard of before, right? But I'm able to download it in English or New Air, which is the South Sudanese language or Amharic, which is the Ethiopian primary language.  And so that's the why of KiwiX. It gives us the ability to take, because they don't have internet at this school. They have very limited power. And so with Raspberry Pis and KiwiX, I'm able to then provide them access to education. And so now they're able to continue with their education without having to carry over, you know, literally tons of paper material that would then get, you know, torn up or wet or because it's a very human environment. This continues to just work, okay? That's, and this is an example of the why. And I'm not just talking Ethiopia or remote Africa places. We have places right here in the United States that are just as remote and just as disconnected. Some of the rural South, some of the rural Indian tribes, you know, some of the reservations don't have access. And so we can provide that with the, as I called it, the magic of open source right here in the US. And so here's some of the tools that I was able to use with KiwiX. We have the KiwiX Manage, which creates this XML file, because like when I took to Ethiopia, you know, I had a two terabyte drive and it had several hundred ZIM files. And so by using an XML file, then I wouldn't have to manually list out all 200 of them on the command line. I could just point to a library file instead. KiwiX read gives me the voted read search. And of course KiwiX serve is what I then put on a small little box that can then re-broadcast via Apache or Nginx for to actually serve those ZIM files. I can build, you know, the KiwiLibraries, there's over 3,900 books already in the library. 110 or 1100 in English. You know, so it gives you an idea that there's another 2,000 or more that's in other languages. You can even create your own ZIM files. If you've got copyright permissions for the website that you want to then reshare, you can do that by using the ZIM tools at the two locations that I have on the screen. And it's really, it's very simple.  Any questions so far? Okay. Very good. So, Rancher, we'll talk a little bit about Rancher. This is, because this was a combined idea here that I had, myself and Musse. We wanted to take this standalone application Kiwix as an example, okay, that we use. And how do we go about putting it into containers? And being a Zeus employee and being Rancher's an open source platform, I thought it would be a great segue to talk about Rancher and we're gonna look at that. But what is Rancher? Anybody here not know Rancher? A couple? Okay. So Rancher allows us to manage Kubernetes clusters. It's a complete stack to manage all aspects of your Kubernetes clusters. Whether they're, no matter what CNCF Kubernetes engine you desire to use, one of the clouds, one of ours within a Rancher RKE or RKE2 or K3S or one of the clouds, like I say. Any certified, CNCF certified Kubernetes engine can be ran or used inside of Rancher, managed by Rancher. And so it gives you that ability to do a full DevOps idea of managing your environment through to production, okay? Okay. So how do we go about then bringing this all together? KiwiX and Rancher, how do we pull it all into? How do we go about containerizing this application? Well, initially, when I first started, KiwiX does have a Docker image. It's a Docker hub image. But again, I threw my young friend a challenge. I said, I don't wanna use that one. I don't wanna use that image. Let's make this a little bit more fun. Let's use the SUSE base container image instead to host this application, okay? And so he went out and created this Docker hub using the SUSE BCI to host our KiwiX application to actually compile this KiwiX application using the SUSE base container image. If you have questions about SUSE base container, you can always go to the registry.susa.com and you can read more about SUSE BCI and what it can do for you. But it was kind of that fun little challenge. Do we always have to, and I always try to push the envelope. What can we do with open source, right? Do we just have to take, I mean, I could have just stuck with Kiwi Docker, right? I could have just stuck with it and just ran. But I wanna push the envelope. What else could we do? Well, SUSE BCI was sitting there going, use me. All right, let's try it. Well, and behold, we were able to, wasn't that hard actually, from what he tells me because I didn't do it. So we pushed the envelope, we created this. So he's got his Docker hub directory on hub.docker.com with the SUSE BCI KiwiX serve image, okay? And so again, it was all about an exercise of why not? There was nothing wrong with the official Docker KiwiX image, but let's try to push that envelope. Let's just see what else we can do, right? And so we did it with the SUSE base container. In my lab, for what I was gonna show in the demo, we used the Metal LB load balancer and we needed it back in storage to host all of those two terabytes where the ZIMPOWS that I was using, for example, right? So we needed, so I had some prerequisites that I had built in, we needed a load balancer, we needed some backend storage, okay? But then we went out and created a Helm chart for this application because Rancher gives me the ability, I can point to this repository, this application repository, and say this is where my next app is from. And all my Helm chart data is sitting there. And I'll show you that in just a second. And so I've got this Helm chart now on my GitHub repository. I can add this application, this Helm chart repository to Rancher and say this is where my Helm chart is. And in a couple you'll see, it's actually very simple. Once I do that, then it's just a matter of installing this app, okay? And so the Rancher steps were really, really simple. Add the GitHub Helm repo, create our persistent volumes, which like I said on our prereqs, we used NFS, and then launch the install.  But you needed to be able to tell the command line what that answer was, what file are you using. So he created a simple form inside the Helm chart, then it answers some things like the namespace, where's the storage, and the keywix options, for example. Okay, and so because I've got the screenshots here, I know this is really hard to see, and I've got a couple of screenshots, I was hoping to show this to you in live. Again, and we can try again here in a second, but I wasn't having great success. But I was able then, first steps, create my persistent volume, you can see I created the ZIM files, I told it where my NFS server was, I gave it a name, I'm using the plugin, NFS share inside Rancher, and then down here I created the next step beyond create, step two here was a couple more options that I needed to select, like read only, or read writes, or whatnot. So that was kind of step one, creating my persistent volume. My step two then was creating the repo, and again, I told it I gave it a name, I gave it the URL, there's my PHS for SUSE GitHub, what branch was I using, any authentication that I needed to use. And so I was able to then create my repo, and then simply click on install, and then all of this data here comes out of my Helm chart. Some of it's from the Helm read me, some of it's from the Kiwix read me that we created, and it gives you some examples, and I just get a, there's more to this, I just cut it off for screen sake. But then I just click on the word install up in the right hand corner inside of Rancher, and then it gives me a couple more pages, you can see I've got step one, step two, I tell it what namespace that I'm gonna use, where I'm gonna deploy it, I've got storage and Kiwix configuration. This is that menu that I was telling you that Musse created for me with a template inside Helm chart. And then last but not least, here's my storage data, where's it at, NFS share, where's my Kiwix configuration, so there's my, this is actually a typo, it should be dash dash library, library XML, when I'm passing the command line arguments to Kiwix, Kiwix, and once I do that, it goes off and installs that application in my Kubernetes cluster, and I could have told it, I wanna make sure there's always three instances running since I've got metal LB, that metal LB will be the one IP address I get to go to, to see that interface. And then of course, within Rancher, I can also see a lot of, I can just look right at the values, the YAML file for the values, and see there's my dash dash library and library XML, I'm telling it what namespace, my volume name, pieces about that, where's it going, LeapMac at my house. And so, voila, then boom, here's the end results, I was able to create an IP address for me within my metal LB space, and provided a interface, and I only had like a six books loaded in this particular example, just to keep it small and portable. But I've got some Wiki, I've got some Khan Academy stuff there, which then allowed me to, the audio works, there's audio in any of these, they work, video in any of those, those work. And so, that's what, that's the process of getting, just taking this idea of, you know, this Docker, this standalone image, pulling it into what else can I do with it, pulling it into Docker, or pulling it into Rancher using the SUSE-based container image. And so, that was where I was going. So let's try one more time here, see if I can get the VPN to work. Any questions why I bring this up? Thoughts, suggestions, comments? No? You guys are too easy. Sorry, yes sir. Well then, yes, yes, it is actually, very much so. And again, it goes back to standard, you know, load, depending on how big you make your KiwiX serve machine, or in this case, how much resource do we give it in the container world on our, on our, and I did, by the way, get this, this is working to some degree. Can I make it a little bigger? Oops, I didn't mean to do that. Wrong button. You get this right and left thing going on here. The KiwiX server, it depends on how much, how many ZIM files am I going to share? They, a couple years ago, they had a couple of bugs that didn't let you share more than a couple hundred ZIM files on a Raspberry Pi, but I think they've fixed that now. But again, it's a matter of resources. How many clients are going to hit it?  Yes sir. Exactly, so I work with, you know, I asked the, the, so the question is, who helps curate the product or the, the, what I'm taking there, right? Who's answering the questions of, which ZIM files do I take? Right? And so for me and my project, I asked the, both the orphanage director, I also asked the, the college president what's important to you?  And so I worked with both and each one had specific curated content that they needed. The orphanage obviously needed more elementary, middle school, some high school content, you know, a lot of Khan Academy was really important to that. The university, however, needed more of the typical higher grade content, you know, a lot more TED talk-ish kind of ideas, you know, kind of expand the mind on what is out there, right? And inside of, outside their little world. So you work with where you're going to see what they need. Yes sir. Constantly, right? So yes, that is one. So the question is, you know, how often do I update the content? And to some degree, I mean, yes, everything, as soon as I download it, it's static, right? It's not a live update, you know, it's not like, you know, any updates that are gonna happen that happen tomorrow, you know, for a Khan Academy class, for example, is going to be, it's gonna show up in my ZIM file.  So I don't have to worry about too much, you know, of that. Now, like, let's talk about world history, you know, for example, yes, when I went in 20, and I first set this up in 2019, obviously there's been three years of updates in world history, right? Some very dramatic changes in world history in the last three years. So that's, they're not gonna have that access with what they have today. So I go back about once a year, and when I go back, I take a new SSD with me that has a lot more, you know, maybe newer updated data, newer ZIM files on it. And with that, then I can, you know, just refresh their, what their infrastructure is. So yeah, there's lots of, you know, ways to, and that requires two different infrastructures. Yeah, exactly. So, but that's all a matter of, you know, like the nursing school would need more medical, you know, information versus the theology school would need, you know, their needs are very different, even though it's the same school. So, so there's my rancher node. If you look real closely at the top, it says Leap Mac. It was because this is open source of Leap running on an old iMac. So, yay, open source of Leap. And so it's my master rancher node, but I've got a couple of clusters down here. You know, you can see I've got K3S, RKE2, and for example, the one we were just looking at, from the demos, from the slides, see if this comes up here. Gives me the dashboard, and if I go into service discovery, services I think, is it here? And see, I've got this, oh no, here we go. And right here, if you'll notice, really tiny at the bottom of the screen, I've hovered over that, it shows me the IP address it's going to load balance to. And just for grants, let's just do that. It's gonna open up a new tab, and there's my live keywix server. And this, for example, my friend took the, this Ethiopian English readers website as an example. He created a ZIM file for it. And so I can look through, you know, like I spend a lot of time in Gambela. I can look at their stories, you know, about Gambela.  So, it gives me, you know, so he was able to take this as an example of using, then I can come back up here and hit home, and get back to my main page. You know, there's my Khan Academy, for example. This was the geometry one for Khan Academy. It's a little bigger to, takes a little bit more to read. That's, especially through a VPN.  Okay?  Okay? And so, in, you know, that's what KiwiX does for us. By adding it to the rancher and, you know, learning how to do all this, and to be quite honest, this was kind of a project for me to get deeper into what's possible, right? And some of that, you know, like the base container image, I hadn't played with yet. And so it forced me to present, to learn more about it, right? The same with our rancher writing Helm charts, and speaking of Helm charts, if I can find my mouse again. Oh, I gotta go the wrong way. Okay. So here is my Helm chart. Make it a little bigger here. For this project that we just kind of put together. And, you know, like, again, like a lot of things, it's a learning project, right? This is by no means finished, but there's our steps, there's some examples, the chart info that you're gonna look at, some examples, you know, of course, typical left things we needed to do, you know, to read me for the app, read me for the main top, we've got our questions YAML and our values YAMLs. But this was, you know, just our simple chart data that I would then, you know, add it to Rancher to make it an app that I could deploy via Rancher to my Kubernetes clusters. And so that's, you know, one idea, you know, for the idea of having different spaces because it's a Kubernetes cluster, I could then have, I don't have to have duplicate hardware, you know, I could have different, I could have one NFS share with multiple libraries files and each one is using a different library file with all the ZIM files in the same directory in the same NFS share. And I could, because I can set up, I need three nodes for a minimum, for example, I could update the ZIM file library and then redeploy very quickly via Rancher. So, does that make sense a little bit? I hope it's still waiting, it's still spinning. That's not good. This is what I was afraid of. So that's those pieces. Yeah, yeah. Seems like I can get to my home network, I can't get to other sites. So anyway. And so that's just kind of, you know, an example of what we were able to do, you know, very simple, taking a very simple little project like KiwiX with a real world need, but then seeing what I could do with it by pulling it into Kubernetes and how to create the Helm chart, how to tie it all together, how to then redeploy it, how to write Helm charts using this. I know we've had a couple of sessions that we had a whole track this week on Kubernetes. I hope you guys were able to make some of those. And so, you know, I think one, we had one track today or yesterday, it was talking about writing Helm charts. So I look forward to seeing the recording of that one. So any questions so far too? I'm kind of closing, you know, near the end. So as a repository, sure, sure. Yeah, I don't know. I would imagine so. You know, if it's meant to be let's see where's it at. So we have, you know, out of the box in Rancho, we have, you know, hours that we provide, that we support directly. We have those that are provided to us by partners, you know, that, you know, are known to work. And then we have things like mine, for example, that is, you know, a third party repository that I just added to this repository, added to my repository hubs, so that I could, you know, if I needed to, you know, go to, and add a job, is it under workloads? Forget, I'll add an appointment. And so I would add a name here. I would tell it, you know, what image am I using, you know, that was where I would put in my KiwiX, for example. So, you know, I would imagine so. If it's, you know, a container, a bowl, is that a word? Then, yeah, I would imagine so. Any other questions? Okay, well, I won't belabor the point. You kind of get an idea of what I'm doing with KiwiX and the far regions of the world. Get an idea of what we can do in the Kubernetes world, you know, taking simple apps and then containerizing them, using SUSE-based container image, even, you know, that's even something it wasn't originally designed for, or with, rather, I shouldn't say for. And just continuously pushing that envelope. What can we do, you know? Thinking outside the box, you know, not just taking the defaults. I hate taking the defaults. You know, the next, next, next idea, right? So, I like playing what-ifs. All right, well, thank you all. Again, I appreciate your time. Look forward to game night and get some dinner before then. All right, thanks all.