3600+ entries in 0.016s
Framedragger: true. and treating it differently leads to mismatched expectations.
Framedragger: ("supposed" and "putting this together" is really stretching it, but i agree that "hey i didn't commit to anything" is a really shitty attitude, of the same kind as "i hacked up loggotron but it's bad lol")
Framedragger: i told gabriel i'd be interested in reviewing clim-web etc.; he sent me a very nice email with instructions incl. setup; this was 20 dec; i didn't have time to look at it.
Framedragger: i was not supposed to do anything gabriel_laddel_p. stop with the passive aggressive tone already, it's annoying
Framedragger: well, i'm sorry if i angered you, did not intend that :)
Framedragger: this reminds me of when i earnestly tried to pull a "do you even positivism" russell's teapot "prove it" on mp re. his claims on Tor
Framedragger: take it easy friend, things can be said and appreciated in jest :)
Framedragger: (i don't really see why you'd have to trust this intermediary node, though)
Framedragger: admirable approach, but not very pragmatic. then again, pragmatic things can lead to bad places, too...
Framedragger: whatyougonnado.jpg ; fwiw gabriel_laddel_p i'd lend you a vps for a month for free (i wouldn't have access to it) just so that you'd stop pissing people off, but your call of course
Framedragger: mircea_popescu: ah, that's pretty cool. i see what you mean - you can see craters and the dark side still being the moon... collective delusion / cognitive dissonance something something! (and btw i meant the album but both work well in this instance..) :)
☟︎ Framedragger: iirc same evening included me "really getting" dark side of the moon, "like really getting it you know?"; but eh, it was beautiful so can't complain.
Framedragger: luckily enough i realized i was on hash before i could quickly set up a blog in haskell and start writing stupid words about the singularity
Framedragger:
http://btcbase.org/log/2017-01-07#1598383 << reminds me of how i first chanced upon lisp. i was eighteen, more pretentious than now, and had eaten my first hashcake half an hour ago. i was reading esr, jumped to topic of lisp and homoiconicity, and was like... d0000d. this is how you penetrate the universe. knowwhatimsayin.
☝︎☟︎ Framedragger: btw trinque i don't think my gpg key has all the associated ratings in your wot.deedbot.org wwwtron. but mebbe the latter isn't finished anyway, so i'm jumping ahead of myself :)
Framedragger: ah yeah. there was an old 3g modem plugged into internal pcie, i removed it. pretty lulzy
Framedragger: (i want to connect my x220 which does not have thunderb0lt)
Framedragger: asciilifeform: k, good to know, thanks. it's just one bus lane afaict (pci express x1), ExpressCard 2.0, so 'double' the bandwidth i take it. 4-5gbps total
Framedragger: right, i can see how that can be bundled up into a business product.
Framedragger: ever done something like that? :) portable rig is portable.
Framedragger: aha, otherwise too much bandwidth gfx card <-> cpu apparently
Framedragger: (not worth if you have a really high end gfx card tho - waste of money)
Framedragger: OT, anyone's done an egpu rig on an x220? i'm probably gonna do an abonimation, and connect an nvidia card to x220 via its expresscard slot. there's this antichrist-like adapter (
http://www.hwtools.net/Adapter/PE4C%20V2.1.html) which does the magic. bottleneck is expresscard (5 gbps or somesuch) but if one uses external monitor, it's all pretty good apparently.
☟︎ Framedragger: it's a well known fact that an unbalanced high number of parentheses results in irc ping timeouts.
Framedragger: !~later tell gabriel_laddel_p "I cannot presently maintain a connection to IRC." << get a bouncer ffs. ping me if you'd like a free one
Framedragger: from glyf.org source, '<meta name="ICBM" content="39.083611, -77.148333" />' << rockville town square, ~15mi north of washington, dc :p
Framedragger: that handwritten card looks rather lovely i must say
Framedragger: medium: "However, in building out this model, we realized we didn’t yet have the right solution to the big question of driving payment for quality content." ahahahahaa another startup realizes that this exotic nuance of balance sheet called REVENUE cannot be simply california-sun-wished-away
Framedragger: some airlines (such as ryanair) try to stuff the user with tons of shitty offers before reservation confirmation page. horribru UX. such m0netizzation $trategy. imbeciles indeed :/
Framedragger: this one time, i was scriptifying cheap flight booking. was amazed how less-laggy the simulated/automated 'browsing experience' (website didn't like bots, needed to convince it by running part of actual browser) was (cf. manual clicking on airline's website). got depressed
Framedragger: i suppose you also avoid the 'why does a multibillion clock machine lag on key press omfg' fail as icing on the cake.
Framedragger: (i at least check that my webpages look good on lynx/elinks)
Framedragger: yeah, gossipd client != browser. market share matters hm.
Framedragger: (fwiw sandboxing efforts look nice and more technically involved; question is how easy it'd be to apply work done there to other browsers and so on; if not, meh)
☟︎ Framedragger: so suddenly the numbers of wide populace matter? :)
Framedragger: i guess you meant conceptually dead, and with definite practically-dead event horizon in sight
Framedragger: so turn off such on-by-default leakage (and other leakages for fingerprinting), etc.
Framedragger: simple, high-entropy fingerprint of a computer. In fact, the hash of the rendered image can be used almost identically to a tracking cookie by the web server."
Framedragger: certainly nothing of huge import. some of those are definitely a bit snakeoil'y, but not completely useless. i don't know how much you care about e.g. browser fingerprinting. right now html5 canvas leaks badly, i.e. "The adversary simply renders WebGL, font, and named color data to a Canvas element, extracts the image buffer, and computes a hash of that image data. Subtle differences in the video card, font packs, and even font and graph
Framedragger: We think that Key Escrow is a Bad Thing; however the user should have the freedom to decide whether to go to prison or to reveal the content of one specific message without compromising all messages ever encrypted for one secret key. DON'T USE IT UNLESS YOU ARE REALLY FORCED TO DO SO."
Framedragger: "Display the session key used for one message. See --override-session-key for the counterpart of this option.
Framedragger just learned of existence of "--show-session-key" in gnupg. "hehe"
Framedragger: random film recommendation for weirdos: cannibal holocaust ("cannibal exploitation horror film")
Framedragger: (but then, duplication different cache layers != "general gpu cache for everyone yolo!1")
Framedragger:
http://btcbase.org/log/2017-01-02#1595160 << right! (well, some duplication is not bad in itself - os can be dumb about higher-level cache but may want something for optimising/aligning disk i/o and so on. but this sometimes leads to complexity it appears, and may be unwanted in the first place (e.g. in phuctor)...)
☝︎ Framedragger: (and according to .kr banks, have a few people sit at table and literally stare at teams, making notes. such conservative bank, hasn't changed them into robots yet)
☟︎ Framedragger: without being snarky, i think one guideline would be "announce more than 0 days in advance" :)
Framedragger: re. latter, yes postgres doesn't instruct, apparently it's efficient on bulk writes that way, as the os can use its own cache to optimize the write order etc..
Framedragger: hm yes fair enough re. former. unknown what to do when process restarts, too, etc.
Framedragger: random sorta-cs'y question: are there any os-level cache implementations which make use of clock sweep (or something more sophisticated), cf. just simple LRU? (reading about caching strategy in postgres and possible duplication of data blocks at postgres cache level + os cache level).
Framedragger: (actually, i'm sure you've considered all this, so sorry for assuming you may not have)
Framedragger: but they expanded my cell's volume so i have room to walk around now
Framedragger: probably a useful piece of code to have anyway; actual tests for proper maintenance. :)
Framedragger:
http://btcbase.org/log/2016-12-31#1594781 << hmm. what i could do is, check that all generated gpg keys have the right e and N (by comparing to the e,N,IP CSVs that i fully trust); to make sure that i didn't mess up the gpg-generation thing. i don't think it'd be really possible, and i had done some manual checks before, but maybe worth to write an automated full-on test.
☝︎ Framedragger: docs say would need to get rebuilt only if there were any unwritten changes. which there shouldn't be as asciilifeform is not using write cache
Framedragger: (and follow-up, does explain analyze show the use of that index)
Framedragger: i suspect then that the inserts/sec slowness is due to postgres currently making really damn sure that *all* layers of cache are forced. this "full forcing of cache for every row" is what makes things slower; but it's also the only really-super-reliable approach for the case at hand (remote box).
Framedragger: mircea_popescu: because you could tell postgres to flush rows (forcing all caching layers) every 100 rows, not every 1 row as currently specified
Framedragger: right. either it's completely-reliable, or NP-complete complex dragons in a cave
Framedragger: mircea_popescu: consider a scenario in which you knew how much data you could lose ("up to 100 last rows"), and you could check if you lost any (last row id == last-id-processed.txt ? false : true). that being said, this way things become more wibbly-wobbly, so probably fuck that. :(
Framedragger: "Note that open_sync writing is buggy on some platforms (such as Linux), and you should (as always) do plenty of tests under a heavy write load to make sure that you haven't made your system less stable with this change. Reliable Writes contains more information on this topic. " oh god. more inserts/sec but zero data loss => probably can't help you much. documentation doesn't encourage me :/
Framedragger: but this way you would constrain any losses to particular known amounts.
Framedragger: here's what i'm thinking: disable synchronous_commit , but set 'checkpoints' so that results are flushed to db every $n inserts/updates. i can see however how you may barf from such an idea, "it's either reliable, or isn't".
Framedragger: "lose weeks of work" is insane :( i'm sorry to hear that. *this* would not expose you to that scenario. but one would have to pin down still-possible data loss scenarios, if any.
Framedragger: << need to understand just what does that imply..
Framedragger: "For situations where a small amount of data loss is acceptable in return for a large boost in how many updates you can do to the database per second, consider switching synchronous commit off. This is particularly useful in the situation where you do not have a battery-backed write cache on your disk controller, because you could potentially get thousands of commits per second instead of just a few hundred."
Framedragger: asciilifeform: docs advise heavily on enabling write cache (but (sanely) insist on battery backup in that case) for your 'loads of inserts per sec' use case..