Slashdot Log In
Interview: Alan Cox Answers
from the center-of-the-kernel-universe dept.
Phil-14 asks:
Do you think that non-x86 versions of Linux will forever remain on the periphery, or will Linux actually become a
force for platform independence?
Alan Answers:
The focus of developers is always going to reflect the hardware people have.
As non x86 machines become more prevalent the importance of the kernel port
will do so. PowerPC for example has gone from being a fringe BeBox project
to a major platform.
Embedded systems and palmtops are likely to increase the amount of non-x86 linux platforms. The price squeeze is also going to take its tool - there are simpler cheaper processors and in the end that pricing will begin to count big time.
Intel clearly see IA64 eventually replacing x86. It may be in time that the x86 port is viewed in the same way as the 680x0 port. It may also be that IA64 is a turkey, we all run AMD K7's and x86 lives on. Its a guessing game.
asad asks:
Do you see yourself still working on Linux 5 years from
now? What about other people on the Kernel mailing list? And
do you think the quality of the code people now write for
Linux is still up to the standards of the old days ?
Alan Answers:
I have no idea what I will be doing in five years. Somehow I suspect it will
involve Linux and Red Hat a great deal.
The code standards haven't changed much. Linus is very keen on having clean modular and maintainable code. We have ugly code in there, but its mostly in specific drivers and quite frequently coping with ugly hardware.
Linus is picky, but Linus always was picky. Linux is as good as it is because he is prepared to be a right pain about doing things properly.
aheitner asks:
Okay, there's not a Linux hacker on the face of the planet
who wouldn't kill to have your job.
- - Paid by RHADL.
- - Wake up when you want, work when you want.
- - Go to all the big trade shows.
- - Work with the likes of Linus and all the other regulars.
- - Get free toys (and I mean good toys) like PA-RISC systems from HP and Athlons from AMD.
Alan Answers:
I'm actually paid by the support side of Red Hat not RHAD labs. That
might sound strange but if you are selling high end support to people they
want to know you have someone to fix the really bizarre, and you also
need people who can. So in many ways I'm in support.
I did it because it was fun. I'd been doing other free(ish) software stuff like AberMUD before that. I got into Linux to have a better development platform for AberMUD then got side tracked somewhat into hacking the OS.
As for the toys. New toys are fun whether they are expensive or not. The important thing is new. So I had lots of cheaper strange devices I was hacking on before - like the Macintosh 68K port, and Linux 8086.
The advantage of working for Red Hat is much more time than money: So many toys so few hours.
Techno_Jesus asks:
I'm always concerned with redundancy and I think the linux
kernel development could benifit from it the same way our
servers can. If something were to happen to Linus (albeit
very tragic) would you or someone else be able to take the
weight that he bears for the kernel development process? I
fear that the community is putting all it's eggs in one
basket and perhaps you are the only viable replacement.
Alan Answers:
It used to be "what happens if Linus gets hit by a bus" now its
"What happens if Linus and Alan both get hit by busses". I guess someone
like DaveM would take over (yes next years question is "What happens if
Linus, Alan and DaveM get ...")
Kindjal asks:
How is the whole linux-on-sgi thing going? You were
originally the guy behind that....what's your opinion on the
sgi embracing linux stuff happening now?
Alan Answers:
I was hardly the guy behind it. Dave Miller did the original ground work while
at SGI. Ralf Baechle did a lot of the other work along with Miguel de Icaza.
Almost all the work I did was on fixing up userspace packages and building
install and bootstrap tools.
The SGI I had is now in the hands of some other people who are still working on it. There is a lot of work within SGI on the new x86 machines and some work on the mips boxes. Check out oss.sgi.com
Amphigory asks:
I notice here that you were involved in the creation of
the nano-x project at some point. What is your opinion on
the continued viability of X-Windows? Should the open source
community be focusing on developing something better, or is
X the best we can hope for?
Alan Answers:
Ben Pfaff wrote a library for Debian called Bogl that did basic drawing but
was very compact - ideal for non X boot disks. I had a copy of an old Minix
library called mini-X and I stuck them together. Alex Holden and others then
decided to actually clean it up and make it work usefully.
Its good enough to play minesweeper and probably doesn't need much work to be able to use it as say a Mozilla front end or to port gdk (and thus gtk/gnoem) to it.
For most things X11 is far superior. X is bad at some things - notably code size and handling fast 3D games. These are all getting fixed. X is a very flexible framework and there is little wrong with X itself as a system. XFree 4.0 should do a lot to polish up the implementation. Its rarely a good idea to throw out 15+ years of work because it has a few glitches. X is probably relevant to everything but small PDA devices or set top boxes. My interest in Nanogui is with the Psion5/Geofox Linux port where you have very tight storage constraints.
Borg[9 of 9] asks:
Alan, with the upcoming 2.4 kernel is there any work
being done to address Linux tcpip performance issues? Is
there any plans on making the IP stack multi-threaded and
what about the stack spin lock issues on SMP machines?
Alan Answers:
DaveM, Alexey Kuznetsov and others have been working on this very hard. It is
one reason the 2.3.x tcp/ip is currently a little wobbly. It is however all
happening.
John Fulmer asks:
I'm a network security person and have always been
intrigued by the concept of the 'hardened' BSD kernel (which
isn't really THAT hard), and some of the role-based and
compartmentalized systems out there.
What is the status of the security of Linux' overflows and root hacks) and what do you see as the overall direction, if any, of Linux's security beyond the standard UNIX security model?
Alan Answers:
Ok Linux 2.0 is absolutely traditional. Later 2.0 adds securelevel which gives
a little more security at a usability price. Linux 2.2 uses capability sets so
you can give processes finer grained rights. You can also revoke rights for all
processes which can be useful in higher security environments.
There are people playing with role based models on Linux, although not in the mainstream kernel tree. There are also projects like Stackguard designed to catch buffer overflow attacks. Ultimately the only real way to improve security is careful auditing of packages. On the whole this works. Almost no packages that have been audited have future security holes logged against them. The Linux security audit project is the place to get involved with this. Anyone want to audit the perl interpreter ?
emil asks:
While I realize that you might not be completely
objective about this question, what do you think of the
design of the HURD, as it compares to Linux?
I once asked Linus himself this question and he replied in rather annoyed tones that "the HURD is a great academic design that would never work in practice" (or something along those lines).
Richard Stallman has been steadfast in refusing to endorse Linux as the GNU kernel. Does he raise these objections merely for emotional reasons, or does he see the HURD as having real technical advantages to the current monolithic design?
Alan Answers:
HURD is a great concept. Like most great concepts it isnt
efficiently implementable I suspect. Hurd is a GNU vision and every
project needs some lofty probably unachievable goal.
The HURD design is more about Richard Stallman's ideas about how a system should work to promote community than about high perfomance OS design. Linux is a bit more pragmatic about things. We took ideas from the microkernel world (like loadable device drivers) but we didn't take the accompanying partitioning and performance loss.
HURD is a rich flexible environment where the user has a lot of power to say "no I don't like that, I'll write my own code and use it" - even for things like filesystems. Right now HURD is a research project. Maybe one day it will become a useful OS.
Tekmage asks:
How has the multicultural and multilingual participation
affected the development of Linux as a whole?
Have you begun to see evidence of third-world participation effecting the progress of Linux yet, or is it still in the "hope to see soon" category? What needs to be done/changed to assist in the cross-cultural adoption of Linux? (Unicode?)
When can we expect to see a Linux Universal Translator Engine? :-)
Alan Answers:
We have uf8 unicode support in the kernel for stuff like the console and file
names. We have Japanese X11 fonts. Gnome and KDE have a lot of translations
although mostly to left to right rendered Western european languages. Its
a start.
What do you call third world ? Really its a gradation, and also a lot of it is based on perception. I get code and patches from countries as culturally varied as India, and Iran. There is a noticable amount of activity in Brazil, both with the kernel and other packages. The real third world countries don't really yet have the infrastructure to support the Linux development model. Linux helps to give them the tools to create that infrastructure and I am sure in time it will come when I get kernel patches from these countries too.
Developing countries are also in a good position to benefit from the opening of the market. It doesn't matter where I am on the globe providing I have part time connectivity, electricity and computers I can do Linux development work for companies anywhere in the world - this is one of the other great things about my job. If I wanted to move country there are almost no logistical barriers to doing that and continuing to work for Red Hat.
Actually promoting cross cultural adoption of Linux is hard. It has to come from people in those countries. Maybe I can get away with putting together a French language Linux distribution in the UK, but to put together a good distribution for any significantly different culture I think you need to be part of it. I expect a lot of the growth in support for other languages, and cultural needs to come directly from people hacking the code in the countries that need it.
Linux development isnt centralised in Redmond so you can go out and do this. Most of the time we can communicate world wide. Not always. Its really hard sometimes to follow Japanese Linux projects in Europe and the USA. I guess the reverse is probably true.
Next week's interview: Tim O'Reilly
Re:No, it's "perq". (Score:3)
You mean "yanqs" of course...
Grow up. (Score:3)
It seems like the corporate closed-source model has several flaws, the most aggregious of which is.. no source code access!
A) I've seen the source for MFC (it's distributed with their compiler) and you don't want to look at it, believe me
B) IMHO the most egregious fault of the Free Software movement is an inability to spell. I'd still rather deal with that than MFC, of course.
There are thousands of open-source projects, some as small as a few lines of code. Who are WE? doesn't the we that is YOU work for M$?
The "we" that he's referring to is "we software developers". That's abundantly clear in his post. Yessiree Bob, them fiends -- fiends, I tell you! -- who code at MS are programmers too, much like the heavenly angels in the free software camp.
I'm going to assume that you're claming that closed-source corporate software DOES have this,
You can assume anything you like, but the point of his entire post was that MS does not have that. Here's his second sentence, which seems to have escaped your comprehension (even though you quoted it):
It seems that the corporate and open-source development models have at least one flaw in common: insufficient documentation.
Get it? I think your second "aggregious [sic]" flaw is an inability to understand simple declarative sentences in the English language.
please, don't give me any line of shit about corporate $oftware being better than OSS. It's bullshit.
He said nothing of the kind. He's developed some software and he's seen how the process works, and now he's offering some thoughts about how the process might be improved. In his opinion, his thoughts on the subject apply equally to both open and closed development. IMHO he's right, too, even though he's not suggesting anything terribly revolutionary. IIRC Knuth has been on a similar kick for years. If he did anything wrong, he may have been assuming his audence consisted of programmers. Of course there are a lot of them around Slashdot, but there are also a lot of dingbats like you.
A minor gripe... (Score:3)
Ok, I'm as sick and tired of everyone complaining about moderation, censorship, and those sorts of things as anyone else. But the system plain doesn't work unless people honestly and fairly moderate things. I guess I'll just e-mail Alan directly to ask him the question.
Of course, now it's up to 5 again - after the questions had been sent to Alan. gah.
Actually, in the off chance Alan's reading this article: Alan, how much of your software development is done because of a contract, and how much just for the fun of hacking?
What happens if Linus gets hit by a meteor (Score:3)
Docs *ARE* useful (Score:3)
For one, stating the design and then implementing it has been shown to increase code quality. More importantly, it means you know what the code *should* be doing. This makes "Is this a bug?" questions much easier to solve. I've noticed a lot of patches on the linux-kernel list arise from misunderstandings due to unclear code.
Then there is the generally accepted fact that programmers of all skill levels sometimes forget things. How many here have gone back to their own code they wrote six months ago, and said to themselves, "What does this do?" I know some kernel hackers have -- that same phrase shows up in the Linux kernel source!
Linux is contributed to by tens, if not hundreds, of developers. Not *all* of them are going to be Seventh Level Hackers like Linus and Alan. For someone who is, say, just tring to implement an input device driver, it would be nice if some of the magic_kernel_functions() were explained a little clearer.
I'm not saying every function should be documented complete with purpose, arguments, return value, pre- and post-conditions. If someone wants to do that, more power to them, but I'm not saying It Must Be.
However, some things could be added, to positive effect: Top-of-file comments explaining what is contained in a file. Brief comments explaining which a function is supposed to do. A guide to where key kernel structures, macros, etc., come from.
A lot of this stuff was laid out very well in the Kernel Hacker's Guide and similar documents, but they have fallen far out of date. Documention for the 2.2 and 2.3 series kernels is very lacking.
I would try my hand at doing some of this, but frankly, I don't understand much of the kernel myself. I've been reading source lately trying to figure some stuff out, but with almost *SIXTY MEGABYTES* of kernel source, that is a lot of reading!
Just my 1/4 of a byte.
If only docs were adequate... (Score:3)
No, it's "perq". (Score:4)
Of course, you yanks have a way of bastardizing the spelling of words, so it may well be "perk" in the US, but that's not where Alan is, is it?
(And the piece of paper you sign authorizing the back to give somebody your money is a cheque. A check is a pattern of alternate colo[u]r squares.)
Re:Death By Misadventure (Score:4)
(I know -- this joke is so old it collects a pension now. I couldn't resist.)
Grand Bus Conspiracy (Score:5)
Reading this, a strange image comes to mind....
"Thank you for coming, gentlemen..."
"Cut the crap, Bill. Why did you want us here?"
The speaker glares. "No names", he replies. "As for why I called us togeather... I understand this is highly irregular. Normally we would be attempting to tear each other apart in the marketplace. And I know that means there's no love lost towards me. However, today we are seeing a bigger enemy. All our business is dependant on proprietary technology. Today, the threat to our business models is not each other... it's open source."
There is a wave of grumblings and grudging agreements. One speaker blurts out "OK... sure... but what do we do? Many of our numbers are attempting to embrace it to survive..."
The speaker frowns. "You'll notice THEY aren't here. No... there is another solution. Destroy open source. Destroy its poster child: Linux."
More grumbling. The speaker grins.
"Obviously you think I'm insane. Gentelmen, I'm not. We have a solution. Cut off the head, and the snake dies. You'll note that a year or two ago... if a bus had hit Linus Torvalds... it may have stopped this menace before it surfaced. Now it would take two, possibly three bus incidents. Gentlemen, we must act now! The plan is simple... at the next big Linux convention, we pool our collective resources togeather and charter lots and lots of busses...."
The plot thickens. And I swear to cut down on Penguin mints...