I want to make a massive disclaimer that I use Suckless software and enjoy it. Well, mostly. I have been using dwm exclusively for well over two years now and tools like st and dmenu for much longer. They make good software.
A common misconception I hear is that Suckless software follows the Unix philosophy, or is somehow minimal. I think this is partially true. Especially for tools like dmenu. However there are some deeper problems within the software that I think bars it from being labelled Unix-y.
the configuration file
Suckless software is not configured via a file. Instead it is configured via a header file (basically a file declaring variables, functions, and whatnot throughout the source code). The problem here is that a huge part of what makes Unix great is the file system. That is, everything is a file, including configuration. Instead the configuration is baked into the binary from that header file. Not only does this disrespect the filesystem, but it uses one of the most complex tools in a Unix system for such a basic task -- the C compiler.
They do provide an explanation, although a poor one on their page for dwm.
dwm is customized through editing its source code, which makes it extremely fast and secure - it does not process any input data which isn't known at compile time, except window titles and status text read from the root window's name.
Maybe it is technically faster, but I don't think the users care about waiting a few hundred nanoseconds for the program to read their configuration file. Especially opposed to the time it takes to compile the program. In a sense it isn't faster, when you compile is when you load it. And of course when you do that the time to compile all the files again is much longer than just reading a configuration file.
Now in terms of the security, I call in to question exactly what the threat is. If you don't trust a configuration file, you're not in a situation to trust the binary either, or if you have per-user configs your entire user. With shell or home folder access an evil person can cause much more chaos than changing your window manager settings and causing your poorly written C to read memory it shouldn't. How about recording your screen without your knowledge, or stealing all the cookies in your browser?
When it comes to security, you need a threat model. And I can't think of any that would make compile-time configuration somehow more secure. If you're somehow worried about untrusted configuration Unix filesystem permissions provides better ways for that.
You don't have to learn Lua/sh/ruby or some weird configuration file format (like X resource files), beside C, to customize it for your needs: you only have to learn C (at least in order to edit the header file).
Configuration formats can be not weird. YAML is probably easier to learn than C header files. Take for example this portion of my config.h for dwm.
static const Layout layouts[] = {
/* symbol arrange function */
{ "[]=", tile }, /* first entry is default */
{ "><>", NULL }, /* no layout function means floating behavior */
{ "[O]", monocle },
{ "]-", gaplessgrid },
};
I'd say for a normal person this would be weirder than even an Xresources file. I'll roughly translate this to YAML.
layout:
symbols:
grid: "]-"
monocole: "[0]"
tile: "[]="
other: "><>" # i.e. floating
Much more readable right? I think even people new to touching a configuration file would have an easier time toying with this. Of course I use YAML as an example, it's not perfect but it's way better than the C header files.
patches
I am not against the concept of patches. I think that extending your program with niche features is good, and sharing them is better. The problem I have is that some really basic features is stuck as patches. Take st for example. In order to properly render boxes, make st resize properly, or fix title parsing you need to patch your build. And of course when you have so many patches you end up with conflicts, which requires you to modify the source code of st for them to work.
Making Suckless software work well is a challenge for anyone, especially those who don't know C or programming to begin with. The software would be much better if they accepted even a few of these patches.
"small" code
LibXft, Xlib, and friends are all very large libraries. Suckless makes claims such as dwm only having two thousand lines of code, yet they use 16,000+ lines long, buggy, unstable libraries. I think if you're going to make a claim on being extremely tiny it's misleading to exclude the line count of those libraries as well. With that considered the actual difference between it and other software using similar libraries is less impressive. I mean come on, the browser they made uses WebKit of all things.
They also exclude basic features like configuration files, which of course also deflates the line count. I'd venture to guess that the functionality per line of code is much stronger with most other software.
conclusion
Suckless criticises software developers for thinking more lines of code equals better software. I agree, but caring about how tiny you can make your program (outside of something like embedded) is just as bad. A lot of their software is so close to excellence but fails because they're too stuck up in their own ways. I think the true marker of good software is the ratio of its size and functionality. Suckless has the size part, but not the functionality. They should learn more about what makes Unix great and embrace its good parts.