Forem: Tomáš Janoušek

Even faster bash startup

Tomáš Janoušek — Wed, 25 Nov 2020 00:00:00 +0000

I sped up bash startup from 165 ms to 40 ms. It’s actually noticeable. Why and how did I do it?

Motivation
Investigation
- man
- death by a thousand cuts
- completions
- fzf
- are we done yet?
- history
Conclusion
Update 1: Why not fix typing before the prompt instead?

Motivation

Whenever I need to quickly look something up (or use a calculator), I open a new terminal (using a keyboard shortcut) and start typing into it. Slow bash startup disrupts this workflow as I would often type before the shell prompt:

Daniel Parker recently wrote an excellent blog post Faster Bash Startup detailing his journey from 1.7 seconds to 210 ms. I start at 165 ms and need to go significantly lower than Daniel, therefore different techniques will be needed.

Investigation

hyperfine is a brilliant command-line tool for benchmarking commands that I discovered recently (thanks to Daniel!), so let’s see where we are now:

[tomi@notes ~]$ hyperfine 'bash -i'
Benchmark #1: bash -i
  Time (mean ± σ): 165.8 ms ± 0.7 ms [User: 156.3 ms, System: 12.8 ms]
  Range (min … max): 164.9 ms … 167.1 ms 17 runs

Now we need to find out what’s taking so long. How to profile a bash shell script slow startup? Most Stack Overflow answers suggest some variant of set -x, which will help us find any single command that takes unusually long.

man

In my case, that command was man -w, specifically this piece of my .bashrc.d/10_env.sh:

export MANPATH=$HOME/.local/share/man:
# FIXME: workaround for /usr/share/bash-completion/completions/man
MANPATH=$(man -w)

Turns out none of this is needed any more, man and manpath now add ~/.local/share/man automatically so I can just drop it and save more than 100 ms¹.

death by a thousand cuts

But that’s it. No other single command stands out, it’s just a lot of small things that add up. Daniel says “it has to take some time,” and he’s mostly right, but I still have one trick up my sleeve.

My .bashrc is split into several smaller parts in ~/.bashrc.d, so I can profile these and see if anything stands out. My .bashrc thus becomes:

