4 ms·

> suckless tools having their configuration baked into the executable at compile time, they start up instantly I wonder how many milliseconds slower the startu

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

eeZah7Ux 6y ago
Milliseconds? Probably less than one.
rejschaap 6y ago
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.
- waheoo 6y ago
  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?
- mikepurvis 6y ago
  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.
  - johannes1234321 6y ago
    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 ...
  - karatestomp 6y ago
    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.
- tutfbhuf 6y ago
  > 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.
Carpetsmoker 6y ago
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.
08-15 6y ago
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?

eeZah7Ux 6y ago

Milliseconds? Probably less than one.

rejschaap 6y ago

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.

waheoo 6y ago
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?
mikepurvis 6y ago
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.
- johannes1234321 6y ago
  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 ...
- karatestomp 6y ago
  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.
tutfbhuf 6y ago
> 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.

Carpetsmoker 6y ago

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.

08-15 6y ago

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?