Changing the console resolution in FreeBSD 12 with UEFI boot

There are many pages on the Web that explain how to change the console resolution in the FreeBSD boot process, either for BIOS or UEFI boot. All of them generally agree that the way to do it is to put a line into /boot/loader.rc.local, either mode X or, more recently for UEFI, gop set X.

With FreeBSD 12, all of that went out the window.

FreeBSD 12 now defaults to the “Lua loader”, that is, the last stage of the boot process is now implemented in Lua rather than Forth. I’m not sure why, but probably because Lua is just the embedded language all the cool kids are using these days.

The thing is, while the manpages on loader(8) and related topics confidently imply that loader.rc.local is a platform-independent source of configuration data, in reality it is not.

Workaround

The simplest way to work around the issue is to switch back to the Forth-based loader:

cd /boot
ln -f loader_4th.efi loader.efi

This will restore loader.rc.local to its former glory, i.e. it will be read and applied.

Do not, as I just did, try to cp loader_4th.efi loader.efi; cp overwrites existing destination files and it just so happens that loader.efi is loader_lua.efi (a hard link), so the cp command will overwrite the Lua loader with the Forth one.

Fix

The alternative is to replace loader.rc.local with its newfangled Lua replacement:

cd /boot/lua
cat >local.lua <<<EOF
loader.perform("whatever you want")
EOF

Put your preferred loader command inside the quotes; if you want to run multiple commands, each needs its own loader.perform() call, I think.

By the way, even though gop set X works for me on the loader command line, it does not work in either loader.rc.local or lua/local.lua. The older mode X command works everywhere.

Warum ist denn im neuen Outlook-Icon die E-Mail verpixelt? Hat Microsoft endlich den Datenschutz für sich entdeckt?

Danach kommt gar nichts mehr.

It’s not exactly German, is it?

(Source)

Problem

You want your OTRS installation to send your agents notifications whenever a ticket is created through the web service interface.

Analysis

The default notification configuration does not do this, perhaps because the triggering event is NotificationNewTicket, whatever that is.

Solution

Create a new ticket notification, or change the existing one, and set the “Event” field to TicketCreate.

Problem

When replying to or forwarding a message in Outlook, the attribution header uses a 12-hour clock (AM/PM).

You are of the opinion that this format is a remnant from the Dark Ages, when it was, well, dark and people had to be told whether it was day or night, and so you would really like Outlook to stop that.

Analysis

Outlook is being excessively clever here, as usual. It has an option to override the language used for formatting the attribution header, and this option overrides not just the language but the entire locale with the (im)moral equivalent of en-US.

Solution

In Options/Advanced/International options, turn off “Use English for message headers on replies and forwards and for forward notifications. [sic]".

Outlook will now use the format defined in Windows regional settings. It will also use the language defined there.

ZFS backup via SSH tunnel. Throughput without SSH compression is ~4 Mb/s. With compression, it is >30 Mb/s (of compressed data!), and about 400 MiB/min net (about 1.7:1 compression). How come?

#include <algorithm>

std::vector<int> spaces = std::accumulate(lines.begin() + 1, lines.end(),
        std::vector<int>(max_length, 1), [](auto acc, auto line) {
    std::vector<int> tmp(acc.size(), 0);
    std::transform(line.begin(), line.end(), acc.begin(), tmp.begin(), 
            [](wchar_t ch, int b) {
        return b && (ch == L' '); 
    });
    return tmp;
});

It’s Maplebark. Not Marble Arch.

I just used Vim’s listchars feature for the first time to make non-breaking spaces visible. Only I found that it did not appear to work correctly; the nbsp item in listchars only worked if I also included trail, on the other hand, including eol would not change the behavior.

Before reporting bugs, one should always try the latest release, and so I did. I was not inconsiderably surprised that the bug was indeed fixed there.

Then I looked at the repo, and found that it had been fixed not 24 hours before I hit it when using the entire feature for the first time.