Author's note: Alan Cox needs little introduction--most will know him for his long-standing work on the Linux kernel (not to mention his appreciation and promulgation of the Welsh language among hackers). Cox is one of the keynote speakers at EuroOSCON this October, where he will talk about computer security.

According to Alan Cox, we're just at the beginning of a long journey into getting security right. Eager for directions and a glimpse of the future, O'Reilly Network interviewed him about his upcoming keynote.

Edd Dumbill: You're talking about the next 50 years of computer security at EuroOSCON. How would you sum up the current state of computer security?

Alan Cox: It is beginning to improve, but at the moment computer security is rather basic and mostly reactive. Systems fail absolutely rather than degrade. We are still in a world where an attack like the slammer worm combined with a PC BIOS eraser or disk locking tool could wipe out half the PCs exposed to the internet in a few hours. In a sense we are fortunate that most attackers want to control and use systems they attack rather than destroy them.

ED: Linux sysadmins see a security advisory and fix practically every day now. Is this sustainable, and does it harm Linux that this happens?

AC: It isn't sustainable and it isn't going to work forever. Times between bug discovery and exploits have dropped dramatically and better software tools will mean better and faster written exploits, as well as all the good things.

I think it harms Linux perhaps less than most systems because Linux security has been better than many rivals. However, even the best systems today are totally inadequate. Saying Linux is more secure than Windows isn't really addressing the bigger issue--neither is good enough.

ED: You say that we're only just at the beginning of getting computer security right. What are the most promising developments you see right now?

AC: There are several different things going on. Firstly, the once-stagnant world of verification tools has finally begun to take off and people have started to make usable code verification and analysis tools. This helps enormously in stopping mistakes getting into production.

Related to this, languages are changing and developing. Many take some jobs away from the programmer and make it harder or near impossible to make certain mistakes. Java for example has done a lot to make memory allocation bugs and many kinds of locking errors very hard to make.

The second shift has been towards defense in depth. No-execute flags in processors and software emulation of them, randomization of the location of objects in memory and SELinux help control, constrain and limit the damage an attacker can do. That does help. There have been several cases now where boxes with no-execute or with restrictive SELinux rulesets are immune to exploits that worked elsewhere.

SELinux also touches on the final area--the one component of the system you cannot verify, crash test, and debug: the user. Right now, systems rely on user education and reminding users "do not install free screen savers from websites" and the like. The truth is, however, that most users don't read messages from their IT staff, many don't understand them and most will be forgotten within a month. SELinux can be used to turn some of these into rigid policy, turning a virus outbreak into a helpdesk call of "the screen saver won't install."

This last area is very important. We know the theory of writing secure computer programs. We are close to knowing how to create provably secure computer systems (some would argue we can--e.g. EROS). The big hurdles left are writing usable, managable, provably secure systems, and the user.

It's important perhaps to point out here that secure programs, reliable programs and correct programs are all different things. Knowing how to write provably secure programs is very different from saying we know how to write reliable or correct programs.

ED: Can security in software development be meaningfully incorporated into tools, so it doesn't end up stifling the productivity of developers?

AC: The current evidence is yes. Many of the improvements actually increase programmer productivity by taking away tedious tasks like memory management, or identifying potential bugs at compile time and saving the programmer from chasing bugs for days, and because many of them use labeling techniques where you have to indicate when you mean to do unusual things--actually making code easier for other humans to analyze.

There is no evidence that sparse has slowed kernel development, tainting features have hindered Perl, or that Java memory management harmed most productivity.

The tools are doing by machinery what is hard to do by hand. Bad tools could slow people down, but good tools do not.

ED: Isn't there a fundamental level at which security concerns and the freedom of individuals to innovate are opposed? Is there an end in sight to open source software created by small numbers of people?

AC: There are areas where they come together--obvious ones are safety critical systems. It's just possible that you don't want nuclear power station employees innovating on site, for example.

There are 'security' systems such as 'trusted computing' that can be abused by large corporations to block innovation, and unfortunately the EU ministers seem to want to help them, not their citizens. Whether the EU commission is corrupt, incompetent, or just misguided is open to debate but the results are not pretty. We've seen that with the X-Box. Microsoft sells you a product and threaten to sue you for using it to its full.

Those same tools, however, are valuable to end users, providing they have control over them. The same cryptographic techology that will let Apple lock their OS to apple branded x86 computers is there for me to keep personal data secure if a future laptop is stolen. It is a tool, unfortunately a tool that can be easily abused.

To a homeowner a secure house is generally good. but if you lose control of the key, it can be a positive hindrance. TCPA is no different.

ED: Where is the ultimate driving force for implementing secure software going to come from? It seems that regulatory enforcement, such as in the pharmaceutical industry, might be the only way to properly protect the consumer.

AC: At the moment it is coming from the cost of cleaning up. Other incentives come from statutory duties with data protection, and also from bad publicity.

In the future they might also come from lawsuits--for example, if an incompetently run system harms another user--or from Government. In theory as we get better at security the expected standard rises and those who fail to keep up would become more and more exposed to negligence claims.

The bad case is that someone or some organization unleashes a large scale internet PC destroyer before we are ready and legislation gets rushed through in response. That will almost certainly be bad legislation.

Edd Dumbill is editor at large for O'Reilly Network and coauthor of Mono: A Developer's Notebook. He also writes free software for GNOME and packages Bluetooth-related software for the Debian GNU/Linux distribution. Edd has a weblog called Behind the Times.

ZDnet Printer Friendly - Interview with Alan Cox

Do you think this step is a threat to Linux?

No. There is a real difference between "you can have a quick look at some of our source code but you can't do anything with it, and you have to be a government and we have to like you". In addition to which, just having the source code isn’t really that useful because unless you have the code for compiler and you can rebuild all the code and verify it, how do you know the source code they have given you is anything to do with the actual operating system your running? And that is a very real question. One the other hand we've had military and government security people who've actually taken a basic Linux system including the compiler, they’ve audited that compiler and have built and audited every single single sub set pieces of Linux they use so they can definitively say that it doesn’t have any back doors in it. At least in their version of it and they are happy with it and any back doors they have put in themselves for their own use.

[Mar 3, 2005] The ups and downs of life with Linus Tech News on ZDNet Linux kernel maintainer Alan Cox has given an insight into the experience of working with Linus Torvalds, the founder of Linux who maintains its development kernel.

During a talk last weekend at the Free and Open source Software Developers European Meeting, FOSDEM, on the challenges of maintaining a stable Linux kernel, Cox revealed that although Linus is good at developing code, he does not enjoy some of the other jobs that go along with software development such as bug fixing and beta testing.

"Linus is a good developer, but is a terrible engineer," said Cox. "I'm sure he would agree with that."

Cox explained that he and Torvalds sometimes have different approaches to fixing a problem, due in part to their different responsibilities. As the maintainer of the development kernel Torvalds needs make sure the kernel code is easy to maintain, while Cox is more interested in kernel stability and is not so worried about "hacking" the code to get it to work.

"One of the hard problems to fix is design errors," said Cox. "These are a pain because they need a lot of refactoring. Linus' approach is to re-write it to a better design. But to get a stable kernel you tend to do small horrible fixes. Linus is very keen to have maintainable code, while to have a stable kernel I'm keen to have code that works."

Cox said that Torvalds does not always let people know when he has fixed a security bug in the kernel. This can be a problem as the patch will take a while to make it to production, which means that hackers can exploit the vulnerability before it is made available to individuals and enterprises running Linux.

"Linus has this bad habit of fixing security holes quietly," said Cox. "This is a bad idea as some people read all the kernel patches to find the security holes."

Linux enjoys a reputation as a particularly secure operating system, compared to rivals such as Microsoft's Windows. Last month a mailing list was set up to help Linux kernel developers share information on security flaws.

Deciding what bugs to fix in the Linux kernel is not always easy, particularly as fixing it can impact other applications. Cox said he gives top priority to bugs that are reported soon after the release candidate is made available.

"Release candidates will pick out a lot of the stupid bugs, and what are plain stupid ideas," said Cox. "Two or three days after the release candidate we will have 150 emails with same bugs." These early issues can be easy to fix as they are often obvious bugs. "Early problems you get are normally very easy to fix," said Cox. "As soon as the release comes out bug reports say 'You've broken this'. Almost immediately you go, 'Whoops, that's my mistake'. Ten minutes later the fix is in the development tree."

But kernel bugs that appear easy to fix can be misleading. "Sometimes you see a fix and think 'this is perfect, move my fix into the kernel tree'," said Cox. "Later you think, 'I must have been drunk. Don't apply that patch'."

[Jun 01, 2004] Alan Cox: An Open Letter On Software Patents and EU Election

Most of the time the ability to influence Politicians is remarkably limited. They ignore letters, and often all the major parties reflect only large proprietary interests, ensuring you get CD's that won't play in a car, arrested for helping the blind read protected ebooks and prevented from writing and using software by the patent lobby, intent on locking up technical creativity the same way the soviets locked up the typewriter.

