Hacker News Reader

Comment by hhmc | Hacker News Reader

> If something goes wrong while using them, you can easily jump right into the code that implements them and nail down issues using basic debugger skills.

I feel like we have very different conceptions of what 'easily' fixing a configuration issue looks like.

View on HN

From the implementation POV, suckless software is very simple, and this makes it easier not only to tweak configuration (which is usually done C headers through defines), but also any kind of customization you might need.

Take their window manager dwm as an example. The codebase is only 2000 lines long, so any bug you find will have to be hidden in those 2000 lines. If you take a Sunday afternoon to study the code, you will very likely understand how every piece of the software works, at which point you will be in a position to fix anything you might find. You might even end up forking it and implementing your own window manager (AwesomeWM was originally forked from Dwm).

This comment strikes home. The "bug-space" is so much smaller, and definitely possible for a lone newcomer to grasp in a day or two

A window manager may be only 2000 lines of source code but it implements a host of formal and informal standards and interacts with hundreds of other programs on my computer.

You may need only a day or two to orient yourself to the source code, but that’s on top of months or years of experience with X11R6 and ICCCMv2 and EWMH and such. How much debugging did you first need to do to discover your current issue was even in dwm?

EDIT: I especially love the phrasing in Wikipedia's ICCCM article: dwm "can be configured for compliance". If 'configuration' can include editing source code, I'm sure that's true!

I agree to an extent. I'll admit, there is much more under the surface of dwm that 2000 lines of source code. It's all abstractions in the end. But Gnome and KDE are more likely to have bugs because they cover such a wide scope. I've never had dwm fail to do what it claimed to do. But I have had weird Gnome glitches with taskbar hovering and window dragging with workspaces, etc.

Dwm "wins" by just giving up, in a sense. It doesn't try to implement a taskbar, therefore it cannot have a buggy taskbar.

EDIT: I guess it does have a "Taskbar", but in a very, very limited scope.

iirc Dwm doesn't have a "taskbar", at least by default, there's a patch for that.

Yeah, I guess a better word is "statusbar" or "workspace bar". It just displays the currently selected workspaces, the current window's title, and dwmstatus. The point is that it doesn't try to manage buttons and icons for minimize/maximize/multiple-stacked window types etc, like a traditional window manager

> If you take a Sunday afternoon to study the code, you will very likely understand how every piece of the software works, at which point you will be in a position to fix anything you might find. You might even end up forking it and implementing your own window manager (AwesomeWM was originally forked from Dwm).

I don't think I have ever needed to do this "fix" any piece of configuration in any software.

While I understand the concept and approach, I don't think that this is a productive use of most people's time.

Be a little charitable to OP and this reply. The configuration is indeed in code but it's macro defines. It's essentially as simple as changing a text configuration file, it's not like you have to actually edit code (as in new functions, adding actual logic). Things like fonts and sizes and colors is changing defines, it's actually simple.

Now when it comes to more complex stuff, like hotkeys, well you're essentially programming already in most other wms that doesn't have such things build in. AwesomeWM, i3, qtile (not popular but I used it for years) basically is half-way to programming, although it's a line, so it isn't any worse. I think the thing people aren't getting is the code is actually simple, so editing it and recompiling it isn't a chore.

I actually am quite familiar with suckless tools and I do consider myself an advanced user, so I'm probably part of their target market as well. But to be honest, from a pragmatic point of view I just don't see how configuration through code is better/worse than configuration through dot/json/ini files in the average "suckless" use-case. Why must this even be something that I care about?

If it's a case of their software being simpler to understand so which makes it easier to fix bugs, then sure, I get that. But in my experience, software that has been around forever just tends to have fewer bugs in general so it's also just something else that I simply don't need to care about. And how often does the average user of suckless tools actually have to fix bugs in the programs? If it's more than once, then does the label "suck less" even qualify?

Is it just because the software is extremely minimal and therefore less "bloated"? I get that too, but personally, why would I care if a piece of software is 70kb or 500kb in this age? YMMV.

Don't get me wrong - I'm not trying to bash suckless or any other community here. I'm just very pragmatic about the tools that I use and my workflow. If you're the type of person that likes to tinker and customize every aspect from the ground up, sure then maybe suckless tools are for you. Tinker and mod away, there's absolutely nothing wrong with that.

> I get that too, but personally, why would I care if a piece of software is 70kb or 500kb in this age? YMMV.

I'm torn on this because I am way, way over screwing around with my OS, but I also hate that all the modern standard desktop operating systems (macOS, Win10, Gnome3 or KDE) that you get if you don't want to jack with defaults and configure things or use some way-less-popular so likely to be (even more) janky distro or "spin" or whatever, want to take up a gigabyte or more (way more for macOS and Win10 especially, tens of GB) of disk and hundreds of MB of RAM, while delivering experiences that are marginally better than what we had in the late 90s and early 2000s with sub-GB OS installations and low-tens of MB of memory use when idle.

All the more reason to not get worked up over including something as mundane as a TOML parser in your dependencies for a config file. So that, you know, you don't have to recompile your WM whenever you want to adjust something.

Personally, it's a hugely productive use of my time, if I didn't have the ability to customize my UIs to work around my health issues I could code very little, or not at all.

I use Awesome WM which is configured / scripted with lua. I know lua already so it's great.

Have you ever used software with bugs?

Reply on news.ycombinator.com