Contribute to Linux(kernel)

[Dario]

Competent developers are not a majority. Not only in Linux kernel but everywhere.

I don't know how experienced you are, but from my POV I cannot make that statement.

Linux is hip and this is why it attracts attention of many wannabees

at some point, we were all wannbees.

consequently reducing the code quality and moving the issue more into community management rather than purely technical skill.

I haven't seen the statistic for quite some time, but if I remember correctly anonymous coders are by far the smallest group, but that doesn't mean they are less skilled then some one else. I think that Linux was crappy long time ago...so trend is quite opposite.
The bolded part...not sure what you mean...if it's community there for it's not pure technical skill?

If you want to get a hang of Linux kernel development, subscribe to LKML and follow it closely for a while.

LKML is _not_ a good source to learn Linux, nor do I want to bother these guys with noob questions. That being said, they do have KNML, but my sources so far were R.Love's Linux Kernel Development, J.Cobert and Greg's book "Linux Device Drivers", some others and of course, code peeking. But still, far for me to do anything serious.

[Dario]

The social / personal aspect is part of it. But I don't see where the license, driver architecture and general architectural direction could be constructed as "personal" problem.

Unstable driver API is the consequence of fast changing code and the nature of Linux. It does have it's drawbacks, but so do other approaches. Still not the reason why one should _hate_ linux with such a passion. Also, plenty(majority) of drivers are wirtten for user space and as far as I'm tracking things...it's pretty stable. For the kernel part, Greg K.Hartman had a good explaination and is far more adequate then I am. I think it might be somewhere in /Documentation dir.
General arhitecture...you have to be more specific, but same as the above...has it's prons and cons.

No, Linux is not "open", Linux is GPL, and thus "free"(*). Which, funny enough, is much less free(**) than "open" is.

Yes, you're right, I made classical mistake of equilazing free and open. I don't agree with second part though and won't discuss further since that(free vs open vs commercial) doesn't interest me.

Cheers!

[Combuster]

And here's the point where I originally created the "no linux debates" forum rule:

There's no hate but knowledge it could be done (much) better.
There's no truth but facts.
Stallman is for all intents and purposes a religion.
There is no spoon.

[OSwhatever]

That still is kernel development. If you refer to the core kernel as a definition of kernel development then that will always be the part which will not change as rapidly as some subsystems, drivers/modules...although the rate of change is flat across the whole kernel. What is so good about writing drivers, subsystem is that you get the chance to work with people from other fields of industry like hardware/logic design. And that is always a good "starting" point from which you can go to any other field of kernel development...not just the kernel, but maybe compilers, etc.
Anyway, what is you definition of exciting kernel space programming?

I don't consider driver development kernel development at all, even if the driver reside in kernel space. Kernel development is when you design solution in the kernel. The basic purpose of an operating system is handling resources, when you design solutions handling those resources, that is kernel development.

If you look at many interesting kernels around, mach, BSD, L4 and many more you notice that they actually all come from the university institutions. Larger companies like Microsoft also invest a lot in kernel development. Smaller companies usually don't do this because they don't have the time and money, they just use some off the shelf kernel. Doing research in an institution can be really fun and rewarding. The down side is that the pay is usually very bad and the university is very narrow. People in institutions seems to defend their positions with any weapon available as a result of the funding issue.

If you want to design kernels as a job, I think they are quite rare and you often have to compromize on something (money for example). If you do I think you're lucky.

I find it quite boring that Linux has almost taken over in the embedded space. It's like if you're an ice cream enthusiast and vanilla was competing out every other flavour. Linux has the benefit for many companies that it is free, many geeks has tinkered with it, those geeks are now in management positions, Linux runs on many different architectures compared to other kernels. I can see the benefit of Linux, but for me it is boring.

[Dario]

I don't consider driver development kernel development at all, even if the driver reside in kernel space. Kernel development is when you design solution in the kernel. The basic purpose of an operating system is handling resources, when you design solutions handling those resources, that is kernel development.

I can partially agree with you since driver is mechanism which handles some specific resource(hardware).
Also, I don't think that writing a driver for chinese web cam is as lovely expirience as writing driver for..graphics card.
Finding a job where they need a fellow to rewrite a scheduler or mm is unlikley to happen. But drivers are, as I said before, a good starting point.

If you look at many interesting kernels around, mach, BSD, L4 and many more you notice that they actually all come from the university institutions.

At that time, they couldn't come from nowhere else. Linus admitted, if he didn't wrote and gave Linux for free, some one else would.

If you want to design kernels as a job, I think they are quite rare and you often have to compromize on something (money for example). If you do I think you're lucky.

That's why I think that Linux is the only choice.
http://linuxkernel.specialtyjobmarkets. ... licRecords

[Dario]

So from the

starting to make some sense out of that "mess"(early kernel code(x86), generic code->higher half of the kernel, not sub systems). Although I am aware that there's much more to learn

camp you moved to be a strong Linux advocate?

Let's not put any labels yet.
And if I really were a "strong Linux advocate"...why would that be so wrong? I know it's cool thing to say: "hey Linux suck just because I think that I'm competent enough to say so", but still...
Anyway, don't label me, I'm here for technical reasons and having big interests in Linux and these are not of any mental nature.
Now the "mess" part...I should have said "spaghetti", meaning "complex", especially for the newcomers like me.

Cheers!

[Dario]

Anyway, don't label me, I'm here for technical reasons and having big interests in Linux and these are not of any mental nature.

That's what worried me, you basically just advocating linux in this thread instead of discussing it's technical merits/drawbacks.

I am? Quote me then.
Also note, "technical merits/drawbacks" is not the subject here, so I think that you see this thread as Linux evangelisation only because you don't like Linux as you stated in your first post. And that's cool, but don't put words in my mouth.

[NickJohnson]

So, what about you guys...have you ever considered such a challenge?

"technical merits/drawbacks" is not the subject here

Then what is? You asked whether we would like to work on Linux, and those who answered no (which was all of them) simply gave their reasoning, which was mostly technical. You really can't disagree with opinions that you asked for, and since you did, you must care more about imparting your beliefs than getting a consensus or gaining knowledge. I'm not saying that you're wrong or that you're the only source of argument in this thread, but you are the one being inconsistent.

[Dario]

So, what about you guys...have you ever considered such a challenge?

"technical merits/drawbacks" is not the subject here

Then what is? You asked whether we would like to work on Linux, and those who answered no (which was all of them) simply gave their reasoning, which was mostly technical. You really can't disagree with opinions that you asked for, and since you did, you must care more about imparting your beliefs than getting a consensus or gaining knowledge. I'm not saying that you're wrong or that you're the only source of argument in this thread, but you are the one being inconsistent.

Again, quote me on any of my "beliefs". In fact, if you read my posts again, you will see that I refused to discuss them. I was trying to see whether any you guys have tendency towards such jobs. And when I was asked about some certain technological aspect of Linux I kindly gave an answer and then someone labeled me as Linux advocate. Nonsense! None of this would have happened if I agreed with everything you said.
Thomas gave me some really useful answers like what are the benefits and drawbacks of such jobs. I was hoping that far more experienced people then I am would give me some directions and was not expecting flamewars.
But since that obviously won't happen then this thread is mature for lock.