Re: [freenet-dev] Fwd: [freenet-support] Usability testing?on?Windows XP

[Florent Daignière]

* Theodore Hong <[EMAIL PROTECTED]> [2008-06-04 13:18:11]:

> Matthew Toseland <[EMAIL PROTECTED]> wrote:
> > On Wednesday 04 June 2008 05:42, Florent Daignière wrote:
> >> Moreover, if we want the "trust-chain" in between us and the newbies to
> >> be established, we HAVE TO distribute the installer from emu and not
> >> from mirrors... meaning that it has to be as small as possible if we
> >> intend to stand a slashdoting.
> >>
> > Well then we'll have to make it a lot smaller than even 3.6MB: we'd want 
> > some
> > sort of minimal shell that downloads a hash from emu and then fetches the
> > rest from a mirror.
> 
> Is there a project signing key that we can use to sign releases?
> theo

http://archives.freenetproject.org/message/20080515.125656.0d8a973e.en.html
For X509 (jarsigner)

and http://downloads.freenetproject.org/alpha/README for GPG


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

Re: [freenet-dev] Fwd: [freenet-support] Usability?testing?on?Windows XP

[Florent Daignière]

* Matthew Toseland <[EMAIL PROTECTED]> [2008-06-04 12:33:40]:

> On Wednesday 04 June 2008 05:35, Florent Daignière wrote:
> > * Matthew Toseland <[EMAIL PROTECTED]> [2008-06-03 17:22:56]:
> > 
> > > On Monday 02 June 2008 17:37, Julien Cornuwel wrote:
> > > > Florent Daignière a écrit :
> > > > > * Matthew Toseland <[EMAIL PROTECTED]> [2008-06-02 14:15:02]:
> > > > > 
> > > > >>> Additionnaly, that page was in English despite the fact he chose 
> French
> > > > >>> in the installer. I had to tell him he had to finish the installer 
> and
> > > > >>> then, click on the link to the first-time wizard.
> > > > >> Okay this is bad, I think it's been fixed though. Nextgens?
> > > > >>
> > > > > 
> > > > > Yeah, it was a windows-specific bug and which has been fixed.
> > > > 
> > > > Before or after I did the test ? Because it was not at that moment.
> > > > 
> > > > >>> - Just a detail : every shortcuts (except Browse Freenet) in the 
> menu
> > > > >>> came with the same default icon. He was disapointed and I had to 
> tell
> > > > >>> him it was irrelevant and everything was fine.
> > > > >>>
> > > > > 
> > > > > If you have icon files I can use I'll be pleased to fix that
> > > > 
> > > > Well, no I don't *have* any. And seriously, you don't want me to draw
> > > > some ;)
> > > > 
> > > > >>> Maybe we should only spawn the browser at the very end of the
> > > > >>> installation process, when the installer closes and Freenet is up 
> and
> > > > >>> running. 
> > > > >> We open the browser very shortly after Freenet is working. However, 
> at 
> > > the 
> > > > >> moment, we download and install more stuff after that - namely the 
> > > bundled 
> > > > >> apps. In any case, without major changes to the installer, we have 
> > > > >> to 
> > > open 
> > > > >> the browser during the processes page (again, am I right nextgens? 
> > > > >> Is 
> > > there 
> > > > >> any possibility of exit-hooks?). Is it a big deal?
> > > > > 
> > > > > Last time I tried to use them they were issues
> > > > > 
> > > > >> The most likely consequence is that the user doesn't complete the 
> > > installer,
> > > > >> or that there is a long delay before it, right?
> > > > >>
> > > > > 
> > > > > We could time-delay the browser startup if that's the only thing :)
> > > > 
> > > > Any solution would be good. Small details like that keep users telling
> > > > others that Freenet is complicated. We are so used to it that we can't
> > > > see them anymore but, newbies do...
> > > 
> > > I'm not sure that a time delay would help. And exit hooks don't work. So 
> what 
> > > can we do?
> > 
> > Maybe we should not open the browser and wait for the user to click on
> > "browse-freenet".
> > 
> I dunno... what exactly is it that confuses some users?
> 
> Most installers for e.g. games have a checkbox on the last page for whether 
> to 
> open the app you just installed on exiting the installer, really we should do 
> that.

That's not trivial


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

Re: [freenet-dev] Website and IE

[Florent Daignière]

* Michael Tänzer <[EMAIL PROTECTED]> [2008-06-04 11:21:56]:

> I'm still working on the drupal thingie, but I'm a little short on time
> currently.
> One of the drupal coders, drewish, was so kind to provide a plugin which
> fixes the tranlation problems http://drupal.org/project/active_translation

I have set it up on the vhost... but it seems to be encountering
problems rebuilding the translation table


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

Re: [freenet-dev] Website and IE

[Florent Daignière]

* Loki <[EMAIL PROTECTED]> [2008-06-04 10:13:51]:

> Well not a wizard here, but maybe a help.
> 
> In style.css just activate the out commented line /*width: 150px;*/
> 
> div#menu {
>   font-family: Sans-serif, Arial, "Times New Roman", Georgia, Times, 
> serif; 
>   float:left;
>   /*width: 150px;*/< 
>   font-style: normal;
>   font-weight: normal;
>   text-align: left;
>   line-height: 100%;
>   color: #00;
>   background: #CCDDFF;
>   text-decoration: none;
>   margin-top: 15px;
>   margin-bottom: 10px;
>   border: 1px solid #99CCFF;
> }
> 
> Background:
> If no width definition for the Box exist, so Firefox use the minimum needed 
> width, IE6 the maximum available width.
> 

Okay, I've reverted r19832 in r20191 :)

> Problems:
> If the box has a fixed width definition, it will not resize with the font 
> zooming feature.
> 

Well, I guess we will have to cope with that for the time being :/


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

Re: [freenet-dev] CPUID patch from FMS

[Florent Daignière]

* Florent Daignière <[EMAIL PROTECTED]> [2008-05-18 06:09:15]:

> * Matthew Toseland <[EMAIL PROTECTED]> [2008-05-17 14:44:27]:
> 
> > On Saturday 17 May 2008 13:58, Florent Daignière wrote:
> > > * Florent Daignière <[EMAIL PROTECTED]> [2008-05-17 14:03:10]:
> > > 
> > > > * Matthew Toseland <[EMAIL PROTECTED]> [2008-05-17 12:29:09]:
> > > > 
> > > > > As nextgens is worried about anonymous contributions, I thought he 
> > > > > might 
> > want 
> > > > > to review this before I apply it.
> > > > > 
> > > > 
> > > > There is a related bug in the bug tracker... It's not the only bits that
> > > > need updating :/
> > > > 
> > > > See #74
> > > 
> > > http://download.intel.com/design/processor/applnots/24161832.pdf
> > > 
> > http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/25481.pdf
> > > 
> > > Here are the CPUID codes if you want to update them.
> > > 
> > So should we or shouldn't we apply yongjhen's patch?
> 
> I think that applying that patch instead of updating the whole set of codes
> is not the way to go...
> 
> If we were really after performances we would recompile the native
> libraries with the new libgmp... which has performances boost on that
> kind of (recent) processors.

Any progress ?
Did you fill a ticket in for that issue ?


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

[freenet-dev] Website and IE

[Florent Daignière]

The website looks awful in IE; is there any CSS wizard who has any clue
on how to fix it ?

http://img258.imageshack.us/img258/1830/72265808xc0.png


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

Re: [freenet-dev] Fwd: [freenet-support] Usability testing?on?Windows XP

[Florent Daignière]

* Matthew Toseland <[EMAIL PROTECTED]> [2008-06-03 17:24:48]:

> On Monday 02 June 2008 15:13, Florent Daignière wrote:
> > * Matthew Toseland <[EMAIL PROTECTED]> [2008-06-02 15:03:37]:
> > 
> > > On Monday 02 June 2008 14:47, Florent Daignière wrote:
> > > > * Matthew Toseland <[EMAIL PROTECTED]> [2008-06-02 14:15:02]:
> > > > 
> > > > > Okay, what issues do we have here?
> > > > > 
> > > > > 1. The processes page takes longer than the copying files page. In 
> fact, 
> > > most 
> > > > > of the time of the installer is occupied by the processes page.
> > > > > 
> > > > > IMHO the solution to this is to bundle everything which is essential 
> with 
> > > the 
> > > > > base installer. Then the processes page will take much less time. 
> > > > > Also 
> we 
> > > > > won't need a separate bundle-installer, so it will be easier to use 
> > > > > in 
> > > places 
> > > > > where the Freenet website is blocked. The downside is the installer 
> will 
> > > be 
> > > > > significantly bigger.
> > > > 
> > > > I'm not convinced about that
> > > 
> > > Why? It won't be huge, if we don't bundle any unnecessary Huge Stuff (see 
> > > below). And it's not small now.
> > 
> > That means we will have to generate new installers on a regular basis...
> > I don't like that :p
> 
> Is there any good reason for this dislike?

Downloading stuffs during the install process actually tests the user's
connectivity; If we don't do that we will end up with more support
requests from users having non-freenet-related issues.

Moreover, if we want the "trust-chain" in between us and the newbies to
be established, we HAVE TO distribute the installer from emu and not
from mirrors... meaning that it has to be as small as possible if we
intend to stand a slashdoting.

Arguably we don't distribute the installer ourselves yet... but I was in
the process of changing that.


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

Re: [freenet-dev] Fwd: [freenet-support] Usability testing?on?Windows XP

[Florent Daignière]

* Matthew Toseland <[EMAIL PROTECTED]> [2008-06-03 17:22:56]:

> On Monday 02 June 2008 17:37, Julien Cornuwel wrote:
> > Florent Daignière a écrit :
> > > * Matthew Toseland <[EMAIL PROTECTED]> [2008-06-02 14:15:02]:
> > > 
> > >>> Additionnaly, that page was in English despite the fact he chose French
> > >>> in the installer. I had to tell him he had to finish the installer and
> > >>> then, click on the link to the first-time wizard.
> > >> Okay this is bad, I think it's been fixed though. Nextgens?
> > >>
> > > 
> > > Yeah, it was a windows-specific bug and which has been fixed.
> > 
> > Before or after I did the test ? Because it was not at that moment.
> > 
> > >>> - Just a detail : every shortcuts (except Browse Freenet) in the menu
> > >>> came with the same default icon. He was disapointed and I had to tell
> > >>> him it was irrelevant and everything was fine.
> > >>>
> > > 
> > > If you have icon files I can use I'll be pleased to fix that
> > 
> > Well, no I don't *have* any. And seriously, you don't want me to draw
> > some ;)
> > 
> > >>> Maybe we should only spawn the browser at the very end of the
> > >>> installation process, when the installer closes and Freenet is up and
> > >>> running. 
> > >> We open the browser very shortly after Freenet is working. However, at 
> the 
> > >> moment, we download and install more stuff after that - namely the 
> bundled 
> > >> apps. In any case, without major changes to the installer, we have to 
> open 
> > >> the browser during the processes page (again, am I right nextgens? Is 
> there 
> > >> any possibility of exit-hooks?). Is it a big deal?
> > > 
> > > Last time I tried to use them they were issues
> > > 
> > >> The most likely consequence is that the user doesn't complete the 
> installer,
> > >> or that there is a long delay before it, right?
> > >>
> > > 
> > > We could time-delay the browser startup if that's the only thing :)
> > 
> > Any solution would be good. Small details like that keep users telling
> > others that Freenet is complicated. We are so used to it that we can't
> > see them anymore but, newbies do...
> 
> I'm not sure that a time delay would help. And exit hooks don't work. So what 
> can we do?

Maybe we should not open the browser and wait for the user to click on
"browse-freenet".


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

[freenet-dev] Fwd: [freenet-support] Usability testing on?Windows XP

[Florent Daignière]

* Matthew Toseland  [2008-06-02 15:03:37]:

> On Monday 02 June 2008 14:47, Florent Daigni?re wrote:
> > * Matthew Toseland  [2008-06-02 14:15:02]:
> > 
> > > Okay, what issues do we have here?
> > > 
> > > 1. The processes page takes longer than the copying files page. In fact, 
> most 
> > > of the time of the installer is occupied by the processes page.
> > > 
> > > IMHO the solution to this is to bundle everything which is essential with 
> the 
> > > base installer. Then the processes page will take much less time. Also we 
> > > won't need a separate bundle-installer, so it will be easier to use in 
> places 
> > > where the Freenet website is blocked. The downside is the installer will 
> be 
> > > significantly bigger.
> > 
> > I'm not convinced about that
> 
> Why? It won't be huge, if we don't bundle any unnecessary Huge Stuff (see 
> below). And it's not small now.

That means we will have to generate new installers on a regular basis...
I don't like that :p

> > > 2. The installer shouldn't download Thingamablog and Thaw. They are huge, 
> we 
> > > have not audited the code, and users can get them if they want them. 
> > > Debundling them would mean that as soon as we open the browser the 
> Processes 
> > > page will have completed, and the user can click Next and go on to 
> creating 
> > > icons. There seems to be a consensus on debundling, at least between Ian 
> and 
> > > Nextgens. :) I think a policy of not bundling anything we can't code 
> review 
> > > is reasonable, and clearly code reviewing Thingamablog for example would 
> be a 
> > > massive undertaking and isn't appropriate at this time. I do think we 
> should 
> > > keep the current plugins, however most of them are small. Even if we 
> include 
> > > the WoT plugin, that is also likely to be reasonably small for the 
> > > foreseeable future.
> > 
> > Ok, let's get rid of them then
> 
> For reasons of code reviewability?
> 

Yep

> Further to the above, I do actually review Thingamablog commits, however I 
> haven't reviewed the original, and it's not really widely enough used that we 
> can assume it to be safe? However, I do disagree with Ian's assertion that 
> nothing we don't own is reviewable: it is much easier to hide bugs in C 
> because you have buffer overflows, format string vulnerabilities and so on. 
> In Java, well written code *can* be reviewed, although of course more subtle 
> bugs may slip through the net. Also I review jSite commits (I dunno whether 
> the original on which the diffs are applied was reviewed though).
> > 
> > > 3. Is it possible to change the names of the two panels? Copying Files vs 
> > > Setting Up Freenet, perhaps?
> > 
> > We could get rid of one of the panel before the processing one
> 
> Good idea.

Will see what I can do

> > 
> > > 4. Is it possible to open the browser after closing the installer rather 
> than 
> > > in the Processes page?
> > 
> > Not "cleanly" but we could do a workaround time-delaying the browser
> > startup.
> 
> I'm not convinced that's better than the alternative.

Okay, so WONTFIX
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: 

[freenet-dev] Fwd: [freenet-support] Usability testing on Windows XP

[Florent Daignière]

* Matthew Toseland  [2008-06-02 14:15:02]:

> Okay, what issues do we have here?
> 
> 1. The processes page takes longer than the copying files page. In fact, most 
> of the time of the installer is occupied by the processes page.
> 
> IMHO the solution to this is to bundle everything which is essential with the 
> base installer. Then the processes page will take much less time. Also we 
> won't need a separate bundle-installer, so it will be easier to use in places 
> where the Freenet website is blocked. The downside is the installer will be 
> significantly bigger.
> 

I'm not convinced about that

> 2. The installer shouldn't download Thingamablog and Thaw. They are huge, we 
> have not audited the code, and users can get them if they want them. 
> Debundling them would mean that as soon as we open the browser the Processes 
> page will have completed, and the user can click Next and go on to creating 
> icons. There seems to be a consensus on debundling, at least between Ian and 
> Nextgens. :) I think a policy of not bundling anything we can't code review 
> is reasonable, and clearly code reviewing Thingamablog for example would be a 
> massive undertaking and isn't appropriate at this time. I do think we should 
> keep the current plugins, however most of them are small. Even if we include 
> the WoT plugin, that is also likely to be reasonably small for the 
> foreseeable future.
> 

Ok, let's get rid of them then

> 3. Is it possible to change the names of the two panels? Copying Files vs 
> Setting Up Freenet, perhaps?
> 

We could get rid of one of the panel before the processing one

> 4. Is it possible to open the browser after closing the installer rather than 
> in the Processes page?
> 

Not "cleanly" but we could do a workaround time-delaying the browser
startup.

> 5. Icons: We need proper icons for our various shortcuts. On unix the 
> situation is worse: We have no icons. On Windows, Browse Freenet has the 
> bunny icon and the rest don't have anything.

Well provide me icons and maybe I'll consider using them :p
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: 

[freenet-dev] Fwd: [freenet-support] Usability testing on Windows XP

[Florent Daignière]

* Matthew Toseland  [2008-06-02 14:15:02]:

> > Additionnaly, that page was in English despite the fact he chose French
> > in the installer. I had to tell him he had to finish the installer and
> > then, click on the link to the first-time wizard.
> 
> Okay this is bad, I think it's been fixed though. Nextgens?
> 

Yeah, it was a windows-specific bug and which has been fixed.

> > - Just a detail : every shortcuts (except Browse Freenet) in the menu
> > came with the same default icon. He was disapointed and I had to tell
> > him it was irrelevant and everything was fine.
> > 

If you have icon files I can use I'll be pleased to fix that

> > Maybe we should only spawn the browser at the very end of the
> > installation process, when the installer closes and Freenet is up and
> > running. 
> 
> We open the browser very shortly after Freenet is working. However, at the 
> moment, we download and install more stuff after that - namely the bundled 
> apps. In any case, without major changes to the installer, we have to open 
> the browser during the processes page (again, am I right nextgens? Is there 
> any possibility of exit-hooks?). Is it a big deal?

Last time I tried to use them they were issues

> The most likely consequence is that the user doesn't complete the installer,
> or that there is a long delay before it, right?
> 

We could time-delay the browser startup if that's the only thing :)

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: 

Re: [freenet-dev] Fwd: [freenet-support] Usability testing on?Windows XP

[Florent Daignière]

* Matthew Toseland <[EMAIL PROTECTED]> [2008-06-02 15:03:37]:

> On Monday 02 June 2008 14:47, Florent Daignière wrote:
> > * Matthew Toseland <[EMAIL PROTECTED]> [2008-06-02 14:15:02]:
> > 
> > > Okay, what issues do we have here?
> > > 
> > > 1. The processes page takes longer than the copying files page. In fact, 
> most 
> > > of the time of the installer is occupied by the processes page.
> > > 
> > > IMHO the solution to this is to bundle everything which is essential with 
> the 
> > > base installer. Then the processes page will take much less time. Also we 
> > > won't need a separate bundle-installer, so it will be easier to use in 
> places 
> > > where the Freenet website is blocked. The downside is the installer will 
> be 
> > > significantly bigger.
> > 
> > I'm not convinced about that
> 
> Why? It won't be huge, if we don't bundle any unnecessary Huge Stuff (see 
> below). And it's not small now.

That means we will have to generate new installers on a regular basis...
I don't like that :p

> > > 2. The installer shouldn't download Thingamablog and Thaw. They are huge, 
> we 
> > > have not audited the code, and users can get them if they want them. 
> > > Debundling them would mean that as soon as we open the browser the 
> Processes 
> > > page will have completed, and the user can click Next and go on to 
> creating 
> > > icons. There seems to be a consensus on debundling, at least between Ian 
> and 
> > > Nextgens. :) I think a policy of not bundling anything we can't code 
> review 
> > > is reasonable, and clearly code reviewing Thingamablog for example would 
> be a 
> > > massive undertaking and isn't appropriate at this time. I do think we 
> should 
> > > keep the current plugins, however most of them are small. Even if we 
> include 
> > > the WoT plugin, that is also likely to be reasonably small for the 
> > > foreseeable future.
> > 
> > Ok, let's get rid of them then
> 
> For reasons of code reviewability?
> 

Yep

