3 ms·
grpc reads some configuration from environment; environment has portability problems too, so it's useful to set it to cross platform shape.
by GoblinSlayer 2y ago
grpc reads some configuration from environment; environment has portability problems too, so it's useful to set it to cross platform shape.
- fch42 2y agoThe "cross platform" way of setting the environment is to set it "from outside" of the program - meaning, through the executor, whether that's the shell or the container runtime or even the kernel commandline if you insist to rewrite init in rust/go/zig/... It can be as-easy-as spawning your process via "env -i VAR1=... ... myprogram ..." - and given this also clears the dangers of env-insertion exploits, it's good practice. (the argument that the horses have long bolted with respect to "just do the right think ok?!" here holds some water. I'm of the generation though where people on the internet could still tell each other they were wrong, and I assert that here; you're wrong if you believe a non-threadsafe unix interface is a bug. No matter what kind of restrictions around its use that means. You're still wrong if you assume the existence of such restrictions is a bug)
- gpderetta 2y agoAt the limit a program can execve itself with the new env.
- fch42 2y agoIndeed, and from my point of view, that's perfectly ok.
- GoblinSlayer 2y agoIt's not cross platform. Does java provide such interface?
- hinkley 2y agoSome of the docker containers I made ended up having a bash shell as the entry point and I moved most of the environment variable init out of the code and into the script. But in dev sandbox some of that code runs without the script, so it was still a headache.