Re: how is pulseaudio supposed to work?

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

 



On Dec 19, 2007 11:05 AM, Les Mikesell <lesmikesell@xxxxxxxxx> wrote:
> I just don't see  the conceptual difference between this device and
> (say) a tape device.  It seems as silly to give exclusive access to a
> sound device based on an assumed proximity as it would with a tape
> device that is likely to also be needed for scheduled jobs - and will
> need exclusive access.   And even stranger to tie access to some
> particular window manager startup when many different ones may be
> running along with processes not running under X and ones tunneled via
> ssh instead of having a local session.

Maybe there is no conceptual difference... which is why I think we're
expressing frustration at the wrong piece of the new world order.
Now that the default hal rules no longer "hide" internal disk drive
partitions from gnome-volume-manager even if they are explicitly
listed in fstab, I imagine this will also be a cause for frustration
similar to the tape drive  or the audio hardware scenario. Same goes
for cd changers.

I think the underlying problem is that advanced hardware access policy
technology is advancing far more rapidly than local administrators are
able to keep up with and its disrupting workflow that has been used
for years.  It's the bargain price of rapid innovation.  I don't think
there are insurmountable things going on, I just don't think we have a
good enough understanding on how to use HAL/CK/PK to do local policy
hardware access customizations, so we end up fighting the technologies
instead of reconfiguration them.

What we need to understand better as local sysadmins is how PolicyKit,
ConsoleKit, and Hal  can be re-configured to support well defined
multuser environments scenarios, and limit how session related daemons
get access to hardware.   I don't know about you, but I learn best by
having one or two tasked-based examples of how to reconfigure these
things. For example having an example on how to write new
configurations for these technologies that let me pre-emptively get
access to a sound output for mpd in such a way that the user desktop
PA daemon loses control would be a good read. Or how to reconfigure
things so local tape/harddrive partitions are restricted from console
user access so they can be used by automated backup services running
out of cron.  And I don't mean "find the hal policy definition file
that came with F7 and drop it on your system."  We need to actually
have from scratch examples to work through, so we can understand the
logic of constructing the configuration, not cookie cutter recipes to
'fix' things.

I'll also say that I've seen the same sort of frustrations being
expressed of selinux when it was introduced. The recent blog posts
from Dan Walsh concerning how to actually reconfigure the selinux
policy to get non-default things done have been exactly the sort of
"re-learning" material that all the new technologies are going to
need.  The lock down of x-guest environment blog posts in particular
have been good to help me think about actually using selinux to get
something done and not just finding ways to disable selinux because
its in the way.  What we really need is this sort re-configure "Use
CK/PK/Hal" to get something cool done. Unfortunately, as with the case
of the selinux stuff, we really need the people who grok these
technologies to produce this "re-learning" material, because the rest
of us are just completely and utterly lost and are going to continue
to work around these technologies instead of attempting to use them.

Questions for the future.
Can we develop drop-in configurations to replace the default configs
for CK/PK/Hal which provide a better starting point for defined
multi-user usage cases? Can we develop graphical tools which help
tweak those configs for local needs? Will this tie into sabayon?  I
would think there would be a compelling RHEL need to introduce some
local admin-centric helper tools for local hardware access policy
decisions, so local admins will start to reach for the new technology
as a solution instead of fighting it by just trying to turn it off or
work around it.

-jef"And by we.. I mean not me."spaleta

-- 
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux