On 16-03-2012 15:13, Matthew Toseland wrote:
Updating its own binaries is incompatible with the standard unix way
of doing things, isn't it? Even if it's not technically a violation of
FHS?
I'd just like to point out that this is not the case at all, specially
because flexibility is a major c
On Thursday 22 Mar 2012 20:34:53 Ximin Luo wrote:
> On 22/03/12 12:00, Matthew Toseland wrote:
> > On Wednesday 21 Mar 2012 00:30:42 Ximin Luo wrote:
> >> "Implicit dependency" means that changing some code in one area results in
> >> a
> >> logical error in the other, that is not immediately appa
On Friday 23 Mar 2012 13:23:50 Ian Clarke wrote:
> On Thu, Mar 22, 2012 at 7:00 AM, Matthew Toseland amphibian.dyndns.org
> > wrote:
>
> > Making stuff static is tempting but means we can't do
> > multi-nodes-in-one-VM tests
>
> Have we ever actually done that? It seems like we're always making
On Thu, Mar 22, 2012 at 7:00 AM, Matthew Toseland wrote:
> Making stuff static is tempting but means we can't do
> multi-nodes-in-one-VM tests
Have we ever actually done that? It seems like we're always making
decisions to accomodate rare (and sometimes fictional) edge-cases.
Ian.
--
Ian Cl
On Thursday 22 Mar 2012 20:34:53 Ximin Luo wrote:
> On 22/03/12 12:00, Matthew Toseland wrote:
> > On Wednesday 21 Mar 2012 00:30:42 Ximin Luo wrote:
> >> "Implicit dependency" means that changing some code in one area results in
> >> a
> >> logical error in the other, that is not immediately appa
On Friday 23 Mar 2012 13:23:50 Ian Clarke wrote:
> On Thu, Mar 22, 2012 at 7:00 AM, Matthew Toseland > wrote:
>
> > Making stuff static is tempting but means we can't do
> > multi-nodes-in-one-VM tests
>
> Have we ever actually done that? It seems like we're always making
> decisions to accomod
On Thu, Mar 22, 2012 at 7:00 AM, Matthew Toseland wrote:
> Making stuff static is tempting but means we can't do
> multi-nodes-in-one-VM tests
Have we ever actually done that? It seems like we're always making
decisions to accomodate rare (and sometimes fictional) edge-cases.
Ian.
--
Ian Cl
On 22/03/12 12:00, Matthew Toseland wrote:
> On Wednesday 21 Mar 2012 00:30:42 Ximin Luo wrote:
>> "Implicit dependency" means that changing some code in one area results in a
>> logical error in the other, that is not immediately apparent in the
>> documentation nor any compile-time checking built
On 22/03/12 12:00, Matthew Toseland wrote:
> On Wednesday 21 Mar 2012 00:30:42 Ximin Luo wrote:
>> "Implicit dependency" means that changing some code in one area results in a
>> logical error in the other, that is not immediately apparent in the
>> documentation nor any compile-time checking built
On Wednesday 21 Mar 2012 00:30:42 Ximin Luo wrote:
> "Implicit dependency" means that changing some code in one area results in a
> logical error in the other, that is not immediately apparent in the
> documentation nor any compile-time checking built into the language. Obviously
> this is not nece
On Wednesday 21 Mar 2012 00:30:42 Ximin Luo wrote:
> "Implicit dependency" means that changing some code in one area results in a
> logical error in the other, that is not immediately apparent in the
> documentation nor any compile-time checking built into the language. Obviously
> this is not nece
Holy crap toad you need to take your head out of your ass. I'm losing patience
with your persistent denial that the freenet code simply SUCKS BALLS in quite a
lot of areas.
"Implicit dependency" means that changing some code in one area results in a
logical error in the other, that is not immediat
On Monday 19 Mar 2012 01:52:19 Ximin Luo wrote:
> On 16/03/12 18:13, Matthew Toseland wrote:
> > On Thursday 15 Mar 2012 21:02:26 Ximin Luo wrote:
> >> (Top-posting because previous post is too long to reply to in-line.)
> >>
> >> ## refactoring
> >>
> >> Refactoring the code helps to make it more
Holy crap toad you need to take your head out of your ass. I'm losing patience
with your persistent denial that the freenet code simply SUCKS BALLS in quite a
lot of areas.
"Implicit dependency" means that changing some code in one area results in a
logical error in the other, that is not immediat
On Monday 19 Mar 2012 01:52:19 Ximin Luo wrote:
> On 16/03/12 18:13, Matthew Toseland wrote:
> > On Thursday 15 Mar 2012 21:02:26 Ximin Luo wrote:
> >> (Top-posting because previous post is too long to reply to in-line.)
> >>
> >> ## refactoring
> >>
> >> Refactoring the code helps to make it more
On 18-03-2012 22:11, Ximin Luo wrote:
> On 19/03/12 01:09, Ximin Luo wrote:
>> On 16/03/12 23:09, Marco Schulze wrote:
>>> Well, the obvious question is 'why?'. Using /opt + /usr/bin scripts +
>>> service
>>> scripts seems to be good enough. Either way, fred .jar paths are
>>> configurable,
>>>
On 18-03-2012 21:57, Matthew Toseland wrote:
> On Friday 16 Mar 2012 20:38:46 Marco Schulze wrote:
>> On 16-03-2012 15:13, Matthew Toseland wrote:
>>> Updating its own binaries is incompatible with the standard unix way
>>> of doing things, isn't it? Even if it's not technically a violation of
>>>
On 18-03-2012 22:11, Ximin Luo wrote:
On 19/03/12 01:09, Ximin Luo wrote:
On 16/03/12 23:09, Marco Schulze wrote:
Well, the obvious question is 'why?'. Using /opt + /usr/bin scripts + service
scripts seems to be good enough. Either way, fred .jar paths are configurable,
the jars themselves sho
On 18-03-2012 21:57, Matthew Toseland wrote:
On Friday 16 Mar 2012 20:38:46 Marco Schulze wrote:
On 16-03-2012 15:13, Matthew Toseland wrote:
Updating its own binaries is incompatible with the standard unix way
of doing things, isn't it? Even if it's not technically a violation of
FHS?
I'd jus
On 16/03/12 18:13, Matthew Toseland wrote:
> On Thursday 15 Mar 2012 21:02:26 Ximin Luo wrote:
>> (Top-posting because previous post is too long to reply to in-line.)
>>
>> ## refactoring
>>
>> Refactoring the code helps to make it more understandable for other coders.
>> One
>> of the reasons why
On 19/03/12 01:09, Ximin Luo wrote:
> On 16/03/12 23:09, Marco Schulze wrote:
>> Well, the obvious question is 'why?'. Using /opt + /usr/bin scripts + service
>> scripts seems to be good enough. Either way, fred .jar paths are
>> configurable,
>> the jars themselves should have 6** permissions and
On 16/03/12 23:09, Marco Schulze wrote:
> Well, the obvious question is 'why?'. Using /opt + /usr/bin scripts + service
> scripts seems to be good enough. Either way, fred .jar paths are configurable,
> the jars themselves should have 6** permissions and be owned by the fred user.
> Why shouldn't a
On Friday 16 Mar 2012 20:38:46 Marco Schulze wrote:
> On 16-03-2012 15:13, Matthew Toseland wrote:
> > Updating its own binaries is incompatible with the standard unix way
> > of doing things, isn't it? Even if it's not technically a violation of
> > FHS?
>
> I'd just like to point out that this
On 16/03/12 18:13, Matthew Toseland wrote:
> On Thursday 15 Mar 2012 21:02:26 Ximin Luo wrote:
>> (Top-posting because previous post is too long to reply to in-line.)
>>
>> ## refactoring
>>
>> Refactoring the code helps to make it more understandable for other coders.
>> One
>> of the reasons why
On 19/03/12 01:09, Ximin Luo wrote:
> On 16/03/12 23:09, Marco Schulze wrote:
>> Well, the obvious question is 'why?'. Using /opt + /usr/bin scripts + service
>> scripts seems to be good enough. Either way, fred .jar paths are
>> configurable,
>> the jars themselves should have 6** permissions and
On 16/03/12 23:09, Marco Schulze wrote:
> Well, the obvious question is 'why?'. Using /opt + /usr/bin scripts + service
> scripts seems to be good enough. Either way, fred .jar paths are configurable,
> the jars themselves should have 6** permissions and be owned by the fred user.
> Why shouldn't a
On Friday 16 Mar 2012 20:38:46 Marco Schulze wrote:
> On 16-03-2012 15:13, Matthew Toseland wrote:
> > Updating its own binaries is incompatible with the standard unix way
> > of doing things, isn't it? Even if it's not technically a violation of
> > FHS?
>
> I'd just like to point out that this
We already have a layout that adheres to the FHS, see debian-staging for
details :)
But this is only for run-time data, NOT the binaries themselves. That part is
rigid and would require much more work, because (to implement it properly)
would need to integrate well with all the various existing i
On 16-03-2012 15:13, Matthew Toseland wrote:
> Updating its own binaries is incompatible with the standard unix way
> of doing things, isn't it? Even if it's not technically a violation of
> FHS?
I'd just like to point out that this is not the case at all, specially
because flexibility is a maj
Well, the obvious question is 'why?'. Using /opt + /usr/bin scripts +
service scripts seems to be good enough. Either way, fred .jar paths are
configurable, the jars themselves should have 6** permissions and be
owned by the fred user. Why shouldn't autoupdate work?
An unrelated question: it se
On Thursday 15 Mar 2012 21:02:26 Ximin Luo wrote:
> (Top-posting because previous post is too long to reply to in-line.)
>
> ## refactoring
>
> Refactoring the code helps to make it more understandable for other coders.
> One
> of the reasons why I don't work more on freenet myself is because it
On 16-03-2012 15:13, Matthew Toseland wrote:
> Updating its own binaries is incompatible with the standard unix way
> of doing things, isn't it? Even if it's not technically a violation of
> FHS?
I'd just like to point out that this is not the case at all, specially
because flexibility is a maj
Well, the obvious question is 'why?'. Using /opt + /usr/bin scripts +
service scripts seems to be good enough. Either way, fred .jar paths are
configurable, the jars themselves should have 6** permissions and be
owned by the fred user. Why shouldn't autoupdate work?
An unrelated question: it s
We already have a layout that adheres to the FHS, see debian-staging for
details :)
But this is only for run-time data, NOT the binaries themselves. That part is
rigid and would require much more work, because (to implement it properly)
would need to integrate well with all the various existing i
On 16-03-2012 15:13, Matthew Toseland wrote:
Updating its own binaries is incompatible with the standard unix way
of doing things, isn't it? Even if it's not technically a violation of
FHS?
I'd just like to point out that this is not the case at all, specially
because flexibility is a major c
On Thursday 15 Mar 2012 21:02:26 Ximin Luo wrote:
> (Top-posting because previous post is too long to reply to in-line.)
>
> ## refactoring
>
> Refactoring the code helps to make it more understandable for other coders.
> One
> of the reasons why I don't work more on freenet myself is because it
(Top-posting because previous post is too long to reply to in-line.)
## refactoring
Refactoring the code helps to make it more understandable for other coders. One
of the reasons why I don't work more on freenet myself is because it's
extremely difficult to make any changes that are more than a s
(Top-posting because previous post is too long to reply to in-line.)
## refactoring
Refactoring the code helps to make it more understandable for other coders. One
of the reasons why I don't work more on freenet myself is because it's
extremely difficult to make any changes that are more than a s
On Wednesday 14 Mar 2012 11:49:33 Ximin Luo wrote:
> Library has some architectural problems. I don't think it's a great use of
> time
> to try to improve the existing code directly.
>
> - We didn't create a proper specification for how the data structure should
> work over freenet
> - I made a m
On Wednesday 14 Mar 2012 11:49:33 Ximin Luo wrote:
> Library has some architectural problems. I don't think it's a great use of
> time
> to try to improve the existing code directly.
>
> - We didn't create a proper specification for how the data structure should
> work over freenet
> - I made a m
40 matches
Mail list logo