Recently, I’ve been trying to research the availability of a couple of features for visually impaired users (zoom and invert) on Linux. (I’m doing this research on behalf of a visually impaired friend who currently uses MacOS and would like to use Linux.)

Unfortunately, accessibility on Linux seems to be very much Balkanized by desktop environment. There doesn’t even seem to be any sort of forum or mailing list for discussing accessibility across desktop environments. The Linux Foundation Wiki makes mention of an “Open Accessibility Group”, but all of the links lead to a11y.org, and all of the pages on a11y.org are blank. So, defunct, I guess?

Someone suggested that /r/Blind would be a good place to ask questions about Linux accessibility. I gave that a try, but my post was deleted by the moderators without any explanation other than “keeping communities safe, civil, and true to their purpose.” This was my first attempt at using Reddit, and it was not a good first impression. Someone told me that Reddit is known for deleting posts at random without reason, so it’s good to know not to waste my time on Reddit any further.

I did have a small amount of success asking on the wayland-devel mailing list, but that’s not really the appropriate place to discuss accessibility features, since Wayland is lower-level than that.

What I would really like is a comparison of desktop environments, showing which ones support zoom and invert, and showing what the keyboard shortcuts to zoom in and out are for each desktop environment. (Since, of course, these shortcuts are not standardized.) Unfortunately, this doesn’t seem to exist, as far as I can tell.

The default desktop environment for Ubuntu supports zoom and invert. However, the documentation does not mention any keyboard shortcuts for zooming in and out. A kind person told me that the shortcuts are <super><alt>Plus and <super><alt>Minus, but apparently you are just supposed to know that? Also, using the keyboard shortcuts jumps straight from 1.0 to 2.0, rather than going through smaller steps as the MacOS implementation does.

Side rant: What the heck is the default desktop environment for Ubuntu? I thought it was Unity, but the list of desktop envionments on the login screen lists “Ubuntu” separately from “Unity”. If I choose “Ubuntu”, zoom and invert work as described, but if I choose “Unity”, zoom and invert do not seem to be supported.

It looks like KDE Plasma also supports zoom, but you have to set up your own keybindings to make it work. Why aren’t there default keybindings?

Roughly 25 years ago, when I was an undergraduate at MIT, I was a member of the Brain Opera team at the MIT Media Lab. Specifically, I worked with Ben Denckla to write Rogus McBogus, the MIDI software which the Brain Opera was built on top of.

An archive of the original Brain Opera website still exists, although some of the links are broken. Part of that website is a page of pictures.

The Web has come a long way in the past 25 years, and I thought it would be nice to have a list of those pictures that includes thumbnails. So, here it is:

Teresa clearly winning in a common-room free-for-all versus Ed.	A classic smirk by Joe Paradiso.	Maribeth, Sharon, and Maggie, having fun with plastics.
Ben Denckla, in Barcode heaven.	Teresa and Tanya, hamming it up during sherry hour.	Matt and Pete, in a ceremonial toast to Sam Adams.
Tod, extremely close-up (warning: not for the faint of heart).	Homework for Tod’s class.	Matt and his gun.
Our wacky, first webmaster, Ben Adida	A beaming Ara Knaian, flush with excitement over the Rhythm Tree pads.	Joe Paradiso with the synthesizer he built in his basement.
The Audio Super-Twins, Maribeth and Ed, conferring about special powers.	A technician from Mystic Scene Shop, putting together the Mind Forest hardware.	Maggie Orth’s birthday party.
Well-wishers and onlookers at Maggie’s party.	Joyously opening up the Yamaha speakers in the Cube.	Sharon and Ben testing the mini-monitors
Sharon and Zoe at work.	Maggie, setting up for Sherry Hour	Ben and Patrick, the wondertwins of code.
Ben Denckla, coding away.	John Yu, close up and in his element.	More of John Yu in his element.
Jin Kang at work.	Jin Kang at play.	Jin Kang, early for a meeting.
June and Tod at work during sherry hour.	Teresa Marrin and Matt Gorbet.	Maribeth and Teresa.
Matt in a silly mood.	Patrick at work.	Patrick and Ben, in their usual style.
Patrick and John at work.	John, at work by himself.	Pete, kicking back.
Rolf Rando at work	Rolf at work 2.	Rolf at work 3.
Rolf at work 4.	Spock working on the Sensor Chair.	Spock with his scope.
Spock with his scope, looking serious.	Joe Paradiso setting up for the gig in London.	Ed calibrating the Sensor Chair in London, March 1996
More calibrations in the chair	Portal to the Cube, Brain Opera central.	The Sensor Chair.
Radar music at 10/10.	Pictures of the Digital Baton (1/7)	Pictures of the Digital Baton (2/7)
Pictures of the Digital Baton (3/7)	Pictures of the Digital Baton (4/7)	Pictures of the Digital Baton (5/7)
Pictures of the Digital Baton (6/7)	Pictures of the Digital Baton (7/7)	Maggie Orth and the Digital Baton (1/5)
Maggie Orth and the Digital Baton (2/5)	Maggie Orth and the Digital Baton (3/5)	Maggie Orth and the Digital Baton (4/5)
Maggie Orth and the Digital Baton (5/5)	Ara on Holiday	The Brain Opera Team (1/2)
The Brain Opera Team (2/2)	The Rhythm Tree Bags Are Built (1/2)	The Rhythm Tree Bags Are Built (2/2)
Tanya and Laura	The Cube: Hot Staging the Brain

