Forging a new path.

[Gustin Johnson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

alex stone wrote:
> On Mon, Apr 13, 2009 at 1:32 AM, Gustin Johnson <gustin at echostar.ca>
>  wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>> 
>> alex stone wrote:
>>> Eric, i respect and appreciate the points you've made.
>>> 
>>> I have to disagree for a) the fact that pulseaudio is mandatory,
>>>  and it's a pain to take it out, or even get it working with
>>> jack, and b)
>> sudo update-rc.d -f pulseaudio remove
>> 
>> This keeps pulseaudio installed by prevents it from starting 
>> automatically.  As a short term workaround it does not get any 
>> easier.
> 
> So why does it need to be compulsory as an install? would be simpler 
> to make it optional, in an Audio based distro.
> 
This distro uses Ubuntu as a base.  Ubuntu makes pulse a dependency.
Sucks to be us.  This is what the discussion about deviating too far
from a  stock Ubuntu is about.  The choices made here have consequences.
I for one am glad that no one is rushing in to this.
> 
>> Most of the people I know do not use the phrase "state of the art",
>>  instead "bleeding edge" is much more common, and for good reason.
>>  As it is I find that Ubuntu is pretty aggressive with bringing in
>>  new versions of software.  I am not sure that becoming another 
>> Debian Unstable or Experimental is in anyone's best interest.
> 
> And you may have missed my note that mentioned stability, as a 
> natural proviso. I wasn't talking about bleeding edge, but as modern
>  a stable version as is possible. There's a difference.
> 
> 
Yes, as modern and as stable as possible.  I do not see how that is not
the current state of things?  The largest problem as I see it, is the
lack of packagers to bring newer versions in to the fold.

>> IMO, stable should have more importance than being up to date.
> 
> See above.
> 
> 
>> Pulse is not a replacement for jack.  pulse has a different 
>> objective than jack.
> 
> Is that objective complementary to an audio based distro?
> 
As I understood it, Ubuntu Studio was a media centred distro, jack is
not appropriate for all work loads.  I would not be surprised to find
out that this is one of the issues that prompted Cory to ask the
question about the *purpose* of Ubuntu Studio.

>> This is actually a reasonably complex issue.  I understand that 
>> this has caused some frustration for you, but instead of just 
>> complaining, you could research the problem and be part of the 
>> solution instead of just complaining.
> 
> Doesn't cause me frustration, because a) i pulled it out, and b) i 
> switched distros to one that wasn't compulsory. 64Studio 3.0 (beta 
> 3), and c) i have no fear at trying new things, including summary 
> solutions. And at the time it appeared, i asked the same question 
> then, and was fairly abruptly dismissed out of hand, because the 
> "decision had already been made for mainstream Ubuntu."
> 
> The people i've tried to help have a problem with it though, and ask 
> the same question i did. Why is it there?
> 
Because Ubuntu has it, we currently have it.
> 
>> This is an upstream dependency, removing it has its own share of 
>> issues.
> 
> and so any intent to remove the app drags a shedload of dependencies 
> with it, messing up what may well have been a good install otherwise.
> 
> 
> 
My point is that it has to be done right.  Just yanking it out is hard.
 I don't like it or use it, but I understand why it is hard to remove
