6 ms·

> My recollection is that most CP/M programs were configured via patching. I honestly would have liked that better for a lot of programs than the dotfiles they

> My recollection is that most CP/M programs were configured via patching. I honestly would have liked that better for a lot of programs than the dotfiles they litter all over my home directory.

ozlikethewizard 5mo ago
Yea this is something I'd love to see standardised, a distro that was able to enforce a .config folder somehow would be a winner for me. Think weve probably missed the boat though.
- 9dev 5mo ago
  As these things go, there obviously is a standard for this called the XDG Base Directory Specification[0], which elegantly solves almost all configuration path needs—and has been ignored, violated, or only partially implemented, since forever. [0]: https://specifications.freedesktop.org/basedir/latest/ https://specifications.freedesktop.org/basedir/latest/
  - amelius 5mo ago
    Say what you want about AI but one nice aspect of it is that it is more likely to follow these kinds of standards than humans.
  - hollerith 5mo ago
    The problems this standard solves are not hard, and "elegant" is not how I'd describe the solution.
fredoralive 5mo ago
Part of the philosophy of the slightly odd suckless people is their projects are mostly configured by changing the source code and recompiling. This is I suppose a similar approach in a modern open source vein. Although their general asceticism makes their projects a bit of an acquired taste I suspect.
- analog_daddy 5mo ago
  Ohh acquired taste it is.. I had two stints with suckless software. First, when i was in early twenties when I had a lot of time in the world, and thought the manliest way to talk to a machine is all through low level C code. Had a whole flow to patch it and heck the code is so well written and commented, i was able to understand it. Then, i guess life happened and i discovered more interesting stuff to spend time on. And now in my late twenties, suckless terminal is the only one that would work reliably on a shitty old enterprise linux system at work. Yeah, we got xterm and konsole (the older one). I am seeing them in a whole different light now. I did not read the source code now and it is effectively a foreign language to me, but just being able to have modern features in it without too many dependencies is a different level of bliss. This time, I am glad I have the flexi patch to the rescue since, i passed on suckless terminal as a real alternative since I don’t want to patch it manually or solve merge conflicts! Even though I don’t like the elitist attitude of the project, can’t deny they got a point. Why does a terminal emulator need to be so complicated! https://github.com/bakkeby/st-flexipatch https://github.com/bakkeby/st-flexipatch
  - archargelod 5mo ago
    > I don’t want to patch it manually or solve merge conflicts I wonder, is this really such a big problem? How often do people add patches or change their config? I've configured my st once and haven't touched that build for years. I use only few patches like scrollback, custom colortheme and a "plumb" for few scripts. I've also had an opportunity recently, to try a "modern" and trendy terminal and I can't see myself switching to something slower (in terms of lag) and using 10x more memory and cpu even when idle for literally zero gain.
    - analog_daddy 5mo ago
      Not frequently, however in experimental phase where you need to debug if any specific combination of patch is causing issues, it helps a lot. For instance, I had issues with my delete key not working even with delkey patch and then after trying to enable patches incrementally I zeroed in on the fixkeyboardinput patch. Sure I can do this in a VCS flow but, it feels magical what a bunch of ifdef’s simplify the process to. And I feel it is still suckless philosophy since the code still compiles to exactly what you need. Additionally, it helps lower the barrier to entry for a lot of people, who would have shied away from the manual patching flow. You’d be surprised how often i have seen people squint with default xterm on our servers, not knowing how to configure it and messing around with xrdb. (Which takes a while to propagate across LSF clusters). With flexipatch it feels easier to introduce it to them since I just say run make after any config changes to apply the setting and restart the terminal emulator. Ohh i tried wezterm and ghostty. Couldn’t get them working using just software rendering. And once st worked, I realized I don’t need it tbh.
PunchyHamster 5mo ago
Well, they are supposed to be all in .config, problem is many app developers think they are special little boys that deserve its own directory
- delta_p_delta_x 5mo ago
  %LOCALAPPDATA% on Windows. Or better still, use GetAppContainerFolderPath or SHGetKnownFolderPath with FOLDERID_LocalAppData.
  - ziml77 5mo ago
    I don't know if anyone is actually using roaming profiles, but config should go into the %APPDATA% folder to support that. %LOCALAPPDATA% is for things that shouldn't be synced to different machines, such as caches.
    - Uvix 5mo ago
      I know we used to use them in our corporate environment. Not sure if we still do, or if they gave up and called OneDrive “good enough”.
- delusional 5mo ago
  It all sounds so easy, until you learn about the XDG Base Directory Specification[1]. You're actually supposed to do a whole song and dance around a hierarchical set of environment variables, associated defaults, and resolution orders. Interfacing with people is never easy. [1]: https://specifications.freedesktop.org/basedir/latest/ https://specifications.freedesktop.org/basedir/latest/
  - archargelod 5mo ago
    No. Actually, it's easy. Just check for directory env or use a fallback. For example here's how you'd do this in bash: export CONFIG_DIR="${XDG_CONFIG_HOME:-$HOME/.config}" export CACHE_DIR="${XDG_CACHE_HOME:-$HOME/.cache}" ... XDG_*_DIRS are a bit more complicated, but nothing that can't be solved with a simple for-loop in any modern programming language.