Nearly three years ago, I bought a TinyFPGA BX, thinking it would be interesting to play around with at some point. It’s been just sitting in a box, waiting patiently for me, and I finally got it out last month.

I followed the user guide, but immediately ran into problems. Selecting “Upload” from the “Apio” menu in Atom just resulted in the error message “Error: board TinyFPGA-BX not connected”.

I dug a bit deeper, and learned how to run tinyprog from the command line. (Because the IDE was hiding the real error message from me, and because I just don’t like IDEs anyway.) tinyprog was throwing an exception, saying that the serial port did not exist. This seemed weird, since tinyprog was the one who chose the serial port to use in the first place, and the solution was not obvious to me.

I asked some questions on the TinyFPGA Discourse and on Stack Exchange. Asking on Stack Exchange went about as well as Stack Exchange usually does, which is to say that people rushed to berate me for asking the question in the first place, without providing any constructive suggestions.

Although it required waiting a few days for a response, the TinyFPGA Discourse proved to be much more fruitful in the end.

The main problem, which prevented the board from being programmed at all, was that TinyFPGA BX and my computer’s USB ports (all of them) did not get along, for unknown reasons. The solution was to put a powered USB hub between the computer and the TinyFPGA.

Now the TinyFPGA could be programmed, but tinyprog still threw an exception after successfully programming the board. This problem turned out to be caused by modemmanager, a mysterious daemon that runs on Ubuntu, which pokes random serial ports at inappropriate times.

I disabled modemmanager with:

$ systemctl disable ModemManager.service
Removed /etc/systemd/system/dbus-org.freedesktop.ModemManager1.service.
Removed /etc/systemd/system/multi-user.target.wants/ModemManager.service.
$ systemctl stop ModemManager.service
$

and now tinyprog programs the board without throwing an exception.

So far, so good. Next, I need to learn Verilog! (I read some Verilog other people had written at my job at Fulcrum Microsystems back 15 years ago or so, but I didn’t write any myself.)

About two and a half years ago, I wrote a JSON parser in 6502 assembly language. It’s been hanging around in relative obscurity until now. A couple of days ago, JSON65 saw a huge traffic spike, due to being posted on Hacker News. I thought I would take this opportunity to provide some background and answer a few questions that were raised.

Background

I grew up in the 1980s, when personal computers were quite different than they are today. (Indeed, the concept of a “personal” computer was rather new back then.) Most computers that were sold for home use had an 8-bit microprocessor, one or two 5¼" floppy disk drives, and something on the order of 64 KiB of RAM.

My first encounter with a computer was when my dad brought home an NCR DM-V from work so that he could write his Master’s thesis using WordStar. The computer could also run Microsoft BASIC, and my dad showed me how to write programs in BASIC. Once I discovered a magical book called the “manual”, which revealed all the secrets of BASIC, I was on a roll. I wrote a lot of programs in BASIC for that computer.