In about a week you get an opportunity to send the EU politicians a message they cannot ignore - but sadly only 18% of UK citizens will bother to do so. While most British people would like to ignore the EU, the simple fact is that it is the EU that passed the EUCD, it is the EU that can fight software patents and it is the EU that is currently working to create even more draconian "intellectual property rights" laws.

This letter is aimed at the other 82% of hackers, open source enthusiasts, or just people who want the rights to use CD's they paid for fairly and honestly. That little piece of cardboard is your chance to call the EU to account, and thanks to the EU voting system you can make a difference, in fact you count five fold due to the expected low turnout.

There are two parties that are fundmanetally opposed to things like Software Patents.The Green-EFA alliance (Green Party, Plaid Cymru and friends) have been fighting the patent fight from the beginning including organising events in Brussels, as well as fighting to make the EU more democratic (to stop unelected Beaurocrats overturning the will of the parliament). The UKIP (UK Independance Party) is opposed on the ground that EU legislation like software patents clogs up British business and harms Britain as a sovereign nation. Unlike our parliamentary elections the EU voting system means it is not a two horse race.

To defeat software patents now needs an absolute majority in the parliament. That is going to be hard to achieve, but you get to adjust the make up of the parliament, and every vote is going to count.

Please, if you were not going to vote, either vote for the UKIP or Green-EFA alliance members. Ideally pick the one of the two that is most likely to win in your area, but if you have philosophical reasons for favouring one of the two (such as a dislike of the EU) please go vote for the one you favour. These are the people who will have to decide how to fix the EUCD, these are the people who will have to decide on Software Patents. Whether you believe in the EU or not, the people you vote for (or the pro patent, pro DRM people who will get in by default if you do not vote) will dictate your future rights.

The turnout in the UK is expected to be 18%. That favours anyone who can mobilize and get out and vote. It's a one off opportunity to kick the pro-patent lobby somewhere that hurts.

Vote, get your friends and families to vote, get LUGs to vote en-masse. Call out the troops - it's payback time...

Alan Cox

[Feb 22, 2005] Fosdem 2005 An interview conducted by FOSDEM & the LinuxFR readers

FOSDEM - What is your feedback about your sabbatical year ?

Alan Cox - I enjoyed the MBA a great deal. I've learned a lot of useful stuff that helps when tying computing into the real world. I'm still working on the thesis and need to go interview more folks using Linux on the desktop in business and/or planning to do so yet.

FOSDEM - Some security websites published unpatched security issues affecting the stable kernels. There is no highly critical remote hole right now, but how can we improve the way the security fixes are made?

Alan Cox - The obvious improvement is more tools so that they don't happen in the first place. I'm personally of the opinion that responsible security disclosure involves telling the developers first, and perhaps giving them 14 days to respond and resolve the problem. If you don't force a time then large vendors tend to take forever, if you release immediately then many people can be harmed before a fix exists.

FOSDEM - Should we, for example, name a security maintainer who would handle all the security advisories and bugfixes for stable kernels ?

Alan Cox - Definitely. We sort of have that for the vendor kernels but not officially for the base kernel. For 2.4 Marcelo is part of vendor-sec so he's both 2.4 maintainer and security guy. 2.6 is less clear.

It also has to be more than one person. It's no good if a serious hole occurs and the named security person is flying to Australia that day, or ill or whatever.

FOSDEM - You are working for a well-known Linux distribution. Does your employer impose you any sort of contraint or does he allow you some freedom?

Alan Cox - Red Hat primarily pays me to work on the kernel. I'm mostly trusted to use my own judgement on what that means, and guided by the hot issues customers see. There are things I get through Red Hat, such as vendor pre-production systems and documents that are restricted but nobody in Red Hat demands I run Red Hat products for example. Except for the little boxes (running Debian) I do run Red Hat Fedora but that's by choice.

FOSDEM - Linux is now developed by professionals, who are paid by companies having sales targets. Is this kind of development less fun? What is in your opinion the consequence of the fact linux is now more and more developed by professionals?

Alan Cox - Less fun for some, more for others. It's harder to do research type 'blue sky' projects with Linux in some ways but there are people who love total reliability, verification and quality and those kind of skills are becoming more and more demanded in the Linux world. Big Linux servers have to stay up and companies demand more and more stability and quality as a result.

The kernel itself definitely has changed, its much more "finished" now. There is no real feeling that there are big pieces of catching up to do. The desktop is perhaps today more like the kernel was a few years ago.

FOSDEM - Can GNU/Linux or *BSD take any advantage of the access to the source code of OpenSolaris?

Alan Cox - The licensing really prevents code sharing. We have multiply licensed code that we share with BSD so in theory third parties can usefully contribute code to all the systems. It may also be useful for driver/hardware information if there is actually anything Solaris drives that Linux does not.

FOSDEM - From your valuable insight and broad overview of the whole Linux kernel, what should be the 5 items which have to be addressed by the upcoming kernel releases (apart from hardware support which obviously cannot be addressed by the solely kernel team) ?

Alan Cox

Better performance on small machines

Virtualisation (Xen etc)

More security features

Resolving the X and kernel video muddle properly

World domination

FOSDEM - There has been a great improvement between the 2.4 and 2.6 kernel versions. A lot of developers have been hacking since the first release of the 2.6 kernel, but nothing has been carried out on a 2.7 version. What are your comments on this?

Alan Cox - I'm still watching this experiment with interest - it reflects the changes in the kernel from development to mostly finished. No conclusions as yet beyond the need for 2.6.x.y subreleases of fixes for each 2.6.x

FOSDEM - What do you expect from your FOSDEM talk?

Alan Cox - A lot of hard questions. FOSDEM seems to have a reputation for being a real developer conference so it should be a lot of fun. I hope the beer is good.

2004

[Oct 07, 2004] Alan Cox on writing better software - Ping Wales Welsh technology news By Basheera Khan

A large part of the software industry has never heard of the science of quality assurance - or if it has, it doesn't believe in it. Thus spake Alan Cox, Wales' most famous Red Hat employee and one of the most influential voices in the IT world. Currently wrapping up his MBA at Swansea University, it's clear that Cox has been spending a lot of time thinking about what the software world can learn from everyone else about quality.

Cox was speaking at the launch of an advanced technical computing group for Wales, run by IT Wales, part of Swansea University's computer science department. IT Wales' other activities include running events for SMEs in South and West Wales, and working to retain IT skills in Wales by matchmaking computer science graduates with Welsh businesses.

The advanced technical computing group aims to bring best practise to Welsh software engineers from organisations such as the British Computer Society, the Natural Computing Forum and the Welsh e-Science Centre. Activities kick off in January 2005.

Cox, a graduate of Swansea University, discussed a number of trends which are allowing developers to produce better quality software. While some of these trends relate specifically to the computing world, others are simply a case of that world putting into practice the kinds of techniques which have been seen as essential in traditional industry for some time.

Starting with the statement that "all software sucks", Cox compared software engineering to its counterpart on the hardware side of the equation, where the economic incentives for getting it right first time are indisputable; with hardware, a single error can cost millions.

Using microprocessor manufacturers as an example, Cox said, "They put over 100 million gates/transistors on a tiny piece of silicon. On that piece of silicon there are more lines than there are on a roadmap of London - and they work. There are very very few errors in a microprocessor."

When software doesn't work the way it should, it's easy and cheap to ship an upgrade or a patch to the users, who are then inclined to accept buggy software as the normal state of affairs, Cox said.

Even though there has been a movement for some time to introduce traditional engineering concepts such as quality assurance to software development, Cox sees today's software engineering as "the art of writing large bad programs rather than small bad programs".

Of the much-vaunted 'holy grail' of reusable objects, Cox said, "As far as I'm concerned these all generally suck too. Part of the problem is that they're sold as products and the original ideas behind a lot of reusable products is that you wrote it once. If you write it once, it has to do everything. If it does everything it's complicated, and if it's complicated, it's broken. That's not always the case but it is quite frequently the case."

As for QA, "Everybody in the real world will agree - the moment a project is behind deadline, quality assurance tends to go out the window. People go through the specification and everything marked 'optional' becomes 'version 2', and everything marked 'QA needed' becomes, 'we'll find out from the users if it works,'" Cox said.

Another factor that's led to the current state of affairs is that of canny software companies which shift bad software as quickly as possible, on the basis that once the end user has one piece of software for the job it becomes harder to switch to another one - in that context, Cox considers Microsoft's release of early versions of MS Windows as a very sound economic and business decision.

Compounding the situation even further is the incentive for businesses to deny all knowledge and point fingers when software errors are uncovered. If there are several parties responsible for the maintenance of a piece of software, he said, it's in everybody's interests that the other person fixes the bug because the customer will assume that whoever fixes the bug was responsible for it. Most businesses, particularly SMEs, don't have that luxury.

Gladly, it seems there are good reasons why this situation can't go on for much longer. One large incentive for improving matters is security. "We're looking at very large numbers of PCs being taken over every day, used as zombie machines, fed software which makes them dial the internet via Ghana, and in particular, something known as zero day holes. In other words, someone who's finding a security flaw and exploiting it before the rest of the world knows."

