Bitcoin Forum
December 14, 2024, 12:58:21 AM *
News: Latest Bitcoin Core release: 28.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 ... 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 [213] 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 ... 345 »
  Print  
Author Topic: [ANN][XEL] Elastic Project - The Decentralized Supercomputer  (Read 450532 times)
This is a self-moderated topic. If you do not want to be moderated by the person who started this topic, create a new topic.
sevenrustlust
Member
**
Offline Offline

Activity: 112
Merit: 10


View Profile
March 06, 2017, 09:44:46 PM
 #4241

I forgot to buy the ICO, when it will be released on exchange?

*sigh*
Don't make me cry more  Embarrassed Embarrassed
ImI
Legendary
*
Offline Offline

Activity: 1946
Merit: 1019



View Profile
March 06, 2017, 10:10:05 PM
 #4242


Two stage solution would make sense. First rudimentary network, then SN-network. Gives lots of room for testing and process of thought.

I completely agree...and I would prefer if we took this approach as well.  However, last I heard from EK, he still wanted to move forward with the SN approach for the initial release.

Well, for weeks now we have moved towards the SN approach. I mean, sure, we can stick to the rudimentary network for the start. But imho this will be more complex than going the last remaining meters towards the SN approach. Why? Because then we have to put a lot of work in getting the Java ElasticPL interpreter and the xel miner's C based interpreter in sync.

I do not want to decide anything, I am just saying that getting the SN ready is the quicker solution.

If you feel comfortable with going straight to SNs i think go for it. Just wanted to bring up this option in case rudimentary network would be an easy thing to do.
teletobi
Hero Member
*****
Offline Offline

Activity: 734
Merit: 500



View Profile
March 06, 2017, 10:34:11 PM
 #4243


Two stage solution would make sense. First rudimentary network, then SN-network. Gives lots of room for testing and process of thought.

I completely agree...and I would prefer if we took this approach as well.  However, last I heard from EK, he still wanted to move forward with the SN approach for the initial release.

Well, for weeks now we have moved towards the SN approach. I mean, sure, we can stick to the rudimentary network for the start. But imho this will be more complex than going the last remaining meters towards the SN approach. Why? Because then we have to put a lot of work in getting the Java ElasticPL interpreter and the xel miner's C based interpreter in sync.

I do not want to decide anything, I am just saying that getting the SN ready is the quicker solution.

If you feel comfortable with going straight to SNs i think go for it. Just wanted to bring up this option in case rudimentary network would be an easy thing to do.

Take all the time needed to get a good Solution.

Join the Elastic revolution!  Elastic - The Decentralized Supercomputer
ELASTIC WEBSITE | NEW ANNOUNCEMENT THREAD | ELASTIC SLACK | ELASTIC FORUM
wpalczynski
Legendary
*
Offline Offline

Activity: 1456
Merit: 1000



View Profile
March 06, 2017, 11:32:19 PM
 #4244


Two stage solution would make sense. First rudimentary network, then SN-network. Gives lots of room for testing and process of thought.

I completely agree...and I would prefer if we took this approach as well.  However, last I heard from EK, he still wanted to move forward with the SN approach for the initial release.

Well, for weeks now we have moved towards the SN approach. I mean, sure, we can stick to the rudimentary network for the start. But imho this will be more complex than going the last remaining meters towards the SN approach. Why? Because then we have to put a lot of work in getting the Java ElasticPL interpreter and the xel miner's C based interpreter in sync.

I do not want to decide anything, I am just saying that getting the SN ready is the quicker solution.

I'll support upgrading the miner for whichever way we go (which I assume using SNs).  I'm just worn out and tired of reading page after page of posts about how any minute the code would be ready...it really takes the fun out of working on this.

Makes it hard for me to just read this thread never mind for you guys putting work into this.  All these noobs whining and coming across as so demanding and ungrateful despite the seemingly insincere pats on the back associated with each whine and complaint.

Bgjjj2016
Sr. Member
****
Offline Offline

Activity: 448
Merit: 250

Ben2016


View Profile
March 07, 2017, 03:11:29 AM
 #4245


Two stage solution would make sense. First rudimentary network, then SN-network. Gives lots of room for testing and process of thought.

