maven : why marmalade ?

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

maven : why marmalade ?

Hale India
Hi

I just got a look on maven 2 description and I have some questions ?

Why maven made the move from jelly to marmelade ?
Is this after a community process where Maven users, Maven developers,
maven tags developers has been involved. If not how this decision has
been taken ?
What about marmelade license which seems not to be Apache License V2 ?
What about living an Apache project for a codehaus project ?

I personaly feel that all hat moves : ant to maven, cvs to subversion,
jelly to marmalade where people create news peojects instead of
contributing to improve existing one, all these moves are not a big
advantage for open source.

Already my ISP does not support Linux because instead of having one good
linuxconf they have many "proprietary" configuration tools.

May be am I wrong and you have good reasons to do this ?

Thanks for any answers to my questions

Andre

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: maven : why marmalade ?

Simon Kitching
On Fri, 2005-06-24 at 08:36 +0000, A Leg wrote:
> Hi
>
> I just got a look on maven 2 description and I have some questions ?

I suggest you try the maven list for answers specifically about
marmalade/jelly and the future of Maven.

> What about marmelade license which seems not to be Apache License V2 ?

It's a BSD license which is perfectly compatible with the Apache
license. Not every good project in the world is here at Jakarta...

> What about living an Apache project for a codehaus project ?

If people think it's better then it's their choice. Projects get
superceded by better designs over time - that's progress. Sometimes it
happens as version N+1 of an existing project, sometimes it's something
external.

Besides, I *believe* that maven2 provides the option to use Marmalade,
Jelly or any other language. So it's adding options rather than dropping
Jelly support.

>
> I personaly feel that all hat moves : ant to maven, cvs to subversion,
> jelly to marmalade where people create news peojects instead of
> contributing to improve existing one, all these moves are not a big
> advantage for open source.

If you don't like change, I'm afraid you're in the wrong industry.
Computer software is improving fast, and that means change. Yes it's a
little tiring to keep up sometimes but that's better than stagnation.

It's not just open source; people are screaming about the end of Visual
Basic and Win9x. And Borland JBuilder users are facing a change soon -
to a product built on Eclipse. Tough luck, times change.

>
> Already my ISP does not support Linux because instead of having one good
> linuxconf they have many "proprietary" configuration tools.

Then they're fools. They should pick one linux distribution and stay
with it; no need to support multiple types. And anyway the differences
between linux variants really are pretty trivial. I suspect they're not
telling you the real reason.

Regards,

Simon


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: maven : why marmalade ?

Hale India
Hi Simon

Thank's for your answer.

I don't see any answer about the community process.

To help for answer I explain this question below giving an example on
how it works with Jini :
When Jini team want to change/improve some specification. Before to do
it they propose it to the community, so community can vote.

This is the way that all standards works (Iso, Env, etc..).

Why maven, and more generaly, apache projects does not follow similar way ?

It could be costly, for users, to change to often and standards try to
be stable.
That is why I was asking for the reasons of change : to know what will
be the benefits, to understand and appreciate.

Have fun

Andre


Simon Kitching wrote:

>On Fri, 2005-06-24 at 08:36 +0000, A Leg wrote:
>  
>
>>Hi
>>
>>I just got a look on maven 2 description and I have some questions ?
>>    
>>
>
>I suggest you try the maven list for answers specifically about
>marmalade/jelly and the future of Maven.
>
>  
>
>>What about marmelade license which seems not to be Apache License V2 ?
>>    
>>
>
>It's a BSD license which is perfectly compatible with the Apache
>license. Not every good project in the world is here at Jakarta...
>
>  
>
>>What about living an Apache project for a codehaus project ?
>>    
>>
>
>If people think it's better then it's their choice. Projects get
>superceded by better designs over time - that's progress. Sometimes it
>happens as version N+1 of an existing project, sometimes it's something
>external.
>
>Besides, I *believe* that maven2 provides the option to use Marmalade,
>Jelly or any other language. So it's adding options rather than dropping
>Jelly support.
>
>  
>
>>I personaly feel that all hat moves : ant to maven, cvs to subversion,
>>jelly to marmalade where people create news peojects instead of
>>contributing to improve existing one, all these moves are not a big
>>advantage for open source.
>>    
>>
>
>If you don't like change, I'm afraid you're in the wrong industry.
>Computer software is improving fast, and that means change. Yes it's a
>little tiring to keep up sometimes but that's better than stagnation.
>
>It's not just open source; people are screaming about the end of Visual
>Basic and Win9x. And Borland JBuilder users are facing a change soon -
>to a product built on Eclipse. Tough luck, times change.
>
>  
>
>>Already my ISP does not support Linux because instead of having one good
>>linuxconf they have many "proprietary" configuration tools.
>>    
>>
>
>Then they're fools. They should pick one linux distribution and stay
>with it; no need to support multiple types. And anyway the differences
>between linux variants really are pretty trivial. I suspect they're not
>telling you the real reason.
>
>Regards,
>
>Simon
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [hidden email]
>For additional commands, e-mail: [hidden email]
>
>
>  
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

