“Wrap marker” Thunderbird Extension

Yay, time for a new Thunderbird extension. Wrap Marker.

The code is up on GitHub.

This Thunderbird extension adds a word wrap marker (also called “ruler”, depending on what editor you’re using) to the text area in the compose window when you’re editing plain text emails. In effect, a vertical line indicating that you’re close to the 72/76/80-character mark. (You can change the position in about:config. The default is 76.)

It works by changing the entire editor’s (think “iframe”) designMode from “on” to “off”, and adding a div with contenteditable=”true” instead. If this changes how your compose text area behaves, I’d consider that a bug, so please let me know.

At the time of this writing (February 26, 2018), this extension is still kind of beta and not exactly “thoroughly tested”. It will be submitted to Thunderbird’s extension page once it’s been tested some more and maybe once it’s gotten some of the known bugs fixed. These include:

  • Quoted text in a reply isn’t blue.
  • Your cursor position preference isn’t honored. The cursor will always be in the upper left corner when you start a new reply.
  • This feature is disabled for HTML emails. I don’t think it’ll ever work for HTML emails.
  • You get scrollbars all the time (This is probably fixable. Forgot to fix.)

Backporting security fixes to old versions of the Linux kernel (Meltdown to 2.6.18) (Part 1)

In this post, I’ll give a quick overview over what it takes to backport a large patch (the KAISER patch to protect against Meltdown) to the Linux kernel to a version of the Linux kernel from around ten years ago. Note that this post only covers the main technique and the assembly portion of the patch.

First of all, one should think hard about whether this necessary. Couldn’t you just run a newer kernel with older user space? The answer is, in most cases, yes, you could. As evidenced by our ability to run old Docker images with 10-year-old userland on modern kernels (perhaps adding vsyscall=emulate to the kernel command line), things often work just fine. However, you may run into problems if you’re running on bare metal. I’ve heard of people running a maintained 3.10 kernel on 10-year-old userland without much fuss. I’ve personally run a 64-bit kernel with 100% 32-bit userland (same kernel version, without X11).

However, some people may not be able to afford to re-test their whole setup with different kernel versions all the time, and that is why distributions usually backport pure security fixes from newer kernels to older kernels. The Linux kernel is constantly improved, and over time, the code base of the kernel version included in a specific stable version of a distribution, which may only get security fixes, tends to look pretty different from the current Linux kernel.

Now let’s pretend we have to backport a fix for the Meltdown vulnerability to Linux 2.6.18. First of all, we try very hard to come up with alternative ways to thwart this vulnerability. For 2.6.18, we come up empty-handed, but for earlier kernels, we may find the so-called 4G/4G patch.

This 4G/4G patch unfortunately never made it into the mainline kernel, but was adopted by Red Hat for inclusion in Red Hat Enterprise Linux up to version 4. So we could get our hands on a version of this patch for Linux 2.6.9, and perhaps forward-port this to 2.6.18. The patch at http://people.redhat.com/mingo/4g-patches/4g-2.6.6-B7 weighs in at around 4500 lines, and our foremost priority should be to find a patch with as few lines as possible.

The patch referenced in the original Meltdown paper weighs in at only 1000 lines, and is almost guaranteed to be very barebones. I’d say it would therefore make sense to attempt to backport this patch, and if we manage to do that, perhaps look at what the various distributors decided to do differently from what’s in this patch.

Before we start, it would probably make sense to find a couple sentences that describe what the patch is supposed to do. It’s more than likely that we came across various descriptions of the patch when we were looking for a barebones patch to base our work off from. LWN has a good introduction.

Preparations

We need the source tree of the target kernel version and the source kernel version extracted somewhere. The source kernel version can be had by doing:

$ git clone https://github.com/torvalds/linux.git
$ # cd / mv / etc.
$ git checkout v4.10-rc6

The target version in our case is over here: http://vault.centos.org/5.11/updates/SRPMS/kernel-2.6.18-419.el5.src.rpm. We need to extract this and apply all of the existing patches. I use a current version of Debian, and rpmbuild operates in ~/rpmbuild. So create this directory, and the directories, SRPMS, RPMS, SPECS, SOURCES, BUILD, and BUILDROOT below it. Move the .src.rpm into the SOURCES directory, and issue the following commands.

$ cd ~/rpmbuild/SOURCES
$ rpm2cpio * | cpio -idmv
$ mv kernel.spec ../SPEC
$ cd ../SPEC
$ rpmbuild --nodeps -bp kernel.spec

Make sure you didn’t get any errors in the last step. Your patched kernel, ready to build from, is now inside ~/rpmbuild/BUILD/.

We’ll be making a lot of use of grep and git blame to backport patches. I usually use less to browse code quickly, or open it in an editor (usually kate and/or sublime) when I think I’ll need the file for a longer time. I have two monitors, but having more would help. I also have a bunch of paper to scribble stuff on. When you have a lot of terminal windows open just for the grepping, compiling and other things, you’ll probably find that giving the editor

You’ll find that you’ll have to read up on four-level page tables while creating the patch. Depending on the way you work, you might as well do that before you dig in.

Here are a few more less tips:

  • You likely already know that you can search files by hitting ‘/’
    • You can use the arrow keys to browse through your search history
    • You can disable regex search by hitting Ctrl-R
    • You can type -N followed by return to display line numbers

For debugging, I use the venerable Bochs.

Digging in

arch/x86/entry/entry_64.S and arch/x86/entry/entry_64_compat.S

