the (un)real thoughts of realbt

I have spent a lot of time in the last few days arguing with the Linux Standards Base compiler, which is an altered version of GCC that links against LSB-standardised libraries and such. It should act exactly the same as regular GCC, at least in terms of functionality and command-line argument parsing.

The main issue I ran into was exporting symbols on a shared library that are being exported from a static library. What am I talking about? Well, if you speak gcc…

g++ -shared mylib.a mylib2.a -o mysuperlib.so

(Notice I’m using static libraries as filenames, not with the -l library option. It doesn’t make a difference which you use.)

So imagine mylib.a exports some symbols that I want my mysuperlib.so (shared library) to also export. By default, these symbols aren’t needed, so they won’t be exported. This is intended behaviour of the linker since it doesn’t have any knowledge that it should export the symbols, since the linker will only pull out symbols from the static library that it thinks it needs. This is why if you did the same above with object files, it will work as you would probably want. The linker knows you want to link against the entire object file when you link against one — but when you link against a library archive (a static, .a file), it only knows the parts it should “pull into” the linking by what you’re linking against.

The solution to this is to tell the linker to include the whole library (archive).

g++ -shared -Wl,--whole-archive,mylib.a -Wl,--no-whole-archive,mylib2.a -o mysuperlib.so

The -Wl switch passes instructions to the linker. We only want to include the entire library of mylib.a, not mylib2.a — which is why we use –no-whole-archive afterward.

The above code works great. As does the following variation:

g++ -shared -Wl,--whole-archive mylib.a -Wl,--no-whole-archive mylib2.a -o mysuperlib.so

Notice the space instead of the comma after the –whole-archive switch. g++ deals with this fine.

Would you believe lsbc++ (the LSB c++ compiler) does not work with the altered version? It’s true. There seems to be a difference in the way it parses command-line options, even though they are both based on the same code-base. Any guesses as to how long it took me to figure that out?

It all started in June. I decided I would buy a bike and start cycling to work. Over a hill, and over a bridge, the trip takes only about 20 minutes — which is usually a little bit faster than taking transit. It’s good exercise, and cheaper than transit (bike not included).

Off I went to Sport Chek to buy the cheapest bike I could find.

$109 + tax later, I had a cheap bike.

Within a few weeks, my front tire came loose. Something in the axel went funny, and the wheel rotated on its axis ever so slightly. That’s not good. So I took it back and had them fix it. Warantee service #1. The friendly bike mechanic at the store gladly fixed it, but said that it would likely happen again because it’s a cheap bike, with cheap parts.

Granted, when you pay $100 for a bike, you don’t expect it to last for ever. Daily use was not what was intended for this bake, apparently. But that’s like saying that if you buy a cheap car and the transmission falls out four weeks later, it wasn’t intended for daily use.

So my cheap bike was nicknamed Adam, after Adam Sandler and my altered version of one of his dumb songs: Piece of Shit Bike.

Skip ahead about 6 weeks. I was riding home, just about to go over the Burrard Bridge, when my gears went all funny. My chain didn’t fall off (although that has happened countless times), but it went all funny, and I could no longer shift into 6th gear. I managed to climb over the bridge, and even up all the hills. But as soon as I got to the top, the gear sproket thingy on the rear tire came all loose. When I peddled, the chain turned through the sproket thingy, but the tire didn’t turn. Nice. Good thing I made it to the top of the hill first.

Warantee service #2.

Today, I took my bike back and had a chat with the same friendly bike mechanic. First, I asked for my money back. No dice. Then, I asked if there was anything else that could be done (trying to avoid having the bike serviced a second time in as many months). The manager became involved and offered me an exchange for another bike. I was able to talk him down a little bit lower on this bike.

Another $180 + tax later, and I now have a bigger and lighter frame, a better bike, and a larger bill. Or at least I will when I pick it up tomorrow after work.

So much for the flight of my cheap bike. Intending to spend under $200, I’ve now spent nearly $300. How did that happen?

Let’s hope the new, yet to be named, bike works out better.

Much controversy surrounds the plain text vs. HTML email debate. And apart from the ideological debate (which consumes most of the debate), there are a number of technical problems (which translate into usability issues) that arise from either type.

