Why Linux Is Not Attracting Young Developers 742
judeancodersfront writes "Jonathan Corbet recently pointed out at the Linux Foundation Collaboration Summit that the Linux kernel team was getting older and not attracting young developers. This article suggests the Linux kernel no longer has the same appeal to young open source developers that it did 10 years ago. Could it be that the massive code base and declining sense of community from corporate involvement has driven young open source programmers elsewhere?"
Re:bad attitudes (Score:1, Informative)
I've tried to get involved in the development of the kernel and been hounded out because I asked questions.
What sort of development community is it if you can't ask someone who's written a section of code "What does this function do?"
Re:reverence and awe (Score:1, Informative)
The 2.6 kernel contains approximately 4 million lines of code.
The real work needed isn't in the kernel. (Score:2, Informative)
BUT recently, I was trying to get someone's computer up and running, and Linux was the only thing that would install due to some bug or other, so I temporarily put an Ubuntu install on their computer. Decided it would be a nice experiment for a non power user, to see how well they could cope.
He hated it. He couldn't get flash going, so it wouldn't work with certain sites. He was having trouble doing basic navigation of the OS, and had no idea which programs really did what beyond the basic.
There were a host of other issues I can't really remember now, but it was a very frustrating experience for him, and he was very happy when he got his Windows 7 back.
I sat him down with my macbook and he seemed to figure out OSX handily.
The Kernel works well. The OS handles many things very well internally, but the overall user experience, while MUCH MUCH improved over how things used to be, just is not as easy to use as a Mac or Windows computer.
The real work needs to be done by UI designers with coders to support them. Even connecting to a wireless network can be a chore. God forbid a driver doesn't work or something along those lines and you need to open a terminal.
While you'd think the 'many eyeballs' thing would take care of something like that, it seems all these eyeballs and the heads behind them just want their OS to work, and for a non power user right now, I wouldn't call it ready.
Re:Monolithic Kernel = Death of Self-Teaching (Score:5, Informative)
...the thing has gotten so big now [what is it - like 20,000 files which get compiled in the basic kernel?]
But that's counting each and every file system, each and every architecture and most significantly each and every hardware driver. The amount of code you need to understand to be able to, for instance, write a new network driver, is substantially less than the totality of the Linux kernel source.
Out of ~25k *.[ch] files I count ~9k in drivers alone, plus ~1k in sound. There's ~1.5k in fs and kernel has ~200. Although arch has ~10k only ~700 of those are for x86. Yes, this is a very rough and ready, not to mention incomplete, set of figures, but you get the idea.
Re:older developers... (Score:3, Informative)
Oops, meant to say "bug free binary SEARCH." Though a good hire should be able to knock off a conceptually correct quicksort or heapsort in 20 minutes or so.
Re:Monolithic Kernel = Death of Self-Teaching (Score:5, Informative)
It's true that there are ~30,000 files in the Linux kernel, but 25,000 of those are either driver code or architecture specific code, so if you only care about the x86 and aren't interested in drivers, you really only have 6,000 files you need to worry about. If you are interested in a specific part of the kernel, it is even easier: for example, if you are only interested in the ext3 filesystem, that's around 160 files. Which is very manageable.
Re:reverence and awe (Score:5, Informative)
It's a lot less indimitating than it sounds.
that 4 million lines is spread across about 22 different architectures, a couple dozen file systems, and thousands of device drivers. The actual amount of that which one needs to understand to work on something is vastly smaller.
Re:older developers... (Score:3, Informative)
Re:older developers... (Score:4, Informative)
You certainly can teach students how to create various data structures in python, however I expect the general response from the students would be very poor. It seems somewhat silly to have students implement things that a language natively supports. You're likely to get many "why do I have to reimplement this if python already supports it" type complaints.
I did however read the comment I was replying to as "why should we need to learn things in Data Structures that python can already do". Perhaps I misread it.
Really though, a good class would be completely language agnostic. In my data structures class the professor demonstrated concepts with Pascal, but expected assignments to be completed using either C, C++, or python, at the student's discretion. Most students opted to use C.
Re:Why? Because it's no fun (Score:3, Informative)
WDM does divide drivers into class drivers that handle the common device functionality. You then can develop minidrivers or filter drivers which provide device specific functionality. This creates a set of generic driver classes and sort of controls the types of drivers you can create, but you aren't restricted from creating monolithic or legacy drivers which don't fall under the that model. I'm sure about WDF, it may be more standardized.
I do agree that WHQL is a good thing and probably catches a large amount of buggy drivers. Microsoft also includes the verifier.exe tool with Windows which you can use to perform the same tests as WHQL.
Statistics can be (ab)used to lie (Score:2, Informative)