 sounds like it's working. So, you may all have known that I was working for Red Hat until January 7th. That's, it was a wonderful, wonderful time working there, at a great time, but I felt like the AIDA initiative was something I wanted to do even more than that. So, when I left Red Hat, they took away my laptop. This is a close-up of a repair. My cat knocked my laptop off the desk, and so we ended up having to do the, ooh, I bet this thing has a little light. No, okay. I had a friend of mine do rivet the hinge back together. It's a little closer. He managed to do that without breaking it, which is really stunning. It involves a lot of hammer work, so. Unfortunately, I had to send that back home, and I really like my MacBook Air, but until this morning around 11 a.m., it didn't have Linux on it. And I was gonna give a live demo today, so. I'd like to give a little introduction about how to install Linux on the MacBook Air, just because now I have all of this useless knowledge, and I need to inflict it on somebody else. So, I figure you all have a high tolerance for boredom, because you're in this talk, so. Suffer. So, I did not shell out for the Superdrive, which is apparently the only way you can boot a CD on the MacBook Air. You can't boot from a USB key. I don't know why I assume it's some sort of firmware thing. Apparently that you can do this now, but I didn't have a Linux box, because I was sitting in my hotel room, and I didn't have network access once I did get the installer booting, because the drivers didn't work, so. So, this is what I finally, there's a lot of many, many, many, many other steps involved here, including a lot of cussing, so. And giving up at 12.30 a.m. Anyway, so, this is how I ended up doing it. So, I created a separate partition. Went and got the, this is the network installer image. It's supposed, you're supposed to put it on your USB stick and boot from that, but as I mentioned, we can't do that. I downloaded it, so, feel a little guilty about this. I downloaded the 64-bit install CD on the conference network. I always feel, I've always thought, gosh, what are all these, why do people think they need to, download kernel trees whenever they're at a Linux conference? It's so rude and inconsiderate. Yeah, well, okay, I didn't have Linux on my machine, I'm doing a Linux demo on. So, if your network was really slow and urban-ness last night, I'm sorry. All right, so, I then put the CD image on a USB key. Remember, I can't boot from it. So, I did this thing I called Frankenboot. So, you can, I could boot by getting this boot image on a partition, but once it starts up, it wants to boot from the network. It wants to, sorry, it wants to finish the install through the network, which as I mentioned, you know, we don't have any. So, if I'd had a Linux machine, I could have created a bootable image out of the CD. I did not have a Linux machine. So, what I did is I just put in the SysLinux configuration files and the initial RAM disk and the kernel image onto the USB key image, and then I put it in the Linux partition, and then I use refit to boot it. So, okay, now I have an installer. Fortunately, it asked me where the install media is located. It's actually on SDV. Right, except the wireless driver still doesn't work and magically I just figured out through the power of the internet that I needed to get this thing, some version of the BroadCam wireless drivers. Anyway, so here we are. I think you probably came here for the easy kernel development with using more Linux talk, unless you came here for the other talk that was canceled and replaced with my talk on Monday. So, in case you think this is even more awful than usual, that I have some minor amount of excuse, although I probably would have waited till today to write the slides anyway, so. That's all, installing Linux is like, okay, I did need it, but it was a really, really excellent way to procrastinate. So, the cool thing about user mode Linux is that you're just running a process on Linux. It's just like normal, hey, this is like a program that you're running whenever you compile something, a C file and you get, you know, and you run it, it's just a process. So, really kernel development is now user space development. I know there's, it feels to me, I'm always trying to destroy the mystique of kernel development like, oh, it's so hard. It's, okay, it sucks, it's hard, but it's not as hard as you think and it's not magic. And this really takes away, I think, a good chunk of the magic by saying that you can use wonderful things like GDB, yes. I tried to go find a quote about using GDB, something like, I would rather poke my eyes out with, you know, seven razors dipped in lemon juice than use JDB, but I figured I could just make up my own, like that. Yes, because the development environment on Linux is so incredibly awesome. So, I actually wrote up, it was so annoyed with the process of getting UML running, UML is not the language, it's user-mode-linux. But to me, that's what I think of when I see that. That I actually wrote up this webpage a couple of years ago online, you can look at it. That has all this stuff on here, so if you wanna go follow those instructions, you can go to that webpage. I think it's like the first UML tips or something like that will get you that on Google. So, part of why I wrote this page is that at the time, user-mode-linux website had a very large amount of documentation. And a very large amount of that documentation, I think nearly 99% of it was out of date. And there was a whole lot of stuff about how to get the latest patches to make user-mode-linux work. And then I realized about a day into that, that actually mainline Linux worked now with that user-mode-linux actually compiled and worked. So, just go get the regular source tree, you're fine. This is the most important part of using user-mode-linux. Usually when you're compiling or doing anything interesting in the kernel tree, it automatically guesses your architecture, which is of course either 64-bit or 32-bit Intel, ha ha, right? But I've worked on PowerPC and stuff like that. So, what you have to remember is to always tell it that your architecture is actually user-mode-linux. You can edit this in the make file, but that's gonna cause little spurious patches whenever you're doing diffs and things like that. So, I prefer to just put it on the command line and just repeat it to myself a lot. Just don't forget, and when you forget, that's what you have to do to fix it. You have to delete every single extraneous file. So, and that's very painful, and then you have to rebuild your entire tree, so just don't do that. One of the things I did to reduce the pain of this of making that mistake is I put my output, I build with the output going to a separate output tree, so it doesn't build inside your source tree. So, when you do make MR proper inside your source tree, you don't get, you don't have, because usually what I do is I forget to do anything at all, just type make, and I end up compiling in my source tree, and then I can do make MR proper, and everything is better, so. Once you have your user mode Linux source tree down, you need to get a dot kernel config file. I put one up on that webpage that you can use, it has things set for the most part, meaningfully. You have to remember to use ArchEagle UM, whenever you're running menu config, anything that involves make, you have to do that. So this is, if you're doing file systems development, the most important configuration option. Without this, whenever your machine crashes, the disk is in some sort of like undetermined state. It's like having a disk driver that doesn't actually write to the disk. When it says it does, it just writes when it feels like it. So I had a number of like, when I first started doing this, I had a number of spurious bugs, it's like, that's strange, seems like these things are being written out of order. Oh, that's because they are. So that's turned on in my configuration file. Yeah. For most people though, if you're not doing file system development, you probably wanna be using the host of us. It's super easy, you just have a directory, you just point UML edit, life is good. You can just edit your files directly and all that stuff, but for the rest of us, that's not what we're gonna do. There's a bunch of cool stuff in kernel hacking that you should go and look at, and every time I look at it, there's something new and useful in there, so. Go take a look. The stuff to do with like, configure or debug memory allocations and things like that is pretty cool. So actually the most difficult part of running user mode Linux is getting a working root file system. This has become a lot easier over recently, and there's like automatic tools to build one for you. The most recent one I built was using Debian Bootstrap. One of the things that's been a super big pain for me during development is that I've been switching back and forth between 32-bit and 64-bit laptops, and you have to have a different root file system for both of those, so extremely irritating. Fedora has something, I don't know what, so I figured I could like edit this if somebody has the answer. Collaborative presentation making. All right, well, who likes Red Hat anyway, so. So this is the part where you should not abuse the wireless network, and I'm not sure what my bandwidth cap is for my hosting, that's about 170 megabytes. But when you get home, maybe you could download it if you really want to do this. This has all of my Union Mount project development stuff on here, so. Union Mount is this incredibly boring Linux file system VFS feature, so. If you find all this strange stuff on that root file system, that's what it's about. Okay, so this is another great way to waste an entire working day. Is that, so the root device for, if you're using one of these external images, instead of the host file system, the root device on, you need to populate slash dev in your root file, UML root file system. It wants, rather, so your normal Linux boots up with slash dev SDA as the root file system. What I like to do is I like to not start anything complicated, like any demons at all in my user mode Linux installation. So that's not, that would go through normally and populate slash dev for you. So what you have to do is instead go and mcnod yourself explicitly, and this is a wonderful chain, a little extra feature that recently that the assumed naming changed from one of these formats to the other one. Great, okay, you get really familiar with this particular error message saying that user mode Linux can't mount the root file system. It's like, ah, yes, for which reason this time? There's a lot of reasons. This is another reason why it's not mounting. For some reason, I think the way that we normally type, it's like you always type ing not ign. Apparently you always type udb instead of, or db instead of bd. I don't know if you can even tell the difference, I can't, it's like even if you're not dyslexic, usually you'll become dyslexic with b and d reversed like that. What's really hysterical about this is that uml now detects this and prints out a little message, hey, you probably transposed these two letters. Would you like to check that out? And I just think it should be like, okay, we know what you meant and we're gonna transpose it for you, but whatever, at least it's got a message now, so. This is how I remember. You say block device, block, but you see me sitting at the computer, uml block device, nah, nah, okay, ubd. That's your mnemonic for today. So here's another, this is your next stumbling block for running user mode Linux. Theoretically what you would do is you would, once you've run make to create the image, what it does is it creates an executable named just plain Linux in the top level of your source directory. You could just run that thing, right? Right? Not so right. So the way I usually run user mode Linux is under gdb, that wonderful bastion of awesome debugging this. It's, I run it with a set of commands automatically. This first one tells it where to find the, this is the kernel command line basically, tells it where to find the root file system image. So that, if I was running this in source Linux-26, I would then have in that directory a file named uml under bar root, under bar image and that would get mounted inside user mode Linux as a file system. RW says that it's just the kernel command line saying to mount the root file system, read, write. It's not about to pop up. So the zigzag v thing is extraordinary irritating. If you just run it, start gdb without this, you'll have the process pot, you'll have gdb, it'll drop into gdb every microsecond or something like that and say, gosh, I just got a signal, what should I do with it? It turns out that uml uses zigzag v or at least it uses signals internally to emulate various things in the kernel. So what you need to do is you need to tell gdb to ignore it. Otherwise it's gonna try to get involved in everybody's business all the time. So I usually use uml in this wonderful awesome way. This really cuts down in your like booting time, your repeat time, how long it takes to test something new. I like to just boot direct set the init equal command line option so that it starts the test script immediately, it doesn't have to, it doesn't go through any of the init levels or I mean, even in it level one, it still tries to start services and ridiculous things like that. Who needs those things? So I tell it to just start my test script immediately. This other thing in here, UBD one, some of my tests need an ISO image, a CD image. So that's just another block device that it can use. So we've got, we remember zigzag v from the last one. Sig user one is great. This is, when I'm interested in something which is usually when it's hanging, why is it hanging? I just send it, Sig user one, it pauses or it drops into gdb and then I can do whatever I want. Dasho says only sends the, pkill says find the thing with linux in it, any process with linux in it and send it this signal, Sig user one and dasho says only send it to the parent. Otherwise you're gonna get like this, you know, UML has multiple threads running and you're gonna get all these different threads being unhappy. Great. Ooh, 15 minutes in, that's wonderful. This talk's probably gonna end early unless you have a lot of questions so. All right, so this is how I spent most of the last year and a half. Not coming up on two years now. This is what I looked at every day. Okay. Hooray. So here's my source tree. Let me look at my branches. Because who knows where I am. Oh look, only one branch, that's so amazing. Huh, I've been doing random hacking as a temporary commit xxx. The ones before that are actually working. Implement union-aware-else-set-ex-adder. That's really awesome and fun. Cool, not really. All right, so let's compile. This says, the dash c part is not necessary at this point, but I'll just take it out. That just says that's where the source is living. So do, do, do, do. Oh, I'm running, I have ccache installed too. Oh my gosh, it doesn't work. That never happens. Well instead of debugging it here, I'm going to check out, actually I'm gonna go ahead and go two back, two branches back, so currently, or to change that spot. Compile, compile, compile, compile. Usually at this point I get bored and I switch to the other window, but you know, it's not all that long. There we go, ta-da! That's, and then here's my, the touchpad is way too sensitive on this. That's gonna be annoying. Run. There's a ton of debugging output on this. Ah, it doesn't work! Oh, that never happens. Okay. So this is the, where, this is the script that actually gets executed when it starts. This isn't the init equal, whatever, script. Here's a little tour of my source base. I mean, just trying to show you, it's kernel development. You can write a whole bunch of scripts and never have to type anything and never have to reboot anything and it's just awesome. Okay, run, test, it's aged. Okay, so this says, this is the set of tests. This is of course some random ridiculous packed together test suite, which is nonetheless, in git, yay! 10th commit for moving laptop, yes. I try not to check things in for good. Okay, this is the best part, I think. No need to shut down. Just ctrl-d, oh, ah! This happens a lot. It's gonna complain. This is a stack trace and it died. That's, it's very unhappy about that. But that's much better than actually having to shut down and the benefit of that is that it does a dirty shut down on your disk. So if you have some sort of bug in your file system, it's gonna show up. Whereas it wouldn't if you'd done a really nice shutdown. So that's my excuse. Really, I just never got it working, so. There we go. It works. Oh no, still doesn't work, because this is my life. So this is like, part of what I'd like to point out here is that it takes like 20 seconds for this to compile. Doing, oh yes, I forgot to rerun. I have to rebuild my test root image. So that's, I don't know, three seconds. And then it boots. And then actually getting to the test is like another two seconds, right? What my tests are incredibly long. So this, you can see it just skipped the FS specific tests. This part takes forever, but I'm used to that too. So what I usually end up doing is heading over here, compiling something. So we're gonna try this because I happen to know that this sort of works. I can go ahead and do this because the magic of Unix is such that the old file image is gonna stay there and continue running. This is running off that Linux binary. This is gonna replace it, but that's okay because the other one is still open. Okay, I'm bored, I'm bored. Ha, die, yes, okay. What I'm gonna do here is I'm going to turn back on these tests because I got them working. I'm going to, I started running make from here because you don't want to overwrite your UML disk image while it's mounted. So that way I have to actually not be running in UML before I can rebuild the image. So this is a ton of debugging output. So success, success, success, success. There aren't any existing tests for EXT2 correctly handling directory entries because we just got it right like 10 years ago and just nobody ever broke it, but that was very inconvenient for me. So, all right, so that's my, I never rebooted anything, I never, I think this is a huge advantage over doing VMware or any sort of entire virtual machine, like Quimoo or anything like that because, let me just go back to this because this is super boring. Everyone knows how to do VMware and things like that, but the thing is is that you don't need to emulate every hardware instruction in order to emulate enough to do a lot of interesting development in Linux. So this is much faster, it's much smaller. The root image I have is way bigger than it needs to be. It's really around, I don't know, 200 megabytes, something like that. You don't have to reserve any memory. It's just hugely that much easier and faster. So I can do a, I can test a new kernel in like 30 seconds until I get to the part where I actually run my tests. Usually what I do is I move the tests that I'm working with up to the beginning of my test scripts and then I run it right away. So getting that change, compile, test cycle down to as few seconds as possible is vital to making things work. So I threatened to teach you a little bit about VFS. I'm only gonna do a little bit of complaining about one particular stumbling block to VFS development. But VFS is the virtual file system layer in Linux. It's what's on top of all of the file systems. So the first reason why there might be very many people working on the VFS is that it's super, super boring, very, very boring, but also kind of complicated. And something I'm not gonna put down on the slide is that perhaps some of the VFS developers are a reason why you wouldn't wanna work on the VFS. I'm really bitchy some days. No, well yes. But I think this is the real reason why nobody wants to work in the VFS. Struct name iData, I remember first encountering four years ago, and thinking, what is this? I don't get it. And so I spent a few months being like, I don't know, I don't know, and reading the documentation. And then I realized nobody else got it either. Nobody, so struct name iData, this is a collection of random pointers to stuff that you might need later on. It's like the world's biggest stupidity here. There's more. Check it out, there's a union. Open intent, nobody knows what an open intent is. We just know that if you don't pass it around, sometimes you get kernel panics, you know. It's, this is, I have, if I were to be locked up in prison for five years, what I would do is I would fix, not referring to anyone in particular, I would remove name iData from the kernel and that would get me, make me a lot of friends. So like this thing right here, path is like points, the queuester last, right? This is something you need to like free at random points. And yeah, it's like an object oriented programmers nightmare. Okay, so excellent. We've got lots and lots and lots of time to be early. I'm along with Mary Gardner. We're found, I'm founding a, the iData initiative, which sort of sounds like a really cool Angelina Jolie movie, which involves like spies running around and things like that. The born conspiracy, the iData initiative, yeah, cool. Unfortunately, there's no repelling off buildings or high heels or anything like that. We're just getting more women involved in open source. And specifically we're going to get them involved in open source careers. The best way to be involved in open source is to have somebody be paying you to do it. It's always best to be enjoying what you do and making living at the same time. Mary Gardner is kind enough to do this with me and save me. And the question we're working on this week is figuring out, so there's been about 10 years of women in open source activism of various sorts done entirely on a volunteer basis. And Mary and I are, what's our estimate of how many hours we've total spent? I don't know, over 10 years, 20 hours a week. A lot of, I don't know, that's many, many hours, 1,000. 10,000, probably. And all of that ends up, you know what, people will always say, yes, totally support you working on this thing, but when it comes to your annual review, somehow, this never seems to get on there. So we're looking to see what we can do. There's a bunch of projects that you just can't do unless you have someone who can concentrate on them. Either it just takes sustained effort or it just really sucks and you're not gonna do it unless you're getting paid to do it. It's a usual problem with volunteer work. But we think that we could make a significant difference if we had full-time people working on this. So here's a sample of the kind of projects we're thinking about doing. One of these is First Patch Week. It's a little bit inspired by Canonical's BZR team. They have a concept of a patch pilot where, and this is the important part, each person spends one week out of five with their primary responsibility to see patches that go to the mailing list and work with the people who sent the patches to get them actually integrated. The important part is that that's their number one priority for that week instead of being what you do after you get everything else done, which, of course, it's never done, so you never actually go and help people with their patches. So this would be getting certain companies to participate and say, okay, we pledge this week, we're gonna put these set of employees on First Patch Duty. We're gonna line them up with people who want to do patches. Often what people say to me at this point is, oh, well, I don't know if there's a bug that's easy enough for someone to pick up in a week and finish. And I agree, all those good bugs we fix because we're busy avoiding fixing the hard bugs. So instead, we'd have specific projects more or less symbolic or important or difficult. So don't worry about having actual bugs that someone can fix in a week. We're thinking about an open source project scorecard we can go through and say, have some sort of standards or metrics for how friendly they are to new contributors, how well the documentation is done, whether you have prominent or frequent incidences of people being total jerks, specifically to women, but also in general. One of our set, our theories is that if you fix the things that make it difficult for women to be involved in open source, you're gonna fix the things that make it difficult for everybody to be involved in women in open source. Everybody would love to be involved in women in open source for everyone to be involved in open source. So whatever changes we make or things we notice are going to benefit everyone. And our third project is basically providing a consulting service, you know, people walk up and say, gosh, I would love to have more women developers at my company, what do I do? I know, I'll print a pink t-shirt, you know, and like, well, that can be one element of a well-coordinated strategy, but no. So we could at least help people with understanding the basics of what not to do and with some work, we can perhaps help people have a successful women in open source outreach program from the beginning instead of figuring it out as you go as we have for the last 10 years. So at this particular time, we're looking for project suggestions, measurable goals are very difficult. There aren't any numbers right now. Probably one of our measurable goals is to simply create, do an initial survey of women in open source at this point and funders in contacts. So this is like not, hey, you should talk to Microsoft about getting money, but I know this person, specific person at the Microsoft open source office who controls the budget for trying to look like we don't totally want to destroy Linux, that sort of thing, so. Please email us, this will go to both Mary and I. And I think that's it. Questions? I'd like to just ask about how to get companies involved in actually supporting initiatives to get more women. I mean, company managers often seem to be, well, if it doesn't directly involve earning more money, then why should I be interested? So how do you get companies interested in supporting, having more women involved in working in open source? It's interesting to me because, so it's interesting to me because I'm always surprised by how supportive people are, especially in management of this kind of projects. A lot of companies and managers seem pretty no nonsense and they're not going to be interested in anything that doesn't directly result in revenue. But when you actually talk to people frequently, they discover, or you discover that they're actually extremely interested in helping women in open source. They just don't know how. So my particular philosophy is not to go around trying to convince people who are not convinced already but to find the people who are very interested. One of the things I'm finding is that there's a demographic change going through in open source right now. A lot of people are having kids and a lot of those kids are girls and a lot of those girls are hitting the age when their parents are saying, hey, I'd love for you to be interested in computers too but strangely you don't seem to be interested and everyone mocks you at school when you say that you use Linux. And that's suddenly like an awareness thing that, oh, I can't share this thing that I love with my daughter, so. How much access to the hardware do you have with user mode Linux? I can use it for hardware device drivers? So user mode Linux, there's a line that it's useful for kernel development above that line and not below that line. So basically user mode Linux emulates all devices. It just uses, if it's faking up a disk, it just opens up a file. Underneath it, on Linux. So if you wanna do, there's actually, Kristoff Hellig did, I think, two years ago at LCA a talk on how to do PCI driver development in QEMU. So you'd wanna go to a lower level of emulation for that. There's, yeah, you wouldn't do any Ethernet driver work or anything like that in it. Mine's actually a bit of an addition to that one. What about SMP? I realized, as for the talk a couple of days ago, we had, you know, SMP is pretty much a solved problem, but how does that work with UNL? I have no idea, so I'm gonna look at the configuration, something I've thought about. What is it doing? Is it doing the wrong thing? Yes, right. I think it's single threaded. Yeah, okay, yeah, I don't think if you're doing SMP work, UNL's not for you. Stunned them into silence, excellent. Do you mind if we go with the new person first? And then we'll do follow up in a second. Cueing theory. The test cases that you were running were just like in your init script. Is it, I guess, still possible to have an interactive session? So if you do want to just have a shell and be doing stuff. Yeah, it ends in a shell. So. Oh, so that shell is in the pretend Linux. Oh, sorry, in the user-made Linux. Pretend Linux, I like that. Where do I do this? I'm sorry? Sure. So this is, this is drop into a shell so we can fiddle around. That's where I do it. Yes. Oh, sorry, sorry. I don't know why I did release. No idea. Is it? Oh yeah, three, well, that, really? Three cores? That's very odd. I usually do. Yeah, I think you have to go do that. That's like over here in the setup script. Oh gosh, this is so funny, you're like, you should always write comments, even if you think no one will ever see this. Well, okay. Yeah, this is exciting. I had to add a user for something and of course I decided I would, no, didn't want to ever do it twice, so. Is there like a bunch of test suites for the kernel? I mean, are you a brave lone ranger writing these scripts to do these tests on the kernel or of other people? Are there a bunch of other scripts somewhere that can be used to test other aspects of the kernel's operation? There are many scripts somewhere, which is a really, I think, excellent description of it, so. Generally, I'll get to you in one sec, okay. Oh, okay. Yeah, yeah, go ahead. Well, I just want to give the general theory of kernel testing, which is that every so often someone says we should really have a kernel test suite and then create a kernel test suite and then nobody adds tests to it and then it dies. And so there's multiple of these lying around. Right now, the current iteration of that for file systems is XFS tests, and what I really ought to do, but I have not done, of course, is move all of these tests into XFS tests and then just run that and have this be part of it, but I haven't done this. Oh, the other one, of course, is LTP, the Linux test project, so that's got IBM and it's lots of people involved. It's very active. I don't think it goes specifically to a lot of file system tests, but it's a really good way of stressing the kernel. It tries to call system calls with invalid argument combos and all that sort of stuff, so check out LTP. Yeah, there's like FSFuzzer and things like that. I mean, there's a bunch of random stuff all over there, but it's the usual problem with test frameworks that, yeah, they aren't quite right for you. It's just easier for you to write your own scripts, which have much better comments and run faster. All right, I think that's it. Thank you, everyone, for coming. No, we still have time for a few more questions, and there's one up there. Sorry, I'm not gonna let you off yet. Everyone be, oh crap, okay. Would you like to talk to us about the union and file system stuff you've been doing? Please. I would not particularly like to, but I can do, do you have anything in mind, like current status or? So, union mounts is a project to basically replace union FS and AUFS with something that could ever possibly be conceived of being merged into mainline. I did some new stuff, which makes it possible, I think, I even applied for a patent on one of them. So, for Red Hat, so it's open to GPL software and all that kind of stuff. So there's, it's new, if it fails, it'll fail in a new and different way than the previous efforts in this direction. I've been working at it for about a year and a half. I took it over from Jan Blunk, who worked on it for a couple of years, that which is, you know, people have been working on this general problem for about 17 years. It's, I've done two in-person code reviews with Al Vero, which I mean, it's hard to tell that he ever doesn't detest the entire world, but he actually was really positive and had a good time reviewing things. It was stunning, I mean, just, I've never seen anyone who could pick up code so quickly and just be right all of the time. So, he has looked at it, but, you know, everybody's got their priorities and I think it's still just not up there. So, where I am right now on it is, I'm doing an EXT2 cleanup, as you could see, over here, with my, yeah. So, just to show that you can implement, you can make the, the idea is I'm pushing a little bit of the ugly into the underlying file system. If I can show that you can do this incredibly cleanly and beautifully in EXT2, it'll be a lot more convincing that it's just not gonna be a huge overhead for all the other file systems. So, but I decided to stop working on that full time and start working on the ADA initiative because I feel it's more pressing and also because at this point, what I really need to do is get Alfiro to actually take a look at it and start banging on it a little more. So, it's in maintenance mode, it's like my 10% time project and people always bug me and ask me about it, but, you know, I do what I can do, so. All right, great, now really stunned into silence. Oh, one question about woman in Lenox. Stats from a UQ introductory programming course, there were 256 men and under 50 women. Most of them were reluctantly doing it because it's compulsory in the multimedia course. Wouldn't you need more women coming into university doing IT before you can get them developing in Lenox? Yes, so, there has been one report on the number of women involved in Lenox in any measurable way, and that comes out to somewhere between 1% and 5%. In the closed source computer programming world in general, or all computer programming in general, that number's more like 20 to 30%. My particular feeling is that open source is far more influential and visible than closed source. You know, all the reasons that we love open source and are working on it instead of some private project that'll get canceled and all our code will be thrown away, instead of some project that you'll work on for several years, and put your code on the internet and nobody will read. It's a very, very important difference, but I am perfectly happy to steal women from closed source at this point. We're focusing on late college early career women, simply because that's kind of what we remember or we've always been at that stage or I don't know, something like that. I would be interested at some point in trying to get women into computer science programs early in college, like the first year of college, by pointing out that there's this other alternate route which involves getting flown to Australia for free and drinking a lot of very expensive alcohol. So that's a, which I don't really do anymore, but that there's all of these wonderful, fun advantages to working on open source that you just don't get if you're in some programmer dungeon inside of IBM. Unless there's any more questions, I think we could fit another one in. No? Can we, you know? We're done. We're done. We're done then. A 20 year old problem that's like almost intractable. It's an enormous boil the ocean style issue. You're talking about union mounts, right? Yes, because I think this project is easier. Is Al Vero like, he cares that much about women in open source that he won't accept your patch? Perhaps, perhaps that's an, he has a young daughter. Yeah, yeah, I decided that this would be easier than getting any form of unioning file system actually merged into Linux, so we'll see. Okay, we might put our hands together for our speaker.