asciilifeform: and before anyone asks, no, you can't automagically strip the crapolade away with a profiler. certain routines are quite legitimately there but are traversed infrequently (say, only when shutting down, or if disk is full, or a cable is unplugged, nuclear war has been declared, and so on.)

asciilifeform: it certainly cannot be accomplished by twiddling the usual config. there is crud in there by the megatonne, glued in with glass.

asciilifeform: danielpbarron: and there is no practical way to separate the 'flies from the cutlets' here. who here has even 'tried' building a lin. kernel with -not one- driver for hardware you don't have or want?

asciilifeform: danielpbarron: linux 2.6.x kernel is a mega-turd. and while there remains a single line therein which does not execute during the normal operation of bitcoind-on-pogo, i will maintain that this is true.

asciilifeform: danielpbarron: in essence, like most supposedly 'gpl compliant' commercial products, the compliance is a total and unabashed crock of shit.

asciilifeform: danielpbarron: i have not been able to build the linux that comes with pogo. the included patches do not apply cleanly.

asciilifeform: danielpbarron: but try to understand a more fundamental principle here. eventually this needs to turn into a system with -no- extraneous parts. as in, i take a stick and point to a byte, and you are able to tell me why it is there.

asciilifeform: danielpbarron: 128M of eeprom are more than enough to store whatever you want, but these things eat up ram footprint (both by themselves and when read-cached)

asciilifeform: danielpbarron: those can't be stored on /dev/sda1 << absolutely not. node must be self-contained and able to format a brand-new disk entirely on its own, when plugged in.

asciilifeform: danielpbarron: the latter is almost -readable- in length

asciilifeform: danielpbarron: linux kernel and minimal userland are massive compared to netbsd

asciilifeform: and yes, esr was a barnacle on 'foss' from day one. authored inconsequential crap, claiming to be 'contributor'; attached his name to 'jargon file' historical book, having added various bogus entries; etc

asciilifeform: i'm taking a forced break, simply have no time presently

asciilifeform: and while i could, with some effort, shoehorn bitcoind into one of the still-produced alternatives for 'pogo' - all of which have no more than 32M of ram - it presumes something other than the mega-turd that linux kernel is.

asciilifeform: netbsd or minix are afaik the only practical paths towards a 100% crud-free node box.

asciilifeform: anyone with ideas re: resolving the 'sys.mk' retardation, speak.

asciilifeform: almost like there's a script, aha.

asciilifeform: open challenge to rms? the latter will remove the gnome if he has any balls left

asciilifeform: mircea_popescu: nope. this is a cross-compile and uses 'TOOLDIR' var.

asciilifeform: let's do a 'trichotomy' on the netbsd thing. as far as i can see, there are three and only three possibilities in a case like this (i am deliberately not including the forth, of my being a muppet.) 1) whole orchestra -never- worked 2) once worked, but a sniveling shitgnome fucked with the docs 3) docs were once correct and described a working sys, but a sniveling shitgnome changed the code 'because pr0gr3ss' ☟︎

asciilifeform: can anyone here shed any light on the question of how netbsd's 'nbmake' finds its global config, 'sys.mk' ? the docs are silent. and no, it doesn't look in its install dir.

asciilifeform: thus it will be attacked in every available way. the 'consensus' of 'the community' and 'how the world works' will stand as a solid wall against the 'obsolete, white male privileged' gcc.

asciilifeform: the ancient, gnarly code, the caretakers - few in number, mostly know one another; the infrequent patches - not an especially shitgnome-friendly environment.

asciilifeform: gcc is a natural target, as one of the last remaining total bastions agains poetteringization and 'modern advances,' 'pr0gr3ss!111!1111!,' etc.

asciilifeform: for folks unfamiliar with esr, he has always been an unabashed barnacle who clung to whatever he saw as 'winning' at the moment. so usg did not have to break his kneecaps. he knew exactly when to bend over and lube up.

asciilifeform: mircea_popescu: the llvm thing, prior to career as apple crud, had a previous life as a darling plaything of u.s. 'comp sci' academitardia ☟︎

asciilifeform: mod6: yes, it is set to the path that the 'tools' build.sh process spits out.

asciilifeform: 'TL;DR: You can't beat clang. Join it.' << this idiot has long avoided his correct place - in pederasty and by the latrine corner.

asciilifeform: BingoBoingo: i can only conclude that he is an apple/usg shill.

asciilifeform: mod6: and yes, the file exists. just isn't seen.

asciilifeform: BingoBoingo: zaurus << and a spare century or two

asciilifeform: and the frustrating thing is, i have the kernel built. and all standard userland proggys. but ramdisk also needs the /dev and /etc; the former - has to get crapped out of a build script thingie that refuses to grind

asciilifeform: thing is, netbsd is the one and only path because 1) it builds the toolchain 2) builds a <1MB kernel 3) perfectly set up for a one-executable userland. but (3) refuses to happen so far

asciilifeform: BingoBoingo: i've built perfectly usable netbsd boxes previously. but this one -has- to be a cross-compile. and live in ramdisk.

asciilifeform: question for all: has anyone, ever, built netbsd ramdisk on cross-compile build system, or knows of anyone who has done so, or knows so much as a shred of evidence that this has ever worked?

asciilifeform: any of you try 'micro-ecc' yet ?

asciilifeform: mircea_popescu: simple experiment shows that penalizing nodes sending out-of-order blocks - does very little. as pointed out. what we want is to 'embrace & extend' the block sync process in the sense of preferring friendly nodes for sync.