Show Idle (>14 d.) Chans
← 2018-10-22 | 2018-10-24 → ↓
mircea_popescu: money kinda cancelled, but yeah
mircea_popescu: http://btcbase.org/log/2018-10-23#1865268 << they aren't ; but bad peer set can produce it also, and often enough does.
a111: Logged on 2018-10-23 01:48 asciilifeform: http://btcbase.org/log/2018-10-23#1865261 << incidentally i dun see how these are mechanically distinguishable from a node's pov
mircea_popescu: http://btcbase.org/log/2018-10-23#1865276 << don't waste your time with that, let it emerge naturally.
a111: Logged on 2018-10-23 01:51 mod6: Gotta catch up on l0gz and the rest. In particular, I'm just about nowhere on my task of creating answers to FAQs/Common Questions about the Foundation itself. I'll be working on that this week as a main priority - will post what I have for review/comments/corrections in #trilema by end of weekend.
mircea_popescu: every time we notice same answer is given to repeated question, we note it down. before, what's the use ?
mircea_popescu: sit there try to come up with imaginatioins of future people seems a waste of your time.
a111: Logged on 2018-10-22 22:44 asciilifeform: relatedly, mod6 et al, i suggest abolition of '-verifyall' flag, it should really be permanently welded on, bypassing sig tests doesn't win ~anyffin in so far as i can tell
mircea_popescu: entirely nonfeature.
bvt: hi, i have mp-wp set up now: http://bvt-trace.net/2018/10/instead-of-hello-world-fg-tests/ . I will publish writeup and updated vpatch for vpatch later today.
bvt: thx
mircea_popescu: "While the FG shop has been closed for quite some time already," asciilifeform think we should bake a new set ?
mircea_popescu: diana_coman re http://ossasepia.com/2018/10/18/smg-comms-chapter-3-packing-serpent/#selection-85.346-85.466 wouldn't it be better to have a single style for this ?
mircea_popescu: slowly but surely a republican ada style manual is shaping up (and through the exact http://btcbase.org/log/2018-10-23#1865304 process, at that!)
a111: Logged on 2018-10-23 04:35 mircea_popescu: every time we notice same answer is given to repeated question, we note it down. before, what's the use ?
diana_coman: mircea_popescu, what would the style be there?
diana_coman: on one hand libs on their own should logically have their own types; on the other hand, when they are used as part of a bigger project, it makes sense I think to make their types subtypes - where they fit/are the same
mircea_popescu: i dunno, make everything a byte ? or an octet
mircea_popescu: ie, have some tmsr-wide meta-types.
diana_coman: hm, theoretically the byte is standard but there is the bit/byte confusion issue and moreover I really find octet easier on brain as it directly points at "it's eight bits!"
diana_coman: that being said, names are one thing, definition of the types another: i.e. every packet and project still needs to define/have defined somewhere the types it uses
diana_coman: ftr I quite like the neat way in which asciilifeform defined those basic types in FFA; however, he went for the classical types so byte, nibble ; and I find octet SO much easier than I'm reluctant to give it up in my code (though all it takes is anyway a "subtype Octet is Byte" at top if Byte definition is to be adopted)
diana_coman: than->that
esthlos: http://btcbase.org/log/2018-10-19#1864316 << apologies alf, I'm running behind! trying to gather time to get caught up in the next week or two
a111: Logged on 2018-10-19 21:27 asciilifeform: whatever happend to http://summaries.logs.esthlos.com btw
deedbot: http://bimbo.club/?p=64 << Bimbo.Club - TMSR Log Summary - 10/19/2018
mircea_popescu: diana_coman i can see it ; i like octet also, but yeah, can't start forcing this cultural issue on people. a one line define i guess only reasonable approach at this point.
diana_coman: yes; basically Ada makes it easy enough to not have to force anything; funny how Ada is in fact *very* accommodating - where it makes sense to be
mircea_popescu: yeah. i guess a history of c cultural sadness is showing in my preoccupatons huh.
mircea_popescu: a well, what can you do
mircea_popescu: aaactually, ill tell you what i can do : im going to teh beach. back thurs or some shit!
diana_coman: ahaha, that's the spirit: when C strikes, go to the beachz!
diana_coman: have fun
asciilifeform: happy beaching, mircea_popescu
asciilifeform: diana_coman: i actually have 0 objections to 'octet', tho i confess i never suffered from 'bit'-'byte' conflation ( never worked on a box with 7 or 9 bit bytes, e.g. the CDC described in 1st ed k&r -- tho i did work on boxes with odd word lengths, e.g. pic16, where 14bit nonbreakable word... )
asciilifeform: in own proggies, i like using explicitly-bitted types, e.g. Unsigned_8 in http://btcbase.org/patches/udp_genesis#L441
diana_coman: asciilifeform, it's like a 1ms internal, perceptible interpreting-slowdown every time I meet bit/byte
diana_coman: not exactly confusion, just ...stumble I guess
diana_coman: and yes, octet is defined in smg.comms as unsigned_8 ofc
asciilifeform: nao possibly i never suffer from this because i very rarely refer to bits explicitly
diana_coman: (I just don't want to carry about Interfaces.Unsigned_8 everywhere)
diana_coman: not to mention that I think it is actually saner to have local names for types used
BingoBoingo: Enjoy the beach
asciilifeform: !Q later tell nicoleci http://btcbase.org/log/2018-10-23#1865327 >> s/Their/There
a111: Logged on 2018-10-23 13:19 deedbot: http://bimbo.club/?p=64 << Bimbo.Club - TMSR Log Summary - 10/19/2018
lobbesbot: asciilifeform: The operation succeeded.
asciilifeform: http://btcbase.org/log/2018-10-23#1865312 << ideally we oughta bake the new one, with ice40 & scintillator, imho
a111: Logged on 2018-10-23 06:19 mircea_popescu: "While the FG shop has been closed for quite some time already," asciilifeform think we should bake a new set ?
asciilifeform: the primary headache of old FG is imho the very modest output rate, which makes the thing take ridiculous length of time to test on my bench
a111: Logged on 2018-10-23 06:05 bvt: hi, i have mp-wp set up now: http://bvt-trace.net/2018/10/instead-of-hello-world-fg-tests/ . I will publish writeup and updated vpatch for vpatch later today.
asciilifeform: mircea_popescu: classical FG also fits very reluctantly in servers, but currently i dun have a good idea re what specifically to do about this ( the 'obvious' pill is to have a pci variant, but ice40 is too small for the necessary logic, which in itself is quite gnarly )
asciilifeform: if x86 pc were a product of sane folx, it'd have rng sockets on mobo...
asciilifeform: or at the very least , >1 serial port ( the current pizarro boxen, do have rs232 header on mobo, but only one, and at the traditional +/- 12v signal levels, rather than ttl, and i eschew the converters, because they all work by oscillating capacitor pump, hence noisy )
asciilifeform: i wouldn't even be opposed to putting usb logic on FG -- but to this very day have not found a sane (i.e. not reflashable via usb) interface ic , aside from the chinese dongles ( which i outboarded, because if a piece can be outboarded -- it oughta, per specificity-of-diddling )
asciilifeform: diana_coman: given as you're the leading industrial FG user, perhaps share your pov on the above ?
diana_coman: asciilifeform, so far it's been mainly use-in-testing, what can I say; what is it you'd need feedback on?
asciilifeform: diana_coman: the redesign
asciilifeform: right nao, 2 FG ~just barely~ fit in a 1u serv, and it takes adhesive fasteners
diana_coman: I can't say that I see a clear suggestion on how to solve that though
asciilifeform: aand there's the usb-ttl thing, which is gnarly
diana_coman: myeah, that's about the main current pain from my pov
asciilifeform: if this were a bake-by-the-thousands product, we could bake asic. but currently this is not realistic imho
asciilifeform: ( plus i ~like~ that it gets made from off-the-shelf components, from strategic pov it is imho superior )
diana_coman: so far the FGs are one of the relatively few things that I positively like having to deal with!
asciilifeform: what i'd really like is to bake an entire comp, a la rockchip, with FG on board. but this too is in same budgetary ballpark as asic .
diana_coman: I rather think we'll get there one day; not yet though
asciilifeform: ( if yer baking asics, incidentally, may as well bake a http://btcbase.org/log/2015-01-22#987731 and get sane cpu )
a111: Logged on 2015-01-22 06:26 asciilifeform: whateverthefuck fpga cpu << http://www.cs.utah.edu/~elb/cadbook/Chapters/Chapter13/mips.v << mips.
asciilifeform: if could afford asic with ~100k transistors -- could have 256x256 multiplier, have 4096bit constant-spacetime rsa in coupla millisecond...
asciilifeform: 'if wishes were horses'(tm)
asciilifeform: i'ma describe , for the l0gz : ideal cpu for crypto would be something quite like the schoolbook mips.v -- no cache, no branch prediction, no pipeline, no dram controller (run off sram strictly), a set of large regs for multiply-shift , and dedicated pipe to FG (i.e. have single-instruction that fills a register with entropy )
asciilifeform: would also have some antifuse rom on-board, with option to run entirely from same.
asciilifeform: fabricate it in 1uM or similar 1980s process. package with optical quartz lid , a la old EPROMs, for audit-with-childrens-microscope.
BingoBoingo: billymg: The CoC situation is lulzier than my reading of it yesterday lead me to believe
deedbot: http://qntra.net/2018/10/manufactured-trannycocist-outrage-over-sqlites-longstanding-benedictine-code-of-conduct-as-coc-incompatibilities-set-up-to-replace-license-incompatibilities-as-top-open-source-drama-fountain/ << Qntra - Manufactured TrannyCoCist Outrage Over SQLite's Longstanding Benedictine Code Of Conduct As CoC Incompatibilities Set Up To Replace License Incompatibilities As Top Open Source Drama Fountain
asciilifeform: in related lulz, '...following his brief sabbatical in which he pledged to shed his abusive tendencies, it's hoped a kinder and gentler Linus is ready to resume his duties. Perhaps not coincidentally, with the return of Torvalds will come a "harassment-free" code of conduct that is now part of the kernel source tree.'
BingoBoingo: Not really news unless someone involved in the zombie Linus thing comes up with a line like: "but that would put me in the position of editing and redacting Benedict of Nursia, as if I were wiser than he"
asciilifeform: in other noose, 178.238.224.213 ( by all indications, does not contain a public node of any kind ) has been spamming randomly generated blox, incl. to zoolag, at the rate of 5-10 erry sec
asciilifeform: if receiving end were prb ( which last i knew, still had the 'orphanage' thing ) -- would balloon to fill ram
asciilifeform: diana_coman: the 1 crackpottery i've considered adding to FG-2, is an 'authenticated' mode, where userland proggy gets ability to verify that rng bits actually came from a particular FG. the way to do it would be to have a keccak salt, printed on the board, and have the thing send , instead of naked bytes, packets, of b0,b1,...bN bytes, followed by keccak(salt, b0,b1,...bn) . could be enabled by jumper setting, conceivably.
asciilifeform: cuz right nao, theoretically, a supplier of e.g. usb-ttl dongles, or even bugged cable, could substitute prng for the FG bits, undetected
asciilifeform: i'ma let mircea_popescu ponder whether this kind of thing is worth doing
asciilifeform: 1 of the wins from it would be that user could immediately verify that baud rate etc are set correctly, instead of relying on the convenient happenstance that a FG misconfigged serial line will produce low-entropy rubbish (with stuck bits)
asciilifeform: the obvious down-side, aside from the substantially moar complicated logic, would be that you could no longer dd if=/dev/fg | dieharder etc
asciilifeform: would have to actually process the stream before use.
asciilifeform: 1 possible way around this, would be to send the hashes on a separate serial line.
asciilifeform: then the primary one could function exactly as the classical FG line did.
asciilifeform: ( at the cost of occupying 2, rather than 1, serial ports )
asciilifeform: ( if it isn't obvious to the reader -- the salt would have to be unique per-board, naturally )
asciilifeform: another pheature i've considered, is to give the thing a sd card slot, so it could fill it straight for otp use. but this is perhaps a bridge too far.
asciilifeform: ( tho quite possibly a FG2 that doubles as an iron otptron, could be a marketable win in itself )
a111: Logged on 2016-06-10 18:07 asciilifeform: ;;calc 10**12 / ((9600 / 8) * 60 * 60 * 24)
asciilifeform: i suspect that there is a sane space b/w the classical design and http://btcbase.org/log/2016-09-12#1540775 extremity, simply gotta find what it is.
a111: Logged on 2016-09-12 22:47 mircea_popescu: comes alive at night and fucks your wife.
asciilifeform: 'and here is where you strap a live snake, to bite-while-you-smite!'(tm)(r)
asciilifeform: meanwhile, in heathen lulz, https://archive.is/B9hHc#selection-9797.129-9817.37 << ye olde lukejr, 'http://therealbitcoin.org (which is NOT a full node, mind you)'
asciilifeform: didjaknow.
asciilifeform: ( nao i'm curious, what, by d00d's lights, is 'full node', and where might one get such a thing )
Mocky: sd card slot has merit. for iron otptron even two slots is not going overboard imo if it doesn't overcomplicate the design, since generally will need two copies and may prefer not to plug into general purpose comp
asciilifeform: Mocky: it's an old idea of asciilifeform's -- otptron gets 2 sd slots. fill switch triggers fill-up of both with identical otp. then you fly to bananistan with ~one~ and trade with the other fella for his. then you both have identical xor of pad-a and pad-b, in the respective slots.
Mocky: yup, or fill two over lunch together and each walk away with identical copy
asciilifeform: ( he did same thing, on his end )
asciilifeform: Mocky: idea is that you dun need to transport the unit itself
asciilifeform: Mocky: theoretically dun have to use with an actual comp, can have dumb glass terminal on the plaintext side of each box
asciilifeform: or voice encoder, etc
asciilifeform: the ciphertext side can be an off-the-shelf ethernet-to-rs232 box.
asciilifeform: 1 of the things i like about otp box is that it is trivial to verify that it functions as specified ( can plug in a pad with known contents, throw in known plaintext, and observe -- with a comp of your choice -- what comes out )
Mocky: i'm not familiar with off-the-shelf ethernet-to-rs232 box, but it sounds self explanatory
asciilifeform: the method where you exchange cards, has 2 wins: it is not enuff for enemy to get copy of simply 1 card, must get one of each ; and rng failure on 1 side doesn't sink you, you get combined reliability of the 2 rng's ( perhaps yours is of 1 type, and other fella's -- another )
asciilifeform: they're a standard item, common in laboratory/industrial automation etc
Mocky: ah yes, i see the 2 cards angle now
asciilifeform: this kinda thing is 1 obvious application for a quality rng ( dun even have to be blazing fast rng, an ordinary FG handily fills a 1G card in ~week or so )
asciilifeform: and for point-to-point link, e.g., shell, can last for a good while ( i dun think i've put 1 whole GB through a shell in the past yr... )
asciilifeform: or if yer doing voice, 100*10**9 / ((9600 / 8) * 60 * 60 * 24) / 365.0 ~= 2.6 ~years~ of 9600 baud voice, with 100G card.
Mocky: yeah but that card took 2 months for FG x10 to fill, no?
asciilifeform: with scintillator FG , at MB/s, faster.
asciilifeform: but even with ordinary one, it aint much of a problem, just be sure to get the fillers started ~before~ current pad runs dry.
Mocky: yup
asciilifeform: current FG moar than fast enuff, to do 1/year pad flights b/w 2 hypothetical points.
asciilifeform: the 1 missing ingredient, is somebody who actually wants this.
asciilifeform: it is, really, 1970s tech, with the exception of the ssd.
asciilifeform: but even in '90s, with GB disk, could have been easily built.
asciilifeform: the scheme of course lives and dies by the rng; but this is common to any form of crypto whatsoever.
Mocky: but also by ensuring material is not ever reused
asciilifeform: Mocky: well yes, you nuke each block on the card prior to xoring plaintext and sending
asciilifeform: and for good measure, use the cards 1ce, cremate'em when empty
asciilifeform: ( they're , what, a few bux ea. )
asciilifeform: the 1 slightly subtle devil in the details, is that you gotta authenticate incoming data, or enemy can force you to burn your pad by sending rubbish. fortunately there are several easy ways of doing this ( the most obvious, is to use a small piece of each block as a hash salt, and send keccak(salt+ciphertext) after each N bytes of ciphertext )
asciilifeform: that way you can reject rubbish, if somehow enemy is able to send you any
asciilifeform: you only decrypt and wind forward the pad if the auth hash matches the expected one for the block salt.
asciilifeform: this does cost you a certain amount of bandwidth, but imho is necessary.
Mocky: and is block number sent or assumed next available?
asciilifeform: Mocky: you'd want the link to be fully synchronous
asciilifeform: i.e. nothing is sent until prev block ack'd
asciilifeform: that way you dun have to send block #s, or to risk the endpoints getting out of sync.
Mocky: still have to handle unexpected disconnects tho right?
asciilifeform: what's a disconnect in this context ?
asciilifeform: either you get the ack, or you don't
Mocky: ack is sent but never received
asciilifeform: so counterparty retransmits his last ciphered block until he gets it
Mocky: is the last ciphered block stored on disk?
Mocky: ok, i don't see a hole in it
asciilifeform: simple scheme, for example: 512 byte pad blocks; 1st 64 bytes are reserved for a-b keccak salt, last 64 bytes -- b->a salt, 384 in the middle for payload pad. say 'a' starts the convo: sends c = 384byte-plaintext xor 384byte pad . followed by h = keccak(a->b salt + c ). then he expects an ack in the form of keccak(b->a salt + c ) before he winds forward to next block.
asciilifeform: imho it's pretty simple.
asciilifeform: the link, being a physical object, can be disrupted by enemy, but there's nuffin anybody without a copy of the pads can productively do to the traveling bits.
Mocky: so have to store block you most recently ack'd as well, to detect resend
asciilifeform: correct, you need a sram big enuff to hold 2 blox.
asciilifeform: three whole pennies' worth..
Mocky: hows the ack look like, a hash?
asciilifeform: as described above
asciilifeform: in 'simple scheme, for example..'
Mocky: oh right
asciilifeform: the idea being, that nobody lacking a copy of the pad can cause you to wind yours forward.
Mocky: yeah
asciilifeform: each side obtains proof that the other actually received and correctly decrypted a block, prior to sending another.
asciilifeform: nao if you really must have an asynchronous link ( for e.g. delivery on carrier pigeons, or somesuch ) you can have sequence #s. but still must have authenticator mechanism similar to above, or enemy can force your pad forward by sending crapola.
asciilifeform: in an asynchronous scheme, you gotta explicitly divide the pad in halves, one for a->b and one for b->a, so as to exclude any possibility of either end making use of a block of pad that may have already been made use of by other side meanwhile.
asciilifeform: imho the synchronous variant is preferable, when the underlying physical link permits it .
Mocky: the simplicity of otp is appealing, and knowing that no one is sitting on a back door
asciilifeform: can think of it as simply a very long untappable wire.
BingoBoingo: <asciilifeform> meanwhile, in heathen lulz, https://archive.is/B9hHc#selection-9797.129-9817.37 << ye olde lukejr, 'http://therealbitcoin.org (which is NOT a full node, mind you)' << Has been addressed. Turns out I STILL haven't been banned (likely from not using the thing) https://twitter.com/BBoingo/status/1054795688679272450
asciilifeform: Mocky: it dun replace rsa, you can't sign with it, or speak to >1 counterparty . but imho has its uses
asciilifeform: and modern tech makes it possible to avoid the traditional fatal boojums connected with otpism.
asciilifeform: ( specifically: need to carry pads often (not any moar, carry 1TB disk etc ) ; reuse of pad ( nomoar, burn each block after use ) ; shit rng (nomoar, we have decent rng ) )
asciilifeform: BingoBoingo: 'It validates completely validates blocks and transactions' ?
BingoBoingo: It's twitter. The only way to win is Trumpisms
BingoBoingo: And the input box is a turd
BingoBoingo: laggy as fuck
asciilifeform never used twatter, does not know
BingoBoingo: It's not a vice I can recommend
deedbot: http://qntra.net/2018/10/derps-now-doing-dns-over-https/ << Qntra - Derps Now Doing DNS Over HTTPS
jurov: mod6: BingoBoingo: ben_vulpes: asciilifeform: and everyone - therealbitcoin btc-dev mailing list is now working on the Foundation's server. You should have got an announcement,
jurov: but at least gmail needs to be told this is not spam.
asciilifeform: jurov: neato ! ty
mod6: jurov: thanks! messages were in my spambox, but did receive. :]
mats: http://btcbase.org/log/2018-10-23#1865399 << reply from buterin: 'You guys should train users to take an active role in governance and keep their software up to date by having more hard forks.'
a111: Logged on 2018-10-23 17:07 asciilifeform: meanwhile, in heathen lulz, https://archive.is/B9hHc#selection-9797.129-9817.37 << ye olde lukejr, 'http://therealbitcoin.org (which is NOT a full node, mind you)'
asciilifeform: in other lulz: yet another http://btcbase.org/log/2018-10-23#1865380 found, 165.227.138.176
a111: Logged on 2018-10-23 15:40 asciilifeform: in other noose, 178.238.224.213 ( by all indications, does not contain a public node of any kind ) has been spamming randomly generated blox, incl. to zoolag, at the rate of 5-10 erry sec
asciilifeform: same algo, thing shits out 9000 shitblox and dumps at line speed
asciilifeform: ^ also not a public noad of any description
asciilifeform: http://p.bvulpes.com/pastes/4GZTO/?raw=true << raw barfola. observe that NONE of the 'prev' hashes match any known bitcoin block .
asciilifeform: 501 of'em, interestingly
asciilifeform: conceivably, these could be forkcoin noades behind a nat
asciilifeform: ( tho traditionally these have some means of sticking with their own kind, possibly this has changed )
asciilifeform: would be interesting to learn wtf is inside those blox. but i dun currently have the box configured to save liquishit ( no conceivable disk would suffice )
mod6: asciilifeform: i appreciate you passing around the offending ips
asciilifeform: i'ma leave a tcpdump -w fuckwads.pcap -i eth0 "host 165.227.138.176" or "host 178.238.224.213" running on zoolag
asciilifeform: possibly we learn moar later
asciilifeform: or hey, wai not tcpdump -w fuckwads.pcap -i eth0 "net 165.227.0.0/16" or "net 178.238.0.0/16" .
mod6: *thumbsup*
asciilifeform: if anybody notices moar of these, plox to share, so i can add'em to the glue trap
mod6: im grepping my incoming logs for similar, will report if i see sludge
asciilifeform: i admit that i'm pretty curious re just what it is that they're offering up as blox.
asciilifeform: will post the pcap once it fattens up.
bvt: a better write-up on the vpatch temporary file creation: http://bvt-trace.net/2018/10/vpatch-replacing-mktemp3
asciilifeform: update : so far only buncha addr's, getdata's, inv's, from *176, in the glue trap.
asciilifeform: defo seems to be a misconfigured/maliciously-configged shitfork noad, none of the tx hashes in the inv's line up with anything from human planet
asciilifeform: as for *213 : behold : answer to this bermuda triangle : https://archive.is/9j7vx#selection-5463.0-5525.29 << tardstalk : 'interesting thing! a creativecoin clone ( with strange ico: real coins vs virtual coins ) ... if you want to add me: addnode=178.238.224.213:12358' etc etc
asciilifeform: 'The installation is a three-by-three-meter replica of steel and wood reproducing the coin minting machine used by Spanish settlers in the gold and silver mines of Potosí, (Bolivia). The mill mints physical coins that are automatically registered in a blockchain...' blah blah
asciilifeform: wtf this idjit is doing connecting to trb noadez, is anybody's guess.
asciilifeform: such... 'creative'
BingoBoingo: lolollolololololocaust
asciilifeform: i gotta wonder nao, if prb's tx checker is porous enuff that it actually relays these !
BingoBoingo: It could very well be
asciilifeform: suggests that the typical shitcoin-of-the-day nowadays is a bch-style phork, rather than 2013-style 'prb with genesis swapped'
asciilifeform: and they live, live, cuz not in fact worth the bullet
asciilifeform: ( bullet still costs a day's work, or so, to set up shitnode-of-the-day, then find some exchange where it can even be traded , etc )
asciilifeform: offers approx same ev as hunting rats in sewer for their skins
asciilifeform: i suspected shitfork, when realized that the 501 blox gotta be a few kB most, ea. -- my pipe couldn't disgorge 501 human-sized blox in <2sec
BingoBoingo: [emoji: watermelon running from Baltimore native]
billymg: http://btcbase.org/log/2018-10-23#1865377 << BingoBoingo: nice. imo it's a great way to respond. "oh a CoC? why yes, great idea! in fact let's take it one step further" -- a sort of embrace, extend, extinguish strategy
a111: Logged on 2018-10-23 15:14 deedbot: http://qntra.net/2018/10/manufactured-trannycocist-outrage-over-sqlites-longstanding-benedictine-code-of-conduct-as-coc-incompatibilities-set-up-to-replace-license-incompatibilities-as-top-open-source-drama-fountain/ << Qntra - Manufactured TrannyCoCist Outrage Over SQLite's Longstanding Benedictine Code Of Conduct As CoC Incompatibilities Set Up To Replace License Incompatibilities As Top Open Source Drama Fountain
← 2018-10-22 | 2018-10-24 → ↑
Random(trilema) | Download hourly DB snapshot | Get Source Code