Archiv

Archive for the ‘oss’ Category

Increase avatar size in bbpress

I needed to increase the image dimensions for the avatars in bbpress. There is no direct filter available which lets you change the size for a specific avatar location. From the forums, I gather that you have to edit the template. I managed to make it work using the filter system. The filters get called for every avatar location, so I base my heuristic on the requested avatar size. The default ’small‘ avatar size is 14px and nearly useless. These are displayed inline. The faces next to the postings are 80px by default. I increased them to 110. Bigger images would likely break the formatting.

<?php
function my_bbp_change_avatar_size($author_avatar, $topic_id, $size) {
    $author_avatar = '';
    if ($size == 14) {
        $size = 24;
    }
    if ($size == 80) {
        $size = 110;
    }
    $topic_id = bbp_get_topic_id( $topic_id );
    if ( !empty( $topic_id ) ) {
        if ( !bbp_is_topic_anonymous( $topic_id ) ) {
            $author_avatar = get_avatar( bbp_get_topic_author_id( $topic_id ), $size );
        } else {
            $author_avatar = get_avatar( get_post_meta( $topic_id, '_bbp_anonymous_email', true ), $size );
        }
    }
    return $author_avatar;
}

/* Add priority (default=10) and number of arguments */
add_filter('bbp_get_topic_author_avatar', 'my_bbp_change_avatar_size', 20, 3);
add_filter('bbp_get_reply_author_avatar', 'my_bbp_change_avatar_size', 20, 3);
add_filter('bbp_get_current_user_avatar', 'my_bbp_change_avatar_size', 20, 3);
?>

Note that we hook up three different filters. You can play around with different avatar locations this way, but I couldn’t be bothered to find out the details. The first one is for some inline avatars (likely for the topic author only), the second one probably for inline avatars for reply authors. The last one probably is for the avatars displayed next to full postings.

We also need some CSS:

/* We increased the tiny avatar size, so adjust the position */
#bbpress-forums p.bbp-topic-meta img.avatar, #bbpress-forums ul.bbp-reply-revision-log img.avatar, #bbpress-forums ul.bbp-topic-revision-log img.avatar, #bbpress-forums div.bbp-template-notice img.avatar, #bbpress-forums .widget_display_topics img.avatar, #bbpress-forums .widget_display_replies img.avatar {
    margin-bottom: -2px;
}
/* Increase max-width for the big avatars */
#bbpress-forums div.bbp-forum-author img.avatar, #bbpress-forums div.bbp-topic-author img.avatar, #bbpress-forums div.bbp-reply-author img.avatar {
/*margin: 12px auto 0;*/
max-width: 110px;
}

There is a filter available that will simply change the default avatar size, but that is only available for the user detail page – e.g. the profile. The code in BBPress looks like this:

<?php
echo get_avatar( bbp_get_displayed_user_field( 'user_email', 'raw' ), 
                       apply_filters( 'bbp_single_user_details_avatar_size', 150 ) );
?>

I wish the authors had included this for every avatar location.

Bonus – Better Editor

By default, current BBPress releases only include the default HTML editor toolkit. Very useful. To get TinyMCE back, install bbpress-enable-tinymce-visual-tab and enable TinyMCE in Settings->Forums. I use the twentythirteen theme and the mode switching tabs (text<->visual) look weird. I also found the image insertion dialog horribly broken. Some CSS fixes that:

/* Fix tab switch in TinyMCE BBpress */
.wp-editor-tabs .wp-switch-editor {
    padding-top: 0px;
}

/* Hide image embedding widget in TinyMCE BBpress.
 * It's just horribly broken.
 */
#bbp_topic_content_image {
    display: none;
}

Kategorien:informatik, oss

Web2py, JQuery Mobile and Caching

So I’ve been playing around with JQuery Mobile to build a nice mobile version of my web2py app. Once I had that running, I wanted to make the website load a bit faster, because waiting about five seconds is way too much! Time to install the Google Pagespeed extension into my trusty Firefox, set the UA string to something iphone-is and look at the recommendations!

Compression

The Pagespeed extension complained about my files not being compressed. Some googling turned up the necessary .htaccess magic to enable mod_deflate on HTML, CSS and JS files. The transfer size went down from 448kb to 124kb! That’s an insane improvement. Still, there was some work left. Speaking from memory, this took page load time from about 5s down to 3.4s.

Proper Caching

Another complaint by the pagespeed extension was the caching: I needed to set the expires header! By setting the timestamp in the expires header, you tell the browser not to worry for a while and just fetch the file from cache. If you don’t set that header (or „cache-control“, alternatively), the browser will perform a conditional request, asking the server „hey, did that file change since last time I downloaded it?“. This is not a lot of overhead, but still, setting the „expires“ header can save us quite a few network requests.

Modifying the header via .htaccess did not work because web2py was already setting it in gluon/main.py. Apparently, if there is a timestamp included in the file name, the expires header is set to a date in the far future. This technique is called URL fingerprinting. I decided not to care and just hardcoded the expires header for all static files. This will eventually come back to bite me. The result for this tweak: page load time went down from 3s to 1.85s with a warm cache! The 3s case was with a warm cache and conditional requests – each request took 500ms to execute and not all of them were parallel. Page load time with cold cache was 3.4s!