I completely agree...and I would prefer if we took this approach as well.  However, last I heard from EK, he still wanted to move forward with the SN approach for the initial release.

Well, for weeks now we have moved towards the SN approach. I mean, sure, we can stick to the rudimentary network for the start. But imho this will be more complex than going the last remaining meters towards the SN approach. Why? Because then we have to put a lot of work in getting the Java ElasticPL interpreter and the xel miner's C based interpreter in sync.

I do not want to decide anything, I am just saying that getting the SN ready is the quicker solution.
EK, thanks for responding. As little knowledge as I have, I can say with confidence ( I'm sure for others as well) that you have made the right decisions in the past and you should continue doing it going forward. Nothing wrong with being a scientist and a leader the same time. You also have great supporters like Coralreefer, Unvoid, .........and many nontechnical people like me.

My " I want that Old Toyota Camry very bad" BTC Fund :1DQU4oqmZRcKSzg7MjPLMuHrMwnbDdjQRM
Join the Elastic revolution! Elastic Network: The Decentralized Supercomputer 
ELASTIC WEBSITE|ANNOUNCEMENT THREAD|JOIN THE SLACK
mm2543363580
Full Member
***
Offline Offline

Activity: 952
Merit: 105



View Profile
March 07, 2017, 03:50:12 AM
 #4246

It looks like an interesting project, I will watch carefully maybe something unexpected appears.

clivemy
Full Member
***
Offline Offline

Activity: 190
Merit: 100


View Profile
March 07, 2017, 09:22:03 AM
 #4247


Two stage solution would make sense. First rudimentary network, then SN-network. Gives lots of room for testing and process of thought.

I completely agree...and I would prefer if we took this approach as well.  However, last I heard from EK, he still wanted to move forward with the SN approach for the initial release.

Well, for weeks now we have moved towards the SN approach. I mean, sure, we can stick to the rudimentary network for the start. But imho this will be more complex than going the last remaining meters towards the SN approach. Why? Because then we have to put a lot of work in getting the Java ElasticPL interpreter and the xel miner's C based interpreter in sync.

I do not want to decide anything, I am just saying that getting the SN ready is the quicker solution.


So would it be possible for the community to get to vote on whether we wait for a complete version to be released (with SNs, Guardnodes, etc.) or release a 'proof of concept' now?

It would be nice to have a complete list of all the pros and cons involved with releasing now or waiting for a more completed version.

For example:

PROS
A two stage solution would mean that we have a 'proof of concept' model we could release now
We'd have a roadmap (stage 1, stage 2, etc.)
We could begin a PR campaign around that
Attract more developers to help with Stage 2

CONS
More development time required to release a more completed version that has SNs, Guardnodes, etc.
Allows for a more developed model to be released
Less time consuming for the developers in the long run if a completed version is released, rather than releasing in stages
(sorry, I can't think of a 4th reason, but you get the idea).

bitcoinpaul
Hero Member
*****
Offline Offline

Activity: 910
Merit: 1000



View Profile
March 07, 2017, 09:42:38 AM
 #4248

Go for SN
wizzardTim
Legendary
*
Offline Offline

Activity: 1708
Merit: 1000


Reality is stranger than fiction


View Profile
March 07, 2017, 11:32:41 AM
 #4249

I think the approach with SN is better too

Behold the Tangle Mysteries! Dare to know It's truth.

- Excerpt from the IOTA Sacred Texts Vol. I
Bgjjj2016
Sr. Member
****
Offline Offline

Activity: 448
Merit: 250

Ben2016


View Profile
March 07, 2017, 12:12:49 PM
 #4250

Hi EK, Should we ( rest of us here) work on the advertisement, website, signature,.... or should we wait till SN is completely implemented? Thank you !

My " I want that Old Toyota Camry very bad" BTC Fund :1DQU4oqmZRcKSzg7MjPLMuHrMwnbDdjQRM
Join the Elastic revolution! Elastic Network: The Decentralized Supercomputer 
ELASTIC WEBSITE|ANNOUNCEMENT THREAD|JOIN THE SLACK
techwriterjoe
Member
**
Offline Offline

Activity: 95
Merit: 10


View Profile
March 07, 2017, 01:47:39 PM
 #4251

I see the community support for SN. As long as the devs who will be implementing the solution are onboard, then I'm onboard.

Could we share a roadmap? It does not necessarily need dates, yet.

I suggest running an agile type project management style. Perhaps make a larger roadmap, but only give dates for specific goals that can be completed within 2-3 weeks. Choose your sprint cycles 2 or 3 weeks. So only commit to any work for the 2-3 weeks and don't worry about dating the roadmap beyond that.
Mrboot
Legendary
*
Offline Offline

Activity: 1204
Merit: 1000


View Profile
March 07, 2017, 02:15:48 PM
 #4252

I see the community support for SN. As long as the devs who will be implementing the solution are onboard, then I'm onboard.

Could we share a roadmap? It does not necessarily need dates, yet.

I suggest running an agile type project management style. Perhaps make a larger roadmap, but only give dates for specific goals that can be completed within 2-3 weeks. Choose your sprint cycles 2 or 3 weeks. So only commit to any work for the 2-3 weeks and don't worry about dating the roadmap beyond that.

SCRUM FTW
Selsonblue
Hero Member
*****
Offline Offline

Activity: 661
Merit: 500


View Profile
March 07, 2017, 03:53:30 PM
 #4253


I suggest running an agile type project management style. Perhaps make a larger roadmap, but only give dates for specific goals that can be completed within 2-3 weeks. Choose your sprint cycles 2 or 3 weeks. So only commit to any work for the 2-3 weeks and don't worry about dating the roadmap beyond that.

1. Scrum / agile has worked in geographically dispersed dev groups in the past (my experiences) - but there has to be 100% buy in and a good amount of daily communication. - Both of which are probably not going to happen at this late stage of development.

2. We all want to be informed and such. But it wouldnt be worth spending an hour or two to produce a roadmap when there is "not much left" to begin with.

If you want to suggest ways to assist with the project, research use cases, help prioritize the PR campaign or development ideas; you need to bring the discussion to slack and discuss! Clivemy and myself (boardwalk), jibble, coralreefer, bgjjj, and others are in there discussing the PR stuff almost daily. The more the merrier right?

Also, We have publicly available PR and development backlogs created -- Coralreefer (miner software dev.) has given a good amount of detail on what he sees as his next tasks for miner development. These boards are updated as developments take place. Use them as your first source for info.

PR tracking: https://trello.com/b/2efzgZZT/pr-tasks
Development Backlog: https://trello.com/b/fPdyn5Vp/development-backlog

EK is at the point were his time is better spent coding. Trying to write release notes / project updates before he figures the code out is a nearly impossible task. You cant switch to agile / scrum mid way through a development cycle and expect a better outcome.  Patience is a virtue.
techwriterjoe
Member
**
Offline Offline

Activity: 95
Merit: 10


View Profile
March 07, 2017, 05:16:04 PM
 #4254

I see the community support for SN. As long as the devs who will be implementing the solution are onboard, then I'm onboard.

Could we share a roadmap? It does not necessarily need dates, yet.

I suggest running an agile type project management style. Perhaps make a larger roadmap, but only give dates for specific goals that can be completed within 2-3 weeks. Choose your sprint cycles 2 or 3 weeks. So only commit to any work for the 2-3 weeks and don't worry about dating the roadmap beyond that.

SCRUM FTW

I may be interpreting your comment wrong. Scrum is a term borrowed from Rugby with similar meaning. It is simply the daily standup meeting and those involved form the scrum. Scrum and Agile go together. Sometimes those terms are used interchangeably. Agile is the idea of short iterations and sprints. It creates the ability to adapt with agility.

It's very easy to get lost in the idea of continually adding features. I think the devs should commit among themselves, not really on here, that this should be the last really big feature update before release. Of course, this is barring an absolutely necessary feature. The SN feature is somewhat optional but I agree with EK's statement that it should be implemented now because it will cause too much pain to implement with an app that is already in production/maintenance phase.
techwriterjoe
Member
**
Offline Offline

Activity: 95
Merit: 10


View Profile
March 07, 2017, 05:21:12 PM
 #4255


I suggest running an agile type project management style. Perhaps make a larger roadmap, but only give dates for specific goals that can be completed within 2-3 weeks. Choose your sprint cycles 2 or 3 weeks. So only commit to any work for the 2-3 weeks and don't worry about dating the roadmap beyond that.

1. Scrum / agile has worked in geographically dispersed dev groups in the past (my experiences) - but there has to be 100% buy in and a good amount of daily communication. - Both of which are probably not going to happen at this late stage of development.

2. We all want to be informed and such. But it wouldnt be worth spending an hour or two to produce a roadmap when there is "not much left" to begin with.

If you want to suggest ways to assist with the project, research use cases, help prioritize the PR campaign or development ideas; you need to bring the discussion to slack and discuss! Clivemy and myself (boardwalk), jibble, coralreefer, bgjjj, and others are in there discussing the PR stuff almost daily. The more the merrier right?

Also, We have publicly available PR and development backlogs created -- Coralreefer (miner software dev.) has given a good amount of detail on what he sees as his next tasks for miner development. These boards are updated as developments take place. Use them as your first source for info.

PR tracking: https://trello.com/b/2efzgZZT/pr-tasks
Development Backlog: https://trello.com/b/fPdyn5Vp/development-backlog

EK is at the point were his time is better spent coding. Trying to write release notes / project updates before he figures the code out is a nearly impossible task. You cant switch to agile / scrum mid way through a development cycle and expect a better outcome.  Patience is a virtue.

"EK is at the point were his time is better spent coding." completely agree.
wpalczynski
Legendary
*
Offline Offline

Activity: 1456
Merit: 1000



View Profile
March 07, 2017, 11:29:43 PM
 #4256

I see the community support for SN. As long as the devs who will be implementing the solution are onboard, then I'm onboard.

Could we share a roadmap? It does not necessarily need dates, yet.

I suggest running an agile type project management style. Perhaps make a larger roadmap, but only give dates for specific goals that can be completed within 2-3 weeks. Choose your sprint cycles 2 or 3 weeks. So only commit to any work for the 2-3 weeks and don't worry about dating the roadmap beyond that.

GO ahead, please make a roadmap.  Devs are busy coding.

Bgjjj2016
Sr. Member
****
Offline Offline

Activity: 448
Merit: 250

Ben2016


View Profile
March 08, 2017, 02:52:46 AM
 #4257

I see the community support for SN. As long as the devs who will be implementing the solution are onboard, then I'm onboard.

Could we share a roadmap? It does not necessarily need dates, yet.

I suggest running an agile type project management style. Perhaps make a larger roadmap, but only give dates for specific goals that can be completed within 2-3 weeks. Choose your sprint cycles 2 or 3 weeks. So only commit to any work for the 2-3 weeks and don't worry about dating the roadmap beyond that.

GO ahead, please make a roadmap.  Devs are busy coding.
As much as most of us here don't like the word " Roadmap", it could be used constructively as an informative tool for us and attract more people to this project as long as it's not being used for pushing our devs into a time restrain . IMHO

My " I want that Old Toyota Camry very bad" BTC Fund :1DQU4oqmZRcKSzg7MjPLMuHrMwnbDdjQRM
Join the Elastic revolution! Elastic Network: The Decentralized Supercomputer 
ELASTIC WEBSITE|ANNOUNCEMENT THREAD|JOIN THE SLACK
rubiprojects
Sr. Member
****
Offline Offline

Activity: 240
Merit: 250


View Profile
March 08, 2017, 03:45:57 AM
 #4258

Elastic is catching my eyes, very impressive job you have done. I wait for the official launch, for the supercomputer on blockchain revolution.
cybterpunk
Full Member
***
Offline Offline

Activity: 414
Merit: 101


View Profile
March 08, 2017, 09:44:35 AM
 #4259

Elastic is catching my eyes, very impressive job you have done. I wait for the official launch, for the supercomputer on blockchain revolution.

XEL is the real supercomputer.

i will support it.
provenceday
Legendary
*
Offline Offline

Activity: 1148
Merit: 1000



View Profile
March 08, 2017, 10:10:53 AM
 #4260

time will reward people with patience.
Pages: « 1 ... 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 [213] 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 ... 345 »
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!