from the Ubuntu Studio devs perspective.
> 
>> jack and pulse are used differently.
> 
> Correct. So why put a server for domestic consumption in an audio 
> distro by default, and leave the, erm, audio server as optional?
> 
> 
>> It depends.  Everyone has their own perspective, and saying that 
>> audio is a mess does not really accurately give a picture of the 
>> problem.  All those posts have a particular axe to grind, and 80% 
>> of them are just wrong to begin with.  There is a lot of room for 
>> improvement, and thus there is ample opportunity for you to help 
>> out.
> 
> I have, and continue to do so with users who ask questions that i may
>  know the answer to, or need some assistance with setting up their 
> install to work. See the previous post for alternative definition of 
> what may constitute "A contribution.".
> 
> 
> 
>> There is no magic bullet solution here, so stop looking for one.
> 
> Frankly, that doesn't mean anything. Whether you think my view is 
> valid or not is up to you, but it may well be a valid perspective, 
> and natural questions to ask, for others. That's up to them.
> 
You keep going on about pulseaudio.  This is only one piece in a larger
puzzle.  I would encourage you to dig deeper, you obviously care about
open source and in particular open source creative tools.  I hope that
you can find a productive means of contribution.  The main areas as I
see it are 1) doing the work, 2) documenting the work, 3) testing the
completed work, and 4) paying someone else to do the work.  There may be
more, this is again only how I see it.
> 
>> This is what Cory was talking about.  There are people who just 
>> bitch and moan but do absolutely nothing about it.
> 
> I'm not bitching and moaning at all. I'm asking questions, and 
> suggesting a fresh view might be fruitful for all, including giving 
> the devs a chance to breathe. And frankly you're talking nonsense 
> with an assumption that anyone who 'questions the path' is by default
>  someone who doesn't contribute, and just bitches and moans. It's 
> somewhat ironic that questions, and alternate perspectives, are 
> autocratically dismissed as complaining when they differ from the 
> status quo, yet you ask for help, expecting no alternate view. Not 
> exactly the 'community' spirit you're expecting of others is it?

I do not see one path that is the correct one.  But I do not get the
sense that you have done any research or have any idea of what is going
on.  I do not think that you and I are too far apart in our views since
neither of us is a fan of pulse.  The difference is that I bothered to
look in to why it is there.  It turns out that this is one of many
complicated things the Studio devs have to contend with.

Asking the same question over and over again is not far from bitching
and moaning.  The answers are there if you bothered to look for them.
> 
> This may sound hard and
>> callous, but I do not care about Johny Air Guitar.  If he takes no 
>> action or initiative, why should I *give* him my time to fix his 
>> problems for him.  I understand that we all started somewhere, and
>>  at some point someone helped us.  I like helping people, but most
>>  people here are donating their time, and if Johny Air Guitar wants
>>  people to fix his problems for free without doing a single thing 
>> himself, then we are all better of if he goes elsewhere.
> 
> 
> That's your view for one type of user, and JAG may have been a poor 
> analogy on my part. If however a new user, keen to try, but lacking 
> 'linux syntax' just can't get the knack of getting everything working
>  together because they might think in a different way, gets 
> frustrated, because they're simply "expected to know", then a 
> potential contributor goes away. Not all users are deadbeats, but 
> they may just not be able to get their head around it at the start.
> 
I remember the first time I sat in front of a *Nix machine.  I remember
the work I had to put in to learning to do things a different way.  I
remember the help that I received.  Most of all, I remember the advice
that I received that sounded an awful lot like this:

http://www.catb.org/~esr/faqs/smart-questions.html

I do not get the impression that one is expected to know, but I do get
the impression that some level of personal responsibility is expected.
This is a very crucial distinction but one that often gets lost when
talking about the so called "average user".

>> Free and Open Source software is at it's best when everyone pitches
>>  in to the best of his or her abilities.  The old notion of a 
>> passive consumer/user does not fit in particularly well here.  I do
>>  not mean that everyone needs to be a coder or a packager, there 
>> are a lot of things that even non technical people can do to help 
>> out.
> 
> And many of us do. I keep seeing the same names come up for the same 
> generous souls when i'm out doing my modest linux audio bit. That 
> would be the 'other' contributors who make regular contributions at 
> the coalface, in their local communities, be they physical locales, 
> or digital communal meeting places. You don't see them often, but 
> they're out there contributing just the same.
> 
Yes they are, and words do not do these people justice.  Speaking of
which, how many people have donated to Paul Davis and the Ardour crowd?
   Please do not answer that question directly, but if you have the
