[ohm] OHM vs. PPM
Marc-André Lureau
marcandre.lureau at gmail.com
Sat May 3 04:35:48 PDT 2008
Hi,
On Fri, May 2, 2008 at 1:13 PM, Rob Taylor <rob.taylor at codethink.co.uk> wrote:
> Richard Hughes wrote:
> > Sure. OHM was designed super small, quick, and per-system for a reason -
> > I'm against the change making it per-session. OLPC needs a per-system
> > solution, and won't be doing this in the session at all.
>
> Hey Richard! It'd be good if you could go over the reasons for system
> level, and also how you see things fitting in with g-p-m.
>
> Personally, I'm not invested in a particular way forward, I just want a
> plan that works well for desktop and embedded :)
I second that. I thought you agreed that ohm fits better in the
session level in the discussion we had at Fosdem. Obviously, I
misunderstood. I can't wait to read your answer! For the design
principle, could you explain why current OHM could not fit in session
level? The X hack would disappear..
Certainly, for embedded devices, discussing OHM for system level or
session level make little sense, since there is often only one
"system" bus...
I personally believe that some policies are better run in system level
(to react to services and hardware) and some other in session level
(program/user requests, tweakable policies)
Why not having 2 instances of OHM: system (which has privileges and
can change policykit configuration) and one per session? Is it so bad?
I wish the goal of OHM is to have a common framework to express
policies, instead of having a dozen of different daemons, with hard
coded policies, different usages and coding styles.
I also wonder if OHM could offer a library that gnome-settings-daemon
could use to make session policy decisions (instead of having a
per-session ohm daemon)
regards,
--
Marc-André Lureau
More information about the Ohm-devel
mailing list