log☇︎
44700+ entries in 0.025s
diana_coman considers eating treebark: ate it before, certainly better than eating glibc-barf
asciilifeform will brb : teatime.
asciilifeform: ada.interrupts ~will~ have to be tested, it's a must for 'bare irons' adaisms as a class. ☟︎
asciilifeform: ( for killing processes, it is possible to e.g. use ada.interrupts system . but asciilifeform not yet tested ! )
asciilifeform: that being said, sjlj is apparently totally broken on arm gcc currently, and if want a threaded proggy on e.g. rk, currently stuck with zcx
a111: Logged on 2019-02-12 23:41 asciilifeform: there's a lulzy 'pentagon standard' one, the name presently escapes me, iirc it is in the log tho
asciilifeform: diana_coman: the 1 use case i can picture for zcx, is on ultracompact irons. but even there, really, are we gonna use a http://btcbase.org/log/2019-02-12#1895612 somewhere ?! ☝︎
diana_coman: I guess the main thing against it would be that part where can't kill
diana_coman: I don't know about option c i.e. whether there is something lost by going with it
diana_coman has no curiosity on the topic: all pain at its time, not earlier
asciilifeform: ( e.g. asciilifeform was quite surprised when found that trb and ALL deps built cleanly & functioned on static musl ) ☟︎
asciilifeform: rrright, was curious re the volume of barfola ☟︎
diana_coman: asciilifeform, no, but obv I will have to not try but do it
diana_coman: asciilifeform, honestly, all I wanted was this game! lol
asciilifeform: diana_coman: if it aint a seekrit: didja ever try building client on musl ?
asciilifeform: ( the less said on the subj, the better, tho, my appetite already ruined by thinkin' about it )
diana_coman: to my mind option b has the benefit that it concentrates the effort in the right direction at least ☟︎
asciilifeform: diana_coman gets the trooly hard nuts to crack ( which is why retained by s.mg for coin , neh )
diana_coman remembers that eulora client is 99% NON-tmsr
asciilifeform: ( asciilifeform is for instance at this very moment sitting on a glibcistic gentoo box, but where all tmsr soft is musltronic )
asciilifeform: mircea_popescu: fix of sjlj on arm64 is actually moar urgent than arm-cuntoo, cuz sanely build ( static-musl ) ~will~ run on glibcistic linux
asciilifeform: i expect that i'm even doomed to open a book and see how the fuck arm64 worx.
asciilifeform: mircea_popescu: entirely. see 2d ago thrd.
diana_coman: that's precisely why it was tolerated until now afaik: because all sorts not yet fully ported to anything tmsr
mircea_popescu: asciilifeform getting an aarch64 musl sjlj going will be a fun task.
diana_coman: and asciilifeform beat me to it
asciilifeform: diana_coman: the caveat is that i still dunhave a working cuntoo for all asciilifeform-operated irons; e.g. rk is still running barbaric old glibc gentoo
mircea_popescu: diana_coman looks like it's going the way of cuntoo-ada-musl, no glibc.
diana_coman: re glibc: until now I saw it as tolerated until full tmsr version (whatever that might be, i.e. owned glibc version or musl or whatever)
asciilifeform: rather than continuing in a babelized gnat with 'pick yer threader, pick yer stdlib' etc
asciilifeform: given this, asciilifeform would go with 'b' + 'we fix the breakages , both as-we-find-'em and proactively '
mircea_popescu: it was short form for that.
mircea_popescu: asciilifeform still gotta build the ada environment ~with something~. ☟︎
asciilifeform: ( as asciilifeform recently discovered re ffa. it dun thread, and gcc correctly snips out all pertinent coad )
asciilifeform: 'd' is arguably mis-statement of problem, a threadless proggy incorporates ~neither~ system
mircea_popescu: asciilifeform i very much don't expect you want the prb 12 that is emacs. rewrite yes ? :D ☟︎
asciilifeform: for instance, emacs has yet to be cured, as i understand ☟︎
asciilifeform: mircea_popescu: cuntoo is arguably a realtime test lab for 'what does removing glibc from ~errything~ cost'
mircea_popescu: asciilifeform but it's not you who has to see, maybe someone sees, what. im certainly not sending you to e.2
mircea_popescu: asciilifeform current one prolly v49, note how gcc went from 5 to 8 in 2 years.
asciilifeform: i dun see where drepperism wins in ~any~ version, vs. the ab initio and 10x moar compact musl.
asciilifeform: re 'e', i can't picture what'd move anyone with two neurons to rub together to maintain a glibc, that'd be rather like starting a trb from prb 12 (or what is current one)
mircea_popescu: e. something else (among which possible e.1. someone reads and implements dwarf properly ; e.2. someone picks a glibc to grandfather and dedicates himself to cleaning and fixing.)
mircea_popescu: d. ada-zcx-musl-static is the standard for non-threaded programs, we don't standardize threading.
mircea_popescu: c. ada-?-musl-static is the standard, either zcx or sjlj is acceptable (mostly based on what threading philosophy one embraces), with an obvious preference for zcx if one doesn't thread. ☟︎☟︎
mircea_popescu: b. ada-sjlj-musl-static is the standard, and we simply don't sign or use anything that doesn't live up to this.
mircea_popescu: a. we make no standard, every man for his own, but : a.1. ada is the preferred language ; a.2. musl is the preferred standards provider ; a.3. zcx is the preferred exception mechanism ; a.4. static is the preferred build mode. this should come with a design process for candidates evaluation for standardization.
asciilifeform: this is rather like if 2 d00dz run, and the 1 carrying 100kg of lispmachine ends up winning.
asciilifeform: ( and when found that ~despite this~, http://www.loper-os.org/?p=2906 , was pant-shittingly hilarious, how koch still managed to be the tortoise in the race ) ☟︎
asciilifeform: asciilifeform's 1st step in writing ffa, recall, was to conceive of (and prove) an arithmetic workaround for above. that, right off the bat, cost ~10fold cpu.
asciilifeform: they didn't include a word x word mul that gives you both halves. why not ? 'oh not all irons have a mul instr.'
asciilifeform: mircea_popescu: ... nor is this the only instance of this kinda thing. consider e.g. https://archive.is/MxPlA#selection-14.407-2653.3
a111: Logged on 2019-02-12 23:41 asciilifeform: there's a lulzy 'pentagon standard' one, the name presently escapes me, iirc it is in the log tho
a111: Logged on 2019-02-17 15:21 asciilifeform: unix tries to 'be all possible kitchen' and appears to 'succeed', via fraudulently slipping in 9000 unprincipled-exceptions (hardcoded limits, not only in gcc, but even 'ls' , see old thrd, and moar or less errywhere ) , and 'optimizations'
asciilifeform: mircea_popescu: near as i can tell , zcx is a http://btcbase.org/log/2019-02-17#1897558 , it attempts to implement multiprocess on ~all~ machines, incl. ones that dun have any support for interrupts (e.g http://btcbase.org/log/2019-02-12#1895612 ) ☝︎☝︎
a111: Logged on 2019-02-17 14:14 mircea_popescu: asciilifeform one of the larger, more impressive books in my parents' library was "welt der kunst". i couldn't read german, but mom explained it's "the world of art" so it populated my childish immagination for a full decade, until old enough to read it. by that time it disappointed -- not that anything could have lived to heights a kid might build in mind over years.
mircea_popescu: i actually thought this. i was still thinking this, feb 11th.
mircea_popescu: and i thought, naivity of naivities and unexamined infantilism of unexamined infantilisms, that sjlj is a quaint artefact of slow yore, meanwhile supplanted by more modern, better alternatives.
asciilifeform: ( none of asciilifeform's items to date, called for it )
asciilifeform: mircea_popescu: until diana_coman's test battery, i never even attempted to use the tasking system.
a111: Logged on 2019-02-12 13:12 bvt: during the gnat build, the sjlj runtime is built, so it should be possible to switch to it and test.
mircea_popescu: afaik everybody up until a week ago when http://btcbase.org/log/2019-02-12#1895231 nobody even compiled ada other than zcx. ☝︎
mircea_popescu shall give it some time to hear from people.
asciilifeform: item is ~10x the mass of musl, and fulla 'surprises' that erry time turned out to be architecturally baked in.
mircea_popescu: anyway, this can rest nao,
mircea_popescu: nevertheless, we never actually said "do not use this".
mircea_popescu: yes, no glibc was in fact a preference, and we got it out, of trb, of eulora, etc. no argument there.
asciilifeform: i dun think anyone's compressed it into a compact chronology of yet
asciilifeform: mircea_popescu: this was a ~3 month thread
a111: Logged on 2015-04-06 18:19 mircea_popescu: what's now needed is an expert computer engineer willing and able to take over maintenance of libnss, starting with fixing it so it allows proper static linking.
asciilifeform: this was a 2015 find. after which asciilifeform immediately proceeded to get glibc the hell out of trb.
asciilifeform: when uncovered that drepper (maintainer of glibc) deliberately broke static linkage globally
asciilifeform: it was subj of mircea_popescu's letter to rms, and the associated lulz
a111: Logged on 2015-04-29 16:28 mod6: so libnss is dynamically compiled and built/linked to glibc, and can not be avoided?
asciilifeform: was found that glibc actually prohibits static linkage.
asciilifeform: mircea_popescu: we did. recall the 'nss' incident.
asciilifeform: mircea_popescu: imho the near-term thing to do is for bvt to get the gcc5sim, glibcism, out of his test setup. then can proceed to fix bugs that we actually have in the house, rather than liquishit that only afflicts glibctards.
mircea_popescu: asciilifeform yes. but to my knowledge to date musl was a preference rather than a standard. we never said "no more glibc linking" as we said eg http://btcbase.org/log/2018-09-19#1851879 ☝︎
asciilifeform: as is all current test build of ffa, etc
asciilifeform: mircea_popescu: the diana_coman-bin we disasmed yesterday , is musltronic.
mircea_popescu: some time to look at things and consider matters will be needed ; but i specifically want to hear something from asciilifeform ave1 bvt diana_coman phf spyked trinque ☟︎☟︎☟︎☟︎☟︎
asciilifeform: but remains to be established if bvt's bug afflicts it.
asciilifeform: ( half the reason why asciilifeform dug out musl, is that it's compact enuff to be fixable, at least in principle )
mircea_popescu: so is basically the idea what we want is to get sjlj to work on musl for ada proggies ? or what ?
mircea_popescu: in any case, this is a major decision / inflexion point, and we truly need all hands on deck for this, i'm not equipped with the right chicken darts to throw at guts / read feathers thereof.
asciilifeform: quite obv, any fix will have to fix musl.
asciilifeform: glibc has 0 biz in tmsr proggy.
asciilifeform: this is theoretically fixable. the sad part tho is that gcc is a potentially ~bottomless well of these.
mircea_popescu: so leaving hardware alone, "zombie thread because northbridge went south" etc -- we still need a linking scheme that works.
asciilifeform: to revisit orig upstack thrd : pc dun offer iron locks. so threading relies on software locks, that 'work' in the sense where gcc is relied on to shit'em out correctly. what bvt appears to have found , is that (under particular inputs) it doesn't.
asciilifeform: this is how the 'cloud' people ended up with their circus. 'pc is broken' 'what if you connect 9000 pc'
mircea_popescu: s.mg is perfectly willing to eventually erect torture chamber where shamed boxes ritualistically destroyed for their sins.
mircea_popescu: the principle ain't changing to fit the world.
mircea_popescu: so it'll come to more boxes, whatever.
mircea_popescu: i find it works fine with people ; and it'll work doubleplusfine with hardware. let it adapt to my needs or die.
mircea_popescu: something like "keep two of everything and throw out anything that behaves in any way contrary to your illusion no matter what happens".
asciilifeform: that's asciilifeform's tack.
mircea_popescu: i intend to approach hardware breakage at hardware level.
asciilifeform: what we did, is to poke with awl until punctured some of the illusions.
asciilifeform: or the 'seppuku of son'