Adventures & experiences in contemporary technology
With Linux distributions offering you everything on a plate, there is a temptation to stick with what they offer rather than taking things into your own hands. For example, Debian’s infrequent stable releases and the fact that they don’t seem to change software versions throughout the lifetime of such a release means that things such as browser versions are fixed for the purposes of stability; Lenny has stuck with Firefox 3.06 and called it Iceweasel for some unknown reason. However, I soon got to grabbing a tarball for 3.5 and popped its contents into /opt where the self-contained package worked without a hitch. The same modus operandii was used to get in Eclipse PDT and that applied to Ubuntu too until buttons stopped working, forcing a jumping of ship to Netbeans. Of course, you could make a mess when veering away from what is in a distribution but that should be good enough reason not to get carried away with software additions. With the availability of DEB packages for things like Adobe Reader, RealPlayer, VirtualBox, Google Chrome and Opera, keeping things clean isn’t so hard. Your mileage may vary when it comes to how well things work out for you but I have only ever had the occasional problem anyway.
What reminded me of this was a recent irritation with the OpenOffice package included in Ubuntu 9.10 whereby spell checking wasn’t working. While there were thoughts about is situ fixes like additional dictionary installations, I ended up plumping for what could be called the lazy option: grabbing a tarball full of DEB packages from the OpenOffice website and extracting its contents into /tmp and, once the URE package was in place, installing from there using the command:
dpkg -i o*
To get application shortcuts added to the main menu, it was a matter of diving into the appropriate subfolder and installing from the GNOME desktop extension package. Of course, Ubuntu’s OpenOffice variant was removed as part of all this but, if you wanted to live a little more dangerously, the external installation goes into /opt so there shouldn’t be too much of a conflict anyway. In any case, the DIY route got me the spell checking in OpenOffice Writer that I needed so all was well and another Ubuntu rough edge eradicated from my life, for now anyway.
One of the things that stopped working as it should after my recent Ubuntu 9.10 upgrade was the Eclipse PDT installation that I had in place. Editing files went a bit haywire and creating projects had me pushing buttons with nothing happening. Whether this was a Java or GNOME issue, I don’t know but I found it happening too on openSUSE 11.2 (there should be more on that distro in a later entry). That was enough to get me looking again at Netbeans.
In both openSUSE (NB version 6.5) and Ubuntu (NB version 6.7.1), I plucked the default offering of Netbeans from the respective software repositories and added the PHP plugin in both cases. Unlike when I last gave the platform a go, things seemed to go smoothly and it looks to have replaced Eclipse for PHP development duties. Project scanning make take a little while but it’s far from annoying and my earlier dalliance with using Netbeans as a PHP editor was stymied by performance that was so sluggish as to make the thing a pain to use. Up to now, Netbeans’ footprints when it comes to its use of PC power never was light so I am wondering if dual-core and quad-core CPU’s help along with a copious supply of RAM. Only time will tell if these inital positive impressions stay the course and I’ll be keeping an open mind for now.
I have been running into a few woes on the home computing front that may or may not give rise to a number of posts on here. Having my Windows VM’s going awry on VMware is a more worrying development with my need to use a Windows-based application for my hillwalking mapping but I am going to devote this entry to a spot of bother that I started to have with Eclipse, if only because I managed to sort that one out.
Up to yesterday, I had all my offline website development stuff in a single project area for sake of ease of testing. I suppose that I got led into this by my use of Dreamweaver and the way that it sets up what it calls Sites. Applying that same of working to Quanta Plus and Netbeans just chokes up the respective IDE’s and makes them less usable. Until recently, Eclipse escaped this because it seemed to check if a file had changed when you tried editing it and asked you if you wanted the latest version. This stopped in the last few days for whatever reason and it started to stall just like the others.
Naturally, I wanted to set it back as before so a certain amount of investigation was in order. I ended up refreshing my installation in /usr/lib, a manual extraction of the Eclipse PDT archive but that didn’t resolve the issue. In fact, it created another one but we’ll talk about that later. Creating a smaller project made it all work again and I’ll be building up a number of these.
The new issue pertained to the creation and selection of the Eclipse workspace. There was no problem using what I wanted it to use but it wouldn’t remember the setting. There was more blundering about before I happened on the cause: access permissions. I copied the new Eclipse files in as the root user and that meant that Eclipse couldn’t update its setting when I was running it under my own account. Running the editor using sudo sorted out the workspace selection issue for now but a more permanent fixing such as giving myself write access to the configuration directory and what’s in there remains an outstanding task.
The mention of the Eclipse workspace brings me back to the way that it was working before the upheaval hit me. It does keep a copy of every file that you edit in there and maybe more besides. Thus, having a copy of every file in the project would have meant that it didn’t need to do the constant churning being performed by Quanta or Netbeans. That’s impression that I have but I’ll sticking with smaller project bundles from now on. Learning all this was useful.