log☇︎
67900+ entries in 0.487s
Framedragger: can you not picture this setup with a read-only slave, with a *separate* "give new key to master" interface (separate so that the replication doesn't become write-write but stays write-read)
Framedragger: alright. i will grant you that the end system wouldn't be "oh so elegantly simple", because you would have to have a submission queue (maybe something that trinque had in mind). user submits key; gets permalink (immediately); meanwhile key gets sent to master (immediately), and master puts it into "to be inserted" queue. under normal loads, the insertion happens ~immediately, ☟︎
Framedragger: yes that's the tricky part. my natural answer to that would be to "drop it, have user be able to come back right away - to a permalink - but results only displayed when the upstream db actually processes and inserts the new entry. (this entry would then get fed into the slave via streaming replication)"
asciilifeform: the job where it takes you from a base64 gpg key you found on some godforsaken usenet post, to a permanent link in phuctor
Framedragger: are you absolutely unwilling to have a delay there?
asciilifeform: does he IMMEDIATELY get a bookmarkable link based on the key's hash ? that he can come back to next hour, next day, next decade ? if so, how ?? ☟︎
asciilifeform: what happens when a user submits a gpg key ?
Framedragger: well, i'm not that certain, but i am assuming you have more experience there with me. i will only remark that you merely need a *read slave*, not an actual mirror db which can handle writes and sync state. the syncing would go one way only. (hence the multiple references to pg streaming replication.)
Framedragger: now, complexity management-wise.. maybe; having same person manage both boxes may not be best idea (and the alternative has its own advantages). but the current "phuctor is down, i don't know why, it's a black box" isn't the greatest example of current setup, either. (this may be a red herring, i'm not sure)
Framedragger: of course being able to point to a working prototype would do so much more than arguments. unfortunately that would most likely require the needed modifications on the phuctor box, so a bit of chicken-and-egg.
Framedragger: asciilifeform: hold on. the idea was to separate reads from writes. having a separate box for www which gets updates from phuctor box, and having pg indices on it for quick search is *not* resource-intensive. i can cite examples but basically i'm quite certain that a <= 16gb memory box would suffice. phuctor box is 256 gigs yes, but it does *so much more*.
asciilifeform: 'oh gotta have clipboard be a separate process'
Framedragger: asciilifeform: the parallel to "this is how winblowz blew up" breaks, imho, if you consider the splitting-off of www not as an addition, but as actual splitting-off, i.e., the box with phuctor on it may no longer have a www interface (just an option, i know you may be against it). if you picture it that way, it's more about modularisation vs. fixing and inflating a single monolithic thing.
asciilifeform: http://btcbase.org/log/2017-04-07#1639884 << is it not obvious how creating MORE things that gotta be 'nuked later' is a problem ? ☝︎
asciilifeform: http://btcbase.org/log/2017-04-07#1639881 << i'll say that being able to paste in an unknown base64 pgp key and see a search result NOW, is not negotiable. ☝︎
asciilifeform: and this requires guaranteed consistency. right now i have this guarantee because there is one db, and not a multilevel morass.
a111: Logged on 2017-04-07 14:44 trinque: mircea_popescu: more clearly stated, I do not see a www as part of the algorithm of phuctor. it is one source of input where there could be many, and one output idem. with a clearly defined line between www and phuctor (even allowing for that www may require cached copies of phuctor data to operate properly), this gives you something you can nuke later and replace.
asciilifeform: http://btcbase.org/log/2017-04-07#1639880 << imho this is a mistake. the presentation of results is not ~cleanly~ separable from the generation, because certain situations (dupes, or the omission of a concordance factor/modulus/key linkage) must be HARD-guaranteed not to happen ☝︎
mircea_popescu: no i don't mean that. i just mean, yes in principl;e doing something with the plebs is not a bad idea ; but the exact what and wherefore coulo use more conteplation.
trinque: mircea_popescu: more clearly stated, I do not see a www as part of the algorithm of phuctor. it is one source of input where there could be many, and one output idem. with a clearly defined line between www and phuctor (even allowing for that www may require cached copies of phuctor data to operate properly), this gives you something you can nuke later and replace. ☟︎
shinohai: http://btcbase.org/log/2017-04-07#1639637 <<< This is what I said to Steemit evangelist R. Hilarski a few days ago when he accused me of just hating on altcoins. "When you lose all your BTC in scams, at least your wife is kinda hot so she can come by trilema and bare her tits for bits." ☝︎
asciilifeform: trinque: understand, first thing, and only thing , that a brute labourer would say re phuctor, is 'buy $mil of replication', 'use clouds', etc
a111: Logged on 2017-02-19 03:54 asciilifeform: (iirc we had a thread where i described how corporate ameritards, if given a problem like phuctor, would happily soak up a few $mil and megawatt of iron)
trinque: really the right thing to do here is sell a buncha fuckgoats, get asciilifeform rich, hire stable boy
asciilifeform: which is why fixes that retain it, seem like total waste of time to me ( i put a good deal of time into experimenting with db configs the last time we had this thread. and it made 0 measurable difference, for instance. )
asciilifeform: if i had insisted, phuctor would still be a waited-for thing ☟︎
asciilifeform: and yes, originally phuctor front end was to be a cl proggy
asciilifeform: now i can make a separate queuer just for offline subs
trinque: which is only a thing because www is 'daddy buy me a pony now!'
asciilifeform: trinque: another problem: i thought of having new submissions go to a queue, instead of main db. but! that would nuke the vey valuable 'paste in an unknown pgp key and know ~immediately~' feature.
mircea_popescu: might as well just make a proper cache table.
Framedragger: (when you query a mat view, data is returned directly from it, without touching the source live table)
trinque: thing's designed for parallelism yes, but of the same exact data in same spot is a big ask
trinque: it's a speedup for someone loading the stats page
mircea_popescu: trinque> materialized views are nothing more than a named query which stores its results in a table << this is a convenience not a speed-up
trinque: it grew beyond this scope the same reason bash did, or anything else that was originally a user interface
Framedragger: btw, i once screwed around with memoization in flask. iirc something can be done here as well, asciilifeform (it may be as trivial as adding a decorator before the function which handles GET request)
trinque: it's a goddamned spreadsheet; you're supposed to compute elsewhere and then fart your results in there so somebody managerial can ask it questions
trinque: so here's what relational db was supposed to be for, like bash originally had a 'supposed to be for'
Framedragger: and ^ is effectively a cache of sorts (useful here)
shinohai: lol Jason Dreyzehner "Head of Design" at buttpay followed me on twitter. Perhaps staring at T&A will be useful in making UI decisions.
asciilifeform: a very recent one . but i'll have to get back to you Framedragger re : which
trinque: materialized views are nothing more than a named query which stores its results in a table
Framedragger: again, no, and as per ACID, no dirty reads (*not a bad thing here*)
asciilifeform: what actually happens if you read a row being written
Framedragger: index-only scans allow to search in a table without 'touching', or 'locking' the actual rows (which may be simultaneously written-to, at the same time)
mircea_popescu: better do a 404 be sure.
mircea_popescu: asciilifeform re thehill : nah, they are just braindamaged. trilema works by bits, eg, http://trilema.com/2015/a-lunatic-with-a-bloodied-a takes you to article
mircea_popescu: have a rss queue, what.
mircea_popescu: go right ahead, produce a list of 5k rss items, THEN dole them out slowly.
trinque: could get me a pg connection and I could listen for pg_notify on a trigger of that table
asciilifeform: another gotcha is that the process that does the actual crunching is written in c and communicates solely via the db. it spends ~3min a day reading, but then ~all day checking 'do we already have this factor? ' writing it, in short bursts. but each of these bursts must show up in rss.
mircea_popescu: a db write is either insert or update ; finding out things is usually a select. it ~may~ be worthwhile to separate your reads from the writes, because it is technically possible (thopugh i'd hope unlikely) the db is dumb enough to put write locks in for something like "update x on y" even though it should be "select y if z then update x".
trinque: oh and 3) rendering www is a stage of work
trinque: two thoughts, beyond which a look at the actual thing would be needed. 1) queues and workers, always 2) db acts as your queue, schema reflects the stages of work
asciilifeform: and yes this can be done in bursts, as mircea_popescu described a while ago. but still gotta query whole db for mods
mircea_popescu: set a to a*b ?
mircea_popescu: your updates consist of "set a to b" neh ?
asciilifeform: mircea_popescu: db vacuum is not a sequence of writes for the purpose of subj
trinque: man, I've worked on pg databases that did nothing but write *and* read concurrently while sitting on a few hundred million rows
asciilifeform: the use of python for frontend was a mistake. i did it to avoid having to write gpg disasmer from 0, and www liquishit from 0
trinque: there's already a function that renders that page...
a111: Logged on 2017-04-07 13:12 trinque: simple fix is to crap out a stats page static file at interval.
asciilifeform: http://btcbase.org/log/2017-04-07#1639647 << in point of fact this is not simple -- right now the thing is wholly reactive -- proggy only runs per request. and is written in a lang having no actual threading... ☝︎
trinque: simple fix is to crap out a stats page static file at interval. ☟︎
mircea_popescu: a look, they're all "must oust assad".
mircea_popescu: is this a good thing ?
mircea_popescu: btw, whosoever wants a good dose of mosfilm in english, try "west point story". cagney's blond even.
BingoBoingo: A+++ surgeon
BingoBoingo: "Member when we had a white president who liked our country"
mircea_popescu: more accurately, it'd look like what a thing that looked like something used to look.
BingoBoingo: "Support our troops" took Dubya approval ratings from toilet to 80%+ Imagine what a war that ended would do!
mircea_popescu: so spend 2mn to make a pothole costs 300 bucks to fix ?
mircea_popescu: i might be a little slow on the uptake, but what is tomahawk supposed to do to airstrip ?
BingoBoingo: "rimfire" is a pain
asciilifeform: mircea_popescu: aha, this is considered a mega-crime in usa, ~same penalty as for being found with a crate of grenades, or aircraft autocannon. go figure.
mircea_popescu: lmao "one count of possession of a silencer" ? really ?
mircea_popescu: ah lol. i thought for a moment they actually were going for the fortifications there.
mircea_popescu: trinque well it'll be a little difficult to start another iraq seeing how the ru planes actually work.
BingoBoingo: "“Unlike the previous administration, President Trump confronted a pivotal moment in Syria and took action,” said Sens. John McCain (R-AZ) and Lindsey Graham (R-SC)." << Apparently Trump satisfied the Lich's war boner.
BingoBoingo: Bah, those are smaller ships and a couple converted ballistic missile submarines
BingoBoingo: Not a likely outcome, but possibru
BingoBoingo: And recently russian has expressed "limits" to support of Assad. Perhaps A-10 and Su-25 regime change Syria in harmony to MWGA
asciilifeform: '"Assad choked out the lives of helpless men, women and children," President Donald Trump said in remarks from Mar-a-Lago, his family compound in Palm Beach, Florida. "It is in this vital national security interest of the United States to prevent and deter the spread and use of deadly chemical weapons," said Trump...'
mircea_popescu: for the record, i was trying to watch a comedy. half hour in i'm like... feh, i wonder what trilema's up to
mircea_popescu: except it was a distance the helicopter actually flew at.
asciilifeform: i meant -- it may be an incredible feat of akmanship, or a snore, or a lucky shot (ww2-style), depending on distance, neh.
mircea_popescu: know from backchannels and the fact that the govt isn't making a point "oh, they had bazooka"
mircea_popescu: check it out asciilifeform isis shot down a helicopter
asciilifeform: ^ who has a winblowz box up ?
mircea_popescu: guy sounds like a roguelike
mircea_popescu: fromloper get a key, get a name, stuff.
deedbot: http://www.contravex.com/2017/04/06/tesla-model-3conomics/ << » Contravex: A blog by Pete Dushenski - Tesla Model 3conomics.
Framedragger: (apparently some couple of russians had a fight and one shot the other over a dispute regarding kant. i can believe that)
trinque: I by way of a sad life always write the where clause first
Framedragger: not a bad eventual outcome at all
mircea_popescu: and then it crashed because suddenly turning 10s of ks of article into a 3mb turd inflated the db.
Framedragger: i mean even if mircea_popescu aborted a db write, it shouldn't have forked into gigs of crap?..
CompanionCube: in the sense that it/the dump tool produced a overly-large 40gb file?
mircea_popescu: how is mysql a shit ?