Live data from Hacker News

Syncthing – a continuous file synchronization program

syncthing.net

231–233 of 233 posts

Re: Syncthing – a continuous file synchronization program

#231
post #30

Syncthing is great, but bear in mind in the default configuration (unless you set STNOUPGRADE=1) it will automatically download a replacement binary and exec it, granting the developer remote code execution on your machine at any time, Solarwinds-style. https://news.ycombinator.com/item?id=27933308 No-interaction autoupdate really should be opt-in. It's super dangerous software otherwise. Anyone with release credenti…

Not on Debian though.

Is this something to worry about if installing via the package manager of a different distribution?

Re: Syncthing – a continuous file synchronization program

#232
post #202

Earlier quoted context omitted.

If you would use that variable, you wouldn't set it globally. You would set it only for the syncthing process. For example, when you use systemd to run syncthing, you can configure the environment for syncthing in the unit file. Other Go programs on your machine won't be affected.

I wonder if my annoyance stems from a difference between Windows vs. Linux conventions? I hark back to when environment variables were set globally on a machine (back in DOS days). I realize NTVDM emulation introduced the ability to configure more granular ones (eg. system vs. user) and you can now create a shortcut[1] that launches an intermediate step which tailors the environment for a single process. But always v…

> What happens if someone's creating a script that will shell out simultaneously to multiple Go programs? Do they all inherit the parent's environment variables?

By default, every process inherits the environment of its parent process. So if you set an environment variable (eg. with the EXPORT command in bash), then every process you launch from the shell will have the same value for the environment variable.

However, you can set environment variables for each command that you execute.

So for example in a shell script you could do something like this:

    # set the environment variables value to 4
    # valid for all subsequently executed commands
    export GOMAXPROCS=4
    
    # run syncthing but limit it to 2 processors
    # defining the variable like this it will only affect this command
    GOMAXPROCS=2 /usr/local/bin/syncthing

    # run some other go program
    # the environment var will be set to the value 4 again
    /usr/local/bin/other-go-program
The beauty of using environment variables is that they are much more flexible than command line options.

For example, assume I execute a script from someone else, who did not set GOMAXPROCS. Then I could just set the GOMAXPROCS variable and then execute the script. I could change the config without needing to edit the script!

Re: Syncthing – a continuous file synchronization program

#233

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.

Easy on Linux, not so much (and messier) on Windows.
Post reply on HN