Skip Navigation

InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)SP
Posts
1
Comments
171
Joined
2 yr. ago

  • Oh forgot to add that the last case that you mentioned, where multiple users sharing a PC, and keeping the folder in sync with all, is not straightforward. This needs another always-on (server like) device.

    At least in Windows each user gets a different Syncthing ID. So if you sync the file with an always-on device, the other user can get the update when they come online from that.

  • Here one crucial element that needs to be highlighted is Syncthing is decentralised by design. I mean it is different from a server-client way of thinking. It is very much like how git stores content, if you are familiar with it.

    For example, let us say I have 5 devices and there is a folder I want in all my devices kept in sync. Since there is no server, to propagate updates made in one device (let us call it Source Device) to other devices, it has to happen either directly, or indirectly. Here I'm assuming all 5 devices are configured to communicate with each other directly.

    Whenever one of the other 4 devices (Device 1) becomes 'online' at the same time as of Source Device, the sync will happen. This is the direct way. The indirect one is, let us say after the sync happened between Source Device and Device 1, the Source Device goes 'offline', but the Device 1 continues to be 'online', now if Device 2 comes online, the change will be propagated from Device 1 to Device 2.

    Note that the assumption, one device configired with all other devices is not the case, propagation of change has to take a path that similar to indirect way, even if all the devices are simultaneously online.

    This configuration, where each device is configured to communicate with all other, is a pain to maintain, since Syncthing is not designed like a publish-subscribe model. What people usually do is, an always-on device (usually a server) is used as one of the devices that need to be kept in sync. Again, this is not a client server model, but each device is a 'node', and the always-on device is also just another node.

    As you already experienced, it is very easy to get sync conflicts, if a folder is shared between multiple users, because of this decentralised design. In my opinion Syncthing works best for a single user. My use cases are, syncing my notes between pc and mobile, sync files scanned with the mobile to my pc, etc.

    If your case is more focused on multiple users, WebDAV server can be an option. But again it's not straight forward and may not cover all use cases. Depending on what you are trying to achieve, a tool more suitable might be available. For example, if the aim is collaborative development there is Iroh (Still in early stages of development)

    I hope this helps.

  • Well this thread clearly established that I neither have technical knowledge and I don't pay attention to spelling...

    Jokes aside this is a good explanation. I have seen admins using vSphere and it kind of makes sense. I'm just starting to scratch the surface of homelab, and now started out with a raspberry pie. My dream is a full fledged self sustaining homelab.

  • TBH I felt this is something they made up once it got more attention. If they had felt remorse, they might have come back to apologise or correct their mistake, sometime in the past two weeks I guess.

    Who knows maybe they are really ill. Maybe they just made everything up.

  • Even though I don't completely support what the other person said, the defense you are making here is dangerous. It's not gatekeeping or anything like elitism, which is the argument of the other person. I don't see the point of arguing with them regarding it.

    So here you said 'biting more than you can chew'. The fundamental problem I see here, which is something people say about Linux also, is that the entry barrier is pretty high. Most of the time it stems from lack of easy to access documentation in the case of Linux. But when it comes to some specific projects, the documentation is incomplete. Many of the self hostable applications suffer from this.

    People should be able to learn their way to chew bigger things. That is how one can improve. Most people won't enjoy a steep learning curve. Documentation helps to ease this steepness. Along with that I completely agree with the fact that many people who figure out things, won't share or contribute into the documentation.

    My point is in such scenarios, I think we should encourage people to contribute into the project, instead of saying there are easier ways to do it. Then only an open source project can grow.

  • I have been using something very similar to this. In my team I insisted on people without any git experience working on a separate local branch, than the feature branch

    . To ensure screw ups are minimal, we pull and create a local feature branch and then a new local only dummy branch, on top of it. Once the team is more comfortable with git, I am planning to treat the local feature branch as a dummy branch.

    So far things have been pretty neat. Spaghetti is no more with minimal conflicts.

  • I don't use Fennec. But mull.

    I hope you know about 'Clear Cache', and this issue is not that. If you haven't done that you can do a simple search to find steps.

    If the clear cache did not solve the issue, the only way is backing up only relevant data. It looks like Fennec does support sync. In that case you can login using a mozilla account, and choose what to sync. Once all your stuff is synced with another device, its safe to do whatever you want.

  • If tailscale will suite your need, but facing amy limitations on free plan, an alternative is Innernet https://github.com/tonarino/innernet

    Obviously not as user friendly as tailscale and you have to work things out in the command line, just posting as an alternative. That's all.