Mozilla SeaMonkey and More Confusion

I just downloaded Mozilla SeaMonkey to test out. For the interested, I have some instructions and commands near the end of this post. However this post is more about confusion in Mozilla’s choice of naming for their products.

I don’t care to re-tell the whole story about Netscape, Mozilla and Firefox, but let me be clear that these folks have had the most abysmal track record when it comes to names. Currently the Mozilla project claims the following for SeaMonkey:

The SeaMonkey project is a community effort to deliver production-quality releases of code derived from the application formerly known as “Mozilla Application Suite”. Whereas the main focus of the Mozilla Foundation is on Mozilla Firefox and Mozilla Thunderbird, our group of dedicated volunteers works to ensure that you can have “everything but the kitchen sink” — and have it stable enough for corporate use.

The truth is that sometimes for corporate users and maybe more-so for personal users stability may not be as valuable as name recognition. Simply put a web browser should be known as just that, not code names or monikers. Before the “Mozilla Application Suite”, it was known as just Mozilla. And Firefox (technically Mozilla Firefox) is living on its third name designation (prev. Firebird, prev. Pheonix). I understand the issue with trademarks and branding, but I question if so many names is healthy for Mozilla’s wider adoption. Additionally Firefox and Thunderbird are available through mozilla.COM – the Mozilla Corporation, not to be confused with – the Mozilla Foundation. Of course this move was necessary if any of these groups wanted commercial success of their products.

The way I see it (objections welcome) is that the Mozilla “People” want everyone to think in terms of their flagship products: Firefox Browser and Thunderbird Mail Client. Ideally they would hope the Firefox would somehow imply “web browser” and a similar effect for Thunderbird even though for most people this would not be blatantly obvious (ie. can you guess the purpose of Microsoft Internet Explorer?). The Mozilla folks wouldn’t mind if people forget that Mozilla is (was) also a browser and mail client, so naming it to some funny project code-name (that they really don’t care if people use) would be logical.

Of course this is all just a lot of time wasted (mine included) instead of focusing on better products. I’ll keep using Mozilla whatever-the-hell-you-want-to-call-it, but if they want a true corporate presense this is one of the many factors they need to overcome.

I hope this will be one of the last names thrown around from this group.

SeaMonkey Installation to /opt

This assumes you have either the mozilla or the firefox RPM installed. These commands are for FC4, but should apply to all distributions.

Note: SeaMonkey will properly work with your ~/.mozilla profile directory.

All commands executed as root of course, start with: su -


# wget
# gunzip -c seamonkey-1.0.en-US.linux-i686.tar.gz | tar xf - -C /opt/
# ln -s /opt/seamonkey/seamonkey /usr/local/bin/seamonkey
# cd /opt/seamonkey/
# mv plugins plugins_seamonkey_default
# ln -s /usr/lib/mozilla/plugins plugins


# rm /usr/local/bin/seamonkey
# cd /opt/
# rm -rf seamonkey


As your own user (not root):

# cp -ar ~/.mozilla ~/mozbkp_pre_seamonkey
# seamonkey &

Currently using, it seems significantly faster than Mozilla 1.7.8 and much more responsive than my Firefox installation in FC4. Usability seems the same, however I have not validated added memory or resource consumption (knowing Mozilla, I know it will be a bigger resource hog).

MPlayer Fedora Guide Updated

I updated my guide to compiling MPlayer on Fedora. Of course, this guide is no longer necessary to most people, since RPM’s are available, however seeing as the software is a bit complex I compile it to suit my own needs. I’ve received many emails from NON Fedora users who have found the guide useful. So I will maintain it.

Some things have changed in the past 7 months. LIVE.COM, which provided streaming library support for MPlayer, was renamed to LIVE555. No doubt having to do with Microsoft purchasing Additionally XviD finally release v. 1.1 after almost a year since their last release, and they support GCC4 now. Other than that, there were some minor URL’s which required changes.

There has been a great deal of development in MPlayer behind the scenes, and I wait patiently for the next major release. The CVS builds are pretty slick for the more daring.

Merry Christmas from Macromedia Flash

The most current version of Flash for Linux is version 7.0 while Windows users are already on 8.0. However Macromedia has officially stated that there will be an upcoming version 8.5 for Linux. However it will be shipped after the Windows version becomes available. Even though that post states that no 64bit version is being planned, another engineer has stated that there is some work being done towards a 64bit version.

In the end, it’s good news to see Macromedia/Adobe putting forth some effort to support Linux .

Evaluating New Linux Distributions

For Linux and Open Source in general, choice has always been abundant. However in both the Linux Server market and to a degree in the Linux “Desktop” market only a few major distributions have taken most attention. In my (future) spare time, I plan on evaluating new Linux distributions to see how well they compare for either a Linux Server (preliminary examination) and more critically: the Linux Desktop.

