date:20090521

XMLLibrarian on downloads.freenetproject.org was compiled with Java 6
and emitting UnsupportedClassVersionError.
Please recompile it with Java 5 and update the binary.

[freenet-dev] Using standard ports of encrypted protocols

2009-05-21 Thread Florent Daigniere

Arne Babenhauserheide wrote:
> On Wednesday, 20. May 2009 18:14:53 Matthew Toseland wrote:
>> Depends on your threat model. Freenet traffic clearly doesn't look like
>> these without proper stego transport plugins, and the connections between
>> nodes definitely don't look like them, unless what you are imitating is
>> purely peer to peer, in which case you need to look at the other nodes'
>> connections as well and/or the timing. 
> 
> Is a steganography transport plugin planned? 
> 

Yes, but that's long term stuff. The important bit is the plugin system. 
Stego transports shouldn't be bundled by default otherwise they become 
part of the protocol and that defeats the purpose.

NextGen$

[freenet-dev] Usability test results

On Friday 15 May 2009 17:05:09 Robert Hailey wrote:
> 
> On May 14, 2009, at 5:06 PM, Matthew Toseland wrote:
> 
> > On Thursday 14 May 2009 20:36:31 Robert Hailey wrote:
> >>
> >> On May 14, 2009, at 12:17 PM, Matthew Toseland wrote:
> >>
> >>> Because we were both on the same LAN, it did not connect, until I
> >>> told him to
> >>> set it to allow local addresses on that peer. There should be a
> >>> checkbox when
> >>> adding a noderef, defaulting to on, "Friend may be on the same local
> >>> network
> >>> as me" or something. (#3098)
> >>
> >> I think that it should be possible to automatically detect this.
> >> Specifically, if we detect that our peer has the same "external
> >> address" as us, try and connect locally. Is that a reliable  
> >> indicator?
> >
> > Not very (what if it changes?) ... we don't want darknet peers to  
> > cause us to
> > connect to addresses on our LAN ... otherwise the solution is simply  
> > to try
> > the local addresses included ...
> 
> I agree that we don't want to try the local addresses of ~all~ our  
> peers; local connections are in principal an exception and not cause  
> enough to be sending so much local garbage handshaking traffic (that  
> could give away a freenet node).
> 
> But I think this is the right way to go... If it is not defined for a  
> given peer (allow/disallow local connections), then we could just  
> calculate the default boolean as  
> his.extAddresses.containsAny(my.extAddresses) if it matches, then  
> there is an excellent chance of it being a local connection (99%). If  
> it changes, that's great! The decision to try local connections would  
> change too! As it's probably a laptop that has floated out of the LAN  
> (and we would want to stop sending handshakes to the local address  
> anyway). At worst we might send a few garbage handshakes to local non- 
> freenet machine until we connect to the node & find it's new external  
> address.
> 
> The reason I think this would solve the problem because (I think) the  
> principal reason that the nodes could not communicate is because the  
> gateway would have to send a packet to itself (many inexpensive or  
> firewalled ones will not).
> 
> e.g.
> internal -> firewall -> external  (generally works w/ current  
> countermeasures)
> 
> internal -->
>   firewall
> internal <--
> 
> Does not work (at least for me). So what I propose is really an  
> extension of "detecting the problem" (the gateway which has the same  
> external ip). Don't know about multihoming, but I presume that this is  
> works in the common case.

Nonetheless it is highly unreliable as a way to detect it with dynamic 
external IP address, especially given that the two nodes are unable to 
communicate by any other means.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
URL: 
<https://emu.freenetproject.org/pipermail/devl/attachments/20090521/750183d2/attachment.pgp>

[freenet-dev] XMLLibrarian binary on downloads.freenetproject.org

On Thu, May 21, 2009 at 5:23 PM, Matthew Toseland
 wrote:
> On Thursday 21 May 2009 03:53:04 you wrote:
>> XMLLibrarian on downloads.freenetproject.org was compiled with Java 6
>> and emitting UnsupportedClassVersionError.
>> Please recompile it with Java 5 and update the binary.
>>
> It was compiled with your plugin build script iirc. Please update the build
> script for all the plugins to use java 5.

I have just updated with target="1.5" at 222d686

HOWEVER, you should always build with a 1.5 JDK.
This is the only way to ensure it does not use any Java 6 specific API
(accidentially).

--

[freenet-dev] Usability test results

 queue rather than actually  
> sending a packet. But it looks to me like a bit of cruft from a  
> previous design.
> 
> In any case, you have a design note in the comments of PacketThrottle  
> that it would be better to have a sorted list or red/black tree rather  
> than a ticket system (where all threads wakeup); maybe a new class  
> needs to be written (BulkQueue) that *only* interleaves waiters (round  
> robin?) and the packet throttle then used only for actually sending  
> packets.

Yeah...
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
URL: 
<https://emu.freenetproject.org/pipermail/devl/attachments/20090521/fe53d0b2/attachment.pgp>

[freenet-dev] Separate browser or not

Matthew Toseland skrev:
> On Sunday 17 May 2009 11:43:26 Zero3 wrote:
>> Colin Davis skrev:
>>> As implemented currently, Private browsing is all-or-nothing in 
>>> FF3.5beta4 and Safari, but Google Chrome is per-window.
 Firefox has issues with coalescing windows, no? If I run firefox with 
> command 
 line options to use one profile, it may use another if a window is 
> already 
 open, there are things like that... Is opening a window with privacy mode 
 enabled safe and reliable?
>> I guess both ways should work fine for us? We simply launch the browser 
>> with the command line arguments, and let the browser handle the 
>> window/tab management?
> 
> No, Firefox might very well end up opening a window in non-incognito mode.

Surely such bug would be fixed before the beta turns into final?

- Zero3

[freenet-dev] Updating helper executables on Windows

