User bus conclusion
thiago at kde.org
Wed Nov 10 07:50:26 PST 2010
Em Quarta-feira, 10 de Novembro de 2010, às 14:15:35, Lennart Poettering
> 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
> 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
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
Size: 190 bytes
Desc: This is a digitally signed message part.
More information about the dbus