3 ms·

It's a funny idea of sucking less where any user configuration involves editing config.h and recompiling.

by Freaky 11y ago

falcolas 11y ago
Which is easier? Re-running make, or having to write and induce another library to read configuration files? Configuration files introduce a new point of failure (file not present, file corrupted, file not readable), a point of slowdown (how long does it take to read the file from disk, how long does it take to parse and load the file), and a point of complexity (parsing even ini files is pretty complicated, if you want to support the myriad of ways we write them). All of this for values which change once every... how long? Once a year? Once an install? Or for most configuration values, never? I still use configuration files, because I'm OK with including third party libraries... but I can certainly understand why some people may not be.
- mondoshawan 11y ago
  Parsing config files is not hard. A simple key-value flat file is often more than enough. You don't need external libs for it, but it does add additional complexity. Suckless is about minimalism and speed, and if you want speed, you don't want extra junk like config files clogging up your code's mainline.
- Freaky 11y ago
  > Which is easier? Re-running make, or having to write and induce another library to read configuration files? It's certainly easier for the programmer to just leave some of the work to the compiler, but it's at the cost of being a complete pain in the ass to packagers and users. Do you even have to do much work yourself? .Xresources is already parsed and loaded for you by xrdb if you can't afford the cost of an extra 100 microseconds doing it yourself. Is the API to interact with that mindblowing horrid or something? > All of this for values which change once every... how long? When I'm configuring software to taste, several times a minute. And considering this is likely to be my first exposure to the software, it better not suck completely.
adrusi 11y ago
As a big fan of suckless software I can agree. While I understand the reasoning behind it, that configuration files are awful and introduce needless dependencies and make it too easy to leave a design decision up to the user as a config option rather than just picking the right choice for them, having to recompile software is a problem. The biggest issue is package management. I maintain local forks of some AUR packages for st and surf (the suckless terminal and web browser). It was a lot more work to set up than the single command that installing software should be, and I don't get automatic updates. But if suckless maybe takes their fight against bloat too far, it's only because hardly anyone else seems to care at all.

It's a funny idea of sucking less where any user configuration involves editing config.h and recompiling.

by Freaky 11y ago

It's a funny idea of sucking less where any user configuration involves editing config.h and recompiling.

Which is easier? Re-running make, or having to write and induce another library to read configuration files? Configuration files introduce a new point of failure (file not present, file corrupted, file not readable), a point of slowdown (how long does it take to read the file from disk, how long does it take to parse and load the file), and a point of complexity (parsing even ini files is pretty complicated, if you want to support the myriad of ways we write them). All of this for values which change once every... how long? Once a year? Once an install? Or for most configuration values, never? I still use configuration files, because I'm OK with including third party libraries... but I can certainly understand why some people may not be.

mondoshawan 11y ago
Parsing config files is not hard. A simple key-value flat file is often more than enough. You don't need external libs for it, but it does add additional complexity. Suckless is about minimalism and speed, and if you want speed, you don't want extra junk like config files clogging up your code's mainline.
Freaky 11y ago
> Which is easier? Re-running make, or having to write and induce another library to read configuration files? It's certainly easier for the programmer to just leave some of the work to the compiler, but it's at the cost of being a complete pain in the ass to packagers and users. Do you even have to do much work yourself? .Xresources is already parsed and loaded for you by xrdb if you can't afford the cost of an extra 100 microseconds doing it yourself. Is the API to interact with that mindblowing horrid or something? > All of this for values which change once every... how long? When I'm configuring software to taste, several times a minute. And considering this is likely to be my first exposure to the software, it better not suck completely.

adrusi 11y ago

As a big fan of suckless software I can agree. While I understand the reasoning behind it, that configuration files are awful and introduce needless dependencies and make it too easy to leave a design decision up to the user as a config option rather than just picking the right choice for them, having to recompile software is a problem. The biggest issue is package management. I maintain local forks of some AUR packages for st and surf (the suckless terminal and web browser). It was a lot more work to set up than the single command that installing software should be, and I don't get automatic updates. But if suckless maybe takes their fight against bloat too far, it's only because hardly anyone else seems to care at all.