42200+ entries in 0.031s
mod6: It was just "plugged in"
to SATA channel 2.
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.
trinque: I don't know why you find
this surprising
trinque: no dude, why would
the drive still be mounted on
the build dir if you rebooted?
mod6: Is
this what you're asking?
trinque: ok. so what happens
to mounts when you reboot
trinque: didn't you just say you were going
to reboot?
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: ('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.
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.
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~.
diana_coman: mircea_popescu, what is
the gain vs having as input octets or words?
mircea_popescu: i really do not wish
to see c strings, and i don't perceive char buffer
to be different. "bitstream" does not exist. so my
thinking is,
to henceforth mandate datapassing as such a field.
mircea_popescu: diana_coman well, apparently it expects
to be called with a bitstream, which is a peculiarly inconvenient datastruct in practice.
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
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.
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
bvt: i.e.
there is really directory structure /cuntoo/portage/profiles/root/cuntoo/build/...
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: i.e. one
that physically exists on disk?
trinque: bvt: you confirm
that
this exists in your genesis, but is not a valid path?
mircea_popescu: ah, i vaguely recalled we had
two of
them, one bit
the other byte.
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: 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: yes,
that one is
there; but I don't see
the path
that vdiff seems
to see
trinque: this is what's vdiff'd
to produce genesis
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
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
trinque: seems as
though
there's a dereferenced symlink munged into
the path.
diana_coman: trinque,
that's weird; fwiw: no, my home dir as far as I can see is *not* in
the profiles directory
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?
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
a111: Logged on 2019-03-10 17:40 asciilifeform: i'd like
to see phf come back
to life and fix. failing
this, 1 of us will have
to
mircea_popescu: i don't really, and besides my/our policy has mostly been
to have pizarro own iron, hence
the snsa sale etc.
BingoBoingo: Right. Half empty crates are for
testing new couriers.
BingoBoingo: asciilifeform: Aite. We don't do
these very often yet, so getting
things in hand
trumps getting plane
ticket arranged.
BingoBoingo: asciilifeform: It's march 10th, what is
the window for a supply run looking like and what issues appear
to be blocking?
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: I don't recall it being discussed in detail (i.e. with numbers for stack size and input size) anywhere and I
think it should be, if it stays as it is
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.
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.