User bus conclusion

[Thiago Macieira]

Em Quarta-feira, 10 de Novembro de 2010, às 17:05:05, Lennart Poettering 
escreveu:
> 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.

The reason I didn't see a problem is that I don't think the Plasma 
architecture has that problem. The configuration files are reloaded prior to 
saving, if I understand correctly what I'm being told in the KDE mailing list, 
and the change is saved to the config file immediately. That means the changes 
applied to one screen will not apply to the other until the application is 
restarted or reloads its configuration.

Also, the architecture in Plasma is of anchors, not of precise positions, so 
it scales across screen sizes. It also has activities (i.e., different panel 
and desktop configurations), so if you're on your big screen, you should use 
the activity that is suited to that. You keep precise configs for the screen 
you're in.

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

Ok, that's the first I'm hearing of that. I believe we must create a separate 
discussion on this. Have you engaged anyone from KDE and other DEs to discuss 
this?

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

It might be, but it's solving a problem that isn't solved elsewhere.

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

Ouch, that's not what we're doing. The process that forks doesn't have any 
locked mutexes or even spawned threads. Its only purpose is to preload some 
libraries so that libdl has a chance to do its work only once (it's also run 
with LD_BIND_NOW=1). Maybe this is solved with prelinking, but I haven't 
personally seen much of an uptake of this technology...

What does the session manager (systemd here?) have to do with page faults? Or 
random even?

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

It's not designing for broken drivers. It's working around the stubbornness of 
NVidia, by saving our users tens of megabytes of memory used, plus load-time 
relocations. It only takes 7 processes that need to do OpenGL to consume 100 
MB of memory. libnvidia-glcore.so.256.44 has 395613 relative relocations out 
of 402050 total relocations.

I'm pretty sure GNOME users have NVidia cards too.

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

Agreed.

-- 
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/782616a7/attachment.pgp>