"The update side is becoming a problem. You take a WinXP machine, you plug it onto the internet, on average you have 20 minutes before it is infected with something, if it's not behind a firewall. That is considerably less time than you need just to download the updates. These are becoming economic issues, because they're starting to cost businesses all over the world astronomical amounts of money."

So, how does one make the world a better place by writing better software? For starters, Cox says, we need to accept that humans are fallible and that software engineers, no matter how well trained, will make large numbers of mistakes in their software - so we should start using the right tools to keep the error count as low as possible.

Here, then, are Alan Cox's hot tips and tools for writing better software...
Execute-only code: One of the classic ways of attacking a web server with a known security hole is to feed that server with a command that triggers the security hole, and which contains a piece of code that is run as a result. Cox cited recent developments in microprocessor design which allow execute-only and read-only areas of memory, which provides protection against such potential damage because, for instance, any data fed to trigger a security hole won't run if it's not in executable memory.

Firewalling by default: "Red Hat has been doing this for four years now, Microsoft is finally doing it, Apple has been reasonably intelligent about this for a long time as well. You don't leave your front door open just in case you need to walk in and out. It's much much safer to have your front door shut. So by having firewalling by default, it actually allows users to accept, there is probably insecure software on my computer system. It may have bugs in it. But if the rest of the world can't get at my software, I don't care - not too much."

Languages are very important, particularly when it comes to the issue of memory allocation.
"If computer programmers get the memory allocation wrong, why are we letting the computer programmers do the memory allocation? The computer can do this. The world has moved on since the design of languages like Fortran and C."

"So for other newer languages, we have garbage collection, we have sensible memory allocation, and this means we can take things away from the programmer, so that providing the language has done it right, the programmer cannot make that mistake anymore. And this works out incredibly effectively when you look at the kind of bugs you get in software. Even when just doing it by getting programming interfaces right, we see huge improvements."

"I looked at this for some of the Linux desktop code. And instead of using standard C functions for a lot of the memory handling for text, it has a library which doesn't allow the programmer to screw it up. If you look at the history of this kind of error, almost none of them occurred in desktop [environment] compared to a very large number that were found elsewhere in applications on Linux. So it tells us that using the right tools works."

Validation tools: "They used to be very expensive, they're getting a lot cheaper. So we know for example if a given function takes a lock, it should also get rid of the lock in all paths. So one of the cases where the error code forgets to do things, we catch."

Type safety: "Things like type safety are now taken for granted. When I was an undergraduate at Swansea University, we thought it was a novelty when the C compiler told you if you passed a floating value to a function instead of an integer."

Tainting: "The idea is that when you've got untrusted data, you actually tell the computer this data is untrusted, because then you can look through how the untrusted data is used, and what other data it creates. And you can look for cases where you're doing stuff with untrusted data that you shouldn't be - like relying on it. And so we catch human mistakes before we ship them to the consumer."

Rule verification: "If you have rules in your software, you know how certain bits of it should behave, you can start to use software in some cases to verify or to validate these rules."

Good interfaces: This is another surprisingly effective one. If you look at a lot of other businesses, if you're a car manufacturer and you find you've got a lot of faulty cars coming off the production line because someone's put a part in backwards, the first thing you do is make a new version of that part which has a knob on it or something so it won't fit backwards. That's the immediate reaction. So we've started to do this kind of thing in software. So we have things that are simple and hard to misuse."

"An example of this is, with locking, instead of having one function for taking a lock and another function for releasing the lock, which inevitably means that someone always has an error handling or an unusual case where they forget, you have a single function which calls another function locked; it takes the lock, calls the function, and drops the lock. All of a sudden it's another mistake you can't make because the computer won't let you, because fundamental to your language, fundamental to the way you're coding, is the idea that this lock must be released. And it turns out you can do a lot of these things in languages like C++ by being a bit clever."

Defensive interfaces: "Locks with corrupt flags is another example. One of the things the telco industry cares about is that systems stay up. So eventually your software crashes with somebody owning the lock - someone currently has the sole right to some critical data structure. And in this case what the telecoms people do with newer systems is that after a certain amount of time, the system has a watchdog, much like your video recorder does. If the video recorder or your DVD player crashes, it just reboots after a certain amount of time, as if nothing has happened. This is great until you've got locking, and you kill a particular part of your phone switch and it owns some critical part of the system."

"[With] defensive interfaces, I can now take a lock and I can be told, 'I'm giving you this lock, but be aware that something terrible happened to the last user of it' - which means that when you take this lock you can actually start to take defensive actions."

Mathematical models: "People have started to use mathematical models for things like defect rates. Turns out all the models exist - the large part of industry that actually makes physical objects has known about them for a considerable number of years. They tell you interesting things like when you should release software beta. Providing you've got a good estimate of the cost of finding faults yourself, and the quality of the fault finding relative to your beta testers, you can actually do the maths to tell you when you should be going into beta testing."

Scripted debugging: "Traditionally you think of your debugger as something that you use after your software has crashed. But a debugger turns out to be very useful in quality assurance, because you have a lot of things in your software which you can't easily inspect. You can actually use a debugger as part of your QA testing to go in at the end of the run and say, are all the internal values right? Does the software appear to have behaved as we expected on the inside as well as on the outside?"

Brute force testers: "These are beta testers, and users of dot-zero versions of software, of course. And tools like CrashMe, which is one of the ones we use for Linux. And there are application level equivalents of this. The basic idea is, generate random input, feed it to the application, keep doing this until the application breaks. It's surprisingly effective. In a recent study they did this with Windows application software, feeding random Windows events to it, so effectively it simply sat there at full computer speed continuously clicking randomly, closing and opening dialog boxes, picking menu items, and typing. And about half the Windows software they subjected to this particular torture, crashed."

Root cause analysis: "I've got a friend who works on aeroplanes, and he has the wonderful job of, when a piece of an aeroplane falls off, cracks, or something before it was supposed to, they go to him and say 'why did it happen?'. And it's then not a case of saying 'oh, this analysis is wrong', it's saying 'how did this analysis come to be wrong? How did it make this wrong decision? Where else have we made this decision?' People are starting to do this with software."

"The OpenBSD Project started doing it with security in particular, and found it very effective. Every time somebody found a mistake, they'd take the entire software base for these systems - bear in mind, working in the open source world you have a lot of source code, so it's much easier - and you look, with the aid of automated search tools, for every other occurrence of the same problem, in all your software. Because if someone's made a mistake once, we know lots of other people will have made the mistake.

"All of this sort of analysis then leads back to things like, what tools didn't we use? Are our interfaces wrong? And because you're able to actually start digging in and get data, you can start to understand not only the 'oh, it's failed, I'll fix it', sort of the car mechanic approach to software maintenance, but actually the need do the kinds of things that should be done and which go on elsewhere, where you say 'Why did this fail? Where else have we got this? Where else will it fail? What should I do proactively? How do I change the software component involved so it can't happen again, or so that it blows up on the programmer when they make the mistake, not blows up on the user when they run the software?".

Document trails: "I've worked for several large software companies, before I worked for Red Hat, and trying to answer questions like, 'Who wrote the first version of this software?' and 'What other code is this function in?' can be interesting."

"So you're looking at an ISDN router and you say, that's a security hole. And you have no idea where else this code appears in your company's product line. So you have no ability to test all the cases. Someone has to test each one individually, and possibly get it wrong, possibly find the code. So document trails are also a big help; where did this code come from, where is it going, what things do we know programmers get wrong with it? Actually carrying the documentation around with this software not only makes you get the documentation right so you can tell the programmer, by the way, people always get this wrong, but more importantly, you can fix it so they can't get it wrong. Because after all, programmers don't read documentation - you know that."

Rigorous reviews: "The effect of having to explain it to a second person is sometimes truly startling, as people try to explain what the code is doing and then realise that what they've written doesn't do the same thing."

Statistics: "And the final one which turns out to be really useful is statistics. Because if you've got enough copies of a piece of software out there, you can actually do statistical analysis, and so we've been doing this now with Linux, and you can start asking questions like, is there a 90% probability that all of these mysterious crashes with this kind of pattern, happened on a machine with a particular physical device, like a particular SCSI controller? Did 90% of them happen on a machine with a USB keyboard? We've actually pinned down hardware problems in this way - in one case we managed to pin down a fault in a particular brand of disk drive, because we looked at it and we realised it is directly correlated to this particular make of disk. And we went to the disk vendor, who ignored us, and eventually enough Windows people hit the problem that Microsoft went to the disk vendor, whereupon it got fixed."

A video of the presentation is available at IT Wales.

2003

[Jan 28, 2003] Interview with Alan Cox Builder AU Program At Work by Brendon Chase, ZDNet Australia

One of the head programmers behind Linux, Alan Cox talks exclusively to Builder Australia about the uptake of Linux, Microsoft’s plans to share its source code and his Linux predictions.

