3 ms·

This article (And most notably its title) uses a narrow view of programs, how they're interacted with, and storage models. Should your car's ECUs do this? Your

This article (And most notably its title) uses a narrow view of programs, how they're interacted with, and storage models. Should your car's ECUs do this? Your washing machine? A GUI program? What should they output if storage is the last page of flash memory? What if it uses 2 pages? If it's offboard, should it report the device ID? If it's a GUI, should it have a button that displays this? Would an import/export feature meet the intent?

cafeinux 3y ago
I find the author's intent and meaning to be rather straightforward to understand: he's a Unix sysadmin, so I think it's understandable that he's speaking about programs executed on a Unix-like system that a sysadmin is likely to administrate. So no, nor a washing machine nor a car ECU is expected to do this (not until sysadmins are paid to administrate them at least). As for technicians that might need to configure one someday, those people are usually expected to already know where to look, or at least to be able to read their documentation correctly. And anyway, car ECUs and washing machine usually provide a UI for configuration and don't rely on config files as a primary mode of configuration. As for GUI programs, if they use a human readable config file under the hood, or if they accept a config file as input (some let the user change some simple settings through their UI but uses a config file to change more advanced settings), yes they should have a way to show where it is (either through a command, or through the settings UI for example). I don't really know what you are talking about with the pages of a flash memory... Since in Unix, everything is a file, it will be read through a file anyway, not directly through pages. Same thing for offboard: just display the path to the file, wherever it might physically be. And if you really are in the most rare and hypothetical scenario where your program reads its config directly from the pages of a flash memory, just have it display "The config is read from the last [two] page[s] of <this flash memory> when invoqued with --help.
- the__alchemist 3y ago
  The article makes sense in this context, and after a reread, the hint is identification of background in the first sentence. I misunderstood due to the title of "Everything that uses configuration files should report where they're located",and lines "if a program uses a configuration file (or several), it should have an obvious command line way to find out where it expects to find that configuration file.", and use of "program" in general. Specifically, "program" in this case refers to "CLI program that runs on Linux, used by the IT field".

cafeinux 3y ago

I find the author's intent and meaning to be rather straightforward to understand: he's a Unix sysadmin, so I think it's understandable that he's speaking about programs executed on a Unix-like system that a sysadmin is likely to administrate. So no, nor a washing machine nor a car ECU is expected to do this (not until sysadmins are paid to administrate them at least). As for technicians that might need to configure one someday, those people are usually expected to already know where to look, or at least to be able to read their documentation correctly. And anyway, car ECUs and washing machine usually provide a UI for configuration and don't rely on config files as a primary mode of configuration. As for GUI programs, if they use a human readable config file under the hood, or if they accept a config file as input (some let the user change some simple settings through their UI but uses a config file to change more advanced settings), yes they should have a way to show where it is (either through a command, or through the settings UI for example). I don't really know what you are talking about with the pages of a flash memory... Since in Unix, everything is a file, it will be read through a file anyway, not directly through pages. Same thing for offboard: just display the path to the file, wherever it might physically be. And if you really are in the most rare and hypothetical scenario where your program reads its config directly from the pages of a flash memory, just have it display "The config is read from the last [two] page[s] of <this flash memory> when invoqued with --help.

the__alchemist 3y ago
The article makes sense in this context, and after a reread, the hint is identification of background in the first sentence. I misunderstood due to the title of "Everything that uses configuration files should report where they're located",and lines "if a program uses a configuration file (or several), it should have an obvious command line way to find out where it expects to find that configuration file.", and use of "program" in general. Specifically, "program" in this case refers to "CLI program that runs on Linux, used by the IT field".