 Let's start with Sarah. So I'm Sarah Sharp. I work on USB support, specifically USB 3. And I do some power management within that as well. Hi, I'm Taejun. Nowadays, mostly I spend my time working on state groups, control groups, resource management. But I also work on world queues and persevere memory allocators and stuff. Nice to meet you. Is your mic on? Yeah. And I'm Linus. And I think Greg spoke the other day. I don't actually do any work anymore. I just, I manage people. I turn to the dark side. And all I do is merge other people's patches these days. Greg, I maintain some subsystems. I also release the stable kernels. Thank you. So I'm going to start with some of the questions right away. First question, has Linux kernel development become more focused on embedded and moved away from our traditional kind of enterprise-y server thing? And how do we keep that in balance? Anybody want to start? I mean, embedded today is what enterprise was five years ago. I mean, you have a quad core in your pocket. But no, the fun thing about Linux is all the changes that you make have to work on all of the things. So the enterprise guys didn't care about power management, but the embedded guys did. It turned out the embedded people got power management and the kernel and all the enterprise people were like, wow, you saved us a couple million dollars in our data centers. Thank you. So it works for everything. So enterprise is the same as embedded these days. It works for everything. Yeah, I mean, if you look at just the last merge window, most of the actual code was the embedded side. But that's mainly because the embedded side has all these wild and wacky devices. And most of the kernel code these days is device drivers. But at the same time, while the embedded side and arm gets a lot of, like, mind share these days, another feature we did was scalability to, like, 200 core machines that people are looking at in the corporate world. So we have a pretty good balance, I think. So the embedded people might outnumber us, but they haven't conquered us yet? No. I mean, the embedded people have numbers, but at the same time, I have to say, the embedded people are very fractured. Right. And they all fight with each other, too. So there's a lot of stuff going on. And it's actually getting much better than it used to be. But the big machines are still where a lot of large companies put a lot of effort in. And they seem to be more streamlined and know what they're doing sometimes. Other comments? So I don't necessarily think that people need to do anything like special to match the balance. Because, like, as the embedded world becomes more and more important, I mean, there's more research to it. There's more engineers to it. And if I look at the patches, even for WorldQ coming in, like way back, the embedded changes, the changes coming from the embedded world would be like really fringe, you know, fractured thing, which doesn't make any sense in general sense, in general environment. But nowadays, I mean, there are a lot more engineers. And of course, if you have more engineers, you have more experienced ones. And you have these changes which are generally useful. So I think the balance is kind of finding yourself as the amount of resources, engineering resources coming in from embedded world is, you know, increasing. So I don't really think there's anything, you know, special that you need to do. I think as a driver maintainer, I do have to balance, you know, I test all of my code on, you know, my desktop machine. But then I also have to balance the, you know, the XHCI platform driver as well. That's a non-PCI driver. So that's in my mind as I'm testing and looking at code, like, is it going to break the embedded side? It's definitely more prominent in my mind these days. Okay. So something that we had a lot of positive feedback last year at LinuxCon in San Diego was the Linux community's been growing in scope and scale and diversity over years. How have we... How do you give us a score? How are we doing and growing? Sarah, you were involved with some Linux Foundation programs with interns, getting more women in open source. Sure. Comments about that? Also, so last year, one of the things we discussed was that we bring in a lot of new people into the kernel and people do one-off patches. But there really needs to be a way for people to get a larger, beefier project within the kernel and get some one-on-one mentorship. So one of the things that we... that I coordinated this year was I coordinated the Linux kernel project under the FOSS outreach program for women. And that's a three-month internship program for women to get involved in open source projects. They get paid $5,000 and they get a mentor in the community to help them take on a larger project. So this is part of getting them actual mentors and getting them into projects and then getting them jobs in projects as well. We have two interns here that are going to present about what they worked on in this internship program over the summer. So if you want to come to that, you can come to the next session. And they're both looking for jobs. And they're both looking for jobs if people want to hire the kernel hackers. Comments about diversity? I was one of the mentors. I had an intern, so she did great. I mean, she had 60 patches in this last merge window, so that's good. Wow. They're in the staging tree, hey. But she took a TTY driver. Some people accuse me of making her do really, really mean stuff, but I keep track of all the kernel statistics. And something interesting happened in this last merge window. It turned out in the Czech Republic, a university professor made all their students get a patch merged into the kernel. That was one of their assignments. And we got about 20 different patches and about five of them, three to five of them said this was really easy. It was not hard at all. Thank you very much for letting me get a good grade and I'm going to keep doing it. So they did it. In Texas, some of them were real code fixes. So that was great. That professor did a wonderful job. So apparently we weren't that scary. We're not scary. As part of the outreach program for women, on the kernel newbies page, if you look at the page for the outreach program, there's actually a first patch tutorial that walks you through base Linux install, what packages you need to install, some basic get commands, and how to make a well-formatted patch for the community to send it. So we have better tutorials now because of that. I also want to say that the OPW interns are doing real work. One of our interns is working up on speeding up x86 boot process by doing parallel boot. And so there are some bigger picture things that our interns are working on. I'd like to say that the kernel... If you just look at the numbers, we have an amazing amount of developers and the kernel is, in some respects, it's a hard project to get involved with because it's just very big and very complicated. In other respects, it's actually of all the open-source projects, it's somewhat easier than many others because we have so many different things you can do. I mean, there are people who come in because they're interested in doing drivers. There are people who are coming in because they're interested in low-level CPU stuff. There are people doing all these small incremental things, especially in the staging tree trying to clean stuff up. So the kernel, in many respects, has more opportunities for new people to come in than many other open-source projects. And I think that's why you can see that the kernel actually has a ton of developers, and we get patches from 1,000 people every single release while many other open-source projects are really struggling to just find five people who are involved. So I mean, people talk about how hard the kernel is, but at the same time, just look at the numbers. It can't be that hard to get involved. So first of all, I didn't do anything to encourage new developers, so I'm sorry. But I want to make two observations. The first thing is, one, you know, if you look at any part of kernel, usually any part of code pass, there's usually between zero and two people who are paying attention to their part of code. And it's not a lot of people, and a lot of, I mean, if you look at, if you go into a file and try to spend two hours trying to understand certain part of the logic, in 70% of cases, you will go, oh my God, this is stupid. So, seriously, there are so many things to do, so there are always opportunities. And the second thing that I want to, I observed over the course of this year was that I'm noticing a lot more of Chinese developers coming in, especially from Huawei, during the past two months. I think they're doing something systematic, like creating a new color team. Are there people from Huawei here? Yeah, you guys are doing a good job. I mean, it's really increasing, because I can see that many of these guys, some of these guys are not really experienced in how this thing works, the development process, or how the environment is set up, how the common conventions are set up, but they're still trying to systematically raise new corner developers. And I think China is really in a good position to build a new group of corner developers, because they have so many people, and very strong technology industry there. They have R&D centers from all the big companies and local companies. Yeah, I think it's very increasing. Yeah, I think we're going to see a lot more new developers from the new time of office. Yeah, I think it's hard to think of a place in the world where we don't have some patches coming from these days. We've gotten from Antarctica before, too. Antarctica? Antarctica sent patches. So, I'm not sure who this question was focused at, but apparently there's an opening for a CO at Microsoft. Was there any interest from our panelists? I'll move right along. So, yeah, one other question. Actually, this is a question Jim got asked yesterday, or asked yesterday. What's the most embarrassing place you've ever seen Linux used in person? So, I saw it once on a... like the infotainment system crashed, and then I saw the Tux logo, and that was kind of embarrassing because it crashed because I saw the logo. It's not so much. I've seen that, too. And what's really embarrassing about that is when you see the kernel messages scrolled by, you see version 2.2.18. And it's like, Christ people, that was 10 years ago. Give me a chance. So, sometimes the embarrassing moment is not so much that they're using Linux. It's that they're using a really, really old version of Linux. Yeah, that's happened to me more than once. Usually, right after I've introduced myself, I have to put my hat in on Linux to the guy sitting next to me and said, you guys. So, another question. Looking beyond your lifetime, your dust, what are your hopes and expectations for Linux next 10, 15, 20, 30 years? Some of us have to go further than Sarah said for getting to that dust stage. I mean, my big goal is that I want to see Linux continue to succeed, and we have to continue to change, to work with all the hardware and all the devices out there. And if we stop changing, we stop our rate of change and stop doing that, we will die. So, I mean, I'm sure that our community keeps growing and that we keep changing along with the rest of the world. That's my worries. So, I want to see it happen. Yeah, I mean, I can't really argue with that. One of the fun things has been that, especially the hardware platforms that Linux has been running on, and through the hardware platforms, and the usage that Linux has seen has been changing so much that, despite doing this for 22 years, it's very different today than it was 10 years ago, than it was 20 years ago. And the only thing I can hope for is that 10 years from now, 20 years from now, it's going to be different still, just because of the different usage patterns and the hopefully hardware innovation doesn't stop just because shrinking stops. So, for me, the short-term goal is getting Sigurd in some usable form. And hopefully you'll live longer. I'll live that call. Hopefully that won't take 30 years. Yeah, but I mean, that's the thing. I mean, I really don't have this long-term view, and I think that's the same with the last question, with embedded and server space. It's just that it's almost impossible to have a long-term view which will not be contradicted by the reality. And the best you can do is to follow the path of evolution and try to adapt as fast as you can and then try to find what the next step is. And I think right now for me, the next step is getting research management in Sigurd in some usable form, and after that, I'll find something interesting. Yeah, Dan. I think for me, what I'd like to do, you know, Greg and Linus talked about getting Linux to work on all hardware and being inclusive to all hardware. I'd like to make sure that our community is inclusive to all people that want to contribute as well. And so that getting more diversity, getting more diverse voices in our community is something I would like to see continue on. So, just a reminder, people are still collecting questions if you have them. But another question, the kernel community, and I've actually observed this and kind of nudged the people who have the report to me at Red Hat. We're all very focused on kernel mechanisms, but Linux is an ecosystem including user space. How do we keep that balance? I mean, are there burning user space issues or application issues that we as kernel developers need to be more aware of or concerned with? Well, that's where we have the plumbers conference, right? It's the kernel and the plumbing above the kernel and the system D and Udev and all the stuff interaction. That's why we're all sitting down for three days and hashing it all out again. I mean, that's the great, we're all working together on that. And there are people that crosses boundaries and there's some of us that just stay down in the kernel. So, there's a whole large community here working on that. So, that's a very important thing. I have to say, I sometimes hope that, okay, we have a lot of kernel developers. I hope some of them would go into user space. Not because I don't want to have them, but because I see all these things that a lot of user space projects do. And I say, Christ people, why are you doing it that way? We know how to do it, right? And we know how to not break compatibility. And then I see these user space projects that break compatibility every single version and say, hey, we need to redesign this and break every single user. And I'm telling, I'd really like to see some of the kernel culture spread into user space. And if that means that some of the kernel people have to go to user space to spread the word, I'll happily lose them if that improves user space. Yeah. So, I think my opinion would be a bit different. The thing is that if you talk to people who are working on base systems, right, or in user space, you know, desktop or whatever, while it's true that, you know, they don't have as much resource than we do, and they probably have, you know, worse practice than in some aspects than we do, but there are also a lot of things that we need to learn from user space, I think, that if you talk to how some of the kernel features are designed to user space guys, a lot of it is just barely usable, not usable. And I think we just need a lot more communication between the people who are actually using our kernel features and the people who are developing the kernel features. And I think we kind of need to lose the mindset that, you know, we are somehow, like, doing better in most things than user space. I mean, it's just like there are, like, very different approaches taken, and in many aspects, there are more advanced, like, in taking in, like, new developments in software engineering or whatnot. So I think it would be very beneficial if you can, like, talk more. I think that one of the areas that user space and kernel really, really needs to collaborate on is power management. You know, we can have the best power management in the kernel in the world. We can get into the deepest sea states. We can have the best USB power management. But as soon as user space starts holding your USB devices, your power is just going to go to crap. So it's a definite balance that we need to communicate back and forth between user space people and kernel people as well. So some of the interesting technologies, I mean, Linus, you mentioned hardware innovation. Later this week, we'll be talking about new classes of memory parts like persistent DRAM and how we handle it in file and storage in Plumbers. Anything in the horizon that you're currently working on or worried about that is the most exciting and kind of game-changing technology? Throw persistent memory as a change. What would you do with that? Persistent memory is interesting. We've heard that a long time. It's interesting to see it come out now and how it's going to work. I'm glad other people are doing that. Thunderbolt 2 is coming out. I heard you just heard about that. So that's another faster they keep trying to chase after USB. So we got that working the other day. The Intel did. USB 3.1 is coming out. USB 3.1 is coming out to try and combat Thunderbolt 2. It'll show up in cinemas over the Christmas holiday, right? Yeah, it will. Actually, I'm personally more interested. This is a slightly longer time frame, but on the 5 to 10-year time frame scale, I'm very interested to see what and how the industry actually reacts to the fact that soon we will actually come against some physical limits. People used to be talking about having thousands of cores and one die because you keep shrinking and those people clearly had no idea about physics because we won't be shrinking for very much longer. It's getting physically harder and harder and economically more and more expensive. And we've gotten so used to the fact that all these... Like the reason Linux runs really well on cell phones is that cell phones grew up, right? There are already thousands of times more powerful than the original machine that Linux came to be on. And we've gotten used to the fact and we don't even think about it. I mean, people pay lip service to the whole Moore's Law thing. But 5, 10 years, it's going to be tough. And that's going to affect us in the kernel land, especially because we are so... We're kind of the layer between the hardware and the software and what happens when hardware doesn't improve so quickly... Magically making it faster. So that's going to be interesting, but it's a slightly longer time scale. I mean, it might not be 5, 10 years, maybe it's 15, but it's going to happen. I'm just happy that Sada is dying out. He was the trainer of it, though. I'm the main trainer and I'm happy he's dying. Yeah, but I mean, it's kind of interesting because everything is now converging. The physical interconnection is not everything, but a lot of them are converging on the Sada Express and especially... Not Sada Express, but the PCI Express. Thunderbolt is PCI Express. And especially, we are seeing a lot of developments in the storage stack. And traditionally, our storage stack has been really slow, something, you know, because this was so slow that it didn't really matter how we did it. But nowadays, I mean, it's being pushed and pushed harder and harder, and like there are now storage devices coming out, which can do like tens of millions of IOPS per second and, you know, our IOPS stack is way outdated. So, the ANSI is working on this block multicure thing, which is probably going to solve a lot of those issues, but I'm really interested in seeing how that eventually develops. And I think it's also going to affect how we generally perceive storage. I mean, we use things like this really complex, hierarchical, you know, complex arrangement because we could spend the CPU time to optimize IOPS accesses, but nowadays it doesn't really matter anymore, so it's going to change somehow. And I think it's going to be simpler in the future, so I'm kind of really excited to see how this is going to turn out. We're already having trouble doing 500,000 nios a second, let alone 5 million nios a second through the device, so we have to change something. I think the interesting thing is, you know, there's all these new, you know, hardware things that we're going to do, but really to me, the interesting thing is what we do with the hardware. I mean, if you look at something like Google Glass, the hardware is really not that advanced. I mean, it's basically a panda board, but what you do with it is very interesting. And so, you know, I'd like to see... It's going to be interesting to see what we end up doing with Linux and where it goes and, you know, what we end up doing in the user space with it. So I think this question is directed mostly at Lienus and a slight variation of it is, have you fulfilled your ambition of diving all around the world? And if not, which sites do we need to have conferences at so you can finish that list? So we do need more conferences in the Caribbean, I think. Yeah. Yeah. That said, apparently I have been diving enough because two days ago when I was on this boat, it turns out I knew the boat captain because he used to be on a boat in Hawaii. It's... When you start recognizing boat captains around the world, there's something really, really right. Anybody else have conference sites that they need to add to the list? Hawaii. Yeah, so this question, have any of you been approached by the U.S. for a backdoor? No. Not that I can talk about this. Yeah. So going back to diversity and growing the community, I think it'd be interesting looking back at your own career, what got you interested in software and eventually in kernel programming? Start with. So my wife, she was my girlfriend at the time in the university. She came back. She had a class that had a bunch of lectures that happened. And I was in the computers and she came back and said, hey, I heard this strange bearded guy with free software stuff. You heard about that before? I said, no, I hadn't. And so I looked into that and that was Richard Stallman. And that was a long, long time ago. That was the same time I was in the university as he was. And then later on, a lot longer, my wife and daughter went on vacation for a week and I didn't have anything to do. So I was like, oh, I had been using Linux for a long time so I sat down and I wrote a driver. I was bored so I came back and I'd written the driver. I was alone. Let me write some Linux software. So boredom drove you to it? Boredom driven software, yes. I don't know. I had no, I think the major reason I did the kernel was I had not enough money. And that was even before. I couldn't afford a Unix for my machine. But even before, I'd never been able to afford buying games like all my friends played games with their computers. I didn't have any, so I had to type them in myself. So I think to some degree it's not boredom but necessity. Necessity made you start something. All right, Dejan, can you want to boredom necessity slash poverty? I think actually I'm going to be a bit serious about this one. So I always have been a nerd. There's no question about it. When I was young, like five, six years old, I had one sister. And when you're extending family gatherings, they tell the youngsters to do something like sing, to dance, whatever. And after all that is over, then my aunts, my uncles would tell me that you have no chance but you have to study. You have no talent whatsoever. So that's what I heard while growing up. I guess I was just a natural born nerd. I mean, so I was always into programming and computer and stuff. But I always wanted to do operating systems. I don't know why. It was just interest in how it actually works on the hardware. And I always wanted to do operating systems. But I'm from Korea and while I graduated kind of good school in Korea, I had really no chance of doing any operating system development without doing a master's degree in the U.S. I mean, how am I going to get a job in Microsoft? How am I going to get a job with son at the time if I don't have any degree in the U.S.? I don't really speak English. It was just not going to work. And I still really wanted to do it. And there were students. I mean, this is completely often. I mean, it didn't matter where I come from or what degree I had. And that's how I got into Linux. And I, too, till this day, I just really love the fact that it doesn't have that artificial barrier of entrance. If you can do it, then you can do it. I mean, it doesn't really matter who you are, you know, where you came from. And that's just an awesome thing. So, you know, if you're interested, just, you know, give it a shot. It might work out. Just go and do it. And after you've transformed yourself into the upstream presence, getting a job doing that and getting paid is a lot easier. Yeah, it's really easier. I don't know why. I don't know. People like to give money to me, so. So I think I can top boredom and poverty. I got involved in Linux because my then-boyfriend-now-husband was involved in the Portland State Aerospace Society, and they build open-source rockets. And so I actually got Linux running on my machine because I wanted to build USB sensors for this Linux-based rocket that was going to go 24,000 feet in the air. Were you afraid that if you didn't do it right, it would crash back on your house? Oh, we've had the rocket crash before and not, you know, and it got kind of squished. But, you know, it's just an experiment. It's something fun to do. So, another question from the audience. What do you think about software abstraction, virtual servers, virtual software-defined networks, software-defined storage? The turtles all the way down. Something. Some things make sense. Virtualization containers are a good solution for a lot of problems. The cloud. I mean, these guys have been doing this for over 40 years ago. I mean, these are good, well-proven designs and ideas of how to compartmentalize things and do computing. So, I mean, it's a well-known, well-thought-out, well-researched area. It's how to do things. But still, running on bare metals is fun. Yeah. Part of the reason I got into it was playing with hardware. All these virtualization stuff, I don't want to have anything to do with it because I want to run on bare hardware. That's where the real excitement is. Real men and women do that. Right? Yeah, I think we're still in the process of finding out how it all works out. And I don't know. I really don't have any stuff about it. I think it'll be interesting to see, you know, where virtualization goes, you know, if people start having, you know, dual OS tablets where they've got windows running on Linux in there. It'll be interesting to see what happens. All right. So another audience question. Is there anything you want to tell everyone about explaining how difficult it is to be a kernel maintainer? What makes your life easy? What makes your life hard? I get a whole hour-long talk on that. We have documentation on how to do patches, how to send them, read them. Read that. I mean, that's the easiest thing. You can, if you read that and follow that, it makes my life so much easier. Lina, anything you especially hated? Our seat. One of my major sources of stress is when, and I'm looking at you, James, is when people send me last-minute stuff and want me to merge stuff. And then I have to hurry. And I hate being in a hurry and feeling like I'm on a deadline. So one of the things people should do is prepare beforehand and send it out when it's ready. And if it's not ready in a timely manner, wait until the next release. So being a maintainer, I think there are a lot of conventions and just the people, how to interact with Andrew Bolton, how to interact with Greg, how to interact with Lina. And these things are difficult to document. And those small tricks, those small conventions, those small acquaintances, those things add up to make the daily life and maintaining stuff not so hard eventually. I mean, it takes a person a new maintainer maybe six months a year and the person will make several mistakes in the course of that time, but I don't really think it's that hard to pick up. But I think what makes maintaining a subsystem more difficult is when you have to make long-term decisions and try to drive people towards certain directions and which of course not everyone is happy about it. And you yourself are not even sure whether this is always the right direction or not. So those long-term decisions can be more difficult, I think, but daily life of being a maintainer, I don't really find that too harsh or too difficult. I think as a maintainer, the hardest thing that I have difficulty with is I need people to explain why I need to apply a particular patch. It's not enough that you send me a patch that it's perfect. You need to tell me why it fixes this particular bug and how you trigger it. You basically have to use your persuasive skills to tell me why I should be care about this particular patch. And so I think that that's something that a lot of people don't get when they do first patch development. They don't understand that it's not about getting your patch in, it's about convincing me that there is a problem that you've solved that problem. I agree very much with Sarah. Another thing that I personally find hard to deal with are these drive-by shootings. When somebody throws a patch over the fence and then doesn't understand that in order to be a useful kernel developer, it's not enough to just write the code and send it out there. You have to write the code, you have to explain why, you have to answer questions when somebody asks, why did you do this? You have to be ready to not just do the code, you have to be ready to maintain your own piece of code. Maybe if it's just for one single patch you're sending, it's only a couple of days of answering questions about it, but it's even better if you're making it clear that, hey, if there are problems, I will take care of them and make it clear that you are responsible for the code you sent in. All right, so I think we're close to the end of the hour. So maybe a last question to wrap up with, I'll combine two questions. How do you spend your non-kernel hacking, non-software hacking time? And is there anything that would draw you away from hacking on Linux as a full-time job? Well, I used to joke that Linux was my hobby, and then I became my job, so I lost a hobby. So I moved a couple of years ago up to Seattle and we're near water, so I started building a kayak, and wooden kayak, and it was supposed to take about 50 to 60 hours. Like my daughter likes reminding people, it took me three years. But it's finished, it's done, so I like, and then she likes reminding people I've only used it three times. So yeah, I need to do hobbies, it's done now. So if you need a professionally built kayak, Greg's the guy to go to? No, no, no. So yeah, my wife is like, you're not building the rest of the family when we're outgoing and buying the rest of them. So they did that. So no, I love doing this, it's just fun. Well, I do my diving. I do have a regular life outside of Linux also. And I don't really see any project coming along that would be more interesting than Linux. I can't imagine what would fill the void in my life if I didn't have Linux to work on. It's not a bad job if you can get it, right? Right, yeah. So I moved to New York like one month ago, and I'm having a blast there. So is there like anyone from New York here? Use your hands. Yay, we're living in an awesome city. So I've been to, I mean, I usually mountain bike almost every week or every other week. But these days I'm spending a lot of time like just hanging out in the city. And last weekend I went to Comedy Cellar, which is a comedy club, a famous comedy club in New York. And I've already been there three times, although I was living there only for one month. And I saw Louis C.K. there in person. So I just wanted to say that. I'm telling this to everyone. But anyway, so I'm trying to like having a life out of this, you know, nerdy sphere. And as for job, I mean, I'm so happy with my job that I cannot really see myself doing anything else. I mean, I cannot even imagine how I would spend my life without, you know, hacking and conning. So as your manager, I don't have to worry you're going to run off and do stand-up. I'm just not talented. I mean, my answer, you know, uncles were right, I have no talent. So I'm kind of a geeky geeky. I mean, I do bicycling and I do gardening. But then I also play Magic the Gathering and I do Dungeons and Dragons on the weekend. And so I just like doing geeky things. Thank you. And I think that's it. So I want to, before you sit down. So I want to, I want to sneak in one last question because many of you may not know this, but Greg and I do this thing called the Greg and Jim Show where we go around all over the world and we sit down and we talk with companies who want to get better at participating in kernel development and in fact want to integrate upstream code contributions into their business process, you know, when they're getting a product ready to go to market, you know, how do I get a patch that I need to ship a product ready also simultaneously for the main line? So any advice, this is the question we always get, right? And I thought I'd take this opportunity to get some advice for those companies, engineers, the guys who are working on getting the kernel ready for a product or whatnot, how they can also integrate that process into the main line. Any advice for these folks? Get involved really, really, really early in your hardware design cycle before you have silicon. Get patches upstream. I mean, I talk about when you should submit patches. It should be after or right really, really early. Other companies really understand this. I'll give you an example of Intel. A couple kernel releases ago, we ripped code out of the kernel for an Intel chip that never shipped. Intel is that far ahead of everybody else. So companies need to be involved really, really early in their design cycle and their integration cycle to get stuff upstream because it takes a while. It takes six months to get new features and new stuff in. They need to realize that because other companies do realize that. And also, not just really early, but really being involved and not just say, builds your patches inside the company and then you're of the opinion that, hey, we did this perfect solution for our problem. Why aren't you taking it when you then give the kernel community this Fedacomplete, this thing that solves your problem that solves nobody else's problems. So you need to be aware of the fact that in order to get things merged, you need to solve not your own problem, well, not just your own problem, but also realize that the world is bigger than your company and try to solve things in a way where it makes sense for other people, even if it primarily is for your own situation. One thing that I want to say is that you're probably, if this is like the first time that your organization is sending patches upstream that it is almost essential to budget extra time and resources to do that. Because it's not like, you know, if your manager asks you that, you know, do we want to open it? You know, yeah, sure, and we can just send it and forget about it, and it's not going to happen that way. You're going to have to send it and you're going to have to follow up, and that's probably going to take a significant amount of your time and resources, which is a good thing, but you just need to make sure that you have that budget in your timeline or you insist on that this is an extra effort that you need to take on and make sure that it's known throughout the scheduling to your management or whatever, and that will make your life a lot easier if you have to take care of it. I think that a lot of companies that they need to contribute like this giant chunk of code, what they don't realize is when they walk in with that giant chunk of code that you're walking into an existing community, we have no trust in you, we don't know your skills, and so you're going to get really scrutinized. So one way that you can, you know, kind of ease that process is to work with the community beforehand. As Greg said, you know, bounce your hardware designs off of kernel maintainers, you know, see, you know, work with them to design new APIs rather than designing your APIs behind closed doors and then trying to get it in the kernel and maybe do small patches in the community you know you're going to need to contribute in eventually so that we know we can trust you with the process, we know you're going to be around for a while, and so you can build up your trust with that community. You guys will be happy. I actually talked to the vendor who worked on that airline system, and they're now employing this methodology, so you may see a more recent kernel version next time, and I'm hoping it won't crash, but at least you may or may not see it, so it's good news there. I want to thank you guys for coming. We're going to go and take a break here, and then the session starts right after that. Thanks everybody for coming.