Matthew Toseland skrev:
> On Sunday 17 May 2009 11:41:00 Zero3 wrote:
>> Matthew Toseland skrev:
 Detecting the version of an installed application in the launcher (at 
 least in Windows) shouldn't be a problem. It will most likely be 
 registered in the registry next to the .exe path we are checking already 
 for the individual browsers. We can also check the version info of .exes 
 as an alternative (most Windows applications are compiled with various 
 static info like version and author). The Windows launcher is already 
 running Chrome with a command line argument making it start in privacy 
 mode btw.
>>> You should prioritise Chrome with privacy mode over Firefox without it.
>> Agreed: https://bugs.freenetproject.org/view.php?id=3118.
> 
> I thought you had already done this?

At time of writing, no. But since then I managed to figure git out and 
changed it (hence the bug is now "resolved").

... which leads to another thing to consider: We need to make it 
possible to update the start.exe/stop.exe/freenetlauncher.exe files for 
existing users when new updates are made available.

The easiest way to do this right now would probably be to add them to 
the update.cmd script.

- Zero3

[freenet-dev] Freenet 0.7 build 1210

Freenet 0.7 build 1210 is out. Sorry for the delay in announcing it. It will
be mandatory at midnight. There was also a minor git mess relating to
tagging - it was released from a local branch because I forgot to push before
tagging, although it has been merged back into master now. If you are
building from source you need to either clone the tag or do "git fetch -t
origin" to fetch orphan tags.

Changes:
- Startup fix: you can now move the persistent temp directory, as long as you
update freenet.ini accordingly. This is also an issue when moving the node.
- Startup fix: Deleting the persistent temp dir and moving the node failed to
startup
- Let the node start up even if the database is unrecoverably corrupted. Tell
the user what the situation is, and refuse to do any persistent requests or
inserts.
- Don't commit every database job immediately, unless we need to for memory
reasons (some job types), for UI reasons (e.g. starting a request), every 30
seconds, or after every job if the new alwaysCommit config option is enabled.
This should reduce disk I/O and improve performance significantly on some
systems with big queues.
- Fix various client layer bugs, in freesite inserts and other things.
- SSK insert collision handling fix - store the data as well as forwarding it.
- Minor crypto optimisation in handling SSKs.
- First time wizard: remove the memory limit selection page, add a page to ask
the user whether to auto-update Freenet and whether to load JSTUN and UPnP
(this may reduce performance on a new node *slightly*, but we don't want to
have to ask in the installer), warn the user about monthly bandwidth usage,
always show the bandwidth and store size pages, minor fixes.
- Enable javascript support by default in fproxy, minor fixes, get rid of the
MIME type column on the queue page in simple mode, more tolerant parsing of
noderefs and bulk download lists.
- Fix various connection level bugs, which hopefully once everyone has 1210
will fix the forced disconnected because not acknowledging packets bug. In
simulation this fixes "Unmatchable packet from ", which really
shouldn't happen!
- Minor plugin code improvements (new APIs, require XMLLibrarian version 22).
- Internal bugfix which hopefully only was breaking IPv6 address detection
from peers.
- Internal bugfix relating to moving files, might have caused bugs in several
places.
- Don't let default changes override the local option for whether to
preallocate the store.
- Lots of internal cleanup and some work on the many-nodes-one-VM simulators /
automated network tests, including a new long-term data retrievability test.

Also, the XMLLibrarian plugin now shows a search's progress without using
javascript, and immediately from typing a search on the homepage (thanks
mikeb). KeyExplorer 0.4 beta is out, and there has been more work on the WoT
web of trust plugin (thanks saces). A bugfix in the UPnP plugin, and as
previously mentioned we deployed the new windows installer (thanks Zero3).

Thanks to:
sdiz
3BUIb3S50i
platy
nextgens
saces
juiceman
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20090521/5e0d16f6/attachment.pgp>

[freenet-dev] Plugin snapshots

Please post on the list when you want me to distribute a new snapshot of a 
plugin. Thanks.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
URL: 
<https://emu.freenetproject.org/pipermail/devl/attachments/20090521/a0f82bca/attachment.pgp>

[freenet-dev] Updating helper executables on Windows

On Thu, May 21, 2009 at 6:58 AM, Zero3  wrote:
> Matthew Toseland skrev:
>> On Sunday 17 May 2009 11:41:00 Zero3 wrote:
>>> Matthew Toseland skrev:
> Detecting the version of an installed application in the launcher (at
> least in Windows) shouldn't be a problem. It will most likely be
> registered in the registry next to the .exe path we are checking already
> for the individual browsers. We can also check the version info of .exes
> as an alternative (most Windows applications are compiled with various
> static info like version and author). The Windows launcher is already
> running Chrome with a command line argument making it start in privacy
> mode btw.
 You should prioritise Chrome with privacy mode over Firefox without it.
>>> Agreed: https://bugs.freenetproject.org/view.php?id=3118.
>>
>> I thought you had already done this?
>
> At time of writing, no. But since then I managed to figure git out and
> changed it (hence the bug is now "resolved").
>
> ... which leads to another thing to consider: We need to make it
> possible to update the start.exe/stop.exe/freenetlauncher.exe files for
> existing users when new updates are made available.
>
> The easiest way to do this right now would probably be to add them to
> the update.cmd script.
>
> - Zero3
> ___
> Devl mailing list
> Devl at freenetproject.org
> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
>

I would be happy to do this, however I will need a defined directory
structure on the download site, with known file names.  Like we have
the .url link for the freenet.jar.  I believe I can use the .sha1 file
to check for updates if you want to have a static name. ie
wrapper_win32x86.exe etc.  Also I would prefer to not have them inside
a zip unless we have have a built-in unzipping program in Windows I
can reliably call by command line.  Otherwise we will have to bundle
yet another third party utility.

[freenet-dev] Separate browser or not

2009-05-21 Thread Colin Davis

As an aside, Matthew had asked in the past about reducing the number of
connections from the browser to the node.

Digg's new library may be able to assist- It breaks images into data uris,
and then inlines them.