commons development practises (was maven : why marmalade ?)

Simon Kitching
On Fri, 2005-06-24 at 09:52 +0000, A Leg wrote:

> Hi Simon
>
> Thank's for your answer.
>
> I don't see any answer about the community process.
>
> To help for answer I explain this question below giving an example on
> how it works with Jini :
> When Jini team want to change/improve some specification. Before to do
> it they propose it to the community, so community can vote.
>
> This is the way that all standards works (Iso, Env, etc..).
>
> Why maven, and more generaly, apache projects does not follow similar way ?

You'll need to ask the maven team why they make the decisions they do -
this is the jakarta commons list, not the maven list.

Things like moving to subversion and maven *are* well discussed
beforehand. You'll find lots of email on these subjects in the archives.

>
> It could be costly, for users, to change to often and standards try to
> be stable.
> That is why I was asking for the reasons of change : to know what will
> be the benefits, to understand and appreciate.

Jakarta commons doesn't define standards, nor does it implement them.
Standards have to move very slowly, painfully (and expensively).

No project here in commons has dozens of full-time architects and coders
(if they do, I want to join!!). So the work has to move at a pace that
keeps developers involved, or the project will die. Of course old
releases are always available if you *don't* want to move up to the
latest releases; they are never deleted.

Backwards compatibility is taken seriously; features are seldom dropped
without providing at least one intermediate release where both the old
and new functionality are present to allow code to be changed over. If
you (or any other user) do see this happening for a particular release
of a commons component then please speak up. Even better, offer a patch
that provides a nicer way of changing from the old to the new behaviour.

And users are very welcome to subscribe to the development list and
comment on any changes they see. Though comments like "I think you
should spend lots of your time doing X because I want it" may not get a
lot of respect (an offer to pay for the work may get a different
response).

In fact, I think I can speak for most projects when I say we would
*really like* more feedback from users. In particular, when release
candidates are announced there is very seldom any feedback at all from
the user community for the project - yet you're the ones who should care
the most. And providing QA by testing candidate releases with your
software is one of the easiest ways for users of a component to
contribute back.

Regards,

Simon


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: commons development practises (was maven : why marmalade ?)

Paul Libbrecht
André,

Any reason you don't announce milestones of such projects on
commons-dev/commons-user ? Just this would be an interesting feedback!

paul


André Leg a écrit:
> I am using jelly for our project :
> http://compiere-mfgscm.sourceforge.net/


Le 24 juin 05, à 09:20, Simon Kitching a écrit :

> In fact, I think I can speak for most projects when I say we would
> *really like* more feedback from users. In particular, when release
> candidates are announced there is very seldom any feedback at all from
> the user community for the project - yet you're the ones who should
> care
> the most. And providing QA by testing candidate releases with your
> software is one of the easiest ways for users of a component to
> contribute back.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: commons development practises (was maven : why marmalade ?)

Hale India
In reply to this post by Simon Kitching
Hi Simon

Thank's for your answer. I understand much better this one than previous
one.

Simon Kitching wrote:

