It's weird starting without music. Sorry, I just sort of ran out of time today. All right, so today we're going to talk about files. On Monday, Carl introduced you to the wonderful, wild, messy, weird world of disks, these actual physical objects. And so what we're going to talk about for the next couple of weeks is sort of this challenge that the systems community spent a fair amount of time on, which was how to build a reliable system, a file system that has some desirable properties that we'll start to talk about today, on top of this really unreliable substrate, and how to make it perform well. So on some level, I think, as hopefully Carl acknowledged, the world of spitting disks is something that's sort of retreating into the past. But we can still learn a lot from sort of studying how this was done. And there's a lot of sort of principles about how to build these types of systems that apply to not only flash storage, but certainly to cloud services and other types of things. I mean, failure is a reality in a variety of different types of computer systems. And some of our ideas about how to cope with failure came out of early work on file systems, right? I mean, file systems predate the cloud. They predate large distributed systems. And so this was sort of one of our first chances in the systems community to really cope with failure. OK, so Simon 3.1, how many people are done? I know that there are some, wow. What is wrong with you guys? There's something different about this year. I don't know what it is. Maybe it's you. You can certainly think that if you want to feel good about yourselves. Clearly, you guys are doing better, so there's something. If you have ideas about what's going on, I would be happy to hear them. Are office hours working better? Office hours working well? How many people go to office hours a lot? They feel like office hours work well. OK, I think having them downstairs works well. There's all sorts of issues with the one small office approach to office hours, even if you have your own office. The ninjas are awesome, right? Ninjas are good? Yeah, I don't know. I'm really very pleased. It's too bad this is my last time teaching the class. Maybe next year will be awful. OK, so hopefully, whoever I've cursed to ever takes this over, they're going to have terrible students. OK, so Simon 3.1 is due on Friday. If you're done, move on. Recitations have already moved down to 3.2. This is another one of those cases where there'll be no extensions for this particular part of the assignment. So get it done or work on it later and don't get any points. Any questions about Simon stuff? Logistics? I know I've been away for a little while. Our goal is to have the midterm back by, like, we may have it available to distribute at some point next week. The TAs, we're trying to finish grading it by this week. I think that's aggressive. When they do finish it, we take it over to the printing place on campus and have them scan it for us. Once we're done with that, you guys can have the exams back. So at some point, we'll make them available in office hours. You guys can pick them up. They'll also be incorporated as part of your midterm grade score. OK, any questions about disks? Everybody remembers perfectly how disks work? If we have some time at the end of today's lecture, I'll also go over some of the midterm questions. So I'll sort of run through this stuff quickly. Parts of the disk, what's a platter? What is the platter? Yeah, the platter is the part where I write stuff on. It contains the magnetic material that encodes the information that's being written down to the disk. What about the spindle? Yeah, it's the thing where I mount the platters on. It's the part in the middle that spins everything around. I really wish I was here on Monday. I love that lecture with all the videos. It's a really cool video. Did you guys watch the Saucid videos? Is that still in there? The Saw video? Did I get rid of that one? Oh, it's too bad. Anyway, maybe we'll pop with that one later. The head, drive head. Yeah, so this is probably one of the most interesting parts of a magnetic disk. This is where all the action happens. This is the part of the disk that's responsible for both reading magnetic information off of the disk platter and altering that magnetic information during writes. Well, actually, I'm curious. How many people still have a machine with a spinning disk? OK, how many people have a laptop with a spinning disk? Oh, man, get rid of those right away. These are dangerous. I used to have one of those. I'm really glad I don't anymore. Drop it. Just a minute to say goodbye. Yeah, a lot of times, I think Carl probably talked a little bit about the capacity curves.  So if you want something big and cheap and you don't need a huge amount of performance, has anyone ever priced out a terabyte flash drive or a two terabyte flash drive? Yeah, those numbers get scary. Big. All right, this location, so what's a track? Once we start talking about file systems, particularly old file system designs, think a lot about this stuff. Yeah. Is the track like a rain around it? Yeah, think about a lane on a track. It's like a lane on a track. It's one. It's the place where the heads, if I just let the head stay in one place, it's the place all the locations around the disk it'll see as the platter spins beneath it. Sector. Yeah. Yeah, so it's like a slice of the disk, right? And these are not necessarily, well, there's interesting features of these. Cylinder group or cylinder. That's put together. Yeah, all the tracks. Remember, disk typically consists of multiple platters arranged vertically around a single spindle. Imagine, so a track is on one platter. The cylinder is on all the platters going down. Why is the cylinder interesting from the perspective of file system design? Yeah. Yeah, so typically on, it's hard to say anything categorical about disk drive design. I suspect there were disk drives where you can move the heads independently. But a lot of disk drives have all the heads for all the platters mounted on the same device, on the same, well, there's one head, and the actuators for all of the platters are all on that. So essentially, all the heads are in the same location at any one given point in time. And so the cylinder represents all of the information that I can read from the entire disk without moving the heads very far. And why is that important? Yeah. Moving the heads is the really slow part. Moving the heads on a disk requires not only moving a physical object, which is always slow, but then stabilizing that head once it reaches the location over a very, very, very thin point on the disk.  It's sort of amazing that they work at all. And this is really a very high precision instrument. If you get the location slightly wrong, you're reading a totally different set of data. So rather than the MP3 file that you wanted, you're playing some other song or something. And disks, and hopefully Carl emphasizes some money, I mean, disks are really different than everything else we talked about. Discs are physical devices, so they move. They have this physical component to them that creates a great deal of latency. On some level, all of the delays in other parts of the system are really the function of the distance between data and where the data is being processed and the speed of light. Or the speed of light through copper. How fast I can get things across the chip. So if I've got registers on my CPU and I wanna do some computation on memory, the latency involved, which is actually sizable from the perspective of the CPU, is really the time it takes to communicate with the memory, get the data from the memory, and move it to the CPU and into the registers in which it's going to be processed. That's just electrons moving around. This is actual physical things moving. So this is slow on a whole different order of magnitude. And remember, from the perspective of the CPU, memory reads are slow. CPUs play a lot of games to try to minimize the latency of even a read to memory. So a read to disk is like a whole, it's like Pluto. The last thing is that disks have, so one thing that you may notice as we start talking about file systems is there's a lot of different file system designs. How many people could name at least three different file systems that they've heard of that they might use on one of their computers? Yeah, if you run Windows, is Windows still using NTFS or have they moved on to something else? Okay, so Windows says NTFS, Macs have their own thing, HDFS, I think. I don't remember what it's called. Linux has EXT4. You might have heard of things like Ryzer. I'm not sure Ryzer works anymore. But there's actually still new file systems out there with new features that people are developing. And that's a little bit different than the other things we've talked about. So the file system is on some level a distinct piece of system software that is tightly integrated with the operating system, but also separate. So the same operating system can run multiple file systems at the same time. You don't really do this with schedulers or with page replacement algorithms or other things on the system. Those are a little bit different. So file systems have always sort of been integrated into the operating system in a slightly different way. Now obviously if you run Windows, you have sort of a tight coupling between Windows and NTFS, but Windows can mount and read data from other types of drives, right? FAT32, other CD-ROM file systems, things like that. All right. So here's how we actually move things around at a disk. I actually have to issue a command so that the operating system has to send some sort of electronic signal to the disk, using some sort of protocol to tell the disk what to do. The drive actually has to position the heads appropriately. So this is important. I have to wait for the heads to actually stop vibrating, moving around so that they're properly stabilized over that very narrow track. Wait until the platter rotates to the correct location and then finally pull data off the platter and transfer it back to the system, usually to some sort of memory buffer. So and we've already talked about the slow part here, which is the seek time. That really dominates everything else. Seek and settle. So, and this is sort of become a little more interesting, right? So for a long time, disks were becoming bigger, but not faster.  Wear these video recording devices around all the time so that they can collect a complete trace of their entire life? Sounds, I don't know, I don't know about you guys, maybe your life's more interesting than mine, but there's a lot of boring stuff that that would be capturing, right, if you were me. But yeah, so, you know, people are generating more data or we're expecting access to more data. Discs have gotten quite a bit bigger. That curve has slowed down a little bit, right?  That was my big hard drive. My small, I'm serious, my small hard drive was four gigabytes. That's the one that came with the computer. And that's like, I mean, how many people have a two terabyte drive or something like that, right? Yeah, so that's several orders of magnitude. You know, so you have more space than I do. You should feel lucky about that. All right, questions about disks? Let me talk about files. Yeah. So Carl mentioned third space. Yeah, maybe. As a possibility. We'll talk a little bit about that when we come back to hierarchical files. That's a good point. I mean, well, let me ask an easier question. How many people have a device that has a hierarchical file system on it? I mean, everybody's hands should be in the air. You all do, you know. How many people use that? How many people organize things? How many people create folders with subfolders? Yeah, you guys are weird though. Computer scientists do this because we've encouraged you. Because you guys use the command line and stuff like that. So you're doing things a little differently. How many people's parents do this, right? Yeah, all in downloads? Or like all in my documents or whatever. Like who knows where my documents is on Windows? Like it might not even be rooted with the rest of the file system. It's like, well, but that's all people know, right? Yeah, all in downloads, I like that. I go into my downloads recently, just to lead everything. But yeah, on some people's machines, that would be a problem. Yeah, so, you know, well, how many, let me ask a different question. How many people use one of these search things on a regular basis? To find files, to locate things. I like the, I ask this every year. And I never know, does Windows still have the dog? No? It's too bad. The dog was so helpful. It was like, oh, it's really cute actually. That was one of Windows' bests. You think of all the things that went, they've created the clippy stuff and all that stuff.  Maybe I just like dogs, right? Like, great that they had a cat, too. They was like, no, no thanks. I'm not helping you. Just like slunk off, hit in the corner. Yeah, so people are using, I don't use this stuff, but I'm, you know, I'm from a previous generation. So I turn spotlight off. I just don't really care. It's just not how I look for things, but I know people do that, right? And how many people are nervous about storing anything on their computer today? Like, how many people just don't feel good about having stuff stored on their computer, just on your computer?  I mean, the biggest shift for me, just to blunder into a little bit of personal history, is has been music. So how many people still have like a tree somewhere on their system with all their MP3s in it, right? That's organized very carefully by album and artists and stuff like that. What a waste of time. Just stop, right? I will give you guys $10 and you can try Google Play Music for a month. You'll never go back. I still have that somewhere, but I don't know why. I never listen to that stuff anymore. Yeah, and I spent hours and hours, probably days of my life organizing that stuff, dealing with special characters back in the day. Linux didn't like special characters. You know, these weird things when you have an accent. So don't listen to music by artists with accents in their title, right? That was the solution. Anyway, a total waste of time. But I think that's very different now. A lot of people use Spotify, Google Play Music, that's all search-based. Who knows where those files are or where they come from, but as long as I hit play and it starts playing in my browser, I don't care, right? All right, good question, though. All right, so let's talk about files. So part of the goal of files and file systems is to remove all the problems. And this is the classic, our classic attempt at the classic thing that abstractions do. So I've got this low-level disk interface. So here's what the disk understands. Read and write in entire sectors, blocks. Sometimes this is bigger now, maybe 10, 24, maybe 248 bytes. But that's what the disk lets me do. The disk doesn't know about files. The disk doesn't know about names. Well, the disk does know about names. It has this notion of names as numbers. So you can kind of think of the disk as a huge array of blocks. And that's it. So all the stuff that you guys associate with using files, human-readable names, the notion that files can grow and shrink and be deleted and created and have permissions and location, it's all implemented in software. None of that exists on the disk. The data required to implement that has to persist on disk, but the structure is entirely up to the file system. So this is kind of what makes file systems fun. It took me a long time to appreciate file systems. Maybe you guys don't appreciate file systems, but essentially you're given this very simple data structure which is a big linear array. And your job is to use that to implement all of these features that you guys are used to. Start talking about some of those today. And again, and this is partly due to speed, but it's also partly just for historical reasons, more of the interesting parts of the file system are actually implemented in software. So for example, the tricks that we play to try to make file systems fast, to try to make disks fast, the file system tries to hide all of these ugly delays that the disk has to do and do things intelligently. That's all done in software. On the CPU, those memory delays that I've been hinting at, those are hidden from the operating system in these really cool ways, but they're totally invisible to the operating system. Does anyone, do you guys talk about out of order execution and pipelining and stuff like that when you do your hardware stuff? No one's ever heard about that? So cool, out of order execution will blow your mind. It's totally awesome, right? Anyway, but that's what the CPU is doing internally. From the perspective of the operating system, the CPU is executing instructions in the order in which they were presented. What's really happening behind the scenes is that the CPU is playing all these cool games to try to make things go as fast as possible and to hide memory related latencies. You should go look this up, it's very cool. And this is kind of what explains the design space. So one of the reasons that there's so many different file systems out there is if you guys want to, you can actually write your own file system and you can run it on your own machine. In fact, there's now pretty well developed support in Linux for user space file systems. So there are tools where you can write your file system and you can run it in a user space that doesn't even have to run with kernel permissions and you can use that to do cool stuff. And to some degree that's why all these things exist. Okay, yeah, anyway. And that's that, okay. Yeah, so Flash. So Flash seems like, I just want you guys to keep this in the back of your mind as we're talking about some of these old disk-based file systems. Flash may seem like it solves a lot of these problems. It does have certain desirable characteristics compared to disks. So for example, there's no moving parts. So you might think Flash never fails. Is that true? Does Flash never fail? Who thinks that Flash never fails? False, right? Flash fails in other weird ways. And Flash has other strange properties. So certain types of Flash drives, if I want to rewrite one bit, I have to first erase this huge chunk that surrounds it and then rewrite the entire chunk with one bit changed. So that's weird. That causes me to have to do some interesting things in my file system design. And Flash actually wears out. I do not know why this is. I have no idea. My mental model of Flash wearing out is of like, I don't know, something that's been scratched too often and it starts to like, the coating starts to come off. So it's a totally ridiculous. Like clearly there's something more subtle going on with the underlying, because this is all electronics, right? I have no idea why Flash wears out, but it does wear out. And it wears out as a function of usage. So if you keep writing and reading to the same part of the Flash drive, that's the part of the Flash drive that's going to fail. And that makes things interesting. So Flash drives actually do a lot of interesting things internally to try to spread out the load across the entire Flash chip and make the whole thing last longer. So anyway, there are certainly complications associated with Flash and we might come back and talk about this a little bit later. Okay. So let me briefly, and I'm gonna try not to belabor this. Yeah, definitely, yeah. And it's sort of interesting. So a lot of the file system designs that came up around disk-based systems have been ported to Flash where they make sense and they don't, right? So there's certain features of them. They usually don't, well, I shouldn't say that. Sometimes they actually hurt. Sometimes some of the things that we do in disk don't work on Flash very well. The other interesting thing that happens with Flash is that Flash typically has software that runs on the Flash trip. This is something called the Flash translation layer. That Flash translation layer is doing things internally with the Flash that are somewhat opaque to the file system. So this makes things even more complicated. Sometimes I think some of what those Flash translation layers are doing is actually trying to make the Flash look a little bit more like a spinning disk in certain ways, right? But that can complicate file to system design further. But yeah, absolutely. I mean, there's definitely work on new file system designs that are responding to properties of Flash. But right now what we've done is we've sort of taken some of these older file system designs and we just moved them over to Flash and we're sort of hoping that they work well. They work okay, but they're not necessarily taking great advantage of the Flash chip. There's also these new, does anyone have a hybrid drive on their machine? One of these new, fangled? Yeah, so there's like this even newer thing that I think we had an exam question on a couple years ago where people are trying to combine Flash and a spinning disk in the same package to produce kind of the best of both worlds, right? So remember when we talked about using disk to back memory? We wanted the entire disk plus memory plus swap to look as fast as memory, but to be larger. So that's kind of what they're trying to do with Flash, right? So you can think of these hybrid drives. The goal is to make the whole drive look as fast as Flash, but increase capacity more cheaply by using a spinning disk for part of the backing store. That's kind of cool. Okay, any other questions before? This part's sort of boring, so I'm just gonna try to like blow right through it because I think you guys understand this, but I think we just wanna be specific. Okay, so what do I need to do? So the file is one of our primary abstractions here and the features of the file end up dictating a lot of what the file system design requirements are. So what do I need to do to be a file? What are the requirements for a file? Not a trick question. I think you guys know these, thank you. That's to be have a name. I'd be able to find it. So that's to be some name that the system understands refers to that, fine. Okay, what else? Yeah, okay. I mean it, yeah. Well let's go with the simple stuff first, okay? So Farron only has a name, right? It's not super interesting, yeah. Is it data for and follow up with the store? Yeah, it should like store data, right? That's useful. The data that a file stores is treated as if it's contiguous by the users of the file, right? So that you guys think of a file as a contiguous set of bytes. It has a start, it has an end, and there's some series of bits in between the start and end. How those bits are interpreted is one of these things that ends up being the function of what kind of file I think it is. So has anyone tried to open like an mb3 as a text file? Yeah, there's some weird characters in there, right? Like it's not a text file, so it doesn't look like text. You can open it with Vim and like play around and edit it and then see what it sounds like. I don't know what that would do. But yeah, so the, how we interpret those bytes is something that really happens at higher layers. But it's a set of bytes. What should I be able to do to those? Well, something else. They should persist.  That would not be a good file system. Like you would not appreciate that. So I need to persist that content over time. What else? What other things do I do with files? What's that? I read and write. I read and write? Yeah, so there's an interface to the file for accessing its contents. What about writes? What can I do to a file? What's that? A file. Right, so there's a name. The name can change, right? I can move the file around so I can change the name. What about the contents? Yeah. It can grow, it can shrink. I can delete it. I can truncate it back to zero. I can grow it up to multiple terabytes on most modern file systems. So again, think about it. You have to build this data structure on top of what's essentially a flat linear array. These are some of the design requirements. Okay, what else? So now we've talked about some of the basic properties. People had started to get into some of the other things. So what are some of the other features of a file that you might think of as more like metadata? Yeah, timestamps associated with use. What else? Ownership. Ownership, yeah. I mean, if file systems don't get ownership right, the world becomes a very interesting place. I can log into Timberlake and send mail as you and read your mail and finish your assignments for you and stuff like that. Maybe you'd like that part, but anyway, yeah. So ownership is big. This is something that is a core file system feature. What else? Yeah, metadata store about it. What about, well, type is interesting. Let's come back to that. Yeah, permissions in general. So UNIX has a specific set of permissions. There's other file systems that do permissions a little bit differently. What's another piece of information about a file that the file system maintains? It's kind of like permissions, but not quite. When I think of permissions, I mean ownership. But what other information do I store about the file? Yeah, that's basically the path, right? That's another feature of the path. Yeah. Yeah, that's internal file system data, right? Remember, computers like to name things with numbers. So there is something called an I know number. We'll come back to that, but there's something else. There's the permission bits, right? Can I read to this file? Can I write to this file? Can I execute the file? And that's something, maybe if you guys have downloaded something from somewhere online and wanted to run under your computer, one of the things you have to do is actually adjust the file system permission so that you can execute it. Otherwise, the system will say, you're trying to execute this file, I don't know how to execute. And then the last thing here is this idea of sort of how files relate to processes. And this really sort of boils down to things like what files a process has opened, where the file pointer is for those processes. I can see people already starting to doze off. I'm just gonna like try to speed up a little bit here. Okay, we already talked about this. Blah, blah, blah. So again, I mean these basic file expectations seem like they're pretty simple, but they're still bugs. I mean, file systems are complicated and there are still bugs in modern file systems. I'm sure that I could have found a more modern version of this bug. But, and this is, you know, Margot used to say, Margot worked on file systems for a long time. So she used to say, you know, data loss is one of those things. It's one of the worst bugs ever because if your file system loses data, not only is the person whose data you lost angry, but they now have, like they're probably, we're trying to work on a project and you destroyed all of their data. So now they've got nothing to do, which means they have time to call you on the phone, send you nasty emails, flame you on hacker news or whatever, like they've got a lot of time on their hands to come after you about this. So this is bad. And file systems still do this. There's also a really interesting line of work that's been going on for a couple of years about trying to prove certain properties about file systems. And that's really interesting, right? You know, can I prove, can I come up with ways of being 100% confident that my file system doesn't suffer from certain problems? Okay. Now, what's hard about this? Well, not only is it hard to build this complex data structure over this linear array, but file systems have to deal with all of these issues. So what happens if someone trips over the power cord in your data center and suddenly, they know all the power to a rack goes out? What are my expectations about what happens after that? It may be the case that some of the data is lost. That's okay. We'll come back to this when we talk a little bit about recovery, but I don't want the entire file system to be corrupted. Has anyone ever had this happen to them? Like a total file system corruption? Yeah, so I had this happen to me. Remember that 20 gigabyte drive I was really proud of? So I had all, remember that MP3 collection I was really proud of, right? So now these stories come together, right? So I had that all on that drive. And at some point I was starting to mess around with Linux and I accidentally overwrote the super block on this drive. And so it basically, so it's really frustrating, right? Because you haven't modified very much of the data, but you understand how data structures work, right? You modified the important parts of the data. Anyway, so I was pretty sad about this. This was back when you guys don't understand what it used to be like to get music, right? You had to do a lot of dodgy things to download music from the internet. This is pre-Napster, okay? I'm that old. So I spent like $50 on this CD of recovery software for this drive and I thought, this is awesome. So I ran it and it discovered like, I don't know, 95% of the files I had on the drive. So I'm thinking this is awesome, okay? The problem was that the other 5% of the files were intermixed in the other MP3 tracks, right? So you'd have like Britney Spears on and suddenly there'd be this like tiny little snippet of something else, right?  So essentially everything was ruined. It was terrible, right? I think I had someone made Napster at that point because everything got much easier after that. It's easier to do bad things online. All right, so we talked about this. You know what? I'm not gonna do this exercise, this is sort of boring. You guys can go through this. I used to do a little design exercise here about where to store the file method metadata, but it's not really that interesting. Okay, and there's also this idea of establishing a relationship between a file and the user. You guys may have wondered, for example, why do I have to call open? I just call read and write and give it a path and give it where I wanna put the data in the file and have that work. And there are some reasons for this. File systems like to observe these relationships so that they can optimize certain things, right? It's helpful if I know that a process is in the process of using a file, I can do some intelligent caching and other things. And I can also provide some guarantees based on open so I can allow a process to open a file exclusively to make sure that nobody else is using that file behind my back. That could be a useful thing to do. Okay. Yeah, I don't guys know about this. This is sort of all review at this point. Actually, you know what's to do this. Is there anything about this that doesn't make any sense to people? You guys implemented this stuff, so I think you get it. This is the interface for manipulating the shared information that's sort of between the process and the file. All right, any questions at this point? Basic file expectations. Okay, good. I've got 15 minutes to do midterm review. Okay, let's midterm questions. So obviously the secret about this exam is it was all recycled questions. Hopefully they didn't bother anybody. I don't know why it would have, but I've written so many. It's so hard to come up with good midterm questions after you've written like thousands of them. I have this thing that happens to me now where I think, oh, that would be a great midterm question. And I start writing it up and then I look through my huge catalog of old questions like, oh no, I used that one three years ago. I just totally forgot. So that's sort of depressing. Any specific questions about stuff that was on here? Munch? You wrote in an answer? It doesn't matter. Oh, I'm sorry, you know what? I'm not scrolling the right thing. Okay, let me go over here. Yeah, everybody gets a credit for this. So there used to be, there is a correct answer to this question, I think. On that was the one. Well, thinking of Bob is also, I guess. Did he say that? Does he say that in the lecture? Okay, awesome. He says, on that, right? Okay, anyway.  They were like, I'm gonna lose a point because I didn't know what song you played in class. I don't care. Yeah. Well. I mean, there were only four options, right? One out of, I'm glad that I'm not the only person with verbal tics, right? But I do, I just want to point this out. This question is very much on here out of love and respect, like the fact that Carl has been willing to lecture has been super helpful, right? And he's good at it. Okay, any other questions on the multiple choice other than the one about Carl? Yeah. Go for Jay. Jay. Right, good question. So look, categorical statement, let me just give you a test taking tip. Categorical statements like this almost always falls, right? Like I can come up with a counter example. So why doesn't this ensure that variable foo is protected? Yeah. What if foo's also modified outside of it? Exactly, right?  At which point this piece of code doesn't matter, right? I mean locks only work if everybody who is modifying a variable uses them properly. And this is why in other languages they have better primitives for doing this. So in C, this is what we got. In other languages, you have ways to say certain, just make sure that certain methods or certain types of access to a variable are always synchronized regardless of who's doing it. That's a much better design pattern, right? Better to design a particular object so that all the accesses to it follow certain rules than hope that everybody that uses the object follows the rules properly. Makes sense? Yeah. Yeah. I have the exact same thing. As soon as I saw that it was false, I'm like, duh, he means that there's other code that would be accessed in or modified who then it's false, but I don't know. When I read that, I wasn't thinking that there could be other code. It just says the following code, which, yes. I'm not backing down on this one. I think this is an OK question. Yeah. OK, other questions so that I can get defensive and defend my solutions. This one makes sense. Yeah, so we talked about this a little bit in class. I mean, if I have a thread that figures out how to yield right before its quantum ends, essentially it can kind of keep itself in the top queue despite the fact that it's really doing stuff that's very computationally intensive. Maybe a yield or I do like a really short sleep.  And one solution here is to just give threads credit for how much of the quantum they use. The goal of MLQ is to reward threads that do a little bit of my work and then block again. Yeah. People know I don't think this stuff is black magic. I mean, Linux has like one scheduler and it's open source. So if you really wanted to, you could probably go. But I don't think it's subject to this sort of manipulation. Windows and stuff, that's a good question. I don't know if there's. I suspect a lot of the stuff doesn't change very often. So I suspect a lot is known about how these things are done. And to some degree, remember you also want it to be tunable frequently. So you need to allow information to come in from the outside. Somebody who's running certain types of workloads on a Windows NT server may have tweaks that they make to the scheduling algorithm to get those workloads to perform better. What's that? I think you can also set quantum lengths and fiddle with that a little bit, right? Yeah, I think there's a few knobs usually. Depends on the schedule. Yeah. Other questions about this? Oh yeah, there we go. So this is a nice question. This is modern, right? I mean, modern computers have more than. We passed this threshold a long time ago, right? I mean, how many people have more than 4 gigabytes of RAM on their machine? OK, yeah, great. So clearly a 32-bit address space is starting to struggle at that point. Yeah, and we haven't gone all the way to 64. That's a long way. In 64, I think it's enough to address every atom in the universe, so you're probably never going to have that much, given that it takes at least one atom to store a bit. You're probably not going to have that many megabytes of RAM anytime soon, so that's a little bit overkill. So we've gone somewhere in the middle. Some systems have eight-bit extensions that allow me to latch on to a 32-bit base address and therefore create a 40-bit address, 48 bits. I'm sure it's out there. Any questions about this sort of obvious stuff? How this is done is you could probably give a whole lecture about how we started to add large, wider address support to modern systems. It's ugly. A lot of reasons is because it's being bolted on to previous 32-bit architectures. So again, imagine a 32-bit chip where in addition to my 32-bit addressing, I now have one 8-bit register that sets which page table I use or something like that so that I can support wider address spaces. And a lot of this ends up being pretty hacky. OK. Yeah, this is an easy one. Illusions, any questions about this? This is sort of cool. I mean, there's probably other other. These right answers are not intended to be exhaustive. If you guys came up with other things, we'll give you credit for them. The solution set is just examples of ways that you could have answered the questions. Questions about this one? All right. Yeah, exceptions. The thing this question is trying to get at that I hope you guys have absorbed is the fact that memory-related exceptions are not fatal and are really calm. So of the exceptions that your computer experiences, the program experiences while running, probably 99.99999% of them are memory-related and totally benign. It's just address translation. That's how it works. So I mean, how many people have seen a program crash because it's divided by zero? I mean, that just doesn't happen very often. Well, OK. One that you didn't write. Sorry. Or you didn't. Well, anyway, that's a mean thing to say. I mean, hopefully we sort those out earlier. This is an exception. Yeah, Vicki, if you would wait, what's the example? Sorry. Only program. I mean, I guess that's an example of an exception that would terminate it. It's a different example because it's memory-related. But it's an example of using bad memory. So that's a great point. Using bad memory falls in the category of something that could terminate a process. But most of the time, again, unless you're a new C program and you're hitting all these segmentation faults, most memory-related exceptions are translated by the operating system because they're access to valid memory. Yeah. So you actually could use memory for both. You could say memory in a case where it's translated is an example of something that doesn't terminate the process, memory in a case of bad reference to something that I don't have permissions to use or isn't the right type of operation, again, trying to write to my code segment or something like that, that could come in. OK. Signalization primitives. Yeah, so this is, hopefully this is something people figured out. It's kind of an interesting design choice. Any questions about busy waiting versus non-busy waiting? OK. Yep, what privileges do I need to multiplex memory? The ability to modify the TOB, access to kernel data structures. And this is how I control the memory on the system that a process can use. I mean, that is the kernel's primary objective. Make memory available to processes, but control on a page per page granularity what a process can do to each page of memory. And again, with as little intervention as possible. OK. Well, I'm going to answer questions. How many people did the wait time prediction question? OK. How many people did the jumbo pages question? It's the other one. OK, it's a pretty good mix. Any questions about either one of these? Well, we'll start with the wait time prediction. Questions about this? How many people read the previous exams when they were reviewing? OK, good. I thought about telling you that this was all old stuff, but I didn't want to, like, bias how people studied. So maybe I should have done that.  Any questions about the jumbo pages? It's a nice thing about giving an exam that's all old questions. No one has any problems. Gas. I don't know. It's not clear that these questions are still better than they used to be just because I've reused them. We're good? OK. Any other general exam questions? So just looking ahead a little bit, the final exam is going to be identical to the previous final exams. I will probably gin myself up a little bit and actually write some new questions for it, because sometimes that's fun. So again, don't make any assumptions based on the format of the midterm. I know that the midterm is time pressure. So that's normally reflected in the scores. That's fine. The final is not. So the final is roughly about twice as long as the midterm, but you have three hours instead of 50 minutes. So people typically do not have a problem finishing the final exam on time. OK, I will see you guys on Friday. Good luck finishing assignment 3.1.


