log
84 entries in 0.314s
a111: Logged on 2019-04-23 23:09 asciilifeform: incidentally, even a very brief look at the 1801 item confirms the troof of http://btcbase.org/log/2019-02-14#1896836 -- thing defo aint a 'and here is where the ameri-crystal does x' , it's a quite 'fits-in-head' object , very evidently produced from page-long spec of the orig instruction set
spyked: re ffi, in that older research I've tried to avoid fast-running code in favour of fits-in-head, but I'll make sure to double-check in this iteration. the only www-related cffi dependency I recall was in cl+ssl, which I will remove on sight before genesis
asciilifeform: incidentally, even a very brief look at the 1801 item confirms the troof of http://btcbase.org/log/2019-02-14#1896836 -- thing defo aint a 'and here is where the ameri-crystal does x' , it's a quite 'fits-in-head' object , very evidently produced from page-long spec of the orig instruction set ☝︎☟︎
bvt: OriansJ in #bootstrappable has a notion of hygiene (at least basic, ie groks fits-in-head), and still works on the stage0; i had no interaction with janneke (mes author) yet, so can't make claims about him. he does make some noise in the #bootstrappable and #guix
asciilifeform: the forth-like notation admittedly requires some practice, for the unprepared ; but the win from it is a fits-in-head interpreter ( ch.17 -- 1024 ln; ch.18 , with subroutines , currently writing the docs -- 1516 , and not expected to ever grow much )
asciilifeform: constanttimeized stein's o(n^2) gcd ( http://www.loper-os.org/?p=2963 ) is not only imho fast enuff (even a magical 100fold speedup in it, would not affect speed of rsa key gen measurably , consider above ) but fits-in-head and has no error terms.
asciilifeform: ( afaik the last 'fits-in-head' kernel was 1.sumthing... )
asciilifeform: ffa in particular is intended as , among other things, a didactic demonstration of what means 'fits-in-head'.
a111: 74 results for "fits-in-head", http://btcbase.org/log-search?q=fits-in-head
asciilifeform: !#s fits-in-head
bvt: myeah, complexity does not go too well with both constant-time and fits-in-head.
a111: Logged on 2018-08-21 18:28 asciilifeform: all i particularly care for in re scripting is to obtain a replacement for perl/python/bash where the interpreter is simple (i.e. readable, fits-in-head, auditable, correct)
a111: Logged on 2018-08-21 18:28 asciilifeform: all i particularly care for in re scripting is to obtain a replacement for perl/python/bash where the interpreter is simple (i.e. readable, fits-in-head, auditable, correct)
asciilifeform: all i particularly care for in re scripting is to obtain a replacement for perl/python/bash where the interpreter is simple (i.e. readable, fits-in-head, auditable, correct) ☟︎☟︎
asciilifeform: Mocky: not merely this. there is also a set of human-enforced conventions re: 'fits-in-head' of any proposed change.
a111: Logged on 2018-05-01 14:59 trinque: and in service to fits-in-head
trinque: and in service to fits-in-head ☟︎
asciilifeform: spyked: i dun have anything against mechanical proof per se; but it is NOT a substitute for fits-in-head, because there is nor cannot be any such substitute. and the mass of the theorem-verifier is to be included with the mass of the program, for the purpose of 'is this head-fittable'. but possibly i repeat old thread.
asciilifeform: in any case fits-in-head MUST come ahead of 'proofiness'.
asciilifeform: i do not have anything against mechanized proof per se. but in practice it is in ~100% of published cases used as an attempted 'i can't believe it's not self-evident correctness!' margarinesque substitute for fits-in-head.
asciilifeform: thing is, a sparkism is not a substitute for a 'fits-in-head'-correct routine.
asciilifeform: or for that matter, usable maxwell. ( modern electronic design uses a narrowly restricted, i.e. sorta-fits-in-head special form of maxwell )
asciilifeform: but there are already plenty of haskellists writing nonsense. asciilifeform wanted an actually usable fits-in-head item.
asciilifeform: and if i were a haskellist and writing with an eye toward ~machine~ proof, rather than fits-in-head, i probably would have written one.
asciilifeform: it however is a gangrene that will grow ANYWHERE where fits-in-head is not an iron principle.
asciilifeform: a proper fits-in-head item fits in the literate man's head.
mod6: <+asciilifeform> which, btw, imho is intrinsically unsuitable for a fits-in-head rsatron, it is extremely gnarly and uses float approximations that get magically unfudged back to int, etc << ugh. right.
asciilifeform: which, btw, imho is intrinsically unsuitable for a fits-in-head rsatron, it is extremely gnarly and uses float approximations that get magically unfudged back to int, etc
asciilifeform: aka fits-in-head.
asciilifeform: FIRST you write the fits-in-head minimal ffa-like thing. THEN you spark.
asciilifeform: ( and -- fits-in-head !! )
asciilifeform: because it is a ludicrous proposition -- massive ball of shit, that makes gcc look compact and fits-in-head.
asciilifeform: but married to x86, and certainly not fits-in-head.
asciilifeform: in this case, correctness & fits-in-head.
asciilifeform: thing is optimized for -- strictly -- constant (always-worst-case) time and space usage; and fits-in-head (in that order)
trinque: http://btcbase.org/log/2017-04-10#1641431 << that this is wrong, and letting data access patterns ~between distinct algorithmic components of your system~ be built in ad-hoc manner destroys fits-in-head for the entire system ☝︎
a111: Logged on 2017-02-11 00:27 asciilifeform: ROP is why you want not only 'fits-in-head' source of proggy, but the smallest binary physically possible.
asciilifeform: ROP is why you want not only 'fits-in-head' source of proggy, but the smallest binary physically possible. ☟︎
ben_vulpes: the situation's a good example of the tension between writing code that does one thing really specifically well, and fits-in-head, vs a larger program that handles eg conditions and the concomittant complexity
asciilifeform: it isn't even about 'attack surfaces', but for getting maximally compact description. i.e. fits-in-head.
asciilifeform: the sleep of fits-in-head breeds monsters.
scriba: Logged on 2016-09-13: [17:51:53] <asciilifeform> the reason why we ~have~ spec-by-program is because it is the only actual alternative to fits-in-head.
asciilifeform: the reason why we ~have~ spec-by-program is because it is the only actual alternative to fits-in-head.
asciilifeform: and not fits-in-head.
g_l: http://btcbase.org/log/2016-08-30#1531840 < CLIM fits-in-head, and the final showstopping error (X11 related crap) has been reduced to a simple test case, and is in the process of being solved. ☝︎
asciilifeform: (for which the toolkit includes, e.g., 'fits-in-head')
asciilifeform: the correct answer, from the twin standpoints of reliability and fits-in-head - is bitcoinfs.
asciilifeform: mircea_popescu: fits-in-head means that i get to huffmanize TO THE MAX
asciilifeform: which is a fallacy because... correct-c still is not conducive to fits-in-head; is not readily distinguishable by naked eye from underhanded-c; cannot provide rational guarantees of handling error conditions mid-way; and 10,001 other defects that don't look like defects to folks who grew up with crippled systems
asciilifeform: a fits-in-head library with no loose parts and no sharp edges can be used as it is.
trinque: doesn't this run directly against your fits-in-head thing?
asciilifeform: 1.1MB TGZ of src !11 this does not appear to be in any serious way 'lighter' or more fits-in-head-sy than x11.
asciilifeform: mircea_popescu: in the interest of fits-in-head - sure
davout: anyway, my point is that if nobody remembers, that nobody bothered to blog it, the fact that completeness is a problem might indicate a violation of fits-in-head
asciilifeform: because 'correct' MEANS, among ither things, fits-in-head.
asciilifeform: minimal as specified in r5, AND ts does not fully implement r5 (largely in the interest of fits-in-head, but also original author's laziness)
asciilifeform: it intereferes with fits-in-head and therefore harmful.
asciilifeform: what i wanted was a generic, fits-in-head (a few 1000 lines of c, no deps) stateless, 'protocol-less' cipherator that one could put, e.g., ftp over
punkman: "because why trust on a single cryptographic primitive" << because it's nice if the whole thing fits-in-head, and even if you cascade there is still the possibility of meet-me-in-the-middle attacks or I dunno what else
ascii_butugychag: http://log.bitcoin-assets.com/?date=04-02-2016#1396374 << sorta what bernstein tried to do. fits-in-head ciphers. ☝︎
assbot: Logged on 04-02-2016 15:56:22; ascii_butugychag: punkman: fits-in-head only plox.
ascii_butugychag: punkman: fits-in-head only plox. ☟︎
ascii_butugychag: 1) fits-in-head. also known popularly as 'knowing precisely wtf you're doing'
asciilifeform: and also don't wait for me to write a fits-in-head and provably non-misbehaving btc client, even though i would much like to, know exactly how, and even have bits'n'pieces sitting around. because instead of this i'm stuck doing pointless crud in шарашка, so as to eat.
asciilifeform: there is such a thing as fits-in-head
ascii_field: it is important to remember why we came up with the whole shebang of 'fits-in-head 1-page' patches, 'v', the lot
ascii_field: understand, i have no objection to tools such as computerized theorem-proving, data flow analysis, etc. except in that these are put forward as ~substitutes for fits-in-head simplicity~.
ascii_field: my other problem is that i have not yet found an implementation of ml language that fits-in-head.
ascii_field: from usg's point of view, ANYTHING is better than having folks wake up to cpu-with-bounds-checking-on-all-ops and fits-in-head
ascii_field: invariably subtracts from fits-in-head.
assbot: Logged on 09-09-2015 11:39:38; asciilifeform: http://log.bitcoin-assets.com/?date=09-09-2015#1267236 << the path to fits-in-head STRICTLY depends on every particular thing on the machine being implemented ONCE. this includes lexer, parser, related items.
asciilifeform: http://log.bitcoin-assets.com/?date=09-09-2015#1267236 << the path to fits-in-head STRICTLY depends on every particular thing on the machine being implemented ONCE. this includes lexer, parser, related items. ☝︎☟︎
asciilifeform: this means fits-in-head.
asciilifeform has very little patience for peddlers of 'hardenings,' 'mitigations,' and other so-called 'solutions' which are guaranteed to advance the pestilence of non-fits-in-head
asciilifeform: the ultimate systemic solution is 'fits-in-head'
asciilifeform: seems as if they are even abolishing 'busybox' in favour of something 'fits-in-head'-flavoured
asciilifeform: the answer is ALWAYS, without exception, fits-in-head+does-not-crash+operates-correctly.
trinque: Naphex: as far as what it means to have a fits-in-head system, please do read asciilifeform's material; he's far more qualified to say.
ben_vulpes: <asciilifeform> ... prevention of fits-in-head << can vouch for the pita of this in clojure
asciilifeform: but to get back to original thread, i wasn't even specifically thinking of 0days in the jre itself, but the overall turdification and prevention of fits-in-head that java inescapably leads to.
ascii_field: there is no incremental path from -committee of crud- to -individual fits-in-head-
ascii_modem: fits-in-head is the only answer. though it goes well with a balanced diet of public impalements for wreckerz
asciilifeform: the principal thing-not-to-do is complexity that prevents fits-in-head
asciilifeform: because the only genuinely curative pill is: fits-in-head.