Nicolás Brailovsky

Unix trivia day: in the olden days of the 90’s there were a lot of Unix boxes out there named “elvis”. Nowdays it’s not uncommon to find one, either. Have you ever wondered why are there so many boxes called elvis?

This is related to Solaris’ ping command. When you ping $HOST it prints “$HOST is alive” (if it’s responding the pings), thus elvis is alive!

A log time ago, in a galaxy far away, I posted a list of stuff I apt-get’d as soon as my Buguntu install was ready. Well, fast forward to KK and this is the new apt-get script:

Quite a progress I’d say, as these are mostly programs I use which don’t come in the default install (even though they should). You know, I even have hopes for the sound system in my notebook this time…

An interesting topic for a change: is Linux binary portable? That is, can we take a binary file and be sure it’ll run in any other Linux system? What happens if we broaden that to any POSIX system, will it blend? Eh, I mean, will it run?

Doing some research on the subject I wrote down a list of the thought process which led my to an (inconclusive) answer:

1. First we should define what a binary is for us: When we talk about a binary we are usually thinking about a compiled binary file, not an interpreted script file like Ruby or Python. Those are for people who like things to actually work, so let’s focus on a compiled executable file, like a C/C++ application.

2. Defining compiled file: What could it be other than a sequence of bytes the microprocessor can understand? Yes, that’s right, it’s sort of interpreted code, only there’s electronics behind, not more code. This brings us to the first interesting conclusion: the executable must be (leaving emulators aside) compatible with the architecture you’re on. Running Sparc? Well then, the binary better be compiled for Sparc because otherwise to the uP will not make any sense.

3. Format: as any other thing, a binary file must have a format. That is a standard which defines the structure the file will follow. ELF is the binary format for Linux and it’s quite standard. Of course, if the binary format is a standard then we should get perfect portability between different platforms running on equal architecture. Unfortunately that’s not the case.

4. (Cont’d) Why don’t we? The binary depends not only on compile time “stuff” but a loading time linking occurs: the executable binary will get linked with the system files like glibc, or any other dependency on a shared library it may have.

So, what are the keypoints for Linux binary portability? Architecture, binary format and system libraries.

Of course, making the executable run is only part of the equation, as running and segfaulting on the spot is not so nice either. For this last part you’ll have to closely follow the standards defined by POSIX for paths and stuff like that.

Epilogue

As an epilogue, we could add that Windows binary compatibility tends to be great. Running binaries from 12 years back is no small feat, yet this leads to a whole lot of other problems: an incredible complex loader, security bugs, backwards compatibility headaches, et al. The old new thing is a great source of information for this topics, I’m quite illiterate about Windows binaries nowdays

Followup links

• http://evanjones.ca/portable-linux-binaries.html
• http://autopackage.org/docs/devguide/ch07.html (I swear this one was working when I wrote this text… a year ago)

Oh, talking about binaries:

Remember my problems with dual screen support in Ubuntu? Well, I still love bashing Ubuntu, and the sound system in Linux is certainly a topic to rant a lot. Making the sound work fine in Ubuntu is an odyssey in pain and frustration, unless it works fine out of the box. And even if it does, it may still have it’s kirks. Lots of them. In my case the sound starts in mute. I know it’s a problem with pulse (which is a WTF in itself) and alsa, I don’t really care what’s the problem though, I just want to play my mp3s collection without having to carefully turn the knobs up to eleven in alsamixer.

After trying a lot of the “solutions” found on the internets I’ve decided the best thing to do, short of switching back to windows me, is adding the following to my “fix_ubuntu_fuckups.sh” start script, which already contains my dual-screen pseudofix:

This sets alsamixer to normal volume levels. As for the real fix, I’ll wait till the next Ubuntu version. I wonder which sound subsystem will they chose next time.

I’m quite sure I have written about this before but I’m too lazy to search for the article right now. Well, dual screens in Ubuntu still sucks. Much less than ever before, granted, but it still works quite bad. In my specific case the whole desktop is shown, in both monitors (which by itself is a huge improvement over previous versions) but the working area is clipped to the notebook’s monitor size. Not nice.

To fix this problem (more like hacking it away, actually) I keep a handy bash script in the top left corner on my desktop:

Also, as I have two nice rotable monitors at work it’s nice that now Ubuntu supports actually rotating the picture displayed in the monitor (thanks Ubuntu for coming up to speed… with windows 98, that is). Obviously I keep another script for this, as it doesn’t really work by default:

Even though I love bashing Ubuntu (and bash) I’m quite confident most, if not all, of this issues will be gone in future versions of the OS.

It’s been a long time since I posted a Linux related tip. Not in the mood I guess… well, this is one which really annoyed me, until I found out how easy it is: I hate some of the default file associations in gnome. Movieplayer, for example, is a horrible choice. Breaking and devolving with each new distro release, I have decided to settle with vlc as my default movie player, yet I couldn’t easily change the default file type association. After fiddling around with the thingy in gnome resembling a regedit (ugh) I found out the easy way:

* Right click the file for which you want to change default associations and click properties
* Select “open with” tab
* …
* Profit!

Few things look cooler than debugging a multithreaded application using TUI through ssh on a client, halfway across the world. There you are, felling the geek of the century when all of the sudden gdb starts jumping from one thread to the other. OMFGBBQ! What are you going to do now?

The scheduler locking policy defines when will thread context swtiches occur. If you are debuging a thead and don’t want to be bothered by another then just lock the scheduler.

gdb has a default scheduling locking which defaults to “most annoying”, but fortunately you can easily change it:

set scheduler-locking

The possible values are:

• off: Disable locking, switches threads whenever gdb damn pleases
• on: Enable locking, won’t (ever) switch threads. Beware of deadlocks!
• step: Disable locking while running only

Hopefully this will save you some time.

The other day I had to create one of those “enum to string” functions. They really suck, always getting out of sync, so I made a script to auto-update the header file containing this function… just add a target to the makefile and you’re done!

Anyway, this is the part of the script I came up with to get the enum elements:

cat enum_definition.h | sed -n ‘/enum OID/,/\}\;/ s/\(.*\)/\1/p’

Nice voodoo, isn’t it? How the hell are you supposed to understand that? Well, you’re not, sed is write-only-code, but you can try reading http://www.grymoire.com/Unix/Sed.html#toc-uh-25, a great sed introduction.

Have fun!

A little known fact about gdb is that you can use it in graphics mode, called TUI. Yes, you can obviously use DDD or a similar front end but that’s not even nearly as cool as using a console based GUI (!), is it?

The easiest way is to start gdb like this:

gdb -tui

That will display the usual gdb console plus a code listing, similar to the code listing you get using the “list” command but shown in another window. Alternatively you can press C-X C-A (both, in that order) while in gdb to switch between TUI mode and back.

Don’t know enough about gdb? Read http://beej.us/guide/bggdb/, a great gdb intro.