Contribute to Linux(kernel)

[Dario]

I have been staring at the Linux code for quite some time and I'm 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, I'm starting to think...why not get my self involved more deeply...writing device drivers or tuning code for embedded devices...maybe even after some time and gained experience, hacking some subsystem...I don't know...the code base is huge and it's far more challenging to get your self involved today then it was 20 years ago, but still...It's a dream job for me...to get paid for "real" programming. And there are many jobs opened for kernel engineers now that Linux is popular platform for embedded devices and data centers. For example, Chris Mason, an engineer working on BTRFS at Oracle...great guy:
http://www.youtube.com/watch?v=oSgGVX2CGOQ
it would be wonderful to learn and collaborate with such a people.

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

[OSwhatever]

Most of the people writing in this forum are people who design kernels from scratch, either using well known paradigms, new ones or a mix. In this case the Linux kernel isn't satisfying since it is already more or less already written and people tends to lean more towards experimental kernels here.

You see a lot of job ads out there where they seek "Linux kernel developers", but in reality I don't think it is much kernel development but rather adapting the kernel to a system and drivers. I would find that job pretty much a vanilla software engineer job, not bad but not exciting.

[Dario]

I am personally not inclined to dive into half-amateurish half-serverish code of Linux kernel, not to mention that I despise GPL and would rather work on BSD kernel any time.

Statements about GPL I will ignore since it's not the subject here. BSD vs. Linux also.
And the part about "amaterusih code", well I will have to accept that all these guys working at Intel, IBM, Oracle, Siemens...are, well... amateurs.

[Thomas]

Hi Dairo,

I work on a similar job. But not Linux. I do not do much development but big fixing. I am a maintenance engineer. I am sorry I cannot share the actual problems I solved. But it's a head scratching job, problems are generally not reproducible . It takes a lot of time to debug. I spend more thing debugging than actually coding something. Coding/Development is not a big deal once you isolate the problem.

--Thomas

[Dario]

Most of the people writing in this forum are people who design kernels from scratch, either using well known paradigms, new ones or a mix. In this case the Linux kernel isn't satisfying since it is already more or less already written and people tends to lean more towards experimental kernels here.

Yeah, well I was talking about the fellows who _would_ like to make a living out of system programming.

You see a lot of job ads out there where they seek "Linux kernel developers", but in reality I don't think it is much kernel development but rather adapting the kernel to a system and drivers. I would find that job pretty much a vanilla software engineer job, not bad but not exciting.

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?

[Dario]

Hi Dairo,
I work on a similar job. But not Linux. I do not do much development but big fixing. I am a maintenance engineer. I am sorry I cannot share the actual problems I solved. But it's a head scratching job, problems are generally not reproducible . It takes a lot of time to debug. I spend more thing debugging than actually coding something.

