History: 20 years ago, Heather BJ Clifford and I wrote a book, Linux IP Stacks Commentary, which walked through the Linux TCP/IP stack code and commented it in detail. (Old-timers will remember the Lion's Unix Commentary, the book published by University xerographic copies on the sly. Same sort of thing.) CoriolisOpen published it. And a bit later sank into the west. Nothing has been done since, at least not by us.
Now: when I was released from my last job, I tried retirement. Wasn't for me. I started going crazy with nothing significant to do. So, going through old hard drives (that's another story), I found the original manuscript files, plus the page proof files, for that two-decade-old book. Aha! Maybe it's time for an update. But how to keep it fresh, as Torvalds continues to release new updates of the Linux kernel? Publish it on the Web. Carefully.
After four months (and three job interviews) I have the beginnings of the second edition up and available for reading. At the moment it's an updated, corrected, and expanded version of the "gray matter", the exposition portions of the first edition. In addition, I have put forth ideas for making the commentary portions easier to keep up to date, after they are initially written.
The URL for the alpha-beta version of this Web book is https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Fwww.satchell.net%2Fipsta... for your reading pleasure. The companion e-mail address is up and running for you to provide feedback. There is no paywall.
Thanks to the work of Professor Donald Knuth (thank you!) on his WEB and CWEB programming languages, I have made modifications, to devise a method for integrating code from the GIT repository of the Linux kernel without making any modifications (let alone submissions) to said kernel code. The proposed method is described in the About section of the Web book. I have scaffolded the process and it works. But that's not the hard part.
The hard part is to write the commentary itself, and crib some kind of Markup language to make the commentary publishing quality. The programs I write will integrate the kernel code with the commentary verbiage into a set of Web pages. Or two slightly different sets of web pages, if I want to support a mobile-friendly version of the commentary.
Another reason for making it a web book is that I can write it and publish it as it comes out of my virtual typewriter. No hard deadlines. No waiting for the printers. And while this can save trees, that's not my intent.
The back-of-the-napkin schedule calls for me to to finish the expository text in September, start the Python coding for generating commentary pages at the same time, and start the writing the commentary on ICMP in October. By then, Linus should have version 6.0.0 of the Linux kernel released.
I really, really, really don't want to charge readers to view the web book. Especially as it's still in the virtual typewriter. There isn't any commentary (yet). One thing I have done is to make it as mobile-friendly as I can, because I suspect the target audience will want to read this on a smartphone or tablet, and not be forced to resort to a large-screen laptop or desktop. Also, the graphics are lightweight to minimize the cost for people who pay by the kilopacket. (Does anywhere in the world still do this? Inquiring minds want to know.)
I host this web site on a Protectli appliance in my apartment, so I don't have that continuing expense. The power draw is around 20 watts. My network connection is AT&T fiber — and if it becomes popular I can always upgrade the upstream speed.
The thing is, the cat needs his kibble. I still want to know if there is a source of funding available.
Also, is it worthwhile to make the pages available in a zip file? Then a reader could download a snapshot of the book, and read it off-line.
In 1997, well-known developer Patrick Lenz founded the first listing and announcement site for free and open-source software, freshmeat.net. It was meant to be the guide to open-source programs. But freshmeat never lived up to its promise.
We get together, virtually and in person, to help each other. To laugh. To learn. Starting in the 80s on BBSes, I have made lifelong friends -- many of whom I never met in person. Some are geeks and freaks. Others aren't.
The concern about "who is using us or our data?" was equally important during the user group era. Back then, when I was VP of the Phoenix PC User Group, I had members get angry about the vendor presentations, because they felt that they were paying to join a group where companies "just advertised their products to us." They saw it as paying for vendors to market, and resented it. (I disagreed, but I understood their viewpoint.)
The larger issue now, of course, is that we knew it was Corel doing the marketing, so we could avoid that meeting if we chose. Now, we have no knowledge or control over who collects the data and how it's used.... assuming we show up at the online "meeting." That's a real concern, but I don't think it has anything to do with user groups.
The larger problem was that we didn't have documentation -- very little of it good, anyway. The fact that we needed to get together in person to discover how things worked was a symptom of the new industry's failure, not a strength. However, the fact that we got together in person to help each other speaks to the essential humankindness of the people who wanted to improve things.
In order to get a loan you must first prove you don't need it.