Alas, the DM-V was just on loan, and my dad had to return it to work when he finished his thesis. To replace it, my parents bought an Apple //e. I continued writing programs in BASIC on the Apple //e. I was really into it. I had the Beagle Bros Peeks and Pokes chart. I subscribed to Open-Apple/A2-Central. I was so into it that my dad had to make a “no computer before 6 AM” rule, because otherwise I would get up arbitrarily early to program.

Applesoft BASIC was incredibly slow, and also didn’t provide access to all of the features of the hardware. So, I started to learn 6502 assembly language. Initially, I just wrote small parts of my programs in assembly language, since it was easy to mix BASIC and assembly language on the Apple II. I assembled my programs with the mini-assmebler which was available in the Integer BASIC ROM image (which was loaded into the Language Card RAM area under DOS 3.3).

Eventually, I needed something more powerful than the mini-assembler. The obvious solution might have been to buy an assembler, but assemblers were expensive for a kid back then, plus I just enjoyed making things myself. So, around 8th grade or so, I wrote my own assembler in BASIC, which I called PPAssemble. It worked, but PPAssemble was so slow that I really only used it for one thing: to bootstrap PPAssemble II, which was an assembler I wrote in assembly language.

All of this came to an end when I graduated from high school. My parents gave me a 486 laptop which ran MS-DOS and Windows 3.1. (Perhaps unsurprisingly, one of the things I did over the summer was write an 8086 assembler in QBasic.) Then, in the fall, MIT introduced me to UNIX, and shortly after that I learned C.

Retrocomputing

Fast forward to 2018, when I got the old Apple //e out of the garage and started using it again. I installed the cc65 cross-compilation toolchain on my Mac, and started writing code for the Apple II again.

Why JSON?

The three main reasons I wrote a JSON parser in 6502 assembly language were:

1. Because I can.
2. Because it’s fun!
3. Because it’s a bit perverse.

However, the specific motivation for writing a JSON parser was because I was writing some other program (which I don’t think I ever finished) and I wanted a configuration file format for it, an ASCII format which could be easily hand-written. YAML was a logical choice, but YAML is fairly complicated, so I went with the much simpler JSON.

My first thought was to compile YAJL with cc65. I eventually got it to compile, but there were a couple of problems:

• YAJL is huuuuuuge! (by 6502 standards, anyway)
• It didn’t work.

Rather than trying to debug why YAJL didn’t work correctly when compiled with cc65, I decided to just write a JSON parser from scratch.

Why assembly language?

The main reason I got the Apple //e out again was to relive my glory days of programming in 6502 assembly language. So, that was the primary motivation for writing my JSON parser in assembly language. However, there are also some practical motivations for doing so:

1. The 6502 instruction set is not a particularly good match for C.
2. cc65 is a relatively naive compiler, compared to a modern optimizing compiler like gcc or clang.
3. Both code size and speed are important on the Apple II, since it is very slow (1 MHz, with each instruction taking several clock cycles) and has limited memory (48K, 64K, or 128K, depending on how you count it, and how much work you’re willing to go to to access it).

Then why is it written in four languages?

JSON65 is written in two languages, C and 6502 assembly language.

The JSON parser is a single file, json65.s. So, it is correct to say that the JSON parser is written entirely in 6502 assembly language. However, it is designed to be called from C, because it uses the cc65 calling convention. It also calls a few of the support functions in cc65’s runtime library: callptr4, incsp4, incsp6, negeax, pushax, resteax, and saveeax. (These functions are for manipulating the “pseudo-registers” in the zero page that the cc65 calling convention uses.)

JSON65 includes some additional, optional code beyond the core event-driven parser, most of which is written in C. json65-file.c feeds the parser from a file, and json65-tree.c provides a tree-based interface to the parser, as an alternative to the SAX-style event-driven parser.

GitHub’s code analysis also shows Perl and Haskell code in the JSON65 repository. This is because of the tools directory, which contains some scripts which I used to generate some code when I was writing JSON65. The average user of JSON65 doesn’t need these. And in any case, they run on the host, not on the 6502!

