We really REALLY wanted to like Syncthing, but much as it offers the option to move away from BitTorrent’s growing parasitic ways, ST is simply not ready for the common user. It is convoluted to setup and establish syncs and to use in general. We have had continuous problems and found the ST site’s local documentation wanting. So…
If anyone knows of 2nd / 3rd party documentation and tutorials, please share. We will not give up yet but will also not recommend it to our audience (self-publishers and other authors) for an on the fly third or fourth tier backup system.
If the onsite documentation doesn’t suit you, you might want to look at this detailed video tutorial that was independently released on YouTube approx. 6 months ago.
It’s more than 40 minutes long, but it covers all the basic setup details in a methodical, graphic manner.
After you get Syncthing working, you are most welcome to participate in improving / editing the docs - so others may benefit from what you have learned. Unlike BTSync, this is a not-for-profit project - if you give back, everyone in the community is enriched.
If you do get it sorted, it would be much appreciated if you can provide some pointers on how to fix up the documentation so it works better for the next person in the same situation.
If we can, Jakob. The first step will be to see if video-to-text instruction (1) is possible and (2) renders something useable by non-geeks. Video sucks for tutorials and is aimed primarily at lookiloos who will never need a further reference back to legitimate documentation.
If all this is so, we will likely do a little article to inform our audience and get them off of BitTorrent Sync. This discussion page has also be “pinned” in some staff browsers (mostly Chromium) so we can share notice back here if all works out.
I also have a strong preference against video tutorials. It is difficult to control the speed of the information and hard to find the one random piece of information you need. And they are usually useless for the blind, unlike plain text. Finally, they are so much worse than text for people with limited data internet connections.
Not everything in that tutorial was applicable to my particular situation, but it helped me get comfortable enough to figure out the rest on my own. It is mostly oriented towards a technically adept audience, but since you seem to be doing the legwork for your organization, it may be worth your effort to try to understand the parts about setting up Syncthing through the graphic interface.
And I have to echo what NickPyz said: this is a community open-source project. Anyone can improve the documentation, including you!
Finally, this is sort of an unrelated nit-pick, but I have to say it: Syncthing, Dropbox, BTSync, etc are NOT backup systems. Please don’t rely on them for backups. That is just asking for tears. Regardless of what “tier” they are.
Thanks, Ifam! Any references are helpful in the long run. And while we agree with you in general that clouding / synching should not be use for a primary backup, our approach for authors to protect in-process projects includes three tiers, the last of which is sync/cloud based.
That is how our operation’s owners (Barb and J.C. Hendee) have been working for 16 years as full-time authors. They have run the gambit of almost all possibilities in backup structures for intellectual properties. The use of cloud and/or sync is not yes or no, but inbetween in the details.
The “fourth” tier is of course burning the backup to permanent media, such as a DVD/CD, upon completion of an individual project. All previous projects remain in the backup scheme so that they are re-burned as well against DVD/CD degradation. Just so you know where in the scheme of things that we seek to place Syncthing.
bettez, that sounds inviting (in all senses of the word). How do we proceed with this variation? Should a new topic be started?
ADDENDUM: We have now looked over the documentation referenced as well as the video tutorials. At this point, we will pause, for neither of these address the primary concern.
We have both tech-savvy and novice users at NDAS where such procedures are concerned. Our readership of authors fall in the latter category almost exclusively. While we greatly appreciate how much more secure and autonomous is Syncthing’s function, it is not ready for prime time (as initially judged) for the common user as compared to BitTorrent Sync. Sad considering how parasitic and profiteering BT has become in recent times.
We will continue to explore it on our own, but an extended approach to creating documentation will not solve the problem that ST itself is not even half as friendly and easy to use as BTS. It has a long way to go in that category. Very long.
Yes, if you can give any specific feedback, we’d love to hear it. I’m not a Syncthing developer but I’m sure they all would like to see Syncthing become very easy to use.
I think the OP is pretty clear that the problem is not just lacking docs but that for their purposes the user experience is too convoluted and just won’t fly. Which is perfectly valid and something we should try to address, in time.
Finally someone is actually listening. And the rest should be listening to Jakob (calmh), since they are not listening to us. It is time to start taking the “geek” out of working with Syncthing, or no one but “geeks” will use it.
And as Jakob said, a new location for documentation is not an answer. Content and not access is the secondary problem with instructions; the primary problem is that there is no simple setup for the user in leaving higher levels of complexity, customizing, and (yes) increased security for later.
The later is the area where uses will leave ST and run back to BTS… regardless they they will get more out of SC. “More” that you cannot do easily and conveniently is more of nothing.
This conversation lacks the specifics necessary to resolve anything. The 1st step of systematic problem solving is to clearly state the problem and it’s effects. That step is missing in this thread:
(1) First we were told that the documentation was lacking, however no detailed example was offered up - other than a broad-brush generalization. How can we improve the docs if a dissatisfied customer won’t point to at least 1 specific deficiency; and is reluctant to participate in the improvement process?
(2) Later we were told that the problem wasn’t just the docs, but it was with the complexity and geekiness of the product itself. Once again, a generalized statement, no specifics.
I am not a geek. I invested a very modest amount of my time learning how to use Syncthing. The RETURN ON INVESTMENT has been rewarding for me and also for those colleagues with whom I sync data.
I agree that there are opportunities to improve this project - just look at the active user forums and Issue Tracker. Users are interested in bug fixes, in new features, better UX, and in simplification. In almost every case, the originator provides specific problem details or a detailed innovation idea - and is an active participant in finishing what they initiated.
That’s the spirit we need to advance Syncthing.
NDAS - please stop repeating the “run back to BTSync” threat. It isn’t going to expedite your issues - which unfortunately remain too vague to be acted upon. Also, don’t discount the listening skills of the community. There are great listeners here, many will actually go to work for YOU and deliver real results - but only after you provide something specific to work on … and pending your commitment to becoming a team player.
(I will step down off my orange crate now - speech is OVER).
“The 1st step of systematic problem solving is to clearly state the problem and it’s effects.”
Yes, correct, though it was shortly later determined that our perception of the problem was not fully correct; we thought improved documentation and or alternative sources might shed light on something we were missing. That turned out to be wrong as well.
The problem is Sycnthing and not its documentation per se. Until the use of ST after first install is streamlined for common users, no amount of work on documentation will solve the problem.
“…just look at the active user forums and Issue Tracker.”
We have. Mention of some similar perspectives as ours (as of now) have been cover by others in some different ways. Nothing has changed adequately. We will watch that area, but we feel deep involvement would not (yet) be fruitful. Most development outside of squashing bugs has leaned to additional features, which is not what this is about.
“…please stop repeating the “run back to BTSync” threat”
It is not a threat; you chose to perceive it that way. It is a statement of fact. Upon install, BTS allows a user to (1) select a target for sync, (2) select a mode of two-way or one-way, and (3) generate the “secret” code to distribute / use at other locations to initialize the sync. All other options and refinements can be applied before or after such initialization and thereby do not complicate the baseline process.
Until ST can do the same, BTS will be what the average user will prefer by comparison. If you know of other applications we should look at that use the Tor network for encrypted cloud-less syncing between points anywhere on the planet, then do share. We are still running BTS now locally and globally as a third or fourth tier backup (depending on sync content type), though its growing commercially based limitations are a concern.
“(I will step down off my orange crate now - speech is OVER).”
[Smile] Never give up the crate. Keep it handy for when necessary.
I’m philosophically opposed to this mode of operation. It requires secure and private communication between the parties, and it removes the choice of allowing or disallowing the relationship from the source (i.e. the secret can leak).
That said, a more user friendly one-time-code kind of thing has been discussed and could work, but no one has put in the effort to fully design it yet.
We understand the concern, Jakob, and even agree with it. A “one-time” code would be a step in the right direction, but as you said, nothing is happening.
Another approach might be to have the code generated be dependent upon the “generator” and the “recipient” both being established and known. Not fully secure in all ways, but an inch in the right direction. However, we have no one here with the capability to suggest “how.”