IDE thoughts (aka Hating Eclipse)

When I first started programming, way back in the early 1990s, the first IDE I was exposed to was the Borland C++ DOS IDE that came with my copy of Borland C++ (on something like 31 3.5″ disks and a huge box of printed manuals). I started using Microsoft Visual C++ sometime after starting TAMS in 1995 and eventually moved over to Visual Studio after it came out in 1997. All along the way these IDEs were intuitive, easy to use, and still very powerful.

After starting IBM in 2000, I did less and less C/C++ coding and much more scripting work (shell and perl primarily) and web development in PHP. The scripting work didn’t require the use of a full-blown IDE and I did most of my perl development in Scite, a very sophisticated text editor but not a full IDE. The PHP code was developed either in Scite and FTP’d up to the sever or directly on the server using vi/vim.

After about a decade without working with a full IDE, I decided about a week ago that it was time to test the IDE waters out again — primarily for integrated version control support. Against every rational fiber in my body, I decided to try Eclipse.

Up until last week I had an irrational hatred for Eclipse primarily because Lotus is using it for every desktop program they create from Notes to Sametime. Yes, they bundle this huge java-based IDE with dozens of unnecessary plugins that you can’t remove due to dependency hell, just to have an IM session. And of course each one comes with its own bundled java JRE. After being acquired, Rational was forced down this ungodly road as well. Even the most recent version of IBM Tivoli Directory Integrator was moved to Eclipse. At IBM, there is no escaping Eclipse.

Knowing my hatred was primarily an architectural/philosophical issue I decided to give Eclipse a chance for what it was actually developed for: an IDE. I’m happy to say that my hatred is no longer irrational but is well founded: Eclipse sucks.

Unlike all of the other IDEs I’ve ever used, Eclipse is completely unintuitive. My needs weren’t all that difficult: I need a project containing a list of PHP files. I need to be able to edit and save those files. I need to be able to run the scripts through the command line PHP interpreter. And finally I need to be able to commit changes to my local SVN repository.

The project containing PHP files was easy. Editing and saving the files seemed to work OK too, although I’m still not use to its autocompletion stuff and my tab settings still aren’t correct (both user error I know). I’m completely unable to run the files through the PHP interpreter despite multiple times trying to figure it out. It is totally unclear to me how to check files into the SVN repository and at one point while trying to commit something Eclipse helpfully told me that an error occurred then deleted my file. I proceeded to spend the next 2 hours using ext3grep to the file back.

I acknowledge that the bulk of my hatred is just that initial learning curve. I get that Eclipse is very flexible and configureable but that also makes it unintuitive and unforgiving. Unless I can have some Eclipse-guru come sit beside me for a few hours and help me get things set up, I’m not going back.

For now I’m going to explore other IDE options like Komodo and Zend Studio to see how they fare (see also Seven great PHP IDEs compared from developerWorks). If they’re even remotely better than Eclipse they’ll be worth buying.

Running CUDA-enabled BOINC clients on Fedora 11

At the start of the summer I finally got BOINC running on my CUDA-capable NVIDIA graphics card. About the same time I stopped running BOINC since the last thing I needed over the summer was a space heater under my desk. Now that fall is officially upon us, I’m willing to burn some CPU cycles — and warm my feet. I started up BOINC only to discover that it isn’t recognizing the CUDA device any longer. Hurmph.

After some digging it appears that the problem was that some Fedora update along the way tightened up security such that the user running the BOINC service (ie: boinc) was unable to access the /dev/nvidia0 device. Following these instructions I was able to get the permissions fixed and the whole thing working.

Granted, setting up CUDA in the first place was a herculean task since the CUDA libraries have to exactly match the NVIDIA X11 driver versions. Then you have to make sure BOINC knows about the library (ln -s /usr/local/cuda/lib/ /var/lib/boinc/ for instance). The whole matching versions thing is quite the pain in the ass as the X11 drivers can be updated more frequently than the CUDA drivers forcing you to either delay updating the X11 driver install until the CUDA driver matches or upgrading the X11 driver and having CUDA disabled until the CUDA driver catches up.

Oh well, that’s what happens when you live on the bleeding edge!

Installing VMware Player 2.5.3 RPM on Fedora 11

When installing the VMware Player 2.5.3 RPM on Fedora 11, the installation will get stuck in the third ‘Configuring…’ phase. After a bit of digging I discovered the problem is the same as that for installing VMware Workstation 6.5.3 on Fedora 11 and revolves around a locking issue for /etc/vmware/database. Fixing the issue for Player is similar to that for Workstation and is detailed in this forum post by psyk.