> Further to the above, I do actually review Thingamablog commits, however I 
> haven't reviewed the original, and it's not really widely enough used that we 
> can assume it to be safe? However, I do disagree with Ian's assertion that 
> nothing we don't own is reviewable: it is much easier to hide bugs in C 
> because you have buffer overflows, format string vulnerabilities and so on. 
> In Java, well written code *can* be reviewed, although of course more subtle 
> bugs may slip through the net. Also I review jSite commits (I dunno whether 
> the original on which the diffs are applied was reviewed though).
> > 
> > > 3. Is it possible to change the names of the two panels? Copying Files vs 
> > > Setting Up Freenet, perhaps?
> > 
> > We could get rid of one of the panel before the processing one
> 
> Good idea.

Will see what I can do

> > 
> > > 4. Is it possible to open the browser after closing the installer rather 
> than 
> > > in the Processes page?
> > 
> > Not "cleanly" but we could do a workaround time-delaying the browser
> > startup.
> 
> I'm not convinced that's better than the alternative.

Okay, so WONTFIX


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

Re: [freenet-dev] Fwd: [freenet-support] Usability testing on Windows XP

[Florent Daignière]

* Matthew Toseland <[EMAIL PROTECTED]> [2008-06-02 14:15:02]:

> Okay, what issues do we have here?
> 
> 1. The processes page takes longer than the copying files page. In fact, most 
> of the time of the installer is occupied by the processes page.
> 
> IMHO the solution to this is to bundle everything which is essential with the 
> base installer. Then the processes page will take much less time. Also we 
> won't need a separate bundle-installer, so it will be easier to use in places 
> where the Freenet website is blocked. The downside is the installer will be 
> significantly bigger.
> 

I'm not convinced about that

> 2. The installer shouldn't download Thingamablog and Thaw. They are huge, we 
> have not audited the code, and users can get them if they want them. 
> Debundling them would mean that as soon as we open the browser the Processes 
> page will have completed, and the user can click Next and go on to creating 
> icons. There seems to be a consensus on debundling, at least between Ian and 
> Nextgens. :) I think a policy of not bundling anything we can't code review 
> is reasonable, and clearly code reviewing Thingamablog for example would be a 
> massive undertaking and isn't appropriate at this time. I do think we should 
> keep the current plugins, however most of them are small. Even if we include 
> the WoT plugin, that is also likely to be reasonably small for the 
> foreseeable future.
> 

Ok, let's get rid of them then

> 3. Is it possible to change the names of the two panels? Copying Files vs 
> Setting Up Freenet, perhaps?
> 

We could get rid of one of the panel before the processing one

> 4. Is it possible to open the browser after closing the installer rather than 
> in the Processes page?
> 

Not "cleanly" but we could do a workaround time-delaying the browser
startup.

> 5. Icons: We need proper icons for our various shortcuts. On unix the 
> situation is worse: We have no icons. On Windows, Browse Freenet has the 
> bunny icon and the rest don't have anything.

Well provide me icons and maybe I'll consider using them :p


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

Re: [freenet-dev] Fwd: [freenet-support] Usability testing on Windows XP

[Florent Daignière]

* Matthew Toseland <[EMAIL PROTECTED]> [2008-06-02 14:15:02]:

> > Additionnaly, that page was in English despite the fact he chose French
> > in the installer. I had to tell him he had to finish the installer and
> > then, click on the link to the first-time wizard.
> 
> Okay this is bad, I think it's been fixed though. Nextgens?
> 

Yeah, it was a windows-specific bug and which has been fixed.

> > - Just a detail : every shortcuts (except Browse Freenet) in the menu
> > came with the same default icon. He was disapointed and I had to tell
> > him it was irrelevant and everything was fine.
> > 

If you have icon files I can use I'll be pleased to fix that

> > Maybe we should only spawn the browser at the very end of the
> > installation process, when the installer closes and Freenet is up and
> > running. 
> 
> We open the browser very shortly after Freenet is working. However, at the 
> moment, we download and install more stuff after that - namely the bundled 
> apps. In any case, without major changes to the installer, we have to open 
> the browser during the processes page (again, am I right nextgens? Is there 
> any possibility of exit-hooks?). Is it a big deal?

Last time I tried to use them they were issues

> The most likely consequence is that the user doesn't complete the installer,
> or that there is a long delay before it, right?
> 

We could time-delay the browser startup if that's the only thing :)



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

[freenet-dev] Trust path, new download location

[Florent Daignière]

Hi,
Over the WE I have been changing a few things on emu...
Three goals here:
1) Make the installation and update process MITM proof
[1]
2) Get rid of the current load-balancer (I wrote it in
php and it sucks...) and limit the number of redirects
to follow to download a file
3) Gradually get rid of all the backward compatibility
stuffs we keep server-side
Hopefully that means less hits on emu and faster downloads.

From now on all the files are downloaded from
https://checksums.freenetproject.org/latest/
... And no, don't ask for it there is no directory listing... We
need to be able to change the URL we use more easily than now;
Hence I've simplified to the minimum the naming scheme: you ask
for the filename and that's it; they are no subdirectories
anymore and latest version of plugins can be accessed directly.

Before I can finish up and move on they are three things which
should be done:
1) update.cmd needs to be updated; imho it could be
rewritten from scratch, using update.sh as model. I can
precisely describe why it sucks if needed. We want all
the scripts to use the Sha1Test class
2) The node should be updated to download plugins from
the new URL and should check the checksums it provides
3) users should be asked to double-check that they have
an up to date updating script and that *it works*; It's
probably something we want to talk about in the next
release-announcement message.
Once those are done I will get rid of two vhosts on emu
(downloads.freenetproject.org and get.freenetproject.org) and
simplify *a lot* the release-building scripts. I'll create a
vhost dedicated to the 0.5 legacy code if someone want it
(complain now or never)... but we can't reasonably keep the
current file hierarchy.

Would anyone object if I force the installer to be downloaded
from emu and disable file-listing in the directory where it will
be ? Lately I heard of weird bugs from some users... and it
turns out they were using a 7 month old installer to set their
nodes up... they used some download-directory (like zdnet.com)
and got their old, deprecated installer from them! Needless to
say there isn't much we can do against that... but checking
referrers and disabling file-listing is something we can do
reasonably easily.

Are Zero3Cool or Juiceman still around and willing to tackle the
update.cmd part or shall I add it to my todo?

Does anyone want to do the plugins part? Bombe? dbkr?

NextGen$
[1] Here is the security model:
The certificate of checksums.freenetproject.org has been signed by a
real CA... We bundle it in the installer and verify the certificates
with it (It is valid 'till 2036); Arguably we should check some CRLs
too...

Files whose extensions are .sig and .sha1 are downloaded directly
from emu, other filetypes lead to a direct redirection to one of the
mirrors. We check the file we got from the mirror against the SHA1
checksum we downloaded securely from emu.

Everything is handled by apache through RewriteRules, no php vodoo is
involved anymore :)
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: 

[freenet-dev] Trust path, new download location

[Florent Daignière]

Hi,
Over the WE I have been changing a few things on emu...
Three goals here:
1) Make the installation and update process MITM proof
[1]
2) Get rid of the current load-balancer (I wrote it in
php and it sucks...) and limit the number of redirects
to follow to download a file
3) Gradually get rid of all the backward compatibility
stuffs we keep server-side
Hopefully that means less hits on emu and faster downloads.

From now on all the files are downloaded from
https://checksums.freenetproject.org/latest/
... And no, don't ask for it there is no directory listing... We
need to be able to change the URL we use more easily than now;
Hence I've simplified to the minimum the naming scheme: you ask
for the filename and that's it; they are no subdirectories
anymore and latest version of plugins can be accessed directly.

Before I can finish up and move on they are three things which
should be done:
1) update.cmd needs to be updated; imho it could be
rewritten from scratch, using update.sh as model. I can
precisely describe why it sucks if needed. We want all
the scripts to use the Sha1Test class
2) The node should be updated to download plugins from
the new URL and should check the checksums it provides
3) users should be asked to double-check that they have
an up to date updating script and that *it works*; It's
probably something we want to talk about in the next
release-announcement message.
Once those are done I will get rid of two vhosts on emu
(downloads.freenetproject.org and get.freenetproject.org) and
simplify *a lot* the release-building scripts. I'll create a
vhost dedicated to the 0.5 legacy code if someone want it
(complain now or never)... but we can't reasonably keep the
current file hierarchy.

Would anyone object if I force the installer to be downloaded
from emu and disable file-listing in the directory where it will
be ? Lately I heard of weird bugs from some users... and it
turns out they were using a 7 month old installer to set their
nodes up... they used some download-directory (like zdnet.com)
and got their old, deprecated installer from them! Needless to
say there isn't much we can do against that... but checking
referrers and disabling file-listing is something we can do
reasonably easily.

Are Zero3Cool or Juiceman still around and willing to tackle the
update.cmd part or shall I add it to my todo?

Does anyone want to do the plugins part? Bombe? dbkr?

NextGen$
[1] Here is the security model:
The certificate of checksums.freenetproject.org has been signed by a
real CA... We bundle it in the installer and verify the certificates
with it (It is valid 'till 2036); Arguably we should check some CRLs
too...

Files whose extensions are .sig and .sha1 are downloaded directly
from emu, other filetypes lead to a direct redirection to one of the
mirrors. We check the file we got from the mirror against the SHA1
checksum we downloaded securely from emu.

Everything is handled by apache through RewriteRules, no php vodoo is
involved anymore :)


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

[freenet-dev] Chinese translation for dont-close-me / welcome

[Florent Daignière]

* Daniel Cheng  [2008-05-30 11:54:14]:

> On Sun, May 11, 2008 at 11:36 PM, Florent Daigni?re
>  wrote:
> > * Daniel Cheng  [2008-05-11 23:24:06]:
> >
> >> On Sun, May 11, 2008 at 10:58 PM, Florent Daigni?re
> >>  wrote:
> >> > * Daniel Cheng  [2008-05-11 22:51:31]:
> >> >
> >> >> On Sun, May 11, 2008 at 10:49 PM, Daniel Cheng
> >> >>  wrote:
> >> >> > On Sun, May 11, 2008 at 6:53 PM, Florent Daigni?re
> >> >> >  wrote:
> >> >> >> * Daniel Cheng  [2008-05-11 17:32:44]:
> >> >> >>
> >> >> >>> On Sun, May 11, 2008 at 5:11 PM, Florent Daigni?re
> >> >> >>>  wrote:
> >> >> >>> > * Daniel Cheng  [2008-05-11 
> >> >> >>> > 17:03:06]:
> >> >> >>> >
> >> >> >>> >> Hi,
> >> >> >>> >> Here are the Chinese translation for cont-close-me and 
> >> >> >>> >> welcome.html
> >> >> >>> >>
> >> >> >>> >> Regards,
> >> >> >>> >> Daniel Cheng
> >> >> >>> >
> >> >> >>> > Commited in r19890. You might also want to translate 
> >> >> >>> > pack-descriptions
> >> >> >>> > in the installer (see
> >> >> >>> > https://emu.freenetproject.org/svn/trunk/apps/new_installer/langpacks)
> >> >> >>> >
> >> >> >>>
> >> >> >>> There is file for Simplified Chinese (zh-cn) already..  chn.xml
> >> >> >>
> >> >> >> They are a few additionnal strings you might wanna add:
> >> >> >>
> >> >> >
> >> >> > Okay, i have sync most of enu.xml and chn.xml (and converted to utf-8)
> >> >> >
> >> >> Oops.. try this one..
> >> >> I should have been more careful.
> >> >
> >> > Commited in r19893. May you check that it works (aka the encoding isn't
> >> > broken) on the live installer please?
> >> >
> >> > Give ~5mins for mirrors to update though.
> >> >
> >> > sha1:
> >> > 63df1914e5ac7bc3358f4a15cf67785410c9ed58
> >> > /var/www/downloads/alpha/installer/new_installer.jar
> >>
> >> No, it's not working. All plugin descriptions are still in English.
> >
> > I think I've fixed it in r19894 ... but it seems like a few other
> > strings are missing (same for the french one in fact) :/
> >
> 
> I have tried the new installer on windows today.
> The chinese translation show up in the java installer, but it still
> use the English version of dont-close-me.html and welcome.html .
> 
> Thanks.

I might have found why; try post r20144 installers :)

d41f73d9623f2589693fa849bf6df95064029655
/var/www/downloads/alpha/installer/new_installer.jar
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: 

Re: [freenet-dev] Chinese translation for dont-close-me / welcome

[Florent Daignière]

* Daniel Cheng <[EMAIL PROTECTED]> [2008-05-30 11:54:14]:

> On Sun, May 11, 2008 at 11:36 PM, Florent Daignière
> <[EMAIL PROTECTED]> wrote:
> > * Daniel Cheng <[EMAIL PROTECTED]> [2008-05-11 23:24:06]:
> >
> >> On Sun, May 11, 2008 at 10:58 PM, Florent Daignière
> >> <[EMAIL PROTECTED]> wrote:
> >> > * Daniel Cheng <[EMAIL PROTECTED]> [2008-05-11 22:51:31]:
> >> >
> >> >> On Sun, May 11, 2008 at 10:49 PM, Daniel Cheng
> >> >> <[EMAIL PROTECTED]> wrote:
> >> >> > On Sun, May 11, 2008 at 6:53 PM, Florent Daignière
> >> >> > <[EMAIL PROTECTED]> wrote:
> >> >> >> * Daniel Cheng <[EMAIL PROTECTED]> [2008-05-11 17:32:44]:
> >> >> >>
> >> >> >>> On Sun, May 11, 2008 at 5:11 PM, Florent Daignière
> >> >> >>> <[EMAIL PROTECTED]> wrote:
> >> >> >>> > * Daniel Cheng <[EMAIL PROTECTED]> [2008-05-11 17:03:06]:
> >> >> >>> >
> >> >> >>> >> Hi,
> >> >> >>> >> Here are the Chinese translation for cont-close-me and 
> >> >> >>> >> welcome.html
> >> >> >>> >>
> >> >> >>> >> Regards,
> >> >> >>> >> Daniel Cheng
> >> >> >>> >
> >> >> >>> > Commited in r19890. You might also want to translate 
> >> >> >>> > pack-descriptions
> >> >> >>> > in the installer (see
> >> >> >>> > https://emu.freenetproject.org/svn/trunk/apps/new_installer/langpacks)
> >> >> >>> >
> >> >> >>>
> >> >> >>> There is file for Simplified Chinese (zh-cn) already..  chn.xml
> >> >> >>
> >> >> >> They are a few additionnal strings you might wanna add:
> >> >> >>
> >> >> >
> >> >> > Okay, i have sync most of enu.xml and chn.xml (and converted to utf-8)
> >> >> >
> >> >> Oops.. try this one..
> >> >> I should have been more careful.
> >> >
> >> > Commited in r19893. May you check that it works (aka the encoding isn't
> >> > broken) on the live installer please?
> >> >
> >> > Give ~5mins for mirrors to update though.
> >> >
> >> > sha1:
> >> > 63df1914e5ac7bc3358f4a15cf67785410c9ed58
> >> > /var/www/downloads/alpha/installer/new_installer.jar
> >>
> >> No, it's not working. All plugin descriptions are still in English.
> >
> > I think I've fixed it in r19894 ... but it seems like a few other
> > strings are missing (same for the french one in fact) :/
> >
> 
> I have tried the new installer on windows today.
> The chinese translation show up in the java installer, but it still
> use the English version of dont-close-me.html and welcome.html .
> 
> Thanks.

I might have found why; try post r20144 installers :)

d41f73d9623f2589693fa849bf6df95064029655
/var/www/downloads/alpha/installer/new_installer.jar


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

[freenet-dev] [freenet-cvs] r20116 - trunk/freenet/src/freenet/node/fcp

[Florent Daignière]

* bombe at freenetproject.org  [2008-05-28 
20:09:11]:

