4 ms·

Really dislike software with configuration baked into the code, every key binding and experiment requires recompilation which prevents managing it sanely throug

by joaomsa 12y ago

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.

blux 12y ago
This is kind of a default approach for minimal WMs (probably inspired by DWM).
- keenerd 12y ago
  Do you consider an 85 megabyte configuration parser to be minimal?
Zikes 12y ago
Yep, definitely the sort of thing that belongs in a dotfile.
amackera 12y ago
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.
shapeshed 12y ago
I'm another advocate for dwm and st. Compiling dwm takes seconds (it is a small codebase) and keeps configuration out of the core.
- icantthinkofone 12y ago
  Compile time never trumps best practice.
  - dllthomas 12y ago
    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.
    - johnchristopher 12y ago
      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/ http://dwm.suckless.org/
      - dllthomas 12y ago
        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.
hunt 12y ago
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.
- rakoo 12y ago
  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/ http://dwm.suckless.org/customisation/
doki_pen 12y ago
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.

by joaomsa 12y ago

blux 12y ago

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

keenerd 12y ago
Do you consider an 85 megabyte configuration parser to be minimal?

Zikes 12y ago

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

amackera 12y ago

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.

shapeshed 12y ago

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

icantthinkofone 12y ago
Compile time never trumps best practice.
- dllthomas 12y ago
  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.
  - johnchristopher 12y ago
    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/ http://dwm.suckless.org/
    - dllthomas 12y ago
      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.

hunt 12y ago

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.

rakoo 12y ago
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/ http://dwm.suckless.org/customisation/

doki_pen 12y ago

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.