commit e7537e7e4c0da4e8e3f602f74d526e993f16c4d6
parent 85a4835457dfd9ba2870e04e78f98a5a0a443f63
Author: Andrew Laack <andrew@laack.co>
Date: Sun, 19 Oct 2025 21:53:41 -0500
Wrote post about config files
Diffstat:
6 files changed, 171 insertions(+), 1 deletion(-)
diff --git a/posts/entries/config-files-suck.md b/posts/entries/config-files-suck.md
@@ -0,0 +1,39 @@
+# Config Files Suck
+
+## Date: 2025/11/19
+
+Config files suck for three main reasons.
+
+## Reasons
+
+1. They often require learning an idiosyncratic way of defining things that doesn't generalize across programs
+2. They are annoying to version and track
+3. Config files limit the configurability of software
+
+## Explanation
+
+### Learning Useless Things Sucks
+
+Config files suck because learning useless things sucks. Most config files follow their own definition format. This results in ephemeral information being learned and very quickly forgotten. Often this process repeats a few times for pieces of software that require reconfiguration to meet the expectations of the user.
+
+The time spent understanding the DSL of the config file would likely be better spent writing code in a proper programming language. There are two primary benefits to this. First, it builds on prior experience. If you are skilled at writing C code your ability to understand and configure software that is configured in C is improved by this prior knowledge. Second, by doing this process of configuration you are learning information that is likely less ephemeral. There are only a few good programming languages and by programming in them your proficiency in using them increases.
+
+### The Disconnect Between Configuration and Source Code Sucks
+
+Consider my dotfiles [1]. There are three files in my dotfiles that don't reside in the XDG_CONFIG_HOME directory. These three files are my .bashrc, my .Xresources, and my .xinitrc files. I have these in my XDG_CONFIG_HOME directory and symlink to them from their expected locations because the programs don't respect the XDG_CONFIG_HOME directory specification. This is annoying to setup on each system I use. A simple solution to this is to not use software that doesn't respect the spec, but when Xorg and Bash don't respect the spec, it becomes a bit more difficult to do so.
+
+The bigger issue is that the disconnect between the configuration of software and source code results in multiple sources of information contributing to the configuration of a software program. This is annoying because to achieve the same program configuration across systems one must ensure two different locations are synchronized instead of one.
+
+### Being Limited in What You Can Change About Programs Sucks
+
+Config files often don't allow for large changes to be made to programs. The changes that can be made are constrained to what is deemed reasonable by the developers of the software. This is not similar to proprietary software where the developers actively hinder the freedom of users, but by having the source code and the configuration done in the same location, you can fundamentally change the operation of the program without jumping between different locations.
+
+## The Redeeming Factor
+
+As I see it, config files are worthwhile if users are expected not to build from source. This may be the case for many open source projects, but I personally dislike using software in this way. This is a matter of opinion, but I think one of the most valuable parts free software is the freedom to change the source code as I see fit. By distributing software with config files, this sends an implicit message to users that they are expected to use the software as is, without modifying the source code.
+
+If you don't see a reason to build from source, it is your right to continue using config files. If you are building a project where you want users to configure, extend, and customize their computing experience to the fullest extent, consider doing away with config files as it forces users to directly manipulate your codebase, giving them more autonomy and flexibility. This may hinder mass adoption, but is that why you build software? It's not why I do.
+
+## Citations
+
+[1] - [https://git.laack.co/dotfiles](https://git.laack.co/dotfiles)
diff --git a/posts/site/config-files-suck.html b/posts/site/config-files-suck.html
@@ -0,0 +1,52 @@
+<!DOCTYPE html>
+<html xmlns="http://www.w3.org/1999/xhtml" lang="" xml:lang="">
+<head>
+ <meta charset="utf-8" />
+ <meta name="generator" content="pandoc" />
+ <meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=yes" />
+ <title>config-files-suck</title>
+ <style>
+ code{white-space: pre-wrap;}
+ span.smallcaps{font-variant: small-caps;}
+ div.columns{display: flex; gap: min(4vw, 1.5em);}
+ div.column{flex: auto; overflow-x: auto;}
+ div.hanging-indent{margin-left: 1.5em; text-indent: -1.5em;}
+ /* The extra [class] is a hack that increases specificity enough to
+ override a similar rule in reveal.js */
+ ul.task-list[class]{list-style: none;}
+ ul.task-list li input[type="checkbox"] {
+ font-size: inherit;
+ width: 0.8em;
+ margin: 0 0.8em 0.2em -1.6em;
+ vertical-align: middle;
+ }
+ .display.math{display: block; text-align: center; margin: 0.5rem auto;}
+ </style>
+ <link rel="stylesheet" href="style.css" />
+</head>
+<body>
+<h1 id="config-files-suck">Config Files Suck</h1>
+<h2 id="date-20251119">Date: 2025/11/19</h2>
+<p>Config files suck for three main reasons.</p>
+<h2 id="reasons">Reasons</h2>
+<ol type="1">
+<li>They often require learning an idiosyncratic way of defining things that doesn’t generalize across programs</li>
+<li>They are annoying to version and track</li>
+<li>Config files limit the configurability of software</li>
+</ol>
+<h2 id="explanation">Explanation</h2>
+<h3 id="learning-useless-things-sucks">Learning Useless Things Sucks</h3>
+<p>Config files suck because learning useless things sucks. Most config files follow their own definition format. This results in ephemeral information being learned and very quickly forgotten. Often this process repeats a few times for pieces of software that require reconfiguration to meet the expectations of the user.</p>
+<p>The time spent understanding the DSL of the config file would likely be better spent writing code in a proper programming language. There are two primary benefits to this. First, it builds on prior experience. If you are skilled at writing C code your ability to understand and configure software that is configured in C is improved by this prior knowledge. Second, by doing this process of configuration you are learning information that is likely less ephemeral. There are only a few good programming languages and by programming in them your proficiency in using them increases.</p>
+<h3 id="the-disconnect-between-configuration-and-source-code-sucks">The Disconnect Between Configuration and Source Code Sucks</h3>
+<p>Consider my dotfiles [1]. There are three files in my dotfiles that don’t reside in the XDG_CONFIG_HOME directory. These three files are my .bashrc, my .Xresources, and my .xinitrc files. I have these in my XDG_CONFIG_HOME directory and symlink to them from their expected locations because the programs don’t respect the XDG_CONFIG_HOME directory specification. This is annoying to setup on each system I use. A simple solution to this is to not use software that doesn’t respect the spec, but when Xorg and Bash don’t respect the spec, it becomes a bit more difficult to do so.</p>
+<p>The bigger issue is that the disconnect between the configuration of software and source code results in multiple sources of information contributing to the configuration of a software program. This is annoying because to achieve the same program configuration across systems one must ensure two different locations are synchronized instead of one.</p>
+<h3 id="being-limited-in-what-you-can-change-about-programs-sucks">Being Limited in What You Can Change About Programs Sucks</h3>
+<p>Config files often don’t allow for large changes to be made to programs. The changes that can be made are constrained to what is deemed reasonable by the developers of the software. This is not similar to proprietary software where the developers actively hinder the freedom of users, but by having the source code and the configuration done in the same location, you can fundamentally change the operation of the program without jumping between different locations.</p>
+<h2 id="the-redeeming-factor">The Redeeming Factor</h2>
+<p>As I see it, config files are worthwhile if users are expected not to build from source. This may be the case for many open source projects, but I personally dislike using software in this way. This is a matter of opinion, but I think one of the most valuable parts free software is the freedom to change the source code as I see fit. By distributing software with config files, this sends an implicit message to users that they are expected to use the software as is, without modifying the source code.</p>
+<p>If you don’t see a reason to build from source, it is your right to continue using config files. If you are building a project where you want users to configure, extend, and customize their computing experience to the fullest extent, consider doing away with config files as it forces users to directly manipulate your codebase, giving them more autonomy and flexibility. This may hinder mass adoption, but is that why you build software? It’s not why I do.</p>
+<h2 id="citations">Citations</h2>
+<p>[1] - <a href="https://git.laack.co/dotfiles">https://git.laack.co/dotfiles</a></p>
+</body>
+</html>
diff --git a/posts/site/feed.xml b/posts/site/feed.xml
@@ -7,9 +7,16 @@
<language>en-us</language>
<managingEditor>andrew@laack.co</managingEditor>
<webMaster>andrew@laack.co</webMaster>
-<lastBuildDate>Fri, 17 Oct 2025 00:32:22 -0500</lastBuildDate>
+<lastBuildDate>Sun, 19 Oct 2025 21:52:53 -0500</lastBuildDate>
<atom:link href="https://blog.laack.co/feed.xml" rel="self" type="application/rss+xml"/>
<item>
+<title><![CDATA[Config Files Suck]]></title>
+<link>https://blog.laack.co/config-files-suck.html</link>
+<description><![CDATA[<p>Config files suck for three main reasons.</p><h2 id="reasons">Reasons</h2><ol type="1"><li>They often require learning an idiosyncratic way of defining things that doesn’t generalize across programs</li><li>They are annoying to version and track</li><li>Config files limit the configurability of software</li></ol><h2 id="explanation">Explanation</h2><h3 id="learning-useless-things-sucks">Learning Useless Things Sucks</h3><p>Config files suck because learning useless things sucks. Most config files follow their own definition format. This results in ephemeral information being learned and very quickly forgotten. Often this process repeats a few times for pieces of software that require reconfiguration to meet the expectations of the user.</p><p>The time spent understanding the DSL of the config file would likely be better spent writing code in a proper programming language. There are two primary benefits to this. First, it builds on prior experience. If you are skilled at writing C code your ability to understand and configure software that is configured in C is improved by this prior knowledge. Second, by doing this process of configuration you are learning information that is likely less ephemeral. There are only a few good programming languages and by programming in them your proficiency in using them increases.</p><h3 id="the-disconnect-between-configuration-and-source-code-sucks">The Disconnect Between Configuration and Source Code Sucks</h3><p>Consider my dotfiles [1]. There are three files in my dotfiles that don’t reside in the XDG_CONFIG_HOME directory. These three files are my .bashrc, my .Xresources, and my .xinitrc files. I have these in my XDG_CONFIG_HOME directory and symlink to them from their expected locations because the programs don’t respect the XDG_CONFIG_HOME directory specification. This is annoying to setup on each system I use. A simple solution to this is to not use software that doesn’t respect the spec, but when Xorg and Bash don’t respect the spec, it becomes a bit more difficult to do so.</p><p>The bigger issue is that the disconnect between the configuration of software and source code results in multiple sources of information contributing to the configuration of a software program. This is annoying because to achieve the same program configuration across systems one must ensure two different locations are synchronized instead of one.</p><h3 id="being-limited-in-what-you-can-change-about-programs-sucks">Being Limited in What You Can Change About Programs Sucks</h3><p>Config files often don’t allow for large changes to be made to programs. The changes that can be made are constrained to what is deemed reasonable by the developers of the software. This is not similar to proprietary software where the developers actively hinder the freedom of users, but by having the source code and the configuration done in the same location, you can fundamentally change the operation of the program without jumping between different locations.</p><h2 id="the-redeeming-factor">The Redeeming Factor</h2><p>As I see it, config files are worthwhile if users are expected not to build from source. This may be the case for many open source projects, but I personally dislike using software in this way. This is a matter of opinion, but I think one of the most valuable parts free software is the freedom to change the source code as I see fit. By distributing software with config files, this sends an implicit message to users that they are expected to use the software as is, without modifying the source code.</p><p>If you don’t see a reason to build from source, it is your right to continue using config files. If you are building a project where you want users to configure, extend, and customize their computing experience to the fullest extent, consider doing away with config files as it forces users to directly manipulate your codebase, giving them more autonomy and flexibility. This may hinder mass adoption, but is that why you build software? It’s not why I do.</p><h2 id="citations">Citations</h2><p>[1] - <a href="https://git.laack.co/dotfiles">https://git.laack.co/dotfiles</a></p>]]></description>
+<pubDate>Wed, 19 Nov 2025 00:00:00 -0600</pubDate>
+<guid>https://blog.laack.co/config-files-suck.html</guid>
+</item>
+<item>
<title><![CDATA[You Don't Need Anything]]></title>
<link>https://blog.laack.co/you-dont-need-anything.html</link>
<description><![CDATA[<h2 id="context">Context</h2><p>The words we say have an impact on how we think. A word I find problematic is the word need.</p><h2 id="definition">Definition</h2><p>Need: a requirement, necessary duty, or obligation.</p><h2 id="my-thoughts">My Thoughts</h2><p><strong>Do You Really <em>need</em> Anything?</strong></p><p>I often say this when people use an unqualified need. An unqualified need is as follows:</p><p><strong>I <em>need</em> to eat food, I’m starving!</strong></p><p>Aside from the fact that they likely aren’t starving, they don’t <em>need</em> food. This can be thought of in a similar way as the is-ought problem [2]. If someone says they <em>need</em> something, you can ask them, “Why do you <em>need</em> it?”. In the case of food they may say, “I <em>need</em> food to survive”, and to this you may say, “Why do you <em>need</em> to survive”, and this can continue indefinitely as needs are predicated upon something. Often need has an implicit qualification as is the case of, “I <em>need</em> food” implying that it is needed to survive, but you don’t <em>need</em> to survive. I don’t want you to die, but it is not necessary for you to live. Tying this to the definition of need, there is no requirement, duty, or obligation for someone to be alive. There are no universal requirements to do things, no one has a universal duty to do things, and no one has a universal obligation to do anything. You may <em>need</em> to complete a project at work to not get fired, but you don’t <em>need</em> to complete the project, you can just get fired, you are not obligated to not be fired.</p><p>The danger in statements like, “I <em>need</em> to eat food”, is they create a dependence upon something. By saying you <em>need</em> something you are telling yourself that without it you are incomplete. You are beholden unto this thing. This is dangerous because it leads to acts of immorality because of the perception that something must be done. I believe this is what has led to mass surveillance. People think they <em>need</em> to do what their boss tells them to do even when they know it’s wrong.</p><p>YOU DON’T NEED ANYTHING. You want it because you perceive the consequences of not having it are worse than having it. This is not a need. This is a want. Understand the difference.</p><p>You don’t need to live. You don’t need food. You don’t need water.</p><h2 id="citations">Citations</h2><p>[1] - <a href="https://www.dictionary.com/browse/need">https://www.dictionary.com/browse/need</a></p><p>[2] - <a href="https://en.wikipedia.org/wiki/Is%E2%80%93ought_problem">https://en.wikipedia.org/wiki/Is%E2%80%93ought_problem</a></p>]]></description>
diff --git a/posts/site/index.html b/posts/site/index.html
@@ -11,6 +11,7 @@
<h1>Andrew's Blog</h1>
<p><a href="feed.xml">RSS Feed</a></p>
<ol>
+<li><a href="config-files-suck.html">config-files-suck</a> - <em>2025/11/19</em></li>
<li><a href="you-dont-need-anything.html">you-dont-need-anything</a> - <em>2025/10/17</em></li>
<li><a href="stop-collecting-user-data.html">stop-collecting-user-data</a> - <em>2025/10/12</em></li>
<li><a href="adnauseum-track-me-not-and-privacy-through-obscurity.html">adnauseum-track-me-not-and-privacy-through-obscurity</a> - <em>2025/10/4</em></li>
diff --git a/posts/wip/my-definition-of-good-software.md b/posts/wip/my-definition-of-good-software.md
@@ -0,0 +1,32 @@
+# My Definition of Good Software
+
+## Obvious Attributes of Good Software
+
+These are attributes of good software that I deem so obvious they needn't be discussed any further.
+
+- Distributed under a Free license
+- Free from malware, as described by the FSF [1]
+
+## Less Obvious Attributes
+
+1. Written in C, assembly, a functional programming language, or POSIX shell
+
+Software written in C can be good because C is a performant language that has compilers for most operating systems and architectures. Moreover, C compilers are simple to make which allows for ease of distribution of C code across new operating systems and architectures.
+
+Software written in functional programming languages can be good because functional languages provide assurances about the software. Functional languages enforce no side effects and immutability. While this can slow down software, it gives useful guarantees about its correctness.
+
+Software written in POSIX shell can be good because, similar to C, it is highly portable, and there are cases where using scripting languages can make sense.
+
+2. Minimal Dependencies
+
+Software with more dependencies is more brittle. It often relies on the continued development of other projects, often when not entirely necessary.
+
+There is no expectation for software to be entirely self contained, but lots of consideration should be given prior to adding dependencies to software.
+
+3. Easy Patching
+
+DSLs suck. Patching the software should be easy and done in the language the program was written in. This allows for users to transfer their understanding of languages to the tools they use without having to learn idiosyncratic syntax for config files.
+
+## Citations
+
+[1] - https://www.gnu.org/proprietary/proprietary.html
diff --git a/posts/wip/what-i-want-from-a-vcs.md b/posts/wip/what-i-want-from-a-vcs.md
@@ -0,0 +1,39 @@
+# What I Want From a VCS
+
+Similar to Luke Smith's blog post about browsers [1], I would like to put forth what I want from a VCS. Currently, no VCS meets all of my requirements for it to be considered good.
+
+Here is a list of VCS's in consideration. If there are additional ones I am missing that are free software (a requirement for it to even be considered ethical to use) and reasonable enough to be compared, please email me.
+
+- Git
+- Mercurial
+- Subversion (SVN)
+- Fossil
+- Darcs
+- Revision Control System
+- CVS
+- SCCS
+- Pijul
+- JJ
+
+
+## Cutting Down The List
+
+
+1. The VCS can't allow rewriting history
+
+The purpose of a VCS is to track the history of files. If the history of files can be rewritten it both makes the state at a given time confusing, and defeats the purpose of using a VCS.
+
+Disqualifies:
+
+- Git (Rebase)
+- JJ
+- Fossil
+- Mercurial
+- Darcs
+
+Allows:
+
+- CVS
+- SVS
+- SCCS
+- RCS
