• # Original version

    Posté par  (site web personnel) . En réponse à la dépêche Linus Torvalds : l’interview anniversaire des 20 ans du noyau. Évalué à 10. Dernière modification le 15 novembre 2011 à 16:56.

    LinuxFR : You've been doing Linux for about 20 years now and it's a hard job. Is it still fun ?

    Linus Torvalds : Oh, absolutely. It's still fun. And partly exactly because I've been doing it for 20 years, I wouldn't call it "hard". It's still challenging and interesting, but I think I'm good at it.

    LinuxFR : Why did you choose to switch the kernel from his original non-GPL copyright to the GPL licence ? Was it an ethical or a practical choice ?

    Linus Torvalds : Practical. I think my original license contained the ethical parts I cared about, but it turns out that it was too strict about that whole "no money" thing, and it also wasn't well enough known. Moving to the GPL fixed the problems that people had with my original license, and had the advantage that it was a known entity and also a lot more likely to stand up in court than the short blurb I had written originally.

    LinuxFR : I know that you consider yourself a very pragmatic person and not a prophet...but do you agree that there is an ethical content in the GPL license ?

    Linus Torvalds : I'll answer this two very different ways, and try to explain why I answer it two ways.

    So the first and the very negative answer is that I absolutely despise the people who try to push the GPL as being about "ethics".
    I think that's absolute bullshit. Why? Because ethics are to me something private. Whenever you use it as an argument for why somebody_else should do something, you're no longer being ethical, you're just being a sanctimonious dick-head.

    But the second answer is that I personally feel that the GPL (version 2) matches what I want to do. I really like doing programming, and I wanted to put my stuff out there for others to enjoy, but I felt that the whole "you can do with it as you wish, but your improvements need to be available the same way the original is available" is just very fair, and is a great way to do development.

    So personally I think the GPLv2 matches quite closely what I think is "the right way to live my life". And by "right way" I don't think it's the only way. I've done commercial programming too, and I enjoyed that a lot, and I think that was fair and appropriate too (hey, they paid me for it).

    So I think the GPLv2 is a great license, and I use it for my own personal reasons. I do think that's true of a lot of other people too, but I really want to point out that it's not that the license is somehow ethical per se. A lot of other people think that the BSD license with its even more freedoms is a better license for them. And others will prefer to use a license that leaves all the rights with the original copyright holder, and gives no rights to the sources at all to others. And for them, that is their answer. And it's fine. It's their choice.

    Trying to push any particular license as "the ethical choice" just makes me mad. Really.

    LinuxFR : Why is the desktop so special and so much harder than any other market ?

    Linus Torvalds : Because it's so much more interesting. It's the market where people do so many different things.

    Your average server does almost nothing. Sure, it may have a lot of CPU power, a fast network, and lots of IO, but it does the same thing over and over again, and that "same thing" is pretty limited. It's running a database, a mail or web server, various analytics etc. It may be important for the company, but it's not a very varied workload,
    and it's not something people are attached to.

    In contrast, your desktop is what you see every day, and you get attached to it. The attachment might be some kind of "stockholm syndrome" where you really don't necessarily like it (think of all the people who grew to know computers through DOS and Windows, and the three-finger ctrl-alt-del salute), but even then it becomes a kind of dependency where you get used to it and rely on it rather more intimately than you ever end up relying on the company mainframe.

    And the desktop does so much more. You play games on it, you do word processing on it, you do development on it. It's not a single-trick pony. Of course, for some people it has also become "you use a web browser on it" and nothing much more, but even that single use tends to in many ways be a more complex workload than most server workloads.

    Of course, what's interesting is how smartphones are slowly starting to share many of those desktop complexities. It may not be there yet (and maybe it never will be), but phones already have a fair amount of the same rich and complex media issues that desktops have, and are getting more varied uses.

    LinuxFR : Why Linux desktop hasn’t been adopted by the mainstream users ? Is it possible for the kernel community to improve this situation or is it mostly a user space problem ?

    Linus Torvalds : I don't think there's much we can do on the kernel side, except continue to improve in general, and make sure we remain the technically best choice.

    And it's not really that we don't have mainstream users - Android is an example of lots of mainstream users for Linux. The problem is that the desktop is a difficult market to reach. There are huge amounts of "network effects" where having existing users is a big reason to retain them and get more new users. It's also that most people really
    really don't want to change their environment, and if they do switch, they want help and support. Where "support" is not necessarily about commercial support, it's about knowing that you have people around you who know the system and can give you advice etc.

    Getting past that hump is hard. And it's not something that happens by pointing at technical issues. It's often a social issue.

    LinuxFR : I know it's a strange (and probably dumb) question but are you still able to fully understand all parts of Linux kernel or do you really need trusted maintainers ? For example concerning the complex pathname lookup patchs from Nick Piggin what was your process to choose between these patchs and the other solution from Dave Chinner ? Have you received some advices from Al Viro or was it your lone decision ?

    Linus Torvalds : Oh, I absolutely don't claim to know and understand all of the kernel. I know a wider chunk of it than most kernel developers, but there are many areas where I almost entirely rely on the maintainers, because I just don't know (or necessarily even care - we all have our own areas of interests) enough about some subsystem.

    That said, the example you picked wasn't one of those areas. The VFS layer and most of the VM layer I'm intimately familiar with, and so I had no problems feeling like I could make those decisions on my own, and support the end result even without further help. Of course, that's not to say that I didn't expect people like Al to help me, and
    I didn't talk it over with them, but when it came to the new pathname lookup, I was much more personally involved than I am in most other areas.

    Of course, usually I don't really want to feel like I need to be personally involved. The pathname patches had been around for most of a year, and weren't making much progress (there was a lot of discussion, but not as much forward progress as I wanted), so I ended up championing those patches a bit more than I would necessarily
    otherwise have done. I'd have been perfectly happy having them go entirely through the normal submaintainer channels.

    In some other cases, I can't do that kind of "I'll step in and make some executive decision", because I don't necessarily know the area well enough, or I don't feel like I can really end up maintaining the end result if I really piss off the maintainer too badly. So then I can prod and try to raise discussion about issues, but I'll just have
    to trust that somebody gets up and makes the right decision.

    (Btw, "right decision" is not necessarily the right word. Sometimes you just need to make a decision. It's not always clear what the "right" answer is, and sometimes it's fine to just say "we don't know" and not make a decision at all. But at other times you really do need to make some kind of technical choice. The good news is that most
    technical choices can be reversed if they turn out to be wrong later on - it may be very painful, but sometimes it's better to just make a choice even if you can't know whether it's the right one. Even if there is a chance that you may have to reverse that choice later)

    I should say that those kinds of situations are actually pretty rare. Most of the time the development process works without anybody having to make particularly difficult choices. Most of the time it's fairly clear that the forward direction is, and sometimes it's just hard to find people that actually write the code :)

    LinuxFR : What do think about this citation from Lennart Poettering ? : "In fact, the way I see things the Linux API has been taking the role of the POSIX API and Linux is the focal point of all Free Software development. Due to that I can only recommend developers to try to hack with only Linux in mind and experience the freedom and the opportunities this offers you. So, get yourself a copy of The Linux Programming Interface, ignore everything it says about POSIX compatibility and hack away your amazing Linux software. It's quite relieving!"

    Linus Torvalds : Well, I think it can be a reasonable way to simplify a very difficult problem (portability).

    But one reason it's likely to be a good way is that we really don't try to extend too much - and not unnecessarily - on the standard interfaces, so even if you do end up deciding to just care about Linux, it's really hard to make the end result horribly unportable. Linux is a pretty middle-of-the-way UNIX in many respects, and even
    outside of the unixes, most of the frameworks that you'd use on Linux are available on other platforms too (often because they are open source).

    So even if you later decide that you do want to be portable after all, going with Linux to begin with was probably not a bad idea, and it may have simplified the early decision process in a project.

    LinuxFR : Do you think systemd is a huge improvement in comparison to SysV init ? Is it a game changing technology ?

    Linus Torvalds : I also will take a somewhat wait-and-see approach, it's not widely enough used yet. I do think bootup performance is important, and anything that helps that, and helps make it more flexible is a good thing. Would I call it "game changing"? Probably not.

    LinuxFR : Do you use btrfs ? When do you think it will be ready to replace ext4 as the default recommended file system ?

    Linus Torvalds : I've used btrfs on a couple of the laptops I have, but honestly, when it comes to filesystem usage, the big factor is distribution support. Almost nothing else matters, as long as the core capability is there. So getting a distribution to pick a filesystem by default is the way it ends up being the commonly recommended one, simply because what most people care about in filesystems is neither features nor performance, but stability.

    And me personally, I don't worry about it any more. I had some issues with ext3 (horrible fsync performance in particular), but most of what I do is actually totally dominated by the VFS layer, because it caches so well (ie I have the kernel sources in memory pretty much all the time, and the filesystem doesn't matter because all the caching is
    done by generic routines).

    LinuxFR : With Linux and Git you've done two softwares that changed the computer world. How is it possible to have two gigantic success like these ? What is the difference between you and mere mortals ?

    Linus Torvalds : I think a lot of it is just stubborn persistence. Especially Linux - I was in the right place at the right time, but others could have done their own operating system. And others did. But very few people ended up just doing it as much as I did. I've been at it for twenty years. Most developers doing some random private project for their own enjoyment don't stay with it long enough for it to ever be even release ready. Much less for decades.

    With git, things were a bit different. Partly because I had a use case that was big enough (the kernel) that I could jump-start it, but partly because I really came at an old problem from a new angle, and I do think I did a good job as "architect" for the project. I really think that git has a fundamentally good design (in the case of Linux I
    could just build on top of the design of Unix that had already been done), and I could push it through because Linux needed more than the existing SCM projects could offer.

    But with git, a lot of the credit really does go to Junio Hamano. He's really been a great maintainer. People like that are important. Yes, open source programming is a team sport, but finding the right people is really the killer feature (the same is obviously true in the kernel too - I really do think we have a great set of maintainers. I may
    complain about them and I'm somewhat infamous for my flames when things don't work, but at the same time I'm convinced there's some of the best people out there working on maintaining the kernel).

    LinuxFR : I've seen that you read a lot about biology and evolution theory (for example Richard Dawkins). Is that knowledge useful for Linux process developpement ? Is it mostly a darwinian competitive model or a cooperative one ?

    Linus Torvalds : I don't think it's useful for the kernel, but it does happen to be a subject I'm interested in. Biology, evolution, human behavior - they are all fascinating subjects. And I think there are parallels between technological development and evolution. I obviously do not believe in Intelligent Design when it comes to biology (and I think anybody who does is woefully badly educated), but after all, I often think that "intelligent design" is much overrated in technology too. Many technical improvements really do seem to be about more "organic" developments, and very few are fully designed ahead of time. In fact, I think most interesting technical problems are too complicated to "design" for - the way you get to a solution is very much through incremental improvements and trial and error.

    LinuxFR : You are now an american citizen. What do you think about software patent law in USA ? Is your voice strong enough to help fight this law in this country ?

    Linus Torvalds : I have to admit that while I don't like patents, I also tend to try to stay away from getting too involved in issues like those. I'm good at what I do, I think there are people who are better at fighting the patent mess. And I think you need to do so from within the system - so I'd expect that any solution will actually largely come from all the companies who are being hurt by the mess that it is.

    LinuxFR : You often wrote detailled posts on realworldtech.com but I've never seen a post from you on lwn.net. Why ? Do you read lwn.net regularly ?

    Linus Torvalds : Heh. rwt is where I go to flame people and argue about computer architecture. I like people who argue back, and I also like how it's not Linux people, or even about Linux. So I can spout my opinions and see what arguments I can get to happen.

    lwn? That would be an entirely different kettle of fish.

    LinuxFR : Various people criticized kernel security. Do you think kernel devs put enough work on kernel security mechanisms and code review ? Do you think some parts of GRSecurity should be imported in mainline ?

    Linus Torvalds : I think we've done a pretty good job, but one of the problems with the security world is that it's so black-and-white. To some security people, even me just saying "pretty good job" is like a red flag. They don't think "pretty good" is good enough, they think security is somehow everything.

    And I disagree. Most security problems are just bugs. We need to try to avoid bugs, but bugs happen. That's a truism, but I think it's what it all boils down to. Are we better at avoiding bugs than other projects? I think we're doing pretty well, especially considering just the insane amount of code we write and change every single day. I really don't think it's useful to try to separate "security bugs" from other bugs. They're all just bugs, and almost any bug could be a security bug under the right circumstances.

    As to grsecurity, I think we've taken the important things, and left the extreme things (the ones that actually hinder usability or are otherwise extremely intrusive) behind.

    In general, the best way to security tends to be to have many different layers of security. You can never be entirely bug-free in any half-way interesting program, but with multiple layers of security, one layer will hopefully end up protecting against the possibility of a bug at another layer that might otherwise have resulted in an exploit.

    So in the kernel, we tend to try to have the generic layers already have security checks early, so even if there's a bug in a filesystem or a driver, it's harder to cause that bug to be exploitable. And when we do find some overflow, we tend to fix both the immediate overflow itself as well as (when possible) add checks at higher levels so that the overflow couldn't have happened in the first place. So in many cases we actually end up with several fixes to the same problem - each of which would have fixed things on its own, but together they end up hopefully being more resistant to a similar problem happening somewhere else (or later be re-introduced in the same place - it's embarrassing when it happens, but that has happened too).

    LinuxFR : Do you think security experts and exploits creator have a different mindset compared to other kernel developpers ?

    Linus Torvalds : Oh yes. Some of the more interesting exploits in particular have made me go "that needs a really twisted mind to come up with" and being quite impressed.

    But it's not always about being impressed. Quite often I get rather depressed by all the sleaze in security circles. It really is a circus. A lot of it is all about posturing and PR (on all sides:vendors, security people, exploiters etc).

    LinuxFR : I've done a interview with Brad Spengler (GRSecurity) and asked a question about his opinion on you and kernel security. Brad's answer was: "He at times can understand security better than some of the other developers, but security isn't one of his main goals (...) His ideas regarding security that have formed the official policy of kernel developers to omit security-relevant information in changelogs and treat all bugs the same are destructive".
    Do you think all bugs should be treated the same ? And why ?

    Linus Torvalds : I tend to think that all bugs should be treated the same, and I neither want to point out, nor particularly hide our security issues.

    The thing is, even security people cannot agree. Many of them want full disclosure. Others want very limited disclosure (vendors and big financial institutions). Others want just total secrecy, both to avoid embarrassment, but also at least to some degree to avoid the issue leaking to the "black hat" people who write exploits.

    And then there's the fights about leaks - everybody knows that there are different classes of "bad guys", ranging from just regular good people who want to try things out (hey, university kids who hear about a new exploit, and decide that they want to test whether the big university machines really do crash) to script kiddies who like being annoying but don't necessarily have all that impressive technical background and understanding, to people who are really smart and may well be doing things for serious criminal gain.

    How the hell do you resolve those discussions? I claim that you can't. There is no "right way", and the people who push their way of doing disclosure (or not) are demonstrably doing bad things.

    So my personal opinion is that the only sane approach is to just realize that it's not a solvable issue, and just treat bugs as bugs. We try to avoid having them in the first place, but when they do happen, we fix them. And we fix them without shouting from the rooftops about the details about how to exploit the issue, and without even trying to make it easy for the people who might want to try to exploit things to find them. And yes, that can very much involve not saying everything we know about how to exploit the bug in the changelog, or even necessarily pointing out that there is an advisory about it.

    Do security people always agree with me? Hell no. But they don't agree amongst themselves either, so what does that prove?

    LinuxFR : Do you have an opinion on OpenBSD quality ? They put strong emphasis on security. Is there some lessons to learn from this project ?

    Linus Torvalds : I think that any single-purpose OS project is a failure, and it doesn't matter what the purpose is. Security on its own is not a worthy goal - you need to have users for security to even matter in the first place.

    So I think the single-mindedness about security in OpenBSD just makes the whole project less interesting and relevant in the end.

    But again, that's just my general "bugs are bugs" thinking. I think security is important, but so is performance, and so are features. The world just isn't black-and-white. There is no one single thing that matters more than other things.

    LinuxFR : LLVM compiler is making huge progress. What do you think about this project ? Is LLVM architecture better than GCC and do you think it will replace GCC in the long run ?

    Linus Torvalds : Replace? Might happen, but I don't think it's particularly likely. I do find compilers interesting, and I think it's good to have some competition in that area, and so I like seeing LLVM make the effort.

    LinuxFR : There is a Linux kernel on my ADSL box sent by my Internet service provider. There is also a Linux kernel on my Sony TV and on my printer. However I'm not free to hack on my ADSL box, my TV or my printer (due to legal reasons or due to tivoization). What do you think about this situation ?

    Linus Torvalds : I personally think flexible hardware is more interesting than locked down hardware, but at the same time, to me the "fair exchange" was always about the software and the ideas, not about hardware.

    So my whole issue with Tivo and company has always been "hey, they designed and built the hardware, the fact that they used my software doesn't give me any special rights to the hardware".

    Since they are using Linux, I do expect them to make their changes to Linux source code available to people as the license requires. There obviously have been cases of companies not doing even that, but that's the exception rather than the rule.

    So you can take that Linux source code with their modifications, and design and build your own ADSL box or TV or whatever and use whatever improvements to Linux that they did. Or more relevantly, you can use their Linux improvements EVEN IF YOU DON'T make an ADSL box - you can do it on your desktop, or on some totally unrelated computer, and that's when the improvements become rally interesting - when you use them for something else than they were originally meant for.

    Now, of course, most Linux users in that space don't actually need to make all that many changes to the kernel, so there may not be any improvements. That's fair too. If Linux worked for them without modifications, then that's fine. Again, it will work for you without modifications if you want to do some similar hardware.

    So I always thought the whole "Tivoization" thing was silly thing. If you want to make your own Tivo, just do it. Don't think that just because it runs open source you should control the hardware. It's open source. If you want to make open hardware, make open hardware.

    Now, that said, I do think that there are serious problems in the content industry, where content providers are using laws and technical measures to basically try to lock people in and create more of a monopoly situation. I don't like DRM. But I think that's a different issue from the software license, and I also think that it was seriously wrong of the FSF to try to use the GPLv3 as a way to make other peoples software projects into weapons in their fight against DRM. And I'm very happy that I had made it clear that Linux was a GPLv2-only project many years before that all happened.

    LinuxFR : What is your opinion about Android ? Are you mostly happy they made cellphones very usable or sad because it's really a kernel fork ?

    Linus Torvalds : I think forks are good things, they don't make me sad. A lot of Linux development has come out of forks, and it's the only way to keep developers honest - the threat that somebody else can do a better job and satisfy the market better by being different. The whole point of open source to me is really the very real ability to fork (but also the ability for all sides to then merge the forked content back, if it turns out that the fork was doing the right things!)

    So I think the android fork forced the mainline developers to seriously look at some of the issues that android had. I think we've solved them in mainline, and I hope (and do think) that android will eventually end up merging to mainline. But it will probably take time and further effort.

    I think the more serious long-term issue we have in the kernel is the wild and crazy embedded platform code (and mostly ARM - not because ARM is in any way fundamentally crazier, but because ARM is clearly the most successful embedded platform by far). The embedded world has always tended to eschew standardized platforms: they've been resource constrained etc, so they've done very tailored chip and board solutions, and felt that they couldn't afford a lot of platform abstraction.

    That causes a big maintenance headache, because then all those crazy platforms look slightly different to the kernel, and we have all that silly code just to support all those variations of what is really just the same thing deep down, just differently hooked up and with often arbitrary small differences.

    But that's something that happens both within and outside of Android, it's in no way android-specific.

    LinuxFR : What about the technical differences between Android and mainline ? Do you think the "wakelock" controversy is solvable ?

    Linus Torvalds : I think it is technically largely solved (ie "details to be fixed, but nothing fundamentally scary"), but practically once you have an interface and existing code, it just is a fair amount of work to change. And there perhaps isn't quite enough motivation to make those changes very quickly. So it will take time, and probably several releases (both mainline and adroid) to actually happen.

    LinuxFR : Windows 8 will run on ARM. Is this a real threat to Linux dominance on embedded market?

    Linus Torvalds : It's not how I think, or care. Linux competes with itself, not with Windows. IOW, at least as far as I'm concerned, the thing I want to make sure is that Linux just improves.

    If anything, I suspect that in order to support ARM, MS will end up forcing some platform standardization on the ARM setups they support, and will make our job easier. I won't mind that at all.

    LinuxFR : Can you explain why you're not happy with the ARM patches sent to you during merge windows ? Is there an obvious solution for this fragmentation problem ?

    Linus Torvalds : Obvious solution? No. The problem is the wild variety of hardware, and then in many cases the Linux ARM platform code (not the ARM CPU support, but the support for certain chips with all the glue issues around the CPU core) has been mostly ugly "copy-and-paste" from some previous ARM platform support file, with some minimal editing to make it match the new one.

    And it just results in this unmaintainable mess. It becomes painful when somebody then fixes some core infrastructure, and you end up with a hundred different ARM files all using that infrastructure. That happened with the IRQ chip driver cleanups Thomas did recently (well, has been doing over along time, the recent part is really just the final removal of some nasty old interfaces).

    It results in other maintainability issues too - patches being big just means that people won't look at them as carefully etc etc. So it's just a bad situation. Many of the cases should be solvable by having better generic solutions and then plugging in just some per-platform numbers for those solutions.

    LinuxFR : What is your opinion about microkernels ? Do you still think it's a technical failure ?

    Linus Torvalds : Yes, I'm still convinced that it's one of those ideas that sounds nice on paper, but ends up being a failure in practice, because in real life the real complexity is in the interactions, not in the individual modules.

    And microkernels strive to make the modules more independent, making the interactions more indirect and complicated. The separation essentially ends up also cutting a lot of obvious and direct communication channels.

    LinuxFR : What about managed OS like Singularity ? Is it research only or do you think it can work ?

    Linus Torvalds : I'm a rather harsh and pragmatic person. Right now it looks like research only. The devil really is in the details, and a lot of these nice theoretical frameworks talk about the big issues, but not about all the details that you hit when you have all those crazy users that do odd (and wonderful) things.

    And the thing is, I really don't see the point. Operating systems aren't that complicated. There's nothing wrong with the UNIX model. Sure, we have a lot of code, and I'm not claiming it's simple code, but it's quite manageable. The biggest problems we tend to have in Linux is driver and platform support - not things that are fixed with some new programming model. Microkernels or managed code? They really solve none of the big problems I see.

    LinuxFR : Imagine we're in 2031 and the Linux kernel is now forty years old. Are you still the project leader ? Do you think the kernel is more or less the same than in 2011 or do you think there are new radical innovations included ?
    /troll mode: Was it rewritten in C++ ?

    Linus Torvalds : I really really hope that by 2031, we'll have moved past the OS as a place for radical ideas. Sure, it will run some OS, and I hope it will be Linux, but all the radical and interesting work had better be done in user space and in giving us more exciting interfaces to the computing power.

    So I personally do think that the kernel approach will still be valid and that the changes will be at a different level.

    After all, we've had forty years of Unix, and that whole "monolithic kernel in C" hasn't become invalid in those forty years. Sure, the details have changed, the language has evolved, and we have way more complex interfaces, but the basic design is still quite recognizable. And I don't think another 20 years will necessarily change that at all.

    LinuxFR : Thanks a lot for your answers...and happy birthday for the kernel :-)