>On Fri, 2005-06-24 at 09:52 +0000, A Leg wrote:
>  
>
>>Hi Simon
>>
>>Thank's for your answer.
>>
>>I don't see any answer about the community process.
>>
>>To help for answer I explain this question below giving an example on
>>how it works with Jini :
>>When Jini team want to change/improve some specification. Before to do
>>it they propose it to the community, so community can vote.
>>
>>This is the way that all standards works (Iso, Env, etc..).
>>
>>Why maven, and more generaly, apache projects does not follow similar way ?
>>    
>>
>
>You'll need to ask the maven team why they make the decisions they do -
>this is the jakarta commons list, not the maven list.
>
>Things like moving to subversion and maven *are* well discussed
>beforehand. You'll find lots of email on these subjects in the archives.
>
>  
>
You are right, I will ask to maven mailing list.

>>It could be costly, for users, to change to often and standards try to
>>be stable.
>>That is why I was asking for the reasons of change : to know what will
>>be the benefits, to understand and appreciate.
>>    
>>
>
>Jakarta commons doesn't define standards, nor does it implement them.
>Standards have to move very slowly, painfully (and expensively).
>
>  
>
Open source user needs standards to be able to answer to TCO agrguments.
And Apache fondation seems to me one of rare organisation capable to
produce some.

Example I gave you : Jini community process is moving fast and not
expensively.
It is arealy cutting edge technology. That is why I gave it as example.
Are you afraid to "change" your process ?

>No project here in commons has dozens of full-time architects and coders
>(if they do, I want to join!!). So the work has to move at a pace that
>keeps developers involved, or the project will die. Of course old
>releases are always available if you *don't* want to move up to the
>latest releases; they are never deleted.
>
>  
>
I understand this concern, I have he same. Having a well involved
community is also a good way to get people motivated.

>Backwards compatibility is taken seriously; features are seldom dropped
>without providing at least one intermediate release where both the old
>and new functionality are present to allow code to be changed over. If
>you (or any other user) do see this happening for a particular release
>of a commons component then please speak up. Even better, offer a patch
>that provides a nicer way of changing from the old to the new behaviour.
>
>And users are very welcome to subscribe to the development list and
>comment on any changes they see. Though comments like "I think you
>should spend lots of your time doing X because I want it" may not get a
>lot of respect (an offer to pay for the work may get a different
>response).
>
>  
>
I agree 100%.

>In fact, I think I can speak for most projects when I say we would
>*really like* more feedback from users. In particular, when release
>candidates are announced there is very seldom any feedback at all from
>the user community for the project - yet you're the ones who should care
>the most. And providing QA by testing candidate releases with your
>software is one of the easiest ways for users of a component to
>contribute back.
>
>  
>
That is why I sent my feedback, to try to explain that backward
compatibility with maven 1 tags is important.

Regards

Andre

>Regards,
>
>Simon
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [hidden email]
>For additional commands, e-mail: [hidden email]
>
>
>  
>

Reply | Threaded
Open this post in threaded view
|

Re: commons development practises (was maven : why marmalade ?)

Hale India
In reply to this post by Paul Libbrecht
Hi Paul

You are right, I will look to publish the plugin layer next week and I
will announce it here.
It is currently in use from more than 3 month in production for some
automotive industry application. And it works fine 24hx7 days a week.
I use httpclient in tags and I got very usefull help from the team for
very technical issues like proxy with authentification, site signature etc..
I use also Ojb from db project of apache for persistence layer and same
: very nice.

You see Simon, I am not so afraid by change, I use quite up to date
solutions.
But for example in automotive industry some solutions needs to run 10
years and more, you cannot update plants every 6 months.
Many jakarta commons are very good api, and no need to changes them
without control.
The change process could take in count this requirement.

But I am a quite happy jakarta-common user.

Have fun.

Andre

Paul Libbrecht wrote:

> Andr?,
>
> Any reason you don't announce milestones of such projects on
> commons-dev/commons-user ? Just this would be an interesting feedback!
>
> paul
>
>
> Andr? Leg a ?crit:
>
>> I am using jelly for our project :
>> http://compiere-mfgscm.sourceforge.net/
>
>
>
> Le 24 juin 05, ? 09:20, Simon Kitching a ?crit :
>
>> In fact, I think I can speak for most projects when I say we would
>> *really like* more feedback from users. In particular, when release
>> candidates are announced there is very seldom any feedback at all from
>> the user community for the project - yet you're the ones who should care
>> the most. And providing QA by testing candidate releases with your
>> software is one of the easiest ways for users of a component to
>> contribute back.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: commons development practises (was maven : why marmalade ?)

