Thank you for this constructive argument
Have a nice day.
@markhewitt1978 Hi, thank you for your feedbacks!
We are aware that this limitation bothers a lot of users and we have plan to address that in the next major version of XO.
XO 5 was already a major improvement over its predecessor because it allows viewing and handling a much bigger infra.
XO 6 will go further in this direction by introducing a tree view and the possibility to edit and handle many objects at the same time.
@Danp That may not be directly to script but to the external environment: SMB works much better if
cifs-utils is installed on the system, something that is present on our doc but might be missing in some install scripts.
We have no animosity whatsoever regarding these scripts but we prefer our appliances (or even manual installs from our documentation) because we understand much better what's going on and it's easier to replicate and fix the issues
Regarding your idea of including the commit identifier for the source version, that's not a bad idea, a (as simple as possible) implementation in a PR would be welcome
Thank you all for your reports, should be fixed
@rizaemet-0 Thank you, this is really interesting, it suggest that HTTP encryption in XO is a CPU bottleneck.
It should be alleviated in the future, because in a couple of month, all backup jobs should run in separate process, which will better distribute load on multiple CPUs.
@s-pam we were not able to reproduce so far on our side. Also, most of the XO team (myself included) is on holidays until next week, thus I'm not sure we'll be able to fix it before.
If you are using an official XO appliance, you can rollback to the
stable channel and if you are using XO from the sources, you can go back to a previous commit.