tmsr - Search: " T"

209900+ entries in 0.126s

a111: Logged on 2017-03-10 20:31 Framedragger: some (very initial) symlink stats - more stuff will have to wait - given a "here are 1mn 'transactions' which symlink to files, resolve links and read from linked files in random order for 100mn times" setup, with one-folder-deep structure, like so: "simple_f1/e5/e5edc34c57d5ea2ea99cfe16d04655aa000c3d7f268022d2b21f95928fa34674 -> /files_f1/99997.txt", most basic stats are:

mircea_popescu: http://btcbase.org/log/2017-03-10#1624551 << these are actually pretty encouraging as such ☝︎

a111: Logged on 2017-03-10 19:39 trinque: we'll make a CL lib for p

mircea_popescu: acid is not a bad idea in the sense "valentine's day" is not a bad idea.

mircea_popescu: (they do this, and they think they're smart for it, too.)

mircea_popescu: Framedragger i just meant "don't fucking rebalance my tree, behind the scenes, idiot!"

asciilifeform: mircea_popescu: aha, i started at one point to do it, and realized 'wtf why' ☟︎

a111: Logged on 2017-03-10 19:38 asciilifeform: trinque: then i'll need a cl pgp parser

mircea_popescu: http://btcbase.org/log/2017-03-10#1624528 << and this not worth doing, either, because just do p when it comes out and be done with it ☝︎

Framedragger: also just ftr, a b-tree by definition has every part of it be of the same depth. 'unbalancing b-tree' doesn't even make sense. but you could have 'just a normal tree', and one can implement custom indices. just pointing out

asciilifeform: btw it may even be worth taking top 32 and bottom 32 and comparing (fuck knows, sha(sha(x)) could produce different ! distribution, for no entirely good reason, for each )

mircea_popescu: compare and contrast with the mit offering.

asciilifeform: ( he asked 'what do' and i answered 'take all tx, from first to top of currentheight, and count how many share their senior 32bit )

mircea_popescu: asciilifeform in any case this is turning into QUITE the course on caching!

mircea_popescu: this theory of yours crashes on the jagged shores of a meaner reality.

a111: Logged on 2017-03-10 23:06 mircea_popescu: http://btcbase.org/log/2017-03-10#1624446 << there may be a lot of merit in this. even l1-l4 implemented via kernel table may be faster than freestanding l1 with "occasonal" (to be defined) cache miss aka collision.

asciilifeform: http://btcbase.org/log/2017-03-10#1624751 << ben_vulpes actually went off to calculate it, empirically!, earlier today, lessee what he comes back with ☝︎

mircea_popescu: there is no practical way to tell postgresql to do slave reads ; nor any way to tell ~any db to do unbalancing btree stores.

Framedragger: (also just for poterity it's not like you can't tell a decent db which indexing mechanism it should use. but i agree with main 'general tools are ~meh' sentiment)

a111: Logged on 2017-03-10 19:34 asciilifeform: Framedragger: i am increasingly finding that 'general purpose db' is, like the infamous 'vise-grip', The Wrong Tool For Every Job

mircea_popescu: http://btcbase.org/log/2017-03-10#1624517 << don't knock it too much, bunny-hop fuck-chair is fine tool for she who for the first time took her clothes off in public today. ☝︎

mircea_popescu: Framedragger yeah that's exactly it, the distributions

mircea_popescu: the rebalancing above a fine examplke of the fundamental problems.

Framedragger: ftr i didn't every say it was the right thing for bitcoin with uniformly distributed hashspace

mircea_popescu: asciilifeform no, no, nothing of the kind. i was contemplating no hardware whatsoever, just the tower of crud that builds up to consumer fs

asciilifeform: (i sat down with the ext4 thing and very quickly came to the conclusion that it, and every other konsoomer fs, is 'pessimized' for our specific scenario)

mircea_popescu: this is exactly contrarty to the engineering assumption in "balancing"

asciilifeform: mircea_popescu: aha! which is why i published an algo with 0 rebalance, today.

mircea_popescu: because any arbitrart hash has equal chances to be seen as next hash as any other.

a111: Logged on 2017-03-10 19:33 asciilifeform: Framedragger: but not right tool for ~this~ job

mircea_popescu: http://btcbase.org/log/2017-03-10#1624512 << rebalancing the tree is actually a terrible idea for bitcoin block storage. ☝︎

a111: Logged on 2017-03-10 22:23 mircea_popescu: im not against the idea in the slightest. i'm just very unpersuaded by the theory hard drives work, to any spec, in any sanemanner.

asciilifeform: http://btcbase.org/log/2017-03-10#1624688 << if you're thinking of the iron failing -- i operate disks in raid5 (and for past couplea years -- raid5 of ssd; on this particular box in this particular room, for instance, 4 x 1tb ssd) : 0 detectable failures-with-loss of any kind. ☝︎

asciilifeform: if you just need to store linear array of blox -- nothing beats raw hdd. fuck fs.

a111: Logged on 2017-03-10 22:21 mircea_popescu: the noion that hdd is usable or useful is a cute pipe-dream of the web generation, unsupported in cold reality.

a111: Logged on 2017-03-10 19:33 asciilifeform: Framedragger: all you need is to check a read candidate against the current list of active writes.

a111: Logged on 2017-03-10 19:19 asciilifeform: for completeness, i will note that you can model any 'whole disk' variant with an enormous flat file, in userland, at some speed penalty.

mircea_popescu: http://btcbase.org/log/2017-03-10#1624496 << experimentally this is almost never above 50% ☝︎

a111: Logged on 2017-03-10 19:11 asciilifeform: ( i wonder if there are any traditional fs that will actually give you 16G of contiguous blocks, if asked nicely )

a111: Logged on 2017-03-10 18:57 asciilifeform: i'd like to think of an elegant solution to this

mircea_popescu: http://btcbase.org/log/2017-03-10#1624468 << very much this. ☝︎

a111: Logged on 2017-03-10 18:40 asciilifeform: you can use x64's page table to 'cheat' and store a sparse form !

mircea_popescu: http://btcbase.org/log/2017-03-10#1624446 << there may be a lot of merit in this. even l1-l4 implemented via kernel table may be faster than freestanding l1 with "occasonal" (to be defined) cache miss aka collision. ☝︎☟︎

a111: Logged on 2017-03-10 18:24 asciilifeform: Framedragger: there was old thread with mircea_popescu , where he stated that usg and china attempted it at same time, and perma-deadlocked

a111: Logged on 2017-03-10 18:24 Framedragger: while at it, and i'm guessing it's in the logs.., i wonder when was the last time some tried to come up with an approximation what the costs to get to >50% network hashing power would be

mircea_popescu: http://btcbase.org/log/2017-03-10#1624417 << this is not accountable in dollars. ☝︎

mod6: perhaps not. i like that we're thinking about things like this though.

a111: Logged on 2017-03-10 18:20 asciilifeform: at any rate, working around this idiocy would be very cheap -- say we index by top32 of keccak(txid) instead of plain txid. in the event of.

mircea_popescu: http://btcbase.org/log/2017-03-10#1624413 << this truly isn't a concern. ☝︎

a111: Logged on 2017-03-10 18:17 asciilifeform: do the arithmetic, it isn't as if anyone can cancel the 'block per 10min' thing.

mircea_popescu: http://btcbase.org/log/2017-03-10#1624406 << they try; but yeah hehe. ☝︎

mircea_popescu: http://btcbase.org/log/2017-03-10#1624395 << your emulator stil lsucks what can i tell you. ai winter! ☝︎

a111: Logged on 2016-01-21 13:29 asciilifeform: 'if i make it what i think is the right size, it crashes!111'

a111: Logged on 2017-03-10 18:02 asciilifeform: (some time grep for the sleeps, it is instructive)

a111: Logged on 2017-03-10 18:01 asciilifeform: trinque: i've found that 'kill', which syncs the db, followed by kill -9, which nukes shitoshi's pointless wait idiocy, worx 100%.

mircea_popescu: http://btcbase.org/log/2017-03-10#1624375 << confirmed, this is safe. just don't issue the -0 before it hd a chance to settle down. ☝︎

a111: Logged on 2017-03-10 18:01 trinque: god forbid the disk always be in a coherent state, eh?

mircea_popescu: http://btcbase.org/log/2017-03-10#1624374 < heh. though this be a taller order than meets the eye. ☝︎

mod6: diana_coman, Framedragger: thanks

Framedragger: mod6: damn man, very sorry to hear that.

diana_coman: mod6, so sorry about that

a111: Logged on 2017-03-10 17:16 asciilifeform: the Right Thing would probably be to have a very simple kernel driver that takes a specially-marked disk partition and gives userland trb linear use of it, as plain array

mod6: <+mircea_popescu> http://btcbase.org/log/2017-03-10#1624297 << this sounds like a quite elegant solution, yes. << yeah, nice idea here. all of this is very exciting. ☝︎

mod6: On a brighter note, about to setup a new trb node this weekend outside of aws. So that's awesome.

mod6: Thanks Sir. Me too.

mircea_popescu: sorry to hear.

mod6: with chemo... could be 8-12. we don't think we'll do chemo tho. don't see much of a point.

mod6: <+mircea_popescu> how goes mod6 << eh, it goes. getting ready to release V 99994 here soon. mom was diagnosed with stage 4 small cell cancer about 6 weeks ago -- so that's been pretty intense.

a111: Logged on 2017-03-10 17:43 asciilifeform: imho the 'hard part' is not even to implement this table, it is freshman homework, but to unravel the liquishit in trb and learn where to even put the lookup/write !

mircea_popescu: because yes, alf is entirely correct, the hdds piss out 4kb or more per call

a111: Logged on 2017-03-10 17:36 asciilifeform: that is, you don't need 8 bytes to say which 4kB slice has the beginning

mircea_popescu: http://btcbase.org/log/2017-03-10#1624352 << this is a major part of the savings in fsdb ☝︎

Framedragger: ah, you're probably right. lots of fs-specific cache madness, too

mircea_popescu has seen architerctures where there were de facto 3 different disk caches

mircea_popescu: afaik it bundles a lot fo that in

Framedragger: (and yah i'm sure there's lots of crud in the former worth dropping..)

Framedragger: kernel driver would work around userland fs specific stuff. but certainly not against disk seek, disk cache, etc. just to clarify

mircea_popescu: dispensing with the kernel's accumulated gunk comes at no cost to the wizard, but at disability to anyone else.

mircea_popescu: im not against the idea in the slightest. i'm just very unpersuaded by the theory hard drives work, to any spec, in any sanemanner. ☟︎

mircea_popescu: i don't think anyone correctly represents the tower of accidental good luck that stands between a disk seek and your desired pron.

Framedragger: mircea_popescu: (i thought with "sounds great on paper" you were responding to possible kernel module workarounds. but if you're against the *whole* idea, fair enough.)

mircea_popescu: it's more the case that those 10k lines of ??? actually contain the mystery bullshit that makes the whole pile of crap evern work.

Framedragger: but yeh, maybe more exposure to userspace shite if not driver - maybe

mircea_popescu: the noion that hdd is usable or useful is a cute pipe-dream of the web generation, unsupported in cold reality. ☟︎

mircea_popescu: Framedragger it sounds great on paper and then crashes irrecoverably six weeks in.

Framedragger: (or, use linux cap to allow raw access, but that's maybe meh)

a111: Logged on 2017-03-10 17:19 asciilifeform: it is statistically possible that we don't even have ONE collision yet

mircea_popescu: http://btcbase.org/log/2017-03-10#1624307 << it is the case, one collision a year sort of deal./ ☝︎

Framedragger: not that it's necessarily the way to go. but consider what asciilifeform was saying - one could just pass an already-opened file handle. handle to *whatever*. no ring0 driver, no root permissions.

Framedragger: mircea_popescu: but if you read further down, we were saying that it may be possible to just access a raw block device without kernel module :)

mircea_popescu: http://btcbase.org/log/2017-03-10#1624297 << this sounds like a quite elegant solution, yes. ☝︎

mircea_popescu: http://btcbase.org/log/2017-03-10#1624290 << contiguity is the big problem. perhaps it can be resolved through "alternative starvation', as in, running naught else. but that is liable to run into the genius of "dwim" "modern" linuxhit ☝︎

a111: Logged on 2017-03-10 17:10 asciilifeform: if you're willing to blow another 16GB, you can have an l2 table

mircea_popescu: http://btcbase.org/log/2017-03-10#1624278 << this blowing seems altogether a foregone conclusion. ☝︎

a111: Logged on 2017-03-10 13:58 deedbot: http://phuctor.nosuchlabs.com/gpgkey/83747C8EA3613D6D3DEEEDE006197672FCB135ABA18188DB332E25098C44C765 << Recent Phuctorings. - Phuctored: 1650...4657 divides RSA Moduli belonging to '202.130.103.22 (ssh-rsa key from 202.130.103.22 (13-14 June 2016 extraction) for Phuctor import. Ask asciilifeform or framedragger on Freenode, or email fd at mkj dot lt) <ssh...lt>; ' (wtt22.smartinfo.com.hk. HK)

asciilifeform: http://btcbase.org/log/2017-03-10#1624149 << this is a hosting co in hk, and domain peddler. betcha ~all~ of their shithosting offerings, are debianized. ☝︎

mircea_popescu: possibly their best.

mircea_popescu: https://www.youtube.com/watch?v=kQFKtI6gn9Y << spare time.

a111: Logged on 2017-03-10 17:02 trinque: oh jesus docker Framedragger