Hi guys, my name is Angelica with Smoke Cartel and today we are going to be reviewing the Grave Dugout.  It's made of this cool aluminum, it's got a beautiful texture, beautiful finish and the engraved logo is obviously very aesthetically pleasing. It comes in this handy little carrying case with a carabiner clip so you can easily clip it to any backpack or if you go mountain climbing. The Dugout itself is very nicely made, it opens just like so, has a magnetic closure so you don't feel like it's going to necessarily pop open easily, only opens in one direction and obviously the bat is spring loaded.  The bat itself has I feel like a good storage capacity, you can probably get like three or four hits. If you have a couple of pokers on the bottom, they are kind of hard to access, I still have not been able to access them, maybe we can try that later. But they are there. It's your pretty basic Dugout with a few enhancements that make it really nice. This is a great option for those who really like Dugouts and are looking to kind of upgrade to a nicer one. So check it out on our website, SmiltCartel.com


Everybody I am Matthew Miller the Fedora project leader and this is a Fedora Council video meeting as I always say but maybe it's the first one you're watching. We try not to conduct our business in meetings at all. We try to do it asynchronously because we're a global community that is hard to get together for one meeting but we also find value in the high bandwidth connections of meetings and occasionally in actually literal high bandwidth video meetings where we can talk back and forth. Particularly about once a month we do a thing where we pick an interesting section of the project or something that needs help or something we want to focus on or something that's going on that we want we invite members of that part of the project to come and give us a presentation what they're doing. Kind of basic thing is what's going on where are there problems where you could use help what the council could do for you and you know other future plans that sub project. So today we have Steven Gallagher representing ELN which is sort of new sub project in Fedora that's related to the production of Red Hat Enterprise Linux and I will let Steven give you the details for that. Welcome Steven. Thanks for having me Matthew. So first of all yes I'm going to introduce Fedora ELN to those of you who either haven't heard about it yet or don't know much about it. As a start we generally do try to refer to it always as Fedora ELN because it is very important to us that this is part of the Fedora project and not a third party not a rel project or whatnot so let me just I'll make sure I put that in my what my rules for saying words I guess that part of my brain. So I hope my presentation is coming along for the recording. Yep looks good. All right so as as we like to refer to it in the in the ELN SIG we call it pulling putting the rel ish on the beefy miracle so some of the videos may not be familiar with that old joke but we once had a Fedora release that whose codename was beefy miracle and it became kind of a meme of its own in the Fedora community. So when we came up with this idea to start actively developing rel in Fedora more and more clearly delineated the term relish kind of came naturally. So let me so let me talk a little bit first about the history of how Fedora become it became rel. So with rel 8 as my example and for and for rel's prior to that what we would generally do is we would stop after a particular Fedora release where we had internally at Red Hat decided okay we're going to start we're going to halt here in the end and prepared this to be the next Red Hat Enterprise Linux. Generally we would we would pick a Fedora release on its release day we would then we would then take a snapshot essentially of of disk it for all of the packages that we intended to have in Red Hat Enterprise Linux copy that internally and then spend about the next six months sometimes up to up to nine months preparing to bootstrap rel or not preparing to but actively trying to bootstrap rel from that Fedora release which was extremely time-consuming and very very painful for those of us me who had to do it and a large a large part of that was because you know Fedora being what it is it's always looking to the future it's always expanding it always has the newest and latest tools and as think as these things go sometimes it's not possible to build it's build itself from its current state so that was not a great situation because yeah it took six nine months a good chunk of time to to turn Fedora into something that we could use to start to hand to the developers to start building rel so we wanted and now as of rel 8 they announced that future versions of rel rel 9 which is in beta right now and and onwards we're going to be coming out every three years on a schedule not when we get not when it's done as was in the past we would slip and slip and slip and it would just you know the gap between rel 7 and rel 8 was well I'm sure some of you have have raised children into call into school age in that time so with only three years to with only three years to work with spending six months just getting it started it was not going to work so a few of us most mostly alexandra federova and myself and a couple of others in the in the bootstrapping team sat down and tried to figure out how can we shorten that bootstrapping time how can we make that work better and at some point and I don't actually remember which of us initially had the idea but we decided that the easiest thing to do would be to never stop bootstrapping essentially take a take a project create a project in fedora land whose purpose was to continuously bootstrap and fries linux so when and so when we started this we gave it we gave it a code name project that eventually turned it turned into eln it was El Nino which is which was a multi-layered set of reference references and in jokes of course el l l is the distribution tag for rel and sento s for enterprise linux Nino is the is the Spanish word for a male child so there the implication in that was that this is the project that is the immature version of what will grow up into enterprise linux and then also el Nino is a type of weather pattern that occurs every three or four years and pretty much always brings storms in with it so I think that reference should be fairly obvious a lot of a lot of furious activity tends to happen in both the fedora and rel communities right around the time that we are heading towards a release so what is eln itself it's a it's no longer el Nino we we kind of back renamed it to be enterprise linux next and it's an attempt to make an early early preview kind of a kind of an alpha but more of a pre alpha of what the next major you know a major version of rel rel 10 rel 11 rel 12 rel 12 hopefully I'll be retired by rel 13 will look like and maintain and then try to maintain those changes and keep them up to date making sure that they build in fedora so how are we doing this well for the a great many packages actually just build as is against rel which is great those are the easy ones but there are a number of packages that are maintained in in fedora that are conditionalized so that they would build in rel or apple it's differently than they would build in fedora now for a lot of so some of the cases for that might be you might be in rel in fedora you're okay with including experimental or unstable plugins or optional optional features that you know a niche group of people might use but in rel you know you maybe just want to maintain only the pieces that the majority of people will use and that aren't likely to break and cause a lot of support costs so maybe you can conditionalize your package for that maybe you conditionalize it to reduce your dependencies which is a big thing in rel because we the every package we ship we have to support that red hat so reducing that number is always a goal we also build sometimes in enterprise linux with different compiler baselines and different op the compiler optimizations or or similar functionality so we would so in eln we always track sometimes ahead of the intended baselines and optimizations for for red hat enterprise linux and another very common one is that with eln and rel oftentimes we try to package pre-built documentation which is kind which is in general a no-no in fedora because we always want to make sure that it's up to date and regenerated but in in red hat oftentimes the document documentation builds in fedora are responsible for some of the longest dependency chains the distribution I mean if you were to look at the dependency chain of any basic python module without building its documentation and the dependency chain of it when you have pythons when you have python sphinx documentation built it is three orders of magnitude longer so that's one of those things that we very very aggressively try to remove from rel and so we can start we can start doing some of that months and months maybe even years in advance when we do it in now enterprise in eln red hat eln that's fedora eln goodness so that allows us to make a bunch of uh just rel specific ish changes but for the most part we try not to disrupt fedora itself we do a we do a series of rebuilds through our through the same koji instance but we do them triggered by a bot that follow that follows along and does not uh it does not uh block fedora packages if the eln package is not building or is or is failing its tests so that we don't interest so that we don't significantly interfere with or delay the development of fedora but in general any package that is in the what we've declared the rel content set is rebuilt automatically in from fedora rawhide every time a fedora rawhide build is triggered is completed uh or more to the point it's actually whenever that build is tagged into the uh candidate tag for or for inclusion in the next compose uh don't need to go into the specifics of that i suppose um lost my train of thought for a moment but uh so what a eln is also essentially the point it with the the point from which we will fork uh the next version of centOS stream which is where which is the open environment where we will uh where uh red hat will do development for red hat enterprises linux n plus one in fedora is this uh what when we were doing this uh in fedora 30 sorry for rel 9 we broke inheritance at the final freeze of fedora 34 so we had a stable fixed set of a set of uh commits that we could then say okay these are going to get moved into the centOS stream uh discrete repositories uh trimmed for sort of uh legal reasons um the history rather is trimmed a bit so that we don't have to get uh so that we uh that's complicated i should probably leave that one out um so during that process uh if you were if you were working towards rel 9 you would build you would do your work on rawhide first rawhide for most of the time until we got to fedora 34 branched and then people who were trying to target to rel would be working on fedora 34 branched for a bit about a month month and a half and then switch over to centOS stream 9 well it did turn out that we uh that that was an awful lot of churn and conf and confusion rained from that so starting with uh rel 10 which we intend intend and expect to branch from fedora 40 we're going to do the uh we're going to do the centOS stream fork off at the at the fedora 40 branch point as opposed to the later freeze uh so the point is the point there being will be from from now on any non-centOS stream you know directly rel work will go it will be going into rawhide and only rawhide will be it will be will need uh dealt with until we get to centOS stream um eln will always track rawhide we've already uh moved on uh to developing rel 10 eln we've got we've made some uh interesting progress there and we are experimenting with a variety of of things including but not limited to the x8664 v3 compiler baseline some some new compiler flags related to link time optimization and similar and we're also we're also monitoring through the the content resolver service um how our dependency trees are growing or or shrinking and trying to keep that headed towards the the smaller side of things but we are generally these days we have we have a compose most days that succeeds um every once in a while like just this past week we had a an extended period where uh the where eln's compose was broken for esoteric reasons but uh in general it's available uh we've got from uh dato from amazon from uh i believe we had some from ibm some from i think i think we had somebody from lenovo who have all been actively working with us to get uh new functionality and tweaks into the uh eln systems so it's been uh fairly effective it's been fairly it's been uh a pleasure to work with everyone and i think that pretty much sums up the explanation so maybe we should next move on to just any questions and what uh what you want and more you might might want to know about uh elan so i'm going to stop sharing my screen because with blue jeans that's the only way i can see your faces when you ask questions still being shared there we go and i put us all into gallery view you can see we've got a small audience uh today but i think we'll we'll put this online so more people can see it as well i've got a couple questions does anyone else have ones to start i'll throw one out there so is eln usable as like uh you know you could do we build a like an installer compose and actually install it on a machine that like an anti-goal for the project so we do produce an installable and installable compose i have on a couple of occasions installed it into a virtual machine successfully this it is not at this time an active goal to make sure that that that is necessarily installable we generally stop at present because we by lack of resources we stop at is it capable of booting the installer that's that's our minimum the viable product as far as i'm concerned uh whether it successfully installs that's that's a problem that uh that the that really requires a subject matter expert to deal with there there are a number of users though that have gone to from a fedora base to eln you know done a system upgrade online that way which tends to kind of work originally that's what we were recommending people do as well if they you know if they wanted to work on it with a container we never i or i never at least expected anyone to attempt this on their laptop and i'm both surprised and pleased by the number of them that have actually pulled that off so the only note for people hearing this and thinking they might want to try that is they probably should start with a minimal fedora install and then move over from there so you're not bringing in a bunch of depths and end up with a hybrid system good advice a frankenstein system i i've got a couple like smaller technical questions and then some big questions uh the first one highly technical is does the eln bill bot have some sort of punny name and if not why not given everything else um it actually does i thought so but it we're actually using the same the same build bot that that mirrors content from centOS stream to rel internally so it and it is referred to as the distro baker um all right so we which which was so named because uh as kind of a joke that stuck the bootstrapping team internal to red hat for rel 8 named it named itself the bakery so naturally when we came when we had to build a bot it became the distro baker that that's better than a lot of possible alternatives along those lines um the other question this one actually is more technical uh so there are these rel conditionals basically choices in packages that are rel specific um is there a process to review those as things go forward and see if they were there for some you know reason related to some weird thing in you know rel 6 and remove and clean those up is that part of eln scope it is definitely in scope is not something we have had the resources to do yet um it generally speaking that's going to be a task that we're going to need the maintainer to be involved with and our so far what we've been our focus has been heavily on making sure that it is stabilized enough that uh it's that that maintainers could start to care about it more right now right now our best our best intention is to make sure that the the maintainer doesn't notice that we're doing it you know it doesn't it doesn't negatively impact them we then we want to move to having them take advantage of it for improving for improving their ability to get something into rel and actually segues into my other questions which is um when this project was you talked about and proposed one of the goals i know was to make sure there were no downsides or minimal downsides for average fedora linux packages who might not care about rel um in practice how was that worked out like what you have people seen disruptions have there been things that need to be adjusted there have been there have been some adjust adjustments made uh mostly because we just didn't realize in some cases that people would get notifications on certain events and we had to we had to work with rel engine to to reduce that fire hose um but for the most part we've actually been pretty successful it was a lot of notifications i did use the word fire hose it's not um but that was that was a definitely a bug to be worked out not a uh design choice so on the other side of that same coin uh are there advantages for fedora maintainers who don't necessarily care about rel does there a benefit or is it sort of um neutral is the best we can hope for well i guess it's it partially depends on whether or not they don't care about rel but does rel care about them uh because if it's you know if we've got a package for something that is central to rel like for example bash that isn't maintained by a red hat maintainer that way i mean bash probably is i haven't looked i'm just pulling a name out of a hat but uh then it's entirely possible that elad will become relevant to them if only because rel maintainers will start make proposing or pushing changes into it uh directly but a direct benefit to them i think it's hard i think it's hard to uh claim one uh off the cuff i'd have to give that some more thought but i don't but in general i think the best we can hope for is not antagonizing anyone all right fair enough i mean there there is the advantage of of rel maintainers suddenly actually care about fedora you know in that aspect and and they do you know they'll go and fix bugs that maybe you haven't had time to get to where those things upstream because they're going to affect rel as well um the question remains is it you know how is that going to last right it's obviously died off quite a bit with the current rel cycle you know before we've always had in fedora before every rel release is branched we suddenly have interest from rel maintainers and developers and then they disappear i think that the process is going to be better now because there's notification and things like that but how much better remains to be and how much does that end up benefiting fedora and a piece of that too going to be working to change the the culture inside of red hat to be to care more about that because instead of instead of before it was a hand wavy eventually for the fedora will become something you care about it's now we're trying to get people to recognize fedora eln as being this is what you need to be caring about because this specific thing is what's going to come to bite you later so fix it now and save yourself a lot of headaches yeah that intermittent caring has always been a problem where you know a lot of times your red hat doesn't even pay it for a while hadn't paid attention for like four years and then suddenly cared a whole lot maybe in a kind of overbearing way sometimes so hopefully this will reduce that but i guess that i recall a certain pizza metaphor involved there right this this does thus bakery right this but this goes yeah actually we're doing a good job of leading into the questions that i noted so one of the things i've concerned about is that you mentioned branching to eln at the f40 fork so it's about nine months from that half when that happens until the f40 release happens so once that is branched how do you keep people's attention on on the fedora side of things when you know rel demands are coming on the other side how to realistically a lot of them a lot of there will probably be a few six months dippin in activity there but not necessarily because there are plenty of packages and plenty of maintenance and rel land that are going to be still trying to trying to keep their fedora stuff in sync because they want to catch they want to pull something in past the f40 you know there there i'm sure that plenty of stuff that happened that will still happen in the kernel just as justin can attest and i'm sure that there are plenty of other packages too that will continue to be developed on rawhide and may yet be pulled over and so caring about it in rawhide means that the that that's what that pulling that in down the line becomes much easier the kernel is typically not part of the branch and it never has been uh every time they've branched fedora for a rail release they branch user space but then kernel keeps going they said a target upstream kernel version that they're going to fork over who's what happened this time it was months after and does that rel kernel now come derived from the fedora kernel the source rpm for uh rawhide will build a rel kernel and will build a um so when it's built against dln it builds a rel kernel it's completely different so that's actually a big change from the kernel in i even up to rel eight right uh yes rel seven for sure where the kernel actually was kind of disconnected from fedora completely yeah so they they used to branch um they've branched the fedora kernel and then you know kind of maintain it completely separately at that point uh and at that point they may or may not pick up some of the spec changes and those things we've made one of the advantages to this setup is now you know all the spec changes everything is happening in arc which is the elin kernel and and fedora kernel and there there are some disadvantages to it from a fedora standpoint and some advantages but the disadvantages are not so bad we know put a pretty good trade off so there are patches that are rel specific and have no relevance to fedora by policy now those are all hidden behind a uh config rel differences and so even though the code is there um unless you are building a rel kernel it doesn't actually um you know the code path taken isn't there and then when we branch for fedora stable releases i go through and remove those things just because so much of our support model given the the single maintainer uh of kernel is you you've got to be able to go upstream so people need to be able to apply patches that they're given um or uh yeah revert patches things like that without having a bunch of of noise in the way that might especially non-developers make it more difficult for them to interact with upstream one quick and i should wait pause i'm going to interject before you interjection haha i should introduce justin here who is fedora kernel maintainer for a very long time and does a lot of other things and has done a lot of other things in fedora including being one of the founding members of the elensig uh i was just going to mention justin did i think twice during that talk that statement you mentioned arc uh without without a preamble so for the benefit of anyone who isn't familiar with that acronym you might want to clarify right so that that acronym and that actually probably should be changed at some points there's been a lot of discussion about it it's supposed to stand for always ready kernel um and it started as an internal rel thing and uh you know they wanted to have essentially a modern kernel turns out it's it's hard to keep up and you're not doing that day to day and we were already doing it for rawhide so it kind of made sense there and like said there have been a bunch of advantages to that setup too you know it's we do have kernel developers actively looking at things you know pretty consistent even after the rel 9 kernels branch there are still people there one of the ways that that's done is because the rel configs are there they have to be reviewed as they come in and so that gets people looking at at the new things coming in for fedora everything is the configs are kept differently and there are several things in there that allow me to do builds for fedora without having to wait for rel process so like if we have a compile bug or something of that nature that that really has to be fixed i've got a patch for it i don't have to wait to get permission to put it in we have a process where essentially it goes into disk it so we can build with it but it doesn't go into the tree until it gets approved that makes sense um uh steven you mentioned uh that the fork kind of goes it goes it flows to centOS stream at some point um can you talk a little bit more about the relationship is that kind of a handoff to centOS stream how does the build or bakery team stay involved on both sides there how does that so the yes uh the bake well the former the team formerly known as the bakery um now uh generally known as the uh emerging rel team uh works on the fedora side uh our you know uh our uh avatar is the fedora eln and we are also heavily involved with the centOS stream project and in fact where we contribute to on both sides we kind of straddle that line so yeah uh we we spent uh i'd say probably about eight months uh smoothing the way for uh for rel rel nine over on that side for shifting our our primary focus again back to uh eln to prep for rel ten i guess so uh is that focus likely to be a wave between the two projects of focus or is there um it's going to be a wave in the same sense that the uh the waves crashing on the beach are a wave some of them will be larger some of them will be smaller and uh and they will be entirely unpredictable okay fair enough um it will not be a nice clean wave so what about fedora server which is something i you know is is dear to you um when we set that up one of the things we wanted to do was make that kind of a clear upstream for the rel server product um is that still kind of in the plans is and how does you know the the emerging rel team work with with you know the fedora server working group um and how does that all connect so you're right that that was the initial intention of the fedora server group and ultimately it i'll be frank we failed in large part because we didn't have something like eln uh at the time or have even the the beginnings of an idea for something like eln uh to to work from we didn't have the ability to change our configuration specifically to build the fedora server we had we were working under the same constraints that we were before which was we can make small configuration changes but not package level changes uh to to what we shipped in fedora server um with that with that plus the fact that that back at that time we were still dealing with the with this uncertainty about you know rel while being an open open source operating system red enterprise linux was developed in a fairly proprietary way once it once it forked off of fedora we i mean the sources became available when we shipped them and uh you know we accept contributions into fedora but it was it was no clear pipeline for someone who wasn't a red hatter to get a patch through that entire system and i think now we have a much better story about that with eln and centOS stream so i guess that um leads me to another question what you kind of governance and decision making at the engineering level in eln so this is one of the things that i think is a clear distinction between the centOS stream thing and sent and fedora project which is if fedora in fedora although there are a lot of red headers involved if fedora makes the engineering decision our headlight um thing for that being the butter fs change right um those are those are made you know with input from red hat for some things but independently um and then centOS stream is set up basically you know as centOS linux was before all of the engineering decisions are for around the main centOS linux were made by red hat even though centOS branded red hat made the decisions and if centOS linux came out with something that wasn't like rel that was a bug like the decisions it wasn't supposed to deviate and centOS stream kind of follows that same thing the engineering decisions even though it's a community project the ultimate decisions you know come it's it's more of a we welcome your input and patches accepted kind of open source project whereas fedora is a you know you make the decision you see where i'm going here where does eln fit into that if i am somebody who is not a red header but very gets very involved like you mentioned there were non-red headers involved like can they ultimately how much voice do they have so i'm going to tell you the truth which may get me in trouble all right that's what that's what we like like which is that realistically and practically red hat cannot say no to what is coming what comes into centOS stream from fedora so if you have something somewhat controversial or just plain brand new fedora eln fedora and fedora eln are the place to push for that it may require it'll require you to work earlier in the process but it is effectively a way to bypass the bureaucracy inherent in trying to get your changes into centOS stream now i say bureaucracy and i know that carries a negative connotation but it's also very important for making sure that things get reviewed that nothing gets that nothing is being supported that is difficult or impossible to actually actually do so for i like in the centOS stream policy to and maybe this is a bad analogy these days but to choosing a supreme court justice for the US government centOS stream contributors nominate a change but it has but and red hat acts as the advice and consent for that change yeah let's let's not touch the third rail on going further on that analogy but i'm speaking nearly i don't know how it is it has been an interesting issue and it's actually something that that's actively being discussed right now on kernel because that's one place where people have been trying to get changes in particularly the hyperscale sig on on the centOS side is you know they've got code changes they wanted the the instance that kicked it off as they wanted some code updated from upstream and a driver that's turned off in rel right the config is turned off the sig would be building that module and supporting it but they wanted it in the real tree and their advantages and disadvantages to that um so there was some discussion about how do we take that how do we worry about you know do we have to worry about this chunk of code that doesn't interact and a decision really hasn't been made yet on what a firm policy would be but i i've heard uh you know a good bit of discussion around it's a lot of it's going to be up to the engineers uh discretion right if it's a dead code path or are they willing to take that and and maintain that stuff you know as obviously getting anything turned on you're or adding a package or something like that if it's if it's in rel it's supported so there has to be an engineer behind it that that supports it but even for you know for other things where you could you know i i'd like this code in there uh there might be a path it's it is being discussed it's just too new to to really have a policy yet i mean it's not it's not impossible that a controversial change made into infadora eln will be backed out when it gets to sent to a stream or but it is a lot more effort to do that than it is to get to uh figure out how to maintain it so still your your best bet is if you want to get something in that's uh maybe a little risky or a little controversial do it in fedora first i would say early how about early is the way to do it right i'm sure i think it's a way to it's a way to influence bigger changes and also have them proved and tested before they're actually hitting the rel level of yeah absolutely and i probably should have called that out but uh flip my mind um i've got a one or two more things is anybody else have questions i know there's other people still other people on the call here i'll throw another one out there um so what do you like how do you define success for eln and do you think you're achieving it right now i define success for eln as red hat continues to pay me and so i'm still working for red hat therefore i'm successful now um in all seriousness uh we will prove success when you know around the fedora 40 branch period where we will figure where we will know for certain as this all worked and can we basically jump straight from fedora 40 branch to developers can start working on rel you know give a give or take a week or two and rather than six months and i think uh with rel 9 uh we we had a great deal of success there i think we we took that six months down to something like seven weeks uh on that so yeah that's pretty good yeah that was that was a big win and i think we can do better uh for rel 10 i think we we're going to be working a lot on some automations this stuff that uh there's some additional automation that should make it a lot easier so i think that's how we'll define success is that we are essentially automating ourselves out of a job oh there's plenty of jobs for you don't worry uh so i guess um my final questions uh first one is yeah oh yeah you talked a little bit about what what the plans are coming ahead um what are the big things uh or are there big things that'll affect things from the fedora side uh or is it mostly you're going to implement on the roadmap of you know the rel 10 development and that's it or are there more big changes in store um i am i can only speak for myself in this case not specifically for the entire yellen sig but i am very strongly backing the uh the packet and source git horse and i think that uh we're going we're going to be we're going to want to see an awful lot more of that happening in the yellen space and that's going to and that and that will naturally filter to the into rawhide as well so that's there's a lot of potential there and i've been playing around with uh the packet source kit for some time now on just a few of my packages and i think there are still some rough edges but i'd like what i really want to get to is an is a point where a fedora contributor can take a patch from upstream slap it on it slap it uh commit it to a source git repository and everything after that is automated everything after that from you know from getting from building it in koji to preparing it for for a uh an errata update in bodhi to uh delivering it and to also to preparing it downstream for rel 10 or 11 uh all of that um i think should be essentially just it just happened once i come once the uh commit is pushed possibly some sort of human review of whether it works well a human the human review would have to take place before the push to source get it we would have to have ci and and and review that was very thorough so then there's the osci team is also very heavily uh involved the project i i think that's a i i'm excited to see that too so i'll be interesting to watch that it's the final question is uh what can we as the fedora council do to help eln succeed that's a good question um talking us up it never hurts lost your audio does that that's just you is it my herd okay yeah you're fine student maybe it's on my side okay um the question was uh what can the council do to help uh very much i think we helping us uh get our name out there let people help help us uh communicate what we're trying to do and especially uh i think one of the best things we can do we talked a little bit earlier about how sometimes there are maintainers in fedora that don't match the uh maintainers in rel and that they there is perhaps some friction uh around you know in those months leading up to rel that's the robolies i want to since we want to be trying to change that internally i think we also want to be uh making communicating that externally that to maintainers that uh you're probably if we do this right you are going to see more more contribution and more and more churn throughout the process and i think we need to work very hard on breaking that those ages old tendencies to think of the package as mine to remember that you are a steward not a shepherd if you will yeah um i guess i i i asked for what we could do so i will take that that part of it but i also want to um there's always a balance there between you know ownership and pride and that like the um there's a tragedy of the commons problem that can happen when when something doesn't you know when it belongs to everybody and then it belongs to nobody and nobody cares and so a lot of these packages where people have that mine feeling also means they've they're kind of invested in that and uh taking that away from people is um hard so there's a balance there to figure out and i don't actually know exactly how to strike that especially with this you don't have to have an answer to that that's why that's why i asked for door council to take it over yeah it's something something to work on so i guess that a general idea of you know shared shared responsibility for things um and uh maybe figuring out you know when when they're disagreements you know i know some people don't like to have any conditionals in their spec files like how to figure out how to take those kind of right that that was a that was actually uh thank you for bringing that up that was a topic that uh was very hot heated when the elans six were started um and in fact to date there have been almost 400 more emails about the topic than there have been actual conditionals added for spec files to to adapt to elan okay that's uh we we're well we're well prepared for if the situation arises we've already discussed it i mean well realistically people thought it was going to be much more intrusive than it was and i and uh did not initially believe our protestations that we were going to try and stay out of their way and i think our actions have spoken much louder than our words because i haven't heard a complaint about that in months that's good to hear that kind of goes back to what my first questions too um right is there anything else okay well thank you very much justin and steven uh ben this is the time of the call where i put you on the spot are you now yes this is the part of the call where i forgot that i should have the tab open ready to it's a little comedy routine we do because i do this every time and then every time i feel bad because ben is surprised uh what what's coming up next month april uh 14th we have leonardo rossetti and others talking about the cube dev sig okay that'll be interesting anything anything after that or are we looking for more uh there are items on the wish list nothing has been scheduled because we're not doing one in may because of the release party so and the one release okay so um if people are interested in uh wow june seems so far off but i guess it's not all right um there'll be we'll see you in the future i guess thank you again and goodbye everybody thanks


