On Fri, Nov 20, 2009 at 01:24:18PM -0500, Mathieu Bouchard wrote:
On Fri, 20 Nov 2009, Chris McCormick wrote:
Maybe I am misunderstanding something, but if this is a question of being able to apt-get install vanilla Pd under Debian GNU/Linux, I would like to have that option rather than only having the option to install pd-extended.
What's in pd-vanilla, that you can't have by installing pd-extended ?
Hi!
Your question is the wrong way around. I can't answer it like that because it contains built in assumptions which don't make sense to me.
Chris.
------------------- http://mccormick.cx
On Sat, Nov 21, 2009 at 03:02:14AM +0000, Chris McCormick wrote:
On Fri, Nov 20, 2009 at 01:24:18PM -0500, Mathieu Bouchard wrote:
On Fri, 20 Nov 2009, Chris McCormick wrote:
Maybe I am misunderstanding something, but if this is a question of being able to apt-get install vanilla Pd under Debian GNU/Linux, I would like to have that option rather than only having the option to install pd-extended.
What's in pd-vanilla, that you can't have by installing pd-extended ?
Your question is the wrong way around. I can't answer it like that because it contains built in assumptions which don't make sense to me.
Hi!
Ok, I'll answer your question as if you'd asked it like this: "Why would you like the option of running pd-vanilla?" Rather than the front-loaded question you asked me.
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.
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.
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.
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?
Of course, Free and Open Source Software is also about choice, and so it's always good to give users the choices they would like. I shouldn't even have to justify my own preference for running pd-vanilla to you, beyond saying "having pd-vanilla is a useful feature for me, and I would appreciate it if it was available to me as a choice."
"It works for me," is the worst kind of programmer mentality.
Chris.
------------------- http://mccormick.cx
On Nov 21, 2009, at 12:03 AM, Chris McCormick wrote:
On Sat, Nov 21, 2009 at 03:02:14AM +0000, Chris McCormick wrote:
On Fri, Nov 20, 2009 at 01:24:18PM -0500, Mathieu Bouchard wrote:
On Fri, 20 Nov 2009, Chris McCormick wrote:
Maybe I am misunderstanding something, but if this is a question of being able to apt-get install vanilla Pd under Debian GNU/Linux, I would like to have that option rather than only having the option to install pd-extended.
What's in pd-vanilla, that you can't have by installing pd- extended ?
Your question is the wrong way around. I can't answer it like that because it contains built in assumptions which don't make sense to me.
Hi!
Ok, I'll answer your question as if you'd asked it like this: "Why would you like the option of running pd-vanilla?" Rather than the front-loaded question you asked me.
- 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.
- 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.
- 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.
- 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.
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 :).
.hc
Of course, Free and Open Source Software is also about choice, and so it's always good to give users the choices they would like. I shouldn't even have to justify my own preference for running pd-vanilla to you, beyond saying "having pd-vanilla is a useful feature for me, and I would appreciate it if it was available to me as a choice."
"It works for me," is the worst kind of programmer mentality.
Chris.
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
----------------------------------------------------------------------------
I spent 33 years and four months in active military service and during that period I spent most of my time as a high class muscle man for Big Business, for Wall Street and the bankers. - General Smedley Butler
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:
- 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.
- 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.
- 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.
- 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.
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.
Cheers,
Chris.
------------------- http://mccormick.cx
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:
- 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.
- 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.
- 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.
- 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.
On Sat, 21 Nov 2009, Chris McCormick wrote:
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.
If (random popular interpreter) Python or Ruby or PHP were nearly as modular as Pd is, you'd need to download your for-loop statement from a third party, and then you'd have people arguing on the mailing-list that they should be able to run Ruby without a for-loop statement interpreter if they damn well please. Then you'd have at least five different representations for text strings, in which the only one considered standard is the one that is a big honking memory leak by design; and each of the non-leaking representations would be pushed for by a minority of specialists and rejected by a majority of them. THAT's modularity!
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.
Even though pd-extended is built as one set of things, there's nothing that prevents you from designing a scheme of .deb files that cuts that one set of binaries (made from a single "make" command) into a conveniently-compartmentalised system designed so that each package doesn't pull in too many other packages at once (recursively speaking).
I don't know whether debian packaging really wants you to have one makefile per package, but if ever it's the case, you can probably fake it so as to avoid having to split a makefile-system that has an advantage at being all together. the package-splitting would be only there to avoid pulling too many deps at once, just to avoid apt-get install pd-extended telling you «the following 242 dependencies will be ADDED. Once installed it will take 3859 Megs. Do you want to continue? (Y/Y)». But seriously, so far, I don't recall being really annoyed by the number of deps in the pd-extended debs.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
On Sat, 21 Nov 2009, Hans-Christoph Steiner wrote:
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.
A hero is a kind of self-designated victim. Everybody waits for everybody else to do something, and then one of them gets annoyed by the situation and does something. From that moment on, everybody expects the one who has already given, to give again.
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 :).
It's not ironic, not kind of and not maybe. We're talking about pd vanilla packaging, and chiefly two branches have ever been packaged, vanilla and extended, and then suddenly talking about extended would be ironic? What's wouldn't be ironic then?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
On Sat, 21 Nov 2009, Chris McCormick wrote:
Ok, I'll answer your question as if you'd asked it like this: "Why would you like the option of running pd-vanilla?" Rather than the front-loaded question you asked me.
What does «front-loaded» mean here??
- 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.
How to make pd-extended super stable:
1. download pd-extended 2. install pd-extended 3. delete .pdsettings 4. done
that way you don't get any of the annoying externals.
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.
It's not that: there are possibly many features that one wish hadn't been implemented, but few of them really are impediments and even fewer are showstoppers or close to (i'm not talking about pd in particular).
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.
You are confusing pressure and resistance.
- 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?
What if I want to apt-get install Pd onto my toaster / microwave-oven / Apple IIc or BBC-Micro ?
If you want that to happen, you may be a candidate for maintaining the «puredata» package in Debian!
Of course, Free and Open Source Software is also about choice,
Whose choice of what?
You can choose to run the programme, choose to study how the programme works, choose to modify the programme to do whatever you want, choose to redistribute the programme, and choose to fork the project. What else do you want to choose about?
and so it's always good to give users the choices they would like.
There's nothing in the Free Software Definition that says anything like volunteers who happen to be served by users have to volunteer extra time to provide the users with the choices they like, for free.
I shouldn't even have to justify my own preference for running pd-vanilla to you,
Well, why are you replying to me? That's because you think it's worth it.
beyond saying "having pd-vanilla is a useful feature for me, and I would appreciate it if it was available to me as a choice."
The issue is not whether you prefer pd-vanilla or whether you think pd-vanilla shall be the default in such a manner that all questions have to be biased in favour of pd-vanilla. The question is whether HCS would take on the job of maintaining the debian package for it.
"It works for me," is the worst kind of programmer mentality.
What about the worst kinds of user mentality? (while we are at separating users and programmers again...)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
On Sun, Nov 22, 2009 at 12:30:01PM -0500, Mathieu Bouchard wrote:
On Sat, 21 Nov 2009, Chris McCormick wrote:
I shouldn't even have to justify my own preference for running pd-vanilla to you,
Well, why are you replying to me? That's because you think it's worth it.
Excellent point, sir!
Thanks for all your lovely long essays. I'm sure they contained many important points, but I'm sorry I don't have time to read or respond to them all. Which is the same reason that this:
"Even though pd-extended is built as one set of things, there's nothing that prevents you from designing a scheme of .deb files that cuts that one set of binaries (made from a single "make" command) into a conveniently-compartmentalised system designed so that each package doesn't pull in too many other packages at once (recursively speaking)."
is 100% irrelevant to me, and quite a ridiculous solution to the problem I raised.
I'll continue to `apt-get install puredata` for as long as I can.
Back to work.
Have a nice day,
Chris.
------------------- http://mccormick.cx
On Sat, 21 Nov 2009, Chris McCormick wrote:
On Fri, Nov 20, 2009 at 01:24:18PM -0500, Mathieu Bouchard wrote:
On Fri, 20 Nov 2009, Chris McCormick wrote:
Maybe I am misunderstanding something, but if this is a question of being able to apt-get install vanilla Pd under Debian GNU/Linux, I would like to have that option rather than only having the option to install pd-extended.
What's in pd-vanilla, that you can't have by installing pd-extended ?
Your question is the wrong way around. I can't answer it like that because it contains built in assumptions which don't make sense to me.
Ah, I see: you want questions that have a vanilla bias.
I'm not sorry: I asked the question that I wanted to ask, the way I wanted to ask it.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
-
Chris McCormick -
Hans-Christoph Steiner -
Mathieu Bouchard