Following those directions will allow the RPM to be installed successfully — it even ends with an “Installation was successful” message — despite the python tracebacks it dumps out. The first time you start VMPlayer it’ll ask for the root password in order to configure/compile the kernel modules.

Note that for those of you Fedora 11 users holding out to have VMware cleanly close when shutting down a VM, you’ll be sorely disappointed. kill `pidof vmware-vmx` is still your friend.

OS X and the Linux desktop

I’ve only played with Sebastian, B’s MacBook Pro, for a few hours while getting it configured for B, but from what I’ve seen I really like it.

For the past several years I’ve been running Linux both on my desktop and my laptop. The recent move from RHEL to Fedora on both systems helped with the usability issues but it’s obvious to me that Linux still doesn’t have the spit-and-polish that end-users expect on a desktop workstation. Still, I’m much more productive on a unix-based system than I ever was on a Windows-based system even with cygwin installed.

OS X seems to have the best of both worlds: a unix system with a very polished desktop environment. Moreover Apple isn’t trying to hide the unix underpinnings either — you can easily run a bash/ksh/perl/etc script from the Automator. A real scripting language built right into the OS — no more learning VB scripts just to automate some of B’s tasks! [Aside: powershell might address some of this gripe for Windows systems, and I’ve heard great things about it, but it’s been a long time coming.]

While out at a customer site last week two of the IBMers out on-site were using Macs. When my laptop comes due for an upgrade in ~1.5 years rest assured I’ll be moving to a Mac either on IBM’s dime or my own.

Ubuntu and Fedora

Two months ago I was pondering what Linux distribution to use for my personal machine in the IBM Austin lab. I ended up going with Ubuntu Intrepid – Desktop. At first I had some problems with it albeit all user error like forgetting to disable the power settings so the machine went into suspend mode. After looking back on it, I should have installed the server, not desktop version. Now it seems to be operating just fine.

For my desktop, however, I decided to stick with what I know and went with Fedora 10 for my desktop. After running with Fedora 10 for 1.5 weeks I decided to take the jump on my T60p laptop as well and spent today getting that reinstalled. Overall I’m much happier than I was with the Redhat Enterprise Linux 5 Workstation-based image. Having a recent version of Evolution and other oft-used applications sure is nice, not to mention the little improvements that come with recent Gnome versions.

My desktop is suspending and unsuspending correctly (that should save a few kilowatts of energy over the course of a month) but every time I hibernate the machine it immediately boots back up after successfully writing out the hibernation file. I haven’t had a chance to play with it too much however. I’m hoping I’ll have more luck with the T60p.

Desktop Linux choices

IBM has an standard internal desktop Linux image called the IBM Open Client. This image is based off the Redhat Enterprise Linux 5 Workstation and includes a set of applications to let folks get real work done. Recently they’ve introduced early-adopter programs for an IBM layer on top of Ubuntu and Fedora. The nice thing about using something besides RHEL is that with Ubuntu and Fedora you’re using much more recent kernel and Gnome versions, among other things. Before this Friday I need to select one of the three choices for a reinstallation – I’m mostly undecided which to use.

I possess 3 IBM-provided computers: a T60p laptop and two desktops all of which are running some flavor of the IBM Open Client. One desktop resides in the IBM Austin lab and facilitates me being able to work off-site by providing a place to drive long-running tests and some remote storage. This machine is currently backlevel running RHEL4 and needs to be upgraded to something a bit more current while I’m in town over Thanksgiving. Whatever I do is going to require reinstalling the OS so there’s no real advantage to just upgrading to the latest IBM Open Client image (RHEL4 to RHEL5 requires a reinstall too).

The lab machine operates more as a server than a desktop and being an older model computer it isn’t as though I need a bleeding edge kernel to make the devices work. The most important part of this machine is that it stay on the network and require zero physical interaction — including as few reinstallations as possible. Some might immediately point to a long-term supported Ubuntu release, and I’ve seriously considered that option. The problem is that for my entire Linux career, I’ve been a Redhat/Fedora user and am very familiar with how those distros do things (file layout, configuration tools, package management, etc) — I’m not certain I want to jump to a Debian distro for a remote machine. I’m leaning towards Fedora 10 and while that’s bleeding-edge as far as IBM tools go I think it will be a few years before it comes outdated and I am unable to get package updates for it (which is where I’m at with three Linux servers that I’m responsible for — something I keep putting off addressing).

At some point I’ll be making a similar decision both for my T60p laptop and my dual-head desktop boxes although what I decide to do with the lab machine has little sway on what I’ll end up using for my day-to-day machines. Part of me is still strongly leaning towards Ubuntu if only to become familiar with it and use an LTS release to reinstall the aforementioned three Linux servers.