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?

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.

Who would have ever thought I would be writing about the end of the era of CRTs? I’m a big fan. I thought they offered a crispness LCDs didn’t afford, at resolutions I could afford.

As my Nokia 21″ CRT went on the fritz, I bought a Viewsonic 19″ widescreen LCD this week. 1440×900 isn’t quite as large as the 1600×1200 resolution I was used to. But then again, the freed up (physical) desk space alone is worthwhile. I can’t believe how much space I have now. And it’s actually very nice to look at.

At work, I’m growing used to working with multiple monitors. Perhaps I’ll have to get a second one at home. Of course, I will never have as much (virtual) desktop real-estate as I have at work: a 24″ and a 19″ LCD. Very nice.

After working with them for just a few days, I have to say that the crispness is just as good as my CRT. Especially after the tube started to go. Plus, I find them a lot easier on my eyes.

My last post about URLs was likely a little long and confusing. Allow me to summarise in 3 points exactly what I think is wrong with most URLs today:

1. URLs to web documents (essentially html files, or anything that renders as html) should not include a file extension specifier. The user doesn’t need this, nor does a smart web server/application.
2. URLs should not contain query strings unless absolutely necessary. Most simple GET queries can be nested as a nicely formed path in a URL.
3. A URL should tell you exactly what you are accessing. Numerical identifiers (usually database keys) are fine (of course, it’s better to have meaningful numerical identifiers than random ones, but that’s another story) as long as the user is able to identify them as such. For example: http://www.news.ca/article/7467289598. Even though the number is meaningless, one should be able to make an educated guess that it is some sort of unique identifier used to “look up” the actual article.