Pulse is either a rebranding or a fork of Syncthing. I'm not quite sure yet.
I just implemented Syncthing on a cluster of front-end web servers. I know best practice would be using hooks to make all my web servers update from a Git repository, but I prefer to do dev on one server and then just update one production server when I go live. Syncthing simply replicates the right directories to the rest of the front-end servers.
I have 8 static asset web servers that run on low-end VPS's with just 256 megs of memory. Syncthing only consumes about 15 megs of that precious memory, leaving plenty for Nginx.
Syncthing is competing with BTSync. BTSync has the disadvantage of being a closed-source product, but it's far easier to setup and configure. Syncthing will take a bit of configuration to get everything just right. It also comes as a plain binary without a native way to make it a system daemon. You have to come up with your own init.d, move config files to a shared directory, set the right permissions on that config file directory, etc.
BTSync is also a lot easier when it comes to adding shared folders. With their system, you share a folder on one computer and receive a key and a secret. On other computers, you simply pick an empty folder, enter the key and secret, and then everything synchronizes.
With SyncThing, you have to configure the relationship on all sides of the connection. When you start setting up a big mesh of dozens of machines, this gets very very tedious and you find yourself just picking one machine to be the "master" and pointing each machine to that one master. This has the downside of not being able to source pieces of the replication from all of the various servers.
The recently added "introducer" feature allows you to establish trust relationships between all nodes which have access to a common repository on a node automatically.
Tag your "central" server as an introducer on all of the other node configs, and they will all add each other (assuming they have any repositories in common). This really aids in this use case.
One of BTSync's advantages is that it's a lot faster (since it uses "only" 128-bit keys) and (being a C++ program instead of something written in Golang, possibly also using more compact datastructures) that it consumes a lot less memory.
It appears to be a valid rebranding of the project from the developers, who are interested in extending their desire somehow to a privacy-centered phone OS? Seems like quite a big pivot.
I keep hearing that Syncthing (Pulse) is just like BTSync, except you set it up manually, and that the developers don't have any plans to add peer discovery.
But peer discovery is the whole point of BTSync. Sure, Syncthing/Pulse is an improvement over rsync, but only an incremental one. BTSync, with its peer discovery, is a radical improvement.
Even having a roadmap for peer discovery would make me a lot more interested in it. As it is, no thanks, I have better things to do than maintain N^2 configuration problems.
There is a global syncthing discovery service. Nodes can locate each other by ID using that service. The code for that server is open source and you can run your own on your own network. Individual nodes on the same subnet can discover each other without the discover service.
You do need to know the node ID and repository ID, and the nodes both need to establish that relationship. But the mutual acceptance of the node ID is how trust is established so I don't see how that could be made optional. They could allow for UI improvements where the user is prompted to add a repository that has been published from another node rather than requiring that to be manually added, but that's just a ui change.
I haven't used btsync so I'm unclear on what specifically is missing on syncthing in this respect. It seems to be pretty good with respect to discovery.
BTSync is a radical improvement in the network protocols but I still can't get the btsync web ui to change my password. You could say that their priorities are in the right place for an open source project, which they are not.
Don't get me wrong, I love the concept and most of the implementation of btsync. But they are holding themselves back, leaving an opportunity for projects like Pulse.
That said, Pulse is dead in the water without peer-discovery. How do I connect to a peer with Pulse if there is no central server?
I'm a bit worried that, as far as I see, the Syncthing protocol doesn't really allow having servers/peers that don't see plain-text. (Since I think it mostly just uses TLS to keep things secret from eavesdroppers.) I've always been looking for an open source Dropbox-like that allows having storage that only sees ciphertext (despite the fact that it would require a little key management from the user, which I think is a usability challenge, but one that can be overcome).
BitTorrent Sync has functionality for generating "encrypted secrets" using the developer API. It is possible to deliver a secret key to a peer which only allows for that peer to access encrypted versions of the folder content.
That's such a non-descript name, I don't think this is a good move. Syncthing is great, it's a thing to sync things. Dropbox, the box where you drop files into. BTSync uses BT to sync things. Pulse? Uhm, maybe it's something about heartbeats or social media analysis?
Recently set up Syncthing on Raspberry Pi, N900 and Win7 laptop for the 'perfect' synchronised notes (mainly notes, anyway) system. Can also report low enough resource usage to be useful on these systems. The phone battery life is not significantly affected and the Pi continues to play media, run Tmux and perform backups without hesitation.
Memory use is consistently under 15 MB and CPU use in the low single % figures. I am only syncing my notes, for the most part, but it fits the bill perfectly.
Excited to see where the project goes from here, having just read about the Indie team's phone project in Linux Voice recently.
[+] [-] deftnerd|11 years ago|reply
I just implemented Syncthing on a cluster of front-end web servers. I know best practice would be using hooks to make all my web servers update from a Git repository, but I prefer to do dev on one server and then just update one production server when I go live. Syncthing simply replicates the right directories to the rest of the front-end servers.
I have 8 static asset web servers that run on low-end VPS's with just 256 megs of memory. Syncthing only consumes about 15 megs of that precious memory, leaving plenty for Nginx.
Syncthing is competing with BTSync. BTSync has the disadvantage of being a closed-source product, but it's far easier to setup and configure. Syncthing will take a bit of configuration to get everything just right. It also comes as a plain binary without a native way to make it a system daemon. You have to come up with your own init.d, move config files to a shared directory, set the right permissions on that config file directory, etc.
BTSync is also a lot easier when it comes to adding shared folders. With their system, you share a folder on one computer and receive a key and a secret. On other computers, you simply pick an empty folder, enter the key and secret, and then everything synchronizes.
With SyncThing, you have to configure the relationship on all sides of the connection. When you start setting up a big mesh of dozens of machines, this gets very very tedious and you find yourself just picking one machine to be the "master" and pointing each machine to that one master. This has the downside of not being able to source pieces of the replication from all of the various servers.
[+] [-] finnn|11 years ago|reply
>Syncthing is becoming Ind.ie Pulse
would indicate it's a rebranding, but I see no evidence on the Syncthing side of things that this is the case
[+] [-] Nux|11 years ago|reply
In my case git hooks would not have worked as each web server generates content that needs to be available on all of them afterwards.
I hope they're going to do well and get it to work smoother.
[+] [-] JeremyNT|11 years ago|reply
Tag your "central" server as an introducer on all of the other node configs, and they will all add each other (assuming they have any repositories in common). This really aids in this use case.
[+] [-] teacup50|11 years ago|reply
Bummer.
[+] [-] ferongr|11 years ago|reply
[+] [-] deftnerd|11 years ago|reply
It appears to be a valid rebranding of the project from the developers, who are interested in extending their desire somehow to a privacy-centered phone OS? Seems like quite a big pivot.
[+] [-] quadrangle|11 years ago|reply
[+] [-] marco1|11 years ago|reply
With that team, they want to create free versions of Dropbox (Indie Pulse), Android/iOS (Indie Phone), Facebook (Heartbeat)?
Love the idea and intentions, so I hope they get good support on their open-source projects.
[1] https://ind.ie/team/
[+] [-] neolefty|11 years ago|reply
But peer discovery is the whole point of BTSync. Sure, Syncthing/Pulse is an improvement over rsync, but only an incremental one. BTSync, with its peer discovery, is a radical improvement.
Even having a roadmap for peer discovery would make me a lot more interested in it. As it is, no thanks, I have better things to do than maintain N^2 configuration problems.
[+] [-] JeremyNT|11 years ago|reply
You do need to know the node ID and repository ID, and the nodes both need to establish that relationship. But the mutual acceptance of the node ID is how trust is established so I don't see how that could be made optional. They could allow for UI improvements where the user is prompted to add a repository that has been published from another node rather than requiring that to be manually added, but that's just a ui change.
I haven't used btsync so I'm unclear on what specifically is missing on syncthing in this respect. It seems to be pretty good with respect to discovery.
[+] [-] mieses|11 years ago|reply
[+] [-] baran1|11 years ago|reply
[+] [-] dochtman|11 years ago|reply
[+] [-] rich90usa|11 years ago|reply
[+] [-] balu_|11 years ago|reply
[+] [-] abritishguy|11 years ago|reply
[+] [-] aw3c2|11 years ago|reply
[+] [-] luxpir|11 years ago|reply
Memory use is consistently under 15 MB and CPU use in the low single % figures. I am only syncing my notes, for the most part, but it fits the bill perfectly.
Excited to see where the project goes from here, having just read about the Indie team's phone project in Linux Voice recently.