> Algorithms for designing the kernel (for doing the actual design
> and stuff) vary from developer to developer, but most seem to
> involve staring, deep thought and lots of caffeine.
The algorithms I know about seem to be along the lines of the
following:
1. Read a dozen or so pages of source code looking for
whatever bug one is after. Drink several large mugs
of coffee whilst doing so.
2. Toss a coin. If heads, go to step 3; if tails, go to
step 4; if it lands on its edge, go to step 5.
3. Note a bug one wasn't looking for, and fix it. Go to
step 1.
4. Overlook the bug one was looking for. Go to step 1.
5. Have a brainwave, and go directly to the bug and fix
it, even though it was nowhere near the code one was
looking at. Go to step 1.
Put any timescale you care to against that lot.
> The "graduate student algorithm" should prove a sufficiently
> close approximation :)
The "GSA" is basically the above with step 3 omitted in my
experience.
Best wishes from Riley.
* Copyright (C) 1999, Memory Alpha Systems.
* All rights and wrongs reserved.
+----------------------------------------------------------------------+
| There is something frustrating about the quality and speed of Linux |
| development, ie., the quality is too high and the speed is too high, |
| in other words, I can implement this XXXX feature, but I bet someone |
| else has already done so and is just about to release their patch. |
+----------------------------------------------------------------------+
* http://www.memalpha.cx/Linux/Kernel/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/