Dom0 and processes.

[drew....@gmail.com]

Hi folks,

I'm wanting to enquire as to some things that I believe that the developers only can answer.

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? Why not just start it when the script is run for the transfer of icons?

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?
Why does it have a session id attached to it instead of just running?

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?

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Thu, Sep 22, 2016 at 08:36:11PM -0700, drew....@gmail.com wrote:
> Hi folks,
>
> I'm wanting to enquire as to some things that I believe that the developers
> only can answer.
>
> 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).

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

> 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

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

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

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

iQEcBAEBCAAGBQJX5PFwAAoJENuP0xzK19csVL4IAJJPuRnr8M1CesVMLpNbf3bG
kInToSCawq8KrGalYltKO/lP6ApWMbqOq8w5cUilzJZPyVU9MIKPzk8lP3/mZFwQ
MAFRo0nUVkM6aeC92N/B28WdnbaW6OtfVtR0TxOGQDUROyRF+mrotuszy0eCU3Xe
K2JvsDsM8u8xGVRnQqjgTyM/o8pFKJqfn3CG1cgFqc+zhmByidzba2WFXs0iomUw
vHmdYva98UYd9Ei15zTquXRImVLV2YaEli3W2g7IOD4O8aX0TCRMpq8d2y0Ul/qd
cb1JaXpLlWhAGC3JN4Xcen8IhYkxonnZbzAuzx7r+AREcptYHwiwEjU3shUx9U4=
=+kww
-----END PGP SIGNATURE-----

[drew....@gmail.com]

> 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

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.

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Sun, Sep 25, 2016 at 05:41:35PM -0700, drew....@gmail.com 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-----

[drew....@gmail.com]

On Monday, 26 September 2016 19:38:05 UTC+10, Marek Marczykowski-Górecki wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Sun, Sep 25, 2016 at 05:41:35PM -0700, drew....@gmail.com 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.

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?

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

When you install an application on the virtual it tells dom0 that there are more applications/icons.
That in itself takes at least 10 seconds. Another 0.5 seconds (at most) isn't going to be much addon for it.


 

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

The dialog has a parent, and has the parent icon, so it just gets the icon from the parent window, not from the VM again.
Or are you actually fetching the icon from the VM causing more and more overhead every time a dialog pops up?


 

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

I read that, but that didn't answer my question succinctly.

 

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

If it was a part of the WM, then it would happen all the time. But other processes in the system don't have that session tag on them, and they are things built for Qubes by Qubes-OS.

Thus, I was confused and needing to enquire.


 

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

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

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.
Thus, less running to sit there taking RAM and CPU time and sitting there listening and waiting for input.

1 processes accepting input rather than 20... I think it's something worth looking into.

I do understand that time is short for your "little team" as you put it, and things take time to get done.
If I was able to just pick up the code and do the work I would, but there aren't comments or anything there that would allow me to easily follow the code.

So that's why I have to leave it up to the professionals in most cases. But if it's something that you would most likely put on the back burner, I would be happy to look into it and follow through to finding out the tasks that need to be done, and even implementing and testing them.


Sincerely,
Drew.

P.S. Please don't misunderstand anything I'm saying, I'm merely providing information and trying to find out information, nothing is meant to make you uncomfortable or feel like an attack or harassment or anything. If it does, I apologise, it is not meant to.

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Mon, Sep 26, 2016 at 06:35:10PM -0700, drew....@gmail.com 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-----

[drew....@gmail.com]

On Wednesday, 28 September 2016 08:09:23 UTC+10, Marek Marczykowski-Górecki wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Mon, Sep 26, 2016 at 06:35:10PM -0700, drew....@gmail.com 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.

so if I disable it, then it merely just can't change the icon from the default that dom0 has set at first?

 

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

I run Qubes myself, not as a startup, and it has no session on it, no session id, nothing like that. so it's something that someone at Qubes has done to do it during boot. (or so I assume since it's been like that since installation)
 

Makes sense. Just a shame that they are using so much RAM each.
But that's how Python works since all the libraries that you are loading on 1 instance.


 

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

But they are still using RAM, and a lot more than you thought.
So is this just meaning there is something wrong or???

 

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

What would it take for me to get a full code copy of the last version when 4 comes out and you stop advancing 3.*?
That way I can get a copy and build and all myself.
That way, NOT requiring the technology that is not in my PC, but version 4 will REQUIRE.
Then the older version can continue to advance and remain secure and stable instead of becoming obsolete.

I think that qrexec could be changed too. they may hold a state, but they can keep the state internally in maybe 10 bytes of RAM, instead of having 20 MB for separate processes. Since it's only there to pass commands from dom0 to the virtual?

If the code was commented, I would be able to follow it and find all this out instead of having to ask.