[PD-dev] updating 'puredata' package to 0.42.5

[Hans-Christoph Steiner]

On Nov 21, 2009, at 12:44 AM, Chris McCormick wrote:

> Hi Hans!
>
> Let me prefix this by saying I think you and everyone else are doing  
> great work
> with pd-extended.
>
> On Sat, Nov 21, 2009 at 12:19:45AM -0500, Hans-Christoph Steiner  
> wrote:
>>
>> On Nov 21, 2009, at 12:03 AM, Chris McCormick wrote:
>>
>>> On Sat, Nov 21, 2009 at 03:02:14AM +0000, Chris McCormick wrote:
>>>
>>> 1. Pd is minimal whilst pd-extended is maximal. Hans has stated  
>>> on  list
>>> that he would like to include as many externals as possible in the
>>> distribution. I think this is a bad architectural decision which  
>>> leads to
>>> complexity  and bugs.  I would rather run something which has an
>>> architecture I agree with.
>>
>> Just like to throw in my two cents since I am mentioned by name ;)   
>> I  may
>> have said that years ago, but that is definitely no longer the case  
>> and
>> hasn't been for years.  We really should be working towards a   
>> common, simple
>> library format so we don't need to include so much stuff in a  
>> single package.
>
> Ok! I am obviously behind the times. Sorry about that. I guess it's  
> still the
> case that at this point in time it is included in a single package,  
> but very
> nice to hear that you are moving towards something more modular. I  
> should note
> that Pd itself is not very modular in terms of the way it's  
> distributed, it's
> just that there is not a lot of stuff in it.
>
>>> 2. pd-extended has not yet earned my trust as a software project.  
>>> I  have
>>> been using Pd for a few years, and it has earned my trust. There  
>>> are many
>>> things which Miller has not implemented which I wish he had, but  
>>> there are
>>> far fewer things that he has implemented which I wish he hadn't.
>>
>> If you do find problems please do let us know.
>
> I will, thanks for the invitation. This is one of the great things  
> about
> pd-extended, that the development is so public and open. I am  
> looking forward
> to the day when pd-extended fits my needs and I can begin to trust  
> it when I
> use it more.
>
>>> 3. Hans is the leader of the pd-extended project, and I disagree  
>>> with many
>>> of his technical decisions. I don't trust him to make technical  
>>> decisions as
>>> much as I trust Miller. This may be outweiged down the track by
>>> evolutionary pressure, since pd-extended will be subjected to a  
>>> lot more
>>> pressure  than Pd will be, because Pd basically has a sole  
>>> maintainer. For
>>> me this is  the biggest thing going for pd-extended - it is  
>>> properly exposed
>>> to the  evolutionary pressures of the Free Software community.
>>
>> Funny, I never wanted to be a leader of this, I'd much prefer it if  
>> more
>> people were involved in the work and the decision making.  And   
>> thankfully,
>> I'm not the only one who works on it.  Others have  contributed a  
>> lot as
>> well.
>
> Of course, and you are doing a neccessary job and I think a lot of  
> people
> appreciate it, especially people who just want to get something  
> working fast on
> their platform, and need the functionality of some externals but  
> can't compile
> them.
>
>>> 4. I often want to run Pd on constrained devices and in  
>>> constrained  places.
>>> Getting it to do so is hard enough without the bloat that pd- 
>>> extended
>>> experiences. What if I want to apt-get install Pd onto my router/
>>> gumstix/phone with an ARM based processor with 8MB of flash memory?
>>
>> I often to that as well.  You should see how many python libraries  
>> are
>> available for embedded devices.  Many many.  Just because a library  
>> is
>> sitting there on the disk doesn't mean you have to use it.  But it  
>> does meant
>> that you _can_ use it.
>
> I guess the difference is that when disk space is constrained I have  
> the option
> to install or not install something with Python, whilst I don't  
> really have
> that option with pd-extended. If you do an `apt-cache search python- 
> ` you will
> see a ton of stuff that you can optionally install. I think the  
> Python VM and
> language strike the right balance with what hey choose to be  
> 'batteries
> included' and what they leave out. Possibly pd-extended still needs  
> to find
> that balance.

I think the commonly agreed-upon future direction for Pd-extened on  
Debian-esque platforms is having all of the libs broken out into  
separate packages.  It is just a matter of getting the work done...

>
>> All that said, I like the forkiness of Pd and think its a strength.  
>> I don't
>> think everyone should use Pd-extended, or whatever.  Its kind of  
>> ironic maybe
>> that this thread started with me talking about doing pd- vanilla  
>> maintenance
>> :).
>
> Yes, I agree. Choice is good. Also, that irony is not lost on me! I  
> would
> really appreciate having someone dedicated to updating vanilla Pd in  
> Debian. I
> must apologise for always contributing words rather that code or  
> action, which
> is what you do for the benefit of us all.


IOhannes beat me to the punch, he just didn't mention it.  :-)

.hc


----------------------------------------------------------------------------

The arc of history bends towards justice.     - Dr. Martin Luther  
King, Jr.