Shared Memory in Unix - System V vs POSIX API

Many Linux/Unix developers these days already forget the "Unix" war of the 80s and 90s, whereby System V camp (i.e. the "commercial" camp) fought against the opensource (BSD) camp. Recently, I found the relic of those days, lingering in IBM Unix-like API. The system I worked on is not exactly Unix per se, but it has compatibility APIs for IBM AIX API.

Enough with the background story. Now, the task at hand need me to craft a solution requiring shared memory and semaphore API. I was surprised that the said environment doesn't support shm_open() POSIX API. Upon further scrutiny, the system doesn't support all shm_XXX() API. This is where I took a step back and try to look back into the platform history to get the big picture. Then I realize that this system is what was once described as System V compliant. This "standard" predates POSIX to some extent, before Linux and other BSD-derived Unix took to the enterprise. In those times, the enterprise Unix market was mostly served by big Unix vendors, i.e. IBM, HP, Sun, SCO, etc. That was when the System V standard were "ratified" for their customers. Now, back to the problem. If shm_XXX() POSIX APIs are not supported, then what API I'm supposed to use? The answer is the shmXXX() API. Instead of shm_open() and such, you get shmget() and such. Linux and most BSD-derived Unix of today also support the System V API as well. So, these System V APIs could be thought of as portable among most operational Unix system of today.

These are several links explaining how to use the System V shmXXX() family of APIs:

• http://www.cs.cf.ac.uk/Dave/C/node27.html
• http://docs.oracle.com/cd/E23824_01/html/821-1602/svipc-2.html

Hopefully, this saves the days of those poor souls (who were like me) trying to use shared memory in "Legacy" Unix-like systems. 

GLSL 3.30 in Intel Haswell CPU

This error could show up while trying to run your OpenGL program that uses GLSL on Haswell:

$ error GLSL 3.30 not supported.. 

It's very probably because you don't specifically ask the OpenGL implementation (in this case mesa) for Core Profile because only Haswell OpenGL core profile supports GLSL 3.30, as shown in this Haswell glxinfo dump:

....
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Haswell Mobile 
OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.4.5
OpenGL core profile shading language version string: 3.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
....
OpenGL version string: 3.0 Mesa 10.4.5
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
....

As you can see, the non-core profile only supports up-to GLSL 1.30. Now, how do you go about asking core profile in your OpenGL application? If you are using freeglut, you can use these functions:

...
#include <gl\freeglut.h>
...
int main(int argc, char * argv[])
{
...
glutInitContextVersion(3,3);
glutInitContextProfile(GLUT_CORE_PROFILE);
...
}

Remember that the initialization code above must be called when you initialize your OpenGL environment. Also, it only applies if you use freeglut library.

Using Windows Key in Fluxbox

It's easy to add Windows-specific key to Fluxbox. All you have to do is as follows:

1. Find out how Xorg server recognizes the key. You can use xev for this. You can run xev from xterm or other terminal and observe the name of the specific-key shown in xev log. For example, the Windows key in my laptop is recognized as Super_L by Xorg.
2. Add the key to ~/.fluxbox/keys file. 

Let me give you an example. Let's add Windows key (Super_L) to my Fluxbox keys configuration file and let the key invokes Fluxbox "root" menu when pressed. This is the snippet from ~/.fluxbox/keys file for this function to work.

#  Windows Key -- show root menu
Super_L :RootMenu

That's it. That's all you need to make Windows key to work as you expected (analog to how the Windows key work in Windows).

Adding Lock Screen to Fluxbox

It's easy to add lock screen to Fluxbox. You have many options but I'll stick to xscreensaver because it's the most bug free and standardized. For those using Arch Linux, just "pacman -S xscreensaver" and you get all that you need to run xscreensaver.

Adding the menu to Fluxbox is easy. I added the lock screen menu to ~/.fluxbox/usermenu. The additional menu entry as follows:

[separator]      
[exec] (Lock Screen) {xscreensaver-command -lock} 
[separator]      

I added the separator to make the menu entry stand-out, to reduce the possibility to inadvertently click it. This is how it looks like in my Fluxbox "root" menu (the lock screen menu entry color is inverted for emphasis):

You have to start the xscreensaver "server" upon starting Xorg. In my case, I add the following line to ~/.xprofile:

xscreensaver -no-splash &

Pay attention that you have to make sure that ~/.xprofile is parsed by ~/.xinitrc when you start Xorg. This is my ~/.xinitrc:

#!/bin/sh

# Make sure this is before the 'exec' command or it won't be sourced.
[ -f /etc/xprofile ] && source /etc/xprofile
[ -f ~/.xprofile ] && source ~/.xprofile

# Parse .Xresources
[[ -f ~/.Xresources ]] && xrdb -merge ~/.Xresources

exec startfluxbox

Hopefully this is useful for others using Fluxbox out there.

Adding New Menu Entries to Fluxbox

In this post I assume that you're using Fluxbox 1.3.7 or newer. In this version of Fluxbox, adding new menu entries to the "root menu" (the one shown when you right click on the desktop) consists of these steps:

1. Add the menu entries in ~/.fluxbox/usermenu
2. Run fluxbox-generate_menu

Editing ~/.fluxbox/menu directly is not recommended. However, I recommend you to read the file to get an idea about the syntax to create menu entries and submenus. Therefore, we would just add the new menu entries in usermenu file. This is an example:

      [exec] (Evince Reader) {evince} 
      [exec] (File Manager) {pcmanfm} 

Usually, usermenu is empy, unless you have alter it previously. The configuration above means I added two entries, i.e. Evince Reader and pcmanfm file manager to the root menu. Once usermenu file is ready as shown in the configuration file above, I run fluxbox_generate-menu to create the new root menu in Fluxbox. This is the result:

As you can see, the new menu entries are now integrated into fluxbox root menu.