Simon Kitching
In reply to this post by Hale India
On Fri, 2005-06-24 at 10:50 +0000, A Leg wrote:

> That is why I sent my feedback, to try to explain that backward
> compatibility with maven 1 tags is important.

No, you moaned about the fact that software changes in general. CVS to
subversion and ant to maven were two of your complaints. And my response
was that in the software world things always change. Live with it. Learn
to love it. Remember that it keeps us employed.

A polite question *to the maven list* asking whether they are intending
to support maven1 plugins in maven2, and if not whether the problem is
technical (cannot be done), or motivational (too much effort) would have
been the appropriate move.

If the answer is the latter, then you have to seriously consider how
many people actually care about compatibility. If it's only you and your
dog then you have to accept you're out of luck - it's no-one's
responsibility to work for you for free. If there are many people, then
it's time to politely request support for it - or gather the affected
people and work together to create a patch that implements the feature
*you* need. And remember no-one is going to take away the version you're
using right now.

Under no circumstance do you have the right to demand that new
development on the project is halted and all APIs are frozen just to
suit you.


In any case, are you
a) using Maven to build your own project, or
b) a supplier of Maven plugins which wrap your project?

If (a) then what's the problem? Maven1 will continue to exist. If you
are using it then clearly there aren't any bugs that bother you. And
anyway I believe the Maven team are intending to provide bugfixes for
maven1. And if they don't, you can fix it yourself and still be way
ahead of having built your own solution.

If (b), then creating wrappers for maven2 is likely to be a very small
amount of work. From what I can see, the maven2 team have given some
thought to how people can structure their custom maven plugins so that
the work to support both is reduced.

And none of this is really relevant to this commons list.

Regards,

SImon


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: commons development practises (was maven : why marmalade ?)

Hale India
Hi Simon


Simon Kitching wrote:

>On Fri, 2005-06-24 at 10:50 +0000, A Leg wrote:
>
>  
>
>>That is why I sent my feedback, to try to explain that backward
>>compatibility with maven 1 tags is important.
>>    
>>
>
>No, you moaned about the fact that software changes in general. CVS to
>subversion and ant to maven were two of your complaints. And my response
>was that in the software world things always change. Live with it. Learn
>to love it. Remember that it keeps us employed.
>
>  
>
I did'nt moaned and I tried to be polite. I was talking about subversion
too, because maven project is thinking also to change from cvs, and for
ant I suppose that you understand the link with maven. So I was talking
about specific maven case.

>A polite question *to the maven list* asking whether they are intending
>to support maven1 plugins in maven2, and if not whether the problem is
>technical (cannot be done), or motivational (too much effort) would have
>been the appropriate move.
>  
>
I think hat my question here was polite. I am not sure about your last
answer.

>If the answer is the latter, then you have to seriously consider how
>many people actually care about compatibility. If it's only you and your
>dog then you have to accept you're out of luck - it's no-one's
>responsibility to work for you for free. If there are many people, then
>it's time to politely request support for it - or gather the affected
>people and work together to create a patch that implements the feature
>*you* need. And remember no-one is going to take away the version you're
>using right now.
>
>  
>
I have no dogs, but I am working with many It managers of large and
small companies and they all care a lot about backward compatibility.
I personnaly spend a lot of time for open source projects for free
(about 10 hours a days 6 days a week from 3 years) and I am happy to do it.
I beleive that is is the case for most of open source developers,
probably you also ?

>Under no circumstance do you have the right to demand that new
>development on the project is halted and all APIs are frozen just to
>suit you.
>
>
>In any case, are you
>a) using Maven to build your own project, or
>b) a supplier of Maven plugins which wrap your project?
>
>If (a) then what's the problem? Maven1 will continue to exist. If you
>are using it then clearly there aren't any bugs that bother you. And
>anyway I believe the Maven team are intending to provide bugfixes for
>maven1. And if they don't, you can fix it yourself and still be way
>ahead of having built your own solution.
>
>If (b), then creating wrappers for maven2 is likely to be a very small
>amount of work. From what I can see, the maven2 team have given some
>thought to how people can structure their custom maven plugins so that
>the work to support both is reduced.
>  
>
I didn't demand any thing specific for me. I was just asking questions
to be able to choose.
Nobody is obliged to answer me, any answer should be correct.
I have no problem with maven.
My problem was about support around jelly and I got a nice and clear
answer from jelly team and I will keep using it.

