Show Idle (>14 d.) Chans
← 2019-05-27 | 2019-05-29 → ↓
04:47 mp_en_viaje holy hell, deedbot ran off again!
04:47 mp_en_viaje diana_coman, sorry about last night lol. had to order another truckful of internet.
04:48 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!
04:48 a111 Logged on 2019-05-27 22:32 diana_coman: you mean if it timeouts on a request then it lets it just lets it be? it makes it even simpler from my pov, not as if it's an issue but essentially I'm not sure how do you then avoid the case where you play happily offline and ...not notice it?
04:49 mp_en_viaje practically, yes it;s undesirable, but the overwhelming consideration is that this undesirableness can not be managed for the client by the server, because the server suffers from a serious knowledge problem wrt it.
↖
04:50 mp_en_viaje therefore will necessarily have to be resolved by the client. in many important fields (such as where the client thinks its located), the server has the important mechanism of denial, to support fast correction. but when it comes to, eg, what icon should represent x item, or how its 3d texture shoudl look etc, there's no shits given. client can display the world any way it does, and the server will not care.
04:51 mp_en_viaje in another statement : there's two classes of data : erste klasse, which is data which the client may reference (such as, move me two to the left), and buluk klasse, which is data the client may never reference (such as, make my armor one iota shinier).
04:53 mp_en_viaje (the fundament of the male world, this division, btw. not permitting any-thing-whatsoever being discussed is what repressing the female mind, worldview and experiential approach is all about)
04:57 mp_en_viaje http://btcbase.org/log/2019-05-27#1915695 << what would this "nothing fits" look like ? for instance, if a client makes himself a modfile, to have all the characters move lasciviously and otherwise sit about nude, or if joe the manga fan makes his shield sport a tentacle pattern, the server should periodically re-enact the one-true-look with medieval officialness ? why ?
04:57 a111 Logged on 2019-05-27 22:33 diana_coman: not notice it until all of a sudden nothing fits
04:59 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.
04:59 mp_en_viaje whether i can be arsed or not to do this is one thing ; but if i am arsed i should encounter no further difficulty.
05:00 mp_en_viaje (the programmatic logic being that as i focus on the game again, the screen will have to be redrawn, which will suck from the cache ; obviously this may not work ~exactly~ like this for a number of reasons -- which is why it's called an ideal. it should work like this.)
05:02 mp_en_viaje (obviously "forevermore" means -- for as long as he's wearing that type of armor, and include all other dudes wearing the same type, yes, i'm not looking for dwim here.)
05:04 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
05:04 a111 Logged on 2019-05-27 22:35 diana_coman: lol, internet a la cluj
05:04 mp_en_viaje ver again.
05:04 mp_en_viaje "grandfather was rich, what means 'don't squander.
05:04 mp_en_viaje http://btcbase.org/log/2019-05-27#1915698 << i would say so.
05:04 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
05:06 mp_en_viaje and more generally i believe a lot of software systems would greatly improved through liberal application of just this kind of carelessness. the idiots are careless at the wrong ends -- by all means, DO http://btcbase.org/log/2019-05-13#1912968 ; do NOT "hi this is the glass from last night, how would you rate your drinking experience please fill out this form".
05:06 a111 Logged on 2019-05-13 17:09 asciilifeform: meanwhile , in ru heathendom , (translation mine) : 'there is a sign that distinguishes a troo programmer from an impostor. a true programmer , before going to bed, will put on his nightstand two glasses. one with water -- in case in the night he becomes thirsty. and one empty -- in case not.'
05:07 mp_en_viaje http://btcbase.org/log/2019-05-27#1915699 << model for me how this waste of traffic would look ? seems exactly the opposite to me, specifically : 1. case careless -- request is sent ; were resppnse receinved, all the better ; otherwise, whatever. total sent : 1 request ; maybe 1 answer. say symbolically 1.5 "packets"
05:07 a111 Logged on 2019-05-27 22:51 diana_coman: while this has the advantage of being very simple indeed, all it does in fact is that it pushes the complexity a bit higher up at the added cost of a lot of waste traffic
05:09 mp_en_viaje 2. case careful -- request is sent (p=1), if received correctly (p=2) then all is well, else new request sent (p=2.5) and if now received correctly all is well but if not yet new request sent (p=3.5) and if not well again you're looking at... well, depends how noisy/lossy the channel is, but it seems to me the careless case saves a good chunk of bw, roughly speaking the square of the noise rate.
05:12 mp_en_viaje http://btcbase.org/log/2019-05-27#1915700 << if your argument is actually "the client should asynchronously ask for all data it uses defaults for AT SOME OTHER TIME than in the middle of heavy gameplay, such that all the complex gfx of everyone's armors, mounts and flying dildoes are downloaded piecemeal and while sitting around, rather than en masse whenever teleporting to a large market town" you have a solid point. but it's
↖
05:12 a111 Logged on 2019-05-27 22:54 diana_coman: if that armor of the stars is requested once then it's wanted *anyway* so what's the point in not tracking it where the request is assembled and instead having it tracked through repeated requests; after all this "oh, still not have it" is anyway still a look "is it in the cache now?" just that it's pushed higher up
05:12 mp_en_viaje a case for "retry X magic number of times at Y magic intervals which i the designer knew ahead of time, for everyone and for all time".
05:13 mp_en_viaje the elegant solution for this would be for the client to keep a list, "items the server mentioned, we asked for but never received usable answer therefore using a default", and either go through it whenever convenient (eg, when player goes afk) or else even expose a button for player to do himself).
↖
05:14 mp_en_viaje http://btcbase.org/log/2019-05-27#1915701 << no, let the server stop being fucking stupid and reference things it can't provide.
05:14 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.
05:15 mp_en_viaje win-win!
~ 2 hours 30 minutes ~
07:45 * diana_coman is reading
07:47 diana_coman mp_en_viaje: I suspect it's again one of those things where there is no disagreement at the core but we are not yet fully in sync re various bits and pieces;
↖
07:48 diana_coman one thing that I see there is that you seem to consider that this "request" is ONLY for art stuff; the way I see it, it's not just for that but a generic mechanism for any sort of thing requested, be it art or contents or position or whatever
07:49 diana_coman hence my "doesn't fit" - in this specific data-that-matters sense, not re eye candy
07:50 diana_coman let me expand a bit on the concrete solution I'm talking about:
07:51 diana_coman client asks for data from EuCache; EuCache replies with either true (data found + whatever values that data has) or false (not found + default values)
↖
07:51 diana_coman this can/is to be done by any bit and part of the client that is looking for some data of any sort, be it art, position, whatever
07:52 diana_coman so up to here I think it's clear that yes, client can therefore play happily forever after totally offline
07:54 diana_coman cache will have some default value for anything (because defaults are by type/role so not a problem to have them upfront) and it provides those or better, simply marking them as what they are but never saying "huh, no such thing"
07:55 diana_coman on top of the above, the client further has this choice: it can decide it wants to ask for some fresh stuff basically, be it file or anything else
07:56 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
07:57 diana_coman anytime it wants something fresh, it will place a request with the local Requester (hence, NOT directly with the server, for all it cares the data comes from Fuckgoats really)
07:58 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!)
07:59 diana_coman so the Requester accepts all and any requests and keeps them neatly in a queue
08:00 diana_coman whenever it decides it CAN actually send a message to the server to ask for something, it packs together as many of those pending requested stuff as it can in one message (protocol allows a request for several files/obj in same message) and it sends it on its way
08:01 diana_coman now there is the apparently disputed bit: in the simplest implementation, requester can now consider that it's job is done and therefore go to sleep until next time when it might send a message
08:02 diana_coman the idea here being that well, if the caller still wants that stuff and it's not there, they will just request it again anyway so it gets again into the queue and at some point it will make it into a message
08:06 diana_coman and now re waste traffic: at t1 there are requests for obj a, b, c; at t2 Requester wakes up and asks the server "what are a, b, c", drops those as "done" and goes back to sleep; at t3 there is another request for a,b,c so Requester puts them back in its queue; at t4 a,b,c arrive; at t5 Requester wakes up and ...asks the server again "what are a,b,c?" because well, they are there in the queue, right?
↖
08: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
↖ ↖
08:08 diana_coman for that matter I suppose it can even just have one queue, they are all "pending" and simply prune it every time it wakes up;
08:11 diana_coman might add also, since it's perhaps not obvious: there is no exact "repeat request" as such because anyway, how could that be (counter of messages at the very least is different!) but more importantly, every time Requester asks the server for something, it simply asks about as many pending things as it can, there is no "oh, I asked about those and not yet here so let's ask exactly those again"
08:13 diana_coman and given the two-class system those are effectively priorities: at every ask-opportunity, the Requester will choose first object request and only second file request (those really are the ONLY two types of questions the client may ask the server)
08:18 diana_coman http://btcbase.org/log/2019-05-28#1915729 - fully asynch is the core of it but I don't see the case of x magic number of times; logically speaking x is simply ask until you are answered, there is no set or fixed x times
08:18 a111 Logged on 2019-05-28 09:12 mp_en_viaje: http://btcbase.org/log/2019-05-27#1915700 << if your argument is actually "the client should asynchronously ask for all data it uses defaults for AT SOME OTHER TIME than in the middle of heavy gameplay, such that all the complex gfx of everyone's armors, mounts and flying dildoes are downloaded piecemeal and while sitting around, rather than en masse whenever teleporting to a large market town" you have a solid point. but it's
08:20 diana_coman it's true that atm at least it's more independent from game play rather than "when not busy"
08:22 diana_coman or strictly speaking when "not busy as measured by number of erste klasse requests still pending"
08:23 diana_coman and re Y magic intervals, that is not really there either, that's the whole point of data-received notifications, to NOT rely on magic Y interval
08:25 diana_coman the timeout is the only magic value, yes, but that is literally last resort, aka guaranteed after that time, it WILL send another request; it WILL however send one sooner if the previous one is answered, why would it wait longer than it has to
~ 58 minutes ~
09:23 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.
09:23 a111 Logged on 2019-05-28 08:49 mp_en_viaje: practically, yes it;s undesirable, but the overwhelming consideration is that this undesirableness can not be managed for the client by the server, because the server suffers from a serious knowledge problem wrt it.
~ 2 hours 41 minutes ~
12:05 diana_coman !!up nocredit
12:05 deedbot nocredit voiced for 30 minutes.
12:06 diana_coman nocredit says he needs support with trb so let's here
12:06 diana_coman what did you do and where are you stuck nocredit ?
12:06 nocredit hi, thanks for the voice. Basically trb (with aggressive patch) simply is too slow to sync, and i'm using a VULTR vps with 6 cores and 16GB of ram. For too slow i mean that after 1 week is just at block height 300k
12:08 nocredit for instance, with bitcoin core in half a day I have a synced node
12:08 diana_coman nocredit: it's unlikely that it's too slow since plenty of people are running same and sync no problem ; it is true that it's not on vps usually but at any rate, it may be all sorts of other stuff: is it blackholed?
12:09 diana_coman it does take time to sync fully if you start from 0, yes;
12:10 nocredit 80% of the debug.log is about discarded blocks
12:10 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?
12:10 trinque having serious problems with the DC I'm using for deedbot, sorry folks. I'm going to try to get the migration to pizarro completed this weekend.
12:11 trinque they had an outage earlier today in singapore, and for some reason this resulted in the bot being permastuck
12:11 nocredit first of all i'd like to ask what is a sane time for sync from zero to 100%
↖
12:12 asciilifeform nocredit: approx 3 weeks, if you're syncing from trb nodes via -addnode .
12:12 asciilifeform this is indep. of cpu/ram, so long as box meets minimum spec (2GB)
12:14 nocredit second, my vps provider (vultr) is complaining with me that i put too much wear and tear to their ssd
12:14 asciilifeform nocredit: the reason your log consists 80+% of 'discarded block' is that trb deliberately does NOT hold on to a received block unless it matches the litmus for possibly being the immediately next block in the chain. this is deliberate, and i personally wrote this patch.
12:14 nocredit is there a recommended vps provider to use?
12:14 asciilifeform nocredit: bitcoin on vps is a nonstarter
12:14 asciilifeform esp. if your hoster is 'oh noes, someone is actually ~using~ what he paid for!' type.
12:15 diana_coman asciilifeform: doesn't pizarro offer anything though?
12:15 diana_coman BingoBoingo: ^ ?
12:15 asciilifeform diana_coman: for trb ?! it already has 3 iirc trb nodes
12:15 diana_coman for paying customers who may want to run trb, what?
12:15 asciilifeform diana_coman: colo people can run trb, or for that matter anythign else
12:15 diana_coman or nao you are not interested in such customers or what?
12:15 diana_coman so there, let the man know about it, no?
12:16 asciilifeform entirely interested. colo available any time, this is on the price sheet.
12:17 diana_coman nocredit: to answer your question: the recommended provider to use is Pizarro; it offers colocation that would fit your needs quite well ; you can join them in #pizarro and ask and you can have a look at http://pizarroisp.net/pizarro-hosting-rate-sheet/
12:17 asciilifeform incidentally, there's a vacant rk, and if customer chooses to use the available sata snake and a 1tb ssd, he can trb. BingoBoingo plox to add this to the advertised list.
12:18 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
12:18 asciilifeform nocredit: vps is woefully inadequate for the job. you need a physical machine.
12:18 nocredit the small vps would only handle the network traffic
12:19 nocredit as it's doing VPN host tasks
12:19 asciilifeform nocredit: if you absolutely cannot afford physical colo, you can use vps as a means of getting static ip. set up ssh tunnel to your home node from the vps.
12:19 diana_coman nocredit: re provider I warmly recommend talking to Pizarro and in particular to BingoBoingo in #pizarro.
12:19 asciilifeform nocredit: http://pizarroisp.net .
12:21 nocredit thanks, yes physical colo is too much, i hope that ssh tunnel is stable enough for 3 weeks of sync
12:21 * asciilifeform brb:teatime
12:21 BingoBoingo The vacant rk can indeed be rigged with the SATA snake to add a 1tb drive.
12:22 nocredit another question: if i run core without using segwit features (so sticking with the 1 starting addresses) am i actually protected from an eventual attack on segwit? I know that here is not core support, but there is a way to tell core to dump the segwit part?
↖
12:23 BingoBoingo It takes time, but I can also but a blockchain on a drive.
12:23 BingoBoingo nocredit: Segwit and all the other core weird happens on 3 addresses
12:24 BingoBoingo 1 addresses are pay to public key hash. 3 addresses are pay to weird addresses.
12:24 diana_coman nocredit: since you have nothing to do with segwit, you are immune to attacks on segwit, not as much protected as entirely immune by definition, no?
12:25 BingoBoingo The bigger concern with core is the bloat. Shit like the "payment protocol"
12:25 nocredit correct, I appreciate TRB as it removes the bloat. But 3 weeks to sync is really a pain
12:25 BingoBoingo The Gavin or some other shitgnome early on tried to push a "mandatory" segwitting, but that proposal died quickly and they all now pretend that never happened.
12:26 BingoBoingo nocredit: Once synced it is very tenacious with staying synced. Most of the core sync speedup is they stopped verifying many blocks
12:27 diana_coman nocredit: for that matter if running own trb is too big a pain/expense, I suppose you might be better served by getting in the wot and using deedbot's wallet for that matter.
12:28 nocredit and last: if i tar gz everything synced as far as now on the VPS and dump it at my premise, i'll be able to restart at block height 300k in the future?
12:28 BingoBoingo The TRB 3-6 week sync (CPU and disk bound) is a strictly linear, no exceptions to verification affair
12:28 BingoBoingo <nocredit> and last: if i tar gz everything synced as far as now on the VPS and dump it at my premise, i'll be able to restart at block height 300k in the future? << As long as you cleanly shut down the daemon before dumping
12:28 nocredit because vultr vps has sent me a takedown notice
12:28 nocredit with some spare time to dump the hdd
12:28 diana_coman lolz @ service
12:29 nocredit totally a shit service btw
12:29 diana_coman nocredit: you know that saying that one's too poor to use cheap stuff?
12:29 BingoBoingo But you have to shut the daemon down cleanly for blockindex.dat to be portable
12:29 nocredit but yes, i've learn the lesson. Only bare metal at my home
12:29 diana_coman it seems to me you can't afford to not use pizarro for bitcoin really
12:30 diana_coman or that, yes.
12:31 nocredit ok perfect. Will update here when I complete the sync
12:31 diana_coman !!key nocredit
12:31 deedbot Not registered.
12:32 BingoBoingo nocredit: Maybe register a GPG key. Otherwise hard to tell whoever returns is you
12:32 diana_coman nocredit: register a key with deedbot as otherwise there can't possibly be a "next time/later", it's always first time...
12:32 nocredit ok
12:42 BingoBoingo !!up nocredit
12:42 deedbot nocredit voiced for 30 minutes.
12:42 BingoBoingo nocredit: How about you make your way to #pizarro
12:46 BingoBoingo nocredit: Other than running a Bitcoin node, what else do you spend your time on?
~ 24 minutes ~
13:10 feedbot http://thetarpit.org/posts/y05/092-cl-who.html << The Tar Pit -- CL-WHO genesis
~ 49 minutes ~
13:59 feedbot http://qntra.net/2019/05/china-squeezes-us-as-tensions-rise-windows-out-in-the-pla-rare-earth-exports-on-the-chopping-block/ << Qntra -- China Squeezes US As Tensions Rise: Windows Out In The PLA, Rare Earth Exports On The Chopping Block
~ 1 hours 34 minutes ~
15:34 mp_en_viaje http://btcbase.org/log/2019-05-28#1915737 << aha
15:34 a111 Logged on 2019-05-28 11:47 diana_coman: mp_en_viaje: I suspect it's again one of those things where there is no disagreement at the core but we are not yet fully in sync re various bits and pieces;
15:35 mp_en_viaje http://btcbase.org/log/2019-05-28#1915741 << imo should not deliver default values every time it delivers a false, lotta traffic wastage. default should be a special object in each class.
15:35 a111 Logged on 2019-05-28 11:51 diana_coman: client asks for data from EuCache; EuCache replies with either true (data found + whatever values that data has) or false (not found + default values)
15:35 diana_coman mp_en_viaje: what traffic?
15:35 diana_coman between c and ada ?
15:36 mp_en_viaje it's remarkable, reading through all this, how much like a web browser this client actually is. TTL next ?
15:36 diana_coman for the same money the c code can have the defaults and that is it
15:36 diana_coman not like the cache is on server
15:36 diana_coman ahahhaha
15:36 * diana_coman has just re-read the cs manual so feels rather ..funny
15:37 mp_en_viaje (fucking obviously they got the ttl wrong, who the fuck heard of ttl as a SERVER-side setting. how is the server to know how often my pictures of jodie foster's injured snatch need refreshing ?!)
15:38 mp_en_viaje http://btcbase.org/log/2019-05-28#1915754 << your proposal does not fix your own proposed problem. suppose things work as you describe, and the requester gets the reques again... it puts it in the queue again yes ?
15:38 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
15:39 diana_coman uhm, while it still has them pending or what?
15:39 mp_en_viaje diana_coman, if the server asked what's b answers no such thing, use default.jpg every time, you're sending default.jpg every time.
15:39 mp_en_viaje diana_coman, no, after they resolved.
15:39 diana_coman after they resolved is however "refresh", isn't it?
15:40 mp_en_viaje not objectively fresher than they are when there's no queue and t4 comes around.
15:41 diana_coman uhm, wait
15:41 mp_en_viaje aite.
15:42 diana_coman so you say there is no difference between caller asking for it 10 times and this resulting guaranteed in 10 messages to the server because requester does not keep track of anything on one hand and on the other hand 10 requests resulting in only 1 message to server because requester does keep track?
15:42 diana_coman freshness is not objective, no; it's subjective and decided by user of cache
15:43 diana_coman the point is not about "how fresh the final data is" but rather simply that: how many messages get generated for x requests
15:44 mp_en_viaje i am not saying "there is no difference". i am saying "you are proposing to produce a mechanism to resolve a problem you imagine exists, such that the solution's parameters are populated by guesswork and the imagined problem is not eliminated"
15:44 diana_coman the default.jpg is not sent by server, no; local cache has defaults because it has to - it needs to use something before there is even any answer from server; hence the defaults part is not about traffic at all
15:44 diana_coman what parameters?
15:44 mp_en_viaje i do not agree with this.
15:44 mp_en_viaje but let's resolve one issue at a time, because this is not working.
15:45 diana_coman ok
15:45 mp_en_viaje so, as to the matter of client cache. situation 1, no-cache : client wants some item, asks for it, potentially asks again before server has had chance to answer.
15:46 mp_en_viaje situation 2, cache (called "requester") : client will abstain from asking for some item for a certain time after having asked.
15:46 diana_coman uhm, "no cache" is ...impossible; by definition the data on client IS CACHE
15:46 diana_coman only if it throws it away without even using it, can there be "no cache"
15:46 mp_en_viaje o brother.
15:46 diana_coman well yes, because requester is not cache, ugh.
15:47 mp_en_viaje i guess we go back to the text, hang on.
15:47 diana_coman k.
15:48 mp_en_viaje http://btcbase.org/log/2019-05-28#1915753 & http://btcbase.org/log/2019-05-28#1915754
15:48 a111 Logged on 2019-05-28 12:06 diana_coman: and now re waste traffic: at t1 there are requests for obj a, b, c; at t2 Requester wakes up and asks the server "what are a, b, c", drops those as "done" and goes back to sleep; at t3 there is another request for a,b,c so Requester puts them back in its queue; at t4 a,b,c arrive; at t5 Requester wakes up and ...asks the server again "what are a,b,c?" because well, they are there in the queue, right?
15:48 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
15:49 diana_coman move those three IDs* I should have said; not the objects themselves
15:49 mp_en_viaje your proposal does not resolve the t4-t5 problem. having a pending queue does not mean that the client may not decide to ask again JUST as the "requester" took them out of the pending queue.
15:49 diana_coman yes but requester does not put it back in queue
15:49 diana_coman it accepts the new request, looks that it's pending so ..nothing to do with it
15:50 diana_coman i.e. client comes in the shop and asks 100 times for the same thing while shopkeeper is working on delivering it so what
15:50 diana_coman it's still the same thing
15:51 diana_coman otherwise yes, no point in having the queues in the first place really; a duplicate request can have at most the effect of increasing counter of "requests for this here object a" if one wants then to treat them as priorities basically aka ask first for those items that have been demanded most times
15:54 diana_coman or you mean a potential "race condition" there?
15:56 mp_en_viaje lol this shiternet... im getting like 7 lines in a bundle.
15:56 mp_en_viaje diana_coman, nevermind the "it's pending
15:56 mp_en_viaje AFTER it took it out of the queue. immediately after.
15:56 mp_en_viaje nope.
15:56 diana_coman the point is not to forbid to the client repeated request
15:57 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
15:58 mp_en_viaje dude this piece of shit... it's showing your lines but not sending mine.
15:58 mp_en_viaje i have NEVER seen this shitty internet in my fuckign life jesus
15:58 mp_en_viaje http://p.bvulpes.com/pastes/G85i2/?raw=true << this is how this convo looks on my side
15:59 diana_coman ugh; at least Internet used to be working well in Ro.
16:05 mp_en_viaje not anymore. anyway, looky : take the object icon.jpg. the client may ask for this item icon.jpg at time intervals Ti which, as far as we know, are random. now, if you have a queue, of fixed duration L, you offer the guarantee that "for any Tjs that are closer than L only the first does go through". this, you say, "reduces overal requests".
16:05 mp_en_viaje it ~might~. you can not prove they do, for all you know all Ti come at L+e. how do you know it helps anything ?
16:08 mp_en_viaje diana_coman, makes sense ?
16:09 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)
16:09 mp_en_viaje what is this "dynamic" mean ?
16:09 diana_coman or because I don't get it
16:10 diana_coman it depends on what arrives and when + on the contents of the queue itself really since for instance a huge filename will fill a whole msg
16:10 mp_en_viaje this is such a bizarre issue to have.
16:11 diana_coman let's take it from the other end, maybe it's easier
16:11 mp_en_viaje looky : if there's no queue, you can in principle get a new request just as the old request was satisfied.
16:11 diana_coman what is the gain in forcing every request -> a message to server?
16:11 mp_en_viaje if there IS a queue, you can STILL get a new request just as the queued request is satisfied.
16:11 mp_en_viaje this not self-evident ?
16:12 diana_coman no, because it forces the very same problem higher up where there is even less information to decide on when to request
16:13 mp_en_viaje decision seems simple enough : how about now.
16:14 diana_coman it does seem a weird problem to have in the simple sense that honestly it's just easier to do it as you say: no responsibility for traffic, just shoot whatever and as many times as higher level asks for... data, not for traffic, but whatevers.
16:16 mp_en_viaje it's easier, and it's not clear that the complicateder way is in any sense better.
16:16 diana_coman let me get this part straight though: how is this "now" decided? every frame whoever has something unknown asks for it? some parameter every x ms ask for everything unknown?
16:16 diana_coman or what?
16:17 diana_coman honestly, as a player, I'll then have to hack my own client, lolz
16:17 mp_en_viaje client asks what is X, gets a response including data it doesn't have ; asks for the data.
16:17 mp_en_viaje if it gets it, it uses it. if it doesn't get it, it uses the default.
16:17 diana_coman and here we go again
16:17 mp_en_viaje optionally, as per http://btcbase.org/log/2019-05-28#1915732 ; but this doesn't have to be first pass.
16:17 a111 Logged on 2019-05-28 09:13 mp_en_viaje: the elegant solution for this would be for the client to keep a list, "items the server mentioned, we asked for but never received usable answer therefore using a default", and either go through it whenever convenient (eg, when player goes afk) or else even expose a button for player to do himself).
16:19 diana_coman is at all clear that there is this separation between the client-part that uses/needs some data on one hand, the one I kept calling "client" or c/cpp and on the other hand the lower layer that is protocol aware and actually "asks what is x"?
16:19 diana_coman or you propose that this shouldn't even be
16:19 diana_coman ?
16:20 mp_en_viaje it's clear, one's in c the other in ada, yes.
16:21 diana_coman oook; so then, do you mean that "asks for data" is to be driven by.... what it receives from server rather than attempted use?
16:21 mp_en_viaje yes.
16:21 diana_coman finally at least the whole trouble makes sense
16:22 mp_en_viaje oh ?!
16:22 diana_coman this bit here is the part where we were not in sync
16:23 diana_coman why exactly though would client ask based on what server says rather than based on what it finds itself actually needing to use?
16:23 mp_en_viaje because usage is imperative, and it will use default in any case.
16:24 mp_en_viaje similarily you look up new words when you hear them rather than when you decide to use them.
16:24 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?
16:24 mp_en_viaje "now we're printing this guy's helmet. wait, wtf do we put in the press ?!"
16:25 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
16:26 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)
16:27 mp_en_viaje the client does not keep everything in the sense that it's not required to keep everything, not in the sense that it can be relied on to not keep everything.
16:27 mp_en_viaje function of how much space the user is willing to give the cache, client could indeed keep everything.
16:27 diana_coman "wtf do we put in the press ?! " -> the default.
16:28 diana_coman well yes, but that's the thing, the problem is not solved by asking in advance
16:28 mp_en_viaje hence, imperative. once client decides to print something, IT WILL BE PRINTED. no ifs or buts or lookups.
16:28 mp_en_viaje what advance ?
16:29 diana_coman client asks what is a? server says it's (name this) (position that) (mesh theother) and so on
16:29 diana_coman if client doesn't care about mesh , but it asks for it because it saw it, isn't that in advance?
16:30 mp_en_viaje if it doesn't care, it doesn't ask.
16:30 mp_en_viaje that's what "doesn't care" means, definitionally.
16:30 mp_en_viaje not "does not print" but "does not ask"
16:30 diana_coman uhm
16:33 diana_coman from my pov I'm fine to switch perspective and go then with this approach, so basically there are no "client/cpp demands" anything since Ada-part directly handles it on the principle "if I saw it and it's not there, then I'll ask for it"; how is any limit re space or anything of the sort to be defined and handled in this case?
16:34 mp_en_viaje well, if client sets a limit, then oldest-used files get wiped.
16:34 diana_coman so it needs now to keep in addition a timestamp on data access?
16:35 mp_en_viaje doesn't fs keep this ?
16:35 mp_en_viaje i mean, it's in the stat innit ?
16:36 diana_coman fwiw I'll clearly have to hack my own client at the very least for making it text-only since there's no point in asking for all the graphical parts just because server did inform that those objects have this and that graphical part
16:36 mp_en_viaje how would the server not inform ?!
16:36 diana_coman hm?
16:36 mp_en_viaje i mean, if client doesn't know wtf it is, how is client to use it ? obviously it informs.
16:37 diana_coman I said "server did inform" not didn't, lol
16:37 mp_en_viaje um
16:37 mp_en_viaje so if your client doesn't care about them, it doesn't ask for them, what's the problem ?
16:38 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?
16:39 diana_coman it cares about the object; this doesn't mean it cares about ALL its properties
16:39 mp_en_viaje ok, so those it cares about it asks about and those it doesn't care about it doesn't ask about.
16:39 mp_en_viaje neh /
16:39 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
16:40 diana_coman uhm
16:40 mp_en_viaje "anything it hears mentioned it doesn't know and cares about".
16:40 diana_coman but that care is not "use" from earlier but..what?
16:40 mp_en_viaje client setting.
16:40 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.
16:41 diana_coman (re files and access time I need to look if I can get it, hopefully, via Ada.Directories)
16:41 mp_en_viaje and so i suppose all this can go in config file.
16:41 diana_coman oh joy
16:41 mp_en_viaje this part is not avoidable though, only user can tailor this sorta thing. "how much space to give cache and what sorta thigns to keep there" is emintently the function of config
16:44 diana_coman myeah, "useful" things.
16:44 diana_coman what else does one want in cache really.
16:45 mp_en_viaje if you recall the whole theory with "give alternatives for gfx", server could in principle offer a LIST of meshes. possibly different qualities, and even same quality.
16:45 mp_en_viaje so this goes right into that anyway.
16:45 diana_coman rolling back to the original thing, this is all there is to it: if c/cpp does not actually get to ask for anything then there is no trouble at all, sure.
16:46 mp_en_viaje right.
16:46 mp_en_viaje imo much sounder like that, for myriad reasons.
16:47 mp_en_viaje now what was the other one
16:47 diana_coman iirc it was specifically not a list of meshes but at most a list of overall graphical profiles as it were; i.e. each thing then at any time has only one option
16:49 mp_en_viaje nah! see, "what is armor of the pigs ?" "well, it could be joes_armorofpigs.mesh or moes_armorofpigs.mesh or dyna_armorofpigs.mesh" and client is set to get dyna* so continues "what is dyna_armorofpigs.mesh"
16:49 mp_en_viaje [rough sketch, not exact implementation detail]
16:49 diana_coman ugh, last time the rough sketch sounded as I said above though, lolz
16:49 mp_en_viaje :p
16:50 diana_coman open-ended lists like that are always a mess and doubly so via messages
16:50 mp_en_viaje oh, they're a mesh ?
16:51 diana_coman a mshhh
16:51 mp_en_viaje this design permits fallback ("i want to see dynas but if absent gimme joes" sorta setting)
16:51 mp_en_viaje ie, we can accept incomplete art sets.
16:51 mp_en_viaje aka "trust me, it's really smart (tm)"
16:52 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
16:52 mp_en_viaje exactly what i mean.
16:52 diana_coman lolz, given earlier thing, possibly not :P
16:52 mp_en_viaje oh, you're saying server shouldn't advertise what it has ?
16:53 diana_coman why would it do it like that for each and every thing?
16:54 * diana_coman now realises this should have been on #eulora
16:54 mp_en_viaje kinda, huh.
16:54 mp_en_viaje are we moving over ?
16:54 diana_coman let's
16:54 mp_en_viaje kk
~ 17 minutes ~
17:11 asciilifeform meanwhile in ye olde snakepit, http://p.bvulpes.com/pastes/GQU8m/?raw=true
17:12 asciilifeform !#seen copypaste
17:12 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
17:13 asciilifeform !!gettrust copypaste
17:13 deedbot L1: 0, L2: -6 by 2 connections.
17:13 asciilifeform lol
~ 19 minutes ~
17:32 mp_en_viaje guy's trying.
17:34 asciilifeform 'can translate Spanish and Tagalog. sorry if you think this is spam'
17:34 asciilifeform if i knew tagalog, i think i'd try an' keep it seekrit, lol
17:35 mp_en_viaje what's that, pinoy lang ?
17:35 mp_en_viaje i think he lived there.
17:35 asciilifeform aha!
17:41 mp_en_viaje http://btcbase.org/log/2019-05-28#1915778 << honestly, i don't even see this as a legitimate question.
17:41 a111 Logged on 2019-05-28 16:11 nocredit: first of all i'd like to ask what is a sane time for sync from zero to 100%
17:42 mp_en_viaje "how long will it take me to read all the books ? IT SEEMS UNREASONABLY LONG!!!"
17:42 asciilifeform at uni of clony circa 1400 prolly was answerable q , with 'reasonable' number as answr
17:42 mp_en_viaje by and large, a time penalty for being late equal to the square of the years passed seems the lowest possible bottom limit. so, if you start today and sync in less than a century, you're getting off too easy.
17:43 mp_en_viaje shoulda been here in 2009.
17:44 mp_en_viaje holy shit, vps too. dude, go away.
17:44 asciilifeform already went away
17:46 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.
17:46 a111 Logged on 2019-05-28 16:22 nocredit: another question: if i run core without using segwit features (so sticking with the 1 starting addresses) am i actually protected from an eventual attack on segwit? I know that here is not core support, but there is a way to tell core to dump the segwit part?
17:48 asciilifeform mp_en_viaje: iirc this is 1st recorded such case ( d00d took the sweat to build trb, note that there ain't a '4lusers' binariola package or anyffin of the kind) but then went and planted it on a lolhost
17:49 mp_en_viaje the list of fixations.
17:49 asciilifeform hm?
17:53 mp_en_viaje there's a list of ("independent") fixations. even if patient finds way out of one (thereby becoming ballas' "single issue independent"), the rest still remain.
17:54 mp_en_viaje so yes compiled, but ~of course~ uses vps (with any luck, "kubinetes '''deployment'''"), and also coca cola and also cisco router and also and also.
17:54 asciilifeform aa as in http://btcbase.org/log/2016-07-04#1497185
17:54 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."
17:55 mp_en_viaje aha
17:56 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."
17:57 asciilifeform still gotta add, that trb bringup takes weeks not because the set weighs 100TB ( as erryone already knows, it's below 300GB atm ) but cuz the sync mechanism is rather sad
17:58 BingoBoingo Don't forget the more important part. It takes time because verification IS NOT sad
17:58 mp_en_viaje this is true
17:58 asciilifeform BingoBoingo: most of the time aint spent in verify tho
17:59 asciilifeform it's spent waiting for someone to 'please drop a block in my gaping mouth'
17:59 mp_en_viaje moreover verification eminently paralelizable. his "6 cores" make no diff whatsoever.
17:59 asciilifeform this is true even with 'aggressor', the latter merely asks ~newly connected~ peers to give blox
17:59 mp_en_viaje but ~could~.
18:00 mp_en_viaje if 90% of time were spent in verification ; and if verification were ~correctly~ MT, then extant blockchain could be verified in roughly 10days / corecount.
18:00 asciilifeform mp_en_viaje: db could be not only parallelized but made O(1) , iirc we had lengthy worked example of just how
18:00 mp_en_viaje ie, one day per year ellapsed (and yes, this will stay linear)
18:00 asciilifeform and mp_en_viaje's napkin figure is correct (and pessimistic, could easily ~day on existing irons if rewritten properly )
18:01 mp_en_viaje only if that properly involves a whole lotta unrolling. which, im not even callin a bad idea
18:02 asciilifeform mp_en_viaje: no elaborate massage needed -- simply need 32GB or so hashtable . ( who wants, can dig up old thread with the exact algo, atm asciilifeform's hands somewhat full )
18:03 mp_en_viaje 32gb is a lotta unrolling in this context. and yes, not terribru idea, seeing how dataset is >100gb
18:03 asciilifeform handily fits in a reasonable ram. and 99.9999% of queries will land in it in O(1)
18:04 mp_en_viaje * not exact figures
18:04 asciilifeform ( the remainder, end up asking for a second lookup )
18:04 mp_en_viaje im sure his vultr comes with 192gb ram and a takedown notice if you allocate >@
18:04 mp_en_viaje >2
18:04 asciilifeform lol
18:16 mp_en_viaje asciilifeform, thinkign about it, there's just no way to have a proper trb without the rainbows. and yes it'd be 32 gb, but so what. the point stands, there is a minimal bitcoin box.
↖
18:16 mp_en_viaje it just happens to need >32gb ram much like it happens to need >100gb hdd
18:23 asciilifeform for uses where absolutely gotta fetch arbitrary tx in O(1) , indeed >=32G
18:23 asciilifeform it's a ~linear trade of time for space tho, conceivably could use same scheme with various sizes of table, at predictable cost
18:23 mp_en_viaje for other uses, just not load it in memory. but trb gotta ship with them.
18:24 mp_en_viaje what i'm sayng here is, that a trb w/o the rainbow tables is shipped defective, like a car without wheels or w/e, toys without batteries.
18:26 asciilifeform can point to ~concrete~ braindamages of orig author that resulted in the sad db. one was the expectation that tx 'down to genesis' are mutable 4evah; the other, the idea that 'utxo set' is what matters to fetch quickly, rather than ~any~ tx
18:27 mp_en_viaje very specifically naive sorta "generality fixation" / premature optimization. but yes.
18:28 asciilifeform granted i cannot say how he ought to have decided on concrete number 'down below which not mutable.' he would've had to 'guts' .
18:28 a111 Logged on 2018-12-28 17:03 asciilifeform: with guts.
18:28 mp_en_viaje im not sure an actual number need have been produced.
18:29 asciilifeform well for 2-level db ( 'nursery' where blocks that are thought to be part of the snake's tongue that may still reorg ; 'graveyard' where errything else ) does require a number.
18:29 mp_en_viaje consider the following line : 1. the only meaningful measure of tx mutability is the hashpower that went into mining its block ; 2. consequently, the mutability of tx 100k blocks ago is ~= the mutability of tx 600k blocks ago.
18:30 asciilifeform this is entirely correct afaik
18:30 mp_en_viaje so then all that's needed is a % rule. "99% means, graveyward starts where the last 1% of total difficulty starts"
18:31 asciilifeform mp_en_viaje: this is potentially risky when node is young .
18:31 mp_en_viaje 80% similarly. and so on. just pick one -- by which i mean, expose knob in config, let any user pick his hairdo"
18:31 asciilifeform knob -- yes.
18:31 mp_en_viaje right.
18:31 mp_en_viaje start with 100%, change when to what feels like.
18:35 mp_en_viaje moreover, this discussion illustrates a major flaw in current bitcoin protocol -- it does not correctly judge SUMS.
18:36 asciilifeform mp_en_viaje: i still suspect that safe bringup of a noad where certain blocks are immediately stored in readonly form requires some form of a http://btcbase.org/log/2018-10-22#1865197
18:36 a111 Logged on 2018-10-22 22:37 asciilifeform: mircea_popescu: unrelated to anyffing: i have a tentative thing that eats a http://btcbase.org/log/2018-10-20#1864354 and gives trb option of replacing 'checkpoints' with it ( i.e. on boot, tests all already-stored blox against it, and if any blox in the tape are not yet present, then it requests & accepts them and only them, 1 at a time ). do we want this for field use ? (if so i can put on conveyor for cleanup)
18:36 mp_en_viaje i could (in principle) produce an alternate block #2, very cheaply, but of higher diff than the true block #2. this then ~should~ be accepted by syncing node.
18:37 mp_en_viaje then i could continue this way to block 620k. just as long as i have both a) longest chain and b) a more difficultuous block sometime early on, my chain is technically, by protocol rules, the true chain.
18:37 mp_en_viaje this is currently kept off the table by hand.
18:37 asciilifeform ( observe that it is rather inexpensive, using current-day iron, to bake a phony chain from genesis to... blk# 200k or so )
18:37 mp_en_viaje asciilifeform, to block 1mn or so.
18:37 mp_en_viaje i do not need to match difficulty block by block, see.
18:37 asciilifeform possibly, i have not experimentally verified
18:37 asciilifeform and indeed no need to match diff
18:38 asciilifeform can artificially keep it floating at whatever value
18:38 mp_en_viaje so, real chain weighs 1bn and block #2 weighs 1, i make fake chain with block alt-#2 weigh 2 and total chain weigh 10mn, in 1mn blocks.
18:38 asciilifeform any # that'll fit on yer disk, really
18:38 asciilifeform there's no monotonic component in the diff eqn.
18:38 mp_en_viaje my chain, being both a) longer and b) having a "better" early block, is therefore the "longer chain" in bitcoin sense.
18:38 asciilifeform aha!
18:39 asciilifeform therefore there's an intrinsic wot component in noad bringup
18:39 mp_en_viaje now, this "wouldn't work" because reasons to do with handwave.
18:39 mp_en_viaje asciilifeform, exactly.
18:39 mp_en_viaje but this is also orig author braindamage. "longer chain" has NO NOTION of "proposed chain sigm-adiff"
18:39 asciilifeform hence why asciilifeform wrote a 'cement' mechanism, where you can explicitly feed in a signed list of hashes to newborn noad
18:40 mp_en_viaje what should have been written, and from out the gate, would've been function to sum all diffs, and declare longer chain == highest hash.
18:40 asciilifeform but iirc i never published this ( not that it's hard to make ) , cuz wasn't burning ( and still unsure whether this was the right approach as such )
18:40 mp_en_viaje rather than this sad sum of parts.
18:40 asciilifeform mp_en_viaje: theoretically even nao 'longest chain is the 1 with highest hash' . problem is that this takes arbitrary space to evaluate.
18:40 mp_en_viaje so, in short : to find lulz in bitcoin one needn't indeed look far.
18:41 mp_en_viaje asciilifeform, what do you mean /
18:42 asciilifeform nm, wrong
18:42 asciilifeform mp_en_viaje's formulation is correct
18:43 mp_en_viaje right.
18:44 mp_en_viaje there's a romanian derrogatory negative that exactly sums this problem : "din parti" ie, "no fucking way" (literally, "made of parts"). thisis what satoshi made, the "longest chain" of "highest early block and largest total block count". this does not actually sum to "best chain"
18:44 asciilifeform it's funny, erry yr or so asciilifeform goes 'bbbut i distinctly recall, protocol went like x' ...then dig in the sores again and 'mno, instead did the retarded thing'
18:44 asciilifeform from the 1000000-byte block thing, to this
18:44 mp_en_viaje i recall at least a half dozen of these "nope, nm, mp was right"
18:45 asciilifeform there was at least 1 where we both went 'bbbut x'
18:45 * mp_en_viaje is sad to be right each time
18:45 mp_en_viaje aha!
18:46 mp_en_viaje but the good news is that fixing this is free. simply write the protocol correclty, and let whoever smartass make "bitcoin cash the real bitcoin
18:46 mp_en_viaje by diverging at some point.
18:46 mp_en_viaje since we're discussing "trb should
18:46 asciilifeform nao that i think about it, iirc we indeed had thread where calculated that with 10 or so % of total hash horse , could frag the net ~by orphanage size~ ( us, 0, heathens, a range of x's )
18:46 mp_en_viaje " and dbs -- trb ALSO should keep track and sum the hash weights.
18:47 asciilifeform by constructing a set of successively-longer reorgable chains that take X 'on credit to allcomer' buffers to actually evaluate
18:47 mp_en_viaje myeah.
18:51 asciilifeform to round out this thrd : asciilifeform suspects that some unknown but nonzero % of 'perma-wedged noad' cases, are accounted for by adhoc attempts to carry out this experiment
18:53 asciilifeform ( it'd be easier to say something concrete on this subj if ye olde shitoshi had actually included a reasonable set of debug knobs. but, unsurprisingly, did not, and made it quite difficult to retrofit, also )
18:53 asciilifeform theoretically if you built with 'dumpblock', can debug this scenario by hand.
18:54 * mp_en_viaje shall bbl
18:54 asciilifeform ( to date -- no reports of a live specimen of constructed wedge chain, afaik )
18:54 asciilifeform laters.
18:54 * asciilifeform also bbl:meat
18:59 feedbot http://qntra.net/2019/05/balkan-tensions-rise-with-serbian-military-on-alert-after-kosovo-police-persecute-ethnic-serbs/ << Qntra -- Balkan Tensions Rise With Serbian Military On Alert After Kosovo Police Persecute Ethnic Serbs
← 2019-05-27 | 2019-05-29 → ↑

Random(trilema) | Download hourly DB snapshot | Get Source Code

Theme: Light | Dark | System Default