tuff 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.  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.  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 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?  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.  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.  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.  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.  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 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.  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 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.  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.  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.  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.  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.  And I'm doing the inter... Is it working for you? Yeah, it's okay.  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