Adam Clark

Hopefully this doesn't re-open the ticket - just wanted to add that the newest versions that have Wayland support seem to be much more efficient on my systems. Thanks for the suggestions along the way, too, it's been helpful in understanding and managing things.

Thanks, I did run through both of your suggestions. I think using X mode is the winner overall - CPU usage was a bit higher in Curses mode over X11 mode, and X mode is pretty minimal. The External Scaling option when using SDL makes things a little blurry, but does reduce CPU time as well. Is this just something that will always be seen under SDL mode?

Further, I should mention that the syncterm version is current from synchronet's gitlab master branch

syncterm CPU usage seems high

The mbtask binary is designed to be started by root, normally in a system startup script. It handles the tasks that require privileges, then drops privileges to the mbse user. Unless you're running a different system than what's published here, that's not true. mbtask, as most of the mbse binaries are installed, are run as the mbse user, SETUID root. That's a huge difference from running as the root user - in that, mbse's environment is there, intact, when the binary is run, including the MBSE_ROOT...

The mbtask binary is designed to be started by root, normally in a system startup script. It handles the tasks that require privileges, then drops privileges to the mbse user. Unless you're running a different system than what's published here, that's not true. mbtask, as most of the mbse binaries are installed, are run as the mbse user, SETUID root. That's a huge difference from running as the root user. If they were run as the root user, there'd be no user to drop privilege levels to. You have...

I believe the item that's compelling is the complexity around having multiple places where "root" for mbse is determined, and I know of no other software that claims it pays attention to a environment variable to determine it's root, and then also uses a user's home directory as a determining factor as well. Your description of the startup process seems to be incorrect. MBSE is started as the mbse user which is why the binaries have setUID on them - it requires root privileges to bind to privileged...

Hi there... This is really about having a difference of MBSE_ROOT and the mbse user's home directory. I haven't seen anything in the bits I've been looking at that suggests having a different installation prefix would cause problems if MBSE_ROOT and the mbse user's home directory are set to the same place.