kdeinit (was: Summary from Buildsystem BoF at Desktop Summit)

[Oswald Buddenhagen]

On Sat, Aug 20, 2011 at 02:43:49PM +0200, Thiago Macieira wrote:
> On Saturday, 20 de August de 2011 14:11:32 Oswald Buddenhagen wrote:
> > yeah, at the cost of rather considerable instability.
> > we should see whether regular service activation isn't the better
> > option, now that we have it.
> 
> What instability? If kded crashes, what makes you think individual services 
> won't crash, in addition to taking longer to load and use more memory?
> 
look at it from the perspective of the daemon, not the modules.
there have been *tons* of bugs related to crashes and freezes in
kded - which were module bugs actually.
in-process is simply no sound architecture from a stability (and
security) pov. guess which other kde component i'm thinking of ...

> One problem with a no-exec scenario is the inability to switch security 
> contexts and to control them on a per-binary case. Today, that is. There's 
> nothing preventing additional code to be introduced to do that,
>
indeed, that's what i suggested as well.

> if we start from an all-privileged daemon like systemd. It's privilege
> elevation that suffers.
> 
does the session systemd run privileged in the first place?

> [...] The end result is that the launcher has a lot more COW
> operations that aren't its fault and its pages are duplicated
> everywhere.
> If there's a privilege boundary in the process, then this might even
> be a security risk [...]
> 
yeah, both of these concern result from systemd being "a bit" more than
kdeinit. they could be mitigated by forking off the actual launcher
process very early, but this may turn out ugly.

> It's far easier to introduce the feature we want into the prelinker and 
> dynamic loader, such as having a "stasis" process: the dynamic loader could 
> load everything as needed, then freeze the images just prior to running any 
> code.
> 
one can have that with some ptrace trickery.
but i'm not sure how this fixes the problem. do you want to exec() such
pre-initialized images?

> > i think it is pretty clear that our *code* is not going to be accepted
> > as the cross-desktop solution. [...]
> 
> I don't know where you got those numbers for weight, not to mention it's 
> completely ambiguous (did you mean memory consumption?).
>
code size => shared memory, page faults on load.

> But I don't care what they like or dislike: if the implementation is
> good, it should stay.
> 
there are two problems with that:
- history has shown that it doesn't matter what the pragmatic solution
  would be, on both sides (just remember the utterly ridiculous bike
  shedding when aRts dared to add a glib dependency)
- introducing a qt or even kde dependency into a so far gnome-only
  system can be a very real resource problem. that's not likely to apply
  to kglobalaccel (as it is pretty desktop-specific), but i'm assuming
  you are making a general statement


> I could even accept the alternate representation to be optional, so an
> UTF-8- to-UTF-16 coversion needs to happen when Qt-based code reads
> the config.
> 
on-demand conversion could lead to some nasty encoding ping-pong when
the data is accessed concurrently.

> The problem I found is the same as QUrl today: implicit sharing of lazily 
> constructed data. When you need to finish your lazy work, do you need to detach 
> or not? If you detach, only one side will get the non-lazy output. If you 
> don't detach, you need to somehow make the setting thread-safe -- which QUrl 
> doesn't do.
> 
not detaching needs to do atomic pointer replacement to avoid memory
leaks, but other than that it is relatively uncritical.
a problem is of course that the converted data would need a separate
allocation, as opposed to the embedded raw string data.

> This also carries the burden of checking the flags at many points in the code, 
> probably adding overhead to timing-sensitive code which many already find slow.
> 
when i was pondering this with andre, we came up with the idea to make
character access possible only through some kind of reference object, so
checking the need for detaching and conversions would have to be done
only when obtaining the reference.
but that was long before qt5 actually materialized, including its
"mostly source compatible" mandate.