You have been working for Red Hat since January 2000, What is your title and what are you doing?
I was contracted a bit before that for a while. I am a fellow; most of what I'm doing is working on the kernel, some of it other applications that need fixing. I also deal with awkward bugs, things that matter to important customers with support contracts that reassures them we can fix bugs whenever they turn up

What do you think of large organisations looking at Linux for their solutions?
I see a lot of big financial institutions looking and deploying very large amounts of Linux on servers. Desktop people are looking looking at it more and more I think because open office is highly available, accessibility, user interface among other considerations to a point where the stuff is useful, but not necessarily perfect just yet. The one problem they've got is the lack of available software, which in big business normally isn’t a problem because you have large numbers of people who need very small sets of software, but smaller businesses can be a challenge because you’re trying to use the same PC apps for email, for accounts, word processing, so you many find the PC's might not be there yet.

Recently Microsoft have announced they are releasing their source code to governments...(interrupts)
To a few governments, it leaves the question: "If they have to release the source code to governments what does it say to the companies they won't release it to?" It’s also interesting to note that in some countries, where perhaps the relationship between governments, business and the people are not so good that by giving it only to government it is giving government the power to use all security holes in Windows so they may have done harm to business and individuals. But (releasing the source code) it is a step in the right direction.

Do you think this step is a threat to Linux?
No. There is a real difference between "you can have a quick look at some of our source code but you can't do anything with it, and you have to be a government and we have to like you". In addition to which, just having the source code isn’t really that useful because unless you have the code for compiler and you can rebuild all the code and verify it, how do you know the source code they have given you is anything to do with the actual operating system your running? And that is a very real question. One the other hand we've had military and government security people who've actually taken a basic Linux system including the compiler, they’ve audited that compiler and have built and audited every single single sub set pieces of Linux they use so they can definitively say that it doesn’t have any back doors in it. At least in their version of it and they are happy with it and any back doors they have put in themselves for their own use.

What do you think of Sun's announcement to release Mad Hatter midway through this year?
It’s just another distribution. I think it's quite clear where all the work is coming from. I don’t see where the value added is unlike those like Dell, but maybe they have things they'll do.

Where do you see Linux in 2 years?
I think in two years we'll see more Linux on the desktop. It will be very interesting to see what happens, its very hard to judge.

How about 5 years?
Hopefully world domination! (laughs). We shall see, it could be in five years time, someone comes along with something much neater, and we'll all be wondering "those old operating systems were awfully clunky."

What desktop environment do you prefer to use?
I'm mixed, open office, a lot of GNOME stuff and one or two KDE apps. If you have Red Hat they all look the same, so it ceases to be what desktop do you run and it becomes a question of which program is the best, which program environment do I prefer to write software, so it gets rid of that divide.

One subject you bought up in your talk is documentation in Open Source. What grade do you give it at the moment?
It varies by project. Some projects are absolutely brilliant, a lot of it is pretty poor. Certainly in terms of things for example Solaris, where where the Sun people have had this long going very tight discipline about documenting everything in a very definite and clear format. So we have some way to go in that field.

In yesterday's Q and A session, there was concerns raised about the benchmark getting higher and higher to start working on the kernel. Is this a real concern?
There is a thing about the core of the kernel because it's a very very complex, very very refined piece of software. In terms of writing device drivers it has actually gotten easier as there is a lot more infrastructure in the kernel so there is a lot less code you have to write and a lot more code to copy. Being open source the way you write a driver is to find something similar, copy it and go from there. It's perhaps a little different in the Windows world.

When is the next Red Hat release?
We don’t pre announce releases and I can’t speak for Red Hat.

There are many standards bodies around. What do you think of standardisation?
A lot of them go way back before Linux. Most of the standards bodies things are useful. The problem sometimes comes when standards bodies standardise things that are dumb and generally free software ignores those standards. Most of the standards bodies are not necessarily interested in free software but they see free software as part of the universe they are trying to build standards into. Having one set of standards for free software and one set of standards for Windows doesn't really work, the only person you hurt at the end of the day is the customer as they can't switch easily.

How have you found Linux.conf.au 2003?
Really good. There is some good technical stuff here. The other main conference I go to is the Ottawa one, which is the other technical one. Things like Linuxworld which is marketing and press releases just isn't my thing.

Copyright © 2005 CNET Networks, Inc. All rights reserved.
Builder is a registered service mark of CNET Networks, Inc. Builder Logo is service mark of CNET Networks, Inc.

2002

[Mar 06, 2002]Alan Cox hails 64-bit Linux - ZDNet UK News

Part I: In an interview with ZDNet UK, the Linux 'kernel hacker' gives his views on the GPL, 64-bit computing and why grandmothers should want to use Linux
Alan Cox is generally referred to in the open-source developer community as a "kernel hacker" -- someone whose programming responsibilities cover the Linux kernel, or core, itself. Thousands of developers all over the world, from hobbyists to IBM engineers, are constantly contributing to open source software, so Cox's role of organising and applying improvements is vital.

Cox makes use of the decentralised nature of the Internet to work from his home in Swansea, despite the fact that his employer Red Hat is based in the US; in fact, at the moment he prefers not to visit the States, because of concerns about the Digital Millennium Copyright Act (DMCA).

He spoke with ZDNet UK in Swansea in a wide-ranging interview touching on the latest challenges for Linux at the high- and low-end, the arrival of revolutionary 64-bit hardware and why it's hard to argue with the economics of open-source software.

Q: What were some of the biggest developments for Linux last year?
A: I guess the 2.4 kernel coming of age is one of them. We now have a good solid, very scalable kernel, which all the vendors are shipping, that's improved no end on four- and eight-way machines.

Is scalability mainly an enterprise issue?
It's pretty important for the big enterprises. It helps everybody. If you look at the direction the market is going, you've got things like Intel's new Pentium 4 with hyper-threading, where a single CPU is effectively two, so you've got scaling issues going on in single-processor machines.

Beyond that a lot of the user interface work is really starting to show. The Nautilus file manager... some really, really good work being done with KDE and also configuration tools.

What's the importance of improving graphical user environments like KDE and GNOME?
Within a very large organisation what they want is a small number of people who can maintain large numbers of machines, and they'll be very skilled people. The moment you go into smaller businesses and outside of the big-business, large-government role, you need machines where anybody can say, "Ah, what's happened here?" and fix it. So it doesn't necessarily become a case of needing the power, you start to need the usability. Even if the usability means you can't do some of the clever things, these people still need to be able to do things like set up a simple firewall and configure their email and stuff. So that is very important.

On a technical level, other things would be clustering work being started.

IBM recently introduced its first dedicated Linux mainframe server. Linux on the mainframe seems to be getting a lot of attention at the moment.
It actually goes back a fair way. It's been around for a year or so. Now it's really starting to take off with this server consolidation thing, and IBM has sort of hit the wave with the blade server people as well. If you can run a thousand copies of Linux on one machine, what are the savings of not having a room full of computers? I think they just have been at the right place at the right time in a sense. They've got hardware which is very fault-tolerant and they can ship it now while everyone else is very much -- all the PC style hardware doing this is very new.

IBM is spending a lot of money promoting its Linux plans. Do you see any problem with IBM integrating Linux into its corporate strategy?
There are one or two points of friction for IBM. Certain drivers for the S/390 (mainframe) are closed source, which has proved problematic for customers, because they can't upgrade to the versions of the kernel they want, because they can't get the right drivers from IBM. On the whole, though, I think it would be fair to say that IBM have been extremely good citizens of the open source world, they've contributed a lot of very, very good code. I don't think that's a big issue, just this one S/390 issue.

What are the most important developments coming up for the Linux kernel?
In the desktop world there are a set of transitions for the legacy-free PCs which we have to be ready for -- we're pretty much in the right spot. So you see machines where USB is basically the only plug-in interface. ACPI (Advanced Configuration and Power Interface) is becoming a requirement on machines, so you have to support the ACPI configuration.

We've covered the Pentium 4 hyper-threading. There are more scaling questions, because we have more memory, bigger disks, again and again and again. Possibly the Intel IA-64 processors, depending on if they take off, and the AMD Hammer could be a very, very big thing. That looks like that will actually be a consumer-oriented 64-bit processor. It will be able to run 64-bit and 32-bit as well.

Who will mainly benefit from 64-bit?
We get large numbers of people, particularly people with large financial analysis systems, electronics design automation, even things like SAP, where believe it or not, 4GB of address space, 4GB of memory, is just not enough. The SAP people have to actually try and squash their code into it, the software is so powerful. For those kind of roles 64-bit is basically essential, and at the moment a lot of these people are stuck on very expensive proprietary system, and once they can go 64-bit, they'll be able to dump a lot of this hardware, and move over to mainstream PC platforms and save an absolute fortune.

The consumer level impact is, I suspect, just speed improvements here and there. Obviously being able to do 64-bit integer math is good for certain kinds of 3D work, so it might help the gaming people. There's all sorts of other applications where having 64-bit just happens to be a help. But the really, really big gains are for the big electronic design automation systems.

