Day changed to 2021-04-01
[13:00] cruciform: jfw, I'm under the weather today; may we reschedule for Tuesday? Apologies again for late-notice
[13:32] cruciform: also, was the Euloran junto meeting recorded last night? Missed it on account of hitting the sack early
[15:40] jfw: cruciform: ok, no worries. not like I don't have other things to fill the time!
[15:43] jfw: do ask if you run into trouble with the router process; I reckon it's the largest or most "unguided" project we've assigned so far
[15:47] jfw: I will inquire into the recording.
Day changed to 2021-04-05
[14:28] cruciform: jfw, I’ve recovered, though haven’t got any closer to completing router-setup-homework (pure derpage/avoidance on my part). I could use a little more time to get it sorted – may we move tomorrow’s session to Thursday?
[16:35] jfw: cruciform: I don't think it'll be that bad once you get started; what about taking just an hour tonight or in the morning to try and then we'll just take Tuesday's session to continue working through it?
[18:15] cruciform: jfw, cool - let's do that; see ya tomorrow @ 18:00 UTC
Day changed to 2021-04-11
[23:54] jfw: https://espotek.com/labrador/ << and here I was thinking I might need to drop .1 BTC on an oscilloscope to do any serious hardware work. modernity, huh?
[23:56] jfw: and finally I find something cool that *wasn't* mentioned in ye olde tmsr logz, HA!
Day changed to 2021-04-12
[00:00] jfw: and if the $30 hobbyist postage-stamp thing isn't up to par there's more commercial looking $70 ones with winblows interface, and failing that, ~ $400 for entry level of 'grownup' standalone bench scopes.
Day changed to 2021-04-19
[21:55] jfw: I'm finding that my process for grading the early homework assignments involves filling in explanations for what was missed, which ends up making it take as long to grade as it would to do the assignment. Not too scalable.
[21:58] cruciform: well, how scalable can highly-specialized, one-on-one tuition be?
[21:58] jfw: I suppose it comes from not being quite satisfied that things were adequately covered in the texts.
[21:58] jfw: well the basics aren't all that specialized
[21:58] jfw: (I've got others going through unix-001 still)
[21:59] cruciform: what's the alternative - "read the manual again"?
[22:00] jfw: why not - and then they'll at least know which part they're missing!
[22:00] cruciform: heh, it wasn't meant altogether snarkily
[22:01] jfw: cruciform: but how goes with you? and should we plan to make it another lab day tomorrow?
[22:01] cruciform: when I tutored, I'd always go through the homework painstakingly with the student, and show em where they fucked up
[22:01] cruciform: I'm dealing with estate agent bullshit, still
[22:01] cruciform: tomorrow ought to work fine; I should be able to get the homework done beforehand
[22:02] cruciform: (current stupid problem: despite paying the entire contract upfront, they're asking for tax returns etc)
[22:02] jfw: but I mean, will you have the network online and ready for new stuff, or better to just make that the goal for tomorrow?
[22:03] jfw: o_O
[22:03] cruciform: as in, have the router setup finished? Yea, that'll be a decent goal
[22:04] cruciform: I offered one landlord and entire year's rent upfront, he declined: "what's your proof of income???"
[22:04] cruciform: *an entire
[22:05] jfw: could ask for proof that he exists I guess
[22:05] cruciform: I've been writing up my experience getting scammed on a BTC-OTC trade/WoT/filtration; should have that posted soon
[22:06] cruciform: heh
[22:06] cruciform: these "people" are so wed to their delusions of how the world works
[22:06] jfw: and the deed too. I mean, almost sounds like wanting to prove you're a mark for his scheme
[22:08] cruciform: well, it's been cause for self-reflection, at least: where have I been derping/promising but not delivering etc
[22:08] jfw: I don't think I'd pay a year in advance without some proof of ownership from the other party. but then, overheated suburbs of exploding city, seller's market etc.
[22:08] cruciform: yea - the market is utterly ridiculous, here
[22:09] jfw: I gotta run but thanks for confirming on tomorrow.
[22:09] cruciform: I'm kinda glad the landlord turned down the year-upfront offer; I agree it's not one I'd make
[22:09] cruciform: cool; cya tomorrow
Day changed to 2021-04-27
[04:44] jfw: dorion: here's a decision I hadn't quite realized was necessary to make, or so non-obvious if seemingly small: how to go about labeling servers in a field deployment with relatively little remote-hands support.
[04:45] jfw: as a sysadmin I always liked "meaningful" labels eg hostname as opposed to dumb serial number or database ID
[04:47] jfw: but this was supported by having a small & competent team, a label maker in working order handy or at least sticky notes and a marker in the worst case, so that I could trust that this "distributed database" would be maintained
[04:53] jfw: if something fails and we need to direct the client to install a shelf spare, or something gets repurposed, where we can reconfigure the software level remotely, either: client plugs in new thing, tells us its serial, we update a list, and that's the extent of their responsibility; or else we "push" a new label name which falls to them to get printed & applied (and to the right thing in a workable
[04:53] jfw: place!)
[05:03] jfw: it's perhaps one facet of the larger "seeing servers as pets or as cattle" divide. do you know and love each one individually, its personality, history and individually selected name? or is it just one of many, indistinguishable outside whatever written records were kept?
[05:09] jfw: I definitely see these ones as cattle, but in the role of the remote hands it can still be rather helpful to be able to know at a glance wtf you're looking at - especially when communicating with remote admins who think in terms of hostnames rather than physical numberings.
[05:22] jfw: (needless to say, the scenario is one where poking the wrong thing can turn a minor problem into a major one.)
[21:50] jfw: Since there was some surprise at this, I'll point out that the social engineering operation SEGWIT, targetting ill-informed would-be Bitcoin users, is only the latest (if it's even that anymore) in a long string of same ; that Bitcoin addresses begin with a "1" ; and that the [known specimens found in the wild][https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki] of pretend-Bitcoin
[21:50] jfw: addresses beginning with "3" have always worked on the basis of "anyone can spend", this being required for transactions spending them to make it into the actual Bitcoin network at all. I'd conjecture that a notion that "multisig" is somehow safer comes about because the "ANYONECANSPEND" term itself apparently
[21:50] jfw: originated in the SEGWIT days, nonetheless things are what they are whether or not someone's yet put a name on them.
[21:55] jfw: gah, crossed the [][] linking order but it's recognized as a link well enough anyway.
[21:59] jfw: probably the canonical required reading on the subject
Day changed to 2021-04-28
[14:08] dorion: http://fixpoint.welshcomputing.com/2021/jwrd-logs-for-Apr-2021/#1830 -- I think we should be clear on what the written records are and use that as a starting point and basis for the ongoing management and client communication. e.g. using the appendix in the recent report and adding the serial numbers for which machine server which purpose.
[14:08] sourcerer: 2021-04-27 05:03:35 (#jwrd) jfw: it's perhaps one facet of the larger "seeing servers as pets or as cattle" divide. do you know and love each one individually, its personality, history and individually selected name? or is it just one of many, indistinguishable outside whatever written records were kept?
[14:08] dorion: s/server/serves/
[14:16] dorion: http://fixpoint.welshcomputing.com/2021/jwrd-logs-for-Apr-2021/#1834 -- mind teasing out a bit how this works in practice ?
[14:16] sourcerer: 2021-04-27 21:50:09 (#jwrd) jfw: addresses beginning with "3" have always worked on the basis of "anyone can spend", this being required for transactions spending them to make it into the actual Bitcoin network at all. I'd conjecture that a notion that "multisig" is somehow safer comes about because the "ANYONECANSPEND" term itself apparently
[18:37] jfw: dorion: which part? do you mean, how the 3-addresses are derived and thus how coin in them is spent?
[18:53] dorion: yeah.
[18:53] jfw: dorion: to my eye, network configuration exists in up to three places: 1) the actual, active configuration ie how the physical objects connect and how the relevant bits in memory that control their operation are set; 2) labels on the physical objects by which to navigate during physical installation & maintenance operations; 3) documents recording it all which are essentially secondary sources at
[18:53] jfw: best but facilitate understanding & planning if kept up to date.
[18:53] jfw: you seem to be addressing how the documents (3) are to be managed, which is fine & necessary but my question here was about (2).
[19:00] jfw: 3-addresses, also known as "pay to script hash" or p2sh, were introduced by Gavin in 2012, in the linked BIP16 and related; in his own words : "Old implementations will validate that the {serialize script}'s hash value matches when they validate blocks created by software that fully support this BIP, but will do no other validation."
[19:02] jfw: Gavin the enemy agent, that is.
[19:04] dorion: jfw, where are the serial numbers ? on the bottom of the cases ?
[19:04] jfw: wherever I put them, which I'm figuring to be somewhere more readily visible.
[19:05] dorion: you're making the labels then ? they're not already on the cases from upstream ?
[19:05] jfw: correct
[19:09] dorion: when you say "pet name" you mean, e.g., pub1 from the appendix ?
[19:10] jfw: so to expand a bit re 3-addresses, all a non-gavinist node requires to accept a transaction spending away the coins in them, is any string that hashes to that address (after some other minor encoding transformations) - which is kindly provided by the "owner" of the coins when they broadcast their own unconfirmed transaction.
[19:11] jfw: ie it's a potential additional mining reward every time such transactions are issued; though if a miner takes it, the fork between gavincoin miners and bitcoin miners will manifest.
[19:12] jfw: node operators too, not just miners.
[19:14] jfw: nah, pub1 is a cattle style name - a function identifier and a number; pet style names are exactly that, proper names.
[19:16] jfw: the generalization to those two approaches depending on one's relationship to the machines in question is a side point really.
[19:17] dorion: jfw, ok. as far as the number identifier, is that relative to the deployment ? e.g. client1 has a pub1, client2 has a pub1 too.
[19:20] jfw: yes
[19:22] jfw: (one can add domain names if this becomes a problem)
[19:32] dorion: alright, we're delivering pre-installed/configured with our own labels. if we go with functional names, as opposed to purely numerical, the spare isn't going to be labeled for what it's going to be when it's live, since we don't know yet. when the time comes, client has to do that. if it's purely numerical, the label can be pre-applied and client just has to plug it in.
[19:33] jfw: exactly (well, plug it in and communicate what they did so we can update the docs, but this is the same in either case)
[19:37] dorion: is it a big deal to provide an extra set of pre-printed labels from the start ?
[19:39] jfw: not in itself
[19:40] dorion: seems like that'd be a good balance of functional names and cheap to maintain consistently.
[19:40] dorion: as opposed to bring your own, sticky notes + sharpie, etc.
[19:42] jfw: seems like a band-aid to me though as it only works once
[19:42] jfw: could then mail a new label I guess
[19:43] jfw: ah, which is fine as we'd be mailing a new spare anyway
[19:45] jfw: (that is, minimal marginal cost)
[19:46] jfw: if the spare fails before new one arrives... c'est la vie and that's why some things are already redundant
[19:46] dorion: mailing works then.
[19:48] jfw: and with this view, a permanent US base would be quite helpful for providing long-term support.
[19:50] jfw: so now I'm figuring for each box one label (permanent) with our SKU and serial number and another (replaceable) with functional name, and a set of spare labels for the latter
[19:59] dorion: ok, works.
[23:29] jfw: dorion: cool, thanks for the input. next decision in this vein then is the design of those stockkeeping unit & serial numbers - basically how to construct the "primary key" by which stuff we stock is identified as a class and as an individual.
[23:30] jfw: for s/n, it seems fine to me to continue using incrementing decimal numbers as we've been doing to some extent already
[23:33] jfw: for sku, the two extremes are fully numeric (decimal, hex or otherwise) or fully "meaningful" as illustrated for example by pcengines
[23:40] jfw: then there's whether the serial is unique across our whole catalog or just per sku; the latter has some (probably minor) advantage of brevity, but the global approach seems preferable to me; for one thing the redundancy provides a bit of error detection, and for another it simplifies issuance of new numbers if there's only one counter involved (eg can use an auto_increment database field)
[23:50] jfw: changing topics, I'm in the market for a new webcam, preferably with strong support on both windows & linux. http://www.ideasonboard.org/uvc/ looked nice and authoritative as far as what seems to have emerged from the battlefield of the 2000's as some kind of standard interface; except the reported USB ID for the "Logitech C310" on my desk disagrees with /usr/share/misc/usb.ids and actual
[23:50] jfw: observation
[23:55] jfw: and it's not just a case of different IDs released under the same marketing name - the one they cite is used by a different thing, "HD Webcam C510" according to usb.ids. Seems fair to conclude then that the "works" status is just as likely to be typo'd
Day changed to 2021-04-29
[00:00] jfw: nice to know the driver got merged in the 2.6 kernel branch though.
[00:13] jfw: I'll probably try "anyone but logitech" because their camera control software on windows is quite sad.
[02:39] jfw concludes the entire current crop of webcams, prolific as it is, is shit, and buys the cheapest logitech c270
[19:57] jfw: Wow... turns out the boot configuration menu on the apu1, provided by a "sortbootorder" Coreboot payload from the defunct Sage Electronic Engineering, saves its configuration state not to the battery-backed NVRAM used by every PC BIOS ever, such that popping the battery is all you need for a field reset, but to the boot ROM by way of an SPI flash protocol library (making it possible to brick the
[19:57] jfw: unit, for one thing). It WRITES, to "READ-ONLY" memory. Because they could, I guess.
[20:17] jfw resists the urge to rip it out straightaway, on the theory that the path to sanity starts by at least reproducing what exists & works
[22:04] dorion: http://fixpoint.welshcomputing.com/2021/jwrd-logs-for-Apr-2021/#1881 -- global is fine with me.
[22:04] sourcerer: 2021-04-28 23:40:38 (#jwrd) jfw: then there's whether the serial is unique across our whole catalog or just per sku; the latter has some (probably minor) advantage of brevity, but the global approach seems preferable to me; for one thing the redundancy provides a bit of error detection, and for another it simplifies issuance of new numbers if there's only one counter involved (eg can use an auto_increment database field)
[22:06] dorion: http://fixpoint.welshcomputing.com/2021/jwrd-logs-for-Apr-2021/#1888 -- perhaps a symptom of why they're now defunct.
[22:06] sourcerer: 2021-04-29 19:57:07 (#jwrd) jfw: Wow... turns out the boot configuration menu on the apu1, provided by a "sortbootorder" Coreboot payload from the defunct Sage Electronic Engineering, saves its configuration state not to the battery-backed NVRAM used by every PC BIOS ever, such that popping the battery is all you need for a field reset, but to the boot ROM by way of an SPI flash protocol library (making it possible to brick the
[23:02] jfw: could be; mediocre work for "proud prices" as the pcengines guy told me.
[23:05] jfw: another weirdness is that you can't enable or disable boot options, except for the PXE ROM for netbooting as a special case, only reorder them. not impressed with the subsequent work on it by pcengines / their newer contractor either, just piling on more layers of shit
[23:10] jfw: so far it looks to me like this feature would have been better done as a seabios mod rather than a separate thing, importing "libpayload" and all because why bother leveraging the BIOS code that it's already married to
Day changed to 2021-04-30
[03:27] dorion: http://dorion-mode.com/2021/04/elvin-coaljobs-euloran-gatherings/
[17:36] jfw: dorion: after another 10h this week of digging to get oriented to those 'SageBIOS' coreboot sources, my takeaway is that they're still crap no matter what angle I look from - but more interestingly, none of it appears to actually be necessary
[17:39] jfw: that is, I'm anticipating that I can use a stack of mainline coreboot (same one captured in '16 for thinkpads), mainline SeaBIOS (idem), and - here's the previously unknown - a mainline sgabios to accomplish the serial console redirection (which I'll note appears to have already existed, as a nice standalone thing, long before they went and did their own
[17:39] jfw: seabios based hack for it)
[17:47] jfw: the problem with the "start with what exists/works" approach as previously imagined for this case is that the archaeotarball that looks most likely to be such a thing has entirely dubious provenance while its parts aren't practically separable (e.g. to use just the extras as I'd been thinking) - "spittoon comes all in one strand"
[17:50] jfw: so the adjustment is that the mainline stuff also exists & works - not fully in the same way as what the apu1 ships with, but those extras don't actually add the value that I naively imaged they did.
[17:56] jfw: sgabios comes from Google, '08, which is mildly concerning, but I suppose that was back when google sorta worked, the chrome + apps virii had escaped the lab but not yet become a global pandemic etc.
[18:23] dorion: jfw, if it is actually the case that sagebios is unnecessary, sounds like a productive 10h. I'm not enough of a google expert to known the extent they worked in '08, if ever, but using the extant coreboot+seabios with sgabios --which I counted to be less than 3k LoC-- looks better than drinking the sagebios spittoon.
[18:25] dorion: so go ahead with trying the coreboot+seabios+sgabios and lets see what comes out of it.
[18:32] dorion: jfw, do you reckon this approach would mitigate the bricking risks described upstack ? or will you still start with the sortbootorder coreboot payload ?
[19:07] jfw: to expand a bit in case it's unclear: bricking is kind of a relative thing, eg for average windows user, clicking the wrong link on a web page can render the machine unusable to the extent of their capacity for repairs. in our case, we can always recover the ROM to a known state by means of in-system programming with chip-clip. that's rather a pain though due to the specialty tools, knowledge &
[19:07] jfw: time required. so brickable in this sense means "possible to make a mess through software means in the field that can't be repaired by same"
[19:10] jfw: strictly speaking, machine becomes brickable as soon as actual-ROM was substituted with pretend-ROM, but sortbootorder's offense is doing it as SOP with convenient UI for the foot-gun.
[19:11] jfw: so my argument is that sortbootorder - as one of the Sage extras - isn't actually necessary or useful.
[19:12] dorion: ok, cool, thanks for the clarity, make sense, looks like a big win, lets see how it comes out.
[19:12] jfw: if so, this doesn't just mitigate but eliminates the risk.
[19:13] jfw: cool
[13:00] cruciform: jfw, I'm under the weather today; may we reschedule for Tuesday? Apologies again for late-notice
[13:32] cruciform: also, was the Euloran junto meeting recorded last night? Missed it on account of hitting the sack early
[15:40] jfw: cruciform: ok, no worries. not like I don't have other things to fill the time!
[15:43] jfw: do ask if you run into trouble with the router process; I reckon it's the largest or most "unguided" project we've assigned so far
[15:47] jfw: I will inquire into the recording.
Day changed to 2021-04-05
[14:28] cruciform: jfw, I’ve recovered, though haven’t got any closer to completing router-setup-homework (pure derpage/avoidance on my part). I could use a little more time to get it sorted – may we move tomorrow’s session to Thursday?
[16:35] jfw: cruciform: I don't think it'll be that bad once you get started; what about taking just an hour tonight or in the morning to try and then we'll just take Tuesday's session to continue working through it?
[18:15] cruciform: jfw, cool - let's do that; see ya tomorrow @ 18:00 UTC
Day changed to 2021-04-11
[23:54] jfw: https://espotek.com/labrador/ << and here I was thinking I might need to drop .1 BTC on an oscilloscope to do any serious hardware work. modernity, huh?
[23:56] jfw: and finally I find something cool that *wasn't* mentioned in ye olde tmsr logz, HA!
Day changed to 2021-04-12
[00:00] jfw: and if the $30 hobbyist postage-stamp thing isn't up to par there's more commercial looking $70 ones with winblows interface, and failing that, ~ $400 for entry level of 'grownup' standalone bench scopes.
Day changed to 2021-04-19
[21:55] jfw: I'm finding that my process for grading the early homework assignments involves filling in explanations for what was missed, which ends up making it take as long to grade as it would to do the assignment. Not too scalable.
[21:58] cruciform: well, how scalable can highly-specialized, one-on-one tuition be?
[21:58] jfw: I suppose it comes from not being quite satisfied that things were adequately covered in the texts.
[21:58] jfw: well the basics aren't all that specialized
[21:58] jfw: (I've got others going through unix-001 still)
[21:59] cruciform: what's the alternative - "read the manual again"?
[22:00] jfw: why not - and then they'll at least know which part they're missing!
[22:00] cruciform: heh, it wasn't meant altogether snarkily
[22:01] jfw: cruciform: but how goes with you? and should we plan to make it another lab day tomorrow?
[22:01] cruciform: when I tutored, I'd always go through the homework painstakingly with the student, and show em where they fucked up
[22:01] cruciform: I'm dealing with estate agent bullshit, still
[22:01] cruciform: tomorrow ought to work fine; I should be able to get the homework done beforehand
[22:02] cruciform: (current stupid problem: despite paying the entire contract upfront, they're asking for tax returns etc)
[22:02] jfw: but I mean, will you have the network online and ready for new stuff, or better to just make that the goal for tomorrow?
[22:03] jfw: o_O
[22:03] cruciform: as in, have the router setup finished? Yea, that'll be a decent goal
[22:04] cruciform: I offered one landlord and entire year's rent upfront, he declined: "what's your proof of income???"
[22:04] cruciform: *an entire
[22:05] jfw: could ask for proof that he exists I guess
[22:05] cruciform: I've been writing up my experience getting scammed on a BTC-OTC trade/WoT/filtration; should have that posted soon
[22:06] cruciform: heh
[22:06] cruciform: these "people" are so wed to their delusions of how the world works
[22:06] jfw: and the deed too. I mean, almost sounds like wanting to prove you're a mark for his scheme
[22:08] cruciform: well, it's been cause for self-reflection, at least: where have I been derping/promising but not delivering etc
[22:08] jfw: I don't think I'd pay a year in advance without some proof of ownership from the other party. but then, overheated suburbs of exploding city, seller's market etc.
[22:08] cruciform: yea - the market is utterly ridiculous, here
[22:09] jfw: I gotta run but thanks for confirming on tomorrow.
[22:09] cruciform: I'm kinda glad the landlord turned down the year-upfront offer; I agree it's not one I'd make
[22:09] cruciform: cool; cya tomorrow
Day changed to 2021-04-27
[04:44] jfw: dorion: here's a decision I hadn't quite realized was necessary to make, or so non-obvious if seemingly small: how to go about labeling servers in a field deployment with relatively little remote-hands support.
[04:45] jfw: as a sysadmin I always liked "meaningful" labels eg hostname as opposed to dumb serial number or database ID
[04:47] jfw: but this was supported by having a small & competent team, a label maker in working order handy or at least sticky notes and a marker in the worst case, so that I could trust that this "distributed database" would be maintained
[04:53] jfw: if something fails and we need to direct the client to install a shelf spare, or something gets repurposed, where we can reconfigure the software level remotely, either: client plugs in new thing, tells us its serial, we update a list, and that's the extent of their responsibility; or else we "push" a new label name which falls to them to get printed & applied (and to the right thing in a workable
[04:53] jfw: place!)
[05:03] jfw: it's perhaps one facet of the larger "seeing servers as pets or as cattle" divide. do you know and love each one individually, its personality, history and individually selected name? or is it just one of many, indistinguishable outside whatever written records were kept?
[05:09] jfw: I definitely see these ones as cattle, but in the role of the remote hands it can still be rather helpful to be able to know at a glance wtf you're looking at - especially when communicating with remote admins who think in terms of hostnames rather than physical numberings.
[05:22] jfw: (needless to say, the scenario is one where poking the wrong thing can turn a minor problem into a major one.)
[21:50] jfw: Since there was some surprise at this, I'll point out that the social engineering operation SEGWIT, targetting ill-informed would-be Bitcoin users, is only the latest (if it's even that anymore) in a long string of same ; that Bitcoin addresses begin with a "1" ; and that the [known specimens found in the wild][https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki] of pretend-Bitcoin
[21:50] jfw: addresses beginning with "3" have always worked on the basis of "anyone can spend", this being required for transactions spending them to make it into the actual Bitcoin network at all. I'd conjecture that a notion that "multisig" is somehow safer comes about because the "ANYONECANSPEND" term itself apparently
[21:50] jfw: originated in the SEGWIT days, nonetheless things are what they are whether or not someone's yet put a name on them.
[21:55] jfw: gah, crossed the [][] linking order but it's recognized as a link well enough anyway.
[21:59] jfw: probably the canonical required reading on the subject
Day changed to 2021-04-28
[14:08] dorion: http://fixpoint.welshcomputing.com/2021/jwrd-logs-for-Apr-2021/#1830 -- I think we should be clear on what the written records are and use that as a starting point and basis for the ongoing management and client communication. e.g. using the appendix in the recent report and adding the serial numbers for which machine server which purpose.
[14:08] sourcerer: 2021-04-27 05:03:35 (#jwrd) jfw: it's perhaps one facet of the larger "seeing servers as pets or as cattle" divide. do you know and love each one individually, its personality, history and individually selected name? or is it just one of many, indistinguishable outside whatever written records were kept?
[14:08] dorion: s/server/serves/
[14:16] dorion: http://fixpoint.welshcomputing.com/2021/jwrd-logs-for-Apr-2021/#1834 -- mind teasing out a bit how this works in practice ?
[14:16] sourcerer: 2021-04-27 21:50:09 (#jwrd) jfw: addresses beginning with "3" have always worked on the basis of "anyone can spend", this being required for transactions spending them to make it into the actual Bitcoin network at all. I'd conjecture that a notion that "multisig" is somehow safer comes about because the "ANYONECANSPEND" term itself apparently
[18:37] jfw: dorion: which part? do you mean, how the 3-addresses are derived and thus how coin in them is spent?
[18:53] dorion: yeah.
[18:53] jfw: dorion: to my eye, network configuration exists in up to three places: 1) the actual, active configuration ie how the physical objects connect and how the relevant bits in memory that control their operation are set; 2) labels on the physical objects by which to navigate during physical installation & maintenance operations; 3) documents recording it all which are essentially secondary sources at
[18:53] jfw: best but facilitate understanding & planning if kept up to date.
[18:53] jfw: you seem to be addressing how the documents (3) are to be managed, which is fine & necessary but my question here was about (2).
[19:00] jfw: 3-addresses, also known as "pay to script hash" or p2sh, were introduced by Gavin in 2012, in the linked BIP16 and related; in his own words : "Old implementations will validate that the {serialize script}'s hash value matches when they validate blocks created by software that fully support this BIP, but will do no other validation."
[19:02] jfw: Gavin the enemy agent, that is.
[19:04] dorion: jfw, where are the serial numbers ? on the bottom of the cases ?
[19:04] jfw: wherever I put them, which I'm figuring to be somewhere more readily visible.
[19:05] dorion: you're making the labels then ? they're not already on the cases from upstream ?
[19:05] jfw: correct
[19:09] dorion: when you say "pet name" you mean, e.g., pub1 from the appendix ?
[19:10] jfw: so to expand a bit re 3-addresses, all a non-gavinist node requires to accept a transaction spending away the coins in them, is any string that hashes to that address (after some other minor encoding transformations) - which is kindly provided by the "owner" of the coins when they broadcast their own unconfirmed transaction.
[19:11] jfw: ie it's a potential additional mining reward every time such transactions are issued; though if a miner takes it, the fork between gavincoin miners and bitcoin miners will manifest.
[19:12] jfw: node operators too, not just miners.
[19:14] jfw: nah, pub1 is a cattle style name - a function identifier and a number; pet style names are exactly that, proper names.
[19:16] jfw: the generalization to those two approaches depending on one's relationship to the machines in question is a side point really.
[19:17] dorion: jfw, ok. as far as the number identifier, is that relative to the deployment ? e.g. client1 has a pub1, client2 has a pub1 too.
[19:20] jfw: yes
[19:22] jfw: (one can add domain names if this becomes a problem)
[19:32] dorion: alright, we're delivering pre-installed/configured with our own labels. if we go with functional names, as opposed to purely numerical, the spare isn't going to be labeled for what it's going to be when it's live, since we don't know yet. when the time comes, client has to do that. if it's purely numerical, the label can be pre-applied and client just has to plug it in.
[19:33] jfw: exactly (well, plug it in and communicate what they did so we can update the docs, but this is the same in either case)
[19:37] dorion: is it a big deal to provide an extra set of pre-printed labels from the start ?
[19:39] jfw: not in itself
[19:40] dorion: seems like that'd be a good balance of functional names and cheap to maintain consistently.
[19:40] dorion: as opposed to bring your own, sticky notes + sharpie, etc.
[19:42] jfw: seems like a band-aid to me though as it only works once
[19:42] jfw: could then mail a new label I guess
[19:43] jfw: ah, which is fine as we'd be mailing a new spare anyway
[19:45] jfw: (that is, minimal marginal cost)
[19:46] jfw: if the spare fails before new one arrives... c'est la vie and that's why some things are already redundant
[19:46] dorion: mailing works then.
[19:48] jfw: and with this view, a permanent US base would be quite helpful for providing long-term support.
[19:50] jfw: so now I'm figuring for each box one label (permanent) with our SKU and serial number and another (replaceable) with functional name, and a set of spare labels for the latter
[19:59] dorion: ok, works.
[23:29] jfw: dorion: cool, thanks for the input. next decision in this vein then is the design of those stockkeeping unit & serial numbers - basically how to construct the "primary key" by which stuff we stock is identified as a class and as an individual.
[23:30] jfw: for s/n, it seems fine to me to continue using incrementing decimal numbers as we've been doing to some extent already
[23:33] jfw: for sku, the two extremes are fully numeric (decimal, hex or otherwise) or fully "meaningful" as illustrated for example by pcengines
[23:40] jfw: then there's whether the serial is unique across our whole catalog or just per sku; the latter has some (probably minor) advantage of brevity, but the global approach seems preferable to me; for one thing the redundancy provides a bit of error detection, and for another it simplifies issuance of new numbers if there's only one counter involved (eg can use an auto_increment database field)
[23:50] jfw: changing topics, I'm in the market for a new webcam, preferably with strong support on both windows & linux. http://www.ideasonboard.org/uvc/ looked nice and authoritative as far as what seems to have emerged from the battlefield of the 2000's as some kind of standard interface; except the reported USB ID for the "Logitech C310" on my desk disagrees with /usr/share/misc/usb.ids and actual
[23:50] jfw: observation
[23:55] jfw: and it's not just a case of different IDs released under the same marketing name - the one they cite is used by a different thing, "HD Webcam C510" according to usb.ids. Seems fair to conclude then that the "works" status is just as likely to be typo'd
Day changed to 2021-04-29
[00:00] jfw: nice to know the driver got merged in the 2.6 kernel branch though.
[00:13] jfw: I'll probably try "anyone but logitech" because their camera control software on windows is quite sad.
[02:39] jfw concludes the entire current crop of webcams, prolific as it is, is shit, and buys the cheapest logitech c270
[19:57] jfw: Wow... turns out the boot configuration menu on the apu1, provided by a "sortbootorder" Coreboot payload from the defunct Sage Electronic Engineering, saves its configuration state not to the battery-backed NVRAM used by every PC BIOS ever, such that popping the battery is all you need for a field reset, but to the boot ROM by way of an SPI flash protocol library (making it possible to brick the
[19:57] jfw: unit, for one thing). It WRITES, to "READ-ONLY" memory. Because they could, I guess.
[20:17] jfw resists the urge to rip it out straightaway, on the theory that the path to sanity starts by at least reproducing what exists & works
[22:04] dorion: http://fixpoint.welshcomputing.com/2021/jwrd-logs-for-Apr-2021/#1881 -- global is fine with me.
[22:04] sourcerer: 2021-04-28 23:40:38 (#jwrd) jfw: then there's whether the serial is unique across our whole catalog or just per sku; the latter has some (probably minor) advantage of brevity, but the global approach seems preferable to me; for one thing the redundancy provides a bit of error detection, and for another it simplifies issuance of new numbers if there's only one counter involved (eg can use an auto_increment database field)
[22:06] dorion: http://fixpoint.welshcomputing.com/2021/jwrd-logs-for-Apr-2021/#1888 -- perhaps a symptom of why they're now defunct.
[22:06] sourcerer: 2021-04-29 19:57:07 (#jwrd) jfw: Wow... turns out the boot configuration menu on the apu1, provided by a "sortbootorder" Coreboot payload from the defunct Sage Electronic Engineering, saves its configuration state not to the battery-backed NVRAM used by every PC BIOS ever, such that popping the battery is all you need for a field reset, but to the boot ROM by way of an SPI flash protocol library (making it possible to brick the
[23:02] jfw: could be; mediocre work for "proud prices" as the pcengines guy told me.
[23:05] jfw: another weirdness is that you can't enable or disable boot options, except for the PXE ROM for netbooting as a special case, only reorder them. not impressed with the subsequent work on it by pcengines / their newer contractor either, just piling on more layers of shit
[23:10] jfw: so far it looks to me like this feature would have been better done as a seabios mod rather than a separate thing, importing "libpayload" and all because why bother leveraging the BIOS code that it's already married to
Day changed to 2021-04-30
[03:27] dorion: http://dorion-mode.com/2021/04/elvin-coaljobs-euloran-gatherings/
[17:36] jfw: dorion: after another 10h this week of digging to get oriented to those 'SageBIOS' coreboot sources, my takeaway is that they're still crap no matter what angle I look from - but more interestingly, none of it appears to actually be necessary
[17:39] jfw: that is, I'm anticipating that I can use a stack of mainline coreboot (same one captured in '16 for thinkpads), mainline SeaBIOS (idem), and - here's the previously unknown - a mainline sgabios to accomplish the serial console redirection (which I'll note appears to have already existed, as a nice standalone thing, long before they went and did their own
[17:39] jfw: seabios based hack for it)
[17:47] jfw: the problem with the "start with what exists/works" approach as previously imagined for this case is that the archaeotarball that looks most likely to be such a thing has entirely dubious provenance while its parts aren't practically separable (e.g. to use just the extras as I'd been thinking) - "spittoon comes all in one strand"
[17:50] jfw: so the adjustment is that the mainline stuff also exists & works - not fully in the same way as what the apu1 ships with, but those extras don't actually add the value that I naively imaged they did.
[17:56] jfw: sgabios comes from Google, '08, which is mildly concerning, but I suppose that was back when google sorta worked, the chrome + apps virii had escaped the lab but not yet become a global pandemic etc.
[18:23] dorion: jfw, if it is actually the case that sagebios is unnecessary, sounds like a productive 10h. I'm not enough of a google expert to known the extent they worked in '08, if ever, but using the extant coreboot+seabios with sgabios --which I counted to be less than 3k LoC-- looks better than drinking the sagebios spittoon.
[18:25] dorion: so go ahead with trying the coreboot+seabios+sgabios and lets see what comes out of it.
[18:32] dorion: jfw, do you reckon this approach would mitigate the bricking risks described upstack ? or will you still start with the sortbootorder coreboot payload ?
[19:07] jfw: to expand a bit in case it's unclear: bricking is kind of a relative thing, eg for average windows user, clicking the wrong link on a web page can render the machine unusable to the extent of their capacity for repairs. in our case, we can always recover the ROM to a known state by means of in-system programming with chip-clip. that's rather a pain though due to the specialty tools, knowledge &
[19:07] jfw: time required. so brickable in this sense means "possible to make a mess through software means in the field that can't be repaired by same"
[19:10] jfw: strictly speaking, machine becomes brickable as soon as actual-ROM was substituted with pretend-ROM, but sortbootorder's offense is doing it as SOP with convenient UI for the foot-gun.
[19:11] jfw: so my argument is that sortbootorder - as one of the Sage extras - isn't actually necessary or useful.
[19:12] dorion: ok, cool, thanks for the clarity, make sense, looks like a big win, lets see how it comes out.
[19:12] jfw: if so, this doesn't just mitigate but eliminates the risk.
[19:13] jfw: cool