 but I love to see all the people showing up and people responding in those threads. So if you haven't introduced yourself yet there, even if you've been around Fedora a long time or if you're brand new, join those threads, say hi, you don't need to say anything profound, just a little bit about yourself and use that also to greet new people coming into the project. I think those are a really nice sign of health and just friendliness in the, it's in the, what we call the water cooler section of the forum there. I don't know if that, I'm not sure how well that metaphor translates, but it's basically an old-timey office thing where people used to go into an office together and then you would go stand around the water fountain and chit chat and so on as an excuse really to have some social time. So the water cooler section of the forum is kind of a social area as well. So I also have some other metrics here. I do a lot of charts and graphs as you may have known for previous things, but I have promised Steve Smudgen, Steve Smudgen to always show this disclaimer here. What we're doing, and there's gonna be a little bit about metrics telemetry coming up further, what we're doing is pretty much like trying to dig into ancient dirt and figure out what these bones mean. It's not really direct observation because we don't do deep tracking of what's going on. So the dinosaur here represents uncertainty about this. And in fact, I ended up cutting a lot of the graphs as I dug deeper into this because I found some bugs in the process and I'm working with the DNF team to figure out exactly what's going on. But yeah, I was looking at these numbers. So these are basically released by release numbers here and these should be going up and to the right. You're growing each time and they're not. So that had me a little concerned and that's a pretty big drop there and not quite the rebound I wanted. I was like, okay, are we losing users here? So losing people to all of this chaos and the apocalyptic horsemen, are they taking our people leaving and some people are still saying they're happy but things are going wrong? Maybe, I mean, can't really tell. But I tried to look and this is another view of that which is basically each of the releases at the peak point broken down by which variant is reporting in. So for the last one, that's not at its peak yet. You can see it's still going up. So that bar will grow. But one of the things I noticed looking at is that actually workstation is going down and some of the other ones like server, core OS, cloud are growing here. So I thought, well, that's interesting. What is? And so when I actually look more deeply into it, it turns out that this decrease is in the desktop variants that are using a DNF, not the OS tree ones, just the desktop variants that are using DNF and it's GNOME based, KDE, Cinnamon, XFCE, all of them. So something's weird going on there. I have not figured it out yet. But I went back to the old counting method. So here are the dotted lines. So the new counting method is DNF based. I can go into details, it DNF checking in into things. And the old method basically is we're just counting how many unique IP addresses show every day. And it happens that these correlate at like a two to one factor really well in a way that made me like half people double check several different times. Like maybe we're at like a hex tuple checking by now that this isn't just like a double counting problem. And I'm 95% sure that it is not a double counting problem at this point. But I don't really rely too much on the absolute numbers anyways, more of the patterns to make sure the patterns are right. But anyways, yeah, you can see for those releases, there's a really good correlation. Then, or those drops are, the old method keeps going up like I would hope and expect it to. And you can see that correlation like the first couple of weeks, it's the growth is still there. And then something branches off, something's going wrong. There are, we found a maybe related bug in the way DNF CountMe works. It's supposed to report in how old the system is since it was first installed. Not very granular. It's a first week, first month, first six months older kind of thing. So we didn't really want to find, we didn't want to be able to track people. So we would use these really big buckets. But everything's getting a reset back to the beginning every time someone upgrades, which was not the intent. And it may be something along that way that we're losing the higher numbered ones for some reason. Not sure, DNF team is looking into it and some of the CPE people as well. We'll figure out what that is. And hopefully next time, I'll be able to give some of the graphs and charts that have some more meaning to it. But I don't want to do too much just being optimistic with the numbers I want to see and just throwing away the ones I don't want to. But I feel pretty confident that we're still actually having some growth here. But we'll figure that. And that's the problem with doing dinosaur digging. And we'll see what the latest science says when we go back into the dig next year. Pause for water. So something different. So if you've followed anything I've said in the past 10 years, you've heard me say that mailing lists and IRC and kind of the old way of communicating in Fedora hides our activity. It isn't necessarily bad. And there's actually a lot of good things about these technologies that IRC has a really cool distributed open nature, mailing lists have lots of virtues. I've got opinions, but they make it hard to see what's going on. When people look at the project, it's really hard to notice, okay, we've got real activity here. We don't really look alive. And for a lot of people, especially signing up for a mailing list is incredibly intimidating. And IRC is really hard. So one of the things we're doing is working, you're moving to matrix as a more modern real-time communication. And I've been pushing for discourse, the discussion that Fedora project at org to be our primary asynchronous discussion platform instead of mailing lists. I made a proposal to move the develop list and all the develop conversations to there. And as a first step in that to move the discussion about our change proposals. I thought we will get more engagement there. We will get more people involved, more people seeing what's going on, more feedback. And yeah, so let me bring out another, another ancient curse here. We had, oh, this is just a screenshot here. I think I maybe should have like added some fire or flames to this to make it really exciting. But there was like almost 1400 posts in less than a month. And most of those were like the first week and the first weekend. And a lot of people here always came to this. So, and a lot of people came in pretty upset. So, because we are exposing this to a lot of new people a lot of people who are not used to our process got, came to this discussion. And there are a number of things we could have done wrong, done better to maybe prepare people for how this was gonna go. We could have maybe adjusted the language in the presentation. We could have maybe coached the person who was giving, making this proposal on how to interact more gently with some of the people who had strong objections. Well, things like that. But largely people were coming in and people were assuming that Red Hat had made a back room decision that was already done. This was the announcement of it. Yes. Oh yeah, I'm sorry. Yeah, right. IBM, which honestly, like I would love to blame IBM for everything stupid that Red Hat does, but it turns out companies can be stupid all by themselves. Or smart, whatever. Backroom deals happening, but that's not the way we work. Everything is transparent. And so this was the first time most people in Fedora were seeing this proposal. I had happened to have seen it before, but most people in Fedora leadership didn't really review this or anything. This was the proposal. This is the start of it. People aren't used to that. People are used to having companies make anti-user decisions. And the way you deal with that is you come into their forum and you just light that up. You just, it's not really a matter of what you say. It's how much you say it and how angrily you say it and how much you are persistent with it. And you're hoping that the weight, the volume, just the fury of it is going to change that bad decision. That's not what we were doing. And even through that, even people who didn't come in with quite that mindset were upset that this was even proposed. How can Fedora even think of such a thing? And honestly, that upset me, but in a very different way. Because Fedora, and hopefully, most of the people in this room, I'm preaching to the converted here already that people already have this feeling, but it's important enough I wanna say it. We are a big collaborative project and we try new things. We don't always agree on how we're gonna do it, but we're all working together towards this common goal. That vision, it may not be in your mind a utopian ring space station, it may be something else. But this idea of having a world where we all build software together and share and make the world a better place, like that's what we're trying to do here. And this is a charged topic. People have strong opinions. I have strong opinions. It's really, privacy is really important and user privacy is something we should put at the forefront. But some people really presented it as an all or nothing. Like you have this completely this way or Fedora is Satan. That all or nothing approach is never to bend the Fedora way. Like we have freedom as a core principle in free software and other kinds of freedom or primarily use software freedom. But we also have features and first, which it doesn't cancel that one out but those things are all important together. And most crucially, we're friends who are working together to do all this. So it has to be a safe place to propose things that other people might disagree with. I don't know if you recognize this painting of the school of Athens here. It's kind of famous. And this is how that turned out. So maybe not, maybe not so great. But really unlike in that situation, like if someone makes a proposal that seems annoying or terrible or dangerous, like if it might corrupt the youth, we still need to have the ability to talk about it. And we want to be able to talk about it in the open. And the alternative is we have the same kind of decisions but we put them back in the back room. We put them back in develop list or we use some of the technology discourse has. We could put it in hidden forums and we can make it so you have to be this tall to participate. We can do a lot of those things but I don't want to do that. Like that's this goal of having more people participate and more involvement is good. We want the feedback and we want to be able to adjust and we want to know what people think. So we're going to keep trying this for the next round. We've got some new rules we're going to put into place including no tolerance for personal attacks. I think one of the, one of the, that's generally against the rules in Fedora but one of the mistakes I think we made in moderation was there are people who are coming in and can see if we could, we were afraid of looking like we were doing censorship. And in fact, I moved one post where they were complaining about IBM. I didn't delete it. I moved it to the off topic forum and that person then flamed me for censorship. Can't win. But we made the mistake of saying, okay, people are angry. They've got some point about privacy. Yeah, they said it in a bad way but we're going to leave that there because we want to make sure they don't feel like we're shutting them down. We should have just said, here's the basic rule. You can say your opinion, say your opinion but don't attack people in it. Like that's, and that includes conspiracy theories and suggesting that the person making the proposal is in acting in bad faith that they're not going to do what they say they do. There was a whole lot of this that actually the proposal in specific went out of its way to say we care about privacy. We don't want to collect user data and there was a lot of, if you give them an inch, they'll take a mile kind of response. That was literally one of the responses and that doesn't help because even though that's not directly like calling the person bad names, it is an attack on their character and on the process and we need people can, again, I'm not, hopefully people all in the room are all on the same page here. I'm getting worked up. But for everybody in the world really, we want people to be part of Fedora coming into this. So if you're part of this discussion, if this is not just a user commentary, this is you are part of Fedora and you are helping us make this decision on this change. Like that's you are becoming a contributor by talking in this discussion. And so by doing that, you have to be part of this same thing. You have to want the same goal of we are going to make Fedora better altogether. If that's not what you're aiming for, you really shouldn't be part of the discussion. That's basically table stakes for participating. And so I hope that we can get people who are interested in making things better and get new perspectives and bring more people in through this. So we'll see how it goes next time. I really don't want to have to try and do some of the things where we restrict to people who have been Fedora community members for a year or in a certain number of groups or whatever. We'd like to make it open to everybody, but we'll see how it goes. We're also gonna try some, like we have a video about the process. We're gonna try and make it a lot more, some more explaining. Hopefully it'll go better next time. And no one ends up drinking hemlock at the end. All right, again. All right, so that was grim a little bit, but I think generally overall gonna be good. I mentioned red hat layoffs. Layoffs suck. I won't go into detail, but again, out of my control, what can I say? But I do want to say a lot of people really felt like Fedora got hit hard by this. And I feel like we got hit hard by this. A lot of my friends lost their jobs. That sucked. Fedora, I've talked a lot to leadership at Red Hat and Fedora was not targeted in this. Like there are a lot of other important to Red Hat things that were other, there were other cuts there. And it seems like, again, this isn't an official Red Hat statement or anything, but people who were program managers either their real title or their title underlying in the database underneath your employment stuff, it was program managers. Like that, Marie Norton, her job working on code of conduct stuff was somehow coded as a program manager. So I don't know, bad metadata causes bad problems, maybe. But Fedora has always counted on having a program manager role. Like we wrote it into the council charter it was kind of an assumption that this would be a funded role. And Ben Cotton who was a former program manager has a good explanation of why this really is, needs to be a paid position. Obviously we run a lot of Fedora on volunteers and even though people who work for Red Hat do a lot of volunteering in Fedora in the things that they care about. But there are some things Ben talks about flywheel theory which is making sure that someone is there to carry the momentum. And so when people are volunteering they don't, an essential part of that is you don't have an obligation. Someone who's getting paid to do the role or when a paid role exists even if it's not the same person there is an obligation to do it. So that makes sure that we have a baseline for momentum for some of these important things. You may notice some of these things that program manager used to do not happening in Fedora right now. That's kind of a problem. And no one has stepped up to say oh, I will do that. And that's because nobody has to. So having a funded role here will really help some of these basic things that help keep the program on, the project on track. Fundamentally you can't make volunteers do things so we need somebody that the project can make do things. So Mike McGrath who's in my management chain she went to bat to get a new position created which is very hard in the current climate that is you cannot replace a role that was cut because there's a whole bunch of legal paperworky things and they would be bad. But Mike said what would this job look like if we put it in an engineering role? How could this, what would this be? Because people like Ben were really doing pretty deeply technical stuff. It wasn't just one of the kind of a an observational, is this going red, green or yellow? What's the status this week? Kind of program management is very hands-on knowing what's happening. They're not a coding role but something that is pretty deeply technical. So we are creating a new role. We are tentatively calling it the Fedora Operations Architect for reasons that are naming things as hard but it can't be called program manager. So this role has been created. The REC is open soon and we will hopefully be hiring somebody into this position to work full-time to make sure that we have that flywheel and backstop for a lot of the program activities that we will now not call program activities anymore in the project. So that will be coming up soon and I'm really looking forward to that because yeah, we need that on the team. Also, not coming from Red Hat speaking of paid roles. If anybody else has a way to get a diversity position funded on the council, I've been asking Red Hat for this for 10 years and it's not happening. People who work for, I don't know, some other large companies met at Amazon like it doesn't have to be a Red Hat employee. I would like to have that be a funded role because it's very important and it's one of those other things where volunteers are doing amazing things but I wanna make sure we never lose that momentum and then we have that backstop. Okay, so yeah, the past, the present, the future here, where is future going? Now what? Or where's Fedora going? So our last big strategic plan was called Fedora Next, it was almost a decade ago when this shirt was brand new. So it's time for a new map to have a plan you need to know what you're aiming for. It's difficult to make predictions especially about the future. Anyone who knows where technology is going to be in five years needs to go back and check with Socrates about the possibility of knowing things. You really can't. I think what's happening in technology right now with all the large language models and those things, five years ago, no one would have predicted like, it may be people would have said that AI is gonna be important or whatever but how things are playing out, no one, anybody who predicted that got it by luck. And five years from now, anybody who knows what the big thing is going on is gonna get that by luck as well. So we picked a guiding star for our strategy which is we want to double the number of the door contributors who are active every week. That is not double the number till here, double the number every week. That would be impossible. But it's actually really hard to write this in writing in a way that doesn't have that ambiguity but I can say it out loud. Double the number of contributors who are active every week. Anyways, no matter what technology the future holds, having an active, strong, healthy community, a growing community will be ready for that and we can adjust. So with that in mind, well first we wanted to talk, had to talk about what a contribution is exactly and I'm not gonna go in super detail here but I came up with a working definition. This is on the Fedora discussion forum. If anybody has a different definition that they think is better, you should fight me for it. I think this is pretty good. That's the basic thing. It's pretty broad and this is the framework. I've talked about this before. How do we get from this high level ideal thing, a guiding star principle to something that's actually practical? Again, this is a whole talk to talk about this but basically we start on the right, that right, with the high level things which are outcomes impact on the world you want to happen but that you can't do directly and then on the left side there are actually the more tangible things and it kind of goes from that abstract down to the tangible and back and I find it a very good process and so we're in the process of basically making a very big chart filling these things out. We can go through the themes here but I think better to just highlight them here quickly. These are the basic things we've picked. Again, honestly the specifics aren't as important as having a framework we're working in, a goal and things that we can actually, that seem meaningful and that we can adjust as we need them. But in going through these themes I had hoped to present here is our filled out logic model. Here's the plan at this conference. A lot of those rough things that came up kind of lost momentum in the middle of this and ecosystem connections includes working with CentOS and our downstream distributions, Rocky and all Malinix and everybody else. So given that things suddenly changed in that front in a way that wasn't under our control maybe it's good that we didn't have a big plan worked out there and we were leaving that for figuring out that that's okay. We want to be able to adjust but and there are some other things that came up that maybe we should add that didn't end up getting fitted into these plans at all but we'll talk about that. So yeah, we want to get this restarted but I want to make sure we do it right. I heard recently that anything worth doing is worth doing poorly, which I liked. There is some amount of, we don't want to put it off until everything is perfect. So we do want to move forward but I also want to make sure that it's not something that's dropped down on the community like here's our plan. So there's going to be a lot of work here for the Fedora Council and for everyone else. I had a schedule for this, I'm going to rework this. I think probably you're going to target a presentation around FOSDEM with everything really in a neat package. Hopefully a lot of stuff actually done much before that but that's kind of the next big milestone date. So we'll have a Fedora Council election in the meantime if you would like to work on this, have ideas. And additionally, one of the other ways to participate in the Fedora Council is through Fedora Initiatives, which we used to call objectives and the documentation needs to be updated but maybe we'll make the new person we're hiring do that documentation updating, that'd be awesome. So anyways, we need to work on this as a council and as a project overall. If there are specific areas that you're interested in as you go and look through those things you could, something you could work on or something you could be a leader in we could really use your help as we try and get Fedora into this beautiful, glorious future. We need everybody, provide feedback on it, run for the council, think about where you contribute and I also need to ask the design team to update the sticker sheet with the new logo because it's a nice sticker sheet. Yeah, so hopefully all of that will get us to the glorious future we would like to get to. I think things aren't going really well in Fedora despite all of the interesting times. I think there's also something to be said for having some interests. I would actually not like to live in boring times. I like to have some spice, some challenges. It's good, hopefully not quite as rough as the last year, last few years coming up but I think we are a strong, healthy community and we can deal with it and we can work all together to build this amazing thing. There we go. Does anybody have questions? Yes. We could maybe run them. Yeah, I've got two mics, Justin can do mic running. So looking at the graphs of updates, even the old ones seem to imply that there is a fall happening in the number of systems. You said that you don't know what is the underlying reasons but can you speculate a bit? Sorry, can you repeat? I was busy being distracted about the microphones. Yeah, it sounds not good but maybe if I keep it like this, is it okay? Yeah. So can you speculate a bit on the reasons why the graph of updating systems seems to be going down even in the old method? No, no, no, no, let me go back to the graph. Yeah, so it's hard to tell. One of, there's a lot, especially the IP thing is pretty sensitive to like how network topology is and it also doesn't make any distinction between systems that are just CI systems test runners, whether it's a container that pinged the system once and all that, so we can't really distinguish those very well. So it's really hard to make a guess. I don't know, I guess your question assumes things are going down overall. I don't know, I think the F-36, the metal one there is up higher than the next one but there's room for some variation there. I think one possibility is that around there, this is where REL 9 came out and there could be, this is often a thing where we see a little bit of dip in Fedora usage because a lot of people get frustrated with enterprise Linux distributions because they don't have the updated newest software and so they switch to using Fedora Linux and then suddenly there's a new release of, the enterprise Linux that has new enough stuff and they're like, okay, I'm gonna off-ramp onto this. So I'm gonna see a little bit of a dip at that time so that could explain some of this. But yeah, it's also possible that we were, for a little bit there, the darlings of the Linux enthusiasts, people were really excited about the Fedora, the new Ubuntu was a bunch of YouTube videos and things like that. And now, with the narrative of being red-headed is evil, maybe that does have a little bit of a toll here but I don't know, and maybe not so much just even that negative narrative but just like a bump for people being excited about it and now everybody's onto the next thing that's being recommended on all the YouTube channels this week. I'd like to get us back to being the one that's recommended all the time, that would be nice but that's not always possible. Is that? Okay, so I have a very same, quite same question. Have you ever thought how you can count, for example, local mirrors when it comes to the usage of Fedora? How you can count? Local mirrors. So someone is mirroring the whole distribution and in case of people I work with when there is the big update, they just mirror it, it will go up and then it will go down because there is the mirror and only one, there is a, they do it for example once a week or something like that, so. Right, so our CountMe system here relies on the mirror network, it basically is intrinsic to when you are getting, you're updating your system, you must contact our servers so there's already a network connection there so we're not, there's a tiny little bit of metadata that's part of the CountMe thing which you can turn off but basically we're not collecting additional information in any way there and which is handy but leaves us blind to a lot of things that we could maybe otherwise observe including if someone basically just copies everything to a private mirror and then installs a lot of systems from there. So the answer to that is we have to do something a little more active, something that is a service that reports in despite having the mirror so actually the OS Tree system to actually use something like that, they don't use the, it's not part of the update so they actually have a separate little service that runs and basically does the same kind of check just to say hey I'm here so we could do something like that more widely. I think we'd want to do anything very carefully because it gets into the whole issues of privacy and opt in and opt out and so on but yeah it's hard to know, there could be a lot more systems. I think my general assumption is that people's behavior tends to at least not be quick in those changes so it's unlikely that one release will have like 20% of people suddenly now using mirroring in a different way so the general trends are okay but I don't, yeah that's one of the reasons I don't try and claim that these are absolute numbers in any way. I would love a question not about the metrics but that's not that that's bad, we just got room for other things. So I think that we have seen with the change proposal for opting opt out metrics as well as the change in the CentOS source release that a lot of influence is in a very few people hands and those people then go on websites and comment very actively on their point of view. So if we change the change process in a way that is more transparent which it has its benefits, it also has the risk of those people being even more influential into this. What's your idea or plan to prevent this or manage this? Right, so basically the let's not insult the people. I want to say nice things about us. The enthusiast blogger, YouTuber, podcast, social media people who follow this, there's some amount of I want the hits, I want the drama but generally they are really interested people who want to know what's going on and they're following this because they think it's an exciting development that they're interested in and so one of the things we can do and one of the things I'm going to do I haven't had a chance because of all the flock and all these things coming up but I want to actually spend more time talking directly to those people, going on more podcasts and things and that's actually more people in Fedora can do that as well. Talk to people and tell people, hey this is the process, we're being transparent. This is why you're seeing this, we like the involvement but give us a chance here, don't assume that things are done decisions, this is how it works and whenever I've talked to somebody about this, it's even people who were angry, it's ended up being a very reasonable discussion so I think not all problems can be solved by talking more but maybe this one actually really can. For new contributors, maybe here or watching online, what's one thing that you think they should be taking away or thinking about after flock this year? So I think for new contributors, that thing I said about posting hello on the introductions thread, hopefully that's not too intimidating, there's also the introductions being on the matrix chat which maybe feel a little more transient and we have a Fedora social hour every week, we have a bunch of things like that. The best way to start getting involved is to get more involved just with the people and the community and don't worry so much about what the first thing I'm gonna do is what thing I'm gonna do that's gonna check off that contributor box, figure out what's going on, who we all are, what you find exciting in the project, what's interesting and then as you did, you'll find a lot of things that are like, wow, this could use some help and then at that point, you maybe will feel more comfortable talking to somebody around there like, hey, I see this, how can I make this better and get more involved that way, I think that's, but yeah, welcome to Fedora, new people, I think that's maybe the, Hi, Matthew, my question is regarding strategy and I know that doubling our contributors, did you say what time period that was? It's, no, it's a five year period. Five years, okay. I was actually wondering about the artifacts we produced too and like what the strategy is there because traditionally for a very long time as your charts show, workstation is the most popular download. Do we have specific strategy that we wanna aim for in terms of usage of the other additions and spins and are there things we're looking to or new audiences or new communities that we're looking to adopt Fedora and I of course have my own agenda in asking this question and I have opinions but I'm wondering what yours are and if the answer is we don't really have that yet, I'm wondering what we can do to get that started. Yeah, so actually that theme kind of goes throughout a lot of these, now I've used too many words because they are called these themes. That theme goes throughout these themes. That motif goes throughout these themes, there we go. So in this area here where we're trying to talk about the Fedora additions and spins, there's some things about kind of getting the different desktop spins and the Fedora additions to have a little stronger individual marketing and marketing story every release so we can kind of talk about them better, where they fit and therefore one of the big parts of this is Fedora SIGs and special interest groups. One of the problems is that the only deliverable we've given for say the design team or the picking on ones that have actually done this so that like there's a computational neuroscience group and the artifact is a bootable CD or bootable USB media that you can put on a computer and then you have a selection of software that's tailored towards that. And this was a great idea. I know, Mo, you've actually taught classes on using open source software and design by going into a computer lab, booting up a bunch of systems and that's great but those computer labs barely exist anymore and this isn't really the best way for these groups to spend their time but that's kind of the only thing we offer as a menu of things you could do. It's either that or whatever you want, you could do anything, it's Fedora. So we need to kind of have some ways for those groups to maybe have a set of software that can easily be found and put together in the GNOME software or KDE's, DNF, Dragora, like the GUI things for there, other ways to present sets of software and it's kind of other things that teams can do as artifacts other than here's a dedicated version of the OS for your interest. So that's one of the things. Yeah, one of the technical things that we are pushing for moving more towards OS tree and having those immutable distributions be our primary offerings. So that's kind of more on a technical side but it also kind of goes to where we want things to be in moving forward from the way we put things together in the 90s into a new way of putting together operating systems. I think that's kind of, hopefully we can bring our audience along with that and then one of the other areas here also accessibility, making sure that we have all the affordances in the operating system and our tooling and our websites and docs so that people who have need assistance in vision or hearing or whatever else are able to participate in our project. This is also actually one of the nice things I like about the discourse software. They've put a lot of work into this and it's pretty easy for people who have vision impairments to participate. And so I think that's some of, a lot of our other tools aren't like that. So that's nice. We wanna have more pre-installed systems. We're working with some more vendors, SlimBook and those two to get more Fedora on more systems. I think that'll make it more available to people. And we also have a couple of things about rebuilding our local on the ground communities in different parts of the world in India and Mexico and places where they've been historically been strong but we haven't really been giving the support that I think we used to. And I'm gonna kind of rebuild those and not just those places but are all around the world. The United States for that matter, we don't really have the local on the ground communities that we used to and so building that up is important. But if in all of that, there's more that you're interested in than we haven't covered. Yeah, like bring it to us. Let's, I'm kind of collecting a grab bag of like stuff that didn't fit into these themes but is important. And I don't know how we're gonna end up organizing this. I feel like the current structure is kind of a lot so we might need to consolidate and cut some things down into what's practically achievable but I also wanna make sure we're not missing things that are important. And one thing I'll add on that for the 12 o'clock today in this room, there'll be a session on the Fedora Latam community around the reaching the world part two. Hi, Matthew. I have a question. I have- Where's the voice coming from? This site. Just a little bit. Hi, thanks for the very informative keynote. I have two questions. For the starter, you talked about the discourse and how we moved from IRC and I know there are many changes of we were on Begur and then GitHub and then GitLab and all of that. So I acknowledge that we need to change according to the technology and the benefits but at the same time it gets overwhelming for the contributors to keep changing and switching between these tools and processes. So from the contributor side as well as from the federal leadership side what are the efforts needs to be taken care of so that it will be an easy movement for easy to switch for the contributors and be on the latest platform where everybody is. Yeah, change is painful. I think there's some research that you know change can actually register in your brain and it's physical pain. So yeah, acknowledge that technology is always changing and some of it's out of our control. There are two big things that you mentioned, the Apagar which is our Git Forge that was home built by some amazing Fedora people, Pingu and others. It's been kind of out of maintenance for a long time. There's actually, I think we ended up not having the session because a person couldn't attend. There's actually interest in rebuilding that as a possible future option. I know a lot of people have been experimenting with the GitLab that GitLab is providing to us under their open source program. That has a bunch of limitations as we've been exploring with that. So I think if we end up using GitLab we'll probably end up with a hosted GitLab of our own somehow. So there's gonna be a bunch of moving around there and I think we wanna make that as painless as possible but the change is there. I guess that's something people can help with because documentation can help and just finding where the rough edges are, testing things out and seeing okay, maybe we could somebody help develop some sort of work around for this so that it acts more like I expect that kind of thing. The other big thing that is going to happen at any moment and I wish Red Hat would come out and say this more loudly because they keep being like no, no, don't worry. We use bugzilla.redhat.com for bug tracking. Red Hat internal stuff has all decided to move to JIRA which for so many reasons we do not want to do for Fedora. And so I, yeah. Nice, loudest applause I've ever gotten. That's amazing. Yeah, so we need to find some other solution there and so although Red Hat's not pulling the plug, there's also like only two people who work on this at Red Hat and maybe not even full-time anymore and if those people decide to go and start a turnip farm or whatever else that is more fun than bugzilla, that Red Hat's not going to backfill them with a new bugzilla job and so that is going to slowly fall apart and I would like to not be in the position of Fedora trying to catch bugzilla because it's big and a mess and of the things we want to run, like that's not one of them. So we should figure out what we're gonna need to figure out what our plan is and that's gonna be a lot of change because it's gonna be very different. On the other hand, it does give us an opportunity to do things differently because a lot of the bugzilla like fields and workflow and complexity is there for weird Red Hat reasons that have nothing to do with Fedora so we could maybe have something simpler. We could maybe even have a much simpler bugzilla, I don't know, but probably something better and probably something that we've learned a lot about bugs and users filing bugs and how to deal with things over the last 20 years in Fedora, there used to be a page on our wiki which about when to file a bug and I thought, oh, this'll be interesting when I went and looked at it last year and thought it's gonna give me some interesting wisdom and it basically said, if you see any tiny problem, file a bug immediately and that's actually not great advice because it's gonna leave, most of those bugs may just get untouched, which leaves you feeling like you did a bunch of bug filing going through this weird interface for nothing. It may be something that's already upstream, there may be something else and there are just more bugs than there are people to fix them and more time to track. So having important things tracked is important but filing a bug isn't necessarily the first move. So moving to something where people say, I have this problem, I observed this thing and then that gets possibly filed to bugs I was talking to, I'm sorry, I'm terrible with names which is a big liability in this job but one of the inkscape maintainers and they actually have an inbox where anybody can submit an issue, a problem or whatever and they have a whole separate triage team that isn't developers who go through that and actually make and file bugs that are when they're appropriate or collect things, collect feedback. That's amazing, we tried to do that in Fedora a while ago and it did not work so that same approach isn't quite the Fedora thing but we do have, again, I'm sorry that discourse is my answer to all problems but we have a really active community in Ask Fedora of people who are interested in helping people solve their user problems and their hardware problems and the things they run into and I think that we can sort of steer that into being something that is that first line where if you see a problem, talk about it here and then people who have a little more knowledge and experience and things can identify, okay, here's the bugs and then basically separate this problems and issues from bugs and sorry, this is a thing I'm passionate about and I spent too much time on it are you here to cut me off, Justin? So we have just a few more minutes we'll take one more audience question and then we have one online question and I think it'll be a good way to wrap the session. So I'm Wichita Bogzilla, so my name is Isaac I work at the Risk Vive International Group part of the Linux Foundation I'm a veteran Red Hatterer as well and great to be here in my native city so I'd like to welcome everybody to Cork City the best city on the planet but I do have a question so you kind of mentioned in one of your answers there you're looking to do more factory installs kind of Fedora images and I have an opportunity for you so I think we could do factory installs Fedora on Risk Vive cards like the, you know the little Raspberry Pi equivalents and I know the people that actually doing those cards and I'm sure they would be more interested to we could figure out who we want to go with yeah that would be amazing I said one of the problems we had so Red Hat put a lot of work into getting ARM hardware sort of standardized in the server space like that was John Masters' mission for about 10 years and that worked okay enough I guess but on the small devices, small boards things like basically Raspberry Pi ended up being the only thing you could ever rely on because for every other little board by the time somebody got it actually enabled with standard upstream everything that board was no longer in production so that's great fun if like little tiny single board computers are your hobby but if you wanted to just run something on it there was no choice but Raspberry Pi and Raspberry Pi they have their own OS and they have their own mission and it's fine if Fedora Linux runs on it but it's not really what they're there for and their approach is not really compatible with us so that's always been a big frustration and spent a lot of resources trying to get it to go so this is a long way of saying I hope that risk five can be different and that we can have, so we don't have to have a bunch of like enablement packages and bringing these boards up so if we can have something where out of the box upstream kernel Fedora Linux is just going to run with maybe a little bit of tweaking but not something that's a several month expert level thing to enable if you could help that part happen we can bring the OS that would be amazing. All right and this will be our last question before we transition to our keynote speaker for this morning but this question is coming from online from the person who usually gives us bragging rights of five continents at Flock but could not make it here from Australia so this is from Ryan Lurch if you could summarize what future plan for the Fedora project are you most hopeful for? Wow, no, that was not a good last question that's way too broad. So yeah, I think like I said about predicting the future I think having any one particular plan of it is like you've got to have backups and be able to adjust but I think focusing on community and community health and community growth and using that as our measure and we've got some work in progress to actually bring technical measurements so we can actually have a dashboard with the number that we're trying to make grow. I think that is a focus and some of these ideas like I was saying about bringing new people into the community first and the technology like that follows I think that's exciting and I think that's some innovation in how to do a project I'm not saying we're the first ones to do it but it's a good way to make software it's a good way to do Fedora, I think that's exciting. All right, thank you Matthew for the state of Fedora. I'm not clapping for myself here I'm just clapping for excitement that everybody is here in person in the room it is so great, I'm really happy to be back in person and see all of you and thank you so much for being here. So with that we will invite our next our keynote speaker up to the stage this morning for the talk, what does Red Hat want? This is from Brian Exelbeard so Brian enjoys a good beer, a nice coffee and a rousing conversation about taxation. Born in the US, he now lives with his partner and daughter in Burno in the Czech Republic. His focus is on family, walks on artisanal bread and reading long form articles. By night he tinkers with his thousands of spreadsheets and occasionally works on projects that are often glue code or the interstitial pieces that fill the spaces between systems. By day he is the real business strategist at Red Hat. Welcome Brian Exelbeard to the stage. It's true about the tax conversation at dinner last night it was a very, very passionate, exciting thing about how taxes have done. Yeah, I'm realizing that wherever he got this bio from probably needs a slight update but yeah, let's go taxes. I have no slides, no slides, thank you. I would like you to, please. So I'll try the handheld mic, we'll see how that works. If I need to grip the podium, we'll balance as needed. I guess I should start by saying that there are no slides that is not a mistake. There's a lot of reasons for that. If we have Q and A you can ask why. So it's great to be back at Flock. This is my first Flock actually since 2018, not 2019. 2018 also happens to be the last Flock that I helped plan. I didn't get to 2019 in Budapest because my daughter had just been born. And I like all of you but I really love her and when she was only a few months old I wanted to spend more days with her than with you, nothing personal. If I did have slides, I would spend the next 10 minutes showing you pictures of the most beautiful child you have ever seen. Lucky for all of you, she is here in Ireland at this event and she hopes to come to game night tonight and she invites all of you, she told me this this morning, to come and play unicorn glitter luck with her, which is a cooperative game that my partner tells me is also a metaphor for software development. This is also great to be at a Sintos Connect. My understanding is this is actually the second event to carry that name. You'll notice the theme here. I also missed the previous Sintos Connect that was in Brussels earlier this year. This time it wasn't my daughter though, it was an airline. I had been doing some personal travel right before this and they canceled my flight home. So they trapped me on the beautiful island of Madeira for a week, so I was trapped in paradise, literally. And if I had slides, I would be showing you pictures of me being very, very grumpy in paradise. My understanding is that someone plans to circulate one of those pictures, so good luck. That is not a badge, but it could be useful. There's also a picture of me in cat ear headphones because I was trying to work with all of the equipment I had, including my daughter's headphones. Now, there's some debate about whether speakers should introduce themselves at the beginning of a talk or at the end of a talk. And either all of you got way fitter and way more beautiful or there's a lot of new faces in the crowd, so I'm gonna go with the beginning of the talk. I am Brian Exelbeard and today I'm a technical business strategist for Red Hat Enterprise Linux in the REL business unit. I focus on what REL should be doing in like 18 to 36 months, so way out there. My specific area of focus is on upstream communities, developers, and something that we call the unpaid Linux market. And as a part of this work, I happen to work directly with the CentOS project as I sit on the CentOS board as the Red Hat liaison to that project. Prior to this, I was the F-Cake, the Fedora Community Action and Impact Coordinator and that's why I had the privilege of planning Flock 2018 in Dresden. By 2019, this role had passed to Marie Norden and now it's being held by Justin wherever he has run off to. And they are both doing amazing jobs way better than I ever could have. This talk, it has a bit of a history. It's not always a keynote, that's unusual, but traditionally Flock, I should say Red Hat has shown up to Flock and the VP of Platform Engineering would usually stand up and tell Fedorans what Red Hat was thinking. And when my role was created, they gave the talk to me. This is also the first time that this talk has ever been delivered to the CentOS project. There's a little bit of debate on that, but I haven't been able to find any actual evidence of this talk having been given to the CentOS project. And because of that, I'm gonna spend a little more time on CentOS project concerns because a lot of Fedorans have heard variants of this talk over the years. And as for the title, well it is what it is. The talk has always been called the what does Red Hat want talk. And so for tradition's sake, I didn't change it. But I've tried to play with the format over the last few years and I think you'll see that I've done that again. So before I get into that, I'd like to do what someone in my management chain, Gunnar Helixen, calls some table setting. So let me start with this. I work for Red Hat and I am here talking on behalf of Red Hat. And that means that I am biased. I like RHEL, I like the outputs of the Fedor and the CentOS projects. Everything else is fourth place at best. At Red Hat, we view operating systems through the lens of the problems that the customers, potential customers and partners face in the markets that we wanna serve. We're cautious in what we say and in what we promise because we expect to be held to those promises and we expect to have to back them up. So we don't casually use words like production or casually try to predict the future. And so with that having been said to kind of give you a frame of reference for where I'm talking from, I wanna start by comparing a few things. I wanna compare code and community. To paraphrase my friend Matthew Miller, Fedora Linux is an operating system, it's bits. And Fedora, it's a reference to the Fedora project which is the community and that's people. And I'm noticing more and more that people are using the language of community to talk about bits. For example, I'm seeing a lot of conversation about CentOS Stream which is bits and then someone tries to conclude by making a conclusion about the CentOS project which is people. That's a problem. Something else that I've been noticing is that there's a lot of confusion about companies and communities. Especially when the community project is sponsored by a company. And this is something else that comes up a lot when Red Hats talked about because we sponsor a lot of projects. And I'm seeing that some of our new enterprise Linux friends they're having this same challenge too. So we need to think about the difference in those. You see, done right. And I do think Red Hat does this right. The community is held at arm's length. The community has the independence to be able to have a separate opinion on the same things that the company has. It means that they have agency, that ability to have an independent viewpoint or opinion. And I wanna talk about agency for a minute because it's a very critical topic. Agency is that ability to act independently and it is very important. When agency is denied, you will find that actors get carried along a path that they didn't choose. And open source is all about agency. The four essential freedoms of free software are about ensuring that users have agency. Forking is an expression of agency. Special interest groups are SIGs, working groups, Spens and labs, these can all be expressions of agency. And Red Hat strongly believes in agency. When Red Hatters go to work and open source projects they have agency. They're expected to act in the best interests of the project. They have things they wanna do for sure but they have that agency to go and do it in the way that is best for that community, not just best for Red Hat. And that agency, it shows up in the community projects that we sponsor. Both the Fedora Project and the Centos Project have governing bodies that are set up to govern through consensus. Red Hat doesn't have a magic veto here. Both projects have someone who's in a dual role. That person represents Red Hat to the project and represents the project inside of Red Hat. Now in the Fedora Project, that person is Matthew Miller. I'm not sure where he has gone, but that person is Matthew. And in the Centos Project, that person is me in my role as the Red Hat liaison. We both have the ability to share Red Hat's viewpoint to the project and if necessary to vote against a decision on behalf of Red Hat. But we don't have a veto power because these communities govern through consensus, any governing board member can stop anything. And so the agency that I'm talking about here that exists for these projects, it's demonstrated actually by how infrequently Red Hat has anything to say and how we haven't acted to deny consensus. Now Matthew is very active in Fedora Project governance, but he has almost never had to speak as Red Hat. And if you look at the Fedora Council's decisions, you'll find that they're almost all unanimous consensus, but all by consensus. And in the Centos Project, you can see that agency very directly because there's a liaison. For those of you who know me personally, you know that I like to talk often about taxation. But if you go to a Centos Project board meeting, you will find that I say very, very little. And that is because there I speak as Red Hat and Red Hat doesn't have a lot of opinions and we haven't needed to deny consensus. The Fedora Project and the Centos Project have agency. There is not an interlocking governance structure that is shared with its corporate sponsors. And while the projects may at times have a significant number of Red Hatters in them and in their governance in particular, it isn't because this is a requirement. It's because those Red Hatters are passionate about the community and the community has recognized this and they've selected those Red Hatters through whatever the process that each project uses to select members of its leadership. They're not being selected because they represent or are acting on behalf of Red Hat. To put a very fine point on this, there are several Linux projects where the CEO of a company is also the project leader. And I like Matthew a lot and he keeps looking up every time I say his name, which is great. He is a distinguished engineer at Red Hat and I really believe he deserves this title but he is not the CEO of Red Hat. And you have a lot of agency. You have the agency to start or join a SIG. You can build a new spin, you can land your code, you can go build a user base and bring them with you. And you should feel confident and safe in your ability to inspire and influence people and know that your work will help many. And I think the real message for this part of this is if you think you're blocked by Red Hat somehow, come talk to me. I will be very happy to remind you that you're not because you have agency. Now, before I tell you what Red Hat wants, I do wanna spend just a minute talking about CentOS Stream in particular. So the CentOS project is a community and CentOS Stream is a code base and people need to stop confusing that. Success for the CentOS project is not measured solely on CentOS Stream. In fact, from my perspective, the SIGs are really the manifestation of a lot of the CentOS projects success. And a lot of this comes about because of the way CentOS Stream is structured. Specifically, it's maintainer model. It's all Red Hat by design. So anyone can contribute or propose a change to the CentOS Stream code base and those changes get made subject to the agreements of the maintainers. And at Red Hat, we've been very consistent in describing it this way. You can propose a change, the maintainers will review the change. So the real question is why is it like this in terms of the Red Hat only maintainership? And it's because Red Hat conceived of CentOS Stream for several reasons. And the two that we talk about the most are, that we wanted a place that we could open up minor release contribution and development for RHEL to a broad non-Red Hat audience in an accessible way. This is very much like what we do with major release RHEL development in the Fedora project. Also, we wanted to further enable participation for our open source ecosystem partners. And we've been consistent in describing our goals with CentOS Stream this way. But I think what people are missing is that at its core, what CentOS Stream really is, is it is an open sourcing of the practice of controlled limited operating system change. Now that is part of what we deliver as the value of RHEL. And that practice results in a code base that is fantastic to use to build Linux distributions. It makes slow and deliberate changes only after extensive testing and a lot of contemplation. And this is why you may see contributions get rejected. You see, if that contribution isn't required by RHEL, then that contribution isn't needed in the operating system. You have to have a basis for accepting contributions. And this is the one that we chose. But what if you need that change? Well, this goes back to the agency. You see, that's where SIGs come in. SIGs can build their own Linux distributions. They can layer software on top of them. And this allows them to focus on their differentiation. It lets them focus on serving a specific set of use cases or a specific audience. And they only have to do the work where what they want varies from what a RHEL audience would want. And this is a real model. It's existed long before CentOS Stream did. And we're seeing other industry actors and open source actors embrace the idea of building on CentOS Stream, which proves the value of the model and the value of CentOS Stream. But it also shows how refinement and targeting make everything better. It makes each Linux distribution more valuable to its users because you can't be all things for all people. Another proof point for the value of CentOS Stream is that we use it to build almost all of the approximately 17 different versions of RHEL that we are shipping at any one time. The only ones that we're not building from CentOS Stream are the ones in the RHEL 7 major release family. And we don't do that because there is no CentOS Stream 7 to start from. Now, I've talked a lot about CentOS Stream's code and I can't talk about the code without also addressing the very complicated view that Red Hat has of CentOS Stream binaries. So remember, Red Hat's cautious. We take CentOS Stream, we pass it through a productization process, and we wrap it with a bunch of promises and agreements and services for delivery to our customers. So we only recommend RHEL be used in production. If you have a RHEL-shaped problem, we're gonna tell you to use RHEL. Now, the converse of that is this. If you come to Red Hat and you go, hey, Red Hat, is this recommended for use in production? We're going to say, okay, well, how does it relate to the promises and agreements that we make with our customers? And if it doesn't match, we're not gonna recommend it. And so this is why you can find a statement on a Red Hat website right now today that says CentOS Stream is not designed for production use. And the reason for that is that it doesn't fulfill the specific promises and the specific agreements that we make with our customers. Now, there are a lot of Linux distributions out there. And there are a few that claim to solve the same problems that RHEL does. We think RHEL is the best of all of them and we don't recommend any of the others for use in production. But this doesn't make them bad operating systems. It just means we're not recommending them and we're not gonna make a promise about them. But I wanna be super clear here because there seems to be a lot of confusion. If you've got a problem that CentOS Stream or Fedora Linux solves, use it. They're both great operating systems. They're operating systems you can trust. I know people who use CentOS Stream personally. They're very, very happy with it. I happen to run Fedora Linux, specifically Fedora Workstation and Fedora IoT on my own devices. It fits the bill for me. I don't need what CentOS Stream or RHEL is offering. I've chosen what meets my needs. And when I have this conversation with folks, inevitably they come back to me and they go, okay, Brian, all this is true, why did Red Hat put that code in the CentOS project in the first place? And so for CentOS Stream to be successful by our measures, we knew that we needed infrastructure that a successful open source project has. And this really comes down to an investment question because we could have stood up whole new infrastructure but we didn't do that. There was obviously some other choices and we obviously went with one of them. So why did we do that? Well, it all comes back to this investment. When you invest, you're investing for the future at the cost of not doing something else today. A dollar that I save is a dollar I don't get to spend on craft ice cream. So when we were looking around, we were like, well, where are we making similar investments? We found two places. We were making an investment in the Fedora project and we were making an investment in the CentOS project. And we didn't wanna stop those investments. We need a place like the Fedora project. It is where innovation and integration meet and Fedora Linux sits right at that intersection point. And we need a place like the CentOS project. It is where we do work in technologies above the operating system like virtualization. And it's where a lot of work happens, where well stops and these folks carry it forward in different and exciting ways. So we had to make a choice. We have infrastructure over here in the Fedora project. We have more infrastructure over here in the CentOS project. What is the value of yet more infrastructure? And the answer is it's wasted duplication. It's gonna deny me craft ice cream. It's gonna deny resources to better uses. And so it was obvious we needed to co-locate this code. The choice of the CentOS project just made sense. So this brings us to the question or I should say the major topic today, which is what does Red Hat want? So let me start by saying this. Red Hat does not show up to a project and say, do this. That is not how open source works. Now you will absolutely find Red Hatters from various teams all over the company who will show up on a project and say, hey, we wanna do this. But they don't get to do it by fiat. They do it the open source way. They will propose that change. They'll discuss that change. They'll make that change safe for people to consume in the community and then they will do the heavy lifting to land that change. Those are not the teams or the themes that I wanna talk about today. So I wanna go back similar to my CentOS stream comments and tell you that this is really an investment question. So we're making an investment in these projects to achieve some goals. And here are some of those goals. And I wanna be clear, these goals apply equally to both the Fedora project and the CentOS project. We wanna see fantastic open source communities. This means you're growing, you're active, you're vibrant. They're places where Red Hatters can go to engage the open source way. And we know that a part of having functioning great open source communities are that people are using your outputs. So we wanna see your outputs be specific. We want you to know who do you wanna serve? Why do you wanna serve them and how do you plan to serve them? We want the projects to have a voice. Be you. Red Hat is not gonna be your proxy when you choose not to talk. And we're not gonna show up and tell you what to do or what to say. We want you to fill in the white space in Enterprise Linux. White space here is a reference to all that place that like it's in the background. It never seems to get looked at. And so an example of this is actually in the desktop operating system space. Red Hat and RHEL are deliberately not in that market. We chose to exit that market, we're not there. We do offer a workstation. Workstations are very specific kinds of hardware, doing very specific kinds of work, not general purpose desktops. The very confusingly named Fedora workstation is a fantastic desktop. And it is doing a very good job of filling that white space in Enterprise Linux. Related to that, we'd like to see cross-pollination between the projects and within the projects. That could be the projects working together themselves. It could be SIGs working together. We wanna see you connect yourself where it makes sense. We wanna be able to realize flows like somebody needing to make a contribution to Fedora Linux, even though Fedora Linux doesn't meet their consumption needs, and then consuming that contribution through either CentOS Stream or RHEL. Now, I've talked some about what Red Hat wants. Inevitably, someone will ask in the Q and A, is there anything Red Hat doesn't want? Well, yes, yes, there is. Red Hat does not actually wanna monetize the entire market of Linux consumers. We're not interested in that. We know that there are people who do not ever wanna pay Red Hat or may not ever wanna pay for Linux, and that's great, good for you, have a nice day. And I wanna be clear that within the market of folks that we do not wanna monetize, there's a significant number of people who just don't want the things that RHEL promises and delivers. If you don't need RHEL, we're not gonna sell you RHEL. And while I'm talking about this monetization concept, even within the part of the market that we wanna monetize, there are significant segments that we don't want to. And you can see that in the RHEL developer programs for individual and teams. We're not interested in monetizing what we call the development use case. And there's a related point here, and that is that Red Hat's open source strategy is one of differentiation. Now, people on the internet have suggested that Red Hat might wanna make products out of Fedora Linux or CentOS Stream. And I can't see how that works the way the people on the internet claim. Because if we were to do that, we would have to then go build all brand new communities to stand in front of whatever those things are now called. And the company that just told you that a third infrastructure was not a good investment is not gonna go build yet even more communities that we have to invest in and stand up and help be successful when we already have two amazing communities. Besides, if we really wanted to somehow make one of these things a product, we'd just go create a derivative operating system, which is exactly what we're telling everybody else that they should go do. It is a model that just works for everybody here. Another thing that we don't wanna see is we don't wanna see the Fedora project or the CentOS project try to deliver the RHEL value and promises. And the reason for this is because we don't see the projects as competition. We wanna make sure it stays that way. But the bigger reason for that is that the projects shouldn't be trying to duplicate each other or Red Hat. Because if there's a legitimate reason why one of the projects feels the need to do that, we have a major problem in our ecosystem and in Enterprise Linux. And we need to go solve that problem, not worry about trying to duplicate each other. So, I apologize, I've lost my place in my notes. While I'm mentioning competitors, we're not worried about competitors. Competitors make a market stronger by bringing differentiated value. And the key here is differentiated value. The operating system is not a commodity and you can prove this by the number of operating systems that are available for you to use in the market. And so in our view, if someone tries to copy well without adding any improvement, but just making it cheaper, it harms everyone. This activity creates confusion for consumers who often come away with a false sense of security because they think a promise has been made about the copy that hasn't been made. And when you consider the act of copying, it creates a race to the bottom. It generally starts with a lowering of prices, which is because the copier has an almost zero lower bound for pricing. And all of the costs, they're being borne by the thing that's being copied. So this reduces the funding that's available to improve and grow the original. And the response in other industries is to start to cut it. You try to focus it more narrow and more narrow. In software, what you'd see is the code base would become more specialized and it would meet fewer people's needs. Now, as an open source community, we like to think that open source is immune to this. We have the ability to contribute upstream, so none of this is gonna happen for us. But if you start to examine this, what you'll find is those upstream contributions, they're not the thing being copied. What's being copied is the distribution. And the distribution is an opinionated collection of all of those upstream components. And that opinionation is the differentiation and that's what's being copied. That opinionation, that differentiation, it's developed by product managers, by market needs. And if you destroy that market, you destroy that ability for that differentiation to exist and for a strong, healthy market of differentiated offerings to exist. Now, what I've outlined today is not new. Over the years, this talk has gone from generalities to specifics and back again. And in every version that I've seen or given, there is an underlying theme here. Red Hat really wants to build the best in class enterprise products for the problems that we wanna solve in the markets that we wanna serve. And critically, we wanna do this through an open source development model. This model enables entire ecosystems to grow well beyond what we can directly address or even have an interest in addressing. And truly amazing communities like the Fedora community and the Sentos community multiply that even more. Now, we've stumbled along this journey at times. And every time we do so, we do it publicly. And every time this happens, we learn a lesson. Often alongside or along with most of you. But we pick ourselves up and we keep moving forward. We stand by our decisions as a commercial open source company. But we recognize that these stumbles, they can cause some of you to have doubts or waiver in your trust of us. But our commitment to open source and collaboration has never wavered. And when we say we wanna collaborate, we mean it. So as we continue to walk this path, we're gonna loosen and learn and adjust. And we hope that you're gonna walk this path with us to continue to improve Enterprise Linux and the open source ecosystem every day. I look forward to seeing all of you in the Fedora project and in the Sentos project. Thank you very much. Justin, Matt, thank you. Justin is supposed to tell me if I'm allowed to have questions or not because Matthew talks a lot. So we are at 1030. So we have a coffee break lined up but I figure we can take one question here because I see one hand and then we'll break for coffee from 1030 to 11. The speech was really good. But one thing I'm thinking of as like a commercial open source project that has been stumbles when does like the business kind of take over? Like what's happened last month where Red Hat and IBM decided to make closed sourced. So what I wanted to ask is like when does like profits like basically take away open source? I don't know, this is the first time asking a question so, yeah. So a couple of clarifications just to make sure that we're, I'm answering the question that was asked. First, the decisions that were taken recently were all taken by Red Hat as an independent entity. IBM had nothing to do with it. And Red Hat's code is still open. It is not closed. However, the core of your question seemed to be, and please correct me here if I'm wrong, when does the business drive decision making that from your perspective may or may not have an impact on open source broadly speaking? Yeah, okay. I think the answer to that is that like all companies, Red Hat is constantly looking at the market and looking at what is going on in the world and we have to make adjustments to how we handle our product. One of the things that we do is that we have an upstream first philosophy at Red Hat which means that we contribute all of our code as far upstream as it is possible to contribute it. What we find sometimes is that upstream projects are like they're super excited to take our code and they do it and their output becomes better and the broader community of us, our competitors, everyone is enriched by this contribution that Red Hat has made. In some cases, we show up to upstream projects and they're like, wait, we wrote this? This is like 10 years old, dude, seriously, no. And that's cool too. Oftentimes we visit our friends in Fedora where they're like, mm-mm, no, that's not happening. We do every 13 months, please go away. But eventually, we do find a home for it, CentOS Stream being I'll say the home of last resort because ideally things flow into CentOS Stream. And so in that sense, I think that the business can do whatever it wants on the product side and the code is always out there. The code is guaranteed to be available. Anyone can pick up these upstream components and build the opinionated, differentiated Linux distribution of their dreams. There are absolutely going to be decisions that Red Hat has to undertake for its own fiscal well-being. Otherwise, we can't afford to pay all of those developers that are doing all of this contribution into the upstream. But I will say that there's a natural tension in engineering companies in general, which Red Hat is one of, between engineering-led and business-led. And I think that all companies face that tension and most of the time most people don't notice it because it's like ripples below the ocean. And sure, occasionally sometimes you're like, whoa, what was that? Oh, one of the teams must have just suddenly asserted themselves. But in reality, a lot of it is around the idea of when you're in an engineering-led organization, you are focused on solving the problem that you perceive the customers having from the point of view of an engineer. And when you're in a business-led organization, you are solving the problem that the customer has from the perspective of what the market is telling you. And if you, I'm not sure whom you work for, you may very well work for Red Hat, I don't know, but if you go talk to your peers in the industry, I think you'll find out that a lot of people sometimes wind up working on a piece of code that they never execute themselves or that their execution of it is, for lack of a better way of saying this, they have the hello world level execution. I happen to run a piece of a server virtually that's running Fedora IoT. I would not pretend to be the example of what Fedora IoT is trying to target. So my ideas of how that product should improve personally are not necessarily relevant to the vision of the market that that product's actually trying to serve. And I think that's the tension that you're seeing a lot of here. Thank you all very much. Enjoy coffee, because I know Justin wants to get me on stage. Thank you, Brian. So quick housekeeping, we are gonna break for coffee speakers, just as a note, we will have laptop provided in the room. So you can open up an online link or if you have offline slides, we'll need to make sure you have a USB key or some way to put those on the laptop. We do have some, either me or Sean can get you a USB key if you need. Otherwise, we'll be starting back up at 11. There's three rooms upstairs that have three smaller sessions. We'll have a session back here at the main stage and we'll be back at 11. Enjoy your coffee. And we're at two minutes past the hour so we should probably get started. I wanted to introduce Akash. He is our speaker and he's gonna talk about the Fedora website and apps revamp. So everybody give a hand to Akash. Right, so let's check if it's working. Can you folks hear me? Perfect, thanks. Right, morning folks, two folks who know me. Nice to meet you. Nice to see you in person again after so many years. A bunch of folks I met during Faustum, a bunch of folks in the CPE face to face and for the folks who don't know me, I'm Akash Deep Dhar. I work in the Red Hat community platform engineering team as a software engineer. That's my day job. Apart from that, I take part in things like mentorship, documentation, packaging. A bunch of stuff I do is about making sure that Fedora Workstation becomes a platform of choice for video gaming and stuff. Nice to meet you folks too. Right, so today I'm gonna talk about Fedora Website Snaps revamp community objective. That was how it was called back in the day. Nowadays it's called community initiatives. It's a place where you become a part of Fedora Council. You select yourself a task, a goal that you would want to achieve in a given time and then you pick your own team. Check if the things that you wanna achieve with that community objective does it really bring Fedora forward as a community. And this is the story about that and the things that we learned during the way while we were revamping not just the websites and applications, like sure that was the goal but what we really wanted to do was revamp the team while we were at it. So here's the story. It started off at December 2020 where we were like four enthusiasts who were working on Fedora mode. If you don't know, it's a meatpot logging application. We used to have or we still have IRC meetings or meetings on matrix that needs logging for folks to look back to check to the records and that's what we used to make use of for logging them. So we started off with that because the app was falling apart. It was in a sorted state and the team of four was myself, Justin, Ramya Paremi and Naseer Hussain. We decided that we'd start working with that and we slowly started to increase that remit of websites and applications that we would take care of because we totally could do a lot more than just that. The initially time the team was called DevOps Sig but we quickly thought to not increase our remit that much because, well, that would include almost every application that's maintained in the infrastructure and maybe that would be a bit too much. You know, jumping in the deep end when you don't know how to swim, not something that we would necessarily want to do. We were assisted by Marine Orden who helped us bring all those ideas together so that it does not sound as crazy as we made it sound like initially and it looked a lot more achievable, a lot more quantifiable and then it became a council objective when we proposed it to the council. Right, so we did start very humbly with a bunch of crazy ideas, a bunch of wide-eyed, crazy, starry-eyed people but when we got our ideas formalized, we wanted to make sure that we really have a team, some calculatable, quantifiable goals to accomplish when we can say that, yeah, we are indeed making some progress, otherwise we can just go on and on about revamping our websites while not doing anything at all. So we drafted our mission and vision statement, the long-distance thing, the 10K feet view of our goals and one of the things that really helped us to get action items from those was the logic model and it was really helpful because it was actually allowing us to move left from the goals, from something that we would want to end up doing after 18 months or 24 months back to something that you'd want to do right now. Yeah, if it's code, if it's documentation, if it's making sure that you're able to on-board people onto the team as effectively as possible, it was allowing you to connect those goals to things that you could start off right away and well, we were helped with Ben Cotton to make sure that we choose really realistic goals and not something that's way beyond our means with both respect to the time as well as the efforts and finally, this proposal was met by the Fedora Council with a universal approval, all plus ones, no zeros or no minus ones whatsoever and then we really got off to starting doing things which were much more than one application that we started off with, that was Fedora Meet Portlogs. I'd say the very first thing that we did was to create a team because how much of a team of four people would end up making, right? We needed more folks and we needed more folks fast. The existing team that we had was only a team of one person so you can imagine how bad that would end up being if that one person was to disappear or one person was to become really busy and we were having a Fedora Linux 39 coming out at that point in time but our websites are not updated according to that so we really wanted to make sure that we have more points of failure and not just one and then we started looking into the appropriate tools, web technologies, workflows, the design things that we would want to take into account while making our websites and applications and this was around the time in June, 2021 that I joined Red Hat as an Associate Software Engineer in the community platform engineering team. Moving on to August where we started writing down the rules and regulations because we really wanted to make sure that we are progressing towards a certain goal and we are not deviating ourselves with ideas that might just come in and that might look all shiny and we might want to pursue it but this was around the time when we had a bunch of disagreements. A lot of disagreements, a lot of dissatisfaction within the team because well, admittedly, everyone was really, really enthusiastic about what they wanna do and it's almost like the purpose for everyone to do with the objective was a good one albeit the way of achieving that goal was a lot different and this time again, we were helped by Justin and Marie. Unfortunately, this was again the time when NASA had to leave their efforts for a while and moving on when we actually got back on track on October 2021, we acquired interns because we wanted to really make sure that we not only keep our instructions to ourselves but well, maybe we could onboard some interns, teach them about stuff and who knows, we can have them as long-term Fedora project contributors down the line. So, me and Franchoa Andrew was one of the contributors who worked on the Fedora Meadpot Logs project pushing it to the completion while the Fedora websites, the general offerings websites of place where people download ISO images from, let's just say, were mentored by Honorab Sizer and Michael Shero. We continued on conducting regular planning meetings for the co-leads to make sure that we are really up to the task for leading the entire team which was getting significantly bigger. At this point, it was no longer a team of four, we had already become a team of over 20 people. At around December 2021, Ramya Parimi, who was a co-lead with me in the objective, decided to step down and the Fedora Easy Fix project, a website where people could take a look at good first issues to just get started with contributing to the community. It had to be abandoned because there was a lack of interest in the community to use that website. Again, not a good time for the community objective and this was again helped by Graham White who stepped right in as a co-lead and he used the project management skills that he had to guide the project forward, guide the community forward into revamping our websites and applications. The interactive organization chart, the one that we, Marine Norden designed back in the day which encompassed everything from council to Fesco to all, little six, was made interactive by one of us as at around this point. By February 2022, the revamp efforts for the websites was started off, it was proposed by Pavel Zelowski. Regular discussions with the stakeholders which includes folks from the different six as well as the ones from the infrared team, marketing, you name it, were conducted from then on. We also acquired a couple of interns named Rishabhangi Chaudhary and Ujong from Outreechi and their first two rewrite meatbot logs and their fedora graphs were enhanced just because we had more people on the board. Now that we had things really chocked out, the path really planned for us, we walked on that path to make some progress. So my focus, which was previously on engineering because well, I used, I love writing code, but I decided that, you know, it's just me that I'm addressing and some more people who would work along with me. I would much rather write documentation to help people do the stuff that I do whenever I'm not around, let's just say. So my focus shifted onto writing documentation for both development of the code base as well as the workflow as the how team should operate, how meetings should be run, stuff like that. We also continued to having active presence in events like nested fedora. In Fedora Linux release parties, we conducted a bunch of workshops, Ashlyn Knox and Onurab says that again, to thank for that. And we really used that time to convert a bunch of Fedora Linux users into Fedora project contributors because we used the time to tell them about the stuff that we have been up to and how they can be a part of it. Then this was again the time when the internships were headed towards completion. By June 2022, multiple outcomes of the objective and outputs were completed. It was again the time where we were checking things of left, right and center because well, we were making some good progress. The first mockup was for the renewed websites for the Fedora workstation, which arguably is our primary offering was designed by Maureen Duffy. She's over there. So the talks about the discourse about the Fedora badges, the fact that we would want to use something that's already there, that we are using for discussions and to use that for Fedora badges front end was started by Matthew. Honoralp Cesar was elected as the mindset representative for the team. So, moving on to August 2022, where we had the first in-person representation for the team in the Fedora Hatch Pune 2022. I met with a bunch of people from not just within the community, but also within Red Hat, who were not necessarily a part of the Fedora project community at that point in time, but just because they worked on web technologies, they were really interested to get their hands on to building something that they would find interesting with people that are not necessarily their colleagues, just community people and have fun while doing so. The Fedora website's 3.0 manifesto was designed by me and shared both within the community as well as within Red Hat. The design walkup for the Fedora IoT website was created by Emma and the rewrite for the Fedora Meatbot Logs 2.0 application was finally completed at around that time. By September 2022, the team enthusiasm was again reignited by the advent of Fedora website's 3.0. This is where we decided that we'd not only redesign our websites, but the navigation, the look and feel, using a newer set of technologies rather than just bringing along the old ones that was based on frozen flask. And Nuxt.js was selected for the websites, while Vue.js was selected for the web applications that were under a remit. The discussions for the long-term maintenance for the Fedora badges was started and the third design walkup, that is for the flock to Fedora websites, was created by Ashlyn. Moving on to October 2022, the development efforts for the websites were joined by a bunch of new contributors. A lot of those really steered back for a long time that I really appreciate folks like Nico Dunck, Jefferson Oliveira, and Deepesh Nair. The design efforts were joined by Madeline Peck, Jess Tietas, and Don de Marais. Effective collaboration was done and it was not just the websites team by themselves, but they also started collaborating with people from Fedora infrastructure, Fedora design, Fedora marketing to better collaborate as to what should be there in the content of those websites and how it should be deployed, stuff like that. The progress along with the development for the Fedora badges, we really need to understand if the Fedora badges was something that the community really wants to revive or they could simply use it in the state that it was in. So we started collecting testimonials from the community. By December 2022, Sandro and Errol Skin, they volunteered to look after the Fedora badges project in the state that it is in, the technologically feasibility investigation. Basically we're just investigating what kind of technologies that we can make use of to revamp the Fedora badges web application was done by me at around that time. The investigation was joined by Mikal and Lenka who are over here from the community platform engineering team. And the work on the Fedora websites 3.0 project was at that point in time it was in full swing. The mock-ups that were made were actually implemented in the code base. And in the final phase of the community objective, when the badges technological investigations completed, we started writing code for it. And this was around the time when the code base for the Fedora websites 3.0 stack, say the components or the tools we made use of was nearly completed. This was again around the time when Fedora Linux 38 came out. And I think that we decided that it would be for the best to not just bring out our new websites in front of the community with the release of Fedora Linux 38, but also to call this council objective as a success. I visited the council face-to-face representing this community initiative in Frankfurt in February, 2023. And by April, 2023, we got back to community survey results as to understanding how well we have been doing our job in the community as a team which takes care of our websites and our applications. Matthew Miller and Ben Cotton proposed a closure of the objective at around that time, but I was still thinking that maybe we could use some more time to connect the infrastructure elements, maybe make the community folks a lot more welcoming to the infrastructure tools because it's still something that requires intervention from dedicated teams. The Fedora badges 2.0 and the remaining websites were elected as future scope because well, if we tried to make things perfect in the very first attempt, we're only going to fail at it because attaining perfection is an elusive goal. And finally, we decided that, you know what? Let's call this thing as a success and everything else can be done down the line. And that is where we were able to call this thing as a closure and it's probably one of the most recent community initiatives from the Fedora council. Right, so sure, that was the story about how we started the, well, the rocky path that we took, the changes of the remit that we went underwent and the kind of results that we ended up having, but what did we end up achieving? What were our achievements? So in order to retain contributors that we onboarded because well, onboarding is easy, but in order to make sure that the folks that you have onboarded, they stay around for a while and they communicate actively, they contribute, we really needed to make sure that they were recognized for their efforts. And one of the first things that we did was to have a badge dedicated for folks working in the team. And it's called Rock the Web. We award it to anyone who participates in the team and we do plan on creating more badges dedicated to particular websites or particular applications like, let's just say that it's the badges website that's being reworked on. So chances are that if people are to participate in that they might be awarded with that badge. The next thing that we worked on was to give some tangible swag and we have planned that. It's still something that we are having in process, but we really want to make sure that people understand that, yeah, we really, really appreciate their time, their effort that they have spent within the team, making our websites and our applications much better than how they were before. The next thing was about the ability. We wanted to make sure that people not only jump on the team just because they wanna do something, but they also have what it takes to update these legacy websites and applications or if they don't have what it takes, we should provide them with a platform where they not only do stuff, but they learn stuff about it. They learn the technologies, they learn about the workflows that's required and the team had been and it continues to maintain a bunch of projects in its current state. A bunch of projects that we started, we thought we would be maintaining, but just because it became too big of a deal for us to do that or maybe we had another team that was taking care of it, we decided to step it down from our remit and probably pass it over to some other teams and then finally there were certain projects that we could not maintain because of the lack of the community interest in that project. So we decided that, you know what? We just simply deprecate them and of course the deprecation happened only after we were able to get the community approval that yeah, if it's something that people could really make use of. Finally, we really wanted to make sure that the information about maintaining these projects because mind you, the ones who are maintaining it right now they might not be maintaining it forever. They might start doing something else some months down the line, some years down the line. So there should be some documentation that people can follow and do the exact same thing as others did. We did document that as well. Then comes the regularity and responsibility. It's about achieving that the Fedor Linux websites are updated regularly as soon as the new updates come out. So we wanted to make sure that the team had what it takes. The technology was up to the mark for that to happen. And the responsibility means we had to really make sure that we were sizing it only up until the kind that we had the capability for and nothing more than that. Then the knowledge of maintaining these websites and developing them as well as the interest to not only create these websites but also to onboard the newcomers so that they can find something that they would want to really work for very easily. And finally mentoring them to make sure that they really stay back and they feel really welcome in the community as well as us participating in a mindset community so that we not only represent ourselves but we also get to understand what others have to say about us. Right, I'm gonna take a couple more minutes for the lessons and I'm going to be really quick because every lesson is just a couple of words. So we made sure that we start small and connect goals to the work that we wanted to do first and to remain regular because trust me if you don't have that momentum things are gonna fall apart and you can't do it alone so you would have to recruit members, lots of them. Then finally expect disagreements, debates, accidents, it's normal, it's fine, don't freak out and document everything so that you get to come back to things later and it's not all alien stuff for you. And finally, recognize stuff, recognize people's efforts, their time and communicate often whenever you are taking decisions. That's about it. Here are the links that you can follow to know more about the team while the objective is complete, the team still stays and takes care of the websites and applications so you are by all means welcome to be a part of it. Here are the places where our documentation, our chat platform, our repositories as well as our discussions are done. Thank you so much. Right, so do you folks have any questions? Hold on, hold on. So you are saying that you are using Next.js for the websites? Yeah. Are you doing anything to make sure that the non-interactive parts of the website continue to work without JS enabled on the browser? Yeah, we are. So we are in the process of minifying the JavaScript parts as much as it's possible to a point that a bunch of things minus, well, the things that require to interact with the server to get the ISOs, what's that thing called? The integrity checks, you know? So the hash keys are the only parts that require JS right now but everything else works totally without JS at this point. We really made sure of that. Oh, well, a lot of people don't. Yeah, no, it was one of the design ideas, by the way, because we really wanted to make sure that this is not just accessible to normal browsers but also those which are, well, outdated. How are you integrating with other teams? So it goes by the need by need basis. Certain times we of course started off with the teams that we really needed to integrate with. So if it's coming to deployments, so we really had to communicate with Fedora infrastructure but we really did not want to limit that interaction on the basis of what we wanted to do with them. We wanted to learn how we can do much better at providing them something that's easy to deploy rather than just giving them a Docker file, you know? And that's how we were also attaining that information to do a bit more towards that time. Also, when it comes to design as well, I think a bunch of folks from the design team they became a very integral part of the Websites and Apps team as well. So they were regular parts of the meetings, regular stakeholders who would actually help us decide things that would make sense, you know? Yeah, I mean, I was one of the stakeholders. And I felt, so very clearly I felt included. There was no point at which I did not have an opportunity to express my needs or to listen and get more feedback. But there was a complication around participating in the regular cadence. And that's something that I would love to see maybe an opportunity from the perspective of running another team to look at how we can maybe create an integration point. Julie noted, yeah. One of the things that has happened very recently is we started dividing our meetings to two parts, something that's a lot more accessible to folks who live on the eastern part of the world, that's to say earlier time zones versus the ones that's a bit late, say we really want to make sure that there's a common time that's suited for everyone but as time zones are difficult. Yeah, that can happen. Thank you so much. Do we have the time for it? I just had a very fast question. On the slides you had three languages. Could you explain that? Oh yeah, say the first one, the one that's in the larger type phase is English. The second one is Bengali. Third one is Hindi. And the fourth one is Irish. So really wanted to not just pay homage to the mother tongues that I have but also to the beautiful country that I am in right now. So yeah, that's the rational behind those. So you coming in? Yeah, definitely. Cool, thank you so much. What's your strong point? You already checked it in advance, torture. So up next we have Peter Boy. He's going to talk about Fedora Docs, plans for the future, how you can contribute. We're just doing a little bit of text that up here for his laptop. Okay, does someone has a Fedora sticker at hand so I can hide the FSI? Yeah. No. Oh, it's already online. I need my manuscript, sorry. Yeah, well, I'm Peter Boy. You can read. And that's the first, oh sorry. And it's the first time I'm in an in-person Fedora meeting so probably some words about me. I'm working as a scientist at the University of Bremen, no redhead, no, whatever. I graduated in sociology as a first and as a minor in applied mathematics that was the home of computer science those days. And statistics. And well, because of that, my colleagues thought I was a perfect person to care about our department's computer equipment. And it grew and grew because we were funded as an excellence research collective. So we had our own equipment, we had freedom from the university IT and the side drop grew and grew too. At the end, I ended with 24 or so servers and hardware. At the end, all of them in Fedora server. And well, and I began to contribute to Fedora thanks to Matthew's reboot of the server of a gig. I wanted to spend some of our internal Fedora documentation to Fedora, that was a starting point. Well, nowadays I do a lot of more than contributing docs. And when Ben a year ago started to reboot the docs team which was dormant for many years at that time, I came to the crazy idea to join the docs team as well. And well, now I'm the member of the board and the only one who is regularly available. Okay, so it could be better. Well, let's start. Some pages didn't work with the equipment here and other pages. Okay, so wonderful, the IT technology. Well, let's start with a short analysis where we are standing, where we are standing. It's not a secret, the state of the docs in Fedora, there's a lot to wish for, let's say, that way. We are suffering with the docs team for many years until recently we had online our docs from Fedora 18 onwards or so and if you skip through the docs released by release you could see from release to release a number of documents which compose the docs got less. And sometimes anytime it ended with just two, it was an installation guide and it was the administration guide. Well, but as a scientist I tried to make analysis. The idea was it's not a coincidence that we have such a, how to put it, not a bad state but a state which has many open wishes. It must be a structural issue. And the thesis is we have a weak integration of docs into the Fedora project and into the Fedora development. There are several signs of it, is it here? Okay, you may see and compare some starting points of several distributions. It is Fedora, it is Rocky Linux and Arc Linux or how they are pronounced. And maybe you notice a difference between them but we don't want to make a guessing display here. If you compare them you'll see these quite successful distributions have all a document link in the main part of the website besides Fedora. It doesn't, we have no document link in our website. It's a weak indicator or indicator of docs is not in the main objective of Fedora, of the Fedorians. And if you have a look at our procedures, eGV have a lot of regularities, a lot of decision chains to make a package. All these decision chains handle about technical issues. There is no requirement to have a doc. At least, for instance, in the description field for the package that there's a link to any kind of description. And even worse, we have additions. We have a lot of procedures to make this addition. It's a product document requirement. You have to specify the marketing chances and you have to specify the user base, the problem, but you don't have to have a documentation. We have no issues to distribute our flagship, our lighthouse distributables without documentation available. Fortunately, most of our additions have a documentation, but that I think is more by coincidence than by system, systematically issues. But the problem is, this week integration, I think it's long-standing, more than a decade. We can change that in foreseeable future. And as far as I know, Matthew can talk about it. Documentation was no topic in the current next Fedora discussion, I suppose. Yeah, yeah. So, next challenge is 2030 or so, flash probably. I was saying, we had documentation as one of the points somewhere, and then it ended up falling out in one of the reorganizations, but there's kind of a bucket of here are the things we didn't know what to do with, where should they go? That's gonna be part of the conversation. But yeah, you're right, it's not been a focus, except there is one section, like the accessibility documentation has a call out, but that's kind of about the documentation we have already, rather than making it a specific focus. I have to hurry. Well, the state of our documentation has some, I suppose, not fortunate effects of our distribution as a whole. For instance, we are hiding all our excellent technical capabilities, because without documentation nobody sees it. And many Fedorian want to, for instance, set up a web server, they don't find any documentation and start with documentation from Debian or whatever they are finding, and wondering because why it doesn't work. And the thing is, okay, Fedora doesn't work. Or Fedora is awaited as difficult to use and some decide not to switch to another distribution. That's a negative effect in the wrong run, among others. We could, I think we could fix it without too much work. The minimum could be to change our package guides to include some kind of documentation. It's new for packages. Oh no, it isn't new. We are used to do that with change proposals. It's, I had to read double time or three, but yes, we have in our change proposals a section about documentation and to explain our users what to do. So our packages are not so unused to documentation. Maybe in the long run we have a chance to improve the situation. Well, that's a general consequences. We have, well, that's the gist of it. The gist of it, we hide all our excellent engineering results because we have no documentation, no one finds it. Well, and we have an effect of our documentation tools themselves. We switched sometimes to go from DocBook and be the publican, was it, to EskiDoc and Torra and a good workflow. And the problem is that is a workflow that is fine for developers, but not fine for those here who are dedicated writers. I don't know from any public publisher who asks for a good repository or ask for EskiDoc. That's the different workflows. And the workflow has a lot to desire because for instance, at the moment we have no preview tool, so we are writing docs without having to see the presentation of the content. And unfortunately, if you are writing docs, there's interdependence between the content and the presentation of the content. And so our tools are missing very important element of writing. Well, and we have a kind of quandary at the moment. We have a workflow which is perfect for developers and we are in urgent need for developers who write documentation. Or we have people who want to write documentation and have a huge barrier in form of the Git and workflow with the pull request workflow which is quite unknown to them. And this is really a problem. After Ben started the reboot of the docs group, we managed to get eight new contributors over the one year. Well, currently the age, the eight one is a zero again. So after one year, nearly at the same point as he started a year ago with Ben's initiative. I don't know the exact reasons, but involved in all cases were issues with the workflow and with the GitLab user interface which is nice and powerful, but 80% of it's unneeded for documentation. And we have no options at the moment as I got to know to simplify for docs. So we have a new, we have one barrier dropped and have built a new one. No, nevertheless, we can not wait until we have a better integration. We might have to do some things in the time we have. So we started or I started to evaluate how we can improve documentation with the circumstances as they are. And we took three, the two ways, the one way is to fix document structure. The most problem is our document structure was it was perfect for Fedora 10, but all the changes we made with the last Fedora Next to create the additions didn't went to the documentation. We had a unified installation guide which should be valid for all our distributables, but it wasn't. So, sorry, this is, this is, this is, it's very hard. Well, we changed the Docs Home page and I wrote a blog post about the change we made and we adopted the structure of our documentation, the structure of our distribution. And we had, we resolved some documentation problem with that. The responsibilities for the edit, for the additions is now the addition workgroup. And the addition workgroup should be familiar with the workflow and pull request workflow. So it seems it's not a problem for them. I hope so to make the proper the right to create the proper documentation. Oh, if I better. Okay, that's, coming with Fedora Release 27, we changed the Home page. We're in the, no, that's just a moment. You can see a bit more. We have just the introductory part, first part at the top and in the center of the page are our additions or additions to be in case of Kino and Silver Blue it is. And we have, we have an opportunity to add some of our goodies. These QuickDocs, for example, or a specific box for the ARM computers, for S-bits for a single board computers, which is currently a discussed topic. Well, there was some, I skipped that, sorry. The other way was to improve, to make contribution easier for our users. And the way that was, first step was, as documentation team, we documented the procedure. So we created documentation about how to contribute to Fedora. And we concentrated on QuickDocs because this type of content, which is not so complex and not so huge as contribution for installation guide for addition. And so it's easier for users to start to contribute to. And we developed this documentation, how to do it. We developed some templates for creating QuickDoc document and various others help material. So we hope it is easier to do that. I skipped all the details at the moment. We are trying to demonstrate these things in our workshop sessions on Friday, I suppose, somewhere. So we can demonstrate the things in detail and we can hopefully get feedback if we did a good documentation or a bad one, for instance. Well, another step is, we have to improve our doc tools. Specifically, we need a text processing option for ASCII docs documentation with a preview or a visibility interface. The only one I found at the moment is ASCII Doc FX, yes. And well, we need developers to develop our documentation tools and that's a long-term goal. It's not for the next two Fedora editions or so. But what we already have in the work is to automate the generation of our release notes. So these notes suffer from the same issue as our usual documentation from release to release. The percentage of changes which were included in the release notes are going down. And to help, therefore, we are going to automate that, probably not with the next, but with the over next. Okay, that's a short overview with some technical issues. And yeah, but we have time for questions, I think. It's not me, it's she. Hi. So you mentioned there are some, I suppose, issues with people onboarding in terms of learning the Git workflow and that kind of thing. Do you think there's an issue with the documentation format? So ASCII Doc over something like Markdown, which is a bit more ubiquitous? No, not ASCII Doc, it's a tool issue. A tool on the workflow issue. All of these, well, they were users without a development experience, but some of them were dedicated writers. So the problem was not to make a text. The problem was to get a text in our documentation. And it was additional work for them, that's a problem. And it was not attractive enough. I'm not, I'm too fussy, but it's a German wording. I think we can fix that, but it's additional work on our side or my side. Well, just a little comment on the workflow. So I've been involved in publishing lately and the process that people use like the professional writers in air quotes without Git, it's a living hell to be fair. And I believe that spreading the Git based workflow is actually a net good for everyone, for non-developy writers as well because the process can spread around and they can bring it with them to other projects. Maybe, my problem is the guys are away. I would like to have it. And all of them struggled with the workflow and the additional work. And my goal at the moment is to make it easier for them, to provide better guidance. For instance, you plan, we are planning for a virtual shared writing sessions where we have someone attend during the session who can fix problems or explain them. But we have additional work to do. Okay, so I have no problem with the Git workflow. I do that myself and our projects, it's not a problem. But the non-development defined users are, not the problem, but they have the problem, so. Well, it may be a bit of a shameless plug but in virus, our distro. So when we switched from Media Weekend to Sphinx and Git, the community of the communication developers actually exploded. So sometimes I wonder if it may be just an issue of marketing that workflow to people or attracting the right kind of people. Yeah, I think, well, if I read what they have written, they were the right people, content-wise, at least. And well, I'm quite unhappy or sad to have lost them. It's, they weren't able to write qualitative high-level documentation. Do you think it might be worthwhile to, I like having consolidated in one tool, but do you think it might be worthwhile to move something like the QuickDocs to another system like a dedicated wiki or even to solving all my problems with discourse, using the discourse as a docs plug-in that was marked down-based? Would it, might it make sense to have a different, like easy format docs that people could use or would you think it's better to keep it all in place? There were some people who proposed to go back to wiki. I don't think it's a solution. We should have a unified system for normal docs and QuickDocs, we have to refer back and forth. It's a matter of presentation to the public. I think it's not a good idea. The counter example is the ARM area. They are only on wiki and it's hard to find them because it doesn't fit in to our documentation structure. And so my, what is the Krueger in German? It's a help, my helping stick to make a box for the ARM on the wiki, on our main page. So to have a topic which is highly discussed at the moment, well, you have to offer something about it. And so I'm more on the trip, make it easier to use the workflow and hoping on the council that we get a better integration in the long run. And I hope that our repository, I don't know, Pagu, I don't know how to pronounce. However you want. OK, that we can keep that because it's much easier with the workflow because it's much less powerful, OK? But all that we need for documentation is there. So it's meant hopefully we can use it for some years. For what it's worth, Jolene, who's a lawyer at Red Hat, who is awesome, but not a coder, she's not non-technical, but she's the lawyer, right? And she found, so I convinced her that she should use our docs process for the new Fedora legal page. She didn't want to use the wiki. And she found Pagar too hard to use, but was happy with GitLab once you figured it out. She thought it was much, much easier. So that's my one other data point there. I think also, if we had a dedicated GitLab, we could configure some of it to turn all of that stuff off so we could have a much simpler, at least a section that's much simpler. But we have to figure out how to get to something like that. I'm sorry I'm throwing stream of conscious thoughts out here, but there's also, there's a stalled thing in GitLab where they are looking at having an ASCII.preview in addition to the markdown preview, which would probably help, but that doesn't seem to be going anywhere. But maybe that's something we could invest in working on. Well, as this Java program, ASCII.fx is it. They have some working, editing tools in the menu, like any text processing things. And they have a preview. And you can plug in your own CSS. So with some effort, we can use it for our own CSS at the party at the moment. Yeah, it'd be nice to have that added into the Git forage tool entirely. So I don't know, maybe if people do end up investing more in Pagger development, we could solve both of those problems and maybe make it have that preview. Well, nevertheless, before we go, I'm still on the trip to make documentation in Fedora better and to try hard to get it done. So although sometimes I'm a bit desperate about, I have to sleep at night and then it's OK. Thank you very much. And just a plus. Only criteria, so that's all. We'll come to see us. I don't have any PowerPoints for the next one. If there's any. In my computer, you see, I have the representation of the Google Drive. See, you want to use your old laptop. OK. There's no audio. There's no audio on your computer. No, no, no. There's only the GMA. This side. No, let me throw in my data first. Is Jose here? Yeah, I'm trying to show him how much. I'm trying to show you how much we have to work on. No problem. Yeah, I guess. And Jose is, I think, Jose is my friend. That's, I don't know. Jose is there. He's OK. He's certainly not going to be out there. He's not presenting. So you're? Jose is, maybe it's a part of the development of my computer. Oh, OK. OK, so it's fine. OK, so the next talk is going to be by Luis Bazan, and it's on the challenges and Fedora Latam in the Latin American community. So take it away, Luis. Send the game to your presentation. Remote screen. That's not a problem. Displays. It's just not detecting any external display. Yeah. What's around the back? It's here. Well, let's go use another laptop. No problem. No problem. Let's go use another. We're going to have Jimmie. You have this? Jimmie. Go ahead. Go ahead. Go ahead. Go ahead. Go ahead. What's around the back? Sorry for the delay team, the next talk is about Fedora Latam, what we need to reactivate the region. I think we need a lot of people in this side, maybe you have seen that side because you are one of the people in this side. Let's go Latam. Yeah, you know, some issues, but I don't know what happened with the old Latam. The next topic is about all the challenges we have in Fedora Latam and what we need to reactivate this region. You know, in the last maybe three or four years, you know, pandemic and other topics, I think it's internal topics, I don't know. I am not going to talk about that topic, it's not important, but you know, the pandemic destroyed everything and all the countries in Latam, Mexico, Panama, Argentina, Chile, Colombia, Venezuela and other countries, you know, disappeared maybe these two years. And you know, in the pandemic, any team can work in different, you know, events. It's not possible because all the people is locked in their house and in other sides, you know. But you know, let me open my notes because this is my first time in the vlog as a speaker, but I am ready for this. I think thank you, Justin, for giving me the opportunity to talk about Fedora in this conference, about community. And let me start with this. This is not a talk, this is maybe a discussion because we need a help. We need a help to reactivate the region, the Latam region. In this region, we have a lot of people in different countries and what happened in the past, the principal event in Latam is the food con. And obviously, the Fedora members know this event disappeared, is deprecating. We don't organize more food cons in the Latam regions. You know, what we need now, we need support. We need support, we need ideas, we need brainstorm. And this is why I'm coming with this topic in this session because we need help from all the people, Mexico, NA people, Justin, Red Hat, because one of the goals is, you know, in my mind, one of the goals is talk with the former ambassadors in these regions and try to come back with these ambassadors to reactivate country by country. I need talk in private maybe or in other sessions with all these ambassadors about what we need to reactivate this country by country because all the events disappear and the community extinct, I think, in the Latam side. You know, this topic was born from seeing how the Fedora town community has been disappeared and we are almost extinct. I miss my Latam region, I miss that. I want to talk with my people in Peru, Argentina again and Chile. The last week I talked with a former ambassador, one of these guys I think, I talk with Alex Callejas, I talk with Jose, I talk with Alejandro Pérez in Panama, Abdel Martinez in Panama, Luis Segundo in Panama, other guys in Peru, Alex Obiedo. And my question is, give me a feedback, what do you need to, you know, what is your feedback to maybe to reactivate the region? Because I am not the only member of this part of this team of this community and, you know, I need the feedback for all the ambassadors and this is what I get back, you know. I get back these answers, you know, I get carry-old workshops. The people say we need more workshops in Latam, packages, workshops, documentation, translators, localization, because the people need motivation. In Latam, the people need motivation. I don't know in the other regions what I can talk about in Latam. In Latam, if you don't give a goal for the people, the people don't feel, I need contribute to translate, but what I receive back, you know, this is a volunteer role, you know. You are a volunteer, this is a contributor, this is free, but maybe the people contributing to the community, but maybe want to receive something back, you know, maybe a motivation. I have one idea to this motivation. What do you think if take the people in the country A and send to the country B and the people in the country B send to the country A, you know, as maybe per event. Send people to Mexico, from Panama, send people to Mexico, to Panama, to Argentina and maybe create these workshops with these ambassadors. Not send all the people, obviously, you know, the budget is important, but send one ambassador the next week or the next event to Mexico to talk with the Mexico team and maybe learn about how the Mexico community, you know, grow these two years because Mexico, congratulations Mexico because you have a big community on your side and maybe the next talk is about that. And the questions are is how are we going to do it? How can we reactivate and improve our communities? This is two questions. One second and the answers. Let me list the answers in the screen. You know, the answer is carry out workshop packages, return to large LATAM events such as a field. I mentioned fears. I don't know if Brazil continue organizing this event, but I mentioned this because in this event in the past Fedora put stands and talk and networking with a lot of people, thousands of people in Brazil. Brazil is a big country. And other events, obviously, you know, we lost football, but what I can say when I say large events, maybe we need to create a new event for LATAM because FLOG, and sorry for that, FLOG is I think only for NAA people and APAC, EMEA, but it's really hard for LATAM people to travel to EMEA maybe sometimes, you know, maybe we need to create a new large event for LATAM to, you know, to meet with all these people. You know, this is the answers, the feedback from ambassadors. I think this is the most important answer from the ambassadors in LATAM. We need to create a presence, again, generate noise in all the countries. You know, generate, we need more noise in all LATAM countries with universities, I don't know, students, public events. In Panama, we have maybe, per month, some events in universities. We need to reactivate again the, maybe an ambassador program is there, but you know, we have, we need to reactivate again these ambassadors because the ambassadors disappear, I think. I don't know where is the ambassador now, but it's not in the countries disappear totally. I don't know, we need to talk with all the ambassadors. Some people mention other countries, Colombia, Republica, Dominicana and other sites. I don't know if you have the contacts for this site, please give me to start the communication with these teams. And how can we start? I think I jump all this slide talking, I mean, put, you know, click the next, but you know, I say this, we can start with me. I can contact each deformed ambassadors to see if they would like to resume activities. But you know, what happen if these former ambassadors not like to come back? I have other option, you know. The other option is, you know, after listening, you know, the other option is if the ambassador not want to come back because in the past he fight with the community, I don't know. We need to start communicating with the new guys in the Fedora community because we have a new guys, but this require take them by the hand, you know. These people need help to grow and to understand how create events and to understand other things, to understand the rules, the project, the code of conduct, you know. These new ambassadors need to understand all these topics because, and you need to explain this because, you know, to don't block the rules, you know, and to create a good events in all the, in the countries and in the universities, obviously we need swag, we need sponsors, we need maybe some budget. In the past, we worked with Fedora with a budget. LATAM worked with some budget. I don't know in 2023 the budget of LATAM. I don't know if Alex understand the budget of LATAM. You have the numbers of the budget of LATAM, no? I don't know today LATAM not have a real number to say, okay, we have this budget to work with all the countries. In the past we have a budget. We have a budget to work with all the countries and say, okay, this is for this country, this is for this country because we need money to create noise, to move events, you know, to create new events and maybe to create swags, to create banners, et cetera, no? Now, okay, I put the, I think the one of the next slide. Now after listening to all these, tell me how you can help in this room, I know if you have any idea to give to LATAM, to reactivate the region, give me the idea, send me the channel, send me the chat, ping me in any channel. I think I am on all the channels in Fedora, infrastructure, meetings, LATAM, Batch, Mindshare. I think I am in all the channels. Ping me and I need these ideas because we need, it's important for the community to reactivate this region. The region, we lost the region in the last two years and we need to reactivate. And if you have the ideas to help or to reactivate the region, please give me. No problem if you are from EMEA, APEC, LATAM, N.A. You are welcome to start help to the community to reactivate the region. In the past, the people from EMEA and APEC and N.A. traveled to the food cons in LATAM and helped with some workshops. This is important. We need external people to share all the projects from Fedora because we have a lot of projects inside Fedora, documentation, website, infrastructure, applications, developers. Wow, we have a lot. We need help to teach these people because now we don't have maybe how I can start, how we can start because we need to start. Any questions at this point, Tim? Yeah, please, go ahead. Question or suggestion? Merexuji speaking. I wonder what I've seen is that you said you need to be present on many conferences and start new conferences and a lot of stuff and more money and more people and it's like full front on, yeah, more people sending there and still the same way. I'm wondering why? Do you have some data for that? But just not criticizing or saying why. I can give example what we've done in Czech Republic in Brno. Rather than having big conference in many of them, we have one big in Brno, but that doesn't activate the community there. We are doing a lot, a lot of small stuff. Get courses at school, coding stuff at grammar school and high school. Packaging workshops for the people from the community outside. You are outside for a fair amount, but you want to create an R-Pin package. Let's come to this workshop. Summer camps, a lot of small activities which you can group, like meeting in the pubs and speaking about Python. Everybody buys their own beer and this costs you literally nothing, nothing but your own time. We have literally every week some activity which costs nothing and keep people pushing. You don't have this time this week, so what about next week? Come, this guy doesn't cost nothing, just your time. I think it's not a question, it's maybe a suggestion. For example, in Mexico, in the next talk, you are going to receive a lot of information of the Mexico community, but in Panama, I can talk about Panama. In Panama, we push the people, the universities, all the times. Obviously, we have some goals sometimes, because I want maybe some packages. I try to recruit some packages, documentation people translate, sometimes we need to translate the documents to Spanish or to other language. I try that in Panama with Fedora Panama team. I think Fedora Mexico do the same, but what happened? It's a good point. You don't need a big team. You need small groups and this group can broadcast and diffuse all the information. That part is perfect, but what I need? I need the same in Peru, I need the same in Chile, Argentina, because in the past we have this team, these are small groups, but this group disappears. Why? It's a large history. Sorry, Justin. Yeah, sorry. Yeah, thank you for that point. Lukas, Czech Republic. I wanted to remark that the situation in the Czech Republic might be a little bit different, because we are a small country. And if we have something called Pivo, for example, which is a development discussions regarding Python every week, I believe, in a pub, so people who are interested in Prague, they can hop on a train and they can reach Brno in no time and take part in Pivo if they want. And that might be a different thing in Argentina, Panama, Brazil, where there are distances big as hell. I think you could, however, move these activities online a little bit and share something online. I wanted, however, to remark something else. The previous talk said that it's a problematic to get people involved in doing Fedora documentation. And now we have problems to get people involved in communities, in Latham. And what if our bars are set too high? And I would like to explain. Sometimes I have the feeling that if there is somebody who finds out about Linux and he or she would like to get involved, then they don't know how to start. And when they start, it's not enough. They make a pull request, for example, and immediately they get a review which is full of, don't do this, do it differently, this is not enough. You need to learn this first. And then the people just lose their interest because it's too difficult to get involved. And maybe we should embrace attempts and we should just take it and maybe make it better. I wanted to say this already when the documentation talk was here, that maybe if people do not know how to make a pull request for documentation in Eskidoq, maybe we could accept an article written in library office and maybe we could find someone who is more experienced to convert it to Eskidoq and we would have at least that content if not the form. And maybe if we accepted, I don't know, talks, how-tos, articles, how do I use Fedora, maybe even if it's not 100% correct, maybe still it's worth to gather it somehow and to make it public and make it better over time. You mentioned a good idea. You say remote sessions, yeah? And maybe request remote session with experts maybe to explain about this good push, good merge, good... Oh, sorry. And it's a good idea to create these workshops. Maybe if the expert person, the engineer, the expert engineer from rail, Fedora, I don't know, is in Burneu, in Czech Republic, we can schedule a session with this guy. The people in Panama can translate your session obviously and we can do this session about documentation for example and maybe motivate the people in the university to start documentation, start translation, localization, infrastructure, but obviously we need the correct person to teach, to start teaching. Of course. It's always better when there is an expert teaching something. But I was a teacher originally before joining Red Hat and I think that for starters it's enough when the teacher knows just a little bit more than those people. So experts are fine, but also helpers are fine. And I think the good point about communities is that one expert could serve many, but the community can't exist without those helpers. And I think we need more helpers who just say, okay, I can help with this. Up to this point, I can't help any further, but then maybe it's not needed because those coming people, the newcomers, maybe, you know, very intelligent people. Yeah, and I mentioned that, Justin, we have a time? We have a time? Two minutes, okay. Please, Jose, share what you are going to say. Oh, yeah, thank you. Feora Latin, we must focus and we must focus on people. Connecting with the people is important to pay attention to individuals and establishes connection with them. Maybe, in this moment, no. And we have to tell them. We have to tell them. Okay, yeah, you know, we need to pay attention to all the people in Latin. You know, as humans, I know. And, you know, this is the moment we need to start, I think, to connect with the people to start to involve with the people, to involve with all the guys and then start a church, you know, all the things, all the topics, all the workshops, etc., I think. This is what Jose tried to say to the team. Let's go. I'm going to create this week with Kevin Felsi. I'm going to request the Latin channel in Matrix. Please, join to that channel. I receive all the ideas. I want to talk with you, sir. Maybe to this. Yeah, just a few things to remind me of her email. Perfect. What the channel is created. Ah, your Santos, yeah. Santos Kiwi. No, Fedora Kiwi. Fedora Kiwi, okay. Yeah, let me thank you. Thank you for the time and thank you for the opportunity just to talk about the Latin region. And that's all, team. So as a quick note, it is now lunchtime. We'll have lunch served in the suite upstairs just before the meeting room. So go and get yourself a seat and a bite to eat. Please give a warm welcome to Isaac Schultz, and he's going to speak about Riscuit for a Biscuit, Linux on Risc 5. Oh, I don't need a second microphone. There's one there. I'll be for question time. So I got a few questions and I'm going to ask first. And you can hear I've got a fellow very singing voice. That's because I'm from the city and we're noted for, we sing, we don't talk. And when we get excited, we jump up two octaves. All right. So Sharra Hans, where's everyone from? Where you from? All right. So how many Americans have we here? Okay. All right. How many Europeans? Rest of European. So we got a Czech Republic. Anybody else? Poland, India. All right. Czech Republic. Who's Ireland? Ireland, mother Ireland. Hey. Up the rebels. Oh my God. We got a car corny, a fellow car corny in here. I have to be very careful now because everything I say will be fact checked in the room. And over in the corner, 10 miles away. Panama. Ooh. Bono's got some money in the Panama accounts. I'm sure we'll all be interested to hear about that over a few points. Anywhere else? South Africa. Via Dublin. All right. I'm just testing. Just see what my audience is here. Anybody here has done assembly programming? It's not mandatory. Actually, this is... I'm actually pleasantly surprised. That's kind of cool. Let's see. So if you done assembly, then you know what an X86 and ARM processor are, right? All right. Okay. Good. And let's see. I'm assuming I know there's a few hardware enablement people here. Hardware enablement. Linux hardware enablement. All right. Does anyone know what CISC architecture is? Okay, we've got a nod. We've got a hands. I think it'll become explanatory when we go in. And here's a nice one. Here's an Irish one. And the Irish beat. The dobs need to tell me the answer to this one. Indianism. Anybody here know what Indianism is? Okay. Does any... So... Not as many as they expected. Do... So Indianism is about... if you take the 64-bit or 32-bit register or address space, and the CPU starts on the least significant bit to do its calculations with little Indian. And on the greatest bit, the highest bit out for big Indian. PowerPC traditionally used to be big Indian until they changed about four or five years ago. And X86 for quite some time has been Indian. I don't know how far back that went. But does anyone know where the word Indian... the term comes from? From? Hey, we got a winner, winner chicken dinner. All right, you're going to get this. This is my only prize. It's a pair of risk socks. I'm fashioning them today, and you know, you can see. I mean, I'm on the catwalk. Right? Here's your... Here's your risk five socks. Indeed, the answer is the term Indianism came from Gulliver's travels. And there's an Irish connection. Jonathan Swift was the dean of St. Patrick's in Dublin. And he wrote Gulliver's travels. Right? Okay. And amazing that the term comes up here. Another one I should say is, does anybody know who George Boole is? All right. We'll teach you about George Boole in a second. All right, we're here. We're in Cork. So it would be neglectful of me and my fellow Cork warning. That was a few Gaelic words. I mean, we're here. We might as well use it, right? So forgive me the people that are 10 miles that way. But it seems the majority of people are here. These are Cork local places that you should try and visit while you're here. The English market is a wonderful covered vegetables, meat market, fish, et cetera. Shandong is, if you look up the hill when you're downtown, you'll hear bells and you'll see it. It's worth a visit. You can go up to the top of it. And you can actually ring the bells. They have the tunes written out in numbers. So you can ring tunes on the bells. The Kool K is a very famous outdoor trading spot, like a flea market, and has been there since before my dad was born. My dad was born in 1930. And you'll notice that it's Kool K, not Kool Kwe. And when you go down to the water here, we don't call those Kwe's. We call them Kee's. So when Paul Cormier and company call Kwe Kwe, they're mispronounced in the term, and that includes the guided invented Kwe, it actually is Kee. And it fits in right with the whole docker idea, because a Kee is where you dock a boat. Docker? Or should I say docker-like? Right? A lot of history there. Murphy Stout. We got a bit of time. Murphy Stout is our equivalent here in Cork. It's as good as Guinness, if not better. Right? So have a pint of Murphy Stout. Our favorite drink is Tanura. Isn't that right, Aiden? Do you want to tell me you're a Beamish, man? Oh, Jesus, he drinks Beamish. Beamish is very, very bitter, bitter, bitter. The kind of is. Murphy's is just as good, if not better. Right. We'll have a revolution here in a minute now with the Dublin people against the Cork people. So Tanura is a tangerine drink. You can only get here in the, we call Cork the real capital of Ireland. It's an ongoing joke. But it is really the real capital. And this is our coat of arms over here. All the best whiskeys in Ireland are made in Cork, in Middleton. Irish distilleries. That bottle there will set you back probably about 200 euros. And crunchy bars are my favorite, crunchies are my favorite chocolates. They're not exactly Cork, but it's rock toffee. In actual fact, a crunchy bar is rock toffee. You could actually get rock toffee here years ago. And here is George Boole. I'm bringing it back, you see. He was met it in the madness to quote the immortal bar. George Boole invented what? Bingo. Boole and algebra. And as we know, all those ones and zeros are the reason why we're sitting here. Right. Which feeds back into the other thing called Indianism, et cetera. Right. George Boole was English. But he was the professor of mathematics in my local university here, University College Cork, my alma mater. And he had a townhouse in the city, which a friend of mine used to live in. So I've been in and out of that house, and it's been renovated. It's a beautiful house. And he had another house down on Black Rock. And what killed him? Literally, the Irish weather killed George Boole. I don't even think he was 50. He walked from the college one day to his house in Black Rock, which is probably about two and a half, three miles, maybe more. It rained, and it rained so that he got so wet, he caught a really bad cold, and it killed him. So the founder of our Booleian Algebra kicked the bucket because of the Irish weather. And the Irish weather is one of the reasons why you don't live here, because I can't stand the rain, just like Tina Turner and a few other pop singers. I can't stand the rain. In the middle, the bottom is the Cork coat of arms. And there are two castles, one at either side of the lee, and the boat's coming up the middle. So it's a nautical town, and if you're not used to high tides, our tides here are more like Canada. They're very, the low tide and the high tide, there's a huge difference, anytime of the year. Unlike in Hawaii where it's like maybe three foot of a difference, here it's probably 25, 30 feet, maybe more, depending on the time of the year. And if anyone has problems understanding me, just kind of, you know the way you get someone to slow down? Just go like this, because when I'm home, now that I'm home on my native surroundings, we talk really fast. You know, it's the whole little Indianism kicking in on steroids. All right, risk it for a biscuit. So let me say who I am. My name is Isaac, last name is Shute. It is a very uncommon name for anyone from the city. That's been honest. So I was sticking out like a sore tongue from an early age. I actually went back to college at a late age. I had gone to university with a seminary, decided that I wasn't going to be a priest, and eventually went back to college and graduated here in Cork. I did computer science in Italian and loved every bit of it, got into computers, and I remember there was one course in computer science that always resonated with me. And actually, Aiden, where did you go? Did you go to Regional Tech or to UCC? UCC, on the ball. I don't know if you remember Johnny Vaughn. All right, so there was a professor up there, John Vaughn, and he used to do the 8086 architecture course. And if I look back in it, it was the only course that I still remember to this day, where we went into... and we did some assembly. We went into the architecture itself, ALU, CPU, registers, pushing, pulling, blah, blah, blah. And it gave me appreciation, translation buffers, et cetera, gives virtual page memories, et cetera, paging out. It gave me an appreciation for the complexity of the hardware, and I felt like from a software engineering perspective, it was like that Michelangelo moment where the two fingers meet in creation and it was the electricity between the two fingers. That's the hardware, where the hardware and the software come together. The rubber meets the road. And a lot of people have no appreciation for that space. It's not really taught very well, and a lot of people, especially today, all our software layers are so abstracted away upstairs, very few people get to dabble deep down. And risk it for a biscuit. I have to explain the term for people that are not native English speakers, because I want to be cognizant of that. I'm not a native English speaker. I'm a Carcogonian. Get a laugh out of Eden now. Risking something for something better. So take a risk for a bigger reward. And risk five truly is risking putting a bet on the table on something that's worth putting a bet on, because it's going to pay off. And let's see. Okay, here's the complexity that we're faced with. Probably not what you thought would be the first slide. So for 11 years of my life, I managed the hardware enablement team, we say a team of program managers that interfaced with all the silicon vendors IO adapter vendors, graphics card vendors, NVIDIA, etc. Intel, AMD, ARM, the server vendors, so the HPs, the Dells, etc. And trying to figure out how do you enable rel, Linux, sitting on these multitude of adapters and hardware componentry, and how do you light them up and bring them into the fold. So that was an interesting challenge because at the end of the day, it's great that we all have our favorite little part of the equation that we play in, but without a healthy software ecosystem or applications that do work that customers actually need to do the work and solve the problems that they have, no matter what we architect or what solution we create, it's actually, it's irrelevant if it's the best solution on the planet and there's very few applications running on it. So from the get go, we're kind of looking at risk five and this is one of the reasons I was hired to, you know, how do we have the most vibrant, healthy and healthiest hardware ecosystem and software ecosystem enabled for our customers. So the customers have choice and it's a challenge. And I have my own, this has been recorded, so I have my own thoughts on some of the past history of events, so I'm not going to malign some of the guilty parties, but we've all learned lessons through our former silicon-enablement relationships that will help us do things better this time around. I'm hoping. All right. So this is just a very quick recap for risk versus SISC. So the risk in risk five really stands for reduced instruction set computing, ARM chips or risk chips, digital Unix used to run on alpha, that was a risk chip, PA risk. So then you've got SISC, which is complex instruction set computing, Intel x86. And the primary difference really is that as you do a cycle in the CPU per clock cycle, a risk machine would execute one instruction per cycle, whereas a SISC processor would actually take a few cycles to complete an operation. I'm sure we could get some zealots of Intel that would probably disembowel me and say you're completely wrong for this reason, this reason, this reason, but the fact is that as a result, risk is a little bit from performance better performance perspective, right? So risk five, yeah, there was a risk one, risk two, three, four, and now we've risk five. And one would say, well, so what? Well, it speaks so a lot. Risk five, and for the non-native English-speaking people, so V is the Roman numeral for five, and we just say risk five as opposed to risk V. This is about as close as you can get to open source hardware from the perspective of open source CPUs. Which is, it can be misinterpreted. So remember, open source is free, free access to stuff that you can do something meaningful with, but it's not like free beer, right? You've heard like free speech versus free beer. The fact is that we have an ISA, so it's the specification itself for how a risk five chip should behave and operate is available for free. And you don't even need to be a member of the risk five international foundation in order to create a risk five chip that's risk five compliant as long as you adhere to the specification itself. Now, if you want to help evolve the technology and help evolve the specifications, then you become a member of the organization. From a company perspective, Red Hat's already a member, all the Big Wigs are members. You could, and that costs a few Bob, but we leave that up to the CFOs and these companies and the CTOs, they can make that decision. From a personal perspective, there's nothing stopping anyone being a member on a personal account basis. So it's an open source community and from that perspective. And people can help correct, people can have suggestions, et cetera. So unlike X86 and ARM and all those many... I won't say fails, but historical sunset CPU chipsets and chipsets, they had closed source ISAs, so you would have to pay a license to get access to the design. Now, Sun Solaris, I will have to give an honorable mention because our CTO used to be at Sun, they open sourced all that jazz as well at one point. So this is where risk five... Ah, so if a member can a member create something that's closed source for them to use. So in theory, you can have your own private extension that you would use. But then the onus is on you then to support that and you need to get an operating system vendor to support that extension as well, right? From an embedded perspective, of course you can do whatever you want. It's all self-support anyway. Great question. So again, if you were to go to ARM tomorrow and say, hey, I want to change the design, I want you to change this and change that, they'd say, I don't know if they'll do a private contract which you wouldn't do that change, but it's going to cost you a lot of money just for the privilege. With risk five, that whole specification is free and open. So again, here's where the free and open verses expense. If you're going to try and create a chip, based off the specification and adhered to specification, of course you're going to have to have the infrastructure to do that and you're going to have to have a contract with a fab unless you've got a fab in your back pocket which very few people have, other than Intel and TSM, et cetera. So the expense of making the chip is still there. So there's no free lunch in some respects. Yes, the code is available, the descriptions available, the specifications available, just like open source code, but when you start to create a product, there are expenses associated with creating the product, but still it's a lot cheaper to create with this new architecture than it is with historical architectures because you've such an overhead with regard to how much the tech, the IP is going to cost you upfront to begin with. All right, so there's the concept of ratified specifications and then there's continuous evolution where we have the specification continues to evolve, right? So we've got two primary specifications. One is think of it as the unprivileged specification is for, you know, user mode applications and then you've got the privilege specification which is for machine mode, supervisor mode such as operating systems need and hypervisor, things like that. And of course the privilege specification inherits a lot of the stuff that's already in the first spec to begin with. And there is a link in there, I will make these slides available so you can see that there's actually another deck available with regard to the unratified specifications. And will I say it as a camera? Maybe. It's a very long, slow process to ratify specification, but you know, people collaborate, create a specification around a specific thing and then there's a window where that's publicly reviewed and then it's frozen and then that makes its way into the specification hey this is the latest version of the spec and then of course there's another variant that's going to be hey, we're now working on these other things. So I'm going to hit the Diane Harser open standards and collaboration I mean open, open, open, open just like open source software this is open, open. And last time I looked Linux Foundation was a pretty open organization in place to work which is kind of cool. However, here's the kicker. So for those of us here that are not American a lot of countries are kind of sick and tired of being beholding to America because it's got the crown juice of technology and IP for technology. And countries like China countries like India which is a pretty big country Brazil the European community they want to have choice and technology choice and they don't want to be completely dependent on an American multinational for that choice, right? So as a result this geographical kind of diversity aspect bleeds into the risk-vive equation where all these entities are extremely interested in risk-vive enablement which is really cool. We're on a voyage that's pretty unique and to prove our neutrality the foundation is actually registered in Switzerland these days I won't give you my private ideas around Switzerland and neutrality. I've got some interesting ones for over a pint. Let's see. I'm going to check the time. This is stuff we can read. So you've got the European community have you even got Intel? Did ARM have Intel when they were trying to enable their technology? No, but they didn't. In actual fact there was a lot of friction let's say in the community and elsewhere. So we've got Intel. I'll give kudos to Pat Gelsinger and actually I met Pat Gelsinger one day it was the day after he was hired at EMC I bumped into him at the coffee station and had coffee with him really nice guy but I did find it peculiar that he still had on his website that his desire in life was to be the CEO of Intel. I guess he got his wish. So Pat has decided to kind of make separate divisions with Intel and have Intel also be the foundry of choice for chip vendors so that if you're a startup you can actually get Intel to create your chips whatever shape or form but they're big into helping enable the risk 5 market which is cool right? There's a little thing here about España por favor ellos they are very much interested in this technology as well as is Brazil there's another project called RISE and that's helping focus energy across multiple companies across the industry to enable the software ecosystem and accelerate the adoption of risk 5 so we've got a lot of wind in our sales so to speak I think you can read this one this is more of an architecture slide I'll get killed for saying that I'm sure and like the open standards is a big thing for us toolchain is interesting so when it comes to compilers and it comes to debuggers and libraries and tooling in general on the toolchain side they actually need to be enabled with the extensions for risk 5 in order for that extension to be supported so it's kind of interesting that it's not just the operating system supports the chip it's like the toolchain itself all the individual components of the toolchain have to be able to support the individual components of the technology so it's important for the operating system then in turn to take advantage of various extensions so as you can imagine there's a multitude of extensions so there's a multitude of timelines associated with each of those extensions some are frozen some are already supported some are about to be supported for instance in GCC and I'm actively tracking them and other people as well to see where are the gaps are a really cool slide I'm not a fan of architecture at times but sometimes you get one and you go like wow, gee whiz Batman this one catches the imagination so if you look at the graphic and you look at the projection they're projecting at the end of 2025 nearly 80 billion risk 5 cores shipped that is phenomenal it's daunting now of course when it comes to enterprise computing this is the edge of the iceberg because they're starting with risk 5 and embedded type devices small edge type devices and then kind of bleeding into bigger and bigger and bigger as you come up the hardware stack some performance benchmarking material of course performance is an important thing and I would be what is it that is not negligent or even misleading if I actually said hey you know we're the best performing thing on the planet we're getting there that's what I can say we're getting there and I've given my experience with ARM enablement in the enterprise compute space I believe we're about 5 years ahead of where ARM was at this moment in its evolution within the enterprise compute space which is again an interesting moment in time there's a lovely slide lots of partners lots of software partners application vendors, runtimes operating systems that are interested kicking the tires Debian came out the other day saying they officially support risk 5 as an architecture Ubuntu already officially supported as well canonical of course we've got Fedora support as well and over time as services start to come along with the CPUs in the enterprise servers then the natural evolution is that Fedora then sent our stream and then into REL as we continue to kind of make progress and likewise with OpenSUSE likewise with ARM and Linux et cetera hypervisor support extremely important and I would add that the sweet spot is the question I'm sure Troy and others are asking when will the technology be ready for enterprise compute and it's kind of a chicken and egg because it's like when will the CPUs be ready when will the box vendors such as HP and Amazon and Nvidia and others be ready and what's that kind of moment in time where it all intersects and you don't want to start the work of enablement at that moment in time you want to start maybe three years ahead of that which is why I'm standing here in front of you today alright not a good slide there's a risk membership link here if your company wants to join the risk foundation the risk by foundation there's some more information in there as well and extensions and here's a concept so the only real mandatory extension is the integer extension can you add can you subtract et cetera everything else has to be an additional extension so there's a multiplication integer multiplication and division M the atomics A you got the various floating points F D and actually you can add floating points somewhere it's on a different slide and then there's compression et cetera these extensions are what add which they extend the ability of the CPU itself the SOC to do additional things and in theory you can have a multitude of chip designs that will just do very basic stuff to very complex stuff including all the memory management that we're used to at the high end from an enterprise compute perspective but the fact is that you can actually design chips to do all of this very little or a lot so you can imagine you can have customizable chips we're not expecting rel to be running or fedora to be running on those heavily customized chips with reduced instruction sets et cetera that wouldn't make much sense and there wouldn't be much of a business case for that however we will expect all the distros not expect we hope and we petition and request that all the the main Linux distributions work with us in enabling RISC Vive their distros sitting on RISC Vive of course some of that is working upstream with the Linux community itself and then have the platform available so that the box vendors can consume it and the kind of the whole ecosystem starts to build out a little word on profiles if you're not up the speed on profiles it can be a little confusing and the one I draw attraction here to is our last major profile was really rva20 and we're talking 64 bit not 32 bit we add in additional extensions as they get ratified over time hence you got rva22 23 so there's additional things that kind of come in with the new specifications and when things become hard and available and then of course the future there is a rv128 not sure how far out that is in the event horizon oh and more importantly let me see go back here there's a link here to a great profile document on github if you want to overindulge yourself and if you need to sleep some night you've got insomnia and then of course we've got the hardware platform definitions for RISC Vive that work is starting this year and that will start to kind of evolve that is probably something that will be really interesting to the folks within the distro space right this is the decoder ring you're going to see many variations of this but for intense purposes you've got rv is RISC Vive the second or the third digit here can be an integer I or A application the 23 is the year so it could be 20, 22, 23 U that one is it can be privileged privileged mode itself is it user is it supervisor and then of course at the end you've got 64 so you will see some of these names are 32 at the end you're not going to be interested in that but the 64 yes and rva 20 S 64 is probably the one that's of most interest right now from a Linux distribution perspective and as we get to ratification and evolution points probably be 20 that rva 24 will probably be the next one that will be of similar importance and again so I didn't want to use the poster that they had in World War 1 for recruiting troops we need I need you but we need you as part of the community and the extended community to help us enable the ecosystem is pretty complicated on the one hand with the tool chain which in itself is a pretty complicated world and has to be enabled for risk 5 on the other hand and a lot of the tool chain is available so GCC and the debuggers LLVM etc they're all available today and they're all enabled and there's some residual work that Seedle needs to be done but the good news is the work is getting done however then you look at it and it's like okay I'm a customer I'm going to mention probably a customer a partner whose name may not be appreciated but for instance Oracle right Oracle is a pretty important player in the database space and it's like well Isaac when is Larry going to actually trust you to put his stuff on it well you got this whole stack here and we got to have the stack in place so we need so you got the socks themselves who are the sock vendors that are going to be creating enterprise socks who are the box vendors that are going to be consuming these socks then you've got oil adapters, yeah you can have probably arm adapters x86 adapters but you're going to have native adapters as well and upstream drivers and box drivers etc so you've got the most important part of the equation where are the operating systems and of course when you think of operating systems today you're thinking of what about VMware what about the hypervisors Hyper-V what about AWS what about Alibaba what about all the major regional hypervisor players and then of course you've got Microsoft Docker and everybody else so that all needs to be coordinated carefully so we can kind of from a cross community cross company perspective enable the architecture so that Larry and others Larry's customers can actually fully embrace and adopt the technology it's not going to happen overnight but it's going to be a walk run but the good news is that we're well on the way and we definitely have the wind behind our sales right now and there's a as I said I feel like we're five years ahead of where ARM was at this point and I couldn't tell you where we're going to leapfrog ARM from the technological perspective but it is going to happen and it's a pretty exciting space but we definitely need the Linux and again RISC5 foundation is part of the Linux foundation and we want to give customers choice of platform, choice of solutions give partners choices and help enable a more competitive architectural landscape so let's see this is just the life cycle thing that we were discussing earlier and for anyone that really loves iCharts this one is the best one I've ever seen it's the RISC5 reference card this gets into the arithmetic stores loads memory management and a whole lot of other stuff which is fascinating probably for John Masters Redbeard but for plebs like myself probably a little bit too much there was a song back in the 80s called the future is so bright I gotta wear shades if I was in a country where the sun was shining apparently global warming is making it the warmest time of the year the warmest, July on record in the planet in most countries Ireland just had the wettest so there's no point in wearing sunglasses but the future is so bright I gotta wear shades RISC5 is going to grow up into all these environments that we've known and loved for so long and we rely on everyone's assistance and help from a community perspective to help bring this out into the open to birth this technology and I'm looking forward to work with everyone on it so any questions no I didn't say what languages we're going to respond to ok I have a lot of questions actually the first one is you told us about RISC5 well performing I won't argue but what about the power efficiency I mean you know because when we calculate a lot of things we calculate in the long term how much power it will consume so do you have any benchmarks like power instruction per watt this kind of benchmark you know I'm sure there are and you're going to give me your name and your email and I'm going to get you the data because I don't have it off the top of my head because you know our intent is to be as competitive on the power envelope front as ARM is the day and power in green is kind of an interesting one because even the high end CPUs from AMD today they consume a lot more energy but because you need a lot less of them to do your work you've gone from two racks of systems to a half a rack of system consuming less power so the power equation depending on who's writing the white paper can be misleading but our intent is that it's going to be as competitive and competitive with ARM's power envelopes actually it's called performance per watt the other thing is that Linus Tor was actually said that I agree with him that in order to get the new architecture to become very competitive you need the developers to have the boxes and I agree with him for me personally I started using ARM as my workstation because Apple created the Macs and it was much easier than spin something on AWS or use Raspberry Pi that well sorry it's not good enough for serious work when you compile a lot of things so do you know any workstation for developers with RISC 5 that you can recommend or say that I have very same problem with PowerPC because very similar to the Tegels and getting it you know was very hard with ARM event but it's very popular I waited like the half year to get the proper equipment and how it works when it comes to the RISC yeah so so those offerings are coming from partners right I'm not aware of the road maps but I do know that for instance there has been a laptop that has been shipped with a RISC 5 chip in it already which says a lot in itself actually I'm curious how many people do we have on line right now because I'm wondering if there's some of the partners on line if someone's monitoring that they may have an answer and I can repeat it once we have the answer in because I know there are partners on smart when I asked any more questions okay sorry ah so the 16 bit compressed instructions it's like ARM's some right I'm sorry I didn't catch that so you were talking about an extension for 16 bit compressed instructions it's an equivalent of ARM's some feature or the compress yes and a more practical question about well helping RISC 5 so suppose I compile the binaries of my project for RISC 5 and it doesn't exactly work as I expect so what's the best course of action to find out why right now because there are so many possibilities now that it's the whole stack is still a bit experimental in compilers, in Linux kernel and so on I would be lying to say I have an answer for that question so we have people on the team that look after that set of things and you're going to give me your name and I'm going to follow up okay you got my word I'll leave you in the back sorry because I certainly won't be debugging it with you I wish I could what boards do you recommend for like RISC 5 development like single board compilers or like an FPGA alright so if I'm not diagnostic I kind of have to leave that up to people to choose from the existing ones that are available and I'm not being flippant it's just like I have to love all my children equally I love SUSE I love RHEL I love Fedora I love Ubuntu and I can't suggest one over the other or choose one over the other but if I'm wrong there's some milk boards available what's up yeah I'm just going to search it up okay Tomasz we got this chap here waiting patiently thank you I think I noticed that on one of the slides but I have a question are there any extensions to accelerate cryptographic yes vector crypto what about post quantum cryptography that one I'd have to check but vector crypto has been heavily worked on right now okay thank you hi first of all great talk so thank you for giving it and for my question I thought it was really interesting kind of the membership of various countries or organizations across the world within risk 5 when you talked about I don't know a better way to say this democratizing access to developing hardware which is predominantly or at least historically but in the US when thinking about these partners are there specific applications that they are looking into developing using risk 5 is it more about creating more consumer oriented devices that they have control over the manufacturing pipeline or is it more around servers and stuff like that I was wondering if you just I think it's more from a government perspective and you know you think a lot of governments are like one big huge company and they have to purchase a lot of systems and they want to have the choice and they don't want to be totally dependent on one specific geo for the technology you can imagine it's a bit like I mean oil and the Arab countries and the US is a similar conundrum and Russia where a country like Ireland for instance we don't have any oil it costs the scenario I would like to get it and we are dependent on all those countries so from a technology perspective it's a similar analogy where having the ability to use these in your own geo that have the technology in the geo that they're not dependent on somebody in Redmond or Seattle or Silicon Valley for choice is always good choice and open they're my two favorite words so how far is the development of PCI based extension devices things like sound cards graphics devices has come for this instruction set it's a work in progress and it's an extremely important part of the equation right exactly double or no sorry it's probably a stupid question but no such thing what level of technology regarding the chip manufacturers does this actually need like are you still relying on like Taiwan semiconductor or unless you've got a few billion dollars to create a fab you are but you got to remember like Taiwan semiconductor they now own I know it's like 75% of those new lithographic machines that come out of that company in Holland and Intel has a ton on back order but they have nowhere near the same amount of systems for anyone that's interested yeah you should look it up I can't remember the name of that company in Holland but it's almost like a photocopier with gas that's the best way you can describe it and it's able to create the blueprint on the silicon and they can do several layers and layer on top of it which is just mind-boggling or the gas comes from Russia I think it comes from dilayeron that's actually a local joke there are politicians a lot of hot gas a lot of hot gas like every other country any more questions and so on is it a standard like reference design of a south bridge right now or not sorry you're going to have to repeat I apologize is it a standard design for a south bridge for risk 5 south bridge yeah south bridge that one I'd have to look into I don't know that's been honest we got another one from the yellow submarine okay last question yeah okay so I had a problem for example I needed the necessary virtualization on ARM and it came with one of the version like 8.5 or something I get it doesn't matter because right now I believe there is no necessary virtualization in risk if it will be how would it look like and when I can how can I check there is some kind of extension it's in pipeline you mean a hypervisor extension yeah yeah but yeah you have a hypervisor extension but this is like the first layer of virtualization in most cases but I need the second layer and because and I like you know to have virtualize virtualize on VMs necessary virtualization which I don't think rel actually supports the day rev depends on the hypervisor but generally so there are two virtualization serums and if the extension is compliant with the serums I can show you later then necessary virtualization is perfectly doable and actually it works at least in some cases but on risk 5 it's of course a question for the risk 5 team very cool and ARM isn't quite there yet on virtualization so the intent would be that we're going to leapfrog ARM probably on virtualization okay last question anybody over here alright so just to finish I'm just going to give you a quick a former opera singer and this is our local song that blow down the mardike to each ellen tree where we sported and played need the green levee shed on the banks of my own lovely lee where we sported and played need the green levee shed on the banks of my own lovely lee lovely lee up the rivers that's a song about our river the river down here the banks of our river we love our town alright thanks folks those of you that I want to get names off of names badges and serial numbers I'm going to just come over here and we're going to write it down alright thank you thank you Isaac so we have next session coming up in 4 minutes thank you very much see you again Okay, so it's time for another session. Okay, I'm serious, we want to start next session. Please continue the discussion but outside, thank you very much. So the next session is presented by Sandro, it's about neuroscience in Federa. Please go ahead. Let me correct that a little bit. I'm not a neuroscientist, like many of us are not lawyers, I'm not a neuroscientist. This is a collaborative effort, the presentation has been put together by Ankur Sinha, I hope I pronounced his name correctly. He is London based and he was not able to get a visa to leave the island. So I'm doing the presentation, Lewis is a backup as well, he's in the audience, so you might see his name on the slide as well, indeed I'm Sandro, let's go. This is a talk primarily about use cases of Federa and in that particular case, the use case of how to use Federa for neuroscience and that all comes together in the neuro Federa special interest group, which maintains a whole bunch of packages aimed at neuroscience research development. Neuroscience of course is about the brain, this is what neuroscience primarily focuses on the research regarding how our brain works. This is what you see now is quite an interesting picture, it has a lot of figures, it's mind boggling to think about how much is going on in our head and what we are able to do with it. These slides are from a previous talk in 2019, but they are here to remind us of the challenges that neuroscience is facing. These are only large brains, we now have a full description of some invertebrates like the sea, elegance and the leech. Neurons are complex, different properties give them different electrophysiological properties. For example, complex morphologies mean compartmentalization of current different conductances, capacitances and so on, that's basically what the research focuses on, the conductivity of these things and stuff and what to derive from that. Passive and active ion channels whose activity can depend on the potential difference across cell membrane. Inputs at different parts of the tree can cause the neuron to behave differently. More and more information suggests that the Giler support cells play an important role in neuronal signals and learning. The most recent estimate puts the number of neurons in the human brain at about 86 billion. Neurons in the brain are diverse, you see a few examples here of what they look, makes for a nice wallpaper, put it up in your bedroom. Here we show different morphologies, but they also differ by other parameters, protein composition and so on. Thousands of connections between neurons, each neuron connects with thousands of other neurons forming a massive network, so the brain can be thought of as a massively parallel processor. This is basically what the research is aiming at, what we want to get to know among other things is how the brain functions, the physiology, how it is structured, the anatomy, structural connectivity and also the chemical compounds that are involved. Of course also how we process information, basically that's this kind of physical computation about behaviors and cognition, that's all different areas of research that are going on in neuroscience these days and it's ever evolving, this is really a fast moving field in science. This is of course not just to know how it works, but there is also more, we want to, neuroscientists want to see whether they can prevent certain diseases or whether they can treat diseases and it also serves as a brain inspired computing, say like we look at nature, we copy it and we make it better and in that regard there is also something to be learned. And of course what is consciousness, that's another subject and to take applications from the extreme ends of the spectrum, immediate clinical applications, immediate technological applications, these are the two extremes in the research field. We move on to the research pipeline, like basically how is the research done and the research general workflow can be broken down as follows. The four basic categories, the ground truth comes from observing the brain directly at whatever level of detail is appropriate. One can look at the synapses and synaptic vesicles, the micro structure of what makes a neuron, the channels, pumps, the whole detailed cell or just the voltage difference or the current or a network of neurons firing or at high levels with EEG and MEG and other signals and one can look at FMRIs, all at different levels. All this produces huge amounts of new data data that must be analyzed, it could be fancy MI and deep learning techniques, standard statistical methods, information theory and so on. Experiments can control for everything, neither can they observe everything. From the observations and predictions made by experiments, theorists and modelers create models where they explore other parameters to make predictions about them. These models need to be validated against experimental data. Finally, the predictions made by theorists and modelers provide new hypothesis to inform future experiments. Let me just move on one slide. There's more coming in, I might have moved into that already, but that's okay. It's not quite a cycle though, usually we jump from one to another as required. But there's more, there's funding, there's collaboration and project and finance management, there's development of tools, both hardware and software and chemical and genetic, required to carry out all this work. And finally, the results of research must be peer reviewed and published and ideally disseminated to a non-scientific audience through sun markers, news, podcast, blog posts, social media and whatnot. Science can be thought of as a small scale non-profit industries. So where does the free and open, as we know from the software coming in, there's a free and open science as well, it applies there and applies certainly to neuroscience. This I think is the, at least for my part, since as I said at the beginning, I'm not a neuroscientist, so I'm reading here mostly what Ankur would be much more suited to explain. But this analogy actually I find quite interesting. Free and open science means everyone should have the freedom to share, study and modify scientific material. And in free and open source software, everyone should have the freedom to share, study and modify software seems to me almost identical. And this includes all research related activities, tools and output, not only source code. And free and open science implicitly includes and relies heavily on free and open source software. These go hand in hand. This is a selection of tools that are being used in open neuroscience. There's a link if you want to look up some more information. A majority of the tools used nowadays is free and open source software. The exceptions, yeah, the exceptions is usually the hardware that relies on corporate patents and or tools such as microscopes which use lasers or lenses which are developed commercially, FMRI machines and so on. So the hardware is not yet open source but most of the software has meanwhile moved on to open source. That brings us to the question, what can we in Fedora do to help? Yes, various specialties, biologists, mathematicians, physicists, chemists, psychologists. The pay and software development industry is higher in general than in academia. Also career paths for software developers in academia is not clear. A small proportion of trained software developers works in academia. It's a limited time, they have limited time, limited funding, limited resources. They do it because they love what they do. Sounds pretty similar to what we do in Fedora. The code quality is usually limited as well because it usually starts out as a hobby project and then evolves into something larger. Therefore the best practices are not always well implemented. Testing is not always carried out thoroughly. Maintenance can be flaky, depends on the type of software. Sometimes people lose interest and then the software decays slowly. And stops working eventually. There's usually complex dependency chains. Software depends on a lot of other software and then the cycle basically starts again. If one of these components is not being maintained, this could be a problem for some other software which stops functioning correctly or functioning at all. Action and support is not always up to the standards where people would like it. And there's a lack of know-how in how to develop software. This implies and this is based on anecdotal evidence that the software used in research is not the best quality. This comes from Ankur who has experienced that himself in his research. This means there's a waste of time and effort. Software is not always up to date. Some of that is still running on Python too. I do a dare say, do we have that in Fedora? Yes, we do. I won't name it. Most of you are using or still in touch encountering Python 2 software. If you picked up your badge today, then you made use of some Python 2 software. Developers in the academia, the scientists are not always aware of helpful development tools. They tend not to use them. They rarely run test suits at all. It's actually been improved. I see a lot more packages in the new Fedora ecosystem that has extensive testing. And it sometimes takes quite a while to run. Posts are not always reported and patches are not always supplied upstream. And if correctness of a tool cannot be verified, how can the correctness of the scientific result be claimed? So that poses a problem for the scientists and for the research, because you need to be sure that what you are presenting in your paper is actually correct and that people can reproduce it and verify it. So what we do as the neuro Fedora SIG, we liaison with upstream and with users. We do that already. We try to follow best practices in software development. For example, the tools used to build certain packages. It's just a string of scripts that does something, but that doesn't work in Fedora, so we need to step in there and make it work for our built system so that it can be employed in Fedora. Well, in Fedora we have the infrastructure to do that. That's a pro, certainly. We work to grow the community. We try to get people who would like to pick up packaging in Fedora, have them start with a simple Python package. That's how I made my way into packaging by packaging some software that was on the list of the neuro Fedora instance needed to be packed for Fedora, packaged for Fedora. I did that and actually I had the experience immediately that that one piece of software that I volunteered to package for Fedora that had a stack of dependencies. Not that big, but I think it was four or five other packages that needed packaging before I actually could get that package into Fedora. And they were not all that easy, but you live and learn and finally we got that in. Fedora is available in Fedora and thereby available to the neuroscientists around the world. We learn from each other as I did and I hope others will volunteer to join Fedora and especially in that case the neuro Fedora community. Then we try to provide information to the end users about the software and sometimes we even provide documentation and deliver that back upstream. The primary goal of the neuro Fedora SIG is to provide ready to use integrated force platform for neuroscientists. This spin that you can pull from the website that has all the neuro SIG packages in there and if you install that then you have the entire collection of software that we have packaged for Fedora available at your fingertips. That is the best way to get researchers started. They don't have to look around, they don't have to run the pip install and then wonder why this one package actually doesn't install. We have solved that for them and it's in Fedora. You can grab that, install it and run and use all the software that is in there, whatever you need. The secondary goals are also to improve the software standard and the maintenance of the tools being used. We help users develop software and while doing so you also improve your own development skills. We try to make neuroscience accessible even to non-specialists, well me included, I'm not a scientist, I keep repeating that. The science is underlying, I have a grasp of what the tools are being used for even though I'm not involved in using them but it's complex at times. Of course we want to make Fedora the go-to distribution for neuroscience and any help in that is appreciated so if you want to join there will be a link on the last slide. That's what we also do. We are building basically on what is already in Fedora, all the tooling needed for providing the software, like some packages are just pure Python, others are a mixture of C and Python and there's other stuff there as well. But we can usually leverage on what has already been packaged for Fedora and which is already up to a high standard which makes our work easier. So we basically build on the community as well. And that basically is just one step short of taking the entire FOSS model and applying that to neuroscience research. Be open, be transparent and let people know what's in the box. It's not hidden, it's up to you, you can look into it, you can modify it, you can improve it and you can base your own development work on it and then make it available again to other researchers or software developers. It's almost five years old now, the special interest group, that's how long it exists. We have about 40 contributors, the number of package maintainers has improved quite a bit. We started out with just about 10 a few years ago and now we are 27 package maintainers. We also have newcomers from other sections, the outreach and so on. And there's only a few people that really have a neuroscience background. So you do not have to be a neuroscientist to join the community and help out. There's a lot of tasks also for people who just want to get themselves familiarized with packaging or maybe who want to improve their skills in development. Python is, I think, by far the largest programming language being used in that software. So if you have an affinity with Python, then you should definitely look into neurofidora and there's a lot of Python work waiting for you. We have about 266 packages ready to install, that was only 150 a while ago. And there is, the queue is ever growing. And of course people choose what they feel comfortable with in packaging. Some packages, we also discover along the way that you encounter dependencies which are patent encumbered and therefore that's where it stops. We cannot put it into Fedora unless there's an option to leave certain parts out. There was the need to scratch my head. There was what's it called, flare? No, it's a big Python tool that uses the GPUs for computation and whatnot and there's an effort now to get that into Fedora somehow. Well that has been, I forgot to name, that has been a big blocker for quite a few packages where that tool has been, where that is a dependency for the software. But so if that makes its way into Fedora, then we have a whole new list of packages. No, no, no, it's, I think it's, it's something like Flare or Flash. It has something, it has something. I'll look it up, hit me up and I'll have it looked up because there was a big discussion on discourse recently and people immediately jumped in there. Well, you can't package that because it needs the proprietary GPU drivers and whatnot and it's a Python piece of software but it uses these drivers to speed up computation. If you don't have it, then it's so down slow that it's not usable. So, but there's apparently now an effort to see what can be done and if it gets done, then that will help us a lot. So, we are building on that effort and we might even contribute to that effort if we feel like we have something to contribute. Yeah, we keep packaging. That's what we mainly do. We maintain the software, new updates means we need to update and if there's like recently Python 3.12 hit raw height, that meant a whole myriad of bug reports for packages that were no longer able to install and here you see again that the developers are not always following best practices because some of the stuff that happened in Python, in the latest Python release or pre-release, it's not even out yet, things that were deprecated for several releases have now finally been removed. Software developers have been warned about it. If you look through the output, there is a lot of warning in it. This is deprecated, it will be removed eventually. Developers didn't care about it and now they need to change their code to make it compatible with the new Python version. Well, you could have seen that a long way coming, but okay, that's where we step in. We provide patches upstream and if we cannot provide the patches ourselves, then we at least leave a bug report upstream informing them that the software as is is not compatible with the latest Python release, which will be part of Fedora 39. So if they do not get around to fixing that, then that means we need to drop that package from Fedora at least temporarily until they have fixed it. And this is the interaction where we can contribute to the neuroscience software development from our perspective of Fedora being a bleeding edge. You know, we have Python 3.12 integrated already, whereas Python itself, the organization has not even released it yet. It's a pre-release. And that tends to produce mixed reactions. Some developers are quick to provide fixes, which we can then apply as patches. Others are more like, well, Python 3.12 is, that's too new for me. It's not even out yet. I'm not going to look at it. I'll look at it later. So then we are stuck and or we can, if we do understand what's the problem exactly, we can try to look into it and provide patches upstream. Say like, you know, if you change that, that makes it compatible with Python 3.12, and it stays compatible with 3.11 as well. So backwards compatible and everyone has helped. People can keep using that software. So we contribute to upstream quite a bit. Yeah, we, that's from the scientist's perspective. Researchers are encouraged to contribute to a FOSS, make the software open source, adhere to the standards. And we encourage people to interact with each other more. To make better software, make the final product more suitable for everyone. That's what we are continuously working on. So that's also, that's why it's headed under future plans. Basically anything, it's just more everyday life of a package for Amphidora. It's packaging, testing, containers, documentation, evangelism, marketing, design. So all these aspects come back in what we do in the neurophidora interest group. And that's where we are looking for help constantly. So if you feel like you have to spare a few cycles or you would like to contribute to certain software and help out, you're welcome. You can contact us, get in touch with us, and you find all the information on neuro.phidoraproject.org. We have a mailing list as well. We are on ISE slash matrix. It's neurophidora. I forgot the name, I have it there, but you can look it up, it's all on the site. The activities are in Pager as a project of the special interest group. There you have bug trackers for software that we would like to have package issues that might have come up, things that need to be discussed. If you feel something there, something, oh, I could help out here. You can just drop a line in the ticket and someone will add you to the special interest group and you can work on that ticket. And your help will be greatly appreciated. You can find us basically anywhere. That's about it. Questions? Take that. Thank you. Really interesting project. And I have like six or seven questions, but I'm going to only ask a couple. Let's stop as one. Yeah, let's start with one. So I guess my first question is you said you have just a few contributors. There are like really neuroscience researchers. And I assume many other people might have come through outreach or maybe RSE or other disciplines. In terms of like the rest of the community, maybe not people like maintaining packages and stuff. What portion of that, like, how prevalent is neurophedora among neuroscience researchers as something that they use? I know many people use fedora spins quite actively, myself included, but don't really actively contribute. So I'm curious your perspective there. Personally, I don't have that information available. I know that Ankur is very engaged in the project. He is a neuroscientist. He would probably be able to answer that question, but he is putting a lot of effort in there to make it known to other, to fellow researchers, fellow scientists, and that the spin is available. And if you need software tooling for your work to get you started quickly, grab the spin, install it, and you have all these packages at your fingertips. Nothing else you need to do, you can just use it. But how many? That is a question I would need to relay to Ankur. So like a non-answer of sorts would be I used to work as a postdoc in a lab that was using fedora for neuroscience. And unless you were involved in close cooperation with the lab, there is no way you could have told this from the outside because it's not like you advertise in articles that you are using this operating system or that operating system. So I think that in general, there is no body who has any idea on a wider scale about different labs and different groups and so on. Any more questions? This is a question that came in from the chat room that I am relaying. So there's a question about whether in the space there's any open source alternatives for diagnostic tests used around ADHD, autism, or other similar software in the Nero fedora software stack. Person was curious about because there's usually closed source software used in this and they were just wondering, I guess, if there was any open source software in this space or if the Nero SIG is covering things like that. I'm inclined to say that since the ADHD, that is a certain defect in the way the brain works, maybe that's not the right term that a scientist would use. There's certainly tools for analysis of certain data and maybe for producing charts or images, presentations and stuff like that. But specifically for the research of these defects, I'm not aware, but that's probably more because I'm not the actual scientist. That's unfortunately another question I would have to relay to Ankur. I wish he were here, but unfortunately he's not. But feel free to post these questions in the chat room. Ankur is very active there and he's probably able to point to some links and you might even find some links on the website that is up on the screen. That has links to other stuff as well, so there might be something in there already. I'll just note he is in the flock chat right now answering some of these questions. So if you are looking for the answers, just jump into Matrix. I wouldn't have expected any differently. So six more questions. Let's take question number seven, please. Number seven? OK, well, actually I thought of six more during the last question, so we're only halfway through now. So I work for a university, which is why a lot of this is really interesting to me. I work for a university open source programs office. My question for you with the Nuro Fedora project, it's quite like it's obviously a very useful software stack for an entire discipline. And certainly from my perspective, there is many organizations advocating for using more open source technology, having more unified software stacks for specific disciplines. And we work, whether they're nonprofit foundations that provide funding for this or in the US, a lot of government agencies are now really interested in seeing this sort of work like NSF and Nuro of Open Science and stuff like that. My question for the Nuro Fedora project and the folks involved in that is, do you have maintainers or community members that are working with these organizations? Is this something that you think the community, I know it's just a special interest group and it's just a spin. So it's not like you guys have your own foundation or whatever. But is this something like interacting with these organizations? Is this something your community is interested in doing, seeking funding and hiring people? Well, I think it happens indirectly because a lot of the software that we package for Fedora is written by scientists themselves. These are researchers that write tools they need to do their work. We package these tools for Fedora and while we do so and while they're developing, we interact with them. So there is the exchange of information and helping each other out and making better software and contributing back to the software that is used by other neuroscience in the special interest group itself. I don't think we have, at least I'm not aware of any members that are actively involved in software development, especially for neuroscience. Maybe Ankur is, but I'm not sure and there might be a few but I'm just not aware of. Okay, thank you. Any more questions? Okay, thank you for the presentation. You're welcome. You're welcome. Okay, we have 20 minutes before the next talk, so coffee. Welcome everyone from the break. We have Neil and Davide here to speak about Asahira mix. Flor is yours. Cool. Hello everyone, my name is Davide. And my name is Neil. We'll be talking about the Fedora side remix, bringing Fedora to Apple Silicon Macs. I'm Davide, this is Neil. We do a lot of things. I do a lot of things in Fedora and in Sentos. I do a lot of things in Fedora, Sentos and other places. I work in Meta, Neil works at Red Hat. These has nothing to do with either of our jobs. Bingo. Mostly. Yeah. All right. I think you're doing this one. Yeah, so we'll start a little bit with Fedora Sahi over you, can I get over? So the Fedora Sahi SIG is our special interest group that packages and maintains the software used to support Apple Silicon platforms. We design, we try to bring in all the software that's needed for being able to boot and run and configure and be able to lifecycle Apple Silicon hardware. That includes things that are used for like say, doing rescue environments with iMobile device and or Libi mobile device or whatever it's called, as well as like being able to have M1N1 for the Stage 1 bootloaders and having custom things, managing the patch sets and changes upstream and sidestream for being able to handle the Apple Silicon platform. And as our primary deliverable for that is the Fedora Sahi Remix. So this remix is a special derivative of the Fedora Linux that's optimized for Apple Silicon platforms. As I mentioned earlier, we maintain a bunch of software for the Apple Silicon platforms. And on top of that, for this remix, we have a few core changes that allow it to successfully run in a proper fashion. So that's a custom kernel that is derived from the Fedora kernels with the Asahi Linux patch set as well as custom Mesa that contains the latest stuff to enable hardware acceleration, custom U-boot to be able to boot the system, and the Fedora Sahi Remix branding. The remix comes with KDE Plasma and GNOME, as well as server and minimal flavors. This Mac Mini is currently running the presentation, is running the GNOME flavor. That MacBook down there is, which is a MacBook Pro, I believe, is running the KDE flavor and just running GLS gears in a loop to distract you. Mm-hmm. So the flagship experience for Fedora Sahi remix is Fedora Sahi KDE. And this variant is essentially the Fedora KDE spin just tweaked and enabled to ship on Apple Silicon hardware. So the bullet points on screen basically kind of describe what we do with the collection of KDE software, being able to provide our branding and usability tweaks and Firefox, SE Linux for security, firewall D, the whole works. Next. And as Davida mentioned, the Mac Mini that we're presenting from actually runs Fedora Sahi GNOME, which is a derivative of Fedora Workstation for Apple Silicon platforms. It's essentially the same experience. Like I said with the KDE one, it's just minor tweaks to be able to enable it to run on the platform. Next. And for the final bits, the server and minimal ones, these are intended for headless operation of Apple Silicon hardware. In particular, like the Mac Mini that we're running GNOME on, we could also use it as a server and be able to have the ability to do ARM 64 based workloads in a server configuration with this using Linux rather than trying to do weird things with Mac OS. The minimal version is essentially the same kind of environment, but it's actually more stripped down because the intent is to be able to prototype for being able to eventually do something like putting it into Mac Minis that are running in clouds. Like if you've seen those various providers that'll like rack up Mac Minis for you and then give you them and just in time, the idea would be hopefully to be able to provide Fedora Sahi in a cloud environment, at least enable those people to be able to provide it if they ever figure out how to deal with bootstrapping it. If you use the Fedora Everything ISO, that would be the closest. Right. All right, now let's talk about how we got here. Back in 2020 and even before, one of the things that Neil and I worked on was getting ButterFS in Fedora and ultimately this led to a change for Fedora 33 to make ButterFS the default file system. And one of the things we had to do as part of this was of course making sure that ButterFS would behave well on all architectural supported by Fedora. And one of the architecture supported by Fedora is AR64. And one of the things we quickly discovered back then was that there aren't that many platforms available in the market that are widely available, are reasonably cheap and can be around 24 seven without self destroying after a little bit. So we were running things like file system stress test and if you're on file system stress test on Raspberry Pi, your Raspberry Pi will probably die after a month's issue or so of operation. They're just not designed for this kind of workload. And while you can definitely get server grade AR64 hardware, you probably don't want server grade AR64 hardware in your apartment, both for power usage and for the noise. And even more so during the pandemic, that was definitely not something you wanted to deal with. So we were keenly interested in having a usable AR64 platform that would be well-supported for this kind of workload. At the same time, Hector Martin started the SI project to port Linux to Apple Silicon. Apple had released these Apple Silicon machines a while ago. There were these new ARM64-based systems. They were, as opposed to most ARM64 systems that you can get on the market, which tend to be developer boards. These are like finished products you can buy in a big box store. They are reasonably reliable. They are reasonably priced to some extent that you can buy a Mac Mini and run it. And it's not horrific. And you can keep these in your bedroom and not hate your life. And I guess these don't burn themselves out after a stress test. Yes, that too. And the NDSI project was a big success. It started with a Patreon, and it was funded very, very quickly. The goal was met overnight. And the developers were able to work on this and announce the project by Christmas 2020. And over the next year, this matured extremely quickly to the point that it got, I think it was in like six months, it got from basically nothing to a working usable system. So these are something that we are definitely interested in. We started taking a look at it and seeing if we could leverage this work and get involved. And in early 2012 was when Asai Linux released their first Alpha 2022, sorry. We didn't go back in time yet. No, we did not go back in time. Was when Asai Linux released their first Alpha release, which was based on Arts Linux alarm, the ARM port for Arts Linux. So in about 2021, we started looking at how we could integrate this work in Fedora. We started the Fedora Asai project, as we called it there. We did not really start doing much work on the porting itself until 2022, because we actually get access to the hardware and stuff. By the end of 2022, mid to end of 2022, we had images that were usable, I would say, for not regular users, but for interested users. They would not require active development work to be used. We chose to use Kiwi to build these images, because Kiwi allowed us to iterate very quickly on it. And we were able to spin up the environment easily for this. At that time, we were still using placeholder branding for this, because this wasn't an official project in any way. We worked with Fedora Council to get trademark approval, so we could actually brand this as Fedora, because we wanted this to be a Fedora thing. This was granted, so we were able to brand this as a Fedora Asai remix. We called this a remix and not a spin because of complicated reasons, but the effectively the idea here is that this is Fedora with just the added bits necessary to provide a good experience on Apple Silicon while we work on getting this bits integrated into Fedora proper. So ultimately, we would like this to not exist and you to just be able to run Fedora or station or server or whatever. But it's gonna take a while to get there and there's some non-trivial deviations needed right now from stock Fedora, not only the use of 16K page kernel, as Neil mentioned, the use of attached UBoot and a few other components. But ultimately, we wanna get to the point where you can just run more station or server or whatever and that would work and I suspect we'll get there in a couple of Fedora releases. All right, so where we are today, we're what I would like to call slightly well oiled. At this point, we have a process for being able to manage the derivative components that we need to build the remix with our custom kernel downstream from Fedora's kernels as well as a Mesa build that comes from the Asahi project upstream. Davida's got batches, the backports, the patches on top of the Fedora UBoot and he manages the infrastructure for the website and we now, as of like a couple of weeks ago, now have auto-build infrastructure so we're actually doing nightlies or dailies. I don't know what time we're actually running. We're doing dailies and to be clear, the reason he says it's only infrastructure and he's not using the Fedora one is because we can't build Kiwi images on the Fedora Koji right now. So that's the main reason why we're using dedicated in-front. There's like some Rube Goldberg-esque thing that I spun up on AWS right now for this. But like long-term, ideally we can get all of these in Fedora in-front and not have to maintain dedicated stuff for it. Right, but now that we're at a place and this is where the slightly well oiled part comes from, we now are in a place where we are able to, with minimal human intervention, make sure we can make releases and pump them out as we make changes to the underlying components that make up the remix. So the big part of why Fedora Sahi is kind of so special is that we did a lot of work actually upstream in Fedora too. So as I mentioned earlier, that the Fedora KDE variant is the flagship and that meant that a lot of work needed to be done there to specifically make Fedora Sahi with KDE to be absolutely perfect or not perfect, but absolutely like perfect for the hardware. And that meant like changing to Plasma Wayland by default, getting all the stack to move to using Wayland natively as much as possible, getting the login manager into that, which was actually really, really hard. Get me outside sometime in the hallway and I'll tell you like the whole horror story that led to how long it took to get that. But also having PipeWire and these other innovations that came from other people within the project and their willingness to help us be able to support our hardware platform also allowed us to have a very streamlined experience for people that just wasn't possible on other platforms. So and on top of all that, we did a lot of work for desktop related arm software because nobody else was really running them in any serious capacity and we were seeing lots of little quirks and bugs and stuff like that and we were capable of drilling into them and fixing them and polishing up the experience to the point where it's actually quite possible to use it in a semi sort of kind of daily driver sort of scenario. If you're just doing simple stuff like a browser and some documents and whatever, right? Like most of the things are actually in a good working state. I use it as a daily driver for my work desktop at home and it's fine. It's worth noting that all these changes don't just benefit the specific part but they're useful for all the other systems that run on AR64. So if you have like a Pinebook Pro or Raspberry Pi used as a desktop, all of these end up helping out there as well. There were a surprising number of weird hangs that were in like browsers of all things that cause us narrowing down and getting those fixes and actually improved the quality of the experience for all ARM desktop platforms if any others exist like the Pinebook Pro and some others. Next slide. And today I wanna, you know, the state of the hardware support with the Fedora Sahi remix, we have good coverage on all M1 machines and M2 laptops. We have firmware support going up to the latest firmware at this time which is V13.5 and as of a couple of weeks ago, we switched on hardware accelerated graphics by default. However, we do have a few things that are not supported yet. The speaker, the camera and on laptops, the HDMI or display port connectivity is not working. There's much more details about the matrix of features and functions that are in development, working, not working, partial working, whatever, on the Asahi Linux Wiki. All right, now let's talk about what's coming up next. We are happy to announce that the Fedora Sahi remix is going to be the next flagship distribution that will be used by the Asahi Linux project that's been developed together by Asahi Linux and the Fedora project. The tentative release for this is the end of this month. There are, thank you. Oh yeah, so the tentative official release is the end of this month. We're working through everything. It's not quite done yet, we're working through it. We're hoping that we'll have it done by the end of this month. There are development builds available that you can play with that we'll have a link later. Although, as Neil mentioned, this isn't released yet officially, so if the developer builds ETR machine, maybe think about whether you're okay with that. At the same time, the various patches on the various components of these are getting integrated in their respective upstream projects because the general philosophy around Asahi Linux has always been to try and get as much as possible integrated upstream because there's no point ultimately maintaining downstream force of things. So slowly and methodically, we're getting support for all the components in the kernel, in Uboot, in Meza, in X keyboard config for the Wii or Mac keyboard in all of these projects so that eventually we will be able to just run a stock kernel, a stock Uboot, and so on and have a good working system. Yeah, and a lot of this effort has been driven by Hector Martin, Mark Caternas, Alyssa Rosentwig, and Asahi Lina, sorry, Alyssa, if I didn't say your name right. But Rust for Linux, from my personal experience as the maintainer for the Fedora Asahi kernel, Rust for Linux tends to be like one of the stragglers here. It's starting to get better at keeping up with the new Rust compiler versions. It uses a lot of Rust unstable features, which means that every time the Rust compiler gets upgraded, my kernel builds get broken. And so that's actually a big part of where this is less where I like it to be in terms of the stability level because the guarantee of me being able to pump out new kernel builds is not where I think it would be. But it's getting better. It's workable. We saw that by effectively having a stripped down Rust compiler in a copper that we can use in an emergency. Yeah, absolutely. So if we bring in a 16K variant to the Fedora kernel, which is definitely on the table, it's something to do. I know that there are patches. The Rust stuff right now is not ready. It's not on stream. There's no way we're turning that on. I get that. I'm not gonna bring that in. The rest of the stuff though, my understanding is fairly well, it's being staged and merged upstream fairly quickly. So if I were to turn on a 16K variant and release that as a standard Fedora kernel, is it possible to do the graphics driver as an out-of-tream module? No, because Rust doesn't know how to build modules. So trust me, this burned my soul so hard because I wanted to do it that way too. Oh, so I don't think we actually said that. So it's probably worse for people that aren't following this closely. The reason we are talking about Rust is because the GPU drivers for this platform are written in Rust. It's actually the first major kernel component that isn't a toy driver that's being developed using Rust from the start. And because it's the first one, it ends up leveraging a lot of fringe unstable Rust features that are in the process of being developed. So it's taking a while to get it integrated. Eric, you were trying to say something. I was wondering what you were gonna say. You might wait for the mic. You might want a microphone first. One thing I would like to say FDM, if Rust support isn't ready for the Fedora kernel yet, like for months we were running on software rendered graphics and they're actually screaming really fast. So even things like YouTube and all that runs pretty flawlessly on just the software rendered graphics using like simple DRM. So it's not a blocker. It's nice to have the hardware accelerated graphics but you don't need it for day-to-day usage unless you're into gaming or that kind of thing. Yeah, absolutely. So to kind of add some more color here to this, up until two weeks ago I produced two variants of the same kernel build. One that had the GPU driver and one that didn't. And the default that we shipped up until two weeks ago was the one that didn't have it. So I actually am fully okay with the idea of us having that turned on in the baseline. And then my kernel build is basically waiting until we can get to a point that can be integrated upstream. So that's the reason I proposed the MR upstream to get the 16K flavor in because we're getting to a point within the next couple of kernel releases that we will probably have all the basic bring up for non-hardware accelerated graphics desktop usability. I think a Mac Mini you can already run it on the... Yeah, I'm talking about with the laptops. Oh yeah, no, for the laptops for sure. But I think if... The Mac Mini's been fine for... The Mac Mini's already fine, yeah. The Mac Mini's been fine for about a year now, but the extended power management features that are needed for the laptops, those are just now getting in the process of being upstreamed and stuff like that. Yeah, so for the most part, when it comes to enabling new hardware platforms, it's device tree updates. There has been I think a grand total of one driver rewrite upstream and that was for the mailbox driver because it turned out the mailbox subsystem was a really bad fit for it and so the driver got rewritten to not depend on it anymore and use its own queuing model for stuff. And beyond that, I don't think we've had any major subsystem rewrites, but in general, I think we're getting to a point where basic functionality can be enabled for almost every use case in the upstream Fedora kernel and the reason we wanna have the 16 and 4K flavors is because there's some other stuff we're trying to enable where we can have host guest being host 16K guest VM 4K doing some interesting stuff and we're trying to figure out what that's gonna look like and so one of the things that I wanna switch to in the next few weeks as soon as my flavor MR has merged is reconfigure our downstream kernel to be kernel 16K and get the infrastructure set up for some of this other stuff that we're working on the pipeline for having the dual kernel install set up for. Yeah, I hope 4K is not going away. I still need it. So and yeah, next slide, I guess. Oh, a quick question. Is there a particular reason why speaker support is so difficult to implement? Which? Speaker support. Oh, you don't wanna blow up the speakers because there's no firmware on the speakers to actually keep them from blowing up. It's all entirely software controlled by the operating system, so you can pump as much volume as you want and you can fry them. On the laptop specifically, you can physically damage the hardware if you're not careful, so the idea is to do this in a way that it's safe so that users cannot easily damage their machines. So technically everything is plumbed in, but we have hard disabled all of the access to it by default because blowing out your speakers and then taking it to an Apple store there, it is a dicey move if they're going to repair your laptop after you've blown out the speakers like that. There's. Has it been hard getting the hardware working on like M1 and M2 since a lot of the stuff in MacBooks are proprietary and don't have much documentation on it? No. Really, it's been easy. So the thing is that Apple, so I talked to Hector a lot about this in the background because I'm interested, as it turns out, Apple's like every other normal PC maker in that they don't actually like everything changing all the bloody time because it makes their own software development lives hell. So what they've done is that they've built essentially an internal standard platform and they build on top of that for every successive platform. So a lot of the stuff that we built originally for M1 has worked for M1 Pro, Max, M2, and so on. On top of that, Apple has a pretty high tendency of reusing their hardware configurations across generations. And so a lot of the driver stuff we've done has essentially been able to be one-to-one reused. The main thing is that oftentimes ports change in the internal configuration for device trees and whatever, but the actual drivers and enablement work tends to not be too bad. Sometimes there's some new quirks or whatever that has to be dealt with, but that's no different than what happens on X86. Yeah, I think between M1 and M2, the main thing that changed was the controller for the touchpad, I believe is completely different. And that new instruction that screwed up all the browsers. And there was a new instruction in the CPU itself that changed things a little bit, but yeah. Actually, yeah, I was kind of wondering how like the touchpad hardware. Authenticated pointers, that's what it was. That broke all the browsers. Oh, the touchpad, there is ongoing work on that. It is not ready yet, but. Yeah, because it's a haptic touchpad, so it's probably gonna be harder than a normal touchpad. The touchpad is mostly done at the touchpad, which is the other stuff is that the patches were originally written for Intel Mac several years ago, but none of the people that were working on it really wanted to try to shuffle it to upstream. The ASAHI Linux team essentially forked the patches and reworked them to clean them up for upstream use, because there are still three generations of ARM-based Macs that sadly have the touchpad, and so we need to deal with them. So yeah. I think we've covered everything on this one. Yeah, let's go. So, because we also covered this quite a bit during the questions that came up, but essentially, like our goal is to eliminate the delta as much as possible and try to get everything into mainline Fedora, with the long-term goal of actually eliminating the ASAHI remix entirely and just have mainline Fedora for all of this stuff, so more to come in the future on that. Yeah, what I suspect will end up happening down the road is that we will, as new generations of hardware come out, we'll probably always have the remix in some form for the bleeding edge support for this new hardware to use as kind of an incubator to then get the support into Fedora proper. Right. It's hard to tell in advance how things will develop. And of course, if you've got Apple Silicon hardware and are interested in this stuff, you can come join us. We've got an issue tracker, a mailing list, and also, if you're a user or interested in discussion and support, we have support forums. In partnership with the ASAHI Linux project, where all ASAHI forum-based discussion is moving to on discussionfedoroproject.org, and we have a matrix channel where you can all join. And I assume Matt is turning it on to make it go live. And I realize now we did not actually put a link on this thing to the actual remix website, so I would put that up now so you can. You can stare at its glory. You can have a reference if Firefox loads. There it is. At least it's a lot easier when we can actually read the screen. It is a lot, it is. Yeah, if you weren't here before, we're trying to set it up before. We had the spy monitor here, so it was typing and looking over there. But yeah, it's, Dada Dada Fedora dash outside the screen is.org, and that has a lovely curl pipe bash command that you can run on an Apple Silicon machine. Right now that points to the daily builds that kick off every day at 5 p.m. UTC, I believe. As we said, the daily builds are daily, development builds that are mostly untested, so they may or may not work, blow up your machine, nobody knows. That said, they have been pretty, They work pretty well lately, David. Matthew wants to know if you are on a discourse. I see you have a mailing list. We got both. Oh, okay, all right. Was it on that page? Yes. It was on that page, yes. Okay. Can I bring that back? Yes, you can. It was here, yeah. Discussion. Is it live? It is live. It is live, yes. We love it. Thank you. We are actually, I don't think we actually use the mailing list that much. I think it's mostly two. I kept everything locked until we were ready to launch. So the mailing list was also available, but I wasn't letting anybody in or putting any messages or whatever. Now that we're actually launching and going live with a public presence, both presences are now active. You can subscribe and start having messages and people will start talking to you and whatever. Whichever method you actually prefer communicating, we're available on both. Yeah, and most of us hang out in that matrix room. So you can also reach us there. There's a link to the Wiki page for the SIG for the SI Linux project itself and for Fedora. And yeah, I think that's all we have. Yeah, actually I wanna make a special note here. That discussion topic, just like the mailing list, it includes both upstream, ASAHI Linux discussion, as well as Fedora ASAHI remix discussion. So ASAHI Linux contributors, a number of them, have joined the Fedora project to work with us and collaborate with us directly with the ASAHI SIG. So they're members of the SIG and are available and present for people to get feedback and talk with them and everyone can benefit from that. Right, and that's the reason why it exists or it does in the discussion forums as a separate category and all that other fun stuff. Any other questions? Yes. All right, this is a bit of an ignorant question and I know nothing about any of this. But how, like, does the development on ASAHI sort of impact development for other similar sort of platforms like risk five? Like is there any sort of transitionary work that you think working on this can? Not really. I think it helps in the sense that getting better support for ARC64 is helpful in breaking the X86 monoculture. So when you have software that only works on X8664, the jump from getting it to build there to getting it built on ARM definitely makes it easier down the road to also getting support in our risk five. But the risk five is different enough from ARCH that I don't think work directly on ARCH usefully impacts work on risk five. I think it's mostly gonna help people from a mindset perspective. It's not really gonna help people from a code or technology perspective. Got it. Thank you. David. Yes, okay, so I wanna qualify this first by saying I don't use either environment, but I was curious why KDE was chosen over NOME since we promote NOME as kind of the other interface or the primary interface on other things and then follow up, will those other environments work on this or are you primarily just focused on KDE right now? So there's a few major reasons for this. So the first major reason why it's KDE and NOME at all as opposed to just all of the bloody variants is that the primary requirement for full support from the Asahi Linux community is that it's gotta run on Wayland. And so it needs to be a full stack Wayland environment bottom to top because there's enough weird bugs and edge cases and brokenness in Xorg that can't be fixed for the Apple Silicon platform that it just wasn't feasible to do any of that sort of thing. From the remix perspective as the primary maintainer of the remix, my particular requirements for any other desktop environment is that somebody has to want to step up to support it and be able to be willing to accept bug reports and work on fixing things. It has to be able to run in a Wayland based environment to take advantage of the enhancements and fixes we've done in the Wayland stack specifically for Apple Silicon platforms. Why KDE Plasma over GNOME? Because KDE Plasma was actually willing to do a lot of work for the upstream community, the Asahi Linux community to adapt and fix things to make the Apple Silicon hardware be responsive on the desktop. One simple example is keyboard brightness control. There are no keyboard, there's no hardware buttons for keyboard brightness control on modern Macintosh computers and there is no way to control it in GNOME without a button. Did they fix that last week? They did fix that last week, but for a very long time, it took a long time. There's other things between impedance mismatches with modern and several other things where the relationship for upstream with KDE was considerably warmer than it was with GNOME and the end result was the people that are working on this stuff and daily driving and actually being able to fix things and get things working were able to get it done faster and better with KDE Plasma than they were with GNOME. Now I would like for both desktops to be equally well supported, but at this point in time, at least there are some gaps in the GNOME experience on ARM platforms just in general. We're not even talking about Apple Silicon, but in general, there are several weaknesses in GNOME on ARM that are not present in KDE Plasma on ARM because there's been a lot more work on KDE on ARM than there has been GNOME on ARM. Okay, well, so that's good to know. So if I was to go and buy an M1 MacBook now, like KDE would probably be what I wanted to use, but is GNOME aware of these? Yeah, we've been talking to them and part of the reason we even shipped both is because there has been progress on that front and because Fedora gets new GNOME basically every release, we can see the incremental improvements as they come out and my hope is that with more exposure to this and people actually actively seeing this and being able to use GNOME on a real ARM platform that everyone cares about, that we will actually see the quality of GNOME on ARM improve. Yeah, for what is worth, I think GNOME is mostly fine, like there's definitely little areas that aren't quite as polished, but it's perfectly usable. The other thing I would mention with our other KDE and GNOME is the ASI Linux distribution they had based on ARCH. That one used KDE by default and there was a mild preference from a bunch of the upstream ASI developers towards KDE. So that was another reason why we favored going with KDE as the flagship here. And the thing is that between the two desktops, like we support them as well as anyone would expect within Fedora. Yeah, and if somebody wanted to support other desktops by all means, there's no... If somebody's willing to do the work, we're more than happy to build images for other variants. Yeah, provided the requirements are met, we can do it. Next, window manager thing? Yeah, after step, no. Does that run on Wayland? I don't think it runs on anything in about 20 years. So one other question, which is an idle curiosity at my point, but you probably have the answer to. How long does it take to build a kernel RPM on an M1 Mac? 22 minutes. Excellent. I do it enough times. On the laptop. Yeah, on the laptop. It's probably faster if you get... They have models that are like... An M1 Ultra on a Mac Studio or something that have more cores, those are probably even faster. So I have a Lenovo X13S, which is fairly difficult to install on right now, but it is the closest thing most people can get without having a jet engine in their room. Yep. To build a reasonable AR64 kernel. So as a development platform, the M1 would be a decent AR64 development platform. That was the reason for my question. Yeah, I can build Chromium in 36 minutes on there. So it's very fast. There are some workloads where these machines are ridiculously well performing. As it turns out, it's very, very, very good at compiling. I just wanted to add something to the comparison between ASAHI and the X13S effort. Two things, the Apple Silicon is faster. So you're going to get faster builds. But another thing I find super useful for development personally, because this is my main development machine, this M1 Mac Mini, is... The firmware is unlocked onto the EL2 layer, so you can use KVM. And that's something we don't have on the X13S yet. And I heard rumors of that, so that's great to hear. So for the... Because the peanut gallery was talking here, the X13S that we're talking about here is supposedly maybe going to also have KVME things in the near future. I actually have a question, and I'm surprised it wasn't brought up. Is Apple contributing to ASAHI? No. Apple is completely, gleefully, blissfully, happily, hopefully ignoring us. And I'm okay with that. I will actually, it brings up an interesting point, right? We've gotten very used to this idea that vendors are essentially going to be supporting the hardware platforms directly in the Linux kernel. And that has actually led to a little bit of an inconsistency in how well computers are actually supported in Linux, because we've kind of gotten used to not having to do it ourselves, and not having to understand how the computers are actually working for the Linux level. The bring up for Fedora ASAHI remix has actually been one of the more joyful platform bring ups I've done in a very long time. And I typically dislike ARM. So that's a, it's quite a bit of praise there. From the x86 perspective, if a vendor isn't involved everyone just usually gives up and just says go find something else, and sometimes something else isn't a thing that you can get. And it leads to a very sad situation. The nature of how the Apple Silicon platform works with all the people that are actually interested and people actually caring about it. We're seeing a much higher quality Linux platform coming out of a hardware platform that the OEM just isn't doing anything for. Then we see for a lot of x86 platforms that you have vendors partially or some degree kind of supporting because the community has much more ownership over the platform than you have for the other stuff. So that's a little bit of my soapbox when people talk about x86 versus ARM and Apple Silicon stuff. Okay, thank you. More questions? Just kind of following on from that last question. I'm curious if you could speak on thinking towards the future, especially in the last few talks we had your talk, we had a talk on risk five. And these new platforms that are coming about and the work that it will take for things like Linux or the Fedora project to support those platforms. Thinking forward in like the next decade or two, do you have any concerns or hopes about like what that support means for our communities if you think it will be an additional stressor or if you think it will open up new opportunities or just like general thoughts, I guess. I think in general, you're likely to see a wider variety of use cases stem out from this. Because I think especially that you can see these on ARM outside of the desktop and server. ARM is very popular in the example, in the embedded space. But you will see this risk five as well where I suspect there will be more examples of non-traditional use cases that will be well enabled where something like Fedora or like a major distribution will be a usable platform there. Like in the past on the embedded, you often had people build their own because the system was so constrained. These days, you have systems that are massive compared to what you had even a few years ago where it is actually viable to say, oh, I'll just run like Fedora workstation plus my software on top and it's gonna be fine for some use cases, not for everything, of course. So you will probably see more of that. In terms of supportability and workload, it's hard to tell, but I think if we continue to see the kind of interest we have seen, for example, with the ASI project where there's a very excited community doing work, doing actively work and doing work the right way, like getting the work upstream in the projects upstream so it can be maintained in the future, that I think both's very, very well. Where I think this breaks up a little bit is when you have say a vendor making a trade, dropping a BSP on the floor and running away and then that kind of withers because sometimes people pick that up and like go to the table of upstreaming and get it well supported, but it can take like a decade for that to happen. And then the hardware isn't shipped anymore maybe or it's just obsolete or it doesn't make a ton of sense. You see these a lot with phones where like, yeah, you can run Linux on a pixel from, I don't know. Five years ago? Yeah, it's things like that. Yeah, and this adds a little bit of extra context to my comments earlier is that one of the more interesting challenges that we're gonna start seeing is where's the balance between community versus vendor enablement for platforms, whether it's in risk five or arm or even x86 or whatever. My personal desire is to see more of the balance tip towards the community rather than towards the vendors because the vendors seem to not be that responsible with it. We've let the vendors kind of drive how they're gonna consider support for Linux and it hasn't paid off nearly as well as I would have liked in across the different spaces. Some of them have been better than others and it kind of depends on who you're working with and what they're doing but when it comes to community stuff people don't have the bandwidth to be willing to just say, well, we're gonna do this and then drop it on the floor and then go do something else or whatever. Most people don't have the money to do that much less anything else, much less the time. So you tend to see the much more methodical, careful, correct way of doing things when you have the community-centric approach towards these kinds of enablements. It's slower for sure, it's sometimes frustrating but it tends to lead to a more correct solution over time. He's got a- I would actually like to strongly counter that statement with we've worked for decades to get vendors to do as much as they can to try to push this stuff upstream. I get there are some that are horrible. I'm not gonna name names. There are some that will do nothing. There are some that will ride a driver, maybe lob it upstream and they leave it. There's various levels of, but the more the vendors get involved, the better it is for everybody. I'm not saying that- If they take a community-centric approach, I agree. Yes, but even if they don't, we need to be pushing them in that direction rather than saying, don't just half-ass it and let the community take care of it instead. We need to say, you need to do better as a vendor. Now I get the Apple Silicon case as a completely different case and they have no commercial interest in doing it but as a whole, as a blanket statement, I think we need to be pushing hard for vendors to continue to do the right thing and move in the right direction. I agree with you in principle. The problem is that I'm so burned out from it. Like having experienced this in the private space, in previous jobs, in previous experiences, like I used to do arm-bring-up stuff as part of my job for some things. I used to do platform stuff. I used to debugging. I've had to write drivers before. I've had to debug drivers with vendors before. I am all burned out from most of that and I imagine that a lot of other people are and the problem is most of us that are out there that are working in this community space who want to make, who want to pressure the vendors to do that, they don't actually have a voice. They don't have a way to talk to anybody and this kind of comes to the larger problem of like, we don't have commercial Linux desktop. Not really and without the commercial Linux desktop thing to like create this virtuous cycle of enablement and support and communication because at a business to business level it's a lot easier to do these kinds of things whereas at the community level it's way harder and so with what I have and what's available to me I can't really do anything about it. I agree. I mean it's been a problem for a long time. I get the burnout. I mean we've been doing this since 1995 now. It's frustrating but that doesn't mean that we should give up and just say don't do anything because we need to be moving. I mean how long does it take into, I realize we're a long way still from having an upstream fully working NVIDIA driver. How long did it take though to even get them to do what they did and open up their specs and open source their driver? Almost 20 years. Exactly, exactly what I'm saying there. Don't give up because it can get better. Yeah. The only reason we have working cameras in our laptops is because of Chromebooks. Otherwise it would be a binary. Which also comes back to that there was a commercial Linux desktop case that gave it. Right, like I don't, okay I'm gonna say this Google is probably the best thing that ever happened to Linux desktop because they drove a ton of open source upstreaming effort for both x86 and ARM platforms that made the infrastructure for desktop Linux way better. There's a lot of pieces under the hood that actually came from them for building Chrome OS that we rely on today or we are about to rely on today or that we are integrating and adapting from. And that's because they felt the need, the desire and the stuff wasn't there before and they had the power to pull it off. The part that makes it difficult for me and this is one of the reasons why I've really liked working on this Apple Silicon platform stuff versus everything else I've ever done in the past was that when, as a person who is working on something like this, everything I'm doing is actually impactful in actually improving the space for everyone whereas when I'm kind of shouting into the void to some of these nameless people or whatever that are supposed to care about some of these things, they don't. And there's only so much I as an individual can do with no real backing or scale or support or any of that kind of stuff. Again, I'm just a guy in Fedora trying to make desktop Linux work, what am I supposed to do? Yeah, there's a big difference when you approach these from the point of view a company with a commercial relationship and you have certain levers you can pull. If you're approaching this from the point of view of a volunteer that either wants to do work in a specific area or as a user that would like to see development in a specific area and doesn't really have a way to do it themselves besides, I don't know, donating to a project that knows they're doing it, it's definitely more difficult to see what is the approach to getting viable support for X. No, like I said, I get it. I've done that and I've done it with, I'll do it with XR664 and ended up with personal contracts with vendors because nobody else knew how to, seriously, it's weird. But it doesn't mean it's worth giving up on. So I realize it's frustrating. You still push forward. You work around it and make things work as long as you have to. But in the meantime, you still, let's not give up. Yeah, be clear, I'm not giving up. I just, I have for the most part, stepped out of the fight for a little bit, but I'm happy to encourage other people doing it. And it's not entirely hopeless, as you said. And video opened up. Other people have been doing it. We've got Lenovo doing stuff upstream. Occasionally Dell does some stuff and you see HP sometimes now. I've been seeing a lot of improvement on that space. Heck, I think even ASUS and Acer are starting to do stuff. Like it is improving, but it's still a giant patchwork and there's still no community, there's no avenue for community pressure to make an impact. And that's something that we do need to solve because almost all of these things are not, they're not company driven. They're like the needs and the usage is by individuals. And so if that's the case, we need an avenue for their voice to matter. And I don't know of one right now. With the Apple Silicon one, with the Asahi Linux project, the individual voice has mattered and that's what's led to tremendous improvements so quickly. The bring up to make this a fully usable platform for his uses, it only took four months. Yeah. Like that's impressive. And that's because being able to work with the people and get tight feedback loops and actually having people care about what people are experiencing, that makes a huge impact, whether it's a company or an individual. It does, but you also had years of Leonardo working behind the scenes, getting AR64 to the way it was to begin with. I mean, it's not just that there's more to it and we've got to keep applying that pressure in any way that we can. Yeah, sure. It's just, I'm just saying, like from the computers that people are actually using, like the fact that we're able to bring this up so quickly and now have a wonderful experience to share with everyone in partnership with an upstream community is phenomenal. We haven't done anything like this before. No, but I think it is a good point to raise that this isn't something that came up in a vacuum. It definitely built upon the work that was done for like... For decades. At least a decade and change from Leonardo, from other partners that try to develop the arts. I mean, hell, arm for length. Space, the arm space and then the air space in a viable one. That's for sure something that's worth noticing. I mean, hell, arm for length started in 1999. So like, it's not like it's new. It's a very old thing that's incrementally been built over the literal decades. This might be a silly question, but for the Apple hardware and maybe for other ARM hardware as well, is there a firmware update story at all for Linux? Yes, and it's hard to have this conversation in general. So for Apple hardware specifically, the way the firmware works is that the firmware is distributed alongside MacOS. The firmware itself isn't redistributable, meaning that you can't copy it and serve it from your website, but it is on the machine. So the way the provisioning process for the machine right now works is that the installer will grab the firmware out of MacOS and that's how it's available on Linux. And then on Linux it's installed like any other firmware using the Linux firmware interface. Because most of this is non-volatile firmware. Like firmware that's not at your runtime. There's also firmware that is updated on the machine itself and that's updated as part of the MacOS update cycle. But that is something that is specific to this platform. In general for ARM, this tends to be something that is very vendor specific that you would need to see. And it's also component specific because oftentimes you'll have like a mini PCIe, Wi-Fi card or whatever that comes with its own firmware concerns. You have the firmware for the main system. You might have firmware for like weird additional co-processors and stuff. So it's very hard to answer these in general terms. For Apple Silicon platforms, the main cases to think of is whenever you update your MacOS operating system container environment, which is the boot environment volume, not Linux containers, but like volume container, when it gets upgraded, the firmware is downloaded and installed onto the system and the system DFUs into that environment. Going forward then it reflashes itself and boots up with that new version of the firmware. When we boot into Linux, every time we poke at what's available from that MacOS has put into the boot environment and we copy it in and load it to initialize the hardware. So the only thing we actually have to maintain is the Drakeit module that was written to be able to pull that stuff out and boot and initialize it. And the device trees, which actually know where the hardware configuration actually is to connect the kernel to the hardware to be able to do things. And the parser to extract the firmware files from the like proprietary format that I use for that. Right. You are required to maintain dual boot script. Yeah. Ish. So you are required to have, there's two parts of this. Right now the way these are deployed, yes. They're designed so that you have MacOS, you have a full MacOS alongside your Linux install. The full MacOS isn't strictly necessary but right now it is the easiest way to do firmware updates. So that's why we're recommending people to keep it. The way the Linux side is provisioned is that the installer makes a straight down MacOS container and then effectively repons the kernel from the MacOS kernel to the Linux kernel to boot it. So you have like a skeleton MacOS that is used as scaffolding to boot Linux and that one sticks around effectively forever but it's completely inert once you boot the Linux. You just waste like a couple of gigabytes of this space. Yeah. It's essentially going to be what we do in the PC world with UEFI. Yeah. It's like MacOS has a giant boot loader. Which by the way, that's also how it works on Intel machines. Yeah. It's a special weird MacOS running at firmware. There's a question back there. Is it kind of like how I think Apple's Unix worked? Where it would like boot into MacOS and then... There are a number of disturbing parallels, yes. That was even more fun because if I remember right, that went from a live Mac system and you ran Unix from there. Yeah, kind of, that's what it kind of sounded like. It is definitely fun in that sense. You can't quite k-exact from MacOS to Linux, although that would be entertaining. You... Okay. Although the pre-bootive environment is technically a derivative of MacOS. Yeah, let's just say, you basically are doing that. These things have a couple of variants because Apple really likes building things in-house. So they have variants of their own core operating system that they use for various things. So there's like... There's a little MacOS that's the boot loader. There's a little MacOS in the damn dungle for doing video output. That one's weird. It's a very interesting example of vertical integration in a company. So the boot loader on these things is actually a stripped-down... Well, the state-to-boot loader is a stripped-down MacOS. The recovery environment, which has a GUI and everything is a stripped-down MacOS, and he runs the bootpeaker thingy is a MacOS app. Yeah, and that also means, by the way, you have full hardware services. You have Wi-Fi working at Early Boot. You can do Bluetooth and have audio going through at Early Boot. It's weird. Oh, you put it in full screen. That's why it was weird. Well, given that we are... I can show you one quick thing. Oh, yeah, that's right. You should say that while I do this. So while he's doing this, I'll explain. So the way that we actually boot into this system is we start with the weird MacOS environment, which then goes to M1N1, or MINI, which then loads U-boot, which then loads... Which creates a UEFI-ish environment that then loads grub, that execs the Fedora kernel, that then boots the Linux environment, and you're about to see it. So we will see if this works because I don't know if HDMI is actually going to sync. Unless you just invited the gods against us. Because this may not sync, but we'll see. Hey, there you go. Your first MacOS environment. Yeah, so this is the bootloader. And in the bootpeaker, you can pick whether you want MacOS or Fedora, or if you do options, it would put you in the recovery environment, which is like a full system where you can run, like the Huant of FDisk and the Terminal and things like that. So if you pick Fedora, it says 37 because this is an old install, but... I figured it was something like that. We changed the thing to actually say something more descriptive now, and then it will change the... And then it will do this. Now it's booting, and when it boots, it copies the partition into the boot partition, and now it boots into MINI, which you didn't see because it's invisible. Now it's booting U-boot. Now U-boot is going to boot the UEFI, that's booting Grub. Grub is booting the kernel. That's the Plymouth thing that's going on. The one on the back, the FUXE on the back comes from MINI, actually, and then you get a desktop after a while. Oh, and MINI apparently provides the fake background thingy that we do on x86, like it can do it too. Although Plymouth doesn't know that that's there, so it doesn't load it correctly, but it can do it. Oh, and this one I wrote a login, nice. And there's your Fedora desktop. We just did it. Five boot environments in one go. Yeah. Okay, perfect. Thank you. We are out of time. Thank you, perfect. Alrighty. Oh, and if you want to play with this, there's a MacBook there that doesn't have any personal data on it. So if you want to play with a machine, it's there or you can find me, and I'm happy to lend it to you for five minutes. Oh, this is off, maybe. Someday. There we go. Yeah, I don't think we've done that one. Okay. This one is mine, that one is yours. This is here. Hello. Sorry, I'll introduce one is mine. Does the speaker notes work? Pardon? The speaker notes do they work? So yeah, it depends how you set it up. I'll turn it off. Can we actually use that display again? Um, yes. So with that, you could get speaker notes, like you would see on the screen. Okay, I can see my notes and they are not there. Yeah, you're using PowerPoint, so it'll work. Yeah, okay, perfect. So, if you're going to book... Oh, okay, so... Oh, okay, perfect. So you can just stand here and the microphone will pick it up. And I'm doing the inter... Is it working for you? Yeah, it's okay. We have the final session of the day, coming up. Okay, so final session of the day, we have Nikita here, and the presentation is about Fedora Badges. Floor is yours. Thank you all for joining. It's a crowd. I didn't expect these many people here. So before I begin, I would... Before I begin to talk about the Fedora Badges, how to? I would like to briefly introduce myself. So hey, I'm Nikita Tripati, and I'm a final year engineering student at Indian Institute of Technology, Roorkee. And I interned at the Fedora Badges design project last year as an outreach intern for the summer cohort. And I've been contributing to Fedora ever since for the design requirements. And I would just like to mention before I start, this presentation could not have been made possible without the guidance of Mary Norden and the contributions of Chris Idoko. So here we go. Here's a content reveal of my presentation. I will introduce the Badges system. Then we'll walk through on how to use them and then explore what lies beyond the horizon. Okay. As we all already might know, Fedora Badges is a fun initiative created somewhere towards the end of 2012. So this initiative was to induce a sense of recognition and achievement in contributors for their engagement with the Fedora community. These engagements could be through their contributions, through their involvement, or their participation with the Fedora community. So effectively, this introduced game-like elements into the non-game environment of the contributor to make the contributor experience even better while encouraging them for the holistic development of the Fedora infrastructure. This method in technical terms is called gamification. So to see what Fedora has done so far with the Badges, you just need to go to the explore page of the Fedora Badges. And here is a snapshot of it. So with over 600 Badges in existence and many in the making, the Fedora Badges have maintained their style for a long time by following a strict style guide. This guide specifies the colors, fonts, shapes that should be used in all the Badges. And it also provides instructions for the overall design of the Badges. So the style guide has helped to ensure that the Fedora Badges are consistent in their appearance. And this makes them easy to identify and recognize, and it's important for the program that is designed to reward the contributors. Now that we are familiar with the Wats, let us have a look at the house and create our own Badge. So to start off, we should have a start with a clear purpose. So which means asking yourself, what do you want your Badge to communicate? Are you trying to identify people? Are you trying to promote a message? Or simply make a statement. Once you know your purpose, you can start to develop a design that aligns with your goal. And just like Leonardo da Vinci said, simplicity is the ultimate sophistication, so keep it simple. Badges should be easy to read and understand, use clear fonts and colors to avoid too much clutter. Stick to the Fedora brand. Fedora has several branding elements used the Fedora logo and style guide. Incorporate them into your Badge design. This will help to create a cohesive look and feel for all the Badges. And most importantly, be creative. Badges are a great opportunity to get creative with your design. Use illustrations, have a look at the photos or even custom artwork to create a unique and memorable Badge. In design, it is very important to get feedback. Once you have a design, show it to a people in the community and get their feedback. This will help you to identify any potential problems or areas for improvement. So Fedora Badges has several existing Badged CDs. These CDs are a fun way to create another dimension to the Fedora Badges, such as collecting a set of Badges and help to develop more content. Moreover, the Fedora Badges are classified into six main categories. These are development Badges, content Badges, the quality Badges, community Badges, miscellaneous ones, and even Badges. And as you must have noticed, all the categories have a corresponding color during associated with them. The Fedora Badges came into existence about a decade ago, and the Badge templates stayed the same through these years. Over time, some shortcomings were noticed in the existing design, and hence came the need for a new Badge template. So learning from the research and discussing the previously identified improvements, I made a series of iterations. In the new version, I reduced all the white space to lay more emphasis on the graphics. I removed the drop shadow from the design in order to make it look more sleek and modern. And during the designing of the iterations, I was also inclusive of a future possibility of dark mode being implemented across all the Fedora websites. In the original design, as we can see, there was a repetition of the vector shape provided. In simpler terms, the border, the white space, and the graphic space were all made out of a single shape. Because of this, mathematically, the design was balanced, but this created a visual imbalance to the eyes that the corner is a bit thicker around the turn. So to improve this, I introduced a solution that instead of using the given shape as the border, we could add an outer border to the graphic base shape and make it look more visually balanced. This added to an oversimplification to the previously existing separate layers in the SVG file. The simpler design also added to the simplicity of usage. So I reduced the numbers of the editable layers. I added a clip group so that anyone can simply put their design inside of it and a body group where the design could be put. And it will automatically get clipped or hidden. And it will not leak beyond the borders. So this eliminated the traditional method of separately clipping the objects which can be observed in a lot of present badges. And for the sake of consistency, I also added the typical tabography composition for the badges and patterns in invisible layers. And I provided an instruction layer which can be deleted. And it also recommends the contributor to delete all the unused layers so that when the badges produce it occupies a lesser storage space. So the website doesn't take a lot of time to load because of the badge size. So in order to first accommodate more clear guidelines, secondly to assist contributors maintain consistency across the Fedora badges for the deliverance of the authentic Fedora experience. And to give the decade old badges tile guide a modern refresh, I created the new official Fedora badges guide. In the new guideline, I included all these essential instructions from the previous guide and I added a few updates. So as you can see here, since there was an update in the Inkscape application and a few technical things changed in the export options, I added those. There's a 256 by 256 pixel and a 96 DPI which was previously incorrectly mentioned in the old guideline. So it has been corrected now after the update. In addition to the previously laid guidelines, I introduced some new ones to help contributors to Fedora badges. For example, on this page, I am suggesting a good trick of trade for color selection, that is to select any column and then go with the top three rows in the main palette for the badges design composition. I also included some of the unwritten rules about topics which needed consistency, such as this one. So while some of these rules might seem obvious to everyone, some of them might not be, but they need to be followed. And I remember I had to ask about this one specifically with Mary a lot, I had to trouble her a lot in my first making of the badges. So here's top secret sneak peek into the new look of the badges, which are yet to be released. But hey, what are you waiting for? Go make your own batch today, be creative, express yourself and get involved. Thank you all for being such a great, nice audience and I'm really grateful for this opportunity and my experience at Fedora has been the most enriching ones I have had so far. Any questions? So is there going to be any update to the guidelines about issuing badges to contributors? About? About issuing badges to contributors? No, not that I am aware of. I'm just curious if you also designed some guidelines for that or not? No, no, no. And maybe a list of batch ideas that you can start from? Badge ideas? Yeah, like a list of badges that people may want to introduce. Can you please repeat, I'm not able to... Well, any specific ideas that beginners who want to try their hand at designing badges may start from? Since we are at the flock event, why not people start with designing the event's badge for the flock event? Any badge can be designed. Most of the badges are of the beginner level so anyone can go and design a badge. There are some badges that require new artwork so that would go for maybe the intermediate or advanced level. But beginner badges, there are a lot of those and anybody can go and design those. Maybe I have the answer you were looking for. I think you were looking for inspiration on how to design badges, if I got your question correctly. Yeah, well, you can look on Pager, there's the Fedora Badges project. It has all the badges that are available in there. And you can look at these designs and PNG, SVG files are all in there and you can use that as a starting point and modify and whatnot. I mean, it's open source, it's out there for you. Otherwise, look on Badges.FedoraProject.org and whatever badge it takes you fancy and use that as an inspiration. The source board is available and the images are available. Everything is there. So I would just like to add up on that. When I first started contributing to badges, for me to understand what type of artwork Fedora wants, I just went to this Fedora Badges Explorer page. I just looked at all the badges and got an idea about what kind of artwork do they want. Then I read the guidelines. There is a complete set of rules that I need to follow, the border size and the shapes. There are some already existing artworks that you can just cut, paste and use them over the badges. So those are helpful. Hey, Nikita, great presentation and I've been really excited to learn about all the new design work going into the badges along with the ongoing work that we have to do Badges 2.0. So it's been really cool to see also the artwork getting the refresh and getting a new look. So my question is since you were an intern last year with Fedora, I was just curious to know what you've been up to since your Outreachy internship finished and I know you've mentioned you're finishing your last year of school but just curious to know what you've been up to since Outreachy and what your next steps have been since your internship. Okay, so after my internship at Outreachy, I worked with Software Freedom Conservancy as a consultant for their graphic designs and I made graphic designs for their event, FOSSI, this year. And besides that, I've been contributing to Fedora. I was in the design chat and many of you must have known that this Creative Freedom Summit that occurred around January, right? So we used to make some banners and promotional social media posts. So I made some backgrounds for that and those were used. And I keep contributing as much time I get during my coursework and all the things that are happening. So that would sum up my open-source journey so far. More questions? So this is a very deeply technical question, so bear with me. But what's your favorite badge? Okay, so it's not up yet. I made this badge during my contribution time. So it's a high five, but it's high five badge. So I really like this one. I made it during my contribution. What did I do? I don't really remember. There was some specification, but I was too focused on the artwork. I also have a question. I know that you are pretty good at Inkscape, since you can draw that, but for someone who is not very good at Inkscape, how can I learn and maybe start creating a badge? Okay, so if you have never done any graphic design and you want to start with Inkscape, there are online tutorials on YouTube. And you can also find it on the official Inkscape website or on the Fedora Badges website. So there is a list of tutorials for you to learn Inkscape from. Thank you. I was also just going to add at Creative Freedom Summit, I remember there were some sessions for beginners on doing things with Inkscape. So also the recordings from the Creative Freedom Summit in January would probably be a good resource too. Perfect. Thank you. Okay, thank you for the presentation. Well, that's it for today for this room. Enjoy the game night. Yeah, so just some housekeeping stuff. So we will be on pause, I believe until six. So the game night is going to be in the room upstairs where we had lunch. If you have any board games, card games, anything that you brought along with you, please bring them with you. Thank you. Thank you. Thank you.