User bus conclusion

[Thiago Macieira]

Em Quarta-feira, 10 de Novembro de 2010, às 14:15:35, Lennart Poettering 
escreveu:
> On Wed, 10.11.10 08:56, Thiago Macieira (thiago at kde.org) wrote:
> > For the record, KDE hasn't decided that multiple logins are wrong. In
> > fact, they work and kdm does not block you from logging in. So I posted
> > to kde-core- devel to check whether this is intentional and it is a
> > use-case that KDE wants to actively support, or whether it's just
> > accidental and legacy because no one thought of the consequences.
> 
> Note that many programs that are often used in KDE already break if you
> do this (firefox, ...). Also, are you sure that KDE's gnome-panel
> equivalent can properly deal with this?

That's Plasma. But deal with what? I'm probably missing something, because I 
don't see something needing dealing with...

> > However, what happens if KDE decides that this is supported?
> 
> Well, my secret hope that I can convince KDE to switch to adopt systemd
> as session manager eventually. In systemd I definitely don't want to
> support three levels of busses and babysitting managers. So I really
> hope KDE doesn't decide to stick with the broken 3-level metaphor. (3
> levels = systemd, user, session). With systemd we want to define the
> user context programs run under as something that transcends all levels
> of our stack, from the kernel to the session manager, including cgroups,
> XDG_RUNTIME_DIR and everything else. I don't want to complicate that by
> adding a 3rd abstraction layer.

And we can agree that we want less complexity. But adopting systemd is not a 
KDE decision, it's a distribution decision.

I'm not sure that supporting multiple, simultaneous logins is a supported 
feature, like I said. I've just posted to k-c-d asking for confirmation either 
way.

> That all said, the question whether I can convince KDE to adopt systemd
> as session manager is probably nothing we should discuss here, and
> there's some issues we'd have to find good answers to because we can
> make this happen, i.e. KDE probably insists on support of
> fork()+dlopen() for spawning processes, but in systemd this is not going
> to happen. Also KDE probably cares about non-Linux much more than other
> desktops.

The problem being solved by fork+dlopen is the startup time for the relocation 
and basic initialisation of libraries (global statics, mostly, but could also 
be loading plugins, parsing basic config, etc.), as well as for sharing read-
only but dirty memory.

The latter point is quite considerable if you remember that C++ virtual tables 
are read-only but relocatable, so they are dirty pages. A large C++ library 
often has a lot of data there. For example, QtWebKit has 690k in its 
.data.rel.ro section (and the gtk equivalent has still 660k)

Worse, NVidia's libGL.so has impure text (not -fPIC) so each process using 
OpenGL on an NVidia system takes up 15 MB of additional, private memory.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Senior Product Manager - Nokia, Qt Development Frameworks
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freedesktop.org/archives/dbus/attachments/20101110/7a9da60c/attachment.pgp>