To Do

All requests are currently handled via the CGI interface. Letting Apache handle static files directly would likely increase performance and magically make the expires header work without having to hack web2py.

The real WTF

JQuery: 91.4kB, JQuery Mobile: 141.1kB, JQuery Mobile CSS: 92.4kB. That’s about 300kB of code. I have not done any benchmarking yet to determine parsing and execution time, but it would seem that 300kB of code is a bit excessive for a puny mobile device.

 

Kategorien:informatik, oss

Pogoplug B04 und Owncloud

Arch Linux ARM läuft nun auf dem Pogoplug. Installation war schmerzfrei. Kurze Notiz zur Installation von OwnCloud:

  • pacman -S owncloud php-apache php-sqlite
  • Config-dateien gemäß Ausgabe editieren
  • Apache starten
  • Die Adresse des Pogoplugs aufrufen mit / als pfad
  • Wenn du ein anderes Datenverzeichnis möchtest, musst du in /etc/httpd/conf/extra/owncloud.conf den pfad für openbasedir ergänzen
  • in /etc/php/php.ini muss man zusätzlich noch iconv.so und openssl.so aktivieren; das sagt OwnCloud aber
Kategorien:livehacking, oss

FHEM 5.3 on OpenWRT with WOL

I’ve finally installed the FHT80b thermostat in the bathroom. While I was fiddling with FHEM, I figured I wanted to use WOL for my media box. This required an update to FHEM 5.3.

On the OpenWRT box, some additional steps are required. My FHEM instance does not run with root privileges, so I’m also setting some +s bits.

# opkg install etherwake
# ln -s /usr/bin/etherwake /usr/bin/ether-wake
# chmod +s /usr/bin/etherwake

Ping is also provided by busybox, but I did not want to +s the whole busybox binary, so I installed a dedicated ping binaryand removed the symlink from /bin/ping to /bin/busybox.

# opkg install iputils-ping
# chmod +s /usr/bin/ping
# rm /bin/ping

Kategorien:informatik, oss, wohnung

RTF: Fail and you

As with any programming gig, you are bound to encounter some interesting fails.

One of our customers is providing RTF files generated by a third party. To do the silly little things we computational linguists tend todo – a bit of information extraction here, some sentiment analysis there – I convert the RTF to HTML using rtf2html to process it with BeautifulSoup.

But, of course, the umlauts are broken: any umlaut in the generated HTML is preceded by an @ sign in my editor, which turns out to be 0 – a null byte. This caused some pre-emptive facepalms because I knew I was in for some pain.

Looking at the relevant section in the RTF document, I see the following:

\uc2 M\u228\’00\’E4rz

This is supposed to „März“. I found the download for the 1.91. RTF spec on microsoft.com where you can choose between .doc and .docx. Microsoft, this is bad and you should feel bad.

The spec tells me that RTF initially was not unicode-aware. When unicode was introduced in a later revision, they decided any characters which are not ASCII should be represented by their Unicode code position preceded by \u. Following this unicode representation, a close representation of the character in the declared codepage for the document should be used. In our case, the representation consists of two ASCII characters: \’00 and \’E4. The \uc2 keyword tells unicode-enabled RTF readers to skip 2 characters after the unicode character because they’re obviously redundant.

The unicode presentation here is \u228 which properly points to „ä“. For RTF readers which are not unicode-enabled, the unknown \u keyword is simply ignored and the regular \’xx representations in the declared codepage are used.

So we have two fails here:

  • rtf2html does not support Unicode. This is no big deal per se as the RTF spec is backwards compatible in this regard, but me being a big fan of Unicode, I will consider it s a minor fail. If rtf2html supported unicode, the broken document would be displayed properly
  • the alternate representation of the Unicode character is broken. The declared codepage is cp1252, so why would you ever use a two-byte replacement? Interestingly enough, \’E4 is indeed the correct cp1252 code for „ä“.

Specs are hard. Let’s go shopping. Do people actually test their software before they deploy it? I’m either going to patch rtf2html to ignore 0 (which will probably break other documents in equally hilarious ways) or add proper unicode support which should not be too hard.

Kategorien:informatik, oss

Formatting your SD card as EXT4 in Android

7. Dezember 2011 2 Kommentare

I was thinking about formatting my SD card as ext4 for my android phone, as fat32 sucks in several ways. Android does not support this out of the box, with the most problematic limitation being the file permissions on ext4. fat32 has no fancy ACL, while ext4 actually supports file permissions. Given that every app on android runs as its own uid/gid, this is of course problematic, especially for shared directories.

But first things first: we need patches for vold to make Android accept the ext4 fs on the file system. Current Android 2.3 based distributions such as CyanogenMod 7 already come with the necessary file system drivers, so it’s just a matter of telling vold everything is going to be OK. Additionally, we need a patch for the recovery system to make it mount the sdcard properly. You can probably do without this patch if you manually remount /sdcard in the recovery, e.g. using adb. In any case, a working recovery is not necessary for day-to-day operation but it will come in handy if fecal matter starts hitting the ventilation device. The patches can be found on xda, thanks to user DebauchedSloth. A pre-compiled vold is provided by user Xziped.

