-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Mon, Sep 26, 2016 at 06:35:10PM -0700, [email protected] wrote: > On Monday, 26 September 2016 19:38:05 UTC+10, Marek Marczykowski-Górecki > wrote: > > It is receiver - it receives icons from VM. > > > > Okay, so bear with me on this, maybe I'm just not understanding... > > You say it's a receiver.. It receives the icons from the VM... > The icons are already local to Dom0 via the app-menu synchronisation script. > So why is it that it needs this running all the time? You have the icons > locally, they need not be remote. > They are all in the .desktop files in the applications folder are they not?
No, this is about different icon - not the one in the menu, but the one in window title bar. Application can place there any icon and even change it during runtime. For example my IM client has remote user avatar there. (...) > > > > > Why does it have a session id attached to it instead of just > > running? > > > > > > > > This is how desktop environment (KDE?) start applications. In case of > > > > qubes-manager it is ignored. > > > > > > > > > > 1. I've never seen KDE attach session IDs to processes. Nor any GUI in > > > Linux. > > > 2. I'm using xFCE > > > 3. The IDs were there in KDE as well. > > > > I think this is Qt/KDE thing. I've just tried with "konsole" and when it > > is restored as part of saved session (not closed on logoff), it also > > have "-session xxxxx" parameter. > > > > I have my own App Runner that I use that integrates with Qubes. I ahve my > own manager that I can use for basic tasks of starting stopping killing and > more. It uses Qt. Whether on KDE, XFCE or any other WM that I have ever > seen, I have NEVER had a "-session xxxxx" on it. Maybe it depends on some QtApplication object settings. > > > > > 3. > > > > > Why is there a > > > > > /usr/lib/qubes/qrexec-daemon > > > > > running for every virtual? > > > > > and a > > > > > /usr/sbin/qubesdb-daemon > > > > > > > > > > Will this be rectified instead of sitting there absorbing system > > > > resources > > > > > in a future update? > > > > > > > > No, those are intentionally separate processes (same as before - to > > make > > > > code simpler, which is very important in security critical > > components). > > > > Both of them together use about 1MB RAM, so it's negligible. > > > > > > > > > > how does it make code simpler? it's the same piece of code for the whole > > > thing. Multiple processes using identical code. > > > > Because a single process don't need to worry about message origin - it > > talks only to a single VM. No need to policy what should go where. > > > > While that makes sense, it's only a single switch and maybe 2 bytes of code > that have to be added in to any packet. It may look simple, but in practice it is not. There are many things in a single process that are shared - for example open files, shared memory and more. Handling multiple VMs in a single process means you need to take care to isolate those things. When having it in multiple processes - - operating system does the job for you. > > > So if they use 1 MB ram in total, why doe I have 7 qrexec-daemons > > running > > > at over 2000 kb? > > > I also have 7 of the qubesdb-daemon running at over 2800 kb RAM usage. > > > > Still, this is negligible in comparison to 200+ MB per VM. > > > > Okay, look at it this way... > > If there are 3 per VM.. That's 10 MB per VM. (as a current maximum for > those 3 processes) > That means when I have 20 VMs started I have 20 MB RAM used. That means I > have 60 threads running that could all run at the same time causing the PC > to lag badly. Those processes _passively_ wait for VM (or dom0) requests. > If you worry about RAM usage, here is a hint: kill packagekitd in VMs. > > The service itself is disabled, but apparently something do start it > > from time to time. And it can use 30-50MB or even more. > > > > qvm-run --all -u root 'killall packagekitd' > > > > > If it was only 3 processes at <3 MB each for all VMs... Then it could just > receive the task, perform the action without hastle. > > So instead of adding in a case statement that just says it's this vm it is > this vms window/task/icon/whatever, you run multiple instances. > > It really would be simple and cleaner to add in the few lines of code (I > assume from what I have seen), rather than running so many processes > absorbing RAM and CPU time. > > At worst case, when it's needed to create another instance to do something, > it can just spawn a sub daemon that runs and dies. I think this approach could be used for window icons, as it mostly doesn't carry any state (so such "sub daemon" really could die after handling request). But not qrexec or qubesdb, which do hold some state. Anyway, probably wont happen anytime soon, unless someone (you?) send a patch. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJX6u4KAAoJENuP0xzK19csuQ8H/RjbYMNb5goGR7ZKtl9ODeLh F5oA8TMh1EglFbOuWFyHms8tUL0sBFeeeZMY+kolD7ZAS8hDFj4EbND2DrYNP8c3 U7ti8ETnTHjwRgIc4ascOJU7k0Qh5JwWsmDX1PPjSqv6euQOxbQL1RV0F57sKpdZ bSdcbj38MZtw0S1npdXOa63KdXrh9nRW6kQaeYzu/l+Y8jvRa1EJoN7k3Um9FBz1 sAcjRWiQd0uE0p+vYQWNnbx+0BxWSzguH8niqp2pzOXDuE+EwzeRrqTDrtSKePUq GJ6zOmj31m1gQNiP4jbqxitoQwRjRaMFZC2fWPM2RiE0qSWoLw9efZClrh70SvE= =th0I -----END PGP SIGNATURE----- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/20160927220914.GI31510%40mail-itl. For more options, visit https://groups.google.com/d/optout.
