3 ms·

> "Then you do a Bluetooth transfer, or CIFS/SMB file share, or FTP, or HTTP, or IrDA, or USB, etc. Why would you use a cloud service?" I suppose this is what

by amirmc 13y ago

> "Then you do a Bluetooth transfer, or CIFS/SMB file share, or FTP, or HTTP, or IrDA, or USB, etc. Why would you use a cloud service?" I suppose this is what you say to people who extol the virtues of Dropbox or BitTorrent Sync? It almost sounds like you've completely missed the wave of stuff that's happening, which I find hard to believe (or you're being deliberately obtuse). > "No, these products are still centralized. They are merely made more redundant, fault-tolerant and highly-available." How do you suppose they are made redundant, fault-tolerant and highly-available? I've tried to describe how in my previous comment and you haven't given any counterpoints. > "They may also be distributed, which is different than decentralized." Ok, this made me think as I tend to use the words interchangeably. Some quick Google searching doesn't clarify anything either (I find conflicting versions). Ovearall, I get the feeling that you have a different view of what 'centralised' means but even then, you haven't given any examples of why such things are more reliable or faster, whereas I've tried to do so.

peterwwillis 13y ago
'The wave of stuff that's happening' is not some crazy new paradigm shift. It's remote network services. Why you would use a remote network service when all your files are available locally, I have no idea. People are weird. The easiest way to think of this is in terms of network architecture. A Client-Server model of network architecture is by definition centralized; you have one or more clients, and only one server. The client connects to the server to do whatever it wants. In a decentralized model, the server is any node with the ability to serve the requests of the clients - which often includes other clients. It would take too much time to explain how all of that stuff works, but suffice to say that just because there's more than one computer involved or more than one process involved does not make it a decentralized service. If the client is still just talking to one thing (on the frontend), it's basically centralized. To explain how centralized architecture is faster, consider a simple example where there is one client, and three nodes distributing a file. The client has to first find and identify the nodes, which usually takes more time than just resolving a single server, because it has to "search" for its peer nodes. Then it has to request a file, which is probably split up into pieces and little requests are sent to each node. Each node then sends the client the pieces. The client then reassembles them on its end to create the finished file. Compare this to a server, where from lookup to file transfer, there is one continuous operation; there is no need to communicate with multiple nodes or track multiple connections or piece together files. Also with the distributed model, you are at the mercy of all the nodes in the network, not just one, and all of the different networks those nodes might be on. You also may end up doing 3x the network operations, depending on protocols, chunk sizes, etc. Because you can't bet on the source of the file coming from one reliable place, network latency may go up, and bandwidth may also go down - in practice over the internet this is virtually guaranteed vs a central server's large pipe.

by amirmc 13y ago

peterwwillis 13y ago

'The wave of stuff that's happening' is not some crazy new paradigm shift. It's remote network services. Why you would use a remote network service when all your files are available locally, I have no idea. People are weird. The easiest way to think of this is in terms of network architecture. A Client-Server model of network architecture is by definition centralized; you have one or more clients, and only one server. The client connects to the server to do whatever it wants. In a decentralized model, the server is any node with the ability to serve the requests of the clients - which often includes other clients. It would take too much time to explain how all of that stuff works, but suffice to say that just because there's more than one computer involved or more than one process involved does not make it a decentralized service. If the client is still just talking to one thing (on the frontend), it's basically centralized. To explain how centralized architecture is faster, consider a simple example where there is one client, and three nodes distributing a file. The client has to first find and identify the nodes, which usually takes more time than just resolving a single server, because it has to "search" for its peer nodes. Then it has to request a file, which is probably split up into pieces and little requests are sent to each node. Each node then sends the client the pieces. The client then reassembles them on its end to create the finished file. Compare this to a server, where from lookup to file transfer, there is one continuous operation; there is no need to communicate with multiple nodes or track multiple connections or piece together files. Also with the distributed model, you are at the mercy of all the nodes in the network, not just one, and all of the different networks those nodes might be on. You also may end up doing 3x the network operations, depending on protocols, chunk sizes, etc. Because you can't bet on the source of the file coming from one reliable place, network latency may go up, and bandwidth may also go down - in practice over the internet this is virtually guaranteed vs a central server's large pipe.