242300+ entries in 0.142s
Framedragger: anyway, i imagine a bunch of d(a)emons fighting for i/o... and yeah no one is saying
that
there's a straightforward solution...
mircea_popescu: i dunno
that alf is a db engineer by
trade, so it's entirely possible specific measures could help, especially if
they're of
the magic number ilk of "set X
to Y in config file, we didn't docum,ent
this anywhere but its
tru!"
Framedragger: this reminds me. you know, sometimes postgres prefers
to do sequential read instead of using a reasonable index, because, as it estimates, using index would involve
too much seeking etc. *but* with SSD, random access is much much faster. (and btw postgres does not automatically know about seek
times in SSDs..)
mircea_popescu: a similar situation
to how compression works great on literature and poorly on (proper) random strings.
mircea_popescu: in general db optimization / low consumption success stories rest on a very opposite situation -
the lines are only ever interesting in one perspective and light only lights one facet at a
time sorta
things.
mircea_popescu: lol. yeah, might work here, it's not clear.
the problem, you have
to understand, is how integrated
the data is. sure a db with however many lines did fine in whatever box.
the problem is
that everything phuctor has, phuctor uses, and so it's very close
to
the unmitigated nightmare which is "random access"t
Framedragger: (master + 1 single slave sounds reasonable
to me fwiw)
a111: Logged on 2016-11-19 18:55 asciilifeform: we are at
the farthest possibly limit of what can be done on one box, at anything like reasonable budget (whether paying
the cost of a small european flat for a server for public service is 'reasonable' is separate question)
mircea_popescu: be marked as dirty after each insert if need be etc. possibly phuctor has grown industrial enough
this is actulaly needed.
a111: Logged on 2016-11-19 18:52 asciilifeform: Framedragger: db being hammered 24/7 with 'do we have
this hash' 'do we have
this fp' 'add
this and
this' 1000/sec is
the bottle.
mircea_popescu:
http://btcbase.org/log/2016-11-19#1570951 << for
the record, separate dbs for selects and inserts is
the way
to go. from experience it can rescue a large project / save 9x% off
the hardware costs.the way you do it is
that you have a master db copy which is
the only one
that
takes
the inserts, and slave dbs which are
the only ones
that
take
the selects. replication can be at dedicated sql cluster level or above, slave dbs can
☝︎ a111: Logged on 2016-11-19 18:48 mircea_popescu: and if
there's
to
there's no loss.
mircea_popescu: and from my pov, V is
truly great in
the sense
that it allows a very simple
test for when april next rolls around. phf's viewer
trivially allows
to see what signatures are actually active in
the deployed branches of republican code. join
that set with
the set of box owners and you have a very good first approximation of
the l1.
a111: Logged on 2016-11-17 14:43 Framedragger: (and on a side note, "hang out on #trilema after splitting with gf" has been one of
the more constructive choices i've made in my life)
BingoBoingo: There will always be enough stuff
to be done in
the future.
This is not a reason
to not make
things and move into
the done category.
mircea_popescu: not
that
there's anything wrong with running your own service on your own box. but
the pill for collaboration exists and is used.
mircea_popescu: we have V specifically so it saves us from
this box-owner / code-writer confusion.
mircea_popescu: Framedragger
technically yes you can - make a V root for it, like properly sane people,
then he'll just import
that / patch it himself when he's ready.
Framedragger: yah but
there's also enough of stuff
to be done :) if
trinque does WoT browser i won't do in parallel just so
that
there are
two
BingoBoingo: WoT browser is like log viewer, who
the fuck cares how many
there are so long as
there is a non-zero number!
Framedragger: or one could even dare
to develop something collaboratively, but
the republic would surely segfault
then.
☟︎ Framedragger: BingoBoingo: k; but direct
this at
trinque, unless he gets convinced
that he wants
to do
things sequentially and in payment-system-first order :p
BingoBoingo: Framedragger: Wot browser must also maintain existing url structure
to retrieve a nick's profile
a111: Logged on 2016-11-19 17:17 asciilifeform: ben_vulpes: heathen-facing publicationtron is inherently contradictory
thing .
mircea_popescu:
http://btcbase.org/log/2016-11-19#1570790 << amusingly enough,
this is actually
true. "i would like
to lecture
these monkeys in modern psychology" "ok ?" "can you design a shitproof semipermeable membrane
that still allows my precious words
to reach
them ?" "uh. not really. whatever
the fuck it is, sooner or later
the shit will clog it"
☝︎ Framedragger: sure. "javascript in
the backend", etc etc etc.; i mean, it's still a horrible language. but yeah.
mircea_popescu: tbh i
think javascript is not ever hated in
the context of its original domain, "make drawn man move his arms" ; it's whenever it
tries
to be other
things
that it draws ire.
a111: Logged on 2016-11-19 17:03 Framedragger: regarding visualization, a more condensed question: if a javascript-using
thing were delivered, would
this be hated upon (and berated by asciilifeform) and accepted if otherwise good and properly maintained, or hated upon and dismissed (and berated by asciilifeform)? :)
a111: Logged on 2016-11-19 17:03
trinque: anyone else is going
to have stale data
mircea_popescu: might discover it fails via resource exhaustion in
the very large dataset
that is
tmsr wot, but who knows. worth a shot.
a111: Logged on 2016-11-19 16:57 Framedragger: re. visualization, i like stuff like
this (mouse over on labels around
the circle), but it's a hella lot of JS, and i share
the hate
towards
the latter:
http://bl.ocks.org/mbostock/7607999 - what's nice about btcalpha visualization is
that it uses by-now standard html5 canvas directives (<path>) with no need for JS.
a111: Logged on 2016-11-19 16:45 Framedragger: i suppose
the idea could be
to re-implement
that, but using deedbot's view of WoT, and add additional
things as desired.
mircea_popescu: and yes, we're woprking on fixing
this.
the work is wide, and we can't get over, some handsome rovers from
town
to
town etc.
mircea_popescu: but
the point remains, mtbf in linux world is NOT years.
mircea_popescu: point in case here. it is beyond even
the shadow of
the most absurd doubt
that alf's code locked
the box. but he's willing
to spend
time fighting
the obvious, rather
than anything else, because hey,
this is a bitter pill
to swallow.
Framedragger: asciilifeform:
then, i
think, box needs
to physically reside with someone in your WoT. i'm just saying. maybe cheap slippery slope sophism.
mircea_popescu: asciilifeform you gotta learn
to judiciously allocate your
time ; Framedragger
the problem isn't so much locking up
the box - it's
that
the box will fuck up,
this being "foss" bullshit, and
then
the owner will be like "i dun wanna pay for a box i can't use, notwithstanding
this is what i claimed i want".
a111: Logged on 2016-11-19 16:36 mod6: Anyway, now
that it seems
that private a more rich
ticketing system is wanted,
these
things can be considered for sure. Salud!
Framedragger: (this is a case where i am more cynical
than asciilifeform: a DC you don't know, what illusions does one have; okay, one could install a sensor which signals if box was 'tampered with';
they could still
take box offline, clone memory, set up a replica. etc etc etc.)
mircea_popescu: not saying it's not possible, but in practice above pay grade of most dc
techs.
mircea_popescu: afaik it can't actually dump ram or do useful debugging. but it can reboot
the system, which is you know, a crossed wire.
mircea_popescu: anyway. in
the intervening years
there's
this new approach
that dcs favour because cheaper.
mircea_popescu: what exactly did you
think you were asking when you asked for
the dc
to kvm in your box and fix it for you ?
mircea_popescu: apparently
the divergence is winder
than previously realised. anyway - ipkvm capable chipsets come with ipkvm.
a111: Logged on 2016-11-19 16:16 asciilifeform: i wrote, in
the qntra piece, 'examine debianized boxes for nsaware'. now 'owner' will have a chance
to clean up before any mass 'examination'
takes place.
a111: Logged on 2016-11-19 16:07 pete_dushenski: of lines of code and
that many chinese sensors ~will~ fail at some point. and it will be unexpectedly. and catastrophically.
Framedragger: by
the way, i haven't ever used it, but from reading around it appears
that streaming replication may indeed be quite efficient. every
time row is inserted, row is sent off
to remote replica. but
this does not really require cpu. so maybe it wouldn't slow
things down further / wouldn't be particularly slow even if db being clobbered 24/7
Framedragger: wonder what was
the memory status. maybe in syslog
Framedragger: but yeah, i've noticed
that sshd works just fine (incl accepting new connections) even if cpu at ~100% and/or no free disk space.
there's
that.
☟︎ a111: Logged on 2016-11-19 19:24 asciilifeform: 0328 hours lithuania
time.
mircea_popescu: i dunno
that
they actualy bother keeping it for client managed boxes.
mircea_popescu: though i must confess syn flood had a better ring
to it altogether.
mircea_popescu: there is no such
thing as code with guaranteed jack shit on linux. next question.
mircea_popescu: now stop
thrashing about, write better code in general and make
the above call so
this can go on.
mircea_popescu: asciilifeform in point of fact i have asked
the public force
to locate car drunk ho abandoned "dunno where".
they did. i didn't
throw a shitfit about "o noes surveillance state".
this because a) i asked
them
to do it and b) obviously
they just put
the number in
the stolen cars interface and
then a patrol saw it.
mircea_popescu: it's a fucking admin interface bridged into
the fucking bus, what
the everloving shit would it care about your derpy os's notions of "users". as if
those fucking EVEN WORK irl.
☟︎ mircea_popescu: well, until you insisted i ask, nobody did. once i ask,
they gotta do specific
things.