We have something in arch/x86/entry/entry_64.S and arch/x86/entry/entry_64_compat.S. Okay, we’re adding a few macros (SWITCH_KERNEL_CR3_NO_STACK, SWITCH_USER_CR3, SWITCH_KERNEL_CR3). These macros all seem to be close to a macro called SWAPGS or SWAPGS_UNSAFE_STACK. The presence of “UNSAFE_STACK” also dictates which SWITCH_CR3 macro we’re using. Though nothing may make sense yet, these are all important observations.

On the old kernel, this path doesn’t exist at all, but we have a promising-sounding arch/x86_64/ path.

~/src/kernel/el5/linux-2.6.18.4$ find arch/x86_64/ -name *entry*
arch/x86_64/kernel/entry.S
arch/x86_64/ia32/ia32entry.S

Opening arch/x86_64/kernel/entry.S, we see code that looks similar on the whole. SWAPGS doesn’t exist, but swapgs (as a pure assembly instruction) does. So let’s figure out what SWAPGS is about:

~/src/kernel/git$ grep -rn SWAPGS
...
arch/x86/include/asm/irqflags.h:122:#define SWAPGS      swapgs
...
arch/x86/include/asm/paravirt.h:908:#define SWAPGS                                                              \
        PARA_SITE(PARA_PATCH(pv_cpu_ops, PV_CPU_swapgs), CLBR_NONE,     \
                  call PARA_INDIRECT(pv_cpu_ops+PV_CPU_swapgs)          \
                 )
...

At this point, we might have a hunch that SWAPGS was introduced with the intention to make the same entry code work for both real hardware/real virtualization and paravirtualization, and this is sufficiently confirmed when we git blame the file a bit:

$ git blame arch/x86/entry/entry_64.S
...
72fe485854429 arch/x86/kernel/entry_64.S (Glauber de Oliveira Costa 2008-01-30 13:32:08 +0100  143)     SWAPGS_UNSAFE_STACK
...
$ git show 72fe485854429
commit 72fe4858544292ad64600765cb78bc02298c6b1c
Author: Glauber de Oliveira Costa <gcosta@redhat.com>
Date:   Wed Jan 30 13:32:08 2008 +0100

    x86: replace privileged instructions with paravirt macros
    
    The assembly code in entry_64.S issues a bunch of privileged instructions,
    like cli, sti, swapgs, and others. Paravirt guests are forbidden to do so,
    and we then replace them with macros that will do the right thing.
...

When looking at the above git blame, there are a lot of lines affecting SWAPGS with different commit hashes, but this one is the oldest. We should be able to transfer the macro calls to the lines adjacent to the swapgs instructions. Fortunately, the number of swapgs instructions and the number of SWAPGS macro calls are almost the same in both kernels. With just the names (SWITCH_KERNEL_CR3) of the macros we don’t really know if this switches the kernel CR3 to the user CR3 or the other way round, and when you look at code that was accepted upstream or in distributions, you might see that the macro names have become easier to understand. So let’s dig into the macros, which are declared in the newly #included asm/kaiser.h.

asm/kaiser.h

