Plugging into Linux kernel upstream discussions

Sending Emails

  1. Use a UI-based email client such as Thunderbird that supports sending plaintext emails.
  2. Go back to your roots, and use a terminal-based email client such as mutt that lets you control the encoding with config options, and send emails that you compose in your editor of choice (vim for yours truly).

Setting up mutt

Getting mutt and dependencies

Configuring mutt

$ mkdir -p ~/.mutt
# Put a space as the first character of the command
# to avoid your password# being stored in .bash_history.
#
# Also, replace -r with whatever ID corresponds to your key, probably whatever
# email you used when you created it.
$ echo -n 'mypassword' | gpg --encrypt -r void@manifault.com > ~/.mutt/password.gpg
# vim: syntax=bash
# Setting up mutt identity

set realname = "David Vernet"
set from = "david@bytelab.codes"

# Login and Passwords
#
# Note:
# To create a file with an encrypted password, use the following
# incantation:
# echo -n 'mypassword' | gpg --encrypt -r david@bytelab.codes > ~/.personal_configs/mutt/password.gpg
# IMAP / SMTP password.
set my_password = "`gpg --batch -q --decrypt -r david@bytelab.codes ~/.mutt/password.gpg`

set imap_user = "david@bytelab.codes"
set imap_pass = $my_password

# Point mutt to whatever SMTP server you're using.
set smtp_user = "dcvernet@bytelab.codes"
set smtp_url = "smtp://$smtp_user@smtp.gmail.com:587"
set smtp_pass = $my_password

# Point mutt to whatever IMAP server you're using.
set folder = "imaps://imap.gmail.com:993"
set spoolfile = "+INBOX"

# TLS all the way
set ssl_force_tls = yes

Subscribe to upstream lists

Closing Thoughts

An aside on the whole upstream communication system

  1. This is the way things have been done for over twenty-five years, and the results speak for themselves. Linux is ridiculously pervasive, it’s free, and it’s run by a global community of contributors who work on separate subsystems that are housed in separate repositories. It’s actually kind of a miracle that it all works, and I could see the argument for there being no need to mess with something that’s been working well for decades.
  2. While I’m not at all an authority on how this system was put in place, I have a feeling that the slightly higher barrier to entry is somewhat by design. Kernel work can be very challenging, and I think that requiring people to be able to set up a plain-text encoding email system and self-sufficiently read and discover how to be contributors, is on some axes correlated with how likely they are to know what they’re doing and send out good quality code.
  3. In my opinion, the whole communication system is a bit arcane, but the Linux kernel documentation is pretty damn good. There’s also a lot of great content on https://linux-kernel-labs.github.io/refs/heads/master/index.html as well. So while it’s easy to dunk on the vger website for being poor, etc., I think the theme is that the Linux kernel community strongly prefers content over showmanship — which isn’t to say that there’s not a ton of room for better documentation — more on that in a follow-on post.
  4. Perhaps most importantly, the people who set up this system are probably the ones who have contributed the most to the kernel over the years, and continue to have the deepest breadth of knowledge. Who the hell am I, or anyone else, to tell them what system they should or shouldn’t be using to continue to iterate on the global powerhouse of a free and open-source operating system they’ve built?

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Byte Lab

Byte Lab

Byte Lab is a technical blog that discusses systems engineering, and the tech industry.