Why are strings limited to 255 characters?

Because JSON65 can parse incrementally, a JSON document like this:

[ "This is a string" ]

could be fed into the parser in two chunks. For example, the first chunk could be:

[ "This is

and the second chunk could be:

 a string" ]

In order to provide the string "This is a string" to the callback, one of the following things must happen:

• The callback must be called twice (with "This is" and " a string"), and the user of the library must deal with putting the two parts together. I didn’t want to do this, because it makes the library harder to use.

• The parser must copy the two parts of the string into a dynamically allocated buffer, which it can then provide to the callback. I didn’t want to do this, because the Apple II has very little memory, and I didn’t want to leave to chance whether or not you would run out of memory during parsing.

• The parser must copy the two parts of the string into a statically allocated buffer, which it can then provide to the callback. This is the solution I chose, but it means that strings are limited to the length of the buffer.

So, there had to be a limit on the length of strings. Why 255 bytes, specifically? This is because of addressing modes.

The 6502 offers an indirect indexed addressing mode, for example:

LDA ($40),Y

which loads a 16-bit integer from the consecutive zero-page locations $40 and $41. It then adds the contents of the Y register (which is 8 bits wide) to that 16-bit integer. That result is used as an address, and a single byte is loaded from that address and placed in the accumulator.

This makes it easy to index into a buffer of 256 bytes or fewer. Just store the address of the buffer somewhere in the zero page, and then load the Y register with the array index.

To index into a buffer longer than 256 bytes, you’d need to do 16-bit addition (8 bits at a time) to add the base address to the index, and then store the result in the zero page somewhere. Then you’d load 0 into the Y register, and you’d still use the same indirect indexed addressing:

LDA ($40),Y

(because the original 6502 does not offer an indirect, non-indexed addressing mode.)

Doing so would not be the end of the world, but it is more instructions, so therefore it takes more space and more time. Given that the buffer has to be of some finite size, 256 bytes seems like a fine choice.

(I believe I limited the length to 255, rather than 256, so that the length of the string can also fit in a single byte.)

Note that although the length of a string is limited, the length of a line is not limited. So, for example, you could have a JSON document like this:

[ "Up to 255 chars", "Up to 255 chars", "Up to 255 chars" ]

all on a single line, where each of the three strings on the line is up to 255 characters in length. (Technically 255 bytes, not characters, but that distinction only matters if you’re using non-ASCII characters.)

Previously, I’ve posted about how to run Arduino code on a SAMD11 on a breadboard, and about how to run Rust code on a Feather M4. This post just combines those two ideas, and shows how to run Rust code on a SAMD11 on a breadboard.

I’m going to be using the 14-pin ATSAMD11C14A, which is supported by the samd11_bare crate. (The 20-pin ATSAMD11D14AS I used before is not currently supported by Rust.)

Hardware setup

I started out by soldering the ATSAMD11C14A to a SOIC-14 breakout, and then putting that and a SWD connector breakout on a breadboard.

Next, I wired up power and ground. On the SWD breakout, the two “GND” pins go to ground, and the “Vref” pin goes to power. On the ATSAMD11C14A, pin 12 goes to power, and pin 11 goes to ground. I also added wires to connect the two power buses together and the two ground buses together.

After that, I added a 0.1μF capacitor between pins 11 and 12 on the ATSAMD11C14A.

Next, I wired up the debug pins between the SWD breakout and the microcontroller. RST goes to pin 6, CLK goes to pin 7, and SWIO goes to pin 8.

Finally, I added an LED to pin 2 of the microcontroller. I connected one end of a 220Ω resistor to pin 2, and I connected the other end to a spare row on the breadboard. Then I connected the LED’s cathode (short pin, flat side) to the row the resistor is connected to, and I connected the LED’s anode (long pin, round side) to the positive power rail.

Now, to get ready to program the ATSAMD11C14A, I hooked up my trusty SnapVCC (set on 3.3V) to the power and ground rails of the breadboard. And I got out my MAX32625PICO and connected it to the debug header.

Software setup

Make sure you have Rust installed, and then install thumb6 support:

$ rustup target add thumbv6m-none-eabi

Next, you’ll need an ARM toolchain. Download the ARM gcc toolchain from ARM’s website, and then install it something like this:

$ cd /opt
$ tar -xf ~/Desktop/gcc-arm-none-eabi-9-2020-q2-update-x86_64-linux.tar.bz2
$ export PATH="/opt/gcc-arm-none-eabi-9-2020-q2-update/bin:$PATH"

See this bug for more information.

Clone the Rust atsamd repository:

$ git clone https://github.com/atsamd-rs/atsamd.git
$ cd atsamd/boards/samd11_bare

In the boards/samd11_bare directory, create a file named openocd.cfg with the following contents:

source [find interface/cmsis-dap.cfg]
transport select swd

set CHIPNAME at91samd11c14a
source [find target/at91samdXX.cfg]

reset_config  srst_nogate

adapter_nsrst_delay 100
adapter_nsrst_assert_width 100

init
targets
reset halt

at91samd bootloader 0
program blinky_basic.bin verify
reset
shutdown

Then, in that directory, do:

$ cargo build --release --example blinky_basic
$ arm-none-eabi-objcopy -O binary target/thumbv6m-none-eabi/release/examples/blinky_basic blinky_basic.bin

Make sure the MAX32625PICO (our debug probe) is connected to the computer’s USB port, and the breadboard is getting 3.3V power (from the SnapVCC, or other 3.3V power source). Then, upload the program with:

$ openocd

This should start blinking the LED on the breadboard.

Yesterday, I tried embedded Rust on the Feather M4. Today I thought I would try out embedded Rust on a slightly more exotic board, the Longan Nano. It is a 32-bit RISC-V board which is very inexpensive, and has a 160x80 color LCD built in.

This was mostly just a matter of following the instructions in the longan-nano crate. The only thing that stymied me for a couple minutes was that they forgot to mention that dfu-util has to be run as root.

I already have Rust installed on my Ubuntu 20.04 machine:

$ rustc --version
rustc 1.46.0 (04488afe3 2020-08-24)

If you don’t, you’ll need to install Rust first.

Next, following the instructions in the longan-nano crate:

$ rustup target add riscv32imac-unknown-none-elf

The next step is to install a RISC-V toolchain. The longan-nano crate recommends installing a toolchain from SiFive, but I opted to install the Ubuntu package gcc-riscv64-unknown-elf instead. Note that despite having “64” in the name, gcc-riscv64-unknown-elf supports both 32-bit and 64-bit RISC-V processors.

$ sudo apt-get install gcc-riscv64-unknown-elf

The next step is to install dfu-util. Because of a bug in some versions of the Longan Nano bootloader, the longan-nano crate recommends installing the development version of dfu-util from git, which has a workaround for the bug, rather than installing a stable release of dfu-util.

$ cd ~/src
$ git clone git://git.code.sf.net/p/dfu-util/dfu-util
$ cd dfu-util
$ ./autogen.sh
$ ./configure
$ make
$ sudo make install

And now, back to the longan-nano crate:

$ cd ~/src
$ git clone https://github.com/riscv-rust/longan-nano
$ cd longan-nano
$ cargo build --examples --release --all-features

Because I installed a different RISC-V toolchain than they did, I had to use riscv64-unknown-elf-objcopy instead of riscv-nuclei-elf-objcopy:

$ riscv64-unknown-elf-objcopy -O binary target/riscv32imac-unknown-none-elf/release/examples/ferris ferris.bin

Now hold down the “BOOT0” button on the Longan Nano while connecting it to the computer’s USB port. Uploading the code to the board must be done as root:

$ sudo dfu-util -a 0 -s 0x08000000:leave -D ferris.bin

This should display a picture of Ferris, the Rust mascot.

Update: By doing the following setup once, it’s possible to avoid having to run dfu-util as root.

$ sudo sh -c 'cat > /etc/udev/rules.d/99-gigadevice.rules'
ATTRS{idVendor}=="28e9", ENV{ID_MM_DEVICE_IGNORE}="1"
SUBSYSTEM=="usb", ATTRS{idVendor}=="28e9", MODE="0666"
SUBSYSTEM=="tty", ATTRS{idVendor}=="28e9", MODE="0666"
^D
$ sudo udevadm control --reload-rules
$ sudo udevadm trigger

I’ve been learning Rust recently, and I thought it would be interesting to program a microcontroller in Rust. Luckily, embedded Rust is a thing, and seems to have a fair amount of support. Among others, there is support for ESP32, Longan Nano, Teensy 4, and the Apollo3 chip used in the Artemis module. But there seems to be especially good support for the ATSAMD family of ARM microcontrollers, which are used in a number of Adafruit products.

So, I decided to give embedded Rust a try with a Feather M4 module I had lying around. There is a board support crate for the Feather M4, so the process was relatively straightforward. All I had to do was follow the instructions, but I’ll go ahead and repeat them below.

The first step was to install Rust on my Ubuntu 20.04 machine:

$ curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
$ source $HOME/.cargo/env
$ which rustc
/home/ppelleti/.cargo/bin/rustc
$ rustc --version
rustc 1.46.0 (04488afe3 2020-08-24)

Next, following the instructions in the Feather M4 crate, I installed the toolchain needed by Cortex M4 processors, such as the ATSAMD51.

$ rustup target add thumbv7em-none-eabihf

Now, following the instructions for installing cargo-hf2, which will be used to talk to the board’s bootloader to load the program onto the board:

$ sudo apt-get install libudev-dev libusb-1.0-0-dev
$ sudo sh -c 'cat > /etc/udev/rules.d/99-adafruit-boards.rules'
ATTRS{idVendor}=="239a", ENV{ID_MM_DEVICE_IGNORE}="1"
SUBSYSTEM=="usb", ATTRS{idVendor}=="239a", MODE="0666"
SUBSYSTEM=="tty", ATTRS{idVendor}=="239a", MODE="0666"
^D
$ sudo udevadm control --reload-rules
$ sudo udevadm trigger
$ cargo install cargo-hf2

Then, clone the repository to get the Feather M4 examples:

$ git clone https://github.com/atsamd-rs/atsamd
$ cd atsamd/boards/feather_m4/

Finally, connect the Feather M4 board to the computer, and press the feather’s reset button twice.

$ cargo hf2 --release --example blinky_basic

It works! Perhaps the neopixel_rainbow example is a bit more exciting:

$ cargo hf2 --release --example neopixel_rainbow

Don’t forget to press the reset button twice before running cargo hf2.

Lately I’ve been interested in 9P, the file protocol used by the Plan 9 operating system. Although Plan 9 is mostly a historical curiosity at this point, 9P is still in use outside of Plan 9. It seems especially popular for sharing files between guest and host operating systems when using virtualization. (Such as VirtFS or Windows Subsystem for Linux.)

My interest in 9P is that it’s fairly simple, and easier to implement than competing file protocols such as SMB, NFS, and WebDAV. For example, I’m thinking of having some of my embedded projects serve up their SD card via 9P, to make them easier to configure.

Linux comes with a 9P client (more on that below). There is a third-party client for MacOS, Mac9P, although I haven’t been able to get it to work on my Mac. And although Windows must have a built-in 9P client to support WSL, I haven’t seen any information about how to use that client to connect to external 9P servers.

Discounting older versions of the protocol that are no longer in use, there are basically three variants of 9P:

• 9P2000 - The original variant of 9P, used by Plan 9. A “lowest common denominator” that clients can fall back on.
• 9P2000.u - A variant which gives 9P more “UNIX-like” semantics, rather than Plan 9 semantics. Not clear if this is still in use much.
• 9P2000.L - A variant which changes 9P to pretty much exactly match the semantics of Linux.

The client that comes with Linux (v9fs) supports 9P2000 and 9P200.L.

Let’s take a look at how easy it is to get up and running on Linux. First, install the 9mount command:

$ sudo apt-get install 9mount

Then mount the public 9P server which is provided by 9p.io:

$ mkdir $HOME/9
$ 9mount 'tcp!9p.io' $HOME/9

Voila! Now take a look:

$ cd $HOME/9
$ ls -l
total 8929
drwxrwxr-x 1 4294967294 4294967294       0 Jul 15  2018 9grid
drwxrwxr-x 1 4294967294 4294967294       0 Jul 15  2018 adm
drwxrwxr-x 1 4294967294 4294967294       0 May 23 02:02 contrib
drwxrwxr-x 1 4294967294 4294967294       0 Jul 15  2018 dist
drwxrwxr-x 1 4294967294 4294967294       0 Jul 20 00:38 extra
-rw-rw-r-- 1 4294967294 4294967294 9142602 Jan 22  2015 lsr
drwxrwxr-x 1 4294967294 4294967294       0 Jul 15  2018 nix
drwxrwxrwx 1 4294967294 4294967294       0 Jun  5 00:31 patch
drwxrwxr-x 1 4294967294 4294967294       0 Jul 15  2018 plan9
-rw-rw-r-- 1 4294967294 4294967294       0 Jun 23  2013 _sources
drwxrwxr-x 1 4294967294 4294967294       0 Jul 15  2018 wiki
drwxrwxr-x 1 4294967294 4294967294       0 Jul 15  2018 xen

To unmount the filesystem when you’re done:

$ cd $HOME
$ 9umount $HOME/9

Sometimes I want to know where I downloaded a file from. Most web browsers store this information in extended attributes, but there isn’t a particularly friendly way to read it. It’s stored differently on each major platform, and on MacOS, it’s not particularly human-readable if you use the “xattr” command to read it:

bash$ xattr -l lufa-LUFA-170418.zip
com.apple.metadata:kMDItemWhereFroms:
00000000  62 70 6C 69 73 74 30 30 A2 01 02 5F 10 3C 68 74  |bplist00..._.<ht|
00000010  74 70 73 3A 2F 2F 63 6F 64 65 6C 6F 61 64 2E 67  |tps://codeload.g|
00000020  69 74 68 75 62 2E 63 6F 6D 2F 61 62 63 6D 69 6E  |ithub.com/abcmin|
00000030  69 75 73 65 72 2F 6C 75 66 61 2F 7A 69 70 2F 4C  |iuser/lufa/zip/L|
00000040  55 46 41 2D 31 37 30 34 31 38 5F 10 29 68 74 74  |UFA-170418_.)htt|
00000050  70 3A 2F 2F 77 77 77 2E 66 6F 75 72 77 61 6C 6C  |p://www.fourwall|
00000060  65 64 63 75 62 69 63 6C 65 2E 63 6F 6D 2F 4C 55  |edcubicle.com/LU|
00000070  46 41 2E 70 68 70 08 0B 4A 00 00 00 00 00 00 01  |FA.php..J.......|
00000080  01 00 00 00 00 00 00 00 03 00 00 00 00 00 00 00  |................|
00000090  00 00 00 00 00 00 00 00 76                       |........v|
00000099
com.apple.quarantine: 0001;59d47dc6;Chromium;AE65E6B1-F0DB-437C-B645-B1C867485050

