shrinking datastores.
- More unit tests.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20080519/9c19925a/attachment.pgp>
requests, a message system would likely have almost exactly the
same performance on a high latency Freenet as on a broadcast-routed network.
>
> Cheers,
> Michael
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20080519/7ba88791/attachment.pgp>
Matthew Toseland wrote:
>> Who says we need 8 GB per exchange for it to be viable? Seems to me that
>> even a few megabytes a day would be useful in a lot of places (or a few
>> kilobytes if you can choose which channels to participate in).
>
> Only if it's a broadcast system, and like I said,
On Mon, May 19, 2008 at 8:01 PM, Matthew Toseland
wrote:
> On Monday 19 May 2008 08:30, Daniel Cheng wrote:
>> On Thu, May 15, 2008 at 9:11 PM, Matthew Toseland
>> wrote:
>> > On Thursday 15 May 2008 06:11, Daniel Cheng wrote:
>> >> On Thu, May 15, 2008 at 7:08 AM, Matthew Toseland
>> >> wrote:
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20080519/c8c479b0/attachment.pgp>
}
An interesting solution to not having to seek ... but surely it would be
better to seek when needed, and not read the header?
> }
> } catch (EOFException e) {
> long size = l * (dataBlockSize + headerBl
On Mon, May 19, 2008 at 6:30 PM, Matthew Toseland
wrote:
> On Sunday 18 May 2008 11:51, Daniel Cheng wrote:
>> On Sun, May 18, 2008 at 4:58 AM, Matthew Toseland
>> wrote:
>> > GCC 4.3 shipped in March, including the new ECJ frontend. It has full
> support
>> > for all the new 1.5 language
next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20080519/1250fbb0/attachment.pgp>
available
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20080519/bb0f1276/attachment.pgp>
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20080519/6119679e/attachment.pgp>
On Thu, May 15, 2008 at 9:11 PM, Matthew Toseland
wrote:
> On Thursday 15 May 2008 06:11, Daniel Cheng wrote:
>> On Thu, May 15, 2008 at 7:08 AM, Matthew Toseland
>> wrote:
>> > On Sunday 11 May 2008 11:24, j16sdiz at freenetproject.org wrote:
>> >> Author: j16sdiz
>> >> Date: 2008-05-11
part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20080519/e8087268/attachment.pgp>
>>>> soon, unless convinced to use something else in the meantime. But it
> seems
> > >>>> that with BDBJE (which isn't a native object database), you can lose
> the
> > >>>> database even by an unclean shutdown... can anyone confirm this from
> > >>>> experience? Or is it only out of disk space and memory corruption
that
> causes
> > >>>> this?
> > >>>
> > >>> I'm still not convinced that we need a database... as our requirements
> > >>> are completely different from their typical use-cases... but well,
your
> > >>> immediate concern is to store persistent requests to disk, right? What
> > >>> about using Hibernate or javax.persistence (from EE) to do that ?
> > >>>
> > >> eee
> > >> Hibernate is just ORM -- You need a sql backend for that.
> > >> (I am not oppose to the idea of using a sql backend, but then we have
> > >> to decide which one to use)
> > >>
> > >> javax.persistence have Java5 dependency, and you need a J2EE
> > >> container. just too ugly.
> > >>
> > >> --
> > >> ___
> > >> Devl mailing list
> > >> Devl at freenetproject.org
> > >> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
> > >>
> > >
> > >
> > >
> > > --
> > > __
> > > GnuPG key: (0x48DBFA8A)
> > > Keyserver: pgpkeys.pca.dfn.de
> > > Fingerprint:
> > > 477D F057 1BD4 1AE7 8A54 8679 6690 E2EC 48DB FA8A
> > > __
> > > ___
> > > Devl mailing list
> > > Devl at freenetproject.org
> > > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
> > >
> >
> >
> >
> > --
> > Email: ian at uprizer.com
> > Cell: +1 512 422 3588
> > Skype: sanity
> > ___
> > Devl mailing list
> > Devl at freenetproject.org
> > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
> >
> >
>
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20080519/5350c4c3/attachment.pgp>
f the store?
>
> The graph show a CHK Cache with maximum size of 10,000 keys.
Well, it's a tradeoff ... it could be configurable ...
I don't see that it would necessarily be a problem for small stores - if they
are small, they will fill up reasonably fast despite this.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20080519/d916a97e/attachment.pgp>
ould simply link to the freesites for popular
> applications?
That would be much better imho
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20080519/a14f9948/attachment.pgp>
..
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20080519/b2280e31/attachment.pgp>
vice wrapper, etc?
We can make the assumption that they are widely used and that they were
reviewed by competent people outside of freenet's scope.
I don't think that making such an assumption for freenet-related code is
wise; Who would use Thaw/jSite/Frost/... without freenet ?
> Or you agree with Ian that we shouldn't bundle any freenet-related code?
I agree with Ian that bundling freenet-related code might lead to
problems... Both from the PR PoV and from the legal one.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20080519/51660cfa/attachment.pgp>
ready need 1.5
for ./contrib/bdb
> > > (yes I know, nobody else want to recompile freenet-ext).
> > :(
> > So it works?
>
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20080519/adfe9832/attachment.pgp>
://sdiz.net/temp/store.png
> This is the data from a live node on internet with 10,000 keys
Hmm, doesn't look like a big gain really...
How big is the maximum size of the store?
>
> Regards,
> Daniel
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20080519/a3401f98/attachment.pgp>
t attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20080519/6b93456a/attachment.pgp>
; You mean the database engine (BDBJE currently), the native big integer
code,
> > the java service wrapper, etc?
>
> We can make the assumption that they are widely used and that they were
> reviewed by competent people outside of freenet's scope.
>
> I don't think that making such an assumption for freenet-related code is
> wise; Who would use Thaw/jSite/Frost/... without freenet ?
>
> > Or you agree with Ian that we shouldn't bundle any freenet-related code?
>
> I agree with Ian that bundling freenet-related code might lead to
> problems... Both from the PR PoV and from the legal one.
In which case, we should simply link to the freesites for popular
applications?
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20080519/8d2ee97c/attachment.pgp>
Hey,
yes - works. Java memory usage is a bit higher as with the sun-vm. Reason
may be: loading native*.so grabs java mem under gcj while the sun-vm grabs
system memory. "top" shows ~equal usage. GC is active and runs also under
GCJ. While poking around, I noticed a high number of hash entries
hat's a big concern... and reviewing all the 3rd party code we
> bundle is unrealistic.
>
You mean the database engine (BDBJE currently), the native big integer code,
the java service wrapper, etc? Or you agree with Ian that we shouldn't bundle
any freenet-related code?
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20080519/d135760a/attachment.pgp>
jdbm, but then we'd have to maintain jdbm. Or we could
use a real object database and save *everything* to it. Implementing an
on-disk hashtable ourselves is another option, but it would require chaining
and therefore garbage collection... Quadratic probing for example probably
wouldn't work well for us, since it needs to be reliable and need few seeks.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20080519/3552bf4b/attachment.pgp>
hat
causes
> >>>> this?
> >>>
> >>> I'm still not convinced that we need a database... as our requirements
> >>> are completely different from their typical use-cases... but well, your
> >>> immediate concern is to store persistent requests to disk, right? What
> >>> about using Hibernate or javax.persistence (from EE) to do that ?
> >>>
> >> eee
> >> Hibernate is just ORM -- You need a sql backend for that.
> >> (I am not oppose to the idea of using a sql backend, but then we have
> >> to decide which one to use)
> >>
> >> javax.persistence have Java5 dependency, and you need a J2EE
> >> container. just too ugly.
> >>
> >> --
> >> ___
> >> Devl mailing list
> >> Devl at freenetproject.org
> >> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
> >>
> >
> >
> >
> > --
> > __
> > GnuPG key: (0x48DBFA8A)
> > Keyserver: pgpkeys.pca.dfn.de
> > Fingerprint:
> > 477D F057 1BD4 1AE7 8A54 8679 6690 E2EC 48DB FA8A
> > __
> > ___
> > Devl mailing list
> > Devl at freenetproject.org
> > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
> >
>
>
>
> --
> Email: ian at uprizer.com
> Cell: +1 512 422 3588
> Skype: sanity
> ___
> Devl mailing list
> Devl at freenetproject.org
> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
>
>
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20080519/000a7d88/attachment.pgp>
ped GCJ 4.3 with 1.5 language support but not 1.5
classpath? Or what?
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20080519/f806c4d4/attachment.pgp>
---
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20080519/cdc01aa8/attachment.pgp>
application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20080519/22f6225d/attachment.pgp>
On Thu, May 15, 2008 at 9:11 PM, Matthew Toseland
[EMAIL PROTECTED] wrote:
On Thursday 15 May 2008 06:11, Daniel Cheng wrote:
On Thu, May 15, 2008 at 7:08 AM, Matthew Toseland
[EMAIL PROTECTED] wrote:
On Sunday 11 May 2008 11:24, [EMAIL PROTECTED] wrote:
Author: j16sdiz
Date: 2008-05-11
On Sunday 18 May 2008 05:27, Florent Daignière wrote:
* Matthew Toseland [EMAIL PROTECTED] [2008-05-17 19:00:13]:
On Saturday 17 May 2008 00:29, Matthew Toseland wrote:
Ian and I have eventually come to the conclusion that we should include
db4o,
and use it for our various
On Sunday 18 May 2008 05:17, Florent Daignière wrote:
* Ian Clarke [EMAIL PROTECTED] [2008-05-17 13:35:40]:
On Sat, May 17, 2008 at 6:10 AM, Matthew Toseland
[EMAIL PROTECTED] wrote:
Exactly, which is why Thaw, Freemail, etc are the apps that will
motivate users to use Freenet. Only
On Sunday 18 May 2008 04:14, Evan Daniel wrote:
On Sat, May 17, 2008 at 10:08 PM, Juiceman [EMAIL PROTECTED] wrote:
On Sat, May 17, 2008 at 4:58 PM, Matthew Toseland
[EMAIL PROTECTED] wrote:
GCC 4.3 shipped in March, including the new ECJ frontend. It has full
support
for all the new 1.5
On Sunday 18 May 2008 06:56, Sven-Ola Tücke wrote:
Hi,
while ./freenet/ compiles with 1.4, you already need 1.5 for ./contrib/bdb
(yes I know, nobody else want to recompile freenet-ext).
:(
So it works?
// Sven-Ola
Am Samstag 17 Mai 2008 22:58:02 schrieb Matthew Toseland:
GCC 4.3
On Sunday 18 May 2008 11:51, Daniel Cheng wrote:
On Sun, May 18, 2008 at 4:58 AM, Matthew Toseland
[EMAIL PROTECTED] wrote:
GCC 4.3 shipped in March, including the new ECJ frontend. It has full
support
for all the new 1.5 language features. IMHO this means that there is no
longer any
On Sunday 18 May 2008 19:44, Ian Clarke wrote:
I've got to say, I really hope Perst employ better software engineers
than their web designers, because their website is awful. It somewhat
shakes my confidence in them. I know this seems like a very
superficial judgement, but if they put little
On Mon, May 19, 2008 at 6:30 PM, Matthew Toseland
[EMAIL PROTECTED] wrote:
On Sunday 18 May 2008 11:51, Daniel Cheng wrote:
On Sun, May 18, 2008 at 4:58 AM, Matthew Toseland
[EMAIL PROTECTED] wrote:
GCC 4.3 shipped in March, including the new ECJ frontend. It has full
support
for all the
* Matthew Toseland [EMAIL PROTECTED] [2008-05-19 11:47:16]:
On Sunday 18 May 2008 05:17, Florent Daignière wrote:
* Ian Clarke [EMAIL PROTECTED] [2008-05-17 13:35:40]:
On Sat, May 17, 2008 at 6:10 AM, Matthew Toseland
[EMAIL PROTECTED] wrote:
Exactly, which is why Thaw, Freemail,
* [EMAIL PROTECTED] [EMAIL PROTECTED] [2008-05-19 11:01:38]:
Author: toad
Date: 2008-05-19 11:01:38 + (Mon, 19 May 2008)
New Revision: 19960
Modified:
trunk/freenet/src/freenet/clients/http/staticfiles/defaultbookmarks.dat
Log:
Update Freemail edition
What about updating the
On Monday 19 May 2008 12:33, Florent Daignière wrote:
* Matthew Toseland [EMAIL PROTECTED] [2008-05-19 11:47:16]:
On Sunday 18 May 2008 05:17, Florent Daignière wrote:
* Ian Clarke [EMAIL PROTECTED] [2008-05-17 13:35:40]:
On Sat, May 17, 2008 at 6:10 AM, Matthew Toseland
[EMAIL
On Monday 19 May 2008 11:48, Sven-Ola Tuecke wrote:
Hey,
yes - works. Java memory usage is a bit higher as with the sun-vm. Reason
may be: loading native*.so grabs java mem under gcj while the sun-vm grabs
system memory. top shows ~equal usage. GC is active and runs also under
GCJ. While
On Monday 19 May 2008 08:30, Daniel Cheng wrote:
On Thu, May 15, 2008 at 9:11 PM, Matthew Toseland
[EMAIL PROTECTED] wrote:
On Thursday 15 May 2008 06:11, Daniel Cheng wrote:
On Thu, May 15, 2008 at 7:08 AM, Matthew Toseland
[EMAIL PROTECTED] wrote:
On Sunday 11 May 2008 11:24, [EMAIL
On Monday 19 May 2008 13:00, Matthew Toseland wrote:
On Monday 19 May 2008 11:48, Sven-Ola Tuecke wrote:
Hey,
yes - works. Java memory usage is a bit higher as with the sun-vm. Reason
may be: loading native*.so grabs java mem under gcj while the sun-vm grabs
system memory. top shows
On Mon, May 19, 2008 at 8:01 PM, Matthew Toseland
[EMAIL PROTECTED] wrote:
On Monday 19 May 2008 08:30, Daniel Cheng wrote:
On Thu, May 15, 2008 at 9:11 PM, Matthew Toseland
[EMAIL PROTECTED] wrote:
On Thursday 15 May 2008 06:11, Daniel Cheng wrote:
On Thu, May 15, 2008 at 7:08 AM, Matthew
* Matthew Toseland [EMAIL PROTECTED] [2008-05-19 12:58:24]:
software on people's machines which we didn't write, and which for all
we know could contain well hidden code to delete their hard disks on
July 4th just for a laugh. If we install this software, WE ARE
RESPONSIBLE
On Monday 19 May 2008 13:04, Daniel Cheng wrote:
On Mon, May 19, 2008 at 8:01 PM, Matthew Toseland
[EMAIL PROTECTED] wrote:
On Monday 19 May 2008 08:30, Daniel Cheng wrote:
On Thu, May 15, 2008 at 9:11 PM, Matthew Toseland
[EMAIL PROTECTED] wrote:
On Thursday 15 May 2008 06:11, Daniel
On Monday 19 May 2008 11:34, Matthew Toseland wrote:
On Sunday 18 May 2008 19:44, Ian Clarke wrote:
Looking at the manual, it looks like Perst operates at a lower level
than db4o - you need to manually create and maintain indexes. This is
closer to the Java collections API, which could
On Monday 19 May 2008 14:47, Matthew Toseland wrote:
On Monday 19 May 2008 11:34, Matthew Toseland wrote:
On Sunday 18 May 2008 19:44, Ian Clarke wrote:
Looking at the manual, it looks like Perst operates at a lower level
than db4o - you need to manually create and maintain indexes.
On Sunday 02 March 2008 16:35, Ian Clarke wrote:
What do people think of this website as a possible way to improve how
we provide user support?:
http://getsatisfaction.com/
It looks friendly, and pretty powerful.
What exactly is the benefit? Regular users on forums able to evaluate a
Matthew Toseland a écrit :
Thoughts? IMHO backups are an important feature, and they'd probably have to
be hot backups for our usage... but then, not corrupting on running out of
disk space is important too!
I just rewrote the WoT plugin to use db4o and I must say I like it. My
code is much
On Monday 19 May 2008 18:02, Julien Cornuwel wrote:
Matthew Toseland a écrit :
Thoughts? IMHO backups are an important feature, and they'd probably have
to
be hot backups for our usage... but then, not corrupting on running out of
disk space is important too!
I just rewrote the WoT
On Monday 19 May 2008 15:13, [EMAIL PROTECTED] wrote:
Author: j16sdiz
Date: 2008-05-19 14:13:41 + (Mon, 19 May 2008)
New Revision: 19961
Modified:
trunk/freenet/src/freenet/client/async/USKFetcher.java
Log:
fix IllegalStateException on isMetadata()
Modified:
On Friday 16 May 2008 16:15, [EMAIL PROTECTED] wrote:
Author: j16sdiz
Date: 2008-05-16 15:15:24 + (Fri, 16 May 2008)
New Revision: 19954
Modified:
trunk/freenet/src/freenet/store/BerkeleyDBFreenetStore.java
Log:
BDBFS: reconstruct() - read data only when needed
Modified:
Matthew Toseland wrote:
Who says we need 8 GB per exchange for it to be viable? Seems to me that
even a few megabytes a day would be useful in a lot of places (or a few
kilobytes if you can choose which channels to participate in).
Only if it's a broadcast system, and like I said, they can
On Monday 19 May 2008 20:26, Michael Rogers wrote:
Matthew Toseland wrote:
Who says we need 8 GB per exchange for it to be viable? Seems to me that
even a few megabytes a day would be useful in a lot of places (or a few
kilobytes if you can choose which channels to participate in).
Freenet 0.7 build 1150 changelog (sorry for the delay!):
- Chinese translations for a lot of the UI.
- Add The Freenet Applications Freesite to the default bookmarks.
- Some CPU usage optimisations.
- Fix a seednodes bug (seeding for count was bogus).
- Fix an infinite loop in shrinking
Matthew Toseland a écrit :
On Monday 19 May 2008 18:02, Julien Cornuwel wrote:
Matthew Toseland a écrit :
Thoughts? IMHO backups are an important feature, and they'd probably have
to
be hot backups for our usage... but then, not corrupting on running out of
disk space is important too!
56 matches
Mail list logo
