feedbot: http://bimbo.club/2020/06/work-report-6152020/ << Bimbo Club -- Work Report - 6/15/2020
feedbot: http://bimbo.club/2020/06/work-report-6162020/ << Bimbo Club -- Work Report - 6/16/2020
jfw: billymg: since the #select was formerly done in the themes and I gather now in the 'footnotes' processor, perhaps that would need to be reverted too in one's theme?
diana_coman: http://ossasepia.com/2020/06/01/ossasepia-logs-for-Jun-2020/#1027177 - ah, this rings a bell and I'll need to have a look because iirc I have one level nested replies (though not sure it has anything to do with the theme as such, hm)
sonofawitch: 2020-06-17 03:54:19 (#ossasepia) billymg: diana_coman: ^ the above probably a better answer to your earlier question
jfw: whaack, possibly you have some restrictive 'umask' causing the permissions trouble in the first place, but yes cp -p can be helpful
jfw: Working through the process for a demonstration, deploying TRB in a fresh environment - even knowing where to look for all the pieces - is definitely a pain; and my own wallet too though less so
diana_coman: lol, a more familiar pain with own wallet?
jfw: V alone or at least the one I'm using so far doesn't get you over the hill of 'resolve this project name / key / whatever to a set of files ready to press'
jfw: diana_coman: perhaps, but own wallet has fewer pieces needing to be rounded up so far
diana_coman: that sounds like a script being sorely needed
diana_coman: and a write up afterwards.
jfw: that's probably the practical approach, yeah; but needing a special unique script for this one thing grates. I need a bitcoin-bootstrapper, why? haven't I already bootstrapped a unix and V?
diana_coman: well, that route it's already "why do I need to bootstrap V, haven't I already bootstrapped a unix?" heh
diana_coman: the "why" in the end is simple really - because there's no better alternative available and no, can't wait "however long it takes" until that better alternative is "ready" etc
jfw: "that's how we ended up in this software mess in the first place" sticks in my head but I can't disagree
jfw: comes right back to balancing present vs future costs.
diana_coman: no, it's not that how we ended up in this software mess in the first place, heh
diana_coman: choosing what is as opposed to what one might want is certainly not "how one ends up in mess"
diana_coman: note though that choosing what has to be chosen *now* doesn't mean that it has to remain like that forever or anything of the sort
diana_coman: you can argue perhaps that making a script now lowers the pain and thus makes the problem less visible/easier to ignore - in which case fine, don't make the script and keep the pain until the root trouble gets solved, sure
diana_coman: only I don't think it's your clients who are supposed to either solve it or wait until it's solved.
jfw: I think I get it - or at least I've got as far as I'm going to from chewing on this example.
jfw: this one script won't be creating bigger problems, in itself; my thinking was that by using something you become more dependent on it + the system it's a part of. perhaps that's more a result of using it blindly or allowing that to happen than of the mere use though ("don't blame the drug")
diana_coman: jfw, that is exactly what I mean above by makes the problem less visible to some extent; but this visible always depends inevitable on who and how is looking, heh.
sonofawitch: 2020-06-17 21:37:35 (#ossasepia) diana_coman: you can argue perhaps that making a script now lowers the pain and thus makes the problem less visible/easier to ignore - in which case fine, don't make the script and keep the pain until the root trouble gets solved, sure
diana_coman: inevitably*
jfw: I'm just slower to figure out what I'm arguing then!
diana_coman: well, came to rant and ended up arguing - it might take a while to switch!