log☇︎
200700+ entries in 0.122s
trinque: danielpbarron: seems ok, maybe my tar or gzip has the HIV
danielpbarron: and is it redundant to include sha512 on both the tar.gz and the iso?
danielpbarron: tar.gz only compressed it from ~708 to 682
danielpbarron: also please let me know if my format was right. I emulated mod6's thing but maybe there's a better way to do it with iso
trinque: danielpbarron: lets work on getting those in next week
trinque: then also danielpbarron this project with ISOs might take rewriting the downloader, will have to look at it
trinque: so, gotta untwist that
trinque: I'm getting on the previous batch of deeds that I have insufficient funds, which is bullshit.
danielpbarron: got them from different stores even
danielpbarron: will be interesting to see if my unopened 5.5 cd1 is the same bitwise as the one in the above mentioned deed
danielpbarron: i even have the missprint 5.8 and the replacement cd they sent afterwards
danielpbarron: i can do an unboxing video or something. i have 5.5 through 5.8 in original sealed packaging ☟︎
trinque: when we get it to work, all, far as I'm concerned
danielpbarron: on a related note, which openbsd cds are specifically wanted? i did 5.5 cd1 because i have that pack opened already, and because the more useful cd2 (containing amd64) got damaged when i tried to remove it from one of my iMac G3s that wouldn't spit it back out (it also has ppc -- probably the arch of interest)
shinohai: I was gonna say, all those trb artifacts were huge
danielpbarron: i was voiced obviously, but maybe deedbot had reconnected since then, and didn't see me as authed anymore?
trinque: got 10s of gigs over there free, nah
danielpbarron: file is 682M -- maybe that's too big? ☟︎
danielpbarron: http://btcbase.org/log/2017-04-07#1639551 << why didn't this work? ☝︎
trinque: any time
asciilifeform: ty for taking the sweat to puzzle over this, trinque .
asciilifeform: i'ma have to do some rtfm, to figure out how trinque's snippet worx.
a111: Logged on 2017-04-07 16:48 asciilifeform: trinque: can i , purely using sql query, force it to not attempt write ( and -- importantly -- to take no locks ! ) if an item already exists ?
trinque: http://btcbase.org/log/2017-04-07#1640077 << was direct response to this ☝︎
asciilifeform: trinque: this looks like it does exactly same thing as my current routine
trinque: does this query look up the mod IDs to append their factor arrays, or does your worker already know those
trinque: know mod IDs to update at this point?
trinque: array type in db or join table?
asciilifeform dusts off notebook, listens to trinque
trinque: the insert statement can return its id to a calling update statement
asciilifeform: for some of whom -- we may already know it, and have it in the indices
asciilifeform: it can potentially belong to 10,000,001 mods.
asciilifeform: ( a factor belongs to ~one or more~ mods )
asciilifeform: thing is, it also has to update the respective mod's factors indices array
trinque: or thereabouts
asciilifeform: trinque: can i , purely using sql query, force it to not attempt write ( and -- importantly -- to take no locks ! ) if an item already exists ? ☟︎
trinque: I'm of course shooting in the dark as to what happens when in what you have.
jurov: coinbr public announcement: there are some stuck orders, and it came at worst possible time. During the weekend I should be able to fix.
trinque: the "unique" is just an index which yes eggogs if insert happens and is already present. the eggog is just a matter of how do you want to find out about this
trinque: well one sec, so you're trying to establish relationship between keys and factors in the db, yes?
asciilifeform: is this in point of fact any faster than running a search and ensuring that there is no eggog query submitted ?
asciilifeform: it handles 3 cases : new factor of old modulus that had some known factors; new factor of modulus that had no known factors; old factor of modulus that had some known factors.
asciilifeform: do to the db, i mean.
asciilifeform: factors get created by the werker process (in c, and unable to do anything whatsoever other than to search for whether a particular factor already exists)
trinque: you have a keys table, factors table, factors has a unique constraint on value column of factors, there is a join table called key_factor which joins key and factor
asciilifeform: Framedragger: it means that the user doesn't immediately learn the 'do we know this key?' answer.
Framedragger: last note before i fuck off: the "user submits key; gets permalink (immediately); meanwhile key gets sent to master (immediately), and master puts it into "to be inserted" queue" + "all inserted + updated rows get sent back to slave via streaming replication and pg trigger" doesn't look like petrocheese to me. is all.
asciilifeform: and a ~very~ serious, imho, surrender. 'oh, this thing that you could do whenever you wanted in 2013? can't do it no moar.'
asciilifeform: but that ain't a solution imho.
asciilifeform: even, hell, distribute printed edition, like telephone book.
asciilifeform: and yes, if you were to throw out the realtime query ability, you could run phuctor as a 'newspaper'.
asciilifeform: this presupposes that the task can be cut.
trinque: you conflate the paper delivery kid with the printing works and the writers and, and, at your own design
asciilifeform: maybe i misunderstood the idea ? what was meant ?
trinque: I'm not defending that because it's not what I said.
asciilifeform: i do not need 'stable boy' for anything. there is no conceivable room, imho, for any such thing in any of my systems.
asciilifeform: imho to even suggest such a thing, betrays a very serious misunderstanding of the concept. dumb humans are in every respect an inferior version of the machine. the only thing more agonizing than programming comp, is programming dumb humans. ☟︎
asciilifeform: but meanwhile i also must address the 'stable boy' thing
asciilifeform: trinque: i'ma reread the trinque lines from log.
trinque: I refuse to retype it
Framedragger: (i'll just note that the *permalink* can be derived on the slave box, and nowhere did i say something contradicting this) ☟︎
asciilifeform: this in re the dual-db optimization, yes
trinque: so you're talking to me about Framedragger's whatever, k
asciilifeform: the dual db thing
trinque: ^ find reference for this pls
asciilifeform: i must point out, that i am unwilling to solve it by redefining the problem.
trinque: asciilifeform: you did not seriously cogitate on anything I sad for more than 5 seconds
asciilifeform: trinque: speaking strictly of this particular problem.
trinque: if so dispense with republic, bring on teh stalin
trinque: I find the notion that asciilifeform here is the only guy capable of adhering to own standards lulzy
asciilifeform: the performance wins described in this thread by Framedragger and trinque can only come at the cost of 1) massive increase in complexity, and in particularly state 2) loss of immediate linkability of freshly pasted keys.
Framedragger: asciilifeform: yeah i said some stupid things, apologies for depressing you there
Framedragger: if people decide to compromise on things after an agreement was made not to, i mean.. fuck those people
trinque catches up on thread, 1sec
asciilifeform: the apparent willingness of, e.g., Framedragger , to introduce petro-cheese is quite depressing
asciilifeform: ( to dispense, for instance, with immediate linkability )
asciilifeform: given that i found that various otherwise reasonable people are willing to make all kinds of compromises
asciilifeform: at one point i thought that giving it to other folx could be a reasonable thing. now i ~definitely~ do not
Framedragger: rewriting 60000 lines for this.. how does that follow..
Framedragger: asciilifeform: fwiw i'd be willing to set up a read slave on 16gb dedi box (siphnos, unmetered connection) for fri, that part is not hard imho. sure, if/when decision would be made to *actually expose it to everyone*, things could be moved (and maintained by someone else), but this is one way to prototype things.
asciilifeform: and if you think rewriting 600 ln. of python is painful -- try rewriting 60,000. which is what is being proposed : to give asciilifeform 60,000 lines to later inevitably rewrite.
asciilifeform: or the cost of getting a 2nd box with five-nines uptime.
asciilifeform: this is not even to mention the complexity cost.
asciilifeform: while retaining what i see as the non-negotiable features.
asciilifeform: i don't presently see them as cleanly cuttable apart
trinque: you *have* turdworks by your own decision to use www (which I think is reasonable)
trinque: not let them seep all through
trinque: my proposal was to put your turdworks in a box
asciilifeform: which issue trinque
Framedragger: (just so i don't feel like just throwing random verbiage at you, what i mean is something like `CREATE TRIGGER setup_send_update AFTER INSERT OR UPDATE ON phuctor FOR EACH ROW EXECUTE PROCEDURE send_update);` - it wouldn't be hard to try.)
a111: Logged on 2017-04-07 15:30 asciilifeform: this is how winblowz ended up with bookcase-length api, people.
trinque: http://btcbase.org/log/2017-04-07#1639899 << imma seriously start calling this russing over the issue if we get one more of y'all in here doing that. ☝︎
asciilifeform: and if ANY of these exist previously, incl. from a submission 5 seconds ago -- they gotta be correctly linked
Framedragger: that is fine, and a postgres trigger would mean that any affected row gets sent off. i do understand that new-key-addition is a db-intense process, of course
Framedragger: which means, "whenever new row, send it off [without having to execute a new select query etc]"
Framedragger: it is updated in ~realtime from the master via streaming replication
asciilifeform: and the cached copy is updated when ?
Framedragger: it reads from the cached copy, damnit.
asciilifeform: and from where, do you think, it reads ?
Framedragger: but you no longer reading from the front (in the sense of sql queries), which in db-land is good for performance.