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

[Alexander Neundorf]

On Sunday 21 August 2011, Thiago Macieira wrote:
> On Sunday, 21 de August de 2011 10:19:26 Oswald Buddenhagen wrote:
> > > 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 ...
> 
> Sure, if each of 10 modules has a certain chance of failure or MTBF, the
> whole process has a much greater chance of failure or smaller MTBF. But if
> you look from the point of view from the system that requires each of
> those services, it doesn't matter if the crash brings down all services or
> just one.
> 
> In any case, kded restarts.
> 
> > > 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?
> 
> I have no clue. I don't even know if there's a session systemd.
> 
> > > 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?
> 
> This isn't a fully-formed idea. It might need kernel help too.
> 
> > > > 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.
> 
> That is true. But it is not proven. Sure, QtCore is much bigger than glib:
> 
> $ ls -l /usr/lib/libQtCore.so.4.8.0 /lib/libglib-2.0.so.0.2800.8
> -rwxr-xr-x 1 root root  979028 Jun  8 02:53 /lib/libglib-2.0.so.0.2800.8*
> -rwxr-xr-x 1 root root 2980096 Jul 25 22:28 /usr/lib/libQtCore.so.4.8.0*
> 
> But file sizes don't mean much. You'd have to check how much in page faults
> really happens to fault in those services: given comparable uses of the
> libraries, what is the actual memory use? What's more, you can also justify
> it as a trade-off in readability and maintainabilty.
> 
> In a running system, where QtCore is already loaded, there aren't any page
> faults to load the code or marginal increase in memory usage because of it.
> And if we fix the above problem of prelinking, the prelinked read-only data
> can also be shared.
> 
> (note my use of commas in "where QtCore is already loaded": it's not a
> restrictive definition of system, it's an explanation of it; for me, there
> are no systems where QtCore isn't already loaded)
> 
> > - 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
> 
> Right. And if we accept glib dependencies, I don't see why they shouldn't
> accept QtCore dependencies.


Yes. Requiring QtCore as a dependency should be seen the same way as requiring 
glib. It's not a huge library, it has few dependencies, and it is there on 
many many systems anyway (e.g. all systems I have access to).

We should work on that. Being able to use QtCore is great, I want to have it 
available on every system. There's no reason for us to say "yeah, we know it's 
big, so it's ok if you rewrite everything using glib instead".

QtCore is fine.

Alex