It opens up a whole new market for Linux, doesn't it?
It's effectively extending the PC itself, not just Linux, extending the whole PC into another market area where currently there's a barrier. In some ways it could be as big a shift as the 386 was in opening the 32-bit world to the PC. From that the PC became the ubiquitous 32-bit system; now it could become the ubiquitous 64-bit system.

Last spring you met with some of the other main Linux programmers in the first Linux Summit. Was that useful, and will it happen again this year?
Provisionally so, at the Ottawa Linux Symposium (OLS), I believe, which is the main kernel developer forum. It was strange in a way. The official part of it was actually very non-productive. The amount of work that got done over beer and at three in the morning cannot possibly be overestimated.

A lot of it is meeting people. Meeting somebody occasionally you get to understand them enough that you can follow things in email or other discussions that you just would not pick up normally. So yeah, it is a big, big help.

Sometimes lots of things come out of it. At the last OLS I went to there were people literally sitting around with their laptops and they would just look over each other's shoulders and get to talking and pick up on things that never would have occurred to them before.

How militant are you about which licences people use for their software, and how they use them?
People who are not following the (free software) licence are pirates, it's as simple as that. It's no different if you take GPL (GNU Public Licence) code and don't give people the source code, or if you make copies of movies and sell them to people, it's the same thing. In terms of other software, it really depends on the people who write it. I don't think you have a right to dictate how somebody controls their own work, apart from the very, very basic standard you'd expect.

