3 ms·

Don't require people to change 'source code' to configure your programs

54 points by ingve 3y ago

spintin 3y ago
Unless you can hot-reload it?
- jraph 3y ago
  It's not the point I think (it's not about having to recompile). The point is not having to maintain a fork of the config file.
enriquto 3y ago
Alternative (the suckless way): don't require people to keep stupid 'configuration files', help them edit your program to suit their particular needs.
- jraph 3y ago
  That's completely in the opposite direction of the post. The post argues against forcing users to maintain a fork of the configuration files. You are arguing to help users maintain their own forks of the entire program, basically. While I'm interested in being able to fork the programs I use, and most likely upstreaming the changes, I'm not interested in having to do so to configure them. Configuration files are not stupid and are there for a reason.
  - klez 3y ago
    I'm assuming you're unfamiliar with suckless[0], which GP wasn't using as an adjective, but as the name of a project. There's a philosophy behind that decision, which you (and, in part, I) can disagree with. But they do have their reasons to prefer avoiding configuration files. [0] http://suckless.org/ http://suckless.org/
    - jraph 3y ago
      I am familiar with suckless, but that's useful to mention it explicitly for those here who aren't. Of course I childishly played with the name (but that's their fault picking this name :-)). And of course one can disagree. I like their goal of minimalism and simplicity. I disagree that developer's simplicity should be at the expense of the user's convenience. Computers are already incredibly complex things, and are here to automate things and ease our lives as users. Hopefully a program is written once and used many times, so usage should be optimized, even if it makes the developer's lives a bit harder (I would say interesting :-)). Making software lean and lightweight is part of it (and that's where I agree with suckless), we owe this to our users instead of forcing them to experience slowness and to upgrade their hardware often. Of course that's my view. (I'm a dev)
- Barrin92 3y ago
  That's not an alternative way, that's literally what the post is critiquing. There's nothing stupid about configuration files, on the contrary, it's completely nonsensical and conceptually wrong to have enduser runtime configuration written into compile time source code. It also entirely defeats the ostensible purpose of making "non-bloated" software because it doesn't get much more bloated than having to recompile an entire program every time you want to make a trivial change that could just be read from a file. You've now made having the entire compiler toolchain installed a requirement if someone wants to change a font. It's the equivalent of burning your house down and building a new one because you want to change a poster on the wall. Suckless software is just an exercise in contrarianism.
  - jraph 3y ago
    yep, there's nothing suckless in this, or it's suckless for the devs but not for the users. But even for the devs it kinda sucks in the end.
- lordgrenville 3y ago
  When I read the headline, I thought this was going to be specifically attacking suckless.
- farmdve 3y ago
  I thought most software authors have this particular stance, which of course they are in their right to have, that they are offering free software and thus have no obligation to help anyone with anything, and they can always do it by themselves. In the past I've seen links here on HN where certain OSS authors were pressured into helping, fixing, adding features by users who 'demanded' it and the authors were feeling very bad about all this. It wasn't just one post.
smokel 3y ago
> you're having people modify files that you will also change How is this different from the ever changing nginx configuration files? I think the underlying problem is that various programs use different ways of shipping things. Some include configuration in source code, others require one to read a book to setup a configuration file, others have a database with configuration settings. If it weren't for us humans creating these things, we would probably have settled on a single interface.
- citrin_ru 3y ago
  > How is this different from the ever changing nginx configuration files? Nginx developers don’t change configuration files, they only provide an example config - you can create your own config based on this example but you don’t need to update it if an example will be changed in a later release. Package maintainers in many Linux distributions is another story - they usually want to own nginx.conf and end user only drop files into sites-available/enabled and conf.d. I don’t like this approach but it provides easier start.
  - jraph 3y ago
    On the other end, I've yet to find apt complain that the nginx.conf file from the package was updated, so I guess this is reasonably well handled.
globalnode 3y ago
or just dont use their programs, or write your own!
- enriquto 3y ago
  Hear, hear! ...after all, a program is nothing more than a configuration file for a compiler!
cholindo 3y ago
A bit off topic, but this is why I started using KDE over gnome. I liked to use middle mouse button for drag-move/resize but in gnome it required editing the source code and recompiling.
- berkes 3y ago
  For me, it's the exact opposite. The fact that in KDE, not only can I configure literally every pixel at times, I often must configure all kinds of things. I very much prefer highly opinionated software for three reasons. That softwares' defaults matter everything, so they are well researched and thought out. While with configurable software, defaults are often accidentally, historically, or whimsically defined. Settings combine. One setting of two options gives two variations. Four such settings 16. Now imagine the combinations of a KDE app with a hundred settings, many of which can take several values. It's impossible to support, test, understand and debug all these combinations. Yet they often affect eachother. Updates in KDE were, for this reason alone, a break-fest. But even flipping some check boxes often brought my KDE in an invalid state so that (seemingly unrelated) parts would just stop working. But most importantly, I realized my time is best spend on efficiently using software, rather than spending time on making it work efficiently for my personal workflows. I.e. better to adapt my workflow to some well thought out default, than to waste time thinking out that workflow myself. I still have vim and my shell configured, but that's where I spend almost all my time. For the rest: just vanilla Ubuntu with some nice wallpapers. It has "just worked" for over a decade and many updates now. Which is a much bigger timesaver than configuring the amount of pixels of grab-space of my window borders will ever be.
  - jraph 3y ago
    Have you tried KDE recently? A lot of care has been put in the defaults in KDE (recently?). They have even set double click to open by default in Plasma 6, though most of the team actually prefers single click, recognizing that it's what users coming from other environment are used to. Today, the default configuration in KDE software is well thought and usable as is. You don't need to change anything. But you can if you want. I've used KDE for years now, and when I set up a new environment, I don't change much actually. It's ready to use out of the box. You don't need to choose between "configurable but painful to set up" and "opinionated and non configurable". "Configurable with 'opinionated' defaults" is also an option and to me that's what KDE provides.
jraph 3y ago
The argument is actually broader than what I expected from the title. It's not a matter of having to edit C code or Makefiles, it's a matter of having to edit any file (even a configuration file) that is shipped by the author of the program (or the package) and that can change. Then you are basically expected to maintain a fork. I can't agree more with this. Please make me edit completely empty files to override defaults. Also related, it's painful when APT asks you what to do with an upgraded configuration file, just to notice that upstream edits are just mistake fixes in comments (hello Matrix / Synapse a while ago), or that self-closing XML tags have became totally equivalent but more verbose full, empty tags (WHY?!? Hello Collabora Online). The moves to: - let us expand the configuration in config.d folders - ship default configuration files in system folders, outside /etc, config that you can overrides in /etc are welcome. With the later, you can provide a fully documented default config file, and then I can override it, even commenting why I changed a value and these comments are not mixed with upstream documentation.
- vaylian 3y ago
  > (hello Matrix / Synapse) Synapse also supports using a drop-in directory for configuration
  - jraph 3y ago
    Nice. That was some time ago, it probably improved since then. I edited my post to reflect this.
- duskwuff 3y ago
  Yes. Yes yes yes. Configuration files with standardized contents tend to ossify into an appendage of the application written in what is effectively a domain-specific language. (See sendmail, for instance.)
- Arnavion 3y ago
  There's a nice spec for this by the UAPI group: https://uapi-group.org/specifications/specs/configuration_files_specification/ https://uapi-group.org/specifications/specs/configuration_fi... , with the most common implementation called libeconf. The tl;dr is that an application / OS vendor can ship the default configuration in a path like /usr/etc, some dynamic runtime component can then override it in a path like /run, and a sysadmin can override that in a path like /etc. Each location is searched for a main config file or dropin patches under a `.d` directory or both (depending on the software's choice), and then considered in a defined order - later search directory roots have priority over earlier ones when the filename is the same, and dropins are considered in lexicographical order of filename regardless of which search directory they were found under. That said, it unfortunately doesn't go on to specify local-user overridability via $XDG_CONFIG_HOME etc, which might limit its adoption.
throwitaway222 3y ago
Written _today_ jaw drops.
wolpoli 3y ago
I am not sure if allowing users to override default by editing/adding to a completely empty file is a good solution either. It's rather error prone and easy to, for example, accidentally type field name incorrectly.
- jraph 3y ago
  When you are editing some configuration, you are testing that the change works, so the typo should be spotted at some point, no? You can make your program complain that the field is unknown too. Personally I copy paste everything and type few things anyway, but a way to handle this is to provide an example config file with everything commented out from which you can start. I quite like this way of doing things.
samus 3y ago
The bottom line seems to be that such ad-hoc configuration mechanism should be considered to be part of the public interface, which requires managing backwards compatibility when changes become necessary. Developers usually don't like doing that and are probably only used to do this with function signatures and object structures, not with source code files. Under that lens, it should become obvious how bizarre it is to expect configuration to happen that way. What could an alternative be? First of all, considering user-friendly configuration as a first-class feature and explicitly thinking about the upgrade path. Developing a configuration file format and most importantly having a backwards compatibility policy for that seems the obvious solution.
- jraph 3y ago
  > configuration mechanism should be considered to be part of the public interface, which requires managing backwards compatibility when changes become necessary I'm not sure it's quite related to the fact you shouldn't have to maintain a fork of the configuration, but absolutely agree. As it happens, I deprecated three configuration parameters in a project I work on just yesterday this way [1]. It is enforced by the fact the configuration is defined using a Java class checked by revapi. I just deprecated the related methods, hidden the properties (so they don't appear in UIs), made the setters do nothing and the getters return the most sensible values given the new behavior. [1] https://github.com/xwiki-contrib/confluence/commit/fad5d0c52601008a760f41babd4ba6221c6e357e#diff-afd15c0e7fc621734649298674a3174d9c9554d0be04ce0785d83c794a1504fe https://github.com/xwiki-contrib/confluence/commit/fad5d0c52...
  - samus 3y ago
    The problem still applies even when the user only sees a UI, but in a less explicit way. Power users usually customize a lot of settings that they expect to still find in updated versions. If there is no sane way to export those settings*, then people will remember it or write it down somewhere. *: looking at you, Putty, which stores connection settings in the Windows registry
    - jraph 3y ago
