 I'm the opening actor, possibly the floor show, I'm not quite sure which one. We have the distinct privilege of having Linda's Torvalds with us. It's a Q&A session, I would like to put the emphasis on the queue, so form an orderly queue if you'd like to ask something, because I will not talk to you if you don't. Actually DKG over here is doing the actual question moderation. And I suppose without further ado you welcome Linus. So apparently there are absolutely no questions, that's fine, we'll cut it short. Just out of interest how many of people are local here, I just want to know. So not too many because I did a Q&A a few months ago at the local Portland Linux Unix users group, so I was hoping there were new people here, which there apparently is. I don't do speeches, I hate doing public speaking just, so I don't know what you're interested in, so it is a Q&A or it's nothing. I'll start with something non-controversial. No, no, I'm fine with controversial, that's not usually my problem. It's well known around these parts that in 2007 you did an interview where you said that although you've used many Linux distributions you had never used Debian because you found it difficult to install. Have you tried it since? No, that was quick. I'm sure it's gotten much easier to install. To me a distribution is, I'm sorry, you may want to close your ears now. A distribution is not very interesting. I wanted to be easy to install so that I can just get on with my life, which is mostly the kernel. The closest I got to installing Debian was there was one machine. I forget which one it was. It may have been the MacBook Air that actually had trouble installing something. Debian, the installer would boot but then it didn't install there either. Eventually I figured out what was the problem with that machine but by then it was too late. I have tried Debian too and that got nixed really fast because they made it really hard for me to install my own kernel. When make install doesn't work for me, I'm like, whatever, I'll do something else then. Somebody should check that you can just do make install and you don't have to build a package and install a package. If I have to install a package, at that point the distribution gets in my way and at that point I'm saying I'll do something else instead. If there's a way to break installing an operating system I've found it multiple times and if there isn't one you already know of I've found it, and Debian last time, super easy, highly recommended trying. Maybe I should try. One of the problems I have is I am not an MIS person. I mean, I may do kernels and people think that that means that I'm technical but when it comes to actually maintaining machines I am a complete disaster, right? And I change my own machines regularly so changing the system I run on my machine would be easy, right? I end up upgrading machines a couple of times a year usually, but I end up having also to maintain my family's machines and that ends up being the one that I don't upgrade my family's machines very often and I don't want to run multiple different distributions across different machines because I suck at MIS so it ends up being, for me, a distribution is something very sticky. Once I started with one thing I have a really hard time just doing something else because that means I have to switch over all my kids' machines, my wife's machine and that's just painful. So that's why. Okay, so this is a little difficult. I guess we're all, at least for me, I'm kind of wondering very much like I think you are lately how to get to the year of the Linux desktop if you will, right? Wow. And we don't like it to be the year of the Debian desktop if possible and I'm trying to figure out if anything, if you have any insight as to possibly how to get closer or towards that, if anything. So I mean there's a lot of things that are getting closer to that and I think, I mean people, technical people don't tend to use Chromebooks but I think that Chromebooks are the kind of thing that will make the year of the desktop more possible, right? Because once people get used to running their applications basically as a browser, that makes a lot of things much easier. That said, let me go on my first rant of the evening, right? One of the problems desktop has, I mean ignoring all the purely market and getting free installs and making it just so that normal people and by normal people, I mean obviously non-technical people will just buy a machine and it just works. One of the things that none of the distributions have ever gotten right is application packaging, right? And now somebody will say, hey, d-package is way improved and much better than RPM and that's not at all what I'm talking about. I'm talking about actual application writers that want to make a package of their application for Linux. And I've seen this first hand with the other project I've been involved with which is my dialogue application, right? We make binaries for Windows and OS X. We basically don't make binaries for Linux. Why? Because making binaries for Linux desktop applications is a major fucking pain in the ass, right? You don't make binaries for Linux. You make binaries for Fedora 19, Fedora 20, maybe there's even like Vell 5 from 10 years ago. You make binaries for Debian, actually you don't make binaries for Debian stable because Debian stable has libraries that are so old that anything that was built in the last century doesn't work, right? But you might make binaries available for Debian whatever the code name is for unstable and even that is a major pain because Christ, we had this small local flame just a couple of days ago. Debian has these rules that you're supposed to use shared libraries, right? And if you don't use shared libraries, getting your package in is just painful. But using shared libraries is not an option when the libraries are experimental and the libraries are used by two people and one of them is crazy. So every other day, some ABI breaks, right? So you actually want to just compile one binary and have it work preferably forever and preferably across all the Linux distributions. And I actually think distributions have done a horribly, horribly bad job. One of the things that I do in the kernel, and I have to fight this every single release and I think it's sad, we have one rule in the kernel. There is one rule, we don't break user space. Everything else is kind of a guideline. The whole security thing, it's a guideline that we shouldn't do stupid shit, right? But that's not a hard rule. People do stupid shit all the time, I don't get that upset. People break user space, I get really, really angry. This is something that is religious for me. You do not break user space. And even in the kernel, every single release, I have people saying, okay, I'm changing this ABI because it's cleaning stuff up. And I'm like, no, you're not changing that ABI because I will crush you, right? And actually, it's often okay to change ABI as long as nobody notices. But immediately when somebody notices, it's a bad thing. And this is like a big deal for the kernel. And I spend a lot of effort explaining to all the developers that this is a really, really important thing. And then all the distributions come in and they screw it all up. Because they break binary compatibility left and right. They update G lib C and everything breaks. You, hey, you can recompile everything, right? That really seems to be this mindset quite often. It's like the G lib C people say, it was a bug. Look, here's the standard. It says you can't rely on that. Nobody cares. If it's a bug that people rely on, it's not a bug. It's a feature, right? And I won't even get into all the other libraries. But it's really sad when the most core library in the whole system is okay with breaking stuff. And as long as things improve and they fix the ABI. So that's my rant. And that's what I really fundamentally think needs to change for Linux to work on the desktop. Because you can't have application writers do 15 billion different versions. And I'm on record as saying that maybe Valve will actually save the Linux desktop. And it's actually not because I think games are important. I don't care. I don't play games. I think some people do. So games may be important. But the really important issue is I guarantee you Valve will not make 15 different binaries. And I also guarantee you that every single desktop distribution will care about Valve of binaries. So the problem is Valve will build everything statically linked and create huge binaries. And that's kind of sad. But it's what you have to do right now. Sorry about the rant. This isn't a question for Linus. I just wanted to... This should have actually been something that was relayed to the audience at the beginning of the talk. And I'm terribly sorry that I didn't do this. It's my fault. Due to the nature of this session, there may be a course language involved. If you are sensitive to course language, I invite you to step out with me and we can discuss it. Thank you. I'm sorry. I didn't read the guidelines. I'm sorry. They sent me the guidelines. So you can't really blame the organizers. It's my fault. What version of GCC do you think we should ship in the next version of Debian? Well, we fixed the particular problem we had with the particular version of GCC you already shipped. So you're fine. You're off the hook. There's still some discussion. All the discussion seems to mostly died down that the way the kernel fixed the GCC bug, and realistically almost nobody else is going to be impacted by that bug because you need to have inline assembly and very few projects do that. The way we did it in the kernel was kind of a big hammer approach. And some people were a bit upset about that. It does mean that any version of GCC that is more recent than let's say 4.2 is probably fine. I have an incredibly boring technical question. I recently saw that there was another patch for proposal of revoke getting implemented. So have you had a look at this yet? I haven't had time to look at the patch. I looked at some of the very core infrastructure for it. The whole counting thing that it used. And it's probably going to happen. One thing that I was happy about was that one of the comments was that this might end up being generic enough that we can use the same thing that we basically use for CISFS, which kind of has the same issue anyway. We have a lot of our own internal things that can be revoked already. It's just that it's not exposed generically for any file descriptor. It's going to be painful. There's no question about that. At the same time, people have been asking about revoke for a long, long time. It's going to get done. I'm not going to say it's next version. It's probably going to be some discussion before it goes in. Hi. I'm sorry to ask this question almost, but it's something that I think is a little bit important. How do you think it affects the culture of a community of a project when the leader is on that project's public mailing list, telling people in response to patch reviews that they should be retroactively aborted, and maybe that you're surprised that they're still alive because they should have starved to death when they were children because they were too stupid to find a pit to suck on? I agree that some people might be put off by that. But on the other hand, in the end, I don't care. I care about technology, and I've actually seen projects that took the whole political correctness so far that the project no longer is about the technology. We're getting more questions, I think. At some point, we might want to moderate them. I'm very happy to talk about this. It's not a problem for me. My standpoint has always been that, hey, people are different. I'm abrasive. I grew up in a culture that I think is not quite as politically correct as the culture, especially in the US today. I also grew up in a family that was largely dysfunctional. People are different, and some people take offense, and some people give offense. We all have to live together, but the living together is not by finding some lowest common denominator. It has actually been fairly successful, is to try and realize that, hey, unlike your family, you can actually pick your friends, and you can pick the co-workers, and open source is actually really good at that, better so than many commercial software projects, because in a commercial setting, you're kind of stuck with your boss. In open source, find people you like. Find people you like working with. I work directly with, let's say, 20 people closely, and 50 people more or less. Every release, there's 1,000 people involved. Find somebody you like better than me. That's fine. I'm not willing to be less honest, because I know I'm abrasive. Quite often, when I say something like, I wonder how he grew to be an adult when he's so stupid that I don't expect him to find food. Some people might realize that it's kind of hyperbole and joking. I'm not saying something bad that it's not politically correct or whatever, although certainly I would understand if people do say this. It's more about treating other people with respect and maybe saying technical... You know what? You can applaud everything you want, but I don't respect people unless they deserve their respect. There are people who think that respect is something that should be given. I happen to be one of the people who am perfectly happy saying, no, respect should be earned. Without being earned, you don't get it. It's really that simple. Not everybody agrees, and that's fine too. There are people I refuse to work with. It cuts both ways, and I realize that. OK, thank you. Good evening. System D. Wow. It uses technology exposed by the Linux kernel that is not exposed by other kernels. It's a user space thing. Are you happy about System D using Linux-only technology? Do you not care since it's user space? To follow up, what's your opinion about PID 1? Wow. I don't think PID 1 is that special, right? I actually think System D does a lot of things right. The problem I've had with System D has been there are a few... Literally, before System D really got started, this must be one of the kernel summits, and I'd like to say five years ago, but that's the number completely made up, right? Leonard was giving a talk about UUIDs to the kernel people at the kernel summit, and we laughed him out of the room, right? UUIDs are crazy shit. They're up there with XML as bad ideas, right? And exposing them as something really cool and clever was... I felt just stupid and I wasn't the only one. At the same time, there's no question that the Unix init system is not wonderful, right? And it wasn't being very actively maintained, and System D gives a lot of features that you really couldn't get any other way. The boot up speed ups are real, right? And it's not saying that you couldn't get the same things with non-System D, but System D stepped up and did it, right? So I think the fight mostly is over. The lack of portability is sad. The thing that I absolutely hate is that the bug reports have been basically ignored in some cases, and I don't like that. But is there really much discussion left? Maybe. I thought Debian already basically decided to go with System D, but apparently I may have heard just one side of the story, right? I realized people expected me to hate System D. I don't hate it really. I think it's somewhat interesting and it has quirks, but what does not, right? Okay, thank you. So you mentioned desktops and distros as being something that more or less you wanted to not get in your way or make your life more difficult or add overhead. Things like make install, for example. The top couple of ways that a distribution like Debian could make your life personally or professionally easier actually be a positive influence above just having Linux and a bunch of software. So my personal Linux use is actually pitiful. I've shown what my desktop looks like and the universal response is that's it, right? I have a web browser and three terminal windows open and that's pretty much it. I have no need for a distro to do anything fancy for my own case. I use make, gcc, bash and xterm or gterm or anything. I don't even care which terminal, right? The thing that would make my life easier and that I've sometimes heard like ranting about is it's sometimes, I mean my family runs Linux. Obviously they've been running Linux for a long time. I have no trouble with Linux, but I was ranting not that long ago about how setting the time zone or connecting to a new wireless printer was unnecessarily hard and required privileges that my kids should not need to have even though clearly when they go to school they need to be able to connect to the school printer. And the solution is not that I as a system administrator go to the school and install that printer, right? The solution was at that point to just say, okay kids you can be admins and whatever here. Here's the root password in the case of one of them and the other ones I just made admins so that they wrote their own password. But that was to me annoyance and it was an unnecessary annoyance, right? So I would like distributions to really concentrate on making it easy for normal people because that way I don't have to maintain the machine so much. Thanks. By the way I would like to point out that both of my complaints actually did get fixed. At least the time zone thing on the distro I do use. You can now set whatever time zone you want and it never complains. Of course it crashes if you set the time zone to be the automatic network time and the network goes away, but that's not a distro bug. That was a gnome bug. Hi. You may remember a few years ago an event in Cambridge you probably don't. We gave you a Debian t-shirt. I hope you appreciated it and it's seen in appropriate use. A question, what happens, cast your mind a few years forward from now. One of your kids comes to you and says, daddy I want to be a kernel hacker. What are you going to say to them? I'm going to say, halleluw, because it's not going to happen. I have never pushed my, I mean I want my kids to get an education and my wife claims I pushed them, but I have never pushed them into computer science. I kind of hope because I think it's a great education. I think it's a great way to get a job. I think it's just a wonderful area to be in so I hope that they decide to look at it. But so far there is absolutely zero interest and I don't see it happening. I'd love for them to be kernel developers but I may have to adopt. Hi. In discussion to further the conversation about subsurface, I have a half troll, half serious question, which is have you considered circumventing distributions entirely and distributing subsurface as something that runs inside a Linux container using LXC or Docker or something like that? I haven't and I have to admit that I'm not even the maintainer of subsurface anymore. I started the project and like most smart people, I just pushed it off to somebody else who was willing to take it. It has been talked about. It's not something subsurface will do on its own, but there are projects that apparently have realized that this is a problem and there's been noises about making the whole Docker container work as a way to install application packages sanely, securely and in an environment that is limited or maybe not limited is the right word, but in a standardized environment so that you can do things like upgrade your system and not break your applications. I'm actually hopeful that there are people who are looking at this. Subsurface is a small project with basically a handful of developers, which is actually true of most of them. You probably know, probably all of you work on small projects with a handful of developers. It means that those kinds of projects don't really have the resources to say, hey, we will push through this thing that makes our binary work across all these myriad Linux distributions, but is anybody working on something like that here? One hand, no two hands, so someday, yes. This isn't really a question, and I'm sorry to have to say this, but I like working with people that can express technical disagreement in a reasonable and often pleasant way without resulting to playground insults, and it's really disappointing to me that you don't think that's important. That's fine. I can deal. One of the things I have noticed during this for a long time, is that the skin is a good thing to have. I think it also means that the criticism ends up not working so well just because I'm used to it in so many other areas. So, Sparse was sort of born out of, you know, GCC is too painful to hack on, and Git was born out of, well, Bitkeeper went away, and there was another version control system, so I'm going to go right one. Have you considered going off and solving the application binary distribution problem? What would it take to get you sufficiently annoyed with that problem to go off and solve it and, you know, write something in a week that becomes a new standard? You know, I... Git was actually a really simple problem. It was just that everybody looking at it were... I mean, there was something with version control people. They had their mind warped by years of CVS, and Git is actually a really simple problem to solve, and that's why it took two weeks to get a first running version. Sparse took longer, but at the same time, writing a C front-end is still a fairly simple and self-contained thing. The C preprocessor is interesting, but solving the whole binary issue is really hard. And I mean, part of the problem is you can solve it by just linking everything statically and giving your own file system with the thing, too. But you really have to do that right now, right? Because you can't rely on the libraries that the system gives you, and you can't rely on all the paths that those libraries depend on. We literally have that issue. I mean, and this is not Linux specific. This is when you do Windows or OSX binaries, you will notice that packaging applications is hard because different systems have different fonts, they have different paths to icons and things like that, and basically to be really a complete package, you have to include all of those resources, too. I'd love to say that I'll solve that, but I think it's very unlikely, since most of the projects I've been involved with have been solving my own personal problem, and for subsurface, my solution right now is, I will recompile. I know it's the wrong solution, but it works for me, and sadly it works for almost everybody here. It doesn't tend to work very well for maintainers of packages because they can't necessarily ask all their users to recompile, but I don't maintain subsurface. Other than compile once, install it and run it anywhere, what are your requirements for such a system? Is that the one and only requirement, or is there more to it than that? For example, people have suggested that what we do by using QT, and before we used QT, we are cute, like the QT people say. We use GTK. I had people tell me that, you guys are crazy, you shouldn't do that. Use the Java class libraries, and it will look ugly, but it will be easy to get to run most places. One of the problems is applications can't do that because they end up requiring, like in the case of subsurface, we require these odd interfaces to USB, direct interfaces to USB devices, or serial ports, or stuff like that, and anybody who tells me that serial ports work under Java has obviously been, I don't know, they've been eating the wrong kind of mushroom. I tried some Java dialogues, and the problem was, no, serial ports do not work with Java. So the requirements are actually, you want everything. You want actual hardware access, because not everything wants hardware access, but a lot of programs do want to talk over Bluetooth to something, or over serial line to something else. So you actually want, you don't want the kind of Linux standard base thing, which is a minimal install that says, okay, for this simple application and databases tend to be simple in that sense, right? This is all you need to rely on. Now, I mean, for user-facing applications, you want all these graphical libraries with OpenGL with everything. And I mean, this is part of why I'm hopeful about Valve, because they want obviously the graphical part, but in games you actually want the hardware parts too. You want to have access to your own controller and things like that, so. My question is about Git. First of all, thank you for Git. It's a great tool. Really seriously, whenever people thank me for Git, you should thank Junior Hamano. He's been maintaining it for now eight years. Over nine. He really took it where it needed to go. So that's actually leading into exactly my question, so I was going to say that just over nine years ago you handed over maintainership to him, and I was wondering what your thoughts were on where it has gone in that time. So for example, starting with a less obvious one that's relevant in the Debian community of Git NX, which Joey has made, it would sort of a dropbox, sort of synchronization type of thing, the more obvious ones of GitHub, and actually that's a mixture of an interesting monoculture of often its own world, but also really popularizing Git and open source drive-by-contributions making a low barrier to entry, and everyone from companies to teenagers are using it and doing really cool things. So what's your thought on how things have gone since you handed over? So I mean, I have to say, Git has been a huge success story, and by now, if you're a developer, I mean, you tend to be using Git. I mean, and the interesting part is, it's true not just, it's definitely not just the Linux kernel, but it's outside Linux too. It's Windows, it's Mac, everybody's using Git. And it's interesting just because looking back, people used to complain so loudly about all the horrible user interface issues, and some of them were horrible user interface issues. Don't get me wrong. I mean, there were warts there. At the same time, some of those warts were not actually warts. They were the design, and people had complained endlessly about it, and five years went past, and people stopped complaining and started realising that, hey, this whole rename thing actually works so much better than it worked in any other SCM, or the whole, OK, Git blame is kind of slow and odd, but wow, it actually follows the code to other files and things like that. It's been interesting seeing how it's not just that people have started using Git, it's that people have started realising the whole point of distributed, and the Git model of distributed systems. I think GitHub has been hugely important. The fact that you have an easy way to do hosting is just enormously important for an SCM, and Git made it easy. Git made it technically fairly easy to do that kind of hosting in a way that pretty much any centralized system did not do, but it's still kudos to GitHub, who has been, as a company, one of the driving forces making Git popular, and very much I'd like to say, I mean, Junior, it's interesting. One of the things I personally consider most important when it comes to technical people is this notion of taste, and the reason I gave Git off to Junior is it took me not even months, it took me like weeks to realise, OK, this guy has taste, and he's shown it ever since. I mean, I designed the kind of basics and the rules for how Git would work, but all the actual work has been Junior, and a lot of other people obviously too, but Junior has been a very central force. Thank you. I would like to go back to your earlier statement about breaking user space, and I want to make sure that one of the feelings that I have agree with that. In my role as a driver developer, I also review other people's drivers in our group, and one of the frustrations I have, and bear with me if I try to articulate it, is that I see changes being made in the data structure that has passed between user space and driver in the iOcto calls, which would break the iOcto call. That's one thing. Also, I see data types used in the data structure for the iOcto that are not consistent between 32-bit and 64-bit. One of them comes to mind is something called DMA, that is better under bar T, and I get annoyed when I see that being used in the data structure. Is that reasonable at all for me to... It's absolutely reasonable. iOctos have been a huge mess. There are sub-areas in the kernel that have been burned so many times that they basically cleaned up their act. So the GPU layer comes to mind for being a very heavy user of iOctos, and they got burned exactly. It's not even a type like 64-bit, which you would think, how different can a 64-bit type be? It turns out, wow, on 32-bit it may be 32-bit aligned, and on 64-bit it may be 64-bit aligned. Depending on where in the structure it is, the layout of the struct is different. That's a huge pain, and part of it is interesting to iOctos. iOctos are designed to be things that bypass all the normal rules, and it's very annoying. They've been problematic for everything, like the compact layer has a huge amount of code to deal with just the iOctol mess. So part of it is kind of bi-design. Part of it is driver of writers, and I really can't blame them, driver of writers don't have the background, and should need to have the background to really realize all of these kinds of problems. And it's so easy to get wrong, so in particular in drivers, it is a very common mistake, and it's sad when it happens, and I hate it when it happens, but I also understand why it happens. Thank you. So firstly, I'd like to thank you for your focus on backward ABI compatibility, because that's really useful, and by and large you've done an awesome job at it. So thank you very much. Now you talked about user space compatibility. Now I'm from a Debian background, so I've not used the distros that you've used, so maybe you're going to have a different experience. Also I have a tendency to, I don't much like desktop environments and things, so I tend to be at quite low layers of the stack, but my experience of user space backward compatibility is quite good as well. I just had a look in the user local of my Colo, which was installed several decades ago, and the oldest binary there that I could still run was from April 1995. There were a couple of slightly older binaries, and I could have run those. I had the libc, I'm pretty sure they would have worked, but my kernel doesn't have a.out executable support anymore. You can still compile it in. That of course isn't your fault that my kernel, which is the Debian distro kernel, doesn't have that in. Even if you compile it in, I will not guarantee that it works. That said, we did, and I was very proud of the fact, that at some point I think it was Alan Cox who took the original binaries that I made available for on the floppy boot disks in 1991 and tried to run them, and they still ran. The problem is saying that, yes, our backwards compatibility goes back almost 20 years, is padding ourselves on the back, but the fact is all the real compatibility issues aren't the old binaries. All the real compatibility issues tend to be modern binaries because they do way more complicated things. The compatibility issues tend to be things like when you upgrade a library, the application stops working. I'm pretty sure everybody here has seen that. Sometimes it's a library bug. You've never seen that? I don't deal with Nome. That stuff is off my radar, but I've not had my executables break because I upgraded the library. Lower level code tends to be easier. It tends to be UI code, partly because the libraries are way more complicated, partly also because UI code tends to be much bigger, so bugs happen more. One thing that annoyed me personally enormously, this was a couple of years ago, back when people still used Flash, and Adobe used to make Flash Player available, and Flash Player used Mem Copy to copy overlapping memory in the audio layer of Flash Player. Everybody knows that's wrong. You're not supposed to do that. You're supposed to use Mem Move. It just happened to work because it was copying from a lower address to an upper one or something so that from a upper one to a lower, it was compacting memory, and a forward moving Mem Copy happened to work by pure luck. Then G-Lib C fixed that pure luck and broke a binary that I could not recompile. When I can't watch kittens on YouTube, I get upset. I have to see that. I appreciate your pain there. I would actually agree with you on that point, and I think they should have used symbol versioning to give you a backward compatible, slower version of Mem Copy. They could have just made the old Mem Copy. I think it ended up happening after many, many flames, but I'm not sure these days I don't have to care about that anymore. It's the kind of example that we actually have a lot in the kernel where we fixed something that clearly was a bug, and when we fix it, we break something else. I hope I wasn't the unintentionally funny one here. But it turns out people sometimes rely on bugs, and some of our bugs have been outrageously stupid. Then people say, hey, this commit, which was clearly a bug fix, broke my application. It is really frustrating, and sometimes we just say, okay, we'll undo it. Sometimes the problem ends up being that one of our problems in the kernel ends up being that people often test kernels, especially in big commercial environments. They tend to be like two years behind. Some of these things, literally the breakage doesn't happen when we break things. It happens two years after we broke something and we get a report that, hey, 3.4.15 broke my application, and it can be really hard to find, but we try our best. I do not guarantee that we don't ever break user space. We do break user space. Sometimes we have to because it turns out sometimes the interfaces were so buggy that they were glaring security holes without the fix. Sometimes it's like, okay, two years have passed. We don't even know what broke. I'm sorry, you need to really dig into this if you need to get it fixed, and a lot of people at that point say, screw that. So we break things, and I'd love to say we never do, but we do. Do you agree that you undermine GPL version three, and how can we get you to stop? What? How can we get you to stop? 3.3. I undermined it on purpose. I actually thought the GPL version 3 extensions were horrible. I understand why people would want to do them, but I think it should have been a completely new license. My argument for liking version 2, and I still think version 2 is a great license, was that I give you source code, you give me your changes back where even. That's my take on GPL version 2. It's that simple. Version 3 extended that in ways that I personally am really uncomfortable with. Namely, I give you source code. That means that if you use that source code, you can't use it on your device unless you follow my rules. To me, that's a violation of everything version 2 stood for. I understand why the FSF did it, because I know what the FSF wants. To me, it's not the same license at all. I was very upset and made it very clear, and this was months before version 3 was actually published. There was discussion about this long before. There was an earlier version of version 3 years before actually, where I said, no, this is not going to fly. During that earlier discussion, I had already added to the kernel that, hey, I don't have the version 2 or later, and I was really happy then when version 3 came out that I had done that something like five years before, because there was never any question about what the license for the kernel was. But I actually thought that version 3 is... Now, I actually think version 3 is a fine license, right? I'm a firm believer in if you write your code, it is your choice to pick a license, and version 3 is a fine license. Version 3 was not a good... Here, we give you version 2, and then we try to sneak in these new rules and try to force everybody to upgrade. That was the part I disliked. The FSF did some really sneaky stuff, a downright in moral, in my opinion. You're talking about devolusation? The devolusation was always my main dislike of version 3, and the FSF was being very dishonest saying, hey, we actually allow you to invalidate the devolusation clause, and they tried to... They literally lied to people and said, hey, so that means that you can use GPL version 3 without the devolusation part, right? This is... How many people heard this particular statement from the FSF? Maybe they only tried to convince me with that one, but they did, right? And it was like, I'm not stupid, right? Yes, the GPL version 3 allows you to say devolusation is not an issue for us, but it allows somebody else to take the project and say, hey, the GPL version 3 without devolusation is compatible with the full GPL version 3, so I will now make my own fork of this and I will start doing drivers that use the full version 3. Am I stuck then? I'm stuck saying, hey, I gave you the source code and now I can't take it back, your changes. That's completely against the whole point of the license in the first place. So the FSF was... The kind of stuff that was going on behind the scenes made me once and for all to decide to never have anything to do with the FSF again. So if you want to give money to an organization that does good, give it to the EFF. The FSF is full of crazy, bigoted people. That's just my opinion, right? Actually, I overstated that a bit, right? The FSF has a lot of nice people in it, but some of them are a bit too extreme. I wish the EFF cared more about software freedom, but so do you think that Tivozation benefits me as a user somehow? No. No, I don't. But that was never my argument. That was not why I select the GPL version 2. This isn't my whole point. It's not that I think Tivozation is necessarily something that you should strive for, but it is something that in my world view it's your decision. If you make hardware that locks down the software, that's your decision as a hardware maker. That has no impact on my decision as a software maker to give you the software. Do you see where I'm coming from? I don't like locked down hardware, but at the same time, that was never the social contract I intended with Linux. I mean, people may or may not realize that GPL version 2 wasn't even the first license for Linux. To me, the important part was always, I give you software, you can do whatever you want with it. If you make improvements, you have to give them back. That was the first version of the license. It also had a completely broken clause, which was completely insane and I was stupid. Hey, it happens. My original license says you can't make money change hands. That was a mistake. That was clearly just wrong and bad because it really didn't have anything to do with what I wanted. But I was young, I was poor, I didn't realize that the whole money thing wasn't the important part. I saw the error in my ways and I saw the GPL version 2 and said, hey, that's the perfect license. And then I saw the GPL version 3 and I said, no, that's overreaching a lot. That's not what I wanted. So I made Linux GPL version 2 only. You think getting the patches back is useful even if you can't modify the device that it's used on? Yeah, absolutely. Tivo itself was actually an example of this. Their patches were kind of crafty, but they were basically running on originally a fairly standard MIPS thing. And their patches were working around bugs in the chipsets they used. And they were valid patches. The fact that they then felt that their hardware had to be locked down some way, I didn't like it, but as I mentioned, I felt that that was their decision. And they had real reasons for that. That's something people sometimes miss. There are sometimes reasons to do what Tivo did. Sometimes it's imposed on you by wireless carriers. Sometimes it's imposed on you by Disney. Sometimes it's imposed on you by laws. The GPL version 3 actually accepts the last one when it comes to things like medical equipment, I think. But the point is that the whole Tivoization thing, sometimes there's a reason for it. I mean, I'm not a hardware designer. I think FPGAs and stuff like that is really cool. But I really don't want to impose my world view on anybody else. You don't have to use Linux. If you do use Linux, the only thing I ask for is source code back. And then there's all the other verbiage in the GPL version 2 about exact details, and those aren't important. And that was always my standpoint. OK, well, I'll stop when I'm placing the mic now. I mean, I like other licenses too. I have used the four... Which BSD license is it? That's the acceptable one. One of the BSD licenses is actually really nice. And it's actually the... ISC. And I actually encourage people who don't care about the giving code back, but care about the, hey, I did something cool, please use it. I encourage people to use the BSD license for that. And I mean, the BSD license is wonderful for that. It so happens that I thought that for my project, that giving back was equally important. So for me, BSD is bad. But the point is for me, right? The GPL version 3 may be the perfect license for what you guys want to do. And that's fine. And then it's the license you should use. It's just that when somebody else wrote the code, you don't get that choice, right? I would like to come back to the topic of getting an application running everywhere on every distribution and compare it to the out-of-three modules in the kernel, where the rule is to get your module in the kernel, could we ask maybe the same for the application to get them merged into distributions? I think that's what actually happens quite often. I mean, this is what most of you, I actually, I don't know what most of you are doing. I'm assuming most of you maintain one or more packages. Am I completely wrong? No, okay. So most of you, your work is literally to bring in the application into the system. And I think that's actually the right solution for all the base applications. Do not get me wrong. I do not think that something like 90% of the core stuff that is open source should just be in the distribution. But then there's the crazy stuff, right? There's something like some surface is open source, but let's face it, we have maybe 1,000 users worldwide out of which maybe a couple of 100 are running Linux, out of which maybe 10 are running on Debian. I don't know. We do have some numbers. So those numbers are not completely made up. But my point is, if you have 10 users on Debian and you have 10 users on Fedora, and I know we have a couple of users on... Actually we have a couple of users on Arch, and we have most of the Linux users seem to be on Ubuntu, which actually kind of makes sense, right? Because divers are not necessarily computer technical people, and Ubuntu has been selling to that kind of crowd. So if you have that kind of situation, does it make sense to have people inside every distribution package that application for that distribution and do so in a really timely manner when we're making major changes that is really important to users because without those changes, their dive computer does not work, right? No, it does not make any sense at all. So even for open source projects, bringing that project into a project like Debian is just waste of manpower. You guys have better things to do. Trust me, you really do. Some surfaces are fun applications, but nobody should waste their life. Oh, maybe the maintainer is actually here. But the point is, I'm grateful we actually do have a Debian maintainer. Did I screw that up? No, but it's... This is an example of something where it would make more sense for us, like for Windows, we have nightly builds, and by we, I don't mean me because I haven't touched a Windows machine in a long time, but Dirk Hondl, who is the real maintainer, builds basically nightly, and it's really convenient because these users that have problems with a particular model of dive computer, he can make a Windows binary and say, hey, install that package and see if it fixes your problem. This is what you want for real users, right? For Linux, we can't do that. The Debian package is out of date. It's not a nightly build. There's no way to create a nightly build. The only thing you can tell these kind of people is, hey, take the git tree and compile it and see if it works or not. And that works if you're people like us. But if you're a diver who's in Hawaii and has trouble with his dive computer and is running Ubuntu or Debian, it's not really a very good solution, right? So even for open source, I don't think distros should maintain everything. You should do the core, and the core is still going to be thousands of packages, right? There's no question about that. And then we have all the commercial software and Debian is probably mostly people who really don't care. I don't know. Maybe I'm just projecting here. What is Debian's feeling about, like commercial databases and stuff like that? I don't know. Yeah. So I'm probably talking to the wrong crowd, but some other distributions definitely have the whole thing with, no, hey, Valve is actually using Debian, isn't it? They started off using Ubuntu, but now they're using Debian, right? So even Debian should be aware of these kinds of commercial packages. And for them, they have to give a package. And right now, they have to pick not just a distro, but a version of the distro. So I think we have time for two more questions. How convenient. You're really timely, I guess. We're running badly low on the number of friends. So I have to ask, sorry, behind not being able to watch kittens on TV and GPL3 and NVIDIA and breaking user space. What is, you think, is the thing that is most strong with the world? Most strong with the world. You know what, I mean, I'm famous for being a negative Nelly and just shouting at people and being an ass in public and just using 20% curves words in any random email. The fact is, most of the time, I'm actually very happy. It's just that when I'm happy, I'm quiet, right? So I'm not really all that down on things. It's just that when you see me in public, it's usually because something went wrong, right? So world is good, everything is okay with it? The world is actually mostly good. And Linux is doing great and I really have no real complaints. But then I get up on the wrong side of the bed and I want to bite somebody's head off and somebody sends me a patch that breaks something and I get really upset. Actually, part of it is I actually enjoy arguments. People still quote the argument I had with Andrew Taunambam 23 years ago because I was a young stupid university student and what do I do? I start arguing with the professor who made the operating system that I was using. So I'm argumentative, I get negative, but on the whole, I mean, things are so good. Not being able to watch kittens actually tops it. What? Not being able to watch kittens on YouTube actually tops your list. I can watch kittens these days because I've stopped having to care about flash because it turns out Chrome has flash built in and they actually maintain it, so I don't have to worry anymore. And even like I'm famous for my NVIDIA rant, even NVIDIA, what the hell happened? They have been active maintainers in their areas. It's like the world turned all pink and roses. Your rant happened? I'd like to say that maybe it was helpful. It certainly raised the profile of the problem. So, hey, maybe sometimes cursing is good, right? But I actually think the rant raised the issue, but realistically NVIDIA also noticed that Android is so important to them and Linux has actually become a major player to them now that they are working on the mobile space. So they started realizing, hey, maybe we should play together. And that's the much more important part and that's the one that has brought so many companies around. Thank you. So I just wanted to ask a question about security, get your ideas on that. Are you familiar with capsicum and the per process? I've heard the name. I have to admit that I do not know the details. So it's per process, so you can fork a process and then limit the privileges on that. But I'd be curious about your thoughts on SE Linux or App Armor or any of the other. So the thing is, I dislike black and white people and a lot of the security people are very black and white and the only thing they care about is security. This has often resulted in me butting heads with security people. At the same time, security is important. There's no question about that. We've had problems with security code that does horribly, horribly bad things because the people who wrote it thought security was the only thing that mattered and we've had huge performance issues, for example. And I used to run without SE Linux because when I did file system optimizations, having SE Linux enabled was completely pointless because at that point any optimization I did was worth nothing because SE Linux would just take up all available time checking credentials. At some point I realized everybody else is actually running with SE Linux on so I started turning SE Linux on and seeing where the problems were and most of them were reasonably easily fixable. SE Linux is still quite noticeable under certain loads but it's much better than it used to be and I'm not taking credit for all of that. I am taking credit for some of it and pushing some of the involved people into looking more at performance angles because performance matters even when security matters. One of the biggest problems I've had with SE Linux or not so much with SE Linux but security in general is people constantly tend to ask me to mark security bugs in commit logs and it's one of those things where I push back very much because some of the first people who read the commit logs are the black hats and marking something as a security bug tends to just help that class of people so I'm very nervous about doing that on a per commit basis because once you see, hey, this one liner fixes a security bug it's not that hard to figure out what the security bug is. So I consciously do something that some security people absolutely hate and they think I'm a weenie and they make that very clear by kind of not making a big deal of it. The other reason I don't make a big deal of it is that most bugs can, or not most but a lot of bugs can be security bugs and you don't even realize there was a great write up of the project zero bug how many read it, it was like last week where there was an overflow in G-Lib C of a single byte on the stack and the overflow was only a zero byte so it was an off by one error on a bounce check with a string wow those never happen, right? And basically the argument was this is not a security bug because there's no way to take advantage of it and then it took people a couple of weeks and it's a really interesting read of how you turn that zero byte bug into an actual root hole and it's interesting not because it proves any particular point except the fact that you can turn pretty much any bug into a security bug and this again flies in the face of saying marking patches of security fixes because hey any fix can be a security fix so I'm at odds with some of the security people at the same time it has been interesting working with them some of the smartest people and most I mean emails that make me go wow this guy is just out of this world smart have actually been from the people who have been on the wrong side of the security debate some of that has been really eye popping so I kind of sometimes end up respecting the black hats more than the white hats which is kind of sad because from a technical angle sometimes they seem to be more on top of it but I think we're doing a reasonably good job and I say reasonably good because I don't think this is something you can solve we do this as well as we can on security and we have multiple layers so SC Linux or App Armor or anything like that is just one of the layers we need to be aware of and most of the layers aren't even in the kernel so user land layers that need to also work so that maybe didn't actually answer the original question but the question was kind of open-ended Thank you very much