log☇︎
14100+ entries in 0.096s
mircea_popescu: bflame how about you make yourself useful and implement a keccak as discussed ^ then patch diana_coman 's tree with it.
a111: Logged on 2019-03-10 20:00 phf: there are three possible solutions, a) make sure that stack is arbitrarily large b) feed keccak buffers no larger than some magic size c) rewrite keccak to operate on char arrays directly without the need for bitstream allocation
diana_coman: that seems to be at most at reading-chunk-from-file level which is not really related to keccak and not a problem if I understand correctly what phf says; specifically on one hand he said http://btcbase.org/log/2019-03-10#1901225 and then option c from http://btcbase.org/log/2019-03-10#1901236 ☝︎☝︎
diana_coman: that requires simply a bit-level keccak; which requires in turn someone with the time to do the transformation as it were
mircea_popescu: diana_coman i mean that instead of keccak receiving array of bits stored in octets, keccak receives (and processes) a eucomms field.
mircea_popescu: to be clear : i expect that in the regular course of republican work, GB-sized vdiffs will occur -- strictly because we're contemplating confiscating all sort and manner of heathen artefact, and by now bloat is just a synonym for heathen. the "increase stack" fix works ok as a stop-gap, but we can't really 8x everything just for boredom.
mircea_popescu: diana_coman do you see the wisdom in implementing a keccak variant that uses eucomms-style fields ? so that something like "hello world" would be passed as 0x01146865 6c6c6f77 6f726c64
bvt: i confirm that it is both in genesis and is a valid path. i'm testing live cuntoo though, have no access to bootstrap env currently
trinque: bvt: you confirm that this exists in your genesis, but is not a valid path?
diana_coman: i.e. there isn't yet a bit-level keccak implemented, no
diana_coman: mircea_popescu, when he says "explodes" he means that keccak implementation expects as input a bitstream where each bit is stored in an octet
bvt: trinque: i also confirm that under /cuntoo/portage/profiles there is a directory structure that corresponds to my bootstrap environment
mircea_popescu: phf pretty sure that's the wrong version of it ? iirc there was also a keccak that didn't explode ? diana_coman ?
diana_coman: apparently vdiff is correct after all and there is this thing it sees - it just took me a bit to find it as I thought it was just a misplaced path rather than...the actual thing,huh
diana_coman: ha, wait, there actually IS a b/profiles/home/...
trinque: diana_coman: there oughta be a cuntoo/portage dir inside the build dir
diana_coman: fwiw a test file created there and vdiffed resulted in no such nonsense
a111: Logged on 2018-12-03 21:48 diana_coman: hm, if it's indeed the tmp thing, it might be worth a try to press vtools to current leaf (i.e. vtools_tempfile_standalone or _notmp) and see if that cures it; my archive contains pressed vtools to ksum patch only, not further
trinque: diana_coman: I'm running again with a vdiff pressed to http://btcbase.org/patches/vtools_ksum per http://btcbase.org/log/2018-12-03#1878057 ☝︎
mod6: <+asciilifeform> we also host owner-operated iron (e.g. dulap is still snsa ; and trinque has some, and mod6 ) << The Foundation's 2nd box ("lovelace") is with ben_vulpes, currently. He's going to find a home for it in his new area, last we had talked about it. I don't have any machines on-hand that are waiting to go to .uy. However, I might be interested in buying a UY1 style machine from alf...
trinque: thing is, my src directory is also a mount on my dev machine.
trinque: seems as though there's a dereferenced symlink munged into the path.
phf: there are three possible solutions, a) make sure that stack is arbitrarily large b) feed keccak buffers no larger than some magic size c) rewrite keccak to operate on char arrays directly without the need for bitstream allocation ☟︎
asciilifeform: i'm reluctant to do the massive rk thing until we have a semblance of working gnat for arm
asciilifeform: BingoBoingo: i'd ~really~ like to avoid the scenario where i go out with a half-empty crate
BingoBoingo: asciilifeform: It's march 10th, what is the window for a supply run looking like and what issues appear to be blocking?
diana_coman: mircea_popescu, yes, I don't suspect the code is broken as such but it is a limitation of the approach and I did not really expect bumping into it at 7MB
mircea_popescu: the whole "low stack by default" thing is a low level "let's stimulate heap usage", in the same exact way the empire of smegma would impose a high import tax on soap.
asciilifeform: i'ma detail, ftr : 'ffacalc' runs 'as fed', i.e. 1 command at a time. but 'peh' , adult version, has support for functions and loops, and therefore requires the 'tape' to exist in memory. so currently i have 'tape can be 1000000 bytes', but this is not acceptable obv. in the long term
diana_coman: mircea_popescu, this is a different machine, the cuntoo-guinea pig
diana_coman: asciilifeform, ftr this is a 4.7MB file
a111: Logged on 2018-10-20 01:44 asciilifeform: !Q later tell phf i found today that your keccak-vdiff is unable to eat a 40MB file ( dies politely with stack overflow )
a111: Logged on 2019-03-10 16:43 mircea_popescu: ie, that structured data should really be much better hardware supported, that memory should include much more processor per storage cell, that in fact memory should look a lot more like trees than the current flat, democratic lines of "all cells are equal"
asciilifeform: http://btcbase.org/log/2019-03-10#1901148 << imho the ( ~homogeneous~ variant of ) fpga is actually the correct model. i.e. you get to stitch it later into however many parallel mechanisms you happen to need on a given occasion. ☝︎
a111: Logged on 2019-03-10 16:42 mircea_popescu: asciilifeform thinking about whart you said, i can't repress the suspicion that maybe the memory model is acrtually profoundly fucked,as a central driver of the whole cs insanity.
mircea_popescu: make a 18446744073709551616 byte ram arm board, for the keks.
mircea_popescu: ie, that structured data should really be much better hardware supported, that memory should include much more processor per storage cell, that in fact memory should look a lot more like trees than the current flat, democratic lines of "all cells are equal" ☟︎
mircea_popescu: asciilifeform thinking about whart you said, i can't repress the suspicion that maybe the memory model is acrtually profoundly fucked,as a central driver of the whole cs insanity. ☟︎
asciilifeform: i dun expect to even live to see with own eyes a machine where 64bits of addr space fully populated (on current x64 Official standard, only 48 addr lines even connected, the rest mandatory 0)
a111: Logged on 2019-03-10 02:23 mircea_popescu: vp of motherfucking what, exactly ? "how to give away the market to the azns" ? that's a skill ?
a111: Logged on 2019-03-10 02:24 mircea_popescu: any fucking monkey picked out in the street could have made ~just as good~ a "corporate executive" as the fucktards apple hired -- and somehow nobody is telling them this. and of course the idiots don't have the werewithal to look in the mirror, "if plumbers were as good at plumbing as we are at executiving, we'd be quite literally swimming in the shit we're metaphorically drowning in!"
a111: Logged on 2019-03-10 03:04 mircea_popescu: i ~can't imagine~ what the fuck must have been going through the skull of whoever came up with "working a piece or moving the worked piece, same thing". what the fuck ever is it same thing!
asciilifeform: the thing with gigantic multers is that they grow physically with the cube of the bitness. hence scarce. ( tho i dun imagine even a 8192bit single-cycle multer would be remotely near as heavy as the 3bil-transistor 'let's fry eggs' pentium-xxviii or whatnot )
a111: Logged on 2019-03-10 03:02 mircea_popescu: but speaking of those design decisions, by my current thinking the ideal processor is defined as follows : the bus width is 512bits ; therefore the byte is 512bits. the processing core is a state machine, with 512 byte-sized registers. a processor is composed of 512 + 8*9 such cores. for convenience imagine them organized in a cube, 8x8x8, with an extra 64 item layer on three sides.
asciilifeform: think, where else are idjits gonna ~lease~ ( the new crapple thing! not even buy, lease.. ) a brick for its weight in gold
mircea_popescu: i ~can't imagine~ what the fuck must have been going through the skull of whoever came up with "working a piece or moving the worked piece, same thing". what the fuck ever is it same thing! ☟︎
mircea_popescu: but speaking of those design decisions, by my current thinking the ideal processor is defined as follows : the bus width is 512bits ; therefore the byte is 512bits. the processing core is a state machine, with 512 byte-sized registers. a processor is composed of 512 + 8*9 such cores. for convenience imagine them organized in a cube, 8x8x8, with an extra 64 item layer on three sides. ☟︎
mircea_popescu: but on a more optimistic note, that's probably the most anyone cared about anything to do with the topic or the persons named or otherwise referred to in their entire history. that should count for something.
a111: Logged on 2017-03-15 00:29 mircea_popescu: pretty fine example of exactly why warren was so vocal (item was strictly a barony created so elizabeth warren could be barron OF SOMETHING). this cfpb item spent 55mn on "renovations" of its hq, ie more than the gsa spent that year on everything the usg owns ; spent immensely on travel (which is not something they do). the chairman is supposed to not be removable by the president except "for cause" (meanwhile that got strick
mircea_popescu: this is the fucking problem of socialism, when that wanna-be alt-hilary stupid cow asks "if the government can print money to rescue wall street, why won't it print money to let the chitlins enjoy the college lifestyle free of charge (and permanently!)" she has a fucking point -- and the entirely similar stup ☝︎
mircea_popescu: any fucking monkey picked out in the street could have made ~just as good~ a "corporate executive" as the fucktards apple hired -- and somehow nobody is telling them this. and of course the idiots don't have the werewithal to look in the mirror, "if plumbers were as good at plumbing as we are at executiving, we'd be quite literally swimming in the shit we're metaphorically drowning in!" ☟︎
mircea_popescu: vp of motherfucking what, exactly ? "how to give away the market to the azns" ? that's a skill ? ☟︎
mircea_popescu: jobs' been dead what, a decade ? not even a decade. meanwhile, fifty FUCKING MORONS sat around in rooms pompously pretending as to how "of course i'm teh vp, didn';t you see the sign on the door ?"
a111: Logged on 2019-03-09 22:40 asciilifeform: when you build 1 of these things, there's a set of decisions that end up determining shape of whole thing; and it so happens that intel made ~all~ of the most retarded possible choices.
mircea_popescu: http://btcbase.org/log/2019-03-09#1901062 << very much this. "oh, couldn't POSSIBLY spare another bus width for a FULL mult result. NEVERTHELESS... can fucking spare eight trillion bus widths to specify instruction length. it's 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000101 and not a mere fucking 0000000000000000000000000000000000000000000000000 ☝︎
asciilifeform: remember, only a terrorist(tm)(r) 'writes own crypto', 'good citizens use openssl' etc etc
asciilifeform: ftr an 'iron ffa' cpu does not even require a massive multiplier . even a microcoded ffa-style thing that lets you specify 'and at memory x there is a w-word int, and at y a w word int, add'em' etc , would still massively win over the extant liquishit, it would do the arithm atomically, without invoking branchpredictor, losing cache, etc.
asciilifeform: fwiw it's still a 64bit mul, the only win is that it dun set any flags (and therefore keeps the pipe flowing)
asciilifeform: http://p.bvulpes.com/pastes/ncZvu/?raw=true << details, for anyone who gives a shit
asciilifeform: where yes it'll do a e.g. 512-bit add, but -- evidently -- using ~existing~ regs, and putting out same (or greater) amt of heat, and locking up the pipe
asciilifeform: in lulz inspired by bvt's article, asciilifeform went and dug re 'modern' cpu arithm instructions, and found https://lemire.me/blog/2018/04/19/by-how-much-does-avx-512-slow-down-your-cpu-a-first-experiment/ << intel's crud apparently ~drops frequency~ if you use'em , ultimately nuking all gains from doing so ( they want you to use, so as to shit out binaries that crash on amd, but really gains 0 )
a111: Logged on 2018-12-03 21:48 diana_coman: hm, if it's indeed the tmp thing, it might be worth a try to press vtools to current leaf (i.e. vtools_tempfile_standalone or _notmp) and see if that cures it; my archive contains pressed vtools to ksum patch only, not further
trinque: http://btcbase.org/log/2018-12-03#1878057 << I am currently running a build with a vdiff pressed to same. The only difference is that I have altered the gpr files to statically link. ☝︎
trinque: the paths ending up in your genesis vpatches are hard to blame on my script, rather than a difference between our vdiff executables.
asciilifeform: it is such a retarded design that even intel and microshit ~tried to escape~, in 1990s. but nsa decided that it ~likes~ x86 , and for it to remain cemented standard , on acct of http://www.loper-os.org/?p=1299 .
asciilifeform: when you build 1 of these things, there's a set of decisions that end up determining shape of whole thing; and it so happens that intel made ~all~ of the most retarded possible choices. ☟︎☟︎
asciilifeform: btw, bvt , rax etc. ~are~ encoded as 1-8, the iron dun see reg names at all, the classic names are a convention of the asmers and the vendor docs. and imho remains on acct of the asinine x86isms like MUL which use fixed input and output regs, makes'em slightly easier to remember. ☟︎
mircea_popescu: ftr, warlock has the stronger troops for large maps ; sorceress for medium. if you're looking for a shortcut to beating his ass.
asciilifeform: diana_coman: neato, i once spent half a summer in 'heroes 2' also
trinque: your asking did however send me on a spelunk through scripts/kconfig/conf.c by way of ./scripts/kconfig/Makefile
trinque: http://btcbase.org/log/2019-03-08#1900931 << it's actualy the opposite. kernel makefile found that .config lacked a value for a *new* key present in the trinque-supplied kernel, so asked for a value, suggesting default. ☝︎
a111: Logged on 2019-03-08 18:15 asciilifeform: why linus et al did not supply a ready-built http://btcbase.org/log/2019-03-08#1900938 util, remains a mystery to asciilifeform , just as he found it mystery in '90s
BingoBoingo: It's a gentoo liveusb, but yes it is seeming so
trinque: y'all are having hanbot work in a livecd?
mircea_popescu: which is JUST AS BROKEN BY DESIGN. ctrl-d will end a file AND kill a terminal, but not touch a task. ctrl-c will kill n levels of task depth, as in her example, FOUR. ☟︎
mircea_popescu: dude, this "x distance apart" is like the fucking speed bumps. brilliant fucking idea, "how about everyone pays a tax so that some edge cases benefit"
hanbot: i dunno, shit's supposed to fail if you do the wrong thing. possibly i'm a moron for making it too easy to do the wrong thing, keyboards oughta be 10ft apart, give second to surgical assistant, whatever. but it is fucking frustrating.
mircea_popescu: there's a difference between selecting for intelligent users and selecting for inept hoop jumping acrobatic users -- and "foss" managed to implement the 2nd kind while loudly making postureclaims as to everything under the sun.
hanbot: which means i have yet another incomplete cuntoo install with no vpatch and yet no way to start again without another freakin' reboot. it's like walking a tightrope, here i was worried the power'd go out or w/e, but no, fingers got confused after 30m of back and forth, fuck me.
hanbot: so there i am merrily entering choices into the kernel config's endless querying on the tail of my cuntoo installation attempt, and i'm noting down all the modules it asks about that don't appear in http://btcbase.org/log/2019-03-08#1900940 for posterity, during which i ctrl + c on the wrong of the two keyboards i'm handling while trying to copy a module name and bam, make dies, which means kernel configuring dies, which means bootstrap.sh dies, ☝︎☟︎
BingoBoingo: Well, when you put a third of your generation capacity in the same damn dam...
BingoBoingo: Venezolana today during spanish class logistics talk made of a point of how maduro was blaming the "Imperialists" for the blackout. I offered that it was almost certainly the imperialists, breaking shit is part of their regime change recipe.
asciilifeform: http://btcbase.org/log/2019-03-08#1900962 << near as i could tell, subj is a kind of http://btcbase.org/log/2017-08-03#1693150 , i.e. junkyard dog ☝︎☝︎
mircea_popescu: http://btcbase.org/log/2019-03-08#1900954 << seems quite evidently a case of "here in orc cvasirepublic, we rely on implicits to do the job where understanding wtf's going on would have been useful". ☝︎
mircea_popescu: most amusing element -- neither of the "parties" involved read as much as a line of ye olde menshevik-bolshevik disputes.
a111: Logged on 2019-03-08 18:05 asciilifeform: iirc trinque had an experimental proggy that takes a running kernel's lspci / lsmod output, and diddles an existing config so as to give a kernel that boots on $iron . but afaik not yet published.
asciilifeform: why linus et al did not supply a ready-built http://btcbase.org/log/2019-03-08#1900938 util, remains a mystery to asciilifeform , just as he found it mystery in '90s ☝︎☟︎
asciilifeform: since mircea_popescu is asleep, i'ma 'fill in' for him and note ftr that the necessity for this process is indeed a warcrime of the gnutards, and really not how sane configurator of any kind oughta work
hanbot: ty asciilifeform, will give it a whirl.
asciilifeform: iirc trinque had an experimental proggy that takes a running kernel's lspci / lsmod output, and diddles an existing config so as to give a kernel that boots on $iron . but afaik not yet published. ☟︎
asciilifeform: lobbes_field: imho it's an asinine default behaviour of linus's builder ; tho the alternative ( build a ball of ??? that fails to boot ) may be equally asinine
asciilifeform: 'found I could replicate mod6's process of copying the .config file in /usr/src/linux into the cuntoo/config directory' suggests that this build was using a non-trinqueian .config ?
asciilifeform: nao what i do not know, is how this scenario can play out using trinque's cuntoo kit -- iirc he includes both a particular kernel source and a config (for 1 of his irons) that was known to be edible by it
asciilifeform: hanbot: this also happens when you used a config baked for a certain kernel, but then feed it to another (usually moar recent) kernel's make
asciilifeform: hanbot: i can tell you ~what~ you saw, tho not yet why : the linux kernel make starts asking itemized config q's if it sees sumthing in the given config that dun add up to something 'menuconfig' could have shat out, by its lights ( e.g. a module for $device is enabled, but 1 of its deps aint )
BingoBoingo: Meanwhile local derps trying to statnerd over Uruguay being relatively expensive without a discussion of the Ham scam https://archive.is/DqocT
a111: Logged on 2019-03-06 23:12 mircea_popescu: well eg in lobbes 's case there's also an auction thing, and the archiving bit, and so on ; in spyked's case there's also a lot of rss and so on.
spyked: http://btcbase.org/log/2019-03-06#1900726 <-- incidentally, there is some overlap between logotron web interface and web-based img pastetron: both need www code, which I will genesis as soon as I have a working item ☝︎
asciilifeform: hanbot: it's a livecd, naturally regens host key erry time you revv it up
asciilifeform: buncha kids, mostly of local party elite, seekritly sewed themselves some semblance of ss uniform, and raised swastica flag at night on city hall; then marched to cemetery and laid half a tonne of flowers on old white army graves ☟︎