asciilifeform: ( granted, nobody actually knows, these folx are fold of printing identical legend and keeping same vendor:usbid while fiddling something or other )
asciilifeform: BingoBoingo: interesting. these are both chinese pl2303 , nominally identical.
asciilifeform: diana_coman: ty for putting it in the log, i'd like to find the answer to the riddle.
asciilifeform: ( btw if anybody discovers a viable replacement for the pl2303 snake that dun cost an arm and leg and dun include flashable chips, i'd like to hear about it )
asciilifeform: ( above 7, pl2303 driver starts doing something odd, the boxes still work but several times slower )
asciilifeform: i've operated up to 7 on 1 linux box simultaneously , without problems ( the linux usb tweak from section 2 of operating manual http://nosuchlabs.com/hardware.html is required if using 3 or greater )
asciilifeform: i have my box set to stty... both on boot, so i never observed this effect. possible quirk of the pl2302 driver. i recommend , as in any battlefield installation of FG, to carry out the s.nsa-recced tests.
asciilifeform: but possibly this oughta wait for trinque's return and for the remaining fine-tunings to cuntoo .
asciilifeform: 1 of the things i'd like to do, supposing trinque hasn't yet already made it, is to replace the horrid gui-laden boot usb stick currently in pizarro bilge, with a cuntoo stick.☟︎
asciilifeform: hats off to trinque , pretty great item. ( as i understand , we will still need a troo tmsr tarballs mirror, and coupla other things. but it's a good start, 100% musltronic gentoo. )☟︎
asciilifeform looking forward to building some cuntoo boxen for own experiments.
asciilifeform: BingoBoingo: when diana_coman gives the signal that box is good to work, can remove kvm snakes and boot stick.
asciilifeform: diana_coman: at the risk of pedantry -- all of the pasted items, other than (4) , exist on your box's disk , exactly as pasted.
asciilifeform: ( afaik this is the first battlefield test of cuntoo. )
asciilifeform: i expect that trinque will find this thread to be of interest, when he comes back.
asciilifeform: diana_coman: aite. do not hesitate to ask, if the purpose of particular change , or anything else, is unclear.
asciilifeform: diana_coman: lemme know if box functions as expected. you will prolly want to install ave1's gnat . but even prior to this, can proceed with emerging eulora deps , and see which ones work under muslism .
asciilifeform: diana_coman: possibly i'm mistaken , will have to actually try the new vtool ( and whether it can be pressed with traditional vtron ) .
asciilifeform: 8) the kernel trinque's system ended up building, is preserved in /boot/bk . it boots, but dun see nic or FG, on account of rejecting modulism
asciilifeform: 7) FG are operating at /dev/ttyUSB0 and /dev/ttyUSB1
asciilifeform: 6) i emerged 2 proggies, 'app-misc/mc' (midnight commander) and 'usbutils' , which i needed during debugging.
asciilifeform: 5) nic config is in /etc/conf.d/net and /etc/resolv.conf , if diana_coman wants to change the former for any reason plz talk to pizarro folk 1st
asciilifeform: ( i dun blame trinque , afaik this is default lilo behaviour nowadays ) but i fixed.
asciilifeform: trinque's original also does something i consider ugly, it allows lilo to refer to disks/partitions by 'uuid' rather than device path, imho this should not be done ( it resembles poettering's warcrime against nic device names, and makes hand-tuning needlessly difficult )☟︎
asciilifeform: (3) contains 2 mistakes by asciilifeform re partition map; ergo , i wrote a 4) http://p.bvulpes.com/pastes/A94DS/?raw=true << install-corrected.sh << which reflects necessary changes to partition map ( and removes the console-via-rs232 that remained from trinque's orig experiment )
asciilifeform: hey trinque , is it safe to delete 'cuntoo' dir ( contains copy of distfiles, etc, could free ~1G ) or does it get used ?☟︎
asciilifeform: are hardbaked into kernel. trinque as i understand is working on an automatic process for this.
asciilifeform: the 1 non-trinquian component is the kernel, which is bitwise identical to what is on 1) dulap 2) the primary s.mg box. fortunately kernel carries own libc, musltronicity dun affect it. but the trinquian kernel src and my original config is still there, as well as my config for the iron; it is possible for diana_coman to later build the kernel with trinque's gcc, what is needed is to transform my config so that all necessary modules
asciilifeform: trinque's gcc, btw, is exactly as was printed on the crate, x86_64-gentoo-linux-musl 4.9.4☟︎
asciilifeform: say, builds modular kernel once, then lsmod, parse output, then builds cemented kernel with same parts.
asciilifeform: nah, simpler, would use existing mechanism that loads modules
asciilifeform: i.e. 'this dun run, the pertinent iron aint there'
asciilifeform: 1 very useful thing, that we dun have yet, would be a mechanism for unerringly pointing out deadcoad in a given running kernel.
asciilifeform: in the end there is no compelling reason to have modulism on box where iron dev aint happening.
asciilifeform: trinque: i have no prob with your 'cemented' approach to kernel, it is Right Thing; mine simply not caught up yet ( december 2017 build )
