This … is the key right now. We are iterating tests and this period we are in now we are pulling the client up a few notches. Essentially the tests are great the improvements I think are pretty good each iteration and we are happy we are closing on Alpha releases soon enough. Essentially nobody knows, but hopefully we all see the effort is maximum and that is all we can ask.
This is a great place to be IMO.
[facepalm]
Evidently some people believe it is. And clearly some people have decided they can piss on you for asking. Ask as often as you want and be as mad as you want. This is an open forum and your concerns are as important as the next guys. Dont be intimidated.
But let me offer that David and team are working as best they can at delivering a bulletproof product and it may take another 6 months or a year for it to come together. It’s been a much more relaxed place since they stopped teasing the community with “…hopefully next week”, “…in a few days”, and other hollow inferences.
There are hundreds if not thousands of people that share your sentiments but have learned that there is nothing that can be done to change the pace of progress. Some have abandoned hope, some have turned against the community and team, some become pro FUDsters, some are cry babies, some just suck it up & wait… Pick one.
Hope that helps.
Nicely put!
(Emphasis mine AND my pick) 
GETs/PUTs/POSTs/DELETEs OH MY!
Did I miss something in the last update? Is the test network still runnning or not? I’m having trouble logging in or registering new accounts. So is the network still up or not? My vault works but not the launcher. Glitch or intended?
I was just able to connect to the network to create an account without issue.
I had that issue a few days back. Good old reboot solved it for me.
on what OS?.. Linux shouldn’t need a reboot!
It’s a good question… experience here is degraded. DNS lookup at least is very sticky and not remotely what it was at the start of the test. I can’t tell if there’s an incompatibility issue now with the central droplets… but it’s as if something is off from where it was. I wonder if the network suffered a disruption. Last night I couldn’t get a clear sense of if established websites are still up. Running the scan tonight, is getting stuck in the same way and restarting the launcher does little to progress it. I’m inclined to wait to Test 5 more than expecting that what is left of Test 4 is worth chasing after. I also wonder that the devs are reasonably pushing stresses in ways that do degrade performance and strain the network to test it… which is what tests are for.
The reboot was Linux that had a vault running for about 4 days non stop. Tried restarting only the launcher a few times not wanting to interrupt the vault but no luck. As soon as I rebooted I could access my old account and create new, not possible prior.
Edit: Mint, if it makes any difference
hmm… I have Mint and so rebooted.
On occasions past I’ve found a launcher process running where the launcher GUI is closed but don’t think that’s it this time.
The wget is notionally 30secs and gives up… yet it’s sticky for minutes at a time. I half wondered if they’ve put some DDOS protection to limit too many DNS lookups in a period from one IP but expect that’s not it either. The terminal give limited information about any progress that’s being made, so I can’t make it out.
My very unscientific impression was that some sites that did exist, now don’t … fiee.safenet I think was one and I’m stuck on abittner.safenet where that PublicID I know did exist. Curious that it’s sticking on those… which is why I wondered the network has seen a disruptive event that has it think that data exists and then it can’t find it. Still, I don’t know why wget doesn’t just give up after 30secs… I suspect it receives a yes the data exists response and waits for the data that’s then not arriving. … but I am guessing with little to go on and could be wrong.
If you look at http://explore.yvette.safenet that is still the old list and towards the bottom lists PublicID without a known website. It would be encouraging to know that others can still see sites listed there, as that would suggest user error here rather than network issue.
Edit: just to add that the way around this for me atm is ctrl-z putting the spider to pause in the background. Stopping and restarting the launcher and then bringing the spider process back to the foreground with fg… but that doesn’t always work and the crawl list is too long for me to persist. I’ll see if it can get to the end this evening and post what I can see later.
Well, if you’re truly asking, I’d say “no earlier than yesterday, and LIKELY no later than the end of the universe.”
Just to be SAFE.
So, something has disrupted the websites that existed Sun evening in Test 4.
The crawl this evening, stuck many times and seemingly those points it stuck related to the websites that did exist but don’t respond now… or at least they don’t respond in good time.
On Sunday including the simple sites with default template there were 45 sites.
The survivors look to be these 7:
http://upstate.safenet
http://hob.safenet
http://quotes.blindsite.safenet
http://explore.yvette.safenet
http://maze.safenet
http://hello.safenet
http://dcymatrix.safenet
I found exactly the same number of PublicIDs=47 - that is 404 responses from requests to those. Though on a quick look at them, it seems only 38 are the same PublicIDs, so that’s curious… perhaps users deleting them with the API, or the network forgot them entirely.
New PublicIDs appear to be
daniel.safenet
engineerfree.safenet
ghost.safenet
hob.safenet
maidsafe.safenet
maveric.safenet
safe.safenet
steve.safenet
wes.safenet
… and obvously, it’s possible there are websites to those PublicIDs that I’m unaware of. Equally there are likely other PublicIDs beyond those I guessed at.
Responses for sites that never existed, seem as fast as ever; so, I don’t think there’s a problem with the DNS, so much as the data that cannot be retrieved.
Where a website existed and now apparently does not, the reply or lack of it appears to stall the launcher in a way that only restarting it can help. There were a few occasions where that restart didn’t help and those centred on websites that I knew had existed.
So, all very curious… perhaps it’s more obvious to the devs what disruption the network suffered and naturally some of that might have been intended.
What I’d like to see is the network capable of responding to NEVER events. So, where data is lost, the network and launcher should acknowledge that in a sensible way - surprise perhaps but not stalling with some vain expectation that the data will necessity arrive. In the case that users cleanly delete subdomains or PublicIDs that did exist, the response I would expect should be as clean as if those never existed.
Brain over and looks like time to dream of Test 5… or perhaps an excuse for @bluebird to startup a community net again??
That was always the plan: once testnet4 is finished then community1 gets a reboot. In the next 12 hours seems a good time.
Bad news in Odroid - Hardkernel have released Ubuntu 16.04 LTS for U2/U3 but it’s used a 3.8 kernel, and this will never be updated.
Apparently there is a 4.x kernel but it’s all DIY with very little support.
More here:
It’s there any point continuing with Odroid-U3?
I think we need to look a bit further into this actually and see if we really do require the socket_reuse parts. That seems like a bit of a disappointment if 03 is going to languish in old kernels mind you. Recently many security folks are looking deeper at the kernel and it’s security, so a few things to keep in mind.
I just don’t know right now, we have about 20 of these things kicking about as well so seems like such a waste.