Syncthing – a continuous file synchronization program • Hacker News Board

Re: Syncthing – a continuous file synchronization program

#141

Post by Normal_gaussian » Thu, Oct 14, 2021, 12:36 PM UTC

marcellus23 wrote: post #132

Normal_gaussian wrote: post #112

Earlier quoted context omitted.

You can't publish your own competing app. The desired behaviour requires running a background service (not allowed) that watches arbitrary folders (not allowed).

I think you lost the plot - you can publish a competing app that uses the Files app for sync, just like NextCloud does.

That is a somewhat combative thing to say.

We see a NextCloud dev explaining that background uploads don't work herehttps://github.com/nextcloud/ios/issues/215

And we can see syncthing devs lamenting the many issues with an iOS client here https://github.com/syncthing/syncthing/issues/102

It may be the case that file eventing now works, but a quick check with an iOS dev friend suggests that the filesystem sandboxing is too restrictive to be meaningful anyway.

Further on this issue, consider that a functioning syncthing client is a node in a p2p network, so must be able to advertise and listen to requests in the background as well as the background jobs that NextCloud requires (as NextCloud is centralised it doesn't need node level co-ordination) - so a partially working NextCloud client is good enough, but a partially working Syncthing client is woefully broken.

Re: Syncthing – a continuous file synchronization program

#142

Post by BrandoElFollito » Thu, Oct 14, 2021, 12:40 PM UTC

j1elo wrote: post #123

deaddabe wrote: post #21

I have switched from Nextcloud to Syncthing. The former was a resource hog that was eating up too much everything on my modest VPS. I share the files on my local network at home between phone, laptop and desktop. My only issues so far: - I need to manually start Syncthing on the devices, whereas Nextcloud was always running on boot. Not sure if I should start it every time, especially on the Android phone which canno…

> [Nextcloud] was a resource hog that was eating up too much everything on my modest VPS. I've seen comments like this in multiple occasions. Is it really that bad? I guess if there was a flagrant performance bug, it would have been sorted out with time, so the only remaining explanation is that the code is really poorly laid out, or with design flaws that cause so many performance problems for users. However next to…

I tried both and stayed with Nextcloud because of some features (especially sharing and specifically private links).

I have a ~5 years old server (Intel Skylake, 8 GB RAM) on which I run a bunch od docker containers (about 30). One of them is Nextcloud and the load average is 0.8-1.0. This is for an average of 2 users (me and the rest of my family that in total uses the server as I do myself).

Not a very scientific comparison, but I never had any performance issues.

Re: Syncthing – a continuous file synchronization program

#143

Post by fps_doug » Thu, Oct 14, 2021, 12:40 PM UTC

rkagerer wrote: post #118

Glad to see another option out there for file sync. Browsing the FAQ I noticed: To further limit the amount of CPU used when syncing and scanning, set the environment variable GOMAXPROCS to the maximum number of CPU cores Syncthing should use Are they using an environment variable shared by other Go programs? Seems like bad practice... why aren't they using a variable or or switch that's unique to Syncthing instead?

> Are they using an environment variable shared by other Go prpgrams? Seems like bad practice...

Huh? So only set it for syncthing.

Re: Syncthing – a continuous file synchronization program

#144

Post by uhtred » Thu, Oct 14, 2021, 12:42 PM UTC

deaddabe wrote: post #21

I have switched from Nextcloud to Syncthing. The former was a resource hog that was eating up too much everything on my modest VPS. I share the files on my local network at home between phone, laptop and desktop. My only issues so far: - I need to manually start Syncthing on the devices, whereas Nextcloud was always running on boot. Not sure if I should start it every time, especially on the Android phone which canno…

If you just need to access your NAS from outside your home network so your phone can syncthing to it, you can use syncthing in global mode -- it will use public relay servers to sync between phone and NAS. But maybe you need more than that / knew this already.

Re: Syncthing – a continuous file synchronization program

#145

Post by dolni » Thu, Oct 14, 2021, 12:46 PM UTC

bipson wrote: post #131

Reventlov wrote: post #12

Earlier quoted context omitted.

I would not qualify the web UI of "excellent" : understanding the relations between paired devices, remote devices, folders you want to sync, and so on is harder than what it should be. Likewise, the android application is so bad the best way is to open the web UI on your phone to do stuff (and sometimes, it's the only way to achieve some goals). There is definitely a lot of room for improvement for easier adoption,…

The first thing I really like about syncthing is that it does what it is supposed to do very well (besides very seldom glitches), while not being dropbox, nextcloud, owncloud, etc. but p2p and entirely independent of any external tools/devices/etc. The second thing I like is that it is a successful FOSS project, meaning it works and is being regularly and often improved by its users. Your comment, as helpful as you m…

> and by god, if a better solution is so obvious to you, why haven't you proposed it yet, or - god forbid - made a merge/pull request??

Because there isn't any obligation to? Why do you think you would be entitled to ask for that?

Re: Syncthing – a continuous file synchronization program

#146

Post by hparadiz » Thu, Oct 14, 2021, 12:51 PM UTC

j1elo wrote: post #138

hparadiz wrote: post #124

Earlier quoted context omitted.

It's also kind of arrogant of FOSS advocates to say "just make a pull request" whenever there's criticism of anything FOSS. You could spend weeks working on something only to have the maintainer say no and I've seen this happen and every time it does I just think to myself "welp there's another person who will never make another pull request again".

As a FOSS maintainer I always try to make it clear that before trying your luck with a PR, you should always first engange in a conversation with me. Seems kind of obvious to my eyes, asking, talking, discussing about some change before doing the actual work. But as it seems, "obviousness" is in the eye of the beholder...

That's fine and all except that the typical refrain from internet folks is that if something is free then you are not allowed to critique, comment, or request changes. If you really care about freedom you can handle a little bit of online banter.

Re: Syncthing – a continuous file synchronization program

#147

Post by MikusR » Thu, Oct 14, 2021, 12:55 PM UTC

miki123211 wrote: post #136

I have to pitch Resilio Sync (formerly Bittorrent Sync) here. It's a proprietary, more polished alternative that offers a freeware license for personal use. My biggest issue with Syncthing was that there was no auto-discovery, if you had 25 or so computers across a group of friends, you needed to set up 25^2 connections, which wasn't really feasible. Not sure if this is still a thing, but Resilio solves this perfectl…

Syncthing has been end-to-end encrypted for years. And now also supports encrypted at rest.

Re: Syncthing – a continuous file synchronization program

#148

Post by alexktz » Thu, Oct 14, 2021, 12:56 PM UTC

miki123211 wrote: post #136

I have to pitch Resilio Sync (formerly Bittorrent Sync) here. It's a proprietary, more polished alternative that offers a freeware license for personal use. My biggest issue with Syncthing was that there was no auto-discovery, if you had 25 or so computers across a group of friends, you needed to set up 25^2 connections, which wasn't really feasible. Not sure if this is still a thing, but Resilio solves this perfectl…

+1 for Resilio Sync. Purchased a license 7 years ago and it still works today - how refreshing is that?

Lots of people love Syncthing and that is great for them, but I've always found btsync to be easier to use.

Re: Syncthing – a continuous file synchronization program

#149

Post by rglullis » Thu, Oct 14, 2021, 1:00 PM UTC

8fingerlouie wrote: post #108

rglullis wrote: post #106

Earlier quoted context omitted.

Yes, of course. Syncthing is not a backup solution. Luckily the amount of data that I have that is considered private and valuable is not that much (~100GB of family photos and videos, some scanned documents) so my backup strategy has been good old SneakerNet. I have a couple of thumb drives that I leave with family, and occasionally get them back to check/refresh.

I keep my data in the cloud, a local (versioned) backup, and for irreplaceable data like photos, i also burn identical M-disc media at least every year. One stored at home, another in a remote location. While i will probably have worse problems to deal with in case the cloud disappears and my local data is gone as well, chances are that once those are solved, my family photos will not be a problem after those :)

I think for me the original comment was not just about the data, it was also about "what if the cloud disappears".

Financially, it might make sense to pay MS a few bucks an year for a service. Philosophically, the idea is much harder to stomach.

I am far from being a card-carrying member of /r/datahoarder, but I don't like the idea of supporting (much less depending on) streaming services, and I would pay for a subscription service if it was based on open source.

Re: Syncthing – a continuous file synchronization program

#150

Post by rkagerer » Thu, Oct 14, 2021, 1:02 PM UTC

hparadiz wrote: post #126

rkagerer wrote: post #118

Glad to see another option out there for file sync. Browsing the FAQ I noticed: To further limit the amount of CPU used when syncing and scanning, set the environment variable GOMAXPROCS to the maximum number of CPU cores Syncthing should use Are they using an environment variable shared by other Go programs? Seems like bad practice... why aren't they using a variable or or switch that's unique to Syncthing instead?

It's a GO runtime setting. Has nothing to do with Syncthing.

I'm not a Go programmer, but couldn't they achieve the same thing without name collision by reading a custom environment variable at startup and setting runtime.GOMAXPROCS?