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://www.satchell.net/ipsta... 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.
Brexit means Brexit, lol
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.
Same here fellow old-timer. Slashdot always had a kind of white male bias, but these days the politics has gotten worse. I think the issue is that Digg, Reddit and Hacker News superseded it as news aggregators and Twitter and Facebook just became a lot more important for discussions.
I remember when the controversey over the Star Wars prequels was over if Lucas had dumbed down the franchise,and not the kind of culture war people are having over the new movies.
As once-loyal listeners tune away, most AM stations are barely holding onto life, slashing staff and budgets as deeply as they can while struggling to find a return to profitability. Once upon a time, having a broadcast license of any kind was like having a permit to print money. In today’s world, that's no longer true.
But, with 10,000 AM broadcast towers in the United States, stretching high into the sky, there may be an opportunity for wireless carriers who don't want to argue with community opposition from neighborhoods where residents don't want yet another cell tower. The amount of money an AM station owner can pocket by sharing its tower with a wireless partner varies widely, depending on the tower's location, height, and several other factors. But it's certainly more income — and a way to keep "old" technology from becoming obsolete.
Ron, an IT admin, summarizes the situation succinctly: “More like applied, applied another, removed, I think re-applied, I give up, and have no clue where I am anymore.”
Feel like you're alone? Here's what other sysadmins have done so far, as well as their current plans and long-term strategy, not to mention how to communicate progress to management.
A DSTG team led by mathematician Dr. Neil Gordon set about developing a new technique to extract a path from a subset of the Inmarsat data called the Burst Timing Offset (BTO). This measured how quickly the aircraft responded each time the satellite pinged it, and was used to determine the distance between the satellite and the plane. Investigators used these calculations to draw a set of rings on the earth’s surface.
...The DSTG used its computers to generate a huge number of possible routes and then test them to see which best fit the observed data. Their endpoints were pooled to generate a probabilistic “heat map” of the plane’s most likely resting places using a technique called Bayesian analysis. These calculations allowed the DSTG team to draw a box 400 miles long and 70 miles across, which contained about 90 percent of the total probability distribution.
Cool stuff, even if we still don't know where the plane ended up.
Your program is sick! Shoot it and put it out of its memory.