User bus conclusion

[Lennart Poettering]

On Wed, 10.11.10 16:50, Thiago Macieira (thiago at kde.org) wrote:

> 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...

User logs in once. User logs in a second time. Both graphically. Now he
adds two applets to his first login. One RSS feed applet show his
favourite slashdot.org feed, the other one another RSS feed
spiegel.de. Now he logs out from the first login. Logs out from the
second. Logs in again. Should both applets now be shown? Logs in again
on the second as well. Should he now have 4 applets in total? He kills
an applet on one screen. Should the applet be removed on the other too?
Or only when he logs out? Or never? If he moves the applet around on one
screen, should it move around on the other too? Or should it only change
position after logout/relogin? Or would you keep it all time seperate?
But how would you do this, when he logs in again, how would you select
the stored applet info to restore? Now, to make it even messier he uses
two different screens for this: one small one and one big one. Because
he has way more real estate on one than on the other he has a lot more
applets on one than on the other. So, if he logs out now, and logs in,
what happens with his earlier configuration?

And it only gets messier from there. As soon as you save state that is
dependent on the screen you lost. That's why I believe we shouldn't ever
support multiple graphical logins.

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

Not entirely. "systemd as a system manager" is a distro decision. "systemd
as a session manager" is a decision for the DEs.

> > 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.

Yes, I know why KDE does this. Doesn't change the fact that it is a bad
idea. But this is nothing to discuss here and now.

> 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)

Yes, I know. If loading C++ libs/binaries is slow then maybe it's a good
idea to fix that instead of coming up with crazy hacks that break the
audit trail, cause constant random page faults in the session manager, leaves
mutexes in an undefined state, breaks threading and is actually
explicitly recommended not do by the POSIX specs.

> 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.

Well, it's sad that KDE is apparently specifically designed for closed
source drivers, instead of cleanliness and correctness.

But anyway, this is really not a discussion to have hear and now.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.