4700+ entries in 0.097s
BingoBoingo: Could be this last century hasn'
t had Janissaries. Just social security in disguise.
mircea_popescu: a game being, definitionally, "i don'
t want to KNOW what it does, i want to DISCOVER what it does"
a111: Logged on 2019-06-01 12:49 mircea_popescu: asciilifeform, i'd much rather dump a package deal than baby this box. i figure the grand or so it cost ain'
t worth an hour of my time
mircea_popescu: the logic behind
http://btcbase.org/log/2019-06-01#1916530 if it wasn'
t self obvious : secure box and gaming box are exactly opposite design constraints. computer games (as a distinct and opposite category to eulora) are by definition code that'll run on your box without your having run it. if you're going to do that ANYWAY, might as well save your time.
☝︎ mircea_popescu: asciilifeform, i'd much rather dump a package deal than baby this box. i figure the grand or so it cost ain'
t worth an hour of my time
☟︎ mircea_popescu: i don'
t mind the hardware -- i just wish to know what software anyone knows of.
mircea_popescu: but i can'
t fucking run old gentoo on it. for one thing, what games even run on old gentoo ?
mircea_popescu: and yeah, sure, he wasn'
t using that back in february. but just because he wasn'
t doesn'
t fucking mean nobody was, amirite. cheapo "safe email" + cheapo "anonimity tools" == internet failure.
mircea_popescu: 0% chances for this to pass if i don'
t actually fish it out of the spam list by hand. and for obvious fucking reasons : people who use protonmail are retarded.
mircea_popescu: nobody speaks on the boat ; and if someone does, it's because someone else made a mistake. but real men don' tmake mistakes, and boys aren'
t welcome on the boat.
mircea_popescu: i didn'
t delete them off the site, just took 'em out of rotation is all.
mircea_popescu: ">100 chicks on campus want to suck dick on their knees, can'
t because 30 nobody would even spit on cockblock all they see"
a111: Logged on 2019-05-31 01:38 BingoBoingo: 77 want to work, can'
t because 38 want not to strike but occupy the workplace and fuck it all to hell
BingoBoingo: 77 want to work, can'
t because 38 want not to strike but occupy the workplace and fuck it all to hell
☟︎ phf: asciilifeform: right, snabb doesn'
t have some of our restrictions, i.e. they accept all kinds of modern gnarl in exchange for the ability to send raw packets. i'm not sure their approach even works on old cards
mp_en_viaje: indeed. i had sluts live illegally for years, didn'
t even get fined.
mp_en_viaje: "you're still working for the government, you just don'
t get a pension"
BingoBoingo: Still, the Herbal and the viagra are there. The seekrit email doesn'
t have seekrit, and the email part is doubtful
BingoBoingo: mp_en_viaje: AHA, the catch is IEA doesn'
t count Russia, China, or India as "advanced economies"
BingoBoingo: In wankers "nuclear capacity operating in advanced economies would decline by two-thirds by 2040, from about 280GW in 2018 down to just over 90GW in 2040" << If the capacity is declining, they aren'
t "advanced economies" unless "advanced" means Africanizing
a111: Logged on 2017-03-14 14:31 asciilifeform: Framedragger: the problem with tcp isn'
t simply that enemy can insert an RST packet and make you blame your peer. (and whitelists do 0 against this.) but that it is very expensive , computationally, long before you have any idea who you're talking to.
mp_en_viaje: so, in short : to find lulz in bitcoin one needn'
t indeed look far.
mp_en_viaje: now, this "wouldn'
t work" because reasons to do with handwave.
BingoBoingo: Don'
t forget the more important part. It takes time because verification IS NOT sad
mp_en_viaje: "cogentco doesn'
t give me ip" "ever wondered why ?" "you mean there's a government conspiraci ?" "no. i mean there doesn'
t need to be one."
a111: Logged on 2016-07-04 21:47 mircea_popescu: but better keep movin' an' don'
t stand still - if the skeeters don'
t get you the gators will."
mp_en_viaje:
http://btcbase.org/log/2019-05-28#1915806 << yes, if you use bitcoin addresses you're protected from scammers trying to get people to use non-bitcoin addresses ; no, the scam unwinds on its own time not on yours (or anyone else's) time. you similarly can'
t tell MMM to "stop pyramid scheming" in 1995.
☝︎ a111: 2016-02-14 <copypaste> it's an IDE for a new proprietary language. it's crud, sure, but code generation isn'
t bad by itself
mp_en_viaje: oh, you're saying server shouldn'
t advertise what it has ?
diana_coman: it still seems over the top; it's enough if client has a known list of preferences and asks for them in that order, after all; if it doesn'
t get that, it goes for next and so on
mp_en_viaje: it's only the user whocan decide "i don'
t want any sounds" or "no videos" or "no meshes only icons" or anything like this.
mp_en_viaje: "anything it hears mentioned it doesn'
t know and cares about".
diana_coman: but if it is to ask of anything it doesn'
t yet have/know, then it should ask for all of them, it can'
t not care about some of them
mp_en_viaje: ok, so those it cares about it asks about and those it doesn'
t care about it doesn'
t ask about.
diana_coman: it cares about the object; this doesn'
t mean it cares about ALL its properties
diana_coman: it asks for the object; the object descriptor includes the properties; on the principle that "what client doesn'
t yet know, client will investigate further", it should ask for them further,right?
mp_en_viaje: so if your client doesn'
t care about them, it doesn'
t ask for them, what's the problem ?
diana_coman: I said "server did inform" not didn'
t, lol
mp_en_viaje: i mean, if client doesn'
t know wtf it is, how is client to use it ? obviously it informs.
mp_en_viaje: that's what "doesn'
t care" means, definitionally.
diana_coman: if client doesn'
t care about mesh , but it asks for it because it saw it, isn'
t that in advance?
diana_coman: (and this thing that "doesn'
t keep everything" is why I went with the different approach aka ask when needed, not when heard of it)
diana_coman: the difference being that client (as previously discussed) anyway does not keep everything so asking when it doesn'
t need it is not solving that problem
diana_coman: how is it imperative?? server says this guy wears the helmet of doom; client says meh, can'
t be arsed to show helmets; how is it imperative?
diana_coman: or you propose that this shouldn'
t even be
mp_en_viaje: if it gets it, it uses it. if it doesn'
t get it, it uses the default.
mp_en_viaje: client asks what is X, gets a response including data it doesn'
t have ; asks for the data.
diana_coman: I don'
t think I get it and I'm not sure whether it's because some things are still not right (for starters there is no fixed duration as it's dynamic basically)
diana_coman: then I don'
t get it; because if it is the client's decision to ask immediate refresh then sure, what's the problem? it's their decision and it still is the minimum traffic resulting
a111: Logged on 2019-05-28 12:07 diana_coman: my proposal was to have the Requester ask "what are a,b,c" and move those three objects into a "pending" queue; when another request for them arrives, that's fine; when requester wakes up, it checks and prunes any that meanwhile are there so it doesn'
t ask again for stuff it meanwhile got
diana_coman: after they resolved is however "refresh", isn'
t it?
a111: Logged on 2019-05-28 12:07 diana_coman: my proposal was to have the Requester ask "what are a,b,c" and move those three objects into a "pending" queue; when another request for them arrives, that's fine; when requester wakes up, it checks and prunes any that meanwhile are there so it doesn'
t ask again for stuff it meanwhile got
diana_coman: nocredit: register a key with deedbot as otherwise there can'
t possibly be a "next time/later", it's always first time...
diana_coman: it seems to me you can'
t afford to not use pizarro for bitcoin really
nocredit: my problem is that i don'
t have a static ip at my premises, so at home it's a pain with the myip parameter. I was trying with a pico vps to bypass this by set up a private vpn, but as now i'm stuck
diana_coman: asciilifeform: doesn'
t pizarro offer anything though?
diana_coman: you can feed it manually blocks if you have them & are in a hurry but otherwise I don'
t yet fully grasp your problem as such: is it stalled or is it just that you don'
t expect it to take longer than 1 week or what?
diana_coman:
http://btcbase.org/log/2019-05-28#1915708 - even on re-re-read I can'
t follow this: where does it seem as if I'm saying in the least that server should solve this at all for client? (no, it can'
t, of course); my approach is to solve this in a single point in client aka Requester rather than have it spread throughout client at every point where some part finds out it wants some data.
☝︎ diana_coman: my proposal was to have the Requester ask "what are a,b,c" and move those three objects into a "pending" queue; when another request for them arrives, that's fine; when requester wakes up, it checks and prunes any that meanwhile are there so it doesn'
t ask again for stuff it meanwhile got
☟︎☟︎ diana_coman: the Requester is the one who knows where data comes from, what does one need to do to obtain it, what sort of constraints there are (e.g. don'
t spam server with 1001 requests per second) and even what has to be obtained in order to be able to make a request at all (e.g. a set of Serpent keys!)
diana_coman: and I say "fresh" because it's not even necessarily a case that it doesn'
t have it but maybe (e.g. for position) it considers it obsolete hence deletes it and wants it new
diana_coman: hence my "doesn'
t fit" - in this specific data-that-matters sense, not re eye candy
a111: Logged on 2019-05-27 22:58 diana_coman: basically I don'
t actually think that "needed 100 times" SHOULD translate into "send 100 requests to the server" ; something is either needed or not; it might be more needed than something else, sure but that's a relative (and changing) ordering of requests at most, not a traffic-generator essentially.
a111: Logged on 2019-05-27 22:41 diana_coman: anyway, if it shouldn'
t even retry the correct way to put it is that it doesn'
t *care* at all about the result; i.e. it sends the request, it goes to sleep for timeout interval and then when it wakes up it simply makes and sends the next request, without any care in the world re anything
mp_en_viaje: "grandfather was rich, what means 'don'
t squander.
mp_en_viaje:
http://btcbase.org/log/2019-05-27#1915697 << trist da' tru. the fucking problem with solving problems is that as the problem solvers get old the next generation takes over, and they only ever dealt with the solution ; didn'
t ever deal with the problem. consequently they limply expect the solution, in the sad terms of "oh, do we still have to", without any appreciation for the difficulty of the problem, resulting in fucking amer
☝︎ mp_en_viaje: in the vhs-unix-that-never-existed ideal in my own mind, i should be able to, upon encountering for the first time a dude i don'
t like, alt-tab out of the game, edit the cached file representing this dude's armor, write "dickhead" in spray paint all over the breastplate, and without any further interaction on my part see the dickhead appropriately labeled all over the game forevermore.
mp_en_viaje:
http://btcbase.org/log/2019-05-27#1915694 << philosophically, the situation where player is happy offline, and unaware of it does not require fixing. take asciilifeform for instance, he's been happily playing eulora offline for years, and hasn'
t yet noticed!
☝︎ diana_coman: basically I don'
t actually think that "needed 100 times" SHOULD translate into "send 100 requests to the server" ; something is either needed or not; it might be more needed than something else, sure but that's a relative (and changing) ordering of requests at most, not a traffic-generator essentially.
☟︎ diana_coman: anyway, if it shouldn'
t even retry the correct way to put it is that it doesn'
t *care* at all about the result; i.e. it sends the request, it goes to sleep for timeout interval and then when it wakes up it simply makes and sends the next request, without any care in the world re anything
☟︎ diana_coman: at which point recovery is a bitch way worse than restart; I suppose the point might be "don'
t die, just make it clear there's nobody answering "
mp_en_viaje: but if it's not happy with theresult, not only does it not die -- it doesn'
t even retry.
mp_en_viaje: it doesn'
t die nor does it retry. just plods along.
mp_en_viaje: client notices it doesn'
t know wtf these are ; so at t2 says "what's an a ?"
mp_en_viaje: whole discussion is predicated on comms failure, client asks but doesn'
t for some reason get.
mp_en_viaje: mentioned means the client sees an object it doesn'
t have in a server communication.