[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