asciilifeform: it is interestingly imho reminiscent of plant toxin , d00d couldn't think of anyffin but 'let's make it poison' in re defense

asciilifeform: ( well, fungus, in rms's case )

asciilifeform: successfully turned vegetable

asciilifeform: afaik they no longer think anyffin

asciilifeform: see related thrd, http://btcbase.org/log/2015-01-10#972076 , re similar in gcc ☝︎

asciilifeform: ( he saw the notion as 'making life too easy' for nvidia & other blob pushers )

asciilifeform: linus specifically opposed making a stable one

asciilifeform: the most rampant inconsistency, btw, is not even in the userland abi, but in driver (module) end

asciilifeform: vfication is a 'not whether, but when'(tm)(r)

asciilifeform: i.e. if digging up a vintage kernel, would also have to take up the gcc from the period, or backport the current one, as i understand

asciilifeform: http://btcbase.org/log/2019-02-20#1898063 << very good idea; sadly pertinent , however , is the abi breakage ( chronicled e.g. here : https://archive.is/8j7m0 ) ☝︎

asciilifeform: http://btcbase.org/log/2019-02-20#1898072 << i suspect he was barfing on the 'interfaces' thing. ☝︎

asciilifeform: guten morgen mircea_popescu

asciilifeform: ^ for bonus lulz, it wasn't the 'iso std d&d fireball' but the http://trilema.com/2014/the-all-american-asshole-in-his-own-words-with-my-own-notes/#selection-1021.79-1025.1 thing, from what i gather was a 'mortal combat' clone of some type

asciilifeform prefers the http://btcbase.org/log/2019-02-12#1895439 site, at least was sorta entertaining ☝︎

asciilifeform: ugh

asciilifeform: recall, thrd where 'is it possible to make a bag of rngola that 1) exists in 2 copies 2) cannot be quickly read in transit to destination'

asciilifeform considered this yrs ago as a possible onetimepad scheme , but not satisfied that it could be repeatable enuff for digitize

asciilifeform: 1 slightly moar practical variant of this seal would be if could make the 'glitter' in the epoxy from kcl or other commonplace mild radioactive. then tape instant film over the chassis and develop/swap erry coupla months, and compare the liquishit to previous photo.

asciilifeform: fuhrerbunker , we know had one ( fella was obsessed with 'what if mailbomb' etc )

asciilifeform: you'd want pb foil over the packages, ideally

asciilifeform: ( plus dose the poor silicon erry time )

asciilifeform: the obv problem is that you need 70kg of deathray to verify the seal

asciilifeform: incidentally, asciilifeform was thinking, glitter + epoxy + xray == pretty good '3d' seal.

asciilifeform: http://www.loper-os.org/pub/misc/xray/dead_samsung_35kv_100s.jpg << to complete yest. thrd : the least rubbishy shot of the dead samsung. steel shell prolly calls for a scintillator screen , and large film, to actually get decent shot. but even here usbistic contacts sorta visible.

asciilifeform updated testfire piece ( die shot detail )

asciilifeform: that was btw a 35mm film. instrument can eat 35x35 ~cm~, for ~100x magnification.. ( i just dun have any on hand atm )

asciilifeform: http://btcbase.org/log/2019-02-19#1898025 << actually pretty grainy ( the barbaric film is to blame ) but in the full res jpg can still see e.g. the au whiskers connecting ic pins to dies etc ☝︎

asciilifeform: are these posted ?

asciilifeform: trinque: oh hey

asciilifeform: re ^ -- the steel shell is a bitch, will need tuning for kv. but for demo purposes, the FG analogue board photo ~did~ come out pretty well, will scan it when it dries.

asciilifeform: nobody seems to publish the test data on subj tho, aside from 'golden toilet' ic houses

asciilifeform: will also be interesting at some pt to roast a ~working~ ssd; in theory soft xray eats ssd

asciilifeform will post a scan once he gets a decent exposure, this may not be today, aint a priority item

asciilifeform: 1st photo subj is those dead samsung ssd stix BingoBoingo sent in.

asciilifeform: in entirely other noose, the xray worx...

asciilifeform indeed expected that it's 100% gcc5ism

asciilifeform: http://bvt-trace.net/2019/02/gnat-zero-cost-exceptions-and-asynchronous-task-aborting-part-3/#selection-49.0-58.0 << pretty great.

asciilifeform: trb-capable box, btw, i have one going .

asciilifeform: that's half the appeal, all of my recipe for it still worx.

asciilifeform: afaik they haven't changed the chipset.

asciilifeform: BingoBoingo: apu1 will be exactly same as when i 1st laid hands on it in '14

asciilifeform: ( it may be possible to pack'em tighter, but currently imho reliability trumps max utilization of cubic metrage )

asciilifeform: BingoBoingo: http://btcbase.org/log/2019-02-18#1897935 << to allow for power and sufficient thermal , 4 per 1u. ☝︎

asciilifeform: see, asciilifeform has an actual blobless bios for apu1.

asciilifeform: ( not unless somebody pays to colo one, at any rate )

asciilifeform: it is infested

asciilifeform: we won't be using apu2 at piz

asciilifeform: in 1984.

asciilifeform: it remains a serious wtf to me : think, bolix had ecc.

asciilifeform: ( i'd pay in gold for small box with ecc, dun exist afaik )

asciilifeform: BingoBoingo: iirc no ecc on either

asciilifeform: ( btw there was to be a demo unit of same in the 1st crate, but did not fit masswise )

asciilifeform: mircea_popescu: apu is something rather like a x64 rk.

asciilifeform: i also have an old and well-oiled toolchain for it, where can e.g. throw customer payload directly into rom, if desired

asciilifeform: ( on rk, 0 and 1 respectively )

asciilifeform: and equipped with 3 GB nics.

asciilifeform: mircea_popescu: apu wins substantially on 1 score -- it can eat ~3~ msata ssd's

asciilifeform: i.e. i won't be holding up the expedition for its fix.

asciilifeform: presently correct.

asciilifeform: cuz srsly

asciilifeform: mircea_popescu: i'd still like to see the arm64 wtf resolved

asciilifeform: the apu loses on physical space ( it takes the sq. metrage of 6 rk , just by itself ) and cost ( +30% over rk ) aand naturally x86itude.

asciilifeform: correct.

asciilifeform: ( this is somewhat of a black art, it is probably possible to come up with a benchmark where the rk wins )

asciilifeform: and in apu -- 2. but apu still cleans its clock for most processes, oddly enuff (tho not by large margin)

asciilifeform: 4 .

asciilifeform: so asciilifeform leans to installing a qty of x64 boxen of roughly same cost profile as rk ( but with added bonus that they eat sata drives ) : apu1. these also have bonus of published electrical schematic and custom asciilifeform bios from src.

asciilifeform: what we have this wk, is a 'sjlj-gnat dun go on arm64'. i dun expect this is a permanent disease, but i do expect it'll take time to fix, esp. if asciilifeform has to do with own 2hands. until then, rk cluster is stuck with the obsolete compiler ( which runs e.g. 'lamp stack' and even zcx-gnat , but obv. won't run the emerging standard sjljistic one until fix. )

asciilifeform: BingoBoingo: ty, will take a look shortly, 1st would like to macroexpand mircea_popescu's point

asciilifeform bbl,meat

asciilifeform: BingoBoingo: plox to make use of mircea_popescu's suggested, in log, leads for the hunt, but do not limit to it

asciilifeform: BingoBoingo: it is also my understanding that the new rk is presently idle. if this is still so, i'ma commandeer it for propaganda ops. lemme know.

asciilifeform: BingoBoingo: if no passengers stand up, crate will contain 100% piz buildout materiel . and would like your input on precisely what, also asap.

asciilifeform: and on what existing userbase says ( asciilifeform still ! waiting ! for any passengers ! to stand up, re http://btcbase.org/log/2019-01-15#1887214 . if none by end of this wk, i will assume there are none ! ) ☝︎

asciilifeform: in part the exact mix will depend on what BingoBoingo yields in terms of userbase prelim. hunt

asciilifeform: re rk -- not errybody is running ada proggy, and errything else appears to work quite well there.

asciilifeform: re capacity : also needs discussion. currently considering rk array (1u), two x64 boxen of dulap type, and additionally a set of apu1d4 (see logs, or https://archive.is/8JBbH ) .

asciilifeform: and would rather not have to do whole thing from scratch

asciilifeform: BingoBoingo: ty, would really like to see motion on this front asap

asciilifeform: BingoBoingo mircea_popescu has point : are you gonna produce a list of spammees, or just what is it you have hands full with, and asciilifeform has to dredge the net with own hands and halt all other work ?

asciilifeform: ( as i understand, battlefield proggies will use sjlj moar or less exclusively )

asciilifeform: fwiw mine also worked ( i.e. didn't bomb in bvt't test ) on zcx. but not tried sjlj yet.

asciilifeform: bvt: built with sjlj mode ?

asciilifeform: neato

asciilifeform: fits on floppy...

asciilifeform: meanwhile, in world of ancient warez finds : http://nosuchlabs.com/pub/warez/artek.zip << ada-83 compiler for msdos, circa 1987.

asciilifeform: i can see that it might have to let go of any locks it holds, but what if holds none ? this is easily shown at compile time

asciilifeform currently wonders why the fuck an aborted thread needs to unwind its stack frame by frame, it has no further biz in this world after it stops, so wtf even for, new thread gets entirely new stack

asciilifeform: imho yes

asciilifeform: ave1 are you gonna bake one ? someone's gotta, and i will with own hands if no one has it ☟︎

asciilifeform: and hrm, loox like we still dun have a genesis for this thing

asciilifeform: ( currently it's a 4hr build, lol )

asciilifeform: would also like to see wtf i did to the -j32 thing

asciilifeform: not to mention 'test may reveal presence of bug, but never absence'(tm)(r)

asciilifeform: notyetwunderbar, still gotta 1) sjlj 2) try test w/ naked one and see if pill even necessary

asciilifeform: looking in the log, iirc diana_coman had same issue, & cured

asciilifeform: despite both paths being set correctly

asciilifeform: gnat1: RTS path not valid: missing adainclude and adalib directories

asciilifeform: but this is with zcx. then went to build with sjlj, found, grr, that it :