CppPro 3y ago
The best way to make and maintain quality is to gatekeep your creation, so that incompetent people can not "help you".
- jraph 3y ago
  I don't understand your comment, its relation with the article and how it solves the issue at hand. Maybe you gatekept your comment from mediocre HN visitors?
  - CppPro 3y ago
    You have to pay a fee in order to see this answer.
kazinator 3y ago
> The core problem is you're having people modify files that you will also change, for example when you release a new version of your software that has new options that you want people to be able to change or configure. That's a solved problem. You have an "example-config.xyz" file in the distribution that the user must rename to "config.xyz" and customize. The new version of the software clobbers example-config.xyz, not touching config.xyz. If the user also retains the original example-config.xyz in a copy called ORIG-config.xyz, then after the upgrade, they can do a three-way diff.
- jraph 3y ago
  Yep. As an alternative, make your program work with a default set of configurations (that can be in a file shipped with the app) and let the user only specify the changes they want. This way, the tree way diff is not necessary anymore in most cases.
deleted 3y ago
[deleted]
j16sdiz 3y ago
The author is talking about `autoconf` or `./configure`. If I understand correctly, these kind of "config" usually involve external dependency -- like if you don't need x11 support, don't try to link libxcb. I am not sure maintaining a fork would make sense in this case. Maybe a plugin system would do, but that's a non-trivial. Dealing with runtime library dependency is hard.
banish-m4 3y ago
Software and systems configuration management is often misunderstood and under appreciated. Simplicity, maintenance costs, and robustness must be balanced with care.