Even if Freenet doesn't want to use the library, inlining images as Data
URIs may improve load times. Just a thought.
-CPD


http://ajaxian.com/archives/digg-shows-multipart-xmlhttprequest-prototype

[freenet-dev] Updating helper executables on Windows

2009-05-21 Thread Robert Hailey


On May 21, 2009, at 11:32 AM, Juiceman wrote:

> On Thu, May 21, 2009 at 6:58 AM, Zero3   
> wrote:
>> Matthew Toseland skrev:
>>> On Sunday 17 May 2009 11:41:00 Zero3 wrote:
 Matthew Toseland skrev:
>> Detecting the version of an installed application in the  
>> launcher (at
>> least in Windows) shouldn't be a problem. It will most likely be
>> registered in the registry next to the .exe path we are  
>> checking already
>> for the individual browsers. We can also check the version info  
>> of .exes
>> as an alternative (most Windows applications are compiled with  
>> various
>> static info like version and author). The Windows launcher is  
>> already
>> running Chrome with a command line argument making it start in  
>> privacy
>> mode btw.
> You should prioritise Chrome with privacy mode over Firefox  
> without it.
 Agreed: https://bugs.freenetproject.org/view.php?id=3118.
>>>
>>> I thought you had already done this?
>>
>> At time of writing, no. But since then I managed to figure git out  
>> and
>> changed it (hence the bug is now "resolved").
>>
>> ... which leads to another thing to consider: We need to make it
>> possible to update the start.exe/stop.exe/freenetlauncher.exe files  
>> for
>> existing users when new updates are made available.
>>
>> The easiest way to do this right now would probably be to add them to
>> the update.cmd script.
>>
>> - Zero3
>>
>
> I would be happy to do this, however I will need a defined directory
> structure on the download site, with known file names.  Like we have
> the .url link for the freenet.jar.  I believe I can use the .sha1 file
> to check for updates if you want to have a static name. ie
> wrapper_win32x86.exe etc.  Also I would prefer to not have them inside
> a zip unless we have have a built-in unzipping program in Windows I
> can reliably call by command line.  Otherwise we will have to bundle
> yet another third party utility.

If it helps, my understanding is that zip & jar are cross compatible.  
Or more specifically,
that a jar is a zip file with extra flags and a manifest file.

--
Robert Hailey

[freenet-dev] Separate browser or not

On Thursday 21 May 2009 18:54:38 Colin Davis wrote:
> As an aside, Matthew had asked in the past about reducing the number of
> connections from the browser to the node.
> 
> Digg's new library may be able to assist- It breaks images into data uris,
> and then inlines them.
> 
> Even if Freenet doesn't want to use the library, inlining images as Data
> URIs may improve load times. Just a thought.
> -CPD

Well it's not the stuff that we have already fetched that slows things down, 
it's the images we have to wait for.
> 
> http://ajaxian.com/archives/digg-shows-multipart-xmlhttprequest-prototype
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
URL: 
<https://emu.freenetproject.org/pipermail/devl/attachments/20090521/0d038b3c/attachment.pgp>

[freenet-dev] Separate browser or not

On Thursday 21 May 2009 11:54:32 Zero3 wrote:
> Matthew Toseland skrev:
> > On Sunday 17 May 2009 11:43:26 Zero3 wrote:
> >> Colin Davis skrev:
> >>> As implemented currently, Private browsing is all-or-nothing in 
> >>> FF3.5beta4 and Safari, but Google Chrome is per-window.
> >>>> Firefox has issues with coalescing windows, no? If I run firefox with 
> > command 
> >>>> line options to use one profile, it may use another if a window is 
> > already 
> >>>> open, there are things like that... Is opening a window with privacy 
mode 
> >>>> enabled safe and reliable?
> >> I guess both ways should work fine for us? We simply launch the browser 
> >> with the command line arguments, and let the browser handle the 
> >> window/tab management?
> > 
> > No, Firefox might very well end up opening a window in non-incognito mode.
> 
> Surely such bug would be fixed before the beta turns into final?

I have no idea, but it does exactly the above with profiles sometimes iirc.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
URL: 
<https://emu.freenetproject.org/pipermail/devl/attachments/20090521/44d7dda6/attachment.pgp>

[freenet-dev] update.cmd in java-based installer

Are all the changes made to update.cmd compatible with the java-based 
installer? For example, juiceman removed a bunch of commands relating to 
start.cmd; certainly I haven't tested my changes with the java-based 
installer.

Also, do we want to get rid of Windows support from the java-based installer? 
The website always shows the exe for windows users now...

Oh, and you didn't write version 3.0 - at least not all of it. :)
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
URL: 
<https://emu.freenetproject.org/pipermail/devl/attachments/20090521/5dc569e9/attachment.pgp>

[freenet-dev] update.cmd in java-based installer

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thu, May 21, 2009 at 4:19 PM, Matthew Toseland  wrote:
> Are all the changes made to update.cmd compatible with the java-based
> installer? For example, juiceman removed a bunch of commands relating to
> start.cmd; certainly I haven't tested my changes with the java-based
> installer.

I've always coded it assuming it would be used for both installers, so
unless there is a bug, yes.  =)
I would prefer that there is only one update.cmd on the website.

>
> Also, do we want to get rid of Windows support from the java-based installer?
> The website always shows the exe for windows users now...

Hmm.  The new installer is nice...  Have we received any reports of it
not working?
I don't see any reason to remove support unnecessarily... It is not
much work to copy updates to both branches.

>
> Oh, and you didn't write version 3.0 - at least not all of it. :)

I'll just change it to read "contributions by Juiceman" on next commit.  =)

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Use GnuPG with Firefox : http://getfiregpg.org (Version: 0.7.5)

iEYEARECAAYFAkoWAZAACgkQ4esu1mlKOs8g5QCfS3h76lE+dBmZLeLTp30ArgRR
I+gAnjYsuPWByBr9atZO6K4+rBjxt0l1
=Rsmn
-END PGP SIGNATURE-

