Braindead X11 Clipboard Exposed

I've been using Linux with X11 as GUI system as my primary and only work system for like 6 years now. It's great, much better than another world - asymptotically.  But there're few issues which sustain - an  being hated - for years. One of them is how clipboard in X11 works. It works illogically, unpredictably, and non-reliably. Based on many years' background black-box analysis, there appears to be more than one clipboard buffer, and some apps apparently take clipboard with themselves when they quit.

It finally came a right moment to both be hit by it and have time to investigate. This blog post shares the same sentiment as I above, and confirms suspected design braindeadness.

To quote:

Three selections are defined in the ICCCM: CLIPBOARD, PRIMARY, and SECONDARY, each of which behaves like a clipboard in its own right:

• CLIPBOARD: traditionally used when text is copied and pasted from the edit menu, or via the Ctrl+C and Ctrl+V shortcuts in applications that support them.
• PRIMARY: traditionally used when a mouse selection is made, and pasted with middle-click or Shift-Insert.
• SECONDARY: ill-defined secondary selection. Most applications don't use it.

Be gone soon, X11, be replaced by something sane.

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 .

NSLU Optware for Android

Yes, there was kind of attempt at that already, but:

• It's no longer available at the link announced and spread over the Internet (yep, it's available at another, but why so ... complicated?)
• It ships binary blobs of unknown origin. Yup, maybe one could trace their origins, but who'd bother, and telepaths are on vacation as usual. It should be described stringently where they are from, if not scripted to be collected in user's build directory from known good sources, so users can actually trust them.
• It is marketed as supporting only something called "Nook Color". What's that, I thought it was Optware for Android? Could I have Optware specifically for my HP nx9420 notebook, serial number XYZZY, 3Gb of RAM? Just make sure it's different from the Optware for the same notebook, but with 4Gb of RAM, and from any other Optwares in the world!
• It goes as far as patching rootfs ramdisk. That may work on Nook Color or may brick it. That may work on next firmware upgrade of Nook Color or may brick. That may work on another device or may brick. The talk is not about this, it's about the fact that it's two big differences - to be able to install and run bash and to have sshd started automatically after the boot. I definitely want first, but I will do good consideration if/when I need second. So, I don't want setup for those 2 stages to mixed and done without myself being ready for stage 2.
• It still appears to rely on presence of some other 3rd party stuff (look at that #!/bin/sh line, there's no such thing on pristine Android device, only #!/system/bin/sh)

So well, I decided to take my turn on hacking up an Optware bootstrap script for pure Android (root and adb access are the only prereqs). It's hosted here: https://github.com/pfalcon/optware-android and intended to be run on a Linux hosts. It starts by downloading CodeSourcery toolchain for libc and ipkg and immediate dependencies from http://ipkg.nslu2-linux.org/feeds/optware/cs08q1armel/cross/stable to bootstrap ipkg on device. Yep, it's being tested on Nook Tablet so far, but at least it is called Optware for Android and I have that aim ;-). So, bugreports and patches are welcome. And I have few more devices to test it on, just steal me some time...

Thoughts/notes on Android version upgrades and reusing Android drivers

So, what it takes to upgrade Android on an arbitrary Android device (from user perspective)? What takes to run Linux in full-fledged mode? This boils down to few things:

Kernel porting

Upgrade kernel. This means forward-porting hardware support modules to a new kernel version. That's, when source code for such modules is available. Sometimes, it's not violating GPL (or tainting kernel, but who wants that? ;-) ). In an ideal world, that would all that's needed, but vendors don't like GPL, and try to move stuff outside of kernel. So, the list continues.



Bitblt acceleration porting

Next step is making sure that basic hardware acceleration works - accelerated bitblt/compositing (defining compositing as bitblt with alpha). This is actually pretty important step - without accelerated bitblt, Android with more or less big screen will run pretty sluggishly. Well, X Windows won't run too zippy either. Bitblt code in Android lives in /system/lib/hw/copybit.*.so  and depends on gralloc.*.so from the same dir (* there is vendor/implementation identifier - Android support multiple, pluggable implementations). Needless to say, for a random device, source for these modules are not available - vendors don't have to provide it, it's Apache2-licensed, and very few choose to uphold OpenSource spirit nonetheless. So, if new Android version have changes the ABI for those modules, then oops - upgrade is "not possible" is layman terms. Of course, real men will immediately think about writing adapters, etc...

What about other X and other "foreign" windowing systems? They would need drivers/adapters too, and base all their low-level FB access based on Android's gralloc/bitblt/etc. model.

OpenGL ES porting

Last, least, but nonetheless. Curse of the modern world - OpenGL. You didn't have it on your Apple 2 (I mean Apple 2, yes, not what you thought about!) and everything was great, wasn't it? Apart from games you don't have time to play, what it's useful for? Yes, as soon as we'll stream videosignal directly into the brain, it will be useful for augmented reality, but I mean, *useful now*. They keep talking they added some hardware acceleration using OpenGL to the normal UI, then immediately say it didn't work that great, and depends on many things, because... Because OpenGL simply doesn't work that great, yeah. For example, even "accelerated", it's pretty slow, buggy, inconsistent across devices, etc, etc.

Anyway, thanks for listening to the rant. Let's de-emphasize usefulness of OpenGL, let's just take it as a challenge - vendors hacked it, so why can't hackers hack it? The basic idea is the same as with bitblt - there's an interface between closed vendor OpenGL ES implementation and Android. If interface changed, you're hosed. I mean, you write adapters. You also write adapters to make it talk with your windowing system of choice, and not Android. The core interfacing part of OpenGL ES/Android junction is EGL. How to deal about it is worth a separate post.

Critical review of build systems

Last time I looked at possible alternatives to OpenEmbedded, I mostly looked at how many packages they support, how many architectures/OSes, and how easy is to add overrides. Of course, OpenEmbedded outperforms any other generally available build system in these respects.

But still, while the idea of grand unified build system is very cool, maybe it would be easier to add/extend support for some non-Linux OS to some other build system? (As OE is targetted at Linux.) Let's see.

GUB
This software tries to steal "grand unified" motto, though so far it has 200+ packages, but supports Windows. Recipes are structured as Python classes, overrides are handled like:

class Ctypes__mingw (Ctypes):

 One thing which immediately catches eye is "def patch (self)". Yeah, Python doesn't let people play with curlies, but they'll go out fo their ways with braces. Recipes-classes do allow deal of declarativeness, for example, in specifying patches, and yet there're stuff like:

    def patch (self):
        self.system ('''
cd %(srcdir)s && patch -p1 < %(patchdir)s/busybox-mkconfigs.patch
''')

Summary: Violates standard codestyle for target language (PEP8), breaks declarative vs imperative metadata separation.

mingw-cross-env
Targets mingw32 (only). Doesn't support DLLs. Uses .mk for recipes. Both recipes and other files (patches, etc.) lie in one flat directory. Recipes look clean, but one target and no sharedlibs is trivial case on its own.

Samba and iptables UDP broadcast issues

Have been having issues with browsing Samba from Windows boxes or vice-versa for years, like me? No wonder - just google for "ip_conntrack_netbios_ns site:samba.org". See? It's not documented or even mentioned that that kernel module must be loaded for NetBIOS broadcasts to get thru firewall, except for one recent post, even though the issue was raised and solved 5 years ago: https://bugzilla.redhat.com/show_bug.cgi?id=113918 .