I want to develop a common test/evaluation plan for different distributions so I make fair assessments on their comparable value. Additionally, I do not have the luxury to test any system thoroughly over an extended period of time. The following are some ideas I have thought out.

  • Installation
    • Partitioning, Dual Boot, Networking
  • Software Selection
    • Environments, Office, Multimedia, Development, Server
  • Software Support
    • Security and General Updates, Software Repositories, Package Management
  • Basic Hardware Support
    • Motherboard, Networking, Video, Sound, Power Management (ACPI), DVD/DVD-R
  • Peripheral Hardware Support
    • Digital Camera, Printers, Scanners, Media Card Readers, PDA’s, USB Devices
  • Community Support
    • Mailing Lists, Websites, Forums, Newsgroups
  • General Usuability and Stability
  • Default Behavior and Configuration

I think I have covered the most important issues. Hopefully I will be able to perform all the above for every distribution. I appreciate suggestions and comments to these points.

Pitfalls to Installing Everything

The purpose of this article is to explain the potential problems in installing every package that comes included in any given Linux distribution. For the most part, this is a bad practice and is not conducive to becoming proficient in Linux for either a seasoned professional or a newcomer (ie. “newbie”). It is my hope that this will help educate people on this subject matter.

There are some abundancy arguments that are commonly used and overstated. Specifically: Disk space, memory and bandwidth are all “cheap”. Technically none of these are always true. In fact these are almost always entirely false in third world countries.

There are some minimal advantages to installing everything. There will not be any dependency issues among software packages included in the software distribution. All software will be immediately available for use to try and test. Other advantages are possible, but these are the most relevant.

The problems I see are as follows:

  • Most software will never be used and is redundant. Many of these applications are designed for experienced users who know how to install them even though they are not included in the default install. Examples: Most newbies do not use ‘vi’ or ’emacs’. Most devel packages are only used for compilation.
  • Every software whether used or not must be maintained if they may be accessed by multiple users whether remotely or locally. A typical problem would be for security updates or bugs that you would not normally encounter with default settings.
  • Updates take longer and consume more resources. Everytime a system wide update is done (ex: yum update) it needs to download updates for every single package on the system. Even though you may not pay for your bandwidth, there is some cost to the provider and could serve someone else who could use it more appropriately.
  • (For new comers) You really do not learn anything. It is beneficial at times to understand how software dependancies work and to learn how to install software when needed. Needs change and are not the same for everyone.
  • There is more immediate drain on local resources. Most distributions package enough software to run as either a server and/or a desktop. It does not make sense to run multiple server applications on a desktop machine. Furthermore, most distributions package some packages with the knowledge that some should not run at the same time, i.e. the installer should know what they are doing. Additionally many services and daemons perform redundant tasks, i.e. multiple FTP servers are not typically required or recommended.
  • Although rare, some distributions may include conflicting versions of packages with the intention of the user selecting only one. This is typical of a distribution which may provide a new less popular version in addition to a widely used version. An example in past I’ve seen is (SuSE?) shipping both Apache 1.x as well as Apache 2.x.
  • There are hardware specific options that should not be on every machine and require extra steps to update. In the case of Fedora Core, some kernel packages (which a small population require) are not updated on the same frequency as more common packages. This has lead to some confusion and difficulty.
  • An additional note to Fedora Core users: Fedora Core has always been “bleeding edge” distribution, which basically means it will typically ship with the absolute latest (sometimes not adequately tested) software versions. Also there will always be some software included that may not make it into the next version or update.

Given these points, it is still entirely up to the end user as to what software they should install and use. However, it is very unlikely that anyone could potentially use every single included application. It is better to choose less than more and install as needed. Furthermore it is best to understand why something is needed as opposed to foolish assumptions that more unknown software is beneficial.

MPlayer from CVS in FC4

I’ve been following along with the improvements made by the MPlayer development team through their mailing list. When Fedora Core 4 came out there were some (I think many) issues with the choice to use GCC4 (the GNU Compiler). Many applications, such as MPlayer, were not yet supported. There were patches from other groups, but the MPlayer team did not officially support it. As usual I compiled from source, but I used GCC3.2. I’ve never had any problems.

A week ago I pulled a CVS snapshot through their website and decided to compile and test a developmental version to see anything new. I installed along side my current version of MPlayer v1.0pre7. (I used ----prefix=/opt/mplayercvs/ during the configure step.) It all seemed to work perfectly with GCC4. Some basic things I noticed were better support for some media formats and full support for many output plugins that didn’t work with the GCC3.2 workaround. Finally they also have ported the GUI to GTK2. The forever old (and still very poor) gui was using GTK1.2 and has now been deprecated. Although I don’t see any new features in the GUI, it is nice to finally have a consistent GTK/Gnome interface – fonts, themes and all.

Basically good progress, but not recommended for average users. I am looking forward to the new release, even though lately it seems Xine has seemed like a better alternative.