Ron Steinke <[EMAIL PROTECTED]> writes:
> Full thread dump:
[lots of crap here]
> ... (~600k more, then tee (unix command line tool) failed with a write error)
*claps for the pretty fireworks*
-S
___
Freenet-dev mailing list
[EMAIL PROTECTED]
http://
"Mark J. Roberts" <[EMAIL PROTECTED]> writes:
> > >From blah blah blah
> >
> > confuses the fucking braindead parser. Arrrgghh.
>
> The list server even munges it with a > prefix it's so evil!
From-mangling is a more complicated issue than it appears to be at
first glance. Look here f
Oskar Sandberg <[EMAIL PROTECTED]> writes:
> One of them has to be completely isolated from freenet in order for
> a MITM to work in the protocol that Scott posted as well.
I'm not sure I understand why this is true. Is it because of the way
a node discovers other nodes?
-S
__
Adam Langley <[EMAIL PROTECTED]> writes:
> I could put it in a thread. Each client would have 2 (or more)
> threads. One would be neuroses and the rest would be the client.
> Client and Neuroses would communicate via a socket pair. Even with
> shared libraries, this could be quite bloated. (thou
Travis Bemann writes:
> This requires that the *first* connection between Alice and Bob
> *MUST* be MITMed. If this first connection is not MITMed, then MITM
> is not possible between Alice and Bob. This is the case with other
> protocols such as SSH (assuming that there is no initial shared
>
Speaking of problems with 0.3.6, is anyone else finding that inserts
with HTL=1 don't work? Everything seems to go fine from the client's
point of view, but the node gives a null pointer exception, and the
key doesn't end up in the data store.
-S
__
[EMAIL PROTECTED] writes:
> A fairly large bytecode savings.
Bah, it's negligible. Maybe on the order of ten bytes per return.
Most of the difference you're seeing there is unused exception
handling code, in case the code inside the synchronized block throws
an exception. I didn't realize it w
"Mr.Bad" <[EMAIL PROTECTED]> writes:
> Except doesn't the lock happen -after- the method has started with a
> synchronized block, and -before- the method starts with the
> synchronized method keyword? I'm not sure at all.
I'm pretty sure that, in the code generated by most compilers, a
synchroni
Scott Gregory Miller <[EMAIL PROTECTED]> writes:
> The second synchronizes the entire method. The internal
> synchronized block lets you lock a specific chunk of code. Better,
> you get to lock on a specific object, so you can control access to
> the object rather than the method.
Java (stupid
"Mr.Bad" <[EMAIL PROTECTED]> writes:
> Hey, so, just wondering here, for my own edification: is there an
> advantage to doing this:
>
> public void gar(int foo) {
> synchronized(this) {
> // stuff happens here;
> }
> }
>
> ...rather than t
Scott Gregory Miller <[EMAIL PROTECTED]> writes:
> The protocol should completely defeat the Man in the Middle attack
> as well.
Your protocol doesn't deal with MITM at all. It assumes that Alice
already knows Bob's public key, and MITM only works in cases where
both Alice and Bob fail to actua
Say, how about including a source tarball with each release? It would
be nice to be able to grab the source for a given release without
having to screw with CVS. It's also pretty much the standard
M.O. outside of the Java contingent.
-S
___
Freenet
"Mr.Bad" <[EMAIL PROTECTED]> writes:
> Also, I think Oskar and Scott need to have a powwow about
> features. Scott seems to be totally opposed to 3 lines of
> unnecessary code, while Oskar doesn't mind throwing in the kitchen
> sink, as long as it's not used. B-)
Speaking of which, could we get
"Mr.Bad" <[EMAIL PROTECTED]> writes:
> I'm just a little skeptical that these guys could get a working
> product up without -any- Fred code in it fast enough to make these
> press statements. If it -did- have Fred code in it, I believe that
> they'd have to put it under GPL -- since Fred is GPL a
14 matches
Mail list logo
