Live data from Hacker News

Why I Use Suckless Tools

christine.website

11–20 of 215 posts

Re: Why I Use Suckless Tools

#11
post #6
post #2

This caters to a very specific audience though. This particular concept while labelled suckless sounds like hell to me. To change a config I need to recompile stuff? Jikes To each their own though. I can see how this could work well if one invested a mountain of time into learning & fine-tuning it all

> suckless tools having their configuration baked into the executable at compile time, they start up instantly I wonder how many milliseconds slower the startup of a C application will be, when it reads a config file from SSD first.

Yeah, reading a single file will not have a noticable impact, but we all know it will not stop at a single file. Before you know it a full blown web browser is included. The suckless philosophy is pretty extreme, but I'm grateful there are people exploring this space.

Re: Why I Use Suckless Tools

#12

Seems like having to use a bunch of popular patches is counter to the author's other praises about how simple and minimal the software is. Why doesn't upstream integrate them and let everyone use them without having to patch?

I'm guessing it's because of their philosophy that more lines of code might be a liability: https://suckless.org/philosophy/

Note that you can use dwm just fine without any patches.

Re: Why I Use Suckless Tools

#13

Seems like having to use a bunch of popular patches is counter to the author's other praises about how simple and minimal the software is. Why doesn't upstream integrate them and let everyone use them without having to patch?

Because suckless tools value low line count over most other metrics.

The software is generally pretty good though, they cater to a niche. Dont be mad if thats not you. (Its not me either)

Luke smith has some pretty good content covering their tools

https://youtu.be/unqsQJaECv0

Re: Why I Use Suckless Tools

#14
I'm not familiar with this "suckless" philosophy, although I've seen it go by a couple times recently. I'm guessing that "suckless" means something different from what I might guess, given half of the article is about how great it is consists of having to debug some serious problem yourself, and the rest of it is self-congratulation over having to recompile everything because "reading configs is hard".

To paraphrase Arthur Dent: "Ah, this is obviously some strange use of the word 'less' that I wasn't previously aware of."

Re: Why I Use Suckless Tools

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

Re: Why I Use Suckless Tools

#16
post #6

Earlier quoted context omitted.

> suckless tools having their configuration baked into the executable at compile time, they start up instantly I wonder how many milliseconds slower the startup of a C application will be, when it reads a config file from SSD first.

Yeah, reading a single file will not have a noticable impact, but we all know it will not stop at a single file. Before you know it a full blown web browser is included. The suckless philosophy is pretty extreme, but I'm grateful there are people exploring this space.

Yea people seem to be quite critical of this when its not like they have to use it.

Do people act this way if you do LFS?

Re: Why I Use Suckless Tools

#17
I used st for a while but switched to kitty. kitty obviously has way more features (things like colour switching can be added to st, but requires messing with patches which I dislike, and dislike more than compiling on each configuration change).

I've been using kitty for a few months now and performance is great. in fact, the biggest performance gain I saw was when I switched away from "oh my zsh" to a manually written `~/.zshrc`.

Re: Why I Use Suckless Tools

#18
post #6

Earlier quoted context omitted.

> suckless tools having their configuration baked into the executable at compile time, they start up instantly I wonder how many milliseconds slower the startup of a C application will be, when it reads a config file from SSD first.

Yeah, reading a single file will not have a noticable impact, but we all know it will not stop at a single file. Before you know it a full blown web browser is included. The suckless philosophy is pretty extreme, but I'm grateful there are people exploring this space.

I think that's the key thing. It's not about config, it's the fact that the "plugins" are all compiled in as well— meanwhile over here in the real world we have there are entire programs and methodologies dedicated to managing directories of vimscript files, and sharing your personal dotfiles directory on github is a thing.

Re: Why I Use Suckless Tools

#19
post #4

I get that people enjoy very minimalist computer experiences, but startup time is hardly that different between these programs and other slightly more ergonomic programs which offer conveniences like a config file. If you look at my startup time for my system it goes something like this: 10s - waiting for monitor to wake up to pick OS at dual boot menu 15s - typing disk encryption password 15s - system uses disk encr…

I completely agree. Suckless tools shouldn't be pedantic about C code minimalism. As per my definition, suckless tools are lightweight, KISS and offer some simple ergonomics. I find it nice to be able to scroll the terminal up, when I'm not inside of tmux.

Re: Why I Use Suckless Tools

#20

Seems like having to use a bunch of popular patches is counter to the author's other praises about how simple and minimal the software is. Why doesn't upstream integrate them and let everyone use them without having to patch?

After everyone upstreams their favourite feature, it'll end up as bloated as the normal (sucky?) software they ostensibly hate.
Post reply on HN