LinLog

Well, I finally got up the courage to try prelink today. OK, so it's more like I said, "Oh, what the hell," but the outcome is the same. I installed prelink from the Ubuntu repositories and ran it.

If you've not heard of it, prelink is a tool that, well, prelinks your binaries. I'm not exactly an expert on shared libraries, but my understanding is that it basically does the work of the dynamic linker ahead of time. So, instead of the linker relocating libraries at run-time, it's already done. The net result is that programs load faster. This is supposed to be especially true of C++ programs, as they apparently make the loader do a lot of work.

I heard of prelink some time ago, but was always a bit wary of it. I'm a bit wary of anything that modifies system files. But I read through a thread on it at Ubuntu Forums, and there seemed to be few people who had problems, so I decided to give it a go. I also read the documentation and saw that prelink has an uninstall option and that it should cause libraries to revert to their normal loading if, for some reason, prelinking fails. That eased my mind a little.

It's only been a few hours, but so far I haven't been disappointed. I haven't actually timed application start-up with and without prelinking, but KDE applications are definitely loading faster. I don't know if they're loading in half the time, as some people claimed, but the difference is definitely noticable. In particular, I noticed that Kontact is coming up much faster. Also, Konqueror is loading up with almost no wait. Basically, things are now starting in what feels like the right amount of time. I know my Sempron 2500 with 512MB of RAM isn't exactly a high-end system, but it's got enough horse power that I shouldn't have to wait three seconds for the file manager to start up. And now I don't.

Wow, two weeks since the last entry. I guess I haven't had much time for blogging lately.

Anyway, I finally fixed my problem with VMware Player today. After hosing my system a month ago, I hadn't bothered to try installing VMware Player again until about two weeks ago. I didn't figure it would be an issue, since I'd used it under Breezy before. But I was oh so very wrong.

VMware Player works perfectly on a vanilla Kubuntu Breezy installation. However, I had been keeping up with the updates. That was my mistake. It seems that the kernel 2.6.12-10 package is not compatible with VMware's kernel drivers. I had kernel 2.6.12-10 installed, and every time I tried to use a bridged network connection (I'm too lazy to figure out how to use NAT), something bad would happen. If I was lucky, the player would just crash. If I was unlucky, I'd get a kernel panic and the whole system would go down.
The solution? Downgrade to kernel 2.6.12-9. Yes, that's right - "downgrading" to a previous build of the same kernel version fixed the problem.

I think I've learned a valuable lesson from this. That lesson is: screw updates. I don't need to be on the bleeding edge. In fact, I don't need to be on any edge. It's safer to take a Windows kind of approach and use the same damned software until the next OS upgrade. In fact, come to think of it, I should write an entry on Windows and compatibility some time.

So that adventure was a huge waste of time and energy. I still don't know whose fault it was - Ubuntu's or VMware's - and, frankly, I really don't care. It's working now and I'm going to stop doing kernel updates because of this. Between this and my under-sized /boot partition that I don't feel like fixing, kernel updates just aren't worth the trouble.

I'm a little pissed off at BitPim right now. I'm also pissed off at whatever idiot decided it would be a good idea to emulate MacOS.

I just finished using BitPim to get some pictures off my cell phone. Now, for whatever reason, BitPim saves everything is downloads in its own data folder. Apparently it wants to be a one-stop PIM suite that integrates with your cell phone. Whatever.... I think that's a complete waste of time, but I don't know of any other program that runs on Linux and lets me access my phone, so I use it BitPim anyway.

Anyway, today I was stupid enough to try to use the "save" feature for pictures to move them out of the BitPim folder and put them with the rest of my images. I have a folder of other images from my camera, so I figured I'd put them there. However, before I clicked the "OK" button in the save dialog, I realized that I don't completely trust BitPim and decided I'd better check if that folder already had files with the same names as the ones I was saving. It did, so I tried to click the "cancel" button. The only problem was, some moron decided it would be a good idea to put the "OK" button on the right, where the cancel button normally is. By the time I realized this, I'd already clicked "OK" and BitPim happily overwrote my existing files without so much as a warning.

Now, I'm not really too upset about the lost images. They weren't really that important to me. In fact, I don't even remember what they were of. I'm just irritated because the loss was so easily avoidable. For one thing, it's not really that hard to check if a file path already exists. Just a confirmation box would have been enough. In fact, a confirmation box was the least they could do, since I was "saving" multiple files, which means the file picker only showed directories, so I couldn't actually see if there were any files already in the target path.

The second thing, i.e. the position of the OK button, really gets on my nerves. I mean, I knew I wanted to cancel the operation, so I did what I always do: I immediately went for the right-most button. It was completely automatic; I didn't even realize what I was doing until it was already too late. After all, I work at a computer every day, using Windows at work and KDE at home, and the right-most button is alwasy - always - the "cancel" or "no" button. Why would they switch it to the other side? Are they stupid or something?

Most likely, somebody thought it would be a good idea to emulate the MacOS style, kind of like the GNOME people do. And, as Tog pointed out, putting the "OK" button on the right is the more natural design decision. However, Tog also admits that it just doesn't matter anymore. Once Windows hit 90% desktop market share, such small design choices, even if they were correct before, became wrong. In a perfect world, where everyone came to your software with no bad habits, then maybe putting "OK" on the right would be the right choice. But we don't live in a perfect world, and if your software is cross platform, then the odds are that most of the people who use it will be used to Windows. And for any user who is used to Windows, putting "OK" on the right is unequicially wrong.

I guess I'm just sick of developers, especially in the free software world, doing things differently just for the sake of being different. Or perhaps I should say for the sake of not being like Microsoft. There's plenty of room to do new and innovative things without worrying about petty little details like button position. It's not doing your users any favors. This is especially true for people like me, who use Windows at work and Linux (or whatever your favorite OS is) at home. And since I can't choose not to use Windows, guess which piece of software I'll be looking to dump....

You know, years ago I thought the disconnect in user experience didn't matter. I figured that the people who complained about moving back and forth between Windows and Linux were just lamers looking for something to complain about. After a while, though, it really does start to grate on you. It's not an immediately fatal problem, but more like an itch that you can't quite reach. It's not a big deal at first, but it doesn't go away slowly builds up to the point where it drives you insane. That's part of the reason that I use KDE these days - because it can easily be configured to work like Windows.