Sounds painful. Thank you for sharing the experience. I need them since I'm on the cross road here. Only one year left in college and I'm not sure whether to push things more towards these kind of jobs which I find very interesting or should I spend time to get my self more professional in user space programming(read business applications->C#, Java ) or system, network administration.

Coding/Development is not a big deal once you isolate the problem.

I agree. But that should be the fun part. Although, I guess it largely depends on the project you are working in.

[Thomas]

Hi,
The decision about your career path solely depends on you. You need to find out what you like the best , From my side - i enjoy what I am doing for the most part. I had to sacrifice many things to do what I like, ultimately it makes you a little more happier. In any job, there are lot of things you can learn and certain things you will learn only when you do it, not from university.

At any rate do not make the mistake of treating any or job anything with pessimism as I did initially. Make the most of any situation you are in where ever you are.

Wishing you all the best
--Thomas

[Solar]

Maintenance coding - i.e., isolating / fixing bugs, and improving an already-existing system - can be a rewarding and fulfilling job. But it is very different from the job that is developing a new software.

The maintenance coder is facing a given architecture, and usually is on a budget too tight to make sweeping changes. You have to cope with varying code styles, underdocumented source and the general mess that is usually left behind when developers are pressed into a time / budget schedule. On the upper hand, you are usually the one fixing the problems, not the one introducing them.

The developer, in contrast, is usually given a starting point, a goal, and a schedule. While you are not exactly free to do "whatever you want" (because there are team members, company policies, and software architects to be considered), you are building, not maintaining. On the downside, if your concept doesn't work out, the deadline draws closer, and you have to get it working, things can become... interesting.

Both jobs can be great, or living hell. It depends on the environment. A good team, a boss who understands the craft, and customers who know what they want and can cope with a "no" make for a nice experience, no matter if it's maintenance or development. But a crap team, a boss who doesn't listen or believes that yelling makes right, and customers who think software is done in an assembly line, can make either an ordeal.

Maintenance work also pivots on the quality of the code base, and the people who could give you a helping hand (or leave you hanging out to dry). That being said, I personally wouldn't touch the Linux kernel with a ten-foot pole.

[Solar]

Statements about GPL I will ignore since it's not the subject here. BSD vs. Linux also.

Granted. But it is important what your software is being used for. While you can ignore it for the better part of your working day, it still matters for that "gut" feeling. Which becomes more and more important over the years.

My last job was a software that helped a major bank managing its investment risks. (Not good enough, obviously, but that's another story. )

Today I work on a software that is mainly used in postal advertising.

It does make a difference.

And the part about "amaterusih code", well I will have to accept that all these guys working at Intel, IBM, Oracle, Siemens...are, well... amateurs.

Big names don't make competence.

[Dario]

Both jobs can be great, or living hell. It depends on the environment. A good team, a boss who understands the craft, and customers who know what they want and can cope with a "no" make for a nice experience, no matter if it's maintenance or development. But a crap team, a boss who doesn't listen or believes that yelling makes right, and customers who think software is done in an assembly line, can make either an ordeal.

That is very critical for me. I'm not materialist and I would always prefer more "scientific" environment with good team, people you can learn from over any well paid job with primitive social environment.

[Dario]

Granted. But it is important what your software is being used for. While you can ignore it for the better part of your working day, it still matters for that "gut" feeling. Which becomes more and more important over the years

.

Not sure what is your point here...how does this relate to e.g. Linux?

Big names don't make competence.

Agree, but what does? Does academia? Anonymous hackers?
Obviously, someone who works as kernel engineer(for any OS) at BIG_Name_Company will be more respectable then the guy who just got out of the university.
And what is so ugly and evil in the kernel that you wouldn't touch with a ten-foot pole?
I have seen some "badly" written drivers, but these were mostly from OEM's that decided to throw the code into the mainline kernel, or if they were backward engineered.

[Dario]

Hi,
I had to sacrifice many things to do what I like, ultimately it makes you a little more happier.

Yeah, I'm aware of that...to make any progress in understanding and actually implement something useful in Linux source code, requires long time commitment and sacrifice. Mine would be even greater since it requires from me to move out of the country.

In any job, there are lot of things you can learn and certain things you will learn only when you do it, not from university.

That is especially true in IT. While university does provide you with "basic" knowledge (here basic means a very large and complex field), IT ind. requires a lot experience in some specific technology....and most of them I find really boring.

[Solar]

Granted. But it is important what your software is being used for. While you can ignore it for the better part of your working day, it still matters for that "gut" feeling. Which becomes more and more important over the years

.

Not sure what is your point here...how does this relate to e.g. Linux?

I do not like it as an operating system. I do not like what it came to stand for. I do not like the philosophy behind the GPL. I do not like the philosophy about the non-stable kernel driver API. I do not like it when people spread FUD on things they don't understand (re C++ and the LKML FAQ). I do not like how several high-profile Linux characters approach things. I could easily fill a small book with things I don't like about Linux, and probably would if less people had been brainwashed into believing that Linux is "The Good Guys".

Big names don't make competence.

Agree, but what does? Does academia? Anonymous hackers?

Competence makes competence. You will find competence and incompetence alike in small garage companies and big-business megacorps alike. You don't find out until you talked to them and worked with them. That's why job interviews and probation periods swing both ways.

Obviously, someone who works as kernel engineer(for any OS) at BIG_Name_Company will be more respectable then the guy who just got out of the university.

Will he?

I don't have a university degree myself. My formal training consists of a employment-office-funded, 18-month occupational redeployment after I stopped studying towards a teacher's certification in Biology and Sports.

If I would give someone with a diploma and a flashy business card some kind of advance credit, I probably would not be where I am today. I judge people by deeds, and expect to be judged likewise.

[Dario]

I do not like it as an operating system. I do not like what it came to stand for. I do not like the philosophy behind the GPL. I do not like the philosophy about the non-stable kernel driver API. I do not like it when people spread FUD on things they don't understand (re C++ and the LKML FAQ). I do not like how several high-profile Linux characters approach things. I could easily fill a small book with things I don't like about Linux, and probably would if less people had been brainwashed into believing that Linux is "The Good Guys".

OK, so your problem with Linux is it's social aspect and some others...so it's personal.
About C++ and Linus....I think that was something about GIT, not Linux...but no matter what, it still is his personal opinion. I don't have to necessary agree with it, nor do I admire Linus. It's a huge project so one should expect the variety of opinions and primitive attacks.
Anyway, I see Linux only as open technology which is being widespreaded and there for more approachable then any other(AFAIK).
But we are going offtopic here..

Competence makes competence. You will find competence and incompetence alike in small garage companies and big-business megacorps alike. You don't find out until you talked to them and worked with them. That's why job interviews and probation periods swing both ways.

Yes, it's relative.

If I would give someone with a diploma and a flashy business card some kind of advance credit, I probably would not be where I am today. I judge people by deeds, and expect to be judged likewise.

You know...different people tell me different things concerning this subject. I can only conclude that it depends on many factors...mostly the type of job. In general I agree with you. But again...way off topic.

[Solar]

OK, so your problem with Linux is it's social aspect and some others...so it's personal.

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.

Anyway, I see Linux only as open technology which is being widespreaded and there for more approachable then any other(AFAIK).

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

But we are going offtopic here..

Not really, but neither are we getting anywhere.

(*): As defined by Mr. Stalman
(**): As defined by the general populace