[Openicc] Linux CM ideology .. Linux CM proposal

Richard Hughes hughsient at gmail.com
Tue Feb 8 04:26:05 PST 2011


On 8 February 2011 11:44, Kai-Uwe Behrmann <ku.b at gmx.de> wrote:
>> Fedora ships yajl by default for just libvirt.
>
> Yail, is one of many libraries for JSON. I see many JSON libraries comming
> with a Linux. Some of them are installed by default, e.g. libjson-glib or
> libqjson.

You're indeed right. json-glib is used by clutter, rhythmbox, mutter
and gnome-games extra in Fedora and is present on the CD media.

> I do not want to argue about a DBus interface.

Like it or not, DBus is _the_ standard way for processes to
interoperate with frameworks and applications in Unix-like operating
systems. There aren't many serious frameworks on a desktop Linux box
that either don't use DBus, or aren't wrapped by a DBus interface.
Even CUPS is wrapped, and both of the new init systems are controlled
by DBus now.

> But how performs Polkit on windows or osX? I guess its non portable.

No, PolicyKit is very portable. It's already useable on Solaris, and
the BSDs. Windows integration isn't something I'm personally bothered
about, as applications should be using the core framework on those
other operating systems, like ColorSync.

> Hiding the user data base in one single file for all users behind a system
> daemon is nonsense.

It is? Care to explain why?

> Users do not want other users to look into their privat settings.

We're not storing private settings. The fact that my DVI1 panel has
profile "GCM - Hewlett Packard - HP LP2480zx - 3CM82200KV
(2010-09-08).icc" associated with is is hardly private information.

> We have the file system and home directories. This works fine for remote
> home directories where a DB in /var is invisible.

The session preferences are stored in the users home directory, of
course. But /var/lib in the FHS is for persistent data specific to the
machine. The machine includes the devices attached to it. Take away
/var/lib on a multihead machine and more will break than just the
device -> profiles mapping...

> Hence colord in the current form is not an option at all. Its simply too
> complex and momolithic right from the beginning.

Can you expand on how you think it's complex? It's actually one of the
simplest daemons I think I've even written. Compared to a moderately
complex daemon like PackageKit it's 1% of the code size and
complexity.

> If we want to meet somewhere in respect to user settings, we need to start
> with a least common denominator. JSON seems a good candidate to me.

Least common denominator is not good enough. The session needs to
*query* things like "give me all the profiles for device $foo" and
"find all the devices that use profile $bar" which is why we should be
using a database, rather than searching discrete files on the
filesystem every time the session asks for data[1].

Richard.

[1] if you're caching the data to do the query, you have to provide an
IPC for the session to use rather than accessing the files directly
else very quickly the cache becomes decoherent.


More information about the openicc mailing list