This will make Android mount the ext4 formatted SD card properly. There’s still the permission problem, however. Several solutions are proposed.

  • Run chmod 777 every once in a while to fix permissions
  • Monitor the sdcard for changed/new files and run chmod accordingly
  • Use yet another patch provided by DebauchedSloth which uses a FUSE-based utility to transparently ignore file permissions, mimicking fat32 behavior on any file system. (ticket 1928, ticket 1929)

These options, in my not so humble opinion, all suck. I’m not going to fuck around with a terminal regularly just to have an usable phone. I also don’t believe that constantly monitoring the file system for changes will improve battery life or performance. The third approach with FUSE apparently kills performance.

I propose a fourth workaround, as fixing Android core itself is obviously not going to happen – people need to read their SD cards on windows and only neckbeards like me care about ext4 at all. My workaround would consist in adding a mount option to ext4 to essentially ignore file permissions, or rather report 777 for everything back to the VM layer. It looks like fs/ext4/acl.c might be relevant here.

Frankly, I do not care enough right now to make this happen. And yes, I am aware that my proposal still seems indicative of crystal meth consumption.

As an additional caveat: Android saves some app data on the sdcard in /sdcard/.android-secure – until I understand what exactly is going on there, I’d probably be wary of just mocking around with permissions. On the other hand, it’s unlikely to result in problems, because what will be more insecure than fat32?

Kategorien:android, oss

Current OpenWrt setup

Just flashed OpenWRT Backfire10.03.1-rc4. Flashing via mtd did not work – most likely PEBKAC – so I made some use of WIFI tethering on the trusty Android phone and installed tftp. Five minutes later, I’m back up and running. Neat. Coming from Kamikaze, one of the more notable changes would be the switch to a 2.6

kernel for the WRT54Gs. Now, what do I do with this small box now that its doing basic routing?

Statistics and Graphs

To get some graphs in the Luci web interface, install luci-app-statistics. Unfortunately, this seems to need a lot of space in the flash file system. This plugin depends on collectd, hence the disk space requirements. I have no clue how to get this working: I see the config option, but I’m not seeing any graphs. Perhaps I need to wait for a cron job to run? Removing it again so I can actually install other stuff…

 

Quality of Service / Traffic Shaping

luci-app-qos: configure traffic shaping/QoS to make sure your SSH and XMPP don’t suffer when doing bulk file transfers over HTTP. Configuration is under Essentials -> Network -> QoS. Took me a while to find that.

The only thing you need to configure is the speed of your internet connection. If you go use a service like http://www.wieistmeineip.de/speedtest/ you might find that your speed is way too low. In my case, I had accidentally enabled QoS in the init script settings with the default setting of 1MBit/s download speed, which obviously is too slow. So, disable QoS and measure again. Then plug the numbers into the QoS config.

Since it’s saturday night, I’m not getting good numbers, so let’s postphone this..

SSL support for the web interface

luci-ssl: SSL support for luci. For some reason, my router rebooted after installing this. However, luci is now available over HTTPS. Neat! If you want to disable regular HTTP access, drop to a shell and execute „uci delete uhttpd.main.listen_http && uci commit“. Apparently, this is not yet possible within Luci itself.

Dynamic DNS

    luci-ddns: dynamic dns support, will update your account on dyndns.org and friends. Seems to work!

    Keeping time current

    luci-app-ntpc: keep the time on your OpenWRT device in sync with NTP servers. Configuration will show up in System -> Time Synchronisation. Seems to work.

      Also see the OpenWRT wiki for more Luci goodness.

      Hints:

      • in Luci, first hit „Update package lists“ under „System -> Software“ to get a list of packages other than those already installed.
      • if you’ve installed a new module and it doesn’t show up, `rm /tmp/luci-indexcache` in a shell on the device and reload the web interface in your browser.
      • occasionally, luci/firefox will choke when you navigate away from a loading page. This manifests as an error message about broken XML in the browser. Usually, the new page will load anyways.
      • Do not remove luci-theme-openwrt.

      Okay, so I upgraded from OpenWRT Kamikaze to Backfire10.03.1-rc4 and I’m not that happy. The router has rebooted spontaneously about four or five times by now while I was using Luci. This might be related to the increased load when using the web interface, who knows.

      In any case, it shouldn’t be happening at all. Other things, like the fact that newly installed packages not showing up in the Luci menu, or the extremely slow web interface, certainly don’t make for a good impression.

      However, this is OpenWrt: it’s not bad. From prior experience, I expect the base of the system to be in good shape. So, ignoring the web interface, I’ll just leave this box running and hope it’ll continue to work as unobtrusively as before on Kamikaze. This optimism is mainly motivated by the fact that I’m too lazy to go back to Kamikaze and configure everything again. I haven’t even tried WLAN yet..

      Kategorien:livehacking, oss