By Jonathan Corbet
June 2, 2011
Linus Torvalds rather famously does not like speaking in public, so his
conference appearances tend to be relatively rare and unscripted. At
LinuxCon Japan, Linus took the stage for a question-and-answer session led
by Greg Kroah-Hartman. The result was a wide-ranging discussion covering
many issues of interest to the kernel development and user communities.
3.0
The opening topic was somewhat predictable: what was the reasoning behind
the switch to 3.0 for the next kernel release? The problem, said Linus,
was too many numbers which were getting too big. A mainline kernel release
would have a 2.6.x number, which would become 2.6.x.y once Greg put out a
stable release. Once distributors add their build number, the result is an
awkward five-number string. Even so, we have been using that numbering
scheme for about eight years; at this point, the "2.6" part of a kernel
version number is pretty meaningless.
Once upon a time, Linus said, making a change in the major number would be
an acknowledgment of some sort of major milestone. The 1.0 kernel was the
first to have networking, 1.2 added support for non-x86 architectures, 2.0
added "kind of working" SMP support, and so on. We used to think that
incrementing the major version number required this kind of major new
feature, but, in the 2.6.x time frame, we have stopped doing feature-based
releases. The current development process works wonderfully, but it has
caused the 2.6.x numbering scheme to stick around indefinitely. As we
approach the 20th anniversary of the Linux kernel, we had a good
opportunity to say "enough," so that is what Linus did.
"3.x" will not stay around forever - or even until the kernel is 30 years
old; Linus said he expects to move on around 3.20 or so.
Linus noted that some people were thinking that 3.0 meant it was time to
start with big new features (or removal of old code), but that's not what
is meant to happen. It is just a number change, no more. Trying to have
the kernel be stable all the time has, he said, worked very well; that is
not going to change.
Greg was clearly happy with this change; he presented Linus with the bottle
of whiskey he had promised as a token of his appreciation. After debating
opening it on the spot (Greg brought paper cups too, just in case), they
decided it might be best to finish the discussion first.
Greg asked: what recent changes did he like the most? Linus responded that
he tends to like the boring features, things that people don't notice.
Performance improvements, for example; he called out the dcache scalability work as one example. There
is no new interface for users, it just makes the same old stuff go faster.
Features and bloat
Is the kernel, as Linus famously said on a 2009 panel, bloated? Linus
acknowledged that it is still pretty big; it couldn't possibly run on the
machine that he was using to develop it 20 years ago. But even phones are
far more powerful than that old machine now, so nobody really cares. The kernel
has been growing, but that growth is generally necessary to meet the needs
of current hardware and users.
What about the addition of features just for the heck of it - new stuff
that is not strictly driven by new hardware? Is that something that we can
still do? Linus said that there are certainly developers working on
features with no current users, thinking five years or so into the future.
Sometimes that work succeeds, sometimes we end up with code that we regret
adding. Linus said that he is increasingly insisting on evidence that real
users of a feature exist before he is willing to merge that feature.
Greg asked about control groups, noting that a lot of kernel developers
really object to them. Linus responded that control groups were a feature
that did not initially have a whole lot of users, but they do now. Control
groups were initially added for certain specific server setups; few others
had any interest in them. Developers were unhappy because control
groups complicate the core infrastructure. But control groups have begun
to find a lot of users outside of the original target audience; they are,
in the end, a successful feature.
Symmetric multiprocessing (SMP) was also, at the beginning, a feature with
few users; it was a "big iron" feature. Now we see SMP support used across
the board, even in phones. That illustrates, Linus said, one of the core
strengths of Linux: we use the same kernel across a wide range of
platforms. Nobody else, he said, does things that way; they tend to have
different small-system and large-system kernels - iOS and Mac OS, for
example. Linux has never done that; as a result, for example, there has
never been a distinct cut-down kernel for embedded systems. Since the full
kernel
is available even at that level, Linux has been a real success in the
embedded world.
Embedded systems, world domination, and the next 20 years
Continuing with the topic of embedded systems, Greg asked about the current
furor over the state of the ARM tree. Linus responded that developers in
that area have been a bit insular, solving their own problems and nothing
more. That has resulted in a bit of a mess, but he is happy with how
things are working out now. As a result of pushback from Linus and others,
the ARM community is beginning to react; the 3.0 kernel, Linus thinks, will
be the first in history where the ARM subtree actually shrinks. The
embedded world has a history of just thinking about whatever small platform
it's working on at the moment and not thinking about the larger ecosystem,
but that is changing; this community is growing up.
Many years ago, Greg said, Linus had talked about the goal of "total
world domination" and how more applications were the key to getting there.
Is that still true? Linus responded that it's less true than it used to
be. We now have the applications to a large degree. He also no longer
jokes about world domination; it was only funny when it was obviously meant
in jest.
At this point, Linus said, we are doing really well everywhere except on
the traditional desktop. That is kind of ironic, since the desktop is what
Linus started the whole thing for in the first place - he wanted to run it
on his own desktop system. We have most of what we should need at this
point, including a lot of applications, but the desktop is simply a hard
market to get into. It's hard to get people to change their habits. That
said, we'll get there someday.
Can we do anything in the kernel to further that goal? Linus responded
that he'd been thinking about that question, but he didn't really know. A
lot of work has been done to get the kernel to support the desktop use
case; kernel developers, after all, tend to use Linux as their desktop, so
they are well aware of how well it works. But it's up to the distributors
to target that market and create a complete product.
Greg noted that 20 years is a long time to be working on one project; has
Linus ever thought about moving on? Linus responded that he really likes
concentrating on one thing; he is not a multi-tasker. He's really happy to
have one thing that he is doing well; that said, he never had expected to
be doing it for this long. When asked if he would continue for another 20
years, Linus said that he'd be fairly old by then. Someday somebody young
and energetic will show up and prove that he's really good at this work.
That will be Linus's cue to step aside: when somebody better comes along.
What do we need to do to keep the kernel relevant? Linus said that
relevance is just not a problem; the Unix architecture is now 40 years old,
and it is just as relevant today as ever. Another 20 years will not make a
big difference. But we will continue to evolve; he never wants to see the
kernel go into a maintenance mode where we no longer make significant
changes.
Moments, challenges, and licenses
A member of the audience asked Linus to describe his single most memorable
moment from the last 20 years. Linus responded that he didn't really have
one; the kernel is the result of lots of small ideas contributed by lots of
people over a long time. There has been no big "ah ha!" moment. He went
on to describe a pet peeve of his with regard to the technology industry:
there is a great deal of talk about "innovation" and "vision." People want
to hear about the one big idea that changes the world, but that's not how
the world works. It's not about visionary ideas; it's about lots of good
ideas which do not seem world-changing at the time, but which turn out to be
great after lots of sweat and work have been applied.
He did acknowledge that there have been some interesting moments, though,
going back to nearly 20 years ago when Linux went from a personal project
to something where he no longer knew all of the people who were involved in
it. At that point, he realized, Linux wasn't just his toy anymore. There
have been exciting developments; the day Oracle announced that it would
support Linux was one of those. But what it really comes down to is
persistence and hard work by thousands of people.
Another person asked whether the increasing success of web applications
would mean the end of Linux. Linus responded that the move toward the
browser has, instead, been helpful to Linux. There used to be a whole lot
of specialized, Windows-only applications for tasks like dealing with
banks; those are now all gone. When applications run in the browser, the
details of the underlying operating system don't matter, at which point it
comes down to technology, licensing, and price - all of which are areas in
which Linux excels.
The next question was: are you happy with Ubuntu? Linus suggested that
Greg should answer that question for a more amusing result. He went on to
say that Ubuntu is taking a different approach and is getting some
interesting results. It is helpful to have a distributor working with a
less technical, more user-centric approach. Ubuntu has been successful
with that approach, showing the other distributors a part of the market
that they were missing. Greg added that his main concern is that he wants
to see the kernel community grow. Things are, Greg said, getting better.
What is the toughest technical problem that Linus has ever had to deal
with? Linus answered that the biggest problems he faces are not
technical. In the end, we can solve technical issues; we make bad
decisions sometimes, but, over time, those can be fixed. When we have
serious problems, they are usually in the area of documentation and help
from hardware manufacturers. Some manufacturers not only refuse to help us
support their hardware; they actively try to make support hard. That,
Linus said, irritates him, but that problem is slowly going away.
What is really hard, though, is the problem of mixing the agendas of
thousands of developers and hundreds of companies. That leads to
occasional big disagreements over features and which code to merge. If
Linus loses sleep, it tends to be over people and politics, not technical
issues; the interactions between people can sometimes frustrate him. We
usually solve these problems too, but the solution can involve bad blood
for months at a time.
The linux-kernel mailing list, Linus said, is somewhat famous for its
outspoken nature; it is seen as a barrier to participation sometimes. But
it's important to be able to clear the air; people have to be able to be
honest and let others know what they are thinking. If you try to be subtle
on the net, people don't get it; that can lead to developers putting years
of work into features that others simply hate. In the long run, Linus
said, it can be much healthier to say "hell no" at the outset and be sure
that people understand. Of course, that only works if we can then admit it
when it turns out that we were wrong.
The final question was about the GPL: is he still happy with the license?
Linus said that, indeed, he is still very happy with GPLv2. He had started
with a license of his own creation which prohibited commercial use; it took
very little time at all before it became clear that it was making life hard
for distributors and others. So he has always been happy with the switch
to the GPL which, he said, is a fair and successful license. He feels no
need to extend it (or move to GPLv3); the license, he said, has clearly
worked well. Why change it?
[Your editor would like to thank the Linux Foundation for assisting with
his travel to Japan.]
(
Log in to post comments)