> Author: bombe
> Date: 2008-05-28 20:09:11 + (Wed, 28 May 2008)
> New Revision: 20116
> 
> Modified:
>trunk/freenet/src/freenet/node/fcp/ClientPut.java
> Log:
> use TargetFilename to find a MIME type before trying Identifier
> 
> Modified: trunk/freenet/src/freenet/node/fcp/ClientPut.java
> ===
> --- trunk/freenet/src/freenet/node/fcp/ClientPut.java 2008-05-28 14:30:01 UTC 
> (rev 20115)
> +++ trunk/freenet/src/freenet/node/fcp/ClientPut.java 2008-05-28 20:09:11 UTC 
> (rev 20116)
> @@ -10,6 +10,7 @@
>  import java.io.UnsupportedEncodingException;
>  import java.net.MalformedURLException;
>  import java.security.MessageDigest;
> +import java.util.Arrays;
>  
>  import freenet.client.ClientMetadata;
>  import freenet.client.DefaultMIMETypes;
> @@ -33,8 +34,6 @@
>  import freenet.support.io.FileBucket;
>  import freenet.support.io.SerializableToFieldSetBucketUtil;
>  
> -import java.util.Arrays;
> -
>  public class ClientPut extends ClientPutBase {
>  
>   final ClientPutter putter;
> @@ -191,6 +190,9 @@
>   if(mimeType == null && origFilename != null) {
>   mimeType = 
> DefaultMIMETypes.guessMIMEType(origFilename.getName(), true);
>   }
> + if (mimeType == null) {
> + mimeType = 
> DefaultMIMETypes.guessMIMEType(targetFilename, true);
> + }

I bet that targetFilename can be null and that you're introducing an NPE
here...
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: 

Re: [freenet-dev] [freenet-cvs] r20116 - trunk/freenet/src/freenet/node/fcp

[Florent Daignière]

* [EMAIL PROTECTED] <[EMAIL PROTECTED]> [2008-05-28 20:09:11]:

> Author: bombe
> Date: 2008-05-28 20:09:11 + (Wed, 28 May 2008)
> New Revision: 20116
> 
> Modified:
>trunk/freenet/src/freenet/node/fcp/ClientPut.java
> Log:
> use TargetFilename to find a MIME type before trying Identifier
> 
> Modified: trunk/freenet/src/freenet/node/fcp/ClientPut.java
> ===
> --- trunk/freenet/src/freenet/node/fcp/ClientPut.java 2008-05-28 14:30:01 UTC 
> (rev 20115)
> +++ trunk/freenet/src/freenet/node/fcp/ClientPut.java 2008-05-28 20:09:11 UTC 
> (rev 20116)
> @@ -10,6 +10,7 @@
>  import java.io.UnsupportedEncodingException;
>  import java.net.MalformedURLException;
>  import java.security.MessageDigest;
> +import java.util.Arrays;
>  
>  import freenet.client.ClientMetadata;
>  import freenet.client.DefaultMIMETypes;
> @@ -33,8 +34,6 @@
>  import freenet.support.io.FileBucket;
>  import freenet.support.io.SerializableToFieldSetBucketUtil;
>  
> -import java.util.Arrays;
> -
>  public class ClientPut extends ClientPutBase {
>  
>   final ClientPutter putter;
> @@ -191,6 +190,9 @@
>   if(mimeType == null && origFilename != null) {
>   mimeType = 
> DefaultMIMETypes.guessMIMEType(origFilename.getName(), true);
>   }
> + if (mimeType == null) {
> + mimeType = 
> DefaultMIMETypes.guessMIMEType(targetFilename, true);
> + }

I bet that targetFilename can be null and that you're introducing an NPE
here...


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

[freenet-dev] [freenet-cvs] r20090 - trunk/freenet/src/freenet/node

[Florent Daignière]

* toad at freenetproject.org  [2008-05-23 23:59:07]:

> Author: toad
> Date: 2008-05-23 23:59:07 + (Fri, 23 May 2008)
> New Revision: 20090
> 
> Modified:
>trunk/freenet/src/freenet/node/Version.java
> Log:
> 1151:
> L10n:
> - More Chinese translations.
> Client layer:
> - USKs: Don't hold the USKFetcher lock while decoding the metadata block. 
> This method can be called from the packet receiver threads, so shouldn't 
> block for I/O.
> - ClientRequestScheduler: Dropped flag was wrong in removePendingKey(), so 
> sometimes we wouldn't remove from offeredKeys => memory leak.
> Datastore:
> - Even faster reconstruction: Don't read the headers unless we need to, seek 
> if we do.
> - Trivial refactoring.
> - Don't read the data if we don't need to.
> - Fix an instant timeout during reconstruction on a huge store.
> Bookmarks:
> - Update editions.
> Dev stuff:
> - Indenting.
> - Logging.
> - Trivial commits to test whether the smartbear (codecollaborator, closed 
> source code review engine we've got access to) integration is working, and to 
> test the attach-a-commit-to-an-existing-review mechanism (which still doesn't 
> work).
> - Comments.
> 
> Website:
> - Ask for and autodetect java 1.5 (not 1.4). German and English versions.
> - Better 404 handling.
> - Cleanup an FAQ item slightly.
> - Delete dead code which was confusing the parser.
> 
> Installer:
> - Require java 1.5.
> 
> Scripts:
> - Fix verify_indent script (add -source 1.4).
> 
> j16sdiz
> toad
> nextgens
> 
> OTHER RECENT PROGRESS: (Not part of 1151, but you may be interested in it):

Heh... so where is the user-alert to warn if a 1.4 jvm is in use ?
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: 

Re: [freenet-dev] [freenet-cvs] r20090 - trunk/freenet/src/freenet/node

[Florent Daignière]

* [EMAIL PROTECTED] <[EMAIL PROTECTED]> [2008-05-23 23:59:07]:

> Author: toad
> Date: 2008-05-23 23:59:07 + (Fri, 23 May 2008)
> New Revision: 20090
> 
> Modified:
>trunk/freenet/src/freenet/node/Version.java
> Log:
> 1151:
> L10n:
> - More Chinese translations.
> Client layer:
> - USKs: Don't hold the USKFetcher lock while decoding the metadata block. 
> This method can be called from the packet receiver threads, so shouldn't 
> block for I/O.
> - ClientRequestScheduler: Dropped flag was wrong in removePendingKey(), so 
> sometimes we wouldn't remove from offeredKeys => memory leak.
> Datastore:
> - Even faster reconstruction: Don't read the headers unless we need to, seek 
> if we do.
> - Trivial refactoring.
> - Don't read the data if we don't need to.
> - Fix an instant timeout during reconstruction on a huge store.
> Bookmarks:
> - Update editions.
> Dev stuff:
> - Indenting.
> - Logging.
> - Trivial commits to test whether the smartbear (codecollaborator, closed 
> source code review engine we've got access to) integration is working, and to 
> test the attach-a-commit-to-an-existing-review mechanism (which still doesn't 
> work).
> - Comments.
> 
> Website:
> - Ask for and autodetect java 1.5 (not 1.4). German and English versions.
> - Better 404 handling.
> - Cleanup an FAQ item slightly.
> - Delete dead code which was confusing the parser.
> 
> Installer:
> - Require java 1.5.
> 
> Scripts:
> - Fix verify_indent script (add -source 1.4).
> 
> j16sdiz
> toad
> nextgens
> 
> OTHER RECENT PROGRESS: (Not part of 1151, but you may be interested in it):

Heh... so where is the user-alert to warn if a 1.4 jvm is in use ?


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

[freenet-dev] Moving to java 1.5

[Florent Daignière]

* Matthew Toseland  [2008-05-21 11:46:57]:

> On Wednesday 21 May 2008 06:42, Florent Daigni?re wrote:
> > * Matthew Toseland  [2008-05-17 21:58:02]:
> > 
> > > 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 reason to stick to java 1.4.
> > > 
> > > Comments?
> > 
> > Last time I was the one who strongly objected (that was in November)...
> > but since then things have changed:
> > 
> > 
> http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2008-February/001172.html
> > 
> > As no one has objected this time let's do it... 
> 
> There have been objections on the grounds that classpath for 1.5 isn't 
> stable. 

http://builder.classpath.org/japi/jdk15-classpath.html

As far as I can see we don't use the problematic bits (swing,
java.security, java.crypto, javax.management, ...) of the API.

> Is IcedTea (or OpenJDK 1.6) sufficiently stable?
> 

It's shipped with fedora and ubuntu now (arguably that's not a valid
point considering that ubuntu is bundling alpha versions of FF).
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: 

[freenet-dev] Moving to java 1.5

[Florent Daignière]

* Matthew Toseland  [2008-05-17 21:58:02]:

> 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 reason to stick to java 1.4.
> 
> Comments?

Last time I was the one who strongly objected (that was in November)...
but since then things have changed:

http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2008-February/001172.html

As no one has objected this time let's do it... We will make the switch 
gradually:

phase 1: (today)
- update the website 
- update the installer to require a 1.5 compliant jvm

phase 2: (before next stable)
- Create a user-alert asking the user to update, bare next
  stable from auto-updating to what will be stable+1 if the jvm
  is not 1.5 compliant

phase 3: (when next stable is out)
- I'll update emu's build scripts to use a 1.5 jvm
- We can start to introduce 1.5 code
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: 

Re: [freenet-dev] Moving to java 1.5

[Florent Daignière]

* Matthew Toseland <[EMAIL PROTECTED]> [2008-05-21 11:46:57]:

> On Wednesday 21 May 2008 06:42, Florent Daignière wrote:
> > * Matthew Toseland <[EMAIL PROTECTED]> [2008-05-17 21:58:02]:
> > 
> > > 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 reason to stick to java 1.4.
> > > 
> > > Comments?
> > 
> > Last time I was the one who strongly objected (that was in November)...
> > but since then things have changed:
> > 
> > 
> http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2008-February/001172.html
> > 
> > As no one has objected this time let's do it... 
> 
> There have been objections on the grounds that classpath for 1.5 isn't 
> stable. 

http://builder.classpath.org/japi/jdk15-classpath.html

As far as I can see we don't use the problematic bits (swing,
java.security, java.crypto, javax.management, ...) of the API.

> Is IcedTea (or OpenJDK 1.6) sufficiently stable?
> 

It's shipped with fedora and ubuntu now (arguably that's not a valid
point considering that ubuntu is bundling alpha versions of FF).


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

Re: [freenet-dev] Moving to java 1.5

[Florent Daignière]

* Matthew Toseland <[EMAIL PROTECTED]> [2008-05-17 21:58:02]:

> 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 reason to stick to java 1.4.
> 
> Comments?

Last time I was the one who strongly objected (that was in November)...
but since then things have changed:

http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2008-February/001172.html

As no one has objected this time let's do it... We will make the switch 
gradually:

phase 1: (today)
- update the website 
- update the installer to require a 1.5 compliant jvm

phase 2: (before next stable)
- Create a user-alert asking the user to update, bare next
  stable from auto-updating to what will be stable+1 if the jvm
  is not 1.5 compliant

phase 3: (when next stable is out)
- I'll update emu's build scripts to use a 1.5 jvm
- We can start to introduce 1.5 code


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

[freenet-dev] CPUID patch from FMS

[Florent Daignière]

* Ian Clarke  [2008-05-17 10:35:59]:

> On Sat, May 17, 2008 at 6:29 AM, Matthew Toseland
>  wrote:
> > As nextgens is worried about anonymous contributions, I thought he might 
> > want
> > to review this before I apply it.
> 
> You know, I wish you guys would at least try using that Smartbear
> software, this is *exactly* what it is designed for and makes
> code-review much easier.
> 

Okay, I've set it up on emu and I'm about to configure the svn-hooks; I
will publish its address when I'm done.

Here is what the doc says about them:

###
Subversion Server Triggers
Subversion server-side hooks can enforce certain workflow rules across all 
Subversion clients:
- Review-before-commit
- Create review automatically upon commit
- Upload changelists upon commit so reviews can be created by revision 
number
###

IMHO we don't want the first option... I'm not sure about the others...
The third one would be useful if we really use the tool and the second
one would actually force us to use it.

Which of the hooks shall I set up ? :)
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: 

Re: [freenet-dev] CPUID patch from FMS

[Florent Daignière]

* Ian Clarke <[EMAIL PROTECTED]> [2008-05-17 10:35:59]:

> On Sat, May 17, 2008 at 6:29 AM, Matthew Toseland
> <[EMAIL PROTECTED]> wrote:
> > As nextgens is worried about anonymous contributions, I thought he might 
> > want
> > to review this before I apply it.
> 
> You know, I wish you guys would at least try using that Smartbear
> software, this is *exactly* what it is designed for and makes
> code-review much easier.
> 

Okay, I've set it up on emu and I'm about to configure the svn-hooks; I
will publish its address when I'm done.

Here is what the doc says about them:

###
Subversion Server Triggers
Subversion server-side hooks can enforce certain workflow rules across all 
Subversion clients:
- Review-before-commit
- Create review automatically upon commit
- Upload changelists upon commit so reviews can be created by revision 
number
###

IMHO we don't want the first option... I'm not sure about the others...
The third one would be useful if we really use the tool and the second
one would actually force us to use it.

Which of the hooks shall I set up ? :)


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

