Work on my bathroom continues. I had expected it to be complete on Friday but it lookse like the new completion date will be Tuesday or Wednesday.
It will be very nice to have a working shower, and a toilet I don't need to "flush" with a bucket.
The only interesting thing I've been doing is planning on a kernel to support long-term for some poor unfortunate souls who cannot use Debian-based kernels.
I know building, supporting, and maintaining a kernel will be a pain. But at the moment it looks like a valid thing to be suggesting.
Otherwise life goes on. I've been hit by the DIY bug, largely as the result of seeing all the bathroom work going on, and figuring I was going to live with dust/mess anyway - so I've erected some more book-shelves, and ordered a pair of ceiling fans.
The only other thing to report is that I've started deleting emails. (shock!)
I look after a few machines for myself, friends and so on. Each one will send me automated emails at times. I've got them going back years - but no longer:
#
# Prune old mailboxes.
#
for maildir in .Automated.backups .machines.spotlight .machines.skx; do
nrecent --keep=150 $HOME/Maildir/${maildir}/cur
done
Another new use for my nrecent tool. (Note: Only delete files from ./cur, to avoid deleting messages I've not read. Maildir is your friend!)
ObQuote: "I'm sorry I'm sweating on you... " - Knocked Up.
Why is it they "cannot use Debian-based kernels"? Some feature patch that's not accepted upstream?
Missing patches aren't so much of a problem, but there are known-bugs which are present. e.g. #668511 Kernel panic with bridge networking.
I guess they come under the heading of missing-patches, but only slightly.
I am surprised that there is not a 'good' effort underway already to provide a distribution-independent kernel. I don't mean kernel.org with that statement but rather taking one of their 'Stable' releases (2.6.32 / 3.2) and building a community of support around it to include:
* Sensible configuration supporting most types of 'common' hardware
* Working with the upstream maintainer to get problems fixed at source
* Adding 3rd party patches as deemed necessary
* Mailing lists, IRC or other forms of support for using it
* Packages to install it on CentOS, Debian, Ubuntu, etc etc