swf.wtf(1) — About

swf.wtf(1) User Commands swf.wtf(1)

Name

swf.wtf — a blog about Linux, developer tooling, and things that should be simpler than they are

Synopsis

swf.wtf [--read post] [--rant topic] [--footnote-count N] [--coffee] [--no-bullshit]

Description

swf.wtf is a personal technical blog operated by a human being who uses Fedora Linux by choice — and yes, that sentence does contain a certain amount of implied personality. It publishes guides, notes, and opinions about software development, Linux, and the specific kind of low-grade institutional frustration that accumulates when you spend enough time reading documentation that was clearly written by someone who understood the subject so completely that they forgot what it was like not to.

Posts on swf.wtf attempt to be technically accurate, occasionally funny, and — this is the part that distinguishes them from approximately forty percent of the internet — honest about when something is genuinely annoying.^[1] The working assumption is that you are an adult who can handle sentences that contain both a git rebase command and an opinion about it.

The name swf.wtf is not explained here. This is intentional. It is, however, pronounced however you want to pronounce it, because the author lacks both the authority and the desire to police that.^[2]

Options

--read post

The primary function. Posts cover Linux configuration, developer tooling, CLI workflows, and whatever else has recently caused the author to stare at a terminal for twenty minutes before discovering the solution was a single environment variable. Written with the assumption that you know what a terminal is but not the assumption that you've memorised every flag of every command.

--rant topic

Some posts contain digressions. These digressions are clearly labelled and entirely optional, but they are also correct, so you should probably read them. Topics include but are not limited to: outdated documentation that hasn't been updated since 2019, software that adds a GUI to something that did not require a GUI, and the specific emotional experience of an error message that is technically accurate but provides zero actionable information.^[3]

--footnote-count N

Posts on this site contain footnotes. More footnotes than are strictly necessary. This is a feature, not a bug. The footnotes are where things that are true but would disrupt the flow of the main text go to live. They deserve to exist. They have been through enough.^[4]

--coffee

Most content was produced between the hours of 9pm and 1am, which explains both the quality of the writing and the intensity of the opinions. This flag cannot be disabled.

--no-bullshit

Enabled by default. Guides include TL;DR sections for the impatient and full explanations for the curious. Affiliate links: zero. Sponsored content: none. Introductory paragraphs explaining what SSH is before getting to the actual SSH guide: kept to a minimum, despite the temptation.^[5]

Author

A person. Specifically, a person who runs Fedora Linux on their primary machine, uses the terminal for tasks that could technically be accomplished with a GUI but aren't, and has opinions about SSH key algorithms that are, frankly, completely proportionate to the situation and not at all excessive.

Professional background: software. Specific details: deliberately omitted, because the about page of a personal blog is not a LinkedIn profile and the author would like to keep it that way. What you need to know is that the technical content is written from experience, not from reading three Stack Overflow answers and synthesising them into false confidence.^[6]

The author's relationship with Linux began the way most people's relationships with Linux begin: with an Ubuntu live USB, an afternoon of ambient overconfidence, and the slowly dawning realisation that the Wi-Fi driver situation was going to require a second laptop to resolve. Things have improved substantially since then. The opinions have only deepened.

