asciilifeform: BingoBoingo: flibusta mirror was ~100G last i looked. of ~ascii text~ .
asciilifeform: BingoBoingo: the other solution is that the folx who did the orig scan actually give half a shit and proofread. but this is evidently not ever happening in anglostan outside of dedicated effort like mircea_popescu's
asciilifeform: the anglosads, near as i can tell, scanning in their shakspeares and... never touched again.
asciilifeform: http://btcbase.org/log/2019-02-10#1894768 << nao if only ocr actually worked. ( asciilifeform admits, never had much enthusiasm for 'let's preserve gutenberg' on acct of most of it being ~unreadable, even the orig jpegs or whatnot are often '90s-quality and wtf to do with'em but throw out, and ditto the text )☝︎
asciilifeform: ( consider how long took to clean , to reasonable level of non-sepsis, trb -- a 200x smaller product )
asciilifeform: ( afaik the last 'fits-in-head' kernel was 1.sumthing... )
asciilifeform: mircea_popescu: good % of the flagolade is auto-set by the configurator, it's not exactly a civilized product
asciilifeform: all currently fielded asciilifeform kernels are small variations on that 1.
asciilifeform: mircea_popescu: it's a reasonably compact kernel, to support various items currently in standard use, raid card, FG serial dongles, iptables.
asciilifeform: already beginning to tip, like titanic, and blowing horn one final time.
asciilifeform: the 'official' kernel is headed straight to bottom of the sea.
asciilifeform: i regret to inform that i do not have a config that works on 'anythings'
asciilifeform: for instance asciilifeform has a known-working config for all dulap-like boxen; presently in use by diana_coman on iirc both diana_coman units; another for rkisms
asciilifeform: mircea_popescu: re 'which kernels work?' : this is a++ q, but sadly incomplete, instead q is always 'which kernels for on $iron'
asciilifeform: rright but what was the 'still there' 1 doing
asciilifeform: diana_coman: ah looked ? and what was it doing instead of exiting ?
asciilifeform: in re 'had to import exit()', i found that this is troo for ~100% of os i/o, not only e.g. udp but character i/o, etc. i dunlike the standard i/o glue thing came with at all.
asciilifeform: diana_coman: can you post plox the whole test jig, i'd like to reproduce the effect and see wtf , in gdb ( prolly won't get to it until nightfall tho )
asciilifeform: -- at least iirc, can't seem to dig up the pertinent chapter & verse just nao
asciilifeform: diana_coman: incidentally, per the std doc, raise PROGRAM_ERROR with "eggog!"; also oughta drop the whole process dead.
asciilifeform: diana_coman: it is exactly == to GNAT.OS_Lib.OS_Exit(0) , yes, btw; i did the 'import' for the same reason as for the character i/o, i.e. to lose the dependency on the standard lib
asciilifeform: diana_coman: how did you model 'wedged task' ? ( i.e. what didja put in it ? infinite loop? or eternal i/o wait ? )
asciilifeform: i dun know of a workaround for this, either, other than to finally fucking bury unix.
asciilifeform: will add to this also, that if yer thread is actually wedged, it will almost always be on acct of http://btcbase.org/log/2019-02-08#1893811 , i.e. waiting for a blocking unix i/o, and no matter what yer pthreads proggy is written in , c, ada, cobol, whatever, it will still become a zombie, cuz unix is retarded.☝︎☟︎
asciilifeform: it's an exact repeat of the ancient thread re the 'acid' guarantees in sql.
asciilifeform: nuffin keeps you from calling exit(-1) and nuking whole process + all children. i have nfi where is the puzzler here.
asciilifeform: i dun think it even makes sense to think of the problem in terms of 'write a new ada' tho. the way i see ada, is as a junkyard wars workaround against the retardation of pc arch, where pointerolade, overflowable arrays, etc. if you had a sane arch, you could program in moar or less whatever you want (e.g on bolix, ada, fortran, c, lisp, were implemented as simply skins around the arch, and all shared in the nonoverflowability etc )
