5 ms·

Environment variables are a gigantic, decades-old hack that nobody should be using... but instead everyone has rejected file-based configuration management and

Environment variables are a gigantic, decades-old hack that nobody should be using... but instead everyone has rejected file-based configuration management and everyone is abusing environment variables to inject config into "immutable" docker containers...

GoblinSlayer 2y ago
Everything already supports environment variables, and everyone and their dog have their own favorite yaml-based configuration management.
- fch42 2y ago
  That (managing the env "from the outside) is and always has been the "supposed" way of using it. Modifying _your own_ environment _at runtime_ is not. The corresponding functions - setenv/getenv - and state - envp/environ - have in the UNIX standards "always" (since threads exist, really) been marked non-MT. "way back when" people were happy to accept that stated restrictions on use don't make bugs. Today, general sense of overentitlement makes (some) people say "but since whatever-trickery can remove this restriction... you're wrong and I'm entitled to my bugfix". I agree the damage is done, though.
Sharlin 2y ago
It's funny how any hack, no matter how big, somehow becomes a commonplace everyday "solution" once it's needed to work around some quirk of whatever technology is fashionable at the time.
deleted 2y ago
[deleted]
secondcoming 2y ago
We use env vars on cloud machines to hold various metadata information about the machines. They can be queried by any program and is extremely useful. It's too useful to be considered a hack. People just misuse them.
acuozzo 2y ago
> instead everyone has rejected file-based configuration management With good reason. Files are surprisingly hard: https://danluu.com/deconstruct-files/ https://danluu.com/deconstruct-files/
- nyrikki 2y ago
  Rejecting one hard problem and replacing it with another method that is officially documented to be worse isn't really a solution. Note the standard: https://pubs.opengroup.org/onlinepubs/009604499/functions/setenv.html https://pubs.opengroup.org/onlinepubs/009604499/functions/se... > The setenv() function need not be reentrant. A function that is not required to be reentrant is not required to be thread-safe. With the increased use of PIE, thunks for both security and due to ARM + the difference between glibc and musl, plus busybox and you have a huge mess. I would encourage you to play around with ghidra, just to see what return oriented programming and ARM limits does. Compilers have been good at hiding those changes from us, but the non-reentrant nature will cause you issues even without threads. Hint, these thunks can get inserted in the MI lowering stage or in the linker. But setenv() is owned by posix, with only getenv() being differed to cppr. Perhaps someone could submit a proposal on how to make it reentrant to the Open Group. But it wasn't really intended for maintaining mutable state so it may be a hard sell.
  - acuozzo 2y ago
    > replacing it with another method that is officially documented to be worse isn't really a solution Agreed, 150%. My comment had more to do with rejecting files than it did with embracing environ as a suitable alternative. SQLite is likely the most trouble-free option at the moment. With that being said, it would be nice to see Android's sys/system_properties.h ported to GNU/Linux proper and, from there, other Unixen. > I would encourage you to play around with ghidra, just to see what return oriented programming and ARM limits does. Having worked professionally in reverse engineering at DoD, I can assure you that this is something I'm intimately familiar with. Files and environ are bad.
- lamontcg 2y ago
  That applies mostly to databases using the filesystem. For configuration files, the write-fsync-move strategy works fine. Generally you don't need fsync, since most people don't use the file system settings that allow data writes to be reordered with the metadata rename.

GoblinSlayer 2y ago

Everything already supports environment variables, and everyone and their dog have their own favorite yaml-based configuration management.

fch42 2y ago
That (managing the env "from the outside) is and always has been the "supposed" way of using it. Modifying _your own_ environment _at runtime_ is not. The corresponding functions - setenv/getenv - and state - envp/environ - have in the UNIX standards "always" (since threads exist, really) been marked non-MT. "way back when" people were happy to accept that stated restrictions on use don't make bugs. Today, general sense of overentitlement makes (some) people say "but since whatever-trickery can remove this restriction... you're wrong and I'm entitled to my bugfix". I agree the damage is done, though.

Sharlin 2y ago

It's funny how any hack, no matter how big, somehow becomes a commonplace everyday "solution" once it's needed to work around some quirk of whatever technology is fashionable at the time.

deleted 2y ago

[deleted]

secondcoming 2y ago

We use env vars on cloud machines to hold various metadata information about the machines. They can be queried by any program and is extremely useful. It's too useful to be considered a hack. People just misuse them.

acuozzo 2y ago

> instead everyone has rejected file-based configuration management With good reason. Files are surprisingly hard: https://danluu.com/deconstruct-files/ https://danluu.com/deconstruct-files/

nyrikki 2y ago
Rejecting one hard problem and replacing it with another method that is officially documented to be worse isn't really a solution. Note the standard: https://pubs.opengroup.org/onlinepubs/009604499/functions/setenv.html https://pubs.opengroup.org/onlinepubs/009604499/functions/se... > The setenv() function need not be reentrant. A function that is not required to be reentrant is not required to be thread-safe. With the increased use of PIE, thunks for both security and due to ARM + the difference between glibc and musl, plus busybox and you have a huge mess. I would encourage you to play around with ghidra, just to see what return oriented programming and ARM limits does. Compilers have been good at hiding those changes from us, but the non-reentrant nature will cause you issues even without threads. Hint, these thunks can get inserted in the MI lowering stage or in the linker. But setenv() is owned by posix, with only getenv() being differed to cppr. Perhaps someone could submit a proposal on how to make it reentrant to the Open Group. But it wasn't really intended for maintaining mutable state so it may be a hard sell.
- acuozzo 2y ago
  > replacing it with another method that is officially documented to be worse isn't really a solution Agreed, 150%. My comment had more to do with rejecting files than it did with embracing environ as a suitable alternative. SQLite is likely the most trouble-free option at the moment. With that being said, it would be nice to see Android's sys/system_properties.h ported to GNU/Linux proper and, from there, other Unixen. > I would encourage you to play around with ghidra, just to see what return oriented programming and ARM limits does. Having worked professionally in reverse engineering at DoD, I can assure you that this is something I'm intimately familiar with. Files and environ are bad.
lamontcg 2y ago
That applies mostly to databases using the filesystem. For configuration files, the write-fsync-move strategy works fine. Generally you don't need fsync, since most people don't use the file system settings that allow data writes to be reordered with the metadata rename.