Note — On the choice of Fedora Fedora was chosen after extensive use of Ubuntu (fine, opinionated in ways that occasionally conflict with the user's opinions), Arch (excellent, requires the kind of ongoing maintenance commitment usually reserved for vintage motorcycles), and Debian (stable in the way that a geological formation is stable — technically admirable, practically inconvenient when you need software from this decade). Fedora sits at a point on the stability/freshness curve that suits the author's temperament. This note exists because the author has been asked about the distro choice before and would like to answer it once, here, in a footnote-adjacent block, rather than in every comment section for the rest of the blog's existence.^[7]

Environment

Fedora Linux (current release). Updated regularly. Occasionally broken by an update and then fixed within twenty minutes, which the author considers an acceptable trade-off for having current software.

EDITOR

Set to something reasonable. The editor wars will not be relitigated here. Both sides have made their arguments. The arguments are well known. The author has chosen. The choice will not be disclosed because the author values their inbox.^[8]

SHELL

zsh. It's on the machine, it has good completion, and the prompt customisation is worth the ten minutes of configuration. bash remains the correct answer for scripts you intend to share with other people's machines, which is a different question.

TERMINAL

Something that renders colour and doesn't fight with tmux. That's the entire specification. The author has stopped having strong feelings about terminal emulators because there is a finite number of hours in a life.

COFFEE

Present. Non-negotiable. Not a personality trait, just a practical dependency that has been in the requirements file for long enough that removing it would constitute a breaking change.

Return Value

You read the post, the command worked, you learned something, life is marginally better. This is the desired outcome and the author is pleased.

Something in the guide didn't work on your specific setup. This is not necessarily anyone's fault. Linux is a broad church. File a mental note, check the footnotes, try the thing that's slightly different about your system.

You disagree with one of the opinions. That's fine. The opinions are offered freely and with the understanding that reasonable people can disagree. Unreasonable people can also disagree but they tend to do so at higher volume and the author has muted that frequency.

127

Command not found. You're probably looking for a post that doesn't exist yet. Check back. It's likely in a draft state somewhere, half-finished, waiting for the author to stop second-guessing the third paragraph.

SIGINT

You got halfway through a post and had to go do something else. The post will still be here. The author does not take this personally. Much.

Bugs

Technical errors, factual inaccuracies, and commands that have stopped working because a package maintainer decided to change the flag syntax without telling anyone — these are bugs, and the author wants to know about them. The method for reporting them is: write a message, send it somehow, be specific about what broke and how. This process is deliberately unstructured because the author has watched elaborate bug reporting systems get adopted, ignored, and eventually abandoned by projects that would have been better served by a simple email address.

Opinions you disagree with are not bugs. Jokes that didn't land are not bugs, though the author accepts that they represent a form of failure. Footnotes that are longer than the main text they annotate are a documented feature and will not be patched.

See Also

swf.wtf — home
fedora-setup(7) — Fedora × Omakub setup guide
sql-guide(1) — Oracle 19c + MySQL study notes
coding-with-ai-agents(1) — Claude AI, Claude Code, and Codex guide
git-guide(1) — Git from Zero beginner guide
github-ssh-linux(1) — SSH keys on Linux
now(1) — what I'm currently up to
steven@swf.wtf — contact
github.com/StevenWFry — source code
@swfwtf@mastodon.social — Mastodon

Footnotes

[1] The forty percent figure is approximate. The actual figure for "internet content that accurately reflects the emotional experience of doing the thing it describes" is difficult to measure, but any developer who has read a tutorial that described a complex multi-step process as "simply" or "just" doing something knows the feeling of being lied to by an adverb. This blog attempts to use the word "simply" only when the thing is, demonstrably, simple. Which is less often than you might hope.

[2] Current leading pronunciations observed in the wild include "swiff dot what the f", "swuff dot wtf" (treating wtf as an initialism within a domain that is itself an initialism, which is a level of recursive obscurity the author finds endearing), and simply reading out the URL letter by letter, which takes longer but has an undeniable precision to it. All are accepted. None are wrong. This is the one area of this blog where there is no opinion.

[3] "No such file or directory" is perhaps the most technically accurate and least useful error message in the history of computing. Yes. That has been established. The file is not there. What would be helpful is knowing whether it was never there, was there and was deleted, was there under a different name, or requires a package that wasn't installed. The operating system knows some of these things. It has chosen not to share them. This represents a philosophical position about user relationships with their tools that the author disagrees with, at length, usually at around 11pm.

[4] The footnotes are not an affectation. They are a structural solution to a genuine problem: technical writing contains information that is true and relevant but would derail the main argument if inserted inline. The alternatives are: omit the information (bad), include it anyway and lose the reader (also bad), or put it in a footnote where it can be found by those who want it and ignored by those who don't (good). David Foster Wallace used footnotes. Legal documents use footnotes. The author is in acceptable company, is the point.

[5] The introductory paragraph explaining what SSH is before an SSH guide is a genuine temptation, because it pads the word count, signals thoroughness, and provides an on-ramp for beginners. The problem is that anyone who needs SSH explained from first principles is probably not yet at the stage where this specific guide is useful to them, and anyone who is at that stage does not need three paragraphs explaining that SSH stands for Secure Shell and was designed by Tatu Ylönen in 1995. The author has made peace with not being all things to all readers.

[6] The "three Stack Overflow answers synthesised into false confidence" method of technical writing is more prevalent than the industry would like to admit. It produces content that is plausible, internally consistent, and wrong in ways that only become apparent when you try to follow it on a slightly different system configuration than the one the author used. The author has made this mistake. The author is not proud of it. The author now runs the commands before publishing them, which is the minimum viable standard and yet somehow distinguishes this blog from a meaningful portion of its competition.

[7] The distro choice note will not, in fact, prevent the question from appearing in comment sections. Nothing prevents a question from appearing in a comment section. The internet is a place where questions arrive regardless of whether they have already been answered, often with the energy of someone who believes they are the first person to have ever thought of asking. The author has made peace with this too. There is a lot of peace-making involved in maintaining a public presence on the internet. It is, in many ways, a practice in radical acceptance.

[8] The editor wars — specifically the vim versus emacs debate, which has been ongoing since approximately 1985 and shows no signs of resolution — represent one of the most sustained examples of human beings arguing about a preference as though it were a moral position. Both editors are good. Both communities contain people who are unreasonable about this in ways that suggest the editor preference is doing a lot of emotional heavy lifting. The author's choice is made, is comfortable, and is staying private, in the same way that one's vote is private: not because it is shameful, but because announcing it solves nothing and invites everything.

[9] The bash manual is 184 pages in its PDF form, which is remarkable for a program whose core value proposition is "runs commands in sequence." This is not a criticism. The feature set is genuinely extensive and much of it is useful. It is, however, a reminder that the tools we think of as simple — the ones we use without thinking, the ones that feel like furniture — often contain entire architectural philosophies that we have never examined. The author finds this humbling and occasionally terrifying in roughly equal measure.