3 ms·

I'm confused; you object with my use of decentralized, but then argue (it seems) that distributed also does not fit the bill. So.. I think we have a fundamenta

I'm confused; you object with my use of decentralized, but then argue (it seems) that distributed also does not fit the bill. So.. I think we have a fundamental failure in communication here. It's difficult to discuss decentralization or distributed designs when, well, we can't even refer to the platforms that advertise themselves as such. Ie, I did not make this terminology. The platform we're discussing literally advertises itself as such in this title. I'm not sure what's even being discussed anymore.

pdonis 7y ago
I'm not trying to "discuss decentralized or distributed designs". I'm trying to get somebody to explain to me why I should prefer something like dgit to GitHub on the basis of it being "decentralized". So far the answers I've gotten are: (A) It's decentralized! Woohoo! (I'm paraphrasing.) Which tells me nothing about why "decentralized" is better than GitHub. (B) It's distributed! Woohoo! (Again, I'm paraphrasing.) Which, again, tells me nothing about why "distributed" is better than GitHub. Not to mention that "distributed" is not the same thing as "decentralized", so if I'm supposed to prefer something like dgit because it's "distributed", the goal posts have been moved. (C) If GitHub goes down, you can automatically switch to pushing to <other place>. Which amounts to "this solution has better failover than GitHub", which, as I noted, (a) might or might not be true (I'd want to see your uptime numbers), and (b) has nothing whatever to do with <other place> being "decentralized" or "distributed" since "decentralized" has nothing to do with failover reliability, and GitHub is just as "distributed" as <other place>. (D) You can keep all the "non-git components" in <other place> along with the git repo. Which might be an advantage if it's easier to get them from <other place> than from GitHub, but, again, has nothing to do with <other place> being "decentralized" or "distributed", it just has to do with how accessible <other place> makes the "non-git components" as compared with GitHub. Is there an (E)?
- asdkhadsj 7y ago
  I feel like your arguments are being disingenuous. All I can think of to summarize it on is for the same reasons I might want to host a file on IPFS, I may also want to use my central Git repo (the one my team pushes to) on something like IPFS. Yes, I could host my file on Github. However I think it's well beyond my patience to argue for why IPFS(/sia/etc) should exist, in this conversation. If you see no reason why someone would want to host anything on IPFS/sia/etc over Dropbox or Github, I'm not the person to change your mind. This discussion merely spawned because I thought I had an idea on what the hell Dgit even is. I didn't write it, have never used it, and know next to nothing about it. Merely, I had envisioned a use case for my team using Git on IPFS, and mentioned that in these comments.

pdonis 7y ago

I'm not trying to "discuss decentralized or distributed designs". I'm trying to get somebody to explain to me why I should prefer something like dgit to GitHub on the basis of it being "decentralized". So far the answers I've gotten are: (A) It's decentralized! Woohoo! (I'm paraphrasing.) Which tells me nothing about why "decentralized" is better than GitHub. (B) It's distributed! Woohoo! (Again, I'm paraphrasing.) Which, again, tells me nothing about why "distributed" is better than GitHub. Not to mention that "distributed" is not the same thing as "decentralized", so if I'm supposed to prefer something like dgit because it's "distributed", the goal posts have been moved. (C) If GitHub goes down, you can automatically switch to pushing to <other place>. Which amounts to "this solution has better failover than GitHub", which, as I noted, (a) might or might not be true (I'd want to see your uptime numbers), and (b) has nothing whatever to do with <other place> being "decentralized" or "distributed" since "decentralized" has nothing to do with failover reliability, and GitHub is just as "distributed" as <other place>. (D) You can keep all the "non-git components" in <other place> along with the git repo. Which might be an advantage if it's easier to get them from <other place> than from GitHub, but, again, has nothing to do with <other place> being "decentralized" or "distributed", it just has to do with how accessible <other place> makes the "non-git components" as compared with GitHub. Is there an (E)?

asdkhadsj 7y ago
I feel like your arguments are being disingenuous. All I can think of to summarize it on is for the same reasons I might want to host a file on IPFS, I may also want to use my central Git repo (the one my team pushes to) on something like IPFS. Yes, I could host my file on Github. However I think it's well beyond my patience to argue for why IPFS(/sia/etc) should exist, in this conversation. If you see no reason why someone would want to host anything on IPFS/sia/etc over Dropbox or Github, I'm not the person to change your mind. This discussion merely spawned because I thought I had an idea on what the hell Dgit even is. I didn't write it, have never used it, and know next to nothing about it. Merely, I had envisioned a use case for my team using Git on IPFS, and mentioned that in these comments.