Patrick Shirkey <[email protected]> writes: > Nedko Arnaudov wrote: >> Stéphane Letz <[email protected]> writes: >> >> >>> First we have to get a consensus on this "runtime choice of auto-start >>> strategy", then we'll have to find the best way to implement it. >>> >> >> I was against mixed jack1/jack2 and i'm against the runtime choice >> now. IMHO it complicates things for user instead of simplifying it. >> It also complicates codebase and I think we can spend our efforts with >> something else instead. Still, if someone has the motivation to do >> runtime choice of auto-strategy - fine, i can live with it. The only >> important thing is that with jackdbus the default strategy must be >> autostarting through dbus. If it is not, by default jackdbus control apps >> will not work with jackdbus. Such setup will be pretty useless, eh? >> >> > > > You will be isolating a whole lot of existing users by forcing a new > paradigm on them before they are ready. Just look at Facebook for a > good example of how this doesn't work. > > I think jack devs have to put the effort into making the transition to > a more flexible system as subtle as possible rather than smacking > people round the head with it.
I'm not forcing the new paradigm to anybody. I dont want to force and i cant force because i dont maintain neither jack1 nor jack2. jackdbus was optional and alternative from day zero. it was configure option in the very first dbus.patch that was against jack1 codebase. Packagers force users. Or users force themself. Developers create software. They may give advice but they dont deploy to end user. At least in open source world. -- Nedko Arnaudov <GnuPG KeyID: DE1716B0>
pgpvdk1giaWPk.pgp
Description: PGP signature
_______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
