Better read this announcement immediately if you’ve updated to 2.1.1 within the last few days. It’s quite likely you need to go to 2.1.2 asap as the security on 2.1.1 was compromised.

This security hole does NOT apply to people still on 2.1 (but I imagine if you were planning to upgrade, you should go directly to 2.1.2…).

Or, what to do when you want to update?

I’ve been thinking about this in light of my previous entry plus the annoyinggood comments my friend made.

There are basically three options to update an application on a Linux distro:

1. From that distro’s official repositories
2. From “unofficial” repositories
3. From source files

Really, all three have their pros and cons. The safest and most prudent approach is to work from official (and, really, popular or widely used as well) repositories. This is least likely to break things and as long as the package managers (apt, rpm, yast, Synaptic Package Manager, and so on and so forth) are used, uninstallation is clean as well. But, I am left dependent on when the folks managing the repositories decide to check in new packages.

This brings me to the second option (which is a slightly fuzzy distinction here, but I’ll make it anyway). There are repositories that individuals put together, often for particular projects, although others put together more general and very useful repositories (such as treviño’s). These repositories, while they make it easier to install more complex updates to applications, may still break other things in the distro as they are usually too narrowly focused on the app to make sure the distro as a whole is okay. This is the problem I had with updating gtkpod: while I used repositories to install it, it broke several applications because of the conflicts it created by updating shared libraries (which were not backward compatible as it turned out).

The third option, to download source and compile can sometimes avoid these problems (for example, by making a private copy of some of the libraries so as to leave the older ones in place for the distro and yet make the newer items available). But the largest con with these are that it’s often difficult to uninstall these things (unless you have a good idea of what you’re doing) and it’s very easy to forget what you’ve done later on. Come a distro upgrade and there may well be two versions of something hanging about. Or, it breaks the custom install and time is required to reconcile the two again. It’s also difficult to resolve things if the compile just doesn’t work, and it’s impossibel to tweak things (eg to have two separate libraries) unless you really are unix-conversant.

Different people take different approaches. One friend is willing to wait and just use official repositories. Another is willing to go for various different things as long as its repository based. I will sometimes compile things from source partly because I can, and partly because I do use things that aren’t actually available any other way. But now and then I get tripped up by zooming a bit too quickly to the third option. For starters, I could have saved myself a little trouble with Flash 9 by using treviño’s handy repository…

Even so, one thing I noticed with new versions (eg, going from Ubuntu’s Dapper Drake to Edgy Eft) is that the newer version sometimes removes or replaces previously installed packages, even those installed from the repository. I can’t remember offhand all of the ones that were so affected, but Network Manager (the best linux app for handling wireless) was one of them. Going from Warty to Dapper, it disappeared entirely, and I threw my hands up and wrote a script. Then going to Edgy, it didn’t like my script anymore, and looking about, I realized Network Manager was now integrated into the desktop. So there’s always that. Sometimes packages are simply removed. I then have to remember what I did have so I can restore it.

To fill in these holes, one of the things I do is I keep a file (I call mine “log” simply enough) in which I detail all the things I do to my Linux installation, and from where/how. Later on, that saves me time figuring out what I did and which programs I do have. It helped me reinstall Flash 9 as well; I’d recorded where I got the instructions and what happened when I followed them.

