#trilema | 2018-10-24

09:40

briefly revisiting http://btcbase.org/log/2018-10-23#1865463 >> nobody noticed the omission, but i oughta've pointed out that 'a' and 'b' gotta proceed from opposite ends of the pad, when sending, otherwise risk collision

↖

09:40

a111

Logged on 2018-10-23 18:01 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.

09:41

09:40	asciilifeform	briefly revisiting http://btcbase.org/log/2018-10-23#1865463 >> nobody noticed the omission, but i oughta've pointed out that 'a' and 'b' gotta proceed from opposite ends of the pad, when sending, otherwise risk collision
		↖
09:40	a111	Logged on 2018-10-23 18:01 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.
09:41	asciilifeform	bvt: http://btcbase.org/log/2018-10-23#1865503 << this is very interesting ! i had nfi that open() had been sabotaged on mips-linux ( observe , in your table, errybody has same flags but for mips )
		↖
09:41	a111	Logged on 2018-10-23 21:41 bvt: a better write-up on the vpatch temporary file creation: http://bvt-trace.net/2018/10/vpatch-replacing-mktemp3
09:49	asciilifeform	http://btcbase.org/log/2018-10-23#1865502 >> as promised >> http://nosuchlabs.com/pub/trb/fuckwads_in.pcap ( filtered , for convenience: only incoming crapola )
09:49	a111	Logged on 2018-10-23 21:12 asciilifeform: will post the pcap once it fattens up.
09:51	asciilifeform	tldr : the shitcoin people are in fact pretending to compatibility with ordinary btc protocol; even going as far as using unchanged version strings, and backdated block timestamps ( of course trb rejects the liquishit in O(1) , but it is entertaining )
09:54	asciilifeform	bvt : i'ma have to implement something to make calls to open() portable, cuz this is riotously ridiculous
09:54	asciilifeform	it is not possible to get away without open() in a nontrivial proggy on unixlike
09:55	asciilifeform	my mmap thing, which i've mostly finished rework to prepare for genesis, demands open(), mmap cannot eat fopen()
10:01	bvt	asciilifeform: re open flags: this is exactly what i was pointing at. should have made the text bold, i guess. if all these flags numbers were the same, i would have used the syscall wrapper functions.
10:02	bvt	and the amount of damage is ridiculous, even errno codes are different on mips.
10:02	asciilifeform	bvt: search turned up plenty of folx on the net wondering why their $proggy (all kinds) dun go on mips
10:02	asciilifeform	with culprit being the assumption of standard open() flags
10:03	asciilifeform	i.e. mips linux was sabotaged.
10:05	asciilifeform	my mmap thing was originally c-free (aside from a coupla imported, adatronically, calls) but apparently will have to include a .c simply for open(), to be portable.
10:05	bvt	i would try to make some sort of write-up about this. i wanted to suggest making a Ada library that exposes a subset of Linux system calls without C code, because i clearly needed it for the tempfile.
10:06	asciilifeform	bvt: i have a variant of this in ffa, and yet another subset in mmap
10:06	asciilifeform	prolly at some point we'll unify these and others
10:07	asciilifeform	but currently seems to me that it is impossible to write a portable proggy that uses open() without a .c that #include's the system's flags
10:07	bvt	but so far it's not clear what the subset should be, what to do about C structures (with problems like e.g. https://www.openwall.com/lists/musl/2017/01/25/1)
10:08	bvt	well, for the library that i had in mind was strictly a database of flag name->int mappings, syscall numbers, maybe structure definitions.
10:09	asciilifeform	bvt: didja get a chance to read my udp lib ? the structs thing is the reason for http://btcbase.org/patches/udp_errata_asciilifeform/tree/udp/libudp/unix_udp.c .
10:10	asciilifeform	there is afaik no clean way of portably eating the ridiculous c structs without actually including a .c component.
10:11	asciilifeform	if it weren't for struct sockaddr_in..., struct in_addr..., i'd've simply imported the calls via pragma Import(C, ... )
10:11	bvt	yes, i skimmed through it. all these sockaddr structures would be a bitch to do in ada. this is why i believe it would be useful to define, what subset we'd need.
10:12	asciilifeform	my orig attempt at the udp thing tried to stick with purely pragma Import(...), but the result was definitely not portable, and so i rewrote it like-so
10:14	asciilifeform	imho, segregating as much as possible of unix liquishit in a short .c, is cleaner than buncha Import() and hardcoded flag constants derived by guesswork
10:15	asciilifeform	the .c absolutely gotta be bug-free tho, or it sinks yer whole proggy
		↖
10:18	bvt	i would much prefer going pure ada for a subset of posix. otherwise it's the same as relying on GNAT-specific packages -- it exports plenty of interesting stuff, not sure about networking though.
10:31	Mocky	http://btcbase.org/log/2018-10-24#1865522 >> plus then you either have to reverse the pad for one, or maintain a bit of state for top-eater vs bottom-eater
10:31	a111	Logged on 2018-10-24 13:40 asciilifeform: briefly revisiting http://btcbase.org/log/2018-10-23#1865463 >> nobody noticed the omission, but i oughta've pointed out that 'a' and 'b' gotta proceed from opposite ends of the pad, when sending, otherwise risk collision
		~ 48 minutes ~
11:19	asciilifeform	Mocky: i can think of several algos for reliably picking 'left' and 'right' without any manual config ( recall, 'a' and 'b' have the cards slotted in, in opposite orders, call'em pad 'x' and 'y' , 'a' has x-y and b y-x -- both get same final xor, x xor y, is used as pad p )
11:20	asciilifeform	bvt: thing is, there's a non-negotiable must-have subset of posix, that ~cannot~ be implemented as pure ada. e.g. the udp structs liquishit. or , as we learned from bvt , open()
11:21	asciilifeform	when we get own sane os, can reimplement on ~that~ . but under unixlike, stuck with .c thing
11:21	asciilifeform	bvt: you'll find that the gnat-specific packages are ~entirely liquishit -- check out what passes for 'gnat.sockets' for instance.