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 im
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>
has other problems.
With passive 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, t
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 feature
- 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>
Desc: not 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 10:24:22
- 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/e8087268/attachment.pgp>
t layer with
> db4o
> > >>>> 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>
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 datastore
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
mum size of 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>
he legal one.
>
> In which case, we should 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>
mits...
-- 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>
gt; >
> 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.
-- 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>
ou already 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>
http://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>
n-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/6b93456a/attachment.pgp>
cern... 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?
>
> 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 (
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, t
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: trunk/fr
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
>
>
> Modif
tall anonymously written code on people's
> > computers without an audit.
>
> Agreed, that'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>
we need a persistent hashtable of some kind, at least in the long run.
We could grab one from 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>
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/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>
able
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20080519/22f6225d/attachment.pgp>
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
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 mu
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
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
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, whic
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 200
* 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
>
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:
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.
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 200
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
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 To
* [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 updat
* 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
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
>>
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 (
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 us
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 vari
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 lit
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
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:
> >
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 a
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
>> >>
57 matches
Mail list logo
