Or if you do.. Well done! you really know your way around obscure and vast manpages. :-)

Among the millions of zsh features i will be presenting you with some pretty useful ones for daily use.

1. esc-.
   insert the last argument of the previous command in history, repeat to cycle through commands/arguments in history.
2. esc-'
   quote the whole line. (for use with su -c, ssh et al).
3. esc-q
   clear the current line and insert on next blank prompt (useful for inserting interim commands).
4. !"
   got a command with many ! but too tired to escape all of them in order to not call upon history? just prefix it with a !” ( “ left intentionaly unclosed).
5. =zsh
   expand to the full path in $PATH ( eq to which zsh ).
6. !$
   use last command’s argument.
7. !$:h
   use last command’s argument, strip a level, add more :h to traverse the levels.
8. vi =(foo)
   process substitution, use vi to edit the output of foo.
9. <file
   is like “more < file”.
10. >file
    is like “cat > file”.
11. >>file
    is like … you guessed it, “cat >> file”.
12. !:t another
    history exp trick, this one strips the path in the previous command giving you the basename only.
13. !-2\$:r
    talking about history lets get a little more complex. second to last command, first parameter without file extension.
14. for i (*.c) { ... }
    pretty much self-explanatory, shorter way to write a for loop.
15. vared
    edit variables from the comfort of your zsh prompt.
16. hash -d name=path
    another awesome feature is the ability to have named directories. you create one like that and you can cd to it from anywhere using cd ~name.
17. echo $foo:e
    get the extension of $foo (the opposite of :r).
18. repeat n
    run a command n times.
19. alias -s tex=vim
    now running somefile.tex in zsh will open somefile.tex with vim.
20. tetris
    all work and no play makes jack a dull boy! thus zsh has a tetris mode to help you relax at times. just load the module and assign it to a key or something!
21. zftp
    when dealing with a lot of ftp stuff, this module can save you hours by automating the process through shell scripts.
22. ^r
    search history by greping the history file, ( can be “/” if using vi input mode).
23. ^a
    go to the beginning of line.
24. ^e
    same for the end of it.
25. zmv
    the Z shell Programmable rename/move .. a BEAST that with enough loving can trully perform miracles.
26. zle
    the Z shell line editor .. another module that needs a book of its own.
27. ls /u/s/d/m/e<tab>
    the shorter version for ls /usr/share/docs/mutt/examples
28. you can setup directory specific configs for use with different projects, ref: mika’s conf on mika’s blog.
29. ls -l *(.L-100)
    list all files in the current dir that are less than 100bytes in size (ignore directories).
30. ls -l *(Lm+50)
    list all files and dirs in the current directory that are more than 50 Megabytes in size.

Bonus:
{% codeblock lang:sh %} kapow(){ touch ~/.pow/$1/tmp/restart.txt; if [ $? -eq 0 ]; then; echo “pow: restarting $1” ; fi } compctl -W ~/.pow -/ kapow {% endcodeblock %}

this gem from Christofer Sexton will let you quickly restart an app in pow.

As announced in July 2011 , the openSUSE Xen maintainers intended to discontinue support for 32-bit Xen host in openSUSE12.1. Now that 12.1 has been released, we are hearing complaints from users virtualizing on older P4-based systems. I understand their frustration, but given that the upstream Xen community has ignored the 32-bit host, and no other distros are supporting it, we can no longer justify the effort required to support it. Supported 32-bit Xen packages are going by way of the dodo, and dropping them in openSUSE may very well mean extinction.

That said, users still have a few options. First, we have quite stable 32 and 64-bit Xen packages in openSUSE11.4. The Xen version is 4.0.3, which has all the latest upstream fixes and improvements for the 4.0 branch. In fact, the package sources are shared with SLES11 SP1 and benefit from the broader user-base and QA of the enterprise product. openSUSE11.4 contains kernel version 2.6.37, which has excellent support for older P4-based hardware.

Another option is using the openSUSE Build Service to maintain your own 32-bit Xen packages. In fact, the community itself can maintain 32-bit Xen in the Virtualization project if there is enough interest. We will be happy to accept any patches that do not break 64-bit environments :-). One benefit of this option is that the openSUSE Factory Xen packages are developed in the Virtualization project. A community maintained, 32-bit Xen host in this project would be submitted to Factory, and hence included in the next openSUSE release, as part of the overall Xen package submission done by the openSUSE maintainers.

So, the year changed again and with it come quite often new decisions. Some swear to work out the superfluous kilos, pounds, or whatever standardized measure your country uses, gained too fast during the festivals. If it is your decision, it is for sure good for your body and I wish you success that goes beyond the act of subscribing to a local gym (and never appearing there after first month).

