[freenet-dev] Infocalypse feedback (Mercurial over Freenet)
On Monday 11 May 2009 20:20:49 Arne Babenhauserheide wrote: > Hi, > > I just want to provide some feedback on Infocalypse - I hope this is the right > place, since it's an application on freenet. > > I tried it a bit and I really like it. > > I didn't yet try inserting a big repo, but it works pretty well for the > smaller repositories I tested (which are also available in the web). > > The only problem I still have is that keeping the uris in the central config > file didn't work (all paths in the config file were lowercase while the real > paths aren't - maybe that's connected to the issue). > > Different from simply uploading the full hg repo into freenet, infocalypse > also feels quite fast. If you want to test it, here's my repository checkout > uri: > > USK at ko8wbLzQDQc~1gmMEvO8ewpcH0yQKDExMs4kpFDoeOQ,0KpmSJb35Q6UwgdhAJpTMH0jnjUriv7DtaFtTq3dlRI,AQACAAE/test.R1/0 > > The mirror of freenet staging worked, too. > > The initial pull took about an hour, and it succeeded, though I got the log > output "GetFailed". > Most recent revision was 13919 > user:Daniel Cheng (???) > date:Mon May 11 10:48:31 2009 +0800 > summary: Remove unused variable (leftovers of r27142) Woah, nice, dogfood at last! :) > > Best wishes, > Arne > > Besides: I use a live build of Mercurial (directly from the main repo), and > infocalypse works. -- 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/20090511/09d8dc9a/attachment.pgp>
[freenet-dev] Missing statistics
On Monday 11 May 2009 18:15:52 Robert Hailey wrote: > > Perhaps I am going crazy, but I seem to recall a statistic with > regards to the end-result of requests (when Matthew had me tracking > down the FATAL_TIMEOUT) errors. > > Something like this: > +---+ > | SSK final states| > +-+-+ > | FATAL_TIMEOUT | 12% | > | REQUEST_TIMEOUT | 6% | > | SUCCESS | 2% | > +-+-+ > > Where is it? has it ever existed on the stats page? > > Surely if 80-95% of requests are failing, we should know why they are > failing... right? They are mostly failing because of DNF because SSK requests are all polling nonexistent keys, surely? We had such a table for swaps, and we have something similar for backoff reasons, but I don't think we have anything like that for requests. -- 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/20090511/3c5e4350/attachment.pgp>
[freenet-dev] Infocalypse feedback (Mercurial over Freenet)
Hi, I just want to provide some feedback on Infocalypse - I hope this is the right place, since it's an application on freenet. I tried it a bit and I really like it. I didn't yet try inserting a big repo, but it works pretty well for the smaller repositories I tested (which are also available in the web). The only problem I still have is that keeping the uris in the central config file didn't work (all paths in the config file were lowercase while the real paths aren't - maybe that's connected to the issue). Different from simply uploading the full hg repo into freenet, infocalypse also feels quite fast. If you want to test it, here's my repository checkout uri: USK at ko8wbLzQDQc~1gmMEvO8ewpcH0yQKDExMs4kpFDoeOQ,0KpmSJb35Q6UwgdhAJpTMH0jnjUriv7DtaFtTq3dlRI,AQACAAE/test.R1/0 The mirror of freenet staging worked, too. The initial pull took about an hour, and it succeeded, though I got the log output "GetFailed". Most recent revision was 13919 user:Daniel Cheng (???) date:Mon May 11 10:48:31 2009 +0800 summary: Remove unused variable (leftovers of r27142) Best wishes, Arne Besides: I use a live build of Mercurial (directly from the main repo), and infocalypse works. --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- - singing a part of the history of free software - http://infinite-hands.draketo.de -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20090511/bdd8785a/attachment.pgp>
[freenet-dev] Hashcash-based global introduction? was Re: Question about an important design decision of the WoT plugin
Luke771 schrieb: > I can't comment on the technical part because I wouldnt know what im > talking about. > However, I do like the 'social' part (being able to see an identity even > if the censors mark it down it right away as it's created) "The censors"? There is no central authority to censor people. "Censors" can only censor the web-of-trust for those people that trust them and which want to see a censored net. You cant and should not prevent them from this, if they want it. > On the other hand tho, if a user knows that it will take his system > three days or a week to finish the job, he may decide to do it anyway. > I mean the real problem is 'not knowing' that it may take a long time. > A user that starts a process and doesnt see any noticeable progress > would probably abort, but the same user would let it run to completion > if he expects it to take several days. Why use this sort of announcement, if it takes several days? Announcement over captchas takes only around 24 hours, which is faster and needs less resources. So i dont see any real reason for hashcash-introductions. -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 315 bytes Desc: OpenPGP digital signature URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20090511/c58081a1/attachment.pgp>
[freenet-dev] No-WoT messages for new ID's [was: Hashcash, was: Question]
Luke771 schrieb: >>> Also, what about an option for ignoring the WoT's opinion until a newbie >>> has posted at least N messages, or M time has elapsed? >>> >> Sounds like a better idea than hash cash. >> >> > great idea > it would solve the problem in a simple elegant way, and without all the > hashcash problems > ...but I usually miss some very obvious point: what am I missing now? > > BTW, make it N messages only, no elapsed time: if an ID isnt sending any > messages, it surely isn't flooding anything > > also IMHO the no-WoT messages should be relatively many, like 75 or 100. > This would ensure that virtually 'everyone' has had a chance to see at > least one message from that ID (I'm thinking of an ID that sends lots of > messages to a board that has relatively few subscribers) > The WoT is the basic trust calculation, why depend the option on Freetalk? If it really gets that central role that i hear, then it will not only be used for Freetalk, but also for filesharing, freesite publishing and more. Now if you only depend on the messages or the time, the user could do any bad thing via freesites or filesharing for an infinite abmount of time and would still be visible. So imho also no real option in the future. -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 315 bytes Desc: OpenPGP digital signature URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20090511/d567ca73/attachment.pgp>
[freenet-dev] Missing statistics
On May 11, 2009, at 3:23 PM, Matthew Toseland wrote: > On Monday 11 May 2009 18:15:52 Robert Hailey wrote: >> >> Perhaps I am going crazy, but I seem to recall a statistic with >> regards to the end-result of requests (when Matthew had me tracking >> down the FATAL_TIMEOUT) errors. >> >> Something like this: >> +---+ >> | SSK final states| >> +-+-+ >> | FATAL_TIMEOUT | 12% | >> | REQUEST_TIMEOUT | 6% | >> | SUCCESS | 2% | >> +-+-+ >> >> Where is it? has it ever existed on the stats page? >> >> Surely if 80-95% of requests are failing, we should know why they are >> failing... right? > > They are mostly failing because of DNF because SSK requests are all > polling > nonexistent keys, surely? That makes sense, but is it also DNF for CHK requests? Surely the vast majority of CHK requests correspond to data which has been inserted, and such a table might show the effectiveness of bloom filter sharing with a new final state "BLOOM_FOUND" (or the like). > We had such a table for swaps, and we have something similar for > backoff > reasons, but I don't think we have anything like that for requests. I presume what I was looking at much earlier was on the peer list for backoff, thanks. -- Robert Hailey
[freenet-dev] Missing statistics
Perhaps I am going crazy, but I seem to recall a statistic with regards to the end-result of requests (when Matthew had me tracking down the FATAL_TIMEOUT) errors. Something like this: +---+ | SSK final states| +-+-+ | FATAL_TIMEOUT | 12% | | REQUEST_TIMEOUT | 6% | | SUCCESS | 2% | +-+-+ Where is it? has it ever existed on the stats page? Surely if 80-95% of requests are failing, we should know why they are failing... right? -- Robert Hailey -- next part -- An HTML attachment was scrubbed... URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20090511/8d4e394f/attachment.html>
[freenet-dev] Current uservoice top 5
On May 10, 2009, at 2:50 PM, Arne Babenhauserheide wrote: > Am Mittwoch 06 Mai 2009 00:23:54 schrieb Matthew Toseland: >> Isn't using a reasonably low scheduling priority enough? And we >> already do >> that! > > Not really, since I can't disable it (when I want full speed), and > it sadly > doesn't work really well for memory consumption. > > I'd like an option to have freenet go inactive as soon as the system > load gets > too high. It will lose connections anyway (low scheduling priority > leads to > far too high answer-times), so it could just explicitely take a > break until my > system runs well again. > > But I don't want to have that all the time. When I compile something > in the > background, I want freenet to take predecence (that's already well > covered > with the low scheduling priority, though). > > Best wishes, > Arne AFAIK this is a common design in other systems. Sendmail, for example, will not accept any network connections if the system's load is over some constant. I suppose the real issue would be detecting that in a platform- independent way (i.e. adding more JNI???). -- Robert Hailey
[freenet-dev] No-WoT messages for new ID's [was: Hashcash, was: Question]
>> Also, what about an option for ignoring the WoT's opinion until a newbie >> has posted at least N messages, or M time has elapsed? >> > > Sounds like a better idea than hash cash. > > great idea it would solve the problem in a simple elegant way, and without all the hashcash problems ...but I usually miss some very obvious point: what am I missing now? BTW, make it N messages only, no elapsed time: if an ID isnt sending any messages, it surely isn't flooding anything also IMHO the no-WoT messages should be relatively many, like 75 or 100. This would ensure that virtually 'everyone' has had a chance to see at least one message from that ID (I'm thinking of an ID that sends lots of messages to a board that has relatively few subscribers)
[freenet-dev] Hashcash-based global introduction? was Re: Question about an important design decision of the WoT plugin
Matthew Toseland wrote: > As a parallel option for introduction, a hashcash-protected global > announcement queue? > > Say KSK,23 at blah is a KSK protected by hashcash (this key type is > implementible, the catch is that you may get a collision and then you have to > find another slot and recompute). > > Then as an opt-in, and with a configurable hashcash strength, WoT nodes could > poll a single global introduction queue. They would announce which strength > queues they poll. > > This would ensure that everyone who wants to can see every new identity as it > is announced, and form their own opinion of it. > > When it gets spammed, the hash strength can be increased. Obviously hashcash > is not a real solution on its own. > > Would this satisfy the anti-WoT-censorship folk, or at least appease them to > some degree? > > Also, it would cut the time taken to get announced: once the hashcash is > solved and the key posted, we don't need to wait 24 hours for an > acknowledgement. > > Drawbacks: > - Excludes users with slow systems. > - Limited deterrent to a determined attacker. > - Might need native hashcash cracking libraries? OTOH the hashes are > implemented in native code anyway by the JVM, so maybe not. > > Advantages: > - With the current system, if an identity is marked as spam early on, many > people won't see it. Whereas if you can announce to a large number of people > at once, and have each evaluate your posts individually, this may avoid some > of the effects the anti-wot-censorship lobby are complaining about. > - Useful emergency fallback should the captchas be broken. > > Sensible? Stupid? > > Also, what about an option for ignoring the WoT's opinion until a newbie has > posted at least N messages, or M time has elapsed? > > I can't comment on the technical part because I wouldnt know what im talking about. However, I do like the 'social' part (being able to see an identity even if the censors mark it down it right away as it's created) As for the two main problems, I realize that it wouldn't help against a powerful attacker , and discriminating against users who have cheap/old systems IS a problem, especially considering that such systems are relatively common in the places where Freenet is most needed. On the other hand tho, if a user knows that it will take his system three days or a week to finish the job, he may decide to do it anyway. I mean the real problem is 'not knowing' that it may take a long time. A user that starts a process and doesnt see any noticeable progress would probably abort, but the same user would let it run to completion if he expects it to take several days. Another problem is: would a low-end system still be usable during the process? an operation that takes 6 days to complete but still leaves the box usable for, say surfing the web and read/write e-mail, would be way better than having the same operation complete in 2 days but leaving the user unable to surf, read, etc. OK, I cut it here before I say _too_ many stupid things. Thx for addressing this problem, I appreciate that.
Re: [freenet-dev] No-WoT messages for new ID's [was: Hashcash, was: Question]
Luke771 schrieb: Also, what about an option for ignoring the WoT's opinion until a newbie has posted at least N messages, or M time has elapsed? Sounds like a better idea than hash cash. great idea it would solve the problem in a simple elegant way, and without all the hashcash problems ...but I usually miss some very obvious point: what am I missing now? BTW, make it N messages only, no elapsed time: if an ID isnt sending any messages, it surely isn't flooding anything also IMHO the no-WoT messages should be relatively many, like 75 or 100. This would ensure that virtually 'everyone' has had a chance to see at least one message from that ID (I'm thinking of an ID that sends lots of messages to a board that has relatively few subscribers) The WoT is the basic trust calculation, why depend the option on Freetalk? If it really gets that central role that i hear, then it will not only be used for Freetalk, but also for filesharing, freesite publishing and more. Now if you only depend on the messages or the time, the user could do any bad thing via freesites or filesharing for an infinite abmount of time and would still be visible. So imho also no real option in the future. signature.asc Description: OpenPGP digital signature ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Hashcash-based global introduction? was Re: Question about an important design decision of the WoT plugin
Luke771 schrieb: I can't comment on the technical part because I wouldnt know what im talking about. However, I do like the 'social' part (being able to see an identity even if the censors mark it down it right away as it's created) The censors? There is no central authority to censor people. Censors can only censor the web-of-trust for those people that trust them and which want to see a censored net. You cant and should not prevent them from this, if they want it. On the other hand tho, if a user knows that it will take his system three days or a week to finish the job, he may decide to do it anyway. I mean the real problem is 'not knowing' that it may take a long time. A user that starts a process and doesnt see any noticeable progress would probably abort, but the same user would let it run to completion if he expects it to take several days. Why use this sort of announcement, if it takes several days? Announcement over captchas takes only around 24 hours, which is faster and needs less resources. So i dont see any real reason for hashcash-introductions. signature.asc Description: OpenPGP digital signature ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Current uservoice top 5
On May 10, 2009, at 2:50 PM, Arne Babenhauserheide wrote: Am Mittwoch 06 Mai 2009 00:23:54 schrieb Matthew Toseland: Isn't using a reasonably low scheduling priority enough? And we already do that! Not really, since I can't disable it (when I want full speed), and it sadly doesn't work really well for memory consumption. I'd like an option to have freenet go inactive as soon as the system load gets too high. It will lose connections anyway (low scheduling priority leads to far too high answer-times), so it could just explicitely take a break until my system runs well again. But I don't want to have that all the time. When I compile something in the background, I want freenet to take predecence (that's already well covered with the low scheduling priority, though). Best wishes, Arne AFAIK this is a common design in other systems. Sendmail, for example, will not accept any network connections if the system's load is over some constant. I suppose the real issue would be detecting that in a platform- independent way (i.e. adding more JNI???). -- Robert Hailey ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
[freenet-dev] Missing statistics
Perhaps I am going crazy, but I seem to recall a statistic with regards to the end-result of requests (when Matthew had me tracking down the FATAL_TIMEOUT) errors. Something like this: +---+ | SSK final states| +-+-+ | FATAL_TIMEOUT | 12% | | REQUEST_TIMEOUT | 6% | | SUCCESS | 2% | +-+-+ Where is it? has it ever existed on the stats page? Surely if 80-95% of requests are failing, we should know why they are failing... right? -- Robert Hailey ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
[freenet-dev] Infocalypse feedback (Mercurial over Freenet)
Hi, I just want to provide some feedback on Infocalypse - I hope this is the right place, since it's an application on freenet. I tried it a bit and I really like it. I didn't yet try inserting a big repo, but it works pretty well for the smaller repositories I tested (which are also available in the web). The only problem I still have is that keeping the uris in the central config file didn't work (all paths in the config file were lowercase while the real paths aren't - maybe that's connected to the issue). Different from simply uploading the full hg repo into freenet, infocalypse also feels quite fast. If you want to test it, here's my repository checkout uri: u...@ko8wblzqdqc~1gmmevo8ewpch0yqkdexms4kpfdoeoq,0KpmSJb35Q6UwgdhAJpTMH0jnjUriv7DtaFtTq3dlRI,AQACAAE/test.R1/0 The mirror of freenet staging worked, too. The initial pull took about an hour, and it succeeded, though I got the log output GetFailed. Most recent revision was 13919 user:Daniel Cheng (???) j16s...@freenetproject.org date:Mon May 11 10:48:31 2009 +0800 summary: Remove unused variable (leftovers of r27142) Best wishes, Arne Besides: I use a live build of Mercurial (directly from the main repo), and infocalypse works. --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- - singing a part of the history of free software - http://infinite-hands.draketo.de 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] Missing statistics
On Monday 11 May 2009 18:15:52 Robert Hailey wrote: Perhaps I am going crazy, but I seem to recall a statistic with regards to the end-result of requests (when Matthew had me tracking down the FATAL_TIMEOUT) errors. Something like this: +---+ | SSK final states| +-+-+ | FATAL_TIMEOUT | 12% | | REQUEST_TIMEOUT | 6% | | SUCCESS | 2% | +-+-+ Where is it? has it ever existed on the stats page? Surely if 80-95% of requests are failing, we should know why they are failing... right? They are mostly failing because of DNF because SSK requests are all polling nonexistent keys, surely? We had such a table for swaps, and we have something similar for backoff reasons, but I don't think we have anything like that for requests. 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] Infocalypse feedback (Mercurial over Freenet)
On Monday 11 May 2009 20:20:49 Arne Babenhauserheide wrote: Hi, I just want to provide some feedback on Infocalypse - I hope this is the right place, since it's an application on freenet. I tried it a bit and I really like it. I didn't yet try inserting a big repo, but it works pretty well for the smaller repositories I tested (which are also available in the web). The only problem I still have is that keeping the uris in the central config file didn't work (all paths in the config file were lowercase while the real paths aren't - maybe that's connected to the issue). Different from simply uploading the full hg repo into freenet, infocalypse also feels quite fast. If you want to test it, here's my repository checkout uri: u...@ko8wblzqdqc~1gmmevo8ewpch0yqkdexms4kpfdoeoq,0KpmSJb35Q6UwgdhAJpTMH0jnjUriv7DtaFtTq3dlRI,AQACAAE/test.R1/0 The mirror of freenet staging worked, too. The initial pull took about an hour, and it succeeded, though I got the log output GetFailed. Most recent revision was 13919 user:Daniel Cheng (???) j16s...@freenetproject.org date:Mon May 11 10:48:31 2009 +0800 summary: Remove unused variable (leftovers of r27142) Woah, nice, dogfood at last! :) Best wishes, Arne Besides: I use a live build of Mercurial (directly from the main repo), and infocalypse works. 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] Missing statistics
On May 11, 2009, at 3:23 PM, Matthew Toseland wrote: On Monday 11 May 2009 18:15:52 Robert Hailey wrote: Perhaps I am going crazy, but I seem to recall a statistic with regards to the end-result of requests (when Matthew had me tracking down the FATAL_TIMEOUT) errors. Something like this: +---+ | SSK final states| +-+-+ | FATAL_TIMEOUT | 12% | | REQUEST_TIMEOUT | 6% | | SUCCESS | 2% | +-+-+ Where is it? has it ever existed on the stats page? Surely if 80-95% of requests are failing, we should know why they are failing... right? They are mostly failing because of DNF because SSK requests are all polling nonexistent keys, surely? That makes sense, but is it also DNF for CHK requests? Surely the vast majority of CHK requests correspond to data which has been inserted, and such a table might show the effectiveness of bloom filter sharing with a new final state BLOOM_FOUND (or the like). We had such a table for swaps, and we have something similar for backoff reasons, but I don't think we have anything like that for requests. I presume what I was looking at much earlier was on the peer list for backoff, thanks. -- Robert Hailey ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] New Windows update script, please commit
On Friday 08 May 2009 19:06:18 Zero3 wrote: Matthew Toseland skrev: On Friday 08 May 2009 12:40:32 Zero3 wrote: Matthew Toseland skrev: On Tuesday 20 January 2009 03:18:07 Juiceman wrote: On Fri, Jan 16, 2009 at 5:46 AM, Zero3 wrote: Juiceman skrev: Here is a patch for a new version of the Windows update script. Please commit since that svn directory is restricted. I've tested it extensively on my XP machine. This should handle the new installer start/stop.exe while still being compatible with current installs. It will need to be made to handle the new node service ID the new installer creates. It also still needs some Vista functionality. Here is a further revision of the update script. Mostly error handling, beautification. Please commit. I have applied this for the new wininstaller. Is it 100% Vista compatible? In particular, will it RunAs itself in order to self-escalate on Vista? Note that the update.cmd script doesn't need to (and wouldn't even be able to) escalate itself. It should have write access to the files already (inherited from the user running the script), and the start/stop scripts handle escalation themselves. So it should just work? Unless the user runs it from a user other than the one they installed as? I thought we created a user for Freenet, are the files writable by both the installing user and the freenet user? I haven't had a chance to test it myself then. Juiceman knows best what works and what doesn't (yet). (We discussed what things that needed to change to support both types of installations a while ago.) You need admin privs to install Freenet. As any admin by default will have readwrite access to program files, any admin (including the installing one) should be able to use the update.cmd script. Normal users will not have access to do that (which they shouldn't...) The custom freenet user also has full access to the files to allow Freenet to update itself (but the update.cmd script is run as the executing user!). Btw., did you remember to add the update.cmd to src_freenetinstaller/FreenetInstaller_Include_Files.inc? It isn't included in the .exe you linked to. I have now. :| New prototype wininstaller released. 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] Please help us test the new wininstaller (Vista users especially welcome)
On Friday 08 May 2009 15:12:33 gh...@hushmail.com wrote: Both installers were from toad's links yesterday. One earlier in the day and the second around four hours later (with a slightly different file size). Here is the MD5 generated on both files. a8f88c158cc3927cdc786b67150b86f9 and 4fb8e9ff969d7c2b0575aa370874cf89. I'm more than happy to give it another go or two or three. Once I've had a bit more coffee... New version, should include update.cmd: 8854028 2009-05-11 23:54 FreenetInstaller-1209.exe md5: 23e1b4ef70b1bd35ba2fc32fbc54637f sha256: 00461dd83d9b0370d9f59fabe00168966ef5e6c5ad2d6b588a4d5f3036b304aa 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] file queue
Who created this bugtracker category? What is its purpose, how is it different from fred-client-layer? 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] Windows installer category on the bug tracker
On Friday 08 May 2009 19:50:45 Zero3 wrote: Hey Now that bugs regarding my installer are being submitted to the bug tracker, it would be really nice with a Windows Installer category with me being assigned/monitored/something to all bugs by default, so I get notified when something is posted - especially in these months I'm in the military and don't have enough time to keep up-to-date with every single bug/mail/commit/etc. :). Done. wininstaller, will auto-assign bugs to you. 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] Please help us test the new wininstaller (Vista users especially welcome)
On Sunday 10 May 2009 00:54:48 Luke771 wrote: Zero3 wrote: gh...@hushmail.com skrev: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 08 May 2009 05:51:58 -0600 Zero3 ze...@zerosplayground.dk wrote: Hey You seem to have tested the *old* Windows installer, which unfortunately doesn't work on Vista. If you can, please test the new one from the link from toad's mail :). - Zero3 The good: Under Vista64 the installer does produce a functioning node. Great! What about the problems you mentioned in your previous mail? (I just replied to those in another message) The bad: Wrapper.conf seems to not get an update from wizard mode. Maximum memory was still default of 192 and not the 512 I had set. If I do a new install and configure it manually rather than using the wizard, after a node reboot I can see the changes. A reboot after the wizard install does not. We already have a couple of bugs reported in that area. You probably hit one of them: https://bugs.freenetproject.org/view.php?id=2500 https://bugs.freenetproject.org/view.php?id=2573 The unfortunate: The installer does not see existing 64 bit java installs under the Vista OS. The option to install java only installs the 32 bit java. This works and allows the install to complete but now you have both 32/64 bit jre's. OK - see previous mail. The messy workaround: After the node is installed and working, shut it down. Uninstall the 32 bit java. Start-run-cmd, then cd to %windir%\syswow64. There create three symbolic links to the 64 bit java in %windir%\system32. mklink java.exe ..\system32\java.exe mklink javaw.exe ..\system32\javaw.exe mklinik javaws.exe ..\system32\javaws.exe Restart the node. (I believe these links will break if java is ever updated and need to be recreated manually at that point in time.) Thoughts: The installer cannot be spoofed by the symbolic links alone, only after a completed install is done can the freenet software be ran under a 64 bit java. Could the installer be revised to detect a 64 bit OS? Also adjusting for 64 bit java detection and it's possible download accordingly? The options to make changes to the wrapper don't happen when using the wizard. Can this be fixed or should it be removed and then after the node is up remind the user to adjust memory usage if he/she wants and then to reboot the node. As previously mentioned: Does anyone know how to handle this 32-bit vs. 64-bit stuff? What to do? (I have no idea, and nothing to test 64-bit stuff on). OK, I _know_ I'm gonna say something stupid but I have to, so here it goes: Joe Cynical suggests: the average user probably wouldnt be bothered by having both a 32-bit and a 64-bit JRE's, especially if told that he's supposed to. Make simple install just install JRE automatically and expert mode let the user manually give the path to his JRE. IMHO it should work in any case. But it does, so there is no great urgency to fix 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] Please help us test the new wininstaller (Vista users especially welcome)
On Friday 08 May 2009 19:15:46 gh...@hushmail.com wrote: On Fri, 08 May 2009 05:51:58 -0600 Zero3 ze...@zerosplayground.dk wrote: Hey You seem to have tested the *old* Windows installer, which unfortunately doesn't work on Vista. If you can, please test the new one from the link from toad's mail :). - Zero3 The good: Under Vista64 the installer does produce a functioning node. Great! The bad: Wrapper.conf seems to not get an update from wizard mode. Maximum memory was still default of 192 and not the 512 I had set. If I do a new install and configure it manually rather than using the wizard, after a node reboot I can see the changes. A reboot after the wizard install does not. Permissions problem, surely? The unfortunate: The installer does not see existing 64 bit java installs under the Vista OS. The option to install java only installs the 32 bit java. This works and allows the install to complete but now you have both 32/64 bit jre's. :| Better than nothing. The messy workaround: After the node is installed and working, shut it down. Uninstall the 32 bit java. Start-run-cmd, then cd to %windir%\syswow64. There create three symbolic links to the 64 bit java in %windir%\system32. mklink java.exe ..\system32\java.exe mklink javaw.exe ..\system32\javaw.exe mklinik javaws.exe ..\system32\javaws.exe Restart the node. (I believe these links will break if java is ever updated and need to be recreated manually at that point in time.) Nice, a desktop version of Windows with support for symlinks. Thoughts: The installer cannot be spoofed by the symbolic links alone, only after a completed install is done can the freenet software be ran under a 64 bit java. Could the installer be revised to detect a 64 bit OS? Also adjusting for 64 bit java detection and it's possible download accordingly? The options to make changes to the wrapper don't happen when using the wizard. Can this be fixed or should it be removed and then after the node is up remind the user to adjust memory usage if he/she wants and then to reboot the node. We have removed the memory limit option in git ... 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] LoggerHook.registerClass in non-plugin code: good idea or not? 006d85dbcd31ffce94279667f5e9ab62d054c9cf
On Wednesday 06 May 2009 01:39:54 Daniel Cheng wrote:
On Wed, May 6, 2009 at 6:21 AM, Matthew Toseland
t...@amphibian.dyndns.org wrote:
sdiz commit 006d85dbcd31ffce94279667f5e9ab62d054c9cf
diff --git a/src/freenet/client/ArchiveHandlerImpl.java
b/src/freenet/client/ArchiveHandlerImpl.java
index 56a9b81..e8046ca 100644
--- a/src/freenet/client/ArchiveHandlerImpl.java
+++ b/src/freenet/client/ArchiveHandlerImpl.java
@@ -24,13 +24,7 @@ class ArchiveHandlerImpl implements ArchiveHandler {
private static volatile boolean logMINOR;
static {
- Logger.registerLogThresholdCallback(new
LogThresholdCallback()
{
-
- @Override
- public void shouldUpdate() {
- logMINOR = Logger.shouldLog(Logger.MINOR,
this);
- }
- });
+ Logger.registerClass(ArchiveHandlerImpl.class);
}
private final FreenetURI key;
Etc.
Logger.registerClass uses JNI and weak references, it is a great thing. It
That's not JNI, ... JNI is native C code.
This is Reflection (
http://java.sun.com/docs/books/tutorial/reflect/index.html )
Yes, I meant reflection. :)
could simplify much code as above, but shouldUpdate() is slow because of
JNI.
Given we very rarely change logging settings, is that a problem? How long
would it take to run the JNI hooks on every class? If it's less than 100ms
or
so, we should use this everywhere.
Do you have an opinion on this part?
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] Re long-term tester: commit b706e8b54055caaa9555d1c2e6f447f390341210
On Wednesday 06 May 2009 02:17:57 Daniel Cheng wrote: On Wed, May 6, 2009 at 6:21 AM, Matthew Toseland t...@amphibian.dyndns.org wrote: AFAICS you are not using innerDir/innerDir2: both nodes start in dir. It is using. The nodestart.starttestnode always start in a directory name with darknet port number. Confusing? Yes. But this is what other class in freenet.node.simluator.* using. The darknet ports should be aligned so they don't conflict with other tests, as I have done for the other tests. Fixed in 144ea69. IMHO it should be calculated statically as with the others, setting it to 10/11/12/13 does not prevent overlap. Somebody should run this regularly - the uid is just a fixed constant to separate my tests from somebody else's tests... I run the other tests daily, I should run this daily too... Are you doing? Do you have any scripts to parse the output yet? (I don't...) I am trying to run it daily .. mainly for debugging purpose. Any results yet? Is it working well enough to give a rough idea of data persistence? 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] Current uservoice top 5
On Monday 11 May 2009 16:50:44 Robert Hailey wrote: On May 10, 2009, at 2:50 PM, Arne Babenhauserheide wrote: Am Mittwoch 06 Mai 2009 00:23:54 schrieb Matthew Toseland: Isn't using a reasonably low scheduling priority enough? And we already do that! Not really, since I can't disable it (when I want full speed), and it sadly doesn't work really well for memory consumption. I'd like an option to have freenet go inactive as soon as the system load gets too high. It will lose connections anyway (low scheduling priority leads to far too high answer-times), so it could just explicitely take a break until my system runs well again. On Windows, it may not get enough CPU time even to do a graceful shutdown. If you start a game, or anything else that runs at higher priority, and uses all available cores, Freenet will not get scheduled at all, except maybe when the other task is waiting for I/O. But I don't want to have that all the time. When I compile something in the background, I want freenet to take predecence (that's already well covered with the low scheduling priority, though). Best wishes, Arne AFAIK this is a common design in other systems. Sendmail, for example, will not accept any network connections if the system's load is over some constant. Partly because it forks each time... I suppose the real issue would be detecting that in a platform- independent way (i.e. adding more JNI???). Exactly, sendmail isn't cross platform. 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] What to do on SSK collisions: f86448d51c2e3248e1dfec513eefde50902aac30
commit f86448d51c2e3248e1dfec513eefde50902aac30 Author: Daniel Cheng (鄭郁邦) j16s...@freenetproject.org Date: Fri May 8 21:04:28 2009 +0800 FreenetStore: Simplify code, remove overwrite parameter This parameter is always false. (Except when doing BDB-SaltedHash migration, which does not have to overwrite) The reason I introduced the overwrite parameter was that when we send an SSK insert and get a DataFound with different data, we should not only propagate the data downstream, but also replace our local copy of it. However apparently I never implemented this. Is it a good idea? 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] What to do on SSK collisions: f86448d51c2e3248e1dfec513eefde50902aac30
On Tuesday 12 May 2009 00:45:54 Matthew Toseland wrote: commit f86448d51c2e3248e1dfec513eefde50902aac30 Author: Daniel Cheng (鄭郁邦) j16s...@freenetproject.org Date: Fri May 8 21:04:28 2009 +0800 FreenetStore: Simplify code, remove overwrite parameter This parameter is always false. (Except when doing BDB-SaltedHash migration, which does not have to overwrite) The reason I introduced the overwrite parameter was that when we send an SSK insert and get a DataFound with different data, we should not only propagate the data downstream, but also replace our local copy of it. However apparently I never implemented this. Is it a good idea? Looks like we do store the collided data for a local insert (NodeClientCore.java:XXX we have collided), but not for a remote one. Except that a bug prevents the former from working. So we need to fix getBlock(). Ok... 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] LoggerHook.registerClass in non-plugin code: good idea or not? 006d85dbcd31ffce94279667f5e9ab62d054c9cf
On Tue, May 12, 2009 at 7:10 AM, Matthew Toseland
t...@amphibian.dyndns.org wrote:
On Wednesday 06 May 2009 01:39:54 Daniel Cheng wrote:
On Wed, May 6, 2009 at 6:21 AM, Matthew Toseland
t...@amphibian.dyndns.org wrote:
sdiz commit 006d85dbcd31ffce94279667f5e9ab62d054c9cf
diff --git a/src/freenet/client/ArchiveHandlerImpl.java
b/src/freenet/client/ArchiveHandlerImpl.java
index 56a9b81..e8046ca 100644
--- a/src/freenet/client/ArchiveHandlerImpl.java
+++ b/src/freenet/client/ArchiveHandlerImpl.java
@@ -24,13 +24,7 @@ class ArchiveHandlerImpl implements ArchiveHandler {
private static volatile boolean logMINOR;
static {
- Logger.registerLogThresholdCallback(new
LogThresholdCallback()
{
-
- @Override
- public void shouldUpdate() {
- logMINOR = Logger.shouldLog(Logger.MINOR,
this);
- }
- });
+ Logger.registerClass(ArchiveHandlerImpl.class);
}
private final FreenetURI key;
Etc.
Logger.registerClass uses JNI and weak references, it is a great thing. It
That's not JNI, ... JNI is native C code.
This is Reflection (
http://java.sun.com/docs/books/tutorial/reflect/index.html )
Yes, I meant reflection. :)
could simplify much code as above, but shouldUpdate() is slow because of
JNI.
Given we very rarely change logging settings, is that a problem? How long
would it take to run the JNI hooks on every class? If it's less than 100ms
or
so, we should use this everywhere.
Do you have an opinion on this part?
The reflection part (minor the shouldLog() function) take 2ms on my machine
for each class.
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
