Ubuntu Spyware

On few occasions I noticed that some "zeitgeist" daemon running on my Ubuntu 12.04 system takes a lot of CPU cycles, so it had to be killed. Today, clearing off my disk, I also noticed that it eats noticeable chunk of it (100MB+). I proceeded to investigate what Zeitgeist is, finally. Here some links and comments:

1. Tutorial on GNOME Activity Journal, Zeitgeist and Sezen describes it as a universal user's interaction logging system.
2. I was never asked if I want to install or enable such system and/or logging during Ubuntu install/upgrade.
3. It turned out that daemon was installed and running automatically, but frontend app (gnome-activity-journal) wasn't installed.

So, this thing collected my activity without my consent and behind my back, and clearly not for the purpose of letting me use that data. This all pretty matches the definition of trojan spyware. In addition to that it also eats system resources and makes system running slow.

Few people share the concern that Zeitgeist is exactly spyware and not some productivity tool, future of Linux user interface and other marketing bullshit from Gnome3 and Canonical:

• http://martesmartes.blogspot.com/2011/12/zeitgeist-spyware-delivered-with-linux.html
• http://askubuntu.com/questions/227111/can-i-trust-ubuntu-even-though-stallman-calls-it-spyware-what-about-zeitgeist
• http://forum.prisonplanet.com/index.php?topic=191577.0

How to remove Zeitgeist: http://martesmartes.blogspot.com/2012/06/even-nicer-little-improvement-in-linux.html

Overall situation with spyware on Ubuntu, from Richard Stallman: http://www.fsf.org/blogs/rms/ubuntu-spyware-what-to-do .

Buffalo SkyStation CWR-GN150S Teardown

Walking last few hours thru Hong Kong streets and molls during last visit, I was looking for some impulsive shopping, and bought micro-router having following labels: Buffalo SkyStation CWR-GN150S, Hornington NE-GN150S, etc. What lured me was its really small size (5.5x4.5x1.7cm) and 2 Ethernet ports. It was also couple of bucks cheaper than TL-WR703N. I was thinking where's the catch, and later got it - it doesn't have USB host port (micro USB it has is only for power).

All manual for the router is in Japanese/Chinese, same for firmware, no English firmware on Internets, actually, barely any English pages at all. Teardown was even more disappointing: it has only 16MB of RAM (bye, OpenWRT), and turned out it uses RTL8196C SoC, infamous for being of MIPS-Lexra architecture, which is MIPS subarch crippled due to patent trolling between MIPS vendors. There's barely any support for this subarch from gcc and OpenSource projects, I found just one brave guy who tries to change the situation:

• http://ncrmnt.org/wp/2011/08/30/rtl8196-vs-openwrt-2/
• https://github.com/nekromant/linux-rlx-upstream

 Well, I added hacking on all this stuff to my (very long) queue. In the meantime, just posting this to let other folks to google it up.

Overriding install prefix in build systems

Following up with reviewing capabilities of various build systems in previous post, recently I looked how to build all packages with custom --prefix and friends values. This is continuation of Optware for Android project, where I'd like to achieve ability to install on non-rooted device.

Here are the results:

• I was surprised at first, but OpenWRT has --prefix hardcoded as /usr when calling configure. Fortunately, that call is in common file, so it would be easy to introduce configurable variable instead. However, it turns out that install routines, which are individual for each package, have /usr hardcoded either, so each recipe needs to be patched still, which is problem for maintainability and/or upstreaming.
• Looking at Optware, situation is even worse - there, there's even less common infrastructure, and even configure call is hardcoded in each script with --prefix=/opt.
• Buildroot, being prototype for OpenWRT, has the same hardcode at /usr.
• I obviously turned to OpenEmbedded at that point (well, I tried Yocto this time) - it for sure always have had nice configurable variables for prefix and all other layout variables (--sysconfdir, etc.). Turned out, while variables are there, OE/Yocto is not ready out of the box to full configurability of both prefix and base_prefix. There were few issues seen:
• Compiler search path issues. Some aspects of search paths (mostly related to shlib linking) appear to be not stored by gcc when configured during cross-compiler, and require command-line overrides. OE passes --sysroot on each invocation, but I had to add few -rpath-link directives to get it right. While it took some time to figure the need for -rpath-link, I'm still not sure I figured where to put them (well, per upstreamability criteria).
• Some packages still hardcode paths, especially related to base_prefix. Sometimes it's a bit harder than trivial to patch (like with busybox).
• Ordering issues. Some packages implicitly assume that base_prefix and prefix are different, and filter filesets during packaging by file prefix. This doesn't work if base_prefix==prefix, so requires reshuffling filtering patters and/or package order (fortunately, OE has well-defined package splitting order).