Session:Linux where are we going ELCE 2012
- Linux: Where are we?
- Dirk Hohndel, Linus Torvalds
- Intel, Linux Foundation
- LF, where art thou?
- ~ 47 minutes
- Transcribed by
- Jan Engelhardt
- Verified by
- 1 -
(Fast pass - there _are_ orthographic errors still.)
[…] which is: you are destined to be successful. And, but, you know, one of these challenges that Linux faced early was that proprietary […] would create fear, uncertainity and doubt (FUD) about open source. So you should be careful, because they are going to take your slides and describe a scenario where 3D printers start to self-replicate, take over the world, right. […] I can give you, just for today.
Right, our next speaker needs very, very little introduction. He is the creator of Linux itself, Linus Torvalds. He is here for the first time in Spain, and I look forward to hearing from him and from Dirk Hohndel, the Chief Linux and Open Source Technologist at Intel, to talk about where Linux is going.
So, come on up, Linus and Dirk. (Applause) (Gangsta music selected by the people behind the curtain to be played through speakers)
?: Oh wow, this is the *haha*
DIRK: First, a request. I have seen quite a few empty seats, and there are people piled out in the hallway over there (<<<). If you have an empty seat next to you, can you move this (>>>) way and make space, so [that] a few more people find a seat and do not have to stand […]? I really appreciate the […] The people who are now getting a seat also really appreciate that. Oh, look at this, there is lots of free seats, guys, is that not awesome? I like how this works.
DIRK: This is what is called “crowd movement”, right? So, we now have lots of free spaces around the aisle here. Please come on in. Thank you everyone for making this an increasingly warm morning in this conference room here. It is exciting to be here. Linus is actually here for the first time. I have been to Spain quite a few times — my mother used to have an appartment just an hour south of Barcelona, so I have been here a few times.
DIRK: I at first thought we should be, you know, congengient(?) of the current situation and turn this into the election 2012 dis[…], but I think Donald Trump has taken all the good points already, so we will both skip this and, instead, let us talk about Linux. Linux is more or less at drinking years age now — 21 years old.
LINUS: In the US, it is 21. Here, here it is, what, 15?
DIRK: No, 15 is when it is mandatory to drink.
DIRK: But, we have done a lot of talking about 21 years of Linux, so the news, I guess, is not so much in the last 21 years. The news is in, as the title of the presentation says, “What is next?”. But still, what do you think were the highlights, what are the things you are most proud of that Linux achieved?
LINUS: I think the highlight for me has been something that I did not expect, which was, when I started, Linux was my personal project. I sat in my […]. It was not a basement, but it was a dark room, like, keeps the evil sun aways, so that you can see the monitor better, and it was completely […] single person working on a small project on his own.
LINUS: And I felt that was very interesting and the technology was very fun. But especially these days, what makes it so much fun, I think, is the technology is still intersting, but what is even more so is the discussion and the community and the arguments. A lot of arguments, but it keeps us kind of interested, motivated to discuss things about Linux and how things should be done, and the community around the kernel in particular has been the biggest success.
DIRK: But that is kind of an inward-facing view. But let us turn this around — what do you think has been the biggest impact outside this company, you know, besides curing, you know, cancer, and world hunger and all this. But, where do you think, what is, if a stupid conversation partner like me asks you: “What is the one thing you are most proud of that you have achieved through the nets, with the impact outside of the developer community?”
LINUS: I would not say “I have achieved”, what I find...
DIRK: “We have achieved”
LINUS: ...interesting is actually, the people who do things that I would never have done, and I am not actually personally even interested in it. So, all the people who — I do not know how many of you are aware of the OLPC One Laptop Per Child project, for example. Things like that, where somebody tries to improve the world, and this is so not me. (Audience laughter) I did not do Linux to improve the world, I did Linux because the technology was interesting, and I just found that part fascinating. But what Linux has then allowed others to do, others who actually care about other people to trying to get to these— (Audience laughter)
LINUS: But seriously, it is really fun to see those projects and see them exactly, because you realize “no, I would never have done anything like that”. And there is tons of these small projects, the small projects are often the more interesting ones. I mean, when the big companies say “We make a big business about ~~”, I do not care. I mean, it is interesting to see that too, but I think the small oddball projects are what makes me feel like “Hey, that is fine”.
DIRK: So, since this is all about you, then let's make it about you. What was the award that you personally received that you were most proud of? I mean, I assume most people are aware that you got the Millenium Technology Prize this year, shared with an other scientist who, a few weeks later then, got for the same the Nobel Prize in medicine, so,...
LINUS: ... yeah ...
DIRK: what is the highest […] which—
LINUS: […] There is no Nobel Prize in Computer Science. I like getting awards, but at the same time, it is not why I did it. It is not a big deal for me, it is not, it is something that ok, it is recognition and I appreciate that, but at the same time, it is not what motivates me […] what I think about my doing Linux. So, I should not say “I do not care”, because I do care, but it is not that important.
DIRK: So far we have established, you do not do this for the other people. You do not do it—
LINUS: No, but I do it for other people in the sense that I actually view it like the community, it really a motivating factor. But I do not do it in order to help Third World countries. I find it exciting that other people do, but...
DIRK: So, I throw this in. This is obviously not just the two of us talking. We talk way too much with each other anyway. Please, if you have questions, raise a hand. I am not sure if we have microphones, otherwise yell and I will repeat.
DIRK: I absolutely encourage audience questions, but until I get some, I will continue.
LINUS: I would like to just say that one of the reasons I do not do public speaking. I absolutely […] standing up here with slides and speaking[…] audiences I do not know what you guys are interested in. So,...
AUDIENCE MEMBER: NVIDIA.
AUDIENCE MEMBER (mic): NVIDIA.
[Referring to Linus's “Fuck you, NVIDIA” stance earlier the year.]
LINUS: I had answered that question exhaustively. (Audience laughter) But I do find, I mean, I really this is supposed to be a questions-and-answers session, so I wanted to point out that, please do feel free to shout out your questions. There is, hey:
AUDIENCE MEMBER: Jonathan Corbet [of LWN.net] said yesterday that Linux was for one time chasing the tail lights of all other systems, and at the moment, […] we are not chasing tail lights anymore. So we are driving in the dark, […] which means you […]
AUDIENCE MEMBER: […] Where are we going?
LINUS: Do we need to repeat that question? You were loud and nice, I think people heard the question.
DIRK: No, they cannot hear in the back. So the question is, Jonathan Corbet said yesterday [2012-Nov-06] that we are no longer chasing tail lights of others. So, the question is, we are now obviously driving in the dark and he [Linus] is steering — where are we going?
LINUS: The kernel I would not be too worried about. The kernel has always been kind of defined by the interfaces of the hardware and the platform software above the kernel. So, the kernel has never really had a steering wheel to begin with. The kernel has been defined by the uses and the hardware platform its built on. And we are doing really well. I think some of the other open source project have less of a direction in mind — and I will not name the projects because people know what I am talking about.
[Interpretation of transcriber: He is probably thinking of graphical desktop environments and his own personal forth-and-back swining experience with them.]
LINUS: But, we are in a situation where sometimes people do not have a vision of where they want to go. The kernel has been in this odd situation that I never had a vision of where I would really wanted to go. I mean that very seriously. One of the things I think has so successful about the kernel, the kernel did everything I really expeceted it to do back in the fall of 1991. Right, and ever since then, and actually the reason I continue doing the kernel was, what has defined the direction for the kernel has been all these odd people and odd companies that have certain things they want to solve, and for the kernel, the direction has always come from the outside.
LINUS: And I actually — that has been one of the reason that Linux has been so successful is that I and a lot of other kernel engineers did not have this vision of “we want to drive it in that particular way”. We were very open to the visions from outside, and some other projects have not necessarily always been as succesfully taking direction from outside.
DIRK: So since you are not a new GUI toolkit, although we all wait for “LTK” [pun on GTK].
DIRK: What are the open source projects you are engaged in, besides the kernel?
LINUS: I try not to get too enganged in other projects, part of it is: I just do not have the time. I also do not tend to have the interest. Peronsally, I think kernels are interesting because they are very low-level hardware. I had to get involved in Source Control Management — so hopefully you all use git. I am very happy to say that it was written for the kernel needs, but turns out, a lot of projects noticed that what git does is actually the right way to do software control management.
LINUS: The third projects I have been involved in, is, Dirk is actually the lead developer for out diving log software and that is not a big important project, but we will take over in the diving world someday.
DIRK: I beg to differ on the last qualification. <>. Hard to see, very bright light. There, yes, Sir. Oh, there is a microphone, awesome!
AUDIENCE MEMBER: [Linus,] you said you are not very much conerned about the future of Linux as far as the kernel is concerned. So what is that worries you the most about the future?
LINUS: So I am actually a very optimistic person, I am not hugely worried about the future.
LINUS: The things that tend to make me stay up at night are — every once in a while, we had difficult personal relationships. And, we are, the kernel people, I mean, I do not know how you are actively involved in the kernel commnunity, but we like arguing, and, (Audience exhilaration) being heated is not necessarily bad. But sometimes, there are personalities that clash a lot and can be problematic. It is not actually that common, but when it happens, it is one of those things that make me worried. Then, there is the just legal situations everybody knows about. The issues with the patent system is just broken. It is more so in the US. I think the European patent system is in better shape than the American one,
LINUS: but it is clearly not perfect here either. We have had — In the US, we have had these really bogus copyright lawsuits too. That is not something that I worry too much about, but it is very irritating when, like the SCO drama dragged on for, whatever, 8 years?! It is a long time. So, the technical side I am not worried about, because I think we are in a very good spot and have a very deep and good kernel community. And, technical challenges I do not worry about. I do worry about community issues and legal issues and occassionally, I worry about hardware companies.
[He is thinking about NVIDIA, probably.]
DIRK: More questions — over there... microphone is on the way.
AUDIENCE MEMBER: It is question [sic] connected with hardware companies. They are very frustated with Linux; it is too speedy. Interfaces is [sic] changes too frequently. This is a problem with hardware guys. (I am from the hardware guys, partly.) While we were working for some hardware, you have changed already [sic] like three to four steps. For the business, is [sic] a very frustating. Do you think is [sic] this necessary to speed up such, such big speed of changing interfaces? Our […] [problem is not with] the scheduler or something, but interfaces is [sic] changing too rapidly.
LINUS: So, we have had issues with that. I am guessing you are working for an embedded hardware [manufacturer].
LINUS: One of the biggest issues we have had with hardware companies, certain classes of hardware companies has been [sic], they like to use Linux, and especially in the embedded world, but they come from a model where you have a product cycle that you do development for anything between one and five years, and then you maintain that product largely unchanged 5, 10, 15 years. And, they came from a background where software is largely static. I mean, they buy a license to their software stack and that is what they use for the lifetime of the product. And we had huge problems initially with the embedded side, the embedded hardware companies who just...
LINUS: ... wanted to continue doing the same development model. And they found it very painful to take a kernel release and then two years later, when they wanted to […] the hardware, everything had changed from under them. And I do not think it is something where we, in the kernel community necessarily, have needed to change. We have had fairly good luck with slowly — kind of — introducing the open source model to hardware companies themselves, so that a lot of the embedded devleopers are much happier tracking our kernel instead of staying on one kernel and then a few years down the line, noticing that everything has changed around them. They are much happier now to track kernels, and that has made it, I have to say, in the last few years, it has become much more pleasant with a lot of decent […] vendors.
LINUS: It sounds like not all of them have quite caught on yet...
(Audience exhilaration) [probably thinking about NVIDIA again]
LINUS: ...but things are getting better. It is very hard for us “No, we will not change internal interfaces”, because quite often, we end up having to rearchitect some driver subsystem. And then, when we make changes, we will have to change every single driver that uses that subsystem to work with the changes. And saying “No, we will not do that”, because we want to stay stable internally — (a) it does not allow us to make the changes we need to do, and (b) it is very frustating to developers. So, I do not think our model is going to change much, although, as the kernel […] large portions of the kernel no longer see huge changes anymore.
DIRK: I think the ability to make changes and the ability to change even internal interfaces is one of the major strengths of Linux. And, in many ways for hardware vendors — I obviously work for Intel, which is, I think, a pretty big hardware vendor — uh, it is a learning experience. And once you buy into it, and once you say “We do our development upstream, we aggressively work in the upstream repositories and do so in the way that means we integrate the community into our own development model”, then this actually becomes an advantage for you. And once you reach out to the commnunity and take them seriously, and do that work, it is a major advantage that you have in innovating and creating interesting products. So, in many ways, I understand the question, but I would say it is also an indication of maybe you need to try a little harder to work upstream. And then, it becomes much, much easier.
DIRK: More questions? In the middle back there!
AUDIENCE MEMBER: I am coming from another side, not from the hardware, with embedded system, but with very large systems. We are using Linux for a very, very large system. And what we are kind of worried every time is what is going to happen in the next release? Because, for example, lately, we have moved from the O(1) scheduler to a completely new scheduler, and I feel in my bones that there has been an impact(?) struggle towards this scheduler, because there have been different variance. And now, we have one scheduler that we think we are going to concentrate on, and we are going to […] according to this one.
AUDIENCE MEMBER: But, my colleague from my work came one day to me, and said “You know what, I saw they have next release [sic], and they took out the cgroups”, and I said up “Man, they took out the cgroups? What do you want from[…] is gone?” So, I understand..
LINUS: cgroups is still there.
AUDIENCE MEMBER: Oh yeah I know that.
LINUS: Not everybody likes them, but they are still there. Uhm, what is actually, I mean this is a real issue, in general is that one of that is, how should I put this, especially the specialized systems, and this is true both on the big very like supercomputer-side, and on the embedded side. They do not get the same kind of day-to-day testing that a more normal size system gets,
LINUS: the kind of system that developers actively use every day. So what we do see and what I think is very true is that we do most of our testing, not just the developers, but if you look at the user base that uses Linux and especially uses modern kernels and is willing to test out development stuff, they tend to be a class of hardware that sits somewhere inbetween, in the middle. So, we have anything from 2–16 CPUs, and then if you go way beyond that, and make supercomputers, it is often the case that you notice that we made changes and we have not been able to test those changes on your 4000 CPU monster — because there is [sic] only five of those in the world.
LINUS: And, in that situation, you do have the source code available. But I realize that I can sometimes be slightly painful when you make changes and we cannot always test on your system. I think that is somewhat unavoidable. It is not perfect and I actually love this for us kernel developers to have a much and wider range of hardware we can play and do daily builds on. And the fact that our daily builds and daily work tends to be done on a very limited set of machines is sometimes a problem.
DIRK: So, we at Intel actually do builds with fairly sizable machines and we provide information on regression, performance, but again, this is, you know, 16-core or 32-core system, not much more thousands.
LINUS: Yes, it is the extreme ends that usually, they tend to be specialized, and they do not track daily stuff,
LINUS: They sometimes do not even track monthly stuff. They may upgrade every year or two, because they are big machines and they are used for big things.
DIRK: More questions. Over there. I am trying to make them as far apart as possible. The mic is right next to you.
AUDIENCE MEMBER: Last year, you stated that you […] Linux kernels developers are not really focused because you cannot easy, cannot easy(?) the change the kernel on devices, for example in […]. Is it going to change soon?
LINUS: Uhm, I do not really that much. I mean, it is true that kernel developers often do not interact with individual embedded systems that much, because most of them tend to be very locked down, even when they, you can change the kernel on your cellphone, it is usually just made unnecessarily painful by the phone manufacturer with a lot of bootloaders and so on.
LINUS: At the same time, most of the embedded systems these days actually tend to look fairly similar. There is being a huge amount of standardization in the embedded world, mostly around ARM. And it means that even though people may not develop for one particular phone or something like that, a lot of the work that gets done by a lot of kernel developers is actually for embedded systems. And they just tend to use, there is, development boards that they either get from work or buy online, you can get them fairly easy online — that look not exactly like a phone, but are close enough that we actually are doing, I think, much better in that space today than just 3 years ago.
LINUS: So, the embedded people have been very active and have been, I have been so pleased with what has happened in the ARM community in the last two years that I do not worry about the embedded at all as much as I used to.
DIRK: There are a lot of projects that try to make this easier. The Yocto project, which is also a Linux Foundation project, has tried to consolidate the efforts around embedded Linux development, and make it easier for people to rapidly develop and deploy embedded systems. So this is not just the kernel, it is much more the whole stack that needs more ease of use.
DIRK: More questions? All the way back there, Gentlemen.
AUDIENCE MEMBER: A very general question. Where is the next Linus Torvalds in the OS business? Will there be a new very disruptive […] in the next 10 years or so? Or is Linux as innovative as you can get?
LINUS: So, I may be a bit biased,
LINUS: but realistically, I do not actually think operating systems need all that much innovation. I mean, just to a large degree, when I started Linux, there were all these crazy people doing “innovative” operating systems, and they were all horrible. And they were trying to do things in new ways, and it turns out, sometimes, the old ways are the correct ways, and, you have done something for 30 years one way, because that works. And, I do not think there is a lot of innovation in operating systems that it is worth doing. I think what operating systems should do, and this is how I, what I think is important when I look at Linux, is to work well. It is not about innovation, it is about getting all the details right,
LINUS: and doing the right thing, and really getting performance right, being able to run across a wide variety of machines, doing the best you can do in security, in getting applications all the interfaces they need to do their work right. It is not about trying to come up with a new of doing things. And if you actually look at all the major operating systems today, they are pretty much based on ideas that were basically developed 50 years ago. So, I think innovation, I mean, I am not saying innovation should not happen, but I do not think you should necessarily do innovation in the operating system area. You can do cool small thigns within an operating system. There are lots of details inside the kernels that are worth doing better,
LINUS: but I do not see some genius coming around and saying “Hey, we should just switch around how we do things, and do this completely new operating system”, I do not think that makes sense. I think it makes more sense for somebody to say, “Hey, there are all these cool things we could do with computers, and let's just build on top of existing hardware and existing software to get those cool things done instead of trying to rearchitect the world.”
LINUS: That said, I am biased. And […] some crazy young guy — or gal — comes around and shows me wrong, and that would be interesting, but I think it is unlikely.
DIRK: I think one of the challenges is the network effect. We have so many people working on Linux, so many people working with Linux, on top of Linux, to try to compete with this brain tank that is working on that is certainly going to be very hard.
DIRK: And the question is, is it worth the investment? Would it not be much more valuable to focus on creating the […] above this infrastructure that is there. And that seems to be where the industry is going. I mean, if you look at the phone market with Android, and if you look at many of the embedded places where there used to be all these proprietary operating systems, and they have mostly disappeared, it is mostly Linux these days.
DIRK: More questions? All be on the side, because I always go for the middle, and this is the longest way I can send you.
AUDIENCE MEMBER: After we used the kernel like for over 10 years, […] it gets larger and larger and larger. And, obviously some of the things in there are not required anymore, per se. So, I am just asking, is there ever like some procedure to get things out that nobody uses anymore?
LINUS: We do remove stuff — occassionally. But there is a fairly high threshold for removing code. One example of this is, we, or rather […] did some architecture massaging to try to use the same generic code for a lot of the standard process handling like fork(2) and exec(2). And in the process, we have noticed, that we have two architectures that clearly have not worked at all for at least two years, or something like this, right. And nobody uses them, and nobody has every complained. They kind of compile in the cross-compile environment, but nobody cares. And we have not removed them, even though clearly, they are not getting used. And one reason for that is, it turns out, that, what occassionally happens is,
LINUS: somebody, some random person in the middle of nowhere has access to a piece of hardware and finds that the kernel almost works for him. And he says, "ok, I will take over maintenace of the kernel for this piece of hardware, and I will fix it so it works for me". And that is not only how we often get new people, it's just fun to see. So, I actually say hey, there is no real cost to maintaining this code that clearly nobody uses and really does not work. By "doesn't work", maybe it works in practice for people, but it has known bugs. It's better to leave it be and allow people to come in and say "I will step up and fix it", than it is to very aggressively say "hey, clearly this is broken, we should just throw it away".
LINUS: So we actually do not remove code unless it has major problems, generally. Most of the time, this kind of code, people don't ever compile in. I mean, this was/are architectures, that if you run on any normal machine, it will not get compiled, it will not get used. So, a lot of the code in that sense, it has no overhead apart from existing.
LINUS: Sometimes, there are real overheads that, the security people in particular have added over the years, and we cannot remove, because there is [sic] 5 people who still use those interfaces. But quite often, we have drivers or architectures or filesystems that are just not getting used, but we still need them in, in case something comes along and says “I want to maintain this”.
DIRK: But having said that, you do have a process to remove code, and it happens at times.
LINUS: We do have a process to remove code, but it is rare. And it is clear that we add way more code than we have ever removed.
DIRK: […] Linux keeps growing.
DIRK: Back there‽
AUDIENCE MEMBER: My question regarding Android and Linux consistence. Your vision about this. Until now, Google st[…] well and uses Linux as a […] and now, Android have changes in kernel side [sic] […] […] […] […] […] […] […]
LINUS: So, the Android situation actually is much better today than it was a year ago, or two years ago. The Android situation is not actually all that different from say the RedHat or SUSE situation some 10–15 years ago. The fact is, a lot of vendors end up doing their own forks and saying “We need these changes to support the market we are going after”. And what happened in the case of Android was that Google had this vision of where they wanted to go, and they needed to the kernel and they said “[We] will do that”, and they were obviously fairly successful. On the other side, we had kernel developers who felt that the extensions were not always very well designed and well thought out, and said “Hey, you should have done it in a completely different way”.
LINUS: And, for a couple of years, there was, there was discussion on bad blood about this. And people worked on trying to convince the Google people to change the way they are doing things. But, the Google people at the same time have the situation that they have applications that are using the interfaces they started they designed with. A year and a half ago — when was this? —
DIRK: Almost exactly a year ago.
LINUS: We in, yeah, in the kernel community just decided, “Hey, the Android thing is clearly for Google, and we should just stop being difficult about it and start merging the code back”. And, it was not that Google did not make the code available to us, they always did. It is that we in the kernel community were kind of fighting taking it.
LINUS: And now, a year has passed and we not taken all of it back yet, but I think most of it is now in the standard kernel, and there is a few pieces that are details that people do not care that deeply anymore that Google still carries in the Android tree. But, this is how development happens. This is how kernel development has always happened. It is just people kind of forgot it for a while, cause, for several years, all the major distributions had decided that they do not want to create their own fork anymore, and they all were very aggressive at feeding things upstream first, and people had kinda forgotten that this is what all the distribution used to be 10–15 years ago. So, I do not think it was not that painful to me. I have seen it before, and the fact that companies come up with new usage models—
LINUS: often does mean that we have to change and improve our kernel interfaces to support those usage models. And it is not always easy for us to change, so it can take a few years to kind of get over it, and say “Ok, you were right, you have 100 million devices running your code, you must be doing something right, let's take it back”.
DIRK: There, right in the hallway, the gentlemen.[…]
AUDIENCE MEMBER: Last year in Prague, there was concern from all of the panel that kernel maintainers were getting older year over year...
DIRK: I am getting younger, what are you talking about‽
AUDIENCE MEMBER: And there is a higher barrier of entry for new people. Has the situation improved?
LINUS: So, I think last year I […] said — I do not think it is actually true. I think it is true that the main maintainers are getting older, because a lot of us have been around for a long time, I mean, I have been doing this for 21+ years, some of the main maintainers have been around for almost as long. So, we are, by definition, 21 years older than when we, what we used to be, right.
LINUS: At the same time, there is tons of new people coming in all the time. It used to be that people who came in to kernel development were literally, I mean they were highschool students, they were maybe 1st year university. It is true, that these days the people come in tend to be older, for that is often because they come in as professionals, because there are so many companies involved.
LINUS: So, it is not because we are getting older as a developer community, it is that the situation has changed. Now the kernel is so important for a lot of companies. You do not get — I mean, you still get highschool students, but you get even more of the people whose job it is to do kernel development work. So we are getting older, but I do not think this is a bad thing, I think this is just normal. I would be much more worried about if we did not have a huge a lively development community. But we are getting new people all the time, we have ton of people working on the kernel.
LINUS: The question that always comes up after the age question, so I will just mention it myself before somebody else asks, is, the males-females ratio question. And, it is just the fact that we are 99% male. And there are very few females, and nobody really knows why.
LINUS: It is not Linux-specific, although the kernel community is probably a fairly extreme case of that. But I mean, if you look at Computer Science, even at universities, once you get past a few years of Computer Science education, it tends to be very male-dominated. And it, there is something social about it, and we would love to change that. And we do have female programmers in the kernel community, but there is too few of them.
DIRK: Ok, I think we have time for one more question. Right there in the middle[…]
AUDIENCE MEMBER: In the past, the main focus on systems has been performance. Lately, there is a big thing about power usage. You have data centers that take up the power of a city, you have small embedded farms with a […] low power usage. What is your take, and where is that headed to?
LINUS: I actually do not think the performance-versus-power [discussion] really much of a versus. Quite often, you actually want the same thing for both power and performance. You want lean, mean code, and you want the code to be efficient, and what is bad for performance tends to be bad for power too. Power does have additional aspects to it, mainly that you need to have, device drivers in particular, need to be very power-aware to aggressively power down the hardware. So, so power does have that. I think I am for it. The good news is, people had become very concious about power. And it is not just the kernel people, this is very much the hardware manufacturers too. It used to be almost impossible to even measure power.
LINUS: I mean, you could measure power at the wall, but then actually knowing what that number meant when you actually measured power for the whole system was, used to be very hard. With especially embedded people becoming much more power-aware, they tend to have much better view into where the power goes, and that makes it much easier to debug. And, in fact, even on a laptop today, we have much better tools, so that we can see, ok, we are not, we do not just see, “Ok this laptop is using 11 W of power , but we can actually see ok, it is actually the panel is using 2 W of the 11 W, and the CPU is using 1½ W, and the network is using 5 W, and you say “Why is the networking chip using 5 W of power?” So, we are getting better at it, we are certainly not perfect, but I think people are very well aware of power usage, not just in the industry, but also inside the kernel community.
DIRK: So, Linus, the topic for our panel was “Where are we going with Linux?” And I know I will not get a 5-year outlook from you. I have given up on that question. But, can you at least give us a “what's coming, what is interesting” in Linux 3.7, 3.8, in the next 6 months?
LINUS: So, right now, we are in the, we finish the merge window for 3.7, and in this merge window, we had a few interesting things coming up. 64-bit ARM is happening in 3.7, and I was, something that had a lot of discussion, a lot of it was about the name, not so much about the code, and mine will [sic] prevailed, and it's called now ARM64 and not something odd ["AArch64"].
LINUS: But there has been a, we, for the last more than five years, how long have we been the whole time-based [release] thing? Six years? We have done kernel release not based on features, but instead on, we have the 3-month release window, and what is ready in time for the merge window […] will get in regardless. And that has meant that we do not — I do not — need to plan ahead. I do not need to say “Ok, in order to release kernel 3.8, I need to have ARM64 with SMP working and tested and ready to ship”. So, I do not actually need to worry about that, and it has made my job so much easier, I think it has made all the kernel developers' job so much easier, because now they do not have to worry about “Ok, let's get this ready in time for so-and-so release”.
LINUS: It has been “Let's get this ready”, and whenever it is ready, it will get merged. So I do not actually need to plan, not even five years ahead. Not even more than usually like two released ahead. I know, some of the things going in 3.8. And when I say “no”, I think it will happen, but if something big comes up, it will not make it into 3.8, and nobody will care, because there is always 3.9. So we do not have the kind of long-term plans, and I think everybody is much happier now.
DIRK: So to sum it up, we have no plan, but everybody is happy.
(Audience laughter, Audience applause)
JIM ZEMLIN: Thanks everyone, thanks for coming. In honor of Linus coming, for every single person in this room, we have a special gift for you. — It is the latest version of the Linux kernel, if you go to www.kernel.org! What did you think I was going to say? Alright, well, thank you for coming, we will see you next year at many of our events, enjoy the rest of the day.