4 ms·

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

> 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.

> 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.