> 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) > > 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. > > 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? > > 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. > > 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. 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. That's not even the VIRTUAL, that's the PHYSICAL. My PC has only just started. -- 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/e0a2bc1c-28a4-4216-803e-03ed5890ed55%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
