4 ms·

> 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 fe

by hhmc 6y ago

> 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.

tarruda 6y ago
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).
- ryanmjacobs 6y ago
  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
  - ken 6y ago
    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!
    - ryanmjacobs 6y ago
      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.
      - RMPR 6y ago
        iirc Dwm doesn't have a "taskbar", at least by default, there's a patch for that.
        ryanmjacobs 6y ago
        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
- ilitirit 6y ago
  > 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.
  - noobermin 6y ago
    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.
    - ilitirit 6y ago
      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.

by hhmc 6y ago

tarruda 6y ago

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).

ryanmjacobs 6y ago
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
- ken 6y ago
  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!
  - ryanmjacobs 6y ago
    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.
    - RMPR 6y ago
      iirc Dwm doesn't have a "taskbar", at least by default, there's a patch for that.
      - ryanmjacobs 6y ago
        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
ilitirit 6y ago
> 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.
- noobermin 6y ago
  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.
  - ilitirit 6y ago
    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.