Archive

My Firefox (or rather Iceweasel) is prone to constantly spinning and eating about 50-70% CPU on average when should be supposed to just sit idle. I tried to find the root cause, but Javascript profiler sees nothing and other forays didn’t end up with much (I discovered that spinning progress wheel when some tab is forever loading amounts to about 20% CPU, though). Not sure if always, but sometimes it spins within WebGLImageConverter::run() (no callgraph, sorry).

So in the end I decided to treat the symptoms instead. Cleaning my CPU fan helped with the noise, but the main problem is that running firefox brings my battery life to about 1/2 to 1/3. So one obvious solution would be to just stop the damn process when I don’t use it. I typically don’t do background downloads while on battery (or otherwise), so that means I want it stopped when the window is inactive – not in focus. This is surprisingly exotic idea, apparently, and not easy to do in most window managers.

I even tried switching to awesome or i3 window managers which should make this easy, but I’m psychologically not up to that; I think I’m too conservative, but I decided not to stick with that. I use the MATE desktop environment with marco window manager. Perhaps switching to sawfish would be a good option, but in the end I just decided to write a shell script that will periodically assess the situation and suspend or resume firefox as needed. Of course this introduces extra wakeups and ambient CPU load, but when powertop reports that my GoogleTalkPlugin (running at all times for whatever reason) wakes up 150 times per second, the powersaving situation on Linux is still too messy – so who cares?

Here goes the script, in the hope that it will be useful for someone else too. Run it in a terminal or backgrounded in your ~/.xprofile, it will stop the firefox process when out of focus for more than 10s and on battery, and resume it within a second when switching back. In practice, I found these timings completely acceptable so far, and didn’t notice any ill effects of constant STOP/CONT either.

I recently switched to xterm-256color in my konsole, but I found that vim looks exceedingly ugly, unfortunately. The colors were all washed out and difficult to read with reduced brightness. I decided to explore some alternative color schemes, including popular ones like solarized etc., but they just don’t work for me – I have the default color scheme burned into my mind and I really like its high contrast even though I can easily stare at it for 12+ hours in a row. It also works great even in adverse light coditions on a notebook.

In the end, I didn’t find any dark vim color scheme that would just look like its default 16-color color scheme. (Light background color scheme looks mostly the same in 16 and 256 colors by default.) So I had to create my own – 256like16.vim, drop it in ~/.vim/colors. You may want to edit yours to add some more bolds to make it look exactly like the 16-color scheme, but I ended up liking this one more, after all.

(You will need to install colorsupport.vim so that GUI color settings are used in the 256-color terminal. This particular script worked by far the best for me, and :ColorSchemeBrowse is also great when exploring schemes.)

Call me old-fashioned but I’m still using xterm on my desktop computer (where I use just fluxbox as my window manager) – it suits me just fine, but for one thing that I finally managed to solve. xterm by default ignores the clipboard, and none of the previously published solutions cut it for me, until now.

In X11, we have two commonly used selection buffers – PRIMARY and CLIPBOARD:

PRIMARY is used when you simply highlight text in most applications, without pressing anything, and you can paste from it using the middle mouse button; it is of fleeting nature and used for quick cut’n’paste; and it doesn’t work well with all applications, e.g. libreoffice doesn’t put highlighted stuff there at least in some contexts and non-textarea HTML5 text edit widgets usually can’t handle the middle button for pasting.

CLIPBOARD is used when you use ctrl-c or ctrl-v and can be used even with the evil applications above, but the problem is it’s not supported by xterm well!

In most terminal emulators, you can use the clipboard either using menus or shift-ctrl-c / shift-ctrl-v. However, in xterm, the best you can do is either…

Have a different set of bindings for selection to PRIMARY and CLIPBOARD. This is a lot better, but I’m out of modifiers since I use shift to cut’n’paste in terminal applications that use mouse themselves (e.g. elinks).

So, my solution is to bring in the shift-ctrl-c / shift-ctrl-v bindings! In your ~/.Xresources or ~/.Xdefaults, add

Now, you can use shift-ctrl-v for pasting from CLIPBOARD, and almost use shift-ctrl-c for copying to clipboard. There is a catch – you must press shift-ctrl-c while you are still holding the mouse button, i.e you press left mouse button, drag your selection, then before releasing it, press shift-ctrl-c; thankfully, that can be done by one hand without too much cramping.

It’s a bit inconvenient because of this bug, and doesn’t quite work with left and right selection; maybe I will sometime get around to adding true clipboard support to xterm code, but I think this is good enough for me at this point. :)

I don’t send email from my notebook often, dealing with my correspondence on my server machine via ssh. When I need to do it, it’s usually when I’m sending Git patches or something like that. I didn’t meet much trouble with sending it directly, but SMTP servers of Debian-involved people are some of the most picky one can meet and I decided it’ll be best if I switch the exim4 on my notebook to smarthost mode where all mail is relayed via my main server.

So that should be trivial to do, right? Wrong, apparently. I figured I’d use SMTP auth, but it just seems mind-bogglingly complicated to configure if you don’t want to spend an evening on it. The client part is fairly easy (probably both on exim4 and postfix), but setting up postfix server to do SMTP auth (for just a single person) is really silly stuff. Maybe not so crazy if you use PAM / shadow for authentication, but that means that on my notebook, I’d have to store (in plaintext) my server password anyone could use to log in – no way. It seems I could switch to Dovecot and somehow pass it a simple password to use, but at that point my patience ran out and I just backed off a litle.

