This week got off to a slow start; causes coming to mind are my struggle towards a Laufrichtungsanderung on reviews and plans, as well as pondering what was happening with Robinson and what I might do about it.
After publishing the plan there was some feeling of “why did I go writing all that stuff, sure I wanted to do it but now I have to!” By that evening though I was getting back to productivity, starting by continuing on my TRB direction, then mixing the momentarily unsexier items back in.
1. Research health insurance: 4h.
Not started; I’ll make this the focus for Saturday.
2. Basic backup scripting for newly upgraded Thinkpad. This is just to adapt my existing tar+gpg based full backup script, with excludes for large datasets that don’t fit this treatment (bitcoin database, local software & web archives). 2h.
Done in 1.2h, which involved tweaking my script for Busybox tar, running, verifying, and some data pruning. Explicitly breaking the backups problem into this and the following part was helpful in getting started.
3. Investigate options for efficient differential backups on Gales. In the past I’ve used rsync and unison but the prospect of committing these to my own V-tree gives me pause. The Gales mirror sync scripts I wrote prove it can be done quite simply; one option would be to expand these to handle metadata and soft/hard links. Minimum 3h.
Not started; this could be a good one for the rest of today.
4. Streamline time tracking tools or usage – no more manual aggregation: 3h.
I also wanted to lose the clunky Ledger format, so ended up taking 4.3h for a pure sh/awk rewrite, in which I learned a bit about calendar date processing where in my Python days I’d just “import time”. It doesn’t do multi-level aggregation yet but should at least beat what I was doing before; I’ll cut over for the upcoming week, see how it goes and budget some time for tweaks.
5. Blog: definitely don’t write anything about TRB patches, Gales Scheme, Gales Bitcoin Wallet, or router setup! 10h.
So far the anti-plan prevails. I spent 4.8h refining and further testing my TRB build system simplification patch, further cutting down on the proliferation of makefiles and build directories, discovering parallel build was broken (and was before the change, no thanks to openssl) and fixing that. Then 2.7h reviewing and signing the whole vpatch set, with my main key where I was confident in my grasp of the patch and my “unchecked” key otherwise.
10h actual writing probably isn’t happening by Sunday but I’ll go for at least one article on those patches.
6. Assist Robinson as requested, or otherwise unexpected tasks: 5h.
This being eaten by the above patch refinement, I’ll need to allow for some more as it looks like there’s at least a phone meeting with a prospect coming up.
7. Chat in #ossasepia, or otherwise engage blogs: 5h.
Around 4h, but I haven’t kept up with blogs too well, such as billymg’s survey.
8. Weekly review: 1h at 18:00 UTC Friday. Not expecting to be done with all the above by then but I can look at how it’s gone so far.
Started late (I got recruited for a morning shopping run and didn’t get moving soon enough on that), and wound up at 2.5h with some distractions.
9. Next week’s plan: 1h. Efficiency can be improved later but priority is to get the plans more meaningful/useful.
I’ll go for this on Saturday.
10. Keep in touch with past students + remote friends and family: 1h.
Not seeing this as “work” really so leaving it for Sunday.
Time permitting:
11. Investigate TRB sync and peering logic. My new node has made very little progress, with intervals of nothing but “bastard blocks” alternating with silence, a behavior I’ve observed many times before but is really starting to bug me.
I spent 3h thinking on this and writing some node monitoring scripts. One of these confirms that it spends most of its sync time doing nothing useful whatsoever (presently 13 hours since last accepted block) but works briefly on restart.
Total here is 23.5h for the 3.5 days. It’s looking feasible to hit the remaining targets, except the 10h writing, in the remaining 1.5 days, as long as I stay on track. One change for next week will be bringing JWRD discussions and sales assistance back to the front and center.
Some focused productivity and taking more control do seem to creep in, at least from what this review says, so it looks to me not bad at all. And now that the review-block is broken at least, perhaps it will gradually take less time to do it, too, that’s how it tends to go anyway.
This does sound like main priority for you indeed, anyway. And as usual, feel free to ask or talk in chan if it helps at all.
Comment by Diana Coman — April 18, 2020 @ 8:02 am
This ended up with #3 having quite a pull on me. I took a high-level look at the rsync codebase which confirmed my suspicion that it’s way the hell too big, then started on some coding for accurately describing filesystem trees. I let this all soak up 10.9h and displace much of the rest.
There was 1.5h on a conference call with a prospect and followup chat with Robinson, and 1h on vpatch organization and test presses in preparation for patch publication. In the latter I discovered painfully that v.pl’s strange press-path algorithm runs in exponential time – on my faster machine, my two measly bitcoin patches bring its minimum latency for any operation from 3.5 to 11 seconds.
Finally I got in a token .5h poking at health insurance, and concluded that poking at websites won’t be an effective route and this needs to be approached as getting contact info and talking to people kind of project.
Comment by Jacob Welsh — April 20, 2020 @ 5:44 am
Ha, 10.9h is quite something indeed. The rsync codebase (like most “tools”) is too inflated, certainly, but do note that you need to pick and choose too when & what gets the limited time available or you’ll end up ~forever cleaning up.
Glad to hear something is happening on jwrd front too. Re v.pl, did you try Bvt’s vtools? Or was it that you didn’t want to add gnat to the mix or what?
As most tend to be, anyway.
Comment by Diana Coman — April 20, 2020 @ 7:15 am
Ack on needing to choose one’s fights. This one’s been bugging me for years really, and I have the notion that if I import rsync now and keep building processes on it I’ll simply never be rid of it, so I’m resolved to tackle it as long as the problem doesn’t explode too much further.
Ack on most projects tending to require focus on people (if that’s a valid way to rephrase).
From http://logs.ossasepia.com/log/ossasepia/2020-04-20#1024817 :
jfw: diana_coman: re bvt’s vtools work, I got the idea that it had some shortcomings like lack of leafs command and a non-tree-like patch tree view, and would require further work from me either on GNAT builds or making v.sh do without. Whereas v.pl was supposed to be the known-working historical tool, and a relatively smaller investment there would be adequate for my present needs.
diana_coman: jfw: he fixed those issues/lacks
diana_coman: it does require gnat though, that’s the price for using ada, true; and yes, in principle v.pl is the smaller investment route indeed
diana_coman: but yeah, it has its own quirks for sure.
jfw: diana_coman: good to know you consider them fixed now.
diana_coman: jfw: what are you using for v-pressing/work anyway?
diana_coman: (and yes re vtools; I have it on my list for this week to also mirror it all + publish my sigs for it, as they accumulated but I never set down to publish any of them.)
jfw: diana_coman: v.pl for pressing. For diffing, the ill-fated vdiff on top of GNU diff presently.
jfw: Which itself is not ideal for sure.
diana_coman: ah, I had the impression you found v.pl inadequate for what you needed, in the end.
diana_coman: eh, ~nothing’s ever ideal, if it gets to that.
jfw: hm, no I was happy with v.pl after the work I did on it, at least until finding this exp-time issue
diana_coman: then it’s just a matter of deciding whether it’s something you can live with in exchange for not-having-to-get-gnat-too or not, pretty much; anyways, it doesn’t sound like a priority-problem atm.
jfw: ah but I did discover another shortfall of busybox patch – it doesn’t delete empty directories after deleting the last file with the -E flag, that is, a presser built on it can never delete directories. This nudges me further toward embracing GNAT so as to get phf’s vpatch program. But yeah, not seeing the priority quite yet.
diana_coman: jfw: so give it some time then.
jfw: will do.
Comment by Jacob Welsh — April 21, 2020 @ 7:18 pm