1000+ entries in 0.311s
mircea_popescu: "Slave reads were allowed for performance reasons" << check it out, apparently it's in the sql
spec after all. even on mondoshit >D
Reuel: mircea_popescu is there a
spec for the bot you mentioned
mircea_popescu: and i see no problem with any other or only other services be used - which iirc i even said when bot
spec for archival was drawn, that everyone making one should ideally use a diff service
mircea_popescu: (of course as far as the
spec goes, the bot saves archive.is + base64 blobs of all pages, so there is that, as inconvenient as it is)
ben_vulpes: is there any sort of
spec for "what difftron entails"?
mircea_popescu: so then use that. as the
spec says, m.t specifically left unspecified.
mircea_popescu: i don't think today's logic does anything ; and i don't expect carrying it forward is useful.
spec does include room for trb.n to do some banning, including on the basis of passively exfiltrated data from trb.b. that a protocol for this purpose may later develop i don't dispute, but it's not included both because it's not needed and because it can't become a "dependency". it's not.
mircea_popescu: do you read the
spec or just sit there and dream a little dream ?
mircea_popescu: davout no he's saying it's not in the sql
spec! which, considering how specwork goes, he might be even right about some version.
mircea_popescu: 1) shared_buffers is to be per
spec "25% of available ram" ; but it does diminish returns in the gb. you probably have it as 128mb, make it 2gb say.
phf: ben_vulpes: well, we're kind of constrained by the hardcode -p1 behavior, but i've no idea if that's an implementation detail or a
spec mircea_popescu: check that out, there's no actual fips 180 past 1 published online. because why the fuck would there be. anyway, i can't source this "The SHA512/384
spec says that the final bit length of the message is to be stored as a 128-bit (!) integer at the end of the message." assertion. as best it can be determined the blocks are either 512 (for sanity) or 1024 bits (for 384 hmac etc)
phf: i guess the multiple keys idea was already introduced in gossipd (in the original
spec i suspect it was a solution to "no automatic RSA-ing" problem)
phf: mircea_popescu: csail (mit ai lab then) published "ai memos" from 1959 to sometime in early 2000s where they described a lot of "firsts" in computing in general. scheme
spec was published by sussman and steele, lisp 1.5 compiler (first "self-hosting"), lisp machine architecture, etc. most papers are not so much ai as computing in general.
mircea_popescu: so i'ma just wait here for you to p, and comment thar rather than try and
spec a tmsr-rsa-clearsign ?
adlai: although i may be understanding the
spec incorrectly
phf: neither current wot nor gossipd
spec wot have the history component, because if you go by "there's no rating outside of rater" past ratings make absolutely no difference.
mircea_popescu: asciilifeform iirc we had a
spec for sane log that went along the lines of separations like discussed
mircea_popescu: is nary a
spec in this history and soon forgotten like bell bottoms and whatever other fashionable nonsense. 80s hair and 1790s sociopolitics.
mircea_popescu: it being a
spec, it didn't contain an implementation, no.
mircea_popescu: eventually we'll have a full
spec, at which point we'll be forking anyway.
a111: Logged on 2016-10-31 21:48 gabriel_laddel:
http://btcbase.org/log/2016-10-31#1560716 < it may be that CLIM itself sucks -- but the implementation is 100% common lisp and is easy enough to mechanically alter if you have problems with it. Should tmsr~ decide to strip whatever features from CLIM and alter the
spec, at least we have a codebase and
spec to argue about and something working to us
a111: Logged on 2016-10-31 21:48 gabriel_laddel:
http://btcbase.org/log/2016-10-31#1560716 < it may be that CLIM itself sucks -- but the implementation is 100% common lisp and is easy enough to mechanically alter if you have problems with it. Should tmsr~ decide to strip whatever features from CLIM and alter the
spec, at least we have a codebase and
spec to argue about and something working to us
a111: Logged on 2016-10-31 17:45 phf: trinque: i'd like to at least try it out. i'm unconvinced clim is a good idea, because there aren't any good implementations. mcclim is terribly over-engineered (in the best of java style, with delegates for proxies etc.), clim codebase that lispworks/allegro share is less so, but more hacky. which makes me wonder if clim
spec itself is suspect
gabriel_laddel:
http://btcbase.org/log/2016-10-31#1560716 < it may be that CLIM itself sucks -- but the implementation is 100% common lisp and is easy enough to mechanically alter if you have problems with it. Should tmsr~ decide to strip whatever features from CLIM and alter the
spec, at least we have a codebase and
spec to argue about and something working to us
☝︎☟︎☟︎ a111: Logged on 2016-10-31 17:45 phf: trinque: i'd like to at least try it out. i'm unconvinced clim is a good idea, because there aren't any good implementations. mcclim is terribly over-engineered (in the best of java style, with delegates for proxies etc.), clim codebase that lispworks/allegro share is less so, but more hacky. which makes me wonder if clim
spec itself is suspect
phf: well, mcclim layers things in a way that i thought was part of the
spec, but turns out it was beach's decision (to among other things support multiple different backends). when i was trying to optimize the x11 backend last time, i was hitting multiple "independent" layers, that all demanded attention. there wasn't really an 80/20 solution, which made me conclude that there's not a single subtrate that you can optimize (the way, say,
phf: trinque: i'd like to at least try it out. i'm unconvinced clim is a good idea, because there aren't any good implementations. mcclim is terribly over-engineered (in the best of java style, with delegates for proxies etc.), clim codebase that lispworks/allegro share is less so, but more hacky. which makes me wonder if clim
spec itself is suspect
☟︎☟︎ BingoBoingo: And definitely too far out of
spec for bottled "single barrel" origin product.
BingoBoingo: Likely barrel were to far out of
spec for blending into standard 20-30/bottle product so "exclusive" label attached.
mircea_popescu: adlai a) you don't get to call a
spec leaky. if it's not clear what's going on to you, it's probably because you are dumb, not because the going on is broken.
mircea_popescu: trinque he has a serious issue with things that i don't yet fully grok, but i can not presently distinguish from this irrational meltdown and the irrational meltdown on the gossipd
spec.
mircea_popescu: ah also : re "encryption" : we CAN use the eliza involved in gossipd
spec (anyone actually did this or just some quick napkin work and then forgot about ?) to eliza the actual emissions.
Framedragger: phf: is that
spec available online somewhere (or, keywords) by any chance? curious to take a peek at some point.. is it published by symbolics?
phf: in related news i finally read genera's defsystem
spec and not only does it ~makes sense~ it's also obvious that first takes on c-land defsystems was a pale imitation of original functionality, i.e. слышит звон но не знает где он
Framedragger: mircea_popescu: understand and agree. it's worth to have it be pointed out in the comments if only so that someone doesn't start assuming that the
spec implicitly provides guarantees of uniqueness etc. and good to have a picture of the madness and lack of guarantee anyway. but i guess you're right
Framedragger: heh possibru! and in other news scriba complies with the mighty bot
spec (restarting)
mircea_popescu: most people approach
spec work as a positive endeavour ; which is why mine read so bewildering at first.
mircea_popescu: large part of
spec's job is exactly in the negative. a good
spec allows me to construct a complete negative of the item. this is much more important than commonly realised
mircea_popescu: the part where you can
spec things that don't actually fit in head. for instance, i can specify "a good fuck", or "an acceptably behaved slut" or "a boring housewife"
scriba: Logged on 2016-09-13: [17:51:53] <asciilifeform> the reason why we ~have~
spec-by-program is because it is the only actual alternative to fits-in-head.
mircea_popescu: i suppose effort to bridge the gap has been made, perhaps most notably the "literate code" thing, but still.
spec is not code ; code is not
spec.
mircea_popescu: much like a definition of an apple is not an apple ; just so a
spec is not a program.
mircea_popescu: maybe ; but a
spec is not defined as "can mechanically be transformed into a working program".
a111: Logged on 2016-09-13 08:11 mircea_popescu: trinque asciilifeform & everyone : without detracting from the more important gossipd
spec work, im thinking of making a bot
spec. it'd require bots to answer in pm to help, help json and help sexpr. comments/ideas ?
shinohai: mircea_popescu: a bot
spec would help clarify things, yes
mircea_popescu: trinque asciilifeform & everyone : without detracting from the more important gossipd
spec work, im thinking of making a bot
spec. it'd require bots to answer in pm to help, help json and help sexpr. comments/ideas ?
☟︎ mircea_popescu: asciilifeform you should prolly write a lighthouse thingamajig
spec and ping trilema.
mircea_popescu is very happy he sat down to try and pin down that
spec.
mircea_popescu: once we have some sort of acceptabru
spec all sorts of prototyping work can begin
mircea_popescu: trinque i know i brought this on myself, but an unsubscribe will be useful so i don't get everything on gossipd
spec twice lol
mircea_popescu: moreover nothing prevents emergent/de facto specs. the job of the gossipd
spec is to keep people from doing world-breaking idiotic stuff. how they handle their own wives is their own problem.
Framedragger: topic-based publish/subscribe has been sorta well researched, but i guess this problem is on another 'layer': gossipd document would leave this for 'implementation'. even though it may not be trivial at all, to make decisions regarding such matters, choose best
spec, or design it from ground zero. but of course makes sense to discuss the foundations first
mircea_popescu: kinda why i'm reading through this
spec ben_vulpes dug up.
phf: (that idea is actually introduced in original gossip
spec, but it's not obvious without rereading relevant bits a few times that it allows you to have secondary key
phf: we had a thread about it two weeks ago, where the conclusion was that gossipd as written in the only available
spec has all kinds of problems and shouldn't be implemented/used
mod6: i'd have to dig it up, but i thought there was a trilema that outlined the '
spec' back a while ago.
mircea_popescu: come to think of it, is there such a thing as a gossipd
spec even ? what's the current canonical version ?
mod6: but, maybe the first step, to recognize Framedragger, is to update the
spec. there has been much discussion about this, and maybe I'm having a hard time keeping all of the details in my head.
Framedragger: [like, *of course* the only reason we want a
spec which allows for data in initial syn packet is for shitphones to be able to load google ads quicker. use for security???! nowai]
Framedragger: and gossipd without any auth whatsoever wouldn't really be that? in all honesty, i should reread the
spec, which is probably outdated, and log search sucks, fml
a111: Logged on 2016-09-08 21:44 gabriel_laddel: I'm translating the
spec from HTML to CLIM.
a111: Logged on 2016-09-08 21:58 mircea_popescu: wait, the clim authoritative
spec exists as a html ?!
Framedragger: yeah that i really like. reminds of that bitcoin wallet
spec - no non-ascii parts
Framedragger: mircea_popescu: no disagreement there; just pointing out that sometimes small arrangement disagreements still prop up; say, different order of variable initialization (which otherwise bears no actual significance); etc. of course one *could* have a convention
spec so precise taht it would include things like "if there is arbitrary order of initialization of $x then default to alphanumerical order".