Why not just use ssh for smarthost SMTP transport? Authentication via ssh is something everyone understands nowadays, it does the best job there, no silly passwords involved and you can just pipe SMTP through it. You wouldn’t do that at in a company setting with Windows notebooks, but for a single geek, it seems ideal.

sudo -u Debian-exim /bin/bash
ssh-keygen # go with the default, and empty password, this will be used in an automated way
ssh me@server.example.org # to fill up known_hosts; it will fail yet
cat ~/.ssh/id_rsa.pub # this is my public key
exit # ..the sudo

Set up ssh key on server – paste the public key printed by the cat above to ~me/.ssh/authorized_keys and prependcommand="nc -w1 localhost smtp",no-agent-forwarding,no-port-forwarding,no-X11-forwarding to the key line. This key can now be used only for mail relaying.

Do dpkg-reconfigure exim4-config and configure smarthost mode. Also use it to find out whether you are using split or big configuration. You will also probably want to enable “mailname hiding”, otherwise your return-path will contain an unroutable address.

Inspired by the Debian CTTE deliberations on the new default init for Debian, I installed systemd on my notebook after tonight’s forced reboot and played with it a little.

(And I like it! I was very sceptical when hearing about systemd first, but after reading a lot of discussions and trying it myself, I find most of the problematic points either fixed already or a load of FUD. The immediate big selling point for me is actually journald, it and its integration with systemctl is really awesome. I’ll actually find systemd more useful on servers than desktops, I think.)

While it’s a nice exercise for anyone wanting to get familiar with systemd, I still decided to share a tidbit – service file that will make log entries show up on /dev/tty12. Many people run with rsyslogd set up for this, you’ll want to disable that (by default, all journal entries are forwarded to rsyslog). The advantage of showing journal entries instead is mainly color coding. :)

(I did not get h264 FLV stream working reliably, unfortunately. I tried #transcode{vcodec=h264,venc=x264{keyint=20},vb=4096,scale=1} and duplicate{dst=http{mux=ffmpeg{mux=flv},dst=...,select=noaudio}.)

One commercial project I was working on for Raspberry Pi involved playing various MP3 samples when a button is pushed. The original implementation used mplayer to play back the samples, however the issue is that there was up to 1500ms latency between mplayer was executed and start of playback.

I didn’t do detailed profiling, but I think two factors causing high latency of mplayer were that (i) just loading all the .so libraries mplayer depends on can take many hundreds of milliseconds (ii) the file is being scanned for whatever stuff, streams detected etc. and that can also take some extra time; perhaps I could force mplayer to realize this is a simple MP3 file, but (i) is still the much bigger factor.

I wanted to avoid recoding all the samples to wav. That would allow me to use aplay directly and the playback starts immediately, but it would also feel really silly; decoding of MP3 is not the bottleneck, just the latency of mammoth software loading and initializing itself is. I also didn’t try mpd as that might have been a bit painful to set up.

Another point worth noting is that I didn’t use the crappy on-board PWM audio but a $3 chinese USB soundcard (which is still much better than PWM audio). And using reasonably up-to-date Raspbian Wheezy. So I tried…

mplayer -slave -idle, started in parallel with my program and receiving commands via FIFO. It hangs after the first file (even though it works fine when ran without -slave).

cmus running in parallel with my program, controlled by cmus-remote. Convincing it to use ALSA device of my choice was really hard, but eventually I managed, only to hear my files sped up about 20x.

madplay I couldn’t convince about using a non-default ALSA device at all.

mpg123 started immediately and could play back the MP3 files on a non-default ALSA device. Somehow, the quality was very low though (telephone grade) and there was an intense high-pitched clip at the end of the playback.

mpg321 I couldn’t convince to produce any sound and anyway it had about 800ms latency before playback started, probably due to its libao dependency.

sox, or rather AUDIODEV=hw:1 play worked! (After installing a package with MP3 support for sox.) No latency, normal quality, no clips, no hangs. Whew.

Verdict: There still is a software on Linux that can properly and quickly play MP3 files on Raspberry Pi, though it was a challenge to find it. I didn’t think of sox at first and I was almost giving up hope. BTW, normally you would use sox and play for applying a variety of audio transformations and effects in a batch/pipeline fashion and it can do a lot of awesome magic.

For about 13 years now, I’m running the Muaddib IRC bot that serves a range of Czech channels. Its features varied historically, but the main one is providing conversational AI services (it learns from people talking to him and replies back based on the learnt stuff). It runs the Megahal Markov chain algorithm, using the Hailo implementation right now.

Sometimes, I need to reset its brain. Most commonly when the server happens to hit a disk full situation, something no Megahal implementation seems to be able to deal with gracefully. :-) (Hailo is SQLite-based.) Thankfully, it’s a simple sed job with all the IRC logs archived. However, Muaddib always had trouble with non-ASCII data, mixing a variety of encodings and liking to produce a gibberish result.

So, historically, people used to talk to Muaddib using ISO-8859-2 and UTF8 encodings and now I had mixed ISO-8859-2/UTF8 lines and I wanted to convert them all to UTF8. Curiously, I have not been able to quickly Google out a solution and had to hack together my own (and, well, dealing with Unicod ein Perl is never something that goes quickly). For the benefit of fellow Google wanderers, here is my take:

It relies on the Encode::decode() ability to specify a custom conversion failure handler (and the fact that Latin2 character sequences that are also valid UTF-8 sequences are fairly rare). Note that Encode 2.35 (found in Debian squeeze) is broken and while it documents this feature, it doesn’t work. Encode 2.42_01 in Debian wheezy or latest CPAN version (use perl -MCPAN -e 'install Encode' to upgrade) works fine.