[freenet-dev] Why WoTs won't work....

2009-05-21 Thread Evan Daniel

It's not all that interesting.  It has been discussed to death many
times.  The Advogato algorithm (or something like it) solves this
problem (not perfectly, but far, far better than the current FMS / WoT
alchemy), as I have explained in great detail.

Evan Daniel

On Sat, May 9, 2009 at 12:57 PM,   wrote:
> Interesting discussion from Frost, especially the last post at the bottom. 
> Its about WoTs in general and why they won't work.
>
>
>
> - Hahahahah at YLE3ZHs5LkiwE3FdJyQlcF5+RkA - 2009.04.05 - 02:28:11GMT 
> -
>
> I had to forward this one here.
>
> --- jezreel?X~GLTTHo9aaYtIpGT6OOyBMMFwl3b8LwFu6TUw9Q82E sent via FMS on 
> 2009-04-05 at 01:31:54GMT ---
>
> Probably not an amazing subject, but FMS is so dead lately so what the
> hell. ?Falafel, why do some of the folks posting to Frost hate you so
> much? ?In particular Luke771 and VolodyA. ?You generally seem like a
> nice identity so I'm just curious.
> --
> jezreel at 
> pbxwgrdegrigwuteoz3tc6cfla2xu3trmi2tgr2enfrvi4bxkzlectshfvyw2wcxkrffslccijku4z2om5gtoojrpzdfcolkovtdawjuifigkrcqjbevsvrnla2xotcdpfvw6lkmkzzsyqkrifbucqkf.freemail
>
> ;))
>
> - VolodyA! V A at r0pa7z7JA1hAf2xtTt7AKLRe+yw - 2009.04.11 - 
> 12:11:26GMT -
>
> I should point out i do not hate falafel, i do not know him. I do hate what 
> he is doing to Freenet, however. If he was to stop supporting intruduction of 
> censorship on Freenet i would not say anything bad about him.
>
> In fact i tend to agree with much of what he has to say on other subjects.
>
> --
> May all the sentient beings benefit from our conversation.
>
> - Denminkan at DlKKAIKia79j4oVPbgFK4zNh25Y - 2009.04.14 - 16:13:07GMT 
> -
>
> Falafel is doing nothing. If a single guy can make the protocol not work, 
> then the protocol is shitty from the start and we need to write a new one.
>
> - Anonymous - 2009.04.14 - 20:46:59GMT -
>
> The only shit around here is spewing from the mouths of those who don't 
> understand how it works. ?No one can stop you from seeing what you want to 
> see. ?Anyone who tells you otherwise is spreading misinformation.
>
> - Luke771 at CH4jCmDc27eeqm9Cw_WvJu+COIM - 2009.05.04 - 01:01:46GMT 
> -
>
>
> No one can really censor FMS alright, BUT there IS a problem with those 
> 'censored trust lists' anyway.
> The existance of censored trust lists forces users to actively maintain their 
> own trust lists, the WoT wont work 'on its own' as it would if everyone used 
> it the way it's supposed to.
>
> Let me try to explain: if everyone used wot to block flood attacks and 
> nothing else, new users wouldnt need to try and find out which trust lists 
> are 'good', they wouldnt need to work on thir trust lists for hours every 
> day, try to spot censors or "guys who wont block pedos", they could simply 
> use FMS and occasianlly set a high trust for someone they actually trust, or 
> lower the trust for someone they caught spamming
>
> But the current situation makes FMS a pain in the ass. Users have to work on 
> your trust lists regularly, and new users risk (and probably do) to have some 
> of the content blocked by some censor because the guy posted one message on a 
> board that the censor found 'immoral'.
>
> It may take time until the new user figures out which trust lists to use, and 
> there's a very real risk that he would think that it isnt worth the hassle 
> and give up on FMS completely.
> I did that, others did that, and more will.
>
> THAT is the real problem with the Little Brothers, not their non-existent 
> ability to censor content. they cant censor anything and they know it. But 
> they can and do make FMS a pain in the ass to use.
>
> Another problem is that, assuming that the fms community will survive (which 
> i dontthink it will), it my end up split into a number of closed 
> sub-communities that refuse to talk to each other. But this is only a guess, 
> so far. We'll have to see how it turns out.
>
> In the meantime, making FMS into a PITa has been done already, that is why 
> FMS is as good as dead, and that's why I think that invesiting develpers' 
> time and effort into WoT and Freetalk is a huge waste: FMS failed because of 
> human stupidity and arrogance, and so will Freetalk/WoT, and I really cant 
> understand why the devs cant see the obvious (or refuse to admit it)
>
> BTW, I dont hate Falafel. Hate costs energy. A lot of it.
> --
> FAFS - the Freenet Applications FreeSite
> USK at 
> ugb~uuscsidMI-Ze8laZe~o3BUIb3S50i25RIwDH99M,9T20t3xoG-dQfMO94LGOl9AxRTkaz~TykFY-voqaTQI,AQACAAE/FAFS/47/
>
> -Don't think out of the box: destroy it!-
> ___
> Devl mailing list
> Devl at freenetproject.org
> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Using standard ports of encrypted protocols

2009-05-21 Thread Florent Daigniere

Arne Babenhauserheide wrote:
> On Wednesday, 20. May 2009 18:14:53 Matthew Toseland wrote:
>> Depends on your threat model. Freenet traffic clearly doesn't look like
>> these without proper stego transport plugins, and the connections between
>> nodes definitely don't look like them, unless what you are imitating is
>> purely peer to peer, in which case you need to look at the other nodes'
>> connections as well and/or the timing. 
> 
> Is a steganography transport plugin planned? 
> 

Yes, but that's long term stuff. The important bit is the plugin system. 
Stego transports shouldn't be bundled by default otherwise they become 
part of the protocol and that defeats the purpose.

NextGen$
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Usability test results

