Hacker News Reader

Comment by Havoc | Hacker News Reader

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

View on HN

On the other hand, compiling these applications is also near-instant and literally just requires executing "make", another thing they are quite good at. Small application <=> small build system.

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

With suckless you don't have your dotfiles on GitHub, but your fork and then you have to keep close to upstream all the time. Else they might cause a merge hell later ...

And then pretty soon the plugins are in one or more scripting languages (probably JavaScript) and your scripting subsystem is 100x the size of all of dwm.

> it will not stop at a single file. Before you know it a full blown web browser is included

There are real world examples like bspwm (my favorite window manger), that proves you wrong. It is configurable via config file and is as "suckless" as it could be.

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?

I benchmarked my 600-line zsh config this morning because I was curious how long it takes to run. It takes about 0.02 seconds to run, and that's on a €250 crappy Celeron laptop.

Reading a simple config file will probably be faster. So yeah, it's pretty much negligible.

I do like the config.h as it's easy to include your own hacks, I added some key mappings and modifications to dwm that would be much harder with a config.ini or whatnot; but that's very different than startup speed.

Over millions of application runs, it adds up to hours!

But seriously, reading a config file means there has to be a syntax and a parser, and both have to be maintained. The syntax can be limiting or fiendishly complex, both by accident. The parser can have bugs. Is it really worth adding these headaches just so editing your config file is one instead of two commands?

Milliseconds? Probably less than one.

The recompilation takes basically no time. And I think it's appropriate for something like a window manager where changes should be infrequent and the thing should be as fast and do only its job. For people who frequently change small things, this provides some friction and can be annoying to change a pixel difference and have to wait a few seconds to see the difference.

The code is less than 2k lines. It's understandable probably after a weekend.

Reply on news.ycombinator.com