97700+ entries in 0.059s
lobbes: well, sounds good
to me.
ben_vulpes: lobbes: shared shell alone, i haven't examined
the implications of
this scheme for rockchips yet
lobbes: and would
this be for both shared hosting customers and rockchip (and anything else)?
ben_vulpes: this incentivizes
the hunt for long
term customers
ben_vulpes: and yes, of
the affiliate's recruited set, not of all customers.
ben_vulpes: lobbes: for so long as a customer is paying pizarro is
the intention
lobbes: ben_vulpes: Here's my initial q's: 1) Is
that in perpetuity? 2) I assume
this is a percentage of
the revenue of
the set of
the customers
the sales person recruits and not of
the entire set of customers?
a111: Logged on 2018-05-21 22:47 ben_vulpes: mod6 asciilifeform: a sales incentive scheme proposal: we kick back 5% of revenue
to affiliates who've recruited up
to 10 paying customers, 10% up
to 25 paying customers, 15%
to 50 customers and
then 20% for recruiting over 50 customers, which'd be a
tidy .03 btc/mo, way better
than any other "while you sleep" scheme out
there.
mircea_popescu: aand in
today's aphorisms, "Licking
the power socket will never kill
the licking of power sockets, even
though it may kill all lickers of power sockets."
ben_vulpes: mod6 asciilifeform: a sales incentive scheme proposal: we kick back 5% of revenue
to affiliates who've recruited up
to 10 paying customers, 10% up
to 25 paying customers, 15%
to 50 customers and
then 20% for recruiting over 50 customers, which'd be a
tidy .03 btc/mo, way better
than any other "while you sleep" scheme out
there.
☟︎☟︎☟︎ a111: Logged on 2018-05-21 19:23 asciilifeform: 'AmRRON Dark Labs, a
type of Skunk Works for
the Patriot community, has built a machine...' blah
a111: Logged on 2018-05-21 16:55 phf:
http://btcbase.org/log/2018-05-20#1815927 << i'll
take a look, i had further comments about diana_coman's original spec and
the responses, but does
this new spec replaces
the other one entirely?
mircea_popescu: usefully,
too, if anyoen wants
to keep
these
they're autosorted by run
a111: Logged on 2018-05-21 16:38 esthlos: but under current behaivor, program won't clean up
tempdir when it eggogs
a111: Logged on 2018-05-21 11:40 spyked:
the __attribute__((gnu_inline)) attr is of course very stupid
through its lack of portability, but as per
https://gcc.gnu.org/onlinedocs/gcc/Inline.html , it seems
that
the wrecking
to
this compiling/linking behaviour of inline was done pretty early on (C90).
a111: Logged on 2018-05-21 10:12 ave1: does anyone have a ru
to eng or de
translation dictionary as a
text file?
a111: Logged on 2018-05-21 00:01 asciilifeform: by ~that~ measure it was dead 3+y ago , when it
turned
to openly infecting
the stored
tarballs
ben_vulpes: asciilifeform BingoBoingo: i await a
transaction
to clear
through deedbot,
then i shall settle your invoices
mircea_popescu: ben_vulpes, but you can also
talk
to ads already posted.
lobbesbot: ben_vulpes: Sent 22 hours and 13 minutes ago: <asciilifeform> is
there a problem with
the invoice ? ( aside from
the fact
that i forgot
the 36 usd fee , in it ) ? how come i'm still waiting ?
ben_vulpes: mircea_popescu: it doesn't make sense
to put delicate items acquired with much suffering like BingoBoingo's cedula immediately into
the statists hopper (localbitcoins demands "an ID"
to post ads), when one can pick from
the sale offers and operate on
the side of
the
transaction where id is not asked for
☟︎ mircea_popescu: there's
two important advantages of reasoned decisionmaking. first and foremost it gathers your people around you,
this is what loyalty is made of, at its best. secondly and more importantly it permits history, which is
to say humanity.
mimisbrunnr: Logged on 2018-05-17 14:40 mircea_popescu: what is behind comments like
http://btcbase.org/log/2018-05-16#1814037, "I moved more recently
than
this fellow and I'll get my id after he does" ? "I don't, properly speaking,
think bb is a person, at least not in
the same sense /
to
the same degree I am" ?
a111: Logged on 2018-01-09 18:57 mircea_popescu: unicode is
the solution!
phf: asciilifeform:
transliteration code failing, give me a sec
a111: Logged on 2018-01-09 20:29 asciilifeform: in other oldies, seiko's 'DPU414'
thermal printer, can be had for <fiddybux, and not only prints 80cols x infinity (continuous
tape) but knows how
to eat rs232 and... print hexdump (up
to 19200 baud)
BingoBoingo: asciilifeform: Well,
the existence of FUCKGOATS raises
the bar
BingoBoingo: <asciilifeform> 'AmRRON Dark Labs, a
type of Skunk Works for
the Patriot community, has built a machine...' blah << LOL, FBI-otron in
the wild!
spyked: I'm pretty sure
that happens with functions qualified as static. but
the inline qualifier might cause
the compiler
to eliminate
those definitions.
spyked: ah. my intuition was
that static inline might increase
the size by leaving unused definitions in every .o file generated from
the respective .c
that imported
the header.
phf: spyked: you kind of have a choice between #define equivalent inline, which is going
to be actual inline and increase
the binary size, or else i don't
think it really matters. supposedly
the annotation makes
the calls "faster", but
the notion of faster is very vague. i suspect it's essentially an equivalent of "register" keyword:
things are maybe sometimes reshuffled
to make
things maybe sometimes faster
spyked: but
this is easy
to verify with readelf -s | grep inlined_func
a111: Logged on 2018-05-21 16:34 phf:
http://btcbase.org/log/2018-05-21#1816308 << is
there any need for
that alternative? from my research static inline is one of
the few behavioral commonalities between c99 and pre-c99. it also supposedly works across different compilers, etc.
spyked:
http://btcbase.org/log/2018-05-21#1816325 <-- it's not needed, at least not in
the case of vtools. it may have been worth it if it had reduced binary size, but from my experiment it makes no difference. gcc seems
to remove
the definitions of static-inlined functions (after inlining
them), but I don't really know if it does
that in general.
☝︎ phf: ccl has a fancy system, based on hacked up gcc, for generating ffi mappings (called interfaces), which you
then can use with (use-interface-dir :foo) (#_foobar ...)
esthlos: gotta run for a bit,
thanks for
the info phf
esthlos: is
that a reader macro for system calls?
phf: clozure doesn't need
to, #_mkdtemp
esthlos: may just have
to get dirty with
the ffi
phf: sbcl has both own ffi, and
there's also SB-UNIX:SB-MKSTEMP
phf: cffi is compatibility layer
to native ffis (a rather dodgy one
too)
esthlos: phf, I assume by ffi you mean a call
to run-program, not a use of cffi?
phf: true, i'd still just go for an ffi
to mkstemp. you're dealing with a unix substrate, might as well use unix
tooling. otherwise you have
to juggle file-probe, create-directory, but restart if
there's exception, etc.
esthlos: but under current behaivor, program won't clean up
tempdir when it eggogs
☟︎ a111: Logged on 2018-03-28 19:32 asciilifeform: funnily enuff, if working rng were standard on pc, 128bits from it would give unique-gensym (
the supposed problem , according
to
the gcc nitwits, with mktemp , is collision ) without O(N) searching ( as in mkstemp) with probability ~1
esthlos: phf: was about
to mention
that
phf: asciilifeform:
that's not going
to work cross-invocations
though. gensym is incremental across
the instance, so same invocations should produce roughly same gensym numbers
esthlos: anyone have a good idea for generating unique identifiers for v's gpg keyring name? I just spent a painful hour debugging because CL's #'get-universal-time is only precise
to
the second
phf: i'm alive by
the way, will start catching up on
the mother of logs
phf:
http://btcbase.org/log/2018-05-21#1816308 << is
there any need for
that alternative? from my research static inline is one of
the few behavioral commonalities between c99 and pre-c99. it also supposedly works across different compilers, etc.
☝︎☟︎ mod6: trinque: yeah, I
think it's gonna rain here
today
too.
trinque: doing just fine. watching
the rain come down.
spyked: it might also in a way be interesting
to report how I stumbled upon
this: I
tried
to recompile gnupg-1.4.10 on my broken debian system and got
the same "multiple definition" linking errors as in vtools' case (though I *did* use gcc<5). so I dug and found
the usual kochs "fixing"
things
to compile gnupg on newer gccs.
☟︎ spyked: (or
that might be C99, actually)
spyked: the __attribute__((gnu_inline)) attr is of course very stupid
through its lack of portability, but as per
https://gcc.gnu.org/onlinedocs/gcc/Inline.html , it seems
that
the wrecking
to
this compiling/linking behaviour of inline was done pretty early on (C90).
☟︎ spyked: 1. pressed latest vtools; 2. changed all "static inline"
to "extern inline __attribute__((gnu_inline))" in
http://btcbase.org/patches/vtools_fixes_static_tohex#L5 ; 3. compiled; 4. diffed
the symbols in
the generated vdiff against
the unmodified version => no changes, xnmalloc et al. are not included in
the final binary.
a111: Logged on 2018-03-29 10:22 spyked: phf's ld might add an "static"
to "inline"; or not, not sure; can verify by objdump'ing vdiff and seeing if
there appear multiple (with local linkage) definitions of xnmalloc in
the same file.
ave1: does anyone have a ru
to eng or de
translation dictionary as a
text file?
☟︎