On Friday 15 May 2009 17:05:09 Robert Hailey wrote:
> 
> On May 14, 2009, at 5:06 PM, Matthew Toseland wrote:
> 
> > On Thursday 14 May 2009 20:36:31 Robert Hailey wrote:
> >>
> >> On May 14, 2009, at 12:17 PM, Matthew Toseland wrote:
> >>
> >>> Because we were both on the same LAN, it did not connect, until I
> >>> told him to
> >>> set it to allow local addresses on that peer. There should be a
> >>> checkbox when
> >>> adding a noderef, defaulting to on, "Friend may be on the same local
> >>> network
> >>> as me" or something. (#3098)
> >>
> >> I think that it should be possible to automatically detect this.
> >> Specifically, if we detect that our peer has the same "external
> >> address" as us, try and connect locally. Is that a reliable  
> >> indicator?
> >
> > Not very (what if it changes?) ... we don't want darknet peers to  
> > cause us to
> > connect to addresses on our LAN ... otherwise the solution is simply  
> > to try
> > the local addresses included ...
> 
> I agree that we don't want to try the local addresses of ~all~ our  
> peers; local connections are in principal an exception and not cause  
> enough to be sending so much local garbage handshaking traffic (that  
> could give away a freenet node).
> 
> But I think this is the right way to go... If it is not defined for a  
> given peer (allow/disallow local connections), then we could just  
> calculate the default boolean as  
> his.extAddresses.containsAny(my.extAddresses) if it matches, then  
> there is an excellent chance of it being a local connection (99%). If  
> it changes, that's great! The decision to try local connections would  
> change too! As it's probably a laptop that has floated out of the LAN  
> (and we would want to stop sending handshakes to the local address  
> anyway). At worst we might send a few garbage handshakes to local non- 
> freenet machine until we connect to the node & find it's new external  
> address.
> 
> The reason I think this would solve the problem because (I think) the  
> principal reason that the nodes could not communicate is because the  
> gateway would have to send a packet to itself (many inexpensive or  
> firewalled ones will not).
> 
> e.g.
> internal -> firewall -> external  (generally works w/ current  
> countermeasures)
> 
> internal -->
>   firewall
> internal <--
> 
> Does not work (at least for me). So what I propose is really an  
> extension of "detecting the problem" (the gateway which has the same  
> external ip). Don't know about multihoming, but I presume that this is  
> works in the common case.

Nonetheless it is highly unreliable as a way to detect it with dynamic 
external IP address, especially given that the two nodes are unable to 
communicate by any other means.


signature.asc
Description: This is a digitally signed message part.
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] XMLLibrarian binary on downloads.freenetproject.org

On Thu, May 21, 2009 at 5:23 PM, Matthew Toseland
 wrote:
> On Thursday 21 May 2009 03:53:04 you wrote:
>> XMLLibrarian on downloads.freenetproject.org was compiled with Java 6
>> and emitting UnsupportedClassVersionError.
>> Please recompile it with Java 5 and update the binary.
>>
> It was compiled with your plugin build script iirc. Please update the build
> script for all the plugins to use java 5.

I have just updated with target="1.5" at 222d686

HOWEVER, you should always build with a 1.5 JDK.
This is the only way to ensure it does not use any Java 6 specific API
(accidentially).

--
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Usability test results

On Friday 15 May 2009 17:05:09 Robert Hailey wrote:
> 
> On May 14, 2009, at 5:06 PM, Matthew Toseland wrote:
> 
> > On Thursday 14 May 2009 20:36:31 Robert Hailey wrote:
> >>
> >> On May 14, 2009, at 12:17 PM, Matthew Toseland wrote:
> >>
> >>> Once connected to my node, it repeatedly RNFed on the top block of
> >>> TUFI.
> >>> Performance with one peer is expected to be poor, but it is worse
> >>> than IMHO
> >>> it could be. Some sort of fair sharing scheme ought to allow a
> >>> darknet peer
> >>> that isn't doing much to have a few requests accepted while we are
> >>> rejecting
> >>> tons of requests from other darknet peers and opennet peers. (#3101)
> >>
> >> I second that, but I'm not sure as to the best implementation.
> >>
> >> On the surface this appears to be the same issue as balancing local/
> >> remote requests. i.e. if your node is busy doing everyone else's  
> >> work,
> >> your requests should take clear advantage when you finally get around
> >> to clicking a link.
> >
> > Possibly. It is indeed a load balancing problem. Queueing will help,  
> > or maybe
> > simulated queueing.
> >>
> >> I think this conflicts with the current throttling mechanism; piling
> >> on requests till one or both nodes say 'enough',
> >
> > Is this how it works now?
> 
> Yep. To the best of my understanding...
> 
> Q: How do we determine if we are going to take a remote request?
> A: If there is "room" to incur it's expected bandwidth.
> 
> Premise-1: all chks transfer at an equal rate
> 
> Result-1: new transfers squeeze bandwidth from other transfers.
> Result-2: a node will accept any number of transfers until such a  
> point that all of them would go over the maximum allowed transfer time.
> 
> Effectively making every transfer to the slowest-allowed transfer (not  
> counting local traffic or non-busy nodes). This is why I advocated  
> lowering the slowest transfer time as a general speedup.

Which we tried, and it caused a massive slowDOWN. Mostly because most requests 
do not result in a transfer, so we need a substantial number of requests to 
compensate for that. The real solution is a bulk flag, but we cannot 
implement that until 0.7.5 has shipped.
> 
> >> and if we reserve
> >> some space we will not hit our bandwidth goal. Or that requests are
> >> actually "competing" like collisions on a busy ethernet channel  
> >> rather
> >> than having an order.
> >
> > Yes, it is very much like that.
> 
> Does that mean that the logical alternative is token passing?
> 
> In fact... guarantee-able request acceptance (token passing), might  
> actually be a logical prerequisite for a fair-queueing system.
> 
> Interestingly any node can measure how many requests it can accept  
> right now (for bandwidth), but only can guess as to it's peers (by  
> backoff); so then, we may well accept requests which we cannot make  
> good on, because our peers cannot accept them (ethernet collision  
> logic at every hop).

