commit 6764d173f70723d1e760050911e63d8388680bd1
parent 675e3064411c4df7585b8092a895fa2947b3fc7d
Author: Jake Bauer <jbauer@paritybit.ca>
Date: Wed, 5 Apr 2023 19:39:05 -0400
*
Diffstat:
2 files changed, 185 insertions(+), 37 deletions(-)
diff --git a/content/garden/philosophy-software-development.md b/content/garden/philosophy-software-development.md
@@ -3,64 +3,187 @@ Summary: DRAFT: A Philosophy of Software Development
# [%title]
-<p class="note">This blog post is related to the previous: <em><a href="/blog/free-software-is-an-abject-failure">Free Software is an Abject Failure</a></em>.</p>
-
-I believe that the way we are building software today is fundamentally flawed. I'm not talking in terms of language, architecture, design choices, licensing choices, or anything along those lines. Instead, I'm talking about something that neither the Free Software nor the Open Source movements have been able to solve: mindset. I believe the mindset behind why we create software, who we are writing it for, and what purpose it is serving is wrong.
-
-The way we build software today creates and emphasizes a producer-consumer relationship between the developers of software and the users of that software instead of a more holistic environment in which they are one and the same. It creates people who become dependent on those who write the software they use instead of empowering them to create or mold computer software to fit their needs. Software should instead be made the same way we used to make most things before the age of computing: as robust tools built for one purpose, with only as much complexity as needed to do its job, and to last a long time[postapocalyptic]. This is only possible when it serves the needs of the user-developer, not those of developers vying for the highest market share or ever-increasing profits.
-
-Today our lives are dominated by gargantuan software projects which ultimately control how we can use our computers. Think Google and the Chrome web browser ecosystem. Think Apple and their entire ecosystem. Think GNU and gcc or even the entire Linux kernel. It doesn't matter if the software was written by a company or by FOSS contributors, the end result is the same: complicated, buggy, hard-to-understand software that individual users or communities cannot realistically mold to fit their needs, except in limited cases where allowed by the producers of that software.
-
-I'm sure we've all been in situations like when your favourite browser decides that it's more important to introduce built-in colour themes with great fanfare and excitement while stripping out usability features like menu icons[firefox] or severely handicapping adblocking[manifestv3]. When your favourite messaging app decides that sticker integration is more important than reliable message delivery and robust server and client software[matrix]. When an important feature is stripped from an artistic program because the company who owns the software is having a childish feud with the company who "owns colours"[lttcolor]. Or when your favourite desktop environment decides that it's time to redesign everything from the ground up[gnome, kde4]. I could go on and on, but I'm sure you see the problem.
-
-Any software aiming to attract the widest userbase, either to make more money, gain more funding, or just have more people using "objectively better software" will always be a race to the bottom. When the developers of software try to cater to every user, to every use case, the software can only head in one direction: into becoming a bloated, buggy, unmaintainable mess. Good luck trying to remove some functionality that 99% of your users don't need, but which a tiny subset do and will complain loudly about if it's removed (why do you think Windows has become such a monstrous mess) [xkcd1172].
+<p class="note">This blog post is related to the previous: <em><a
+href="/blog/free-software-is-an-abject-failure">Free Software is an Abject
+Failure</a></em>.</p>
+
+I believe that the way we are building software today is fundamentally flawed.
+I'm not talking in terms of language, architecture, design choices, licensing
+choices, or anything along those lines. Instead, I'm talking about something
+that neither the Free Software nor the Open Source movements have been able to
+solve: mindset. I believe the mindset behind why we create software, who we are
+writing it for, and what purpose it is serving is wrong.
+
+The way we build software today creates and emphasizes a producer-consumer
+relationship between the developers of software and the users of that software
+instead of a more holistic environment in which they are one and the same. It
+creates people who become dependent on those who write the software they use
+instead of empowering them to create or mold computer software to fit their
+needs. Software should instead be made the same way we used to make most things
+before the age of computing: as robust tools built for one purpose, with only
+as much complexity as needed to do its job, and to last a long
+time[postapocalyptic]. This is only possible when it serves the needs of the
+user-developer, not those of developers vying for the highest market share or
+ever-increasing profits.
+
+Today our lives are dominated by gargantuan software projects which ultimately
+control how we can use our computers. Think Google and the Chrome web browser
+ecosystem. Think Apple and their entire ecosystem. Think GNU and gcc or even
+the entire Linux kernel. It doesn't matter if the software was written by
+a company or by FOSS contributors, the end result is the same: complicated,
+buggy, hard-to-understand software that individual users or communities cannot
+realistically mold to fit their needs, except in limited cases where allowed by
+the producers of that software.
+
+I'm sure we've all been in situations like when your favourite browser decides
+that it's more important to introduce built-in colour themes with great fanfare
+and excitement while stripping out usability features like menu icons[firefox]
+or severely handicapping adblocking[manifestv3]. When your favourite messaging
+app decides that sticker integration is more important than reliable message
+delivery and robust server and client software[matrix]. When an important
+feature is stripped from an artistic program because the company who owns the
+software is having a childish feud with the company who "owns
+colours"[lttcolor]. Or when your favourite desktop environment decides that
+it's time to redesign everything from the ground up[gnome, kde4]. I could go on
+and on, but I'm sure you see the problem.
+
+Any software aiming to attract the widest userbase, either to make more money,
+gain more funding, or just have more people using "objectively better software"
+will always be a race to the bottom. When the developers of software try to
+cater to every user, to every use case, the software can only head in one
+direction: into becoming a bloated, buggy, unmaintainable mess. Good luck
+trying to remove some functionality that 99% of your users don't need, but
+which a tiny subset do and will complain loudly about if it's removed (why do
+you think Windows has become such a monstrous mess) [xkcd1172].
So, what would a different software landscape look like?
-Well, to start, the fact of the matter is that as a civilization we simply do not need massive kernels which handle absolutely everything in a system, web browsers which have morphed into de-facto operating systems, or messaging apps which have become social media platforms. Creations like these are a result of the current software development ecosystem in which a team of developers, a company, or a single person has virtually complete control over the direction and featureset of that piece of software. Those who come to depend on that software are at the mercy of those developers and have no choice but to suffer when those developers inevitably add extra features which introduce more bugs and more issues and change the experience of using the software. This is an ecosystem in which software has owners and users of the software must either
-
-It would mean writing software to be as hackable as possible. Allowing for both extensibility and core modifications. It means writing software in a way that is easy to read, understand, and maintain not only for yourself but also for others.
-
-> “Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.”
-> -- Brian Kernighan
-
-By all accounts this is not a new idea; aspects of this philosophy have existed since the early days of programming and are observed by other disciplines. For example, it's well understood in the gaming industry, that it is impossible to make a game for everybody. The more features are added with the goal of appeasing every person's preferences, the harder the game is to understand and the more of a muddy, confusing mess it becomes for players. Others have also come up with similar manifestos and philosophies. Edsger Dijkstra spoke about this very thing in his 1972 ACM Turing Award Lecture _The Humble Programmer_[CITE]. Both the Malleable Systems[malleablesystems] and Trivial Technologies[trivialtechnologies] manifestos espouse similar ideals. Trivial Technology:
+Well, to start, the fact of the matter is that as a civilization we simply do
+not need massive kernels which handle absolutely everything in a system, web
+browsers which have morphed into de-facto operating systems, or messaging apps
+which have become social media platforms. Creations like these are a result of
+the current software development ecosystem in which a team of developers,
+a company, or a single person has virtually complete control over the direction
+and featureset of that piece of software. Those who come to depend on that
+software are at the mercy of those developers and have no choice but to suffer
+when those developers inevitably add extra features which introduce more bugs
+and more issues and change the experience of using the software. This is an
+ecosystem in which software has owners and users of the software must either
+
+It would mean writing software to be as hackable as possible. Allowing for both
+extensibility and core modifications. It means writing software in a way that
+is easy to read, understand, and maintain not only for yourself but also for
+others.
+
+> “Debugging is twice as hard as writing the code in the first place.
+Therefore, if you write the code as cleverly as possible, you are, by
+definition, not smart enough to debug it.” > -- Brian Kernighan
+
+By all accounts this is not a new idea; aspects of this philosophy have existed
+since the early days of programming and are observed by other disciplines. For
+example, it's well understood in the gaming industry, that it is impossible to
+make a game for everybody. The more features are added with the goal of
+appeasing every person's preferences, the harder the game is to understand and
+the more of a muddy, confusing mess it becomes for players. Others have also
+come up with similar manifestos and philosophies. Edsger Dijkstra spoke about
+this very thing in his 1972 ACM Turing Award Lecture _The Humble
+Programmer_[CITE]. Both the Malleable Systems[malleablesystems] and Trivial
+Technologies[trivialtechnologies] manifestos espouse similar ideals. Trivial
+Technology:
> is a new way of doing FOSS, whose goal is to maximally empower the individual by providing a stepping stone for whatever they may wish to build.
And the Malleable Systems philosophy is:
-> Software must be as easy to change as it is to use it.
-> All layers, from the user interface through functionality to the data within, must support arbitrary recombination and reuse in new environments.
-> Tools should strive to be easy to begin working with but still have lots of open-ended potential.
-> People of all experience levels must be able to retain ownership and control.
+> Software must be as easy to change as it is to use it. > All layers, from the
+user interface through functionality to the data within, must support arbitrary
+recombination and reuse in new environments. > Tools should strive to be easy
+to begin working with but still have lots of open-ended potential. > People of
+all experience levels must be able to retain ownership and control.
> Recombined workflows and experiences must be freely shareable with others.
-> Modifying a system should happen in the context of use, rather than through some separate development toolchain and skill set.
-> Computing should be a thoughtfully crafted, fun, and empowering experience.
+> Modifying a system should happen in the context of use, rather than through
+some separate development toolchain and skill set. > Computing should be
+a thoughtfully crafted, fun, and empowering experience.
Not doing this causes struggles which even the IETF has noticed. One development group simply cannot take into account the needs of all users of the technology they develop.
[https://datatracker.ietf.org/doc/html/rfc8890#section-4](https://datatracker.ietf.org/doc/html/rfc8890#section-4)
-In fact, abstraction is the wrong word to refer to libraries as they are used today since most libraries are treated as black boxes; as services which someone else wrote for you that you don't have to think about at all. When it boils down to it, libraries and web APIs aren't really that different in terms of how they are used by software developers. You have allowed someone else to think about the details of whatever the library does and deferred not only that burden to them, but also a great deal of knowledge about how that library influences and shapes your program and control over that aspect of your program. vendor libraries, you should be responsible for maintaining a library someone made if you use it in your program, it is a utility, not an API.
-
-This ties in with the notion that software should be simple and perform one task or one logical grouping of tasks well. Writing the tool you want to fulfill just your needs ensures that the software remains simple and easy for one person to grasp. It should be simple enough that a single human can hold all the code in their head and know exactly which parts do what. Failing that, it should be broken up into a base system with an API/ABI and a set of plugins/modules/extensions such that each part can be understood on its own, like a lamp can be understood independently of the electrical grid. This is called human scale software.[humanscale]
-
-Also, in open source you are not beholden to the people for whom you create things. Just because there are people who use your software doesn't mean you automatically become a slave to their wants and desires. [need to talk more about this philosophy and how FOSS doesn't solve it]
+In fact, abstraction is the wrong word to refer to libraries as they are used
+today since most libraries are treated as black boxes; as services which
+someone else wrote for you that you don't have to think about at all. When it
+boils down to it, libraries and web APIs aren't really that different in terms
+of how they are used by software developers. You have allowed someone else to
+think about the details of whatever the library does and deferred not only that
+burden to them, but also a great deal of knowledge about how that library
+influences and shapes your program and control over that aspect of your
+program. vendor libraries, you should be responsible for maintaining a library
+someone made if you use it in your program, it is a utility, not an API.
+
+This ties in with the notion that software should be simple and perform one
+task or one logical grouping of tasks well. Writing the tool you want to
+fulfill just your needs ensures that the software remains simple and easy for
+one person to grasp. It should be simple enough that a single human can hold
+all the code in their head and know exactly which parts do what. Failing that,
+it should be broken up into a base system with an API/ABI and a set of
+plugins/modules/extensions such that each part can be understood on its own,
+like a lamp can be understood independently of the electrical grid. This is
+called human scale software.[humanscale]
+
+Also, in open source you are not beholden to the people for whom you create
+things. Just because there are people who use your software doesn't mean you
+automatically become a slave to their wants and desires. [need to talk more
+about this philosophy and how FOSS doesn't solve it]
[https://lucumr.pocoo.org/2022/7/9/congratulations/](https://lucumr.pocoo.org/2022/7/9/congratulations/)
[https://www.b-list.org/weblog/2022/jul/11/pypi/](https://www.b-list.org/weblog/2022/jul/11/pypi/)
-This results in simpler software that is easier to maintain, learn, and develop. Simpler software means fewer security holes and fewer things that can break (minimizes the “this is broken for no reason!” moments).
-
-Computer software should be generally single-purpose. Objects which have computers in them but for which the computer is not the totality should have special, purpose-built software, not general purpose kernels or software stacks treated like black boxes. Not only does this make such a stack likely simpler to capture in the brain, but also should limit maintenance burden in the future due to minimal dependencies and a simpler, smaller codebase. Yes, this does have a much higher upfront cost, but the long run is a more diverse, healthier software ecosystem where more people are empowered to mold their computers to fit their needs. The goal of this philosophy is to make software simpler, easier to understand and manage, and more approachable for everyone.
-
-You should build tools yourself that suits your needs. These days, this is most commonly seen with many hackers who have their own personal websites. Many, such as myself, don't feel like existing static site generators or content management systems fit their needs so we build our own. In my case, my static site generator is built to do only what I need out of my site, and nothing else. Because it is a shell script of a couple hundred lines long with very clear workings, it's easy for someone to take my static site generator, tear out the parts they don't need, and shove in some new functionality they do need. Perhaps they want to add automatic Gemini→Gopher & HTML generation. They absolutely could do that, and there's no need for me to write a large program to accommodate needs I don't have. Here are some great examples of people who have done something similar: [My Website is One Binary — j3s.sh](https://j3s.sh/thought/my-website-is-one-binary.html), [Oscean - wiki.xxiivv.com](https://wiki.xxiivv.com/site/oscean.html).
-
-In conclusion, the overarching theme of this philosophy is that you, as a developer or a user of software, should create or modify software to fits your needs or the needs of your community, and not anyone else. That means not taking feature requests that don’t align with your intended vision, not adding features that you don't need but someone else wants, and making it as easy as possible to fork and modify your software so that others can do the same without needing to come to you. Let those other people fork your project and do the work to make the software fit their needs, instead of trying to fit their needs into your software. When possible, design from the ground up. You can reuse existing code or make libraries out of the things you write, but don’t rely on abstractions to take care of absolutely everything for you. Expose the inner workings of your programs to developers wherever possible. Keep the human in the loop.
+This results in simpler software that is easier to maintain, learn, and
+develop. Simpler software means fewer security holes and fewer things that can
+break (minimizes the “this is broken for no reason!” moments).
+
+Computer software should be generally single-purpose. Objects which have
+computers in them but for which the computer is not the totality should have
+special, purpose-built software, not general purpose kernels or software stacks
+treated like black boxes. Not only does this make such a stack likely simpler
+to capture in the brain, but also should limit maintenance burden in the future
+due to minimal dependencies and a simpler, smaller codebase. Yes, this does
+have a much higher upfront cost, but the long run is a more diverse, healthier
+software ecosystem where more people are empowered to mold their computers to
+fit their needs. The goal of this philosophy is to make software simpler,
+easier to understand and manage, and more approachable for everyone.
+
+You should build tools yourself that suits your needs. These days, this is most
+commonly seen with many hackers who have their own personal websites. Many,
+such as myself, don't feel like existing static site generators or content
+management systems fit their needs so we build our own. In my case, my static
+site generator is built to do only what I need out of my site, and nothing
+else. Because it is a shell script of a couple hundred lines long with very
+clear workings, it's easy for someone to take my static site generator, tear
+out the parts they don't need, and shove in some new functionality they do
+need. Perhaps they want to add automatic Gemini→Gopher & HTML generation. They
+absolutely could do that, and there's no need for me to write a large program
+to accommodate needs I don't have. Here are some great examples of people who
+have done something similar: [My Website is One Binary
+— j3s.sh](https://j3s.sh/thought/my-website-is-one-binary.html), [Oscean
+- wiki.xxiivv.com](https://wiki.xxiivv.com/site/oscean.html).
+
+In conclusion, the overarching theme of this philosophy is that you, as
+a developer or a user of software, should create or modify software to fits
+your needs or the needs of your community, and not anyone else. That means not
+taking feature requests that don’t align with your intended vision, not adding
+features that you don't need but someone else wants, and making it as easy as
+possible to fork and modify your software so that others can do the same
+without needing to come to you. Let those other people fork your project and do
+the work to make the software fit their needs, instead of trying to fit their
+needs into your software. When possible, design from the ground up. You can
+reuse existing code or make libraries out of the things you write, but don’t
+rely on abstractions to take care of absolutely everything for you. Expose the
+inner workings of your programs to developers wherever possible. Keep the human
+in the loop.
[https://actsofvolition.com/2004/04/theriseof/](https://actsofvolition.com/2004/04/theriseof/)
diff --git a/content/now.md b/content/now.md
@@ -6,9 +6,34 @@ Summary: This is a now page. I'm using it a bit like a monthly log where it desc
This is my monthly log. It describes what I've been up to recently and what I'm
currently working on. [Learn more about now pages here](https://nownownow.com/about).
+* [March 2023](#march-2023)
* [February 2023](#february-2023)
* [January 2023](#january-2023)
+## March 2023
+
+Another month, another update.
+
+This month saw the release of two blog posts, one on [styling external
+links](/blog/styling-external-links), and another on running [OpenBSD on the
+Dell XPS 13 9380](blog/openbsd-on-the-dell-xps-13-9380). The replacement
+battery for the XPS still hasn't arrived, but it should be here sometime this
+month. I'm looking forward to being able to use this laptop portably.
+
+In the meantime, I've been rummaging around in the OpenBSD codebase trying to
+figure out the peculiar issue of the laptop not resuming properly after
+suspending when two devices which are handled by the same driver are enabled at
+the same time. No luck yet, but given my unfamiliarity with the codebase and
+the difficulty of debugging the issue, I'm not surprised.
+
+I've also been doing the usual editing for the [Linux
+Lads](https://linuxlads.com/) podcast, and I'm very happy how one of the
+[recent episodes](https://linuxlads.com/episodes/98) turned out in which the
+lads interviewed Gabe Kangas, the creator of
+[Owncast](https://owncast.online/).
+
+That's all for this month. Bye for now!
+
## February 2023
This month continued the theme of the previous month with changes to the