Ximian recently decided to switch class libraries for Mono (a clone of Microsoft's .Net) away from the GPL. How controversial is that to you?
I've only looked briefly at the reasoning behind it, but I think at least part of the reasoning was that, for something like Mono they wanted people to be able to link proprietary code with the free software code and mix them up and get it to work. Really you have to ask the Ximian people about that. I don't really have a problem with it; it's their software.

You feel it's important for Linux that free software licences are able to coexist with proprietary licences, don't you?
We're being very careful with that. We specifically allow people to use all the system call entry points for Linux for driver software, and the main libraries you need to build applications are under (a different) licence. So the library itself you have to provide source for, but not the application. Because obviously Oracle are not going to give source code to their tools. But you don't want to create a system where you arbitrarily shut people out -- that's the Microsoft world.

It's actually ironic that, because Microsoft has started putting licences on Windows libraries now which basically forbid you from writing free or open source using their Windows libraries. They're specifically trying to shut out and control. They're monopolists.

Their role as a monopoly changes the way they approach software, you're saying.
An application and operating system should be totally different things. They're different works. It should not be Microsoft's business how (an application) is written and vice-versa. And as a monopolist, even more so -- the fact that you can say "oh, you're not allowed to licence your code like this and run it on our system," that's 90 percent of the desktops, bang, gone. So as monopolists they have duties beyond the norm.

Do you feel it will be Linux's ultimate role to be ubiquitous on the desktop the way Microsoft is today?
It may play in the same markets, but it can never play that Microsoft kind of role, because being open source, you can't control people, you can't force the prices up 40 percent every year, you don't need to force people to upgrade because it's a service-based industry anyway. So looking at it from that perspective it's very different. In terms of being able to get it into lots of very different market areas, then yes, I think that is important.

See Part II: The battle for the desktop

Cox, one of the chief contributors to the Linux kernel, says 64-bit computing will open up a huge new market for open-source software. He also finds fault with proposed Microsoft-influenced guidelines for reporting software security bugs

The advent of affordable 64-bit computing could be the best thing to happen to Linux in a long time, opening up a new market potentially as important as the original PC market, according to Linux "kernel hacker" Alan Cox. He also criticised new guidelines suggested by the Internet Engineering Task Force (IETF) covering the reporting of software security holes.

Click here for part one of ZDNet UK's exclusive interview with Alan Cox

New processors emerging from AMD and Intel -- whose main focus has until now been desktop chips -- will allow many companies currently locked into expensive computer systems to switch to mainstream chips and open software like Linux, Cox said. The new Itanium line from Intel and the upcoming Hammer range from AMD offer similar performance to the RISC processors made by the likes of IBM and Sun Microsystems, but aim to achieve desktop-level prices.

"Large numbers of people will be able to dump a lot of expensive hardware," said Cox in an interview with ZDNet UK. "It will effectively extend the PC into a whole new market area. It could be as big as the 386." The 386 was an Intel processor introduced in the late 1980s, known to Linux developers as the first consumer processor powerful enough to run industrial-strength software like the Unix operating system.

The 386 was instrumental to the early growth of Linux, a Unix-like operating system that many say could replace Windows as the dominant software on PCs. Once reasonably powerful hardware was available for a low cost, a large number of programmers began installing and improving Linux -- Cox, then a student at the University of South Wales, among them. The result, more than ten years later, is the software that runs a good number of the servers on the Web and many of the protocols that make the Internet work.

AMD's Hammer is particularly promising, Cox said, because it will run on both consumer and server platforms right away. Unlike Itanium, Hammer is optimised to run software based on the current x86 instruction set as well as 64-bit software. Itanium places the emphasis on 64-bit code, leaving the consumer market to the Pentium 4 for the near term.

Cox, an employee of Linux vendor Red Hat, is now one of the chief developers on the Linux core -- or kernel -- and is largely responsible for coordinating and integrating the contributions of hundreds of developers around the world. Linus Torvalds, who initiated the Linux project as a student in Finland, still has the final say on modifications to the kernel.

A controversy arose recently over whether the job of applying "patches" was getting to be too big for one person, but Cox says he feels the solution that emerged, involving automating the kernel changes, is ultimately satisfactory. "The free software community has a way of self-correcting when problems arise," he said.

Linux is based on the "free", or open-source, development model which requires developers to make the original programming code of their software improvements freely available to other developers.

Communal debugging is central to open-source development, and Cox bridles at recent attempts to change the way bugs are reported to software vendors. A recent draft protocol from the Internet Engineering Task Force (IETF), for example, has been criticised for stigmatising those who report security holes before the software vendor has had a chance to create a patch, and Cox tends to agree with some of the criticisms.

"It's too prone to let things run and run and run," he said. "If the vendor hasn't fixed the bug in 28 days, then tough -- after that you're not reporting bugs, you're covering up for a company's incompetence, and there's a very big difference."

The immediate challenges for Linux developers include extending its capabilities for both power users and grandmothers, Cox believes. On the high-end, scalability is becoming an increasingly important issue, while it's also crucial to make Linux accessible through simple interfaces, he said.

The emerging use of hyperthreading within Intel's Pentium 4 processor means that Linux must scale even within the chip. Hyperthreading is designed to improve performance by allowing the chip to behave like a two-processor system. It is present in all Pentium 4s but is only made use of so far in the new server P4, called Xeon.

Progress was made in this direction last year, said Cox. "The 2.4 kernel is coming of age," he said. "It is getting more scalable, especially with four- and eight-way machines. That's the direction the market is going."

On the other hand, simplicity is more important than power if Linux is to penetrate certain markets, like small businesses and the home, Cox argues. He applauded the advances last year made by organisations focused on user interfaces, such as GNOME and KDE.

The home market is the toughest market to crack in many ways, he said, because of the particular needs of consumers. Ultimately, though, the all-purpose PC as championed by Microsoft may prove to be less attractive to home users than a simpler, less expensive machine specialised for applications like Web use and productivity tools. Linux is ideal for such machines because of its low cost, reliability and flexibility.

"You could question whether the consumer PC market will survive in its current form," he said.

The shift to specialised, Web-centric devices is made easier by the fact that the new applications users want no longer require a monolithic, standard operating system, but simply a standards-compliant Web browser, Cox said. Microsoft argues that users will always want a uniform operating system so that everyone can run the same applications; it also says its operating system monopoly makes things easier for developers by providing them with a huge, homogenous market.

Cox's views, not surprisingly, tend in the opposite direction. "There shouldn't be one worldwide operating system," he said. "Peoples' needs are all very different."

One Linux innovation last year that was less than a complete success was last year's "Kernel Summit", where many of Linux's main contributors, including Torvalds and Cox, met face to face to coordinate their plans. The official part of the programme wasn't very productive, although things picked up after hours.

"The amount of work that got done over beer at 3 am cannot possibly be calculated," he added.

[Feb 12, 2002] The ITW Interview By Matthew Pearce

Alan Cox is one of the most influential IT innovators in the world. A graduate of the University of Wales, Swansea, he has been a key developer of the Linux kernel for nearly a decade. Currently working for Red Hat® writing kernel and application code, Cox was previously responsible for the original Linux multiprocessing support, and for much of the early work on networking. Here we ask him about his changing role at Red Hat, and learn about the benefits Linux brings to business.

itwales.com: You're a leading kernel developer on Linux. What exactly does your role entail?

Alan: Mostly I am involved in making sure changes get integrated and that the changes are of a high enough quality. Often this also means working through longer-term plans for the Linux kernel. It also gets to be fun because many of the contributors have conflicting aims and it is necessary to find problem solutions that work for all cases √ from Linux on a PDA to Linux mainframes.

itwales.com: The Linux kernel is a modular one. What benefits does this bring to the OS user?

Alan: Modularity is an essential part of a reliable system. If you cannot change one part of the system without needing to modify the rest of the system you cannot fix a bug without risking introducing thousands more.

The modularity is more important to developers. With developers working on Linux on all continents its essential that everyone can make changes without full communication.

itwales.com: You recently stated that you plan to work more closely with customers. How do you see your role changing in the near future?

Alan: Red Hat is starting to pick up a number of enterprise customers. These people pay for √ and expect √ a very high standard of service. That includes improving the OS kernel to provide facilities that they depend on in legacy platforms they want to discard. One of the things Red Hat has to be able to do is to deliver those facilities.

itwales.com: The Linux OS is renowned for being stable, fast and virtually virus-immune. How have you achieved this?

Alan: Open development. People have spent ten years looking over each other's code able to refine the existing code and to spot security holes. The same process of peer review that ensures university research quality and that bridges don't fall down has simply been applied to software, which as an engineering discipline should always have been the case.

itwales.com: As a student, you installed Linux on the Swansea Computer Society computer. Is this how you began experimenting with the Linux kernel and became interested in Linux?

Alan: At the time the 386 based PC began to take off it was apparent that this was the better longer-term option for the society. We had two old minicomputers kindly donated by the computer center but we needed to move on. It also appealed to quite a few of the society people because it was not a closed box. The computer society's goal was educational and a bunch of students attempting to debug their own kernel certainly proved that.

itwales.com: Open source' means software is owned by everyone, and anyone can contribute to it. Is the sharing of ideas important to you? Was choosing to work within the free software community an ethical decision?

Alan: Technically the software is still owned by the person who wrote it, but that is more of a credit thing √ which is important in the community. For me it wasn't really an ethical decision, it's simply the right way to do engineering. You don't build reliable bridges by refusing to let anyone see the plans.

There is a real problem in both the US and Western Europe today with people trying to own and control ideas, but that is something bigger than just software or free software. Ironically it is having the same effects on free software as other things √ all the great innovation is moving to Eastern Europe, India and South America.

itwales.com: What are the advantages of an open community when it comes to product development?

Alan: From the developer point of view it means there is a huge range of talent. No matter how obscure a problem or a requirement is there will be someone who wants to solve it and who understands the field.

It also allows the sharing of development work. A large part of a computer system nowadays is generic and the revenue is in customisation and services. In the open community the cost of building the generic parts of a system are shared not duplicated. For researchers it has turned out to be a very big blessing too. It is possible to take an open source OS and modify it to test research theories and algorithms in real world environments without building costly throwaway mock ups. Furthermore, if it works out, it can be folded into the main project.

itwales.com: Linux has yet to be widely adopted as an OS by businesses, but the expense of Windows new XP operating system might change that. How are you targeting businesses?

Alan: Larger companies are adopting Linux rapidly for server systems in particular. Getting further into that market is now mostly about growing the quality of high-end support services.

The desktop is more challenging because desktop users are an extremely varied bunch of people. It demands a high quality and an easy-to-use environment √ which is now mostly there √ and it demands a large application portfolio which tends to be the chicken and egg problem.

At the moment the desktop market for Linux is growing in two areas. Firstly in providing large numbers of easily managed desktops running either custom or very standardised software (such as the Star Office suite), secondly in the technical desktop market where the tools wanted are primarily the powerful development tools Linux has had for many years.

The ever-rising price of MS Office is increasingly pushing companies to look at Star Office both on Windows and on Linux. In many ways the effective forty per cent price hikes in Microsoft pricing have been the biggest driver of Linux on the desktop.

itwales.com: Are the merits of Linux's business applications attracting users?

Alan: The main things that attract business at that level are the pricing, reliability and the reduced business risk. The fact that there are multiple suppliers of the operating system gives a great deal of comfort to companies using it. In addition the license ensures that they can always get a custom change made for their own use, even if the main distributors are not interested. In the open source world one example of this was Y2K. When packages had Y2K problems and were no longer maintained by their authors, anyone or any group of users could fix or pay for fixing work. There was no ⌠enforced upgrade■ risk.

itwales.com: It's been said that in the last year, particularly with IBM's use of Linux technology, Linux has become a mass-market alternative to Windows. Was 2001 a turning point for Linux?

Alan: It didn't strike me as a turning point. There has been a continuous trend in the increasing use of Linux particularly server side. With some of the big names now using and supporting it, visibility has increased.

itwales.com: Do you think Linux markets itself effectively to businesses?

Alan: That is really a job for the vendors, and I think they are doing a good job. There is a difference between effective marketing and claiming to be the one true solution to all problems. Linux is not the one true solution (if such a thing truthfully ever can exist), but we are working on it.

itwales.com: Why should an SME choose Linux as an operating system?

Alan: Because it will save them money and do the job better. If at this time that isn't true for their application set then they shouldn't choose it. The desktop monopoly has perhaps clouded things but with any tool the same fundamental rules apply, be it a hammer or a web server. Is it the right price, is it reliable, will it do the job?

itwales.com: How does it save SME's money, specifically?

Alan: As an SME you can pick from multiple vendors, or download it yourself. You can install it on as many machines as you like without expensive software auditing. If you need specialist features you can go to a company with experience directly in the matter. You can buy support from where you feel happiest, including companies that actually listen to their customers. No single company controls the ability to modify the software.

In many ways the lack of a per seat license to install the software is a side effect of the recognition that it's more efficient to develop openly. The better overall pricing, improved reliability and removal of vendor lock-ins are the really important factors.

itwales.com: How can Linux overcome Microsoft's dominance at the desktop? Will you have to come up with radical new technology?

Alan: In part this depends on the legal settlements. One of the big problems right now is getting Linux pre-installed on a PC. When you investigate why this is hard you end up looking back at questionable monopolist influences.

With the settlement, the large number of civil lawsuits pending, possible EU action, and the question now raised in the US about whether business practices of not paying dividends are in fact allowable or an illicit tax haven there are several chances for justice to be done.

Beyond that, the open source model is faster and more cost effective. It improves more rapidly, and for less investment. It's very hard to compete against a fundamentally more efficient model.

itwales.com: Microsoft recently implied that it's going to seriously target Linux in 2002 as a competitor, plus any vendors that support it (such as IBM). They are especially concerned with the server marketplace, and aim to find out about the use of Linux in their customer base. How can Linux combat this "assault' from the IT giant?

Alan: Primarily by being cheaper, more reliable and higher quality. End users believe their own experiences over a salesman. Company directors talk to each other as well as to sales people. In terms of advertising, IBM have already been running Linux TV advertising in the USA.

itwales.com: In recent years, commentators have warned of a fragmentation of Linux (in a similar fashion to Unix). Because the OS is open source, programmers can come up with different versions, and applications may not run on every version of the OS. Do you think a level of competition will be introduced by this?

Alan: Competition and product differentiation don't have to mean incompatibility, and in fact the incompatibility story is mostly a marketing myth put about by a certain large vendor. The Linux companies care about compatibility a great deal, and one recent result of this was the Linux Standard Base, which defines precisely the base behavior of the core Linux software that applications rely on. You can expect to see compliance statements in the next series of vendor releases.

itwales.com: You resigned from the Usenix ALS committee earlier this year, reportedly because Dmitry Sklyarov, the Russian programmer, was arrested in the US. What do you think of the situation in the US at the moment with regard to the Digital Millennium Copyright act?

Alan: At the moment I consider the USA not a safe place for a software engineer to visit. Money and lobbyists buy many things but when it comes to the courts I don't think that the DMCA aim to send people to jail for even discussing security flaws is going to stand well against the US constitution. Until then I'd rather play safe.

These things happen. Right now the UK Government is busy trying to pass the similar European copyright directive into law in a way which may well make it a criminal offence to help a blind person read an electronic book if it has been protected by some mechanism that interferes with their screen reading software. It also puts web caches that do filtering (for example pornography filtering for schools) on questionable legal ground.

itwales.com: What is your opinion on the Government's involvement with Microsoft? Do you think that governments, as a rule, should use open source technology?

Alan: When the prime minister is appearing at product launches by a company twice found by courts to be abusing a monopoly, and facing billions of dollars in lawsuits you have to ask questions.

Governments should evaluate open source technologies certainly. The fact they get the source code and can audit it has been a reason for some countries to adopt open source, pricing is another. However, I don't think its right that government should have fixed rules beyond ⌠fair review■. There may be situations where proprietary software is genuinely the right choice.

itwales.com: In terms of its skills base and its WDA initiatives, do you think Wales is improving as a venue for software development?

Alan: In some ways √ and the lack of London pricing means it is cheaper for an SME to get the staff (as well as a higher standard of living for the staff) than in the South East. Right now we seem to have a problem in that all the IT literate people move to the South East because there is little Welsh IT employment. As a result of them moving there is no expertise here so there are not enough Welsh IT companies. Thus the cycle continues.

It is a very hard problem, and one I am glad I don't have to solve!

2001

2000

[Nov 23, 2000] Linux.ie Alan Cox Interview "Total domination is bad. The Microsoft dominance already badly misled people about how to choose systems. Instead of 'what tool do I use for the job' it's 'well it was shipped with the box'. Linux is a tool, Windows is a tool and so are numerous other systems. It's really important people go back to looking for the right tool for the job. That will never always be Linux. No single tool can do everything well."

1) Is Linux heading towards a major rather than minor computing role, or is it still too early to tell how things will unfold?