Yes. On 0.5 we tried to estimate the rate at which we could accept requests 
and publish this, but we could never take our peers' inter-request times into 
account when calculating our own without getting network collapse.

Some system involving queueing is likely the best we can achieve. Token 
passing (advertising to several nodes when we have an available slot) is 
really just an essential optimisation for queueing. But by definition 
queueing results in all requests spending longer on a hop, and some requests 
spending much longer (and perhaps timing out). Simulated queueing (randomly 
dropping requests to maintain queue lengths, but routing immediately those we 
accept) might be an alternative for lower latency at the cost of lower 
accuracy. Maximum queue times could be radically different for requests with 
and without the bulk flag.
> 
> >> One thing that I was playing around with earlier was re-factoring
> >> PacketThrottle to be viewed from the queue-side. Rather than
> >> "sendThrottledPacket" blocking till "a good time" to enqueue a  
> >> message
> >> based on the throttle, that all the packets would be serially
> >> available interleaved (e.g. PacketThrottle.getBulkPackets(n); returns
> >> the next 'n' packets).
> >
> > Good idea... I thought it was somewhat like that already? It is  
> > important in
> > some cases for it to block...
> 
> Only in that they feed an outbound message queue rather than actually  
> sending a packet. But it looks to me like a bit of cruft from a  
> previous design.
> 
> In any case, you have a design note in the comments of PacketThrottle  
> that it would be better to have a sorted list or red/black tree rather  
> than a ticket system (where all threads wakeup); maybe a new class  
> needs to be written (BulkQueue) that *only* interleaves waiters (round  
> robin?) and the packet throttle then used only for actually sending  
> packets.

Yeah...


signature.asc
Description: This is a digitally signed message part.
_

Re: [freenet-dev] Separate browser or not

Matthew Toseland skrev:
> On Sunday 17 May 2009 11:43:26 Zero3 wrote:
>> Colin Davis skrev:
>>> As implemented currently, Private browsing is all-or-nothing in 
>>> FF3.5beta4 and Safari, but Google Chrome is per-window.
 Firefox has issues with coalescing windows, no? If I run firefox with 
> command 
 line options to use one profile, it may use another if a window is 
> already 
 open, there are things like that... Is opening a window with privacy mode 
 enabled safe and reliable?
>> I guess both ways should work fine for us? We simply launch the browser 
>> with the command line arguments, and let the browser handle the 
>> window/tab management?
> 
> No, Firefox might very well end up opening a window in non-incognito mode.

Surely such bug would be fixed before the beta turns into final?

- Zero3
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Updating helper executables on Windows

Matthew Toseland skrev:
> On Sunday 17 May 2009 11:41:00 Zero3 wrote:
>> Matthew Toseland skrev:
 Detecting the version of an installed application in the launcher (at 
 least in Windows) shouldn't be a problem. It will most likely be 
 registered in the registry next to the .exe path we are checking already 
 for the individual browsers. We can also check the version info of .exes 
 as an alternative (most Windows applications are compiled with various 
 static info like version and author). The Windows launcher is already 
 running Chrome with a command line argument making it start in privacy 
 mode btw.
>>> You should prioritise Chrome with privacy mode over Firefox without it.
>> Agreed: https://bugs.freenetproject.org/view.php?id=3118.
> 
> I thought you had already done this?

At time of writing, no. But since then I managed to figure git out and 
changed it (hence the bug is now "resolved").

... which leads to another thing to consider: We need to make it 
possible to update the start.exe/stop.exe/freenetlauncher.exe files for 
existing users when new updates are made available.

The easiest way to do this right now would probably be to add them to 
the update.cmd script.

- Zero3
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Freenet 0.7 build 1210

Freenet 0.7 build 1210 is out. Sorry for the delay in announcing it. It will 
be mandatory at midnight. There was also a minor git mess relating to 
tagging - it was released from a local branch because I forgot to push before 
tagging, although it has been merged back into master now. If you are 
building from source you need to either clone the tag or do "git fetch -t 
origin" to fetch orphan tags.

Changes:
- Startup fix: you can now move the persistent temp directory, as long as you 
update freenet.ini accordingly. This is also an issue when moving the node.
- Startup fix: Deleting the persistent temp dir and moving the node failed to 
startup
- Let the node start up even if the database is unrecoverably corrupted. Tell 
the user what the situation is, and refuse to do any persistent requests or 
inserts.
- Don't commit every database job immediately, unless we need to for memory 
reasons (some job types), for UI reasons (e.g. starting a request), every 30 
seconds, or after every job if the new alwaysCommit config option is enabled. 
This should reduce disk I/O and improve performance significantly on some 
systems with big queues.
- Fix various client layer bugs, in freesite inserts and other things.
- SSK insert collision handling fix - store the data as well as forwarding it.
- Minor crypto optimisation in handling SSKs.
- First time wizard: remove the memory limit selection page, add a page to ask 
the user whether to auto-update Freenet and whether to load JSTUN and UPnP 
(this may reduce performance on a new node *slightly*, but we don't want to 
have to ask in the installer), warn the user about monthly bandwidth usage, 
always show the bandwidth and store size pages, minor fixes.
- Enable javascript support by default in fproxy, minor fixes, get rid of the 
MIME type column on the queue page in simple mode, more tolerant parsing of 
noderefs and bulk download lists.
- Fix various connection level bugs, which hopefully once everyone has 1210 
will fix the forced disconnected because not acknowledging packets bug. In 
simulation this fixes "Unmatchable packet from ", which really 
shouldn't happen!
- Minor plugin code improvements (new APIs, require XMLLibrarian version 22).
- Internal bugfix which hopefully only was breaking IPv6 address detection 
from peers.
- Internal bugfix relating to moving files, might have caused bugs in several 
places.
- Don't let default changes override the local option for whether to 
preallocate the store.
- Lots of internal cleanup and some work on the many-nodes-one-VM simulators / 
automated network tests, including a new long-term data retrievability test.

