mircea_popescu: but this would remove the inband-ness
phf: the reason why we have issues with +++ and --- is because vdiff specifically ignores the @ ... @ bits when postprocessing a patch. a complete vdiff-er wouldn't have to do that kind of post processing and can produce a valid patch always
phf: +++ --- is there not for content parsing, but for allowing an arbitrary prelude (that is for including patches in email)
phf: i'm not sure this is necessary, patch already contains line count information in the @ ... @ part
a111: Logged on 2017-12-14 19:55 mircea_popescu: you ~could have a diff format whereby first line is x y z with x = total line count, y notation line count z data line count, and then instead of +++ --- bs you just have line count references in the notation part.
mod6: ben_vulpes: also, patch will not even create those output directories for the build process if the dir doesn't contain at least 1 file. it simply ignores them.
asciilifeform: and just text, and subject to diffing like any other text.
asciilifeform: imho this is the troo cut
mircea_popescu: asciilifeform you don't specifically need a manifest, as per discussion (have you been reading the discussion ?) ; can just follow the hashes.
asciilifeform: ( trb-genesis, for better or worse, was a plain cut of the original material. ended up preserving the idiocy of empty file. )
ben_vulpes: if i recall correctly, the empty files are necessary to hold the output of trbs compilation process
asciilifeform: i dunno that the addition of a knob to divorce from the idiocy of unixpathism , is really escapable
asciilifeform: and does away with the horror chamber of 'i moved a file, where did the 10 MB of crud come from'
asciilifeform: incidentally mircea_popescu , phf , consider a particular cut : suppose that ( otherwise unchanged ) diff format did not mention paths at all, only hashes. and there is a separate section, 'manifest', that is table of hashes to paths. during press, the latter is eaten and traditional unix dir appears.
asciilifeform: the tragicomic part is that i picked plain old diff for vtronics 'so that patches will be readable'
asciilifeform: it's a pathetically dumb state machine.
a111: Logged on 2017-12-14 21:16 mircea_popescu: but this is why this discussion was so important : it has in fact emerged that the correct implementation of diff would first a) calculate hash of all files in each dir ; then b) process moves and only then c) do the diffing.
asciilifeform: http://btcbase.org/log/2017-12-14#1751725 << the retardation of unixdiff is unfortunately not limited to file moves. it also has no ability to represent , e.g., sections of a file moving ( iirc this came up during the original genesis thread )
shinohai: Why even bother with Bitcoin
phf: to put lisp commands that need to be run after the source has been pressed to the current patche's state.)
phf: (fwiw so far i've been using patches prelude to stuff metainformation there. one interesting property of patching an already pressed lisp system, is that you don't want a clean press. instead you want to find what state your system is, and then press it further down the chain. but because you don't want to restart the system likewise, you want some additional actions performed as you're moving down the press chain. so i've been using prelude as a place
asciilifeform: you could in phf's unified-namespace thing, but i dun see how else otherwise
mircea_popescu: we evidently also ~could~ add filename to the hash. but i dun wanna.
a111: Logged on 2017-11-14 22:08 asciilifeform must invoke herr babbage, 'i cannot rightfully apprehend the confusion of ideas...'
mircea_popescu: tbh i don't even understand why the machine permits such insanity. an empty file is very much a http://btcbase.org/log/2017-11-14#1738478 trigger
mircea_popescu: if you put empty files in your project i will personally chase you down in the afterlife.
mircea_popescu: phf no such thing as empty lines. put a fucking comment in there.
mircea_popescu: anywya, this system'd be purrfect : if hash unchanged, "this is THE SAME file by a different name (or path, same thing" ; if hash changed "this is DIFFERENT FILE by same name"
phf: not restricted to moves by the way, there's also copy. there's a certain symmetry lost though. if you say make a genesis with 3 empty files a b c, then they are fresh line patches. but the patch against that that creates another 3 empty files puts cp a x; cp a y; cp a z; in the prelude instead
mircea_popescu: but this is why this discussion was so important : it has in fact emerged that the correct implementation of diff would first a) calculate hash of all files in each dir ; then b) process moves and only then c) do the diffing.
mircea_popescu: phf because it's the logical way for it to work
mircea_popescu: hence the keccak instead of curent whatever it is.
phf: (that was by the way how btcbase patcher worked for a long time, until i had to modify it because there are placeholder items in bitcoin source code that are at different filepaths)
mircea_popescu: it's why we have them
mircea_popescu: this'd require all file movements to be a separate patch, as you can't both move and edit in the same go. which imo is bonus the right thing
phf: say you have /a/foo and you have /a/bar/foo where both foo are identical. you're running diff -ruN a b, what is the expected behavior?
mircea_popescu: if you have a : a/b a/c and b : b/b b/d/c it is thereby evident upon diffing a and b that c was moved from a/ to b/d/ if a/c contents === b/d/c contents.
mircea_popescu: i dun get what the problem is.
phf: diff can't know if the newly appeared item that's identical to an item that exists elsewhere in previous state has been moved there from the elsewhere or created in situ
mircea_popescu: then WHY!!!! can't i use it to move files!!11
mircea_popescu: when i say diff a/foo b/foo, diff fails to output "one is in a, the other in b" as the first fucking item on its list of differences. this is because the (idiots) that made diff thought they gain something by eliding "the trivial case".
phf: there's no way of knowing without having a complete history of states whether or not foo was moved or removed
mircea_popescu: "the difference between a/fuckyoustallman.c and b/fuckyoustallman.c is 1) that one's in a and the other in b ; 2) no further"
mircea_popescu: but it can know that it's not in the same directory.
mircea_popescu: if i edit glib.c and replace line 50 with "fuck you stallman", and then try to compile glib.c, i get an error. if i edit glib.c and MOVE glib.c to /fuck/you/stallman/glib.c, and try to compile glib.c, i get an error
phf: sure, but diff's way of indicating change is to show what happened to a file, that is all the lines of the file got deleted
mircea_popescu: the FILE has changed.
phf: well, moving of the file is a filesystem operation, what does it have to do with ~diffing~?
phf: diff/patch allows for absolute paths, we don't them it though
mircea_popescu: but whatever, in 1970 people couldn't afford disks with actual directory structure in them
mircea_popescu: the fact that unix diff is directory blind is an idiocy larger than commonly encountered in that thing's misdesign
phf: but anyway, i'm not convinced that file management is a proper concern for diff. we could add it to a diff format, by placing some instructions in the prelude (which is normally ignored by unix patchers). rm src/foo.c, mv src/foo.c src/bar.c which can be used as instructions for reader with non compliant patchers, or parsed by the vpatcher to be executed. this is all incredibly inband, but conforms to the medium
phf: btw one of the reasons for dodgy delete function in the diff is that patches theoretically a reversible, -'ing all the lines of file can conversely be +'d back
phf: actually phf-shiva-swank is still broken in the experimental patchset, because it was produced by vdiff/patch combination (vdiff made some claims of shasums, which patch didn't verify. the fact that i should've verified the press is a different question)
phf: in this case the value of proper vpatch/vdiff is that they never produce fuzzy patches and always validate the shasum for you, but they don't do the v-tronic management
phf: well, this goes back to the threads about whether or not it makes sense to patch sigs on your workbench. i use patch in my workflow frequently outside of pressing a tree to bring things from one state into another. i might have a dozen of unsigned patches, that i'm working with that won't see the light of day
mircea_popescu: isn't the latter actually ideal, protocol wise ?
phf: i don't think that's a good idea, but i can't articulate an objection. vpatch now needs to know about your wot and wot management, or else the process of patching now becomes explicitly providing a pub key, a corresponding sig and a vpatch itself.
mircea_popescu: not produce them
mircea_popescu: how can they sig for you
phf: from that perspective both vdiff and vpatch ~could~ also produce a corresponding sig, in which case the protocol is that patch/diff produce an always valid vpatch (i.e. vpatch/sig combination)
mircea_popescu: can you imagine any other context besides pressing this new diff/patch would be used in ?
mircea_popescu: so basically keep them modular ?
phf: in my thinking vtroner is a larger beast, that's responsible for the management of the entire press chain. patch/diff are dealing with a specific problem of comparing two states, producing a difference of those two tays, and then taking a state into a next state according to differences
mircea_popescu: in principle we could do incremental builds ; but only if they can be cleanly upgraded later, that's a major point.
phf: this then is entirely unscoped
phf: mpi is a fraction of what gnupg is, are we then moving away from pgp keys and signatures?
mircea_popescu: and why would diff/patch be outside of vtroner is the larger design question
mircea_popescu: the whole idea is to eg import keccak from eucrypt
phf: chain validation needs to only go as far as "does the hash on the file that i'm about to patch corresponds to what i expect"
phf: well, signature validation is done by gnupg, i don't see any reason to bring that whole thing in, and there's very little reason to system("gnupg ...")
phf: take existing stuff, strip it down to just what we already have -ruN functionality. i think that the actual tools should be vdiff and vpatch, that is they do shasuming themselves and produce proper vpatches/apply proper vpatches, but without chain or signature validation.
phf: http://btcbase.org/log/2017-12-14#1751602 << i have some ideas of the first steps, that is i can make backwards compatible vpatched diff/patch
asciilifeform: maybeshakespeare, maybeanothermanbysamename
a111: Logged on 2017-01-03 21:14 mircea_popescu: v is really only as powerful as the underlying differ is.
mircea_popescu: you ~could have a diff format whereby first line is x y z with x = total line count, y notation line count z data line count, and then instead of +++ --- bs you just have line count references in the notation part.
mircea_popescu: maybe he bites the bullet and makes special files. or who the hell knows. i'm curious.
mircea_popescu: i'm letting him contribute, what. he understands what the problems are.
mircea_popescu: kinda open matter yet ; but procedurally one takes the diff source code, genesises it, patches the differences and produces a drop-in diff replacement.
asciilifeform: mircea_popescu: consider making a spec for the One Troo Diff ?
a111: Logged on 2017-12-14 19:22 mircea_popescu: that could've meant tmsr-diff. what it means practically is that there's going to be a "new" mpi in eucrypt, textually identical to the genesis one ; and people will be re-reading and re-reading and RE-READING whole lots of the same exact code as if new, resulting in a situation where instead of the problem being pushed into "a filesystem hierarchy standard" it'll be pushed into a "code standard". which happens to be exactly
asciilifeform: incidentally if mircea_popescu wanted to go 'whole hog' re http://btcbase.org/log/2017-12-14#1751589 , could even throw out asciilifeform's mpi and make new one from the source material. see if it ends up same, possibly find new cuts.
asciilifeform: mechanical tools can make the job slightly smaller, or - when they're rubbish - slightly larger. but it remains.
mircea_popescu: contrary to naive intuition, there is no damage in re-reading old code as if it were new.
asciilifeform: if mircea_popescu decides to have the eulora programmers not only copy the thing verbatim, as if v never existed, but to retype it, and whack'em with a stick for each mistyped letter, who am i to object . it's his proggy.
mircea_popescu: over time it'll actually get systematized, as in the aaerne-thompson system for folk takes, or as in the tmsr-diff here. but that day is far into teh future.
mircea_popescu: like how oral culture worked, the concept of a trope, as found in folk tales, is really simply equivalent to "and this is how mpi goes, and this is how bubblesort goes..." and so on.
mircea_popescu: that could've meant tmsr-diff. what it means practically is that there's going to be a "new" mpi in eucrypt, textually identical to the genesis one ; and people will be re-reading and re-reading and RE-READING whole lots of the same exact code as if new, resulting in a situation where instead of the problem being pushed into "a filesystem hierarchy standard" it'll be pushed into a "code standard". which happens to be exactly
mircea_popescu: yes we don't have a gns yet, but this doesn't excuse us from... doing the same computations by hand as if we had it! it's not suddenly allowable to go "well since i have no running water i therefore do not wash". no bitch -- since you have no running water, you walk fifty miles uphil each way to GET water in a bucket. still wash.
a111: Logged on 2017-12-14 16:13 phf: rs~ might a little bit more meaning out of the press namespace. one pill to satisfy later group of people would be to come up with a filesystem hierarchy standard, i.e. you always press at the same root, but you're pressing into a tmsr namespace. so it'll be /bin/bitcoin/... /lib/mpi/...
mircea_popescu: http://btcbase.org/log/2017-12-14#1751486 << i considered this. it's not evidently broken, but i think it subtly is broken, and the principal cause of the failure of the unix actually -- a failure to correctly handle namespaces.
mircea_popescu: so now that problem is solved ; go do something else, there shall be no more of this.
mircea_popescu: the world's not some sort of wide open grazing range where we can just randomly produce useless nonsense.
mircea_popescu: this is me opting out. now go read thefucking logs ; copy BY HAND on a notebook what you did wrong, in fucking gothic longhand, a dozen times, and get it in your thick skull.
mircea_popescu: and it's not the first time ; it's the fucking third. every time she tried to get some sort of support from you, you acted the retarded usarmy desk flier, cost her 10x the time it'd have taken if she were camping in the desert.
a111: Logged on 2017-12-05 15:11 asciilifeform: and in general i dun expect any of it to be paid for, there is no tradition of any such thing. but i do have the possibly naive expectation of the work not to be shat on.
a111: Logged on 2017-12-14 15:51 asciilifeform: phf: given example works with my vtron, oughta equally work with mod6's. and does the job (both from vtronic genealogy pov, and gnumake's -- the latter (see the makefile of my faux 'eucrypt') recurses updir ) the 1 down-side is aesthetics.
mircea_popescu: http://btcbase.org/log/2017-12-14#1751463 << it does exactly one fucking job. this one : diana_coman please don't talk to asciilifeform or take any further advice from him. total timewaste.
mircea_popescu: mpi is a SUB. and if it can't act the sub part it's getting cut out with hot irons and the ground where it stood salted.
mircea_popescu: there is that.
a111: Logged on 2017-12-07 16:52 mircea_popescu: so then why can't she simply move the mpi/ dir into eucrypt/mpi/ and proceed ?
mircea_popescu: the correct time to not understand it was LAST fuycking week, when http://btcbase.org/log/2017-12-07#1748152
a111: Logged on 2017-12-14 15:38 asciilifeform: the 1 thing i still don't fully understand is why diana_coman's subdir gotta move
mircea_popescu: http://btcbase.org/log/2017-12-14#1751446 << VERY late in the game to "not understand" this.
mircea_popescu: that's also why poor people, stupid people (but i repeat myself) and socialists, "democrats", pantsuits etc are so fucking unfunny. too hope-y, or rather, their intellects are too dysfunctional to handle contradiction, of whatever kind.
mircea_popescu: (humor necessarily feeds of contradiction of expectations ; hope is always and no matter how disguised continuation of expectation. the contradiction between the two is absolute and a matter of definition.)
a111: Logged on 2017-12-14 13:49 shinohai: But the concept of a UBI is hilarious period.
mircea_popescu: http://btcbase.org/log/2017-12-14#1751431 << nah. there's a straight relationship between humour and hope : anything thats hopeable is not humorous and vice-versa.
BingoBoingo first 3 days heard it as "Bom dia" though they adopted portuguese greeting from Brasil.
ben_vulpes: mike_c, the republic's mole in IAC
ben_vulpes: apparently mike_c's new gig has now banned messages to girls from users they haven't "liked" yet
asciilifeform: ( and the supposed converter boxes, dun work worth a shit. ) but iirc i already mentioned this.
asciilifeform: ( connection left as exercise for the reader. )
asciilifeform: possibly i can guess what ben_vulpes wanted... answr is, there is 0 ionospheric propagation at any of the spectrum the cheapo rtl dongle is able to pick up.
a111: Logged on 2017-12-14 05:08 ben_vulpes: canvassing the low bandwidth radio space
phf: err, yes, i was going to say slackware, but they are sloppier than bsd
phf: it is to some extent a bsd model (that slackless os also follows it), where you have baseline system, where the source is owned by a cabal of maintainers/developers
asciilifeform: this also makes the vtronic-linux a moar tenable, imho, proposition.
asciilifeform: also oughta satisfy mircea_popescu's 'there was 1 genesis' item. because under phf's unification, there in fact ~was~ , created an empty universe with a 'bitcoin' dir.
asciilifeform: it very much seems to me, to be The Right Thing.
asciilifeform: phf: how inside ? they're sibling dirs
phf: actually, i think fg is the only exception
asciilifeform: iirc all of the v-releases, to date, are already dir-siblings in phf's hypothetical tmsr-rootdir.
asciilifeform: i happen to see the entire unix directory scheme as idiocy
phf: rs~ might a little bit more meaning out of the press namespace. one pill to satisfy later group of people would be to come up with a filesystem hierarchy standard, i.e. you always press at the same root, but you're pressing into a tmsr namespace. so it'll be /bin/bitcoin/... /lib/mpi/...
phf: well, the nature of v is that you're pressing into a global namespace. in fact that was a property of the original idea to a great extent (hence mp and his insistence on there being only one genesis). we compromised that already by having multiple projects, but you still run into the same issue when you're trying to combine multiple projects together. you're basically saying that the press namespace doesn't matter as long as there's no collision. ~othe
asciilifeform: ( both demonstrated in the example. )
asciilifeform: though i'll admit that i personally dun get the fixation with moving mpi to being a subdir of $newproj.
asciilifeform: phf: sad indeed, and afaik unfixable without sending gnupatch/gnudiff to where they belong -- into the oven.
asciilifeform: i'ma leave it for diana_coman , mod6 , phf , mircea_popescu , et al, to consider which pill is less barfatronic, and possibly conceive of another.
phf: i didn't necessarily need the illustration, because i understood what you were saying, my point was merely that it's sad state of things
mod6: sure, thanks for posting the sample for diana_coman
asciilifeform: at any rate it oughta be obvious what the illustration does simply from naked eye reading.
asciilifeform: mod6: i dun like to uncase the launch codes 10,000,000 times per day every time test press. but others are moar than welcome to.
asciilifeform: imho the item i posted just nao, illustrates the cleaner method. but it has down-side in that one has to give up on 'i get to decide exactly what the unix dir structure will look like, notwithstanding the fact that gnumake was dropped as a baby and has nfi what file moving is'
mod6: your example will not work with my vtron, for one simple reason: the new rules state that we do not do ANYTHING with vpatches that do not have a corresponding signature - we IGNORE WILD vpatches and drop them on the floor.
asciilifeform: if phf , or anyone else, can think of a 3rd ( that is, one that actually preserves the v-genealogy , rather than idiot-cut-and-pastism ) i'm all ears.
asciilifeform: now let's come back to my much earlier pill, which i suggested in the mircea_popescu thread. which is imho even uglier. in that one, diana_coman would have to introduce the three mpi-ism vpatches comprising her working set, as ~files~ into eucrypt. and a sed script, and a vtron invocation, into her eucrypt makefile.
asciilifeform: phf: given example works with my vtron, oughta equally work with mod6's. and does the job (both from vtronic genealogy pov, and gnumake's -- the latter (see the makefile of my faux 'eucrypt') recurses updir ) the 1 down-side is aesthetics.
asciilifeform: it's not eucrypt, of course, but the helloworld i originally included in mpi . but shows what i meant above.
phf: well, the project is called eucrypt, presses into eucrypt directory, inside it has support infrastructure like mpi
phf: presumably she doesn't want to compromise the resultant press because of poor tooling
asciilifeform: then you dun need any gnupatch shenanigans.
asciilifeform: it isn't required for the linker, nor for maintaining v-lineage ( the latter works just as well if diana_coman were to simply add a comment to 1 or more items in mpi dir , that 'this is nao part of eucrypt' )
asciilifeform: the 1 thing i still don't fully understand is why diana_coman's subdir gotta move
asciilifeform: phf: this is the basic insanity of gnupatch. a proper vpatch ought to see that the hashes are the same incoming and outgoing , and Do The Right Thing without the idiot spew
phf: diana_coman: it's not going to be pretty. it'll be twice the amount of text: once to delete the old file with - - - - and once to create a new file with + + + +
diana_coman: mind telling me how you see it done? it's hopefully faster than debugging a wrong approach; once I have it working I'll write up the failure too if that's the thing
diana_coman: asciilifeform, it does the move BUT it requires post-cleaning (i.e. leaves some stuff behind) + works only with mod6's v; so something is wrong somewhere and hopefully it's just on my side i.e. I can correct it quickly following your explanation of how it should be done
diana_coman: asciilifeform, I need to create a vpatch that performs the change of dir structure from a/mpi to b/eucrypt/mpi where the contents of the mpi folder in both cases are identical; or more specifically for the task at hand: I want to create a vpatch that has as antecedent my previous sane_mpi_eucrypt.vpatch (whose output is an mpi folder with all sorts) and results in eucrypt/mpi where this new mpi folder has precisely same contents
jhvh1: asciilifeform: The operation succeeded.
asciilifeform: !~later tell diana_coman plox to describe, very very specifically, what you need done. then i'll show how.
BingoBoingo: But it would piss of walmart customers: "Whaddya mean the help is taking home more money because they work AND get muh welfares!
shinohai: But the concept of a UBI is hilarious period.
BingoBoingo: And they stick
a111: Logged on 2017-12-07 16:51 asciilifeform: mircea_popescu: you can: diff ~the patch~
ben_vulpes: canvassing the low bandwidth radio space
asciilifeform: ( if it's shortwave -- i'll say right nao, it won't work, and the chinese 'up-converter' box -- defo wontwork )
ben_vulpes: http://ebrombaugh.studionebula.com/radio/r820t2_breakout/index.html << 17.20 for three breakout boards for the cheapo sdr chip in many tv tuners
a111: Logged on 2017-12-13 22:11 mod6: For other non-trb projects, perhaps the author can designa how that should work.
mod6: <+mircea_popescu> http://btcbase.org/log/2017-12-13#1751176 << nah, too complex and therefore frail system like that. simply : host ALL sigs for ALL things yourself ; let the urls be known publicly and don't change them. << This works. Having the redundancy is a good thing too.
mod6: <+asciilifeform> http://btcbase.org/log/2017-12-13#1751193 << iirc nothing yet spent, even << nearly; we did recently approve the first expendature: renewal of therealbitcoin.org
mircea_popescu: i dunno if im getting old or the thing is changing or what, but anyway.
mircea_popescu: http://btcbase.org/log/2017-12-13#1751240 << you know, it's only 1250 lines by btcbase count ; i recall in the past we had 2, maybe even a coupla 3k line days. yet NEVER before was it the case convo got so dense i had to switch to log reading WHILE AT THE TERMINAL.
asciilifeform: will emphasize, nobody should sign unless fully ready to say ' i know for a fact that this piece works, would jump with the parachute '
a111: Logged on 2017-12-14 00:41 mircea_popescu: http://btcbase.org/log/2017-12-13#1751176 << nah, too complex and therefore frail system like that. simply : host ALL sigs for ALL things yourself ; let the urls be known publicly and don't change them.
mircea_popescu: and if they were hungarian, it'd just mean she got married.
asciilifeform: if it were japanese , turtles would be plugging her holes and depicted in full squirming glory. but their cocks would be unicorn-shaped.
mircea_popescu: joke works just as well in either approach. but the буржуй bullshit consists of building an extra-tower of cvasi-funny bolted on the wall of the joke.
mircea_popescu: the fact that chick's depicted "under a cover" rather than in the frank position ( http://img.tfd.com/medical/Davis/Tabers/v26.jpg ) is a ~stylistical~ choice.
a111: Logged on 2017-12-13 18:23 mircea_popescu: honeslty i much preferred the density. made all sorts of буржуй bullshit untenable and plain-evidently not desirable.
mircea_popescu: "not hosting your sigs" is therefore a low level "can't be bothered to rate but still dun like you" sorta hostility
a111: Logged on 2017-12-13 22:11 mod6: For other non-trb projects, perhaps the author can designa how that should work.
mircea_popescu: http://btcbase.org/log/2017-12-13#1751176 << nah, too complex and therefore frail system like that. simply : host ALL sigs for ALL things yourself ; let the urls be known publicly and don't change them.
mircea_popescu: so just put them on your site somewhere.
a111: Logged on 2017-12-13 22:00 diana_coman: mod6, more FFA tests sounds good to me; slightly related: is there any protocol/preferred approach for publishing signatures to someone else's patches?
mircea_popescu: http://btcbase.org/log/2017-12-13#1751153 << more of an arges area item, that. morphs into falnic further west.
asciilifeform: refreshingly little mention of it, even in heathendom, past few yrs
asciilifeform: re foundations -- incidentally whatever happened to the derpoundation
mircea_popescu: ok, fine. about 40% of the 148mn or so land sqkm are actually farmed.that's still 60mn.
asciilifeform: ( see mircea_popescu's essay re the andes , for instance )
a111: Logged on 2017-12-13 22:50 mircea_popescu: fun fact : total land area on this planet being 510 mn sqkm ; and bitcoin cap being 21 mn, it therefore follows that the absolute maximal average price for land is a dime per square km.
a111: Logged on 2017-12-13 23:18 mircea_popescu: pretty much all of the mental pathology we call ustardianism directly derives from this fundamentally economic problem.
asciilifeform: http://btcbase.org/log/2017-12-13#1751237 << aha, and to think about the various symptoms individually, is rather like thinking of each individual fractured bone in d00d dropped from a skyscraper, as separate injury
asciilifeform: what do you call these in eng
mircea_popescu: and note that the ~most used armored item (stug) ALSO fucking maybach gasoline engine
mircea_popescu: wut.the.fuck.
mircea_popescu: asciilifeform yeah, i always wondered. the insanity of the eg panzer 4 GASOLINE engine still harrows my mind.
asciilifeform: ( i suspect the answer is -- comically -- in the scarcity of the diesel cycle in its birth land !! almost until end of war, ~0 diesel there )
mircea_popescu: i am skeptical this is actually worth bothering.
asciilifeform: gotta wonder why germans did not conceive of biodiesel. the tech was aaalmost there...
mircea_popescu: it IS better soap than synthetic, but it also doesn't keep as well. so...
mircea_popescu: slave labour works in the sense of education ; not very productive as extraction.
mircea_popescu: nazis didn't make bank on slave labour either.
asciilifeform: everybody tries. even with stalin's human material as i understand the ev was only marginally +.
mircea_popescu: well... 3x as many whippers as zeks. no idea where you'd get the whippers, but perhaps try china before naganting ?
mircea_popescu: fun fact : if 1960s vietcong invaded, the us could not muster a defense.
a111: Logged on 2017-12-13 23:17 mircea_popescu: it's true that women also have the avenue of not-being-animals anymore, but this happens to have opened just as most "jobs" got destroyed. so yes that works for a 5% of them, and another 10% or so could pretend and convincingly hope. the majority however, very much confront the pork bellies are $2 problem.
asciilifeform: http://btcbase.org/log/2017-12-13#1751235 << this applies across the board. ( as amply observed by mircea_popescu and others ). and the males dun even have the 'retreat into biology' option.
a111: Logged on 2017-12-13 23:16 mircea_popescu: the fundamental problem of eg, india, where everyone aborts girls because they don't want to pay for their raising to the level where they can be married ~because the trade value of the she-cow is NOT ENOUGH~ is really the fundamental problem of humanity : yes the cost of living went up, but the price of a head of cattle, or a goat, OR A WOMAN as such didn't go up. it went down. it's much cheaper to buy an ox now, either in s
asciilifeform: http://btcbase.org/log/2017-12-13#1751233 << softer version of the industrial world's 'abort everything that moves' issue
mircea_popescu: phf incidentally, what's the definition of tov popov ?
a111: 2016-01-22 <TheNewDeal> so so, how bout you?
asciilifeform: !#seen TheNewDeal
jhvh1: asciilifeform: I have not seen TheNewDeal.
asciilifeform: !~seen TheNewDeal
asciilifeform: nm looks like BingoBoingo linked : TheNewDeal
a111: Logged on 2017-12-13 22:30 BingoBoingo: <mircea_popescu> o yeah, through careful management the foundation ended up with like a quarter million dollars in its coffers or some shit ? << Careful management that further attracted an especially large donation from whatshisname
asciilifeform: http://btcbase.org/log/2017-12-13#1751194 << there was a d00d, iirc he was going mad, decided to get rid of his coinz..
mircea_popescu: there was a brief craze with "ostrich farms" at some point late 90s, but meh. it's just not very good.
a111: Logged on 2017-12-13 22:27 mircea_popescu: o yeah, through careful management the foundation ended up with like a quarter million dollars in its coffers or some shit ?
asciilifeform: nope. (tho they are sold widely here. but can't bring meself to eat ameriburger at all, not after the 1st one)
mircea_popescu: OFF WITH THEIR HEADS!
a111: Logged on 2017-12-13 22:22 mircea_popescu: serious about it, they'd have such things as hunter-meat-distribution services oiled and ready.
asciilifeform: http://btcbase.org/log/2017-12-13#1751185 << but! then, they'd have to confront the fact that the land can support maybe 1 in 20 of'em .
a111: Logged on 2017-12-13 22:00 diana_coman: mod6, more FFA tests sounds good to me; slightly related: is there any protocol/preferred approach for publishing signatures to someone else's patches?
asciilifeform: http://btcbase.org/log/2017-12-13#1751173 << same protocol as everybody uses for their original sigs -- just put'em somewhere people can see'em , they'll end up in phf's thing
asciilifeform: http://btcbase.org/log/2017-12-13#1751171 << aside from FZ's not being structs any longer, there shouldn't be much that you can't fix with search+replace
a111: Logged on 2017-12-13 21:09 mod6: asciilifeform: is this the chainsaw item? https://i.ytimg.com/vi/59sccgnsIgY/hqdefault.jpg
mircea_popescu: (transduction also term of art in biology, but ima stop before retyping the whole thesaurus by hand)
mircea_popescu: (neurotic here is used properly -- as the opposite of psychotic, which is to say, attempting to resolve psychological tension through self-transduction rather than reality-reconstruction.)
mircea_popescu: pretty much all of the mental pathology we call ustardianism directly derives from this fundamentally economic problem.
mircea_popescu: which neatly sends the precious-cuntlet syndrome straight into metaphysics, "there's a thing beyond the sensible which makes me valuable, let's call it emotions and you could never understand".
mircea_popescu: it's true that women also have the avenue of not-being-animals anymore, but this happens to have opened just as most "jobs" got destroyed. so yes that works for a 5% of them, and another 10% or so could pretend and convincingly hope. the majority however, very much confront the pork bellies are $2 problem.
mircea_popescu: the fundamental problem of eg, india, where everyone aborts girls because they don't want to pay for their raising to the level where they can be married ~because the trade value of the she-cow is NOT ENOUGH~ is really the fundamental problem of humanity : yes the cost of living went up, but the price of a head of cattle, or a goat, OR A WOMAN as such didn't go up. it went down. it's much cheaper to buy an ox now, either in s
mircea_popescu: "snowderella or what's her name DIDNT EVEN HAVE TO STAY ALIVE till the prince came, why should i hit the threadmill". how did he come ? well... that's his problem! and his business! as a prince, to come! (ie, http://btcbase.org/log/2017-12-12#1749973 )
mircea_popescu: a concern with "privacy", preoccupations with "feminism" in the ustardian sense, complete unskilled cluelessness etcetera are all great predictors of the underlying syndrome.