means, please head over to http://ardour.org/node and give what you can.
> 
> 
>> The weight of numbers can also be crippling.
> 
> 
> That's possible, but how many is too many?
> 
I do not have an answer for that.  We are where we are because some
people simply choose to focus on the quality, without regard to numbers
or dates.  By focusing on the code they have brought us this far.
Focusing on the number of users is pointless in my opinion.  Of more
importance are the number of contributers.
> 
>> The Linux audio community is certainly larger than when I started 
>> with it 10 years ago.  We have come a long way, and I am looking 
>> forward to what the future brings.
> 
> Good to hear.
> 
> 
>> I am not sure that this is the case.  I am also not sure that we 
>> should be focusing on this particular metric.
> 
> :)
> 
>> We don't have to.  From my perspective I see the LTS versions as 
>> the stable one, with the other releases as technical previews and a
>>  work in progress before the next LTS.
> 
> And yet Cory was smart enough to post a warning note not so long ago,
>  about the pressure of getting an RT kernel out for 8.10, because of 
> the significant changes in the vanilla kernel. He got a lot of 
> support and encouragement at the time, because the majority of the 
> non-coding regulars wanted to make sure the devs weren't killing 
> themselves trying to help the community with "something for the 
> scheduled update".
> 
> 
>> 64 Studio already does this.  They have made the move from Debian 
>> to Ubuntu LTS.  One problem with LTS (though less of a problem than
>>  Debian Stable was) is that some things do get quite a bit out of 
>> date by the time the next LTS rolls around.  Things get challenging
>>  when the kernel and userspace start to drift apart.  An example 
>> faced by 64Studio was that they could not support the latest nVidia
>>  drivers without a newer version of Xorg, which in turn required a
>>  new kernel, which required updated udev utilities... things can
>> get out of hand pretty quickly.
> 
> I'm using 64Studio 64bit 3.0 (beta 3) now. Already a sound and stable
>  distro, with a 'state of the art' 2.6.29-RT kernel, and the hunt is
>  on (including me) for the latest "state of the art" versions of 
> packages. I know this because i'm testing a few in all sorts of 
> experiments, and trials, and reporting back.
> 
> And no compulsory Pulseaudio.
> 
Because it based on Hardy.  Pulseaudio was introduced with 8.10.

>> Then of course the problem becomes one where we are not supporting
>>  the latest hardware.  Joe User will complain that there are 
>> problems with his shiny new motherboard and CPU (and possibly GPU)
>>  that are supported by newer kernels etc.  There is cost to either
>>  approach.
> 
> Yet 64studio are on the 2.6.29rt kernel, with Hardy LTS. I would 
> think they'd thought as far ahead as they could, in the compromise 
> between a stable working system, and the uncertainty of what new 
> hardware devices might be coming out next. And that's the same for 
> all distros, yes?

The current *stable* 64Studio had this particular problem, which is why
they switched to Ubuntu.  Hopefully a two year cycle is not as painful
as the last Debian one.  With 64Studio being Ubuntu based, I expect that
there will be some useful and beneficial cross pollination if not
outright co-operation with Ubuntu Studio.

64Studio 3 is still in beta, the proof will be 4 years out.  I am
optimistic, but only time will tell.

Incidentally, my main audio workstation is running 64Studio *stable* (2.1).
> 
>> Jack is also something that is not trivial to keep current.
> 
> I don't understand the validity of this comment at all, based on my 
> own modest experiences.
> 
Then try and package it.  I have and failed, and I sincerely hope that
you (or anyone else) can do better.  I know Cory and the gang (and those
folks at 64Studio too) would love this.
> 
> 
>>> I wonder if this would be a far better solution, all round.
>> Probably not a simple one.  I do not see us as too far from the 
>> best path as it is. <snip>
> 
> I'm not up on the actual mechanics or politics involved, so you could
>  be right, and i wouldn't know
> 
That is only how I see it.  I am not arrogant enough to assume that I
*know* the correct path.

Cheers,
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAknioMAACgkQwRXgH3rKGfMahACfelBpm+sCudiQtUYIcahtOOPW
hkoAnixaiIfcHeIGWGOkFKjmQV8iaCCk
=Ur5k
-----END PGP SIGNATURE-----