mircea_popescu: asciilifeform, indeed not. think about how this works : a) the comment includes a link not-to-trilema. so it's potentially a spammer ; then b) uses an "vps" ip, which has a very high likeliness of being previously used to a spammer, and marked as such in trilema's own antispam.
asciilifeform: i thought mpwp spamola trap was 100% based on the clever boobytrap described in earlier thrd, no magic banlists
mircea_popescu: other than, of course, not using protonmail.
mircea_popescu: in other wowz : http://trilema.com/2015/open-callgraph-for-therealbitcoin-in-svg-format/#comment-114712 << comment automatically (and incorrectly i suspect ?) marked as spam back then
a111: Logged on 2019-05-31 15:57 asciilifeform: they also have a thing where the captain can point to anyone, 'you!' , and then point to any piece of gear, from reactor to toilet, and demand an account of what are all of the parts, and how it works, in detail. and the pointed man must pass the exam. if fails, has no moar 'r&r' time , must study, until passes.
asciilifeform: ftr asciilifeform hasn't been there even as tourist. so many moar interesting places to tour, e.g. north kr...
asciilifeform: aaah the lolzpeople of lolifornia, land of 10k/mo 1room flats, double-digit sales tax, rolling blackouts...
BingoBoingo: ^ For the growing Mud Hut industry files
asciilifeform: they also have a thing where the captain can point to anyone, 'you!' , and then point to any piece of gear, from reactor to toilet, and demand an account of what are all of the parts, and how it works, in detail. and the pointed man must pass the exam. if fails, has no moar 'r&r' time , must study, until passes.
asciilifeform: there is an interesting tradition in ru navy. they open a kingston and fill a lamp cover with sea water; the boat dives, and the green recruits are given to drink, and told : 'this salt water will be the last thing you taste if you fuck up' .
asciilifeform: esp. re trade-offs. e.g., for many decades , air is given 19 % oxygen instead of the typical sea level 21 . reduced fire but at expense of making the men very slightly stupider.
asciilifeform: asciilifeform doesn't work in the sea. but finds these interesting, because they illustrate engineering fundamentals.
asciilifeform: ( iirc wasn't even thought newsworthy outside of ru. diesels 'not sexy', and besides, didn't sink, merely unloaded half the crew as corpses )
asciilifeform: in 1 recent case, in iirc '07, a diesel boat was sold to india and sailed to purchaser, crewed by ~builders and designers~ (is called 'factory crew'). and there was small fire, during which they ended up pumping halon into wrong compartment.
asciilifeform: lotsa material like this in the lit, for aficionados.
asciilifeform: in 1 particular documented case, where boat was raised 7yrs later, they found that an old salt turned valve in wrong direction. fella served on a diff design for a decade, where dir was opposite. he put such strength into 'closing' valve that the handle was bent. rest of crew breathed for 2wks, aside from one who hung self in bed and another who shorted battery with both hands.
asciilifeform: the 'pros' sometimes also made mistake. most of these mistakes are at the bottom of the sea still.
asciilifeform: nao the conscripts came, as people do, in degrees of stupid. and instead of idle chat they would sometimes do things like rewiring the 'did you check compartment x in 17 places' buttons to those of adjacent compartment, so that the 'yes checked' lamp would light and they could instead sleep. then would be caught, and disciplined the old-fashioned way, with beating.
asciilifeform: some of the former would go on to become the latter, most did not. a conscript sailed for 3y.
asciilifeform: mircea_popescu: classic sovok boat was different from the american one in at least 1 fundamental -- there would be ~twodozen 18yo conscripts on board, plus roughly 2x that number of professionals
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: asciilifeform, a yeah, the silence of the classic nuke sub. usgistani agitpropo makers never get this right, from capra's submarine all the way to star trek there's always endless pointless chatter, and bridge bunnies. no such thing in reality.
mircea_popescu: in other news of little consequence, i added 4 more headers and deleted like a dozen or so (older, shittier ones), leaving the grand total at 57.
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
feedbot: http://www.loper-os.org/?p=3378 << Loper OS -- Sometimes, at night, I dream about the boat.
BingoBoingo: 77 want to work, can't because 38 want not to strike but occupy the workplace and fuck it all to hell
BingoBoingo: In the contemporary problem: https://www.elobservador.com.uy/nota/asi-quedo-la-planta-de-friopan-tras-la-ocupacion-del-sindicato-201953020513
BingoBoingo: Anglophages: Everybody must grow rice in the superior Uruguayo style to feed the Africa!
BingoBoingo: In outsiders neglecting the local situation: https://www.bbc.com/mundo/noticias/2012/10/121024_uruguay_arroz_am
asciilifeform: in principle a useful os could consist simply of a lisp runtime and nic diddler (dun strictly need fs etc; could store bits on a nfs or the like)
a111: Logged on 2018-09-04 16:15 asciilifeform: and recall, at one time asciilifeform burned 6mo+ to try and bring up realtek GB nic from 'raw iron', in the end did not even succeed in this
asciilifeform: phf: i once sank good bit of time into attempt to bring up the ubiquitous 'crab nic' (realtek gb) from asm. broke teeth, it needs a working interrupt stack to run (i.e. 'spittoon in 1 strand', need entire os) . since then, found the 'seekrit' datashit, theoretically could do it, but not had time.
a111: Logged on 2019-02-03 17:27 mircea_popescu: in other news, mp's own bash grenadiers regiment suggests an ad interim solution for http://btcbase.org/log/2019-02-02#1891951 in the shape of ls | grep ^x..$' | while read line; do curl -Ls -o /dev/null -w %{url_effective} -X POST -F "pastebox=@$line" http://p.bvulpes.com -w %{url_effective}; done
mircea_popescu: speaking of which, i'm about to transfer ~15 gb worth of pics through http://btcbase.org/log/2019-02-03#1892065 mechanism, and it occurs to me... hey ben_vulpes would this be criminal misuse of the system ?
asciilifeform also catching up , with the bloody ch18, the php crapola ate up moar sweat than -- i think -- any prev. ch, possibly aside from barrett
mircea_popescu: im thinking of catching up with all the invoicing this weekend.
asciilifeform: ty for the work, mircea_popescu
asciilifeform: mircea_popescu: got it, worx. plox to deedbot-invoice asciilifeform (i'ma have to refill the piggy before i can fill it tho).
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
phf: they use some subset of intel cards that let you push/pull own raw packets from userspace, essentially bypassing linux tcpip implementation. that is a direction to consider..
a111: Logged on 2018-08-21 17:36 phf: http://btcbase.org/log/2018-08-20#1843300 << little known fact: slime's architecture was originally implemented in a similar project for erlang called distel, by the same author luke gorrie. lukego also wrote an emacs clone in erlang and tcp/ip stack in cmucl.
a111: Logged on 2019-05-29 08:51 spyked: http://btcbase.org/log/2019-05-22#1915245 <-- in other c coad, /me spent his last 2-3 weeks looking at the tcp stack implementation in linus' kernel. it is truly a fungus, macguyvered with duct tape and rubber bands, such that changing one line almost anywhere breaks shit all over the place.
phf: i'm not sure that's particularly useful. at the time i was still switching between running btcbase on hunchentoot in prod and on alisp/aserve in development
a111: Logged on 2019-05-29 08:42 spyked: in particular, I saw trinque, phf and ben_vulpes have been using it in the past, so I'd appreciate any input you have on the matter
mp_en_viaje: asciilifeform, well, meanwhile since i'm here put a little more weight into the network and so on.
BingoBoingo: And in local cultural weird, the pichis are more likely to tell the government surveyors they smoke "pasta base" (cocaine refining waste product) than marijuana https://www.elobservador.com.uy/nota/personas-que-viven-en-la-calle-aumentaron-a-2-038-segun-datos-del-mides-2019530111026
asciilifeform: ( and with modern-day ru-style cyrillic, rather than the slavonic pre-1860 thing seen in ro museums )
mp_en_viaje: moar like schmuck. vagabond. bum. how do you call these ? student ?
asciilifeform: so moar informant/stooge than 'spy' then
mp_en_viaje: "you're still working for the government, you just don't get a pension"
mp_en_viaje: i think by now they use a sort of auxiliaries that are allowed to marry.
asciilifeform: afaik traditionally marrying aboriginals is verboten for these
mp_en_viaje: cuz that's where the job sends, yes ?
asciilifeform: also waithefuq would anyone move to transnistria. why not to proper ru.
BingoBoingo: ^ In still other USG lulz
mp_en_viaje: in other usg lulz : back in 2010 there was romanian gavin : https://kingofromania.com/2011/12/31/the-foot-of-the-ladder/
mp_en_viaje: closed two days later i wonder ? probably... ALSO the investor's fault ? it's not like "everything the government makes IS shit", not at all ?
mp_en_viaje: imagine if someone collected all the us-ranged dependopopotami, all those suburban fat wives looking for someone to validate their concerns, and sold them off.
mp_en_viaje: imagine, if say the usg were sold on the market. do you think it'd either be closed in two days, or just discontinued for being shit ?
a111: Logged on 2015-05-19 00:48 justJanne: Every. Single. Time. A governmentally owned institution got sold to a US investor they either closed down 2 days later, became shit, or just expensive.
ave1: and then the bridge between the insane world and sane trilema became harder and harder to cross
feedbot: http://trilema.com/2019/the-clouds-that-threaten-domestic-bliss/ << Trilema -- The Clouds That Threaten Domestic Bliss
BingoBoingo: Still, the Herbal and the viagra are there. The seekrit email doesn't have seekrit, and the email part is doubtful
BingoBoingo: Well, here's hwo herbal viagra works. They get some dry herbal and spray with with viagra then put in capsules. Sell as "herbal viagra" far more honest than the seekrit scamola
asciilifeform: standing next to the 'seekrit email' people, e.g. the 'herbal viagra' pushers look honest. (at least viagra actually exists)
asciilifeform: still beggars belief. these imho are almost literally 'selling brooklyn bridge'.
asciilifeform: how the fuck do they get marketed..? 'OUR promisejuice is 9000x moar truthy than $rival's' ?!
a111: Logged on 2019-05-29 23:45 mp_en_viaje: being a common "private" email service recommended outside the republic > being a "private" email service commonly recommended outside the republic ?
asciilifeform: http://btcbase.org/log/2019-05-29#1916188 << i find it riotously lulzy that anyone still can be found to fall for the 'seekrit email' flavour of scamola. srsly, wtf
asciilifeform suspects that dijkstra would've enjoyed 'peh', where there aint even such a thing as a jump
asciilifeform: then sure. d called it 'structured programming' (i.e. the craft of ~not~ writing a proggy like this)
mp_en_viaje: how shall i formalize the idea here...
asciilifeform: often enuff, won't. sorta half the appeal of ada
a111: Logged on 2019-05-29 23:30 mp_en_viaje: http://btcbase.org/log/2019-05-29#1916138 << this incidentally is as fine a measure of code quality as could ever be hoped for : DLC, "disentangled lines count", the number of lines which can be changed.
asciilifeform: http://btcbase.org/log/2019-05-29#1916180 << direct or inverse proportion ? in e.g. ffa, the # of 'can be changed an' still work' is ~0
mp_en_viaje: asciilifeform, it's not the first time!
mp_en_viaje: whatever, next best use for tennessee is the "accidental" re-routing of spent nuclear fuel packages.
a111: Logged on 2019-05-29 23:34 mp_en_viaje: http://btcbase.org/log/2019-05-29#1916147 << you're doing the anchors backwards.
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
mp_en_viaje: being a common "private" email service recommended outside the republic > being a "private" email service commonly recommended outside the republic ?
a111: Logged on 2019-05-29 15:27 asciilifeform: tcp shows erry possible sign of having been designed, from the start, to extend the ease of snoopage from traditional circuit-switched telco grid, to the packet world. consider e.g. the 'helpfully' plaintext sequence numbers.
a111: Logged on 2019-05-29 08:51 spyked: http://btcbase.org/log/2019-05-22#1915245 <-- in other c coad, /me spent his last 2-3 weeks looking at the tcp stack implementation in linus' kernel. it is truly a fungus, macguyvered with duct tape and rubber bands, such that changing one line almost anywhere breaks shit all over the place.
mp_en_viaje: http://btcbase.org/log/2019-05-29#1916138 << this incidentally is as fine a measure of code quality as could ever be hoped for : DLC, "disentangled lines count", the number of lines which can be changed.
BingoBoingo: Sure, but that involves breaking a bunch of rather ingrained habits.
BingoBoingo: And failed at month 11 of the 1 year guarantee
BingoBoingo: The coffee maker
BingoBoingo: And routers on network borders need the entire BGP table in RAM
asciilifeform: or how routers on erry hop of a connection are forced to maintain a 'circuit' state in memory, as if they were telco switches
asciilifeform: tcp shows erry possible sign of having been designed, from the start, to extend the ease of snoopage from traditional circuit-switched telco grid, to the packet world. consider e.g. the 'helpfully' plaintext sequence numbers.
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.
a111: Logged on 2016-08-26 13:34 asciilifeform: tcp is evil, fundamentally because it violates the 'NEVER something-for-nothing-to-all-comers-FUCKOFFRANDOS' principle.
asciilifeform: the protocol is 'fractally retarded' -- i.e. broken on absolutely erry possible level. starting from where it takes exactly 1 trivially forged packet to close someone's connection, to where 'allcomers' get a substantial chunk of memory allocated , and make ddos trivial , to where it forces 9000x moar complicated design of routing gear, to... could continue but why.
asciilifeform: i vaguely suspect that it may have been the original usg-'standards committee'-powered explicitly-organized nobus generator
asciilifeform: spyked: not only is the implementation what it is, but tcp per se is massive pile o'shit, where it aint even possible to implement it w/out 9000 tonnes of state machine gnarl
asciilifeform: the usual megatonne-of-c-liquishit style of 'works'.
a111: Logged on 2019-05-29 09:06 spyked: the weird part is that the linux tcp stack ~works~ for the most part. I imagine the maintainer of that particular subsystem must be a neckbeard with 20+y experience in tcp (because sure, it's not only the implementation, the protocol itself is a mountain of complexity)
a111: Logged on 2019-03-15 21:44 mircea_popescu: made slightly mroe interesting by it having been written before rather than after linus went dumb.
spyked: and then looking at e.g. https://elixir.bootlin.com/linux/v3.10/source/Documentation/CodingStyle , one can readily notice that half or maybe more of the tcp code doesn't meet that minimum set of criteria. and yet... it's there. so, I guess re. http://btcbase.org/log/2019-03-15#1902966 he was prolly dumb from the very beginning
spyked: the weird part is that the linux tcp stack ~works~ for the most part. I imagine the maintainer of that particular subsystem must be a neckbeard with 20+y experience in tcp (because sure, it's not only the implementation, the protocol itself is a mountain of complexity)
diana_coman: by now I suspect most code out there is the fungus sort as that's how things "naturally grow"
a111: Logged on 2019-05-22 19:44 mp_en_viaje: spyked, some very sad http://trilema.com/2017/the-world-has-changed/ shit right there.
a111: Logged on 2019-05-22 21:36 lobbes: As it stands I have two full pages of hand-written notes with various c and apache-stack likbez, and that was just so I could understand up to line 152 of https://github.com/mbattyani/mod_lisp/blob/master/mod_lisp2.c (only 900 or so lines left to eat). I most likely will publish these notes as a blog post once all is said and done
spyked: http://btcbase.org/log/2019-05-22#1915245 <-- in other c coad, /me spent his last 2-3 weeks looking at the tcp stack implementation in linus' kernel. it is truly a fungus, macguyvered with duct tape and rubber bands, such that changing one line almost anywhere breaks shit all over the place.
spyked: and I guess I'd prefer starting from code already battle-tested by L1 (in the form of a tarball + ksum?) rather than shithub, and turning _that_ into a genesis. although I suspect I'll have to dig deeper into the heathenpits of git commits anyway.
spyked: in particular, I saw trinque, phf and ben_vulpes have been using it in the past, so I'd appreciate any input you have on the matter
spyked: so far I've been looking at the project changelog and the patch history and the patches seem like a mixed bunch, with (perhaps) some useful things and breakage a la sslism. so before going further, I'd like to get some idea of what version of hunchentoot the lordship and the L2 are using
spyked: *for the genesis
a111: Logged on 2019-05-22 21:36 lobbes: http://www.thetarpit.org/posts/y05/090-tmsr-work-ii.html#selection-197.31-205.258 << I wager there's a good chance you'll publish a genesis of tbnl/hunchentoot before I eat through mod_lisp, but I agree: as pieces emerge, we can sync up, regrind as needed, etc.
spyked: good morning, #t! following up on the http://btcbase.org/log/2019-05-22#1915244 thread: I've started reviewing hunchentoot, the first step would be to figure out which code base to use as a starting point from the genesis.
asciilifeform: theoretically if you built with 'dumpblock', can debug this scenario by hand.
mp_en_viaje: " and dbs -- trb ALSO should keep track and sum the hash weights.
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 )
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
asciilifeform: there was at least 1 where we both went 'bbbut x'
mp_en_viaje: i recall at least a half dozen of these "nope, nm, mp was right"
asciilifeform: from the 1000000-byte block thing, to this
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'
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"
asciilifeform: mp_en_viaje: theoretically even nao 'longest chain is the 1 with highest hash' . problem is that this takes arbitrary space to evaluate.
mp_en_viaje: rather than this sad sum of parts.
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 )
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.
mp_en_viaje: my chain, being both a) longer and b) having a "better" early block, is therefore the "longer chain" in bitcoin sense.
asciilifeform: ( observe that it is rather inexpensive, using current-day iron, to bake a phony chain from genesis to... blk# 200k or so )
mp_en_viaje: this is currently kept off the table by hand.
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.
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.
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)
mp_en_viaje: so then all that's needed is a % rule. "99% means, graveyward starts where the last 1% of total difficulty starts"
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.
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.
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
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.
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.
asciilifeform: ( the remainder, end up asking for a second lookup )
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 )
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.
asciilifeform: this is true even with 'aggressor', the latter merely asks ~newly connected~ peers to give blox
asciilifeform: BingoBoingo: most of the time aint spent in verify tho
BingoBoingo: Don't forget the more important part. It takes time because verification IS NOT sad
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
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: 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.
mp_en_viaje: the list of fixations.
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
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?
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.
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.
mp_en_viaje: "how long will it take me to read all the books ? IT SEEMS UNREASONABLY LONG!!!"
mp_en_viaje: i think he lived there.
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: oh, they're a mesh ?
diana_coman: ugh, last time the rough sketch sounded as I said above though, lolz
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"
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
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.
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.
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
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.
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
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 ?
mp_en_viaje: how would the server not inform ?!
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
mp_en_viaje: i mean, it's in the stat innit ?
mp_en_viaje: well, if client sets a limit, then oldest-used files get wiped.
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?
diana_coman: client asks what is a? server says it's (name this) (position that) (mesh theother) and so on
mp_en_viaje: function of how much space the user is willing to give the cache, client could indeed keep everything.
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.
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
mp_en_viaje: "now we're printing this guy's helmet. wait, wtf do we put in the press ?!"
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?
mp_en_viaje: similarily you look up new words when you hear them rather than when you decide to use them.
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?
diana_coman: this bit here is the part where we were not in sync
diana_coman: finally at least the whole trouble makes sense
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?
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"?
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).
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: honestly, as a player, I'll then have to hack my own client, lolz
mp_en_viaje: it's easier, and it's not clear that the complicateder way is in any sense better.
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.
diana_coman: no, because it forces the very same problem higher up where there is even less information to decide on when to request
mp_en_viaje: if there IS a queue, you can STILL get a new request just as the queued request is satisfied.
diana_coman: what is the gain in forcing every request -> a message to server?
mp_en_viaje: looky : if there's no queue, you can in principle get a new request just as the old request was satisfied.
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
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)
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 ?
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".
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
mp_en_viaje: AFTER it took it out of the queue. immediately after.
mp_en_viaje: diana_coman, nevermind the "it's pending
diana_coman: or you mean a potential "race condition" there?
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
diana_coman: it's still the same thing
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
diana_coman: it accepts the new request, looks that it's pending so ..nothing to do with it
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.
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
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?
mp_en_viaje: i guess we go back to the text, hang on.
mp_en_viaje: o brother.
diana_coman: only if it throws it away without even using it, can there be "no cache"
diana_coman: uhm, "no cache" is ...impossible; by definition the data on client IS CACHE
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.
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
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"
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
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?
diana_coman: after they resolved is however "refresh", isn't it?
mp_en_viaje: diana_coman, no, after they resolved.
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.
diana_coman: uhm, while it still has them pending or what?
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
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 ?