54 points by ingve 3y ago

spintin 3y ago

Unless you can hot-reload it?

jraph 3y ago
It's not the point I think (it's not about having to recompile). The point is not having to maintain a fork of the config file.

enriquto 3y ago

Alternative (the suckless way): don't require people to keep stupid 'configuration files', help them edit your program to suit their particular needs.

jraph 3y ago
That's completely in the opposite direction of the post. The post argues against forcing users to maintain a fork of the configuration files. You are arguing to help users maintain their own forks of the entire program, basically. While I'm interested in being able to fork the programs I use, and most likely upstreaming the changes, I'm not interested in having to do so to configure them. Configuration files are not stupid and are there for a reason.
- klez 3y ago
  I'm assuming you're unfamiliar with suckless[0], which GP wasn't using as an adjective, but as the name of a project. There's a philosophy behind that decision, which you (and, in part, I) can disagree with. But they do have their reasons to prefer avoiding configuration files. [0] http://suckless.org/ http://suckless.org/
  - jraph 3y ago
    I am familiar with suckless, but that's useful to mention it explicitly for those here who aren't. Of course I childishly played with the name (but that's their fault picking this name :-)). And of course one can disagree. I like their goal of minimalism and simplicity. I disagree that developer's simplicity should be at the expense of the user's convenience. Computers are already incredibly complex things, and are here to automate things and ease our lives as users. Hopefully a program is written once and used many times, so usage should be optimized, even if it makes the developer's lives a bit harder (I would say interesting :-)). Making software lean and lightweight is part of it (and that's where I agree with suckless), we owe this to our users instead of forcing them to experience slowness and to upgrade their hardware often. Of course that's my view. (I'm a dev)
Barrin92 3y ago
That's not an alternative way, that's literally what the post is critiquing. There's nothing stupid about configuration files, on the contrary, it's completely nonsensical and conceptually wrong to have enduser runtime configuration written into compile time source code. It also entirely defeats the ostensible purpose of making "non-bloated" software because it doesn't get much more bloated than having to recompile an entire program every time you want to make a trivial change that could just be read from a file. You've now made having the entire compiler toolchain installed a requirement if someone wants to change a font. It's the equivalent of burning your house down and building a new one because you want to change a poster on the wall. Suckless software is just an exercise in contrarianism.
- jraph 3y ago
  yep, there's nothing suckless in this, or it's suckless for the devs but not for the users. But even for the devs it kinda sucks in the end.
lordgrenville 3y ago
When I read the headline, I thought this was going to be specifically attacking suckless.
farmdve 3y ago
I thought most software authors have this particular stance, which of course they are in their right to have, that they are offering free software and thus have no obligation to help anyone with anything, and they can always do it by themselves. In the past I've seen links here on HN where certain OSS authors were pressured into helping, fixing, adding features by users who 'demanded' it and the authors were feeling very bad about all this. It wasn't just one post.

smokel 3y ago

> you're having people modify files that you will also change How is this different from the ever changing nginx configuration files? I think the underlying problem is that various programs use different ways of shipping things. Some include configuration in source code, others require one to read a book to setup a configuration file, others have a database with configuration settings. If it weren't for us humans creating these things, we would probably have settled on a single interface.

citrin_ru 3y ago
> How is this different from the ever changing nginx configuration files? Nginx developers don’t change configuration files, they only provide an example config - you can create your own config based on this example but you don’t need to update it if an example will be changed in a later release. Package maintainers in many Linux distributions is another story - they usually want to own nginx.conf and end user only drop files into sites-available/enabled and conf.d. I don’t like this approach but it provides easier start.
- jraph 3y ago
  On the other end, I've yet to find apt complain that the nginx.conf file from the package was updated, so I guess this is reasonably well handled.

globalnode 3y ago

or just dont use their programs, or write your own!

enriquto 3y ago
Hear, hear! ...after all, a program is nothing more than a configuration file for a compiler!

cholindo 3y ago

A bit off topic, but this is why I started using KDE over gnome. I liked to use middle mouse button for drag-move/resize but in gnome it required editing the source code and recompiling.

berkes 3y ago
For me, it's the exact opposite. The fact that in KDE, not only can I configure literally every pixel at times, I often must configure all kinds of things. I very much prefer highly opinionated software for three reasons. That softwares' defaults matter everything, so they are well researched and thought out. While with configurable software, defaults are often accidentally, historically, or whimsically defined. Settings combine. One setting of two options gives two variations. Four such settings 16. Now imagine the combinations of a KDE app with a hundred settings, many of which can take several values. It's impossible to support, test, understand and debug all these combinations. Yet they often affect eachother. Updates in KDE were, for this reason alone, a break-fest. But even flipping some check boxes often brought my KDE in an invalid state so that (seemingly unrelated) parts would just stop working. But most importantly, I realized my time is best spend on efficiently using software, rather than spending time on making it work efficiently for my personal workflows. I.e. better to adapt my workflow to some well thought out default, than to waste time thinking out that workflow myself. I still have vim and my shell configured, but that's where I spend almost all my time. For the rest: just vanilla Ubuntu with some nice wallpapers. It has "just worked" for over a decade and many updates now. Which is a much bigger timesaver than configuring the amount of pixels of grab-space of my window borders will ever be.
- jraph 3y ago
  Have you tried KDE recently? A lot of care has been put in the defaults in KDE (recently?). They have even set double click to open by default in Plasma 6, though most of the team actually prefers single click, recognizing that it's what users coming from other environment are used to. Today, the default configuration in KDE software is well thought and usable as is. You don't need to change anything. But you can if you want. I've used KDE for years now, and when I set up a new environment, I don't change much actually. It's ready to use out of the box. You don't need to choose between "configurable but painful to set up" and "opinionated and non configurable". "Configurable with 'opinionated' defaults" is also an option and to me that's what KDE provides.

jraph 3y ago

The argument is actually broader than what I expected from the title. It's not a matter of having to edit C code or Makefiles, it's a matter of having to edit any file (even a configuration file) that is shipped by the author of the program (or the package) and that can change. Then you are basically expected to maintain a fork. I can't agree more with this. Please make me edit completely empty files to override defaults. Also related, it's painful when APT asks you what to do with an upgraded configuration file, just to notice that upstream edits are just mistake fixes in comments (hello Matrix / Synapse a while ago), or that self-closing XML tags have became totally equivalent but more verbose full, empty tags (WHY?!? Hello Collabora Online). The moves to: - let us expand the configuration in config.d folders - ship default configuration files in system folders, outside /etc, config that you can overrides in /etc are welcome. With the later, you can provide a fully documented default config file, and then I can override it, even commenting why I changed a value and these comments are not mixed with upstream documentation.

vaylian 3y ago
> (hello Matrix / Synapse) Synapse also supports using a drop-in directory for configuration
- jraph 3y ago
  Nice. That was some time ago, it probably improved since then. I edited my post to reflect this.
duskwuff 3y ago
Yes. Yes yes yes. Configuration files with standardized contents tend to ossify into an appendage of the application written in what is effectively a domain-specific language. (See sendmail, for instance.)
Arnavion 3y ago
There's a nice spec for this by the UAPI group: https://uapi-group.org/specifications/specs/configuration_files_specification/ https://uapi-group.org/specifications/specs/configuration_fi... , with the most common implementation called libeconf. The tl;dr is that an application / OS vendor can ship the default configuration in a path like /usr/etc, some dynamic runtime component can then override it in a path like /run, and a sysadmin can override that in a path like /etc. Each location is searched for a main config file or dropin patches under a `.d` directory or both (depending on the software's choice), and then considered in a defined order - later search directory roots have priority over earlier ones when the filename is the same, and dropins are considered in lexicographical order of filename regardless of which search directory they were found under. That said, it unfortunately doesn't go on to specify local-user overridability via $XDG_CONFIG_HOME etc, which might limit its adoption.

throwitaway222 3y ago

Written _today_ jaw drops.

wolpoli 3y ago

I am not sure if allowing users to override default by editing/adding to a completely empty file is a good solution either. It's rather error prone and easy to, for example, accidentally type field name incorrectly.

jraph 3y ago
When you are editing some configuration, you are testing that the change works, so the typo should be spotted at some point, no? You can make your program complain that the field is unknown too. Personally I copy paste everything and type few things anyway, but a way to handle this is to provide an example config file with everything commented out from which you can start. I quite like this way of doing things.

samus 3y ago

The bottom line seems to be that such ad-hoc configuration mechanism should be considered to be part of the public interface, which requires managing backwards compatibility when changes become necessary. Developers usually don't like doing that and are probably only used to do this with function signatures and object structures, not with source code files. Under that lens, it should become obvious how bizarre it is to expect configuration to happen that way. What could an alternative be? First of all, considering user-friendly configuration as a first-class feature and explicitly thinking about the upgrade path. Developing a configuration file format and most importantly having a backwards compatibility policy for that seems the obvious solution.

jraph 3y ago
> configuration mechanism should be considered to be part of the public interface, which requires managing backwards compatibility when changes become necessary I'm not sure it's quite related to the fact you shouldn't have to maintain a fork of the configuration, but absolutely agree. As it happens, I deprecated three configuration parameters in a project I work on just yesterday this way [1]. It is enforced by the fact the configuration is defined using a Java class checked by revapi. I just deprecated the related methods, hidden the properties (so they don't appear in UIs), made the setters do nothing and the getters return the most sensible values given the new behavior. [1] https://github.com/xwiki-contrib/confluence/commit/fad5d0c52601008a760f41babd4ba6221c6e357e#diff-afd15c0e7fc621734649298674a3174d9c9554d0be04ce0785d83c794a1504fe https://github.com/xwiki-contrib/confluence/commit/fad5d0c52...
- samus 3y ago
  The problem still applies even when the user only sees a UI, but in a less explicit way. Power users usually customize a lot of settings that they expect to still find in updated versions. If there is no sane way to export those settings*, then people will remember it or write it down somewhere. *: looking at you, Putty, which stores connection settings in the Windows registry
  - jraph 3y ago