for i in ~/.bashrc.d/*.sh; do
    if [[$__bashrc_bench]]; then
        TIMEFORMAT="$i: %R"
        time . "$i"
        unset TIMEFORMAT
    else
        . "$i"
    fi
done; unset i

Let’s see what happens…

[tomi@notes ~]$ __bashrc_bench=1 bash -i
/home/tomi/.bashrc.d/10_env.sh: 0,118
/home/tomi/.bashrc.d/20_history.sh: 0,000
/home/tomi/.bashrc.d/20_prompt.sh: 0,002
/home/tomi/.bashrc.d/30_completion_git.sh: 0,000
/home/tomi/.bashrc.d/31_completion.sh: 0,011
/home/tomi/.bashrc.d/50_aliases.sh: 0,002
/home/tomi/.bashrc.d/50_aliases_sudo.sh: 0,000
/home/tomi/.bashrc.d/50_functions.sh: 0,001
/home/tomi/.bashrc.d/50_git_dotfiles.sh: 0,008
/home/tomi/.bashrc.d/50_mc.sh: 0,000
/home/tomi/.bashrc.d/90_fzf.sh: 0,011

118 ms in 10_env.sh was caused by man -w and we know what to do with that.

completions

11 ms in 31_completion.sh which loads bash-completion. That’s certainly better than Daniel’s 235 ms, probably because up-to-date bash-completion only loads a few necessary completions and defers everything else to being loaded on demand. I couldn’t live without the completions, so 11 ms is a fair price.

8 ms for 50_git_dotfiles.sh, which defines a few aliases and sets up git completions for my git-dotfiles alias, seems too much, though. Good news is that we don’t need to drop this. We can use bash-completion’s on-demand loading. Whenever completions for command cmd are needed for the first time, bash-completion looks for ~/.local/share/bash-completion/completions/cmd or /usr/share/bash-completion/completions/cmd.

Therefore, ~/.local/share/bash-completion/completions/git-dotfiles becomes:

. /usr/share/bash-completion/completions/git
complete -F _git git-dotfiles

fzf

90_fzf.sh loads key bindings and completions code so that fzf is used when searching through history, completing ** in filenames, etc. Well worth the 11 ms it needs to load².

are we done yet?

After these changes, I got:

[tomi@notes ~]$ __bashrc_bench=1 bash -i
/home/tomi/.bashrc.d/10_env.sh: 0,001
/home/tomi/.bashrc.d/20_history.sh: 0,000
/home/tomi/.bashrc.d/20_prompt.sh: 0,002
/home/tomi/.bashrc.d/30_completion_git.sh: 0,000
/home/tomi/.bashrc.d/31_completion.sh: 0,012
/home/tomi/.bashrc.d/50_aliases.sh: 0,002
/home/tomi/.bashrc.d/50_aliases_sudo.sh: 0,000
/home/tomi/.bashrc.d/50_functions.sh: 0,001
/home/tomi/.bashrc.d/50_git_dotfiles.sh: 0,000
/home/tomi/.bashrc.d/50_mc.sh: 0,000
/home/tomi/.bashrc.d/90_fzf.sh: 0,011

That’s 29 ms, brilliant! Or… is it? 🤔

[tomi@notes ~]$ hyperfine 'bash -i'
Benchmark #1: bash -i
  Time (mean ± σ): 55.7 ms ± 1.0 ms [User: 47.6 ms, System: 11.1 ms]
  Range (min … max): 54.8 ms … 58.9 ms 53 runs

history

Some of those additional 26 ms are spent reading my huge (HISTSIZE=50000) .bash_history file. I will skip the details about how I investigated this, because I didn’t: I stumbled upon this by chance while testing something else.

We can see that using an empty history file brings us down to a little under 40 ms:

[tomi@notes ~]$ HISTFILE=/tmp/.bash_history_tmp hyperfine 'bash -i'
Benchmark #1: bash -i
  Time (mean ± σ): 38.6 ms ± 0.7 ms [User: 34.0 ms, System: 7.8 ms]
  Range (min … max): 37.8 ms … 42.3 ms 75 runs

Now, cutting 17 ms by sacrificing the shell history is probably not a good deal for most people. I settled for setting up a systemd timer to back up .bash_history to git once a day and lowered HISTSIZE to 5000³. This still keeps my bash startup below 40 ms:

[tomi@notes ~]$ hyperfine 'bash -i'
Benchmark #1: bash -i
  Time (mean ± σ): 39.9 ms ± 0.5 ms [User: 36.1 ms, System: 6.8 ms]
  Range (min … max): 39.1 ms … 42.1 ms 73 runs

Conclusion

By dropping unnecessary invocation of man -w, deferring loading of git completions to when they’re needed, and shortening my shell history file, I managed to speed up bash startup from 165 ms to 40 ms.

Benchmark #1: bash -i
  Time (mean ± σ): 165.8 ms ± 0.7 ms [User: 156.3 ms, System: 12.8 ms]
  Range (min … max): 164.9 ms … 167.1 ms 17 runs

Benchmark #1: bash -i
  Time (mean ± σ): 39.9 ms ± 0.5 ms [User: 36.1 ms, System: 6.8 ms]
  Range (min … max): 39.1 ms … 42.1 ms 73 runs

More importantly, I no longer type before the prompt, even if I try!

And at this point I can finally agree with Daniel that further tweaking will only have diminishing returns⁴. 😊

Update 1: Why not fix typing before the prompt instead?

Redditor buttellmewhynot (pun intended) comments:

I feel like it shouldn't matter that the shell starts with a delay. If you start a shell, the computer should assume that you want further input directed there and queue somewhere to send it to the shell when it's up.

I understand that there's probably a lot of weird quirks about how terminals and shells work and how processes get created but surely there's a way to do this.

They're right on both points. The input is queued somewhere, and there is a way to fix the messed up prompt. As some might suspect, zsh handles it fine: try running sleep 5 and type some input in the meantime:

zsh	bash

pending input handling without custom prompt

We can see that:

in all cases, the input appears twice (bit annoying, but tolerable)
zsh prompt is never messed up
bash prompt is messed up if there's no newline after the input⁵
no input is discarded, in contrast to the first image of this post

Turns out my PROMPT_COMMAND which was meant to ensure the prompt always starts on new line was discarding the pending input. Zsh uses a different approach, printing $COLUMNS spaces and then a carriage return (explanation), which I don't like as it messes up copy/paste. But I managed to improve my solution to correctly detect pending input and not discard it.

It's not perfect (so I'll still try to keep bash startup fast), but it's definitely an improvement, and it will be useful whenever I get impatient with a slow command and start typing the next command before the prompt appears.

Thank you buttellmewhynot for nudging me in the correct direction.

At the time of publishing this post, man -w no longer takes 100+ ms thanks to several performance improvements in libseccomp ↩
At the time of publishing this post, the latest fzf release (0.24.3) loads twice as long (20+ ms). I fixed this in #2246 and #2250, but it might take a short while to be released and find its way to distributions. ↩
5000 is a bit limiting in practice, as it rolls over in a few weeks. In 2020, you’d expect your shell to keep unlimited history without slowdown. I will address this in another post soon. ↩
Some people may be even more sensitive to latency than me, but measurements by Dan Luu suggest that at this scale there are other bottlenecks: Computer latency, Keyboard latency. ↩
GNU Readline assumes the prompt starts in the first column so it gets more messed up later e.g. when walking through history using ↑/↓. ↩

A better xrandr command-line experience

Tomáš Janoušek — Sun, 11 Oct 2020 00:00:00 +0000

Can we make a small improvement to xrandr command-line user experience so that extra tools like arandr (GUI for xrandr) or autorandr become unnecessary for some people (like me)? Yes, I think that making the --output option a bit more powerful goes a long way, and lets me cover most use-cases with just four shell functions/aliases.

function layout-vertical {
  xrandr-smart --output 'eDP-*' --auto \
               --output '!(eDP-*)' --auto --above 'eDP-*'
}
function layout-horizontal {
  xrandr-smart --output 'eDP-*' --auto \
               --output '!(eDP-*)' --auto --right-of 'eDP-*'
}
function layout-clone {
  xrandr-smart --output 'eDP-*' --auto \
               --output '!(eDP-*)' --auto --same-as 'eDP-*'
}
function layout-extonly {
  xrandr-smart --output '!(eDP-*)' --auto
}

functions/aliases I wish I could have

TL;DR
What? Why?
Behind the scenes
Limitations
Future work

TL;DR

Grab it here: release branch, tarball.

What? Why?

The way monitor layouts work for most people with mainstream operating systems or desktop environments (like GNOME) is this: you connect an external monitor for the first time, your desktop expands to this monitor, then you can change its position or turn it off in the settings, and then this setup is remembered so that you don’t need to do it again the next time you connect it. People with non-mainstream X11 window managers (like xmonad, i3, awesomewm, fluxbox) can get a similar experience: arandr being the “settings UI” and autorandr handling the initial expansion, saving and restoring.

Still, many people don’t know about these tools, and just use plain xrandr, and then look a bit too nerdy when trying to connect to a projector at some meetup or conference. I’ve got to admit I used to be one of them: I had a script to handle external monitors at home/work, but connecting anything else was so unusual that I didn’t bother writing a script, and had to do it manually, and feel bad about myself afterwards.

This year I finally decided to do something about it. Not a big deal, right? Just adopt autorandr and be done with it. But the script is massive (1500 lines of code including various workarounds for X11 and driver bugs that are already fixed) and the format of its state/configuration files is undocumented, and that’s a bit of a red flag as I like to keep this stuff cleaned up and in version control. So I tried to think of something simpler.

The simple solution I came up with is to extend xrandr to allow shell globs as output names and disable unspecified outputs.

So instead of having several scripts like

layout-home-cz-hdmi

xrandr \
    --output HDMI-2 --mode 1920x1200 --pos 0x0 --dpi 96 \
    --output eDP-1 --mode 1920x1080 --pos 0x1200 --dpi 96 --primary

layout-home-uk-dock

xrandr \
    --output DP-2-1 --mode 1920x1080 --pos 0x0 --dpi 96 \
    --output eDP-1 --mode 1920x1080 --pos 0x1080 --dpi 96 --primary

now I just have

layout-vertical

xrandr-smart \
    --output 'eDP-*' --auto --dpi 96 --primary \
    --output '!(eDP-*)' --auto --above 'eDP-*' --dpi 96

and I think that’s beautiful.

The source for the xrandr-smart script as described is in my dotfiles monorepo, but the best way to obtain the most recent version of it is to use the standalone/xrandr-smart branch, which can also be downloaded as a tarball.

Behind the scenes

xrandr-smart invokes the xrandr-auto-find function which resolves output globs (if the globs match nothing or more than one output, it fails) and invokes the xrandr-auto-off functionto disable all other unspecific outputs.

As an example, layout-vertical might translate to:

xrandr-auto-off \
    --output eDP-1 --auto --dpi 96 --primary \
    --output HDMI-1 --auto --above eDP-1 --dpi 96
↓
xrandr \
    --output eDP-1 --auto --dpi 96 --primary \
    --output HDMI-1 --auto --above eDP-1 --dpi 96 \
    --output DP-1 --off \
    --output DP-2 --off \
    --output HDMI-2 --off

And that’s all there is to it, really.

Limitations

There are two significant limitations compared to GNOME and autorandr:

The generic layout-horizontal, layout-vertical scripts can only support the laptop panel and one external monitor. In reality, this isn’t a problem as triple head setups usual need fine-tuned positioning anyway.
We need extra code to support layout saving and (possibly automatic) restoring. Turns out that’s just a few lines: layout-auto, keybindings¹.

Future work

We could additionally use parse-edid to get monitor vendor and model and match against that as well. This could make xrandr-smart useful even in triple-head and non-laptop setups.

Yeah, I invoke this manually using a Fn-key combo. There’s an endless stream of bugs in the kernel, X server and GPU drivers, plus the occassional security issue in a screensaver, so I feel safer to just invoke it manually when I think everything is settled down. ↩

font-weight: 300 considered harmful (and a fontconfig workaround)

Tomáš Janoušek — Sat, 18 Jul 2020 00:00:00 +0000

Many web pages these days set font-weight: 300 in their stylesheet. With DejaVu Sans as my preferred font, this results in very thin and light text that is hard to read, because for some reason the “DejaVu Sans ExtraLight” variant (weight 200) is being used for weights < 360 (in Chrome; in Firefox up to 399). Let’s investigate why this happens and what can be done about it.

The Problem
MacOS font smoothing, CSS
Linux, fontconfig, CSS
The Solution
Appendix A: Why glob?

The Problem

Here’s what a test page looks like on my laptop (14” 1920x1080):

DejaVu Sans at different font-weights

For comparison, and possibly also as a clue as to why web designers use font-weight: 300, here’s a table of various font-weights of DejaVu Sans on my system and the default sans-serif font on MacOS Catalina and Android (unfortunately I don’t have any HiDPI laptop or low-DPI smartphone, so the comparison might be imprecise/unfair):

Boldness comparison¹ (scaled to equal height)

MacOS font smoothing, CSS

In MacOS, font-weight: normal looks almost bold, so web designers who use MacOS/Safari might use font-weight: 300 to compensate for this, ruining it for everybody else. :-(

Well, actually not everybody, as some desktop users (e.g. a Fedora Live DVD) won’t have an extra-light variant of sans serif, so the normal (regular, or book) variant will be used for all weights. But Android users and desktop users with DejaVu (used to be default on most Linux distributions, not sure what’s the current status) and possibly also Windows users are affected.

Nikita Prokopov suggested that disabling font smoothing in MacOS reduces the boldness, and my experiments confirm that. Furthermore, subpixel smoothing (antialiasing)² comes somewhere in the middle between the default and no smoothing (on my display).

Effect of disabling font smoothing in MacOS

Boldness comparison, this time with no smoothing in MacOS

Anyway, we can’t put all the blame on web designers. Matching an extra-light font with font-weight: 300 doesn’t seem to be a good idea, and matching it with font-weight: 350 is just plain silly (and I’d need to use explicit language to describe my feelings about Firefox using an extra-light font for font-weight: 399).

Actually, we can put all the blame on them, as font-weight: 300 has always (even in CSS Level 1) meant “lighter than normal, even if the only lighter font is weight 100.” Firefox’s behaviour of selecting an extra-light font for font-weight: 399 is in fact conforming to the most recent draft specification.

MacOS’ somewhat bolder rendering of normal-weight fonts is therefore a very weak excuse for using font-weight: 300, which literally forces the browser to not use a normal-weight font (or bolder) unless there is no other font available.

With that out of the way, let’s finally proceed to ~~fix~~ work around the problem, since persuading thousands of web developers to fix their websites doesn’t seem feasible at this point.

Linux, fontconfig, CSS

Font selection and appearance in Linux is highly configurable via fontconfig. That is both a curse and a blessing. In this case, it is quite advantageous.

There are a few handy command-line utilities which make it really easy to test the configuration. I’ll use fc-list and fc-match here to see what fonts I have and when DejaVu Sans ExtraLight is used:

$ fc-list | grep -F -w 'DejaVu Sans' | sort
/usr/share/fonts/truetype/dejavu/DejaVuSans-BoldOblique.ttf: DejaVu Sans:style=Bold Oblique
/usr/share/fonts/truetype/dejavu/DejaVuSans-Bold.ttf: DejaVu Sans:style=Bold
/usr/share/fonts/truetype/dejavu/DejaVuSansCondensed-BoldOblique.ttf: DejaVu Sans,DejaVu Sans Condensed:style=Condensed Bold Oblique,Bold Oblique
/usr/share/fonts/truetype/dejavu/DejaVuSansCondensed-Bold.ttf: DejaVu Sans,DejaVu Sans Condensed:style=Condensed Bold,Bold
/usr/share/fonts/truetype/dejavu/DejaVuSansCondensed-Oblique.ttf: DejaVu Sans,DejaVu Sans Condensed:style=Condensed Oblique,Oblique
/usr/share/fonts/truetype/dejavu/DejaVuSansCondensed.ttf: DejaVu Sans,DejaVu Sans Condensed:style=Condensed,Book
/usr/share/fonts/truetype/dejavu/DejaVuSans-ExtraLight.ttf: DejaVu Sans,DejaVu Sans Light:style=ExtraLight
/usr/share/fonts/truetype/dejavu/DejaVuSansMono-BoldOblique.ttf: DejaVu Sans Mono:style=Bold Oblique
/usr/share/fonts/truetype/dejavu/DejaVuSansMono-Bold.ttf: DejaVu Sans Mono:style=Bold
/usr/share/fonts/truetype/dejavu/DejaVuSansMono-Oblique.ttf: DejaVu Sans Mono:style=Oblique
/usr/share/fonts/truetype/dejavu/DejaVuSansMono.ttf: DejaVu Sans Mono:style=Book
/usr/share/fonts/truetype/dejavu/DejaVuSans-Oblique.ttf: DejaVu Sans:style=Oblique
/usr/share/fonts/truetype/dejavu/DejaVuSans.ttf: DejaVu Sans:style=Book
/usr/share/fonts/truetype/ttf-dejavu/DejaVuSans-Bold.ttf: DejaVu Sans:style=Bold
/usr/share/fonts/truetype/ttf-dejavu/DejaVuSansMono-Bold.ttf: DejaVu Sans Mono:style=Bold
/usr/share/fonts/truetype/ttf-dejavu/DejaVuSansMono.ttf: DejaVu Sans Mono:style=Book
/usr/share/fonts/truetype/ttf-dejavu/DejaVuSans.ttf: DejaVu Sans:style=Book


$ fc-match -v sans \
  | grep -F -w -e style: -e weight: -e fullname:
        style: "Book"(s)
        fullname: "DejaVu Sans"(s)
        weight: 80(f)(s)

$ fc-match -v sans:weight=extralight \
  | grep -F -w -e style: -e weight: -e fullname:
        style: "ExtraLight"(s)
        fullname: "DejaVu Sans ExtraLight"(s)
        weight: 40(f)(s)

$ fc-match -v sans:weight=60 | grep -F -w -e weight: 
        weight: 40(f)(s)

$ fc-match -v sans:weight=61 | grep -F -w -e weight: 
        weight: 80(f)(s)

$ fc-match -v sans:weight=139 | grep -F -w -e weight: 
        weight: 80(f)(s)

$ fc-match -v sans:weight=140 | grep -F -w -e weight: 
        weight: 200(f)(s)

Fontconfig defines these symbolic font weights:

constant	value
thin	0
extralight	40
ultralight	40
light	50
demilight	55
semilight	55
book	75
regular	80
normal	80
medium	100
demibold	180
semibold	180
bold	200
extrabold	205
black	210
heavy	210

Fontconfig weight constants

Apparently fontconfig selects the font with the closest weight requested. That’s not what CSS needs, so browsers probably don’t use fontconfig font patterns and therefore the usual fontconfig ways of avoiding the extra-light font don’t work.

But wait. Actually, some browsers do. The surf browser, built using WebKitGTK, translates font-weigth: 300 to fontconfig weight 50, font-weight: 200 to fontconfig weight 40 and font-weight: 100 to fontconfig weight 0, which is a correct mapping, but it won’t result in correct behaviour if only font weights 0 and 80 are available, as 80 is closer to 60, but CSS mandates that 0 is chosen. (To find this out, I used FC_DEBUG=1 surf.) Indeed, the fontconfig configuration suggested in the link above is a sufficient workaround for the WebKitGTK browser:

surf before

$ FC_DEBUG=1 surf test.html |&amp; grep -F -w -c ExtraLight
7

~/.config/fontconfig/fonts.conf

<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<fontconfig>
    <match target="pattern">
        <test qual="any" name="family">
            <string>DejaVu Sans</string>
        </test>
        <test name="weight" compare="less">
            <const>book</const>
        </test>
        <edit name="weight" mode="assign" binding="same">
            <const>book</const>
        </edit>
    </match>
</fontconfig>

surf after

$ FC_DEBUG=1 surf test.html |&amp; grep -F -w -c ExtraLight
0

In a real CSS-conforming browser, this won’t work as fontconfig is presumably only used to list available fonts, and the font matching algorithm then runs in the browser engine itself. One might also desperately attempt to use fontconfig’s <match target="scan"> to lower the weight of the font to 0 and hope the browser will select the nearer, normal variant. Or at least I did desperately try that. That won’t work, either:

CSS still prefers a weight 0 font for font-weight: 300 when both weight 0 and weight 400 are available.
<match target="scan"> needs to be applied system-wide and fontconfig caches then need to be regenerated using fc-cache by root, as apparently the system-wide caches are preferred. Therefore it’s also impossible to apply this rule to a web browser only.

There is still one option left, fortunately: <selectfont>, which controls the set of available fonts. Its documentation is quite high-level and in some aspects downright incorrect, but by reading the source we can conclude that it works like this:

First, check if the filename is explicitly accepted by any <glob>. If it isn’t, then check whether it’s rejected, and only if it’s not accepted but it is explicitly rejected, skip the font. Otherwise continue.

(The documentation claims that <glob> only filters directories, but this is fortunately not true.)
Then, similarly, check if the font matches any accept <pattern> (these may test various font properties). If not, check reject patterns, and skip the font if rejected and not accepted. Otherwise continue and allow the font to be used.
Order of configuration directives doesn’t matter, it’s just being added to glob/pattern accept/reject lists as the configuration is read.

The Solution

Fontconfig’s <selectfont> lets us hide DejaVu Sans ExtraLight from the browser. If we want to keep the font available for other applications (if we don’t, then it might be easier to just uninstall it), let’s create a browser-specific fontconfig conf:

~/.config/fontconfig/browser.conf

<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<fontconfig>
    <include>fonts.conf</include>

    <!-- disable DejaVu Sans ExtraLight, it tends to match font-weight: 300 -->
    <selectfont>
        <rejectfont>
            <glob>*/DejaVuSans-ExtraLight.ttf</glob>
        </rejectfont>
    </selectfont>