I think it is still hard to predict. The market is changing so fast.

Not only do we have the shift from the desktop to servers and thin client machines happening - and it is happening at least in consumer spaces with things like NTL's TV set internet stuff and the ongoing projects from other big vendors. We also have the exploding mobile market, the phone/PC fusion and more. So it's hard to guess.

Linux does well as a server OS, it does extremely well on the thin client and embedded environments too. The configurability and the fact that it isnt owned by a competitor to the companies using it make it a big win for them.

The desktop will be the hardest battle. The Microsoft lawsuit might help there if there is enough will in the US Government to split Microsoft and force the units to act alone. We now have most of the GUI environment we need for end users.

2) What do you think has been most integral to Linux's growing success and visibility in the past 18 months?
a) In terms of the OS itself (eg, why is Linux such a contender?) and
b) In terms of marketing success (eg commercial deals, product announcements, backing of big name players, etc).
The biggest thing of all has been the rest of the world seeing free software going from a crazy concept to a marketed advantage and marketed in a way that the business community understands. The stock market flotations also gave it a definite air of reality.

You can get news out of hype, and there has been a lot of Linux hype from companies either because they sell Linux products or because they see it as a stick to bash Bill Gates with (or both). Hype doesn't actually create a large user base and sustained deployment which Linux unlike Java is getting.

In terms of Linux itself I think the Gnome and KDE desktops have been the big shift in thinking. Linux has picked up people who believe in OpenSource and who want Linux to be part of a bigger community than just the computer wizards.

3) Where would you like to see Linux go today?

what could be done to most enhance the OS itself and why would that element be important (user interface, killer app, or whatever) and

in terms of commercial success.Is total world domination (in the commercial space) important?

The big step is the desktop. There are vendors with clear interests in this sort of area - Helixcode and Eazel for example who are doing real money work on the GNOME desktop. The other big area to deal with is high availability clustering. Wensong Zhang did the first free Linux clustering for web server failover and the like but that is only the baby steps. To do full clustering and to be able to position Linux to replace things like VMS as a highly available (and here we are talking minutes of downtime a year) clustering solution is no small job.

I personally think the desktop or at least the thin client end of the desktop is the most important. Linux has good security features which makes it ideal for things like call centre environments, although perhaps less so for their staff. Building a thin client Linux environment with hotdesking, sensible shared file store and good network efficiency is a golden opportunity.

Total domination is bad. The Microsoft dominance already badly misled people about how to choose systems. Instead of 'what tool do I use for the job' it's 'well it was shipped with the box'. Linux is a tool, Windows is a tool and so are numerous other systems. It's really important people go back to looking for the right tool for the job. That will never always be Linux. No single tool can do everything well.

4) If it's important, or if you think that Linux is going to take a larger role in the commercial world anyway, where do you think it will have its greatest success, and how might that change the computing industry?
For example: at first, Linux seemed a desktop OS for enthusiasts, then began to sneak onto servers and has staked out some serious web server territory, of course. But IBM is eyeing it, for example, as being as important to applications as TCP/IP is to the internet. Software companies will port to Linux, they say, because it's easier than porting to Unix flavours or NT. That benefits hardware companies and big app companies like SAP, according to that view. I'm interested how you think things might develop; if you'd agree with the IBM scenario, for example.

Linux is the sum of contributions so it will go where the contributors take it. Right now that is everything from IBM mainframes to pocket computers. Some of it is through investment and funding and a lot of it is because someone just thought it would be neat if Linux did XYZ and had fun working on it.

I can see Linux becoming the generic OS for embedded applications and servers. Where people will pick Linux unless they need some given feature that favours another system. I don't know what will happen on the desktop.

Only time will tell.

5) There's much talk now of Linux fragmenting into flavours. Do you think this could happen?

The ISVs don't and won't stand for it. The customers won't stand for it and the community definitely wouldn't. There is a lot of work right now to get definitive standards via the Linux standards base (linuxbase.org). That has real big vendor backing because the vendors want to ship 'Foo for Linux' not 'Foo for Red Hat', 'Foo for Mandrake' etc. Also non-Linux people are quite interested in this too. We may end up creating a common interface for applications on the PC in any Unixlike environment. That is definitely good for customers.

Ultimately nobody who wants to build the Linux space either commercially or for fun has any business or technical reason for creating an incompatible variant. In fact the pressure is entirely to improve compatibility.

6) Can Linux and the open source attitudes of the developer community surrounding it co-exist with Linux's commercial success? Do you see strains arising out of these developments?

The developer community on the whole seems not to care too much.
Certainly the developers I work with both in and outside Red Hat are more loyal to Linux than to their companies. There are certainly marketing people who see other vendors as the enemy. Programmers never cared for marketing peoples' views anyway ;)

7) Linux companies hit celestial IPO heights recently then have crashed since then. Is this a 'correction'? A failure of Linux to meet expectations in the commercial world? A pointer that an open source OS won't make anybody money?

I think there is plenty of scope to make money, as it seems to do a lot of people. Its certainly not going to make Microsoft like profits and that's probably a good thing for everyone long term. It is about time people got fair prices.

The stock valuations just remind me that the US technology stock market is basically a gambling den. It seems to be based on riding hype to the highest value you dare then trying not to be the last one to sell. In time I imagine the Linux valuations will settle down.

8) Finally, what motivated your own involvement with Linux and why does it remain so central to your life?

Well I got into it by accident. I wanted an OS to debug my multi-user game on and Linux hacking became a sort of hobby.

Now I'm paid to give away code and watch it empower people all over the world - especially developing countries. I don't know many jobs to compete with that one.

Alan

Chat with Alan Cox Contributed by jono on Sunday June 18, @ 11:49PM

At the Linux Expo we had a chat with Alan Cox about everything from kernel hacking to Jolt cola. Check out the transcription by hitting [DETAILS].

Interview with Alan Cox

Please note that this is a transcription of a conversation.

Everyone knows you as the kernel hacker in the Linux world. What do you do when you are not hacking the kernel?

At the moment I am in the middle of trying to buy a house. It involves a house where all the windows need replacing and a few other things like that. Thats one of the things keeping me occupied. Trying to figure out how to get rid of all the hardware is the other. Two things are hard. One of which is finding space for it and the other is getting stuff you don't need back to people, so there is a fair bit of space management going on.

How is Telsa taking all of this?

Better than she took two MicroVAX 2's in the living room a few years ago.

Those are the ones about the size of a fridge aren't they?

Thats about right, yes.

Did you manage to get Linux running on them?

I was just looking after them temporarily while waiting for someone who was a bit late taking them off my hands. They get a little bit touchy after a while.

What else do you do hobbies wise?

Well, Linux is my hobby. I have been playing around with various things; I have a spider plant I am growing and stuff like that.

Any cacti?

The machine room would probably do very well for a cactus.

Getting on to the more technical side, what are the main elements of the kernel that you *enjoy* hacking?

I have great fun with all of it. Most of what I am doing now is coordinated across large amounts of the kernel, so there is not really any specific bit of the kernel that I am concentrating on anymore. In some ways thats more fun, because every day you are dealing with a different piece of the code with a bunch of people.

On average how much time do you spend hacking away?

Dunno, probably about 60 hours a week.

A fair bit then...

I do sleep which is something contrary to rumor.

The Linux community seems to have given you the status of the archetypal hacker. Do you think that you fit the stereotype of a hacker; sitting there with a pointy hat drinking loads of Jolt cola?

Well, unfortunately the Swansea supplier of Jolt cola no longer sells Jolt cola. I am currently investigating whether you can buy it by the crate wholesale.

We have had similar problems. We wanted to buy it from Think Geek but unfortunately they don't ship it over here.

I know there are UK suppliers, so somebody needs to get into the business of selling Jolt in the UK, by the crate load over the Internet.

Yeah...we should maybe think about that.

On the kernel front, the jump from 2.0 to 2.2 everyone thought that happened too slowly, it took over a year to come out. You seem to have gone quite quickly from 2.2 to 2.4 and that kind of worries me. Why has it taken so little time?

Part of it is how many things you stick in each time. With 2.2 we just kept thinking..."we will just squeeze this and this in". We could probably have stopped two or three times in the 2.2 build up. We thought 2.1.40 something was pretty stable, we will go from there; we didn't do that though; we might as well try this as well. It's always longer than you intend anyway. We thought that we want to get a release out, so we won't put journaling in the standard kernel. Journaling is great but it will have to miss if we are to get it out.

Are you going to put the Reiser FS in the 2.5 kernel?