>And none of this is really relevant to this commons list.
>
>  
>
I made a mistake, I was looking to send it to maven list. I personally
will not go ahead with this discussion on this list.
But all this discussion is relevant for any open source project.
You cannot ask for feed back and have this kind of answer if feed back
is not 100% ok for you.
Once again I am happy to use some jakarta commons api.

Best regards

Andre

>Regards,
>
>SImon
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [hidden email]
>For additional commands, e-mail: [hidden email]
>
>
>  
>

Reply | Threaded
Open this post in threaded view
|

Re: maven : why marmalade ?

Martin Cooper
In reply to this post by Hale India
On 6/24/05, A Leg <[hidden email]> wrote:
> Hi Simon
>
> Thank's for your answer.
>
> I don't see any answer about the community process.

If you're talking about changes in Maven, the community is on the
Maven lists, not here in Jakarta Commons.

> To help for answer I explain this question below giving an example on
> how it works with Jini :
> When Jini team want to change/improve some specification. Before to do
> it they propose it to the community, so community can vote.
>
> This is the way that all standards works (Iso, Env, etc..).
>
> Why maven, and more generaly, apache projects does not follow similar way ?

You need to be asking these questions on the Maven lists. We're only
customers of Maven here. ;-)

--
Martin Cooper


> It could be costly, for users, to change to often and standards try to
> be stable.
> That is why I was asking for the reasons of change : to know what will
> be the benefits, to understand and appreciate.
>
> Have fun
>
> Andre
>
>
> Simon Kitching wrote:
>
> >On Fri, 2005-06-24 at 08:36 +0000, A Leg wrote:
> >
> >
> >>Hi
> >>
> >>I just got a look on maven 2 description and I have some questions ?
> >>
> >>
> >
> >I suggest you try the maven list for answers specifically about
> >marmalade/jelly and the future of Maven.
> >
> >
> >
> >>What about marmelade license which seems not to be Apache License V2 ?
> >>
> >>
> >
> >It's a BSD license which is perfectly compatible with the Apache
> >license. Not every good project in the world is here at Jakarta...
> >
> >
> >
> >>What about living an Apache project for a codehaus project ?
> >>
> >>
> >
> >If people think it's better then it's their choice. Projects get
> >superceded by better designs over time - that's progress. Sometimes it
> >happens as version N+1 of an existing project, sometimes it's something
> >external.
> >
> >Besides, I *believe* that maven2 provides the option to use Marmalade,
> >Jelly or any other language. So it's adding options rather than dropping
> >Jelly support.
> >
> >
> >
> >>I personaly feel that all hat moves : ant to maven, cvs to subversion,
> >>jelly to marmalade where people create news peojects instead of
> >>contributing to improve existing one, all these moves are not a big
> >>advantage for open source.
> >>
> >>
> >
> >If you don't like change, I'm afraid you're in the wrong industry.
> >Computer software is improving fast, and that means change. Yes it's a
> >little tiring to keep up sometimes but that's better than stagnation.
> >
> >It's not just open source; people are screaming about the end of Visual
> >Basic and Win9x. And Borland JBuilder users are facing a change soon -
> >to a product built on Eclipse. Tough luck, times change.
> >
> >
> >
> >>Already my ISP does not support Linux because instead of having one good
> >>linuxconf they have many "proprietary" configuration tools.
> >>
> >>
> >
> >Then they're fools. They should pick one linux distribution and stay
> >with it; no need to support multiple types. And anyway the differences
> >between linux variants really are pretty trivial. I suspect they're not
> >telling you the real reason.
> >
> >Regards,
> >
> >Simon
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: [hidden email]
> >For additional commands, e-mail: [hidden email]
> >
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: maven : why marmalade ?

