Well I’ve made a point to AVOID Windows 8 and 10 in fact I’ve gone to quite extreme lengths to do so. I don’t want anything to do with those systems if I can avoid it. Windows 7 works fine for the gaming I need to do and Linux works fine for everything else.
As for Manjaro Linux it’s basically a user friendly version of Arch Linux. All the control without the bad interface isues.
Can’t get my invitation code to work. Disabled my VPN and clicked on the ‘Set IP’ button, see the ‘Please wait…’ message and after a couple of minutes it goes into an empty error message. 'Error; '. It recognises the current IP, but I somehow can’t get it to register.
I have the same issue, can’t set my IP. I do get an invitation token but when I try to login I get this error: Core error: Unexpected: Could not connect to the SAFE Network
The apps seem to be able to run fine from the nfs though.
Btw, one detail about the UI, for long “domains”, I think it would be better if it automatically resized its font size to keep the URI within the screen of the Web-Hosting-Manager.
I have the exact same error as @beekeeper. The request to https://invite.maidsafe.net/invite/resetIp takes very long and then I get a “504 Gateway Time-out” error response from nginx. Is the service overloaded or is there some other issue on your side @maidsafe?
To be more exact: for Linux it doesn’t depend as much on the distribution (like Manjaro or Arch, etc.), but on the desktop environment and on the program that handles custom URI schemes, which apparently is different on each DE. In general case, it’s xdg-open, but it could be just an alias to some custom implementation, like gnome-open (for Gnome Shell) or gvfs-open (default on Ubuntu). And to quote the Arch wiki:
So you probably might try replacing xdg-open with e.g. gvfs-open and most likely it should work fine.
The issue here seems to not be the invite server but the droplets themselves. So droplets did not have a swap memory at all. So on some of the nodes it went over its minimal actual memory and thereby shut the vault off only in a handful of proxy nodes. On some of these it also caused the droplet to hang which then prevented the invite server from being able to edit the client whitelist.
Luckily since the network already has churn process integrated, it has allowed us to simply set some swap memory on the nodes and start the vaults on the affected nodes back up. We did not intend to be testing churn on TEST-17 but good thing it works and was tested in an unintentional way I guess.
Invite server should be back online now I think and we’ll keep an eye on the droplets to see if the hanging issue is reproduced later on as that part is still a question as to what caused some nodes to hang.