Hacker News Reader

Comment by joaomsa | Hacker News Reader

Really dislike software with configuration baked into the code, every key binding and experiment requires recompilation which prevents managing it sanely through a package manager.

I get the appeal of "minimal" in this case, but it just doesn't work for me.

View on HN

I understand that it isn't a nice idea having code and configuration mixed together and that splitting them would be preferable. However, howm takes less than 1 second to compile on my laptop, once you have a configuration that you like you'll rarely change it and I feel that having the configuration in code makes it easier for hackers to find subtle new ways of customising howm.

A downside that I can see to using a header file for configuration is that a compile is required for installation and configuration. I don't see this as being too much of an issue as I don't plan on making howm available as a binary, so a compiler would be required anyway.

I think we can all agree that once a good setup is found, you don't change it that much; recompiling is ok as long as it's fast.

The point of GP is that since config.h is part of the standard distribution, any local modification should be overwritten (or discarded) upon updating the software, or the user has to maintain a local "fork" with his custom config.h.

You should get inspiration from what suckless does [0]. It uses the same idea of config through header, and the "solution" is workable for all involved parties.

[0] http://dwm.suckless.org/customisation/

The benefits of this model include less attack surface area and much leaner code resulting in less bugs. It doesn't fit every project, but the "configuration" code for this WM would likely be larger than the WM itself.

Yep, definitely the sort of thing that belongs in a dotfile.

Though that's very understandable I have to disagree. I've been using dwm and st for years now with nothing but love for both of them.

I'm another advocate for dwm and st. Compiling dwm takes seconds (it is a small codebase) and keeps configuration out of the core.

Compile time never trumps best practice.

It's not "we need to keep compile time down to seconds, therefore configure in the source"; it's "compile time is seconds (if that), so there's not much difference between configuring in the source and configuring in a file except complexity". One part of the motivation for the best practice you cite is that compiling can be complicated and take a long time, and configuration changes should be quick. This is a solid argument against that portion of the motivation. Following practices because they are known as best practices when the motivations for those practices don't apply has another name - cargo culting.

Edited to add: Which is not to say that this best practice should be simply discarded, but to say that the appropriate response is to point to the other motivations for it and determine whether they are more important than the upsides of configuring in the source.

That's not the whole story:

> Because dwm is customized through editing its source code, it’s pointless to make binary packages of it. This keeps its userbase small and elitist. No novices asking stupid questions. There are some distributions that provide binary packages though.

source: http://dwm.suckless.org/

I think I explicitly stated that I was not covering the whole story. The above would be another consideration - with both pros and cons (of which suckless, of course, stresses the pros) - which should be factored in. There are others as well.

This is kind of a default approach for minimal WMs (probably inspired by DWM).

Do you consider an 85 megabyte configuration parser to be minimal?

Reply on news.ycombinator.com