Show Idle (>14 d.) Chans

← 2020-07-28 | 2020-07-31 →
feedbot: << Ossa Sepia -- What's Eulora's GUI Going to Be Like?
feedbot: << Trilema -- Due soldi di speranza
feedbot: << The Tar Pit -- Briefly, on programming IRC bots using Common Lisp
diana_coman: fwiw and as I just saw spyked's trouble keeping a node in sync on mechanical HDD - I can confirm it's possible, at least so far.
diana_coman: and I mean sync without feeding it blocks separately.
diana_coman: jfw - what's the exact definition of a "sane system" as required by your build system for trb or is there a different distro you successfully tried it on?
jfw: diana_coman: is an exact definition of sanity ever possible? anyway, so far not tested on distros besides Gales Linux. Apparently whaack had trouble building on CentOS which I mean to look into this week.
diana_coman: well, all terms were in the given tech context, you know?
diana_coman: so no, not asking for the philosophical exactd definition of sanity, lol
jfw: well for instance, I'm sure it can be got to build on CentOS, but that would mean it ends up with glibc and probably some degree of dynamic linking, which for a certain view of what a bitcoin node is, won't count as sane
diana_coman: aha; I simply wanted to figure out if it turned out so far more of a gales-advantage basically or there are other tested options.
whaack: jfw: My trouble on centos was that I needed to make sure `python` pointed to python 2.7 (instead of 2.6.6)
jfw: diana_coman: alright. my experience with HDD node which I'm guessing is what you saw
jfw: whaack: right, and that python is involved at all seems somewhat interesting. Probably no end of such hassles though so long as the DWIM-heavy build systems of the dependency libs remain in place.
diana_coman: jfw - that's the discussion, yes; thanks for linking it, too.
jfw: np
diana_coman: whaack - so then why not-sane re centos, I don't get it?
diana_coman: because no python 2.7?
jfw: meanwhile we've had a hot spell and I've left that test machine mostly off so the poor HDD node is a ways behind.
diana_coman: jfw - should add re hdd that indeed, when starting from 0, it all depends on what "bearable time for sync" means for one; yes, I sync-ed a node like that; no, I didn't mind it took a few months to get there (after that it remained in sync without any trouble really)
jfw: indeed. curious, did you do any bdb cache tuning there? I observed the default seems to be set quite low
jfw: but casual tests haven't shown much difference for me
diana_coman: no, I did not.
whaack: diana_coman: I said that centos does not make the cut for being a sane environment because of the point jfw made about dynamic linking. I don't fully understand the ramifications though, from what I gather the problem boils down to you don't know if the binary you get from compiling on computer A == the binary you get from compiling on computer B
whaack: I need to clear up some confusion of dynamic vs static linking and the problems with the former
diana_coman: whaack, it's true that the default install of centos iirc does not come with static linking, but this doesn't mean you can't set it up for that, lol
diana_coman: anyways, now I'm confused - did you manage to build trb statically linked on centos or not?
whaack: erm...I ran `make ONLINE=1` and have a running bitcoind, I'm not quite sure that it is statically linked
diana_coman: jfw - meant to say: I got around to give a spin to your full online/offline gbw orchestra and all went quite smoothly as far as that test went.
jfw: thanks diana_coman.
jfw: whaack, might be a start for glibc vs. musl which is a somewhat distinct question from dynamic linking
jfw: the enemy might make amusing reading re static linking - "it's no good, because I broke it"
trinque: > the libc
trinque: the only one, indeed.
feedbot: << Trilema -- Il delitto di Giovanni Episcopo
← 2020-07-28 | 2020-07-31 →