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.
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.
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.
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.
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.
> 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.
> 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.
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.
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.
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.
I ditched it entirely during the KDE 3 fiasco.
Been on Gnome/Ubuntu ever since.
But I have tried it now and again, and found that while it's much better than KDE 3, it's still a poor experience out of the box, for me. Or at least, Kubuntu is. It's OK, but not "Good".
For me, the tell-tale is that when my immediate thought is "hmm, maybe I can configure this", something is not right (for me). With Gnome, sometimes I have this (e.g. Gnome Console which has IMO insane default window sizes).
Personally, I think this should never be a setting. Just Good defaults, maybe through heuristics (last size after resize? fullscreen? x% of screen size?).
With KDE I have this all the time. Literally every app that I opened, be it the PDF reader, or the document Scanner, do I immediately go "Something feels off, maybe I must change some settings?" and the answer almost always is in those settings.
I'm not demanding. On contrary, I prefer others with more expertise (of console sizes, PDF displaying, Scanner UI) to make decisions for me, so that I can focus on what I do best instead.
I understand that there's a need for highly configurable software. That my preference of getting force-fed strong opinions is not for everyone. I really do. But I'm using KDE here as an example of what "configuritis" can lead to.
Which KDE 3 fiasco? Are you thinking of the first releases of KDE 4 which were buggy?
It appears to me it's not the fact that KDE is configurable that you dislike, but the design and default configuration choices or the bugs. Or its differences with what you are used to.
I 100% agree with you that the desktop environment should come with good defaults and you shouldn't need to mess with the settings. Life is too short for pointless configuration.
But you are not actually pointing to anything specific so it would be hard to discuss in details or (dis)agree. Not that it's actually an issue, of course. But we can't take any particular insight from your comments other than "this person doesn't like KDE for some reason". If you pointed us at some actual dumb defaults that you shouldn't need to configure but need to, we could actually get your point. The only example you gave is for Gnome, actually. I don't remember struggling with the terminal size on Gnome but then again, I pretty much always maximize all my windows or put them on a side of the screen with a keyboard shortcut, and use tabs so I don't actually create a new terminal window too often.
The problem with GNOME "researched and thought-out opinions" is that they often require all apps to follow it to work well. They ignore use cases involving non-GNOME apps (case in point - systray), but using only GNOME apps is extremely limited.
I used GNOME as my main IDE since v2.4 (2003), but slowly grew frustrated with the changes until the v40 was a bit too much and finally gave KDE a chance (after several previous tries which did not convince me). KDE was finally mature and stable, it took maybe 30 minutes to configure it to my liking - I don't think I had to change the config since then.
> The fact that in KDE, not only can I configure literally every pixel at times, I often must configure all kinds of things.
Neither of those things are true when it comes to KDE. While it is more configurable than GNOME, it's not a particularly high bar to pass, and it comes with perfectly usable and reasonable defaults out-of-the-box.
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.
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.)
There's a nice spec for this by the UAPI group: 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.
I think it is matter of contract between author and users. Some authors just do not provide services like "background compatibility".
"Shipping" requires a lot of work, and some people just refuse to do that. Some of my popular programs are just repos on Github. To use them you have to run build script and execute from source code.
It elimites people who would require a lot of support, and would not give a meaningful contribution. Less work for me...
And if you desperately need my software, I always provide consulting...
I fail to see what is won by not providing clear, simple, standardised installation instructions in a README.
I make a habit of providing these for myself and they are great, both when I enter a new domain and need to remind myself of best practice, and when I return to a domain after a long time.
The lack of such instructions is a strong indicator to me that a project hasn’t reached maturity.
The downside of this is that if the author changes a configuration key, you configuration will probably be invalid (thus refusing to come back online), or worse, ignored and the warning buried in systemd logs.
At least if the maintainers version and your version require review, you have a fighting chance to update the configuration with your customizations, without downtime or unexpected behavior.
You can't rely on this stuff if you want to avoid downtime.
If you want to avoid downtimes, you need to read changelogs and plan upgrades, and maybe test the upgrades before upgrading the production, in any case.
That works for an enterprise or business. When you are doing this stuff for fun and/or hobby, being halted during the upgrade is a MUCH better UX than deleting all my data or whatever undefined thing might happen.
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.
> 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.
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
Yep, that's something Firefox manages the right way I think (in about:config).
Each setting can be in different state:
- default value
- explicitly set to something
As such, parameters set to the default can (and should) be changed in further upgrades, explicitly changed values should be kept, unless they don't make sense anymore.
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.
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.
> 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.
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.
Software and systems configuration management is often misunderstood and under appreciated. Simplicity, maintenance costs, and robustness must be balanced with care.
48 comments
[ 2.7 ms ] story [ 106 ms ] threadWhile 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.
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/
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)
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.
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.
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.
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.
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.
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.
I ditched it entirely during the KDE 3 fiasco. Been on Gnome/Ubuntu ever since.
But I have tried it now and again, and found that while it's much better than KDE 3, it's still a poor experience out of the box, for me. Or at least, Kubuntu is. It's OK, but not "Good".
For me, the tell-tale is that when my immediate thought is "hmm, maybe I can configure this", something is not right (for me). With Gnome, sometimes I have this (e.g. Gnome Console which has IMO insane default window sizes). Personally, I think this should never be a setting. Just Good defaults, maybe through heuristics (last size after resize? fullscreen? x% of screen size?). With KDE I have this all the time. Literally every app that I opened, be it the PDF reader, or the document Scanner, do I immediately go "Something feels off, maybe I must change some settings?" and the answer almost always is in those settings.
I'm not demanding. On contrary, I prefer others with more expertise (of console sizes, PDF displaying, Scanner UI) to make decisions for me, so that I can focus on what I do best instead.
I understand that there's a need for highly configurable software. That my preference of getting force-fed strong opinions is not for everyone. I really do. But I'm using KDE here as an example of what "configuritis" can lead to.
It appears to me it's not the fact that KDE is configurable that you dislike, but the design and default configuration choices or the bugs. Or its differences with what you are used to.
I 100% agree with you that the desktop environment should come with good defaults and you shouldn't need to mess with the settings. Life is too short for pointless configuration.
But you are not actually pointing to anything specific so it would be hard to discuss in details or (dis)agree. Not that it's actually an issue, of course. But we can't take any particular insight from your comments other than "this person doesn't like KDE for some reason". If you pointed us at some actual dumb defaults that you shouldn't need to configure but need to, we could actually get your point. The only example you gave is for Gnome, actually. I don't remember struggling with the terminal size on Gnome but then again, I pretty much always maximize all my windows or put them on a side of the screen with a keyboard shortcut, and use tabs so I don't actually create a new terminal window too often.
I used GNOME as my main IDE since v2.4 (2003), but slowly grew frustrated with the changes until the v40 was a bit too much and finally gave KDE a chance (after several previous tries which did not convince me). KDE was finally mature and stable, it took maybe 30 minutes to configure it to my liking - I don't think I had to change the config since then.
Neither of those things are true when it comes to KDE. While it is more configurable than GNOME, it's not a particularly high bar to pass, and it comes with perfectly usable and reasonable defaults out-of-the-box.
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.
Synapse also supports using a drop-in directory for configuration
That said, it unfortunately doesn't go on to specify local-user overridability via $XDG_CONFIG_HOME etc, which might limit its adoption.
"Shipping" requires a lot of work, and some people just refuse to do that. Some of my popular programs are just repos on Github. To use them you have to run build script and execute from source code.
It elimites people who would require a lot of support, and would not give a meaningful contribution. Less work for me...
And if you desperately need my software, I always provide consulting...
I make a habit of providing these for myself and they are great, both when I enter a new domain and need to remind myself of best practice, and when I return to a domain after a long time.
The lack of such instructions is a strong indicator to me that a project hasn’t reached maturity.
At least if the maintainers version and your version require review, you have a fighting chance to update the configuration with your customizations, without downtime or unexpected behavior.
If you want to avoid downtimes, you need to read changelogs and plan upgrades, and maybe test the upgrades before upgrading the production, in any case.
But you have a point, and maybe a solution to this issue ought to be found.
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.
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/fad5d0c52...
*: looking at you, Putty, which stores connection settings in the Windows registry
Each setting can be in different state:
- default value
- explicitly set to something
As such, parameters set to the default can (and should) be changed in further upgrades, explicitly changed values should be kept, unless they don't make sense anymore.
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.
Maybe you gatekept your comment from mediocre HN visitors?
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.
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.