Hale India
Hi Martin

You are right I made a mistake.
Hopefully answers of Dion and Paul are Ok for me : we will keep using
Jelly. It is good working and support is Ok.

We are also very happy with others common projects : httpclient, net etc.

Andre

Martin Cooper wrote:

>On 6/24/05, A Leg <[hidden email]> wrote:
>  
>
>>Hi Simon
>>
>>Thank's for your answer.
>>
>>I don't see any answer about the community process.
>>    
>>
>
>If you're talking about changes in Maven, the community is on the
>Maven lists, not here in Jakarta Commons.
>
>  
>
>>To help for answer I explain this question below giving an example on
>>how it works with Jini :
>>When Jini team want to change/improve some specification. Before to do
>>it they propose it to the community, so community can vote.
>>
>>This is the way that all standards works (Iso, Env, etc..).
>>
>>Why maven, and more generaly, apache projects does not follow similar way ?
>>    
>>
>
>You need to be asking these questions on the Maven lists. We're only
>customers of Maven here. ;-)
>
>--
>Martin Cooper
>
>
>  
>
>>It could be costly, for users, to change to often and standards try to
>>be stable.
>>That is why I was asking for the reasons of change : to know what will
>>be the benefits, to understand and appreciate.
>>
>>Have fun
>>
>>Andre
>>
>>
>>Simon Kitching wrote:
>>
>>    
>>
>>>On Fri, 2005-06-24 at 08:36 +0000, A Leg wrote:
>>>
>>>
>>>      
>>>
>>>>Hi
>>>>
>>>>I just got a look on maven 2 description and I have some questions ?
>>>>
>>>>
>>>>        
>>>>
>>>I suggest you try the maven list for answers specifically about
>>>marmalade/jelly and the future of Maven.
>>>
>>>
>>>
>>>      
>>>
>>>>What about marmelade license which seems not to be Apache License V2 ?
>>>>
>>>>
>>>>        
>>>>
>>>It's a BSD license which is perfectly compatible with the Apache
>>>license. Not every good project in the world is here at Jakarta...
>>>
>>>
>>>
>>>      
>>>
>>>>What about living an Apache project for a codehaus project ?
>>>>
>>>>
>>>>        
>>>>
>>>If people think it's better then it's their choice. Projects get
>>>superceded by better designs over time - that's progress. Sometimes it
>>>happens as version N+1 of an existing project, sometimes it's something
>>>external.
>>>
>>>Besides, I *believe* that maven2 provides the option to use Marmalade,
>>>Jelly or any other language. So it's adding options rather than dropping
>>>Jelly support.
>>>
>>>
>>>
>>>      
>>>
>>>>I personaly feel that all hat moves : ant to maven, cvs to subversion,
>>>>jelly to marmalade where people create news peojects instead of
>>>>contributing to improve existing one, all these moves are not a big
>>>>advantage for open source.
>>>>
>>>>
>>>>        
>>>>
>>>If you don't like change, I'm afraid you're in the wrong industry.
>>>Computer software is improving fast, and that means change. Yes it's a
>>>little tiring to keep up sometimes but that's better than stagnation.
>>>
>>>It's not just open source; people are screaming about the end of Visual
>>>Basic and Win9x. And Borland JBuilder users are facing a change soon -
>>>to a product built on Eclipse. Tough luck, times change.
>>>
>>>
>>>
>>>      
>>>
>>>>Already my ISP does not support Linux because instead of having one good
>>>>linuxconf they have many "proprietary" configuration tools.
>>>>
>>>>
>>>>        
>>>>
>>>Then they're fools. They should pick one linux distribution and stay
>>>with it; no need to support multiple types. And anyway the differences
>>>between linux variants really are pretty trivial. I suspect they're not
>>>telling you the real reason.
>>>
>>>Regards,
>>>
>>>Simon
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: [hidden email]
>>>For additional commands, e-mail: [hidden email]
>>>
>>>
>>>
>>>
>>>      
>>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: [hidden email]
>>For additional commands, e-mail: [hidden email]
>>
>>
>>    
>>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [hidden email]
>For additional commands, e-mail: [hidden email]
>
>
>  
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]