CppPro 3y ago

The best way to make and maintain quality is to gatekeep your creation, so that incompetent people can not "help you".

jraph 3y ago
I don't understand your comment, its relation with the article and how it solves the issue at hand. Maybe you gatekept your comment from mediocre HN visitors?
- CppPro 3y ago
  You have to pay a fee in order to see this answer.

kazinator 3y ago

> The core problem is you're having people modify files that you will also change, for example when you release a new version of your software that has new options that you want people to be able to change or configure. That's a solved problem. You have an "example-config.xyz" file in the distribution that the user must rename to "config.xyz" and customize. The new version of the software clobbers example-config.xyz, not touching config.xyz. If the user also retains the original example-config.xyz in a copy called ORIG-config.xyz, then after the upgrade, they can do a three-way diff.

jraph 3y ago
Yep. As an alternative, make your program work with a default set of configurations (that can be in a file shipped with the app) and let the user only specify the changes they want. This way, the tree way diff is not necessary anymore in most cases.

deleted 3y ago

[deleted]

j16sdiz 3y ago

The author is talking about `autoconf` or `./configure`. If I understand correctly, these kind of "config" usually involve external dependency -- like if you don't need x11 support, don't try to link libxcb. I am not sure maintaining a fork would make sense in this case. Maybe a plugin system would do, but that's a non-trivial. Dealing with runtime library dependency is hard.

banish-m4 3y ago

Software and systems configuration management is often misunderstood and under appreciated. Simplicity, maintenance costs, and robustness must be balanced with care.