[freenet-dev] Combating bloat (was: Re: Post 0.7?idea:?off-grid darknet!

[Florent Daignière]

* Matthew Toseland  [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 FOR WHAT IS DOES.  We don't have the resources to audit
> > > > > this code, and we can't install 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?
> > 
> > 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?

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: 

[freenet-dev] [freenet-cvs] r19960 - trunk/freenet/src/freenet/clients/http/staticfiles

[Florent Daignière]

* toad at freenetproject.org  [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 bookmarks *only* when we are about to release ?
As the default bookmarks are used only on fresh nodes and the installer
sets up *stable*, it doesn't make any sense to have up to date bookmarks
in trunk, does it ?

Lately they were loads of bookmark-update-only commits...
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: 

[freenet-dev] Combating bloat (was: Re: Post 0.7 idea:?off-grid darknet!

[Florent Daignière]

* Matthew Toseland  [2008-05-19 11:47:16]:

> On Sunday 18 May 2008 05:17, Florent Daigni?re wrote:
> > * Ian Clarke  [2008-05-17 13:35:40]:
> > 
> > > On Sat, May 17, 2008 at 6:10 AM, Matthew Toseland
> > >  wrote:
> > > >> Exactly, which is why Thaw, Freemail, etc are the apps that will
> > > >> motivate users to use Freenet.  Only developers download the JRE, most
> > > >> users get it bundled with Java apps.  The same will be true of
> > > >> Freenet, its a platform, most end-users don't want platforms on their
> > > >> own.  The solution is *not* to bundle, that is just pretending that
> > > >> Freenet is more than it is.
> > > >
> > > > We have a lot of traffic from wikipedia. We have a lot of traffic from
> > > > slashdot. For a user to even understand what Thaw is he must first 
> understand
> > > > what Freenet is. Thaw, Freemail, FMS and jSite, don't have any sort of 
> web
> > > > presence right now.
> > > 
> > > So they should get a web presence, we can't reinvent sourceforge, and
> > > we can't reinvent apt-get, we don't have the resources.
> > > 
> > 
> > Agreed
> > 
> > > > Freenet is not the same as Java. It's a bad metaphor. Maybe it would be 
> a
> > > > better metaphor if any major freenet client had a web presence and
> > > > significant hits of its own, but none of them do. AND WE CAN'T WAIT FOR 
> THEM
> > > > TO GET ONE
> > > 
> > > Why not?  It would be a 30 minute job for those apps to set up with 
> > > Google 
> Code.
> > > 
> > > >, for much the same reason that we couldn't wait for FMS to release
> > > > 0.7.0. That means we have to do what we can for *our users*, which means
> > > > making it as easy as possible to get these client applications.
> > > 
> > > You must think our users are morons if the only way they can use an
> > > app is if we bundle it.  FMS isn't bundled, and it seems to have no
> > > shortage of users.
> > > 
> > > This "we've got to bundle everything" is a classic feature creep
> > > attitude.  If you think being user friendly means installing a bunch
> > > of software on someone's computer without them asking for it then you
> > > have a bizarre notion of user friendliness.
> > > 
> > > We aren't Google Code, we aren't apt-get, and we aren't Sourceforge.
> > > Trying to be those things will be a massive waste of resources.
> > > 
> > 
> > On the other hand, hosting freenet-related projects doesn't involve too
> > much overhead as far as emu's administration is concerned... And it
> > allows us to cross-reference bugs in between applications and the node,
> > which is very handy.
> > 
> > > And of course there is also the issue that we would be installing
> > > 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 FOR WHAT IS DOES.  We don't have the resources to audit
> > > this code, and we can't install 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?

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: 

Re: [freenet-dev] Combating bloat (was: Re: Post 0.7?idea:?off-grid darknet!

[Florent Daignière]

* 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 FOR WHAT IS DOES.  We don't have the resources to audit
> > > > > this code, and we can't install 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?
> > 
> > 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?

That would be much better imho


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

Re: [freenet-dev] [freenet-cvs] r19960 - trunk/freenet/src/freenet/clients/http/staticfiles

[Florent Daignière]

* [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 bookmarks *only* when we are about to release ?
As the default bookmarks are used only on fresh nodes and the installer
sets up *stable*, it doesn't make any sense to have up to date bookmarks
in trunk, does it ?

Lately they were loads of bookmark-update-only commits...


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

Re: [freenet-dev] Combating bloat (was: Re: Post 0.7 idea:?off-grid darknet!

[Florent Daignière]

* 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, etc are the apps that will
> > > >> motivate users to use Freenet.  Only developers download the JRE, most
> > > >> users get it bundled with Java apps.  The same will be true of
> > > >> Freenet, its a platform, most end-users don't want platforms on their
> > > >> own.  The solution is *not* to bundle, that is just pretending that
> > > >> Freenet is more than it is.
> > > >
> > > > We have a lot of traffic from wikipedia. We have a lot of traffic from
> > > > slashdot. For a user to even understand what Thaw is he must first 
> understand
> > > > what Freenet is. Thaw, Freemail, FMS and jSite, don't have any sort of 
> web
> > > > presence right now.
> > > 
> > > So they should get a web presence, we can't reinvent sourceforge, and
> > > we can't reinvent apt-get, we don't have the resources.
> > > 
> > 
> > Agreed
> > 
> > > > Freenet is not the same as Java. It's a bad metaphor. Maybe it would be 
> a
> > > > better metaphor if any major freenet client had a web presence and
> > > > significant hits of its own, but none of them do. AND WE CAN'T WAIT FOR 
> THEM
> > > > TO GET ONE
> > > 
> > > Why not?  It would be a 30 minute job for those apps to set up with 
> > > Google 
> Code.
> > > 
> > > >, for much the same reason that we couldn't wait for FMS to release
> > > > 0.7.0. That means we have to do what we can for *our users*, which means
> > > > making it as easy as possible to get these client applications.
> > > 
> > > You must think our users are morons if the only way they can use an
> > > app is if we bundle it.  FMS isn't bundled, and it seems to have no
> > > shortage of users.
> > > 
> > > This "we've got to bundle everything" is a classic feature creep
> > > attitude.  If you think being user friendly means installing a bunch
> > > of software on someone's computer without them asking for it then you
> > > have a bizarre notion of user friendliness.
> > > 
> > > We aren't Google Code, we aren't apt-get, and we aren't Sourceforge.
> > > Trying to be those things will be a massive waste of resources.
> > > 
> > 
> > On the other hand, hosting freenet-related projects doesn't involve too
> > much overhead as far as emu's administration is concerned... And it
> > allows us to cross-reference bugs in between applications and the node,
> > which is very handy.
> > 
> > > And of course there is also the issue that we would be installing
> > > 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 FOR WHAT IS DOES.  We don't have the resources to audit
> > > this code, and we can't install 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?

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.


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

[freenet-dev] New database for Freenet: db4o

[Florent Daignière]

* Matthew Toseland  [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 persistence needs. I eventually reached the 
> > conclusion that while we can do most of what we need to do with simple 
> > flatfile databases, there are big chunks that will require a real database 
> of 
> > some kind (even if it's only a persistent hash table). db4o has various 
> > advantages:
> > - Robust in real-world use. See for example this testimonial from a company 
> > who used it on cell phones:
> > http://www.db4o.com/about/customers/success/mandalait.aspx
> > BDBJE has not met our expectations in this regard. It seems very sensitive 
> to 
> > unusual situations - in particular, it will spontaneously corrupt and lose 
> > all data on running out of disk space.
> > - True object database: no SQL, simple and powerful queries, etc.
> > - Transparent or manual activation of objects from storage.
> > - 800K jar, so not big enough to be a problem.
> > - Mature and actively maintained.
> > - Allows for future expansion (e.g. passive requests will need to store a 
> fair 
> > amount of persistent data).
> > - Much more flexible than the hand-coded solution I was thinking of. We can 
> > persistent the entire queue (not just the splitfiles), if it's useful to do 
> > that.
> > - Transactions (although this requires some juggling of in-memory objects 
> > on 
> > rollback).
> > 
> > Tasks:
> > - Add db4o to freenet-ext.jar.
> > - Think about using it for the datastore. We don't want to have two 
> databases! 
> > Sdiz's new datastore may be the One True Store, or it may not be. If it's 
> > not, we don't want to keep BDBJE: we could build a db4o-based store, with 
> > or 
> > without LRU replacement. It would have the advantage of filling up more 
> > quickly than sdiz's store. It should require reconstructing less frequently 
> > than BDBJE!
> > - Migrate the client layer, including splitfiles, pendingKeys, and so on, 
> > to 
> > be persisted via db4o. Of course there will be latency here when objects 
> > are 
> > not cached, so we will need to cache a few request choices in advance for 
> > each RequestStarter. And we will need to devise some way to deal with 
> > requests that don't want to be persisted - presumably we'd keep them in RAM.
> > 
> It turns out that db4o does indeed unrecoverably self-corrupt when it runs 
> out 
> of disk space. (Thanks nextgens for getting me to test this!)
> 
> http://amphibian.dyndns.org/bdb4o-test.log
> 

muhahahaha.

Last time I checked the bdb database was recoverable... Okay
it lost some^wmost of the data in the process but at least it did
attempt to recover!

> We will therefore have to keep a fallback. IMHO for the client layer the 
> fallback should be downloads.dat.gz. We are careful not to lose that when we 
> run out of disk space, and it should only contain what is needed to restart 
> requests from the beginning (in practice a lot will come from the store).
> 

...

While we are at it, what's wrong with bdb-je's persistence framework
again ?
http://www.oracle.com/database/berkeley-db/je/index.html

> I apologise if the above was presented as a fait accompli, any input on 
> databases would be appreciated. On Friday, me and Ian spent a long time 
> debating the issue, first and foremost of whether we should even have a 
> database; I was initially in favour of not having one at all, or using jdbm's 
> persistent hashtable class (HTree).
> 
> Personally I think if we have a database it should be a native object 
> database 
> i.e. either Perst or db4o. It also should be robust, low overhead, mature, 
> open source etc. I will start implementing the new client 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 ?
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: 

[freenet-dev] Combating bloat (was: Re: Post 0.7 idea: off-grid darknet!

[Florent Daignière]

* Ian Clarke  [2008-05-17 13:35:40]:

> On Sat, May 17, 2008 at 6:10 AM, Matthew Toseland
>  wrote:
> >> Exactly, which is why Thaw, Freemail, etc are the apps that will
> >> motivate users to use Freenet.  Only developers download the JRE, most
> >> users get it bundled with Java apps.  The same will be true of
> >> Freenet, its a platform, most end-users don't want platforms on their
> >> own.  The solution is *not* to bundle, that is just pretending that
> >> Freenet is more than it is.
> >
> > We have a lot of traffic from wikipedia. We have a lot of traffic from
> > slashdot. For a user to even understand what Thaw is he must first 
> > understand
> > what Freenet is. Thaw, Freemail, FMS and jSite, don't have any sort of web
> > presence right now.
> 
> So they should get a web presence, we can't reinvent sourceforge, and
> we can't reinvent apt-get, we don't have the resources.
> 

Agreed

> > Freenet is not the same as Java. It's a bad metaphor. Maybe it would be a
> > better metaphor if any major freenet client had a web presence and
> > significant hits of its own, but none of them do. AND WE CAN'T WAIT FOR THEM
> > TO GET ONE
> 
> Why not?  It would be a 30 minute job for those apps to set up with Google 
> Code.
> 
> >, for much the same reason that we couldn't wait for FMS to release
> > 0.7.0. That means we have to do what we can for *our users*, which means
> > making it as easy as possible to get these client applications.
> 
> You must think our users are morons if the only way they can use an
> app is if we bundle it.  FMS isn't bundled, and it seems to have no
> shortage of users.
> 
> This "we've got to bundle everything" is a classic feature creep
> attitude.  If you think being user friendly means installing a bunch
> of software on someone's computer without them asking for it then you
> have a bizarre notion of user friendliness.
> 
> We aren't Google Code, we aren't apt-get, and we aren't Sourceforge.
> Trying to be those things will be a massive waste of resources.
> 

On the other hand, hosting freenet-related projects doesn't involve too
much overhead as far as emu's administration is concerned... And it
allows us to cross-reference bugs in between applications and the node,
which is very handy.

> And of course there is also the issue that we would be installing
> 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 FOR WHAT IS DOES.  We don't have the resources to audit
> this code, and we can't install 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.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: 

[freenet-dev] CPUID patch from FMS

[Florent Daignière]

* Matthew Toseland  [2008-05-17 14:44:27]:

> On Saturday 17 May 2008 13:58, Florent Daigni?re wrote:
> > * Florent Daigni?re  [2008-05-17 14:03:10]:
> > 
> > > * Matthew Toseland  [2008-05-17 12:29:09]:
> > > 
> > > > As nextgens is worried about anonymous contributions, I thought he 
> > > > might 
> want 
> > > > to review this before I apply it.
> > > > 
> > > 
> > > There is a related bug in the bug tracker... It's not the only bits that
> > > need updating :/
> > > 
> > > See #74
> > 
> > http://download.intel.com/design/processor/applnots/24161832.pdf
> > 
> http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/25481.pdf
> > 
> > Here are the CPUID codes if you want to update them.
> > 
> So should we or shouldn't we apply yongjhen's patch?

I think that applying that patch instead of updating the whole set of codes
is not the way to go...

If we were really after performances we would recompile the native
libraries with the new libgmp... which has performances boost on that
kind of (recent) processors.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: 

[freenet-dev] CPUID patch from FMS

[Florent Daignière]

* Ian Clarke  [2008-05-17 20:43:17]:

> On Sat, May 17, 2008 at 12:53 PM, Matthew Toseland
>  wrote:
> > On Saturday 17 May 2008 16:35, Ian Clarke wrote:
> >> On Sat, May 17, 2008 at 6:29 AM, Matthew Toseland
> >>  wrote:
> >> > As nextgens is worried about anonymous contributions, I thought he might
> > want
> >> > to review this before I apply it.
> >>
> >> You know, I wish you guys would at least try using that Smartbear
> >> software, this is *exactly* what it is designed for and makes
> >> code-review much easier.
> >
> > I personally review all commits.
> 
> Who reviews your commits?  Perhaps if it were easier, someone would.
> 

Its a matter of time and will more than a tool-related problem afaic :/
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: 

Re: [freenet-dev] New database for Freenet: db4o

[Florent Daignière]

* 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 persistence needs. I eventually reached the 
> > conclusion that while we can do most of what we need to do with simple 
> > flatfile databases, there are big chunks that will require a real database 
> of 
> > some kind (even if it's only a persistent hash table). db4o has various 
> > advantages:
> > - Robust in real-world use. See for example this testimonial from a company 
> > who used it on cell phones:
> > http://www.db4o.com/about/customers/success/mandalait.aspx
> > BDBJE has not met our expectations in this regard. It seems very sensitive 
> to 
> > unusual situations - in particular, it will spontaneously corrupt and lose 
> > all data on running out of disk space.
> > - True object database: no SQL, simple and powerful queries, etc.
> > - Transparent or manual activation of objects from storage.
> > - 800K jar, so not big enough to be a problem.
> > - Mature and actively maintained.
> > - Allows for future expansion (e.g. passive requests will need to store a 
> fair 
> > amount of persistent data).
> > - Much more flexible than the hand-coded solution I was thinking of. We can 
> > persistent the entire queue (not just the splitfiles), if it's useful to do 
> > that.
> > - Transactions (although this requires some juggling of in-memory objects 
> > on 
> > rollback).
> > 
> > Tasks:
> > - Add db4o to freenet-ext.jar.
> > - Think about using it for the datastore. We don't want to have two 
> databases! 
> > Sdiz's new datastore may be the One True Store, or it may not be. If it's 
> > not, we don't want to keep BDBJE: we could build a db4o-based store, with 
> > or 
> > without LRU replacement. It would have the advantage of filling up more 
> > quickly than sdiz's store. It should require reconstructing less frequently 
> > than BDBJE!
> > - Migrate the client layer, including splitfiles, pendingKeys, and so on, 
> > to 
> > be persisted via db4o. Of course there will be latency here when objects 
> > are 
> > not cached, so we will need to cache a few request choices in advance for 
> > each RequestStarter. And we will need to devise some way to deal with 
> > requests that don't want to be persisted - presumably we'd keep them in RAM.
> > 
> It turns out that db4o does indeed unrecoverably self-corrupt when it runs 
> out 
> of disk space. (Thanks nextgens for getting me to test this!)
> 
> http://amphibian.dyndns.org/bdb4o-test.log
> 

muhahahaha.

Last time I checked the bdb database was recoverable... Okay
it lost some^wmost of the data in the process but at least it did
attempt to recover!

> We will therefore have to keep a fallback. IMHO for the client layer the 
> fallback should be downloads.dat.gz. We are careful not to lose that when we 
> run out of disk space, and it should only contain what is needed to restart 
> requests from the beginning (in practice a lot will come from the store).
> 

...

While we are at it, what's wrong with bdb-je's persistence framework
again ?
http://www.oracle.com/database/berkeley-db/je/index.html

> I apologise if the above was presented as a fait accompli, any input on 
> databases would be appreciated. On Friday, me and Ian spent a long time 
> debating the issue, first and foremost of whether we should even have a 
> database; I was initially in favour of not having one at all, or using jdbm's 
> persistent hashtable class (HTree).
> 
> Personally I think if we have a database it should be a native object 
> database 
> i.e. either Perst or db4o. It also should be robust, low overhead, mature, 
> open source etc. I will start implementing the new client 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 ?


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

Re: [freenet-dev] Combating bloat (was: Re: Post 0.7 idea: off-grid darknet!

[Florent Daignière]

* 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 developers download the JRE, most
> >> users get it bundled with Java apps.  The same will be true of
> >> Freenet, its a platform, most end-users don't want platforms on their
> >> own.  The solution is *not* to bundle, that is just pretending that
> >> Freenet is more than it is.
> >
> > We have a lot of traffic from wikipedia. We have a lot of traffic from
> > slashdot. For a user to even understand what Thaw is he must first 
> > understand
> > what Freenet is. Thaw, Freemail, FMS and jSite, don't have any sort of web
> > presence right now.
> 
> So they should get a web presence, we can't reinvent sourceforge, and
> we can't reinvent apt-get, we don't have the resources.
> 

Agreed

> > Freenet is not the same as Java. It's a bad metaphor. Maybe it would be a
> > better metaphor if any major freenet client had a web presence and
> > significant hits of its own, but none of them do. AND WE CAN'T WAIT FOR THEM
> > TO GET ONE
> 
> Why not?  It would be a 30 minute job for those apps to set up with Google 
> Code.
> 
> >, for much the same reason that we couldn't wait for FMS to release
> > 0.7.0. That means we have to do what we can for *our users*, which means
> > making it as easy as possible to get these client applications.
> 
> You must think our users are morons if the only way they can use an
> app is if we bundle it.  FMS isn't bundled, and it seems to have no
> shortage of users.
> 
> This "we've got to bundle everything" is a classic feature creep
> attitude.  If you think being user friendly means installing a bunch
> of software on someone's computer without them asking for it then you
> have a bizarre notion of user friendliness.
> 
> We aren't Google Code, we aren't apt-get, and we aren't Sourceforge.
> Trying to be those things will be a massive waste of resources.
> 

On the other hand, hosting freenet-related projects doesn't involve too
much overhead as far as emu's administration is concerned... And it
allows us to cross-reference bugs in between applications and the node,
which is very handy.

> And of course there is also the issue that we would be installing
> 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 FOR WHAT IS DOES.  We don't have the resources to audit
> this code, and we can't install 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.


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

Re: [freenet-dev] CPUID patch from FMS

[Florent Daignière]

* Matthew Toseland <[EMAIL PROTECTED]> [2008-05-17 14:44:27]:

> On Saturday 17 May 2008 13:58, Florent Daignière wrote:
> > * Florent Daignière <[EMAIL PROTECTED]> [2008-05-17 14:03:10]:
> > 
> > > * Matthew Toseland <[EMAIL PROTECTED]> [2008-05-17 12:29:09]:
> > > 
> > > > As nextgens is worried about anonymous contributions, I thought he 
> > > > might 
> want 
> > > > to review this before I apply it.
> > > > 
> > > 
> > > There is a related bug in the bug tracker... It's not the only bits that
> > > need updating :/
> > > 
> > > See #74
> > 
> > http://download.intel.com/design/processor/applnots/24161832.pdf
> > 
> http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/25481.pdf
> > 
> > Here are the CPUID codes if you want to update them.
> > 
> So should we or shouldn't we apply yongjhen's patch?

I think that applying that patch instead of updating the whole set of codes
is not the way to go...

If we were really after performances we would recompile the native
libraries with the new libgmp... which has performances boost on that
kind of (recent) processors.


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

Re: [freenet-dev] CPUID patch from FMS

[Florent Daignière]

* Ian Clarke <[EMAIL PROTECTED]> [2008-05-17 20:43:17]:

> On Sat, May 17, 2008 at 12:53 PM, Matthew Toseland
> <[EMAIL PROTECTED]> wrote:
> > On Saturday 17 May 2008 16:35, Ian Clarke wrote:
> >> On Sat, May 17, 2008 at 6:29 AM, Matthew Toseland
> >> <[EMAIL PROTECTED]> wrote:
> >> > As nextgens is worried about anonymous contributions, I thought he might
> > want
> >> > to review this before I apply it.
> >>
> >> You know, I wish you guys would at least try using that Smartbear
> >> software, this is *exactly* what it is designed for and makes
> >> code-review much easier.
> >
> > I personally review all commits.
> 
> Who reviews your commits?  Perhaps if it were easier, someone would.
> 

Its a matter of time and will more than a tool-related problem afaic :/


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

[freenet-dev] CPUID patch from FMS

[Florent Daignière]

* Florent Daigni?re  [2008-05-17 14:03:10]:

> * Matthew Toseland  [2008-05-17 12:29:09]:
> 
> > As nextgens is worried about anonymous contributions, I thought he might 
> > want 
> > to review this before I apply it.
> > 
> 
> There is a related bug in the bug tracker... It's not the only bits that
> need updating :/
> 
> See #74

http://download.intel.com/design/processor/applnots/24161832.pdf
http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/25481.pdf

Here are the CPUID codes if you want to update them.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: 

[freenet-dev] CPUID patch from FMS

[Florent Daignière]

* Matthew Toseland  [2008-05-17 12:29:09]:

> As nextgens is worried about anonymous contributions, I thought he might want 
> to review this before I apply it.
> 

There is a related bug in the bug tracker... It's not the only bits that
need updating :/

See #74

> CPUID patch
> From:
> yongjhen at okYcFnYIaKTYWj1K7EfA7LONeLu7Bwazdd4djTIe4eU
>   Date:
> Friday 16 May 2008 03:43:30
>   Groups:
> freenet
>   Followup-To:
> freenet
> Message was signed with unknown key 0xB3FFA5B9.
> The validity of the signature cannot be verified.
>   Hi all,
> 
> This patch makes Freenet recognize Intel Pentium M, Core, and Core 2 as
> Pentium 4 compatible, and load corresponding native BigInteger library.
> Tested on my laptop with Core CPU.
> 
> 
> --- freenet/src/freenet/support/CPUInformation/CPUID.java.orig
> 2008-04-23 15:24:19.0 +0800
> +++ freenet/src/freenet/support/CPUInformation/CPUID.java
> 2008-05-16 10:35:55.0 +0800
> @@ -280,7 +280,10 @@
> }
> public boolean IsPentium4Compatible()
> {
> -   return getCPUFamily() >= 15;
> +   int family = getCPUFamily();
> +   int model = getCPUModel();
> +   return (family >= 15 ||
> +   (family == 6 && (model == 9 || model
> >=13)));
> }
> public String getCPUModelString() throws
> UnknownCPUException {
> if(getCPUFamily() == 4){
> 
> 
> Cheers!
> 
> --
> FMS:  yongjhen at okYcFnYIaKTYWj1K7EfA7LONeLu7Bwazdd4djTIe4eU
> Freemail: yongjhen at alqualonde.freemail
> PGP fingerprint: 88B6 7F21 38E1 01E6 CF3E B1AD 31CC C1F2 B3FF A5B9
> 
> 
>   End of signed message



> ___
> 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: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: 

[freenet-dev] GPG auto-signing key on emu

[Florent Daignière]

* Florent Daigni?re  [2008-05-15 14:56:56]:

> (2) emu's gpg autosigning key has expired and will be renewed when I get
> around to do it

The new key has been generated, you can find details about the key on
http://downloads.freenetproject.org/alpha/README

Ian, toad and me can revoke it if needed.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: 

Re: [freenet-dev] CPUID patch from FMS

[Florent Daignière]

* Florent Daignière <[EMAIL PROTECTED]> [2008-05-17 14:03:10]:

> * Matthew Toseland <[EMAIL PROTECTED]> [2008-05-17 12:29:09]:
> 
> > As nextgens is worried about anonymous contributions, I thought he might 
> > want 
> > to review this before I apply it.
> > 
> 
> There is a related bug in the bug tracker... It's not the only bits that
> need updating :/
> 
> See #74

http://download.intel.com/design/processor/applnots/24161832.pdf
http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/25481.pdf

Here are the CPUID codes if you want to update them.


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

[freenet-dev] indent verification broken (was: Verification of r19955 on emu)

[Florent Daignière]

* Daniel Cheng  [2008-05-16 23:22:15]:

> an empty indent verification message. =(
> 

That's because of two things:
1) we used a 1.4 jvm with assertion disabled to compile and it
didn't like your "assert"
2) the gpg key we use to sign messages has expired and is
pending renewal (same key that the one we use for mirrors)

I'll make emu regenerate the indent-verification message when those two
issues have been addressed.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: 

Re: [freenet-dev] CPUID patch from FMS

[Florent Daignière]

* Matthew Toseland <[EMAIL PROTECTED]> [2008-05-17 12:29:09]:

> As nextgens is worried about anonymous contributions, I thought he might want 
> to review this before I apply it.
> 

There is a related bug in the bug tracker... It's not the only bits that
need updating :/

See #74

> CPUID patch
> From:
> [EMAIL PROTECTED]
>   Date:
> Friday 16 May 2008 03:43:30
>   Groups:
> freenet
>   Followup-To:
> freenet
> Message was signed with unknown key 0xB3FFA5B9.
> The validity of the signature cannot be verified.
>   Hi all,
> 
> This patch makes Freenet recognize Intel Pentium M, Core, and Core 2 as
> Pentium 4 compatible, and load corresponding native BigInteger library.
> Tested on my laptop with Core CPU.
> 
> 
> --- freenet/src/freenet/support/CPUInformation/CPUID.java.orig
> 2008-04-23 15:24:19.0 +0800
> +++ freenet/src/freenet/support/CPUInformation/CPUID.java
> 2008-05-16 10:35:55.0 +0800
> @@ -280,7 +280,10 @@
> }
> public boolean IsPentium4Compatible()
> {
> -   return getCPUFamily() >= 15;
> +   int family = getCPUFamily();
> +   int model = getCPUModel();
> +   return (family >= 15 ||
> +   (family == 6 && (model == 9 || model
> >=13)));
> }
> public String getCPUModelString() throws
> UnknownCPUException {
> if(getCPUFamily() == 4){
> 
> 
> Cheers!
> 
> --
> FMS:  [EMAIL PROTECTED]
> Freemail: [EMAIL PROTECTED]
> PGP fingerprint: 88B6 7F21 38E1 01E6 CF3E B1AD 31CC C1F2 B3FF A5B9
> 
> 
>   End of signed message



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


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

[freenet-dev] GPG auto-signing key on emu

[Florent Daignière]

* Florent Daignière <[EMAIL PROTECTED]> [2008-05-15 14:56:56]:

> (2) emu's gpg autosigning key has expired and will be renewed when I get
> around to do it

The new key has been generated, you can find details about the key on
http://downloads.freenetproject.org/alpha/README

Ian, toad and me can revoke it if needed.


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

Re: [freenet-dev] indent verification broken (was: Verification of r19955 on emu)

[Florent Daignière]

* Daniel Cheng <[EMAIL PROTECTED]> [2008-05-16 23:22:15]:

> an empty indent verification message. =(
> 

That's because of two things:
1) we used a 1.4 jvm with assertion disabled to compile and it
didn't like your "assert"
2) the gpg key we use to sign messages has expired and is
pending renewal (same key that the one we use for mirrors)

I'll make emu regenerate the indent-verification message when those two
issues have been addressed.


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

[freenet-dev] Combating bloat (was: Re: Post 0.7 idea: off-grid darknet!

[Florent Daignière]

* Ian Clarke  [2008-05-16 09:35:34]:

> On Fri, May 16, 2008 at 9:27 AM, Florent Daigni?re
>  wrote:
> >> But the same argument could be used in my Java analogy.  Java has a
> >> far higher profile than many apps written in Java, but it doesn't
> >> follow that Java should bundle all of these apps.
> >
> > Heh, java has a frozen API... last time I checked ours is neither frozen nor
> > even versioned!
> 
> How is that relevant to this discussion?
> 

If you want freenet to be a framework people actually use to write
applications for, then it has to be versioned and to provide some level
of backward-compatibility in between minor versions.

> > [snip.]
> >> > If you did want to push Freenet-the-service, rather than
> >> > Freenet-the-program, I'd suggest that for the late .7 and early .8 you
> >> > continue the focus on making the install simpler.. For example, the
> >> > project could create a Freenet-for-embedded.zip, which defaults to
> >> > opennet only, auto-detects it's IP, and joins the network when the .jar
> >> > is run, rather than asking the user any questions.
> >>
> >> Well, I've been describing Freenet as a platform since around 1999 -
> >> there is nothing new about this.  I think we do need to do some work
> >> to make Freenet more easily embedded, possibly as you suggest.
> >>
> >
> > What about fproxy; shall it be separated from fred too ? I think it
> > should be a plugin to the node.
> 
> Fproxy is the means through which the node is configured, so it
> doesn't make sense to separate it.

The configuration framework is accessible from FCP... Some applications
like Thaw are already using it.

> Technically the freenet->http
> aspect of fproxy is a client app, but since its already tightly
> integrated, and since it is serves as a "gateway" to Freenet, it makes
> sense to keep it part of Freenet.
> 

Well, if you want freenet to run on embedded systems you will have some
tradeoffs to make at some point... I do think that fproxy and its
dependencies (the content-filter could be pluggable too) are nothing but
overhead.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: 

[freenet-dev] Combating bloat (was: Re: Post 0.7 idea: off-grid darknet!

[Florent Daignière]

* Ian Clarke  [2008-05-16 09:21:10]:

> On Thu, May 15, 2008 at 5:09 PM, Colin Davis  wrote:
> > I can certainly understand where you're coming from, and agree that it
> > would be ideal, but I don't think that Freenet is ready to be promoted
> > by application development.. Currently, when Freenet makes a new
> > revision, that hits Slashdot, Reddit, etc, and encourages people to
> > download.. A new revision of Frost/etc doesn't make a blip, and
> > certainly doesn't spur much action.
> 
> But the same argument could be used in my Java analogy.  Java has a
> far higher profile than many apps written in Java, but it doesn't
> follow that Java should bundle all of these apps.
> 

Heh, java has a frozen API... last time I checked ours is neither frozen nor
even versioned!

[snip.]
> > If you did want to push Freenet-the-service, rather than
> > Freenet-the-program, I'd suggest that for the late .7 and early .8 you
> > continue the focus on making the install simpler.. For example, the
> > project could create a Freenet-for-embedded.zip, which defaults to
> > opennet only, auto-detects it's IP, and joins the network when the .jar
> > is run, rather than asking the user any questions.
> 
> Well, I've been describing Freenet as a platform since around 1999 -
> there is nothing new about this.  I think we do need to do some work
> to make Freenet more easily embedded, possibly as you suggest.
> 

What about fproxy; shall it be separated from fred too ? I think it
should be a plugin to the node.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: 

Re: [freenet-dev] Combating bloat (was: Re: Post 0.7 idea: off-grid darknet!

[Florent Daignière]

* Ian Clarke <[EMAIL PROTECTED]> [2008-05-16 09:35:34]:

> On Fri, May 16, 2008 at 9:27 AM, Florent Daignière
> <[EMAIL PROTECTED]> wrote:
> >> But the same argument could be used in my Java analogy.  Java has a
> >> far higher profile than many apps written in Java, but it doesn't
> >> follow that Java should bundle all of these apps.
> >
> > Heh, java has a frozen API... last time I checked ours is neither frozen nor
> > even versioned!
> 
> How is that relevant to this discussion?
> 

If you want freenet to be a framework people actually use to write
applications for, then it has to be versioned and to provide some level
of backward-compatibility in between minor versions.

> > [snip.]
> >> > If you did want to push Freenet-the-service, rather than
> >> > Freenet-the-program, I'd suggest that for the late .7 and early .8 you
> >> > continue the focus on making the install simpler.. For example, the
> >> > project could create a Freenet-for-embedded.zip, which defaults to
> >> > opennet only, auto-detects it's IP, and joins the network when the .jar
> >> > is run, rather than asking the user any questions.
> >>
> >> Well, I've been describing Freenet as a platform since around 1999 -
> >> there is nothing new about this.  I think we do need to do some work
> >> to make Freenet more easily embedded, possibly as you suggest.
> >>
> >
> > What about fproxy; shall it be separated from fred too ? I think it
> > should be a plugin to the node.
> 
> Fproxy is the means through which the node is configured, so it
> doesn't make sense to separate it.

The configuration framework is accessible from FCP... Some applications
like Thaw are already using it.

> Technically the freenet->http
> aspect of fproxy is a client app, but since its already tightly
> integrated, and since it is serves as a "gateway" to Freenet, it makes
> sense to keep it part of Freenet.
> 

Well, if you want freenet to run on embedded systems you will have some
tradeoffs to make at some point... I do think that fproxy and its
dependencies (the content-filter could be pluggable too) are nothing but
overhead.


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

Re: [freenet-dev] Combating bloat (was: Re: Post 0.7 idea: off-grid darknet!

[Florent Daignière]

* Ian Clarke <[EMAIL PROTECTED]> [2008-05-16 09:21:10]:

> On Thu, May 15, 2008 at 5:09 PM, Colin Davis <[EMAIL PROTECTED]> wrote:
> > I can certainly understand where you're coming from, and agree that it
> > would be ideal, but I don't think that Freenet is ready to be promoted
> > by application development.. Currently, when Freenet makes a new
> > revision, that hits Slashdot, Reddit, etc, and encourages people to
> > download.. A new revision of Frost/etc doesn't make a blip, and
> > certainly doesn't spur much action.
> 
> But the same argument could be used in my Java analogy.  Java has a
> far higher profile than many apps written in Java, but it doesn't
> follow that Java should bundle all of these apps.
> 

Heh, java has a frozen API... last time I checked ours is neither frozen nor
even versioned!

[snip.]
> > If you did want to push Freenet-the-service, rather than
> > Freenet-the-program, I'd suggest that for the late .7 and early .8 you
> > continue the focus on making the install simpler.. For example, the
> > project could create a Freenet-for-embedded.zip, which defaults to
> > opennet only, auto-detects it's IP, and joins the network when the .jar
> > is run, rather than asking the user any questions.
> 
> Well, I've been describing Freenet as a platform since around 1999 -
> there is nothing new about this.  I think we do need to do some work
> to make Freenet more easily embedded, possibly as you suggest.
> 

What about fproxy; shall it be separated from fred too ? I think it
should be a plugin to the node.


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

[freenet-dev] [freenet-cvs] r19945 - trunk/freenet/src/freenet/clients/http/staticfiles

[Florent Daignière]

* toad at freenetproject.org  [2008-05-15 15:55:23]:

> Author: toad
> Date: 2008-05-15 15:55:23 + (Thu, 15 May 2008)
> New Revision: 19945
> 
> Modified:
>trunk/freenet/src/freenet/clients/http/staticfiles/defaultbookmarks.dat
> Log:
> Add The Freenet Applications Freesite, if only for its help.
> 

It's ugly. it does more harm than good imho
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: 

[freenet-dev] x509 certificates on emu

[Florent Daignière]

* Matthew Toseland  [2008-05-15 14:03:54]:

> On Thursday 15 May 2008 13:56, you wrote:
> > Hi,
> > 
> > Due to a recent debian-specific bug in openssl, I've regenerated
> > the SSL certificates on emu; here are the new fingerprints:
> > 
> > subject= /C=KR/ST=Daejeon/L=Daejeon/O=freenetproject.org/OU=StartCom Free 
> Certificate 
> Member/CN=emu.freenetproject.org/emailAddress=hostmaster at freenetproject.org
> > SHA1 Fingerprint=F3:8F:A6:8C:73:95:05:03:96:7E:F6:3B:24:D8:B8:AE:AD:E0:66:11
> > 
> > subject= /C=KR/ST=Daejeon/L=Daejeon/O=freenetproject.org/OU=StartCom Free 
> Certificate 
> Member/CN=bugs.freenetproject.org/emailAddress=hostmaster at 
> freenetproject.org
> > SHA1 Fingerprint=B5:C3:DE:5B:64:D1:DF:24:0C:FD:7D:C2:14:77:03:54:2A:B9:35:B1
> > 
> > Apache, dovecot and postfix are using those from now on. I have
> > also changed the key we are using to sign the installer... but
> > as it doesn't work as I'd like it to it might change again
> > soon... Anyway, I will keep you posted.
> 
> Will this break incoming opportunistic SSL?

No that won't; our previous certificate wasn't trusted by any CA.

> Don't other mailers expect the cert to stay the same once they've seen it?

No, if they were accepting non-trusted certificates, there is no point
in rejecting a trusted one...
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: 

[freenet-dev] x509 certificates on emu

[Florent Daignière]

Hi,

Due to a recent debian-specific bug in openssl, I've regenerated
the SSL certificates on emu; here are the new fingerprints:

subject= /C=KR/ST=Daejeon/L=Daejeon/O=freenetproject.org/OU=StartCom Free 
Certificate Member/CN=emu.freenetproject.org/emailAddress=hostmaster at 
freenetproject.org
SHA1 Fingerprint=F3:8F:A6:8C:73:95:05:03:96:7E:F6:3B:24:D8:B8:AE:AD:E0:66:11

subject= /C=KR/ST=Daejeon/L=Daejeon/O=freenetproject.org/OU=StartCom Free 
Certificate Member/CN=bugs.freenetproject.org/emailAddress=hostmaster at 
freenetproject.org
SHA1 Fingerprint=B5:C3:DE:5B:64:D1:DF:24:0C:FD:7D:C2:14:77:03:54:2A:B9:35:B1

Apache, dovecot and postfix are using those from now on. I have
also changed the key we are using to sign the installer... but
as it doesn't work as I'd like it to it might change again
soon... Anyway, I will keep you posted.

NextGen$
PS: 
(1) as most of you have noticed by now emu is currently rejecting
PublicKey authentications... It will stay like that for the time being.
(2) emu's gpg autosigning key has expired and will be renewed when I get
around to do it
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: 

Re: [freenet-dev] [freenet-cvs] r19945 - trunk/freenet/src/freenet/clients/http/staticfiles

[Florent Daignière]

* [EMAIL PROTECTED] <[EMAIL PROTECTED]> [2008-05-15 15:55:23]:

> Author: toad
> Date: 2008-05-15 15:55:23 + (Thu, 15 May 2008)
> New Revision: 19945
> 
> Modified:
>trunk/freenet/src/freenet/clients/http/staticfiles/defaultbookmarks.dat
> Log:
> Add The Freenet Applications Freesite, if only for its help.
> 

It's ugly. it does more harm than good imho


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

Re: [freenet-dev] x509 certificates on emu

[Florent Daignière]

* Matthew Toseland <[EMAIL PROTECTED]> [2008-05-15 14:03:54]:

> On Thursday 15 May 2008 13:56, you wrote:
> > Hi,
> > 
> > Due to a recent debian-specific bug in openssl, I've regenerated
> > the SSL certificates on emu; here are the new fingerprints:
> > 
> > subject= /C=KR/ST=Daejeon/L=Daejeon/O=freenetproject.org/OU=StartCom Free 
> Certificate 
> Member/CN=emu.freenetproject.org/[EMAIL PROTECTED]
> > SHA1 Fingerprint=F3:8F:A6:8C:73:95:05:03:96:7E:F6:3B:24:D8:B8:AE:AD:E0:66:11
> > 
> > subject= /C=KR/ST=Daejeon/L=Daejeon/O=freenetproject.org/OU=StartCom Free 
> Certificate 
> Member/CN=bugs.freenetproject.org/[EMAIL PROTECTED]
> > SHA1 Fingerprint=B5:C3:DE:5B:64:D1:DF:24:0C:FD:7D:C2:14:77:03:54:2A:B9:35:B1
> > 
> > Apache, dovecot and postfix are using those from now on. I have
> > also changed the key we are using to sign the installer... but
> > as it doesn't work as I'd like it to it might change again
> > soon... Anyway, I will keep you posted.
> 
> Will this break incoming opportunistic SSL?

No that won't; our previous certificate wasn't trusted by any CA.

> Don't other mailers expect the cert to stay the same once they've seen it?

No, if they were accepting non-trusted certificates, there is no point
in rejecting a trusted one...


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

[freenet-dev] x509 certificates on emu

[Florent Daignière]

Hi,

Due to a recent debian-specific bug in openssl, I've regenerated
the SSL certificates on emu; here are the new fingerprints:

subject= /C=KR/ST=Daejeon/L=Daejeon/O=freenetproject.org/OU=StartCom Free 
Certificate Member/CN=emu.freenetproject.org/[EMAIL PROTECTED]
SHA1 Fingerprint=F3:8F:A6:8C:73:95:05:03:96:7E:F6:3B:24:D8:B8:AE:AD:E0:66:11

subject= /C=KR/ST=Daejeon/L=Daejeon/O=freenetproject.org/OU=StartCom Free 
Certificate Member/CN=bugs.freenetproject.org/[EMAIL PROTECTED]
SHA1 Fingerprint=B5:C3:DE:5B:64:D1:DF:24:0C:FD:7D:C2:14:77:03:54:2A:B9:35:B1

Apache, dovecot and postfix are using those from now on. I have
also changed the key we are using to sign the installer... but
as it doesn't work as I'd like it to it might change again
soon... Anyway, I will keep you posted.

NextGen$
PS: 
(1) as most of you have noticed by now emu is currently rejecting
PublicKey authentications... It will stay like that for the time being.
(2) emu's gpg autosigning key has expired and will be renewed when I get
around to do it


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

[freenet-dev] Post-0.7.0 priorities

[Florent Daignière]

* Jano  [2008-05-14 12:55:49]:

> Florent Daigni?re wrote:
> 
> > * Jano  [2008-05-14
> > 11:21:05]:
> > 
> >> > Personally I'm pretty skeptical of anything requiring more than 100MB.
> >> 
> >> However, current implementation (IINM) uses the cache to resume downloads.
> >> Thus, downloading anything bigger than that in more than one go has the
> >> potential of a lot of waste in retries (hence BW & time).
> >> 
> >> I know, it's a spurious reason since downloads in progress could be saved
> >> somewhere else until completion... but still is a reason for now.
> >> 
> > 
> > They are good reasons why we shouldn't implement download-resuming.
> 
> Could you please elaborate?
> 

For the n-th. time : not having that "feature" gives users a good
incentive to keep their nodes up.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: 

[freenet-dev] [freenet-cvs] r19914 - trunk/freenet/src/freenet/crypt/ciphers

[Florent Daignière]

* Daniel Cheng  [2008-05-14 19:31:37]:

> On Wed, May 14, 2008 at 2:33 PM, Florent Daigni?re
>  wrote:
> > * Daniel Cheng  [2008-05-14 11:34:19]:
> >  > On 5/14/08, Florent Daigni?re  wrote:
> >  > > * j16sdiz at freenetproject.org  
> > [2008-05-13 16:11:59]:
> >  > >
> >  > > > Author: j16sdiz
> >  > > > Date: 2008-05-13 16:11:59 + (Tue, 13 May 2008)
> >  > > > New Revision: 19914
> >  > > >
> >  > > > Added:
> >  > > >trunk/freenet/src/freenet/crypt/ciphers/RijndaelTest.java
> >  > > > Log:
> >  > > > JUnit for Rijndael
> >  > > >
> >  > > >
> >  > > > Added: trunk/freenet/src/freenet/crypt/ciphers/RijndaelTest.java
> >  > > > ===
> >  > > > --- trunk/freenet/src/freenet/crypt/ciphers/RijndaelTest.java
> >  (rev 0)
> >  > > > +++ trunk/freenet/src/freenet/crypt/ciphers/RijndaelTest.java 
> > 2008-05-13 16:11:59 UTC (rev 19914)
> >  > > > @@ -0,0 +1,95 @@
> >  > > > +/* This code is part of Freenet. It is distributed under the GNU 
> > General
> >  > > > + * Public License, version 2 (or at your option any later version). 
> > See
> >  > > > + * http://www.gnu.org/ for further details of the GPL. */
> >  > > > +package freenet.crypt.ciphers;
> >  > > > +
> >  > > > +import java.util.Arrays;
> >  > > > +import java.util.Random;
> >  > > > +
> >  > > > +import javax.crypto.Cipher;
> >  > > > +
> >  > > > +import freenet.crypt.UnsupportedCipherException;
> >  > > > +import freenet.support.HexUtil;
> >  > > > +import junit.framework.TestCase;
> >  > > > +
> >  > > > +/**
> >  > > > + * @author sdiz
> >  > > > + */
> >  > > > +public class RijndaelTest extends TestCase {
> >  > > > + private final byte[] PLAINTXT128_1 = 
> > HexUtil.hexToBytes("0123456789abcdef1123456789abcdef");
> >  > > > + private final byte[] KEY128_1 = 
> > HexUtil.hexToBytes("deadbeefcafebabe0123456789abcdef");
> >  > > > + private final byte[] CIPHER128_1 = 
> > HexUtil.hexToBytes("8c5b8c04805c0e07dd62b381730d5d10");
> >  > > > +
> >  > > > + private final byte[] PLAINTXT192_1 = 
> > HexUtil.hexToBytes("0123456789abcdef1123456789abcdef2123456789abcdef");
> >  > > > + private final byte[] KEY192_1 = 
> > HexUtil.hexToBytes("deadbeefcafebabe0123456789abcdefcafebabedeadbeef");
> >  > > > + private final byte[] CIPHER192_1 = 
> > HexUtil.hexToBytes("7fae974786a9741d96693654bc7a8aff09b3f116840ffced");
> >  > > > +
> >  > > > + private final byte[] PLAINTXT256_1 = HexUtil
> >  > > > + 
> > .hexToBytes("0123456789abcdef1123456789abcdef2123456789abcdef3123456789abcdef");
> >  > > > + private final byte[] KEY256_1 = HexUtil
> >  > > > + 
> > .hexToBytes("deadbeefcafebabe0123456789abcdefcafebabedeadbeefcafebabe01234567");
> >  > > > + private final byte[] CIPHER256_1 = HexUtil
> >  > > > + 
> > .hexToBytes("6fcbc68fc938e5f5a7c24d7422f4b5f153257b6fb53e0bca26770497dd65078c");
> >  > > > +
> >  > > > + private static final Random rand = new Random();
> >  > >
> >  > > Where did you dig those constants from? presumably FIPS but would you
> >  > > mind putting a reference in a comment please ?
> >  > >
> >  >
> >  > No, it's not from any know reference. I just pick a random key and
> >  > plain text, enipher it, get the ciphertext.
> >  >
> >
> >  Using our implementation or a 3rd party one ?
> >
> >
> >  > I was planning to implement JVM-based AES (bug 2330), this test is
> >  > just a casual test to verify the pure java implementation and jvm
> >  > implementation matches.
> >  >
> >
> >  Well then you should be testing it against the live jvm's code and not
> >  some pre-computed value if that's the point...
> >
> >  Anyway I do suggest you check it against known to be good values:
> >  http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf for
> >  instance.
> >
> 
> No,
> The code we are using is *not* FIPS-197 compliance. The standard test
> vector does not test the use cases we have.

Okay my bad I didn't check it... still, could we check our code against
their test vectors anyway? On top of the checks you've already
written...

That might catch things like the infamous encryption bug we had at some
point. (The code was fine on .5, the usecase changed on .7 and it
wasn't anymore)
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: 

[freenet-dev] Post-0.7.0 priorities

[Florent Daignière]

* Jano  [2008-05-14 11:21:05]:

> > Personally I'm pretty skeptical of anything requiring more than 100MB.
> 
> However, current implementation (IINM) uses the cache to resume downloads.
> Thus, downloading anything bigger than that in more than one go has the
> potential of a lot of waste in retries (hence BW & time).
> 
> I know, it's a spurious reason since downloads in progress could be saved
> somewhere else until completion... but still is a reason for now.
> 

They are good reasons why we shouldn't implement download-resuming.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: 

[freenet-dev] [freenet-cvs] r19914 - trunk/freenet/src/freenet/crypt/ciphers

[Florent Daignière]

* Daniel Cheng  [2008-05-14 11:34:19]:

> On 5/14/08, Florent Daigni?re  wrote:
> > * j16sdiz at freenetproject.org  [2008-05-13 
> > 16:11:59]:
> >
> > > Author: j16sdiz
> > > Date: 2008-05-13 16:11:59 + (Tue, 13 May 2008)
> > > New Revision: 19914
> > >
> > > Added:
> > >trunk/freenet/src/freenet/crypt/ciphers/RijndaelTest.java
> > > Log:
> > > JUnit for Rijndael
> > >
> > >
> > > Added: trunk/freenet/src/freenet/crypt/ciphers/RijndaelTest.java
> > > ===
> > > --- trunk/freenet/src/freenet/crypt/ciphers/RijndaelTest.java 
> > > (rev 0)
> > > +++ trunk/freenet/src/freenet/crypt/ciphers/RijndaelTest.java 2008-05-13 
> > > 16:11:59 UTC (rev 19914)
> > > @@ -0,0 +1,95 @@
> > > +/* This code is part of Freenet. It is distributed under the GNU General
> > > + * Public License, version 2 (or at your option any later version). See
> > > + * http://www.gnu.org/ for further details of the GPL. */
> > > +package freenet.crypt.ciphers;
> > > +
> > > +import java.util.Arrays;
> > > +import java.util.Random;
> > > +
> > > +import javax.crypto.Cipher;
> > > +
> > > +import freenet.crypt.UnsupportedCipherException;
> > > +import freenet.support.HexUtil;
> > > +import junit.framework.TestCase;
> > > +
> > > +/**
> > > + * @author sdiz
> > > + */
> > > +public class RijndaelTest extends TestCase {
> > > + private final byte[] PLAINTXT128_1 = 
> > > HexUtil.hexToBytes("0123456789abcdef1123456789abcdef");
> > > + private final byte[] KEY128_1 = 
> > > HexUtil.hexToBytes("deadbeefcafebabe0123456789abcdef");
> > > + private final byte[] CIPHER128_1 = 
> > > HexUtil.hexToBytes("8c5b8c04805c0e07dd62b381730d5d10");
> > > +
> > > + private final byte[] PLAINTXT192_1 = 
> > > HexUtil.hexToBytes("0123456789abcdef1123456789abcdef2123456789abcdef");
> > > + private final byte[] KEY192_1 = 
> > > HexUtil.hexToBytes("deadbeefcafebabe0123456789abcdefcafebabedeadbeef");
> > > + private final byte[] CIPHER192_1 = 
> > > HexUtil.hexToBytes("7fae974786a9741d96693654bc7a8aff09b3f116840ffced");
> > > +
> > > + private final byte[] PLAINTXT256_1 = HexUtil
> > > + 
> > > .hexToBytes("0123456789abcdef1123456789abcdef2123456789abcdef3123456789abcdef");
> > > + private final byte[] KEY256_1 = HexUtil
> > > + 
> > > .hexToBytes("deadbeefcafebabe0123456789abcdefcafebabedeadbeefcafebabe01234567");
> > > + private final byte[] CIPHER256_1 = HexUtil
> > > + 
> > > .hexToBytes("6fcbc68fc938e5f5a7c24d7422f4b5f153257b6fb53e0bca26770497dd65078c");
> > > +
> > > + private static final Random rand = new Random();
> >
> > Where did you dig those constants from? presumably FIPS but would you
> > mind putting a reference in a comment please ?
> >
> 
> No, it's not from any know reference. I just pick a random key and
> plain text, enipher it, get the ciphertext.
> 

Using our implementation or a 3rd party one ?

> I was planning to implement JVM-based AES (bug 2330), this test is
> just a casual test to verify the pure java implementation and jvm
> implementation matches.
> 

Well then you should be testing it against the live jvm's code and not
some pre-computed value if that's the point...

Anyway I do suggest you check it against known to be good values:
http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf for
instance.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: 

Re: [freenet-dev] Post-0.7.0 priorities

[Florent Daignière]

* Jano <[EMAIL PROTECTED]> [2008-05-14 12:55:49]:

> Florent Daignière wrote:
> 
> > * Jano <[EMAIL PROTECTED]> [2008-05-14
> > 11:21:05]:
> > 
> >> > Personally I'm pretty skeptical of anything requiring more than 100MB.
> >> 
> >> However, current implementation (IINM) uses the cache to resume downloads.
> >> Thus, downloading anything bigger than that in more than one go has the
> >> potential of a lot of waste in retries (hence BW & time).
> >> 
> >> I know, it's a spurious reason since downloads in progress could be saved
> >> somewhere else until completion... but still is a reason for now.
> >> 
> > 
> > They are good reasons why we shouldn't implement download-resuming.
> 
> Could you please elaborate?
> 

For the n-th. time : not having that "feature" gives users a good
incentive to keep their nodes up.


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

Re: [freenet-dev] [freenet-cvs] r19914 - trunk/freenet/src/freenet/crypt/ciphers

[Florent Daignière]

* Daniel Cheng <[EMAIL PROTECTED]> [2008-05-14 19:31:37]:

> On Wed, May 14, 2008 at 2:33 PM, Florent Daignière
> <[EMAIL PROTECTED]> wrote:
> > * Daniel Cheng <[EMAIL PROTECTED]> [2008-05-14 11:34:19]:
> >  > On 5/14/08, Florent Daignière <[EMAIL PROTECTED]> wrote:
> >  > > * [EMAIL PROTECTED] <[EMAIL PROTECTED]> [2008-05-13 16:11:59]:
> >  > >
> >  > > > Author: j16sdiz
> >  > > > Date: 2008-05-13 16:11:59 + (Tue, 13 May 2008)
> >  > > > New Revision: 19914
> >  > > >
> >  > > > Added:
> >  > > >trunk/freenet/src/freenet/crypt/ciphers/RijndaelTest.java
> >  > > > Log:
> >  > > > JUnit for Rijndael
> >  > > >
> >  > > >
> >  > > > Added: trunk/freenet/src/freenet/crypt/ciphers/RijndaelTest.java
> >  > > > ===
> >  > > > --- trunk/freenet/src/freenet/crypt/ciphers/RijndaelTest.java
> >  (rev 0)
> >  > > > +++ trunk/freenet/src/freenet/crypt/ciphers/RijndaelTest.java 
> > 2008-05-13 16:11:59 UTC (rev 19914)
> >  > > > @@ -0,0 +1,95 @@
> >  > > > +/* This code is part of Freenet. It is distributed under the GNU 
> > General
> >  > > > + * Public License, version 2 (or at your option any later version). 
> > See
> >  > > > + * http://www.gnu.org/ for further details of the GPL. */
> >  > > > +package freenet.crypt.ciphers;
> >  > > > +
> >  > > > +import java.util.Arrays;
> >  > > > +import java.util.Random;
> >  > > > +
> >  > > > +import javax.crypto.Cipher;
> >  > > > +
> >  > > > +import freenet.crypt.UnsupportedCipherException;
> >  > > > +import freenet.support.HexUtil;
> >  > > > +import junit.framework.TestCase;
> >  > > > +
> >  > > > +/**
> >  > > > + * @author sdiz
> >  > > > + */
> >  > > > +public class RijndaelTest extends TestCase {
> >  > > > + private final byte[] PLAINTXT128_1 = 
> > HexUtil.hexToBytes("0123456789abcdef1123456789abcdef");
> >  > > > + private final byte[] KEY128_1 = 
> > HexUtil.hexToBytes("deadbeefcafebabe0123456789abcdef");
> >  > > > + private final byte[] CIPHER128_1 = 
> > HexUtil.hexToBytes("8c5b8c04805c0e07dd62b381730d5d10");
> >  > > > +
> >  > > > + private final byte[] PLAINTXT192_1 = 
> > HexUtil.hexToBytes("0123456789abcdef1123456789abcdef2123456789abcdef");
> >  > > > + private final byte[] KEY192_1 = 
> > HexUtil.hexToBytes("deadbeefcafebabe0123456789abcdefcafebabedeadbeef");
> >  > > > + private final byte[] CIPHER192_1 = 
> > HexUtil.hexToBytes("7fae974786a9741d96693654bc7a8aff09b3f116840ffced");
> >  > > > +
> >  > > > + private final byte[] PLAINTXT256_1 = HexUtil
> >  > > > + 
> > .hexToBytes("0123456789abcdef1123456789abcdef2123456789abcdef3123456789abcdef");
> >  > > > + private final byte[] KEY256_1 = HexUtil
> >  > > > + 
> > .hexToBytes("deadbeefcafebabe0123456789abcdefcafebabedeadbeefcafebabe01234567");
> >  > > > + private final byte[] CIPHER256_1 = HexUtil
> >  > > > + 
> > .hexToBytes("6fcbc68fc938e5f5a7c24d7422f4b5f153257b6fb53e0bca26770497dd65078c");
> >  > > > +
> >  > > > + private static final Random rand = new Random();
> >  > >
> >  > > Where did you dig those constants from? presumably FIPS but would you
> >  > > mind putting a reference in a comment please ?
> >  > >
> >  >
> >  > No, it's not from any know reference. I just pick a random key and
> >  > plain text, enipher it, get the ciphertext.
> >  >
> >
> >  Using our implementation or a 3rd party one ?
> >
> >
> >  > I was planning to implement JVM-based AES (bug 2330), this test is
> >  > just a casual test to verify the pure java implementation and jvm
> >  > implementation matches.
> >  >
> >
> >  Well then you should be testing it against the live jvm's code and not
> >  some pre-computed value if that's the point...
> >
> >  Anyway I do suggest you check it against known to be good values:
> >  http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf for
> >  instance.
> >
> 
> No,
> The code we are using is *not* FIPS-197 compliance. The standard test
> vector does not test the use cases we have.

Okay my bad I didn't check it... still, could we check our code against
their test vectors anyway? On top of the checks you've already
written...

That might catch things like the infamous encryption bug we had at some
point. (The code was fine on .5, the usecase changed on .7 and it
wasn't anymore)


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

[freenet-dev] Website not the big problem atm? was Re: Content Management System

[Florent Daignière]

* Ian Clarke  [2008-05-13 13:45:18]:

> On Tue, May 13, 2008 at 12:59 PM, Matthew Toseland
>  wrote:
> >  As nextgens pointed out recently, our current website has a 40% conversion
> >  rate - that is, 40% of our unique visitors downloaded Freenet.
> 
> Firstly, I don't buy that stat, and secondly, the inference you draw
> from it is wrong.
> 
> I don't buy the stat because:
> 
> 40% of visitors view the download page (according to Google
> Analytics), that doesn't mean 40% of visitors downloaded Freenet, or
> really understood what it was when they clicked on this. I think a lot
> of people just habitually click on "Download" when they see it.
> 

The standard corporate method to gather statistics is to phone home or
to ask for feedback through surveys; do we want to do that?

> > Given the
> >  level of political baggage and technicality that Freenet inevitably comes
> >  with, that suggests that the website is not the biggest problem facing us.
> >  No?
> 
> No.  I definitely don't think you can conclude that the website isn't
> a problem from this statistic.

I agree but not for the same reason... Statistics gathered right-after a
big release are irrelevant (the visitor-base is biased: they came here
*because* of the announcement where they read that freenet is and that
it is cool/smart/whatever)... They are unlikely to look for anything but
the download link.

> I mean, just look at it, its a mass of
> text, with a menu the length of the Amazon river. 

I'm more worried about the content itself than how it's presented. Most
of it *is* outdated.

> I've personally had
> many experiences of people not having a clue what Freenet was, nor
> trying it out, even after viewing the website.
> 

That hardly prove anything either. Some man pages are known to be useful and
well-designed pieces of documentation... and still, users don't read
them.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: 

[freenet-dev] [freenet-cvs] r19914 - trunk/freenet/src/freenet/crypt/ciphers

[Florent Daignière]

* j16sdiz at freenetproject.org  [2008-05-13 
16:11:59]:

> Author: j16sdiz
> Date: 2008-05-13 16:11:59 + (Tue, 13 May 2008)
> New Revision: 19914
> 
> Added:
>trunk/freenet/src/freenet/crypt/ciphers/RijndaelTest.java
> Log:
> JUnit for Rijndael
> 
> 
> Added: trunk/freenet/src/freenet/crypt/ciphers/RijndaelTest.java
> ===
> --- trunk/freenet/src/freenet/crypt/ciphers/RijndaelTest.java 
> (rev 0)
> +++ trunk/freenet/src/freenet/crypt/ciphers/RijndaelTest.java 2008-05-13 
> 16:11:59 UTC (rev 19914)
> @@ -0,0 +1,95 @@
> +/* This code is part of Freenet. It is distributed under the GNU General
> + * Public License, version 2 (or at your option any later version). See
> + * http://www.gnu.org/ for further details of the GPL. */
> +package freenet.crypt.ciphers;
> +
> +import java.util.Arrays;
> +import java.util.Random;
> +
> +import javax.crypto.Cipher;
> +
> +import freenet.crypt.UnsupportedCipherException;
> +import freenet.support.HexUtil;
> +import junit.framework.TestCase;
> +
> +/**
> + * @author sdiz
> + */
> +public class RijndaelTest extends TestCase {
> + private final byte[] PLAINTXT128_1 = 
> HexUtil.hexToBytes("0123456789abcdef1123456789abcdef");
> + private final byte[] KEY128_1 = 
> HexUtil.hexToBytes("deadbeefcafebabe0123456789abcdef");
> + private final byte[] CIPHER128_1 = 
> HexUtil.hexToBytes("8c5b8c04805c0e07dd62b381730d5d10");
> +
> + private final byte[] PLAINTXT192_1 = 
> HexUtil.hexToBytes("0123456789abcdef1123456789abcdef2123456789abcdef");
> + private final byte[] KEY192_1 = 
> HexUtil.hexToBytes("deadbeefcafebabe0123456789abcdefcafebabedeadbeef");
> + private final byte[] CIPHER192_1 = 
> HexUtil.hexToBytes("7fae974786a9741d96693654bc7a8aff09b3f116840ffced");
> +
> + private final byte[] PLAINTXT256_1 = HexUtil
> + 
> .hexToBytes("0123456789abcdef1123456789abcdef2123456789abcdef3123456789abcdef");
> + private final byte[] KEY256_1 = HexUtil
> + 
> .hexToBytes("deadbeefcafebabe0123456789abcdefcafebabedeadbeefcafebabe01234567");
> + private final byte[] CIPHER256_1 = HexUtil
> + 
> .hexToBytes("6fcbc68fc938e5f5a7c24d7422f4b5f153257b6fb53e0bca26770497dd65078c");
> +
> + private static final Random rand = new Random();

Where did you dig those constants from? presumably FIPS but would you
mind putting a reference in a comment please ?
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: 

[freenet-dev] Website not the big problem atm? was Re: Content Management System

[Florent Daignière]

* Matthew Toseland  [2008-05-13 19:50:38]:

> On Tuesday 13 May 2008 19:45, Ian Clarke wrote:
> > On Tue, May 13, 2008 at 12:59 PM, Matthew Toseland
> >  wrote:
> > >  As nextgens pointed out recently, our current website has a 40% 
> conversion
> > >  rate - that is, 40% of our unique visitors downloaded Freenet.
> > 
> > Firstly, I don't buy that stat, and secondly, the inference you draw
> > from it is wrong.
> > 
> > I don't buy the stat because:
> > 
> > 40% of visitors view the download page (according to Google
> > Analytics), that doesn't mean 40% of visitors downloaded Freenet, or
> > really understood what it was when they clicked on this. I think a lot
> > of people just habitually click on "Download" when they see it.
> 
> Fair point. Nextgens, can you get us a statistic on the number who actually 
> downloaded new_installer.jar ??

It's not relevant here as windows vista users use the .exe file...
Here are the real-stats in number of hits (not unique visitors)

root at emu:/var/log/vlogger-https/downloads.freenetproject.org# for i in $( ls 
-1 05*); do echo $i:$(zgrep -cE 'GET /alpha/installer/.*install' $i); done
05012008-access.log.gz:418
05022008-access.log.gz:384
05032008-access.log.gz:387
05042008-access.log.gz:408
05052008-access.log.gz:448
05062008-access.log.gz:481
05072008-access.log.gz:389
05082008-access.log.gz:1963
05092008-access.log.gz:6518
05102008-access.log.gz:2596
05112008-access.log:1431
05112008-access.log.gz:1
05122008-access.log:1626
05132008-access.log:1518

for i in $( ls -1 05*); do echo $i:$(zgrep -cE 'GET /download.html' $i); done
05012008-access.log.gz:726
05022008-access.log.gz:623
05032008-access.log.gz:663
05042008-access.log:530
05042008-access.log.gz:0
05052008-access.log.gz:819
05062008-access.log.gz:717
05072008-access.log.gz:668
05082008-access.log.gz:4268
05092008-access.log.gz:15636
05102008-access.log.gz:5203
05112008-access.log:3403
05112008-access.log.gz:4
05122008-access.log:3897
05132008-access.log:3645

We aren't that far from the ~40% announced...
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: 

Re: [freenet-dev] Post-0.7.0 priorities

[Florent Daignière]

* Jano <[EMAIL PROTECTED]> [2008-05-14 11:21:05]:

> > Personally I'm pretty skeptical of anything requiring more than 100MB.
> 
> However, current implementation (IINM) uses the cache to resume downloads.
> Thus, downloading anything bigger than that in more than one go has the
> potential of a lot of waste in retries (hence BW & time).
> 
> I know, it's a spurious reason since downloads in progress could be saved
> somewhere else until completion... but still is a reason for now.
> 

They are good reasons why we shouldn't implement download-resuming.


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

Re: [freenet-dev] [freenet-cvs] r19914 - trunk/freenet/src/freenet/crypt/ciphers

[Florent Daignière]

* Daniel Cheng <[EMAIL PROTECTED]> [2008-05-14 11:34:19]:

> On 5/14/08, Florent Daignière <[EMAIL PROTECTED]> wrote:
> > * [EMAIL PROTECTED] <[EMAIL PROTECTED]> [2008-05-13 16:11:59]:
> >
> > > Author: j16sdiz
> > > Date: 2008-05-13 16:11:59 + (Tue, 13 May 2008)
> > > New Revision: 19914
> > >
> > > Added:
> > >trunk/freenet/src/freenet/crypt/ciphers/RijndaelTest.java
> > > Log:
> > > JUnit for Rijndael
> > >
> > >
> > > Added: trunk/freenet/src/freenet/crypt/ciphers/RijndaelTest.java
> > > ===
> > > --- trunk/freenet/src/freenet/crypt/ciphers/RijndaelTest.java 
> > > (rev 0)
> > > +++ trunk/freenet/src/freenet/crypt/ciphers/RijndaelTest.java 2008-05-13 
> > > 16:11:59 UTC (rev 19914)
> > > @@ -0,0 +1,95 @@
> > > +/* This code is part of Freenet. It is distributed under the GNU General
> > > + * Public License, version 2 (or at your option any later version). See
> > > + * http://www.gnu.org/ for further details of the GPL. */
> > > +package freenet.crypt.ciphers;
> > > +
> > > +import java.util.Arrays;
> > > +import java.util.Random;
> > > +
> > > +import javax.crypto.Cipher;
> > > +
> > > +import freenet.crypt.UnsupportedCipherException;
> > > +import freenet.support.HexUtil;
> > > +import junit.framework.TestCase;
> > > +
> > > +/**
> > > + * @author sdiz
> > > + */
> > > +public class RijndaelTest extends TestCase {
> > > + private final byte[] PLAINTXT128_1 = 
> > > HexUtil.hexToBytes("0123456789abcdef1123456789abcdef");
> > > + private final byte[] KEY128_1 = 
> > > HexUtil.hexToBytes("deadbeefcafebabe0123456789abcdef");
> > > + private final byte[] CIPHER128_1 = 
> > > HexUtil.hexToBytes("8c5b8c04805c0e07dd62b381730d5d10");
> > > +
> > > + private final byte[] PLAINTXT192_1 = 
> > > HexUtil.hexToBytes("0123456789abcdef1123456789abcdef2123456789abcdef");
> > > + private final byte[] KEY192_1 = 
> > > HexUtil.hexToBytes("deadbeefcafebabe0123456789abcdefcafebabedeadbeef");
> > > + private final byte[] CIPHER192_1 = 
> > > HexUtil.hexToBytes("7fae974786a9741d96693654bc7a8aff09b3f116840ffced");
> > > +
> > > + private final byte[] PLAINTXT256_1 = HexUtil
> > > + 
> > > .hexToBytes("0123456789abcdef1123456789abcdef2123456789abcdef3123456789abcdef");
> > > + private final byte[] KEY256_1 = HexUtil
> > > + 
> > > .hexToBytes("deadbeefcafebabe0123456789abcdefcafebabedeadbeefcafebabe01234567");
> > > + private final byte[] CIPHER256_1 = HexUtil
> > > + 
> > > .hexToBytes("6fcbc68fc938e5f5a7c24d7422f4b5f153257b6fb53e0bca26770497dd65078c");
> > > +
> > > + private static final Random rand = new Random();
> >
> > Where did you dig those constants from? presumably FIPS but would you
> > mind putting a reference in a comment please ?
> >
> 
> No, it's not from any know reference. I just pick a random key and
> plain text, enipher it, get the ciphertext.
> 

Using our implementation or a 3rd party one ?

> I was planning to implement JVM-based AES (bug 2330), this test is
> just a casual test to verify the pure java implementation and jvm
> implementation matches.
> 

Well then you should be testing it against the live jvm's code and not
some pre-computed value if that's the point...

Anyway I do suggest you check it against known to be good values:
http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf for
instance.


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

Re: [freenet-dev] Website not the big problem atm? was Re: Content Management System

[Florent Daignière]

* Ian Clarke <[EMAIL PROTECTED]> [2008-05-13 13:45:18]:

> On Tue, May 13, 2008 at 12:59 PM, Matthew Toseland
> <[EMAIL PROTECTED]> wrote:
> >  As nextgens pointed out recently, our current website has a 40% conversion
> >  rate - that is, 40% of our unique visitors downloaded Freenet.
> 
> Firstly, I don't buy that stat, and secondly, the inference you draw
> from it is wrong.
> 
> I don't buy the stat because:
> 
> 40% of visitors view the download page (according to Google
> Analytics), that doesn't mean 40% of visitors downloaded Freenet, or
> really understood what it was when they clicked on this. I think a lot
> of people just habitually click on "Download" when they see it.
> 

The standard corporate method to gather statistics is to phone home or
to ask for feedback through surveys; do we want to do that?

> > Given the
> >  level of political baggage and technicality that Freenet inevitably comes
> >  with, that suggests that the website is not the biggest problem facing us.
> >  No?
> 
> No.  I definitely don't think you can conclude that the website isn't
> a problem from this statistic.

I agree but not for the same reason... Statistics gathered right-after a
big release are irrelevant (the visitor-base is biased: they came here
*because* of the announcement where they read that freenet is and that
it is cool/smart/whatever)... They are unlikely to look for anything but
the download link.

> I mean, just look at it, its a mass of
> text, with a menu the length of the Amazon river. 

I'm more worried about the content itself than how it's presented. Most
of it *is* outdated.

> I've personally had
> many experiences of people not having a clue what Freenet was, nor
> trying it out, even after viewing the website.
> 

That hardly prove anything either. Some man pages are known to be useful and
well-designed pieces of documentation... and still, users don't read
them.


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

Re: [freenet-dev] [freenet-cvs] r19914 - trunk/freenet/src/freenet/crypt/ciphers

[Florent Daignière]

* [EMAIL PROTECTED] <[EMAIL PROTECTED]> [2008-05-13 16:11:59]:

> Author: j16sdiz
> Date: 2008-05-13 16:11:59 + (Tue, 13 May 2008)
> New Revision: 19914
> 
> Added:
>trunk/freenet/src/freenet/crypt/ciphers/RijndaelTest.java
> Log:
> JUnit for Rijndael
> 
> 
> Added: trunk/freenet/src/freenet/crypt/ciphers/RijndaelTest.java
> ===
> --- trunk/freenet/src/freenet/crypt/ciphers/RijndaelTest.java 
> (rev 0)
> +++ trunk/freenet/src/freenet/crypt/ciphers/RijndaelTest.java 2008-05-13 
> 16:11:59 UTC (rev 19914)
> @@ -0,0 +1,95 @@
> +/* This code is part of Freenet. It is distributed under the GNU General
> + * Public License, version 2 (or at your option any later version). See
> + * http://www.gnu.org/ for further details of the GPL. */
> +package freenet.crypt.ciphers;
> +
> +import java.util.Arrays;
> +import java.util.Random;
> +
> +import javax.crypto.Cipher;
> +
> +import freenet.crypt.UnsupportedCipherException;
> +import freenet.support.HexUtil;
> +import junit.framework.TestCase;
> +
> +/**
> + * @author sdiz
> + */
> +public class RijndaelTest extends TestCase {
> + private final byte[] PLAINTXT128_1 = 
> HexUtil.hexToBytes("0123456789abcdef1123456789abcdef");
> + private final byte[] KEY128_1 = 
> HexUtil.hexToBytes("deadbeefcafebabe0123456789abcdef");
> + private final byte[] CIPHER128_1 = 
> HexUtil.hexToBytes("8c5b8c04805c0e07dd62b381730d5d10");
> +
> + private final byte[] PLAINTXT192_1 = 
> HexUtil.hexToBytes("0123456789abcdef1123456789abcdef2123456789abcdef");
> + private final byte[] KEY192_1 = 
> HexUtil.hexToBytes("deadbeefcafebabe0123456789abcdefcafebabedeadbeef");
> + private final byte[] CIPHER192_1 = 
> HexUtil.hexToBytes("7fae974786a9741d96693654bc7a8aff09b3f116840ffced");
> +
> + private final byte[] PLAINTXT256_1 = HexUtil
> + 
> .hexToBytes("0123456789abcdef1123456789abcdef2123456789abcdef3123456789abcdef");
> + private final byte[] KEY256_1 = HexUtil
> + 
> .hexToBytes("deadbeefcafebabe0123456789abcdefcafebabedeadbeefcafebabe01234567");
> + private final byte[] CIPHER256_1 = HexUtil
> + 
> .hexToBytes("6fcbc68fc938e5f5a7c24d7422f4b5f153257b6fb53e0bca26770497dd65078c");
> +
> + private static final Random rand = new Random();

Where did you dig those constants from? presumably FIPS but would you
mind putting a reference in a comment please ?


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

Re: [freenet-dev] Website not the big problem atm? was Re: Content Management System

[Florent Daignière]

* Matthew Toseland <[EMAIL PROTECTED]> [2008-05-13 19:50:38]:

> On Tuesday 13 May 2008 19:45, Ian Clarke wrote:
> > On Tue, May 13, 2008 at 12:59 PM, Matthew Toseland
> > <[EMAIL PROTECTED]> wrote:
> > >  As nextgens pointed out recently, our current website has a 40% 
> conversion
> > >  rate - that is, 40% of our unique visitors downloaded Freenet.
> > 
> > Firstly, I don't buy that stat, and secondly, the inference you draw
> > from it is wrong.
> > 
> > I don't buy the stat because:
> > 
> > 40% of visitors view the download page (according to Google
> > Analytics), that doesn't mean 40% of visitors downloaded Freenet, or
> > really understood what it was when they clicked on this. I think a lot
> > of people just habitually click on "Download" when they see it.
> 
> Fair point. Nextgens, can you get us a statistic on the number who actually 
> downloaded new_installer.jar ??

It's not relevant here as windows vista users use the .exe file...
Here are the real-stats in number of hits (not unique visitors)

[EMAIL PROTECTED]:/var/log/vlogger-https/downloads.freenetproject.org# for i in 
$( ls -1 05*); do echo $i:$(zgrep -cE 'GET /alpha/installer/.*install' $i); done
05012008-access.log.gz:418
05022008-access.log.gz:384
05032008-access.log.gz:387
05042008-access.log.gz:408
05052008-access.log.gz:448
05062008-access.log.gz:481
05072008-access.log.gz:389
05082008-access.log.gz:1963
05092008-access.log.gz:6518
05102008-access.log.gz:2596
05112008-access.log:1431
05112008-access.log.gz:1
05122008-access.log:1626
05132008-access.log:1518

for i in $( ls -1 05*); do echo $i:$(zgrep -cE 'GET /download.html' $i); done
05012008-access.log.gz:726
05022008-access.log.gz:623
05032008-access.log.gz:663
05042008-access.log:530
05042008-access.log.gz:0
05052008-access.log.gz:819
05062008-access.log.gz:717
05072008-access.log.gz:668
05082008-access.log.gz:4268
05092008-access.log.gz:15636
05102008-access.log.gz:5203
05112008-access.log:3403
05112008-access.log.gz:4
05122008-access.log:3897
05132008-access.log:3645

We aren't that far from the ~40% announced...


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

[freenet-dev] Content Management System

[Florent Daignière]

* Ian Clarke  [2008-05-12 23:04:59]:

> On Mon, May 12, 2008 at 9:32 PM, Florent Daigni?re
>  wrote:
> >  I personnaly won't work on it for now. The main point against our
> >  current website is that it's not community-friendly... Let's see if the
> >  community feels involved and will contribute to the presumably
> >  community-friendly sandbox.
> 
> Not sure that this makes much sense.  Seems like you are saying that
> unless the "community" builds up the new site so that its better than
> the current site, then the "community" doesn't deserve a better
> website.  Hmm.  To paraphrase Margaret Thatcher, "There is no such
> thing as community", its all just individuals.
> 

Heh I'm trying to make things move forward here... sorry if that sounded
rude or inappropriate but yeah... I think we need external help to make
any progress here.

Most of the current contributors are coders and don't have good
web-designing skills ... or don't want to do it.

> Freenet needs a website worthy of a respectable and reasonably well
> funded free software project in 2008, unfortunately it doesn't have
> one right now.

We all agree that the current website sucks.

> Maybe Drupal is the answer, maybe not.  Frankly I'm
> not convinced that migrating to a CMS really solves the big problems
> with the website at all.
> 

Me neither... but Michael suggested it and no one strongly objected this
time. Last time someone did suggest it I was the one who did object...
and let's face it, the website hasn't evolved much since then... so
presumably I might have been wrong.

> Either way, its up to us to come up with a website that newbies feel
> comfortable with.  We've been very lucky with funding from large
> donors over the years, but sooner or later that luck is going to run
> out.  We can't assume that when the Google donation runs out in 6
> months, we will find someone else willing to donate $10k+.  We have 6
> months to build up enough of a userbase that we can get >$3k/month in
> donations reliably, or we can wave goodbye to Matthew's full-time
> attention.  Call me a pessimist, but this project is in big trouble if
> we lose Matthew.
> 
> Having an appealing website that efficiently turns newbies into
> dedicated Freenet users (and donors) isn't just some nice thing to
> make us all feel better, its a requirement for the survival of the
> project.

Well what's the solution then? To make Matthew work on the website? to
send a call for help on @announce (possibly a better phrased than mine)?

Shall I forget about the drupal vhost right-now and delete it?
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: 

[freenet-dev] WoT plugin

[Florent Daignière]

* Julien Cornuwel  [2008-05-12 19:14:06]:

> Hi,
> 
> I'm having interrogations about the use of the WoT plugin and I'm
> confronted to a choice :
> 
> The plugin is able to handle multiple local identites. But do you think
> it could be usefull to allow local identities to set different trust
> levels on other identities.
> 
> Possibilities are :
> 
> 1) One identity publish its trustlist and all local identities share the
> same trust tree.
> 2) Every local identity has to handle its own trust list and has its own
> trust tree. That implies that one identity might see someone while
> another won't.
> 
> In my opinion, 1) would fit most uses of the plugin. Except the one
> where you share your node with a person you totally disagree with (quite
> unlikely, isn't it ?).
> 
> The flaw of 2) is that every identity has to set its own trust values
> for every identities. An option could be to allow the user to set a
> "parent" identity that the new identity would share it's trust list with.
> 
> 
> What do you think ?

Go for the second option
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: 

[freenet-dev] Content Management System

[Florent Daignière]

* Michael T?nzer  [2008-05-08 17:41:55]:

> Florent Daigni?re schrieb:
> > * Michael T?nzer  [2008-05-08 05:04:07]:
> It's probably not possible to migrate in two days but it seems that now
> is a good point to start the process, as Ian mentioned he wanted to
> change the website significantly (this also includes the texts). We
> probably should migrate in a soft way and try it in a test environment
> first. The Website would be a good point to start with because it has
> not so much content on it.

Okay, let's try it. I've set a drupal vhost up on emu
(http://wwwtest.freenetproject.org/).

Here is the deal: if it reaches the point where it's actually better
than the actual website then we switch permanently... Otherwise I'll
just delete it. I will grant admin access to whoever wants it... and
can install modules/themes/whatever on request. We need to put some kind
of deadline otherwise nothing will ever be done: what about one month?

I personnaly won't work on it for now. The main point against our
current website is that it's not community-friendly... Let's see if the
community feels involved and will contribute to the presumably
community-friendly sandbox.

> The other things could be done step by step,
> or never if we want to keep them (e.g. I'm not quite convinced about
> drupals bug tracker, but there are definitely better wiki engines than
> wikkawiki).
> 
> > Can a CMS have some level of history ? All the tools we use have
> > native versioning; that's a feature we don't want to loose.
> 
> Drupal has native versioning, I think that's one of the core features
> which made it one of the favourite CMSs for OpenSource projects.

It seems like it's a per-page versioning... that's not what we want, is
it ?
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: 

Re: [freenet-dev] Content Management System

[Florent Daignière]

* Ian Clarke <[EMAIL PROTECTED]> [2008-05-12 23:04:59]:

> On Mon, May 12, 2008 at 9:32 PM, Florent Daignière
> <[EMAIL PROTECTED]> wrote:
> >  I personnaly won't work on it for now. The main point against our
> >  current website is that it's not community-friendly... Let's see if the
> >  community feels involved and will contribute to the presumably
> >  community-friendly sandbox.
> 
> Not sure that this makes much sense.  Seems like you are saying that
> unless the "community" builds up the new site so that its better than
> the current site, then the "community" doesn't deserve a better
> website.  Hmm.  To paraphrase Margaret Thatcher, "There is no such
> thing as community", its all just individuals.
> 

Heh I'm trying to make things move forward here... sorry if that sounded
rude or inappropriate but yeah... I think we need external help to make
any progress here.

Most of the current contributors are coders and don't have good
web-designing skills ... or don't want to do it.

> Freenet needs a website worthy of a respectable and reasonably well
> funded free software project in 2008, unfortunately it doesn't have
> one right now.

We all agree that the current website sucks.

> Maybe Drupal is the answer, maybe not.  Frankly I'm
> not convinced that migrating to a CMS really solves the big problems
> with the website at all.
> 

Me neither... but Michael suggested it and no one strongly objected this
time. Last time someone did suggest it I was the one who did object...
and let's face it, the website hasn't evolved much since then... so
presumably I might have been wrong.

> Either way, its up to us to come up with a website that newbies feel
> comfortable with.  We've been very lucky with funding from large
> donors over the years, but sooner or later that luck is going to run
> out.  We can't assume that when the Google donation runs out in 6
> months, we will find someone else willing to donate $10k+.  We have 6
> months to build up enough of a userbase that we can get >$3k/month in
> donations reliably, or we can wave goodbye to Matthew's full-time
> attention.  Call me a pessimist, but this project is in big trouble if
> we lose Matthew.
> 
> Having an appealing website that efficiently turns newbies into
> dedicated Freenet users (and donors) isn't just some nice thing to
> make us all feel better, its a requirement for the survival of the
> project.

Well what's the solution then? To make Matthew work on the website? to
send a call for help on @announce (possibly a better phrased than mine)?

Shall I forget about the drupal vhost right-now and delete it?


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

Re: [freenet-dev] WoT plugin

[Florent Daignière]

* Julien Cornuwel <[EMAIL PROTECTED]> [2008-05-12 19:14:06]:

> Hi,
> 
> I'm having interrogations about the use of the WoT plugin and I'm
> confronted to a choice :
> 
> The plugin is able to handle multiple local identites. But do you think
> it could be usefull to allow local identities to set different trust
> levels on other identities.
> 
> Possibilities are :
> 
> 1) One identity publish its trustlist and all local identities share the
> same trust tree.
> 2) Every local identity has to handle its own trust list and has its own
> trust tree. That implies that one identity might see someone while
> another won't.
> 
> In my opinion, 1) would fit most uses of the plugin. Except the one
> where you share your node with a person you totally disagree with (quite
> unlikely, isn't it ?).
> 
> The flaw of 2) is that every identity has to set its own trust values
> for every identities. An option could be to allow the user to set a
> "parent" identity that the new identity would share it's trust list with.
> 
> 
> What do you think ?

Go for the second option


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

Re: [freenet-dev] Content Management System

[Florent Daignière]

* Michael Tänzer <[EMAIL PROTECTED]> [2008-05-08 17:41:55]:

> Florent Daignière schrieb:
> > * Michael Tänzer <[EMAIL PROTECTED]> [2008-05-08 05:04:07]:
> It's probably not possible to migrate in two days but it seems that now
> is a good point to start the process, as Ian mentioned he wanted to
> change the website significantly (this also includes the texts). We
> probably should migrate in a soft way and try it in a test environment
> first. The Website would be a good point to start with because it has
> not so much content on it.

Okay, let's try it. I've set a drupal vhost up on emu
(http://wwwtest.freenetproject.org/).

Here is the deal: if it reaches the point where it's actually better
than the actual website then we switch permanently... Otherwise I'll
just delete it. I will grant admin access to whoever wants it... and
can install modules/themes/whatever on request. We need to put some kind
of deadline otherwise nothing will ever be done: what about one month?

I personnaly won't work on it for now. The main point against our
current website is that it's not community-friendly... Let's see if the
community feels involved and will contribute to the presumably
community-friendly sandbox.

> The other things could be done step by step,
> or never if we want to keep them (e.g. I'm not quite convinced about
> drupals bug tracker, but there are definitely better wiki engines than
> wikkawiki).
> 
> > Can a CMS have some level of history ? All the tools we use have
> > native versioning; that's a feature we don't want to loose.
> 
> Drupal has native versioning, I think that's one of the core features
> which made it one of the favourite CMSs for OpenSource projects.

It seems like it's a per-page versioning... that's not what we want, is
it ?


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

[freenet-dev] Subversion 1.5

[Florent Daignière]

* Ian Clarke  [2008-05-11 18:08:23]:

> Merging in Subversion is a major PITA, but fortunately this is about
> to change with version 1.5, see this blog entry for details:
> 
>   http://blog.red-bean.com/sussman/?p=92
> 
> Hopefully this will make it easier for us to use more pervasive use of
> branches.  This means, for example, that if making a big change, this
> can be done in a branch so that trunk remains stable.
> 
> If we wanted to be really ambitious, we could build snapshots of each
> branch too, but that would be a reasonable amount of work.
> 
> Ian.

Another cool feature will be "Relative URLs, peg revisions in
svn:externals"... With it we will be able to make the anonymous and
authenticated repositories coexist.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: 

Re: [freenet-dev] Subversion 1.5

[Florent Daignière]

* Ian Clarke <[EMAIL PROTECTED]> [2008-05-11 18:08:23]:

> Merging in Subversion is a major PITA, but fortunately this is about
> to change with version 1.5, see this blog entry for details:
> 
>   http://blog.red-bean.com/sussman/?p=92
> 
> Hopefully this will make it easier for us to use more pervasive use of
> branches.  This means, for example, that if making a big change, this
> can be done in a branch so that trunk remains stable.
> 
> If we wanted to be really ambitious, we could build snapshots of each
> branch too, but that would be a reasonable amount of work.
> 
> Ian.

Another cool feature will be "Relative URLs, peg revisions in
svn:externals"... With it we will be able to make the anonymous and
authenticated repositories coexist.


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

[freenet-dev] Chinese translation for dont-close-me / welcome

[Florent Daignière]

* Daniel Cheng  [2008-05-11 22:51:31]:

> On Sun, May 11, 2008 at 10:49 PM, Daniel Cheng
>  wrote:
> > On Sun, May 11, 2008 at 6:53 PM, Florent Daigni?re
> >  wrote:
> >> * Daniel Cheng  [2008-05-11 17:32:44]:
> >>
> >>> On Sun, May 11, 2008 at 5:11 PM, Florent Daigni?re
> >>>  wrote:
> >>> > * Daniel Cheng  [2008-05-11 17:03:06]:
> >>> >
> >>> >> Hi,
> >>> >> Here are the Chinese translation for cont-close-me and welcome.html
> >>> >>
> >>> >> Regards,
> >>> >> Daniel Cheng
> >>> >
> >>> > Commited in r19890. You might also want to translate pack-descriptions
> >>> > in the installer (see
> >>> > https://emu.freenetproject.org/svn/trunk/apps/new_installer/langpacks)
> >>> >
> >>>
> >>> There is file for Simplified Chinese (zh-cn) already..  chn.xml
> >>
> >> They are a few additionnal strings you might wanna add:
> >>
> >
> > Okay, i have sync most of enu.xml and chn.xml (and converted to utf-8)
> >
> Oops.. try this one..
> I should have been more careful.

Commited in r19893. May you check that it works (aka the encoding isn't
broken) on the live installer please?

Give ~5mins for mirrors to update though.

sha1:
63df1914e5ac7bc3358f4a15cf67785410c9ed58
/var/www/downloads/alpha/installer/new_installer.jar
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: 

[freenet-dev] Chinese translation for dont-close-me / welcome

[Florent Daignière]

* Daniel Cheng  [2008-05-11 17:03:06]:

> Hi,
> Here are the Chinese translation for cont-close-me and welcome.html
> 
> Regards,
> Daniel Cheng

Commited in r19890. You might also want to translate pack-descriptions
in the installer (see
https://emu.freenetproject.org/svn/trunk/apps/new_installer/langpacks)

NextGen$
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: 

Re: [freenet-dev] Chinese translation for dont-close-me / welcome

[Florent Daignière]

* Daniel Cheng <[EMAIL PROTECTED]> [2008-05-11 22:51:31]:

> On Sun, May 11, 2008 at 10:49 PM, Daniel Cheng
> <[EMAIL PROTECTED]> wrote:
> > On Sun, May 11, 2008 at 6:53 PM, Florent Daignière
> > <[EMAIL PROTECTED]> wrote:
> >> * Daniel Cheng <[EMAIL PROTECTED]> [2008-05-11 17:32:44]:
> >>
> >>> On Sun, May 11, 2008 at 5:11 PM, Florent Daignière
> >>> <[EMAIL PROTECTED]> wrote:
> >>> > * Daniel Cheng <[EMAIL PROTECTED]> [2008-05-11 17:03:06]:
> >>> >
> >>> >> Hi,
> >>> >> Here are the Chinese translation for cont-close-me and welcome.html
> >>> >>
> >>> >> Regards,
> >>> >> Daniel Cheng
> >>> >
> >>> > Commited in r19890. You might also want to translate pack-descriptions
> >>> > in the installer (see
> >>> > https://emu.freenetproject.org/svn/trunk/apps/new_installer/langpacks)
> >>> >
> >>>
> >>> There is file for Simplified Chinese (zh-cn) already..  chn.xml
> >>
> >> They are a few additionnal strings you might wanna add:
> >>
> >
> > Okay, i have sync most of enu.xml and chn.xml (and converted to utf-8)
> >
> Oops.. try this one..
> I should have been more careful.

Commited in r19893. May you check that it works (aka the encoding isn't
broken) on the live installer please?

Give ~5mins for mirrors to update though.

sha1:
63df1914e5ac7bc3358f4a15cf67785410c9ed58
/var/www/downloads/alpha/installer/new_installer.jar


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

Re: [freenet-dev] Chinese translation for dont-close-me / welcome

[Florent Daignière]

* Daniel Cheng <[EMAIL PROTECTED]> [2008-05-11 17:03:06]:

> Hi,
> Here are the Chinese translation for cont-close-me and welcome.html
> 
> Regards,
> Daniel Cheng

Commited in r19890. You might also want to translate pack-descriptions
in the installer (see
https://emu.freenetproject.org/svn/trunk/apps/new_installer/langpacks)

NextGen$


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

[freenet-dev] What to do with the 0.5 related stuffs?

[Florent Daignière]

* Ringo Kamens <2600denver at gmail.com> [2008-05-08 23:35:20]:

> I think we should keep .5 stuff around, since a lot of things link to
> it

We can provide permanent redirects to new content, that's not a problem.

> but there's no reason to advertise it. Also, I get the feeling that
> lots of freenet users don't trust .7 yet and that the .5 community
> will continue to flourish for quite some time.

Where are those users? that's the big question...
They don't use our infrastructure anymore that's for sure.

The number of hits on the .5 pages is ridiculous; We don't get much
downloads either... The only service some are still using is the
seednode-generation one.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: 

[freenet-dev] Content Management System

[Florent Daignière]

* Michael T?nzer  [2008-05-08 22:47:28]:

> Ian Clarke schrieb:
> > You could argue that all of those things have it easy, because most
> > people understand what those things do, they don't need an elaborate
> > explanation.  But look at Gnome's website:
> > 
> >   http://www.gnome.org/
> > 
> > It is clean, simple, yet if you need to you can quickly dig down to a
> > vast wealth of information.
> > 
> 
> Gnome uses Plone as it's CMS. This may be not the best choice for us
> though, as Plone is Phyton based, but that's something nextgens might
> know better than me.
> 

I don't have any problem with using python; Trac is in python too
iirc... But I don't think that Plone is what we need, it's a framework
more than a CMS.

> > Either way, since we are Java hackers for the most part, not web
> > designers, I strongly recommend that we borrow as much as we can from
> > elsewhere, even so far as using free or creative commons HTML and CSS
> > verbatim, perhaps with only a few minor changes.
> > 

What about java-based CMSes then ? :p
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: 

[freenet-dev] [freenet-cvs] r19836 - in trunk/website: . includes pages/de

[Florent Daignière]

* Michael T?nzer  [2008-05-09 09:32:01]:

> Florent Daigni?re schrieb:
> > * Michael T?nzer  [2008-05-08 23:35:21]:
> > 
> >> Some of your changes broke the link to the English news site on the
> >> German one. The old link doesn't work either.
> >> We need that link because the news section needs to be up to date and I
> >> can't always translate it in real time.
> > 
> > Okay, what's the exact url of the broken link ?
> > 
> 
> Well it should link to the English news section, before your changes it
> was href="/index.php?site=news&lang=en" then you changed it to
> href="/news.html?lang=en" neither the old nor the new one work now (one
> just gets the german section, because of the content negotiation with
> the browser).

Fixed :)

Please don't use the old links anymore.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: 

Re: [freenet-dev] What to do with the 0.5 related stuffs?

[Florent Daignière]

* Ringo Kamens <[EMAIL PROTECTED]> [2008-05-08 23:35:20]:

> I think we should keep .5 stuff around, since a lot of things link to
> it

We can provide permanent redirects to new content, that's not a problem.

> but there's no reason to advertise it. Also, I get the feeling that
> lots of freenet users don't trust .7 yet and that the .5 community
> will continue to flourish for quite some time.

Where are those users? that's the big question...
They don't use our infrastructure anymore that's for sure.

The number of hits on the .5 pages is ridiculous; We don't get much
downloads either... The only service some are still using is the
seednode-generation one.


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

Re: [freenet-dev] Content Management System

[Florent Daignière]

* Michael Tänzer <[EMAIL PROTECTED]> [2008-05-08 22:47:28]:

> Ian Clarke schrieb:
> > You could argue that all of those things have it easy, because most
> > people understand what those things do, they don't need an elaborate
> > explanation.  But look at Gnome's website:
> > 
> >   http://www.gnome.org/
> > 
> > It is clean, simple, yet if you need to you can quickly dig down to a
> > vast wealth of information.
> > 
> 
> Gnome uses Plone as it's CMS. This may be not the best choice for us
> though, as Plone is Phyton based, but that's something nextgens might
> know better than me.
> 

I don't have any problem with using python; Trac is in python too
iirc... But I don't think that Plone is what we need, it's a framework
more than a CMS.

> > Either way, since we are Java hackers for the most part, not web
> > designers, I strongly recommend that we borrow as much as we can from
> > elsewhere, even so far as using free or creative commons HTML and CSS
> > verbatim, perhaps with only a few minor changes.
> > 

What about java-based CMSes then ? :p


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

[freenet-dev] [freenet-cvs] r19836 - in trunk/website: . includes pages/de

[Florent Daignière]

* Michael T?nzer  [2008-05-08 23:35:21]:

> Some of your changes broke the link to the English news site on the
> German one. The old link doesn't work either.
> We need that link because the news section needs to be up to date and I
> can't always translate it in real time.

Okay, what's the exact url of the broken link ?
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: 

[freenet-dev] What to do with the 0.5 related stuffs?

[Florent Daignière]

Hi,

I'm currently in the process of cleaning up our server... And
I'm planning to get rid of all the .5-related stuffs now that
0.7 is officially released. That includes our builds and
seednode files hosted on downloads.freenetproject.org, a *lot*
of apache redirection for old URLs and the short mention of it
on the download page of our website.

Obviously we will keep the source code in our svn-tree.

Any objection? If so, object soon or never.

NextGen$
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: 

Re: [freenet-dev] [freenet-cvs] r19836 - in trunk/website: . includes pages/de

[Florent Daignière]

* Michael Tänzer <[EMAIL PROTECTED]> [2008-05-09 09:32:01]:

> Florent Daignière schrieb:
> > * Michael Tänzer <[EMAIL PROTECTED]> [2008-05-08 23:35:21]:
> > 
> >> Some of your changes broke the link to the English news site on the
> >> German one. The old link doesn't work either.
> >> We need that link because the news section needs to be up to date and I
> >> can't always translate it in real time.
> > 
> > Okay, what's the exact url of the broken link ?
> > 
> 
> Well it should link to the English news section, before your changes it
> was href="/index.php?site=news&lang=en" then you changed it to
> href="/news.html?lang=en" neither the old nor the new one work now (one
> just gets the german section, because of the content negotiation with
> the browser).

Fixed :)

Please don't use the old links anymore.


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

Re: [freenet-dev] [freenet-cvs] r19836 - in trunk/website: . includes pages/de

[Florent Daignière]

* Michael Tänzer <[EMAIL PROTECTED]> [2008-05-08 23:35:21]:

> Some of your changes broke the link to the English news site on the
> German one. The old link doesn't work either.
> We need that link because the news section needs to be up to date and I
> can't always translate it in real time.

Okay, what's the exact url of the broken link ?


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

[freenet-dev] What to do with the 0.5 related stuffs?

[Florent Daignière]

Hi,

I'm currently in the process of cleaning up our server... And
I'm planning to get rid of all the .5-related stuffs now that
0.7 is officially released. That includes our builds and
seednode files hosted on downloads.freenetproject.org, a *lot*
of apache redirection for old URLs and the short mention of it
on the download page of our website.

Obviously we will keep the source code in our svn-tree.

Any objection? If so, object soon or never.

NextGen$


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

[freenet-dev] Content Management System

[Florent Daignière]

* Michael T?nzer  [2008-05-08 17:41:55]:

> Florent Daigni?re schrieb:
> > * Michael T?nzer  [2008-05-08 05:04:07]:
> > 
> >> In the last few weeks I've done some work on the website. While
> >> translating it, there were some things that struck me so I changed them.
> >> But our site is still far from perfect. It lacks a attractive design and
> >> some features that would be quite handy (e.g. select the language by
> >> hand, RSS-Feeds, a search) but are a little bit difficult to implement
> >> (at least if we want to do it in a safe and efficient way) or at least I
> >> don't have the time and skills to do it.
> > 
> > Select language by hand is trivial to implement and we can delegate the 
> > search
> > to google so that's trivial too... okay RSS would require some work
> > 
> 
> I know it's not that hard to do but someone actually has to do it.

No one has bothered that's why it hasn't been done.

[snip.]

> > At the moment we are using mantis as a BTS, Wikka as a wiki-engine, a
> > home-maid website and *loads* of custom scripting for almost
> > everything... How do you plan to migrate existing content ?
> > 
> 
> The fully custom made site is one of the problems, as we are not experts
> in some of the things we did. I saw that you fixed some security issues
> in our php code today, some issues that dealt with character escaping
> and such things.

The broken code wasn't mine! I have already fixed the exact same bug 3
years ago and someone reintroduced it since then!

We should really have regression tests; even for the website.

> I'm no PHP expert but I think these are things which
> are obvious to a professional php-developer but can completely break our
> security, which means if some  here> guy used this issue to hack into our server and replace the
> binaries we provide, then this could be rather dangerous for our users.
> 

I'm not a fan of security by obscurity but let's face it: we have fixed
only a few security related bugs in the last few years... Drupal had many
more (and that's logical given that it's a gaz plant compared to our
requirements). Their last release was on the 9th of April and guess
what? It's a security bugfix!

> What I want to say: If you're not absolutely sure about what you're
> doing, leave it to the pros, they know how to deal with it, and we can
> concentrate on what we do best: provide our users with tools to give
> them true freedom of speech.
> 

Go on with that logic... and we end up being dependant on a 3rd party
entity. We left SourceForge because their service wasn't up to our
expectations anymore and at the time there was no good alternative.

> It's probably not possible to migrate in two days but it seems that now
> is a good point to start the process, as Ian mentioned he wanted to
> change the website significantly (this also includes the texts). We
> probably should migrate in a soft way and try it in a test environment
> first. The Website would be a good point to start with because it has
> not so much content on it. The other things could be done step by step,
> or never if we want to keep them (e.g. I'm not quite convinced about
> drupals bug tracker, but there are definitely better wiki engines than
> wikkawiki).

I don't share your views here. Either we switch to a CMS and use it for
everything or we don't.

They are good and bad reasons to switch to a CMS: I don't think that
security is a good one. As you've highlighted, our website doesn't
evolve much and has a long history; that's why it's pretty secure
overall. On the other hand, integration of services into the CMS
is a good reason to make the switch. Find a CMS which has a good
integration with mantis or can import its tickets and then we can
consider a migration seriously. If it was up to me, we would use Trac
and only Trac (for the website, wikki and bug-tracker).

A few weeks ago someone asked me to set a blog engine up (Wordpress), I
did and so far no one used it... We obviously don't want the same thing
to happen with a Drupal, do we ?
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: 

[freenet-dev] Content Management System

[Florent Daignière]

* Michael T?nzer  [2008-05-08 05:04:07]:

> In the last few weeks I've done some work on the website. While
> translating it, there were some things that struck me so I changed them.
> But our site is still far from perfect. It lacks a attractive design and
> some features that would be quite handy (e.g. select the language by
> hand, RSS-Feeds, a search) but are a little bit difficult to implement
> (at least if we want to do it in a safe and efficient way) or at least I
> don't have the time and skills to do it.

Select language by hand is trivial to implement and we can delegate the search
to google so that's trivial too... okay RSS would require some work

> I also noticed, that the format
> we use to save the content (it's just a php file containing HTML which
> is included in some kind of very simple template) leaves room for
> optimization (for both, the author who needs to write valid HTML and
> know about the things he can do with it (not all of us do know how to
> write clean and valid HTML (I do not exclude myself from this
> statement)), and the user, who might get malformed HTML or ugly pages
> because the browser has some bugs the author didn't know of). We also
> have the problem, that our site consists of many different components:
> there's the homepage, the wiki, emu, SVN, which looks very fragmented.
> 
> We could address most of this problems by using a CMS (content
> management system).

It's not the first time it's being debated...

> Of course a CMS is not a Swiss Army knife for
> everything and it does raise several issues: is it fast enough to
> survive a slashdot, can we use our already existent database, how can we
> migrate, is it safe?

Don't worry about performances for now...

At the moment we are using mantis as a BTS, Wikka as a wiki-engine, a
home-maid website and *loads* of custom scripting for almost
everything... How do you plan to migrate existing content ?

Can a CMS have some level of history ? All the tools we use have
native versioning; that's a feature we don't want to loose.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: 

Re: [freenet-dev] Content Management System

[Florent Daignière]

* Michael Tänzer <[EMAIL PROTECTED]> [2008-05-08 17:41:55]:

> Florent Daignière schrieb:
> > * Michael Tänzer <[EMAIL PROTECTED]> [2008-05-08 05:04:07]:
> > 
> >> In the last few weeks I've done some work on the website. While
> >> translating it, there were some things that struck me so I changed them.
> >> But our site is still far from perfect. It lacks a attractive design and
> >> some features that would be quite handy (e.g. select the language by
> >> hand, RSS-Feeds, a search) but are a little bit difficult to implement
> >> (at least if we want to do it in a safe and efficient way) or at least I
> >> don't have the time and skills to do it.
> > 
> > Select language by hand is trivial to implement and we can delegate the 
> > search
> > to google so that's trivial too... okay RSS would require some work
> > 
> 
> I know it's not that hard to do but someone actually has to do it.

No one has bothered that's why it hasn't been done.

[snip.]

> > At the moment we are using mantis as a BTS, Wikka as a wiki-engine, a
> > home-maid website and *loads* of custom scripting for almost
> > everything... How do you plan to migrate existing content ?
> > 
> 
> The fully custom made site is one of the problems, as we are not experts
> in some of the things we did. I saw that you fixed some security issues
> in our php code today, some issues that dealt with character escaping
> and such things.

The broken code wasn't mine! I have already fixed the exact same bug 3
years ago and someone reintroduced it since then!

We should really have regression tests; even for the website.

> I'm no PHP expert but I think these are things which
> are obvious to a professional php-developer but can completely break our
> security, which means if some  here> guy used this issue to hack into our server and replace the
> binaries we provide, then this could be rather dangerous for our users.
> 

I'm not a fan of security by obscurity but let's face it: we have fixed
only a few security related bugs in the last few years... Drupal had many
more (and that's logical given that it's a gaz plant compared to our
requirements). Their last release was on the 9th of April and guess
what? It's a security bugfix!

> What I want to say: If you're not absolutely sure about what you're
> doing, leave it to the pros, they know how to deal with it, and we can
> concentrate on what we do best: provide our users with tools to give
> them true freedom of speech.
> 

Go on with that logic... and we end up being dependant on a 3rd party
entity. We left SourceForge because their service wasn't up to our
expectations anymore and at the time there was no good alternative.

> It's probably not possible to migrate in two days but it seems that now
> is a good point to start the process, as Ian mentioned he wanted to
> change the website significantly (this also includes the texts). We
> probably should migrate in a soft way and try it in a test environment
> first. The Website would be a good point to start with because it has
> not so much content on it. The other things could be done step by step,
> or never if we want to keep them (e.g. I'm not quite convinced about
> drupals bug tracker, but there are definitely better wiki engines than
> wikkawiki).

I don't share your views here. Either we switch to a CMS and use it for
everything or we don't.

They are good and bad reasons to switch to a CMS: I don't think that
security is a good one. As you've highlighted, our website doesn't
evolve much and has a long history; that's why it's pretty secure
overall. On the other hand, integration of services into the CMS
is a good reason to make the switch. Find a CMS which has a good
integration with mantis or can import its tickets and then we can
consider a migration seriously. If it was up to me, we would use Trac
and only Trac (for the website, wikki and bug-tracker).

A few weeks ago someone asked me to set a blog engine up (Wordpress), I
did and so far no one used it... We obviously don't want the same thing
to happen with a Drupal, do we ?


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

Re: [freenet-dev] Content Management System

[Florent Daignière]

* Michael Tänzer <[EMAIL PROTECTED]> [2008-05-08 05:04:07]:

> In the last few weeks I've done some work on the website. While
> translating it, there were some things that struck me so I changed them.
> But our site is still far from perfect. It lacks a attractive design and
> some features that would be quite handy (e.g. select the language by
> hand, RSS-Feeds, a search) but are a little bit difficult to implement
> (at least if we want to do it in a safe and efficient way) or at least I
> don't have the time and skills to do it.

Select language by hand is trivial to implement and we can delegate the search
to google so that's trivial too... okay RSS would require some work

> I also noticed, that the format
> we use to save the content (it's just a php file containing HTML which
> is included in some kind of very simple template) leaves room for
> optimization (for both, the author who needs to write valid HTML and
> know about the things he can do with it (not all of us do know how to
> write clean and valid HTML (I do not exclude myself from this
> statement)), and the user, who might get malformed HTML or ugly pages
> because the browser has some bugs the author didn't know of). We also
> have the problem, that our site consists of many different components:
> there's the homepage, the wiki, emu, SVN, which looks very fragmented.
> 
> We could address most of this problems by using a CMS (content
> management system).

It's not the first time it's being debated...

> Of course a CMS is not a Swiss Army knife for
> everything and it does raise several issues: is it fast enough to
> survive a slashdot, can we use our already existent database, how can we
> migrate, is it safe?

Don't worry about performances for now...

At the moment we are using mantis as a BTS, Wikka as a wiki-engine, a
home-maid website and *loads* of custom scripting for almost
everything... How do you plan to migrate existing content ?

Can a CMS have some level of history ? All the tools we use have
native versioning; that's a feature we don't want to loose.


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