Therefore, I wrote a utility called whence, which presents the information in a friendlier format:

bash$ whence lufa-LUFA-170418.zip
lufa-LUFA-170418.zip:
  URL         https://codeload.github.com/abcminiuser/lufa/zip/LUFA-170418
  Referrer    http://www.fourwalledcubicle.com/LUFA.php
  Application Chromium
  Date        Tue Oct  3 23:20:54 PDT 2017

whence works on FreeBSD, Linux, MacOS, and Windows. It normally produces output in a colorized, human-readable form. (Set NO_COLOR to avoid using ANSI color in the terminal.) With the option -j or --json, it will produce JSON output instead.

whence supports the XDG Common Extended Attributes on FreeBSD, Linux, and MacOS. On MacOS, it also supports com.apple.quarantine, com.apple.metadata:kMDItemWhereFroms, and com.apple.metadata:kMDItemDownloadedDate. On Windows, it uses the Zone.Identifier alternate data stream.

These attributes are attached to downloaded files by most web browsers, with the notable exception of Firefox on Linux. You can also get curl to attach extended attributes by using the --xattr command-line option.

To add Juneteenth to the list of holidays recognized by M-x holidays in Emacs, just add the following to your .emacs file:

(setq holiday-other-holidays '((holiday-fixed 6 19 "Juneteenth")))