[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <64884922-4254-4827-9A9F-09053043B8E6@mac.com>
Date: Thu, 29 Mar 2007 18:54:33 -0400
From: Kyle Moffett <mrmacman_g4@....com>
To: "Ahmed S. Darwish" <darwish.07@...il.com>
Cc: Cong WANG <xiyou.wangcong@...il.com>,
Russ Meyerriecks <datachomper@...il.com>,
linux-kernel@...r.kernel.org,
Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: Student Project Ideas
On Mar 29, 2007, at 16:59:36, Ahmed S. Darwish wrote:
> On Thu, Mar 29, 2007 at 06:32:21PM +0800, Cong WANG wrote:
>> Second, in fact, I am also a college student and also want to find
>> a suitable and real task in linux kernel for me to work on. KJ
>> doesn't help much. ;-p
>
> No, it really helps alot, just be _patient_. For me, I sent a
> series of dumb patches at first to use ARRAY_SIZE macro instead of
> manual computation. Though the patches were completely braindead, I
> learnt alot of stuff about how everything works here.
One thing that I think is fairly non-obvious to newcomers is that
Linux kernel development is not done at all the way they teach you in
your Large Scale Software Engineering classes. Many of those classes
talk much about careful design (whether top-down, bottom-up, outside-
in, waterfall, spiral, $BUZZWORD_OF_THE_DAY) and detailed unit-
testing, whereas Linux kernel development isn't really "designed" at
all.
Linux is all about evolution: Somebody comes up with a design they
like and talk about it on LKML, lots of knowledgeable people put in
input, the design is reworked, repeat. After a few discussion emails
(or none at all for small projects), somebody just sits down and
codes the damn thing. In a business nobody does any code till they
have the design finalized, the managers consider the extra coding a
waste of man-hours, whereas in Linux the whole design process centers
around writing many subtly different versions of the same thing until
everybody agrees that it looks right.
Then it gets pulled into Andrew Mortons tree and promptly breaks all
over the place because people try things you didn't expect. You then
get the opportunity to recode half the thing all over again to fix
the newly discovered deficiencies. Repeat several times.
After a while it stops crashing peoples boxes and goes into Linus
tree, but at that point your job is only half done. Now you have to
maintain the feature, add patches, improve functionality, and
continue to be active in the community.
Large college end-of-study projects are single-person activities,
they want to test _your_ knowledge. On the other hand Linux kernel
development is a community exercise, it's trying to use the knowledge
of thousands to build the best kernel possible. If you can get
approval to use the bits of code that many others contribute then
more power to you.
The other thing to realize about Linux is that it is NOT a "hobbyist"
OS any more, there are some extremely mission-critical Linux systems
out in the world which depend on the code quality and efficiency.
There are few people indeed who can really efficiently increase the
performance of the Linux schedular or other core subsystems. Kudos
to Linus Torvalds, Ingo Molnar, Con Kolivas, Andrew Morton, and
others too numerous to list for their incredible skill and dedication.
So while it's entirely possible to do innovative dissertation work on
the Linux kernel with your own private source tree, don't expect to
go from a cold standing start to having a big project in the upstream
kernel without investing twice as much time as it was to do the
dissertation in the first place. That's not to say that you can't
always get advice from many others on this mailing list during the
process, though.
Cheers,
Kyle Moffett
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists