[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Jackd hell and other oddities



On Thu, 2007-04-12 at 18:03 -0400, Eric Dantan Rzewnicki wrote:
> On Thu, Apr 12, 2007 at 10:33:32PM +0200, Ismael Valladolid Torres wrote:
> > Eric Dantan Rzewnicki escribe:
> > > /etc/security/limits.conf needs to be set up as well. It's a simple
> > > step, but I guess it would be good if users didn't have to ask about it.
> > 
> > A multimedia dedicated distro should ship /etc/security/limits.conf
> > configured for realtime but not a generic distro. Letting all process
> > from a user in the group audio getting realtime could pose a security
> > problem in a server setup.
> 
> Sure, but some sort of audio-workstation meta-package could perhaps
> include a debconf question that sets this up based on user input or
> something.

 Debconf is powerful, but it works best when it is non-interactive;
"strong and silent".  Most users will only know one way to encounter 
debconf: at install time.  There is no compelling and discoverable 
UI to debconf on a freshly installed GNOME or KDE desktop!

 This configuration must be possible to find by digging a little in
the "System" menu on GNOME or in KDEs control center.  And it needs
to be triggered by the installation of packages that "suggest" low
latency features. 
 Why should the user have to know _in advance_ what settings to tweak
to make an app work?  The app's packagers  should have that knowledge,
and present that information in a convenient way.  And not by dumping
a README.txt into a pager.  If you have the power to compile source
code and build packages, you also have the power to add new components
in the Desktop Environment that will provide a nice and shiny UI with
all the choices the user must make.  Not necessarily at install time;
at runtime is often more convenient.

 What is missing is a policy on how such UI-plumbing is supposed to
be done.


>  It would of course not be something installed by default on
> all systems whether asked for or not.

 It probably should be the default for an audiovisual workstation.
But then again, the user ought to be warned that services that 
require high availability should not be hosted on that computer!

-- 
 Herman Robak





Reply to: