RFCs now use unicode rather than ASCII. I've been printing RFCs to read them for decades, when I did it last week the result didn't look pretty.
I found a new tool, u2ps, that almost does what a2ps and enscript do not. I had to make one small change, to make it interpret the form feeds in RFCs, then it worked exactly as I needed.
The script I use wraps u2ps to print RFCs double-sided, two RFC pages per A4 page (four per sheet). At heart it's like this short unix command:
u2ps -k -M A4 -s 11.5 --header-right=''
| psnup -2 2>/dev/null
| lpr -o sides=two-sided-long-edge
John Gruber wrote about Richard Stallman's disgraceful behaviour in September 2019 and again two weeks later. Read that, and maybe the original article too. This isn't about Stallman though, it's about the correction, so today the original article is a digression.
I quote the correction from the original article: [UPDATE 7 OCTOBER 2019: Please read this correction regarding an erroneous allegation originally contained in, but now removed from, this article.]
That's the way to do it. I think that's the best correction I've seen on the web; frank about what the mistake was and that it was a mistake, frank about how and why it happened, apologetic, frank about what changes were made to the original blog posting to correct the mistake, posted as a separate article so it would be on the top of the home page for a while, and last but not least, with links in both directions.
Yes, I post this today because I'm annoyed about a different correction on another site.
I quote one of the Economist editors on their writing/linking policy: That’s the same that we do in the weekly as well — we’re not big on linking out. And it’s not because we’re luddites, or not because we don’t want to send traffic to other people. It’s that we don’t want to undermine the reassuring impression that if you want to understand Subject X, here’s an Economist article on it — read it and that’s what you need to know. And it’s not covered in links that invite you to go elsewhere. We’ll link to background, and we’ll link to things like white papers or scientific papers and stuff like that. The idea of a 600-word science story that explains a paper is that you only need to read the 600-word science story — you don’t actually have to fight your way through the paper. There is a distillation going on there.
(Emphasis mine.)
The same applies to technical documentation: Stick to your subject and document that. Background information is often a digression. It adds bulk, it adds information that someone may appreciate, but quite often it adds no information that you want to convey.
How can you tell whether it's a digression in any single case? If you define the audience and goal of your text, then the goal typically answers that question. Either the text in question helps your specified audience towards the specified goal, or else it's a digression.
The digression may be something you should link to.
It's still light outside, we've time for another beer.
The photo was taken four hours after sunset.
The simplest form of question is a yes/no question. How many kinds of answers does that permit?
There are eight kinds, as I count them. There's yes
and no
, including lookalikes like yes, in my opinion
or most probably yes
. This is about kinds of answers, not details.
Three more kinds of straight answers: neither
, both
and not 100% straight, it depends
. (Some yes/no questions don't allow neither/both.)
The sixth kind is to talk about the question, for example you've heard a politician say that's a really interesting question
and […More…]
A Huawei employee suggested to me that the Matebooks would be good for my kind of use. I want something small enough to fit comfortably on my lap, and I use the laptop as a terminal and text editor. I took his advice, bought the 2022 16GB 13" model, and it's great.
What a keyboard, what a screen, what a touchpad, what perfect linux support. That's all I have to say.
Update: The fingerprint reader is not supported by libfprint. […More…]
Or: Leveraging Schopenhauer's book of dirty tricks in agile software development.
This rather lengthy posting started when I read Schopenhauer's little book about rhetoric. The book is great, I particularly like the smoothly satirical preface. He describes about forty dirty tricks, and as I read I realised that I've heard every single trick in scrum meetings etc. I think some of my past colleagues would nod as they read Schopenhauer's preface: Nobody absolutely knows yet, but later, with the benefit of hindsight it may become clear that I was right today, so it's best for everyone if I have my way in this meeting.
Rhetoric (/ˈrɛtərɪk/) is the art of persuasion
is Wikipedia's first sentence on the subject. When people use the word, they often don't use it to mean exactly that, though. Sometimes it means an argument
or an opinionated statement
, sometimes a choice of phrasing
, sometimes wording with more elegance than substance
, and quite often the word rhetoric is used to mean any device that's used to win a discussion except by achieving a shared understanding of the subject matter.
That isn't what Aristotle had in mind. I don't think Aristotle ever used dirty tricks such as the door in the face, the Gish gallop, guilt by association, or making jokes about other participants in a discussion.
Books on rhetoric study, analyse, categorise and explain rhetorical devices, which are means to persuade, or if not persuade, at least to carry a meeting. Today I want to speechify a bit about using the same field of study, these same devices, in three other ways: ⓐ Listening more attentively to what others are saying, noticing unfair rhetoric, ⓑ countering or neutering that unfair rhetoric, and ⓒ staying fair.
Below you'll find Schopenhauer's dirty rhetorical tricks, grouped and worded as I see it. I describe each (fairly or unfairly), mention an agile software example to help you learn to notice it when someone uses that dirty trick, and if I can, I write a bit about how to counter that trick while staying fair and within a normal software development context. […More…]