But this could be also a nice time to take a decision that you were procrastinating with for too long. That one is good for your intellect and programming skills (even though you don't consider yourself a programmer yet). What about starting to contribute to a Free and Open Source Software project (FOSS)?

Sounds interesting? So I have one for your. It is having a big and growing community. It can accomodate all levels of skills. And the impact you will have is multiplied by the wide addoption of the product itself.

Well, you must have guessed right by now. I am speaking about the LibreOffice project, your natural entry point into the marvelous world of the FOSS.

Whether you are expert or beginner programmer or C++ is sounding Chinese Traditional for you, just find a way to join channel #libreoffice-dev channel at irc.freenode.net in order to meet other developers and visit our Easy Hacks for ideas where to start.

I promis you that a year from now, you will not regret that you have started. Although, it is quite probable that you will pour a tear over an unused year-pass from the local gym.

Using drbd as a simple and reliable alternative to distributed block devices is quite common. Especially in primary/primary mode, it provides the possibility to host block devices for virtual machines on two different hosts.

However, there is one annoyance that any active user stumbles over at some point in time. After a network restart, it may happen, that the devices switch to standalone mode and do not even try to reconnect to their peer. The reason for this is, that when doing a network restart, the device is shut down for a short time. DRBD itself has no means to wait for hotplugging devices, and thus just cuts the network connection in that case.

I know of two methods to solve that issue on the operating system side.

1. Create a script in /etc/sysconfig/network/scripts/ifup.d that contains the necessary code to reconnect the drbd device to its peer
2. The easiest way I know about is to switch the network interface to startmode nfsroot.

To accomplish this, edit the configuration file of the device that is used to connect to the peer, like e.g. /etc/sysconfig/network/ifcfg-eth0 and change the line

STARTMODE='<auto|manual|onboot>'

to

STARTMODE='nfsroot'

This changes the behavior of the networking scripts to not shut down the interface during a network stop or restart event. However, when using this method, I still would recommend monitoring the connection state of drbd in /proc/drbd.

I’ve been working at Mozilla on Firefox Mobile for a few months now. One of the goals of the new native UI is to have liquid smooth scrolling and panning at all times. Unsurprisingly, we do this by drawing into an OpenGL texture and moving it around on the screen. This is pretty fast until you run out of content in the texture and need to update it. Gecko runs in a separate thread and can draw to a buffer there without blocking us, but uploading that data into the texture is where problems arise. Right now we use just one very large texture (usually 2048x2048), and glTexSubImage2D can take anywhere from 25ms to 60ms. Given that our target is 60fps, we have about 16ms to draw a frame. This means we’re guaranteed to miss at least one frame every time we upload, but likely more than that. What we need is a way of uploading texture data asynchronously (and preferably quicker). This is where direct textures can help.

If you haven’t read Dianne Hackborn’s recent posts on the Android graphics stack, you’re missing out (part 1, part 2). The window compositing system she describes (called SurfaceFlinger) is particularly interesting because it is close to the problem we have in Firefox. One of the pieces Android uses to to draw windows is the gralloc module. As you may have guessed, gralloc is short for ‘graphics alloc’. You can see the short and simple API for it here. Android has a wrapper class that encapsulates access to this called GraphicBuffer. It has an even nicer API, found here. Usage is very straightforward. Simply create the GraphicBuffer with whatever size and pixel format you need, lock it, write your bits, and unlock. One of the major wins here is that you can use the GraphicBuffer instance from any thread. So not only does this reduce a copy of your image, but it also means you can upload it without blocking the rendering loop!

To get it on the screen using OpenGL, you can create an EGLImageKHR from the GraphicBuffer and bind it to a texture:

#define EGL_NATIVE_BUFFER_ANDROID 0x3140
#define EGL_IMAGE_PRESERVED_KHR   0x30D2

GraphicBuffer* buffer = new GraphicBuffer(1024, 1024, PIXEL_FORMAT_RGB_565,
                                          GraphicBuffer::USAGE_SW_WRITE_OFTEN |
                                          GraphicBuffer::USAGE_HW_TEXTURE);

unsigned char* bits = NULL;
buffer->lock(GraphicBuffer::USAGE_SW_WRITE_OFTEN, (void**)&bits);

// Write bitmap data into 'bits' here

buffer->unlock();

// Create the EGLImageKHR from the native buffer
EGLint eglImgAttrs[] = { EGL_IMAGE_PRESERVED_KHR, EGL_TRUE, EGL_NONE, EGL_NONE };
EGLImageKHR img = eglCreateImageKHR(eglGetDisplay(EGL_DEFAULT_DISPLAY), EGL_NO_CONTEXT,
                                    EGL_NATIVE_BUFFER_ANDROID,
                                    (EGLClientBuffer)buffer->getNativeBuffer(),
                                    eglImgAttrs);

// Create GL texture, bind to GL_TEXTURE_2D, etc.

// Attach the EGLImage to whatever texture is bound to GL_TEXTURE_2D
glEGLImageTargetTexture2DOES(GL_TEXTURE_2D, img);

The resulting texture can be used as a regular one, with one caveat. Whenever you manipulate pixel data, the changes will be reflected on the screen immediately after unlock. You probably want to double buffer in order to avoid problems here.

If you’ve ever used the Android NDK, it won’t be surprising that GraphicBuffer (or anything similar) doesn’t exist there. In order to use any of this in your app you’ll need to resort to dlopen hacks. It’s a pretty depressing situation. Google uses this all over the OS, but doesn’t seem to think that apps need a high performance API. But wait, it gets worse. Even after jumping through these hoops, some gralloc drivers don’t allow regular apps to play ball. So far, testing indicates that this is the case on Adreno and Mali GPUs. Thankfully, PowerVR and Tegra allow it, which covers a fair number of devices.

With any luck, I’ll land the patches that use this in Firefox Mobile today. The result should be a much smoother panning and zooming experience on devices where gralloc is allowed to work.