</fontconfig>

When we now set the FONTCONFIG_FILE=~/.config/fontconfig/browser.conf environment variable, DejaVu Sans ExtraLight is nowhere to be seen:

$ FONTCONFIG_FILE=~/.config/fontconfig/browser.conf \
  fc-match -v sans:weight=40 | grep -F -w -e weight:
        weight: 80(f)(s)

$ FONTCONFIG_FILE=~/.config/fontconfig/browser.conf \
  fc-list | grep -F -w -c ExtraLight
0

Setting FONTCONFIG_FILE=~/.config/fontconfig/browser.conf for the browser is left as an exercise to the reader.

Appendix A: Why glob?

An observant reader might have noticed that the solution could be made more robust by using <pattern> instead of <glob> and matching on the font weight, thus disabling all light fonts. This is probably correct, but not usable in my case, as I already use accept patterns to limit the available fonts to a few reasonable ones to prevent web designers from selecting hard to read font faces. With the advent of web fonts, this workaround has become less effective lately. :-(

Screenshots:

DejaVu Sans on my system
MacOS Catalina
MacOS Catalina + subpixel antialiasing
MacOS Catalina + disabled font smoothing
Android Samsung S10e
Android Samsung S3

↩
Subpixel antialiasing is disabled since Mojave, possibly because it’s not necessary with HiDPI/Retina displays and dropping it reduces code complexity considerably. ↩

Forem: Tomáš Janoušek

Even faster bash startup

Table of Contents

Motivation

Investigation

man

death by a thousand cuts

completions

fzf

are we done yet?

history

Conclusion

Update 1: Why not fix typing before the prompt instead?

A better xrandr command-line experience

Table of Contents

TL;DR

What? Why?

Behind the scenes

Limitations

Future work

font-weight: 300 considered harmful (and a fontconfig workaround)

Table of Contents

The Problem

MacOS font smoothing, CSS

Linux, fontconfig, CSS

The Solution

Appendix A: Why glob?

Forem: Tomáš Janoušek

Even faster bash startup

Table of Contents

Motivation

Investigation

man

death by a thousand cuts

completions

fzf

are we done yet?

history

Conclusion

Up­date 1: Why not fix typ­ing be­fore the prompt in­stead?

A better xrandr command-line experience

Table of Contents

TL;DR

What? Why?

Behind the scenes

Limitations

Future work

font-weight: 300 considered harmful (and a fontconfig workaround)

Table of Contents

The Problem

MacOS font smoothing, CSS

Linux, fontconfig, CSS

The Solution

Appendix A: Why glob?

Update 1: Why not fix typing before the prompt instead?