asm/kaiser.h consists of assembly code (#ifdef __ASSEMBLY__) and C code (#else).  Assembly code in the Linux kernel uses AT&T syntax, which means that the first operands are the sources and the second operands the destinations. The macros look pretty clean (i.e., they are mostly pure assembly code), except for the use of something called PER_CPU_VAR. Modern processors have more than one core, and these cores operate independently. One core might be executing user land, and another core might be in the kernel or about to do the entry into the kernel.

Unfortunately, when we grep for PER_CPU_VAR in the old kernel code, we come up empty-handed:

src/kernel/el5/linux-2.6.18.4$ grep -r PER_CPU_VAR .
src/kernel/el5/linux-2.6.18.4$

Note that a case-insensitive grep comes up with ia64-specific (as in Itanium) code. grepping for PER_CPU, on the other hand, yields a lot of results. Even the KAISER patch itself contains DECLARE_PER_CPU and DEFINE_PER_CPU statements. However, the older kernel doesn’t have DECLARE_PER_CPU_SECTION or DEFINE_PER_CPU_SECTION.

~/src/kernel/git$ grep -r PER_CPU_SECTION . | grep define
./include/linux/percpu-defs.h:#define DECLARE_PER_CPU_SECTION(type, name, sec)                  \
... (More matches in the same file)

Now, we do a chain of git blames until we find something that we consider useful:

git blame include/linux/percpu-defs.h
git show 7c756e6e19e71
git blame 7c756e6e19e71^ -- include/linux/percpu-defs.h # start blaming from one before 7c756e6e19e71; don't forget the '--'
git show 5028eaa97dd1d
# Looks like 5028eaa97dd1d creates the file for the first time, and the definitions used to be in include/asm-generic/percpu.h
git blame 5028eaa97dd1d^ -- include/asm-generic/percpu.h
git show 9b8de7479d0db
git blame 9b8de7479d0db^ -- include/linux/percpu.h
git show 0bd74fa8e29dc

At this point, we finally found the commit that first introduced DEFINE_PER_CPU_SECTION, but this still depends on DEFINE_PER_CPU_PAGE_ALIGNED, which isn’t available yet in 2.6.18. So the search continues:

git blame 0bd74fa8e29dc^ -- include/linux/percpu.h
git show 63cc8c7515646

This commit indicates that DEFINE_PER_CPU_PAGE_ALIGNED was introduced to avoid wasting memory. I don’t believe we really need to care about this. Let’s trace PER_CPU_VAR next:

grep -r PER_CPU_VAR . | grep define
git blame ./arch/x86/include/asm/percpu.h
git show dd17c8f72993f
git blame dd17c8f72993f^ -- arch/x86/include/asm/percpu.h
git show 3334052a321ac

This commit unifies the percpu_32.h and percpu_64.h files into a single header file, and indicates that PER_CPU_VAR only existed in the 32-bit code paths. Instead, the 64-bit code had this, which we grep straight away:

DECLARE_PER_CPU(struct x8664_pda, pda);

~/src/kernel/el5/linux-2.6.18.4$ grep -r x8664_pda
...
include/asm-x86_64/pda.h:11:struct x8664_pda {
...
~/src/kernel/el5/linux-2.6.18.4$ less -N include/asm-x86_64/pda.h
...
     10 /* Per processor datastructure. %gs points to it while the kernel runs */ 
     11 struct x8664_pda {
     12         struct task_struct *pcurrent;   /* Current process */
     13         unsigned long data_offset;      /* Per cpu data offset from linker address */
     14         unsigned long kernelstack;  /* top of kernel stack for current */ 
     15         unsigned long oldrsp;       /* user rsp for system call */
     16 #if DEBUG_STKSZ > EXCEPTION_STKSZ
     17         unsigned long debugstack;   /* #DB/#BP stack. */
     18 #endif
     19         int irqcount;               /* Irq nesting counter. Starts with -1 */   
     20         int cpunumber;              /* Logical CPU number */
     21         char *irqstackptr;      /* top of irqstack */
     22         int nodenumber;             /* number of current node */
     23         unsigned int __softirq_pending;
     24         unsigned int __nmi_count;       /* number of NMI on this CPUs */
     25         int mmu_state;     
     26         struct mm_struct *active_mm;
     27         unsigned apic_timer_irqs;
     28 } ____cacheline_aligned_in_smp;
...

Interesting, this is a per-processor data structure? pda.h doesn’t exist in modern kernels anymore, but some additional googling confirms that, yes, we should be able to use this. I ended up adding unsafe_stack_register_backup to this struct. Through some additional code searching we can find out how to access members of the PDA structure (for assembly, there’s a hint at the top: %gs points to the structure when we’re in kernel space).

The rest of asm/kaiser.h consists entirely of C function prototypes, which we can just copy over. At this point, we have successfully backported about 37% of the entire patch. I used this git blame technique to backport the entire patch. It’s a lot of work, and if you do not include the time it takes to read through the Meltdown papers and the news to get a good overview of what needs to be done, it took me about two to three weeks to get a still-broken patch that causes the system to panic around PID number 370, which is still long before you get to log in to the console. It still took well over a dozen rebuilds to get there.

KDE: Windows freeze or flicker but application doesn’t crash

I’m running KDE on two different systems, and one of them exhibits the following problem very often, and the other just did for the first time:

Windows stop updating their content, and perhaps flicker a bit. Switching to a different window and back causes the window contents to be updated, but still frozen. Which means that the application itself is not crashed.

The following command fixes this:

kwin --replace

You can run this from the run command prompt (Alt+F2) (also called Plasma search or krunner), or you could run it in a terminal. (You’d have to make sure the process doesn’t exit when you close the terminal though.)

If everything appears to be frozen and you can’t get to the run command prompt, you could still switch to a console, log in, and try running the following:

DISPLAY=:0 kwin --replace

Both systems have internal Intel graphics (quite different chipsets though) and KDE5.

The above commands will fix the problem for that time. Your open applications should not be affected by the change. I haven’t looked much into permanent fixes, but changing the rendering backend (System Settings → Display and Monitor → Compositor) may change the frequency the problem is triggered or maybe even get rid of it altogether. (I felt that OpenGL 2.0 probably triggered the problem fewer times than OpenGL 3.1.)

I’ve noticed a fair amount of traffic to my KDE-related posts. If you run into any weird KDE problems that you don’t know how to fix, feel free to leave a comment and ask.

Meltdown / Spectre Kernel Patch Benchmarks on Older Systems

The Meltdown patch for the Linux kernel makes use of the relatively new PCID instruction. I still sometimes use my old laptop, which contains a Core 2 Duo Penryn CPU (T7250), and does not support the PCID instruction, so I did a quick UnixBench run to see what kind of difference the absence of the PCID instruction would make. At the end of this article, I have a bonus “benchmark” for an alternative way to mitigate Meltdown: disabling the CPU’s caches. All my tests were performed on Debian Wheezy (currently oldstable) using kernel version 3.16.0-5-amd64.

First of all, here are another person’s results for a CPU that supports PCID. And since that’s in Japanese, here’s the important bit:

Test Before After Change (positive is better)
System Call Overhead 5391.9 4009.7 -25.63%

Now, my tests on the Penryn CPU:

Test Before After Change (positive is better)
Dhrystone 2 using register variables 3360.4 3414.1 +1.60%
Double-Precision Whetstone 724.1 724 -0.01%
Execl Throughput 1351.7 1222.9 -9.53%
File Copy 1024 bufsize 2000 maxblocks 1582 1244 -21.37%
File Copy 256 bufsize 500 maxblocks 1255.9 922.1 -26.58%
File Copy 4096 bufsize 8000 maxblocks 1982.4 1810.6 -8.67%
Pipe Throughput 1672.8 765.4 -54.24%
Pipe-based Context Switching 1108.3 671 -39.46%
Process Creation 1150 1025.3 -10.84%
Shell Scripts (1 concurrent) 1995.7 1909 -4.34%
Shell Scripts (8 concurrent) 1831.8 1743.3 -4.83%
System Call Overhead 1705.6 544.9 -68.05%
System Benchmarks Index Score 1535.8 1160.9 -24.41%

And the raw data in case you are interested:

Before updating:

Test Score Unit Time Iters. Baseline Index
Dhrystone 2 using register variables 39215974.0 lps 10.0 s 7 116700.0 3360.4
Double-Precision Whetstone 3982.6 MWIPS 9.9 s 7 55.0 724.1
Execl Throughput 5812.4 lps 29.2 s 2 43.0 1351.7
File Copy 1024 bufsize 2000 maxblocks 626453.0 KBps 30.0 s 2 3960.0 1582.0
File Copy 256 bufsize 500 maxblocks 207854.8 KBps 30.0 s 2 1655.0 1255.9
File Copy 4096 bufsize 8000 maxblocks 1149781.6 KBps 30.0 s 2 5800.0 1982.4
Pipe Throughput 2080979.1 lps 10.0 s 7 12440.0 1672.8
Pipe-based Context Switching 443337.7 lps 10.0 s 7 4000.0 1108.3
Process Creation 14490.3 lps 30.0 s 2 126.0 1150.0
Shell Scripts (1 concurrent) 8461.7 lpm 60.0 s 2 42.4 1995.7
Shell Scripts (8 concurrent) 1099.1 lpm 60.1 s 2 6.0 1831.8
System Call Overhead 2558469.9 lps 10.0 s 7 15000.0 1705.6
System Benchmarks Index Score: 1535.8

After updating:

Test Score Unit Time Iters. Baseline Index
Dhrystone 2 using register variables 39842314.8 lps 10.0 s 7 116700.0 3414.1
Double-Precision Whetstone 3982.0 MWIPS 9.8 s 7 55.0 724.0
Execl Throughput 5258.5 lps 30.0 s 2 43.0 1222.9
File Copy 1024 bufsize 2000 maxblocks 492638.1 KBps 30.0 s 2 3960.0 1244.0
File Copy 256 bufsize 500 maxblocks 152610.9 KBps 30.0 s 2 1655.0 922.1
File Copy 4096 bufsize 8000 maxblocks 1050156.7 KBps 30.0 s 2 5800.0 1810.6
Pipe Throughput 952188.4 lps 10.0 s 7 12440.0 765.4
Pipe-based Context Switching 268401.0 lps 10.0 s 7 4000.0 671.0
Process Creation 12918.3 lps 30.0 s 2 126.0 1025.3
Shell Scripts (1 concurrent) 8094.2 lpm 60.0 s 2 42.4 1909.0
Shell Scripts (8 concurrent) 1046.0 lpm 60.1 s 2 6.0 1743.3
System Call Overhead 817288.1 lps 10.0 s 7 15000.0 544.9
System Benchmarks Index Score: 1160.9

Now, Mitigating Meltdown by switching off CPU caches:

You wouldn’t even want to run UnixBench without CPU caches. Here’s a “simpler” benchmark that tells you why:

# time perl -e 'for (1..1000000) {}'

real 0m0.056s
user 0m0.052s
sys 0m0.000s
# insmod disable_cache.ko
# time perl -e 'for (1..1000000) {}' 

real 0m44.689s
user 0m40.044s
sys 0m0.520s
# rmmod disable_cache

Unless you enjoy working on a system that is some 800 times slower. (Don’t try to do this in a GUI setting.)

Nonetheless, here’s some code to disable the CPU caches. (Modified from https://www.linuxquestions.org/questions/linux-kernel-70/disabling-cpu-caches-936077/)

#include <linux/init.h>
#include <linux/module.h>
#include <linux/smp.h>

MODULE_LICENSE("Dual BSD/GPL");

void _disable_cache(void *p) {
 printk(KERN_ALERT "Disabling L1 and L2 caches on processor %d.\n", smp_processor_id());
 __asm__(".intel_syntax noprefix\n\t"
 "mov rax,cr0\n\t"
 "or rax,(1 << 30)\n\t"
 "mov cr0,rax\n\t"
 "wbinvd\n\t"
 ".att_syntax noprefix\n\t"
 : : : "rax" );
}
void _enable_cache(void *p) {
 printk(KERN_ALERT "Enabling L1 and L2 caches on processor %d.\n", smp_processor_id());
 __asm__(".intel_syntax noprefix\n\t"
 "mov rax,cr0\n\t"
 "and rax,~(1 << 30)\n\t"
 "mov cr0,rax\n\t"
 "wbinvd\n\t"
 ".att_syntax noprefix\n\t"
 : : : "rax" );
}

static int disable_cache_init(void)
{
 on_each_cpu(_disable_cache, NULL, 1);
 return 0;
}
static void disable_cache_exit(void)
{
 on_each_cpu(_enable_cache, NULL, 1);
}

module_init(disable_cache_init);
module_exit(disable_cache_exit);

Makefile:

obj-m += disable_cache.o

all:
	make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules

Note that you need to indent using tabs in Makefile. CR0 can only be read from Ring 0, and thus a kernel module is needed.

Here’s some example code to just read the CR0 registers on all CPUs:

#include <linux/init.h>
#include <linux/module.h>
#include <linux/smp.h>

MODULE_LICENSE("Dual BSD/GPL");

void cache_status(void *p) {
 long int cr0_30 = 0;
 __asm__(".intel_syntax noprefix\n\t"
 "mov %0, cr0\n\t"
 "and %0, (1 << 30)\n\t"
 "shr %0, 30\n\t"
 ".att_syntax noprefix\n\t"
 : "=r" (cr0_30));
 printk(KERN_INFO "Processor %d: %ld\n", smp_processor_id(), cr0_30&(1<<30)>>30);
}

static int cache_status_init(void) {
 on_each_cpu(cache_status, NULL, 1);
 return 0;
}
static void cache_status_exit(void) {
 on_each_cpu(cache_status, NULL, 1);
}

module_init(cache_status_init);
module_exit(cache_status_exit);

And the corresponding Makefile:

obj-m += cache_status.o

all:
	make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules

 

KDE: The Window Switcher installation is broken, resources are missing.

So I was highly displeased with the standard Breeze task switcher, and thought I’d get a few new ones by clicking the star icon next to the drop-down menu where you select the task switcher. My recommendation is “Grid”. Trying to use Grid, all I get is this error message:

The Window Switcher installation is broken, resources are missing.
Contact your distribution about this.

Hrm. So then I Google and look at code, waste time trying silly things, just to postpone this problem for another weekend. Well, it’s the next weekend now, and just when I’m about to dive back into the code… I restart X (i.e. re-login), and when I try to bring the message up one more time… It doesn’t appear anymore, and Grid and all the others are working! I try installing one more, and sure enough, it didn’t work, but one more re-login and tada. So the answer to this problem might be: restart your KDE session.

It’s still a bug though. But unfortunately I’m no longer interested in looking into this bug now. :(

KDE input problems (KDE applications don’t accept input)

On KDE 5.28.0, which is currently the version of KDE included in Debian Stretch, you may run into the following problem: if you run IBus (to work with an IME like Mozc or Anthy to type Japanese), you might find that you sometimes lose the ability to input text in KDE/Qt applications (like konsole, or the run bar (krunner) when you press Alt+F2). It looks like you can fix this by running:

ibus-daemon -r -x -d

Since you can still type stuff in applications that don’t use Qt, such as Firefox, typing the above command into a text area in Firefox, copying and pasting (right click, paste) that text into krunner, then using your mouse to select “Command line: ibus-daemon -r -x -d”, you should be able to get input to work again. If you do not have any non-Qt applications, you could switch to the console and instead do:

DISPLAY=:0 ibus-daemon -r -x d

However, you may need a second hack to get Japanese input to work again: open xterm (not konsole) and activate your Japanese IME (which should work just fine). This seems to cause Japanese input to work again system-wide.

英語で書いてもあまり役に立たないでしょうから、日本語バージョンも合わせて書きます。

Debian Stretch に入っている KDE 5.28.0 に、(IBus が稼働している環境では)KDE/Qt 系のアプリケーションに、時々、何も入力できなくなる不具合があるようです。IBus のデーモンを再起動すると直るので、以下のコマンドを実行してみてください。

ibus-daemon -r -x -d

キーボードが使えないのに、コマンドを実行するのにはどうすればいいですかというと、Qt を使用しているアプリケーション以外の入力はできるはずなので、例えば Firefox のテキストボックスにコマンドを入力、コピーして、Alt+F2 で開ける実行メニュー (krunner) を開いて、コマンドを右クリックで貼り付けて、マウスで実行するように選択すれば、キーボードをほとんど使わずに実行できます。(ショートカットキーは使えるはずです。)
うまくいかない場合は、コンソールで以下のコマンドを実行すればいけると思います。

DISPLAY=:0 ibus-daemon -r -x -d

ただし、これだけでは日本語入力が直らない(場合があります?)。直らない場合は、xterm (konsole などではなく、xterm)を開いて、一回日本語入力に切り替えて、使えるかどうか試してみてください。(使えるはずです。)
これをやるだけで、他のアプリの日本語入力も直るようです。

The Boring Game

I wrote a game! In 2.5 hours, even. It’s a console (as in Linux terminal) game, and written in Perl (5). I’ll call it “The Boring Game”.

You’re the pilot of a sophisticated airplane that does not crash into mountains, but bores tunnels through them. Flying costs money (because you use up fuel). Operating the boring machine attached to your airplane is extremely energy-intensive, and costs a fortune. Boring horizontally is expensive, but wait till you see how much you have to pay to bore up. However, (completed) tunnels are very useful infrastructure, so you get a nice reward every time you make it through the mountain.

The game’s settings are global constants at the top of the source file:

my $USLEEP = 80000;
my @STATE_CHANGE_PROBABILITY = (0.1, 0.4, 0.1);
my $MAX_ALTITUDE = 120; # (1 == one column). Need a few more columns to display the current funds
my $MOUNTAIN_CHAR = '.';
my $MOUNTAIN_OUTLINE_CHAR = '|';
my $PLAYER_CHAR = '@';
my $UP_CMD = 'k';
my $DOWN_CMD = 'j';
my $QUIT_CMD = 'q';

Here’s a YouTube video of the game in action:

You can get the source code at https://github.com/qiqitori/theboringgame.
To play the game, put boring_game.pl in any directory you want, and issue the following command:

perl boring_game.pl

Beach Cleaning in Matsue, Japan

Ocean trash
Ocean trash

Now that I’m living in Matsue, I often find myself not having much to do. Which means I’m usually sitting at my computer or sitting on my bicycle. One of my first destinations was the sea, which is about 10 km north from where I live.

The spot marked “須々海海岸” on Google Maps is overwhelmingly beautiful and saddening at the same time. While the pictures shared on Google Maps may show you that this is indeed a very beautiful spot, most of these pictures do not show that there is a lot of plastic trash on the beach.

So not having much to do, being somewhat young (28 back then) and being reasonably environmentally minded, I one day decided to see if I could maybe help clean this place up. Unfortunately, my Google queries for beach cleanup activities in Matsue didn’t yield any results, so I just decided to buy a pair of (gardening) gloves and a pack of large trash bags and get some cleaning done.

It turned out to be a great way to pass the time (in late spring, when it isn’t crazy hot and mostly not raining), so I kept coming back, and decided to continue until the tsuyu (rainy season) would kick in.

Ocean garbage collection application form
Ocean garbage collection application form

Just gathering the trash is of course not quite enough. You need to get it to the waste processing facilities. So I just went to the town hall and asked the person at the entrance what to do. I was told to go to the “volunteer” department at the 松江市環境センター (Matsue Environmental Office), where I had to fill out a form (pictured) with the following information: personal information, pick-up address (no house means no address, so this is a bit hard, but the guy at the counter really knew his way around town, and showing him the place on Google StreetView helped a bit too), the number of trash bags, cleanup date, next date in case rains gets in the way. After filling out the form, I got the number of Matsue-branded trash bags that I’d put on the form, at which point I had to explain that I’d actually already started cleaning, unfortunately using regular unlabeled trash bags. That was fine, but he told me to use the right bags next time. The form allows you to tick 自己搬入 (bringing in the trash yourself), but you’d probably have to explain yourself if you want to do that. I opted to have a truck pick up the trash I’d pile up at the side of the road, which usually takes place within one week after your cleanup date.

Some collected ocean trash
Some collected ocean trash

Not knowing much about the  recycling facilities here, I generally sorted the trash by type: plastic bottles (of which there are many, many), plastic bottle labels, plastic bottle caps, styrofoam, hard plastic (probably mostly originating from buoys), soft plastic (think polyester), random other plastic. I had no intention of taking care of tree branches/logs, and was in fact told not to pick those up, as they wouldn’t fit into the plastic bags anyway.

Random thoughts

  • Japanese beaches may have a lot of ugly フナムシ (sea roaches). They will definitely crawl all over your bags, so make sure to close them properly. :p
  • This place doesn’t have a lot of people come by, but the people I did meet were quite eager to talk. Mostly older guys who have come out to do some fishing.
  • Carrying the trash bags from the beach up to the road (which is probably a 20 m altitude difference) was pretty tough, but very, um, good exercise. Combined with the 10 km (very much non-flat) ride on the bicycle… it was pretty intense. :p
  • I’ll probably re-commence my cleaning activities when it gets a bit cooler, perhaps in September. Hoping the place won’t be infested by spiders.
  • One day, I found that someone had helped during my absence \o/

KDE graphics problems (flickering windows)

On a Kaby Lake i7 (i7-7700) with embedded HD Graphics 630 on Debian Testing with KDE 5.28.0, I had a problem where the window manager (kwin_x11) would fail in the following way: everything would be fine for a few hours or a few days even, but then windows would flicker a bit, and usually much later window contents wouldn’t be updated until I focused a different window and then back, and after a while the whole screen froze and only the mouse pointer kept moving.

To fix a system that is still half responsive, open the run dialog (Alt+F2) and execute:

kwin --replace

To fix a system where no windows are updated, switch to the console and do:

DISPLAY=:0 kwin --replace

For a more permanent solution, selecting OpenGL 3.1 in System Settings > Display and Monitor > Compositor worked for me on one system.

Cooking Western-Style in Japan

If you’re finding yourself longing for some western dish that is generally not available in Japanese restaurants, perhaps something your mom made when you were child, your only option may be to cook the dish yourself. Maybe this article will help you find the necessary ingredients? If you don’t find your answer here, feel free to leave a comment.

Supermarkets

First of all, if you can’t find what you’re looking for, try a bigger supermarket. If you are in Tokyo, you may have some trouble finding a big one, so here’s a list of supermarket chains that tend to have bigger stores:

  • イトーヨーカドー (Ito Yokado)
  • マルエツ (Maruetsu)
  • ライフ (Life)
  • ダイエー (Daiei)
  • マックスバリュー (Max Value)

In addition, these two places have a strong selection of imported goods and are partially geared towards people buying in bulk:

  • 肉のハナマサ (Niku no Hanamasa)
  • 業務スーパー (Gyoumu Suupaa / Super / Supermarket)

Here are some well-equipped import stores:

  • 成城石井 (Seijou-Ishii)
  • Kaldi Coffee Farm (Weird name, but just a normal store)
  • Lapin (local chain in Matsue, Shimane) has a good selection of imported goods

Stocks

This is a very popular stock for western foods: Ajinomoto Consomme. According to the ingredients it includes both chicken and beef extracts. There are other stocks available, including chicken, beef, and vegetable stocks, but not all supermarkets have all of these. Beef stock feels a bit less common, and vegetable stock almost rare.

Milk products

Milk products are quite pricy in Japan. You can get milk, yoghurt, cream, sour cream, and various types of cheese at most supermarkets. Butter is available, but often sold out. (Reportedly, especially before February 14.) The types of cheese available at supermarkets are as follows:

  • Shredded cheese (practically everywhere — usually imported and consisting of cheddar, gouda, mozzarella) (unless you buy in bulk, expect to pay 100-200 JPY per 100 g)
  • Those wrapped square processed cheese slices (practically everywhere) (about 200 yen for a pack of ~10 slices)
  • Cream cheese:
    • Philadelphia (available at most supermarkets) (about 400 yen for a 200 g pack) (you’ll sometimes find a cheaper, very similar product by メグミルク (Meg-Milk))
    • Camembert* (available at most supermarkets)
    • Cottage cheese (available at some supermarkets)
    • Mascarpone* (available at some supermarkets)
      * Not sure if these count as cream cheeses
  • Mozzarella (round balls) (available at many supermarkets, but about 300 JPY per 100 g)
  • Parmesan cheese (available at most supermarkets in powder form)
  • Cheese in tiny portions to be eaten as a tsumami (can be quite high-quality)
  • Cheese in small portions to be eaten as a snack (I recommend さけるチーズ (sakeru chiizu))

Bigger supermarkets may sell packets of non-sliced gouda and/or cheddar. For other kinds of cheese, you may have to try an import store or the basement floor of an expensive department store. (Note: you’ll pay about 1000 JPY per 100 g of cheese at the department store.)

By the way, here are the reasons butter is often hard to get (from what I’ve gathered):

  • Milk products are made according to a priority production system:
    milk, cream > cheese, yoghurt > butter
  • Low-fat milk isn’t very popular in Japan

Condiments

Ketchup, mayonnaise and mustard are available, but Japanese mayonnaise is made differently and tastes a bit different. You can get western-style mayonnaise at import shops like 成城石井 (Seijou-Ishii). There are three types of mustard that are widely available in Japan: Japanese mustard (からし, karashi), French Dijon mustard, American yellow mustard. Karashi is similar to wasabi or horseradish in pungency. Ketchup appears to be about the same as everywhere else.

As for vinegar, you will find at least wine vinegar (red and white) and balsamic vinegar. I’ve never seen malt vinegar in shops, but it appears to be available on Amazon.
The most common types of vinegar are 穀物酢 (kokumotsu-su, grain vinegar) and rice vinegar. Grain vinegar is pretty cheap, but I wouldn’t recommend buying it over the slightly more expensive rice vinegar if you intend to use it in food. (Of course, our mileage may vary.)

Oil

  • Olive oil is widely available
  • Vegetable oil is widely available (often rapeseed or sunflower)
  • Flaxseed oil (亜麻仁油) is usually available in bigger supermarkets (very pricy though)

Aromatic vegetables

Onions, scallions, leek, garlic, green peppers, and carrots are all widely available. Celery stalks and leaves are often available, but I’ve never seen celery root. Shallots are rare.

Other vegetables

  • Widely available: broccoli, spinach, cabbage (red cabbage isn’t that widely available), lettuce, tomatoes, eggplant, cucumbers, bell peppers, radish (daikon)
  • If you’re into pumpkins/squashes, Japan has kabocha: green outside, orange inside, both parts being edible. That’s the only type of squash that I’ve seen, but very widely available.
  • Slightly less common: cauliflower (expensive (300 JPY for a small head) in Tokyo, cheap (150+ JPY for a larger head) in Shimane), zucchini (usually not available in winter)
  • Usually not available in supermarkets: Brussels sprout, kale (I’ve seen both though)

Everything else may be difficult to find.

Canned vegetables

The Gyoumu Supermarket generally shines in the canned goods category.

  • Canned tomatoes are widely available, usually for less than 100 JPY
  • Canned corn is widely available (also the only item in this category that has a good chance of not being imported)
  • Canned/glass-jarred olives are often available at supermarkets. You can get them cheapest at the Gyoumu Supermarket.
  • Canned (white) asparagus is often available in supermarkets. Green asparagus is often available fresh, especially in spring. Fresh white asparagus is available sometimes, but a bit pricey
  • Canned/glass-jarred pickled cucumbers (gherkin) are available at many supermarkets, but pretty pricey. Try the Gyoumu Supermarket

Legumes (Beans)

The Gyoumu Supermarket shines here, too.

  • Canned kidney beans are available in most supermarkets. Some supermarkets may have dried beans. Definitely available at the Gyoumu Supermarket
  • Canned chickpeas are slightly less common than kidney beans, but still reasonably available. Definitely available at the Gyoumu Supermarket
  • Lentils are pretty rare. Try Seijou-Ishii and similar supermarkets. Not available at the Gyoumu Supermarket, as far as I know
  • Broad beans are sometimes used in Japanese cooking, and thus sometimes available fresh. Otherwise they may be available dried
  • Normal green beans (いんげん, the long ones) are available frozen at the Gyoumu Supermarket, and sometimes fresh
  • Regular peas are available frozen

Fresh herbs

Most supermarkets with a non-tiny vegetable section will have parsley. If it’s a bigger supermarket, they will probably have other fresh herbs. Basil is the most common. You’ll often find rosemary and sage.

  • Parsley (commonly available)
  • Basil (reasonably commonly available)
  • Mint (if basil is available, mint is probably available too)
  • Rosemary, sage, chervil (available in some stores)

Everything else may be difficult to find, but have a look at SB’s lineup of fresh herbs.

Non-fresh herbs and spices

Most herbs and spices that I’m familiar with are mostly available.
Here are some herbs that might be hard to find in stores: caraway, non-generic varieties of paprika, marjoram. (Try Amazon if you can’t find your favorite herb or spice in the stores.)
Most stores sell herbs and spices in tiny bottles containing 3-10 g of actual product. In the case of paprika, you’re likely to use up the entire bottle for a single meal. If you regularly use a certain herb or spice a lot, you may be better off buying in bulk from Amazon.
For curry mixes, you usually have two choices: Garam Masala and a typical mix that produces the flavor of Japanese curry.

Mushrooms

  • Common mushroom (commonly available, but expensive, though much cheaper here in Shimane)
  • Oyster mushroom (ヒラタケ, hiratake) (commonly available, and not quite as expensive) (also used in Japanese cooking) (never used it)
  • Hen-of-the-woods (舞茸, maitake) (commonly used in Japanese cooking and therefore commonly available and cheap; works well in many western dishes)
  • Porcini are only available in dried packs, and most supermarkets don’t seem to have them

Meat

  • Beef is expensive, and often imported from the US or Australia
  • Pork feels neither expensive nor cheap, and is usually Japanese produce
  • Chicken feels very cheap, and is usually Japanese produce

You can get minced meat of all of the above. Occasionally, you’ll find a supermarket that doesn’t have minced beef. (This seems to be a more common occurrence in Shimane.) The most common type of minced meat is a mix between beef and pork.
Most supermarkets will also sell steaks, but you’ll probably pay 1000 JPY or more for a decent-sized one.
Wiener sausages are available at virtually all supermarkets. Most supermarkets will have a small selection of non-wiener sausages. If you want to eat decent sausages, I recommend the こだわり生フランク (kodawari nama-furanku) from the Gyoumu Supermarket. I think these are probably among the best sausages you can buy in Japan.
Other types of meat may be hard to find, but some supermarkets have mutton now.

Fish

Lots of fish in Japan.
Smoked salmon, canned tuna and canned anchovy are available. Herring is available, but soused herring isn’t. (Justification for this factoid: I know a Japanese guy who loves soused herring.)

Nuts

All nuts that I’m familiar with, except hazelnuts, are available at most supermarkets, though (unless they’re peanuts) usually quite expensive.

Flour

Most supermarkets have only two types of flour: 薄力粉 (hakurikiko) and 強力粉 (kyourikiko). Hakurikiko is cheaper, and is usually used for cakes, cookies, okonomiyaki, and tenpura. Kyourikiko is used for bread. Both are non-whole-wheat. To get whole-wheat, rye, and other types of flour, go to Seijou-Ishii or similar import stores.

Carbs

  • Japanese rice works just fine in western dishes (including risotto)
  • Potatoes are expensive. They’re more used as a vegetable, rather than a source of carbs in Japanese cooking
  • Frozen french fries are available. You can get them much cheaper at the Gyoumu Supermarket than at most other places
  • Pasta is available, but I have a feeling that the cheap stuff tastes a bit odd. ~100 yen per 250 g seems to get you good quality. (I kind of have a feeling that low-quality pasta tends to get some unwanted flavor from its packaging.) Small supermarkets often only have spaghetti or fast-cooking pasta
  • Cornflakes are widely available
  • Oatmeal is starting to appear in store shelves
  • I’ve seen couscous at Kaldi Coffee Farm and Lapin in Matsue
  • Bread is explained in the next section

Bread

Perhaps we’ve come to the most disappointing part of this article. (Note that I’m not trying to be objective in this paragraph.)
White bread that you would toast before eating is ubiquitous. Other kinds of bread will be harder to find. Bread that contains a small percentage of rye is becoming more common these days, but bread with a significant ratio of rye, let alone pure rye bread, is exceedingly rare. There are bakeries in Japan, but if you go into one, you’ll often find that filled bread is way more common than “naked” bread. If you’re lucky, you’ll find something without any fillings, but most will be white bread: baguettes, croissants. Many bakeries will sell something called パン・ド・カンパーニュ (Pain de campagne), which may be quite passable. (It uses sourdough.) If you don’t have an obvious bakery in your vicinity, try some of the chains:

  • Anderson http://www.andersen.co.jp/ is quite okay.
  • Linde (http://www.lindtraud.com/) in Tokyo has pretty good bread.
  • The best bread I’ve had in Japan was from Maison Kayser in Sunshine City in Ikebukuro, Tokyo. However, when I went to check them out (on May 28, 2017), they didn’t have any dark bread for some reason. :(
  • High-quality supermarkets like Seijou-Ishii usually have decent bread too.

By the way, this raisin and walnut stone oven bread tastes very nice and is possibly available at many Aeon stores.

So what to put on your bread? Japan doesn’t have a large selection of spreads, but peanut butter, nutella, (at least) strawberry jam, cheese (see above), and some types of meat are available at most supermarkets. In supermarkets, you’ll often see small Real salami is pretty expensive. Seijou-Ishii and the Gyoumu Supermarket usually sell bruschetta spreads.

You’ll often see peanut butter and strawberry jam being sold in small containers for about 120 JPY that look like in the image pictured here on the right. This stuff, especially the peanut butter, tastes pretty bad, in my opinion. The cheap price may entice you to buy this, but don’t say I didn’t warn you. :p