Let’s start with the introduction of mobile devices: PDAs, cell phones, wireless email toys, BlackBerries, etc. These came long after the plain-text days of Pine. Typically these do not handle richtext formatting. When email is sent as HTML (and when the email client behaves properly), a plaintext copy of the original message is included in the envelope. This ensures that clients not capable of handling the HTML content are able to read the email in its simplest form.

This should work for mobile devices too, right? Well, sure. If they’re built smart enough to ignore the HTML content and go straight for the plain-text version, that’s great. But that still means that the envelope is 100-150% larger than it would be with just the plain text message. While this isn’t a problem for anyone on a broadband connection, you want to be able to download and read your email on your wireless device as fast as possible. You shouldn’t need to download wasted garbage that won’t be touched anyway.

What about office workers and non-technical staff? Anyone that’s familiar with the pre-Outlook days of email can recognise the non-technical staff person using Outlook in an office environment. If you’re used to using Word, it comes as a surprise to find out that email was never intended to cary richtext. Plain text — what’s that? What do you mean I can’t bold that word? This is a huge usability problem and email really hasn’t provided an elegant solution (unless you consider HTML mail “elegant”).

To these users, it only makes sense that one should be able to compose email using all the same features afforded by a dumb word processor. Unfortunately, the deeper understanding of email and its history just aren’t in the minds of most IT workers anymore, and therefore users don’t understand it either. And why should they have to? Email was never meant to be a complex application. Nor should it be.

For Hotmail users and 75% of the wired world, reply methods means nothing. But it is a huge deal. It’s been the cause of many flamewars over the years. Quoted or outlined; quoting and nested; top replies and bottom replies. What is all this? In the good-old plain-text days, text was quoted with a greater-than sign followed by a space (”> “). One then replied to the entire content (or however much of it the replying author wished to quote) below, such that the email thread read like a conversation. It was very intuitive.

But then software makers started defaulting the reply position above the quoted text. This meant that you had to read the email upside down in reverse in order to re-read the thread. Somewhat less intuitive than bottom-reply (discussed above), but this quickly became the norm with Hotmail and the like.

Then along came HTML mail, which became a hybrid of Microsoft Word and top-replies. This was the end of plain-text.

So what’s better? They all have their merits, of course. Usability, it’s nice to be able to bold text in an email without using special characters to highlight a word. It starts to seem cumbersume and very old-school to train a new office worker to use underscores to make a word appear underlined.

Ultimately, it’s become one big mess of usenet flaming, Outlook HTML abuse, and ill-conceived forking of confirmity. One thing for certain: nothing is going to change. On one hand, it would be nice of the world could abandon plain-text, and everyone move to pure richtext (no, not HTML). But the support isn’t there, and it adds to the bulk on mobile devices. It also makes bottom-replies near impossible; at the very least incredibly awkward. And switching entirely to plain-text seems very 1960s of us. In a world of camera phones and RFID tracking, it feels very backward.

It’s a perfect example of human usability, technical standards and habits, and lack of a plan from the non-Microsofties in the world. Email was never meant to be a complex application.

At work, I am a Windows user. And as a result, I use iTunes to listen to my music while I’m busy coding. iTunes is a wonderful application. I appreciate the way it handles my music and helps me organise the songs I listen to in a sane way. Much better than the way I did in the old days of WinAmp. It’s no wonder that at home I use Amarok (previously known as amaroK; don’t ask, it’s a KDE thing).

The only problem with iTunes are its widget controls. I can’t say for certain how well it works on Mac OS (though I suspect it’s flawless), but I know that it’s a little quirky on Windows.

When I click on the pause button (or any other button, for that matter) when the iTunes window is in the background, the first click only brings the window into focus. I have to click a second time to actually “click” the pause button.

Not a big deal. In fact, it almost makes sense. But when you stop and think: this is not standard Windows behaviour, you start to wonder. What was Apple thinking? Surely other people have complained about this. It’s only a little annoying. But it is a usability issue. And what is Apple better at than most software manufacturers? Usability.

What’s with the trend of teeny-bopping iPod users walking down the street in a group, each of them with one ear bud in, while chatting away amongst themselves. I don’t understand the need of listening to their music while together. There is a reason they are called personal audio players.