One two three first.!!
Now to read really looking forward to this one
Well done to all the team for all the hard work.
Second and a whole 8 minutes late!
Thanks so much to the entire Maidsafe team for all of your hard work!
There’s been some more buying of eMAID on the DEX. Here is the link to the latest activity MaidSafeCoin (eMAID) Token Tracker | Etherscan.
Great work again, thank you!
As a non-techie I wonder…
… how can you even have different nodes, when you’re spinning them up in DO? Is it just because of this, or something else too:
Is there a way to eliminate that class of problems altogether?
From your post it may seem that single-threaded code is better.
No. It is generally worse. But it is easier to make.
Thinking about multithreading when network can’t survive for several hours may be interpreted as premature optimization.
But when network will gain more stability, it will be the time to think more close about multithreading again.
(I hope that no one will come with multiprocess solution - I hate it)
DO nodes ar mostly the same, but some can fail for any reason, but the nodes from homes are all different. Also some nodes fill faster than others etc.
We are working on this too.
Coupled with bug hunting, that sounds like a good weeks work all round.
Probably the least of your worries but do you think the issues of being able to join a node will be resolved for the next public testnet?
It should be that you can join if the network needs a node, but only if
Thanks for this amazing update!
You guys are getting real close now. Keep it up!
Fantastic update Maid team - one of the best yet IMO, thanks.
Looking like testnets in a month or two might reach full stability! Looking forward to that day when it goes up and stays up with no problems.
Progress is very apparent after a 3 week absence! Lord help me… I’m drowning.
I’m loving the switch to single threaded. I’ve written some complex threaded applications before, but when the node is designed to be horizontally scalable and independent, why not use it? The tests so far use a minimal amount of CPU, possibly a bunch of storage, and potentially a ton of bandwidth, which always was going to be the concern alongside latency. So many mind bending bugs no longer there… A NAS with fast storage and connection can take a few nodes, and a raspberry pi or the like can do one or two just fine alongside a simpler code base. Easy to deploy nodes in droplets. Win win as I see it.
I agree, great work! Oh man, we are getting closer and closer! Cheers
Thx 4 the upload Maidsafe devs
great job team
An elegant solution to the cutoff of SledDBC
We’re so close to SAFENET
Keep hacking super ants
Excellent update. Great job team Maidsafe
Thank you for the heavy work team MaidSafe! I add the translations in the first post
Privacy. Security. Freedom
Less bugs really. Those droplets were highlighting an issue we haven’t seen locally. The key is being able to spot the issues and repro them more easily. With the elastic server we have part one down, and with pending logging improvements and simpler code, the second part should be getting easier too.
Indeed, it’s been in the core code for so long, it was just how things were done in the code there. But it was increasingly apparent that it was causing complexity and bugs more than any benefit we were getting (as can be seen from those benches).
I don’t think the update implies we shouldn’t multithread. So much (as you say), let’s get it going as simply and cleanly as possible, and then see where are bottlenecks lie and what multi-threading may give us.
But the change up to a single-threaded-first approach definitely feels like a positive change for the codebase.