On Fri, Nov 12, 2010 at 02:20:35PM -0800, ron minnich wrote:
> On Fri, Nov 12, 2010 at 2:15 PM, Eric Van Hensbergen wrote:
>
> > No, that's true. I think this is actually a huge open issue for
> > existing distributed file systems in general and I'm not sure of a
> > good way around.
>
> yeah,
On Fri, Nov 12, 2010 at 11:21:51PM -0800, ron minnich wrote:
> I can't help it, this one struck me as quite funny, after all the
> shared library discussions we've had on this list.
>
> "A Stanford researcher, Philip Guo, has developed a tool called CDE to
> automatically package up a Linux progra
> On Sat Nov 13 02:34:14 EST 2010, don.bai...@gmail.com wrote:
>> So now bin/ls is going to weigh 200 megabytes on SomeDistro thanks to
>> a packaging of localities, terminal colours, etc? Sounds great.
>
> i can't wait. in 200-odd megabytes you can have
> (a) a plan 9 distribution, or
> (b) linu
On Sat, Nov 13, 2010 at 8:58 AM, wrote:
> That's only fair. GNU ls is probably about the same number of
> lines of code as Plan 9 :)
actually, I'm pretty sure the configure script is as many lines as Plan 9 :-)
ron
I wonder if, 10 years from now, someone using such "static" libraries
will come up with a way to dynamically link against them.
On Sat, Nov 13, 2010 at 5:05 PM, ron minnich wrote:
> On Sat, Nov 13, 2010 at 8:58 AM, wrote:
>
>> That's only fair. GNU ls is probably about the same number of
>> li
On Sat Nov 13 12:09:46 EST 2010, rminn...@gmail.com wrote:
> On Sat, Nov 13, 2010 at 8:58 AM, wrote:
>
> > That's only fair. GNU ls is probably about the same number of
> > lines of code as Plan 9 :)
>
> actually, I'm pretty sure the configure script is as many lines as Plan 9 :-)
but the con
I think I misfiled the tape with your talk and the HARE panel. I'm looking.
On Fri, Nov 12, 2010 at 9:32 PM, Bruce Ellis wrote:
> where's mine. i have begun a world fair style video. but without
> brucee in the disney spinning cups it won't be the same.
>
> obrigado
>
> On Thu, Oct 28, 2010 at 1
found it. Will try to rip and encode for you this weekend.
On Sat, Nov 13, 2010 at 11:18 AM, Eric Van Hensbergen wrote:
> I think I misfiled the tape with your talk and the HARE panel. I'm looking.
>
> On Fri, Nov 12, 2010 at 9:32 PM, Bruce Ellis wrote:
>> where's mine. i have begun a world fa
Hi folks,
I'm currently looking for the opposite of an bloom filter, which
may have false negatives but no false positives.
The purpose is allowing an spooling (store+forward) mail relay
to learn which addresses are not accepted by the actual maildrop
(which is connected by an uucp-link, so no
* Brantley Coile wrote:
Hi,
> i'm sorry. those who are not in silicon valley or northeast georgia will
> have to relocate.
That would be the primary blocker for me, as I don't want to
leave my home country :(
Could you perhaps imagine giving certain projects to contractors
in a foreign cou
Hi folks,
I'm now thinking about changing mozilla to use webfs instead of
its own protocol handling for quite some while (the whole caching
machinery should also be kicked off in this process and delegated
to either an local proxy like wwwoffle or implemented in webfs).
The big question to me n
* Charles Forsyth wrote:
> ``My last company switched to nmake, and they're OUT OF BUISINESS :-) :-)
> :-)''
> [fortune]
When it comes to builder systems, I'm still thinking of an more
declarative approach: describing the software's structure by
certain object types and their relations (eg. we
* ron minnich wrote:
> If you're the kind of guy who can't resist changing things that don't
> need changing, then you won't get it; perhaps you'd be better off
> working on libtool. But Plan 9 is far from dead.
Nobody with at least half-sane mind voluntarily works on or even
with libtool ... it
> In longer terms, I'd also replace mozilla's handling of other
> protocols, eg. ftp, by an webfs implementation.
>
>
> What do you think about this ?
webfs is client side, not server side.
- erik
> The purpose is allowing an spooling (store+forward) mail relay
> to learn which addresses are not accepted by the actual maildrop
> (which is connected by an uucp-link, so no direct smtp chat),
> to get rid of the thousands silly error bounces from brute force
> attacks on email addresses.
Very(
> I'm currently looking for the opposite of an bloom filter, which
> may have false negatives but no false positives.
>
> The purpose is allowing an spooling (store+forward) mail relay
> to learn which addresses are not accepted by the actual maildrop
> (which is connected by an uucp-link, so no di
> This requires the remote uucp site to give you a Bloom
> filter with all the valid addresses inserted, but that seems
> unavoidable. I don't know how the opposite-of-Bloom-filter
> approach would work anyway.
One problem with this is handling wildcarded addresses. How do you indicate
(say) lynd
On Sat Nov 13 17:28:09 EST 2010, lyn...@orthanc.ca wrote:
> > The purpose is allowing an spooling (store+forward) mail relay
> > to learn which addresses are not accepted by the actual maildrop
> > (which is connected by an uucp-link, so no direct smtp chat),
> > to get rid of the thousands silly e
> i think the idea of spooling email is largely discredited.
It's not a spam avoidance trick. It's how I get around arbitrary
blockage of SMTP/submission port injection when I'm not sitting at
home. If you read your mail on a laptop, it's the easiest way around
all the ISP/Hotel/Public-WIFI filt
On Sat, Nov 13, 2010 at 12:56 PM, erik quanstrom wrote:
> > In longer terms, I'd also replace mozilla's handling of other
> > protocols, eg. ftp, by an webfs implementation.
> >
> >
> > What do you think about this ?
>
> webfs is client side, not server side.
>
> - erik
>
> I must confess, I under
> One problem with this is handling wildcarded addresses. How do you indicate
> (say) lyndon+* is allowable in a bloom filter, where the '+' is an
> arbitrary (to the upstream) symbol.
Tell the accepting site to strip +* from all the email addresses
before checking. There aren't that many cases l
On Fri, Nov 12, 2010 at 11:21 PM, ron minnich wrote:
> I can't help it, this one struck me as quite funny, after all the
> shared library discussions we've had on this list.
>
> "A Stanford researcher, Philip Guo, has developed a tool called CDE to
> automatically package up a Linux program and a
On Fri, Nov 12, 2010 at 11:37 PM, Federico G. Benavento wrote:
> cinap did years ago for linux emu
>
> http://9hal.ath.cx/usr/cinap_lenrek/lbun/mklbun
>
> which packages linuxemu, the linux exec you want and the
> required libs all in an rc bundle that you can execute
> as a regular program
>
> i
> Tell the accepting site to strip +* from all the email addresses
> before checking. There aren't that many cases like that.
There aren't many, but at least one that I care about exists. The
case is one-off throw away addresses. When I send a message, I
generate an address crypto-based on the
> > ladd Nov 13 04:08:12 Disallowed gossinternational.com!ruiohfsd
> > (gossinternational.com/124.172.212.142) to blocked name
> > quanstro.net!b94cd358e11d3ffb43628c10bc786087
> >
> > i think the idea of spooling email is largely discredited.
> > it opens up the possiblity for backscatter spam,
> The problem with strings is that they are human oriented and human
> dependent, on mood and/or trend. Numbers are agnostic.
>
> Isn't a solution a la IP network numbers possible? I mean, a user,
> whatever string is locally associated to it (and this may change),
> is uniquely identified by a n
> There aren't many, but at least one that I care about exists. The
> case is one-off throw away addresses. When I send a message, I
> generate an address crypto-based on the recipient and the time-frame I
> expect a response. I don't want mail coming back outside the
> specified response period
> okay, there must be more to the story. why do you need crypto
> secure burner email addresses to avoid spam?
If I could tell you that, I wouldn't need them.
[[resent from my subscribed email address after the mailing list rejected the
original]]
Hi Enrico,
On 14 Nov 2010, at 02:24, Enrico Weigelt wrote:
> * ron minnich wrote:
>
>> If you're the kind of guy who can't resist changing things that don't
>> need changing, then you won't get it; perhaps
grep -f is very efficient. you can extract it to a lib if you like.
please think about this and peek at the code before replying. i
understand the code because i was lucky enough to be in the room when
it was written.
a negatie bloom sounds good but your positives will (potentially) collide.
so t
oops "prefixes are common". it's hot and i'm still wingless.
brucee
On Sun, Nov 14, 2010 at 1:52 PM, Bruce Ellis wrote:
> grep -f is very efficient. you can extract it to a lib if you like.
> please think about this and peek at the code before replying. i
> understand the code because i was luck
crap i was right the first time. suffixes from .com to .crazy-tool.com
On Sun, Nov 14, 2010 at 1:54 PM, Bruce Ellis wrote:
> oops "prefixes are common". it's hot and i'm still wingless.
>
> brucee
>
> On Sun, Nov 14, 2010 at 1:52 PM, Bruce Ellis wrote:
>> grep -f is very efficient. you can extra
On Nov 13, 2010, at 21:17, Gary V. Vaughan wrote:
> People like to beat on GNU Libtool, and in some cases that criticism is
> not undeserved... but in my experience, many critics of the tool come
> from a perspective of building on a single architecture. If you have
> never tried to build and lin
> When I write C code which I intend to be portable, I write against p9p, ...
I don't think this is fair to Gary's well-reasoned mail.
He explicitly said libtool was solving the problem of
providing a single consistent command line tool that
handled the job of building a *shared library* on a
vari
> You may well be right that there's too much momentum behind
> autoconf/automake to change GNU. But that doesn't mean it's the right
> thing to do, or something sensible people ought to choose to
> participate in.
to be a bit more blunt, the argument that the tyrrany of the
auto* is unstoppable
35 matches
Mail list logo
