why syncthing should solve problems that you’ve induced on yourself
don’t think we should duplicate normal OS functionality to enable running on systems with an incomplete OS. That way lies madness.
Sure, it’s madness… MADNESS to want to run Syncthing on a linux-based NAS. How crazy to have whole directories on your home LAN’s network storage solution automagically and securely synchronize with other devices. </sarcasm>
Treating it as though I’m trying to pawn off personal problems on you is dismissive of a usage case that, if you take a step back, I think you’d admit is pretty compelling. It’s not MY problem, it’s just A problem. You wrote the software, but it’s the people who use it that define the usage cases. It’s not the cases which you (you personally) think of when you write it that make software great, but the ones you didn’t think of when you wrote it that it ends up being perfect for.
TBH, Syncthing is such a great fit for this environment, I’m surprised you didn’t think of it. Syncthing is, otherwise, just perfect for embedded platforms. It seems that you have reduced its reliance on the OS on purpose. It is statically linked, can automatically upgrade, doesn’t use syslog or any other system-based logging resources (leaving that up to the invoker to sort out), and its built-in web UI requires nothing from the system it is on. It is already divorced from almost all OS support requirements, obviously by design. That’s a really great design and it makes it eminently suitable for embedded devices. It already detects when being run as root, and the time it would take to implement this change is less than than the time taken to discuss it.
There’s also a technical issue that due to limitations with the Go threading model
I would be happy to make the changes and submit the patch.
Anyway, enough said. I’ve made my case. If you’re still against it, it’s your software to decide the direction of. I don’t have the time or inclination to fork() it (hah, get it) nor is this issue important enough to warrant that.