mort96 5mo ago
You would've preferred binary patching of the executable? Really?
Hendrikto 5mo ago
If people just followed the XDG Base Directory Specification, config file littering would be a non-issue. More and more projects adopt it, even holdouts like Firefox.
- user3939382 5mo ago
  I contemplated for years and eventually saw someone implement a transparent kernel redirect for programs reaching for ~/.*
- ninkendo 5mo ago
  I wonder how many apps actually read the correct XDG environment variables and obey them, versus just hardcoding paths that match their machine’s config paths (typically ~/.config/*) I almost want to set up a VM that sets up XDG_CONFIG_HOME as ~/.foobar and see how many apps actually respect it, and how many still write to ~/.config.
  - jdpage 5mo ago
    A few years ago I had a Windows box where I pointed XDG_CONFIG_HOME et al to the corresponding-ish Windows paths (AppData subdirectories, mostly) so that the many Linux-derived CLI programs I was using wouldn't clutter up my userdir, and it worked pretty well, though there were a few programs that didn't get the memo. Unfortunately I don't remember which ones they were. Most programs get it right, though!
- skydhash 5mo ago
  I don’t mind ~/.* for config, especially when the config is just one or two files. What I don’t like is programs like go and cargo treating my $HOME as a dumping ground for every file they want to download and/or cache.
  - MereInterest 5mo ago
    At least cargo places everything in a .cargo directory, so it doesn’t display by default. Go will instead write to $HOME/go, without even the decency to use a hidden directory, unless you first define the GOPATH environment variable. And if you install more than one version of go, they get placed in $HOME/sdk [0]. Last I checked, this path is hard-coded with no override, despite this being a known issue for 8 years. [0] https://github.com/golang/go/issues/26520 https://github.com/golang/go/issues/26520
SoftTalker 5mo ago
I'll take dotfiles I can grep and mange with a text editor over settings littered all over a central binary registry. But maybe that's just what I'm used to.
- charonn0 5mo ago
  I'm the opposite: I'll take a centralized, strongly-typed registry over 'stringly' typed dotfiles scattered across the entire filesystem.
- liquid_thyme 5mo ago
  Every single program has to write logic to parse/store/query/validate those values. A common API with a single store can be type-enforced, backed up, and likely easier to work with from an internationalization perspective. I do like dotfiles for portable apps where everything the program needs is in one folder. Personally, my need for portable apps has gone down year on year.

> My recollection is that most CP/M programs were configured via patching. I honestly would have liked that better for a lot of programs than the dotfiles they litter all over my home directory.

ozlikethewizard 5mo ago

Yea this is something I'd love to see standardised, a distro that was able to enforce a .config folder somehow would be a winner for me. Think weve probably missed the boat though.

9dev 5mo ago
As these things go, there obviously is a standard for this called the XDG Base Directory Specification[0], which elegantly solves almost all configuration path needs—and has been ignored, violated, or only partially implemented, since forever. [0]: https://specifications.freedesktop.org/basedir/latest/ https://specifications.freedesktop.org/basedir/latest/
- amelius 5mo ago
  Say what you want about AI but one nice aspect of it is that it is more likely to follow these kinds of standards than humans.
- hollerith 5mo ago
  The problems this standard solves are not hard, and "elegant" is not how I'd describe the solution.

fredoralive 5mo ago

Part of the philosophy of the slightly odd suckless people is their projects are mostly configured by changing the source code and recompiling. This is I suppose a similar approach in a modern open source vein. Although their general asceticism makes their projects a bit of an acquired taste I suspect.

analog_daddy 5mo ago
Ohh acquired taste it is.. I had two stints with suckless software. First, when i was in early twenties when I had a lot of time in the world, and thought the manliest way to talk to a machine is all through low level C code. Had a whole flow to patch it and heck the code is so well written and commented, i was able to understand it. Then, i guess life happened and i discovered more interesting stuff to spend time on. And now in my late twenties, suckless terminal is the only one that would work reliably on a shitty old enterprise linux system at work. Yeah, we got xterm and konsole (the older one). I am seeing them in a whole different light now. I did not read the source code now and it is effectively a foreign language to me, but just being able to have modern features in it without too many dependencies is a different level of bliss. This time, I am glad I have the flexi patch to the rescue since, i passed on suckless terminal as a real alternative since I don’t want to patch it manually or solve merge conflicts! Even though I don’t like the elitist attitude of the project, can’t deny they got a point. Why does a terminal emulator need to be so complicated! https://github.com/bakkeby/st-flexipatch https://github.com/bakkeby/st-flexipatch
- archargelod 5mo ago
  > I don’t want to patch it manually or solve merge conflicts I wonder, is this really such a big problem? How often do people add patches or change their config? I've configured my st once and haven't touched that build for years. I use only few patches like scrollback, custom colortheme and a "plumb" for few scripts. I've also had an opportunity recently, to try a "modern" and trendy terminal and I can't see myself switching to something slower (in terms of lag) and using 10x more memory and cpu even when idle for literally zero gain.
  - analog_daddy 5mo ago
    Not frequently, however in experimental phase where you need to debug if any specific combination of patch is causing issues, it helps a lot. For instance, I had issues with my delete key not working even with delkey patch and then after trying to enable patches incrementally I zeroed in on the fixkeyboardinput patch. Sure I can do this in a VCS flow but, it feels magical what a bunch of ifdef’s simplify the process to. And I feel it is still suckless philosophy since the code still compiles to exactly what you need. Additionally, it helps lower the barrier to entry for a lot of people, who would have shied away from the manual patching flow. You’d be surprised how often i have seen people squint with default xterm on our servers, not knowing how to configure it and messing around with xrdb. (Which takes a while to propagate across LSF clusters). With flexipatch it feels easier to introduce it to them since I just say run make after any config changes to apply the setting and restart the terminal emulator. Ohh i tried wezterm and ghostty. Couldn’t get them working using just software rendering. And once st worked, I realized I don’t need it tbh.

PunchyHamster 5mo ago

Well, they are supposed to be all in .config, problem is many app developers think they are special little boys that deserve its own directory

delta_p_delta_x 5mo ago
%LOCALAPPDATA% on Windows. Or better still, use GetAppContainerFolderPath or SHGetKnownFolderPath with FOLDERID_LocalAppData.
- ziml77 5mo ago
  I don't know if anyone is actually using roaming profiles, but config should go into the %APPDATA% folder to support that. %LOCALAPPDATA% is for things that shouldn't be synced to different machines, such as caches.
  - Uvix 5mo ago
    I know we used to use them in our corporate environment. Not sure if we still do, or if they gave up and called OneDrive “good enough”.
delusional 5mo ago
It all sounds so easy, until you learn about the XDG Base Directory Specification[1]. You're actually supposed to do a whole song and dance around a hierarchical set of environment variables, associated defaults, and resolution orders. Interfacing with people is never easy. [1]: https://specifications.freedesktop.org/basedir/latest/ https://specifications.freedesktop.org/basedir/latest/
- archargelod 5mo ago
  No. Actually, it's easy. Just check for directory env or use a fallback. For example here's how you'd do this in bash: export CONFIG_DIR="${XDG_CONFIG_HOME:-$HOME/.config}" export CACHE_DIR="${XDG_CACHE_HOME:-$HOME/.cache}" ... XDG_*_DIRS are a bit more complicated, but nothing that can't be solved with a simple for-loop in any modern programming language.

mort96 5mo ago

You would've preferred binary patching of the executable? Really?

Hendrikto 5mo ago

If people just followed the XDG Base Directory Specification, config file littering would be a non-issue. More and more projects adopt it, even holdouts like Firefox.

user3939382 5mo ago
I contemplated for years and eventually saw someone implement a transparent kernel redirect for programs reaching for ~/.*
ninkendo 5mo ago
I wonder how many apps actually read the correct XDG environment variables and obey them, versus just hardcoding paths that match their machine’s config paths (typically ~/.config/*) I almost want to set up a VM that sets up XDG_CONFIG_HOME as ~/.foobar and see how many apps actually respect it, and how many still write to ~/.config.
- jdpage 5mo ago
  A few years ago I had a Windows box where I pointed XDG_CONFIG_HOME et al to the corresponding-ish Windows paths (AppData subdirectories, mostly) so that the many Linux-derived CLI programs I was using wouldn't clutter up my userdir, and it worked pretty well, though there were a few programs that didn't get the memo. Unfortunately I don't remember which ones they were. Most programs get it right, though!
skydhash 5mo ago
I don’t mind ~/.* for config, especially when the config is just one or two files. What I don’t like is programs like go and cargo treating my $HOME as a dumping ground for every file they want to download and/or cache.
- MereInterest 5mo ago
  At least cargo places everything in a .cargo directory, so it doesn’t display by default. Go will instead write to $HOME/go, without even the decency to use a hidden directory, unless you first define the GOPATH environment variable. And if you install more than one version of go, they get placed in $HOME/sdk [0]. Last I checked, this path is hard-coded with no override, despite this being a known issue for 8 years. [0] https://github.com/golang/go/issues/26520 https://github.com/golang/go/issues/26520

SoftTalker 5mo ago

I'll take dotfiles I can grep and mange with a text editor over settings littered all over a central binary registry. But maybe that's just what I'm used to.

charonn0 5mo ago
I'm the opposite: I'll take a centralized, strongly-typed registry over 'stringly' typed dotfiles scattered across the entire filesystem.
liquid_thyme 5mo ago
Every single program has to write logic to parse/store/query/validate those values. A common API with a single store can be type-enforced, backed up, and likely easier to work with from an internationalization perspective. I do like dotfiles for portable apps where everything the program needs is in one folder. Personally, my need for portable apps has gone down year on year.