Torvalds Says It's No Picnic To Become Major Linux Coder

Jack Spine writes "Linus Torvalds has given an interview to ZDNet.co.uk about the trials and tribulations of becoming a Linux kernel developer. 'Torvalds said that, while it is relatively easy for coders and organisations to contribute small patches, the contribution of large patches, developed in isolation, could lead to both new and established contributors becoming frustrated. "It's definitely not easy to become a 'big contributor'," wrote Torvalds. "For one thing, the kernel is quite complex and big, and it inevitably simply takes time to learn all the rules — not just for the code, but for how the whole development environment works. Similarly, for a new developer, it will take time before people start recognising the name and start trusting the developer to do the right things.""

Comments

Re:This goes for every OS/FOSS project out there.

[houghi]

I am sure this goes for closed source as well. If the rookie comes in, he will also have to prove himself. The same goes for every other aspect in life.

If are new into a group, it is to be expected that you have to prove yourself. Whether this is with your local gang, a family you are married into or a bunch of coders is irrelevant.

Even Neo had to prove himself first. Each group will have its own rules and speed of how fast you are accepted. A group of drunk people in a bar might have a lower standard, but if you do not fit in, they will not accept you and will not listen to your sugestions, no matter how wise they are. (Stop drinking? Why? This is FREE BEER)

Re:Andy's revenge

[0xABADC0DA]

Seriously though, the problem with microkernels is that they (in theory) help the system cope with mistakes but they don't help prevent mistakes in the first place. Each component in a microkernel is isolated from others using memory protection, but they can still corrupt themselves or crash themselves.

There's very few parts of the kernel that actually need pointer arithmetic, unsafe casts, or for that matter need to operate particularly quickly. You don't have to believe me just look at the code. Open up some random source files from the kernel and look for pointer math, unsafe casts. Figuring out what locks are held when is harder, but can be done (performance being more important when locks are held).

Microkernels are solving the wrong problem. They should be focussed on preventing the errors in the first place not on recovering from them. So, a 'safe kernel' that is mostly written in a language that prevents errors, such as Limbo/Dis or for that matter Java or C#. That would be much easier to work on and an improvement over Linux style kernels.