Also, the XMLLibrarian plugin now shows a search's progress without using 
javascript, and immediately from typing a search on the homepage (thanks 
mikeb). KeyExplorer 0.4 beta is out, and there has been more work on the WoT 
web of trust plugin (thanks saces). A bugfix in the UPnP plugin, and as 
previously mentioned we deployed the new windows installer (thanks Zero3).

Thanks to:
sdiz
3BUIb3S50i
platy
nextgens
saces
juiceman


signature.asc
Description: This is a digitally signed message part.
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Plugin snapshots

Please post on the list when you want me to distribute a new snapshot of a 
plugin. Thanks.


signature.asc
Description: This is a digitally signed message part.
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Updating helper executables on Windows

On Thu, May 21, 2009 at 6:58 AM, Zero3  wrote:
> Matthew Toseland skrev:
>> On Sunday 17 May 2009 11:41:00 Zero3 wrote:
>>> Matthew Toseland skrev:
> Detecting the version of an installed application in the launcher (at
> least in Windows) shouldn't be a problem. It will most likely be
> registered in the registry next to the .exe path we are checking already
> for the individual browsers. We can also check the version info of .exes
> as an alternative (most Windows applications are compiled with various
> static info like version and author). The Windows launcher is already
> running Chrome with a command line argument making it start in privacy
> mode btw.
 You should prioritise Chrome with privacy mode over Firefox without it.
>>> Agreed: https://bugs.freenetproject.org/view.php?id=3118.
>>
>> I thought you had already done this?
>
> At time of writing, no. But since then I managed to figure git out and
> changed it (hence the bug is now "resolved").
>
> ... which leads to another thing to consider: We need to make it
> possible to update the start.exe/stop.exe/freenetlauncher.exe files for
> existing users when new updates are made available.
>
> The easiest way to do this right now would probably be to add them to
> the update.cmd script.
>
> - Zero3
> ___
> Devl mailing list
> Devl@freenetproject.org
> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
>

I would be happy to do this, however I will need a defined directory
structure on the download site, with known file names.  Like we have
the .url link for the freenet.jar.  I believe I can use the .sha1 file
to check for updates if you want to have a static name. ie
wrapper_win32x86.exe etc.  Also I would prefer to not have them inside
a zip unless we have have a built-in unzipping program in Windows I
can reliably call by command line.  Otherwise we will have to bundle
yet another third party utility.
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Separate browser or not

2009-05-21 Thread Colin Davis

As an aside, Matthew had asked in the past about reducing the number of
connections from the browser to the node.

Digg's new library may be able to assist- It breaks images into data uris,
and then inlines them.

Even if Freenet doesn't want to use the library, inlining images as Data
URIs may improve load times. Just a thought.
-CPD


http://ajaxian.com/archives/digg-shows-multipart-xmlhttprequest-prototype


___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Updating helper executables on Windows

2009-05-21 Thread Robert Hailey


On May 21, 2009, at 11:32 AM, Juiceman wrote:

> On Thu, May 21, 2009 at 6:58 AM, Zero3   
> wrote:
>> Matthew Toseland skrev:
>>> On Sunday 17 May 2009 11:41:00 Zero3 wrote:
 Matthew Toseland skrev:
>> Detecting the version of an installed application in the  
>> launcher (at
>> least in Windows) shouldn't be a problem. It will most likely be
>> registered in the registry next to the .exe path we are  
>> checking already
>> for the individual browsers. We can also check the version info  
>> of .exes
>> as an alternative (most Windows applications are compiled with  
>> various
>> static info like version and author). The Windows launcher is  
>> already
>> running Chrome with a command line argument making it start in  
>> privacy
>> mode btw.
> You should prioritise Chrome with privacy mode over Firefox  
> without it.
 Agreed: https://bugs.freenetproject.org/view.php?id=3118.
>>>
>>> I thought you had already done this?
>>
>> At time of writing, no. But since then I managed to figure git out  
>> and
>> changed it (hence the bug is now "resolved").
>>
>> ... which leads to another thing to consider: We need to make it
>> possible to update the start.exe/stop.exe/freenetlauncher.exe files  
>> for
>> existing users when new updates are made available.
>>
>> The easiest way to do this right now would probably be to add them to
>> the update.cmd script.
>>
>> - Zero3
>>
>
> I would be happy to do this, however I will need a defined directory
> structure on the download site, with known file names.  Like we have
> the .url link for the freenet.jar.  I believe I can use the .sha1 file
> to check for updates if you want to have a static name. ie
> wrapper_win32x86.exe etc.  Also I would prefer to not have them inside
> a zip unless we have have a built-in unzipping program in Windows I
> can reliably call by command line.  Otherwise we will have to bundle
> yet another third party utility.

If it helps, my understanding is that zip & jar are cross compatible.  
Or more specifically,
that a jar is a zip file with extra flags and a manifest file.

--
Robert Hailey

___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Separate browser or not

On Thursday 21 May 2009 18:54:38 Colin Davis wrote:
> As an aside, Matthew had asked in the past about reducing the number of
> connections from the browser to the node.
> 
> Digg's new library may be able to assist- It breaks images into data uris,
> and then inlines them.
> 
> Even if Freenet doesn't want to use the library, inlining images as Data
> URIs may improve load times. Just a thought.
> -CPD

Well it's not the stuff that we have already fetched that slows things down, 
it's the images we have to wait for.
> 
> http://ajaxian.com/archives/digg-shows-multipart-xmlhttprequest-prototype


signature.asc
Description: This is a digitally signed message part.
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Separate browser or not

