Comparison of TBR and local library's inventory

I was interested in knowing if a membership at the local library would be worthwhile, or rather if I’m ordering too many books that I could just borrow. So I compared my To-Be-Read/To-Be-Ordered list (collected with amParser) with the library’s inventory.

Results: Of 73 TBR books (disregarding reference books) the library has 16, 3 of which are not in my preferred language, but only available as German translations. Better than imagined. Time to get a library card.

Persistence

When in doubt, use brute force.
– Ken Thompson in an entirely different context

After having lost around 20kg since new year’s, I decided to test my deadlift strength. I had a goal of 220kg (aka 5plate) in mind, which would be 10kg below my PR. It was a bit of a struggle…

Go static linking

With Go you get statically linked executables, right?

% go build 
% file unreadMail
unreadMail: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, not stripped

% GOARCH=arm go build
% file unreadMail
unreadMail: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, not stripped

% CGO_ENABLED=0 go build
% file unreadMail
unreadMail: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, not stripped

The answer is a clear sometimes. Apparently the import of net causes the executable to be dynamically linked, since it uses CGO. Unless you disable CGO entirely. I would like an option to force go build to statically link or fail if not possible, please. Implicit behavioral changes are not my thing.

[Update 20170815:] You can still force Go to produce a statically linked executable by invoking an external linker and using a libc that fully supports static linkage, i.e. not GNU libc. My favorite so far is musl with its gcc wrapper:

CC=/usr/bin/musl-gcc go build -ldflags ' -linkmode=external -extldflags "-static"'

Not pretty, but better than dynamically linked executables…

Use for unreadMail

Or: “Print the internet”

Wherein I expand on the reason I wrote (lib)UnreadMail:

I wanted to reduce my time on electronic devices. A big chunk is devised to checking my mails, or at least that’s the initial intent - I use unreadMail now to automatically check my mail and print it out. I decide then if I need to go online or if it can wait. This setup only works because of proper spam control, otherwise things would be flooded. Here’s the rough outline of what I did:

• Set up Raspbian on a Raspberry Pi. Changed the account password and set locale and timezone in raspi-config.
• Set up a CUPS print server on there and added my printer.
• Deployed the unreadMail binary on the raspi with the .pem certificate of my server, a fetch script and a print script. Fetch calls unreadMail with the appropriate parameters for cert, server, user and pwfile. Print uses Fetch to get all unseen mails, then limits their number and length and sends them to the printer. If something breaks the limit, this is indicated on the printout. If there are no mails to print, this is indicated as well.
• A cronjob calls Print once a day.

I know that this wastes paper. But I also know, that the alternative wastes my time.

libUnreadMail

I wrote a small library in golang that implements barely enough IMAP to read unseen mail, that you can find here. It contains an example program that fetches all mails and prints the plain text to stdout.

I found the existing IMAP libraries too confusing to use - but having seen the RFCs concerning IMAP, that’s hardly the implementers’ fault. My stuff implements only the tiniest fraction of what IMAP encompasses. The standard is waaaay to big for my taste.