President of the Senate Ahmed Lawan has said that the 2009 agreement signed with the leadership of the Academic Staff Union of Universities ASU is unrealistic and not implementable. Lawan, during a meeting between the leadership of the National Association of Nigerian Students NANDs and some principal officers of the Senate of the National Assembly Complex of BOOJA, appealed to the striking members of the Academic Staff Union of Universities ASU to call off the industrial action for the sake of students. No challenge is insurmountable and I want to think positively that we are going to resolve this issue as soon as possible. But first I don't like the 2009 agreement because it's not a practical, it's not a realistic agreement. Somebody just wanted ASU to go back to the classrooms and just sign everything there. ASU may not like to hear what I'm saying but this is the truth. We must understand that there are things that we are going to do, we should do, we must do. And it's government fault to sign things that it knew was going to be difficult to implement. ASU will accept realities and that is I think going to be the starting point and government must not be selfish because we are not talking about ASU, we are talking about our students, our youth, our students, not ASU. In his submission, the National President of NANDS, Comrade Sondi Asifon stressed the need for urgent action by the federal government to end insistent ASU strike permanently. There is need because the ASU are saying they don't have the trust in the Ministry of Education that it didn't say. We want to satisfy as their father and as number two, the number three man in this country is Senate President. We want to see efforts to intervene in this matter. We understand that the President of NANDS is this, but we know through you today we have seen the President of NANDS. And a message is supposed to show it again. We want to go back to class. We want our university to be open. We want this issue to be resolved. We want ASU and federal government to go back to their position. So as NANDS today, we can continue with academic activities.