On Thursday 21 May 2009 11:54:32 Zero3 wrote:
> Matthew Toseland skrev:
> > On Sunday 17 May 2009 11:43:26 Zero3 wrote:
> >> Colin Davis skrev:
> >>> As implemented currently, Private browsing is all-or-nothing in 
> >>> FF3.5beta4 and Safari, but Google Chrome is per-window.
>  Firefox has issues with coalescing windows, no? If I run firefox with 
> > command 
>  line options to use one profile, it may use another if a window is 
> > already 
>  open, there are things like that... Is opening a window with privacy 
mode 
>  enabled safe and reliable?
> >> I guess both ways should work fine for us? We simply launch the browser 
> >> with the command line arguments, and let the browser handle the 
> >> window/tab management?
> > 
> > No, Firefox might very well end up opening a window in non-incognito mode.
> 
> Surely such bug would be fixed before the beta turns into final?

I have no idea, but it does exactly the above with profiles sometimes iirc.


signature.asc
Description: This is a digitally signed message part.
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Why WoTs won't work....

2009-05-21 Thread gulli

Interesting discussion from Frost, especially the last post at the bottom. Its 
about WoTs in general and why they won't work.



- hahaha...@yle3zhs5lkiwe3fdjyqlcf5+rka - 2009.04.05 - 02:28:11GMT -

I had to forward this one here.

--- jezreel℺X~GLTTHo9aaYtIpGT6OOyBMMFwl3b8LwFu6TUw9Q82E sent via FMS on 
2009-04-05 at 01:31:54GMT ---

Probably not an amazing subject, but FMS is so dead lately so what the 
hell.  Falafel, why do some of the folks posting to Frost hate you so 
much?  In particular Luke771 and VolodyA.  You generally seem like a 
nice identity so I'm just curious.
-- 
jezr...@pbxwgrdegrigwuteoz3tc6cfla2xu3trmi2tgr2enfrvi4bxkzlectshfvyw2wcxkrffslccijku4z2om5gtoojrpzdfcolkovtdawjuifigkrcqjbevsvrnla2xotcdpfvw6lkmkzzsyqkrifbucqkf.freemail

;))

- VolodyA! V a...@r0pa7z7ja1haf2xttt7aklre+yw - 2009.04.11 - 
12:11:26GMT -

I should point out i do not hate falafel, i do not know him. I do hate what he 
is doing to Freenet, however. If he was to stop supporting intruduction of 
censorship on Freenet i would not say anything bad about him.

In fact i tend to agree with much of what he has to say on other subjects.

-- 
May all the sentient beings benefit from our conversation.

- denmin...@dlkkaikia79j4ovpbgfk4znh25y - 2009.04.14 - 16:13:07GMT -

Falafel is doing nothing. If a single guy can make the protocol not work, then 
the protocol is shitty from the start and we need to write a new one.

- Anonymous - 2009.04.14 - 20:46:59GMT -

The only shit around here is spewing from the mouths of those who don't 
understand how it works.  No one can stop you from seeing what you want to see. 
 Anyone who tells you otherwise is spreading misinformation.

- luke...@ch4jcmdc27eeqm9cw_wvju+coim - 2009.05.04 - 01:01:46GMT -


No one can really censor FMS alright, BUT there IS a problem with those 
'censored trust lists' anyway.
The existance of censored trust lists forces users to actively maintain their 
own trust lists, the WoT wont work 'on its own' as it would if everyone used it 
the way it's supposed to.

Let me try to explain: if everyone used wot to block flood attacks and nothing 
else, new users wouldnt need to try and find out which trust lists are 'good', 
they wouldnt need to work on thir trust lists for hours every day, try to spot 
censors or "guys who wont block pedos", they could simply use FMS and 
occasianlly set a high trust for someone they actually trust, or lower the 
trust for someone they caught spamming

But the current situation makes FMS a pain in the ass. Users have to work on 
your trust lists regularly, and new users risk (and probably do) to have some 
of the content blocked by some censor because the guy posted one message on a 
board that the censor found 'immoral'.

It may take time until the new user figures out which trust lists to use, and 
there's a very real risk that he would think that it isnt worth the hassle and 
give up on FMS completely.
I did that, others did that, and more will.

THAT is the real problem with the Little Brothers, not their non-existent 
ability to censor content. they cant censor anything and they know it. But they 
can and do make FMS a pain in the ass to use.

Another problem is that, assuming that the fms community will survive (which i 
dontthink it will), it my end up split into a number of closed sub-communities 
that refuse to talk to each other. But this is only a guess, so far. We'll have 
to see how it turns out.

In the meantime, making FMS into a PITa has been done already, that is why FMS 
is as good as dead, and that's why I think that invesiting develpers' time and 
effort into WoT and Freetalk is a huge waste: FMS failed because of human 
stupidity and arrogance, and so will Freetalk/WoT, and I really cant understand 
why the devs cant see the obvious (or refuse to admit it)

BTW, I dont hate Falafel. Hate costs energy. A lot of it.
-- 
FAFS - the Freenet Applications FreeSite
u...@ugb~uuscsidmi-ze8laze~o3buib3s50i25riwdh99m,9T20t3xoG-dQfMO94LGOl9AxRTkaz~TykFY-voqaTQI,AQACAAE/FAFS/47/

-Don't think out of the box: destroy it!-
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] update.cmd in java-based installer

Are all the changes made to update.cmd compatible with the java-based 
installer? For example, juiceman removed a bunch of commands relating to 
start.cmd; certainly I haven't tested my changes with the java-based 
installer.

Also, do we want to get rid of Windows support from the java-based installer? 
The website always shows the exe for windows users now...

Oh, and you didn't write version 3.0 - at least not all of it. :)


signature.asc
Description: This is a digitally signed message part.
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Why WoTs won't work....

On Sun, May 10, 2009 at 12:57 AM,   wrote:
> Interesting discussion from Frost, especially the last post at the bottom. 
> Its about WoTs in general and why they won't work.
>

There are no (new) interesting bits.
The pain is well known among developers, repeating/explaining won't change it.

If you want to have an alternative, do it with a *FULL PROPOSAL*
(with the all advantage / disadvantage listed; impact on the network;
etc...), not just
"Hey! Why not do this " ...  This is wasting everybody's energy.

___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] update.cmd in java-based installer