- By Grant Gross -
Alan Cox is not only a long-time Linux kernel contributor and maintainer, he also isn't afraid to make waves once in awhile. While Linux kernel creator Linus Torvalds usually stays above the fray of the politics of Open Source and related topics, the U.K.-based Cox, sometimes referred to as Torvalds' second in command, isn't afraid to weigh in on several topics, including his opposition to the U.S. Digital Millennium Copyright Act.
Last week, Cox announced that he's passing the maintenance of the 2.4 kernel onto another member of the kernel team. We thought it was a good time to check in with him, and ask him what's next on his plate. (Links added by NewsForge, not Cox.)
NewsForge: You announced recently that you'll be passing on the maintenance of the 2.4 kernel to Marcelo Tosatti, but it sounds like you'll continue to be involved in kernel development and in other Linux issues. What are your plans in the coming months?
Cox: I have a list of things I want to get done in 2.5, most of which consist of
removing old ugly code. There is some device driver stuff I want to work on,
and there are a whole collection of userspace things I want to play with
somewhat more -- especially configuration tools and usability. There is basic
stuff that bugs me and I don't have to fix right now -- like PPP
configuration tools not bothering to say, "You have no firewall configured
would you like to run the firewall configuration tool."
NewsForge: You said you'd like to spend more time working on Red Hat customer needs. What's your role at Red Hat and how do you interact with customers?
Cox: Primarily I work on the kernel and kernel related projects but I'm also
there to ensure that we can deliver our enterprise customers an extremely
high level of support in deploying Linux, in customising Linux and very
importantly in supporting them by getting problems fixed fast.
NewsForge: You recently announced that you wouldn't detail Linux kernel security fixes because of the U.S. Digital Millennium Copyright Act. Concerns raised about your choice seem to be along the vein of, "How can the DMCA be used against you with your own code?" You answered that Linux's standard security features may be used for "rights management" of copyrighted work. Can you explain your view further without running afoul of the DMCA yourself?
Cox: The DMCA makes no distinctions about intent, ownership or even permission. Those are perhaps the biggest problems it has in the general case.
File permissions are rights management. The DMCA makes it very difficult to
discuss anything that might compromise "rights management," even if all you
did was show that the products people were using are dangerously insecure.
Right now, for example, it's not clear that someone finding a rights management
systems used by a friendly company was flawed without being prosecuted.
The advice given was pretty simple -- chances of being arrested non-zero; chance of being convicted by a sane U.S. court -- nil. However, spending six
months trapped in the U.S.A. does not appeal to me.
NewsForge: In July, you called for a boycott of U.S. technology conferences, including the Annual Linux Showcase happening this week, because of the DMCA and the U.S. FBI's use of it to prosecute Russian programmer Dmitry Sklyarov. What's the status of that boycott?
Cox: It stands. I'm far from alone in the boycott. Some conferences --
particularly security vulnerability ones have relocated outside of the U.S.A.
fearing persecution. I'm hopeful that the Felten case will settle the issue
and bury that problem for good. [In the case, a Princeton professor's team was threatened with DMCA prosecution for presenting research on a music industry anti-copying technology. Edward Felten is now suing the recording industry and the government over those threats.] It's just unfortunate that the politicians don't seem to think that making sure a law is constitutional is part of their duty. Sadly that isn't a U.S.-specific disease. I've recently joined the FIPR [Foundation for Information Policy Research] advisory council to help make sure our politicians don't do unfortunate
things due to lack of knowledge of the IT field.
NewsForge: We read that you and Linus have resolved a virtual memory disagreement you've had. Are you happy with the new code?
Cox: As of 2.4.14, it is looking good. It looks like that will be the first 2.4
kernel (well plus a small fix or two) that passes the Red Hat QA test sets
without serious adulteration. That can only be a good thing.
NewsForge: You're quoted in an eWeek story saying that the biggest disagreement remaining is over dynamic device naming in 2.5. Can you explain that issue to people who don't
follow the kernel development team that closely?
Cox: Computer systems get a lot more dynamic in configuration -- you can now hot-swap many devices without expensive bangs and smoke. One of the problems
that causes is that historically Unix was tied around a static naming and
structure. Your /home didn't wander around for example.
One of the big issues therefore is how you handle naming and finding objects
that can shuffle around over time and between boots. Linus favours a more
devfs like approach, I favour a real /dev file system and creating nodes on
the fly by a usermode daemon. This allows you to remember file permissions
and policy more easily. It also means you need a way to describe a device
(traditionally a major/minor numbering) which Linus doesn't like.
NewsForge: The last year or so has seen more corporations involved in Linux development, namely IBM. Are you happy with how companies like IBM have worked with the kernel team?
Cox: They vary. Some of it is corporate culture. A lot of Intel has been very
difficult to work with because they have an almost secret service-like need
-to-know basis for a lot of information. Over time both sides are learning
how to improve that but its still pretty rocky in places both from that and
also because there are Perl people with long memories who regard the
Randal Schwartz affair as still grounds for non-cooperation.
IBM has been a mixture. The S/390 people basically turned up with a complete
Linux coding style compliant and "Linuxthink" S/390 tree ready to merge.
That was quite an amazing achievement. Other bits of IBM turned up with
ugly Windows escapee code that took time to clean up. The PPC64 stuff is up
in the air but will get there.
Some of it has worked very well. I've had an Intel performance improvement,
improved further by Compaq and bugfixed by Dell, for example. Gradually these
big companies are figuring out how to make the system work while not
accidentally revealing future product directions that might be useful to
It has been good, and we have received a lot of very general improvements
from big companies that people overlook -- system 5 semaphore optimisations and
shmfs stuff from SAP, scsi pieces from HP and so on.
NewsForge: In general, what's next for the Linux kernel? What features/changes would you like to see in upcoming kernels?
Cox: I really want to see the Compaq clustering code, the IBM DLM and OpenGFS in the 2.5 tree creating a real clustered Linux with true failover
facilities. That will really open the door to the enterprise market.
NewsForge: Where do you see Linux in a couple of years? What's your vision for Linux in the near future?
Cox: Initially, still the server end of things and embedded systems. Over time,
however, I think Microsoft's expensive software creation methods and
spiraling price hikes will open the desktop up to competition. I think StarOffice will be important here and also InterMezzo. InterMezzo is the perfect basis for building an environment where there is "the company file system"
and it is scalable enough to deliver that.
Some of that depends on the states fixing the Microsoft "settlement." Unless they go beyond "can ship two operating systems" to "can ship non-Windows PCs without penalty" and also "can ship non-Windows OSes cheaper than they sell Windows" then it's going to be a slower and harder battle.