The Kernel Newbies Crash Course LKD4 Challenge! Play along at home!
In the spirit of the Eudyptula Challenge, we here at the Crash Course Linux Training Centre and Craft Gin Appreciation Institute introduce the LKD4 Challenge. Everyone can play ... fun for the whole family, ages 6 and up. Seriously, though, if you're looking for something to put your Linux kernel understanding to work with a challenge you probably can't get kicked out of, here's a suggestion. It's sort of explained here: http://www.crashcourse.ca/wiki/index.php/Updates_to_LKD3 although it's been a while since I've added anything to that page so I probably need to do a bit of updating and restructuring, but here's the short version. There are frequent references on this list to the standard books that any kernel newbie should have (along with their common acronyms for brevity): * LKD3: Linux Kernel Development (3rd ed), by Robert Love * LDD3: Linux Device Drivers (3rd ed), by Corbet et al * ELDD: Essential Linux Device Drivers, by Venkateswaran Sad part is that at least the first two of those books are starting to show their age -- I should know about LKD3, I was the technical editor. Yes, you can look inside at the masthead and that's me. Now, there is absolutely *no* schedule for an LKD4 (yet), but it doesn't hurt to look ahead and prepare for it if it happens. It's possible I might tech edit that next edition but, even if not, it doesen't hurt to prepare for it, which is why I started that wiki page; to start keeping track of everything that would need to be updated. If you want to play along, the rules are pretty simple (actually, the rules are non-existent, you just have to want to participate). First, you need a copy of LKD3. And, second, you just need to figure out what needs updating. That's about it. This doesn't require a massive investment of time -- you don't need to tackle entire sections or chapters at once. An update could represent something as simple as a change to a single line or single paragraph, an update to a filename, a revision to a listed snippet of code or what have you. You also don't need to try to deal with the whole book -- just pick the part of the Linux kernel that most interests you and work on that. As for what constitutes reporting an "update", it's pretty flexible but it's always best if you try to be complete and provide as much context as possible. As a hypothetical example, say a listed structure in LKD3 has changed since publication -- then that's something that should be reported as an update. But don't stop there. Figure out *why* it changed, perhaps identify the Git commit where it happened, investigate what else might have been affected by the same commit, and so on. Other things to be reported would naturally include: * new features added since publication * entire subsystems deleted since publication * suggestions for topics that should be covered in more detail It's all very open-ended -- just a totally *unofficial* project to update LKD3. Finally, while that's a wiki page, I'm reluctant to make it world-writable given the immediate infestation of spammers, so people are free to just email me, and I can add their stuff and give them credit if they want. It's all in good fun and, in the end, the goal is to improve the content. Questions? rday -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ========================================================================
2014-09-20 8:24 GMT-05:00 Robert P. J. Day <rpjday@crashcourse.ca>:
In the spirit of the Eudyptula Challenge, we here at the Crash Course Linux Training Centre and Craft Gin Appreciation Institute introduce the LKD4 Challenge. Everyone can play ... fun for the whole family, ages 6 and up.
Seriously, though, if you're looking for something to put your Linux kernel understanding to work with a challenge you probably can't get kicked out of, here's a suggestion.
It's sort of explained here:
http://www.crashcourse.ca/wiki/index.php/Updates_to_LKD3
although it's been a while since I've added anything to that page so I probably need to do a bit of updating and restructuring, but here's the short version.
There are frequent references on this list to the standard books that any kernel newbie should have (along with their common acronyms for brevity):
* LKD3: Linux Kernel Development (3rd ed), by Robert Love * LDD3: Linux Device Drivers (3rd ed), by Corbet et al * ELDD: Essential Linux Device Drivers, by Venkateswaran
Sad part is that at least the first two of those books are starting to show their age -- I should know about LKD3, I was the technical editor. Yes, you can look inside at the masthead and that's me.
Now, there is absolutely *no* schedule for an LKD4 (yet), but it doesn't hurt to look ahead and prepare for it if it happens. It's possible I might tech edit that next edition but, even if not, it doesen't hurt to prepare for it, which is why I started that wiki page; to start keeping track of everything that would need to be updated.
If you want to play along, the rules are pretty simple (actually, the rules are non-existent, you just have to want to participate). First, you need a copy of LKD3. And, second, you just need to figure out what needs updating. That's about it.
This doesn't require a massive investment of time -- you don't need to tackle entire sections or chapters at once. An update could represent something as simple as a change to a single line or single paragraph, an update to a filename, a revision to a listed snippet of code or what have you.
You also don't need to try to deal with the whole book -- just pick the part of the Linux kernel that most interests you and work on that. As for what constitutes reporting an "update", it's pretty flexible but it's always best if you try to be complete and provide as much context as possible.
As a hypothetical example, say a listed structure in LKD3 has changed since publication -- then that's something that should be reported as an update. But don't stop there. Figure out *why* it changed, perhaps identify the Git commit where it happened, investigate what else might have been affected by the same commit, and so on.
Other things to be reported would naturally include:
* new features added since publication * entire subsystems deleted since publication * suggestions for topics that should be covered in more detail
It's all very open-ended -- just a totally *unofficial* project to update LKD3.
Finally, while that's a wiki page, I'm reluctant to make it world-writable given the immediate infestation of spammers, so people are free to just email me, and I can add their stuff and give them credit if they want. It's all in good fun and, in the end, the goal is to improve the content.
Questions?
rday
--
======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca
Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ========================================================================
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Hi Robert, So at this moment the idea is just update the topics as they are currently covered in LDD3 without going any further? I mean, the suggestions for topics to be covered in more detail will be considered by you as a "wish list" or can we also try to start writing down those details? Best regards -- Gustavo Silva Embedded Software Engineer silvagustavo@users.sourceforge.net <silvagusta@users.sourceforge.net>
2014-09-20 14:59 GMT-05:00 Gustavo Silva <silvagustavosilva@gmail.com>:
2014-09-20 8:24 GMT-05:00 Robert P. J. Day <rpjday@crashcourse.ca>:
In the spirit of the Eudyptula Challenge, we here at the Crash Course Linux Training Centre and Craft Gin Appreciation Institute introduce the LKD4 Challenge. Everyone can play ... fun for the whole family, ages 6 and up.
Seriously, though, if you're looking for something to put your Linux kernel understanding to work with a challenge you probably can't get kicked out of, here's a suggestion.
It's sort of explained here:
http://www.crashcourse.ca/wiki/index.php/Updates_to_LKD3
although it's been a while since I've added anything to that page so I probably need to do a bit of updating and restructuring, but here's the short version.
There are frequent references on this list to the standard books that any kernel newbie should have (along with their common acronyms for brevity):
* LKD3: Linux Kernel Development (3rd ed), by Robert Love * LDD3: Linux Device Drivers (3rd ed), by Corbet et al * ELDD: Essential Linux Device Drivers, by Venkateswaran
Sad part is that at least the first two of those books are starting to show their age -- I should know about LKD3, I was the technical editor. Yes, you can look inside at the masthead and that's me.
Now, there is absolutely *no* schedule for an LKD4 (yet), but it doesn't hurt to look ahead and prepare for it if it happens. It's possible I might tech edit that next edition but, even if not, it doesen't hurt to prepare for it, which is why I started that wiki page; to start keeping track of everything that would need to be updated.
If you want to play along, the rules are pretty simple (actually, the rules are non-existent, you just have to want to participate). First, you need a copy of LKD3. And, second, you just need to figure out what needs updating. That's about it.
This doesn't require a massive investment of time -- you don't need to tackle entire sections or chapters at once. An update could represent something as simple as a change to a single line or single paragraph, an update to a filename, a revision to a listed snippet of code or what have you.
You also don't need to try to deal with the whole book -- just pick the part of the Linux kernel that most interests you and work on that. As for what constitutes reporting an "update", it's pretty flexible but it's always best if you try to be complete and provide as much context as possible.
As a hypothetical example, say a listed structure in LKD3 has changed since publication -- then that's something that should be reported as an update. But don't stop there. Figure out *why* it changed, perhaps identify the Git commit where it happened, investigate what else might have been affected by the same commit, and so on.
Other things to be reported would naturally include:
* new features added since publication * entire subsystems deleted since publication * suggestions for topics that should be covered in more detail
It's all very open-ended -- just a totally *unofficial* project to update LKD3.
Finally, while that's a wiki page, I'm reluctant to make it world-writable given the immediate infestation of spammers, so people are free to just email me, and I can add their stuff and give them credit if they want. It's all in good fun and, in the end, the goal is to improve the content.
Questions?
rday
--
======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca
Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ========================================================================
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Hi Robert,
So at this moment the idea is just update the topics as they are currently covered in LDD3 without going any further? I mean, the suggestions for topics to be covered in more detail will be considered by you as a "wish list" or can we also try to start writing down those details?
Best regards
-- Gustavo Silva Embedded Software Engineer silvagustavo@users.sourceforge.net <silvagusta@users.sourceforge.net>
Sorry, typo correction: LKD3 Best regards -- Gustavo Silva
On Sat, 20 Sep 2014, Gustavo Silva wrote:
Hi Robert,
So at this moment the idea is just update the topics as they are currently covered in LDD3 without going any further?
"LKD3", not "LDD3". two very different books.
I mean, the suggestions for topics to be covered in more detail will be considered by you as a "wish list" or can we also try to start writing down those details?
the "challenge" is simply to review "Linux Kernel Development (3rd ed)" by robert love, and identify *anything* that needs to be updated for the (hypothetical) LKD4. there are no hard and fast rules ... you can peruse LKD3 and make note of *anything* that needs to be updated with respect to the current version of the kernel. eventually, there *might* be an LKD4, and if there is, it will make it a much better book if numerous people have already identified (in detail) the parts that need to be updated. so take on the challenge, pick the parts of the book that interest you most, and let me know what needs fixing, and i'll keep track of it all, and when/if LKD4 comes out, it will be a much better book because of everyone's efforts. rday -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ========================================================================
2014-09-20 15:12 GMT-05:00 Robert P. J. Day <rpjday@crashcourse.ca>:
On Sat, 20 Sep 2014, Gustavo Silva wrote:
Hi Robert,
So at this moment the idea is just update the topics as they are currently covered in LDD3 without going any further?
"LKD3", not "LDD3". two very different books.
Yep, you are right, it was a typo.
I mean, the suggestions for topics to be covered in more detail will be considered by you as a "wish list" or can we also try to start writing down those details?
the "challenge" is simply to review "Linux Kernel Development (3rd ed)" by robert love, and identify *anything* that needs to be updated for the (hypothetical) LKD4. there are no hard and fast rules ... you can peruse LKD3 and make note of *anything* that needs to be updated with respect to the current version of the kernel.
eventually, there *might* be an LKD4, and if there is, it will make it a much better book if numerous people have already identified (in detail) the parts that need to be updated.
so take on the challenge, pick the parts of the book that interest you most, and let me know what needs fixing, and i'll keep track of it all, and when/if LKD4 comes out, it will be a much better book because of everyone's efforts.
OK, I got it, thanks for the clarification.
rday
--
======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca
Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ========================================================================
Best regards -- Gustavo Silva Embedded Software Engineer silvagustavo@users.sourceforge.net <silvagusta@users.sourceforge.net> Twitter: https://twitter.com/embeddedgus
On Sat, 20 Sep 2014 09:24:40 -0400 (EDT) "Robert P. J. Day" <rpjday@crashcourse.ca> wrote:
Questions?
As the book is IIUC publicly available would it be possible to set up a GIT repository with the content and everyone could mark or change the pages by e.g. special latex commands and sent you a respective patch? This way it would be easier to see what is already reviewed and does not need to change, and there might be even the small chance that people could include the requesting change, instead of only putting a marker where the change should happen. The work you have to do should hopefully stays the same, as it would be with emails you get?
rday
On Mon, 22 Sep 2014, Dominik Dingel wrote:
On Sat, 20 Sep 2014 09:24:40 -0400 (EDT) "Robert P. J. Day" <rpjday@crashcourse.ca> wrote:
Questions?
As the book is IIUC publicly available would it be possible to set up a GIT repository with the content and everyone could mark or change the pages by e.g. special latex commands and sent you a respective patch?
This way it would be easier to see what is already reviewed and does not need to change, and there might be even the small chance that people could include the requesting change, instead of only putting a marker where the change should happen.
The work you have to do should hopefully stays the same, as it would be with emails you get?
i'm not aware that LKD3 is publicly available -- i know LDD3 is. and in any event, as someone who has edited/pre-pub reviewed *many* technical books, i can assure you that authors don't want updates recorded that way, they much prefer bullet points labelled with page and paragraph number so *they* can decide how that content should be rewritten. i/we are not trying to rewrite the book -- all i'm trying to do is keep track of what needs updating so that, if there *is* an LKD4, the author has a concise list of changes. the goal here is to make life easy for the author, not so much for the rest of us. anyway, i just need to finish up a couple things and i can start adding in some updates people have already sent me. rday p.s. i know i mentioned this earlier, but in addition to simple updates: http://www.crashcourse.ca/wiki/index.php/Updates_to_LKD3 feel free to suggest improvements to explanations, entirely new features/subsystems that should be addressed, and so on. whatever occurs to you, and i'll try to get it onto that page somewhere. note that section 5 on that page is the chapter by chapter listing, so section 5.1 corresponds to chapter 1, and so on. -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ========================================================================
participants (3)
-
Dominik Dingel -
Gustavo Silva -
Robert P. J. Day