In any installation, I note the application, the version, the relevant webpages, whether I used apt-get, whether i added repositories (and if so which) and whether I compiled from source (in which case I frequently cut and paste the entire transcript from the terminal into the log. This file is so important I back it up on a jump drive so that I can always get at it.

Update:
I was asked “Why not apt?” As it turns out, the repositories still have Flash 7 listed in them. Nevertheless, this article may be a better/different way to install Flash 9, especially as it looks like it would include automatic updating, and it uses a more standard way of updating (which generally should be via apt; the tricky issue as always is when one wants something not in the repositories).

So earlier this month I installed Flash 9 for Linux on my Firefox from a HowtoForge article. Flash is one of those necessary evils*, I suppose, but it gets more difficult to ignore entirely so while I refuse to use it myself, I do install it so I can see what the heck is going on in some of the sites I visit. Not to mention that YouTube and VideoEgg both use Flash (the latter version 9 in particular).

To install it, I went to the Adobe download site. It automatically detects the incoming OS, so this step needs to be done from the Linux OS. This brings up a tar.gz file which I downloaded and saved. Using a terminal window, I unpacked it via

tar xvfz install_flash_player_9_linux.tar.gz

That gave me a new directory, which I cd’d to. I ran the installer:

sudo ./flashplayer-installer

After getting the root password, there’s some information and verbiage, until eventually it asks:

Please enter the installation path of the Mozilla, SeaMonkey, or Firefox browser...

At this point, I entered /usr/lib/firefox — more on that in a moment. After doing this, it chugged along for a few more seconds before informing me it was done. So now I fired up a Firefox window and all looked well. This was back in the first week of February.

Then about a week ago, I started noticing little oddities. Some of the places I was visiting started using something called VideoEgg, which simply would not run — it just spun in place forever as if it was downloading. I got very hit and miss behaviors, so I checked my plugins on Firefox via about:plugins. Lo and behold, it said I had version 7! Scratching my head, I went through the same process as above, checked again, and it showed 9. This kind of thing made me grumpy, especially when I spotted the same problem next time I started up Firefox. This time I kept searching on “Shockwave” in the about:plugins page and voila! I found I had both versions installed; and the behavior depended on which came up first.

I knew, from that plugin page, the relevant file name is libflashplayer.so. So I used a terminal window and looked for it using

locate libflashplayer.so

and what I found was a copy in /usr/lib/firefox/plugins as well as in ~/.mozilla/plugins. So I renamed the one in .mozilla (as having the older date) to another name, shut Firefox down, and started it up again. This time only one version of Flash (yay!) and at version 9 (yay!). It turns out that Firefox pretty much looks at four places: the global Mozilla and Firefox directories, and the local (home account) Mozilla and Firefox directories. It will find plugins in all of them (and probably a few more for all I know) so using any of these directories in the initial flashplayer-installer script will “work” but if it isn’t the same directory that the previous flash installation resides in, that double plugin situation will occur.

So, what I would recommend before installing Flash 9 is to first see where any older flash plugins are residing (via the locate command above) and either use that as the directory to give to the original flashplayer-installer script, or clean up afterwards, as I did.

And have I got a test site for Flash..

---

*Look at the date on that Flash article!. There are numerous other reasons to hate it as well, but the mockery it makes of accessibility issues, particularly for the visually impaired, is the number one for me.

Webcams are interesting beasties…

First of all, I found out, somewhat to my surprise, that the quality of a webcam can depend as much on the software used as on the camera itself. It turns out that Yahoo’s webcam is very choppy and slow, though it gets the job done. The webcam through the MSN protocol was much better. However, using Kopete’s MSN protocol let me to run into a bug where the incoming cam just freezes and lags — at one point, I realized I was seeing images 10 minutes old. I can only speculate the packets took a quick side trip to a sun-drenched beach somewhere first before coming back to our gray, drizzly area.

So, I tried out aMSN to see if it was true that the webcam performance was better over MSN. This package is strictly for the MSN protocol and is designed just for Linux. The interface to this looks a little rough around the edges, although it’s possible that it’s a font issue in my installation. Ubuntu has 0.95-2.1 in its repositories, but I don’t recommend installing that. aMSN has a later version (0.96) that’s demonstrably improved, and I found it here using a standalone installer (a tar.gz for more traditional compile/install is also offered) which intrigued me enough to try it out, and it installed without any problems.

And indeed, it proved quite responsive with both incoming / outgoing webcams, showing the picture with much less choppiness.

I think in conclusion I’d have to say that I really look forward to Gaim incorporating video capability (which is rumored for 3.0, but as I said, I’m not holding my breath since 2.0 just came out) because I like Gaim’s interface the best. Kopete seems to be actively working on its code, judging from all the email on its devel list, so I would expect the bug I found to be fixed quickly. At that point, I’d be happy to use Kopete, as I can see its interface growing on me. It’s just a pity it doesn’t have a windows version, as I like being able to use the same programs at home and at work. But, in the meantime, aMSN’s not bad at all and I won’t mind using it for the webcam until one of the multiprotocol apps work for me. I prefer to run as few programs as possible

But if what you need is a robust MSN connection, I’d definitely recommend aMSN.

Those busy folks are at it again…just installed another update. This one apparently comes highly recommended with security fixes and the like. As usual, I used Mark on WordPress’s zipped diff file. No fuss, no muss…