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
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
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
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
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
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
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
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 into
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
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 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 understandable
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
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 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
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
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
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
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
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
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 is not
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
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 be
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 I don't work
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
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
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
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
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
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'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
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
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 mistake
(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
34 matches
Mail list logo
