-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Sun, Sep 25, 2016 at 05:41:35PM -0700, [email protected] wrote: > > > > 1... > > > Why is there a /usr/bin/python /usr/lib/qubes/icon-receiver script > > running > > > once for each virtual? > > > Why can't it just have 1 instance running and then spawn a copy when it > > > receives data and thus reduce overhead by having only 1 process running > > > taking 30 MB RAM, instead of 30 MB for every virtual when it's not even > > > needed all the time? > > > > To make it simpler. Having one process for all the VMs would require > > making sure to not mixup contexts (like assigning green icon to red VM). > > > > It's a receiver, not a poster. > If it isn't JUST a receiver, why is it called a receiver? (very deceptive)
It is receiver - it receives icons from VM. > > > Why not just start it when the script is run for the > > > transfer of icons? > > > > Mostly for performance. It's startup takes 0.5s or more. Starting it on > > demand would mean 0.5s delay in adding an icon to window, which would > > not look pretty. And would also use a lot more CPU. > > > > But it is something we may consider to lower memory usage. This would > > also require having someone to actually work on it - as we already have > > way too much work for our little team. So if that's important for you, > > consider working on it. > > > > 0.5 seconds... and yet I have to wait for 30-45 seconds for it to be done > anyway. an extra half a second will hardly be noticible. > CPU usage for a moment when sending icons from guest to dom0 wouldn't cause > any issues at all. It isn't about only initial application startup, but every window. For example if you open a file, you'll have additional 0.5s on file section dialog... > > > 2. > > > /usr/bin/python2 /usr/bin/qubes-manager -session > > > xxxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx_xxxxxxxxxx_xxxxxx > > > Why is that using 118 MB RAM? > > > Why over 1 GB of virtual? > > > > There are some memory leaks in qubes-manager. Some of them were recently > > fixed, but its current architecture makes is really hard at least to fix > > all of them. This is one of the reasons why we're rewriting it from > > scratch: > > https://github.com/QubesOS/qubes-issues/issues/2132 > > <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2FQubesOS%2Fqubes-issues%2Fissues%2F2132&sa=D&sntz=1&usg=AFQjCNGgENvR6dQsEnXhTtqgfz3UKzzPSA> > > > > > > Yes, your QM does have a lot of memory leaks, but that's just the way > Python works with the widgets you are using, instead of allowing them to be > turned on separately they are always active. > > ReWriting from scratch would be good. > What language is it going to be written in? > Will it have a decent UI? > Will it be available for 3.2? No, in 4.0. For other questions read linked ticket and a discussion 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. > > > 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. > 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. 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' - -- 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 iQEcBAEBCAAGBQJX6Ox1AAoJENuP0xzK19csLDEH/2pPLcT5u3GINMSG8wU5FYbY TBtuzEe4etEc9Yah3l+frCZi/xqRTcvKkkTBYDBxgyzji+Ol5jZhP4i0r27jmVrV +nngijEjxE6Y0p59tIFxHI+18mXanliyejTQ+mmIRRT4fvE51PcrpBAepqMAv+R7 Oa93ojgAW+tk8GIZEPBPEOYCSKJr4U9/iWKhDJCUgHkeCHB8xusFJDPY+u/dnRtR M7fyurV2iyd56RXDjAjSEsU4Ym6hgl3R32MXsiWMgOWmT0teKyNpDpLctfHjI4DR +TDuvIhYtuNXnNDW/cwh/go/MAaU353v8l5TVOFqbrCJ+rf8DHGYGJZ9s2MlBQc= =gc+S -----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/20160926093757.GY31510%40mail-itl. For more options, visit https://groups.google.com/d/optout.
