Forging a new path.

[Gustin Johnson]

-----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.

> keeping ubuntustudio as close to the mainstream as possible.
> 
> In response:
> 
> a) Why isn't pulse audio optional, instead of compulsory, and
> 
That is made compulsory upstream, by the default Ubuntu
> b) there's been a lot of development and updates in audio apps and
> utilities in the last twelve months. (libsndfile to version 19, just
> for one example).
> If UBS is to follow the mainstream as closely as possible, then all
> our essential audio utilities will, by the nature of going with the
> flow for the greater good will have an additional layer of proviso
> keeping in line with the rest, which may 'restrict' the opportunity to
> include state of the art versions with the intent of  "as up to date
> as possible" within the bounds of stability .
> 
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.

> As much as anything else we've mentioned, it surely makes sense to go
> modern/still stable when undertaking such a task.
> 
IMO, stable should have more importance than being up to date.

> And i say this respectfully to you.
> 
> Why does pulseaudio, which is basically a server to run domestic apps,
> get compulsory precedent over jack in an audio based distro?
> 
Pulse is not a replacement for jack.  pulse has a different objective
than jack.

> I'm still curious as to why this happened, and why jack users, which
> we can fairly bet in an audio distro environment will be the majority
> of users, are the ones who have to go through the pain and hassle of
> eradicating an unwanted domestic server from a distro based on
> audio/musicmaking usage?

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.
> 
> If the intent of the Ubuntustudio project is to cater to predominately
> domestic music making (and no offence intended here at all), then so
> be it. I have no hassle with that, and will use and/or build something
> else. (Which i've done directly as a result of the pulseaudio
> compulsory inclusion, and the subsequent debris left behind when i
> removed it, including the compulsory dependencies.)
> 
> But if the intent is to cater to those who are enthusiastic about
> producing music at a more serious level (and i do soundtrack work from
> time to time, like you) in addition to the enthusiasts, then it seems
> the addition of a domestic server as compulsory, before a professional
> server (and i use these terms for highlighting the difference only) is
> shooting one's self in the digital foot.
> 
> There's already been comments here lauding the virtues of lean and
> mean, and i don't see how handicapping that with an additional layer
> of unwanted sound server actually helps.
> 
This is an upstream dependency, removing it has its own share of issues.

> So while i appreciate your position as a perspective for enthusiasts,
> (again no offence) maybe the mission statement for UBstudio is more as
> a leg into music making in Linux, rather than a potentially serious
> studio based profile. If that's incorrect, and not the intent, then i
> respectfully suggest my original point holds true.
> 
> Jack as a 'default' server from install, and pulse as the optional extra.
> 
jack and pulse are used differently.

> I've read so much stuff in the nearly 2 years i've been using linux
> about how the linux sound system in general is a mess, it's confusing,
> and hard to setup, and how tough it is to get a decent rig going.

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 don't think that's true when we stick to basics, and at least share
> the same room when singing from the hymn sheet.
> 
There is no magic bullet solution here, so stop looking for one.

> We can be as pompous as we like about the virtues of using linux and
> the opportunities it provides, but frankly, if Johnny Air Guitar can't
> a) hear something when he pretends to swing the axe, and b) has to
> deal with unwanted challenges just to get started, then he's gonna do
> the Win or Mac thing, and tell all his mates that Linux sucks, because
> he can't get it going, and doesn't want to appear dumb in front of his
> pals.

This is what Cory was talking about.  There are people who just bitch
and moan but do absolutely nothing about it.  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.

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.
> 
> That means our community stays small, and that help that people keep
> asking for isn't going to materialize immediately because the weight
> of numbers coming into our community isn't there.
> 
The weight of numbers can also be crippling.

> Is our community (one which i'm enthusiastic to be a part of) getting
> bigger or smaller?
> 
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.

> If smaller, why?

I am not sure that this is the case.  I am also not sure that we should
be focusing on this particular metric.

> 
> I think it's good you're asking for help, providing a framework, and
> impetus, and i admire you for that.
> 
> But it's also about the fundamentals of a system.
> 
> You've written that it might be more work for the already overworked
> devs if they stray too far from the mainstream.
> I would argue that the addition of unused components in a distro must
> surely be a source of extra time wasted that could be better spent
> elsewhere, including the devs getting time off to enjoy their own
> lives a bit more.
> 
> Personally, i'd rather have a good rt kernel, a solid and reliable
> late version Jack (and optional Jack2) option at install time, the
> most commonly used up to date audio apps, and a lightweight window
> manager, then point the users towards the repos for the.....other
> stuff.
> 
> But i'm not a coder, just an enthusiastic user, and passionate about
> spreading the linux audio word, so what do i know.
> 
> One more question.
> 
> Why does UBstudio have to follow the mainstream version schedule?
> 
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.

> Why not release UBS for only the LTS versions, and put the time and
> effort saved into a much longer timespan for the devs, and
> contributors, and finetuning UBS with audio related updates and
> improvements?

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.

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.

Jack is also something that is not trivial to keep current.

> 
> 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>

> On Sun, Apr 12, 2009 at 11:19 PM, Eric Hedekar <afterthebeep at gmail.comy> wrote:
> 
>> Sometimes helping out with the dev team really is just that simple - create
>> a page on the wiki.  I think that's well within everyone's abilities here............
> 
Amen to that.

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

iEYEARECAAYFAkniXd8ACgkQwRXgH3rKGfNPQgCcCtawhUr7Lbb3eM2IA94PcVLJ
ICQAnRTLw+iggn0Bn6MFS3u1jhEAhTz2
=ZBVY
-----END PGP SIGNATURE-----