As I understand it we will take all the code for the journaling file systems and create a single layer that everyone can use, so with the ext3, Reiser, JFS, XFS; a lot of what they need is common, so we want to get them together to build the right common code. Also, NWFS, the network file system is apparently now journalled.

What's the first thing your going to be adding to 2.5?

I have no idea. It depends what the first patches are that I get.

How did you originally get into coding the kernel? I assume you did user level stuff before the real low level stuff...

I got involved with a multi user game. Having done that I kind of hacked UNIX like behavior into the Amiga so I could test MUD on it. I wasn't as arrogant as Linus, so I didn't believe I could write my own kernel. Arrogance and stupidity were two of the starting ingredients in some ways! Finally there was a reason to own a PC; PCI had got better but there was nothing to run on it. 386BSD was announced, but I downloaded the earlier release as 386BSD required a floating point chip, and those were about £50 extra; I wasn't far past being a student, and I wasn't very rich. I managed to scrape together this old 386 with 4MB. I did some stuff with the university computer society; the university went Ethernet. We got the new TCP/IP stuff implemented and bang...ok...debug it a bit...bang...debug it a bit...oh it's staying up...log in...bang...and we were actually the first people putting the first Linux networking code on really busy networks. The campus network was busy and had lots of protocols on it, so we were the first people seeing lots of bugs, so we started fixing them because we kind of wanted the university bulliten board up for more than three hours a day. With 0.99 to 1.12 we were having more uptime hours than anyone else. Fred took over the networking for a while, and he wanted to rewrite it, and we were trying to work with the original code, so I sent out a bunch of patches called net2debugged and Linus started applying them, and somehow I ended up in charge of the networking code. 2.0.29 was really the last one that I was in charge of the networking.

One of the most fundamental questions to ask is what is your favorite editor!?

Joe. The first editor I really worked with was Wordstar, and Joe has Wordstar keys.

Have you ever been tempted over to FreeBSD or Windows?

Windows...no. If Linux had not been around then I would probably be using FreeBSD. It is a really technically excellent Operating System.

Do you enjoy the press attention?

I try to keep the journalists away...at shows I can't avoid them. At the show they hassle me, when I leave they don't, and thats fine.

KDE or GNOME?

Currently I run GNOME. Saying that, I run whatever I happen to prefer, it just happens that GNOME fits my desktop how I like it. I am not pro either of them. The reason I didn't use KDE because of the Qt non-free license, but now it's a free license it doesn't matter, so it's just a choice of one or the other.

[2000-06-14 ] Linux Today - Linux Journal An Interview with Alan Cox [Kernel Developer]

Linux Journal: How did you first learn about Linux? What were you doing in your own life at the time?

Alan Cox: I was hacking bits of ideas for my own OS and working on a MUD called AberMUD. I had pondered getting a decent PC, since the Amiga was getting a bit long in the tooth. 386BSD came out, and it looked like there was finally an OS worth running on x86 hardware. Linux came out around the same time, but didn't need an FPU, so I started running Linux.

LJ: What attracted you to it, compared to FreeBSD, proprietary Unix systems, or lucrative areas such as Windows? What made you want to help with development?

Alan: Linux was a lot easier to set up in the early days; MCC Linux and then SLS made it really easy to install by the standards of the time. I looked at the BSD systems, but I liked the way the GPL meant I was writing code that nobody could run off with. I didn't really chose not to hack 386BSD; I was just having too much fun with Linux to bother.

LJ: What part of Linux were you personally interested in and working on? How are you still involved with Linux development?

Alan: Initially, I was working on the networking code after Ross Biro stopped maintaining it, and Fred van Kempen basically dropped the mainstream code to rewrite it. I ended up maintaining the code and getting it going. Nowadays, I do the stable kernel releases and a fair bit of patch merging and debugging of drivers.

LJ: What was most important to you about Linux? What's the very best thing about Linux?

Alan: I think the most important thing about Linux is that it gives people the ability to do what they want. The "Penguin Powered" logos people love should really be "Penguin Empowered". That, I think, is the best thing about Linux, too. We've given the computer back to the user.

LJ: How important was the GNU project, and how did the GNU Hurd factor in to your thinking? Should Linux be known as GNU/Linux?

Alan: I knew about GNU several years before. In fact, in many ways, Linux exists because GNU chose to pursue the Hurd rather than using UZI as their Unix OS core, as they could have done. GNU/Linux is perhaps overstating it, but ignoring the FSF contribution is even worse. Richard has perhaps made a few enemies by insisting on GNU/Linux — but it does remind people.

It's really x11/BSD/GNU/....../Linux.

LJ: What was it like to be working with others over the Internet at a time when several computer luminaries thought that organizing successful software development over the Internet was difficult, if not impossible? Did you realize how revolutionary this approach was?

Alan: I don't think it was revolutionary. People had been doing it for a long time before that, a very long time. The modern Internet and large-scale access just made that project a bit easier — the lack of people and slow networks killed earlier equivalent projects like UZI and OMU, stopping them from spreading.

One thing Linux taught me: far too many people write about software design, but have never run a real-world computing business. The folks who seem to get software design right are mostly engineers. They want it to work, they want to solve the problem and they aren't totally obsessed by reusable components, object orientation, Java ... whatever the meme of the month is.

LJ: What are you doing with your life now? What's a typical day like? How do you find time for work and Linux, and how do you balance free software with the need to make a living (or the desire to become rich)? What do you do for fun?

Alan: I work for Red Hat. I work from home, hacking free software — it's great. It's been a bit busy, but I have a lot of fun when I'm visiting shows and abroad, both meeting the people and also getting to see other places. It isn't just the shows; I've visited the depths of Iceland with a bunch of mad 4x4 drivers, spent a week in a very snowy Vienna, and been to the Glengarry Highland games in Canada.

LJ: Who do you think other than Linus has had the most influence over the Linux community, and why?

Alan: Umm, that might be me, although I try not to. It really depends on which part of the community you mean, or even outside of the community ... People like Eric have had a big influence on business folks, which I certainly don't have.

LJ: What do you think is the most important addition or change needed by Linux in order for it to succeed further? In what direction does Linux development need to go? Where is Linux's future the brightest? What is the #1 biggest threat to Linux today?

Alan: Probably the biggest thing Linux needs now is better applications and user-space tools. We need to take Linux to the level where you can give it to your grandmother, and not expect a phone call back except to say "thanks". The biggest thing the kernel needs now is documentation.

I'm not sure what the threats to Linux really are. The biggest one is probably Linux fragmenting. I don't think that is going to happen in the mainstream, but we are already seeing a few vendors pulling that way in embedded space.

The app vendors and the users, I don't think, will tolerate a vendor going off at a tangent.

LJ: How do you feel about Linux's current popularity? Would you have preferred it stayed contained in the hacker community? Would it have survived on the fringes?

Alan: It was a bit of a surprise. On my first trip to Red Hat, they had about six people, and the new boy was this Donnie Barnes guy. Now they are heading for five hundred.

Linux would have survived on the fringes, I think. There has always been a market for things people can actually play with and tune.

LJ: Would it have survived without the IPOs and financial backing? What impact has the commercialization of Linux had? How do you feel about Linux profiteering and the people who make millions off of other people's volunteered efforts?

Alan: I'm working for a vendor. I get regular mail from people trying to find Linux-aware folks to hire. I think those who wrote code for fun have plenty of opportunity to reap rewards. Even when I wasn't working for Red Hat, it didn't bother me. I wrote it for fun, and the fact that people found it useful was a greater reward than money. We've made it possible to put computers into places that could never have afforded Microsoft products.

LJ: How can Linux compete with Microsoft in the desktop sector, and will we be able to hold the commercial sector if we don't take the desktop as well? Can we take the desktop without ruining the spirit of Linux by dumbing it down? Where will our next areas of growth and expansion be?

Alan: Trying to predict the desktop is hard. Firstly, I think it's safe to say that the PC desktop of today is probably the dinosaur of tomorrow. Most end users want simpler systems. They want to trade flexibility for ease of use, and power for size.

There will be plenty of people who choose the full PC, some because they enjoy it and some because they need all the power. Those, I suspect, are the minority.

The machines of tomorrow are mostly going to be web-oriented, or very mobile (or both). People will expect them to just work. Folks like Palm have taken the first stumbling steps in this direction, with huge success.

Linux is a good OS for building embedded systems with, and to be able to extensively customize. GNOME and KDE will give people a good battle on the desktop and beyond.

LJ: How do you feel about commercial applications being written for Linux, and proprietary software and protocols in general? Do you run Linux more for philosophical reasons or practical reasons? If something that appeared to be better came along, would people jump ship? Conversely, would we stay with Linux even if it somehow degenerated, took a wrong turn, or stopped progressing?

Alan: I don't believe open source works for everything. There are some cases where the ideas in the code truly have value, but not many. I don't currently use any proprietary software generally, except Netscape. And Mozilla is now within a hair's breadth of replacing that.

I like the flexibility and the control of free software. Most of my experiences with proprietary software have either been getting screwed as a user, or being part of a large company that h