trinque: this kind of bitterness imho is of the "nose to spite face" variety.
nicoleci: (lower right corner) the transactions grouped the images from multiple articles on one or two pages
a111: Logged on 2017-07-06 15:09 mircea_popescu: which is how every god damned kid that was sexually abused through the process of socialist schooling (which is all of them -- education is education, and socialist school is definitionally sexual abuse of all children involved) ends up with the idea that newton sat down TO discover whatever he did (unimportant, really) and THEREFORE he did.
nicoleci: its been a pleasure transcribing them. really wish it was something they speak on in us schools, instead of trying to teach the periodic table by a song but w/e.
nicoleci: tbh all of the articles have been very interesting
nicoleci: asciilifeform, glad it finally came - i really enjoyed reading it. probably one of the more bizarre transactions
asciilifeform: wtf does the illustration have to do with it tho ? maybe mistake, and it is for adjacent section ?
asciilifeform: ^ i've been waiting for that 1 from the beginning!111
feedbot: http://bimbo.club/2019/03/philosophical-transactions-for-the-months-of-april-may-and-june-1716-part-iv/ << Bimbo.Club -- Philosophical Transactions. For the months of April, May and June, 1716. - Part IV.
asciilifeform: mircea_popescu: imho half of 'fits in head' is specifically ~refraining~ from gilding the lilies that dun need gilding.
a111: Logged on 2019-03-11 19:49 asciilifeform: so presently i cannot think of a scenario where i'd want to reopen the case of gcd.
asciilifeform: iirc the subj of the piece (the chinese 'empty chair' pantsuit nobel derp) finally bit it coupla yrs ago
mircea_popescu: spoke the words.
asciilifeform: cohen iirc was from day1 aligned with the wikitards & the rest of that gang of pseudo-republic people
mircea_popescu: there's of course http://trilema.com/2012/cine-se-casatoreste/#selection-61.94-61.383
mircea_popescu: the cohen dork, ~claimed it~. like rms or linus or hwatever other, "cypherpunks" / "internet freedom" blablabla. like the piratebay dorks, like zimmerman, and so on.
mircea_popescu: djb was just some manalone. perhaps more talented than most, but manalone is manalone, like a very talented chimp. howsoever talented, the chimp's not a person.
mircea_popescu: but these two cocksuckers ~never did anything~, they were lords like nubbins was one briefly.
mircea_popescu: one example that'd come close is that aurenheimer schmuck say, or the charlie shrimp.
mircea_popescu: that's the situation, djb never derped at length about republican values.
mircea_popescu: there's this pic of some indistinct slut i posted once i'm too lazy to retrieve. she happens to be white, sports all manner of celtic cross tattoos, stylisized "SS" etc, is taking a coupla brown dicks.
mircea_popescu: http://btcbase.org/log/2019-03-11#1901370 << not to discourage headloadings ; however ima try to get someone to do it by then.
asciilifeform: for the highlighting, i use mircea_popescu's js thing
asciilifeform: if the upstack note was unclear, btw -- you can do ~2500 4096b gcd's for the price of 1 4096b modexp.
asciilifeform: bvt: ty for the link tho, it confirms the (already yrs-long) suspicion that d00d's head is fulla maggots nao.
asciilifeform: so presently i cannot think of a scenario where i'd want to reopen the case of gcd.
a111: Logged on 2019-01-11 17:34 asciilifeform: whereas the gcd litmus ( gcd(candidate, primorial) ) costs 1ms .
asciilifeform: that being said, gcd is not the bottleneck of anyffin in ffa.
bvt: iirc the c-t version of algorithm comes later - around section 5. there is a formula for calculating upper bound of iterations, but I did not check his math.
asciilifeform: in re single-shot gcd, you either ~look at the bits~ , and that's lehmer's (not constant-time-able) method, or you do not, and that's stein's or the division-powered one, and i suspect it can be proven that yer stuck with quadratic runtime if you dun look at the bits.
asciilifeform expected to find that linked item is re ~mass~ gcd, in the sense of 'bernsteinization' used in phuctor. but apparently djb has nothing to add re ~that~
asciilifeform: and he's doing what appears to be the classic dividing variant of gcd, + newton's method . so idea is to... introduce floatism!? ( and the assoc. eggogs )
asciilifeform: bvt: from surface look, loox like lulzy piece, e.g. 'The algorithm is not constant-time as shown but can be made constant-time with low overhead'
bvt: also, i did not forgot about http://btcbase.org/log/2019-03-01#1899904 , but had too little time to investigate it properly; will try to do tests over this week and do a writeup on the weekend
bvt: asciilifeform: https://gcd.cr.yp.to/papers.html -- rather new constant time gcd from djb. i did not look at it closely so can't say if it's anything good or belong to the kunstkammer
a111: Logged on 2019-03-10 23:28 trinque: bvt: diana_coman: I wager that if you change line 14 of scripts/make_portage_tree.sh to the following, my sig will verify on the resulting genesis.vpatch : dest=$pdir/profiles/${src#$bdir/usr/portage/profiles/}
a111: Logged on 2019-03-10 21:39 trinque: scripts/make_portage_tree.sh << line 14, I do string-munging on the path that's specific to my own filesystem layout
lobbesbot: BingoBoingo: The operation succeeded.
asciilifeform: aside from that, protocol per se also has well-known problems (the reliance on 'trackers', and general ease of 'poisoning')
asciilifeform: http://btcbase.org/log/2019-03-11#1901354 << spyked - i was thinking, 'let's make torrent', then realized that torrent is some (afaik) largely unexplored heathenware, possibly due for a civilized replacement. might be worth expanding on if anyone has free hands.
a111: Logged on 2019-03-11 10:01 diana_coman: mircea_popescu, in short, the keccak spec in its current form really since it considers input at bit-level and then goes on to mess about with some assumptions at bit-level and some at octet-level and making a lot of confusion without any good reason e.g. http://ossasepia.com/2018/02/08/eucrypt-chapter-9-byte-order-and-bit-disorder-in-keccak/#selection-55.383-63.563 ; one needs to disentangle that and put it in octet-only shape, octet stre
a111: Logged on 2019-03-10 21:05 bvt: http://btcbase.org/log/2019-03-09#1901061 << iirc there were restriction on what regs can be used as base and index; another example of isa ugliness is MOV http://archive.is/w0IAC#selection-607.0-945.2
asciilifeform: http://btcbase.org/log/2019-03-10#1901308 << it's ALL! like this. the whole motherfucking x86 arch. where is there example of ~non~-ugliness, i'd like to learn.
diana_coman: http://btcbase.org/log/2019-03-06#1900648 -> ftr asciilifeform you were right here; it was a server dep (crystal space) that was bringing in the non-sjljistic libs
a111: Logged on 2019-03-10 23:28 trinque: bvt: diana_coman: I wager that if you change line 14 of scripts/make_portage_tree.sh to the following, my sig will verify on the resulting genesis.vpatch : dest=$pdir/profiles/${src#$bdir/usr/portage/profiles/}
diana_coman: am as input/output, with the reference implementation to check against
diana_coman: mircea_popescu, in short, the keccak spec in its current form really since it considers input at bit-level and then goes on to mess about with some assumptions at bit-level and some at octet-level and making a lot of confusion without any good reason e.g. http://ossasepia.com/2018/02/08/eucrypt-chapter-9-byte-order-and-bit-disorder-in-keccak/#selection-55.383-63.563 ; one needs to disentangle that and put it in octet-only shape, octet stre
a111: Logged on 2019-03-09 21:37 asciilifeform: spyked et al : http://nosuchlabs.com/pub/gutentext.tar.xz << mirror (replaced the old tarball)
spyked: http://btcbase.org/log/2019-03-09#1901047 <-- sounds reasonable; I've set it to redirect to a notice, at worst people will ask here if they're confused.
BingoBoingo: So in trends, the neon nazis shifted to memeing against Trump in favor of a candidate promising 1000 "dollars" a month
feedbot: http://trilema.com/2019/antiqua-sanctorum-patrum-or-the-lordship-list-sixth-year/ << Trilema -- Antiqua Sanctorum Patrum, or -- The Lordship list, sixth year.
trinque: bvt: diana_coman: I wager that if you change line 14 of scripts/make_portage_tree.sh to the following, my sig will verify on the resulting genesis.vpatch : dest=$pdir/profiles/${src#$bdir/usr/portage/profiles/}
trinque: scripts/make_portage_tree.sh << line 14, I do string-munging on the path that's specific to my own filesystem layout
mod6: I also have tar'd up the entire cuntoo build directory, but have not posted it. It's like 1.7G, but will send it somewhere if someone wants it.
mod6: I have also posted the entire typescript (47Mb WARNING) of the build to my website: http://www.mod6.net/cuntoo-blog-2/nomods.cuntoo.build.typescript
mod6: Is there anything else I can check for you while I have your ear?
mod6: Oh, sorry, I guess I wasn't excatly sure what you were asking me to look for, and where. I never had /dev/sdb mounted when I did the bootstrap.
mod6: I've looked at the genesis.vpatch that was genereated ( http://www.mod6.net/cuntoo-blog-2/nomods.genesis.vpatch ), and at first glance I don't see these files in their paths. (even if I remove the preceeding 'a/').
mod6: trinque: Ok, immediately I notice that in my /home/mod6/cuntoo/nomods/cuntoo working directory, from which I ran `./bootstrap.sh -k config/cuntoo-test1 -d /dev/sdb` there is currently nothing in the 'build' directory.
bvt: there are Import(Ada,...) and Import(Asm,...), which do the same thing according to the docs (http://archive.is/XEHW0#selection-17075.0-17109.171), and I did not manage to find any ABI docs with 'ada calling sequence'.
a111: Logged on 2019-03-10 02:44 mircea_popescu: http://bvt-trace.net/2019/03/ffa-chapter-9-homework-comba-in-x86_64-assembly/#selection-15.295-19.176 << why this, specifically ? is there no ada asm calling method besides this ?
bvt: http://btcbase.org/log/2019-03-10#1901101 << I decided against inline assembly because the asm source is quite large, it's inconvenient to have 100+ lines of asm inline with comments.
bvt: ('denver' is arm at frontend and vliw inside, dynamic jit tries to continuously improve translation: if you have a loop, the 1st, 100th and 1000th loop iterations can execute totally different vliw code)
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.
bvt: http://btcbase.org/log/2019-03-09#1901064 << well, IMO nvidia's "denver" managed to beat even them.
a111: Logged on 2019-03-09 22:35 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.
bvt: http://btcbase.org/log/2019-03-09#1901061 << iirc there were restriction on what regs can be used as base and index; another example of isa ugliness is MOV http://archive.is/w0IAC#selection-607.0-945.2
asciilifeform: mircea_popescu et al : there are no cstrings in ada, unless one explicitly bakes'em in order to throw to c linked liquishit. all arrays carry their bounds with'em.
mircea_popescu: the problem with any other datastruct, such as octets or words, is that you never know how large it is.
mircea_popescu: the ~problem~ with c-strings is that to know how loing it is you must look ~at the end~.
mircea_popescu: that you always know how large the field is.
diana_coman: mircea_popescu, what is the gain vs having as input octets or words?
diana_coman: so perhaps the text coding etc would help at chunking-file stage if needed but what is that to do with keccak
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
a111: Logged on 2019-03-10 19:44 phf: http://btcbase.org/log/2019-03-10#1901176 << i'll put it to the top of the stack, i remember fixing it, but never completing the patch.
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: 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.
diana_coman: mircea_popescu, from keccak's pov there is no meaning to the input so I don't quite see what you mean there
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
diana_coman: trinque, bvt put clearly what I was trying to say: here I have the same: the full directory structure inside /cuntoo/portage/profiles
a111: Logged on 2018-10-12 13:08 diana_coman: asciilifeform, hm, the bit version blows up buffers even more because it uses *internally* arrays of bits as per http://www.dianacoman.com/2018/02/01/eucrypt-chapter-8-bit-level-keccak-sponge/#selection-51.100-51.594
bvt: i.e. there is really directory structure /cuntoo/portage/profiles/root/cuntoo/build/...
diana_coman: mircea_popescu, that's at...another level
diana_coman: i.e. there isn't yet a bit-level keccak implemented, no
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: trinque, what should be in the portage/profiles dir?
diana_coman: ha, wait, there actually IS a b/profiles/home/...
trinque: right, this is what leads me to believe there's some vdiff bug to discover
diana_coman: cp -R portage would fail otherwise anyway
diana_coman: fwiw a test file created there and vdiffed resulted in no such nonsense
diana_coman: trinque, I'm trying here to even *see* this "profiles/" path in any other way than in the vpatch but so far no luck
mod6: Ok, I'm gonna shutdown the cuntoo box, and boot my original gentoo ssd (where I built cuntoo from). I'll see what I can find out from the genesis.vpatch thing.
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
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...
diana_coman: trinque, this is probably having to do with the drive being external, connected via USB and how it's mounted, I don't see any other explanation
diana_coman: trinque, that's weird; fwiw: no, my home dir as far as I can see is *not* in the profiles directory
phf: ksum right now works for any sized file, because it goes the b) route: http://btcbase.org/patches/vtools_tempfile_standalone_notmp/tree/vtools/src/ksum.adb#L12
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
phf: buffer needs to be converted to 8x bitstream, which is in turn allocated on the stack
a111: Logged on 2019-03-10 18:09 asciilifeform: mircea_popescu: ideally, mmap the inputs
phf: http://btcbase.org/log/2019-03-10#1901200 << that is not at all the problem. i can read the file just fine, but as i do i feed chunks of it to keccak. keccak doesn't take char buffers, it wants "bitstream" i.e. arrays of bits, which means whatever char
trinque: you'll notice it thinks your home dir is sitting in the profiles dir, which is mighty strange! maybe it is?
trinque: diana_coman: http://p.bvulpes.com/pastes/rWreS/?raw=true << here's the diff of your genesis and mine again
phf: rather not array of octets, but array of bits
phf: the problem is that our ada keccak explodes whatever char buffer it gets into an array of octets, which means that, while diff keeps the size of chunks under some particular value, keccak explodes that value x8
BingoBoingo: <mircea_popescu> true enough. nevertheless, in my view owning iron helps give pizarro some meat on its bones. << That it does
phf: http://btcbase.org/log/2019-03-10#1901176 << i'll put it to the top of the stack, i remember fixing it, but never completing the patch.
mircea_popescu: true enough. nevertheless, in my view owning iron helps give pizarro some meat on its bones.
asciilifeform: ^ this goes for other folx! bring out thy irons.
mircea_popescu: i don't really, and besides my/our policy has mostly been to have pizarro own iron, hence the snsa sale etc.
asciilifeform: i'm reluctant to do the massive rk thing until we have a semblance of working gnat for arm
asciilifeform: mircea_popescu: possibly you have an iron that wants to go in the crate ?
asciilifeform: BingoBoingo: i'd ~really~ like to avoid the scenario where i go out with a half-empty crate
BingoBoingo: asciilifeform: Aite. We don't do these very often yet, so getting things in hand trumps getting plane ticket arranged.
asciilifeform: BingoBoingo: currently hands full restarting ffa conveyor; however will be ordering irons in next 2 wks, and scheduling flight when the items with least predictable shipment windows are in hand
BingoBoingo: asciilifeform: It's march 10th, what is the window for a supply run looking like and what issues appear to be blocking?
asciilifeform: ^ the various drafts of this item
asciilifeform: mircea_popescu: kernel ( linus's , that is ) -- exposes. the tricky bit was/is the ada glue.
mircea_popescu: asciilifeform imo it is the job of the kernel to expose all available memory (ram, and fucking hell, disk, too, ALL available memory) to me as i fucking want it : stack, cpu registers, heap, whatever it is i wanna call it.
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
asciilifeform: mircea_popescu: ideally, mmap the inputs
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.
mircea_popescu: diana_coman see, if it is broken code, then it just eats all stack available. but i suspect here code is sound, demand on stack defensibly large.
asciilifeform: tho not neccessarily required, in vdiff, the process as i understand it does not actually demand random access to the entire input
asciilifeform: mmap is the obv. logical method to handle multi-MB inputs for e.g. vdiff , without introducing heapisms
asciilifeform wonders if phf hung on waiting for asciilifeform to fix the mmap lib
asciilifeform: so it will have to have the mmap routine.
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
asciilifeform: diana_coman: the 'errything on stack' approach has its limits; it is why i wrote the mmap thing (currently stuck in limbo , but i'ma have to revive it and fix, cuz ffa 17 also is hitting against this wall, you can't expect to put 100MB on stack, you gotta mmap it
asciilifeform: diana_coman: i think he's trapped in some sorta cube hell; the squarebracket thing mircea_popescu asked for also not happened yet etc
lobbesbot: asciilifeform: The operation succeeded.
a111: Logged on 2019-03-01 08:57 phf: asciilifeform: give me until end of march to resolve it one way or another, feel free to neg rate me then
diana_coman: (i.e. it runs, it returns fine, no differences between the files)
diana_coman: mircea_popescu, this is a different machine, the cuntoo-guinea pig
mircea_popescu: diana_coman try it with the megastack size from before, calling tests ?
asciilifeform: diana_coman: i do not presently know where is the barf threshold, i suspect it depends on yer stack size
asciilifeform: phf promised to fix, but then went on his ill-fated voyage
asciilifeform: ( the style of programming that would appear on ' asciilifeform's ideal cpu ' is best illustrated in http://btcbase.org/patches/fg-genesis/tree/fg.v . i.e. all of the independent pieces in fact run in parallel, and in deterministic time, there are no interrupts, no scheduler, etc. )
diana_coman: mircea_popescu, yes, vdiff on the 2 genesis.vpatch files overflows the stack; while on same machine and same files, diff seems to have no such trouble
asciilifeform: http://btcbase.org/log/2019-03-10#1901140 << the down side of 'let's 512b bus' is that most cpu time (where it runs, not counting idles on i/o here) is spent in 'inner loops' where yer counting to e.g. 3. and nao you gotta move 512bits when yer counting to... 3
a111: Logged on 2019-03-10 17:02 mircea_popescu: perhaps the correct republican approach is not to bake cpu, but to ~bake memory~. why even bother with the whole turdpile that's ddr init when could simply have sane ram, and rk with it.
asciilifeform: http://btcbase.org/log/2019-03-10#1901153 << bake 'pile of reconnectable flipflop' and then you aint gotta ever bake anyffin else again. iirc i detailed this in ancient thread, mircea_popescu barfed ( iirc answered 'why waste so many transistor on interconnects' ) , but can't currently dig up where we had this
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.
asciilifeform: http://btcbase.org/log/2019-03-10#1901147 << it indeed is, and in precisely the way described.
mircea_popescu: make a 18446744073709551616 byte ram arm board, for the keks.
a111: Logged on 2018-09-25 00:39 asciilifeform: the only binball is that coupla kB of ddr ram init thing.
mircea_popescu: perhaps the correct republican approach is not to bake cpu, but to ~bake memory~. why even bother with the whole turdpile that's ddr init when could simply have sane ram, and rk with it.
mircea_popescu: http://btcbase.org/log/2019-03-10#1901145 << say this again ?! vdiff blows the stack when processing the two diffs ?
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.
diana_coman: trinque, which are exactly the paths that don't match? since I don't have the original genesis.vpatch I can't really know what to check to look if indeed those paths actually exists or not or wtf
a111: Logged on 2019-03-09 22:43 trinque: diana_coman, other folks that have cuntooed, can y'all confirm that the paths that ended up in your genesis.vpatch do not in fact exist? I'd like you to reproduce the commands starting at line 114 of scripts/make_portage_tree.sh in your build directories, i.e. cd ~/src/cuntoo/build/cuntoo and then run them, as root
diana_coman: http://btcbase.org/log/2019-03-09#1901066 -> I ran those and I got exactly the same genesis.vpatch (i.e. diff on this vs the one obtained from the script itself returned empty)
mircea_popescu: o right the registers. i recall.
asciilifeform bbl, maffs then meat
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)
asciilifeform: ( at current or even hypothetical magic '1 atom per' density )
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 ?
asciilifeform: http://btcbase.org/log/2019-03-10#1901094 << with or without crapple, asia laffs allthewaytothebank -- it aint as if crapple bricks are made somewhere other than shenzhen
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!"
asciilifeform: http://btcbase.org/log/2019-03-10#1901095 << rando monkey from the zoo would make 9000x better director than the catamite d00d ( recall, what he was in charge of prev. : rounding the corners on the 'ui'.. )
asciilifeform: aaaanyfffing but get rid of the idjit von neumann bottleneck and bake micro-cpus into the ram
asciilifeform: so they 'let's find sumthing to do'.
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: http://btcbase.org/log/2019-03-10#1901108 << pipelineism, branchpredictionism, etc., all these heresies, were birthed from the fact that speed of memory fell massively behind that of cpu, in the time it takes to fetch ~anything~ you can do five digits of clock cycle
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: the 64 "flat outer" cores are state machines that can do mvin and mvout -- taking registers to memory or memory to registers, ie use the bus. only, of course, for the state machines inside their ~projection~.
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: he's on ch9, where no barrett, ~80% of the cpu eaten by knuthian div.
asciilifeform: think, where else are idjits gonna ~lease~ ( the new crapple thing! not even buy, lease.. ) a brick for its weight in gold
a111: Logged on 2019-03-10 02:22 mircea_popescu: http://btcbase.org/log/2019-03-09#1901064 << in quite related news : went to flagship mall in this country, escazu multiplaza (escazu being where the us embassy compound lies, and all the retarded gringos live, very miami real estate racket reservation), and guess what ? there's no ipad store. AT ALL. instead, huawei dominates both in advertising (these large floating banners) and location (top floor store, only one to sell c
asciilifeform: http://btcbase.org/log/2019-03-10#1901090 << i was convinced somehow that crapple stores exist only in the reich
a111: Logged on 2019-03-10 02:44 mircea_popescu: http://bvt-trace.net/2019/03/ffa-chapter-9-homework-comba-in-x86_64-assembly/#selection-15.295-19.176 << why this, specifically ? is there no ada asm calling method besides this ?
asciilifeform: http://btcbase.org/log/2019-03-10#1901101 << recall, ave1 found that the asm inlining was ~yet another~ item partially broken in ye olde gnat ( iirc it dun let you assign registers deterministically )
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: the remainder 8 "sharp outer" cores control the flats, by moving things in and out of ~their~ registers.
mircea_popescu: the 64 "flat outer" cores are state machines that can do mvin and mvout -- taking registers to memory or memory to registers, ie use the bus. only, of course, for the state machines inside their ~projection~.
mircea_popescu: the 512 "central" cores are state machines that can do add or mul, and always proceed ~on their entire register set~. so if you don't want to multiply 131072-bit numbers, just put in zeros ; and if you put larger numbers in there you'll just get the LAST 262144 bits of the result, is all.
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: http://bvt-trace.net/2019/03/ffa-chapter-9-homework-comba-in-x86_64-assembly/#selection-15.295-19.176 << why this, specifically ? is there no ada asm calling method besides this ?
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.
mircea_popescu: id cow "from twitter" explaining @whatever conference "how serious they take banning" blinks incomprehendingly just as she's done with her soundbytes. yeah, why is it ??? there's entirely no difference between any of them and any other aspiring-writers-in-new-york, philosophy of art history studies rejects the world over. why those, why not these ? blink blink ?
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#1901064 << in quite related news : went to flagship mall in this country, escazu multiplaza (escazu being where the us embassy compound lies, and all the retarded gringos live, very miami real estate racket reservation), and guess what ? there's no ipad store. AT ALL. instead, huawei dominates both in advertising (these large floating banners) and location (top floor store, only one to sell c
a111: Logged on 2019-03-09 22:38 asciilifeform: if you ever wonder why your x64 iron draws 50x the wattage to do same thing as e.g. rk, wonder no longer -- the insanity where shit gets moved around to accomodate idjit instructions with fixed in/out hoppers, the insanity where you gotta set prefixes to specify what width ~each operand~ is (why this is needed ? srsly) , all of this adds up to 3bil transistors that heat the room
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: but no prizes for guessing why it aint on the market.
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: ... so 'mulx' aint in anyffing i have. if someone wants to test it with own hands, he can, otherwise fughetit.
asciilifeform: and meanwhile2, we have answr to above quandary, 'In 2017, BMI2 was further incorporated in AMD's Zen-architecture...'
asciilifeform: ftr asciilifeform suspects that 99% of what can be won from asmism in ffa, can be had simply from bvt's existing 64bit mul, plus doing adc for the additions-with-carry instead of the manually-cranked carry calc, and that all 'fancy' instructions will only lead to sad
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: bvt: the only new instrs that seem to be even theoretically of use, are 'mulx' and 'adcx' -- but i dun have any iron that supports these atm, and cannot even begin to say whether constant time etc
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: i.e. they can't stuff any moar transistors in there, and end up offering the equiv. of ye olde 'winmodem'
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 remainder of work here is resolving this issue (I have not had) with paths, after which we can start producing ebuilds for novel republican work atop the genesis.
trinque: the paths ending up in your genesis vpatches are hard to blame on my script, rather than a difference between our vdiff executables.
trinque: diana_coman, other folks that have cuntooed, can y'all confirm that the paths that ended up in your genesis.vpatch do not in fact exist? I'd like you to reproduce the commands starting at line 114 of scripts/make_portage_tree.sh in your build directories, i.e. cd ~/src/cuntoo/build/cuntoo and then run them, as root
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: ( and this is not even touching the subj of the tlb cache, which is ~1/3 to half of those transistors , which we have on acct of the idjit paging scheme )
asciilifeform: if you ever wonder why your x64 iron draws 50x the wattage to do same thing as e.g. rk, wonder no longer -- the insanity where shit gets moved around to accomodate idjit instructions with fixed in/out hoppers, the insanity where you gotta set prefixes to specify what width ~each operand~ is (why this is needed ? srsly) , all of this adds up to 3bil transistors that heat the room
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.
asciilifeform played it with brother
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.
lobbesbot: asciilifeform: The operation succeeded.
asciilifeform: spyked et al : http://nosuchlabs.com/pub/gutentext.tar.xz << mirror (replaced the old tarball)
a111: Logged on 2019-02-07 19:12 asciilifeform: diana_coman: np. lemme know which flavours the kid ended up liking, i may have moar in the depths of the warez chests along those lines.
asciilifeform: ( why ? asciilifeform , for instance, sometimes gotta switch gnats , and the emacsen dun see it )
asciilifeform: meanwhile, in unixtardation : apparently there is no known way to change PATH envir. var. for ~running~ processes globally
spyked: asciilifeform, I applied mircea_popescu's pill to block spam-linkers. pl0x to set referrer to http://thetarpit.org or http://lucian.mogosanu.ro
feedbot: http://thetarpit.org/posts/y05/088-gutenberg-iv.html << The Tar Pit -- Gutenberg ASCII archive updated, now with 0.5% less junk
trinque: asciilifeform: that gentoo-specific patchset question is because these patches are present in "gentoo sources"
lobbesbot: BingoBoingo: The operation succeeded.
a111: Logged on 2019-03-08 18:01 asciilifeform: hanbot: that answers it then. that one contains some flag that trinque's kernel has nfi what to do with.
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.
BingoBoingo: Eh, I'm still up. Will put the shoes back on and remember to open the terminal before I take shoes off text walk
BingoBoingo: hanbot: Is it alright if the reboot waits until morning?