 I'm going to talk about the Linux kernel community, how we work, how fast we're going, and some things about how it interacts with companies. So first off, to start off, this is how big the kernel is right now, 17 million lines of code, we keep growing every time, every release at a very linear, very constant rate. It's a very nice, we haven't slowed down in a very long time, it's very straight. This is for the past year, we have over 3,000 developers and at least 430 companies, I say at least because there are still a number of companies we don't know who people work for. Everybody that contributes to the kernel, we ask, they don't have to tell us, but usually they do. So this is for the 3-8 to 3-12 kernel, so the past year we're through development. We finally made over 3,000 people last year and for the past two years we've had over 400 different companies. It's the largest software project ever, by a number of people and by a number of different companies. This is our rate of change for the past year. It's not that bad, it's until you realize what that scale is. We keep going faster every year. This is what we do every single day. This breaks down to 7.5 changes per hour, 24 hours a day, 7 days a week. This is very, very fast. Years ago we were going at 2 changes an hour and we thought that was too fast. We keep increasing every single year. What this means is if you diverge from the kernel community, we keep going faster than what we used to do, so you need to be aware of that. The 3-10 kernel, we did 9 changes an hour. That was really, really fast. I don't think we'll see that again, but every year I say we can't possibly keep doing this and every year we go faster. I keep being wrong. So how do we do this? Two very important things. We do releases based on time. We do a release every two to three months, and that allows companies to anticipate when they're going to get things into the kernel. We don't require certain features in every release. If you miss a certain release, that's fine, you can come back, get in the next release. It's only another three months away. Along with doing things based on time, we do incremental changes. Every single change that goes into the kernel is a very tiny, specific thing. We don't rewrite everything all at once. Every single step of all those changes have to be buildable and they have to work. So all those changes per hour, they all work. And those are the patches we've accepted. That isn't the patches we've rejected. We reject. It takes about two to three times to get a patch in. That's how many people we are doing. So this is how things work. This is Linus's tree, and he does a release, let's say 3.8.0. And so then we have two weeks. All the developers take all the changes that they have, all the maintainers, and they throw them all to Linus. And then he does a release candidate. So he'll do 3.9.0 RC1, release candidate 1. And then we do only bug fixes and regression fixes. We do release candidate 2 in one week, release candidate 3 the next week, 4, 5, 6, 7. All things settle down. It's been about two months, and he does another release, and we start all over again. And we've been doing this for the past nine years. Very repeatable, very regular. The only change for the past nine years is that the time between releases is going down. We used to be three months, now we're just over two months. So we are going faster. We're very regular. We know how to do this, we're very used to it. After we started doing this development model nine years ago, we realized that people rely on these kernels. So what happens if there's a bug in 3.8? So we came up with stable kernel releases. And I maintain the stable kernels, so I'll take them, and I'll do 3.8.1, then 2, then 3, 4. And in these kernels are bug fixes only. All the changes in there have to be in Linux's tree, so we can't diverge, so they are there. And then I do about one release a week. Another nice thing is after Linux does a new release, I throw it away. I'm done with it. I don't have to maintain it for a long period of time, and we just go on 3.9.0, and then we'll go 3.9.1, 2, 3. And we've been doing this for about eight years. Very regular, very repeatable. I said I throw them away. I will maintain long-term kernels. Some of the enterprise people have been using long-term kernels for a long time. Now we've formalized it, and we make a specific statement about it. So long-term kernel, I take one every year, and I'll maintain it for two years. So right now the 3.4 kernel and the 3.10 kernel are the long-term kernels. People base product on this. The LTSI project is based on this, so they'll take the 3.10 kernel, add some features, and ship it into product. 3.4 is the same way. The 3.2 kernel is being maintained for Debian when the Debian developers is maintaining that. And he says he'll do that for five years, which is a long time. So how do we do this development? We talked about releases, let's talk about development. So we have 3,000 developers, right? They make a change. They figure out they want to fix a bug, they want to add a new feature, they make a change. They take that change, and they send that on to the maintainer of the file or the driver. And we have about 700 of these maintainers. They're all listed in the kernel, we have a tool to figure out where you send them to, they do that. So they look at the patch, they say, oh, it's good, it's bad, they push back, and they say eventually they'll say they accept it. What this means is every single line of the kernel can be traced back usually to at least two people who've read it and reviewed it. It's very, very well audited. The best audited body of code ever. So they look at this, they say that, and then they send, if they agree with it, they'll send it on off to a maintainer of a subsystem. A maintainer of a subsystem is something like USB, networking, wireless, file systems, things like that. We have about 150 of these. They'll take that and then make a tree, they make their own kernel tree. I maintain a number of different subsystems, like USB and staging and serial. So I have a tree for that. And then every single day, they're all pulled together, merged together automatically, into something called Next, Linux Next. All the merges are figured out, we figure out if we broke something or we didn't break anything. All these kernels are built on about 30 different platforms, and they're booted, a lot of different ones as well. And then there's Andrew Morden, who's out there picking up patches where there's parts that are not maintained to the kernel. We still have lots of areas that are not maintained. And he'll scoop up patches that are dropped or things like that. And he has his own tree, and then that gets merged as well. And we do this every single day. So if you want to test what's going to be in the next Linux kernel, Next Release, Test Next. So this is what we do every day. And then when Linus does a release candidate, or he lets us send him patches for two weeks, all the subsystem maintainers send the stuff to Linus. The individual people aren't sending them, it's the subsystem maintainers. Linus does not pull directly from Next because sometimes there's things wrong in the subsystem trees. For example, I had TTY, I maintained the TTY layer, the serial layer. And for one release, it just wasn't working. All the stuff that was in there just was not ready, so I didn't send it at all to Linus, and we skipped the whole release. So everything that goes to Linus should be in Linux Next. We run some numbers and we test that and we find out who isn't abiding by that, and it works really well. So about almost all the changes that go to Linus have been tested ahead of time. That lets things be very repeatable, very reliable, and very up to date. So this is what we do all the time. So who are the people doing this? These are the top ten companies for the past year. If you look, number one and number seven are not sponsored by anybody. Amateurs, people just doing it for fun, and then there's some unknown people. We don't know who they work for. That makes up about 15% of the contributions are done by people doing it on their own. Or you can look at the other way and that's 85% of the kernel is contributed by companies, people paying to have the work done. Now to be fair, if you start contributing, none of these people that are amateurs have contributed more than five patches. If you start contributing, somebody will hire you. There's lots and lots of jobs out there. So common companies, Intel, Red Hat, Linaro, Samsung, TI, IBM, Suza. Number ten is interesting. That's about 2,000 patches, this number says, that is one developer did that last year, one developer got a whole company to the top ten. So any company just doesn't think that they can contribute. That's one person, one person doing that work. He's amazing, he does really good work, but that's one person. And the number next 20 common companies, Google, Reneasys. Reneasys does a really good job, really good job getting their stuff. Free scale, Broadcom, Oracle. Consultants are companies that work for other companies, very common. What's interesting here is if you rely on Linux and you don't contribute, which is fine, you're allowed to do that. You need to be aware that these companies are gonna take drive Linux forward to work better for them. That's how we do work, we make Linux work for them. If you're not contributing, you have to rely on these companies to do what's best for you. And that might not be the true, but not be the case. You need to get involved if you wish to see Linux work good for you. Or you need to pay somebody, consultants do well. That's very, very important, you need to be part of this process. There are a lot of very large companies that do not contribute, and that's fine, you don't have to if you don't want to. So let's talk about, this is the releases, Reneasys Tree, My Stable Trees. And then there's Enterprise Kernels, so these are the distributions, Red Hat, Sousa, Canonical will take a kernel, and they'll start it. They'll branch it off one of my stable releases. And they'll test it for a long time, find problems, and they'll pick other patches and do another release. And then they'll take some features that were in Leneasys Tree and add it there. And then they'll pick some other things and add them. So the kernels you're running for an Enterprise kernel, this number really doesn't mean much. It was a point in time when they started. But they're maintaining these for seven, 10, 12 years long. But they're adding lots of things to it. And that's great, that's the way they work. They pick things and choose things. But realize that this is not a community-based kernel, it's based on it, but they add a lot of other stuff to it, which is great, that's the way they work. So if you see an Enterprise kernel, it's a weird numbering scheme, they add to the end of it, that's where they are. But if you're relying on these companies, when they find a bug, they should push it back to the community so that it gets picked up in their next release. Sometimes they don't do that. So I really want you to be aware of this. If you're a person who's contributing or you get your kernel from somebody, usually a company, if they're not a member of the community, those fixes that are made in there are not going to go upstream. So the next release that happens is not going to have them. The next time you buy the product or kernel from them, those fixes are probably not going to be there. You need to be aware of that. And if you're an Enterprise kernel company, you need to be part of the community. And so you really, really need to be aware of that. And the last thing, of course, penguins. Thank you very much.