42700+ entries in 0.028s

mircea_popescu: NOBODY WORTH
THE MENTION EVER WAS BLACK. OR EVEN BROWN. GET
THE FUCK OVER IT ALREADY, LIES WONT FIX IT!
mircea_popescu: fucking "java".
this imbecile fashion
to name
things after africans already.
mircea_popescu: no fucking way.
they "hired" 9000 zeks who were "hired" anyway by virtue of being zeks,
to wrap it in crap so "nobody can
tell".
mircea_popescu: spyked
that works. fwiw i'd keep
the look of
the
thing, manpage-like
diana_coman: ftr I have otherwise down even what
the symlink was pointed at; it's not
that
the issue per se
diana_coman: me neither but it's a ...test machine; so it gets all
tested, what can I say
diana_coman: no, it's not
the symlink
that caused
the breakage; it's
the botched removal i.e. it did more
than remove
the symlink
diana_coman: asciilifeform, no need and no use for
that
trinque: 2019 marketing push for
the derps
trinque: asciilifeform:
they
totally either-did-or-are-considering-seriously ending
the whatever-you-idiots-think-we-do program
BingoBoingo: Ah, first
they drop
their armor. Next
the legionaires put warnings on
their own kit.
shinohai: BingoBoingo: Nah, mine has "Antrorsum hostem" engraved on
the sharp end.
BingoBoingo: Aite, just wanted
to make sure you weren't driving dull side into ground, climbing, and using sharp side as seat. Once again a case of reserve sharp side for enemy.
shinohai: Throw at enemy, laugh as
they attempt removal or drop now useless shield.
BingoBoingo: Well shinohai, how do you usually use your Pilum
to get
the feeling you are accustomed
to receiving from it?
shinohai: Why does
this feel like a Roman Pilum ?
a111: Logged on 2019-02-07 16:49 asciilifeform: in other cuntooisms : if anyone is short a x64 box
to
test-fire cuntoo with, asciilifeform has a surplus disposable box, 'lenovo s10-3' , with
that same chipset as in x60 etc period (
https://archive.is/Dny84 ) , if anyone in l1 wants, it's yours for
the cost of postage ( has a mechanical hdd in it, i fughet of what size )
hanbot: trinque, /sys fails with "/usr/gnat/vtoolsp1/vtools/cuntoo/build/sys:
target is busy." lsof doesn't match anything
tho.
mod6: My availability is pretty limited
that day, during
the day. Probably will be around later
that evening, or more for sure on Sunday.
trinque: I'd like
to get it done saturday afternoon if
that works.
mod6: I'll do what I can
this weekend,
time-permitting.
mod6: trinque:
thx! and yah, it was nice
to get
that going.
trinque: lets all plan on smashing
through
this path bug in
the vpatch
this weekend. I'll be available for it.
trinque: in related news, I have
trashed my cuntoo build drive with repeated builds!
trinque: the script runs
this umount for you at
the beginning of each attempt
to clean up after any prior build attempt. it wont bother with
the umounts if
they're already gone.
trinque: could
try umount build/*; umount build
trinque: these have
to be unmounted from within build dir before umounting build
trinque: hanbot:
the reason for
the recursive unmount is
that
the build mounts /proc /dev and /sys in
the build
target
a111: Logged on 2018-05-17 15:34 asciilifeform: ( and, lulzily, classical sd card ~does not support write protect~, it has
the same usg.nonsensical 'software read writeprotect
tab' as old floppies )
mircea_popescu: honestly a sane box should not end up in
the state you described, short of doing
things
to it like alf's easy bake oven.
mircea_popescu: i dunno anything else you could
try instead of a reboot anyway.
hanbot: mircea_popescu i haven't, based on noting various unknown webderps reporting it hung/killed
their session
mircea_popescu: asciilifeform i didn't dig into it, but noticed
the little
tab looking at
them. now
that i
think about it, i seem
to recall
this was actually discussed in log.
hanbot: mircea_popescu yes, makes sense. quandry is whether figuring out process lineage or ordering reboot and re-prepping for bootstrap will
take
the larger amt of
time, but
then former path comes with figuring out new (to me) shit, so...prolly best.
mircea_popescu: asciilifeform i have a bunch here, which have a
tab! you switch it
to permit writing or not!
mircea_popescu: from
the other pov,
the jbd2/sdb3-8
thing is
typically
the kernel doing journalling.
mircea_popescu: so your
thing here is
to figure out who
the fuck is
the parent, why
the fuck is it not cleaning up its dead kids, and possibly kill it
too, and it's stupid father in
turn until presumably you end up with
the kernel which WILL clean
them all up.
mircea_popescu: lled, whatever, at which point its parent, ie, whoever spawned it, waits on it and cleans it up. 4. until such a
thing happens,
the ~process
table~ still lists it, even
though it is no longer able
to ~do~ anything.
this is a "zombie", process existing in listings only, not yet cleaned up by its parent. (it can, unfortunately, block unmounting).
mircea_popescu: should show
the parent. basically,
the way
this whole
thing works is as follows : 1. linux is organized around "processes", which are a sort of agents let's say.
they're listed in /proc/ ; 2. any process can spawn other processes,
the whole menagerie's spawned by
the kernel (which in systemd
thing is also process 1, hence
the whole
http://btcbase.org/log/2018-10-19#1863880 thing ). 3. a process can close, or be
terminated, ki
☝︎ hanbot: continuing my mounting woes, i can't unmount sdb3 partition on
target drive from initial cuntoo bootstrap.sh (target is busy); offending process from 'lsof | grep sdb3' looks like /proc/4693/exe ("txt, unknown"), no response from kill -9, no idea how it zombied out or why, what am i gonna do?
mircea_popescu: hanbot anyway,
the same effect can be obtained by simply umount-ing all
the partitions.
mircea_popescu: come
to
think of it, prolly also requires root. are you not root ?
mircea_popescu: possible you ran it previously (when it worked) on an unmount
that supports -R ? whereas
the one using now doesn't ?
hanbot: so check
this out: on new attempt
to run cuntoo bootstrap.sh, i get
this error: "umount: invalid option -- 'R'". whereas man umount shows no uppercase R option (lowercase r makes sense, remount read-only). and moreover, first bootstrap.sh run moved past
this no prob, not like
the script *changed*, wth?
mircea_popescu: if volume is a concern, can limit it
to so many bytes /
time interval / ip. add command
to your bot
to whitelist ips by
their being claimed by l2 people,
then you can even invoice
them.
mircea_popescu: minus
the "Alipay and Wechat Pay are supported currently:" shockingly idiotic bs, of course.
a111: Logged on 2019-03-04 19:29 mircea_popescu:
https://img.vim-cn.com/ << check
them out. we prolly want something like
this actually huh.
BingoBoingo: <asciilifeform>
today -- prolly
they discuss which ver of systemd
to use. << Nah, more likely
they discuss how great
the version
they are ordered
to use is
mircea_popescu: hey, i recall a
time in
the 90s irc was for dating. fulla exactly
the kinda gal you'd like
to meet, bash & fuck on 1st "date".
mircea_popescu: the more patient sinophiles are invited
to squeeze
the rock for butter at
their leisure, my interest's exhausted.
mircea_popescu: well,
that linuxba
thing
turned out
to be pretty retarded.
mircea_popescu: there's no math broken-er
than
the math completely
the fuck undone.
mircea_popescu: yes, of course. i'm not proposing you publish
the damn
thing in any particular scheme, or
that your math comes out a particular way
mircea_popescu: if
the
tree is (evaluate object) (decide if buying object) (deal with
the fallout of buying object) you can't possibly spend 300ms alftime on 1, 190s alftime on 2 and 168`000`000 s altfime on 3. it's just insane.
mircea_popescu: this is no way
to go about
things, balance
the
tree, let everything get a commensurate qty of brain cycles.
mircea_popescu: a more balanced distribution of your own brainpower
to
the
trees of your own life can only benefit you. as it is, you're stuck now spending weeks of
time
to deal with
the results of decisions
that
took minutes
to
take on
the basis of information you "compiled" in half seconds, by sucking
thumbs.