150100+ entries in 1.114s

mircea_popescu: anyway, all this is (as you prolly expect it from shit i do) very much experimental. trying to actually make
a site where users can safely use their ips.
mircea_popescu: i think they spent
a coupla million real dollars on that gateway
assbot: Logged on 19-07-2015 19:09:25; decimation: also, I don't know what the 'web 2.0' thing he posted
a picture of is? is that some kind of dns control panel?
mircea_popescu: anyway, zee germans have gained
a very petty habit of being miserable to the people they owe gratitude to. no hitler statues, put that kohl fellow in jail...
mircea_popescu: specifically re 13 : if isis submits
a bid to buy out raytheon, this proposal will not go to the shareholders. it will go to
a so called "anti trust regulator" or w/e, which will reject it.
decimation: it's
a fair point, he probably didn't believe it in his heart of hearts
mircea_popescu: not that the guy is pointedly "against populism", admitting for the sake of argument that tyhe concept even holds meaning outside of its proper reference (it is after all
a notion of democracy). but then again the bar for "not being x" is not "being patently against x"
decimation: "7. We demand that the State shall make it its primary duty to provide
a livelihood for its citizens. If it should prove impossible to feed the entire population, foreign nationals (non-citizens) must be deported from the Reich."
mircea_popescu: (great film btw, murphy is the heir to the throne of zamunda, pursues some ugly nigglet in queens. who doesn't like him because he's rich, and to their assheads at the time in the 80s this is
a flaw)_
decimation: yeah, but the main point is that hitler was
a populist dictator who actually delievered on his promises to
a great degree
mircea_popescu: as hitler correctly figured out (and plainly said so) , the only future of germany as
a nation lay in the destruiction of britain as an empire.
mircea_popescu: so
a slightly larger germany. still no different from the previous situation.
mod6: don't challenge me to
a spelling contest, i'll lose.
mod6: yeah. well, i think i'll just prune by hand if I do at all. like i was saying earlier, im
a bit paranoid now that some script might later accidentially remove the dirs if they're rendered empty.
decimation: I suspect you are gonna need
a shell script, like ascii suggested.
mod6: there's
a bunch of lines that reference it actually, and no, i was hoping to get rid of these barnacles without having to change other files.
decimation: it's pretty likely we would have germany+us+ussr today, or at least they would have been
a 'triumvirate' during the cold war
ben_vulpes: i am clearly not elite enough to set my own priorities, otherwise i'd be down on the beach with
a margarita and my laptop
phf: it's totally
a makefile.unix artifact, since building with cmake/clang works without them
ben_vulpes: i've been able to get on the computer for maybe 10 minutes max at
a stretch over the past few days, or i'd take
a crack at it myself and figure it out
ben_vulpes: mod6: re gitkeeps do we even know why those empty dirs are necessary for
a succesful compile?
☟︎ decimation: it's not unlike the ddos/spam problem mentioned earlier - each entity sees the street and sewer vaults as
a zone to stuff shit for 'free'
mod6: <+mod6> so... yah,
a bash script or removal by hand. would be fine i'd think. but now i gotta test it
a bit harder. if we leave empty directories in there, im worred that patch might come along at
a later time and be helpful again, removing those object output diretories. << so if i do remove them by hand, have to ensure that these empty dirs wont get nuked later on accident
assbot: Logged on 19-07-2015 18:34:53; mod6: but now I'm scared that even if i /do/ remove them by hand, they might get accidentially pruned by
a downstream patch (later in time) causing the makefile to puke.
mod6: <+punkman> mod6: ben reminded me to add
a patch that removes the 5 .gitignore files. << I dunno why patch was needed for this, just remove them manually in next release << yeah, i mentioned that after the fact lastnight. but was discussed here:
http://log.bitcoin-assets.com/?date=19-07-2015#1206370 << this makes sense.
☝︎ phf: i think maybe getblocks already works like "get block N" where n is block height. client sends out his top block on
a chain, and server responds with
a sequences (?) of blocks from then on
punkman: asciilifeform: I don't really have
a theory. are we sure that nuked orphanage can't cause more wedges?
punkman: mod6: ben reminded me to add
a patch that removes the 5 .gitignore files. << I dunno why patch was needed for this, just remove them manually in next release
phf: well, that's certainly
a way to cut gordian knot
decimation: actually such
a command would be very useful for
a 'fork detector'
phf: asciilifeform: of course the easiest option is to add
a new network command, that does
a sane request for initial block chain parts, but i think it can still be done within the framework of current sync model
decimation: asciilifeform: was that taken at
a zoo?
decimation: yeah, it's
a fair point. that point has been made
decimation: jurov: I was envision the miners paying for your caches, on the assumption that most folks won't want to pay
a third party to clearn bitcoin
phf: mucking around with the code that desides what blocks to send to
a requesting client
phf: asciilifeform: it's not
a permanent stuck, but
a slowdown. i haven't sent out that orphanage graph that i posted some time ago, because i'm still kicking shit around, but the beahior that you can see from it, is that blocks are sent out as multiple subchains. when
a subchain arrives that's missing
a parent subchain, it gets rejected many times over and over, until parent subchain is filled in. i think the behavior can be improved by
decimation: yes, but you would agree that building such
a network with an eye toward minimizingn latency everywhere would be expensive
☟︎ phf: re: orphanage, i'm still investigating, but there's no reason why we can't have
a better initial sync block handoff strategy, that doesn't get stock, because some parent in an orphanage subchain failed to get sent out
decimation: the pre-digital version was expecting some kind of handout/human attenion being paid to
a stranger
assbot: Logged on 19-07-2015 18:34:53; mod6: but now I'm scared that even if i /do/ remove them by hand, they might get accidentially pruned by
a downstream patch (later in time) causing the makefile to puke.
decimation: my earlier proposal of 'charging per packet routed' is
a jungle way of implementing this
decimation: probably could go to opencores right now and find
a crypto block
decimation: now, the scammer could discover
a 'credited ip' and run down its account
decimation: you could put
a packet counter pretty easily
decimation: also, I don't know what the 'web 2.0' thing he posted
a picture of is? is that some kind of dns control panel?
☟︎ assbot: The lulz of today, or "you think it's only some kids that will exhaust their resources soon?" on Trilema -
A blog by Mircea Popescu. ... (
http://bit.ly/1TKLzL8 )
mod6: maybe the best option is to add
a one line shell script that just does: `find . -name ".gitignore" -exec rm '{}' \;`
mod6: i might just be dumb. build
a test env with
http://dpaste.com/23VKWD8.txt and see if anyone can get the rm_gitignore.patch file to apply without removing the obj/test obj/nogui or obj-test dirrs
mod6: so... yah,
a bash script or removal by hand. would be fine i'd think. but now i gotta test it
a bit harder. if we leave empty directories in there, im worred that patch might come along at
a later time and be helpful again, removing those object output diretories.
mod6: ben reminded me to add
a patch that removes the 5 .gitignore files. seems easy enough, so crated
a quick patch, attempted to apply, worked fine -- I didn't notice that it blew away the directories as well though. : obj/test obj/nogui obj-test
mod6: but now I'm scared that even if i /do/ remove them by hand, they might get accidentially pruned by
a downstream patch (later in time) causing the makefile to puke.
☟︎☟︎ mod6: i searched lastnight for
a looong time to find anything to tell patch to no prune empty directories, but it doesnt seem like an available option.
mod6: So this can be used as
a test platform for all the patches, etc. . If you're really ambitious you can install gentoo as above ^^ then use this to pull down the v0.5.3.1 basecode and apply these patches:
http://dpaste.com/23VKWD8.txt mod6: oh and there is
a new Gentoo guide for nomultilib/glibc -- I created it yesterday & trinque verified as well: